On Tue, 22 Jan 2019, Andrew F. Davis wrote:
> On 1/21/19 4:12 PM, Liam Mark wrote:
> > On Mon, 21 Jan 2019, Christoph Hellwig wrote:
> >
> >> On Mon, Jan 21, 2019 at 11:44:10AM -0800, Liam Mark wrote:
> >>> The main use case is for allowing clients to pass in
> >>> DMA_ATTR_SKIP_CPU_SYNC in
Add du node to r8a7744 SoC DT. Boards that want to enable the DU
need to specify the output topology.
Signed-off-by: Biju Das
---
arch/arm/boot/dts/r8a7744.dtsi | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/r8a7744.dtsi
On Tue, 22 Jan 2019, Greg Kroah-Hartman wrote:
> On Tue, Jan 15, 2019 at 03:18:56PM +1100, Finn Thain wrote:
> > The "generic" NVRAM module, drivers/char/generic_nvram.c, implements a
> > /dev/nvram misc device. This module is used only by 32-bit PowerPC
> > platforms.
> >
> > The RTC "CMOS"
Hello, Julien!
On 1/21/19 7:09 PM, Julien Grall wrote:
> Hello,
>
> On 21/01/2019 12:43, Oleksandr Andrushchenko wrote:
>> On 1/18/19 1:43 PM, Julien Grall wrote:
>>> On 18/01/2019 09:40, Oleksandr Andrushchenko wrote:
On 1/17/19 11:18 AM, Christoph Hellwig wrote:
> On Wed, Jan 16, 2019
On 1/22/19 10:28 AM, Oleksandr Andrushchenko wrote:
Hello, Julien!
Hi,
On 1/21/19 7:09 PM, Julien Grall wrote:
Well, I didn't get the attributes of pages at the backend side, but IMO
those
do not matter in my use-case (for simplicity I am not using zero-copying at
backend side):
They are
On Tue, 22 Jan 2019 at 21:56, Alex Deucher wrote:
>
> On Tue, Jan 22, 2019 at 4:19 AM Ard Biesheuvel
> wrote:
> >
> > On Mon, 21 Jan 2019 at 20:04, Michel Dänzer wrote:
> > >
> > > On 2019-01-21 7:28 p.m., Ard Biesheuvel wrote:
> > > > On Mon, 21 Jan 2019 at 19:24, Michel Dänzer wrote:
> > >
PTR_RET is deprecated and will be removed soon.
Use PTR_ERR_OR_ZERO instead.
Notice that these are the last instances of PTR_RET in the
whole codebase.
Signed-off-by: Gustavo A. R. Silva
---
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
On Tue, Jan 22, 2019 at 06:13:11AM -0800, Ronald Tschalär wrote:
> commit d6abe6df706c66d803e6dd4fe98c1b6b7f125a56 (drm/bridge:
> sil_sii8620: do not have a dependency of RC_CORE) added a dependency on
> INPUT. However, this causes problems with other drivers, in particular
> an input driver that
commit d6abe6df706c66d803e6dd4fe98c1b6b7f125a56 (drm/bridge:
sil_sii8620: do not have a dependency of RC_CORE) added a dependency on
INPUT. However, this causes problems with other drivers, in particular
an input driver that depends on MFD_INTEL_LPSS_PCI (to be added in a
future commit):
* Greg Kroah-Hartman [190122 15:28]:
> When calling debugfs functions, there is no need to ever check the
> return value. The function can work or not, but the code logic should
> never do something different based on this.
Acked-by: Tony Lindgren
This patch series aims to add display support for iWave G20D-Q7 board based on
RZ/G1N.
This patch series is tested against linux-next
V1--> V2
* Add DU support : Removed LVDS definition from r8a7743 DU node.
V2--> V3
* Added LVDS support for both r8a7743 and r8a7744 SoC.
Biju
On Mon, 21 Jan 2019, Brian Starkey wrote:
> Hi,
>
> Sorry for being a bit sporadic on this. I was out travelling last week
> with little time for email.
>
> On Fri, Jan 18, 2019 at 11:16:31AM -0600, Andrew F. Davis wrote:
> > On 1/17/19 7:11 PM, Liam Mark wrote:
> > > On Thu, 17 Jan 2019,
The LVDS encoders on RZ/G1N SoC is similar to RZ/G1M. Add support for
RZ/G1N (R8A7744) SoC to the LVDS encoder driver.
Signed-off-by: Biju Das
---
drivers/gpu/drm/rcar-du/rcar_lvds.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/rcar-du/rcar_lvds.c
On Mon, 21 Jan 2019, Brian Starkey wrote:
> Hi Liam,
>
> On Fri, Jan 18, 2019 at 10:37:47AM -0800, Liam Mark wrote:
> > Add support for configuring dma mapping attributes when mapping
> > and unmapping memory through dma_buf_map_attachment and
> > dma_buf_unmap_attachment.
> >
> > For example
On Tue, 22 Jan 2019, Andrew F. Davis wrote:
> On 1/21/19 4:18 PM, Liam Mark wrote:
> > On Mon, 21 Jan 2019, Andrew F. Davis wrote:
> >
> >> On 1/21/19 2:20 PM, Liam Mark wrote:
> >>> On Mon, 21 Jan 2019, Andrew F. Davis wrote:
> >>>
> On 1/21/19 1:44 PM, Liam Mark wrote:
> > On Mon, 21
Document the RZ/G1N (R8A7744) LVDS bindings.
Signed-off-by: Biju Das
---
Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt
From: Priit Laes
Even though HDMI connector features hotplug detect pin (HPD), there
are older devices which do not support it. For these devices fall
back to additional check on I2C bus to probe for EDID data.
One known example is HDMI/DVI display with following edid:
$ xxd -p display.edid
Quoting Joerg Roedel (2019-01-22 18:51:35)
> On Tue, Jan 22, 2019 at 04:48:26PM +0200, Joonas Lahtinen wrote:
> > According to our IOMMU folks there exists some desire to be able to assign
> > the iGFX device aka have intel_iommu=on instead of intel_iommu=igfx_off
> > due to how the devices might
https://bugs.freedesktop.org/show_bug.cgi?id=108031
--- Comment #2 from Alexander Schlarb ---
Created attachment 143205
--> https://bugs.freedesktop.org/attachment.cgi?id=143205=edit
4.19.0 Debian kernal boot log (external screen working)
I can reproduce this with
00:01.0 VGA compatible
On Wed, 2019-01-23 at 03:03 -0800, Kees Cook wrote:
> Variables declared in a switch statement before any case statements
> cannot be initialized, so move all instances out of the switches.
> After this, future always-initialized stack variables will work
> and not throw warnings like this:
>
>
On Wed, Jan 23, 2019 at 05:02:38PM +0200, Joonas Lahtinen wrote:
> We have many reports where just having intel_iommu=on (and using the
> system normally, without any virtualization stuff going on) will cause
> unexplained GPU hangs. For those users, simply switching to
> intel_iommu=igfx_off
On 1/22/19 11:33 AM, Sumit Semwal wrote:
> Hello everyone,
>
> Sincere apologies for chiming in a bit late here, but was off due to
> some health issues.
>
Hope you are feeling better friend :)
Looks like this email was a bit broken and you replied again, the
responses are a little different
Hi Daniel.
On Thu, Jan 17, 2019 at 10:03:34PM +0100, Daniel Vetter wrote:
> Having the probe helper stuff (which pretty much everyone needs) in
> the drm_crtc_helper.h file (which atomic drivers should never need) is
> confusing. Split them out.
>
> To make sure I actually achieved the goal here
On 1/22/19 9:23 PM, Sumit Semwal wrote:
> Hello everyone,
>
> (Thanks to Dan for letting me know my last email got corrupted :/ -
> resending it here)
>
Hmm, this one seems a bit messed up also (Thunderbird doesn't seem to
like it at least).
[snip]
> - from dma-buf PoV, ION is an exporter of
On Wed, 23 Jan 2019, Edwin Zimmerman wrote:
> On Wed, 23 Jan 2019, Jani Nikula wrote:
>> On Wed, 23 Jan 2019, Greg KH wrote:
>> > On Wed, Jan 23, 2019 at 03:03:47AM -0800, Kees Cook wrote:
>> >> Variables declared in a switch statement before any case statements
>> >> cannot be initialized, so
On Wed, Jan 23, 2019 at 03:49:02PM +0200, Imre Deak wrote:
> On Mon, Nov 12, 2018 at 06:59:59PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > On gen3 we must disable the TV encoder vertical filter for >1024
> > pixel wide sources. Once that's done all we can is try to center
> >
The current code allows the TCON clock divider to have a range between 4
and 127 when feeding the DSI controller.
The only display supported so far had a display clock rate that ended up
using a divider of 4, but testing with other displays show that only 4
seems to be functional.
This also
The current calculation for the video start delay in the current DSI driver
is that it is the total vertical size, minus the backporch and sync length,
plus 1.
However, the Allwinner code has it as the active vertical size, plus the
back porch and the sync length. This doesn't make any difference
Hi,
Here is a series implementing the burst mode support for DSI.
It's been tested on an A33 board with the panel supported on the 4th patch,
which should remove all quirks due to a different SoC from the equation.
Let me know what you think,
Maxime
Konstantin Sudakov (2):
drm/sun4i: dsi:
From: Konstantin Sudakov
The Rondo RB070D30 panel is a MIPI-DSI panel based on a Fitipower EK79007
controller and a 1024x600 panel.
Signed-off-by: Konstantin Sudakov
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/panel/Kconfig| 9 +-
drivers/gpu/drm/panel/Makefile
On Mon, Dec 17, 2018 at 02:35:05PM -0800, Jeykumar Sankaran wrote:
> Add display port support in DPU by creating hooks
> for DP encoder enumeration and encoder mode
> initialization.
>
> This change is based on the SDM845 Display port
> driver changes[1].
>
> changes in v2:
> - rebase on [2]
From: Konstantin Sudakov
The current driver doesn't support the DSI burst operation mode.
Let's add the needed quirks to make it work.
Signed-off-by: Konstantin Sudakov
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 178 +++---
1 file changed,
https://bugs.freedesktop.org/show_bug.cgi?id=105733
l...@protonmail.ch changed:
What|Removed |Added
CC||l...@protonmail.ch
--- Comment #57
https://bugs.freedesktop.org/show_bug.cgi?id=108031
--- Comment #4 from Alex Deucher ---
(In reply to Alex Deucher from comment #3)
> Remove amdgpu.dpm=1 from your kernel command line. The default dpm
> implementation changed in 4.19.
and setting dpm=1 overrides that resulting in different
Previously the heap to allocate from was selected by a mask of allowed
heap types. This may have been done as a primitive form of constraint
solving, the first heap type that matched any set bit of the heap mask
was allocated from, unless that heap was excluded by having its heap
ID bit not set in
https://bugs.freedesktop.org/show_bug.cgi?id=105733
--- Comment #58 from krutoiles...@gmail.com ---
The corruption suggestion is interesting. My RX580 does this and now it
won't even boot on windows anymore, just crashes.
On Wed, Jan 23, 2019, 12:44 PM l...@protonmail.ch changed bug 105733
>
Hi Andrew,
On Wed, Jan 23, 2019 at 10:51:24AM -0600, Andrew F. Davis wrote:
> On 1/22/19 11:33 AM, Sumit Semwal wrote:
> > Hello everyone,
> >
> > Sincere apologies for chiming in a bit late here, but was off due to
> > some health issues.
> >
>
> Hope you are feeling better friend :)
>
>
Paul Kocialkowski writes:
> From: Boris Brezillon
>
> The DRM framework provides a generic way to report underrun errors.
> Let's implement the necessary hooks to support it in the VC4 driver.
>
> Signed-off-by: Boris Brezillon
> ---
> Changes in v3:
> - Generic underrun report function has
On Wed, 23 Jan 2019 at 04:39, Christopher James Halse Rogers
wrote:
>
> We can't use drmSetMaster to query whether or not a drm fd is master
> because it requires CAP_SYS_ADMIN, even if the fd *is* a master fd.
>
> Pick DRM_IOCTL_MODE_ATTACHMODE as a long-deprecated ioctl that is
> DRM_MASTER but
Paul Kocialkowski writes:
> During an atomic commit, the HVS is configured with a display list
> for the channel matching the associated CRTC. The Pixel Valve (CRTC)
> and encoder are also configured for the new setup at that time.
> While the Pixel Valve and encoder are reconfigured
> syzbot is hitting a lockdep warning [1] because flush_work() is called
> without INIT_WORK() after kzalloc() at vkms_atomic_crtc_reset().
>
> Commit 6c234fe37c57627a ("drm/vkms: Implement CRC debugfs API") added
> INIT_WORK() to only vkms_atomic_crtc_duplicate_state() side. Assuming
> that
https://bugs.freedesktop.org/show_bug.cgi?id=108031
--- Comment #3 from Alex Deucher ---
Remove amdgpu.dpm=1 from your kernel command line. The default dpm
implementation changed in 4.19.
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=105733
--- Comment #60 from l...@protonmail.ch ---
dwagner, my problem persists even if I completely power the system down after
shutting it down by holding down the power button and then turning the PSU
completely off. I have not tried shutting it off
https://bugs.freedesktop.org/show_bug.cgi?id=105733
--- Comment #59 from dwagner ---
I don't think your observations indicate a hardware defect.
I have also a reproducible "hysteresis"-effect with regards to my RX460 GPU:
When I experience the bug scenario I reported in
https://bugs.freedesktop.org/show_bug.cgi?id=108916
--- Comment #1 from Axel Davy ---
Hi,
I just wanted to confirm the trace reproduces the issue, but it may not be a
nine issue but a radeonsi llvm issue. The trace has no glitches on llvmpipe.
--
You are receiving this mail because:
You are
On 24 January 2019 6:18:32 am NZDT, Emil Velikov
wrote:
>On Wed, 23 Jan 2019 at 04:39, Christopher James Halse Rogers
> wrote:
>>
>> We can't use drmSetMaster to query whether or not a drm fd is master
>> because it requires CAP_SYS_ADMIN, even if the fd *is* a master fd.
>>
>> Pick
https://bugzilla.kernel.org/show_bug.cgi?id=201497
--- Comment #6 from Daniel Andersson (engyw...@gmail.com) ---
Created attachment 280701
--> https://bugzilla.kernel.org/attachment.cgi?id=280701=edit
5.0-rc3 drm.debug=0x4
This is still an issue on 5.0-rc3.
--
You are receiving this mail
https://bugzilla.kernel.org/show_bug.cgi?id=201497
Daniel Andersson (engyw...@gmail.com) changed:
What|Removed |Added
Kernel Version|4.19|4.19 4.20 5.0-rc1
https://bugs.freedesktop.org/show_bug.cgi?id=109444
Bug ID: 109444
Summary: Graveyard Keeper: Lockup in under 5min of play.
Product: DRI
Version: unspecified
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
https://bugs.freedesktop.org/show_bug.cgi?id=109445
Bug ID: 109445
Summary: Graveyard Keeper: Lockup in under 5min of play.
Product: DRI
Version: unspecified
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
https://bugs.freedesktop.org/show_bug.cgi?id=109445
Mike Mestnik changed:
What|Removed |Added
URL||https://store.steampowered.
https://bugs.freedesktop.org/show_bug.cgi?id=109445
--- Comment #1 from Mike Mestnik
---
Created attachment 143210
--> https://bugs.freedesktop.org/attachment.cgi?id=143210=edit
ar file containing glxinfo and Xorg.log
--
You are receiving this mail because:
You are the assignee for the
Hello Dmity,
On Wed, Jan 23, 2019 at 02:03:42PM -0800, Dmitry Torokhov wrote:
> On Wed, Jan 23, 2019 at 09:45:56AM +0100, Lukas Wunner wrote:
> > On Tue, Jan 22, 2019 at 06:13:11AM -0800, Ronald Tschalär wrote:
> >> commit d6abe6df706c66d803e6dd4fe98c1b6b7f125a56 (drm/bridge:
> >> sil_sii8620: do
Hello Dmity,
On Wed, Jan 23, 2019 at 02:21:05PM -0800, Dmitry Torokhov wrote:
> On Thu, Jan 24, 2019 at 12:17:35AM +0200, Laurent Pinchart wrote:
> > On Wed, Jan 23, 2019 at 02:03:42PM -0800, Dmitry Torokhov wrote:
> >> On Wed, Jan 23, 2019 at 09:45:56AM +0100, Lukas Wunner wrote:
> >>> On Tue,
From: Jérôme Glisse
CPU page table update can happens for many reasons, not only as a result
of a syscall (munmap(), mprotect(), mremap(), madvise(), ...) but also
as a result of kernel activities (memory compression, reclaim, migration,
...).
Users of mmu notifier API track changes to the CPU
From: Jérôme Glisse
This update each existing invalidation to use the correct mmu notifier
event that represent what is happening to the CPU page table. See the
patch which introduced the events to see the rational behind this.
Signed-off-by: Jérôme Glisse
Cc: Christian König
Cc: Jan Kara
From: Jérôme Glisse
Hi Andrew, i see that you still have my event patch in you queue [1].
This patchset replace that single patch and is broken down in further
step so that it is easier to review and ascertain that no mistake were
made during mechanical changes. Here are the step:
Patch 1 -
From: Jérôme Glisse
CPU page table update can happens for many reasons, not only as a result
of a syscall (munmap(), mprotect(), mremap(), madvise(), ...) but also
as a result of kernel activities (memory compression, reclaim, migration,
...).
Users of mmu notifier API track changes to the CPU
From: Jérôme Glisse
CPU page table update can happens for many reasons, not only as a result
of a syscall (munmap(), mprotect(), mremap(), madvise(), ...) but also
as a result of kernel activities (memory compression, reclaim, migration,
...).
This patch introduce a set of enums that can be
From: Jérôme Glisse
Helper to test if a range is updated to read only (it is still valid
to read from the range). This is useful for device driver or anyone
who wish to optimize out update when they know that they already have
the range map read only.
Signed-off-by: Jérôme Glisse
Cc: Christian
From: Jérôme Glisse
When range of virtual address is updated read only and corresponding
user ptr object are already read only it is pointless to do anything.
Optimize this case out.
Signed-off-by: Jérôme Glisse
Cc: Christian König
Cc: Jan Kara
Cc: Felix Kuehling
Cc: Jason Gunthorpe
Cc:
From: Jérôme Glisse
When range of virtual address is updated read only and corresponding
user ptr object are already read only it is pointless to do anything.
Optimize this case out.
Signed-off-by: Jérôme Glisse
Cc: Christian König
Cc: Jan Kara
Cc: Felix Kuehling
Cc: Jason Gunthorpe
Cc:
From: Jérôme Glisse
When range of virtual address is updated read only and corresponding
user ptr object are already read only it is pointless to do anything.
Optimize this case out.
Signed-off-by: Jérôme Glisse
Cc: Christian König
Cc: Jan Kara
Cc: Felix Kuehling
Cc: Jason Gunthorpe
Cc:
From: Jérôme Glisse
When range of virtual address is updated read only and corresponding
user ptr object are already read only it is pointless to do anything.
Optimize this case out.
Signed-off-by: Jérôme Glisse
Cc: Christian König
Cc: Jan Kara
Cc: Felix Kuehling
Cc: Jason Gunthorpe
Cc:
On Wed, Jan 23, 2019 at 10:32:00PM +, Jason Gunthorpe wrote:
> On Wed, Jan 23, 2019 at 05:23:15PM -0500, jgli...@redhat.com wrote:
> > From: Jérôme Glisse
> >
> > When range of virtual address is updated read only and corresponding
> > user ptr object are already read only it is pointless to
From: Thierry Reding
Upon driver failure, the driver core will take care of clearing the
driver data, so there's no need to do so explicitly in the driver.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/tegra/vic.c | 1 -
1 file changed, 1 deletion(-)
diff --git
On Mon, Nov 12, 2018 at 06:59:59PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> On gen3 we must disable the TV encoder vertical filter for >1024
> pixel wide sources. Once that's done all we can is try to center
> the image on the screen. Naturally the TV mode vertical resolution
> must
On Mon, Nov 12, 2018 at 07:00:00PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Since gen3 can't handle >1024 wide sources with vertical scaling
> let's not advertize such modes in the mode list. Less tempetation
> to the user to try out things that won't work.
>
> Signed-off-by: Ville
On Wed, Jan 23, 2019 at 04:41:44PM +0300, Dmitry Osipenko wrote:
> 23.01.2019 12:39, Thierry Reding пишет:
> > From: Thierry Reding
> >
> > On Tegra186 and later, the ARM SMMU provides an input address space that
> > is 48 bits wide. However, memory clients can only address up to 40 bits.
> > If
On Wed, Jan 09, 2019 at 10:20:49AM +0100, Michel Dänzer wrote:
On 2019-01-08 8:25 p.m., Sasha Levin wrote:
From: Nicholas Kazlauskas
[ Upstream commit 520f08df45fbe300ed650da786a74093d658b7e1 ]
When variable refresh rate is active [...]
Variable refresh rate (FreeSync) support is only
On Wed, Jan 23, 2019 at 03:47:45PM +0300, Dmitry Osipenko wrote:
> 23.01.2019 12:39, Thierry Reding пишет:
> > From: Thierry Reding
> >
> > Loading the firmware requires an allocation of IOVA space to make sure
> > that the VIC's Falcon microcontroller can read the firmware if address
> >
https://bugzilla.kernel.org/show_bug.cgi?id=201273
--- Comment #31 from quirin.blae...@freenet.de ---
Bug is still alive. amd-staging-drm-next
9846725b3f1c54bdc072b42c9b67b8dd6fdf9a90
--
You are receiving this mail because:
You are watching the assignee of the bug.
On Tue, Jan 22, 2019 at 02:53:37PM -0500, Sean Paul wrote:
> On Tue, Jan 22, 2019 at 07:42:30PM +, Wentland, Harry wrote:
> >
> >
> > On 2019-01-22 2:19 p.m., Daniel Vetter wrote:
> > > On Tue, Jan 22, 2019 at 8:00 PM Wentland, Harry
> > > wrote:
> > >> On 2019-01-16 11:39 a.m., Daniel
On Wed, 23 Jan 2019, Daniel Stone wrote:
> If it helps, maybe we could draw up a list somewhere (README in igt?
> wiki?) of which tests seem to pass generically across a few drivers,
> which ones are expected to pass, which ones don't but really should,
> etc. I'm currently running on imx-drm
On Mon, 2019-01-07 at 12:58 +0100, Lucas Stach wrote:
> Am Freitag, den 21.12.2018, 12:11 +0100 schrieb Philipp Zabel:
> > Hi Lucas,
> >
> > > On Wed, Dec 19, 2018 at 4:40 PM Lucas Stach
> > > wrote:
> > >
> > > On a NOP double buffer update where current buffer address is the same
> > > as
Den 22.01.2019 20.30, skrev Daniel Vetter:
> On Tue, Jan 22, 2019 at 8:07 PM Noralf Trønnes wrote:
>>
>>
>>
>> Den 22.01.2019 10.32, skrev Daniel Vetter:
>>> On Mon, Jan 21, 2019 at 01:21:46PM +0100, Noralf Trønnes wrote:
Den 21.01.2019 10.55, skrev Daniel Vetter:
> On Mon,
The > should be >= to avoid an off by one bug.
Fixes: c46c24bb6b11 ("drm/komeda: Add komeda_framebuffer")
Signed-off-by: Dan Carpenter
---
I'm 98% sure this is correct, but please review it carefully because I'm
not 100% positive.
drivers/gpu/drm/arm/display/komeda/komeda_framebuffer.c | 2 +-
Make the video_setup() function slightly easier to read by removing the
repeated checks for !global. Remove the misleading return value comment
while at it.
I'm slightly hesitant to change any of this, but here goes anyway, with
hopes that the next person to have to look at this has it a wee bit
Hi Simon,
On Wed, Jan 23, 2019 at 09:56:57AM +0100, Simon Horman wrote:
> On Wed, Jan 23, 2019 at 12:54:04AM +0200, Laurent Pinchart wrote:
> > The LVDS1 encoder must supply a pixel clock to the DU for the DPAD
> > output when the LVDS0 encoder is used. Enable it despite its output not
> > being
On Tue, 22 Jan 2019, "Wentland, Harry" wrote:
> Would it make sense to append something like ", if such a test can be
> reasonably made using IGT for the target HW." to make it clear to
> contributors that in cases like the one discussed this is at the
> reviewers discretion?
I think the
update SPDX License Identifier from GPL-2.0+ to GPL-2.0
and drop some GPL text.
Signed-off-by: Sandy Huang
---
drivers/gpu/drm/rockchip/rockchip_rgb.c | 11 +--
drivers/gpu/drm/rockchip/rockchip_rgb.h | 11 +--
2 files changed, 2 insertions(+), 20 deletions(-)
diff --git
On Tue, Jan 22, 2019 at 07:34:55PM +0200, Ville Syrjälä wrote:
> On Tue, Jan 22, 2019 at 07:22:24PM +0200, Imre Deak wrote:
> > On Mon, Nov 12, 2018 at 06:59:58PM +0200, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > To make vblank timestamps work better with the TV encoder let's
> >
From: Emil Velikov
The functions are virtually identical, fold them up.
Signed-off-by: Emil Velikov
---
xf86drm.c | 98 +--
1 file changed, 15 insertions(+), 83 deletions(-)
diff --git a/xf86drm.c b/xf86drm.c
index 374734eb..18c9693a 100644
From: Emil Velikov
Some devices can lack OF data or it may not be available in the uevent
file. Fallback to the MODALIAS data in those cases.
We strip any leading "MODALIAS=.*:" thus the resulting information is
compatible with existing code in Mesa.
Signed-off-by: Emil Velikov
---
xf86drm.c
On Wed, Jan 23, 2019 at 12:11:36PM +0200, Jani Nikula wrote:
> On Wed, 23 Jan 2019, Daniel Stone wrote:
> > If it helps, maybe we could draw up a list somewhere (README in igt?
> > wiki?) of which tests seem to pass generically across a few drivers,
> > which ones are expected to pass, which ones
On Wed, Jan 23, 2019 at 12:03:40PM +0200, Jani Nikula wrote:
> On Tue, 22 Jan 2019, "Wentland, Harry" wrote:
> > Would it make sense to append something like ", if such a test can be
> > reasonably made using IGT for the target HW." to make it clear to
> > contributors that in cases like the one
On Wed, Jan 23, 2019 at 11:38:17AM +0200, Jani Nikula wrote:
> Make the video_setup() function slightly easier to read by removing the
> repeated checks for !global. Remove the misleading return value comment
> while at it.
>
> I'm slightly hesitant to change any of this, but here goes anyway,
On Tue, Jan 22, 2019 at 08:19:10PM +0100, Daniel Vetter wrote:
> On Tue, Jan 22, 2019 at 8:00 PM Wentland, Harry
> wrote:
> > On 2019-01-16 11:39 a.m., Daniel Vetter wrote:
> > > Compared to the RFC[1] no changes to the patch itself, but igt moved
> > > forward a lot:
> > >
> > > - gitlab CI
From: Thierry Reding
Loading the firmware requires an allocation of IOVA space to make sure
that the VIC's Falcon microcontroller can read the firmware if address
translation via the SMMU is enabled.
However, the allocation currently happens at a time where the geometry
of an IOMMU domain may
From: Thierry Reding
Move initialization of the shared IOMMU domain after the host1x device
has been initialized. At this point all the Tegra DRM clients have been
attached to the shared IOMMU domain.
This is important because Tegra186 and later use an ARM SMMU, for which
the driver defers
From: Thierry Reding
On Tegra186 and later, the ARM SMMU provides an input address space that
is 48 bits wide. However, memory clients can only address up to 40 bits.
If the geometry is used as-is, allocations of IOVA space can end up in a
region that cannot be addressed by the memory clients.
From: Thierry Reding
Tegra186 and later are different than earlier generations in that they
use an ARM SMMU rather than the Tegra SMMU. The ARM SMMU driver behaves
slightly differently in that the geometry for IOMMU domains is set only
after a device was attached to it. This is to make sure that
From: Thierry Reding
The host1x and clients instantiated on Tegra186 support addressing 40
bits of memory.
Signed-off-by: Thierry Reding
---
drivers/gpu/host1x/dev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/host1x/dev.c b/drivers/gpu/host1x/dev.c
index
From: Thierry Reding
Tegra DRM clients need access to their parent, so store a pointer to it
upon registration.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/tegra/drm.c | 2 ++
drivers/gpu/drm/tegra/drm.h | 1 +
2 files changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/tegra/drm.c
Hi,
On Tue, 22 Jan 2019 at 19:42, Wentland, Harry wrote:
> On 2019-01-22 2:19 p.m., Daniel Vetter wrote:
> > I'd say we'll shrug these cases off as "can't be reasonable tested,
> > won't have an igt". First driver team with hw that can be validated
> > gets to fill the gaps :-) In practice still
On Wed, Jan 23, 2019 at 09:40:34AM +, Brian Starkey wrote:
> On Tue, Jan 22, 2019 at 08:19:10PM +0100, Daniel Vetter wrote:
> > On Tue, Jan 22, 2019 at 8:00 PM Wentland, Harry
> > wrote:
> > > On 2019-01-16 11:39 a.m., Daniel Vetter wrote:
> > > > Compared to the RFC[1] no changes to the
On Wed, Jan 23, 2019 at 03:28:59PM +0800, Tina Zhang wrote:
> This patch prevents division by zero htotal.
How did you manage to get here with htotal == 0? This needs backtraces
(or if this is just about static checkers, a mention of that).
-Daniel
>
> Signed-off-by: Tina Zhang
> Cc: Adam
Hi Andrzej,
On 09/01/19 12:12, Andrzej Hajda wrote:
> On 09.01.2019 10:51, Lucas Stach wrote:
>> Am Mittwoch, den 09.01.2019, 11:12 +0200 schrieb Tomi Valkeinen:
>>> Hi Andrzej,
>>>
>>> On 09/01/19 10:22, Andrzej Hajda wrote:
Hi Tomi,
On 03.01.2019 12:59, Tomi Valkeinen wrote:
On Wed, Jan 23, 2019 at 12:35:02PM +0100, Philipp Zabel wrote:
> On Fri, 2018-10-05 at 17:11 +0200, Philipp Zabel wrote:
> > On Fri, 2018-09-14 at 18:59 +0200, Lucas Stach wrote:
> > > Currently there is a small race window where we could manage to arm the
> > > vblank event from atomic flush, but
On Wed, Jan 23, 2019 at 03:38:45PM +1100, Christopher James Halse Rogers wrote:
> We can't use drmSetMaster to query whether or not a drm fd is master
> because it requires CAP_SYS_ADMIN, even if the fd *is* a master fd.
>
> Pick DRM_IOCTL_MODE_ATTACHMODE as a long-deprecated ioctl that is
>
1 - 100 of 129 matches
Mail list logo
