https://bugs.freedesktop.org/show_bug.cgi?id=108937
--- Comment #6 from Christopher Snowhill ---
I don't control the application, and it's already the latest version currently
available. It's already a feature implemented by a patch that hasn't been
accepted by upstream since it was submitted
On 04.12.2018 20:02, Ville Syrjälä wrote:
> On Tue, Dec 04, 2018 at 08:03:53AM +0100, Andrzej Hajda wrote:
>> On 03.12.2018 22:48, Ville Syrjälä wrote:
>>> On Thu, Nov 29, 2018 at 09:46:16AM +0100, Andrzej Hajda wrote:
Quite late, hopefully not too late.
On 21.11.2018 12:51,
https://bugs.freedesktop.org/show_bug.cgi?id=108937
Christian König changed:
What|Removed |Added
Resolution|NOTOURBUG |DUPLICATE
--- Comment #5 from
https://bugs.freedesktop.org/show_bug.cgi?id=104597
Christian König changed:
What|Removed |Added
CC||kod...@gmail.com
--- Comment #18
https://bugs.freedesktop.org/show_bug.cgi?id=108937
Christian König changed:
What|Removed |Added
Resolution|--- |NOTOURBUG
Status|NEW
Hi Ville,
On Tuesday, 4 December 2018 21:13:20 EET Ville Syrjälä wrote:
> On Tue, Dec 04, 2018 at 08:46:53AM +0100, Andrzej Hajda wrote:
> > On 03.12.2018 22:38, Ville Syrjälä wrote:
> >> On Thu, Nov 29, 2018 at 10:08:07AM +0100, Andrzej Hajda wrote:
> >>> On 21.11.2018 19:19, Laurent Pinchart
From: Jérôme Glisse
CPU page table update can happens for many reasons, not only as a result
of a syscall (munmap(), mprotect(), mremap(), madvise(), ...) but also
as a result of kernel activities (memory compression, reclaim, migration,
...).
Users of mmu notifier API track changes to the CPU
From: Jérôme Glisse
To avoid having to change many callback definition everytime we want
to add a parameter use a structure to group all parameters for the
mmu_notifier invalidate_range_start/end callback. No functional changes
with this patch.
Signed-off-by: Jérôme Glisse
Cc: Andrew Morton
From: Jérôme Glisse
To avoid having to change many call sites everytime we want to add a
parameter use a structure to group all parameters for the mmu_notifier
invalidate_range_start/end cakks. No functional changes with this
patch.
Changes since v1:
- introduce mmu_notifier_range_init() as
https://bugs.freedesktop.org/show_bug.cgi?id=108771
--- Comment #4 from John ---
Created attachment 142730
--> https://bugs.freedesktop.org/attachment.cgi?id=142730=edit
dolphin save for the last story
This includes a save right before the crash (for the US version of the game).
Start the
https://bugs.freedesktop.org/show_bug.cgi?id=108771
John changed:
What|Removed |Added
Summary|[amdgpu]] *ERROR* ring gfx |[amdgpu] *ERROR* ring gfx
https://bugs.freedesktop.org/show_bug.cgi?id=108771
--- Comment #3 from John ---
Here's a trace that crashes my system:
https://mega.nz/#!plBngY4B!zQ8P24a84PsHWym-5hAGUMjiMKv1CKQB7EFnlPorrx4
I don't know why the trace is all black and does not display anything, but the
end result is the same,
+ others
Hi,
On Sun, Aug 05, 2018 at 01:48:07PM +0100, Marc Zyngier wrote:
> Leaving the DRM driver enabled on reboot or kexec has the annoying
> effect of leaving the display generating transactions whilst the
> IOMMU has been shut down.
>
> In turn, the IOMMU driver (which shares its
https://bugzilla.kernel.org/show_bug.cgi?id=105111
fin4...@hotmail.com changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugzilla.kernel.org/show_bug.cgi?id=192161
fin4...@hotmail.com changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugzilla.kernel.org/show_bug.cgi?id=178281
fin4...@hotmail.com changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugzilla.kernel.org/show_bug.cgi?id=193651
fin4...@hotmail.com changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugzilla.kernel.org/show_bug.cgi?id=201439
fin4...@hotmail.com changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
Hi,
On Tue, Dec 4, 2018 at 3:54 PM Jeykumar Sankaran wrote:
>
> DPU is short for the Display Processing Unit. It is the display
> controller on Qualcomm SDM845 chips.
>
> This change adds MDSS and DSI nodes to enable display on the
> target device.
>
> Changes in v2:
> - Beefed up
On Thu, Oct 25, 2018 at 05:09:29PM +0200, Alex Gonzalez wrote:
> Alex Gonzalez (4):
> drm/panel: simple: Add AUO G101EVN010 panel support
> ARM: dts: ccimx6ulsbcpro: Enable AUO G101EVN010 lcdif panel
> ARM: imx_v6_v7_defconfig: Select TOUCHSCREEN_GOODIX
> ARM: dts: ccimx6ulsbcpro: Add
https://bugs.freedesktop.org/show_bug.cgi?id=108937
--- Comment #3 from Christopher Snowhill ---
Yes, that dodges the issue. Should I be enabling this setting system-wide,
possibly for other applications? I recall Totem having the same issue with
H.264 hardware decoding.
--
You are receiving
DPU is short for the Display Processing Unit. It is the display
controller on Qualcomm SDM845 chips.
This change adds MDSS and DSI nodes to enable display on the
target device.
Changes in v2:
- Beefed up commit message
- Use SoC specific compatibles for mdss and dpu (Rob H)
On 2018-12-03 06:47, Sean Paul wrote:
On Tue, Nov 27, 2018 at 02:28:30PM -0800, Jeykumar Sankaran wrote:
Add display port support in DPU by creating hooks
for DP encoder enumeration and encoder mode
initialization.
This change is based on the SDM845 Display port
driver changes[1].
changes in
On Mon, 3 Dec 2018 15:18:17 -0500 jgli...@redhat.com wrote:
> CPU page table update can happens for many reasons, not only as a result
> of a syscall (munmap(), mprotect(), mremap(), madvise(), ...) but also
> as a result of kernel activities (memory compression, reclaim, migration,
> ...).
>
>
https://bugs.freedesktop.org/show_bug.cgi?id=106175
--- Comment #74 from Brandon Wright ---
Is anyone from the AMD driver team still following this?
Could we please have a review of Nicholas's patch and try to get it into 4.20?
It's not that disruptive code-wise, but it makes a big smoothness
https://bugzilla.kernel.org/show_bug.cgi?id=200695
Claude Heiland-Allen (cla...@mathr.co.uk) changed:
What|Removed |Added
Kernel Version|4.17.19, 4.18.5 through |4.17.19,
Add 'bi_tcxo' as ref clock for the DSI PHYs, it was previously
hardcoded in the PLL 'driver' for the 10nm PHY.
Signed-off-by: Matthias Kaehlcke
Reviewed-by: Douglas Anderson
Reviewed-by: Stephen Boyd
---
based on "[v4,1/3] arm64: dts: qcom: sdm845: Add dpu to sdm845 dts file"
Get the ref clock of the PHY from the device tree instead of
hardcoding its name and rate.
Signed-off-by: Matthias Kaehlcke
---
Changes in v4:
- always use parent rate in dsi_pll_28nm_clk_set_rate()
- pass name of VCO ref clock to pll_28nm_register() instead of
storing it in a struct field
-
Add 'xo_board' as ref clock for the DSI PHYs, it was previously
hardcoded in the PLL 'driver' for the 28nm PHY.
Signed-off-by: Matthias Kaehlcke
Reviewed-by: Douglas Anderson
Reviewed-by: Stephen Boyd
---
Changes in v4:
- added 'Reviewed-by: Stephen Boyd ' tag
Changes in v3:
- added
Allow the PHY drivers to get the ref clock from the DT.
Signed-off-by: Matthias Kaehlcke
Reviewed-by: Stephen Boyd
Reviewed-by: Douglas Anderson
---
Chnages in v4:
- added "Reviewed-by" tags from Stephen and Doug
Changes in v3:
- added note that the ref clock is only required for new DTS
The MSM DSI PHY drivers currently hardcode the name and the rate of
the PHY ref clock. Get the ref clock from the device tree instead.
Note: testing of this series was limited to SDM845 and the 10nm PHY
Major changes in v4:
- always use parent rate for 28nm and 28nm 8960 PHYs
Major changes in
Get the ref clock of the PHY from the device tree instead of
hardcoding its name and rate.
Note: This change could break old out-of-tree DTS files that
use the 10nm PHY
Signed-off-by: Matthias Kaehlcke
Reviewed-by: Douglas Anderson
---
Changes in v4:
- none
Changes in v3:
- fixed check for
Get the ref clock of the PHY from the device tree instead of
hardcoding its name and rate.
Note: This change could break old out-of-tree DTS files that
use the 14nm PHY.
Signed-off-by: Matthias Kaehlcke
Reviewed-by: Douglas Anderson
---
Changes in v4:
- none
Changes in v3:
- fixed check for
Get the ref clock of the PHY from the device tree instead of
hardcoding its name and rate.
Signed-off-by: Matthias Kaehlcke
---
Changes in v4:
- always use parent rate in dsi_pll_28nm_clk_set_rate() and
dsi_pll_28nm_clk_recalc_rate()
- pass name of VCO ref clock to pll_28nm_register() instead
Add 'xo_board' as ref clock for the DSI PHY, it was previously
hardcoded in the PLL 'driver' for the 28nm 8960 PHY.
Signed-off-by: Matthias Kaehlcke
Reviewed-by: Stephen Boyd
---
Changes in v4:
- added 'Reviewed-by: Stephen Boyd ' tag
Changes in v3:
- patch added to the series
---
On Sat, Dec 1, 2018 at 10:54 AM Rob Clark wrote:
>
> This solves a problem we see with drm/msm, caused by getting
> iommu_dma_ops while we attach our own domain and manage it directly at
> the iommu API level:
>
> [0038] user address but active_mm is swapper
> Internal error:
https://bugs.freedesktop.org/show_bug.cgi?id=108710
--- Comment #12 from mikhail.v.gavri...@gmail.com ---
Created attachment 142726
--> https://bugs.freedesktop.org/attachment.cgi?id=142726=edit
4.20 g94f371cb7394 + mesa 18.3.0-rc5
--
You are receiving this mail because:
You are the assignee
https://bugs.freedesktop.org/show_bug.cgi?id=108710
--- Comment #11 from mikhail.v.gavri...@gmail.com ---
I am was able reproduce this issue again with mesa 18.3.0-rc5
--
You are receiving this mail because:
You are the assignee for the bug.___
https://bugs.freedesktop.org/show_bug.cgi?id=108937
--- Comment #2 from Christoph Haag ---
Try setting allow_rgb10_configs to false for chromium in drirc or starting
chromium with the env var
allow_rgb10_configs=false chromium
see also bug #104597
--
You are receiving this mail because:
You
On Mon, Dec 03, 2018 at 03:50:48PM -0800, Brendan Higgins wrote:
> On Thu, Nov 29, 2018 at 7:44 PM Luis Chamberlain wrote:
> >
> > On Wed, Nov 28, 2018 at 11:36:28AM -0800, Brendan Higgins wrote:
> > > The ultimate goal is to create minimal isolated test binaries; in the
> > > meantime we are
On Mon, Dec 03, 2018 at 03:48:15PM -0800, Brendan Higgins wrote:
> On Thu, Nov 29, 2018 at 5:54 AM Kieran Bingham
> wrote:
> >
> > Hi Brendan,
> >
> > Thanks again for this series!
> >
> > On 28/11/2018 19:36, Brendan Higgins wrote:
> > > The ultimate goal is to create minimal isolated test
On Tue, Dec 4, 2018 at 11:56 AM Robert Foss wrote:
>
> If dma_fence_wait fails to wait for a supplied in-fence in
> msm_ioctl_gem_submit, make sure we release that in-fence.
>
> Also remove this dma_fence_put() from the 'out' label.
>
> Signed-off-by: Robert Foss
> Reviewed-by: Chris Wilson
>
On Tue, Dec 4, 2018 at 1:04 PM Douglas Anderson wrote:
>
> When trying to get the display up on my sdm845 board I noticed that
> the display wouldn't probe if I had the dsi1 node marked as "disabled"
> even though my board doesn't use dsi1. It looks like the msm code
> adds all nodes to its list
On Tue, 13 Nov 2018 13:42:05 +0100, Heiko Stuebner wrote:
> From: Heiko Stuebner
>
> This is a panel handled through the generic lvds-panel binding,
> so only needs its additional compatible specified.
>
> Signed-off-by: Heiko Stuebner
> ---
>
Hi Geert,
On Tuesday, 4 December 2018 21:45:10 EET Geert Uytterhoeven wrote:
> On Tue, Dec 4, 2018 at 7:51 PM Laurent Pinchart wrote:
> > On Tuesday, 4 December 2018 20:42:53 EET Geert Uytterhoeven wrote:
> > > On Tue, Dec 4, 2018 at 7:12 PM Laurent Pinchart wrote:
> > > > On Tuesday, 4 December
https://bugs.freedesktop.org/show_bug.cgi?id=107946
Alex Deucher changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://bugs.freedesktop.org/show_bug.cgi?id=107946
--- Comment #7 from Dave Johnson ---
This has been resolved for me in the current 4.19 stable build. Thanks!
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel
Hi Laurent,
On Tue, Dec 4, 2018 at 7:51 PM Laurent Pinchart
wrote:
> On Tuesday, 4 December 2018 20:42:53 EET Geert Uytterhoeven wrote:
> > On Tue, Dec 4, 2018 at 7:12 PM Laurent Pinchart wrote:
> > > On Tuesday, 4 December 2018 19:30:25 EET Geert Uytterhoeven wrote:
> > >> On Tue, Dec 4, 2018
https://bugzilla.kernel.org/show_bug.cgi?id=201067
--- Comment #12 from Dave Johnson (d...@locochino.com) ---
This is fixed for me in 4.19-stable
--
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing
On Tue, Dec 04, 2018 at 11:37:05PM +0530, Ramalingam C wrote:
> HDCP1.4 is enabled and validated only on GEN9+ platforms.
>
> Signed-off-by: Ramalingam C
> Reviewed-by: Sean Paul
> ---
> drivers/gpu/drm/i915/intel_hdcp.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git
On Tue, Dec 04, 2018 at 08:46:53AM +0100, Andrzej Hajda wrote:
> On 03.12.2018 22:38, Ville Syrjälä wrote:
> > On Thu, Nov 29, 2018 at 10:08:07AM +0100, Andrzej Hajda wrote:
> >> On 21.11.2018 19:19, Laurent Pinchart wrote:
> >>> Hi Ville,
> >>>
> >>> Thank you for the patch.
> >>>
> >>> On
On Tue, Dec 04, 2018 at 08:03:53AM +0100, Andrzej Hajda wrote:
> On 03.12.2018 22:48, Ville Syrjälä wrote:
> > On Thu, Nov 29, 2018 at 09:46:16AM +0100, Andrzej Hajda wrote:
> >> Quite late, hopefully not too late.
> >>
> >>
> >> On 21.11.2018 12:51, Ville Syrjälä wrote:
> >>> On Wed, Nov 21, 2018
Hi Geert,
On Tuesday, 4 December 2018 20:42:53 EET Geert Uytterhoeven wrote:
> On Tue, Dec 4, 2018 at 7:12 PM Laurent Pinchart wrote:
> > On Tuesday, 4 December 2018 19:30:25 EET Geert Uytterhoeven wrote:
> >> On Tue, Dec 4, 2018 at 5:36 PM Laurent Pinchart wrote:
> >>> Implement a .mode_valid()
Hi Laurent,
On Tue, Dec 4, 2018 at 7:12 PM Laurent Pinchart
wrote:
> On Tuesday, 4 December 2018 19:30:25 EET Geert Uytterhoeven wrote:
> > On Tue, Dec 4, 2018 at 5:36 PM Laurent Pinchart wrote:
> > > Implement a .mode_valid() handler in the R-Car glue layer to reject
> > > modes with an
https://bugs.freedesktop.org/show_bug.cgi?id=108940
Alex Deucher changed:
What|Removed |Added
Attachment #142710|text/x-log |text/plain
mime type|
HDCP1.4 is enabled and validated only on GEN9+ platforms.
Signed-off-by: Ramalingam C
Reviewed-by: Sean Paul
---
drivers/gpu/drm/i915/intel_hdcp.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
b/drivers/gpu/drm/i915/intel_hdcp.c
index
Hi Geert,
On Tuesday, 4 December 2018 19:30:25 EET Geert Uytterhoeven wrote:
> On Tue, Dec 4, 2018 at 5:36 PM Laurent Pinchart wrote:
> > Implement a .mode_valid() handler in the R-Car glue layer to reject
> > modes with an unsupported clock frequency.
> >
> > Signed-off-by: Laurent Pinchart
> >
Couple of more HDCP1.4 fixes on
- Key load process for CFL
- Encryption status change time
- debug log addition
- active platform coverage
v1 and v2 went into old series https://patchwork.freedesktop.org/series/38978/
as v8 and v9, due to the same series title. Now changed the title.
Adding a debug log when the DP_AUX_NATIVE_REPLY_ACK is missing
for aksv write. This helps to locate the possible non responding
DP HDCP sinks.
v2:
Rewritten for readability [Sean Paul]
Signed-off-by: Ramalingam C
Reviewed-by: Sean Paul
---
drivers/gpu/drm/i915/intel_dp.c | 7 ++-
1 file
At enable/disable of the HDCP encryption, for encryption status change
we need minimum one frame duration. And we might program this bit any
point(start/End) in the previous frame.
With 20mSec, observed the timeout for change in encryption status.
Since this is not time critical operation and we
HDCP1.4 key load process varies between Intel platform to platform.
For Gen9 platforms except BXT and GLK, HDCP1.4 key is loaded using
the GT Driver Mailbox interface. So all GEN9_BC platforms will use
the GT Driver Mailbox interface for HDCP1.4 key load.
v2:
Using the IS_GEN9_BC for filtering
Hi,
On Mon, Dec 3, 2018 at 6:41 PM Jeykumar Sankaran wrote:
> >> + dsi1: dsi@ae96000 {
> >> + compatible = "qcom,mdss-dsi-ctrl";
> >> + reg = <0xae96000 0x400>;
> >> + reg-names =
When trying to get the display up on my sdm845 board I noticed that
the display wouldn't probe if I had the dsi1 node marked as "disabled"
even though my board doesn't use dsi1. It looks like the msm code
adds all nodes to its list of components even if they are disabled. I
believe this doesn't
(2018-11-22 16:49:47 +0200)
are available in the git repository at:
git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-2018-12-04
for you to fetch changes up to 4377d4e0d3d511986033ba7b4182d5a80b7f9ea2:
drm/i915: Update DRIVER_DATE to 20181204 (2018-12-04 19:26:17 +0200
On Mon, Dec 03, 2018 at 11:32:06AM +, Ayan Halder wrote:
> The list of modifiers to be supported for each plane has been dynamically
> generated
> from 'malidp_format_modifiers[]' and 'malidp_hw_regmap->features'.
>
> Changes from v1:-
> 1. Replaced DRM_ERROR() with DRM_DEBUG_KMS() in
On Mon, Dec 03, 2018 at 11:32:05AM +, Ayan Halder wrote:
> Considering the fact that some of the AFBC specific pixel formats are
> expressed
> in bits per pixel (ie bpp which is not byte aligned), the pitch (ie width *
> bpp)
> is not guaranteed to be aligned to burst size (ie 8 or 16
On Mon, Dec 03, 2018 at 11:32:04AM +, Ayan Halder wrote:
> Formats like DRM_FORMAT_VUY101010, DRM_FORMAT_YUV420_8BIT and
> DRM_FORMAT_YUV420_10BIT are expressed in bits per pixel as they have a non
> integer value of cpp (thus denoted as '0' in drm_format_info[]). Therefore,
> the calculation
On Mon, Dec 03, 2018 at 11:32:03AM +, Ayan Halder wrote:
> In malidp, the writeback pipeline does not support writing crtc output
> to a framebuffer with modifiers ie the memory writeback content is
> devoid of any compression or tiling, etc.
> So we have added a commit check in memory
On Mon, Dec 03, 2018 at 11:32:02AM +, Ayan Halder wrote:
> The newly supported AFBC YUV formats have the following rotation memory
> constraints (in DP550/DP650).
> 1. DRM_FORMAT_VUY888/DRM_FORMAT_VUY101010 :- It can rotate upto 8
> horizontal lines in the AFBC output buffer.
> 2.
On Mon, Dec 03, 2018 at 11:32:01AM +, Ayan Halder wrote:
> The constraints are as follows (for Mali-DP 500, 550, 650) :-
>
> 1. AFBC is not supported for the formats defined in
> malidp_hw_format_is_linear_only()
>
> 2. Some of the formats are supported only with AFBC modifiers. Thus we
https://bugs.freedesktop.org/show_bug.cgi?id=105113
--- Comment #11 from Jan Vesely ---
(In reply to Maciej S. Szmigiero from comment #10)
> (In reply to Jan Vesely from comment #9)
> > (In reply to Maciej S. Szmigiero from comment #8)
> > > Aren't program@execute@calls-struct and
On Sun, Nov 25, 2018 at 3:40 PM Laurent Pinchart
wrote:
> Add the backlight device for the LVDS1 output, in preparation for panel
> support.
>
> Signed-off-by: Laurent Pinchart
Reviewed-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's
On Tue, Dec 04, 2018 at 08:44:00AM -0800, Stephen Boyd wrote:
> Quoting Matthias Kaehlcke (2018-11-30 16:52:48)
> > Get the ref clock of the PHY from the device tree instead of
> > hardcoding its name and rate. Use default values if the ref
> > clock is not specified.
> >
> > Signed-off-by:
Hi Laurent,
On Tue, Dec 4, 2018 at 5:36 PM Laurent Pinchart
wrote:
> Implement a .mode_valid() handler in the R-Car glue layer to reject
> modes with an unsupported clock frequency.
>
> Signed-off-by: Laurent Pinchart
Thanks for your patch!
> --- a/drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c
> +++
On Tue, Dec 04, 2018 at 08:48:22AM -0800, Stephen Boyd wrote:
> Quoting Matthias Kaehlcke (2018-11-30 16:52:54)
> > Add 'xo_board' as ref clock for the DSI PHY, it was previously
> > hardcoded in the PLL 'driver' for the 28nm 8960 PHY.
>
> Why is driver in quotes?
It's not really a full fledged
Hi,
On Fri, Nov 30, 2018 at 4:53 PM Matthias Kaehlcke wrote:
>
> Allow the PHY drivers to get the ref clock from the DT.
>
> Signed-off-by: Matthias Kaehlcke
> ---
> Changes in V3:
> - added note that the ref clock is only required for new DTS
> files/entries
>
> Changes in v2:
> - add the
On Mon, Dec 03, 2018 at 11:32:00AM +, Ayan Halder wrote:
> We have added some new formats to be supported on DP500/DP550/DP650.
Make a bit more descriptive commit message here, please!
>
> Signed-off-by: Ayan Kumar Halder
>
> Depends on :- https://patchwork.kernel.org/patch/10460063/
Add support for the VXT VL050-8048NT-C01 800x480 panel to the
panel-simple driver.
This panel is used on some boards manufactured by TechNexion, such as
imx7d-pico.
Signed-off-by: Fabio Estevam
---
drivers/gpu/drm/panel/panel-simple.c | 27 +++
1 file changed, 27
The VXT VL050-8048NT-C01 is a TFT LCD panel with a 800x480 resolution
connected via 24 width parallel interface.
Signed-off-by: Fabio Estevam
---
.../devicetree/bindings/display/panel/vl050_8048nt_c01.txt | 12
1 file changed, 12 insertions(+)
create mode 100644
VXT Ltd is a manufacturer of projected capacitive touch panel
and display solutions: http://www.vxt.com.tw/
Signed-off-by: Fabio Estevam
---
Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
1 file changed, 1 insertion(+)
diff --git
On Mon, Dec 03, 2018 at 11:31:59AM +, Ayan Halder wrote:
> We need to define a common list of format modifiers supported by each of the
> Mali
> display processors. The difference between DP500 from DP550/650 is that DP500
> does not support block split mode (ie AFBC_FORMAT_MOD_SPLIT) and
If dma_fence_wait fails to wait for a supplied in-fence in
msm_ioctl_gem_submit, make sure we release that in-fence.
Also remove this dma_fence_put() from the 'out' label.
Signed-off-by: Robert Foss
Reviewed-by: Chris Wilson
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/msm/msm_gem_submit.c
Hi Simon,
Could you please consider taking this patch in your tree ? It's independent
from the rest of the series.
On Sunday, 25 November 2018 16:40:30 EET Laurent Pinchart wrote:
> Add the backlight device for the LVDS1 output, in preparation for panel
> support.
>
> Signed-off-by: Laurent
On Sun, Nov 04, 2018 at 08:54:26AM +, Shawn Guo wrote:
>On Thu, Oct 25, 2018 at 05:09:29PM +0200, Alex Gonzalez wrote:
>> Alex Gonzalez (4):
>> drm/panel: simple: Add AUO G101EVN010 panel support
>> ARM: dts: ccimx6ulsbcpro: Enable AUO G101EVN010 lcdif panel
>> ARM: imx_v6_v7_defconfig:
On Mon, Dec 03, 2018 at 11:31:58AM +, Ayan Halder wrote:
> Added the AFBC decoder registers for DP500 , DP550 and DP650.
> These registers control the processing of AFBC buffers. It controls various
> features like AFBC decoder enable, lossless transformation and block split
> as well as
https://bugs.freedesktop.org/show_bug.cgi?id=108359
--- Comment #1 from Jeremy Newton ---
This should have been fixed. Can you retest using a newer version?
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel
https://bugs.freedesktop.org/show_bug.cgi?id=97759
Jeremy Newton changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Implement a .mode_valid() handler in the R-Car glue layer to reject
modes with an unsupported clock frequency.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c | 15 +++
1 file changed, 15 insertions(+)
Changes since v1:
- Add a comment to explain where
https://bugs.freedesktop.org/show_bug.cgi?id=108883
--- Comment #1 from Jeremy Newton ---
Unfortunately, we don't support Vulkan on RHEL 6.
If you can't update the OS, you could try building our Vulkan driver from
source. Note that it's not tested on RHEL 6, so it might not work:
On Mon, Dec 03, 2018 at 11:31:56AM +, Ayan Halder wrote:
> We have added a new format ie DRM_FORMAT_XVYU2101010 which is supported
> by mali display driver.
>
> Signed-off-by: Ayan Kumar halder
Reviewed-by: Liviu Dudau
Best regards,
Liviu
> ---
> drivers/gpu/drm/drm_fourcc.c | 1 +
>
On Tue, Dec 04, 2018 at 10:51:42AM -0500, Bruce Wang wrote:
> On Mon, Dec 3, 2018 at 2:56 PM Sean Paul wrote:
> >
> > From: Sean Paul
> >
> > Since dpu_crtc subclasses crtc_state, we need a custom .reset hook in
> > order to allocate the right amount of memory to accommodate the
> > additional
On Tue, Dec 04, 2018 at 11:28:37AM +0530, Kishon Vijay Abraham I wrote:
> Hi Maxime,
>
> On 21/11/18 3:03 PM, Maxime Ripard wrote:
> > Hi Sakari,
> >
> > Thanks for your review.
> >
> > On Mon, Nov 19, 2018 at 03:43:57PM +0200, Sakari Ailus wrote:
> >>> +/*
> >>> + * Minimum D-PHY timings based
https://bugzilla.kernel.org/show_bug.cgi?id=201867
--- Comment #1 from david.kremer...@gmail.com ---
I must add that the symptom as well as the concerned hardware starts to be
pretty well documented.
The problem arises with
- recent nvidia mobile cards
- optimus technology built in
- intel
On Tue, Dec 04, 2018 at 03:22:12PM +0100, Paul Kocialkowski wrote:
> This is the final step to indicate to the core that our driver
> supports framebuffer modifiers.
>
> Signed-off-by: Paul Kocialkowski
Acked-by: Maxime Ripard
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel
On Tue, Dec 04, 2018 at 03:22:18PM +0100, Paul Kocialkowski wrote:
> This adds the appropriate device-tree compatible and quirk data for
> hooking frontend support for the A20. It supports the FIR coefficients
> ready bit but not the access control bit. It also takes different phase
> values than
On Tue, Dec 04, 2018 at 03:22:09PM +0100, Paul Kocialkowski wrote:
> This introduces stride and offset configuration for the VPU tiling mode.
> Stride is calculated differently than it is for linear formats and an
> offset is calculated, for which new register definitions are introduced.
>
>
On Tue, Dec 04, 2018 at 03:22:11PM +0100, Paul Kocialkowski wrote:
> This introduces a list of supported modifiers for the driver, that
> includes the Allwinner tiled modifier, as well as a format_mod_supported
> callback.
>
> The callback uses both the backend and frontend helpers to indicate
>
On Tue, Dec 04, 2018 at 03:22:10PM +0100, Paul Kocialkowski wrote:
> This introduces a helper to check whether a frontend input format
> supports tiling mode. This helper is used when tiling is requested in
> the frontend format support helper.
>
> Only semiplanar and planar YUV formats are
On Tue, Dec 04, 2018 at 03:22:08PM +0100, Paul Kocialkowski wrote:
> This introduces the data input mode definitions for the tiled YUV mode,
> that are used in the input mode helper if tiling is requested.
>
> The modifier is passed to the helper from the framebuffer to determine
> if tiling is
On Tue, Dec 04, 2018 at 03:22:06PM +0100, Paul Kocialkowski wrote:
> Planar YUV formats come with 3 distinct planes, which requires
> configuring the frontend line stride and address registers for the
> third plane.
>
> Our hardware only supports the YUV planes order and in order to support
>
1 - 100 of 218 matches
Mail list logo
