On Tue, 14 Jan 2020, "Bharadiya,Pankaj"
wrote:
> Hi Jani,
>
> On Mon, Jan 13, 2020 at 02:14:51PM +0200, Jani Nikula wrote:
>> On Mon, 13 Jan 2020, Pankaj Bharadiya
>> wrote:
>> > We will need struct drm_device pointer to pass it to drm_WARN* calls.
>> >
>> > Add helper functions to exract
Hi
Am 13.01.20 um 19:52 schrieb Alex Deucher:
> On Fri, Jan 10, 2020 at 4:21 AM Thomas Zimmermann wrote:
>>
>> The callback struct drm_driver.get_scanout_position() is deprecated in
>> favor of struct drm_crtc_helper_funcs.get_scanout_position(). Convert
>> amdgpu over.
>>
>
> I would prefer to
On Fri, Jan 10, 2020 at 7:30 PM Steven Price wrote:
>
> On 09/01/2020 19:49, Mark Brown wrote:
> > On Thu, Jan 09, 2020 at 04:53:02PM +, Steven Price wrote:
> >> On 09/01/2020 16:28, Mark Brown wrote:
> >>> On Thu, Jan 09, 2020 at 02:14:42PM +, Steven Price wrote:
> >
> I'm not sure
The Bifrost GPU on MT8183 uses 2 regulators (core and SRAM) for
devfreq, and provides OPP table with 2 sets of voltages.
TODO: This is incomplete as we'll need add support for setting
a pair of voltages as well.
Signed-off-by: Nicolas Boichat
---
drivers/gpu/drm/panfrost/panfrost_devfreq.c |
Some GPUs, namely, the bifrost/g72 part on MT8183, have a second
regulator for their SRAM, let's add support for that.
We extend the framework in a generic manner so that we could
support more than 2 regulators, if required.
Signed-off-by: Nicolas Boichat
---
v3:
- Make this more generic, by
For testing only, the driver doesn't really work yet, AFAICT.
Signed-off-by: Nicolas Boichat
---
v3:
- Match mt8183-mali instead of bifrost, as we require special
handling for the 2 regulators and 3 power domains.
drivers/gpu/drm/panfrost/panfrost_drv.c | 9 +
1 file changed, 9
It is useful to know which component cannot be powered on.
Signed-off-by: Nicolas Boichat
Reviewed-by: Steven Price
Reviewed-by: Alyssa Rosenzweig
---
Was useful when trying to probe Bifrost GPU, to understand what
issue we are facing.
v3:
- Rebased on
When there is a single power domain per device, the core will
ensure the power domain is switched on (so it is technically
equivalent to having not power domain specified at all).
However, when there are multiple domains, as in MT8183 Bifrost
GPU, we need to handle them in driver code.
Define a compatible string for the Mali Bifrost GPU found in
Mediatek's MT8183 SoCs.
Signed-off-by: Nicolas Boichat
Reviewed-by: Alyssa Rosenzweig
---
v3:
- No change
.../bindings/gpu/arm,mali-bifrost.yaml | 18 ++
1 file changed, 18 insertions(+)
diff --git
Add a basic GPU node for mt8183.
Signed-off-by: Nicolas Boichat
Reviewed-by: Alyssa Rosenzweig
---
Upstreaming what matches existing bindings from our Chromium OS tree:
https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-4.19/arch/arm64/boot/dts/mediatek/mt8183.dtsi#1348
Hi!
Follow-up on the v2: https://patchwork.kernel.org/cover/11322801/ .
The main purpose of this series is to upstream the dts change and the binding
document, but I wanted to see how far I could probe the GPU, to check that the
binding is indeed correct. The rest of the patches are
https://bugzilla.kernel.org/show_bug.cgi?id=206141
--- Comment #4 from Janpieter Sollie (janpieter.sol...@dommel.be) ---
Hi Alex,
Thank you for the feedback. Tried that one as well.
When I already multiplied the timeout by 4, guess it will be the bad state
then.
Is there any way I could reset
On Mon, Jan 13, 2020 at 01:03:11PM +0200, Jyri Sarha wrote:
> Hi,
> While working with CRTC color related properties (gamma and CTM for
> instance) and making them persistent over suspend-resume cycle it
> occurred to me if I am just wasting resources by storing the property
> values in the driver
On Mon, Jan 13, 2020 at 10:01 AM Thomas Zimmermann wrote:
>
> Hi
>
> Am 13.01.20 um 00:00 schrieb Daniel Vetter:
> > On Fri, Jan 10, 2020 at 12:57:07PM +0100, Thomas Zimmermann wrote:
> >> In drm_atomic_helper_fake_vblank() the DRM core sends out VBLANK
> >> events if struct
Hi, Dave, Daniel:
This fix non-smooth cursor problem, add cmdq support, add ctm property
support and some refinement.
Regards,
CK
The following changes since commit
e42617b825f8073569da76dc4510bfa019b1c35a:
Linux 5.5-rc1 (2019-12-08 14:57:55 -0800)
are available in the Git repository at:
[AMD Public Use]
Thanks for your time and hope you get well soon!
-Original Message-
From: Lyude Paul
Sent: Tuesday, January 14, 2020 1:59 AM
To: Lin, Wayne ; dri-devel@lists.freedesktop.org;
amd-...@lists.freedesktop.org
Cc: Kazlauskas, Nicholas ; Wentland, Harry
; Zuo, Jerry
On Mon, Jan 13, 2020 at 3:17 PM Rob Clark wrote:
>
> On Mon, Jan 13, 2020 at 2:55 PM Brian Ho wrote:
> >
> > On Mon, Jan 13, 2020 at 09:57:43AM -0800, Kristian Kristensen wrote:
> > > On Mon, Jan 13, 2020 at 8:25 AM Rob Clark wrote:
> > >
> > > > On Mon, Jan 13, 2020 at 7:37 AM Brian Ho wrote:
On Tue, Jan 14, 2020 at 12:41 AM Jordan Crouse wrote:
>
> On Mon, Jan 13, 2020 at 09:25:57PM +0100, Bas Nieuwenhuizen wrote:
> > This
> >
> > 1) Enables core DRM syncobj support.
> > 2) Adds options to the submission ioctl to wait/signal syncobjs.
> >
> > Just like the wait fence fd, this does
Hi Ville,
So the two major changes you would like to see here are:
use version_greate(edid) function
and make use of :
drm_for_each_detailed_block() instead of the for loop.
But this function does not parse the monitor range yet so
you are suggesting modifying that dmr helper function as well?
On Mon, Jan 13, 2020 at 09:25:57PM +0100, Bas Nieuwenhuizen wrote:
> This
>
> 1) Enables core DRM syncobj support.
> 2) Adds options to the submission ioctl to wait/signal syncobjs.
>
> Just like the wait fence fd, this does inline waits. Using the
> scheduler would be nice but I believe it is
Jyri Sarha wrote on Fri [2019-Dec-20 17:55:13 +0200]:
> Add entry for tidss DRM driver.
>
> Version history:
>
> v2: no change
>
> v3: - Move tidss entry after omapdrm
> - Add "T: git git://anongit.freedesktop.org/drm/drm-misc"
>
> v4: no change
>
> v5: no change
>
> Signed-off-by:
Jyri Sarha wrote on Fri [2019-Dec-20 17:55:10 +0200]:
> Add dt-schema yaml bindig for AM65x DSS, AM65x version TI Keystone
> Display SubSystem.
>
> Version history:
>
> v2: no change
>
> v3: - Add ports node
> - use allOf in ti,am65x-oldi-io-ctrl to add both $ref and maxItems
> - Add
Jyri Sarha wrote on Fri [2019-Dec-20 17:55:09 +0200]:
> Add dt-schema yaml bindig for K2G DSS, an ultra-light version of TI
> Keystone Display SubSystem.
>
> Version history:
>
> v2: no change
>
> v3: - Add ports node
> - Add includes to dts example
> - reindent dts example
>
> v4: -
Jyri Sarha wrote on Fri [2019-Dec-20 17:55:12 +0200]:
> This patch adds a new DRM driver for Texas Instruments DSS IPs used on
> Texas Instruments Keystone K2G, AM65x, and J721e SoCs. The new DSS IP is
> a major change to the older DSS IP versions, which are supported by
> the omapdrm driver.
Jyri Sarha wrote on Fri [2019-Dec-20 17:55:11 +0200]:
> Add dt-schema yaml bindig for J721E DSS, J721E version TI Keystone
> Display SubSystem.
>
> Version history:
>
> v2: no change
>
> v3: - reg-names: "wp" -> "wb"
> - Add ports node
> - Add includes to dts example
> - reindent
My compiler yells:
.../drivers/gpu/drm/msm/adreno/adreno_gpu.c:69:27:
error: '/*' within block comment [-Werror,-Wcomment]
Let's fix.
Fixes: 6a0dea02c2c4 ("drm/msm: support firmware-name for zap fw (v2)")
Signed-off-by: Douglas Anderson
---
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 2 +-
Hi,
On Tue, Jan 07, 2020 at 04:59:56PM +0530, Harigovindan P wrote:
> Subject: dt-bindings: display: add sc7180 panel variant
>
> Add a compatible string to support sc7180 panel version.
The sc7180 is a SoC, I suppose you are referring to the sc7180-idp, a
board based on this SoC. But even with
This
1) Enables core DRM syncobj support.
2) Adds options to the submission ioctl to wait/signal syncobjs.
Just like the wait fence fd, this does inline waits. Using the
scheduler would be nice but I believe it is out of scope for
this work.
Support for timeline syncobjs is implemented and the
On Fri, Jan 10, 2020 at 4:22 AM Thomas Zimmermann wrote:
>
> VBLANK callbacks in struct drm_driver are deprecated in favor of
> their equivalents in struct drm_crtc_funcs. Convert radeon over.
>
> Signed-off-by: Thomas Zimmermann
Reviewed-by: Alex Deucher
> ---
>
On Fri, Jan 10, 2020 at 4:22 AM Thomas Zimmermann wrote:
>
> VBLANK callbacks in struct drm_driver are deprecated in favor of
> their equivalents in struct drm_crtc_funcs. Convert amdgpu over.
I think I'd prefer to just update the signatures of the relevant
functions rather than wrapping them.
Hi Pankaj.
On Mon, Jan 13, 2020 at 05:25:52PM +0530, Pankaj Bharadiya wrote:
> Add new struct drm_device based WARN* macros. These are modeled after
> the core kernel device based WARN* macros. These would be preferred
> over the regular WARN* macros, where possible.
>
> These macros include
On Fri, Jan 10, 2020 at 4:22 AM Thomas Zimmermann wrote:
>
> The callback struct drm_driver.get_scanout_position() is deprecated in
> favor of struct drm_crtc_helper_funcs.get_scanout_position(). Convert
> radeon over.
>
I'd prefer to just change the signature of
radeon_get_crtc_scanoutpos() to
On Fri, Jan 10, 2020 at 4:21 AM Thomas Zimmermann wrote:
>
> The callback struct drm_driver.get_scanout_position() is deprecated in
> favor of struct drm_crtc_helper_funcs.get_scanout_position(). Convert
> amdgpu over.
>
I would prefer to just change the signature of
On Mon, Jan 13, 2020 at 02:33:36PM +0200, Jani Nikula wrote:
> On Mon, 13 Jan 2020, Pankaj Bharadiya
> wrote:
> > Device specific dev_WARN and dev_WARN_ONCE macros available in kernel
> > include device information in the backtrace, so we know what device
> > the warnings originate from.
> >
> >
Hi Jani,
On Mon, Jan 13, 2020 at 02:14:51PM +0200, Jani Nikula wrote:
> On Mon, 13 Jan 2020, Pankaj Bharadiya
> wrote:
> > We will need struct drm_device pointer to pass it to drm_WARN* calls.
> >
> > Add helper functions to exract drm_device pointer from various structs.
>
> Please don't do
Hey! Haven't taken a look at this patch yet but just wanted to let you know
I'm going to try to get to most of the stuff you've got pending for me. I came
down with a really nasty cold last week so sorry if you've had any other
patches waiting until now!
On Mon, 2020-01-13 at 17:36 +0800, Wayne
On Mon, Jan 13, 2020 at 10:36:04AM -0500, Brian Ho wrote:
> This wait queue is signaled on all IRQs for a given GPU and will be
> used as part of the new MSM_WAIT_IOVA ioctl so userspace can sleep
> until the value at a given iova reaches a certain condition.
>
> Signed-off-by: Brian Ho
> ---
>
On Mon, Jan 13, 2020 at 10:36:05AM -0500, Brian Ho wrote:
> Implements an ioctl to wait until a value at a given iova is greater
> than or equal to a supplied value.
>
> This will initially be used by turnip (open-source Vulkan driver for
> QC in mesa) for occlusion queries where the userspace
On Sun, Jan 12, 2020 at 11:53:58AM -0800, Rob Clark wrote:
> From: Rob Clark
>
> For newer devices we want to require the path to come from the
> firmware-name property in the zap-shader dt node.
Reviewed-by: Jordan Crouse
> Signed-off-by: Rob Clark
> ---
>
Hi Paul.
On Mon, Jan 13, 2020 at 01:17:41PM -0300, Paul Cercueil wrote:
> The FRD350H54004 is a simple 3.5" 320x240 24-bit TFT panel, found for
> instance inside the Anbernic RG-350 handheld gaming console.
>
> v2: Order alphabetically
> v3: Add connector_type, and update timings according to
Hi Paul.
On Mon, Jan 13, 2020 at 01:17:40PM -0300, Paul Cercueil wrote:
> Add bindings documentation for the Frida 3.5" (320x240 pixels) 24-bit
> TFT LCD panel.
>
> v2: Switch documentation from plain text to YAML
> v3: Simply add new compatible to panel-simple.yaml file instead of
> adding
Hi Paul.
On Mon, Jan 13, 2020 at 01:17:39PM -0300, Paul Cercueil wrote:
> Add an entry for Shenzhen Frida LCD Co., Ltd.
>
> v2: No change
> v3: No change
>
> Signed-off-by: Paul Cercueil
> Acked-by: Sam Ravnborg
> Acked-by: Rob Herring
Applied to drm-misc-next.
Sam
> ---
>
On Sun, Jan 12, 2020 at 11:53:57AM -0800, Rob Clark wrote:
> From: Rob Clark
>
> Since zap firmware can be device specific, allow for a firmware-name
> property in the zap node to specify which firmware to load, similarly to
> the scheme used for dsp/wifi/etc.
>
> v2: only need a single error
On Mon, Dec 16, 2019 at 07:46:43PM -0800, Juston Li wrote:
> 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
>
>
On 09/01/2020 17:27, Martin Blumenstingl wrote:
> On Thu, Jan 9, 2020 at 12:31 PM Steven Price wrote:
>>
>> On 07/01/2020 23:06, Martin Blumenstingl wrote:
>>> dev_pm_opp_set_rate() needs a reference to the regulator which should be
>>> updated when updating the GPU frequency. The name of the
On Mon, Jan 13, 2020 at 08:20:42AM -0500, mikita.lip...@amd.com wrote:
> From: Mikita Lipski
>
> [why]
> Fix compilation warnings on i386 architecture:
> undefined reference to `__udivdi3'
> [how]
> Switch DIV_ROUND_UP to DIV64_U64_ROUND_UP
>
> Reported-by: Randy Dunlap
> Signed-off-by: Mikita
On 2020-01-13 8:20 a.m., mikita.lip...@amd.com wrote:
> From: Mikita Lipski
>
> [why]
> Fix compilation warnings on i386 architecture:
> undefined reference to `__udivdi3'
> [how]
> Switch DIV_ROUND_UP to DIV64_U64_ROUND_UP
>
> Reported-by: Randy Dunlap
> Signed-off-by: Mikita Lipski
https://bugzilla.kernel.org/show_bug.cgi?id=206141
Alex Deucher (alexdeuc...@gmail.com) changed:
What|Removed |Added
CC|
I just came across a DMAR allocation issue when I wanted to use the UDL
driver with a DL-165 chipset and had the Intel IOMMU enabled.
It seems like it could be solved with the same patch already applied to
the EVDI driver:
Hi Maxime,
On Mon, Dec 16, 2019 at 07:08:12PM +0100, Stephan Gerhold wrote:
> 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
Am 13.01.20 um 16:35 schrieb Qiang Yu:
Charge TTM allocated system memory to memory cgroup which will
limit the memory usage of a group of processes.
NAK to the whole approach. This belongs into the GEM or driver layer,
but not into TTM.
The memory is always charged to the control group of
On Mon, Jan 13, 2020 at 10:45:25PM +0800, Christian König wrote:
> Ping? Just a trivial cleanup.
>
> Am 10.01.20 um 16:09 schrieb Christian König:
> > Another completely unused feature.
> >
> > Signed-off-by: Christian König
Reviewed-by: Huang Rui
> > ---
> >
Charge TTM allocated system memory to memory cgroup which will
limit the memory usage of a group of processes.
The memory is always charged to the control group of task which
create this buffer object and when it's created. For example,
when a buffer is created by process A and exported to
Signed-off-by: Qiang Yu
---
include/linux/memcontrol.h | 1 +
mm/memcontrol.c| 9 +
2 files changed, 10 insertions(+)
diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
index d76977943265..6518b4b5ee07 100644
--- a/include/linux/memcontrol.h
+++
This is for driver which will allocate memory for both user application
and kernel device driver usage. For example, GPU driver will allocate
some GFP_USER pages and mapped to user to fill commands and data like
texture and vertex, then let GPU command processor "eat" these memory.
These buffers
Buffers created by GPU driver could be huge (often several MB and even hundred
or thousand MB). Some GPU driver call drm_gem_get_pages() which uses shmem to
allocate these buffers which will charge memcg already, while some GPU driver
like amdgpu use TTM which just allocate these system memory
okay.. so checking whatever is the difference with _REV being 5
(meaning the firmware uses the legacy paths) doesn't help in any way.
It's using a different method to turn the link of and the other ACPI
variables touched either point to undocumented registers on the PCI
bridge or internal ACPI
From: Colin Ian King
There is a hunk of code that is incorrectly indented, clean up the
indentation and a comment block. Also remove block braces around a
one line statement on an if condition and add missing spaces after
if keywords.
Signed-off-by: Colin Ian King
---
Ping? Just a trivial cleanup.
Am 10.01.20 um 16:09 schrieb Christian König:
Another completely unused feature.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 6 --
drivers/gpu/drm/nouveau/nouveau_bo.c | 8
drivers/gpu/drm/qxl/qxl_ttm.c
This patch adds the support for the notification of HD-audio hotplug
via the already existing drm_audio_component framework. This allows
us more reliable hotplug notification and ELD transfer without
accessing HD-audio bus; it's more efficient, and more importantly, it
works without waking up the
From: Mikita Lipski
[why]
Fix compilation warnings on i386 architecture:
undefined reference to `__udivdi3'
[how]
Switch DIV_ROUND_UP to DIV64_U64_ROUND_UP
Reported-by: Randy Dunlap
Signed-off-by: Mikita Lipski
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c | 2 +-
1 file
From: Colin Ian King
There are a couple of statements that are indented too deeply,
clean these up by removing the extraneous tabs. Also remove an
empty line.
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/gma500/cdv_intel_dp.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
Am Dienstag, 31. Dezember 2019, 09:12:36 CET schrieb Krzysztof Kozlowski:
> The Rockship DRM GEM code uses vmap()/vunmap() so vmalloc header must be
> included to avoid warnings like (on IA64, compile tested):
>
> drivers/gpu/drm/rockchip/rockchip_drm_gem.c: In function
>
On Mon, 13 Jan 2020, Chen Zhou wrote:
> If CONFIG_ACPI=n and CONFIG_BACKLIGHT_CLASS_DEVICE=m, compilation complains
> with undefined references:
>
> drivers/gpu/drm/i915/display/intel_panel.o: In function
> `intel_backlight_device_register':
> intel_panel.c:(.text+0x4dd9): undefined reference to
On Mon, Dec 30, 2019 at 3:04 AM Enric Balletbo i Serra
wrote:
>
> From: Jitao Shi
>
> Add documentation for DT properties supported by
> ps8640 DSI-eDP converter.
>
> Signed-off-by: Jitao Shi
> Acked-by: Rob Herring
> Reviewed-by: Philipp Zabel
> Signed-off-by: Ulrich Hecht
> Signed-off-by:
Add pixel clock limits to the driver as per TFP410 datasheet: min 25MHz,
max 165MHz.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/bridge/ti-tfp410.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/bridge/ti-tfp410.c
b/drivers/gpu/drm/bridge/ti-tfp410.c
Am Donnerstag, 9. Januar 2020, 15:20:57 CET schrieb Wambui Karuga:
> Replace the open coded calculation with the more concise and readable
> DIV_ROUND_UP macro.
>
> Signed-off-by: Wambui Karuga
applied to drm-misc-next
Thanks
Heiko
___
dri-devel
Am Donnerstag, 9. Januar 2020, 08:31:29 CET schrieb Tobias Schramm:
> commmit 2589c4025f13 ("drm/rockchip: Avoid drm_dp_link helpers") changes
> the type of variables used to store the display port data rate and
> number of lanes to u8. However u8 is not sufficient to store the link
> data rate of
Hi Andrzej,
On 09/12/2019 16:45, Andrey Smirnov wrote:
+ Chris Healy
On Mon, Dec 9, 2019 at 12:27 AM Tomi Valkeinen wrote:
Link training fails with:
Link training timeout waiting for LT_LOOPDONE!
main link enable error: -110
This is caused by too tight timeouts, which were changed
https://bugzilla.kernel.org/show_bug.cgi?id=206141
--- Comment #2 from Janpieter Sollie (janpieter.sol...@dommel.be) ---
Tried to make ALL functions where ETIMEDOUT is specified (in
drivers/gpu/amd/amdgpu/) with timeout << 2, but nothing. Am I looking at the
wrong function here?
--
You are
On Fri, Jan 3, 2020 at 2:09 PM Bartlomiej Zolnierkiewicz
wrote:
> On 10/29/19 8:02 PM, Eric W. Biederman wrote:
> >
> > The goal is to avoid memory that has values of the previous users of
> > that memory region from leaking to userspace. Which depending on who
> > the previous user of that
On Mon, 13 Jan 2020, Pankaj Bharadiya
wrote:
> Device specific dev_WARN and dev_WARN_ONCE macros available in kernel
> include device information in the backtrace, so we know what device
> the warnings originate from.
>
> Similar to this, add new struct drm_device based drm_WARN* macros. These
>
On Mon, 13 Jan 2020, Pankaj Bharadiya
wrote:
> Add new struct drm_device based WARN* macros. These are modeled after
> the core kernel device based WARN* macros. These would be preferred
> over the regular WARN* macros, where possible.
>
> These macros include device information in the
On Mon, 13 Jan 2020, Pankaj Bharadiya
wrote:
> We will need struct drm_device pointer to pass it to drm_WARN* calls.
>
> Add helper functions to exract drm_device pointer from various structs.
Please don't do this.
We use the helpers we currently have when they involve something more
complex
On Mon, 13 Jan 2020, Chris Wilson wrote:
> Quoting Wambui Karuga (2020-01-13 11:10:25)
>> fn(...) {
>> ...
>> struct intel_engine_cs *E = ...;
>> +struct drm_i915_private *dev_priv = E->i915;
>
> No new dev_priv.
Wambui, we're gradually converting all dev_priv variable and parameter
names to
Hi Thierry,
On 02/12/2019 15:07, Laurent Pinchart wrote:
Hi Tomi,
Thank you for the patch.
On Thu, Nov 14, 2019 at 11:39:50AM +0200, Tomi Valkeinen wrote:
The panel datasheet says that the panel samples at falling edge, but
does not say anything about h/v sync signals. Testing shows that if
Drm specific drm_WARN* calls include device information in the
backtrace, so we know what device the warnings originate from.
Covert all the calls of WARN* with device specific drm_WARN*
variants in functions where any one of intel_pm, intel_encoder,
i915_perf_stream or intel_crtc_state struct
Drm specific WARN* calls include device information in the
backtrace, so we know what device the warnings originate from.
Covert all the calls of WARN* with device specific drm_WARN*
variants in functions where first function argument is a
struct pointer and has drm_i915_private struct pointer
On 12/12/2019 22:35, Laurent Pinchart wrote:
Hi Tomi,
On Thu, Dec 12, 2019 at 11:37:51AM +0200, Tomi Valkeinen wrote:
On 11/12/2019 18:53, Tony Lindgren wrote:
* Laurent Pinchart [191202 13:05]:
Hi Tomi,
Thank you for the patch.
On Thu, Nov 14, 2019 at 11:39:49AM +0200, Tomi Valkeinen
Drm specific drm_WARN* calls include device information in the
backtrace, so we know what device the warnings originate from.
Covert all the calls of WARN* with device specific drm_WARN*
variants in functions where drm_device struct pointer is readily
available.
The conversion was done
We will need struct drm_device pointer to pass it to drm_WARN* calls.
Add helper functions to exract drm_device pointer from various structs.
Signed-off-by: Pankaj Bharadiya
---
drivers/gpu/drm/i915/display/intel_display_types.h | 14 ++
drivers/gpu/drm/i915/gvt/gvt.h
Device specific dev_WARN and dev_WARN_ONCE macros available in kernel
include device information in the backtrace, so we know what device
the warnings originate from.
Similar to this, add new struct drm_device based drm_WARN* macros. These
macros include device information in the backtrace, so we
Add new struct drm_device based WARN* macros. These are modeled after
the core kernel device based WARN* macros. These would be preferred
over the regular WARN* macros, where possible.
These macros include device information in the backtrace, so we know
what device the warnings originate from.
Quoting Wambui Karuga (2020-01-13 11:10:25)
> fn(...) {
> ...
> struct intel_engine_cs *E = ...;
> +struct drm_i915_private *dev_priv = E->i915;
No new dev_priv.
There should be no reason for drm_dbg here, as the rest of the debug is
behind ENGINE_TRACE and so the vestigial debug should be moved
The "fix" struct has a 2 byte hole after ->ywrapstep and the
"fix = info->fix;" assignment doesn't necessarily clear it. It depends
on the compiler. The solution is just to replace the assignment with an
memcpy().
Fixes: 1f5e31d7e55a ("fbmem: don't call copy_from/to_user() with mutex held")
Hi,
While working with CRTC color related properties (gamma and CTM for
instance) and making them persistent over suspend-resume cycle it
occurred to me if I am just wasting resources by storing the property
values in the driver and restoring them in dev_pm_ops runtime_resume()..
Wouldn't it work
[Why]
Noticed this while testing MST with the 4 ports MST hub from
StarTech.com. Sometimes can't light up monitors normally and get the
error message as 'sideband msg build failed'.
Look into aux transactions, found out that source sometimes will send
out another down request before receiving the
Hi
Am 13.01.20 um 00:00 schrieb Daniel Vetter:
> On Fri, Jan 10, 2020 at 12:57:07PM +0100, Thomas Zimmermann wrote:
>> In drm_atomic_helper_fake_vblank() the DRM core sends out VBLANK
>> events if struct drm_crtc_state.no_vblank is enabled. Replace cirrus'
>> VBLANK events with the DRM core's
https://bugzilla.kernel.org/show_bug.cgi?id=206155
--- Comment #3 from Janpieter Sollie (janpieter.sol...@dommel.be) ---
Created attachment 286777
--> https://bugzilla.kernel.org/attachment.cgi?id=286777=edit
amdgpu module load with all debugging turned on
hereby the debug info of the amdgpu
Hi John
Am 10.01.20 um 13:54 schrieb John Garry:
>
>
> Hi Thomas,
>
>> drm-tip now contains
>
> I have tested today's linux-next, which includes this:
>
>>
>> commit a88248506a2bcfeaef6837a53cde19fe11970e6c
>> Author: Thomas Zimmermann
>> Date: Tue Dec 3 09:38:15 2019 +0100
>>
>>
90 matches
Mail list logo
