From: Dave Airlie
This interface will allow sync object to be used to back
Vulkan fences. This API is pretty much the vulkan fence waiting
API, and I've ported the code from amdgpu.
v2: accept relative timeout, pass remaining time back
to userspace.
v3: return to absolute timeouts.
v4: absolute
On Mon, Jul 17, 2017 at 03:00:47PM -0600, Jonathan Corbet wrote:
> Commit 8f2e045ec878 (drm/color: un-inline drm_color_lut_extract()) moved
> the only kerneldoc comment out of include/drm/drm_color_mgmt.h, leading to
> this warning:
>
> ./include/drm/drm_color_mgmt.h:1: warning: no structured
On Mon, Jul 17, 2017 at 11:14:03AM -0700, Matthias Kaehlcke wrote:
> The current code uses in some instances enum transcoder for PCH
> transcoders and enum pipe in others. This is error prone and clang
> raises warnings like this:
>
> drivers/gpu/drm/i915/intel_dp.c:3546:51: warning: implicit conv
Not all places correctly stated that gem_free_object_unlocked is the
one to use.
Reported-by: Eric Anholt
---
Documentation/gpu/drm-mm.rst | 2 +-
drivers/gpu/drm/drm_gem_cma_helper.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/gpu/drm-mm.rst b/Do
On Mon, Jul 17, 2017 at 11:01:33AM -0700, Eric Anholt wrote:
> Daniel Vetter writes:
>
> > CMA helpers are struct_mutex free, and so is the mxsfb itself. And
> > that's the only valid reason for using gem_free_object. Please read
> > the kerneldoc for this stuff :-)
>
> I'm sure all of these cam
On Mon, Jul 17, 2017 at 04:20:23PM -0700, John Stultz wrote:
> On Tue, Jul 11, 2017 at 9:27 AM, Daniel Vetter wrote:
> > On Tue, Jul 11, 2017 at 5:44 PM, John Stultz wrote:
> >> On Tue, Jul 11, 2017 at 8:12 AM, Daniel Vetter wrote:
> >>> On Tue, Jul 11, 2017 at 5:05 PM, John Stultz
> >>> wrote
On 03/31/2017, 01:23 PM, Arnd Bergmann wrote:
> On Fri, Mar 31, 2017 at 12:29 PM, Jani Nikula
> wrote:
>> On Fri, 31 Mar 2017, Zhenyu Wang wrote:
>>> On 2017.03.30 11:46:27 +0200, Jiri Slaby wrote:
Handlers are currently the only blocker to compile the kernel with gcc 7
and KASAN+use-af
On 2017年07月18日 01:35, Christian König wrote:
Am 17.07.2017 um 19:22 schrieb Marek Olšák:
On Sun, Jul 16, 2017 at 11:36 PM, Dave Airlie wrote:
I can take a look at it, I just won't have time until next week
most likely.
I've taken a look, and it's seemingly more complicated than I'm
expectin
On 2017年07月18日 08:48, Dave Airlie wrote:
From: Dave Airlie
These are just wrappers using the amdgpu device handle.
Signed-off-by: Dave Airlie
Acked-by: Chunming Zhou
---
amdgpu/amdgpu.h| 55 +-
amdgpu/amdgpu_cs.c | 38 +++
Currently the hikey dsi logic cannot generate accurate byte
clocks values for all pixel clock values. Thus if a mode clock
is selected that cannot match the calculated byte clock, the
device will boot with a blank screen.
This patch uses the new mode_valid callback (many thanks to
Jose Abreu for u
The explanation for the endpoint ID numbering scheme is convoluted
and hard to understand.
This patch aims to improve the readability of it by combining the
existing two paragraphs, while also providing a diagram example,
and how endpoints should be numbered based on that example.
Signed-off-by:
https://bugs.freedesktop.org/show_bug.cgi?id=100143
--- Comment #2 from bugzi...@colorremedies.com ---
Created attachment 132741
--> https://bugs.freedesktop.org/attachment.cgi?id=132741&action=edit
journal konly 4.13.0-rc1
Same hardware, different kernel, same 'possible circular locking depend
Allows gdb to access contents of user mode mapped BOs. System memory
is handled by TTM using kmap. Other memory pools require a new driver
callback in ttm_bo_driver.
v2:
* kmap only one page at a time
* swap in BO if needed
* make driver callback more generic to handle private memory pools
* docum
Allows gdb to access contents of user mode mapped VRAM BOs.
v2: return error for non-VRAM pools
Signed-off-by: Felix Kuehling
Reviewed-by: Michel Dänzer
Acked-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 62 +
1 file changed, 62 insertions(
From: Dave Airlie
This just sends chunks to the kernel API for a single command
stream.
This should provide a more future proof and extensible API
for command submission.
v2: use amdgpu_bo_list_handle, add two helper functions to
access bo and context internals.
Signed-off-by: Dave Airlie
---
On Thu, Jul 13, 2017 at 10:13 PM, Maxime Ripard
wrote:
> Some channel0 setup has to be done, no matter what the output interface is
> (RGB, CPU, LVDS). Move that code into a common function in order to avoid
> duplication.
>
> Signed-off-by: Maxime Ripard
> ---
> drivers/gpu/drm/sun4i/sun4i_tcon
On 18 July 2017 at 03:02, Christian König wrote:
> Am 17.07.2017 um 05:36 schrieb Dave Airlie:
>>>
>>> I can take a look at it, I just won't have time until next week most
>>> likely.
>>
>> I've taken a look, and it's seemingly more complicated than I'm
>> expecting I'd want to land in Mesa before
Changes in v2:
- rename rk322x to rk3228(Heiko Stübner)
Signed-off-by: Mark Yao
---
Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt | 4
1 file changed, 4 insertions(+)
diff --git
a/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt
b/Documentation/de
In the hardware design process, the design of line flags
register is associated with the interrupt register,
placing the line flags in the interrupt definition is
more reasonable, and it would make multi-vop define easilier.
Changes in v3:
- Explain more in details, introduce why we need this patc
Vop Full framework now has following vops:
IP versionchipname
3.1 rk3288
3.2 rk3368
3.4 rk3366
3.5 rk3399 big
3.6 rk3399 lit
3.7 rk3228
3.8 rk3328
The above IP version is from H/W define, some of vop support ge
It's a hardware bug, all window's overlay channel reset
value is same, hardware overlay would be die.
so we must initial difference id for each overlay channel.
The Channel register is supported on all vop will full design.
Following is the details for this register
VOP_WIN0_CTRL2
bit[7:4] win_
Since the drm atomic framework, only a small part of the vop
register needs sync write, Currently seems only following registers
need sync write:
cfg_done, standby and interrupt related register.
All ctrl registers are using the sync write method that is
inefficient, hardcode the write_relaxed
Grouping the vop registers facilitates make register
definition clearer, and also is useful for different vop
reuse the same group register.
Signed-off-by: Mark Yao
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 99 +-
drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 61
At present we are using init_table to initialize some
registers, but the Register init table use un-document define,
it is unreadable, and sometimes we only want to update tiny
bits, init table method is not friendly, it's diffcult to
reuse for difference chips.
To make it clean, initialize regist
These patches try to make all current rockchip full framework vop works
on drm, fill missing vop on full framework.
Vop Full framework now has following vops:
IP versionchipname
3.1 rk3288
3.2 rk3368
3.4 rk3366
3.5 rk3399 big
Hi all,
Today's linux-next merge of the drm-misc tree got a conflict in:
drivers/gpu/drm/vc4/vc4_crtc.c
between commit:
1ed134e6526b ("drm/vc4: Fix VBLANK handling in crtc->enable() path")
from the drm-misc-fixes tree and commit:
0b20a0f8c3cb ("drm: Add old state pointer to CRTC .enable
Hi all,
After merging the drm-misc tree, today's linux-next build (x86_64
allmodconfig) failed like this:
Caused by commit
b6dcaaac4474 ("drm/vblank: _ioctl posfix for ioctl handler")
interacting with commit
d5288c88c67c ("switch compat_drm_wait_vblank() to drm_ioctl_kernel()")
from Linu
Rob,
在 2017年07月18日 04:07, Rob Herring 写道:
On Mon, Jul 17, 2017 at 04:14:28PM +0800, Caesar Wang wrote:
This patch adds the MALI's power-model to set the IPA model to be used
for power management.
What's IPA? India Pale Ale or Intermediate Physical Address?
IPA is intelligent Power Allocator.
From: Dave Airlie
This just sends chunks to the kernel API for a single command
stream.
This should provide a more future proof and extensible API
for command submission.
Signed-off-by: Dave Airlie
---
amdgpu/amdgpu.h| 21 +
amdgpu/amdgpu_cs.c | 30
From: Dave Airlie
These are just wrappers using the amdgpu device handle.
Signed-off-by: Dave Airlie
---
amdgpu/amdgpu.h| 55 +-
amdgpu/amdgpu_cs.c | 38 +
2 files changed, 92 insertions(+), 1 deletion(
On Tue, Jul 11, 2017 at 9:27 AM, Daniel Vetter wrote:
> On Tue, Jul 11, 2017 at 5:44 PM, John Stultz wrote:
>> On Tue, Jul 11, 2017 at 8:12 AM, Daniel Vetter wrote:
>>> On Tue, Jul 11, 2017 at 5:05 PM, John Stultz wrote:
>> > be even better if you could calculate whether the mode is valid,
On Mon, Jul 17, 2017 at 4:35 PM, Hans Verkuil wrote:
> On 17/07/17 16:26, Arnd Bergmann wrote:
>> Let me try again without ccache for now and see what warnings remain.
>> We can find a solution for those first, and then decide how to deal with
>> ccache.
>
> Sounds good.
>
> I'm OK with applying
On Mon, Jul 17, 2017 at 08:59:18PM +, Pandiyan, Dhinakaran wrote:
>
>
>
> On Mon, 2017-07-17 at 18:55 +, Pandiyan, Dhinakaran wrote:
> > Looks like a typo in
> >
> > cf54ca8 ("drm/i915/cnl: Implement voltage swing sequence.")
> >
> > but Cc'ing Rodrigo, Clint to make sure this wasn't
Back in 2012, commit 9807f75955ea (UAPI: (Scripted) Disintegrate
arch/s390/include/asm) moved struct cmbdata (and its kerneldoc comments) to
another file, but did not update the docs to match. The result is this
warning:
./arch/s390/include/asm/cmb.h:1: warning: no structured comments found
Commit 8f2e045ec878 (drm/color: un-inline drm_color_lut_extract()) moved
the only kerneldoc comment out of include/drm/drm_color_mgmt.h, leading to
this warning:
./include/drm/drm_color_mgmt.h:1: warning: no structured comments found
That comment is already picked up in drm_color_mgmt.c, so j
The only function of interest in that file was scsi_print_status(). That
function was removed in commit 7ac7076344d9 (scsi: remove
scsi_print_status()) but the docs were not changed to match, yielding this
warning:
./drivers/scsi/constants.c:1: warning: no structured comments found
There's n
There are no kerneldoc comments in drivers/dma-buf/seqno-fence.c, and it
appears there never have been. Stop looking for comments there to
eliminate this warning:
./drivers/dma-buf/seqno-fence.c:1: warning: no structured comments found
Signed-off-by: Jonathan Corbet
---
Documentation/drive
Documentation/gpu/drm-mm.rst includes from include/drm/drm_syncobj.h with
:export:, but this is a header file without export directives. That
results in this warning:
./include/drm/drm_syncobj.h:1: warning: no structured comments found
...and a failure to obtain the documentation from that f
The docs build complains:
./include/linux/init.h:1: warning: no structured comments found
The problem is that the comments in question were moved to module.h in
commit 0fd972a7d91d (module: relocate module_init from init.h to
module.h). Fix basics.rst to match.
Signed-off-by: Jonathan Corbe
...because there are none there, and I cannot figure out what would ever
have been of interest there. This eliminates this warning:
./kernel/sys.c:1: warning: no structured comments found
from the build.
Signed-off-by: Jonathan Corbet
---
Documentation/driver-api/basics.rst | 3 ---
1 fil
I've come to the conclusion that we really need to make the docs build
quieter. Here's a small step in that direction: getting rid of all of the
"no structured comments found" warnings. Such warnings are usually the
result of kerneldoc comments being moved elsewhere, so this took a bit of
git arc
On Mon, 2017-07-17 at 18:55 +, Pandiyan, Dhinakaran wrote:
> Looks like a typo in
>
> cf54ca8 ("drm/i915/cnl: Implement voltage swing sequence.")
>
> but Cc'ing Rodrigo, Clint to make sure this wasn't a workaround.
>
> -DK
Checked with Clint, this wasn't a workaround, a typo indeed.
https://bugs.freedesktop.org/show_bug.cgi?id=100143
Elizabeth changed:
What|Removed |Added
QA Contact|intel-gfx-bugs@lists.freede |
|sktop.org
Hi,
On Mon, Jul 17, 2017 at 1:23 PM, Sean Paul wrote:
>> diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c
>> b/drivers/gpu/drm/rockchip/cdn-dp-core.c
>> index 9b0b058..e59ca47 100644
>> --- a/drivers/gpu/drm/rockchip/cdn-dp-core.c
>> +++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c
>> @@ -802,6 +
On Mon, Jul 17, 2017 at 05:10:45PM +0200, Daniel Vetter wrote:
> CMA helpers are struct_mutex free, and so is the mxsfb itself. And
mxsfb copypasta
otherwise
Reviewed-by: Sean Paul
> that's the only valid reason for using gem_free_object. Please read
> the kerneldoc for this stuff :-)
>
> Sig
https://bugs.freedesktop.org/show_bug.cgi?id=98513
--- Comment #6 from Shawn Starr ---
This currently works in 4.12.0-rc7+ w/ drm-next-4.13-wip, will try latest and
close if works.
--
You are receiving this mail because:
You are the assignee for the bug._
https://bugs.freedesktop.org/show_bug.cgi?id=100141
Shawn Starr changed:
What|Removed |Added
Resolution|--- |WORKSFORME
Status|NEW
https://bugs.freedesktop.org/show_bug.cgi?id=92775
Shawn Starr changed:
What|Removed |Added
Resolution|--- |WORKSFORME
Status|NEW
On Mon, Jul 17, 2017 at 2:55 PM, Maxime Ripard
wrote:
> On Fri, Jul 14, 2017 at 04:56:01PM +0800, Chen-Yu Tsai wrote:
>> Hi,
>>
>> On Thu, Jul 13, 2017 at 10:41 PM, Maxime Ripard
>> wrote:
>> > In the earlier display engine designs, any register access while a commit
>> > is pending is forbidden.
El Mon, Jul 17, 2017 at 11:07:01AM +0200 Daniel Vetter ha dit:
> On Fri, Jul 14, 2017 at 06:04:03PM -0700, Matthias Kaehlcke wrote:
> > The current code uses two different enum types for PCH transcoders and
> > performs implicit conversions between the two types. This is error prone
> > and causes
From: Srinivas Kandagatla
ADV7533 only supports audio samples word width from 16-24 bits.
This patch restricts the audio sample sizes to the supported ones,
so that sound card does not report wrong list of supported hwparms.
Without this patch aplay would fail when playing a 32 bit audio.
Signe
+++ Peter Zijlstra [14/07/17 18:10 +0200]:
On Fri, Jul 14, 2017 at 05:58:18PM +0200, Mike Galbraith wrote:
On Fri, 2017-07-14 at 17:50 +0200, Peter Zijlstra wrote:
> Urgh, is for some mysterious reason the __bug_table section of modules
> ending up in RO memory?
>
> I forever get lost in that
On Fri, Jul 14, 2017 at 8:56 AM, Daniel Vetter wrote:
> On Fri, Jul 14, 2017 at 03:07:11PM +0530, Vikas Patil wrote:
> > On Thu, Jul 13, 2017 at 7:20 PM, Daniel Vetter
> wrote:
> > > On Thu, Jul 13, 2017 at 3:33 PM, Vikas Patil
> wrote:
> > >> Dear All,
> > >>
> > >> I am looking for an solutio
On Mon, Jul 17, 2017 at 10:56:47AM +0200, Hans Verkuil wrote:
> Hi Russell,
>
> On 09/06/17 16:10, Russell King - ARM Linux wrote:
> > On Fri, Jun 09, 2017 at 03:56:39PM +0200, Neil Armstrong wrote:
> >> Yes, but on the Amlogic Meson plarform, the DW-HDMI CEC controller is
> >> not used, but a cus
Hi Maxime,
On 17/07/17 07:32, Maxime Ripard wrote:
> On Thu, Jul 13, 2017 at 05:25:08PM +0100, Kieran Bingham wrote:
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> index 82b978a5dae6..c2f382feca07 100644
> --- a/drivers/gpu/drm/rca
The current code uses in some instances enum transcoder for PCH
transcoders and enum pipe in others. This is error prone and clang
raises warnings like this:
drivers/gpu/drm/i915/intel_dp.c:3546:51: warning: implicit conversion
from enumeration type 'enum pipe' to different enumeration type
'e
At module unload we are expecting a struct drm_device but at
probing we are not setting it right. Fix this and correct the
arcpgu module unload.
Signed-off-by: Jose Abreu
Fixes: 0c4250e7b15e ("drm: Add support of ARC PGU display controller")
Cc: Carlos Palminha
Cc: Alexey Brodkin
Cc: Daniel Vet
On 7/14/2017 4:13 PM, Rob Clark wrote:
On Fri, Jul 14, 2017 at 12:52 AM, Rajendra Nayak wrote:
Hi Rob,
On 07/11/2017 11:50 PM, Rob Clark wrote:
The goal here is to support inheriting a display setup by bootloader,
although there may also be some non-display related use-cases.
Rough idea is
For 0.85V cnl_get_buf_trans_edp() returns the DP table, instead of EDP.
Use the correct table.
The error was pointed out by this clang warning:
drivers/gpu/drm/i915/intel_ddi.c:392:39: warning: variable
'cnl_ddi_translations_edp_0_85V' is not needed and will not be emitted
[-Wunneeded-interna
Hi all,
Two fixes and an improvement for arcpgu. I've sent this patches in separate
but I've now collected them all to ease the review.
Best regards,
Jose Miguel Abreu
Jose Abreu (3):
drm: arcpgu: Fix mmap() callback
drm: arcpgu: Fix module unload
drm: arcpgu: Allow some clock deviation in
From: Srinivas Kandagatla
Currently hdmi client drivers does have means to limit the
sample sizes that it can only support. Having formats parameter
option would solve this.
This issue was noticed on DB410c board when adv7511 hdmi codec driver
failed to play a 32 bits audio samples, as it does n
On Mon, Jul 17, 2017 at 01:39:48PM +0200, Hans Verkuil wrote:
> On 17/07/17 11:05, Russell King - ARM Linux wrote:
> > On Mon, Jul 17, 2017 at 10:56:47AM +0200, Hans Verkuil wrote:
> >> Hi Russell,
> >>
> >> On 09/06/17 16:10, Russell King - ARM Linux wrote:
> >>> On Fri, Jun 09, 2017 at 03:56:39PM
Now that ARC properly supports DMA mmap() we can use the standard
CMA helper to map dumb buffers. This makes ARC PGU works with
standard DRM consumer applications like, for example, mpv/mplayer
via DRM. While at it, use the DEFINE_DRM_GEM_CMA_FOPS() helper.
This fixes the use of dumb buffers.
Sig
From: Srinivas Kandagatla
This patch adds option to allow hdmi-codec drivers to restrict
the audio sample size based on the values that are suppored in hardware.
First patch is adding that formats option to hdmi_codec_pdata and
second patch is a fix in adv7511 codec driver which only supports
16
On Fri, Jul 14, 2017 at 04:38:01PM +0200, Lucas Stach wrote:
> While this is no build dependency, etnaviv will only work correctly on most
> systems if CMA and DMA_CMA are enabled. Select both options if available to
> avoid users ending up with a non-working GPU due to a lacking kernel config.
Ho
Hi Daniel, all,
So, I was playing around with arcpgu and I found a bug at module
unloading. I corrected it and tested (using a 4.12 kernel) and I
got a nice WARNING from DRM core at unloading (instead of the old
NULL pointer I got :D). I debugged it and found out that an empty
modesetting (i.e. a
For 0.85V cnl_get_buf_trans_edp() returns the DP table, instead of EDP.
Use the correct table.
The error was pointed out by this clang warning:
drivers/gpu/drm/i915/intel_ddi.c:392:39: warning: variable
'cnl_ddi_translations_edp_0_85V' is not needed and will not be emitted
[-Wunneeded-interna
Currently we expect that clock driver produces the exact same value
as we are requiring. There can, and will, be some deviation
however so we need to take that into account instead of just
rejecting the mode.
According to the HDMI spec we have a max of +-0.5% for the pixel clock
frequency deviatio
On Sat, Jul 15, 2017 at 07:00:18PM +0800, Chris Zhong wrote:
> Some DP/HDMI sink need to receive the audio infoframe to play sound,
> especially some multi-channel AV receiver, they need the
> channel_allocation from infoframe to config the speakers. Send the
> audio infoframe via SDP will make the
Hi Matt,
On 17 July 2017 at 20:39, Matt Hoosier wrote:
> Also beware that the DRM backend of Weston will aggressively set the mode
> before you have any chance to paint user-defined content of your own in a
> Wayland client program. So there will still be some window of time during
> which your e
On Mon, Jul 17, 2017 at 04:14:28PM +0800, Caesar Wang wrote:
> This patch adds the MALI's power-model to set the IPA model to be used
> for power management.
What's IPA? India Pale Ale or Intermediate Physical Address?
>
> Signed-off-by: Caesar Wang
> ---
>
> Changes in v2: None
>
> Document
On Mon, Jul 17, 2017 at 04:14:27PM +0800, Caesar Wang wrote:
> RK3399's GPU uses the quad-core Mali-T860, which is the new generation of
> high-end graphics processors from ARM.
>
> This patch added "rockchip,rk3399-mali" for dt-bindings, in order to
> support IPA of gpu thermal in later.
>
> Sig
On Sat, Jul 15, 2017 at 02:47:50PM +0200, Hans Verkuil wrote:
> From: Hans Verkuil
>
> This documents the binding for the Tegra CEC module.
>
> Signed-off-by: Hans Verkuil
> ---
> .../devicetree/bindings/media/tegra-cec.txt| 26
> ++
> 1 file changed, 26 insertions
This makes sense, it should have returned the edp ddi buf translation
table as per the Bspec.
Please add this to the commit message:
Fixes: cf54ca8bc567 ("drm/i915/cnl: Implement voltage swing sequence.")
After that,
Reviewed-by: Manasi Navare
Manasi
On Mon, Jul 17, 2017 at 11:21:27AM -0700, M
Looks like a typo in
cf54ca8 ("drm/i915/cnl: Implement voltage swing sequence.")
but Cc'ing Rodrigo, Clint to make sure this wasn't a workaround.
-DK
On Mon, 2017-07-17 at 11:21 -0700, Matthias Kaehlcke wrote:
> For 0.85V cnl_get_buf_trans_edp() returns the DP table, instead of EDP.
> Use th
https://bugzilla.kernel.org/show_bug.cgi?id=196337
Johannes Hirte (johannes.hi...@datenkhaos.de) changed:
What|Removed |Added
Summary|Re-enable GFX PG breaks |[amdgpu][c
On Thu, Jul 13, 2017 at 04:13:09PM +0200, Maxime Ripard wrote:
> The LHR050H41 is a 1280x700 4-lanes DSI panel.
>
> Signed-off-by: Maxime Ripard
> ---
> Documentation/devicetree/bindings/display/panel/huarui,lhr050h41.txt | 19
> +++
> 1 file changed, 19 insertions(+)
> create
On Thu, Jul 13, 2017 at 04:13:06PM +0200, Maxime Ripard wrote:
> The Allwinner SoCs usually come with a DSI encoder. Add a binding for it.
>
> Signed-off-by: Maxime Ripard
> ---
> Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt | 85 +++-
> 1 file changed, 85 insertions(+)
> c
Daniel Vetter writes:
> CMA helpers are struct_mutex free, and so is the mxsfb itself. And
> that's the only valid reason for using gem_free_object. Please read
> the kerneldoc for this stuff :-)
I'm sure all of these came from copy and paste, not the docs. That
said, the CMA docs currently say
Am 17.07.2017 um 19:22 schrieb Marek Olšák:
On Sun, Jul 16, 2017 at 11:36 PM, Dave Airlie wrote:
I can take a look at it, I just won't have time until next week most likely.
I've taken a look, and it's seemingly more complicated than I'm
expecting I'd want to land in Mesa before 17.2 ships, I'
On Wed, Jul 12, 2017 at 10:04:02AM +0800, Mark Yao wrote:
> Changes in v2:
> - rename rk322x to rk3228(Heiko Stübner)
This goes below '---' and you need a commit msg here. Also, it is not
clear in the subject this is for Rockchip.
> Signed-off-by: Mark Yao
> ---
> Documentation/devicetree/bin
On Sun, Jul 16, 2017 at 11:36 PM, Dave Airlie wrote:
>>
>> I can take a look at it, I just won't have time until next week most likely.
>
> I've taken a look, and it's seemingly more complicated than I'm
> expecting I'd want to land in Mesa before 17.2 ships, I'd really
> prefer to just push the n
Am 14.07.2017 um 21:44 schrieb Felix Kuehling:
On 17-07-14 06:08 AM, Christian König wrote:
Am 13.07.2017 um 23:08 schrieb Felix Kuehling:
[SNIP]
+result += bytes;
+buf = (uint8_t *)buf + bytes;
+pos += bytes;
+len -= bytes;
+if (pos >= (nodes->start + no
Am 17.07.2017 um 05:36 schrieb Dave Airlie:
I can take a look at it, I just won't have time until next week most likely.
I've taken a look, and it's seemingly more complicated than I'm
expecting I'd want to land in Mesa before 17.2 ships, I'd really
prefer to just push the new libdrm_amdgpu api
On Mon, Jul 17, 2017 at 05:06:42PM +0200, Daniel Vetter wrote:
> On Mon, Jul 17, 2017 at 11:35 AM, Peter Zijlstra wrote:
> > On Sat, Jul 15, 2017 at 11:53:28AM +0200, Daniel Vetter wrote:
> >> A more complete solution would be to do the mutex_init in the drm core
> >> only for legacy drivers, plus
https://bugs.freedesktop.org/show_bug.cgi?id=101787
--- Comment #7 from Julien Isorce ---
Thx for the logs but I do not see anything that could be associated to "radeon:
The kernel rejected CS, see dmesg for more information (-22)" in the first
dmesg attached.
Also about GST_DEBUG=6, do: GST_D
On Fri, Jul 14, 2017 at 08:12:12PM -0700, Brian Norris wrote:
> DRM drivers should supply a compat version if they're going to provide
> an ioctl implementation at all. This can confuse 32-bit user space on a
> 64-bit system.
>
> Signed-off-by: Brian Norris
Thanks, applied.
-Daniel
> ---
> dri
https://bugs.freedesktop.org/show_bug.cgi?id=101787
--- Comment #6 from 247 ---
inserted all you requested...also, inputting your command in terminal results
in "wrong pipeline, no vaapih264enc"
--
You are receiving this mail because:
You are the assignee for the bug.___
https://bugs.freedesktop.org/show_bug.cgi?id=101787
--- Comment #5 from 247 ---
Created attachment 132738
--> https://bugs.freedesktop.org/attachment.cgi?id=132738&action=edit
dmesg after boot
--
You are receiving this mail because:
You are the assignee for the bug.___
https://bugs.freedesktop.org/show_bug.cgi?id=101787
--- Comment #4 from 247 ---
Created attachment 132737
--> https://bugs.freedesktop.org/attachment.cgi?id=132737&action=edit
dmesg gst debug_6
--
You are receiving this mail because:
You are the assignee for the bug.__
https://bugs.freedesktop.org/show_bug.cgi?id=101787
--- Comment #3 from 247 ---
Created attachment 132735
--> https://bugs.freedesktop.org/attachment.cgi?id=132735&action=edit
this is the dmesg file...
this is the dmesg file...i will post dmesg after boot and other thing you
requested in a mom
Looks good to me.
Reviewed-by: Lyude
On Mon, 2017-07-17 at 15:10 +0300, Imre Deak wrote:
> On Thu, May 12, 2016 at 04:00:40PM +0300, Imre Deak wrote:
> > In case of an unknown broadcast message is sent mstb will remain
> > unset,
> > so check for this.
> >
> > CC: Dave Airlie
> > Signed-off-by
On Mon, Jul 17, 2017 at 11:39:56AM +0200, Maarten Lankhorst wrote:
> Op 15-07-17 om 11:31 schreef Daniel Vetter:
> > The legacy plane->fb pointer is refcounted by calling
> > drm_atomic_clean_old_fb().
> >
> > In practice this isn't a real problem because:
> > - The caller in the i915 gpu reset cod
https://bugzilla.kernel.org/show_bug.cgi?id=196197
--- Comment #9 from Andreas Brogle (an...@ok.de) ---
Hello,
same problem with a ATI Radeon HD3450 graphics card (RV620).
Maybe the problem is mainboard specific, it is a TYAN S3992-E.
Life must go on.
Have installed a NVIDIA card now. That is wo
CMA helpers are struct_mutex free, and so is the mxsfb itself. And
that's the only valid reason for using gem_free_object. Please read
the kerneldoc for this stuff :-)
Signed-off-by: Daniel Vetter
Cc: Shawn Guo
---
drivers/gpu/drm/zte/zx_drm_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 delet
CMA helpers are struct_mutex free, and so is the mxsfb itself. And
that's the only valid reason for using gem_free_object. Please read
the kerneldoc for this stuff :-)
Signed-off-by: Daniel Vetter
Cc: Eric Anholt
---
drivers/gpu/drm/pl111/pl111_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 de
CMA helpers are struct_mutex free, and so is the mxsfb itself. And
that's the only valid reason for using gem_free_object. Please read
the kerneldoc for this stuff :-)
Signed-off-by: Daniel Vetter
Cc: Marek Vasut
---
drivers/gpu/drm/mxsfb/mxsfb_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 de
On Mon, Jul 17, 2017 at 11:35 AM, Peter Zijlstra wrote:
> On Sat, Jul 15, 2017 at 11:53:28AM +0200, Daniel Vetter wrote:
>> A more complete solution would be to do the mutex_init in the drm core
>> only for legacy drivers, plus add it to each modern driver that still
>> needs it, which would also
2017-07-17 13:50 GMT+02:00 Hans Verkuil :
> If the stih-cec driver is a module and the drm sti driver is built-in, then
> the CEC core will be a module also, causing the CEC notifier to fail (will be
> compiled as empty functions).
>
> To prevent this select CEC_CORE if CEC_NOTIFIER is set to ensur
https://bugs.freedesktop.org/show_bug.cgi?id=98924
Stefano Cipriani changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
1 - 100 of 155 matches
Mail list logo
