The pull request you sent on Fri, 22 Mar 2019 12:20:28 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2019-03-22
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/fd1f297b794c77e52412dc621b5884210291
Thank you!
--
Deet-doot-dot, I am a bot.
Hi Harry,
I noticed this patch is already in mainline, but the stable tag
was removed. What is the reason for that if this bug is present
in stable?
Thanks
--
Gustavo
On 1/3/19 3:11 PM, Wentland, Harry wrote:
> On 2019-01-03 2:48 p.m., Gustavo A. R. Silva wrote:
>> Fix boolean expression by
On 3/21/19 10:14 PM, Joe Perches wrote:
> On Thu, 2019-03-21 at 22:10 -0500, Gustavo A. R. Silva wrote:
>> Hi Harry,
>>
>> I noticed this patch is already in mainline, but the stable tag
>> was removed. What is the reason for that if this bug is present
>> in stable?
>
> It's not a bug, it's
https://bugs.freedesktop.org/show_bug.cgi?id=110214
--- Comment #7 from Diego Viola ---
(In reply to Diego Viola from comment #6)
> (In reply to Michel Dänzer from comment #1)
> > Please attach the corresponding Xorg log file and output of glxinfo and
> > dmesg.
>
> Done.
>
> >
> > I can't
https://bugs.freedesktop.org/show_bug.cgi?id=110214
--- Comment #6 from Diego Viola ---
(In reply to Michel Dänzer from comment #1)
> Please attach the corresponding Xorg log file and output of glxinfo and
> dmesg.
Done.
>
> I can't seem to reproduce this, and I'm not sure what exactly "parts
On Thu, 2019-03-21 at 22:10 -0500, Gustavo A. R. Silva wrote:
> Hi Harry,
>
> I noticed this patch is already in mainline, but the stable tag
> was removed. What is the reason for that if this bug is present
> in stable?
It's not a bug, it's just a style issue and
the && use in some compilers
Hi Linus,
Fixes for rc2, seems to be lots of little minor ones for regressions
in rc1, and some cleanups, the exynos one is the largest one, and is
for a hw difference between exynos versions.
Regards,
Dave.
drm-fixes-2019-03-22:
drm i915, amdgpu, vmwgfx, exynos, nouveau and udl fixes
The
On Thu, Mar 21, 2019 at 10:49:03AM +0100, Uwe Kleine-König wrote:
> Hello,
>
> On Wed, Mar 20, 2019 at 01:01:26PM +, Leonard Crestez wrote:
> > Commit d80f8206905c ("pwm: imx: Split into two drivers") also adds a new
> > CONFIG_PWM_IMX27 for the PWM block on recent IMX chips and we should
> >
On Thu, Mar 21, 2019 at 6:16 PM Frank Rowand wrote:
>
> On 2/14/19 1:37 PM, Brendan Higgins wrote:
> > Split up the super large test cases of_unittest_find_node_by_name and
> > of_unittest_dynamic into properly sized and defined test cases.
>
> I also still object to this patch.
I figured. Will
On Thu, Mar 21, 2019 at 6:15 PM Frank Rowand wrote:
>
> On 2/14/19 1:37 PM, Brendan Higgins wrote:
> > Split out a couple of test cases that these features in base.c from the
> > unittest.c monolith. The intention is that we will eventually split out
> > all test cases and group them together
On Thu, Mar 21, 2019 at 6:10 PM Frank Rowand wrote:
>
> On 2/27/19 11:42 PM, Brendan Higgins wrote:
> > On Tue, Feb 19, 2019 at 10:44 PM Frank Rowand
> > wrote:
> >>
> >> On 2/19/19 7:39 PM, Brendan Higgins wrote:
> >>> On Mon, Feb 18, 2019 at 11:52 AM Frank Rowand
> >>> wrote:
>
>
https://bugs.freedesktop.org/show_bug.cgi?id=110142
Peter Easton changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
On Thu, Mar 21, 2019 at 5:22 PM Frank Rowand wrote:
>
> On 2/27/19 7:52 PM, Brendan Higgins wrote:
> > On Wed, Feb 20, 2019 at 12:45 PM Frank Rowand
> > wrote:
> >>
> >> On 2/18/19 2:25 PM, Frank Rowand wrote:
> >>> On 2/15/19 2:56 AM, Brendan Higgins wrote:
> On Thu, Feb 14, 2019 at 6:05
Hi, Hsin-yi:
On Thu, 2019-03-21 at 22:09 +0800, Hsin-Yi Wang wrote:
> On Thu, Mar 21, 2019 at 9:46 AM CK Hu wrote:
> >
> > Hi, Hsin-yi:
> >
> > On Thu, 2019-03-21 at 09:28 +0800, CK Hu wrote:
> > > Hi, Hsin-yi:
> > >
> > > On Wed, 2019-03-20 at 15:18 +0800, Hsin-Yi Wang wrote:
> > > >
Invoking the uevent generator for the content protection property state
change of a connector. This helps the userspace to detect the new state
change without polling the property val.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/intel_hdcp.c | 11 +++
1 file changed, 11
Implements drm blob property content_protection_downstream_info
property on HDCP capable connectors.
Downstream topology info is gathered across authentication stages
and stored in intel_hdcp. When HDCP authentication is complete,
new blob with latest downstream topology information is updated to
HDCP2.2 phase-II introduces below features:
Addition of three connector properties
HDCP Content Type
HDCP Topology
Addition of binary sysfs "hdcp_srm"
parsing for HDCP1.4 and 2.2 SRM table
Once HDCP1.4/2.2 authentication is completed
Binary Sysfs entry is created to pass the HDCP SRM table into
kerel for the HDCP authentication purpose.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/i915_sysfs.c | 32 +++
1 file changed, 32 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_sysfs.c
Populates the downstream info for HDCP2.2 encryption also. On success
of encryption Blob is updated.
Additional two variable are added to downstream info blob. Such as
ver_in_force and content type.
v2:
s/cp_downstream/content_protection_downstream [daniel]
v3:
DRM API for generating uevent for a status changes of connector's
property.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/drm_sysfs.c | 28
include/drm/drm_sysfs.h | 5 -
2 files changed, 32 insertions(+), 1 deletion(-)
diff --git
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.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/i915_debugfs.c | 13 +++--
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.
v2:
s/cp_content_type/content_protection_type [daniel]
disable at hdcp_atomic_check to avoid check at
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
This patch adds a optional CP downstream info blob property to the
connectors. This enables the Userspace to read the information of HDCP
authenticated downstream topology.
Driver will updated this blob with all downstream information at the
end of the authentication.
In case userspace
Implements the SRM table parsing for HDCP 1.4 and 2.2.
And also revocation check is added at authentication of HDCP1.4
and 2.2
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/i915_drv.c | 1 +
drivers/gpu/drm/i915/i915_drv.h | 6 +
drivers/gpu/drm/i915/intel_drv.h | 2 +
Hi Stephen,
On Fri, Mar 22, 2019 at 10:57:28AM +1100, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the drm-intel tree got a conflict in:
>
> drivers/gpu/drm/i915/gvt/mmio_context.c
>
> between commit:
>
> 1e8b15a1988e ("drm/i915/gvt: Add in context mmio 0x20D8 to gen9
The following changes since commit a788ade4f6e0302710f89b2a3534346df752072d:
drm/nouveau/dmem: use dma addresses during migration copies
(2019-02-20 09:00:03 +1000)
are available in the Git repository at:
git://github.com/skeggsb/linux linux-5.1
for you to fetch changes up to
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in:
drivers/gpu/drm/i915/gvt/mmio_context.c
between commit:
1e8b15a1988e ("drm/i915/gvt: Add in context mmio 0x20D8 to gen9 mmio list")
from the drm-intel-fixes tree and commit:
8a68d464366e ("drm/i915: Store the
From: Clinton Taylor
Added PHY_TEST_PATTERN_SEL bit definitions for DPCD 00248h and
HBR2_COMPLIANCE_SCRAMBLER_RESET DPCD definition.
Signed-off-by: Clinton Taylor
---
include/drm/drm_dp_helper.h | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git
On Thu, Mar 21, 2019 at 3:27 PM Logan Gunthorpe wrote:
>
>
>
> On 2019-03-21 4:07 p.m., Brendan Higgins wrote:
> > A couple of points, as for needing CONFIG_PCI; my plan to deal with
> > that type of thing has been that we would add support for a KUnit/UML
> > version that is just for KUnit. It
Paul Kocialkowski writes:
> Hi,
>
> Le mercredi 20 mars 2019 à 09:56 -0700, Eric Anholt a écrit :
>> Paul Kocialkowski writes:
>>
>> > The firstopen DRM driver hook was initially used to perform hardware
>> > initialization, which is now considered legacy. Only a single user of
>> > firstopen
[+cc Rafael]
On Wed, Mar 13, 2019 at 06:25:02PM -0400, Lyude Paul wrote:
> On Fri, 2019-02-15 at 16:17 -0500, Lyude Paul wrote:
> > On Thu, 2019-02-14 at 18:43 -0600, Bjorn Helgaas wrote:
> > > On Tue, Feb 12, 2019 at 05:02:30PM -0500, Lyude Paul wrote:
> > > > On a very specific subset of
https://bugs.freedesktop.org/show_bug.cgi?id=110217
--- Comment #2 from numz...@yandex.ru ---
Created attachment 143756
--> https://bugs.freedesktop.org/attachment.cgi?id=143756=edit
Xorg config
If I uncomment the proper `Output-...` option, Xorg starts in the correct mode
but with flicker.
https://bugs.freedesktop.org/show_bug.cgi?id=110217
--- Comment #1 from numz...@yandex.ru ---
Created attachment 143755
--> https://bugs.freedesktop.org/attachment.cgi?id=143755=edit
Xorg log
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=110217
Bug ID: 110217
Summary: RX580: screen turns black or flickers until forced
reconfiguration
Product: DRI
Version: unspecified
Hardware: x86-64 (AMD64)
OS:
https://bugs.freedesktop.org/show_bug.cgi?id=110214
Diego Viola changed:
What|Removed |Added
Hardware|Other |x86-64 (AMD64)
OS|All
On Wed, Mar 20, 2019 at 6:08 PM Logan Gunthorpe wrote:
>
> Hi,
>
> On 2019-02-14 2:37 p.m., Brendan Higgins wrote:
> > This patch set proposes KUnit, a lightweight unit testing and mocking
> > framework for the Linux kernel.
>
> I haven't followed the entire conversation but I saw the KUnit
On Thu, Mar 21, 2019 at 03:14:06PM -0400, Nicolas Dufresne wrote:
> Le jeudi 21 mars 2019 à 18:35 +0200, Ville Syrjälä a écrit :
> > > I'm not sure what it's worth, but there is a "pixel format guide"
> > > project that is all about matching formats from one API to another:
> > >
On Tue, Mar 19, 2019 at 5:08 AM Brian Starkey wrote:
>
> Hi John,
>
> On Tue, Mar 05, 2019 at 12:54:29PM -0800, John Stultz wrote:
> > From: "Andrew F. Davis"
>
> [snip]
>
> > +
> > +#define NUM_HEAP_MINORS 128
> > +static DEFINE_IDR(dma_heap_idr);
> > +static DEFINE_MUTEX(minor_lock); /*
On Thu, Mar 21, 2019 at 08:29:31PM +, Thomas Hellstrom wrote:
> On Thu, 2019-03-21 at 10:12 -0400, Jerome Glisse wrote:
> > On Thu, Mar 21, 2019 at 01:22:41PM +, Thomas Hellstrom wrote:
> > > Add two utilities to a) write-protect and b) clean all ptes
> > > pointing into
> > > a range of
https://bugs.freedesktop.org/show_bug.cgi?id=110214
--- Comment #5 from Diego Viola ---
Created attachment 143752
--> https://bugs.freedesktop.org/attachment.cgi?id=143752=edit
dmesg
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=110214
--- Comment #4 from Diego Viola ---
Created attachment 143751
--> https://bugs.freedesktop.org/attachment.cgi?id=143751=edit
glxinfo
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=110214
--- Comment #3 from Diego Viola ---
Created attachment 143750
--> https://bugs.freedesktop.org/attachment.cgi?id=143750=edit
Xorg.0.log
--
You are receiving this mail because:
You are the assignee for the
On Thu, Mar 21, 2019 at 4:41 PM Meelis Roos wrote:
>
> I decided to put a discrete graphics card into a PC and found a fitting
> Radeon HD 7450.
> It works, but there is strange whiteness like the brightness is oversaturated
> and
> light places turn into other colors:
> * on fbcon, right after
https://bugs.freedesktop.org/show_bug.cgi?id=110214
--- Comment #2 from Diego Viola ---
Created attachment 143749
--> https://bugs.freedesktop.org/attachment.cgi?id=143749=edit
Screencast demonstrating the problem
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=108625
Alex Deucher changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
On 3/5/19 2:54 PM, John Stultz wrote:
> Add generic helper dmabuf ops for dma heaps, so we can reduce
> the amount of duplicative code for the exported dmabufs.
>
> This code is an evolution of the Android ION implementation, so
> thanks to its original authors and maintainters:
> Rebecca
On 3/19/19 9:26 AM, Brian Starkey wrote:
> Hi John,
>
> On Tue, Mar 05, 2019 at 12:54:30PM -0800, John Stultz wrote:
>
> ...
>
>> +
>> +void dma_heap_buffer_destroy(struct dma_heap_buffer *heap_buffer)
>> +{
>> +struct heap_helper_buffer *buffer = to_helper_buffer(heap_buffer);
>> +
>> +
On Thu, 2019-03-21 at 10:12 -0400, Jerome Glisse wrote:
> On Thu, Mar 21, 2019 at 01:22:41PM +, Thomas Hellstrom wrote:
> > Add two utilities to a) write-protect and b) clean all ptes
> > pointing into
> > a range of an address space
> > The utilities are intended to aid in tracking dirty
On Thu, Mar 21, 2019 at 07:51:16PM +, Thomas Hellstrom wrote:
> Hi, Jérôme,
>
> Thanks for commenting. I have a couple of questions / clarifications
> below.
>
> On Thu, 2019-03-21 at 09:46 -0400, Jerome Glisse wrote:
> > On Thu, Mar 21, 2019 at 01:22:22PM +, Thomas Hellstrom wrote:
> >
On Thu, Mar 21, 2019 at 07:59:35PM +, Thomas Hellstrom wrote:
> On Thu, 2019-03-21 at 09:52 -0400, Jerome Glisse wrote:
> > On Thu, Mar 21, 2019 at 01:22:35PM +, Thomas Hellstrom wrote:
> > > This is basically apply_to_page_range with added functionality:
> > > Allocating missing parts of
On Wed, Mar 6, 2019 at 8:05 AM Benjamin Gaignard
wrote:
> Le mar. 5 mars 2019 à 21:54, John Stultz a écrit :
> > +#define to_cma_heap(x) container_of(x, struct cma_heap, heap)
>
> Even if I had write this macro years ago, now I would prefer to have a
> static inline function
> to be able to
On Tue, Mar 19, 2019 at 7:26 AM Brian Starkey wrote:
>
> Hi John,
>
> On Tue, Mar 05, 2019 at 12:54:30PM -0800, John Stultz wrote:
>
> ...
>
> > +
> > +void dma_heap_buffer_destroy(struct dma_heap_buffer *heap_buffer)
> > +{
> > + struct heap_helper_buffer *buffer =
The map_atomic/unmap_atomic callbacks have been removed, remove
the related comments.
Fixes: f664a5269542 ("dma-buf: remove kmap_atomic interface")
Signed-off-by: Andrew F. Davis
---
include/linux/dma-buf.h | 5 -
1 file changed, 5 deletions(-)
diff --git a/include/linux/dma-buf.h
Other function have inline documentation, a couple still have
theirs at the top of the structure, update the docs and move
them inline.
Signed-off-by: Andrew F. Davis
---
include/linux/dma-buf.h | 29 +
1 file changed, 25 insertions(+), 4 deletions(-)
diff --git
On Fri, Mar 15, 2019 at 2:06 AM Christoph Hellwig wrote:
> > + if (buffer->kmap_cnt) {
> > + buffer->kmap_cnt++;
> > + return buffer->vaddr;
> > + }
> > + vaddr = dma_heap_map_kernel(buffer);
> > + if (WARN_ONCE(!vaddr,
> > +
On Thu, 2019-03-21 at 09:52 -0400, Jerome Glisse wrote:
> On Thu, Mar 21, 2019 at 01:22:35PM +, Thomas Hellstrom wrote:
> > This is basically apply_to_page_range with added functionality:
> > Allocating missing parts of the page table becomes optional, which
> > means that the function can be
Hi, Jérôme,
Thanks for commenting. I have a couple of questions / clarifications
below.
On Thu, 2019-03-21 at 09:46 -0400, Jerome Glisse wrote:
> On Thu, Mar 21, 2019 at 01:22:22PM +, Thomas Hellstrom wrote:
> > Resending since last series was sent through a mis-configured SMTP
> > server.
>
From: Jérôme Glisse
Empty chunk do not have a bo associated with them so no need to pin/unpin
on suspend/resume.
This fix suspend/resume on 5.1rc1 when NOUVEAU_SVM is enabled.
Signed-off-by: Jérôme Glisse
Reviewed-by: Tobias Klausmann
Tested-by: Tobias Klausmann
Cc: Ben Skeggs
Cc:
Hi,
On Fri, Feb 08, 2019 at 11:55:41AM +, Robert Chiras wrote:
[..snip..]
> > > version of eLCDIF with Raydium RM67191 DSI panel on mScale850D
> > > (i.MX8MQ). And I tried using this driver but there is no signal on
> > > the
> > > screen, even through the register values are all identical.
Add vendor prefix "mixel" for Mixel Inc. Will be used for a MIPI DSI
PHY driver.
Signed-off-by: Guido Günther
---
Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt
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.MX8MQ. Support for i.MX8QM and i.MX8QXP can be
added
Add support for the MIXEL DPHY IP as found in the NXP's i.MX8MQ.
Signed-off-by: Guido Günther
Reviewed-by: Sam Ravnborg
---
.../bindings/phy/mixel,mipi-dsi-phy.txt | 29 +++
1 file changed, 29 insertions(+)
create mode 100644
Hi Da.*,
Here's the first 5.2 PR from -misc. There's a bit of everything in the PR,
enjoy!
drm-misc-next-2019-03-21:
drm-misc-next for 5.2:
UAPI Changes:
- Add Colorspace connector property (Uma)
- fourcc: Several new YUV formats from ARM (Brian & Ayan)
- fourcc: Fix merge conflicts between new
This adds initial support for the Mixel IP based mipi dphy as found on i.MX8
processors. It has support for the i.MX8MQ, support for other variants can be
added - once the platform specific parts are in - via the provided devdata.
The driver is somewhat based on what's found in NXPs BSP.
Public
On Thu, Mar 21, 2019 at 8:56 AM Logan Gunthorpe wrote:
>
>
>
> On 2019-03-20 11:23 p.m., Knut Omang wrote:
> > Testing drivers, hardware and firmware within production kernels was the use
> > case that inspired KTF (Kernel Test Framework). Currently KTF is available
> > as a
> > standalone git
On Thu, Mar 21, 2019 at 05:04:19PM +0100, Paul Kocialkowski wrote:
> Hi,
>
> Le mercredi 20 mars 2019 à 20:39 +0200, Ville Syrjälä a écrit :
> > On Wed, Mar 20, 2019 at 02:27:59PM -0400, Nicolas Dufresne wrote:
> > > Le mercredi 20 mars 2019 à 18:41 +0200, Ville Syrjälä a écrit :
> > > > On Wed,
This new export type exposes to userspace the SRAM area as a DMA-Heap,
this allows for allocations as DMA-BUFs that can be consumed by various
DMA-BUF supporting devices.
Signed-off-by: Andrew F. Davis
---
Hello all,
This is an example user of the currently RFC DMA-HEAP framework. It
exports a
Paul Kocialkowski writes:
> Hi,
>
> Le mercredi 20 mars 2019 à 09:58 -0700, Eric Anholt a écrit :
>> Paul Kocialkowski writes:
>>
>> > The binner BO is a pre-requisite to GPU operations, so we must ensure
>> > that it is always allocated when the GPU is in use. Currently, we are
>> >
Hi,
Le mercredi 20 mars 2019 à 20:39 +0200, Ville Syrjälä a écrit :
> On Wed, Mar 20, 2019 at 02:27:59PM -0400, Nicolas Dufresne wrote:
> > Le mercredi 20 mars 2019 à 18:41 +0200, Ville Syrjälä a écrit :
> > > On Wed, Mar 20, 2019 at 12:30:25PM -0400, Nicolas Dufresne wrote:
> > > > Le mercredi
Hi,
Le mercredi 20 mars 2019 à 09:58 -0700, Eric Anholt a écrit :
> Paul Kocialkowski writes:
>
> > The binner BO is a pre-requisite to GPU operations, so we must ensure
> > that it is always allocated when the GPU is in use. Currently, we are
> > allocating it at probe time and
On 3/21/19 11:38 AM, Wentland, Harry wrote:
>
>
> On 2019-03-21 5:39 a.m., Mario Kleiner wrote:
>> On Wed, Mar 20, 2019 at 1:53 PM Kazlauskas, Nicholas
>> wrote:
>>>
>>> On 3/20/19 3:51 AM, Mario Kleiner wrote:
Ok, fixed all the style issues and ran checkpatch over the patches. Thanks.
On Wed, Mar 20, 2019 at 06:15:54PM +, Brian Starkey wrote:
> On Tue, Mar 19, 2019 at 07:29:18PM -0400, Nicolas Dufresne wrote:
> > All RGB mapping should be surrounded by ifdef, because many (not all)
> > DRM formats represent the order of component when placed in a CPU
> > register, unlike
On Tue, Mar 19, 2019 at 12:48:19PM +, Måns Rullgård wrote:
> Maxime Ripard writes:
>
> > On Mon, Mar 18, 2019 at 04:23:56PM +, Måns Rullgård wrote:
> >> Maxime Ripard writes:
> >>
> >> > On Thu, Mar 14, 2019 at 04:09:13PM +, Måns Rullgård wrote:
> >> >> Maxime Ripard writes:
> >> >>
On 2019-03-21 5:39 a.m., Mario Kleiner wrote:
> On Wed, Mar 20, 2019 at 1:53 PM Kazlauskas, Nicholas
> wrote:
>>
>> On 3/20/19 3:51 AM, Mario Kleiner wrote:
>>> Ok, fixed all the style issues and ran checkpatch over the patches. Thanks.
>>>
>>> On Tue, Mar 19, 2019 at 2:32 PM Kazlauskas,
Hi,
Le mercredi 20 mars 2019 à 09:56 -0700, Eric Anholt a écrit :
> Paul Kocialkowski writes:
>
> > The firstopen DRM driver hook was initially used to perform hardware
> > initialization, which is now considered legacy. Only a single user of
> > firstopen remains at this point (savage).
> >
>
No, atomic cmpxchg is a hardware operation. If you want to replace that
you need a lock again.
Maybe just add a comment and use an explicit cast to void* ? Not sure if
that silences the warning.
Christian.
Am 21.03.19 um 15:13 schrieb Zhou, David(ChunMing):
cmpxchg be replaced by some
On Tue, Mar 19, 2019 at 3:55 PM Maxime Ripard wrote:
>
> On Mon, Mar 11, 2019 at 09:31:11PM +0530, Jagan Teki wrote:
> > On Mon, Mar 11, 2019 at 9:07 PM Maxime Ripard
> > wrote:
> > >
> > > On Mon, Mar 11, 2019 at 07:06:23PM +0530, Jagan Teki wrote:
> > > > Vertical video start delay is
cmpxchg be replaced by some simple c sentance?
otherwise we have to remove __rcu of chian->prev.
-David
Original Message
Subject: Re: [PATCH 1/9] dma-buf: add new dma_fence_chain container v6
From: Christian König
To: "Zhou, David(ChunMing)" ,kbuild test robot ,"Zhou,
On Thu, Mar 21, 2019 at 01:22:41PM +, Thomas Hellstrom wrote:
> Add two utilities to a) write-protect and b) clean all ptes pointing into
> a range of an address space
> The utilities are intended to aid in tracking dirty pages (either
> driver-allocated system memory or pci device memory).
>
Hi Sergey,
On Tue, Mar 19, 2019 at 5:47 PM Sergey Suloev wrote:
>
> Hi, guys,
>
> On 3/19/19 1:53 PM, Maxime Ripard wrote:
>
> On Mon, Mar 11, 2019 at 09:36:27PM +0530, Jagan Teki wrote:
>
> On Mon, Mar 11, 2019 at 9:08 PM Maxime Ripard
> wrote:
>
> On Mon, Mar 11, 2019 at 07:06:24PM +0530,
On Tue, Mar 19, 2019 at 4:23 PM Maxime Ripard wrote:
>
> On Mon, Mar 11, 2019 at 09:36:27PM +0530, Jagan Teki wrote:
> > On Mon, Mar 11, 2019 at 9:08 PM Maxime Ripard
> > wrote:
> > >
> > > On Mon, Mar 11, 2019 at 07:06:24PM +0530, Jagan Teki wrote:
> > > > pll-video => pll-mipi => tcon0 =>
Add vendor prefix for microtech, known as
Microtech Technology Company Limited. a known producer for
Liquid Crytal Display modules and Touch Panels.
Signed-off-by: Jagan Teki
---
Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
1 file changed, 1 insertion(+)
diff --git
Novatek NT35596 is a single-chip IC solution for small or medium-sized
LTPS TFT LCD panels. NT35596 provides several system interfaces like
MIPI/SPI/I2C.
Currently added support for Microtech MTF050FHDI-03 is 1080x1920,
4-lane MIPI DSI LCD panel which has inbuilt NT35596 IC chip.
NT35596
This is v2 series for Novatek NT35596 panel driver. here is previous
series set[2]
Since there is no proper programming guide for NT35596 IC, the driver
init sequence is referenced from [1] but analyzed based on datasheet.
NT35596 support several regulators on the chip, among those ony 4
Add vendor prefix for novatek.
Novatek Microelectronics Corp. is a leading fabless chip design
company specializing in the design, development and sales of a
wide range of display driver ICs & SoC solutions.
Signed-off-by: Jagan Teki
---
Documentation/devicetree/bindings/vendor-prefixes.txt |
On Wed, Mar 20, 2019 at 9:25 AM YueHaibing wrote:
>
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/gpu/drm/radeon/radeon_ttm.c: In function 'radeon_move_vram_ram':
> drivers/gpu/drm/radeon/radeon_ttm.c:254:24: warning:
> variable 'rdev' set but not used [-Wunused-but-set-variable]
Novatek NT35596 is a single-chip IC solution for small or medium-sized
LTPS TFT LCD panels. NT35596 provides several system interfaces like
MIPI/SPI/I2C.
Microtech MTF050FHDI-03 is 1080x1920, 4-lane MIPI DSI LCD panel which
has inbuilt NT35596 IC chip.
NT35596 support several regulators on the
On Wed, Mar 20, 2019 at 4:33 AM Nathan Chancellor
wrote:
>
> When building with -Wsometimes-uninitialized, Clang warns:
>
> drivers/gpu/drm/amd/amdgpu/../powerplay/vega20_ppt.c:456:2: warning:
> variable 'num_of_levels' is used uninitialized whenever '?:' condition
> is false
On Wed, Mar 20, 2019 at 1:29 PM Colin King wrote:
>
> From: Colin Ian King
>
> There is a spelling mistake in pr_warn message; fix it.
>
> Signed-off-by: Colin Ian King
Applied. thanks!
Alex
> ---
> drivers/gpu/drm/amd/powerplay/smu_v11_0.c | 2 +-
> 1 file changed, 1 insertion(+), 1
On Thu, Mar 21, 2019 at 01:22:35PM +, Thomas Hellstrom wrote:
> This is basically apply_to_page_range with added functionality:
> Allocating missing parts of the page table becomes optional, which
> means that the function can be guaranteed not to error if allocation
> is disabled. Also
On Thu, Mar 21, 2019 at 01:22:22PM +, Thomas Hellstrom wrote:
> Resending since last series was sent through a mis-configured SMTP server.
>
> Hi,
> This is an early RFC to make sure I don't go too far in the wrong direction.
>
> Non-coherent GPUs that can't directly see contents in
Add two utilities to a) write-protect and b) clean all ptes pointing into
a range of an address space
The utilities are intended to aid in tracking dirty pages (either
driver-allocated system memory or pci device memory).
The write-protect utility should be used in conjunction with
page_mkwrite()
This is basically apply_to_page_range with added functionality:
Allocating missing parts of the page table becomes optional, which
means that the function can be guaranteed not to error if allocation
is disabled. Also passing of the closure struct and callback function
becomes different and more
Cc: Andrew Morton
Cc: Matthew Wilcox
Cc: Will Deacon
Cc: Peter Zijlstra
Cc: Rik van Riel
Cc: Minchan Kim
Cc: Michal Hocko
Cc: Huang Ying
Cc: Souptick Joarder
Cc: "Jérôme Glisse"
Cc: linux...@kvack.org
Cc: linux-ker...@vger.kernel.org
Resending since last series was sent through a
Driver fault callbacks are allowed to drop the mmap_sem when expecting
long hardware waits to avoid blocking other mm users. Allow the mkwrite
callbacks to do the same by returning early on VM_FAULT_RETRY.
In particular we want to be able to drop the mmap_sem when waiting for
a reservation object
On 21/03/2019 00:58, Andrey Smirnov wrote:
> Regardless of how it's going to be implemented in the end, there'd
> have to be a way to specify which HPD input is being used. Which means
True.
> a either a new DT binding or re-using already existing to be agreed on
> by DT folks. It just seems to
Hi,
On Wed, Mar 20, 2019 at 04:18:26PM +0530, Uma Shankar wrote:
> Added the const version of infoframe for DRM metadata
> for HDR.
>
> Signed-off-by: Uma Shankar
Unless there's a strong reason not to, I think this can be squashed
into patch 6.
> ---
> drivers/video/hdmi.c | 63
>
Hi,
On Wed, Mar 20, 2019 at 04:18:18PM +0530, Uma Shankar wrote:
> This patch implements get() and set() functions for HDR output
> metadata property.The blob data is received from userspace and
> saved in connector state, the same is returned as blob in get
> property call to userspace.
>
> v2:
On Wed, Mar 20, 2019 at 04:18:19PM +0530, Uma Shankar wrote:
> Enable Dynamic Range and Mastering Infoframe for HDR
> content, which is defined in CEA 861.3 spec.
>
> The metadata will be computed based on blending
> policy in userspace compositors and passed as a connector
> property blob to
1 - 100 of 179 matches
Mail list logo
