Re: [PATCH AUTOSEL 5.4 002/205] drm/panfrost: Add missing check for pfdev->regulator
On Fri, Jan 17, 2020 at 05:59:09PM +0100, Greg KH wrote:
> On Fri, Jan 17, 2020 at 04:12:27PM +, Steven Price wrote:
> > On Thu, Jan 16, 2020 at 04:39:37PM +, Sasha Levin wrote:
> > > From: Steven Price
> > >
> > > [ Upstream commit 52282163dfa651849e905886845bcf6850dd83c2 ]
> >
> > This commit is effectively already in 5.4. Confusingly there were two
> > versions of this upstream:
> >
> > 52282163dfa6 ("drm/panfrost: Add missing check for pfdev->regulator")
> > c90f30812a79 ("drm/panfrost: Add missing check for pfdev->regulator")
> >
> > It got merged both through a -fixes branch and through the normal merge
> > window. The two copies caused a bad merge in mainline and this was
> > effectively reverted in commit 603e398a3db2 ("drm/panfrost: Remove NULL
> > check for regulator").
> >
> > c90f30812a79 is included in v5.4 so should already be in any v5.4.y
> > release.
>
> Have I mentioned this month just how much I hate the way the DRM tree
> handles stable patches like this? This kind of fallout is a pain for
> stable maintainers, I dred every time I see a drm patch tagged for
> stable.
>
> But we've been over this all before :(
Another example is:
29cd13cfd762 ("drm/v3d: Fix memory leak in v3d_submit_cl_ioctl")
0d352a3a8a1f ("drm/v3d: don't leak bin job if v3d_job_init fails.")
Two fixes for a memory leak were merged so now it's a double free. I
sent a patch on Jan 10 but no one responded.
regards,
dan carpenter
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 206225] nouveau: Screen distortion and lockup on resume
https://bugzilla.kernel.org/show_bug.cgi?id=206225 --- Comment #5 from Christoph Marz (derchiller-fo...@online.de) --- Created attachment 286875 --> https://bugzilla.kernel.org/attachment.cgi?id=286875&action=edit 5.4.11: Syslog excerpt: Resume after hibernation: No error -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3] drm/dp_mst: Fix W=1 warnings
Le sam. 18 janv. 2020 à 01:55, Lyude Paul a écrit :
>
> Hey, does this still need review?
yes please.
There is a question about what we should do of crc4 variable below.
Thanks,
Benjamin
>
> On Tue, 2020-01-07 at 14:11 +0100, Benjamin Gaignard wrote:
> > Le ven. 20 déc. 2019 à 15:03, Benjamin Gaignard
> > a écrit :
> > > Le lun. 16 déc. 2019 à 09:28, Benjamin Gaignard
> > > a écrit :
> > > > Le mer. 4 déc. 2019 à 17:47, Jani Nikula a
> > > > écrit :
> > > > > On Thu, 28 Nov 2019, Benjamin Gaignard
> > > > > wrote:
> > > > > > Fix the warnings that show up with W=1.
> > > > > > They are all about unused but set variables.
> > > > > > If functions returns are not used anymore make them void.
> > > > > >
> > > > > > Signed-off-by: Benjamin Gaignard
> > > > > > ---
> > > > > > CC: Jani Nikula
> > > > > >
> > > > > > changes in version 3:
> > > > > > - remove the hunk that may conflict with c485e2c97dae
> > > > > > ("drm/dp_mst: Refactor pdt setup/teardown, add more locking")
> > > > > >
> > > > > > changes in version 2:
> > > > > > - fix indentations
> > > > > > - when possible change functions prototype to void
> > > > > >
> > > > > > drivers/gpu/drm/drm_dp_mst_topology.c | 83 +--
> > > > > >
> > > > > > 1 file changed, 31 insertions(+), 52 deletions(-)
> > > > > >
> > > > > > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> > > > > > b/drivers/gpu/drm/drm_dp_mst_topology.c
> > > > > > index 1437bc46368b..d5cb5688b5dd 100644
> > > > > > --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> > > > > > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> > > > > > @@ -674,7 +674,6 @@ static bool drm_dp_sideband_msg_build(struct
> > > > > > drm_dp_sideband_msg_rx *msg,
> > > > > > u8 *replybuf, u8 replybuflen,
> > > > > > bool hdr)
> > > > > > {
> > > > > > int ret;
> > > > > > - u8 crc4;
> > > > > >
> > > > > > if (hdr) {
> > > > > > u8 hdrlen;
> > > > > > @@ -716,8 +715,6 @@ static bool drm_dp_sideband_msg_build(struct
> > > > > > drm_dp_sideband_msg_rx *msg,
> > > > > > }
> > > > > >
> > > > > > if (msg->curchunk_idx >= msg->curchunk_len) {
> > > > > > - /* do CRC */
> > > > > > - crc4 = drm_dp_msg_data_crc4(msg->chunk, msg-
> > > > > > >curchunk_len - 1);
> > > > >
> > > > > Again, someone needs to check if crc4 should be *used* instead of
> > > > > thrown
> > > > > away. Blindly throwing stuff out is not the way to go.
> > > >
> > > > Hi Dave,
> > > >
> > >
> > > + Lyude who has been hacking in this code recently
> >
> > gentle ping for the reviewers,
> >
> > Thanks,
> > Benjamin
> > > > Your are the original writer of this code, could you tell us if we can
> > > > drop crc4
> > > > ao if there is something else that I have misunderstood ?
> > > >
> > > > Thanks,
> > > > Benjamin
> > > >
> > > > > BR,
> > > > > Jani.
> > > > >
> > > > > > /* copy chunk into bigger msg */
> > > > > > memcpy(&msg->msg[msg->curlen], msg->chunk, msg-
> > > > > > >curchunk_len - 1);
> > > > > > msg->curlen += msg->curchunk_len - 1;
> > > > > > @@ -1014,7 +1011,7 @@ static bool drm_dp_sideband_parse_req(struct
> > > > > > drm_dp_sideband_msg_rx *raw,
> > > > > > }
> > > > > > }
> > > > > >
> > > > > > -static int build_dpcd_write(struct drm_dp_sideband_msg_tx *msg, u8
> > > > > > port_num, u32 offset, u8 num_bytes, u8 *bytes)
> > > > > > +static void build_dpcd_write(struct drm_dp_sideband_msg_tx *msg, u8
> > > > > > port_num, u32 offset, u8 num_bytes, u8 *bytes)
> > > > > > {
> > > > > > struct drm_dp_sideband_msg_req_body req;
> > > > > >
> > > > > > @@ -1024,17 +1021,14 @@ static int build_dpcd_write(struct
> > > > > > drm_dp_sideband_msg_tx *msg, u8 port_num, u32
> > > > > > req.u.dpcd_write.num_bytes = num_bytes;
> > > > > > req.u.dpcd_write.bytes = bytes;
> > > > > > drm_dp_encode_sideband_req(&req, msg);
> > > > > > -
> > > > > > - return 0;
> > > > > > }
> > > > > >
> > > > > > -static int build_link_address(struct drm_dp_sideband_msg_tx *msg)
> > > > > > +static void build_link_address(struct drm_dp_sideband_msg_tx *msg)
> > > > > > {
> > > > > > struct drm_dp_sideband_msg_req_body req;
> > > > > >
> > > > > > req.req_type = DP_LINK_ADDRESS;
> > > > > > drm_dp_encode_sideband_req(&req, msg);
> > > > > > - return 0;
> > > > > > }
> > > > > >
> > > > > > static int build_enum_path_resources(struct drm_dp_sideband_msg_tx
> > > > > > *msg, int port_num)
> > > > > > @@ -1048,7 +1042,7 @@ static int build_enum_path_resources(struct
> > > > > > drm_dp_sideband_msg_tx *msg, int por
> > > > > > return 0;
> > > > > > }
> > > > > >
> > > > > > -static int build_allocate_payload(struct drm_dp_sideband_msg_tx
> > > > > > *msg, int port_num,
> > > > > > +static void build_allocate_payload(struct drm_dp_sideband_msg_tx
> > > > > > *msg, int port_num,
> > > > > >
Re: [PATCH v2] dt-bindings: display: Convert a bunch of panels to DT schema
Hi Rob. On Fri, Jan 17, 2020 at 05:17:56PM -0600, Rob Herring wrote: > Convert all the 'simple' panels which match the constraints of the > common panel-simple.yaml schema. This conversion is based on how the > panels are documented. Some may turn out to be more complex once the > schema is applied to actual dts files. Thanks for updating this patch - and very good to reduce the number of files with almost the same content. One comment below, with that addressed: Reviewed-by: Sam Ravnborg There are likely some dt files that assume panels need no power and need a fixed-regulator or something as power-supply now is mandatory. Should this be checked before we apply this patch? As we continue to see new panels more or less every week I would like this patch applied to drm-misc-next as soon as possible to avoid any future conflicts. > index 513f03466aba.. > --- a/Documentation/devicetree/bindings/display/panel/innolux,p120zdg-bf1.txt > +++ /dev/null > @@ -1,22 +0,0 @@ > -Innolux P120ZDG-BF1 12.02 inch eDP 2K display panel > - > -This binding is compatible with the simple-panel binding, which is specified > -in simple-panel.txt in this directory. > - > -Required properties: > -- compatible: should be "innolux,p120zdg-bf1" > -- power-supply: regulator to provide the supply voltage > - > -Optional properties: > -- enable-gpios: GPIO pin to enable or disable the panel > -- backlight: phandle of the backlight device attached to the panel > -- no-hpd: If HPD isn't hooked up; add this property. panel-simple.yaml does not include the no-hpd property. We only have 2 bindings, this and sharp,ld-d5116z01b.yaml that include the no-hpd property. We have two options: 1) add the no-hpd property to panel-simple.yaml 2) keep an independent binding for panels using no-hpd I suggest to keep an independent binding for innolux,p120zdg-bf1 so we keep panel-simple.yaml slim. In other words do not delete this file and remove the compatible from panel-simple.yaml Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 206231] R9 280X low performance with all games
https://bugzilla.kernel.org/show_bug.cgi?id=206231 --- Comment #12 from Jacques Belosoukinski (kentos...@whiteninjastudio.com) --- The framerate with CS GO is not good with graphics on "high". I tried the Dust II map and I get a maximum of 90 fps in some places, a minimum of ~ 50 fps looking towards "middle" where the main door is. It seems very weak to me. For Dota 2 with Vulkan, the game runs at more than 100 fps in some places, but with a some elements on the screen, it's more around ~ 60fps. I noticed that as with other games, GPU usage is always low when there is a need for performance. Screenshtos: https://i.ibb.co/BTknwjH/csgo.jpg https://i.ibb.co/c35Rxmg/dota2.jpg -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm: fix parameters documentation style
Hi Benjamin On Tue, Jan 14, 2020 at 05:01:35PM +0100, Benjamin Gaignard wrote: > Remove old documentation style and use new one to avoid warnings when > compiling with W=1 > > Signed-off-by: Benjamin Gaignard Thanks for the warning fixes. This is legacy stuff that is not even wired into the kernel-doc stuff. But that is no excuse for old-style comments. Applied to drm-misc-next. Sam > --- > CC: Randy Dunlap > version 2: > - fix return documentation > > drivers/gpu/drm/drm_dma.c | 21 +++-- > 1 file changed, 11 insertions(+), 10 deletions(-) > > diff --git a/drivers/gpu/drm/drm_dma.c b/drivers/gpu/drm/drm_dma.c > index e45b07890c5a..a7add55a85b4 100644 > --- a/drivers/gpu/drm/drm_dma.c > +++ b/drivers/gpu/drm/drm_dma.c > @@ -42,10 +42,10 @@ > #include "drm_legacy.h" > > /** > - * Initialize the DMA data. > + * drm_legacy_dma_setup() - Initialize the DMA data. > * > - * \param dev DRM device. > - * \return zero on success or a negative value on failure. > + * @dev: DRM device. > + * Return: zero on success or a negative value on failure. > * > * Allocate and initialize a drm_device_dma structure. > */ > @@ -71,9 +71,9 @@ int drm_legacy_dma_setup(struct drm_device *dev) > } > > /** > - * Cleanup the DMA resources. > + * drm_legacy_dma_takedown() - Cleanup the DMA resources. > * > - * \param dev DRM device. > + * @dev: DRM device. > * > * Free all pages associated with DMA buffers, the buffers and pages lists, > and > * finally the drm_device::dma structure itself. > @@ -120,10 +120,10 @@ void drm_legacy_dma_takedown(struct drm_device *dev) > } > > /** > - * Free a buffer. > + * drm_legacy_free_buffer() - Free a buffer. > * > - * \param dev DRM device. > - * \param buf buffer to free. > + * @dev: DRM device. > + * @buf: buffer to free. > * > * Resets the fields of \p buf. > */ > @@ -139,9 +139,10 @@ void drm_legacy_free_buffer(struct drm_device *dev, > struct drm_buf * buf) > } > > /** > - * Reclaim the buffers. > + * drm_legacy_reclaim_buffers() - Reclaim the buffers. > * > - * \param file_priv DRM file private. > + * @dev: DRM device. > + * @file_priv: DRM file private. > * > * Frees each buffer associated with \p file_priv not already on the > hardware. > */ > -- > 2.15.0 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH -next] drm/drm_dp_mst:remove set but not used variable 'origlen'
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/drm_dp_mst_topology.c:3693:16: warning: variable
‘origlen’ set but not used [-Wunused-but-set-variable]
int replylen, origlen, curreply;
It looks like never use variable origlen after assign value to it.
Fixes: ad7f8a1f9ced7 (drm/helper: add Displayport multi-stream helper (v0.6))
Signed-off-by: Bo YU
---
drivers/gpu/drm/drm_dp_mst_topology.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 4b74193b89ce..4c76e673206b 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -3690,7 +3690,7 @@ static bool drm_dp_get_one_sb_msg(struct
drm_dp_mst_topology_mgr *mgr, bool up)
{
int len;
u8 replyblock[32];
- int replylen, origlen, curreply;
+ int replylen, curreply;
int ret;
struct drm_dp_sideband_msg_rx *msg;
int basereg = up ? DP_SIDEBAND_MSG_UP_REQ_BASE :
DP_SIDEBAND_MSG_DOWN_REP_BASE;
@@ -3710,7 +3710,6 @@ static bool drm_dp_get_one_sb_msg(struct
drm_dp_mst_topology_mgr *mgr, bool up)
}
replylen = msg->curchunk_len + msg->curchunk_hdrlen;
- origlen = replylen;
replylen -= len;
curreply = len;
while (replylen > 0) {
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amd/display: do not allocate display_mode_lib unnecessarily
On Sat, Jan 4, 2020 at 2:23 PM Dor Askayo wrote:
>
> 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 a/drivers/gpu/drm/amd/display/dc/core/dc.c
> b/drivers/gpu/drm/amd/display/dc/core/dc.c
> index dd4731ab935c..83ebb716166b 100644
> --- a/drivers/gpu/drm/amd/display/dc/core/dc.c
> +++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
> @@ -2179,12 +2179,7 @@ void dc_set_power_state(
> enum dc_acpi_cm_power_state power_state)
> {
> struct kref refcount;
> - struct display_mode_lib *dml = kzalloc(sizeof(struct
> display_mode_lib),
> - GFP_KERNEL);
> -
> - ASSERT(dml);
> - if (!dml)
> - return;
> + struct display_mode_lib *dml;
>
> switch (power_state) {
> case DC_ACPI_CM_POWER_STATE_D0:
> @@ -2206,6 +2201,12 @@ void dc_set_power_state(
> * clean state, and dc hw programming optimizations will not
> * cause any trouble.
> */
> + dml = kzalloc(sizeof(struct display_mode_lib),
> + GFP_KERNEL);
> +
> + ASSERT(dml);
> + if (!dml)
> + return;
>
> /* Preserve refcount */
> refcount = dc->current_state->refcount;
> @@ -2219,10 +2220,10 @@ void dc_set_power_state(
> dc->current_state->refcount = refcount;
> dc->current_state->bw_ctx.dml = *dml;
>
> + kfree(dml);
> +
> break;
> }
> -
> - kfree(dml);
> }
>
> void dc_resume(struct dc *dc)
> --
> 2.24.1
>
I've been running with this fix applied on top of Fedora's
5.3.16-300.fc31.x86_64 kernel for
the past two weeks, suspending and resuming often. This the first time
since I bought my
RX 580 8GB more than a year ago that I can suspend and resume reliably.
I'd appreciate a quick review for the above, it really is a trivial change.
Thanks,
Dor
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RESEND v3 2/2] drm: bridge: adv7511: Add support for ADV7535
On Fri, 2020-01-17 at 11:55 +0100, Andrzej Hajda wrote:
> [External]
>
> On 17.01.2020 11:27, Andrzej Hajda wrote:
> > On 07.01.2020 14:34, 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 but on ADV7533 can
> > > be 1.2V
> > > or 1.8V and is configurable in a register.
> > >
> > > Signed-off-by: Bogdan Togorean
> > > ---
> > > drivers/gpu/drm/bridge/adv7511/Kconfig | 13 ++
> > > drivers/gpu/drm/bridge/adv7511/Makefile | 3 +-
> > > drivers/gpu/drm/bridge/adv7511/adv7511.h | 44 +++---
> > > --
> > > drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 35 ++--
> > >
> > > 4 files changed, 32 insertions(+), 63 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/bridge/adv7511/Kconfig
> > > b/drivers/gpu/drm/bridge/adv7511/Kconfig
> > > index 8a56ff81f4fb..47d4eb9e845d 100644
> > > --- a/drivers/gpu/drm/bridge/adv7511/Kconfig
> > > +++ b/drivers/gpu/drm/bridge/adv7511/Kconfig
> > > @@ -4,8 +4,9 @@ config DRM_I2C_ADV7511
> > > depends on OF
> > > select DRM_KMS_HELPER
> > > select REGMAP_I2C
> > > + select DRM_MIPI_DSI
> > > help
> > > - Support for the Analog Device ADV7511(W) and ADV7513 HDMI
> > > encoders.
> > > + Support for the Analog Device ADV7511(W)/13/33/35 HDMI
> > > encoders.
> > >
> > > config DRM_I2C_ADV7511_AUDIO
> > > bool "ADV7511 HDMI Audio driver"
> > > @@ -15,16 +16,8 @@ config DRM_I2C_ADV7511_AUDIO
> > > Support the ADV7511 HDMI Audio interface. This is used in
> > > conjunction with the AV7511 HDMI driver.
> > >
> > > -config DRM_I2C_ADV7533
> > > - bool "ADV7533 encoder"
> > > - depends on DRM_I2C_ADV7511
> > > - select DRM_MIPI_DSI
> > > - default y
> > > - help
> > > - Support for the Analog Devices ADV7533 DSI to HDMI encoder.
> > > -
> > > config DRM_I2C_ADV7511_CEC
> > > - bool "ADV7511/33 HDMI CEC driver"
> > > + bool "ADV7511/33/35 HDMI CEC driver"
> > > depends on DRM_I2C_ADV7511
> > > select CEC_CORE
> > > default y
> > > diff --git a/drivers/gpu/drm/bridge/adv7511/Makefile
> > > b/drivers/gpu/drm/bridge/adv7511/Makefile
> > > index b46ebeb35fd4..d8ceb534b51f 100644
> > > --- a/drivers/gpu/drm/bridge/adv7511/Makefile
> > > +++ b/drivers/gpu/drm/bridge/adv7511/Makefile
> > > @@ -1,6 +1,5 @@
> > > # SPDX-License-Identifier: GPL-2.0-only
> > > -adv7511-y := adv7511_drv.o
> > > +adv7511-y := adv7511_drv.o adv7533.o
> > > adv7511-$(CONFIG_DRM_I2C_ADV7511_AUDIO) += adv7511_audio.o
> > > adv7511-$(CONFIG_DRM_I2C_ADV7511_CEC) += adv7511_cec.o
> > > -adv7511-$(CONFIG_DRM_I2C_ADV7533) += adv7533.o
> > > obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511.o
> > > diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511.h
> > > b/drivers/gpu/drm/bridge/adv7511/adv7511.h
> > > index 52b2adfdc877..ed9cfd944098 100644
> > > --- a/drivers/gpu/drm/bridge/adv7511/adv7511.h
> > > +++ b/drivers/gpu/drm/bridge/adv7511/adv7511.h
> > > @@ -220,6 +220,10 @@
> > >
> > > #define ADV7533_REG_CEC_OFFSET 0x70
> > >
> > > +#define ADV7533_REG_SUPPLY_SELECT0xe4
> > > +
> > > +#define ADV7533_V1P2_ENABLE BIT(7)
> > > +
> > > enum adv7511_input_clock {
> > > ADV7511_INPUT_CLOCK_1X,
> > > ADV7511_INPUT_CLOCK_2X,
> > > @@ -320,6 +324,7 @@ struct adv7511_video_config {
> > > enum adv7511_type {
> > > ADV7511,
> > > ADV7533,
> > > + ADV7535,
> > > };
> > >
> > > #define ADV7511_MAX_ADDRS 3
> > > @@ -393,7 +398,6 @@ static inline int adv7511_cec_init(struct
> > > device *dev, struct adv7511 *adv7511)
> > > }
> > > #endif
> > >
> > > -#ifdef CONFIG_DRM_I2C_ADV7533
> > > void adv7533_dsi_power_on(struct adv7511 *adv);
> > > void adv7533_dsi_power_off(struct adv7511 *adv);
> > > void adv7533_mode_set(struct adv7511 *adv, const struct
> > > drm_display_mode *mode);
> > > @@ -402,44 +406,6 @@ int adv7533_patch_cec_registers(struct
> > > adv7511 *adv);
> > > int adv7533_attach_dsi(struct adv7511 *adv);
> > > void adv7533_detach_dsi(struct adv7511 *adv);
> > > int adv7533_parse_dt(struct device_node *np, struct adv7511
> > > *adv);
> > > -#else
> > > -static inline void adv7533_dsi_power_on(struct adv7511 *adv)
> > > -{
> > > -}
> > > -
> > > -static inline void adv7533_dsi_power_off(struct adv7511 *adv)
> > > -{
> > > -}
> > > -
> > > -static inline void adv7533_mode_set(struct adv7511 *adv,
> > > - const struct drm_display_mode
> > > *mode)
> > > -{
> > > -}
> > > -
> > > -static inline int adv7533_patch_registers(struct adv7511 *adv)
> > > -{
> > > - return -ENODEV;
> > > -}
> > > -
> > > -static inline int adv7533_patch_cec_registers(struct adv7511
> > > *adv)
> > > -{
> > > - return -ENODEV;
> > > -}
> > > -
> > > -static inline int adv7533_attach_dsi(struct adv7511 *adv)
> > > -{
> > > - return -ENODEV;
> > > -}
> > > -
> > > -static inline void adv7533_detach_dsi(struct adv7511 *adv)
> > > -{
> > > -}
> > > -
> > > -static inline int adv7533_parse_dt(struct device
Re: [PATCH 0/4] drm/i915/display: conversion to new logging macros.
On Fri, 17 Jan 2020, Jani Nikula wrote: On Thu, 16 Jan 2020, Wambui Karuga wrote: This series converts the printk based logging macros in drm/i915/display/intel_display.c to the new struct drm_device based logging macros. This change was split into four for manageability and due to the size of drm/i915/display/intel_display.c. Please still write more descriptive commit messages than "part N". What would be a more descriptive subject line? I wasn't really sure about the subject line since the series is for the same file - which is why I went with "part N". What are your basing your patches on? Our CI uses drm-tip, and it's > failing to apply the patches. I'm using drm-tip, but I can rebase and try again. Thanks. wambui. BR, Jani. Wambui Karuga (4): drm/i915/display: conversion to new logging macros part 1 drm/i915/display: conversion to new logging macros part 2 drm/i915/display: conversion to new logging macros part 3 drm/i915/display: convert to new logging macros part 4. drivers/gpu/drm/i915/display/intel_display.c | 1021 ++ 1 file changed, 596 insertions(+), 425 deletions(-) -- Jani Nikula, Intel Open Source Graphics Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 206247] New: 5.4.x: WARNING: CPU: 1 PID: 561 at drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dcn_calcs.c:1464 dcn_bw_update_from_pplib+0xa5/0x2e0 [amdgpu]
https://bugzilla.kernel.org/show_bug.cgi?id=206247 Bug ID: 206247 Summary: 5.4.x: WARNING: CPU: 1 PID: 561 at drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dcn_cal cs.c:1464 dcn_bw_update_from_pplib+0xa5/0x2e0 [amdgpu] Product: Drivers Version: 2.5 Kernel Version: 5.4.x Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-...@kernel-bugs.osdl.org Reporter: udo...@xs4all.nl Regression: No [ 35.250541] [ cut here ] [ 35.278240] WARNING: CPU: 1 PID: 561 at drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dcn_calcs.c:1464 dcn_bw_update_from_pplib+0xa5/0x2e0 [amdgpu] [ 35.357964] Modules linked in: amdgpu(+) gpu_sched hid_generic aesni_intel ttm sr_mod cdrom usbhid i2c_dev autofs4 [ 35.419996] CPU: 1 PID: 561 Comm: systemd-udevd Not tainted 5.4.13 #13 [ 35.459106] Hardware name: Gigabyte Technology Co., Ltd. X570 AORUS PRO/X570 AORUS PRO, BIOS F11 12/06/2019 [ 35.517545] RIP: 0010:dcn_bw_update_from_pplib+0xa5/0x2e0 [amdgpu] [ 35.554572] Code: 0c 24 85 c9 74 24 8d 71 ff 48 8d 44 24 04 48 8d 54 f4 0c eb 0d 48 83 c0 08 48 39 d0 0f 84 2a 01 00 00 44 8b 00 45 85 c0 75 eb <0f> 0b e8 84 9e 93 e7 4c 89 e2 be 04 00 00 00 4c 89 ef e8 54 59 fe [ 35.667119] RSP: 0018:a45ac04fb6c0 EFLAGS: 00010246 [ 35.698421] RAX: a45ac04fb6c4 RBX: 9f808a33 RCX: 0004 [ 35.741178] RDX: a45ac04fb6e4 RSI: 0003 RDI: a8deae51 [ 35.783937] RBP: a45ac04fb800 R08: R09: 03c5 [ 35.826696] R10: 0002 R11: 00f0 R12: a45ac04fb750 [ 35.869455] R13: 9f80865a8400 R14: 0001 R15: 000a [ 35.912212] FS: 7f1f6579a940() GS:9f809ee4() knlGS: [ 35.960700] CS: 0010 DS: ES: CR0: 80050033 [ 35.995125] CR2: 55fb7c7b9e98 CR3: 000409b72000 CR4: 003406e0 [ 36.037884] Call Trace: [ 36.052577] dcn10_create_resource_pool+0x82d/0xb30 [amdgpu] [ 36.086480] ? __kmalloc+0xeb/0xf0 [ 36.106891] dc_create_resource_pool+0xbe/0x130 [amdgpu] [ 36.138767] dc_create+0x213/0x6b0 [amdgpu] [ 36.163871] amdgpu_dm_init+0x138/0x1c0 [amdgpu] [ 36.191574] ? phm_wait_for_register_unequal.part.0+0x4a/0x80 [amdgpu] [ 36.230741] dm_hw_init+0x9/0x20 [amdgpu] [ 36.254801] amdgpu_device_init.cold+0x119b/0x1344 [amdgpu] [ 36.288230] amdgpu_driver_load_kms+0x41/0xc0 [amdgpu] [ 36.319020] drm_dev_register+0x10c/0x150 [ 36.343071] amdgpu_pci_probe+0xcd/0x130 [amdgpu] [ 36.371257] ? pci_match_device+0xd2/0x100 [ 36.395787] pci_device_probe+0xc9/0x140 [ 36.419277] really_probe+0x142/0x3b0 [ 36.441204] device_driver_attach+0x4e/0x60 [ 36.466254] __driver_attach+0x85/0x140 [ 36.489221] ? device_driver_attach+0x60/0x60 [ 36.515314] bus_for_each_dev+0x73/0xb0 [ 36.538283] bus_add_driver+0x13f/0x1e0 [ 36.561249] driver_register+0x67/0xb0 [ 36.583694] ? 0xc0389000 [ 36.603540] do_one_initcall+0x47/0x16f [ 36.626507] ? ___cache_free+0x2c/0x1f0 [ 36.649475] do_init_module+0x51/0x200 [ 36.671921] load_module+0x24b6/0x26e0 [ 36.694370] ? vfs_read+0xee/0x120 [ 36.714733] ? __do_sys_finit_module+0xaa/0x110 [ 36.741866] __do_sys_finit_module+0xaa/0x110 [ 36.767960] do_syscall_64+0x63/0x410 [ 36.789886] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 36.820144] RIP: 0033:0x7f1f667401ad [ 36.841551] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d ab 5c 0c 00 f7 d8 64 89 01 48 [ 36.954097] RSP: 002b:7fffc9e46388 EFLAGS: 0246 ORIG_RAX: 0139 [ 36.999461] RAX: ffda RBX: 55fb7c7ef480 RCX: 7f1f667401ad [ 37.042217] RDX: RSI: 55fb7c7e2aa0 RDI: 000f [ 37.084976] RBP: 0002 R08: R09: 0007 [ 37.127736] R10: 000f R11: 0246 R12: 55fb7c7e2aa0 [ 37.170493] R13: R14: 55fb7c7e7c40 R15: 55fb7c7ef480 [ 37.213251] ---[ end trace fdc62e5509be6ed6 ]--- This bootuip message has been shown for quite a while -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/msm: Add syncobj support.
Hi Bas,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on tegra-drm/drm/tegra/for-next]
[also build test ERROR on drm-tip/drm-tip linus/master v5.5-rc6 next-20200117]
[cannot apply to drm-exynos/exynos-drm-next drm-intel/for-linux-next
drm/drm-next]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url:
https://github.com/0day-ci/linux/commits/Bas-Nieuwenhuizen/drm-msm-Add-syncobj-support/20200118-033342
base: git://anongit.freedesktop.org/tegra/linux.git drm/tegra/for-next
config: arm-defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (GCC) 7.5.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.5.0 make.cross ARCH=arm
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All error/warnings (new ones prefixed by >>):
drivers/gpu/drm/msm/msm_gem_submit.c: In function 'msm_parse_post_deps':
>> drivers/gpu/drm/msm/msm_gem_submit.c:512:23: error: 'syncobj_desc'
>> undeclared (first use in this function); did you mean 'syncobj_stride'?
if (copy_from_user(&syncobj_desc,
^~~~
syncobj_stride
drivers/gpu/drm/msm/msm_gem_submit.c:512:23: note: each undeclared
identifier is reported only once for each function it appears in
In file included from include/linux/list.h:9:0,
from include/linux/preempt.h:11,
from include/linux/spinlock.h:51,
from include/linux/seqlock.h:36,
from include/linux/time.h:6,
from include/linux/ktime.h:24,
from include/linux/sync_file.h:17,
from drivers/gpu/drm/msm/msm_gem_submit.c:8:
>> include/linux/kernel.h:868:2: error: first argument to
>> '__builtin_choose_expr' not a constant
__builtin_choose_expr(__safe_cmp(x, y), \
^
include/linux/kernel.h:877:19: note: in expansion of macro '__careful_cmp'
#define min(x, y) __careful_cmp(x, y, <)
^
>> drivers/gpu/drm/msm/msm_gem_submit.c:514:15: note: in expansion of macro
>> 'min'
min(syncobj_stride, sizeof(syncobj_desc {
^~~
vim +512 drivers/gpu/drm/msm/msm_gem_submit.c
491
492 static int msm_parse_post_deps(struct drm_device *dev,
493 struct drm_file *file,
494 uint64_t out_syncobjs_addr,
495 uint32_t nr_out_syncobjs,
496 uint32_t syncobj_stride,
497 struct msm_submit_post_dep **post_deps)
498 {
499 int ret = 0;
500 uint32_t i, j;
501
502 *post_deps = kmalloc_array(nr_out_syncobjs, sizeof(**post_deps),
503 GFP_KERNEL | __GFP_NOWARN |
__GFP_NORETRY);
504 if (!*post_deps) {
505 ret = -ENOMEM;
506 goto out_syncobjs;
507 }
508
509 for (i = 0; i < nr_out_syncobjs; ++i) {
510 uint64_t address = out_syncobjs_addr + i *
syncobj_stride;
511
> 512 if (copy_from_user(&syncobj_desc,
513 u64_to_user_ptr(address),
> 514 min(syncobj_stride,
> sizeof(syncobj_desc {
515 ret = -EFAULT;
516 goto out_syncobjs;
517 }
518
519 (*post_deps)[i].point = syncobj_desc.point;
520 (*post_deps)[i].chain = NULL;
521
522 if (syncobj_desc.flags) {
523 ret = -EINVAL;
524 break;
525 }
526
527 if (syncobj_desc.point) {
528 if (!drm_core_check_feature(dev,
529
DRIVER_SYNCOBJ_TIMELINE)) {
530 ret = -EOPNOTSUPP;
531 break;
532 }
533
534 (*post_deps)[i].chain =
535 kmalloc(sizeof(*(*post_deps)[i].chain),
536 GFP_KERNEL);
537 if (!(*post_deps)[i].chain) {
538
[Bug 206247] 5.4.x: WARNING: CPU: 1 PID: 561 at drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dcn_calcs.c:1464 dcn_bw_update_from_pplib+0xa5/0x2e0 [amdgpu]
https://bugzilla.kernel.org/show_bug.cgi?id=206247 --- Comment #1 from udo (udo...@xs4all.nl) --- Some context: [ 33.608142] Console: switching to colour dummy device 80x25 [ 33.641766] [drm] initializing kernel modesetting (RAVEN 0x1002:0x15D8 0x1002:0x15D8 0xC8). [ 33.691838] [drm] register mmio base: 0xFCD0 [ 33.691842] [drm] register mmio size: 524288 [ 33.691868] [drm] add ip block number 0 [ 33.775887] [drm] add ip block number 1 [ 33.775887] [drm] add ip block number 2 [ 33.775888] [drm] add ip block number 3 [ 33.775888] [drm] add ip block number 4 [ 33.775889] [drm] add ip block number 5 [ 33.775889] [drm] add ip block number 6 [ 33.775890] [drm] add ip block number 7 [ 33.775890] [drm] add ip block number 8 [ 33.815135] [drm] BIOS signature incorrect 5b 7 [ 34.028500] ATOM BIOS: 113-PICASSO-115 [ 34.028523] [drm] VCN decode is enabled in VM mode [ 34.028524] [drm] VCN encode is enabled in VM mode [ 34.028524] [drm] VCN jpeg decode is enabled in VM mode [ 34.028557] [drm] vm size is 262144 GB, 4 levels, block size is 9-bit, fragment size is 9-bit [ 34.028564] amdgpu :0a:00.0: VRAM: 2048M 0x00F4 - 0x00F47FFF (2048M used) [ 34.028565] amdgpu :0a:00.0: GART: 1024M 0x - 0x3FFF [ 34.028566] amdgpu :0a:00.0: AGP: 267419648M 0x00F8 - 0x [ 34.028569] [drm] Detected VRAM RAM=2048M, BAR=2048M [ 34.028569] [drm] RAM width 128bits DDR4 [ 34.028915] [TTM] Zone kernel: Available graphics memory: 7190102 KiB [ 34.291895] md: md127: resync done. [ 34.339191] [TTM] Zone dma32: Available graphics memory: 2097152 KiB [ 34.491530] [TTM] Initializing pool allocator [ 34.491538] [TTM] Initializing DMA pool allocator [ 34.491594] [drm] amdgpu: 2048M of VRAM memory ready [ 34.575594] [drm] amdgpu: 8192M of GTT memory ready. [ 34.575608] [drm] GART: num cpu pages 262144, num gpu pages 262144 [ 34.643124] [drm] PCIE GART of 1024M enabled (table at 0x00F40090). [ 34.686767] [drm] use_doorbell being set to: [true] [ 34.716100] amdgpu: [powerplay] hwmgr_sw_init smu backed is smu10_smu [ 34.754769] [drm] Found VCN firmware Version: 1.73 Family ID: 18 [ 34.790801] [drm] PSP loading VCN firmware [ 34.836051] [drm] reserve 0x40 from 0xf47f80 for PSP TMR [ 35.108064] [drm] DM_PPLIB: values for F clock [ 35.134706] [drm] DM_PPLIB: 0 in kHz, 3099 in mV [ 35.162883] [drm] DM_PPLIB: 0 in kHz, 3099 in mV [ 35.191055] [drm] DM_PPLIB: 0 in kHz, 3099 in mV [ 35.219246] [drm] DM_PPLIB: 160 in kHz, 4399 in mV [ 35.250541] [ cut here ] [ 35.278240] WARNING: CPU: 1 PID: 561 at drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dcn_calcs.c:1464 dcn_bw_update_from_pplib+0xa5/0x2e0 [amdgpu] -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 206247] 5.4.x: WARNING: CPU: 1 PID: 561 at drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dcn_calcs.c:1464 dcn_bw_update_from_pplib+0xa5/0x2e0 [amdgpu]
https://bugzilla.kernel.org/show_bug.cgi?id=206247 --- Comment #2 from udo (udo...@xs4all.nl) --- And: [ 37.213251] ---[ end trace fdc62e5509be6ed6 ]--- [ 37.241010] [drm] DM_PPLIB: values for DCF clock [ 37.268901] [drm] DM_PPLIB: 30 in kHz, 3099 in mV [ 37.299672] [drm] DM_PPLIB: 60 in kHz, 3574 in mV [ 37.330452] [drm] DM_PPLIB: 626000 in kHz, 4250 in mV [ 37.361230] [drm] DM_PPLIB: 654000 in kHz, 4399 in mV [ 37.422755] [drm] Display Core initialized with v3.2.48! [ 37.479630] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [ 37.519238] [drm] Driver supports precise vblank timestamp query. [ 37.559261] [drm] VCN decode and encode initialized successfully(under DPG Mode). [ 37.606817] [drm] fb mappable at 0x60BC1000 [ 37.631893] [drm] vram apper at 0x6000 [ 37.656429] [drm] size 33177600 [ 37.675225] [drm] fb depth is 24 [ 37.694545] [drm]pitch is 15360 [ 37.715700] fbcon: amdgpudrmfb (fb0) is primary device [ 37.760951] Console: switching to colour frame buffer device 480x135 [ 37.855543] amdgpu :0a:00.0: fb0: amdgpudrmfb frame buffer device [ 37.913255] amdgpu :0a:00.0: ring gfx uses VM inv eng 0 on hub 0 [ 37.913259] amdgpu :0a:00.0: ring comp_1.0.0 uses VM inv eng 1 on hub 0 [ 37.913262] amdgpu :0a:00.0: ring comp_1.1.0 uses VM inv eng 4 on hub 0 [ 37.913264] amdgpu :0a:00.0: ring comp_1.2.0 uses VM inv eng 5 on hub 0 [ 37.913266] amdgpu :0a:00.0: ring comp_1.3.0 uses VM inv eng 6 on hub 0 [ 37.913268] amdgpu :0a:00.0: ring comp_1.0.1 uses VM inv eng 7 on hub 0 [ 37.913271] amdgpu :0a:00.0: ring comp_1.1.1 uses VM inv eng 8 on hub 0 [ 37.913273] amdgpu :0a:00.0: ring comp_1.2.1 uses VM inv eng 9 on hub 0 [ 37.913275] amdgpu :0a:00.0: ring comp_1.3.1 uses VM inv eng 10 on hub 0 [ 37.913277] amdgpu :0a:00.0: ring kiq_2.1.0 uses VM inv eng 11 on hub 0 [ 37.913279] amdgpu :0a:00.0: ring sdma0 uses VM inv eng 0 on hub 1 [ 37.913281] amdgpu :0a:00.0: ring vcn_dec uses VM inv eng 1 on hub 1 [ 37.913283] amdgpu :0a:00.0: ring vcn_enc0 uses VM inv eng 4 on hub 1 [ 37.913285] amdgpu :0a:00.0: ring vcn_enc1 uses VM inv eng 5 on hub 1 [ 37.913288] amdgpu :0a:00.0: ring vcn_jpeg uses VM inv eng 6 on hub 1 [ 38.541203] [drm] Initialized amdgpu 3.35.0 20150101 for :0a:00.0 on minor 0 -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] drm/panel: make LVDS panel driver DPI capable
Hi Oleksandr & Stafan.
Thanks for the update to panel-lvds.
On Wed, Jan 15, 2020 at 12:34:17PM +, Oleksandr Suvorov wrote:
> From: Stefan Agner
>
> The LVDS panel driver has almost everything which is required to
> describe a simple parallel RGB panel (also known as DPI, Display
> Pixel Interface).
>
> Signed-off-by: Stefan Agner
> Signed-off-by: Oleksandr Suvorov
> ---
There are a few high-level things we need to have sorted out.
The driver, when this patch is added, assumes that certain properties
are now mandatory when using the panel-dpi compatible.
- data-mapping
- width-mm
- height-mm
- panel-timing
But this does not match the panel-dpi binding.
So we need the panel-dpi binding updated first.
The current driver specify the connector type in drm_panel_init().
But a DPI panel is assumed to use a DRM_MODE_CONNECTOR_DPI,
and not a DRM_MODE_CONNECTOR_LVDS.
So the drm_panel_init() call needs to take into account the type
of binding.
> @@ -257,7 +279,7 @@ static struct platform_driver panel_lvds_driver = {
> .probe = panel_lvds_probe,
> .remove = panel_lvds_remove,
> .driver = {
> - .name = "panel-lvds",
> + .name = "panel-generic",
I think changing the name of the driver like this is an UAPI change,
which is not OK
> .of_match_table = panel_lvds_of_table,
> },
> };
Sam
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH AUTOSEL 5.4 002/205] drm/panfrost: Add missing check for pfdev->regulator
On Sat, Jan 18, 2020 at 11:18:45AM +0300, Dan Carpenter wrote:
> On Fri, Jan 17, 2020 at 05:59:09PM +0100, Greg KH wrote:
> > On Fri, Jan 17, 2020 at 04:12:27PM +, Steven Price wrote:
> > > On Thu, Jan 16, 2020 at 04:39:37PM +, Sasha Levin wrote:
> > > > From: Steven Price
> > > >
> > > > [ Upstream commit 52282163dfa651849e905886845bcf6850dd83c2 ]
> > >
> > > This commit is effectively already in 5.4. Confusingly there were two
> > > versions of this upstream:
> > >
> > > 52282163dfa6 ("drm/panfrost: Add missing check for pfdev->regulator")
> > > c90f30812a79 ("drm/panfrost: Add missing check for pfdev->regulator")
> > >
> > > It got merged both through a -fixes branch and through the normal merge
> > > window. The two copies caused a bad merge in mainline and this was
> > > effectively reverted in commit 603e398a3db2 ("drm/panfrost: Remove NULL
> > > check for regulator").
> > >
> > > c90f30812a79 is included in v5.4 so should already be in any v5.4.y
> > > release.
> >
> > Have I mentioned this month just how much I hate the way the DRM tree
> > handles stable patches like this? This kind of fallout is a pain for
> > stable maintainers, I dred every time I see a drm patch tagged for
> > stable.
> >
> > But we've been over this all before :(
>
> Another example is:
>
> 29cd13cfd762 ("drm/v3d: Fix memory leak in v3d_submit_cl_ioctl")
> 0d352a3a8a1f ("drm/v3d: don't leak bin job if v3d_job_init fails.")
>
> Two fixes for a memory leak were merged so now it's a double free. I
> sent a patch on Jan 10 but no one responded.
Have a link to the patch? I can't seem to find it :(
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 206231] R9 280X low performance with all games
https://bugzilla.kernel.org/show_bug.cgi?id=206231 --- Comment #13 from Sylvain BERTRAND (sylvain.bertr...@gmail.com) --- What is your CPU? -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Bug 206231] R9 280X low performance with all games
What is your CPU? ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 206231] R9 280X low performance with all games
https://bugzilla.kernel.org/show_bug.cgi?id=206231 --- Comment #14 from Sylvain BERTRAND (sylvain.bertr...@gmail.com) --- BTW, your screenshots are of too low quality to be readable. And what is the tool you user to overlay amd gpu performance? (vulkan?) -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Bug 206231] R9 280X low performance with all games
BTW, your screenshots are of too low quality to be readable. And what is the tool you user to overlay amd gpu performance? (vulkan?) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 206231] R9 280X low performance with all games
https://bugzilla.kernel.org/show_bug.cgi?id=206231 --- Comment #15 from Jacques Belosoukinski (kentos...@whiteninjastudio.com) --- (In reply to Sylvain BERTRAND from comment #14) > BTW, your screenshots are of too low quality to be readable. > And what is the tool you user to overlay amd gpu performance? (vulkan?) Sorry you can view the full resolution here : https://ibb.co/GCmHFkf https://ibb.co/ZXsvNZL I use Gallium HUD with this options : GALLIUM_HUD="fps,cpu,GPU-load,VRAM-usage,draw-calls" %command% (In reply to Sylvain BERTRAND from comment #13) > What is your CPU? My is CPU is an AMD FX 8320 -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Bug 206231] R9 280X low performance with all games
On Sat, Jan 18, 2020 at 03:00:49PM +, bugzilla-dae...@bugzilla.kernel.org wrote: > https://ibb.co/GCmHFkf > https://ibb.co/ZXsvNZL Still the unreadable screenshots. huh?? > I use Gallium HUD with this options : Gallium HUD does not work with vulkan (as far as I know), hence for dota2 vulkan. In dota2 you have an option to display the 3d engine(valve source2) fps. In cs:go, there is a way to enable the 3d engine(valve source1) fps display. It is via the "console", see google.com. > My is CPU is an AMD FX 8320 I have a FX9590, then our benchmarks should be mostly the same. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 206231] R9 280X low performance with all games
https://bugzilla.kernel.org/show_bug.cgi?id=206231 --- Comment #16 from Sylvain BERTRAND (sylvain.bertr...@gmail.com) --- On Sat, Jan 18, 2020 at 03:00:49PM +, bugzilla-dae...@bugzilla.kernel.org wrote: > https://ibb.co/GCmHFkf > https://ibb.co/ZXsvNZL Still the unreadable screenshots. huh?? > I use Gallium HUD with this options : Gallium HUD does not work with vulkan (as far as I know), hence for dota2 vulkan. In dota2 you have an option to display the 3d engine(valve source2) fps. In cs:go, there is a way to enable the 3d engine(valve source1) fps display. It is via the "console", see google.com. > My is CPU is an AMD FX 8320 I have a FX9590, then our benchmarks should be mostly the same. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 206225] nouveau: Screen distortion and lockup on resume
https://bugzilla.kernel.org/show_bug.cgi?id=206225 Ilia Mirkin (imir...@alum.mit.edu) changed: What|Removed |Added CC||imir...@alum.mit.edu --- Comment #6 from Ilia Mirkin (imir...@alum.mit.edu) --- I see you have nouveau.config=PCRYPT=0 in your kernel config. Why did you add this -- was there some kind of issue with the engine? Did someone in #nouveau tell you to do it to help some issue? It's normally used for copy acceleration on G96 (which would, in turn, be used to copy off any vram data to ram on suspend). The reason I ask is that starting with kernel 4.3, that will no longer have the effect of disabling PCRYPT. The new config to achieve that would be nouveau.config=cipher=0. Note that for G96, I don't think anything in firmware-misc-nonfree would affect it either way. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[radeon-alex:amd-19.50 1794/2704] configure: error: in `drivers/gpu/drm/scheduler/dkms':
Hi Flora, FYI, the error/warning still remains. tree: git://people.freedesktop.org/~agd5f/linux.git amd-19.50 head: 1f30c089d757f6d88703676d913f06d8a5ef4353 commit: 4d49aa8a40ceecfd8a6b2d4e1b86396fbeedbb01 [1794/2704] drm/amdkcl/autoconf: generate config.h for in-tree build config: sparc64-allyesconfig (attached as .config) compiler: sparc64-linux-gcc (GCC) 7.5.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross git checkout 4d49aa8a40ceecfd8a6b2d4e1b86396fbeedbb01 # save the attached .config to linux build tree GCC_VERSION=7.5.0 make.cross ARCH=sparc64 If you fix the issue, kindly add following tag Reported-by: kbuild test robot All errors (new ones prefixed by >>): >> configure: error: in `drivers/gpu/drm/scheduler/dkms': >> configure: error: C compiler cannot create executables See `config.log' for more details -- >> configure: error: in `drivers/gpu/drm/ttm/dkms': >> configure: error: C compiler cannot create executables See `config.log' for more details --- 0-DAY kernel test infrastructure Open Source Technology Center https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org Intel Corporation .config.gz Description: application/gzip ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 206225] nouveau: Screen distortion and lockup on resume
https://bugzilla.kernel.org/show_bug.cgi?id=206225 --- Comment #7 from Christoph Marz (derchiller-fo...@online.de) --- (In reply to Ilia Mirkin from comment #6) > I see you have nouveau.config=PCRYPT=0 in your kernel config. Why did you > add this -- was there some kind of issue with the engine? Did someone in > #nouveau tell you to do it to help some issue? Hello Ilia, I had found a bug report (https://bugs.freedesktop.org/show_bug.cgi?id=58378) dealing with a similar issue, and there you suggested to try that option (https://bugs.freedesktop.org/show_bug.cgi?id=58378#c46), and it seemingly solved the issue, so I gave it a try, but removed it after I noticed that it had no effect at all. >It's normally used for copy > acceleration on G96 (which would, in turn, be used to copy off any vram data > to ram on suspend). > > The reason I ask is that starting with kernel 4.3, that will no longer have > the effect of disabling PCRYPT. The new config to achieve that would be > nouveau.config=cipher=0. Ok, thanks for clarification. Copy acceleration sounds good, is there any downside? > Note that for G96, I don't think anything in firmware-misc-nonfree would > affect it either way. I will uninstall that package and report back. BTW: No problems with 5.4.13 so far. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 206225] nouveau: Screen distortion and lockup on resume
https://bugzilla.kernel.org/show_bug.cgi?id=206225 --- Comment #8 from Ilia Mirkin (imir...@alum.mit.edu) --- Well, the problem the other users were having is that their GPUs were actually missing the crypt engine entirely, and we were not properly reading the capabilities bits that indicated this. Trying to use the crypt engine when it's not actually there has some obvious downsides :) But I don't see an indication that this would be the case on your setup. (First of all, we now respect the capability bit, and secondly, you don't have any mmio read/write errors in that range.) -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 206231] R9 280X low performance with all games
https://bugzilla.kernel.org/show_bug.cgi?id=206231 --- Comment #17 from Jacques Belosoukinski (kentos...@whiteninjastudio.com) --- (In reply to Sylvain BERTRAND from comment #16) > On Sat, Jan 18, 2020 at 03:00:49PM +, > bugzilla-dae...@bugzilla.kernel.org wrote: > > https://ibb.co/GCmHFkf > > https://ibb.co/ZXsvNZL > > Still the unreadable screenshots. huh?? > > > I use Gallium HUD with this options : > > Gallium HUD does not work with vulkan (as far as I know), hence for dota2 > vulkan. > In dota2 you have an option to display the 3d engine(valve source2) fps. > > In cs:go, there is a way to enable the 3d engine(valve source1) fps display. > It is via the "console", see google.com. > > > My is CPU is an AMD FX 8320 > > I have a FX9590, then our benchmarks should be mostly the same. I downloaded the Vulkan DLC and active the FPS in Dota 2. I get between ~80 and 90 fps : https://cdn.discordapp.com/attachments/410134758891323400/668192505740787762/20200118213508_1.jpg https://cdn.discordapp.com/attachments/410134758891323400/668192505740787762/20200118213508_1.jpg For CSGO, i get between ~70 and +100fps : https://cdn.discordapp.com/attachments/410134758891323400/668197367094181899/20200118215441_1.jpg https://cdn.discordapp.com/attachments/410134758891323400/668197384995733504/20200118215612_1.jpg -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[git pull] drm fixes for 5.5-rc7
Hey Linus, Back from LCA2020, fixes wasn't too busy last week, seems to have quieten down appropriately, some amdgpu, i915, then a core mst fix and one fix for virtio-gpu and one for rockchip. Dave. drm-fixes-2020-01-19: drm fixes for 5.5-rc7 core mst: - serialize down messages and clear timeslots are on unplug amdgpu: - Update golden settings for renoir - eDP fix i915: - uAPI fix: Remove dash and colon from PMU names to comply with tools/perf - Fix for include file that was indirectly included - Two fixes to make sure VMA are marked active for error capture virtio: - maintain obj reservation lock when submitting cmds rockchip: - increase link rate var size to accommodate rates The following changes since commit b3a987b0264d3ddbb24293ebff10eddfc472f653: Linux 5.5-rc6 (2020-01-12 16:55:08 -0800) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2020-01-19 for you to fetch changes up to f66d84c8b4db9a4f77f29e2d8fd521196c879582: Merge tag 'drm-misc-fixes-2020-01-16' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes (2020-01-18 12:54:37 +1000) drm fixes for 5.5-rc7 core mst: - serialize down messages and clear timeslots are on unplug amdgpu: - Update golden settings for renoir - eDP fix i915: - uAPI fix: Remove dash and colon from PMU names to comply with tools/perf - Fix for include file that was indirectly included - Two fixes to make sure VMA are marked active for error capture virtio: - maintain obj reservation lock when submitting cmds rockchip: - increase link rate var size to accommodate rates Aaron Liu (1): drm/amdgpu: update goldensetting for renoir Chris Wilson (3): drm/i915/gt: Skip trying to unbind in restore_ggtt_mappings drm/i915/gt: Mark context->state vma as active while pinned drm/i915/gt: Mark ring->vma as active while pinned Dave Airlie (3): Merge tag 'amd-drm-fixes-5.5-2020-01-15' of git://people.freedesktop.org/~agd5f/linux into drm-fixes Merge tag 'drm-intel-fixes-2020-01-16' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixes Merge tag 'drm-misc-fixes-2020-01-16' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes Gerd Hoffmann (1): drm/virtio: add missing virtio_gpu_array_lock_resv call Mario Kleiner (1): drm/amd/display: Reorder detect_edp_sink_caps before link settings read. Tobias Schramm (1): drm/rockchip: fix integer type used for storing dp data rate Tvrtko Ursulin (1): drm/i915/pmu: Do not use colons or dashes in PMU names Wayne Lin (2): drm/dp_mst: clear time slots for ports invalid drm/dp_mst: Have DP_Tx send one msg at a time YueHaibing (1): drm/i915: Add missing include file drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c| 2 +- drivers/gpu/drm/amd/display/dc/core/dc_link.c | 2 +- drivers/gpu/drm/drm_dp_mst_topology.c | 39 -- drivers/gpu/drm/i915/gt/intel_context.c | 40 +-- drivers/gpu/drm/i915/i915_gem_gtt.c | 7 ++--- drivers/gpu/drm/i915/i915_pmu.c | 11 ++-- drivers/gpu/drm/i915/selftests/i915_random.h | 1 + drivers/gpu/drm/rockchip/cdn-dp-core.h| 2 +- drivers/gpu/drm/virtio/virtgpu_plane.c| 1 + include/drm/drm_dp_mst_helper.h | 6 10 files changed, 94 insertions(+), 17 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Bug 206231] R9 280X low performance with all games
On Sat, Jan 18, 2020 at 08:59:14PM +, bugzilla-dae...@bugzilla.kernel.org wrote: > I downloaded the Vulkan DLC and active the FPS in Dota 2. I get between ~80 > and > 90 fps : I have ~ the same fps (even though it can go somewhat below in intense team fights) > For CSGO, i get between ~70 and +100fps : I have ~ the same for competitive maps. For danger zone maps, namely big open maps, csgo 3d engine has disastrous performance. Valve is aware of the problem. It seems there is a kind of cpu cap somewhere since max or lowest 3d settings does not seem to impact significantly the performance. Don't forget: I heard southern island parts suffer from a critical mip mapping bug/slowdown. The real benchmark is how much time and how often the fps goes below 60 in the worst realistic conditions (average does not matter). I did re-install "rise of the tomb raider", I still get gpu vm faults. If I recall properly "bioshock infinite" is gpu nasty even though it is a GL game. -- Sylvain ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 206231] R9 280X low performance with all games
https://bugzilla.kernel.org/show_bug.cgi?id=206231 --- Comment #18 from Sylvain BERTRAND (sylvain.bertr...@gmail.com) --- On Sat, Jan 18, 2020 at 08:59:14PM +, bugzilla-dae...@bugzilla.kernel.org wrote: > I downloaded the Vulkan DLC and active the FPS in Dota 2. I get between ~80 > and > 90 fps : I have ~ the same fps (even though it can go somewhat below in intense team fights) > For CSGO, i get between ~70 and +100fps : I have ~ the same for competitive maps. For danger zone maps, namely big open maps, csgo 3d engine has disastrous performance. Valve is aware of the problem. It seems there is a kind of cpu cap somewhere since max or lowest 3d settings does not seem to impact significantly the performance. Don't forget: I heard southern island parts suffer from a critical mip mapping bug/slowdown. The real benchmark is how much time and how often the fps goes below 60 in the worst realistic conditions (average does not matter). I did re-install "rise of the tomb raider", I still get gpu vm faults. If I recall properly "bioshock infinite" is gpu nasty even though it is a GL game. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm fixes for 5.5-rc7
The pull request you sent on Sun, 19 Jan 2020 07:21:35 +1000: > git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2020-01-19 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/244dc2689085d7ff478f7b61841e62e59bea4557 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 206017] Kernel 5.4.x unusable with GUI due to crashes (some hard)
https://bugzilla.kernel.org/show_bug.cgi?id=206017 --- Comment #14 from Paul (paul.e.hi...@outlook.com) --- (In reply to Paul from comment #13) > Hello! > > I am experiencing the same issue on 5.4.10 (Fedora 31, KDE Spin). I'm going > to attempt the 'amdgpu.noretry=0' fix later today. > > I made the below bug report with Fedora: > https://ask.fedoraproject.org/t/fedora-kde-amdgpu-issue/5026 > > > Summarized: > gpu: Radeon Vega 10 > > Issue: I discovered a lot of these entries within journalctl and dmesg after > gui freezes: > > kernel: [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, but > soft recovered > kernel: [drm:amdgpu_dm_atomic_commit_tail [amdgpu]] *ERROR* Waiting for > fences timed out! > > Thank you! Just wanted to report in that the 'amdgpu.noretry=0' workaround resolved my issues. Thanks! -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v10 4/5] drm/panel: support for boe, tv101wum-n53 wuxga dsi video mode panel
Boe,tv101wum-n53's connector is same as boe,tv101wum-nl6.
The most codes can be reuse.
So boe,tv101wum-n53 and boe,tv101wum-nl6 use one driver file.
Add the different parts in driver data.
Signed-off-by: Jitao Shi
Reviewed-by: Sam Ravnborg
---
.../gpu/drm/panel/panel-boe-tv101wum-nl6.c| 31 +++
1 file changed, 31 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
index 2160144ca51b..e77ea577d93a 100644
--- a/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
+++ b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
@@ -593,6 +593,34 @@ static const struct panel_desc auo_kd101n80_45na_desc = {
.discharge_on_disable = true,
};
+static const struct drm_display_mode boe_tv101wum_n53_default_mode = {
+ .clock = 159916,
+ .hdisplay = 1200,
+ .hsync_start = 1200 + 80,
+ .hsync_end = 1200 + 80 + 24,
+ .htotal = 1200 + 80 + 24 + 40,
+ .vdisplay = 1920,
+ .vsync_start = 1920 + 20,
+ .vsync_end = 1920 + 20 + 4,
+ .vtotal = 1920 + 20 + 4 + 10,
+ .vrefresh = 60,
+ .type = DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED,
+};
+
+static const struct panel_desc boe_tv101wum_n53_desc = {
+ .modes = &boe_tv101wum_n53_default_mode,
+ .bpc = 8,
+ .size = {
+ .width_mm = 135,
+ .height_mm = 216,
+ },
+ .lanes = 4,
+ .format = MIPI_DSI_FMT_RGB888,
+ .mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_SYNC_PULSE |
+ MIPI_DSI_MODE_LPM,
+ .init_cmds = boe_init_cmd,
+};
+
static int boe_panel_get_modes(struct drm_panel *panel,
struct drm_connector *connector)
{
@@ -725,6 +753,9 @@ static const struct of_device_id boe_of_match[] = {
{ .compatible = "auo,kd101n80-45na",
.data = &auo_kd101n80_45na_desc
},
+ { .compatible = "boe,tv101wum-n53",
+ .data = &boe_tv101wum_n53_desc
+ },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, boe_of_match);
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v10 2/5] drm/panel: support for boe tv101wum-nl6 wuxga dsi video mode panel
Add driver for BOE tv101wum-nl6 panel is a 10.1" 1200x1920 panel.
Signed-off-by: Jitao Shi
---
drivers/gpu/drm/panel/Kconfig | 9 +
drivers/gpu/drm/panel/Makefile| 1 +
.../gpu/drm/panel/panel-boe-tv101wum-nl6.c| 693 ++
3 files changed, 703 insertions(+)
create mode 100644 drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index ae44ac2ec106..ca727c233a9a 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -29,6 +29,15 @@ config DRM_PANEL_BOE_HIMAX8279D
24 bit RGB per pixel. It provides a MIPI DSI interface to
the host and has a built-in LED backlight.
+config DRM_PANEL_BOE_TV101WUM_NL6
+ tristate "BOE TV101WUM 1200x1920 panel"
+ depends on OF
+ depends on DRM_MIPI_DSI
+ depends on BACKLIGHT_CLASS_DEVICE
+ help
+ Say Y here if you want to support for BOE TV101WUM WUXGA PANEL
+ DSI Video Mode panel
+
config DRM_PANEL_LVDS
tristate "Generic LVDS panel driver"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 7c4d3c581fd4..a659ce403d0e 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -1,6 +1,7 @@
# SPDX-License-Identifier: GPL-2.0
obj-$(CONFIG_DRM_PANEL_ARM_VERSATILE) += panel-arm-versatile.o
obj-$(CONFIG_DRM_PANEL_BOE_HIMAX8279D) += panel-boe-himax8279d.o
+obj-$(CONFIG_DRM_PANEL_BOE_TV101WUM_NL6) += panel-boe-tv101wum-nl6.o
obj-$(CONFIG_DRM_PANEL_LVDS) += panel-lvds.o
obj-$(CONFIG_DRM_PANEL_SIMPLE) += panel-simple.o
obj-$(CONFIG_DRM_PANEL_FEIYANG_FY07024DI26A30D) +=
panel-feiyang-fy07024di26a30d.o
diff --git a/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
new file mode 100644
index ..51fde588adc1
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
@@ -0,0 +1,693 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2018 MediaTek Inc.
+ * Author: Jitao Shi
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#include
+
+struct panel_desc {
+ const struct drm_display_mode *modes;
+ unsigned int bpc;
+
+ /**
+* @width_mm: width of the panel's active display area
+* @height_mm: height of the panel's active display area
+*/
+ struct {
+ unsigned int width_mm;
+ unsigned int height_mm;
+ } size;
+
+ unsigned long mode_flags;
+ enum mipi_dsi_pixel_format format;
+ const struct panel_init_cmd *init_cmds;
+ unsigned int lanes;
+};
+
+struct boe_panel {
+ struct drm_panel base;
+ struct mipi_dsi_device *dsi;
+
+ const struct panel_desc *desc;
+
+ struct regulator *pp1800;
+ struct regulator *avee;
+ struct regulator *avdd;
+ struct gpio_desc *enable_gpio;
+
+ bool prepared;
+};
+
+enum dsi_cmd_type {
+ INIT_DCS_CMD,
+ DELAY_CMD,
+};
+
+struct panel_init_cmd {
+ enum dsi_cmd_type type;
+ size_t len;
+ const char *data;
+};
+
+#define _INIT_DCS_CMD(...) { \
+ .type = INIT_DCS_CMD, \
+ .len = sizeof((char[]){__VA_ARGS__}), \
+ .data = (char[]){__VA_ARGS__} }
+
+#define _INIT_DELAY_CMD(...) { \
+ .type = DELAY_CMD,\
+ .len = sizeof((char[]){__VA_ARGS__}), \
+ .data = (char[]){__VA_ARGS__} }
+
+static const struct panel_init_cmd boe_init_cmd[] = {
+ _INIT_DELAY_CMD(24),
+ _INIT_DCS_CMD(0xB0, 0x05),
+ _INIT_DCS_CMD(0xB1, 0xE5),
+ _INIT_DCS_CMD(0xB3, 0x52),
+ _INIT_DCS_CMD(0xB0, 0x00),
+ _INIT_DCS_CMD(0xB3, 0x88),
+ _INIT_DCS_CMD(0xB0, 0x04),
+ _INIT_DCS_CMD(0xB8, 0x00),
+ _INIT_DCS_CMD(0xB0, 0x00),
+ _INIT_DCS_CMD(0xB6, 0x03),
+ _INIT_DCS_CMD(0xBA, 0x8B),
+ _INIT_DCS_CMD(0xBF, 0x1A),
+ _INIT_DCS_CMD(0xC0, 0x0F),
+ _INIT_DCS_CMD(0xC2, 0x0C),
+ _INIT_DCS_CMD(0xC3, 0x02),
+ _INIT_DCS_CMD(0xC4, 0x0C),
+ _INIT_DCS_CMD(0xC5, 0x02),
+ _INIT_DCS_CMD(0xB0, 0x01),
+ _INIT_DCS_CMD(0xE0, 0x26),
+ _INIT_DCS_CMD(0xE1, 0x26),
+ _INIT_DCS_CMD(0xDC, 0x00),
+ _INIT_DCS_CMD(0xDD, 0x00),
+ _INIT_DCS_CMD(0xCC, 0x26),
+ _INIT_DCS_CMD(0xCD, 0x26),
+ _INIT_DCS_CMD(0xC8, 0x00),
+ _INIT_DCS_CMD(0xC9, 0x00),
+ _INIT_DCS_CMD(0xD2, 0x03),
+ _INIT_DCS_CMD(0xD3, 0x03),
+ _INIT_DCS_CMD(0xE6, 0x04),
+ _INIT_DCS_CMD(0xE7, 0x04),
+ _INIT_DCS_CMD(0xC4, 0x09),
+ _INIT_DCS_CMD(0xC5, 0x09),
+ _INIT_DCS_CMD(0xD8, 0x0A),
+ _INIT_DCS_CMD(0xD9, 0x0A),
+ _INIT_DCS_CMD(0xC2, 0x0B),
+ _INIT_DCS_CMD(0xC3, 0x0B),
+ _INIT_DCS_CMD(0xD6, 0x0C),
+ _INIT_DCS_CMD(0xD7, 0x0C),
+ _INIT_DCS_CMD(0xC0, 0x05),
+ _INIT_DCS_CMD(0xC1, 0x05),
+ _INIT_DCS_C
[PATCH v10 3/5] drm/panel: support for auo, kd101n80-45na wuxga dsi video mode panel
Auo,kd101n80-45na's connector is same as boe,tv101wum-nl6.
The most codes can be reuse.
So auo,kd101n80-45na and boe,tv101wum-nl6 use one driver file.
Add the different parts in driver data.
Signed-off-by: Jitao Shi
---
drivers/gpu/drm/panel/Kconfig | 6 +-
.../gpu/drm/panel/panel-boe-tv101wum-nl6.c| 64 +--
2 files changed, 61 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index ca727c233a9a..b5413edd625b 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -30,13 +30,13 @@ config DRM_PANEL_BOE_HIMAX8279D
the host and has a built-in LED backlight.
config DRM_PANEL_BOE_TV101WUM_NL6
- tristate "BOE TV101WUM 1200x1920 panel"
+ tristate "BOE TV101WUM and AUO KD101N80 45NA 1200x1920 panel"
depends on OF
depends on DRM_MIPI_DSI
depends on BACKLIGHT_CLASS_DEVICE
help
- Say Y here if you want to support for BOE TV101WUM WUXGA PANEL
- DSI Video Mode panel
+ Say Y here if you want to support for BOE TV101WUM and AUO KD101N80
+ 45NA WUXGA PANEL DSI Video Mode panel
config DRM_PANEL_LVDS
tristate "Generic LVDS panel driver"
diff --git a/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
index 51fde588adc1..2160144ca51b 100644
--- a/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
+++ b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
@@ -34,6 +34,7 @@ struct panel_desc {
enum mipi_dsi_pixel_format format;
const struct panel_init_cmd *init_cmds;
unsigned int lanes;
+ bool discharge_on_disable;
};
struct boe_panel {
@@ -367,6 +368,15 @@ static const struct panel_init_cmd boe_init_cmd[] = {
{},
};
+static const struct panel_init_cmd auo_kd101n80_45na_init_cmd[] = {
+ _INIT_DELAY_CMD(24),
+ _INIT_DCS_CMD(0x11),
+ _INIT_DELAY_CMD(120),
+ _INIT_DCS_CMD(0x29),
+ _INIT_DELAY_CMD(120),
+ {},
+};
+
static inline struct boe_panel *to_boe_panel(struct drm_panel *panel)
{
return container_of(panel, struct boe_panel, base);
@@ -444,12 +454,22 @@ static int boe_panel_unprepare(struct drm_panel *panel)
}
msleep(150);
- gpiod_set_value(boe->enable_gpio, 0);
- usleep_range(500, 1000);
- regulator_disable(boe->avee);
- regulator_disable(boe->avdd);
- usleep_range(5000, 7000);
- regulator_disable(boe->pp1800);
+
+ if (boe->desc->discharge_on_disable) {
+ regulator_disable(boe->avee);
+ regulator_disable(boe->avdd);
+ usleep_range(5000, 7000);
+ gpiod_set_value(boe->enable_gpio, 0);
+ usleep_range(5000, 7000);
+ regulator_disable(boe->pp1800);
+ } else {
+ gpiod_set_value(boe->enable_gpio, 0);
+ usleep_range(500, 1000);
+ regulator_disable(boe->avee);
+ regulator_disable(boe->avdd);
+ usleep_range(5000, 7000);
+ regulator_disable(boe->pp1800);
+ }
boe->prepared = false;
@@ -542,6 +562,35 @@ static const struct panel_desc boe_tv101wum_nl6_desc = {
.mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_SYNC_PULSE |
MIPI_DSI_MODE_LPM,
.init_cmds = boe_init_cmd,
+ .discharge_on_disable = false,
+};
+
+static const struct drm_display_mode auo_kd101n80_45na_default_mode = {
+ .clock = 157000,
+ .hdisplay = 1200,
+ .hsync_start = 1200 + 80,
+ .hsync_end = 1200 + 80 + 24,
+ .htotal = 1200 + 80 + 24 + 36,
+ .vdisplay = 1920,
+ .vsync_start = 1920 + 16,
+ .vsync_end = 1920 + 16 + 4,
+ .vtotal = 1920 + 16 + 4 + 16,
+ .vrefresh = 60,
+};
+
+static const struct panel_desc auo_kd101n80_45na_desc = {
+ .modes = &auo_kd101n80_45na_default_mode,
+ .bpc = 8,
+ .size = {
+ .width_mm = 135,
+ .height_mm = 216,
+ },
+ .lanes = 4,
+ .format = MIPI_DSI_FMT_RGB888,
+ .mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_SYNC_PULSE |
+ MIPI_DSI_MODE_LPM,
+ .init_cmds = auo_kd101n80_45na_init_cmd,
+ .discharge_on_disable = true,
};
static int boe_panel_get_modes(struct drm_panel *panel,
@@ -673,6 +722,9 @@ static const struct of_device_id boe_of_match[] = {
{ .compatible = "boe,tv101wum-nl6",
.data = &boe_tv101wum_nl6_desc
},
+ { .compatible = "auo,kd101n80-45na",
+ .data = &auo_kd101n80_45na_desc
+ },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, boe_of_match);
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v10 5/5] drm/panel: support for auo, b101uan08.3 wuxga dsi video mode panel
Auo,auo,b101uan08.3's connector is same as boe,tv101wum-nl6.
The most codes can be reuse.
So auo,b101uan08.3 and boe,tv101wum-nl6 use one driver file.
Add the different parts in driver data.
Signed-off-by: Jitao Shi
Reviewed-by: Sam Ravnborg
---
.../gpu/drm/panel/panel-boe-tv101wum-nl6.c| 78 +++
1 file changed, 78 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
index e77ea577d93a..01faf8597700 100644
--- a/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
+++ b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
@@ -377,6 +377,53 @@ static const struct panel_init_cmd
auo_kd101n80_45na_init_cmd[] = {
{},
};
+static const struct panel_init_cmd auo_b101uan08_3_init_cmd[] = {
+ _INIT_DELAY_CMD(24),
+ _INIT_DCS_CMD(0xB0, 0x01),
+ _INIT_DCS_CMD(0xC0, 0x48),
+ _INIT_DCS_CMD(0xC1, 0x48),
+ _INIT_DCS_CMD(0xC2, 0x47),
+ _INIT_DCS_CMD(0xC3, 0x47),
+ _INIT_DCS_CMD(0xC4, 0x46),
+ _INIT_DCS_CMD(0xC5, 0x46),
+ _INIT_DCS_CMD(0xC6, 0x45),
+ _INIT_DCS_CMD(0xC7, 0x45),
+ _INIT_DCS_CMD(0xC8, 0x64),
+ _INIT_DCS_CMD(0xC9, 0x64),
+ _INIT_DCS_CMD(0xCA, 0x4F),
+ _INIT_DCS_CMD(0xCB, 0x4F),
+ _INIT_DCS_CMD(0xCC, 0x40),
+ _INIT_DCS_CMD(0xCD, 0x40),
+ _INIT_DCS_CMD(0xCE, 0x66),
+ _INIT_DCS_CMD(0xCF, 0x66),
+ _INIT_DCS_CMD(0xD0, 0x4F),
+ _INIT_DCS_CMD(0xD1, 0x4F),
+ _INIT_DCS_CMD(0xD2, 0x41),
+ _INIT_DCS_CMD(0xD3, 0x41),
+ _INIT_DCS_CMD(0xD4, 0x48),
+ _INIT_DCS_CMD(0xD5, 0x48),
+ _INIT_DCS_CMD(0xD6, 0x47),
+ _INIT_DCS_CMD(0xD7, 0x47),
+ _INIT_DCS_CMD(0xD8, 0x46),
+ _INIT_DCS_CMD(0xD9, 0x46),
+ _INIT_DCS_CMD(0xDA, 0x45),
+ _INIT_DCS_CMD(0xDB, 0x45),
+ _INIT_DCS_CMD(0xDC, 0x64),
+ _INIT_DCS_CMD(0xDD, 0x64),
+ _INIT_DCS_CMD(0xDE, 0x4F),
+ _INIT_DCS_CMD(0xDF, 0x4F),
+ _INIT_DCS_CMD(0xE0, 0x40),
+ _INIT_DCS_CMD(0xE1, 0x40),
+ _INIT_DCS_CMD(0xE2, 0x66),
+ _INIT_DCS_CMD(0xE3, 0x66),
+ _INIT_DCS_CMD(0xE4, 0x4F),
+ _INIT_DCS_CMD(0xE5, 0x4F),
+ _INIT_DCS_CMD(0xE6, 0x41),
+ _INIT_DCS_CMD(0xE7, 0x41),
+ _INIT_DELAY_CMD(150),
+ {},
+};
+
static inline struct boe_panel *to_boe_panel(struct drm_panel *panel)
{
return container_of(panel, struct boe_panel, base);
@@ -621,6 +668,34 @@ static const struct panel_desc boe_tv101wum_n53_desc = {
.init_cmds = boe_init_cmd,
};
+static const struct drm_display_mode auo_b101uan08_3_default_mode = {
+ .clock = 159667,
+ .hdisplay = 1200,
+ .hsync_start = 1200 + 60,
+ .hsync_end = 1200 + 60 + 4,
+ .htotal = 1200 + 60 + 4 + 80,
+ .vdisplay = 1920,
+ .vsync_start = 1920 + 34,
+ .vsync_end = 1920 + 34 + 2,
+ .vtotal = 1920 + 34 + 2 + 24,
+ .vrefresh = 60,
+ .type = DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED,
+};
+
+static const struct panel_desc auo_b101uan08_3_desc = {
+ .modes = &auo_b101uan08_3_default_mode,
+ .bpc = 8,
+ .size = {
+ .width_mm = 135,
+ .height_mm = 216,
+ },
+ .lanes = 4,
+ .format = MIPI_DSI_FMT_RGB888,
+ .mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_SYNC_PULSE |
+ MIPI_DSI_MODE_LPM,
+ .init_cmds = auo_b101uan08_3_init_cmd,
+};
+
static int boe_panel_get_modes(struct drm_panel *panel,
struct drm_connector *connector)
{
@@ -756,6 +831,9 @@ static const struct of_device_id boe_of_match[] = {
{ .compatible = "boe,tv101wum-n53",
.data = &boe_tv101wum_n53_desc
},
+ { .compatible = "auo,b101uan08.3",
+ .data = &auo_b101uan08_3_desc
+ },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, boe_of_match);
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v10 1/5] dt-bindings: display: panel: Add boe tv101wum-n16 panel bindings
Add documentation for "boe,tv101wum-n16", "auo,kd101n80-45na",
"boe,tv101wum-n53" and "auo,b101uan08.3" panels.
Signed-off-by: Jitao Shi
Reviewed-by: Sam Ravnborg
Reviewed-by: Sam Ravnborg
---
.../display/panel/boe,tv101wum-nl6.yaml | 80 +++
1 file changed, 80 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml
diff --git
a/Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml
b/Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml
new file mode 100644
index ..740213459134
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml
@@ -0,0 +1,80 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/boe,tv101wum-nl6.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: BOE TV101WUM-NL6 DSI Display Panel
+
+maintainers:
+ - Thierry Reding
+ - Sam Ravnborg
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+enum:
+# BOE TV101WUM-NL6 10.1" WUXGA TFT LCD panel
+ - boe,tv101wum-nl6
+# AUO KD101N80-45NA 10.1" WUXGA TFT LCD panel
+ - auo,kd101n80-45na
+# BOE TV101WUM-N53 10.1" WUXGA TFT LCD panel
+ - boe,tv101wum-n53
+# AUO B101UAN08.3 10.1" WUXGA TFT LCD panel
+ - auo,b101uan08.3
+
+ reg:
+description: the virtual channel number of a DSI peripheral
+
+ enable-gpios:
+description: a GPIO spec for the enable pin
+
+ pp1800-supply:
+description: core voltage supply
+
+ avdd-supply:
+description: phandle of the regulator that provides positive voltage
+
+ avee-supply:
+description: phandle of the regulator that provides negative voltage
+
+ backlight:
+description: phandle of the backlight device attached to the panel
+
+ port: true
+
+required:
+ - compatible
+ - reg
+ - enable-gpios
+ - pp1800-supply
+ - avdd-supply
+ - avee-supply
+
+additionalProperties: false
+
+examples:
+ - |
+dsi {
+#address-cells = <1>;
+#size-cells = <0>;
+panel@0 {
+compatible = "boe,tv101wum-nl6";
+reg = <0>;
+enable-gpios = <&pio 45 0>;
+avdd-supply = <&ppvarn_lcd>;
+avee-supply = <&ppvarp_lcd>;
+pp1800-supply = <&pp1800_lcd>;
+backlight = <&backlight_lcd0>;
+status = "okay";
+port {
+panel_in: endpoint {
+remote-endpoint = <&dsi_out>;
+};
+};
+};
+};
+
+...
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v10 0/5] add driver for "boe, tv101wum-nl6", "boe, tv101wum-n53", "auo, kd101n80-45na" and "auo, b101uan08.3" panels
Changes since v9: - remove Rob from maintainers in boe,tv101wum-nl6.yaml Changes since v8: - merge the panel documents to one. - delay move the drm_panel_of_backlight after drm_panel_init Changes since v7: - base drm-misc-next branch - fix document pass dt_binding_check - remove backlight from panel driver Changes since v6: - fix boe_panel_init err uninit. - adjust the delay of backlight on. Changes since v5: - covert the documents to yaml - fine tune boe, tv101wum-n53 panel video timine Changes since v4: - add auo,b101uan08.3 panel for this driver. - add boe,tv101wum-n53 panel for this driver. Changes since v3: - remove check enable_gpio. - fine tune the auo,kd101n80-45na panel's power on timing. Changes since v2: - correct the panel size - remove blank line in Kconfig - move auo,kd101n80-45na panel driver in this series. Changes since v1: - update typo nl6 -> n16. - update new panel config and makefile are added in alphabetically order. - add the panel mode and panel info in driver data. - merge auo,kd101n80-45a and boe,tv101wum-nl6 in one driver Jitao Shi (5): dt-bindings: display: panel: Add boe tv101wum-n16 panel bindings drm/panel: support for boe tv101wum-nl6 wuxga dsi video mode panel drm/panel: support for auo, kd101n80-45na wuxga dsi video mode panel drm/panel: support for boe, tv101wum-n53 wuxga dsi video mode panel drm/panel: support for auo, b101uan08.3 wuxga dsi video mode panel .../display/panel/boe,tv101wum-nl6.yaml | 80 ++ drivers/gpu/drm/panel/Kconfig | 9 + drivers/gpu/drm/panel/Makefile| 1 + .../gpu/drm/panel/panel-boe-tv101wum-nl6.c| 854 ++ 4 files changed, 944 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml create mode 100644 drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c -- 2.21.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RFC 3/3] drm/ttm: support memcg for ttm_tt
On Mon, Jan 13, 2020 at 11:56 PM Christian König
wrote:
>
> 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.
>
Sorry for responding late.
GEM layer seems not a proper place to handle this as:
1. it is not aware of the back storage (system mem or device mem) unless
we add this information up to GEM which I think is not appropriate
2. system memory allocated by GEM with drm_gem_get_pages() is already
charged to memcg, it's only the ttm system memory not charged to memcg
Implement in driver like amdgpu is an option. But seems the problem is inside
TTM which does not charge pages allocated by itself to memcg, won't it be
better to solve it in TTM so that all drivers using it can benefit? Or you just
think we should not rely on memcg for GPU system memory limitation?
> > 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 process B,
> > then process B populate this buffer, the memory is still charged
> > to process A's memcg; if a buffer is created by process A when in
> > memcg B, then A is moved to memcg C and populate this buffer, it
> > will charge memcg B.
>
> This is actually the most common use case for graphics application where
> the X server allocates most of the backing store.
>
> So we need a better handling than just accounting the memory to whoever
> allocated it first.
>
You mean the application based on DRI2 and X11 protocol draw? I think this
is still reasonable to charge xserver for the memory, because xserver allocate
the buffer and share to application which is its design and implementation
nature. With DRI3, the buffer is allocated by application, also
suitable for this
approach.
Regards,
Qiang
> Regards,
> Christian.
>
> >
> > Signed-off-by: Qiang Yu
> > ---
> > drivers/gpu/drm/ttm/ttm_bo.c | 10 ++
> > drivers/gpu/drm/ttm/ttm_page_alloc.c | 18 +-
> > drivers/gpu/drm/ttm/ttm_tt.c | 3 +++
> > include/drm/ttm/ttm_bo_api.h | 5 +
> > include/drm/ttm/ttm_tt.h | 4
> > 5 files changed, 39 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> > index 8d91b0428af1..4e64846ee523 100644
> > --- a/drivers/gpu/drm/ttm/ttm_bo.c
> > +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> > @@ -42,6 +42,7 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > static void ttm_bo_global_kobj_release(struct kobject *kobj);
> >
> > @@ -162,6 +163,10 @@ static void ttm_bo_release_list(struct kref *list_kref)
> > if (!ttm_bo_uses_embedded_gem_object(bo))
> > dma_resv_fini(&bo->base._resv);
> > mutex_destroy(&bo->wu_mutex);
> > +#ifdef CONFIG_MEMCG
> > + if (bo->memcg)
> > + css_put(&bo->memcg->css);
> > +#endif
> > bo->destroy(bo);
> > ttm_mem_global_free(&ttm_mem_glob, acc_size);
> > }
> > @@ -1330,6 +1335,11 @@ int ttm_bo_init_reserved(struct ttm_bo_device *bdev,
> > }
> > atomic_inc(&ttm_bo_glob.bo_count);
> >
> > +#ifdef CONFIG_MEMCG
> > + if (bo->type == ttm_bo_type_device)
> > + bo->memcg = mem_cgroup_driver_get_from_current();
> > +#endif
> > +
> > /*
> >* For ttm_bo_type_device buffers, allocate
> >* address space from the device.
> > diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c
> > b/drivers/gpu/drm/ttm/ttm_page_alloc.c
> > index b40a4678c296..ecd1831a1d38 100644
> > --- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
> > +++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
> > @@ -42,7 +42,7 @@
> > #include /* for seq_printf */
> > #include
> > #include
> > -
> > +#include
> > #include
> >
> > #include
> > @@ -1045,6 +1045,11 @@ ttm_pool_unpopulate_helper(struct ttm_tt *ttm,
> > unsigned mem_count_update)
> > ttm_put_pages(ttm->pages, ttm->num_pages, ttm->page_flags,
> > ttm->caching_state);
> > ttm->state = tt_unpopulated;
> > +
> > +#ifdef CONFIG_MEMCG
> > + if (ttm->memcg)
> > + mem_cgroup_uncharge_drvmem(ttm->memcg, ttm->num_pages);
> > +#endif
> > }
> >
> > int ttm_pool_populate(struct ttm_tt *ttm, struct ttm_operation_ctx *ctx)
> > @@ -1059,6 +1064,17 @@ int ttm_pool_populate(struct ttm_tt *ttm, struct
> > ttm_operation_ctx *ctx)
> > if (ttm_check_under_lowerlimit(mem_glob, ttm->num_pages, ctx))
> > return -ENOMEM;
> >
> > +#ifdef CONFIG_MEMCG
> > + if (ttm->memcg) {
> > + gfp_t gfp_flags = GFP_USER;
> > + if (ttm->page_flags & TTM_PAGE_FLAG_NO_RETRY)
> > + gfp_flags |= __GFP_RETRY_MAYFAIL;
> > + ret = mem_cgroup_charge_drvmem(ttm->memcg, gfp_flags,
> > ttm->num_pages);
> > +
Re: [PATCH v10 0/5] add driver for "boe, tv101wum-nl6", "boe, tv101wum-n53", "auo, kd101n80-45na" and "auo, b101uan08.3" panels
Hi Jitao. On Sun, Jan 19, 2020 at 09:45:36AM +0800, Jitao Shi wrote: > Changes since v9: > - remove Rob from maintainers in boe,tv101wum-nl6.yaml This series is already applied to drm-misc-next. I removed Rob from Maintainers while applying. Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
