On 5/21/19 1:51 PM, Bartlomiej Zolnierkiewicz wrote:
> Add COMPILE_TEST support to gbefb driver for better compile
> testing coverage.
>
> While at it convert bogus udelay() calls to mdelay() (needed to
> build driver on ARM) and remove dead x86 specific code.
>
> Signed-off-by: Bartlomiej Zolni
On 5/21/19 12:53 PM, Bartlomiej Zolnierkiewicz wrote:
> Add COMPILE_TEST support to da8xx-fb driver for better compile
> testing coverage.
>
> Signed-off-by: Bartlomiej Zolnierkiewicz
I queued the patch for v5.3.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung
On 5/21/19 3:44 PM, Bartlomiej Zolnierkiewicz wrote:
> This is a PCI driver and FB_CYBER2000 depends on PCI in Kconfig so
> there is no need to check for PCI inside the driver code.
>
> Cc: Russell King
> Signed-off-by: Bartlomiej Zolnierkiewicz
I queued the patch for v5.3.
Best regards,
--
B
On 5/22/19 12:15 PM, Bartlomiej Zolnierkiewicz wrote:
> Reorder code a bit and then remove no longer needed function
> prototypes.
>
> Signed-off-by: Bartlomiej Zolnierkiewicz
I queued the patch for v5.3.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electron
On 5/24/19 1:58 PM, Bartlomiej Zolnierkiewicz wrote:
> Add COMPILE_TEST support to pvr2fb driver for better compile
> testing coverage.
>
> While at it:
>
> - mark pvr2fb_interrupt() and pvr2fb_common_init() with
> __maybe_unused tag (to silence build warnings when
> !SH_DREAMCAST)
>
> - co
Hi,
On Fri, Jun 07, 2019 at 03:07:18AM +, John Stultz wrote:
> This adds a CMA heap, which allows userspace to allocate
> a dma-buf of contiguous memory out of a CMA region.
>
> This code is an evolution of the Android ION implementation, so
> thanks to its original author and maintainters:
>
Le ven. 7 juin 2019 à 13:19, Philippe CORNU a écrit :
>
> Hi Yannick,
>
> Thank you for your patch
>
> Acked-by: Philippe Cornu
Applied on drm-misc-next
Thanks,
Benjamin
>
> Philippe :-)
>
> On 6/3/19 10:32 AM, Yannick Fertré wrote:
> > This patch enables runtime power management (runtime PM) s
Le ven. 7 juin 2019 à 10:51, Philippe CORNU a écrit :
>
> Hi Yannick,
>
> Thank you for your patch
>
> Acked-by: Philippe Cornu
Applied on drm-misc-next
Thanks,
Benjamin
> Philippe :-)
>
> On 6/3/19 10:31 AM, Yannick Fertré wrote:
> > Print display controller hardware version in debug mode onl
On the exporter side we add optional explicit pinning callbacks. If those
callbacks are implemented the framework no longer caches sg tables and the
map/unmap callbacks are always called with the lock of the reservation object
held.
On the importer side we add an optional invalidate callback. This
Avoid that we ping/pong the buffers when we stop to pin DMA-buf
exports by using the allowed domains for exported buffers.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/
Pipeline removal of the BOs backing store when no placement is given
during validation.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index c7de667d482a
Instead of relying on the DRM functions just implement our own import
functions. This prepares support for taking care of unpinned DMA-buf.
v2: enable for all exporters, not just amdgpu, fix invalidation
handling, lock reservation object while setting callback
v3: change to new dma_buf attach
The caching of SGT's is actually quite harmful and should probably removed
altogether when all drivers are audited.
Start by providing a separate DMA-buf export implementation in amdgpu. This is
also a prerequisite of unpinned DMA-buf handling.
v2: fix unintended recursion, remove debugging lefto
This way we can even pipeline imported BO evictions.
v2: Limit this to only cases when the parent object uses a separate reservation
object as well. This fixes another OOM problem.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo_util.c | 20 +++-
1 file changed
Hi John,
I haven't looked at any selftests before, but is there any advantage
to using the test harness?
https://www.kernel.org/doc/html/v5.1/dev-tools/kselftest.html#test-harness
Couple of minor things below
On Fri, Jun 07, 2019 at 03:07:19AM +, John Stultz wrote:
> Add very trivial allocat
On 03.06.2019 16:21, Colin King wrote:
> From: Colin Ian King
>
> The less than check for the variable num_lanes is always going to be
> false because the variable is a u32. Fix this by making num_lanes an
> int and also make loop index i an int too.
>
> Addresses-Coverity: ("Unsigned compared ag
On 07.06.2019 09:27, Dan Carpenter wrote:
> This should check that "i" is within bounds before checking reading from
> the array.
>
> Fixes: ff5781634c41 ("drm/bridge: sii902x: Implement HDMI audio support")
> Signed-off-by: Dan Carpenter
> ---
> drivers/gpu/drm/bridge/sii902x.c | 4 ++--
> 1 fil
https://bugs.freedesktop.org/show_bug.cgi?id=110795
--- Comment #9 from Andrew Shark ---
@Rolf, my script is specifically targeted at pro variant. I do not understand
your desire to use amd bundled archive for All-Open stack, because All-Open is
already provided by Ubuntu repos.
However, you can
Hi Neil,
Thank you for the patch.
On Mon, May 20, 2019 at 03:37:50PM +0200, Neil Armstrong wrote:
> This patch adds a new format_set() callback to the bridge ops permitting
> the encoder to specify the new input format and encoding.
>
> This allows supporting the very specific HDMI2.0 YUV420 out
https://bugs.freedesktop.org/show_bug.cgi?id=109206
--- Comment #48 from Alex Deucher ---
The patch is for the kernel.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #92 from magist3r ---
Just for the reference: screen flickering appears for me only with
amdgpu.ppfeaturemask=0x.
I think to flash my card with OC'ed BIOS and disable buggy OverDrive
completely.
--
You are receiving this m
On 07/06/2019 15:38, Laurent Pinchart wrote:
> Hi Neil,
>
> Thank you for the patch.
>
> On Mon, May 20, 2019 at 03:37:50PM +0200, Neil Armstrong wrote:
>> This patch adds a new format_set() callback to the bridge ops permitting
>> the encoder to specify the new input format and encoding.
>>
>> T
Hi Rodrigo,
On Thu, Jun 06, 2019 at 07:41:01PM -0300, Rodrigo Siqueira wrote:
> This patch implements the necessary functions to add writeback support
> for vkms. This feature is useful for testing compositors if you don’t
> have hardware with writeback support.
>
> Signed-off-by: Rodrigo Siqueir
On Fri, Jun 7, 2019 at 4:40 AM Daniel Vetter wrote:
>
> On Thu, Jun 06, 2019 at 07:40:38PM -0300, Rodrigo Siqueira wrote:
> > When vkms calls drm_universal_plane_init(), it sets 0 for the
> > possible_crtcs parameter which works well for a single encoder and
> > connector; however, this approach i
https://bugs.freedesktop.org/show_bug.cgi?id=110781
--- Comment #51 from Richard Thier ---
> I do have an old 1024x768 monitor with VGA input,
> I might give it a spin this weekend.
But didn't the LCD also supports smaler resolutions natively? Most of them do
even if their best native is more ex
On Fri, Jun 7, 2019 at 12:07 PM Bartlomiej Zolnierkiewicz
wrote:
>
>
> On 6/6/19 9:38 AM, Daniel Vetter wrote:
> > Hi Bart,
>
> Hi Daniel,
>
> > On Tue, May 28, 2019 at 11:02:31AM +0200, Daniel Vetter wrote:
> >> Hi all,
> >>
> >> I think we're slowly getting there. Previous cover letters with mor
This feature is only used by vmwgfx and superflous for everybody else.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 27 --
drivers/gpu/drm/ttm/ttm_bo_util.c| 1 -
drivers/gpu/drm/ttm/ttm_execbuf_util.c | 7 +
drivers/gpu/drm/vmwgfx
On Fri, Jun 07, 2019 at 01:14:57PM +0200, Benjamin Gaignard wrote:
> Le ven. 7 juin 2019 à 12:07, Emil Velikov a écrit :
> >
> > On Thu, 6 Jun 2019 at 22:15, Daniel Vetter wrote:
> > >
> > > I. was. blind.
> > >
> > > Caught with vkms, which has some really slow crc computation function.
> > >
>
On Fri, Jun 07, 2019 at 02:17:20PM +, Brian Starkey wrote:
> Hi Rodrigo,
>
> On Thu, Jun 06, 2019 at 07:41:01PM -0300, Rodrigo Siqueira wrote:
> > This patch implements the necessary functions to add writeback support
> > for vkms. This feature is useful for testing compositors if you don’t
>
On Thu, Jun 06, 2019 at 04:03:57PM +0200, Hans de Goede wrote:
> Hi,
>
> On 06-06-19 15:38, Maxime Ripard wrote:
> > On Thu, Jun 06, 2019 at 01:13:40PM +0200, Hans de Goede wrote:
> > > On 06-06-19 11:14, Maxime Ripard wrote:
> > > > On Fri, May 24, 2019 at 02:57:59PM +0200, Hans de Goede wrote:
>
https://bugs.freedesktop.org/show_bug.cgi?id=110781
--- Comment #52 from Alex Deucher ---
(In reply to Richard Thier from comment #51)
> > I do have an old 1024x768 monitor with VGA input,
> > I might give it a spin this weekend.
>
> But didn't the LCD also supports smaler resolutions natively?
On Fri, Jun 7, 2019 at 4:48 AM Daniel Vetter wrote:
>
> On Thu, Jun 06, 2019 at 07:41:01PM -0300, Rodrigo Siqueira wrote:
> > This patch implements the necessary functions to add writeback support
> > for vkms. This feature is useful for testing compositors if you don’t
> > have hardware with writ
One needs to set "(struct drm_device *)->irq_enabled = true" to signal drm core
to enable vblank interrupts after the hardware has been initialized.
Correspondingly, one needs to disable vblank interrupts by setting
"(struct drm_device *)->irq_enabled = false" at the beginning of the
de-initializin
On Fri, Jun 07, 2019 at 11:37:55AM -0300, Rodrigo Siqueira wrote:
> On Fri, Jun 7, 2019 at 4:40 AM Daniel Vetter wrote:
> >
> > On Thu, Jun 06, 2019 at 07:40:38PM -0300, Rodrigo Siqueira wrote:
> > > When vkms calls drm_universal_plane_init(), it sets 0 for the
> > > possible_crtcs parameter which
https://bugs.freedesktop.org/show_bug.cgi?id=110781
--- Comment #53 from Rui Salvaterra ---
(In reply to Richard Thier from comment #49)
> I don't get it. Is there no supported resolution below that big one? That is
> quite hard to believe. Mine is 1024x768 when maxed, but sometimes I reverse
> e
On Fri, Jun 07, 2019 at 02:05:13PM +0300, Jani Nikula wrote:
> We've moved the override and firmware EDID (simply "override EDID" from
> now on) handling to the low level drm_do_get_edid() function in order to
> transparently use the override throughout the stack. The idea is that
> you get the ove
https://bugs.freedesktop.org/show_bug.cgi?id=110781
--- Comment #54 from Richard Thier ---
> The GPU has a scaler that can scale a smaller image to the native timing.
> Many > LCD monitors also have a scaler built in to provide the same
> functionality.
I see, but still I see a big performanc
Hi Hean-Loong:
Please format your commit message like this:
Reviewed-by: Rob Herring
Signed-off-by: Ong, Hean Loong
---
V15:
v14:
The version history needs go after the ---
Dinh
On 6/7/19 9:30 AM, Hean-Loong, Ong wrote:
> From: "Ong, Hean Loong"
>
> Device tree binding for Intel FPGA Vi
https://bugs.freedesktop.org/show_bug.cgi?id=110781
--- Comment #55 from Alex Deucher ---
Performance will be better because the 3D engine is rendering to a smaller
surface (e.g., 640x480) regardless of whether you are fullscreen or windowed.
The size of the rendered image is what impact 3D perf
https://bugs.freedesktop.org/show_bug.cgi?id=110795
Andrew Shark changed:
What|Removed |Added
Attachment #144471|0 |1
is obsolete|
https://bugs.freedesktop.org/show_bug.cgi?id=110677
Michel Dänzer changed:
What|Removed |Added
Attachment #144269|text/x-log |text/plain
mime type|
https://bugs.freedesktop.org/show_bug.cgi?id=110781
--- Comment #56 from Rui Salvaterra ---
And speaking of performance, I wonder if this will have any effect… I'll try it
later.
https://git.congatec.com/android/qmx6_kernel/commit/a0a53aa8c7b491a43e2ef66786f9511bae8cbc35
--
You are receiving t
From: Ville Syrjälä
drm_mode_create_from_cmdline_mode() can return NULL, so the caller
should check for that.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_fb_helper.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/dr
From: Ville Syrjälä
Respect the user's choice of depth/bpp for the fbdev framebuffer
and throw out the fb we inherited from the BIOS if it doesn't
match.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_fbdev.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers
From: Ville Syrjälä
i915 will now refuse to enable a C8 plane unless the gamma_lut
is already enabled (to avoid scanning out whatever garbage got
left in the hw LUT previously). So in order to make the fbdev
code work with C8 we need to program the gamma_lut already
during restore_fbdev_mode_atom
From: Ville Syrjälä
If the user specifies zero width/height cmdline mode i915 will
blow up as the fbdev path will bypass the regular fb sanity
check that would otherwise have refused to create a framebuffer
with zero width/height.
The reason I thought to try this is so that I can force a specifi
https://bugs.freedesktop.org/show_bug.cgi?id=110795
Andrew Shark changed:
What|Removed |Added
Attachment #144478|0 |1
is obsolete|
https://bugs.freedesktop.org/show_bug.cgi?id=108309
--- Comment #10 from Jason Oliveira ---
Having the same issue, but it seems to be localized to Vulkan. I've confirmed
this on a Ryzen 2300U laptop and a desktop Ryzen 2400G. I have a save file in
Pac-Man Champion Edition DX+ that guaranteed will
On Thu, Jun 06, 2019 at 09:13:51AM +, Ser, Simon wrote:
> On Tue, 2019-06-04 at 17:15 +0200, Christian König wrote:
> > Am 04.06.19 um 17:05 schrieb Ser, Simon:
> > > Hi,
> > >
> > > I'm trying to link ALSA playback devices and DRM connectors. In other
> > > words, I'd like to be able to know
https://bugs.freedesktop.org/show_bug.cgi?id=110856
Bug ID: 110856
Summary: Freesync causes in-game blackscreens when game has low
fps.
Product: DRI
Version: XOrg git
Hardware: x86-64 (AMD64)
OS: Linux (All)
https://bugs.freedesktop.org/show_bug.cgi?id=110856
Arek Tumas changed:
What|Removed |Added
Priority|medium |high
--
You are receiving this mail becau
On Fri, Jun 7, 2019 at 12:24 AM Dave Airlie wrote:
>
> I sent this out earlier, but I forgot the subject, and then Ben asked
> about some nouveau firmware fixes.
Well, the first one at least had the address to pull from, and the diffstat.
The second one has the subject, and mentions nouveau, but
On Fri, Jun 7, 2019 at 10:20 AM Linus Torvalds
wrote:
>
> The second one has the subject, and mentions nouveau, but doesn't
> actually have the tag name or the expected diffstat and shortlog.
Hmm. I'm guessing you meant for me to pull the
'tags/drm-fixes-2019-06-07-1'
thing, which looks likel
On Thu, Jun 06, 2019 at 03:58:21PM -0700, Doug Anderson wrote:
> Hi,
>
> On Thu, Jun 6, 2019 at 9:42 AM Sean Paul wrote:
> >
> > On Tue, Jun 04, 2019 at 01:42:07PM -0700, Douglas Anderson wrote:
> > > On Rockchip rk3288-based Chromebooks when you do a suspend/resume
> > > cycle:
> > >
> > > 1. You
On Fri, Jun 07, 2019 at 03:03:39PM +, Ayan Halder wrote:
> One needs to set "(struct drm_device *)->irq_enabled = true" to signal drm
> core
> to enable vblank interrupts after the hardware has been initialized.
> Correspondingly, one needs to disable vblank interrupts by setting
> "(struct dr
On Fri, Jun 07, 2019 at 07:26:08PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> drm_mode_create_from_cmdline_mode() can return NULL, so the caller
> should check for that.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Daniel Vetter
Aside I noticed that we can drop a few EXPORT_SYMBO
On Fri, Jun 07, 2019 at 07:26:09PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> If the user specifies zero width/height cmdline mode i915 will
> blow up as the fbdev path will bypass the regular fb sanity
> check that would otherwise have refused to create a framebuffer
> with zero width
On Fri, Jun 07, 2019 at 07:26:10PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> i915 will now refuse to enable a C8 plane unless the gamma_lut
> is already enabled (to avoid scanning out whatever garbage got
> left in the hw LUT previously). So in order to make the fbdev
> code work with
On Fri, Jun 07, 2019 at 07:26:11PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Respect the user's choice of depth/bpp for the fbdev framebuffer
> and throw out the fb we inherited from the BIOS if it doesn't
> match.
>
> Signed-off-by: Ville Syrjälä
I guess we're going boom right now
No longer needed since the i915 initial config logic was pulled into
the shared helper by Noralf.
Spotted while reviewing patches from Ville.
Cc: Noralf Trønnes
Cc: Ville Syrjala
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_fb_helper.c | 9 +
include/drm/drm_fb_helper.h |
Sphinx doesn't like orphan documents:
Documentation/accelerators/ocxl.rst: WARNING: document isn't included in
any toctree
Documentation/arm/stm32/overview.rst: WARNING: document isn't included in
any toctree
Documentation/arm/stm32/stm32f429-overview.rst: WARNING: document isn't
in
Quoting Iurii Zaikin (2019-06-05 18:29:42)
> On Fri, May 17, 2019 at 11:22 AM Stephen Boyd wrote:
> >
> > Quoting Brendan Higgins (2019-05-14 15:17:10)
> > > diff --git a/kernel/sysctl-test.c b/kernel/sysctl-test.c
> > > new file mode 100644
> > > index 0..fe0f2bae66085
> > > --- /dev/
The opening comment mark "/**" is reserved for kernel-doc comments, so
it will generate a warning with "make W=1".
drivers/gpu/drm/drm_memory.c:2: warning: Cannot understand * \file
drm_memory.c
Also, silence a checkpatch warning by adding a license identfiter where
it indicates the MIT license
https://bugs.freedesktop.org/show_bug.cgi?id=110781
--- Comment #57 from Richard Thier ---
Hello everyone!
I have found one more place where we can end up calling extra ioctls for
GEM_CREATE. I remember telling you above after the very first proposed patch of
Marek, that "Interesting to me is th
Hello all,
So I've got a new IP on our new SoC I'm looking to make use of and would
like some help figuring out what framework best matches its function. The
IP is called a "Page-based Address Translator" or PAT. A PAT instance
(there are 5 of these things on our J721e device[0]) is basically a
re
This patch adds the bindings for the Page-based Address Translator (PAT)
present on various TI SoCs. A Page-based Address Translator (PAT) device
performs address translation using tables stored in an internal SRAM.
Each PAT supports a set number of pages, each occupying a programmable
4KB, 16KB, 6
This patch adds a driver for the Page-based Address Translator (PAT)
present on various TI SoCs. A PAT device performs address translation
using tables stored in an internal SRAM. Each PAT supports a set number
of pages, each occupying a programmable 4KB, 16KB, 64KB, or 1MB of
addresses in a window
https://bugs.freedesktop.org/show_bug.cgi?id=110781
--- Comment #58 from Richard Thier ---
The output from gdb glxgears on the segfault:
#0 0xb75a8892 in radeon_winsys_bo_create (rws=0x45e100, size=4096,
alignment=4096, domain=RADEON_DOMAIN_GTT, flags=(unknown: 0))
at radeon_drm_bo.c:993
#1
userspace may transfer a newline, and this terminating newline
is replaced by a '\0' to avoid followup issues.
'n-1' is the index to replace the newline of CRC source name.
v2: update patch subject, body and format. (Sam)
Cc: Leo Li
Cc: Harry Wentland
Cc: Sam Ravnborg
Signed-off-by: Dingchen
Hi Laurent,
On 28/05/2019 15:12, Laurent Pinchart wrote:
> The DRM core and DU driver guarantee that the LVDS bridge will not be
> double-enabled or double-disabled. Remove the corresponding unnecessary
> checks.
I'm glad to hear it - that's quite a few WARN_ON's removed which
hopefully is a good
https://bugs.freedesktop.org/show_bug.cgi?id=109887
--- Comment #6 from Jon Doane ---
I'm also having this particular issue with a Vega 64. It appears that setting
any non-stock voltage to any of the power states will cause the voltage at any
clock to jump to 1.20v. I haven't been able to find a
Hi Laurent,
On 28/05/2019 15:12, Laurent Pinchart wrote:
> The THC63LVD1024 LVDS decoder can operate in two modes, single-link or
> dual-link. In dual-link mode both input ports are used to carry even-
> and odd-numbered pixels separately. Document this in the DT bindings,
> along with the related
Hi Laurent,
On 28/05/2019 15:12, Laurent Pinchart wrote:
> Hello everybody,
>
> This patch series implements support for LVDS dual-link mode in the
> R-Car DU and R-Car LVDS encoder drivers, and well as in the thc63lvd1024
> LVDS decoder driver.
>
> LVDS dual-link is a mode of operation where tw
Hi Kieran,
On Fri, Jun 07, 2019 at 11:16:37PM +0100, Kieran Bingham wrote:
> On 28/05/2019 15:12, Laurent Pinchart wrote:
> > Hello everybody,
> >
> > This patch series implements support for LVDS dual-link mode in the
> > R-Car DU and R-Car LVDS encoder drivers, and well as in the thc63lvd1024
>
On Fri, Jun 7, 2019 at 12:00 PM Stephen Boyd wrote:
>
> Quoting Iurii Zaikin (2019-06-05 18:29:42)
> > On Fri, May 17, 2019 at 11:22 AM Stephen Boyd wrote:
> > >
> > > Quoting Brendan Higgins (2019-05-14 15:17:10)
> > > > diff --git a/kernel/sysctl-test.c b/kernel/sysctl-test.c
> > > > new file m
Hi Kieran,
On Fri, Jun 07, 2019 at 11:15:06PM +0100, Kieran Bingham wrote:
> On 28/05/2019 15:12, Laurent Pinchart wrote:
> > The THC63LVD1024 LVDS decoder can operate in two modes, single-link or
> > dual-link. In dual-link mode both input ports are used to carry even-
> > and odd-numbered pixels
On Thu, Jun 06, 2019 at 03:44:29PM -0300, Jason Gunthorpe wrote:
> From: Jason Gunthorpe
>
> Ralph observes that hmm_range_register() can only be called by a driver
> while a mirror is registered. Make this clear in the API by passing in the
> mirror structure as a parameter.
>
> This also simpl
Hi Laurent,
On 28/05/2019 15:12, Laurent Pinchart wrote:
> Add a new optional renesas,companion property to point to the companion
> LVDS encoder. This is used to support dual-link operation where the main
> LVDS encoder splits even-numbered and odd-numbered pixels between the
> two LVDS encoders.
Hi Laurent,
On 07/06/2019 23:30, Laurent Pinchart wrote:
> Hi Kieran,
>
> On Fri, Jun 07, 2019 at 11:15:06PM +0100, Kieran Bingham wrote:
>> On 28/05/2019 15:12, Laurent Pinchart wrote:
>>> The THC63LVD1024 LVDS decoder can operate in two modes, single-link or
>>> dual-link. In dual-link mode bot
On Thu, Jun 06, 2019 at 03:44:30PM -0300, Jason Gunthorpe wrote:
> From: Jason Gunthorpe
>
> So long a a struct hmm pointer exists, so should the struct mm it is
> linked too. Hold the mmgrab() as soon as a hmm is created, and mmdrop() it
> once the hmm refcount goes to zero.
>
> Since mmdrop()
On Thu, Jun 06, 2019 at 03:44:31PM -0300, Jason Gunthorpe wrote:
> From: Jason Gunthorpe
>
> As coded this function can false-fail in various racy situations. Make it
> reliable by running only under the write side of the mmap_sem and avoiding
> the false-failing compare/exchange pattern.
>
> Al
Hi Laurent,
On 28/05/2019 15:12, Laurent Pinchart wrote:
> Set a drm_bridge_timings in the drm_bridge, and use it to report the
> input bus mode (single-link or dual-link). The other fields of the
> timings structure are kept to 0 as they do not apply to LVDS buses.
>
> Signed-off-by: Laurent Pin
On Fri, Jun 07, 2019 at 10:31:07AM -0300, Jason Gunthorpe wrote:
> The wait_event_timeout macro already tests the condition as its first
> action, so there is no reason to open code another version of this, all
> that does is skip the might_sleep() debugging in common cases, which is
> not helpful.
On Thu, Jun 06, 2019 at 03:44:36PM -0300, Jason Gunthorpe wrote:
> From: Jason Gunthorpe
>
> Trying to misuse a range outside its lifetime is a kernel bug. Use WARN_ON
> and poison bytes to detect this condition.
>
> Signed-off-by: Jason Gunthorpe
> Reviewed-by: Jérôme Glisse
> ---
> v2
> - Ke
On Thu, Jun 06, 2019 at 03:44:37PM -0300, Jason Gunthorpe wrote:
> From: Jason Gunthorpe
>
> This list is always read and written while holding hmm->lock so there is
> no need for the confusing _rcu annotations.
>
> Signed-off-by: Jason Gunthorpe
> Reviewed-by: Jérôme Glisse
Reviewed-by: Ira
On Sat, 8 Jun 2019 at 03:24, Linus Torvalds
wrote:
>
> On Fri, Jun 7, 2019 at 10:20 AM Linus Torvalds
> wrote:
> >
> > The second one has the subject, and mentions nouveau, but doesn't
> > actually have the tag name or the expected diffstat and shortlog.
>
> Hmm. I'm guessing you meant for me to
Hi Laurent,
On 28/05/2019 15:12, Laurent Pinchart wrote:
> In dual-link mode the LVDS0 encoder transmits even-numbered pixels, and
> sends odd-numbered pixels to the LVDS1 encoder for transmission on a
> separate link.
>
> To implement support for this mode of operation, determine if the LVDS
> c
Hi Laurent,
On 28/05/2019 15:12, Laurent Pinchart wrote:
> Add the new renesas,companion property to the LVDS0 node to point to the
> companion LVDS encoder LVDS1.
>
> Signed-off-by: Laurent Pinchart
> Reviewed-by: Jacopo Mondi
> Tested-by: Jacopo Mondi
Reviewed-by: Kieran Bingham
> ---
>
Hi Laurent,
On 28/05/2019 15:12, Laurent Pinchart wrote:
> In dual-link LVDS mode, the LVDS1 encoder is used as a companion for
> LVDS0, and both encoders transmit data from DU0. The LVDS1 output of DU1
> can't be used in that case, don't create an encoder and connector for
> it.
>
> Signed-off-b
Hi Dave,
The following changes since commit a188339ca5a396acc588e5851ed7e19f66b0ebd9:
Linux 5.2-rc1 (2019-05-19 15:47:09 -0700)
are available in the Git repository at:
git://linuxtv.org/pinchartl/media.git tags/du-next-20190608
for you to fetch changes up to 8e8fddab0d0acdefb1ad76852d954b2
https://bugs.freedesktop.org/show_bug.cgi?id=110781
--- Comment #59 from Marek Olšák ---
Richard, your change for create_fence is correct.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@li
On Mon, Jun 03, 2019 at 06:55:05PM +0200, Andrey Konovalov wrote:
> This patch is a part of a series that extends arm64 kernel ABI to allow to
> pass tagged user pointers (with the top byte set to something else other
> than 0x00) as syscall arguments.
>
> strncpy_from_user and strnlen_user accept
On Mon, Jun 03, 2019 at 06:55:06PM +0200, Andrey Konovalov wrote:
> This patch is a part of a series that extends arm64 kernel ABI to allow to
> pass tagged user pointers (with the top byte set to something else other
> than 0x00) as syscall arguments.
>
> do_pages_move() is used in the implementa
On Mon, Jun 03, 2019 at 06:55:04PM +0200, Andrey Konovalov wrote:
> This patch is a part of a series that extends arm64 kernel ABI to allow to
> pass tagged user pointers (with the top byte set to something else other
> than 0x00) as syscall arguments.
>
> copy_from_user (and a few other similar f
On Mon, Jun 03, 2019 at 06:55:07PM +0200, Andrey Konovalov wrote:
> This patch is a part of a series that extends arm64 kernel ABI to allow to
> pass tagged user pointers (with the top byte set to something else other
> than 0x00) as syscall arguments.
>
> This patch allows tagged pointers to be p
On Mon, Jun 03, 2019 at 06:55:15PM +0200, Andrey Konovalov wrote:
> This patch is a part of a series that extends arm64 kernel ABI to allow to
> pass tagged user pointers (with the top byte set to something else other
> than 0x00) as syscall arguments.
>
> videobuf_dma_contig_user_get() uses provi
On Mon, Jun 03, 2019 at 06:55:18PM +0200, Andrey Konovalov wrote:
> This patch is a part of a series that extends arm64 kernel ABI to allow to
> pass tagged user pointers (with the top byte set to something else other
> than 0x00) as syscall arguments.
>
> This patch adds a simple test, that calls
On Mon, Jun 03, 2019 at 06:55:17PM +0200, Andrey Konovalov wrote:
> This patch is a part of a series that extends arm64 kernel ABI to allow to
> pass tagged user pointers (with the top byte set to something else other
> than 0x00) as syscall arguments.
>
> vaddr_get_pfn() uses provided user pointe
On Mon, Jun 03, 2019 at 06:55:08PM +0200, Andrey Konovalov wrote:
> This patch is a part of a series that extends arm64 kernel ABI to allow to
> pass tagged user pointers (with the top byte set to something else other
> than 0x00) as syscall arguments.
>
> mm/gup.c provides a kernel interface that
On Mon, Jun 03, 2019 at 06:55:09PM +0200, Andrey Konovalov wrote:
> This patch is a part of a series that extends arm64 kernel ABI to allow to
> pass tagged user pointers (with the top byte set to something else other
> than 0x00) as syscall arguments.
>
> get_vaddr_frames uses provided user point
101 - 200 of 205 matches
Mail list logo
