On 28/07/15 14:14, Chris Wilson wrote:
> Styled after WARN_ON/DRM_ERROR_ON, this prints a mild warning message (a
> KERN_NOTICE for significant but mild events) that allows us to insert
> interesting events without alarming the user or bug reporting tools.
>
Wouldn't it be better to opt for DRM_NO
On 28/07/15 14:14, Chris Wilson wrote:
> Styled after WARN_ON/DRM_ERROR_ON, this prints a mild warning message (a
> KERN_NOTICE for significant but mild events) that allows us to insert
> interesting events without alarming the user or bug reporting tools.
>
Wouldn't it be better to opt for DRM_NO
On Tue, Jul 28, 2015 at 11:51 AM, Dan Carpenter
wrote:
> We recently changed the drm_amdgpu_info_device struct so now there is
> a 4 byte hole at the end. We need to initialize it so we don't disclose
> secret information from the stack.
>
> Fixes: fa92754e9c47 ('drm/amdgpu: add VCE harvesting in
On Tue, Jul 28, 2015 at 08:46:24PM +0200, Daniel Vetter wrote:
> On Wed, Jul 22, 2015 at 02:58:01PM +0530, Archit Taneja wrote:
> > Some drm drivers call remove_conflicting_framebuffers. Create a
> > drm_fb_helper function that wraps around these calls.
> >
> > This is part of an effort to prevent
On Wed, Jul 22, 2015 at 02:58:01PM +0530, Archit Taneja wrote:
> Some drm drivers call remove_conflicting_framebuffers. Create a
> drm_fb_helper function that wraps around these calls.
>
> This is part of an effort to prevent drm drivers from calling fbdev
> functions directly, in order to make fb
t --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150728/6a353dd5/attachment-0001.html>
org/archives/dri-devel/attachments/20150728/da20542c/attachment.html>
drivers/gpu/drm/nouveau/nvkm/engine/fifo/gk104.c:372:1-4: WARNING: end returns
can be simpified
Simplify a trivial if-return sequence. Possibly combine with a
preceding function call.
Generated by: scripts/coccinelle/misc/simple_return.cocci
Signed-off-by: Fengguang Wu
---
gk104.c |6
Hello Ben Goz,
The patch 914bea6329b2: "drm/amdkfd: Add support for VI in DQM" from
Jan 12, 2015, leads to the following static checker warning:
drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager_vi.c:158
init_sdma_vm()
warn: should this be a bitwise op?
drivers/gpu/drm/amd/amd
Hello Oded Gabbay,
The patch 32c22e994f44: "drm/amdgpu: add amdgpu <--> amdkfd gfx7
interface" from Jun 12, 2015, leads to the following static checker
warning:
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v7.c:453 kgd_hqd_destroy()
warn: bitwise AND condition is false here
drive
We recently changed the drm_amdgpu_info_device struct so now there is
a 4 byte hole at the end. We need to initialize it so we don't disclose
secret information from the stack.
Fixes: fa92754e9c47 ('drm/amdgpu: add VCE harvesting instance query')
Signed-off-by: Dan Carpenter
diff --git a/driver
From: Werner Johansson
This adds support for the Sharp panel found on the Qualcomm
Snapdragon 800 Dragonboard (APQ8074)
Signed-off-by: Werner Johansson
Signed-off-by: Bjorn Andersson
---
drivers/gpu/drm/panel/Kconfig | 9 +
drivers/gpu/drm/panel/Makefile |
From: Werner Johansson
Signed-off-by: Werner Johansson
Signed-off-by: Bjorn Andersson
---
.../bindings/panel/sharp,ls043t1le01.txt | 22 ++
1 file changed, 22 insertions(+)
create mode 100644
Documentation/devicetree/bindings/panel/sharp,ls043t1le01.txt
diff --
On Tue, Jul 28, 2015 at 06:09:16PM +0100, Dave Gordon wrote:
> On 28/07/15 17:34, Chris Wilson wrote:
> >On Tue, Jul 28, 2015 at 05:29:09PM +0100, Dave Gordon wrote:
> >>On 28/07/15 14:27, Chris Wilson wrote:
> >>>Since we already return -EFAULT to the user, emitting an error message
> >>>*and* WAR
On Tue, Jul 28, 2015 at 02:42:49PM +0100, Emil Velikov wrote:
> On 21 July 2015 at 13:50, Chris Wilson wrote:
> > If the number of items to process in the request is zero, we can forgo
> > duplicating, sorting the request and feeding it into the kernel and
> > instead report success immediately.
On 28/07/15 17:34, Chris Wilson wrote:
> On Tue, Jul 28, 2015 at 05:29:09PM +0100, Dave Gordon wrote:
>> On 28/07/15 14:27, Chris Wilson wrote:
>>> Since we already return -EFAULT to the user, emitting an error message
>>> *and* WARN is overkill. If the caller is upset, they can do so, but for
>>>
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150728/753ed7a7/attachment.html>
On Tue, Jul 28, 2015 at 10:30:08AM -0400, Rob Clark wrote:
> On Tue, Jul 28, 2015 at 7:18 AM, Daniel Vetter
> wrote:
> > Trying to do anything with kms drivers when oopsing has become a
> > failing proposition. But since we can end up in the fbdev code simply
> > due to the console unblanking tha
The struct exynos_drm_gem_obj can have fields of the struct
exynos_drm_gem_buf then don't need to use exynos_drm_buf.c file.
Signed-off-by: Joonyoung Shim
---
drivers/gpu/drm/exynos/Makefile | 3 +-
drivers/gpu/drm/exynos/exynos_drm_buf.c | 170
drivers/gpu
The dma-buf codes of exynos drm is almost same with prime helpers. A
difference is that consider DMA_NONE when import dma-buf, but it's wrong
and we don't consider it any more, so we can use prime interface.
Signed-off-by: Joonyoung Shim
---
drivers/gpu/drm/exynos/Makefile| 2 +-
d
The function roundup_gem_size can be merged in exynos_drm_gem_create.
Signed-off-by: Joonyoung Shim
---
drivers/gpu/drm/exynos/exynos_drm_gem.c | 9 +
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
b/drivers/gpu/drm/exynos/exynos_drm
The function update_vm_cache_attr can be merged in exynos_drm_gem_mmap.
Signed-off-by: Joonyoung Shim
---
drivers/gpu/drm/exynos/exynos_drm_gem.c | 28 +++-
1 file changed, 11 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
b/drivers/
The function check_gem_flags is too simple, so it's better to move codes
in each consumer functions.
Signed-off-by: Joonyoung Shim
---
drivers/gpu/drm/exynos/exynos_drm_gem.c | 24
1 file changed, 8 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exyn
The drm_gem_object_release() function already performs this cleanup,
so there is no reason to do it explicitly.
Signed-off-by: Joonyoung Shim
---
drivers/gpu/drm/exynos/exynos_drm_gem.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
b/drivers/gpu/d
Don't create a fake mmap offset in exynos_drm_gem_dumb_map_offset. If
not, it will call drm_gem_create_mmap_offset whenever user requests
DRM_IOCTL_MODE_MAP_DUMB ioctl.
Signed-off-by: Joonyoung Shim
---
drivers/gpu/drm/exynos/exynos_drm_gem.c | 12 +++-
1 file changed, 7 insertions(+), 5
For more correct error information.
Signed-off-by: Joonyoung Shim
---
drivers/gpu/drm/exynos/exynos_drm_gem.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
b/drivers/gpu/drm/exynos/exynos_drm_gem.c
index 8fffc4d..550d267 1006
The userptr, write and pfnmap of struct exynos_drm_gem_buf are not used
anywhere.
Signed-off-by: Joonyoung Shim
---
drivers/gpu/drm/exynos/exynos_drm_gem.h | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.h
b/drivers/gpu/drm/exynos/exynos_drm_gem.h
Already struct exynos_drm_gem_buf has pages of the buffer, so we don't
need to copy from sg table of the buffer to sg table of dma-buf
attachment, just can make sg table from pages of the buffer.
Signed-off-by: Joonyoung Shim
---
drivers/gpu/drm/exynos/exynos_drm_dmabuf.c | 55 +++---
The exynos_drm_gem_map_buf can be merged in exynos_drm_gem_fault.
Signed-off-by: Joonyoung Shim
---
drivers/gpu/drm/exynos/exynos_drm_gem.c | 36 +++--
1 file changed, 12 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
b/drivers/g
There is no reason to use mutex locking in pagefault handler.
Signed-off-by: Joonyoung Shim
---
drivers/gpu/drm/exynos/exynos_drm_gem.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
b/drivers/gpu/drm/exynos/exynos_drm_gem.c
index 752cb7c..474122
The convert_to_vm_err_msg is called just once by exynos_drm_gem_fault,
so it's simple not to use the function.
Signed-off-by: Joonyoung Shim
---
drivers/gpu/drm/exynos/exynos_drm_gem.c | 33 +
1 file changed, 9 insertions(+), 24 deletions(-)
diff --git a/drivers/
Already struct exynos_drm_gem_buf has pages of the buffer when buffer is
created, so just can use pages in page fault handler, we don't have to
make sgtable of the buffer. But this needs to construct pages of the
buffer that is imported from dma-buf prime.
Signed-off-by: Joonyoung Shim
---
drive
This patchset improves gem and dma-buf codes of exynos drm.
Major changes:
- remove needless using sg table.
- use prime helpers instead of exynos specific dma-buf functions.
- merge struct exynos_drm_gem_buf in struct exynos_drm_gem.
- remove simple functions.
- cleanup.
Thanks.
Joonyoung Shim
This is simplest solution about reported problem[1]. It's no problem to
clear channel only when iommu is enabled, if we consider that we cannot
recognize iommu errors when iommu is disabled and it have been valid
until now. But this cannot be nice solution.
[1] https://lkml.org/lkml/2015/7/21/404
On 07/28/2015 05:30 PM, Krzysztof Kozlowski wrote:
> On 28.07.2015 17:28, Joonyoung Shim wrote:
>> This is simplest solution about reported problem[1]. It's no problem to
>> clear channel only when iommu is enabled, if we consider that we cannot
>> recognize iommu errors when iommu is disabled and
On Tue, Jul 28, 2015 at 05:29:09PM +0100, Dave Gordon wrote:
> On 28/07/15 14:27, Chris Wilson wrote:
> >Since we already return -EFAULT to the user, emitting an error message
> >*and* WARN is overkill. If the caller is upset, they can do so, but for
> >the purposes of debugging we need only log th
On 28.07.2015 17:28, Joonyoung Shim wrote:
> This is simplest solution about reported problem[1]. It's no problem to
> clear channel only when iommu is enabled, if we consider that we cannot
> recognize iommu errors when iommu is disabled and it have been valid
> until now. But this cannot be nice
On 28/07/15 14:27, Chris Wilson wrote:
> Since we already return -EFAULT to the user, emitting an error message
> *and* WARN is overkill. If the caller is upset, they can do so, but for
> the purposes of debugging we need only log the erroneous values.
>
> Signed-off-by: Chris Wilson
> Cc:: Alex D
This is simplest solution about reported problem[1]. It's no problem to
clear channel only when iommu is enabled, if we consider that we cannot
recognize iommu errors when iommu is disabled and it have been valid
until now. But this cannot be nice solution.
[1] https://lkml.org/lkml/2015/7/21/404
On 28 July 2015 at 01:52, Hans de Goede wrote:
> Hi,
>
> On 24-07-15 04:32, Ben Skeggs wrote:
>>
>> On 24 July 2015 at 01:20, Hans de Goede wrote:
>>>
>>> MSI interrupts appear to not work for nv46 based cards. Change the mc
>>> subdev oclass for these cards from nv44 to nv4c, the nv4c mc code is
DRM Docbook is now Markdown ready. This means its doc is able to
use markdown text on it.
* Documentation/DocBook/drm.tmpl: Contains a table duplicated from
drivers/gpu/drm/i915/i915_reg.h. This is not needed anymore
* drivers/gpu/drm/drm_modeset_lock.c: had a code example that used
to look p
Markdown support is given by calling an external tool, pandoc, for all
highlighted text on kernel-doc.
Pandoc converts Markdown text to proper Docbook tags, which will be
later translated to pdf, html or other targets.
This adds the capability of adding human-readle text highlight (bold,
underlin
The "highlight" code is very sensible to the order of the hash keys,
but the order of the keys cannot be predicted on Perl. It generates
faulty DocBook entries like:
- @device_for_each_child
We should use an array for that job, so we can guarantee that the order
of the regex execution on d
Functions, Structs and Parameters definitions on kernel documentation
are pure cosmetic, it only highlights the element.
To ease the navigation in the documentation we should use inside
those tags so readers can easily jump between methods directly.
This was discussed in 2014[1] and is implement
This series add supports for hyperlink cross-references on
Docbooks and an optional markup syntax for in-source
Documentation.
eg:
https://people.collabora.com/~danilo/intel/Documentation.MarkDown/DocBook/drm/API-drm-dev-ref.html
old:
https://people.collabora.com/~danilo/intel/Documentation.
Archit, Laurent,
On Tue, 28 Jul 2015 13:47:37 +0530
Archit Taneja wrote:
> Hi,
>
> On 07/27/2015 02:29 PM, Laurent Pinchart wrote:
> > Hi Archit,
> >
> > (CC'ing Boris Brezillon)
> >
> > Thank you for the patch.
> >
> > On Monday 27 July 2015 11:46:57 Archit Taneja wrote:
> >> ADV7511 is repres
On 27 July 2015 at 10:59, Tapani Pälli wrote:
> On 07/03/2015 06:44 PM, Emil Velikov wrote:
>>
>> On 01/07/15 12:37, Tapani Pälli wrote:
>>>
>>> (We need this include in porting changes for the OpenGL ES
>>> conformance suite.)
>>>
>>> Signed-off-by: Tapani Pälli
>>> ---
>>> intel/intel_bufm
On 07/25/2015 07:20 AM, Stephan Mueller wrote:
> Am Donnerstag, 23. Juli 2015, 15:16:23 schrieb Danilo Cesar Lemes de Paula:
>
> Hi Danilo,
>
>> This series add supports for hyperlink cross-references on Docbooks and
>> an optional markup syntax for in-source Documentation.
>
> Can you please g
Using hdmi_avi_infoframe_pack() to create the AVI infoframe calculates
the checksum of the frame and breaks the second calculation which is
done in tda998x_write_if(). Then the HDMI AVI frame is wrong and
the display device does not handle correctly the video frames.
Fixes: 8c7a075da9f7980c ("use
When looking up a dpaux device through its firmware node, probe it if it
hasn't already.
The goal is to reduce deferred probes to a minimum, as it makes it very
cumbersome to find out why a device failed to probe, and can introduce
very big delays in when a critical device is probed.
Signed-off-b
When looking up a panel through its firmware node, probe it if it hasn't
already.
The goal is to reduce deferred probes to a minimum, as it makes it very
cumbersome to find out why a device failed to probe, and can introduce
very big delays in when a critical device is probed.
Signed-off-by: Tome
Hello,
I have a problem with the panel on my Tegra Chromebook taking longer
than expected to be ready during boot (Stéphane Marchesin reported what
is basically the same issue in [0]), and have looked into ordered
probing as a better way of solving this than moving nodes around in the
DT or playi
On Tue, Jul 28, 2015 at 1:50 PM, Andreas Färber wrote:
> Am 28.07.2015 um 14:54 schrieb Srinivas Kandagatla:
>> This patch adds LVDS panel for IFC6410.
>>
>> Signed-off-by: Rob Clark
>> [Rob Clark: WIP patch]
>> Signed-off-by: Srinivas Kandagatla
>> ---
>> arch/arm/boot/dts/qcom-apq8064-ifc641
On 21 July 2015 at 13:50, Chris Wilson wrote:
> If the number of items to process in the request is zero, we can forgo
> duplicating, sorting the request and feeding it into the kernel and
> instead report success immediately. This prevents a NULL dereference of
> the sorted->items for the no-op
Since we already return -EFAULT to the user, emitting an error message
*and* WARN is overkill. If the caller is upset, they can do so, but for
the purposes of debugging we need only log the erroneous values.
Signed-off-by: Chris Wilson
Cc:: Alex Dai
Cc: Dave Gordon
Cc: Tom O'Rourke
---
driver
Add a new debug value to distinguish and filter upon debug messages
emanating from GEM support code.
Signed-off-by: Chris Wilson
---
include/drm/drmP.h | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index f2d68d185274.
Styled after WARN_ON/DRM_ERROR_ON, this prints a mild warning message (a
KERN_NOTICE for significant but mild events) that allows us to insert
interesting events without alarming the user or bug reporting tools.
For an example I have changed a DRM_ERROR for being unable to set a
performance enhanc
|--- |FIXED
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150728/c755eaa2/attachment.html>
Hi,
On 07/27/2015 02:29 PM, Laurent Pinchart wrote:
> Hi Archit,
>
> (CC'ing Boris Brezillon)
>
> Thank you for the patch.
>
> On Monday 27 July 2015 11:46:57 Archit Taneja wrote:
>> ADV7511 is represented as an i2c drm slave encoder device. ADV7533, on
>> the other hand, is going be a normal i2c
The last user is gone, no need for trylocking any more in this legacy
helper.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_modeset_lock.c | 52 --
include/drm/drm_modeset_lock.h | 1 -
2 files changed, 11 insertions(+), 42 deletions(-)
diff --git
Since the panic handling is gone this is only used for force-restoring
the fbdev/fbcon from sysrq, and that's done with a work item. No need
any more to do trylocks, we can just do normal locking.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_fb_helper.c | 11 +--
1 file changed,
Trying to do anything with kms drivers when oopsing has become a
failing proposition. But since we can end up in the fbdev code simply
due to the console unblanking that's done unconditionally just
removing our panic handler isn't enough. We need to block all fbdev
callbacks when oopsing.
There wa
On Tue, Jul 28, 2015 at 11:55 AM, Daniel Vetter wrote:
> On Tue, Jul 28, 2015 at 10:30:08AM -0400, Rob Clark wrote:
>> On Tue, Jul 28, 2015 at 7:18 AM, Daniel Vetter
>> wrote:
>> > Trying to do anything with kms drivers when oopsing has become a
>> > failing proposition. But since we can end up
for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150728/e302818d/attachment.html>
deon.dpm=0 radeon.runpm=0 radeon.modeset=0 to get X to start
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150728/c8b1550d/attachment-0001.html>
Hi Dave,
More drm-misc, mostly fine-tuning of atomic helpers. They're mostly
driver-wide interface changes of the helpers and I need them for i915
work, so I plan to pull this tag into drm-intel-next too.
Cheers, Daniel
The following changes since commit dcd14dd957f02ef679c61325a2221a0574bdcab3
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150728/0d408c2a/attachment.html>
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150728/94fd1ef6/attachment.html>
On Tue, Jul 28, 2015 at 7:18 AM, Daniel Vetter
wrote:
> Trying to do anything with kms drivers when oopsing has become a
> failing proposition. But since we can end up in the fbdev code simply
> due to the console unblanking that's done unconditionally just
> removing our panic handler isn't enou
On Mon, Jul 27, 2015 at 06:57:33PM -0400, Jilai Wang wrote:
> Add plane properties hflip/vflip which are used in MDP driver to flip
> the input horizontally/vertically.
>
> Signed-off-by: Jilai Wang
Is the existing rotation prop with flip masks not enough?
-Daniel
> ---
> Documentation/DocBook
On Wed, 10 Jun 2015 14:58:48 +0200
Nicholas Mc Guire wrote:
> event API conformance testing with coccinelle spatches are being
> used to locate API usage inconsistencies this triggert with:
> ./drivers/gpu/drm/i2c/tda998x_drv.c:1062
> incorrect check for negative return
>
> The return of
e bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150728/a080c7de/attachment.html>
There is an API to do the same operation on kernel side than on userland.
You can get an dmabuf handle, select the allocator if required, and
secure it on kernel side.
Your question makes me realize that I have forget to add an
EXPORT_SYMBOL for smaf_create_handle function, I will fix that.
Benja
scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150728/bf899e68/attachment.html>
2015-07-27 ì¤í 10:58ì Vlastimil Babka ì´(ê°) ì´ ê¸:
> On 07/13/2015 10:35 AM, Gioh Kim wrote:
>> From: Gioh Kim
>>
>> Migration is completely generalized so that migrating mobile page
>> is processed with lru-pages in move_to_new_page.
>>
>> Signed-off-by: Gioh Kim
>> Acked-by: Rafael
> On Mon, Jul 27, 2015 at 4:55 PM, Vlastimil Babka wrote:
>> On 07/13/2015 10:35 AM, Gioh Kim wrote:
>>>
>>> From: Gioh Kim
>>>
>>> Add framework to register callback functions and check page mobility.
>>> There are some modes for page isolation so that isolate interface
>>> has arguments of p
On Monday 27 July 2015 04:51 PM, Thierry Reding wrote:
> On Thu, Jul 23, 2015 at 09:38:46AM +0200, Daniel Vetter wrote:
> [...]
>> On Thu, Jul 23, 2015 at 9:31 AM, Daniel Vetter
>> wrote:
> [...]
>>> Shobhit Kumar (8):
> [...]
>>>pwm: crc: Add Crystalcove (CRC) PWM driver
>
> Would you
u are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150728/20b852cf/attachment.html>
u are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150728/36bd8259/attachment.html>
Hi Benjamin,
It looks like this framework only allows user space client to talk with trust
application, it there a plan to provide kernel side APIs for kernel space
client?
Please correct me if my understanding is wrong.
Thanks
Xiaoquan
-Original Message-
From: Linaro-mm-sig [mailto:
80 matches
Mail list logo
