On Wed, 25 Jul 2018 07:38:37 +0200,
Qu, Jim wrote:
>
> Jim: Just like Alex said, we want driver can get eld info when hotplug in new
> device. amdgpu driver is a bit difference from radeon driver, it is not a
> suitable place to call notify() function in *_audio_enable() , since they are
> not
Hi, Stu:
On Tue, 2018-07-24 at 16:17 +0800, Stu Hsieh wrote:
> This patch add dummy buffer for RDMA memory mode
>
> When display power on, the drm frame work would modeset and
> set up the display HW.
>
> In this time, the RDMA would start wroking and read the data from memory.
> But, user
On 2018年07月25日 13:28, Takashi Iwai wrote:
On Wed, 25 Jul 2018 05:32:52 +0200,
Qu, Jim wrote:
@@ -269,6 +271,10 @@ static void radeon_audio_enable(struct radeon_device *rdev,
if (rdev->audio.funcs->enable)
rdev->audio.funcs->enable(rdev, pin, enable_mask);
+
+
See comments in line.
Thanks
JimQu
发件人: amd-gfx 代表 Takashi Iwai
发送时间: 2018年7月23日 22:50
收件人: alsa-de...@alsa-project.org
抄送: amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
主题: [PATCH 4/4] drm/amdgpu: Add audio component support
This
On Wed, 25 Jul 2018 05:32:52 +0200,
Qu, Jim wrote:
> @@ -269,6 +271,10 @@ static void radeon_audio_enable(struct radeon_device
> *rdev,
>
> if (rdev->audio.funcs->enable)
> rdev->audio.funcs->enable(rdev, pin, enable_mask);
> +
> + if (acomp && acomp->audio_ops &&
On Tue, 24 Jul 2018, Daniel Thompson wrote:
> Currently, if the DT does not define num-interpolated-steps then
> num_steps is undefined and the interpolation code will deploy randomly.
> Fix with a simple initialize to zero.
>
> Fixes: 573fe6d1c25c ("backlight: pwm_bl: Linear interpolation
Hi, Stu:
On Tue, 2018-07-24 at 16:17 +0800, Stu Hsieh wrote:
> This patch fixed the error value for add DSI1 in mutex
>
English is not my mother language, but should it be 'fix' rather than
'fixed'?
Regards,
CK
> Signed-off-by: Stu Hsieh
> ---
> drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 2
https://bugs.freedesktop.org/show_bug.cgi?id=105532
--- Comment #10 from Timothy Arceri ---
(In reply to Christian Lanig from comment #7)
> (In reply to Alexander Tsoy from comment #5)
> > (In reply to Christian Lanig from comment #4)
> > There are native linux binaries in the linux subfolder.
>
Hi Takashi lwai,
Sorry, I have to use outlook again, since my mail client had some problems that
did not receive these series patches.
See the commands in line.
Thanks
JimQu
发件人: amd-gfx 代表 Takashi Iwai
发送时间: 2018年7月23日 22:50
收件人:
Hi, Stu:
On Tue, 2018-07-24 at 16:17 +0800, Stu Hsieh wrote:
> This patch add layer number condition for RDMA to control plane
>
> When plane init in crtc create,
> it use the number of OVL layer to init plane.
> That's OVL can read 4 memory address.
>
> For mt2712 third ddp, it use RDMA to
Hi, Stu:
On Tue, 2018-07-24 at 16:17 +0800, Stu Hsieh wrote:
> This patch add memory mode for RDMA
>
> If use RDMA to read data from memory, it should set memory mode to RDMA
>
> Signed-off-by: Stu Hsieh
> ---
> drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 16 +++-
> 1 file changed,
Hi, Stu:
It looks like the series is a bug fix of [1]. In [1], you create third
crtc but it does not work unless apply this series. So for all the
patches in this series, you should refer to [2] to add 'Fixes:' and
'Cc:' in commit message.
[1]
Hi,
On Tue, Jul 24, 2018 at 12:12 AM, Daniel Thompson
wrote:
> Currently, if the DT does not define num-interpolated-steps then
> num_steps is undefined and the interpolation code will deploy randomly.
> Fix with a simple initialize to zero.
>
> Fixes: 573fe6d1c25c ("backlight: pwm_bl: Linear
On Fri, Jul 20, 2018 at 04:43:09PM -0400, Sean Paul wrote:
> From: Jeykumar Sankaran
>
> Adds bindings for Snapdragon 845 display processing unit
>
> Changes in v2:
> - Use SoC specific compatibles for mdss and dpu (Rob Herring)
> - Use assigned-clocks to set initial clock frequency (Rob
Once we push the job, the scheduler could run it and free it. So, if
we want to reference their fences, we need to grab them before then.
I haven't seen this happen in many days of conformance test runtime,
but let's still close the race.
Signed-off-by: Eric Anholt
Fixes: 57692c94dcbe
This adds just enough performance counter support to measure the
clock. We don't have linux kernel drivers for the clock driving the
HW, and this was useful for determining that the V3D HW is running on
a slow clock, not that the driver was slow.
Signed-off-by: Eric Anholt
---
https://bugs.freedesktop.org/show_bug.cgi?id=106658
--- Comment #5 from Tim Carr ---
Have you tried booting with the 'idle=nomwait' kernel option? This worked for
the submitter of similar bug #106670, and so far seems to have worked for me as
well.
--
You are receiving this mail because:
You
Tanmay Shah writes:
> On 2018-07-24 12:19, Eric Anholt wrote:
>> Tanmay Shah writes:
>>
>>> file derived from msm-next kernel uapi header.
>>
>> Unless there's an exception from Dave, I believe uapi headers in libdrm
>> and Mesa should be direct copies from "make headers_install" on the
>>
On 2018-07-24 12:19, Eric Anholt wrote:
Tanmay Shah writes:
file derived from msm-next kernel uapi header.
Unless there's an exception from Dave, I believe uapi headers in libdrm
and Mesa should be direct copies from "make headers_install" on the
drm-next branch. How does this compare to
On Tue, 24 Jul 2018, Michal Hocko wrote:
> oom_reap_task_mm should return false when __oom_reap_task_mm return
> false. This is what my patch did but it seems this changed by
> http://www.ozlabs.org/~akpm/mmotm/broken-out/mm-oom-remove-oom_lock-from-oom_reaper.patch
> so that one should be fixed.
On Mon, Jul 23, 2018 at 12:32 PM, Gustavo A. R. Silva
wrote:
> idx can be indirectly controlled by user-space, hence leading to a
> potential exploitation of the Spectre variant 1 vulnerability.
>
> This issue was detected with the help of Smatch:
>
> drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c:408
On Mon, Jul 23, 2018 at 10:29 AM, Jia-Ju Bai wrote:
> cik_pcie_gen3_enable() is only called by cik_common_hw_init(), which is
> never called in atomic context.
> cik_pcie_gen3_enable() calls mdelay() to busily wait, which is not
> necessary.
> mdelay() can be replaced with msleep().
>
> This is
https://bugs.freedesktop.org/show_bug.cgi?id=106228
--- Comment #5 from Daniel Drake ---
Created attachment 140809
--> https://bugs.freedesktop.org/attachment.cgi?id=140809=edit
additional patch
this patch may also be required
--
You are receiving this mail because:
You are the assignee for
On Tue, 24 Jul 2018 16:17:47 +0200 Michal Hocko wrote:
> On Fri 20-07-18 17:09:02, Andrew Morton wrote:
> [...]
> > - Undocumented return value.
> >
> > - comment "failed to reap part..." is misleading - sounds like it's
> > referring to something which happened in the past, is in fact
> >
https://bugzilla.kernel.org/show_bug.cgi?id=199425
--- Comment #13 from Johannes Hirte (johannes.hi...@datenkhaos.de) ---
(In reply to Harry Wentland from comment #11)
> Should be fixed by https://patchwork.freedesktop.org/patch/230831/ which is
> merged into amd-staging-drm-next
Just tested
This caused a kernel oops since %pdH interpreted the pointer
as a struct file.
Signed-off-by: Hans Verkuil
---
drivers/gpu/drm/drm_dp_cec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_dp_cec.c b/drivers/gpu/drm/drm_dp_cec.c
index
Tanmay Shah writes:
> file derived from msm-next kernel uapi header.
Unless there's an exception from Dave, I believe uapi headers in libdrm
and Mesa should be direct copies from "make headers_install" on the
drm-next branch. How does this compare to that?
signature.asc
Description: PGP
Boris Brezillon writes:
> This is needed to ensure ->is_unity is correct when the plane was
> previously configured to output a multi-planar format with scaling
> enabled, and is then being reconfigured to output a uniplanar format.
>
> Fixes: fc04023fafec ("drm/vc4: Add support for YUV
https://bugs.freedesktop.org/show_bug.cgi?id=107367
Bug ID: 107367
Summary: [regression, bisected] Games freeze the PC with newest
AMD Staging DRM Next Kernel
Product: Mesa
Version: git
Hardware: Other
OS:
file derived from msm-next kernel uapi header.
Signed-off-by: Tanmay Shah
---
Makefile.sources | 1 +
include/drm/msm_drm.h | 308 ++
2 files changed, 309 insertions(+)
create mode 100644 include/drm/msm_drm.h
diff --git
On 2018-07-23 15:14, Tanmay Shah wrote:
file derived from msm-next kernel uapi header.
Change-Id: Idcaa1ad6fc13e0c1d2d0a2e619121d2c5450f7da
---
Makefile.sources | 1 +
include/drm/msm_drm.h | 308
++
2 files changed, 309 insertions(+)
Hi Jordan,
I might be a bit late for the party, so consider the following jfyi.
On 24 July 2018 at 17:33, Jordan Crouse wrote:
> +void drm_puts(struct drm_printer *p, const char *str)
One could easily use the compiler to detect if drm_printf or drm_puts
should be used. See the trace_printk
https://bugzilla.kernel.org/show_bug.cgi?id=200633
--- Comment #2 from sybo...@gmail.com ---
dmesg: https://ghostbin.com/paste/7pyty
Xorg: https://ghostbin.com/paste/38zyy
amdgpu.dc=0 does indeed make the issue go away, so I'm guessing DC was turned
on by default for Tonga in this kernel.
--
Hi,
On Tuesday 17 July 2018 04:33 AM, Carsten Behling wrote:
modesetting X11 driver may provide negative x/y cordinates in
mdp5_crtc_cursor_move call when rotation is enabled.
Cursor buffer can overlap down to its negative width/height.
ROI has to be recalculated for negative x/y indicating
https://bugs.freedesktop.org/show_bug.cgi?id=107309
--- Comment #2 from Vasilis LIaskovitis ---
Cool, thanks!
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
On Monday, July 16, 2018 03:45:43 PM Hans de Goede wrote:
> On x86 some firmwares use a low non native resolution for the display when
> they have shown some text messages. While keeping the bgrt filled with info
> for the native resolution. If the bgrt image intended for the native
> resolution
On Saturday, July 21, 2018 08:16:09 PM Randy Dunlap wrote:
> From: Randy Dunlap
>
> Fix indentation warning (from gcc 8.1.0) in omap2/omapfb:
>
> ../drivers/video/fbdev/omap2/omapfb/dss/dispc.c: In function 'pixinc':
> ../drivers/video/fbdev/omap2/omapfb/dss/dispc.c:1859:2: warning: this 'else'
On Friday, July 20, 2018 07:52:13 PM Colin King wrote:
> From: Colin Ian King
>
> Pointer 'in' is being assigned but is never used hence it is
> redundant and can be removed.
>
> Cleans up clang warning:
> warning: variable 'in' set but not used [-Wunused-but-set-variable]
>
> Signed-off-by:
On Monday, July 16, 2018 02:44:58 PM Colin King wrote:
> From: Colin Ian King
>
> The value of tmp being used in the switch statement has the range of
> just 0..3 hence the case 4 statement can never be reached and is
> deadcode and can be removed.
>
> Detected by CoverityScan, CID#744384
On Friday, July 13, 2018 05:55:55 PM Dan Carpenter wrote:
> The omapfb_register_client[] array has OMAPFB_PLANE_NUM elements so the
> > should be >= or we are one element beyond the end of the array.
>
> Fixes: 8b08cf2b64f5 ("OMAP: add TI OMAP framebuffer driver")
> Signed-off-by: Dan Carpenter
Add a puts function for the coredump printer to bypass printf()
for constant strings for a speed boost. Reorganize the
coredump printf callback to share as much code as possible.
v2: Try to reuse code between print and puts as suggested by
Chris Wilson
Signed-off-by: Jordan Crouse
---
Add the contents of each ringbuffer to the GPU state and dump the
data in the crash file encoded with ascii85. To save space only
the used portions of the ringbuffer are dumped.
Signed-off-by: Jordan Crouse
---
Documentation/gpu/msm-crash-dump.rst| 7 +
HLSQ, SP and TP registers are only accessible from a special
aperture and to make matters worse the aperture is blocked from
the CPU on targets that can support secure rendering. Luckily the
GPU hardware has its own purpose built register dumper that can
access the registers from the aperture. Add
Add the infrastructure to capture the current state of the GPU and
store it in memory so that it can be dumped later.
For now grab the same basic ringbuffer information and registers
that are provided by the debugfs 'gpu' node but obviously this should
be extended to capture a much larger set of
The i915 DRM driver very cleverly used ascii85 encoding for their
GPU state file. Move the encode functions to a general header file to
support other drivers that might be interested in the same
functionality.
v4: Make the return value const char * as suggested by Chris Wilson
v3: Fix error_puts
Convert the format of the 'show' debugfs file and the crash
dump to a format resembling YAML. This should be easier to
parse and be more flexible for future changes and expansions.
v2: Use a standard .rst for the msm crashdump documentation
Signed-off-by: Jordan Crouse
---
Do a bit of cleanup to prepare for upcoming changes to pass the
hanging task comm and cmdline to the crash dump function.
v2: Use GFP_ATOMIC while holding the rcu lock per Chris Wilson
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/msm_gpu.c | 20 +++-
1 file changed, 11
Capture the GPU state on a GPU hang and store it for later playback
via the devcoredump facility. Only one crash state is stored at a
time on the assumption that the first hang is usually the most
interesting. The existing crash state can be cleared after capturing
it and then a new one will be
For hangs, dump copy out the contents of the buffer objects attached to the
guilty submission and print them in the crash dump report.
Signed-off-by: Jordan Crouse
---
Documentation/gpu/msm-crash-dump.rst| 14 ++
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 58 -
Convert the existing GPU show function to use the GPU state to
dump the information rather than reading it directly from the hardware.
This will require an additional step to capture the state before
dumping it for the existing nodes but it will greatly facilitate reusing
the same code for dumping
Add a puts() function to use seq_puts() to help speed up
up print time for constant strings.
Reviewed-by: Daniel Vetter
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/drm_print.c | 6 ++
include/drm/drm_print.h | 2 ++
2 files changed, 8 insertions(+)
diff --git
Add drm_puts() for a much faster path to print constant strings
into a drm_printer object with memcpy and friends. This can
have seconds off of really large outputs such as GPU dumps.
If the drm_printer object supports a custom puts function then
use that otherwise fall back to the slower legacy
Add a drm printer suitable for use with the read callback for
devcoredump or other suitable buffer based output format that
isn't otherwise covered by seq_file.
v2: Add improved documentation per Daniel Vetter
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/drm_print.c | 74
This is revision 8 implementing a GPU crash state for drm/msm
(https://patchwork.freedesktop.org/series/36097/). This patchset adds better
documentation and reflects comments from the mailing lists. I know we will
miss 4.19 at this point, but I think this is ready to soak in msm-next for
a while.
On Mon, Jul 23, 2018 at 02:27:35PM -0700, matthew.s.atw...@intel.com wrote:
> From: Matt Atwood
>
> According to DP spec (2.9.3.1 of DP 1.4) if
> EXTENDED_RECEIVER_CAPABILITY_FIELD_PRESENT is set the addresses in DPCD
> 02200h through 0220Fh shall contain the DPRX's true capability. These
>
On Mon, Jul 23, 2018 at 02:27:34PM -0700, matthew.s.atw...@intel.com wrote:
> From: Matt Atwood
>
> This bit was added to DP Training Aux RD interval with DP 1.3. Via
> descriptiion of the spec this field indicates the panels true
> capabilities are described in DPCD address space 02200h through
On Tuesday, July 24, 2018 06:13:19 PM Bartlomiej Zolnierkiewicz wrote:
> On Thursday, July 12, 2018 09:29:38 AM Steven Rostedt wrote:
> >
> > From: Steven Rostedt (VMware)
> >
> > There's been discussion on the fb list about the addition of
> > WARN_CONSOLE_UNLOCKED() inside the fb code. The
On Thursday, July 12, 2018 09:29:38 AM Steven Rostedt wrote:
>
> From: Steven Rostedt (VMware)
>
> There's been discussion on the fb list about the addition of
> WARN_CONSOLE_UNLOCKED() inside the fb code. The complaint is that when
> the fb module is loaded with lockless_register_fb the
On Monday, July 09, 2018 05:41:45 PM Gustavo A. R. Silva wrote:
> In preparation to enabling -Wimplicit-fallthrough, mark switch cases
> where we are expecting to fall through.
>
> Signed-off-by: Gustavo A. R. Silva
Patch queued for 4.19, thanks.
Best regards,
--
Bartlomiej Zolnierkiewicz
On Monday, July 09, 2018 05:04:36 PM Gustavo A. R. Silva wrote:
> In preparation to enabling -Wimplicit-fallthrough, mark switch cases
> where we are expecting to fall through.
>
> Signed-off-by: Gustavo A. R. Silva
Patch queued for 4.19, thanks.
Best regards,
--
Bartlomiej Zolnierkiewicz
On Monday, July 09, 2018 04:36:08 PM Gustavo A. R. Silva wrote:
> In preparation to enabling -Wimplicit-fallthrough, mark switch cases
> where we are expecting to fall through.
>
> Signed-off-by: Gustavo A. R. Silva
Patch queued for 4.19, thanks.
Best regards,
--
Bartlomiej Zolnierkiewicz
On Saturday, July 07, 2018 08:29:36 AM Randy Dunlap wrote:
> From: Randy Dunlap
>
> Fix a build warning in viafbdev.c when CONFIG_PROC_FS is not enabled
> by marking the unused function as __maybe_unused.
>
> ../drivers/video/fbdev/via/viafbdev.c:1471:12: warning:
> 'viafb_sup_odev_proc_show'
On Monday, July 09, 2018 12:02:16 AM Tony Lindgren wrote:
> * Arnd Bergmann [180706 12:39]:
> > In a kernel configuration with both CONFIG_FB_OMAP=m and CONFIG_FB_OMAP2=m,
> > Kbuild fails to point out that we have two modules with the same name
> > (omapfb.ko),
> > but instead fails with a
On Friday, July 06, 2018 03:04:22 PM Anton Vasilyev wrote:
> goldfish_fb_probe() allocates memory for fb, but goldfish_fb_remove() does
> not have deallocation of fb, which leads to memory leak on probe/remove.
>
> The patch adds deallocation into goldfish_fb_remove().
>
> Found by Linux Driver
On Thursday, July 05, 2018 03:52:17 PM Daniel Vetter wrote:
> Fix up the indenting that confused sphinx. To make sure we
> don't have to make the examples unreadable with escaping just
> put them in as block quotes, that seems the simplest solution.
>
> Cc: Bartlomiej Zolnierkiewicz
> Cc:
The suspend/resume functions are not referenced when power
management is disabled:
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c:1288:12: error: 'dpu_runtime_resume'
defined but not used [-Werror=unused-function]
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c:1261:12: error: 'dpu_runtime_suspend'
defined
https://bugs.freedesktop.org/show_bug.cgi?id=107309
Emil Velikov changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://bugs.freedesktop.org/show_bug.cgi?id=107309
--- Comment #1 from Emil Velikov ---
The message is harmless since Mesa falls back to use the DRM driver name.
That said, a slightly better (I'm obviously biased) solution has been on the
list for ~month [1]. Just double-checked and pushed it
On 2018-07-20 05:14 PM, Alexandru Gheorghe wrote:
> Drivers that subclass drm_plane need to copy the logic for linking the
> drm_plane with its state and to initialize core properties to their
> default values. E.g (alpha and rotation)
>
> Having a helper to reset the plane_state makes sense
This patch adds a colorspace property, enabling
userspace to switch to various supported colorspaces.
This will help enable BT2020 along with other colorspaces.
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/drm_atomic.c| 4
drivers/gpu/drm/drm_connector.c | 31
This patch attaches the colorspace connector property to the
hdmi connector. Based on colorspace change, modeset will be
triggered to switch to new colorspace.
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/intel_atomic.c | 1 +
drivers/gpu/drm/i915/intel_hdmi.c | 3 +++
2 files changed,
Based on colorspace property value create an infoframe
with appropriate colorspace. This can be used to send an
infoframe packet with proper colorspace value set which
will help to enable wider color gamut like BT2020 on sink.
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/intel_hdmi.c | 2
This patch series creates a new connector property to program
colorspace to sink devices. Modern sink devices support more
than 1 type of colorspace like 601, 709, BT2020 etc. This helps
to switch based on content type which is to be displayed. The
decision lies with compositors as to in which
On Tuesday, July 03, 2018 03:28:13 PM Dan Carpenter wrote:
> The "mem" buffer has "size" bytes. The ">" should be ">=" to prevent
> reading one character beyond the end of the array.
>
> Signed-off-by: Dan Carpenter
Patch queued for 4.19, thanks.
Best regards,
--
Bartlomiej Zolnierkiewicz
On Monday, July 02, 2018 05:04:40 PM Lyude Paul wrote:
> It's been a pretty good while since kernel modesetting was introduced.
> It has almost entirely replaced previous solutions which required
> userspace modesetting, and I can't even recall any drivers off the top
> of my head for modern day
On Saturday, June 30, 2018 03:29:49 PM Yisheng Xie wrote:
> Following pattern is often used:
>
> for (i = 0; i < FB_MAX; i++) {
> if (registered_fb[i]) {
> ...
> }
> }
>
> Therefore, as Andy's suggestion, for_each_registered_fb() helper can
> be introduced to
On Saturday, June 30, 2018 03:30:48 PM Yisheng Xie wrote:
> change beeng to being and occured to occurred.
>
> Signed-off-by: Yisheng Xie
Patch queued for 4.19, thanks.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics
On Saturday, June 30, 2018 10:59:15 AM Timur Tabi wrote:
> On 6/29/18 1:46 PM, Kees Cook wrote:
> > In the quest to remove all stack VLA usage from the kernel[1], this moves
> > the buffer off the stack (since it could be as much as 1024 bytes), and
> > uses a new area in the cursor data
2018-07-23 18:30 GMT+02:00 Eric Engestrom :
> On Friday, 2018-07-20 13:33:29 +0200, Benjamin Gaignard wrote:
>> This is a modetest like tool but using atomic API.
>>
>> With modetest_atomic it is mandatory to specify a mode ("-s")
>> and a plane ("-P") to display a pattern on screen.
>>
>> "-v"
On Monday, July 09, 2018 07:12:50 AM Daniel Mack wrote:
> Hi Bartlomiej,
Hi,
> Should I resend with Robert's Reviewed-bys again? I'd like to get this
> merged for 4.19 if possible.
No need for resend, I added Robert's tags while applying your patches.
Best regards,
--
Bartlomiej
On Sunday, June 24, 2018 05:38:17 PM Daniel Mack wrote:
> Optionally obtain a lcd-supply regulator during probe and use it in
> __pxafb_lcd_power() to switch the power supply of LCD panels.
>
> This helps boards booted from DT to control such voltages without
> callbacks.
>
> Signed-off-by:
On Sunday, June 24, 2018 05:38:16 PM Daniel Mack wrote:
> pxafb_init_fbinfo() can not only report errors caused by failed
> allocations but also when the clock can't be found.
>
> To fix this, return an error pointer instead of NULL in case of errors,
> and up-chain the result.
>
>
On Sunday, June 24, 2018 05:38:14 PM Daniel Mack wrote:
> When parsing the video modes from DT properties, make sure to zero out
> memory before using it. This is important because not all fields in the mode
> struct are explicitly initialized, even though they are used later on.
>
> Fixes:
On Sunday, June 24, 2018 05:38:15 PM Daniel Mack wrote:
> This helps us clean up the probe() and remove() implementations.
>
> Signed-off-by: Daniel Mack
Patch queued for 4.19, thanks.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics
On Wednesday, July 04, 2018 09:35:02 PM Daniel Mack wrote:
> Add a device tree match table for this hardware graphics acceleration
> driver so it can be used by pxa3xx boards booted with a devicetree.
>
> Signed-off-by: Daniel Mack
Patch queued for 4.19, thanks.
Best regards,
--
Bartlomiej
On Wednesday, July 04, 2018 09:35:01 PM Daniel Mack wrote:
> This patch adds the binding documentation for the pxa300 gcu.
>
> Signed-off-by: Daniel Mack
Patch queued for 4.19, thanks.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics
On Wednesday, July 04, 2018 09:08:48 PM Fredrik Noring wrote:
> Hi Bartlomiej,
>
> > > With this change fb_find_mode can match interlaced and progressive
> > > modes equally well, and distinguish between for example 1920x1080i
> > > and 1920x1080p.
> > >
> > > Signed-off-by: Fredrik Noring
> >
Hi Tomi,
Thank you for the patch.
On Monday, 18 June 2018 16:22:35 EEST Tomi Valkeinen wrote:
> Add DT bindings for Texas Instruments K2G SoC Display Subsystem. The DSS
> is quite simple, with a single plane and a single output.
>
> Signed-off-by: Tomi Valkeinen
> Cc:
On Fri 20-07-18 17:09:02, Andrew Morton wrote:
[...]
> - Undocumented return value.
>
> - comment "failed to reap part..." is misleading - sounds like it's
> referring to something which happened in the past, is in fact
> referring to something which might happen in the future.
>
> - fails
Hi Tomi,
Thank you for the patch.
On Monday, 18 June 2018 16:22:34 EEST Tomi Valkeinen wrote:
> From: Peter Ujfalusi
>
> The sync in some panels needs to be driven by different edge of the pixel
> clock compared to data. This is reflected by the
> DISPLAY_FLAGS_SYNC_(POS|NEG)EDGE in videmode
This is needed to ensure ->is_unity is correct when the plane was
previously configured to output a multi-planar format with scaling
enabled, and is then being reconfigured to output a uniplanar format.
Fixes: fc04023fafec ("drm/vc4: Add support for YUV planes.")
Cc:
Signed-off-by: Boris
drm_atomic_helper_async_check() declares the plane, old_plane_state and
new_plane_state variables to iterate over all planes of the atomic
state and make sure only one plane is enabled.
Unfortunately gcc is not smart enough to figure out that the check on
n_planes is enough to guarantee that
Async plane update is supposed to work only when updating the FB or FB
position of an already enabled plane. That does not apply to requests
where the plane was previously disabled or assigned to a different
CTRC.
Check old_plane_state->crtc value to make sure async plane update is
allowed.
https://bugs.freedesktop.org/show_bug.cgi?id=99923
--- Comment #33 from Alex Smith ---
We've had several user reports of this through our support, and reproduced it
internally as well (on a 270X, which is our officially supported minimum spec).
Seems to be specific to SI cards.
Given that this
https://bugs.freedesktop.org/show_bug.cgi?id=107328
Christian König changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--- Comment #3 from Christian
On Tue, Jul 24, 2018 at 09:11:21AM +0100, Alexandru-Cosmin Gheorghe wrote:
> Hi Maxime,
>
> On Tue, Jul 24, 2018 at 08:57:20AM +0200, Maxime Ripard wrote:
> > On Fri, Jul 20, 2018 at 10:15:08PM +0100, Alexandru Gheorghe wrote:
> > > Signed-off-by: Alexandru Gheorghe
> > > ---
> > >
On Sun, Jul 22, 2018 at 04:43:56PM +0200, Jernej Škrabec wrote:
> Hi Maxime,
>
> Dne sreda, 11. julij 2018 ob 10:30:36 CEST je Maxime Ripard napisal(a):
> > On Tue, Jul 10, 2018 at 10:34:53PM +0200, Jernej Skrabec wrote:
> > > This series fixes several issues found in R40 HDMI patch series after
Hey
On request of Noralf, I picked up the patches and prepared v5. Works
fine with
Xorg, if configured according to:
https://lists.freedesktop.org/archives/dri-devel/2014-January/052777.html
If anyone knows how to make Xorg pick it up dynamically without such a
static
configuration,
On Mon, Jul 23, 2018 at 09:57:00AM +0100, Ayan Kumar Halder wrote:
> We do not need sun4i_backend_format_is_packed_yuv422() /
> sun4i_backend_format_is_planar_yuv() to determine if the format is yuv multi
> planar
> or not. (struct drm_format_info *)->is_yuv tells if the format is yuv or not.
>
https://bugs.freedesktop.org/show_bug.cgi?id=106707
Chris Wilson changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
1 - 100 of 157 matches
Mail list logo
