There is no synchronization between processes (e.g. 3D app and compositor)
within X on AMD hw. It works because of some hacks in Mesa.
Marek
On Wed, Mar 11, 2020 at 1:31 PM Jason Ekstrand wrote:
> All,
>
> Sorry for casting such a broad net with this one. I'm sure most people
> who reply will
: Update DRIVER_DATE to 20200225 (2020-02-25 10:41:22 -0800)
are available in the Git repository at:
git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-2020-03-13
for you to fetch changes up to 217a485c8399634abacd2f138b3524d2e78e8aad:
drm/i915: Update DRIVER_DATE to 20200313
On Fri, Mar 13, 2020 at 01:07:27PM -0500, Rob Herring wrote:
> Extra dtc warnings (roughly what W=1 enables) are now enabled by default
> when building the binding examples. These were fixed treewide in
> 5.6-rc5, but some new display bindings have been added with new
> warnings:
>
>
On Fri, Mar 13, 2020 at 5:02 PM Michel Dänzer wrote:
> On 2020-03-13 1:35 p.m., Kazlauskas, Nicholas wrote:
> > On 2020-03-12 10:32 a.m., Alex Deucher wrote:
> >> On Thu, Mar 5, 2020 at 4:21 PM Mario Kleiner
> >> wrote:
> >>>
> >>> Commit '16f17eda8bad ("drm/amd/display: Send vblank and user
>
On Thu, Mar 12, 2020 at 4:08 PM Gurchetan Singh
wrote:
>
>
>
> On Thu, Mar 12, 2020 at 2:29 AM Gerd Hoffmann wrote:
>>
>> On Wed, Mar 11, 2020 at 04:36:16PM -0700, Gurchetan Singh wrote:
>> > On Wed, Mar 11, 2020 at 3:36 AM Gerd Hoffmann wrote:
>> >
>> > > Hi,
>> > >
>> > > > I should've been
Many callers of drm_encoder_init use a drm_encoder_funcs
that contains only a drm_encoder_cleanup() callback.
drm_simple_encoder_init() was introduced to cover the
common case where an encoder with only basic functionality
was needed. But it really do not belong in drm_simple_*
Rename
Thomas Zimmermann had made a nice patch-set that introduced
drm_simple_encoder_init() which is already present in drm-misc-next.
While looking at this it was suddenly obvious to me that
this was functionalty that really should be included in drm_encoder.c
The case where the core could handle the
A lot of drivers requires only a basic encoder with no need
to extend the functionality.
This was previously implemented in drm_simple_kms_helper.c
but encoders are not necessarily simple despite no
need for a drm_encoder_funcs for adding functionality.
Move the init function to drm_encoder.c to
atmel-hlcdc has no need to extend the functionality of the
encoder, so use drm_encoder_init().
Signed-off-by: Sam Ravnborg
Cc: Sam Ravnborg
Cc: Boris Brezillon
Cc: Nicolas Ferre
Cc: Alexandre Belloni
Cc: Ludovic Desroches
Cc: Thomas Zimmermann
Cc: Laurent Pinchart
---
On Fri, Mar 13, 2020 at 12:21 PM Ville Syrjala
wrote:
>
> From: Ville Syrjälä
>
> Make the topology id const since we don't want to change it.
>
> Signed-off-by: Ville Syrjälä
Series is:
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/drm_connector.c | 4 ++--
>
On Fri, Mar 13, 2020 at 08:45:35AM +, Laxminarayan Bharadiya, Pankaj wrote:
>
>
> > -Original Message-
> > From: Ville Syrjälä
> > Sent: 12 March 2020 19:25
> > To: Laxminarayan Bharadiya, Pankaj
> >
> > Cc: jani.nik...@linux.intel.com; dan...@ffwll.ch; intel-
> >
On Fri, Mar 13, 2020 at 03:35:30PM +0100, Gerd Hoffmann wrote:
> Hi,
>
> > > + if (pci_request_region(pdev, 0, "bochs-drm") != 0)
> > > + DRM_WARN("Cannot request framebuffer, boot fb still active?\n");
> > So you could use drm_WARN() which is what is preferred these days.
>
> Nope,
Extra dtc warnings (roughly what W=1 enables) are now enabled by default
when building the binding examples. These were fixed treewide in
5.6-rc5, but some new display bindings have been added with new
warnings:
Documentation/devicetree/bindings/display/ti/ti,am65x-dss.example.dts:21.27-49.11:
On 3/7/20 7:02 AM, Leon He wrote:
From: Leon He
There are two errors in the dmabuf-heap selftest:
1. The 'char name[5]' was not initialized to zero, which will cause
strcmp(name, "vgem") failed in check_vgem().
2. The return value of test_alloc_errors() should be reversed, other-
wise
Hi Dave,
The following changes since commit bb6d3fb354c5ee8d6bde2d576eb7220ea09862b9:
Linux 5.6-rc1 (2020-02-09 16:08:48 -0800)
are available in the Git repository at:
git://anongit.freedesktop.org/tegra/linux tags/drm/tegra/for-5.7-rc1
for you to fetch changes up to
Done. There was a bit of fuzz when applying it. Please double check it:
https://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-next=a7fbb630c5485f5095146df46f04c2ca1a24c299
Thanks,
Alex
Alex
On Fri, Mar 13, 2020 at 10:51 AM Lucas Stach wrote:
>
> Hi Alex,
>
> since you seem to be picking
From: Ville Syrjälä
Make the topology id const since we don't want to change it.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_connector.c | 4 ++--
include/drm/drm_connector.h | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_connector.c
From: Ville Syrjälä
A+B on the previous line, B+A on the next line. Brain hurts.
Signed-off-by: Ville Syrjälä
---
include/drm/drm_displayid.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/drm/drm_displayid.h b/include/drm/drm_displayid.h
index
From: Ville Syrjälä
The EDID extension block checksum byte is not part of the
actual DispID data, so don't use it in validate_displayid().
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_edid.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git
From: Ville Syrjälä
Currently the DispID tile block gets parsed in drm_get_edid(), which
is an odd place for it considering we parse nothing else there. Also
this doesn't work for override EDIDs since
drm_connector_update_edid_property() refuses to do its job twice
in such cases. Thus we never
From: Ville Syrjälä
Instead of everyone having to call validate_displayid() let's just
have drm_find_displayid_extension() do it for them.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_edid.c | 19 +--
1 file changed, 5 insertions(+), 14 deletions(-)
diff --git
From: Ville Syrjälä
The fact that the DispID starts at byte offset 1 is due to
the DispID coming from and EDID extension block (the first byte
being the extesion block tag). Instead of hadrdocoding that idx==1
assumptions all over let's just have drm_find_displayid_extension()
return it since it
From: Ville Syrjälä
I was playing around with the tile stuff a bit and noticed a bunch of
issues in the DisplayID parser. This series aims to fix what I found.
Ville Syrjälä (9):
drm: Constify topology id
drm/edid: Swap some operands in for_each_displayid_db()
drm/edid: Remove idx==1
From: Ville Syrjälä
As with the byte offset (idx) drm_find_displayid_extension() is
the only one who actually knows how much data the resulting DispID
block can contain. So return the length from therein instead of
assuming it's the EDID block length all over.
Signed-off-by: Ville Syrjälä
---
From: Ville Syrjälä
Throw out the magic '5' from validate_displayid() and replace with
the actual thing we mean sizeof(header)+checksum. Also rewrite the
checksum loop to be less hard to parse for mere mortals.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_edid.c | 13 -
1
From: Ville Syrjälä
Currently the code assumes that the entire EDID extesion block
can be taken up by the DispID blocks. That is not true. There
is at least always the DispID checksum, and potentially fill
bytes if the extension block uses the interior fill scheme
to pad out to fill EDID block
On 3/3/20 10:34 PM, Leon He wrote:
If the 'name' array in check_vgem() was not initialized to null, the
value of name[4] may be random. Which will cause strcmp(name, "vgem")
failed.
Nit: "to fail" instead of "failed"
Signed-off-by: Leon He
---
On 13/03/2020 15:17, Laurent Pinchart wrote:
> Hi Neil,
>
> On Fri, Mar 13, 2020 at 03:12:13PM +0100, Neil Armstrong wrote:
>> On 13/03/2020 14:40, Laurent Pinchart wrote:
>>> On Wed, Mar 11, 2020 at 01:51:33PM +0100, Phong LE wrote:
Add the ITE bridge HDMI it66121 bindings.
Hi Alex,
since you seem to be picking up scheduler patches, can I ask you to
take this one through your tree?
Regards,
Lucas
On Mo, 2020-01-20 at 11:59 +0100, Christian König wrote:
> Am 20.01.20 um 11:51 schrieb Lucas Stach:
> > 1db8c142b6c5 (drm/scheduler: Add
It's to restore the gamma ramp to be the default linear one. Let's say
that the driver doesn't have the GAMMA_LUT property support, and then
you want to modeset with C8 (indexed) format. That means that modeset
has to set the LUT to make the indexed lookups work (which it does, it
all works, you
On 2020-03-13 1:35 p.m., Kazlauskas, Nicholas wrote:
> On 2020-03-12 10:32 a.m., Alex Deucher wrote:
>> On Thu, Mar 5, 2020 at 4:21 PM Mario Kleiner
>> wrote:
>>>
>>> Commit '16f17eda8bad ("drm/amd/display: Send vblank and user
>>> events at vsartup for DCN")' introduces a new way of pageflip
>>>
Hi,
> > + if (pci_request_region(pdev, 0, "bochs-drm") != 0)
> > + DRM_WARN("Cannot request framebuffer, boot fb still active?\n");
> So you could use drm_WARN() which is what is preferred these days.
Nope, this isn't yet in -fixes.
cheers,
Gerd
On Fri, Mar 13, 2020 at 6:18 AM Christian König
wrote:
>
> Am 13.03.20 um 10:56 schrieb Lucas Stach:
> > From: Robert Beckett
> >
> > Add a new trace event to show when jobs are run on the HW.
> >
> > Signed-off-by: Robert Beckett
> > Signed-off-by: Lucas Stach
>
> There is also the scheduled
Hi Neil,
On Fri, Mar 13, 2020 at 03:12:13PM +0100, Neil Armstrong wrote:
> On 13/03/2020 14:40, Laurent Pinchart wrote:
> > On Wed, Mar 11, 2020 at 01:51:33PM +0100, Phong LE wrote:
> >> Add the ITE bridge HDMI it66121 bindings.
> >>
> >> Signed-off-by: Phong LE
> >> ---
> >>
Hi Lee, Daniel,
On 24/02/2020 14:37, Daniel Thompson wrote:
> On Mon, Feb 24, 2020 at 02:07:48PM +, Jon Hunter wrote:
>> If probing the LP885x backlight fails after the regulators have been
>> enabled, then the following warning is seen when releasing the
>> regulators ...
>>
>> WARNING:
On 13/03/2020 15:38, Laurent Pinchart wrote:
Hi Tomi,
On Fri, Mar 13, 2020 at 03:30:15PM +0200, Tomi Valkeinen wrote:
On 13/03/2020 15:22, Laurent Pinchart wrote:
On Fri, Mar 13, 2020 at 02:24:10PM +0200, Tomi Valkeinen wrote:
Remove unused writeback code. This code will never be used, as
On 13/03/2020 14:40, Laurent Pinchart wrote:
> Hi Phong,
>
> Thank you for the patch.
>
> On Wed, Mar 11, 2020 at 01:51:33PM +0100, Phong LE wrote:
>> Add the ITE bridge HDMI it66121 bindings.
>>
>> Signed-off-by: Phong LE
>> ---
>> .../bindings/display/bridge/ite,it66121.yaml | 98
Hi Phong,
Thank you for the patch.
On Wed, Mar 11, 2020 at 01:51:34PM +0100, Phong LE wrote:
> This commit is a simple driver for bridge HMDI it66121.
> The input format is RBG and there is no color conversion.
> Audio, HDCP and CEC are not supported yet.
>
> Signed-off-by: Phong LE
> ---
>
On 13/03/2020 15:22, Laurent Pinchart wrote:
Hi Tomi,
Thank you for the patch.
On Fri, Mar 13, 2020 at 02:24:10PM +0200, Tomi Valkeinen wrote:
Remove unused writeback code. This code will never be used, as omapfb is
being deprecated.
I'm fine with that, but out of curiosity, is there any
Hi Phong,
Thank you for the patch.
On Wed, Mar 11, 2020 at 01:51:33PM +0100, Phong LE wrote:
> Add the ITE bridge HDMI it66121 bindings.
>
> Signed-off-by: Phong LE
> ---
> .../bindings/display/bridge/ite,it66121.yaml | 98 +++
> 1 file changed, 98 insertions(+)
> create
Hi Tomi,
On Fri, Mar 13, 2020 at 03:30:15PM +0200, Tomi Valkeinen wrote:
> On 13/03/2020 15:22, Laurent Pinchart wrote:
> > On Fri, Mar 13, 2020 at 02:24:10PM +0200, Tomi Valkeinen wrote:
> >> Remove unused writeback code. This code will never be used, as omapfb is
> >> being deprecated.
> >
> >
Am 13.03.20 um 12:21 schrieb Christoph Hellwig:
On Thu, Mar 12, 2020 at 11:19:28AM -0300, Jason Gunthorpe wrote:
The non-page scatterlist is also a big concern for RDMA as we have
drivers that want the page list, so even if we did as this series
contemplates I'd have still have to split the
Hi Tomi,
Thank you for the patch.
On Fri, Mar 13, 2020 at 02:24:10PM +0200, Tomi Valkeinen wrote:
> Remove unused writeback code. This code will never be used, as omapfb is
> being deprecated.
I'm fine with that, but out of curiosity, is there any particular reason
to remove that code now
Remove unused writeback code. This code will never be used, as omapfb is
being deprecated.
Signed-off-by: Tomi Valkeinen
---
drivers/video/fbdev/omap2/omapfb/dss/dispc.c | 114 ---
drivers/video/fbdev/omap2/omapfb/dss/dss.h | 20
2 files changed, 134 deletions(-)
diff
On 2020-03-12 10:32 a.m., Alex Deucher wrote:
On Thu, Mar 5, 2020 at 4:21 PM Mario Kleiner wrote:
Commit '16f17eda8bad ("drm/amd/display: Send vblank and user
events at vsartup for DCN")' introduces a new way of pageflip
completion handling for DCN, and some trouble.
The current
On Thu, 12 Mar 2020 18:01:12 +0200
Ville Syrjälä wrote:
> On Thu, Mar 12, 2020 at 03:37:03PM +, Laxminarayan Bharadiya, Pankaj
> wrote:
> >
> >
> > > -Original Message-
> > > From: Ville Syrjälä
> > > Sent: 12 March 2020 19:35
> > > To: Laxminarayan Bharadiya, Pankaj
> > >
> >
Am 12.03.20 um 16:57 schrieb Jason Ekstrand:
On Wed, Mar 11, 2020 at 8:18 AM Christian König
wrote:
Am 11.03.20 um 04:43 schrieb Jason Ekstrand:
Explicit synchronization is the future. At least, that seems to be what
most userspace APIs are agreeing on at this point. However, most of our
Am 13.03.20 um 10:56 schrieb Lucas Stach:
From: Robert Beckett
Add a new trace event to show when jobs are run on the HW.
Signed-off-by: Robert Beckett
Signed-off-by: Lucas Stach
There is also the scheduled fence we could used for this, but this trace
point adds a few extra fields which
From: Robert Beckett
Add a new trace event to show when jobs are run on the HW.
Signed-off-by: Robert Beckett
Signed-off-by: Lucas Stach
---
.../gpu/drm/scheduler/gpu_scheduler_trace.h | 27 +++
drivers/gpu/drm/scheduler/sched_main.c| 1 +
2 files changed, 28
Hi Gred.
On Fri, Mar 13, 2020 at 09:41:52AM +0100, Gerd Hoffmann wrote:
> Shutdown of firmware framebuffer has a bunch of problems. Because
> of this the framebuffer region might still be reserved even after
> drm_fb_helper_remove_conflicting_pci_framebuffers() returned.
>
> Don't consider
> -Original Message-
> From: Ville Syrjälä
> Sent: 12 March 2020 19:25
> To: Laxminarayan Bharadiya, Pankaj
>
> Cc: jani.nik...@linux.intel.com; dan...@ffwll.ch; intel-
> g...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; airl...@linux.ie;
>
Shutdown of firmware framebuffer has a bunch of problems. Because
of this the framebuffer region might still be reserved even after
drm_fb_helper_remove_conflicting_pci_framebuffers() returned.
Don't consider pci_request_region() failure for the framebuffer
region as fatal error to workaround
Add helper functions that can allow i915 to detect and control
an integrated privacy screen via ACPI methods. These shall be used
in the next patch.
Signed-off-by: Rajat Jain
---
v9: same as v8
v8: Initial version. formed by refactoring the previous patch 4.
print the connector name in the
On Thu, Mar 12, 2020 at 04:16:33PM +, Steven Price wrote:
> > Actually, while you are looking at this, do you think we should be
> > adding at least READ_ONCE in the pagewalk.c walk_* functions? The
> > multiple references of pmd, pud, etc without locking seems sketchy to
> > me.
>
> I agree
On Thu, Mar 12, 2020 at 6:36 PM Jason Ekstrand wrote:
> From the perspective of a Wayland compositor (I used to play in this
> space), they'd love to implement the new explicit sync extension but
> can't. Sure, they could wire up the extension, but the moment they go
> to flip a client buffer to
On 3/8/20 12:50 PM, Sam Ravnborg wrote:
> Fix following type af warnings in the panel bindings:
>
> Warning (unit_address_vs_reg): /example-0/dsi/panel: node has a reg or ranges
> property, but no unit name
> Warning (unit_address_vs_reg): /example-0/dsi@ff45: node has a unit name,
> but
Driver fails to probe with -EPROBE_DEFER, which produces a bit noisy error
message in KMSG during kernel's boot up. This happens because voltage
regulators tend to be probed later than the DRM driver.
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/tegra/hdmi.c | 34
On Thu, Mar 12, 2020 at 04:39:02PM +0100, Christian König wrote:
> > > The structure for holding dma addresses doesn't really exist
> > > in a generic form, but would be an array of these structures:
> > >
> > > struct dma_sg {
> > > dma_addr_t addr;
> > > u32 len;
> > > };
>
On Thu, Mar 12, 2020 at 02:40:08PM +, Steven Price wrote:
> On 12/03/2020 14:27, Jason Gunthorpe wrote:
> > On Thu, Mar 12, 2020 at 10:28:13AM +, Steven Price wrote:
> > > By refactoring to deal with the !pud_huge(pud) || !pud_devmap(pud)
> > > condition early it's possible to remove the
Krzysztof Kozlowski writes:
> diff --git a/arch/powerpc/kernel/iomap.c b/arch/powerpc/kernel/iomap.c
> index 5ac84efc6ede..9fe4fb3b08aa 100644
> --- a/arch/powerpc/kernel/iomap.c
> +++ b/arch/powerpc/kernel/iomap.c
> @@ -15,23 +15,23 @@
> * Here comes the ppc64 implementation of the IOMAP
>
On Thu, Mar 12, 2020 at 10:28:13AM +, Steven Price wrote:
> By refactoring to deal with the !pud_huge(pud) || !pud_devmap(pud)
> condition early it's possible to remove the 'ret' variable and remove a
> level of indentation from half the function making the code easier to
> read.
>
> No
On Wed, Mar 11, 2020 at 06:36:47PM -0700, Ralph Campbell wrote:
> > @@ -390,8 +384,15 @@ static int hmm_vma_walk_pmd(pmd_t *pmdp,
> > return -EBUSY;
> > }
> > return hmm_pfns_fill(start, end, range, HMM_PFN_NONE);
> > - } else if (!pmd_present(pmd))
>
pmd_to_hmm_pfn_flags() already checks it and makes the cpu flags 0. If no
fault is requested then the pfns should be returned with the not valid
flags.
It should not unconditionally fault if faulting is not requested.
Fixes: 2aee09d8c116 ("mm/hmm: change hmm_vma_fault() to allow write fault on
On Thu, Mar 12, 2020 at 05:02:18PM +, Steven Price wrote:
> > Having the walker deref the pointer and pass the value it into the ops
> > for use rather than repeatedly de-refing an unlocked value seems like
> > a much safer design to me.
>
> Yeah that sounds like a good idea.
Ok.. let see
On Thu, Mar 12, 2020 at 03:47:29AM -0700, Christoph Hellwig wrote:
> On Thu, Mar 12, 2020 at 11:31:35AM +0100, Christian König wrote:
> > But how should we then deal with all the existing interfaces which already
> > take a scatterlist/sg_table ?
> >
> > The whole DMA-buf design and a lot of
On 2020-03-12 8:19 a.m., Jason Gunthorpe wrote:
> On Thu, Mar 12, 2020 at 03:47:29AM -0700, Christoph Hellwig wrote:
>> On Thu, Mar 12, 2020 at 11:31:35AM +0100, Christian König wrote:
>>> But how should we then deal with all the existing interfaces which already
>>> take a scatterlist/sg_table
On Wed, Mar 11, 2020 at 06:28:30PM -0700, Ralph Campbell wrote:
> > mm/hmm.c | 8 ++--
> > 1 file changed, 6 insertions(+), 2 deletions(-)
> >
> > diff --git a/mm/hmm.c b/mm/hmm.c
> > index 72e5a6d9a41756..35f85424176d14 100644
> > +++ b/mm/hmm.c
> > @@ -325,6 +325,7 @@ static int
12.03.2020 12:33, Thierry Reding пишет:
> On Mon, Mar 09, 2020 at 01:38:09AM +0300, Dmitry Osipenko wrote:
>> Driver fails to probe with -EPROBE_DEFER if display output isn't ready
>> yet. This produces a bit noisy error message in KMSG during kernel's boot
>> up on Tegra20 and Tegra30 because RGB
68 matches
Mail list logo
