On Wed, Nov 13, 2019 at 2:32 AM james qian wang (Arm Technology China)
wrote:
>
> Fix the build errors lead by
>
> 'commit 4039f0293bbd ("drm/komeda: Add option to print WARN- and INFO-level
> IRQ events")'
>
> Signed-off-by: james qian wang (Arm Technology China)
>
Reviewed-by: Daniel Vetter
On Wed, Nov 13, 2019 at 8:56 AM Maxime Ripard wrote:
>
> The driver assumes that the platform uses the device tree, and thus relies
> on some fields (of_node) being declared in some structures (drm_bridge).
>
> This isn't true for all platforms, so make sure we can only compile the
> ANX6345 on pl
Hi John
Am 12.11.19 um 20:13 schrieb John Donnelly:
>
> In short . I started with :
>
> git bisect start
>
> git bisect bad be8454afc50f
>
> git bisect good fec88ab0af97
>
> And at the the end of bisects showed this was the offending commit :
>
> c0a74c732568
>
> commit c0a74c7325
On Wed, Nov 13, 2019 at 8:39 AM Gerd Hoffmann wrote:
>
> Hi,
>
> > > > >> VRAM helpers use drm_gem_ttm_mmap(), which wraps ttm_bo_mmap_obj().
> > > > >> These changes should be transparent.
> > > > >
> > > > > There's still the issue that for dma-buf mmap vs drm mmap you use
> > > > > different
On Tue, Nov 12, 2019 at 10:10 PM John Hubbard wrote:
>
> On 11/12/19 12:38 PM, Jason Gunthorpe wrote:
> > On Mon, Nov 11, 2019 at 04:06:37PM -0800, John Hubbard wrote:
> >> Hi,
> >>
> >> The cover letter is long, so the more important stuff is first:
> >>
> >> * Jason, if you or someone could look
On 11/13/19 12:22 AM, Daniel Vetter wrote:
...
Why are we doing this? I think things got confused here someplace, as
Because:
a) These need put_page() calls, and
b) there is no put_pages() call, but there is a release_pages() call that
is, arguably, what put_pages() would be.
the comment
Hi
Am 12.11.19 um 16:13 schrieb Daniel Vetter:
> On Tue, Nov 12, 2019 at 3:51 PM Thomas Zimmermann wrote:
>>
>> Hi
>>
>> Am 12.11.19 um 15:31 schrieb Daniel Vetter:
>>> On Tue, Nov 12, 2019 at 3:03 PM Thomas Zimmermann
>>> wrote:
Hi
Am 12.11.19 um 14:40 schrieb Daniel Vetter
From: Thomas Hellstrom
We're gradually moving towards using DMA coherent memory in most
situations, although TTM interactions with the DMA layers is still a
work-in-progress. Meanwhile, use coherent memory when there are size
restrictions meaning that there is a chance that streaming dma mapping
From: YueHaibing
drivers/gpu/drm/vmwgfx/vmwgfx_surface.c:339:22:
warning: variable srf set but not used [-Wunused-but-set-variable]
'srf' is never used, so can be removed.
Signed-off-by: YueHaibing
Reviewed-by: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/vmwgfx_surface.c | 2 --
1 file chan
From: Thomas Hellstrom
With AMD-SEV high-bandwidth port messaging runs into trouble since the
message content is encrypted using the vm-specific key, and the
hypervisor is unable to read it.
So use unencrypted dma-coherent bounce buffers for temporary message
storage space. Allocating that memor
On Tue, Nov 12, 2019 at 4:50 PM Paul Kocialkowski
wrote:
>
> Hi,
>
> On Tue 12 Nov 19, 16:11, Paul Kocialkowski wrote:
> > Hi,
> >
> > On Tue 12 Nov 19, 11:20, Patrik Jakobsson wrote:
> > > On Thu, Nov 7, 2019 at 4:30 PM Paul Kocialkowski
> > > wrote:
> > > >
> > > > psbfb_probe performs an evalu
On Wed 13-11-19 01:02:02, John Hubbard wrote:
> On 11/13/19 12:22 AM, Daniel Vetter wrote:
> ...
> > > > Why are we doing this? I think things got confused here someplace, as
> > >
> > >
> > > Because:
> > >
> > > a) These need put_page() calls, and
> > >
> > > b) there is no put_pages() call,
On Tue 12-11-19 20:26:56, John Hubbard wrote:
> Introduce pin_user_pages*() variations of get_user_pages*() calls,
> and also pin_longterm_pages*() variations.
>
> These variants all set FOLL_PIN, which is also introduced, and
> thoroughly documented.
>
> The pin_longterm*() variants also set FOL
On Tue 12-11-19 20:26:51, John Hubbard wrote:
> An upcoming patch changes and complicates the refcounting and
> especially the "put page" aspects of it. In order to keep
> everything clean, refactor the devmap page release routines:
>
> * Rename put_devmap_managed_page() to page_is_devmap_managed(
On Tue 12-11-19 20:26:50, John Hubbard wrote:
> An upcoming patch uses try_get_compound_head() more widely,
> so move it to the top of gup.c.
>
> Also fix a tiny spelling error and a checkpatch.pl warning.
>
> Signed-off-by: John Hubbard
Looks good. You can add:
Reviewed-by: Jan Kara
On Tue 12-11-19 20:26:48, John Hubbard wrote:
> A subsequent patch requires access to gup flags, so
> pass the flags argument through to the __gup_device_*
> functions.
>
> Also placate checkpatch.pl by shortening a nearby line.
>
> Reviewed-by: Jérôme Glisse
> Reviewed-by: Ira Weiny
> Cc: Kiri
On Monday, October 21, 2019 4:51:48 PM CET Geert Uytterhoeven wrote:
> There is no need to cast a typed pointer to a void pointer when calling
> a function that accepts the latter. Remove it, as the cast prevents
> further compiler checks.
>
> Signed-off-by: Geert Uytterhoeven
> ---
> drivers/p
On Tue 12-11-19 20:26:49, John Hubbard wrote:
> There are four locations in gup.c that have a fair amount of code
> duplication. This means that changing one requires making the same
> changes in four places, not to mention reading the same code four
> times, and wondering if there are subtle diffe
On Tue, 12 Nov 2019, Colin King wrote:
> From: Colin Ian King
>
> There is a spelling mistake in a dev_err error message. Fix it.
>
> Signed-off-by: Colin Ian King
> ---
> drivers/video/backlight/qcom-wled.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Applied, thanks.
--
Lee Jo
On Wed, Nov 13, 2019 at 02:01:53AM +, james qian wang (Arm Technology
China) wrote:
> On Fri, Nov 08, 2019 at 04:09:54PM +, Ayan Halder wrote:
> > On Mon, Nov 04, 2019 at 11:12:27PM +0100, Andrzej Pietrasiewicz wrote:
> > > There are afbc helpers available.
> > >
> > > Signed-off-by: Andr
On Wed, Nov 13, 2019 at 10:51:51AM +0100, Thomas Zimmermann wrote:
> Hi
>
> Am 12.11.19 um 16:13 schrieb Daniel Vetter:
> > On Tue, Nov 12, 2019 at 3:51 PM Thomas Zimmermann
> > wrote:
> >>
> >> Hi
> >>
> >> Am 12.11.19 um 15:31 schrieb Daniel Vetter:
> >>> On Tue, Nov 12, 2019 at 3:03 PM Thomas
On Wed, Nov 13, 2019 at 11:12:10AM +0100, Jan Kara wrote:
> On Wed 13-11-19 01:02:02, John Hubbard wrote:
> > On 11/13/19 12:22 AM, Daniel Vetter wrote:
> > ...
> > > > > Why are we doing this? I think things got confused here someplace, as
> > > >
> > > >
> > > > Because:
> > > >
> > > > a) The
There are no callers of drm_fb_helper_unlink_fbi() left. Remove the
function.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_fb_helper.c | 16 +---
include/drm/drm_fb_helper.h | 6 --
2 files changed, 1 insertion(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/dr
The udl driver can use the generic fbdev emulation. After conversion,
a number of cleanups can be applied.
The fbdev conversion is in patch 1. As udl was the only remaining
external user of unlink_framebuffer(), that function now becomes an
internal interface of the fbdev code (Patches 2 + 3).
V4
The udl driver can use the generic fbdev implementation. Convert it.
v4:
* hardcode console bpp to 16
v3:
* remove module parameter fb_bpp in favor of fbdev's video
* call drm_fbdev_generic_setup() directly; remove udl_fbdev_init()
* use default for struct drm_mode_
There are no external callers of unlink_framebuffer() left. Make the
function an internal interface.
Signed-off-by: Thomas Zimmermann
---
drivers/video/fbdev/core/fbmem.c | 3 +--
include/linux/fb.h | 1 -
2 files changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/video/
Dave, Daniel,
Take 2 of the coherent memory patches are now ready for pulling.
Following the discussion we had after the last merge attempt that had to
be reverted, it might make sense to send this to Linus as a pull request
separate from other DRM stuff.
This time Linus has been heavily involved
Hi Jacopo,
Sorry for spoiling your v7 ;-)
On Wed, Nov 13, 2019 at 11:04 AM Jacopo Mondi wrote:
> Document the newly added 'cmms' property which accepts a list of phandle
renesas,cmms
> and channel index pairs that point to the CMM units available for each
> Display Unit output video channel.
>
On Tuesday, 12 November 2019 18:24:16 GMT Daniel Vetter wrote:
> On Tue, Nov 12, 2019 at 2:00 PM Mihail Atanassov
> wrote:
> >
> > On Monday, 11 November 2019 15:53:14 GMT Liviu Dudau wrote:
> > > On Thu, Nov 07, 2019 at 11:42:44AM +, Mihail Atanassov wrote:
> > > > It's possible to get multip
On Mon, Oct 14, 2019 at 8:43 PM Dmitry Torokhov
wrote:
> Instead of fwnode_get_named_gpiod() that I plan to hide away, let's use
> the new fwnode_gpiod_get_index() that mimics gpiod_get_index(), but
> works with arbitrary firmware node.
>
> Reviewed-by: Laurent Pinchart
> Signed-off-by: Dmitry T
Hi,
> > ... but after looking again I think we are all green here. Given that
> > only self-import works we'll only see vram gem objects in the mmap code
> > path, which should have everything set up correctly. Same goes for qxl.
> >
> > All other ttm drivers still use the old mmap code path,
On Tue, Nov 5, 2019 at 4:41 PM Daniel Vetter wrote:
> On Tue, Nov 5, 2019 at 4:29 PM Linus Walleij wrote:
> > On Tue, Nov 5, 2019 at 1:40 AM Dmitry Torokhov
> > wrote:
> > I'm happy to merge it into the GPIO tree if some DRM maintainer can
> > provide an ACK.
>
> Ack.
Thanks!
> > Getting ACK
On Wed, Nov 13, 2019 at 2:18 AM Daniel Vetter wrote:
>
> On Wed, Nov 13, 2019 at 8:39 AM Gerd Hoffmann wrote:
> >
> > Hi,
> >
> > > > > >> VRAM helpers use drm_gem_ttm_mmap(), which wraps ttm_bo_mmap_obj().
> > > > > >> These changes should be transparent.
> > > > > >
> > > > > > There's still
When mapping ttm objects via drm_gem_ttm_mmap() helper
drm_gem_mmap_obj() will take an object reference. That gets
never released due to ttm having its own reference counting.
Fix that by dropping the gem object reference once the ttm mmap
completed (and ttm refcount got bumped).
For that to wor
Hi,
On Wed, Nov 13, 2019 at 01:27:25PM +, Tian Yunhao wrote:
> The datasheet of V3s (and various other chips) wrote
> that TCON0_DCLK_DIV can be >= 1 if only dclk is used,
> and must >= 6 if dclk1 or dclk2 is used. As currently
> neither dclk1 nor dclk2 is used (no writes to these
> bits), let
Hi Dave, Daniel,
Here's a PR for this week's drm-misc-fixes.
Maxime
drm-misc-fixes-2019-11-13:
- One fix to the dotclock dividers range for sun4i
The following changes since commit 105401b659b7eb9cb42d6b5b75d5c049ad4b3dca:
drm/shmem: Add docbook comments for drm_gem_shmem_object madvise field
On Tue, 12 Nov 2019 at 12:54, Thomas Hellstrom wrote:
>
> On 11/1/19 2:05 PM, Emil Velikov wrote:
> > From: Emil Velikov
> >
> > With earlier commit 9c84aeba67cc ("drm/vmwgfx: Kill unneeded legacy
> > security features") we removed the no longer applicable validation, as
> > we now have isolation
On Wed, 6 Nov 2019 at 16:30, Adrian Ratiu wrote:
>
> Convert the common bridge code and the two rockchip & stm drivers
> which currently use it to the regmap API in anticipation for further
> changes to make it more generic and add older DSI host controller
> support as found on i.mx6 based device
Hi Adrian,
On Wed, 6 Nov 2019 at 16:31, Adrian Ratiu wrote:
>
> Register existence, address/offsets, field layouts, reserved bits and
> so on differ between MIPI-DSI versions and between SoC vendor boards.
> Despite these differences the hw IP and protocols are mostly the same
> so the generic dr
Applied the series, although a couple of the patches were already
applied from a previous patch set.
Thanks,
Alex
On Wed, Nov 13, 2019 at 9:12 AM yu kuai wrote:
>
> This patch set fixes various unrelated gcc '-Wunused-but-set-variable'
> warnings.
>
> yu kuai (7):
> drm/amdgpu: remove set but
Den 13.11.2019 12.52, skrev Thomas Zimmermann:
> There are no callers of drm_fb_helper_unlink_fbi() left. Remove the
> function.
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Noralf Trønnes
___
dri-devel mailing list
dri-devel@lists.freed
Den 13.11.2019 12.52, skrev Thomas Zimmermann:
> The udl driver can use the generic fbdev implementation. Convert it.
>
> v4:
> * hardcode console bpp to 16
> v3:
> * remove module parameter fb_bpp in favor of fbdev's video
> * call drm_fbdev_generic_setup() directly; remove ud
Den 13.11.2019 12.52, skrev Thomas Zimmermann:
> There are no external callers of unlink_framebuffer() left. Make the
> function an internal interface.
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Noralf Trønnes
___
dri-devel mailing list
Hi
Am 13.11.19 um 16:26 schrieb Noralf Trønnes:
>
>
> Den 13.11.2019 12.52, skrev Thomas Zimmermann:
>> The udl driver can use the generic fbdev implementation. Convert it.
>>
>> v4:
>> * hardcode console bpp to 16
>> v3:
>> * remove module parameter fb_bpp in favor of fbdev's video
>>
On Wed, 6 Nov 2019 at 16:31, Adrian Ratiu wrote:
>
> This adds support for the Synopsis DesignWare MIPI DSI v1.01 host
> controller which is embedded in i.MX 6 SoCs.
>
> Based on following patches, but updated/extended to work with existing
> support found in the kernel:
>
> - drm: imx: Support Sy
Am 13.11.19 um 16:41 schrieb Thomas Zimmermann:
>> Either way you choose:
>
> Glad you like it :)
>
more like this
>>
>> Btw, nice diffstat!
Glad you like it :)
>>
>>> if (ret)
>>> goto err;
>>>
>>> @@ -367,6 +368,4 @@ void udl_fini(struct drm_device *dev)
>>>
>>> if
Hi,
On 12-11-2019 14:47, Daniel Vetter wrote:
On Tue, Nov 12, 2019 at 2:39 PM Hans de Goede wrote:
Hi,
On 12-11-2019 14:32, Daniel Vetter wrote:
On Tue, Nov 12, 2019 at 11:43 AM Hans de Goede wrote:
Hi,
On 12-11-2019 10:47, Daniel Vetter wrote:
On Sun, Nov 10, 2019 at 04:41:01PM +0100,
This patchset removes the load/unload callback functions from ast. Tested
on AST 2100 HW.
Thomas Zimmermann (2):
drm/ast: Replace drm_get_pci_device() and drm_put_dev()
drm/ast: Call struct drm_driver.{load,unload} before registering
device
drivers/gpu/drm/ast/ast_drv.c | 42
Both functions are deprecated. Open-code them them in preparation
of removing struct drm_driver.{load,unload}.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/ast/ast_drv.c | 31 +--
1 file changed, 29 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/a
Both callbacks are deprecated. Remove them and call functions explicitly.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/ast/ast_drv.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_drv.c b/drivers/gpu/drm/ast/ast_drv.c
index 78c90
On Wed, 6 Nov 2019 at 16:31, Adrian Ratiu wrote:
>
> Reviewed-by: Neil Armstrong
> Reviewed-by: Emil Velikov
Please drop this one. I'm not that experienced in DT to provide
meaningful review.
Actually, I've just noticed that respective maintainers/lists are not
CC'd on the series.
Please use th
On Mon, Nov 11, 2019 at 06:25:33PM +0100, Hans de Goede wrote:
> Hi,
>
> On 11-11-2019 13:53, Maxime Ripard wrote:
> > Hi Hans,
> >
> > Thanks for this series (and thanks for bouncing the mails too).
> >
> > All the previous patches are
> > Acked-by: Maxime Ripard
>
> Thank you for the review.
>
>
https://bugs.freedesktop.org/show_bug.cgi?id=23
--- Comment #4 from Leonardo da Silva ---
i have the same problem, I bought 2x 3400g with A320-S2H, one machine running
ubuntu 19.10 and the other Arch Linux, both with the same problem described
above when using integrated graphics.
--
You ar
On Wed, Nov 13, 2019 at 02:51:45PM +0100, Gerd Hoffmann wrote:
> Hi,
>
> > > ... but after looking again I think we are all green here. Given that
> > > only self-import works we'll only see vram gem objects in the mmap code
> > > path, which should have everything set up correctly. Same goes
On Wed, Nov 13, 2019 at 07:53:56AM -0600, Rob Herring wrote:
> On Wed, Nov 13, 2019 at 2:18 AM Daniel Vetter wrote:
> >
> > On Wed, Nov 13, 2019 at 8:39 AM Gerd Hoffmann wrote:
> > >
> > > Hi,
> > >
> > > > > > >> VRAM helpers use drm_gem_ttm_mmap(), which wraps
> > > > > > >> ttm_bo_mmap_obj(
On Wed, Nov 13, 2019 at 02:56:12PM +0100, Gerd Hoffmann wrote:
> When mapping ttm objects via drm_gem_ttm_mmap() helper
> drm_gem_mmap_obj() will take an object reference. That gets
> never released due to ttm having its own reference counting.
>
> Fix that by dropping the gem object reference on
On Wed, Nov 13, 2019 at 04:58:56PM +0100, Thomas Zimmermann wrote:
> Both functions are deprecated. Open-code them them in preparation
> of removing struct drm_driver.{load,unload}.
>
> Signed-off-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/ast/ast_drv.c | 31 +--
>
On Wed, 13 Nov 2019, Emil Velikov
wrote:
On Wed, 6 Nov 2019 at 16:30, Adrian Ratiu
wrote:
Convert the common bridge code and the two rockchip & stm
drivers which currently use it to the regmap API in
anticipation for further changes to make it more generic and
add older DSI host controlle
On Wed, Nov 13, 2019 at 05:35:41PM +0100, Daniel Vetter wrote:
> On Wed, Nov 13, 2019 at 04:58:56PM +0100, Thomas Zimmermann wrote:
> > Both functions are deprecated. Open-code them them in preparation
> > of removing struct drm_driver.{load,unload}.
> >
> > Signed-off-by: Thomas Zimmermann
> > -
On Wed, Nov 13, 2019 at 04:58:57PM +0100, Thomas Zimmermann wrote:
> Both callbacks are deprecated. Remove them and call functions explicitly.
>
> Signed-off-by: Thomas Zimmermann
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/ast/ast_drv.c | 13 +
> 1 file changed, 9 insertio
We are not supposed to modify the passed in string, make char pointers
used in drm_mode_parse_cmdline_options() const char * where possible.
Acked-by: Maxime Ripard
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/drm_modes.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
dif
Refactor drm_mode_parse_cmdline_options() so that it takes a pointer
to the first option, rather then a pointer to the ',' before the first
option.
This is a preparation patch for allowing parsing of stand-alone options
without a mode before them, e.g.: video=HDMI-1:margin_right=14,...
Acked-by:
Before this commit, if the last option of a video=... option is for
example "rotate" without a "=" after it then delim will point to
the terminating 0 of the string, and value which is sets to
will point one position past the end of the string.
This commit fixes this by enforcing that the content
Before this commit it was impossible to add an extra mode argument after
a bpp or refresh specifier, combined with an option, e.g.
video=HDMI-1:720x480-24e,rotate=180 would not work, either the "e" to
force enable would need to be dropped or the ",rotate=180", otherwise
the mode_option would not be
Sometimes we want to override a connector's panel_orientation from the
kernel commandline. Either for testing and for special cases, e.g. a kiosk
like setup which uses a TV mounted in portrait mode.
Users can already specify a "rotate" option through a video= kernel cmdline
option. But that only s
Instead of only setting mode->specified on false on an early exit and
leaving e.g. mode->bpp_specified and mode->refresh_specified as is,
lets be consistent and just zero out the entire passed in struct at
the top of drm_mode_parse_command_line_for_connector()
Signed-off-by: Hans de Goede
---
dr
Add a freestanding function argument to drm_mode_parse_cmdline_options()
similar to how drm_mode_parse_cmdline_extra() already has this.
This is a preparation patch for allowing parsing of stand-alone options
without a mode before them, e.g.: video=HDMI-1:margin_right=14,...
Acked-by: Maxime Ripa
drm_connector_get_cmdline_mode() calls
drm_mode_parse_command_line_for_connector() with &connector->cmdline_mode
as mode argument, so anything which we store in the mode arguments gets
kept even if we return false.
Avoid storing a possibly false-postive bpp/refresh_specified setting
in connector->
Before this commit it was impossible to combine an extra mode argument
specified directly after the resolution with an option, e.g.
video=HDMI-1:720x480e,rotate=180 would not work, either the "e" to force
enable would need to be dropped or the ",rotate=180", otherwise the
mode_option would not be a
From: Derek Basehore
Not every platform needs quirk detection for panel orientation, so
split the drm_connector_init_panel_orientation_property into two
functions. One for platforms without the need for quirks, and the
other for platforms that need quirks.
Hans de Goede (changes in v2):
Rename
Some options which can be specified on the commandline, such as
margin_right=..., margin_left=..., etc. are applied not only to the
specified mode, but to all modes. As such it would be nice if the user
can simply say e.g.
video=HDMI-1:margin_right=14,margin_left=24,margin_bottom=36,margin_top=42
fb_get_options() will return fb_mode_option if no video=
argument is present on the kernel commandline, so there is no need to also
do this in drm_mode_parse_command_line_for_connector() as our only caller
uses fb_get_options() to get the mode_option argument.
Changes in v2:
-Split out the changes
If the new video=... panel_orientation option is set for a connector, honor
it and setup a matching "panel orientation" property on the connector.
BugLink: https://gitlab.freedesktop.org/plymouth/plymouth/merge_requests/83
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/drm_connector.c | 7
On Wed, 2019-11-13 at 20:44 +0800, yu kuai wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c: In function
> ‘gfx_v6_0_constants_init’:
> drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c:1579:6: warning: variable
> ‘mc_shared_chmap’ set but not used [-Wunused-bu
2019. 11. 12. 17:41 keltezéssel, Ilia Mirkin írta:
On Tue, Nov 12, 2019 at 9:23 AM Böszörményi Zoltán wrote:
But no, all GPU devices (now only one, the UDL device) have screen 0
(a.k.a. DISPLAY=:0.0) set when AutoBindGPU is true:
[ 2444.576] xf86AutoConfigOutputDevices: xf86NumScreens 2 xf86N
Hi,
On 11/13/19 3:16 PM, Christoph Hellwig wrote:
On Wed, Nov 13, 2019 at 10:51:43AM +0100, Thomas Hellström (VMware) wrote:
From: Thomas Hellstrom
We're gradually moving towards using DMA coherent memory in most
situations, although TTM interactions with the DMA layers is still a
work-in-pro
On Wed, Nov 13, 2019 at 11:59 AM Böszörményi Zoltán wrote:
>
> 2019. 11. 12. 17:41 keltezéssel, Ilia Mirkin írta:
> > On Tue, Nov 12, 2019 at 9:23 AM Böszörményi Zoltán wrote:
> >> But no, all GPU devices (now only one, the UDL device) have screen 0
> >> (a.k.a. DISPLAY=:0.0) set when AutoBindGPU
On Wed, Nov 13, 2019 at 02:52:23PM +0100, Linus Walleij wrote:
> On Tue, Nov 5, 2019 at 4:41 PM Daniel Vetter wrote:
> > On Tue, Nov 5, 2019 at 4:29 PM Linus Walleij
> > wrote:
> > > On Tue, Nov 5, 2019 at 1:40 AM Dmitry Torokhov
> > > wrote:
>
> > > I'm happy to merge it into the GPIO tree if
Hi Thomas: See below
> On Nov 13, 2019, at 2:17 AM, Thomas Zimmermann wrote:
>
> Hi John
>
> Am 12.11.19 um 20:13 schrieb John Donnelly:
>>
>> In short . I started with :
>>
>> git bisect start
>>
>> git bisect bad be8454afc50f
>>
>> git bisect good fec88ab0af97
>>
>> And at the the
2019. 11. 13. 18:25 keltezéssel, Ilia Mirkin írta:
On Wed, Nov 13, 2019 at 11:59 AM Böszörményi Zoltán wrote:
2019. 11. 12. 17:41 keltezéssel, Ilia Mirkin írta:
On Tue, Nov 12, 2019 at 9:23 AM Böszörményi Zoltán wrote:
But no, all GPU devices (now only one, the UDL device) have screen 0
(a.
> > +/**
> > + * pin_user_pages_fast() - pin user pages in memory without taking locks
> > + *
> > + * Nearly the same as get_user_pages_fast(), except that FOLL_PIN is set.
> > See
> > + * get_user_pages_fast() for documentation on the function arguments,
> > because
> > + * the arguments here a
On Tue, Nov 12, 2019 at 08:26:50PM -0800, John Hubbard wrote:
> An upcoming patch uses try_get_compound_head() more widely,
> so move it to the top of gup.c.
>
> Also fix a tiny spelling error and a checkpatch.pl warning.
>
> Signed-off-by: John Hubbard
Simple enough...
Reviewed-by: Ira Weiny
On Wed, Nov 13, 2019 at 11:31:54AM +0200, Andy Shevchenko wrote:
> On Wed, Nov 13, 2019 at 08:38:15AM +0100, Arnd Bergmann wrote:
> > On Wed, Nov 13, 2019 at 8:27 AM Christoph Hellwig wrote:
> > >
> > > On Tue, Nov 12, 2019 at 10:24:23PM +, Luis Chamberlain wrote:
> > > > I think this would be
On Wed, Nov 13, 2019 at 2:43 AM Jan Kara wrote:
>
> On Tue 12-11-19 20:26:56, John Hubbard wrote:
> > Introduce pin_user_pages*() variations of get_user_pages*() calls,
> > and also pin_longterm_pages*() variations.
> >
> > These variants all set FOLL_PIN, which is also introduced, and
> > thoroug
On Tue, Nov 12, 2019 at 08:26:55PM -0800, John Hubbard wrote:
> As it says in the updated comment in gup.c: current FOLL_LONGTERM
> behavior is incompatible with FAULT_FLAG_ALLOW_RETRY because of the
> FS DAX check requirement on vmas.
>
> However, the corresponding restriction in get_user_pages_r
On Tue, Nov 12, 2019 at 08:26:56PM -0800, John Hubbard wrote:
> Introduce pin_user_pages*() variations of get_user_pages*() calls,
> and also pin_longterm_pages*() variations.
>
> These variants all set FOLL_PIN, which is also introduced, and
> thoroughly documented.
>
> The pin_longterm*() varia
On Tue, Nov 12, 2019 at 08:27:07PM -0800, John Hubbard wrote:
> Fix the gup benchmark flags to use the symbolic FOLL_WRITE,
> instead of a hard-coded "1" value.
>
> Also, clean up the filtering of gup flags a little, by just doing
> it once before issuing any of the get_user_pages*() calls. This
>
On Tue, Nov 12, 2019 at 08:27:08PM -0800, John Hubbard wrote:
> Up until now, gup_benchmark supported testing of the
> following kernel functions:
>
> * get_user_pages(): via the '-U' command line option
> * get_user_pages_longterm(): via the '-L' command line option
> * get_user_pages_fast(): as
On Tue, Nov 12, 2019 at 08:27:09PM -0800, John Hubbard wrote:
> It's good to have basic unit test coverage of the new FOLL_PIN
> behavior. Fortunately, the gup_benchmark unit test is extremely
> fast (a few milliseconds), so adding it the the run_vmtests suite
> is going to cause no noticeable chan
On Tue, Nov 12, 2019 at 08:27:10PM -0800, John Hubbard wrote:
> Now that all other kernel callers of get_user_pages(FOLL_LONGTERM)
> have been converted to pin_longterm_pages(), lock it down:
>
> 1) Add an assertion to get_user_pages(), preventing callers from
>passing FOLL_LONGTERM (in additi
On Tue, Nov 12, 2019 at 08:26:51PM -0800, John Hubbard wrote:
> An upcoming patch changes and complicates the refcounting and
> especially the "put page" aspects of it. In order to keep
> everything clean, refactor the devmap page release routines:
>
> * Rename put_devmap_managed_page() to page_is
On Wed, Nov 13, 2019 at 09:02:02AM -0400, Jason Gunthorpe wrote:
> On Tue, Nov 12, 2019 at 08:26:55PM -0800, John Hubbard wrote:
> > As it says in the updated comment in gup.c: current FOLL_LONGTERM
> > behavior is incompatible with FAULT_FLAG_ALLOW_RETRY because of the
> > FS DAX check requirement
On Wed, Nov 13, 2019 at 11:56 AM Joe Perches wrote:
>
> On Wed, 2019-11-13 at 20:44 +0800, yu kuai wrote:
> > Fixes gcc '-Wunused-but-set-variable' warning:
> >
> > drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c: In function
> > ‘gfx_v6_0_constants_init’:
> > drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c:1579:6: w
On Tue, Nov 12, 2019 at 8:27 PM John Hubbard wrote:
>
> An upcoming patch changes and complicates the refcounting and
> especially the "put page" aspects of it. In order to keep
> everything clean, refactor the devmap page release routines:
>
> * Rename put_devmap_managed_page() to page_is_devmap_
> On Nov 13, 2019, at 11:42 AM, John Donnelly
> wrote:
>
> Hi Thomas: See below
>
>> On Nov 13, 2019, at 2:17 AM, Thomas Zimmermann wrote:
>>
>> Hi John
>>
>> Am 12.11.19 um 20:13 schrieb John Donnelly:
>>>
>>> In short . I started with :
>>>
>>> git bisect start
>>>
>>> git bisec
On Wed, Nov 13, 2019 at 6:42 PM John Donnelly
wrote:
>
> Hi Thomas: See below
>
> > On Nov 13, 2019, at 2:17 AM, Thomas Zimmermann wrote:
> >
> > Hi John
> >
> > Am 12.11.19 um 20:13 schrieb John Donnelly:
> >>
> >> In short . I started with :
> >>
> >> git bisect start
> >>
> >> git bisect b
ING on linus/master]
[also build test WARNING on v5.4-rc7 next-20191113]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://sta
On 11/13/19 11:17 AM, Ira Weiny wrote:
...
@@ -348,33 +347,13 @@ static int vaddr_get_pfn(struct mm_struct *mm, unsigned
long vaddr,
flags |= FOLL_WRITE;
down_read(&mm->mmap_sem);
- if (mm == current->mm) {
- ret = get_user_pages(vaddr, 1, flags | FOLL_
On 11/13/19 10:59 AM, Ira Weiny wrote:
On Tue, Nov 12, 2019 at 08:26:56PM -0800, John Hubbard wrote:
Introduce pin_user_pages*() variations of get_user_pages*() calls,
and also pin_longterm_pages*() variations.
These variants all set FOLL_PIN, which is also introduced, and
thoroughly documented
On 11/13/19 3:43 AM, Daniel Vetter wrote:
...
Can't we call this unpin_user_page then, for some symmetry? Or is that
even more churn?
Looking from afar the naming here seems really confusing.
That look from afar is valuable, because I'm too close to the problem to see
how the naming looks. :)
1 - 100 of 141 matches
Mail list logo
