Refer to EDID 1.3 spec, display FEATURE (byte 18h) bit #0 said
"If this bit is set to 1, the display supports timings based on the
GTF standard using default GTF parameter values".
And EDID 1.4 spec shows "If bit 0 is set to 0, then the display
is noncontinuous frequency (multi-mode) and is only
On Sun 06 Oct 18:45 PDT 2019, Brian Masney wrote:
> pm8941 is missing the 5vs2 regulator node so let's add it since its
> needed to get the external display working. This regulator was already
> configured in the interrupts property on the parent node.
>
> Note that this regulator is referred to
Hi,
Me and Mat are working on this together, and I had a followup to
something Mat asked earlier.
On Thu, Oct 3, 2019 at 12:57 PM Mat King wrote:
>
> On Thu, Oct 3, 2019 at 2:59 AM Jani Nikula
> wrote:
> >
> > On Wed, 02 Oct 2019, Mat King wrote:
> > > On Wed, Oct 2, 2019 at 4:46 AM Jani
Hi Markus,
I agree with you, kmemdup may fail so a null check seems necessary there.
On Sun, Oct 6, 2019 at 4:33 AM Markus Elfring wrote:
>
> I have taken another look also at the implementation of the function
> “imx_pd_bind”.
>
On Fri, 04 Oct 2019, Jani Nikula wrote:
>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
From: Bartosz Golaszewski
Add a GPIO lookup entry and a device property for GPIO backlight to the
board file. Tie them to the platform device which is now registered using
platform_device_register_full() because of the properties. These changes
are inactive now but will be used once the gpio
From: Bartosz Golaszewski
While working on my other series related to gpio-backlight[1] I noticed
that we could simplify the driver if we made the only user of platform
data use GPIO lookups and device properties. This series tries to do
that.
The first patch adds all necessary data structures
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
Reviewed-by: Daniel Thompson
Reviewed-by: Andy Shevchenko
---
drivers/video/backlight/gpio_backlight.c | 1 -
1 file changed, 1
From: Bartosz Golaszewski
While working on my other series related to gpio-backlight[1] I noticed
that we could simplify the driver if we made the only user of platform
data use GPIO lookups and device properties. This series tries to do
that.
The first patch adds all necessary data structures
https://bugzilla.kernel.org/show_bug.cgi?id=205089
Alex Deucher (alexdeuc...@gmail.com) changed:
What|Removed |Added
CC|
Simplify the GEM object lookup code with DRM GEM helper
function drm_gem_objects_lookup_user().
v2:
use drm_gem_objects_lookup_user instead of
drm_gem_objects_lookup.
v3:
improve commit comemnt.
Cc: Eric Anholt
Reviewed-by: Steven Price
Signed-off-by: Qiang Yu
---
Simplify the driver code with DRM GEM helper function.
v2:
improve commit comment.
Signed-off-by: Qiang Yu
---
drivers/gpu/drm/lima/lima_gem.c | 64 -
1 file changed, 6 insertions(+), 58 deletions(-)
diff --git a/drivers/gpu/drm/lima/lima_gem.c
Do not need to maintain our own shmem memory management
code as drm_gem_shmem_helpers provides it. And we can
also benifit from the work of others with shared code.
This is also a preparation for implementing buffer madv.
Signed-off-by: Qiang Yu
---
drivers/gpu/drm/lima/Kconfig | 1
Use DRM GEM helper function drm_gem_objects_lookup() for
GEM object lookup at once instead of one by one with
drm_gem_object_lookup().
v2:
improve commit comment.
Signed-off-by: Qiang Yu
---
drivers/gpu/drm/lima/lima_drv.c | 5 ++-
drivers/gpu/drm/lima/lima_gem.c | 73
This prevent CMA printing dumy "PFNs busy" info which is
caused by alloc fail re-try case.
Signed-off-by: Qiang Yu
---
drivers/gpu/drm/lima/lima_device.c | 2 +-
drivers/gpu/drm/lima/lima_vm.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git
Change drm_gem_objects_lookup() to not use user space bo handles
directly and add a new interface drm_gem_objects_lookup_user()
for doing the original work.
This is for driver like lima which does not pass gem bo
handles continously in an array in ioctl argument.
v2:
1. add
By using shared drm helpers:
1. drm_gem_objects_lookup
2. drm_gem_(un)lock_reservations
3. drm_gem_shmem_helpers
we can simplify lima driver a lot and benifit from updates to
these functions.
drm_gem_objects_lookup need a refine in order to be used by lima.
Note:
1. changes to panfrost and v3d
Add support for the avdd33 regulator to the analogix-anx78xx driver.
Note that the regulator is currently enabled during driver probe and
disabled when the driver is removed. This is currently how the
downstream MSM kernel sources do this.
Let's not merge this upstream for the mean time until I
I am using an Analogix SP6001 SlimPort Micro-USB to 4K HDMI Adapter to
connect my Nexus 5 phone to an external display. The external display is
not fully working yet however I think I'm close. When I plug the cable
into the phone, the interrupt for the hot plug detect GPIO for the HDMI
bridge
Add HDMI tx and phy nodes to support an external display that can be
connected over the SlimPort. This is based on work from Jonathan Marek.
Signed-off-by: Brian Masney
Reviewed-by: Linus Walleij
---
Changes since v1:
- Add hdmi_pll to hdmi-phy node
- add power-domain to hdmi-phy per binding
pm8941 is missing the 5vs2 regulator node so let's add it since its
needed to get the external display working. This regulator was already
configured in the interrupts property on the parent node.
Note that this regulator is referred to as mvs2 in the downstream MSM
kernel sources.
Add HDMI nodes and other supporting infrastructure in order to support
the external display. This is based on work from Jonathan Marek.
Signed-off-by: Brian Masney
Reviewed-by: Linus Walleij
---
Changes since v1:
- Regulators always on as a temporary haack.
- Hot plug detect pin for the HDMI
Add msm8974 Phase-Locked Loop (PLL) support to the MSM HDMI so that an
external display can be used on this SoC.
Signed-off-by: Brian Masney
---
Changes since v1:
- New patch introduced in v2
drivers/gpu/drm/msm/Makefile | 1 +
drivers/gpu/drm/msm/hdmi/hdmi.h | 6 +
https://bugs.freedesktop.org/show_bug.cgi?id=111481
--- Comment #79 from Shmerl ---
Just got a freeze using Firefox even with Mesa master. So it's not fixed.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel
On Thu, 03 Oct 2019, Daniel Thompson wrote:
> I guess... although the Thinkpad code hasn't added any standard
> interfaces (no other laptop should be placing controls for a privacy
> screen in /proc/acpi/ibm/... ). Maybe its not too late.
As far as I am concerned, it is *not* too late. And you
https://bugs.freedesktop.org/show_bug.cgi?id=109628
--- Comment #27 from Mirek Kratochvil ---
Confirming the posted X driver workaround fixes it on 2700U. Debian 5.2.*
kernels and vanilla 5.3.1 work perfectly now.
Anyway, the latest X driver from git is broken as well. Should the issue be
https://bugs.freedesktop.org/show_bug.cgi?id=111481
--- Comment #78 from Shmerl ---
Trying now running Firefox with most recent Mesa master, to check if any fixes
in radeonsi prevent these hangs now or not.
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=109628
--- Comment #26 from Mirek Kratochvil ---
Hello everyone,
reporting the same on thinkpad E585; blackscreen issue is triggered by starting
X with compositor (lightdm works okay though).
Attaching my warning + backtrace + TEST_DEBUG_DATA from
https://bugs.freedesktop.org/show_bug.cgi?id=111481
--- Comment #77 from Shmerl ---
I suspect the above is OpenGL related bug in radeonsi.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
https://bugs.freedesktop.org/show_bug.cgi?id=111481
--- Comment #76 from Sebastian Meyer ---
Created attachment 145668
--> https://bugs.freedesktop.org/attachment.cgi?id=145668=edit
dump of the sdma0 ring after a timeout error
Just had another ring sdma0 timeout while being on the desktop and
https://bugs.freedesktop.org/show_bug.cgi?id=110886
--- Comment #26 from Kai-Heng Feng ---
Created attachment 145666
--> https://bugs.freedesktop.org/attachment.cgi?id=145666=edit
PSP failed with drm.debug=1
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=110886
--- Comment #27 from Kai-Heng Feng ---
Created attachment 145667
--> https://bugs.freedesktop.org/attachment.cgi?id=145667=edit
ring test failed with drm.debug=1
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=110886
--- Comment #25 from Kai-Heng Feng ---
(In reply to Andrey Grodzovsky from comment #24)
> (In reply to Kai-Heng Feng from comment #23)
> > Created attachment 145576 [details]
> > journalctl last boot kernel message
>
> Can u retry with latest
https://bugs.freedesktop.org/show_bug.cgi?id=111889
--- Comment #7 from sdico...@mail.ru ---
(In reply to Alex Deucher from comment #6)
> What component (mesa, kernel, etc.) did you change which caused the
> regression?
It is difficult to tell exactly. The regression developed during a series of
From: Andrey Smirnov
[ Upstream commit e0655feaec62d5139b6b13a7b1bbb1ab8f1c2d83 ]
According to the datasheet tc358767 can transfer up to 16 bytes via
its AUX channel, so the artificial limit of 8 appears to be too
low. However only up to 15-bytes seem to be actually supported and
trying to use
From: Andrey Smirnov
[ Upstream commit e0655feaec62d5139b6b13a7b1bbb1ab8f1c2d83 ]
According to the datasheet tc358767 can transfer up to 16 bytes via
its AUX channel, so the artificial limit of 8 appears to be too
low. However only up to 15-bytes seem to be actually supported and
trying to use
From: Andrey Smirnov
[ Upstream commit e0655feaec62d5139b6b13a7b1bbb1ab8f1c2d83 ]
According to the datasheet tc358767 can transfer up to 16 bytes via
its AUX channel, so the artificial limit of 8 appears to be too
low. However only up to 15-bytes seem to be actually supported and
trying to use
From: Andrey Smirnov
[ Upstream commit e0655feaec62d5139b6b13a7b1bbb1ab8f1c2d83 ]
According to the datasheet tc358767 can transfer up to 16 bytes via
its AUX channel, so the artificial limit of 8 appears to be too
low. However only up to 15-bytes seem to be actually supported and
trying to use
From: Andrey Smirnov
[ Upstream commit e0655feaec62d5139b6b13a7b1bbb1ab8f1c2d83 ]
According to the datasheet tc358767 can transfer up to 16 bytes via
its AUX channel, so the artificial limit of 8 appears to be too
low. However only up to 15-bytes seem to be actually supported and
trying to use
On Sun, Oct 6, 2019 at 9:55 AM Theodore Y. Ts'o wrote:
>
> Well, one thing we *can* do is if (a) if we can create a kselftest
> branch which we know is stable and won't change, and (b) we can get
> assurances that Linus *will* accept that branch during the next merge
> window, those subsystems
https://bugs.freedesktop.org/show_bug.cgi?id=110674
--- Comment #159 from ReddestDream ---
Oh. Also,
cat /sys/kernel/debug/dri/0/amdgpu_pm_info
Now seems to work on 5.3.4 with more than one monitor in. It doesn't report
nonsense values like 0 watts like it did before. :)
--
You are receiving
https://bugs.freedesktop.org/show_bug.cgi?id=110674
--- Comment #158 from ReddestDream ---
More good news. It seems that 5.3.4 does work for me and doesn't (at least
immediately since I'm typing this from there right now) fall apart into a
glitchy mess.
I'm still not really sure of the complete
On Fri, Oct 04, 2019 at 06:18:04PM -0700, Brendan Higgins wrote:
> > Let's talk about current state. Right now kunit is in linux-next and
> > we want to add a few more tests. We will have to coordinate the effort.
> > Once kunit get into mainline, then the need for this coordination goes
> > down.
> On 10/6/19, 7:04 AM, Pavel Machek wrote:
>
> Hi!
>
> > > >> I have been looking into adding Linux support for electronic privacy
> > > >> screens which is a feature on some new laptops which is built into the
> > > >> display and allows users to turn it on instead of needing to use a
> > > >>
https://bugs.freedesktop.org/show_bug.cgi?id=110674
--- Comment #157 from ReddestDream ---
@Tom B. Well, some good news. Kernel 5.3.4 should have the patches for Radeon
VII included now. I'll do some more tests on that ...
--
You are receiving this mail because:
You are the assignee for the
The packet length of DCS long write packet should not be added with 1
when constructing long write packet.
Fix this.
Signed-off-by: Icenowy Zheng
---
drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
The formula in the BSP kernel indicates that a 16-byte overhead is used
when sending the HFP. However, this value is currently set to 6 in the
sun6i_mipi_dsi driver, which makes some panels flashing.
Fix this overhead value.
Signed-off-by: Icenowy Zheng
---
From: Jagan Teki
The LCD timing definitions between Linux DRM vs Allwinner are different,
below diagram shows this clear differences.
Active Front Sync Back
Region Porch Porch
This patchset contains several fixes to the sun6i_mipi_dsi driver.
First, it's a rebased version of video start delay porch fix from Jagan
Teki.
The next patch fixes the overhead of HFP packet, according to the source
code of BSP [1].
The final patch fixes DCS long write, which fixes
On Wed, Oct 02, 2019 at 06:06:32PM +0200, Krzysztof Kozlowski wrote:
> The device node name should reflect generic class of a device so rename
> power domain nodes to "power-domain". No functional change.
>
> Signed-off-by: Krzysztof Kozlowski
> ---
> arch/arm/boot/dts/exynos4.dtsi| 14
在 2019-10-06日的 22:44 +0800，Icenowy Zheng写道：
> 在 2019-10-03四的 09:53 +0530，Jagan Teki写道：
> > Hi Wens,
> >
> > On Tue, Oct 1, 2019 at 1:34 PM Icenowy Zheng
> > wrote:
> > > This reverts commit 62e7511a4f4dcf07f753893d3424decd9466c98b.
> > >
> > > This commit, although claimed as a refactor, in
在 2019-10-03四的 09:53 +0530，Jagan Teki写道：
> Hi Wens,
>
> On Tue, Oct 1, 2019 at 1:34 PM Icenowy Zheng wrote:
> > This reverts commit 62e7511a4f4dcf07f753893d3424decd9466c98b.
> >
> > This commit, although claimed as a refactor, in fact changed the
> > formula.
> >
> > By expanding the original
https://bugs.freedesktop.org/show_bug.cgi?id=110674
--- Comment #156 from Tom B ---
This is strange because with a patched 5.3.1, I have perfect stability. An
uptime of over a week and no issues. Are you saying that the issue comes back
in 5.4? Hopefully not as Linux 5.4 + Mesa 19.3 looks to
https://bugzilla.kernel.org/show_bug.cgi?id=204611
--- Comment #6 from Carmen Bianca Bakker (car...@carmenbianca.eu) ---
Created attachment 285365
--> https://bugzilla.kernel.org/attachment.cgi?id=285365=edit
journalctl output on Thinkpad X395
--
You are receiving this mail because:
You are
https://bugzilla.kernel.org/show_bug.cgi?id=204611
Carmen Bianca Bakker (car...@carmenbianca.eu) changed:
What|Removed |Added
CC|
https://bugzilla.kernel.org/show_bug.cgi?id=205093
Marcin P (kat.zygf...@gmail.com) changed:
What|Removed |Added
Summary|[amdgpu] resume of IP block |[amdgpu] resume of IP
Hi!
> > >> I have been looking into adding Linux support for electronic privacy
> > >> screens which is a feature on some new laptops which is built into the
> > >> display and allows users to turn it on instead of needing to use a
> > >> physical privacy filter. In discussions with my colleagues
On Wed 2019-10-02 09:46:50, Jonathan Corbet wrote:
> On Tue, 1 Oct 2019 10:09:46 -0600
> Mat King wrote:
>
> > I have been looking into adding Linux support for electronic privacy
> > screens which is a feature on some new laptops which is built into the
> > display and allows users to turn it
On Tue 2019-10-01 10:09:46, Mat King wrote:
> Resending in plain text mode
>
> I have been looking into adding Linux support for electronic privacy
> screens which is a feature on some new laptops which is built into the
> display and allows users to turn it on instead of needing to use a
>
I have taken another look also at the implementation of the function
“imx_pd_bind”.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/imx/parallel-display.c?id=43b815c6a8e7dbccb5b8bd9c4b099c24bc22d135#n197
On Wed, Sep 11, 2019 at 07:40:35PM -0700, Guido Günther wrote:
> Temperature and hysteresis were picked after the CPU.
>
> Signed-off-by: Guido Günther
The patch prefix should be 'arm64: dts: ...'
I fixed it up and applied the patch.
Shawn
> ---
> arch/arm64/boot/dts/freescale/imx8mq.dtsi |
On Mon, Sep 16, 2019 at 04:32:55PM +0200, Lucas Stach wrote:
> On Mi, 2019-09-11 at 19:40 -0700, Guido Günther wrote:
> > Add #cooling-cells for when the gpu acts as a cooling device.
> >
> > Signed-off-by: Guido Günther
>
> Reviewed-by: Lucas Stach
Lucas,
I assume you will pick it up.
62 matches
Mail list logo
