Hi Feng,
do you still have the test setup that produced the performance penalty?
If so, could you give a try to the patchset at [1]? I think I've fixed
the remaining issues in earlier versions and I'd like to see if it
actually improves performance.
Best regards
Thomas
[1]
On Sun, 2019-12-29 at 16:22 +, Eric Engestrom wrote:
> On Monday, 2019-12-16 16:51:28 +, Souza, Jose wrote:
> > 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
Hi Boris,
Thank you for the patch.
On Fri, Dec 27, 2019 at 03:41:22PM +0100, Boris Brezillon wrote:
> Stop iterating on the bridge chain when we reach the bridge element.
> That's what other helpers do and should allow bridge implementations
> to execute a pre_enable operation on a sub-chain.
Hi Yannick,
Am Freitag, 20. Dezember 2019, 16:52:47 CET schrieb Yannick FERTRE:
> Hello Heiko,
> I test with success your patch on a board stm32mp1 with a panel raydium
> rm68200.
> I need more time to test with a HDMI bridge like ad7533.
I guess this was too short before the holiday season,
Am Sonntag, 5. Januar 2020, 15:05:26 CET schrieb Heiko Stuebner:
> Am Dienstag, 24. Dezember 2019, 15:38:49 CET schrieb Miquel Raynal:
> > Hello,
> >
> > This series aims at supporting LVDS on PX30.
> >
> > A first couple of patches update the documentation with the new
> > compatible and the
Hi Lucas,
Am Mo., 6. Jan. 2020 um 11:08 Uhr schrieb Lucas Stach :
>
> On Do, 2020-01-02 at 11:02 +0100, Christian Gmeiner wrote:
> > Signed-off-by: Christian Gmeiner
> > ---
> > drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 12
> > 1 file changed, 12 insertions(+)
> >
> > diff --git
On Mo, 2020-01-06 at 11:57 +0100, Christian Gmeiner wrote:
> Hi Lucas
>
> Am Mo., 6. Jan. 2020 um 11:03 Uhr schrieb Lucas Stach
> :
> > On Do, 2020-01-02 at 11:02 +0100, Christian Gmeiner wrote:
> > > They will be used for extended HWDB support. The eco id logic was taken
> > > from galcore
https://bugzilla.kernel.org/show_bug.cgi?id=206017
--- Comment #10 from udo (udo...@xs4all.nl) ---
More like 6 hours or less.
--
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
Hi
Am 23.12.19 um 04:08 schrieb Zhihui Chen:
> without the obj[0] set, we can see the following panic:
>
> [ 29.236764] pstate: 2049 (nzCv daif +PAN -UAO)
> [ 29.241532] pc : drm_gem_vram_offset+0x10/0x28 [drm_vram_helper]
> [ 29.247511] lr : hibmc_plane_atomic_update+0x30/0xe0
A number of cleanups that I wanted to apply for some time. The first
two patches simplify the public interface. The third patch adds support
for struct drm_driver.gem_create_object. All tested by running fbdev,
X11 and Weston on ast HW.
v3:
* drm_gem_vram_create(): test for allocation
The flag 'interruptible', which is passed to various functions,
is always set to be false. Remove it and hard-code the value.
Signed-off-by: Thomas Zimmermann
Suggested-by: Daniel Vetter
Reviewed-by: Daniel Vetter
Acked-by: Sam Ravnborg
---
drivers/gpu/drm/ast/ast_mode.c | 2 +-
Drivers that what to allocate VRAM GEM objects with additional fields
can now do this by implementing struct drm_driver.gem_create_object.
v3:
* separately check allocation failure in if/else branches
before upcast to gbo
v2:
* only cast to gbo within if branch; set gbo
TTM is an implementation detail of the VRAM helpers and therefore
shouldn't be exposed to the callers. There's only one correct value
for the BO device anyway, which is the one stored in the DRM device.
So remove struct ttm_bo_device from the VRAM-helper interface and
use the device's VRAM
The hibmc driver aligns scanlines to 16 bytes. By using the new pitch_align
argument of drm_gem_vram_fill_create_dumb(), convert hibmc over.
v2:
* move changes to VRAM helpers into separate patch
Signed-off-by: Thomas Zimmermann
Reviewed-by: Daniel Vetter
Acked-by: Sam Ravnborg
---
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
Reviewed-by: Daniel Vetter
Acked-by: Sam Ravnborg
---
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
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
Reviewed-by: Daniel Vetter
Acked-by: Sam Ravnborg
---
A number of cleanups that I wanted to apply for some time. The first
two patches simplify the public interface. The third patch adds support
for struct drm_driver.gem_create_object. All tested by running fbdev,
X11 and Weston on ast HW.
v4:
* rebased onto recent drm-tip
v3:
*
The flag 'interruptible', which is passed to various functions,
is always set to be false. Remove it and hard-code the value.
Signed-off-by: Thomas Zimmermann
Suggested-by: Daniel Vetter
Reviewed-by: Daniel Vetter
Acked-by: Sam Ravnborg
---
drivers/gpu/drm/ast/ast_mode.c | 2 +-
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
Reviewed-by: Daniel Vetter
Acked-by: Sam Ravnborg
---
drivers/gpu/drm/hisilicon/hibmc/Makefile | 2 +-
On 06/01/2020 11:03, Boris Brezillon wrote:
> Hi Neil,
>
> On Thu, 19 Dec 2019 11:11:48 +0100
> Neil Armstrong wrote:
>
>> +/**
>> + * drm_atomic_helper_duplicate_bridge_state() - Default duplicate state
>> helper
>> + * @bridge: bridge containing the state to duplicate
>> + *
>> + * Default
Hi Yiwei
On jueves, 19 de diciembre de 2019 19:52:26 (CET) Yiwei Zhang wrote:
> Hi Rohan,
>
> Thanks for pointing out the pids issue! Then the index would be {namespace
> + pid(in that namespace)}. I'll grab a setup and play with the driver to
> see what I can do. I know how to find an Intel or
Am Mittwoch, 11. Dezember 2019, 21:34:17 CET schrieb Johan Jonker:
> From: Nickey Yang
>
> Fix edid reading error when edid's block > 2.
>
> Signed-off-by: Nickey Yang
> Signed-off-by: Johan Jonker
applied to drm-misc-next for 5.6
Thanks
Heiko
On Mo, 2020-01-06 at 12:40 +0100, Christian Gmeiner wrote:
> Hi Lucas
>
> Am Mo., 6. Jan. 2020 um 12:22 Uhr schrieb Lucas Stach
> :
> > On Mo, 2020-01-06 at 11:57 +0100, Christian Gmeiner wrote:
> > > Hi Lucas
> > >
> > > Am Mo., 6. Jan. 2020 um 11:03 Uhr schrieb Lucas Stach
> > > :
> > > > On
https://bugzilla.kernel.org/show_bug.cgi?id=206017
--- Comment #9 from udo (udo...@xs4all.nl) ---
5.4.8 runs less than 12 hours until hard crash when used.
--
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel
On Mon, Jan 06, 2020 at 11:03:54AM +0100, Boris Brezillon wrote:
> On Thu, 19 Dec 2019 11:11:48 +0100 Neil Armstrong wrote:
>
> > +/**
> > + * drm_atomic_helper_duplicate_bridge_state() - Default duplicate state
> > helper
> > + * @bridge: bridge containing the state to duplicate
> > + *
> > + *
Am Dienstag, 24. Dezember 2019, 15:39:00 CET schrieb Miquel Raynal:
> Describe LVDS IP. Add the CRTC and LVDS relevant endpoints so they can
> be linked together.
>
> Signed-off-by: Miquel Raynal
> +
> + vopb_out_lvds: endpoint@0 {
> + reg = <0>;
Report the correct perfmon domains and signals depending
on the supported feature flags.
Reported-by: Dan Carpenter
Fixes: 9e2c2e273012 ("drm/etnaviv: add infrastructure to query perf counter")
Cc: sta...@vger.kernel.org
Signed-off-by: Christian Gmeiner
---
Hi Lucas
Am Mo., 6. Jan. 2020 um 11:15 Uhr schrieb Lucas Stach :
>
> On Do, 2020-01-02 at 11:02 +0100, Christian Gmeiner wrote:
> > Take product id, customer id and eco id into account. If that
> > delivers no match try a search for model and revision.
> >
> > Signed-off-by: Christian Gmeiner
>
Hi Lucas
Am Mo., 6. Jan. 2020 um 11:03 Uhr schrieb Lucas Stach :
>
> On Do, 2020-01-02 at 11:02 +0100, Christian Gmeiner wrote:
> > They will be used for extended HWDB support. The eco id logic was taken
> > from galcore kernel driver sources.
> >
> > Signed-off-by: Christian Gmeiner
> > ---
> >
Hi Lucas
Am Mo., 6. Jan. 2020 um 12:22 Uhr schrieb Lucas Stach :
>
> On Mo, 2020-01-06 at 11:57 +0100, Christian Gmeiner wrote:
> > Hi Lucas
> >
> > Am Mo., 6. Jan. 2020 um 11:03 Uhr schrieb Lucas Stach
> > :
> > > On Do, 2020-01-02 at 11:02 +0100, Christian Gmeiner wrote:
> > > > They will be
Adding the pitch alignment as an argument to drm_gem_vram_fill_create_dumb()
allows to align scanlines to certain offsets. A value of 0 disables scanline
pitches.
v3:
* only do power-of-2 test if pitch_align given; fails otherwise
* mgag200: call drm_gem_vram_fill_create_dumb()
TTM is an implementation detail of the VRAM helpers and therefore
shouldn't be exposed to the callers. There's only one correct value
for the BO device anyway, which is the one stored in the DRM device.
So remove struct ttm_bo_device from the VRAM-helper interface and
use the device's VRAM
Drivers that what to allocate VRAM GEM objects with additional fields
can now do this by implementing struct drm_driver.gem_create_object.
v3:
* separately check allocation failure in if/else branches
before upcast to gbo
v2:
* only cast to gbo within if branch; set gbo
Hi
Am 31.12.19 um 07:50 schrieb Tian Tao:
> since we can get the BO from drm_fb rather than hibmc_fb,do not need
> the hibmc_fb.so we delete the local variable hibmc_fb.
>
> Signed-off-by: Tian Tao
> Signed-off-by: Gong junjie
> ---
> drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c | 4 +---
>
On Sat 28-12-19 20:33:32, John Hubbard wrote:
> On 12/27/19 1:56 PM, John Hubbard wrote:
> ...
> >> It is ancient verification test (~10y) which is not an easy task to
> >> make it understandable and standalone :).
> >>
> >
> > Is this the only test that fails, btw? No other test failures or
Hi Neil,
On Thu, 19 Dec 2019 11:11:48 +0100
Neil Armstrong wrote:
> +/**
> + * drm_atomic_helper_duplicate_bridge_state() - Default duplicate state
> helper
> + * @bridge: bridge containing the state to duplicate
> + *
> + * Default implementation of _bridge_funcs.atomic_duplicate().
> + *
> +
On Do, 2020-01-02 at 11:02 +0100, Christian Gmeiner wrote:
> They will be used for extended HWDB support. The eco id logic was taken
> from galcore kernel driver sources.
>
> Signed-off-by: Christian Gmeiner
> ---
> drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 17 +
>
On 04-01-2020 05:18, Manasi Navare wrote:
On Thu, Jan 02, 2020 at 03:56:09PM +0530, Manna, Animesh wrote:
On 02-01-2020 14:48, Jani Nikula wrote:
On Mon, 30 Dec 2019, Animesh Manna wrote:
vswing/pre-emphasis adjustment calculation is needed in processing
of auto phy compliance request other
Hi
Am 06.01.20 um 11:11 schrieb Thomas Zimmermann:
> Hi Kevin
>
> Am 16.12.19 um 12:40 schrieb Kevin Tang:
>> From: Kevin Tang
>>
>> Adds drm support for the Unisoc's display subsystem.
>>
>> This is drm device and gem driver. This driver provides support for the
>> Direct Rendering
Hi Krzysztof,
20. 1. 5. 오전 12:21에 Krzysztof Kozlowski 이(가) 쓴 글:
> Fix up inconsistent usage of upper and lowercase letters in "Exynos"
> name.
>
> "EXYNOS" is not an abbreviation but a regular trademarked name.
> Therefore it should be written with lowercase letters starting with
> capital
[AMD Public Use]
> -原始郵件-
> 寄件者: Lyude Paul
> 寄件日期: Saturday, January 4, 2020 7:34 AM
> 收件者: Lin, Wayne ; dri-
> de...@lists.freedesktop.org; amd-...@lists.freedesktop.org
> 副本: Kazlauskas, Nicholas ; Wentland,
> Harry ; Zuo, Jerry ;
> sta...@vger.kernel.org
> 主旨: Re: [PATCH]
On Sun, 05 Jan 2020, Pavel Machek wrote:
> Hi!
>
> It would be good to get LED backlight to work in clean way for 5.6
> kernel.
>
> As far as I can see, these are neccessary (but not enough; it does not
> work for me): lm3532 changes to register LED with of node, plus device
> tree changes for
Hi Sam,
On Sun, Jan 5, 2020 at 10:13 AM Sam Ravnborg wrote:
> Good to see we add more functionality to the smallest driver in DRM.
> The patch triggered a few comments - see below.
> Some comments relates to the original driver - and not your changes.
Thanks for your comments!
> On Thu, Jan
On Do, 2020-01-02 at 11:02 +0100, Christian Gmeiner wrote:
> Take product id, customer id and eco id into account. If that
> delivers no match try a search for model and revision.
>
> Signed-off-by: Christian Gmeiner
> ---
> drivers/gpu/drm/etnaviv/etnaviv_hwdb.c | 19 ++-
> 1
Hi
Am 13.12.19 um 11:27 schrieb Daniel Vetter:
> On Thu, Dec 12, 2019 at 08:41:17AM +0100, Thomas Zimmermann wrote:
>> Drivers that what to allocate VRAM GEM objects with additional fields
>> can now do this by implementing struct drm_driver.gem_create_object.
>>
>> v2:
>> * only cast to gbo
This allocation isn't required and can fail when resuming from suspend.
Bug: https://gitlab.freedesktop.org/drm/amd/issues/1009
Signed-off-by: Dor Askayo
---
drivers/gpu/drm/amd/display/dc/core/dc.c | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git
Hi,
* Tony Lindgren [200104 05:51]:
>
> Just changing the alingment fixes the issue. Looks like the minimum
> alignment we currently allow is 128, I think 512 was the minimum
> that worked for me, so maybe the right fix would be to just change
> the minimum to 512 with no specific need to use
Modify commit text to indicate DSI version and SOC detail
Changes in v1:
-Modify commit text to indicate DSI version and SOC detail(Jeffrey
Hugo).
-Splitting visionox panel driver code out into a
different patch(set), since panel drivers are merged into
drm-next
From: kbuild test robot
Remove dev_err() messages after platform_get_irq*() failures.
Line 450 is redundant because platform_get_irq() already prints
an error.
Generated by: scripts/coccinelle/api/platform_get_irq.cocci
Fixes: dd90e9ae55a1 ("video: fbdev: mmp: add COMPILE_TEST support")
* Pavel Machek [200105 18:32]:
> Hi!
>
> It would be good to get LED backlight to work in clean way for 5.6
> kernel.
I agree, this is badly needed for many devices.
> [If you have an idea what else is needed, it would be welcome; it
> works for me in development tree but not in tree I'd like
Hi Kevin
Am 16.12.19 um 12:40 schrieb Kevin Tang:
> From: Kevin Tang
>
> Adds drm support for the Unisoc's display subsystem.
>
> This is drm device and gem driver. This driver provides support for the
> Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
>
> Cc: Orson Zhai
>
Hi Sam,
On Sat, Jan 4, 2020 at 8:47 PM Sam Ravnborg wrote:
>
> Hi Jagan.
> On Wed, Jan 01, 2020 at 04:54:38PM +0530, Jagan Teki wrote:
> > These panel bindings are owned by me, so updated all of them into
> > YAML DT schema.
> >
> > Any inputs?
> Thanks for doing the conversion.
>
>
Hi
Am 28.12.19 um 01:59 schrieb Tian Tao:
> In the previous version, the callback function mode_valid of
> drm_connector_helper_funcs directly returned MODE_OK. Now we will
> ensure that the resolution is correct and return MODE_OK, otherwise
> return MODE_NOMODE.
>
> Signed-off-by: Tian Tao
>
[AMD Public Use]
> -Original Message-
> From: Lyude Paul
> Sent: Saturday, January 4, 2020 6:02 AM
> To: Lin, Wayne ; dri-devel@lists.freedesktop.org;
> amd-...@lists.freedesktop.org
> Cc: Kazlauskas, Nicholas ; Wentland, Harry
> ; Zuo, Jerry ;
> sta...@vger.kernel.org
> Subject: Re:
On Do, 2020-01-02 at 11:02 +0100, Christian Gmeiner wrote:
> Signed-off-by: Christian Gmeiner
> ---
> drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
>
[Why]
When change the connection status in a MST topology, mst device
which detect the event will send out CONNECTION_STATUS_NOTIFY messgae.
e.g. src-mst-mst-sst => src-mst (unplug) mst-sst
Currently, under the above case of unplugging device, ports which have
been allocated payloads and are no
From: Boris Brezillon
drm_bridge_state is extended to describe the input and output bus
configurations. These bus configurations are exposed through the
drm_bus_cfg struct which encodes the configuration of a physical
bus between two components in an output pipeline, usually between
two bridges,
From: Boris Brezillon
One of the last remaining objects to not have its atomic state.
This is being motivated by our attempt to support runtime bus-format
negotiation between elements of the bridge chain.
This patch just paves the road for such a feature by adding a new
drm_bridge_state object
From: Boris Brezillon
This way the drm_bridge_funcs interface is consistent with the rest of
the subsystem.
The only driver implementing those hooks (analogix DP) is patched too.
Signed-off-by: Boris Brezillon
Reviewed-by: Laurent Pinchart
Signed-off-by: Neil Armstrong
---
Changes in v6:
*
From: Boris Brezillon
So that bridge drivers have a way to check/reject an atomic operation.
The drm_atomic_bridge_chain_check() (which is just a wrapper around
the ->atomic_check() hook) is called in place of
drm_bridge_chain_mode_fixup() (when ->atomic_check() is not implemented,
the core
This patch series aims at adding support for runtime bus-format
negotiation between all elements of the
'encoder -> bridges -> connector/display' section of the pipeline.
In order to support that, we need drm bridges to fully take part in the
atomic state validation process, which requires adding
The udl driver for DisplayLink devices depends on support for host-side
USB controllers, which is enabled with CONFIG_USB. Plain USB support as
given by CONFIG_USB_SUPPORT not sufficient.
This patch changes dependencies for udl to depend on CONFIG_USB, instead
of CONFIG_USB_SUPPORT. Users will
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
This variable is used nowhere, so remove it.
Cc: Zhenyu Wang
Cc: zhiyuan...@intel.com
Cc: hang.y...@intel.com
Signed-off-by: Julian Stecklina
---
drivers/gpu/drm/i915/gvt/gvt.h | 2 --
drivers/gpu/drm/i915/gvt/kvmgt.c | 2 --
2 files changed, 4 deletions(-)
diff --git
The documentation had some stale paths to i915 graphics virtualization
code. Fix them to point to existing files.
Cc: Zhenyu Wang
Cc: zhiyuan...@intel.com
Cc: hang.y...@intel.com
Signed-off-by: Julian Stecklina
---
Documentation/gpu/i915.rst | 8
1 file changed, 4 insertions(+), 4
On Mon, 6 Jan 2020 15:34:05 +0100
Neil Armstrong wrote:
> This patch series aims at adding support for runtime bus-format
> negotiation between all elements of the
> 'encoder -> bridges -> connector/display' section of the pipeline.
>
> In order to support that, we need drm bridges to fully
On 01/01/2020 15:52, Laurent Pinchart wrote:
> Hi Julia,
>
> Thank you for the patch.
>
> On Wed, Jan 01, 2020 at 08:43:33AM +0100, Julia Lawall wrote:
>> The dw_hdmi_hw structure is only copied into another structure,
>> so make it const.
>>
>> The opportunity for this change was found using
On Mon, 6 Jan 2020 15:34:07 +0100
Neil Armstrong wrote:
> diff --git a/drivers/gpu/drm/rcar-du/rcar_lvds.c
> b/drivers/gpu/drm/rcar-du/rcar_lvds.c
> index 8ffa4fbbdeb3..b8b22dc55bdb 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_lvds.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_lvds.c
> @@ -590,8
Hi Laurent,
On 19/12/2019 11:44, Laurent Pinchart wrote:
> Hello,
>
> This patch series is the fourth attempt to (nearly, see [1]) complete the
> rework of the omapdrm driver to move to drm_bridge and drm_panel.
>
> Versions, available at [2], explains in its long cover letter the
> rationale
On 06/01/2020 15:40, Boris Brezillon wrote:
> On Mon, 6 Jan 2020 15:34:07 +0100
> Neil Armstrong wrote:
>
>> diff --git a/drivers/gpu/drm/rcar-du/rcar_lvds.c
>> b/drivers/gpu/drm/rcar-du/rcar_lvds.c
>> index 8ffa4fbbdeb3..b8b22dc55bdb 100644
>> --- a/drivers/gpu/drm/rcar-du/rcar_lvds.c
>> +++
On 16/12/2019 04:58, zhengbin wrote:
> Fixes coccicheck warning:
>
> drivers/gpu/drm/meson/meson_crtc.c:360:3-4: Unneeded semicolon
> drivers/gpu/drm/meson/meson_plane.c:181:2-3: Unneeded semicolon
>
> Reported-by: Hulk Robot
> Signed-off-by: zhengbin
> ---
>
Hi,
On 30/12/2019 10:04, Enric Balletbo i Serra wrote:
> Hi all,
>
> This is another version of the driver. Note that the driver changed
> significally and is a more simply because now is using the panel_bridge
> helpers. Apart from this, I addressed the comments from Maxime, Laurent
> and
On Mon, Jan 6, 2020 at 9:10 AM Thomas Zimmermann wrote:
>
> The udl driver for DisplayLink devices depends on support for host-side
> USB controllers, which is enabled with CONFIG_USB. Plain USB support as
> given by CONFIG_USB_SUPPORT not sufficient.
>
> This patch changes dependencies for udl
Hi Sam,
> For future patches can you please incldue a small changelog
> within each patch.
>
> Something like
>
> v2:
> - Drop redundant newlines (Lucas)
>
> This serves several purposes:
> - It explains what was changed since last version
> - It allow the reader to focus on changed parts
> -
Device 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 dev_WARN*
variants in functions where any one of intel_pm, intel_encoder,
i915_perf_stream or intel_crtc_state struct
It's quite useful to print the device name on the stack dump caused
by WARN_ON*.
Introduce dev_WARN_ON and dev_WARN_ON_ONCE macros for the same.
Signed-off-by: Pankaj Bharadiya
---
drivers/gpu/drm/i915/i915_utils.h | 8
1 file changed, 8 insertions(+)
diff --git
Device 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 dev_WARN*
variants in functions where first function argument is a
struct pointer and has drm_i915_private struct pointer
dev_WARN does not support conditional warning unlike WARN.
Add condition support to dev_WARN (file: include/linux/device.h)
to make it work like WARN and modify all existing callers to use it.
This is quite useful where we want to replace existing WARN with
dev_WARN.
Following cocci script is
We will need struct device pointer to pass it to dev_WARN* calls.
Add helper functions to exract 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.
Knowing the device specific information in the backtrace would be
helpful in development all around.
This patch series aims to
Device 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 dev_WARN*
variants in functions where drm_device struct pointer is readily
available.
The conversion was done
Hi Heiko.
On Mon, Jan 06, 2020 at 07:37:53PM +0100, Heiko Stuebner wrote:
> Am Montag, 6. Januar 2020, 19:17:31 CET schrieb Sam Ravnborg:
> > The reg property in the example caused following warnings:
> >
> > xinpeng,xpp055c272.example.dts:20.17-27: Warning (reg_format):
> >
On 26/12/2019 13:12, yu kuai wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/gpu/drm/bridge/cdns-dsi.c: In function
> ‘cdns_dsi_bridge_enable’:
> drivers/gpu/drm/bridge/cdns-dsi.c:788:6: warning: variable ‘bpp’
> set but not used [-Wunused-but-set-variable]
>
> It is never
Hi Claudiu.
On Mon, Jan 06, 2020 at 09:25:40AM +, claudiu.bez...@microchip.com wrote:
>
>
> On 04.01.2020 19:12, Sam Ravnborg wrote:
> > EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> > content is safe
> >
> > Hi Claudiu
> >
> > On Thu, Jan 02, 2020 at
On 1/2/20 8:46 AM, Sam Ravnborg wrote:
Hi Geert.
On Thu, Jan 02, 2020 at 03:12:44PM +0100, Geert Uytterhoeven wrote:
Document support for the Okaya RH128128T display, which is a 128x128
1.44" TFT display driven by a Sitronix ST7715R TFT Controller/Driver.
ST7715R and ST7735R are very similar.
>
> Claudiu Beznea (5):
> drm: atmel-hlcdc: use double rate for pixel clock only if supported
> drm: atmel-hlcdc: enable clock before configuring timing engine
> mfd: atmel-hlcdc: add struct device member to struct
> atmel_hlcdc_regmap
> mfd: atmel-hlcdc: return in case of error
>
On 26/12/2019 13:14, yu kuai wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/gpu/drm/bridge/cdns-dsi.c: In function ‘cdns_dsi_mode2cfg’:
> drivers/gpu/drm/bridge/cdns-dsi.c:515:11: warning: variable ‘nlanes’
> set but not used [-Wunused-but-set-variable]
>
> It is never used,
On Sun, Jan 05, 2020 at 04:51:20PM +0100, Hans de Goede wrote:
> If the new video=... panel_orientation option is set for a connector, honor
> it and setup a matching "panel orientation" property on the connector.
>
> Changes in v2:
> -Improve DRM_INFO message to make it clear that the
Hi Geert.
> Thanks for your comments!
>
> > On Thu, Jan 02, 2020 at 03:12:46PM +0100, Geert Uytterhoeven wrote:
> > > Add support for the Okaya RH128128T display to the st7735r driver.
> > >
> > > The RH128128T is a 128x128 1.44" TFT display driven by a Sitronix
> > > ST7715R TFT
The reg property in the example caused following warnings:
xinpeng,xpp055c272.example.dts:20.17-27: Warning (reg_format):
/example-0/dsi@ff45/panel@0:reg: property has invalid length (4 bytes)
(#address-cells == 2, #size-cells == 1)
xinpeng,xpp055c272.example.dt.yaml: Warning
Hi Christian
On Mon, Jan 06, 2020 at 04:16:45PM +0100, Christian Gmeiner wrote:
> This patch series extends the hwdb for an entry for the gc400 found
> in the ST STM32 SoC. With this patches we report the same limits and
> features for this GPU as the galcore kernel driver does.
For future
On 1/5/20 5:25 PM, Ben Skeggs wrote:
On Tue, 17 Dec 2019 at 10:45, James Jones wrote:
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
---
Hi Christian.
> To be honest.. I forgot the change log thing this time - sorry.
It was small changes - so no worries.
> So the rule
> is to have the change log in the normal commit message?
This is what Danial Vetter tell people - but it is not documented as
far as I can tell.
> Funny - Lucas
On 1/5/20 5:30 PM, Ben Skeggs wrote:
On Tue, 17 Dec 2019 at 10:44, James Jones wrote:
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
This patch series extends the hwdb for an entry for the gc400 found
in the ST STM32 SoC. With this patches we report the same limits and
features for this GPU as the galcore kernel driver does.
Christian Gmeiner (6):
drm/etnaviv: update hardware headers from rnndb
drm/etnaviv: determine
Update the state HI header from rnndb commit
7f1ce75 ("rnndb: document some GPU identity register")
Signed-off-by: Christian Gmeiner
---
drivers/gpu/drm/etnaviv/state_hi.xml.h | 29 --
1 file changed, 18 insertions(+), 11 deletions(-)
diff --git
Use ~0U as marker for 'I do not care'. I am not sure what
GC7000 based devices are in the wild and I do not want to
break them. In the near future we should extend the hwdb.
Signed-off-by: Christian Gmeiner
---
drivers/gpu/drm/etnaviv/etnaviv_hwdb.c | 3 +++
1 file changed, 3 insertions(+)
The information was taken from STM32 glacore driver hw database.
The entry is named as gc7000nano_0x4652.
Signed-off-by: Christian Gmeiner
---
drivers/gpu/drm/etnaviv/etnaviv_hwdb.c | 31 ++
1 file changed, 31 insertions(+)
diff --git
They will be used for extended HWDB support.
Signed-off-by: Christian Gmeiner
---
drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 11 ++-
drivers/gpu/drm/etnaviv/etnaviv_gpu.h | 6 +++---
2 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
Signed-off-by: Christian Gmeiner
---
drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
index 7ee67e12141d..151033d58bfb 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
1 - 100 of 140 matches
Mail list logo
