On Thu, Jan 31, 2019 at 08:26:00PM +0100, Sam Ravnborg wrote:
> Hi Thierry et al.
>
> While reviewing a number of new panel drivers there was a
> certain pattern in the feedback:
> - the now deprecated drmP.h file was used
> - dev_err() and friends was used
>
> This patch-set address the above
Hi Sean.
> Hey Sam,
> Thanks for the patchset, this will make dmesg grepping easier! One comment,
> and
> you're going to hate me for it: Why use DRM_DEV* instead of DRM_*?
>
> When I introduced DRM_DEV, it was to cover the case where there are multiple
> instances of the same driver (ie:
https://bugs.freedesktop.org/show_bug.cgi?id=109206
--- Comment #7 from grak...@gmail.com ---
Can confirm that removing raven_dmcu.bin allows amdgpu to load. Note that
kernel 4.20 also requires iommu=pt kernel option.
--
You are receiving this mail because:
You are the assignee for the
On Thu, Jan 31, 2019 at 09:59:26AM -0800, Rodrigo Vivi wrote:
> On Thu, Jan 31, 2019 at 02:15:07PM +0100, Greg Kroah-Hartman wrote:
> > When calling debugfs functions, they can now return error values if
> > something went wrong. If that happens, return a NULL as a *dentry to
> > the relay core
https://bugzilla.kernel.org/show_bug.cgi?id=202449
Haxk20 (haxk...@gmail.com) changed:
What|Removed |Added
Status|NEW |RESOLVED
On Tue, Jan 29, 2019 at 02:26:29PM -0500, Sean Paul wrote:
> From: Sean Paul
>
> Drivers shouldn't be using these values, add a TODO so someone removes
> them.
>
> Changes in v2:
> - Add drm_display_mode.vrefresh removal (Ville)
> - Add Sam's R-b and bonus points
> Changes in v3:
> - Add hsync
On Thu, Jan 31, 2019 at 07:02:15PM +, Jason Gunthorpe wrote:
> On Thu, Jan 31, 2019 at 09:13:55AM +0100, Christoph Hellwig wrote:
> > On Wed, Jan 30, 2019 at 03:52:13PM -0700, Logan Gunthorpe wrote:
> > > > *shrug* so what if the special GUP called a VMA op instead of
> > > > traversing the
https://bugs.freedesktop.org/show_bug.cgi?id=109524
Bug ID: 109524
Summary: "Invalid glsl version in shading_language_version()"
when trying to run directX games using wine
Product: Mesa
Version: 18.2
Hardware: x86 (IA32)
On Thu, Jan 31, 2019 at 10:03:12PM +0100, Sam Ravnborg wrote:
> Hi Sean.
>
> > Hey Sam,
> > Thanks for the patchset, this will make dmesg grepping easier! One comment,
> > and
> > you're going to hate me for it: Why use DRM_DEV* instead of DRM_*?
> >
> > When I introduced DRM_DEV, it was to
https://bugs.freedesktop.org/show_bug.cgi?id=108487
--- Comment #14 from magiblot ---
Created attachment 143267
--> https://bugs.freedesktop.org/attachment.cgi?id=143267=edit
Stderr output of weston when run on i915 (with patch from comment #13)
(In reply to Daniel Stone from comment #13)
Use of drmP.h is discouraged and yet we see new panel
drivers utilising drmP.h.
Remove usage of drmP.h from current panel drivers to set a good
example for new drivers.
While touching list of include files sort them.
Build tested on arm/x86.
Signed-off-by: Sam Ravnborg
Cc: Linus Walleij
Cc:
Introduce use of DRM_DEV* for logging.
This makes logging in the drm subsystem more consistent.
Signed-off-by: Sam Ravnborg
Cc: Thierry Reding
Cc: David Airlie
Cc: Daniel Vetter
---
drivers/gpu/drm/panel/panel-panasonic-vvx10f034n00.c | 16 ++--
1 file changed, 10 insertions(+),
Introduce use of DRM_DEV* for logging.
This makes logging in the drm subsystem more consistent.
Signed-off-by: Sam Ravnborg
Cc: Thierry Reding
Cc: David Airlie
Cc: Daniel Vetter
---
drivers/gpu/drm/panel/panel-innolux-p079zca.c | 12 +++-
1 file changed, 7 insertions(+), 5
Introduce use of DRM_DEV* for logging.
This makes logging in the drm subsystem more consistent.
Signed-off-by: Sam Ravnborg
Cc: Thierry Reding
Cc: David Airlie
Cc: Daniel Vetter
---
drivers/gpu/drm/panel/panel-ilitek-ili9322.c | 93 +++
Introduce use of DRM_DEV* for logging.
This makes logging in the drm subsystem more consistent.
Signed-off-by: Sam Ravnborg
Cc: Thierry Reding
Cc: David Airlie
Cc: Daniel Vetter
Cc: Stefan Mavrodiev
---
drivers/gpu/drm/panel/panel-arm-versatile.c | 18 ++
1 file changed, 10
Introduce use of DRM_DEV* for logging.
This makes logging in the drm subsystem more consistent.
Signed-off-by: Sam Ravnborg
Cc: Thierry Reding
Cc: David Airlie
Cc: Daniel Vetter
---
drivers/gpu/drm/panel/panel-seiko-43wvf1g.c | 14 --
1 file changed, 8 insertions(+), 6
Introduce use of DRM_DEV* for logging.
This makes logging in the drm subsystem more consistent.
Signed-off-by: Sam Ravnborg
Cc: Thierry Reding
Cc: David Airlie
Cc: Daniel Vetter
---
drivers/gpu/drm/panel/panel-lvds.c | 38 ++
1 file changed, 22
Introduce use of DRM_DEV* for logging.
This makes logging in the drm subsystem more consistent.
Signed-off-by: Sam Ravnborg
Cc: Thierry Reding
Cc: David Airlie
Cc: Daniel Vetter
---
drivers/gpu/drm/panel/panel-jdi-lt070me05000.c | 64 ++
1 file changed, 34
Hi Thierry et al.
While reviewing a number of new panel drivers there was a
certain pattern in the feedback:
- the now deprecated drmP.h file was used
- dev_err() and friends was used
This patch-set address the above items in the panel
drivers in drm/panel/
The hope is that new panel drivers
Introduce use of DRM_DEV* for logging.
This makes logging in the drm subsystem more consistent.
Signed-off-by: Sam Ravnborg
Cc: Thierry Reding
Cc: David Airlie
Cc: Daniel Vetter
---
drivers/gpu/drm/panel/panel-lg-lg4573.c | 20 +++-
1 file changed, 11 insertions(+), 9
Introduce use of DRM_DEV* for logging.
This makes logging in the drm subsystem more consistent.
Signed-off-by: Sam Ravnborg
Cc: Thierry Reding
Cc: David Airlie
Cc: Daniel Vetter
---
drivers/gpu/drm/panel/panel-samsung-ld9040.c | 12 +--
Introduce use of DRM_DEV* for logging.
This makes logging in the drm subsystem more consistent.
Signed-off-by: Sam Ravnborg
Cc: Thierry Reding
Cc: David Airlie
Cc: Daniel Vetter
Cc: Stefan Mavrodiev
---
drivers/gpu/drm/panel/panel-truly-nt35597.c | 2 +-
1 file changed, 1 insertion(+), 1
The num_supplies variable is not used, delete it.
Build tested.
Signed-off-by: Sam Ravnborg
Cc: Thierry Reding
Cc: David Airlie
Cc: Daniel Vetter
---
drivers/gpu/drm/panel/panel-innolux-p079zca.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-innolux-p079zca.c
Introduce use of DRM_DEV* for logging.
This makes logging in the drm subsystem more consistent.
Signed-off-by: Sam Ravnborg
Cc: Stefan Mavrodiev
Cc: Thierry Reding
Cc: David Airlie
Cc: Daniel Vetter
---
drivers/gpu/drm/panel/panel-olimex-lcd-olinuxino.c | 26 +-
1 file
Introduce use of DRM_DEV* for logging.
This makes logging in the drm subsystem more consistent.
Signed-off-by: Sam Ravnborg
Cc: Thierry Reding
Cc: David Airlie
Cc: Daniel Vetter
---
drivers/gpu/drm/panel/panel-orisetech-otm8009a.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
Introduce use of DRM_DEV* for logging.
This makes logging in the drm subsystem more consistent.
Signed-off-by: Sam Ravnborg
Cc: Thierry Reding
Cc: David Airlie
Cc: Daniel Vetter
---
drivers/gpu/drm/panel/panel-simple.c | 19 ---
1 file changed, 12 insertions(+), 7
Introduce use of DRM_DEV* for logging.
This makes logging in the drm subsystem more consistent.
Signed-off-by: Sam Ravnborg
Cc: Thierry Reding
Cc: David Airlie
Cc: Daniel Vetter
---
drivers/gpu/drm/panel/panel-sitronix-st7789v.c | 10 ++
1 file changed, 6 insertions(+), 4
Introduce use of DRM_DEV* for logging.
This makes logging in the drm subsystem more consistent.
Signed-off-by: Sam Ravnborg
Cc: Thierry Reding
Cc: David Airlie
Cc: Daniel Vetter
---
drivers/gpu/drm/panel/panel-raydium-rm68200.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
Introduce use of DRM_DEV* for logging.
This makes logging in the drm subsystem more consistent.
Signed-off-by: Sam Ravnborg
Cc: Thierry Reding
Cc: David Airlie
Cc: Daniel Vetter
---
drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c | 63 -
Introduce use of DRM_DEV* for logging.
This makes logging in the drm subsystem more consistent.
Signed-off-by: Sam Ravnborg
Cc: Thierry Reding
Cc: David Airlie
Cc: Daniel Vetter
---
.../gpu/drm/panel/panel-raspberrypi-touchscreen.c | 22 ++
1 file changed, 14
On Thu, 31 Jan 2019 11:10:06 -0500 Jerome Glisse wrote:
> Andrew what is your plan for this ? I had a discussion with Peter Xu
> and Andrea about change_pte() and kvm. Today the change_pte() kvm
> optimization is effectively disabled because of invalidate_range
> calls. With a minimal couple
On Mon, Jan 28, 2019 at 04:05:34PM -0800, Matthias Kaehlcke wrote:
> Hi,
>
> this series has gone through multiple rounds of review and there are
> no outstanding comments. It seems it should be ready to land, or is
> there anything left that needs to be addressed?
From the drm side, I think
On Wed, Jan 30, 2019 at 1:43 AM Gerd Hoffmann wrote:
>
> 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.
Does virtio_gpu_execbuffer_ioctl also wait
Hi all.
On Thu, Jan 31, 2019 at 08:26:00PM +0100, Sam Ravnborg wrote:
> Hi Thierry et al.
>
> While reviewing a number of new panel drivers there was a
> certain pattern in the feedback:
> - the now deprecated drmP.h file was used
> - dev_err() and friends was used
>
> This patch-set address
Thank you, Nathan. I applied your patch to amd-staging-drm-next.
Sorry for the late response. I'm catching up with my email backlog after
a vacation.
Regards,
Felix
On 2019-01-21 6:52 p.m., Nathan Chancellor wrote:
> Clang warns:
>
> drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_crat.c:866:5:
On Thu, Jan 31, 2019 at 11:55:35AM -0800, Andrew Morton wrote:
> On Thu, 31 Jan 2019 11:10:06 -0500 Jerome Glisse wrote:
>
> > Andrew what is your plan for this ? I had a discussion with Peter Xu
> > and Andrea about change_pte() and kvm. Today the change_pte() kvm
> > optimization is
This fixes the extra issues I discovered upstream after the introduction
of my rework of the atomic VCPI helpers that occur during
suspend/resume.
This time around, we use a slightly different but much less complicated
approach for fixing said issues.
Cc: Daniel Vetter
Lyude Paul (4):
We are seeking nominations for candidates for election to the X.Org Foundation
Board of Directors. All X.Org Foundation members are eligible for election to
the board.
Nominations for the 2019 election are now open and will remain open until 23:59
UTC on 14 February 2019.
The Board consists
This series implements the todo to add reservation_object to
drm_gem_object. I converted the easy drivers, but not Intel or AMD. The
series is build tested only.
Rob
Rob Herring (5):
drm: Add reservation_object to drm_gem_object
drm: etnaviv: Switch to use drm_gem_object reservation_object
Now that the base struct drm_gem_object has a reservation_object, use it
and remove the private BO one.
Cc: Lucas Stach
Cc: Russell King
Cc: Christian Gmeiner
Cc: David Airlie
Cc: Daniel Vetter
Cc: etna...@lists.freedesktop.org
Signed-off-by: Rob Herring
---
Since
commit 39b50c603878 ("drm/atomic_helper: Stop modesets on unregistered
connectors harder")
We've been failing atomic checks if they try to enable new displays on
unregistered connectors. This is fine except for the one situation that
breaks atomic assumptions: suspend/resume. If a
Reviewed-by: Deepak Rawat
On Thu, 2019-01-31 at 11:07 +0100, Thomas Hellstrom wrote:
> 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
https://bugs.freedesktop.org/show_bug.cgi?id=109526
Bug ID: 109526
Summary: [CARRIZO] amdgpu fails to resume from S3, atombios
stuck executing C554 (len 629, WS 0, PS 0)
Product: DRI
Version: unspecified
Hardware: Other
Hi all,
In commit
a93587b31e34 ("drm/amd/display: Only get the connector state for VRR when
toggled")
Fixes tag
Fixes: 3cc22f281318 ("drm/amdgpu: Set FreeSync state using drm VRR
properties")
has these problem(s):
- Target SHA1 does not exist
Maybe instead:
FIxes: bb47de736661
Now that the base struct drm_gem_object has a reservation_object, use it
and remove the private BO one.
Cc: Eric Anholt
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Rob Herring
---
drivers/gpu/drm/vc4/vc4_bo.c| 15 +--
In drm_dp_mst_deallocate_vcpi(), we currently unconditionally call
drm_dp_mst_put_port_malloc() on the port that's passed to us, even if we
never successfully allocated VCPI to it. This is contrary to what we do
in drm_dp_mst_allocate_vcpi(), where we only call
drm_dp_mst_get_port_malloc() on the
Since we now have an easy way of refcounting drm_dp_mst_port structs and
safely accessing their contents, there isn't any good reason to keep
validating ports here. It doesn't prevent us from performing modesets on
branch devices that have been removed either, and we already disallow
enabling new
Reviewed-by: Deepak Rawat
On Thu, 2019-01-31 at 10:52 +0100, Thomas Hellstrom wrote:
> 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
Gen9+ platforms allow CRTC's to be programmed with a background/canvas
color below the programmable planes. Let's expose this for use by
compositors.
v2:
- Split out bgcolor sanitization and programming of csc/gamma bits to a
separate patch that we can land before the ABI changes are ready
Some display controllers can be programmed to present non-black colors
for pixels not covered by any plane (or pixels covered by the
transparent regions of higher planes). Compositors that want a UI with
a solid color background can potentially save memory bandwidth by
setting the CRTC background
Now that the base struct drm_gem_object has a reservation_object, use it
and remove the private BO one.
We can't use the drm_gem_reservation_object_wait() helper for MSM
because (in theory) msm_gem_cpu_prep() will also do some cache
maintenance on the GEM object.
Cc: Rob Clark
Cc: David Airlie
Now that the base struct drm_gem_object has a reservation_object, use it
and remove the private BO one.
Cc: Eric Anholt
Cc: Daniel Vetter
Cc: David Airlie
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Rob Herring
---
drivers/gpu/drm/v3d/v3d_bo.c | 14 +-
Hi all,
After merging the drm tree, today's linux-next build (x86_64 allmodconfig)
produced this warning:
drivers/gpu/drm/amd/amdgpu/../display/modules/power/power_helpers.c:160:9:
warning: #pragma pack (pop) encountered without matching #pragma pack (push)
[-Wpragmas]
#pragma pack(pop)
Many users of drm_gem_object embed a struct reservation_object into
their subclassed struct, so let's add one to struct drm_gem_object.
This will allow removing the reservation object from the subclasses
and removing the ->gem_prime_res_obj callback.
With the addition, add a
Atomic checks should never modify anything outside of the state that
they're passed in. Unfortunately this appears to be exactly what we're
doing in nv50_msto_atomic_check() where we update mstc->pbn every time
the function is called. This hasn't caused any bugs yet, but it needs to
be fixed in
On Thu, Jan 31, 2019 at 11:04:31AM -0800, Gurchetan Singh wrote:
> On Wed, Jan 30, 2019 at 1:43 AM Gerd Hoffmann wrote:
> >
> > 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
https://bugs.freedesktop.org/show_bug.cgi?id=60879
--- Comment #174 from EmilyBrown ---
Thanks for coming with detailed bug which you faced while starting X server and
what happened after few minutes within screenshots for better reference to find
a solution for other users and experts of it.
https://bugs.freedesktop.org/show_bug.cgi?id=109524
Mickey changed:
What|Removed |Added
URL||http://www.onedollarwebhost
Am Mi., 19. Dez. 2018 um 15:45 Uhr schrieb Lucas Stach :
>
> Keep the page at address 0 as faulting to catch any potential state
> setup issues early.
>
> Signed-off-by: Lucas Stach
I like this idea.. but I am unsure about Guido's GC7000 problem.
Reviewed-by: Christian Gmeiner
> ---
>
tree: git://anongit.freedesktop.org/drm/drm-tip drm-tip
head: 3f287cb6d4ae4689eb7c53e4c25f0fba3df16438
commit: 0a2fe4901d16d28bb8ad5f7032e9579f85e7e594 [891/897] Merge
remote-tracking branch 'drm/drm-next' into drm-tip
config: riscv-allmodconfig (attached as .config)
compiler:
tree: git://people.freedesktop.org/~agd5f/linux.git drm-next-5.1-wip
head: 8054c54a6169ca26157d2bed0b52f63d472dbd34
commit: 308176d6f625bc782a34ec316beaefcfa7ad75f3 [17/212] drm/amdgpu: Remove
kgd2kfd function pointers
reproduce:
# apt-get install sparse
git checkout
Hi Dave, Daniel,
Sorry this is a bit late. I had Internet issues yesterday.
A few fixes for 5.0:
- Fix radeon crash on SI with VM passthrough
- Fencing fix for shared buffers
- Fix power hwmon reporting on APUs
- Powerplay fix for APUs
The following changes since commit
Hi Dave, Daniel,
More stuff for 5.1. Mostly bug fixes.
ttm:
- Replace ref/unref naming with get/put
amdgpu:
- Revert DC clang fix, causes a segfault with some compiler versions
- SR-IOV fix
- PCIE fix for vega20
- Misc DC fixes
The following changes since commit
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 #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
Den 30.01.2019 10.43, skrev Gerd Hoffmann:
> 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
> ---
You don't remove the struct virtio_gpu_resource_create_3d
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 #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
>
Den 30.01.2019 10.43, skrev Gerd Hoffmann:
> 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
https://bugs.freedesktop.org/show_bug.cgi?id=105880
--- Comment #46 from Przemek ---
(In reply to Pontus Gråskæg from comment #43)
> (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
Den 30.01.2019 10.43, skrev Gerd Hoffmann:
> 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
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
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: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: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
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
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 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: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 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 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
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
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
1 - 100 of 161 matches
Mail list logo
