tree: git://people.freedesktop.org/~agd5f/linux.git drm-next-4.19
head: a21daa88d4f08c959a36ad9760df045407a080e5
commit: 6e0ef9d85b99baeeea4b9c4a9777809cb0c6040a [82/100] drm/amd/display:
Write TEST_EDID_CHECKSUM_WRITE for EDID tests
config: x86_64-randconfig-g0-06231137 (attached as .config)
On 06/22/2018 09:03 PM, Andrey Grodzovsky wrote:
On 06/22/2018 02:56 PM, Lyude Paul wrote:
On Fri, 2018-06-22 at 13:34 -0400, Andrey Grodzovsky wrote:
On 06/21/2018 04:48 PM, Lyude Paul wrote:
This fixes a regression I accidentally reduced that was picked up by
kasan, where we were checkin
https://bugs.freedesktop.org/show_bug.cgi?id=106490
--- Comment #5 from MWATTT ---
I have this problem too.
A workaround is to set the driconf option "allow_rgb10_configs" to false for
chromium-browser.
This problem affects radeonsi and r600g, but not i965.
--
You are receiving this mail becaus
On 06/22/2018 02:56 PM, Lyude Paul wrote:
On Fri, 2018-06-22 at 13:34 -0400, Andrey Grodzovsky wrote:
On 06/21/2018 04:48 PM, Lyude Paul wrote:
This fixes a regression I accidentally reduced that was picked up by
kasan, where we were checking the CRTC atomic states after DRM's helpers
had alr
On Fri, Jun 22, 2018 at 11:34 PM, Kees Cook wrote:
> On Fri, Jun 22, 2018 at 10:50 AM, Karol Herbst wrote:
>> On Thu, May 24, 2018 at 7:24 PM, Kees Cook wrote:
>>> In the quest to remove all stack VLA usage from the kernel[1], this
>>> allocates the working buffers before starting the writing so
Hi Dave,
A fix for a potential use after free introduced in a previous stable fix
for runtime pm.
The following changes since commit f3294568bbb19cbfc53451de192df6daae80f9b3:
Merge tag 'drm-misc-fixes-2018-06-21' of
git://anongit.freedesktop.org/drm/drm-misc into drm-fixes (2018-06-22 11:03:4
On 2018-06-22 11:24 AM, Michal Hocko wrote:
> On Fri 22-06-18 17:13:02, Christian König wrote:
>> Hi Michal,
>>
>> [Adding Felix as well]
>>
>> Well first of all you have a misconception why at least the AMD graphics
>> driver need to be able to sleep in an MMU notifier: We need to sleep because
>>
On Fri, 2018-06-22 at 13:34 -0400, Andrey Grodzovsky wrote:
>
> On 06/21/2018 04:48 PM, Lyude Paul wrote:
> > This fixes a regression I accidentally reduced that was picked up by
> > kasan, where we were checking the CRTC atomic states after DRM's helpers
> > had already freed them. Example:
> >
On 2018-06-21 04:48 PM, Lyude Paul wrote:
> This fixes a regression I accidentally reduced that was picked up by
> kasan, where we were checking the CRTC atomic states after DRM's helpers
> had already freed them. Example:
>
> ==
> BU
On Thu, May 24, 2018 at 7:24 PM, Kees Cook wrote:
> In the quest to remove all stack VLA usage from the kernel[1], this
> allocates the working buffers before starting the writing so it won't
> abort in the middle. This needs an initial walk of the lists to figure
> out how large the buffer should
On 2018-06-22 21:03, Jordan Crouse wrote:
On Fri, Jun 22, 2018 at 09:51:28AM -0400, Sean Paul wrote:
On Wed, May 30, 2018 at 10:50 AM Rajesh Yadav
wrote:
>
> From: Jordan Crouse
>
> Remove unused code from dpu_io_util.c. The functions are only
> used inside of the msm driver so remove the EX
On 06/21/2018 04:48 PM, Lyude Paul wrote:
This fixes a regression I accidentally reduced that was picked up by
kasan, where we were checking the CRTC atomic states after DRM's helpers
had already freed them. Example:
==
BUG: KASAN
On Fri, Jun 22, 2018 at 06:42:43PM +0200, Michal Hocko wrote:
> [Resnding with the CC list fixed]
>
> On Fri 22-06-18 18:40:26, Michal Hocko wrote:
> > On Fri 22-06-18 12:18:46, Jerome Glisse wrote:
> > > On Fri, Jun 22, 2018 at 05:57:16PM +0200, Michal Hocko wrote:
> > > > On Fri 22-06-18 16:36:4
https://bugs.freedesktop.org/show_bug.cgi?id=102962
--- Comment #10 from amd_user ---
Why does the system freeze when selecting Symmetra in the Hero Selection
screen? Is it a mesa bug or wine bug?
linux 4.17.2
amd ryzen 3
mesa 18.1.2
wine-staging 3.10
--
You are receiving this mail because:
Yo
https://bugs.freedesktop.org/show_bug.cgi?id=106418
--- Comment #6 from Michel Dänzer ---
(In reply to davep from comment #5)
> My name's Dave Panariti (david.and I'm going to be taking a look at this.
Thanks for looking into this, Dave. After hitting the BUG_ON again this week, I
got fed up, to
[Resnding with the CC list fixed]
On Fri 22-06-18 18:40:26, Michal Hocko wrote:
> On Fri 22-06-18 12:18:46, Jerome Glisse wrote:
> > On Fri, Jun 22, 2018 at 05:57:16PM +0200, Michal Hocko wrote:
> > > On Fri 22-06-18 16:36:49, Chris Wilson wrote:
> > > > Quoting Michal Hocko (2018-06-22 16:02:42)
https://bugs.freedesktop.org/show_bug.cgi?id=106928
--- Comment #2 from Roland Scheidegger ---
Definitely looks like a r600 issue, in the sb code (I suppose it would work
with R600_DEBUG=nosb).
An apitrace might be helpful (it should be possible to capture one with nosb so
it doesn't crash and th
[Hmm, the cc list got mangled somehow - you have just made many people
to work for suse ;) and to kvack.org in the preious one - fixed up
hopefully]
On Fri 22-06-18 17:07:21, Chris Wilson wrote:
> Quoting Michal Hocko (2018-06-22 16:57:16)
> > On Fri 22-06-18 16:36:49, Chris Wilson wrote:
> > > Qu
On Fri, Jun 22, 2018 at 05:57:16PM +0200, Michal Hocko wrote:
> On Fri 22-06-18 16:36:49, Chris Wilson wrote:
> > Quoting Michal Hocko (2018-06-22 16:02:42)
> > > Hi,
> > > this is an RFC and not tested at all. I am not very familiar with the
> > > mmu notifiers semantics very much so this is a cru
Hi Christian,
I love your patch! Yet something to improve:
[auto build test ERROR on drm/drm-next]
[also build test ERROR on v4.18-rc1 next-20180622]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux
On Fri 22-06-18 16:36:49, Chris Wilson wrote:
> Quoting Michal Hocko (2018-06-22 16:02:42)
> > Hi,
> > this is an RFC and not tested at all. I am not very familiar with the
> > mmu notifiers semantics very much so this is a crude attempt to achieve
> > what I need basically. It might be completely
https://bugs.freedesktop.org/show_bug.cgi?id=106999
--- Comment #14 from Ilia Mirkin ---
(In reply to Mike Lothian from comment #13)
> I know my SkyQ box outputs at 2160@60Hz in 10bit colour
https://en.wikipedia.org/wiki/HDMI#Refresh_frequency_limits_for_HDR10_video
4k@60@10bpc needs YUV 4:2:2
Quoting Michal Hocko (2018-06-22 16:02:42)
> Hi,
> this is an RFC and not tested at all. I am not very familiar with the
> mmu notifiers semantics very much so this is a crude attempt to achieve
> what I need basically. It might be completely wrong but I would like
> to discuss what would be a bett
On Fri, Jun 22, 2018 at 09:51:28AM -0400, Sean Paul wrote:
> On Wed, May 30, 2018 at 10:50 AM Rajesh Yadav wrote:
> >
> > From: Jordan Crouse
> >
> > Remove unused code from dpu_io_util.c. The functions are only
> > used inside of the msm driver so remove the EXPORT_SYMBOL
> > tags and move the
https://bugs.freedesktop.org/show_bug.cgi?id=106999
--- Comment #13 from Mike Lothian ---
What is Raven capable of? I know my SkyQ box outputs at 2160@60Hz in 10bit
colour
--
You are receiving this mail because:
You are the assignee for the bug.___
dr
On Fri 22-06-18 17:13:02, Christian König wrote:
> Hi Michal,
>
> [Adding Felix as well]
>
> Well first of all you have a misconception why at least the AMD graphics
> driver need to be able to sleep in an MMU notifier: We need to sleep because
> we need to wait for hardware operations to finish
https://bugs.freedesktop.org/show_bug.cgi?id=106999
--- Comment #12 from Alex Deucher ---
>From what I can see the HDMI 2.0 spec only supports 4k@60 at 8 bpc. I think
you need HDMI 2.1 for 4k@60 with 10 bpc or greater.
--
You are receiving this mail because:
You are the assignee for the bug.__
Hi Michal,
[Adding Felix as well]
Well first of all you have a misconception why at least the AMD graphics
driver need to be able to sleep in an MMU notifier: We need to sleep
because we need to wait for hardware operations to finish and *NOT*
because we need to wait for locks.
I'm not sure
On 06/22/2018 02:30 PM, Maarten Lankhorst wrote:
Op 22-06-18 om 12:41 schreef Mahesh Kumar:
This reverts commit e8fa5671183c80342d520ad81d14fa79a9d4a680.
Don't wait for first CRC during crtc_crc_open. It avoids one frame wait
during open. If application want to wait after read call, it can use
From: Michal Hocko
There are several blockable mmu notifiers which might sleep in
mmu_notifier_invalidate_range_start and that is a problem for the
oom_reaper because it needs to guarantee a forward progress so it cannot
depend on any sleepable locks. Currently we simply back off and mark an
oom
On Fri, Jun 22, 2018 at 10:31:42AM +0200, Daniel Vetter wrote:
> On Thu, Jun 21, 2018 at 05:04:02PM -0600, Jordan Crouse wrote:
> > If a encoder name isn't specified for drm_encoder_init() it will try
> > to construct one based on the incoming encoder_type identifier. If the
> > caller passes an in
Hi Dave,
A small set of fixes for mali-dp that I should have sent earlier.
Many thanks!
Liviu
The following changes since commit ce397d215ccd07b8ae3f71db689aedb85d56ab40:
Linux 4.18-rc1 (2018-06-17 08:04:49 +0900)
are available in the Git repository at:
git://linux-arm.org/linux-ld.git f
https://bugs.freedesktop.org/show_bug.cgi?id=107001
Michel Dänzer changed:
What|Removed |Added
Component|Other |Drivers/Gallium/radeonsi
QA Con
On Fri, Jun 22, 2018 at 6:37 AM, Christian König
wrote:
> Some functions are unused after removal of the kmap_atomic
> DMA-buf interface.
>
> Signed-off-by: Christian König
> Fixes: f664a5269542 ("dma-buf: remove kmap_atomic interface")
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/omapdr
https://bugs.freedesktop.org/show_bug.cgi?id=106879
--- Comment #5 from Alex Deucher ---
Is this a regression? If so, can you bisect? Does setting amdgpu.runpm=0 on
the kernel commandline in grub help?
--
You are receiving this mail because:
You are the assignee for the bug.__
https://bugs.freedesktop.org/show_bug.cgi?id=106999
--- Comment #11 from Mike Lothian ---
It might be the same, the EDID says the TV is capable of both 10bit and 12bit
colour, I was under the impression that HDMI 2 was able to do 2160p@60Hz at
those colour depths
--
You are receiving this mail
First step towards unpinned DMA buf operation.
I've checked the DRM drivers to potential locking of the reservation
object, but essentially we need to audit all implementations of the
dma_buf _ops for this to work.
v2: reordered
Signed-off-by: Christian König
---
drivers/dma-buf/dma-buf.c | 9
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 done by the DRM code is actually quite harmful and
should probably removed altogether in the long term.
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 debugg
Add function variants which can be called with the reservation lock
already held.
v2: reordered, add lockdep asserts, fix kerneldoc
Signed-off-by: Christian König
---
drivers/dma-buf/dma-buf.c | 57 +++
include/linux/dma-buf.h | 5 +
2 files ch
[As requested by Daniel cross posting to intel-gfx as well].
This set is the first step towards allowing to use a DMA-buf without actually
pinning the underlying resources. This in turn the the ground work for PCIe P2P
operations as well as quite a bunch of other use cases.
The idea is that we
Each fence object holds function pointers of the module that initialized
it. Allowing the module to unload before this fence's release is
catastrophic. So, keep a refcount on the module until the fence is
released.
Signed-off-by: Akhil P Oommen
---
Changes in v2:
- added description for the new f
Hi Ard,
On 6/22/2018 7:21 AM, Ard Biesheuvel wrote:
> Apologies for only bringing this up now, but I think this patch is
> wrong after all.
>
> screen_info.lfb_base is supposed to be a CPU address, and so
> translating it like this is wrong. If you end up with a PCI address
> here, you have made
On 13 June 2018 at 18:08, Bartlomiej Zolnierkiewicz
wrote:
> On Wednesday, June 13, 2018 05:45:48 PM Ard Biesheuvel wrote:
>> On 18 May 2018 at 16:17, Sinan Kaya wrote:
>> > A host bridge is allowed to remap BAR addresses using _TRA attribute in
>> > _CRS windows.
>> >
>> > pci_bus :00: root
On 20 June 2018 at 00:29, Bjorn Helgaas wrote:
> Minor subject nit: From the caller's point of view, we must convert a bus
> address to a resource *always* (the caller has no knowledge of "whether it
> is translated by the host bridge").
>
> On Fri, May 18, 2018 at 10:17:51AM -0400, Sinan Kaya wro
On 6/22/2018 3:38 PM, Chris Wilson wrote:
Quoting Gustavo Padovan (2018-06-22 11:04:16)
Hi Akhil,
On Fri, 2018-06-22 at 15:10 +0530, Akhil P Oommen wrote:
Each fence object holds function pointers of the module that
initialized
it. Allowing the module to unload before this fence's release is
Hi Thierry,
> This commit adds support for KOE's 5.7" display.
>
> Signed-off-by: Lukasz Majewski
> Reviewed-by: Rob Herring
> ---
> Changes for v2:
> - Add Reviewed-by tag
Could you apply this patch to your tree?
Thanks in advance,
Łukasz
>
> ---
> .../bindings/display/panel/koe,tx14d24vm
On 22 June 2018 at 15:52, Sinan Kaya wrote:
> Hi Ard,
>
> On 6/22/2018 7:21 AM, Ard Biesheuvel wrote:
>> Apologies for only bringing this up now, but I think this patch is
>> wrong after all.
>>
>> screen_info.lfb_base is supposed to be a CPU address, and so
>> translating it like this is wrong. I
https://bugs.freedesktop.org/show_bug.cgi?id=106999
Michel Dänzer changed:
What|Removed |Added
CC||harry.wentl...@amd.com,
On Wed, May 30, 2018 at 10:50 AM Rajesh Yadav wrote:
>
> From: Jordan Crouse
>
> Remove unused code from dpu_io_util.c. The functions are only
> used inside of the msm driver so remove the EXPORT_SYMBOL
> tags and move the header dpu_io_util.h from include/linux.
>
> Signed-off-by: Jordan Crouse
Am 18.06.2018 um 10:28 schrieb Daniel Vetter:
On Fri, Jun 01, 2018 at 02:00:20PM +0200, Christian König wrote:
The caching of SGT's done by the DRM code is actually quite harmful and
should probably removed altogether in the long term.
Hm, why is it harmful? We've done it because it's expensive
Op 22-06-18 om 12:41 schreef Mahesh Kumar:
> This reverts commit e8fa5671183c80342d520ad81d14fa79a9d4a680.
>
> Don't wait for first CRC during crtc_crc_open. It avoids one frame wait
> during open. If application want to wait after read call, it can use
> poll/read blocking read() call.
>
> Suggest
https://bugs.freedesktop.org/show_bug.cgi?id=106999
--- Comment #9 from Mike Lothian ---
I have a feeling that Kwin was trying to modeset back to 60Hz which was causing
Xorg to crash and the error to appear in the dmesg
I'll post the Xorg.0.logs if I manage to reproduce the issue
--
You are re
https://bugs.freedesktop.org/show_bug.cgi?id=106999
--- Comment #8 from Mike Lothian ---
Created attachment 140278
--> https://bugs.freedesktop.org/attachment.cgi?id=140278&action=edit
Xorg.0.log with modesetting
--
You are receiving this mail because:
You are the assignee for the bug.___
https://bugs.freedesktop.org/show_bug.cgi?id=106999
--- Comment #7 from Mike Lothian ---
Xrandr now with modesetting
xrandr
Screen 0: minimum 320 x 200, current 3840 x 2160, maximum 16384 x 16384
HDMI-1 connected primary 3840x2160+0+0 (normal left inverted right x axis y
axis) 1872mm x 1053mm
https://bugs.freedesktop.org/show_bug.cgi?id=106999
--- Comment #6 from Mike Lothian ---
Strange I've just tried to do this again with modesetting and X starts but the
higher than 30Hz options aren't selectable, and 60Hz exactly is still missing
--
You are receiving this mail because:
You are t
https://bugs.freedesktop.org/show_bug.cgi?id=106999
--- Comment #5 from Mike Lothian ---
Created attachment 140277
--> https://bugs.freedesktop.org/attachment.cgi?id=140277&action=edit
Dmesg with error
--
You are receiving this mail because:
You are the assignee for the bug.__
https://bugs.freedesktop.org/show_bug.cgi?id=106999
--- Comment #4 from Mike Lothian ---
If I use the modesetting DDX (with Xorg from git - to include the PCIIDs for
Raven) X no longer starts and I get an error in the dmesg
--
You are receiving this mail because:
You are the assignee for the bu
https://bugs.freedesktop.org/show_bug.cgi?id=106999
--- Comment #3 from Mike Lothian ---
Created attachment 140276
--> https://bugs.freedesktop.org/attachment.cgi?id=140276&action=edit
EDID
--
You are receiving this mail because:
You are the assignee for the bug.__
https://bugs.freedesktop.org/show_bug.cgi?id=106999
--- Comment #2 from Mike Lothian ---
Created attachment 140275
--> https://bugs.freedesktop.org/attachment.cgi?id=140275&action=edit
Dmesg no 60Hz
--
You are receiving this mail because:
You are the assignee for the bug._
https://bugs.freedesktop.org/show_bug.cgi?id=106999
Mike Lothian changed:
What|Removed |Added
CC||m...@fireburn.co.uk
--- Comment #1 from
https://bugs.freedesktop.org/show_bug.cgi?id=106999
Bug ID: 106999
Summary: [raven] 2160p@60Hz no longer available
Product: DRI
Version: DRI git
Hardware: Other
OS: All
Status: NEW
Severity: normal
cz
---
v4:
- Rebase to v4.18-rc1 (applies to next-20180622, too),
v3:
- Add Acked-by,
- Rebase to v4.17-rc1,
v2:
- Add Reviewed-by, Acked-by,
- Drop RFC state,
- Split per subsystem.
---
drivers/video/fbdev/Kconfig | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/dri
Some functions are unused after removal of the kmap_atomic
DMA-buf interface.
Signed-off-by: Christian König
Fixes: f664a5269542 ("dma-buf: remove kmap_atomic interface")
---
drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c | 17 -
1 file changed, 17 deletions(-)
diff --git a/drivers/g
https://bugs.freedesktop.org/show_bug.cgi?id=106470
--- Comment #1 from Dominik 'Rathann' Mierzejewski ---
Ping? Is there anything I can do here to help debug this?
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel
On Wednesday, June 13, 2018 05:42:11 PM Ard Biesheuvel wrote:
> On 18 May 2018 at 16:17, Sinan Kaya wrote:
> > Get rid of base and size variables in favor of a struct resource.
> > The conditional for checking window can be replaced with
> > resource_contains().
> >
> > Signed-off-by: Sinan Kaya
On Friday, June 22, 2018 12:07:48 PM Bartlomiej Zolnierkiewicz wrote:
> On Friday, June 22, 2018 09:54:22 AM Ard Biesheuvel wrote:
> > On 13 June 2018 at 18:08, Bartlomiej Zolnierkiewicz
> > wrote:
> > > On Wednesday, June 13, 2018 05:45:48 PM Ard Biesheuvel wrote:
> > >> On 18 May 2018 at 16:17,
Quoting Gustavo Padovan (2018-06-22 11:04:16)
> Hi Akhil,
>
> On Fri, 2018-06-22 at 15:10 +0530, Akhil P Oommen wrote:
> > Each fence object holds function pointers of the module that
> > initialized
> > it. Allowing the module to unload before this fence's release is
> > catastrophic. So, keep a
On Friday, June 22, 2018 09:54:22 AM Ard Biesheuvel wrote:
> On 13 June 2018 at 18:08, Bartlomiej Zolnierkiewicz
> wrote:
> > On Wednesday, June 13, 2018 05:45:48 PM Ard Biesheuvel wrote:
> >> On 18 May 2018 at 16:17, Sinan Kaya wrote:
> >> > A host bridge is allowed to remap BAR addresses using
Hi Akhil,
On Fri, 2018-06-22 at 15:10 +0530, Akhil P Oommen wrote:
> Each fence object holds function pointers of the module that
> initialized
> it. Allowing the module to unload before this fence's release is
> catastrophic. So, keep a refcount on the module until the fence is
> released.
>
> S
Am 22.06.2018 um 05:11 schrieb Dave Airlie:
On 21 June 2018 at 20:54, Gustavo Padovan wrote:
drm-misc-next-2018-06-21:
drm-misc-next for 4.19:
Cross-subsystem Changes:
- fix compile breakage on ION due to the dma-buf cleanups (Christian König)
The following changes since commit daf0678c2036c91
On Thu, Jun 21, 2018 at 04:01:16PM -0700, John Stultz wrote:
> The driver doesn't support scaling, but when an atomic test is done
> it repeatedly spits out this warning which isn't particularly useful.
>
> So just remove the error message.
>
> Cc: Xinliang Liu
> Cc: Rongrong Zou
> Cc: Xinwei K
On Thu, Jun 21, 2018 at 05:04:02PM -0600, Jordan Crouse wrote:
> If a encoder name isn't specified for drm_encoder_init() it will try
> to construct one based on the incoming encoder_type identifier. If the
> caller passes an invalid encoder_type value the lookup could walk right
> past the end of
On Thu, Jun 21, 2018 at 12:54:28PM -0700, Eric Anholt wrote:
> Drivers such as vc4 don't initialize mode_config.funcs until later in
> initialization, but we know they're atomic since they've got the flag
> set. This avoids oopsing on dereferencing funcs in the new atomic
> methods sanity checks.
On 2018-06-21 10:48 PM, Lyude Paul wrote:
> This fixes a regression I accidentally reduced that was picked up by
> kasan, where we were checking the CRTC atomic states after DRM's helpers
> had already freed them. Example:
>
> [...]
>
> So, we fix this by counting the number of CRTCs this atomic
The rockchip use fully packed pixel format variants
for YUV 10bits.
This patch only make the VOP accept this pixel format,
but it doesn't add the converting data path for
the color gamuts that the target display are supported.
Signed-off-by: Randy Li
---
drivers/gpu/drm/rockchip/rockchip_drm_vo
Add support for Innolux TV123WAM, which is a 12.3" eDP
display panel with 2160x1440 resolution.
Changes in v1:
- Add the compatibility string, display_mode and panel_desc
structures in alphabetical order (Sean Paul).
Signed-off-by: Sandeep Panda
Reviewed-by: Sean Paul
---
drivers/gpu/drm/p
Properties like data-lanes, clock-noncontinuous and lane-polarities
are applicable to DSI and DisplayPort interface also. So update the
documentation to mention the same.
Signed-off-by: Sandeep Panda
Reviewed-by: Rob Herring
---
Documentation/devicetree/bindings/media/video-interfaces.txt | 10
Quoting Sandeep Panda (2018-06-21 05:32:07)
> diff --git
> a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt
> b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt
> new file mode 100644
> index ..c8b8f018356f
> --- /dev/null
> +++ b/Documentation/devi
Innolux TV123WAM is a 12.3" eDP display panel with
2160x1440 resolution, which can be supported by simple
panel driver.
Changes in v1:
- Make use of simple panel driver instead of creating
a new driver for this panel (Sean Paul).
- Combine dt-binding and driver changes into one patch
as do
When removing and reloading the etnaviv module, the following splat
occurs:
sysfs: cannot create duplicate filename '/devices/platform/etnaviv'
CPU: 0 PID: 1471 Comm: modprobe Not tainted 4.17.0+ #1608
Hardware name: Marvell Dove (Cubox)
Backtrace:
[] (dump_backtrace) from [] (show_stack+0x18/0x1c
This pixel format is a fully packed and 10bits variant of NV12.
A luma pixel would take 10bits in memory, without any
filled bits between pixels in a stride. The color gamut
follows the BT.2020 standard.
Signed-off-by: Randy Li
---
drivers/gpu/drm/drm_fourcc.c | 1 +
include/uapi/drm/drm_fourcc
Changes in current patchset:
- Explain in comment as in why dsi dev registration is done in
bridge_attach.
- Make panel/DDC exclusive until HPD support is added.
- Update interrupts and data-lane dt property bindings.
Sandeep Panda (5):
dt-bindings: media: extend interface documentation fo
Reorder allocation to avoid an awkward lock/unlock/lock sequence.
Simpler code due to being able to use ida_alloc_max(), even if we can't
eliminate the driver's spinlock.
Signed-off-by: Matthew Wilcox
---
drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c | 41 ++-
1 file changed, 12
Add support for TI's sn65dsi86 dsi2edp bridge chip.
The chip converts DSI transmitted signal to eDP signal,
which is fed to the connected eDP panel.
This chip can be controlled via either i2c interface or
dsi interface. Currently in driver all the control registers
are being accessed through i2c i
In the last time, I got some feedback and not a clear guide on what
I should do. So just give more comment on describing this 10bits format.
Whether I should add bpp instead cpp in drm_format_info and update a
numbers of functions is up to you guys.
And I don't any other driver would request 10bit
This pixel format is a fully packed and 10bits variant of NV12.
A luma pixel would take 10bits in memory, without any
filled bits between pixels in a stride.
Signed-off-by: Randy Li
---
drivers/gpu/drm/drm_fourcc.c | 1 +
include/uapi/drm/drm_fourcc.h | 8
2 files changed, 9 insertions
Document the bindings used for the sn65dsi86 DSI to eDP bridge.
Changes in v1:
- Rephrase the dt-binding descriptions to be more inline with existing
bindings (Andrzej Hajda).
- Add missing dt-binding that are parsed by corresponding driver
(Andrzej Hajda).
Changes in v2:
- Remove edp pa
The rockchip use fully packed pixel format variants
for YUV 10bits.
This patch only make the VOP accept this pixel format,
but it doesn't add the converting data path for
the color gamuts that the target display are supported.
Signed-off-by: Randy Li
---
drivers/gpu/drm/rockchip/rockchip_drm_vo
Dne četrtek, 21. junij 2018 ob 03:23:27 CEST je Chen-Yu Tsai napisal(a):
> On Thu, Jun 21, 2018 at 3:37 AM, Jernej Škrabec
wrote:
> > Dne sobota, 16. junij 2018 ob 07:48:38 CEST je Chen-Yu Tsai napisal(a):
> >> On Sat, Jun 16, 2018 at 1:33 AM, Jernej Škrabec
> >
> > wrote:
> >> > Dne petek, 15.
In the last time, I got some feedback and not a clear guide on what
I should do. So just give more comment on describing this 10bits format.
Whether I should add bpp instead cpp in drm_format_info and update a
numbers of functions is up to you guys.
And I don't any other driver would request 10bit
https://bugs.freedesktop.org/show_bug.cgi?id=106879
--- Comment #4 from javcasalc ---
Hi
any ideas with this bug?
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http
92 matches
Mail list logo
