https://bugs.freedesktop.org/show_bug.cgi?id=111622
Bug ID: 111622
Summary: VAAPI vaDeriveImage returns
VA_STATUS_ERROR_OPERATION_FAILED
Product: Mesa
Version: 19.1
Hardware: x86-64 (AMD64)
OS: Linux (All)
I've pushed this patch to drm-misc-fixes:
https://cgit.freedesktop.org/drm/drm-misc/commit/?h=drm-misc-fixes=21670bd78a25001cf8ef2679b378c73fb73b904f
There is a conflict when drm-tip merge process which has been solved
by following the doc:
Thanks Heiko, I'll push this patch to drm-misc-fixes.
I can add the Fixes tag before push.
Thanks,
Qiang
On Tue, Sep 10, 2019 at 12:23 AM Vasily Khoruzhick wrote:
>
> On Mon, Sep 9, 2019 at 5:18 AM Heiko Stübner wrote:
> >
> > Hi Qiang,
> >
> > Am Montag, 9. September 2019, 04:30:43 CEST
https://bugs.freedesktop.org/show_bug.cgi?id=111591
--- Comment #4 from Shmerl ---
Uploaded the trace here (should be valid for 30 days):
https://ufile.io/kvf9t1eu
Sorry for huge size, there is an unskippable cutscene in the beginning.
Compressed with pixz, so should be decompressible using
This change adds definitions required for Link Training-tunable PHY
Repeater, which was introduced in the DP 1.3 specification, and
incremented with new features in the DP 1.4*.
Changes since V4:
- Update commit message
- Fix misleading comments related to the spec version
Changes since V3:
-
Please, ignore this patch.
I just noticed that I sent the wrong version. I resend the correct patch
with the title:
[PATCH V5] drm: Add definitions for link training repeaters
Sorry for this mistake.
On 09/09, Siqueira, Rodrigo wrote:
> DP 1.3 specification introduces the Link Training-tunable
https://bugs.freedesktop.org/show_bug.cgi?id=111591
--- Comment #3 from Shmerl ---
Is there any way to postpone tracing kick in, to avoid massive size of the
file?
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel
On Solaris, sys/sysmacros.h has long-deprecated copies of major() & minor()
but not makedev(). sys/mkdev.h has all three and is the preferred choice.
So we check for sys/mkdev.h first, as autoconf's AC_HEADER_MAJOR does.
Fixes build failure with error:
../xf86drm.c: In function ‘drmOpenMinor’:
https://bugs.freedesktop.org/show_bug.cgi?id=111591
--- Comment #2 from Shmerl ---
I'll try to make a trace. The error message looks like this one:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c?h=v5.3-rc8#n5703
--
You
Hi Arnd,
Thank you for the patch.
On Mon, Sep 09, 2019 at 10:33:57PM +0200, Arnd Bergmann wrote:
> This was apparently dropped by accident in a recent
> cleanup, causing a build failure in some configurations now:
>
> drivers/gpu/drm/tilcdc/tilcdc_tfp410.c:296:12: error: implicit declaration of
DP 1.3 specification introduces the Link Training-tunable PHY Repeater,
and DP 1.4* supplemented it with new features. In the 1.4a spec, it was
introduced some innovations to make handy to add support for systems
with Thunderbolt or other repeater devices.
It is important to highlight that DP
On Thu, Sep 5, 2019 at 5:26 PM Rafael J. Wysocki wrote:
>
> On Thursday, September 5, 2019 5:51:23 PM CEST Karol Herbst wrote:
> > is there any update on the testing with my patches? On the hardware I
> > had access to those patches helped, but I can't know if it also helped
> > on the hardware
This was apparently dropped by accident in a recent
cleanup, causing a build failure in some configurations now:
drivers/gpu/drm/tilcdc/tilcdc_tfp410.c:296:12: error: implicit declaration of
function 'devm_pinctrl_get_select_default'
[-Werror,-Wimplicit-function-declaration]
Fixes:
On Mon, 9 Sep 2019 11:57:29 +0100
Daniel Thompson wrote:
> On Sun, Sep 08, 2019 at 10:37:03PM +0200, Andreas Kemnade wrote:
> > For now just enable it in the probe function to allow i2c
> > access and disable it on remove. Disabling also means resetting
> > the register values to default.
> >
>
https://bugs.freedesktop.org/show_bug.cgi?id=111527
--- Comment #4 from tele4...@hotmail.com ---
I reproduced the issue with 7d28e9ddd62eeccf6c528beee6b1a58fdfb7f5a0 + merge
request 1907. No visible effect.
--
You are receiving this mail because:
You are the assignee for the
Finally got a chance to look at this again, some notes below
On Wed, 2019-08-21 at 14:53 +0300, Ville Syrjälä wrote:
> On Tue, Aug 20, 2019 at 08:16:55PM -0400, Lyude Paul wrote:
> > Assuming that GPUs would never have even close to 32 separate video
> > encoders is quite honestly a pretty
https://bugs.freedesktop.org/show_bug.cgi?id=111487
--- Comment #6 from bzz ---
New kernel, problem still here:
[ 242.669782] WARNING: CPU: 2 PID: 183 at
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_hw_sequencer.c:854
dcn10_verify_allow_pstate_change_high.cold+0xc/0x229 [amdgpu]
[
https://bugs.freedesktop.org/show_bug.cgi?id=110659
tempel.jul...@gmail.com changed:
What|Removed |Added
Resolution|--- |NOTOURBUG
https://bugs.freedesktop.org/show_bug.cgi?id=111077
--- Comment #31 from Matt Turner ---
(In reply to rol...@rptd.ch from comment #30)
> How I best test this? Just check out the branch and build it or apply it
> somehow to the mesa branch I have here from bisecting?
wget
On Thu, Sep 5, 2019 at 10:18 PM Gerd Hoffmann wrote:
>
> > +/* How many bytes left in this page. */
> > +static unsigned int rest_of_page(void *data)
> > +{
> > + return PAGE_SIZE - offset_in_page(data);
> > +}
>
> Not needed.
>
> > +/* Create sg_table from a vmalloc'd buffer. */
> > +static
https://bugs.freedesktop.org/show_bug.cgi?id=111077
--- Comment #30 from rol...@rptd.ch ---
How I best test this? Just check out the branch and build it or apply it
somehow to the mesa branch I have here from bisecting?
--
You are receiving this mail because:
You are the assignee for the
On 09/09/2019 16:41, Rob Herring wrote:
> On Fri, Sep 6, 2019 at 4:23 PM Steven Price wrote:
>>
>> On 04/09/2019 13:30, Mark Brown wrote:
>>> The panfrost driver requests a supply using regulator_get_optional()
>>> but both the name of the supply and the usage pattern suggest that it is
>>> being
On Mon, Sep 9, 2019 at 5:18 AM Heiko Stübner wrote:
>
> Hi Qiang,
>
> Am Montag, 9. September 2019, 04:30:43 CEST schrieb Qiang Yu:
> > Oh, I was miss leading by the drm_gem_reservation_object_wait
> > comments. Patch is:
> > Reviewed-by: Qiang Yu
> >
> > I'll apply this patch to drm-misc-next.
https://bugs.freedesktop.org/show_bug.cgi?id=111588
--- Comment #2 from Michel Dänzer ---
(In reply to Hans de Goede from comment #0)
> 5) Plymouth internally calls src/plugins/renderers/drm/plugin.c:
>ply_renderer_buffer_free() this does:
> drmModeRmFB(...);
> munmap
Hi all,
This is regarding the recent hdcp content type patch that was merged into
drm-misc. (https://patchwork.freedesktop.org/patch/320958/?series=57233=11)
There are displays on the market that advertise HDCP 2.2 support and will pass
authentication and encryption but will then show a
There is no point to print deferred probe (and its failures to get
resources) as an error.
In case of multiple probe tries this would pollute the dmesg.
Signed-off-by: Krzysztof Kozlowski
---
drivers/gpu/drm/panfrost/panfrost_device.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
https://bugs.freedesktop.org/show_bug.cgi?id=110659
--- Comment #79 from Pierre-Eric Pelloux-Prayer
---
(In reply to Michel Dänzer from comment #76)
> (In reply to tempel.julian from comment #75)
> > Is it possible that Wine or the affected programs in Wine are the clients
> > that are at fault
On Fri, Sep 6, 2019 at 4:23 PM Steven Price wrote:
>
> On 04/09/2019 13:30, Mark Brown wrote:
> > The panfrost driver requests a supply using regulator_get_optional()
> > but both the name of the supply and the usage pattern suggest that it is
> > being used for the main power for the device and
https://bugs.freedesktop.org/show_bug.cgi?id=110659
--- Comment #78 from Michel Dänzer ---
(In reply to tempel.julian from comment #77)
> I turned DPMS off in Xorg config which leaves the issue unchanged. Is this
> to be expected?
Yeah, this isn't directly related to X's DPMS functionality.
--
On 2019-09-07 4:58 p.m., Alex Deucher wrote:
>
> The patch shuffling doesn't help, but regardless, the same thing could
> happen even with a direct committer tree if someone missed the tag when
> committing.
True, but in the latter case it would at least be possible to add tags
referencing
https://bugs.freedesktop.org/show_bug.cgi?id=110659
--- Comment #77 from tempel.jul...@gmail.com ---
(In reply to Michel Dänzer from comment #76)
> Certainly. It looks like the intention is to prevent the monitors from
> entering power saving mode.
I turned DPMS off in Xorg config which leaves
https://bugs.freedesktop.org/show_bug.cgi?id=111527
--- Comment #3 from Michel Dänzer ---
Does https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1907 help by any
chance?
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=109246
Jean Delvare changed:
What|Removed |Added
CC||jdelv...@suse.de
--- Comment #28 from
Hi
Am 04.09.19 um 08:27 schrieb Feng Tang:
> Hi Thomas,
>
> On Wed, Aug 28, 2019 at 12:51:40PM +0200, Thomas Zimmermann wrote:
>> Hi
>>
>> Am 28.08.19 um 11:37 schrieb Rong Chen:
>>> Hi Thomas,
>>>
>>> On 8/28/19 1:16 AM, Thomas Zimmermann wrote:
Hi
Am 27.08.19 um 14:33 schrieb
Support for vblank requires VSYNC to signal an interrupt, which is broken
on Matrox chipsets. The workaround that is used here and in other free
Matrox drivers is to program to the value of and
enable the VLINE interrupt. This triggers an interrupt at the same time
when VSYNC begins.
VLINE uses
A full-screen memcpy() moves the console's shadow buffer to hardware; with
possibly significant runtime overhead. [1]
The console's dirty worker now waits for the vblank to rate limit the
output frequency. Screen output can pile up while waiting and there's a
chance that multiple screen updates
Before updating the display from the console's shadow buffer, the dirty
worker now waits for vblank. This allows several screen updates to pile
up and acts as a rate limiter.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_fb_helper.c | 12
1 file changed, 12 insertions(+)
https://bugs.freedesktop.org/show_bug.cgi?id=110659
--- Comment #76 from Michel Dänzer ---
(In reply to tempel.julian from comment #75)
> Is it possible that Wine or the affected programs in Wine are the clients
> that are at fault for this?
Certainly. It looks like the intention is to prevent
On Mon, Sep 09, 2019 at 09:37:14AM +0200, Neil Armstrong wrote:
> I'd like some review from ASoC people and other drm bridge reviewers,
> Jernej, Jonas & Andrzej.
> Jonas could have some comments on the overall patchset.
The ASoC bits look basically fine, I've gone ahead and applied
patch 1 as
Change scale_increment_interval and nfl_bpg_offset fields to
u32 to avoid W=1 warnings because we are testing them against
65535.
Signed-off-by: Benjamin Gaignard
---
include/drm/drm_dsc.h | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/include/drm/drm_dsc.h
Fix warnings with W=1.
Few for_each macro set variables that are never used later.
Prevent warning by marking these variables as __maybe_unused.
Signed-off-by: Benjamin Gaignard
---
drivers/gpu/drm/drm_atomic_helper.c | 36 ++--
1 file changed, 18 insertions(+),
Add a modifier 'DRM_FORMAT_MOD_ARM_PROTECTED' which denotes that the framebuffer
is allocated in a protected system memory.
Essentially, we want to support EGL_EXT_protected_content in our komeda driver.
Signed-off-by: Ayan Kumar Halder
/-- Note to reviewer
Komeda driver is capable of rendering
Emil, this seems has been stalled again from DRM maintainers. Just to see if you
have some "magic" to unsilence it like the last time...
On Fri, 2019-08-23 at 14:37 -0400, Qian Cai wrote:
> In file included from ./include/linux/bitmap.h:9,
> from ./include/linux/cpumask.h:12,
>
The init, cleanup and mmap functions of VRAM MM are only used internally.
Remove them from the public interface.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_gem_vram_helper.c | 38 ---
include/drm/drm_gem_vram_helper.h | 7 -
2 files changed, 5
VRAM MM and GEM VRAM are only used with each other. This patch set
moves VRAM MM into GEM VRAM source files and cleans up the helper's
public interface.
Thomas Zimmermann (4):
drm/vram: Move VRAM memory manager to GEM VRAM implementation
drm/vram: Have VRAM MM call GEM VRAM functions directly
The statement's condition is always true.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_gem_vram_helper.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
b/drivers/gpu/drm/drm_gem_vram_helper.c
index
VRAM MM and GEM VRAM buffer objects are only used with each other;
connected via 3 function pointers. Simplifiy this code by making the
memory manager call the rsp. functions from the BOs directly; and
remove the functions from he BO's public interface.
Signed-off-by: Thomas Zimmermann
---
The separation between GEM VRAM objects and and the memory manager
is artificial, as they are only used with each other. Copying both
implementations into the same file is a first step to simplifying
the code.
This patch only moves code without functional changes.
Signed-off-by: Thomas
Am 04.09.19 um 07:47 schrieb Gerd Hoffmann:
> select isn't recursive, so we can't turn on DRM_TTM + DRM_TTM_HELPER
> in config DRM_VRAM_HELPER, we have to select them on the vram users
> instead.
>
> Signed-off-by: Gerd Hoffmann
> ---
> drivers/gpu/drm/Kconfig | 2 --
>
Am 04.09.19 um 07:47 schrieb Gerd Hoffmann:
> New helper to print named bits of some value (think flags fields).
>
> Signed-off-by: Gerd Hoffmann
> ---
> include/drm/drm_print.h | 3 +++
> drivers/gpu/drm/drm_print.c | 33 +
> 2 files changed, 36
https://bugs.freedesktop.org/show_bug.cgi?id=109303
--- Comment #6 from CI Bug Log ---
A CI Bug Log filter associated to this bug has been updated:
{- CML ICL: igt@i915_query@query-topology-known-pci-ids - skip - Test
requirement: IS_HASWELL(devid) || IS_BROADWELL(devid) || IS_SKYLAKE(devid) ||
Hi Qiang,
Am Montag, 9. September 2019, 04:30:43 CEST schrieb Qiang Yu:
> Oh, I was miss leading by the drm_gem_reservation_object_wait
> comments. Patch is:
> Reviewed-by: Qiang Yu
>
> I'll apply this patch to drm-misc-next.
>
> Current kernel release is 5.3-rc8, is it too late for this fix
https://bugzilla.kernel.org/show_bug.cgi?id=204227
--- Comment #12 from Mirek Kratochvil (exa@gmail.com) ---
That sounds great, thank you very much for the information and confirmation. I
will try to update the BIOS and confirm ASAP.
--
You are receiving this mail because:
You are watching
On Sun, Sep 08, 2019 at 06:17:50PM +0200, Jacek Anaszewski wrote:
> On 7/22/19 11:23 PM, Jacek Anaszewski wrote:
> > On 7/22/19 9:06 AM, Lee Jones wrote:
> >> On Thu, 18 Jul 2019, Jacek Anaszewski wrote:
> >>
> >>> On 7/17/19 4:15 PM, Jean-Jacques Hiblot wrote:
> This series aims to add a
https://bugzilla.kernel.org/show_bug.cgi?id=204227
--- Comment #11 from tones...@hotmail.com ---
Some good news. After a bios update to Lenovo's E485/E585 1.54 I no longer
need to provide additional boot arguments in order for the machine to come up
and the visual artifacts have gone away.
I
On Sun, Sep 08, 2019 at 10:37:04PM +0200, Andreas Kemnade wrote:
> add enable-gpios to describe HWEN pin
>
> Signed-off-by: Andreas Kemnade
Looks like patches are in the wrong order. Changes to bindings must
appear in patchsets *before* the Linux implementation of the bindings.
> ---
>
On Sun, Sep 08, 2019 at 10:37:03PM +0200, Andreas Kemnade wrote:
> For now just enable it in the probe function to allow i2c
> access and disable it on remove. Disabling also means resetting
> the register values to default.
>
> Tested on Kobo Clara HD.
>
> Signed-off-by: Andreas Kemnade
> ---
On Sat, Sep 07, 2019 at 11:19:55PM +, Mun, Gwan-gyeong wrote:
> On Fri, 2019-09-06 at 09:24 -0400, Ilia Mirkin wrote:
> > On Fri, Sep 6, 2019 at 7:43 AM Ville Syrjälä
> > wrote:
> > > On Fri, Sep 06, 2019 at 11:31:55AM +, Shankar, Uma wrote:
> > > >
> > > > > -Original Message-
>
Hi,
On Mon, 9 Sep 2019 20:11:59 +1000 Stephen Rothwell
wrote:
>
> If you are bisecting linux-next, I will suggest bisecting between the
> stable branch on linux-next (which is just Linus' tree when I started
> that day) and the top of the first linux-next that fails. (Assuming
> that the
On Sat, 07 Sep 2019, Daniel Vetter wrote:
> On Sat, Sep 7, 2019 at 3:18 AM Rob Clark wrote:
>>
>> On Fri, Sep 6, 2019 at 3:16 PM Marek Olšák wrote:
>> >
>> > + dri-devel
>> >
>> > On Tue, Sep 3, 2019 at 5:41 PM Jiang, Sonny wrote:
>> >>
>> >> Add DRM device name and use DRM_IOCTL_VERSION ioctl
Fix warnings when W=1.
No code changes, only clean up in sti internal structures and functions
descriptions.
Signed-off-by: Benjamin Gaignard
---
drivers/gpu/drm/sti/sti_cursor.c | 2 +-
drivers/gpu/drm/sti/sti_dvo.c| 2 +-
drivers/gpu/drm/sti/sti_gdp.c| 2 +-
Hi Alexander,
On Sun, 8 Sep 2019 17:13:07 +0300 Alexander Kapshuk
wrote:
>
> This is my first bisect. Here's what I've tried so far and based on the
> output I got, I seem to be taken in the opposit direction.
>
> git bisect start
> git bisect bad#
Hi,
> > + vma->vm_flags |= VM_IO | VM_PFNMAP | VM_DONTEXPAND |
> > VM_DONTDUMP;
> > + vma->vm_page_prot =
> > pgprot_writecombine(vm_get_page_prot(vma->vm_flags));
> > + vma->vm_page_prot = pgprot_decrypted(vma->vm_page_prot);
> > + }
>
>
On Sun, Sep 08, 2019 at 08:26:05PM -0500, Sreeram Veluthakkal wrote:
> This patch fixes the issue:
> FILE: drivers/staging/fbtft/fb_agm1264k-fl.c:88:
> CHECK: usleep_range is preferred over udelay; see
> Documentation/timers/timers-howto.rst
> + udelay(20);
>
> Signed-off-by: Sreeram
On Wed, Jul 17, 2019 at 04:15:14PM +0200, 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
On Fri, Sep 06, 2019 at 02:20:52PM +0200, Thomas Zimmermann wrote:
> Generic fbdev emulation maps and unmaps the console BO for updating it's
> content from the shadow buffer. If this involves an actual mapping
> operation (instead of reusing an existing mapping), lots of debug messages
> may be
On Mon, Sep 09, 2019 at 07:02:33AM +, Koenig, Christian wrote:
> Am 05.09.19 um 09:05 schrieb Gerd Hoffmann:
> > No users left. Drivers either setup vma_offset_manager themself
> > (vmwgfx) or pass the gem vma_offset_manager to ttm_bo_device_init
> > (all other drivers).
> >
> >
Le ven. 6 sept. 2019 à 11:22, Yannick Fertré a écrit :
>
> The implementation of functions encoder_enable and encoder_disable
> make possible to control the pinctrl according to the encoder type.
> The pinctrl must be activated only if the encoder type is DPI.
> This helps to move the DPI-related
I agree with Daniels analysis.
It looks like the problem is simply that PM turns of a block before all
work is done on that block.
Have you opened a bug report yet? If not then that would certainly help
cause it is really hard to extract all necessary information from that
mail thread.
https://bugs.freedesktop.org/show_bug.cgi?id=111236
--- Comment #13 from Michel Dänzer ---
Note that my patch is just a proof of concept pointing at where the issue lies.
I hope it helps someone else come up with a proper fix.
--
You are receiving this mail because:
You are the assignee for
https://bugs.freedesktop.org/show_bug.cgi?id=111599
Bug ID: 111599
Summary: [CI][RESUME] igt@gem_ctx_isolation@* - skip - Test
requirement: !(gen > LAST_KNOWN_GEN), SKIP
Product: DRI
Version: XOrg git
Hardware: Other
https://bugs.freedesktop.org/show_bug.cgi?id=111599
--- Comment #1 from CI Bug Log ---
The CI Bug Log issue associated to this bug has been updated.
### New filters associated
* TGL: igt@gem_ctx_isolation@* - skip - Test requirement: !(gen
LAST_KNOWN_GEN), SKIP
-
https://bugs.freedesktop.org/show_bug.cgi?id=111599
Martin Peres changed:
What|Removed |Added
Priority|not set |high
--
You are receiving this mail
https://bugzilla.kernel.org/show_bug.cgi?id=204227
Mirek Kratochvil (exa@gmail.com) changed:
What|Removed |Added
CC||exa@gmail.com
On 06.09.19 19:47, Daniel Vetter wrote:
> I missed that when extending the lockdep annotations to the
> nonblocking case.
>
> I missed this while testing since in the i915 mmu notifiers is hitting
> a nice lockdep splat already before the point of going into oom killer
> mode :-/
>
>
Hi,
On 08/09/2019 15:51, Cheng-yi Chiang wrote:
> On Fri, Aug 30, 2019 at 10:55 AM Cheng-yi Chiang
> wrote:
>>
>> On Wed, Jul 17, 2019 at 6:28 PM Tzung-Bi Shih wrote:
>>>
>>> On Wed, Jul 17, 2019 at 4:33 PM Cheng-Yi Chiang
>>> wrote:
This patch series supports HDMI jack reporting
Reviewed-by: Kevin Wang
Best Regards,
Kevin
From: amd-gfx on behalf of Austin Kim
Sent: Monday, September 9, 2019 12:31 PM
To: Deucher, Alexander ; airl...@linux.ie
; dan...@ffwll.ch
Cc: Zhou, David(ChunMing) ; amd-...@lists.freedesktop.org
;
On Fri, 06 Sep 2019, Thomas Zimmermann wrote:
Generic fbdev emulation maps and unmaps the console BO for updating it's
content from the shadow buffer. If this involves an actual mapping
operation (instead of reusing an existing mapping), lots of debug messages
may be printed, such as
x86/PAT:
To be able to handle the HWEN pin of the lm3630a, add
an enable gpio to the driver and a property.
Tested on Kobo Clara HD
Andreas Kemnade (2):
backlight: lm3630a: add an enable gpio for the HWEN pin
dt-bindings: backlight: lm3630a: add enable_gpios
Since release of the new BCM2835 PM driver there has been several reports
of V3D probing issues. This is caused by timeouts during powering-up the
GRAFX PM domain:
bcm2835-power: Timeout waiting for grafx power OK
I was able to reproduce this reliable on my Raspberry Pi 3B+ after setting
On Sat, Sep 07, 2019 at 12:32:41PM +0200, Daniel Vetter wrote:
> On Sat, Sep 7, 2019 at 11:05 AM Alexander Kapshuk
> wrote:
> >
> > To Whom It May Concern
> >
> > Every kernel I have built since 5.3.0-rc2-next-20190730 and up to
> > 5.3.0-rc7-next-20190903 has resulted in the kernel panic
add enable-gpios to describe HWEN pin
Signed-off-by: Andreas Kemnade
---
.../devicetree/bindings/leds/backlight/lm3630a-backlight.yaml | 4
1 file changed, 4 insertions(+)
diff --git
a/Documentation/devicetree/bindings/leds/backlight/lm3630a-backlight.yaml
For now just enable it in the probe function to allow i2c
access and disable it on remove. Disabling also means resetting
the register values to default.
Tested on Kobo Clara HD.
Signed-off-by: Andreas Kemnade
---
drivers/video/backlight/lm3630a_bl.c | 18 ++
1 file changed, 18
Dne četrtek, 05. september 2019 ob 11:43:25 CEST je Cheng-Yi Chiang
napisal(a):
> From: Yakir Yang
>
> When transmitting IEC60985 linear PCM audio, we configure the
> Aduio Sample Channel Status information of all the channel
> status bits in the IEC60958 frame.
> Refer to 60958-3 page 10 for
size contain non-negative value since it is declared as uint32_t.
So below statement is always false.
if (size < 0)
Remove unnecessary comparison.
Signed-off-by: Austin Kim
---
drivers/gpu/drm/amd/powerplay/navi10_ppt.c | 3 ---
1 file changed, 3 deletions(-)
diff --git
>From Frediano Ziglio
>
> Where does it came this patch?
My fingers tapping the keyboard.
> Is it already somewhere?
No idea yet.
> Is it supposed to fix this issue?
It may do nothing else as far as I can tell.
> Does it affect some other card beside QXL?
Perhaps.
https://bugs.freedesktop.org/show_bug.cgi?id=111236
--- Comment #12 from Víctor Jáquez ---
Hi Michel,
The patch also worked for me! :) Thanks!
In the case of totem, there's a work in progress
https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/merge_requests/122 but
it requires a lot
Am 05.09.19 um 09:05 schrieb Gerd Hoffmann:
> Pass gem vma_offset_manager to ttm_bo_device_init(), so ttm uses it
> instead of its own embedded struct. This makes some gem functions
> (specifically drm_gem_object_lookup) work on ttm objects.
>
> Signed-off-by: Gerd Hoffmann
> ---
>
Am 05.09.19 um 09:05 schrieb Gerd Hoffmann:
> No users left. Drivers either setup vma_offset_manager themself
> (vmwgfx) or pass the gem vma_offset_manager to ttm_bo_device_init
> (all other drivers).
>
> Signed-off-by: Gerd Hoffmann
Patches #4, #5 and #8 in this series are Reviewed-by:
Am 05.09.19 um 09:05 schrieb Gerd Hoffmann:
Rename the embedded struct vma_offset_manager, new name is _vma_manager.
ttm_bo_device.vma_manager changed to a pointer.
The ttm_bo_device_init() function gets an additional vma_manager
argument which allows to initialize ttm with a different vma
https://bugs.freedesktop.org/show_bug.cgi?id=105718
--- Comment #7 from Andrew Sheldon ---
(In reply to Shmerl from comment #5)
> Actually, I've noticed another similar issue. I just got Sapphire Pulse RX
> 5700 XT. It's also dual fan.
>
> According to this:
>
91 matches
Mail list logo
