Dave, Daniel
- The coherent memory changes including mm changes.
- Some vmwgfx debug fixes.
- Removal of vmwgfx legacy security checks.
The following changes since commit 561564bea3248293398dc32ec36da40fb71faed0:
Merge tag 'omapdrm-5.3' of
On Wed, Jun 19, 2019 at 1:48 AM Sergey Senozhatsky
wrote:
>
> On (06/19/19 01:20), Ilia Mirkin wrote:
> > On Wed, Jun 19, 2019 at 1:08 AM Sergey Senozhatsky
> > wrote:
> > >
> > > On (06/14/19 11:50), Sergey Senozhatsky wrote:
> > > > dmesg
> > > >
> > > > nouveau :01:00.0: DRM: GPU lockup
>-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 ; intel-...@lists.freedesktop.org;
>Syrjala,
>Ville ; Lankhorst, Maarten
>;
>dri-devel
The page_offset was only applied to the end of the page range. This caused
the display updates to cause a scrolling effect on the display because the
amount of data written to the display did not match the range display
expected.
Fixes: 301bc0675b67 ("video: ssd1307fb: Make use of horizontal
On (06/19/19 02:07), Ilia Mirkin wrote:
> On Wed, Jun 19, 2019 at 1:48 AM Sergey Senozhatsky
> wrote:
> >
> > On (06/19/19 01:20), Ilia Mirkin wrote:
> > > On Wed, Jun 19, 2019 at 1:08 AM Sergey Senozhatsky
> > > wrote:
> > > >
> > > > On (06/14/19 11:50), Sergey Senozhatsky wrote:
> > > > >
On Sat, Jun 15, 2019 at 07:14:35AM -0700, Christoph Hellwig wrote:
> > mutex_lock(>lock);
> > - list_for_each_entry(range, >ranges, list)
> > - range->valid = false;
> > - wake_up_all(>wq);
> > + /*
> > +* Since hmm_range_register() holds the mmget() lock hmm_release() is
>
On Thu, Jun 13, 2019 at 10:13:54PM -0700, Kees Cook wrote:
> On Thu, Jun 13, 2019 at 04:26:32PM +0100, Catalin Marinas wrote:
> > On Thu, Jun 13, 2019 at 12:02:35PM +0100, Dave P Martin wrote:
> > > On Wed, Jun 12, 2019 at 01:43:20PM +0200, Andrey Konovalov wrote:
> > > > +static int zero;
> > > >
On Sat, Jun 15, 2019 at 07:17:26AM -0700, Christoph Hellwig wrote:
> > - /* Sanity check this really should not happen. */
> > - if (hmm == NULL || range->end <= range->start)
> > - return;
> > -
> > mutex_lock(>lock);
> > list_del_rcu(>list);
> > mutex_unlock(>lock);
> >
On (06/14/19 11:50), Sergey Senozhatsky wrote:
> dmesg
>
> nouveau :01:00.0: DRM: GPU lockup - switching to software fbcon
> nouveau :01:00.0: fifo: SCHED_ERROR 0a [CTXSW_TIMEOUT]
> nouveau :01:00.0: fifo: runlist 0: scheduled for recovery
> nouveau :01:00.0: fifo: channel 5:
sparse reported incorrect type due to different address spaces.
The screen_base is __iomem, but the memory is not from a device so we can
use screen_buffer instead and avoid some type casts.
Signed-off-by: Marko Kohtala
---
drivers/video/fbdev/ssd1307fb.c | 10 +-
1 file changed, 5
On Sat, Jun 15, 2019 at 07:12:11AM -0700, Christoph Hellwig wrote:
> > + spin_lock(>page_table_lock);
> > + if (mm->hmm) {
> > + if (kref_get_unless_zero(>hmm->kref)) {
> > + spin_unlock(>page_table_lock);
> > + return mm->hmm;
> > + }
>
Some displays have dimensions that are not multiple of eight, for example
height of 36, but the driver divided the dimensions by 8. Defining display
to the next multiple of 8 is not good as then the display registers get
configured to dimensions that do not match. This contradicts intructions
by
On (06/19/19 01:20), Ilia Mirkin wrote:
> On Wed, Jun 19, 2019 at 1:08 AM Sergey Senozhatsky
> wrote:
> >
> > On (06/14/19 11:50), Sergey Senozhatsky wrote:
> > > dmesg
> > >
> > > nouveau :01:00.0: DRM: GPU lockup - switching to software fbcon
> > > nouveau :01:00.0: fifo: SCHED_ERROR
On Sat, Jun 15, 2019 at 06:59:06AM -0700, Christoph Hellwig wrote:
> On Thu, Jun 13, 2019 at 09:44:40PM -0300, Jason Gunthorpe wrote:
> > From: Jason Gunthorpe
> >
> > Ralph observes that hmm_range_register() can only be called by a driver
> > while a mirror is registered. Make this clear in the
On Mon, Jun 17, 2019 at 9:36 AM Krzysztof Kozlowski wrote:
>
> On Mon, Jun 17, 2019 at 09:15:23AM -0700, Joseph Kogut wrote:
> > Hi Krzysztof,
> >
> > Thanks for the review.
> >
> > On Sun, Jun 16, 2019 at 1:59 AM Krzysztof Kozlowski wrote:
> > >
> > > On Fri, Jun 14, 2019 at 04:57:19PM -0700,
coccicheck reported unneeded semicolons. Remove them.
Signed-off-by: Marko Kohtala
---
drivers/video/fbdev/ssd1307fb.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/video/fbdev/ssd1307fb.c b/drivers/video/fbdev/ssd1307fb.c
index 6c2980331ffd..9ab00e0dadc7
The kernel driver for ssd1307fb did not allow for all proper
initialization for a Densitron 128x36 display. The trend in the driver
has been to add devicetree properties for the controller initialization
and these patches continue on that trend.
There also were some sparse and Coccinelle errors.
On Sat, Jun 15, 2019 at 07:16:12AM -0700, Christoph Hellwig wrote:
> On Thu, Jun 13, 2019 at 09:44:46PM -0300, Jason Gunthorpe wrote:
> > From: Jason Gunthorpe
> >
> > No other register/unregister kernel API attempts to provide this kind of
> > protection as it is inherently racy, so just drop
Document new bindings for adapting ssd1307fb driver to new displays.
Signed-off-by: Marko Kohtala
---
.../devicetree/bindings/display/ssd1307fb.txt | 10 ++
1 file changed, 10 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/ssd1307fb.txt
On Wed, 19 Jun 2019, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the drm tree got a conflict in:
>
> drivers/gpu/drm/i915/Makefile.header-test
>
> between commit:
>
> e846f0dc57f4 ("kbuild: add support for ensuring headers are self-contained")
>
> from the kbuild tree
Warnings popup when "make ARCH=i386"
In file included from include/drm/drm_mm.h:49,
from include/drm/drm_vma_manager.h:26,
from include/drm/drm_gem.h:40,
from drivers/gpu/drm/arm/display/komeda/komeda_framebuffer.c:9:
On Wed, Jun 19, 2019 at 9:00 AM Noralf Trønnes wrote:
>
>
>
> Den 18.06.2019 19.23, skrev Noralf Trønnes:
> >
> > Den 18.06.2019 18.35, skrev Laurent Pinchart:
> >> Hi Noralf,
> >>
> >> On Tue, Jun 18, 2019 at 03:56:19PM +0200, Noralf Trønnes wrote:
> >>> Den 18.06.2019 15.13, skrev Laurent
On Tue, Jun 18, 2019 at 11:07:50PM -0300, Rodrigo Siqueira wrote:
> For historical reason, the function drm_wait_vblank_ioctl always return
> -EINVAL if something gets wrong. This scenario limits the flexibility
> for the userspace make detailed verification of the problem and take
> some action.
On Tue, Jun 18, 2019 at 11:17:34PM -0300, Rodrigo Siqueira wrote:
> On 06/07, Daniel Vetter wrote:
> > The crc core code can cope with some late crc, the race is kinda
> > unavoidable. So no need to flush pending workers, they'll complete in
> > time.
> >
> > Signed-off-by: Daniel Vetter
> > Cc:
Den 18.06.2019 19.23, skrev Noralf Trønnes:
>
> Den 18.06.2019 18.35, skrev Laurent Pinchart:
>> Hi Noralf,
>>
>> On Tue, Jun 18, 2019 at 03:56:19PM +0200, Noralf Trønnes wrote:
>>> Den 18.06.2019 15.13, skrev Laurent Pinchart:
The recommended way to specify GEM object functions is to
Various displays have differences that only mean initializing the display
driver IC with different fixed register values. Defining these in
devicetree offers easier way to adapt the driver to new displays than
requiring a patch to the kernel.
This adds devicetree properties needed to make the
On (06/19/19 15:27), Sergey Senozhatsky wrote:
> [..]
>
> > If all else fails, just remove nouveau_dri.so and/or boot with
> > nouveau.noaccel=1 -- should be perfect.
>
> Can give it a try.
That has some impact on system responsiveness:
CPU% COMM
339.7 firefox
Which is
On Tue, Jun 18, 2019 at 06:27:22AM -0700, Christoph Hellwig wrote:
> On Tue, Jun 18, 2019 at 10:13:24AM -0300, Jason Gunthorpe wrote:
> > > I don't even think we even need to bother with the POISON, normal list
> > > debugging will already catch a double unregistration anyway.
> >
> > mirror->hmm
On Wed, Jun 19, 2019 at 09:48:56AM +0200, Daniel Vetter wrote:
> On Tue, Jun 18, 2019 at 11:07:50PM -0300, Rodrigo Siqueira wrote:
> > For historical reason, the function drm_wait_vblank_ioctl always return
> > -EINVAL if something gets wrong. This scenario limits the flexibility
> > for 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")
>>
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/
>
>
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 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
> >
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:
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:
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.
>
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, 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
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
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 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
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,
> >
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 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: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 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
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, 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 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 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 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
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
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 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.
> > >
> > >
Hi Gerd,
On 2019/06/19, Gerd Hoffmann wrote:
> +/**
> + * drm_gem_array_from_handles -- lookup an array of gem handles.
> + *
> + * @drm_file: drm file-private structure to use for the handle look up
> + * @handles: the array of handles to lookup.
> + * @nents: the numer of handles.
> + *
> + *
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
> > >
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
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 b/Documentation/gpu/drm-mm.rst
> > index fa30dfcfc3c8..b0f948d8733b 100644
> > ---
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.
>
> -
> > +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;
> > +
> > +
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
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
Hi Krzysztof,
On 2019-06-19 12:08, Krzysztof Kozlowski wrote:
> On Wed, 19 Jun 2019 at 12:01, Marek Szyprowski
> wrote:
>> Hi Krzysztof,
>>
>> On 2019-06-18 21:05, Krzysztof Kozlowski wrote:
>>> Add vendor compatibles for specific implementation of Mali Utgard
>>> (Exynos3250, Exynos4-family)
On Tue, Jun 18, 2019 at 07:47:04PM +0200, Noralf Trønnes wrote:
> > diff --git a/Documentation/fb/modedb.rst b/Documentation/fb/modedb.rst
> > index 3c2397293977..3e8a6f79dcd7 100644
> > --- a/Documentation/fb/modedb.rst
> > +++ b/Documentation/fb/modedb.rst
> > @@ -53,6 +53,17 @@ Specifying the
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 #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
> >
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 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
> 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
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
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
On Tue, Jun 18, 2019 at 11:20:37AM +0200, 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:
Hi,
> - Polish for all the functions and more cross references.
That is nice, helps figurung how all this works together without wading
through the source code (or at least less of it).
For that kind of changes it is probably helpful for review to generate
the diff with more context (say
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 -
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 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 Fri, Jun 14, 2019 at 10:35:23PM +0200, Daniel Vetter wrote:
> Read the docs, komeda is not an old enough driver for this :-)
>
> Signed-off-by: Daniel Vetter
> Cc: "James (Qian) Wang"
> Cc: Liviu Dudau
Acked-by: Liviu Dudau
I'm assuming the whole series goes through drm-misc and I don't
On Fri, Jun 14, 2019 at 10:35:27PM +0200, Daniel Vetter wrote:
> They're the default.
>
> Aside: Would be really nice to switch the others over to
> drm_gem_object_funcs.
>
> Signed-off-by: Daniel Vetter
> Cc: "James (Qian) Wang"
> Cc: Liviu Dudau
> Cc: Brian Starkey
Acked-by: Liviu Dudau
On Tue, Jun 18, 2019 at 10:32:08PM -0400, Brian Masney wrote:
> +++ b/include/soc/qcom/ocmem.h
> @@ -0,0 +1,62 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * The On Chip Memory (OCMEM) allocator allows various clients to allocate
> + * memory from OCMEM based on performance, latency
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 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
> > > >
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, 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
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
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
On Wed, 19 Jun 2019 at 12:01, Marek Szyprowski wrote:
>
> Hi Krzysztof,
>
> On 2019-06-18 21:05, Krzysztof Kozlowski wrote:
> > Add vendor compatibles for specific implementation of Mali Utgard
> > (Exynos3250, Exynos4-family) and Midgard (Exynos5433, Exynos7).
> >
> > Signed-off-by: Krzysztof
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 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.
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
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
Hi Gerd,
On 2019/06/19, Gerd Hoffmann wrote:
> -static void virtio_gpu_init_ttm_placement(struct virtio_gpu_object *vgbo)
> +static const struct drm_gem_object_funcs v3d_gem_funcs = {
s/v3d/virtio/g
Doubt I'll have the time for a proper review - just this and the 1/12 nits :-\
HTH
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
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 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,
/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
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
1 - 100 of 169 matches
Mail list logo
