Note: I did read your response lower down in the thread, but I wanted to make
sure I addressed one of the comments here (see below)
On Thu, 2019-03-21 at 17:48 -0500, Bjorn Helgaas wrote:
> [+cc Rafael]
>
> On Wed, Mar 13, 2019 at 06:25:02PM -0400, Lyude Paul wrote:
> > On Fri, 2019-02-15 at 16:1
Dave Emett writes:
> On Wed, 13 Mar 2019 at 23:52, Eric Anholt wrote:
>>
>> We deref v3d->bin_job in the work handler, but v3d->bin_job doesn't
>> actually hold a ref on the job.
>>
>> Signed-off-by: Eric Anholt
> Reviewed-by: Dave Emett
>
>> ---
>> drivers/gpu/drm/v3d/v3d_irq.c | 3 ++-
>> 1
Dan Carpenter writes:
> The drm_gem_shmem_create() returns error pointers and v3d_bo_create() is
> also supposed to return error pointers.
>
> Fixes: 40609d4820b2 ("drm/v3d: Use the new shmem helpers to reduce driver
> boilerplate.")
> Signed-off-by: Dan Carpenter
Sigh, error pointers are the
Paul Kocialkowski writes:
> Hi,
>
> Le mercredi 06 février 2019 à 15:25 -0800, Eric Anholt a écrit :
>> The HW only executes a load once the tile coordinates packet happens,
>> and only tracks one at a time, so by emitting our two MSAA loads back
>> to back we would end up with an undefined color
On Fri, 2019-03-22 at 13:35 -0700, Anusha wrote:
> Straight copy from the kernel file.
>
> Add PCI IDs for CML, add additional PCI ID
> for ICL.
>
> Align with kernel commits:
>
> a7b4deeb02b97 ("drm/i915/cml: Add CML PCI IDS")
> 9a751b999d17a ("drm/i915: Add new ICL PCI ID")
>
> v2: Do a copy
Straight copy from the kernel file.
Add PCI IDs for CML, add additional PCI ID
for ICL.
Align with kernel commits:
a7b4deeb02b97 ("drm/i915/cml: Add CML PCI IDS")
9a751b999d17a ("drm/i915: Add new ICL PCI ID")
v2: Do a copy from kernel header (Jose)
- Change commit message (Lucas)
v3: Add corr
Add the capability to query information from a submit queue.
The first available parameter is for querying the number of GPU faults
(hangs) that can be attributed to the queue.
This is useful for implementing context robustness. A user context can
regularly query the number of faults to see if it
In VRR mode, proper vblank/pageflip timestamps can only be computed
after the display scanout position has left front-porch. Therefore
delay calls to drm_crtc_handle_vblank(), and thereby calls to
drm_update_vblank_count() and pageflip event delivery, to after the
end of front-porch when in VRR mod
The current patch series, with feedback from Paul, Nicholas and Harry
applied and r-b / acked-by tags added. Thanks for the feedback.
Rebased to current drm-5.2-wip branch.
Patch 1/4 is still the same though. Don't know if i or Nicholas could
fix it in a followup patch, or this one needs more work
During VRR mode we can not allow vblank irq dis-/enable
transitions, as an enable after a disable can happen at
an arbitrary time during the video refresh cycle, e.g.,
with a high likelyhood inside vblank front-porch. An
enable during front-porch would cause vblank timestamp
updates/calculations wh
We want vblank counts and timestamps of flip completion as sent
in pageflip completion events to be consistent with the vblank
count and timestamp of the vblank of flip completion, like in non
VRR mode.
In VRR mode, drm_update_vblank_count() - and thereby vblank
count and timestamp updates - must
For throttling to work correctly, we always need a baseline vblank
count last_flip_vblank that increments at start of front-porch.
This is the case for drm_crtc_vblank_count() in non-VRR mode, where
the vblank irq fires at start of front-porch and triggers DRM core
vblank handling, but it is no lo
https://bugs.freedesktop.org/show_bug.cgi?id=109955
--- Comment #3 from Mauro Gaspari ---
New reports as the issue is still happening:
I found a link on phoronix that describes with pictures exactly what is
happening:
https://www.phoronix.com/forums/forum/linux-graphics-x-org-drivers/open-source
https://bugs.freedesktop.org/show_bug.cgi?id=109955
--- Comment #2 from Mauro Gaspari ---
Created attachment 143760
--> https://bugs.freedesktop.org/attachment.cgi?id=143760&action=edit
full dmesg after crash
--
You are receiving this mail because:
You are the assignee for the bug.___
https://bugs.freedesktop.org/show_bug.cgi?id=109955
--- Comment #1 from Mauro Gaspari ---
Created attachment 143759
--> https://bugs.freedesktop.org/attachment.cgi?id=143759&action=edit
syslog lines relevant to the crash
--
You are receiving this mail because:
You are the assignee for the bug
On Fri, Mar 22, 2019 at 02:24:29PM -0400, Nicolas Dufresne wrote:
> Le jeudi 21 mars 2019 à 23:44 +0200, Ville Syrjälä a écrit :
> > On Thu, Mar 21, 2019 at 03:14:06PM -0400, Nicolas Dufresne wrote:
> > > Le jeudi 21 mars 2019 à 18:35 +0200, Ville Syrjälä a écrit :
> > > > > I'm not sure what it's
On Fri, 22 Mar 2019, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Looks like EDID_QUIRK_FIRST_DETAILED_PREFERRED never did anything.
> Its counterpart in f86EdidModes.c is properly hooked up but somehow
> that functionality was lost when it was copied into the kernel.
>
> The concensus seems to
From: Ville Syrjälä
Looks like EDID_QUIRK_FIRST_DETAILED_PREFERRED never did anything.
Its counterpart in f86EdidModes.c is properly hooked up but somehow
that functionality was lost when it was copied into the kernel.
The concensus seems to be that this quirk is a bit misguided
anyway so let's
https://bugs.freedesktop.org/show_bug.cgi?id=107731
--- Comment #11 from L.S.S. ---
So is there a possible workaround for monitors/KVMs that could cause this
issue? Sadly for 4-port DisplayPort KVMs with working 4K@60 there are very few
alternatives... most are either only DP 1.1 or only 4K@30.
https://bugs.freedesktop.org/show_bug.cgi?id=110225
Bug ID: 110225
Summary: Kernel panic while “ modprobe amdkfd ; modprobe -r
amdkfd " ; 4.14.35 kernel .
Product: DRI
Version: XOrg git
Hardware: Other
OS
https://bugs.freedesktop.org/show_bug.cgi?id=108824
--- Comment #3 from dnico...@gmail.com ---
I'm also finding the same problem with Blender 2.80. Sometimes it crashes
**very** often. Making it almost unusable.
Is there anyone who can take a look at this?
AMDGPU (Vega 56)
Kernel 4.20.15
Mesa 18
Hi,
On 3/20/2019 6:11 PM, Jani Nikula wrote:
On Wed, 20 Mar 2019, "Sharma, Swati2" wrote:
On 15-Mar-19 3:17 PM, Nikula, Jani wrote:
On Fri, 15 Mar 2019, swati2.sha...@intel.com wrote:
From: Swati Sharma
Added state checker to validate gamma_lut values. This
reads hardware state, and compa
Yeah, that should work.
Christian.
Am 22.03.19 um 08:34 schrieb zhoucm1:
how about the attached?
If ok, I will merge to pathc#1.
-David
On 2019年03月21日 22:40, Christian König wrote:
No, atomic cmpxchg is a hardware operation. If you want to replace
that you need a lock again.
Maybe just
https://bugs.freedesktop.org/show_bug.cgi?id=109693
--- Comment #2 from Kamil Páral ---
This issue seems to be causing crashes when playing Half-Life 2:
https://github.com/ValveSoftware/steam-for-linux/issues/6104#issuecomment-466681701
--
You are receiving this mail because:
You are the assign
Kernels are 5.0 and 5.1-rc1.
Is it just kernels 5.0 and 5.1? There haven't really been any display
related changes to radeon in ages. Possibly a duplicate of:
https://bugzilla.kernel.org/show_bug.cgi?id=198123
No, I just put the card in and tested with only the current kernels I had.
I can g
On Thu, Mar 21, 2019 at 03:14:06PM -0400, Nicolas Dufresne wrote:
> Le jeudi 21 mars 2019 à 18:35 +0200, Ville Syrjälä a écrit :
> > > I'm not sure what it's worth, but there is a "pixel format guide"
> > > project that is all about matching formats from one API to another:
> > > https://afrantzis
Hi Dave,
The following changes since commit 9e98c678c2d6ae3a17cb2de55d17f69dddaa231b:
Linux 5.1-rc1 (2019-03-17 14:22:26 -0700)
are available in the Git repository at:
git://anongit.freedesktop.org/tegra/linux tags/drm/tegra/for-5.1-rc2
for you to fetch changes up to 509869a2fec36ecb2b8411
On 22/03/2019 05:28, Andrey Smirnov wrote:
> According to the datasheet tc358767 can transfer up to 16 bytes via
> its AUX channel, so the artificial limit of 8 apperas to be too
> low. However only up to 15-bytes seem to be actually supported and
> trying to use 16-byte transfers results in transf
On Thu, Mar 21, 2019 at 05:48:19PM -0500, Bjorn Helgaas wrote:
> On Wed, Mar 13, 2019 at 06:25:02PM -0400, Lyude Paul wrote:
> > On Fri, 2019-02-15 at 16:17 -0500, Lyude Paul wrote:
> > > On Thu, 2019-02-14 at 18:43 -0600, Bjorn Helgaas wrote:
> > > > On Tue, Feb 12, 2019 at 05:02:30PM -0500, Lyude
https://bugs.freedesktop.org/show_bug.cgi?id=108898
--- Comment #3 from Eero Tamminen ---
(In reply to Eero Tamminen from comment #2)
> Hangs are still happening with the latest Mesa (43f40dc7cb234e) and drm-tip
> kernel (v5.0) git versions in Manhattan test offscreen versions.
Hangs still conti
Hi,
Le mercredi 06 février 2019 à 15:25 -0800, Eric Anholt a écrit :
> The HW only executes a load once the tile coordinates packet happens,
> and only tracks one at a time, so by emitting our two MSAA loads back
> to back we would end up with an undefined color or Z buffer.
This change deals wit
On 22/03/2019 05:28, Andrey Smirnov wrote:
> Simplify AUX data write by dropping index arithmetic and shifting and
> replacing it with a call to a helper function that does three things:
>
> 1. Copies user-provided data into a write buffer
> 2. Optionally fixes the endianness of the write
Hi,
Le mercredi 20 février 2019 à 13:03 -0800, Eric Anholt a écrit :
> This makes sure the vc4_reset doesn't hit an obscure race with the
> GET_PARAM ioctl, fixes a decrement outside of the lock, and prevents
> future code from making mistakes with the weird return value of
> pm_runtime_get_sync()
On Fri, Mar 22, 2019 at 10:47:00AM +0100, Thierry Reding wrote:
> On Thu, Mar 21, 2019 at 10:49:03AM +0100, Uwe Kleine-König wrote:
> > Hello,
> >
> > On Wed, Mar 20, 2019 at 01:01:26PM +, Leonard Crestez wrote:
> > > Commit d80f8206905c ("pwm: imx: Split into two drivers") also adds a new
> >
Hi,
Le mercredi 20 février 2019 à 13:03 -0800, Eric Anholt a écrit :
> Otherwise, you sometimes decode the ident fields based on 0xdeadbeef
> register reads.
Reviewed-by: Paul Kocialkowski
Cheers,
Paul
> Signed-off-by: Eric Anholt
> ---
> drivers/gpu/drm/vc4/vc4_v3d.c | 29 +
Hi,
Le mercredi 20 février 2019 à 13:03 -0800, Eric Anholt a écrit :
> Now I can extend the stats without more copy and pasting between the
> two.
Reviewed-by: Paul Kocialkowski
Cheers,
Paul
> Signed-off-by: Eric Anholt
> ---
> drivers/gpu/drm/vc4/vc4_bo.c | 48 +++--
Hi,
Le mercredi 20 février 2019 à 13:03 -0800, Eric Anholt a écrit :
> This removes a bunch of duplicated boilerplate for the debugfs vs
> runtime printk debug dumping.
This is:
Reviewed-by: Paul Kocialkowski
Cheers,
Paul
> Signed-off-by: Eric Anholt
> ---
> drivers/gpu/drm/vc4/vc4_crtc.c
Hi,
Le mercredi 20 février 2019 à 13:03 -0800, Eric Anholt a écrit :
> The debugfs_regset32 is nice to use for reducing boilerplate in
> dumping a bunch of regs in debugfs, but we also want to be able to
> print to dmesg them at runtime for driver debugging. drm_printer lets
> us format debugfs a
On 22/03/2019 05:28, Andrey Smirnov wrote:
> A very unfortunate aspect of tc_write()/tc_read() macro helpers is
> that they capture quite a bit of context around them and thus require
> the caller to have magic variables 'ret' and 'tc' as well as label
> 'err'. That makes a number of code paths rat
On 22/03/2019 05:28, Andrey Smirnov wrote:
> Simplify tc_set_video_mode() by replacing repreated calls to
> tc_write()/regmap_write() with a single call to
> regmap_multi_reg_write(). While at it, simplify explicit shifting by
> using macros from . No functional change intended.
>
> Signed-off-by:
On 22/03/2019 05:28, Andrey Smirnov wrote:
> Replace explicit polling in tc_link_training() with equivalent call to
> tc_poll_timeout() for simplicity. No functional change intended (not
> including slightly altered debug output).
>
> Signed-off-by: Andrey Smirnov
> Cc: Archit Taneja
> Cc: Andrz
On 22/03/2019 05:28, Andrey Smirnov wrote:
> Replace explicit polling loop with equivalent call to
> tc_poll_timeout() for brevity. No functional change intended.
>
> Signed-off-by: Andrey Smirnov
> Cc: Archit Taneja
> Cc: Andrzej Hajda
> Cc: Laurent Pinchart
> Cc: Tomi Valkeinen
> Cc: Andrey
On 22/03/2019 05:28, Andrey Smirnov wrote:
> Implementation of tc_poll_timeout() is almost a 100% copy-and-paste of
> the code for regmap_read_poll_timeout(). Replace copied code with a
> call to the original. While at it change tc_poll_timeout to accept
> "struct tc_data *" instead of "struct regm
On Thu, Mar 21, 2019 at 10:49:03AM +0100, Uwe Kleine-König wrote:
> Hello,
>
> On Wed, Mar 20, 2019 at 01:01:26PM +, Leonard Crestez wrote:
> > Commit d80f8206905c ("pwm: imx: Split into two drivers") also adds a new
> > CONFIG_PWM_IMX27 for the PWM block on recent IMX chips and we should
> >
> > - struct platform_device *pdev = to_platform_device(dev);
> > - struct msm_gpu *gpu = platform_get_drvdata(pdev);
> > + struct msm_gpu *gpu = dev_get_drvdata(dev);
>
> Nice simplification :-)
>
> Do you catch these with Coccinelle?
Yes, the previous series had the script in the cover
Add support for Three Five displays TFC S9700RTWV43TR-01B 800x480
panel with resistive touch found on TI's AM335X-EVM.
Signed-off-by: Jyri Sarha
---
drivers/gpu/drm/panel/panel-simple.c | 28
1 file changed, 28 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-
Changes since v6:
- Make power-supply a mandatory property
- Split binding to a separate patch
- Drop Tomi's reviewed-by, since the patch has changed quite a bit since his
review
Previous round:
https://patchwork.kernel.org/patch/10854851/
Jyri Sarha (2):
dt-bindings: drm/panel: simple: Add b
Add bindign for TFC S9700RTWV43TR-01B 7" Three Five Corp 800x480 LCD
panel with resistive touch.
The panel is found on TI AM335x-evm.
Signed-off-by: Jyri Sarha
---
.../display/panel/tfc,s9700rtwv43tr-01b.txt | 15 +++
.../devicetree/bindings/vendor-prefixes.txt | 1 +
2
Hi Wolfram,
Thank you for the patch,
On 19/03/2019 16:36, Wolfram Sang wrote:
> We should get 'driver_data' from 'struct device' directly. Going via
> platform_device is an unneeded step back and forth.
>
> Signed-off-by: Wolfram Sang
As with the other in this series, looks good to me.
Revie
Hi Wolfram,
Thank you for the patch,
On 19/03/2019 16:36, Wolfram Sang wrote:
> We should get 'driver_data' from 'struct device' directly. Going via
> platform_device is an unneeded step back and forth.
>
> Signed-off-by: Wolfram Sang
This looks good to me.
Reviewed-by: Kieran Bingham
> ---
The sii902x chip family supports also HDMI audio. Add binding for
describing the necessary i2s and mclk wiring for it.
Signed-off-by: Jyri Sarha
---
.../bindings/display/bridge/sii902x.txt | 33 +++
1 file changed, 33 insertions(+)
diff --git a/Documentation/devicetree/bin
Set output mode to HDMI or DVI according to EDID HDMI signature.
Signed-off-by: Jyri Sarha
Reviewed-by: Andrzej Hajda
Reviewed-by: Laurent Pinchart
---
drivers/gpu/drm/bridge/sii902x.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/bridge/sii902x.c b/drivers/gpu/d
Implement HDMI audio support by using ASoC HDMI codec. The commit
implements the necessary callbacks and configuration for the HDMI
codec and registers a virtual platform device for the codec to attach.
Signed-off-by: Jyri Sarha
---
drivers/gpu/drm/bridge/sii902x.c | 459
Remove trailing white space from sii902x display bridge binding.
Signed-off-by: Jyri Sarha
Reviewed-by: Laurent Pinchart
---
Documentation/devicetree/bindings/display/bridge/sii902x.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/display
From: Tomi Valkeinen
The driver always sets InputBusFmt:EDGE to 0 (falling edge).
Add drm_bridge_timings's input_bus_flags to reflect that the bridge
samples on falling edges.
Signed-off-by: Tomi Valkeinen
Signed-off-by: Jyri Sarha
Reviewed-by: Andrzej Hajda
Reviewed-by: Laurent Pinchart
--
Hi,
On 22/03/2019 05:28, Andrey Smirnov wrote:
> Everyone:
>
> This series contains various improvements (at least in my mind) and
> fixes that I made to tc358767 while working with the code of the
> driver. Hopefuly each patch is self explanatory.
>
> Feedback is welcome!
Ah, I hadn't realized
The pixel clock unit in the first two registers (0x00 and 0x01) of
sii9022 is 10kHz, not 1kHz as in struct drm_display_mode. Division by
10 fixes the issue.
Signed-off-by: Jyri Sarha
Reviewed-by: Andrzej Hajda
Reviewed-by: Laurent Pinchart
---
drivers/gpu/drm/bridge/sii902x.c | 5 +++--
1 file
The sil,i2s-data-lanes property is still under negotiation. The
question really is if there could be a generic audio i2s property to
handle that. alsa_devel added to the list of recipients.
Changes since v3:
- Change i2s-data-lanes to sil,i2s-data-lanes
The already reviewed patches are in front.
how about the attached?
If ok, I will merge to pathc#1.
-David
On 2019年03月21日 22:40, Christian König wrote:
No, atomic cmpxchg is a hardware operation. If you want to replace
that you need a lock again.
Maybe just add a comment and use an explicit cast to void* ? Not sure
if that silences
I decided to put a discrete graphics card into a PC and found a fitting Radeon
HD 7450.
It works, but there is strange whiteness like the brightness is oversaturated
and
light places turn into other colors:
* on fbcon, right after radeondrmfb initializes
* in X after powersave
The colors return
60 matches
Mail list logo