Re: [PATCH v4 07/15] drm/bridge: tc358767: add drm_panel_bridge support
Hi Laurent.
Thanks for the prompt review.
On Mon, Jul 27, 2020 at 12:48:32AM +0300, Laurent Pinchart wrote:
> Hi Sam,
>
> Thank you for the patch.
>
> On Sun, Jul 26, 2020 at 10:33:16PM +0200, Sam Ravnborg wrote:
> > With the bridge operations implemented the last step to prepare
> > this driver for a chained setup is the use of the bridge panel driver.
> >
> > The bridge panel driver is only used when a prot@2 is present in
>
> s/prot/port/
>
> > the DT. So when the display driver request a connector
>
> s/request/requests/
>
> > support both situations:
> > - connector created by bridge panel driver
> > - connector created by this driver
> >
> > And on top, support that the display driver creates the connector,
> > which is the preferred setup.
> >
> > Note: the bridge panel will use the connector type from the panel.
> >
> > v2:
> > - Merge connector and drm_panel_bridge patches
> > and fix so we do not create two connectors (Laurent)
> >
> > Signed-off-by: Sam Ravnborg
> > Cc: Laurent Pinchart
> > Cc: Andrzej Hajda
> > Cc: Neil Armstrong
> > Cc: Jonas Karlman
> > Cc: Jernej Skrabec
> > ---
> > drivers/gpu/drm/bridge/tc358767.c | 70 +++
> > 1 file changed, 35 insertions(+), 35 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/bridge/tc358767.c
> > b/drivers/gpu/drm/bridge/tc358767.c
> > index d86d7f06bebb..75a2cd792ccc 100644
> > --- a/drivers/gpu/drm/bridge/tc358767.c
> > +++ b/drivers/gpu/drm/bridge/tc358767.c
> > @@ -244,8 +244,8 @@ struct tc_data {
> > struct drm_dp_aux aux;
> >
> > struct drm_bridge bridge;
> > + struct drm_bridge *panel_bridge;
> > struct drm_connectorconnector;
> > - struct drm_panel*panel;
> >
> > /* link settings */
> > struct tc_edp_link link;
> > @@ -1234,13 +1234,6 @@ static int tc_stream_disable(struct tc_data *tc)
> > return 0;
> > }
> >
> > -static void tc_bridge_pre_enable(struct drm_bridge *bridge)
> > -{
> > - struct tc_data *tc = bridge_to_tc(bridge);
> > -
> > - drm_panel_prepare(tc->panel);
> > -}
> > -
> > static void tc_bridge_enable(struct drm_bridge *bridge)
> > {
> > struct tc_data *tc = bridge_to_tc(bridge);
> > @@ -1264,8 +1257,6 @@ static void tc_bridge_enable(struct drm_bridge
> > *bridge)
> > tc_main_link_disable(tc);
> > return;
> > }
> > -
> > - drm_panel_enable(tc->panel);
> > }
> >
> > static void tc_bridge_disable(struct drm_bridge *bridge)
> > @@ -1273,8 +1264,6 @@ static void tc_bridge_disable(struct drm_bridge
> > *bridge)
> > struct tc_data *tc = bridge_to_tc(bridge);
> > int ret;
> >
> > - drm_panel_disable(tc->panel);
> > -
> > ret = tc_stream_disable(tc);
> > if (ret < 0)
> > dev_err(tc->dev, "main link stream stop error: %d\n", ret);
> > @@ -1284,13 +1273,6 @@ static void tc_bridge_disable(struct drm_bridge
> > *bridge)
> > dev_err(tc->dev, "main link disable error: %d\n", ret);
> > }
> >
> > -static void tc_bridge_post_disable(struct drm_bridge *bridge)
> > -{
> > - struct tc_data *tc = bridge_to_tc(bridge);
> > -
> > - drm_panel_unprepare(tc->panel);
> > -}
> > -
> > static bool tc_bridge_mode_fixup(struct drm_bridge *bridge,
> > const struct drm_display_mode *mode,
> > struct drm_display_mode *adj)
> > @@ -1354,9 +1336,11 @@ static int tc_connector_get_modes(struct
> > drm_connector *connector)
> > return 0;
> > }
> >
> > - num_modes = drm_panel_get_modes(tc->panel, connector);
> > - if (num_modes > 0)
> > - return num_modes;
> > + if (tc->panel_bridge) {
> > + num_modes = drm_bridge_get_modes(tc->panel_bridge, connector);
> > + if (num_modes > 0)
> > + return num_modes;
> > + }
> >
> > edid = tc_get_edid(&tc->bridge, connector);
> > num_modes = drm_add_edid_modes(connector, edid);
> > @@ -1396,7 +1380,7 @@ tc_connector_detect(struct drm_connector *connector,
> > bool force)
> > if (tc->hpd_pin >= 0)
> > return tc_bridge_detect(&tc->bridge);
> > else
> > - if (tc->panel)
> > + if (tc->panel_bridge)
> > return connector_status_connected;
> >
> > return connector_status_unknown;
> > @@ -1419,16 +1403,23 @@ static int tc_bridge_attach(struct drm_bridge
> > *bridge,
> > struct drm_device *drm = bridge->dev;
> > int ret;
> >
> > - if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR) {
> > - DRM_ERROR("Fix bridge driver to make connector optional!");
> > - return -EINVAL;
> > + if (tc->panel_bridge) {
> > + enum drm_bridge_attach_flags panel_flags;
> > +
> > + /* If a connector is required then this driver shall create it
> > */
> > + panel_flags = flags & ~DRM_BRIDGE_ATTACH_NO_CONNECTOR;
>
> Shouldn't this be
>
> panel_flags = flags | DRM_BRIDGE_
Re: [PATCH 1/2] drm/fourcc: fix Amlogic Video Framebuffer Compression macro
On 26/07/2020 19:25, Sam Ravnborg wrote:
> Hi Neil.
>
> On Thu, Jul 23, 2020 at 11:05:50AM +0200, Neil Armstrong wrote:
>> Fix the Amlogic Video Framebuffer Compression modifier macro to
>> correctly add the layout options, a pair of parenthesis was missing.
>>
>> Fixes: d6528ec88309 ("drm/fourcc: Add modifier definitions for describing
>> Amlogic Video Framebuffer Compression")
>> Signed-off-by: Neil Armstrong
> Looks correct just looking at the patch below.
> Acked-by: Sam Ravnborg
>
> I assume you will apply the patch.
Yes, indeed
Thanks !
Neil
>
> Sam
>
>> ---
>> include/uapi/drm/drm_fourcc.h | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
>> index 4bee7de5f306..82f327801267 100644
>> --- a/include/uapi/drm/drm_fourcc.h
>> +++ b/include/uapi/drm/drm_fourcc.h
>> @@ -1004,7 +1004,7 @@ drm_fourcc_canonicalize_nvidia_format_mod(__u64
>> modifier)
>> #define DRM_FORMAT_MOD_AMLOGIC_FBC(__layout, __options) \
>> fourcc_mod_code(AMLOGIC, \
>> ((__layout) & __fourcc_mod_amlogic_layout_mask) | \
>> -((__options) & __fourcc_mod_amlogic_options_mask \
>> +(((__options) & __fourcc_mod_amlogic_options_mask) \
>> << __fourcc_mod_amlogic_options_shift))
>>
>> /* Amlogic FBC Layouts */
>> --
>> 2.22.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 2/3] drm/ast: Store image size in HW cursor info
Store the image size as part of the HW cursor info, so that the
cursor show function doesn't require the information from the
caller. No functional changes.
Signed-off-by: Thomas Zimmermann
Fixes: 4961eb60f145 ("drm/ast: Enable atomic modesetting")
Cc: Thomas Zimmermann
Cc: Gerd Hoffmann
Cc: Dave Airlie
Cc: Daniel Vetter
Cc: Sam Ravnborg
Cc: Emil Velikov
Cc: "Y.C. Chen"
Cc: # v5.6+
---
drivers/gpu/drm/ast/ast_cursor.c | 13 +++--
drivers/gpu/drm/ast/ast_drv.h| 7 +--
drivers/gpu/drm/ast/ast_mode.c | 8 +---
3 files changed, 17 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_cursor.c b/drivers/gpu/drm/ast/ast_cursor.c
index acf0d23514e8..8642a0ce9da6 100644
--- a/drivers/gpu/drm/ast/ast_cursor.c
+++ b/drivers/gpu/drm/ast/ast_cursor.c
@@ -87,6 +87,8 @@ int ast_cursor_init(struct ast_private *ast)
ast->cursor.gbo[i] = gbo;
ast->cursor.vaddr[i] = vaddr;
+ ast->cursor.size[i].width = 0;
+ ast->cursor.size[i].height = 0;
}
return drmm_add_action_or_reset(dev, ast_cursor_release, NULL);
@@ -194,6 +196,9 @@ int ast_cursor_blit(struct ast_private *ast, struct
drm_framebuffer *fb)
/* do data transfer to cursor BO */
update_cursor_image(dst, src, fb->width, fb->height);
+ ast->cursor.size[ast->cursor.next_index].width = fb->width;
+ ast->cursor.size[ast->cursor.next_index].height = fb->height;
+
drm_gem_vram_vunmap(gbo, src);
drm_gem_vram_unpin(gbo);
@@ -249,14 +254,18 @@ static void ast_cursor_set_location(struct ast_private
*ast, u16 x, u16 y,
ast_set_index_reg(ast, AST_IO_CRTC_PORT, 0xc7, y1);
}
-void ast_cursor_show(struct ast_private *ast, int x, int y,
-unsigned int offset_x, unsigned int offset_y)
+void ast_cursor_show(struct ast_private *ast, int x, int y)
{
+ unsigned int offset_x, offset_y;
u8 x_offset, y_offset;
u8 __iomem *dst, __iomem *sig;
u8 jreg;
dst = ast->cursor.vaddr[ast->cursor.next_index];
+ offset_x = AST_MAX_HWC_WIDTH -
+ ast->cursor.size[ast->cursor.next_index].width;
+ offset_y = AST_MAX_HWC_HEIGHT -
+ ast->cursor.size[ast->cursor.next_index].height;
sig = dst + AST_HWC_SIZE;
writel(x, sig + AST_HWC_SIGNATURE_X);
diff --git a/drivers/gpu/drm/ast/ast_drv.h b/drivers/gpu/drm/ast/ast_drv.h
index e3a264ac7ee2..57414b429db3 100644
--- a/drivers/gpu/drm/ast/ast_drv.h
+++ b/drivers/gpu/drm/ast/ast_drv.h
@@ -116,6 +116,10 @@ struct ast_private {
struct {
struct drm_gem_vram_object *gbo[AST_DEFAULT_HWC_NUM];
void __iomem *vaddr[AST_DEFAULT_HWC_NUM];
+ struct {
+ unsigned int width;
+ unsigned int height;
+ } size[AST_DEFAULT_HWC_NUM];
unsigned int next_index;
} cursor;
@@ -311,8 +315,7 @@ void ast_release_firmware(struct drm_device *dev);
int ast_cursor_init(struct ast_private *ast);
int ast_cursor_blit(struct ast_private *ast, struct drm_framebuffer *fb);
void ast_cursor_page_flip(struct ast_private *ast);
-void ast_cursor_show(struct ast_private *ast, int x, int y,
-unsigned int offset_x, unsigned int offset_y);
+void ast_cursor_show(struct ast_private *ast, int x, int y);
void ast_cursor_hide(struct ast_private *ast);
#endif
diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
index 3680a000b812..5b2b39c93033 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_mode.c
@@ -671,20 +671,14 @@ ast_cursor_plane_helper_atomic_update(struct drm_plane
*plane,
struct drm_plane_state *old_state)
{
struct drm_plane_state *state = plane->state;
- struct drm_framebuffer *fb = state->fb;
struct ast_private *ast = plane->dev->dev_private;
- unsigned int offset_x, offset_y;
-
- offset_x = AST_MAX_HWC_WIDTH - fb->width;
- offset_y = AST_MAX_HWC_WIDTH - fb->height;
if (state->fb != old_state->fb) {
/* A new cursor image was installed. */
ast_cursor_page_flip(ast);
}
- ast_cursor_show(ast, state->crtc_x, state->crtc_y,
- offset_x, offset_y);
+ ast_cursor_show(ast, state->crtc_x, state->crtc_y);
}
static void
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/3] drm/ast: Do full modeset if the primary plane's format changes
The atomic modesetting code tried to distinguish format changes from
full modesetting operations. In practice, this was buggy and the format
registers were often updated even for simple pageflips.
Instead do a full modeset if the primary plane changes formats. It's
just as rare as an actual mode change, so there will be no performance
penalty.
The patch also replaces a reference to drm_crtc_state.allow_modeset with
the correct call to drm_atomic_crtc_needs_modeset().
Signed-off-by: Thomas Zimmermann
Fixes: 4961eb60f145 ("drm/ast: Enable atomic modesetting")
Cc: Thomas Zimmermann
Cc: Gerd Hoffmann
Cc: Dave Airlie
Cc: Daniel Vetter
Cc: Sam Ravnborg
Cc: Emil Velikov
Cc: "Y.C. Chen"
Cc: # v5.6+
---
drivers/gpu/drm/ast/ast_mode.c | 23 ---
1 file changed, 16 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
index 154cd877d9d1..3680a000b812 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_mode.c
@@ -527,8 +527,8 @@ static const uint32_t ast_primary_plane_formats[] = {
static int ast_primary_plane_helper_atomic_check(struct drm_plane *plane,
struct drm_plane_state *state)
{
- struct drm_crtc_state *crtc_state;
- struct ast_crtc_state *ast_crtc_state;
+ struct drm_crtc_state *crtc_state, *old_crtc_state;
+ struct ast_crtc_state *ast_crtc_state, *old_ast_crtc_state;
int ret;
if (!state->crtc)
@@ -550,6 +550,15 @@ static int ast_primary_plane_helper_atomic_check(struct
drm_plane *plane,
ast_crtc_state->format = state->fb->format;
+ old_crtc_state = drm_atomic_get_old_crtc_state(state->state,
state->crtc);
+ if (!old_crtc_state)
+ return 0;
+ old_ast_crtc_state = to_ast_crtc_state(old_crtc_state);
+ if (!old_ast_crtc_state)
+ return 0;
+ if (ast_crtc_state->format != old_ast_crtc_state->format)
+ crtc_state->mode_changed = true;
+
return 0;
}
@@ -775,18 +784,18 @@ static void ast_crtc_helper_atomic_flush(struct drm_crtc
*crtc,
ast_state = to_ast_crtc_state(crtc->state);
- format = ast_state->format;
- if (!format)
+ if (!drm_atomic_crtc_needs_modeset(crtc->state))
return;
+ format = ast_state->format;
+ if (drm_WARN_ON_ONCE(dev, !format))
+ return; /* BUG: We didn't set format in primary check(). */
+
vbios_mode_info = &ast_state->vbios_mode_info;
ast_set_color_reg(ast, format);
ast_set_vbios_color_reg(ast, format, vbios_mode_info);
- if (!crtc->state->mode_changed)
- return;
-
adjusted_mode = &crtc->state->adjusted_mode;
ast_set_vbios_mode_reg(ast, adjusted_mode, vbios_mode_info);
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/3] drm/ast: Disable HW cursor when switching modes
Since converting the ast driver to atomic modesettting, modesetting occationally locks up the graphics hardware and turns the display permanently dark. This happens once or twice per 10 modeswitches. Investigation shows that the ast hardware presumably requires the HW cursor to be disabled while the modeswitch takes place. This patchset fixes the problem by disabling the HW cursor before programming the CRTC mode. After changing the mode, the HW cursor gets re-enabled if it was enabled before. Patches #1 and #2 simplify the modesetting and cursor code in preparation of the actual fix. Patch #3 adds the workaround. The CRTC's atomic_begin() helper disables an active HW cursor and atomic_flush() re-enables it. The process is transparent for userspace and the rest of the DRM code. For mere pageflip operations, nothing changes. Tested on AST2100 HW. The issue is not 100% reproducible, but does not show up after applying the patchset. I think the problem has been fixed. Thomas Zimmermann (3): drm/ast: Do full modeset if the primary plane's format changes drm/ast: Store image size in HW cursor info drm/ast: Disable cursor while switching display modes drivers/gpu/drm/ast/ast_cursor.c | 13 - drivers/gpu/drm/ast/ast_drv.h| 9 +++- drivers/gpu/drm/ast/ast_mode.c | 82 ++-- 3 files changed, 86 insertions(+), 18 deletions(-) -- 2.27.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/3] drm/ast: Disable cursor while switching display modes
The ast's HW cursor requires the primary plane and CRTC to display
at a correct mode and format. This is not the case while switching
display modes, which can lead to the screen turing permanently dark.
As a workaround, the ast driver now disables active HW cursors while
the mode switch takes place. It also synchronizes with the vertical
refresh to give HW cursor and primary plane some time to catch up on
each other.
Signed-off-by: Thomas Zimmermann
Fixes: 4961eb60f145 ("drm/ast: Enable atomic modesetting")
Cc: Thomas Zimmermann
Cc: Gerd Hoffmann
Cc: Dave Airlie
Cc: Daniel Vetter
Cc: Sam Ravnborg
Cc: Emil Velikov
Cc: "Y.C. Chen"
Cc: # v5.6+
---
drivers/gpu/drm/ast/ast_drv.h | 2 ++
drivers/gpu/drm/ast/ast_mode.c | 53 +-
2 files changed, 54 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ast/ast_drv.h b/drivers/gpu/drm/ast/ast_drv.h
index 57414b429db3..564670b5d2ee 100644
--- a/drivers/gpu/drm/ast/ast_drv.h
+++ b/drivers/gpu/drm/ast/ast_drv.h
@@ -162,6 +162,8 @@ void ast_driver_unload(struct drm_device *dev);
#define AST_IO_MM_OFFSET (0x380)
+#define AST_IO_VGAIR1_VREFRESH BIT(3)
+
#define __ast_read(x) \
static inline u##x ast_read##x(struct ast_private *ast, u32 reg) { \
u##x val = 0;\
diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
index 5b2b39c93033..e18365bbc08c 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_mode.c
@@ -514,6 +514,17 @@ static void ast_set_start_address_crt1(struct ast_private
*ast,
}
+static void ast_wait_for_vretrace(struct ast_private *ast)
+{
+ unsigned long timeout = jiffies + HZ;
+ u8 vgair1;
+
+ do {
+ vgair1 = ast_io_read8(ast, AST_IO_INPUT_STATUS1_READ);
+ } while (!(vgair1 & AST_IO_VGAIR1_VREFRESH) &&
+time_before(jiffies, timeout));
+}
+
/*
* Primary plane
*/
@@ -666,6 +677,14 @@ static int ast_cursor_plane_helper_atomic_check(struct
drm_plane *plane,
return 0;
}
+static bool ast_disable_cursor_during_modeset(struct drm_plane *cursor_plane)
+{
+ const struct drm_plane_state *cursor_state = cursor_plane->state;
+
+ return cursor_state && cursor_state->visible && cursor_state->crtc &&
+ drm_atomic_crtc_needs_modeset(cursor_state->crtc->state);
+}
+
static void
ast_cursor_plane_helper_atomic_update(struct drm_plane *plane,
struct drm_plane_state *old_state)
@@ -678,7 +697,12 @@ ast_cursor_plane_helper_atomic_update(struct drm_plane
*plane,
ast_cursor_page_flip(ast);
}
- ast_cursor_show(ast, state->crtc_x, state->crtc_y);
+ /*
+* For modesets, delay show() until end of atomic_flush(). See the
+* atomic_begin() helper for more information.
+*/
+ if (!ast_disable_cursor_during_modeset(plane))
+ ast_cursor_show(ast, state->crtc_x, state->crtc_y);
}
static void
@@ -764,6 +788,22 @@ static void ast_crtc_helper_atomic_begin(struct drm_crtc
*crtc,
struct ast_private *ast = to_ast_private(crtc->dev);
ast_open_key(ast);
+
+ /*
+* HW cursors require the underlying primary plane and CRTC to
+* display a valid mode and image. This is not the case during
+* full modeset operations. So we temporarily disable any active
+* HW cursor and re-enable it at the end of the atomic_flush()
+* helper. The busy waiting allows the code to sync with the
+* vertical refresh.
+*
+* We only do this during *full* modesets. It does not affect
+* simple pageflips on the planes.
+*/
+ if (ast_disable_cursor_during_modeset(&ast->cursor_plane)) {
+ ast_cursor_hide(ast);
+ ast_wait_for_vretrace(ast);
+ }
}
static void ast_crtc_helper_atomic_flush(struct drm_crtc *crtc,
@@ -771,6 +811,7 @@ static void ast_crtc_helper_atomic_flush(struct drm_crtc
*crtc,
{
struct drm_device *dev = crtc->dev;
struct ast_private *ast = to_ast_private(dev);
+ struct drm_plane_state *cursor_state = ast->cursor_plane.state;
struct ast_crtc_state *ast_state;
const struct drm_format_info *format;
struct ast_vbios_mode_info *vbios_mode_info;
@@ -799,6 +840,16 @@ static void ast_crtc_helper_atomic_flush(struct drm_crtc
*crtc,
ast_set_dclk_reg(ast, adjusted_mode, vbios_mode_info);
ast_set_crtthd_reg(ast);
ast_set_sync_reg(ast, adjusted_mode, vbios_mode_info);
+
+ /*
+* Re-enabling the HW cursor; if any. See the atomic_begin() helper
+* for more information.
+*/
+ if (ast_disable_cursor_during_modeset(&ast->cursor_plane)) {
+ ast_wait_for_vretrace(ast);
+ ast_cursor_show(ast, cursor_state->crtc_x,
+ cursor_state->crtc_y);
+ }
}
static void
--
2.27.0
_
Re: [PATCH v5 00/16] acpi/pwm/i915: Convert pwm-crc and i915 driver's PWM code to use the atomic PWM API
On Fri, Jul 17, 2020 at 03:37:37PM +0200, Hans de Goede wrote: > Hi All, > > Here is v5 of my patch series converting the i915 driver's code for > controlling the panel's backlight with an external PWM controller to > use the atomic PWM API. See below for the changelog. > > This series consists of 4 parts: > > 1. acpi_lpss fixes workarounds for Cherry Trail DSTD nastiness > 2. various fixes to the pwm-lpss driver > 3. convert the pwm-crc driver to support the atomic PWM API and > 4. convert the i915 driver's PWM code to use the atomic PWM API > > The involved acpi_lpss and pwm drivers do not see a whole lot of churn, > so the plan is to merge this all through drm-intel-next-queued (dinq) > once all the patches are reviewed / have acks. > > Specifically patches 5-9, 11 still need an Acked- / Reviewed-by > > Andy, can you please take a look at the unreviewed patches? Specifically > patches 5-6 should address your review remarks from v4 of this set > and I've addressed your review remarks on patches 7-9 in v3 already. > A review of patch 11 would also be welcome > > Uwe, can you please take a look at the unreviewed patches? > > Uwe, may I have your Acked-by for merging this series through the > drm-intel-next-queued branch once all PWM patches have an Acked- or > Reviewed-by ? > > This series has been tested (and re-tested after adding various bug-fixes) > extensively. It has been tested on the following devices: > > -Asus T100TA BYT + CRC-PMIC PWM > -Toshiba WT8-A BYT + CRC-PMIC PWM > -Thundersoft TS178 BYT + CRC-PMIC PWM, inverse PWM > -Asus T100HA CHT + CRC-PMIC PWM > -Terra Pad 1061 BYT + LPSS PWM > -Trekstor Twin 10.1 BYT + LPSS PWM > -Asus T101HA CHT + CRC-PMIC PWM > -GPD Pocket CHT + CRC-PMIC PWM > > Changelog: > Changes in v5: > - Dropped the "pwm: lpss: Correct get_state result for base_unit == 0" > patch. The base_unit == 0 condition should never happen and sofar it is > unclear what the proper behavior / correct values to store in the > pwm_state should be when this does happen. Since this patch was added as > an extra pwm-lpss fix in v4 of this patch-set and otherwise is orthogonal > to the of this patch-set just drop it (again). > - "[PATCH 04/16] pwm: lpss: Add range limit check for the base_unit register > value" > - Use clamp_val(... instead of clam_t(unsigned long long, ... > - "[PATCH 05/16] pwm: lpss: Add pwm_lpss_prepare_enable() helper" > - This is a new patch in v5 of this patchset > - [PATCH 06/16] pwm: lpss: Use pwm_lpss_apply() when restoring state on resume > - Use the new pwm_lpss_prepare_enable() helper > > Changes in v4: > - "[PATCH v4 06/16] pwm: lpss: Correct get_state result for base_unit == 0" > - This is a new patch in v4 of this patchset > - "[PATCH v4 12/16] pwm: crc: Implement get_state() method" > - Use DIV_ROUND_UP when calculating the period and duty_cycle values > - "[PATCH v4 16/16] drm/i915: panel: Use atomic PWM API for devs with an > external PWM controller" > - Add a note to the commit message about the changes in > pwm_disable_backlight() > - Use the pwm_set/get_relative_duty_cycle() helpers > > Changes in v3: > - "[PATCH v3 04/15] pwm: lpss: Add range limit check for the base_unit > register value" > - Use base_unit_range - 1 as maximum value for the clamp() > - "[PATCH v3 05/15] pwm: lpss: Use pwm_lpss_apply() when restoring state on > resume" > - This replaces the "pwm: lpss: Set SW_UPDATE bit when enabling the PWM" > patch from previous versions of this patch-set, which really was a hack > working around the resume issue which this patch fixes properly. > - PATCH v3 6 - 11 pwm-crc changes: > - Various small changes resulting from the reviews by Andy and Uwe, > including some refactoring of the patches to reduce the amount of churn > in the patch-set > > Changes in v2: > - Fix coverletter subject > - Drop accidentally included debugging patch > - "[PATCH v3 02/15] ACPI / LPSS: Save Cherry Trail PWM ctx registers only > once ( > - Move #define LPSS_SAVE_CTX_ONCE define to group it with LPSS_SAVE_CTX Hi Hans, I've applied patches 3 through 12 to the PWM tree. I thought it was a bit odd that only a handful of these patches had been reviewed and there were no Tested-bys, but I'm going to trust that you know what you're doing. =) If this breaks things for anyone I'm sure they'll complain. That said I see that Rafael has acked patches 1-2 and Jani did so for patches 13-16. I'm not sure if you expect me to pick those patches up as well. As far as I can tell the ACPI, PWM and DRM parts are all independent, so these patches could be applied to the corresponding subsystem trees. Anyway, if you want me to pick those all up into the PWM tree, I suppose that's something I can do as well. Thierry signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 2/2] drm: panel: Add tianma nt36672a panel driver
Some Poco F1 phones have an LCD panel from Tianma, model nt36672a,
with a resolution of 1080x2246 that operates in DSI video mode.
Add the drm panel driver for it.
During testing, Benni Steini helped us fix
the reset sequence timing (from 10ms to 20ms), to get the bootanimation
to work on Android.
With current AOSP, we need to increase it to 200ms - this seems to be a
safe high value to avoid a white screen occasionally.
Signed-off-by: Sumit Semwal
Cc: Benni Steini
---
v2: increase reset sequence timing to a safe 200ms
---
MAINTAINERS | 7 +
drivers/gpu/drm/panel/Kconfig | 11 +
drivers/gpu/drm/panel/Makefile| 1 +
drivers/gpu/drm/panel/panel-tianma-nt36672a.c | 859 ++
4 files changed, 878 insertions(+)
create mode 100644 drivers/gpu/drm/panel/panel-tianma-nt36672a.c
diff --git a/MAINTAINERS b/MAINTAINERS
index b4a43a9e7fbc..2d384e51353b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5544,6 +5544,13 @@ T: git git://anongit.freedesktop.org/drm/drm-misc
F: Documentation/devicetree/bindings/display/ste,mcde.txt
F: drivers/gpu/drm/mcde/
+DRM DRIVER FOR TIANMA NT36672A PANELS
+M: Sumit Semwal
+S: Maintained
+T: git git://anongit.freedesktop.org/drm/drm-misc
+F:
Documentation/devicetree/bindings/display/panel/tianma,nt36672a-panel.yaml
+F: drivers/gpu/drm/panel/panel-tianma-nt36672a.c
+
DRM DRIVER FOR TDFX VIDEO CARDS
S: Orphan / Obsolete
F: drivers/gpu/drm/tdfx/
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 39055c1f0e2f..da9d74c1ec91 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -437,6 +437,17 @@ config DRM_PANEL_TPO_TD043MTEA1
Say Y here if you want to enable support for TPO TD043MTEA1 800x480
4.3" panel (found on the OMAP3 Pandora board).
+config DRM_PANEL_TIANMA_FHD_NT36672A
+ tristate "TIANMA NT36672A panel"
+ depends on OF
+ depends on DRM_MIPI_DSI
+ depends on BACKLIGHT_CLASS_DEVICE
+ help
+ Say Y here if you want to enable support for the Tianma NT36672A
+ panel. It is seen mostly in Xiaomi Poco F1 mobile phone.
+ The panel has a 1080x2246 resolution and uses 24 bit RGB per pixel.
+ It provides a MIPI DSI interface to the host.
+
config DRM_PANEL_TPO_TPG110
tristate "TPO TPG 800x400 panel"
depends on OF && SPI && GPIOLIB
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index de74f282c433..303e44eb50fa 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -44,6 +44,7 @@ obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7701) +=
panel-sitronix-st7701.o
obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7789V) += panel-sitronix-st7789v.o
obj-$(CONFIG_DRM_PANEL_SONY_ACX424AKP) += panel-sony-acx424akp.o
obj-$(CONFIG_DRM_PANEL_SONY_ACX565AKM) += panel-sony-acx565akm.o
+obj-$(CONFIG_DRM_PANEL_TIANMA_FHD_NT36672A) += panel-tianma-nt36672a.o
obj-$(CONFIG_DRM_PANEL_TPO_TD028TTEC1) += panel-tpo-td028ttec1.o
obj-$(CONFIG_DRM_PANEL_TPO_TD043MTEA1) += panel-tpo-td043mtea1.o
obj-$(CONFIG_DRM_PANEL_TPO_TPG110) += panel-tpo-tpg110.o
diff --git a/drivers/gpu/drm/panel/panel-tianma-nt36672a.c
b/drivers/gpu/drm/panel/panel-tianma-nt36672a.c
new file mode 100644
index ..07e8461b8893
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-tianma-nt36672a.c
@@ -0,0 +1,859 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2020 Linaro Ltd
+ * Author: Sumit Semwal
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+struct panel_cmd {
+ size_t len;
+ const char *data;
+};
+
+#define _INIT_CMD(...) { \
+ .len = sizeof((char[]){__VA_ARGS__}), \
+ .data = (char[]){__VA_ARGS__} }
+
+static const char * const regulator_names[] = {
+ "vddio",
+ "vddpos",
+ "vddneg",
+};
+
+static unsigned long const regulator_enable_loads[] = {
+ 62000,
+ 10,
+ 10
+};
+
+static unsigned long const regulator_disable_loads[] = {
+ 80,
+ 100,
+ 100
+};
+
+struct panel_desc {
+ const struct drm_display_mode *display_mode;
+ const char *panel_name;
+
+ unsigned int width_mm;
+ unsigned int height_mm;
+
+ unsigned long mode_flags;
+ enum mipi_dsi_pixel_format format;
+ unsigned int lanes;
+
+ const struct panel_cmd *on_cmds_1;
+ const struct panel_cmd *on_cmds_2;
+
+ const struct panel_cmd *off_cmds;
+};
+
+struct panel_info {
+ struct drm_panel base;
+ struct mipi_dsi_device *link;
+ const struct panel_desc *desc;
+
+ struct regulator_bulk_data supplies[ARRAY_SIZE(regulator_names)];
+
+ struct gpio_desc *reset_gpio;
+
+ struct pinctrl *pinctrl;
+ struct pinctrl_state *active;
+ struct p
[PATCH v3 1/2] dt-bindings: display: panel: Add bindings for Tianma nt36672a panel
The nt36672a panel from Tianma is a FHD+ panel with a resolution of
1080x2246 and 6.18 inches size. It is found in some of the Poco F1
phones.
Signed-off-by: Sumit Semwal
---
v2: remove ports node, making port@0 directly under panel@0 node.
v3: updated to replace port@0 to just 'port'.
---
.../display/panel/tianma,nt36672a.yaml| 95 +++
1 file changed, 95 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/tianma,nt36672a.yaml
diff --git
a/Documentation/devicetree/bindings/display/panel/tianma,nt36672a.yaml
b/Documentation/devicetree/bindings/display/panel/tianma,nt36672a.yaml
new file mode 100644
index ..03dc323332a5
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/tianma,nt36672a.yaml
@@ -0,0 +1,95 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/tianma,nt36672a.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Tianma model NT36672A DSI Panel display driver
+
+maintainers:
+ - Sumit Semwal
+
+description: |
+ The nt36672a panel from Tianma is a FHD+ LCD display panel with a resolution
+ of 1080x2246. It is a video mode DSI panel.
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+const: tianma,nt36672a
+
+ reg:
+description: DSI virtual channel of the peripheral
+
+ reset-gpios:
+description: phandle of gpio for reset line - This should be 8mA, gpio
+ can be configured using mux, pinctrl, pinctrl-names (active high)
+
+ vddio-supply:
+description: phandle of the regulator that provides the supply voltage
+ Power IC supply
+
+ vddpos-supply:
+description: phandle of the positive boost supply regulator
+
+ vddneg-supply:
+description: phandle of the negative boost supply regulator
+
+ pinctrl-names:
+description: Pinctrl for panel active and suspend
+
+ pinctrl-0:
+description: Active pinctrls
+
+ pinctrl-1:
+description: Suspend pinctrls
+
+ port: true
+
+required:
+ - compatible
+ - reg
+ - vddi0-supply
+ - vddpos-supply
+ - vddneg-supply
+ - reset-gpios
+ - pinctrl-names
+ - pinctrl-0
+ - pinctrl-1
+ - port
+
+unevaluatedProperties: false
+
+examples:
+ - |+
+#include
+dsi0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ panel@0 {
+compatible = "tianma,nt36672a";
+reg = <0>;
+vddi0-supply = <&vreg_l14a_1p88>;
+vddpos-supply = <&lab>;
+vddneg-supply = <&ibb>;
+
+reset-gpios = <&tlmm 6 GPIO_ACTIVE_HIGH>;
+
+pinctrl-names = "panel_active", "panel_suspend";
+pinctrl-0 = <&sde_dsi_active>;
+pinctrl-1 = <&sde_dsi_suspend>;
+
+#address-cells = <1>;
+#size-cells = <0>;
+port {
+ tianma_nt36672a_in_0: endpoint {
+remote-endpoint = <&dsi0_out>;
+ };
+};
+ };
+};
+
+...
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 0/2] Add support for Tianma nt36672a video mode panel
Some Poco F1 phones from Xiaomi have an nt36672a video mode panel; add support for the same. Most of the panel data is taken from downstream panel dts, and is converted to drm-panel based driver by me. It has been validated with v5.8-rc5 on Poco F1 phone; my tree with other dependent patches is here [1] [1]: https://git.linaro.org/people/sumit.semwal/linux-dev.git/log/?h=dev/poco-panel-upstreaming --- v2: In dt-binding, removed ports node, making port@0 directly under panel@0 node. Also updated the panel_on delay to a safer 200ms as needed for latest Android. v3: Replaced port@0 with just port in panel@0 node. [1]: Sumit Semwal (2): dt-bindings: display: panel: Add bindings for Tianma nt36672a panel drm: panel: Add tianma nt36672a panel driver .../display/panel/tianma,nt36672a.yaml| 95 ++ MAINTAINERS | 7 + drivers/gpu/drm/panel/Kconfig | 11 + drivers/gpu/drm/panel/Makefile| 1 + drivers/gpu/drm/panel/panel-tianma-nt36672a.c | 859 ++ 5 files changed, 973 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/tianma,nt36672a.yaml create mode 100644 drivers/gpu/drm/panel/panel-tianma-nt36672a.c -- 2.27.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 11/22] drm: mxsfb: Stop using DRM simple display pipeline helper
On 2020-07-26 20:28, Laurent Pinchart wrote:
> Hi Stefan,
>
> On Fri, Jul 17, 2020 at 05:06:55AM +0300, Laurent Pinchart wrote:
>> On Thu, Jul 09, 2020 at 12:25:42PM +0200, Stefan Agner wrote:
>> > On 2020-06-16 03:50, Laurent Pinchart wrote:
>> >> On Thu, Jun 11, 2020 at 09:33:11PM +0200, Stefan Agner wrote:
>> >>> On 2020-05-30 05:10, Laurent Pinchart wrote:
>> The DRM simple display pipeline helper only supports a single plane. In
>> order to prepare for support of the alpha plane on i.MX6SX and i.MX7,
>> move away from the helper. No new feature is added.
>>
>> Signed-off-by: Laurent Pinchart
>> ---
>> Changes since v1:
>>
>> - Move after mxsfb_crtc.c rename to mxsfb_kms.c
>> ---
>> drivers/gpu/drm/mxsfb/mxsfb_drv.c | 108 +++---
>> drivers/gpu/drm/mxsfb/mxsfb_drv.h | 23 ++--
>> drivers/gpu/drm/mxsfb/mxsfb_kms.c | 184 +++---
>> 3 files changed, 197 insertions(+), 118 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
>> b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
>> index 204c1e52e9aa..a8da92976d13 100644
>> --- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
>> +++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
>> @@ -10,22 +10,23 @@
>>
>> #include
>> #include
>> +#include
>> #include
>> #include
>> +#include
>> #include
>> -#include
>>
>> -#include
>> #include
>> -#include
>> +#include
>> +#include
>> #include
>> #include
>> #include
>> #include
>> #include
>> +#include
>> #include
>> #include
>> -#include
>> #include
>>
>> #include "mxsfb_drv.h"
>> @@ -57,17 +58,6 @@ static const struct mxsfb_devdata mxsfb_devdata[] = {
>> },
>> };
>>
>> -static const uint32_t mxsfb_formats[] = {
>> - DRM_FORMAT_XRGB,
>> - DRM_FORMAT_RGB565
>> -};
>> -
>> -static struct mxsfb_drm_private *
>> -drm_pipe_to_mxsfb_drm_private(struct drm_simple_display_pipe *pipe)
>> -{
>> - return container_of(pipe, struct mxsfb_drm_private, pipe);
>> -}
>> -
>> void mxsfb_enable_axi_clk(struct mxsfb_drm_private *mxsfb)
>> {
>> if (mxsfb->clk_axi)
>> @@ -90,77 +80,6 @@ static const struct drm_mode_config_helper_funcs
>> mxsfb_mode_config_helpers = {
>> .atomic_commit_tail = drm_atomic_helper_commit_tail_rpm,
>> };
>>
>> -static void mxsfb_pipe_enable(struct drm_simple_display_pipe *pipe,
>> - struct drm_crtc_state *crtc_state,
>> - struct drm_plane_state *plane_state)
>> -{
>> - struct mxsfb_drm_private *mxsfb =
>> drm_pipe_to_mxsfb_drm_private(pipe);
>> - struct drm_device *drm = pipe->plane.dev;
>> -
>> - pm_runtime_get_sync(drm->dev);
>> - mxsfb_crtc_enable(mxsfb);
>> -}
>> -
>> -static void mxsfb_pipe_disable(struct drm_simple_display_pipe *pipe)
>> -{
>> - struct mxsfb_drm_private *mxsfb =
>> drm_pipe_to_mxsfb_drm_private(pipe);
>> - struct drm_device *drm = pipe->plane.dev;
>> - struct drm_crtc *crtc = &pipe->crtc;
>> - struct drm_pending_vblank_event *event;
>> -
>> - mxsfb_crtc_disable(mxsfb);
>> - pm_runtime_put_sync(drm->dev);
>> -
>> - spin_lock_irq(&drm->event_lock);
>> - event = crtc->state->event;
>> - if (event) {
>> - crtc->state->event = NULL;
>> - drm_crtc_send_vblank_event(crtc, event);
>> - }
>> - spin_unlock_irq(&drm->event_lock);
>> -}
>> -
>> -static void mxsfb_pipe_update(struct drm_simple_display_pipe *pipe,
>> - struct drm_plane_state *plane_state)
>> -{
>> - struct mxsfb_drm_private *mxsfb =
>> drm_pipe_to_mxsfb_drm_private(pipe);
>> -
>> - mxsfb_plane_atomic_update(mxsfb, plane_state);
>> -}
>> -
>> -static int mxsfb_pipe_enable_vblank(struct drm_simple_display_pipe
>> *pipe)
>> -{
>> - struct mxsfb_drm_private *mxsfb =
>> drm_pipe_to_mxsfb_drm_private(pipe);
>> -
>> - /* Clear and enable VBLANK IRQ */
>> - mxsfb_enable_axi_clk(mxsfb);
>> - writel(CTRL1_CUR_FRAME_DONE_IRQ, mxsfb->base + LCDC_CTRL1 +
>> REG_CLR);
>> - writel(CTRL1_CUR_FRAME_DONE_IRQ_EN, mxsfb->base + LCDC_CTRL1 +
>> REG_SET);
>> - mxsfb_disable_axi_clk(mxsfb);
>> -
>> - return 0;
>> -}
>> -
>> -static void mxsfb_pipe_disable_vblank(struct drm_simple_display_pipe
>> *pipe)
>> -{
>> - struct mxsfb_drm_private *mxsfb
Re: [PATCH v2 4/4] xen: add helpers to allocate unpopulated memory
On 24.07.20 18:36, Boris Ostrovsky wrote:
> On 7/24/20 10:34 AM, David Hildenbrand wrote:
>> CCing Dan
>>
>> On 24.07.20 14:42, Roger Pau Monne wrote:
>>> diff --git a/drivers/xen/unpopulated-alloc.c
>>> b/drivers/xen/unpopulated-alloc.c
>>> new file mode 100644
>>> index ..aaa91cefbbf9
>>> --- /dev/null
>>> +++ b/drivers/xen/unpopulated-alloc.c
>>> @@ -0,0 +1,222 @@
>
>
>
>>> + */
>>> +
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +
>>> +#include
>>> +
>>> +#include
>>> +#include
>>> +
>>> +static DEFINE_MUTEX(lock);
>>> +static LIST_HEAD(list);
>>> +static unsigned int count;
>>> +
>>> +static int fill(unsigned int nr_pages)
>
>
> Less generic names? How about list_lock, pg_list, pg_count,
> fill_pglist()? (But these are bad too, so maybe you can come up with
> something better)
>
>
>>> +{
>>> + struct dev_pagemap *pgmap;
>>> + void *vaddr;
>>> + unsigned int i, alloc_pages = round_up(nr_pages, PAGES_PER_SECTION);
>>> + int nid, ret;
>>> +
>>> + pgmap = kzalloc(sizeof(*pgmap), GFP_KERNEL);
>>> + if (!pgmap)
>>> + return -ENOMEM;
>>> +
>>> + pgmap->type = MEMORY_DEVICE_DEVDAX;
>>> + pgmap->res.name = "XEN SCRATCH";
>
>
> Typically iomem resources only capitalize first letters.
>
>
>>> + pgmap->res.flags = IORESOURCE_MEM | IORESOURCE_BUSY;
>>> +
>>> + ret = allocate_resource(&iomem_resource, &pgmap->res,
>>> + alloc_pages * PAGE_SIZE, 0, -1,
>>> + PAGES_PER_SECTION * PAGE_SIZE, NULL, NULL);
>
>
> Are we not going to end up with a whole bunch of "Xen scratch" resource
> ranges for each miss in the page list? Or do we expect them to get merged?
>
AFAIK, no resources will get merged (and it's in the general case not
safe to do). The old approach (add_memory_resource()) will end up with
the same situation ("Xen Scratch" vs. "System RAM") one new resource per
added memory block/section.
FWIW, I am looking into merging selected resources in the context of
virtio-mem _after_ adding succeeded (not directly when adding the
resource to the tree). Interface might look something like
void merge_child_mem_resources(struct resource *parent, const char *name);
So I can, for example, trigger merging of all "System RAM (virtio_mem)"
resources, that are located under a device node (e.g., "virtio0").
I also thought about tagging each mergeable resource via something like
"IORESOURCE_MERGEABLE" - whereby the user agrees that it does not hold
any pointers to such a resource. But I don't see yet a copelling reason
to sacrifice space for a new flag.
So with this in place, this code could call once adding succeeded
merge_child_mem_resources(&iomem_resource, "Xen Scratch");
--
Thanks,
David / dhildenb
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/drm_fb_helper: fix fbdev with sparc64
On Sat, Jul 25, 2020 at 9:10 PM Sam Ravnborg wrote:
>
> From 1323a7433691aee112a9b2df8041b5024895a77e Mon Sep 17 00:00:00 2001
> From: Sam Ravnborg
> Date: Thu, 9 Jul 2020 21:30:16 +0200
> Subject: [PATCH v2 1/1] drm/drm_fb_helper: fix fbdev with sparc64
>
> Recent kernels have been reported to panic using the bochs_drm framebuffer
> under
> qemu-system-sparc64 which was bisected to commit 7a0483ac4ffc "drm/bochs:
> switch to
> generic drm fbdev emulation". The backtrace indicates that the shadow
> framebuffer
> copy in drm_fb_helper_dirty_blit_real() is trying to access the real
> framebuffer
> using a virtual address rather than use an IO access typically implemented
> using a
> physical (ASI_PHYS) access on SPARC.
>
> The fix is to replace the memcpy with memcpy_toio() from io.h.
>
> memcpy_toio() uses writeb() where the original fbdev code
> used sbus_memcpy_toio(). The latter uses sbus_writeb().
>
> The difference between writeb() and sbus_memcpy_toio() is
> that writeb() writes bytes in little-endian, where sbus_writeb() writes
> bytes in big-endian. As endian does not matter for byte writes they are
> the same. So we can safely use memcpy_toio() here.
>
> For many architectures memcpy_toio() is a simple memcpy().
> One side-effect that is unknown is if this has any impact on other
> architectures.
> So far the analysis tells that this change is OK for other arch's.
> but testing would be good.
The rules are that officially we have to use the io functions for
__mmio pointers. We just drop these sparse annotations on the floor.
I'd replace this with something like:
"Note that this only fixes bochs, in general fbdev helpers still have
issues with mixing up system memory and mmio space. Fixing that will
require a lot more work."
> v2:
> - Added missing __iomem cast (kernel test robot)
> - Made changelog readable and fix typos (Mark)
> - Add flag to select iomem - and set it in the bochs driver
>
> Signed-off-by: Sam Ravnborg
> Reported-by: Mark Cave-Ayland
> Reported-by: kernel test robot
> Tested-by: Mark Cave-Ayland
> Cc: Mark Cave-Ayland
> Cc: Thomas Zimmermann
> Cc: Gerd Hoffmann
> Cc: "David S. Miller"
> Cc: sparcli...@vger.kernel.org
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20200709193016.291267-1-...@ravnborg.org
> ---
>
> This fix introducing a flag in mode_config is at best a band-aid
> solution until we have a proper fix.
> We need to propagate the info about iomem so it is not a driver flag
> thing.
>
> There is also the issue with sys* versus cfb* functions, where cfb*
> functions are used for iomem.
> I did not manage to make the bochs driver work with the cfb* functions,
> for some unknown reason booting would be stuck waiting for the console
> mutex when usign the cfb* functions.
>
> I consider this fix OK to get the kernel working for sparc64 with the
> bochs driver for now. And with the fbdev_uses_iomem flag no other
> drivers will see any changes.
>
> Sam
>
> drivers/gpu/drm/bochs/bochs_kms.c | 1 +
> drivers/gpu/drm/drm_fb_helper.c | 6 +-
> include/drm/drm_mode_config.h | 9 +
> 3 files changed, 15 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/bochs/bochs_kms.c
> b/drivers/gpu/drm/bochs/bochs_kms.c
> index 05d8373888e8..079f46f5cdb6 100644
> --- a/drivers/gpu/drm/bochs/bochs_kms.c
> +++ b/drivers/gpu/drm/bochs/bochs_kms.c
> @@ -146,6 +146,7 @@ int bochs_kms_init(struct bochs_device *bochs)
> bochs->dev->mode_config.preferred_depth = 24;
> bochs->dev->mode_config.prefer_shadow = 0;
> bochs->dev->mode_config.prefer_shadow_fbdev = 1;
> + bochs->dev->mode_config.fbdev_use_iomem = true;
> bochs->dev->mode_config.quirk_addfb_prefer_host_byte_order = true;
>
> bochs->dev->mode_config.funcs = &bochs_mode_funcs;
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 5609e164805f..89cfd68ef400 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -399,7 +399,11 @@ static void drm_fb_helper_dirty_blit_real(struct
> drm_fb_helper *fb_helper,
> unsigned int y;
>
> for (y = clip->y1; y < clip->y2; y++) {
> - memcpy(dst, src, len);
> + if (!fb_helper->dev->mode_config.fbdev_use_iomem)
> + memcpy(dst, src, len);
> + else
> + memcpy_toio((void __iomem *)dst, src, len);
> +
> src += fb->pitches[0];
> dst += fb->pitches[0];
> }
> diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
> index 6c3ef49b46b3..c24c066bdd9c 100644
> --- a/include/drm/drm_mode_config.h
> +++ b/include/drm/drm_mode_config.h
> @@ -865,6 +865,15 @@ struct drm_mode_config {
> */
> bool prefer_shadow_fbdev;
>
> + /**
> +* @fbdev_use_iomem:
> +*
> +* Set to true if framebuffer reside in iomem.
> +* When set to true memc
Re: [PATCH] video: fbdev: added driver for sharp memory lcd displays
On Sun, Jul 26, 2020 at 7:22 PM Sam Ravnborg wrote:
>
> Hi Rodrigo.
>
> On Fri, Jul 24, 2020 at 05:34:04PM -0300, Rodrigo Alencar wrote:
> > The supported displays are ls027b7dh01 (tested), ls044q7dh01,
> > ls013b7dh05, ls013b7dh03
> >
> > Signed-off-by: Rodrigo Alencar <455.rodrigo.alen...@gmail.com>
>
> Thanks for submitting this driver.
> Unfortunately I have some bad news for you...
>
> The binding needs to be submitted as a seperate patch, and all new
> bindings must use the DT schema format (.yaml files).
> See Documentation/devicetree/bindings/*.rst for more info.
>
> And on top of this fbdev/ is in maintenance mode so no new drivers.
> New display drivers and panel drivers must go to gpu/drm/
> and use the frameworks available there.
>
> It looks like what we have here is a panel driver.
> Look for other similar sharp panels in drm/panel/ to get an idea how to
> add support for these new panels.
Since it's directly used, probably drm/tiny since we haven't yet
unified panel (used by other drm_device drivers) and tiny (stand-alone
drivers for simple panels).
-Daniel
>
> Soory, but looks forward for an updated patch.
>
> Sam
>
>
> > ---
> > .../devicetree/bindings/display/smemlcdfb.txt | 46 ++
> > drivers/video/fbdev/Kconfig | 14 +
> > drivers/video/fbdev/Makefile | 1 +
> > drivers/video/fbdev/smemlcdfb.c | 485 ++
> > 4 files changed, 546 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/display/smemlcdfb.txt
> > create mode 100644 drivers/video/fbdev/smemlcdfb.c
> >
> > diff --git a/Documentation/devicetree/bindings/display/smemlcdfb.txt
> > b/Documentation/devicetree/bindings/display/smemlcdfb.txt
> > new file mode 100644
> > index ..e33025dd3374
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/smemlcdfb.txt
> > @@ -0,0 +1,46 @@
> > +Sharp Memory LCD Linux Framebuffer Driver
> > +
> > +Required properties:
> > + - compatible: It should be "sharp,". The supported displays are
> > + ls027b7dh01, ls044q7dh01, ls013b7dh05, ls013b7dh03. Maybe other
> > + monochromatic models can be supported with the current code.
> > + - reg: SPI chip select number for the device.
> > + - spi-max-frequency: Max SPI frequency to use. One must verify the
> > datasheet.
> > + - spi-cs-high: Sharp Memory LCD needs chipselect high.
> > +
> > +Optional properties:
> > + - sharp,frames-per-sec: It should contain the desired frames per second.
> > + It does not represent the actual frame rate. Default: 10
> > + - sharp,extmode-high: External COM Input signal is expected in EXTCOMIN
> > port.
> > + This is recommended to reduce CPU and SPI Load.
> > + - pwm: If property "sharp,extmode-high" is specified, this is
> > recommended.
> > + It should contain the pwm to use, according to
> > + Documentation/devicetree/bindings/pwm/pwm.txt
> > + Verify the display datasheet for the EXTCOMIN signal period
> > + - disp-gpios: The GPIO used to enable the display, if available. See
> > + Documentation/devicetree/bindings/gpio/gpio.txt for
> > details.
> > +
> > +Examples:
> > +
> > +ls027b7dh01: smemlcd@0 {
> > +compatible = "sharp,ls027b7dh01";
> > +reg = <0>;
> > +spi-max-frequency = <100>;
> > +spi-cs-high;
> > +disp-gpios = <&gpio0 7>;
> > +disp-active-high;
> > +sharp,extmode-high;
> > +pwms = <&pwm 0 1>;
> > +};
> > +
> > +ls013b7dh05: smemlcd@3 {
> > +compatible = "sharp,ls013b7dh05";
> > +reg = <3>;
> > +spi-max-frequency = <100>;
> > +spi-cs-high;
> > +disp-gpios = <&gpio0 13>;
> > +disp-active-high;
> > +sharp,extmode-high;
> > +pwms = <&pwm 0 5000>;
> > +sharp,frames-per-sec = <20>;
> > +};
> > diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
> > index b2c9dd4f0cb5..0fff47a59d8b 100644
> > --- a/drivers/video/fbdev/Kconfig
> > +++ b/drivers/video/fbdev/Kconfig
> > @@ -2221,6 +2221,20 @@ config FB_SSD1307
> > This driver implements support for the Solomon SSD1307
> > OLED controller over I2C.
> >
> > +config FB_SMEMLCD
> > + tristate "Sharp Memory LCD framebuffer support"
> > + depends on FB && SPI
> > + depends on OF
> > + depends on GPIOLIB || COMPILE_TEST
> > + select FB_SYS_FOPS
> > + select FB_SYS_FILLRECT
> > + select FB_SYS_COPYAREA
> > + select FB_SYS_IMAGEBLIT
> > + select FB_DEFERRED_IO
> > + select PWM
> > + help
> > + This driver implements support for the Sharp Memory LCD
> > +
> > config FB_SM712
> > tristate "Silicon Motion SM712 framebuffer support"
> > depends on FB && PCI
> > diff --git a/drivers/video/fbdev/Makefile b/drivers/video/fbdev/Makefile
> > index cad4fb64442a..5c58dfd8ac08 100644
> > --- a/drivers/video/fbdev/Makefile
> > +++ b/
Re: [PATCH -next 1/2] drm: Remove redundant NULL check
On Thu, Jul 23, 2020 at 11:27:42AM +0800, Li Heng wrote:
> Fix below warnings reported by coccicheck:
> ./drivers/gpu/drm/drm_drv.c:819:2-7: WARNING: NULL check before some freeing
> functions is not needed.
>
> Fixes: 5dad34f3c444 ("drm: Cleanups after drmm_add_final_kfree rollout")
> Signed-off-by: Li Heng
Queued up, should make it into 5.9 merge window, thanks for your patch.
-Daniel
> ---
> drivers/gpu/drm/drm_drv.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index bc38322..13068fd 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -815,8 +815,7 @@ static void drm_dev_release(struct kref *ref)
>
> drm_managed_release(dev);
>
> - if (dev->managed.final_kfree)
> - kfree(dev->managed.final_kfree);
> + kfree(dev->managed.final_kfree);
> }
>
> /**
> --
> 2.7.4
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/9] drm/ttm: initialize the system domain with defaults
On Thu, Jul 23, 2020 at 05:16:13PM +0200, Christian König wrote:
> Instead of repeating that in each driver.
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 3 ---
> drivers/gpu/drm/drm_gem_vram_helper.c | 3 ---
> drivers/gpu/drm/nouveau/nouveau_bo.c | 3 ---
> drivers/gpu/drm/qxl/qxl_ttm.c | 3 ---
> drivers/gpu/drm/radeon/radeon_ttm.c| 3 ---
> drivers/gpu/drm/ttm/ttm_bo.c | 2 ++
> drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 2 --
> 7 files changed, 2 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> index 0dd5e802091d..e57c49a91b73 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> @@ -84,9 +84,6 @@ static int amdgpu_init_mem_type(struct ttm_bo_device *bdev,
> uint32_t type,
> switch (type) {
> case TTM_PL_SYSTEM:
> /* System memory */
> - man->flags = 0;
> - man->available_caching = TTM_PL_MASK_CACHING;
> - man->default_caching = TTM_PL_FLAG_CACHED;
> break;
> case TTM_PL_TT:
> /* GTT memory */
> diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
> b/drivers/gpu/drm/drm_gem_vram_helper.c
> index 3296ed3df358..be177afdeb9a 100644
> --- a/drivers/gpu/drm/drm_gem_vram_helper.c
> +++ b/drivers/gpu/drm/drm_gem_vram_helper.c
> @@ -1009,9 +1009,6 @@ static int bo_driver_init_mem_type(struct ttm_bo_device
> *bdev, uint32_t type,
> {
> switch (type) {
> case TTM_PL_SYSTEM:
> - man->flags = 0;
> - man->available_caching = TTM_PL_MASK_CACHING;
> - man->default_caching = TTM_PL_FLAG_CACHED;
> break;
> case TTM_PL_VRAM:
> man->func = &ttm_bo_manager_func;
> diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
> b/drivers/gpu/drm/nouveau/nouveau_bo.c
> index 4ccf937df0d0..53af25020bb2 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_bo.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
> @@ -655,9 +655,6 @@ nouveau_bo_init_mem_type(struct ttm_bo_device *bdev,
> uint32_t type,
>
> switch (type) {
> case TTM_PL_SYSTEM:
> - man->flags = 0;
> - man->available_caching = TTM_PL_MASK_CACHING;
> - man->default_caching = TTM_PL_FLAG_CACHED;
> break;
> case TTM_PL_VRAM:
> man->flags = TTM_MEMTYPE_FLAG_FIXED;
> diff --git a/drivers/gpu/drm/qxl/qxl_ttm.c b/drivers/gpu/drm/qxl/qxl_ttm.c
> index 1d8e07b8b19e..e9b8c921c1f0 100644
> --- a/drivers/gpu/drm/qxl/qxl_ttm.c
> +++ b/drivers/gpu/drm/qxl/qxl_ttm.c
> @@ -54,9 +54,6 @@ static int qxl_init_mem_type(struct ttm_bo_device *bdev,
> uint32_t type,
> switch (type) {
> case TTM_PL_SYSTEM:
> /* System memory */
> - man->flags = 0;
> - man->available_caching = TTM_PL_MASK_CACHING;
> - man->default_caching = TTM_PL_FLAG_CACHED;
> break;
> case TTM_PL_VRAM:
> case TTM_PL_PRIV:
> diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
> b/drivers/gpu/drm/radeon/radeon_ttm.c
> index b474781a0920..b4cb75361577 100644
> --- a/drivers/gpu/drm/radeon/radeon_ttm.c
> +++ b/drivers/gpu/drm/radeon/radeon_ttm.c
> @@ -76,9 +76,6 @@ static int radeon_init_mem_type(struct ttm_bo_device *bdev,
> uint32_t type,
> switch (type) {
> case TTM_PL_SYSTEM:
> /* System memory */
> - man->flags = 0;
> - man->available_caching = TTM_PL_MASK_CACHING;
> - man->default_caching = TTM_PL_FLAG_CACHED;
> break;
> case TTM_PL_TT:
> man->func = &ttm_bo_manager_func;
> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> index 7c02ce784805..1f1f9e463265 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> @@ -1677,6 +1677,8 @@ int ttm_bo_device_init(struct ttm_bo_device *bdev,
>* Initialize the system memory buffer type.
>* Other types need to be driver / IOCTL initialized.
>*/
> + bdev->man[TTM_PL_SYSTEM].available_caching = TTM_PL_MASK_CACHING;
> + bdev->man[TTM_PL_SYSTEM].default_caching = TTM_PL_FLAG_CACHED;
> ret = ttm_bo_init_mm(bdev, TTM_PL_SYSTEM, 0);
> if (unlikely(ret != 0))
> goto out_no_sys;
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
> index 1d78187eaba6..00cef1a3a178 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
> @@ -742,8 +742,6 @@ static int vmw_init_mem_type(struct ttm_bo_device *bdev,
> uint32_t type,
> switch (type) {
> case TTM_PL_SYSTEM:
> /* System memory */
> - man->available_caching = TTM_PL_FLAG_CACHED;
Above is CACHED, not CACHING, so needs to stay to overwrite the d
Re: [PATCH 2/9] drm/ttm: remove TTM_MEMTYPE_FLAG_FIXED
On Thu, Jul 23, 2020 at 05:16:14PM +0200, Christian König wrote:
> Instead use a boolean field in the memory manager structure.
>
> Also invert the meaning of the field since the use of a TT
> structure is the special case here.
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 4 +---
> drivers/gpu/drm/drm_gem_vram_helper.c | 1 -
> drivers/gpu/drm/nouveau/nouveau_bo.c | 4 +---
> drivers/gpu/drm/qxl/qxl_ttm.c | 1 -
> drivers/gpu/drm/radeon/radeon_ttm.c| 3 +--
> drivers/gpu/drm/ttm/ttm_bo.c | 14 +++---
> drivers/gpu/drm/ttm/ttm_bo_util.c | 12 ++--
> drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 3 ++-
> include/drm/ttm/ttm_bo_driver.h| 4 +---
> 9 files changed, 19 insertions(+), 27 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> index e57c49a91b73..406bcb03df48 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> @@ -87,15 +87,14 @@ static int amdgpu_init_mem_type(struct ttm_bo_device
> *bdev, uint32_t type,
> break;
> case TTM_PL_TT:
> /* GTT memory */
> + man->use_tt = true;
> man->func = &amdgpu_gtt_mgr_func;
> man->available_caching = TTM_PL_MASK_CACHING;
> man->default_caching = TTM_PL_FLAG_CACHED;
> - man->flags = 0;
> break;
> case TTM_PL_VRAM:
> /* "On-card" video ram */
> man->func = &amdgpu_vram_mgr_func;
> - man->flags = TTM_MEMTYPE_FLAG_FIXED;
> man->available_caching = TTM_PL_FLAG_UNCACHED | TTM_PL_FLAG_WC;
> man->default_caching = TTM_PL_FLAG_WC;
> break;
> @@ -104,7 +103,6 @@ static int amdgpu_init_mem_type(struct ttm_bo_device
> *bdev, uint32_t type,
> case AMDGPU_PL_OA:
> /* On-chip GDS memory*/
> man->func = &ttm_bo_manager_func;
> - man->flags = TTM_MEMTYPE_FLAG_FIXED;
> man->available_caching = TTM_PL_FLAG_UNCACHED;
> man->default_caching = TTM_PL_FLAG_UNCACHED;
> break;
> diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
> b/drivers/gpu/drm/drm_gem_vram_helper.c
> index be177afdeb9a..801a14c6e9e0 100644
> --- a/drivers/gpu/drm/drm_gem_vram_helper.c
> +++ b/drivers/gpu/drm/drm_gem_vram_helper.c
> @@ -1012,7 +1012,6 @@ static int bo_driver_init_mem_type(struct ttm_bo_device
> *bdev, uint32_t type,
> break;
> case TTM_PL_VRAM:
> man->func = &ttm_bo_manager_func;
> - man->flags = TTM_MEMTYPE_FLAG_FIXED;
> man->available_caching = TTM_PL_FLAG_UNCACHED |
>TTM_PL_FLAG_WC;
> man->default_caching = TTM_PL_FLAG_WC;
> diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
> b/drivers/gpu/drm/nouveau/nouveau_bo.c
> index 53af25020bb2..a3ad66ad3817 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_bo.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
> @@ -657,7 +657,6 @@ nouveau_bo_init_mem_type(struct ttm_bo_device *bdev,
> uint32_t type,
> case TTM_PL_SYSTEM:
> break;
> case TTM_PL_VRAM:
> - man->flags = TTM_MEMTYPE_FLAG_FIXED;
> man->available_caching = TTM_PL_FLAG_UNCACHED |
>TTM_PL_FLAG_WC;
> man->default_caching = TTM_PL_FLAG_WC;
> @@ -685,13 +684,12 @@ nouveau_bo_init_mem_type(struct ttm_bo_device *bdev,
> uint32_t type,
> else
> man->func = &ttm_bo_manager_func;
>
> + man->use_tt = true;
> if (drm->agp.bridge) {
> - man->flags = 0;
> man->available_caching = TTM_PL_FLAG_UNCACHED |
> TTM_PL_FLAG_WC;
> man->default_caching = TTM_PL_FLAG_WC;
> } else {
> - man->flags = 0;
> man->available_caching = TTM_PL_MASK_CACHING;
> man->default_caching = TTM_PL_FLAG_CACHED;
> }
> diff --git a/drivers/gpu/drm/qxl/qxl_ttm.c b/drivers/gpu/drm/qxl/qxl_ttm.c
> index e9b8c921c1f0..abb9fa4d80cf 100644
> --- a/drivers/gpu/drm/qxl/qxl_ttm.c
> +++ b/drivers/gpu/drm/qxl/qxl_ttm.c
> @@ -59,7 +59,6 @@ static int qxl_init_mem_type(struct ttm_bo_device *bdev,
> uint32_t type,
> case TTM_PL_PRIV:
> /* "On-card" video ram */
> man->func = &ttm_bo_manager_func;
> - man->flags = TTM_MEMTYPE_FLAG_FIXED;
> man->available_caching = TTM_PL_MASK_CACHING;
> man->default_caching = TTM_PL_FLAG_CACHED;
> break;
> diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
> b/drivers/gpu/drm/radeon/radeon_ttm.c
> index b4cb75361577..9aba18a143e7 100644
> --
Re: [PATCH 2/9] drm/ttm: remove TTM_MEMTYPE_FLAG_FIXED
Am 27.07.20 um 11:48 schrieb dan...@ffwll.ch:
On Thu, Jul 23, 2020 at 05:16:14PM +0200, Christian König wrote:
Instead use a boolean field in the memory manager structure.
Also invert the meaning of the field since the use of a TT
structure is the special case here.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 4 +---
drivers/gpu/drm/drm_gem_vram_helper.c | 1 -
drivers/gpu/drm/nouveau/nouveau_bo.c | 4 +---
drivers/gpu/drm/qxl/qxl_ttm.c | 1 -
drivers/gpu/drm/radeon/radeon_ttm.c| 3 +--
drivers/gpu/drm/ttm/ttm_bo.c | 14 +++---
drivers/gpu/drm/ttm/ttm_bo_util.c | 12 ++--
drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 3 ++-
include/drm/ttm/ttm_bo_driver.h| 4 +---
9 files changed, 19 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index e57c49a91b73..406bcb03df48 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -87,15 +87,14 @@ static int amdgpu_init_mem_type(struct ttm_bo_device *bdev,
uint32_t type,
break;
case TTM_PL_TT:
/* GTT memory */
+ man->use_tt = true;
man->func = &amdgpu_gtt_mgr_func;
man->available_caching = TTM_PL_MASK_CACHING;
man->default_caching = TTM_PL_FLAG_CACHED;
- man->flags = 0;
break;
case TTM_PL_VRAM:
/* "On-card" video ram */
man->func = &amdgpu_vram_mgr_func;
- man->flags = TTM_MEMTYPE_FLAG_FIXED;
man->available_caching = TTM_PL_FLAG_UNCACHED | TTM_PL_FLAG_WC;
man->default_caching = TTM_PL_FLAG_WC;
break;
@@ -104,7 +103,6 @@ static int amdgpu_init_mem_type(struct ttm_bo_device *bdev,
uint32_t type,
case AMDGPU_PL_OA:
/* On-chip GDS memory*/
man->func = &ttm_bo_manager_func;
- man->flags = TTM_MEMTYPE_FLAG_FIXED;
man->available_caching = TTM_PL_FLAG_UNCACHED;
man->default_caching = TTM_PL_FLAG_UNCACHED;
break;
diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
b/drivers/gpu/drm/drm_gem_vram_helper.c
index be177afdeb9a..801a14c6e9e0 100644
--- a/drivers/gpu/drm/drm_gem_vram_helper.c
+++ b/drivers/gpu/drm/drm_gem_vram_helper.c
@@ -1012,7 +1012,6 @@ static int bo_driver_init_mem_type(struct ttm_bo_device
*bdev, uint32_t type,
break;
case TTM_PL_VRAM:
man->func = &ttm_bo_manager_func;
- man->flags = TTM_MEMTYPE_FLAG_FIXED;
man->available_caching = TTM_PL_FLAG_UNCACHED |
TTM_PL_FLAG_WC;
man->default_caching = TTM_PL_FLAG_WC;
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 53af25020bb2..a3ad66ad3817 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -657,7 +657,6 @@ nouveau_bo_init_mem_type(struct ttm_bo_device *bdev,
uint32_t type,
case TTM_PL_SYSTEM:
break;
case TTM_PL_VRAM:
- man->flags = TTM_MEMTYPE_FLAG_FIXED;
man->available_caching = TTM_PL_FLAG_UNCACHED |
TTM_PL_FLAG_WC;
man->default_caching = TTM_PL_FLAG_WC;
@@ -685,13 +684,12 @@ nouveau_bo_init_mem_type(struct ttm_bo_device *bdev,
uint32_t type,
else
man->func = &ttm_bo_manager_func;
+ man->use_tt = true;
if (drm->agp.bridge) {
- man->flags = 0;
man->available_caching = TTM_PL_FLAG_UNCACHED |
TTM_PL_FLAG_WC;
man->default_caching = TTM_PL_FLAG_WC;
} else {
- man->flags = 0;
man->available_caching = TTM_PL_MASK_CACHING;
man->default_caching = TTM_PL_FLAG_CACHED;
}
diff --git a/drivers/gpu/drm/qxl/qxl_ttm.c b/drivers/gpu/drm/qxl/qxl_ttm.c
index e9b8c921c1f0..abb9fa4d80cf 100644
--- a/drivers/gpu/drm/qxl/qxl_ttm.c
+++ b/drivers/gpu/drm/qxl/qxl_ttm.c
@@ -59,7 +59,6 @@ static int qxl_init_mem_type(struct ttm_bo_device *bdev,
uint32_t type,
case TTM_PL_PRIV:
/* "On-card" video ram */
man->func = &ttm_bo_manager_func;
- man->flags = TTM_MEMTYPE_FLAG_FIXED;
man->available_caching = TTM_PL_MASK_CACHING;
man->default_caching = TTM_PL_FLAG_CACHED;
break;
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
b/drivers/gpu/drm/radeon/radeon_ttm.c
index b4cb75361577..9aba18a143e7 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/dr
Re: [PATCH 2/9] drm/ttm: remove TTM_MEMTYPE_FLAG_FIXED
On Mon, Jul 27, 2020 at 11:54:41AM +0200, Christian König wrote:
> Am 27.07.20 um 11:48 schrieb dan...@ffwll.ch:
> > On Thu, Jul 23, 2020 at 05:16:14PM +0200, Christian König wrote:
> > > Instead use a boolean field in the memory manager structure.
> > >
> > > Also invert the meaning of the field since the use of a TT
> > > structure is the special case here.
> > >
> > > Signed-off-by: Christian König
> > > ---
> > > drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 4 +---
> > > drivers/gpu/drm/drm_gem_vram_helper.c | 1 -
> > > drivers/gpu/drm/nouveau/nouveau_bo.c | 4 +---
> > > drivers/gpu/drm/qxl/qxl_ttm.c | 1 -
> > > drivers/gpu/drm/radeon/radeon_ttm.c| 3 +--
> > > drivers/gpu/drm/ttm/ttm_bo.c | 14 +++---
> > > drivers/gpu/drm/ttm/ttm_bo_util.c | 12 ++--
> > > drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 3 ++-
> > > include/drm/ttm/ttm_bo_driver.h| 4 +---
> > > 9 files changed, 19 insertions(+), 27 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> > > b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> > > index e57c49a91b73..406bcb03df48 100644
> > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> > > @@ -87,15 +87,14 @@ static int amdgpu_init_mem_type(struct ttm_bo_device
> > > *bdev, uint32_t type,
> > > break;
> > > case TTM_PL_TT:
> > > /* GTT memory */
> > > + man->use_tt = true;
> > > man->func = &amdgpu_gtt_mgr_func;
> > > man->available_caching = TTM_PL_MASK_CACHING;
> > > man->default_caching = TTM_PL_FLAG_CACHED;
> > > - man->flags = 0;
> > > break;
> > > case TTM_PL_VRAM:
> > > /* "On-card" video ram */
> > > man->func = &amdgpu_vram_mgr_func;
> > > - man->flags = TTM_MEMTYPE_FLAG_FIXED;
> > > man->available_caching = TTM_PL_FLAG_UNCACHED |
> > > TTM_PL_FLAG_WC;
> > > man->default_caching = TTM_PL_FLAG_WC;
> > > break;
> > > @@ -104,7 +103,6 @@ static int amdgpu_init_mem_type(struct ttm_bo_device
> > > *bdev, uint32_t type,
> > > case AMDGPU_PL_OA:
> > > /* On-chip GDS memory*/
> > > man->func = &ttm_bo_manager_func;
> > > - man->flags = TTM_MEMTYPE_FLAG_FIXED;
> > > man->available_caching = TTM_PL_FLAG_UNCACHED;
> > > man->default_caching = TTM_PL_FLAG_UNCACHED;
> > > break;
> > > diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
> > > b/drivers/gpu/drm/drm_gem_vram_helper.c
> > > index be177afdeb9a..801a14c6e9e0 100644
> > > --- a/drivers/gpu/drm/drm_gem_vram_helper.c
> > > +++ b/drivers/gpu/drm/drm_gem_vram_helper.c
> > > @@ -1012,7 +1012,6 @@ static int bo_driver_init_mem_type(struct
> > > ttm_bo_device *bdev, uint32_t type,
> > > break;
> > > case TTM_PL_VRAM:
> > > man->func = &ttm_bo_manager_func;
> > > - man->flags = TTM_MEMTYPE_FLAG_FIXED;
> > > man->available_caching = TTM_PL_FLAG_UNCACHED |
> > >TTM_PL_FLAG_WC;
> > > man->default_caching = TTM_PL_FLAG_WC;
> > > diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
> > > b/drivers/gpu/drm/nouveau/nouveau_bo.c
> > > index 53af25020bb2..a3ad66ad3817 100644
> > > --- a/drivers/gpu/drm/nouveau/nouveau_bo.c
> > > +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
> > > @@ -657,7 +657,6 @@ nouveau_bo_init_mem_type(struct ttm_bo_device *bdev,
> > > uint32_t type,
> > > case TTM_PL_SYSTEM:
> > > break;
> > > case TTM_PL_VRAM:
> > > - man->flags = TTM_MEMTYPE_FLAG_FIXED;
> > > man->available_caching = TTM_PL_FLAG_UNCACHED |
> > >TTM_PL_FLAG_WC;
> > > man->default_caching = TTM_PL_FLAG_WC;
> > > @@ -685,13 +684,12 @@ nouveau_bo_init_mem_type(struct ttm_bo_device
> > > *bdev, uint32_t type,
> > > else
> > > man->func = &ttm_bo_manager_func;
> > > + man->use_tt = true;
> > > if (drm->agp.bridge) {
> > > - man->flags = 0;
> > > man->available_caching = TTM_PL_FLAG_UNCACHED |
> > > TTM_PL_FLAG_WC;
> > > man->default_caching = TTM_PL_FLAG_WC;
> > > } else {
> > > - man->flags = 0;
> > > man->available_caching = TTM_PL_MASK_CACHING;
> > > man->default_caching = TTM_PL_FLAG_CACHED;
> > > }
> > > diff --git a/drivers/gpu/drm/qxl/qxl_ttm.c b/drivers/gpu/drm/qxl/qxl_ttm.c
> > > index e9b8c921c1f0..abb9fa
Re: [PATCH 3/9] drm/radeon: stop implementing init_mem_type
On Thu, Jul 23, 2020 at 05:16:15PM +0200, Christian König wrote:
> Instead just initialize the memory type parameters
> before calling ttm_bo_init_mm.
>
> Signed-off-by: Christian König
Hm what's the motivation here? I do agree that the init_mem_type callback
is rather midlayer-y (having a per-type cast in a callback is a very clear
signal something with the layering is all busted). So removing this sounds
like a good idea, but not really following why just for radeon? Or simply
wip?
-Daniel
> ---
> drivers/gpu/drm/radeon/radeon_ttm.c | 70 ++---
> 1 file changed, 35 insertions(+), 35 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
> b/drivers/gpu/drm/radeon/radeon_ttm.c
> index 9aba18a143e7..b0b59c553785 100644
> --- a/drivers/gpu/drm/radeon/radeon_ttm.c
> +++ b/drivers/gpu/drm/radeon/radeon_ttm.c
> @@ -69,43 +69,43 @@ struct radeon_device *radeon_get_rdev(struct
> ttm_bo_device *bdev)
> static int radeon_init_mem_type(struct ttm_bo_device *bdev, uint32_t type,
> struct ttm_mem_type_manager *man)
> {
> - struct radeon_device *rdev;
> + return 0;
> +}
>
> - rdev = radeon_get_rdev(bdev);
> +static int radeon_ttm_init_vram(struct radeon_device *rdev)
> +{
> + struct ttm_mem_type_manager *man = &rdev->mman.bdev.man[TTM_PL_VRAM];
>
> - switch (type) {
> - case TTM_PL_SYSTEM:
> - /* System memory */
> - break;
> - case TTM_PL_TT:
> - man->func = &ttm_bo_manager_func;
> - man->available_caching = TTM_PL_MASK_CACHING;
> - man->default_caching = TTM_PL_FLAG_CACHED;
> - man->use_tt = true;
> + man->func = &ttm_bo_manager_func;
> + man->available_caching = TTM_PL_FLAG_UNCACHED | TTM_PL_FLAG_WC;
> + man->default_caching = TTM_PL_FLAG_WC;
> +
> + return ttm_bo_init_mm(&rdev->mman.bdev, TTM_PL_VRAM,
> + rdev->mc.real_vram_size >> PAGE_SHIFT);
> +}
> +
> +static int radeon_ttm_init_gtt(struct radeon_device *rdev)
> +{
> + struct ttm_mem_type_manager *man = &rdev->mman.bdev.man[TTM_PL_TT];
> +
> + man->func = &ttm_bo_manager_func;
> + man->available_caching = TTM_PL_MASK_CACHING;
> + man->default_caching = TTM_PL_FLAG_CACHED;
> + man->use_tt = true;
> #if IS_ENABLED(CONFIG_AGP)
> - if (rdev->flags & RADEON_IS_AGP) {
> - if (!rdev->ddev->agp) {
> - DRM_ERROR("AGP is not enabled for memory type
> %u\n",
> - (unsigned)type);
> - return -EINVAL;
> - }
> - man->available_caching = TTM_PL_FLAG_UNCACHED |
> - TTM_PL_FLAG_WC;
> - man->default_caching = TTM_PL_FLAG_WC;
> + if (rdev->flags & RADEON_IS_AGP) {
> + if (!rdev->ddev->agp) {
> + DRM_ERROR("AGP is not enabled\n");
> + return -EINVAL;
> }
> -#endif
> - break;
> - case TTM_PL_VRAM:
> - /* "On-card" video ram */
> - man->func = &ttm_bo_manager_func;
> - man->available_caching = TTM_PL_FLAG_UNCACHED | TTM_PL_FLAG_WC;
> + man->available_caching = TTM_PL_FLAG_UNCACHED |
> + TTM_PL_FLAG_WC;
> man->default_caching = TTM_PL_FLAG_WC;
> - break;
> - default:
> - DRM_ERROR("Unsupported memory type %u\n", (unsigned)type);
> - return -EINVAL;
> }
> - return 0;
> +#endif
> +
> + return ttm_bo_init_mm(&rdev->mman.bdev, TTM_PL_TT,
> + rdev->mc.gtt_size >> PAGE_SHIFT);
> }
>
> static void radeon_evict_flags(struct ttm_buffer_object *bo,
> @@ -778,8 +778,8 @@ int radeon_ttm_init(struct radeon_device *rdev)
> return r;
> }
> rdev->mman.initialized = true;
> - r = ttm_bo_init_mm(&rdev->mman.bdev, TTM_PL_VRAM,
> - rdev->mc.real_vram_size >> PAGE_SHIFT);
> +
> + r = radeon_ttm_init_vram(rdev);
> if (r) {
> DRM_ERROR("Failed initializing VRAM heap.\n");
> return r;
> @@ -804,8 +804,8 @@ int radeon_ttm_init(struct radeon_device *rdev)
> }
> DRM_INFO("radeon: %uM of VRAM memory ready\n",
>(unsigned) (rdev->mc.real_vram_size / (1024 * 1024)));
> - r = ttm_bo_init_mm(&rdev->mman.bdev, TTM_PL_TT,
> - rdev->mc.gtt_size >> PAGE_SHIFT);
> +
> + r = radeon_ttm_init_gtt(rdev);
> if (r) {
> DRM_ERROR("Failed initializing GTT heap.\n");
> return r;
> --
> 2.17.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corp
Re: [PATCH 3/9] drm/radeon: stop implementing init_mem_type
On Mon, Jul 27, 2020 at 12:30:00PM +0200, dan...@ffwll.ch wrote:
> On Thu, Jul 23, 2020 at 05:16:15PM +0200, Christian König wrote:
> > Instead just initialize the memory type parameters
> > before calling ttm_bo_init_mm.
> >
> > Signed-off-by: Christian König
>
> Hm what's the motivation here? I do agree that the init_mem_type callback
> is rather midlayer-y (having a per-type cast in a callback is a very clear
> signal something with the layering is all busted). So removing this sounds
> like a good idea, but not really following why just for radeon? Or simply
> wip?
nvm, I've seen the next series :-) And Alex already r-b'ed it.
-Daniel
>
>
>
> > ---
> > drivers/gpu/drm/radeon/radeon_ttm.c | 70 ++---
> > 1 file changed, 35 insertions(+), 35 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
> > b/drivers/gpu/drm/radeon/radeon_ttm.c
> > index 9aba18a143e7..b0b59c553785 100644
> > --- a/drivers/gpu/drm/radeon/radeon_ttm.c
> > +++ b/drivers/gpu/drm/radeon/radeon_ttm.c
> > @@ -69,43 +69,43 @@ struct radeon_device *radeon_get_rdev(struct
> > ttm_bo_device *bdev)
> > static int radeon_init_mem_type(struct ttm_bo_device *bdev, uint32_t type,
> > struct ttm_mem_type_manager *man)
> > {
> > - struct radeon_device *rdev;
> > + return 0;
> > +}
> >
> > - rdev = radeon_get_rdev(bdev);
> > +static int radeon_ttm_init_vram(struct radeon_device *rdev)
> > +{
> > + struct ttm_mem_type_manager *man = &rdev->mman.bdev.man[TTM_PL_VRAM];
> >
> > - switch (type) {
> > - case TTM_PL_SYSTEM:
> > - /* System memory */
> > - break;
> > - case TTM_PL_TT:
> > - man->func = &ttm_bo_manager_func;
> > - man->available_caching = TTM_PL_MASK_CACHING;
> > - man->default_caching = TTM_PL_FLAG_CACHED;
> > - man->use_tt = true;
> > + man->func = &ttm_bo_manager_func;
> > + man->available_caching = TTM_PL_FLAG_UNCACHED | TTM_PL_FLAG_WC;
> > + man->default_caching = TTM_PL_FLAG_WC;
> > +
> > + return ttm_bo_init_mm(&rdev->mman.bdev, TTM_PL_VRAM,
> > + rdev->mc.real_vram_size >> PAGE_SHIFT);
> > +}
> > +
> > +static int radeon_ttm_init_gtt(struct radeon_device *rdev)
> > +{
> > + struct ttm_mem_type_manager *man = &rdev->mman.bdev.man[TTM_PL_TT];
> > +
> > + man->func = &ttm_bo_manager_func;
> > + man->available_caching = TTM_PL_MASK_CACHING;
> > + man->default_caching = TTM_PL_FLAG_CACHED;
> > + man->use_tt = true;
> > #if IS_ENABLED(CONFIG_AGP)
> > - if (rdev->flags & RADEON_IS_AGP) {
> > - if (!rdev->ddev->agp) {
> > - DRM_ERROR("AGP is not enabled for memory type
> > %u\n",
> > - (unsigned)type);
> > - return -EINVAL;
> > - }
> > - man->available_caching = TTM_PL_FLAG_UNCACHED |
> > -TTM_PL_FLAG_WC;
> > - man->default_caching = TTM_PL_FLAG_WC;
> > + if (rdev->flags & RADEON_IS_AGP) {
> > + if (!rdev->ddev->agp) {
> > + DRM_ERROR("AGP is not enabled\n");
> > + return -EINVAL;
> > }
> > -#endif
> > - break;
> > - case TTM_PL_VRAM:
> > - /* "On-card" video ram */
> > - man->func = &ttm_bo_manager_func;
> > - man->available_caching = TTM_PL_FLAG_UNCACHED | TTM_PL_FLAG_WC;
> > + man->available_caching = TTM_PL_FLAG_UNCACHED |
> > +TTM_PL_FLAG_WC;
> > man->default_caching = TTM_PL_FLAG_WC;
> > - break;
> > - default:
> > - DRM_ERROR("Unsupported memory type %u\n", (unsigned)type);
> > - return -EINVAL;
> > }
> > - return 0;
> > +#endif
> > +
> > + return ttm_bo_init_mm(&rdev->mman.bdev, TTM_PL_TT,
> > + rdev->mc.gtt_size >> PAGE_SHIFT);
> > }
> >
> > static void radeon_evict_flags(struct ttm_buffer_object *bo,
> > @@ -778,8 +778,8 @@ int radeon_ttm_init(struct radeon_device *rdev)
> > return r;
> > }
> > rdev->mman.initialized = true;
> > - r = ttm_bo_init_mm(&rdev->mman.bdev, TTM_PL_VRAM,
> > - rdev->mc.real_vram_size >> PAGE_SHIFT);
> > +
> > + r = radeon_ttm_init_vram(rdev);
> > if (r) {
> > DRM_ERROR("Failed initializing VRAM heap.\n");
> > return r;
> > @@ -804,8 +804,8 @@ int radeon_ttm_init(struct radeon_device *rdev)
> > }
> > DRM_INFO("radeon: %uM of VRAM memory ready\n",
> > (unsigned) (rdev->mc.real_vram_size / (1024 * 1024)));
> > - r = ttm_bo_init_mm(&rdev->mman.bdev, TTM_PL_TT,
> > - rdev->mc.gtt_size >> PAGE_SHIFT);
> > +
> > + r = radeon_ttm_init_gtt(rdev);
> > if (r) {
> > DRM_ERROR("Failed initializing GTT heap.\n");
> > return r;
> > -
Re: [RFC][PATCH] dma-heap: Add proper kref handling on dma-buf heaps
On Sat, Jul 25, 2020 at 03:26:33AM +, John Stultz wrote:
> Add proper refcounting on the dma_heap structure.
> While existing heaps are built-in, we may eventually
> have heaps loaded from modules, and we'll need to be
> able to properly handle the references to the heaps
Uh I kinda want to wait until we cross that bridge ... this entire vendor
heaps thing still sounds very much like vendor trees hacking around
instead of having upstream drivers using upstream infrastructure.
-Daniel
>
> Cc: Sumit Semwal
> Cc: Andrew F. Davis
> Cc: Benjamin Gaignard
> Cc: Liam Mark
> Cc: Laura Abbott
> Cc: Brian Starkey
> Cc: linux-me...@vger.kernel.org
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: John Stultz
> ---
> drivers/dma-buf/dma-heap.c | 31 +++
> include/linux/dma-heap.h | 6 ++
> 2 files changed, 33 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/dma-buf/dma-heap.c b/drivers/dma-buf/dma-heap.c
> index afd22c9dbdcf..90c3720acc1c 100644
> --- a/drivers/dma-buf/dma-heap.c
> +++ b/drivers/dma-buf/dma-heap.c
> @@ -40,6 +40,8 @@ struct dma_heap {
> dev_t heap_devt;
> struct list_head list;
> struct cdev heap_cdev;
> + int minor;
> + struct kref refcount;
> };
>
> static LIST_HEAD(heap_list);
> @@ -190,11 +192,31 @@ void *dma_heap_get_drvdata(struct dma_heap *heap)
> return heap->priv;
> }
>
> +static void dma_heap_release(struct kref *ref)
> +{
> + struct dma_heap *heap = container_of(ref, struct dma_heap, refcount);
> +
> + /* Remove heap from the list */
> + mutex_lock(&heap_list_lock);
> + list_del(&heap->list);
> + mutex_unlock(&heap_list_lock);
> +
> + device_destroy(dma_heap_class, heap->heap_devt);
> + cdev_del(&heap->heap_cdev);
> + xa_erase(&dma_heap_minors, heap->minor);
> +
> + kfree(heap);
> +}
> +
> +void dma_heap_put(struct dma_heap *h)
> +{
> + kref_put(&h->refcount, dma_heap_release);
> +}
> +
> struct dma_heap *dma_heap_add(const struct dma_heap_export_info *exp_info)
> {
> struct dma_heap *heap, *h, *err_ret;
> struct device *dev_ret;
> - unsigned int minor;
> int ret;
>
> if (!exp_info->name || !strcmp(exp_info->name, "")) {
> @@ -223,12 +245,13 @@ struct dma_heap *dma_heap_add(const struct
> dma_heap_export_info *exp_info)
> if (!heap)
> return ERR_PTR(-ENOMEM);
>
> + kref_init(&heap->refcount);
> heap->name = exp_info->name;
> heap->ops = exp_info->ops;
> heap->priv = exp_info->priv;
>
> /* Find unused minor number */
> - ret = xa_alloc(&dma_heap_minors, &minor, heap,
> + ret = xa_alloc(&dma_heap_minors, &heap->minor, heap,
> XA_LIMIT(0, NUM_HEAP_MINORS - 1), GFP_KERNEL);
> if (ret < 0) {
> pr_err("dma_heap: Unable to get minor number for heap\n");
> @@ -237,7 +260,7 @@ struct dma_heap *dma_heap_add(const struct
> dma_heap_export_info *exp_info)
> }
>
> /* Create device */
> - heap->heap_devt = MKDEV(MAJOR(dma_heap_devt), minor);
> + heap->heap_devt = MKDEV(MAJOR(dma_heap_devt), heap->minor);
>
> cdev_init(&heap->heap_cdev, &dma_heap_fops);
> ret = cdev_add(&heap->heap_cdev, heap->heap_devt, 1);
> @@ -267,7 +290,7 @@ struct dma_heap *dma_heap_add(const struct
> dma_heap_export_info *exp_info)
> err2:
> cdev_del(&heap->heap_cdev);
> err1:
> - xa_erase(&dma_heap_minors, minor);
> + xa_erase(&dma_heap_minors, heap->minor);
> err0:
> kfree(heap);
> return err_ret;
> diff --git a/include/linux/dma-heap.h b/include/linux/dma-heap.h
> index 454e354d1ffb..c1572f29cfac 100644
> --- a/include/linux/dma-heap.h
> +++ b/include/linux/dma-heap.h
> @@ -56,4 +56,10 @@ void *dma_heap_get_drvdata(struct dma_heap *heap);
> */
> struct dma_heap *dma_heap_add(const struct dma_heap_export_info *exp_info);
>
> +/**
> + * dma_heap_put - drops a reference to a dmabuf heaps, potentially freeing it
> + * @heap:heap pointer
> + */
> +void dma_heap_put(struct dma_heap *heap);
> +
> #endif /* _DMA_HEAPS_H */
> --
> 2.17.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/9] drm/ttm: initialize the system domain with defaults
Am 27.07.20 um 11:42 schrieb dan...@ffwll.ch:
On Thu, Jul 23, 2020 at 05:16:13PM +0200, Christian König wrote:
Instead of repeating that in each driver.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 3 ---
drivers/gpu/drm/drm_gem_vram_helper.c | 3 ---
drivers/gpu/drm/nouveau/nouveau_bo.c | 3 ---
drivers/gpu/drm/qxl/qxl_ttm.c | 3 ---
drivers/gpu/drm/radeon/radeon_ttm.c| 3 ---
drivers/gpu/drm/ttm/ttm_bo.c | 2 ++
drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 2 --
7 files changed, 2 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 0dd5e802091d..e57c49a91b73 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -84,9 +84,6 @@ static int amdgpu_init_mem_type(struct ttm_bo_device *bdev,
uint32_t type,
switch (type) {
case TTM_PL_SYSTEM:
/* System memory */
- man->flags = 0;
- man->available_caching = TTM_PL_MASK_CACHING;
- man->default_caching = TTM_PL_FLAG_CACHED;
break;
case TTM_PL_TT:
/* GTT memory */
diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
b/drivers/gpu/drm/drm_gem_vram_helper.c
index 3296ed3df358..be177afdeb9a 100644
--- a/drivers/gpu/drm/drm_gem_vram_helper.c
+++ b/drivers/gpu/drm/drm_gem_vram_helper.c
@@ -1009,9 +1009,6 @@ static int bo_driver_init_mem_type(struct ttm_bo_device
*bdev, uint32_t type,
{
switch (type) {
case TTM_PL_SYSTEM:
- man->flags = 0;
- man->available_caching = TTM_PL_MASK_CACHING;
- man->default_caching = TTM_PL_FLAG_CACHED;
break;
case TTM_PL_VRAM:
man->func = &ttm_bo_manager_func;
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 4ccf937df0d0..53af25020bb2 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -655,9 +655,6 @@ nouveau_bo_init_mem_type(struct ttm_bo_device *bdev,
uint32_t type,
switch (type) {
case TTM_PL_SYSTEM:
- man->flags = 0;
- man->available_caching = TTM_PL_MASK_CACHING;
- man->default_caching = TTM_PL_FLAG_CACHED;
break;
case TTM_PL_VRAM:
man->flags = TTM_MEMTYPE_FLAG_FIXED;
diff --git a/drivers/gpu/drm/qxl/qxl_ttm.c b/drivers/gpu/drm/qxl/qxl_ttm.c
index 1d8e07b8b19e..e9b8c921c1f0 100644
--- a/drivers/gpu/drm/qxl/qxl_ttm.c
+++ b/drivers/gpu/drm/qxl/qxl_ttm.c
@@ -54,9 +54,6 @@ static int qxl_init_mem_type(struct ttm_bo_device *bdev,
uint32_t type,
switch (type) {
case TTM_PL_SYSTEM:
/* System memory */
- man->flags = 0;
- man->available_caching = TTM_PL_MASK_CACHING;
- man->default_caching = TTM_PL_FLAG_CACHED;
break;
case TTM_PL_VRAM:
case TTM_PL_PRIV:
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
b/drivers/gpu/drm/radeon/radeon_ttm.c
index b474781a0920..b4cb75361577 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -76,9 +76,6 @@ static int radeon_init_mem_type(struct ttm_bo_device *bdev,
uint32_t type,
switch (type) {
case TTM_PL_SYSTEM:
/* System memory */
- man->flags = 0;
- man->available_caching = TTM_PL_MASK_CACHING;
- man->default_caching = TTM_PL_FLAG_CACHED;
break;
case TTM_PL_TT:
man->func = &ttm_bo_manager_func;
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 7c02ce784805..1f1f9e463265 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -1677,6 +1677,8 @@ int ttm_bo_device_init(struct ttm_bo_device *bdev,
* Initialize the system memory buffer type.
* Other types need to be driver / IOCTL initialized.
*/
+ bdev->man[TTM_PL_SYSTEM].available_caching = TTM_PL_MASK_CACHING;
+ bdev->man[TTM_PL_SYSTEM].default_caching = TTM_PL_FLAG_CACHED;
ret = ttm_bo_init_mm(bdev, TTM_PL_SYSTEM, 0);
if (unlikely(ret != 0))
goto out_no_sys;
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
index 1d78187eaba6..00cef1a3a178 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
@@ -742,8 +742,6 @@ static int vmw_init_mem_type(struct ttm_bo_device *bdev,
uint32_t type,
switch (type) {
case TTM_PL_SYSTEM:
/* System memory */
- man->available_caching = TTM_PL_FLAG_CACHED;
Above is CACHED, not CACHING, so needs to stay to overwrite the default.
Crap I missed that. Problem is that I wanted to remove th
Re: [PATCH 1/3] drm/ast: Do full modeset if the primary plane's format changes
On Mon, Jul 27, 2020 at 09:37:05AM +0200, Thomas Zimmermann wrote:
> The atomic modesetting code tried to distinguish format changes from
> full modesetting operations. In practice, this was buggy and the format
> registers were often updated even for simple pageflips.
Nah it's not buggy, it's intentional. Most hw can update formats in a flip
withouth having to shut down the hw to do so.
> Instead do a full modeset if the primary plane changes formats. It's
> just as rare as an actual mode change, so there will be no performance
> penalty.
>
> The patch also replaces a reference to drm_crtc_state.allow_modeset with
> the correct call to drm_atomic_crtc_needs_modeset().
>
> Signed-off-by: Thomas Zimmermann
> Fixes: 4961eb60f145 ("drm/ast: Enable atomic modesetting")
> Cc: Thomas Zimmermann
> Cc: Gerd Hoffmann
> Cc: Dave Airlie
> Cc: Daniel Vetter
> Cc: Sam Ravnborg
> Cc: Emil Velikov
> Cc: "Y.C. Chen"
> Cc: # v5.6+
> ---
> drivers/gpu/drm/ast/ast_mode.c | 23 ---
> 1 file changed, 16 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
> index 154cd877d9d1..3680a000b812 100644
> --- a/drivers/gpu/drm/ast/ast_mode.c
> +++ b/drivers/gpu/drm/ast/ast_mode.c
> @@ -527,8 +527,8 @@ static const uint32_t ast_primary_plane_formats[] = {
> static int ast_primary_plane_helper_atomic_check(struct drm_plane *plane,
>struct drm_plane_state *state)
> {
> - struct drm_crtc_state *crtc_state;
> - struct ast_crtc_state *ast_crtc_state;
> + struct drm_crtc_state *crtc_state, *old_crtc_state;
> + struct ast_crtc_state *ast_crtc_state, *old_ast_crtc_state;
> int ret;
>
> if (!state->crtc)
> @@ -550,6 +550,15 @@ static int ast_primary_plane_helper_atomic_check(struct
> drm_plane *plane,
>
> ast_crtc_state->format = state->fb->format;
>
> + old_crtc_state = drm_atomic_get_old_crtc_state(state->state,
> state->crtc);
> + if (!old_crtc_state)
> + return 0;
> + old_ast_crtc_state = to_ast_crtc_state(old_crtc_state);
> + if (!old_ast_crtc_state)
The above two if checks should never fail, I'd wrap them in a WARN_ON.
> + return 0;
> + if (ast_crtc_state->format != old_ast_crtc_state->format)
> + crtc_state->mode_changed = true;
> +
> return 0;
> }
>
> @@ -775,18 +784,18 @@ static void ast_crtc_helper_atomic_flush(struct
> drm_crtc *crtc,
>
> ast_state = to_ast_crtc_state(crtc->state);
>
> - format = ast_state->format;
> - if (!format)
> + if (!drm_atomic_crtc_needs_modeset(crtc->state))
> return;
>
> + format = ast_state->format;
> + if (drm_WARN_ON_ONCE(dev, !format))
> + return; /* BUG: We didn't set format in primary check(). */
Hm that entire ast_state->format machinery looks kinda strange, can't you
just look up the primary plane state everywhere and that's it?
drm_framebuffer are fully invariant and refcounted to the state, so there
really shouldn't be any need to copy format around.
But that's maybe for a next patch. With the commit message clarified that
everything works as designed, and maybe the two WARN_ON added:
Reviewed-by: Daniel Vetter
> +
> vbios_mode_info = &ast_state->vbios_mode_info;
>
> ast_set_color_reg(ast, format);
> ast_set_vbios_color_reg(ast, format, vbios_mode_info);
>
> - if (!crtc->state->mode_changed)
> - return;
> -
> adjusted_mode = &crtc->state->adjusted_mode;
>
> ast_set_vbios_mode_reg(ast, adjusted_mode, vbios_mode_info);
> --
> 2.27.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/3] drm/ast: Store image size in HW cursor info
On Mon, Jul 27, 2020 at 09:37:06AM +0200, Thomas Zimmermann wrote:
> Store the image size as part of the HW cursor info, so that the
> cursor show function doesn't require the information from the
> caller. No functional changes.
Uh just pass the state structure and done? All these "store random stuff
in private structures" (they're not even atomic state structures, it's the
driver private thing even!) is very non-atomic. And I see zero reasons why
you have to do this, the cursor stays around.
-Daniel
>
> Signed-off-by: Thomas Zimmermann
> Fixes: 4961eb60f145 ("drm/ast: Enable atomic modesetting")
> Cc: Thomas Zimmermann
> Cc: Gerd Hoffmann
> Cc: Dave Airlie
> Cc: Daniel Vetter
> Cc: Sam Ravnborg
> Cc: Emil Velikov
> Cc: "Y.C. Chen"
> Cc: # v5.6+
> ---
> drivers/gpu/drm/ast/ast_cursor.c | 13 +++--
> drivers/gpu/drm/ast/ast_drv.h| 7 +--
> drivers/gpu/drm/ast/ast_mode.c | 8 +---
> 3 files changed, 17 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/ast/ast_cursor.c
> b/drivers/gpu/drm/ast/ast_cursor.c
> index acf0d23514e8..8642a0ce9da6 100644
> --- a/drivers/gpu/drm/ast/ast_cursor.c
> +++ b/drivers/gpu/drm/ast/ast_cursor.c
> @@ -87,6 +87,8 @@ int ast_cursor_init(struct ast_private *ast)
>
> ast->cursor.gbo[i] = gbo;
> ast->cursor.vaddr[i] = vaddr;
> + ast->cursor.size[i].width = 0;
> + ast->cursor.size[i].height = 0;
> }
>
> return drmm_add_action_or_reset(dev, ast_cursor_release, NULL);
> @@ -194,6 +196,9 @@ int ast_cursor_blit(struct ast_private *ast, struct
> drm_framebuffer *fb)
> /* do data transfer to cursor BO */
> update_cursor_image(dst, src, fb->width, fb->height);
>
> + ast->cursor.size[ast->cursor.next_index].width = fb->width;
> + ast->cursor.size[ast->cursor.next_index].height = fb->height;
> +
> drm_gem_vram_vunmap(gbo, src);
> drm_gem_vram_unpin(gbo);
>
> @@ -249,14 +254,18 @@ static void ast_cursor_set_location(struct ast_private
> *ast, u16 x, u16 y,
> ast_set_index_reg(ast, AST_IO_CRTC_PORT, 0xc7, y1);
> }
>
> -void ast_cursor_show(struct ast_private *ast, int x, int y,
> - unsigned int offset_x, unsigned int offset_y)
> +void ast_cursor_show(struct ast_private *ast, int x, int y)
> {
> + unsigned int offset_x, offset_y;
> u8 x_offset, y_offset;
> u8 __iomem *dst, __iomem *sig;
> u8 jreg;
>
> dst = ast->cursor.vaddr[ast->cursor.next_index];
> + offset_x = AST_MAX_HWC_WIDTH -
> +ast->cursor.size[ast->cursor.next_index].width;
> + offset_y = AST_MAX_HWC_HEIGHT -
> +ast->cursor.size[ast->cursor.next_index].height;
>
> sig = dst + AST_HWC_SIZE;
> writel(x, sig + AST_HWC_SIGNATURE_X);
> diff --git a/drivers/gpu/drm/ast/ast_drv.h b/drivers/gpu/drm/ast/ast_drv.h
> index e3a264ac7ee2..57414b429db3 100644
> --- a/drivers/gpu/drm/ast/ast_drv.h
> +++ b/drivers/gpu/drm/ast/ast_drv.h
> @@ -116,6 +116,10 @@ struct ast_private {
> struct {
> struct drm_gem_vram_object *gbo[AST_DEFAULT_HWC_NUM];
> void __iomem *vaddr[AST_DEFAULT_HWC_NUM];
> + struct {
> + unsigned int width;
> + unsigned int height;
> + } size[AST_DEFAULT_HWC_NUM];
> unsigned int next_index;
> } cursor;
>
> @@ -311,8 +315,7 @@ void ast_release_firmware(struct drm_device *dev);
> int ast_cursor_init(struct ast_private *ast);
> int ast_cursor_blit(struct ast_private *ast, struct drm_framebuffer *fb);
> void ast_cursor_page_flip(struct ast_private *ast);
> -void ast_cursor_show(struct ast_private *ast, int x, int y,
> - unsigned int offset_x, unsigned int offset_y);
> +void ast_cursor_show(struct ast_private *ast, int x, int y);
> void ast_cursor_hide(struct ast_private *ast);
>
> #endif
> diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
> index 3680a000b812..5b2b39c93033 100644
> --- a/drivers/gpu/drm/ast/ast_mode.c
> +++ b/drivers/gpu/drm/ast/ast_mode.c
> @@ -671,20 +671,14 @@ ast_cursor_plane_helper_atomic_update(struct drm_plane
> *plane,
> struct drm_plane_state *old_state)
> {
> struct drm_plane_state *state = plane->state;
> - struct drm_framebuffer *fb = state->fb;
> struct ast_private *ast = plane->dev->dev_private;
> - unsigned int offset_x, offset_y;
> -
> - offset_x = AST_MAX_HWC_WIDTH - fb->width;
> - offset_y = AST_MAX_HWC_WIDTH - fb->height;
>
> if (state->fb != old_state->fb) {
> /* A new cursor image was installed. */
> ast_cursor_page_flip(ast);
> }
>
> - ast_cursor_show(ast, state->crtc_x, state->crtc_y,
> - offset_x, offset_y);
> + ast_cursor_show(ast, state->crtc_x, state->crtc_y);
> }
>
> static void
> --
> 2.27.0
>
--
Daniel Vetter
Softwa
Re: [PATCH 3/3] drm/ast: Disable cursor while switching display modes
On Mon, Jul 27, 2020 at 09:37:07AM +0200, Thomas Zimmermann wrote:
> The ast's HW cursor requires the primary plane and CRTC to display
> at a correct mode and format. This is not the case while switching
> display modes, which can lead to the screen turing permanently dark.
>
> As a workaround, the ast driver now disables active HW cursors while
> the mode switch takes place. It also synchronizes with the vertical
> refresh to give HW cursor and primary plane some time to catch up on
> each other.
>
> Signed-off-by: Thomas Zimmermann
> Fixes: 4961eb60f145 ("drm/ast: Enable atomic modesetting")
Since you already do modeset when changing primary plane I think the much
cleaner solution is to use drm_atomic_helper_disable_planes_on_crtc() and
drm_atomic_helper_commit_planes() with flags =
DRM_PLANE_COMMIT_ACTIVE_ONLY or so, with corresponding changes in
atomic_commit_tail. Much cleaner instead of hand-rolling this all in
callbacks.
Note that with atomic helpers it is _very_ much encouraged to throw the
helper structure into the wind and write your own stuff, this thing is
intentionally very modular. This is to avoid incomprehensible drivers that
are forced to hack around the helper midlayer in their callbacks like the
below very much looks like.
-Daniel
> Cc: Thomas Zimmermann
> Cc: Gerd Hoffmann
> Cc: Dave Airlie
> Cc: Daniel Vetter
> Cc: Sam Ravnborg
> Cc: Emil Velikov
> Cc: "Y.C. Chen"
> Cc: # v5.6+
> ---
> drivers/gpu/drm/ast/ast_drv.h | 2 ++
> drivers/gpu/drm/ast/ast_mode.c | 53 +-
> 2 files changed, 54 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/ast/ast_drv.h b/drivers/gpu/drm/ast/ast_drv.h
> index 57414b429db3..564670b5d2ee 100644
> --- a/drivers/gpu/drm/ast/ast_drv.h
> +++ b/drivers/gpu/drm/ast/ast_drv.h
> @@ -162,6 +162,8 @@ void ast_driver_unload(struct drm_device *dev);
>
> #define AST_IO_MM_OFFSET (0x380)
>
> +#define AST_IO_VGAIR1_VREFRESH BIT(3)
> +
> #define __ast_read(x) \
> static inline u##x ast_read##x(struct ast_private *ast, u32 reg) { \
> u##x val = 0;\
> diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
> index 5b2b39c93033..e18365bbc08c 100644
> --- a/drivers/gpu/drm/ast/ast_mode.c
> +++ b/drivers/gpu/drm/ast/ast_mode.c
> @@ -514,6 +514,17 @@ static void ast_set_start_address_crt1(struct
> ast_private *ast,
>
> }
>
> +static void ast_wait_for_vretrace(struct ast_private *ast)
> +{
> + unsigned long timeout = jiffies + HZ;
> + u8 vgair1;
> +
> + do {
> + vgair1 = ast_io_read8(ast, AST_IO_INPUT_STATUS1_READ);
> + } while (!(vgair1 & AST_IO_VGAIR1_VREFRESH) &&
> + time_before(jiffies, timeout));
> +}
> +
> /*
> * Primary plane
> */
> @@ -666,6 +677,14 @@ static int ast_cursor_plane_helper_atomic_check(struct
> drm_plane *plane,
> return 0;
> }
>
> +static bool ast_disable_cursor_during_modeset(struct drm_plane *cursor_plane)
> +{
> + const struct drm_plane_state *cursor_state = cursor_plane->state;
> +
> + return cursor_state && cursor_state->visible && cursor_state->crtc &&
> +drm_atomic_crtc_needs_modeset(cursor_state->crtc->state);
> +}
> +
> static void
> ast_cursor_plane_helper_atomic_update(struct drm_plane *plane,
> struct drm_plane_state *old_state)
> @@ -678,7 +697,12 @@ ast_cursor_plane_helper_atomic_update(struct drm_plane
> *plane,
> ast_cursor_page_flip(ast);
> }
>
> - ast_cursor_show(ast, state->crtc_x, state->crtc_y);
> + /*
> + * For modesets, delay show() until end of atomic_flush(). See the
> + * atomic_begin() helper for more information.
> + */
> + if (!ast_disable_cursor_during_modeset(plane))
> + ast_cursor_show(ast, state->crtc_x, state->crtc_y);
> }
>
> static void
> @@ -764,6 +788,22 @@ static void ast_crtc_helper_atomic_begin(struct drm_crtc
> *crtc,
> struct ast_private *ast = to_ast_private(crtc->dev);
>
> ast_open_key(ast);
> +
> + /*
> + * HW cursors require the underlying primary plane and CRTC to
> + * display a valid mode and image. This is not the case during
> + * full modeset operations. So we temporarily disable any active
> + * HW cursor and re-enable it at the end of the atomic_flush()
> + * helper. The busy waiting allows the code to sync with the
> + * vertical refresh.
> + *
> + * We only do this during *full* modesets. It does not affect
> + * simple pageflips on the planes.
> + */
> + if (ast_disable_cursor_during_modeset(&ast->cursor_plane)) {
> + ast_cursor_hide(ast);
> + ast_wait_for_vretrace(ast);
> + }
> }
>
> static void ast_crtc_helper_atomic_flush(struct drm_crtc *crtc,
> @@ -771,6 +811,7 @@ static void ast_crtc_helper_atomic_flush(struct drm_crtc
> *crtc,
> {
> struct drm_device *dev = crtc->dev;
> struct ast
Re: [PATCH 1/9] drm/ttm: initialize the system domain with defaults
On Mon, 2020-07-27 at 12:39 +0200, Christian König wrote:
> Am 27.07.20 um 11:42 schrieb dan...@ffwll.ch:
> > On Thu, Jul 23, 2020 at 05:16:13PM +0200, Christian König wrote:
> > > Instead of repeating that in each driver.
> > >
> > > Signed-off-by: Christian König
> > > ---
> > > drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 3 ---
> > > drivers/gpu/drm/drm_gem_vram_helper.c | 3 ---
> > > drivers/gpu/drm/nouveau/nouveau_bo.c | 3 ---
> > > drivers/gpu/drm/qxl/qxl_ttm.c | 3 ---
> > > drivers/gpu/drm/radeon/radeon_ttm.c| 3 ---
> > > drivers/gpu/drm/ttm/ttm_bo.c | 2 ++
> > > drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 2 --
> > > 7 files changed, 2 insertions(+), 17 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> > > b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> > > index 0dd5e802091d..e57c49a91b73 100644
> > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> > > @@ -84,9 +84,6 @@ static int amdgpu_init_mem_type(struct
> > > ttm_bo_device *bdev, uint32_t type,
> > > switch (type) {
> > > case TTM_PL_SYSTEM:
> > > /* System memory */
> > > - man->flags = 0;
> > > - man->available_caching = TTM_PL_MASK_CACHING;
> > > - man->default_caching = TTM_PL_FLAG_CACHED;
> > > break;
> > > case TTM_PL_TT:
> > > /* GTT memory */
> > > diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
> > > b/drivers/gpu/drm/drm_gem_vram_helper.c
> > > index 3296ed3df358..be177afdeb9a 100644
> > > --- a/drivers/gpu/drm/drm_gem_vram_helper.c
> > > +++ b/drivers/gpu/drm/drm_gem_vram_helper.c
> > > @@ -1009,9 +1009,6 @@ static int bo_driver_init_mem_type(struct
> > > ttm_bo_device *bdev, uint32_t type,
> > > {
> > > switch (type) {
> > > case TTM_PL_SYSTEM:
> > > - man->flags = 0;
> > > - man->available_caching = TTM_PL_MASK_CACHING;
> > > - man->default_caching = TTM_PL_FLAG_CACHED;
> > > break;
> > > case TTM_PL_VRAM:
> > > man->func = &ttm_bo_manager_func;
> > > diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
> > > b/drivers/gpu/drm/nouveau/nouveau_bo.c
> > > index 4ccf937df0d0..53af25020bb2 100644
> > > --- a/drivers/gpu/drm/nouveau/nouveau_bo.c
> > > +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
> > > @@ -655,9 +655,6 @@ nouveau_bo_init_mem_type(struct ttm_bo_device
> > > *bdev, uint32_t type,
> > >
> > > switch (type) {
> > > case TTM_PL_SYSTEM:
> > > - man->flags = 0;
> > > - man->available_caching = TTM_PL_MASK_CACHING;
> > > - man->default_caching = TTM_PL_FLAG_CACHED;
> > > break;
> > > case TTM_PL_VRAM:
> > > man->flags = TTM_MEMTYPE_FLAG_FIXED;
> > > diff --git a/drivers/gpu/drm/qxl/qxl_ttm.c
> > > b/drivers/gpu/drm/qxl/qxl_ttm.c
> > > index 1d8e07b8b19e..e9b8c921c1f0 100644
> > > --- a/drivers/gpu/drm/qxl/qxl_ttm.c
> > > +++ b/drivers/gpu/drm/qxl/qxl_ttm.c
> > > @@ -54,9 +54,6 @@ static int qxl_init_mem_type(struct
> > > ttm_bo_device *bdev, uint32_t type,
> > > switch (type) {
> > > case TTM_PL_SYSTEM:
> > > /* System memory */
> > > - man->flags = 0;
> > > - man->available_caching = TTM_PL_MASK_CACHING;
> > > - man->default_caching = TTM_PL_FLAG_CACHED;
> > > break;
> > > case TTM_PL_VRAM:
> > > case TTM_PL_PRIV:
> > > diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
> > > b/drivers/gpu/drm/radeon/radeon_ttm.c
> > > index b474781a0920..b4cb75361577 100644
> > > --- a/drivers/gpu/drm/radeon/radeon_ttm.c
> > > +++ b/drivers/gpu/drm/radeon/radeon_ttm.c
> > > @@ -76,9 +76,6 @@ static int radeon_init_mem_type(struct
> > > ttm_bo_device *bdev, uint32_t type,
> > > switch (type) {
> > > case TTM_PL_SYSTEM:
> > > /* System memory */
> > > - man->flags = 0;
> > > - man->available_caching = TTM_PL_MASK_CACHING;
> > > - man->default_caching = TTM_PL_FLAG_CACHED;
> > > break;
> > > case TTM_PL_TT:
> > > man->func = &ttm_bo_manager_func;
> > > diff --git a/drivers/gpu/drm/ttm/ttm_bo.c
> > > b/drivers/gpu/drm/ttm/ttm_bo.c
> > > index 7c02ce784805..1f1f9e463265 100644
> > > --- a/drivers/gpu/drm/ttm/ttm_bo.c
> > > +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> > > @@ -1677,6 +1677,8 @@ int ttm_bo_device_init(struct ttm_bo_device
> > > *bdev,
> > >* Initialize the system memory buffer type.
> > >* Other types need to be driver / IOCTL initialized.
> > >*/
> > > + bdev->man[TTM_PL_SYSTEM].available_caching =
> > > TTM_PL_MASK_CACHING;
> > > + bdev->man[TTM_PL_SYSTEM].default_caching = TTM_PL_FLAG_CACHED;
> > > ret = ttm_bo_init_mm(bdev, TTM_PL_SYSTEM, 0);
> > > if (
Re: [PATCH 3/9] drm/radeon: stop implementing init_mem_type
Am 27.07.20 um 12:30 schrieb dan...@ffwll.ch:
On Thu, Jul 23, 2020 at 05:16:15PM +0200, Christian König wrote:
Instead just initialize the memory type parameters
before calling ttm_bo_init_mm.
Signed-off-by: Christian König
Hm what's the motivation here? I do agree that the init_mem_type callback
is rather midlayer-y (having a per-type cast in a callback is a very clear
signal something with the layering is all busted). So removing this sounds
like a good idea, but not really following why just for radeon? Or simply
wip?
On the first try only the first 3 mails made it to the list and then my
internet connection crashed.
I've send out the full set a minute later once more.
Christian.
-Daniel
---
drivers/gpu/drm/radeon/radeon_ttm.c | 70 ++---
1 file changed, 35 insertions(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
b/drivers/gpu/drm/radeon/radeon_ttm.c
index 9aba18a143e7..b0b59c553785 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -69,43 +69,43 @@ struct radeon_device *radeon_get_rdev(struct ttm_bo_device
*bdev)
static int radeon_init_mem_type(struct ttm_bo_device *bdev, uint32_t type,
struct ttm_mem_type_manager *man)
{
- struct radeon_device *rdev;
+ return 0;
+}
- rdev = radeon_get_rdev(bdev);
+static int radeon_ttm_init_vram(struct radeon_device *rdev)
+{
+ struct ttm_mem_type_manager *man = &rdev->mman.bdev.man[TTM_PL_VRAM];
- switch (type) {
- case TTM_PL_SYSTEM:
- /* System memory */
- break;
- case TTM_PL_TT:
- man->func = &ttm_bo_manager_func;
- man->available_caching = TTM_PL_MASK_CACHING;
- man->default_caching = TTM_PL_FLAG_CACHED;
- man->use_tt = true;
+ man->func = &ttm_bo_manager_func;
+ man->available_caching = TTM_PL_FLAG_UNCACHED | TTM_PL_FLAG_WC;
+ man->default_caching = TTM_PL_FLAG_WC;
+
+ return ttm_bo_init_mm(&rdev->mman.bdev, TTM_PL_VRAM,
+ rdev->mc.real_vram_size >> PAGE_SHIFT);
+}
+
+static int radeon_ttm_init_gtt(struct radeon_device *rdev)
+{
+ struct ttm_mem_type_manager *man = &rdev->mman.bdev.man[TTM_PL_TT];
+
+ man->func = &ttm_bo_manager_func;
+ man->available_caching = TTM_PL_MASK_CACHING;
+ man->default_caching = TTM_PL_FLAG_CACHED;
+ man->use_tt = true;
#if IS_ENABLED(CONFIG_AGP)
- if (rdev->flags & RADEON_IS_AGP) {
- if (!rdev->ddev->agp) {
- DRM_ERROR("AGP is not enabled for memory type
%u\n",
- (unsigned)type);
- return -EINVAL;
- }
- man->available_caching = TTM_PL_FLAG_UNCACHED |
-TTM_PL_FLAG_WC;
- man->default_caching = TTM_PL_FLAG_WC;
+ if (rdev->flags & RADEON_IS_AGP) {
+ if (!rdev->ddev->agp) {
+ DRM_ERROR("AGP is not enabled\n");
+ return -EINVAL;
}
-#endif
- break;
- case TTM_PL_VRAM:
- /* "On-card" video ram */
- man->func = &ttm_bo_manager_func;
- man->available_caching = TTM_PL_FLAG_UNCACHED | TTM_PL_FLAG_WC;
+ man->available_caching = TTM_PL_FLAG_UNCACHED |
+TTM_PL_FLAG_WC;
man->default_caching = TTM_PL_FLAG_WC;
- break;
- default:
- DRM_ERROR("Unsupported memory type %u\n", (unsigned)type);
- return -EINVAL;
}
- return 0;
+#endif
+
+ return ttm_bo_init_mm(&rdev->mman.bdev, TTM_PL_TT,
+ rdev->mc.gtt_size >> PAGE_SHIFT);
}
static void radeon_evict_flags(struct ttm_buffer_object *bo,
@@ -778,8 +778,8 @@ int radeon_ttm_init(struct radeon_device *rdev)
return r;
}
rdev->mman.initialized = true;
- r = ttm_bo_init_mm(&rdev->mman.bdev, TTM_PL_VRAM,
- rdev->mc.real_vram_size >> PAGE_SHIFT);
+
+ r = radeon_ttm_init_vram(rdev);
if (r) {
DRM_ERROR("Failed initializing VRAM heap.\n");
return r;
@@ -804,8 +804,8 @@ int radeon_ttm_init(struct radeon_device *rdev)
}
DRM_INFO("radeon: %uM of VRAM memory ready\n",
(unsigned) (rdev->mc.real_vram_size / (1024 * 1024)));
- r = ttm_bo_init_mm(&rdev->mman.bdev, TTM_PL_TT,
- rdev->mc.gtt_size >> PAGE_SHIFT);
+
+ r = radeon_ttm_init_gtt(rdev);
if (r) {
DRM_ERROR("Failed initializing GTT heap.\n");
return r;
--
2.17.1
___
dri-devel mailing list
dri-deve
Re: [PATCH] drm/amd/display: Clear dm_state for fast updates
On Monday, July 27, 2020 1:40 AM, Mazin Rezk wrote:
> This patch fixes a race condition that causes a use-after-free during
> amdgpu_dm_atomic_commit_tail. This can occur when 2 non-blocking commits
> are requested and the second one finishes before the first. Essentially,
> this bug occurs when the following sequence of events happens:
>
> 1. Non-blocking commit #1 is requested w/ a new dm_state #1 and is
> deferred to the workqueue.
>
> 2. Non-blocking commit #2 is requested w/ a new dm_state #2 and is
> deferred to the workqueue.
>
> 3. Commit #2 starts before commit #1, dm_state #1 is used in the
> commit_tail and commit #2 completes, freeing dm_state #1.
>
> 4. Commit #1 starts after commit #2 completes, uses the freed dm_state
> 1 and dereferences a freelist pointer while setting the context.
>
> Since this bug has only been spotted with fast commits, this patch fixes
> the bug by clearing the dm_state instead of using the old dc_state for
> fast updates. In addition, since dm_state is only used for its dc_state
> and amdgpu_dm_atomic_commit_tail will retain the dc_state if none is found,
> removing the dm_state should not have any consequences in fast updates.
>
> This use-after-free bug has existed for a while now, but only caused a
> noticeable issue starting from 5.7-rc1 due to 3202fa62f ("slub: relocate
> freelist pointer to middle of object") moving the freelist pointer from
> dm_state->base (which was unused) to dm_state->context (which is
> dereferenced).
>
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=207383
> Fixes: bd200d190f45 ("drm/amd/display: Don't replace the dc_state for fast
> updates")
> Reported-by: Duncan <1i5t5.dun...@cox.net>
> Signed-off-by: Mazin Rezk
> ---
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 36 ++-
> 1 file changed, 27 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index 86ffa0c2880f..710edc70e37e 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -8717,20 +8717,38 @@ static int amdgpu_dm_atomic_check(struct drm_device
> *dev,
>* the same resource. If we have a new DC context as part of
>* the DM atomic state from validation we need to free it and
>* retain the existing one instead.
> + *
> + * Furthermore, since the DM atomic state only contains the DC
> + * context and can safely be annulled, we can free the state
> + * and clear the associated private object now to free
> + * some memory and avoid a possible use-after-free later.
>*/
> - struct dm_atomic_state *new_dm_state, *old_dm_state;
>
> - new_dm_state = dm_atomic_get_new_state(state);
> - old_dm_state = dm_atomic_get_old_state(state);
> + for (i = 0; i < state->num_private_objs; i++) {
> + struct drm_private_obj *obj =
> state->private_objs[i].ptr;
>
> - if (new_dm_state && old_dm_state) {
> - if (new_dm_state->context)
> - dc_release_state(new_dm_state->context);
> + if (obj->funcs == adev->dm.atomic_obj.funcs) {
> + int j = state->num_private_objs-1;
>
> - new_dm_state->context = old_dm_state->context;
> + dm_atomic_destroy_state(obj,
> + state->private_objs[i].state);
> +
> + /* If i is not at the end of the array then the
> + * last element needs to be moved to where i was
> + * before the array can safely be truncated.
> + */
> + if (i != j)
> + state->private_objs[i] =
> + state->private_objs[j];
>
> - if (old_dm_state->context)
> - dc_retain_state(old_dm_state->context);
> + state->private_objs[j].ptr = NULL;
> + state->private_objs[j].state = NULL;
> + state->private_objs[j].old_state = NULL;
> + state->private_objs[j].new_state = NULL;
> +
> + state->num_private_objs = j;
> + break;
> + }
> }
> }
>
> --
> 2.27.0
>
I have tested this on 5.8.0-rc6 w/ an RX 480 for 8 hours and I have not had
the crash described in the Bugzilla thread. I will also be running this
patch on my kernel for the next couple of days to further confirm that this
is working. In addition, I will ask the users in the Bugzilla thread to
test this patch
[PATCH] drm/amd/display: Clear dm_state for fast updates
This patch fixes a race condition that causes a use-after-free during
amdgpu_dm_atomic_commit_tail. This can occur when 2 non-blocking commits
are requested and the second one finishes before the first. Essentially,
this bug occurs when the following sequence of events happens:
1. Non-blocking commit #1 is requested w/ a new dm_state #1 and is
deferred to the workqueue.
2. Non-blocking commit #2 is requested w/ a new dm_state #2 and is
deferred to the workqueue.
3. Commit #2 starts before commit #1, dm_state #1 is used in the
commit_tail and commit #2 completes, freeing dm_state #1.
4. Commit #1 starts after commit #2 completes, uses the freed dm_state
1 and dereferences a freelist pointer while setting the context.
Since this bug has only been spotted with fast commits, this patch fixes
the bug by clearing the dm_state instead of using the old dc_state for
fast updates. In addition, since dm_state is only used for its dc_state
and amdgpu_dm_atomic_commit_tail will retain the dc_state if none is found,
removing the dm_state should not have any consequences in fast updates.
This use-after-free bug has existed for a while now, but only caused a
noticeable issue starting from 5.7-rc1 due to 3202fa62f ("slub: relocate
freelist pointer to middle of object") moving the freelist pointer from
dm_state->base (which was unused) to dm_state->context (which is
dereferenced).
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=207383
Fixes: bd200d190f45 ("drm/amd/display: Don't replace the dc_state for fast
updates")
Reported-by: Duncan <1i5t5.dun...@cox.net>
Signed-off-by: Mazin Rezk
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 36 ++-
1 file changed, 27 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 86ffa0c2880f..710edc70e37e 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -8717,20 +8717,38 @@ static int amdgpu_dm_atomic_check(struct drm_device
*dev,
* the same resource. If we have a new DC context as part of
* the DM atomic state from validation we need to free it and
* retain the existing one instead.
+*
+* Furthermore, since the DM atomic state only contains the DC
+* context and can safely be annulled, we can free the state
+* and clear the associated private object now to free
+* some memory and avoid a possible use-after-free later.
*/
- struct dm_atomic_state *new_dm_state, *old_dm_state;
- new_dm_state = dm_atomic_get_new_state(state);
- old_dm_state = dm_atomic_get_old_state(state);
+ for (i = 0; i < state->num_private_objs; i++) {
+ struct drm_private_obj *obj =
state->private_objs[i].ptr;
- if (new_dm_state && old_dm_state) {
- if (new_dm_state->context)
- dc_release_state(new_dm_state->context);
+ if (obj->funcs == adev->dm.atomic_obj.funcs) {
+ int j = state->num_private_objs-1;
- new_dm_state->context = old_dm_state->context;
+ dm_atomic_destroy_state(obj,
+ state->private_objs[i].state);
+
+ /* If i is not at the end of the array then the
+* last element needs to be moved to where i was
+* before the array can safely be truncated.
+*/
+ if (i != j)
+ state->private_objs[i] =
+ state->private_objs[j];
- if (old_dm_state->context)
- dc_retain_state(old_dm_state->context);
+ state->private_objs[j].ptr = NULL;
+ state->private_objs[j].state = NULL;
+ state->private_objs[j].old_state = NULL;
+ state->private_objs[j].new_state = NULL;
+
+ state->num_private_objs = j;
+ break;
+ }
}
}
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[bug report] drm: xlnx: DRM/KMS driver for Xilinx ZynqMP DisplayPort Subsystem
Hello Hyun Kwon,
The patch d76271d22694: "drm: xlnx: DRM/KMS driver for Xilinx ZynqMP
DisplayPort Subsystem" from Jul 7, 2018, leads to the following
static checker warning:
drivers/gpu/drm/xlnx/zynqmp_dp.c:594 zynqmp_dp_mode_configure()
error: iterator underflow 'bws' (-1)-2
drivers/gpu/drm/xlnx/zynqmp_dp.c
566 static int zynqmp_dp_mode_configure(struct zynqmp_dp *dp, int pclock,
567 u8 current_bw)
568 {
569 int max_rate = dp->link_config.max_rate;
570 u8 bws[3] = { DP_LINK_BW_1_62, DP_LINK_BW_2_7, DP_LINK_BW_5_4 };
571 u8 max_lanes = dp->link_config.max_lanes;
572 u8 max_link_rate_code = drm_dp_link_rate_to_bw_code(max_rate);
573 u8 bpp = dp->config.bpp;
574 u8 lane_cnt;
575 s8 i;
576
577 if (current_bw == DP_LINK_BW_1_62) {
578 dev_err(dp->dev, "can't downshift. already lowest link
rate\n");
579 return -EINVAL;
580 }
581
582 for (i = ARRAY_SIZE(bws) - 1; i >= 0; i--) {
^^
This exits with i == -1.
583 if (current_bw && bws[i] >= current_bw)
584 continue;
585
586 if (bws[i] <= max_link_rate_code)
587 break;
588 }
589
590 for (lane_cnt = 1; lane_cnt <= max_lanes; lane_cnt <<= 1) {
591 int bw;
592 u32 rate;
593
594 bw = drm_dp_bw_code_to_link_rate(bws[i]);
^^
Potential negative array offset.
595 rate = zynqmp_dp_max_rate(bw, lane_cnt, bpp);
596 if (pclock <= rate) {
597 dp->mode.bw_code = bws[i];
598 dp->mode.lane_cnt = lane_cnt;
599 dp->mode.pclock = pclock;
600 return dp->mode.bw_code;
601 }
602 }
603
604 dev_err(dp->dev, "failed to configure link values\n");
605
606 return -EINVAL;
607 }
regards,
dan carpenter
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] drm/ast: Do full modeset if the primary plane's format changes
Hi
Am 27.07.20 um 12:40 schrieb dan...@ffwll.ch:
> On Mon, Jul 27, 2020 at 09:37:05AM +0200, Thomas Zimmermann wrote:
>> The atomic modesetting code tried to distinguish format changes from
>> full modesetting operations. In practice, this was buggy and the format
>> registers were often updated even for simple pageflips.
>
> Nah it's not buggy, it's intentional. Most hw can update formats in a flip
> withouth having to shut down the hw to do so.
Admittedly it was intentional when I write it, but it never really
worked. I think it might have even updated these color registers on each
frame.
>
>
>> Instead do a full modeset if the primary plane changes formats. It's
>> just as rare as an actual mode change, so there will be no performance
>> penalty.
>>
>> The patch also replaces a reference to drm_crtc_state.allow_modeset with
>> the correct call to drm_atomic_crtc_needs_modeset().
>>
>> Signed-off-by: Thomas Zimmermann
>> Fixes: 4961eb60f145 ("drm/ast: Enable atomic modesetting")
>> Cc: Thomas Zimmermann
>> Cc: Gerd Hoffmann
>> Cc: Dave Airlie
>> Cc: Daniel Vetter
>> Cc: Sam Ravnborg
>> Cc: Emil Velikov
>> Cc: "Y.C. Chen"
>> Cc: # v5.6+
>> ---
>> drivers/gpu/drm/ast/ast_mode.c | 23 ---
>> 1 file changed, 16 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
>> index 154cd877d9d1..3680a000b812 100644
>> --- a/drivers/gpu/drm/ast/ast_mode.c
>> +++ b/drivers/gpu/drm/ast/ast_mode.c
>> @@ -527,8 +527,8 @@ static const uint32_t ast_primary_plane_formats[] = {
>> static int ast_primary_plane_helper_atomic_check(struct drm_plane *plane,
>> struct drm_plane_state *state)
>> {
>> -struct drm_crtc_state *crtc_state;
>> -struct ast_crtc_state *ast_crtc_state;
>> +struct drm_crtc_state *crtc_state, *old_crtc_state;
>> +struct ast_crtc_state *ast_crtc_state, *old_ast_crtc_state;
>> int ret;
>>
>> if (!state->crtc)
>> @@ -550,6 +550,15 @@ static int ast_primary_plane_helper_atomic_check(struct
>> drm_plane *plane,
>>
>> ast_crtc_state->format = state->fb->format;
>>
>> +old_crtc_state = drm_atomic_get_old_crtc_state(state->state,
>> state->crtc);
>> +if (!old_crtc_state)
>> +return 0;
>> +old_ast_crtc_state = to_ast_crtc_state(old_crtc_state);
>> +if (!old_ast_crtc_state)
>
> The above two if checks should never fail, I'd wrap them in a WARN_ON.
Really? But what's the old state when the first mode is being programmed?
>
>> +return 0;
>> +if (ast_crtc_state->format != old_ast_crtc_state->format)
>> +crtc_state->mode_changed = true;
>> +
>> return 0;
>> }
>>
>> @@ -775,18 +784,18 @@ static void ast_crtc_helper_atomic_flush(struct
>> drm_crtc *crtc,
>>
>> ast_state = to_ast_crtc_state(crtc->state);
>>
>> -format = ast_state->format;
>> -if (!format)
>> +if (!drm_atomic_crtc_needs_modeset(crtc->state))
>> return;
>>
>> +format = ast_state->format;
>> +if (drm_WARN_ON_ONCE(dev, !format))
>> +return; /* BUG: We didn't set format in primary check(). */
>
> Hm that entire ast_state->format machinery looks kinda strange, can't you
> just look up the primary plane state everywhere and that's it?
> drm_framebuffer are fully invariant and refcounted to the state, so there
> really shouldn't be any need to copy format around.
ast_state->format is the format that has to be programmed in
atomic_flush(). If it's NULL, the current format was used. Updating the
primary plane's format also requires the vbios info, which depends on
CRTC state. So it's collected in the CRTC's atomic_check().
It felt natural to use the various atomic_check() functions to collect
and store and store away these structures, and later use them in
atomic_flush().
I'd prefer to keep the current design. It's the one that worked best
while writing the atomic-modesetting support for ast.
Best regard
Thomas
>
> But that's maybe for a next patch. With the commit message clarified that
> everything works as designed, and maybe the two WARN_ON added:
>
> Reviewed-by: Daniel Vetter
>
>> +
>> vbios_mode_info = &ast_state->vbios_mode_info;
>>
>> ast_set_color_reg(ast, format);
>> ast_set_vbios_color_reg(ast, format, vbios_mode_info);
>>
>> -if (!crtc->state->mode_changed)
>> -return;
>> -
>> adjusted_mode = &crtc->state->adjusted_mode;
>>
>> ast_set_vbios_mode_reg(ast, adjusted_mode, vbios_mode_info);
>> --
>> 2.27.0
>>
>
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
signature.asc
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-d
Re: [PATCH 2/3] drm/ast: Store image size in HW cursor info
Hi
Am 27.07.20 um 12:42 schrieb dan...@ffwll.ch:
> On Mon, Jul 27, 2020 at 09:37:06AM +0200, Thomas Zimmermann wrote:
>> Store the image size as part of the HW cursor info, so that the
>> cursor show function doesn't require the information from the
>> caller. No functional changes.
>
> Uh just pass the state structure and done? All these "store random stuff
> in private structures" (they're not even atomic state structures, it's the
> driver private thing even!) is very non-atomic. And I see zero reasons why
> you have to do this, the cursor stays around.
It's not random stuff. Ast cannot use ARGB for cursors. Anything in
ast_private.cursor represents cursor hardware state (not DRM state);
duplicated for double buffering.
* gbo: two perma-pinned GEM objects at the end of VRAM. It's the HW
cursor buffer in ARGB format. The userspace's cursor image is
converted to ARGB and copied into the current backbuffer.
* vaddr: A mapping of the gbo's into kernel address space. We don't
want to map the gbo on each update, so they are mapped once and the
kernel address is stored in vaddr.
* size: the size of each HW buffer. We could use the value in the fb,
but storing this as well makes the cursor code self-contained.
Best regards
Thomas
> -Daniel
>
>>
>> Signed-off-by: Thomas Zimmermann
>> Fixes: 4961eb60f145 ("drm/ast: Enable atomic modesetting")
>> Cc: Thomas Zimmermann
>> Cc: Gerd Hoffmann
>> Cc: Dave Airlie
>> Cc: Daniel Vetter
>> Cc: Sam Ravnborg
>> Cc: Emil Velikov
>> Cc: "Y.C. Chen"
>> Cc: # v5.6+
>> ---
>> drivers/gpu/drm/ast/ast_cursor.c | 13 +++--
>> drivers/gpu/drm/ast/ast_drv.h| 7 +--
>> drivers/gpu/drm/ast/ast_mode.c | 8 +---
>> 3 files changed, 17 insertions(+), 11 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/ast/ast_cursor.c
>> b/drivers/gpu/drm/ast/ast_cursor.c
>> index acf0d23514e8..8642a0ce9da6 100644
>> --- a/drivers/gpu/drm/ast/ast_cursor.c
>> +++ b/drivers/gpu/drm/ast/ast_cursor.c
>> @@ -87,6 +87,8 @@ int ast_cursor_init(struct ast_private *ast)
>>
>> ast->cursor.gbo[i] = gbo;
>> ast->cursor.vaddr[i] = vaddr;
>> +ast->cursor.size[i].width = 0;
>> +ast->cursor.size[i].height = 0;
>> }
>>
>> return drmm_add_action_or_reset(dev, ast_cursor_release, NULL);
>> @@ -194,6 +196,9 @@ int ast_cursor_blit(struct ast_private *ast, struct
>> drm_framebuffer *fb)
>> /* do data transfer to cursor BO */
>> update_cursor_image(dst, src, fb->width, fb->height);
>>
>> +ast->cursor.size[ast->cursor.next_index].width = fb->width;
>> +ast->cursor.size[ast->cursor.next_index].height = fb->height;
>> +
>> drm_gem_vram_vunmap(gbo, src);
>> drm_gem_vram_unpin(gbo);
>>
>> @@ -249,14 +254,18 @@ static void ast_cursor_set_location(struct ast_private
>> *ast, u16 x, u16 y,
>> ast_set_index_reg(ast, AST_IO_CRTC_PORT, 0xc7, y1);
>> }
>>
>> -void ast_cursor_show(struct ast_private *ast, int x, int y,
>> - unsigned int offset_x, unsigned int offset_y)
>> +void ast_cursor_show(struct ast_private *ast, int x, int y)
>> {
>> +unsigned int offset_x, offset_y;
>> u8 x_offset, y_offset;
>> u8 __iomem *dst, __iomem *sig;
>> u8 jreg;
>>
>> dst = ast->cursor.vaddr[ast->cursor.next_index];
>> +offset_x = AST_MAX_HWC_WIDTH -
>> + ast->cursor.size[ast->cursor.next_index].width;
>> +offset_y = AST_MAX_HWC_HEIGHT -
>> + ast->cursor.size[ast->cursor.next_index].height;
>>
>> sig = dst + AST_HWC_SIZE;
>> writel(x, sig + AST_HWC_SIGNATURE_X);
>> diff --git a/drivers/gpu/drm/ast/ast_drv.h b/drivers/gpu/drm/ast/ast_drv.h
>> index e3a264ac7ee2..57414b429db3 100644
>> --- a/drivers/gpu/drm/ast/ast_drv.h
>> +++ b/drivers/gpu/drm/ast/ast_drv.h
>> @@ -116,6 +116,10 @@ struct ast_private {
>> struct {
>> struct drm_gem_vram_object *gbo[AST_DEFAULT_HWC_NUM];
>> void __iomem *vaddr[AST_DEFAULT_HWC_NUM];
>> +struct {
>> +unsigned int width;
>> +unsigned int height;
>> +} size[AST_DEFAULT_HWC_NUM];
>> unsigned int next_index;
>> } cursor;
>>
>> @@ -311,8 +315,7 @@ void ast_release_firmware(struct drm_device *dev);
>> int ast_cursor_init(struct ast_private *ast);
>> int ast_cursor_blit(struct ast_private *ast, struct drm_framebuffer *fb);
>> void ast_cursor_page_flip(struct ast_private *ast);
>> -void ast_cursor_show(struct ast_private *ast, int x, int y,
>> - unsigned int offset_x, unsigned int offset_y);
>> +void ast_cursor_show(struct ast_private *ast, int x, int y);
>> void ast_cursor_hide(struct ast_private *ast);
>>
>> #endif
>> diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
>> index 3680a000b812..5b2b39c93033 100644
>> --- a/drivers/gpu/drm/ast/ast_mode.c
>> +++ b/drivers/gpu/drm/ast/ast_mode.c
>> @@ -671,20 +671,14 @@ ast_cursor_p
Re: [PATCH 1/9] drm/ttm: initialize the system domain with defaults
Am 27.07.20 um 12:50 schrieb Hellstrom, Thomas:
On Mon, 2020-07-27 at 12:39 +0200, Christian König wrote:
Am 27.07.20 um 11:42 schrieb dan...@ffwll.ch:
On Thu, Jul 23, 2020 at 05:16:13PM +0200, Christian König wrote:
Instead of repeating that in each driver.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 3 ---
drivers/gpu/drm/drm_gem_vram_helper.c | 3 ---
drivers/gpu/drm/nouveau/nouveau_bo.c | 3 ---
drivers/gpu/drm/qxl/qxl_ttm.c | 3 ---
drivers/gpu/drm/radeon/radeon_ttm.c| 3 ---
drivers/gpu/drm/ttm/ttm_bo.c | 2 ++
drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 2 --
7 files changed, 2 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 0dd5e802091d..e57c49a91b73 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -84,9 +84,6 @@ static int amdgpu_init_mem_type(struct
ttm_bo_device *bdev, uint32_t type,
switch (type) {
case TTM_PL_SYSTEM:
/* System memory */
- man->flags = 0;
- man->available_caching = TTM_PL_MASK_CACHING;
- man->default_caching = TTM_PL_FLAG_CACHED;
break;
case TTM_PL_TT:
/* GTT memory */
diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
b/drivers/gpu/drm/drm_gem_vram_helper.c
index 3296ed3df358..be177afdeb9a 100644
--- a/drivers/gpu/drm/drm_gem_vram_helper.c
+++ b/drivers/gpu/drm/drm_gem_vram_helper.c
@@ -1009,9 +1009,6 @@ static int bo_driver_init_mem_type(struct
ttm_bo_device *bdev, uint32_t type,
{
switch (type) {
case TTM_PL_SYSTEM:
- man->flags = 0;
- man->available_caching = TTM_PL_MASK_CACHING;
- man->default_caching = TTM_PL_FLAG_CACHED;
break;
case TTM_PL_VRAM:
man->func = &ttm_bo_manager_func;
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 4ccf937df0d0..53af25020bb2 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -655,9 +655,6 @@ nouveau_bo_init_mem_type(struct ttm_bo_device
*bdev, uint32_t type,
switch (type) {
case TTM_PL_SYSTEM:
- man->flags = 0;
- man->available_caching = TTM_PL_MASK_CACHING;
- man->default_caching = TTM_PL_FLAG_CACHED;
break;
case TTM_PL_VRAM:
man->flags = TTM_MEMTYPE_FLAG_FIXED;
diff --git a/drivers/gpu/drm/qxl/qxl_ttm.c
b/drivers/gpu/drm/qxl/qxl_ttm.c
index 1d8e07b8b19e..e9b8c921c1f0 100644
--- a/drivers/gpu/drm/qxl/qxl_ttm.c
+++ b/drivers/gpu/drm/qxl/qxl_ttm.c
@@ -54,9 +54,6 @@ static int qxl_init_mem_type(struct
ttm_bo_device *bdev, uint32_t type,
switch (type) {
case TTM_PL_SYSTEM:
/* System memory */
- man->flags = 0;
- man->available_caching = TTM_PL_MASK_CACHING;
- man->default_caching = TTM_PL_FLAG_CACHED;
break;
case TTM_PL_VRAM:
case TTM_PL_PRIV:
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
b/drivers/gpu/drm/radeon/radeon_ttm.c
index b474781a0920..b4cb75361577 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -76,9 +76,6 @@ static int radeon_init_mem_type(struct
ttm_bo_device *bdev, uint32_t type,
switch (type) {
case TTM_PL_SYSTEM:
/* System memory */
- man->flags = 0;
- man->available_caching = TTM_PL_MASK_CACHING;
- man->default_caching = TTM_PL_FLAG_CACHED;
break;
case TTM_PL_TT:
man->func = &ttm_bo_manager_func;
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c
b/drivers/gpu/drm/ttm/ttm_bo.c
index 7c02ce784805..1f1f9e463265 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -1677,6 +1677,8 @@ int ttm_bo_device_init(struct ttm_bo_device
*bdev,
* Initialize the system memory buffer type.
* Other types need to be driver / IOCTL initialized.
*/
+ bdev->man[TTM_PL_SYSTEM].available_caching =
TTM_PL_MASK_CACHING;
+ bdev->man[TTM_PL_SYSTEM].default_caching = TTM_PL_FLAG_CACHED;
ret = ttm_bo_init_mm(bdev, TTM_PL_SYSTEM, 0);
if (unlikely(ret != 0))
goto out_no_sys;
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
index 1d78187eaba6..00cef1a3a178 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
@@ -742,8 +742,6 @@ static int vmw_init_mem_type(struct
ttm_bo_device *bdev, uint32_t type,
switch (type) {
case TTM_PL_SYSTEM:
/* System memory */
- man->available_caching = TTM_PL_FLAG_CACHED;
Above is CACHED, not CAC
Re: [PATCH v5 1/5] drm/i915: Add enable/disable flip done and flip done handler
On 2020-07-25 1:26 a.m., Paulo Zanoni wrote:
> Em seg, 2020-07-20 às 17:01 +0530, Karthik B S escreveu:
>>
>> diff --git a/drivers/gpu/drm/i915/i915_irq.c
>> b/drivers/gpu/drm/i915/i915_irq.c
>> index 1fa67700d8f4..95953b393941 100644
>> --- a/drivers/gpu/drm/i915/i915_irq.c
>> +++ b/drivers/gpu/drm/i915/i915_irq.c
>> @@ -697,14 +697,24 @@ u32 i915_get_vblank_counter(struct drm_crtc *crtc)
>> return (((high1 << 8) | low) + (pixel >= vbl_start)) & 0xff;
>> }
>>
>> +static u32 g4x_get_flip_counter(struct drm_crtc *crtc)
>> +{
>> +struct drm_i915_private *dev_priv = to_i915(crtc->dev);
>> +enum pipe pipe = to_intel_crtc(crtc)->pipe;
>> +
>> +return I915_READ(PIPE_FLIPCOUNT_G4X(pipe));
>> +}
>> +
>> u32 g4x_get_vblank_counter(struct drm_crtc *crtc)
>> {
>> struct drm_i915_private *dev_priv = to_i915(crtc->dev);
>> enum pipe pipe = to_intel_crtc(crtc)->pipe;
>>
>> +if (crtc->state->async_flip)
>> +return g4x_get_flip_counter(crtc);
>> +
>> return I915_READ(PIPE_FRMCOUNT_G4X(pipe));
>
> I don't understand the intention behind this, can you please clarify?
> This goes back to my reply of the cover letter. It seems that here
> we're going to alternate between two different counters in our vblank
> count. So if user space alternates between sometimes using async flips
> and sometimes using normal flip it's going to get some very weird
> deltas, isn't it? At least this is what I remember from when I played
> with these registers: FLIPCOUNT drifts away from FRMCOUNT when we start
> using async flips.
This definitely looks wrong. The counter value returned by the
get_vblank_counter hook is supposed to increment when a vertical blank
period occurs; page flips are not supposed to affect this in any way.
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/9] drm/ttm: initialize the system domain with defaults
On Mon, 2020-07-27 at 14:23 +0200, Christian König wrote:
> Am 27.07.20 um 12:50 schrieb Hellstrom, Thomas:
> > On Mon, 2020-07-27 at 12:39 +0200, Christian König wrote:
> > > Am 27.07.20 um 11:42 schrieb dan...@ffwll.ch:
> > > > On Thu, Jul 23, 2020 at 05:16:13PM +0200, Christian König
> > > > wrote:
> > > > > Instead of repeating that in each driver.
> > > > >
> > > > > Signed-off-by: Christian König
> > > > > ---
> > > > >drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 3 ---
> > > > >drivers/gpu/drm/drm_gem_vram_helper.c | 3 ---
> > > > >drivers/gpu/drm/nouveau/nouveau_bo.c | 3 ---
> > > > >drivers/gpu/drm/qxl/qxl_ttm.c | 3 ---
> > > > >drivers/gpu/drm/radeon/radeon_ttm.c| 3 ---
> > > > >drivers/gpu/drm/ttm/ttm_bo.c | 2 ++
> > > > >drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 2 --
> > > > >7 files changed, 2 insertions(+), 17 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> > > > > b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> > > > > index 0dd5e802091d..e57c49a91b73 100644
> > > > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> > > > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> > > > > @@ -84,9 +84,6 @@ static int amdgpu_init_mem_type(struct
> > > > > ttm_bo_device *bdev, uint32_t type,
> > > > > switch (type) {
> > > > > case TTM_PL_SYSTEM:
> > > > > /* System memory */
> > > > > - man->flags = 0;
> > > > > - man->available_caching = TTM_PL_MASK_CACHING;
> > > > > - man->default_caching = TTM_PL_FLAG_CACHED;
> > > > > break;
> > > > > case TTM_PL_TT:
> > > > > /* GTT memory */
> > > > > diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
> > > > > b/drivers/gpu/drm/drm_gem_vram_helper.c
> > > > > index 3296ed3df358..be177afdeb9a 100644
> > > > > --- a/drivers/gpu/drm/drm_gem_vram_helper.c
> > > > > +++ b/drivers/gpu/drm/drm_gem_vram_helper.c
> > > > > @@ -1009,9 +1009,6 @@ static int
> > > > > bo_driver_init_mem_type(struct
> > > > > ttm_bo_device *bdev, uint32_t type,
> > > > >{
> > > > > switch (type) {
> > > > > case TTM_PL_SYSTEM:
> > > > > - man->flags = 0;
> > > > > - man->available_caching = TTM_PL_MASK_CACHING;
> > > > > - man->default_caching = TTM_PL_FLAG_CACHED;
> > > > > break;
> > > > > case TTM_PL_VRAM:
> > > > > man->func = &ttm_bo_manager_func;
> > > > > diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
> > > > > b/drivers/gpu/drm/nouveau/nouveau_bo.c
> > > > > index 4ccf937df0d0..53af25020bb2 100644
> > > > > --- a/drivers/gpu/drm/nouveau/nouveau_bo.c
> > > > > +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
> > > > > @@ -655,9 +655,6 @@ nouveau_bo_init_mem_type(struct
> > > > > ttm_bo_device
> > > > > *bdev, uint32_t type,
> > > > >
> > > > > switch (type) {
> > > > > case TTM_PL_SYSTEM:
> > > > > - man->flags = 0;
> > > > > - man->available_caching = TTM_PL_MASK_CACHING;
> > > > > - man->default_caching = TTM_PL_FLAG_CACHED;
> > > > > break;
> > > > > case TTM_PL_VRAM:
> > > > > man->flags = TTM_MEMTYPE_FLAG_FIXED;
> > > > > diff --git a/drivers/gpu/drm/qxl/qxl_ttm.c
> > > > > b/drivers/gpu/drm/qxl/qxl_ttm.c
> > > > > index 1d8e07b8b19e..e9b8c921c1f0 100644
> > > > > --- a/drivers/gpu/drm/qxl/qxl_ttm.c
> > > > > +++ b/drivers/gpu/drm/qxl/qxl_ttm.c
> > > > > @@ -54,9 +54,6 @@ static int qxl_init_mem_type(struct
> > > > > ttm_bo_device *bdev, uint32_t type,
> > > > > switch (type) {
> > > > > case TTM_PL_SYSTEM:
> > > > > /* System memory */
> > > > > - man->flags = 0;
> > > > > - man->available_caching = TTM_PL_MASK_CACHING;
> > > > > - man->default_caching = TTM_PL_FLAG_CACHED;
> > > > > break;
> > > > > case TTM_PL_VRAM:
> > > > > case TTM_PL_PRIV:
> > > > > diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
> > > > > b/drivers/gpu/drm/radeon/radeon_ttm.c
> > > > > index b474781a0920..b4cb75361577 100644
> > > > > --- a/drivers/gpu/drm/radeon/radeon_ttm.c
> > > > > +++ b/drivers/gpu/drm/radeon/radeon_ttm.c
> > > > > @@ -76,9 +76,6 @@ static int radeon_init_mem_type(struct
> > > > > ttm_bo_device *bdev, uint32_t type,
> > > > > switch (type) {
> > > > > case TTM_PL_SYSTEM:
> > > > > /* System memory */
> > > > > - man->flags = 0;
> > > > > - man->available_caching = TTM_PL_MASK_CACHING;
> > > > > - man->default_caching = TTM_PL_FLAG_CACHED;
> > > > > break;
> > > > > case TTM_PL_TT:
> > > > > man->func = &ttm_bo_manager_func;
> > > > > diff --git a/drivers/gpu/drm/ttm/ttm_bo.c
> > > > > b/drivers/gpu/drm/ttm/ttm_bo.c
> > > > > index 7c02ce784805..1f1f9e463265 100644
> > > > > --- a/drivers/gpu/drm/ttm/ttm_bo.c
> > > > > +++ b/
Re: [PATCH] drm/amd/display: Clear dm_state for fast updates
On 2020-07-27 1:40 a.m., Mazin Rezk wrote:
This patch fixes a race condition that causes a use-after-free during
amdgpu_dm_atomic_commit_tail. This can occur when 2 non-blocking commits
are requested and the second one finishes before the first. Essentially,
this bug occurs when the following sequence of events happens:
1. Non-blocking commit #1 is requested w/ a new dm_state #1 and is
deferred to the workqueue.
2. Non-blocking commit #2 is requested w/ a new dm_state #2 and is
deferred to the workqueue.
3. Commit #2 starts before commit #1, dm_state #1 is used in the
commit_tail and commit #2 completes, freeing dm_state #1.
4. Commit #1 starts after commit #2 completes, uses the freed dm_state
1 and dereferences a freelist pointer while setting the context.
Since this bug has only been spotted with fast commits, this patch fixes
the bug by clearing the dm_state instead of using the old dc_state for
fast updates. In addition, since dm_state is only used for its dc_state
and amdgpu_dm_atomic_commit_tail will retain the dc_state if none is found,
removing the dm_state should not have any consequences in fast updates.
This use-after-free bug has existed for a while now, but only caused a
noticeable issue starting from 5.7-rc1 due to 3202fa62f ("slub: relocate
freelist pointer to middle of object") moving the freelist pointer from
dm_state->base (which was unused) to dm_state->context (which is
dereferenced).
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=207383
Fixes: bd200d190f45 ("drm/amd/display: Don't replace the dc_state for fast
updates")
Reported-by: Duncan <1i5t5.dun...@cox.net>
Signed-off-by: Mazin Rezk
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 36 ++-
1 file changed, 27 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 86ffa0c2880f..710edc70e37e 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -8717,20 +8717,38 @@ static int amdgpu_dm_atomic_check(struct drm_device
*dev,
* the same resource. If we have a new DC context as part of
* the DM atomic state from validation we need to free it and
* retain the existing one instead.
+*
+* Furthermore, since the DM atomic state only contains the DC
+* context and can safely be annulled, we can free the state
+* and clear the associated private object now to free
+* some memory and avoid a possible use-after-free later.
*/
- struct dm_atomic_state *new_dm_state, *old_dm_state;
- new_dm_state = dm_atomic_get_new_state(state);
- old_dm_state = dm_atomic_get_old_state(state);
+ for (i = 0; i < state->num_private_objs; i++) {
+ struct drm_private_obj *obj =
state->private_objs[i].ptr;
- if (new_dm_state && old_dm_state) {
- if (new_dm_state->context)
- dc_release_state(new_dm_state->context);
+ if (obj->funcs == adev->dm.atomic_obj.funcs) {
+ int j = state->num_private_objs-1;
- new_dm_state->context = old_dm_state->context;
+ dm_atomic_destroy_state(obj,
+ state->private_objs[i].state);
+
+ /* If i is not at the end of the array then the
+* last element needs to be moved to where i was
+* before the array can safely be truncated.
+*/
+ if (i != j)
+ state->private_objs[i] =
+ state->private_objs[j];
- if (old_dm_state->context)
- dc_retain_state(old_dm_state->context);
+ state->private_objs[j].ptr = NULL;
+ state->private_objs[j].state = NULL;
+ state->private_objs[j].old_state = NULL;
+ state->private_objs[j].new_state = NULL;
+
+ state->num_private_objs = j;
+ break;
+ }
In the bug report itself I mentioned that I don't really like hacking
around the DRM core for resolving this patch but to go into more
specifics, it's really two issues of code maintenance:
1. It's iterating over internal structures and layout of private objects
in the state and modifying the state. The core doesn't really guarantee
how these things are going to be laid out and it may change in the future.
2. It's freeing an allocation we don
linux-next: Fixes tag needs some work in the drm-fixes tree
Hi all,
In commit
163d5446c37a ("drm/nouveau/disp/gm200-: fix regression from HDA SOR selection
changes")
Fixes tag
Fixes: 9b5ca547bb8 ("drm/nouveau/disp/gm200-: detect and potentially disable
HDA support on some SORs")
has these problem(s):
- SHA1 should be at least 12 digits long
Can be fixed by setting core.abbrev to 12 (or more) or (for git v2.11
or later) just making sure it is not set (or set to "auto").
--
Cheers,
Stephen Rothwell
pgpxEyhQBuyK7.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amd/display: Clear dm_state for fast updates
Am 27.07.20 um 07:40 schrieb Mazin Rezk:
This patch fixes a race condition that causes a use-after-free during
amdgpu_dm_atomic_commit_tail. This can occur when 2 non-blocking commits
are requested and the second one finishes before the first. Essentially,
this bug occurs when the following sequence of events happens:
1. Non-blocking commit #1 is requested w/ a new dm_state #1 and is
deferred to the workqueue.
2. Non-blocking commit #2 is requested w/ a new dm_state #2 and is
deferred to the workqueue.
3. Commit #2 starts before commit #1, dm_state #1 is used in the
commit_tail and commit #2 completes, freeing dm_state #1.
4. Commit #1 starts after commit #2 completes, uses the freed dm_state
1 and dereferences a freelist pointer while setting the context.
Well I only have a one mile high view on this, but why don't you let the
work items execute in order?
That would be better anyway cause this way we don't trigger a cache line
ping pong between CPUs.
Christian.
Since this bug has only been spotted with fast commits, this patch fixes
the bug by clearing the dm_state instead of using the old dc_state for
fast updates. In addition, since dm_state is only used for its dc_state
and amdgpu_dm_atomic_commit_tail will retain the dc_state if none is found,
removing the dm_state should not have any consequences in fast updates.
This use-after-free bug has existed for a while now, but only caused a
noticeable issue starting from 5.7-rc1 due to 3202fa62f ("slub: relocate
freelist pointer to middle of object") moving the freelist pointer from
dm_state->base (which was unused) to dm_state->context (which is
dereferenced).
Bugzilla:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.kernel.org%2Fshow_bug.cgi%3Fid%3D207383&data=02%7C01%7Cchristian.koenig%40amd.com%7C16d6d6d4a02241deb94e08d831efa1bb%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637314252605493548&sdata=JuaMFSMTjAVQBBpbXIf2RWj%2BLcx19ki25XLXbr1C6RA%3D&reserved=0
Fixes: bd200d190f45 ("drm/amd/display: Don't replace the dc_state for fast
updates")
Reported-by: Duncan <1i5t5.dun...@cox.net>
Signed-off-by: Mazin Rezk
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 36 ++-
1 file changed, 27 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 86ffa0c2880f..710edc70e37e 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -8717,20 +8717,38 @@ static int amdgpu_dm_atomic_check(struct drm_device
*dev,
* the same resource. If we have a new DC context as part of
* the DM atomic state from validation we need to free it and
* retain the existing one instead.
+*
+* Furthermore, since the DM atomic state only contains the DC
+* context and can safely be annulled, we can free the state
+* and clear the associated private object now to free
+* some memory and avoid a possible use-after-free later.
*/
- struct dm_atomic_state *new_dm_state, *old_dm_state;
- new_dm_state = dm_atomic_get_new_state(state);
- old_dm_state = dm_atomic_get_old_state(state);
+ for (i = 0; i < state->num_private_objs; i++) {
+ struct drm_private_obj *obj =
state->private_objs[i].ptr;
- if (new_dm_state && old_dm_state) {
- if (new_dm_state->context)
- dc_release_state(new_dm_state->context);
+ if (obj->funcs == adev->dm.atomic_obj.funcs) {
+ int j = state->num_private_objs-1;
- new_dm_state->context = old_dm_state->context;
+ dm_atomic_destroy_state(obj,
+ state->private_objs[i].state);
+
+ /* If i is not at the end of the array then the
+* last element needs to be moved to where i was
+* before the array can safely be truncated.
+*/
+ if (i != j)
+ state->private_objs[i] =
+ state->private_objs[j];
- if (old_dm_state->context)
- dc_retain_state(old_dm_state->context);
+ state->private_objs[j].ptr = NULL;
+ state->private_objs[j].state = NULL;
+ state->private_objs[j].old_state = NULL;
+ state->private_objs[j].new_state = NULL;
+
+ state->num_private_objs = j;
+
Re: [PATCH 2/2] drm/radeon: avoid a useless memset
Am 27.07.20 um 12:34 schrieb Christophe JAILLET:
Avoid a memset after a call to 'dma_alloc_coherent()'.
This is useless since
commit 518a2f1925c3 ("dma-mapping: zero memory returned from dma_alloc_*")
Signed-off-by: Christophe JAILLET
Reviewed-by: Christian König
---
drivers/gpu/drm/radeon/radeon_gart.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/radeon_gart.c
b/drivers/gpu/drm/radeon/radeon_gart.c
index b7ce254e5663..3808a753127b 100644
--- a/drivers/gpu/drm/radeon/radeon_gart.c
+++ b/drivers/gpu/drm/radeon/radeon_gart.c
@@ -85,7 +85,6 @@ int radeon_gart_table_ram_alloc(struct radeon_device *rdev)
}
#endif
rdev->gart.ptr = ptr;
- memset((void *)rdev->gart.ptr, 0, rdev->gart.table_size);
return 0;
}
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/radeon: switch from 'pci_' to 'dma_' API
Am 27.07.20 um 12:34 schrieb Christophe JAILLET:
The wrappers in include/linux/pci-dma-compat.h should go away.
The patch has been generated with the coccinelle script below and has been
hand modified to replace GFP_ with a correct flag.
It has been compile tested.
When memory is allocated in 'radeon_gart_table_ram_alloc()' GFP_KERNEL
can be used because its callers already use this flag.
Both 'r100_pci_gart_init()' (r100.c) and 'rs400_gart_init()' (rs400.c)
call 'radeon_gart_init()'.
This function uses 'vmalloc'.
@@
@@
-PCI_DMA_BIDIRECTIONAL
+DMA_BIDIRECTIONAL
@@
@@
-PCI_DMA_TODEVICE
+DMA_TO_DEVICE
@@
@@
-PCI_DMA_FROMDEVICE
+DMA_FROM_DEVICE
@@
@@
-PCI_DMA_NONE
+DMA_NONE
@@
expression e1, e2, e3;
@@
-pci_alloc_consistent(e1, e2, e3)
+dma_alloc_coherent(&e1->dev, e2, e3, GFP_)
@@
expression e1, e2, e3;
@@
-pci_zalloc_consistent(e1, e2, e3)
+dma_alloc_coherent(&e1->dev, e2, e3, GFP_)
@@
expression e1, e2, e3, e4;
@@
-pci_free_consistent(e1, e2, e3, e4)
+dma_free_coherent(&e1->dev, e2, e3, e4)
@@
expression e1, e2, e3, e4;
@@
-pci_map_single(e1, e2, e3, e4)
+dma_map_single(&e1->dev, e2, e3, e4)
@@
expression e1, e2, e3, e4;
@@
-pci_unmap_single(e1, e2, e3, e4)
+dma_unmap_single(&e1->dev, e2, e3, e4)
@@
expression e1, e2, e3, e4, e5;
@@
-pci_map_page(e1, e2, e3, e4, e5)
+dma_map_page(&e1->dev, e2, e3, e4, e5)
@@
expression e1, e2, e3, e4;
@@
-pci_unmap_page(e1, e2, e3, e4)
+dma_unmap_page(&e1->dev, e2, e3, e4)
@@
expression e1, e2, e3, e4;
@@
-pci_map_sg(e1, e2, e3, e4)
+dma_map_sg(&e1->dev, e2, e3, e4)
@@
expression e1, e2, e3, e4;
@@
-pci_unmap_sg(e1, e2, e3, e4)
+dma_unmap_sg(&e1->dev, e2, e3, e4)
@@
expression e1, e2, e3, e4;
@@
-pci_dma_sync_single_for_cpu(e1, e2, e3, e4)
+dma_sync_single_for_cpu(&e1->dev, e2, e3, e4)
@@
expression e1, e2, e3, e4;
@@
-pci_dma_sync_single_for_device(e1, e2, e3, e4)
+dma_sync_single_for_device(&e1->dev, e2, e3, e4)
@@
expression e1, e2, e3, e4;
@@
-pci_dma_sync_sg_for_cpu(e1, e2, e3, e4)
+dma_sync_sg_for_cpu(&e1->dev, e2, e3, e4)
@@
expression e1, e2, e3, e4;
@@
-pci_dma_sync_sg_for_device(e1, e2, e3, e4)
+dma_sync_sg_for_device(&e1->dev, e2, e3, e4)
@@
expression e1, e2;
@@
-pci_dma_mapping_error(e1, e2)
+dma_mapping_error(&e1->dev, e2)
@@
expression e1, e2;
@@
-pci_set_dma_mask(e1, e2)
+dma_set_mask(&e1->dev, e2)
@@
expression e1, e2;
@@
-pci_set_consistent_dma_mask(e1, e2)
+dma_set_coherent_mask(&e1->dev, e2)
Signed-off-by: Christophe JAILLET
Reviewed-by: Christian König
---
If needed, see post from Christoph Hellwig on the kernel-janitors ML:
https://marc.info/?l=kernel-janitors&m=158745678307186&w=4
---
drivers/gpu/drm/radeon/radeon_gart.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_gart.c
b/drivers/gpu/drm/radeon/radeon_gart.c
index f178ba321715..b7ce254e5663 100644
--- a/drivers/gpu/drm/radeon/radeon_gart.c
+++ b/drivers/gpu/drm/radeon/radeon_gart.c
@@ -72,8 +72,8 @@ int radeon_gart_table_ram_alloc(struct radeon_device *rdev)
{
void *ptr;
- ptr = pci_alloc_consistent(rdev->pdev, rdev->gart.table_size,
- &rdev->gart.table_addr);
+ ptr = dma_alloc_coherent(&rdev->pdev->dev, rdev->gart.table_size,
+&rdev->gart.table_addr, GFP_KERNEL);
if (ptr == NULL) {
return -ENOMEM;
}
@@ -110,9 +110,8 @@ void radeon_gart_table_ram_free(struct radeon_device *rdev)
rdev->gart.table_size >> PAGE_SHIFT);
}
#endif
- pci_free_consistent(rdev->pdev, rdev->gart.table_size,
- (void *)rdev->gart.ptr,
- rdev->gart.table_addr);
+ dma_free_coherent(&rdev->pdev->dev, rdev->gart.table_size,
+ (void *)rdev->gart.ptr, rdev->gart.table_addr);
rdev->gart.ptr = NULL;
rdev->gart.table_addr = 0;
}
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amd/display: Clear dm_state for fast updates
On 2020-07-27 9:39 a.m., Christian König wrote:
Am 27.07.20 um 07:40 schrieb Mazin Rezk:
This patch fixes a race condition that causes a use-after-free during
amdgpu_dm_atomic_commit_tail. This can occur when 2 non-blocking commits
are requested and the second one finishes before the first. Essentially,
this bug occurs when the following sequence of events happens:
1. Non-blocking commit #1 is requested w/ a new dm_state #1 and is
deferred to the workqueue.
2. Non-blocking commit #2 is requested w/ a new dm_state #2 and is
deferred to the workqueue.
3. Commit #2 starts before commit #1, dm_state #1 is used in the
commit_tail and commit #2 completes, freeing dm_state #1.
4. Commit #1 starts after commit #2 completes, uses the freed dm_state
1 and dereferences a freelist pointer while setting the context.
Well I only have a one mile high view on this, but why don't you let the
work items execute in order?
That would be better anyway cause this way we don't trigger a cache line
ping pong between CPUs.
Christian.
We use the DRM helpers for managing drm_atomic_commit_state and those
helpers internally push non-blocking commit work into the system unbound
work queue.
While we could duplicate a copy of that code with nothing but the
workqueue changed that isn't something I'd really like to maintain going
forward.
Regards,
Nicholas Kazlauskas
Since this bug has only been spotted with fast commits, this patch fixes
the bug by clearing the dm_state instead of using the old dc_state for
fast updates. In addition, since dm_state is only used for its dc_state
and amdgpu_dm_atomic_commit_tail will retain the dc_state if none is
found,
removing the dm_state should not have any consequences in fast updates.
This use-after-free bug has existed for a while now, but only caused a
noticeable issue starting from 5.7-rc1 due to 3202fa62f ("slub: relocate
freelist pointer to middle of object") moving the freelist pointer from
dm_state->base (which was unused) to dm_state->context (which is
dereferenced).
Bugzilla:
https://bugzilla.kernel.org/show_bug.cgi?id=207383
Fixes: bd200d190f45 ("drm/amd/display: Don't replace the dc_state for
fast updates")
Reported-by: Duncan <1i5t5.dun...@cox.net>
Signed-off-by: Mazin Rezk
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 36 ++-
1 file changed, 27 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 86ffa0c2880f..710edc70e37e 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -8717,20 +8717,38 @@ static int amdgpu_dm_atomic_check(struct
drm_device *dev,
* the same resource. If we have a new DC context as part of
* the DM atomic state from validation we need to free it and
* retain the existing one instead.
+ *
+ * Furthermore, since the DM atomic state only contains the DC
+ * context and can safely be annulled, we can free the state
+ * and clear the associated private object now to free
+ * some memory and avoid a possible use-after-free later.
*/
- struct dm_atomic_state *new_dm_state, *old_dm_state;
- new_dm_state = dm_atomic_get_new_state(state);
- old_dm_state = dm_atomic_get_old_state(state);
+ for (i = 0; i < state->num_private_objs; i++) {
+ struct drm_private_obj *obj = state->private_objs[i].ptr;
- if (new_dm_state && old_dm_state) {
- if (new_dm_state->context)
- dc_release_state(new_dm_state->context);
+ if (obj->funcs == adev->dm.atomic_obj.funcs) {
+ int j = state->num_private_objs-1;
- new_dm_state->context = old_dm_state->context;
+ dm_atomic_destroy_state(obj,
+ state->private_objs[i].state);
+
+ /* If i is not at the end of the array then the
+ * last element needs to be moved to where i was
+ * before the array can safely be truncated.
+ */
+ if (i != j)
+ state->private_objs[i] =
+ state->private_objs[j];
- if (old_dm_state->context)
- dc_retain_state(old_dm_state->context);
+ state->private_objs[j].ptr = NULL;
+ state->private_objs[j].state = NULL;
+ state->private_objs[j].old_state = NULL;
+ state->private_objs[j].new_state = NULL;
+
+ state->num_private_objs = j;
+ break;
+ }
}
}
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 208661] Backlight doesn't work with both nv_backlight and acpi_video
https://bugzilla.kernel.org/show_bug.cgi?id=208661
--- Comment #6 from Ilia Mirkin (imir...@alum.mit.edu) ---
After a lot of debugging on IRC, here are a few facts that are worth recording:
1. The nv_backlight "method" works -- i.e. the backlight is hooked up to the
GPU. Adjusting brightness via acpi_video connects to the same mechanism
somehow. We didn't dig too deep to figure out how, since it's not really
important.
2. At the start of the mmiotrace, the NVIDIA driver fixes up 0xe100
("PNVIO.GPIO_MODE_0") to be have the 0x4 bit set of the SOR mask. On bootup
it's 0x00180100, while it should be 0x001c0100.
3. This is equivalent to what we do in nv50_gpio_reset. This function is called
in response to the "GPIO" init table method (which, one might mention, is
present in the init tables).
4. Manually setting this value (via nvapoke) makes nv_backlight work. Doing
suspend/resume, which causes init tables to be re-run, makes nv_backlight also
work, since the init table contains the GPIO opcode.
5. Regular boot with NvForcePost=1 kills the panel (and maybe other things).
Not sure what the solution is. Right now we run nv50_gpio_reset unconditionally
on MBP10,1. We can start extending the DMI table with random laptops, or maybe
we can just run that function unconditionally. Is there a downside?
--
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: [v7, PATCH 7/7] drm/mediatek: add support for mediatek SOC MT8183
Hi, Yongqiang:
Yongqiang Niu 於 2020年7月27日 週一 下午3:54寫道：
>
> On Sat, 2020-07-25 at 07:24 +0800, Chun-Kuang Hu wrote:
> > Hi Yongqiang:
> >
> > Yongqiang Niu 於 2020年7月23日 週四 上午10:15寫道：
> > >
> > > This patch add support for mediatek SOC MT8183
> > > 1.ovl_2l share driver with ovl
> >
> > I think this is done in [1], [2], [3], this patch just add the support
> > of mt8183-ovl and mt8183-ovl-2l.
> >
> > [1]
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/gpu/drm/mediatek?h=v5.8-rc6&id=132c6e250ed745443973cada8db17cdbaebdf551
> > [2]
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/gpu/drm/mediatek?h=v5.8-rc6&id=318462d1a568634ba09263cc730cb0fb1d56c2b3
> > [3]
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/gpu/drm/mediatek?h=v5.8-rc6&id=57148baac8b78461e394953cfd5317bde8f795ab
> >
> > > 2.rdma1 share drive with rdma0, but fifo size is different
> >
> > I think this is done in [4], this patch just add the support of mt8183-rdma.
> >
> > [4] https://patchwork.kernel.org/patch/11679549/
> >
> > > 3.add mt8183 mutex private data, and mmsys private data
> > > 4.add mt8183 main and external path module for crtc create
> >
> > The fourth item is the mmsys private data in third item, so you need
> > not to repeat it.
> >
> > >
> > > Signed-off-by: Yongqiang Niu
> > > ---
> > > drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 18
> > > drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 6
> > > drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 47
> > >
> > > drivers/gpu/drm/mediatek/mtk_drm_drv.c | 43
> > > +
> > > 4 files changed, 114 insertions(+)
> > >
> >
> > [snip]
> >
> > > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> > > b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> > > index 014c1bb..60788c1 100644
> > > --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> > > +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> > > @@ -15,6 +15,8 @@
> > >
> > > #define MT2701_DISP_MUTEX0_MOD00x2c
> > > #define MT2701_DISP_MUTEX0_SOF00x30
> > > +#define MT8183_DISP_MUTEX0_MOD00x30
> > > +#define MT8183_DISP_MUTEX0_SOF00x2c
> > >
> > > #define DISP_REG_MUTEX_EN(n) (0x20 + 0x20 * (n))
> > > #define DISP_REG_MUTEX(n) (0x24 + 0x20 * (n))
> > > @@ -25,6 +27,18 @@
> > >
> > > #define INT_MUTEX BIT(1)
> > >
> > > +#define MT8183_MUTEX_MOD_DISP_RDMA00
> > > +#define MT8183_MUTEX_MOD_DISP_RDMA11
> > > +#define MT8183_MUTEX_MOD_DISP_OVL0 9
> > > +#define MT8183_MUTEX_MOD_DISP_OVL0_2L 10
> > > +#define MT8183_MUTEX_MOD_DISP_OVL1_2L 11
> > > +#define MT8183_MUTEX_MOD_DISP_WDMA012
> > > +#define MT8183_MUTEX_MOD_DISP_COLOR0 13
> > > +#define MT8183_MUTEX_MOD_DISP_CCORR0 14
> > > +#define MT8183_MUTEX_MOD_DISP_AAL0 15
> > > +#define MT8183_MUTEX_MOD_DISP_GAMMA0 16
> > > +#define MT8183_MUTEX_MOD_DISP_DITHER0 17
> > > +
> > > #define MT8173_MUTEX_MOD_DISP_OVL0 11
> > > #define MT8173_MUTEX_MOD_DISP_OVL1 12
> > > #define MT8173_MUTEX_MOD_DISP_RDMA013
> > > @@ -74,6 +88,10 @@
> > > #define MUTEX_SOF_DSI2 5
> > > #define MUTEX_SOF_DSI3 6
> > >
> > > +#define MT8183_MUTEX_SOF_DPI0 2
> > > +#define MT8183_MUTEX_EOF_DSI0 (MUTEX_SOF_DSI0 << 6)
> > > +#define MT8183_MUTEX_EOF_DPI0 (MT8183_MUTEX_SOF_DPI0 <<
> > > 6)
> > > +
> > >
> > > struct mtk_disp_mutex {
> > > int id;
> > > @@ -153,6 +171,20 @@ struct mtk_ddp {
> > > [DDP_COMPONENT_WDMA1] = MT8173_MUTEX_MOD_DISP_WDMA1,
> > > };
> > >
> > > +static const unsigned int mt8183_mutex_mod[DDP_COMPONENT_ID_MAX] = {
> > > + [DDP_COMPONENT_AAL0] = MT8183_MUTEX_MOD_DISP_AAL0,
> > > + [DDP_COMPONENT_CCORR] = MT8183_MUTEX_MOD_DISP_CCORR0,
> > > + [DDP_COMPONENT_COLOR0] = MT8183_MUTEX_MOD_DISP_COLOR0,
> > > + [DDP_COMPONENT_DITHER] = MT8183_MUTEX_MOD_DISP_DITHER0,
> > > + [DDP_COMPONENT_GAMMA] = MT8183_MUTEX_MOD_DISP_GAMMA0,
> > > + [DDP_COMPONENT_OVL0] = MT8183_MUTEX_MOD_DISP_OVL0,
> > > + [DDP_COMPONENT_OVL_2L0] = MT8183_MUTEX_MOD_DISP_OVL0_2L,
> > > + [DDP_COMPONENT_OVL_2L1] = MT8183_MUTEX_MOD_DISP_OVL1_2L,
> > > + [DDP_COMPONENT_RDMA0] = MT8183_MUTEX_MOD_DISP_RDMA0,
> > > + [DDP_COMPONENT_RDMA1] = MT8183_MUTEX_MOD_DISP_RDMA1,
> > > + [DDP_COMPONENT_WDMA0] = MT8183_MUTEX_MOD_DISP_WDMA0,
> > > +};
> > > +
> > > static const unsigned int mt2712_mutex_sof[DDP_MUTEX_SOF_DSI3 + 1] = {
> > > [DDP_MUTEX_SOF_SINGLE_MODE] = MUTEX_SOF_SINGLE_MODE,
> > > [DDP_MUTEX_SOF_DSI0] = MUTEX_SOF_DSI0,
> > > @@ -163,6 +195,12 @@ struct mtk_ddp {
>
Re: [PATCH v2] drm/drm_fb_helper: fix fbdev with sparc64
Hi Daniel
On Mon, Jul 27, 2020 at 11:20:13AM +0200, Daniel Vetter wrote:
> On Sat, Jul 25, 2020 at 9:10 PM Sam Ravnborg wrote:
> >
> > From 1323a7433691aee112a9b2df8041b5024895a77e Mon Sep 17 00:00:00 2001
> > From: Sam Ravnborg
> > Date: Thu, 9 Jul 2020 21:30:16 +0200
> > Subject: [PATCH v2 1/1] drm/drm_fb_helper: fix fbdev with sparc64
> >
> > Recent kernels have been reported to panic using the bochs_drm framebuffer
> > under
> > qemu-system-sparc64 which was bisected to commit 7a0483ac4ffc "drm/bochs:
> > switch to
> > generic drm fbdev emulation". The backtrace indicates that the shadow
> > framebuffer
> > copy in drm_fb_helper_dirty_blit_real() is trying to access the real
> > framebuffer
> > using a virtual address rather than use an IO access typically implemented
> > using a
> > physical (ASI_PHYS) access on SPARC.
> >
> > The fix is to replace the memcpy with memcpy_toio() from io.h.
> >
> > memcpy_toio() uses writeb() where the original fbdev code
> > used sbus_memcpy_toio(). The latter uses sbus_writeb().
> >
> > The difference between writeb() and sbus_memcpy_toio() is
> > that writeb() writes bytes in little-endian, where sbus_writeb() writes
> > bytes in big-endian. As endian does not matter for byte writes they are
> > the same. So we can safely use memcpy_toio() here.
> >
> > For many architectures memcpy_toio() is a simple memcpy().
> > One side-effect that is unknown is if this has any impact on other
> > architectures.
> > So far the analysis tells that this change is OK for other arch's.
> > but testing would be good.
>
> The rules are that officially we have to use the io functions for
> __mmio pointers. We just drop these sparse annotations on the floor.
> I'd replace this with something like:
>
> "Note that this only fixes bochs, in general fbdev helpers still have
> issues with mixing up system memory and mmio space. Fixing that will
> require a lot more work."
OK, done.
>
> > v2:
> > - Added missing __iomem cast (kernel test robot)
> > - Made changelog readable and fix typos (Mark)
> > - Add flag to select iomem - and set it in the bochs driver
> >
> > Signed-off-by: Sam Ravnborg
> > Reported-by: Mark Cave-Ayland
> > Reported-by: kernel test robot
> > Tested-by: Mark Cave-Ayland
> > Cc: Mark Cave-Ayland
> > Cc: Thomas Zimmermann
> > Cc: Gerd Hoffmann
> > Cc: "David S. Miller"
> > Cc: sparcli...@vger.kernel.org
> > Link:
> > https://patchwork.freedesktop.org/patch/msgid/20200709193016.291267-1-...@ravnborg.org
> > ---
> >
> > This fix introducing a flag in mode_config is at best a band-aid
> > solution until we have a proper fix.
> > We need to propagate the info about iomem so it is not a driver flag
> > thing.
> >
> > There is also the issue with sys* versus cfb* functions, where cfb*
> > functions are used for iomem.
> > I did not manage to make the bochs driver work with the cfb* functions,
> > for some unknown reason booting would be stuck waiting for the console
> > mutex when usign the cfb* functions.
> >
> > I consider this fix OK to get the kernel working for sparc64 with the
> > bochs driver for now. And with the fbdev_uses_iomem flag no other
> > drivers will see any changes.
> >
> > Sam
> >
> > drivers/gpu/drm/bochs/bochs_kms.c | 1 +
> > drivers/gpu/drm/drm_fb_helper.c | 6 +-
> > include/drm/drm_mode_config.h | 9 +
> > 3 files changed, 15 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/bochs/bochs_kms.c
> > b/drivers/gpu/drm/bochs/bochs_kms.c
> > index 05d8373888e8..079f46f5cdb6 100644
> > --- a/drivers/gpu/drm/bochs/bochs_kms.c
> > +++ b/drivers/gpu/drm/bochs/bochs_kms.c
> > @@ -146,6 +146,7 @@ int bochs_kms_init(struct bochs_device *bochs)
> > bochs->dev->mode_config.preferred_depth = 24;
> > bochs->dev->mode_config.prefer_shadow = 0;
> > bochs->dev->mode_config.prefer_shadow_fbdev = 1;
> > + bochs->dev->mode_config.fbdev_use_iomem = true;
> > bochs->dev->mode_config.quirk_addfb_prefer_host_byte_order = true;
> >
> > bochs->dev->mode_config.funcs = &bochs_mode_funcs;
> > diff --git a/drivers/gpu/drm/drm_fb_helper.c
> > b/drivers/gpu/drm/drm_fb_helper.c
> > index 5609e164805f..89cfd68ef400 100644
> > --- a/drivers/gpu/drm/drm_fb_helper.c
> > +++ b/drivers/gpu/drm/drm_fb_helper.c
> > @@ -399,7 +399,11 @@ static void drm_fb_helper_dirty_blit_real(struct
> > drm_fb_helper *fb_helper,
> > unsigned int y;
> >
> > for (y = clip->y1; y < clip->y2; y++) {
> > - memcpy(dst, src, len);
> > + if (!fb_helper->dev->mode_config.fbdev_use_iomem)
> > + memcpy(dst, src, len);
> > + else
> > + memcpy_toio((void __iomem *)dst, src, len);
> > +
> > src += fb->pitches[0];
> > dst += fb->pitches[0];
> > }
> > diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
> > index 6c3ef49b46b3..c24c066bdd9c 100644
> >
Re: [PATCH v3 4/4] xen: add helpers to allocate unpopulated memory
On 27.07.20 11:13, Roger Pau Monne wrote:
To be used in order to create foreign mappings. This is based on the
ZONE_DEVICE facility which is used by persistent memory devices in
order to create struct pages and kernel virtual mappings for the IOMEM
areas of such devices. Note that on kernels without support for
ZONE_DEVICE Xen will fallback to use ballooned pages in order to
create foreign mappings.
The newly added helpers use the same parameters as the existing
{alloc/free}_xenballooned_pages functions, which allows for in-place
replacement of the callers. Once a memory region has been added to be
used as scratch mapping space it will no longer be released, and pages
returned are kept in a linked list. This allows to have a buffer of
pages and prevents resorting to frequent additions and removals of
regions.
If enabled (because ZONE_DEVICE is supported) the usage of the new
functionality untangles Xen balloon and RAM hotplug from the usage of
unpopulated physical memory ranges to map foreign pages, which is the
correct thing to do in order to avoid mappings of foreign pages depend
on memory hotplug.
Signed-off-by: Roger Pau Monné
---
I've not added a new memory_type type and just used
MEMORY_DEVICE_DEVDAX which seems to be what we want for such memory
regions. I'm unsure whether abusing this type is fine, or if I should
instead add a specific type, maybe MEMORY_DEVICE_GENERIC? I don't
think we should be using a specific Xen type at all.
What about introducing MEMORY_DEVICE_VIRT? The comment for
MEMORY_DEVICE_DEVDAX doesn't really fit, as there is no character device
involved.
In the end its the memory management maintainers to decide that.
Other than that you can have my
Reviewed-by: Juergen Gross
Juergen
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 208661] Backlight doesn't work with both nv_backlight and acpi_video
https://bugzilla.kernel.org/show_bug.cgi?id=208661 --- Comment #7 from Shannon Gaines (iknstu...@protonmail.com) --- Created attachment 290619 --> https://bugzilla.kernel.org/attachment.cgi?id=290619&action=edit Patch to add NvForceGpioReset config option I created a patch that allows users to force a GPIO reset everytime the GPU is initialized as a work-around for this bug. I've attached it. -- 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 v4 08/15] drm/bridge: parade-ps8622: add drm_panel_bridge support
Hi Laurent.
On Mon, Jul 27, 2020 at 12:54:08AM +0300, Laurent Pinchart wrote:
> Hi Sam,
>
> Thank you for the patch.
>
> On Sun, Jul 26, 2020 at 10:33:17PM +0200, Sam Ravnborg wrote:
> > Prepare the bridge driver for use in a chained setup by
> > replacing direct use of drm_panel with drm_panel_bridge support.
> >
> > The connecter is now either created by the panel bridge or the display
> > driver. So all code for connector creation in this driver is no longer
> > relevant and thus dropped.
> >
> > The connector code had some special polling handling:
> > connector.polled = DRM_CONNECTOR_POLL_HPD;
> > drm_helper_hpd_irq_event(ps8622->bridge.dev);
> >
> > This code was most likely added to speed up detection of the connector.
> > If really needed then this functionality belongs somewhere else.
> >
> > Note: the bridge panel will use the connector type from the panel.
> >
> > v2:
> > - Fix to avoid creating connector twice (Laurent)
> > - Drop all connector code - defer to bridge panel
> > - Use panel_bridge for local variable to align with other drivers
> > - Set bridge.type to DRM_MODE_CONNECTOR_LVDS;
> >
> > Signed-off-by: Sam Ravnborg
> > Cc: Andrzej Hajda
> > Cc: Neil Armstrong
> > Cc: Laurent Pinchart
> > Cc: Jonas Karlman
> > Cc: Jernej Skrabec
> > ---
> > drivers/gpu/drm/bridge/parade-ps8622.c | 100 -
> > 1 file changed, 13 insertions(+), 87 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/bridge/parade-ps8622.c
> > b/drivers/gpu/drm/bridge/parade-ps8622.c
> > index d789ea2a7fb9..614b19f0f1b7 100644
> > --- a/drivers/gpu/drm/bridge/parade-ps8622.c
> > +++ b/drivers/gpu/drm/bridge/parade-ps8622.c
> > @@ -42,10 +42,9 @@
> > #endif
> >
> > struct ps8622_bridge {
> > - struct drm_connector connector;
> > struct i2c_client *client;
> > struct drm_bridge bridge;
> > - struct drm_panel *panel;
> > + struct drm_bridge *panel_bridge;
> > struct regulator *v12;
> > struct backlight_device *bl;
> >
> > @@ -64,12 +63,6 @@ static inline struct ps8622_bridge *
> > return container_of(bridge, struct ps8622_bridge, bridge);
> > }
> >
> > -static inline struct ps8622_bridge *
> > - connector_to_ps8622(struct drm_connector *connector)
> > -{
> > - return container_of(connector, struct ps8622_bridge, connector);
> > -}
> > -
> > static int ps8622_set(struct i2c_client *client, u8 page, u8 reg, u8 val)
> > {
> > int ret;
> > @@ -365,11 +358,6 @@ static void ps8622_pre_enable(struct drm_bridge
> > *bridge)
> > DRM_ERROR("fails to enable ps8622->v12");
> > }
> >
> > - if (drm_panel_prepare(ps8622->panel)) {
> > - DRM_ERROR("failed to prepare panel\n");
> > - return;
> > - }
> > -
> > gpiod_set_value(ps8622->gpio_slp, 1);
> >
> > /*
> > @@ -399,24 +387,9 @@ static void ps8622_pre_enable(struct drm_bridge
> > *bridge)
> > ps8622->enabled = true;
> > }
> >
> > -static void ps8622_enable(struct drm_bridge *bridge)
> > -{
> > - struct ps8622_bridge *ps8622 = bridge_to_ps8622(bridge);
> > -
> > - if (drm_panel_enable(ps8622->panel)) {
> > - DRM_ERROR("failed to enable panel\n");
> > - return;
> > - }
> > -}
> > -
> > static void ps8622_disable(struct drm_bridge *bridge)
> > {
> > - struct ps8622_bridge *ps8622 = bridge_to_ps8622(bridge);
> > -
> > - if (drm_panel_disable(ps8622->panel)) {
> > - DRM_ERROR("failed to disable panel\n");
> > - return;
> > - }
> > + /* Delay after panel is disabled */
> > msleep(PS8622_PWMO_END_T12_MS);
>
> I really don't understand why a delay would be needed here.
>
Neither do I. I was there in the original code and I have kept it.
> Reviewed-by: Laurent Pinchart
Thanks.
Sam
>
> > }
> >
> > @@ -436,11 +409,6 @@ static void ps8622_post_disable(struct drm_bridge
> > *bridge)
> > */
> > gpiod_set_value(ps8622->gpio_slp, 0);
> >
> > - if (drm_panel_unprepare(ps8622->panel)) {
> > - DRM_ERROR("failed to unprepare panel\n");
> > - return;
> > - }
> > -
> > if (ps8622->v12)
> > regulator_disable(ps8622->v12);
> >
> > @@ -455,67 +423,17 @@ static void ps8622_post_disable(struct drm_bridge
> > *bridge)
> > msleep(PS8622_POWER_OFF_T17_MS);
> > }
> >
> > -static int ps8622_get_modes(struct drm_connector *connector)
> > -{
> > - struct ps8622_bridge *ps8622;
> > -
> > - ps8622 = connector_to_ps8622(connector);
> > -
> > - return drm_panel_get_modes(ps8622->panel, connector);
> > -}
> > -
> > -static const struct drm_connector_helper_funcs
> > ps8622_connector_helper_funcs = {
> > - .get_modes = ps8622_get_modes,
> > -};
> > -
> > -static const struct drm_connector_funcs ps8622_connector_funcs = {
> > - .fill_modes = drm_helper_probe_single_connector_modes,
> > - .destroy = drm_connector_cleanup,
> > - .reset = drm_atomic_helper_connector_reset,
> > - .atomic_duplicate_state =
[Bug 207901] Nouveau: In a 4 monitor setup, 1-2 displays remains black after boot
https://bugzilla.kernel.org/show_bug.cgi?id=207901 --- Comment #26 from Maurice Gale (mauricega...@gmail.com) --- Sorry for the delay and the mistake. It loaded the 5.3 kernel by default. I recreated the log using 5.7-rc5 with the i2c timeout patch. I also added the new grub options. The file size is much larger than the old one, so it should be correct this time. I noticed that I have more luck getting all monitors displayed when I do not have the Display->MiniDisplay connected (Swap it out for Display->HDMI). It seems as though mini display is causing some issues. Again, thank you so much for your help, and please let me know if you need anything else. -- 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 207901] Nouveau: In a 4 monitor setup, 1-2 displays remains black after boot
https://bugzilla.kernel.org/show_bug.cgi?id=207901 --- Comment #27 from Ilia Mirkin (imir...@alum.mit.edu) --- DP -> HDMI is, most likely, just passive, so the displays are being driven as HDMI rather than as DP. DP is the problematic protocol... -- 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 204241] amdgpu fails to resume from suspend
https://bugzilla.kernel.org/show_bug.cgi?id=204241 felipejfc (fjfcavalca...@gmail.com) changed: What|Removed |Added CC||fjfcavalca...@gmail.com --- Comment #63 from felipejfc (fjfcavalca...@gmail.com) --- I'm having the same issue with an AMD RX5700 and kernel version 5.7.9-1 on manjaro linux. for me adding kernel params 'amd_iommu=on iommu=pt' didn't solve the problem. graphics won't turn on so monitor just keeps blinking -- 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 204241] amdgpu fails to resume from suspend
https://bugzilla.kernel.org/show_bug.cgi?id=204241 --- Comment #64 from felipejfc (fjfcavalca...@gmail.com) --- (In reply to felipejfc from comment #63) > I'm having the same issue with an AMD RX5700 and kernel version 5.7.9-1 on > manjaro linux. > > for me adding kernel params 'amd_iommu=on iommu=pt' didn't solve the > problem. graphics won't turn on so monitor just keeps blinking complementing my last answer, the "fix" that worked for me was to disable IOMMU on BIOS -- 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 207383] [Regression] 5.7 amdgpu/polaris11 gpf: amdgpu_atomic_commit_tail
https://bugzilla.kernel.org/show_bug.cgi?id=207383 --- Comment #101 from Duncan (1i5t5.dun...@cox.net) --- (In reply to Nicholas Kazlauskas from comment #95) > Created attachment 290583 [details] > 0001-drm-amd-display-Force-add-all-CRTCs-to-state-when-us.patch Just booted to 5.8-rc7 with this patched in locally (and the g320+ reverts /not/ patched in). So testing, but noting again that the bug can take a couple days to trigger on my hardware, so while verifying bug-still-there /might/ be fast, verifying that it's /not/ there will take awhile. If this still bugs on me (and barring other developments first) I'll try mnrzk's patch in place of this one. Even if it's not permanent, getting it into 5.8 as a temporary fix and doing something better for 5.9 would buy us some time to develop and test the more permanent fix. -- 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 v4 0/15] drm/bridge: support chained bridges + panel updates
Hi Laurent/all. On Sun, Jul 26, 2020 at 10:33:09PM +0200, Sam Ravnborg wrote: > The objective is that all bridge drivers shall support a chained setup > connector creation is moved to the display drivers. > This is just one step on this path. > > The general approach for the bridge drivers: > - Introduce bridge operations > - Introduce use of panel bridge and make connector creation optional > > v4: > - Dropped patch for ti-sn65dsi86. Await full conversion. > - Dropped patch for ti-tpd12s015. It was wrong (Laurent) > - Drop boe,hv070wsa-100 patch, it was applied > - Combined a few patches to fix connector created twice (Laurent) > - Fix memory leak in get_edid in several drivers (Laurent) > - Added patch to validate panel descriptions in panel-simple > - Set bridge.type in relevant drivers > > v3: > - Rebase on top of drm-misc-next > - Address kbuild test robot feedback > > v2: > - Updated bus_flags for boe,hv070wsa-100 > - Collected r-b, but did not apply patches yet > - On the panel side the panel-simple driver gained a default > connector type for all the dumb panels that do not > include so in their description. > With this change panels always provide a connector type, > and we have the potential to drop most uses of > devm_drm_panel_bridge_add_typed(). > - Added conversion of a few more bridge drivers > > Patches can build but no run-time testing. > So both test and review feedback appreciated! > > Sam > > Sam Ravnborg (15): > drm/panel: panel-simple: validate panel description > drm/panel: panel-simple: add default connector_type > drm/bridge: tc358764: drop drm_connector_(un)register > drm/bridge: tc358764: add drm_panel_bridge support > drm/bridge: tc358767: add detect bridge operation > drm/bridge: tc358767: add get_edid bridge operation > drm/bridge: tc358767: add drm_panel_bridge support > drm/bridge: parade-ps8622: add drm_panel_bridge support > drm/bridge: megachips: add helper to create connector > drm/bridge: megachips: get drm_device from bridge > drm/bridge: megachips: enable detect bridge operation > drm/bridge: megachips: add get_edid bridge operation > drm/bridge: megachips: make connector creation optional > drm/bridge: nxp-ptn3460: add get_edid bridge operation > drm/bridge: nxp-ptn3460: add drm_panel_bridge support Laurent reviewed the full series - thanks! I went ahead and applied the patches for drivers where all patches was reviewed. I will send a v5 soon for tc358767 and nxp-ptn3460 where I have fixed my brown paper bag bugs . I am very happy Laurent spotted these before we applied the patches. This also gives a good indication of the quality of the review. Sam > > .../drm/bridge/megachips-stdp-ge-b850v3-fw.c | 97 +--- > drivers/gpu/drm/bridge/nxp-ptn3460.c | 103 - > drivers/gpu/drm/bridge/parade-ps8622.c | 100 +++- > drivers/gpu/drm/bridge/tc358764.c | 110 +++--- > drivers/gpu/drm/bridge/tc358767.c | 126 > +++-- > drivers/gpu/drm/panel/panel-simple.c | 48 +++- > 6 files changed, 242 insertions(+), 342 deletions(-) > > > ___ > 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
Re: [PATCH 2/6] drm: dsi: Let host and device specify supported bus
Hi Paul,
Thank you for the patch.
On Mon, Jul 27, 2020 at 06:46:09PM +0200, Paul Cercueil wrote:
> The current MIPI DSI framework can very well be used to support MIPI DBI
> panels. In order to add support for the various bus types supported by
> DBI, the DRM panel drivers should specify the bus type they will use,
> and the DSI host drivers should specify the bus types they are
> compatible with.
>
> The DSI host driver can then use the information provided by the DBI/DSI
> device driver, such as the bus type and the number of lanes, to
> configure its hardware properly.
>
> Signed-off-by: Paul Cercueil
> ---
> drivers/gpu/drm/drm_mipi_dsi.c | 9 +
> include/drm/drm_mipi_dsi.h | 12
Use the mipi_dsi_* API for DBI panels will be very confusing to say the
least. Can we consider a global name refactoring to clarify all this ?
> 2 files changed, 21 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_mipi_dsi.c b/drivers/gpu/drm/drm_mipi_dsi.c
> index 5dd475e82995..11ef885de765 100644
> --- a/drivers/gpu/drm/drm_mipi_dsi.c
> +++ b/drivers/gpu/drm/drm_mipi_dsi.c
> @@ -281,6 +281,9 @@ int mipi_dsi_host_register(struct mipi_dsi_host *host)
> {
> struct device_node *node;
>
> + if (WARN_ON_ONCE(!host->bus_types))
> + host->bus_types = MIPI_DEVICE_TYPE_DSI;
> +
> for_each_available_child_of_node(host->dev->of_node, node) {
> /* skip nodes without reg property */
> if (!of_find_property(node, "reg", NULL))
> @@ -323,6 +326,12 @@ int mipi_dsi_attach(struct mipi_dsi_device *dsi)
> {
> const struct mipi_dsi_host_ops *ops = dsi->host->ops;
>
> + if (WARN_ON_ONCE(!dsi->bus_type))
> + dsi->bus_type = MIPI_DEVICE_TYPE_DSI;
> +
> + if (!(dsi->bus_type & dsi->host->bus_types))
> + return -EINVAL;
> +
> if (!ops || !ops->attach)
> return -ENOSYS;
>
> diff --git a/include/drm/drm_mipi_dsi.h b/include/drm/drm_mipi_dsi.h
> index 360e6377e84b..65d2961fc054 100644
> --- a/include/drm/drm_mipi_dsi.h
> +++ b/include/drm/drm_mipi_dsi.h
> @@ -63,6 +63,14 @@ struct mipi_dsi_packet {
> int mipi_dsi_create_packet(struct mipi_dsi_packet *packet,
> const struct mipi_dsi_msg *msg);
>
> +/* MIPI bus types */
> +#define MIPI_DEVICE_TYPE_DSI BIT(0)
> +#define MIPI_DEVICE_TYPE_DBI_SPI_MODE1 BIT(1)
> +#define MIPI_DEVICE_TYPE_DBI_SPI_MODE2 BIT(2)
> +#define MIPI_DEVICE_TYPE_DBI_SPI_MODE3 BIT(3)
> +#define MIPI_DEVICE_TYPE_DBI_M6800 BIT(4)
> +#define MIPI_DEVICE_TYPE_DBI_I8080 BIT(5)
> +
> /**
> * struct mipi_dsi_host_ops - DSI bus operations
> * @attach: attach DSI device to DSI host
> @@ -94,11 +102,13 @@ struct mipi_dsi_host_ops {
> * struct mipi_dsi_host - DSI host device
> * @dev: driver model device node for this DSI host
> * @ops: DSI host operations
> + * @bus_types: Bitmask of supported MIPI bus types
> * @list: list management
> */
> struct mipi_dsi_host {
> struct device *dev;
> const struct mipi_dsi_host_ops *ops;
> + unsigned int bus_types;
> struct list_head list;
> };
>
> @@ -162,6 +172,7 @@ struct mipi_dsi_device_info {
> * @host: DSI host for this peripheral
> * @dev: driver model device node for this peripheral
> * @name: DSI peripheral chip type
> + * @bus_type: MIPI bus type (MIPI_DEVICE_TYPE_DSI/...)
> * @channel: virtual channel assigned to the peripheral
> * @format: pixel format for video mode
> * @lanes: number of active data lanes
> @@ -178,6 +189,7 @@ struct mipi_dsi_device {
> struct device dev;
>
> char name[DSI_DEV_NAME_SIZE];
> + unsigned int bus_type;
> unsigned int channel;
> unsigned int lanes;
> enum mipi_dsi_pixel_format format;
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 1/5] drm/bridge: tc358767: add detect bridge operation
Prepare the bridge driver for chained operation by adding
support for the detect operation.
v3:
- Fix code to make it readable (Laurent)
v2:
- Do not announce detect operation if there is no hpd pin (Laurent)
Signed-off-by: Sam Ravnborg
Reviewed-by: Laurent Pinchart
Cc: Andrzej Hajda
Cc: Neil Armstrong
Cc: Laurent Pinchart
Cc: Jonas Karlman
Cc: Jernej Skrabec
---
drivers/gpu/drm/bridge/tc358767.c | 30 --
1 file changed, 20 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/bridge/tc358767.c
b/drivers/gpu/drm/bridge/tc358767.c
index c2777b226c75..bde89e213882 100644
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -1369,21 +1369,13 @@ static const struct drm_connector_helper_funcs
tc_connector_helper_funcs = {
.get_modes = tc_connector_get_modes,
};
-static enum drm_connector_status tc_connector_detect(struct drm_connector
*connector,
-bool force)
+static enum drm_connector_status tc_bridge_detect(struct drm_bridge *bridge)
{
- struct tc_data *tc = connector_to_tc(connector);
+ struct tc_data *tc = bridge_to_tc(bridge);
bool conn;
u32 val;
int ret;
- if (tc->hpd_pin < 0) {
- if (tc->panel)
- return connector_status_connected;
- else
- return connector_status_unknown;
- }
-
ret = regmap_read(tc->regmap, GPIOI, &val);
if (ret)
return connector_status_unknown;
@@ -1396,6 +1388,20 @@ static enum drm_connector_status
tc_connector_detect(struct drm_connector *conne
return connector_status_disconnected;
}
+static enum drm_connector_status
+tc_connector_detect(struct drm_connector *connector, bool force)
+{
+ struct tc_data *tc = connector_to_tc(connector);
+
+ if (tc->hpd_pin >= 0)
+ return tc_bridge_detect(&tc->bridge);
+
+ if (tc->panel)
+ return connector_status_connected;
+ else
+ return connector_status_unknown;
+}
+
static const struct drm_connector_funcs tc_connector_funcs = {
.detect = tc_connector_detect,
.fill_modes = drm_helper_probe_single_connector_modes,
@@ -1458,6 +1464,7 @@ static const struct drm_bridge_funcs tc_bridge_funcs = {
.disable = tc_bridge_disable,
.post_disable = tc_bridge_post_disable,
.mode_fixup = tc_bridge_mode_fixup,
+ .detect = tc_bridge_detect,
};
static bool tc_readable_reg(struct device *dev, unsigned int reg)
@@ -1680,6 +1687,9 @@ static int tc_probe(struct i2c_client *client, const
struct i2c_device_id *id)
return ret;
tc->bridge.funcs = &tc_bridge_funcs;
+ if (tc->hpd_pin >= 0)
+ tc->bridge.ops |= DRM_BRIDGE_OP_DETECT;
+
tc->bridge.of_node = dev->of_node;
drm_bridge_add(&tc->bridge);
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 4/5] drm/bridge: nxp-ptn3460: add get_edid bridge operation
Add the get_edid() bridge operation to prepare for
use as a chained bridge.
Add helper function that is also used by the connector.
v2:
- Fix memory leak (Laurent)
- Do not save a copy of edid, read it when needed
Signed-off-by: Sam Ravnborg
Reviewed-by: Laurent Pinchart
Cc: Andrzej Hajda
Cc: Neil Armstrong
Cc: Laurent Pinchart
Cc: Jonas Karlman
Cc: Jernej Skrabec
---
drivers/gpu/drm/bridge/nxp-ptn3460.c | 43
1 file changed, 25 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/bridge/nxp-ptn3460.c
b/drivers/gpu/drm/bridge/nxp-ptn3460.c
index 438e566ce0a4..2805c8938f98 100644
--- a/drivers/gpu/drm/bridge/nxp-ptn3460.c
+++ b/drivers/gpu/drm/bridge/nxp-ptn3460.c
@@ -29,7 +29,6 @@ struct ptn3460_bridge {
struct drm_connector connector;
struct i2c_client *client;
struct drm_bridge bridge;
- struct edid *edid;
struct drm_panel *panel;
struct gpio_desc *gpio_pd_n;
struct gpio_desc *gpio_rst_n;
@@ -184,17 +183,13 @@ static void ptn3460_post_disable(struct drm_bridge
*bridge)
}
}
-static int ptn3460_get_modes(struct drm_connector *connector)
+static struct edid *ptn3460_get_edid(struct drm_bridge *bridge,
+struct drm_connector *connector)
{
- struct ptn3460_bridge *ptn_bridge;
- u8 *edid;
- int ret, num_modes = 0;
+ struct ptn3460_bridge *ptn_bridge = bridge_to_ptn3460(bridge);
bool power_off;
-
- ptn_bridge = connector_to_ptn3460(connector);
-
- if (ptn_bridge->edid)
- return drm_add_edid_modes(connector, ptn_bridge->edid);
+ u8 *edid;
+ int ret;
power_off = !ptn_bridge->enabled;
ptn3460_pre_enable(&ptn_bridge->bridge);
@@ -202,30 +197,40 @@ static int ptn3460_get_modes(struct drm_connector
*connector)
edid = kmalloc(EDID_LENGTH, GFP_KERNEL);
if (!edid) {
DRM_ERROR("Failed to allocate EDID\n");
- return 0;
+ goto out;
}
ret = ptn3460_read_bytes(ptn_bridge, PTN3460_EDID_ADDR, edid,
- EDID_LENGTH);
+EDID_LENGTH);
if (ret) {
kfree(edid);
+ edid = NULL;
goto out;
}
- ptn_bridge->edid = (struct edid *)edid;
- drm_connector_update_edid_property(connector, ptn_bridge->edid);
-
- num_modes = drm_add_edid_modes(connector, ptn_bridge->edid);
-
out:
if (power_off)
ptn3460_disable(&ptn_bridge->bridge);
+ return (struct edid *)edid;
+}
+
+static int ptn3460_connector_get_modes(struct drm_connector *connector)
+{
+ struct ptn3460_bridge *ptn_bridge = connector_to_ptn3460(connector);
+ struct edid *edid;
+ int num_modes;
+
+ edid = ptn3460_get_edid(&ptn_bridge->bridge, connector);
+ drm_connector_update_edid_property(connector, edid);
+ num_modes = drm_add_edid_modes(connector, edid);
+ kfree(edid);
+
return num_modes;
}
static const struct drm_connector_helper_funcs ptn3460_connector_helper_funcs
= {
- .get_modes = ptn3460_get_modes,
+ .get_modes = ptn3460_connector_get_modes,
};
static const struct drm_connector_funcs ptn3460_connector_funcs = {
@@ -279,6 +284,7 @@ static const struct drm_bridge_funcs ptn3460_bridge_funcs =
{
.disable = ptn3460_disable,
.post_disable = ptn3460_post_disable,
.attach = ptn3460_bridge_attach,
+ .get_edid = ptn3460_get_edid,
};
static int ptn3460_probe(struct i2c_client *client,
@@ -327,6 +333,7 @@ static int ptn3460_probe(struct i2c_client *client,
}
ptn_bridge->bridge.funcs = &ptn3460_bridge_funcs;
+ ptn_bridge->bridge.ops = DRM_BRIDGE_OP_EDID;
ptn_bridge->bridge.of_node = dev->of_node;
drm_bridge_add(&ptn_bridge->bridge);
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 3/5] drm/bridge: tc358767: add drm_panel_bridge support
With the bridge operations implemented the last step to prepare
this driver for a chained setup is the use of the bridge panel driver.
The bridge panel driver is only used when a port@2 is present in
the DT. So when the display driver requests a connector
support both situations:
- connector created by bridge panel driver
- connector created by this driver
And on top, support that the display driver creates the connector,
which is the preferred setup.
Note: the bridge panel will use the connector type from the panel.
v3:
- Fix wrong logic in connector creation (Laurent)
v2:
- Merge connector and drm_panel_bridge patches
and fix so we do not create two connectors (Laurent)
Signed-off-by: Sam Ravnborg
Cc: Laurent Pinchart
Cc: Andrzej Hajda
Cc: Neil Armstrong
Cc: Jonas Karlman
Cc: Jernej Skrabec
---
drivers/gpu/drm/bridge/tc358767.c | 70 +++
1 file changed, 35 insertions(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/bridge/tc358767.c
b/drivers/gpu/drm/bridge/tc358767.c
index b26c669f3e91..cbad2607ab43 100644
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -244,8 +244,8 @@ struct tc_data {
struct drm_dp_aux aux;
struct drm_bridge bridge;
+ struct drm_bridge *panel_bridge;
struct drm_connectorconnector;
- struct drm_panel*panel;
/* link settings */
struct tc_edp_link link;
@@ -1234,13 +1234,6 @@ static int tc_stream_disable(struct tc_data *tc)
return 0;
}
-static void tc_bridge_pre_enable(struct drm_bridge *bridge)
-{
- struct tc_data *tc = bridge_to_tc(bridge);
-
- drm_panel_prepare(tc->panel);
-}
-
static void tc_bridge_enable(struct drm_bridge *bridge)
{
struct tc_data *tc = bridge_to_tc(bridge);
@@ -1264,8 +1257,6 @@ static void tc_bridge_enable(struct drm_bridge *bridge)
tc_main_link_disable(tc);
return;
}
-
- drm_panel_enable(tc->panel);
}
static void tc_bridge_disable(struct drm_bridge *bridge)
@@ -1273,8 +1264,6 @@ static void tc_bridge_disable(struct drm_bridge *bridge)
struct tc_data *tc = bridge_to_tc(bridge);
int ret;
- drm_panel_disable(tc->panel);
-
ret = tc_stream_disable(tc);
if (ret < 0)
dev_err(tc->dev, "main link stream stop error: %d\n", ret);
@@ -1284,13 +1273,6 @@ static void tc_bridge_disable(struct drm_bridge *bridge)
dev_err(tc->dev, "main link disable error: %d\n", ret);
}
-static void tc_bridge_post_disable(struct drm_bridge *bridge)
-{
- struct tc_data *tc = bridge_to_tc(bridge);
-
- drm_panel_unprepare(tc->panel);
-}
-
static bool tc_bridge_mode_fixup(struct drm_bridge *bridge,
const struct drm_display_mode *mode,
struct drm_display_mode *adj)
@@ -1354,9 +1336,11 @@ static int tc_connector_get_modes(struct drm_connector
*connector)
return 0;
}
- num_modes = drm_panel_get_modes(tc->panel, connector);
- if (num_modes > 0)
- return num_modes;
+ if (tc->panel_bridge) {
+ num_modes = drm_bridge_get_modes(tc->panel_bridge, connector);
+ if (num_modes > 0)
+ return num_modes;
+ }
edid = tc_get_edid(&tc->bridge, connector);
num_modes = drm_add_edid_modes(connector, edid);
@@ -1396,7 +1380,7 @@ tc_connector_detect(struct drm_connector *connector, bool
force)
if (tc->hpd_pin >= 0)
return tc_bridge_detect(&tc->bridge);
- if (tc->panel)
+ if (tc->panel_bridge)
return connector_status_connected;
else
return connector_status_unknown;
@@ -1419,16 +1403,23 @@ static int tc_bridge_attach(struct drm_bridge *bridge,
struct drm_device *drm = bridge->dev;
int ret;
- if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR) {
- DRM_ERROR("Fix bridge driver to make connector optional!");
- return -EINVAL;
+ if (tc->panel_bridge) {
+ enum drm_bridge_attach_flags panel_flags;
+
+ /* If a connector is required then this driver shall create it
*/
+ panel_flags = flags | DRM_BRIDGE_ATTACH_NO_CONNECTOR;
+ ret = drm_bridge_attach(tc->bridge.encoder, tc->panel_bridge,
+ &tc->bridge, panel_flags);
+ if (ret)
+ return ret;
}
+ if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR)
+ return 0;
+
/* Create DP/eDP connector */
drm_connector_helper_add(&tc->connector, &tc_connector_helper_funcs);
- ret = drm_connector_init(drm, &tc->connector, &tc_connector_funcs,
-tc->panel ? DRM_MODE_CONNECTOR_eDP :
-DRM_MODE_CONNECTOR_Displ
[PATCH v5 0/5] drm/bridge: Update tc358767 and nxp-ptn3460 to support chained bridges
This patch-set aims to make connector creation optional and prepare the bridge drivers for use in a chained setup. The objective is that all bridge drivers shall support a chained setup connector creation is moved to the display drivers. This is just one step on this path. The general approach for the bridge drivers: - Introduce bridge operations - Introduce use of panel bridge and make connector creation optional v5: - Applied reviewed patches, so we went from 15 to 5 - Fixed bug in connector creation in both drivers v4: - Dropped patch for ti-sn65dsi86. Await full conversion - Dropped patch for ti-tpd12s015. It was wrong (Laurent) - Drop boe,hv070wsa-100 patch, it was applied - Combined a few patches to fix connector created twice (Laurent) - Fix memory leak in get_edid (Laurent) - Added patch to validate panel descriptions in panel-simple - Set bridge.type in relevant drivers v3: - Rebase on top of drm-misc-next - Address kbuild test robot feedback v2: - Updated bus_flags for boe,hv070wsa-100 - Collected r-b, but did not apply patches yet - On the panel side the panel-simple driver gained a default connector type for all the dumb panels that do not include so in their description. With this change panels always provide a connector type, and we have the potential to drop most uses of devm_drm_panel_bridge_add_typed(). - Added conversion of a few more bridge drivers Patches can build but no run-time testing. So both test and review feedback appreciated! Sam Sam Ravnborg (5): drm/bridge: tc358767: add detect bridge operation drm/bridge: tc358767: add get_edid bridge operation drm/bridge: tc358767: add drm_panel_bridge support drm/bridge: nxp-ptn3460: add get_edid bridge operation drm/bridge: nxp-ptn3460: add drm_panel_bridge support drivers/gpu/drm/bridge/nxp-ptn3460.c | 103 +--- drivers/gpu/drm/bridge/tc358767.c| 126 +++ 2 files changed, 114 insertions(+), 115 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 5/5] drm/bridge: nxp-ptn3460: add drm_panel_bridge support
Prepare the bridge driver for use in a chained setup.
- Replacing direct use of drm_panel with drm_panel_bridge support.
- Make the connector creation optional
Note: the bridge panel will use the connector type from the panel.
v3:
- Fix wrong logic in connector creation (Laurent)
v2:
- Use panel_bridge for local variable name to align with other drivers
- Fix that connector was created twice (Laurent)
- Set bridge.type to DRM_MODE_CONNECTOR_LVDS.
Signed-off-by: Sam Ravnborg
Cc: Andrzej Hajda
Cc: Neil Armstrong
Cc: Laurent Pinchart
Cc: Jonas Karlman
Cc: Jernej Skrabec
---
drivers/gpu/drm/bridge/nxp-ptn3460.c | 60 ++--
1 file changed, 20 insertions(+), 40 deletions(-)
diff --git a/drivers/gpu/drm/bridge/nxp-ptn3460.c
b/drivers/gpu/drm/bridge/nxp-ptn3460.c
index 2805c8938f98..391c1f66f60f 100644
--- a/drivers/gpu/drm/bridge/nxp-ptn3460.c
+++ b/drivers/gpu/drm/bridge/nxp-ptn3460.c
@@ -29,7 +29,7 @@ struct ptn3460_bridge {
struct drm_connector connector;
struct i2c_client *client;
struct drm_bridge bridge;
- struct drm_panel *panel;
+ struct drm_bridge *panel_bridge;
struct gpio_desc *gpio_pd_n;
struct gpio_desc *gpio_rst_n;
u32 edid_emulation;
@@ -126,11 +126,6 @@ static void ptn3460_pre_enable(struct drm_bridge *bridge)
usleep_range(10, 20);
gpiod_set_value(ptn_bridge->gpio_rst_n, 1);
- if (drm_panel_prepare(ptn_bridge->panel)) {
- DRM_ERROR("failed to prepare panel\n");
- return;
- }
-
/*
* There's a bug in the PTN chip where it falsely asserts hotplug before
* it is fully functional. We're forced to wait for the maximum start up
@@ -145,16 +140,6 @@ static void ptn3460_pre_enable(struct drm_bridge *bridge)
ptn_bridge->enabled = true;
}
-static void ptn3460_enable(struct drm_bridge *bridge)
-{
- struct ptn3460_bridge *ptn_bridge = bridge_to_ptn3460(bridge);
-
- if (drm_panel_enable(ptn_bridge->panel)) {
- DRM_ERROR("failed to enable panel\n");
- return;
- }
-}
-
static void ptn3460_disable(struct drm_bridge *bridge)
{
struct ptn3460_bridge *ptn_bridge = bridge_to_ptn3460(bridge);
@@ -164,24 +149,10 @@ static void ptn3460_disable(struct drm_bridge *bridge)
ptn_bridge->enabled = false;
- if (drm_panel_disable(ptn_bridge->panel)) {
- DRM_ERROR("failed to disable panel\n");
- return;
- }
-
gpiod_set_value(ptn_bridge->gpio_rst_n, 1);
gpiod_set_value(ptn_bridge->gpio_pd_n, 0);
}
-static void ptn3460_post_disable(struct drm_bridge *bridge)
-{
- struct ptn3460_bridge *ptn_bridge = bridge_to_ptn3460(bridge);
-
- if (drm_panel_unprepare(ptn_bridge->panel)) {
- DRM_ERROR("failed to unprepare panel\n");
- return;
- }
-}
static struct edid *ptn3460_get_edid(struct drm_bridge *bridge,
struct drm_connector *connector)
@@ -245,12 +216,18 @@ static int ptn3460_bridge_attach(struct drm_bridge
*bridge,
enum drm_bridge_attach_flags flags)
{
struct ptn3460_bridge *ptn_bridge = bridge_to_ptn3460(bridge);
+ enum drm_bridge_attach_flags panel_flags;
int ret;
- if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR) {
- DRM_ERROR("Fix bridge driver to make connector optional!");
- return -EINVAL;
- }
+ /* Let this driver create connector if requested */
+ panel_flags = flags | DRM_BRIDGE_ATTACH_NO_CONNECTOR;
+ ret = drm_bridge_attach(bridge->encoder, ptn_bridge->panel_bridge,
+ bridge, panel_flags);
+ if (ret < 0)
+ return ret;
+
+ if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR)
+ return 0;
if (!bridge->encoder) {
DRM_ERROR("Parent encoder object not found");
@@ -270,9 +247,6 @@ static int ptn3460_bridge_attach(struct drm_bridge *bridge,
drm_connector_attach_encoder(&ptn_bridge->connector,
bridge->encoder);
- if (ptn_bridge->panel)
- drm_panel_attach(ptn_bridge->panel, &ptn_bridge->connector);
-
drm_helper_hpd_irq_event(ptn_bridge->connector.dev);
return ret;
@@ -280,9 +254,7 @@ static int ptn3460_bridge_attach(struct drm_bridge *bridge,
static const struct drm_bridge_funcs ptn3460_bridge_funcs = {
.pre_enable = ptn3460_pre_enable,
- .enable = ptn3460_enable,
.disable = ptn3460_disable,
- .post_disable = ptn3460_post_disable,
.attach = ptn3460_bridge_attach,
.get_edid = ptn3460_get_edid,
};
@@ -292,6 +264,8 @@ static int ptn3460_probe(struct i2c_client *client,
{
struct device *dev = &client->dev;
struct ptn3460_bridge *ptn_bridge;
+ struct drm_bridge *panel_br
[PATCH v5 2/5] drm/bridge: tc358767: add get_edid bridge operation
Prepare for chained bridge with the addition of
get_edid support.
v2:
- Fixed handling of edid storage (Laurent)
Signed-off-by: Sam Ravnborg
Reviewed-by: Laurent Pinchart
Cc: Andrzej Hajda
Cc: Neil Armstrong
Cc: Laurent Pinchart
Cc: Jonas Karlman
Cc: Jernej Skrabec
---
drivers/gpu/drm/bridge/tc358767.c | 34 ---
1 file changed, 18 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/bridge/tc358767.c
b/drivers/gpu/drm/bridge/tc358767.c
index bde89e213882..b26c669f3e91 100644
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -250,8 +250,6 @@ struct tc_data {
/* link settings */
struct tc_edp_link link;
- /* display edid */
- struct edid *edid;
/* current mode */
struct drm_display_mode mode;
@@ -1335,11 +1333,19 @@ static void tc_bridge_mode_set(struct drm_bridge
*bridge,
tc->mode = *mode;
}
+static struct edid *tc_get_edid(struct drm_bridge *bridge,
+ struct drm_connector *connector)
+{
+ struct tc_data *tc = bridge_to_tc(bridge);
+
+ return drm_get_edid(connector, &tc->aux.ddc);
+}
+
static int tc_connector_get_modes(struct drm_connector *connector)
{
struct tc_data *tc = connector_to_tc(connector);
+ int num_modes;
struct edid *edid;
- int count;
int ret;
ret = tc_get_display_props(tc);
@@ -1348,21 +1354,15 @@ static int tc_connector_get_modes(struct drm_connector
*connector)
return 0;
}
- count = drm_panel_get_modes(tc->panel, connector);
- if (count > 0)
- return count;
-
- edid = drm_get_edid(connector, &tc->aux.ddc);
-
- kfree(tc->edid);
- tc->edid = edid;
- if (!edid)
- return 0;
+ num_modes = drm_panel_get_modes(tc->panel, connector);
+ if (num_modes > 0)
+ return num_modes;
- drm_connector_update_edid_property(connector, edid);
- count = drm_add_edid_modes(connector, edid);
+ edid = tc_get_edid(&tc->bridge, connector);
+ num_modes = drm_add_edid_modes(connector, edid);
+ kfree(edid);
- return count;
+ return num_modes;
}
static const struct drm_connector_helper_funcs tc_connector_helper_funcs = {
@@ -1465,6 +1465,7 @@ static const struct drm_bridge_funcs tc_bridge_funcs = {
.post_disable = tc_bridge_post_disable,
.mode_fixup = tc_bridge_mode_fixup,
.detect = tc_bridge_detect,
+ .get_edid = tc_get_edid,
};
static bool tc_readable_reg(struct device *dev, unsigned int reg)
@@ -1689,6 +1690,7 @@ static int tc_probe(struct i2c_client *client, const
struct i2c_device_id *id)
tc->bridge.funcs = &tc_bridge_funcs;
if (tc->hpd_pin >= 0)
tc->bridge.ops |= DRM_BRIDGE_OP_DETECT;
+ tc->bridge.ops |= DRM_BRIDGE_OP_EDID;
tc->bridge.of_node = dev->of_node;
drm_bridge_add(&tc->bridge);
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/6] drm/bridge: Add SPI DBI host driver
Hi Paul,
Thank you for the patch.
On Mon, Jul 27, 2020 at 06:46:10PM +0200, Paul Cercueil wrote:
> This driver will register a DBI host driver for panels connected over
> SPI.
>
> DBI types c1 and c3 are supported. C1 is a SPI protocol with 9 bits per
> word, with the data/command information in the 9th (MSB) bit. C3 is a
> SPI protocol with 8 bits per word, with the data/command information
> carried by a separate GPIO.
>
> Signed-off-by: Paul Cercueil
> ---
> drivers/gpu/drm/bridge/Kconfig | 8 +
> drivers/gpu/drm/bridge/Makefile | 1 +
> drivers/gpu/drm/bridge/dbi-spi.c | 261 +++
> 3 files changed, 270 insertions(+)
> create mode 100644 drivers/gpu/drm/bridge/dbi-spi.c
>
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index c7f0dacfb57a..ed38366847c1 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -219,6 +219,14 @@ config DRM_TI_TPD12S015
> Texas Instruments TPD12S015 HDMI level shifter and ESD protection
> driver.
>
> +config DRM_MIPI_DBI_SPI
> + tristate "SPI host support for MIPI DBI"
> + depends on OF && SPI
> + select DRM_MIPI_DSI
> + select DRM_MIPI_DBI
> + help
> + Driver to support DBI over SPI.
> +
> source "drivers/gpu/drm/bridge/analogix/Kconfig"
>
> source "drivers/gpu/drm/bridge/adv7511/Kconfig"
> diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
> index 7d7c123a95e4..c2c522c2774f 100644
> --- a/drivers/gpu/drm/bridge/Makefile
> +++ b/drivers/gpu/drm/bridge/Makefile
> @@ -20,6 +20,7 @@ obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/
> obj-$(CONFIG_DRM_TI_SN65DSI86) += ti-sn65dsi86.o
> obj-$(CONFIG_DRM_TI_TFP410) += ti-tfp410.o
> obj-$(CONFIG_DRM_TI_TPD12S015) += ti-tpd12s015.o
> +obj-$(CONFIG_DRM_MIPI_DBI_SPI) += dbi-spi.o
> obj-$(CONFIG_DRM_NWL_MIPI_DSI) += nwl-dsi.o
>
> obj-y += analogix/
> diff --git a/drivers/gpu/drm/bridge/dbi-spi.c
> b/drivers/gpu/drm/bridge/dbi-spi.c
> new file mode 100644
> index ..1060b8f95fba
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/dbi-spi.c
> @@ -0,0 +1,261 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * MIPI Display Bus Interface (DBI) SPI support
> + *
> + * Copyright 2016 Noralf Trønnes
> + * Copyright 2020 Paul Cercueil
> + */
> +
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +
> +#include
> +
> +struct dbi_spi {
> + struct mipi_dsi_host host;
> + struct mipi_dsi_host_ops host_ops;
> +
> + struct spi_device *spi;
> + struct gpio_desc *dc;
> + struct mutex cmdlock;
> +
> + unsigned int current_bus_type;
> +
> + /**
> + * @tx_buf9: Buffer used for Option 1 9-bit conversion
> + */
> + void *tx_buf9;
> +
> + /**
> + * @tx_buf9_len: Size of tx_buf9.
> + */
> + size_t tx_buf9_len;
> +};
> +
> +static inline struct dbi_spi *host_to_dbi_spi(struct mipi_dsi_host *host)
> +{
> + return container_of(host, struct dbi_spi, host);
> +}
> +
> +static ssize_t dbi_spi1_transfer(struct mipi_dsi_host *host,
> + const struct mipi_dsi_msg *msg)
> +{
> + struct dbi_spi *dbi = host_to_dbi_spi(host);
> + struct spi_device *spi = dbi->spi;
> + struct spi_transfer tr = {
> + .bits_per_word = 9,
> + };
> + const u8 *src8 = msg->tx_buf;
> + struct spi_message m;
> + size_t max_chunk, chunk;
> + size_t len = msg->tx_len;
> + bool cmd_byte = true;
> + unsigned int i;
> + u16 *dst16;
> + int ret;
> +
> + tr.speed_hz = mipi_dbi_spi_cmd_max_speed(spi, len);
> + dst16 = dbi->tx_buf9;
> +
> + max_chunk = min(dbi->tx_buf9_len / 2, len);
> +
> + spi_message_init_with_transfers(&m, &tr, 1);
> + tr.tx_buf = dst16;
> +
> + while (len) {
> + chunk = min(len, max_chunk);
> +
> + for (i = 0; i < chunk; i++) {
> + dst16[i] = *src8++;
> +
> + /* Bit 9: 0 means command, 1 means data */
> + if (!cmd_byte)
> + dst16[i] |= BIT(9);
> +
> + cmd_byte = false;
> + }
> +
> + tr.len = chunk * 2;
> + len -= chunk;
> +
> + ret = spi_sync(spi, &m);
> + if (ret)
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +static ssize_t dbi_spi3_transfer(struct mipi_dsi_host *host,
> + const struct mipi_dsi_msg *msg)
> +{
> + struct dbi_spi *dbi = host_to_dbi_spi(host);
> + struct spi_device *spi = dbi->spi;
> + const u8 *buf = msg->tx_buf;
> + unsigned int bpw = 8;
> + u32 speed_hz;
> + ssize_t ret;
> +
> + /* for now we only support sending messages, not receiving */
> + if (msg->rx_len)
> + return -EINVAL;
> +
> + gpiod_set_value_cansleep(dbi->dc, 0);
> +
> + speed_hz = mipi_dbi_spi_cmd_max_speed(spi
Re: [PATCH v5 3/5] drm/bridge: tc358767: add drm_panel_bridge support
Hi Sam,
Thank you for the patch.
On Mon, Jul 27, 2020 at 07:03:18PM +0200, Sam Ravnborg wrote:
> With the bridge operations implemented the last step to prepare
> this driver for a chained setup is the use of the bridge panel driver.
>
> The bridge panel driver is only used when a port@2 is present in
> the DT. So when the display driver requests a connector
> support both situations:
> - connector created by bridge panel driver
> - connector created by this driver
>
> And on top, support that the display driver creates the connector,
> which is the preferred setup.
>
> Note: the bridge panel will use the connector type from the panel.
>
> v3:
> - Fix wrong logic in connector creation (Laurent)
>
> v2:
> - Merge connector and drm_panel_bridge patches
> and fix so we do not create two connectors (Laurent)
>
> Signed-off-by: Sam Ravnborg
> Cc: Laurent Pinchart
> Cc: Andrzej Hajda
> Cc: Neil Armstrong
> Cc: Jonas Karlman
> Cc: Jernej Skrabec
> ---
> drivers/gpu/drm/bridge/tc358767.c | 70 +++
> 1 file changed, 35 insertions(+), 35 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/tc358767.c
> b/drivers/gpu/drm/bridge/tc358767.c
> index b26c669f3e91..cbad2607ab43 100644
> --- a/drivers/gpu/drm/bridge/tc358767.c
> +++ b/drivers/gpu/drm/bridge/tc358767.c
> @@ -244,8 +244,8 @@ struct tc_data {
> struct drm_dp_aux aux;
>
> struct drm_bridge bridge;
> + struct drm_bridge *panel_bridge;
> struct drm_connectorconnector;
> - struct drm_panel*panel;
>
> /* link settings */
> struct tc_edp_link link;
> @@ -1234,13 +1234,6 @@ static int tc_stream_disable(struct tc_data *tc)
> return 0;
> }
>
> -static void tc_bridge_pre_enable(struct drm_bridge *bridge)
> -{
> - struct tc_data *tc = bridge_to_tc(bridge);
> -
> - drm_panel_prepare(tc->panel);
> -}
> -
> static void tc_bridge_enable(struct drm_bridge *bridge)
> {
> struct tc_data *tc = bridge_to_tc(bridge);
> @@ -1264,8 +1257,6 @@ static void tc_bridge_enable(struct drm_bridge *bridge)
> tc_main_link_disable(tc);
> return;
> }
> -
> - drm_panel_enable(tc->panel);
> }
>
> static void tc_bridge_disable(struct drm_bridge *bridge)
> @@ -1273,8 +1264,6 @@ static void tc_bridge_disable(struct drm_bridge *bridge)
> struct tc_data *tc = bridge_to_tc(bridge);
> int ret;
>
> - drm_panel_disable(tc->panel);
> -
> ret = tc_stream_disable(tc);
> if (ret < 0)
> dev_err(tc->dev, "main link stream stop error: %d\n", ret);
> @@ -1284,13 +1273,6 @@ static void tc_bridge_disable(struct drm_bridge
> *bridge)
> dev_err(tc->dev, "main link disable error: %d\n", ret);
> }
>
> -static void tc_bridge_post_disable(struct drm_bridge *bridge)
> -{
> - struct tc_data *tc = bridge_to_tc(bridge);
> -
> - drm_panel_unprepare(tc->panel);
> -}
> -
> static bool tc_bridge_mode_fixup(struct drm_bridge *bridge,
>const struct drm_display_mode *mode,
>struct drm_display_mode *adj)
> @@ -1354,9 +1336,11 @@ static int tc_connector_get_modes(struct drm_connector
> *connector)
> return 0;
> }
>
> - num_modes = drm_panel_get_modes(tc->panel, connector);
> - if (num_modes > 0)
> - return num_modes;
> + if (tc->panel_bridge) {
> + num_modes = drm_bridge_get_modes(tc->panel_bridge, connector);
> + if (num_modes > 0)
> + return num_modes;
> + }
>
> edid = tc_get_edid(&tc->bridge, connector);
> num_modes = drm_add_edid_modes(connector, edid);
> @@ -1396,7 +1380,7 @@ tc_connector_detect(struct drm_connector *connector,
> bool force)
> if (tc->hpd_pin >= 0)
> return tc_bridge_detect(&tc->bridge);
>
> - if (tc->panel)
> + if (tc->panel_bridge)
> return connector_status_connected;
> else
> return connector_status_unknown;
> @@ -1419,16 +1403,23 @@ static int tc_bridge_attach(struct drm_bridge *bridge,
> struct drm_device *drm = bridge->dev;
> int ret;
>
> - if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR) {
> - DRM_ERROR("Fix bridge driver to make connector optional!");
> - return -EINVAL;
> + if (tc->panel_bridge) {
> + enum drm_bridge_attach_flags panel_flags;
> +
> + /* If a connector is required then this driver shall create it
> */
> + panel_flags = flags | DRM_BRIDGE_ATTACH_NO_CONNECTOR;
> + ret = drm_bridge_attach(tc->bridge.encoder, tc->panel_bridge,
> + &tc->bridge, panel_flags);
You could write this
flags | DRM_BRIDGE_ATTACH_NO_CONNECTOR);
and drop the panel_flags variable.
Reviewed-by: Laurent Pinchart
> + if (ret)
> +
Re: [PATCH v5 5/5] drm/bridge: nxp-ptn3460: add drm_panel_bridge support
Hi Sam,
Thank you for the patch.
On Mon, Jul 27, 2020 at 07:03:20PM +0200, Sam Ravnborg wrote:
> Prepare the bridge driver for use in a chained setup.
>
> - Replacing direct use of drm_panel with drm_panel_bridge support.
> - Make the connector creation optional
>
> Note: the bridge panel will use the connector type from the panel.
>
> v3:
> - Fix wrong logic in connector creation (Laurent)
>
> v2:
> - Use panel_bridge for local variable name to align with other drivers
> - Fix that connector was created twice (Laurent)
> - Set bridge.type to DRM_MODE_CONNECTOR_LVDS.
>
> Signed-off-by: Sam Ravnborg
> Cc: Andrzej Hajda
> Cc: Neil Armstrong
> Cc: Laurent Pinchart
> Cc: Jonas Karlman
> Cc: Jernej Skrabec
> ---
> drivers/gpu/drm/bridge/nxp-ptn3460.c | 60 ++--
> 1 file changed, 20 insertions(+), 40 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/nxp-ptn3460.c
> b/drivers/gpu/drm/bridge/nxp-ptn3460.c
> index 2805c8938f98..391c1f66f60f 100644
> --- a/drivers/gpu/drm/bridge/nxp-ptn3460.c
> +++ b/drivers/gpu/drm/bridge/nxp-ptn3460.c
> @@ -29,7 +29,7 @@ struct ptn3460_bridge {
> struct drm_connector connector;
> struct i2c_client *client;
> struct drm_bridge bridge;
> - struct drm_panel *panel;
> + struct drm_bridge *panel_bridge;
> struct gpio_desc *gpio_pd_n;
> struct gpio_desc *gpio_rst_n;
> u32 edid_emulation;
> @@ -126,11 +126,6 @@ static void ptn3460_pre_enable(struct drm_bridge *bridge)
> usleep_range(10, 20);
> gpiod_set_value(ptn_bridge->gpio_rst_n, 1);
>
> - if (drm_panel_prepare(ptn_bridge->panel)) {
> - DRM_ERROR("failed to prepare panel\n");
> - return;
> - }
> -
> /*
>* There's a bug in the PTN chip where it falsely asserts hotplug before
>* it is fully functional. We're forced to wait for the maximum start up
> @@ -145,16 +140,6 @@ static void ptn3460_pre_enable(struct drm_bridge *bridge)
> ptn_bridge->enabled = true;
> }
>
> -static void ptn3460_enable(struct drm_bridge *bridge)
> -{
> - struct ptn3460_bridge *ptn_bridge = bridge_to_ptn3460(bridge);
> -
> - if (drm_panel_enable(ptn_bridge->panel)) {
> - DRM_ERROR("failed to enable panel\n");
> - return;
> - }
> -}
> -
> static void ptn3460_disable(struct drm_bridge *bridge)
> {
> struct ptn3460_bridge *ptn_bridge = bridge_to_ptn3460(bridge);
> @@ -164,24 +149,10 @@ static void ptn3460_disable(struct drm_bridge *bridge)
>
> ptn_bridge->enabled = false;
>
> - if (drm_panel_disable(ptn_bridge->panel)) {
> - DRM_ERROR("failed to disable panel\n");
> - return;
> - }
> -
> gpiod_set_value(ptn_bridge->gpio_rst_n, 1);
> gpiod_set_value(ptn_bridge->gpio_pd_n, 0);
> }
>
> -static void ptn3460_post_disable(struct drm_bridge *bridge)
> -{
> - struct ptn3460_bridge *ptn_bridge = bridge_to_ptn3460(bridge);
> -
> - if (drm_panel_unprepare(ptn_bridge->panel)) {
> - DRM_ERROR("failed to unprepare panel\n");
> - return;
> - }
> -}
>
> static struct edid *ptn3460_get_edid(struct drm_bridge *bridge,
>struct drm_connector *connector)
> @@ -245,12 +216,18 @@ static int ptn3460_bridge_attach(struct drm_bridge
> *bridge,
>enum drm_bridge_attach_flags flags)
> {
> struct ptn3460_bridge *ptn_bridge = bridge_to_ptn3460(bridge);
> + enum drm_bridge_attach_flags panel_flags;
> int ret;
>
> - if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR) {
> - DRM_ERROR("Fix bridge driver to make connector optional!");
> - return -EINVAL;
> - }
> + /* Let this driver create connector if requested */
> + panel_flags = flags | DRM_BRIDGE_ATTACH_NO_CONNECTOR;
> + ret = drm_bridge_attach(bridge->encoder, ptn_bridge->panel_bridge,
> + bridge, panel_flags);
Same here, you could write
flags | DRM_BRIDGE_ATTACH_NO_CONNECTOR);
Reviewed-by: Laurent Pinchart
> + if (ret < 0)
> + return ret;
> +
> + if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR)
> + return 0;
>
> if (!bridge->encoder) {
> DRM_ERROR("Parent encoder object not found");
> @@ -270,9 +247,6 @@ static int ptn3460_bridge_attach(struct drm_bridge
> *bridge,
> drm_connector_attach_encoder(&ptn_bridge->connector,
> bridge->encoder);
>
> - if (ptn_bridge->panel)
> - drm_panel_attach(ptn_bridge->panel, &ptn_bridge->connector);
> -
> drm_helper_hpd_irq_event(ptn_bridge->connector.dev);
>
> return ret;
> @@ -280,9 +254,7 @@ static int ptn3460_bridge_attach(struct drm_bridge
> *bridge,
>
> static const struct drm_bridge_funcs ptn3460_bridge_funcs = {
> .pre_enable = ptn3460_pre_enable,
> - .enable = p
Re: [PATCH v5 0/5] drm/bridge: Update tc358767 and nxp-ptn3460 to support chained bridges
Hi all. On Mon, Jul 27, 2020 at 07:03:15PM +0200, Sam Ravnborg wrote: > This patch-set aims to make connector creation optional > and prepare the bridge drivers for use in a chained setup. > > The objective is that all bridge drivers shall support a chained setup > connector creation is moved to the display drivers. > This is just one step on this path. > > The general approach for the bridge drivers: > - Introduce bridge operations > - Introduce use of panel bridge and make connector creation optional > > v5: > - Applied reviewed patches, so we went from 15 to 5 > - Fixed bug in connector creation in both drivers > > v4: > - Dropped patch for ti-sn65dsi86. Await full conversion > - Dropped patch for ti-tpd12s015. It was wrong (Laurent) > - Drop boe,hv070wsa-100 patch, it was applied > - Combined a few patches to fix connector created twice (Laurent) > - Fix memory leak in get_edid (Laurent) > - Added patch to validate panel descriptions in panel-simple > - Set bridge.type in relevant drivers > > v3: > - Rebase on top of drm-misc-next > - Address kbuild test robot feedback > > v2: > - Updated bus_flags for boe,hv070wsa-100 > - Collected r-b, but did not apply patches yet > - On the panel side the panel-simple driver gained a default > connector type for all the dumb panels that do not > include so in their description. > With this change panels always provide a connector type, > and we have the potential to drop most uses of > devm_drm_panel_bridge_add_typed(). > - Added conversion of a few more bridge drivers > > Patches can build but no run-time testing. > So both test and review feedback appreciated! > > Sam > > > Sam Ravnborg (5): > drm/bridge: tc358767: add detect bridge operation > drm/bridge: tc358767: add get_edid bridge operation > drm/bridge: tc358767: add drm_panel_bridge support > drm/bridge: nxp-ptn3460: add get_edid bridge operation > drm/bridge: nxp-ptn3460: add drm_panel_bridge support Fixed up per Laurent's suggestion and applied to drm-misc-next. Sam > > drivers/gpu/drm/bridge/nxp-ptn3460.c | 103 +--- > drivers/gpu/drm/bridge/tc358767.c| 126 > +++ > 2 files changed, 114 insertions(+), 115 deletions(-) > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH -next] crc:Fix build errors
Hi, I actually already sent a patch for this:
https://patchwork.freedesktop.org/patch/378202/
I'm guessing it hasn't gotten picked up upstream yet?
On Mon, 2020-07-27 at 12:00 +0800, Peng Wu wrote:
> If CONFIG_DRM_NOUVEAU=y,the following errors
> are seen while building crc.h.
>
> In file included from
> /scratch/linux/drivers/gpu/drm/nouveau/nouveau_display.c:47:
> /scratch/linux/drivers/gpu/drm/nouveau/dispnv50/crc.h: In function
> ‘nv50_head_crc_late_register’:
> /scratch/linux/drivers/gpu/drm/nouveau/dispnv50/crc.h:109:47: error:
> parameter name omitted
> static inline int nv50_head_crc_late_register(struct nv50_head *) {}
>^~
> /scratch/linux/drivers/gpu/drm/nouveau/dispnv50/crc.h:109:54: warning: no
> return statement in function returning non-void [-Wreturn-type]
> static inline int nv50_head_crc_late_register(struct nv50_head *) {}
> ^
> /scratch/linux/drivers/gpu/drm/nouveau/dispnv50/crc.h: In function
> ‘nv50_crc_handle_vblank’:
> /scratch/linux/drivers/gpu/drm/nouveau/dispnv50/crc.h:111:57: warning:
> ‘return’ with a value, in function returning void
> nv50_crc_handle_vblank(struct nv50_head *head) { return 0; }
> ^
> /scratch/linux/drivers/gpu/drm/nouveau/dispnv50/crc.h:111:1: note: declared
> here
> nv50_crc_handle_vblank(struct nv50_head *head) { return 0; }
> ^~
> /scratch/linux/drivers/gpu/drm/nouveau/dispnv50/crc.h: In function
> ‘nv50_crc_atomic_check_head’:
> /scratch/linux/drivers/gpu/drm/nouveau/dispnv50/crc.h:114:28: error:
> parameter name omitted
> nv50_crc_atomic_check_head(struct nv50_head *, struct nv50_head_atom *,
> ^~
> /scratch/linux/drivers/gpu/drm/nouveau/dispnv50/crc.h:114:48: error:
> parameter name omitted
> nv50_crc_atomic_check_head(struct nv50_head *, struct nv50_head_atom *,
> ^~~
> /scratch/linux/drivers/gpu/drm/nouveau/dispnv50/crc.h:115:7: error:
> parameter name omitted
>struct nv50_head_atom *) {}
>^~~
> /scratch/linux/drivers/gpu/drm/nouveau/dispnv50/crc.h:115:14: warning: no
> return statement in function returning non-void [-Wreturn-type]
>struct nv50_head_atom *) {}
> ^~
> /scratch/linux/drivers/gpu/drm/nouveau/dispnv50/crc.h: In function
> ‘nv50_crc_atomic_stop_reporting’:
> /scratch/linux/drivers/gpu/drm/nouveau/dispnv50/crc.h:118:32: error:
> parameter name omitted
> nv50_crc_atomic_stop_reporting(struct drm_atomic_state *) {}
> ^
> /scratch/linux/drivers/gpu/drm/nouveau/dispnv50/crc.h: In function
> ‘nv50_crc_atomic_init_notifier_contexts’:
> /scratch/linux/drivers/gpu/drm/nouveau/dispnv50/crc.h:120:40: error:
> parameter name omitted
> nv50_crc_atomic_init_notifier_contexts(struct drm_atomic_state *) {}
> ^
> /scratch/linux/drivers/gpu/drm/nouveau/dispnv50/crc.h: In function
> ‘nv50_crc_atomic_release_notifier_contexts’:
> /scratch/linux/drivers/gpu/drm/nouveau/dispnv50/crc.h:122:43: error:
> parameter name omitted
>
> Signed-off-by: Peng Wu
> ---
> drivers/gpu/drm/nouveau/dispnv50/crc.h | 44 +
> -
> 1 file changed, 22 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/dispnv50/crc.h
> b/drivers/gpu/drm/nouveau/dispnv50/crc.h
> index 4bc59e7..3da16cd 100644
> --- a/drivers/gpu/drm/nouveau/dispnv50/crc.h
> +++ b/drivers/gpu/drm/nouveau/dispnv50/crc.h
> @@ -76,22 +76,22 @@ struct nv50_crc {
> };
>
> void nv50_crc_init(struct drm_device *dev);
> -int nv50_head_crc_late_register(struct nv50_head *);
> +int nv50_head_crc_late_register(struct nv50_head *head);
> void nv50_crc_handle_vblank(struct nv50_head *head);
>
> -int nv50_crc_verify_source(struct drm_crtc *, const char *, size_t *);
> -const char *const *nv50_crc_get_sources(struct drm_crtc *, size_t *);
> -int nv50_crc_set_source(struct drm_crtc *, const char *);
> +int nv50_crc_verify_source(struct drm_crtc *crtc, const char *source_name,
> size_t *values_cnt);
> +const char *const *nv50_crc_get_sources(struct drm_crtc *crtc, size_t
> *count);
> +int nv50_crc_set_source(struct drm_crtc *crtc, const char *source_str);
>
> -int nv50_crc_atomic_check_head(struct nv50_head *, struct nv50_head_atom *,
> -struct nv50_head_atom *);
> +int nv50_crc_atomic_check_head(struct nv50_head *head, struct
> nv50_head_atom *asyh,
> +struct nv50_head_atom *armh);
> void nv50_crc_atomic_check_outp(struct nv50_atom *atom);
> -void nv50_crc_atomic_stop_reporting(struct drm_atomic_state *);
> -void nv50_crc_atomic_init_notifier_contexts(struct drm_atomic_state *);
> -void nv50_crc_atomic_relea
Re: [PATCH 1/2] dt-bindings: Add DT bindings for Toshiba TC358762 DSI-to-DPI bridge
On Sat, 25 Jul 2020 23:14:56 +0200, Marek Vasut wrote: > Add DT bindings for Toshiba TC358762 DSI-to-DPI bridge, this > one is used in the Raspberry Pi 7" touchscreen display unit. > > Signed-off-by: Marek Vasut > To: dri-devel@lists.freedesktop.org > Cc: Eric Anholt > Cc: Rob Herring > Cc: Sam Ravnborg > Cc: devicet...@vger.kernel.org > --- > .../display/bridge/toshiba,tc358762.yaml | 116 ++ > 1 file changed, 116 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/bridge/toshiba,tc358762.yaml > My bot found errors running 'make dt_binding_check' on your patch: Documentation/devicetree/bindings/display/bridge/toshiba,tc358762.example.dts:20.13-23: Warning (reg_format): /example-0/bridge@0:reg: property has invalid length (4 bytes) (#address-cells == 1, #size-cells == 1) Documentation/devicetree/bindings/display/bridge/toshiba,tc358762.example.dt.yaml: Warning (pci_device_reg): Failed prerequisite 'reg_format' Documentation/devicetree/bindings/display/bridge/toshiba,tc358762.example.dt.yaml: Warning (pci_device_bus_num): Failed prerequisite 'reg_format' Documentation/devicetree/bindings/display/bridge/toshiba,tc358762.example.dt.yaml: Warning (simple_bus_reg): Failed prerequisite 'reg_format' Documentation/devicetree/bindings/display/bridge/toshiba,tc358762.example.dt.yaml: Warning (i2c_bus_reg): Failed prerequisite 'reg_format' Documentation/devicetree/bindings/display/bridge/toshiba,tc358762.example.dt.yaml: Warning (spi_bus_reg): Failed prerequisite 'reg_format' /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/bridge/toshiba,tc358762.example.dt.yaml: example-0: bridge@0:reg:0: [0] is too short /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/bridge/toshiba,tc358762.example.dt.yaml: bridge@0: '#address-cells', '#size-cells', 'port@0', 'port@1' do not match any of the regexes: 'pinctrl-[0-9]+' /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/bridge/toshiba,tc358762.example.dt.yaml: bridge@0: 'ports' is a required property See https://patchwork.ozlabs.org/patch/1336337 If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure dt-schema is up to date: pip3 install git+https://github.com/devicetree-org/dt-schema.git@master --upgrade Please check and re-submit. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/3] dt-bindings: Add DT bindings for Powertip PH800480T013
On Sat, 25 Jul 2020 23:13:34 +0200, Marek Vasut wrote: > Add DT bindings for Powertip PH800480T013 800x480 parallel LCD, > this one is used in the Raspberry Pi 7" touchscreen display unit. > > Signed-off-by: Marek Vasut > To: dri-devel@lists.freedesktop.org > Cc: Eric Anholt > Cc: Rob Herring > Cc: Sam Ravnborg > Cc: devicet...@vger.kernel.org > --- > .../panel/powertip,ph800480t013-idf02.yaml| 28 +++ > 1 file changed, 28 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/panel/powertip,ph800480t013-idf02.yaml > My bot found errors running 'make dt_binding_check' on your patch: /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/panel/powertip,ph800480t013-idf02.yaml: $id: 'http://devicetree.org/schemas/display/panel/powertip,ph800480t013-idf02#' does not match 'http://devicetree.org/schemas/.*\\.yaml#' Documentation/devicetree/bindings/display/panel/powertip,ph800480t013-idf02.yaml: $id: relative path/filename doesn't match actual path or filename expected: http://devicetree.org/schemas/display/panel/powertip,ph800480t013-idf02.yaml# Documentation/devicetree/bindings/Makefile:20: recipe for target 'Documentation/devicetree/bindings/display/panel/powertip,ph800480t013-idf02.example.dts' failed make[1]: *** [Documentation/devicetree/bindings/display/panel/powertip,ph800480t013-idf02.example.dts] Error 1 make[1]: *** Waiting for unfinished jobs /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/panel/powertip,ph800480t013-idf02.yaml: ignoring, error in schema: $id warning: no schema found in file: ./Documentation/devicetree/bindings/display/panel/powertip,ph800480t013-idf02.yaml /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/panel/powertip,ph800480t013-idf02.yaml: ignoring, error in schema: $id warning: no schema found in file: ./Documentation/devicetree/bindings/display/panel/powertip,ph800480t013-idf02.yaml Makefile:1347: recipe for target 'dt_binding_check' failed make: *** [dt_binding_check] Error 2 See https://patchwork.ozlabs.org/patch/1336335 If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure dt-schema is up to date: pip3 install git+https://github.com/devicetree-org/dt-schema.git@master --upgrade Please check and re-submit. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/radeon: avoid a useless memset
Applied. Thanks!
Alex
On Mon, Jul 27, 2020 at 9:41 AM Christian König
wrote:
>
> Am 27.07.20 um 12:34 schrieb Christophe JAILLET:
> > Avoid a memset after a call to 'dma_alloc_coherent()'.
> > This is useless since
> > commit 518a2f1925c3 ("dma-mapping: zero memory returned from dma_alloc_*")
> >
> > Signed-off-by: Christophe JAILLET
>
> Reviewed-by: Christian König
>
> > ---
> > drivers/gpu/drm/radeon/radeon_gart.c | 1 -
> > 1 file changed, 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/radeon/radeon_gart.c
> > b/drivers/gpu/drm/radeon/radeon_gart.c
> > index b7ce254e5663..3808a753127b 100644
> > --- a/drivers/gpu/drm/radeon/radeon_gart.c
> > +++ b/drivers/gpu/drm/radeon/radeon_gart.c
> > @@ -85,7 +85,6 @@ int radeon_gart_table_ram_alloc(struct radeon_device
> > *rdev)
> > }
> > #endif
> > rdev->gart.ptr = ptr;
> > - memset((void *)rdev->gart.ptr, 0, rdev->gart.table_size);
> > return 0;
> > }
> >
>
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 9/9] soc/qcom: Add REVID driver
On Sun, 26 Jul 2020 13:12:06 +0200, Konrad Dybcio wrote: > From: Xiaozhe Shi > > Add the REVID device driver. The REVID driver will print out the PMIC > revision at probe time. > > Signed-off-by: Xiaozhe Shi > [konradyb...@gmail.com: Fast-forward the driver from kernel 4.14 to 5.8, > convert binding to yaml] > Signed-off-by: Konrad Dybcio > --- > .../bindings/soc/qcom/qcom,qpnp-revid.yaml| 38 ++ > drivers/soc/qcom/Kconfig | 9 + > drivers/soc/qcom/Makefile | 1 + > drivers/soc/qcom/qpnp-revid.c | 288 ++ > include/linux/qpnp/qpnp-revid.h | 369 ++ > 5 files changed, 705 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/soc/qcom/qcom,qpnp-revid.yaml > create mode 100644 drivers/soc/qcom/qpnp-revid.c > create mode 100644 include/linux/qpnp/qpnp-revid.h > My bot found errors running 'make dt_binding_check' on your patch: Documentation/devicetree/bindings/soc/qcom/qcom,qpnp-revid.yaml: while scanning a block scalar in "", line 22, column 18 found a tab character where an indentation space is expected in "", line 24, column 1 Documentation/devicetree/bindings/Makefile:20: recipe for target 'Documentation/devicetree/bindings/soc/qcom/qcom,qpnp-revid.example.dts' failed make[1]: *** [Documentation/devicetree/bindings/soc/qcom/qcom,qpnp-revid.example.dts] Error 1 make[1]: *** Waiting for unfinished jobs /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/soc/qcom/qcom,qpnp-revid.yaml: ignoring, error parsing file warning: no schema found in file: ./Documentation/devicetree/bindings/soc/qcom/qcom,qpnp-revid.yaml /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/soc/qcom/qcom,qpnp-revid.yaml: ignoring, error parsing file warning: no schema found in file: ./Documentation/devicetree/bindings/soc/qcom/qcom,qpnp-revid.yaml Makefile:1347: recipe for target 'dt_binding_check' failed make: *** [dt_binding_check] Error 2 See https://patchwork.ozlabs.org/patch/1336467 If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure dt-schema is up to date: pip3 install git+https://github.com/devicetree-org/dt-schema.git@master --upgrade Please check and re-submit. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 9/9] soc/qcom: Add REVID driver
On Sun, Jul 26, 2020 at 01:12:06PM +0200, Konrad Dybcio wrote: > From: Xiaozhe Shi > > Add the REVID device driver. The REVID driver will print out the PMIC > revision at probe time. > > Signed-off-by: Xiaozhe Shi > [konradyb...@gmail.com: Fast-forward the driver from kernel 4.14 to 5.8, > convert binding to yaml] > Signed-off-by: Konrad Dybcio > --- > .../bindings/soc/qcom/qcom,qpnp-revid.yaml| 38 ++ Bindings should be a separate patch. checkpatch.pl will tell you this. > drivers/soc/qcom/Kconfig | 9 + > drivers/soc/qcom/Makefile | 1 + > drivers/soc/qcom/qpnp-revid.c | 288 ++ > include/linux/qpnp/qpnp-revid.h | 369 ++ > 5 files changed, 705 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/soc/qcom/qcom,qpnp-revid.yaml > create mode 100644 drivers/soc/qcom/qpnp-revid.c > create mode 100644 include/linux/qpnp/qpnp-revid.h ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/radeon: switch from 'pci_' to 'dma_' API
Applied. Thanks!
Alex
On Mon, Jul 27, 2020 at 9:42 AM Christian König
wrote:
>
> Am 27.07.20 um 12:34 schrieb Christophe JAILLET:
> > The wrappers in include/linux/pci-dma-compat.h should go away.
> >
> > The patch has been generated with the coccinelle script below and has been
> > hand modified to replace GFP_ with a correct flag.
> > It has been compile tested.
> >
> > When memory is allocated in 'radeon_gart_table_ram_alloc()' GFP_KERNEL
> > can be used because its callers already use this flag.
> >
> > Both 'r100_pci_gart_init()' (r100.c) and 'rs400_gart_init()' (rs400.c)
> > call 'radeon_gart_init()'.
> > This function uses 'vmalloc'.
> >
> >
> > @@
> > @@
> > -PCI_DMA_BIDIRECTIONAL
> > +DMA_BIDIRECTIONAL
> >
> > @@
> > @@
> > -PCI_DMA_TODEVICE
> > +DMA_TO_DEVICE
> >
> > @@
> > @@
> > -PCI_DMA_FROMDEVICE
> > +DMA_FROM_DEVICE
> >
> > @@
> > @@
> > -PCI_DMA_NONE
> > +DMA_NONE
> >
> > @@
> > expression e1, e2, e3;
> > @@
> > -pci_alloc_consistent(e1, e2, e3)
> > +dma_alloc_coherent(&e1->dev, e2, e3, GFP_)
> >
> > @@
> > expression e1, e2, e3;
> > @@
> > -pci_zalloc_consistent(e1, e2, e3)
> > +dma_alloc_coherent(&e1->dev, e2, e3, GFP_)
> >
> > @@
> > expression e1, e2, e3, e4;
> > @@
> > -pci_free_consistent(e1, e2, e3, e4)
> > +dma_free_coherent(&e1->dev, e2, e3, e4)
> >
> > @@
> > expression e1, e2, e3, e4;
> > @@
> > -pci_map_single(e1, e2, e3, e4)
> > +dma_map_single(&e1->dev, e2, e3, e4)
> >
> > @@
> > expression e1, e2, e3, e4;
> > @@
> > -pci_unmap_single(e1, e2, e3, e4)
> > +dma_unmap_single(&e1->dev, e2, e3, e4)
> >
> > @@
> > expression e1, e2, e3, e4, e5;
> > @@
> > -pci_map_page(e1, e2, e3, e4, e5)
> > +dma_map_page(&e1->dev, e2, e3, e4, e5)
> >
> > @@
> > expression e1, e2, e3, e4;
> > @@
> > -pci_unmap_page(e1, e2, e3, e4)
> > +dma_unmap_page(&e1->dev, e2, e3, e4)
> >
> > @@
> > expression e1, e2, e3, e4;
> > @@
> > -pci_map_sg(e1, e2, e3, e4)
> > +dma_map_sg(&e1->dev, e2, e3, e4)
> >
> > @@
> > expression e1, e2, e3, e4;
> > @@
> > -pci_unmap_sg(e1, e2, e3, e4)
> > +dma_unmap_sg(&e1->dev, e2, e3, e4)
> >
> > @@
> > expression e1, e2, e3, e4;
> > @@
> > -pci_dma_sync_single_for_cpu(e1, e2, e3, e4)
> > +dma_sync_single_for_cpu(&e1->dev, e2, e3, e4)
> >
> > @@
> > expression e1, e2, e3, e4;
> > @@
> > -pci_dma_sync_single_for_device(e1, e2, e3, e4)
> > +dma_sync_single_for_device(&e1->dev, e2, e3, e4)
> >
> > @@
> > expression e1, e2, e3, e4;
> > @@
> > -pci_dma_sync_sg_for_cpu(e1, e2, e3, e4)
> > +dma_sync_sg_for_cpu(&e1->dev, e2, e3, e4)
> >
> > @@
> > expression e1, e2, e3, e4;
> > @@
> > -pci_dma_sync_sg_for_device(e1, e2, e3, e4)
> > +dma_sync_sg_for_device(&e1->dev, e2, e3, e4)
> >
> > @@
> > expression e1, e2;
> > @@
> > -pci_dma_mapping_error(e1, e2)
> > +dma_mapping_error(&e1->dev, e2)
> >
> > @@
> > expression e1, e2;
> > @@
> > -pci_set_dma_mask(e1, e2)
> > +dma_set_mask(&e1->dev, e2)
> >
> > @@
> > expression e1, e2;
> > @@
> > -pci_set_consistent_dma_mask(e1, e2)
> > +dma_set_coherent_mask(&e1->dev, e2)
> >
> > Signed-off-by: Christophe JAILLET
>
> Reviewed-by: Christian König
>
> > ---
> > If needed, see post from Christoph Hellwig on the kernel-janitors ML:
> > https://marc.info/?l=kernel-janitors&m=158745678307186&w=4
> > ---
> > drivers/gpu/drm/radeon/radeon_gart.c | 9 -
> > 1 file changed, 4 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/radeon/radeon_gart.c
> > b/drivers/gpu/drm/radeon/radeon_gart.c
> > index f178ba321715..b7ce254e5663 100644
> > --- a/drivers/gpu/drm/radeon/radeon_gart.c
> > +++ b/drivers/gpu/drm/radeon/radeon_gart.c
> > @@ -72,8 +72,8 @@ int radeon_gart_table_ram_alloc(struct radeon_device
> > *rdev)
> > {
> > void *ptr;
> >
> > - ptr = pci_alloc_consistent(rdev->pdev, rdev->gart.table_size,
> > -&rdev->gart.table_addr);
> > + ptr = dma_alloc_coherent(&rdev->pdev->dev, rdev->gart.table_size,
> > + &rdev->gart.table_addr, GFP_KERNEL);
> > if (ptr == NULL) {
> > return -ENOMEM;
> > }
> > @@ -110,9 +110,8 @@ void radeon_gart_table_ram_free(struct radeon_device
> > *rdev)
> > rdev->gart.table_size >> PAGE_SHIFT);
> > }
> > #endif
> > - pci_free_consistent(rdev->pdev, rdev->gart.table_size,
> > - (void *)rdev->gart.ptr,
> > - rdev->gart.table_addr);
> > + dma_free_coherent(&rdev->pdev->dev, rdev->gart.table_size,
> > + (void *)rdev->gart.ptr, rdev->gart.table_addr);
> > rdev->gart.ptr = NULL;
> > rdev->gart.table_addr = 0;
> > }
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
_
Re: [PATCH 1/3] drm/ast: Do full modeset if the primary plane's format changes
On Mon, Jul 27, 2020 at 1:24 PM Thomas Zimmermann wrote:
>
> Hi
>
> Am 27.07.20 um 12:40 schrieb dan...@ffwll.ch:
> > On Mon, Jul 27, 2020 at 09:37:05AM +0200, Thomas Zimmermann wrote:
> >> The atomic modesetting code tried to distinguish format changes from
> >> full modesetting operations. In practice, this was buggy and the format
> >> registers were often updated even for simple pageflips.
> >
> > Nah it's not buggy, it's intentional. Most hw can update formats in a flip
> > withouth having to shut down the hw to do so.
>
> Admittedly it was intentional when I write it, but it never really
> worked. I think it might have even updated these color registers on each
> frame.
>
> >
> >
> >> Instead do a full modeset if the primary plane changes formats. It's
> >> just as rare as an actual mode change, so there will be no performance
> >> penalty.
> >>
> >> The patch also replaces a reference to drm_crtc_state.allow_modeset with
> >> the correct call to drm_atomic_crtc_needs_modeset().
> >>
> >> Signed-off-by: Thomas Zimmermann
> >> Fixes: 4961eb60f145 ("drm/ast: Enable atomic modesetting")
> >> Cc: Thomas Zimmermann
> >> Cc: Gerd Hoffmann
> >> Cc: Dave Airlie
> >> Cc: Daniel Vetter
> >> Cc: Sam Ravnborg
> >> Cc: Emil Velikov
> >> Cc: "Y.C. Chen"
> >> Cc: # v5.6+
> >> ---
> >> drivers/gpu/drm/ast/ast_mode.c | 23 ---
> >> 1 file changed, 16 insertions(+), 7 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/ast/ast_mode.c
> >> b/drivers/gpu/drm/ast/ast_mode.c
> >> index 154cd877d9d1..3680a000b812 100644
> >> --- a/drivers/gpu/drm/ast/ast_mode.c
> >> +++ b/drivers/gpu/drm/ast/ast_mode.c
> >> @@ -527,8 +527,8 @@ static const uint32_t ast_primary_plane_formats[] = {
> >> static int ast_primary_plane_helper_atomic_check(struct drm_plane *plane,
> >> struct drm_plane_state
> >> *state)
> >> {
> >> -struct drm_crtc_state *crtc_state;
> >> -struct ast_crtc_state *ast_crtc_state;
> >> +struct drm_crtc_state *crtc_state, *old_crtc_state;
> >> +struct ast_crtc_state *ast_crtc_state, *old_ast_crtc_state;
> >> int ret;
> >>
> >> if (!state->crtc)
> >> @@ -550,6 +550,15 @@ static int
> >> ast_primary_plane_helper_atomic_check(struct drm_plane *plane,
> >>
> >> ast_crtc_state->format = state->fb->format;
> >>
> >> +old_crtc_state = drm_atomic_get_old_crtc_state(state->state,
> >> state->crtc);
> >> +if (!old_crtc_state)
> >> +return 0;
> >> +old_ast_crtc_state = to_ast_crtc_state(old_crtc_state);
> >> +if (!old_ast_crtc_state)
> >
> > The above two if checks should never fail, I'd wrap them in a WARN_ON.
>
> Really? But what's the old state when the first mode is being programmed?
Uh, atomic _always_ has a state. That's why you need to call
drm_mode_config_reset, to get this entire machinery started. Also, the
sw state is supposed to always match the hw state (at least once all
the nonblocking commit workers have caught up).
> >
> >> +return 0;
> >> +if (ast_crtc_state->format != old_ast_crtc_state->format)
> >> +crtc_state->mode_changed = true;
> >> +
> >> return 0;
> >> }
> >>
> >> @@ -775,18 +784,18 @@ static void ast_crtc_helper_atomic_flush(struct
> >> drm_crtc *crtc,
> >>
> >> ast_state = to_ast_crtc_state(crtc->state);
> >>
> >> -format = ast_state->format;
> >> -if (!format)
> >> +if (!drm_atomic_crtc_needs_modeset(crtc->state))
> >> return;
> >>
> >> +format = ast_state->format;
> >> +if (drm_WARN_ON_ONCE(dev, !format))
> >> +return; /* BUG: We didn't set format in primary check(). */
> >
> > Hm that entire ast_state->format machinery looks kinda strange, can't you
> > just look up the primary plane state everywhere and that's it?
> > drm_framebuffer are fully invariant and refcounted to the state, so there
> > really shouldn't be any need to copy format around.
>
> ast_state->format is the format that has to be programmed in
> atomic_flush(). If it's NULL, the current format was used. Updating the
> primary plane's format also requires the vbios info, which depends on
> CRTC state. So it's collected in the CRTC's atomic_check().
>
> It felt natural to use the various atomic_check() functions to collect
> and store and store away these structures, and later use them in
> atomic_flush().
>
> I'd prefer to keep the current design. It's the one that worked best
> while writing the atomic-modesetting support for ast.
So if you have actual checks in atomic_check for validation, then this
makes sense - it avoids computing stuff twice and getting in wrong in
one case.
But from reading ast code all you do is store the temporary lookup in
there, and that's really just confusing. You can just look up the
atomic state, at least in atomic_check (in the commit side it's mildly
more annoying, we need to fix a few things). But it's also not totally
horrible ofc, just would be nice to improve this.
-
Re: [PATCH 2/3] drm/ast: Store image size in HW cursor info
On Mon, Jul 27, 2020 at 1:37 PM Thomas Zimmermann wrote:
>
> Hi
>
> Am 27.07.20 um 12:42 schrieb dan...@ffwll.ch:
> > On Mon, Jul 27, 2020 at 09:37:06AM +0200, Thomas Zimmermann wrote:
> >> Store the image size as part of the HW cursor info, so that the
> >> cursor show function doesn't require the information from the
> >> caller. No functional changes.
> >
> > Uh just pass the state structure and done? All these "store random stuff
> > in private structures" (they're not even atomic state structures, it's the
> > driver private thing even!) is very non-atomic. And I see zero reasons why
> > you have to do this, the cursor stays around.
>
> It's not random stuff. Ast cannot use ARGB for cursors. Anything in
> ast_private.cursor represents cursor hardware state (not DRM state);
> duplicated for double buffering.
>
> * gbo: two perma-pinned GEM objects at the end of VRAM. It's the HW
> cursor buffer in ARGB format. The userspace's cursor image is
> converted to ARGB and copied into the current backbuffer.
>
> * vaddr: A mapping of the gbo's into kernel address space. We don't
> want to map the gbo on each update, so they are mapped once and the
> kernel address is stored in vaddr.
>
> * size: the size of each HW buffer. We could use the value in the fb,
> but storing this as well makes the cursor code self-contained.
Yeah, but this kind of stuff should be in the ast_plane_state. Not in
ast_private, that latter option is very non-atomic and results in all
kinds of coordination fun.
-Daniel
>
> Best regards
> Thomas
>
> > -Daniel
> >
> >>
> >> Signed-off-by: Thomas Zimmermann
> >> Fixes: 4961eb60f145 ("drm/ast: Enable atomic modesetting")
> >> Cc: Thomas Zimmermann
> >> Cc: Gerd Hoffmann
> >> Cc: Dave Airlie
> >> Cc: Daniel Vetter
> >> Cc: Sam Ravnborg
> >> Cc: Emil Velikov
> >> Cc: "Y.C. Chen"
> >> Cc: # v5.6+
> >> ---
> >> drivers/gpu/drm/ast/ast_cursor.c | 13 +++--
> >> drivers/gpu/drm/ast/ast_drv.h| 7 +--
> >> drivers/gpu/drm/ast/ast_mode.c | 8 +---
> >> 3 files changed, 17 insertions(+), 11 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/ast/ast_cursor.c
> >> b/drivers/gpu/drm/ast/ast_cursor.c
> >> index acf0d23514e8..8642a0ce9da6 100644
> >> --- a/drivers/gpu/drm/ast/ast_cursor.c
> >> +++ b/drivers/gpu/drm/ast/ast_cursor.c
> >> @@ -87,6 +87,8 @@ int ast_cursor_init(struct ast_private *ast)
> >>
> >> ast->cursor.gbo[i] = gbo;
> >> ast->cursor.vaddr[i] = vaddr;
> >> +ast->cursor.size[i].width = 0;
> >> +ast->cursor.size[i].height = 0;
> >> }
> >>
> >> return drmm_add_action_or_reset(dev, ast_cursor_release, NULL);
> >> @@ -194,6 +196,9 @@ int ast_cursor_blit(struct ast_private *ast, struct
> >> drm_framebuffer *fb)
> >> /* do data transfer to cursor BO */
> >> update_cursor_image(dst, src, fb->width, fb->height);
> >>
> >> +ast->cursor.size[ast->cursor.next_index].width = fb->width;
> >> +ast->cursor.size[ast->cursor.next_index].height = fb->height;
> >> +
> >> drm_gem_vram_vunmap(gbo, src);
> >> drm_gem_vram_unpin(gbo);
> >>
> >> @@ -249,14 +254,18 @@ static void ast_cursor_set_location(struct
> >> ast_private *ast, u16 x, u16 y,
> >> ast_set_index_reg(ast, AST_IO_CRTC_PORT, 0xc7, y1);
> >> }
> >>
> >> -void ast_cursor_show(struct ast_private *ast, int x, int y,
> >> - unsigned int offset_x, unsigned int offset_y)
> >> +void ast_cursor_show(struct ast_private *ast, int x, int y)
> >> {
> >> +unsigned int offset_x, offset_y;
> >> u8 x_offset, y_offset;
> >> u8 __iomem *dst, __iomem *sig;
> >> u8 jreg;
> >>
> >> dst = ast->cursor.vaddr[ast->cursor.next_index];
> >> +offset_x = AST_MAX_HWC_WIDTH -
> >> + ast->cursor.size[ast->cursor.next_index].width;
> >> +offset_y = AST_MAX_HWC_HEIGHT -
> >> + ast->cursor.size[ast->cursor.next_index].height;
> >>
> >> sig = dst + AST_HWC_SIZE;
> >> writel(x, sig + AST_HWC_SIGNATURE_X);
> >> diff --git a/drivers/gpu/drm/ast/ast_drv.h b/drivers/gpu/drm/ast/ast_drv.h
> >> index e3a264ac7ee2..57414b429db3 100644
> >> --- a/drivers/gpu/drm/ast/ast_drv.h
> >> +++ b/drivers/gpu/drm/ast/ast_drv.h
> >> @@ -116,6 +116,10 @@ struct ast_private {
> >> struct {
> >> struct drm_gem_vram_object *gbo[AST_DEFAULT_HWC_NUM];
> >> void __iomem *vaddr[AST_DEFAULT_HWC_NUM];
> >> +struct {
> >> +unsigned int width;
> >> +unsigned int height;
> >> +} size[AST_DEFAULT_HWC_NUM];
> >> unsigned int next_index;
> >> } cursor;
> >>
> >> @@ -311,8 +315,7 @@ void ast_release_firmware(struct drm_device *dev);
> >> int ast_cursor_init(struct ast_private *ast);
> >> int ast_cursor_blit(struct ast_private *ast, struct drm_framebuffer *fb);
> >> void ast_cursor_page_flip(struct ast_private *ast);
> >> -void ast_cursor_show(struct ast_private *ast, int x, i
Re: [PATCH] drm/dbi: Fix SPI Type 1 (9-bit) transfer
Hi Paul.
On Fri, Jul 03, 2020 at 04:23:57PM +0200, Sam Ravnborg wrote:
> On Fri, Jul 03, 2020 at 04:13:41PM +0200, Paul Cercueil wrote:
> > The function mipi_dbi_spi1_transfer() will transfer its payload as 9-bit
> > data, the 9th (MSB) bit being the data/command bit. In order to do that,
> > it unpacks the 8-bit values into 16-bit values, then sets the 9th bit if
> > the byte corresponds to data, clears it otherwise. The 7 MSB are
> > padding. The array of now 16-bit values is then passed to the SPI core
> > for transfer.
> >
> > This function was broken since its introduction, as the length of the
> > SPI transfer was set to the payload size before its conversion, but the
> > payload doubled in size due to the 8-bit -> 16-bit conversion.
> >
> > Fixes: 02dd95fe3169 ("drm/tinydrm: Add MIPI DBI support")
> > Cc: # 4.10
> > Signed-off-by: Paul Cercueil
>
> As discussed on irc this looks correct to me too.
>
> Reviewed-by: Sam Ravnborg
>
>
> I will apply later, but let's wait and see if Noralf or others
> have any feedback first.
I finally went back to this patch, I missed it yesterday.
Applied to drm-misc-fixes with a stable 5.4+ tag.
Sam
> > ---
> > drivers/gpu/drm/drm_mipi_dbi.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/drm_mipi_dbi.c b/drivers/gpu/drm/drm_mipi_dbi.c
> > index bb27c82757f1..bf7888ad9ad4 100644
> > --- a/drivers/gpu/drm/drm_mipi_dbi.c
> > +++ b/drivers/gpu/drm/drm_mipi_dbi.c
> > @@ -923,7 +923,7 @@ static int mipi_dbi_spi1_transfer(struct mipi_dbi *dbi,
> > int dc,
> > }
> > }
> >
> > - tr.len = chunk;
> > + tr.len = chunk * 2;
> > len -= chunk;
> >
> > ret = spi_sync(spi, &m);
> > --
> > 2.27.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
Re: [Nouveau] [PATCH v2] drm/nouveau: Accept 'legacy' format modifiers
On 7/23/20 9:06 PM, Ben Skeggs wrote:
On Sat, 18 Jul 2020 at 13:34, James Jones wrote:
Accept the DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK()
family of modifiers to handle broken userspace
Xorg modesetting and Mesa drivers. Existing Mesa
drivers are still aware of only these older
format modifiers which do not differentiate
between different variations of the block linear
layout. When the format modifier support flag was
flipped in the nouveau kernel driver, the X.org
modesetting driver began attempting to use its
format modifier-enabled framebuffer path. Because
the set of format modifiers advertised by the
kernel prior to this change do not intersect with
the set of format modifiers advertised by Mesa,
allocating GBM buffers using format modifiers
fails and the modesetting driver falls back to
non-modifier allocation. However, it still later
queries the modifier of the GBM buffer when
creating its DRM-KMS framebuffer object, receives
the old-format modifier from Mesa, and attempts
to create a framebuffer with it. Since the kernel
is still not aware of these formats, this fails.
Userspace should not be attempting to query format
modifiers of GBM buffers allocated with a non-
format-modifier-aware allocation path, but to
avoid breaking existing userspace behavior, this
change accepts the old-style format modifiers when
creating framebuffers and applying them to planes
by translating them to the equivalent new-style
modifier. To accomplish this, some layout
parameters must be assumed to match properties of
the device targeted by the relevant ioctls. To
avoid perpetuating misuse of the old-style
modifiers, this change does not advertise support
for them. Doing so would imply compatibility
between devices with incompatible memory layouts.
Tested with Xorg 1.20 modesetting driver,
weston@c46c70dac84a4b3030cd05b380f9f410536690fc,
gnome & KDE wayland desktops from Ubuntu 18.04,
and sway 1.5
Reported-by: Kirill A. Shutemov
Fixes: fa4f4c213f5f ("drm/nouveau/kms: Support NVIDIA format modifiers")
Link: https://lkml.org/lkml/2020/6/30/1251
Signed-off-by: James Jones
---
drivers/gpu/drm/nouveau/nouveau_display.c | 26 +--
1 file changed, 24 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c
b/drivers/gpu/drm/nouveau/nouveau_display.c
index 496c4621cc78..31543086254b 100644
--- a/drivers/gpu/drm/nouveau/nouveau_display.c
+++ b/drivers/gpu/drm/nouveau/nouveau_display.c
@@ -191,8 +191,14 @@ nouveau_decode_mod(struct nouveau_drm *drm,
uint32_t *tile_mode,
uint8_t *kind)
{
+ struct nouveau_display *disp = nouveau_display(drm->dev);
BUG_ON(!tile_mode || !kind);
+ if ((modifier & (0xffull << 12)) == 0ull) {
+ /* Legacy modifier. Translate to this device's 'kind.' */
+ modifier |= disp->format_modifiers[0] & (0xffull << 12);
+ }
I believe this should be moved into the != MOD_LINEAR case.
Yes, of course, thanks. I need to re-evaluate my testing yet again to
make sure I hit that case too. Preparing a v3...
Thanks,
-James
+
if (modifier == DRM_FORMAT_MOD_LINEAR) {
/* tile_mode will not be used in this case */
*tile_mode = 0;
@@ -227,6 +233,16 @@ nouveau_framebuffer_get_layout(struct drm_framebuffer *fb,
}
}
+static const u64 legacy_modifiers[] = {
+ DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK(0),
+ DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK(1),
+ DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK(2),
+ DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK(3),
+ DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK(4),
+ DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK(5),
+ DRM_FORMAT_MOD_INVALID
+};
+
static int
nouveau_validate_decode_mod(struct nouveau_drm *drm,
uint64_t modifier,
@@ -247,8 +263,14 @@ nouveau_validate_decode_mod(struct nouveau_drm *drm,
(disp->format_modifiers[mod] != modifier);
mod++);
- if (disp->format_modifiers[mod] == DRM_FORMAT_MOD_INVALID)
- return -EINVAL;
+ if (disp->format_modifiers[mod] == DRM_FORMAT_MOD_INVALID) {
+ for (mod = 0;
+(legacy_modifiers[mod] != DRM_FORMAT_MOD_INVALID) &&
+(legacy_modifiers[mod] != modifier);
+mod++);
+ if (legacy_modifiers[mod] == DRM_FORMAT_MOD_INVALID)
+ return -EINVAL;
+ }
nouveau_decode_mod(drm, modifier, tile_mode, kind);
--
2.17.1
___
Nouveau mailing list
nouv...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/6] dt-bindings: display: Document NewVision NV3052C DT node
Hi Paul.
On Mon, Jul 27, 2020 at 06:46:08PM +0200, Paul Cercueil wrote:
> Add documentation for the Device Tree node for LCD panels based on the
> NewVision NV3052C controller.
>
> Signed-off-by: Paul Cercueil
Very happy to see work on RG-350 :-)
Some feedback below.
Sam
> ---
> .../display/panel/newvision,nv3052c.yaml | 69 +++
> 1 file changed, 69 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/panel/newvision,nv3052c.yaml
>
> diff --git
> a/Documentation/devicetree/bindings/display/panel/newvision,nv3052c.yaml
> b/Documentation/devicetree/bindings/display/panel/newvision,nv3052c.yaml
> new file mode 100644
> index ..751a28800fc2
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/newvision,nv3052c.yaml
> @@ -0,0 +1,69 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/panel/newvision,nv3052c.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: NewVision NV3052C TFT LCD panel driver with SPI control bus
> +
> +maintainers:
> + - Paul Cercueil
> +
> +description: |
> + This is a driver for 320x240 TFT panels,
The binding describes the HW, not the driver. So please re-phrase this
part.
This datasheet:
https://www.phoenixdisplay.com/wp-content/uploads/2019/05/NV3052C-Datasheet-V0.2.pdf
tells that the driver supports additional resoltions.
I guess the 320x240 resolution is limited to the leadtek panel.
> + accepting a variety of input
> + streams that get adapted and scaled to the panel. The panel output has
> + 960 TFT source driver pins and 240 TFT gate driver pins, VCOM, VCOML and
> + VCOMH outputs.
> +
> + The panel must obey the rules for a SPI slave device as specified in
> + spi/spi-controller.yaml
> +
> +allOf:
> + - $ref: panel-common.yaml#
> +
> +properties:
> + compatible:
> +items:
> + - enum:
> +- leadtek,ltk035c5444t-spi
> +
> + - const: newvision,nv3052c
> +
> + reg:
> +maxItems: 1
> +
> + reset-gpios: true
> + port: true
> +
> +required:
> + - compatible
> + - reg
> +
> +unevaluatedProperties: false
> +
Do the panel need any power?
I had expected to see a power-supply node as mandatory.
> +examples:
> + - |
> +#include
> +spi {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + display@0 {
> +compatible = "leadtek,ltk035c5444t-spi", "newvision,nv3052c";
> +reg = <0>;
> +
> +spi-max-frequency = <1500>;
> +spi-3wire;
> +reset-gpios = <&gpe 2 GPIO_ACTIVE_LOW>;
> +backlight = <&backlight>;
> +power-supply = <&vcc>;
These would fail later due to "unevaluatedProperties: false".
Add them above like
backlight: true
power-supply: true
as done for reset-gpios for example.
> +
> +port {
> + panel_input: endpoint {
> + remote-endpoint = <&panel_output>;
> + };
> +};
> + };
> +};
Personally I prefer 4 space indent. But there is no fixed rule (yet)
what to use.
> +
> +...
> --
> 2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amd/display: Clear dm_state for fast updates
Am 27.07.20 um 16:05 schrieb Kazlauskas, Nicholas:
On 2020-07-27 9:39 a.m., Christian König wrote:
Am 27.07.20 um 07:40 schrieb Mazin Rezk:
This patch fixes a race condition that causes a use-after-free during
amdgpu_dm_atomic_commit_tail. This can occur when 2 non-blocking
commits
are requested and the second one finishes before the first.
Essentially,
this bug occurs when the following sequence of events happens:
1. Non-blocking commit #1 is requested w/ a new dm_state #1 and is
deferred to the workqueue.
2. Non-blocking commit #2 is requested w/ a new dm_state #2 and is
deferred to the workqueue.
3. Commit #2 starts before commit #1, dm_state #1 is used in the
commit_tail and commit #2 completes, freeing dm_state #1.
4. Commit #1 starts after commit #2 completes, uses the freed dm_state
1 and dereferences a freelist pointer while setting the context.
Well I only have a one mile high view on this, but why don't you let
the work items execute in order?
That would be better anyway cause this way we don't trigger a cache
line ping pong between CPUs.
Christian.
We use the DRM helpers for managing drm_atomic_commit_state and those
helpers internally push non-blocking commit work into the system
unbound work queue.
Mhm, well if you send those helper atomic commits in the order A,B and
they execute it in the order B,A I would call that a bug :)
While we could duplicate a copy of that code with nothing but the
workqueue changed that isn't something I'd really like to maintain
going forward.
I'm not talking about duplicating the code, I'm talking about fixing the
helpers. I don't know that code well, but from the outside it sounds
like a bug there.
And executing work items in the order they are submitted is trivial.
Had anybody pinged Daniel or other people familiar with the helper code
about it?
Regards,
Christian.
Regards,
Nicholas Kazlauskas
Since this bug has only been spotted with fast commits, this patch
fixes
the bug by clearing the dm_state instead of using the old dc_state for
fast updates. In addition, since dm_state is only used for its dc_state
and amdgpu_dm_atomic_commit_tail will retain the dc_state if none is
found,
removing the dm_state should not have any consequences in fast updates.
This use-after-free bug has existed for a while now, but only caused a
noticeable issue starting from 5.7-rc1 due to 3202fa62f ("slub:
relocate
freelist pointer to middle of object") moving the freelist pointer from
dm_state->base (which was unused) to dm_state->context (which is
dereferenced).
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=207383
Fixes: bd200d190f45 ("drm/amd/display: Don't replace the dc_state
for fast updates")
Reported-by: Duncan <1i5t5.dun...@cox.net>
Signed-off-by: Mazin Rezk
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 36
++-
1 file changed, 27 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 86ffa0c2880f..710edc70e37e 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -8717,20 +8717,38 @@ static int amdgpu_dm_atomic_check(struct
drm_device *dev,
* the same resource. If we have a new DC context as part of
* the DM atomic state from validation we need to free it and
* retain the existing one instead.
+ *
+ * Furthermore, since the DM atomic state only contains the DC
+ * context and can safely be annulled, we can free the state
+ * and clear the associated private object now to free
+ * some memory and avoid a possible use-after-free later.
*/
- struct dm_atomic_state *new_dm_state, *old_dm_state;
- new_dm_state = dm_atomic_get_new_state(state);
- old_dm_state = dm_atomic_get_old_state(state);
+ for (i = 0; i < state->num_private_objs; i++) {
+ struct drm_private_obj *obj = state->private_objs[i].ptr;
- if (new_dm_state && old_dm_state) {
- if (new_dm_state->context)
- dc_release_state(new_dm_state->context);
+ if (obj->funcs == adev->dm.atomic_obj.funcs) {
+ int j = state->num_private_objs-1;
- new_dm_state->context = old_dm_state->context;
+ dm_atomic_destroy_state(obj,
+ state->private_objs[i].state);
+
+ /* If i is not at the end of the array then the
+ * last element needs to be moved to where i was
+ * before the array can safely be truncated.
+ */
+ if (i != j)
+ state->private_objs[i] =
+ state->private_objs[j];
- if (old_dm_state->context)
- dc_retain_state(old_dm_state->context);
+ state->private_objs[j].ptr = NULL;
+
Re: [PATCH 1/3] drm: Restore driver.preclose() for all to use
On Thu, Jul 23, 2020 at 7:21 PM Chris Wilson wrote:
>
> An unfortunate sequence of events, but it turns out there is a valid
> usecase for being able to free/decouple the driver objects before they
> are freed by the DRM core. In particular, if we have a pointer into a
> drm core object from inside a driver object, that pointer needs to be
> nerfed *before* it is freed so that concurrent access (e.g. debugfs)
> does not following the dangling pointer.
>
> The legacy marker was adding in the code movement from drp_fops.c to
> drm_file.c
I might fumble a lot, but not this one:
commit 45c3d213a400c952ab7119f394c5293bb6877e6b
Author: Daniel Vetter
Date: Mon May 8 10:26:33 2017 +0200
drm: Nerf the preclose callback for modern drivers
Also looking at the debugfs hook that has some rather adventurous
stuff going on I think, feels a bit like a kitchensink with batteries
included. If that's really all needed I'd say iterate the contexts by
first going over files, then the ctx (which arent shared anyway) and
the problem should also be gone.
-Daniel
> References: 9acdac68bcdc ("drm: rename drm_fops.c to drm_file.c")
> Signed-off-by: Chris Wilson
> Cc: Daniel Vetter
> Cc: Gustavo Padovan
> Cc: CQ Tang
> Cc: # v4.12+
> ---
> drivers/gpu/drm/drm_file.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
> index 0ac4566ae3f4..7b4258d6f7cc 100644
> --- a/drivers/gpu/drm/drm_file.c
> +++ b/drivers/gpu/drm/drm_file.c
> @@ -258,8 +258,7 @@ void drm_file_free(struct drm_file *file)
> (long)old_encode_dev(file->minor->kdev->devt),
> atomic_read(&dev->open_count));
>
> - if (drm_core_check_feature(dev, DRIVER_LEGACY) &&
> - dev->driver->preclose)
> + if (dev->driver->preclose)
> dev->driver->preclose(dev, file);
>
> if (drm_core_check_feature(dev, DRIVER_LEGACY))
> --
> 2.20.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 8/9] clk: qcom: gcc-sdm660: Fix up gcc_mss_mnoc_bimc_axi_clk
Quoting Konrad Dybcio (2020-07-26 04:12:05) > Add missing halt_check, hwcg_reg and hwcg_bit properties. > These were likely omitted when porting the driver upstream. > > Signed-off-by: Konrad Dybcio > --- Fixes tag? ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [v6] dt-bindings: msm: disp: add yaml schemas for DPU and DSI bindings
On Thu, Jul 16, 2020 at 08:15:28PM +0530, Krishna Manikandan wrote: > MSM Mobile Display Subsytem (MDSS) encapsulates sub-blocks > like DPU display controller, DSI etc. Add YAML schema > for the device tree bindings for the same. > > Signed-off-by: Krishna Manikandan > > Changes in v2: > - Changed dpu to DPU (Sam Ravnborg) > - Fixed indentation issues (Sam Ravnborg) > - Added empty line between different properties (Sam Ravnborg) > - Replaced reference txt files with their corresponding > yaml files (Sam Ravnborg) > - Modified the file to use "|" only when it is > necessary (Sam Ravnborg) > > Changes in v3: > - Corrected the license used (Rob Herring) > - Added maxItems for properties (Rob Herring) > - Dropped generic descriptions (Rob Herring) > - Added ranges property (Rob Herring) > - Corrected the indendation (Rob Herring) > - Added additionalProperties (Rob Herring) > - Split dsi file into two, one for dsi controller > and another one for dsi phy per target (Rob Herring) > - Corrected description for pinctrl-names (Rob Herring) > - Corrected the examples used in yaml file (Rob Herring) > - Delete dsi.txt and dpu.txt (Rob Herring) > > Changes in v4: > - Move schema up by one level (Rob Herring) > - Add patternProperties for mdp node (Rob Herring) > - Corrected description of some properties (Rob Herring) > > Changes in v5: > - Correct the indentation (Rob Herring) > - Remove unnecessary description from properties (Rob Herring) > - Correct the number of interconnect entries (Rob Herring) > - Add interconnect names for sc7180 (Rob Herring) > - Add description for ports (Rob Herring) > - Remove common properties (Rob Herring) > - Add unevalutatedProperties (Rob Herring) > - Reference existing dsi controller yaml in the common > dsi controller file (Rob Herring) > - Correct the description of clock names to include only the > clocks that are required (Rob Herring) > - Remove properties which are already covered under the common > binding (Rob Herring) > - Add dsi phy supply nodes which are required for sc7180 and > sdm845 targets (Rob Herring) > - Add type ref for syscon-sfpb (Rob Herring) > > Changes in v6: > - Fixed errors during dt_binding_check (Rob Herring) > - Add maxItems for phys and phys-names (Rob Herring) > - Use unevaluatedProperties wherever required (Rob Herring) > - Removed interrupt controller from required properties for > dsi controller (Rob Herring) > - Add constraints for dsi-phy reg-names based on the compatible > phy version (Rob Herring) > - Add constraints for dsi-phy supply nodes based on the > compatible phy version (Rob Herring) > --- > .../bindings/display/msm/dpu-sc7180.yaml | 236 > .../bindings/display/msm/dpu-sdm845.yaml | 216 ++ > .../devicetree/bindings/display/msm/dpu.txt| 141 > .../display/msm/dsi-common-controller.yaml | 180 +++ > .../display/msm/dsi-controller-sc7180.yaml | 120 ++ > .../display/msm/dsi-controller-sdm845.yaml | 120 ++ > .../bindings/display/msm/dsi-phy-sc7180.yaml | 80 +++ > .../bindings/display/msm/dsi-phy-sdm845.yaml | 82 +++ > .../devicetree/bindings/display/msm/dsi-phy.yaml | 126 +++ > .../devicetree/bindings/display/msm/dsi.txt| 246 > - > 10 files changed, 1160 insertions(+), 387 deletions(-) > create mode 100644 > Documentation/devicetree/bindings/display/msm/dpu-sc7180.yaml > create mode 100644 > Documentation/devicetree/bindings/display/msm/dpu-sdm845.yaml > delete mode 100644 Documentation/devicetree/bindings/display/msm/dpu.txt > create mode 100644 > Documentation/devicetree/bindings/display/msm/dsi-common-controller.yaml > create mode 100644 > Documentation/devicetree/bindings/display/msm/dsi-controller-sc7180.yaml > create mode 100644 > Documentation/devicetree/bindings/display/msm/dsi-controller-sdm845.yaml > create mode 100644 > Documentation/devicetree/bindings/display/msm/dsi-phy-sc7180.yaml > create mode 100644 > Documentation/devicetree/bindings/display/msm/dsi-phy-sdm845.yaml > create mode 100644 Documentation/devicetree/bindings/display/msm/dsi-phy.yaml > delete mode 100644 Documentation/devicetree/bindings/display/msm/dsi.txt > > diff --git a/Documentation/devicetree/bindings/display/msm/dpu-sc7180.yaml > b/Documentation/devicetree/bindings/display/msm/dpu-sc7180.yaml > new file mode 100644 > index 000..df70393 > --- /dev/null > +++ b/Documentation/devicetree/bindings/display/msm/dpu-sc7180.yaml > @@ -0,0 +1,236 @@ > +# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/display/msm/dpu-sc7180.yaml# > +$schema: http://devicetree.org/meta-schemas
Re: [PATCH 1/9] clk: qcom: gcc-sdm660: Add missing modem reset
Quoting Konrad Dybcio (2020-07-26 04:11:58) > This will be required in order to support the > modem upstream. > > Signed-off-by: Konrad Dybcio > --- Should have a fixes tag too. > drivers/clk/qcom/gcc-sdm660.c | 1 + > include/dt-bindings/clock/qcom,gcc-sdm660.h | 1 + > 2 files changed, 2 insertions(+) > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V2] drm: hold gem reference until object is no longer accessed
On Mon, Jul 20, 2020 at 06:30:50PM -0400, Steve Cohen wrote: > A use-after-free in drm_gem_open_ioctl can happen if the > GEM object handle is closed between the idr lookup and > retrieving the size from said object since a local reference > is not being held at that point. Hold the local reference > while the object can still be accessed to fix this and > plug the potential security hole. > > Signed-off-by: Steve Cohen > --- > drivers/gpu/drm/drm_gem.c | 10 -- > 1 file changed, 4 insertions(+), 6 deletions(-) > > diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c > index 7bf628e..ee2058a 100644 > --- a/drivers/gpu/drm/drm_gem.c > +++ b/drivers/gpu/drm/drm_gem.c > @@ -871,9 +871,6 @@ drm_gem_flink_ioctl(struct drm_device *dev, void *data, > * @file_priv: drm file-private structure > * > * Open an object using the global name, returning a handle and the size. > - * > - * This handle (of course) holds a reference to the object, so the object > - * will not go away until the handle is deleted. > */ > int > drm_gem_open_ioctl(struct drm_device *dev, void *data, > @@ -898,14 +895,15 @@ drm_gem_open_ioctl(struct drm_device *dev, void *data, > > /* drm_gem_handle_create_tail unlocks dev->object_name_lock. */ > ret = drm_gem_handle_create_tail(file_priv, obj, &handle); > - drm_gem_object_put_unlocked(obj); > if (ret) > - return ret; > + goto err; > > args->handle = handle; > args->size = obj->size; > > - return 0; > +err: > + drm_gem_object_put_unlocked(obj); > + return ret; > } > > /** As this seems to fix an important issue, any reason it wasn't cc: stable on it so that it gets backported properly? How about a "Fixes:" tag so that we know what commit id it fixes so we know how far back to backport things? And a hint to the maintainers that "this is an issue that needs to get into 5.8-final, it shouldn't wait around longer please" would have also been nice to see :) And what chagned from v1, aren't you supposed to list that somewhere in the changelog or below the --- line (never remember what DRM drivers want here...) Care to send a v3? thanks, greg k-h ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/6] drm: dsi: Let host and device specify supported bus
Hi Paul.
On Mon, Jul 27, 2020 at 06:46:09PM +0200, Paul Cercueil wrote:
> The current MIPI DSI framework can very well be used to support MIPI DBI
> panels. In order to add support for the various bus types supported by
> DBI, the DRM panel drivers should specify the bus type they will use,
> and the DSI host drivers should specify the bus types they are
> compatible with.
>
> The DSI host driver can then use the information provided by the DBI/DSI
> device driver, such as the bus type and the number of lanes, to
> configure its hardware properly.
>
> Signed-off-by: Paul Cercueil
> ---
> drivers/gpu/drm/drm_mipi_dsi.c | 9 +
> include/drm/drm_mipi_dsi.h | 12
> 2 files changed, 21 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_mipi_dsi.c b/drivers/gpu/drm/drm_mipi_dsi.c
> index 5dd475e82995..11ef885de765 100644
> --- a/drivers/gpu/drm/drm_mipi_dsi.c
> +++ b/drivers/gpu/drm/drm_mipi_dsi.c
> @@ -281,6 +281,9 @@ int mipi_dsi_host_register(struct mipi_dsi_host *host)
> {
> struct device_node *node;
>
> + if (WARN_ON_ONCE(!host->bus_types))
> + host->bus_types = MIPI_DEVICE_TYPE_DSI;
> +
So all 14 users need to specify bus_types.
Seems doable.
> for_each_available_child_of_node(host->dev->of_node, node) {
> /* skip nodes without reg property */
> if (!of_find_property(node, "reg", NULL))
> @@ -323,6 +326,12 @@ int mipi_dsi_attach(struct mipi_dsi_device *dsi)
> {
> const struct mipi_dsi_host_ops *ops = dsi->host->ops;
>
> + if (WARN_ON_ONCE(!dsi->bus_type))
> + dsi->bus_type = MIPI_DEVICE_TYPE_DSI;
We have ~50 users of mipi_dsi_attach() - doable. But a bit more work.
> +
> + if (!(dsi->bus_type & dsi->host->bus_types))
> + return -EINVAL;
> +
> if (!ops || !ops->attach)
> return -ENOSYS;
>
> diff --git a/include/drm/drm_mipi_dsi.h b/include/drm/drm_mipi_dsi.h
> index 360e6377e84b..65d2961fc054 100644
> --- a/include/drm/drm_mipi_dsi.h
> +++ b/include/drm/drm_mipi_dsi.h
> @@ -63,6 +63,14 @@ struct mipi_dsi_packet {
> int mipi_dsi_create_packet(struct mipi_dsi_packet *packet,
> const struct mipi_dsi_msg *msg);
>
> +/* MIPI bus types */
If you define this as an enum then kernel-doc syntax will be picked up.
See for example: enum drm_driver_feature
> +#define MIPI_DEVICE_TYPE_DSI BIT(0)
> +#define MIPI_DEVICE_TYPE_DBI_SPI_MODE1 BIT(1)
> +#define MIPI_DEVICE_TYPE_DBI_SPI_MODE2 BIT(2)
> +#define MIPI_DEVICE_TYPE_DBI_SPI_MODE3 BIT(3)
> +#define MIPI_DEVICE_TYPE_DBI_M6800 BIT(4)
> +#define MIPI_DEVICE_TYPE_DBI_I8080 BIT(5)
> +
> /**
> * struct mipi_dsi_host_ops - DSI bus operations
> * @attach: attach DSI device to DSI host
> @@ -94,11 +102,13 @@ struct mipi_dsi_host_ops {
> * struct mipi_dsi_host - DSI host device
> * @dev: driver model device node for this DSI host
> * @ops: DSI host operations
> + * @bus_types: Bitmask of supported MIPI bus types
Please add some kind of reference to MIPI_DEVICE_TYPE_* - so the reader
knows for sure this is the bits used here.
> * @list: list management
> */
> struct mipi_dsi_host {
> struct device *dev;
> const struct mipi_dsi_host_ops *ops;
> + unsigned int bus_types;
Use u32. Shorter and we know this is 32 bits wide.
> struct list_head list;
> };
>
> @@ -162,6 +172,7 @@ struct mipi_dsi_device_info {
> * @host: DSI host for this peripheral
> * @dev: driver model device node for this peripheral
> * @name: DSI peripheral chip type
> + * @bus_type: MIPI bus type (MIPI_DEVICE_TYPE_DSI/...)
> * @channel: virtual channel assigned to the peripheral
> * @format: pixel format for video mode
> * @lanes: number of active data lanes
> @@ -178,6 +189,7 @@ struct mipi_dsi_device {
> struct device dev;
>
> char name[DSI_DEV_NAME_SIZE];
> + unsigned int bus_type;
Use u32.
> unsigned int channel;
> unsigned int lanes;
> enum mipi_dsi_pixel_format format;
> --
> 2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH 1/3] drm: Restore driver.preclose() for all to use
> -Original Message-
> From: Daniel Vetter
> Sent: Monday, July 27, 2020 12:33 PM
> To: Chris Wilson ; Dave Airlie
> Cc: intel-gfx ; stable
> ; Gustavo Padovan
> ; Tang, CQ ; dri-
> devel ; Vetter, Daniel
>
> Subject: Re: [PATCH 1/3] drm: Restore driver.preclose() for all to use
>
> On Thu, Jul 23, 2020 at 7:21 PM Chris Wilson
> wrote:
> >
> > An unfortunate sequence of events, but it turns out there is a valid
> > usecase for being able to free/decouple the driver objects before they
> > are freed by the DRM core. In particular, if we have a pointer into a
> > drm core object from inside a driver object, that pointer needs to be
> > nerfed *before* it is freed so that concurrent access (e.g. debugfs)
> > does not following the dangling pointer.
> >
> > The legacy marker was adding in the code movement from drp_fops.c to
> > drm_file.c
>
> I might fumble a lot, but not this one:
>
> commit 45c3d213a400c952ab7119f394c5293bb6877e6b
> Author: Daniel Vetter
> Date: Mon May 8 10:26:33 2017 +0200
>
> drm: Nerf the preclose callback for modern drivers
>
> Also looking at the debugfs hook that has some rather adventurous stuff
> going on I think, feels a bit like a kitchensink with batteries included. If
> that's
> really all needed I'd say iterate the contexts by first going over files,
> then the
> ctx (which arent shared anyway) and the problem should also be gone.
Debugfs code can jump in after drm_gem_release() (where file->object_idr is
destroyed), but before postclose(). At this window, everything is fine for
debugfs context accessing except the file->object_idr.
--CQ
> -Daniel
>
> > References: 9acdac68bcdc ("drm: rename drm_fops.c to drm_file.c")
> > Signed-off-by: Chris Wilson
> > Cc: Daniel Vetter
> > Cc: Gustavo Padovan
> > Cc: CQ Tang
> > Cc: # v4.12+
> > ---
> > drivers/gpu/drm/drm_file.c | 3 +--
> > 1 file changed, 1 insertion(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
> > index 0ac4566ae3f4..7b4258d6f7cc 100644
> > --- a/drivers/gpu/drm/drm_file.c
> > +++ b/drivers/gpu/drm/drm_file.c
> > @@ -258,8 +258,7 @@ void drm_file_free(struct drm_file *file)
> > (long)old_encode_dev(file->minor->kdev->devt),
> > atomic_read(&dev->open_count));
> >
> > - if (drm_core_check_feature(dev, DRIVER_LEGACY) &&
> > - dev->driver->preclose)
> > + if (dev->driver->preclose)
> > dev->driver->preclose(dev, file);
> >
> > if (drm_core_check_feature(dev, DRIVER_LEGACY))
> > --
> > 2.20.1
> >
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V2] drm: hold gem reference until object is no longer accessed
On Mon, Jul 27, 2020 at 09:55:07PM +0200, Greg KH wrote: > On Mon, Jul 20, 2020 at 06:30:50PM -0400, Steve Cohen wrote: > > A use-after-free in drm_gem_open_ioctl can happen if the > > GEM object handle is closed between the idr lookup and > > retrieving the size from said object since a local reference > > is not being held at that point. Hold the local reference > > while the object can still be accessed to fix this and > > plug the potential security hole. > > > > Signed-off-by: Steve Cohen > > --- > > drivers/gpu/drm/drm_gem.c | 10 -- > > 1 file changed, 4 insertions(+), 6 deletions(-) > > > > diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c > > index 7bf628e..ee2058a 100644 > > --- a/drivers/gpu/drm/drm_gem.c > > +++ b/drivers/gpu/drm/drm_gem.c > > @@ -871,9 +871,6 @@ drm_gem_flink_ioctl(struct drm_device *dev, void *data, > > * @file_priv: drm file-private structure > > * > > * Open an object using the global name, returning a handle and the size. > > - * > > - * This handle (of course) holds a reference to the object, so the object > > - * will not go away until the handle is deleted. > > */ > > int > > drm_gem_open_ioctl(struct drm_device *dev, void *data, > > @@ -898,14 +895,15 @@ drm_gem_open_ioctl(struct drm_device *dev, void *data, > > > > /* drm_gem_handle_create_tail unlocks dev->object_name_lock. */ > > ret = drm_gem_handle_create_tail(file_priv, obj, &handle); > > - drm_gem_object_put_unlocked(obj); > > if (ret) > > - return ret; > > + goto err; > > > > args->handle = handle; > > args->size = obj->size; > > > > - return 0; > > +err: > > + drm_gem_object_put_unlocked(obj); > > + return ret; > > } > > > > /** > > As this seems to fix an important issue, any reason it wasn't cc: stable > on it so that it gets backported properly? > > How about a "Fixes:" tag so that we know what commit id it fixes so we > know how far back to backport things? > > And a hint to the maintainers that "this is an issue that needs to get > into 5.8-final, it shouldn't wait around longer please" would have also > been nice to see :) > > And what chagned from v1, aren't you supposed to list that somewhere in > the changelog or below the --- line (never remember what DRM drivers > want here...) > > Care to send a v3? Don't worry, I'm pushing this to drm-misc-fixes now, should still make it to 5.8. Plus cc: stable. I didn't bother with Fixes: since I think the bug is rather old. Also, worst case you leak 32bit of some kernel memory that got reused already (but yeah I know that's often enough to get the foot in somewhere nasty and crack the door open). I think it fell through cracks because Sam said he'll apply, guess that didn't happen. Also yes a changelog, somewhere, for next time around. -Daniel > > thanks, > > greg k-h -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amd/display: Clear dm_state for fast updates
On Mon, Jul 27, 2020 at 9:28 PM Christian König
wrote:
>
> Am 27.07.20 um 16:05 schrieb Kazlauskas, Nicholas:
> > On 2020-07-27 9:39 a.m., Christian König wrote:
> >> Am 27.07.20 um 07:40 schrieb Mazin Rezk:
> >>> This patch fixes a race condition that causes a use-after-free during
> >>> amdgpu_dm_atomic_commit_tail. This can occur when 2 non-blocking
> >>> commits
> >>> are requested and the second one finishes before the first.
> >>> Essentially,
> >>> this bug occurs when the following sequence of events happens:
> >>>
> >>> 1. Non-blocking commit #1 is requested w/ a new dm_state #1 and is
> >>> deferred to the workqueue.
> >>>
> >>> 2. Non-blocking commit #2 is requested w/ a new dm_state #2 and is
> >>> deferred to the workqueue.
> >>>
> >>> 3. Commit #2 starts before commit #1, dm_state #1 is used in the
> >>> commit_tail and commit #2 completes, freeing dm_state #1.
> >>>
> >>> 4. Commit #1 starts after commit #2 completes, uses the freed dm_state
> >>> 1 and dereferences a freelist pointer while setting the context.
> >>
> >> Well I only have a one mile high view on this, but why don't you let
> >> the work items execute in order?
> >>
> >> That would be better anyway cause this way we don't trigger a cache
> >> line ping pong between CPUs.
> >>
> >> Christian.
> >
> > We use the DRM helpers for managing drm_atomic_commit_state and those
> > helpers internally push non-blocking commit work into the system
> > unbound work queue.
>
> Mhm, well if you send those helper atomic commits in the order A,B and
> they execute it in the order B,A I would call that a bug :)
The way it works is it pushes all commits into unbound work queue, but
then forces serialization as needed. We do _not_ want e.g. updates on
different CRTC to be serialized, that would result in lots of judder.
And hw is funny enough that there's all kinds of dependencies.
The way you force synchronization is by adding other CRTC state
objects. So if DC is busted and can only handle a single update per
work item, then I guess you always need all CRTC states and everything
will be run in order. But that also totally kills modern multi-screen
compositors. Xorg isn't modern, just in case that's not clear :-)
Lucking at the code it seems like you indeed have only a single dm
state, so yeah global sync is what you'll need as immediate fix, and
then maybe fix up DM to not be quite so silly ... or at least only do
the dm state stuff when really needed.
We could also sprinkle the drm_crtc_commit structure around a bit
(it's the glue that provides the synchronization across commits), but
since your dm state is global just grabbing all crtc states
unconditionally as part of that is probably best.
> > While we could duplicate a copy of that code with nothing but the
> > workqueue changed that isn't something I'd really like to maintain
> > going forward.
>
> I'm not talking about duplicating the code, I'm talking about fixing the
> helpers. I don't know that code well, but from the outside it sounds
> like a bug there.
>
> And executing work items in the order they are submitted is trivial.
>
> Had anybody pinged Daniel or other people familiar with the helper code
> about it?
Yeah something is wrong here, and the fix looks horrible :-)
Aside, I've also seen some recent discussion flare up about
drm_atomic_state_get/put used to paper over some other use-after-free,
but this time related to interrupt handlers. Maybe a few rules about
that:
- dont
- especially not when it's interrupt handlers, because you can't call
drm_atomic_state_put from interrupt handlers.
Instead have an spin_lock_irq to protect the shared date with your
interrupt handler, and _copy_ the date over. This is e.g. what
drm_crtc_arm_vblank_event does.
Cheers, Daniel
>
> Regards,
> Christian.
>
> >
> > Regards,
> > Nicholas Kazlauskas
> >
> >>
> >>>
> >>> Since this bug has only been spotted with fast commits, this patch
> >>> fixes
> >>> the bug by clearing the dm_state instead of using the old dc_state for
> >>> fast updates. In addition, since dm_state is only used for its dc_state
> >>> and amdgpu_dm_atomic_commit_tail will retain the dc_state if none is
> >>> found,
> >>> removing the dm_state should not have any consequences in fast updates.
> >>>
> >>> This use-after-free bug has existed for a while now, but only caused a
> >>> noticeable issue starting from 5.7-rc1 due to 3202fa62f ("slub:
> >>> relocate
> >>> freelist pointer to middle of object") moving the freelist pointer from
> >>> dm_state->base (which was unused) to dm_state->context (which is
> >>> dereferenced).
> >>>
> >>> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=207383
> >>> Fixes: bd200d190f45 ("drm/amd/display: Don't replace the dc_state
> >>> for fast updates")
> >>> Reported-by: Duncan <1i5t5.dun...@cox.net>
> >>> Signed-off-by: Mazin Rezk
> >>> ---
> >>> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 36
> >>> ++-
> >>> 1 file changed, 27 insertions(+), 9 deletions
Re: [PATCH 3/6] drm/bridge: Add SPI DBI host driver
Hi Paul.
On Mon, Jul 27, 2020 at 06:46:10PM +0200, Paul Cercueil wrote:
> This driver will register a DBI host driver for panels connected over
> SPI.
So this is actually a MIPI DBI host driver.
I personally would love to have added mipi_ in the names - to make it
all more explicit.
But maybe that just because I get confused on all the acronyms.
Some details in the following. Will try to find some more time so I can
grasp the full picture. The following was just my low-level notes for
now.
Sam
>
> DBI types c1 and c3 are supported. C1 is a SPI protocol with 9 bits per
> word, with the data/command information in the 9th (MSB) bit. C3 is a
> SPI protocol with 8 bits per word, with the data/command information
> carried by a separate GPIO.
We did not have any define to distingush between DBI_C1 and DBI_c3:
+/* MIPI bus types */
+#define MIPI_DEVICE_TYPE_DSI BIT(0)
+#define MIPI_DEVICE_TYPE_DBI_SPI_MODE1 BIT(1)
+#define MIPI_DEVICE_TYPE_DBI_SPI_MODE2 BIT(2)
+#define MIPI_DEVICE_TYPE_DBI_SPI_MODE3 BIT(3)
+#define MIPI_DEVICE_TYPE_DBI_M6800 BIT(4)
+#define MIPI_DEVICE_TYPE_DBI_I8080 BIT(5)
Is this on purpose?
I had assumed the host should tell what it supports and the device should
tell what it wanted.
So if the host did not support DBI_C3 and device wants it - then we
could give up early.
>
> Signed-off-by: Paul Cercueil
> ---
> drivers/gpu/drm/bridge/Kconfig | 8 +
> drivers/gpu/drm/bridge/Makefile | 1 +
> drivers/gpu/drm/bridge/dbi-spi.c | 261 +++
This is no bridge driver - so does not belong in the bridge
directory.
gpu/drm/drm_mipi_dbi_spi.c?
> 3 files changed, 270 insertions(+)
> create mode 100644 drivers/gpu/drm/bridge/dbi-spi.c
>
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index c7f0dacfb57a..ed38366847c1 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -219,6 +219,14 @@ config DRM_TI_TPD12S015
> Texas Instruments TPD12S015 HDMI level shifter and ESD protection
> driver.
>
> +config DRM_MIPI_DBI_SPI
> + tristate "SPI host support for MIPI DBI"
> + depends on OF && SPI
> + select DRM_MIPI_DSI
> + select DRM_MIPI_DBI
> + help
> + Driver to support DBI over SPI.
> +
> source "drivers/gpu/drm/bridge/analogix/Kconfig"
>
> source "drivers/gpu/drm/bridge/adv7511/Kconfig"
> diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
> index 7d7c123a95e4..c2c522c2774f 100644
> --- a/drivers/gpu/drm/bridge/Makefile
> +++ b/drivers/gpu/drm/bridge/Makefile
> @@ -20,6 +20,7 @@ obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/
> obj-$(CONFIG_DRM_TI_SN65DSI86) += ti-sn65dsi86.o
> obj-$(CONFIG_DRM_TI_TFP410) += ti-tfp410.o
> obj-$(CONFIG_DRM_TI_TPD12S015) += ti-tpd12s015.o
> +obj-$(CONFIG_DRM_MIPI_DBI_SPI) += dbi-spi.o
mipi_dbi_spi.o would be nice...
> obj-$(CONFIG_DRM_NWL_MIPI_DSI) += nwl-dsi.o
>
> obj-y += analogix/
> diff --git a/drivers/gpu/drm/bridge/dbi-spi.c
> b/drivers/gpu/drm/bridge/dbi-spi.c
> new file mode 100644
> index ..1060b8f95fba
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/dbi-spi.c
> @@ -0,0 +1,261 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * MIPI Display Bus Interface (DBI) SPI support
> + *
> + * Copyright 2016 Noralf Trønnes
> + * Copyright 2020 Paul Cercueil
> + */
> +
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +
> +#include
> +
> +struct dbi_spi {
> + struct mipi_dsi_host host;
It is very confusing that the mipi_dbi_spi driver uses a dsi_host.
It clashes in my head - and then reviewing it not easy.
> + struct mipi_dsi_host_ops host_ops;
const?
> +
> + struct spi_device *spi;
> + struct gpio_desc *dc;
> + struct mutex cmdlock;
> +
> + unsigned int current_bus_type;
> +
> + /**
> + * @tx_buf9: Buffer used for Option 1 9-bit conversion
> + */
> + void *tx_buf9;
> +
> + /**
> + * @tx_buf9_len: Size of tx_buf9.
> + */
> + size_t tx_buf9_len;
> +};
> +
> +static inline struct dbi_spi *host_to_dbi_spi(struct mipi_dsi_host *host)
> +{
> + return container_of(host, struct dbi_spi, host);
> +}
> +
> +static ssize_t dbi_spi1_transfer(struct mipi_dsi_host *host,
> + const struct mipi_dsi_msg *msg)
> +{
> + struct dbi_spi *dbi = host_to_dbi_spi(host);
> + struct spi_device *spi = dbi->spi;
> + struct spi_transfer tr = {
> + .bits_per_word = 9,
> + };
> + const u8 *src8 = msg->tx_buf;
> + struct spi_message m;
> + size_t max_chunk, chunk;
> + size_t len = msg->tx_len;
> + bool cmd_byte = true;
> + unsigned int i;
> + u16 *dst16;
> + int ret;
> +
> + tr.speed_hz = mipi_dbi_spi_cmd_max_speed(spi, len);
> + dst16 = dbi->tx_buf9;
> +
> + max_chunk = min(dbi->tx_buf9_len / 2, len);
Hmm, this looks not right. We limit the max_chunk to 8K here.
We learned the other day th
Re: [PATCH v3 1/2] dt-bindings: display: panel: Add bindings for Tianma nt36672a panel
On Mon, 27 Jul 2020 13:13:47 +0530, Sumit Semwal wrote: > The nt36672a panel from Tianma is a FHD+ panel with a resolution of > 1080x2246 and 6.18 inches size. It is found in some of the Poco F1 > phones. > > Signed-off-by: Sumit Semwal > > --- > v2: remove ports node, making port@0 directly under panel@0 node. > v3: updated to replace port@0 to just 'port'. > --- > .../display/panel/tianma,nt36672a.yaml| 95 +++ > 1 file changed, 95 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/panel/tianma,nt36672a.yaml > Reviewed-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amd/display: Clear dm_state for fast updates
On Mon, Jul 27, 2020 at 10:29 PM Daniel Vetter wrote: > > On Mon, Jul 27, 2020 at 9:28 PM Christian König > wrote: > > > > Am 27.07.20 um 16:05 schrieb Kazlauskas, Nicholas: > > > On 2020-07-27 9:39 a.m., Christian König wrote: > > >> Am 27.07.20 um 07:40 schrieb Mazin Rezk: > > >>> This patch fixes a race condition that causes a use-after-free during > > >>> amdgpu_dm_atomic_commit_tail. This can occur when 2 non-blocking > > >>> commits > > >>> are requested and the second one finishes before the first. > > >>> Essentially, > > >>> this bug occurs when the following sequence of events happens: > > >>> > > >>> 1. Non-blocking commit #1 is requested w/ a new dm_state #1 and is > > >>> deferred to the workqueue. > > >>> > > >>> 2. Non-blocking commit #2 is requested w/ a new dm_state #2 and is > > >>> deferred to the workqueue. > > >>> > > >>> 3. Commit #2 starts before commit #1, dm_state #1 is used in the > > >>> commit_tail and commit #2 completes, freeing dm_state #1. > > >>> > > >>> 4. Commit #1 starts after commit #2 completes, uses the freed dm_state > > >>> 1 and dereferences a freelist pointer while setting the context. > > >> > > >> Well I only have a one mile high view on this, but why don't you let > > >> the work items execute in order? > > >> > > >> That would be better anyway cause this way we don't trigger a cache > > >> line ping pong between CPUs. > > >> > > >> Christian. > > > > > > We use the DRM helpers for managing drm_atomic_commit_state and those > > > helpers internally push non-blocking commit work into the system > > > unbound work queue. > > > > Mhm, well if you send those helper atomic commits in the order A,B and > > they execute it in the order B,A I would call that a bug :) > > The way it works is it pushes all commits into unbound work queue, but > then forces serialization as needed. We do _not_ want e.g. updates on > different CRTC to be serialized, that would result in lots of judder. > And hw is funny enough that there's all kinds of dependencies. > > The way you force synchronization is by adding other CRTC state > objects. So if DC is busted and can only handle a single update per > work item, then I guess you always need all CRTC states and everything > will be run in order. But that also totally kills modern multi-screen > compositors. Xorg isn't modern, just in case that's not clear :-) > > Lucking at the code it seems like you indeed have only a single dm > state, so yeah global sync is what you'll need as immediate fix, and > then maybe fix up DM to not be quite so silly ... or at least only do > the dm state stuff when really needed. Just looked a bit more at this struct dc_state, and that looks a lot like an atomic side-wagon. I don't think that works as a private state, this should probably be embedded into a subclass of drm_atomic_state. And probably a lot of these pointers moved to other places I think, or I'm not entirely clear on what exactly this stuff is needed for ... dc_state is also refcounted, which is definitely rather funny for a state structure. Feels like this entire thing (how the overall dc state machinery is glued into atomic) isn't quite thought thru just yet :-/ -Daniel > We could also sprinkle the drm_crtc_commit structure around a bit > (it's the glue that provides the synchronization across commits), but > since your dm state is global just grabbing all crtc states > unconditionally as part of that is probably best. > > > > While we could duplicate a copy of that code with nothing but the > > > workqueue changed that isn't something I'd really like to maintain > > > going forward. > > > > I'm not talking about duplicating the code, I'm talking about fixing the > > helpers. I don't know that code well, but from the outside it sounds > > like a bug there. > > > > And executing work items in the order they are submitted is trivial. > > > > Had anybody pinged Daniel or other people familiar with the helper code > > about it? > > Yeah something is wrong here, and the fix looks horrible :-) > > Aside, I've also seen some recent discussion flare up about > drm_atomic_state_get/put used to paper over some other use-after-free, > but this time related to interrupt handlers. Maybe a few rules about > that: > - dont > - especially not when it's interrupt handlers, because you can't call > drm_atomic_state_put from interrupt handlers. > > Instead have an spin_lock_irq to protect the shared date with your > interrupt handler, and _copy_ the date over. This is e.g. what > drm_crtc_arm_vblank_event does. > > Cheers, Daniel > > > > > Regards, > > Christian. > > > > > > > > Regards, > > > Nicholas Kazlauskas > > > > > >> > > >>> > > >>> Since this bug has only been spotted with fast commits, this patch > > >>> fixes > > >>> the bug by clearing the dm_state instead of using the old dc_state for > > >>> fast updates. In addition, since dm_state is only used for its dc_state > > >>> and amdgpu_dm_atomic_commit_tail will retain the dc_state if none is >
Re: [PATCH 3/3] drm/i915/gem: Serialise debugfs i915_gem_objects with ctx->mutex
Hi
[This is an automated email]
This commit has been processed because it contains a -stable tag.
The stable tag indicates that it's relevant for the following trees: all
The bot has tested the following trees: v5.7.10, v5.4.53, v4.19.134, v4.14.189,
v4.9.231, v4.4.231.
v5.7.10: Build OK!
v5.4.53: Failed to apply! Possible dependencies:
061489c65ff5 ("drm/i915/dsb: single register write function for DSB.")
11988e393813 ("drm/i915/execlists: Try rearranging breadcrumb flush")
2850748ef876 ("drm/i915: Pull i915_vma_pin under the vm->mutex")
5a90606df7cb ("drm/i915: Replace obj->pin_global with obj->frontbuffer")
67f3b58f3bac ("drm/i915/dsb: DSB context creation.")
8a9a982767b7 ("drm/i915: use a separate context for gpu relocs")
a4e7ccdac38e ("drm/i915: Move context management under GEM")
b27a96ad72fd ("drm/i915/dsb: Indexed register write function for DSB.")
bb120e1171a9 ("drm/i915: Show the logical context ring state on dumping")
c210e85b8f33 ("drm/i915/tgl: Extend MI_SEMAPHORE_WAIT")
d19d71fc2b15 ("drm/i915: Mark i915_request.timeline as a volatile, rcu
pointer")
e8f6b4952ec5 ("drm/i915/execlists: Flush the post-sync breadcrumb write
harder")
v4.19.134: Failed to apply! Possible dependencies:
0258404f9d38 ("drm/i915: start moving runtime device info to a separate
struct")
026844460743 ("drm/i915: Remove intel_context.active_link")
07d805721938 ("drm/i915: Introduce intel_runtime_pm_disable to pair
intel_runtime_pm_enable")
13f1bfd3b332 ("drm/i915: Make object/vma allocation caches global")
1c71bc565cdb ("drm/i915/perf: simplify configure all context function")
2cc8376fd350 ("drm/i915: rename dev_priv info to __info to avoid usage")
2cd9a689e97b ("drm/i915: Refactor intel_display_set_init_power() logic")
37d7c9cc2eb6 ("drm/i915: Check engine->default_state mapping on module
load")
55ac5a1614f9 ("drm/i915: Attach the pci match data to the device upon
creation")
666424abfb86 ("drm/i915/execlists: Use coherent writes into the context
image")
6dfc4a8f134f ("drm/i915: Verify power domains after enabling them")
722f3de39e03 ("i915/oa: Simplify updating contexts")
900ccf30f9e1 ("drm/i915: Only force GGTT coherency w/a on required
chipsets")
c4d52feb2c46 ("drm/i915: Move over to intel_context_lookup()")
f6e8aa387171 ("drm/i915: Report the number of closed vma held by each
context in debugfs")
fa9f668141f4 ("drm/i915: Export intel_context_instance()")
v4.14.189: Failed to apply! Possible dependencies:
3bd4073524fa ("drm/i915: Consolidate get_fence with pin_fence")
465c403cb508 ("drm/i915: introduce simple gemfs")
66df1014efba ("drm/i915: Keep a small stash of preallocated WC pages")
67b48040255b ("drm/i915: Assert that the handle->vma lut is empty on object
close")
73ebd503034c ("drm/i915: make mappable struct resource centric")
7789422665f5 ("drm/i915: make dsm struct resource centric")
82ad6443a55e ("drm/i915/gtt: Rename i915_hw_ppgtt base member")
969b0950a188 ("drm/i915: Add interface to reserve fence registers for vGPU")
a65adaf8a834 ("drm/i915: Track user GTT faulting per-vma")
b4563f595ed4 ("drm/i915: Pin fence for iomap")
e91ef99b9543 ("drm/i915/selftests: Remember to create the fake preempt
context")
f6e8aa387171 ("drm/i915: Report the number of closed vma held by each
context in debugfs")
f773568b6ff8 ("drm/i915: nuke the duplicated stolen discovery")
v4.9.231: Failed to apply! Possible dependencies:
0e70447605f4 ("drm/i915: Move common code out of i915_gpu_error.c")
1b36595ffb35 ("drm/i915: Show RING registers through debugfs")
28a60dee2ce6 ("drm/i915/gvt: vGPU HW resource management")
3b3f1650b1ca ("drm/i915: Allocate intel_engine_cs structure only for the
enabled engines")
82ad6443a55e ("drm/i915/gtt: Rename i915_hw_ppgtt base member")
85fd4f58d7ef ("drm/i915: Mark all non-vma being inserted into the address
spaces")
9c870d03674f ("drm/i915: Use RPM as the barrier for controlling user mmap
access")
bb6dc8d96b68 ("drm/i915: Implement pread without struct-mutex")
d636951ec01b ("drm/i915: Cleanup instdone collection")
e007b19d7ba7 ("drm/i915: Use the MRU stack search after evicting")
f6e8aa387171 ("drm/i915: Report the number of closed vma held by each
context in debugfs")
f9e613728090 ("drm/i915: Try to print INSTDONE bits for all slice/subslice")
v4.4.231: Failed to apply! Possible dependencies:
1b683729e7ac ("drm/i915: Remove redundant check in i915_gem_obj_to_vma")
1c7f4bca5a6f ("drm/i915: Rename vma->*_list to *_link for consistency")
3272db53136f ("drm/i915: Combine all i915_vma bitfields into a single set
of flags")
596c5923197b ("drm/i915: Reduce the pointer dance of i915_is_ggtt()")
c1a415e261aa ("drm/i915: Disable shrinker for non-swapped backed objects")
d0710abbcd88 ("drm/i915: Set the map-and-fenceable flag for preallocated
objects")
Re: [PATCH 1/3] drm: Restore driver.preclose() for all to use
Hi
[This is an automated email]
This commit has been processed because it contains a -stable tag.
The stable tag indicates that it's relevant for the following trees: 4.12+
The bot has tested the following trees: v5.7.10, v5.4.53, v4.19.134, v4.14.189.
v5.7.10: Build OK!
v5.4.53: Build OK!
v4.19.134: Build OK!
v4.14.189: Failed to apply! Possible dependencies:
112ed2d31a46 ("drm/i915: Move GraphicsTechnology files under gt/")
1572042a4ab2 ("drm: provide management functions for drm_file")
7a2c65dd32b1 ("drm: Release filp before global lock")
7e13ad896484 ("drm: Avoid drm_global_mutex for simple inc/dec of
dev->open_count")
b46a33e271ed ("drm/i915/pmu: Expose a PMU interface for perf queries")
c2400ec3b6d1 ("drm/i915: add Makefile magic for testing headers are
self-contained")
cc662126b413 ("drm/i915: Introduce DRM_I915_GEM_MMAP_OFFSET")
e7af3116836f ("drm/i915: Introduce a preempt context")
f0e4a0639752 ("drm/i915: Move GEM domain management to its own file")
NOTE: The patch will not be queued to stable trees until it is upstream.
How should we proceed with this patch?
--
Thanks
Sasha
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/amdgpu/dc: Stop dma_resv_lock inversion in commit_tail
Trying to grab dma_resv_lock while in commit_tail before we've done
all the code that leads to the eventual signalling of the vblank event
(which can be a dma_fence) is deadlock-y. Don't do that.
Here the solution is easy because just grabbing locks to read
something races anyway. We don't need to bother, READ_ONCE is
equivalent. And avoids the locking issue.
v2: Also take into account tmz_surface boolean, plus just delete the
old code.
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Cc: linux-r...@vger.kernel.org
Cc: amd-...@lists.freedesktop.org
Cc: intel-...@lists.freedesktop.org
Cc: Chris Wilson
Cc: Maarten Lankhorst
Cc: Christian König
Signed-off-by: Daniel Vetter
---
DC-folks, I think this split out patch from my series here
https://lore.kernel.org/dri-devel/20200707201229.472834-1-daniel.vet...@ffwll.ch/
should be ready for review/merging. I fixed it up a bit so that it's not
just a gross hack :-)
Cheers, Daniel
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 19 ++-
1 file changed, 6 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 21ec64fe5527..a20b62b1f2ef 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -6959,20 +6959,13 @@ static void amdgpu_dm_commit_planes(struct
drm_atomic_state *state,
DRM_ERROR("Waiting for fences timed out!");
/*
-* TODO This might fail and hence better not used, wait
-* explicitly on fences instead
-* and in general should be called for
-* blocking commit to as per framework helpers
+* We cannot reserve buffers here, which means the normal flag
+* access functions don't work. Paper over this with READ_ONCE,
+* but maybe the flags are invariant enough that not even that
+* would be needed.
*/
- r = amdgpu_bo_reserve(abo, true);
- if (unlikely(r != 0))
- DRM_ERROR("failed to reserve buffer before flip\n");
-
- amdgpu_bo_get_tiling_flags(abo, &tiling_flags);
-
- tmz_surface = amdgpu_bo_encrypted(abo);
-
- amdgpu_bo_unreserve(abo);
+ tiling_flags = READ_ONCE(abo->tiling_flags);
+ tmz_surface = READ_ONCE(abo->flags) &
AMDGPU_GEM_CREATE_ENCRYPTED;
fill_dc_plane_info_and_addr(
dm->adev, new_plane_state, tiling_flags,
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amd/display: Clear dm_state for fast updates
On Mon, Jul 27, 2020 at 11:11 PM Mazin Rezk wrote: > > On Monday, July 27, 2020 4:29 PM, Daniel Vetter wrote: > > > On Mon, Jul 27, 2020 at 9:28 PM Christian König > > wrote: > > > > > > Am 27.07.20 um 16:05 schrieb Kazlauskas, Nicholas: > > > > On 2020-07-27 9:39 a.m., Christian König wrote: > > > >> Am 27.07.20 um 07:40 schrieb Mazin Rezk: > > > >>> This patch fixes a race condition that causes a use-after-free during > > > >>> amdgpu_dm_atomic_commit_tail. This can occur when 2 non-blocking > > > >>> commits > > > >>> are requested and the second one finishes before the first. > > > >>> Essentially, > > > >>> this bug occurs when the following sequence of events happens: > > > >>> > > > >>> 1. Non-blocking commit #1 is requested w/ a new dm_state #1 and is > > > >>> deferred to the workqueue. > > > >>> > > > >>> 2. Non-blocking commit #2 is requested w/ a new dm_state #2 and is > > > >>> deferred to the workqueue. > > > >>> > > > >>> 3. Commit #2 starts before commit #1, dm_state #1 is used in the > > > >>> commit_tail and commit #2 completes, freeing dm_state #1. > > > >>> > > > >>> 4. Commit #1 starts after commit #2 completes, uses the freed dm_state > > > >>> 1 and dereferences a freelist pointer while setting the context. > > > >> > > > >> Well I only have a one mile high view on this, but why don't you let > > > >> the work items execute in order? > > > >> > > > >> That would be better anyway cause this way we don't trigger a cache > > > >> line ping pong between CPUs. > > > >> > > > >> Christian. > > > > > > > > We use the DRM helpers for managing drm_atomic_commit_state and those > > > > helpers internally push non-blocking commit work into the system > > > > unbound work queue. > > > > > > Mhm, well if you send those helper atomic commits in the order A,B and > > > they execute it in the order B,A I would call that a bug :) > > > > The way it works is it pushes all commits into unbound work queue, but > > then forces serialization as needed. We do _not_ want e.g. updates on > > different CRTC to be serialized, that would result in lots of judder. > > And hw is funny enough that there's all kinds of dependencies. > > > > The way you force synchronization is by adding other CRTC state > > objects. So if DC is busted and can only handle a single update per > > work item, then I guess you always need all CRTC states and everything > > will be run in order. But that also totally kills modern multi-screen > > compositors. Xorg isn't modern, just in case that's not clear :-) > > > > Lucking at the code it seems like you indeed have only a single dm > > state, so yeah global sync is what you'll need as immediate fix, and > > then maybe fix up DM to not be quite so silly ... or at least only do > > the dm state stuff when really needed. > > > > We could also sprinkle the drm_crtc_commit structure around a bit > > (it's the glue that provides the synchronization across commits), but > > since your dm state is global just grabbing all crtc states > > unconditionally as part of that is probably best. > > > > > > While we could duplicate a copy of that code with nothing but the > > > > workqueue changed that isn't something I'd really like to maintain > > > > going forward. > > > > > > I'm not talking about duplicating the code, I'm talking about fixing the > > > helpers. I don't know that code well, but from the outside it sounds > > > like a bug there. > > > > > > And executing work items in the order they are submitted is trivial. > > > > > > Had anybody pinged Daniel or other people familiar with the helper code > > > about it? > > > > Yeah something is wrong here, and the fix looks horrible :-) > > > > Aside, I've also seen some recent discussion flare up about > > drm_atomic_state_get/put used to paper over some other use-after-free, > > but this time related to interrupt handlers. Maybe a few rules about > > that: > > - dont > > - especially not when it's interrupt handlers, because you can't call > > drm_atomic_state_put from interrupt handlers. > > > > Instead have an spin_lock_irq to protect the shared date with your > > interrupt handler, and _copy_ the date over. This is e.g. what > > drm_crtc_arm_vblank_event does. > > Nicholas wrote a patch that attempted to resolve the issue by adding every > CRTC into the commit to use use the stall checks. [1] While this forces > synchronisation on commits, it's kind of a hacky method that may take a > toll on performance. > > Is it possible to have a DRM helper that forces synchronisation on some > commits without having to add every CRTC into the commit? > > Also, is synchronisation really necessary for fast updates in amdgpu? > I'll admit, the idea of eliminating the use-after-free bug by eliminating > the use entirely doesn't seem ideal; but is forcing synchronisation on > these updates that much better? Well clearing the dc_state pointer here and then allocating another one in atomic_commit_tail also looks fishy. The proper fix is probably a lot mo
Re: [PATCH v5 1/5] drm/i915: Add enable/disable flip done and flip done handler
On Mon, Jul 27, 2020 at 2:27 PM Michel Dänzer wrote:
>
> On 2020-07-25 1:26 a.m., Paulo Zanoni wrote:
> > Em seg, 2020-07-20 às 17:01 +0530, Karthik B S escreveu:
> >>
> >> diff --git a/drivers/gpu/drm/i915/i915_irq.c
> >> b/drivers/gpu/drm/i915/i915_irq.c
> >> index 1fa67700d8f4..95953b393941 100644
> >> --- a/drivers/gpu/drm/i915/i915_irq.c
> >> +++ b/drivers/gpu/drm/i915/i915_irq.c
> >> @@ -697,14 +697,24 @@ u32 i915_get_vblank_counter(struct drm_crtc *crtc)
> >> return (((high1 << 8) | low) + (pixel >= vbl_start)) & 0xff;
> >> }
> >>
> >> +static u32 g4x_get_flip_counter(struct drm_crtc *crtc)
> >> +{
> >> +struct drm_i915_private *dev_priv = to_i915(crtc->dev);
> >> +enum pipe pipe = to_intel_crtc(crtc)->pipe;
> >> +
> >> +return I915_READ(PIPE_FLIPCOUNT_G4X(pipe));
> >> +}
> >> +
> >> u32 g4x_get_vblank_counter(struct drm_crtc *crtc)
> >> {
> >> struct drm_i915_private *dev_priv = to_i915(crtc->dev);
> >> enum pipe pipe = to_intel_crtc(crtc)->pipe;
> >>
> >> +if (crtc->state->async_flip)
> >> +return g4x_get_flip_counter(crtc);
> >> +
> >> return I915_READ(PIPE_FRMCOUNT_G4X(pipe));
> >
> > I don't understand the intention behind this, can you please clarify?
> > This goes back to my reply of the cover letter. It seems that here
> > we're going to alternate between two different counters in our vblank
> > count. So if user space alternates between sometimes using async flips
> > and sometimes using normal flip it's going to get some very weird
> > deltas, isn't it? At least this is what I remember from when I played
> > with these registers: FLIPCOUNT drifts away from FRMCOUNT when we start
> > using async flips.
>
> This definitely looks wrong. The counter value returned by the
> get_vblank_counter hook is supposed to increment when a vertical blank
> period occurs; page flips are not supposed to affect this in any way.
Also you just flat out can't access crtc->state from interrupt
context. Anything you need in there needs to be protected by the right
irq-type spin_lock, updates correctly synchronized against both the
interrupt handler and atomic updates, and data copied over, not
pointers. Otherwise just crash&burn.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/9] clk: qcom: gcc-sdm660: Add missing modem reset
Quoting Konrad Dybcio (2020-07-26 04:11:58) > This will be required in order to support the > modem upstream. > > Signed-off-by: Konrad Dybcio > --- Applied to clk-next ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 8/9] clk: qcom: gcc-sdm660: Fix up gcc_mss_mnoc_bimc_axi_clk
Quoting Konrad Dybcio (2020-07-26 04:12:05) > Add missing halt_check, hwcg_reg and hwcg_bit properties. > These were likely omitted when porting the driver upstream. > > Signed-off-by: Konrad Dybcio > --- Applied to clk-next ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 4/4] xen: add helpers to allocate unpopulated memory
To be used in order to create foreign mappings. This is based on the
ZONE_DEVICE facility which is used by persistent memory devices in
order to create struct pages and kernel virtual mappings for the IOMEM
areas of such devices. Note that on kernels without support for
ZONE_DEVICE Xen will fallback to use ballooned pages in order to
create foreign mappings.
The newly added helpers use the same parameters as the existing
{alloc/free}_xenballooned_pages functions, which allows for in-place
replacement of the callers. Once a memory region has been added to be
used as scratch mapping space it will no longer be released, and pages
returned are kept in a linked list. This allows to have a buffer of
pages and prevents resorting to frequent additions and removals of
regions.
If enabled (because ZONE_DEVICE is supported) the usage of the new
functionality untangles Xen balloon and RAM hotplug from the usage of
unpopulated physical memory ranges to map foreign pages, which is the
correct thing to do in order to avoid mappings of foreign pages depend
on memory hotplug.
Signed-off-by: Roger Pau Monné
---
I've not added a new memory_type type and just used
MEMORY_DEVICE_DEVDAX which seems to be what we want for such memory
regions. I'm unsure whether abusing this type is fine, or if I should
instead add a specific type, maybe MEMORY_DEVICE_GENERIC? I don't
think we should be using a specific Xen type at all.
---
Cc: Oleksandr Andrushchenko
Cc: David Airlie
Cc: Daniel Vetter
Cc: Boris Ostrovsky
Cc: Juergen Gross
Cc: Stefano Stabellini
Cc: Dan Carpenter
Cc: Roger Pau Monne
Cc: Wei Liu
Cc: Yan Yankovskyi
Cc: dri-devel@lists.freedesktop.org
Cc: xen-de...@lists.xenproject.org
Cc: linux...@kvack.org
Cc: David Hildenbrand
Cc: Michal Hocko
Cc: Dan Williams
---
Changes since v2:
- Drop BUILD_BUG_ON regarding PVMMU page sizes.
- Use a SPDX license identifier.
- Call fill with only the minimum required number of pages.
- Include xen.h header in xen_drm_front_gem.c.
- Use less generic function names.
- Exit early from the init function if not a PV guest.
- Don't use all caps for region name.
---
drivers/gpu/drm/xen/xen_drm_front_gem.c | 9 +-
drivers/xen/Makefile| 1 +
drivers/xen/balloon.c | 4 +-
drivers/xen/grant-table.c | 4 +-
drivers/xen/privcmd.c | 4 +-
drivers/xen/unpopulated-alloc.c | 185
drivers/xen/xenbus/xenbus_client.c | 6 +-
drivers/xen/xlate_mmu.c | 4 +-
include/xen/xen.h | 9 ++
9 files changed, 211 insertions(+), 15 deletions(-)
create mode 100644 drivers/xen/unpopulated-alloc.c
diff --git a/drivers/gpu/drm/xen/xen_drm_front_gem.c
b/drivers/gpu/drm/xen/xen_drm_front_gem.c
index f0b85e094111..270e1bd3e4da 100644
--- a/drivers/gpu/drm/xen/xen_drm_front_gem.c
+++ b/drivers/gpu/drm/xen/xen_drm_front_gem.c
@@ -18,6 +18,7 @@
#include
#include
+#include
#include "xen_drm_front.h"
#include "xen_drm_front_gem.h"
@@ -99,8 +100,8 @@ static struct xen_gem_object *gem_create(struct drm_device
*dev, size_t size)
* allocate ballooned pages which will be used to map
* grant references provided by the backend
*/
- ret = alloc_xenballooned_pages(xen_obj->num_pages,
- xen_obj->pages);
+ ret = xen_alloc_unpopulated_pages(xen_obj->num_pages,
+ xen_obj->pages);
if (ret < 0) {
DRM_ERROR("Cannot allocate %zu ballooned pages: %d\n",
xen_obj->num_pages, ret);
@@ -152,8 +153,8 @@ void xen_drm_front_gem_free_object_unlocked(struct
drm_gem_object *gem_obj)
} else {
if (xen_obj->pages) {
if (xen_obj->be_alloc) {
- free_xenballooned_pages(xen_obj->num_pages,
- xen_obj->pages);
+ xen_free_unpopulated_pages(xen_obj->num_pages,
+ xen_obj->pages);
gem_free_pages_array(xen_obj);
} else {
drm_gem_put_pages(&xen_obj->base,
diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index 0d322f3d90cd..788a5d9c8ef0 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -42,3 +42,4 @@ xen-gntdev-$(CONFIG_XEN_GNTDEV_DMABUF)+=
gntdev-dmabuf.o
xen-gntalloc-y := gntalloc.o
xen-privcmd-y := privcmd.o privcmd-buf.o
obj-$(CONFIG_XEN_FRONT_PGDIR_SHBUF)+= xen-front-pgdir-shbuf.o
+obj-$(CONFIG_ZONE_DEVICE) += unpopulated-alloc.o
diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
index b1d8b028bf80..815ef10eb2ff 100644
--- a/dr
Re: divide error in fbcon_switch
syzbot suspects this issue was fixed by commit: commit ce684552a266cb1c7cc2f7e623f38567adec6653 Author: Tetsuo Handa Date: Sun Jul 12 11:10:12 2020 + vt: Reject zero-sized screen buffer size. bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=155549c490 start commit: 76bb8b05 Merge tag 'kbuild-v5.5' of git://git.kernel.org/p.. git tree: upstream kernel config: https://syzkaller.appspot.com/x/.config?x=dd226651cb0f364b dashboard link: https://syzkaller.appspot.com/bug?extid=13013adc4a234406c29e syz repro: https://syzkaller.appspot.com/x/repro.syz?x=17d69aeae0 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=13fdcc2ae0 If the result looks correct, please mark the issue as fixed by replying with: #syz fix: vt: Reject zero-sized screen buffer size. For information about bisection process see: https://goo.gl/tpsmEJ#bisection ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/6] dt-bindings: display: Document NewVision NV3052C DT node
Add documentation for the Device Tree node for LCD panels based on the
NewVision NV3052C controller.
Signed-off-by: Paul Cercueil
---
.../display/panel/newvision,nv3052c.yaml | 69 +++
1 file changed, 69 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/newvision,nv3052c.yaml
diff --git
a/Documentation/devicetree/bindings/display/panel/newvision,nv3052c.yaml
b/Documentation/devicetree/bindings/display/panel/newvision,nv3052c.yaml
new file mode 100644
index ..751a28800fc2
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/newvision,nv3052c.yaml
@@ -0,0 +1,69 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/newvision,nv3052c.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NewVision NV3052C TFT LCD panel driver with SPI control bus
+
+maintainers:
+ - Paul Cercueil
+
+description: |
+ This is a driver for 320x240 TFT panels, accepting a variety of input
+ streams that get adapted and scaled to the panel. The panel output has
+ 960 TFT source driver pins and 240 TFT gate driver pins, VCOM, VCOML and
+ VCOMH outputs.
+
+ The panel must obey the rules for a SPI slave device as specified in
+ spi/spi-controller.yaml
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+items:
+ - enum:
+- leadtek,ltk035c5444t-spi
+
+ - const: newvision,nv3052c
+
+ reg:
+maxItems: 1
+
+ reset-gpios: true
+ port: true
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+#include
+spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ display@0 {
+compatible = "leadtek,ltk035c5444t-spi", "newvision,nv3052c";
+reg = <0>;
+
+spi-max-frequency = <1500>;
+spi-3wire;
+reset-gpios = <&gpe 2 GPIO_ACTIVE_LOW>;
+backlight = <&backlight>;
+power-supply = <&vcc>;
+
+port {
+ panel_input: endpoint {
+ remote-endpoint = <&panel_output>;
+ };
+};
+ };
+};
+
+...
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
