Upcoming implementations of the R-Car DU have removed support for
interlaced display pipelines. Provide a means to determine this based on
the feature flags of the hardware configuration structs.
Signed-off-by: Kieran Bingham
---
This could be a feature to designate that there is no interlaced
The R-Car DU on the D3 and E3 does not support interlaced pipelines,
thus we need to have a means to reject interlaced configurations on
those platoforms.
Provide a new feature flag, and add that flag to all existing devices
which currently support interlaced pipelines.
When D3 and E3 support is
https://bugs.freedesktop.org/show_bug.cgi?id=107607
Paul Menzel changed:
What|Removed |Added
CC||pmenzel+bugs.freedesktop@mo
On Fri, 2018-08-17 at 16:11 +0200, Hans Verkuil wrote:
> From: Hans Verkuil
>
> Add DisplayPort CEC-Tunneling-over-AUX support to nouveau.
>
> Signed-off-by: Hans Verkuil
> ---
> drivers/gpu/drm/nouveau/nouveau_connector.c | 17 +++--
> 1 file changed, 15 insertions(+), 2
Hi Dmitry,
I love your patch! Yet something to improve:
[auto build test ERROR on tegra-drm/drm/tegra/for-next]
[also build test ERROR on v4.18 next-20180820]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci
https://bugs.freedesktop.org/show_bug.cgi?id=107627
Bug ID: 107627
Summary: Freedesktop runtime version 18.08 Mesa cached shaders
result in crashes
Product: Mesa
Version: 18.1
Hardware: Other
OS: All
https://bugzilla.kernel.org/show_bug.cgi?id=200869
Bug ID: 200869
Summary: UVD cause amdgpu crash on CIK: [amdgpu]] UVD not
responding, trying to reset the VCPU
Product: Drivers
Version: 2.5
Kernel Version: 4.17.17
https://bugs.freedesktop.org/show_bug.cgi?id=107482
--- Comment #9 from Leo Li ---
Michel's right about xgamma leaving 0 and max per-channel values unmodified, so
the original issue is not-a-bug. Although I'm not sure why there's a difference
between amdgpu and dc, I'll have to look into it.
--
Reviewed-by: Lyude Paul
We really need to add support for using this into the MST helpers. A good way to
test this would probably be to hook up an aux device to the DP AUX adapters we
create for each MST topology
On Fri, 2018-08-17 at 16:11 +0200, Hans Verkuil wrote:
> From: Hans Verkuil
>
>
On 15.08.2018 21:49, Sean Paul wrote:
> From: Guenter Roeck
>
> 0day reports:
>
>>> drivers/gpu/drm/bridge/ti-sn65dsi86.o: In function
> `ti_sn_bridge_remove':
>>> drivers/gpu/drm/bridge/ti-sn65dsi86.c:629: undefined reference to
> `mipi_dsi_detach'
>>> drivers/gpu/drm/bridge/ti-sn65dsi86.c:630:
https://bugs.freedesktop.org/show_bug.cgi?id=107482
--- Comment #8 from Michel Dänzer ---
Leo, any ideas what's going on here?
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
Hi Kieran,
Thank you for the patch.
On Monday, 20 August 2018 19:00:44 EEST Kieran Bingham wrote:
> Upcoming implementations of the R-Car DU have removed support for
> interlaced display pipelines. Provide a means to determine this based on
> the feature flags of the hardware configuration
These flags are represented by bit fields. To make this clear, utilise
the BIT() macro.
Signed-off-by: Kieran Bingham
---
This patch fails checkpatch's 80-char limit, due to the line comments
extending across the 80-char boundary on RCAR_DU_FEATURE_EXT_CTRL_REGS
To preserve formatting - this
https://bugs.freedesktop.org/show_bug.cgi?id=107607
--- Comment #1 from Paul Menzel ---
Created attachment 141201
--> https://bugs.freedesktop.org/attachment.cgi?id=141201=edit
Linux 4.18+ messages with drm.debug=0xe
Here is a verbose log. I believe it’s related to DP 1.2 and the MST Dell
This series fixes some intermittent issues with bringing up the
dedicated GM107 GPU that I've been observing on my ThinkPad P50. More
details within.
Lyude Paul (2):
drm/nouveau: Fix GM107 disp core chan init on ThinkPad P50
drm/nouveau: Fix GM107 disp dmac chan init on ThinkPad P50
https://bugs.freedesktop.org/show_bug.cgi?id=105251
--- Comment #18 from Andrey Grodzovsky ---
(In reply to CheatCodesOfLife from comment #17)
> (In reply to Andrey Grodzovsky from comment #16)
> > Hi everyone, I've tried with latest kernel and latest VEGA10 firmware and
> > wasn't able to
https://bugzilla.kernel.org/show_bug.cgi?id=200605
--- Comment #5 from Michel Dänzer (mic...@daenzer.net) ---
(In reply to richts from comment #4)
> In the meantime I'm at 4.18.1 and the problem never happened since then.
Glad to hear that! Can you resolve this report accordingly? Thanks.
--
I've been experiencing a rather strange looking bug on the P50 I've got
for work. After a number of reboots, nouveau will fail to initialize the
dedicated GPU on the system at boot properly. Things start off with
this disp mthd failure:
...
[2.088505] nouveau :01:00.0: disp: outp
Just like how the P50 will occasionally leave the disp's core channel on
before nouveau starts initializing, it will occasionally do the same
thing with the rest of the dmac channel in addition to the core channel.
Example:
[1.604375] nouveau :01:00.0: disp: outp 04:0006:0f81: no heads (0
Hi Kieran,
Thank you for the patch.
On Monday, 20 August 2018 19:00:43 EEST Kieran Bingham wrote:
> These flags are represented by bit fields. To make this clear, utilise
> the BIT() macro.
>
> Signed-off-by: Kieran Bingham
Reviewed-by: Laurent Pinchart
> ---
> This patch fails checkpatch's
On 20.08.2018 17:26, Guenter Roeck wrote:
> On Mon, Aug 20, 2018 at 8:15 AM Andrzej Hajda wrote:
>> On 15.08.2018 21:49, Sean Paul wrote:
>>> From: Guenter Roeck
>>>
>>> 0day reports:
>>>
> drivers/gpu/drm/bridge/ti-sn65dsi86.o: In function
>>> `ti_sn_bridge_remove':
>
https://bugs.freedesktop.org/show_bug.cgi?id=107545
Julien Isorce changed:
What|Removed |Added
Attachment #141084|0 |1
is obsolete|
https://bugs.freedesktop.org/show_bug.cgi?id=107627
Vibol changed:
What|Removed |Added
Hardware|Other |x86-64 (AMD64)
OS|All
On Fri, 2018-08-17 at 16:11 +0200, Hans Verkuil wrote:
> From: Hans Verkuil
>
> If aux->transfer == NULL, then just return without doing
> anything. In that case the function is likely called for
> a non-(e)DP connector.
>
> This never happened for the i915 driver, but the nouveau and amdgpu
>
https://bugs.freedesktop.org/show_bug.cgi?id=107545
--- Comment #3 from Julien Isorce ---
Created attachment 141203
--> https://bugs.freedesktop.org/attachment.cgi?id=141203=edit
cs_dump_user_space.txt
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=107545
--- Comment #4 from Julien Isorce ---
Created attachment 141204
--> https://bugs.freedesktop.org/attachment.cgi?id=141204=edit
cs_dum_kernel_space.txt
Packet0 not allowed!.
--
You are receiving this mail because:
You are the assignee for
https://bugs.freedesktop.org/show_bug.cgi?id=107545
--- Comment #5 from Julien Isorce ---
Extract of the 2 attached cs dumps:
User space so before ioctl radeon_cs_ioctl:
0x0290
0x
0xC0016900
0x02A1
Kernel space so in radeon_cs_ioctl:
0x0290
0x000b
0x
0x02a1
Reviewed-by: Lyude Paul
On Fri, 2018-08-17 at 16:11 +0200, Hans Verkuil wrote:
> From: Hans Verkuil
>
> A big problem with DP CEC-Tunneling-over-AUX is that it is tricky
> to find adapters with a chipset that supports this AND where the
> manufacturer actually connected the HDMI CEC line to
On Mon, 2018-08-20 at 22:43 +0200, Hans Verkuil wrote:
> On 08/20/2018 08:59 PM, Lyude Paul wrote:
> > Reviewed-by: Lyude Paul
> >
> > We really need to add support for using this into the MST helpers. A good
> > way to
> > test this would probably be to hook up an aux device to the DP AUX
Currently, vkms needs VBlank to work well. This patch adds another
operation model that make vkms works without VBlank support.
Signed-off-by: Rodrigo Siqueira
---
drivers/gpu/drm/vkms/vkms_crtc.c | 10 ++
drivers/gpu/drm/vkms/vkms_drv.c | 12 ++--
On 08/20/2018 08:51 PM, Lyude Paul wrote:
> On Fri, 2018-08-17 at 16:11 +0200, Hans Verkuil wrote:
>> From: Hans Verkuil
>>
>> If aux->transfer == NULL, then just return without doing
>> anything. In that case the function is likely called for
>> a non-(e)DP connector.
>>
>> This never happened
On Mon, 2018-08-20 at 22:47 +0200, Hans Verkuil wrote:
> On 08/20/2018 08:51 PM, Lyude Paul wrote:
> > On Fri, 2018-08-17 at 16:11 +0200, Hans Verkuil wrote:
> > > From: Hans Verkuil
> > >
> > > If aux->transfer == NULL, then just return without doing
> > > anything. In that case the function is
On 08/20/2018 08:59 PM, Lyude Paul wrote:
> Reviewed-by: Lyude Paul
>
> We really need to add support for using this into the MST helpers. A good way
> to
> test this would probably be to hook up an aux device to the DP AUX adapters we
> create for each MST topology
If you are interested, I
From: Jacopo Mondi
DU channels not equipped with a DPLL use an SoC internal (provided by
the CPG) or external clock source combined with a DU internal divider to
generate the desired output dot clock frequency.
The current clock selection procedure does not fully exploit the ability
of external
Looks good to me based on my limited understanding. Thomas/Sinclair can
could you please review and then we can include this in drm-fixes.
Thanks,
Deepak
>
> arg.version is indirectly controlled by user-space, hence leading to
> a potential exploitation of the Spectre variant 1 vulnerability.
>
Hi Jacopo,
On Tuesday, 21 August 2018 00:49:41 EEST Laurent Pinchart wrote:
> From: Jacopo Mondi
>
> DU channels not equipped with a DPLL use an SoC internal (provided by
> the CPG) or external clock source combined with a DU internal divider to
> generate the desired output dot clock
Hi Jacopo,
Thank you for the patch.
On Monday, 20 August 2018 18:26:17 EEST Jacopo Mondi wrote:
> From: Jacopo Mondi
>
> DU channels not equipped with a DPLL use an internal (aka SoC provided) or
I'd say "SoC internal (provided by the CPG)"
> external clock source combined with an internal
Hi, thanks for the patch. Perhaps can get rid of vmw_kms_resume
and vmw_kms_suspend, otherwise looks good to me.
>
> convert drm_atomic_helper_suspend/resume() to use
> drm_mode_config_helper_suspend/resume().
>
> suspend_state can be removed from vmw_private as
> it will not be used anymore.
>
https://bugs.freedesktop.org/show_bug.cgi?id=107261
--- Comment #3 from Ian ---
Huh, I've discovered that I can only reproduce this on Wayland. Are you getting
these messages on X.org at all?
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=107623
--- Comment #3 from jian-h...@endlessm.com ---
Created attachment 141207
--> https://bugs.freedesktop.org/attachment.cgi?id=141207=edit
dmesg of boot into multi-user.target
If I boot system into "multi-user.target", then "systemctl suspend"
https://bugs.freedesktop.org/show_bug.cgi?id=107635
Bug ID: 107635
Summary: Internal display always be blank in mirror, extended
and built-in only display mode
Product: DRI
Version: unspecified
Hardware: x86-64 (AMD64)
https://bugs.freedesktop.org/show_bug.cgi?id=107581
--- Comment #7 from Timothy Arceri ---
(In reply to Benjamin Hodgetts from comment #6)
> I haven't tried force_glsl_extensions_warn, but
> MESA_GL_VERSION_OVERRIDE=4.5COMPAT doesn't help. It worked on older versions
> of the game, but has no
2018년 08월 20일 18:00에 Andrzej Hajda 이(가) 쓴 글:
> On 17.08.2018 03:56, Inki Dae wrote:
>>
>> 2018년 08월 13일 20:17에 Andrzej Hajda 이(가) 쓴 글:
>>> On 07.08.2018 10:53, Inki Dae wrote:
2018년 07월 26일 00:46에 Andrzej Hajda 이(가) 쓴 글:
> From: Maciej Purski
>
> The current implementation
Add binary firmware for Cadence MHDP8546 DP bridge.
Release version: 1.2.12
Signed-off-by: Damian Kos
---
LICENCE.cadence | 63 +++
WHENCE | 9 +++
cadence/mhdp8546.bin | Bin 0 -> 131072 bytes
3 files changed, 72 insertions(+)
Host1x is getting attached to an implicit IOMMU DMA domain if
CONFIG_ARM_DMA_USE_IOMMU=y. Since Host1x driver manages IOMMU by
itself, Host1x device must be detached from the implicit domain using
arch-specific IOMMU-API. Note that this works only for arm32 and not
for arm64, which will remain
All Tegra DRM devices are getting attached to an implicit IOMMU DMA
domain if CONFIG_ARM_DMA_USE_IOMMU=y. Since Tegra DRM driver manages IOMMU
by itself, the devices must be detached from the implicit domain using
arch-specific IOMMU-API. Note that this works only for arm32 and not for
arm64,
于 2018年8月20日 GMT+08:00 下午7:52:44, Maxime Ripard 写到:
>Hi!
>
>On Wed, Aug 15, 2018 at 08:07:45PM +0800, Icenowy Zheng wrote:
>> The glue in sun4i-drm of dw-hdmi currently doesn't set the clocks of
>> dw-hdmi exclusively, which will lead the display fails to initialize
>in
>> some situations.
>
This patch adds the v1.2.12 binary firmware for Cadence MHDP8546 DP bridge.
Damian Kos (1):
linux-firmware: add firmware for mhdp8546
LICENCE.cadence | 63 +++
WHENCE | 9 +++
cadence/mhdp8546.bin | Bin 0 -> 131072 bytes
3
Host1x is getting attached to an implicit IOMMU DMA domain if
CONFIG_ARM_DMA_USE_IOMMU=y. Since Host1x driver manages IOMMU by
itself, Host1x device must be detached from the implicit domain using
arch-specific IOMMU-API. Note that this works only for arm32 and not
for arm64, which will remain
Instead of determining the connector type from the type of the display's
omap_dss_device and passing it to the omap_connector_init() function,
move the type determination code to omap_connector.c and remove the type
argument to the connector init function. This moves code to a more
natural
Hi Tomi,
On Monday, 13 August 2018 13:50:18 EEST Tomi Valkeinen wrote:
> On 06/08/18 23:36, Laurent Pinchart wrote:
> > The two functions implement the .set_timings() and .check_timings()
> > operations. Rename them to hdmi_disply_set_timings() and
> > hdmi_display_check_timings() respectively to
Both the .check_timings() and .set_timings() handlers call
tfp410_fix_timings() to fix the timing's flags. As .check_timings() is
always called before .set_timings(), there's no need to fix the flags
twice. Remove the tfp410_fix_timings() call from .set_timings().
Signed-off-by: Laurent Pinchart
Instead of call the dispc timings check function dispc_mgr_timings_ok()
from the internal encoders .check_timings() operation, expose it through
the dispc ops (after renaming it to check_timings) and call it directly
from omapdrm. This allows removal of now empty omap_dss_device
.check_timings()
The fbdev git tree referenced in the MAINTAINERS file doesn't exist
anymore. Update the location to point to the new git tree.
Signed-off-by: Laurent Pinchart
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index
The .set_timings() operations of the omap_dss_device instances don't
need to modify the passed timings. Make the pointer const.
Signed-off-by: Laurent Pinchart
Reviewed-by: Sebastian Reichel
---
drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c | 2 +-
The drm_connector implementation requires access to the omap_dss_device
corresponding to the display, which is passed to its initialization
function and stored internally. Refactoring of the timings operations
will require access to the output omap_dss_device. To prepare for that,
pass it to the
Hi Ulrich,
Thank you for the patch.
On Tuesday, 14 August 2018 16:49:59 EEST Ulrich Hecht wrote:
> From: Koji Matsuoka
>
> This patch adds the option to specify a maximal clock and a minimal vertical
> refresh rate.
What is this needed for ?
> Signed-off-by: Koji Matsuoka
> [uli: renamed
Hi Ulrich,
Thank you for the patch.
On Tuesday, 14 August 2018 16:49:56 EEST Ulrich Hecht wrote:
> Add support for the R-Car D3 (R8A77995) SoC to the R-Car DU driver.
>
> Based on patch by Koji Matsuoka .
>
> Signed-off-by: Ulrich Hecht
> ---
> drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 17
https://bugs.freedesktop.org/show_bug.cgi?id=107261
--- Comment #2 from Ian ---
I'm seeing a very similar dmesg trace with a 2400G on kernel
4.18.1-arch1-1-ARCH: https://pastebin.com/raw/7CAXdXkD
--
You are receiving this mail because:
You are the assignee for the
Hi Jacopo,
Thank you for the patch.
On Monday, 30 July 2018 20:20:14 EEST Jacopo Mondi wrote:
> DU channels not equipped with a DPLL use an internal (aka SoC provided) or
> external clock source combined with an internal divider to generate the
> desired output dot clock frequency.
>
> The
https://bugs.freedesktop.org/show_bug.cgi?id=107169
Timothy Arceri changed:
What|Removed |Added
Assignee|mesa-dev@lists.freedesktop. |dri-devel@lists.freedesktop
Hi Jacopo,
Thank you for the patch.
On Monday, 30 July 2018 20:20:13 EEST Jacopo Mondi wrote:
> Rename the 'value' variable, only used to for writing to DMSR register to a
> more precise 'dmsr' name.
>
> Signed-off-by: Laurent Pinchart
> Signed-off-by: Jacopo Mondi
I think this simple change
On Fri, Aug 17, 2018 at 06:38:16PM +0800, Koenig, Christian wrote:
> Am 17.08.2018 um 12:08 schrieb Huang Rui:
> > I continue to work for bulk moving that based on the proposal by Christian.
> >
> > Background:
> > amdgpu driver will move all PD/PT and PerVM BOs into idle list. Then move
> > all
Hi Tomi,
On Monday, 13 August 2018 14:12:44 EEST Tomi Valkeinen wrote:
> On 06/08/18 23:36, Laurent Pinchart wrote:
> > The series is based on top of the previously submitted "[PATCH v2 00/21]
> > omapdrm: Rework the HPD-related operations" patch series. For convenience
> > I've pushed it to my
Hi Ulrich,
Thank you for the patch.
On Tuesday, 14 August 2018 16:50:01 EEST Ulrich Hecht wrote:
> From: Koji Matsuoka
>
> Signed-off-by: Koji Matsuoka
> Signed-off-by: Takeshi Kihara
> Signed-off-by: Ulrich Hecht
> ---
> arch/arm64/boot/dts/renesas/r8a77995-draak.dts | 8 +---
> 1
-Original Message-
From: dri-devel On Behalf Of Andrey
Grodzovsky
Sent: Friday, August 17, 2018 11:16 PM
To: dri-devel@lists.freedesktop.org
Cc: Koenig, Christian ; amd-...@lists.freedesktop.org
Subject: [PATCH] drm/scheduler: Add stopped flag to drm_sched_entity
The flag will prevent
Hi Ulrich,
Thank you for the patch.
On Tuesday, 14 August 2018 16:49:58 EEST Ulrich Hecht wrote:
> In R-Car D3 and E3, the DU dot clock can be sourced from the LVDS PLL.
> This patch enables that PLL if present.
>
> Based on patch by Koji Matsuoka .
>
> Signed-off-by: Ulrich Hecht
> ---
>
On 14.08.2018 12:26, Heiko Stuebner wrote:
> From: Nickey Yang
>
> Add the ROCKCHIP DSI controller driver that uses the Synopsys DesignWare
> MIPI DSI host controller bridge and remove the old separate one.
>
> changes:
>
> v2:
>add err_pllref, remove unnecessary encoder.enable & disable
>
https://bugs.freedesktop.org/show_bug.cgi?id=107581
Timothy Arceri changed:
What|Removed |Added
Status|NEW |NEEDINFO
--- Comment #5 from Timothy
https://bugs.freedesktop.org/show_bug.cgi?id=105251
--- Comment #17 from CheatCodesOfLife ---
(In reply to Andrey Grodzovsky from comment #16)
> Hi everyone, I've tried with latest kernel and latest VEGA10 firmware and
> wasn't able to reproduce this problem.
>
> From the logs it seems all of
Hi Tomi,
On Monday, 20 August 2018 14:24:23 EEST Tomi Valkeinen wrote:
> On 19/08/18 13:53, Laurent Pinchart wrote:
> > On Monday, 13 August 2018 14:12:44 EEST Tomi Valkeinen wrote:
> >> On 06/08/18 23:36, Laurent Pinchart wrote:
> >>> The series is based on top of the previously submitted
https://bugs.freedesktop.org/show_bug.cgi?id=91880
--- Comment #209 from Sandeep ---
Try removing the amdgpu.dc=1 kernel parameter. Might be causing problems.
If not, then it's a bug in the driver.
--
You are receiving this mail because:
You are the assignee for the
Tiling modifier can't be applied to overlay planes because all tile
modifiers are filtered out.
Fixes: e90124cb46bdb ("drm/tegra: plane: Support format modifiers")
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/tegra/plane.c | 16 ++--
1 file changed, 10 insertions(+), 6
On 07.08.2018 16:07, Dmitry Osipenko wrote:
> Currently gathers of a hung job are getting NOP'ed and a restarted CDMA
> executes the NOP'ed gathers. There shouldn't be a reason to not restart
> CDMA execution starting with a next job, avoiding the unnecessary churning
> with gathers NOP'ing.
>
>
https://bugzilla.kernel.org/show_bug.cgi?id=200605
--- Comment #4 from ric...@gmx.at ---
In the meantime I'm at 4.18.1 and the problem never happened since then.
--
You are receiving this mail because:
You are watching the assignee of the bug.
___
https://bugs.freedesktop.org/show_bug.cgi?id=91880
--- Comment #210 from emilio.more...@gmail.com ---
(In reply to Sandeep from comment #209)
> Created attachment 141193 [details]
> attachment-13440-0.html
>
> Try removing the amdgpu.dc=1 kernel parameter. Might be causing problems.
> If not,
On Fri, Aug 17, 2018 at 03:15:52PM -0400, Mikulas Patocka wrote:
> There's console font corruption when using the mach64 driver in 24bpp
> mode.
>
> In 24bpp mode, the mach64 accelerator is set up for 8-bpp mode (with
> horizontal width and stride multiplied by 3). In this mode, the
> accelerator
Instead of calling the .set_timings() operation recursively from the
display device backwards, iterate over the devices manually in the DRM
encoder code. This moves the complexity to a single central location and
simplifies the logic in omap_dss_device drivers.
Signed-off-by: Laurent Pinchart
The omap_dss_device .set_timings() operation for external encoders
stores the video mode in the device data structure. That mode is then
never used again. Drop it.
Signed-off-by: Laurent Pinchart
Reviewed-by: Sebastian Reichel
---
drivers/gpu/drm/omapdrm/displays/encoder-opa362.c| 5 -
The .check_timings() operation is called recursively from the display
device back to the output device. Most components just forward the
operation to the previous component in the chain, resulting in lots of
duplicated pass-through functions. To avoid that, iterate over the
components manually.
The DSI encoder modifies the passed videomode to take the requirements
of the internal DISPC-DSI bus into account in the .enable_video_output()
operation. This should be performed in the .check_timings() operation
instead. There is however no .check_timings() operation as the DSI
encoder uses a
The video mode is aleady fixed up by the .check_timings() operation,
there's no need to repeat that when enabling the DPI output.
Signed-off-by: Laurent Pinchart
Reviewed-by: Sebastian Reichel
---
drivers/gpu/drm/omapdrm/dss/dpi.c | 12 +---
1 file changed, 1 insertion(+), 11
Constify many pointers to struct videomode, as well as pointers to
container structures, to ensure the video mode isn't modified after
the .check_timings() operation.
Signed-off-by: Laurent Pinchart
Reviewed-by: Sebastian Reichel
---
drivers/gpu/drm/omapdrm/dss/hdmi.h | 8
The bus flags stored in omap_dss_device instances are used to fixup the
video mode before setting it, to honour constraints that can't be
expressed through drm_display_mode. The fixup occurs in the CRTC mode
set operation and the resulting video mode is stored internally in the
CRTC. It is then
The VENC encoder modifies the requested video mode to match the NTSC or
PAL timings (or reject the video mode completely) in the .set_timings()
operation. This should be performed in the .check_timings() operation
instead. Move the fixup.
Signed-off-by: Laurent Pinchart
Reviewed-by: Sebastian
On 16.08.2018 20:54, Sean Paul wrote:
> From: Sean Paul
>
> DRM_MIPI_DSI is included via both "select" and "depends on", this is
> trouble waiting to happen since this will result in different behavior
> depending on which is used.
As Thierry said 'select' is for DSI controllers, 'depends on'
https://bugs.freedesktop.org/show_bug.cgi?id=107623
--- Comment #1 from jian-h...@endlessm.com ---
Created attachment 141197
--> https://bugs.freedesktop.org/attachment.cgi?id=141197=edit
The resume process video
--
You are receiving this mail because:
You are the assignee for the
https://bugzilla.kernel.org/show_bug.cgi?id=199425
--- Comment #18 from Johannes Hirte (johannes.hi...@datenkhaos.de) ---
[183309.195913]
==
[183309.195937] BUG: KASAN: use-after-free in
Hi Ulrich,
Thank you for the patch.
On Tuesday, 14 August 2018 16:50:00 EEST Ulrich Hecht wrote:
> From: Koji Matsuoka
>
> This patch corrects that the extal clock used with the fixed value
> is acquired from the device tree.
> Also, it is possible to select extal or dotclkin for R8A77995 and
On 14.08.2018 12:26, Heiko Stuebner wrote:
> With the regular means of adding the dsi-component in probe it creates
> a race condition with the panel probing, as the panel device only gets
> created after the dsi-bus got created.
>
> When the panel-driver is build as a module it currently fails
On 17.08.2018 03:56, Inki Dae wrote:
>
> 2018년 08월 13일 20:17에 Andrzej Hajda 이(가) 쓴 글:
>> On 07.08.2018 10:53, Inki Dae wrote:
>>> 2018년 07월 26일 00:46에 Andrzej Hajda 이(가) 쓴 글:
From: Maciej Purski
The current implementation assumes that the only possible peripheral
device for
Hi Ulrich,
Thank you for the patch.
On Tuesday, 14 August 2018 16:49:57 EEST Ulrich Hecht wrote:
> From: Koji Matsuoka
>
> This patch adds D3 definition for DU and fixes digital RGB routing.
>
> Signed-off-by: Koji Matsuoka
> ---
> drivers/gpu/drm/rcar-du/rcar_du_drv.c | 3 ++-
>
https://bugs.freedesktop.org/show_bug.cgi?id=107572
--- Comment #15 from Andrew Cook ---
Unigine locked up right at the end of the benchmark, but it also prints a
vmfault
kernel: gmc_v8_0_process_interrupt: 71 callbacks suppressed
kernel: amdgpu :0c:00.0: GPU fault detected: 146 0x0048080c
https://bugs.freedesktop.org/show_bug.cgi?id=107581
--- Comment #6 from Benjamin Hodgetts ---
I haven't tried force_glsl_extensions_warn, but
MESA_GL_VERSION_OVERRIDE=4.5COMPAT doesn't help. It worked on older versions of
the game, but has no positive effect with the current version of the game
https://bugs.freedesktop.org/show_bug.cgi?id=107612
--- Comment #1 from CheatCodesOfLife ---
Created attachment 141192
--> https://bugs.freedesktop.org/attachment.cgi?id=141192=edit
glxinfo |greep OpenGL
forgot to attach this last night.
--
You are receiving this mail because:
You are the
Hi Ulrich,
Thank you for the patch.
On Tuesday, 14 August 2018 16:50:04 EEST Ulrich Hecht wrote:
> Adds LVDS decoder, HDMI encoder and connector for Draak boards.
>
> Signed-off-by: Ulrich Hecht
> Reviewed-by: Laurent Pinchart
I'm afraid I'll have to revoke that, as it applied to the patch
On Fri, Aug 17, 2018 at 06:33:04PM +0100, Ayan Kumar Halder wrote:
> For multi-planar formats, while calculating offsets in planes with index
> greater than 0
> (ie second plane, third plane, etc), one needs to divide (src_x * cpp) with
> horizontal
> chroma subsampling factor and (src_y *
On 19/08/18 13:53, Laurent Pinchart wrote:
> Hi Tomi,
>
> On Monday, 13 August 2018 14:12:44 EEST Tomi Valkeinen wrote:
>> On 06/08/18 23:36, Laurent Pinchart wrote:
>>> The series is based on top of the previously submitted "[PATCH v2 00/21]
>>> omapdrm: Rework the HPD-related operations" patch
The two functions implement the .set_timings() and .check_timings()
operations. Rename them to hdmi_disply_set_timings() and
hdmi_display_check_timings() respectively to match the operations names
and make searching the source code easier.
Signed-off-by: Laurent Pinchart
Reviewed-by: Sebastian
Source components in the display pipeline need to configure their output
signals polarities and clock driving edge based on the requirements of
the sink component.
Those requirements are currently shared across the whole pipeline in the
flags of a videomode structure, instead of being local to
1 - 100 of 131 matches
Mail list logo
