Hi Daniel, Gerd,
On Tue, Sep 17, 2019 at 10:23 PM Daniel Vetter wrote:
>
> On Thu, Sep 12, 2019 at 06:41:21PM +0900, Tomasz Figa wrote:
> > This patch is an early RFC to judge the direction we are following in
> > our virtualization efforts in Chrome OS. The purpose is to start a
> > discussion o
On Fri, Oct 4, 2019 at 5:49 PM shuah wrote:
>
> On 10/4/19 6:33 PM, Brendan Higgins wrote:
> > On Fri, Oct 4, 2019 at 4:57 PM shuah wrote:
> >>
> >> On 10/4/19 5:52 PM, Brendan Higgins wrote:
> >>> On Fri, Oct 4, 2019 at 4:30 PM Theodore Y. Ts'o wrote:
>
> On Fri, Oct 04, 2019 at 04:47
On 10/4/19 6:33 PM, Brendan Higgins wrote:
On Fri, Oct 4, 2019 at 4:57 PM shuah wrote:
On 10/4/19 5:52 PM, Brendan Higgins wrote:
On Fri, Oct 4, 2019 at 4:30 PM Theodore Y. Ts'o wrote:
On Fri, Oct 04, 2019 at 04:47:09PM -0600, shuah wrote:
However, if I encourage arbitrary tests/improveme
On Fri, Oct 4, 2019 at 4:57 PM shuah wrote:
>
> On 10/4/19 5:52 PM, Brendan Higgins wrote:
> > On Fri, Oct 4, 2019 at 4:30 PM Theodore Y. Ts'o wrote:
> >>
> >> On Fri, Oct 04, 2019 at 04:47:09PM -0600, shuah wrote:
> However, if I encourage arbitrary tests/improvements into my KUnit
> b
https://bugzilla.kernel.org/show_bug.cgi?id=204241
a...@tutanota.com changed:
What|Removed |Added
CC||a...@tutanota.com
--- Comment #14 fro
On 10/4/19 5:52 PM, Brendan Higgins wrote:
On Fri, Oct 4, 2019 at 4:30 PM Theodore Y. Ts'o wrote:
On Fri, Oct 04, 2019 at 04:47:09PM -0600, shuah wrote:
However, if I encourage arbitrary tests/improvements into my KUnit
branch, it further diverges away from torvalds/master, and is more
likely
On Fri, Oct 4, 2019 at 4:30 PM Theodore Y. Ts'o wrote:
>
> On Fri, Oct 04, 2019 at 04:47:09PM -0600, shuah wrote:
> > > However, if I encourage arbitrary tests/improvements into my KUnit
> > > branch, it further diverges away from torvalds/master, and is more
> > > likely that there will be a merg
On Fri, Oct 04, 2019 at 04:47:09PM -0600, shuah wrote:
> > However, if I encourage arbitrary tests/improvements into my KUnit
> > branch, it further diverges away from torvalds/master, and is more
> > likely that there will be a merge conflict or issue that is not related
> > to the core KUnit chan
On 10/4/19 5:10 PM, Brendan Higgins wrote:
On Fri, Oct 4, 2019 at 3:47 PM shuah wrote:
On 10/4/19 4:27 PM, Brendan Higgins wrote:
On Fri, Oct 04, 2019 at 03:59:10PM -0600, shuah wrote:
On 10/4/19 3:42 PM, Linus Torvalds wrote:
On Fri, Oct 4, 2019 at 2:39 PM Theodore Y. Ts'o wrote:
This q
On Fri, Oct 4, 2019 at 3:47 PM shuah wrote:
>
> On 10/4/19 4:27 PM, Brendan Higgins wrote:
> > On Fri, Oct 04, 2019 at 03:59:10PM -0600, shuah wrote:
> >> On 10/4/19 3:42 PM, Linus Torvalds wrote:
> >>> On Fri, Oct 4, 2019 at 2:39 PM Theodore Y. Ts'o wrote:
>
> This question is primaril
On 10/4/19 4:27 PM, Brendan Higgins wrote:
On Fri, Oct 04, 2019 at 03:59:10PM -0600, shuah wrote:
On 10/4/19 3:42 PM, Linus Torvalds wrote:
On Fri, Oct 4, 2019 at 2:39 PM Theodore Y. Ts'o wrote:
This question is primarily directed at Shuah and Linus
What's the current status of the kuni
On Fri, Oct 04, 2019 at 03:59:10PM -0600, shuah wrote:
> On 10/4/19 3:42 PM, Linus Torvalds wrote:
> > On Fri, Oct 4, 2019 at 2:39 PM Theodore Y. Ts'o wrote:
> > >
> > > This question is primarily directed at Shuah and Linus
> > >
> > > What's the current status of the kunit series now that
On Thu, Oct 3, 2019 at 5:15 PM Maxime Ripard wrote:
> > > > Fixes: 5fc537bfd000 ("drm/mcde: Add new driver for ST-Ericsson MCDE")
> > > > Signed-off-by: Jonathan Neuschäfer
> > >
> > > Both patches applied!
> >
> > ...but I can't push the changes:
> >
> > $ dim push-branch drm-misc-next
> > dim:
On 10/4/19 3:42 PM, Linus Torvalds wrote:
On Fri, Oct 4, 2019 at 2:39 PM Theodore Y. Ts'o wrote:
This question is primarily directed at Shuah and Linus
What's the current status of the kunit series now that Brendan has
moved it out of the top-level kunit directory as Linus has requested?
On 04/10/2019 20:27, Liviu Dudau wrote:
> On Fri, Oct 04, 2019 at 05:21:56PM +0100, Colin King wrote:
>> From: Colin Ian King
>>
>> The pointer disable_done is being initialized with a value that
>> is never read and is being re-assigned a little later on. The
>> assignment is redundant and hence
On Tue, Oct 1, 2019 at 2:59 PM Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski
>
> We no longer use any symbols from of_gpio.h. Remove this include.
>
> Signed-off-by: Bartosz Golaszewski
Reviewed-by: Linus Walleij
Thanks Bartosz,
Linus Walleij
On Tue, Oct 1, 2019 at 12:45 AM Dmitry Torokhov
wrote:
> So I guess we missed -rc1. Any chance we could get an immutable branch
> off -rc1 that you will pull into your main branch and I hopefully can
> persuade other maintainers to pull as well so we do not need to drag it
> over 2+ merge windows
On Fri, Oct 4, 2019 at 2:39 PM Theodore Y. Ts'o wrote:
>
> This question is primarily directed at Shuah and Linus
>
> What's the current status of the kunit series now that Brendan has
> moved it out of the top-level kunit directory as Linus has requested?
We seemed to decide to just wait for
https://bugs.freedesktop.org/show_bug.cgi?id=111481
--- Comment #72 from Marko Popovic ---
(In reply to Shmerl from comment #71)
> (In reply to Marko Popovic from comment #70)
> >
> > Yes, I can confirm that with 5.4 RC1 and MESA-git from 04.10. (with radv
> > patches included) I can reproduce a
On Mon, Sep 23, 2019 at 02:02:30AM -0700, Brendan Higgins wrote:
> ## TL;DR
>
> This revision addresses comments from Linus[1] and Randy[2], by moving
> top level `kunit/` directory to `lib/kunit/` and likewise moves top
> level Kconfig entry under lib/Kconfig.debug, so the KUnit submenu now
> sho
https://bugs.freedesktop.org/show_bug.cgi?id=111481
--- Comment #71 from Shmerl ---
(In reply to Marko Popovic from comment #70)
>
> Yes, I can confirm that with 5.4 RC1 and MESA-git from 04.10. (with radv
> patches included) I can reproduce all 4 types of hangs, random desktop hang,
> Rise of t
https://bugs.freedesktop.org/show_bug.cgi?id=111481
--- Comment #70 from Marko Popovic ---
(In reply to Shmerl from comment #69)
> I just tried recent kernel 5.4-rc1+ from here:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
>
> It supposedly already has fixes for amdgpu me
https://bugs.freedesktop.org/show_bug.cgi?id=111481
--- Comment #69 from Shmerl ---
I just tried recent kernel 5.4-rc1+ from here:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
It supposedly already has fixes for amdgpu metrics, in this commit:
https://git.kernel.org/pub/scm
Hi Jean,
On 10/3/19 10:28 AM, Jean-Jacques Hiblot wrote:
> If initialization data is available and its fwnode is actually a of_node,
> store this information in the led device's structure. This will allow the
> device to use or provide OF-based API such (devm_xxx).
>
> Signed-off-by: Jean-Jacques
Hi Lorrany,
Its great to hear that you are interested in VKMS project.
Is this your first time in the DRM subsystem or the Linux kernel? First of all,
welcome!
In order to improve your experience, we selected a set of tutorials that may
help you to get into the DRM subsystem:
1. This project is
On 10/4/19 7:42 PM, Mark Brown wrote:
> On Fri, Oct 04, 2019 at 06:12:52PM +0200, Jean-Jacques Hiblot wrote:
>> On 04/10/2019 17:58, Mark Brown wrote:
>
>>> Regulator supplies are supposed to be defined at the chip level rather
>>> than subfunctions with names corresponding to the names on the chi
On Fri, 04 Oct 2019, Michel Lespinasse wrote:
On Thu, Oct 03, 2019 at 01:18:54PM -0700, Davidlohr Bueso wrote:
@@ -1320,15 +1320,14 @@ static bool iotlb_access_ok(struct vhost_virtqueue *vq,
{
const struct vhost_umem_node *node;
struct vhost_umem *umem = vq->iotlb;
- u64
On Fri, 04 Oct 2019, Michel Lespinasse wrote:
On Thu, Oct 03, 2019 at 01:18:52PM -0700, Davidlohr Bueso wrote:
diff --git a/drivers/infiniband/hw/hfi1/mmu_rb.c
b/drivers/infiniband/hw/hfi1/mmu_rb.c
index 14d2a90964c3..fb6382b2d44e 100644
--- a/drivers/infiniband/hw/hfi1/mmu_rb.c
+++ b/drivers/
On Fri, 04 Oct 2019, Matthew Wilcox wrote:
On Fri, Oct 04, 2019 at 06:15:11AM -0700, Michel Lespinasse wrote:
My take is that this (Davidlohr's) patch series does not necessarily
need to be applied all at once - we could get the first change in
(adding the interval_tree_gen.h header), and conve
On Fri, Oct 04, 2019 at 08:08:26PM +0100, Eric Engestrom wrote:
> On Thursday, 2019-10-03 16:53:18 +0300, Ville Syrjälä wrote:
> > On Thu, Oct 03, 2019 at 09:51:18AM +0200, Andrzej Pietrasiewicz wrote:
> > > To human readers
> >
> > The commit message is always for human readers, no need to point
On Fri, Oct 04, 2019 at 05:21:56PM +0100, Colin King wrote:
> From: Colin Ian King
>
> The pointer disable_done is being initialized with a value that
> is never read and is being re-assigned a little later on. The
> assignment is redundant and hence can be removed.
Not really true, isn't it? Th
In imx_pd_bind, the duplicated memory for imxpd->edid via kmemdup should
be released in drm_of_find_panel_or_bridge or imx_pd_register fail.
Fixes: ebc944613567 ("drm: convert drivers to use drm_of_find_panel_or_bridge")
Fixes: 19022aaae677 ("staging: drm/imx: Add parallel display support")
Signed
On Thursday, 2019-10-03 16:53:18 +0300, Ville Syrjälä wrote:
> On Thu, Oct 03, 2019 at 09:51:18AM +0200, Andrzej Pietrasiewicz wrote:
> > To human readers
>
> The commit message is always for human readers, no need to point that
> out...
>
> >
> > "array of struct drm_format modifiers" is almost
https://bugs.freedesktop.org/show_bug.cgi?id=110886
--- Comment #24 from Andrey Grodzovsky ---
(In reply to Kai-Heng Feng from comment #23)
> Created attachment 145576 [details]
> journalctl last boot kernel message
Can u retry with latest FW from
https://git.kernel.org/pub/scm/linux/kernel/git/
On Fri, 04 Oct 2019, Adam Jackson wrote:
> On Sat, 2019-10-05 at 05:58 +0800, Lee Shawn C wrote:
>> This panel (manufacturer is SDC, product ID is 0x4141)
>> used manufacturer defined DPCD register to control brightness
>> that not defined in eDP spec so far. This change follow panel
>> vendor's i
https://bugs.freedesktop.org/show_bug.cgi?id=111729
--- Comment #8 from m...@cschwarz.com ---
There is a correspnding bug report on the Gentoo users forum:
https://forums.gentoo.org/viewtopic-p-8375988.html#8375988
--
You are receiving this mail because:
You are the assignee for the bug.___
https://bugs.freedesktop.org/show_bug.cgi?id=110994
--- Comment #8 from Kimmo ---
(In reply to Jason Playne from comment #2)
> This is has just started effecting me too. Playing "Hellblade: Senuas
> Sacrifice" on steam (so steam play / radv / dxvk)
>
> mesa via pkppa
>
> kernel 5.1.15-050115-ge
https://bugs.freedesktop.org/show_bug.cgi?id=111848
--- Comment #18 from m...@cschwarz.com ---
Bisection turns out to be harder than anticipated because there is another bug
that makes the system freeze on suspend (not reported yet).
Anyways, this seems to be a duplicate of
https://bugs.freedeskt
The pull request you sent on Fri, 4 Oct 2019 17:55:16 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2019-10-04
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/768b47b7a9bca52101ff48081cfcecd3ebc5351a
Thank you!
--
Deet-doot-dot, I am a bot.
https://ko
On Fri, Oct 04, 2019 at 06:15:11AM -0700, Michel Lespinasse wrote:
> Hi Jason,
>
> On Thu, Oct 3, 2019 at 5:26 PM Jason Gunthorpe wrote:
> > Hurm, this is not entirely accurate. Most users do actually want
> > overlapping and multiple ranges. I just studied this extensively:
>
> (Just curious, a
On Fri, Oct 04, 2019 at 06:12:52PM +0200, Jean-Jacques Hiblot wrote:
> On 04/10/2019 17:58, Mark Brown wrote:
> > Regulator supplies are supposed to be defined at the chip level rather
> > than subfunctions with names corresponding to the names on the chip.
...
> > good chance that they come up
Am 04.10.2019 18:02 schrieb Steven Price :
On 04/10/2019 16:34, Koenig, Christian wrote:
> Am 04.10.19 um 17:27 schrieb Steven Price:
>> On 04/10/2019 16:03, Neil Armstrong wrote:
>>> On 04/10/2019 16:53, Grodzovsky, Andrey wrote:
On 10/3/19 4:34 AM, Neil Armstrong wrote:
> Hi Andrey,
>>
From: Colin Ian King
The pointer disable_done is being initialized with a value that
is never read and is being re-assigned a little later on. The
assignment is redundant and hence can be removed.
Addresses-Coverity: ("Unused value")
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/arm/displa
On 04/10/2019 17:58, Mark Brown wrote:
On Fri, Oct 04, 2019 at 05:13:13PM +0200, Jean-Jacques Hiblot wrote:
On 04/10/2019 16:40, Mark Brown wrote:
Why is the LED core populating anything? Is the LED core copying bits
out of the struct device for the actual device into a synthetic device
rath
https://bugs.freedesktop.org/show_bug.cgi?id=111599
Chris Wilson changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
Quoting Chris Wilson (2019-10-04 15:08:57)
> Quoting Dan Carpenter (2019-10-04 11:22:51)
> > The "used" variables here come from the user in the ioctl and it can be
> > negative. It could result in an out of bounds write.
> >
> > Signed-off-by: Dan Carpenter
> > ---
> > drivers/gpu/drm/i810/i81
On Fri, Oct 04, 2019 at 06:15:11AM -0700, Michel Lespinasse wrote:
> My take is that this (Davidlohr's) patch series does not necessarily
> need to be applied all at once - we could get the first change in
> (adding the interval_tree_gen.h header), and convert the first few
> users, without getting
On 04/10/2019 16:34, Koenig, Christian wrote:
> Am 04.10.19 um 17:27 schrieb Steven Price:
>> On 04/10/2019 16:03, Neil Armstrong wrote:
>>> On 04/10/2019 16:53, Grodzovsky, Andrey wrote:
On 10/3/19 4:34 AM, Neil Armstrong wrote:
> Hi Andrey,
>
> Le 02/10/2019 à 16:40, Grodzovsky,
On Fri, Oct 04, 2019 at 05:13:13PM +0200, Jean-Jacques Hiblot wrote:
> On 04/10/2019 16:40, Mark Brown wrote:
> > Why is the LED core populating anything? Is the LED core copying bits
> > out of the struct device for the actual device into a synthetic device
> > rather than passing the actual dev
Hi Lee,
On 04/10/2019 16:39, Lee Jones wrote:
On Wed, 18 Sep 2019, Jean-Jacques Hiblot wrote:
From: Tomi Valkeinen
This patch adds a led-backlight driver (led_bl), which is similar to
pwm_bl except the driver uses a LED class driver to adjust the
brightness in the HW. Multiple LEDs can be us
Am 04.10.19 um 17:27 schrieb Steven Price:
> On 04/10/2019 16:03, Neil Armstrong wrote:
>> On 04/10/2019 16:53, Grodzovsky, Andrey wrote:
>>> On 10/3/19 4:34 AM, Neil Armstrong wrote:
Hi Andrey,
Le 02/10/2019 à 16:40, Grodzovsky, Andrey a écrit :
> On 9/30/19 10:52 AM, Hillf Dant
On 04/10/2019 16:03, Neil Armstrong wrote:
> On 04/10/2019 16:53, Grodzovsky, Andrey wrote:
>>
>> On 10/3/19 4:34 AM, Neil Armstrong wrote:
>>> Hi Andrey,
>>>
>>> Le 02/10/2019 à 16:40, Grodzovsky, Andrey a écrit :
On 9/30/19 10:52 AM, Hillf Danton wrote:
> On Mon, 30 Sep 2019 11:17:45 +02
On Sat, 2019-10-05 at 05:58 +0800, Lee Shawn C wrote:
> This panel (manufacturer is SDC, product ID is 0x4141)
> used manufacturer defined DPCD register to control brightness
> that not defined in eDP spec so far. This change follow panel
> vendor's instruction to support brightness adjustment.
I'
The clkoutN names of clocks must be unique because they represent
unique inputs of clock multiplexer.
Signed-off-by: Krzysztof Kozlowski
---
Documentation/devicetree/bindings/arm/samsung/pmu.yaml | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/b
Convert Samsung S3C/S5P/Exynos Serial/UART bindings to DT schema format
using json-schema.
Signed-off-by: Krzysztof Kozlowski
---
.../bindings/mfd/samsung,exynos5433-lpass.txt | 2 +-
.../bindings/serial/samsung_uart.txt | 58 ---
.../bindings/serial/samsung_uart.yaml | 1
Array elements under 'items' should be indented.
Signed-off-by: Krzysztof Kozlowski
---
Documentation/devicetree/bindings/gpu/samsung-rotator.yaml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/gpu/samsung-rotator.yaml
b/Documentation/devic
On 04/10/2019 16:40, Mark Brown wrote:
On Fri, Oct 04, 2019 at 03:33:13PM +0200, Jean-Jacques Hiblot wrote:
On 04/10/2019 13:39, Mark Brown wrote:
Consumers should just be able to request a regulator without having to
worry about how that's being provided - they should have no knowledge at
al
On Fri, Oct 4, 2019 at 11:08 AM Randy Dunlap wrote:
>
> On 10/3/19 10:59 PM, Stephen Rothwell wrote:
> > Hi all,
> >
> > Changes since 20191003:
> >
>
> on x86_64:
> CONFIG_DRM_AMDGPU=y
> # CONFIG_DRM_AMDGPU_SI is not set
> # CONFIG_DRM_AMDGPU_CIK is not set
> CONFIG_DRM_AMDGPU_USERPTR=y
> CONFIG_
On 04/10/2019 16:53, Grodzovsky, Andrey wrote:
>
> On 10/3/19 4:34 AM, Neil Armstrong wrote:
>> Hi Andrey,
>>
>> Le 02/10/2019 à 16:40, Grodzovsky, Andrey a écrit :
>>> On 9/30/19 10:52 AM, Hillf Danton wrote:
On Mon, 30 Sep 2019 11:17:45 +0200 Neil Armstrong wrote:
> Did a new run from 5
Adjust indentation from spaces to tab (+optional two spaces) as in
coding style with command like:
$ sed -e 's/^/\t/' -i */Kconfig
Signed-off-by: Krzysztof Kozlowski
---
arch/Kconfig | 4 ++--
arch/alpha/Kconfig | 2 +-
arch/arm/Kconfig
Adjust indentation from spaces to tab (+optional two spaces) as in
coding style with command like:
$ sed -e 's/^/\t/' -i */Kconfig
Signed-off-by: Krzysztof Kozlowski
---
certs/Kconfig | 14 ++---
init/Kconfig | 28 +-
On 10/3/19 4:34 AM, Neil Armstrong wrote:
> Hi Andrey,
>
> Le 02/10/2019 à 16:40, Grodzovsky, Andrey a écrit :
>> On 9/30/19 10:52 AM, Hillf Danton wrote:
>>> On Mon, 30 Sep 2019 11:17:45 +0200 Neil Armstrong wrote:
Did a new run from 5.3:
[ 35.971972] Call trace:
[ 35.9743
Adjust indentation from spaces to tab (+optional two spaces) as in
coding style with command like:
$ sed -e 's/^/\t/' -i */Kconfig
Signed-off-by: Krzysztof Kozlowski
---
Changes since v1:
1. Fix also DRM_AMD_DC_HDCP (new arrival since v1).
---
drivers/gpu/drm/Kconfig
devm_regulator_get() is used to populate pfdev->regulator which ensures
that this cannot be NULL (a dummy regulator will be returned if
necessary). So remove the check in panfrost_devfreq_target().
Signed-off-by: Steven Price
---
This looks like it was accidentally reintroduced by the merge from
On Fri, Oct 04, 2019 at 03:33:13PM +0200, Jean-Jacques Hiblot wrote:
> On 04/10/2019 13:39, Mark Brown wrote:
> > Consumers should just be able to request a regulator without having to
> > worry about how that's being provided - they should have no knowledge at
> > all of firmware bindings or plat
On Wed, 18 Sep 2019, Jean-Jacques Hiblot wrote:
> From: Tomi Valkeinen
>
> This patch adds a led-backlight driver (led_bl), which is similar to
> pwm_bl except the driver uses a LED class driver to adjust the
> brightness in the HW. Multiple LEDs can be used for a single backlight.
>
> Signed-o
On Wed, 18 Sep 2019, Jean-Jacques Hiblot wrote:
> Add DT binding for led-backlight.
>
> Signed-off-by: Jean-Jacques Hiblot
> Reviewed-by: Daniel Thompson
> ---
> .../bindings/leds/backlight/led-backlight.txt | 28 +++
> 1 file changed, 28 insertions(+)
> create mode 100644
>
Some fields of komeda_drv members will be useful very early
in probe code, so make sure an instance is available.
Signed-off-by: Mihail Atanassov
---
.../gpu/drm/arm/display/komeda/komeda_drv.c | 30 +++
1 file changed, 17 insertions(+), 13 deletions(-)
diff --git a/drivers/gp
struct komeda_drv has two pointer members only, and both
it and its members get allocated separately. Since both
members' types are in scope, there's not a lot to gain by
keeping the indirection around.
To avoid double-free issues, provide a barebones ->release()
hook for the driver.
Signed-off-b
Greetings,
This series attempts to add support for endpoints (in the DT sense)
whose drivers only have a drm_bridge interface, unlike the tda998x,
which uses the component framework and provides all of drm_encoder,
drm_bridge, drm_connector.
1 & 2 should be fairly non-contentious, and I believe a
To support transmitters other than the tda998x, we need to allow
non-component framework bridges to be attached to a dummy drm_encoder in
our driver.
For the existing supported encoder (tda998x), keep the behaviour as-is,
since there's no way to unbind if a drm_bridge module goes away under
our fe
On Fri, Oct 04, 2019 at 02:12:38PM +, Ayan Halder wrote:
> From: Raymond Smith
>
> 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.
>
> Changes from v1:-
> 1. Reserved the upper four bits (ou
On Fri, Oct 04, 2019 at 10:41:20AM +, Lin, Wayne wrote:
>
>
>
> From: Ville Syrjälä
> Sent: Thursday, October 3, 2019 21:29
> To: Lin, Wayne
> Cc: dri-devel@lists.freedesktop.org ;
> amd-...@lists.freedesktop.org ; Li, Sun peng
> (Leo) ; Kazlauskas, Nichol
From: Ville Syrjälä
drm_get_cea_aspect_ratio() is not used outside drm_edid.c.
Make it static.
Cc: Wayne Lin
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_edid.c | 10 +-
include/drm/drm_edid.h | 1 -
2 files changed, 1 insertion(+), 10 deletions(-)
diff --git a/drivers/g
From: Ville Syrjälä
Extract drm_mode_hdmi_vic() to correctly calculate the final HDMI
VIC for us. Currently this is being done a bit differently between
the AVI and HDMI infoframes. Let's get both to agree on this.
We need to allow the case where a mode is both 3D and has a HDMI
VIC. Currently w
From: Ville Syrjälä
Extract the logic to compute the final CEA VIC to a small helper.
We'll reorder it a bit to make future modifications more
straightforward. No function changes.
Cc: Wayne Lin
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_edid.c | 53 +
From: Ville Syrjälä
I think this should provide most of necessary logic for
adding aspecr ratios to the HDMI 4k modes.
Cc: Wayne Lin
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_edid.c | 37 +++--
1 file changed, 31 insertions(+), 6 deletions(-)
diff -
Hi guys,
I'm Lorrany Azevedo, and I'm participating in the application phase for the
outreachy internships. I'm interested in making a contribution to VKMS, and
I would like to ask for tips on how I can do this, I'm new to the
community and I never made any contribution to the FOSS.
_
From: Raymond Smith
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.
Changes from v1:-
1. Reserved the upper four bits (out of the 56 bits assigned to each vendor)
to denote the category of Arm speci
Quoting Dan Carpenter (2019-10-04 11:22:51)
> The "used" variables here come from the user in the ioctl and it can be
> negative. It could result in an out of bounds write.
>
> Signed-off-by: Dan Carpenter
> ---
> drivers/gpu/drm/i810/i810_dma.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 de
Hi Bogdan,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[cannot apply to v5.4-rc1 next-20191004]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base'
This panel (manufacturer is SDC, product ID is 0x4141)
used manufacturer defined DPCD register to control brightness
that not defined in eDP spec so far. This change follow panel
vendor's instruction to support brightness adjustment.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97883
Cc
On Wed, Oct 2, 2019 at 5:45 PM syzbot
wrote:
>
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:a32db7e1 Add linux-next specific files for 20191002
> git tree: linux-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=175ab7cd60
> kernel config: https:/
https://bugs.freedesktop.org/show_bug.cgi?id=111244
--- Comment #33 from Andrey Grodzovsky ---
OOO today
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.
https://bugs.freedesktop.org/show_bug.cgi?id=111244
--- Comment #32 from mib...@gmx.at ---
Cannot reproduce it anymore as of 5.4rc1, seems like it's fixed for me!
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel ma
https://bugs.freedesktop.org/show_bug.cgi?id=111729
--- Comment #7 from m...@cschwarz.com ---
I began bisecting yesterday and discovered another bug that happens on suspend,
which makes it hard to determine the good/bad status of a build with regards to
_this_ bug in a timely manner.
Hence abortin
On 04/10/2019 13:39, Mark Brown wrote:
On Thu, Oct 03, 2019 at 10:27:26PM +0200, Jacek Anaszewski wrote:
On 10/3/19 9:41 PM, Mark Brown wrote:
Why would we want to do that? We'd continue to support only DT systems,
just with code that's less obviously DT only and would need to put
checks in.
Hi Jason,
On Thu, Oct 3, 2019 at 5:26 PM Jason Gunthorpe wrote:
> Hurm, this is not entirely accurate. Most users do actually want
> overlapping and multiple ranges. I just studied this extensively:
(Just curious, are you the person we discussed this with after the
Maple Tree talk at LPC 2019 ?)
On Fri, Oct 04, 2019 at 12:36:56PM +, Benjamin GAIGNARD wrote:
>
> On 10/4/19 2:27 PM, Ville Syrjälä wrote:
> > On Fri, Oct 04, 2019 at 12:48:02PM +0200, Benjamin Gaignard wrote:
> >> Le jeu. 3 oct. 2019 à 17:46, Ville Syrjälä
> >> a écrit :
> >>> On Thu, Oct 03, 2019 at 05:37:15PM +0200, Ben
On Fri, Oct 4, 2019 at 3:29 AM Koenig, Christian
wrote:
>
> Am 03.10.19 um 23:40 schrieb Colin King:
> > From: Colin Ian King
> >
> > There is a return statement that is not reachable and a variable that
> > is not used. Remove them.
> >
> > Addresses-Coverity: ("Structurally dead code")
> > Fix
On Fri, Oct 04, 2019 at 01:04:24PM +0200, Hans Verkuil wrote:
> It is possible for one HDMI connector to have multiple CEC adapters. The
> typical real-world scenario is that where one adapter is used when the device
> is in standby, and one that's better/smarter when the device is powered up.
>
>
On Fri, Oct 4, 2019 at 3:28 AM Koenig, Christian
wrote:
>
> Am 03.10.19 um 23:52 schrieb Colin King:
> > From: Colin Ian King
> >
> > The boolean variable pasid_mapping_needed is not initialized and
> > there are code paths that do not assign it any value before it is
> > is read later. Fix this
On Fri, Oct 4, 2019 at 8:25 AM zhengbin wrote:
>
> Fix sparse warnings:
>
> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_hdcp.c:32:6:
> warning: symbol 'lp_write_i2c' was not declared. Should it be static?
> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_hdcp.c:42:6:
> wa
On Thu, Oct 3, 2019 at 4:35 PM Raul E Rangel wrote:
>
> dcn20_resource.c:2636:9: error: missing braces around initializer
> [-Werror=missing-braces]
> struct _vcs_dpi_voltage_scaling_st
> calculated_states[MAX_CLOCK_LIMIT_STATES] = {0};
> ^
>
> Fixes: 7ed4e6352c16f ("drm/amd/display:
On Thu, Oct 03, 2019 at 01:32:50PM -0700, Matthew Wilcox wrote:
> On Thu, Oct 03, 2019 at 01:18:47PM -0700, Davidlohr Bueso wrote:
> > It has been discussed[1,2] that almost all users of interval trees would
> > better
> > be served if the intervals were actually not [a,b], but instead [a, b). Thi
https://bugs.freedesktop.org/show_bug.cgi?id=110674
--- Comment #155 from ReddestDream ---
So, I've done some tests with 5.4-rc1 and it seems like I'm getting similar
results to line...@xcpp.org and sehell...@gmail.com. I'm using GNOME with
Wayland (which works fine with only 1 display). Sometime
Hi Michel,
Am 04.10.19 um 13:36 schrieb Michel Lespinasse:
On Fri, Oct 04, 2019 at 06:54:54AM +, Koenig, Christian wrote:
Am 03.10.19 um 22:18 schrieb Davidlohr Bueso:
The amdgpu_vm interval tree really wants [a, b) intervals,
NAK, we explicitly do need an [a, b[ interval here.
Hi Christ
On 10/4/19 2:27 PM, Ville Syrjälä wrote:
> On Fri, Oct 04, 2019 at 12:48:02PM +0200, Benjamin Gaignard wrote:
>> Le jeu. 3 oct. 2019 à 17:46, Ville Syrjälä
>> a écrit :
>>> On Thu, Oct 03, 2019 at 05:37:15PM +0200, Benjamin Gaignard wrote:
Le jeu. 3 oct. 2019 à 17:05, Ville Syrjälä
a é
On Thu, Oct 3, 2019 at 10:13 PM Huacai Chen wrote:
>
> In previous release amdgpu_pmu.o is only built when CONFIG_PERF_EVENTS
> is selected. But after commit 64f55e629237e4752db1 ("drm/amdgpu: Add RAS
> EEPROM table.") it is duplicated in amdgpu-y. This change causes a build
> error when !CONFIG_P
On Fri, Oct 04, 2019 at 12:48:02PM +0200, Benjamin Gaignard wrote:
> Le jeu. 3 oct. 2019 à 17:46, Ville Syrjälä
> a écrit :
> >
> > On Thu, Oct 03, 2019 at 05:37:15PM +0200, Benjamin Gaignard wrote:
> > > Le jeu. 3 oct. 2019 à 17:05, Ville Syrjälä
> > > a écrit :
> > > >
> > > > On Thu, Oct 03, 2
1 - 100 of 161 matches
Mail list logo
