On 11/12/2019 00:57, Laurent Pinchart wrote:
When the DSS initialises its output DPI and SDI ports, failures don't
clean up previous successfully initialised ports. This can lead to
resource leak or memory corruption. Fix it.
Reported-by: Hans Verkuil
Signed-off-by: Laurent Pinchart
---
On Mon, Dec 16, 2019 at 04:43:48PM +0200, Stefan Mavrodiev wrote:
> It's possible hdmi->connector and hdmi->encoder divices to be NULL.
The wording is broken and s/divices/devices/. I'd write:
It's possible that the parent devices of the connector and/or
encoder are NULL. This
Hi!
On Mon 16-12-19 14:25:12, John Hubbard wrote:
> Hi,
>
> This implements an API naming change (put_user_page*() -->
> unpin_user_page*()), and also implements tracking of FOLL_PIN pages. It
> extends that tracking to a few select subsystems. More subsystems will
> be added in follow up work.
On Mon 16-12-19 14:18:59, John Hubbard wrote:
> On 12/16/19 4:53 AM, Jan Kara wrote:
> > With this fixed, the patch looks good to me so you can then add:
> >
> > Reviewed-by: Jan Kara
> >
> > Honza
> >
>
> btw, thanks for the
On 11/12/2019 00:57, Laurent Pinchart wrote:
From: Wen Yang
The call to of_find_matching_node returns a node pointer with refcount
incremented thus it must be explicitly decremented after the last
usage.
Detected by coccinelle with the following warnings:
Hi,
On Tue, Dec 17, 2019 at 8:52 AM Laurent Pinchart
wrote:
>
> Hi Nicolas,
>
> On Tue, Dec 17, 2019 at 08:40:51AM +0800, Nicolas Boichat wrote:
> > (Brilliant, I managed to accidentally send the email below, and send
> > it as HTML, sorry about that... ASCII art in gmail is hard ,-(
>
> No
Hi Randy.
On Mon, Dec 16, 2019 at 08:25:11AM -0800, Randy Dunlap wrote:
> On 12/15/19 9:22 PM, Stephen Rothwell wrote:
> > Hi all,
> >
> > Changes since 20191213:
> >
>
> on x86_64:
>
> ld: drivers/gpu/drm/drm_panel.o: in function `drm_panel_of_backlight':
> (.text+0x2ee): undefined reference
From: Daniel Stone
getfb2 allows us to pass multiple planes and modifiers, just like addfb2
over addfb.
Changes since v2:
- add privilege checks from getfb1 since handles should only be
returned to master/root
Changes since v1:
- unused modifiers set to 0 instead of DRM_FORMAT_MOD_INVALID
Hi,
On Mon, 2019-12-16 at 11:30 +0100, Enric Balletbo Serra wrote:
> Hi all,
>
> Missatge de Hsin-Yi Wang del dia dl., 16 de des.
> 2019 a les 3:42:
> >
> > On Fri, Dec 13, 2019 at 9:52 AM Jitao Shi wrote:
> > >
> > > There are some extra data transfer in dsi.
> > > ex. LPX, hs_prepare,
Hi, Daniel:
On Fri, 2019-12-13 at 18:26 +0100, Daniel Vetter wrote:
> Checking both is one too much, so wrap a WARN_ON around it to stope
> the copypasta.
Even though I don't know what is copypasta,
Acked-by: CK Hu
>
> Signed-off-by: Daniel Vetter
> Cc: CK Hu
> Cc: Philipp Zabel
> Cc:
Hi Rob,
On Thu, Oct 24, 2019 at 03:02:57PM +0800, CK Hu wrote:
> On Wed, 2019-10-23 at 17:56 -0500, Rob Herring wrote:
> > On Wed, Oct 23, 2019 at 4:06 PM CK Hu wrote:
> > > On Wed, 2019-10-23 at 12:42 -0500, Rob Herring wrote:
> > > > On Tue, Oct 22, 2019 at 12:07 PM Matthias Brugger wrote:
> >
Turing introduced a new simplified page kind
scheme, reducing the number of possible page
kinds from 256 to 16. It also is the first
NVIDIA GPU in which the highest possible page
kind value is not reserved as an "invalid" page
kind.
To address this, the invalid page kind is made
an explicit
The pointer used to walk the table of move ops
and pick the right one for the current GPU was
declared static, meaning its state was carried
over between invocations of the function, and also
made the function non-rentrant and thread-unsafe.
Since the table is ordered such that newer GPU
methods
Hi Nicolas,
On Tue, Dec 17, 2019 at 08:40:51AM +0800, Nicolas Boichat wrote:
> (Brilliant, I managed to accidentally send the email below, and send
> it as HTML, sorry about that... ASCII art in gmail is hard ,-(
No worries. I have been told it's indeed painful.
> Take 2:)
>
> Hi Laurent,
>
>
Advertise and accept both the existing
DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK()-based format
modifiers and the more descriptive
DRM_FORMAT_MOD_NVIDIA_BLOCK_LINEAR_2D()-based
format modifiers, preserving backwards
compatibility with existing userspace drivers, but
providing forwards compatibility with
On 12/12/19 6:51 PM, James Jones wrote:
On 12/11/19 1:13 PM, Ilia Mirkin wrote:
On Wed, Dec 11, 2019 at 4:04 PM James Jones wrote:
Allow setting the block layout of a nouveau FB
object using DRM format modifiers. When
specified, the format modifier block layout and
kind overrides the GEM
Make sure framebuffer dimensions and tiling
parameters will not result in accesses beyond the
end of the GEM buffer they are bound to.
Signed-off-by: James Jones
---
drivers/gpu/drm/nouveau/nouveau_display.c | 93 +++
1 file changed, 93 insertions(+)
diff --git
This series modifies the NV5x+ nouveau display backends to advertise
appropriate format modifiers on their display planes in atomic mode
setting blobs.
Corresponding modifications to Mesa/userspace are available here:
https://gitlab.freedesktop.org/cubanismo/mesa/tree/nouveau_work
But those
Allow setting the block layout of a nouveau FB
object using DRM format modifiers. When
specified, the format modifier block layout and
kind overrides the GEM buffer's implicit layout
and kind. The specified format modifier is
validated against he list of modifiers supported
by the target display
Advertise support for the full list of format
modifiers supported by each class of NVIDIA
desktop GPU display hardware. Stash the array
of modifiers in the nouveau_display struct for
use when validating userspace framebuffer
creation requests, which will be supportd in
a subsequent change.
(Brilliant, I managed to accidentally send the email below, and send
it as HTML, sorry about that... ASCII art in gmail is hard ,-(
Take 2:)
Hi Laurent,
> On Tue, Dec 17, 2019 at 12:39 AM Laurent Pinchart
> wrote:
> >
> > Hello Nicolas and Hsin-Yi,
> >
> > On Mon, Dec 16, 2019 at 06:19:24PM
Hi,
On Sun, Dec 15, 2019 at 5:19 PM Jeffrey Hugo wrote:
>
> On Fri, Dec 13, 2019 at 5:49 PM Doug Anderson wrote:
> >
> > Hi,
> >
> > On Fri, Dec 13, 2019 at 4:07 PM Daniel Vetter wrote:
> > >
> > > On Fri, Dec 13, 2019 at 03:45:30PM -0800, Douglas Anderson wrote:
> > > > The bridge chip
Hi Laurent,
On Tue, Dec 17, 2019 at 12:39 AM Laurent Pinchart <
laurent.pinch...@ideasonboard.com> wrote:
>
> Hello Nicolas and Hsin-Yi,
>
> On Mon, Dec 16, 2019 at 06:19:24PM +0800, Nicolas Boichat wrote:
> > On Mon, Dec 16, 2019 at 4:46 PM Hsin-Yi Wang wrote:
> > > On Sat, Dec 14, 2019 at 6:38
https://bugzilla.kernel.org/show_bug.cgi?id=200695
Claude Heiland-Allen (cla...@mathr.co.uk) changed:
What|Removed |Added
Kernel Version|4.17.19, 4.18.5 -- 4.18.20, |4.17.19,
https://bugzilla.kernel.org/show_bug.cgi?id=204609
Błażej Szczygieł (spa...@wp.pl) changed:
What|Removed |Added
CC||spa...@wp.pl
---
https://bugzilla.kernel.org/show_bug.cgi?id=205879
Bjoern Franke (b...@nord-west.org) changed:
What|Removed |Added
Status|NEW |RESOLVED
The R-Car LVDS encoder driver implements the bridge .mode_set()
operation for the sole purpose of storing the mode in the LVDS private
data, to be used later when enabling the encoder.
Switch to the bridge .atomic_enable() and .atomic_disable() operations
in order to access the global atomic
Introduce pin_user_pages*() variations of get_user_pages*() calls,
and also pin_longterm_pages*() variations.
For now, these are placeholder calls, until the various call sites
are converted to use the correct get_user_pages*() or
pin_user_pages*() API.
These variants will eventually all set
Convert drm/via to use the new pin_user_pages_fast() call, which sets
FOLL_PIN. Setting FOLL_PIN is now required for code that requires
tracking of pinned pages, and therefore for any code that calls
put_user_page().
In partial anticipation of this work, the drm/via driver was already
calling
Convert fs/io_uring to use the new pin_user_pages() call, which sets
FOLL_PIN. Setting FOLL_PIN is now required for code that requires
tracking of pinned pages, and therefore for any code that calls
put_user_page().
In partial anticipation of this work, the io_uring code was already
calling
1. Change vfio from get_user_pages_remote(), to
pin_user_pages_remote().
2. Because all FOLL_PIN-acquired pages must be released via
put_user_page(), also convert the put_page() call over to
put_user_pages_dirty_lock().
Note that this effectively changes the code's behavior in
In order to provide a clearer, more symmetric API for pinning
and unpinning DMA pages. This way, pin_user_pages*() calls
match up with unpin_user_pages*() calls, and the API is a lot
closer to being self-explanatory.
Reviewed-by: Jan Kara
Signed-off-by: John Hubbard
---
Update VFIO to take advantage of the recently loosened restriction on
FOLL_LONGTERM with get_user_pages_remote(). Also, now it is possible to
fix a bug: the VFIO caller is logically a FOLL_LONGTERM user, but it
wasn't setting FOLL_LONGTERM.
Also, remove an unnessary pair of calls that were
1. Convert from get_user_pages() to pin_user_pages().
2. As required by pin_user_pages(), release these pages via
put_user_page().
Reviewed-by: Jan Kara
Signed-off-by: John Hubbard
---
arch/powerpc/mm/book3s64/iommu_api.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff
Convert infiniband to use the new pin_user_pages*() calls.
Also, revert earlier changes to Infiniband ODP that had it using
put_user_page(). ODP is "Case 3" in
Documentation/core-api/pin_user_pages.rst, which is to say, normal
get_user_pages() and put_page() is the API to use there.
The new
It's good to have basic unit test coverage of the new FOLL_PIN
behavior. Fortunately, the gup_benchmark unit test is extremely
fast (a few milliseconds), so adding it the the run_vmtests suite
is going to cause no noticeable change in running time.
So, add two new invocations to run_vmtests:
1)
Add tracking of pages that were pinned via FOLL_PIN.
As mentioned in the FOLL_PIN documentation, callers who effectively set
FOLL_PIN are required to ultimately free such pages via unpin_user_page().
The effect is similar to FOLL_GET, and may be thought of as "FOLL_GET
for DIO and/or RDMA use".
After DMA is complete, and the device and CPU caches are synchronized,
it's still required to mark the CPU pages as dirty, if the data was
coming from the device. However, this driver was just issuing a
bare put_page() call, without any set_page_dirty*() call.
Fix the problem, by calling
Commit 817be129e6f2 ("mm: validate get_user_pages_fast flags") allowed
only FOLL_WRITE and FOLL_LONGTERM to be passed to get_user_pages_fast().
This, combined with the fact that get_user_pages_fast() falls back to
"slow gup", which *does* accept FOLL_FORCE, leads to an odd situation:
if you need
1. Change v4l2 from get_user_pages() to pin_user_pages().
2. Because all FOLL_PIN-acquired pages must be released via
put_user_page(), also convert the put_page() call over to
put_user_pages_dirty_lock().
Acked-by: Hans Verkuil
Cc: Ira Weiny
Signed-off-by: John Hubbard
---
From: Dan Williams
After the removal of the device-public infrastructure there are only 2
->page_free() call backs in the kernel. One of those is a device-private
callback in the nouveau driver, the other is a generic wakeup needed in
the DAX case. In the hopes that all ->page_free() callbacks
Fix the gup benchmark flags to use the symbolic FOLL_WRITE,
instead of a hard-coded "1" value.
Also, clean up the filtering of gup flags a little, by just doing
it once before issuing any of the get_user_pages*() calls. This
makes it harder to overlook, instead of having little "gup_flags & 1"
Up until now, gup_benchmark supported testing of the
following kernel functions:
* get_user_pages(): via the '-U' command line option
* get_user_pages_longterm(): via the '-L' command line option
* get_user_pages_fast(): as the default (no options required)
Add test coverage for the new
Convert process_vm_access to use the new pin_user_pages_remote()
call, which sets FOLL_PIN. Setting FOLL_PIN is now required for
code that requires tracking of pinned pages.
Also, release the pages via put_user_page*().
Also, rename "pages" to "pinned_pages", as this makes for
easier reading of
Convert net/xdp to use the new pin_longterm_pages() call, which sets
FOLL_PIN. Setting FOLL_PIN is now required for code that requires
tracking of pinned pages.
In partial anticipation of this work, the net/xdp code was already
calling put_user_page() instead of put_page(). Therefore, in order to
And get rid of the mmap_sem calls, as part of that. Note
that get_user_pages_fast() will, if necessary, fall back to
__gup_longterm_unlocked(), which takes the mmap_sem as needed.
Reviewed-by: Leon Romanovsky
Reviewed-by: Christoph Hellwig
Reviewed-by: Jan Kara
Reviewed-by: Jason Gunthorpe
An upcoming patch uses try_get_compound_head() more widely,
so move it to the top of gup.c.
Also fix a tiny spelling error and a checkpatch.pl warning.
Reviewed-by: Christoph Hellwig
Reviewed-by: Jan Kara
Reviewed-by: Ira Weiny
Signed-off-by: John Hubbard
---
mm/gup.c | 29
An upcoming patch changes and complicates the refcounting and
especially the "put page" aspects of it. In order to keep
everything clean, refactor the devmap page release routines:
* Rename put_devmap_managed_page() to page_is_devmap_managed(),
and limit the functionality to "read only": return
1. Avoid naming conflicts: rename local static function from
"pin_user_pages()" to "goldfish_pin_pages()".
An upcoming patch will introduce a global pin_user_pages()
function.
Reviewed-by: Jan Kara
Reviewed-by: Jérôme Glisse
Reviewed-by: Ira Weiny
Signed-off-by: John Hubbard
---
As it says in the updated comment in gup.c: current FOLL_LONGTERM
behavior is incompatible with FAULT_FLAG_ALLOW_RETRY because of the
FS DAX check requirement on vmas.
However, the corresponding restriction in get_user_pages_remote() was
slightly stricter than is actually required: it forbade all
Hi,
This implements an API naming change (put_user_page*() -->
unpin_user_page*()), and also implements tracking of FOLL_PIN pages. It
extends that tracking to a few select subsystems. More subsystems will
be added in follow up work.
Christoph Hellwig, a point of interest:
a) I've moved the
There are four locations in gup.c that have a fair amount of code
duplication. This means that changing one requires making the same
changes in four places, not to mention reading the same code four
times, and wondering if there are subtle differences.
Factor out the common code into static
1. Call the new global pin_user_pages_fast(), from pin_goldfish_pages().
2. As required by pin_user_pages(), release these pages via
put_user_page(). In this case, do so via put_user_pages_dirty_lock().
That has the side effect of calling set_page_dirty_lock(), instead
of set_page_dirty(). This
On 12/16/19 4:53 AM, Jan Kara wrote:
...
I'd move this still a bit higher - just after VM_BUG_ON_PAGE() and before
if (flags & FOLL_TOUCH) test. Because touch_pmd() can update page tables
and we don't won't that if we're going to fail the fault.
Done. I'll post a full v11 series shortly.
Hi Fabrizio,
On Mon, Dec 16, 2019 at 05:39:55PM +, Fabrizio Castro wrote:
> > From: linux-renesas-soc-ow...@vger.kernel.org
> > On Behalf Of Laurent Pinchart
> > Sent: 13 December 2019 18:28
> > Subject: [PATCH v2] drm: rcar-du: lvds: Get mode from state
> >
> > The R-Car LVDS encoder
https://bugzilla.kernel.org/show_bug.cgi?id=200695
--- Comment #34 from Bjoern Franke (b...@nord-west.org) ---
I'm getting this issue with only one monitor via HDMI connected. It was gone
some kernel versions before and came back with 5.4.x it seems.
--
You are receiving this mail because:
You
https://bugzilla.kernel.org/show_bug.cgi?id=205879
--- Comment #3 from Bjoern Franke (b...@nord-west.org) ---
Created attachment 286321
--> https://bugzilla.kernel.org/attachment.cgi?id=286321=edit
dmesg with amdgpu.dc_log=1
Enabling dc_log=1 shows similarities to #200695, but only with one
Hi Fabrizio,
Thank you for the patch.
On Mon, Dec 16, 2019 at 08:12:32PM +, Fabrizio Castro wrote:
> DT properties dual-lvds-even-pixels and dual-lvds-odd-pixels
> can be used to work out if the driver needs to swap even
> and odd pixels around.
>
> This patch makes use of the return value
Hi Fabrizio,
Thank you for the patch.
On Mon, Dec 16, 2019 at 08:12:30PM +, Fabrizio Castro wrote:
> Dual-LVDS panels are mistakenly identified as bridges, this
> commit replaces the current logic with a call to
> drm_of_find_panel_or_bridge to sort that out.
>
> Signed-off-by: Fabrizio
Hi Fabrizio,
Ping ?
On Fri, Dec 13, 2019 at 07:10:38PM +0200, Laurent Pinchart wrote:
> On Wed, Nov 13, 2019 at 03:51:25PM +, Fabrizio Castro wrote:
> > Add support for transparent LVDS decoders by adding a new
> > compatible string ("lvds-decoder") to the driver.
> > This patch also adds
https://bugzilla.kernel.org/show_bug.cgi?id=205879
--- Comment #2 from Bjoern Franke (b...@nord-west.org) ---
Created attachment 286319
--> https://bugzilla.kernel.org/attachment.cgi?id=286319=edit
xorg log
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=205879
--- Comment #1 from Bjoern Franke (b...@nord-west.org) ---
Xorg logs:
21.247] (WW) AMDGPU(0): No outputs definitely connected, trying again...
[21.247] (II) AMDGPU(0): Output DisplayPort-0 disconnected
[21.247] (II) AMDGPU(0): Output
Hi Stephan,
I fixed up the patch according to your comments, this remains:
On Mon, Dec 16, 2019 at 6:55 PM Stephan Gerhold wrote:
> In general I was wondering if we could benefit from using something like
> the regmap_update_bits() helper to avoid having to write this manually
> all the time.
On Mon, Dec 16, 2019 at 5:34 AM Andrew F. Davis wrote:
>
> The heaps are already in a directory of heaps, adding _heap to a heap
> name is redundant. This patch is only a name change, no logic is changed.
>
> Signed-off-by: Andrew F. Davis
Again, do wish we had caught/made this tweak earlier,
https://bugzilla.kernel.org/show_bug.cgi?id=205879
Bug ID: 205879
Summary: amdgpu: blank screen on RX 460
Product: Drivers
Version: 2.5
Kernel Version: 5.4.3
Hardware: x86-64
OS: Linux
Tree: Mainline
On Mon, Dec 16, 2019 at 5:34 AM Andrew F. Davis wrote:
>
> This is more consistent with the DMA and DRM frameworks convention. This
> patch is only a name change, no logic is changed.
>
> Signed-off-by: Andrew F. Davis
Do wish we had caught/made this tweak earlier, but I do agree its a
more
On Mon, Dec 16, 2019 at 8:11 AM Colin King wrote:
>
> From: Colin Ian King
>
> The -ENOTTY error return path does not free the allocated
> kdata as it returns directly. Fix this by returning via the
> error handling label err.
>
> Addresses-Coverity: ("Resource leak")
> Fixes: c02a81fba74f
The video DSI mode had not really been tested. These fixes makes
it more likely to work on real hardware:
- Put the active width (x width) in the right bits and the VSA
(vertical sync active) in the right bits (those were swapped).
- Calculate the packet sizes in bytes as in the vendor driver,
Hi All,
Here is v2 of my patch-series to make the
i915 code control the SoC panel- and backlight-enable GPIOs on Bay Trail
devices when the VBT indicates that the SoC should be used for backlight
control. This fixes the panel not lighting up on various devices when
booted with a HDMI monitor
Currently only the drivers/pinctrl/devicetree.c code allows registering
pinctrl-mappings which may later be unregistered, all other mappings
are assumed to be permanent.
Non-dt platforms may also want to register pinctrl mappings from code which
is build as a module, which requires being able to
Move the Crystal Cove PMIC panel GPIO lookup-table from
drivers/mfd/intel_soc_pmic_core.c to the i915 driver.
The moved looked-up table is adding a GPIO lookup to the i915 PCI
device and the GPIO subsys allows only one lookup table per device,
The intel_soc_pmic_core.c code only adds
When the LCD has not been turned on by the firmware/GOP, because e.g. the
device was booted with an external monitor connected over HDMI, we should
not turn on the panel-enable GPIO when we request it.
Turning on the panel-enable GPIO when we request it, means we turn it on
too early in the
On Bay Trail devices the MIPI power on/off sequences for DSI LCD panels
do not control the LCD panel- and backlight-enable GPIOs. So far, when
the VBT indicates we should use the SoC for backlight control, we have
been relying on these GPIOs being configured as output and driven high by
the Video
On some older devices (BYT, CHT) which may use v2 VBT MIPI-sequences,
we need to manually control the panel enable GPIO as v2 sequences do
not do this.
So far we have been carrying the code to do this on BYT/CHT devices
with a Crystal Cove PMIC in vlv_dsi.c, but as this really is a shortcoming
of
Hi Liviu,
My way of thinking is explained below. Do you still find it problematic?
W dniu 16.12.2019 o 18:08, Liviu Dudau pisze:
Hi Andrzej,
+struct drm_framebuffer *
+drm_gem_fb_create_with_funcs(struct drm_device *dev, struct drm_file *file,
+const struct
At least Bay Trail (BYT) and Cherry Trail (CHT) devices can use 1 of 2
different PWM controllers for controlling the LCD's backlight brightness.
Either the one integrated into the PMIC or the one integrated into the
SoC (the 1st LPSS PWM controller).
So far in the LPSS code on BYT we have skipped
At least Bay Trail (BYT) and Cherry Trail (CHT) devices can use 1 of 2
different PWM controllers for controlling the LCD's backlight brightness.
Either the one integrated into the PMIC or the one integrated into the
SoC (the 1st LPSS PWM controller).
So far in the LPSS code on BYT we have
Hi All,
Somehow the CI system did not pick up this series the first time, there
are no test results recorded for it:
https://patchwork.freedesktop.org/series/69685
So this is a resend for CI to do its thing. As soon as CI is happy with
this I will push this to drm-intel-next-queued.
Regards,
At least Bay Trail (BYT) and Cherry Trail (CHT) devices can use 1 of 2
different PWM controllers for controlling the LCD's backlight brightness.
Either the one integrated into the PMIC or the one integrated into the
SoC (the 1st LPSS PWM controller).
So far in the LPSS code on BYT we have skipped
https://bugzilla.kernel.org/show_bug.cgi?id=201497
--- Comment #12 from Sebastien Bernard (sbern...@nerim.net) ---
I wonder if it's not a bad EDID from the monitor.
Anyway, that's a regression from 4.18.
--
You are receiving this mail because:
You are watching the assignee of the bug.
Hi,
On 16-12-2019 14:39, Ville Syrjälä wrote:
On Sun, Dec 15, 2019 at 10:33:07PM +0100, Hans de Goede wrote:
Some devices with a builtin panel have the panel mounted upside down,
this is indicated by the rotate_180 bit in the BDB_GENERAL_FEATURES VBT
block.
We store this info in
Hi Liviu,
W dniu 16.12.2019 o 18:19, Liviu Dudau pisze:
Hi Andrzej,
On Fri, Dec 13, 2019 at 04:58:36PM +0100, Andrzej Pietrasiewicz wrote:
Extend the size-checking special function to handle afbc.
Signed-off-by: Andrzej Pietrasiewicz
---
drivers/gpu/drm/drm_fourcc.c | 10
On Mon, Dec 16, 2019 at 10:29:08PM +0530, Jagan Teki wrote:
> On Mon, Dec 16, 2019 at 4:50 PM Maxime Ripard wrote:
> >
> > On Mon, Dec 16, 2019 at 04:37:20PM +0530, Jagan Teki wrote:
> > > On Wed, Dec 4, 2019 at 7:06 PM Maxime Ripard wrote:
> > > >
> > > > On Tue, Dec 03, 2019 at 07:18:10PM
On Mon, Dec 16, 2019 at 07:27:25PM +0200, Ville Syrjälä wrote:
> On Mon, Dec 16, 2019 at 06:10:17PM +0100, Stephan Gerhold wrote:
> > At the moment, video mode parameters like video=540x960,reflect_x,
> > (without rotation set) are not taken into account when applying the
> > mode in
Hi,
the patch "drm/drm_panel: fix EXPORT of drm_panel_of_backlight" in
linux-next breaks the powernv build:
desktop: ~/git/linux-ppc memtrace $ ./compile.sh
CALLscripts/atomic/check-atomics.sh
CALLscripts/checksyscalls.sh
CHK include/generated/compile.h
GEN .version
CHK
Hi Linus,
Thanks for keeping this patch updated!
I think it is about time that we get this patch applied
- it gets increasingly larger and more complex and therefore difficult
to review.
Most of it looks fine to me, I just have a few notes below:
On Tue, Dec 10, 2019 at 11:48:57PM +0100, Linus
On Mon, Dec 16, 2019 at 8:38 AM Jordan Crouse wrote:
>
> Attempt to enable split pagetables if the arm-smmu driver supports it.
> This will move the default address space from the default region to
> the address range assigned to TTBR1. The behavior should be transparent
> to the driver for now
On Fri, 13 Dec 2019 at 11:23, Linus Walleij wrote:
>
> The PWM backlight still supports passing a enable GPIO line as
> platform data using the legacy API.
>
> It turns out that ever board using this mechanism except one
> is pass .enable_gpio = -1. So we drop all these cargo-culted -1's
> from
Applied the series. Thanks!
Alex
On Sat, Dec 14, 2019 at 9:44 AM zhengbin wrote:
>
> zhengbin (3):
> drm/amdgpu: Remove unneeded semicolon in amdgpu_pmu.c
> drm/amdgpu: Remove unneeded semicolon in gfx_v10_0.c
> drm/amdgpu: Remove unneeded semicolon in amdgpu_ras.c
>
>
On Mon, Dec 16, 2019 at 06:10:17PM +0100, Stephan Gerhold wrote:
> At the moment, video mode parameters like video=540x960,reflect_x,
> (without rotation set) are not taken into account when applying the
> mode in drm_client_modeset.c.
A rotation value without exactly one rotation angle is
On Mon, Dec 16, 2019 at 9:32 AM Harry Wentland wrote:
>
> On 2019-12-14 4:12 a.m., zhengbin wrote:
> > Fixes coccicheck warning:
> >
> > drivers/gpu/drm/amd/display/dc/clk_mgr/dcn21/rn_clk_mgr.c:412:90-91:
> > Unneeded semicolon
> >
> > Reported-by: Hulk Robot
> > Signed-off-by: zhengbin
>
>
Hi Andrzej,
On Fri, Dec 13, 2019 at 04:58:36PM +0100, Andrzej Pietrasiewicz wrote:
> Extend the size-checking special function to handle afbc.
>
> Signed-off-by: Andrzej Pietrasiewicz
> ---
> drivers/gpu/drm/drm_fourcc.c | 10 +++-
> drivers/gpu/drm/drm_framebuffer.c
On Fri, Dec 13, 2019 at 04:58:35PM +0100, Andrzej Pietrasiewicz wrote:
> The new version accepts a struct describing deviations from standard way of
> doing the size checks. The caller must provide the respective values.
>
> Signed-off-by: Andrzej Pietrasiewicz
> ---
>
At the moment, video mode parameters like video=540x960,reflect_x,
(without rotation set) are not taken into account when applying the
mode in drm_client_modeset.c.
One of the reasons for this is that the calculation that
combines the panel_orientation with cmdline->rotation_reflection
does not
Hi Andrzej,
On Fri, Dec 13, 2019 at 04:58:34PM +0100, Andrzej Pietrasiewicz wrote:
> Prepare tools for drivers which need to allocate a struct drm_framebuffer
> (or a container of struct drm_framebuffer) explicitly, before calling
> helpers. In such a case we need new helpers which omit
On Mon, 2019-12-16 at 14:58 +0100, Enric Balletbo i Serra wrote:
> From: Jitao Shi
>
> This patch adds drm_bridge driver for parade DSI to eDP bridge chip.
>
> Signed-off-by: Jitao Shi
> Reviewed-by: Daniel Kurtz
> Reviewed-by: Enric Balletbo i Serra
> [uli: followed API changes, removed FW
On Mon, Dec 16, 2019 at 4:50 PM Maxime Ripard wrote:
>
> On Mon, Dec 16, 2019 at 04:37:20PM +0530, Jagan Teki wrote:
> > On Wed, Dec 4, 2019 at 7:06 PM Maxime Ripard wrote:
> > >
> > > On Tue, Dec 03, 2019 at 07:18:10PM +0530, Jagan Teki wrote:
> > > > The MIPI DSI controller in Allwinner A64 is
On Thu, 2019-12-12 at 09:17 -0800, Matt Roper wrote:
> On Tue, Dec 10, 2019 at 12:06:11PM -0800, José Roberto de Souza
> wrote:
> > It is missing the new EHL/JSL PCI ids added in commit
> > 651cc835d5f6 ("drm/i915: Add new EHL/JSL PCI ids")
> >
> > Cc: James Ausmus
> > Cc: Matt Roper
> >
Hello
I have being contributing to i915 for the past 2 years and part of my
work is update the PCI ids of Intel devices in libdrm.
Being able to push my reviewed patches would be really helpful, please
consider this request.
Thanks
___
dri-devel
Ping on unreviewed V2s...
Andrey
On 12/13/19 11:54 AM, Andrey Grodzovsky wrote:
In preparation for doing XGMI reset synchronization using task barrier.
Signed-off-by: Andrey Grodzovsky
Reviewed-by: Le Ma
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 2 -
1 - 100 of 222 matches
Mail list logo
