tree: git://people.freedesktop.org/~agd5f/linux.git
amd-staging-drm-next-navi10
head: e82deaaf0052ac2c79d5f600a953bd951a0b4351
commit: 8ebfb4406404b21eef5c79b48ff3b2eb122c [323/469] drm/amd/display:
Read soc_bounding_box from gpu_info (v2)
reproduce: make htmldocs
If you fix the issue, k
https://bugs.freedesktop.org/show_bug.cgi?id=110956
--- Comment #2 from Andrew Shark ---
Bug 110957 - wsa-amdgpu package has empty copyright file
Bug 110958 - Mentioning 32 bit OS support in Release page
Bug 110959 - Broken link to Homepage of some packages
Bug 110960 - Non-existent alternative d
https://bugs.freedesktop.org/show_bug.cgi?id=110968
Bug ID: 110968
Summary: Allow ubuntu users to install on other ubuntu versions
Product: DRI
Version: unspecified
Hardware: Other
OS: All
Status: NEW
Seve
https://bugs.freedesktop.org/show_bug.cgi?id=110674
--- Comment #45 from sehell...@gmail.com ---
Created attachment 144611
--> https://bugs.freedesktop.org/attachment.cgi?id=144611&action=edit
5.2-rc2 full dmesg with amdgpu.ppfeaturemask=0xfffdbfff
--
You are receiving this mail because:
You a
https://bugs.freedesktop.org/show_bug.cgi?id=110967
Bug ID: 110967
Summary: Naming packages with pro suffix depending if open or
close source
Product: DRI
Version: unspecified
Hardware: Other
OS: All
https://bugs.freedesktop.org/show_bug.cgi?id=110674
--- Comment #44 from sehell...@gmail.com ---
(In reply to Matt Coffin from comment #42)
> For what it's worth, I've experienced a bunch of issues similar to this with
> OVERDRIVE enabled. You can try disabling it by setting the following in
> mod
https://bugs.freedesktop.org/show_bug.cgi?id=110966
Bug ID: 110966
Summary: Documentation update about required lunar sdk
Product: DRI
Version: unspecified
Hardware: Other
OS: All
Status: NEW
Severity: tri
https://bugs.freedesktop.org/show_bug.cgi?id=110965
Bug ID: 110965
Summary: Documentation update about not provided PX package
Product: DRI
Version: unspecified
Hardware: Other
OS: All
Status: NEW
Severity
https://bugs.freedesktop.org/show_bug.cgi?id=110964
Bug ID: 110964
Summary: Documentation update about provided Open Vulkan
implementation
Product: DRI
Version: unspecified
Hardware: Other
OS: All
This inits the panel orientation property for the mediatek dsi driver
if the panel orientation (connector.display_info.panel_orientation) is
not DRM_MODE_PANEL_ORIENTATION_UNKNOWN.
Signed-off-by: Derek Basehore
---
drivers/gpu/drm/mediatek/mtk_dsi.c | 8
1 file changed, 8 insertions(+)
Devicetree systems can set panel orientation via a panel binding, but
there's no way, as is, to propagate this setting to the connector,
where the property need to be added.
To address this, this patch sets orientation, as well as other fixed
values for the panel, in the drm_panel_attach function.
This adds a helper function for reading the rotation (panel
orientation) from the device tree.
Signed-off-by: Derek Basehore
---
drivers/gpu/drm/drm_panel.c | 42 +
include/drm/drm_panel.h | 7 +++
2 files changed, 49 insertions(+)
diff --git a/drive
This adds the plumbing for reading panel rotation from the devicetree
and sets up adding a panel property for the panel orientation on
Mediatek SoCs when a rotation is present.
v3 changes:
-changed from attach/detach callbacks to directly setting fixed panel
values in drm_panel_attach
-removed up
Not every platform needs quirk detection for panel orientation, so
split the drm_connector_init_panel_orientation_property into two
functions. One for platforms without the need for quirks, and the
other for platforms that need quirks.
Signed-off-by: Derek Basehore
---
drivers/gpu/drm/drm_connec
https://bugs.freedesktop.org/show_bug.cgi?id=110963
Bug ID: 110963
Summary: Wrong condition and wrong variable substitution in
libgl1-amdgpu-mesa-dri in postinst script
Product: DRI
Version: unspecified
Hardware: Other
https://bugs.freedesktop.org/show_bug.cgi?id=110962
Bug ID: 110962
Summary: Wrong dependencies cause force dependency on
amdgpu-dkms
Product: DRI
Version: unspecified
Hardware: Other
OS: All
Stat
https://bugs.freedesktop.org/show_bug.cgi?id=110961
Bug ID: 110961
Summary: Are provoded libdrm packages completely open source?
Product: DRI
Version: unspecified
Hardware: Other
OS: All
Status: NEW
Severi
https://bugs.freedesktop.org/show_bug.cgi?id=110960
Bug ID: 110960
Summary: Non-existent alternative dependencies in some deb
packages
Product: DRI
Version: unspecified
Hardware: Other
OS: All
St
https://bugs.freedesktop.org/show_bug.cgi?id=110959
Bug ID: 110959
Summary: Broken link to Homepage of some packages
Product: DRI
Version: unspecified
Hardware: Other
OS: All
Status: NEW
Severity: enhancem
On Fri, Jun 21, 2019 at 2:19 AM Thierry Reding wrote:
>
> On Tue, Jun 11, 2019 at 05:25:47PM -0700, dbasehore . wrote:
> > On Tue, Jun 11, 2019 at 1:57 AM Daniel Vetter wrote:
> > >
> > > On Mon, Jun 10, 2019 at 09:03:48PM -0700, Derek Basehore wrote:
> > > > This adds the attach/detach callbacks
https://bugs.freedesktop.org/show_bug.cgi?id=110958
Bug ID: 110958
Summary: Mentioning 32 bit OS support in Release page
Product: DRI
Version: unspecified
Hardware: Other
OS: All
Status: NEW
Severity: enha
https://bugs.freedesktop.org/show_bug.cgi?id=110957
Bug ID: 110957
Summary: wsa-amdgpu package has empty copyright file
Product: DRI
Version: unspecified
Hardware: Other
OS: Linux (All)
Status: NEW
Severit
https://bugs.freedesktop.org/show_bug.cgi?id=110702
--- Comment #13 from asavah ---
Applied the PR mentioned in 12 as a patch on top of the 19.1.0 tarball release.
All the crashy samples I have now play perfectly.
All the good media I have continues playing perfectly.
Huge thanks for the quick f
On Fri, Jun 21, 2019 at 12:21 PM shuah wrote:
>
> On 6/21/19 12:13 PM, Theodore Ts'o wrote:
> > On Fri, Jun 21, 2019 at 08:59:48AM -0600, shuah wrote:
> ### But wait! Doesn't kselftest support in kernel testing?!
>
>
> >>
> >> I think I commented on this before. I agree with th
On Wed, Jun 19, 2019 at 6:17 PM Frank Rowand wrote:
>
> Hi Brendan,
>
> I am only responding to this because you asked me to in the v4 thread.
Yes, I did! Thank you, I appreciate it!
> Thank you for evaluating my comments in the v4 thread and asking me to
> comment on v5
Of course, I feel as th
On Thu, Jun 20, 2019 at 10:26 AM Ville Syrjala
wrote:
>
> From: Ville Syrjälä
>
> Ilia pointed out some oddball crap in the i915 aspect ratio handling.
> While looking at that I noticed a bunch of fail in the core as well.
> This series aims to fix it all.
>
> Cc: Ilia Mirkin
>
> Ville Syrjälä (
https://bugs.freedesktop.org/show_bug.cgi?id=110956
--- Comment #1 from Andre Klapper ---
Please split this ticket into separate issues - one issue per ticket.
Currently it is impossible to track progress via the ticket status, and
discussing any item from the list is cumbersome with lots of noi
Hi, Daniel,
On 6/21/19 5:57 PM, Daniel Vetter wrote:
On Fri, Jun 21, 2019 at 05:12:19PM +0200, Thomas Hellström (VMware) wrote:
On 6/21/19 1:57 PM, Gerd Hoffmann wrote:
Aargh. Please don't do this. Multiple reasons:
1) I think It's bad to dump all buffer object functionality we can possibly
On Fri, Jun 21, 2019 at 6:07 PM John Stultz wrote:
>
> Often there are many similar modes, which cannot be selected
> via modetest due to its simple string matching.
>
> This change adds a mode index in the display output, which can
> then be used to specify a specific modeline to be set.
>
> Cc:
From: Colin Ian King
Currently when too many retries have occurred there is a memory
leak on the allocation for reply on the error return path. Fix
this by kfree'ing reply before returning.
Addresses-Coverity: ("Resource leak")
Fixes: a9cd9c044aa9 ("drm/vmwgfx: Add a check to handle host message
Hi!
> [Sorry to those receiving this twice... had to dig this out from the
> archives and sent it to the lists from the wrong mailer]
>
> On 27/11/2018 00:44, Brian Dodge wrote:
> >Thank you Pavel, that is a good point.
> >
> >The chip vendor has indicated that there is no reason to maintain the
Often there are many similar modes, which cannot be selected
via modetest due to its simple string matching.
This change adds a mode index in the display output, which can
then be used to specify a specific modeline to be set.
Cc: Ilia Mirkin
Cc: Rob Clark
Cc: Bjorn Andersson
Cc: Sumit Semwal
On Fri, Jun 21, 2019 at 05:13:33PM -0400, Sven Van Asbroeck wrote:
> On Fri, Jun 21, 2019 at 11:15 AM Russell King - ARM Linux admin
> wrote:
> >
> > Another con is the need to keep the functions that detail the register
> > properties up to date, which if they're wrong may result in unexpected
>
Add the register specifier description for an
optional gamma LUT address.
Signed-off-by: Ezequiel Garcia
---
Changes from v1:
* Drop reg-names, suggested by Doug.
---
.../devicetree/bindings/display/rockchip/rockchip-vop.txt | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --gi
Let's support Gamma LUT configuration on RK3288 SoCs.
In order to do so, this series adds a new and optional
address resource.
A separate address resource is required because on this RK3288,
the LUT address is after the MMU address, which is requested
by the iommu driver. This prevents the DR
Add an optional CRTC gamma LUT support, and enable it on RK3288.
This is currently enabled via a separate address resource,
which needs to be specified in the devicetree.
The address resource is required because on some SoCs, such as
RK3288, the LUT address is after the MMU address, and the latter
On Fri, Jun 21, 2019 at 11:15 AM Russell King - ARM Linux admin
wrote:
>
> Another con is the need to keep the functions that detail the register
> properties up to date, which if they're wrong may result in unexpected
> behaviour.
>
> I subscribe to the "keep it simple" approach, and regmap, alth
RK3288 SoC VOPs have optional support Gamma LUT setting,
which requires specifying the Gamma LUT address in the devicetree.
Signed-off-by: Ezequiel Garcia
---
Changes from v1:
* Drop reg-names, as suggested by Doug.
---
arch/arm/boot/dts/rk3288.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 d
https://bugs.freedesktop.org/show_bug.cgi?id=110674
--- Comment #43 from Matt Coffin ---
(In reply to Matt Coffin from comment #42)
> For what it's worth, I've experienced a bunch of issues similar to this with
> OVERDRIVE enabled. You can try disabling it by setting the following in
> modprobe.d
https://bugs.freedesktop.org/show_bug.cgi?id=110674
--- Comment #42 from Matt Coffin ---
For what it's worth, I've experienced a bunch of issues similar to this with
OVERDRIVE enabled. You can try disabling it by setting the following in
modprobe.d or your kernel launch line
amdgpu.ppfeaturemask
https://bugs.freedesktop.org/show_bug.cgi?id=110956
Bug ID: 110956
Summary: List of 19.20-812932 release mistakes
Product: DRI
Version: unspecified
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Seve
On Fri, 21 Jun 2019 at 20:49, Sam Ravnborg wrote:
>
> Build tested using allyesconfig, allmodconfig for various
> architectures.
Hi,
Thanks for fixes. Just for the record, allyesconfig/allmodconfig are
not a proper way for build test specific drivers. They are nice but
since all dependencies are
On 6/21/19 12:13 PM, Theodore Ts'o wrote:
On Fri, Jun 21, 2019 at 08:59:48AM -0600, shuah wrote:
### But wait! Doesn't kselftest support in kernel testing?!
I think I commented on this before. I agree with the statement that
there is no overlap between Kselftest and KUnit. I would like s
Build tested using allyesconfig, allmodconfig for various
architectures.
v2:
- add missing people to recipient list of mail
- no change in actual patch
v3:
- fix build breakage (Inki Dae)
The testing I had done with allyesconfig, allmodconfig
did not trigger a configuration where exynos_drm_g2d.
Drop use of the deprecated drmP.h file.
Replace with forwards / externals as appropriate.
While touching the list of include files divide
them up in blocks and sort them.
v3:
- fix build errors in exynos_drm_g2d.c (Inki Dae)
The exynos_drm_g2d.c file is not built in the
standard configuration
https://bugs.freedesktop.org/show_bug.cgi?id=110117
--- Comment #14 from edo hikmahtiar ---
happened to me too using Opensuse Tumbleweed with kernel 5.1.7 and MESA 19.0.5,
I have been try to disable power management in amdgpu via kernel paramater but
still happen.
this happen to me while I play s
On Fri, Jun 21, 2019 at 08:59:48AM -0600, shuah wrote:
> > > ### But wait! Doesn't kselftest support in kernel testing?!
> > >
> > >
>
> I think I commented on this before. I agree with the statement that
> there is no overlap between Kselftest and KUnit. I would like see this
> removed. Ksel
On 2019/06/19, Ilia Mirkin wrote:
> The bulk SPDX addition made all these files into GPL-2.0 licensed files.
> However the remainder of the project is MIT-licensed, these files
> (primarily header files) were simply missing the boiler plate and got
> caught up in the global update.
>
> Fixes: b244
The pull request you sent on Fri, 21 Jun 2019 14:20:53 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2019-06-21
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/0728f6c3cab107f0aab2c8ded1292dd2cc41a228
Thank you!
--
Deet-doot-dot, I am a bot.
https://k
On Fri, Jun 21, 2019 at 10:06 AM Daniel Stone wrote:
>
> > Does it work for you? I'm getting a connection reset, no data.
>
> It is quite sick indeed; it's fallen down an NFS hole and is being
> restarted. Should be back in a few minutes.
Thanks, everything does indeed look good again now,
Hi Jeffrey.
On Fri, Jun 21, 2019 at 11:31:50AM -0600, Jeffrey Hugo wrote:
> On Fri, Jun 14, 2019 at 12:55 PM Jeffrey Hugo
> wrote:
> >
> > Since we are trying to get the GPU and display hardware in the SoC
> > supported, it would be nice to be able to put the output on the
> > integrated panel f
On Fri, Jun 14, 2019 at 12:55 PM Jeffrey Hugo wrote:
>
> Since we are trying to get the GPU and display hardware in the SoC
> supported, it would be nice to be able to put the output on the
> integrated panel for the reference platform. To do so, we need support
> in the Truly driver to support t
On Fri, Jun 07, 2019 at 11:24:01AM +0100, Emil Velikov wrote:
> On Wed, 5 Jun 2019 at 13:08, Daniel Vetter wrote:
> >
> > This completes Emil's series of removing DRM_UNLOCKED from modern
> > drivers. It's entirely cargo-culted since we ignore it on
> > non-DRIVER_LEGACY drivers since:
> >
> > com
Hi,
On Fri, 21 Jun 2019 at 17:58, Linus Torvalds
wrote:
> On Thu, Jun 20, 2019 at 9:21 PM Dave Airlie wrote:
> >
> > Just catching up on the week since back from holidays, everything
> > seems quite sane.
>
> .. well, except for anongit.freedesktop.org itself, which seems very
> sick indeed.
>
>
On Thu, Jun 20, 2019 at 9:21 PM Dave Airlie wrote:
>
> Just catching up on the week since back from holidays, everything
> seems quite sane.
.. well, except for anongit.freedesktop.org itself, which seems very
sick indeed.
Does it work for you? I'm getting a connection reset, no data.
On Fri, Jun 21, 2019 at 03:48:24PM +0200, Christian König wrote:
> One little comment on patch #8:
> > + /* base.vma_node */
> Is that really useful? I would just drop it.
>
> Apart from that Patches #1, #2, #4, #5, #7 - #12, #14, #15, #18 are
> Reviewed-by: Christian König .
>
> Patches #3, #6
On Fri, Jun 21, 2019 at 02:06:54PM +0200, Christian König wrote:
> Am 21.06.19 um 12:32 schrieb Daniel Vetter:
> > On Fri, Jun 21, 2019 at 11:55 AM Christian König
> > wrote:
> > > Am 21.06.19 um 11:20 schrieb Daniel Vetter:
> > > > On Tue, Jun 18, 2019 at 01:54:50PM +0200, Christian König wrote:
Store the PTR_ERR() result in local variable in clock init error path.
This makes the code consistent with similar section in regulator init
code.
Signed-off-by: Krzysztof Kozlowski
---
Changes since v1:
1. New patch
---
drivers/gpu/drm/lima/lima_device.c | 10 ++
1 file changed, 6 ins
On 6/21/19 11:46 AM, Daniel Vetter wrote:
> On Fri, Jun 21, 2019 at 02:21:43PM +, Harry Wentland wrote:
>> On 2019-06-05 1:06 p.m., Dingchen Zhang wrote:
>>> to terminate the while-loop in drm_dp_aux_crc_work when
>>> drm_dp_start/stop_crc
>>> are called in the hook to set crc source.
>>>
>>>
Mark long numbers with ULL to silence the Smatch warning:
drivers/gpu/drm/lima/lima_device.c:314:32: warning: constant 0x1 is
so big it is long long
Signed-off-by: Krzysztof Kozlowski
Reviewed-by: Qiang Yu
---
Changes since v1:
1. Add reviewed-by tag
---
drivers/gpu/drm/lima/lim
There is no point to print deferred probe messages as errors. Adjust
the printks for error paths of obtaining clocks and reset controller.
This removes the error message of lima_clk_init() call in favor or
specific failure messages inside.
Signed-off-by: Krzysztof Kozlowski
---
Changes since v
There is no point to print deferred probe (and its failures to get
resources) as an error. For example getting a regulator causes three
unneeded error messages:
lima 1300.gpu: failed to get regulator: -517
lima 1300.gpu: regulator init fail -517
lima 1300.gpu: Fatal error
Ping.
On Fri, 2019-06-07 at 15:00 -0400, Qian Cai wrote:
> The opening comment mark "/**" is reserved for kernel-doc comments, so
> it will generate a warning with "make W=1".
>
> drivers/gpu/drm/drm_memory.c:2: warning: Cannot understand * \file
> drm_memory.c
>
> Also, silence a checkpatch wa
Hi Jacopo,
Thanks for the review.
On Fri, 2019-06-21 at 10:22 +0200, Jacopo Mondi wrote:
> Hi Ezequiel,
>just a few minor comments. Thanks for this new iteration.
>
> On Tue, Jun 18, 2019 at 06:34:05PM -0300, Ezequiel Garcia wrote:
> > Add an optional CRTC gamma LUT support, and enable it on
On Fri, Jun 21, 2019 at 05:12:19PM +0200, Thomas Hellström (VMware) wrote:
>
>
> On 6/21/19 1:57 PM, Gerd Hoffmann wrote:
>
> Aargh. Please don't do this. Multiple reasons:
>
> 1) I think It's bad to dump all buffer object functionality we can possibly
> think of in a single struct and force th
On Thu, 2019-06-20 at 10:25 -0700, Doug Anderson wrote:
> Hi,
>
> On Tue, Jun 18, 2019 at 2:43 PM Ezequiel Garcia
> wrote:
> > +static void vop_crtc_gamma_set(struct vop *vop, struct drm_crtc *crtc,
> > + struct drm_crtc_state *old_state)
> > +{
> > + int idle,
On 2019-06-21 5:44 p.m., Daniel Vetter wrote:
> On Fri, Jun 21, 2019 at 05:15:22PM +0200, Michel Dänzer wrote:
>> On 2019-06-21 1:50 p.m., Daniel Vetter wrote:
>>> On Fri, Jun 21, 2019 at 1:37 PM Christian König
>>> wrote:
Am 21.06.19 um 13:03 schrieb Daniel Vetter:
> So if you want to de
On Fri, Jun 21, 2019 at 02:45:45PM +0200, Philipp Zabel wrote:
> On Fri, 2019-06-21 at 21:41 +1000, Stephen Rothwell wrote:
> > Hi all,
> >
> > In commit
> >
> > 912bbf7e9ca4 ("gpu: ipu-v3: image-convert: Fix image downsize
> > coefficients")
> >
> > Fixes tag
> >
> > Fixes: 70b9b6b3bcb21
On Fri, Jun 21, 2019 at 02:21:43PM +, Harry Wentland wrote:
> On 2019-06-05 1:06 p.m., Dingchen Zhang wrote:
> > to terminate the while-loop in drm_dp_aux_crc_work when
> > drm_dp_start/stop_crc
> > are called in the hook to set crc source.
> >
> > Cc:Leo Li , Harry , Nick
> >
> > Signed-of
Hi Robert,
On Fri, Jun 21, 2019 at 11:16 AM Robert Chiras wrote:
> From what I've seen in the schematics, the power lines on the DSI port
> on all the i.MX8 cores are coming from a PMIC providing power for all
> the peripherals. Since I didn't find a way to cut the power on a single
> peripheral
On Fri, Jun 21, 2019 at 05:15:22PM +0200, Michel Dänzer wrote:
> On 2019-06-21 1:50 p.m., Daniel Vetter wrote:
> > On Fri, Jun 21, 2019 at 1:37 PM Christian König
> > wrote:
> >> Am 21.06.19 um 13:03 schrieb Daniel Vetter:
> >>> So if you want to depracate render functionality on primary nodes, yo
On Fri, Jun 21, 2019 at 01:00:17PM +, Koenig, Christian wrote:
> Am 21.06.19 um 14:47 schrieb Emil Velikov:
> > On 2019/06/21, Koenig, Christian wrote:
> >> Am 21.06.19 um 13:58 schrieb Emil Velikov:
> >>> On 2019/06/21, Koenig, Christian wrote:
> Am 21.06.19 um 12:53 schrieb Emil Velikov:
On Fri, Jun 21, 2019 at 12:21 PM Raymond Smith wrote:
>
> Add the DRM_FORMAT_MOD_ARM_16X16_BLOCK_U_INTERLEAVED modifier to
> denote the 16x16 block u-interleaved format used in Arm Utgard and
> Midgard GPUs.
>
> Signed-off-by: Raymond Smith
> ---
> include/uapi/drm/drm_fourcc.h | 10 ++
>
On 2019-06-21 1:58 p.m., Emil Velikov wrote:
> On 2019/06/21, Koenig, Christian wrote:
>> Am 21.06.19 um 12:53 schrieb Emil Velikov:
>>> On 2019/06/21, Koenig, Christian wrote:
>
> In particular, that user-space will "remove" render nodes.
Yes, that is my main concern here. You basically
On Mon, May 27, 2019 at 03:15:52PM -0400, Sven Van Asbroeck wrote:
> -static void
> -reg_set(struct tda998x_priv *priv, u16 reg, u8 val)
> +static int
> +reg_set(struct regmap *regmap, u16 reg, u8 val)
I don't see the point of making this return an 'int' - you don't modify
any of the callsites to
On 2019-06-21 1:50 p.m., Daniel Vetter wrote:
> On Fri, Jun 21, 2019 at 1:37 PM Christian König
> wrote:
>> Am 21.06.19 um 13:03 schrieb Daniel Vetter:
>>> So if you want to depracate render functionality on primary nodes, you
>>> _have_ to do that hiding in userspace. Or you'll break a lot of
>>>
On Mon, May 27, 2019 at 03:15:51PM -0400, Sven Van Asbroeck wrote:
> The tda988x i2c chip registers are accessed through a
> paged register scheme. The kernel regmap abstraction
> supports paged accesses. Replace this driver's
> dedicated i2c access functions with a standard i2c
> regmap.
>
> Pros
On 6/21/19 1:57 PM, Gerd Hoffmann wrote:
Aargh. Please don't do this. Multiple reasons:
1) I think It's bad to dump all buffer object functionality we can
possibly think of in a single struct and force that on all (well at
least most) users. It's better to isolate functionality in structs, h
Hi Dave,
The following changes since commit a188339ca5a396acc588e5851ed7e19f66b0ebd9:
Linux 5.2-rc1 (2019-05-19 15:47:09 -0700)
are available in the Git repository at:
git://anongit.freedesktop.org/tegra/linux tags/drm/tegra/for-5.3-rc1
for you to fetch changes up to eb7cf945a8dac8603e6d07
Hi Brendan,
On 6/19/19 7:17 PM, Frank Rowand wrote:
Hi Brendan,
I am only responding to this because you asked me to in the v4 thread.
Thank you for evaluating my comments in the v4 thread and asking me to
comment on v5
On 6/17/19 1:25 AM, Brendan Higgins wrote:
## TL;DR
A not so quick foll
On Fri, 21 Jun 2019 at 15:01, Yannick FERTRE wrote:
>
> Hi Emil,
>
> The msm driver tests the return value & set state to NULL if no error is
> detected.
>
> the ltdc driver tests the return value & force to suspend if an error is
> detected.
>
> It's not exactly the same.
>
D'oh I've misread that
On Thu, 2019-06-20 at 17:53 +0100, Robert Beckett wrote:
> On Thu, 2019-06-20 at 18:29 +0200, Daniel Vetter wrote:
> > On Thu, Jun 20, 2019 at 3:30 PM Robert Beckett
> > wrote:
> > > On Thu, 2019-06-20 at 14:32 +0200, Daniel Vetter wrote:
> > > > On Thu, Jun 20, 2019 at 12:12:13PM +0100, Robert Be
On Fri, Jun 21, 2019 at 1:15 PM Bartlomiej Zolnierkiewicz
wrote:
>
>
> On 6/17/19 2:47 PM, Arnd Bergmann wrote:
> > Building an allmodconfig kernel now produces a harmless warning:
> >
> > drivers/video/fbdev/pvr2fb.c:726:12: error: unused function
> > 'pvr2_get_param_val' [-Werror,-Wunused-funct
On 2019-06-05 1:06 p.m., Dingchen Zhang wrote:
> to terminate the while-loop in drm_dp_aux_crc_work when drm_dp_start/stop_crc
> are called in the hook to set crc source.
>
> Cc:Leo Li , Harry , Nick
>
> Signed-off-by: Dingchen Zhang
I wonder how this isn't creating problems for Rockchip with
Hi Fabio,
On Vi, 2019-06-21 at 11:00 -0300, Fabio Estevam wrote:
> Hi Robert,
>
> On Thu, Jun 20, 2019 at 10:32 AM Robert Chiras > wrote:
> >
> >
> > Add dt-bindings documentation for Raydium RM67191 DSI panel.
> >
> > Signed-off-by: Robert Chiras
> > Reviewed-by: Sam Ravnborg
> > ---
> >
Hi Emil,
The msm driver tests the return value & set state to NULL if no error is
detected.
the ltdc driver tests the return value & force to suspend if an error is
detected.
It's not exactly the same.
Best regards
--
Yannick Fertré | TINA: 166 7152 | Tel: +33 244027152 | Mobile: +33 62060
Hi Robert,
On Thu, Jun 20, 2019 at 10:32 AM Robert Chiras wrote:
>
> Add dt-bindings documentation for Raydium RM67191 DSI panel.
>
> Signed-off-by: Robert Chiras
> Reviewed-by: Sam Ravnborg
> ---
> .../bindings/display/panel/raydium,rm67191.txt | 39
> ++
> 1 file cha
Hi Robert,
On Thu, Jun 20, 2019 at 10:31 AM Robert Chiras wrote:
> +fail:
> + if (rad->reset)
> + gpiod_set_value_cansleep(rad->reset, 1);
gpiod_set_value_cansleep() can handle NULL, so no need for the if() check.
> +static const struct display_timing rad_default_timing = {
On Fri, Jun 21, 2019 at 01:41:45PM +0100, Daniel Thompson wrote:
> On 22/05/2019 17:34, Paul Cercueil wrote:
> > When the driver probes, the PWM pin is automatically configured to its
> > default state, which should be the "pwm" function.
>
> At which point in the probe... and by who?
The driver
On 21/06/2019 14:46, Daniel Thompson wrote:
[Sorry to those receiving this twice... had to dig this out from the
archives and sent it to the lists from the wrong mailer]
On 27/11/2018 00:44, Brian Dodge wrote:
Thank you Pavel, that is a good point.
The chip vendor has indicated that there is
One little comment on patch #8:
+ /* base.vma_node */
Is that really useful? I would just drop it.
Apart from that Patches #1, #2, #4, #5, #7 - #12, #14, #15, #18 are
Reviewed-by: Christian König .
Patches #3, #6, #13, #16, #17 are Acked-by: Christian König
.
You should try to get a
On Tue, Jun 18, 2019 at 05:53:24PM -0300, Mauro Carvalho Chehab wrote:
> Convert this small file to ReST in preparation for adding it to
> the driver-api book.
>
> While this is not part of the driver-api book, mark it as
> :orphan:, in order to avoid build warnings.
>
> Signed-off-by: Mauro Carv
[Sorry to those receiving this twice... had to dig this out from the
archives and sent it to the lists from the wrong mailer]
On 27/11/2018 00:44, Brian Dodge wrote:
Thank you Pavel, that is a good point.
The chip vendor has indicated that there is no reason to maintain the
old/improper prefi
Hi Brian
On Tue, 27 Nov 2018 at 00:44, Brian Dodge wrote:
> Thank you Pavel, that is a good point.
>
> The chip vendor has indicated that there is no reason to maintain the
> old/improper prefix and wishes to go forward (only) with the "arctic"
> prefix and any existing dts files are or will be
On 14/06/2019 21:36, Daniel Vetter wrote:
Basic helpers have been extracted, now there's a pile more todo still
across the entire tree.
Signed-off-by: Daniel Vetter
No disagreement here... so FWIW:
Reviewed-by: Daniel Thompson
Daniel.
---
Documentation/gpu/todo.rst | 27 +-
On 13/06/2019 20:43, Matthias Kaehlcke wrote:
Check if a brightness curve specified in the device tree is linear or
not and set the corresponding property accordingly. This makes the
scale type available to userspace via the 'scale' sysfs attribute.
To determine if a curve is linear it is compar
Hi,
On 4/30/18 9:59 PM, Aaro Koskinen wrote:
> Hi,
>
> On Mon, Apr 30, 2018 at 10:06:11AM +0300, Tomi Valkeinen wrote:
>> On 27/04/18 21:12, Aaro Koskinen wrote:
You should be targeting omapdrm driver instead, fbdev subsystem is closed
for the new hardware support.
>>>
>>> AFAIK, based
Am 21.06.19 um 14:47 schrieb Emil Velikov:
> On 2019/06/21, Koenig, Christian wrote:
>> Am 21.06.19 um 13:58 schrieb Emil Velikov:
>>> On 2019/06/21, Koenig, Christian wrote:
Am 21.06.19 um 12:53 schrieb Emil Velikov:
> On 2019/06/21, Koenig, Christian wrote:
>> [SNIP]
>> Well part
On 13/06/2019 20:43, Matthias Kaehlcke wrote:
For backlight curves calculated with the CIE 1931 algorithm set
the brightness scale type property accordingly. This makes the
scale type available to userspace via the 'scale' sysfs attribute.
Signed-off-by: Matthias Kaehlcke
I'd like to keep dis
On 2019/06/21, Koenig, Christian wrote:
> Am 21.06.19 um 13:58 schrieb Emil Velikov:
> > On 2019/06/21, Koenig, Christian wrote:
> >> Am 21.06.19 um 12:53 schrieb Emil Velikov:
> >>> On 2019/06/21, Koenig, Christian wrote:
> [SNIP]
> Well partially. That RADV broke is unfortunate, but we
1 - 100 of 183 matches
Mail list logo
