Hi
Am 15.11.19 um 10:21 schrieb Daniel Vetter:
> Again we could delete a lot more if we'd switch over to the generic
> fbdev stuff.
Actually, I do have patches for this since forever. I didn't post them
yet as I couldn't test them. Maybe I should post them and see what
people say.
Best regards
T
Hi
Am 15.11.19 um 10:21 schrieb Daniel Vetter:
> Again we could delete a lot more if we'd switch over to the generic
> fbdev stuff.
>
> Signed-off-by: Daniel Vetter
There's one comment below. Except for that,
Acked-by: Thomas Zimmermann
> ---
> .../gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
Hi Fabrizio,
On Thu, Nov 21, 2019 at 5:00 PM Fabrizio Castro
wrote:
> > From: devicetree-ow...@vger.kernel.org
> > On Behalf Of Laurent Pinchart
> > Sent: 19 November 2019 21:52
> > Subject: Re: [PATCH v4 12/13] [HACK] drm/bridge: lvds-codec: Enforce device
> > specific compatible strings
> >
The hibmc driver's struct hibmc_framebuffer stores a DRM framebuffer
with an associated GEM object. This functionality is also provided by
generic code. Switch hibmc over.
Signed-off-by: Thomas Zimmermann
---
.../gpu/drm/hisilicon/hibmc/hibmc_drm_de.c| 4 +-
.../gpu/drm/hisilicon/hibmc/hibm
The patch set replaces code in hibmc with generic implementation.
Patches 1 to 3 replace fbdev emuation, framebuffer and creation of
dumb buffers with respective code from DRM helpers. Patch 4 adds an
additional interface to debugfs that displays the allocated and free
areas in video memory.
The
The hibmc driver aligns scanlines to 16 bytes. Adding the pitch alignment
as an argument to drm_gem_vram_fill_create_dumb() allows to use the generic
implementation with hibmc. A value of 0 disables scanline pitches.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_gem_vram_helper.c
This change makes information about VRAM consumption available on
debugfs. See
/sys/kernel/debug/dri/0/vram-mm
for an overview of how VRAM is being used.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/d
There's nothing special about hibmc's fbdev emulation that is not
provided by the generic implementation. Switch over and remove the
driver's code.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/hisilicon/hibmc/Makefile | 2 +-
.../gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 5 +-
Set the two interconnect paths for the GPU to maximum speed for now to
work towards getting the GPU working upstream. We can revisit a later
time to optimize this for battery life.
Signed-off-by: Brian Masney
---
drivers/gpu/drm/msm/adreno/a4xx_gpu.c | 8
1 file changed, 8 insertions(+)
19.11.2019 19:58, Dmitry Osipenko пишет:
> 19.11.2019 09:30, Thierry Reding пишет:
>> On Mon, Nov 18, 2019 at 11:02:30PM +0300, Dmitry Osipenko wrote:
>>> All NVIDIA Tegra SoCs have identical topology in regards to memory
>>> interconnection between memory clients and memory controllers.
>>> The me
On Mon, Oct 21, 2019 at 4:14 PM Navid Emamdoost
wrote:
>
> In the implementation of nouveau_bo_alloc() if it fails to determine the
> target page size via pi, then the allocated memory for nvbo should be
> released.
>
> Fixes: 019cbd4a4feb ("drm/nouveau: Initialize GEM object before TTM object")
>
Some A3xx and all A4xx Adreno GPUs do not have GMEM inside the GPU core
and must use the On Chip MEMory (OCMEM) in order to be functional.
There's a separate interconnect path that needs to be setup to OCMEM.
Add support for this second path to the GPU core.
In the downstream MSM 3.4 sources, the
On Thu, Nov 21, 2019 at 12:07:46AM -0800, Christoph Hellwig wrote:
> On Wed, Nov 20, 2019 at 11:13:37PM -0800, John Hubbard wrote:
> > 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
Hi,
* Rob Herring [700101 00:00]:
> On Wed, Oct 09, 2019 at 10:51:26AM +0200, Jean-Jacques Hiblot wrote:
> > Add DT binding for led-backlight.
...
> > new file mode 100644
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/leds/backlight/led-backlight.yaml
...
> > + default-brightnes
Some A3xx and all A4xx Adreno GPUs do not have GMEM inside the GPU core
and must use the On Chip MEMory (OCMEM) in order to be functional.
There's a separate interconnect path that needs to be setup to OCMEM.
This patch series adds support for that path, and sets the votes for the
two interconnect
On Tue, Sep 24, 2019 at 11:38 PM Navid Emamdoost
wrote:
>
> In vmw_cmdbuf_res_add if drm_ht_insert_item fails the allocated memory
> for cres should be released.
>
> Signed-off-by: Navid Emamdoost
Would you please review this patch?
Thanks,
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf_res.c |
zhengbin (2):
drm/amd/powerplay: Use ARRAY_SIZE for smu7_profiling
drm/amdgpu: Use ARRAY_SIZE for sos_old_versions
drivers/gpu/drm/amd/amdgpu/psp_v3_1.c| 2 +-
drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
--
2.7.4
On Fri, Oct 4, 2019 at 2:09 PM Navid Emamdoost
wrote:
>
> In imx_pd_bind, the duplicated memory for imxpd->edid via kmemdup should
> be released in drm_of_find_panel_or_bridge or imx_pd_register fail.
>
> Fixes: ebc944613567 ("drm: convert drivers to use
> drm_of_find_panel_or_bridge")
> Fixes: 1
On Hyper-V, Generation 1 VMs can directly use VM's physical memory for
their framebuffers. This can improve the efficiency of framebuffer and
overall performence for VM. The physical memory assigned to framebuffer
must be contiguous. We use CMA allocator to get contiguouse physicial
memory when the
Some A3xx and all A4xx Adreno GPUs do not have GMEM inside the GPU core
and must use the On Chip MEMory (OCMEM) in order to be functional.
There's a separate interconnect path that needs to be setup to OCMEM.
Let's document this second interconnect path that's available. Since
there's now two avail
Set the two interconnect paths for the GPU to maximum speed for now to
work towards getting the GPU working upstream. We can revisit a later
time to optimize this for battery life.
Signed-off-by: Brian Masney
---
drivers/gpu/drm/msm/adreno/a3xx_gpu.c | 8
1 file changed, 8 insertions(+)
19.11.2019 19:56, Dmitry Osipenko пишет:
> 19.11.2019 09:25, Thierry Reding пишет:
>> On Mon, Nov 18, 2019 at 11:02:26PM +0300, Dmitry Osipenko wrote:
>>> Define interconnect IDs for memory controller (MC), external memory
>>> controller (EMC), external memory (EMEM) and memory clients of display
>
Fixes coccicheck warning:
drivers/gpu/drm/amd/amdgpu/psp_v3_1.c:182:40-41: WARNING: Use ARRAY_SIZE
Reported-by: Hulk Robot
Signed-off-by: zhengbin
---
drivers/gpu/drm/amd/amdgpu/psp_v3_1.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/psp_v3_1.c
Fixes coccicheck warning:
drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c:4946:28-29: WARNING: Use
ARRAY_SIZE
Reported-by: Hulk Robot
Signed-off-by: zhengbin
---
drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/d
Hi Laurent,
Thank you for your feedback!
> From: devicetree-ow...@vger.kernel.org On
> Behalf Of Laurent Pinchart
> Sent: 19 November 2019 21:52
> Subject: Re: [PATCH v4 12/13] [HACK] drm/bridge: lvds-codec: Enforce device
> specific compatible strings
>
> Hi Fabrizio,
>
> On Tue, Nov 19, 20
Hi,
* Jean-Jacques Hiblot [700101 00:00]:
> From: Tomi Valkeinen
>
> This patch adds a led-backlight driver (led_bl), which is similar to
> pwm_bl except the driver uses a LED class driver to adjust the
> brightness in the HW. Multiple LEDs can be used for a single backlight.
...
> + ret =
On Fri, Nov 22, 2019 at 1:13 AM Karol Herbst wrote:
>
> so while trying to test with d3cold disabled, I noticed that I run
> into the exact same error.
Does this mean that you disabled d3cold on the GPU via sysfs (the
"d3cold_allowed" attribute was 0) and the original problem still
occurred in th
On Fri, Nov 22, 2019 at 9:16 AM Thomas Zimmermann wrote:
>
> Hi
>
> Am 15.11.19 um 10:21 schrieb Daniel Vetter:
> > Again we could delete a lot more if we'd switch over to the generic
> > fbdev stuff.
> >
> > Signed-off-by: Daniel Vetter
>
> There's one comment below. Except for that,
>
> Acked-b
On Fri, Nov 22, 2019 at 7:37 AM Gerd Hoffmann wrote:
>
> Use the shared address space of the drm device (see drm_open() in
> drm_file.c) for dma-bufs too. That removes a difference betweem drm
> device mmap vmas and dma-buf mmap vmas and fixes corner cases like
> dropping ptes (using madvise(DONT
https://bugs.freedesktop.org/show_bug.cgi?id=97055
--- Comment #27 from jennyaly ---
I'm not going to try and have a go at suspending until I can at any rate
dependably boot. Suspending consistently brings its very own arrangement of
issues, and has never worked 100% dependably for me. Also, Visi
tree: git://anongit.freedesktop.org/drm-intel topic/core-for-CI
head: 33c006e813c3896741927f86bf30c8b647c9b366
commit: 33c006e813c3896741927f86bf30c8b647c9b366 [20/20] Revert "drm/i915:
Don't select BROKEN"
config: powerpc-taishan_defconfig
compiler: powerpc-linux-gcc (GCC) 7.4.0
reproduce:
On Fri, Nov 22, 2019 at 1:22 AM Karol Herbst wrote:
>
> Fixes state transitions of Nvidia Pascal GPUs from D3cold into higher device
> states.
>
> v2: convert to pci_dev quirk
> put a proper technical explanation of the issue as a in-code comment
> v3: disable it only for certain combinations
The field 'fbdev' in struct psb_framebuffer serves no purpose. Remove
it.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/gma500/framebuffer.c | 1 -
drivers/gpu/drm/gma500/framebuffer.h | 1 -
2 files changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/gma500/framebuffer.c
b/drivers/gpu
These patches remove struct psb_framebuffer and struct psb_fbdev
from gma500. Both are replaced by their equivalents from the DRM
helpers.
The patchset has been tested by running the fbdev console, X11 and
Weston on an Atom Z520 with Poulsbo graphics chip.
Thomas Zimmermann (6):
drm/gma500: Rem
The field 'addr_space' in struct psb_framebuffer serves no
purpose. Remove it.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/gma500/framebuffer.c | 2 --
drivers/gpu/drm/gma500/framebuffer.h | 1 -
2 files changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/gma500/framebuffer.c
b/drive
After removing all unnecessary fields, struct psb_framebuffer is just a
wrapper around struct drm_framebuffer. So we can replace the former with
the latter.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/gma500/accel_2d.c| 6 ++--
drivers/gpu/drm/gma500/framebuffer.c | 48
Gma500's struct psb_fbdev is an, otherwise empty, wrapper around
struct drm_fb_helper. Remove it.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/gma500/accel_2d.c| 10 ++--
drivers/gpu/drm/gma500/framebuffer.c | 70 ++--
drivers/gpu/drm/gma500/framebuffer.h | 6
The gma500 driver stores the console framebuffer in struct psb_fbdev.
Moving it into struct drm_fb_helper will allow for removal of struct
psb_fbdev.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/gma500/accel_2d.c| 5 +++--
drivers/gpu/drm/gma500/framebuffer.c | 16 ++--
Several framebuffer functions take a pointer to an object of type
struct gtt_range when they actually need the GEM base object. Passing
the GEM object removes some type casting and clutter.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/gma500/framebuffer.c | 14 ++
1 file chan
On Thu, Nov 21, 2019 at 11:39:23PM +0100, Rafael J. Wysocki wrote:
> On Thu, Nov 21, 2019 at 8:49 PM Mika Westerberg
> wrote:
> >
> > On Thu, Nov 21, 2019 at 04:43:24PM +0100, Rafael J. Wysocki wrote:
> > > On Thu, Nov 21, 2019 at 1:52 PM Mika Westerberg
> > > wrote:
> > > >
> > > > On Thu, Nov 2
On Thu 21-11-19 18:54:02, John Hubbard wrote:
> On 11/21/19 1:54 AM, Jan Kara wrote:
> > On Thu 21-11-19 00:29:59, John Hubbard wrote:
> > > >
> > > > Otherwise this looks fine and might be a worthwhile cleanup to feed
> > > > Andrew for 5.5 independent of the gut of the changes.
> > > >
> > > >
On Fri, Nov 22, 2019 at 11:36 AM Mika Westerberg
wrote:
>
> On Thu, Nov 21, 2019 at 11:39:23PM +0100, Rafael J. Wysocki wrote:
> > On Thu, Nov 21, 2019 at 8:49 PM Mika Westerberg
> > wrote:
> > >
> > > On Thu, Nov 21, 2019 at 04:43:24PM +0100, Rafael J. Wysocki wrote:
> > > > On Thu, Nov 21, 2019
On Fri, Nov 22, 2019 at 10:07 AM Rafael J. Wysocki wrote:
>
> On Fri, Nov 22, 2019 at 1:13 AM Karol Herbst wrote:
> >
> > so while trying to test with d3cold disabled, I noticed that I run
> > into the exact same error.
>
> Does this mean that you disabled d3cold on the GPU via sysfs (the
> "d3co
On Fri, Nov 22, 2019 at 12:30 PM Rafael J. Wysocki wrote:
>
> On Fri, Nov 22, 2019 at 11:36 AM Mika Westerberg
> wrote:
> >
> > On Thu, Nov 21, 2019 at 11:39:23PM +0100, Rafael J. Wysocki wrote:
> > > On Thu, Nov 21, 2019 at 8:49 PM Mika Westerberg
> > > wrote:
> > > >
> > > > On Thu, Nov 21, 20
On Fri, Nov 22, 2019 at 08:24:57AM +0100, Linus Walleij wrote:
> The MCDE DSI include file redefines some commands that
> already exist in the common header.
>
> Cc: Stephan Gerhold
> Signed-off-by: Linus Walleij
Reviewed-by: Stephan Gerhold
> ---
> drivers/gpu/drm/mcde/mcde_dsi.c | 2
On Fri, Nov 22, 2019 at 12:30:20PM +0100, Rafael J. Wysocki wrote:
> On Fri, Nov 22, 2019 at 11:36 AM Mika Westerberg
> wrote:
> >
> > On Thu, Nov 21, 2019 at 11:39:23PM +0100, Rafael J. Wysocki wrote:
> > > On Thu, Nov 21, 2019 at 8:49 PM Mika Westerberg
> > > wrote:
> > > >
> > > > On Thu, Nov
On Fri, Nov 22, 2019 at 12:34 PM Karol Herbst wrote:
>
> On Fri, Nov 22, 2019 at 12:30 PM Rafael J. Wysocki wrote:
> >
[cut]
> >
>
> the issue is not AML related at all as I am able to reproduce this
> issue without having to invoke any of that at all, I just need to poke
> into the PCI registe
https://bugs.freedesktop.org/show_bug.cgi?id=110605
Andre Klapper changed:
What|Removed |Added
URL|https://theshopolics.com/ |
Alias|NAGENDRA
Dear Maintainers,
Can you please express your opinion on these patches:
[tegra] https://patchwork.freedesktop.org/patch/327099/?series=65831&rev=1
[vc4] https://patchwork.freedesktop.org/patch/327102/?series=65831&rev=1
[zte] https://patchwork.freedesktop.org/patch/327106/?series=65831&rev=1
[zt
On Fri, Nov 22, 2019 at 08:25:08AM +0100, Linus Walleij wrote:
> The i index i always 0..3 in these statements so there
> is no need to tag "& 3" to clamp it to 3 here. Make
> the operator precedence explicit even if it's correct
> as it is, the paranthesis creates less cognitive stress
> for human
Quoting Joonas Lahtinen (2019-11-20 22:40:35)
> Hi Dave & Daniel,
>
> NOTE: CI shard results are delayed, bu I'm sending this
> already because I'll travel tomorrow. I'll let you know
> if the results look OK or not. Or you can look up
> CI_DINF_162 results check at:
>
> https://intel-gfx-ci.01.o
On Fri, Nov 22, 2019 at 12:52 PM Mika Westerberg
wrote:
>
[cut]
[I'm really running out of time for today, unfortunately.]
> > > > The current design is mostly based on the PCI PM Spec 1.2, so it would
> > > > be consequent to follow system-wide suspend in PM-runtime and avoid
> > > > putting P
tree: git://anongit.freedesktop.org/drm-intel topic/core-for-CI
head: 33c006e813c3896741927f86bf30c8b647c9b366
commit: 33c006e813c3896741927f86bf30c8b647c9b366 [20/20] Revert "drm/i915:
Don't select BROKEN"
config: alpha-defconfig
compiler: alpha-linux-gcc (GCC) 7.4.0
reproduce:
wget
From: Thierry Reding
Export the module device table to ensure the VIC compatible strings are
listed in the module's aliases table. This in turn causes the driver to
be automatically loaded on boot if VIC is the only enabled subdevice of
the logical host1x DRM device.
Signed-off-by: Thierry Redin
Hi Dave & Daniel,
A quick fixup amendment to the previous PR. gem_exec_reloc/basic-range
got broken in CI, so we've issued a patch revert the offending commit
for now.
Once the results for CI_DINF_163 appear here, and the timeouts seen
in last three CI_DINF_ are green, feel free to pull this:
ht
On Fri, Nov 22, 2019 at 12:37 AM Gerd Hoffmann wrote:
>
> The fake offset is going to stay, so change the calling convention for
> drm_gem_object_funcs.mmap to include the fake offset. Update all users
> accordingly.
>
> Note that this reverts 83b8a6f242ea ("drm/gem: Fix mmap fake offset
> handli
On Fri, Nov 22, 2019 at 03:42:39PM +0800, CK Hu wrote:
> Hi, Daniel:
>
> On Fri, 2019-11-15 at 10:21 +0100, Daniel Vetter wrote:
> > Aside: There's a few other fb_create implementations which
> > simply check for valid buffer format (or an approximation thereof),
> > and then call drm_gem_fb_creat
On Wed, Nov 20, 2019 at 07:11:38PM +0200, Ville Syrjälä wrote:
> On Wed, Nov 20, 2019 at 05:43:40PM +0100, Daniel Vetter wrote:
> > On Wed, Nov 20, 2019 at 06:25:12PM +0200, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > Now that we've constrained the clipped source rectangle such
> >
The pull request you sent on Fri, 22 Nov 2019 10:43:28 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2019-11-22
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/5d867ab037e58da3356b95bd1a7cb8efe3501958
Thank you!
--
Deet-doot-dot, I am a bot.
https://k
From: Ville Syrjälä
My earlier fixes for drm_rect + div-by-zero fix + some
selftests that Daniel requested.
Cc: Maarten Lankhorst
Cc: Benjamin Gaignard
Cc: Daniel Vetter
Ville Syrjälä (4):
drm/rect: Avoid division by zero
drm/rect: Keep the scaled clip bounded
drm/rect: Keep the clippe
From: Ville Syrjälä
Check for zero width/height destination rectangle in
drm_rect_clip_scaled() to avoid a division by zero.
Cc: sta...@vger.kernel.org
Fixes: f96bdf564f3e ("drm/rect: Handle rounding errors in drm_rect_clip_scaled,
v3.")
Cc: Maarten Lankhorst
Cc: Benjamin Gaignard
Cc: Daniel
From: Ville Syrjälä
Now that we've constrained the clipped source rectangle such
that it can't have negative dimensions doing the same for the
dst rectangle seems appropriate. Should at least result in
the clipped src and dst rectangles being a bit more consistent
with each other.
Cc: Benjamin G
From: Ville Syrjälä
Limit the scaled clip to only clip at most dst_w/h pixels.
This avoids the problem with clip_scaled() not being able
to return negative values. Since new_src_w/h is now properly
bounded we can remove the clamp()s.
Cc: Benjamin Gaignard
Cc: Maarten Lankhorst
Cc: Daniel Vette
From: Ville Syrjälä
Add selftests for drm_rect. A few basic ones for clipped and unclipped
cases, and a few special ones for specific bugs we had in the code.
I'm too lazy to think of more corner cases to check at this time.
Maybe later.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/selfte
On Fri, Nov 22, 2019 at 4:17 AM Daniel Vetter wrote:
>
> On Fri, Nov 22, 2019 at 7:37 AM Gerd Hoffmann wrote:
> >
> > Use the shared address space of the drm device (see drm_open() in
> > drm_file.c) for dma-bufs too. That removes a difference betweem drm
> > device mmap vmas and dma-buf mmap vm
Applied the series. Thanks!
Alex
On Fri, Nov 22, 2019 at 4:01 AM zhengbin wrote:
>
> zhengbin (2):
> drm/amd/powerplay: Use ARRAY_SIZE for smu7_profiling
> drm/amdgpu: Use ARRAY_SIZE for sos_old_versions
>
> drivers/gpu/drm/amd/amdgpu/psp_v3_1.c| 2 +-
> drivers/gpu/drm/amd/pow
On Tue, Nov 19, 2019 at 11:14:43AM +0100, Daniel Vetter wrote:
> On Fri, Nov 15, 2019 at 09:42:00PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Yank out the code for the plane->fb/old_fb/crtc handling from
> > the page flip path into page_flip_internal(), and provide a
> > simpler
From: Mikita Lipski
We shouldn't compare int with unsigned long to find the max value
and since we are not expecting negative value returned from
compute_offset we should make this function return unsigned long
so we can compare the values when computing rc parameters.
v2: Modified function para
According to both the old acpi_igd_opregion_spec_0.pdf and the newer
skl_opregion_rev0p5.pdf opregion specification documents, if a driver
handles hotplug events itself, it should set the opregion CHPD field to
1 to indicate this and the firmware should respond to this by no longer
sending ACPI 0x0
No longer works on the driver.
Signed-off-by: Alex Deucher
---
MAINTAINERS | 1 -
1 file changed, 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index b63c291ad029..d518588b9879 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -856,7 +856,6 @@ S: Maintained
F: drivers/i2c/busses/i2c-am
On Fri, Nov 22, 2019 at 08:04:39PM +0100, Hans de Goede wrote:
> According to both the old acpi_igd_opregion_spec_0.pdf and the newer
> skl_opregion_rev0p5.pdf opregion specification documents, if a driver
> handles hotplug events itself, it should set the opregion CHPD field to
> 1 to indicate thi
From: Yunhao Tian
[ Upstream commit 0b8e7bbde5e7e2c419567e1ee29587dae3b78ee3 ]
The datasheet of V3s (and various other chips) wrote
that TCON0_DCLK_DIV can be >= 1 if only dclk is used,
and must >= 6 if dclk1 or dclk2 is used. As currently
neither dclk1 nor dclk2 is used (no writes to these
bits
Hi,
On Fri, Nov 22, 2019 at 11:48 PM Maxime Ripard wrote:
>
> Hi,
>
> On Thu, Nov 21, 2019 at 05:24:47PM +0530, Jagan Teki wrote:
> > On Sun, Nov 3, 2019 at 11:02 PM Maxime Ripard wrote:
> > >
> > > On Fri, Nov 01, 2019 at 07:42:55PM +0530, Jagan Teki wrote:
> > > > Hi Maxime,
> > > >
> > > > On
https://bugs.freedesktop.org/show_bug.cgi?id=109294
swathi.dhanavant...@intel.com changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--- Comment #10 f
https://bugs.freedesktop.org/show_bug.cgi?id=109294
--- Comment #11 from CI Bug Log ---
The CI Bug Log issue associated to this bug has been archived.
New failures matching the above filters will not be associated to this bug
anymore.
--
You are receiving this mail because:
You are the assigne
On Fri, Nov 22, 2019 at 11:54:45AM -0800, Niranjana Vishwanathapura wrote:
Use HMM page table mirroring support to build device page table.
Implement the bind ioctl and bind the process address range in the
specified context's ppgtt.
Handle invalidation notifications by unbinding the address rang
On Fri, Nov 22, 2019 at 08:14:51PM +, Jason Gunthorpe wrote:
On Fri, Nov 22, 2019 at 12:01:17PM -0800, Niranjan Vishwanathapura wrote:
On Fri, Nov 22, 2019 at 11:54:45AM -0800, Niranjana Vishwanathapura wrote:
> Use HMM page table mirroring support to build device page table.
> Implement the
Hi Dave, Daniel,
Fixes for 5.5.
The following changes since commit 17eee668b3cad423a47c090fe2275733c55db910:
Merge tag 'drm-misc-next-fixes-2019-11-20' of
git://anongit.freedesktop.org/drm/drm-misc into drm-next (2019-11-21 10:19:45
+1000)
are available in the Git repository at:
git://pe
Shared Virtual Memory (SVM) runtime allocator support allows
binding a shared virtual address to a buffer object (BO) in the
device page table through an ioctl call.
Cc: Joonas Lahtinen
Cc: Jon Bloomfield
Cc: Daniel Vetter
Cc: Sudeep Dutt
Signed-off-by: Niranjana Vishwanathapura
---
drivers/
Add Shared Virtual Memory (SVM) support information.
Cc: Joonas Lahtinen
Cc: Jon Bloomfield
Cc: Daniel Vetter
Cc: Sudeep Dutt
Signed-off-by: Niranjana Vishwanathapura
---
Documentation/gpu/i915.rst | 29 +
1 file changed, 29 insertions(+)
diff --git a/Documentati
Define UAPI for Shared Virtual Memory (SVM) fucntionality including
SVM capability and configurability.
When there is no GPU page fault support available, add ioctls
to explicitly bind and migrate virtual address ranges.
Cc: Joonas Lahtinen
Cc: Jon Bloomfield
Cc: Daniel Vetter
Cc: Sudeep Dutt
From: Venkata Sandeep Dhanalakota
As PCIe is non-coherent link, do not allow direct access to buffer
objects across the PCIe link for SVM case. Upon CPU accesses (mmap, pread),
migrate buffer object to host memory.
Cc: Joonas Lahtinen
Cc: Jon Bloomfield
Cc: Daniel Vetter
Cc: Sudeep Dutt
Cc:
For Shared Virtual Memory (SVM) system (SYS) allocator, there is no
backing buffer object (BO). Add support to bind a VA to PA mapping
in the device page table.
Cc: Joonas Lahtinen
Cc: Jon Bloomfield
Cc: Daniel Vetter
Cc: Sudeep Dutt
Signed-off-by: Niranjana Vishwanathapura
---
drivers/gpu/d
Copy the pages duing SVM migration using memcpy().
Cc: Joonas Lahtinen
Cc: Jon Bloomfield
Cc: Daniel Vetter
Cc: Sudeep Dutt
Signed-off-by: Niranjana Vishwanathapura
---
drivers/gpu/drm/i915/i915_svm_devmem.c | 72 ++
1 file changed, 72 insertions(+)
diff --git a/driv
Plugin device memory through HMM as DEVICE_PRIVATE.
Add support functions to allocate pages and free pages from device memory.
Implement ioctl to migrate pages from host to device memory.
For now, only support migrating pages from host memory to device memory.
Cc: Joonas Lahtinen
Cc: Jon Bloomfie
Add support to dump page table for debug purpose.
Here is an example dump. Format is,
[] :
Page Table dump start 0x0 len 0x
[0x0fe] 0x7f000: 0x6b0003
[0x1e6] 0x7f798: 0x6c0003
[0x16d] 0x7f79ada00: 0x5f0003
Add SVM as a capability and allow user to enable/disable SVM
functionality on a per context basis.
Cc: Joonas Lahtinen
Cc: Jon Bloomfield
Cc: Daniel Vetter
Cc: Sudeep Dutt
Signed-off-by: Niranjana Vishwanathapura
Signed-off-by: Venkata Sandeep Dhanalakota
---
drivers/gpu/drm/i915/gem/i915_g
Use blitter engine to copy pages during migration.
As blitter context virtual address space is shared with other flows,
ensure virtual address are allocated properly from that address space.
Also ensure completion of blitter copy by waiting on the fence of the
issued request.
Cc: Joonas Lahtinen
Add support function to blitter copy SVM VAs without requiring any
gem objects. Also add function to wait for completion of the copy.
Cc: Joonas Lahtinen
Cc: Jon Bloomfield
Cc: Daniel Vetter
Cc: Sudeep Dutt
Signed-off-by: Niranjana Vishwanathapura
---
drivers/gpu/drm/i915/Makefile
Shared Virtual Memory (SVM) allows the programmer to use a single virtual
address space which will be shared between threads executing on CPUs and GPUs.
It abstracts away from the user the location of the backing memory, and hence
simplifies the user programming model.
SVM supports two types of vir
As PCIe is non-coherent link, do not allow direct memory access across
PCIe link. Handle CPU fault by migrating pages back to host memory.
Cc: Joonas Lahtinen
Cc: Jon Bloomfield
Cc: Daniel Vetter
Cc: Sudeep Dutt
Signed-off-by: Niranjana Vishwanathapura
---
drivers/gpu/drm/i915/i915_svm_devme
Use HMM page table mirroring support to build device page table.
Implement the bind ioctl and bind the process address range in the
specified context's ppgtt.
Handle invalidation notifications by unbinding the address range.
Cc: Joonas Lahtinen
Cc: Jon Bloomfield
Cc: Daniel Vetter
Cc: Sudeep Du
From: Colin Ian King
The variables HiSidd and LoSidd are being initialized with values that
are never read and are being updated a little later with a new value.
The initialization is redundant and can be removed.
Addresses-Coverity: ("Unused value")
Signed-off-by: Colin Ian King
---
drivers/g
From: Colin Ian King
The variable ret is being initialized with a value that is never
read and it is being updated later with a new value. The
initialization is redundant and can be removed.
Addresses-Coverity: ("Unused value")
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/radeon/si_dpm.c
For eDP panels, it appears it's expected that so long as the panel is in
DPCD control mode that the brightness value is never set to 0. Instead,
if the desired effect is to set the panel's backlight to 0 we're
expected to simply turn off the backlight through the
DP_EDP_DISPLAY_CONTROL_REGISTER.
W
Currently we always determine the initial panel brightness level by
simply reading the value from DP_EDP_BACKLIGHT_BRIGHTNESS_MSB/LSB. This
seems wrong though, because if the panel is not currently in DPCD
control mode there's not really any reason why there would be any
brightness value programmed
I recently got a ThinkPad X1 Extreme 2nd Generation for fixing some
issues on, and noticed that out of the box the backlight doesn't work.
Along the way of fixing that, I found a few issues with how i915 handles
DPCD AUX backlight control and fixed them. Now I've got working
backlight controls, hoo
Max backlight value for the panel was being calculated using byte
count i.e. 0x if 2 bytes are supported for backlight brightness
and 0xff if 1 byte is supported. However, EDP_PWMGEN_BIT_COUNT
determines the number of active control bits used for the brightness
setting. Thus, even if the panel
Turns out we actually already have some companies, such as Lenovo,
shipping machines with AMOLED screens that don't allow controlling the
backlight through the usual PWM interface and only allow controlling it
through the standard EDP DPCD interface. One example of one of these
laptops is the X1 Ex
Annoyingly, the VBT on the ThinkPad X1 Extreme 2nd Gen indicates that
the system uses plain PWM based backlight controls, when in reality the
only backlight controls that work are the standard VESA eDP DPCD
backlight controls.
Honestly, this makes me wonder how many other systems have these issues
1 - 100 of 115 matches
Mail list logo
