On Mon, 17 Jun 2019 at 16:56, Rob Herring wrote:
>
> On Sun, Jun 16, 2019 at 11:15 PM Tomeu Vizoso
> wrote:
> >
> > On Fri, 14 Jun 2019 at 23:22, Rob Herring wrote:
> > >
> > > On Wed, Jun 12, 2019 at 6:55 AM Tomeu Vizoso
> > > wrote:
> > > >
> > > > On Mon, 10 Jun 2019 at 19:06, Rob Herring
On Thu, 2019-06-20 at 11:14 +1000, Alastair D'Silva wrote:
> On Wed, 2019-06-19 at 17:35 -0700, Joe Perches wrote:
> > On Thu, 2019-06-20 at 09:15 +1000, Alastair D'Silva wrote:
> > > On Wed, 2019-06-19 at 09:31 -0700, Joe Perches wrote:
> > > > On Mon, 2019-06-17 at 12:04 +1000, Alastair D'Silva
https://bugs.freedesktop.org/show_bug.cgi?id=96838
--- Comment #1 from Michael Silver ---
I can confirm this on a Dell PowerEdge 2800 running Ubuntu 18.04.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing
Hi Brendan,
I am only responding to this because you asked me to in the v4 thread.
Thank you for evaluating my comments in the v4 thread and asking me to
comment on v5
On 6/17/19 1:25 AM, Brendan Higgins wrote:
> ## TL;DR
>
> A not so quick follow-up to Stephen's suggestions on PATCH v4.
It looks like lima_clk_init will have the same problem if devm_clk_get
returns -EPROBE_DEFER.
Regards,
Qiang
On Wed, Jun 19, 2019 at 2:55 AM Krzysztof Kozlowski wrote:
>
> There is no point to print deferred probe (and its failures to get
> resources) as an error. For example getting a
Looks good for me, patch is:
Reviewed-by: Qiang Yu
I'll apply it to drm-misc-next.
Regards,
Qiang
On Wed, Jun 19, 2019 at 2:55 AM Krzysztof Kozlowski wrote:
>
> Mark long numbers with ULL to silence the Smatch warning:
>
> drivers/gpu/drm/lima/lima_device.c:314:32: warning: constant
On Thu, 2019-06-20 at 09:15 +1000, Alastair D'Silva wrote:
> On Wed, 2019-06-19 at 09:31 -0700, Joe Perches wrote:
> > On Mon, 2019-06-17 at 12:04 +1000, Alastair D'Silva wrote:
> > > From: Alastair D'Silva
> > >
> > > Apologies for the large CC list, it's a heads up for those
> > > responsible
Quoting Brendan Higgins (2019-06-17 01:25:56)
> diff --git a/kunit/test.c b/kunit/test.c
> new file mode 100644
> index 0..d05d254f1521f
> --- /dev/null
> +++ b/kunit/test.c
> @@ -0,0 +1,210 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Base unit test (KUnit) API.
> + *
> + *
The hardware supports either size. Also add checks to ensure that only
these two sizes may be used for supplying a LUT.
Finally, experimental evidence suggests you can't mix sizes for degamma
and gamma. Disallow this as well.
Signed-off-by: Ilia Mirkin
---
Note that all the gv100+ changes are
Convert the common panel bindings to DT schema consolidating scattered
definitions to a single schema file.
The 'simple-panel' binding just a collection of properties and not a
complete binding itself. All of the 'simple-panel' properties are
covered by the panel-common.txt binding with the
Convert the ampire,am-480272h3tmqw-t01h panel binding to DT schema.
Cc: Thierry Reding
Cc: Sam Ravnborg
Cc: Maxime Ripard
Cc: Laurent Pinchart
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Rob Herring
---
.../panel/ampire,am-480272h3tmqw-t01h.txt | 26
Convert the panel-lvds binding to use DT schema. The panel-lvds schema
inherits from the panel-common.yaml schema and specific LVDS panel
bindings should inherit from this schema.
Cc: Thierry Reding
Cc: Sam Ravnborg
Cc: Maxime Ripard
Cc: Laurent Pinchart
Cc: dri-devel@lists.freedesktop.org
Convert the innolux,ee101ia-01 LVDS panel binding to DT schema.
Cc: Thierry Reding
Cc: Sam Ravnborg
Cc: Maxime Ripard
Cc: Laurent Pinchart
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Rob Herring
---
.../display/panel/innolux,ee101ia-01d.txt | 7 ---
Hi,
On Wed, Jun 12, 2019 at 1:51 AM Neil Armstrong wrote:
>
> When using an I2S source using a different clock source (usually the I2S
> audio HW uses dedicated PLLs, different from the HDMI PHY PLL), fixed
> CTS values will cause some frequent audio drop-out and glitches as
> reported on
On Wed, Jun 19, 2019 at 10:42 PM Jason Gunthorpe wrote:
>
> On Wed, Jun 19, 2019 at 10:18:43PM +0200, Daniel Vetter wrote:
> > On Wed, Jun 19, 2019 at 10:13 PM Jason Gunthorpe wrote:
> > > On Wed, Jun 19, 2019 at 09:57:15PM +0200, Daniel Vetter wrote:
> > > > On Wed, Jun 19, 2019 at 6:50 PM
Hi,
On Wed, Jun 19, 2019 at 8:23 AM Neil Armstrong wrote:
>
> On 18/06/2019 19:23, Jernej Škrabec wrote:
> > Hi!
> >
> > Dne torek, 18. junij 2019 ob 01:55:58 CEST je Douglas Anderson napisal(a):
> >> Let's add some better support for HDMI audio to dw_hdmi.
> >> Specifically:
> >>
> >> 1. For
On some platforms using dw_hdmi it may not be possible to make an HDMI
pixel clock exactly, but it may be possible to make a rate that is
close enough to be within spec. For instance on rk3288 we can make
25,176,471 Hz instead of 25,174,825.1748... Hz (25.2 MHz / 1.001). A
future patch to the
Let's add some better support for HDMI audio to dw_hdmi.
Specifically:
1. For 44.1 kHz audio the old code made the assumption that an N of
6272 was right most of the time. That wasn't true and the new table
should pick a more ideal value.
2. The new table has values from the HDMI spec for 297
On Wed, Jun 19, 2019 at 10:18:43PM +0200, Daniel Vetter wrote:
> On Wed, Jun 19, 2019 at 10:13 PM Jason Gunthorpe wrote:
> > On Wed, Jun 19, 2019 at 09:57:15PM +0200, Daniel Vetter wrote:
> > > On Wed, Jun 19, 2019 at 6:50 PM Jason Gunthorpe wrote:
> > > > On Tue, Jun 18, 2019 at 05:22:15PM
On Wed, Jun 19, 2019 at 1:17 PM Rob Herring wrote:
>
> On Sun, Jun 16, 2019 at 7:29 AM Brian Masney wrote:
> >
> > Some A3xx and A4xx Adreno GPUs do not have GMEM inside the GPU core and
> > must use the On Chip MEMory (OCMEM) in order to be functional. Add the
> > optional ocmem property to the
On Wed, Jun 19, 2019 at 10:13 PM Jason Gunthorpe wrote:
> On Wed, Jun 19, 2019 at 09:57:15PM +0200, Daniel Vetter wrote:
> > On Wed, Jun 19, 2019 at 6:50 PM Jason Gunthorpe wrote:
> > > On Tue, Jun 18, 2019 at 05:22:15PM +0200, Daniel Vetter wrote:
> > > > On Tue, May 21, 2019 at 11:44:11AM
On Wed, 19 Jun 2019, Daniel Vetter wrote:
> - figure out what to do with the libdrm manpages. Some stuff we really
> want to also document there. But geez nroff. Maybe we need to stuff
> libdrm into the kernel, dunno.
How would people feel about converting libdrm man pages to rst, and
using
On Sun, Jun 16, 2019 at 7:29 AM Brian Masney wrote:
>
> Some A3xx and A4xx Adreno GPUs do not have GMEM inside the GPU core and
> must use the On Chip MEMory (OCMEM) in order to be functional. Add the
> optional ocmem property to the Adreno Graphics Management Unit bindings.
>
> Signed-off-by:
On Wed, Jun 19, 2019 at 09:57:15PM +0200, Daniel Vetter wrote:
> On Wed, Jun 19, 2019 at 6:50 PM Jason Gunthorpe wrote:
> > On Tue, Jun 18, 2019 at 05:22:15PM +0200, Daniel Vetter wrote:
> > > On Tue, May 21, 2019 at 11:44:11AM -0400, Jerome Glisse wrote:
> > > > On Mon, May 20, 2019 at
On Wed, Jun 19, 2019 at 6:50 PM Jason Gunthorpe wrote:
> On Tue, Jun 18, 2019 at 05:22:15PM +0200, Daniel Vetter wrote:
> > On Tue, May 21, 2019 at 11:44:11AM -0400, Jerome Glisse wrote:
> > > On Mon, May 20, 2019 at 11:39:42PM +0200, Daniel Vetter wrote:
> > > > Just a bit of paranoia, since if
On Wed, Jun 19, 2019 at 9:36 PM Simon Ser wrote:
>
> Hi all,
>
> With Wayland compositors and DRM leases, the number of DRM userspace
> programs has increased (and will probably continue to increase).
> However it's been pretty hard to find good DRM docs for userspace.
>
> The resources currently
On Wed, Jun 19, 2019 at 12:42 PM Jason Gunthorpe wrote:
>
> On Thu, Jun 13, 2019 at 06:23:04PM -0700, John Hubbard wrote:
> > On 6/13/19 5:43 PM, Ira Weiny wrote:
> > > On Thu, Jun 13, 2019 at 07:58:29PM +, Jason Gunthorpe wrote:
> > >> On Thu, Jun 13, 2019 at 12:53:02PM -0700, Ralph Campbell
Hi all,
With Wayland compositors and DRM leases, the number of DRM userspace
programs has increased (and will probably continue to increase).
However it's been pretty hard to find good DRM docs for userspace.
The resources currently available are:
- The kernel docs, although only the high level
On Wed, Jun 19, 2019 at 12:32 PM Sean Paul wrote:
>
> On Wed, Jun 19, 2019 at 12:17:23PM -0700, Nathan Chancellor wrote:
> > Clang warns:
> >
> > drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c:80:6: warning: logical not is
> > only applied to the left hand side of this bitwise operator
> >
On Wed, Jun 19, 2019 at 12:17:23PM -0700, Nathan Chancellor wrote:
> Clang warns:
>
> drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c:80:6: warning: logical not is
> only applied to the left hand side of this bitwise operator
> [-Wlogical-not-parentheses]
> if (!phy->cfg->quirks &
Hey team,
2 fixes this week, the 5.2 trickle continues.
drm-misc-fixes-2019-06-19:
panfrost- Only unmap BO's if they're mapped (Boris)
core- Handle buffer desc copy_to_user failure properly (Dan)
Cc: Boris Brezillon
Cc: Dan Carpenter
Cheers, Sean
The following changes since commit
Clang warns:
drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c:80:6: warning: logical not is
only applied to the left hand side of this bitwise operator
[-Wlogical-not-parentheses]
if (!phy->cfg->quirks & V3_0_0_10NM_OLD_TIMINGS_QUIRK) {
^ ~
On Wed, Jun 19, 2019 at 03:13:40PM -0400, Sean Paul wrote:
> On Wed, Jun 19, 2019 at 12:19 PM Nathan Chancellor
> wrote:
> >
> > Clang warns:
> >
> > drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c:80:6: warning: logical not is
> > only applied to the left hand side of this bitwise operator
> >
On Wed, Jun 19, 2019 at 12:19 PM Nathan Chancellor
wrote:
>
> Clang warns:
>
> drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c:80:6: warning: logical not is
> only applied to the left hand side of this bitwise operator
> [-Wlogical-not-parentheses]
> if (!phy->cfg->quirks &
On Vivante GPUs with an iommu-v1, the gpu linear window's
position must be determined at probe time, and cannot change
during the driver's lifetime.
The existing code attempts to guess a suitable window position
using the dma mask, but this does not always work [1].
According to a recent thread
Replace the duplicated versions of the while loop with the new macro.
Signed-off-by: Andres Rodriguez
Cc: Dave Airlie
---
This patch depends on "drm/edid: parse CEA blocks embedded in DisplayID"
I didn't send them together to avoid grouping the portion that
was cc:stable and the "touch ups"
On Wed, Jun 19, 2019 at 06:49:11PM +0100, Emil Velikov wrote:
> On Wed, 19 Jun 2019 at 17:33, Ville Syrjälä
> wrote:
> >
> > On Wed, Jun 19, 2019 at 05:03:53PM +0100, Emil Velikov wrote:
> > > Hi all,
> > >
> > > Recently I have been looking at i915 and its rather interesting planes.
> > >
> > >
On Wed, Jun 19, 2019 at 12:15:26PM -0600, Jordan Crouse wrote:
> On Sun, Jun 16, 2019 at 09:29:30AM -0400, Brian Masney wrote:
> > The files a3xx_gpu.c and a4xx_gpu.c have ifdefs for the OCMEM support
> > that was missing upstream. Add two new functions (adreno_gpu_ocmem_init
> > and
From: Sean Paul
If state allocation fails, we still try to give back the reference on
it. Also initialize ret in case the crtc is not enabled and we hit the
eject button.
Fixes: 1452c25b0e60 ("drm: Add helpers to kick off self refresh mode in
drivers")
Cc: Daniel Vetter
Cc: Jose Souza
Cc:
On Sun, Jun 16, 2019 at 09:29:30AM -0400, Brian Masney wrote:
> The files a3xx_gpu.c and a4xx_gpu.c have ifdefs for the OCMEM support
> that was missing upstream. Add two new functions (adreno_gpu_ocmem_init
> and adreno_gpu_ocmem_cleanup) that removes some duplicated code. We also
> need to
DisplayID blocks allow embedding of CEA blocks. The payloads are
identical to traditional top level CEA extension blocks, but the header
is slightly different.
This change allows the CEA parser to find a CEA block inside a DisplayID
block. Additionally, it adds support for parsing the embedded
On Sun, Jun 16, 2019 at 09:29:26AM -0400, Brian Masney wrote:
> Some A3xx and A4xx Adreno GPUs do not have GMEM inside the GPU core and
> must use the On Chip MEMory (OCMEM) in order to be functional. Add the
> optional ocmem property to the Adreno Graphics Management Unit bindings.
>
>
On Wed, 19 Jun 2019 at 17:33, Ville Syrjälä
wrote:
>
> On Wed, Jun 19, 2019 at 05:03:53PM +0100, Emil Velikov wrote:
> > Hi all,
> >
> > Recently I have been looking at i915 and its rather interesting planes.
> >
> > In particular newer hardware is capable of using 3 universal planes and
> > a
On Tue, Jun 18, 2019 at 05:22:15PM +0200, Daniel Vetter wrote:
> On Tue, May 21, 2019 at 11:44:11AM -0400, Jerome Glisse wrote:
> > On Mon, May 20, 2019 at 11:39:42PM +0200, Daniel Vetter wrote:
> > > Just a bit of paranoia, since if we start pushing this deep into
> > > callchains it's hard to
On Wed, Jun 19, 2019 at 9:37 AM Jason Gunthorpe wrote:
>
> On Wed, Jun 19, 2019 at 11:40:32AM +0200, Christoph Hellwig wrote:
> > On Tue, Jun 18, 2019 at 12:47:10PM -0700, Dan Williams wrote:
> > > > Git tree:
> > > >
> > > > git://git.infradead.org/users/hch/misc.git hmm-devmem-cleanup.2
> >
On Wed, Jun 19, 2019 at 05:03:53PM +0100, Emil Velikov wrote:
> Hi all,
>
> Recently I have been looking at i915 and its rather interesting planes.
>
> In particular newer hardware is capable of using 3 universal planes and
> a separate cursor-only plane. At the same time only 1 top-most plane
On Mon, 2019-06-17 at 12:04 +1000, Alastair D'Silva wrote:
> From: Alastair D'Silva
>
> Apologies for the large CC list, it's a heads up for those responsible
> for subsystems where a prototype change in generic code causes a change
> in those subsystems.
>
> This series enhances hexdump.
On Wed, Jun 19, 2019 at 12:33:33PM -0300, Ezequiel Garcia wrote:
> On Wed, 2019-06-19 at 18:03 +0300, Ville Syrjälä wrote:
> > On Wed, Jun 19, 2019 at 10:18:18AM -0300, Ezequiel Garcia wrote:
> > > On Wed, 2019-06-19 at 06:20 +, Shankar, Uma wrote:
> > > > > -Original Message-
> > > >
On Mon, Jun 17, 2019 at 10:33:42AM +0200, Christoph Hellwig wrote:
> > drivers/infiniband/hw/cxgb4/qp.c
> >129 static int alloc_host_sq(struct c4iw_rdev *rdev, struct t4_sq *sq)
> >130 {
> >131 sq->queue = dma_alloc_coherent(&(rdev->lldi.pdev->dev),
> > sq->memsize,
> >
Hi Lowry,
On Mon, Jun 17, 2019 at 06:55:49AM +0100, Lowry Li (Arm Technology China) wrote:
> Adds runtime and system power management support in KMS kernel driver.
>
> Depends on:
> - https://patchwork.freedesktop.org/series/61650/
> - https://patchwork.freedesktop.org/series/60083/
>
>
Hi all,
Recently I have been looking at i915 and its rather interesting planes.
In particular newer hardware is capable of using 3 universal planes and
a separate cursor-only plane. At the same time only 1 top-most plane can
be enabled - lets calls those plane3 or cursor.
Hence currently the
On Wed, 2019-06-19 at 18:03 +0300, Ville Syrjälä wrote:
> On Wed, Jun 19, 2019 at 10:18:18AM -0300, Ezequiel Garcia wrote:
> > On Wed, 2019-06-19 at 06:20 +, Shankar, Uma wrote:
> > > > -Original Message-
> > > > From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On
> >
On Wed, 19 Jun 2019, Sean Paul wrote:
> On Wed, Jun 19, 2019 at 01:01:41PM +0300, Dan Carpenter wrote:
>> This test is flipped around so it either leads to a memory leak or a
>> NULL dereference.
>>
>> Fixes: 1452c25b0e60 ("drm: Add helpers to kick off self refresh mode in
>> drivers")
>>
On 18/06/2019 19:23, Jernej Škrabec wrote:
> Hi!
>
> Dne torek, 18. junij 2019 ob 01:55:58 CEST je Douglas Anderson napisal(a):
>> Let's add some better support for HDMI audio to dw_hdmi.
>> Specifically:
>>
>> 1. For 44.1 kHz audio the old code made the assumption that an N of
>> 6272 was right
On Wed, Jun 19, 2019 at 01:01:41PM +0300, Dan Carpenter wrote:
> This test is flipped around so it either leads to a memory leak or a
> NULL dereference.
>
> Fixes: 1452c25b0e60 ("drm: Add helpers to kick off self refresh mode in
> drivers")
> Signed-off-by: Dan Carpenter
Thanks for the patch
On Wed, Jun 19, 2019 at 10:18:18AM -0300, Ezequiel Garcia wrote:
> On Wed, 2019-06-19 at 06:20 +, Shankar, Uma wrote:
> > > -Original Message-
> > > From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On
> > > Behalf Of
> > > Ezequiel Garcia
> > > Sent: Friday, June 14,
On Wed, Jun 19, 2019 at 01:07:05AM -0700, Christoph Hellwig wrote:
> On Wed, Jun 19, 2019 at 12:53:55AM +, Kuehling, Felix wrote:
> > This code is derived from our old MMU notifier code. Before HMM we used
> > to register a single MMU notifier per mm_struct and look up virtual
> > address
Reduce size of duplicated comments by switching to use SPDX identifier.
No functional change.
While here, correct MODULE_LICENSE() string to be aligned with license text.
Signed-off-by: Andy Shevchenko
---
drivers/video/backlight/pwm_bl.c | 11 +++
1 file changed, 3 insertions(+), 8
> rename Documentation/{ => driver-api}/atomic_bitops.rst (99%)
Same here: NAK, this document does not belong to driver-api.
I also realize that, despite previous notices, you keep touching
documentation without even CC-ing the people who care...
Andrea
On Wed, Jun 19, 2019 at 01:18:58AM -0700, Christoph Hellwig wrote:
> > mutex_lock(>lock);
> > - list_del(>list);
> > + list_del_init(>list);
> > mutex_unlock(>lock);
>
> I don't see the point why this is a list_del_init - that just
> reinitializeѕ range->list, but doesn't change
On Wed, 19 Jun 2019 12:42:39 +0200
Peter Zijlstra wrote:
> No, the other way around, Sphinx can recognize local files and treat
> them special. That way we keep the text readable.
>
> Same with that :c:func:'foo' crap, that needs to die, and Sphinx needs
> to be taught about foo().
I did a
On Tue, Jun 18, 2019 at 10:31 AM Robert Chiras wrote:
> --- /dev/null
> +++ b/drivers/gpu/drm/panel/panel-raydium-rm67191.c
> @@ -0,0 +1,709 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * i.MX drm driver - Raydium MIPI-DSI panel driver
Please remove the "i.MX drm driver" as there is
On Wed, Jun 19, 2019 at 08:08:09AM +, Fabrizio Castro wrote:
> Hi Laurent,
>
> Thank you for your feedback!
>
> > From: linux-renesas-soc-ow...@vger.kernel.org
> > On Behalf Of Laurent Pinchart
> > Sent: 18 June 2019 17:44
> > Subject: Re: [PATCH 1/3] dt-bindings: display: renesas: Add
https://bugs.freedesktop.org/show_bug.cgi?id=110949
--- Comment #2 from Mike Lothian ---
It reverts cleanly and the warnings go away once its gone
--
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=110949
Mike Lothian changed:
What|Removed |Added
CC||m...@fireburn.co.uk
--- Comment #1 from
On 6/18/19 1:46 PM, Maarten Lankhorst wrote:
> Op 18-06-2019 om 13:17 schreef Bartlomiej Zolnierkiewicz:
>> Hi,
>>
>> On 6/18/19 11:20 AM, Maarten Lankhorst wrote:
>>> Op 14-06-2019 om 11:25 schreef Maarten Lankhorst:
Hi all,
As discussed with Daniel V, I'm just doing the paperwork
https://bugs.freedesktop.org/show_bug.cgi?id=110702
--- Comment #11 from Pierre-Eric Pelloux-Prayer
---
(In reply to Christian König from comment #10)
> (In reply to Pierre-Eric Pelloux-Prayer from comment #9)
> > The driver fails when trying to allocate a buffer for this video with a
> >
Hi Robert,
On Tue, Jun 18, 2019 at 10:31 AM Robert Chiras wrote:
> +static const struct display_timing rad_default_timing = {
> + .pixelclock = { 6600, 13200, 13200 },
> + .hactive = { 1080, 1080, 1080 },
> + .hfront_porch = { 20, 20, 20 },
> + .hsync_len = {
On Tue, Jun 18, 2019 at 04:30:46PM +0300, Robert Chiras wrote:
> This patch adds Raydium RM67191 TFT LCD panel driver (MIPI-DSI
> protocol).
>
> Signed-off-by: Robert Chiras
Please include in the changelog a list of what was updated - like this:
v2:
- added kconif symbol sorted (sam)
- another
https://bugs.freedesktop.org/show_bug.cgi?id=110949
Bug ID: 110949
Summary: Continuious warnings from agd5f 5.3-wip branch
Product: DRI
Version: XOrg git
Hardware: Other
OS: All
Status: NEW
Severity:
Hi Robert,
On Tue, Jun 18, 2019 at 10:33 AM Robert Chiras wrote:
> +Optional properties:
> +- reset-gpios: a GPIO spec for the RST_B GPIO pin
> +- pinctrl-0phandle to the pin settings for the reset pin
> +- width-mm:physical panel width [mm]
> +- height-mm:
On Wed, 2019-06-19 at 06:20 +, Shankar, Uma wrote:
> > -Original Message-
> > From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf
> > Of
> > Ezequiel Garcia
> > Sent: Friday, June 14, 2019 9:48 PM
> > To: Shankar, Uma
> > Cc: Emil Velikov ;
> >
https://bugs.freedesktop.org/show_bug.cgi?id=110702
--- Comment #10 from Christian König ---
(In reply to Pierre-Eric Pelloux-Prayer from comment #9)
> The driver fails when trying to allocate a buffer for this video with a
> ENOMEM error (the requested size is 3 GB).
Well that strongly sounds
Hi Robert.
Thanks for the contribution.
On Tue, Jun 18, 2019 at 04:30:45PM +0300, Robert Chiras wrote:
> Add dt-bindings documentation for Raydium RM67191 DSI panel.
>
> Signed-off-by: Robert Chiras
> ---
> .../bindings/display/panel/raydium,rm67191.txt | 43
> ++
> 1
https://bugs.freedesktop.org/show_bug.cgi?id=110702
--- Comment #9 from Pierre-Eric Pelloux-Prayer
---
Thanks, I could reproduce on a Raven setup using the files from comment 7 and
8.
The driver fails when trying to allocate a buffer for this video with a ENOMEM
error (the requested size is 3
Em Wed, 19 Jun 2019 12:42:39 +0200
Peter Zijlstra escreveu:
> On Wed, Jun 19, 2019 at 07:22:18AM -0300, Mauro Carvalho Chehab wrote:
> > Hi Daniel,
> >
> > Em Wed, 19 Jun 2019 11:05:57 +0200
> > Daniel Vetter escreveu:
> >
> > > On Tue, Jun 18, 2019 at 10:55 PM Mauro Carvalho Chehab
> > >
https://bugs.freedesktop.org/show_bug.cgi?id=109456
--- Comment #7 from Alex Williamson ---
Can you test this QEMU patch that's already in qemu.git for 4.1:
https://git.qemu.org/?p=qemu.git;a=commitdiff;h=3412d8ec9810b819f8b79e8e0c6b87217c876e32
Alternatively, setting the pci-hole64-size=0 can
Den 18.06.2019 11.20, skrev Daniel Vetter:
> Yes this is a bit a big patch, but since it's essentially a complete
> rewrite of all the prime docs I didn't see how to better split it up.
>
> Changes:
> - Consistently point to drm_gem_object_funcs as the preferred hooks,
> where applicable.
>
/drm-intel tags/drm-intel-next-2019-06-19
for you to fetch changes up to 1ee008f240ad5401f683ec3b79a2e3b044a82a89:
drm/i915: Update DRIVER_DATE to 20190619 (2019-06-19 15:32:25 +0300)
Features:
- HDR support (Uma, Ville)
- Add
On Mon, Jun 03, 2019 at 05:25:54PM +0200, Paul Cercueil wrote:
> The KD035G6-54NT is a 3.5" 320x240 24-bit TFT LCD panel.
>
> Signed-off-by: Paul Cercueil
Reviewed-by: Sam Ravnborg
Rob - ping for review.
Sam
> ---
>
> Notes:
> v2: - Add an address to the panel node
> - Add
Hi Paul.
On Mon, Jun 03, 2019 at 05:23:31PM +0200, Paul Cercueil wrote:
> Add a KMS driver for the Ingenic JZ47xx family of SoCs.
> This driver is meant to replace the aging jz4740-fb driver.
>
> This driver does not make use of the simple pipe helper, for the reason
> that it will soon be
On Wed, Jun 12, 2019 at 10:49:52AM +0200, Paul Cercueil wrote:
>
>
> Le mar. 11 juin 2019 à 23:55, Rob Herring a écrit :
> > On Mon, 3 Jun 2019 17:23:30 +0200, Paul Cercueil wrote:
> > > Add documentation for the devicetree bindings of the LCD controller
> > > present in
> > > the JZ47xx
Den 18.06.2019 11.20, skrev Daniel Vetter:
> Reorder all the functions in drm_prime.[hc] into three groups: core,
> export helpers, import helpers.
>
> Not other changes beyond moving the functions and their unchanged
> kerneldoc around in here.
>
> Cc: Sam Ravnborg
> Cc: Eric Anholt
> Cc:
On Wed, 2019-06-19 at 12:41 +0100, Robert Beckett wrote:
> Notify drm core before sending pending events during crtc disable.
> This fixes the first event after disable having an old stale timestamp
> by having drm_crtc_vblank_off update the timestamp to now.
>
> This was seen while debugging
On Wed, Jun 19, 2019 at 01:45:51PM +0200, Peter Zijlstra wrote:
> On Wed, Jun 19, 2019 at 01:43:56PM +0200, Peter Zijlstra wrote:
> > On Tue, Jun 18, 2019 at 05:53:17PM -0300, Mauro Carvalho Chehab wrote:
> >
> > > .../{ => driver-api}/atomic_bitops.rst| 2 -
> >
> > That's a .txt file,
On Tue, Jun 18, 2019 at 8:12 PM Daniel Vetter wrote:
>
> On Tue, Jun 18, 2019 at 07:48:06PM +0800, Cheng-yi Chiang wrote:
> > On Tue, Jun 11, 2019 at 8:35 PM Daniel Vetter wrote:
> > >
> > > On Tue, Jun 11, 2019 at 08:10:38PM +0800, Cheng-yi Chiang wrote:
> > > > On Tue, Jun 4, 2019 at 3:24 PM
On Wed, Jun 19, 2019 at 01:43:56PM +0200, Peter Zijlstra wrote:
> On Tue, Jun 18, 2019 at 05:53:17PM -0300, Mauro Carvalho Chehab wrote:
>
> > .../{ => driver-api}/atomic_bitops.rst| 2 -
>
> That's a .txt file, big fat NAK for making it an rst.
Also, how many bloody times do I have to
https://bugs.freedesktop.org/show_bug.cgi?id=109456
--- Comment #6 from libgra...@gmail.com ---
Updated to QEMU 4.0.0 and re-tested - same result.
Let me know if you would like anything further info.
Thanks!
--
You are receiving this mail because:
You are the assignee for the
On Tue, Jun 18, 2019 at 05:53:17PM -0300, Mauro Carvalho Chehab wrote:
> .../{ => driver-api}/atomic_bitops.rst| 2 -
That's a .txt file, big fat NAK for making it an rst.
> .../{ => driver-api}/futex-requeue-pi.rst | 2 -
> .../{ => driver-api}/gcc-plugins.rst | 2 -
Notify drm core before sending pending events during crtc disable.
This fixes the first event after disable having an old stale timestamp
by having drm_crtc_vblank_off update the timestamp to now.
This was seen while debugging weston log message:
Warning: computed repaint delay is insane: -8212
On Wed, Jun 19, 2019 at 1:21 PM Gerd Hoffmann wrote:
>
> Hi,
>
> > > > Second one is drm_driver->fops->mmap. That one we need to keep, but this
> > > > isn't mmap on a buffer, but mmap on the entire drm_device. The one which
> > > > should be replaced by drm_gem_object_funcs.vm_ops is
> > > >
> > +struct drm_gem_object_array*
> > +drm_gem_array_from_handles(struct drm_file *drm_file, u32 *handles, u32
> > nents)
> > +{
> > + struct drm_gem_object_array *objs;
> > + u32 i;
> > +
> > + objs = drm_gem_array_alloc(nents);
> > + if (!objs)
> > + return NULL;
> > +
> > +
Hi,
> > > Second one is drm_driver->fops->mmap. That one we need to keep, but this
> > > isn't mmap on a buffer, but mmap on the entire drm_device. The one which
> > > should be replaced by drm_gem_object_funcs.vm_ops is
> > > drm_driver->gem_vm_ops.
> >
> > Hmm, seems ttm hasn't something I
On Wed, Jun 19, 2019 at 11:04:16AM +0200, Gerd Hoffmann wrote:
> Use gem reservation helpers and direct reservation_object_* calls
> instead of ttm.
>
> v3: Also attach the array of gem objects to the virtio command buffer,
> so we can drop the object references in the completion callback.
On Thu, Jun 13, 2019 at 12:43:23PM -0700, Matthias Kaehlcke wrote:
> Add an entry for the stable backlight sysfs ABI to the MAINTAINERS
> file.
>
> Signed-off-by: Matthias Kaehlcke
Well spotted. Thanks!
Acked-by: Daniel Thompson
Daniel.
> ---
> MAINTAINERS | 1 +
> 1 file changed, 1
On Wed, Jun 19, 2019 at 11:04:14AM +0200, Gerd Hoffmann wrote:
> All callers pass no_wait = false.
>
> Signed-off-by: Gerd Hoffmann
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/virtio/virtgpu_drv.h | 5 ++---
> drivers/gpu/drm/virtio/virtgpu_gem.c | 4 ++--
>
On Wed, Jun 19, 2019 at 11:04:09AM +0200, Gerd Hoffmann wrote:
> Add struct and helper functions to manage an array of gem objects.
> See added kernel docs for details.
>
> Signed-off-by: Gerd Hoffmann
Hm, feels like jumping ahead here, I think there's too much still
in-flight:
- Christian is
On 2019/06/18, Daniel Vetter wrote:
> Yes this is a bit a big patch, but since it's essentially a complete
> rewrite of all the prime docs I didn't see how to better split it up.
>
> Changes:
> - Consistently point to drm_gem_object_funcs as the preferred hooks,
> where applicable.
>
> -
On 2019/06/18, Daniel Vetter wrote:
> Reorder all the functions in drm_prime.[hc] into three groups: core,
> export helpers, import helpers.
>
> Not other changes beyond moving the functions and their unchanged
> kerneldoc around in here.
>
> Cc: Sam Ravnborg
> Cc: Eric Anholt
> Cc: Emil
On Wed, Jun 19, 2019 at 07:22:18AM -0300, Mauro Carvalho Chehab wrote:
> Hi Daniel,
>
> Em Wed, 19 Jun 2019 11:05:57 +0200
> Daniel Vetter escreveu:
>
> > On Tue, Jun 18, 2019 at 10:55 PM Mauro Carvalho Chehab
> > wrote:
> > > diff --git a/Documentation/gpu/drm-mm.rst
1 - 100 of 169 matches
Mail list logo
