Hi Jeykumar,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on robclark/msm-next]
[also build test ERROR on v4.20-rc4 next-20181130]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci
https://bugs.freedesktop.org/show_bug.cgi?id=108814
Domen changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On Fri, Nov 30, 2018 at 08:39:01PM +, Abuse wrote:
> On Friday, 30 November 2018 20:35:07 GMT David Miller wrote:
> > From: Jens Axboe
> > Date: Fri, 30 Nov 2018 13:12:26 -0700
> >
> > > On 11/30/18 12:56 PM, Davidlohr Bueso wrote:
> > >> On Fri, 30 Nov 2018, Kees Cook wrote:
> > >>
> > >>>
On Fri, Nov 30, 2018 at 06:14:17PM -0800, Brendan Higgins wrote:
> On Thu, Nov 29, 2018 at 7:29 PM Luis Chamberlain wrote:
> >
> > On Wed, Nov 28, 2018 at 11:36:20AM -0800, Brendan Higgins wrote:
> > > A number of test features need to do pretty complicated string printing
> > > where it may not
On Fri, Nov 30, 2018 at 06:08:36PM -0800, Brendan Higgins wrote:
> On Thu, Nov 29, 2018 at 7:28 PM Luis Chamberlain wrote:
> >
> > > +static void kunit_run_case_internal(struct kunit *test,
> > > + struct kunit_module *module,
> > > +
On Wed, Nov 28, 2018 at 11:36:18AM -0800, Brendan Higgins wrote:
> +int kunit_run_tests(struct kunit_module *module)
> +{
> + bool all_passed = true, success;
> + struct kunit_case *test_case;
> + struct kunit test;
> + int ret;
> +
> + ret = kunit_init_test(, module->name);
>
On Fri, Nov 30, 2018 at 05:51:11PM -0800, Brendan Higgins wrote:
> On Thu, Nov 29, 2018 at 7:14 PM Luis Chamberlain wrote:
> >
> > On Wed, Nov 28, 2018 at 11:36:18AM -0800, Brendan Higgins wrote:
> > > +#define module_test(module) \
> > > + static int module_kunit_init##module(void) \
On Thu, Nov 29, 2018 at 4:23 PM Tomasz Figa wrote:
>
> On Thu, Nov 29, 2018 at 12:03 PM Robin Murphy wrote:
> >
> > On 29/11/2018 19:57, Tomasz Figa wrote:
> > > On Thu, Nov 29, 2018 at 11:40 AM Jordan Crouse
> > > wrote:
> > >>
> > >> On Thu, Nov 29, 2018 at 01:48:15PM -0500, Rob Clark wrote:
Right now, userspace doesn't do any L2T writes, but we should lay out
our expectations for how it works.
Signed-off-by: Eric Anholt
---
include/uapi/drm/v3d_drm.h | 7 +++
1 file changed, 7 insertions(+)
diff --git a/include/uapi/drm/v3d_drm.h b/include/uapi/drm/v3d_drm.h
index
The core scheduler tells us when the job is pushed to the scheduler's
queue, and I had the job_run functions saying when they actually queue
the job to the hardware. By adding tracepoints for the very top of
the ioctls and the IRQs signaling job completion, "perf record -a -e
v3d:.\* -e
We shouldn't be returning v3d-render in for our new queue.
Signed-off-by: Eric Anholt
Fixes: 83d5139982db ("drm/v3d: Add support for submitting jobs to the TFU.")
---
drivers/gpu/drm/v3d/v3d_fence.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git
Now that I've specified how the end-of-pipeline flushing should work,
we're never going to use this function.
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/v3d/v3d_drv.h | 1 -
drivers/gpu/drm/v3d/v3d_gem.c | 21 -
2 files changed, 22 deletions(-)
diff --git
According to Dave, once you've started an L2T flush, all L2T accesses
will be blocked until the flush completes. This fixes a consistent
3-4ms stall between the ioctl and running the job, and 3DMMES Taiji
goes from 27fps to 110fps.
Signed-off-by: Eric Anholt
Fixes: 57692c94dcbe ("drm/v3d:
This is the write combiner for TMU writes. You're supposed to flush
that at job end if you had dirtied any cachelines. Flushing it at job
start then doesn't make any sense.
Signed-off-by: Eric Anholt
Fixes: 57692c94dcbe ("drm/v3d: Introduce a new DRM driver for Broadcom V3D
V3.x+")
---
Add 'xo_board' as ref clock for the DSI PHYs, it was previously
hardcoded in the PLL 'driver' for the 28nm PHY.
Signed-off-by: Matthias Kaehlcke
Reviewed-by: Douglas Anderson
---
Changes in v3:
- added 'Reviewed-by: Douglas Anderson ' tag
Changes in v2:
- patch added to the series
---
Allow the PHY drivers to get the ref clock from the DT.
Signed-off-by: Matthias Kaehlcke
---
Changes in V3:
- added note that the ref clock is only required for new DTS
files/entries
Changes in v2:
- add the ref clock for all PHYs, not only the 10nm one
- updated commit message
---
Add 'bi_tcxo' as ref clock for the DSI PHYs, it was previously
hardcoded in the PLL 'driver' for the 10nm PHY.
Signed-off-by: Matthias Kaehlcke
Reviewed-by: Douglas Anderson
---
based on "[v4,1/3] arm64: dts: qcom: sdm845: Add dpu to sdm845 dts file"
Add 'xo_board' as ref clock for the DSI PHY, it was previously
hardcoded in the PLL 'driver' for the 28nm 8960 PHY.
Signed-off-by: Matthias Kaehlcke
---
Changes in v3:
- patch added to the series
---
arch/arm/boot/dts/qcom-apq8064.dtsi | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
Get the ref clock of the PHY from the device tree instead of
hardcoding its name and rate. Use default values if the ref
clock is not specified.
Signed-off-by: Matthias Kaehlcke
---
Changes in v3:
- use default name and rate if the ref clock is not specified
in the DT
- store vco_ref_clk_name
Get the ref clock of the PHY from the device tree instead of
hardcoding its name and rate.
Note: This change could break old out-of-tree DTS files that
use the 10nm PHY
Signed-off-by: Matthias Kaehlcke
Reviewed-by: Douglas Anderson
---
Changes in v3:
- fixed check for EPROBE_DEFER
- added note
Get the ref clock of the PHY from the device tree instead of
hardcoding its name and rate. Use default values if the ref
clock is not specified.
Signed-off-by: Matthias Kaehlcke
---
Changes in v3:
- use default name and rate if the ref clock is not specified
in the DT
- store vco_ref_clk_name
The MSM DSI PHY drivers currently hardcode the name and the rate of
the PHY ref clock. Get the ref clock from the device tree instead.
Note: testing of this series was limited to SDM845 and the 10nm PHY
Major changes in v3:
- keep supporting DTs without ref clock for the 28nm and the 28nm
8960
Get the ref clock of the PHY from the device tree instead of
hardcoding its name and rate.
Note: This change could break old out-of-tree DTS files that
use the 14nm PHY.
Signed-off-by: Matthias Kaehlcke
Reviewed-by: Douglas Anderson
---
Changes in v3:
- fixed check for EPROBE_DEFER
- added
On Thu, 2018-11-29 at 18:25 -0800, José Roberto de Souza wrote:
> Selective updates have a default granularity requirements as stated
> by eDP spec
Needs reference to the location in the spec.
> , so check if HW can match those requirements before
> enable PSR2.
typo: enabling*
>
> Cc:
On 2018-11-30 12:07, Sean Paul wrote:
On Fri, Nov 30, 2018 at 11:45:55AM -0800, Jeykumar Sankaran wrote:
On 2018-11-29 14:15, Sean Paul wrote:
> On Tue, Nov 20, 2018 at 02:04:14PM -0800, Jeykumar Sankaran wrote:
> > On 2018-11-07 07:55, Sean Paul wrote:
> > > On Tue, Nov 06, 2018 at 02:36:30PM
On Thu, 2018-11-29 at 18:25 -0800, José Roberto de Souza wrote:
> Source is required to comply to sink SU granularity when
> DP_PSR2_SU_GRANULARITY_REQUIRED is set in DP_PSR_CAPS,
> so adding the registers offsets.
>
> v2: Also adding DP_PSR2_SU_Y_GRANULARITY(Rodrigo)
>
> Cc: Dhinakaran Pandiyan
On Thu, 2018-11-29 at 18:25 -0800, José Roberto de Souza wrote:
> eDP spec states 2 different bits to enable sink to trigger a
> interruption when there is a CRC mismatch.
> DP_PSR_CRC_VERIFICATION is for PSR only and
> DP_PSR_IRQ_HPD_WITH_CRC_ERRORS is for PSR2 only.
With PSR short pulse
On Thu, 2018-11-29 at 18:25 -0800, José Roberto de Souza wrote:
> As we have a else block for the 'if (dev_priv->psr.psr2_enabled) {'
> and this bit is only set for PSR1 move it to that block to make it
> more easy to read.
>
> Cc: Dhinakaran Pandiyan
> Cc: Rodrigo Vivi
> Signed-off-by: José
On Thu, 2018-11-29 at 18:25 -0800, José Roberto de Souza wrote:
> For PSR2 there is no register to tell HW to keep main link enabled
Right, there is no bit in PSR2_CTL
Reviewed-by: Dhinakaran Pandiyan
> while PSR2 is active, so don't configure sink DPCD with a
> misleading value.
>
> v2:
On Thu, 2018-11-29 at 18:25 -0800, José Roberto de Souza wrote:
> i915 yet don't support PSR in Apple panels, so lets keep it disabled
> while we work on that.
>
> v2: Renamed DP_DPCD_QUIRK_PSR_NOT_CURRENTLY_SUPPORTED to
> DP_DPCD_QUIRK_NO_PSR (Ville)
>
> Fixes: 598c6cfe0690 (drm/i915/psr:
On Fri, Nov 30, 2018 at 02:40:19PM -0800, Jarkko Sakkinen wrote:
> Got you... Well I now read the 2nd amendment now through, and yeah, kind
> of way I work/function anyway.
Ugh, looked up the word from dictionary for something that makes
additions to some guidelines because did not know the
On Fri, Nov 30, 2018 at 11:22 PM Rob Herring wrote:
>
> On Fri, Nov 30, 2018 at 2:53 PM Daniel Vetter wrote:
> >
> > On Fri, Nov 30, 2018 at 9:32 PM Rob Herring wrote:
> > >
> > > This adds a GitLab CI config file running the DT unittest in a usermode
> > > Linux build. The corresponding CI job
On Fri, Nov 30, 2018 at 2:34 PM Logan Gunthorpe wrote:
>
>
>
> On 2018-11-30 3:28 p.m., Dan Williams wrote:
> > On Fri, Nov 30, 2018 at 2:19 PM Logan Gunthorpe wrote:
> >>
> >> Hey,
> >>
> >> On 2018-11-29 11:51 a.m., Dan Williams wrote:
> >>> Got it, let me see how bad moving
On Fri, Nov 30, 2018 at 02:30:45PM -0800, James Bottomley wrote:
> On Fri, 2018-11-30 at 14:26 -0800, Jarkko Sakkinen wrote:
> > On Fri, Nov 30, 2018 at 03:14:59PM -0700, Jonathan Corbet wrote:
> [...]
> > > Have you read Documentation/process/code-of-conduct-
> > > interpretation.rst?
> > > As
On Tue, Nov 27, 2018 at 10:00:50PM -0800, Doug Anderson wrote:
> Hi,
>
> On Mon, Nov 26, 2018 at 3:12 PM Matthias Kaehlcke wrote:
> > @@ -409,8 +410,9 @@ static void dsi_pll_28nm_destroy(struct msm_dsi_pll
> > *pll)
> > static int pll_28nm_register(struct dsi_pll_28nm *pll_28nm)
> > {
> >
On Fri, 2018-11-30 at 14:26 -0800, Jarkko Sakkinen wrote:
> On Fri, Nov 30, 2018 at 03:14:59PM -0700, Jonathan Corbet wrote:
[...]
> > Have you read Documentation/process/code-of-conduct-
> > interpretation.rst?
> > As has been pointed out, it contains a clear answer to how things
> > should be
On Fri, Nov 30, 2018 at 02:26:05PM -0800, Jarkko Sakkinen wrote:
> On Fri, Nov 30, 2018 at 03:14:59PM -0700, Jonathan Corbet wrote:
> > On Fri, 30 Nov 2018 14:12:19 -0800
> > Jarkko Sakkinen wrote:
> >
> > > As a maintainer myself (and based on somewhat disturbed feedback from
> > > other
On Fri, Nov 30, 2018 at 2:19 PM Logan Gunthorpe wrote:
>
> Hey,
>
> On 2018-11-29 11:51 a.m., Dan Williams wrote:
> > Got it, let me see how bad moving arch_remove_memory() turns out,
> > sounds like a decent approach to coordinate multiple users of a single
> > ref.
>
> I've put together a patch
On Fri, 2018-11-30 at 14:12 -0800, Jarkko Sakkinen wrote:
[...]
> I pasted this already to another response and this was probably the
> part that ignited me to send the patch set (was a few days ago, so
> had to revisit to find the exact paragraph):
I replied in to the other thread.
>
On Fri, Nov 30, 2018 at 03:14:59PM -0700, Jonathan Corbet wrote:
> On Fri, 30 Nov 2018 14:12:19 -0800
> Jarkko Sakkinen wrote:
>
> > As a maintainer myself (and based on somewhat disturbed feedback from
> > other maintainers) I can only make the conclusion that nobody knows what
> > the
On Wed, Nov 28, 2018 at 07:46:06PM +, Ho, Kenny wrote:
>
> On Wed, Nov 28, 2018 at 4:14 AM Joonas Lahtinen
> wrote:
> > So we can only choose the lowest common denominator, right?
> >
> > Any core count out of total core count should translate nicely into a
> > fraction, so what would be
On Fri, Nov 30, 2018 at 2:53 PM Daniel Vetter wrote:
>
> On Fri, Nov 30, 2018 at 9:32 PM Rob Herring wrote:
> >
> > This adds a GitLab CI config file running the DT unittest in a usermode
> > Linux build. The corresponding CI job can be found here:
> >
> >
Hi,
Missatge de Enric Balletbo i Serra del
dia dc., 7 de nov. 2018 a les 9:56:
>
> Commit '88ba95bedb79 ("backlight: pwm_bl: Compute brightness of LED
> linearly to human eye")' allows the possibility to compute a default
> brightness table when there isn't the brightness-levels property in the
>
On Tue, Nov 27, 2018 at 09:56:46PM -0800, Doug Anderson wrote:
> Hi,
>
> On Mon, Nov 26, 2018 at 3:12 PM Matthias Kaehlcke wrote:
> >
> > Get the ref clock of the PHY from the device tree instead of
> > hardcoding its name and rate.
>
> In the case of the 14nm PHY I think it's OK that you break
On Tue, Nov 27, 2018 at 09:41:39PM -0800, Doug Anderson wrote:
> Hi,
>
> On Mon, Nov 26, 2018 at 3:12 PM Matthias Kaehlcke wrote:
> >
> > Allow the PHY drivers to get the ref clock from the DT.
> >
> > Signed-off-by: Matthias Kaehlcke
> > ---
> > Changes in v2:
> > - add the ref clock for all
On Fri, 30 Nov 2018 14:12:19 -0800
Jarkko Sakkinen wrote:
> As a maintainer myself (and based on somewhat disturbed feedback from
> other maintainers) I can only make the conclusion that nobody knows what
> the responsibility part here means.
>
> I would interpret, if I read it like at lawyer
On Fri, Nov 30, 2018 at 01:57:49PM -0800, James Bottomley wrote:
> On Fri, 2018-11-30 at 13:44 -0800, Jarkko Sakkinen wrote:
> > On Fri, Nov 30, 2018 at 01:01:02PM -0800, James Bottomley wrote:
> > > No because use of what some people consider to be bad language
> > > isn't necessarily abusive,
On Fri, 2018-11-30 at 13:54 -0800, Jarkko Sakkinen wrote:
> On Fri, Nov 30, 2018 at 01:48:08PM -0800, David Miller wrote:
> > From: Jarkko Sakkinen
> > Date: Fri, 30 Nov 2018 13:44:05 -0800
> >
> > > On Fri, Nov 30, 2018 at 01:01:02PM -0800, James Bottomley wrote:
> > > > No because use of what
From: Sean Paul
This patch wraps dpu_core_perf_crtc_release_bw() with modeset locks
since it digs into the state objects.
Changes in v2:
- None
Changes in v3:
- Use those nifty new DRM_MODESET_LOCK_ALL_* helpers (Daniel)
Cc: Daniel Vetter
Cc: Jeykumar Sankaran
Signed-off-by: Sean Paul
---
On Fri, 2018-11-30 at 13:44 -0800, Jarkko Sakkinen wrote:
> On Fri, Nov 30, 2018 at 01:01:02PM -0800, James Bottomley wrote:
> > No because use of what some people consider to be bad language
> > isn't necessarily abusive, offensive or degrading. Our most
> > heavily censored medium is TV and
From: Jarkko Sakkinen
Date: Fri, 30 Nov 2018 13:42:33 -0800
> Can you tell how the CoC should be interpreted then?
Regardless of what I think, as others have showen the CoC explicitly
does not apply to existing code.
___
dri-devel mailing list
On Fri, Nov 30, 2018 at 01:48:08PM -0800, David Miller wrote:
> From: Jarkko Sakkinen
> Date: Fri, 30 Nov 2018 13:44:05 -0800
>
> > On Fri, Nov 30, 2018 at 01:01:02PM -0800, James Bottomley wrote:
> >> No because use of what some people consider to be bad language isn't
> >> necessarily abusive,
From: Jarkko Sakkinen
Date: Fri, 30 Nov 2018 13:44:05 -0800
> On Fri, Nov 30, 2018 at 01:01:02PM -0800, James Bottomley wrote:
>> No because use of what some people consider to be bad language isn't
>> necessarily abusive, offensive or degrading. Our most heavily censored
>> medium is TV and
On Fri, Nov 30, 2018 at 01:01:02PM -0800, James Bottomley wrote:
> No because use of what some people consider to be bad language isn't
> necessarily abusive, offensive or degrading. Our most heavily censored
> medium is TV and "fuck" is now considered acceptable in certain
> contexts on most
On Fri, Nov 30, 2018 at 12:35:07PM -0800, David Miller wrote:
> From: Jens Axboe
> Date: Fri, 30 Nov 2018 13:12:26 -0700
>
> > On 11/30/18 12:56 PM, Davidlohr Bueso wrote:
> >> On Fri, 30 Nov 2018, Kees Cook wrote:
> >>
> >>> On Fri, Nov 30, 2018 at 11:27 AM Jarkko Sakkinen
> >>> wrote:
>
On Fri, Nov 30, 2018 at 08:42:23PM +, Chris Mason wrote:
> I think the bar for changing the documentation/comments should be
> improvement in the clarity or approachability of whatever is being
> changed.
>
> This patch set is kind of like Linus sitting at kernel summit with a
> sign that
On Fri, Nov 30, 2018 at 09:31:13PM +0100, Matthias Brugger wrote:
> Like John I don't think that the word "fuck" is something we have to ban from
> the source code, but I don't care too much. Anyway, please don't change it to
> something like heck as it might be difficult for non-english speaker
On Fri, Nov 30, 2018 at 09:09:48PM +0100, John Paul Adrian Glaubitz wrote:
> Or just leave it as is because we're all grown up and don't freak out
> when a piece of text contains the word "fuck".
>
> I still don't understand why people think that the word "fuck" is what
> would keep certain
On Fri, Nov 30, 2018 at 06:13:50PM -0200, Diego Viola wrote:
> On Fri, Nov 30, 2018 at 5:30 PM Jarkko Sakkinen
> wrote:
> >
> > In order to comply with the CoC, replace with a hug.
> >
> > Signed-off-by: Jarkko Sakkinen
> > ---
> > drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c| 2
I'll check on it.
> -Original Message-
> From: Souza, Jose
> Sent: Thursday, 29 November, 2018 3:47 PM
> To: Vivi, Rodrigo
> Cc: dri-devel@lists.freedesktop.org; intel-...@lists.freedesktop.org;
> Runyan, Arthur J ; Pandiyan, Dhinakaran
>
> Subject: Re: [PATCH 4/9] drm/i915/icl: Do not
On Fri, 2018-11-30 at 12:55 -0800, Jarkko Sakkinen wrote:
> On Fri, Nov 30, 2018 at 11:56:52AM -0800, Davidlohr Bueso wrote:
> > On Fri, 30 Nov 2018, Kees Cook wrote:
> >
> > > On Fri, Nov 30, 2018 at 11:27 AM Jarkko Sakkinen
> > > wrote:
> > > >
> > > > In order to comply with the CoC, replace
On Fri, Nov 30, 2018 at 11:40:17AM -0800, Kees Cook wrote:
> On Fri, Nov 30, 2018 at 11:27 AM Jarkko Sakkinen
> wrote:
> >
> > In order to comply with the CoC, replace with a hug.
>
> Heh. I support the replacement of the stronger language, but I find
> "hug", "hugged", and "hugging" to be
On Fri, 30 Nov 2018 12:55:21 -0800
Jarkko Sakkinen wrote:
> This a direct quote from the CoC:
>
> "Harassment includes the use of abusive, offensive or degrading
> language, intimidation, stalking, harassing photography or recording,
> inappropriate physical contact, sexual imagery and
On Fri, 30 Nov 2018 12:55:21 -0800
Jarkko Sakkinen wrote:
> On Fri, Nov 30, 2018 at 11:56:52AM -0800, Davidlohr Bueso wrote:
> > On Fri, 30 Nov 2018, Kees Cook wrote:
> >
> > > On Fri, Nov 30, 2018 at 11:27 AM Jarkko Sakkinen
> > > wrote:
> > > >
> > > > In order to comply with the CoC,
On Fri, Nov 30, 2018 at 11:56:52AM -0800, Davidlohr Bueso wrote:
> On Fri, 30 Nov 2018, Kees Cook wrote:
>
> > On Fri, Nov 30, 2018 at 11:27 AM Jarkko Sakkinen
> > wrote:
> > >
> > > In order to comply with the CoC, replace with a hug.
>
> I hope this is some kind of joke. How would
On Fri, Nov 30, 2018 at 9:32 PM Rob Herring wrote:
>
> This adds a GitLab CI config file running the DT unittest in a usermode
> Linux build. The corresponding CI job can be found here:
>
> https://gitlab.com/robherring/linux-dt-unittest/pipelines
>
> This CI job can be duplicated by others by
From: Jens Axboe
Date: Fri, 30 Nov 2018 13:12:26 -0700
> On 11/30/18 12:56 PM, Davidlohr Bueso wrote:
>> On Fri, 30 Nov 2018, Kees Cook wrote:
>>
>>> On Fri, Nov 30, 2018 at 11:27 AM Jarkko Sakkinen
>>> wrote:
In order to comply with the CoC, replace with a hug.
>>
>> I hope
On Fri, 30 Nov 2018 20:39:01 +
Abuse wrote:
> On Friday, 30 November 2018 20:35:07 GMT David Miller wrote:
> > From: Jens Axboe
> > Date: Fri, 30 Nov 2018 13:12:26 -0700
> >
> > > On 11/30/18 12:56 PM, Davidlohr Bueso wrote:
> > >> On Fri, 30 Nov 2018, Kees Cook wrote:
> > >>
> >
From: Abuse
Date: Fri, 30 Nov 2018 20:39:01 +
> I assume I will now be barred.
Perhaps, but not because you said fuck. It would be because you're
intentionally creating a disturbance on the list and making it more
difficult for developers to get their work done and intentionally
creating a
From: Davidlohr Bueso
Date: Fri, 30 Nov 2018 11:56:52 -0800
> I hope this is some kind of joke.
Whether or not it is a joke, it is censorship.
And because of that I have no intention to apply any patches like this
to any code I am in charge of.
___
Paul Kocialkowski writes:
> In order to test whether the load tracker is working as expected, we
> need the ability to compare the commit result with the underrun
> indication. With the load tracker always enabled, commits that are
> expected to trigger an underrun are always rejected, so
On Fri, Nov 30, 2018 at 11:45:55AM -0800, Jeykumar Sankaran wrote:
> On 2018-11-29 14:15, Sean Paul wrote:
> > On Tue, Nov 20, 2018 at 02:04:14PM -0800, Jeykumar Sankaran wrote:
> > > On 2018-11-07 07:55, Sean Paul wrote:
> > > > On Tue, Nov 06, 2018 at 02:36:30PM -0800, Jeykumar Sankaran wrote:
>
On 2018-11-29 14:15, Sean Paul wrote:
On Tue, Nov 20, 2018 at 02:04:14PM -0800, Jeykumar Sankaran wrote:
On 2018-11-07 07:55, Sean Paul wrote:
> On Tue, Nov 06, 2018 at 02:36:30PM -0800, Jeykumar Sankaran wrote:
> > msm maintains a separate structure to define vblank
> > work definitions and a
tree: git://people.freedesktop.org/~agd5f/linux.git drm-next-4.21
head: 2c486cc4c2774df684d8a43ca7a20670c67ccd76
commit: 062f380725376efab279956b5441071684c2a7ff [68/92] drm/amdgpu: Vega10
doorbell index initialization
config: x86_64-randconfig-x002-201847 (attached as .config)
compiler:
In order to comply with the CoC, replace with a hug.
Jarkko Sakkinen (15):
MIPS: replace with a hug
Documentation: replace with a hug
drm/nouveau: replace with a hug
m68k: replace with a hug
parisc: replace with a hug
cpufreq: replace with a hug
In order to comply with the CoC, replace with a hug.
Signed-off-by: Jarkko Sakkinen
---
drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c| 2 +-
drivers/gpu/drm/nouveau/nvkm/subdev/pmu/fuc/macros.fuc | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git
Hi Dave,
More new features for 4.21:
amdgpu and amdkfd:
- Freesync support
- ABM support in DC
- KFD support for vega12 and polaris12
- Add sdma paging queue support for vega
- Use ACPI to query backlight range on supported platforms
- Clean up doorbell handling
- KFD fix for pasid handling
On Fri, 30 Nov 2018 17:11:04 +0100
Paul Kocialkowski wrote:
> In order to test whether the load tracker is working as expected, we
> need the ability to compare the commit result with the underrun
> indication. With the load tracker always enabled, commits that are
> expected to trigger an
The pull request you sent on Fri, 30 Nov 2018 13:11:42 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2018-11-30
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/570a37437cf24790d77fed6a59fdc9ac749e6b19
Thank you!
--
Deet-doot-dot, I am a bot.
On Fri, Nov 30, 2018 at 08:05:34AM -0600, Rob Herring wrote:
> On Thu, Nov 29, 2018 at 9:37 PM Luis Chamberlain wrote:
> >
> > On Wed, Nov 28, 2018 at 03:26:03PM -0600, Rob Herring wrote:
> > > On Wed, Nov 28, 2018 at 1:37 PM Brendan Higgins
> > > wrote:
> > > >
> > > > Make minimum number of
https://bugzilla.kernel.org/show_bug.cgi?id=201497
--- Comment #3 from Daniel Andersson (engyw...@gmail.com) ---
Any progress on this issue?
--
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
https://bugs.freedesktop.org/show_bug.cgi?id=92936
Andy Furniss changed:
What|Removed |Added
Resolution|--- |WORKSFORME
Status|REOPENED
https://bugs.freedesktop.org/show_bug.cgi?id=104391
--- Comment #9 from Andy Furniss ---
I have a new TV now and can't get hdmi audio working at all.
Maybe my use/setup of alsa doesn't help, but IIRC I did try and fail with a
fedora live USB as well.
It works perfectly if I boot into Windows
Hi,
I will be traveling / busy with other things / without access to my
development setup till 20.12. When I'm back I will handle the rest of
pending v4.21 changes, sorry for the inconvenience.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics
Hi,
On Fri, Nov 30, 2018 at 04:34:54PM +0100, Hans Verkuil wrote:
> On 11/30/18 16:16, Ville Syrjälä wrote:
> > On Fri, Nov 30, 2018 at 03:48:00PM +0100, Hans Verkuil wrote:
> >> On 11/30/18 15:29, Ville Syrjälä wrote:
> >>> On Fri, Nov 30, 2018 at 03:20:59PM +0100, Andrzej Hajda wrote:
> Hi
In order to test whether the load tracker is working as expected, we
need the ability to compare the commit result with the underrun
indication. With the load tracker always enabled, commits that are
expected to trigger an underrun are always rejected, so userspace
cannot get the actual underrun
https://bugs.freedesktop.org/show_bug.cgi?id=108689
--- Comment #3 from Alex <3.1...@ukr.net> ---
Any news?
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
On Fri, Nov 30, 2018 at 02:57:45PM +0530, Sandeep Panda wrote:
> Fix the AUX_CMD_SEND bit for ti,sn65dsi86 bridge chip. With wrong
> value the dpcd aux transactions with eDP panel are failing.
>
> Signed-off-by: Sandeep Panda
Pushed to -misc-fixes, thanks for the patch
Sean
> ---
>
On Fri, Nov 30, 2018 at 10:36 AM Arnd Bergmann wrote:
>
> On Fri, Nov 30, 2018 at 4:31 PM Rob Clark wrote:
> >
> > On Fri, Nov 30, 2018 at 10:12 AM Arnd Bergmann wrote:
> > >
> > > On Fri, Nov 30, 2018 at 4:02 PM Rob Clark wrote:
> > > >
> > > > Signed-off-by: Rob Clark
> > > > ---
> > > >
On Thu, Nov 29, 2018 at 10:36:13AM -0500, Sean Paul wrote:
> On Wed, Nov 28, 2018 at 5:07 AM Daniel Vetter wrote:
> >
> > I've misplaced two functions by accident:
> > - drm_atomic_helper_duplicate_state is really part of the
> > resume/suspend/shutdown device-wide helpers.
> > -
On Fri, Nov 30, 2018 at 4:31 PM Rob Clark wrote:
>
> On Fri, Nov 30, 2018 at 10:12 AM Arnd Bergmann wrote:
> >
> > On Fri, Nov 30, 2018 at 4:02 PM Rob Clark wrote:
> > >
> > > Signed-off-by: Rob Clark
> > > ---
> > > drivers/gpu/drm/msm/msm_drv.c | 4 +++-
> > > 1 file changed, 3
On 11/30/18 16:16, Ville Syrjälä wrote:
> On Fri, Nov 30, 2018 at 03:48:00PM +0100, Hans Verkuil wrote:
>> On 11/30/18 15:29, Ville Syrjälä wrote:
>>> On Fri, Nov 30, 2018 at 03:20:59PM +0100, Andrzej Hajda wrote:
Hi Ville,
As Christoph cannot respond till middle next week I can try
On Fri, Nov 30, 2018 at 10:12 AM Arnd Bergmann wrote:
>
> On Fri, Nov 30, 2018 at 4:02 PM Rob Clark wrote:
> >
> > Signed-off-by: Rob Clark
> > ---
> > drivers/gpu/drm/msm/msm_drv.c | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/msm/msm_drv.c
On Fri, Nov 30, 2018 at 10:14 AM Arnd Bergmann wrote:
>
> On Fri, Nov 30, 2018 at 4:02 PM Rob Clark wrote:
> >
>
> > -
> > -#define MSM_INFO_FLAGS (MSM_INFO_IOVA)
> > +/* Get or set GEM buffer info. The requested value can be passed
> > + * directly in 'value', or for data larger than 64b
https://bugs.freedesktop.org/show_bug.cgi?id=108912
--- Comment #2 from Samantha McVey ---
Nicholas,
That patch seems to resolve the issue.
--
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=107690
--- Comment #17 from Gleb Zasyadko ---
Created attachment 142669
--> https://bugs.freedesktop.org/attachment.cgi?id=142669=edit
dmesg_log_kernel_4.20-rc4_with_HDMI_EDID2.0_OK
Good news! On version 4.20-rc4, my display is finally working in
On Fri, Nov 30, 2018 at 03:48:00PM +0100, Hans Verkuil wrote:
> On 11/30/18 15:29, Ville Syrjälä wrote:
> > On Fri, Nov 30, 2018 at 03:20:59PM +0100, Andrzej Hajda wrote:
> >> Hi Ville,
> >>
> >> As Christoph cannot respond till middle next week I can try to respond
> >> in his absence, as I am
On Fri, Nov 30, 2018 at 4:02 PM Rob Clark wrote:
>
> -
> -#define MSM_INFO_FLAGS (MSM_INFO_IOVA)
> +/* Get or set GEM buffer info. The requested value can be passed
> + * directly in 'value', or for data larger than 64b 'value' is a
> + * pointer to userspace buffer, with 'len' specifying the
On Fri, Nov 30, 2018 at 4:02 PM Rob Clark wrote:
>
> Signed-off-by: Rob Clark
> ---
> drivers/gpu/drm/msm/msm_drv.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
> index 6ebbd5010722..782cc33916d6 100644
https://bugs.freedesktop.org/show_bug.cgi?id=108912
--- Comment #1 from Nicholas Kazlauskas ---
Created attachment 142666
--> https://bugs.freedesktop.org/attachment.cgi?id=142666=edit
0001-drm-amd-display-Fix-NULL-ptr-deref-for-commit_planes.patch
Does this resolve the issue?
--
You are
1 - 100 of 173 matches
Mail list logo
