https://bugs.freedesktop.org/show_bug.cgi?id=105880
--- Comment #45 from Pontus Gråskæg ---
Created attachment 143261
--> https://bugs.freedesktop.org/attachment.cgi?id=143261=edit
dmesg 5.0.0-rc4 dc=1
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=105880
--- Comment #44 from Pontus Gråskæg ---
Created attachment 143260
--> https://bugs.freedesktop.org/attachment.cgi?id=143260=edit
dmesg 5.0.0-rc4 dc=0
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=105880
--- Comment #43 from Pontus Gråskæg ---
(In reply to Przemek from comment #42)
> Good news,
> on amd-staging-drm-next (5.0.0-rc1+) vga connector works without a hitch. I
> don't have dvi connector on my netbook so I am unable to test this one.
Den 30.01.2019 10.43, skrev Gerd Hoffmann:
> Drop the dummy ttm backend implementation, add a real one for
> TTM_PL_FLAG_TT objects. The bin/unbind callbacks will call
> virtio_gpu_object_{attach,detach}, to update the object state
> on the host side, instead of invoking those calls from the
>
The function was unconditionally returning 0, and a caller would have to
rely on the returned fence pointer being NULL to detect errors. However,
the function vmw_execbuf_copy_fence_user() would expect a non-zero error
code in that case and would BUG otherwise.
So make sure we return a proper
if vmw_execbuf_fence_commands() fails, The handle value will be
uninitialized and a bogus fence handle might be copied to user-space.
Fixes: 2724b2d54cda: ("drm/vmwgfx: Use new validation interface for the
modesetting code v2")
Reported-by: Dan Carpenter
Signed-off-by: Thomas Hellstrom
https://bugs.freedesktop.org/show_bug.cgi?id=108889
Chris Wilson changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://bugs.freedesktop.org/show_bug.cgi?id=109493
Chris Wilson changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://bugs.freedesktop.org/show_bug.cgi?id=105880
--- Comment #42 from Przemek ---
Good news,
on amd-staging-drm-next (5.0.0-rc1+) vga connector works without a hitch. I
don't have dvi connector on my netbook so I am unable to test this one.
Thanks,
Przemek.
--
You are receiving this mail
Convert to use vm_insert_range() to map range of kernel
memory to user vma.
Signed-off-by: Souptick Joarder
---
drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 17 ++---
1 file changed, 2 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
On Wed, Jan 30, 2019 at 01:00:02PM -0700, Logan Gunthorpe wrote:
> We never changed SGLs. We still use them to pass p2pdma pages, only we
> need to be a bit careful where we send the entire SGL. I see no reason
> why we can't continue to be careful once their in userspace if there's
> something
Previouly drivers have their own way of mapping range of
kernel pages/memory into user vma and this was done by
invoking vm_insert_page() within a loop.
As this pattern is common across different drivers, it can
be generalized by creating new functions and use it across
the drivers.
On Wed, Jan 30, 2019 at 8:07 PM Brajeswar Ghosh
wrote:
>
> On Wed, Dec 26, 2018 at 3:09 PM Laurent Pinchart
> wrote:
> >
> > Hi Brajeswar,
> >
> > Thank you for the patch.
> >
> > On Monday, 24 December 2018 16:32:18 EET Brajeswar Ghosh wrote:
> > > Remove drm/drm_panel.h which is included more
On 2019-01-30 10:26 a.m., Christoph Hellwig wrote:
> On Wed, Jan 30, 2019 at 10:55:43AM -0500, Jerome Glisse wrote:
>> Even outside GPU driver, device driver like RDMA just want to share their
>> doorbell to other device and they do not want to see those doorbell page
>> use in direct I/O or
Convert to use vm_insert_range() to map range of kernel
memory to user vma.
Signed-off-by: Souptick Joarder
Reviewed-by: Oleksandr Andrushchenko
---
drivers/gpu/drm/xen/xen_drm_front_gem.c | 18 +-
1 file changed, 5 insertions(+), 13 deletions(-)
diff --git
On Wed, Jan 30, 2019 at 11:13:11AM -0700, Logan Gunthorpe wrote:
>
>
> On 2019-01-30 10:44 a.m., Jason Gunthorpe wrote:
> > I don't see why a special case with a VMA is really that different.
>
> Well one *really* big difference is the VMA changes necessarily expose
> specialized new
Currently, the Kbuild core manipulates header search paths in a crazy
way [1].
To fix this mess, I want all Makefiles to add explicit $(srctree)/ to
the search paths in the srctree. Some Makefiles are already written in
that way, but not all. The goal of this work is to make the notation
One of the more common cases of allocation size calculations is finding
the size of a structure that has a zero-sized array at the end, along
with memory for some number of elements for that array. For example:
struct foo {
int stuff;
void *entry[];
};
instance = kzalloc(sizeof(struct
On 2019-01-30 12:38 p.m., Jason Gunthorpe wrote:
> On Wed, Jan 30, 2019 at 02:22:34PM -0500, Jerome Glisse wrote:
>
>> For GPU it would not work, GPU might want to use main memory (because
>> it is running out of BAR space) it is a lot easier if the p2p_map
>> callback calls the right dma map
On 2019-01-30 12:59 p.m., Jason Gunthorpe wrote:
> On Wed, Jan 30, 2019 at 12:45:46PM -0700, Logan Gunthorpe wrote:
>>
>>
>> On 2019-01-30 12:06 p.m., Jason Gunthorpe wrote:
Way less problems than not having struct page for doing anything
non-trivial. If you map the BAR to userspace
On 2019-01-29 9:18 p.m., Jason Gunthorpe wrote:
> Every attempt to give BAR memory to struct page has run into major
> trouble, IMHO, so I like that this approach avoids that.
>
> And if you don't have struct page then the only kernel object left to
> hang meta data off is the VMA itself.
>
>
From: Quentin Schulz
DP 1.4 introduced a DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT bit in
DP_TRAINING_AUX_RD_INTERVAL register. If set, DPCD registers from
DP_DPCD_REV to DP_ADAPTER_CAP should be retrieved starting from
DP_DPCD_REV_EXTENDED. All registers are copied except DP_DPCD_REV,
On Wed, Jan 30, 2019 at 09:00:06AM +0100, Christoph Hellwig wrote:
> On Wed, Jan 30, 2019 at 04:18:48AM +, Jason Gunthorpe wrote:
> > Every attempt to give BAR memory to struct page has run into major
> > trouble, IMHO, so I like that this approach avoids that.
>
> Way less problems than not
On Thu, Jan 31, 2019 at 08:38:12AM +0530, Souptick Joarder wrote:
> Previouly drivers have their own way of mapping range of
> kernel pages/memory into user vma and this was done by
> invoking vm_insert_page() within a loop.
>
> As this pattern is common across different drivers, it can
> be
On Wed, Jan 30, 2019 at 05:47:05PM -0500, Jerome Glisse wrote:
> On Wed, Jan 30, 2019 at 10:33:04PM +, Jason Gunthorpe wrote:
> > On Wed, Jan 30, 2019 at 05:30:27PM -0500, Jerome Glisse wrote:
> >
> > > > What is the problem in the HMM mirror that it needs this restriction?
> > >
> > > No
On Wed, Jan 30, 2019 at 02:01:35PM -0700, Logan Gunthorpe wrote:
> And I feel the GUP->SGL->DMA flow should still be what we are aiming
> for. Even if we need a special GUP for special pages, and a special DMA
> map; and the SGL still has to be homogenous
*shrug* so what if the special GUP
On Wed, Jan 30, 2019 at 03:43:32PM -0500, Jerome Glisse wrote:
> On Wed, Jan 30, 2019 at 08:11:19PM +, Jason Gunthorpe wrote:
> > On Wed, Jan 30, 2019 at 01:00:02PM -0700, Logan Gunthorpe wrote:
> >
> > > We never changed SGLs. We still use them to pass p2pdma pages, only we
> > > need to be
Heavily based on the Armada 510 (Dove) support.
Tested to work well with Display 1 and Display 2 clocks driving the internal
panel on the OLPC XO 1.75 laptop. Some tweaking might be required if anyone
wants to use it with a MIPI or HDMI encoder.
The data sheet is not available, but James Cameron
On Wed, Jan 30, 2019 at 12:45:46PM -0700, Logan Gunthorpe wrote:
>
>
> On 2019-01-30 12:06 p.m., Jason Gunthorpe wrote:
> >> Way less problems than not having struct page for doing anything
> >> non-trivial. If you map the BAR to userspace with remap_pfn_range
> >> and friends the mapping is
On Wed, Jan 30, 2019 at 03:52:13PM -0700, Logan Gunthorpe wrote:
>
>
> On 2019-01-30 2:50 p.m., Jason Gunthorpe wrote:
> > On Wed, Jan 30, 2019 at 02:01:35PM -0700, Logan Gunthorpe wrote:
> >
> >> And I feel the GUP->SGL->DMA flow should still be what we are aiming
> >> for. Even if we need a
Updated firmware for Cadence MHDP8546 DP bridge.
Release version: 1.2.15
---
cadence/mhdp8546.bin | Bin 131072 -> 131072 bytes
1 file changed, 0 insertions(+), 0 deletions(-)
diff --git a/cadence/mhdp8546.bin b/cadence/mhdp8546.bin
index
On 2019-01-30 10:44 a.m., Jason Gunthorpe wrote:
> I don't see why a special case with a VMA is really that different.
Well one *really* big difference is the VMA changes necessarily expose
specialized new functionality to userspace which has to be supported
forever and may be difficult to
From: Quentin Schulz
This adds support for Cadence MHDP DPI to DP bridge.
Basically, it takes a DPI stream as input and output it encoded in DP
format. It supports SST and MST modes.
Changes made in the low level driver (cdn-dp-reg.*):
- moved it to from drivers/gpu/drm/rockchip to
On Wed, Jan 30, 2019 at 09:02:08AM +0100, Christoph Hellwig wrote:
> On Tue, Jan 29, 2019 at 08:58:35PM +, Jason Gunthorpe wrote:
> > On Tue, Jan 29, 2019 at 01:39:49PM -0700, Logan Gunthorpe wrote:
> >
> > > implement the mapping. And I don't think we should have 'special' vma's
> > > for
On Wed, Jan 30, 2019 at 06:26:53PM +0100, Christoph Hellwig wrote:
> On Wed, Jan 30, 2019 at 10:55:43AM -0500, Jerome Glisse wrote:
> > Even outside GPU driver, device driver like RDMA just want to share their
> > doorbell to other device and they do not want to see those doorbell page
> > use in
On 1/30/19 10:35 AM, Daniel Vetter wrote:
> On Tue, Jan 29, 2019 at 02:20:06PM -0600, Gustavo A. R. Silva wrote:
>> In preparation to enabling -Wimplicit-fallthrough, mark switch cases
>> where we are expecting to fall through.
>>
>> This patch fixes the following warnings:
>>
>>
On 2019-01-30 2:50 p.m., Jason Gunthorpe wrote:
> On Wed, Jan 30, 2019 at 02:01:35PM -0700, Logan Gunthorpe wrote:
>
>> And I feel the GUP->SGL->DMA flow should still be what we are aiming
>> for. Even if we need a special GUP for special pages, and a special DMA
>> map; and the SGL still has
From: Quentin Schulz
Document the bindings used for the Cadence MHDP DPI/DP bridge.
Signed-off-by: Quentin Schulz
Signed-off-by: Damian Kos
Reviewed-by: Rob Herring
---
.../bindings/display/bridge/cdns,mhdp.txt | 47 +++
1 file changed, 47 insertions(+)
create mode
On 2019-01-30 12:22 p.m., Jerome Glisse wrote:
> On Wed, Jan 30, 2019 at 06:56:59PM +, Jason Gunthorpe wrote:
>> On Wed, Jan 30, 2019 at 10:17:27AM -0700, Logan Gunthorpe wrote:
>>>
>>>
>>> On 2019-01-29 9:18 p.m., Jason Gunthorpe wrote:
Every attempt to give BAR memory to struct page
On Fri, Dec 21, 2018 at 6:06 PM Souptick Joarder wrote:
>
> On Fri, Dec 21, 2018 at 2:49 PM Brajeswar Ghosh
> wrote:
> >
> > Remove hwmgr_ppt.h which is included more than once
> >
> > Signed-off-by: Brajeswar Ghosh
> > ---
> Acked-by: Souptick Joarder
If no further comment, can we get this
On Wed, Jan 30, 2019 at 12:48:33PM -0700, Logan Gunthorpe wrote:
>
>
> On 2019-01-30 12:19 p.m., Jason Gunthorpe wrote:
> > On Wed, Jan 30, 2019 at 11:13:11AM -0700, Logan Gunthorpe wrote:
> >>
> >>
> >> On 2019-01-30 10:44 a.m., Jason Gunthorpe wrote:
> >>> I don't see why a special case with a
On 2019-01-30 12:06 p.m., Jason Gunthorpe wrote:
>> Way less problems than not having struct page for doing anything
>> non-trivial. If you map the BAR to userspace with remap_pfn_range
>> and friends the mapping is indeed very simple. But any operation
>> that expects a page structure, which
Hello!
This is the series of patches that will add support for the Cadence's DPI/DP
bridge. Please note that this is a preliminary version of the driver and there
will be more patches in the future with updates, fixes and improvements.
Please keep that in mind when looking at FIXME/TODO/XXX
- Extracted common fields from cdn_dp_device to a new cdns_mhdp_device
structure which will be used by two separate drivers later on.
- Moved some datatypes (audio_format, audio_info, vic_pxl_encoding_format,
video_info) from cdn-dp-core.c to cdn-dp-reg.h.
- Changed prefixes from cdn_dp to
On Wed, Jan 30, 2019 at 10:17:27AM -0700, Logan Gunthorpe wrote:
>
>
> On 2019-01-29 9:18 p.m., Jason Gunthorpe wrote:
> > Every attempt to give BAR memory to struct page has run into major
> > trouble, IMHO, so I like that this approach avoids that.
> >
> > And if you don't have struct page
On Wed, Dec 26, 2018 at 3:09 PM Laurent Pinchart
wrote:
>
> Hi Brajeswar,
>
> Thank you for the patch.
>
> On Monday, 24 December 2018 16:32:18 EET Brajeswar Ghosh wrote:
> > Remove drm/drm_panel.h which is included more than once
> >
> > Signed-off-by: Brajeswar Ghosh
> > ---
> >
Currently dsi_display_init_dsi() calls dss_pll_enable() but it is not
paired with dss_pll_disable() in dsi_display_uninit_dsi(). This leaves
the DSS clocks enabled when the display is blanked wasting about extra
5mW of power while idle.
Let's fix this by setting a dsi->disconnect_lanes flag and
On Wed, Jan 30, 2019 at 04:45:25PM -0500, Jerome Glisse wrote:
> On Wed, Jan 30, 2019 at 08:50:00PM +, Jason Gunthorpe wrote:
> > On Wed, Jan 30, 2019 at 03:43:32PM -0500, Jerome Glisse wrote:
> > > On Wed, Jan 30, 2019 at 08:11:19PM +, Jason Gunthorpe wrote:
> > > > On Wed, Jan 30, 2019
On Wed, Jan 30, 2019 at 05:30:27PM -0500, Jerome Glisse wrote:
> > What is the problem in the HMM mirror that it needs this restriction?
>
> No restriction at all here. I think i just wasn't understood.
Are you are talking about from the exporting side - where the thing
creating the VMA can
On 2019-01-30 12:19 p.m., Jason Gunthorpe wrote:
> On Wed, Jan 30, 2019 at 11:13:11AM -0700, Logan Gunthorpe wrote:
>>
>>
>> On 2019-01-30 10:44 a.m., Jason Gunthorpe wrote:
>>> I don't see why a special case with a VMA is really that different.
>>
>> Well one *really* big difference is the VMA
Previouly drivers have their own way of mapping range of
kernel pages/memory into user vma and this was done by
invoking vm_insert_page() within a loop.
As this pattern is common across different drivers, it can
be generalized by creating new functions and use it across
the drivers.
On Wed, Jan 30, 2019 at 02:22:34PM -0500, Jerome Glisse wrote:
> For GPU it would not work, GPU might want to use main memory (because
> it is running out of BAR space) it is a lot easier if the p2p_map
> callback calls the right dma map function (for page or io) rather than
> having to define
On Thu, Jan 31, 2019 at 09:12:45AM +0100, Greg Kroah-Hartman wrote:
> On Thu, Jan 31, 2019 at 09:00:30AM +0100, Daniel Vetter wrote:
> > On Thu, Jan 31, 2019 at 08:50:20AM +0100, Greg Kroah-Hartman wrote:
> > > On Thu, Jan 31, 2019 at 12:29:17PM +0530, Ramalingam C wrote:
> > > > +void
On Thu, Jan 31, 2019 at 12:29:53PM +0530, Ramalingam C wrote:
> Commits the content protection change of a connector,
> without crtc modeset. This improves the user experience.
>
> Originally proposed by Sean Paul at v3 of HDCP1.4 framework
> https://patchwork.freedesktop.org/patch/191759/. For
https://bugs.freedesktop.org/show_bug.cgi?id=107990
--- Comment #9 from Timothy Arceri ---
Thanks for investigating. The brute force fix is to finish implementing
EXT_direct_state_access. I have a partial implementation here which is able to
run Doom and Wolfenstein with this extension
On Thu, Jan 31, 2019 at 12:29:52PM +0530, Ramalingam C wrote:
> Mei hdcp driver is designed as component slave for the I915 component
> master.
>
> v2: Rebased.
> v3:
> Notifier chain is adopted for cldev state update [Tomas]
> v4:
> Made static dummy functions as inline in mei_hdcp.h
> API
On Thu, Jan 31, 2019 at 12:29:22PM +0530, Ramalingam C wrote:
> Defining the mei-i915 interface functions and initialization of
> the interface.
>
> v2:
> Adjust to the new interface changes. [Tomas]
> Added further debug logs for the failures at MEI i/f.
> port in hdcp_port data is
On Thu, Jan 31, 2019 at 09:00:30AM +0100, Daniel Vetter wrote:
> On Thu, Jan 31, 2019 at 08:50:20AM +0100, Greg Kroah-Hartman wrote:
> > On Thu, Jan 31, 2019 at 12:29:17PM +0530, Ramalingam C wrote:
> > > +void component_match_add_typed(struct device *master,
> > > + struct component_match
On Thu, Jan 31, 2019 at 12:29:34PM +0530, Ramalingam C wrote:
> Implements the
> Waitqueue is created to wait for CP_IRQ
> Signaling the CP_IRQ arrival through atomic variable.
> For applicable DP HDCP2.2 msgs read wait for CP_IRQ.
>
> As per HDCP2.2 spec "HDCP Transmitters must
On Thu, Jan 31, 2019 at 12:29:31PM +0530, Ramalingam C wrote:
> Since DP ERRATA message is not defined at spec, those structure
> definition is removed from drm_hdcp.h
>
> Signed-off-by: Ramalingam C
> Suggested-by: Daniel Vetter
Reviewed-by: Daniel Vetter
> ---
> include/drm/drm_hdcp.h | 6
On Thu, Jan 31, 2019 at 08:50:20AM +0100, Greg Kroah-Hartman wrote:
> On Thu, Jan 31, 2019 at 12:29:17PM +0530, Ramalingam C wrote:
> > +void component_match_add_typed(struct device *master,
> > + struct component_match **matchptr,
> > + int (*compare_typed)(struct device *, int, void *), void
101 - 161 of 161 matches
Mail list logo
