It is the first step for the GTT size issue.
Need other patches I am working on it.
Thanks
Roger(Hongbo.He)
-Original Message-
From: Zhou, David(ChunMing)
Sent: Friday, January 12, 2018 2:46 PM
To: He, Roger ; dri-devel@lists.freedesktop.org
Cc: Koenig, Christian
Subject: Re: [PATCH 1/2]
Can this fix GTT size issue or not?
Regards,
David Zhou
On 2018年01月12日 14:14, Roger He wrote:
add input parameter for ttm_dma_unpopulate.
when ttm_dma_pool_get_pages or ttm_mem_global_alloc_page fail, don't
call ttm_mem_global_free_page to update global memory count.
Signed-off-by: Roger He
-
From: "Sharma, Shashank"
HDMI 2.0/CEA-861-F introduces two new aspect ratios:
- 64:27
- 256:135
This patch:
- Adds new DRM flags for to represent these new aspect ratios.
- Adds new cases to handle these aspect ratios while converting
from user->kernel mode or vise versa.
This patch was once
From: Ankit Nautiyal
We parse the EDID and add all the modes in the connector's
modelist. This adds CEA modes with aspect ratio information
too, regadless of if user space requested this information or
not.
This patch prunes the modes with aspect-ratio information, from
a connector's modelist, i
From: Ankit Nautiyal
If the user mode does not support aspect-ratio, and requests for
a modeset, then the flag bits representing aspect ratio in the
given user-mode must be rejected.
Similarly, while preparing a user-mode from kernel mode, the
aspect-ratio info must not be given, if aspect-ratio
From: Ville Syrjälä
Use drm_mode_equal_no_clocks_no_stereo() in
drm_match_hdmi_mode_clock_tolerance() for consistency as we
also use it in drm_match_hdmi_mode() and the cea mode matching
functions.
This doesn't actually change anything since the input mode
comes from detailed timings and we matc
From: Ville Syrjälä
Make mode matching less confusing by allowing the caller to specify
which parts of the modes should match via some flags.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_modes.c | 134 ++--
include/drm/drm_modes.h | 9 +++
From: "Sharma, Shashank"
Current DRM layer functions don't parse aspect ratio information
while converting a user mode->kernel mode or vice versa. This
causes modeset to pick mode with wrong aspect ratio, eventually
causing failures in HDMI compliance test cases, due to wrong VIC.
This patch add
From: Ankit Nautiyal
A new drm client cap is required to enable user-space to advertise
if it supports modes with aspect-ratio. Based on this cap value, the
kernel will take a call on exposing the aspect ratio information in
modes or not.
This patch adds the client cap for aspect-ratio.
Cc: Vil
From: Ville Syrjälä
commit 6dffd431e229 ("drm: Add aspect ratio parsing in DRM layer")
cause us to not send out any VICs in the AVI infoframes. That commit
was since reverted, but if and when we add aspect ratio handing back
we need to be more careful.
Let's handle this by considering the aspect
From: Ankit Nautiyal
This patch series is a re-attempt to enable aspect ratio support in
DRM layer. Currently the aspect ratio information gets lost in
translation during a user->kernel mode or vice versa.
The old patch series (https://pw-emeril.freedesktop.org/series/10850/) had
4 patches, out
if ttm_get_pages or ttm_mem_global_alloc_page fail, should not update
global memory count.
Signed-off-by: Roger He
---
drivers/gpu/drm/ttm/ttm_page_alloc.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c
b/drivers/gpu/drm/ttm/ttm_pa
add input parameter for ttm_dma_unpopulate.
when ttm_dma_pool_get_pages or ttm_mem_global_alloc_page fail, don't
call ttm_mem_global_free_page to update global memory count.
Signed-off-by: Roger He
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_bo.c |
On Thu, Jan 11, 2018 at 3:25 AM, Jernej Skrabec wrote:
> Some SoCs, like Allwinner A83T, have to do additional cleanup when
> HDMI driver unloads. When using DW HDMI through DRM bridge API, there is
> no place to store driver's private data so it can be accessed in unbind
> function. Because of th
On Tue, Jan 9, 2018 at 10:05 PM, John Stultz wrote:
> When using drm_hwcomposer with the hikey/hikey960 boards, the
> resulting display shows lots of tearing.
>
> I'm not much of an expert in how this code should work, but it
> seems that we never call sync_wait(), and thus don't seem to be
> hand
>
> this work is based on the virtio_wl driver in the ChromeOS kernel by
> Zach Reizner, currently at:
>
> https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-4.4/drivers/virtio/virtio_wl.c
>
> There's two features missing in this patch when compared with virtio_wl:
>
> * All
On Gen3 hardware the VSP compositor is required for display. Enable it
by default in the kernel configuration. The option is kept
user-configurable for testing purpose on Gen2 platforms.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/Kconfig | 3 ++-
1 file changed, 2 insertions(+),
https://bugs.freedesktop.org/show_bug.cgi?id=104592
Bug ID: 104592
Summary: [r600g] Rejected CS when using dolphin's GPU texture
decoder
Product: Mesa
Version: git
Hardware: x86-64 (AMD64)
OS: Linux (All)
https://bugs.freedesktop.org/show_bug.cgi?id=104591
Bug ID: 104591
Summary: [r600g] Compute demos and pigilt tests broken on
REDWOOD, works fine on JUNIPER
Product: Mesa
Version: git
Hardware: x86-64 (AMD64)
Hey Linus,
Hopefully the final set of fixes,
Nouveau regression fix,
Tegra regression fix,
vmwgfx crasher + freed data leak
i915 KASAN use after free fix, whitelist register to avoid hang fix, GVT fixes
vc4 irq/pm fix
Dave.
The following changes since commit b2cd1df66037e7c4697c7e40496bf7e4a5e1
Hi Sergei,
Thank you for the patch.
On Thursday, 11 January 2018 18:54:33 EET Sergei Shtylyov wrote:
> After the recent correction of the R-Car gen3 LVDCR1 value, already similar
> enough at their ends rcar_du_lvdsenc_start_gen{2|3}() started asking for a
> merge and it's becoming actually neces
2018년 01월 09일 19:56에 Maxime Ripard 이(가) 쓴 글:
> Now that the core has a drm format helper to tell if a format embeds an
> alpha component in it, let's use it.
>
> Cc: Inki Dae
> Cc: Joonyoung Shim
> Cc: Kyungmin Park
> Cc: Seung-Woo Kim
> Signed-off-by: Maxime Ripard
Acked-by: Inki Dae
Th
Hi Sergei,
Thank you for the patch.
On Thursday, 11 January 2018 18:54:35 EET Sergei Shtylyov wrote:
> Add support for the R-Car V3M (R8A77970) SoC to the DU driver (this SoC
> has only 1 display port). Note that there are some differences with the
> other R-Car gen3 SoCs in the LVDS encoder
The internal LVDS encoder now has DT bindings separate from the DU. Port
the device tree over to the new model.
Signed-off-by: Laurent Pinchart
---
.../boot/dts/renesas/r8a7795-es1-salvator-x.dts| 3 +-
arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts | 3 +-
arch/arm64/boot/dts/renesas/
The internal LVDS encoder now has DT bindings separate from the DU. Port
the device tree over to the new model.
Signed-off-by: Laurent Pinchart
---
arch/arm/boot/dts/r8a7793-gose.dts | 10 +++---
arch/arm/boot/dts/r8a7793.dtsi | 35 +--
2 files changed, 36
The internal LVDS encoder now has DT bindings separate from the DU. Port
the device tree over to the new model.
Signed-off-by: Laurent Pinchart
---
arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts | 3 +-
arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts | 3 +-
arch/arm64/boot/dts/renesas/
The LVDS encoders used to be described in DT as part of the DU. They now
have their own DT node, linked to the DU using the OF graph bindings.
This allows moving internal LVDS encoder support to a separate driver
modelled as a DRM bridge. Backward compatibility is retained as legacy
DT is patched l
The internal LVDS encoder now has DT bindings separate from the DU. Port
the device tree over to the new model.
Signed-off-by: Laurent Pinchart
---
arch/arm/boot/dts/r8a7791-koelsch.dts | 10 --
arch/arm/boot/dts/r8a7791-porter.dts | 16 +---
arch/arm/boot/dts/r8a7791.dtsi
The HDMI encoder is connected to the RGB output of the DU, which is
port@0, not port@1. Fix the incorrect DT description.
Signed-off-by: Laurent Pinchart
---
arch/arm/boot/dts/r8a7791-porter.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/r8a7791-porter.
The internal LVDS encoder now has DT bindings separate from the DU. Port
the device tree over to the new model.
Signed-off-by: Laurent Pinchart
---
arch/arm/boot/dts/r8a7790-lager.dts | 22 ++---
arch/arm/boot/dts/r8a7790.dtsi | 61 -
2 files chan
The Renesas R-Car Gen2 and Gen3 SoCs have internal LVDS encoders. Add
corresponding device tree bindings.
Signed-off-by: Laurent Pinchart
---
.../bindings/display/bridge/renesas,lvds.txt | 54 ++
MAINTAINERS| 1 +
2 files changed
The internal LVDS encoders now have their own DT bindings, representing
them as part of the DU is deprecated.
Signed-off-by: Laurent Pinchart
---
.../devicetree/bindings/display/renesas,du.txt | 26 +-
1 file changed, 11 insertions(+), 15 deletions(-)
diff --git a/Docume
The internal LVDS encoders now have their own DT bindings. Before
switching the driver infrastructure to those new bindings, implement
backward-compatibility through live DT patching.
Patching is disabled and will be enabled along with support for the new
DT bindings in the DU driver.
Signed-off-
Hello,
This patch series addresses a design mistake that dates back from the initial
DU support. Support for the LVDS encoders, which are IP cores separate from
the DU, was bundled in the DU driver. Worse, both the DU and LVDS were
described through a single DT node.
To fix the, patches 01/10 and
Boris Brezillon writes:
> The V3D engine has various hardware counters which might be interesting
> to userspace performance analysis tools.
>
> Expose new ioctls to create/destroy a performance monitor object and
> query the counter values of this perfmance monitor.
>
> Note that a perfomance mo
Hi Sergei,
On Thursday, 21 December 2017 22:23:30 EET Sergei Shtylyov wrote:
> The LVDCR1 register for the R-Car gen3 SoCs was documented as having the
> layout different from the gen2 SoCs in the early R-Car gen3 manuals but
> since v0.52 the LVDCR1 layout is described as being the same as on th
From: Thierry Reding
This is obviously wrong in the current code. Make sure to record the
correct size of the arguments and pass the actual arguments to the
nvif_object_map_handle() function.
Suggested-by: Ben Skeggs
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 4 +
https://bugs.freedesktop.org/show_bug.cgi?id=102800
--- Comment #17 from higu...@gmx.net ---
Sorry for the delay!
yes, it works! After applying the patch, i can use the radeon card without the
runpm=0 normally
--
You are receiving this mail because:
You are the assignee for the bug.
On 01/10/2018 12:59 PM, Noralf Trønnes wrote:
The MIPI DBI spec states that reset active/low time should be more
than 9us. Change from 20ms to 20us.
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/tinydrm/mipi-dbi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/driver
On 01/10/2018 12:59 PM, Noralf Trønnes wrote:
Split out common poweron-reset functionality.
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/tinydrm/mi0283qt.c | 22 ++--
drivers/gpu/drm/tinydrm/mipi-dbi.c | 73 ++
drivers/gpu/drm/tinydrm/st7586.
From: Thierry Reding
Add a new nouveau_pushbuf_kick_fence() function that takes and emits a
sync fence FD. The fence FD can be waited on, or merged with other fence
FDs, or passed back to the kernel as a prerequisite for a subsequent HW
operation.
Based heavily on work by Lauri Peltonen
Signed
From: Mikko Perttunen
Adds ability to pass sync file based prefences and get back
sync file based postfences during job submission. Both
fence fd's are passed in the `fence` field. A new `flags`
field is used to specify if the prefence should be waited
or a postfence created.
Signed-off-by: Mikk
On Tue, Jan 09, 2018 at 03:31:48PM +0530, Vivek Gautam wrote:
> qcom,smmu-v2 is an arm,smmu-v2 implementation with specific
> clock and power requirements. This smmu core is used with
> multiple masters on msm8996, viz. mdss, video, etc.
> Add bindings for the same.
>
> Signed-off-by: Vivek Gautam
From: Mikko Perttunen
Add support for sync file-based prefences and postfences
to job submission. Fences are passed to the Host1x implementation.
Signed-off-by: Mikko Perttunen
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/tegra/drm.c | 82 -
1
From: Mikko Perttunen
Add an implementation of DMA fences backed by Host1x syncpoints,
an interface to specify a prefence for job submissions.
Before submission, prefences containing only Host1x syncpoints
are waited by pushing wait commands to CDMA, whereas other
fences are CPU-waited.
Signed-
From: Thierry Reding
This set of patches adds support for fences to Tegra DRM and complements
the fence FD support for Nouveau. Technically this isn't necessary for a
fence-based synchronization loop with Nouveau because the KMS core takes
care of all that, but engines behind host1x can use the I
From: Thierry Reding
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/nouveau/nouveau_fence.c | 31 ---
1 file changed, 28 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c
b/drivers/gpu/drm/nouveau/nouveau_fence.c
index d61fcfb97b
From: Thierry Reding
This small series of patches implements support for waiting on and
emitting fence FDs on kickoff. This enables explicit fencing and can be
used for example to synchronize buffer accesses between the display
engine and the GPU on Tegra.
The first patch lays the groundwork by
Looks good to me.
>-Original Message-
>From: Navare, Manasi D
>Sent: Thursday, January 4, 2018 12:23 AM
>To: gfx-internal-de...@eclists.intel.com
>Cc: Navare, Manasi D ; Jani Nikula
>; Ville Syrjala ;
>Srivatsa, Anusha ; dri-devel@lists.freedesktop.org
>Subject: [PATCH v2 4/5] drm/dp: Mac
From: Thierry Reding
Add a new NOUVEAU_GEM_PUSHBUF2 IOCTL that accepts and emits a sync fence
FD from/to userspace if requested by the corresponding flags.
Based heavily on work by Lauri Peltonen
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/nouveau/nouveau_drm.c | 1 +
drivers/gpu/drm/
From: Thierry Reding
Turn nouveau_fence_sync() into a low-level helper that adds fence waits
to the channel command stream. The new nouveau_bo_sync() helper replaces
the previous nouveau_fence_sync() implementation. It passes each of the
buffer object's fences to nouveau_fence_sync() in turn.
Th
Hi Maxime,
On Friday, 12 January 2018 00:06:06 EET Laurent Pinchart wrote:
> On Thursday, 11 January 2018 15:12:56 EET Maxime Ripard wrote:
> > On Thu, Jan 11, 2018 at 03:05:01PM +0200, Laurent Pinchart wrote:
> >> On Wednesday, 10 January 2018 17:59:41 EET Maxime Ripard wrote:
> >>> The devm_regu
Hi Maxime,
On Thursday, 11 January 2018 15:12:56 EET Maxime Ripard wrote:
> On Thu, Jan 11, 2018 at 03:05:01PM +0200, Laurent Pinchart wrote:
> > On Wednesday, 10 January 2018 17:59:41 EET Maxime Ripard wrote:
> >> The devm_regulator_get_optional function, unlike it was assumed in the
> >> commit
From: Thierry Reding
struct device is forward-declared twice. Remove the second instance.
Reviewed-by: Chris Wilson
Signed-off-by: Thierry Reding
---
include/drm/drm_prime.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/include/drm/drm_prime.h b/include/drm/drm_prime.h
index 9cd9e36f77
From: Thierry Reding
Implement the ->begin_cpu_access() and ->end_cpu_access() callbacks to
allow userspace to invalidate the cache before accessing a buffer that
is exported using PRIME and flush the cache after modifying the buffer
through its userspace mapping.
Signed-off-by: Thierry Reding
From: Thierry Reding
Export some more of the helpers in order to allow drivers to more fine-
grainedly select which helpers to use. This gives drivers an easy way to
reuse a lot of the code in the helpers while at the same time allowing
them to provide their own implementation for other functions
From: Thierry Reding
Instead of relying on the DRM PRIME helpers to provide all of the
DMA-BUF operations, provide a custom version of struct dma_buf_ops to
allow additional functionality to be implemented.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/nouveau/nouveau_drm.c | 9 +-
dri
From: Thierry Reding
Provide an implementation of mmap() for PRIME exported buffers. This
allows userspace to map these buffers and access them using the CPU.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/nouveau/nouveau_prime.c | 32
1 file changed, 32 ins
From: Thierry Reding
Use IOMMU groups to attach the GPU to its IOMMU domain. This is not
strictly necessary because the domain isn't shared with any other
device, but it makes the code consistent with how IOMMU is handled in
other drivers and provides an easy way to detect when no IOMMU has
been
From: Thierry Reding
The nouveau_fence_get_get_driver_name() function has a redundant _get in
its name. Remove it.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/nouveau/nouveau_fence.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau
https://bugs.freedesktop.org/show_bug.cgi?id=99353
--- Comment #15 from Bong Cosca ---
[39409/39409] skip: 2874, pass: 15671, warn: 12, fail: 20845, crash: 7
Piglit results haven't changed much since, but notably with more crashes.
--
You are receiving this mail because:
You are the assignee f
Hi Jani,
On Thursday, 11 January 2018 16:31:59 EET Jani Nikula wrote:
> On Thu, 11 Jan 2018, Laurent Pinchart wrote:
> > My preference, however, would be for devm_regulator_get_optional() to
> > return NULL when no regulator is present. The current implementation
> > returns -ENODEV in multiple ca
https://bugs.freedesktop.org/show_bug.cgi?id=101900
--- Comment #20 from Alex Deucher ---
Everything looks like it's implemented properly in the code to enable HBR
audio. Take a look at:
drivers/gpu/drm/amd/display/dc/dce/dce_audio.c for audio configuration
drivers/gpu/drm/amd/display/dc/dce/dce
Quoting Thierry Reding (2018-01-11 20:17:30)
> From: Thierry Reding
>
> struct device is forward-declared twice. Remove the second instance.
So good they declared it twice. Also the first one first in with the
alphabetical ordering.
> Signed-off-by: Thierry Reding
Reviewed-by: Chris Wilson
-
Daniel Vetter writes:
> On Wed, Jan 10, 2018 at 03:12:24PM +0100, Linus Walleij wrote:
>> After some discussion and failed patch sets trying to convey
>> the right timing information between the display engine and
>> a bridge using the connector, I try instead to use an optional
>> timing informa
Linus Walleij writes:
> If the bridge has a too strict setup time for the incoming
> signals, we may not be fast enough and then we need to
> compensate by outputting the signal on the inverse clock
> edge so it is for sure stable when the bridge samples it.
>
> Since bridges in difference to pan
From: Thierry Reding
struct device is forward-declared twice. Remove the second instance.
Signed-off-by: Thierry Reding
---
include/drm/drm_prime.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/include/drm/drm_prime.h b/include/drm/drm_prime.h
index 9cd9e36f77b5..59ccab402e85 100644
---
Hi Rob,
> -Original Message-
> From: Rob Herring [mailto:r...@kernel.org]
> Sent: Thursday, January 11, 2018 6:43 AM
> To: Hyun Kwon
> Cc: dri-devel@lists.freedesktop.org; devicet...@vger.kernel.org; Michal
> Simek
> Subject: Re: [PATCH 01/10] dt-bindings: display: xlnx: Add Xilinx kms
>
Hi Daniel,
On Thursday, 11 January 2018 18:36:10 EET Daniel Vetter wrote:
> On Thu, Jan 11, 2018 at 4:58 PM, Maxime Ripard wrote:
> > On Tue, Jan 09, 2018 at 03:28:34PM +0100, Daniel Vetter wrote:
> >> On Tue, Jan 09, 2018 at 02:53:22PM +0100, Maxime Ripard wrote:
> >>> On Tue, Jan 09, 2018 at 01:
Add support for the R-Car V3M (R8A77970) SoC to the DU driver (this SoC
has only 1 display port). Note that there are some differences with the
other R-Car gen3 SoCs in the LVDS encoder part, e.g. LVDPLLCR has the same
layout as on the R-Car gen2 SoCs...
Signed-off-by: Sergei Shtylyov
---
In order to add the R-Car V3M (R8A77970) support to the DU driver we'd need
to keep track not only of the SoC generation but also of the exact model
(for the LVDS encoder support). Therefore add the 'model' field to the
'struct rcar_du_device_info' and initialize it accordingly for the alrea
Hello!
Here's the set of 3 patches against the 'drm-next' branch of David Airlie's
'linux.git' repo plus the patch fixing LVDCR1 for R-Car gen3 posted recently.
The main purpose of these patches is to add the R-Car V3M (R8A77970) support
to the DU driver, we have to do some refactoring first to ac
After the recent correction of the R-Car gen3 LVDCR1 value, already similar
enough at their ends rcar_du_lvdsenc_start_gen{2|3}() started asking for a
merge and it's becoming actually necessary with the addition the R-Car V3M
(R8A77970) support -- this gen3 SoC has gen2-like LVDPLLCR layout.
BT
Hi Daniel,
> -Original Message-
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
> Sent: Thursday, January 11, 2018 12:06 AM
> To: Hyun Kwon
> Cc: Daniel Vetter ; dri-devel@lists.freedesktop.org;
> devicet...@vger.kernel.org; Tejas Upadhyay ; Michal
> Simek
Hi Dave,
The following changes since commit ebae8d07435ae91314f4a28d69b530d09c625815:
drm/tegra: dc: Implement legacy blending (2017-12-21 14:55:55 +0100)
are available in the Git repository at:
git://anongit.freedesktop.org/tegra/linux tags/drm/tegra/for-4.16-rc1-fixes
for you to fetch ch
The documentation was misleading, as for a lot of use-cases holding
the RCU read side lock is sufficient.
Signed-off-by: Lucas Stach
---
include/linux/reservation.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/linux/reservation.h b/include/linux/reservation.h
ind
This adds lockdep asserts to the reservation functions which state in their
documentation that obj->lock must be held. Allows builds with PROVE_LOCKING
enabled to check that the locking requirements are met.
Signed-off-by: Lucas Stach
---
v2: remove erroneous check from reservation_object_get_exc
On Thu, Jan 11, 2018 at 05:41:17PM +0100, Thierry Reding wrote:
> Hi Dave,
>
> Merge branch 'linux-4.15' of git://github.com/skeggsb/linux into drm-fixes
> (2018-01-09 12:03:10 +1000)
>
> are available in the Git repository at:
>
> git://anongit.freedesktop.org/tegra/linux tags/drm/tegra/fo
A good catch. I'll fix that.
Regards,
Samuel Li
> -Original Message-
> From: Dan Carpenter [mailto:dan.carpen...@oracle.com]
> Sent: Thursday, January 11, 2018 1:43 AM
> To: kbu...@01.org; Li, Samuel
> Cc: kbuild-...@01.org; dri-devel@lists.freedesktop.org; amd-
> g...@lists.freedesktop
Hi Dave,
The following changes since commit b0bb222440a5c8273f67dd37946707e6ba6ad832:
Merge branch 'linux-4.15' of git://github.com/skeggsb/linux into drm-fixes
(2018-01-09 12:03:10 +1000)
are available in the Git repository at:
git://anongit.freedesktop.org/tegra/linux tags/drm/tegra/for-
Hi Dave,
Merge branch 'linux-4.15' of git://github.com/skeggsb/linux into drm-fixes
(2018-01-09 12:03:10 +1000)
are available in the Git repository at:
git://anongit.freedesktop.org/tegra/linux tags/drm/tegra/for-4.15-rc8
for you to fetch changes up to d780537f9b49e9d714a454e5ed989d909beab
On Thu, Jan 11, 2018 at 4:58 PM, Maxime Ripard
wrote:
> On Tue, Jan 09, 2018 at 03:28:34PM +0100, Daniel Vetter wrote:
>> On Tue, Jan 09, 2018 at 02:53:22PM +0100, Maxime Ripard wrote:
>> > On Tue, Jan 09, 2018 at 01:32:41PM +0100, Daniel Vetter wrote:
>> > > On Tue, Jan 09, 2018 at 11:56:25AM +01
On Tue, Jan 09, 2018 at 03:28:34PM +0100, Daniel Vetter wrote:
> On Tue, Jan 09, 2018 at 02:53:22PM +0100, Maxime Ripard wrote:
> > On Tue, Jan 09, 2018 at 01:32:41PM +0100, Daniel Vetter wrote:
> > > On Tue, Jan 09, 2018 at 11:56:25AM +0100, Maxime Ripard wrote:
> > > > Some drivers duplicate the
https://bugs.freedesktop.org/show_bug.cgi?id=103316
--- Comment #6 from Vedran Miletić ---
Still the case in Fedora rawhide with kernel 4.15.0-0.rc7.git0.1.fc28.x86_64
[ 2582.430297] [drm] radeon: finishing device.
[ 2582.445874] [TTM] Finalizing pool allocator
[ 2582.445877] [TTM] Finalizing DM
Hi Dave -
Hopefully final drm/i915 fixes for v4.15:
- Fix a KASAN reported use after free
- Whitelist a register to avoid hangs
- GVT fixes
BR,
Jani.
The following changes since commit b2cd1df66037e7c4697c7e40496bf7e4a5e16a2d:
Linux 4.15-rc7 (2018-01-07 14:22:41 -0800)
are available in the
https://bugs.freedesktop.org/show_bug.cgi?id=91880
--- Comment #180 from x...@amail.club ---
>From watching this bug progress over the last two years and not really
improving, I guess this problem is never going to get fixed, at least not too
soon.
>From my testing last year, it would seem that t
On Wed, Jan 10, 2018 at 8:04 PM, Hyun Kwon wrote:
> Hi Rob,
>
> Thanks for the feedback.
>
>> -Original Message-
>> From: Rob Herring [mailto:r...@kernel.org]
>> Sent: Monday, January 08, 2018 8:00 PM
>> To: Hyun Kwon
>> Cc: dri-devel@lists.freedesktop.org; devicet...@vger.kernel.org; Mic
On Thu, Jan 11, 2018 at 1:15 AM, Gustavo A. R. Silva
wrote:
> In case kfd_get_process_device_data returns null, there are some
> null pointer dereferences in functions kfd_bind_processes_to_device
> and kfd_unbind_processes_from_device.
>
> Fix this by printing a WARN_ON for PDDs that aren't found
On Thu, 11 Jan 2018, Laurent Pinchart wrote:
> My preference, however, would be for devm_regulator_get_optional() to return
> NULL when no regulator is present. The current implementation returns -ENODEV
> in multiple cases, making it impossible to properly discriminate between
> having no regu
Den 11.01.2018 08.45, skrev Daniel Vetter:
On Wed, Jan 10, 2018 at 06:02:38PM +0100, Noralf Trønnes wrote:
Den 09.01.2018 11.38, skrev Daniel Vetter:
On Wed, Jan 03, 2018 at 11:21:08PM +0100, Noralf Trønnes wrote:
Prepare for generic fbdev emulation by letting DRM core work directly
with the
Hi Brian & All *DSI DRM experts*,
1) Re-reading this patch, I realize that the returned value of
dw_mipi_dsi_host_transfer() is not correct: we should return the number
of transfered/received bytes...
so I think there are two solutions: fix this in this serie or add a TODO
for later (both solu
Hi Brian,
Reviewed-by: Philippe Cornu
Many thanks,
Philippe :-)
On 01/09/2018 09:33 PM, Brian Norris wrote:
> sparse complains:
>
> drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c:703:6: warning: symbol
> 'dw_mipi_dsi_bridge_mode_set' was not declared. Should it be static?
>
> Signed-off-by: Br
Hi,
On Thu, Jan 11, 2018 at 03:05:01PM +0200, Laurent Pinchart wrote:
> Hi Maxime,
>
> (CC'ing Mark Brown)
>
> Thank you for the patch.
>
> On Wednesday, 10 January 2018 17:59:41 EET Maxime Ripard wrote:
> > The devm_regulator_get_optional function, unlike it was assumed in the
> > commit a1c55
Hi Maxime,
(CC'ing Mark Brown)
Thank you for the patch.
On Wednesday, 10 January 2018 17:59:41 EET Maxime Ripard wrote:
> The devm_regulator_get_optional function, unlike it was assumed in the
> commit a1c55bccf600 ("drm/panel: lvds: Add support for the power-supply
> property"), is actually ret
On 15.12.2017 23:19, Rodrigo Vivi wrote:
> On Fri, Dec 15, 2017 at 04:39:25PM +, Ingo Molnar wrote:
>>
>> * Lucas De Marchi wrote:
>>
>>> CFL was missing from intel_early_ids[]. The PCI ID needs to be there to
>>> allow the memory region to be stolen, otherwise we could have RAM being
>>> arbi
On Tue, Jan 09, 2018 at 01:03:20PM +1100, Jonathan Liu wrote:
> This patchset fixes several issues in sun4i_tmds_determine_rate that I
> discovered while trying to get a projector connected to an Olimex
> A20-OLinuXino-LIME using HDMI with a native resolution of 1280x800 and
> pixel clock of 83.5 M
Hi Daniel,
On Thursday, 11 January 2018 10:19:50 EET Daniel Vetter wrote:
> On Wed, Jan 10, 2018 at 06:28:51PM +0200, Peter Ujfalusi wrote:
> > On 01/09/2018 04:40 PM, Daniel Vetter wrote:
> >> On Tue, Jan 09, 2018 at 04:18:48PM +0200, Peter Ujfalusi wrote:
> >>> On 2018-01-09 14:44, Daniel Vetter
On Wed, Jan 10, 2018 at 08:25:07PM +0100, Jernej Skrabec wrote:
> Some TCONs on newer SoCs doesn't support channel 0, since they are meant
> to be used only with TV or HDMI encoder.
>
> Prepare support for them with adding has_channel_0 quirk.
>
> Signed-off-by: Jernej Skrabec
Acked-by: Maxime
On Wed, Jan 10, 2018 at 08:25:08PM +0100, Jernej Skrabec wrote:
> This TCON is connected to HDMI encoder.
>
> Signed-off-by: Jernej Skrabec
Acked-by: Maxime Ripard
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
signature.asc
https://bugs.freedesktop.org/show_bug.cgi?id=103107
--- Comment #11 from Marta Löfstedt ---
https://patchwork.freedesktop.org/patch/197018/
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@
1 - 100 of 129 matches
Mail list logo
