Hi Prike,
FYI, the error/warning still remains.
tree: git://people.freedesktop.org/~agd5f/linux.git amd-19.50
head: 1f30c089d757f6d88703676d913f06d8a5ef4353
commit: 8d660d16d64cb75fab00f3e78409a93394cb7d29 [2055/2704] drm/amdkcl: Test
whether drm_dev_put is available
config:
[AMD Public Use]
Sorry for any inconvenience I brought.
Thank you so much Lyude, I will have a look on that fix patch later.
> -Original Message-
> From: Lyude Paul
> Sent: Saturday, January 18, 2020 4:45 AM
> To: Sean Paul
> Cc: Lin, Wayne ; dri-devel@lists.freedesktop.org;
>
Hi changzhu,
FYI, the error/warning still remains.
tree: git://people.freedesktop.org/~agd5f/linux.git amd-19.50
head: 1f30c089d757f6d88703676d913f06d8a5ef4353
commit: f12f9b802b6dd80fdee0b7c601b8b9d59a967556 [2031/2704] drm/amdkcl: Test
if linux/overflow.h and struct_size exists
config:
Hi all,
Today's linux-next merge of the drm tree got a conflict in:
drivers/gpu/drm/i915/i915_gem_gtt.c
between commit:
ecc4d2a52df6 ("drm/i915/userptr: fix size calculation")
from the drm-intel-fixes tree and commit:
2c86e55d2ab5 ("drm/i915/gtt: split up i915_gem_gtt")
from the drm
On Tue, Jan 21, 2020 at 10:40:48PM +, Eric Engestrom wrote:
> On Monday, 2020-01-20 18:43:43 +0200, Imre Deak wrote:
> > Platforms without a HW detiler doesn't support the get_tiling IOCTL.
> > Fix the drm_intel_bo_gem_create_from_* functions assuming the default
> > no-tiling, no-swizzling
From: Heiko Stuebner
rockchip_drm_endpoint_is_subdriver() may also return error codes.
For example if the target-node is in the disabled state, so no
platform-device is getting created for it.
In that case current code would count that as external rgb device,
which in turn would make probing
On Monday, 2020-01-20 18:43:43 +0200, Imre Deak wrote:
> Platforms without a HW detiler doesn't support the get_tiling IOCTL.
> Fix the drm_intel_bo_gem_create_from_* functions assuming the default
> no-tiling, no-swizzling setting for the GEM buffer in this case.
>
> Signed-off-by: Imre Deak
>
Hi Anatoli,
FYI, the error/warning still remains.
tree: git://people.freedesktop.org/~agd5f/linux.git amd-19.50
head: 1f30c089d757f6d88703676d913f06d8a5ef4353
commit: c3612b68d1358e8325c377ba5e1f690b39a6cea8 [1967/2704] drm/amdkcl: Test
whether drm_gem_object_put_unlocked() is available
This will calculaet the DC3CO exit delay only once per full modeset.
Cc: Imre Deak
Cc: Anshuman Gupta
Reviewed-by: Anshuman Gupta
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/display/intel_psr.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git
A recent change in BSpec allow us to change EXTLINE while transcoder
is enabled so this allow us to change it even when doing the first
fastset after taking over previous hardware state set by BIOS.
BIOS don't enable PSR, so if sink supports PSR it will be enabled on
the first fastset, so moving
Hi Oleksandr.
>
> There some typos:
>
> > diff --git
> > a/Documentation/devicetree/bindings/display/panel/panel-timing.yaml
> > b/Documentation/devicetree/bindings/display/panel/panel-timing.yaml
> > new file mode 100644
> > index ..59891c7a58ee
> > --- /dev/null
> > +++
On Tue, Jan 21, 2020 at 11:19 AM Douglas Anderson wrote:
>
> From: Sean Paul
>
> Turning on CONFIG_DMA_API_DEBUG_SG results in the following error:
>
> [ 12.078665] msm ae0.mdss: DMA-API: mapping sg segment longer than
> device claims to support [len=3526656] [max=65536]
> [ 12.089870]
From: Sean Paul
Turning on CONFIG_DMA_API_DEBUG_SG results in the following error:
[ 12.078665] msm ae0.mdss: DMA-API: mapping sg segment longer than device
claims to support [len=3526656] [max=65536]
[ 12.089870] WARNING: CPU: 6 PID: 334 at
On Tue, Jan 21, 2020 at 5:10 PM Lucas Stach wrote:
>
> Hi Guido,
>
> On Di, 2020-01-21 at 13:55 +0100, Guido Günther wrote:
> > Hi,
> > On Tue, Jan 21, 2020 at 12:45:25PM +0100, Arnd Bergmann wrote:
> > > As Guido Günther reported, get_abs_timeout() in the etnaviv user space
> > > sometimes
On Mon, 20 Jan 2020 at 16:43, Imre Deak wrote:
>
> Platforms without a HW detiler doesn't support the get_tiling IOCTL.
> Fix the drm_intel_bo_gem_create_from_* functions assuming the default
> no-tiling, no-swizzling setting for the GEM buffer in this case.
>
> Signed-off-by: Imre Deak
Seems
On Thu, 27 Jun 2019 at 22:37, John Stultz wrote:
>
> Often there are many similar modes, which cannot be selected
> via modetest due to its simple string matching.
>
> This change adds a mode index in the display output, which can
> then be used to specify a specific modeline to be set.
>
> Cc:
On Tue, Jan 21, 2020 at 07:29:37PM +0100, Maxime Ripard wrote:
> > Mark, our issue here is that we have a driver tied to a device that is
> > an HDMI encoder. Obviously, we'll want to register into DRM, which is
> > what we were doing so far, with the usual case where at remove /
> > unbind time,
Hi Ezequiel,
The first patch looks spot on. I'll commit it in a moment.
On Mon, 22 Jul 2019 at 17:08, Ezequiel Garcia wrote:
>
> This option finds the first connected connector and then
> sets its preferred mode on it.
>
> Set this option to be set when no mode or plane is set
> explicitily.
Actually Cc'ing this time..
On Tue, Jan 21, 2020 at 07:29:05PM +0100, Maxime Ripard wrote:
> +Mark
>
> On Mon, Jan 20, 2020 at 02:33:26PM +0200, Stefan Mavrodiev wrote:
> > Add HDMI audio support for the sun4i-hdmi encoder, used on
> > the older Allwinner chips - A10, A20, A31.
> >
> > Most of
+Mark
On Mon, Jan 20, 2020 at 02:33:26PM +0200, Stefan Mavrodiev wrote:
> Add HDMI audio support for the sun4i-hdmi encoder, used on
> the older Allwinner chips - A10, A20, A31.
>
> Most of the code is based on the BSP implementation. In it
> dditional formats are supported (S20_3LE and S24_LE),
> --- Comment #23 from Alex Deucher (alexdeuc...@gmail.com) ---
> Is this roughly the same model every GPU vendor uses. GPUs are complex.
No offense intended! It is obvious that the maths being the same for everybody,
sensible hardware models will all look alike. It was more to underline the
https://bugzilla.kernel.org/show_bug.cgi?id=206231
--- Comment #24 from Sylvain BERTRAND (sylvain.bertr...@gmail.com) ---
> --- Comment #23 from Alex Deucher (alexdeuc...@gmail.com) ---
> Is this roughly the same model every GPU vendor uses. GPUs are complex.
No offense intended! It is obvious
On Mon, 20 Jan 2020 10:44:33 +0800, allen wrote:
> Add a DT binding documentation for IT6505.
>
> Acked-by: Sam Ravnborg
> Signed-off-by: Allen Chen
> Signed-off-by: Pi-Hsun Shih
> ---
> .../bindings/display/bridge/ite,it6505.yaml| 89
> ++
> 1 file changed, 89
On Thu, 16 Jan 2020 15:20:31 +
lukasz.l...@arm.com wrote:
> diff --git a/include/trace/events/thermal.h b/include/trace/events/thermal.h
> index 135e5421f003..8a5f04888abd 100644
> --- a/include/trace/events/thermal.h
> +++ b/include/trace/events/thermal.h
> @@ -153,31 +153,30 @@
On Mon, Jan 20, 2020 at 11:56 AM Ezequiel Garcia wrote:
>
> On Sat, 2019-12-14 at 01:59 -0300, Ezequiel Garcia wrote:
> > Currently, the interrupt lines requested by Panfrost
> > use unmeaningful names, which adds some obscurity
> > to interrupt introspection (i.e. any tool based
> > on procfs'
On Fri, Jan 17, 2020 at 8:52 AM Matt Hoosier wrote:
>
> Hi all,
>
> I'm confronting a situation where the hardware with which I work is capable
> of driving connectors at 4K or 8K, but doing so requires bonding the scanning
> of multiple planes together.
>
> The scenario is that you'd have a
Hi Guido,
On Di, 2020-01-21 at 13:55 +0100, Guido Günther wrote:
> Hi,
> On Tue, Jan 21, 2020 at 12:45:25PM +0100, Arnd Bergmann wrote:
> > As Guido Günther reported, get_abs_timeout() in the etnaviv user space
> > sometimes passes timeouts with nanosecond values larger than 10,
> > which
https://bugzilla.kernel.org/show_bug.cgi?id=206231
--- Comment #23 from Alex Deucher (alexdeuc...@gmail.com) ---
(In reply to Sylvain BERTRAND from comment #22)
> Only the AMD/mesa devs can reasonably deal with the insane complexity of the
> GL
> stack (linux(drm) + libdrm + llvm + mesa(GL) +
On Tue, Jan 21, 2020 at 08:01:49AM +, bugzilla-dae...@bugzilla.kernel.org
wrote:
> Yesterday, I compiled and installed the 5.4.13 kernel, but got no
> improvements.
Only the AMD/mesa devs can reasonably deal with the insane complexity of the GL
stack (linux(drm) + libdrm + llvm + mesa(GL) +
https://bugzilla.kernel.org/show_bug.cgi?id=206231
--- Comment #22 from Sylvain BERTRAND (sylvain.bertr...@gmail.com) ---
On Tue, Jan 21, 2020 at 08:01:49AM +, bugzilla-dae...@bugzilla.kernel.org
wrote:
> Yesterday, I compiled and installed the 5.4.13 kernel, but got no
> improvements.
Only
Hi Slava,
FYI, the error/warning still remains.
tree: git://people.freedesktop.org/~agd5f/linux.git amd-19.50
head: 1f30c089d757f6d88703676d913f06d8a5ef4353
commit: f2e0d469732d27bc612df52b42094309ba5877d9 [1963/2704] drm/amdkcl: Test
whether drm_crtc_init_with_planes() wants name
config:
Hi Andrzej,
On 16/01/2020 16.35, Andrzej Hajda wrote:
> On 17.12.2019 11:15, Peter Ujfalusi wrote:
>> Add basic support for the Toshiba TC358768 RGB to DSI bridge.
>> Not all the features of the TC358768 is implemented by the initial driver:
>> MIPI_DSI_MODE_VIDEO and MIPI_DSI_FMT_RGB888 is only
On Mon, Jan 20, 2020 at 2:07 PM Sam Ravnborg wrote:
>
> With panel-timing converted, now convert the single
> remaining .txt user in panel/ of panel-timing to DT schema.
>
> Signed-off-by: Sam Ravnborg
> Cc: Rob Herring
> Cc: Thierry Reding
> Cc: Laurent Pinchart
> Cc: Maxime Ripard
> ---
>
On Mon, Jan 20, 2020 at 2:58 AM Pekka Paalanen wrote:
> On Fri, 17 Jan 2020 10:51:45 -0600
> Matt Hoosier wrote:
>
> > Hi all,
> >
> > I'm confronting a situation where the hardware with which I work is
> capable
> > of driving connectors at 4K or 8K, but doing so requires bonding the
> >
On Mon, Jan 20, 2020 at 2:07 PM Sam Ravnborg wrote:
>
> Add meta-schema variant of panel-timing and
> reference it from panel-common.yaml.
>
> Signed-off-by: Sam Ravnborg
> Cc: Laurent Pinchart
> Cc: Rob Herring
> Cc: Thierry Reding
> Cc: Oleksandr Suvorov
> Cc: devicet...@vger.kernel.org
>
On Tue, Jan 21, 2020 at 12:53:30PM +0200, Jani Nikula wrote:
> Allow a mask of features to be passed to drm_core_check_feature(). All
> features in the mask are required.
>
> Signed-off-by: Jani Nikula
> ---
> include/drm/drm_drv.h | 10 ++
> 1 file changed, 6 insertions(+), 4
On Tue, Jan 21, 2020 at 6:35 AM Dafna Hirschfeld
wrote:
>
> convert the binding file rockchip-drm.txt to yaml format.
> This was tested and verified with:
> make dt_binding_check
> DT_SCHEMA_FILES=Documentation/devicetree/bindings/display/rockchip/rockchip-drm.yaml
Also, make sure just 'make
From: xinhui pan
As we move the ttm_bo_individualize_resv() upwards, we need flush the
copied fence too. Otherwise the driver keeps waiting for fence.
run kfdtest, then perf top.
25.53% [ttm] [k] ttm_bo_delayed_delete
24.29% [kernel] [k]
On Tue, Jan 21, 2020 at 01:55:46PM +0100, Guido Günther wrote:
> Hi,
> On Tue, Jan 21, 2020 at 12:45:25PM +0100, Arnd Bergmann wrote:
> > As Guido Günther reported, get_abs_timeout() in the etnaviv user space
> > sometimes passes timeouts with nanosecond values larger than 10,
> > which
Hi,
On Tue, Jan 21, 2020 at 12:45:25PM +0100, Arnd Bergmann wrote:
> As Guido Günther reported, get_abs_timeout() in the etnaviv user space
> sometimes passes timeouts with nanosecond values larger than 10,
> which gets rejected after my first patch.
>
> To avoid breaking this, while also
On 21-01-20, 13:37, Stefan Mavrodiev wrote:
>
> On 1/21/20 10:35 AM, Vinod Koul wrote:
> > On 15-01-20, 18:07, Maxime Ripard wrote:
> > > On Wed, Jan 15, 2020 at 06:01:37PM +0530, Vinod Koul wrote:
> > > > On 10-01-20, 16:11, Stefan Mavrodiev wrote:
> > > > > Currently the cyclic transfers can be
As Guido Günther reported, get_abs_timeout() in the etnaviv user space
sometimes passes timeouts with nanosecond values larger than 10,
which gets rejected after my first patch.
To avoid breaking this, while also not allowing completely arbitrary
values, set the limit to 19 and
On Tue, Jan 21, 2020 at 11:22 AM Lucas Stach wrote:
>
> On Mo, 2020-01-20 at 19:47 +0100, Arnd Bergmann wrote:
> > On Mon, Jan 20, 2020 at 6:48 PM Lucas Stach wrote:
> > > On Fr, 2020-01-17 at 16:47 +0100, Guido Günther wrote:
> > > > This breaks rendering here on arm64/gc7000 due to
> > > >
> >
Allow a mask of features to be passed to drm_core_check_feature(). All
features in the mask are required.
Signed-off-by: Jani Nikula
---
include/drm/drm_drv.h | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
index
Use drm_core_check_feature() to ensure both the driver features and the
per-device driver features are taken into account when registering
debugfs files.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_debugfs.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git
From: Yannick Fertré
Sometime the post_disable function is missing (not registered).
Signed-off-by: Yannick Fertré
---
drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
From: Etienne Carriere
Change DSI driver to not print an error trace when probe
is deferred for a clock resource.
Signed-off-by: Etienne Carriere
---
drivers/gpu/drm/stm/dw_mipi_dsi-stm.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git
On Mo, 2020-01-20 at 19:47 +0100, Arnd Bergmann wrote:
> On Mon, Jan 20, 2020 at 6:48 PM Lucas Stach wrote:
> > On Fr, 2020-01-17 at 16:47 +0100, Guido Günther wrote:
> > > This breaks rendering here on arm64/gc7000 due to
> > >
> > > ioctl(6, DRM_IOCTL_ETNAVIV_GEM_CPU_PREP or
Number of endpoints could exceed the fix value MAX_ENDPOINTS(2).
Instead of increase simply this value, the number of endpoint
could be read from device tree. Load sequence has been a little
rework to take care of several panel or bridge which can be
connected/disconnected or enable/disable.
The number of interrupts depends on the ltdc version.
Don't try to get interrupt which not exist, avoiding
kernel warning messages.
Signed-off-by: Yannick Fertre
---
drivers/gpu/drm/stm/ltdc.c | 30 +++---
drivers/gpu/drm/stm/ltdc.h | 1 +
2 files changed, 16
Following investigations of a hardware bug, the LIE interrupt
can occur while the display controller is not activated.
LIE interrupt (vblank) don't have to be set if the CRTC is not
enabled.
Signed-off-by: Yannick Fertre
---
drivers/gpu/drm/stm/ltdc.c | 7 ++-
1 file changed, 6
On 1/20/20 10:09 PM, Dave Airlie wrote:
On Thu, 16 Jan 2020 at 19:30, Thomas Hellström (VMware)
wrote:
Dave, Daniel
The main 5.6 -next pull from vmwgfx. Minor things here and there, as well
as an added ioctl for host messaging and a corresponding api version bump.
Is there userspace for this
Add pixel clock limits to the driver as per TFP410 datasheet: min 25MHz,
max 165MHz.
Signed-off-by: Tomi Valkeinen
Reviewed-by: Andrzej Hajda
Reviewed-by: Laurent Pinchart
---
drivers/gpu/drm/bridge/ti-tfp410.c | 13 +
1 file changed, 13 insertions(+)
diff --git
On 17/01/2020 14:53, Laurent Pinchart wrote:
Hi Tomi,
Thank you for the patch.
On Mon, Jan 13, 2020 at 03:45:28PM +0200, Tomi Valkeinen wrote:
Add pixel clock limits to the driver as per TFP410 datasheet: min 25MHz,
max 165MHz.
Signed-off-by: Tomi Valkeinen
---
On 20/01/2020 23:02, Jyri Sarha wrote:
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. While on higher level the
On Mon, Jan 20, 2020 at 01:20:47PM +0100, Thomas Zimmermann wrote:
> Instead of faking VBLANK events by themselves, drivers without VBLANK
> support can enable drm_crtc_vblank.no_vblank and let DRM do the rest.
> The patchset makes this official and converts over drivers.
>
> The current
On 20/01/2020 23:02, Jyri Sarha wrote:
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
v6: no change
v7: no change
v8: - Add Reviewed-by:
On Tue, Jan 21, 2020 at 10:39:34AM +0200, Jani Nikula wrote:
> On Wed, 15 Jan 2020, Jani Nikula wrote:
> > On Wed, 15 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
On 21.01.2020 09:27, Bogdan Togorean wrote:
> ADV7535 is a part compatible with ADV7533 but it supports 1080p@60hz and
> v1p2 supply is fixed to 1.8V
>
> Signed-off-by: Bogdan Togorean
> Reviewed-by: Laurent Pinchart
Reviewed-by: Andrzej Hajda
--
Regards
Andrzej
On 21.01.2020 09:27, Bogdan Togorean wrote:
> ADV7535 is a DSI to HDMI bridge chip like ADV7533 but it allows
> 1080p@60Hz. v1p2 is fixed to 1.8V on ADV7535.
>
> Signed-off-by: Bogdan Togorean
Reviewed-by: Andrzej Hajda
--
Regards
Andrzej
___
On 21.01.2020 09:27, Bogdan Togorean wrote:
> This commit remove DRM_I2C_ADV7533 resulting a simpler driver and less
> choices in Kconfig.
>
> Signed-off-by: Bogdan Togorean
Reviewed-by: Andrzej Hajda
--
Regards
Andrzej
___
dri-devel mailing list
On Wed, 15 Jan 2020, Jani Nikula wrote:
> On Wed, 15 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
On 15-01-20, 18:07, Maxime Ripard wrote:
> On Wed, Jan 15, 2020 at 06:01:37PM +0530, Vinod Koul wrote:
> > On 10-01-20, 16:11, Stefan Mavrodiev wrote:
> > > Currently the cyclic transfers can be used only with normal DMAs. They
> > > can be used by pcm_dmaengine module, which is required for
Hello,
syzbot found the following crash on:
HEAD commit:2747d5fd Add linux-next specific files for 20200116
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=14c99b59e0
kernel config: https://syzkaller.appspot.com/x/.config?x=22f506e7a3a37fe2
dashboard
On Mon, 2020-01-20 at 14:33 +0800, Zhenyu Wang wrote:
> hmm, I failed to apply this one, could you refresh against gvt-staging branch
>
> on https://github.com/intel/gvt-linux?
Done. I've sent out the rebased (and re-tested) patch.
Julian
___
Hi everyone,
Any feedback here?
At least this one should be pretty straightforward
to merge, so I'm not sure it deserves a 6-month delay.
If anyone can take a look, I'd appreciate it.
Thanks!
Ezequiel
On Mon, 2019-07-22 at 13:08 -0300, Ezequiel Garcia wrote:
> When a mode is set with just a
On Mon, Jan 20, 2020 at 10:07 PM Sam Ravnborg wrote:
>
> Add meta-schema variant of panel-timing and
> reference it from panel-common.yaml.
>
> Signed-off-by: Sam Ravnborg
> ---
>
There some typos:
> diff --git
> a/Documentation/devicetree/bindings/display/panel/panel-timing.yaml
>
On Sat, 2019-12-14 at 13:20 -0300, Ezequiel Garcia wrote:
> It's not entirely obvious why these messages have
> "info" severity. In any case, add a proper driver prefix
> to give the user a bit of context of where they are coming from.
>
> Signed-off-by: Ezequiel Garcia
Gentle ping.
Thanks,
Instead of defining KVMGT per-device state in struct intel_vgpu
directly, add an indirection. This makes the GVT code oblivious of
what state KVMGT needs to keep.
The intention here is to eventually make it possible to build
hypervisor backends for the mediator, without having to touch the
Hello Jani,
On Fri, Dec 20, 2019 at 12:04 PM Rajat Jain wrote:
>
> Certain laptops now come with panels that have integrated privacy
> screens on them. This patch adds support for such panels by adding
> a privacy-screen property to the intel_connector for the panel, that
> the userspace can
On Mon, Jan 20, 2020 at 06:51:17PM +0100, Bartlomiej Zolnierkiewicz wrote:
> I guess that a problem is happening during DRM driver load while fbdev
> driver is loaded? I assume do_unregister_framebuffer() is called inside
> do_remove_conflicting_framebuffers()?
Yes, exactly. More details here:
On 20/01/2020 16:09, Quentin Perret wrote:
> Hey Lukasz,
>
> On Monday 20 Jan 2020 at 14:52:07 (+), Lukasz Luba wrote:
>> On 1/17/20 10:54 AM, Quentin Perret wrote:
>>> Suggested alternative: have two registration functions like so:
>>>
>>> int em_register_dev_pd(struct device *dev,
On 1/20/20 6:27 PM, Dietmar Eggemann wrote:
On 20/01/2020 16:09, Quentin Perret wrote:
Hey Lukasz,
On Monday 20 Jan 2020 at 14:52:07 (+), Lukasz Luba wrote:
On 1/17/20 10:54 AM, Quentin Perret wrote:
Suggested alternative: have two registration functions like so:
int
On Sat, 2019-12-14 at 01:59 -0300, Ezequiel Garcia wrote:
> Currently, the interrupt lines requested by Panfrost
> use unmeaningful names, which adds some obscurity
> to interrupt introspection (i.e. any tool based
> on procfs' interrupts file).
>
> In order to improve this, prefix each requested
https://bugzilla.kernel.org/show_bug.cgi?id=206231
--- Comment #21 from Jacques Belosoukinski (kentos...@whiteninjastudio.com) ---
Yesterday, I compiled and installed the 5.4.13 kernel, but got no improvements.
--
You are receiving this mail because:
You are watching the assignee of the bug.
75 matches
Mail list logo
