Hi Tanmay
Reviewing the yaml bindings triggered a few comments. See below.
Sam
On Tue, Mar 31, 2020 at 05:30:27PM -0700, Tanmay Shah wrote:
> From: Chandan Uddaraju
>
> Add bindings for Snapdragon DisplayPort and
> display-port PLL driver.
>
> Changes in V2:
> Provide details about
Hi Christian,
On Tue, 31 Mar 2020, 14:16 Daniel Vetter, wrote:
> On Mon, Mar 30, 2020 at 03:55:31PM +0200, Christian König wrote:
> > Add a peer2peer flag noting that the importer can deal with device
> > resources which are not backed by pages.
> >
> > Signed-off-by: Christian König
>
> On
From: Jeykumar Sankaran
Add display port support in DPU by creating hooks
for DP encoder enumeration and encoder mode
initialization.
This change is based on the Snapdragon Display port
driver changes[1].
changes in v2:
- rebase on [2] (Sean Paul)
- remove unwanted error checks
From: Chandan Uddaraju
Add the needed DP PLL specific files to support
display port interface on msm targets.
The DP driver calls the DP PLL driver registration.
The DP driver sets the link and pixel clock sources.
Changes in v2:
-- Update copyright markings on all relevant files.
-- Use
From: Chandan Uddaraju
The constant N value (0x8000) is used by multiple DP
drivers. Define this value in header file and use this
in the existing i915 display driver.
Signed-off-by: Chandan Uddaraju
Signed-off-by: Vara Reddy
---
drivers/gpu/drm/i915/display/intel_display.c | 2 +-
These patches add support for Display-Port driver on SnapDragon 845 hardware.
It adds
DP driver and DP PLL driver files along with the needed device-tree bindings.
The block diagram of DP driver is shown below:
+-+
|DRM FRAMEWORK|
From: Chandan Uddaraju
Add bindings for Snapdragon DisplayPort and
display-port PLL driver.
Changes in V2:
Provide details about sel-gpio
Changes in V4:
Provide details about max dp lanes
Change the commit text
Changes in V5:
Moved dp.txt to yaml file.
Signed-off-by: Chandan Uddaraju
https://bugzilla.kernel.org/show_bug.cgi?id=207047
Bug ID: 207047
Summary: Crash after failed to pin userptr on amdgpu
Product: Drivers
Version: 2.5
Kernel Version: 5.5.13
Hardware: All
OS: Linux
Tree:
On Sat, 28 Mar 2020 01:41:57 +0100, Martin Blumenstingl wrote:
> Use two spaces for indentation instead of one to be consistent with the
> rest of the file. No functional changes.
>
> Fixes: 6b9ebf1e0e678b ("dt-bindings: display: amlogic, meson-vpu: convert to
> yaml")
> Signed-off-by: Martin
On Wed, 25 Mar 2020 11:38:28 +0100, Johan Jonker wrote:
> In the old txt situation we add/describe only properties that are used
> by the driver/hardware itself. With yaml it also filters things in a
> node that are used by other drivers like 'assigned-clocks' and
> 'assigned-clock-rates' for
On Wed, 25 Mar 2020 11:38:27 +0100, Johan Jonker wrote:
> Current dts files with 'vop' nodes are manually verified.
> In order to automate this process rockchip-vop.txt
> has to be converted to yaml.
>
> Signed-off-by: Johan Jonker
> ---
> Changes v4:
> Change description
> Replace
We already trace DPCD reads/writes on both MST and SST, there's no
reason to have this code here (plus, toggling these things with a
define at the top of the file isn't how we do things in the kernel).
Signed-off-by: Lyude Paul
---
.../display/amdgpu_dm/amdgpu_dm_mst_types.c | 43
DRM already supports tracing DPCD transactions, there's no reason for
the existence of this function. Also, it prints one byte per-line which
is way too loud. So, just remove it.
Signed-off-by: Lyude Paul
---
.../gpu/drm/amd/display/dc/basics/Makefile| 3 +-
There's a bunch of messy DPCD tracing code in amdgpu that isn't needed
since we already support this in DRM. Plus, it's really spammy. So, just
get rid of it.
Lyude Paul (2):
drm/amd/amdgpu_dm/mst: Remove useless sideband tracing
drm/amd/dc: Kill dc_conn_log_hex_linux()
Reviewed-by: Lyude Paul
I'll go ahead and push it to drm-misc-next, thanks!
On Sat, 2020-03-21 at 22:29 +, Maya Rashish wrote:
> Nothing uses the always-0 return value.
>
> Signed-off-by: Maya Rashish
> ---
> drivers/gpu/drm/drm_dp_mst_topology.c | 3 +--
> 1 file changed, 1
Pankaj Bharadiya started cleaning up the MST connector callbacks a while
ago, as I pointed out that they are the same across every driver and
don't serve much purpose. There was one callback that was left over
though from amdgpu, that we delayed removing due to not being completely
sure as to
This finishes up the work that Pankaj Bharadiya started in:
https://patchwork.freedesktop.org/series/74412/
And allows us to entirely remove ->destroy_connector()
Lyude Paul (4):
drm/amd/amdgpu_dm/mst: Remove unneeded edid assignment when destroying
connectors
drm/amd/amdgpu_dm/mst:
Doesn't do anything, noticed this while cleaning up some unrelated
stuff.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
On Tue, Mar 31, 2020 at 1:14 PM Sam Ravnborg wrote:
>
> Hi Rob.
>
> On Tue, Mar 31, 2020 at 11:20:13AM -0600, Rob Herring wrote:
> > On Sun, Mar 29, 2020 at 1:04 PM Sam Ravnborg wrote:
> > >
> > > Hi Rob.
> > >
> > > > > +
> > > > > + mode-gpios:
> > > > > +description: |
> > > > > +
Now that we've removed the last user of this callback, get rid of it and
drm_dp_destroy_connector().
Signed-off-by: Lyude Paul
Cc: Pankaj Bharadiya
---
drivers/gpu/drm/drm_dp_mst_topology.c | 16 +++-
include/drm/drm_dp_mst_helper.h | 2 --
2 files changed, 3 insertions(+),
You can already trace the creation and destruction of connectors using
DRM, and we definitely don't need to be printing info messages on
connector hotplugs as well. So, get rid of these.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c | 5 -
1 file
On Tue, Mar 24, 2020 at 05:45:25PM +0800, David Lu wrote:
> Add bindings documentation for BOE TV105WUM-NW0 10.5" WUXGA TFT LCD
> panel.
>
> Signed-off-by: David Lu
> Change-Id: I450c0e52aae080728d4794bdffc50bb0d2f39f40
Drop this.
> ---
>
Hi Rob.
On Tue, Mar 31, 2020 at 11:20:13AM -0600, Rob Herring wrote:
> On Sun, Mar 29, 2020 at 1:04 PM Sam Ravnborg wrote:
> >
> > Hi Rob.
> >
> > > > +
> > > > + mode-gpios:
> > > > +description: |
> > > > + GPIO ordered MO, LR, and UD as specified in LS037V7DW01.pdf
> > >
> > > 3
On Mon, Mar 23, 2020 at 11:16:57PM +0530, Kiran Gunda wrote:
> Add WLED5 specific bindings.
>
More of the same comments here...
> Signed-off-by: Kiran Gunda
> Signed-off-by: Subbaraman Narayanamurthy
> ---
> .../bindings/leds/backlight/qcom-wled.yaml | 39
> ++
>
On Mon, Mar 23, 2020 at 11:16:55PM +0530, Kiran Gunda wrote:
> Convert the qcom-wled bindings from .txt to .yaml format.
>
> Signed-off-by: Kiran Gunda
> Signed-off-by: Subbaraman Narayanamurthy
> Acked-by: Daniel Thompson
> ---
> .../bindings/leds/backlight/qcom-wled.txt | 154
On Tue, Mar 31, 2020 at 01:25:51PM +0530, Sharat Masetty wrote:
> This patch adds support to parse the OPP tables attached the GPU device,
> the main opp table and the DDR bandwidth opp table. Additionally, vote
> for the GPU->DDR bandwidth when setting the GPU frequency by querying
> the linked
On Sun, Mar 29, 2020 at 1:04 PM Sam Ravnborg wrote:
>
> Hi Rob.
>
> > > +
> > > + mode-gpios:
> > > +description: |
> > > + GPIO ordered MO, LR, and UD as specified in LS037V7DW01.pdf
> >
> > 3 or...
> >
> > > + change configuration between QVGA and VGA mode and the
> > > +
Hi,
On 3/31/20 6:44 PM, Jani Nikula wrote:
On Fri, 27 Mar 2020, David Santamaría Rogado wrote:
This patch is still valid as no changes to panel orientation quirks
have been done. Someone can review this to merge?
Cc: Hans.
Looks good to me:
Reviewed-by: Hans de Goede
Regards,
Hans
On Fri, 27 Mar 2020, David Santamaría Rogado wrote:
> This patch is still valid as no changes to panel orientation quirks
> have been done. Someone can review this to merge?
Cc: Hans.
>
> El mar., 30 jul. 2019 a las 21:49, David Santamaría Rogado
> () escribió:
>>
>> This adds the HD version of
On Tue, Mar 31, 2020 at 01:25:52PM +0530, Sharat Masetty wrote:
> This patch fixes an error in the for loop, thereby allowing search on
> the full list of possible GPU power levels.
>
> Signed-off-by: Sharat Masetty
Oh fun. This qualifies for drm-fixes. Can you pull this out of the stack and CC
On Mon, Mar 30, 2020 at 09:25:11PM +0200, Sam Ravnborg wrote:
> Hi Matthias.
>
> On Sun, Mar 29, 2020 at 10:44:17AM -0700, Matthias Kaehlcke wrote:
> > Hi Sam,
> >
> > On Sat, Mar 28, 2020 at 09:40:47PM +0100, Sam Ravnborg wrote:
> > > Hi Harigovindan
> > >
> > > On Fri, Mar 27, 2020 at
Hi,
On Tue, Mar 31, 2020 at 6:58 AM Kalyan Thota wrote:
>
> "The PM core always increments the runtime usage counter
> before calling the ->suspend() callback and decrements it
> after calling the ->resume() callback"
>
> DPU and DSI are managed as runtime devices. When
> suspend is triggered,
From: CK Hu
mtk_hdmi_phy is currently placed inside mediatek drm driver, but it's
more suitable to place a phy driver into phy driver folder, so move
mtk_hdmi_phy driver into phy driver folder.
Signed-off-by: CK Hu
Signed-off-by: Chun-Kuang Hu
---
drivers/gpu/drm/mediatek/Kconfig
mtk_hdmi_phy is currently placed inside mediatek drm driver, but it's
more suitable to place a phy driver into phy driver folder, so move
mtk_hdmi_phy driver into phy driver folder.
Changes in v3:
- Modify [PATCH v2 3/4] prefix.
Changes in v2:
- include module.h in mtk_hdmi.c
CK Hu (3):
From: CK Hu
tz_disabled is used to control mtk_hdmi output signal, but this variable
is stored in mtk_hdmi_phy and mtk_hdmi_phy does not use it. So move
tz_disabled to mtk_hdmi where it's used.
Signed-off-by: CK Hu
Signed-off-by: Chun-Kuang Hu
---
drivers/gpu/drm/mediatek/mtk_hdmi.c
Mediatek HDMI phy driver is moved from drivers/gpu/drm/mediatek to
drivers/phy/mediatek, so add the new folder to the Mediatek DRM drivers'
information.
Signed-off-by: Chun-Kuang Hu
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index
From: CK Hu
mtk_hdmi_phy is a part of mtk_hdmi module, but phy driver should be an
independent module rather than be part of drm module, so separate the phy
driver to an independent module.
Signed-off-by: CK Hu
Signed-off-by: Chun-Kuang Hu
---
drivers/gpu/drm/mediatek/Kconfig| 9
Use drm_dbg_kms() instead of DRM_DEBUG_KMS.
Signed-off-by: Andrzej Pietrasiewicz
---
drivers/gpu/drm/drm_gem_framebuffer_helper.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_framebuffer_helper.c
This short series addresses the way bpp value is made available
for drm_gem_afbc_min_size(). It can be inferred from the format
if a driver hasn't set anything in cpp[0] (patch 2/2).
While at it, use proper debugging macro (patch 1/2).
Andrzej Pietrasiewicz (2):
drm/core: Use proper debugging
Some drivers (komeda, malidp) don't set anything in cpp. If that is the
case the right value can be inferred from the format. Then the "bpp" member
can be eliminated from struct drm_afbc_framebuffer.
Signed-off-by: Andrzej Pietrasiewicz
---
Documentation/gpu/todo.rst | 15
On Tue, Mar 31, 2020 at 05:50:10PM +0300, Oleksandr Andrushchenko wrote:
> On 3/30/20 12:59, Ding Xiang wrote:
> > Fix a static code checker warning:
> > drivers/gpu/drm/xen/xen_drm_front.c:404 xen_drm_drv_dumb_create()
> > warn: passing zero to 'PTR_ERR'
> >
> > Signed-off-by: Ding
On Tue, Mar 31, 2020 at 6:55 AM Melissa Wen wrote:
>
> These patches address many code style issues on dc_link for readability
> and cleaning up warnings. Change suggested by checkpatch.pl.
> Some issues remain and need some minor code refactoring for proper handling.
>
> Melissa Wen (4):
>
On 3/30/20 12:59, Ding Xiang wrote:
Fix a static code checker warning:
drivers/gpu/drm/xen/xen_drm_front.c:404 xen_drm_drv_dumb_create()
warn: passing zero to 'PTR_ERR'
Signed-off-by: Ding Xiang
Reviewed-by: Oleksandr Andrushchenko
---
drivers/gpu/drm/xen/xen_drm_front.c | 2 +-
On Fri, Mar 27, 2020 at 2:22 PM Sam Ravnborg wrote:
>
> Hi Rob.
>
> On Wed, Mar 25, 2020 at 04:05:38PM -0600, Rob Herring wrote:
> > The 'adi,adxl345' definition is a duplicate as there's a full binding in:
> > Documentation/devicetree/bindings/iio/accel/adi,adxl345.yaml
> >
> > The
On Mon, Mar 30, 2020 at 2:38 AM Masahiro Yamada wrote:
>
> Hi Rob,
>
> On Mon, Mar 30, 2020 at 4:09 PM Masahiro Yamada wrote:
> >
> > On Thu, Mar 26, 2020 at 7:06 AM Rob Herring wrote:
> > >
> > > Setting 'additionalProperties: false' is frequently omitted, but is
> > > important in order to
On Tue, Mar 31, 2020 at 3:38 AM Nathan Chancellor
wrote:
>
> When building arm32 allyesconfig,
>
> ld.lld: error: undefined symbol: __aeabi_uldivmod
> >>> referenced by freesync.c
> >>>
> >>> gpu/drm/amd/display/modules/freesync/freesync.o:(mod_freesync_build_vrr_params)
> >>> in
Hi Alex,
On 2020-03-31 16:10, Alex Deucher wrote:
> On Tue, Mar 31, 2020 at 1:25 AM Marek Szyprowski
> wrote:
>> Hi Alex,
>>
>> On 2020-03-30 15:23, Alex Deucher wrote:
>>> On Mon, Mar 30, 2020 at 4:18 AM Marek Szyprowski
>>> wrote:
Hi
On 2020-03-27 10:10, Marek Szyprowski wrote:
On Tue, Mar 31, 2020 at 1:25 AM Marek Szyprowski
wrote:
>
> Hi Alex,
>
> On 2020-03-30 15:23, Alex Deucher wrote:
> > On Mon, Mar 30, 2020 at 4:18 AM Marek Szyprowski
> > wrote:
> >> Hi
> >>
> >> On 2020-03-27 10:10, Marek Szyprowski wrote:
> >>> Hi Christian,
> >>>
> >>> On 2020-03-27 09:11,
On Mon, Mar 30, 2020 at 02:00:12PM -0700, Guru Das Srinagesh wrote:
> On Mon, Mar 30, 2020 at 09:26:36PM +0100, Daniel Thompson wrote:
> > On Mon, Mar 30, 2020 at 12:15:07PM -0700, Guru Das Srinagesh wrote:
> > > On Sat, Mar 21, 2020 at 02:47:03PM +0300, Dan Carpenter wrote:
> > > > This is a
We try hard to select a suitable hole in the drm_mm first time. But if
that is unsuccessful, we then have to look at neighbouring nodes, and
this requires traversing the rbtree. Walking the rbtree can be slow
(much slower than a linear list for deep trees), and if the drm_mm has
been purposefully
Quoting Daniel Vetter (2020-03-31 11:38:50)
> On Tue, Mar 31, 2020 at 11:20 AM Chris Wilson
> wrote:
> > Quoting Daniel Vetter (2020-03-31 10:16:18)
> > > On Tue, Mar 31, 2020 at 10:59:45AM +0200, Christian König wrote:
> > > > A not so gentle ping, since this pretty much broke all TTM based
>
Hi, Neil:
Neil Armstrong 於 2020年3月31日 週二 下午4:05寫道：
>
> Hi,
>
> On 30/03/2020 16:12, Chun-Kuang Hu wrote:
> > From: CK Hu
> >
> > mtk_hdmi_phy is currently placed inside mediatek drm driver, but it's
> > more suitable to place a phy driver into phy driver folder, so move
> > mtk_hdmi_phy driver
On Tue, Mar 31, 2020 at 2:50 PM Daniel Vetter wrote:
>
> On Tue, Mar 31, 2020 at 2:18 PM Bartlomiej Zolnierkiewicz
> wrote:
> >
> >
> > On 3/31/20 12:18 PM, Dmitry Vyukov wrote:
> > > On Tue, Mar 31, 2020 at 11:57 AM Peter Zijlstra
> > > wrote:
> > >>
> > >> On Mon, Mar 30, 2020 at 10:01:12PM
On Tue, Mar 31, 2020 at 2:18 PM Bartlomiej Zolnierkiewicz
wrote:
>
>
> On 3/31/20 12:18 PM, Dmitry Vyukov wrote:
> > On Tue, Mar 31, 2020 at 11:57 AM Peter Zijlstra
> > wrote:
> >>
> >> On Mon, Mar 30, 2020 at 10:01:12PM -0700, syzbot wrote:
> >>> Hello,
> >>>
> >>> syzbot found the following
Am 31.03.20 um 12:38 schrieb Daniel Vetter:
On Tue, Mar 31, 2020 at 11:20 AM Chris Wilson wrote:
Quoting Daniel Vetter (2020-03-31 10:16:18)
On Tue, Mar 31, 2020 at 10:59:45AM +0200, Christian König wrote:
A not so gentle ping, since this pretty much broke all TTM based drivers.
Could we
[ please remember to include dri-devel ML & me on fbdev issues, thank you ]
On 3/29/20 1:37 AM, Andy Lutomirski wrote:
> On Sat, Mar 28, 2020 at 12:34 PM syzbot
> wrote:
>>
>> Hello,
>>
>> syzbot found the following crash on:
>>
>> HEAD commit:69c5eea3 Merge branch 'parisc-5.6-2' of
On 3/31/20 12:18 PM, Dmitry Vyukov wrote:
> On Tue, Mar 31, 2020 at 11:57 AM Peter Zijlstra wrote:
>>
>> On Mon, Mar 30, 2020 at 10:01:12PM -0700, syzbot wrote:
>>> Hello,
>>>
>>> syzbot found the following crash on:
>>>
>>> HEAD commit:9420e8ad Merge tag 'for-linus' of
On Tue, Mar 31, 2020 at 01:59:32PM +0200, Bartlomiej Zolnierkiewicz wrote:
>
> On 3/27/20 9:25 AM, Takashi Iwai wrote:
> > On Fri, 20 Mar 2020 14:42:51 +0100,
> > Bartlomiej Zolnierkiewicz wrote:
> >>
> >>
> >> On 3/19/20 4:49 PM, Takashi Iwai wrote:
> >>> On Wed, 11 Mar 2020 10:32:27 +0100,
>
On 3/27/20 9:25 AM, Takashi Iwai wrote:
> On Fri, 20 Mar 2020 14:42:51 +0100,
> Bartlomiej Zolnierkiewicz wrote:
>>
>>
>> On 3/19/20 4:49 PM, Takashi Iwai wrote:
>>> On Wed, 11 Mar 2020 10:32:27 +0100,
>>> Takashi Iwai wrote:
Hi,
here is a series of trivial patches just to
On 3/30/20 3:32 PM, Michal Simek wrote:
> The latest Xilinx design tools called ISE and EDK has been released in
> October 2013. New tool doesn't support any PPC405/PPC440 new designs.
> These platforms are no longer supported and tested.
>
> PowerPC 405/440 port is orphan from 2013 by
> commit
From: Heiko Stuebner
The LTK500HD1829W is 5.0" 720x1280 DSI display.
Signed-off-by: Heiko Stuebner
---
drivers/gpu/drm/panel/Kconfig | 11 +
drivers/gpu/drm/panel/Makefile| 1 +
.../drm/panel/panel-leadtek-ltk050h3146w.c| 589 ++
3 files
From: Heiko Stuebner
The LTK050H3146W is a 5.0" 720x1280 DSI display.
Signed-off-by: Heiko Stuebner
---
.../display/panel/leadtek,ltk050h3146w.yaml | 49 +++
1 file changed, 49 insertions(+)
create mode 100644
Removes codestyle issues on the file dc_link between is_same_edid and
get_ddc_line as suggested by checkpatch.pl.
Types covered:
CHECK: Blank lines aren't necessary after an open brace '{'
CHECK: Blank lines aren't necessary before a close brace '}'
WARNING: braces {} are not necessary for
Removes codestyle issues in dc_link file, on dc_link_construct and
translate_encoder_to_transmitter as suggested by checkpatch.pl.
Types covered:
CHECK: Lines should not end with a '('
WARNING: Missing a blank line after declarations
CHECK: Alignment should match open parenthesis
CHECK:
Removes codestyle issues on the file dc_link until detect_dp func as
suggested by checkpatch.pl.
Types covered:
CHECK: Please don't use multiple blank lines
CHECK: Comparison to NULL could be written
ERROR: space required before the open parenthesis '('
CHECK: Alignment should match open
Solve comments alignment problems on dc_link file
Signed-off-by: Melissa Wen
---
drivers/gpu/drm/amd/display/dc/core/dc_link.c | 25 +++
1 file changed, 15 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
These patches address many code style issues on dc_link for readability
and cleaning up warnings. Change suggested by checkpatch.pl.
Some issues remain and need some minor code refactoring for proper handling.
Melissa Wen (4):
drm/amd/display: cleanup codestyle type BLOCK_COMMENT_STYLE on
On Tue, Mar 31, 2020 at 11:20 AM Chris Wilson wrote:
> Quoting Daniel Vetter (2020-03-31 10:16:18)
> > On Tue, Mar 31, 2020 at 10:59:45AM +0200, Christian König wrote:
> > > A not so gentle ping, since this pretty much broke all TTM based drivers.
> > >
> > > Could we revert this for now?
> >
> >
Calling the VRAM helper's prepare_fb() helper now sets the plane's
fence object. This will be useful for PRIME support. VRAM helpers
don't support buffer sharing ATM, so for now there are no drivers
requiring this change.
v2:
* removed a TODO comment about buffer synchronization
Hi
Am 31.03.20 um 10:50 schrieb Daniel Vetter:
> On Tue, Mar 31, 2020 at 10:11:30AM +0200, Thomas Zimmermann wrote:
>> Calling the VRAM helper's prepare_fb() helper now sets the plane's
>> fence object. The helper still has to synchronize with other users
>> of the GEM object. Leave a related
Quoting Daniel Vetter (2020-03-31 10:16:18)
> On Tue, Mar 31, 2020 at 10:59:45AM +0200, Christian König wrote:
> > A not so gentle ping, since this pretty much broke all TTM based drivers.
> >
> > Could we revert this for now?
>
> Always ack for revert.
>
> Acked-by: Daniel Vetter
So you
Quoting Christian König (2020-03-31 09:59:45)
> A not so gentle ping, since this pretty much broke all TTM based drivers.
>
> Could we revert this for now?
Ping???
https://patchwork.freedesktop.org/patch/358535/?series=74984=1
-Chris
___
dri-devel
Hi
Am 24.03.20 um 12:59 schrieb Rodrigo Siqueira:
> Hi Thomas,
>
> First of all, thanks for your patch!
>
> I applied all your series, compiled it, and when I tried
> `make INSTALL_MOD_PATH=/PATH/ modules_instal` I got the following
> message:
>
> depmod: ERROR: Cycle detected: drm_kms_helper
On Tue, Mar 31, 2020 at 10:59:45AM +0200, Christian König wrote:
> A not so gentle ping, since this pretty much broke all TTM based drivers.
>
> Could we revert this for now?
Always ack for revert.
Acked-by: Daniel Vetter
Needs to go to drm-misc-next-fixes, and then maybe also ask for a
On Sun, Mar 29, 2020 at 02:45:08PM +, Simon Ser wrote:
> This is a standard property attached to planes in drm_universal_plane_init
> when drm_mode_config.allow_fb_modifiers is true.
>
> Signed-off-by: Simon Ser
> Cc: Daniel Vetter
> Cc: Daniel Stone
> ---
> drivers/gpu/drm/drm_blend.c |
A not so gentle ping, since this pretty much broke all TTM based drivers.
Could we revert this for now?
Thanks,
Christian.
Am 30.03.20 um 14:34 schrieb Christian König:
This reverts commit 7be1b9b8e9d1e9ef0342d2e001f44eec4030aa4d.
The drm_mm is supposed to work in atomic context, so calling
On Tue, Mar 31, 2020 at 10:11:30AM +0200, Thomas Zimmermann wrote:
> Calling the VRAM helper's prepare_fb() helper now sets the plane's
> fence object. The helper still has to synchronize with other users
> of the GEM object. Leave a related TODO comment in the code.
>
> This will be useful for
On Tue, Mar 31, 2020 at 10:12:38AM +0200, Thomas Zimmermann wrote:
> Most of the documentation was in an otherwise empty file, which was
> probably just left from a previous clean-up effort. So move code and
> documentation into a single file.
>
> Signed-off-by: Thomas Zimmermann
Acked-by: Gerd
Hi,
> + * TODO: Synchronize with other users of the buffer. Buffers
> + * cannot be pinned to VRAM while they are in use by other
> + * drivers for DMA. We should probably wait for each GEM
> + * object's fence before attempting to pin the buffer.
The
On Mon, Mar 30, 2020 at 03:55:31PM +0200, Christian König wrote:
> Add a peer2peer flag noting that the importer can deal with device
> resources which are not backed by pages.
>
> Signed-off-by: Christian König
On the series:
Acked-by: Daniel Vetter
> ---
> drivers/dma-buf/dma-buf.c | 2 ++
Changes since v3:
- refine drive-strength-microamp as from 3000 to 6000.
Changes since v2:
- fix the title of commit message.
- rename mipitx-current-drive to drive-strength-microamp
Changes since v1:
- fix coding style.
- change mtk_mipi_tx_config_calibration_data() to void
Jitao Shi (4):
Add properties to get get mipitx calibration data.
Reviewed-by: Rob Herring
Signed-off-by: Jitao Shi
---
.../devicetree/bindings/display/mediatek/mediatek,dsi.txt| 5 +
1 file changed, 5 insertions(+)
diff --git
a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt
Read calibration data from nvmem, and config mipitx impedance with
calibration data to make sure their impedance are 100ohm.
Signed-off-by: Jitao Shi
---
drivers/gpu/drm/mediatek/mtk_mt8183_mipi_tx.c | 57 +++
1 file changed, 57 insertions(+)
diff --git
Add a property in device tree to control the driving by different
board.
Reviewed-by: Matthias Brugger
Signed-off-by: Jitao Shi
---
drivers/gpu/drm/mediatek/mtk_mipi_tx.c| 14 ++
drivers/gpu/drm/mediatek/mtk_mipi_tx.h| 1 +
Add a property to control mipi tx drive current:
"drive-strength-microamp"
Signed-off-by: Jitao Shi
---
.../devicetree/bindings/display/mediatek/mediatek,dsi.txt| 5 +
1 file changed, 5 insertions(+)
diff --git
a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt
Most of the documentation was in an otherwise empty file, which was
probably just left from a previous clean-up effort. So move code and
documentation into a single file.
Signed-off-by: Thomas Zimmermann
---
Documentation/gpu/drm-mm.rst | 9 ---
drivers/gpu/drm/Makefile
Calling the VRAM helper's prepare_fb() helper now sets the plane's
fence object. The helper still has to synchronize with other users
of the GEM object. Leave a related TODO comment in the code.
This will be useful for PRIME support. VRAM helpers don't support
buffer sharing ATM, so there are no
Hi,
On 30/03/2020 16:12, Chun-Kuang Hu wrote:
> From: CK Hu
>
> mtk_hdmi_phy is currently placed inside mediatek drm driver, but it's
> more suitable to place a phy driver into phy driver folder, so move
> mtk_hdmi_phy driver into phy driver folder.
Pretty sure the subject should start with
On Mon, Mar 30, 2020 at 09:16:19PM +0200, Sam Ravnborg wrote:
> Hi Qiujun
>
> On Sun, Mar 29, 2020 at 04:56:47PM +0800, Qiujun Huang wrote:
> > Set logo_shown to FBCON_LOGO_CANSHOW when the vc was deallocated.
> >
> > syzkaller report: https://lkml.org/lkml/2020/3/27/403
> > general protection
This patch adds support to parse the OPP tables attached the GPU device,
the main opp table and the DDR bandwidth opp table. Additionally, vote
for the GPU->DDR bandwidth when setting the GPU frequency by querying
the linked DDR BW opp to the GPU opp.
Signed-off-by: Sharat Masetty
---
This patch fixes an error in the for loop, thereby allowing search on
the full list of possible GPU power levels.
Signed-off-by: Sharat Masetty
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
Update the documentation for listing the multiple optional GPU and the
DDR OPP tables to help enable DDR scaling.
Signed-off-by: Sharat Masetty
---
.../devicetree/bindings/display/msm/gpu.txt| 63 +-
1 file changed, 61 insertions(+), 2 deletions(-)
diff --git
This patch adds the interconnect bindings to the GPU node. This enables
the GPU->DDR path bandwidth voting.
Signed-off-by: Sharat Masetty
---
arch/arm64/boot/dts/qcom/sc7180.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sc7180.dtsi
This patch adds a new opp table listing the GPU DDR bandwidth opps. Also
adds a required_opp binding to the GPUs main OPP table which holds a
phandle to a bandwidth opp in the new table. This enables linking the
GPU power level opp to the DDR bandwidth opp and helps with scaling
DDR along with GPU
This series adds support for GPU DDR bandwidth scaling and is based on the
bindings from Sarvana[1]. This work is based on Sibi's work for CPU side [2]
which also lists all the needed dependencies to get this series working.
My workspace is based on a chrome tag [3]. Although the bindings add
On Mon, Mar 30, 2020 at 05:51:26PM -0400, Lyude Paul wrote:
> I am glad that my explanation of vblanks made sense! Some comments below on
> things I think we could improve here
>
> On Mon, 2020-03-30 at 20:57 +0200, Sam Ravnborg wrote:
> > Lyude Paul wrote a very good intro to vblank here:
> >
>
On Sat, Mar 28, 2020 at 02:20:22PM +0100, Sam Ravnborg wrote:
> Fix following warning:
> gpu_scheduler.h:103: warning: Function parameter or member 'priority' not
> described in 'drm_sched_entity'
>
> Signed-off-by: Sam Ravnborg
> Cc: Nirmoy Das
> Cc: David Airlie
> Cc: Daniel Vetter
Inline
On Sat, Mar 28, 2020 at 02:20:23PM +0100, Sam Ravnborg wrote:
> Document the callbacks:
> drm_connector_helper_funcs.prepare_writeback_job
> drm_connector_helper_funcs.cleanup_writeback_job
>
> The documentation was pulled from the changelong introducing the
> callbacks, originally
On Sat, Mar 28, 2020 at 02:20:25PM +0100, Sam Ravnborg wrote:
> Add missing documentation to fix following warning:
> panel.c:303: warning: Function parameter or member 'bridge' not described in
> 'drm_panel_bridge_connector'
>
> Signed-off-by: Sam Ravnborg
> Cc: Laurent Pinchart
> Cc: Boris
On Fri, Mar 27, 2020 at 09:11:44AM +0100, Julia Lawall wrote:
> NULL check before kfree is not needed.
>
> Generated by: scripts/coccinelle/free/ifnullfree.cocci
>
> Fixes: c6603c740e0e ("drm: add managed resources tied to drm_device")
> Signed-off-by: kbuild test robot
> Signed-off-by: Julia
1 - 100 of 128 matches
Mail list logo
