On 5/2/19 4:45 PM, Brendan Higgins wrote:
> On Thu, May 2, 2019 at 2:16 PM Frank Rowand wrote:
>>
>> On 5/2/19 11:07 AM, Brendan Higgins wrote:
>>> On Thu, May 2, 2019 at 4:02 AM Greg KH wrote:
On Wed, May 01, 2019 at 04:01:21PM -0700, Brendan Higgins wrote:
> From: Felix Guo
>
On Thu, May 2, 2019 at 1:52 PM John Stultz wrote:
>
> We need solutions for the xgettext and the python-mako usage.
Android doesn't support translations at this level, so you may be
able to just skip xgettext altogether.
- Dan
___
dri-devel mailing li
On 05/02/2019 07:16 PM, Matthew Wilcox wrote:
> On Thu, May 02, 2019 at 06:48:46PM +0530, Anshuman Khandual wrote:
>> Drop the pgtable_t variable from all implementation for pte_fn_t as none of
>> them use it. apply_to_pte_range() should stop computing it as well. Should
>> help us save some cycl
> -Original Message-
> From: Greg KH
>
> On Wed, May 01, 2019 at 04:01:25PM -0700, Brendan Higgins wrote:
> > From: Iurii Zaikin
> >
> > KUnit tests for initialized data behavior of proc_dointvec that is
> > explicitly checked in the code. Includes basic parsing tests including
> > int
On Thu, 2 May 2019 06:46:23 -0700
Matthew Wilcox wrote:
> On Thu, May 02, 2019 at 06:48:46PM +0530, Anshuman Khandual wrote:
> > Drop the pgtable_t variable from all implementation for pte_fn_t as none of
> > them use it. apply_to_pte_range() should stop computing it as well. Should
> > help us s
On Thu, May 02, 2019 at 11:19:50AM +0100, Daniel Thompson wrote:
> On 24/04/2019 10:25, Brian Masney wrote:
> > Add fwnode support to the lm3630a driver and optionally allow
> > configuring the label, default brightness level, and maximum brightness
> > level. The two outputs can be controlled by b
On 5/2/19 1:25 PM, Brendan Higgins wrote:
> On Thu, May 2, 2019 at 4:00 AM Greg KH wrote:
>>
>> On Wed, May 01, 2019 at 04:01:13PM -0700, Brendan Higgins wrote:
>>> A lot of the expectation and assertion infrastructure prints out fairly
>>> complicated test failure messages, so add a C++ style log
+ dwillem...@google.com background on the build changes.
Thanks for doing this. It will be helpful to have fixes to make this build
again.
On Thu, May 2, 2019 at 11:03 AM John Stultz wrote:
> Somewhat recent changes in the AOSP build system has been made
> which fairly severely restricts the bu
Am 30.04.19 um 16:40 schrieb Guido Günther:
> This adds support for the Mixel DPHY as found on i.MX8 CPUs but since
> this is an IP core it will likely be found on others in the future. So
> instead of adding this to the nwl host driver make it a generic PHY
> driver.
>
> The driver supports the i
On Thu, May 02, 2019 at 11:07:51AM +0100, Daniel Thompson wrote:
> On 24/04/2019 10:25, Brian Masney wrote:
> > lm3630a_bank_a_update_status() and lm3630a_bank_b_update_status()
> > both return the brightness value if the brightness was successfully
> > updated. Writing to these attributes via sysf
On 5/2/19 11:07 AM, Brendan Higgins wrote:
> On Thu, May 2, 2019 at 4:02 AM Greg KH wrote:
>>
>> On Wed, May 01, 2019 at 04:01:21PM -0700, Brendan Higgins wrote:
>>> From: Felix Guo
>>>
>>> The ultimate goal is to create minimal isolated test binaries; in the
>>> meantime we are using UML to prov
On 2019-05-01 5:01 p.m., Brendan Higgins wrote:
> +/*
> + * struct kunit_try_catch - provides a generic way to run code which might
> fail.
> + * @context: used to pass user data to the try and catch functions.
> + *
> + * kunit_try_catch provides a generic, architecture independent way to
> ex
fyi, John pushed a MR w/ the same patches:
https://gitlab.freedesktop.org/mesa/mesa/merge_requests/795
(I'm not really an expert on android build system, but if it works,
then ack-by from me)
BR,
-R
On Thu, May 2, 2019 at 1:20 PM Greg Hartman wrote:
>
> + dwillem...@google.com background on the
On 2019-05-01 5:01 p.m., Brendan Higgins wrote:
> ## TLDR
>
> I rebased the last patchset on 5.1-rc7 in hopes that we can get this in
> 5.2.
>
As I said on the last posting, I like this and would like to see it move
forward. I still have the same concerns over the downsides of using UML
(ie. n
On Thu, May 02, 2019 at 06:48:46PM +0530, Anshuman Khandual wrote:
> Drop the pgtable_t variable from all implementation for pte_fn_t as none of
> them use it. apply_to_pte_range() should stop computing it as well. Should
> help us save some cycles.
You didn't add Martin Schwidefsky for some reaso
Drop the pgtable_t variable from all implementation for pte_fn_t as none of
them use it. apply_to_pte_range() should stop computing it as well. Should
help us save some cycles.
Signed-off-by: Anshuman Khandual
Cc: Ard Biesheuvel
Cc: Russell King
Cc: Catalin Marinas
Cc: Will Deacon
Cc: Thomas
On Thu, May 2, 2019 at 2:57 PM Dan Willemsen wrote:
>
> On Thu, May 2, 2019 at 1:52 PM John Stultz wrote:
> >
> > We need solutions for the xgettext and the python-mako usage.
>
> Android doesn't support translations at this level, so you may be
> able to just skip xgettext altogether.
>
from q
On Thu, May 2, 2019 at 8:15 PM Logan Gunthorpe wrote:
>
>
>
> On 2019-05-01 5:01 p.m., Brendan Higgins wrote:
> > +/*
> > + * struct kunit_try_catch - provides a generic way to run code which might
> > fail.
> > + * @context: used to pass user data to the try and catch functions.
> > + *
> > + *
On Thu, May 02, 2019 at 11:45:43AM -0700, Brendan Higgins wrote:
> On Thu, May 2, 2019 at 11:15 AM wrote:
> >
> >
> >
> > > -Original Message-
> > > From: Greg KH
> > >
> > > On Wed, May 01, 2019 at 04:01:25PM -0700, Brendan Higgins wrote:
> > > > From: Iurii Zaikin
> > > >
> > > > KUnit
On Thu, May 02, 2019 at 04:45:29PM -0700, Brendan Higgins wrote:
> On Thu, May 2, 2019 at 2:16 PM Frank Rowand wrote:
> >
> > On 5/2/19 11:07 AM, Brendan Higgins wrote:
> > > On Thu, May 2, 2019 at 4:02 AM Greg KH wrote:
> > >>
> > >> On Wed, May 01, 2019 at 04:01:21PM -0700, Brendan Higgins wrot
https://bugs.freedesktop.org/show_bug.cgi?id=100239
--- Comment #20 from network...@rkmail.ru ---
(In reply to Timothy Arceri from comment #19)
> Does that fix the issue for you?
Yes, it does fix scope rendering for me.
Is any negative performance impact to be expected with that flag? Also, is it
On Thu, May 2, 2019 at 6:50 PM shuah wrote:
>
> On 5/1/19 5:01 PM, Brendan Higgins wrote:
< snip >
> > diff --git a/kunit/kunit-stream.c b/kunit/kunit-stream.c
> > new file mode 100644
> > index 0..93c14eec03844
> > --- /dev/null
> > +++ b/kunit/kunit-stream.c
> > @@ -0,0 +1,149 @@
On Thu, May 2, 2019 at 6:45 PM Frank Rowand wrote:
>
> On 5/2/19 4:45 PM, Brendan Higgins wrote:
> > On Thu, May 2, 2019 at 2:16 PM Frank Rowand wrote:
> >>
> >> On 5/2/19 11:07 AM, Brendan Higgins wrote:
> >>> On Thu, May 2, 2019 at 4:02 AM Greg KH wrote:
>
> On Wed, May 01, 2019 at 0
On Thu, May 2, 2019 at 6:27 PM shuah wrote:
>
> On 5/1/19 5:01 PM, Brendan Higgins wrote:
> > Add a test for string stream along with a simpler example.
> >
> > Signed-off-by: Brendan Higgins
> > ---
> > kunit/Kconfig | 12 ++
> > kunit/Makefile | 4 ++
> > kunit
On Thu, May 2, 2019 at 6:26 PM shuah wrote:
>
> On 5/1/19 5:01 PM, Brendan Higgins wrote:
< snip >
> > diff --git a/kunit/Makefile b/kunit/Makefile
> > index 5efdc4dea2c08..275b565a0e81f 100644
> > --- a/kunit/Makefile
> > +++ b/kunit/Makefile
> > @@ -1 +1,2 @@
> > -obj-$(CONFIG_KUNIT) +=
https://bugs.freedesktop.org/show_bug.cgi?id=108893
--- Comment #7 from Timothy Arceri ---
The trace runs perfectly fast. What is the most recent version you have tested
this with? If you are still using 18.2 I would recommend updating to at least
19.0.
--
You are receiving this mail because:
Y
https://bugs.freedesktop.org/show_bug.cgi?id=110143
--- Comment #5 from Timothy Arceri ---
I've remove the regression tag from the bug title as I don't think this ever
worked on Mesa and have sent a patch [1] that should work around some game bugs
in future Mesa releases.
[1] https://patchwork.f
https://bugs.freedesktop.org/show_bug.cgi?id=110143
Timothy Arceri changed:
What|Removed |Added
Summary|[Regression] Doom 3: BFG|Doom 3: BFG Edition - Steam
tree: git://people.freedesktop.org/~agd5f/linux.git drm-next-5.2-wip
head: ad636d2a1cb80ed84030892630a6159c0e34dd85
commit: d88e20633f0308bf17e954f4e71b44c16252e4f0 [47/78] drm/scheduler: rework
job destruction
config: riscv-allyesconfig (attached as .config)
compiler: riscv64-linux-gcc (GCC)
tree: git://anongit.freedesktop.org/drm/drm-tip drm-tip
head: 6f67b24f2fc7b90a94e4163ae4cd01bc2783fbfd
commit: fb4f0930305e60c480c86c0e2ba9bc8683179bd9 [4/9] Merge remote-tracking
branch 'origin/drm-misc-next' into drm-tip
reproduce: make htmldocs
If you fix the issue, kindly add following ta
https://bugs.freedesktop.org/show_bug.cgi?id=104185
Timothy Arceri changed:
What|Removed |Added
Resolution|--- |WORKSFORME
Status|NEEDINFO
https://bugs.freedesktop.org/show_bug.cgi?id=109124
Timothy Arceri changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=110575
--- Comment #1 from Timothy Arceri ---
Bit of a stab in the dark but if its related to bug #100239
You could try running steam from the command line with:
R600_DEBUG=zerovram steam
--
You are receiving this mail because:
You are the assignee
On 5/1/19 5:01 PM, Brendan Higgins wrote:
A lot of the expectation and assertion infrastructure prints out fairly
complicated test failure messages, so add a C++ style log library for
for logging test results.
Signed-off-by: Brendan Higgins
---
include/kunit/kunit-stream.h | 85 +
https://bugs.freedesktop.org/show_bug.cgi?id=108750
Timothy Arceri changed:
What|Removed |Added
Resolution|--- |NOTOURBUG
Status|NEW
On 5/1/19 5:01 PM, Brendan Higgins wrote:
Add a test for string stream along with a simpler example.
Signed-off-by: Brendan Higgins
---
kunit/Kconfig | 12 ++
kunit/Makefile | 4 ++
kunit/example-test.c | 88 ++
kunit/
On 5/1/19 5:01 PM, Brendan Higgins wrote:
A number of test features need to do pretty complicated string printing
where it may not be possible to rely on a single preallocated string
with parameters.
So provide a library for constructing the string as you go similar to
C++'s std::string.
Signed
https://bugs.freedesktop.org/show_bug.cgi?id=100239
--- Comment #19 from Timothy Arceri ---
If you run steam from the command line with:
R600_DEBUG=zerovram steam
Does that fix the issue for you?
--
You are receiving this mail because:
You are the assignee for the bug.
Hey Linus,
Just a single qxl revert for rc8/final.
Dave.
drm-fixes-2019-05-03:
drm one qxl revert
The following changes since commit 37624b58542fb9f2d9a70e6ea006ef8a5f66c30b:
Linux 5.1-rc7 (2019-04-28 17:04:13 -0700)
are available in the Git repository at:
git://anongit.freedesktop.org/drm
On Thu, May 2, 2019 at 7:04 AM shuah wrote:
>
> On 5/2/19 4:50 AM, Greg KH wrote:
> > On Wed, May 01, 2019 at 04:01:09PM -0700, Brendan Higgins wrote:
> >> ## TLDR
> >>
> >> I rebased the last patchset on 5.1-rc7 in hopes that we can get this in
> >> 5.2.
> >
> > That might be rushing it, normally
On Thu, May 2, 2019 at 4:05 AM Greg KH wrote:
>
> On Thu, May 02, 2019 at 12:50:53PM +0200, Greg KH wrote:
> > On Wed, May 01, 2019 at 04:01:09PM -0700, Brendan Higgins wrote:
> > > ## TLDR
> > >
> > > I rebased the last patchset on 5.1-rc7 in hopes that we can get this in
> > > 5.2.
> >
> > That
On Thu, 2 May 2019 at 20:45, Liviu Dudau wrote:
>
> Hi DRM maintainers,
>
> This is the 2nd pull request for the malidp-next. The new patches add
> additional support for Arm Mali D71 so that it can now be enabled
> correctly and brought up on any SoC that contains the IP. From now on
> we will st
On Thu, May 2, 2019 at 2:16 PM Frank Rowand wrote:
>
> On 5/2/19 11:07 AM, Brendan Higgins wrote:
> > On Thu, May 2, 2019 at 4:02 AM Greg KH wrote:
> >>
> >> On Wed, May 01, 2019 at 04:01:21PM -0700, Brendan Higgins wrote:
> >>> From: Felix Guo
> >>>
> >>> The ultimate goal is to create minimal
See the PhD thesis in the comments in this patch for details, but to
summarize this adds a hacky "unwedge" feature to the dw_hdmi i2c bus to
workaround what appears to be a hardware errata. This relies on a
pinctrl entry to help change around muxing to perform the unwedge.
NOTE that the specific
In certain situations it was seen that we could wedge up the DDC bus
on the HDMI adapter on rk3288. The only way to unwedge was to mux one
of the pins over to GPIO output-driven-low temporarily and then
quickly mux back. Full details can be found in the patch
("drm/bridge/synopsys: dw-hdmi: Add "
> Count us (Mellanox) too, our RDMA devices are exposing special and
> limited in size device memory to the users and we would like to provide
> an option to use cgroup to control its exposure.
Doesn't RDMA already has a separate cgroup? Why not implement it there?
> > and with future work, we c
https://bugs.freedesktop.org/show_bug.cgi?id=110443
--- Comment #11 from Julien Isorce ---
https://gitlab.freedesktop.org/mesa/mesa/merge_requests/796
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
On Rockchip rk3288-based Chromebooks when you do a suspend/resume
cycle:
1. You lose the ability to detect an HDMI device being plugged in.
2. If you're using the i2c bus built in to dw_hdmi then it stops
working.
Let's call the core dw-hdmi's suspend/resume functions to restore
things.
NOTE: i
On Rockchip rk3288-based Chromebooks when you do a suspend/resume
cycle:
1. You lose the ability to detect an HDMI device being plugged in.
2. If you're using the i2c bus built in to dw_hdmi then it stops
working.
Let's add a hook to the core dw-hdmi driver so that we can call it in
dw_hdmi-rock
https://bugs.freedesktop.org/show_bug.cgi?id=109345
--- Comment #26 from Christian Zigotzky ---
(In reply to Michel Dänzer from comment #25)
> (In reply to Christian Zigotzky from comment #24)
> > With which good and bad commit should I start bisecting?
>
> Good: c76cd634eb5bfd497617ea224a54a03b
On Wed, 1 May 2019 17:44:47 +0530, Jagan Teki wrote:
> HD702E lcd is FriendlyELEC developed eDP LCD panel with 800x1280
> resolution. It has built in Goodix, GT9271 captive touchscreen
> with backlight adjustable via PWM.
>
> Add support for it.
>
> Cc: Thierry Reding
> Cc: Sam Ravnborg
> Cc:
https://bugs.freedesktop.org/show_bug.cgi?id=108892
--- Comment #8 from Sami Farin ---
Created attachment 144130
--> https://bugs.freedesktop.org/attachment.cgi?id=144130&action=edit
dmesg
4.19.37 has this bug also.
Graphics: Device-1: Advanced Micro Devices [AMD/ATI] Lexa PRO [Radeon RX
550
On Thu, May 2, 2019 at 1:20 PM Greg Hartman wrote:
>
> + dwillem...@google.com background on the build changes.
>
> Thanks for doing this. It will be helpful to have fixes to make this build
> again.
>
We're still a bit out from getting master to build w/ the current AOSP tree.
We need solution
On Thu, May 2, 2019 at 1:31 PM Rob Clark wrote:
>
> fyi, John pushed a MR w/ the same patches:
> https://gitlab.freedesktop.org/mesa/mesa/merge_requests/795
>
> (I'm not really an expert on android build system, but if it works,
> then ack-by from me)
>
So there's one new issue that cropped up wh
https://bugzilla.kernel.org/show_bug.cgi?id=201273
--- Comment #50 from quirin.blae...@freenet.de ---
Bug is still alive. v5.0.10
--
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lis
On Thu, May 2, 2019 at 3:58 AM Greg KH wrote:
>
> On Wed, May 01, 2019 at 04:01:16PM -0700, Brendan Higgins wrote:
> > Add a test for string stream along with a simpler example.
> >
> > Signed-off-by: Brendan Higgins
> > ---
> > kunit/Kconfig | 12 ++
> > kunit/Makefile
On Thu, May 2, 2019 at 4:00 AM Greg KH wrote:
>
> On Wed, May 01, 2019 at 04:01:13PM -0700, Brendan Higgins wrote:
> > A lot of the expectation and assertion infrastructure prints out fairly
> > complicated test failure messages, so add a C++ style log library for
> > for logging test results.
>
>
From: Sean Paul
These functions were missing documentation.
Fixes the warning:
../include/drm/drm_modeset_helper_vtables.h:1000: warning: Function parameter
or member 'prepare_writeback_job' not described in 'drm_connector_helper_funcs'
../include/drm/drm_modeset_helper_vtables.h:1000: warning:
From: Sean Paul
There are no structured comments in the file, so it generates this
warning on compilation:
include/drm/drm_atomic_state_helper.h:1: warning: no structured comments found
Fixes: 9ef8a9dc4b21 ("drm: Extract drm_atomic_state_helper.[hc]")
Cc: Ville Syrjälä
Cc: Daniel Vetter
Cc: D
https://bugs.freedesktop.org/show_bug.cgi?id=110443
--- Comment #10 from Viktor Jägersküpper ---
I tried to investigate a bit further, and I think video acceleration does not
really work on my RV770, neither with VA-API nor with VDPAU. However, even if I
deactivate hardware video decoding in VLC,
From: Sean Paul
Now that we use the drm psr helpers, we no longer need to hand-roll our
atomic_commit_tail implementation. So use the helper
Changes in v2:
- None
Changes in v3:
- None
Link to v1:
https://patchwork.freedesktop.org/patch/msgid/20190228210939.83386-6-s...@poorly.run
Link to v2:
From: Sean Paul
Hey all,
Back from my break from this. v3 isn't a whole lot different from v2,
aside from the new helpers that I've added. These allowed me to remove
some redundant state from connector and rely solely on crtc_state.
Please take a look,
Sean
Sean Paul (10):
drm: Add atomic v
From: Sean Paul
Instead of fully disabling and re-enabling the vop on self refresh
transitions, only disable the active windows. This will speed up
self refresh exits substantially and is still a power-savings win.
This patch integrates portions of Zain's patch from here:
https://patchwork.kerne
From: Sean Paul
Instead of flushing all vops every time we get a dirtyfb call, use the
damage helper to kick off an atomic commit. Even though we don't use
damage clips, the helper commit will force us through the normal
psr_inhibit_get/put sequence.
Changes in v3:
- Added to the set
Suggested-
From: Sean Paul
Once we start shutting off the link during PSR, we're going to want fast
training to work. If the display doesn't support fast training, don't
enable psr.
Changes in v2:
- None
Changes in v3:
- None
Link to v1:
https://patchwork.freedesktop.org/patch/msgid/20190228210939.83386-
From: Sean Paul
Everyone who implements connector_helper_funcs->atomic_check reaches
into the connector state to get the atomic state. Instead of continuing
this pattern, change the callback signature to just give atomic state
and let the driver determine what it does and does not need from it.
From: Sean Paul
This patch adds atomic_enable and atomic_disable callbacks to the
encoder helpers. This will allow encoders to make informed decisions in
their start-up/shutdown based on the committed state.
Aside from the new hooks, this patch also introduces the new signature
for .atomic_* fun
From: Sean Paul
Instead of rolling our own implementation for tracking when PSR should
be [in]active, use the new self refresh helpers to do the heavy lifting.
Changes in v2:
- updated to reflect changes made in the helpers
Changes in v3:
- use the new atomic hooks to inspect crtc state instead
From: Sean Paul
This patch adds a helper to tease out the currently connected crtc for
an encoder, along with its state. This follows the same pattern as the
drm_atomic_crtc_*_for_* macros in the atomic helpers. Since the
relationship of crtc:encoder is 1:n, we don't need a loop since there is
on
From: Sean Paul
This patch adds a new drm helper library to help drivers implement
self refresh. Drivers choosing to use it will register crtcs and
will receive callbacks when it's time to enter or exit self refresh
mode.
In its current form, it has a timer which will trigger after a
driver-spec
From: Sean Paul
This patch adds atomic variants for all of
pre_enable/enable/disable/post_disable bridge functions. These will be
called from the appropriate atomic helper functions. If the bridge
driver doesn't implement the atomic version of the function, we will
fall back to the vanilla implem
Add vendor/product pairs for the Valve Index HMDs.
Signed-off-by: Andres Rodriguez
Cc: Dave Airlie
Cc: # v4.15
---
drivers/gpu/drm/drm_edid.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 2c22ea446075..649
Hi Dave, Daniel,
Fixes for 5.2:
- SR-IOV fixes
- Raven flickering fix
- Misc spelling fixes
- Vega20 power fixes
- Freesync improvements
- DC fixes
The following changes since commit f55be0be5b7296e73f1634e2839a1953dc12d11e:
drm/amd/display: Add profiling tools for bandwidth validation (2019-0
On Thu, May 2, 2019 at 11:15 AM wrote:
>
>
>
> > -Original Message-
> > From: Greg KH
> >
> > On Wed, May 01, 2019 at 04:01:25PM -0700, Brendan Higgins wrote:
> > > From: Iurii Zaikin
> > >
> > > KUnit tests for initialized data behavior of proc_dointvec that is
> > > explicitly checked i
Paul Kocialkowski writes:
> Hi,
>
> On Thu, 2019-04-25 at 10:42 -0700, Eric Anholt wrote:
>> Paul Kocialkowski writes:
>>
>> > The binner BO is not required until the V3D is in use, so avoid
>> > allocating it at probe and do it on the first non-dumb BO allocation.
>> >
>> > Keep track of whic
On Thu, May 2, 2019 at 4:02 AM Greg KH wrote:
>
> On Wed, May 01, 2019 at 04:01:21PM -0700, Brendan Higgins wrote:
> > From: Felix Guo
> >
> > The ultimate goal is to create minimal isolated test binaries; in the
> > meantime we are using UML to provide the infrastructure to run tests, so
> > def
The ir3_nir_trig.py file was moved in a previous commit,
aa0fed10d3574 (freedreno: move ir3 to common location),
so update the Android.gen.mk file to match.
Cc: Rob Clark
Cc: Emil Velikov
Cc: Amit Pundir
Cc: Sumit Semwal
Cc: Alistair Strachan
Cc: Greg Hartman
Cc: Tapani Pälli
Cc: Jason Ekst
From: Alistair Strachan
The current AOSP master build system breaks building mesa due to the
following error:
external/mesa3d/src/compiler/Android.glsl.gen.mk:94: error:
writing to readonly directory: "external/mesa3d/src/compiler/glsl/ir.h"
This error is bogus -- nothing "writes" to ir.h --
From: Amit Pundir
Add libfreedreno_drm/ir3 to the build
Cc: Rob Clark
Cc: Emil Velikov
Cc: Amit Pundir
Cc: Sumit Semwal
Cc: Alistair Strachan
Cc: Greg Hartman
Cc: Tapani Pälli
Cc: Jason Ekstrand
Signed-off-by: Amit Pundir
[jstultz: Tweaked to add extra ir3 files from master]
Signed-off-
Somewhat recent changes in the AOSP build system has been made
which fairly severely restricts the build environment. This has
made it difficult to test mesa/master w/ AOSP/master.
I'm working with others to try to remedy this, but as a first
step I used some hacks to temporarily remove the build
(Add missing CCs)
On Mon, Apr 29, 2019 at 3:08 PM Chia-I Wu wrote:
>
> This is motivated by having meaningful ftrace events, but it also
> fixes use cases where dma_fence_is_later is called, such as in
> sync_file_merge.
>
> In other drivers, fence creation and cmdbuf submission normally
> happe
On Thu, May 02, 2019 at 05:10:10PM +0100, Ben Davis wrote:
> The phase setting part of malidp_crtc_atomic_check_scaling is refactored
> to allow use in writeback scaling.
>
> Also the enable_memwrite function prototype is simplified by directly
> passing mw_state.
>
> Signed-off-by: Ben Davis
R
On Thu, May 02, 2019 at 05:10:09PM +0100, Ben Davis wrote:
> Add new properties to specify x,y coordinates and
> width and height for writeback.
>
> These are reset to 0 on duplicating state to provide
> robustness against accidental scaling.
>
> Signed-off-by: Ben Davis
Reviewed-by: Liviu Duda
Add new properties to specify x,y coordinates and
width and height for writeback.
These are reset to 0 on duplicating state to provide
robustness against accidental scaling.
Signed-off-by: Ben Davis
---
drivers/gpu/drm/drm_atomic_state_helper.c | 6 +++
drivers/gpu/drm/drm_atomic_uapi.c
Add support for scaling on writeback. To do this add
writeback_dest_x,y,w,h writeback connector properties to specify the
desired output dimensions.
Then implement downscaling on writeback for Malidp-550 and Malidp-650
(upscaling on writeback is not supported on these devices).
v2: Use 0 as defaul
The phase setting part of malidp_crtc_atomic_check_scaling is refactored
to allow use in writeback scaling.
Also the enable_memwrite function prototype is simplified by directly
passing mw_state.
Signed-off-by: Ben Davis
---
drivers/gpu/drm/arm/malidp_crtc.c | 47 ---
drivers/gpu/d
Hi,
On Tue, Apr 30, 2019 at 10:31:08PM +0200, Sam Ravnborg wrote:
> Hi Guido.
>
> Took a look at this, but feedback is trivial as
> I have no experience with PHYs so use only
> the feedback you consider relevant.
They all made sense so I've incorporated them for v10.
>
> Sam
>
> > diff -
console_trylock, called from within printk, can be called from pretty
much anywhere. Including try_to_wake_up. Note that this isn't common,
usually the box is in pretty bad shape at that point already. But it
really doesn't help when then lockdep jumps in and spams the logs,
potentially obscuring t
Quoting Daniel Vetter (2019-05-02 14:56:03)
> Move the open helper around to avoid the forward decl, and give
> drm_setup a drm_legacy_ prefix since it's all legacy stuff in there.
>
> v2: Move drm_legacy_setup into drm_legacy_misc.c (Chris). The
> counterpart in the form of drm_legacy_dev_reinit
On 5/2/19 4:50 AM, Greg KH wrote:
On Wed, May 01, 2019 at 04:01:09PM -0700, Brendan Higgins wrote:
## TLDR
I rebased the last patchset on 5.1-rc7 in hopes that we can get this in
5.2.
That might be rushing it, normally trees are already closed now for
5.2-rc1 if 5.1-final comes out this Sunda
Move the open helper around to avoid the forward decl, and give
drm_setup a drm_legacy_ prefix since it's all legacy stuff in there.
v2: Move drm_legacy_setup into drm_legacy_misc.c (Chris). The
counterpart in the form of drm_legacy_dev_reinit is there already too,
plus it fits perfectly into Dave
Hi Dave & Daniel,
A quick fix to unbreak media driver, worthy inclusion before the merge window.
Best Regards,
Joonas
***
drm-intel-next-fixes-2019-05-02:
- Whitelist a register to avoid media driver from hanging
The following changes since commit 879a4e70f96a26a9368a3caed2f552aa67105852:
On 2019-05-02 at 18:52:53 +0530, Ramalingam C wrote:
> This series adds the content type capability for HDCP through a
> drm connetor proeprty "HDCP Content Type". By default this property will
> be "Type 0". And this property is exposed by the drivers which has the
> HDCP2.2 capability to enable t
drm function is defined and exported to update a connector's
content protection property state and to generate a uevent along
with it.
Need ACK for the uevent from userspace consumer.
v2:
Update only when state is different from old one.
v3:
KDoc is added [Daniel]
Signed-off-by: Ramalingam C
DRM API for generating uevent for a status changes of connector's
property.
This uevent will have following details related to the status change:
HOTPLUG=1, CONNECTOR= and PROPERTY=
Need ACK from this uevent from userspace consumer.
v2:
Minor fixes at KDoc comments [Daniel]
v3:
Check the
This patch adds a DRM ENUM property to the selected connectors.
This property is used for mentioning the protected content's type
from userspace to kernel HDCP authentication.
Type of the stream is decided by the protected content providers.
Type 0 content can be rendered on any HDCP protected dis
drm function to update the content protection property state and to
generate a uevent is invoked from the intel hdcp property work.
Hence whenever kernel changes the property state, userspace will be
updated with a uevent.
Need a ACK for uevent generating uAPI from userspace.
v2:
state update
Attaches the content type property for HDCP2.2 capable connectors.
Implements the update of content type from property and apply the
restriction on HDCP version selection.
Need ACK for content type property from userspace consumer.
v2:
s/cp_content_type/content_protection_type [daniel]
disab
This series adds the content type capability for HDCP through a
drm connetor proeprty "HDCP Content Type". By default this property will
be "Type 0". And this property is exposed by the drivers which has the
HDCP2.2 capability to enable the userspace to configure for "Type 1".
HDCP Content Type:
Adding the HDCP2.2 capability of HDCP src and sink info into debugfs
entry "i915_hdcp_sink_capability"
This helps the userspace tests to skip the HDCP2.2 test on non HDCP2.2
sinks.
v2:
Rebased.
Signed-off-by: Ramalingam C
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_debugfs.c |
1 - 100 of 138 matches
Mail list logo
