On Thu, Aug 22, 2019 at 8:42 AM Thomas Hellström (VMware)
wrote:
>
> 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
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
> framebuffers).
>
> Accessing any vga ioport will switch the qxl device into vga mode.
> The qxl
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
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
> >
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
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
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,
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,
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
No need to store these values. bpp is fixed (32) anyway.
We lookup the stride from struct drm_framebuffer if needed.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/bochs/bochs.h | 2 --
drivers/gpu/drm/bochs/bochs_hw.c | 8 +++-
drivers/gpu/drm/bochs/bochs_kms.c | 2 +-
3 files
Not needed, writing to VBE_DISPI_INDEX_VIRT_HEIGHT has no effect anyway.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/bochs/bochs.h| 1 -
drivers/gpu/drm/bochs/bochs_hw.c | 8 ++--
2 files changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/bochs/bochs.h
Call it from bochs_hw_setfb().
This also allows to make bochs_hw_setformat static.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/bochs/bochs.h | 2 --
drivers/gpu/drm/bochs/bochs_hw.c | 5 +++--
drivers/gpu/drm/bochs/bochs_kms.c | 1 -
3 files changed, 3 insertions(+), 5 deletions(-)
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 wait optimization (Thomas)
- Use
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
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.
> >
> >
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
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();
> +
> +
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
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
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, >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));
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
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
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
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:
-
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
> > ---
> >
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
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
Also rename bochs_hw_setbase to bochs_hw_setfb,
we have to set more than just the base address.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/bochs/bochs.h | 5 +++--
drivers/gpu/drm/bochs/bochs_hw.c | 24 +++-
drivers/gpu/drm/bochs/bochs_kms.c | 11 +++
3
Gerd Hoffmann (4):
drm/bochs: pass framebuffer to bochs_hw_setbase
drm/bochs: drop yres_virtual from struct bochs_device
drm/bochs: drop stride and bpp from struct bochs_device
drm/bochs: move bochs_hw_setformat() call
drivers/gpu/drm/bochs/bochs.h | 10 +++-
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
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
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
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
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
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
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/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:
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
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
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(-)
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;
> > -
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
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 +++
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
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:
>
> -
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
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 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
>
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_
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 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
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
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 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
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
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
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
---
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
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
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
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,
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
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 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
>
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
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 ++
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
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 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;
> > +
> > +
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
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
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
>
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
---
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
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
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 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
On Tue, 20 Aug 2019 04:16:38 +0300
Laurent Pinchart wrote:
> The dumb-vga-dac driver can support simple DRM bridges without being
> limited to VGA DACs. Rename it to simple-bridge.
>
> Signed-off-by: Laurent Pinchart
> Reviewed-by: Andrzej Hajda
Reviewed-by: Boris Brezillon
> ---
>
On Thu, Aug 22, 2019 at 5:26 AM Ville Syrjälä
wrote:
>
> 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(+)
> >
> >
On Tue, 20 Aug 2019 04:16:40 +0300
Laurent Pinchart wrote:
> If an enable GPIO is declared in the firmware, assert it when enabling
> the bridge and deassert it when disabling it.
>
> Signed-off-by: Laurent Pinchart
> Reviewed-by: Andrzej Hajda
> Reviewed-by: Stefan Agner
Reviewed-by: Boris
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
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index 45bfac9e3af7..970194958257 100644
---
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
Hi Jacopo,
On Thu, Aug 22, 2019 at 03:01:46PM +0200, Jacopo Mondi wrote:
> On Tue, Aug 20, 2019 at 08:34:44PM +0300, Laurent Pinchart wrote:
> > 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 Tue, 20 Aug 2019 04:16:35 +0300
Laurent Pinchart wrote:
> To support implementation of DRM connectors on top of DRM bridges
> instead of by bridges, the drm_bridge needs to expose new operations and
> data:
>
> - Output detection, hot-plug notification, mode retrieval and EDID
> retrieval
Hi Julien,
On 22/08/2019 16:43, 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:42 +0300
Laurent Pinchart wrote:
> + /*
> + * Get the HPD GPIO for DVI and HDMI connectors. If the GPIO can provide
> + * interrupts, register an interrupt handler.
> + */
> + if (type == DRM_MODE_CONNECTOR_DVII ||
> + type ==
On Tue, 20 Aug 2019 04:16:45 +0300
Laurent Pinchart wrote:
> The drmP.h header is deprecated, replace it with the headers
> specifically needed by the tfp410 driver. While at it, replace the DRM
> print macros with dev_info() and dev_err() instead of including
> drm_print.h
Looks like
https://bugs.freedesktop.org/show_bug.cgi?id=110865
--- Comment #17 from Alex Deucher ---
Note that it will only work if your monitors have identical timing.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel
1 - 100 of 246 matches
Mail list logo
