On Fri, Jan 25, 2019 at 09:43:24AM +, Russell King wrote:
> Add support for the vendor specific infoframe.
>
> Signed-off-by: Russell King
LGTM.
Reviewed-by: Brian Starkey
> ---
> drivers/gpu/drm/i2c/tda998x_drv.c | 14 ++
> 1 file changed, 14 insertions(+)
>
> diff --git
On Wed, Jan 30, 2019 at 10:33:39AM +, Koenig, Christian wrote:
> Am 30.01.19 um 09:02 schrieb Christoph Hellwig:
> > 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
Hi Russell,
On Fri, Jan 25, 2019 at 09:43:29AM +, Russell King wrote:
> CEA-861 says: "A Source shall not send a non-zero Q value that does
> not correspond to the default RGB Quantization Range for the
> transmitted Picture unless the Sink indicates support for the Q bit
> in a Video
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, 24 Jan 2019 10:39:52 +0530, Jayant Shekhar wrote:
> Add interconnect properties such as interconnect provider specifier
> , the edge source and destination ports which are required by the
> interconnect API to configure interconnect path for MDSS.
>
> Changes in v2:
> - None
>
>
On Wed, Jan 30, 2019 at 04:30:27AM +, Jason Gunthorpe wrote:
> On Tue, Jan 29, 2019 at 07:08:06PM -0500, Jerome Glisse wrote:
> > On Tue, Jan 29, 2019 at 11:02:25PM +, Jason Gunthorpe wrote:
> > > On Tue, Jan 29, 2019 at 03:44:00PM -0500, Jerome Glisse wrote:
> > >
> > > > > But this API
Hi Russell,
These did eventually reach me on Saturday evening.
On Fri, Jan 25, 2019 at 09:43:19AM +, Russell King wrote:
> Add support for writing the SPD infoframe to the TDA998x. Identify us
> as "Generic" vendor "PC" product, and as "PC general" source device
> information.
>
>
It was already fixed a while ago:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7e07834c12b96214e95a473f7b14fc03b20e2e7a
Alex
From: Brajeswar Ghosh
Sent: Wednesday, January 30, 2019 8:58:52 AM
To: Souptick Joarder
Cc: Zhu, Rex;
On 1/29/19 5:44 PM, Liam Mark wrote:
> On Fri, 18 Jan 2019, Liam Mark wrote:
>
>> On Fri, 18 Jan 2019, Andrew F. Davis wrote:
>>
>>> On 1/18/19 12:37 PM, Liam Mark wrote:
The ION begin_cpu_access and end_cpu_access functions use the
dma_sync_sg_for_cpu and dma_sync_sg_for_device APIs to
https://bugzilla.kernel.org/show_bug.cgi?id=202445
--- Comment #4 from Nicholas Kazlauskas (nicholas.kazlaus...@amd.com) ---
Below the range support didn't make it into 5.0. That patches for this are in
amd-staging-drm-next:
https://cgit.freedesktop.org/~agd5f/linux/log/?h=amd-staging-drm-next
https://bugzilla.kernel.org/show_bug.cgi?id=202449
--- Comment #5 from Nicholas Kazlauskas (nicholas.kazlaus...@amd.com) ---
Created attachment 280873
--> https://bugzilla.kernel.org/attachment.cgi?id=280873=edit
0001-drm-amd-display-Attach-VRR-properties-for-eDP-connec.patch
I'm not sure if
On 1/30/19 6:02 AM, Daniel Vetter wrote:
> On Wed, Jan 30, 2019 at 11:42 AM Daniel Vetter wrote:
>>
>> On Thu, Nov 8, 2018 at 3:44 PM Nicholas Kazlauskas
>> wrote:
>>>
>>> This patch introduces the 'vrr_enabled' CRTC property to allow
>>> dynamic control over variable refresh rate support for a
On Sun, 27 Jan 2019, Chen-Yu Tsai wrote:
> gpiod_get_value() gives out a warning if access to the underlying gpiochip
> requires sleeping, which is common for I2C based chips:
>
> WARNING: CPU: 0 PID: 77 at drivers/gpio/gpiolib.c:2500
> gpiod_get_value+0xd0/0x100
> Modules linked in:
>
On Tue, Jan 29, 2019 at 8:49 PM Sam Ravnborg wrote:
>
> Hi Jagan.
>
> > >
> > > I see DRM_MODE_ARG as mode argument, that print all mode timings but
> > > here we need only 3 timings out of it. do we really need? if yes
> > > please suggest an example.
> >
> > fyi: sent v6 for this except this
This patch attaches the colorspace connector property to the
hdmi connector. Based on colorspace change, modeset will be
triggered to switch to new colorspace.
Based on colorspace property value create an infoframe
with appropriate colorspace. This can be used to send an
infoframe packet with
This patch adds a DP colorspace property, enabling
userspace to switch to various supported colorspaces.
This will help enable BT2020 along with other colorspaces.
v2: Addressed Maarten and Ville's review comments. Enhanced
the colorspace enum to incorporate both HDMI and DP supported
This patch series creates a new connector property to program
colorspace to sink devices. Modern sink devices support more
than 1 type of colorspace like 601, 709, BT2020 etc. This helps
to switch based on content type which is to be displayed. The
decision lies with compositors as to in which
Create a new connector property to program colorspace to sink
devices. Modern sink devices support more than 1 type of
colorspace like 601, 709, BT2020 etc. This helps to switch
based on content type which is to be displayed. The decision
lies with compositors as to in which scenarios, a
>-Original Message-
>From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
>Maarten Lankhorst
>Sent: Wednesday, January 30, 2019 3:27 PM
>To: Shankar, Uma ; intel-...@lists.freedesktop.org;
>dri-devel@lists.freedesktop.org
>Cc: emil.l.veli...@gmail.com; Syrjala,
Am 30.01.19 um 11:55 schrieb Chris Wilson:
amdgpu only uses shared-fences internally, but dmabuf importers rely on
implicit write hazard tracking via the reservation_object.fence_excl.
For example, the importer use the write hazard for timing a page flip to
only occur after the exporter has
Hi Liam,
On Tue, Jan 29, 2019 at 03:44:53PM -0800, Liam Mark wrote:
> On Fri, 18 Jan 2019, Liam Mark wrote:
>
> > On Fri, 18 Jan 2019, Andrew F. Davis wrote:
> >
> > > On 1/18/19 12:37 PM, Liam Mark wrote:
> > > > The ION begin_cpu_access and end_cpu_access functions use the
> > > >
https://bugs.freedesktop.org/show_bug.cgi?id=109493
--- Comment #3 from Chris Wilson ---
Hmm, there are no skips here, so the test failed and we got no error message
from the child. That's quite a nasty igt bug.
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=107612
CheatCodesOfLife changed:
What|Removed |Added
CC||zacharybin...@hotmail.com
---
https://bugs.freedesktop.org/show_bug.cgi?id=108720
CheatCodesOfLife changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Dropped in favor of https://lkml.org/lkml/2019/1/29/910
On 1/24/19 5:02 PM, Julien Grall wrote:
>
>
> On 24/01/2019 14:34, Oleksandr Andrushchenko wrote:
>> Hello, Julien!
>
> Hi,
>
>> On 1/22/19 1:44 PM, Julien Grall wrote:
>>>
>>>
>>> On 1/22/19 10:28 AM, Oleksandr Andrushchenko wrote:
There is a potential NULL pointer dereference in case
fb_create_modedb() fails and returns NULL.
Signed-off-by: YueHaibing
---
drivers/video/fbdev/core/fbmon.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/video/fbdev/core/fbmon.c b/drivers/video/fbdev/core/fbmon.c
index
On 1/29/19 9:07 PM, Julien Grall wrote:
> Hi Oleksandr,
>
> On 1/29/19 3:04 PM, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko
>>
>> When GEM backing storage is allocated those are normal pages,
>> so there is no point using pgprot_writecombine while mmaping.
>> This fixes
On Wed, Dec 19, 2018 at 7:54 PM Daniel Vetter wrote:
>
> On Wed, Oct 24, 2018 at 03:28:16PM -0700, Manasi Navare wrote:
> > This patch adds inline functions and helpers for obtaining
> > DP sink's supported DSC parameters like DSC sink support,
> > eDP compressed BPP supported, maximum slice
On Wed, Jan 30, 2019 at 11:42 AM Daniel Vetter wrote:
>
> On Thu, Nov 8, 2018 at 3:44 PM Nicholas Kazlauskas
> wrote:
> >
> > This patch introduces the 'vrr_enabled' CRTC property to allow
> > dynamic control over variable refresh rate support for a CRTC.
> >
> > This property should be treated
Dave, Daniel
A fix for a DMA API change from Christoph Hellwig for vmwgfx, and
Two stable fixes for regressions in the vmwgfx driver
The following changes since commit f0e7ce1eef5854584dfb59b3824a67edee37580f:
Merge tag 'drm-msm-fixes-2019-01-24' of
amdgpu only uses shared-fences internally, but dmabuf importers rely on
implicit write hazard tracking via the reservation_object.fence_excl.
For example, the importer use the write hazard for timing a page flip to
only occur after the exporter has finished flushing its write into the
surface. As
On Thu, Nov 8, 2018 at 3:44 PM Nicholas Kazlauskas
wrote:
>
> This patch introduces the 'vrr_enabled' CRTC property to allow
> dynamic control over variable refresh rate support for a CRTC.
>
> This property should be treated like a content hint to the driver -
> if the hardware or driver is not
Am 30.01.19 um 02:53 schrieb Bas Nieuwenhuizen:
Some blocks in amdgpu can have 0 rqs.
Job creation already fails with -ENOENT when entity->rq is NULL,
so jobs cannot be pushed. Without a rq there is no scheduler to
pop jobs, and rq selection already does the right thing with a
list of length 0.
Am 30.01.19 um 02:53 schrieb Bas Nieuwenhuizen:
I don't see another way to figure out if a ring is initialized if
the hardware block might not be initialized.
Entities have been fixed up to handle num_rqs = 0.
Signed-off-by: Bas Nieuwenhuizen
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c | 11
Am 30.01.19 um 09:02 schrieb Christoph Hellwig:
> 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 this (though we may need
Am 29.01.19 um 21:24 schrieb Logan Gunthorpe:
On 2019-01-29 12:56 p.m., Alex Deucher wrote:
On Tue, Jan 29, 2019 at 12:47 PM wrote:
From: Jérôme Glisse
device_test_p2p() return true if two devices can peer to peer to
each other. We add a generic function as different inter-connect
can
https://bugs.freedesktop.org/show_bug.cgi?id=108720
Samuel Pitoiset changed:
What|Removed |Added
Status|NEW |NEEDINFO
Op 29-01-2019 om 19:50 schreef Uma Shankar:
> This patch attaches the colorspace connector property to the
> hdmi connector. Based on colorspace change, modeset will be
> triggered to switch to new colorspace.
>
> Based on colorspace property value create an infoframe
> with appropriate
On Wed, Jan 30, 2019 at 10:01 AM Philipp Zabel wrote:
> On Wed, 2019-01-30 at 09:16 +0100, Linus Walleij wrote:
> > On Thu, Jan 24, 2019 at 1:51 PM Philipp Zabel
> > wrote:
> >
> > > Since the TVE provides a clock to the DI, the driver can only be
> > > compiled if the common clock framework is
Specifically call virtio_gpu_object_create() before ttm_bo_init(), so
the object is already created when ttm calls the
virtio_gpu_ttm_tt_bind() callback (which in turn calls
virtio_gpu_object_attach()).
With that in place virtio_gpu_object_attach() will never be called with
an object which is not
There is no need to wait for completion here.
The host will process commands in submit order, so commands can
reference the new resource just fine even when queued up before
completion.
On the guest side there is no need to wait for completion too. Which
btw is different from resource destroy,
changes in v2:
- some cleanup patches are reviewed and merged already, dropped them.
- more verbose commit messages.
Gerd Hoffmann (6):
drm/virtio: move virtio_gpu_object_{attach,detach} calls.
drm/virtio: use struct to pass params to virtio_gpu_object_create()
drm/virtio: params struct
Add format, width and height fields to the virtio_gpu_object_params
struct. With that in place we can use the parameter struct for
virtio_gpu_cmd_create_resource() calls too.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 7 ---
Add 3d resource parameters to virtio_gpu_object_params struct. With
that in place we can use it for virtio_gpu_cmd_resource_create_3d()
calls.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 10 +-
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 25
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
move_notify() callback.
With that in place the move
Create virtio_gpu_object_params, use that to pass object parameters to
virtio_gpu_object_create. This is just the first step, followup patches
will add more parameters to the struct. The plan is to use the struct
for all object parameters.
Also drop unused "kernel" parameter for
Hi,
On Mon, Jan 28, 2019 at 01:10:45PM -0200, Fabio Estevam wrote:
> Hi Guido,
>
> On Fri, Jan 25, 2019 at 8:15 AM Guido Günther wrote:
>
> > +config PHY_MIXEL_MIPI_DPHY
> > + bool
> > + depends on OF
> > + select GENERIC_PHY
> > + select GENERIC_PHY_MIPI_DPHY
> > +
Hi Daniel,
On Tue, Jan 29, 2019 at 02:21:53PM +0100, Daniel Vetter wrote:
> I'm kinda fed up explaining why the have a confusing name :-)
Fully agreed, it's confusing and should definitely be fixed.
Acked-by: Laurent Pinchart
> Cc: Noralf Trønnes
> Cc: Laurent Pinchart
> Signed-off-by:
Hi Linus,
On Wed, 2019-01-30 at 09:16 +0100, Linus Walleij wrote:
> On Thu, Jan 24, 2019 at 1:51 PM Philipp Zabel wrote:
>
> > Since the TVE provides a clock to the DI, the driver can only be
> > compiled if the common clock framework is enabled. With the COMMON_CLK
> > dependency in place, it
Hi, Sam,
On 01/25/2019 07:22 PM, Sam Ravnborg wrote:
Hi Thomas.
One little nit, and an improvment proposal (for another patch/day).
On Fri, Jan 25, 2019 at 02:05:48PM +0100, Thomas Hellstrom wrote:
Instead of guessing whether TTM has the dma page allocator enabled,
ask TTM.
Signed-off-by:
On 2019-01-29 10:47 a.m., jgli...@redhat.com wrote:
> +bool pci_test_p2p(struct device *devA, struct device *devB)
> +{
> + struct pci_dev *pciA, *pciB;
> + bool ret;
> + int tmp;
> +
> + /*
> + * For now we only support PCIE peer to peer but other inter-connect
> + *
On Fri, 18 Jan 2019, Liam Mark wrote:
> On Fri, 18 Jan 2019, Andrew F. Davis wrote:
>
> > On 1/18/19 12:37 PM, Liam Mark wrote:
> > > The ION begin_cpu_access and end_cpu_access functions use the
> > > dma_sync_sg_for_cpu and dma_sync_sg_for_device APIs to perform cache
> > > maintenance.
> > >
On 2019-01-29 12:32 p.m., Jason Gunthorpe wrote:
> Jerome, I think it would be nice to have a helper scheme - I think the
> simple case would be simple remapping of PCI BAR memory, so if we
> could have, say something like:
>
> static const struct vm_operations_struct my_ops {
> .p2p_map =
On 2019-01-29 12:56 p.m., Alex Deucher wrote:
> On Tue, Jan 29, 2019 at 12:47 PM wrote:
>>
>> From: Jérôme Glisse
>>
>> device_test_p2p() return true if two devices can peer to peer to
>> each other. We add a generic function as different inter-connect
>> can support peer to peer and we want
Replace memset(vaddr_out + src_offset + 24, 0, 8) with
memset(vaddr_out + src_offset + 3, 0, 1) because memset fills
memory in bytes and not in bits.
Signed-off-by: Mamta Shukla
---
No changes in v2.
drivers/gpu/drm/vkms/vkms_crc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
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 this (though we may need something to ensure we don't get mapping
> requests mixed with different types of pages...).
I think Jerome explained the
Ben,
I wonder if you can take this too:
https://lore.kernel.org/patchwork/patch/1001180/
Thanks
--
Gustavo
On 1/29/19 8:51 PM, Ben Skeggs wrote:
> Got it, thanks.
>
> On Wed, 30 Jan 2019 at 06:55, Gustavo A. R. Silva
> wrote:
>>
>> In preparation to enabling -Wimplicit-fallthrough, mark
On 2019-01-29 2:50 p.m., Jerome Glisse wrote:
> No this is the non HMM case i am talking about here. Fully ignore HMM
> in this frame. A GPU driver that do not support or use HMM in anyway
> has all the properties and requirement i do list above. So all the points
> i was making are without HMM
Use the alpha value to blend vaddr_src with vaddr_dst instead
of overwriting it in blend().
Signed-off-by: Mamta Shukla
---
changes in v2:
-Use macro to avoid code duplication
-Add spaces around '/' and '-'
-Remove spaces at the end of the line
drivers/gpu/drm/vkms/vkms_crc.c | 25
On 2019-01-29 10:47 a.m., jgli...@redhat.com wrote:
> + /*
> + * Optional for device driver that want to allow peer to peer (p2p)
> + * mapping of their vma (which can be back by some device memory) to
> + * another device.
> + *
> + * Note that the exporting device
On 10/8/18 3:47 PM, Colin King wrote:
> From: Colin Ian King
>
> The NOUVEAU_GETPARAM_PCI_DEVICE case is missing a break statement and falls
> through to the following NOUVEAU_GETPARAM_BUS_TYPE case and may end up
> re-assigning the getparam->value to an undesired value. Fix this by adding
>
On 2019-01-29 12:11 p.m., Jerome Glisse wrote:
> On Tue, Jan 29, 2019 at 11:36:29AM -0700, Logan Gunthorpe wrote:
>>
>>
>> On 2019-01-29 10:47 a.m., jgli...@redhat.com wrote:
>>
>>> + /*
>>> +* Optional for device driver that want to allow peer to peer (p2p)
>>> +* mapping of their vma
On 2019-01-29 12:44 p.m., Jerome Glisse wrote:
>> I'd suggest [1] should be a part of the patchset so we can actually see
>> a user of the stuff you're adding.
>
> I did not wanted to clutter patchset with device driver specific usage
> of this. As the API can be reason about in abstract way.
On Tue, Jan 29, 2019 at 03:44:00PM -0500, Jerome Glisse wrote:
> > But this API doesn't seem to offer any control - I thought that
> > control was all coming from the mm/hmm notifiers triggering p2p_unmaps?
>
> The control is within the driver implementation of those callbacks.
Seems like what
Hi Oleksandr,
On 1/29/19 3:04 PM, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
When GEM backing storage is allocated those are normal pages,
so there is no point using pgprot_writecombine while mmaping.
This fixes mismatch of buffer pages' memory attributes between
the
On Tue, Jan 29, 2019 at 07:08:06PM -0500, Jerome Glisse wrote:
> On Tue, Jan 29, 2019 at 11:02:25PM +, Jason Gunthorpe wrote:
> > On Tue, Jan 29, 2019 at 03:44:00PM -0500, Jerome Glisse wrote:
> >
> > > > But this API doesn't seem to offer any control - I thought that
> > > > control was all
On 1/24/19 5:02 PM, Julien Grall wrote:
>
>
> On 24/01/2019 14:34, Oleksandr Andrushchenko wrote:
>> Hello, Julien!
>
> Hi,
>
>> On 1/22/19 1:44 PM, Julien Grall wrote:
>>>
>>>
>>> On 1/22/19 10:28 AM, Oleksandr Andrushchenko wrote:
Hello, Julien!
>>>
>>> Hi,
>>>
On 1/21/19 7:09 PM,
On Tue, Jan 29, 2019 at 2:39 PM Stephen Rothwell wrote:
>
> Hi all,
>
> After merging the drm-intel-fixes tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/gpu/drm/i915/intel_display.c: In function 'has_bogus_dpll_config':
>
In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.
This patch fixes the following warnings:
drivers/gpu/drm/savage/savage_state.c:301:8: warning: this statement may fall
through [-Wimplicit-fallthrough=]
On 2019-01-29 1:57 p.m., Jerome Glisse wrote:
> GPU driver must be in control and must be call to. Here there is 2 cases
> in this patchset and i should have instead posted 2 separate patchset as
> it seems that it is confusing things.
>
> For the HMM page, the physical address of the page ie
On 2019-01-29 4:47 p.m., Jerome Glisse wrote:
> The whole point is to allow to use device memory for range of virtual
> address of a process when it does make sense to use device memory for
> that range. So they are multiple cases where it does make sense:
> [1] - Only the device is accessing
On 2019-01-29 10:47 a.m., jgli...@redhat.com wrote:
> From: Jérôme Glisse
>
> device_test_p2p() return true if two devices can peer to peer to
> each other. We add a generic function as different inter-connect
> can support peer to peer and we want to genericaly test this no
> matter what the
In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.
This patch fixes the following warnings:
drivers/gpu/drm/via/via_dmablit.c:179:3: warning: this statement may fall
through [-Wimplicit-fallthrough=]
In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.
This patch fixes the following warning:
drivers/gpu/drm/nouveau/nouveau_bo.c:1434:53: warning: this statement may fall
through [-Wimplicit-fallthrough=]
Warning level 3 was used:
On Tue, Jan 29, 2019 at 10:30:31AM -0500, Alex Deucher wrote:
> On Fri, Jan 25, 2019 at 10:29 AM Wentland, Harry
> wrote:
> >
> > On 2019-01-24 7:52 p.m., ndesaulni...@google.com wrote:
> > > arch/x86/Makefile disables SSE and SSE2 for the whole kernel. The
> > > AMDGPU drivers modified in this
Suggestions:
1. revert patch
2. get me the disassembly from gcc of the translation unit in question.
3. land patch that adds clang guards or something different based on 2.
Revert first; ask questions later.
On Tue, Jan 29, 2019 at 11:01 AM Wentland, Harry wrote:
>
> On 2019-01-29 1:56 p.m.,
On 1/29/19 2:49 PM, Gustavo A. R. Silva wrote:
>
>
> On 10/8/18 3:47 PM, Colin King wrote:
>> From: Colin Ian King
>>
>> The NOUVEAU_GETPARAM_PCI_DEVICE case is missing a break statement and falls
>> through to the following NOUVEAU_GETPARAM_BUS_TYPE case and may end up
>> re-assigning the
On Tue, Jan 29, 2019 at 06:17:43PM -0700, Logan Gunthorpe wrote:
> This isn't answering my question at all... I specifically asked what is
> backing the VMA when we are *not* using HMM.
At least for RDMA what backs the VMA today is non-struct-page BAR
memory filled in with io_remap_pfn.
And we
On 2019-01-29 12:44 p.m., Greg Kroah-Hartman wrote:
> On Tue, Jan 29, 2019 at 11:24:09AM -0700, Logan Gunthorpe wrote:
>>
>>
>> On 2019-01-29 10:47 a.m., jgli...@redhat.com wrote:
>>> +bool pci_test_p2p(struct device *devA, struct device *devB)
>>> +{
>>> + struct pci_dev *pciA, *pciB;
>>> +
On Tue, Jan 29, 2019 at 02:50:55PM -0500, Jerome Glisse wrote:
> GPU driver do want more control :) GPU driver are moving things around
> all the time and they have more memory than bar space (on newer platform
> AMD GPU do resize the bar but it is not the rule for all GPUs). So
> GPU driver do
On Tue, Jan 29, 2019 at 02:11:23PM -0500, Jerome Glisse wrote:
> On Tue, Jan 29, 2019 at 11:36:29AM -0700, Logan Gunthorpe wrote:
> >
> >
> > On 2019-01-29 10:47 a.m., jgli...@redhat.com wrote:
> >
> > > + /*
> > > + * Optional for device driver that want to allow peer to peer (p2p)
> > > + *
On Tue, 29 Jan 2019, Lucas De Marchi wrote:
> On Tue, Jan 29, 2019 at 2:39 PM Stephen Rothwell
> wrote:
>>
>> Hi all,
>>
>> After merging the drm-intel-fixes tree, today's linux-next build (x86_64
>> allmodconfig) failed like this:
>>
>> drivers/gpu/drm/i915/intel_display.c: In function
On Thu, Jan 24, 2019 at 1:51 PM Philipp Zabel wrote:
> Allow to compile-test imx-drm on other platforms.
>
> Signed-off-by: Philipp Zabel
Reviewed-by: Linus Walleij
Yours,
Linus Walleij
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
On Thu, Jan 24, 2019 at 1:51 PM Philipp Zabel wrote:
> Since the TVE provides a clock to the DI, the driver can only be
> compiled if the common clock framework is enabled. With the COMMON_CLK
> dependency in place, it will be possible to allow building the other
> parts of imx-drm under
101 - 184 of 184 matches
Mail list logo
