Hi Dave/Daniel,
drm-misc-fixes-2019-01-10:
Pull request for drm-misc-fixes for v5.0-rc2:
- Fixes for the tc358767 bridge to work correctly with
tc358867 using a DP connector.
- Make resume work on amdgpu when a DP-MST display is unplugged.
The following changes since commit
https://bugs.freedesktop.org/show_bug.cgi?id=109265
Bug ID: 109265
Summary: [regression, bisected] arb_texture_multisample
texelfetch piglit test failing on NIR backend
Product: Mesa
Version: git
Hardware: Other
Hi, Chunhui:
On Fri, 2019-01-04 at 15:03 +0800, chunhui dai wrote:
> Recalculate the rate of this clock, by querying hardware.
>
> Signed-off-by: chunhui dai
> ---
> drivers/gpu/drm/mediatek/mtk_hdmi_phy.c| 7 ++--
> drivers/gpu/drm/mediatek/mtk_hdmi_phy.h| 3 +-
>
tree: git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next
head: d2d07f246b126b23d02af0603b83866a3c3e2483
commit: fdc916c8be24375d63c36ae363f71e59becfb8f2 [262/270] drm/amdgpu: Add
sysfs file for PCIe usage v4
config: ia64-allmodconfig (attached as .config)
compiler:
On Wed, Jan 09, 2019 at 11:24:05PM +0100, Daniel Vetter wrote:
> On Tue, Jan 08, 2019 at 08:29:39PM +0100, Sam Ravnborg wrote:
> > With all dependencies fixed we can now remove
> > drmP.h from drm_gem_cma_helper.h.
> > It is replaced by the include files required,
> > or forward declarations as
https://bugs.freedesktop.org/show_bug.cgi?id=108521
--- Comment #38 from Alex Deucher ---
(In reply to Robert Strube from comment #34)
> Created attachment 143044 [details]
> dmesg log amdgpu.dpm=0 with 580 as eGPU
>
> Another user is reporting a similar problem with a different Dell laptop
>
tree: git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next
head: d2d07f246b126b23d02af0603b83866a3c3e2483
commit: fdc916c8be24375d63c36ae363f71e59becfb8f2 [262/270] drm/amdgpu: Add
sysfs file for PCIe usage v4
config: i386-randconfig-s3-201901 (attached as .config)
compiler:
On Tue, Jan 08, 2019 at 08:29:39PM +0100, Sam Ravnborg wrote:
> With all dependencies fixed we can now remove
> drmP.h from drm_gem_cma_helper.h.
> It is replaced by the include files required,
> or forward declarations as appropritate.
>
> Signed-off-by: Sam Ravnborg
> Acked-by: Noralf Trønnes
On Tue, Jan 08, 2019 at 08:29:32PM +0100, Sam Ravnborg wrote:
> In the quest to get rid of drmP.h move the newly
> added EXPORT_SYMBOL_FOR_TESTS_ONLY to drm_util.h.
> Fix the single user.
>
> Add a note to drmP.h to avoid further use of it.
>
> Signed-off-by: Sam Ravnborg
> Cc: Maarten
On Tue, Jan 08, 2019 at 08:29:35PM +0100, Sam Ravnborg wrote:
> drmP.h is an relic from the days when there was a single header file.
> To enable the removal of drmP.h from all users drop include
> of drmP.h from drm_modeset_helper.h.
>
> A few files relied on the file included in drmP.h - add
On Wed, Jan 9, 2019 at 9:52 PM Gerd Hoffmann wrote:
>
> Hi,
>
> > > If I understand things correctly it is valid to set all import/export
> > > callbacks (prime_handle_to_fd, prime_fd_to_handle,
> > > gem_prime_get_sg_table, gem_prime_import_sg_table) to NULL when not
> > > supporting dma-buf
Quoting Kuo-Hsin Yang (2019-01-08 07:45:17)
> The gem drivers use shmemfs to allocate backing storage for gem objects.
> On Samsung Chromebook Plus, the drm/rockchip driver may call
> rockchip_gem_get_pages -> drm_gem_get_pages -> shmem_read_mapping_page
> to pin a lot of pages, breaking the page
On Tue, Jan 08, 2019 at 08:29:31PM +0100, Sam Ravnborg wrote:
> Move drm_can_sleep() out of drmP.h to allow users
> to get rid of the drmP.h include.
>
> There was no header file that was a good match for this helper function.
> So add this to drm_util with the relevant includes.
>
> Update
https://bugs.freedesktop.org/show_bug.cgi?id=108521
--- Comment #37 from Robert Strube ---
One additional comment, the user with the XPS 9370 was able to get the RX 580
working as an eGPU flawlessly in Windows 10. This lends some credibility to
the theory that it might not actually be a BIOS
On Thu, Dec 20, 2018 at 10:24:27AM -0200, Shayenne Moura wrote:
> This patch serie removes drm_mode_object dependency from
> drm_display_mode struct. This is part of KMS cleanup.
>
> Shayenne Moura (7):
> drm: msm: Cleanup drm_display_mode print str
> drm: omapdrm: Cleanup drm_display_mode
https://bugs.freedesktop.org/show_bug.cgi?id=108521
--- Comment #36 from Robert Strube ---
(In reply to Robert Strube from comment #34)
> Created attachment 143044 [details]
> dmesg log amdgpu.dpm=0 with 580 as eGPU
>
> Another user is reporting a similar problem with a different Dell laptop
>
https://bugs.freedesktop.org/show_bug.cgi?id=108521
Robert Strube changed:
What|Removed |Added
Attachment #143044|dmesg log amdgpu=0 with 580 |dmesg log amdgpu.dpm=0 with
https://bugs.freedesktop.org/show_bug.cgi?id=108521
--- Comment #35 from Robert Strube ---
Created attachment 143045
--> https://bugs.freedesktop.org/attachment.cgi?id=143045=edit
dmesg log pci=noacpi with 580 as eGPU
Another user has reported a similar problem with a different laptop (XPS
https://bugs.freedesktop.org/show_bug.cgi?id=108521
--- Comment #34 from Robert Strube ---
Created attachment 143044
--> https://bugs.freedesktop.org/attachment.cgi?id=143044=edit
dmesg log amdgpu=0 with 580 as eGPU
Another user is reporting a similar problem with a different Dell laptop (the
Hi,
> > If I understand things correctly it is valid to set all import/export
> > callbacks (prime_handle_to_fd, prime_fd_to_handle,
> > gem_prime_get_sg_table, gem_prime_import_sg_table) to NULL when not
> > supporting dma-buf import/export and still advertise DRIVER_PRIME to
> > indicate the
On Wed, Jan 09, 2019 at 09:39:45PM +0100, Daniel Vetter wrote:
> Hi Kevin,
>
> On Wed, Jan 09, 2019 at 06:09:00PM +0100, Kevin Brace wrote:
> > Hi Sean,
> >
> > I do recall seeing you at XDC2017, I do not believe I spoke with you at
> > the event. I will not name the name, but I had one
On Wed, Jan 9, 2019 at 6:50 PM Noralf Trønnes wrote:
>
> Hi,
>
> I was really pleased to see that the damage helper had landed. Now I can
> do framebuffer flushing solely through the display pipe functions. This
> prepares the ground for the removal of struct tinydrm_device in my next
> series.
On Wed, Jan 09, 2019 at 06:49:53PM +0100, Noralf Trønnes wrote:
> This adds a .fb_create helper that sets the .dirty callback to
> drm_atomic_helper_dirtyfb().
>
> Signed-off-by: Noralf Trønnes
> ---
> drivers/gpu/drm/drm_gem_framebuffer_helper.c | 47 +---
>
Hi Dave, Daniel,
Fixes for 5.0. Highlights:
- Powerplay fixes
- Virtual display pinning fixes
- Golden register updates for vega
- Pitch and gem size validation fixes
- Fix for error case in sr-iov init
- Disable page tables in system memory on RV due to issues with IOMMU
reported on some
Hi Kevin,
On Wed, Jan 09, 2019 at 06:09:00PM +0100, Kevin Brace wrote:
> Hi Sean,
>
> I do recall seeing you at XDC2017, I do not believe I spoke with you at
> the event. I will not name the name, but I had one developer who
> strongly asked me to convert to atomic mode setting, but I refused
On Wed, Jan 09, 2019 at 05:52:20PM +0100, Paul Kocialkowski wrote:
> Hi Daniel,
>
> On Tue, 2019-01-08 at 19:21 +0100, Daniel Vetter wrote:
> > On Tue, Jan 8, 2019 at 3:51 PM Paul Kocialkowski
> > wrote:
> > > During an atomic commit, the HVS is configured with a display list
> > > for the
On Wed, Jan 9, 2019 at 1:20 PM Doug Anderson wrote:
>
> Hi Rob,
>
> On Tue, Dec 18, 2018 at 10:32 AM Jordan Crouse wrote:
> >
> > Now that more of the sdm845 bindings are headed upstream this a refresh of
> > of https://patchwork.freedesktop.org/series/39308/ to add bindings and nodes
> > for
Den 09.01.2019 19.26, skrev Sam Ravnborg:
> Hi Noralf.
>
>>
>> I was really pleased to see that the damage helper had landed. Now I can
>> do framebuffer flushing solely through the display pipe functions. This
>> prepares the ground for the removal of struct tinydrm_device in my next
>>
Hi Linus.
On Wed, Jan 09, 2019 at 02:53:31PM +0100, Linus Walleij wrote:
> The TPO (Toppoly) TPG110 is a pretty generic display driver
> similar in vein to the Ilitek 93xx devices. It is not a panel
> per se but a driver used with several low-cost noname panels.
>
> This is used on the Nomadik
Here's a small series supporting plane reflection (aka. mirroring)
properties on RK3328, RK3368, and RK3399 SoCs.
Note that RK3288 specification doesn't seem to document registers
for plane mirroring, but instead it only seems to support mirroring
at the display (CRTC) level.
A small typo
Fix a small typo in the macros VOP argument. The macro argument
is currently wrongly named "x", and then never used. The code
built fine almost by accident, as the macros are always used
in a context where a proper "vop" symbol exists.
This fix is almost cosmetic, as the resulting code shouldn't
This commit splits the registers for RK3288 from those
for RK3328, RK3368 and RK3399. It seems RK3288 does not
support plane x-y-mirroring, and so in order to support this
for the other SoCs, we need to have separate set of registers
for win0 and win1.
Signed-off-by: Ezequiel Garcia
---
From: Daniele Castagna
Add the KMS plane rotation property to the DRM rockchip driver,
for SoCs RK3328, RK3368 and RK3399.
RK3288 only supports rotation at the display level (i.e. CRTC),
but for now we are only interested in plane rotation.
This commit only adds support for the value of
On Wed, Jan 9, 2019 at 12:36 PM Daniel Vetter wrote:
>
> On Wed, Jan 9, 2019 at 3:54 PM Gerd Hoffmann wrote:
> >
> > On Wed, Jan 09, 2019 at 11:10:44AM +0100, Daniel Vetter wrote:
> > > On Tue, Jan 08, 2019 at 12:25:19PM +0100, Gerd Hoffmann wrote:
> > > > The buffer object must be reserved
Hi Noralf.
>
> I was really pleased to see that the damage helper had landed. Now I can
> do framebuffer flushing solely through the display pipe functions. This
> prepares the ground for the removal of struct tinydrm_device in my next
> series.
I browsed through the code - and the code paths I
Hi Rob,
On Tue, Dec 18, 2018 at 10:32 AM Jordan Crouse wrote:
>
> Now that more of the sdm845 bindings are headed upstream this a refresh of
> of https://patchwork.freedesktop.org/series/39308/ to add bindings and nodes
> for the GPU/GMU and GPU SMMU for sdm845. v7 of this patchset also removes
From: Sravanthi Kollukuduru
Add interconnect properties such as interconnect provider specifier
, the edge source and destination ports which are required by the
interconnect API to configure interconnect path for MDSS.
Changes in v2:
- none
Changes in v3:
- Remove common
From: Sravanthi Kollukuduru
The interconnect framework is designed to provide a
standard kernel interface to control the settings of
the interconnects on a SoC.
The interconnect API uses a consumer/provider-based model,
where the providers are the interconnect buses and the
consumers could be
From: Sravanthi Kollukuduru
Since the upstream interconnect bus framework has landed
upstream, the existing references of custom bus scaling
needs to be cleaned up.
Changes in v2:
- Fixed build error due to partial clean up
Changes in v3:
- Condense multiple lines into a single
The interconnect API provides an interface for consumer drivers to express
their bandwidth needs in the SoC. This data is aggregated and the on-chip
interconnect hardware is configured to the appropriate power/performance
profile.
MDSS is one of the interconnect consumers which uses the
This adds a .fb_create helper that sets the .dirty callback to
drm_atomic_helper_dirtyfb().
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/drm_gem_framebuffer_helper.c | 47 +---
include/drm/drm_gem_framebuffer_helper.h | 3 ++
2 files changed, 44 insertions(+), 6
Useful for drivers that only care about the combined damage.
Cc: Deepak Rawat
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/drm_damage_helper.c | 43 +
include/drm/drm_damage_helper.h | 3 ++
2 files changed, 46 insertions(+)
diff --git
This prepares for the switch to drm_atomic_helper_dirtyfb() in the next
patch. The damage helper returns a drm_rect so switch to that everywhere
including using a pointer in the dirty functions.
This is a non-functional change except for the debug print which looks a
bit different.
This switches to drm_atomic_helper_dirtyfb() as the framebuffer dirty
handler. All flushing will now happen in the pipe functions.
Also enable the damage plane property for all except repaper which can
only do full updates.
ili9225:
This change made ili9225_init() equal to mipi_dbi_init() so use
Hi,
I was really pleased to see that the damage helper had landed. Now I can
do framebuffer flushing solely through the display pipe functions. This
prepares the ground for the removal of struct tinydrm_device in my next
series.
Note:
The damage helper isn't in drm-misc-next yet, it will show up
https://bugs.freedesktop.org/show_bug.cgi?id=107652
Mart Raudsepp changed:
What|Removed |Added
CC||l...@gentoo.org
--- Comment #17 from
On Wed, Jan 9, 2019 at 3:54 PM Gerd Hoffmann wrote:
>
> On Wed, Jan 09, 2019 at 11:10:44AM +0100, Daniel Vetter wrote:
> > On Tue, Jan 08, 2019 at 12:25:19PM +0100, Gerd Hoffmann wrote:
> > > The buffer object must be reserved before calling
> > > ttm_bo_validate for pinning/unpinning.
> > >
> >
https://bugs.freedesktop.org/show_bug.cgi?id=108098
--- Comment #9 from Daniel Stone ---
(In reply to Michel Dänzer from comment #7)
> FWIW, I advise against paying too much attention to fin4478. They are not
> involved in driver development and known for making rather questionable
> suggestions
On 09.01.2019 15:13, Robert Chiras wrote:
> Currently, the enable of the axi clock return status is ignored, causing
> issues when the enable fails then we try to disable it. Therefore, it is
> better to check the return status and disable it only when enable
> succeeded.
> Also, remove the helper
Hi Sean,
I do recall seeing you at XDC2017, I do not believe I spoke with you at the
event.
I will not name the name, but I had one developer who strongly asked me to
convert to atomic mode setting, but I refused due to the state of the code at
the time.
Now, the KMS device support is mostly
https://bugs.freedesktop.org/show_bug.cgi?id=109235
Michel Dänzer changed:
What|Removed |Added
QA Contact|dri-devel@lists.freedesktop |xorg-t...@lists.x.org
Hi Daniel,
On Tue, 2019-01-08 at 19:21 +0100, Daniel Vetter wrote:
> On Tue, Jan 8, 2019 at 3:51 PM Paul Kocialkowski
> wrote:
> > 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
Hi,
On Wed, Jan 9, 2019 at 6:38 AM Georgi Djakov wrote:
>
> Hi Jayant,
>
> On 12/21/18 08:20, Jayant Shekhar wrote:
> > From: Sravanthi Kollukuduru
> >
> > The interconnect framework is designed to provide a
> > standard kernel interface to control the settings of
> > the interconnects on a
Hi,
[This is an automated email]
This commit has been processed because it contains a "Fixes:" tag,
fixing commit: 79e539453b34 DRM: i915: add mode setting support.
The bot has tested the following trees: v4.20.0, v4.19.13, v4.14.91, v4.9.148,
v4.4.169, v3.18.131.
v4.20.0: Failed to apply!
Hi,
[This is an automated email]
This commit has been processed because it contains a "Fixes:" tag,
fixing commit: 79e539453b34 DRM: i915: add mode setting support.
The bot has tested the following trees: v4.20.0, v4.19.13, v4.14.91, v4.9.148,
v4.4.169, v3.18.131.
v4.20.0: Failed to apply!
https://bugs.freedesktop.org/show_bug.cgi?id=109234
--- Comment #12 from Michel Dänzer ---
Looks like this should be reported to Christoph Hellwig and other kernel DMA
mapping helper developers then. Please Cc the dri-devel mailing list when doing
so.
--
You are receiving this mail because:
https://bugs.freedesktop.org/show_bug.cgi?id=109234
--- Comment #10 from Sibren Vasse ---
Created attachment 143038
--> https://bugs.freedesktop.org/attachment.cgi?id=143038=edit
Bisect result
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=109234
--- Comment #11 from Sibren Vasse ---
I've been running into this issue multiple times a day. I noticed I hit the
OOPS a lot more frequent when my system was under load (e.g. compiling a
kernel) and then opening a new tab in Firefox.
Don't
On 01/09/2019 05:22 AM, Christian König wrote:
> Am 07.01.19 um 20:47 schrieb Grodzovsky, Andrey:
>>
>> On 01/07/2019 09:13 AM, Christian König wrote:
>>> Am 03.01.19 um 18:42 schrieb Grodzovsky, Andrey:
On 01/03/2019 11:20 AM, Grodzovsky, Andrey wrote:
> On 01/03/2019 03:54 AM, Koenig,
Hi Tomi,
Am Mittwoch, den 09.01.2019, 16:55 +0200 schrieb Tomi Valkeinen:
> On 09/01/19 11:51, Lucas Stach wrote:
>
> > For the series:
> >
> > > > Tested-by: Lucas Stach
> >
> > on a device with TC358767 and a 4.20 based kernel.
>
> Thanks Lucas.
>
> Does the device use TC358767 as
https://bugs.freedesktop.org/show_bug.cgi?id=104362
--- Comment #11 from nmr ---
Created attachment 143037
--> https://bugs.freedesktop.org/attachment.cgi?id=143037=edit
dmesg dump for hang
--
You are receiving this mail because:
You are the assignee for the
On 09/01/19 11:51, Lucas Stach wrote:
> For the series:
>
> Tested-by: Lucas Stach
>
> on a device with TC358767 and a 4.20 based kernel.
Thanks Lucas.
Does the device use TC358767 as eDP+panel, or as full DP with an
external connector? We have the latter, and I think there are some
missing
https://bugs.freedesktop.org/show_bug.cgi?id=104362
nmr changed:
What|Removed |Added
CC||nnmmrr88...@gmail.com
--- Comment #10 from nmr
On Wed, Jan 09, 2019 at 11:10:44AM +0100, Daniel Vetter wrote:
> On Tue, Jan 08, 2019 at 12:25:19PM +0100, Gerd Hoffmann wrote:
> > The buffer object must be reserved before calling
> > ttm_bo_validate for pinning/unpinning.
> >
> > Signed-off-by: Gerd Hoffmann
>
> Seems a bit a bisect fumble
https://bugs.freedesktop.org/show_bug.cgi?id=109246
--- Comment #13 from Nicholas Kazlauskas ---
(In reply to Michel Dänzer from comment #12)
> (In reply to tme from comment #9)
> > Setting amdgpu.dc=1 on 4.15.18 and 4.16.18 does not reproduce the problem.
> > It does, however, reproduce on
The TPO (Toppoly) TPG110 is a pretty generic display driver
similar in vein to the Ilitek 93xx devices. It is not a panel
per se but a driver used with several low-cost noname panels.
This is used on the Nomadik NHK15 combined with a OSD
OSD057VA01CT display for WVGA 800x480.
The driver is
Since commit 2bcd3ecab773 when switching mode from X11 (ubuntu mate for
example) the display gets blurry, looking like an invalid framebuffer width.
This commit fixed atomic crtc modesetting but didn't update the display
parameters when changing mode, but only when starting a mode setting after
a
On Wed, Jan 09, 2019 at 10:33:25AM +0100, Maxime Ripard wrote:
> Cadence has designed a D-PHY that can be used by the, currently in tree,
> DSI bridge (DRM), CSI Transceiver and CSI Receiver (v4l2) drivers.
>
> Only the DSI driver has an ad-hoc driver for that phy at the moment, while
> the v4l2
Hi Maxime,
On Wed, Jan 09, 2019 at 10:33:24AM +0100, Maxime Ripard wrote:
> The Cadence D-PHY bindings was defined as part of the DSI block so far.
> However, since it's now going to be a separate driver, we need to move the
> binding to a file of its own.
>
> Signed-off-by: Maxime Ripard
On Wed, Jan 09, 2019 at 10:33:17AM +0100, Maxime Ripard wrote:
> Hi,
>
> Here is a set of patches to allow the phy framework consumers to test and
> apply runtime configurations.
>
> This is needed to support more phy classes that require tuning based on
> parameters depending on the current use
>-Original Message-
>From: Brian Starkey [mailto:brian.star...@arm.com]
>Sent: Tuesday, January 8, 2019 7:43 PM
>To: Shankar, Uma
>Cc: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
>Lankhorst,
>Maarten ; Syrjala, Ville
>;
>Sharma, Shashank ; nd
>Subject: Re: [v6
>-Original Message-
>From: Brian Starkey [mailto:brian.star...@arm.com]
>Sent: Tuesday, January 8, 2019 7:37 PM
>To: Shankar, Uma
>Cc: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
>Lankhorst,
>Maarten ; Syrjala, Ville
>;
>Sharma, Shashank ; nd
>Subject: Re: [v6
>-Original Message-
>From: Roper, Matthew D
>Sent: Wednesday, January 9, 2019 1:15 AM
>To: Shankar, Uma
>Cc: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; Syrjala,
>Ville
>; emil.l.veli...@gmail.com; Lankhorst, Maarten
>
>Subject: Re: [v4 10/12] drm/i915: Add HLG
On Wed, 9 Jan 2019 11:37:19 +
Peter Rosin wrote:
> On 2019-01-09 11:12, Daniel Vetter wrote:
> > On Tue, Jan 08, 2019 at 12:31:36PM +, Peter Rosin wrote:
> >> While trying to temporarily hide a plane, one thing that was attempted
> >> was to call (from libdrm)
> >>
> >>
On Wed, 9 Jan 2019 11:12:24 +0100
Daniel Vetter wrote:
> On Tue, Jan 08, 2019 at 12:31:36PM +, Peter Rosin wrote:
> > While trying to temporarily hide a plane, one thing that was attempted
> > was to call (from libdrm)
> >
> > drmModeSetPlane(fd, plane_id, crtc_id, fb_id, 0,
> >
On Tue, 2019-01-08 at 16:15 -0800, Steve Longerbeam wrote:
> The function ipu_csi_init_interface() was inverting the F-bit for
> NTSC case, in the CCIR_CODE_1/2 registers. The result being that
> for NTSC bottom-top field order, the CSI would swap fields and
> capture in top-bottom order.
>
>
Am 07.01.19 um 20:47 schrieb Grodzovsky, Andrey:
On 01/07/2019 09:13 AM, Christian König wrote:
Am 03.01.19 um 18:42 schrieb Grodzovsky, Andrey:
On 01/03/2019 11:20 AM, Grodzovsky, Andrey wrote:
On 01/03/2019 03:54 AM, Koenig, Christian wrote:
Am 21.12.18 um 21:36 schrieb Grodzovsky,
On Tue, Jan 08, 2019 at 12:31:36PM +, Peter Rosin wrote:
> While trying to temporarily hide a plane, one thing that was attempted
> was to call (from libdrm)
>
> drmModeSetPlane(fd, plane_id, crtc_id, fb_id, 0,
> 0, 0, 0, 0, 0, 0, 0, 0);
>
> This call causes a
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:
Hi,
We have TC358867 on our board, which I believe
On Tue, Jan 08, 2019 at 12:25:19PM +0100, Gerd Hoffmann wrote:
> The buffer object must be reserved before calling
> ttm_bo_validate for pinning/unpinning.
>
> Signed-off-by: Gerd Hoffmann
Seems a bit a bisect fumble in your series here: legacy kms code reserved
the ttm bo before calling
On Tue, Jan 08, 2019 at 12:25:07PM +0100, Gerd Hoffmann wrote:
> Conversion to atomic modesetting, step one.
> Add atomic crtc helper callbacks.
>
> Signed-off-by: Gerd Hoffmann
> ---
> drivers/gpu/drm/bochs/bochs_kms.c | 25 +
> 1 file changed, 25 insertions(+)
>
>
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:
> > > Hi,
> > >
> > > We have TC358867 on our board, which I believe is almost identical to
> > > TC358767.
Hi Benjamin.
On Wed, Jan 09, 2019 at 09:21:39AM +0100, Benjamin Gaignard wrote:
> Le mar. 8 janv. 2019 à 20:30, Sam Ravnborg a écrit :
> I just notice the a typo in the title of the commit message reply ->rely ?
Randy already told me this, but I missed that in the update.
Will fix in v4 if this
Am Dienstag, den 08.01.2019, 12:43 -0800 schrieb Matthew Wilcox:
> I wanted to test-compile etnaviv on x86 after making a tree-wide change
> to it. Unfortunately, Kconfig has a bad dependency, so I couldn't.
>
> Signed-off-by: Matthew Wilcox
I think we even want to relax this some more in the
Am Dienstag, den 08.01.2019, 12:50 -0800 schrieb Matthew Wilcox:
> > Signed-off-by: Matthew Wilcox
Thanks, applied to etnaviv/next.
Regards,
Lucas
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 32d76a90..44888eb121d8 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -5141,7 +5141,7 @@
Now that our MIPI D-PHY driver has been converted to the phy framework,
let's move it into the drivers/phy directory.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/Kconfig | 10 +-
drivers/gpu/drm/sun4i/Makefile | 1 +-
Now that we have everything in place in the PHY framework to deal in a
generic way with MIPI D-PHY phys, let's convert our PHY driver and its
associated DSI driver to that new API.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/Kconfig | 11 +-
drivers/gpu/drm/sun4i/Makefile
The Init and wakeup D-PHY parameters are in the micro/milliseconds range,
putting the values real close to the types limits if they were in
picoseconds.
Move them to microseconds which should be better fit.
Suggested-by: Sakari Ailus
Signed-off-by: Maxime Ripard
---
The Cadence D-PHY bindings was defined as part of the DSI block so far.
However, since it's now going to be a separate driver, we need to move the
binding to a file of its own.
Signed-off-by: Maxime Ripard
---
Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt | 21 +---
Hi,
Here is a set of patches to allow the phy framework consumers to test and
apply runtime configurations.
This is needed to support more phy classes that require tuning based on
parameters depending on the current use case of the device, in addition to
the power state management already
The current configuration of the DSI bridge and its associated D-PHY is
intertwined. In order to ease the future conversion to the phy framework
for the D-PHY part, let's split the configuration in two.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/bridge/cdns-dsi.c | 96
Cadence has designed a D-PHY that can be used by the, currently in tree,
DSI bridge (DRM), CSI Transceiver and CSI Receiver (v4l2) drivers.
Only the DSI driver has an ad-hoc driver for that phy at the moment, while
the v4l2 drivers are completely missing any phy support. In order to make
that phy
Now that we have everything we need in the phy framework to allow to tune
the phy parameters, let's convert the Cadence DSI bridge to that API
instead of creating a ad-hoc driver for its phy.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/bridge/Kconfig| 1 +-
The lanes parameter is not solely about the number of lanes, but it also
carries the fact that those are the first lanes in use during the
transmission.
It was implicit so far, so make sure it's explicit now.
Suggested-by: Sakari Ailus
Signed-off-by: Maxime Ripard
---
The videomode.h header inclusion is an artifact from the patches
development, remove it.
Suggested-by: Sakari Ailus
Signed-off-by: Maxime Ripard
---
include/linux/phy/phy-mipi-dphy.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/include/linux/phy/phy-mipi-dphy.h
https://bugs.freedesktop.org/show_bug.cgi?id=109246
--- Comment #12 from Michel Dänzer ---
(In reply to tme from comment #9)
> Setting amdgpu.dc=1 on 4.15.18 and 4.16.18 does not reproduce the problem.
> It does, however, reproduce on 4.17.19.
Can you bisect between 4.16.18 and 4.17.19?
(I see
On 1/9/2019 10:50 AM, Doug Anderson wrote:
...but in the meantime Rajendra has had to change his bindings, so you
still need to spin this to account for Rajendra's v9 bindings [2].
Specifically you need to make changes like:
- compatible =
On Wed, Jan 09, 2019 at 10:24:01AM +0100, Rafael J. Wysocki wrote:
> On Wed, Jan 9, 2019 at 10:13 AM Andrzej Hajda wrote:
> >
> > +CC: Rafael J. Wysocki
> >
> > On 08.01.2019 16:07, Russell King - ARM Linux wrote:
> > > On Tue, Jan 08, 2019 at 03:33:54PM +0100, Andrzej Hajda wrote:
> > >> On
On Wed, Jan 9, 2019 at 10:13 AM Andrzej Hajda wrote:
>
> +CC: Rafael J. Wysocki
>
> On 08.01.2019 16:07, Russell King - ARM Linux wrote:
> > On Tue, Jan 08, 2019 at 03:33:54PM +0100, Andrzej Hajda wrote:
> >> On 08.01.2019 14:21, Russell King - ARM Linux wrote:
> >>> On Tue, Jan 08, 2019 at
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 landing in 5.0,
therefore this fix isn't needed in older
1 - 100 of 120 matches
Mail list logo
