On 8/22/19 3:36 PM, Daniel Vetter wrote:
On Thu, Aug 22, 2019 at 3:30 PM Thomas Hellström (VMware)
wrote:
On 8/22/19 3:07 PM, Daniel Vetter wrote:
Full audit of everyone:
- i915, radeon, amdgpu should be clean per their maintainers.
- vram helpers should be fine, they don't do command
This patch introduce new enum which contains all VPU family (GXBB,
GXL, GXM and G12A).
This enum is used to detect the VPU compatible with the device.
We only need to set .data to the corresponding enum in the device
table, no need to check .compatible string anymore.
Signed-off-by: Julien
On Thu 22 Aug 07:37 PDT 2019, Brian Masney wrote:
> From: Rob Clark
>
> Add support to restore the secure configuration for qcm_scm-32.c. This
> is needed by the On Chip MEMory (OCMEM) that is present on some
> Snapdragon devices.
>
> Signed-off-by: Rob Clark
> [masn...@onstation.org: ported
https://bugs.freedesktop.org/show_bug.cgi?id=110659
--- Comment #39 from Nicholas Kazlauskas ---
Disabling the compositor doesn't make a difference as far as stuttering goes
for Hitman 2's DXVK - I don't see any commits in the log that are lock the
connector and all the planes.
I don't have
Add device tree bindings for the On Chip Memory (OCMEM) that is present
on some Qualcomm Snapdragon SoCs.
Signed-off-by: Brian Masney
Reviewed-by: Rob Herring
---
Changes since v5:
- None
Changes since v4:
- remove qcom from path in $id
Changes since v3:
- add ranges property
- remove
The OCMEM driver handles allocation and configuration of the On Chip
MEMory that is present on some Snapdragon SoCs. Devices which have
OCMEM do not have GMEM inside the GPU core, so the GPU must instead
use OCMEM to be functional. Since the GPU is currently the only OCMEM
user with an upstream
The files a3xx_gpu.c and a4xx_gpu.c have ifdefs for the OCMEM support
that was missing upstream. Add two new functions (adreno_gpu_ocmem_init
and adreno_gpu_ocmem_cleanup) that removes some duplicated code.
Signed-off-by: Brian Masney
---
Changes since v5:
- None
Changes since v4:
- None
From: Rob Clark
Add support to restore the secure configuration for qcm_scm-32.c. This
is needed by the On Chip MEMory (OCMEM) that is present on some
Snapdragon devices.
Signed-off-by: Rob Clark
[masn...@onstation.org: ported to latest kernel; set ctx_bank_num to
spare parameter.]
Some A3xx and A4xx Adreno GPUs do not have GMEM inside the GPU core and
must use the On Chip MEMory (OCMEM) in order to be functional. Add the
optional ocmem property to the Adreno Graphics Management Unit bindings.
Signed-off-by: Brian Masney
---
Changes since v5:
- rename ocmem property to
Add ocmem driver that's needed for some a3xx and a4xx based systems.
Signed-off-by: Brian Masney
---
Changes since v5:
- None
This patch was introduced in v5.
arch/arm/configs/qcom_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/qcom_defconfig
From: Rob Clark
Add support for the OCMEM lock/unlock interface that is needed by the
On Chip MEMory (OCMEM) that is present on some Snapdragon devices.
Signed-off-by: Rob Clark
[masn...@onstation.org: ported to latest kernel; minor reformatting.]
Signed-off-by: Brian Masney
Reviewed-by:
This patch series adds support for Qualcomm's On Chip MEMory (OCMEM)
that is needed in order to support some a3xx and a4xx-based GPUs
upstream. This is based on Rob Clark's patch series that he submitted
in October 2015 and I am resubmitting updated patches with his
permission. See the individual
On Thu, 22 Aug 2019, Ramalingam C wrote:
> On gen12+ platforms, HDCP HW is associated to the transcoder.
> Hence on every modeset associated transcoder is updated into the
> intel_hdcp.
>
> Signed-off-by: Ramalingam C
> ---
> .../drm/i915/display/intel_display_types.h| 7 +++
>
On Wed, Aug 21, 2019 at 06:57:24PM -0700, Rob Clark wrote:
> From: Rob Clark
>
> Signed-off-by: Rob Clark
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 20
> 1 file changed, 20 insertions(+)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
>
On Wed, Aug 21, 2019 at 10:38:35PM +0200, Daniel Vetter wrote:
> Oops.
>
> Fixes: 9edbf1fa600a ("drm: Add API for capturing frame CRCs")
> Cc: Tomeu Vizoso
> Cc: Emil Velikov
> Cc: Benjamin Gaignard
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_debugfs_crc.c | 2 +-
> 1 file
On 8/22/19 4:24 PM, Thomas Hellström (VMware) wrote:
On 8/22/19 4:02 PM, Koenig, Christian wrote:
Am 22.08.19 um 15:06 schrieb Daniel Vetter:
On Thu, Aug 22, 2019 at 07:56:56AM +, Koenig, Christian wrote:
Am 22.08.19 um 08:49 schrieb Daniel Vetter:
With nouveau fixed all ttm-using drives
On Thu, Aug 22, 2019 at 4:24 PM Jason Gunthorpe wrote:
>
> On Thu, Aug 22, 2019 at 10:42:39AM +0200, Daniel Vetter wrote:
>
> > > RDMA has a mutex:
> > >
> > > ib_umem_notifier_invalidate_range_end
> > > rbt_ib_umem_for_each_in_range
> > >invalidate_range_start_trampoline
> > >
On 8/22/19 4:02 PM, Koenig, Christian wrote:
Am 22.08.19 um 15:06 schrieb Daniel Vetter:
On Thu, Aug 22, 2019 at 07:56:56AM +, Koenig, Christian wrote:
Am 22.08.19 um 08:49 schrieb Daniel Vetter:
With nouveau fixed all ttm-using drives have the correct nesting of
mmap_sem vs dma_resv, and
On Thu, Aug 22, 2019 at 10:42:39AM +0200, Daniel Vetter wrote:
> > RDMA has a mutex:
> >
> > ib_umem_notifier_invalidate_range_end
> > rbt_ib_umem_for_each_in_range
> >invalidate_range_start_trampoline
> > ib_umem_notifier_end_account
> > mutex_lock(_odp->umem_mutex);
> >
> > I'm
On Thu, 22 Aug 2019, Ramalingam C wrote:
> From Gen12 onwards, HDCP HW block is implemented within transcoders.
> Till Gen11 HDCP HW block was part of DDI.
>
> Hence required changes in HW programming is handled here.
>
> As ME FW needs the transcoder detail on which HDCP is enabled
> on Gen12+
Hi Neil,
On Thu 22 Aug 2019 at 16:14, Julien Masson wrote:
> On 22/08/2019 11:03, Julien Masson wrote:
>> This patch introduce new enum which contains all VPU family (GXBB,
>> GXL, GXM and G12A).
>> This enum is used to detect the VPU compatible with the device.
>>
>> We only need to set .data
Am 22.08.19 um 15:06 schrieb Daniel Vetter:
> On Thu, Aug 22, 2019 at 07:56:56AM +, Koenig, Christian wrote:
>> Am 22.08.19 um 08:49 schrieb Daniel Vetter:
>>> With nouveau fixed all ttm-using drives have the correct nesting of
>>> mmap_sem vs dma_resv, and we can just lock the buffer.
>>>
>>>
Add drm_dp_mst_dsc_caps_for_port and drm_dp_mst_dsc_enable,
two helper functions for MST DSC
The former, given a port, returns the raw DPCD DSC caps off
that port.
The latter, given a port, enables or disables DSC on that port.
In both cases, the port given as input should be a leaf of
the MST
This field on drm_dp_mst_branch was never filled
Initialize it to zero when the list of ports is created.
When a port is added to the list, increment num_ports,
and when a port is removed from the list, decrement num_ports.
v2: remember to decrement on port removal
Signed-off-by: David Francis
As of DP1.4, ENUM_PATH_RESOURCES returns a bit indicating
if FEC can be supported up to that point in the MST network.
The bit is the first byte of the ENUM_PATH_RESOURCES ack reply,
bottom-most bit (refer to section 2.11.9.4 of DP standard,
v1.4)
That value is needed for FEC and DSC support
Instead of having drm_dp_dpcd_read/write and
drm_dp_mst_dpcd_read/write as entry points into the
aux code, have drm_dp_dpcd_read/write handle both.
This means that DRM drivers can make MST DPCD read/writes.
v2: Fix spacing
Cc: Leo Li
Cc: Lyude Paul
Signed-off-by: David Francis
---
With DSC, bpp can be a multiple of 1/16, so
drm_dp_calc_pbn_mode is insufficient.
Add drm_dp_calc_pbn_mode_dsc, a function which is
the same as drm_dp_calc_pbn_mode, but the bpp is
in units of 1/16.
Reviewed-by: Lyude Paul
Signed-off-by: David Francis
---
drivers/gpu/drm/drm_dp_mst_topology.c
Add necessary support for MST DSC.
(Display Stream COmpression over Multi-Stream Transport)
v4: Split patchset and rebase onto drm-tip
David Francis (5):
drm/dp-mst: Add PBN calculation for DSC modes
drm/dp-mst: Parse FEC capability on MST ports
drm/dp-mst: Add MST support to DP DPCD R/W
Am 22.08.19 um 15:02 schrieb Daniel Vetter:
> On Thu, Aug 22, 2019 at 10:23:29AM +0200, Christian König wrote:
>> Am 21.08.19 um 18:04 schrieb Daniel Vetter:
>>> On Wed, Aug 21, 2019 at 02:31:44PM +0200, Christian König wrote:
[SNIP]
+ /* Try to drop the last reference */
+ if
I was building against amd-staging-drm-next (commit e4a67e6cf14c).
v4 will contain just the drm-mst patches and will apply on latest
drm-tip/drm-tip (commit 018886de4726)
From: Lyude Paul
Sent: August 21, 2019 5:20 PM
To: Francis, David;
On Thu, Aug 22, 2019 at 3:30 PM Thomas Hellström (VMware)
wrote:
>
> On 8/22/19 3:07 PM, Daniel Vetter wrote:
> > Full audit of everyone:
> >
> > - i915, radeon, amdgpu should be clean per their maintainers.
> >
> > - vram helpers should be fine, they don't do command submission, so
> >really
On 8/22/19 3:07 PM, Daniel Vetter wrote:
Full audit of everyone:
- i915, radeon, amdgpu should be clean per their maintainers.
- vram helpers should be fine, they don't do command submission, so
really no business holding struct_mutex while doing copy_*_user. But
I haven't checked them
Whoops, left in a test print. Ignore this patch
From: David Francis
Sent: August 21, 2019 4:01 PM
To: dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org
Cc: Francis, David; Liu, Wenjing; Cornij, Nikola
Subject: [PATCH v3 13/16]
Hi Guido,
I added my signed-off, plus some comments inline.
On Jo, 2019-08-22 at 12:44 +0200, Guido Günther wrote:
> This adds initial support for the NWL MIPI DSI Host controller found
> on
> i.MX8 SoCs.
>
> It adds support for the i.MX8MQ but the same IP can be found on
> e.g. the i.MX8QXP.
>
https://bugzilla.kernel.org/show_bug.cgi?id=204181
--- Comment #42 from Michel Dänzer (mic...@daenzer.net) ---
(In reply to Alex Deucher from comment #37)
> The TearFree option is there to deal with compositors that do not support
> sync to vblank.
Also for cases where a compositor cannot
On Thu, Aug 22, 2019 at 11:06:45AM +0200, Gerd Hoffmann wrote:
> No need for a home-grown version, the generic helper should work just
> fine. It also handles vgacon removal these days, see commit
> 1c74ca7a1a9a ("drm/fb-helper: call vga_remove_vgacon automatically."),
> so that can be removed
From: Colin Ian King
Variable baco_state is initialized to a value that is never read and it is
re-assigned later. The initialization is redundant and can be removed.
Addresses-Coverity: ("Unused Value")
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/amd/powerplay/smu_v11_0.c | 2 +-
1
On Thu, Aug 22, 2019 at 11:06:44AM +0200, Gerd Hoffmann wrote:
> Not needed any more for remove_conflicting_pci_framebuffers calls.
>
> Signed-off-by: Gerd Hoffmann
Reviewed-by: Daniel Vetter
> ---
> include/drm/drm_fb_helper.h | 4 +---
> drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
On Thu, Aug 22, 2019 at 11:06:43AM +0200, Gerd Hoffmann wrote:
> Since commit b0e999c95581 ("fbdev: list all pci memory bars as
> conflicting apertures") the parameter was used for some sanity checks
> only, to make sure we detect any issues with the new approach to just
> list all memory bars as
Full audit of everyone:
- i915, radeon, amdgpu should be clean per their maintainers.
- vram helpers should be fine, they don't do command submission, so
really no business holding struct_mutex while doing copy_*_user. But
I haven't checked them all.
- panfrost seems to dma_resv_lock only
On Thu, Aug 22, 2019 at 07:56:56AM +, Koenig, Christian wrote:
> Am 22.08.19 um 08:49 schrieb Daniel Vetter:
> > With nouveau fixed all ttm-using drives have the correct nesting of
> > mmap_sem vs dma_resv, and we can just lock the buffer.
> >
> > Assuming I didn't screw up anything with my
On Thu, Aug 22, 2019 at 10:23:29AM +0200, Christian König wrote:
> Am 21.08.19 um 18:04 schrieb Daniel Vetter:
> > On Wed, Aug 21, 2019 at 02:31:44PM +0200, Christian König wrote:
> > > [SNIP]
> > > + /* Try to drop the last reference */
> > > + if (!dma_fence_array_recycle(staged))
> > Without an
Hi Laurent,
thanks for review
On Tue, Aug 20, 2019 at 08:34:44PM +0300, Laurent Pinchart wrote:
> Hi Jacopo,
>
> Thank you for the patch.
>
> On Sat, Jul 06, 2019 at 04:07:41PM +0200, Jacopo Mondi wrote:
> > Add a driver for the R-Car Display Unit Color Correction Module.
> >
> > In most of
On Thu, Aug 22, 2019 at 1:55 AM Daniel Vetter wrote:
>
> Full audit of everyone:
>
> - i915, radeon, amdgpu should be clean per their maintainers.
>
> - vram helpers should be fine, they don't do command submission, so
> really no business holding struct_mutex while doing copy_*_user. But
> I
Acked-by: Alex Deucher
From: Hans Verkuil
Sent: Thursday, August 22, 2019 4:08 AM
To: Dariusz Marcinkiewicz ; dri-devel@lists.freedesktop.org
; linux-me...@vger.kernel.org
Cc: David Airlie ; nouv...@lists.freedesktop.org
; Dhinakaran Pandiyan
; Koo, Anthony
Outch, it reapared on the backmerge I did yesterday and I didn't noticed. Sorry
Chris has fixed this now.
Thank you both.
> On Aug 22, 2019, at 3:20 AM, Stephen Rothwell wrote:
>
> Hi all,
>
> I noticed that the drm tree has been back merge into the drm-intel
> tree. Unfortunately, it seems
On Thu, Aug 22, 2019 at 02:09:27PM +0300, Simon Ser wrote:
> This patch adds a line with the port name to connectors in
> debugfs/i915_debug_info. If the port is Type-C, the Type-C port number is
> printed too.
>
> Signed-off-by: Simon Ser
> Cc: Imre Deak
> Cc: Manasi Navare
Looks ok to me:
On Wed, Aug 21, 2019 at 02:31:47PM +0200, Christian König wrote:
> Additional to readers and writers add another class of operations
> which never participate in implicit synchronization.
>
> Signed-off-by: Christian König
> ---
> drivers/dma-buf/dma-resv.c | 27 ---
>
On 20.08.2019 00:45, Laurent Pinchart wrote:
> Hi Andrzej,
>
> On Mon, Aug 19, 2019 at 10:38:35AM +0200, Andrzej Hajda wrote:
>> On 14.08.2019 14:40, Daniel Vetter wrote:
>>> On Wed, Aug 14, 2019 at 01:04:03PM +0300, Laurent Pinchart wrote:
On Wed, Aug 14, 2019 at 08:23:12AM +0200, Andrzej
On Thu, 22 Aug 2019, Ramalingam C wrote:
> Enabling the HDCP1.4 and 2.2 on TGL by supporting the HW block movement
> from DDI into transcoder.
>
> v7:
> port, transcoder definitions are kept within I915.
> corresponding changes in i915-mei interface.
I had some superficial comments here and
On 08/21/19 13:12, Gerd Hoffmann wrote:
> We must make sure our scatterlist segments are not too big, otherwise
> we might see swiotlb failures (happens with sev, also reproducable with
> swiotlb=force).
>
> Suggested-by: Laszlo Ersek
> Signed-off-by: Gerd Hoffmann
> ---
>
On 22/08/2019 12:34, Boris Brezillon wrote:
> On Thu, 22 Aug 2019 12:22:02 +0200
> Neil Armstrong wrote:
>
>> On 22/08/2019 12:09, Boris Brezillon wrote:
>>> On Thu, 22 Aug 2019 11:29:40 +0200
>>> Neil Armstrong wrote:
>>>
>>> +/**
>>> + * struct drm_bus_caps - bus capabilities
From Gen12 onwards, HDCP HW block is implemented within transcoders.
Till Gen11 HDCP HW block was part of DDI.
Hence required changes in HW programming is handled here.
As ME FW needs the transcoder detail on which HDCP is enabled
on Gen12+ platform, we are populating the detail in
On gen12+ platforms, HDCP HW is associated to the transcoder.
Hence on every modeset associated transcoder is updated into the
intel_hdcp.
Signed-off-by: Ramalingam C
---
.../drm/i915/display/intel_display_types.h| 7 +++
drivers/gpu/drm/i915/display/intel_dp.c | 3 ++
For gen12+ platform we need to pass the transcoder info
as part of the port info.
Signed-off-by: Ramalingam C
---
drivers/misc/mei/hdcp/mei_hdcp.c | 11 +++
drivers/misc/mei/hdcp/mei_hdcp.h | 4 +++-
2 files changed, 14 insertions(+), 1 deletion(-)
diff --git
I915 needs to send the index of the transcoder as per ME FW.
To support this, enum mei_fw_ddi is defined and added as a member into
the struct hdcp_port_data.
Signed-off-by: Ramalingam C
---
include/drm/i915_mei_hdcp_interface.h | 13 +
1 file changed, 13 insertions(+)
diff --git
Enabling the HDCP1.4 and 2.2 on TGL by supporting the HW block movement
from DDI into transcoder.
v7:
port, transcoder definitions are kept within I915.
corresponding changes in i915-mei interface.
Ramalingam C (6):
drm/i915: mei_hdcp: I915 sends ddi index as per ME FW
drm: port
Handled the need for exposing enum port to mei_hdcp driver, by
converting the port into ddi index as per ME FW.
Hence enum port definition moved into I915 driver itself.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/display/intel_bios.h| 2 ++
This patch adds a line with the port name to connectors in
debugfs/i915_debug_info. If the port is Type-C, the Type-C port number is
printed too.
Signed-off-by: Simon Ser
Cc: Imre Deak
Cc: Manasi Navare
---
Thanks for your comments, Imre and Manasi. Here is v2:
- Use same port formatting as
Hi Laurent,
thanks for having a look!
On Wed, Aug 21, 2019 at 09:15:18PM +0300, Laurent Pinchart wrote:
> Hi Guido,
>
> Thank you for the patch.
>
> On Fri, Aug 09, 2019 at 06:24:22PM +0200, Guido Günther wrote:
> > The Northwest Logic MIPI DSI IP core can be found in NXPs i.MX8 SoCs.
> >
> >
This adds initial support for the NWL MIPI DSI Host controller found on
i.MX8 SoCs.
It adds support for the i.MX8MQ but the same IP can be found on
e.g. the i.MX8QXP.
It has been tested on the Librem 5 devkit using mxsfb.
Signed-off-by: Guido Günther
Co-developed-by: Robert Chiras
---
The Northwest Logic MIPI DSI IP core can be found in NXPs i.MX8 SoCs.
Signed-off-by: Guido Günther
---
.../bindings/display/bridge/nwl-dsi.yaml | 155 ++
1 file changed, 155 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml
This adds initial support for the NWL MIPI DSI Host controller found on i.MX8
SoCs.
It adds support for the i.MX8MQ but the same IP core can also be found on e.g.
i.MX8QXP. I added the necessary hooks to support other imx8 variants but since
I only have imx8mq boards to test I omitted the
On Thu, 22 Aug 2019 12:22:02 +0200
Neil Armstrong wrote:
> On 22/08/2019 12:09, Boris Brezillon wrote:
> > On Thu, 22 Aug 2019 11:29:40 +0200
> > Neil Armstrong wrote:
> >
> > +/**
> > + * struct drm_bus_caps - bus capabilities
> > + * @supported_fmts: array of MEDIA_BUS_FMT_
On Mon, Aug 19, 2019 at 08:01:57AM +, james qian wang (Arm Technology
China) wrote:
> The patch 5d51f6c0da1b: "drm/komeda: Add writeback support" from May
> 23, 2019, leads to the following static checker warning:
>
> drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c:151
>
On Mon, Aug 12, 2019 at 11:23:41AM +, james qian wang (Arm Technology
China) wrote:
> Fixed two -Wunused-but-set-variable warnings:
>
> /arm/linux/display/aosp-4.14-drm-next/drivers/gpu/drm/arm/display/komeda/komeda_kms.c:
> In function ‘komeda_crtc_normalize_zpos’:
>
On Tue, Aug 13, 2019 at 11:08:20AM +, james qian wang (Arm Technology
China) wrote:
> komeda/komeda_pipeline.c: In function 'komeda_component_add':
> komeda/komeda_pipeline.c:212:3: warning: function 'komeda_component_add'
> might be a candidate for 'gnu_printf' format attribute
>
Also update the comment with a reference to the virglrenderer fix.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio/virtgpu_object.c | 44 ++---
1 file changed, 24 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_object.c
drm-misc-fixes-2019-08-22:
Fixes for v5.3-rc6:
- dma fix for omap.
- Make output polling work on komeda.
- Fix bpp computing for AFBC formats in komeda.
- Support the memory-region property in komeda.
The following changes since commit d45331b00ddb179e291766617259261c112db872:
Linux 5.3-rc4
On 22/08/2019 12:09, Boris Brezillon wrote:
> On Thu, 22 Aug 2019 11:29:40 +0200
> Neil Armstrong wrote:
>
> +/**
> + * struct drm_bus_caps - bus capabilities
> + * @supported_fmts: array of MEDIA_BUS_FMT_ formats
> + * @num_supported_fmts: size of the supported_fmts array
>
Hi all,
I noticed that the drm tree has been back merge into the drm-intel
tree. Unfortunately, it seems that the file
drivers/gpu/drm/i915/i915_gem_batch_pool.c has been resurrected.
It was removed in commit
b40d73784ffc ("drm/i915: Replace struct_mutex for batch pool serialisation")
but
On Thu, 22 Aug 2019 11:29:40 +0200
Neil Armstrong wrote:
> >>> +/**
> >>> + * struct drm_bus_caps - bus capabilities
> >>> + * @supported_fmts: array of MEDIA_BUS_FMT_ formats
> >>> + * @num_supported_fmts: size of the supported_fmts array
> >>> + *
> >>> + * Used by the core to negotiate the
On Wed, 2019-08-21 at 19:42 +0200, Guido Günther wrote:
> Hi,
> On Tue, Aug 13, 2019 at 01:07:52PM +0200, Arnd Bergmann wrote:
> > On Tue, Aug 13, 2019 at 12:10 PM Guido Günther wrote:
> > > On Tue, Aug 13, 2019 at 10:08:44AM +0200, Arnd Bergmann wrote:
> > > > On Fri, Aug 9, 2019 at 6:24 PM
On Thu, Aug 22, 2019 at 11:14 AM Christian König
wrote:
>
> Am 21.08.19 um 22:22 schrieb Daniel Vetter:
> > On Wed, Aug 21, 2019 at 10:11 PM Chris Wilson
> > wrote:
> >> Quoting Christian König (2019-08-21 13:31:37)
> >>> Hi everyone,
> >>>
> >>> In previous discussion it surfaced that
On 8/22/19 10:47 AM, Daniel Vetter wrote:
On Thu, Aug 22, 2019 at 9:56 AM Koenig, Christian
wrote:
Am 22.08.19 um 08:49 schrieb Daniel Vetter:
With nouveau fixed all ttm-using drives have the correct nesting of
mmap_sem vs dma_resv, and we can just lock the buffer.
Assuming I didn't screw up
Use drm_atomic_helper_check_plane_state()
to sanity check the plane state.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio/virtgpu_plane.c | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_plane.c
The Vulkan timeline semaphores allow signaling to happen on the point
of the timeline without all of the its dependencies to be created.
The current 2 implementations (AMD/Intel) of the Vulkan spec on top of
the Linux kernel are using a thread to wait on the dependencies of a
given point to
Reported-by: Yann Droneaud
Signed-off-by: Gerd Hoffmann
---
drivers/dma-buf/udmabuf.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c
index 9635897458a0..6c3ec8fcef01 100644
--- a/drivers/dma-buf/udmabuf.c
+++
Signed-off-by: Gerd Hoffmann
Reported-by: Yann Droneaud
---
drivers/dma-buf/udmabuf.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c
index 6c3ec8fcef01..ca1364102b18 100644
--- a/drivers/dma-buf/udmabuf.c
+++
Signed-off-by: Gerd Hoffmann
---
include/uapi/linux/udmabuf.h | 52 ++--
Documentation/driver-api/dma-buf.rst | 8 +
2 files changed, 57 insertions(+), 3 deletions(-)
diff --git a/include/uapi/linux/udmabuf.h b/include/uapi/linux/udmabuf.h
index
Just noticed a bunch of udmabuf tweaks (add documentation & sanity checks)
are still lingering in a local branch. Resending.
Gerd Hoffmann (3):
udmabuf: add documentation
udmabuf: check that __pad is zero
udmabuf: check that flags has no unsupported bits set
include/uapi/linux/udmabuf.h
When modifying panfrost_devfreq_target() to support a device without a
regulator defined I missed the check on the error path. Let's add it.
Reported-by: Dan Carpenter
Fixes: e21dd290881b ("drm/panfrost: Enable devfreq to work without regulator")
Signed-off-by: Steven Price
---
On 22/08/2019 09:48, Boris Brezillon wrote:
> On Thu, 22 Aug 2019 03:55:56 +0300
> Laurent Pinchart wrote:
>
>> Hi Boris,
>>
>> Thank you for the patch.
>>
>> On Thu, Aug 08, 2019 at 05:11:45PM +0200, Boris Brezillon wrote:
>>> This takes the form of various helpers, plus the addition of 2 new
Am 21.08.19 um 22:05 schrieb Daniel Vetter:
On Wed, Aug 21, 2019 at 06:13:27PM +0200, Daniel Vetter wrote:
On Wed, Aug 21, 2019 at 02:31:37PM +0200, Christian König wrote:
Hi everyone,
In previous discussion it surfaced that different drivers use the shared
and explicit fences in the dma_resv
Am 22.08.19 um 10:37 schrieb Christian König:
Am 21.08.19 um 19:35 schrieb Chris Wilson:
Quoting Chris Wilson (2019-08-21 16:24:22)
Quoting Christian König (2019-08-21 13:31:45)
@@ -117,17 +120,10 @@ i915_gem_busy_ioctl(struct drm_device *dev,
void *data,
Hello Steven Price,
This is a semi-automatic email about new static checker warnings.
The patch e21dd290881b: "drm/panfrost: Enable devfreq to work without
regulator" from Aug 16, 2019, leads to the following Smatch complaint:
drivers/gpu/drm/panfrost/panfrost_devfreq.c:56
On Tue, 20 Aug 2019 04:16:34 +0300
Laurent Pinchart wrote:
> The drm_display_info structure contains many fields related to HDMI
> sinks, but none that identifies if a sink compliant with CEA-861 (EDID)
> shall be treated as an HDMI sink or a DVI sink. Add such a flag, and
> populate it
Am 21.08.19 um 22:22 schrieb Daniel Vetter:
On Wed, Aug 21, 2019 at 10:11 PM Chris Wilson wrote:
Quoting Christian König (2019-08-21 13:31:37)
Hi everyone,
In previous discussion it surfaced that different drivers use the shared and
explicit fences in the dma_resv object with different
On Tue, 20 Aug 2019 04:16:33 +0300
Laurent Pinchart wrote:
> drm_connector.c contains a map of connector types (DRM_MODE_CONNECTOR_*)
> to name strings, but doesn't expose it. This leads to drivers having to
> store a similar map.
>
> Add a new drm_get_connector_type_name() helper function that
Hi Julien,
On 22/08/2019 11:03, Julien Masson wrote:
> This patch introduce new enum which contains all VPU family (GXBB,
> GXL, GXM and G12A).
> This enum is used to detect the VPU compatible with the device.
>
> We only need to set .data to the corresponding enum in the device
> table, no need
On Tue, 20 Aug 2019 04:16:32 +0300
Laurent Pinchart wrote:
> The hdmi_avi_infoframe_init() never needs to return an error, change its
> return type to void.
>
> Signed-off-by: Laurent Pinchart
> Reviewed-by: Andrzej Hajda
Reviewed-by: Boris Brezillon
> ---
> Changes since v1:
>
> -
Not needed any more for remove_conflicting_pci_framebuffers calls.
Signed-off-by: Gerd Hoffmann
---
include/drm/drm_fb_helper.h | 4 +---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 2 +-
drivers/gpu/drm/bochs/bochs_drv.c | 2 +-
drivers/gpu/drm/cirrus/cirrus.c | 2 +-
No need for a home-grown version, the generic helper should work just
fine. It also handles vgacon removal these days, see commit
1c74ca7a1a9a ("drm/fb-helper: call vga_remove_vgacon automatically."),
so that can be removed too.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/i915/i915_drv.c
Gerd Hoffmann (3):
fbdev: drop res_id parameter from remove_conflicting_pci_framebuffers
drm: drop resource_id parameter from
drm_fb_helper_remove_conflicting_pci_framebuffers
drm/i915: switch to drm_fb_helper_remove_conflicting_pci_framebuffers
include/drm/drm_fb_helper.h
Since commit b0e999c95581 ("fbdev: list all pci memory bars as
conflicting apertures") the parameter was used for some sanity checks
only, to make sure we detect any issues with the new approach to just
list all memory bars as apertures.
No issues turned up so far, so continue to cleanup: Drop
Hi Dave & Daniel -
drm-intel-fixes-2019-08-22:
drm/i915 fixes for v5.3-rc6:
- fix hardware state readout for 10 bpc HDMI
BR,
Jani.
The following changes since commit d1abaeb3be7b5fa6d7a1fbbd2e14e3310005c4c1:
Linux 5.3-rc5 (2019-08-18 14:31:08 -0700)
are available in the Git repository at:
This patch introduce new enum which contains all VPU family (GXBB,
GXL, GXM and G12A).
This enum is used to detect the VPU compatible with the device.
We only need to set .data to the corresponding enum in the device
table, no need to check .compatible string anymore.
Signed-off-by: Julien
On Wed, 21 Aug 2019 23:14:56 +0300
Laurent Pinchart wrote:
> > +int
> > +drm_atomic_add_encoder_bridges(struct drm_atomic_state *state,
> > + struct drm_encoder *encoder)
> > +{
> > + struct drm_bridge_state *bridge_state;
> > + struct drm_bridge *bridge;
> > +
> > +
https://bugs.freedesktop.org/show_bug.cgi?id=110888
--- Comment #3 from freedesktop35 ---
Bug 110888 - 5.0.21 just occurred in my computer and I was worried about this
that what I should do. Then i read your article. Source
https://www.australian-writings.org/ gave me solution to sort out this
On Thu, Aug 22, 2019 at 9:56 AM Koenig, Christian
wrote:
> Am 22.08.19 um 08:49 schrieb Daniel Vetter:
> > With nouveau fixed all ttm-using drives have the correct nesting of
> > mmap_sem vs dma_resv, and we can just lock the buffer.
> >
> > Assuming I didn't screw up anything with my audit of
101 - 200 of 246 matches
Mail list logo
