https://bugs.freedesktop.org/show_bug.cgi?id=111570
Andre Klapper changed:
What|Removed |Added
Group||spam
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=105718
--- Comment #6 from Shmerl ---
Hm, it could be radeon-profile mis-reporting fan load percentage, using the max
value of 3200 reported by sensors. That's where I got those 50% I mentioned
above.
I just run The Witcher without vsync (Wine+dxvk) w
> +/* 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 struct sg_table *vmalloc_to_sgt(char *data, uint32_t size, int
> *sg_ents)
https://bugs.freedesktop.org/show_bug.cgi?id=105718
--- Comment #5 from Shmerl ---
Actually, I've noticed another similar issue. I just got Sapphire Pulse RX 5700
XT. It's also dual fan.
According to this:
https://www.gamersnexus.net/hwreviews/3498-sapphire-rx-5700-xt-pulse-review
The top level
https://bugs.freedesktop.org/show_bug.cgi?id=105718
Shmerl changed:
What|Removed |Added
Summary|amdgpu reported fan speed |amdgpu reported fan speed
|l
The hardware supports either size. Also add checks to ensure that only
these two sizes may be used for supplying a LUT.
Signed-off-by: Ilia Mirkin
---
Only tested on G84 and GK208. The GV100+ is entirely untested.
With the fixed modetest tool, setting ilut and olut sizes to different
quantities
https://bugs.freedesktop.org/show_bug.cgi?id=111481
--- Comment #31 from Mathieu Belanger ---
Is that patch set
https://lists.freedesktop.org/archives/amd-gfx/2019-September/039593.html
relate to this ?
Graceful page fault handling for Vega/Navi
--
You are receiving this mail because:
You are
https://bugs.freedesktop.org/show_bug.cgi?id=111555
--- Comment #2 from Shmerl ---
Related: https://github.com/marazmista/radeon-profile/issues/157
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri
https://bugs.freedesktop.org/show_bug.cgi?id=111459
--- Comment #5 from tajgaivi...@freemail.hu ---
Hi,
Have you tried reverting the xorg amdgpu package to an older version? Of course
that is just a workaround.
--
You are receiving this mail because:
You are the assignee for the bug.___
https://bugs.freedesktop.org/show_bug.cgi?id=111077
--- Comment #26 from rol...@rptd.ch ---
I've tried getting something done with RenderDoc but I did not get anywhere. I
can capture the scene in the application (basically just a sky-box) but that's
not really helpful. The problem happens while s
https://bugs.freedesktop.org/show_bug.cgi?id=111555
--- Comment #1 from Shmerl ---
These errors also happen when using radeon-profile to control the fan speed:
[ 3099.422315] amdgpu: [powerplay] Failed to send message 0xe, response
0xfffb param 0x80
[ 3099.422318] amdgpu: [powerplay] Failed
On Fri, Aug 30, 2019 at 3:41 PM Bibby Hsieh wrote:
>
> The CMDQ (Command Queue) in MT8183 is used to help
> update all relevant display controller registers
> with critical time limation.
> This patch add cmdq interface in ddp_comp interface,
> let all ddp_comp interface can support cpu/cmdq funct
On Thu, Sep 5, 2019 at 12:05 PM Rob Clark wrote:
>
> On Thu, Sep 5, 2019 at 10:03 AM Rob Clark wrote:
> >
> > On Wed, Sep 4, 2019 at 11:06 AM Robin Murphy wrote:
> > >
> > > On 04/09/2019 01:12, Rob Clark wrote:
> > > > On Tue, Sep 3, 2019 at 12:31 PM Fabio Estevam
> > > > wrote:
> > > >>
> >
Userspace requested command buffer allocations could be too large
to make as a contiguous allocation. Use vmalloc if necessary to
satisfy those allocations.
Signed-off-by: David Riley
---
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 4 +-
drivers/gpu/drm/virtio/virtgpu_vq.c| 114 +
On Thu, Sep 5, 2019 at 4:32 PM Daniel Vetter wrote:
>
*snip*
> drm_dev_unregister gets called on hotunplug, so your cgroup-internal
> tracking won't get out of sync any more than the drm_minor list gets
> out of sync with drm_devices. The trouble with drm_minor is just that
> cgroup doesn't track
From: Dhinakaran Pandiyan
Currently we restrict the number of encoders that can be linked to
a connector to 3, increase it to match the maximum number of encoders
that can be initialized(32).
To more effiently do that lets switch from an array of encoder ids to
bitmask.
Also removing the best_e
From: Dhinakaran Pandiyan
Currently we restrict the number of encoders that can be linked to
a connector to 3, increase it to match the maximum number of encoders
that can be initialized(32).
To more effiently do that lets switch from an array of encoder ids to
bitmask.
Also removing the best_e
Hi,
[This is an automated email]
This commit has been processed because it contains a -stable tag.
The stable tag indicates that it's relevant for the following trees: all
The bot has tested the following trees: v5.2.11, v4.19.69, v4.14.141, v4.9.190,
v4.4.190.
v5.2.11: Build OK!
v4.19.69: Fai
On Thu, Sep 5, 2019 at 10:21 PM Kenny Ho wrote:
>
> On Thu, Sep 5, 2019 at 4:06 PM Daniel Vetter wrote:
> >
> > On Thu, Sep 5, 2019 at 8:28 PM Kenny Ho wrote:
> > >
> > > (resent in plain text mode)
> > >
> > > Hi Daniel,
> > >
> > > This is the previous patch relevant to this discussion:
> > >
On Thu, Sep 5, 2019 at 4:06 PM Daniel Vetter wrote:
>
> On Thu, Sep 5, 2019 at 8:28 PM Kenny Ho wrote:
> >
> > (resent in plain text mode)
> >
> > Hi Daniel,
> >
> > This is the previous patch relevant to this discussion:
> > https://patchwork.freedesktop.org/patch/314343/
>
> Ah yes, thanks for
On Thu, Sep 5, 2019 at 8:28 PM Kenny Ho wrote:
>
> (resent in plain text mode)
>
> Hi Daniel,
>
> This is the previous patch relevant to this discussion:
> https://patchwork.freedesktop.org/patch/314343/
Ah yes, thanks for finding that.
> So before I refactored the code to leverage drm_minor, I
Hi Ville,
First of all, thank you very much for the review.
I added some comments below.
On 09/05, Wentland, Harry wrote:
> On 2019-09-05 1:29 p.m., Ville Syrjälä wrote:
> > On Wed, Sep 04, 2019 at 07:02:18PM +, Siqueira, Rodrigo wrote:
> >> DP 1.4a specification defines Link Training Tunabl
On Thu, Sep 5, 2019 at 10:03 AM Rob Clark wrote:
>
> On Wed, Sep 4, 2019 at 11:06 AM Robin Murphy wrote:
> >
> > On 04/09/2019 01:12, Rob Clark wrote:
> > > On Tue, Sep 3, 2019 at 12:31 PM Fabio Estevam wrote:
> > >>
> > >> Hi Jonathan,
> > >>
> > >> On Tue, Sep 3, 2019 at 4:25 PM Jonathan Marek
The -modesetting ddx has a totally broken idea of how atomic works:
- doesn't disable old connectors, assuming they get auto-disable like
with the legacy setcrtc
- assumes ASYNC_FLIP is wired through for the atomic ioctl
- not a single call to TEST_ONLY
Iow the implementation is a 1:1 translatio
On 2019-09-05 2:33 p.m., Krzysztof Wilczynski wrote:
> Move the static keyword to the front of declaration of DC_BUILD_ID,
> and resolve the following compiler warning that can be seen when
> building with warnings enabled (W=1):
>
> drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:75:1: warning
(resent in plain text mode)
Hi Daniel,
This is the previous patch relevant to this discussion:
https://patchwork.freedesktop.org/patch/314343/
So before I refactored the code to leverage drm_minor, I kept my own
list of "known" drm_device inside the controller and have explicit
register and unre
Hi Daniel,
This is the previous patch relevant to this discussion:
https://patchwork.freedesktop.org/patch/314343/
So before I refactored the code to leverage drm_minor, I kept my own list
of "known" drm_device inside the controller and have explicit register and
unregister function to init per d
The -modesetting ddx has a totally broken idea of how atomic works:
- doesn't disable old connectors, assuming they get auto-disable like
with the legacy setcrtc
- assumes ASYNC_FLIP is wired through for the atomic ioctl
- not a single call to TEST_ONLY
Iow the implementation is a 1:1 translatio
https://bugs.freedesktop.org/show_bug.cgi?id=111482
--- Comment #15 from Robert ---
Thanks Ilia for your comment! I get this output from "xrandr":
"""
Screen 0: minimum 320 x 200, current 5120 x 1440, maximum 16384 x 16384
DisplayPort-0 disconnected (normal left inverted right x axis y axis)
Dis
On Fri, 2019-08-30 at 13:32 -0700, Anusha Srivatsa wrote:
> Add the new CML PCI IDS.
>
> Align with kernel commit:
> bfc4c359b2822 ("drm/i915/cml: Add Missing PCI IDs")
>
> This is in sync with kernel header as of:
> 0747590267e7 ("drm-tip: 2019y-08m-30d-18h-03m-18s UTC integration
> manifest")
>
On 2019-09-05 1:29 p.m., Ville Syrjälä wrote:
> On Wed, Sep 04, 2019 at 07:02:18PM +, Siqueira, Rodrigo wrote:
>> DP 1.4a specification defines Link Training Tunable PHY Repeater (LTTPR)
>
> A bunch of this stuff was already in DP 1.3 so the statement here
> (and in the comment) is a bit misle
On Wed, Sep 04, 2019 at 07:02:18PM +, Siqueira, Rodrigo wrote:
> DP 1.4a specification defines Link Training Tunable PHY Repeater (LTTPR)
A bunch of this stuff was already in DP 1.3 so the statement here
(and in the comment) is a bit misleading.
"LTTPR" is not a name that appears anywhere in
On Tue, Sep 3, 2019 at 12:07 PM Daniel Vetter wrote:
>
> The -modesetting ddx has a totally broken idea of how atomic works:
> - doesn't disable old connectors, assuming they get auto-disable like
> with the legacy setcrtc
> - assumes ASYNC_FLIP is wired through for the atomic ioctl
> - not a si
On Wed, Sep 4, 2019 at 10:23 PM Gerd Hoffmann wrote:
>
> On Wed, Sep 04, 2019 at 04:10:30PM -0700, Chia-I Wu wrote:
> > On Wed, Sep 4, 2019 at 12:48 AM Gerd Hoffmann wrote:
> > >
> > > Only call virtio_gpu_array_add_fence if we actually have a fence.
> > >
> > > Fixes: da758d51968a ("drm/virtio:
On Wed, Sep 4, 2019 at 11:06 AM Robin Murphy wrote:
>
> On 04/09/2019 01:12, Rob Clark wrote:
> > On Tue, Sep 3, 2019 at 12:31 PM Fabio Estevam wrote:
> >>
> >> Hi Jonathan,
> >>
> >> On Tue, Sep 3, 2019 at 4:25 PM Jonathan Marek wrote:
> >>>
> >>> Hi,
> >>>
> >>> I tried this and it works with
Hi Dave and Daniel,
Fixes for v5.3 final! Hopefully last for v5.3 now. :)
drm-misc-fixes-2019-09-05:
drm-misc-fixes for v5.3 final:
- Make ingenic panel type DPI instead of unknown.
- Fixes for command line parser modes.
The following changes since commit 6978bce054247e4cfccdf689ce263e076499f905:
On Thu, Sep 05, 2019 at 08:16:48AM -0300, Fabio Estevam wrote:
> Booting the adreno driver on a imx53 board leads to the following
> error message:
>
> adreno 3000.gpu: [drm:adreno_gpu_init] *ERROR* Could not find the GPU
> powerlevels
>
> As the "qcom,gpu-pwrlevels" property is optional and
On Thu, Sep 5, 2019 at 11:51 AM 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 for which those workarounds where actually added.
>
> On Mon, Aug 19, 2019 at 11:
On Thu, Sep 05, 2019 at 02:02:38PM +0100, Steven Price wrote:
> On 05/09/2019 13:40, Mark Brown wrote:
> > Is that safe? You can't rely on being able to change voltages even if
> > there's a physical regulator available, system constraints or the
> > results of sharing the regulator with other us
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 for which those workarounds where actually added.
Alex Hung and Mari
On Thu, Sep 05, 2019 at 10:17:41AM -0600, Mathieu Poirier wrote:
> These patches are backport candidates picked out of TI's 4.14.y tree [1],
> with most of them already found in the 4.19.y stable tree.
Could you please update your scripting that only the cover-letter and
I2C related patches will b
From: Niklas Cassel
commit ad4a5becc689c3f32bbbc2b37eff89efe19dc2f9 upstream
find_first_zero_bit()'s parameter 'size' is defined in bits,
not in bytes.
find_first_zero_bit() is called with size in bytes rather than bits,
which thus defines a too low upper limit, causing
dw_pcie_ep_inbound_atu()
From: Vignesh R
commit 524d59f6e30aab5b618da55e604c802ccd83e708 upstream
Legacy INTD IRQ handling is broken on dra7xx due to fact that driver
uses hwirq in range of 1-4 for INTA, INTD whereas IRQ domain is of size
4 which is numbered 0-3. Therefore when INTD IRQ line is used with
pci-dra7xx driv
These patches are backport candidates picked out of TI's 4.14.y tree [1],
with most of them already found in the 4.19.y stable tree.
The set apply and compiles cleanly on 4.14.141.
Thanks,
Mathieu
[1].
http://git.ti.com/gitweb/?p=ti-linux-kernel/ti-linux-kernel.git;a=shortlog;h=refs/heads/ti-l
From: Roman Yeryomin
commit d342b6a973af459f6104cad6effc8efc71a0558d upstream
Signed-off-by: Roman Yeryomin
Signed-off-by: Cyrille Pitchen
Signed-off-by: Mathieu Poirier
---
drivers/mtd/spi-nor/spi-nor.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mtd/spi-nor/
From: Tony Lindgren
commit e128310ddd379b0fdd21dc41d176c3b3505a0832 upstream
This adds support for get_timings() and check_timings()
to get the driver working and properly initializes the
timing information from DT.
Signed-off-by: Tony Lindgren
Signed-off-by: Sebastian Reichel
Signed-off-by:
From: Keerthy
commit 572ff4d560be3784205b224cd67d6715620092d7 upstream
The powerhold mask for TPS65917 is different when comapred to
the other palmas versions. Hence assign the right mask that enables
power off of tps65917 pmic correctly.
Signed-off-by: Keerthy
Signed-off-by: Lee Jones
Signed
From: Vignesh R
commit 61dc8493bae9ba82a1c72edbc6c6065f6a94456a upstream
As per 66AK2G02 TRM[1] SPRUHY8F section 11.15.5.3 Indirect Access
Controller programming sequence, a delay equal to couple of QSPI master
clock(~5ns) is required after setting CQSPI_REG_INDIRECTWR_START bit and
writing data
From: Roger Quadros
commit 42bf02ec6e420e541af9a47437d0bdf961ca2972 upstream
Some platforms (e.g. TI's DRA7 USB2 instance) have more trouble
with the metastability workaround as it supports only
a High-Speed PHY and the PHY can enter into an Erratic state [1]
when the controller is set in SuperS
From: Dan Carpenter
commit 378f79cab12b669928f3a4037f023837ead2ce0c upstream
"size + max" can have an arithmetic overflow when we're allocating:
orig_src_addr = dma_alloc_coherent(dev, size + alignment, ...
I've added a few checks to prevent that.
Fixes: 13107c60681f ("misc: pci_endpo
From: "Andrew F. Davis"
commit dcb407b257af06fa58b0544ec01ec9e0d3927e02 upstream
Currently BCLK inverting is only handled when the DAI format is
DSP, but the BCLK may be inverted in any supported mode. Without
this using this CODEC in any other mode than DSP with the BCLK
inverted leads to bad s
From: Sudeep Holla
commit 33cd7123ac0ba5360656ae27db453de5b9aa711f upstream
Currently the mailbox framework sets txdone_method to TXDONE_BY_POLL if
the controller sets txdone_by_poll. However some clients can have a
mechanism to do TXDONE_BY_ACK which they can specify by knows_txdone.
However, w
From: Christophe Jaillet
commit 1b8b68b05d1868404316d32e20782b00442aba90 upstream
All error handling paths in this function 'goto err' except this one.
If one of the 2 previous memory allocations fails, we should go through
the existing error handling path. Otherwise there is an unbalanced
pm_r
From: Arvind Yadav
commit 0c8b794c4a10aaf7ac0d4a49be2b2638e2038adb upstream
devm_kasprintf() can fail here and we must check its return value.
Signed-off-by: Arvind Yadav
Acked-by: Peter Ujfalusi
Signed-off-by: Mark Brown
Signed-off-by: Mathieu Poirier
---
sound/soc/davinci/davinci-mcasp.c
From: Takashi Iwai
commit befff4fbc27e19b14b343eb4a65d8f75d38b6230 upstream
Don't use BUG_ON() for a non-critical sanity check on production
systems. This patch replaces with a softer WARN_ON() and an error
path.
Signed-off-by: Takashi Iwai
Signed-off-by: Mark Brown
Signed-off-by: Mathieu Po
From: Keerthy
commit 9c049bea083fea21373b8baf51fe49acbe24e105 upstream
Add shutdown handler to cleanly turn off clocks. This will help in cases of
kexec where in a new kernel can boot abruptly.
Signed-off-by: Keerthy
Signed-off-by: Bjorn Helgaas
Acked-by: Kishon Vijay Abraham I
Signed-off-b
From: Kishon Vijay Abraham I
commit b7636e816adcb52bc96b6fb7bc9d141cbfd17ddb upstream
pci_disable_msi() throws a Kernel BUG if the driver has successfully
requested an IRQ and not released it. Fix it here by freeing IRQs before
invoking pci_disable_msi().
Signed-off-by: Kishon Vijay Abraham I
From: Claudio Foellmi
commit 93367bfca98f36cece57c01dbce6ea1b4ac58245 upstream
A very conservative check for bus activity (to prevent interference
in multimaster setups) prevented the bus recovery methods from being
triggered in the case that SDA or SCL was stuck low.
This defeats the purpose of
From: Zumeng Chen
commit 248aefdcc3a7e0cfbd014946b4dead63e750e71b upstream
call of_node_put to release the refcount of np.
Signed-off-by: Zumeng Chen
Acked-by: Viresh Kumar
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Mathieu Poirier
---
drivers/cpufreq/ti-cpufreq.c | 1 +
1 file change
From: "Gustavo A. R. Silva"
commit 09fc38c1af4cb888255e9ecf267bf9757c12885d upstream
In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.
Addresses-Coverity-ID: 1195220
Signed-off-by: Gustavo A. R. Silva
Signed-off-by: Mark Brown
Signed-
On Tue, Sep 3, 2019 at 2:37 AM Dave Airlie wrote:
>
> On Sat, 31 Aug 2019 at 07:27, Alex Deucher wrote:
> >
> > Hi Dave, Daniel,
> >
> > Mostly bug fixes. The big addition is display support for renoir
> > which is new for 5.4. I realize it's a bit late to add it but the
> > rest of the code fo
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 for which those workarounds where actually added.
On Mon, Aug 19, 2019 at 11:52 AM Rafael J. Wysocki wrote:
>
> On Thursday, August 15, 2019
On Thu, Sep 05, 2019 at 02:59:53PM +, Lin, Wayne wrote:
>
>
>
> From: Ville Syrjälä
> Sent: Saturday, August 24, 2019 02:41
> To: Lin, Wayne
> Cc: dri-devel@lists.freedesktop.org ;
> amd-...@lists.freedesktop.org ; Li, Sun peng
> (Leo) ; Kazlauskas, Nichol
From: Ville Syrjälä
Sent: Saturday, August 24, 2019 02:41
To: Lin, Wayne
Cc: dri-devel@lists.freedesktop.org ;
amd-...@lists.freedesktop.org ; Li, Sun peng
(Leo) ; Kazlauskas, Nicholas
Subject: Re: [PATCH] drm/drm_connector: add additional aspect ratio values
https://bugs.freedesktop.org/show_bug.cgi?id=111482
--- Comment #14 from Ilia Mirkin ---
(In reply to Robert from comment #12)
> At least I now know that I can't do anything further. It just would be cool
> if one of the AMD engineers could confirm my assumption that with a
> resolution of 5144x1
On Mon, Aug 26, 2019 at 10:14:20PM +0200, Daniel Vetter wrote:
> Hi all,
>
> Next round. Changes:
>
> - I kept the two lockdep annotations patches since when I rebased this
> before retesting linux-next didn't yet have them. Otherwise unchanged
> except for a trivial conflict.
>
> - Ack from
Ping. Please take a look at this trivial patch.
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,
> from ./arch/x86/include/asm/cpumask.h:5,
> from ./arch/x8
On Wed, Sep 4, 2019 at 3:15 PM Krzysztof Wilczynski wrote:
>
> Move the static keyword to the front of declarations
> of msm_dsi_v2_host_ops, msm_dsi_6g_host_ops and
> msm_dsi_6g_v2_host_ops, and resolve the following
> compiler warnings that can be seen when building
> with warnings enabled (W=1)
On Thu, Sep 5, 2019 at 4:19 PM Maarten Lankhorst
wrote:
>
> Op 03-09-2019 om 21:06 schreef Daniel Vetter:
> > The -modesetting ddx has a totally broken idea of how atomic works:
> > - doesn't disable old connectors, assuming they get auto-disable like
> > with the legacy setcrtc
> > - assumes AS
https://bugs.freedesktop.org/show_bug.cgi?id=111482
--- Comment #13 from Robert ---
Ah and regarding the PCIe3/4 thingy: I can't change that in the BIOS. I didn't
found any configuration that allows me to change it in general or for the PCIe
slot in question. But I guess that's something I don't
https://bugs.freedesktop.org/show_bug.cgi?id=111482
--- Comment #12 from Robert ---
Andrew, you're my hero ;-) While I'm even more sad now (because I now think
that this issue will be indeed never be fixed) I now at least can imagine
what's going on.
As you recommended I changed resolution to 19
Op 03-09-2019 om 21:06 schreef Daniel Vetter:
> The -modesetting ddx has a totally broken idea of how atomic works:
> - doesn't disable old connectors, assuming they get auto-disable like
> with the legacy setcrtc
> - assumes ASYNC_FLIP is wired through for the atomic ioctl
> - not a single call
From: Wei Hu Sent: Thursday, September 5, 2019 1:29 AM
>
> Without deferred IO support, hyperv_fb driver informs the host to refresh
> the entire guest frame buffer at fixed rate, e.g. at 20Hz, no matter there
> is screen update or not. This patch supports deferred IO for screens in
> graphics mo
From: Wei Hu Sent: Thursday, September 5, 2019 2:12 AM
>
> Beginning from Windows 10 RS5+, VM screen resolution is obtained from host.
> The "video=hyperv_fb" boot time option is not needed, but still can be
> used to overwrite what the host specifies. The VM resolution on the host
> could be set
On Thu, Sep 5, 2019 at 2:33 PM Mario Kleiner wrote:
> On Wed, Sep 4, 2019 at 2:57 PM Kazlauskas, Nicholas
> wrote:
> >
> > On 2019-09-03 3:06 p.m., Daniel Vetter wrote:
> > > It's the only flag anyone actually cares about. Plus if we're unlucky,
> > > the atomic ioctl might need a different flag
On 05/09/2019 13:05, Laurent Pinchart wrote:
> Hi Jyri,
>
> On Thu, Sep 05, 2019 at 01:00:51PM +0300, Jyri Sarha wrote:
>> On 05/09/2019 00:52, Laurent Pinchart wrote:
static void omap_crtc_write_crtc_properties(struct drm_crtc *crtc)
{
struct omap_drm_private *
On 05/09/2019 15:02, Steven Price wrote:
> On 05/09/2019 13:40, Mark Brown wrote:
>> On Thu, Sep 05, 2019 at 10:37:53AM +0100, Steven Price wrote:
>>
>>> Ah, I didn't realise that regulator_get() will return a dummy regulator
>>> if none is provided in the DT. In theory that seems like a nicer
>>>
Hi Jacopo,
On Thu, Sep 05, 2019 at 03:14:53PM +0200, Jacopo Mondi wrote:
> On Thu, Sep 05, 2019 at 02:17:12PM +0300, Laurent Pinchart wrote:
> > Hi Jacopo,
> >
> >> +/**
> >> + * rcar_cmm_enable() - enable the CMM unit
> >> + *
> >> + * @pdev: The platform device associated with th
Hi Laurent, Geert,
On Thu, Sep 05, 2019 at 03:20:59PM +0300, Laurent Pinchart wrote:
> Hi Geert,
>
> On Thu, Sep 05, 2019 at 02:05:34PM +0200, Geert Uytterhoeven wrote:
> > On Thu, Sep 5, 2019 at 1:50 PM Laurent Pinchart wrote:
> > > On Fri, Aug 30, 2019 at 08:01:09PM +0200, Jacopo Mondi wrote:
>
On 2019-09-04 4:58 p.m., Randy Dunlap wrote:
> On 9/4/19 6:34 AM, Stephen Rothwell wrote:
>> Hi all,
>>
>> News: this will be the last linux-next I will release until Sept 30.
>>
>> Changes since 20190903:
>>
>
> on x86_64:
>
> In file included from
> ../drivers/gpu/drm/amd/amdgpu/../display/d
Hi Laurent,
On Thu, Sep 05, 2019 at 02:17:12PM +0300, Laurent Pinchart wrote:
> Hi Jacopo,
>
> > +/**
> > + * rcar_cmm_enable() - enable the CMM unit
> > + *
> > + * @pdev: The platform device associated with the CMM instance
> > + *
> > + * Enable the CMM unit by ena
Page fault handler inside vgem driver now preallocates pages in advance
when fault occurs for the first time. Pages can be allocated in
direction of increasing/decreasing addresses, depending on memory access
profile. In case of random access no preallocation occurs.
Synthetic benchmark showed ove
On 05/09/2019 13:40, Mark Brown wrote:
> On Thu, Sep 05, 2019 at 10:37:53AM +0100, Steven Price wrote:
>
>> Ah, I didn't realise that regulator_get() will return a dummy regulator
>> if none is provided in the DT. In theory that seems like a nicer
>> solution to my two commits. However there's sti
From: Thomas Hellström
Dave, Daniel
A single fix from Dan for a previous fix that generated a regression.
The following changes since commit 6b7c3b86f0b63134b2ab56508921a0853ffa687a:
drm/vmwgfx: fix memory leak when too many retries have occurred (2019-08-08
11:22:54 +0200)
are available
Thank you for the review Andrzej. I'll update the patch to v2 shortly, it should
cover all your comments.
FYI, I'll be on holiday until September 16 so I might not be able to respond in
the
following days.
Regards,
Szymon
On 03.09.2019 15:19, Andrzej Hajda wrote:
> +CC: $(./script/get_maintaine
On Thu, Sep 05, 2019 at 10:37:53AM +0100, Steven Price wrote:
> Ah, I didn't realise that regulator_get() will return a dummy regulator
> if none is provided in the DT. In theory that seems like a nicer
> solution to my two commits. However there's still a problem - the dummy
> regulator returned
On 05.09.19 10:14, Gerd Hoffmann wrote:
> On Tue, Aug 06, 2019 at 09:00:10PM +0300, Jaak Ristioja wrote:
>> Hello!
>>
>> I'm writing to report a crash in the QXL / DRM code in the Linux kernel.
>> I originally filed the issue on LaunchPad and more details can be found
>> there, although I doubt whe
On Wed, Sep 4, 2019 at 2:57 PM Kazlauskas, Nicholas
wrote:
>
> On 2019-09-03 3:06 p.m., Daniel Vetter wrote:
> > It's the only flag anyone actually cares about. Plus if we're unlucky,
> > the atomic ioctl might need a different flag for async flips. So
> > better to abstract this away from the uap
Hi Daniel, hi Dave,
a single fix for a error path issue in the newly introduced per-process
address space code.
Regards,
Lucas
The following changes since commit 578d2342ec702e5fb8a77983fabb3754ae3e9660:
Merge tag 'drm-next-5.4-2019-08-23' of
git://people.freedesktop.org/~agd5f/linux into d
Move the static keyword to the front of declaration of modes,
and resolve the following compiler warning that can be seen
when building with warnings enabled (W=1):
drivers/gpu/drm/exynos/exynos_mixer.c:1074:2: warning:
‘static’ is not at beginning of declaration [-Wold-style-declaration]
Signe
From: Ville Syrjälä
Add a function to fill the AVI infoframe bar information from
the standard tv margin properties.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_edid.c | 17 +
include/drm/drm_edid.h | 4
2 files changed, 21 insertions(+)
diff --git a/drivers
Hi Geert,
On Thu, Sep 05, 2019 at 02:05:34PM +0200, Geert Uytterhoeven wrote:
> On Thu, Sep 5, 2019 at 1:50 PM Laurent Pinchart wrote:
> > On Fri, Aug 30, 2019 at 08:01:09PM +0200, Jacopo Mondi wrote:
> > > On Mon, Aug 26, 2019 at 01:15:50PM +0300, Laurent Pinchart wrote:
> > > > How about convert
On Tue, Sep 3, 2019 at 4:38 PM Stephan Gerhold wrote:
> On Tue, Sep 03, 2019 at 11:15:12AM +0200, Linus Walleij wrote:
> > /*
> >* This is the time to perform LP->HS on D-PHY
> >* FIXME: nowhere to get this from: DT property on the DSI?
> > + * values like 48 and 72 see
When handling a GPU page fault addr_to_drm_mm_node() is used to
translate the GPU address to a buffer object. However it is possible for
the buffer object to be freed after the function has returned resulting
in a use-after-free of the BO.
Change addr_to_drm_mm_node to return the panfrost_gem_obje
https://bugzilla.kernel.org/show_bug.cgi?id=204683
--- Comment #6 from Matthias Heinz (m...@familie-heinz.name) ---
I had to switch to drm-next to do further bisecting and I think
634092b1b9f67bea23a87b77880df5e8012a411a is causing the problem.
I might be wrong though.
--
You are receiving this
Hi Laurent,
On Thu, Sep 5, 2019 at 1:50 PM Laurent Pinchart
wrote:
> On Fri, Aug 30, 2019 at 08:01:09PM +0200, Jacopo Mondi wrote:
> > On Mon, Aug 26, 2019 at 01:15:50PM +0300, Laurent Pinchart wrote:
> > > How about converting this binding to yaml alreay ? It should be fairly
> > > simple.
> >
>
On Thu, 2019-08-15 at 09:38 +0100, Colin Ian King wrote:
> On 15/08/2019 09:30, Dan Carpenter wrote:
> > We recently added a kfree() after the end of the loop:
> >
> > if (retries == RETRIES) {
> > kfree(reply);
> > return -EINVAL;
> > }
> >
> > There are two probl
https://bugs.freedesktop.org/show_bug.cgi?id=111481
--- Comment #30 from Mathieu Belanger ---
I will disable the workaround friday after work.
Then I will report when it will crash.
--
You are receiving this mail because:
You are the assignee for the bug.___
Hi Jacopo,
On Fri, Aug 30, 2019 at 08:01:09PM +0200, Jacopo Mondi wrote:
> On Mon, Aug 26, 2019 at 01:15:50PM +0300, Laurent Pinchart wrote:
> > On Mon, Aug 26, 2019 at 09:59:43AM +0200, Jacopo Mondi wrote:
> >> On Mon, Aug 26, 2019 at 09:34:41AM +0200, Geert Uytterhoeven wrote:
> >>> On Sun, Aug
Hi Jacopo,
On Thu, Sep 05, 2019 at 12:58:09PM +0200, Jacopo Mondi wrote:
> On Tue, Aug 27, 2019 at 03:05:17AM +0300, Laurent Pinchart wrote:
> > Hi Jacopo,
> >
> > (Question for Daniel below)
> >
> > Thank you for the patch.
> >
> > On Sun, Aug 25, 2019 at 03:51:54PM +0200, Jacopo Mondi wrote:
> >
1 - 100 of 170 matches
Mail list logo
