On Wed, 21 Aug 2019, Daniel Vetter wrote:
> On Wed, Aug 21, 2019 at 12:43:12PM +0300, Jani Nikula wrote:
>> The module is drm_kms_helper, not drm_kms_firmware.
>>
>> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=204549
>> Reported-by: Göran Uddeborg
>> Fixes: ac6c35a4d8c7 ("drm: add back
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
> > structs:
> > * drm_bus_caps: describe the bus capab
Quoting Daniel Vetter (2019-08-22 07:54:57)
> +#if IS_ENABLED(CONFIG_LOCKDEP)
> +static void dma_resv_lockdep(void)
> +{
> + struct mm_struct *mm = mm_alloc();
> + struct dma_resv obj;
> +
> + if (!mm)
> + return;
> +
> + dma_resv_init(&obj);
> +
> + down
Am 22.08.19 um 08:54 schrieb Daniel Vetter:
> 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 ch
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 course.
>
> v2:
> - Dont forget wu_mutex (Christian König)
> - Keep the
On Thu, 22 Aug 2019 03:12:07 +0300
Laurent Pinchart wrote:
> Hi Boris,
>
> Thank you for the patch.
>
> On Thu, Aug 08, 2019 at 05:11:43PM +0200, Boris Brezillon wrote:
> > So that bridge drivers have a way to check/reject an atomic operation.
> > The drm_atomic_bridge_chain_check() (which is j
Ville or Rodrigo,
Can one of you either merge this patch or Ack it so that I can merge this?
Thank you!
Regards,
Hans
On 8/14/19 12:45 PM, Dariusz Marcinkiewicz wrote:
> Use the new cec_notifier_conn_(un)register() functions to
> (un)register the notifier for the HDMI connector, and fi
Reviewed-by: Dave Airlie
On Thu, Aug 22, 2019 at 4:59 PM Gerd Hoffmann wrote:
>
> On Mon, Aug 05, 2019 at 12:54:01PM +0200, Gerd Hoffmann wrote:
> > qxl has two modes: "native" (used by the drm driver) and "vga" (vga
> > compatibility mode, typically used for boot display and firmware
> > frameb
On Thu, 22 Aug 2019 03:17:32 +0300
Laurent Pinchart wrote:
> Hi Boris,
>
> Thank you for the patch.
>
> On Thu, Aug 08, 2019 at 05:11:44PM +0200, Boris Brezillon wrote:
> > Will be useful for bridge drivers that want to do bus format
> > negotiation with their neighbours.
> >
> > Signed-off-by
Adding Benjamin Gaignard.
Benjamin, can you take a look at this and Ack it (or merge it if you prefer) and
ideally test it as well. This is the only patch in this series that I could not
test since I don't have any hardware.
Regards,
Hans
On 8/14/19 12:45 PM, Dariusz Marcinkiewicz wrote
On Thu, 22 Aug 2019 03:32:10 +0300
Laurent Pinchart wrote:
> Hi Boris,
>
> Thank you for the patch.
>
> On Thu, Aug 08, 2019 at 05:11:48PM +0200, Boris Brezillon wrote:
> > The SN75LVDS83 bridge support several input formats except the input
> > format is directly related to the expected output
On 8/21/19 6:34 PM, Daniel Vetter wrote:
On Wed, Aug 21, 2019 at 05:54:27PM +0200, Thomas Hellström (VMware) wrote:
On 8/20/19 4:53 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 comma
On 8/21/19 9:51 PM, Daniel Vetter wrote:
On Wed, Aug 21, 2019 at 08:27:59PM +0200, Thomas Hellström (VMware) wrote:
On 8/21/19 8:11 PM, Daniel Vetter wrote:
On Wed, Aug 21, 2019 at 7:06 PM Thomas Hellström (VMware)
wrote:
On 8/21/19 6:34 PM, Daniel Vetter wrote:
On Wed, Aug 21, 2019 at 05:54
On 8/21/19 4:09 PM, Daniel Vetter wrote:
On Wed, Aug 21, 2019 at 2:47 PM Thomas Hellström (VMware)
wrote:
On 8/21/19 2:40 PM, Thomas Hellström (VMware) wrote:
On 8/20/19 4:53 PM, Daniel Vetter wrote:
With nouveau fixed all ttm-using drives have the correct nesting of
mmap_sem vs dma_resv, and
On 8/21/19 4:47 PM, Daniel Vetter wrote:
On Wed, Aug 21, 2019 at 4:27 PM Thomas Hellström (VMware)
wrote:
On 8/21/19 4:09 PM, Daniel Vetter wrote:
On Wed, Aug 21, 2019 at 2:47 PM Thomas Hellström (VMware)
wrote:
On 8/21/19 2:40 PM, Thomas Hellström (VMware) wrote:
On 8/20/19 4:53 PM, Daniel
Thanks Michael. See my reply inline to some of your comments.
> -Original Message-
> From: Michael Kelley
> Sent: Monday, August 19, 2019 6:41 AM
> To: Wei Hu ; rdun...@infradead.org; shc_w...@mail.ru;
> > - msg.dirt.rect[0].x1 = 0;
> > - msg.dirt.rect[0].y1 = 0;
> > - msg.dirt.rec
From: Wei Hu Sent: Wednesday, August 21, 2019 4:11 AM
>
> Beginning from Windows 10 RS5+, VM screen resolution is obtained from host.
> The "video=hyperv_fb" boot time option is not needed, but still can be
> used to overwrite what the host specifies. The VM resolution on the host
> could be set
On 8/21/19 2:40 PM, Thomas Hellström (VMware) wrote:
On 8/20/19 4:53 PM, Daniel Vetter wrote:
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 course.
Signed-off-by: D
On 8/20/19 4:53 PM, Daniel Vetter wrote:
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 course.
Signed-off-by: Daniel Vetter
Cc: Christian Koenig
Cc: Huang Rui
Cc:
Alex, Ville/Rodrigo, Ben,
Can you (hopefully) Ack this patch so that I can merge it?
Thank you!
Hans
On 8/14/19 12:44 PM, Dariusz Marcinkiewicz wrote:
> Pass the connector info to the CEC adapter. This makes it possible
> to associate the CEC adapter with the corresponding drm connector
On 8/21/19 5:33 PM, Daniel Vetter wrote:
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 course.
v2:
- Dont forget wu_mutex (Christian König)
- Keep the mmap_sem-less
On 8/20/19 4:53 PM, Daniel Vetter wrote:
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 course.
Signed-off-by: Daniel Vetter
Cc: Christian Koenig
Cc: Huang Rui
Cc:
On 8/21/19 5:14 PM, Daniel Vetter wrote:
On Wed, Aug 21, 2019 at 5:03 PM Thomas Hellström (VMware)
wrote:
On 8/21/19 4:47 PM, Daniel Vetter wrote:
On Wed, Aug 21, 2019 at 4:27 PM Thomas Hellström (VMware)
wrote:
On 8/21/19 4:09 PM, Daniel Vetter wrote:
On Wed, Aug 21, 2019 at 2:47 PM Thomas
From: Hariprasad Kelam
fix below defect reported by coverity
In exynos_dsi_read_from_fifo: A value assigned to a variable is never
used.
fix Defect:1451826
Signed-off-by: Hariprasad Kelam
---
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
dif
On Wed, Aug 21, 2019 at 05:41:51PM +0200, Daniel Vetter wrote:
> > Hm, I thought the page table locks we're holding there already prevent any
> > sleeping, so would be redundant? But reading through code I think that's
> > not guaranteed, so yeah makes sense to add it for invalidate_range_end
> >
Since version 4 of eLCDIF, there are some registers that can do
transformations on the input data, like re-arranging the pixel
components. By doing that, we can support more pixel formats.
This patch adds support for X/ABGR and RGBX/A. Although, the local alpha
is not supported by eLCDIF, the alpha
On 8/20/19 4:53 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 al
On 8/21/19 5:22 PM, Daniel Vetter wrote:
On Wed, Aug 21, 2019 at 5:19 PM Thomas Hellström (VMware)
wrote:
On 8/21/19 5:14 PM, Daniel Vetter wrote:
On Wed, Aug 21, 2019 at 5:03 PM Thomas Hellström (VMware)
wrote:
On 8/21/19 4:47 PM, Daniel Vetter wrote:
On Wed, Aug 21, 2019 at 4:27 PM Thomas
On Wed, Aug 21, 2019 at 03:34:12PM +, Kuehling, Felix wrote:
>
> On 2019-08-20 8:36 a.m., Jason Gunthorpe wrote:
> > On Tue, Aug 20, 2019 at 11:45:54AM +1000, Stephen Rothwell wrote:
> >> Hi all,
> >>
> >> On Mon, 19 Aug 2019 18:34:41 -0700 Randy Dunlap
> >> wrote:
> >>> On 8/19/19 2:18 AM,
Hi,
On Wed, Aug 21, 2019 at 09:32:26PM +0300, Laurent Pinchart wrote:
> When refactoring port lookup for DSS outputs, commit d17eb4537a7e
> ("drm/omap: Factor out common init/cleanup code for output devices")
> incorrectly hardcoded usage of DT port 0. This breaks operation for SDI
> (which uses t
On 8/21/19 4:10 PM, Daniel Vetter wrote:
On Wed, Aug 21, 2019 at 3:16 PM Thomas Hellström (VMware)
wrote:
On 8/20/19 4:53 PM, Daniel Vetter wrote:
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
On Tue, Aug 06, 2019 at 08:15:37PM -0300, Jason Gunthorpe wrote:
> This series is already entangled with patches in the hmm & RDMA tree and
> will require some git topic branches for the RDMA ODP stuff. I intend for
> it to go through the hmm tree.
The RDMA related patches have been applied to t
On Thu, 22 Aug 2019 03:36:32 +0300
Laurent Pinchart wrote:
> Hi Boris,
>
> Thank you for the patch.
>
> On Thu, Aug 08, 2019 at 05:11:49PM +0200, Boris Brezillon wrote:
> > Add a new entry for the Toshiba LTA089AC29000 panel.
> >
> > Signed-off-by: Boris Brezillon
> > ---
> > .../display/pan
On 8/21/19 8:11 PM, Daniel Vetter wrote:
On Wed, Aug 21, 2019 at 7:06 PM Thomas Hellström (VMware)
wrote:
On 8/21/19 6:34 PM, Daniel Vetter wrote:
On Wed, Aug 21, 2019 at 05:54:27PM +0200, Thomas Hellström (VMware) wrote:
On 8/20/19 4:53 PM, Daniel Vetter wrote:
Full audit of everyone:
- i9
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 rcu barrier here you're not syncing to new clients at all.
I don't think this
On Thu, 22 Aug 2019 03:02:17 +0300
Laurent Pinchart wrote:
> > }
> > EXPORT_SYMBOL(drm_atomic_bridge_chain_post_disable);
> > @@ -518,10 +535,18 @@ void drm_atomic_bridge_chain_pre_enable(struct
> > drm_encoder *encoder,
> >
> > list_for_each_entry_reverse(bridge, &encoder->bridge_chain,
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,
busy_check_writer(rcu_dereference(obj->base.resv->fence_excl));
Am 21.08.19 um 18:24 schrieb Chris Wilson:
Quoting Christian König (2019-08-21 13:31:40)
Try to recycle an dma_fence_array object by dropping the last
reference to it without freeing it.
Signed-off-by: Christian König
---
drivers/dma-buf/dma-fence-array.c | 27 +++
i
On Thu, Aug 22, 2019 at 10:16 AM Jason Gunthorpe wrote:
>
> On Wed, Aug 21, 2019 at 05:41:51PM +0200, Daniel Vetter wrote:
>
> > > Hm, I thought the page table locks we're holding there already prevent any
> > > sleeping, so would be redundant? But reading through code I think that's
> > > not gua
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 cou
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 pr
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;
> > +
> > +
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 Masson
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 th
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 +-
dr
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
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:
>
> - Removed
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: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
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 meani
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 according
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 panfrost_devfreq_
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,
busy_check_writer(rcu_dereference(obj
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
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
>>
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
---
drivers/gpu/drm/
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 46b6532ed855.
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
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
+++ b/drivers/dma-buf/udmabuf.
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
+++ b/drivers/dma-buf/udmabuf
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 materi
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
b/drivers/gpu/drm/virti
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
Hi Geert,
On Wed, Aug 21, 2019 at 02:16:02PM +0200, Geert Uytterhoeven wrote:
> On Sat, Jul 6, 2019 at 4:07 PM Jacopo Mondi wrote:
> > Update the 'vsps' property in the R-Car Gen3 SoC device tree files to
> > match what's in in the documentation example.
>
> double in (no worries, I'll fix that u
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 different
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 Guido
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 bus
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 ha
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
> +
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 (201
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
b/drivers/gpu/drm/v
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
> [-Wsuggest
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’:
> /arm/linux/display/aosp
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
> kom
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_ form
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 platform
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
dif
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
---
drivers
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.
> >
> > S
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 i
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 definitio
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 ++
drivers/gpu/drm/i915/display/intel_disp
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 ++
drivers/gpu/dr
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 a/drivers/misc/mei/hdcp/me
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 a/
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 hdcp_port_data
I915 will convert it's port value into ddi index defiend by ME FW
and will pass it as part of hdcp_port_data structure.
Hence we are exposing the enum mei_fw_ddi to I915 through
i915_mei_interface.h.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/display/intel_hdcp.c | 15 +-
driv
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
>>
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
> ---
> drivers/gpu/drm/virti
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.
v2:
intel_display.h is included in intel_hdcp.h
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/display/intel_bios.h
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 t
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 Haj
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 ---
> in
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:
Re
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
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 ;
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
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 Gen
1 - 100 of 250 matches
Mail list logo
