Hi,
On Thu, Apr 25, 2019 at 4:27 AM Paulo Zanoni wrote:
>
> Em qua, 2019-04-24 às 20:58 +0100, Chris Wilson escreveu:
> > Quoting Jian-Hong Pan (2019-04-23 10:28:10)
> > > From: Daniel Drake
> > >
> > > On many (all?) the Gemini Lake systems we work
Hi,
Using libdrm-2.4.97, mesa fails to build on ARM with:
[ 456s] In file included from
../../../../../src/gallium/drivers/freedreno/freedreno_util.h:33,
[ 456s] from
../../../../../src/gallium/drivers/freedreno/freedreno_batch.h:34,
[ 456s] from
../../../../.
ne.
Signed-off-by: Chris Chiu
Signed-off-by: Daniel Drake
---
drivers/gpu/drm/nouveau/nvkm/engine/device/base.c | 29 +++
1 file changed, 29 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
b/drivers/gpu/drm/nouveau/nvkm/engine/device/base.
Hi,
Numerous Asus desktops and All-in-one computers (e.g. D520MT) have a
regression on Linux 4.9 where the VGA output is shown all-white.
This is a regression caused by:
commit 0ce140d45a8398b501934ac289aef0eb7f47c596
Author: Ville Syrjälä
Date: Tue Oct 11 20:52:47 2016 +0300
drm/i915: C
On Thu, May 4, 2017 at 2:37 PM, Ville Syrjälä
wrote:
> Please check if commit bb1d132935c2 ("drm/i915/vbt: split out defaults
> that are set when there is no VBT") fixes things for you.
I think this is not going to help. This would only make a difference
when there is no VBT at all at which point
Hi,
We are working with new laptops that have the AMD Bristol Ridge
chipset with this SoC:
AMD A10-9620P RADEON R5, 10 COMPUTE CORES 4C+6G
I think this is the Bristol Ridge chipset.
During boot, the display becomes unusable at the point where the
amdgpu driver loads. You can see at least two ho
On Fri, May 5, 2017 at 4:29 AM, Ville Syrjälä
wrote:
> On Thu, May 04, 2017 at 02:52:09PM -0600, Daniel Drake wrote:
>> On Thu, May 4, 2017 at 2:37 PM, Ville Syrjälä
>> wrote:
>> > Please check if commit bb1d132935c2 ("drm/i915/vbt: split out defaults
>>
On Fri, Jun 2, 2017 at 4:01 AM, Chris Chiu wrote:
> We are working with new desktop that have the NVIDIA NV118
> chipset.
>
> During boot, the display becomes unusable at the point where the
> nouveau driver loads. We have reproduced on 4.8, 4.11 and linux
> master (4.12-rc3).
To save digging int
Hi Maxime,
On Tue, May 26, 2020 at 6:20 PM Maxime Ripard wrote:
> I gave it a try with U-Boot with my latest work and couldn't reproduce it, so
> it
> seems that I fixed it along the way
Is your latest work available in a git branch anywhere that we could
test directly?
Thanks
Daniel
_
On Wed, May 27, 2020 at 5:13 PM Maxime Ripard wrote:
> I'm about to send a v3 today or tomorrow, I can Cc you (and Jian-Hong) if you
> want.
That would be great, although given the potentially inconsistent
results we've been seeing so far it would be great if you could
additionally push a git bra
,
but rather in the context of updating the plane, which also covers
flips. Like omapdrm we also unreference the old framebuffer here.
Signed-off-by: Daniel Drake
---
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 12 ++--
drivers/gpu/drm/exynos/exynos_drm_plane.c | 8
2 files
On Wed, Sep 17, 2014 at 1:44 AM, Joonyoung Shim
wrote:
> It's problem to add this from commit 25c8b5c3048cb6c98d402ca8d4735ccf910f727c.
My patch moves that drm_framebuffer_reference() call to the plane
function which is called from crtc_mode_set context (and also called
in crtc pageflip path), s
On Wed, Sep 17, 2014 at 7:45 AM, Daniel Vetter wrote:
> I think fb refcounting in exynos is just plain busted. If you look at
> other drivers the only place the refcount framebuffers or backing
> storage objects is for pageflips to make sure the memory doesn't go
> away while the hw is still scann
On Thu, Sep 18, 2014 at 12:39 AM, Daniel Vetter wrote:
> On Wed, Sep 17, 2014 at 6:41 PM, Daniel Drake wrote:
>> 2. drm_mode_rmfb then calls drm_framebuffer_remove, which calls
>> drm_mode_set_config_internal() in order to turn off the CRTC, dropping
>> another ref
On Fri, Sep 19, 2014 at 6:58 AM, Andrzej Hajda wrote:
> The patch replaces legacy functions
> drm_plane_init() / drm_crtc_init() with
> drm_universal_plane_init() and drm_crtc_init_with_planes().
> It allows to replace fake primary plane with the real one.
> Additionally the patch leaves cleanup o
Hi,
I recently filed a bug report regarding graphics corruption seen on
Gemini Lake platforms:
https://bugs.freedesktop.org/show_bug.cgi?id=108085
This has been reproduced on multiple distros on products from at least
4 vendors. It seems to apply to every GeminiLake product that we have
seen.
Th
Hi,
On Mon, Oct 8, 2018 at 1:48 PM Daniel Drake wrote:
> I recently filed a bug report regarding graphics corruption seen on
> Gemini Lake platforms:
> https://bugs.freedesktop.org/show_bug.cgi?id=108085
>
> This has been reproduced on multiple distros on products from at least
WHi Alex,
On Thu, Apr 19, 2018 at 4:13 PM, Alex Deucher wrote:
https://bugs.freedesktop.org/show_bug.cgi?id=105684
>>>
>>> No progress made on that bug report so far.
>>> What can we do to help this advance?
>>
>> Ping, any news here? How can we help advance on this bug?
>
> Can you try one
Hi,
Thanks a lot for this exynos-drm commit:
commit 62747fe0ad5169a767987d9009e3398466555cde
Author: Sean Paul
Date: Tue Jan 15 08:11:08 2013 -0500
drm/exynos: hdmi: support extra resolutions using drm_display_mode timings
As you probably know, many people had written off the Exynos4's
c
On Wed, Dec 4, 2013 at 12:14 PM, Sean Paul wrote:
> I assume this is the "1024x768 at 60Hz" mode in drm_edid.c?
>
> hdisplay = 1024
> hsync_start = 1048
> hsync_end = 1184
> htotal = 1344
> vdisplay = 768
> vsync_start = 771
> vsync_end = 777
> vtotal = 806
That's the one.
> I don't have any doc
On Thu, Dec 12, 2013 at 4:46 PM, Daniel Drake wrote:
> What I feel we are missing here is an explanation for why the first
> row of pixels is treated differently from the rest. Every value that I
> tweak seems to have an effect on the first line (which was rendered
> OK) as well as al
On Fri, Dec 13, 2013 at 9:46 AM, Daniel Drake wrote:
> Lets just accept the fact that the first line of the output image is
> rendered badly. Specifically, it has 257 black pixels added onto the
> end of it. The following rows do not exhibit that problem.
>
> To accept and ignore
Hi,
I'm using exynos_drm on Exynos4412 to output to a Sony HDMI TV.
When I disconnect and then re-plug the TV, Exynos detects this event
and tries to read the EDID from the DDC over I2C.
The DDC does not provide an ACK at this point, so the i2c-s3c2410
driver reports ENXIO, which seems to agree
Resend with correct addresses for Eugeni and Chris...
On Mon, Dec 16, 2013 at 3:47 PM, Daniel Drake wrote:
> Hi,
>
> I'm using exynos_drm on Exynos4412 to output to a Sony HDMI TV.
>
> When I disconnect and then re-plug the TV, Exynos detects this event
> and tries to rea
On Mon, Dec 16, 2013 at 4:19 PM, Daniel Vetter wrote:
> This usually happens if the hpd isn't properly recessed and we start
> the i2c transaction while the physical connection hasn't been
> established properly yet. If you're _really_ slow and careful you can
> probably even break your current de
On Mon, Dec 16, 2013 at 5:40 PM, Daniel Vetter wrote:
> Have a bit of logic in the exynos ->detect function to re-try a 2nd
> round of edid probing after each hdp interrupt if the first one
> returns an -ENXIO. Only tricky part is to be careful with edge
> detection so that userspace gets all the
On Wed, Dec 18, 2013 at 2:43 AM, Daniel Vetter wrote:
> I think we can do it simpler. When you get a hpd interrupt you eventually
> call drm_helper_hpd_irq_event which will update all the state and poke
> connectors. I'd just create a delay_work which you launch from
> hdmi_irq_thread with a 1 sec
On Wed, Dec 18, 2013 at 1:58 PM, Daniel Kurtz wrote:
> +seanpaul
>
> I think the problem is that the hdmi irq is really just an undebounced
> gpio interrupt, and thus, it is firing way too soon.
> The chromium kernel adds an excplicit 1.1 second timer to debounce hpd
> between the hdmi hpd-gpio ir
On Wed, Dec 18, 2013 at 2:18 PM, Daniel Drake wrote:
> Yes, this looks very similar to the approach I tried earlier. I guess
> the patch was written for the same reasons as well.
> Sean, any objections to me taking your patch and sending it upstream?
>
> http://git.chromiu
On Thu, Mar 22, 2018 at 3:09 AM, Daniel Drake wrote:
> On Tue, Feb 20, 2018 at 10:18 PM, Alex Deucher wrote:
>>> It seems that we are not alone seeing amdgpu-induced stability
>>> problems on multiple Raven Ridge platforms.
>>> https://www.phoronix.com/scan.php?pag
Hi Alex,
On Tue, Feb 20, 2018 at 10:18 PM, Alex Deucher wrote:
>> It seems that we are not alone seeing amdgpu-induced stability
>> problems on multiple Raven Ridge platforms.
>> https://www.phoronix.com/scan.php?page=news_item&px=AMD-Raven-Ridge-Mobo-Linux
>>
>> AMD, what can we do to help?
>
>
Hi,
> >>> We are working with new laptops that have the AMD Ravenl Ridge
> >>> chipset with this `/proc/cpuinfo`
> >>> https://gist.github.com/mschiu77/b06dba574e89b9a30cf4c450eaec49bc
> >>>
> >>> With the latest kernel 4.15, there're lots of different
> >>> panics/oops during boot so no c
Hi,
Thanks for the hard work on AMD DC development! Here are some new test
results - hope they are interesting/useful.
CONTEXT
We have been tracking DC for a while as we work with multiple products
where amdgpu previously was not able to support the HDMI audio output.
We are hoping to ship the
From: Yue Hin Lau
Signed-off-by: Yue Hin Lau
Reviewed-by: Eric Bernstein
Acked-by: Harry Wentland
Signed-off-by: Alex Deucher
[dr...@endlessm.com: backport to 4.15]
Signed-off-by: Daniel Drake
---
drivers/gpu/drm/amd/display/dc/dcn10/dcn10_dpp.h | 2 +-
drivers/gpu/drm/amd/display
Hi Russell,
Thanks a lot for writing the Armada DRM driver.
I have tested it on OLPC XO-1.75 (MMP2 aka Armada610) and OLPC XO-4 (MMP3
aka PXA2128). After a bit of fighting, I have it running. Could you share your
X driver, or your methodology for testing hardware cursors? I'd like to test
your wo
On Wed, Jun 26, 2013 at 10:42 AM, Jean-Francois Moine wrote:
> Do you know that there are 2 drm drivers for the Cubox? I posted mine
> (http://lists.infradead.org/pipermail/linux-arm-kernel/2013-May/168732.html)
> before Russell, but I got no return about it yet.
I thought there was some agreemen
Hi Russell,
Thanks for pointing me to the most recent version of your driver.
Can you comment on the below patch for improved clock handling?
It is based on the approach in Jean-Francois Moine's driver, and would
serve for the basis of having clock info come from the DT. If you have
something else
On Fri, Jun 28, 2013 at 3:27 PM, Russell King - ARM Linux
wrote:
> On Tue, Jun 25, 2013 at 04:47:26PM -0400, Daniel Drake wrote:
>> I have tested it on OLPC XO-1.75 (MMP2 aka Armada610) and OLPC XO-4 (MMP3
>> aka PXA2128). After a bit of fighting, I have it running. Could you shar
Hi,
Thanks for all the clear comments and explanations - I'll address all
of that in the next patch.
On Fri, Jun 28, 2013 at 3:18 PM, Russell King - ARM Linux
wrote:
> Sure... lets add some background info first: the big problem here is the
> completely different register layouts for the clock r
On Sat, Jun 29, 2013 at 1:26 PM, Russell King - ARM Linux
wrote:
> So, I'd suggest that an initial approach would be something along the
> lines of:
> - if there is an external clock, can it generate the desired rate?
> if yes, use it.
> - otherwise, get the clock rate from the internal clocks a
Hi Russell,
Here is a new patch which should incorporate all your previous feedback.
Now each variant passes clock info to the main driver via a new
armada_clk_info structure.
A helper function in the core lets each variant find the best clock.
As you suggested we first try external ("dedicated")
On Mon, Jul 1, 2013 at 3:48 PM, Sebastian Hesselbarth
wrote:
> I guess "extclk0" and "extclk1" should be sufficient for clock names.
> Also, they are not dedicated as you can have CRTC0 and CRTC1 use e.g.
> extclk0 simultaneously. See below for .is_dedicated in general.
Maybe we can find better t
Hi,
I'm looking into implementing devicetree support in armada_drm and
would like to better understand the best practice here.
Adding DT support for a DRM driver seems to be complicated by the fact
that DRM is not "hotpluggable" - it is not possible for the drm_device
to be initialised without an
On Tue, Jul 2, 2013 at 12:43 PM, Russell King wrote:
> I will point out that relying on driver probing orders has already been
> stated by driver model people to be unsafe. This is why I will not
> adopt such a solution for my driver; it is a bad design.
Just to clarify, what you're objecting to
On Tue, Jul 2, 2013 at 1:57 PM, Sebastian Hesselbarth
wrote:
> I am against a super node which contains lcd and dcon/ire nodes. You can
> enable those devices on a per board basis. We add them to dove.dtsi but
> disable them by default (status = "disabled").
>
> The DRM driver itself should get a
Hi,
Based on the outcomes of the "Best practice device tree design for display
subsystems" discussion I have drafted a DT binding. Comments much appreciated.
At a high level, it uses a "super node" as something for the driver to bind
to, needed because there is no clear one device that controls a
On Fri, Jul 12, 2013 at 12:39 PM, Jean-Francois Moine wrote:
> - I think it is better to keep the names 'lcd' for the memory to dumb panel
> sub-devices and 'dcon' for the dumb panel to LCD/VGA sub-device, as
> named in the spec.
I agree it is worth keeping the spec-defined names, if they do
On Sat, Jul 13, 2013 at 2:35 AM, Jean-Francois Moine wrote:
> I use my Cubox for daily jobs as a desktop computer. My kernel is a DT
> driven 3.10.0. The dove-drm, tda998x and si5351 (clock) are kernel
> modules. I set 3 clocks in the DT for the LCD0: lcdclk, axi and extclk0
> (si5351). Normally,
On Fri, Jul 12, 2013 at 10:44 AM, Daniel Drake wrote:
> Based on the outcomes of the "Best practice device tree design for display
> subsystems" discussion I have drafted a DT binding. Comments much appreciated.
>
> At a high level, it uses a "super node" as somet
On Mon, Jul 15, 2013 at 3:09 PM, Sascha Hauer wrote:
> You don't have to call drm_irq_install(). Both the exynos and i.MX
> driver do without it and at least the i.MX driver uses multiple irqs per
> drm_device.
Good point, thanks. That unblocks that item.
>> Secondly, devm. I understand from the
Hi Sean,
In your commit "drm/exynos: hdmi: support extra resolutions using
drm_display_mode timings" you added several more HDMI PHY configs to
exynos-drm. Thanks for that.
Can you explain where these magic numbers came from?
I'm interested in adding 85.5MHz for 1366x768 support.
Thanks,
Danie
that the underlying clock gating register has the
same value in both cases.
Anyway, the mixer clearly has some kind of dependency on the HDMI
component, so lets make sure we power that up first.
Signed-off-by: Daniel Drake
---
drivers/gpu/drm/exynos/exynos_drm_hdmi.c | 9 -
1 file ch
a digital world, ask the remote
display not to overscan by default.
Signed-off-by: Daniel Drake
---
drivers/video/hdmi.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
index 9e758a8..6c2d924 100644
--- a/drivers/video/hdmi.c
+++ b/drivers/video/
a digital world, ask the remote
display not to overscan by default.
Signed-off-by: Daniel Drake
---
drivers/gpu/drm/drm_edid.c | 1 +
1 file changed, 1 insertion(+)
Replaces the patch titled "video: hdmi: request underscan by default"
This version moves the change to the DRM layer, as
Hi Sean,
While looking at the following commit I noticed something:
commit f041b257a8997c8472a1013e9f252c3e2a1d879e
Author: Sean Paul
Date: Thu Jan 30 16:19:15 2014 -0500
drm/exynos: Remove exynos_drm_hdmi shim
This commit changes how mixer_check_mode() is used. It used to just
exclude
Hi Russell,
Here is a new patch which should incorporate all your previous feedback.
Now each variant passes clock info to the main driver via a new
armada_clk_info structure.
A helper function in the core lets each variant find the best clock.
As you suggested we first try external ("dedicated")
On Mon, Jul 1, 2013 at 3:48 PM, Sebastian Hesselbarth
wrote:
> I guess "extclk0" and "extclk1" should be sufficient for clock names.
> Also, they are not dedicated as you can have CRTC0 and CRTC1 use e.g.
> extclk0 simultaneously. See below for .is_dedicated in general.
Maybe we can find better t
Hi,
I'm looking into implementing devicetree support in armada_drm and
would like to better understand the best practice here.
Adding DT support for a DRM driver seems to be complicated by the fact
that DRM is not "hotpluggable" - it is not possible for the drm_device
to be initialised without an
On Tue, Jul 2, 2013 at 12:43 PM, Russell King wrote:
> I will point out that relying on driver probing orders has already been
> stated by driver model people to be unsafe. This is why I will not
> adopt such a solution for my driver; it is a bad design.
Just to clarify, what you're objecting to
On Tue, Jul 2, 2013 at 1:57 PM, Sebastian Hesselbarth
wrote:
> I am against a super node which contains lcd and dcon/ire nodes. You can
> enable those devices on a per board basis. We add them to dove.dtsi but
> disable them by default (status = "disabled").
>
> The DRM driver itself should get a
Hi,
Based on the outcomes of the "Best practice device tree design for display
subsystems" discussion I have drafted a DT binding. Comments much appreciated.
At a high level, it uses a "super node" as something for the driver to bind
to, needed because there is no clear one device that controls a
On Fri, Jul 12, 2013 at 12:39 PM, Jean-Francois Moine
wrote:
> - I think it is better to keep the names 'lcd' for the memory to dumb panel
> sub-devices and 'dcon' for the dumb panel to LCD/VGA sub-device, as
> named in the spec.
I agree it is worth keeping the spec-defined names, if they do
On Sat, Jul 13, 2013 at 2:35 AM, Jean-Francois Moine wrote:
> I use my Cubox for daily jobs as a desktop computer. My kernel is a DT
> driven 3.10.0. The dove-drm, tda998x and si5351 (clock) are kernel
> modules. I set 3 clocks in the DT for the LCD0: lcdclk, axi and extclk0
> (si5351). Normally,
On Fri, Jul 12, 2013 at 10:44 AM, Daniel Drake wrote:
> Based on the outcomes of the "Best practice device tree design for display
> subsystems" discussion I have drafted a DT binding. Comments much appreciated.
>
> At a high level, it uses a "super node" as somet
On Mon, Jul 15, 2013 at 3:09 PM, Sascha Hauer wrote:
> You don't have to call drm_irq_install(). Both the exynos and i.MX
> driver do without it and at least the i.MX driver uses multiple irqs per
> drm_device.
Good point, thanks. That unblocks that item.
>> Secondly, devm. I understand from the
Hi Russell,
Thanks a lot for writing the Armada DRM driver.
I have tested it on OLPC XO-1.75 (MMP2 aka Armada610) and OLPC XO-4 (MMP3
aka PXA2128). After a bit of fighting, I have it running. Could you share your
X driver, or your methodology for testing hardware cursors? I'd like to test
your wo
On Wed, Jun 26, 2013 at 10:42 AM, Jean-Francois Moine
wrote:
> Do you know that there are 2 drm drivers for the Cubox? I posted mine
> (http://lists.infradead.org/pipermail/linux-arm-kernel/2013-May/168732.html)
> before Russell, but I got no return about it yet.
I thought there was some agreeme
Hi Russell,
Thanks for pointing me to the most recent version of your driver.
Can you comment on the below patch for improved clock handling?
It is based on the approach in Jean-Francois Moine's driver, and would
serve for the basis of having clock info come from the DT. If you have
something else
On Fri, Jun 28, 2013 at 3:27 PM, Russell King - ARM Linux
wrote:
> On Tue, Jun 25, 2013 at 04:47:26PM -0400, Daniel Drake wrote:
>> I have tested it on OLPC XO-1.75 (MMP2 aka Armada610) and OLPC XO-4 (MMP3
>> aka PXA2128). After a bit of fighting, I have it running. Could you shar
Hi,
Thanks for all the clear comments and explanations - I'll address all
of that in the next patch.
On Fri, Jun 28, 2013 at 3:18 PM, Russell King - ARM Linux
wrote:
> Sure... lets add some background info first: the big problem here is the
> completely different register layouts for the clock r
On Sat, Jun 29, 2013 at 1:26 PM, Russell King - ARM Linux
wrote:
> So, I'd suggest that an initial approach would be something along the
> lines of:
> - if there is an external clock, can it generate the desired rate?
> if yes, use it.
> - otherwise, get the clock rate from the internal clocks a
71 matches
Mail list logo
