[PATCH v2 00/37] drm: Deduplicate fb format information (v2)
On Fri, Nov 18, 2016 at 09:52:36PM +0200, ville.syrjala at linux.intel.com
wrote:
> From: Ville Syrjälä
>
> Second installment of my effort to remove the duplicated
> depth/bpp/pixel_format from drm_framebuffer and just use
> struct drm_format_info instead.
>
> I tried to address all of the review feedback, and collect
> up all the r-bs I already got. Thanks for the review, guys.
>
> Changes since the last version are roughly:
> * drm_framebuffer_init() now fails if the fb isn't properly prepared
> * Applied mode cocciry all over to use fb->format more extensively
> * Dropped a few i915 specific patches that were taken care of the
> previous item
> * Took up Laurent's idea that we can just compare the fb->format
> pointers instead of comparing the fb->format->format values
> * Added a new .get_format_info() hooks for drivers to provide custom
> format information + an quick example patch how we'd hook it up
> for i915 render compression support
>
> Link to the previous version:
> https://lists.freedesktop.org/archives/dri-devel/2016-November/124135.html
>
> Entire series is available here:
> git://github.com/vsyrjala/linux.git fb_format_dedup_2
>
> Cc: Alex Deucher
> Cc: Alexey Brodkin
> Cc: Ben Skeggs
> Cc: Ben Widawsky
> Cc: Brian Starkey
> Cc: "Christian König"
> Cc: Dave Airlie
> Cc: Gerd Hoffmann
> Cc: intel-gfx at lists.freedesktop.org
> Cc: Laurent Pinchart
> Cc: linux-graphics-maintainer at vmware.com
> Cc: Liviu Dudau
> Cc: Mali DP Maintainers
> Cc: Patrik Jakobsson
> Cc: Paulo Zanoni
> Cc: Sinclair Yeh
> Cc: Thomas Hellstrom
>
> Ville Syrjälä (37):
> drm/i915: Add local 'fb' variables
> drm/radeon: Add local 'fb' variables
> drm/radeon: Use DIV_ROUND_UP()
> drm/mgag200: Add local 'fb' variable
> drm/ast: Add local 'fb' variables
> drm/gma500: Add some local 'fb' variables
> drm/cirrus: Add some local 'fb' variables
> drm/arcpgu: Add local 'fb' variables
> drm/arm: Add local 'fb' variables
> drm/nouveau: Fix crtc->primary->fb vs. drm_fb fail
> drm/nouveau: Add local 'fb' variables
I've pushed up to here to drm-misc-next. Thanks for the reviews.
I re-ran spatch to regenerate some of the later patches as there had
been a bit of churn in the code. I've reposted the changed patches,
and if no one screams I'll be pushing the rest tomorrowish.
> drm/vmwgfx: Populate fb->dev before drm_framebuffer_init()
> drm: Pass 'dev' to drm_helper_mode_fill_fb_struct()
> drm/vmwgfx: Populate fb->pixel_format
> drm/qxl: Call drm_helper_mode_fill_fb_struct() before
> drm_framebuffer_init()
> drm/virtio: Call drm_helper_mode_fill_fb_struct() before
> drm_framebuffer_init()
> drm/i915: Set fb->dev early on for inherited fbs
> drm: Populate fb->dev from drm_helper_mode_fill_fb_struct()
> drm: Store a pointer to drm_format_info under drm_framebuffer
> drm/vmwgfx: Populate fb->format correctly
> drm/i915: Populate fb->format early for inherited fbs
> drm: Reject fbs w/o format info in drm_framebuffer_init()
> drm: Replace drm_format_num_planes() with fb->format->num_planes
> drm/i915: Eliminate the ugly 'fb?:' constructs from the ilk/skl wm
> code
> drm: Replace drm_format_plane_cpp() with fb->format->cpp[]
> drm/fb_cma_helper: Replace drm_format_info() with fb->format
> drm/nouveau: Use fb->format rather than drm_format_info()
> drm/i915: Store a pointer to the pixel format info for fbc
> drm: Add drm_framebuffer_plane_{width,height}()
> drm/i915: Use drm_framebuffer_plane_{width,height}() where possible
> drm: Nuke fb->depth
> drm: Nuke fb->bits_per_pixel
> drm: Nuke fb->pixel_format
> drm: Replace 'format->format' comparisons to just 'format' comparisons
> drm: Eliminate the useless "non-RGB fb" debug message
> drm: Add mode_config .get_format_info() hook
> drm/i915: Implement .get_format_info() hook for CCS
>
> drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 2 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c | 4 +-
> drivers/gpu/drm/amd/amdgpu/dce_v10_0.c | 6 +-
> drivers/gpu/drm/amd/amdgpu/dce_v11_0.c | 6 +-
> drivers/gpu/drm/amd/amdgpu/dce_v6_0.c | 6 +-
> drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 6 +-
> drivers/gpu/drm/arc/arcpgu_crtc.c | 3 +-
> drivers/gpu/drm/arm/hdlcd_crtc.c| 18 ++--
> drivers/gpu/drm/arm/malidp_planes.c | 10 +--
> drivers/gpu/drm/armada/armada_crtc.c| 6 +-
> drivers/gpu/drm/armada/armada_fb.c | 2 +-
> drivers/gpu/drm/armada/armada_fbdev.c | 5 +-
> drivers/gpu/drm/armada/armada_overlay.c | 6 +-
> drivers/gpu/drm/ast/ast_fb.c| 4 +-
> drivers/gpu/drm/ast/ast_main.c | 2 +-
> drivers/gpu/drm/ast/ast_mode.c | 16 ++--
> drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_layer.c | 2 +-
> drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 22 ++---
> drivers/gpu/drm
[PATCH] drm: rcar-du: enable VSPDs on R8A7791
We're going to use R8A7791 VSPDs to control DU, so set the corresponding
flag.
Signed-off-by: Sergei Shtylyov
---
The patch is against David Airlie's 'linux.git' repo's 'drm-next' branch.
drivers/gpu/drm/rcar-du/rcar_du_drv.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Index: linux/drivers/gpu/drm/rcar-du/rcar_du_drv.c
===
--- linux.orig/drivers/gpu/drm/rcar-du/rcar_du_drv.c
+++ linux/drivers/gpu/drm/rcar-du/rcar_du_drv.c
@@ -90,7 +90,8 @@ static const struct rcar_du_device_info
static const struct rcar_du_device_info rcar_du_r8a7791_info = {
.gen = 2,
.features = RCAR_DU_FEATURE_CRTC_IRQ_CLOCK
- | RCAR_DU_FEATURE_EXT_CTRL_REGS,
+ | RCAR_DU_FEATURE_EXT_CTRL_REGS
+ | RCAR_DU_FEATURE_VSP1_SOURCE,
.num_crtcs = 2,
.routes = {
/* R8A779[13] has one RGB output, one LVDS output and one
[PATCH 12/23] drm: omapdrm: plane: update fifo size on atomic update
Hi Sebastian, (CC'ing Peter Ujfalusi) On Wednesday 14 Dec 2016 15:03:08 Sebastian Reichel wrote: > On Wed, Dec 14, 2016 at 11:14:32AM +0200, Tomi Valkeinen wrote: > > On 14/12/16 11:10, Laurent Pinchart wrote: > >> On Wednesday 14 Dec 2016 10:43:18 Tomi Valkeinen wrote: > >>> On 13/12/16 19:35, Laurent Pinchart wrote: > On Tuesday 08 Mar 2016 17:39:44 Sebastian Reichel wrote: > > This is a workaround for a hardware bug occuring > > on OMAP3 with manually updated panels. > > Could you please explain what the bug is and how the workaround > operates ? Do you have a reference to an errata document ? > > FWIW I don't know anything about this bug. I just hit it while > getting omapdrm working on n950 and ported this over from omapfb. I wonder if it's a bug or an expected behaviour. In any case, looking at the FIFO thresholds computation function it's quite clear that we need to recompute and set the values when the panel mode changes. Maybe you should explain this in the commit message. > >>> I don't think I ever found out exactly why the problem happens. But on > >>> OMAP3 DSI, the fifo thresholds had to be tuned slightly, otherwise > >>> DISPC would stop. dispc_ovl_compute_fifo_thresholds() does that tuning > >>> if "manual_update" parameter is set on OMAP3. > >> > >> I've had a look at dispc_ovl_compute_fifo_thresholds() and the patch > >> makes sense to me. If Sebastian could address the small issues I pointed > >> out, we could then merge this. Alternatively I can take care of > >> addressing them. > > > > It's only needed with the rest of the DSI manual update series, so I'd > > rather keep it as part of that series. > > To be honest I haven't worked on this for some time. From some > comments on the patchset I think the biggest issue is, that omapdrm > does not use generic panel drivers and cannot easily use the > mipi_dsi_driver_register. I simply did not have enough time to > implement such a huge change. I'll probably give it a go at some point, but it will take time. > I guess a first step is Peter Ujfalusi's series: > https://lkml.org/lkml/2016/9/1/267 Peter, do you plan to respin that patch series ? -- Regards, Laurent Pinchart
[PATCH 00/26] drm/omap: Convert to use videomode from omap_video_timings
Hi Peter, On Thursday 01 Sep 2016 14:22:54 Peter Ujfalusi wrote: > Hi, > > The following series will convert the omapdrm stack to use the generic > videmode instead of the private omap_video_timings struct for the panel > information. > > Since we have several panels under omapdrm/displays/ where the data drive > edge is set to be different then the sync drive edge, the first three patch > will add support to select the sync drive edge via DT. > I was not able to locate the datasheet for all the panels and because the > different edge was used in omapdrm and omapfb for a long time without > complains from users - and they were written this way - I think it is a > valid that we can have panels requiring different edge for data and sync to > be driven. That's very peculiar. Have you been able to locate at least one panel datasheet that documents this requirement ? > The rest of the patches are most mechanical ones. I have decided to split it > up to small chunks and did one change at the time to finally remove the > omap_video_timings from omapdrm. > > > CC: Rob Herring > CC: Mark Rutland > CC: devicetree at vger.kernel.org > > Regards, > Peter > --- > Peter Ujfalusi (26): > dt-bindings: display: display-timing: Add property to configure sync > drive edge > video: display_timing: Add flags to select the edge when the sync is > driven > video: of: display_timing: Add support for syncclk-active property > drm/omap: omap_display_timings: rename x_res to hactive > drm/omap: omap_display_timings: rename y_res to vactive > drm/omap: omap_display_timings: rename hsw to hsync_len > drm/omap: omap_display_timings: rename hfp to hfront_porch > drm/omap: omap_display_timings: rename hbp to hback_porch > drm/omap: omap_display_timings: rename vsw to vsync_len > drm/omap: omap_display_timings: rename vfp to vfront_porch > drm/omap: omap_display_timings: rename vbp to vback_porch > drm/omap: HDMI5: Use pointer to cfg->v_fc_config.timings in > hdmi_core_video_config > drm/omap: omap_display_timings: Use display_flags for interlace mode > drm/omap: dispc: Simplify _dispc_mgr_set_lcd_timings() parameters > drm/omap: omap_display_timings: Use display_flags for h/vsync level > drm/omap: omap_display_timings: Use display_flags for DE level > drm/omap: omap_display_timings: Use display_flags for double_pixel > mode > drm/omap: omap_display_timings: Use display_flags for pixel data edge > drm/omap: omap_display_timings: Use display_flags for sync edge > drm/omap: Change the types of struct omap_video_timings members > drm/omap: Replace struct omap_video_timings with videomode > drm/omap: Use consistent name for struct videomode > drm/omap: panel-tpo-td043mtea1: Add note for incorrect sync drive edge > drm/omap: panel-tpo-td028ttec1: Add note for incorrect sync drive edge > drm/omap: panel-sharp-ls037v7dw01: Add note for incorrect data drive > edge > drm/omap: panel-lgphilips-lb035q02: Add note for incorrect data drive > edge and DE level > > .../bindings/display/panel/display-timing.txt | 6 + > .../gpu/drm/omapdrm/displays/connector-analog-tv.c | 47 ++--- > drivers/gpu/drm/omapdrm/displays/connector-dvi.c | 50 +++-- > drivers/gpu/drm/omapdrm/displays/connector-hdmi.c | 49 +++-- > drivers/gpu/drm/omapdrm/displays/encoder-opa362.c | 20 +- > drivers/gpu/drm/omapdrm/displays/encoder-tfp410.c | 31 ++- > .../gpu/drm/omapdrm/displays/encoder-tpd12s015.c | 20 +- > drivers/gpu/drm/omapdrm/displays/panel-dpi.c | 30 ++- > drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c| 25 ++- > .../omapdrm/displays/panel-lgphilips-lb035q02.c| 59 +++--- > .../drm/omapdrm/displays/panel-nec-nl8048hl11.c| 52 +++-- > .../drm/omapdrm/displays/panel-sharp-ls037v7dw01.c | 58 +++--- > .../drm/omapdrm/displays/panel-sony-acx565akm.c| 53 +++-- > .../drm/omapdrm/displays/panel-tpo-td028ttec1.c| 57 +++--- > .../drm/omapdrm/displays/panel-tpo-td043mtea1.c| 54 ++--- > drivers/gpu/drm/omapdrm/dss/dispc.c| 222 -- > drivers/gpu/drm/omapdrm/dss/display.c | 78 +--- > drivers/gpu/drm/omapdrm/dss/dpi.c | 40 ++-- > drivers/gpu/drm/omapdrm/dss/dsi.c | 156 --- > drivers/gpu/drm/omapdrm/dss/dss.h | 5 +- > drivers/gpu/drm/omapdrm/dss/hdmi.h | 8 +- > drivers/gpu/drm/omapdrm/dss/hdmi4.c| 31 +-- > drivers/gpu/drm/omapdrm/dss/hdmi4_core.c | 8 +- > drivers/gpu/drm/omapdrm/dss/hdmi5.c| 31 +-- > drivers/gpu/drm/omapdrm/dss/hdmi5_core.c | 85 > drivers/gpu/drm/omapdrm/dss/hdmi_wp.c | 73 --- > drivers/gpu/drm/omapdrm/dss/omapdss.h | 98 +++-- > drivers/gpu/drm/omapdrm/dss/output.c | 5 +- > drivers/gpu/drm/omapdrm/dss/rfbi.c | 49 +++-- > drivers/gpu/drm/oma
[PATCH v3 33/37] drm: Nuke fb->pixel_format
From: Ville Syrjälä
Replace uses of fb->pixel_format with fb->format->format.
Less duplicated information is a good thing.
Note that coccinelle failed to eliminate the
"/* fourcc format */" comment from drm_framebuffer.h, so I had
to do that part manually.
@@
struct drm_framebuffer *FB;
expression E;
@@
drm_helper_mode_fill_fb_struct(...) {
...
- FB->pixel_format = E;
...
}
@@
struct drm_framebuffer *FB;
expression E;
@@
i9xx_get_initial_plane_config(...) {
...
- FB->pixel_format = E;
...
}
@@
struct drm_framebuffer *FB;
expression E;
@@
ironlake_get_initial_plane_config(...) {
...
- FB->pixel_format = E;
...
}
@@
struct drm_framebuffer *FB;
expression E;
@@
skylake_get_initial_plane_config(...) {
...
- FB->pixel_format = E;
...
}
@@
struct drm_framebuffer *a;
struct drm_framebuffer b;
@@
(
- a->pixel_format
+ a->format->format
|
- b.pixel_format
+ b.format->format
)
@@
struct drm_plane_state *a;
struct drm_plane_state b;
@@
(
- a->fb->pixel_format
+ a->fb->format->format
|
- b.fb->pixel_format
+ b.fb->format->format
)
@@
struct drm_crtc *CRTC;
@@
(
- CRTC->primary->fb->pixel_format
+ CRTC->primary->fb->format->format
|
- CRTC->primary->state->fb->pixel_format
+ CRTC->primary->state->fb->format->format
)
@@
struct drm_mode_set *set;
@@
(
- set->fb->pixel_format
+ set->fb->format->format
|
- set->crtc->primary->fb->pixel_format
+ set->crtc->primary->fb->format->format
)
@@
@@
struct drm_framebuffer {
...
-uint32_t pixel_format;
...
};
v2: Fix commit message (Laurent)
Rebase due to earlier removal of many fb->pixel_format uses,
including the 'fb->format = drm_format_info(fb->format->format);'
snafu
v3: Adjusted the semantic patch a bit and regenerated due to code
changes
Cc: Laurent Pinchart
Signed-off-by: Ville Syrjälä
Reviewed-by: Alex Deucher (v1)
Reviewed-by: Laurent Pinchart
---
drivers/gpu/drm/amd/amdgpu/dce_v10_0.c | 4 +--
drivers/gpu/drm/amd/amdgpu/dce_v11_0.c | 4 +--
drivers/gpu/drm/amd/amdgpu/dce_v6_0.c | 4 +--
drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 4 +--
drivers/gpu/drm/arc/arcpgu_crtc.c | 2 +-
drivers/gpu/drm/arm/hdlcd_crtc.c| 2 +-
drivers/gpu/drm/arm/malidp_planes.c | 8 +++---
drivers/gpu/drm/armada/armada_crtc.c| 2 +-
drivers/gpu/drm/armada/armada_overlay.c | 2 +-
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 18 ++---
drivers/gpu/drm/drm_atomic.c| 6 ++---
drivers/gpu/drm/drm_crtc.c | 4 +--
drivers/gpu/drm/drm_crtc_helper.c | 4 +--
drivers/gpu/drm/drm_fb_cma_helper.c | 2 +-
drivers/gpu/drm/drm_modeset_helper.c| 1 -
drivers/gpu/drm/drm_plane.c | 6 ++---
drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 2 +-
drivers/gpu/drm/exynos/exynos7_drm_decon.c | 2 +-
drivers/gpu/drm/exynos/exynos_drm_fimd.c| 2 +-
drivers/gpu/drm/exynos/exynos_mixer.c | 8 +++---
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c | 4 +--
drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 6 ++---
drivers/gpu/drm/i915/i915_debugfs.c | 3 ++-
drivers/gpu/drm/i915/intel_atomic_plane.c | 4 +--
drivers/gpu/drm/i915/intel_display.c| 33 +++-
drivers/gpu/drm/i915/intel_fbdev.c | 2 +-
drivers/gpu/drm/i915/intel_overlay.c| 2 +-
drivers/gpu/drm/i915/intel_pm.c | 10
drivers/gpu/drm/i915/intel_sprite.c | 12 -
drivers/gpu/drm/imx/ipuv3-plane.c | 34 -
drivers/gpu/drm/mediatek/mtk_drm_plane.c| 2 +-
drivers/gpu/drm/meson/meson_plane.c | 2 +-
drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c | 2 +-
drivers/gpu/drm/msm/msm_fb.c| 2 +-
drivers/gpu/drm/mxsfb/mxsfb_crtc.c | 2 +-
drivers/gpu/drm/nouveau/dispnv04/overlay.c | 8 +++---
drivers/gpu/drm/nouveau/nv50_display.c | 4 +--
drivers/gpu/drm/omapdrm/omap_fb.c | 2 +-
drivers/gpu/drm/radeon/atombios_crtc.c | 8 +++---
drivers/gpu/drm/rcar-du/rcar_du_plane.c | 4 +--
drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 4 +--
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 18 ++---
drivers/gpu/drm/shmobile/shmob_drm_crtc.c | 6 ++---
drivers/gpu/drm/shmobile/shmob_drm_plane.c | 4 +--
drivers/gpu/drm/sti/sti_gdp.c | 8 +++---
drivers/gpu/drm/sti/sti_hqvdp.c | 2 +-
drivers/gpu/drm/sun4i/sun4i_backend.c | 3 ++-
drivers/gpu/drm/tegra/dc.c | 2 +-
drivers/gpu/drm/tilcdc/tilcdc_crtc.c| 2 +-
drivers/gpu/drm/tilcdc/tilcdc_plane.c | 2 +-
drivers/gpu/drm/vc4/vc4_plane.c
[PATCH v3 32/37] drm: Nuke fb->bits_per_pixel
From: Ville Syrjälä
Replace uses of fb->bits_per_pixel with fb->format->cpp[0]*8.
Less duplicated information is a good thing.
Note that I didn't put parens around the cpp*8 in the below cocci script,
on account of not wanting spurious parens all over the place. Instead I
did the unsafe way, and tried to look over the entire diff to spot if
any dangerous expressions were produced. I didn't see any.
There are some cases where previously the code did X*bpp/8, so the
division happened after the multiplication. Those are now just X*cpp
so the division effectively happens before the multiplication,
but that is perfectly fine since bpp is always a multiple of 8.
@@
struct drm_framebuffer *FB;
expression E;
@@
drm_helper_mode_fill_fb_struct(...) {
...
- FB->bits_per_pixel = E;
...
}
@@
struct drm_framebuffer *FB;
expression E;
@@
i9xx_get_initial_plane_config(...) {
...
- FB->bits_per_pixel = E;
...
}
@@
struct drm_framebuffer *FB;
expression E;
@@
ironlake_get_initial_plane_config(...) {
...
- FB->bits_per_pixel = E;
...
}
@@
struct drm_framebuffer *FB;
expression E;
@@
skylake_get_initial_plane_config(...) {
...
- FB->bits_per_pixel = E;
...
}
@@
struct drm_framebuffer FB;
expression E;
@@
(
- E * FB.bits_per_pixel / 8
+ E * FB.format->cpp[0]
|
- FB.bits_per_pixel / 8
+ FB.format->cpp[0]
|
- E * FB.bits_per_pixel >> 3
+ E * FB.format->cpp[0]
|
- FB.bits_per_pixel >> 3
+ FB.format->cpp[0]
|
- (FB.bits_per_pixel + 7) / 8
+ FB.format->cpp[0]
|
- FB.bits_per_pixel
+ FB.format->cpp[0] * 8
|
- FB.format->cpp[0] * 8 != 8
+ FB.format->cpp[0] != 1
)
@@
struct drm_framebuffer *FB;
expression E;
@@
(
- E * FB->bits_per_pixel / 8
+ E * FB->format->cpp[0]
|
- FB->bits_per_pixel / 8
+ FB->format->cpp[0]
|
- E * FB->bits_per_pixel >> 3
+ E * FB->format->cpp[0]
|
- FB->bits_per_pixel >> 3
+ FB->format->cpp[0]
|
- (FB->bits_per_pixel + 7) / 8
+ FB->format->cpp[0]
|
- FB->bits_per_pixel
+ FB->format->cpp[0] * 8
|
- FB->format->cpp[0] * 8 != 8
+ FB->format->cpp[0] != 1
)
@@
struct drm_plane_state *state;
expression E;
@@
(
- E * state->fb->bits_per_pixel / 8
+ E * state->fb->format->cpp[0]
|
- state->fb->bits_per_pixel / 8
+ state->fb->format->cpp[0]
|
- E * state->fb->bits_per_pixel >> 3
+ E * state->fb->format->cpp[0]
|
- state->fb->bits_per_pixel >> 3
+ state->fb->format->cpp[0]
|
- (state->fb->bits_per_pixel + 7) / 8
+ state->fb->format->cpp[0]
|
- state->fb->bits_per_pixel
+ state->fb->format->cpp[0] * 8
|
- state->fb->format->cpp[0] * 8 != 8
+ state->fb->format->cpp[0] != 1
)
@@
@@
- (8 * 8)
+ 8 * 8
@@
struct drm_framebuffer FB;
@@
- (FB.format->cpp[0])
+ FB.format->cpp[0]
@@
struct drm_framebuffer *FB;
@@
- (FB->format->cpp[0])
+ FB->format->cpp[0]
@@
@@
struct drm_framebuffer {
...
-int bits_per_pixel;
...
};
v2: Clean up the 'cpp*8 != 8' and '(8 * 8)' cases (Laurent)
v3: Adjusted the semantic patch a bit and regenerated due to code
changes
Signed-off-by: Ville Syrjälä
Reviewed-by: Laurent Pinchart
Reviewed-by: Alex Deucher (v1)
---
drivers/gpu/drm/amd/amdgpu/dce_v10_0.c | 2 +-
drivers/gpu/drm/amd/amdgpu/dce_v11_0.c | 2 +-
drivers/gpu/drm/amd/amdgpu/dce_v6_0.c | 2 +-
drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 2 +-
drivers/gpu/drm/armada/armada_crtc.c | 2 +-
drivers/gpu/drm/armada/armada_fbdev.c | 2 +-
drivers/gpu/drm/ast/ast_fb.c | 2 +-
drivers/gpu/drm/ast/ast_mode.c | 9 +
drivers/gpu/drm/cirrus/cirrus_fbdev.c | 2 +-
drivers/gpu/drm/cirrus/cirrus_mode.c | 2 +-
drivers/gpu/drm/drm_fb_helper.c| 8
drivers/gpu/drm/drm_framebuffer.c | 2 +-
drivers/gpu/drm/drm_modeset_helper.c | 3 ---
drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 4 ++--
drivers/gpu/drm/exynos/exynos7_drm_decon.c | 6 +++---
drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 4 ++--
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 2 +-
drivers/gpu/drm/exynos/exynos_mixer.c | 4 ++--
drivers/gpu/drm/gma500/framebuffer.c | 2 +-
drivers/gpu/drm/gma500/gma_display.c | 4 ++--
drivers/gpu/drm/gma500/mdfld_intel_display.c | 6 +++---
drivers/gpu/drm/gma500/oaktrail_crtc.c | 4 ++--
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c | 6 +++---
drivers/gpu/drm/i915/i915_debugfs.c| 4 ++--
drivers/gpu/drm/i915/intel_display.c | 11 ---
drivers/gpu/drm/i915/intel_fbdev.c | 6 +++---
drivers/gpu/drm/mgag200/mgag200_fb.c | 2 +-
drivers/gpu/drm/mgag200/mgag200_mode.c | 16
drivers/gpu/drm/nouveau/dispnv04/crtc.c| 4 ++--
drivers/gpu/drm/nouveau/nouveau_display.c | 2 +-
drivers/gpu/drm/qxl/qxl_draw.c | 2 +-
drivers/gpu/drm/radeon/atombios_crtc.c | 11 ++-
drivers
[PATCH v2 31/37] drm: Nuke fb->depth
From: Ville Syrjälä
Replace uses of fb->depth with fb->format->depth. Less duplicate
information is a good thing.
@@
struct drm_framebuffer *fb;
expression E;
@@
drm_helper_mode_fill_fb_struct(...) {
...
- fb->depth = E;
...
}
@@
struct nouveau_framebuffer *fb;
@@
- fb->base.depth
+ fb->base.format->depth
@@
struct drm_framebuffer fb;
@@
- fb.depth
+ fb.format->depth
@@
struct drm_framebuffer *fb;
@@
- fb->depth
+ fb->format->depth
@@
struct drm_framebuffer fb;
@@
- (fb.format->depth)
+ fb.format->depth
@@
struct drm_framebuffer *fb;
@@
- (fb->format->depth)
+ fb->format->depth
@@
@@
struct drm_framebuffer {
...
-unsigned int depth;
...
};
v2: Drop the vmw stuff (Daniel)
Rerun spatch due to code changes
Signed-off-by: Ville Syrjälä
Reviewed-by: Laurent Pinchart
Reviewed-by: Alex Deucher
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c| 4 ++--
drivers/gpu/drm/armada/armada_fbdev.c | 3 ++-
drivers/gpu/drm/ast/ast_fb.c | 2 +-
drivers/gpu/drm/bochs/bochs_fbdev.c | 2 +-
drivers/gpu/drm/cirrus/cirrus_fbdev.c | 4 ++--
drivers/gpu/drm/drm_fb_cma_helper.c | 2 +-
drivers/gpu/drm/drm_fb_helper.c | 2 +-
drivers/gpu/drm/drm_framebuffer.c | 2 +-
drivers/gpu/drm/drm_modeset_helper.c | 2 --
drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 2 +-
drivers/gpu/drm/gma500/accel_2d.c | 2 +-
drivers/gpu/drm/gma500/framebuffer.c | 2 +-
drivers/gpu/drm/gma500/gma_display.c | 2 +-
drivers/gpu/drm/gma500/mdfld_intel_display.c | 2 +-
drivers/gpu/drm/gma500/oaktrail_crtc.c| 2 +-
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c | 2 +-
drivers/gpu/drm/i915/i915_debugfs.c | 4 ++--
drivers/gpu/drm/i915/intel_fbdev.c| 2 +-
drivers/gpu/drm/mgag200/mgag200_fb.c | 2 +-
drivers/gpu/drm/mgag200/mgag200_mode.c| 6 +++---
drivers/gpu/drm/msm/msm_fbdev.c | 2 +-
drivers/gpu/drm/nouveau/dispnv04/crtc.c | 12 ++--
drivers/gpu/drm/nouveau/dispnv04/dfp.c| 2 +-
drivers/gpu/drm/nouveau/nouveau_fbcon.c | 3 ++-
drivers/gpu/drm/omapdrm/omap_fbdev.c | 2 +-
drivers/gpu/drm/qxl/qxl_fb.c | 5 +++--
drivers/gpu/drm/radeon/radeon_fb.c| 4 ++--
drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c | 5 +++--
drivers/gpu/drm/tegra/drm.c | 3 ++-
drivers/gpu/drm/tegra/fb.c| 2 +-
drivers/gpu/drm/udl/udl_fb.c | 2 +-
drivers/gpu/drm/virtio/virtgpu_fb.c | 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_fb.c| 5 +++--
drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c | 5 +++--
drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 2 +-
include/drm/drm_framebuffer.h | 6 --
36 files changed, 56 insertions(+), 57 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
index 24629bec181a..838943d0962e 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
@@ -245,7 +245,7 @@ static int amdgpufb_create(struct drm_fb_helper *helper,
strcpy(info->fix.id, "amdgpudrmfb");
- drm_fb_helper_fill_fix(info, fb->pitches[0], fb->depth);
+ drm_fb_helper_fill_fix(info, fb->pitches[0], fb->format->depth);
info->flags = FBINFO_DEFAULT | FBINFO_CAN_FORCE_OUTPUT;
info->fbops = &amdgpufb_ops;
@@ -272,7 +272,7 @@ static int amdgpufb_create(struct drm_fb_helper *helper,
DRM_INFO("fb mappable at 0x%lX\n", info->fix.smem_start);
DRM_INFO("vram apper at 0x%lX\n", (unsigned long)adev->mc.aper_base);
DRM_INFO("size %lu\n", (unsigned long)amdgpu_bo_size(abo));
- DRM_INFO("fb depth is %d\n", fb->depth);
+ DRM_INFO("fb depth is %d\n", fb->format->depth);
DRM_INFO(" pitch is %d\n", fb->pitches[0]);
vga_switcheroo_client_fb_set(adev->ddev->pdev, info);
diff --git a/drivers/gpu/drm/armada/armada_fbdev.c
b/drivers/gpu/drm/armada/armada_fbdev.c
index c5dc06a55883..3a58fb600b05 100644
--- a/drivers/gpu/drm/armada/armada_fbdev.c
+++ b/drivers/gpu/drm/armada/armada_fbdev.c
@@ -89,7 +89,8 @@ static int armada_fb_create(struct drm_fb_helper *fbh,
info->screen_base = ptr;
fbh->fb = &dfb->fb;
- drm_fb_helper_fill_fix(info, dfb->fb.pitches[0], dfb->fb.depth);
+ drm_fb_helper_fill_fix(info, dfb->fb.pitches[0],
+ dfb->fb.format->depth);
drm_fb_helper_fill_var(info, fbh, sizes->fb_width, sizes->fb_height);
DRM_DEBUG_KMS("allocated %dx%d %dbpp fb: 0x%08llx\n",
diff --git a/drivers/gpu/drm/ast/ast_fb.c b/drivers/gpu/drm/ast/ast_fb.c
index d6f5ec64c667..
[PATCH v2 25/37] drm: Replace drm_format_plane_cpp() with fb->format->cpp[]
From: Ville Syrjälä
Replace drm_format_plane_cpp(fb->pixel_format) with just
fb->format->cpp[]. Avoids the expensive format info lookup.
@@
struct drm_framebuffer *a;
struct drm_framebuffer b;
expression E;
@@
(
- drm_format_plane_cpp(a->pixel_format, E)
+ a->format->cpp[E]
|
- drm_format_plane_cpp(b.pixel_format, E)
+ b.format->cpp[E]
)
@@
struct drm_plane_state *a;
struct drm_plane_state b;
expression E;
@@
(
- drm_format_plane_cpp(a->fb->pixel_format, E)
+ a->fb->format->cpp[E]
|
- drm_format_plane_cpp(b.fb->pixel_format, E)
+ b.fb->format->cpp[E]
)
@@
struct drm_framebuffer *a;
identifier T;
expression E;
@@
T = a->pixel_format
<+...
- drm_format_plane_cpp(T, E)
+ a->format->cpp[E]
...+>
@@
struct drm_framebuffer b;
identifier T;
expression E;
@@
T = b.pixel_format
<+...
- drm_format_plane_cpp(T, E)
+ b.format->cpp[E]
...+>
v2: Rerun spatch due to code changes
Cc: Laurent Pinchart
Suggested-by: Laurent Pinchart
Signed-off-by: Ville Syrjälä
Reviewed-by: Laurent Pinchart
---
drivers/gpu/drm/arm/hdlcd_crtc.c| 2 +-
drivers/gpu/drm/armada/armada_crtc.c| 3 +-
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 2 +-
drivers/gpu/drm/i915/intel_display.c| 16 +-
drivers/gpu/drm/i915/intel_pm.c | 42 -
drivers/gpu/drm/i915/intel_sprite.c | 2 +-
drivers/gpu/drm/imx/ipuv3-plane.c | 6 ++--
drivers/gpu/drm/mediatek/mtk_drm_plane.c| 2 +-
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 4 +--
drivers/gpu/drm/sti/sti_gdp.c | 2 +-
drivers/gpu/drm/sun4i/sun4i_backend.c | 2 +-
drivers/gpu/drm/tilcdc/tilcdc_crtc.c| 2 +-
drivers/gpu/drm/tilcdc/tilcdc_plane.c | 2 +-
drivers/gpu/drm/vc4/vc4_plane.c | 2 +-
drivers/gpu/drm/zte/zx_plane.c | 2 +-
15 files changed, 45 insertions(+), 46 deletions(-)
diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c
index 35705a4173f3..ecdcd99c92cc 100644
--- a/drivers/gpu/drm/arm/hdlcd_crtc.c
+++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
@@ -238,7 +238,7 @@ static void hdlcd_plane_atomic_update(struct drm_plane
*plane,
scanout_start = gem->paddr + fb->offsets[0] +
plane->state->crtc_y * fb->pitches[0] +
plane->state->crtc_x *
- drm_format_plane_cpp(fb->pixel_format, 0);
+ fb->format->cpp[0];
hdlcd = plane->dev->dev_private;
hdlcd_write(hdlcd, HDLCD_REG_FB_LINE_LENGTH, fb->pitches[0]);
diff --git a/drivers/gpu/drm/armada/armada_crtc.c
b/drivers/gpu/drm/armada/armada_crtc.c
index 2e1c63569c72..99283f30edc5 100644
--- a/drivers/gpu/drm/armada/armada_crtc.c
+++ b/drivers/gpu/drm/armada/armada_crtc.c
@@ -169,7 +169,6 @@ void armada_drm_plane_calc_addrs(u32 *addrs, struct
drm_framebuffer *fb,
int x, int y)
{
u32 addr = drm_fb_obj(fb)->dev_addr;
- u32 pixel_format = fb->pixel_format;
int num_planes = fb->format->num_planes;
int i;
@@ -178,7 +177,7 @@ void armada_drm_plane_calc_addrs(u32 *addrs, struct
drm_framebuffer *fb,
for (i = 0; i < num_planes; i++)
addrs[i] = addr + fb->offsets[i] + y * fb->pitches[i] +
-x * drm_format_plane_cpp(pixel_format, i);
+x * fb->format->cpp[i];
for (; i < 3; i++)
addrs[i] = 0;
}
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
index f97ae75f9e63..3e00512ef187 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
@@ -672,7 +672,7 @@ static int atmel_hlcdc_plane_atomic_check(struct drm_plane
*p,
int xdiv = i ? hsub : 1;
int ydiv = i ? vsub : 1;
- state->bpp[i] = drm_format_plane_cpp(fb->pixel_format, i);
+ state->bpp[i] = fb->format->cpp[i];
if (!state->bpp[i])
return -EINVAL;
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 41f9b3d5ce85..1f9e5adc0d69 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2276,7 +2276,7 @@ u32 intel_fb_xy_to_linear(int x, int y,
int plane)
{
const struct drm_framebuffer *fb = state->base.fb;
- unsigned int cpp = drm_format_plane_cpp(fb->pixel_format, plane);
+ unsigned int cpp = fb->format->cpp[plane];
unsigned int pitch = fb->pitches[plane];
return y * pitch + x * cpp;
@@ -2345,7 +2345,7 @@ static u32 intel_adjust_tile_offset(int *x, int *y,
{
const struct drm_i915_private *dev_priv =
to_i915(state->base.plane->dev);
const struct drm_framebuffer *fb = state->base.fb;
- unsigned int cpp = drm_format_plane_cpp(fb->pixel_format, plane);
+ u
[PATCH v2 23/37] drm: Replace drm_format_num_planes() with fb->format->num_planes
From: Ville Syrjälä
Replace drm_format_num_planes(fb->pixel_format) with just
fb->format->num_planes. Avoids the expensive format info lookup.
@@
struct drm_framebuffer *a;
struct drm_framebuffer b;
@@
(
- drm_format_num_planes(a->pixel_format)
+ a->format->num_planes
|
- drm_format_num_planes(b.pixel_format)
+ b.format->num_planes
)
@@
struct drm_plane_state *a;
struct drm_plane_state b;
@@
(
- drm_format_num_planes(a->fb->pixel_format)
+ a->fb->format->num_planes
|
- drm_format_num_planes(b.fb->pixel_format)
+ b.fb->format->num_planes
)
@@
struct drm_framebuffer *a;
identifier T;
@@
T = a->pixel_format
<+...
- drm_format_num_planes(T)
+ a->format->num_planes
...+>
@@
struct drm_framebuffer b;
identifier T;
@@
T = b.pixel_format
<+...
- drm_format_num_planes(T)
+ b.format->num_planes
...+>
v2: Rerun spatch due to code changes
Cc: Laurent Pinchart
Suggested-by: Laurent Pinchart
Signed-off-by: Ville Syrjälä
Reviewed-by: Laurent Pinchart
---
drivers/gpu/drm/arm/malidp_planes.c | 2 +-
drivers/gpu/drm/armada/armada_crtc.c| 2 +-
drivers/gpu/drm/armada/armada_overlay.c | 2 +-
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_layer.c | 2 +-
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 2 +-
drivers/gpu/drm/drm_atomic.c| 2 +-
drivers/gpu/drm/i915/intel_display.c| 2 +-
drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 2 +-
drivers/gpu/drm/msm/msm_fb.c| 8
drivers/gpu/drm/omapdrm/omap_fb.c | 8
drivers/gpu/drm/tegra/dc.c | 4 ++--
drivers/gpu/drm/tegra/fb.c | 2 +-
drivers/gpu/drm/vc4/vc4_plane.c | 2 +-
13 files changed, 20 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/arm/malidp_planes.c
b/drivers/gpu/drm/arm/malidp_planes.c
index ee7f7663a307..533ee2fa64be 100644
--- a/drivers/gpu/drm/arm/malidp_planes.c
+++ b/drivers/gpu/drm/arm/malidp_planes.c
@@ -116,7 +116,7 @@ static int malidp_de_plane_check(struct drm_plane *plane,
if (ms->format == MALIDP_INVALID_FORMAT_ID)
return -EINVAL;
- ms->n_planes = drm_format_num_planes(fb->pixel_format);
+ ms->n_planes = fb->format->num_planes;
for (i = 0; i < ms->n_planes; i++) {
if (!malidp_hw_pitch_valid(mp->hwdev, fb->pitches[i])) {
DRM_DEBUG_KMS("Invalid pitch %u for plane %d\n",
diff --git a/drivers/gpu/drm/armada/armada_crtc.c
b/drivers/gpu/drm/armada/armada_crtc.c
index 95cb3966b2ca..2e1c63569c72 100644
--- a/drivers/gpu/drm/armada/armada_crtc.c
+++ b/drivers/gpu/drm/armada/armada_crtc.c
@@ -170,7 +170,7 @@ void armada_drm_plane_calc_addrs(u32 *addrs, struct
drm_framebuffer *fb,
{
u32 addr = drm_fb_obj(fb)->dev_addr;
u32 pixel_format = fb->pixel_format;
- int num_planes = drm_format_num_planes(pixel_format);
+ int num_planes = fb->format->num_planes;
int i;
if (num_planes > 3)
diff --git a/drivers/gpu/drm/armada/armada_overlay.c
b/drivers/gpu/drm/armada/armada_overlay.c
index 6743615232f5..a0883a1b3387 100644
--- a/drivers/gpu/drm/armada/armada_overlay.c
+++ b/drivers/gpu/drm/armada/armada_overlay.c
@@ -188,7 +188,7 @@ armada_ovl_plane_update(struct drm_plane *plane, struct
drm_crtc *crtc,
pixel_format = fb->pixel_format;
hsub = drm_format_horz_chroma_subsampling(pixel_format);
- num_planes = drm_format_num_planes(pixel_format);
+ num_planes = fb->format->num_planes;
/*
* Annoyingly, shifting a YUYV-format image by one pixel
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_layer.c
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_layer.c
index 377e43cea9dd..63dfdbf34f80 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_layer.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_layer.c
@@ -446,7 +446,7 @@ void atmel_hlcdc_layer_update_set_fb(struct
atmel_hlcdc_layer *layer,
return;
if (fb)
- nplanes = drm_format_num_planes(fb->pixel_format);
+ nplanes = fb->format->num_planes;
if (nplanes > layer->max_planes)
return;
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
index 246ed1e33d8a..f97ae75f9e63 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
@@ -621,7 +621,7 @@ static int atmel_hlcdc_plane_atomic_check(struct drm_plane
*p,
state->src_w >>= 16;
state->src_h >>= 16;
- state->nplanes = drm_format_num_planes(fb->pixel_format);
+ state->nplanes = fb->format->num_planes;
if (state->nplanes > ATMEL_HLCDC_MAX_PLANES)
return -EINVAL;
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 60697482b94c..62f0f57728e1 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drive
Issue with DRM and "reimplement IDR and IDA using the radix tree"
Forgot to add the most relevant list for this issue (linux-next). Stephen, maybe you will want to temporarily revert this patch until this is cleared? This probably affects other users than DRM. On 12/13/2016 04:14 PM, Alexandre Courbot wrote: > Hi Matthew, > > Trying the latest -next on the Jetson TK1 board (with two different DRM > devices and display and render), I noticed that the GPU device probe > always failed with error -ENOSPC. After investigating I figured out that > this was due to the minor device allocation failing when a second DRM > device is added. > > More precisely, when drm_minor_alloc() is called with DRM_MINOR_PRIMARY > (0) as argument for a second time, the call to idr_alloc() (which has a > requested range of 0..64) fails instead of returning 1 as expected. Note > that the first call is successful. > > Reverting "reimplement IDR and IDA using the radix tree" on 20161213's > next fixes the issue for me, suggesting a bug may have slipped in there. > > Not sure how this could be fixed, so reporting the issue for now in case > it is not known yet. > > Cheers, > Alex. > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel >
[PATCH] drm: rcar-du: enable VSPDs on R8A7791
Hi Sergei,
Thank you for the patch.
On Wednesday 14 Dec 2016 23:37:08 Sergei Shtylyov wrote:
> We're going to use R8A7791 VSPDs to control DU, so set the corresponding
> flag.
>
> Signed-off-by: Sergei Shtylyov
For the same reason I nacked the corresponding patch to the VSP1 driver, I
have to nack this one as well. The Gen2 DU has native planes, this patch would
prevent using them. I don't see a good reason to do so.
> ---
> The patch is against David Airlie's 'linux.git' repo's 'drm-next' branch.
>
> drivers/gpu/drm/rcar-du/rcar_du_drv.c |3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> Index: linux/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> ===
> --- linux.orig/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> +++ linux/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> @@ -90,7 +90,8 @@ static const struct rcar_du_device_info
> static const struct rcar_du_device_info rcar_du_r8a7791_info = {
> .gen = 2,
> .features = RCAR_DU_FEATURE_CRTC_IRQ_CLOCK
> - | RCAR_DU_FEATURE_EXT_CTRL_REGS,
> + | RCAR_DU_FEATURE_EXT_CTRL_REGS
> + | RCAR_DU_FEATURE_VSP1_SOURCE,
> .num_crtcs = 2,
> .routes = {
> /* R8A779[13] has one RGB output, one LVDS output and one
--
Regards,
Laurent Pinchart
[PATCH v2 13/37] drm: Pass 'dev' to drm_helper_mode_fill_fb_struct()
From: Ville Syrjälä
Pass the drm_device to drm_helper_mode_fill_fb_struct() so that we can
populate fb->dev early. Will make it easier to use the fb before we
register it.
@@
identifier fb, mode_cmd;
@@
void drm_helper_mode_fill_fb_struct(
+struct drm_device *dev,
struct drm_framebuffer *fb,
const struct drm_mode_fb_cmd2 *mode_cmd
);
@@
identifier fb, mode_cmd;
@@
void drm_helper_mode_fill_fb_struct(
+struct drm_device *dev,
struct drm_framebuffer *fb,
const struct drm_mode_fb_cmd2 *mode_cmd
)
{ ... }
@@
function func;
identifier dev;
expression E1, E2;
@@
func(struct drm_device *dev, ...)
{
...
drm_helper_mode_fill_fb_struct(
+ dev,
E1, E2);
...
}
@@
expression E1, E2;
@@
drm_helper_mode_fill_fb_struct(
+ dev,
E1, E2);
v2: Rerun spatch due to code changes
Signed-off-by: Ville Syrjälä
Reviewed-by: Laurent Pinchart
Reviewed-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 2 +-
drivers/gpu/drm/armada/armada_fb.c | 2 +-
drivers/gpu/drm/ast/ast_main.c | 2 +-
drivers/gpu/drm/bochs/bochs_mm.c| 2 +-
drivers/gpu/drm/cirrus/cirrus_main.c| 2 +-
drivers/gpu/drm/drm_fb_cma_helper.c | 2 +-
drivers/gpu/drm/drm_modeset_helper.c| 3 ++-
drivers/gpu/drm/exynos/exynos_drm_fb.c | 2 +-
drivers/gpu/drm/gma500/framebuffer.c| 2 +-
drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c | 2 +-
drivers/gpu/drm/i915/intel_display.c| 2 +-
drivers/gpu/drm/mediatek/mtk_drm_fb.c | 2 +-
drivers/gpu/drm/mgag200/mgag200_main.c | 2 +-
drivers/gpu/drm/msm/msm_fb.c| 2 +-
drivers/gpu/drm/nouveau/nouveau_display.c | 2 +-
drivers/gpu/drm/omapdrm/omap_fb.c | 2 +-
drivers/gpu/drm/qxl/qxl_display.c | 2 +-
drivers/gpu/drm/radeon/radeon_display.c | 2 +-
drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 2 +-
drivers/gpu/drm/tegra/fb.c | 2 +-
drivers/gpu/drm/udl/udl_fb.c| 2 +-
drivers/gpu/drm/virtio/virtgpu_display.c| 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 4 ++--
include/drm/drm_modeset_helper.h| 3 ++-
24 files changed, 27 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
index 581601ca6b89..d2036df145b3 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
@@ -508,7 +508,7 @@ amdgpu_framebuffer_init(struct drm_device *dev,
{
int ret;
rfb->obj = obj;
- drm_helper_mode_fill_fb_struct(&rfb->base, mode_cmd);
+ drm_helper_mode_fill_fb_struct(dev, &rfb->base, mode_cmd);
ret = drm_framebuffer_init(dev, &rfb->base, &amdgpu_fb_funcs);
if (ret) {
rfb->obj = NULL;
diff --git a/drivers/gpu/drm/armada/armada_fb.c
b/drivers/gpu/drm/armada/armada_fb.c
index f03c212b754d..2a7eb6817c36 100644
--- a/drivers/gpu/drm/armada/armada_fb.c
+++ b/drivers/gpu/drm/armada/armada_fb.c
@@ -81,7 +81,7 @@ struct armada_framebuffer *armada_framebuffer_create(struct
drm_device *dev,
dfb->mod = config;
dfb->obj = obj;
- drm_helper_mode_fill_fb_struct(&dfb->fb, mode);
+ drm_helper_mode_fill_fb_struct(dev, &dfb->fb, mode);
ret = drm_framebuffer_init(dev, &dfb->fb, &armada_fb_funcs);
if (ret) {
diff --git a/drivers/gpu/drm/ast/ast_main.c b/drivers/gpu/drm/ast/ast_main.c
index 904beaa932d0..d85af0ff2653 100644
--- a/drivers/gpu/drm/ast/ast_main.c
+++ b/drivers/gpu/drm/ast/ast_main.c
@@ -313,7 +313,7 @@ int ast_framebuffer_init(struct drm_device *dev,
{
int ret;
- drm_helper_mode_fill_fb_struct(&ast_fb->base, mode_cmd);
+ drm_helper_mode_fill_fb_struct(dev, &ast_fb->base, mode_cmd);
ast_fb->obj = obj;
ret = drm_framebuffer_init(dev, &ast_fb->base, &ast_fb_funcs);
if (ret) {
diff --git a/drivers/gpu/drm/bochs/bochs_mm.c b/drivers/gpu/drm/bochs/bochs_mm.c
index 099a3c688c26..ceb1fecf02dd 100644
--- a/drivers/gpu/drm/bochs/bochs_mm.c
+++ b/drivers/gpu/drm/bochs/bochs_mm.c
@@ -484,7 +484,7 @@ int bochs_framebuffer_init(struct drm_device *dev,
{
int ret;
- drm_helper_mode_fill_fb_struct(&gfb->base, mode_cmd);
+ drm_helper_mode_fill_fb_struct(dev, &gfb->base, mode_cmd);
gfb->obj = obj;
ret = drm_framebuffer_init(dev, &gfb->base, &bochs_fb_funcs);
if (ret) {
diff --git a/drivers/gpu/drm/cirrus/cirrus_main.c
b/drivers/gpu/drm/cirrus/cirrus_main.c
index 2c3c0d4072ce..52d901fa8687 100644
--- a/drivers/gpu/drm/cirrus/cir
[PATCH v2] drm/mxsfb: use bus_format to determine LCD bus width
On 12/14/2016 09:51 PM, Stefan Agner wrote:
> On 2016-12-13 23:52, Marek Vasut wrote:
>> On 12/14/2016 02:02 AM, Stefan Agner wrote:
>>> The LCD bus width does not need to align with the pixel format. The
>>> LCDIF controller automatically converts between pixel formats and
>>> bus width by padding or dropping LSBs.
>>>
>>> The DRM subsystem has the notion of bus_format which allows to
>>> determine what bus_formats are supported by the display. Choose the
>>> first available or fallback to 24 bit if none are available.
>>>
>>> Signed-off-by: Stefan Agner
>>
>> Minor nits below.
>>
>>> ---
>>> Changes in v2:
>>> - Use seperate function mxsfb_set_bus_fmt
>>>
>>> drivers/gpu/drm/mxsfb/mxsfb_crtc.c | 33 +++--
>>> drivers/gpu/drm/mxsfb/mxsfb_regs.h | 1 +
>>> 2 files changed, 32 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
>>> b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
>>> index 4bcc8a3..956769b 100644
>>> --- a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
>>> +++ b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
>>> @@ -65,13 +65,11 @@ static int mxsfb_set_pixel_fmt(struct mxsfb_drm_private
>>> *mxsfb)
>>> switch (format) {
>>> case DRM_FORMAT_RGB565:
>>> dev_dbg(drm->dev, "Setting up RGB565 mode\n");
>>> - ctrl |= CTRL_SET_BUS_WIDTH(STMLCDIF_16BIT);
>>> ctrl |= CTRL_SET_WORD_LENGTH(0);
>>> ctrl1 |= CTRL1_SET_BYTE_PACKAGING(0xf);
>>> break;
>>> case DRM_FORMAT_XRGB:
>>> dev_dbg(drm->dev, "Setting up XRGB mode\n");
>>> - ctrl |= CTRL_SET_BUS_WIDTH(STMLCDIF_24BIT);
>>> ctrl |= CTRL_SET_WORD_LENGTH(3);
>>> /* Do not use packed pixels = one pixel per word instead. */
>>> ctrl1 |= CTRL1_SET_BYTE_PACKAGING(0x7);
>>> @@ -87,6 +85,35 @@ static int mxsfb_set_pixel_fmt(struct mxsfb_drm_private
>>> *mxsfb)
>>> return 0;
>>> }
>>>
>>> +static void mxsfb_set_bus_fmt(struct mxsfb_drm_private *mxsfb)
>>> +{
>>> + struct drm_crtc *crtc = &mxsfb->pipe.crtc;
>>> + struct drm_device *drm = crtc->dev;
>>> + u32 bus_format = MEDIA_BUS_FMT_RGB888_1X24;
>>> + u32 reg;
>> ^^^ this is uninitialized
>>
>>> + writel(CTRL_BUS_WIDTH_MASK, mxsfb->base + LCDC_CTRL + REG_CLR);
>>> +
>>> + if (mxsfb->connector.display_info.num_bus_formats)
>>> + bus_format = mxsfb->connector.display_info.bus_formats[0];
>>> +
>>> + switch (bus_format) {
>>> + case MEDIA_BUS_FMT_RGB565_1X16:
>>> + reg |= CTRL_SET_BUS_WIDTH(STMLCDIF_16BIT);
>> ^^^
>> here you're doing operation on uninited value.
>>
>>> + break;
>>> + case MEDIA_BUS_FMT_RGB666_1X18:
>>> + reg |= CTRL_SET_BUS_WIDTH(STMLCDIF_18BIT);
>>> + break;
>>> + case MEDIA_BUS_FMT_RGB888_1X24:
>>> + reg |= CTRL_SET_BUS_WIDTH(STMLCDIF_24BIT);
>>> + break;
>>> + default:
>>> + dev_err(drm->dev, "Unknown media bus format %d\n", bus_format);
>>> + break;
>>> + }
>>> + writel(reg, mxsfb->base + LCDC_CTRL + REG_SET);
>>
>> What I was thinking might be better is to save the calculated LCD_CRTC
>> value in mxsfb_drm_private , but maybe R-M-W is good enough after all?
>
> Yeah I see what you are saying, however I would prefer to not cache if
> there is no real reason to...
OK
> It is now a write to the clear and one write to the set variant of the
> register, not sure if that counts as "two writes".
It's two writel() calls, it does.
>> Two writes are IMO not great because it unnecessarily reconfigures the
>> controller twice.
>
> Does that matter? At this point, the RUN bit is guaranteed not to be
> set...
It's probably a matter of taste, although I'd be more comfortable with
RMW here.
--
Best regards,
Marek Vasut
[PATCH v2] drm/mxsfb: fix pixel clock polarity
On 12/14/2016 09:48 PM, Stefan Agner wrote: > The DRM subsystem specifies the pixel clock polarity from a > controllers perspective: DRM_BUS_FLAG_PIXDATA_NEGEDGE means > the controller drives the data on pixel clocks falling edge. > That is the controllers DOTCLK_POL=0 (Default is data launched > at negative edge). > > Also change the data enable logic to be high active by default > and only change if explicitly requested via bus_flags. With > that defaults are: > - Data enable: high active > - Pixel clock polarity: controller drives data on negative edge > > Signed-off-by: Stefan Agner Acked-by: Marek Vasut > --- > Changes since v1: > - Improved comments/fixed typo > > drivers/gpu/drm/mxsfb/mxsfb_crtc.c | 11 +-- > 1 file changed, 9 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c > b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c > index 3770dd2..5556e53 100644 > --- a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c > +++ b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c > @@ -195,9 +195,16 @@ static void mxsfb_crtc_mode_set_nofb(struct > mxsfb_drm_private *mxsfb) > vdctrl0 |= VDCTRL0_HSYNC_ACT_HIGH; > if (m->flags & DRM_MODE_FLAG_PVSYNC) > vdctrl0 |= VDCTRL0_VSYNC_ACT_HIGH; > - if (bus_flags & DRM_BUS_FLAG_DE_HIGH) > + /* Make sure Data Enable is high active by default */ > + if (!(bus_flags & DRM_BUS_FLAG_DE_LOW)) > vdctrl0 |= VDCTRL0_ENABLE_ACT_HIGH; > - if (bus_flags & DRM_BUS_FLAG_PIXDATA_NEGEDGE) > + /* > + * DRM_BUS_FLAG_PIXDATA_ defines are controller centric, > + * controllers VDCTRL0_DOTCLK is display centric. > + * Drive on positive edge -> display samples on falling edge > + * DRM_BUS_FLAG_PIXDATA_POSEDGE -> VDCTRL0_DOTCLK_ACT_FALLING > + */ > + if (bus_flags & DRM_BUS_FLAG_PIXDATA_POSEDGE) > vdctrl0 |= VDCTRL0_DOTCLK_ACT_FALLING; > > writel(vdctrl0, mxsfb->base + LCDC_VDCTRL0); > -- Best regards, Marek Vasut
[PATCH] drm/mxsfb: fix pixel clock polarity
On 12/14/2016 09:29 PM, Stefan Agner wrote: > On 2016-12-14 00:04, Marek Vasut wrote: >> On 12/14/2016 01:01 AM, Stefan Agner wrote: >>> On 2016-12-08 15:38, Marek Vasut wrote: On 12/08/2016 09:46 PM, Stefan Agner wrote: > On 2016-12-07 18:37, Marek Vasut wrote: >> On 12/08/2016 02:26 AM, Stefan Agner wrote: >>> On 2016-12-07 16:59, Stefan Agner wrote: On 2016-12-07 16:49, Marek Vasut wrote: > On 12/08/2016 01:27 AM, Stefan Agner wrote: >> The DRM subsystem specifies the pixel clock polarity from a >> controllers perspective: DRM_BUS_FLAG_PIXDATA_NEGEDGE means >> the controller drives the data on pixel clocks falling edge. >> That is the controllers DOTCLK_POL=0 (Default is data launched >> at negative edge). >> >> Also change the data enable logic to be high active by default >> and only change if explicitly requested via bus_flags. With >> that defaults are: >> - Data enable: high active >> - Pixel clock polarity: controller drives data on negative edge >> >> Signed-off-by: Stefan Agner >> --- >> Hi Marek, > > Hi, that was quick, thanks for checking this. Yeah, I couldn't wait seeing it flying :-) > >> I discovered this while testing on a i.MX 7 eLCDIF IP. Particularly >> the >> non-standard DE polarity was causing issues. I was using a EDT >> display >> which is part of simple panel driver since a while now and does not >> specify any bus_flags currently... Of course I could (and probably >> should) >> add the proper bus_flags there too, but there are several displays >> which do not specify any polarity and likely rely on sensible driver >> standards (which is afact high active for the DE signal). > > I actually use a panel which requires correct settings of the flags, > see > e0932f9d7ba9a16f99a84943b720f109de8e3e06 in mainline , so this patch > would break things for me. So I wonder whether you should fix the > panel > driver or whether the mxsfb should be fixed ? If you ask me, mxsfb. Ok, there are actually two things, one is a bug, one is a default change. The bug: Pixel clock polarity is clearly defined to be controller centric (see comments around DRM_BUS_FLAG_PIXDATA_*EDGE in include/drm/drm_connector.h). The driver does it wrong currently. This might affect your display, and if it does, it is actually wrong also in your display... However, since it is a bug, I think it is not really a debate, it should be fixed... >>> >>> FWIW, it seems that Ortustech com43h4m85ulc samples on falling edge, so >>> DRM_BUS_FLAG_PIXDATA_POSEDGE seems right. And it means that DOTCLK_POL >>> should be 1 (inverted), so with this patch the polarity should actually >>> be correct for that panel. >> >> Well, if I apply this patch, my image is shifted by 1 px to the left and >> there is a 1px white bar on the right side, so I think I have some >> polarity problem now ? > > Ok, lets create facts here: > 1. SoloX Refrence Manual, Figure 37-13. shows DOTCLK_POL=0, and it shows > that the controller drives signals on falling edge of the pixel clock. > The i.MX 7 has the same figure. > 2. Just to verify, I hooked up an oscilloscope on my i.MX 7: It shows > that with DOTCLK_POL=0 the controller drives on falling edge: > http://imgur.com/a/2f2Xt > > So my measurements verify what is in the i.MX data sheets. Good > The current code sets the bit when negative edge (falling edge) is > requested, which is wrong: > #define VDCTRL0_DOTCLK_ACT_FALLING(1 << 25) > ... > if (bus_flags & DRM_BUS_FLAG_PIXDATA_NEGEDGE) > vdctrl0 |= VDCTRL0_DOTCLK_ACT_FALLING; > > Not sure what is going on with your display, maybe the datasheet is just > wrong (it requires DRM_BUS_FLAG_PIXDATA_NEGEDGE in fact) or it is some > other artifact. This is probably where the problem crept in [1], droping PIXDATA_POSEDGE actually makes this patch work for me. CCing Philipp. [1] https://patchwork.kernel.org/patch/9301517/ >>> >>> I looked at a old data sheet of that display and it seemed that >>> PIXDATA_POSEDGE is the right thing. Panelook.cn lists newer data sheets, >>> but I couldn't find them on the open internet, do you have access to a >>> newer one? >> >> Which "version" do you have ? Probably not though. >> > > I couldn't find it anymore, but I think it said Rev. 0 > >>> http://www.panelook.cn/COM43H4M85ULC_ORTUSTECH_4.3_LCM_overview_17296.html >>> >>> I guess in the end it doesn't matter: Given that it is verified that the >>> control
[Bug 98869] Electronic Super Joy graphic artefacts (regression)
https://bugs.freedesktop.org/show_bug.cgi?id=98869 Mark Janes changed: What|Removed |Added Component|Mesa core |Drivers/Gallium/r300 QA Contact|mesa-dev at lists.freedesktop. |dri-devel at lists.freedesktop |org |.org Assignee|mesa-dev at lists.freedesktop. |dri-devel at lists.freedesktop |org |.org -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161214/338f14f2/attachment.html>
[PATCH] amdgpu: get maximum and used UVD handles
On 12 December 2016 at 18:51, wrote: > From: Arindam Nath > > User might want to query the maximum number of UVD > instances supported by firmware. In addition to that, > if there are multiple applications using UVD handles > at the same time, he might also want to query the > currently used number of handles. > > For this we add a new query AMDGPU_INFO_NUM_HANDLES > and a new struct drm_amdgpu_info_num_handles to > get these values. > > Signed-off-by: Arindam Nath > Reviewed-by: Christian König > --- > include/drm/amdgpu_drm.h | 9 + > 1 file changed, 9 insertions(+) > Follow the documented way to update the libdrm headers [1]. You will want to tackle this [2] small task first. If the documentation is unclear and/or can be improved feel free to send a patch. Thanks Emil [1] https://cgit.freedesktop.org/mesa/drm/tree/include/drm/README#n68 [2] https://cgit.freedesktop.org/mesa/drm/tree/include/drm/README#n97
[Libva] [PATCH v2 0/7] Host1x IOMMU support + VIC support
Hi, Comments below: > On Dec 14, 2016, at 6:48 AM, Daniel Vetter wrote: > > On Wed, Dec 14, 2016 at 3:11 PM, Daniel Vetter wrote: >> On Wed, Dec 14, 2016 at 03:32:16PM +0200, Mikko Perttunen wrote: >>> On 14.12.2016 15:05, Daniel Vetter wrote: On Wed, Dec 14, 2016 at 02:41:28PM +0200, Mikko Perttunen wrote: > On 14.12.2016 14:30, Daniel Vetter wrote: >> On Wed, Dec 14, 2016 at 01:16:10PM +0200, Mikko Perttunen wrote: >>> This series adds IOMMU support to Host1x and TegraDRM >>> and adds support for the VIC (Video Image Compositor) >>> host1x client. The series is available as a git repository at >>> git://github.com/cyndis/linux.git; branch vic-2. >>> >>> A userspace test case for VIC can be found at >>> https://github.com/cyndis/drm/tree/work/tegra. >>> The testcase is in tests/tegra and is called submit_vic. >>> The testcase/TRM include full headers and documentation >>> to program the unit. The unit by itself, however, does not >>> readily map to existing userspace library interfaces, so >>> implementations for those are not provided. >> >> Afaik libva has an entire pile of post-processing support. Pretty sure >> other video transcode libraries have similar interfaces, so should all be >> possible to implement this. > > We don't have any actual video transcoding support though, so unless it's > possible to just implement a part of libva and defer the rest to some CPU > implementation, I don't see how this is useful. I suppose I could > implement > a GStreamer plugin for colorspace conversion or resizing, since those are > very modular. Hm, I guess the question then is, how did that get enabled? >>> >>> What is "that"? I'm not exactly sure. >>> >>> Our architecture is such that there's the VIC that handles colorspace >>> conversion, rescaling, blitting and can do some 2d postprocessing effects as >>> well. >>> >>> Then there's the separate NVDEC that is a video bitstream decoder. There's >>> no support for that at the moment. I am working on the IP side of that. >>> >>> The video processing pipeline is then such that NVDEC is fed the bitstream; >>> NVDEC outputs a YUV picture in a specific format; VIC takes that YUV picture >>> and converts/rescales it into the desired format. Or if we are encoding >>> video, VIC takes your RGB image, converts it into a format that NVENC >>> understands, and so on. >>> >>> So with just VIC support, I could implement some simple 2D things. I don't >>> know if anyone would want to specifically use the VIC for those since >>> applications already have fast CPU algorithms. For the video pipeline using >>> VIC is nice since these units can synchronize work without CPU involvement >>> and when you're already using NVDEC or NVENC it's barely any extra effort to >>> involve VIC as well. It can also be useful in power usage sensitive >>> situations, but we aren't really fit for those situations with the upstream >>> kernel anyway :) >> >> Ah I thought the nvdec was already enabled, since for i915 that's how we >> went about things (we have a pretty much exactly matching split in the >> various video related engines). But if that's not there yet then no >> worries, all fine. >> >> Since you do seem to plan to enable everything anyway, might be worth it >> to go directly with something like libva or libvdpau or whatever the cool >> thing is. libva is my recommendation since it works on non-X11 too afaik, >> but I have 0 clue. And might be worth it to check out whether you can't do >> a super-basic libva driver that only does the post processing stuff. With >> libva you can import/export images, so it might be possible even ... And >> directly doing the full video engine support instead of a one-off in >> gstreamer sounds more sensible to me. > > Silly me forgot to add the experts, i.e. Sean (current libva > maintainer) and libva mailing lists. > -Daniel
[PATCH v2 0/7] Host1x IOMMU support + VIC support
On 14 December 2016 at 12:30, Daniel Vetter wrote:
> On Wed, Dec 14, 2016 at 01:16:10PM +0200, Mikko Perttunen wrote:
>> This series adds IOMMU support to Host1x and TegraDRM
>> and adds support for the VIC (Video Image Compositor)
>> host1x client. The series is available as a git repository at
>> git://github.com/cyndis/linux.git; branch vic-2.
>>
>> A userspace test case for VIC can be found at
>> https://github.com/cyndis/drm/tree/work/tegra.
>> The testcase is in tests/tegra and is called submit_vic.
>> The testcase/TRM include full headers and documentation
>> to program the unit. The unit by itself, however, does not
>> readily map to existing userspace library interfaces, so
>> implementations for those are not provided.
>
> Afaik libva has an entire pile of post-processing support. Pretty sure
> other video transcode libraries have similar interfaces, so should all be
> possible to implement this.
>
> Until that exists I really think that the VIC part (and only that, since
> tk1/tx1 in general seems to work with nouveau and all that) should stay
> out of tree.
Related:
With render-only about to be merged soon{tm) and Alexandre already
looking at tegra version of it, one should be able to wire this
functionality and use it in mesa/gallium.
Note: this is not an objection against the work - be that about from
quality or inclusion POV.
Emil
P.S. Goes to check on the renderonly topic.
[PATCH] drm/tegra: hdmi: Fix audio to work with any pixel clock rate
The audio setting implementation was limited to a few specific pixel
clocks. This prevented HDMI audio from working on several test devices
as they need a pixel clock that is not supported by this implementation.
Fix this by implementing the algorithm provided in the TRM using fixed
point arithmetic. This allows the driver to cope with any sane pixel
clock rate.
Signed-off-by: Alban Bedel
---
drivers/gpu/drm/tegra/hdmi.c | 163 ++-
1 file changed, 54 insertions(+), 109 deletions(-)
diff --git a/drivers/gpu/drm/tegra/hdmi.c b/drivers/gpu/drm/tegra/hdmi.c
index cda0491ed6bf..b6078d6604b1 100644
--- a/drivers/gpu/drm/tegra/hdmi.c
+++ b/drivers/gpu/drm/tegra/hdmi.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include
@@ -112,68 +113,11 @@ static inline void tegra_hdmi_writel(struct tegra_hdmi
*hdmi, u32 value,
}
struct tegra_hdmi_audio_config {
- unsigned int pclk;
unsigned int n;
unsigned int cts;
unsigned int aval;
};
-static const struct tegra_hdmi_audio_config tegra_hdmi_audio_32k[] = {
- { 2520, 4096, 25200, 24000 },
- { 2700, 4096, 27000, 24000 },
- { 7425, 4096, 74250, 24000 },
- { 14850, 4096, 148500, 24000 },
- { 0,0, 0, 0 },
-};
-
-static const struct tegra_hdmi_audio_config tegra_hdmi_audio_44_1k[] = {
- { 2520, 5880, 26250, 25000 },
- { 2700, 5880, 28125, 25000 },
- { 7425, 4704, 61875, 2 },
- { 14850, 4704, 123750, 2 },
- { 0,0, 0, 0 },
-};
-
-static const struct tegra_hdmi_audio_config tegra_hdmi_audio_48k[] = {
- { 2520, 6144, 25200, 24000 },
- { 2700, 6144, 27000, 24000 },
- { 7425, 6144, 74250, 24000 },
- { 14850, 6144, 148500, 24000 },
- { 0,0, 0, 0 },
-};
-
-static const struct tegra_hdmi_audio_config tegra_hdmi_audio_88_2k[] = {
- { 2520, 11760, 26250, 25000 },
- { 2700, 11760, 28125, 25000 },
- { 7425, 9408, 61875, 2 },
- { 14850, 9408, 123750, 2 },
- { 0, 0, 0, 0 },
-};
-
-static const struct tegra_hdmi_audio_config tegra_hdmi_audio_96k[] = {
- { 2520, 12288, 25200, 24000 },
- { 2700, 12288, 27000, 24000 },
- { 7425, 12288, 74250, 24000 },
- { 14850, 12288, 148500, 24000 },
- { 0, 0, 0, 0 },
-};
-
-static const struct tegra_hdmi_audio_config tegra_hdmi_audio_176_4k[] = {
- { 2520, 23520, 26250, 25000 },
- { 2700, 23520, 28125, 25000 },
- { 7425, 18816, 61875, 2 },
- { 14850, 18816, 123750, 2 },
- { 0, 0, 0, 0 },
-};
-
-static const struct tegra_hdmi_audio_config tegra_hdmi_audio_192k[] = {
- { 2520, 24576, 25200, 24000 },
- { 2700, 24576, 27000, 24000 },
- { 7425, 24576, 74250, 24000 },
- { 14850, 24576, 148500, 24000 },
- { 0, 0, 0, 0 },
-};
-
static const struct tmds_config tegra20_tmds_config[] = {
{ /* slow pixel clock modes */
.pclk = 2700,
@@ -411,52 +355,49 @@ static const struct tmds_config tegra124_tmds_config[] = {
},
};
-static const struct tegra_hdmi_audio_config *
-tegra_hdmi_get_audio_config(unsigned int sample_rate, unsigned int pclk)
+static int
+tegra_hdmi_get_audio_config(unsigned int audio_freq, unsigned int pix_clock,
+ struct tegra_hdmi_audio_config *config)
{
- const struct tegra_hdmi_audio_config *table;
-
- switch (sample_rate) {
- case 32000:
- table = tegra_hdmi_audio_32k;
- break;
-
- case 44100:
- table = tegra_hdmi_audio_44_1k;
- break;
-
- case 48000:
- table = tegra_hdmi_audio_48k;
- break;
-
- case 88200:
- table = tegra_hdmi_audio_88_2k;
- break;
-
- case 96000:
- table = tegra_hdmi_audio_96k;
- break;
-
- case 176400:
- table = tegra_hdmi_audio_176_4k;
- break;
-
- case 192000:
- table = tegra_hdmi_audio_192k;
- break;
-
- default:
- return NULL;
- }
-
- while (table->pclk) {
- if (table->pclk == pclk)
- return table;
-
- table++;
+ const int afreq = 128 * audio_freq;
+ const int min_n = afreq / 1500;
+ const int max_n = afreq / 300;
+ const int ideal_n = afreq / 1000;
+ int64_t min_err = (uint64_t)-1 >> 1;
+ int n;
+
+ config->n = -1;
+
+ for (n = min_n; n <= max_n; n++) {
+ uint64_t cts_f, aval_f;
+ int64_t cts, err;
+
+ /* compute aval
[Bug 98897] Macbook pro 11,5 screen flicker when AC adapter plugged in
https://bugs.freedesktop.org/show_bug.cgi?id=98897 --- Comment #17 from Cédric Le Goater --- so this is a CHIP_VERDE revision 0x83 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161214/03d508cc/attachment.html>
[RFC] Using DC in amdgpu for upcoming GPU
Thanks Alex my reply was a little off topic :)
-Original Message-
From: Alex Deucher [mailto:alexdeuc...@gmail.com]
Sent: Wednesday, December 14, 2016 1:02 PM
To: Cheng, Tony
Cc: Jani Nikula ; Lukas Wunner ; Bridgman, John ; Deucher, Alexander
; Grodzovsky, Andrey ; amd-gfx mailing list ; dri-devel
Subject: Re: [RFC] Using DC in amdgpu for upcoming GPU
On Wed, Dec 14, 2016 at 12:23 PM, Cheng, Tony wrote:
>
>
> On 12/14/2016 4:57 AM, Jani Nikula wrote:
>>
>> On Tue, 13 Dec 2016, "Cheng, Tony" wrote:
>>>
>>> I am struggling with that these comminty contributions to DC would be.
>>>
>>> Us AMD developer has access to HW docs and designer and we are still
>>> spending 50% of our time figuring out why our HW doesn't work right.
>>> I can't image community doing much of this heavy lifting.
>>
>> I can sympathize with that view, and certainly most of the heavy
>> lifting would come from you, same as with us and i915. However, when
>> you put together your hardware, an open source driver, and smart
>> people, they
>> *will* scratch their itches, whether they're bugs you're not fixing
>> or features you're missing. Please don't underestimate and patronize
>> them, it's going to rub people the wrong way.
>
> I aplogize if my statement offended any one in the community. I'll
> say more about bugs below.
>>>
>>> Dave sent us series of patch to show how it would look like if
>>> someone were to change DC. These changes are more removing code
>>> that DRM already has and deleting/clean up stuff. I guess we can
>>> nak all changes and "rewrite" our own version of clean up patch community
>>> want to see?
>>
>> Please have a look at, say,
>>
>> $ git shortlog -sne --since @{1year} -- drivers/gpu/drm/amd | grep -v
>> amd\.com
>>
>> Do you really want to actively discourage all of them from contributing?
>> I think this would be detrimental to not only your driver, but the
>> whole drm community. It feels like you'd like to have your code
>> upstream, but still retain ownership as if it was in your internal
>> repo. You can't have your cake and eat it too.
>
> That's none "dal" path. It's just Alex plus a handful of guys trying
> to figure out what register writes is needed base on windows driver.
> You knwo who has been contributing to that code path from AMD and we
> know it's a relatively small group of people. Alex and team does
> great job at being good citizen on linux world and provide support.
> But in terms of HW programming and fully expolit our HW that's pretty
> much the best they can do with the resource constraint. Of course the
> quality is not as good as we would like thus we needed all the help we
> can get from community. We just don't have the man power to make it great.
>
> We are proposing to get on a path where we can fully leverage the
> coding and validation resources from rest of AMD Display teams (SW,
> HW, tuning, validation, QA etc). Our goal is to provide a driver to
> linux community that's feature rich and high quality. My goal is
> community finds 0 bug in our code because we should've seen and fixed
> those bug in our validation pass before we release the GPUs. We do
> have a good size team around validation, just today that validation covers 0%
> of upstream source code.
> Alex and I are trying to find a path to get these goodies on the
> upstream driver without 2x size of our teams. We know 2x our team
> size is not an option.
>
> I just want to say I understand were community is coming from. Like I
> said in my first respond to Dave that I would've say no if someone
> want to throw 100k lines of code into project (DAL) I have to maintain
> without knowning what's there and the benefit we are getting. We
> already made a lot of change and design choice in our code base to
> play well with community and absorbing the effort to restructure code
> on other platforms as result of these modification. We are going to
> continue making more modifications to make our code linux worthy base on the
> good feedback we have gotten so far.
>
> DAL3/DC is a new project we started a little over years ago and still
> early enough stage to make changes. Like how community is pushing
> back on our code, after 1 or 2 future generation of GPU built on top
> of DC, the AMD teams on rest of platforms will start pushing back on
> changes in DC. We need find find the balance of what's HW and what's
> core and how to draw the line so community doesn't make much
> modification in what we (both AMD and
> community) deem "hardware backend code". We need to have the linux
> coding style and design principals baked in DC code so when our
> internal teams contribute to DC the code is written in a form linux community
> can accept.
> All of this need to happen soon or we miss this critical inflection
> point and it's going to be anther 6-8 years before we get another
> crack at re-archiecture project to try getting the rest of extended
[Bug 98897] Macbook pro 11,5 screen flicker when AC adapter plugged in
https://bugs.freedesktop.org/show_bug.cgi?id=98897 --- Comment #16 from Cédric Le Goater --- > > What chip do you have (pci device id and revision id)? 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Venus XT [Radeon HD 8870M / R9 M270X/M370X] (rev 83) (prog-if 00 [VGA controller]) Subsystem: Apple Inc. Radeon R9 M370X Mac Edition Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: radeon Kernel modules: radeon -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161214/6a797aa4/attachment-0001.html>
[PATCH libdrm] xf86drm: fix aliasing violation
On Wed, Dec 14, 2016 at 03:46:03PM +, Emil Velikov wrote: > On 12 December 2016 at 23:28, Grazvydas Ignotas wrote: > > On Mon, Dec 12, 2016 at 3:59 PM, Emil Velikov > > wrote: > >> On 11 December 2016 at 18:03, Grazvydas Ignotas > >> wrote: > >>> Just tell the compiler that drm_event will alias the char buffer, > >>> so that it has no excuse to warn or generate bad code. > >>> > >> Afacit this patch [1] from Thierry should correctly address the issue, > >> correct ? > > > > From what I've read, gcc's "strict aliasing" means that it's illegal > > to access the same memory location using pointers of different types, > > with only one exception - accessing an object of any type through a > > char pointer. What is done here is the opposite - char array is read > > as a struct, so according to that it's still wrong. > > > > That said I haven't seen any compiler causing problems in this case, > > and Thierry's solution indeed silences the warning, so I guess you can > > take his patch if you prefer. > > > I've seen a lot of noise on the topic of strict aliasing yet never had > the time to investigate [too much]. > There's some argument(s) that with type based (strict) aliasing the > GCC [used to at least] make incorrect assumptions reordering code > (stores). Latter of which causing issues when combined with > optimisations. > > That aside: afaict the warning there is triggered since we have "& > some_char" on rhs, rather than "some_char_or_void_star". With the > latter of which explicitly allowed on the topic. > The strange this is that fleshing a [identical] small example triggers > no warning, regardless of the level (1,2,3) > $ gcc -Wall -Wextra -Wstrict-aliasing=3 ss.c > > Barring any objections I'm leaning towards Thierry's patch. > > Thierry did you see any side-effect with [1] or you simply did not > have time to double-check/investigate if the problem is truly fixed. > Just double-checking. I haven't done any exhaustive or focussed testing, but I've been running the libdrm from my tree on a couple of systems and never seen any issues with drmHandleEvent(). My understanding of the problem is that aliasing is only a problem if an optimizing path would discard accesses to the aliased memory. I don't think the existing code would cause any issues because we never mix any accesses to buffer and e. I think therefore the warning is a false positive, though gcc might not be looking thoroughly enough to determine that it's harmless. Perhaps a better way to solve this would be to not rely on any casting whatsoever. We could for example add a union that contains all possible events and read that in one at a time. However, drivers can provide their own events, so the union isn't really an option. That said, since we limit ourselves to a 1 KiB buffer any events that are larger than 1 KiB (there probably aren't any) would be breaking libdrm because drmHandleEvent() wouldn't be able to read the event and therefore it won't be removed from the queue. Interestingly the kerneldoc for drm_read() says that the maximum event space is currently 4 KiB, so I guess libdrm could use an update to use that maximum. However, upon further inspection I don't see any code in the kernel that enforces this limit... Let me see if I can untangle that with some patches... Thierry -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161214/ea6682db/attachment.sig>
[PATCH v3] drm/mxsfb: use bus_format to determine LCD bus width
The LCD bus width does not need to align with the pixel format. The
LCDIF controller automatically converts between pixel formats and
bus width by padding or dropping LSBs.
The DRM subsystem has the notion of bus_format which allows to
determine what bus_formats are supported by the display. Choose the
first available or fallback to 24 bit if none are available.
Signed-off-by: Stefan Agner
---
Changes in v3:
- Use read-modify-write to update the LCDC_CTRL field
Changes in v2:
- Use seperate function mxsfb_set_bus_fmt
drivers/gpu/drm/mxsfb/mxsfb_crtc.c | 34 --
drivers/gpu/drm/mxsfb/mxsfb_regs.h | 1 +
2 files changed, 33 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
index 7f21eb3..22512f3 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
@@ -65,13 +65,11 @@ static int mxsfb_set_pixel_fmt(struct mxsfb_drm_private
*mxsfb)
switch (format) {
case DRM_FORMAT_RGB565:
dev_dbg(drm->dev, "Setting up RGB565 mode\n");
- ctrl |= CTRL_SET_BUS_WIDTH(STMLCDIF_16BIT);
ctrl |= CTRL_SET_WORD_LENGTH(0);
ctrl1 |= CTRL1_SET_BYTE_PACKAGING(0xf);
break;
case DRM_FORMAT_XRGB:
dev_dbg(drm->dev, "Setting up XRGB mode\n");
- ctrl |= CTRL_SET_BUS_WIDTH(STMLCDIF_24BIT);
ctrl |= CTRL_SET_WORD_LENGTH(3);
/* Do not use packed pixels = one pixel per word instead. */
ctrl1 |= CTRL1_SET_BYTE_PACKAGING(0x7);
@@ -87,6 +85,36 @@ static int mxsfb_set_pixel_fmt(struct mxsfb_drm_private
*mxsfb)
return 0;
}
+static void mxsfb_set_bus_fmt(struct mxsfb_drm_private *mxsfb)
+{
+ struct drm_crtc *crtc = &mxsfb->pipe.crtc;
+ struct drm_device *drm = crtc->dev;
+ u32 bus_format = MEDIA_BUS_FMT_RGB888_1X24;
+ u32 reg;
+
+ reg = readl(mxsfb->base + LCDC_CTRL);
+
+ if (mxsfb->connector.display_info.num_bus_formats)
+ bus_format = mxsfb->connector.display_info.bus_formats[0];
+
+ reg &= ~CTRL_BUS_WIDTH_MASK;
+ switch (bus_format) {
+ case MEDIA_BUS_FMT_RGB565_1X16:
+ reg |= CTRL_SET_BUS_WIDTH(STMLCDIF_16BIT);
+ break;
+ case MEDIA_BUS_FMT_RGB666_1X18:
+ reg |= CTRL_SET_BUS_WIDTH(STMLCDIF_18BIT);
+ break;
+ case MEDIA_BUS_FMT_RGB888_1X24:
+ reg |= CTRL_SET_BUS_WIDTH(STMLCDIF_24BIT);
+ break;
+ default:
+ dev_err(drm->dev, "Unknown media bus format %d\n", bus_format);
+ break;
+ }
+ writel(reg, mxsfb->base + LCDC_CTRL);
+}
+
static void mxsfb_enable_controller(struct mxsfb_drm_private *mxsfb)
{
u32 reg;
@@ -182,6 +210,8 @@ static void mxsfb_crtc_mode_set_nofb(struct
mxsfb_drm_private *mxsfb)
writel(vdctrl0, mxsfb->base + LCDC_VDCTRL0);
+ mxsfb_set_bus_fmt(mxsfb);
+
/* Frame length in lines. */
writel(m->crtc_vtotal, mxsfb->base + LCDC_VDCTRL1);
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_regs.h
b/drivers/gpu/drm/mxsfb/mxsfb_regs.h
index 31d62cd..66a6ba9 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_regs.h
+++ b/drivers/gpu/drm/mxsfb/mxsfb_regs.h
@@ -44,6 +44,7 @@
#define CTRL_DATA_SELECT (1 << 16)
#define CTRL_SET_BUS_WIDTH(x) (((x) & 0x3) << 10)
#define CTRL_GET_BUS_WIDTH(x) (((x) >> 10) & 0x3)
+#define CTRL_BUS_WIDTH_MASK(0x3 << 10)
#define CTRL_SET_WORD_LENGTH(x)(((x) & 0x3) << 8)
#define CTRL_GET_WORD_LENGTH(x)(((x) >> 8) & 0x3)
#define CTRL_MASTER(1 << 5)
--
2.10.2
[RESEND][PATCH] libkms/exynos: fix memory leak in error path
This patch fixes memory leak in error path of exynos_bo_create().
Signed-off-by: Seung-Woo Kim
---
libkms/exynos.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/libkms/exynos.c b/libkms/exynos.c
index 5de2e5a..0e97fb5 100644
--- a/libkms/exynos.c
+++ b/libkms/exynos.c
@@ -88,7 +88,8 @@ exynos_bo_create(struct kms_driver *kms,
pitch = (pitch + 512 - 1) & ~(512 - 1);
size = pitch * ((height + 4 - 1) & ~(4 - 1));
} else {
- return -EINVAL;
+ ret = -EINVAL;
+ goto err_free;
}
memset(&arg, 0, sizeof(arg));
--
1.7.4.1
[RESEND][PATCH] libkms/exynos: fix memory leak in error path
On 14 December 2016 at 13:12, Eric Engestrom
wrote:
> On Wednesday, 2016-12-14 12:21:55 +, Emil Velikov wrote:
>> On 14 December 2016 at 12:07, Eric Engestrom
>> wrote:
>> > On Wednesday, 2016-12-14 17:16:30 +0900, Seung-Woo Kim wrote:
>> >> This patch fixes memory leak in error path of exynos_bo_create().
>> >
>> > Indeed, thanks!
>> > Reviewed-by: Eric Engestrom
>> >
>> >>
>> >> Signed-off-by: Seung-Woo Kim
>> >> ---
>> >> libkms/exynos.c |3 ++-
>> >> 1 files changed, 2 insertions(+), 1 deletions(-)
>> >>
>> >> diff --git a/libkms/exynos.c b/libkms/exynos.c
>> >> index 5de2e5a..0e97fb5 100644
>> >> --- a/libkms/exynos.c
>> >> +++ b/libkms/exynos.c
>> >> @@ -88,7 +88,8 @@ exynos_bo_create(struct kms_driver *kms,
>> >> pitch = (pitch + 512 - 1) & ~(512 - 1);
>> >> size = pitch * ((height + 4 - 1) & ~(4 - 1));
>> >> } else {
>> >> - return -EINVAL;
>> >> + ret = -EINVAL;
>> >> + goto err_free;
>> >> }
>> >>
>> >> memset(&arg, 0, sizeof(arg));
>> >> --
>> >> 1.7.4.1
>> >>
>> >
>> > However, I feel like a cleaner fix might be to simply move the
>> > allocation to where it's used and remove the now-unnecessary
>> > error path, ie.:
>> >
>> > 8<
>> > diff --git a/libkms/exynos.c b/libkms/exynos.c
>> > index 5de2e5a..e2c1c9f 100644
>> > --- a/libkms/exynos.c
>> > +++ b/libkms/exynos.c
>> > @@ -76,10 +76,6 @@ exynos_bo_create(struct kms_driver *kms,
>> > }
>> > }
>> >
>> > - bo = calloc(1, sizeof(*bo));
>> > - if (!bo)
>> > - return -ENOMEM;
>> > -
>> > if (type == KMS_BO_TYPE_CURSOR_64X64_A8R8G8B8) {
>> > pitch = 64 * 4;
>> > size = 64 * 64 * 4;
>> > @@ -96,7 +92,11 @@ exynos_bo_create(struct kms_driver *kms,
>> >
>> > ret = drmCommandWriteRead(kms->fd, DRM_EXYNOS_GEM_CREATE, &arg,
>> > sizeof(arg));
>> > if (ret)
>> > - goto err_free;
>> > + return ret;
>> > +
>> > + bo = calloc(1, sizeof(*bo));
>> > + if (!bo)
>> Here we're missing the drmIoctl(... DRM_IOCTL_GEM_CLOSE ...)
>
> You're right... I'm not actually improving anything with my suggestion.
>
>>
>> Another solution is to move size/pitch calculation before the calloc.
>> Not sure which one will be better though.
>
> Let's just land Seung-Woo's fix?
> We can always refactor later :)
Agreed. it was just an idea for the future.
Thanks gents, the patch is in master now.
-Emil
[PATCH libdrm] autogen.sh: set format.subjectPrefix and sendemail.to if needed
On 14 December 2016 at 07:04, Michel Dänzer wrote: > On 13/12/16 10:09 PM, Emil Velikov wrote: >> Just set the rules automatically rather than asking each contributor to >> update thing locally. >> >> Signed-off-by: Emil Velikov >> --- >> autogen.sh | 6 ++ >> 1 file changed, 6 insertions(+) >> >> diff --git a/autogen.sh b/autogen.sh >> index c896097..e936f04 100755 >> --- a/autogen.sh >> +++ b/autogen.sh >> @@ -9,6 +9,12 @@ cd "$srcdir" >> autoreconf --force --verbose --install || exit 1 >> cd "$ORIGDIR" || exit $? >> >> +git config --local --get format.subjectPrefix || >> +git config --local format.subjectPrefix "PATCH libdrm" >> + >> +git config --local --get sendemail.to || >> +git config --local sendemail.to "dri-devel at lists.freedesktop.org" > > This is nice in general, but e.g. patches for the amdgpu/radeon > subdirectories should go to the amd-gfx list instead, and possibly also > have a different subject prefix. But maybe this is a good starting point > anyway. > Fully agreed. For now it's ~ reasonable, but we might want something better for the future. Thanks Emil
[Bug 98897] Macbook pro 11,5 screen flicker when AC adapter plugged in
https://bugs.freedesktop.org/show_bug.cgi?id=98897 --- Comment #15 from Alex Deucher --- (In reply to Cédric Le Goater from comment #14) > Hi, > > I have reverted this commit on a 4.8.14 and the flickering stopped. > > C. What chip do you have (pci device id and revision id)? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161214/615e21e2/attachment.html>
[Intel-gfx] [PATCH 05/13] drm: locking&new iterators for connector_list
On Wed, 14 Dec 2016, Daniel Vetter wrote: > On Wed, Dec 14, 2016 at 01:22:15PM +0200, Jani Nikula wrote: >> On Wed, 14 Dec 2016, Daniel Vetter wrote: >> > +/** >> > + * drm_for_each_connector_iter - connector_list iterator macro >> > + * @connector: struct &drm_connector pointer used as cursor >> > + * @iter: struct &drm_connector_list_iter >> > + * >> > + * Note that @connector is only valid within the list body, if you want >> > to use >> > + * @connector after calling drm_connector_list_iter_put() then you need >> > to grab >> > + * your own reference first using drm_connector_reference(). >> > + */ >> > +#define drm_for_each_connector_iter(connector, iter) \ >> > + while ((connector = drm_connector_list_iter_next(iter))) >> > + >> >> Observe that in most, if not all, cases you lock over the for loop, but >> not more. That means you always get/put right around the loop. >> >> You could have a variant of get() that returns the first item, and a >> variant of next() that does put() automatically when it's about to >> return NULL, and implement most of the loops like this: >> >> #define drm_for_each_connector_simple(dev, iter, connector) \ >> for (connector = drm_connector_list_iter_get_first(dev, iter); \ >> connector != NULL; \ >> connector = drm_connector_list_iter_next_put(iter)) >> >> In the long run, that should be called just drm_for_each_connector. >> >> The only case where you'd have to call put() explicitly is when you >> break out of the loop early. Otherwise all looping would be dead simple, >> without all the gets and puts, just like they are now. Perhaps the >> naming of the functions should be such that this is the most common >> case. Perhaps you don't actually need the versions with "manual" locking >> at all. > > I had this in an earlier iteration of this patch series. The implemenation > was somewhat misguided (as in it used srcu and some other wizzardry that I > now managed to remove), but otherwise was exactly what you've asking for > here. > > The amount of leaking was mindboggling. > > And that was only me being sloppyin in converting the piles of existing > loop, not even ongoing maintenance of new loops additions done by people > who're not well versed in the finer details of connector_list walking and > the refcounting dance involved. > > Given that I've concluded that hiding those details is a bad choice, and > to top it off the new code enforces matching get/put using lockdep. We do > pay a price in that simple loops become a bit more verbose, but > unfortunately there's no way to create something which is guarnateed to > get destructed when leaving a code block (unlike in C++). And without that > guarantee I don't think it'll be maintainable long-term. > > I expect that drm_for_each_connector will stay around for a long time > (maybe even forever). As long as your driver doesn't hotplug connectors, > it's perfectly fine. Only core + helpers + any driver supporting mst > really need to switch over. > > Overall not the prettiest thing, but still an acceptable tradeoff imo. Fair enough. Jani. -- Jani Nikula, Intel Open Source Technology Center
[PATCH v13 1/3] drm: Move locking into drm_debugfs_crtc_crc_add
On 14 December 2016 at 13:34, Tomeu Vizoso wrote: > There's no reason any more for callers of this function to take the lock > themselves, so just move the lock to the function to avoid confusion and > bugs when more callers are contributed. > > Signed-off-by: Tomeu Vizoso Reviewed-by: Emil Velikov -Emil
[PATCH v4 11/22] drm: omapdrm: Check the CRTC software state at enable/disable time
On 14/12/16 02:27, Laurent Pinchart wrote:
> The omapdrm DSS manager enable/disable operations check the DSS manager
> state to avoid double enabling/disabling. Check the CRTC software state
> instead to decrease the dependency of the DRM layer to the DSS layer.
> The dispc_mgr_is_enabled() function then be turned into a static
> function, but needs to be moved up in its compilation unit to avoid a
> forward declaration.
>
> Add a WARN_ON to catch double enable or disable that should be prevented
> by the DRM core and would be a clear sign of a bug. The warning should
> eventually be removed.
>
> Signed-off-by: Laurent Pinchart
> ---
> Changes since v3:
>
> - Replace the hardware state check with a software state check in
> omapdrm instead of moving it to omapdss.
> - Added a WARN_ON to catch impossible situations that would be a sign of
> a clear bug
> ---
> drivers/gpu/drm/omapdrm/dss/dispc.c | 27 +--
> drivers/gpu/drm/omapdrm/dss/omapdss.h | 1 -
> drivers/gpu/drm/omapdrm/omap_crtc.c | 6 +++---
> 3 files changed, 16 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/omapdrm/dss/dispc.c
> b/drivers/gpu/drm/omapdrm/dss/dispc.c
> index c839f6456db2..5554b72cf56a 100644
> --- a/drivers/gpu/drm/omapdrm/dss/dispc.c
> +++ b/drivers/gpu/drm/omapdrm/dss/dispc.c
> @@ -620,6 +620,19 @@ u32 dispc_wb_get_framedone_irq(void)
> return DISPC_IRQ_FRAMEDONEWB;
> }
>
> +void dispc_mgr_enable(enum omap_channel channel, bool enable)
> +{
> + mgr_fld_write(channel, DISPC_MGR_FLD_ENABLE, enable);
> + /* flush posted write */
> + mgr_fld_read(channel, DISPC_MGR_FLD_ENABLE);
> +}
> +EXPORT_SYMBOL(dispc_mgr_enable);
> +
> +static bool dispc_mgr_is_enabled(enum omap_channel channel)
> +{
> + return !!mgr_fld_read(channel, DISPC_MGR_FLD_ENABLE);
> +}
> +
> bool dispc_mgr_go_busy(enum omap_channel channel)
> {
> return mgr_fld_read(channel, DISPC_MGR_FLD_GO) == 1;
> @@ -2901,20 +2914,6 @@ enum omap_dss_output_id
> dispc_mgr_get_supported_outputs(enum omap_channel channe
> }
> EXPORT_SYMBOL(dispc_mgr_get_supported_outputs);
>
> -void dispc_mgr_enable(enum omap_channel channel, bool enable)
> -{
> - mgr_fld_write(channel, DISPC_MGR_FLD_ENABLE, enable);
> - /* flush posted write */
> - mgr_fld_read(channel, DISPC_MGR_FLD_ENABLE);
> -}
> -EXPORT_SYMBOL(dispc_mgr_enable);
> -
> -bool dispc_mgr_is_enabled(enum omap_channel channel)
> -{
> - return !!mgr_fld_read(channel, DISPC_MGR_FLD_ENABLE);
> -}
> -EXPORT_SYMBOL(dispc_mgr_is_enabled);
> -
dispc_mgr_is_enabled() is only used in a WARN, so we could even drop the
function, and then no moving is needed. But I'd rather leave that WARN
at least for now. It's quite good at catching bad SW. So:
Reviewed-by: Tomi Valkeinen
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161214/584be2ab/attachment-0001.sig>
[Intel-gfx] [PATCH 10/13] drm/i915: Use drm_connector_list_iter in debugfs
On Wed, 14 Dec 2016, Daniel Vetter wrote:
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 20bc04d5e617..7e25a7fffb1c 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -481,6 +481,9 @@ struct i915_hotplug {
> &(dev)->mode_config.connector_list, \
> base.head)
>
> +#define for_each_intel_connector_iter(intel_connector, iter) \
> + while ((intel_connector =
> to_intel_connector(drm_connector_list_iter_next(iter
I occasionally worry about us relying on the base struct always being
the first member. We don't even document this requirement anywhere.
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
[PATCH v2 0/7] Host1x IOMMU support + VIC support
On 14.12.2016 16:11, Daniel Vetter wrote: > On Wed, Dec 14, 2016 at 03:32:16PM +0200, Mikko Perttunen wrote: >> On 14.12.2016 15:05, Daniel Vetter wrote: >>> On Wed, Dec 14, 2016 at 02:41:28PM +0200, Mikko Perttunen wrote: On 14.12.2016 14:30, Daniel Vetter wrote: > On Wed, Dec 14, 2016 at 01:16:10PM +0200, Mikko Perttunen wrote: >> This series adds IOMMU support to Host1x and TegraDRM >> and adds support for the VIC (Video Image Compositor) >> host1x client. The series is available as a git repository at >> git://github.com/cyndis/linux.git; branch vic-2. >> >> A userspace test case for VIC can be found at >> https://github.com/cyndis/drm/tree/work/tegra. >> The testcase is in tests/tegra and is called submit_vic. >> The testcase/TRM include full headers and documentation >> to program the unit. The unit by itself, however, does not >> readily map to existing userspace library interfaces, so >> implementations for those are not provided. > > Afaik libva has an entire pile of post-processing support. Pretty sure > other video transcode libraries have similar interfaces, so should all be > possible to implement this. We don't have any actual video transcoding support though, so unless it's possible to just implement a part of libva and defer the rest to some CPU implementation, I don't see how this is useful. I suppose I could implement a GStreamer plugin for colorspace conversion or resizing, since those are very modular. >>> >>> Hm, I guess the question then is, how did that get enabled? >> >> What is "that"? I'm not exactly sure. >> >> Our architecture is such that there's the VIC that handles colorspace >> conversion, rescaling, blitting and can do some 2d postprocessing effects as >> well. >> >> Then there's the separate NVDEC that is a video bitstream decoder. There's >> no support for that at the moment. I am working on the IP side of that. >> >> The video processing pipeline is then such that NVDEC is fed the bitstream; >> NVDEC outputs a YUV picture in a specific format; VIC takes that YUV picture >> and converts/rescales it into the desired format. Or if we are encoding >> video, VIC takes your RGB image, converts it into a format that NVENC >> understands, and so on. >> >> So with just VIC support, I could implement some simple 2D things. I don't >> know if anyone would want to specifically use the VIC for those since >> applications already have fast CPU algorithms. For the video pipeline using >> VIC is nice since these units can synchronize work without CPU involvement >> and when you're already using NVDEC or NVENC it's barely any extra effort to >> involve VIC as well. It can also be useful in power usage sensitive >> situations, but we aren't really fit for those situations with the upstream >> kernel anyway :) > > Ah I thought the nvdec was already enabled, since for i915 that's how we > went about things (we have a pretty much exactly matching split in the > various video related engines). But if that's not there yet then no > worries, all fine. Ah, I see :) Yes, perhaps I should have described the situation and hardware in a bit more detail initially - sometimes I forget I'm writing to other people than Thierry as well.. something to keep in mind for future patches. > > Since you do seem to plan to enable everything anyway, might be worth it > to go directly with something like libva or libvdpau or whatever the cool > thing is. libva is my recommendation since it works on non-X11 too afaik, > but I have 0 clue. And might be worth it to check out whether you can't do > a super-basic libva driver that only does the post processing stuff. With > libva you can import/export images, so it might be possible even ... And > directly doing the full video engine support instead of a one-off in > gstreamer sounds more sensible to me. > -Daniel > I'll take a look at libva. Thanks, Mikko.
[Bug 98897] Macbook pro 11,5 screen flicker when AC adapter plugged in
https://bugs.freedesktop.org/show_bug.cgi?id=98897 --- Comment #14 from Cédric Le Goater --- (In reply to Michel Dänzer from comment #10) > If you can't or don't want to bisect, there are only 4 radeon driver commits > between 4.8.6 and 4.8.7, so it shouldn't take long to try manually reverting > each of those. > https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/ > ?h=linux-4.8.y&id=e136de5d733161fdfd203f23b448434170d189ea seems like a good > candidate, since it's clock related and explicitly references your GPU in > the code. Hi, I have reverted this commit on a 4.8.14 and the flickering stopped. C. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161214/03d72de1/attachment.html>
[PATCH libdrm] xf86drm: fix null termination of string buffer
On 12/14/2016 12:23 PM, Emil Velikov wrote: > Did you see this causing issues in practise ? > > We use a combination of strstr to strip any unwanted starting data, > and sscanf which [should] trim any trailing garbage. > That aside, your patch provides an extra bit of robustness which is > always nice ^_^ No, I've not encountering any problem in practice. I completely agree with you. > Barring any objections I'll commit this in a few days. Thank you for your prompt reply!
[PATCH v2 4/4] ASoC: hdmi-codec: add channel mapping control
Add user interface to provide channel mapping.
In a first step this control is read only.
As TLV type, the control provides all configuration available for
HDMI sink(ELD), and provides current channel mapping selected by codec
based on ELD and number of channels specified by user on open.
When control is called before the number of the channel is specified
(i.e. hw_params is set), it returns all channels set to UNKNOWN.
Signed-off-by: Arnaud Pouliquen
---
sound/soc/codecs/hdmi-codec.c | 310 +-
1 file changed, 309 insertions(+), 1 deletion(-)
diff --git a/sound/soc/codecs/hdmi-codec.c b/sound/soc/codecs/hdmi-codec.c
index f27d115..01c837c 100644
--- a/sound/soc/codecs/hdmi-codec.c
+++ b/sound/soc/codecs/hdmi-codec.c
@@ -18,12 +18,131 @@
#include
#include
#include
+#include
#include
#include
#include
#include /* This is only to get MAX_ELD_BYTES */
+#define HDMI_MAX_SPEAKERS 8
+
+struct hdmi_codec_channel_map_table {
+ unsigned char map; /* ALSA API channel map position */
+ unsigned long spk_mask; /* speaker position bit mask */
+};
+
+/*
+ * CEA speaker placement for HDMI 1.4:
+ *
+ * FL FLC FC FRC FR FRW
+ *
+ * LFE
+ *
+ * RL RLC RC RRC RR
+ *
+ * Speaker placement has to be extended to support HDMI 2.0
+ */
+enum hdmi_codec_cea_spk_placement {
+ FL = BIT(0), /* Front Left */
+ FC = BIT(1), /* Front Center */
+ FR = BIT(2), /* Front Right */
+ FLC = BIT(3), /* Front Left Center*/
+ FRC = BIT(4), /* Front Right Center */
+ RL = BIT(5), /* Rear Left*/
+ RC = BIT(6), /* Rear Center */
+ RR = BIT(7), /* Rear Right */
+ RLC = BIT(8), /* Rear Left Center */
+ RRC = BIT(9), /* Rear Right Center*/
+ LFE = BIT(10), /* Low Frequency Effect */
+};
+
+static const struct hdmi_codec_channel_map_table hdmi_codec_map_table[] = {
+ { SNDRV_CHMAP_FL, FL },
+ { SNDRV_CHMAP_FR, FR },
+ { SNDRV_CHMAP_RL, RL },
+ { SNDRV_CHMAP_RR, RR },
+ { SNDRV_CHMAP_LFE, LFE },
+ { SNDRV_CHMAP_FC, FC },
+ { SNDRV_CHMAP_RLC, RLC },
+ { SNDRV_CHMAP_RRC, RRC },
+ { SNDRV_CHMAP_RC, RC },
+ { SNDRV_CHMAP_FLC, FLC },
+ { SNDRV_CHMAP_FRC, FRC },
+ {} /* terminator */
+};
+
+/*
+ * cea Speaker allocation structure
+ */
+struct hdmi_codec_cea_spk_alloc {
+ const int ca_id;
+ const unsigned long speakers[HDMI_MAX_SPEAKERS];
+
+ /* Derived values, computed during init */
+ unsigned int channels;
+ unsigned long spks_mask;
+ unsigned long spk_na_mask;
+};
+
+/* default HDMI channel maps is stereo */
+const struct snd_pcm_chmap_elem hdmi_codec_stereo_chmaps[] = {
+ { .channels = 2,
+ .map = { SNDRV_CHMAP_FL, SNDRV_CHMAP_FR } },
+ { }
+};
+
+/*
+ * hdmi_codec_channel_alloc: speaker configuration available for CEA
+ *
+ * This is an ordered list!
+ * The preceding ones have better chances to be selected by
+ * hdmi_codec_get_ch_alloc_table_idx().
+ */
+static struct hdmi_codec_cea_spk_alloc hdmi_codec_channel_alloc[] = {
+{ .ca_id = 0x00, .speakers = { 0,0, 0, 0, 0,0, FR, FL } },
+/* 2.1 */
+{ .ca_id = 0x01, .speakers = { 0,0, 0, 0, 0, LFE, FR, FL } },
+/* Dolby Surround */
+{ .ca_id = 0x02, .speakers = { 0,0, 0, 0, FC,0, FR, FL } },
+/* surround51 */
+{ .ca_id = 0x0b, .speakers = { 0,0, RR, RL, FC, LFE, FR, FL } },
+/* surround40 */
+{ .ca_id = 0x08, .speakers = { 0,0, RR, RL, 0,0, FR, FL } },
+/* surround41 */
+{ .ca_id = 0x09, .speakers = { 0,0, RR, RL, 0, LFE, FR, FL } },
+/* surround50 */
+{ .ca_id = 0x0a, .speakers = { 0,0, RR, RL, FC,0, FR, FL } },
+/* 6.1 */
+{ .ca_id = 0x0f, .speakers = { 0, RC, RR, RL, FC, LFE, FR, FL } },
+/* surround71 */
+{ .ca_id = 0x13, .speakers = { RRC, RLC, RR, RL, FC, LFE, FR, FL } },
+
+{ .ca_id = 0x03, .speakers = { 0,0, 0, 0, FC, LFE, FR, FL } },
+{ .ca_id = 0x04, .speakers = { 0,0, 0, RC, 0,0, FR, FL } },
+{ .ca_id = 0x05, .speakers = { 0,0, 0, RC, 0, LFE, FR, FL } },
+{ .ca_id = 0x06, .speakers = { 0,0, 0, RC, FC,0, FR, FL } },
+{ .ca_id = 0x07, .speakers = { 0,0, 0, RC, FC, LFE, FR, FL } },
+{ .ca_id = 0x0c, .speakers = { 0, RC, RR, RL, 0,0, FR, FL } },
+{ .ca_id = 0x0d, .speakers = { 0, RC, RR, RL, 0, LFE, FR, FL } },
+{ .ca_id = 0x0e, .speakers = { 0, RC, RR, RL, FC,0, FR, FL } },
+{ .ca_id = 0x10, .speakers = { RRC, RLC, RR, RL, 0,0, FR, FL } },
+{ .ca_id = 0x11, .speakers = { RRC, RLC, RR, RL, 0, LFE, FR, FL } },
+{ .ca_id = 0x12, .speakers = { RRC, RLC
[PATCH v2 3/4] ASoC: core: add optional pcm_new callback for DAI driver
During probe, DAIs can need to perform some actions that requests
the knowledge of the pcm runtime handle.
The callback is called during DAIs linking, after PCM device creation.
For instance this can be used to add relation ship between a DAI pcm
control and the pcm device.
Signed-off-by: Arnaud Pouliquen
---
include/sound/soc-dai.h | 3 +++
sound/soc/soc-core.c| 28
2 files changed, 31 insertions(+)
diff --git a/include/sound/soc-dai.h b/include/sound/soc-dai.h
index 964b7de..960990e 100644
--- a/include/sound/soc-dai.h
+++ b/include/sound/soc-dai.h
@@ -231,6 +231,9 @@ struct snd_soc_dai_driver {
int (*resume)(struct snd_soc_dai *dai);
/* compress dai */
int (*compress_new)(struct snd_soc_pcm_runtime *rtd, int num);
+ /* Optional Callback used at pcm creation*/
+ int (*pcm_new)(struct snd_soc_pcm_runtime *rtd,
+ struct snd_soc_dai *dai);
/* DAI is also used for the control bus */
bool bus_control;
diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c
index 4afa8db..d3a6c22 100644
--- a/sound/soc/soc-core.c
+++ b/sound/soc/soc-core.c
@@ -1552,6 +1552,27 @@ static int soc_probe_dai(struct snd_soc_dai *dai, int
order)
return 0;
}
+static int soc_link_dai_pcm_new(struct snd_soc_dai **dais, int num_dais,
+ struct snd_soc_pcm_runtime *rtd)
+{
+ int i, ret = 0;
+
+ for (i = 0; i < num_dais; ++i) {
+ struct snd_soc_dai_driver *drv = dais[i]->driver;
+
+ if (!rtd->dai_link->no_pcm && drv->pcm_new)
+ ret = drv->pcm_new(rtd, dais[i]);
+ if (ret < 0) {
+ dev_err(dais[i]->dev,
+ "ASoC: Failed to bind %s with pcm device\n",
+ dais[i]->name);
+ return ret;
+ }
+ }
+
+ return 0;
+}
+
static int soc_link_dai_widgets(struct snd_soc_card *card,
struct snd_soc_dai_link *dai_link,
struct snd_soc_pcm_runtime *rtd)
@@ -1663,6 +1684,13 @@ static int soc_probe_link_dais(struct snd_soc_card *card,
dai_link->stream_name, ret);
return ret;
}
+ ret = soc_link_dai_pcm_new(&cpu_dai, 1, rtd);
+ if (ret < 0)
+ return ret;
+ ret = soc_link_dai_pcm_new(rtd->codec_dais,
+ rtd->num_codecs, rtd);
+ if (ret < 0)
+ return ret;
} else {
INIT_DELAYED_WORK(&rtd->delayed_work,
codec2codec_close_delayed_work);
--
1.9.1
[PATCH v2 2/4] ALSA pcm: allow non constant snd_pcm_chmap_elem
For HDMI, channel mapping can be retrieved from ELD. In this case mapping
can change during runtime (plug/unplug).
This patch suppresses the 'const' property of the struct chmap.
Signed-off-by: Arnaud Pouliquen
---
include/sound/pcm.h | 4 ++--
sound/core/pcm_lib.c | 6 +++---
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/include/sound/pcm.h b/include/sound/pcm.h
index af1fb37..3b459a3 100644
--- a/include/sound/pcm.h
+++ b/include/sound/pcm.h
@@ -1355,7 +1355,7 @@ struct snd_pcm_chmap {
struct snd_pcm *pcm;/* assigned PCM instance */
int stream; /* PLAYBACK or CAPTURE */
struct snd_kcontrol *kctl;
- const struct snd_pcm_chmap_elem *chmap;
+ struct snd_pcm_chmap_elem *chmap;
unsigned int max_channels;
unsigned int channel_mask; /* optional: active channels bitmask */
void *private_data; /* optional: private data pointer */
@@ -1387,7 +1387,7 @@ extern const struct snd_pcm_chmap_elem
snd_pcm_alt_chmaps[];
#define SND_PCM_CHMAP_MASK_2468(SND_PCM_CHMAP_MASK_246 | (1U << 8))
int snd_pcm_add_chmap_ctls(struct snd_pcm *pcm, int stream,
- const struct snd_pcm_chmap_elem *chmap,
+ struct snd_pcm_chmap_elem *chmap,
int max_channels,
unsigned long private_value,
struct snd_pcm_chmap **info_ret);
diff --git a/sound/core/pcm_lib.c b/sound/core/pcm_lib.c
index bb12615..252a498 100644
--- a/sound/core/pcm_lib.c
+++ b/sound/core/pcm_lib.c
@@ -2489,7 +2489,7 @@ static int pcm_chmap_ctl_get(struct snd_kcontrol
*kcontrol,
struct snd_pcm_chmap *info = snd_kcontrol_chip(kcontrol);
unsigned int idx = snd_ctl_get_ioffidx(kcontrol, &ucontrol->id);
struct snd_pcm_substream *substream;
- const struct snd_pcm_chmap_elem *map;
+ struct snd_pcm_chmap_elem *map;
if (snd_BUG_ON(!info->chmap))
return -EINVAL;
@@ -2519,7 +2519,7 @@ static int pcm_chmap_ctl_tlv(struct snd_kcontrol
*kcontrol, int op_flag,
unsigned int size, unsigned int __user *tlv)
{
struct snd_pcm_chmap *info = snd_kcontrol_chip(kcontrol);
- const struct snd_pcm_chmap_elem *map;
+ struct snd_pcm_chmap_elem *map;
unsigned int __user *dst;
int c, count = 0;
@@ -2578,7 +2578,7 @@ static void pcm_chmap_ctl_private_free(struct
snd_kcontrol *kcontrol)
* Return: Zero if successful, or a negative error value.
*/
int snd_pcm_add_chmap_ctls(struct snd_pcm *pcm, int stream,
- const struct snd_pcm_chmap_elem *chmap,
+ struct snd_pcm_chmap_elem *chmap,
int max_channels,
unsigned long private_value,
struct snd_pcm_chmap **info_ret)
--
1.9.1
[PATCH v2 1/4] DRM: add help to get ELD speaker allocation
Add helper to allow users to retrieve the speaker allocations without
knowledge of the ELD structure.
Signed-off-by: Arnaud Pouliquen
---
include/drm/drm_edid.h | 13 +
1 file changed, 13 insertions(+)
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index 919933d..0706cc6 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -245,6 +245,7 @@ struct detailed_timing {
# define DRM_ELD_AUD_SYNCH_DELAY_MAX 0xfa/* 500 ms */
#define DRM_ELD_SPEAKER7
+# define DRM_ELD_SPEAKER_MASK 0x7f
# define DRM_ELD_SPEAKER_RLRC (1 << 6)
# define DRM_ELD_SPEAKER_FLRC (1 << 5)
# define DRM_ELD_SPEAKER_RC(1 << 4)
@@ -412,6 +413,18 @@ static inline int drm_eld_size(const uint8_t *eld)
}
/**
+ * drm_eld_get_spk_alloc - Get speaker allocation
+ * @eld: pointer to an ELD memory structure
+ *
+ * The returned value is the speakers mask. User has to use %DRM_ELD_SPEAKER
+ * field definitions to identify speakers.
+ */
+static inline u8 drm_eld_get_spk_alloc(const uint8_t *eld)
+{
+ return eld[DRM_ELD_SPEAKER] & DRM_ELD_SPEAKER_MASK;
+}
+
+/**
* drm_eld_get_conn_type - Get device type hdmi/dp connected
* @eld: pointer to an ELD memory structure
*
--
1.9.1
[PATCH v2 0/4] Generic HDMI codec: Add channel mapping control
Aim of this patch is to add 'Playback Channel Map' control to export audio capabilities in term of HDMI sink speakers allocation. V2: In this version I use chmap helper functions from pcm_lib.c. It is quite tricky to use it from ASoC due to the relation chip of the controls with the pcm runtime. After several tries, my conclusion is that it must be handled in ASoC DAI driver. Main reason is that the DAI driver can not provide snd_pcm_chmap struct through kcontrol structure. But this induces that soc-core provides pcm runtime structure to DAI driver during probe. Base on this conclusion. I reworked my patches by adding 2 new patches in patch-set 1) ALSA pcm: allow non constant snd_pcm_chmap_elem This patch allows to handle non constant channel mapping. As ELD information can change during runtime it is mandatory to properly handle the feature. In term of compatibility with legacy it should be straightforward, as update just consists in suppressing the 'const' constraint. 2) ASoC: core: add optional pcm_new callback for DAI driver This is the only way i found to be able to use snd_pcm_add_chmap_ctls and associated controls helper functions. From my point of view, this is the more simple way to add relationship between DAI and associated pcm devices. Notice that this patch, if accepted, makes the following one obsolete, as it also answer to the associated topic: [PATCH v5 0/2] ALSA controls management using index/device/sub-devices fields (http://www.spinics.net/lists/alsa-devel/msg57639.html). If you estimate that this it not reasonable i will come back to my first version. V1: This patch follow discussion initiates here: [RFC] ASOC: HDMI audio info frame speaker allocation http://www.spinics.net/lists/alsa-devel/msg57363.html The code is fully inspired from HDA driver. On hw_param, HDMI sink speaker capabilities are exported via TLV ops and a CEA allocation is choson, based on ELD information and the number of channels requested by user. Mains differences with HDA implementation are: - Control is read only - Channel swap is not supported. Consequence is that unused channel in the mid of CEA audio infoframe channel mapping are considered as active. example for channel allocation 0x02: FL, FR, 0, FC) This configuration is only available for a 4 channels stream. - Channel allocation table has been reordered and HDMI 2.0 is not supported. Arnaud Pouliquen (4): DRM: add help to get ELD speaker allocation ALSA pcm: allow non constant snd_pcm_chmap_elem ASoC: core: add optional pcm_new callback for DAI driver ASoC: hdmi-codec: add channel mapping control include/drm/drm_edid.h| 13 ++ include/sound/pcm.h | 4 +- include/sound/soc-dai.h | 3 + sound/core/pcm_lib.c | 6 +- sound/soc/codecs/hdmi-codec.c | 310 +- sound/soc/soc-core.c | 28 6 files changed, 358 insertions(+), 6 deletions(-) -- 1.9.1
[RFC PATCH 4/4] staging: android: ion: Call dma_map_sg for syncing and mapping
Technically, calling dma_buf_map_attachment should return a buffer
properly dma_mapped. Add calls to dma_map_sg to begin_cpu_access to
ensure this happens. As a side effect, this lets Ion buffers take
advantage of the dma_buf sync ioctls.
Not-signed-off-by: Laura Abbott
---
drivers/staging/android/ion/ion.c | 61 ++-
1 file changed, 47 insertions(+), 14 deletions(-)
diff --git a/drivers/staging/android/ion/ion.c
b/drivers/staging/android/ion/ion.c
index 86dba07..5177d79 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -776,6 +776,11 @@ static struct sg_table *dup_sg_table(struct sg_table
*table)
return new_table;
}
+static void free_duped_table(struct sg_table *table)
+{
+ sg_free_table(table);
+ kfree(table);
+}
static struct sg_table *ion_map_dma_buf(struct dma_buf_attachment *attachment,
enum dma_data_direction direction)
@@ -784,15 +789,29 @@ static struct sg_table *ion_map_dma_buf(struct
dma_buf_attachment *attachment,
struct ion_buffer *buffer = dmabuf->priv;
struct sg_table *table;
- return dup_sg_table(buffer->sg_table);
+ /*
+* TODO: Need to sync wrt CPU or device completely owning?
+*/
+
+ table = dup_sg_table(buffer->sg_table);
+
+ if (!dma_map_sg(attachment->dev, table->sgl, table->nents,
+ direction)){
+ ret = -ENOMEM;
+ goto err;
+ }
+
+err:
+ free_duped_table(table);
+ return ERR_PTR(ret);
}
static void ion_unmap_dma_buf(struct dma_buf_attachment *attachment,
struct sg_table *table,
enum dma_data_direction direction)
{
- sg_free_table(table);
- kfree(table);
+ dma_unmap_sg(attachment->dev, table->sgl, table->nents, direction);
+ free_duped_table(table);
}
struct ion_vma_list {
@@ -889,16 +908,24 @@ static int ion_dma_buf_begin_cpu_access(struct dma_buf
*dmabuf,
struct ion_buffer *buffer = dmabuf->priv;
void *vaddr;
- if (!buffer->heap->ops->map_kernel) {
- pr_err("%s: map kernel is not implemented by this heap.\n",
- __func__);
- return -ENODEV;
+ /*
+* TODO: Move this elsewhere because we don't always need a vaddr
+*/
+ if (buffer->heap->ops->map_kernel) {
+ mutex_lock(&buffer->lock);
+ vaddr = ion_buffer_kmap_get(buffer);
+ mutex_unlock(&buffer->lock);
}
- mutex_lock(&buffer->lock);
- vaddr = ion_buffer_kmap_get(buffer);
- mutex_unlock(&buffer->lock);
- return PTR_ERR_OR_ZERO(vaddr);
+ /*
+* Close enough right now? Flag to skip sync?
+*/
+ if (!dma_map_sg(buffer->dev->dev.this_device, buffer->sg_table->sgl,
+ buffer->sg_table->nents,
+DMA_BIDIRECTIONAL))
+ return -ENOMEM;
+
+ return 0;
}
static int ion_dma_buf_end_cpu_access(struct dma_buf *dmabuf,
@@ -906,9 +933,15 @@ static int ion_dma_buf_end_cpu_access(struct dma_buf
*dmabuf,
{
struct ion_buffer *buffer = dmabuf->priv;
- mutex_lock(&buffer->lock);
- ion_buffer_kmap_put(buffer);
- mutex_unlock(&buffer->lock);
+ if (buffer->heap->ops->map_kernel) {
+ mutex_lock(&buffer->lock);
+ ion_buffer_kmap_put(buffer);
+ mutex_unlock(&buffer->lock);
+ }
+
+ dma_unmap_sg(buffer->dev->dev.this_device, buffer->sg_table->sgl,
+ buffer->sg_table->nents,
+ DMA_BIDIRECTIONAL);
return 0;
}
--
2.7.4
[RFC PATCH 3/4] staging: android: ion: Remove page faulting support
Unclear if this is wanted or needed?
Not-signed-off-by: Laura Abbott
---
drivers/staging/android/ion/ion.c | 74 ---
1 file changed, 74 deletions(-)
diff --git a/drivers/staging/android/ion/ion.c
b/drivers/staging/android/ion/ion.c
index 76b874a0..86dba07 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -41,37 +41,11 @@
#include "ion_priv.h"
#include "compat_ion.h"
-bool ion_buffer_fault_user_mappings(struct ion_buffer *buffer)
-{
- return (buffer->flags & ION_FLAG_CACHED) &&
- !(buffer->flags & ION_FLAG_CACHED_NEEDS_SYNC);
-}
-
bool ion_buffer_cached(struct ion_buffer *buffer)
{
return !!(buffer->flags & ION_FLAG_CACHED);
}
-static inline struct page *ion_buffer_page(struct page *page)
-{
- return (struct page *)((unsigned long)page & ~(1UL));
-}
-
-static inline bool ion_buffer_page_is_dirty(struct page *page)
-{
- return !!((unsigned long)page & 1UL);
-}
-
-static inline void ion_buffer_page_dirty(struct page **page)
-{
- *page = (struct page *)((unsigned long)(*page) | 1UL);
-}
-
-static inline void ion_buffer_page_clean(struct page **page)
-{
- *page = (struct page *)((unsigned long)(*page) & ~(1UL));
-}
-
/* this function should only be called while dev->lock is held */
static void ion_buffer_add(struct ion_device *dev,
struct ion_buffer *buffer)
@@ -139,25 +113,6 @@ static struct ion_buffer *ion_buffer_create(struct
ion_heap *heap,
buffer->dev = dev;
buffer->size = len;
- if (ion_buffer_fault_user_mappings(buffer)) {
- int num_pages = PAGE_ALIGN(buffer->size) / PAGE_SIZE;
- struct scatterlist *sg;
- int i, j, k = 0;
-
- buffer->pages = vmalloc(sizeof(struct page *) * num_pages);
- if (!buffer->pages) {
- ret = -ENOMEM;
- goto err1;
- }
-
- for_each_sg(table->sgl, sg, table->nents, i) {
- struct page *page = sg_page(sg);
-
- for (j = 0; j < sg->length / PAGE_SIZE; j++)
- buffer->pages[k++] = page++;
- }
- }
-
buffer->dev = dev;
buffer->size = len;
INIT_LIST_HEAD(&buffer->vmas);
@@ -845,25 +800,6 @@ struct ion_vma_list {
struct vm_area_struct *vma;
};
-static int ion_vm_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
-{
- struct ion_buffer *buffer = vma->vm_private_data;
- unsigned long pfn;
- int ret;
-
- mutex_lock(&buffer->lock);
- ion_buffer_page_dirty(buffer->pages + vmf->pgoff);
- BUG_ON(!buffer->pages || !buffer->pages[vmf->pgoff]);
-
- pfn = page_to_pfn(ion_buffer_page(buffer->pages[vmf->pgoff]));
- ret = vm_insert_pfn(vma, (unsigned long)vmf->virtual_address, pfn);
- mutex_unlock(&buffer->lock);
- if (ret)
- return VM_FAULT_ERROR;
-
- return VM_FAULT_NOPAGE;
-}
-
static void ion_vm_open(struct vm_area_struct *vma)
{
struct ion_buffer *buffer = vma->vm_private_data;
@@ -900,7 +836,6 @@ static void ion_vm_close(struct vm_area_struct *vma)
static const struct vm_operations_struct ion_vma_ops = {
.open = ion_vm_open,
.close = ion_vm_close,
- .fault = ion_vm_fault,
};
static int ion_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma)
@@ -914,15 +849,6 @@ static int ion_mmap(struct dma_buf *dmabuf, struct
vm_area_struct *vma)
return -EINVAL;
}
- if (ion_buffer_fault_user_mappings(buffer)) {
- vma->vm_flags |= VM_IO | VM_PFNMAP | VM_DONTEXPAND |
- VM_DONTDUMP;
- vma->vm_private_data = buffer;
- vma->vm_ops = &ion_vma_ops;
- ion_vm_open(vma);
- return 0;
- }
-
if (!(buffer->flags & ION_FLAG_CACHED))
vma->vm_page_prot = pgprot_writecombine(vma->vm_page_prot);
--
2.7.4
[RFC PATCH 2/4] staging: android: ion: Duplicate sg_table
Ion currently returns a single sg_table on each dma_map call. This is
incorrect for later usage.
Not-signed-off-by: Laura Abbott
---
drivers/staging/android/ion/ion.c | 32 +++-
1 file changed, 31 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/android/ion/ion.c
b/drivers/staging/android/ion/ion.c
index 8dd0932..76b874a0 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -795,19 +795,49 @@ void ion_client_destroy(struct ion_client *client)
}
EXPORT_SYMBOL(ion_client_destroy);
+static struct sg_table *dup_sg_table(struct sg_table *table)
+{
+ struct sg_table *new_table;
+ int ret, i;
+ struct scatterlisg *sg, *new_sg;
+
+ new_table = kzalloc(sizeof(*new_table), GFP_KERNEL);
+ if (!new_table)
+ return ERR_PTR(-ENOMEM);
+
+ ret = sg_alloc_table(new_table, table->nents, GFP_KERNEL);
+ if (ret) {
+ kfree(table);
+ return ERR_PTR(-ENOMEM);
+ }
+
+ new_sg = new_table->sgl;
+ for_each_sg(table->sgl, sg, table->nents, i) {
+ memcpy(new_sg, sg, sizeof(*sg));
+ sg->dma_address = 0;
+ new_sg = sg_next(new_sg);
+ }
+
+ return new_table;
+}
+
+
static struct sg_table *ion_map_dma_buf(struct dma_buf_attachment *attachment,
enum dma_data_direction direction)
{
struct dma_buf *dmabuf = attachment->dmabuf;
struct ion_buffer *buffer = dmabuf->priv;
+ struct sg_table *table;
- return buffer->sg_table;
+ return dup_sg_table(buffer->sg_table);
}
static void ion_unmap_dma_buf(struct dma_buf_attachment *attachment,
struct sg_table *table,
enum dma_data_direction direction)
{
+ sg_free_table(table);
+ kfree(table);
}
struct ion_vma_list {
--
2.7.4
[RFC PATCH 1/4] staging: android: ion: Some cleanup
- dmap_cnt isn't used. Remove it.
- Ion has been using dma apis incorrectly to sync the caches.
Remove bad usage in preparation for something better.
- The alignment field doesn't actually change the alignment of an
allocation, it only serves as an error check. This is basically
pointless. Remove the field.
Not-signed-off-by: Laura Abbott
---
drivers/staging/android/ion/ion-ioctl.c | 6 --
drivers/staging/android/ion/ion.c | 92 ++---
drivers/staging/android/ion/ion.h | 5 +-
drivers/staging/android/ion/ion_carveout_heap.c | 16 +
drivers/staging/android/ion/ion_chunk_heap.c| 15 +---
drivers/staging/android/ion/ion_cma_heap.c | 5 +-
drivers/staging/android/ion/ion_page_pool.c | 3 -
drivers/staging/android/ion/ion_priv.h | 4 +-
drivers/staging/android/ion/ion_system_heap.c | 14 +---
9 files changed, 16 insertions(+), 144 deletions(-)
diff --git a/drivers/staging/android/ion/ion-ioctl.c
b/drivers/staging/android/ion/ion-ioctl.c
index 7e7431d..a27db9d 100644
--- a/drivers/staging/android/ion/ion-ioctl.c
+++ b/drivers/staging/android/ion/ion-ioctl.c
@@ -95,7 +95,6 @@ long ion_ioctl(struct file *filp, unsigned int cmd, unsigned
long arg)
struct ion_handle *handle;
handle = ion_alloc(client, data.allocation.len,
- data.allocation.align,
data.allocation.heap_id_mask,
data.allocation.flags);
if (IS_ERR(handle))
@@ -146,11 +145,6 @@ long ion_ioctl(struct file *filp, unsigned int cmd,
unsigned long arg)
data.handle.handle = handle->id;
break;
}
- case ION_IOC_SYNC:
- {
- ret = ion_sync_for_device(client, data.fd.fd);
- break;
- }
case ION_IOC_CUSTOM:
{
if (!dev->custom_ioctl)
diff --git a/drivers/staging/android/ion/ion.c
b/drivers/staging/android/ion/ion.c
index d5cc307..8dd0932 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -102,7 +102,6 @@ static void ion_buffer_add(struct ion_device *dev,
static struct ion_buffer *ion_buffer_create(struct ion_heap *heap,
struct ion_device *dev,
unsigned long len,
- unsigned long align,
unsigned long flags)
{
struct ion_buffer *buffer;
@@ -118,15 +117,14 @@ static struct ion_buffer *ion_buffer_create(struct
ion_heap *heap,
buffer->flags = flags;
kref_init(&buffer->ref);
- ret = heap->ops->allocate(heap, buffer, len, align, flags);
+ ret = heap->ops->allocate(heap, buffer, len, flags);
if (ret) {
if (!(heap->flags & ION_HEAP_FLAG_DEFER_FREE))
goto err2;
ion_heap_freelist_drain(heap, 0);
- ret = heap->ops->allocate(heap, buffer, len, align,
- flags);
+ ret = heap->ops->allocate(heap, buffer, len, flags);
if (ret)
goto err2;
}
@@ -400,7 +398,7 @@ static int ion_handle_add(struct ion_client *client, struct
ion_handle *handle)
}
struct ion_handle *ion_alloc(struct ion_client *client, size_t len,
-size_t align, unsigned int heap_id_mask,
+unsigned int heap_id_mask,
unsigned int flags)
{
struct ion_handle *handle;
@@ -409,8 +407,8 @@ struct ion_handle *ion_alloc(struct ion_client *client,
size_t len,
struct ion_heap *heap;
int ret;
- pr_debug("%s: len %zu align %zu heap_id_mask %u flags %x\n", __func__,
-len, align, heap_id_mask, flags);
+ pr_debug("%s: len %zu heap_id_mask %u flags %x\n", __func__,
+len, heap_id_mask, flags);
/*
* traverse the list of heaps available in this system in priority
* order. If the heap type is supported by the client, and matches the
@@ -427,7 +425,7 @@ struct ion_handle *ion_alloc(struct ion_client *client,
size_t len,
/* if the caller didn't specify this heap id */
if (!((1 << heap->id) & heap_id_mask))
continue;
- buffer = ion_buffer_create(heap, dev, len, align, flags);
+ buffer = ion_buffer_create(heap, dev, len, flags);
if (!IS_ERR(buffer))
break;
}
@@ -797,17 +795,12 @@ void ion_client_destroy(struct ion_client *client)
}
EXPORT_SYMBOL(ion_client_destroy);
-static void ion_buffer_sync_for_device(struct ion_buffer *buffer,
- struct device *dev,
-
[RFC PATCH 0/4] Ion caching (yet again) proof of concept
Hi,
I've been (once again) looking at alternate caching models for Ion. Part of
this work is also to make Ion fit better in to the dma_buf model.
Ion is a bit unusual for dma_buf. Most drivers that support dma_buf have two
parts: exporting buffers that a driver allocates and importing buffers
allocated elsewhere for use by the driver. Ion is basically designed to export
only and not import buffers from other drivers (the need for import is also
on my TODO list) Even more unusual, there is no actual 'driver' to map into.
Ion currently does nothing except pass back the same sg_table each time without
calling dma_map.
The description of the .map_dma_buf function in dma_buf_ops
* @map_dma_buf: returns list of scatter pages allocated, increases usecount
* of the buffer. Requires atleast one attach to be called
* before. Returned sg list should already be mapped into
* _device_ address space. This call may sleep. May also return
* -EINTR. Should return -EINVAL if attach hasn't been called yet.
So Ion is definitely not doing this correctly. This ties back into correcting
the caching model. If we call dma_map_sg/dma_unmap_sg with begin_cpu_access,
this should be enough to allow the caches to always be properly synchronized
and means we can drop the various dma_sync calls floating around. This is going
to violate one of the big fat comments in ion_buffer_create
/*
* this will set up dma addresses for the sglist -- it is not
* technically correct as per the dma api -- a specific
* device isn't really taking ownership here. However, in practice on
* our systems the only dma_address space is physical addresses.
* Additionally, we can't afford the overhead of invalidating every
* allocation via dma_map_sg. The implicit contract here is that
* memory coming from the heaps is ready for dma, ie if it has a
* cached mapping that mapping has been invalidated
*/
for_each_sg(buffer->sg_table->sgl, sg, buffer->sg_table->nents, i) {
sg_dma_address(sg) = sg_phys(sg);
sg_dma_len(sg) = sg->length;
}
The overhead of invalidating is a valid concern. I'm hoping that the
architecture has either evolved such that this won't be a problem or we can
figure out some clever use of DMA_ATTR_SKIP_CPU_SYNC.
As part of this, I'm considering dropping the fault synchronization. If we have
explicit use begin_cpu_access and use of the dma_buf sync ioctls, I don't think
it should be necessary.
I have a 'pre-RFC' tree at
https://pagure.io/kernel-ion/branch/ion_cache_proof_dec14
Yes, the patches are not bisectable and there is more to be done. These have
been compile tested only and haven't been hooked up to anything to actually run
(another actually big TODO). I'm mostly looking for feedback if this looks like
the right direction and if there are going to be major problems with this
approach. I don't actually anticipate this getting merged into
drivers/staging/android/ion but this is the easiest way to continue discussion.
Thanks,
Laura
Laura Abbott (4):
staging: android: ion: Some cleanup
staging: android: ion: Duplicate sg_table
staging: android: ion: Remove page faulting support
staging: android: ion: Call dma_map_sg for syncing and mapping
drivers/staging/android/ion/ion-ioctl.c | 6 -
drivers/staging/android/ion/ion.c | 251
drivers/staging/android/ion/ion.h | 5 +-
drivers/staging/android/ion/ion_carveout_heap.c | 16 +-
drivers/staging/android/ion/ion_chunk_heap.c| 15 +-
drivers/staging/android/ion/ion_cma_heap.c | 5 +-
drivers/staging/android/ion/ion_page_pool.c | 3 -
drivers/staging/android/ion/ion_priv.h | 4 +-
drivers/staging/android/ion/ion_system_heap.c | 14 +-
9 files changed, 90 insertions(+), 229 deletions(-)
--
2.7.4
[PATCH libdrm] autogen.sh: set format.subjectPrefix and sendemail.to if needed
On 13/12/16 10:09 PM, Emil Velikov wrote: > Just set the rules automatically rather than asking each contributor to > update thing locally. > > Signed-off-by: Emil Velikov > --- > autogen.sh | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/autogen.sh b/autogen.sh > index c896097..e936f04 100755 > --- a/autogen.sh > +++ b/autogen.sh > @@ -9,6 +9,12 @@ cd "$srcdir" > autoreconf --force --verbose --install || exit 1 > cd "$ORIGDIR" || exit $? > > +git config --local --get format.subjectPrefix || > +git config --local format.subjectPrefix "PATCH libdrm" > + > +git config --local --get sendemail.to || > +git config --local sendemail.to "dri-devel at lists.freedesktop.org" This is nice in general, but e.g. patches for the amdgpu/radeon subdirectories should go to the amd-gfx list instead, and possibly also have a different subject prefix. But maybe this is a good starting point anyway. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
[PATCH 1/1] drm/amd/amdgpu: get maximum and used UVD handles (v3)
On 12 December 2016 at 18:49, wrote:
> From: Arindam Nath
>
> Change History
> --
>
> v3: changes suggested by Christian
> - Add a check for UVD IP block using AMDGPU_HW_IP_UVD
> query type.
> - Add a check for asic_type to be less than
> CHIP_POLARIS10 since starting Polaris, we support
> unlimited UVD instances.
> - Add kerneldoc style comment for
> amdgpu_uvd_used_handles().
>
> v2: as suggested by Christian
> - Add a new query AMDGPU_INFO_NUM_HANDLES
> - Create a helper function to return the number
> of currently used UVD handles.
> - Modify the logic to count the number of used
> UVD handles since handles can be freed in
> non-linear fashion.
>
> v1:
> - User might want to query the maximum number of UVD
> instances supported by firmware. In addition to that,
> if there are multiple applications using UVD handles
> at the same time, he might also want to query the
> currently used number of handles.
>
> For this we add two variables max_handles and
> used_handles inside drm_amdgpu_info_hw_ip. So now
> an application (or libdrm) can use AMDGPU_INFO IOCTL
> with AMDGPU_INFO_HW_IP_INFO query type to get these
> values.
>
> Signed-off-by: Arindam Nath
> Reviewed-by: Christian König
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 21 +
> drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c | 25 +
> drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.h | 1 +
> include/uapi/drm/amdgpu_drm.h | 9 +
> 4 files changed, 56 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> index 174eb59..3273d8c 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> @@ -570,6 +570,27 @@ static int amdgpu_info_ioctl(struct drm_device *dev,
> void *data, struct drm_file
> return -EINVAL;
> }
> }
> + case AMDGPU_INFO_NUM_HANDLES: {
> + struct drm_amdgpu_info_num_handles handle;
> +
> + switch (info->query_hw_ip.type) {
> + case AMDGPU_HW_IP_UVD:
> + /* Starting Polaris, we support unlimited UVD handles
> */
> + if (adev->asic_type < CHIP_POLARIS10) {
> + handle.uvd_max_handles =
> adev->uvd.max_handles;
> + handle.uvd_used_handles =
> amdgpu_uvd_used_handles(adev);
> +
> + return copy_to_user(out, &handle,
> + min((size_t)size, sizeof(handle))) ?
> -EFAULT : 0;
> + } else {
> + return -EINVAL;
Using EINVAL doesn't seem right here. As per man 3 ioctl
EINVAL The request or arg argument is not valid for this device.
A bit further down you can see the one you want.
ENODEV The fildes argument refers to a valid STREAMS device, but
the corresponding device driver does not support the ioctl() function.
Worth checking through the existing code and correcting similar thinkos ?
Thanks
Emil
[Intel-gfx] [PATCH 10/13] drm/i915: Use drm_connector_list_iter in debugfs
On Wed, Dec 14, 2016 at 3:44 PM, Jani Nikula
wrote:
> On Wed, 14 Dec 2016, Daniel Vetter wrote:
>> diff --git a/drivers/gpu/drm/i915/i915_drv.h
>> b/drivers/gpu/drm/i915/i915_drv.h
>> index 20bc04d5e617..7e25a7fffb1c 100644
>> --- a/drivers/gpu/drm/i915/i915_drv.h
>> +++ b/drivers/gpu/drm/i915/i915_drv.h
>> @@ -481,6 +481,9 @@ struct i915_hotplug {
>> &(dev)->mode_config.connector_list, \
>> base.head)
>>
>> +#define for_each_intel_connector_iter(intel_connector, iter) \
>> + while ((intel_connector =
>> to_intel_connector(drm_connector_list_iter_next(iter
>
> I occasionally worry about us relying on the base struct always being
> the first member. We don't even document this requirement anywhere.
In the cases where we misplaced the base struct we fixed up our to_foo
cast macros to correctly cast NULL pointers. Anything else just goes
boom sooner or later ...
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH v2 0/7] Host1x IOMMU support + VIC support
On Wed, Dec 14, 2016 at 3:11 PM, Daniel Vetter wrote: > On Wed, Dec 14, 2016 at 03:32:16PM +0200, Mikko Perttunen wrote: >> On 14.12.2016 15:05, Daniel Vetter wrote: >> > On Wed, Dec 14, 2016 at 02:41:28PM +0200, Mikko Perttunen wrote: >> > > On 14.12.2016 14:30, Daniel Vetter wrote: >> > > > On Wed, Dec 14, 2016 at 01:16:10PM +0200, Mikko Perttunen wrote: >> > > > > This series adds IOMMU support to Host1x and TegraDRM >> > > > > and adds support for the VIC (Video Image Compositor) >> > > > > host1x client. The series is available as a git repository at >> > > > > git://github.com/cyndis/linux.git; branch vic-2. >> > > > > >> > > > > A userspace test case for VIC can be found at >> > > > > https://github.com/cyndis/drm/tree/work/tegra. >> > > > > The testcase is in tests/tegra and is called submit_vic. >> > > > > The testcase/TRM include full headers and documentation >> > > > > to program the unit. The unit by itself, however, does not >> > > > > readily map to existing userspace library interfaces, so >> > > > > implementations for those are not provided. >> > > > >> > > > Afaik libva has an entire pile of post-processing support. Pretty sure >> > > > other video transcode libraries have similar interfaces, so should all >> > > > be >> > > > possible to implement this. >> > > >> > > We don't have any actual video transcoding support though, so unless it's >> > > possible to just implement a part of libva and defer the rest to some CPU >> > > implementation, I don't see how this is useful. I suppose I could >> > > implement >> > > a GStreamer plugin for colorspace conversion or resizing, since those are >> > > very modular. >> > >> > Hm, I guess the question then is, how did that get enabled? >> >> What is "that"? I'm not exactly sure. >> >> Our architecture is such that there's the VIC that handles colorspace >> conversion, rescaling, blitting and can do some 2d postprocessing effects as >> well. >> >> Then there's the separate NVDEC that is a video bitstream decoder. There's >> no support for that at the moment. I am working on the IP side of that. >> >> The video processing pipeline is then such that NVDEC is fed the bitstream; >> NVDEC outputs a YUV picture in a specific format; VIC takes that YUV picture >> and converts/rescales it into the desired format. Or if we are encoding >> video, VIC takes your RGB image, converts it into a format that NVENC >> understands, and so on. >> >> So with just VIC support, I could implement some simple 2D things. I don't >> know if anyone would want to specifically use the VIC for those since >> applications already have fast CPU algorithms. For the video pipeline using >> VIC is nice since these units can synchronize work without CPU involvement >> and when you're already using NVDEC or NVENC it's barely any extra effort to >> involve VIC as well. It can also be useful in power usage sensitive >> situations, but we aren't really fit for those situations with the upstream >> kernel anyway :) > > Ah I thought the nvdec was already enabled, since for i915 that's how we > went about things (we have a pretty much exactly matching split in the > various video related engines). But if that's not there yet then no > worries, all fine. > > Since you do seem to plan to enable everything anyway, might be worth it > to go directly with something like libva or libvdpau or whatever the cool > thing is. libva is my recommendation since it works on non-X11 too afaik, > but I have 0 clue. And might be worth it to check out whether you can't do > a super-basic libva driver that only does the post processing stuff. With > libva you can import/export images, so it might be possible even ... And > directly doing the full video engine support instead of a one-off in > gstreamer sounds more sensible to me. Silly me forgot to add the experts, i.e. Sean (current libva maintainer) and libva mailing lists. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH libdrm] xf86drm: fix aliasing violation
On 12 December 2016 at 23:28, Grazvydas Ignotas wrote: > On Mon, Dec 12, 2016 at 3:59 PM, Emil Velikov > wrote: >> On 11 December 2016 at 18:03, Grazvydas Ignotas wrote: >>> Just tell the compiler that drm_event will alias the char buffer, >>> so that it has no excuse to warn or generate bad code. >>> >> Afacit this patch [1] from Thierry should correctly address the issue, >> correct ? > > From what I've read, gcc's "strict aliasing" means that it's illegal > to access the same memory location using pointers of different types, > with only one exception - accessing an object of any type through a > char pointer. What is done here is the opposite - char array is read > as a struct, so according to that it's still wrong. > > That said I haven't seen any compiler causing problems in this case, > and Thierry's solution indeed silences the warning, so I guess you can > take his patch if you prefer. > I've seen a lot of noise on the topic of strict aliasing yet never had the time to investigate [too much]. There's some argument(s) that with type based (strict) aliasing the GCC [used to at least] make incorrect assumptions reordering code (stores). Latter of which causing issues when combined with optimisations. That aside: afaict the warning there is triggered since we have "& some_char" on rhs, rather than "some_char_or_void_star". With the latter of which explicitly allowed on the topic. The strange this is that fleshing a [identical] small example triggers no warning, regardless of the level (1,2,3) $ gcc -Wall -Wextra -Wstrict-aliasing=3 ss.c Barring any objections I'm leaning towards Thierry's patch. Thierry did you see any side-effect with [1] or you simply did not have time to double-check/investigate if the problem is truly fixed. Just double-checking. Thanks ! Emil [1] https://cgit.freedesktop.org/~tagr/drm/commit/?h=staging/fixes&id=4ebf7b59e69e43cc3810141dff8e3ef3535f03b2
[PATCH v2 1/7] drm/tegra: Add Tegra DRM allocation API
On Wed, Dec 14, 2016 at 03:01:56PM +0100, Lucas Stach wrote: > Am Mittwoch, den 14.12.2016, 14:48 +0100 schrieb Thierry Reding: > > On Wed, Dec 14, 2016 at 12:35:31PM +0100, Lucas Stach wrote: > > > Am Mittwoch, den 14.12.2016, 13:16 +0200 schrieb Mikko Perttunen: > > > > Add a new IO virtual memory allocation API to allow clients to > > > > allocate non-GEM memory in the Tegra DRM IOMMU domain. This is > > > > required e.g. for loading client firmware when clients are attached > > > > to the IOMMU domain. > > > > > > > > The allocator allocates contiguous physical pages that are then > > > > mapped contiguously to the IOMMU domain using the iova_domain > > > > library provided by the kernel. Contiguous physical pages are > > > > used so that the same allocator works also when IOMMU support > > > > is disabled and therefore devices access physical memory directly. > > > > > > > Why is this needed? If you use the DMA API for those buffers you should > > > end up with CMA memory in the !IOMMU case and normal paged memory with > > > IOMMU enabled. From my understanding this should match the requirements. > > > > We can't currently use the DMA API for these allocations because it > > doesn't allow (or at least didn't back when this was first implemented) > > us to share a mapping between two devices. > > Hm, maybe I'm overlooking something, but isn't this just a matter of > allocating on one device, then constructing a SG list (dma_get_sgtable) > from the buffer you got and use that to dma_map_sg() the buffer on the > other device? Yes, that would work. What I was referring to is sharing framebuffers between multiple CRTCs. Back at the time when IOMMU support was first added, I tried to use the DMA API. However, the problem with that was that we would've had to effectively dma_map_sg() on every page-flip since the buffer is imported into the DRM device, but there's no call that would import it for each CRTC only once. So when the framebuffer is added to a plane, you have to map it to the corresponding display controller. And the dma_map_sg() was, if I recall correctly, on the order of 5-10 ms, which is prohibitively expensive to do per frame. It's also completely unnecessary because all CRTCs in a DRM device can simply share the same IOMMU domain. I can't think of a reason why you would want or need to use separate domains. Back at the time this was something that the DMA API couldn't do, it would simply assign a separate IOMMU domain per device. It's possible that this has changed now given that many others must've run into the same problem meanwhile. > Maybe doing the firmware buffer allocation on host1x (with a 4GB upper > bound) and then sharing the SG list to the devices? That's pretty much what this API is doing. Only it's the other way around: we don't share the SG list with other devices for mapping, we simply reuse the same mapping across multiple devices, since they're all in the same IOMMU domain. > > The reason why we need these patches is that when IOMMU is enabled, then > > the units' falcons will read memory through the IOMMU, so we must have > > allocations for GEM buffers and the firmware go through the same > > mechanism. > > Sorry for maybe dumb questions. > > Do you have any engines other than the GPU that can handle SG > themselves? No, I don't think so. > Wouldn't you want the GEM objects to be backed by CMA in the !MMU > case? That's exactly what's happening already. If no IOMMU is available we allocate buffer objects backing store with dma_alloc_wc(). > How are ordinary GEM objects different from the falcon firmware? They're not. I think we could probably reuse more of the BO allocation functions for the firmware as well. I think Mikko already agreed to look into that. We might have to add some special cases, or split up the helpers a little differently to avoid creating GEM objects from the firmware buffers. We wouldn't want userspace to start mmap()'ing those. Thierry -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161214/872e65bc/attachment.sig>
[PATCH v2 0/7] Host1x IOMMU support + VIC support
On 14.12.2016 15:05, Daniel Vetter wrote: > On Wed, Dec 14, 2016 at 02:41:28PM +0200, Mikko Perttunen wrote: >> On 14.12.2016 14:30, Daniel Vetter wrote: >>> On Wed, Dec 14, 2016 at 01:16:10PM +0200, Mikko Perttunen wrote: This series adds IOMMU support to Host1x and TegraDRM and adds support for the VIC (Video Image Compositor) host1x client. The series is available as a git repository at git://github.com/cyndis/linux.git; branch vic-2. A userspace test case for VIC can be found at https://github.com/cyndis/drm/tree/work/tegra. The testcase is in tests/tegra and is called submit_vic. The testcase/TRM include full headers and documentation to program the unit. The unit by itself, however, does not readily map to existing userspace library interfaces, so implementations for those are not provided. >>> >>> Afaik libva has an entire pile of post-processing support. Pretty sure >>> other video transcode libraries have similar interfaces, so should all be >>> possible to implement this. >> >> We don't have any actual video transcoding support though, so unless it's >> possible to just implement a part of libva and defer the rest to some CPU >> implementation, I don't see how this is useful. I suppose I could implement >> a GStreamer plugin for colorspace conversion or resizing, since those are >> very modular. > > Hm, I guess the question then is, how did that get enabled? What is "that"? I'm not exactly sure. Our architecture is such that there's the VIC that handles colorspace conversion, rescaling, blitting and can do some 2d postprocessing effects as well. Then there's the separate NVDEC that is a video bitstream decoder. There's no support for that at the moment. I am working on the IP side of that. The video processing pipeline is then such that NVDEC is fed the bitstream; NVDEC outputs a YUV picture in a specific format; VIC takes that YUV picture and converts/rescales it into the desired format. Or if we are encoding video, VIC takes your RGB image, converts it into a format that NVENC understands, and so on. So with just VIC support, I could implement some simple 2D things. I don't know if anyone would want to specifically use the VIC for those since applications already have fast CPU algorithms. For the video pipeline using VIC is nice since these units can synchronize work without CPU involvement and when you're already using NVDEC or NVENC it's barely any extra effort to involve VIC as well. It can also be useful in power usage sensitive situations, but we aren't really fit for those situations with the upstream kernel anyway :) Thanks; Mikko. > >>> Until that exists I really think that the VIC part (and only that, since >>> tk1/tx1 in general seems to work with nouveau and all that) should stay >>> out of tree. >> >> Ok. I'll try to whip up something. > > But yeah some gstreamer thing might be doable, but not sure they take that > (I don't have any contacts there). Video is a bit a mess, there's no clear > go-to place for dropping some new hw support. > -Daniel >
[PATCH v2 0/7] Host1x IOMMU support + VIC support
On Wed, Dec 14, 2016 at 01:30:04PM +0100, Daniel Vetter wrote: > On Wed, Dec 14, 2016 at 01:16:10PM +0200, Mikko Perttunen wrote: > > This series adds IOMMU support to Host1x and TegraDRM > > and adds support for the VIC (Video Image Compositor) > > host1x client. The series is available as a git repository at > > git://github.com/cyndis/linux.git; branch vic-2. > > > > A userspace test case for VIC can be found at > > https://github.com/cyndis/drm/tree/work/tegra. > > The testcase is in tests/tegra and is called submit_vic. > > The testcase/TRM include full headers and documentation > > to program the unit. The unit by itself, however, does not > > readily map to existing userspace library interfaces, so > > implementations for those are not provided. > > Afaik libva has an entire pile of post-processing support. Pretty sure > other video transcode libraries have similar interfaces, so should all be > possible to implement this. > > Until that exists I really think that the VIC part (and only that, since > tk1/tx1 in general seems to work with nouveau and all that) should stay > out of tree. I think the VIC is somewhat special with regard to userspace ABI. I understand and completely agree with the requirements the community has established. However, as Mikko already said, there's no use for standalone VIC at all. There aren't any APIs that map to what the hardware does (except maybe parts of X or perhaps pixman, neither of which are likely to see implementations using VIC). I'm also not aware of any of the proprietary driver stack using only VIC for any use cases. The primary reason that I want VIC support upstream is because it makes it easier to test host1x support. Currently the only units that we can test against are gr2d and gr3d on Tegra20 through Tegra114. With Tegra124 gr2d and gr3d went away and got replaced by the gk20a GPU which doesn't use the host1x infrastructure. So on Tegra124 and later we currently have no way of exercising that code. Now, Tegra124 and Tegra210 are by far the most popular generations at this point and there are very few people running Tegra20 or Tegra30 with an upstream kernel (there are some still, and I think they're all awesome) so the host1x infrastructure is effectively untested and therefore I get very nervous whenever I have to apply patches against it because we can only validate on very old chips. Tegra124 is also somewhat of a special case. While it has a GPU that's driven by Nouveau, it doesn't yet have NVDEC and NVENC support that the newer Tegra210 has. The video encoding, if I remember correctly, is a precursor to NVENC (MSENC?) but video decoding is the "legacy" hardware that we had on earlier chips. That involved a fairly complicated setup with firmware that needs to be loaded to a fixed address in system memory (or mapped using the IOMMU). The bottom line is that it's unlikely that we'll ever see an open-source implementation for video decoding on Tegra124 (unless somebody reverse-engineers it), and hence we'd essentially be left without any way of testisc host1x support on TK1. All of that said, I could carry these patches out of tree and use them for testing until we've got a complete userspace ready. It's just something that I had hoped I could avoid. Thierry -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161214/0474a959/attachment.sig>
[PATCH v2 1/7] drm/tegra: Add Tegra DRM allocation API
On 14.12.2016 14:56, Lucas Stach wrote:
> Am Mittwoch, den 14.12.2016, 14:36 +0200 schrieb Mikko Perttunen:
>> On 14.12.2016 13:35, Lucas Stach wrote:
>>> Am Mittwoch, den 14.12.2016, 13:16 +0200 schrieb Mikko Perttunen:
Add a new IO virtual memory allocation API to allow clients to
allocate non-GEM memory in the Tegra DRM IOMMU domain. This is
required e.g. for loading client firmware when clients are attached
to the IOMMU domain.
The allocator allocates contiguous physical pages that are then
mapped contiguously to the IOMMU domain using the iova_domain
library provided by the kernel. Contiguous physical pages are
used so that the same allocator works also when IOMMU support
is disabled and therefore devices access physical memory directly.
>>> Why is this needed? If you use the DMA API for those buffers you should
>>> end up with CMA memory in the !IOMMU case and normal paged memory with
>>> IOMMU enabled. From my understanding this should match the requirements.
>>
>> Yes, memory allocated with the DMA API should work as well, but would
>> also require passing the device pointer for the device that is
>> allocating the memory, which isn't a problem, but this way we don't need
>> that.
>>
> Which in turn would allow you to properly describe the DMA capabilities
> of engines that can address more than 32 bits without the IOMMU, which
> was one of the comments Thierry had the last time around IIRC.
In this case, just the device's DMA mask wouldn't allow that, since
chips post Tegra132 do have units that support more than 32 bits
generally but the firmware must still be in the lower 4G.
I guess this means that we would need to set the DMA mask to the lowest
common denominator which is 32 bits, even though we want to have the
full 34 bits for the GEM objects. However, this should only be an issue
when the IOMMU is disabled so it isn't really that much of a problem.
>
>>>
>>> Also how big can those firmware images get? Will __get_free_pages be
>>> able to provide this much contig memory in a long running system with
>>> fragmented memory space? Isn't CMA the better option here?
>>
>> The largest is about 140 kilobytes. The space is also allocated when the
>> device is initialized which usually happens during boot.
>>
> Which is an order 6 allocation, something you almost certainly don't get
> in a fragmented system. I know it may work most of the time, as you are
> allocating those buffers early, but is most of the time really enough?
> What happens on module unload/load at a later time?
Yeah, it's probably worth fixing.
Thanks,
Mikko.
>
>>>
>>> Regards,
>>> Lucas
>>
>> Thanks,
>> Mikko.
>>
>>>
Signed-off-by: Mikko Perttunen
---
drivers/gpu/drm/tegra/drm.c | 111
+---
drivers/gpu/drm/tegra/drm.h | 11 +
2 files changed, 115 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index b8be3ee..cf714c6 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -1,12 +1,13 @@
/*
* Copyright (C) 2012 Avionic Design GmbH
- * Copyright (C) 2012-2013 NVIDIA CORPORATION. All rights reserved.
+ * Copyright (C) 2012-2016 NVIDIA CORPORATION. All rights reserved.
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*/
+#include
#include
#include
@@ -23,6 +24,8 @@
#define DRIVER_MINOR 0
#define DRIVER_PATCHLEVEL 0
+#define CARVEOUT_SZ SZ_64M
+
struct tegra_drm_file {
struct list_head contexts;
};
@@ -127,7 +130,8 @@ static int tegra_drm_load(struct drm_device *drm,
unsigned long flags)
if (iommu_present(&platform_bus_type)) {
struct iommu_domain_geometry *geometry;
- u64 start, end;
+ unsigned long order;
+ u64 carveout_start, carveout_end, gem_start, gem_end;
tegra->domain = iommu_domain_alloc(&platform_bus_type);
if (!tegra->domain) {
@@ -136,12 +140,25 @@ static int tegra_drm_load(struct drm_device *drm,
unsigned long flags)
}
geometry = &tegra->domain->geometry;
- start = geometry->aperture_start;
- end = geometry->aperture_end;
+ gem_start = geometry->aperture_start;
+ gem_end = geometry->aperture_end - CARVEOUT_SZ;
+ carveout_start = gem_end + 1;
+ carveout_end = geometry->aperture_end;
+
+ order = __ffs(tegra->domain->pgsize_bitmap);
+ init_iova_domain(&tegra->carveout.domain, 1UL << order,
+ carveout
[PATCH 1/2] drm/panel: Add support for S6E3HA2 panel driver on TM2 board
On 14.12.2016 07:04, Hoegeun Kwon wrote: > This patch add support for MIPI-DSI based S6E3HA2 AMOLED panel > driver. This panel has 1440x2560 resolution in 5.7-inch physical > panel in the TM2 device. > > Signed-off-by: Donghwa Lee > Signed-off-by: Hyungwon Hwang > Signed-off-by: Hoegeun Kwon Hi Hoegeun Kwon, Is there a reason to upstream obsolete driver? Current version of the driver is available at [1]. It differs significantly and contains multiple fixes and improvements. I guess it still requires some polishing but it is better base for start. [1]: https://review.tizen.org/git/?p=platform/kernel/linux-exynos.git;a=blob;f=drivers/gpu/drm/panel/panel-s6e3ha2.c;hb=refs/heads/tizen Regards Andrzej
[PATCH v4 06/22] drm: omapdrm: Handle FIFO underflow IRQs internally
On 14/12/16 13:48, Laurent Pinchart wrote:
> Hi Tomi,
>
> On Wednesday 14 Dec 2016 12:22:29 Tomi Valkeinen wrote:
>> On 14/12/16 02:27, Laurent Pinchart wrote:
>>> As the FIFO underflow IRQ handler just prints an error message to the
>>> kernel log, simplify the code by not registering one IRQ handler per
>>> plane but print the messages directly from the main IRQ handler.
>>>
>>> Signed-off-by: Laurent Pinchart
>>> Reviewed-by: Tomi Valkeinen
>>> ---
>>>
>>> +static void omap_irq_fifo_underflow(struct omap_drm_private *priv,
>>> + u32 irqstatus)
>>> +{
>>> + static DEFINE_RATELIMIT_STATE(_rs, DEFAULT_RATELIMIT_INTERVAL,
>>> + DEFAULT_RATELIMIT_BURST);
>>> + static const struct {
>>> + const char *name;
>>> + u32 mask;
>>> + } sources[] = {
>>> + { "gfx", DISPC_IRQ_GFX_FIFO_UNDERFLOW },
>>> + { "vid1", DISPC_IRQ_VID1_FIFO_UNDERFLOW },
>>> + { "vid2", DISPC_IRQ_VID2_FIFO_UNDERFLOW },
>>> + { "vid3", DISPC_IRQ_VID3_FIFO_UNDERFLOW },
>>> + };
>>> +
>>> + const u32 mask = DISPC_IRQ_GFX_FIFO_UNDERFLOW
>>> + | DISPC_IRQ_VID1_FIFO_UNDERFLOW
>>> + | DISPC_IRQ_VID2_FIFO_UNDERFLOW
>>> + | DISPC_IRQ_VID3_FIFO_UNDERFLOW;
>>> + unsigned int i;
>>> +
>>> + spin_lock(&list_lock);
>>> + irqstatus &= priv->irq_mask & mask;
>>> + spin_unlock(&list_lock);
>>> +
>>> + if (!irqstatus)
>>> + return;
>>
>> This is called every time we get any DSS interrupt, so I think it would
>> be good to have a fast-path here without the lock: irqstatus & mask.
>>
>> Or maybe store the enabled underflow irq bits separately from irq_mask,
>> as the underflow bits are never changed after the initial setup, and
>> then there's no need for locking.
>
> I'd prefer going for the former, but I'm a bit concerned that an IRQ bit
> defined as FIFO overflow on one platform could be defined as something else
> on
> another platform and be mistaken.
I meant that you could first check irqstatus & mask, and exit if 0.
After that you could do the above spinlock, and the check against
priv->irq_mask & mask.
So yes, it's not perfect either, and in the worst case could mean still
doing the spinlock at every irq... But, if I'm not mistaken, the current
HW versions do not have overlapping irq bits.
> Given that we already take the same lock in the IRQ handler to call the wait
> handlers, do you think this is really an issue ?
I don't think it's really an issue. But it's nice to optimize irq
handlers, especially as this is a hard-irq.
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161214/6dab0fac/attachment.sig>
[PATCH v2 0/7] Host1x IOMMU support + VIC support
On Wed, Dec 14, 2016 at 03:32:16PM +0200, Mikko Perttunen wrote: > On 14.12.2016 15:05, Daniel Vetter wrote: > > On Wed, Dec 14, 2016 at 02:41:28PM +0200, Mikko Perttunen wrote: > > > On 14.12.2016 14:30, Daniel Vetter wrote: > > > > On Wed, Dec 14, 2016 at 01:16:10PM +0200, Mikko Perttunen wrote: > > > > > This series adds IOMMU support to Host1x and TegraDRM > > > > > and adds support for the VIC (Video Image Compositor) > > > > > host1x client. The series is available as a git repository at > > > > > git://github.com/cyndis/linux.git; branch vic-2. > > > > > > > > > > A userspace test case for VIC can be found at > > > > > https://github.com/cyndis/drm/tree/work/tegra. > > > > > The testcase is in tests/tegra and is called submit_vic. > > > > > The testcase/TRM include full headers and documentation > > > > > to program the unit. The unit by itself, however, does not > > > > > readily map to existing userspace library interfaces, so > > > > > implementations for those are not provided. > > > > > > > > Afaik libva has an entire pile of post-processing support. Pretty sure > > > > other video transcode libraries have similar interfaces, so should all > > > > be > > > > possible to implement this. > > > > > > We don't have any actual video transcoding support though, so unless it's > > > possible to just implement a part of libva and defer the rest to some CPU > > > implementation, I don't see how this is useful. I suppose I could > > > implement > > > a GStreamer plugin for colorspace conversion or resizing, since those are > > > very modular. > > > > Hm, I guess the question then is, how did that get enabled? > > What is "that"? I'm not exactly sure. > > Our architecture is such that there's the VIC that handles colorspace > conversion, rescaling, blitting and can do some 2d postprocessing effects as > well. > > Then there's the separate NVDEC that is a video bitstream decoder. There's > no support for that at the moment. I am working on the IP side of that. > > The video processing pipeline is then such that NVDEC is fed the bitstream; > NVDEC outputs a YUV picture in a specific format; VIC takes that YUV picture > and converts/rescales it into the desired format. Or if we are encoding > video, VIC takes your RGB image, converts it into a format that NVENC > understands, and so on. > > So with just VIC support, I could implement some simple 2D things. I don't > know if anyone would want to specifically use the VIC for those since > applications already have fast CPU algorithms. For the video pipeline using > VIC is nice since these units can synchronize work without CPU involvement > and when you're already using NVDEC or NVENC it's barely any extra effort to > involve VIC as well. It can also be useful in power usage sensitive > situations, but we aren't really fit for those situations with the upstream > kernel anyway :) Ah I thought the nvdec was already enabled, since for i915 that's how we went about things (we have a pretty much exactly matching split in the various video related engines). But if that's not there yet then no worries, all fine. Since you do seem to plan to enable everything anyway, might be worth it to go directly with something like libva or libvdpau or whatever the cool thing is. libva is my recommendation since it works on non-X11 too afaik, but I have 0 clue. And might be worth it to check out whether you can't do a super-basic libva driver that only does the post processing stuff. With libva you can import/export images, so it might be possible even ... And directly doing the full video engine support instead of a one-off in gstreamer sounds more sensible to me. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[Bug 98914] mesa-vdpau-drivers: breaks vdpau for mpeg2video
https://bugs.freedesktop.org/show_bug.cgi?id=98914 --- Comment #12 from Jörg-Volker Peetz --- Thanks for the patch. I reviewed and tested it ok. The hardware accelerated mpeg2video codec works, e.g., with mpv. So, my five years old notebook is "very" old :-(. I did all testing with the integrated GPU (ATI Mobility Radeon HD 4200). >From time to time I try the offloading to the discrete GPU (ATI Mobility Radeon HD 5000 Series) with PRIME. But all too often it hard crashes this notebook. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161214/6a5092b5/attachment.html>
[PATCH 2/2] arm64: dts: exynos: Add support for S6E3HA2 panel device on TM2 board
From: Hyungwon Hwang
This patch add the panel device tree node for S6E3HA2 display
controller to TM2 dts.
Signed-off-by: Hyungwon Hwang
Signed-off-by: Andrzej Hajda
Signed-off-by: Chanwoo Choi
Signed-off-by: Hoegeun Kwon
---
arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 33 +++
1 file changed, 33 insertions(+)
diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
index db879f4..4ad2332 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
+++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
@@ -252,11 +252,44 @@
reg = <1>;
dsi_out: endpoint {
+ remote-endpoint = <&dsi_in>;
samsung,burst-clock-frequency = <51200>;
samsung,esc-clock-frequency = <1600>;
};
};
};
+
+ panel at 0 {
+ compatible = "samsung,s6e3ha2";
+ reg = <0>;
+ vdd3-supply = <&ldo27_reg>;
+ vci-supply = <&ldo28_reg>;
+ reset-gpios = <&gpg0 0 GPIO_ACTIVE_HIGH>;
+ enable-gpios = <&gpf1 5 GPIO_ACTIVE_HIGH>;
+ te-gpios = <&gpf1 3 GPIO_ACTIVE_HIGH>;
+ power-on-delay = <120>;
+ reset-delay = <5>;
+
+ display-timings {
+ timing-0 {
+ clock-frequency = <1487>;
+ hactive = <1440>;
+ vactive = <2560>;
+ hfront-porch = <1>;
+ hback-porch = <1>;
+ hsync-len = <1>;
+ vfront-porch = <1>;
+ vback-porch = <15>;
+ vsync-len = <1>;
+ };
+ };
+
+ port {
+ dsi_in: endpoint {
+ remote-endpoint = <&dsi_out>;
+ };
+ };
+ };
};
&hsi2c_0 {
--
1.9.1
[PATCH 1/2] drm/panel: Add support for S6E3HA2 panel driver on TM2 board
This patch add support for MIPI-DSI based S6E3HA2 AMOLED panel
driver. This panel has 1440x2560 resolution in 5.7-inch physical
panel in the TM2 device.
Signed-off-by: Donghwa Lee
Signed-off-by: Hyungwon Hwang
Signed-off-by: Hoegeun Kwon
---
.../bindings/display/panel/samsung,s6e3ha2.txt | 52 ++
drivers/gpu/drm/panel/Kconfig | 6 +
drivers/gpu/drm/panel/Makefile | 1 +
drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c | 756 +
4 files changed, 815 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt
create mode 100644 drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
diff --git
a/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt
b/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt
new file mode 100644
index 000..1f41f24
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt
@@ -0,0 +1,52 @@
+Samsung S6E3HA2 5.7" 1440x2560 AMOLED panel
+
+Required properties:
+ - compatible: "samsung,s6e3ha2"
+ - reg: the virtual channel number of a DSI peripheral
+ - vdd3-supply: core voltage supply
+ - vci-supply: voltage supply for analog circuits
+ - reset-gpios: a GPIO spec for the reset pin
+ - enable-gpios: a GPIO spec for the panel enable pin
+ - te-gpios: a GPIO spec for the tearing effect synchronization signal gpio
pin
+
+Optional properties:
+ - display-timings: timings for the connected panel as described by [1]
+
+The device node can contain one 'port' child node with one child
+'endpoint' node, according to the bindings defined in [2]. This
+node should describe panel's video bus.
+
+[1]: Documentation/devicetree/bindings/display/panel/display-timing.txt
+[2]: Documentation/devicetree/bindings/media/video-interfaces.txt
+
+Example:
+
+ panel at 0 {
+ compatible = "samsung,s6e3ha2";
+ reg = <0>;
+ vdd3-supply = <&ldo27_reg>;
+ vci-supply = <&ldo28_reg>;
+ reset-gpios = <&gpg0 0 GPIO_ACTIVE_HIGH>;
+ enable-gpios = <&gpf1 5 GPIO_ACTIVE_HIGH>;
+ te-gpios = <&gpf1 3 GPIO_ACTIVE_HIGH>;
+
+ display-timings {
+ timing-0 {
+ clock-frequency = <0>;
+ hactive = <1440>;
+ vactive = <2560>;
+ hfront-porch = <1>;
+ hback-porch = <1>;
+ hsync-len = <1>;
+ vfront-porch = <1>;
+ vback-porch = <15>;
+ vsync-len = <1>;
+ };
+ };
+
+ port {
+ dsi_in: endpoint {
+ remote-endpoint = <&dsi_out>;
+ };
+ };
+ };
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 62aba97..e1a2fcd 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -58,6 +58,12 @@ config DRM_PANEL_SAMSUNG_S6E8AA0
select DRM_MIPI_DSI
select VIDEOMODE_HELPERS
+config DRM_PANEL_SAMSUNG_S6E3HA2
+ tristate "Samsung S6E3HA2 DSI video mode panel"
+ depends on OF
+ select DRM_MIPI_DSI
+ select VIDEOMODE_HELPERS
+
config DRM_PANEL_SHARP_LQ101R1SX01
tristate "Sharp LQ101R1SX01 panel"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index a5c7ec0..993699b 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -4,5 +4,6 @@ obj-$(CONFIG_DRM_PANEL_LG_LG4573) += panel-lg-lg4573.o
obj-$(CONFIG_DRM_PANEL_PANASONIC_VVX10F034N00) +=
panel-panasonic-vvx10f034n00.o
obj-$(CONFIG_DRM_PANEL_SAMSUNG_LD9040) += panel-samsung-ld9040.o
obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E8AA0) += panel-samsung-s6e8aa0.o
+obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E3HA2) += panel-samsung-s6e3ha2.o
obj-$(CONFIG_DRM_PANEL_SHARP_LQ101R1SX01) += panel-sharp-lq101r1sx01.o
obj-$(CONFIG_DRM_PANEL_SHARP_LS043T1LE01) += panel-sharp-ls043t1le01.o
diff --git a/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
b/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
new file mode 100644
index 000..a6ad63b
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
@@ -0,0 +1,756 @@
+/*
+ * MIPI-DSI based s6e3ha2 AMOLED 5.7 inch panel driver.
+ *
+ * Copyright (c) 2016 Samsung Electronics Co., Ltd.
+ * Donghwa Lee
+ * Hyungwon Hwang
+ * Hoegeun Kwon
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+*/
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define S6E3HA2_MIN_BRIGHTNESS 0
+#define S6E3
[PATCH 0/2] Add support for the S6E3HA2 panel on TM2 board
Purpose of this patch is add support for S6E3HA2 AMOLED panel on the TM2 board. The first patch adds support for S6E3HA2 panel device tree document and driver, the second patch add support for S6E3HA2 panel device tree. Hoegeun Kwon (1): drm/panel: Add support for S6E3HA2 panel driver on TM2 board Hyungwon Hwang (1): arm64: dts: exynos: Add support for S6E3HA2 panel device on TM2 board .../bindings/display/panel/samsung,s6e3ha2.txt | 52 ++ arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 33 + drivers/gpu/drm/panel/Kconfig | 6 + drivers/gpu/drm/panel/Makefile | 1 + drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c | 756 + 5 files changed, 848 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt create mode 100644 drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c -- 1.9.1
[PATCH 12/23] drm: omapdrm: plane: update fifo size on atomic update
Hi, On Wed, Dec 14, 2016 at 11:14:32AM +0200, Tomi Valkeinen wrote: > On 14/12/16 11:10, Laurent Pinchart wrote: > > Hi Tomi, > > > > On Wednesday 14 Dec 2016 10:43:18 Tomi Valkeinen wrote: > >> On 13/12/16 19:35, Laurent Pinchart wrote: > >>> On Tuesday 08 Mar 2016 17:39:44 Sebastian Reichel wrote: > >>>> This is a workaround for a hardware bug occuring > >>>> on OMAP3 with manually updated panels. > >>> > >>> Could you please explain what the bug is and how the workaround operates ? > >>> Do you have a reference to an errata document ? FWIW I don't know anything about this bug. I just hit it while getting omapdrm working on n950 and ported this over from omapfb. > >> I don't think I ever found out exactly why the problem happens. But on > >> OMAP3 DSI, the fifo thresholds had to be tuned slightly, otherwise DISPC > >> would stop. dispc_ovl_compute_fifo_thresholds() does that tuning if > >> "manual_update" parameter is set on OMAP3. > > > > I've had a look at dispc_ovl_compute_fifo_thresholds() and the patch makes > > sense to me. If Sebastian could address the small issues I pointed out, we > > could then merge this. Alternatively I can take care of addressing them. > > It's only needed with the rest of the DSI manual update series, so I'd > rather keep it as part of that series. To be honest I haven't worked on this for some time. From some comments on the patchset I think the biggest issue is, that omapdrm does not use generic panel drivers and cannot easily use the mipi_dsi_driver_register. I simply did not have enough time to implement such a huge change. I guess a first step is Peter Ujfalusi's series: https://lkml.org/lkml/2016/9/1/267 -- Sebastian -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161214/df0fdfa4/attachment-0001.sig>
[PATCH v2 1/7] drm/tegra: Add Tegra DRM allocation API
Am Mittwoch, den 14.12.2016, 14:48 +0100 schrieb Thierry Reding: > On Wed, Dec 14, 2016 at 12:35:31PM +0100, Lucas Stach wrote: > > Am Mittwoch, den 14.12.2016, 13:16 +0200 schrieb Mikko Perttunen: > > > Add a new IO virtual memory allocation API to allow clients to > > > allocate non-GEM memory in the Tegra DRM IOMMU domain. This is > > > required e.g. for loading client firmware when clients are attached > > > to the IOMMU domain. > > > > > > The allocator allocates contiguous physical pages that are then > > > mapped contiguously to the IOMMU domain using the iova_domain > > > library provided by the kernel. Contiguous physical pages are > > > used so that the same allocator works also when IOMMU support > > > is disabled and therefore devices access physical memory directly. > > > > > Why is this needed? If you use the DMA API for those buffers you should > > end up with CMA memory in the !IOMMU case and normal paged memory with > > IOMMU enabled. From my understanding this should match the requirements. > > We can't currently use the DMA API for these allocations because it > doesn't allow (or at least didn't back when this was first implemented) > us to share a mapping between two devices. Hm, maybe I'm overlooking something, but isn't this just a matter of allocating on one device, then constructing a SG list (dma_get_sgtable) from the buffer you got and use that to dma_map_sg() the buffer on the other device? Maybe doing the firmware buffer allocation on host1x (with a 4GB upper bound) and then sharing the SG list to the devices? > The reason why we need these patches is that when IOMMU is enabled, then > the units' falcons will read memory through the IOMMU, so we must have > allocations for GEM buffers and the firmware go through the same > mechanism. Sorry for maybe dumb questions. Do you have any engines other than the GPU that can handle SG themselves? Wouldn't you want the GEM objects to be backed by CMA in the !MMU case? How are ordinary GEM objects different from the falcon firmware? Regards, Lucas
[PATCH v2 1/7] drm/tegra: Add Tegra DRM allocation API
On Wed, Dec 14, 2016 at 12:35:31PM +0100, Lucas Stach wrote: > Am Mittwoch, den 14.12.2016, 13:16 +0200 schrieb Mikko Perttunen: > > Add a new IO virtual memory allocation API to allow clients to > > allocate non-GEM memory in the Tegra DRM IOMMU domain. This is > > required e.g. for loading client firmware when clients are attached > > to the IOMMU domain. > > > > The allocator allocates contiguous physical pages that are then > > mapped contiguously to the IOMMU domain using the iova_domain > > library provided by the kernel. Contiguous physical pages are > > used so that the same allocator works also when IOMMU support > > is disabled and therefore devices access physical memory directly. > > > Why is this needed? If you use the DMA API for those buffers you should > end up with CMA memory in the !IOMMU case and normal paged memory with > IOMMU enabled. From my understanding this should match the requirements. We can't currently use the DMA API for these allocations because it doesn't allow (or at least didn't back when this was first implemented) us to share a mapping between two devices. The reason why we need these patches is that when IOMMU is enabled, then the units' falcons will read memory through the IOMMU, so we must have allocations for GEM buffers and the firmware go through the same mechanism. Thierry -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161214/6dd7af93/attachment.sig>
[PATCH v2 0/7] Host1x IOMMU support + VIC support
On 14.12.2016 14:30, Daniel Vetter wrote: > On Wed, Dec 14, 2016 at 01:16:10PM +0200, Mikko Perttunen wrote: >> This series adds IOMMU support to Host1x and TegraDRM >> and adds support for the VIC (Video Image Compositor) >> host1x client. The series is available as a git repository at >> git://github.com/cyndis/linux.git; branch vic-2. >> >> A userspace test case for VIC can be found at >> https://github.com/cyndis/drm/tree/work/tegra. >> The testcase is in tests/tegra and is called submit_vic. >> The testcase/TRM include full headers and documentation >> to program the unit. The unit by itself, however, does not >> readily map to existing userspace library interfaces, so >> implementations for those are not provided. > > Afaik libva has an entire pile of post-processing support. Pretty sure > other video transcode libraries have similar interfaces, so should all be > possible to implement this. We don't have any actual video transcoding support though, so unless it's possible to just implement a part of libva and defer the rest to some CPU implementation, I don't see how this is useful. I suppose I could implement a GStreamer plugin for colorspace conversion or resizing, since those are very modular. > > Until that exists I really think that the VIC part (and only that, since > tk1/tx1 in general seems to work with nouveau and all that) should stay > out of tree. Ok. I'll try to whip up something. > -Daniel Thanks, Mikko. > >> >> The in-kernel firewall is not implemented for VIC; >> therefore, either the IOMMU must be enabled or the firewall >> disabled for the test to pass. >> >> Tested with Jetson TX1 (T210). Probably works also >> with Jetson TK1 (T124). Note that due to hardware changes >> the testcase also needs to be changed to run properly >> on T124: this can be done by removing the topmost >> commit of the aforementioned test repository. >> >> Thanks, >> Mikko. >> >> Arto Merilainen (2): >> drm/tegra: Add falcon helper library >> drm/tegra: Add VIC support >> >> Mikko Perttunen (5): >> drm/tegra: Add Tegra DRM allocation API >> gpu: host1x: Add IOMMU support >> dt-bindings: Add bindings for the Tegra VIC >> arm64: tegra: Enable VIC on T210 >> arm64: tegra: Enable IOMMU for Host1x on Tegra210 >> >> .../display/tegra/nvidia,tegra20-host1x.txt| 13 + >> arch/arm64/boot/dts/nvidia/tegra210.dtsi | 19 +- >> drivers/gpu/drm/tegra/Makefile | 4 +- >> drivers/gpu/drm/tegra/drm.c| 114 +- >> drivers/gpu/drm/tegra/drm.h| 12 + >> drivers/gpu/drm/tegra/falcon.c | 259 ++ >> drivers/gpu/drm/tegra/falcon.h | 127 +++ >> drivers/gpu/drm/tegra/vic.c| 396 >> + >> drivers/gpu/drm/tegra/vic.h| 31 ++ >> drivers/gpu/host1x/cdma.c | 74 +++- >> drivers/gpu/host1x/cdma.h | 6 +- >> drivers/gpu/host1x/dev.c | 40 ++- >> drivers/gpu/host1x/dev.h | 6 + >> drivers/gpu/host1x/hw/cdma_hw.c| 16 +- >> drivers/gpu/host1x/job.c | 72 +++- >> drivers/gpu/host1x/job.h | 1 + >> include/linux/host1x.h | 1 + >> 17 files changed, 1143 insertions(+), 48 deletions(-) >> create mode 100644 drivers/gpu/drm/tegra/falcon.c >> create mode 100644 drivers/gpu/drm/tegra/falcon.h >> create mode 100644 drivers/gpu/drm/tegra/vic.c >> create mode 100644 drivers/gpu/drm/tegra/vic.h >> >> -- >> 2.10.2 >> >
[PATCH v2 1/7] drm/tegra: Add Tegra DRM allocation API
On 14.12.2016 13:35, Lucas Stach wrote:
> Am Mittwoch, den 14.12.2016, 13:16 +0200 schrieb Mikko Perttunen:
>> Add a new IO virtual memory allocation API to allow clients to
>> allocate non-GEM memory in the Tegra DRM IOMMU domain. This is
>> required e.g. for loading client firmware when clients are attached
>> to the IOMMU domain.
>>
>> The allocator allocates contiguous physical pages that are then
>> mapped contiguously to the IOMMU domain using the iova_domain
>> library provided by the kernel. Contiguous physical pages are
>> used so that the same allocator works also when IOMMU support
>> is disabled and therefore devices access physical memory directly.
>>
> Why is this needed? If you use the DMA API for those buffers you should
> end up with CMA memory in the !IOMMU case and normal paged memory with
> IOMMU enabled. From my understanding this should match the requirements.
Yes, memory allocated with the DMA API should work as well, but would
also require passing the device pointer for the device that is
allocating the memory, which isn't a problem, but this way we don't need
that.
>
> Also how big can those firmware images get? Will __get_free_pages be
> able to provide this much contig memory in a long running system with
> fragmented memory space? Isn't CMA the better option here?
The largest is about 140 kilobytes. The space is also allocated when the
device is initialized which usually happens during boot.
>
> Regards,
> Lucas
Thanks,
Mikko.
>
>> Signed-off-by: Mikko Perttunen
>> ---
>> drivers/gpu/drm/tegra/drm.c | 111
>> +---
>> drivers/gpu/drm/tegra/drm.h | 11 +
>> 2 files changed, 115 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
>> index b8be3ee..cf714c6 100644
>> --- a/drivers/gpu/drm/tegra/drm.c
>> +++ b/drivers/gpu/drm/tegra/drm.c
>> @@ -1,12 +1,13 @@
>> /*
>> * Copyright (C) 2012 Avionic Design GmbH
>> - * Copyright (C) 2012-2013 NVIDIA CORPORATION. All rights reserved.
>> + * Copyright (C) 2012-2016 NVIDIA CORPORATION. All rights reserved.
>> *
>> * This program is free software; you can redistribute it and/or modify
>> * it under the terms of the GNU General Public License version 2 as
>> * published by the Free Software Foundation.
>> */
>>
>> +#include
>> #include
>> #include
>>
>> @@ -23,6 +24,8 @@
>> #define DRIVER_MINOR 0
>> #define DRIVER_PATCHLEVEL 0
>>
>> +#define CARVEOUT_SZ SZ_64M
>> +
>> struct tegra_drm_file {
>> struct list_head contexts;
>> };
>> @@ -127,7 +130,8 @@ static int tegra_drm_load(struct drm_device *drm,
>> unsigned long flags)
>>
>> if (iommu_present(&platform_bus_type)) {
>> struct iommu_domain_geometry *geometry;
>> -u64 start, end;
>> +unsigned long order;
>> +u64 carveout_start, carveout_end, gem_start, gem_end;
>>
>> tegra->domain = iommu_domain_alloc(&platform_bus_type);
>> if (!tegra->domain) {
>> @@ -136,12 +140,25 @@ static int tegra_drm_load(struct drm_device *drm,
>> unsigned long flags)
>> }
>>
>> geometry = &tegra->domain->geometry;
>> -start = geometry->aperture_start;
>> -end = geometry->aperture_end;
>> +gem_start = geometry->aperture_start;
>> +gem_end = geometry->aperture_end - CARVEOUT_SZ;
>> +carveout_start = gem_end + 1;
>> +carveout_end = geometry->aperture_end;
>> +
>> +order = __ffs(tegra->domain->pgsize_bitmap);
>> +init_iova_domain(&tegra->carveout.domain, 1UL << order,
>> + carveout_start >> order,
>> + carveout_end >> order);
>> +
>> +tegra->carveout.shift = iova_shift(&tegra->carveout.domain);
>> +tegra->carveout.limit = carveout_end >> tegra->carveout.shift;
>> +
>> +drm_mm_init(&tegra->mm, gem_start, gem_end - gem_start + 1);
>>
>> -DRM_DEBUG_DRIVER("IOMMU aperture initialized (%#llx-%#llx)\n",
>> - start, end);
>> -drm_mm_init(&tegra->mm, start, end - start + 1);
>> +DRM_DEBUG("IOMMU apertures:\n");
>> +DRM_DEBUG(" GEM: %#llx-%#llx\n", gem_start, gem_end);
>> +DRM_DEBUG(" Carveout: %#llx-%#llx\n", carveout_start,
>> + carveout_end);
>> }
>>
>> mutex_init(&tegra->clients_lock);
>> @@ -208,6 +225,7 @@ static int tegra_drm_load(struct drm_device *drm,
>> unsigned long flags)
>> if (tegra->domain) {
>> iommu_domain_free(tegra->domain);
>> drm_mm_takedown(&tegra->mm);
>> +put_iova_domain(&tegra->carveout.domain);
>> }
>> free:
>> kfree(tegra);
>> @@ -232,6 +250,7 @@ static int tegra_drm_unload(struct drm_device *drm)
>> if (tegra->domain) {
>> iommu_domain_free(tegra->domain);
>> drm_mm_tak
[PATCH v13 3/3] drm/i915: Put "cooked" vlank counters in frame CRC lines
Use drm_accurate_vblank_count so we have the full 32 bit to represent
the frame counter and userspace has a simpler way of knowing when the
counter wraps around.
Signed-off-by: Tomeu Vizoso
Reviewed-by: Emil Velikov
---
drivers/gpu/drm/i915/i915_irq.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 24b7620c1005..c0e3d1c1b4f0 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1557,7 +1557,6 @@ static void display_pipe_crc_irq_handler(struct
drm_i915_private *dev_priv,
struct drm_driver *driver = dev_priv->drm.driver;
uint32_t crcs[5];
int head, tail, ret;
- u32 frame;
spin_lock(&pipe_crc->lock);
if (pipe_crc->source) {
@@ -1612,8 +1611,9 @@ static void display_pipe_crc_irq_handler(struct
drm_i915_private *dev_priv,
crcs[2] = crc2;
crcs[3] = crc3;
crcs[4] = crc4;
- frame = driver->get_vblank_counter(&dev_priv->drm, pipe);
- ret = drm_crtc_add_crc_entry(&crtc->base, true, frame, crcs);
+ ret = drm_crtc_add_crc_entry(&crtc->base, true,
+
drm_accurate_vblank_count(&crtc->base),
+crcs);
if (!ret)
wake_up_interruptible(&crtc->base.crc.wq);
}
--
2.7.4
[PATCH v13 2/3] drm/i915: Use new CRC debugfs API
The core provides now an ABI to userspace for generation of frame CRCs,
so implement the ->set_crc_source() callback and reuse as much code as
possible with the previous ABI implementation.
When handling the pageflip interrupt, we skip 1 or 2 frames depending on
the HW because they contain wrong values. For the legacy ABI for
generating frame CRCs, this was done in userspace but now that we have a
generic ABI it's better if it's not exposed by the kernel.
v2:
- Leave the legacy implementation in place as the ABI implementation
in the core is incompatible with it.
v3:
- Use the "cooked" vblank counter so we have a whole 32 bits.
- Make sure we don't mess with the state of the legacy CRC capture
ABI implementation.
v4:
- Keep use of get_vblank_counter as in the legacy code, will be
changed in a followup commit.
v5:
- Skip first frame or two as it's known that they contain wrong
data.
- A few fixes suggested by Emil Velikov.
v6:
- Rework programming of the HW registers to preserve previous
behavior.
v7:
- Address whitespace issue.
- Added a comment on why in the implementation of the new ABI we
skip the 1st or 2nd frames.
v9:
- Add stub for intel_crtc_set_crc_source.
v12:
- Rebased.
- Remove stub for intel_crtc_set_crc_source and instead set the
callback to NULL (Jani Nikula).
Signed-off-by: Tomeu Vizoso
Reviewed-by: Emil Velikov
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i915_irq.c | 81 --
drivers/gpu/drm/i915/intel_display.c | 1 +
drivers/gpu/drm/i915/intel_drv.h | 6 +++
drivers/gpu/drm/i915/intel_pipe_crc.c | 94 ++-
5 files changed, 145 insertions(+), 38 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 20bc04d5e617..d7c0b44a1447 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1874,6 +1874,7 @@ struct intel_pipe_crc {
enum intel_pipe_crc_source source;
int head, tail;
wait_queue_head_t wq;
+ int skipped;
};
struct i915_frontbuffer_tracking {
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index a0e70f5b3aad..24b7620c1005 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1553,41 +1553,70 @@ static void display_pipe_crc_irq_handler(struct
drm_i915_private *dev_priv,
{
struct intel_pipe_crc *pipe_crc = &dev_priv->pipe_crc[pipe];
struct intel_pipe_crc_entry *entry;
- int head, tail;
+ struct intel_crtc *crtc = intel_get_crtc_for_pipe(dev_priv, pipe);
+ struct drm_driver *driver = dev_priv->drm.driver;
+ uint32_t crcs[5];
+ int head, tail, ret;
+ u32 frame;
spin_lock(&pipe_crc->lock);
+ if (pipe_crc->source) {
+ if (!pipe_crc->entries) {
+ spin_unlock(&pipe_crc->lock);
+ DRM_DEBUG_KMS("spurious interrupt\n");
+ return;
+ }
- if (!pipe_crc->entries) {
- spin_unlock(&pipe_crc->lock);
- DRM_DEBUG_KMS("spurious interrupt\n");
- return;
- }
-
- head = pipe_crc->head;
- tail = pipe_crc->tail;
+ head = pipe_crc->head;
+ tail = pipe_crc->tail;
- if (CIRC_SPACE(head, tail, INTEL_PIPE_CRC_ENTRIES_NR) < 1) {
- spin_unlock(&pipe_crc->lock);
- DRM_ERROR("CRC buffer overflowing\n");
- return;
- }
+ if (CIRC_SPACE(head, tail, INTEL_PIPE_CRC_ENTRIES_NR) < 1) {
+ spin_unlock(&pipe_crc->lock);
+ DRM_ERROR("CRC buffer overflowing\n");
+ return;
+ }
- entry = &pipe_crc->entries[head];
+ entry = &pipe_crc->entries[head];
- entry->frame = dev_priv->drm.driver->get_vblank_counter(&dev_priv->drm,
-pipe);
- entry->crc[0] = crc0;
- entry->crc[1] = crc1;
- entry->crc[2] = crc2;
- entry->crc[3] = crc3;
- entry->crc[4] = crc4;
+ entry->frame = driver->get_vblank_counter(&dev_priv->drm, pipe);
+ entry->crc[0] = crc0;
+ entry->crc[1] = crc1;
+ entry->crc[2] = crc2;
+ entry->crc[3] = crc3;
+ entry->crc[4] = crc4;
- head = (head + 1) & (INTEL_PIPE_CRC_ENTRIES_NR - 1);
- pipe_crc->head = head;
+ head = (head + 1) & (INTEL_PIPE_CRC_ENTRIES_NR - 1);
+ pipe_crc->head = head;
- spin_unlock(&pipe_crc->lock);
+ spin_unlock(&pipe_crc->lock);
- wake_up_interruptible(&pipe_crc->wq);
+ wake_up_interruptible(&pipe_crc->wq);
+ } else {
+ /*
+* For s
[PATCH v13 1/3] drm: Move locking into drm_debugfs_crtc_crc_add
There's no reason any more for callers of this function to take the lock
themselves, so just move the lock to the function to avoid confusion and
bugs when more callers are contributed.
Signed-off-by: Tomeu Vizoso
---
drivers/gpu/drm/drm_debugfs_crc.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_debugfs_crc.c
b/drivers/gpu/drm/drm_debugfs_crc.c
index 00e771fb7df2..68b171af237b 100644
--- a/drivers/gpu/drm/drm_debugfs_crc.c
+++ b/drivers/gpu/drm/drm_debugfs_crc.c
@@ -325,16 +325,19 @@ int drm_crtc_add_crc_entry(struct drm_crtc *crtc, bool
has_frame,
struct drm_crtc_crc_entry *entry;
int head, tail;
- assert_spin_locked(&crc->lock);
+ spin_lock(&crc->lock);
/* Caller may not have noticed yet that userspace has stopped reading */
- if (!crc->opened)
+ if (!crc->opened) {
+ spin_unlock(&crc->lock);
return -EINVAL;
+ }
head = crc->head;
tail = crc->tail;
if (CIRC_SPACE(head, tail, DRM_CRC_ENTRIES_NR) < 1) {
+ spin_unlock(&crc->lock);
DRM_ERROR("Overflow of CRC buffer, userspace reads too
slow.\n");
return -ENOBUFS;
}
@@ -347,6 +350,8 @@ int drm_crtc_add_crc_entry(struct drm_crtc *crtc, bool
has_frame,
head = (head + 1) & (DRM_CRC_ENTRIES_NR - 1);
crc->head = head;
+ spin_unlock(&crc->lock);
+
return 0;
}
EXPORT_SYMBOL_GPL(drm_crtc_add_crc_entry);
--
2.7.4
[PATCH v13 0/3] New debugfs API for capturing CRC of frames
Hi, here are the patches that remain to be merged in this series. I have only rebased them since last time. Thanks, Tomeu Tomeu Vizoso (3): drm: Move locking into drm_debugfs_crtc_crc_add drm/i915: Use new CRC debugfs API drm/i915: Put "cooked" vlank counters in frame CRC lines drivers/gpu/drm/drm_debugfs_crc.c | 9 +++- drivers/gpu/drm/i915/i915_drv.h | 1 + drivers/gpu/drm/i915/i915_irq.c | 81 -- drivers/gpu/drm/i915/intel_display.c | 1 + drivers/gpu/drm/i915/intel_drv.h | 6 +++ drivers/gpu/drm/i915/intel_pipe_crc.c | 94 ++- 6 files changed, 152 insertions(+), 40 deletions(-) -- 2.7.4
[PATCH 09/34] drm: kselftest for drm_mm_insert_node()
On ma, 2016-12-12 at 11:53 +, Chris Wilson wrote:
> Exercise drm_mm_insert_node(), check that we can't overfill a range and
> that the lists are correct after reserving/removing.
>
> Signed-off-by: Chris Wilson
> +static int __igt_insert(int count, u64 size)
> +{
> + for (n = 0; n < count; n++) {
> + int err;
> +
> + node = &nodes[n];
> + err = drm_mm_insert_node(&mm, node, size, 0,
> + Â DRM_MM_SEARCH_DEFAULT);
> + if (err) {
> + pr_err("insert failed, step %d, start %llu\n",
> + Â Â Â Â Â Â Â n, nodes[n].start);
> + ret = err;
> + goto out;
> + }
> +
> + if (!drm_mm_node_allocated(node)) {
> + pr_err("inserted node not allocated! step %d, start
> %llu\n",
> + Â Â Â Â Â Â Â n, node->start);
> + goto out;
> + }
> + }
> +
> + /* Repeated use should then fail */
> + if (1) {
Why if (1)? What are you not telling me.
> + if (1) {
Ditto.
> + struct drm_mm_node tmp;
> +
> + memset(&tmp, 0, sizeof(tmp));
> + if (!drm_mm_insert_node(&mm, &tmp, size, 0,
> + DRM_MM_SEARCH_DEFAULT)) {
> + drm_mm_remove_node(&tmp);
> + pr_err("impossible insert succeeded, start
> %llu\n",
> + Â Â Â Â Â Â Â tmp.start);
> + goto out;
> + }
> + }
> +
Second instance of the code below, could be helper?
> + m = 0;
> + drm_mm_for_each_node(node, &mm) {
> + if (node->start != m * size) {
> + pr_err("node %d out of order, expected start
> %llx, found %llx\n",
> + Â Â Â Â Â Â Â m, m * size, node->start);
> + goto out;
> + }
> +
> + if (node->size != size) {
> + pr_err("node %d has wrong size, expected size
> %llx, found %llx\n",
> + Â Â Â Â Â Â Â m, size, node->size);
> + goto out;
> + }
> +
> + if (node->hole_follows) {
> + pr_err("node %d is followed by a hole!\n", m);
> + goto out;
> + }
> +
> + m++;
> + }
> + }
> +
I still do not have a solid opinion what is a decent amount of
iterations to do at each place.
With the helper isolated;
Reviewed-by: Joonas Lahtinen
Regards, Joonas
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
[RFC 0/4] Introduce drmfs pseudo filesystem for drm subsystem
On Mon, 2016-12-12 at 07:33 -0800, Alex Deucher wrote: > On Mon, Dec 12, 2016 at 1:14 AM, sourab gupta > wrote: > > On Mon, 2016-12-05 at 03:06 -0800, Dhingra, Swati wrote: > >> From: Swati Dhingra > >> > >> Currently, we don't have a stable ABI which can be used for the purpose of > >> providing output debug/loggging/crc and other such data from DRM. > >> The ABI in current use (filesystems, ioctls, et al.) have their own > >> constraints and are intended to output a particular type of data. > >> Few cases in point: > >> sysfs - stable ABI, but constrained to one textual value per file > >> debugfs - unstable ABI, free-for-all > >> ioctls - not as suitable to many single purpose continuous data > >> dumping, we would very quickly run out ioctl space; requires more > >> userspace support than "cat" > >> device nodes - a real possibilty, kernel instantiation is more tricky, > >> requires udev (+udev.rules) or userspace discovery of the > >> dynamic major:minor (via sysfs) [mounting a registered > >> filesystem is easy in comparison] > >> netlink - stream based, therefore involves numerous copies. > >> > >> Debugfs is the lesser among the evils here, thereby we have grown used to > >> the > >> convenience and flexibility in presentation that debugfs gives us > >> (including relayfs inodes) that we want some of that hierachy in stable > >> user > >> ABI form. > >> > >> Due to these limitations, there is a need for a new pseudo filesytem, that > >> would act as a stable 'free-for-all' ABI, with the heirarchial structure > >> and > >> thus convenience of debugfs. This will be managed by drm, thus named > >> 'drmfs'. > >> DRM would register this filesystem to manage a canonical mountpoint, but > >> this > >> wouldn't limit everyone to only using that pseudofs underneath. > >> > >> This can serve to hold various kinds of output data from Linux DRM > >> subsystems, > >> for the files which can't truely fit anywhere else with existing ABI's but > >> present so, for the lack of a better place. > >> > >> In this patch series, we have introduced a pseudo filesystem named as > >> 'drmfs' > >> for now. The filesystem is introduced in the first patch, and the > >> subsequent > >> patches make use of the filesystem interfaces, in drm driver, and making > >> them > >> available for use by the drm subsystem components, one of which is i915. > >> We've moved the location of i915 GuC logs from debugfs to drmfs in the last > >> patch. Subsequently, more such files such as pipe_crc, error states, memory > >> stats, etc. can be move to this filesystem, if the idea introduced here is > >> acceptable per se. The filesystem introduced is being used to house the > >> data > >> generated by i915 driver in this patch series, but will hopefully be > >> generic > >> enough to provide scope for usage by any other drm subsystem component. > >> > >> The patch series is being floated as RFC to gather feedback on the idea and > >> infrastructure proposed here and it's suitability to address the specific > >> problem statement/use case. > >> > >> TODO: Create documentation. Will do so in next version. > >> > >> v2: fix the bat failures caused due to missing config check > >> > >> v3: Changes made: > >> - Move the location of drmfs from fs/ to drivers/gpu/drm/ (Chris) > >> - Moving config checks to header (Chris,Daniel) > >> > >> > >> Sourab Gupta (4): > >> drm: Introduce drmfs pseudo filesystem interfaces > >> drm: Register drmfs filesystem from drm init > >> drm: Create driver specific root directory inside drmfs > >> drm/i915: Creating guc log file in drmfs instead of debugfs > >> > >> drivers/gpu/drm/Kconfig| 9 + > >> drivers/gpu/drm/Makefile | 1 + > >> drivers/gpu/drm/drm_drv.c | 12 + > >> drivers/gpu/drm/drmfs.c| 555 > >> + > >> drivers/gpu/drm/i915/i915_guc_submission.c | 33 +- > >> include/drm/drm_drv.h | 3 + > >> include/drm/drmfs.h| 77 > >> include/uapi/linux/magic.h | 3 + > >> 8 files changed, 672 insertions(+), 21 deletions(-) > >> create mode 100644 drivers/gpu/drm/drmfs.c > >> create mode 100644 include/drm/drmfs.h > >> > >> -- > >> 2.7.4 > >> > > > > Hi dri-devel folks, > > > > Any feedback on the proposed drmfs infrastructure being proposed here? > > I haven't looked too closely, but so far we haven't run into anything > that we haven't been able to support via some combination of sysfs and > debugfs. > > Alex Hi Alex, The intent here is to introduce a stable free-for-all ABI which has the hierarchical structure and convenience of debugfs. One of the possible candidate/usecase here is for holding the GuC (micro-controller) logs. Currently, we're using relayfs to provide these logs to userspace. Relayfs needs a parent dentry to be assoc
[PATCH v2 0/4] drm/atomic: Add accessor macros for all atomic state.
On Wed, Nov 16, 2016 at 02:58:04PM +0100, Maarten Lankhorst wrote: > Second approach. Instead of trying to convert all drivers straight away, > implement all macros that are required to get state working. > > Current situation: > Use obj->state, which can refer to old or new state. > Use drm_atomic_get_(existing_)obj_state, which can refer to new or old state. > Use for_each_obj_in_state, which refers to new or old state. > > New situation: > When doing some dereferencing outside atomic_state, use > drm_atomic_get_current_obj_state which has locking checks, instead of > obj->state. > > During atomic check: > - Use drm_atomic_get_obj_state to add a object to the atomic state, > or get the new state. > - Use drm_atomic_get_(old/new)_obj_state to peek at the new/old state, > without adding the object if it's not part of the state. For planes > and connectors the relevant crtc_state is added, so this will work to > get the crtc_state from foo_state->crtc too, saves some error handling. :) > > During atomic commit: > - Do not use drm_atomic_get_obj_state, obj->state or > drm_atomic_get_(existing_)obj_state > any more, replace with drm_atomic_get_old/new_obj_state calls as required. > > During both: > - Use for_each_(new,old,oldnew)_obj_in_state to get the old or new state as > needed. > oldnew will be renamed to for_each_obj_in_state after all callers are > converted > to the new api. > > This will give the correct state regardless of swapping. So this is all nice, but fundamentally it's pile of new code with 0 users. Where are those patches? I think at least converting all the core+helpers to use it consistently would be needed to justify this. -Daniel > > Maarten Lankhorst (4): > drm/atomic: Add new iterators over all state, v2. > drm/atomic: Add accessor macros for the current state. > drm/atomic: Add macros to access existing old/new state > drm/atomic: Add checks to ensure get_state is not called after > swapping. > > drivers/gpu/drm/drm_atomic.c | 24 +++- > drivers/gpu/drm/drm_atomic_helper.c | 47 ++- > drivers/gpu/drm/i915/intel_display.c | 11 +- > include/drm/drm_atomic.h | 247 > ++- > include/drm/drm_atomic_helper.h | 2 + > include/drm/drm_modeset_lock.h | 21 +++ > 6 files changed, 338 insertions(+), 14 deletions(-) > > -- > 2.7.4 > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[PATCH v2.1 2/4] drm/atomic: Add accessor macros for the current state, v2.
On Thu, Nov 17, 2016 at 02:20:10PM +0100, Maarten Lankhorst wrote:
> With checks! This will allow safe access to the current state,
> while ensuring that the correct locks are held.
>
> Changes since v1:
> - Constify returned states.
> - Require plane lock to return plane state, don't allow crtc_lock to
> be sufficient.
>
> Signed-off-by: Maarten Lankhorst
> ---
> diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h
> index e527684dd394..9af5aba8c27c 100644
> --- a/include/drm/drm_atomic.h
> +++ b/include/drm/drm_atomic.h
> @@ -334,6 +334,66 @@ __drm_atomic_get_current_plane_state(struct
> drm_atomic_state *state,
> return plane->state;
> }
>
> +
> +/**
> + * drm_atomic_get_current_plane_state - get current plane state
> + * @plane: plane to grab
> + *
> + * This function returns the current plane state for the given plane,
> + * with extra locking checks to make sure that the plane state can be
> + * retrieved safely.
> + *
> + * Returns:
> + *
> + * Pointer to the current plane state.
> + */
> +static inline const struct drm_plane_state *
> +drm_atomic_get_current_plane_state(struct drm_plane *plane)
> +{
> + drm_modeset_lock_assert_held(&plane->mutex);
> +
> + return plane->state;
> +}
> +
> +/**
> + * drm_atomic_get_current_crtc_state - get current crtc state
> + * @crtc: crtc to grab
> + *
> + * This function returns the current crtc state for the given crtc,
> + * with extra locking checks to make sure that the crtc state can be
> + * retrieved safely.
> + *
> + * Returns:
> + *
> + * Pointer to the current crtc state.
> + */
> +static inline const struct drm_crtc_state *
> +drm_atomic_get_current_crtc_state(struct drm_crtc *crtc)
> +{
> + drm_modeset_lock_assert_held(&crtc->mutex);
> +
> + return crtc->state;
> +}
> +
> +/**
> + * drm_atomic_get_current_connector_state - get current connector state
> + * @connector: connector to grab
> + *
> + * This function returns the current connector state for the given connector,
> + * with extra locking checks to make sure that the connector state can be
> + * retrieved safely.
> + *
> + * Returns:
> + *
> + * Pointer to the current connector state.
> + */
> +#define drm_atomic_get_current_connector_state(connector) \
> +({ /* Implemented as macro to avoid including drmP for struct drm_device */ \
Imo that's not a terrible good reason. Eventually will split drm_device.h
out from drmP.h, and then we can nuke the additional include. Can you pls
respin?
-Daniel
> + struct drm_connector *con__ = (connector); \
> +
> drm_modeset_lock_assert_held(&con__->dev->mode_config.connection_mutex); \
> + (const struct drm_connector_state *)con__->state; \
> +})
> +
> int __must_check
> drm_atomic_set_mode_for_crtc(struct drm_crtc_state *state,
>struct drm_display_mode *mode);
> diff --git a/include/drm/drm_modeset_lock.h b/include/drm/drm_modeset_lock.h
> index d918ce45ec2c..3ca4ee838b07 100644
> --- a/include/drm/drm_modeset_lock.h
> +++ b/include/drm/drm_modeset_lock.h
> @@ -109,6 +109,15 @@ static inline bool drm_modeset_is_locked(struct
> drm_modeset_lock *lock)
> return ww_mutex_is_locked(&lock->mutex);
> }
>
> +static inline void drm_modeset_lock_assert_held(struct drm_modeset_lock
> *lock)
> +{
> +#ifdef CONFIG_LOCKDEP
> + lockdep_assert_held(&lock->mutex.base);
> +#else
> + WARN_ON(!drm_modeset_is_locked(lock));
> +#endif
> +}
> +
> int drm_modeset_lock(struct drm_modeset_lock *lock,
> struct drm_modeset_acquire_ctx *ctx);
> int drm_modeset_lock_interruptible(struct drm_modeset_lock *lock,
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[Bug 98914] mesa-vdpau-drivers: breaks vdpau for mpeg2video
https://bugs.freedesktop.org/show_bug.cgi?id=98914 --- Comment #11 from Christian König --- Created attachment 128472 --> https://bugs.freedesktop.org/attachment.cgi?id=128472&action=edit Possible fix The reason I've wondered that somebody is still using this is that code is only used by very old hardware generation which don't have native MPEG2 support. Anyway, please confirm that the attached patch fixes the problem and I will commit it. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161214/d1b0183e/attachment.html>
[PATCH v2 0/7] Host1x IOMMU support + VIC support
On Wed, Dec 14, 2016 at 02:41:28PM +0200, Mikko Perttunen wrote: > On 14.12.2016 14:30, Daniel Vetter wrote: > > On Wed, Dec 14, 2016 at 01:16:10PM +0200, Mikko Perttunen wrote: > > > This series adds IOMMU support to Host1x and TegraDRM > > > and adds support for the VIC (Video Image Compositor) > > > host1x client. The series is available as a git repository at > > > git://github.com/cyndis/linux.git; branch vic-2. > > > > > > A userspace test case for VIC can be found at > > > https://github.com/cyndis/drm/tree/work/tegra. > > > The testcase is in tests/tegra and is called submit_vic. > > > The testcase/TRM include full headers and documentation > > > to program the unit. The unit by itself, however, does not > > > readily map to existing userspace library interfaces, so > > > implementations for those are not provided. > > > > Afaik libva has an entire pile of post-processing support. Pretty sure > > other video transcode libraries have similar interfaces, so should all be > > possible to implement this. > > We don't have any actual video transcoding support though, so unless it's > possible to just implement a part of libva and defer the rest to some CPU > implementation, I don't see how this is useful. I suppose I could implement > a GStreamer plugin for colorspace conversion or resizing, since those are > very modular. Hm, I guess the question then is, how did that get enabled? > > Until that exists I really think that the VIC part (and only that, since > > tk1/tx1 in general seems to work with nouveau and all that) should stay > > out of tree. > > Ok. I'll try to whip up something. But yeah some gstreamer thing might be doable, but not sure they take that (I don't have any contacts there). Video is a bit a mess, there's no clear go-to place for dropping some new hw support. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[PATCH 03/34] drm: Add drm_mm_for_each_node_safe()
On ke, 2016-12-14 at 11:39 +, Chris Wilson wrote: > On Tue, Dec 13, 2016 at 11:35:42AM +0200, Joonas Lahtinen wrote: > > > > On ma, 2016-12-12 at 11:53 +, Chris Wilson wrote: > > > > > > +#define __drm_mm_nodes(mm) (&(mm)->head_node.node_list) > > > > Not static inline for type checking? > > I was going to make it static inline, then realised the #define makes it > work cleanly with a const drm_mm. Fair enough. Regards, Joonas -- Joonas Lahtinen Open Source Technology Center Intel Corporation
[PATCH 10/34] drm: kselftest for drm_mm_replace_node()
On ma, 2016-12-12 at 11:53 +, Chris Wilson wrote:
> Reuse drm_mm_insert_node() with a temporary node to exercise
> drm_mm_replace_node(). We use the previous test in order to exercise the
> various lists following replacement.
>
> Signed-off-by: Chris Wilson
> +static int __igt_insert(int count, u64 size, bool replace)
> Â {
> Â u32 lcg_state = random_seed;
> Â struct drm_mm mm;@@ -264,9 +264,10 @@ static int __igt_insert(int
> count, u64 size)
> Â }
> Â
> Â for (n = 0; n < count; n++) {
> + struct drm_mm_node tmp, *node;
> Â int err;
> Â
> - node = &nodes[n];
> + node = memset(replace ? &tmp : &nodes[n], 0, sizeof(*node));
Just memset in a separate line for readability.
> @@ -281,6 +282,20 @@ static int __igt_insert(int count, u64 size)
> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â n, node->start);
> Â Â Â Â Â Â Â Â Â Â Â Â goto out;
> Â Â Â Â Â Â Â Â }
> +
> +Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â if (replace) {
> +Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â drm_mm_replace_node(&tmp,
> &nodes[n]);
> +Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â if
> (!drm_mm_node_allocated(&nodes[n])) {
> +Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
> pr_err("replaced new-node not allocated! step %d\n",
> +Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
> n);
> +Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â goto out;
> +Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â }
Maybe go the extra mile and make sure the start and size still match
after replacement.
Reviewed-by: Joonas Lahtinen
Regards, Joonas
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
[PATCH 2/2] stih-cec: add hdmi-notifier support
By using the HDMI notifier framework there is no longer any reason
to manually set the physical address. This was the one blocking
issue that prevented this driver from going out of staging, so do
this move as well.
Update the bindings documenting the new hdmi phandle and
update stih410.dtsi and stih407-family.dtsi accordingly.
Signed-off-by: Benjamin Gaignard
---
.../devicetree/bindings/media/stih-cec.txt | 2 ++
arch/arm/boot/dts/stih407-family.dtsi | 12 -
arch/arm/boot/dts/stih410.dtsi | 15 ++-
drivers/staging/media/st-cec/Kconfig | 1 +
drivers/staging/media/st-cec/stih-cec.c| 29 +-
5 files changed, 45 insertions(+), 14 deletions(-)
diff --git a/Documentation/devicetree/bindings/media/stih-cec.txt
b/Documentation/devicetree/bindings/media/stih-cec.txt
index 71c4b2f..7d82121 100644
--- a/Documentation/devicetree/bindings/media/stih-cec.txt
+++ b/Documentation/devicetree/bindings/media/stih-cec.txt
@@ -9,6 +9,7 @@ Required properties:
- pinctrl-names: Contains only one value - "default"
- pinctrl-0: Specifies the pin control groups used for CEC hardware.
- resets: Reference to a reset controller
+ - st,hdmi-handle: Phandle to the HMDI controller
Example for STIH407:
@@ -22,4 +23,5 @@ sti-cec at 094a087c {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_cec0_default>;
resets = <&softreset STIH407_LPM_SOFTRESET>;
+ st,hdmi-handle = <&hdmi>;
};
diff --git a/arch/arm/boot/dts/stih407-family.dtsi
b/arch/arm/boot/dts/stih407-family.dtsi
index 8f79b41..ef7c79a 100644
--- a/arch/arm/boot/dts/stih407-family.dtsi
+++ b/arch/arm/boot/dts/stih407-family.dtsi
@@ -756,18 +756,6 @@
<&clk_s_c0_flexgen CLK_ETH_PHY>;
};
- cec: sti-cec at 094a087c {
- compatible = "st,stih-cec";
- reg = <0x94a087c 0x64>;
- clocks = <&clk_sysin>;
- clock-names = "cec-clk";
- interrupts = ;
- interrupt-names = "cec-irq";
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_cec0_default>;
- resets = <&softreset STIH407_LPM_SOFTRESET>;
- };
-
rng10: rng at 08a89000 {
compatible = "st,rng";
reg = <0x08a89000 0x1000>;
diff --git a/arch/arm/boot/dts/stih410.dtsi b/arch/arm/boot/dts/stih410.dtsi
index a3ef734..c98d86e 100644
--- a/arch/arm/boot/dts/stih410.dtsi
+++ b/arch/arm/boot/dts/stih410.dtsi
@@ -193,7 +193,7 @@
<&clk_s_d2_quadfs 0>;
};
- sti-hdmi at 8d04000 {
+ hdmi: sti-hdmi at 8d04000 {
compatible = "st,stih407-hdmi";
reg = <0x8d04000 0x1000>;
reg-names = "hdmi-reg";
@@ -259,5 +259,18 @@
clocks = <&clk_sysin>;
interrupts = ;
};
+
+ sti-cec at 094a087c {
+ compatible = "st,stih-cec";
+ reg = <0x94a087c 0x64>;
+ clocks = <&clk_sysin>;
+ clock-names = "cec-clk";
+ interrupts = ;
+ interrupt-names = "cec-irq";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_cec0_default>;
+ resets = <&softreset STIH407_LPM_SOFTRESET>;
+ st,hdmi-handle = <&hdmi>;
+ };
};
};
diff --git a/drivers/staging/media/st-cec/Kconfig
b/drivers/staging/media/st-cec/Kconfig
index 784d2c6..3072387 100644
--- a/drivers/staging/media/st-cec/Kconfig
+++ b/drivers/staging/media/st-cec/Kconfig
@@ -1,6 +1,7 @@
config VIDEO_STI_HDMI_CEC
tristate "STMicroelectronics STiH4xx HDMI CEC driver"
depends on VIDEO_DEV && MEDIA_CEC && (ARCH_STI || COMPILE_TEST)
+ select HDMI_NOTIFIERS
---help---
This is a driver for STIH4xx HDMI CEC interface. It uses the
generic CEC framework interface.
diff --git a/drivers/staging/media/st-cec/stih-cec.c
b/drivers/staging/media/st-cec/stih-cec.c
index 2143448..ce94097 100644
--- a/drivers/staging/media/st-cec/stih-cec.c
+++ b/drivers/staging/media/st-cec/stih-cec.c
@@ -10,11 +10,13 @@
* (at your option) any later version.
*/
#include
+#include
#include
#include
#include
#include
#include
+#include
#include
#include
@@ -130,6 +132,7 @@ struct stih_cec {
void __iomem*regs;
int irq;
u32 irq_status;
+ struct hdmi_notifier*notifier;
};
static int stih_cec_ad
[PATCH 1/2] sti: hdmi: add HDMI notifier support
Implement the HDMI notifier support to allow CEC drivers to
be informed when there is a new EDID and when a connect or
disconnect happens.
Signed-off-by: Benjamin Gaignard
---
drivers/gpu/drm/sti/Kconfig| 1 +
drivers/gpu/drm/sti/sti_hdmi.c | 15 +++
drivers/gpu/drm/sti/sti_hdmi.h | 2 ++
3 files changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/sti/Kconfig b/drivers/gpu/drm/sti/Kconfig
index acd7286..59ceffc 100644
--- a/drivers/gpu/drm/sti/Kconfig
+++ b/drivers/gpu/drm/sti/Kconfig
@@ -8,5 +8,6 @@ config DRM_STI
select DRM_PANEL
select FW_LOADER
select SND_SOC_HDMI_CODEC if SND_SOC
+ select HDMI_NOTIFIERS
help
Choose this option to enable DRM on STM stiH4xx chipset
diff --git a/drivers/gpu/drm/sti/sti_hdmi.c b/drivers/gpu/drm/sti/sti_hdmi.c
index 376b076..6667371 100644
--- a/drivers/gpu/drm/sti/sti_hdmi.c
+++ b/drivers/gpu/drm/sti/sti_hdmi.c
@@ -786,6 +786,8 @@ static void sti_hdmi_disable(struct drm_bridge *bridge)
clk_disable_unprepare(hdmi->clk_pix);
hdmi->enabled = false;
+
+ hdmi_event_disconnect(hdmi->notifier);
}
static void sti_hdmi_pre_enable(struct drm_bridge *bridge)
@@ -892,6 +894,10 @@ static int sti_hdmi_connector_get_modes(struct
drm_connector *connector)
if (!edid)
goto fail;
+ hdmi_event_connect(hdmi->notifier);
+ hdmi_event_new_edid(hdmi->notifier, edid,
+ EDID_LENGTH * (edid->extensions + 1));
+
count = drm_add_edid_modes(connector, edid);
drm_mode_connector_update_edid_property(connector, edid);
drm_edid_to_eld(connector, edid);
@@ -949,10 +955,12 @@ struct drm_connector_helper_funcs
sti_hdmi_connector_helper_funcs = {
if (hdmi->hpd) {
DRM_DEBUG_DRIVER("hdmi cable connected\n");
+ hdmi_event_connect(hdmi->notifier);
return connector_status_connected;
}
DRM_DEBUG_DRIVER("hdmi cable disconnected\n");
+ hdmi_event_disconnect(hdmi->notifier);
return connector_status_disconnected;
}
@@ -1464,6 +1472,10 @@ static int sti_hdmi_probe(struct platform_device *pdev)
goto release_adapter;
}
+ hdmi->notifier = hdmi_notifier_get(&pdev->dev);
+ if (!hdmi->notifier)
+ goto release_adapter;
+
hdmi->reset = devm_reset_control_get(dev, "hdmi");
/* Take hdmi out of reset */
if (!IS_ERR(hdmi->reset))
@@ -1483,11 +1495,14 @@ static int sti_hdmi_remove(struct platform_device *pdev)
{
struct sti_hdmi *hdmi = dev_get_drvdata(&pdev->dev);
+ hdmi_event_disconnect(hdmi->notifier);
+
i2c_put_adapter(hdmi->ddc_adapt);
if (hdmi->audio_pdev)
platform_device_unregister(hdmi->audio_pdev);
component_del(&pdev->dev, &sti_hdmi_ops);
+ hdmi_notifier_put(hdmi->notifier);
return 0;
}
diff --git a/drivers/gpu/drm/sti/sti_hdmi.h b/drivers/gpu/drm/sti/sti_hdmi.h
index 119bc35..70aac98 100644
--- a/drivers/gpu/drm/sti/sti_hdmi.h
+++ b/drivers/gpu/drm/sti/sti_hdmi.h
@@ -8,6 +8,7 @@
#define _STI_HDMI_H_
#include
+#include
#include
#include
@@ -102,6 +103,7 @@ struct sti_hdmi {
struct platform_device *audio_pdev;
struct hdmi_audio_params audio;
struct drm_connector *drm_connector;
+ struct hdmi_notifier *notifier;
};
u32 hdmi_read(struct sti_hdmi *hdmi, int offset);
--
1.9.1
[PATCH 0/2] video/sti/cec: add HDMI notifier support
Following (copying !) what Hans have done in this serie of patches http://www.spinics.net/lists/linux-media/msg109141.html I have implemented hdmi notifier in hdmi controled and stih-cec drivers. Those patches should be applied on top of Hans patches for exynos. I have tested hdmi notifier by pluging/unpluging HDMI cable and check the value of the physical address with "cec-ctl --tuner". "cec-compliance -A" is also functional. Hans, I haven't move stih-cec out of staging because I don't have the exact branch to test it, can you do the move for stih-cec after applying those patches ? Regards, Benjamin Benjamin Gaignard (2): sti: hdmi: add HDMI notifier support stih-cec: add hdmi-notifier support .../devicetree/bindings/media/stih-cec.txt | 2 ++ arch/arm/boot/dts/stih407-family.dtsi | 12 - arch/arm/boot/dts/stih410.dtsi | 15 ++- drivers/gpu/drm/sti/Kconfig| 1 + drivers/gpu/drm/sti/sti_hdmi.c | 15 +++ drivers/gpu/drm/sti/sti_hdmi.h | 2 ++ drivers/staging/media/st-cec/Kconfig | 1 + drivers/staging/media/st-cec/stih-cec.c| 29 +- 8 files changed, 63 insertions(+), 14 deletions(-) -- 1.9.1
[PATCH v2 1/7] drm/tegra: Add Tegra DRM allocation API
Am Mittwoch, den 14.12.2016, 14:36 +0200 schrieb Mikko Perttunen:
> On 14.12.2016 13:35, Lucas Stach wrote:
> > Am Mittwoch, den 14.12.2016, 13:16 +0200 schrieb Mikko Perttunen:
> >> Add a new IO virtual memory allocation API to allow clients to
> >> allocate non-GEM memory in the Tegra DRM IOMMU domain. This is
> >> required e.g. for loading client firmware when clients are attached
> >> to the IOMMU domain.
> >>
> >> The allocator allocates contiguous physical pages that are then
> >> mapped contiguously to the IOMMU domain using the iova_domain
> >> library provided by the kernel. Contiguous physical pages are
> >> used so that the same allocator works also when IOMMU support
> >> is disabled and therefore devices access physical memory directly.
> >>
> > Why is this needed? If you use the DMA API for those buffers you should
> > end up with CMA memory in the !IOMMU case and normal paged memory with
> > IOMMU enabled. From my understanding this should match the requirements.
>
> Yes, memory allocated with the DMA API should work as well, but would
> also require passing the device pointer for the device that is
> allocating the memory, which isn't a problem, but this way we don't need
> that.
>
Which in turn would allow you to properly describe the DMA capabilities
of engines that can address more than 32 bits without the IOMMU, which
was one of the comments Thierry had the last time around IIRC.
> >
> > Also how big can those firmware images get? Will __get_free_pages be
> > able to provide this much contig memory in a long running system with
> > fragmented memory space? Isn't CMA the better option here?
>
> The largest is about 140 kilobytes. The space is also allocated when the
> device is initialized which usually happens during boot.
>
Which is an order 6 allocation, something you almost certainly don't get
in a fragmented system. I know it may work most of the time, as you are
allocating those buffers early, but is most of the time really enough?
What happens on module unload/load at a later time?
> >
> > Regards,
> > Lucas
>
> Thanks,
> Mikko.
>
> >
> >> Signed-off-by: Mikko Perttunen
> >> ---
> >> drivers/gpu/drm/tegra/drm.c | 111
> >> +---
> >> drivers/gpu/drm/tegra/drm.h | 11 +
> >> 2 files changed, 115 insertions(+), 7 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
> >> index b8be3ee..cf714c6 100644
> >> --- a/drivers/gpu/drm/tegra/drm.c
> >> +++ b/drivers/gpu/drm/tegra/drm.c
> >> @@ -1,12 +1,13 @@
> >> /*
> >> * Copyright (C) 2012 Avionic Design GmbH
> >> - * Copyright (C) 2012-2013 NVIDIA CORPORATION. All rights reserved.
> >> + * Copyright (C) 2012-2016 NVIDIA CORPORATION. All rights reserved.
> >> *
> >> * This program is free software; you can redistribute it and/or modify
> >> * it under the terms of the GNU General Public License version 2 as
> >> * published by the Free Software Foundation.
> >> */
> >>
> >> +#include
> >> #include
> >> #include
> >>
> >> @@ -23,6 +24,8 @@
> >> #define DRIVER_MINOR 0
> >> #define DRIVER_PATCHLEVEL 0
> >>
> >> +#define CARVEOUT_SZ SZ_64M
> >> +
> >> struct tegra_drm_file {
> >>struct list_head contexts;
> >> };
> >> @@ -127,7 +130,8 @@ static int tegra_drm_load(struct drm_device *drm,
> >> unsigned long flags)
> >>
> >>if (iommu_present(&platform_bus_type)) {
> >>struct iommu_domain_geometry *geometry;
> >> - u64 start, end;
> >> + unsigned long order;
> >> + u64 carveout_start, carveout_end, gem_start, gem_end;
> >>
> >>tegra->domain = iommu_domain_alloc(&platform_bus_type);
> >>if (!tegra->domain) {
> >> @@ -136,12 +140,25 @@ static int tegra_drm_load(struct drm_device *drm,
> >> unsigned long flags)
> >>}
> >>
> >>geometry = &tegra->domain->geometry;
> >> - start = geometry->aperture_start;
> >> - end = geometry->aperture_end;
> >> + gem_start = geometry->aperture_start;
> >> + gem_end = geometry->aperture_end - CARVEOUT_SZ;
> >> + carveout_start = gem_end + 1;
> >> + carveout_end = geometry->aperture_end;
> >> +
> >> + order = __ffs(tegra->domain->pgsize_bitmap);
> >> + init_iova_domain(&tegra->carveout.domain, 1UL << order,
> >> + carveout_start >> order,
> >> + carveout_end >> order);
> >> +
> >> + tegra->carveout.shift = iova_shift(&tegra->carveout.domain);
> >> + tegra->carveout.limit = carveout_end >> tegra->carveout.shift;
> >> +
> >> + drm_mm_init(&tegra->mm, gem_start, gem_end - gem_start + 1);
> >>
> >> - DRM_DEBUG_DRIVER("IOMMU aperture initialized (%#llx-%#llx)\n",
> >> - start, end);
> >> - drm_mm_init(&tegra->mm, start, end - start + 1);
> >> + DRM_DEBUG("IOMMU apertures:\n");
> >> + DRM_DEBUG(" GEM
[PATCH/RFC 6/7] drm: omapdrm: Register omapdrm platform device in omapdss driver
Hi Tomi,
On Wednesday 14 Dec 2016 10:20:39 Tomi Valkeinen wrote:
> On 14/12/16 01:38, Laurent Pinchart wrote:
> > The omapdrm platform device is a virtual device created for the sole
> > purpose of handling the omapdss/omapdrm driver split. It should
> > eventually be removed. As a first step to ease refactoring move its
> > registration from platform code to driver code.
> >
> > The omapdrm driver name must be changed internally to avoid probing both
> > the device registered in platform code and the device registered in the
> > omapdss driver, as that would otherwise break bisection.
> >
> > Signed-off-by: Laurent Pinchart
> > ---
> > drivers/gpu/drm/omapdrm/dss/core.c | 17 +
> > drivers/gpu/drm/omapdrm/omap_drv.c | 2 +-
> > 2 files changed, 18 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/omapdrm/dss/core.c
> > b/drivers/gpu/drm/omapdrm/dss/core.c index 1bf978b5c5bc..b7c44b85b7c3
> > 100644
> > --- a/drivers/gpu/drm/omapdrm/dss/core.c
> > +++ b/drivers/gpu/drm/omapdrm/dss/core.c
[snip]
> > @@ -285,6 +286,16 @@ static void (*dss_output_drv_unreg_funcs[])(void) = {
> >
> > dss_uninit_platform_driver,
> >
> > };
> >
> > +#if IS_ENABLED(CONFIG_DRM_OMAP)
>
> The #ifs are not needed, don't compile this file if there's no DRM_OMAP.
Right, for a moment I forgot that the dss core isn't shared anymore between
DRM and FBDEV. I'll fix this.
> > +static struct platform_device omap_drm_device = {
> > + .dev = {
> > + .coherent_dma_mask = DMA_BIT_MASK(32),
> > + },
> > + .name = "omapdrm_",
> > + .id = 0,
> > +};
> > +#endif
> > +
> > static int __init omap_dss_init(void)
> > {
> > int r;
> > @@ -300,6 +311,12 @@ static int __init omap_dss_init(void)
> > goto err_reg;
> > }
> >
> > +#if IS_ENABLED(CONFIG_DRM_OMAP)
> > + r = platform_device_register(&omap_drm_device);
> > + if (r)
> > + goto err_reg;
> > +#endif
>
> Where is the unregister?
Oops. Will fix too.
--
Regards,
Laurent Pinchart
[PATCH 16/34] drm: kselftest for drm_mm and top-down alignment
On ma, 2016-12-12 at 11:53 +, Chris Wilson wrote:
> Check that if we request top-down allocation with a particular alignment
> from drm_mm_insert_node() that the start of the node matches our
> request.
>
> Signed-off-by: Chris Wilson
Assuming magic numbers be gone in next iteration.
> +static int igt_topdown_align(void *ignored)
> +{
> + struct drm_mm mm;
> + struct drm_mm_node tmp, resv;
> + int ret = -EINVAL;
> + int n, m, err;
> +
> + drm_mm_init(&mm, 0, ~0ull);
> + memset(&tmp, 0, sizeof(tmp));
> + memset(&resv, 0, sizeof(resv));
> +
> + for (m = 0; m < 32; m++) {
> + u64 end = ~0ull;
> +
> + if (m) {
> + resv.size = BIT_ULL(m);
> + end -= resv.size;
> + resv.start = end;
> +
> + err = drm_mm_reserve_node(&mm, &resv);
> + if (err) {
> + pr_err("reservation of sentinel node failed\n");
> + ret = err;
> + goto out;
> + }
> + }
> +
> + for (n = 0; n < 63 - m; n++) {
> + u64 align = BIT_ULL(n);
DRM_MM_BUG_ON(end %Â align); to protect somebody from modifying? (or end
& (align - 1))
> +
> + err = drm_mm_insert_node_generic(&mm, &tmp, 1, align, 0,
> + Â DRM_MM_SEARCH_BELOW,
> + Â DRM_MM_CREATE_TOP);
> + drm_mm_remove_node(&tmp);
Could move this after if (err) again and in the rest of the code, too.
Reviewed-by: Joonas Lahtinen
Regards, Joonas
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
[PATCH v4 00/22] OMAP DRM fixes and improvements
Hi Tomi, On Wednesday 14 Dec 2016 10:48:06 Tomi Valkeinen wrote: > On 14/12/16 02:27, Laurent Pinchart wrote: > > Hello, > > > > Here's the fourth version of my current stack of pending patches for the > > omapdrm driver. > > > > All comments received for v3 have been considered and patches updated > > where applicable. Patches 21/22 and 22/22 have been added, individual > > changelogs are available in all the patches when they have been modified. > > > > The most notable change in this series is still the rework of the IRQ > > handling code (patches 06/22 to 19/22) that, beside simplifying the code, > > ensures that the vblank count and timestamp get updated properly in order > > to be reported to userspace. > > > > The series is based on top of Dave's drm-next branch. > > I got the following when unloading omapdrm modules, AM5 EVM with two > displays: This should be fixed by "[PATCH] drm: Move vblank cleanup from unregister to release" that I posted earlier today. > > [ 758.762147] [ cut here ] > [ 758.767157] WARNING: CPU: 1 PID: 314 at drivers/gpu/drm/drm_irq.c:349 > drm_vblank_cleanup+0x5c/0x94 [drm] [ 758.781401] Modules linked in: > omapdrm(-) drm_kms_helper drm panel_dsi_cm panel_dpi connector_analog_tv > connector_dvi connecto r_hdmi encoder_tpd12s015 encoder_tfp410 omapdss > cfbfillrect cfbimgblt cfbcopyarea [last unloaded: omapdss_base] [ > 758.803761] CPU: 1 PID: 314 Comm: rmmod Not tainted > 4.9.0-rc8-00106-g8df5349534c6 #53 [ 758.811631] Hardware name: Generic > DRA74X (Flattened Device Tree) [ 758.817755] Backtrace: > [ 758.820240] [] (dump_backtrace) from [] > (show_stack+0x18/0x1c) [ 758.827851] r7:c0d830d8 r6:60030013 r5: > r4:c0d830d8 > [ 758.833546] [] (show_stack) from [] > (dump_stack+0xa8/0xdc) [ 758.840813] [] (dump_stack) from > [] (__warn+0xdc/0x108) [ 758.847814] r9:bf1fefc0 r8:015d > r7:0009 r6:bf229b84 r5: r4: [ 758.855602] [] > (__warn) from [] (warn_slowpath_null+0x28/0x30) [ 758.863230] > r9:015d r8:bf229b84 r7:ee145000 r6: r5: r4:ed22aa00 .[ > 758.871173] [] (warn_slowpath_null) from [] > (drm_vblank_cleanup+0x5c/0x94 [drm]) [ 758.880586] [] > (drm_vblank_cleanup [drm]) from [] (drm_dev_unregister+0x58/0xbc > [drm]) [ 758.890291] r9:ed3b4000 r8:c0ddb380 r7: r6:ee145000 > r5:ee145000 r4:ee145000 [ 758.898201] [] (drm_dev_unregister > [drm]) from [] (pdev_remove+0x2c/0x90 [omapdrm]) [ 758.907643] > r7: r6:c0d0c25c r5:ed233000 r4:ee145000 > [ 758.913357] [] (pdev_remove [omapdrm]) from [] > (platform_drv_remove+0x2c/0x44) [ 758.922362] r5:c0d0c228 r4:c0d0c228 > [ 758.925964] [] (platform_drv_remove) from [] > (__device_release_driver+0x90/0x12c) [ 758.935229] r5:bf2b64e4 > r4:c0d0c228 > [ 758.938829] [] (__device_release_driver) from [] > (driver_detach+0xc0/0xc4) [ 758.947484] r5:bf2b64e4 r4:c0d0c228 > [ 758.951084] [] (driver_detach) from [] > (bus_remove_driver+0x64/0xdc) [ 758.959217] r7:c0b3bbfc r6:c0ddb368 > r5:bf2b42e4 r4:bf2b64e4 > [ 758.964911] [] (bus_remove_driver) from [] > (driver_unregister+0x30/0x50) [ 758.973390] r5:bf2b42e4 r4:bf2b64e4 > [ 758.976991] [] (driver_unregister) from [] > (platform_unregister_drivers+0x3c/0x74) [ 758.986343] r5:bf2b42e4 > r4: > [ 758.989961] [] (platform_unregister_drivers) from [] > (omap_drm_fini+0x28/0x38 [omapdrm]) [ 758.999841] r9:ed3b4000 r8:c0108c04 > r7:0081 r6:0800 r5:0003cd4c r4:bf2b6800 [ 759.007649] [] > (omap_drm_fini [omapdrm]) from [] (SyS_delete_module+0x144/0x21c) > [ 759.016835] [] (SyS_delete_module) from [] > (ret_fast_syscall+0x0/0x1c) [ 759.025142] r6:bec63c10 r5:0003cd10 > r4:bec63dfc > [ 759.029902] ---[ end trace ebaa3f100ebbc054 ]--- > [ 759.036433] [ cut here ] > [ 759.041394] WARNING: CPU: 1 PID: 314 at drivers/gpu/drm/drm_irq.c:349 > drm_vblank_cleanup+0x5c/0x94 [drm] [ 759.050963] Modules linked in: > omapdrm(-) drm_kms_helper drm panel_dsi_cm panel_dpi connector_analog_tv > connector_dvi connecto r_hdmi encoder_tpd12s015 encoder_tfp410 omapdss > cfbfillrect cfbimgblt cfbcopyarea [last unloaded: omapdss_base] [ > 759.072372] CPU: 1 PID: 314 Comm: rmmod Tainted: GW > 4.9.0-rc8-00106-g8df5349534c6 #53 [ 759.081462] Hardware name: Generic > DRA74X (Flattened Device Tree) [ 759.087584] Backtrace: > [ 759.090064] [] (dump_backtrace) from [] > (show_stack+0x18/0x1c) [ 759.097675] r7:c0d830d8 r6:60030013 r5: > r4:c0d830d8 > [ 759.103368] [] (show_stack) from [] > (dump_stack+0xa8/0xdc) [ 759.110633] [] (dump_stack) from > [] (__warn+0xdc/0x108) [ 759.117634] r9:bf1fefc0 r8:015d > r7:0009 r6:bf229b84 r5: r4: [ 759.125421] [] > (__warn) from [] (warn_slowpath_null+0x28/0x30) [ 759.133033] > r9:015d r8:bf229b84 r7:ee145000 r6:0001 r5:00c8 r4:ed22aac8 /[ > 759.140927] [] (warn_slowpath_null) from [] > (drm_vblank_cleanup+0x5c/0x94 [drm]) [ 759.150391]
[PATCH v4 06/22] drm: omapdrm: Handle FIFO underflow IRQs internally
Hi Tomi,
On Wednesday 14 Dec 2016 12:22:29 Tomi Valkeinen wrote:
> On 14/12/16 02:27, Laurent Pinchart wrote:
> > As the FIFO underflow IRQ handler just prints an error message to the
> > kernel log, simplify the code by not registering one IRQ handler per
> > plane but print the messages directly from the main IRQ handler.
> >
> > Signed-off-by: Laurent Pinchart
> > Reviewed-by: Tomi Valkeinen
> > ---
> >
> > +static void omap_irq_fifo_underflow(struct omap_drm_private *priv,
> > + u32 irqstatus)
> > +{
> > + static DEFINE_RATELIMIT_STATE(_rs, DEFAULT_RATELIMIT_INTERVAL,
> > + DEFAULT_RATELIMIT_BURST);
> > + static const struct {
> > + const char *name;
> > + u32 mask;
> > + } sources[] = {
> > + { "gfx", DISPC_IRQ_GFX_FIFO_UNDERFLOW },
> > + { "vid1", DISPC_IRQ_VID1_FIFO_UNDERFLOW },
> > + { "vid2", DISPC_IRQ_VID2_FIFO_UNDERFLOW },
> > + { "vid3", DISPC_IRQ_VID3_FIFO_UNDERFLOW },
> > + };
> > +
> > + const u32 mask = DISPC_IRQ_GFX_FIFO_UNDERFLOW
> > + | DISPC_IRQ_VID1_FIFO_UNDERFLOW
> > + | DISPC_IRQ_VID2_FIFO_UNDERFLOW
> > + | DISPC_IRQ_VID3_FIFO_UNDERFLOW;
> > + unsigned int i;
> > +
> > + spin_lock(&list_lock);
> > + irqstatus &= priv->irq_mask & mask;
> > + spin_unlock(&list_lock);
> > +
> > + if (!irqstatus)
> > + return;
>
> This is called every time we get any DSS interrupt, so I think it would
> be good to have a fast-path here without the lock: irqstatus & mask.
>
> Or maybe store the enabled underflow irq bits separately from irq_mask,
> as the underflow bits are never changed after the initial setup, and
> then there's no need for locking.
I'd prefer going for the former, but I'm a bit concerned that an IRQ bit
defined as FIFO overflow on one platform could be defined as something else on
another platform and be mistaken.
Given that we already take the same lock in the IRQ handler to call the wait
handlers, do you think this is really an issue ?
--
Regards,
Laurent Pinchart
[PATCH 15/34] drm: kselftest for drm_mm and top-down allocation
On ma, 2016-12-12 at 11:53 +, Chris Wilson wrote: > Check that if we request top-down allocation from drm_mm_insert_node() > we receive the next available hole from the top. > > Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen Regards, Joonas -- Joonas Lahtinen Open Source Technology Center Intel Corporation
[PATCH v2 0/7] Host1x IOMMU support + VIC support
On Wed, Dec 14, 2016 at 01:16:10PM +0200, Mikko Perttunen wrote: > This series adds IOMMU support to Host1x and TegraDRM > and adds support for the VIC (Video Image Compositor) > host1x client. The series is available as a git repository at > git://github.com/cyndis/linux.git; branch vic-2. > > A userspace test case for VIC can be found at > https://github.com/cyndis/drm/tree/work/tegra. > The testcase is in tests/tegra and is called submit_vic. > The testcase/TRM include full headers and documentation > to program the unit. The unit by itself, however, does not > readily map to existing userspace library interfaces, so > implementations for those are not provided. Afaik libva has an entire pile of post-processing support. Pretty sure other video transcode libraries have similar interfaces, so should all be possible to implement this. Until that exists I really think that the VIC part (and only that, since tk1/tx1 in general seems to work with nouveau and all that) should stay out of tree. -Daniel > > The in-kernel firewall is not implemented for VIC; > therefore, either the IOMMU must be enabled or the firewall > disabled for the test to pass. > > Tested with Jetson TX1 (T210). Probably works also > with Jetson TK1 (T124). Note that due to hardware changes > the testcase also needs to be changed to run properly > on T124: this can be done by removing the topmost > commit of the aforementioned test repository. > > Thanks, > Mikko. > > Arto Merilainen (2): > drm/tegra: Add falcon helper library > drm/tegra: Add VIC support > > Mikko Perttunen (5): > drm/tegra: Add Tegra DRM allocation API > gpu: host1x: Add IOMMU support > dt-bindings: Add bindings for the Tegra VIC > arm64: tegra: Enable VIC on T210 > arm64: tegra: Enable IOMMU for Host1x on Tegra210 > > .../display/tegra/nvidia,tegra20-host1x.txt| 13 + > arch/arm64/boot/dts/nvidia/tegra210.dtsi | 19 +- > drivers/gpu/drm/tegra/Makefile | 4 +- > drivers/gpu/drm/tegra/drm.c| 114 +- > drivers/gpu/drm/tegra/drm.h| 12 + > drivers/gpu/drm/tegra/falcon.c | 259 ++ > drivers/gpu/drm/tegra/falcon.h | 127 +++ > drivers/gpu/drm/tegra/vic.c| 396 > + > drivers/gpu/drm/tegra/vic.h| 31 ++ > drivers/gpu/host1x/cdma.c | 74 +++- > drivers/gpu/host1x/cdma.h | 6 +- > drivers/gpu/host1x/dev.c | 40 ++- > drivers/gpu/host1x/dev.h | 6 + > drivers/gpu/host1x/hw/cdma_hw.c| 16 +- > drivers/gpu/host1x/job.c | 72 +++- > drivers/gpu/host1x/job.h | 1 + > include/linux/host1x.h | 1 + > 17 files changed, 1143 insertions(+), 48 deletions(-) > create mode 100644 drivers/gpu/drm/tegra/falcon.c > create mode 100644 drivers/gpu/drm/tegra/falcon.h > create mode 100644 drivers/gpu/drm/tegra/vic.c > create mode 100644 drivers/gpu/drm/tegra/vic.h > > -- > 2.10.2 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[PATCH v4 10/22] drm: omapdrm: Let the DRM core skip plane commit on inactive CRTCs
Hi Tomi, On Wednesday 14 Dec 2016 12:43:54 Tomi Valkeinen wrote: > On 14/12/16 02:27, Laurent Pinchart wrote: > > The DRM core supports skipping plane update for inactive CRTCs for > > hardware that don't need it or can't cope with it. That's our case, and > > the driver already skips flushing planes on inactice CRTCs. > > > > We can't remove the check from the driver, as active CRTCs are disabled > > at the hardware level when an atomic flush is performed if a mode set is > > pending. There's however no need to forward the plane commit calls to > > the driver, so use the DRM core infrastructure to skip them with a > > detailed comment to explain why the check must still be kept in the > > driver. > > > > Signed-off-by: Laurent Pinchart > > --- > > Changes since v3: > > > > - Reworded commit message > > --- > > > > drivers/gpu/drm/omapdrm/omap_crtc.c | 8 +++- > > drivers/gpu/drm/omapdrm/omap_drv.c | 3 ++- > > 2 files changed, 9 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c > > b/drivers/gpu/drm/omapdrm/omap_crtc.c index 42c3b44f9689..2832dbffd873 > > 100644 > > --- a/drivers/gpu/drm/omapdrm/omap_crtc.c > > +++ b/drivers/gpu/drm/omapdrm/omap_crtc.c > > @@ -414,7 +414,13 @@ static void omap_crtc_atomic_flush(struct drm_crtc > > *crtc,> > > dispc_mgr_set_gamma(omap_crtc->channel, lut, length); > > } > > > > - /* Only flush the CRTC if it is currently enabled. */ > > + /* > > +* Only flush the CRTC if it is currently enabled. CRTCs that require > > a > > +* mode set are disabled prior plane updates and enabled afterwards. > > +* They are thus not active (regardless of what their CRTC core state > > +* reports) and the DRM core could thus call this function even though > > +* the CRTC is currently disabled. Do nothing in that case. > > +*/ > > if (!omap_crtc->enabled) > > return; > > > > diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c > > b/drivers/gpu/drm/omapdrm/omap_drv.c index 6faba13c8e41..0a2d461d62cf > > 100644 > > --- a/drivers/gpu/drm/omapdrm/omap_drv.c > > +++ b/drivers/gpu/drm/omapdrm/omap_drv.c > > @@ -96,7 +96,8 @@ static void omap_atomic_complete(struct > > omap_atomic_state_commit *commit) > > dispc_runtime_get(); > > > > drm_atomic_helper_commit_modeset_disables(dev, old_state); > > - drm_atomic_helper_commit_planes(dev, old_state, 0); > > + drm_atomic_helper_commit_planes(dev, old_state, > > + DRM_PLANE_COMMIT_ACTIVE_ONLY); > > drm_atomic_helper_commit_modeset_enables(dev, old_state); > > Just to make sure. "ACTIVE" in this context means a crtc that's already > enabled, or will be enabled at the > drm_atomic_helper_commit_modeset_enables() call? Correct, it covers both. > If so: > > Reviewed-by: Tomi Valkeinen -- Regards, Laurent Pinchart
[Intel-gfx] [PATCH 05/13] drm: locking&new iterators for connector_list
On Wed, Dec 14, 2016 at 01:22:15PM +0200, Jani Nikula wrote: > On Wed, 14 Dec 2016, Daniel Vetter wrote: > > +/** > > + * drm_for_each_connector_iter - connector_list iterator macro > > + * @connector: struct &drm_connector pointer used as cursor > > + * @iter: struct &drm_connector_list_iter > > + * > > + * Note that @connector is only valid within the list body, if you want to > > use > > + * @connector after calling drm_connector_list_iter_put() then you need to > > grab > > + * your own reference first using drm_connector_reference(). > > + */ > > +#define drm_for_each_connector_iter(connector, iter) \ > > + while ((connector = drm_connector_list_iter_next(iter))) > > + > > Observe that in most, if not all, cases you lock over the for loop, but > not more. That means you always get/put right around the loop. > > You could have a variant of get() that returns the first item, and a > variant of next() that does put() automatically when it's about to > return NULL, and implement most of the loops like this: > > #define drm_for_each_connector_simple(dev, iter, connector) \ > for (connector = drm_connector_list_iter_get_first(dev, iter); \ >connector != NULL; \ >connector = drm_connector_list_iter_next_put(iter)) > > In the long run, that should be called just drm_for_each_connector. > > The only case where you'd have to call put() explicitly is when you > break out of the loop early. Otherwise all looping would be dead simple, > without all the gets and puts, just like they are now. Perhaps the > naming of the functions should be such that this is the most common > case. Perhaps you don't actually need the versions with "manual" locking > at all. I had this in an earlier iteration of this patch series. The implemenation was somewhat misguided (as in it used srcu and some other wizzardry that I now managed to remove), but otherwise was exactly what you've asking for here. The amount of leaking was mindboggling. And that was only me being sloppyin in converting the piles of existing loop, not even ongoing maintenance of new loops additions done by people who're not well versed in the finer details of connector_list walking and the refcounting dance involved. Given that I've concluded that hiding those details is a bad choice, and to top it off the new code enforces matching get/put using lockdep. We do pay a price in that simple loops become a bit more verbose, but unfortunately there's no way to create something which is guarnateed to get destructed when leaving a code block (unlike in C++). And without that guarantee I don't think it'll be maintainable long-term. I expect that drm_for_each_connector will stay around for a long time (maybe even forever). As long as your driver doesn't hotplug connectors, it's perfectly fine. Only core + helpers + any driver supporting mst really need to switch over. Overall not the prettiest thing, but still an acceptable tradeoff imo. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[Intel-gfx] [PATCH 05/13] drm: locking&new iterators for connector_list
On Wed, 14 Dec 2016, Daniel Vetter wrote:
> The requirements for connector_list locking are a bit tricky:
> - We need to be able to jump over zombie conectors (i.e. with refcount
> == 0, but not yet removed from the list). If instead we require that
> there's no zombies on the list then the final kref_put must happen
> under the list protection lock, which means that locking context
> leaks all over the place. Not pretty - better to deal with zombies
> and wrap the locking just around the list_del in the destructor.
>
> - When we walk the list we must _not_ hold the connector list lock. We
> walk the connector list at an absolutely massive amounts of places,
> if all those places can't ever call drm_connector_unreference the
> code would get unecessarily complicated.
>
> - connector_list needs it own lock, again too many places that walk it
> that we could reuse e.g. mode_config.mutex without resulting in
> inversions.
>
> - Lots of code uses these loops to look-up a connector, i.e. they want
> to be able to call drm_connector_reference. But on the other hand we
> want connectors to stay on that list until they're dead (i.e.
> connector_list can't hold a full reference), which means despite the
> "can't hold lock for the loop body" rule we need to make sure a
> connector doesn't suddenly become a zombie.
>
> At first Dave&I discussed various horror-show approaches using srcu,
> but turns out it's fairly easy:
>
> - For the loop body we always hold an additional reference to the
> current connector. That means it can't zombify, and it also means
> it'll stay on the list, which means we can use it as our iterator to
> find the next connector.
>
> - When we try to find the next connector we only have to jump over
> zombies. To make sure we don't chase bad pointers that entire loop
> is protected with the new connect_list_lock spinlock. And because we
> know that we're starting out with a non-zombie (need to drop our
> reference for the old connector only after we have our new one),
> we're guranteed to still be on the connector_list and either find
> the next non-zombie or complete the iteration.
>
> - Only downside is that we need to make sure that the temporary
> reference for the loop body doesn't leak. iter_get/put() functions +
> lockdep make sure that's the case.
>
> - To avoid a flag day the new iterator macro has an _iter postfix. We
> can rename it back once all the users of the unsafe version are gone
> (there's about 100 list walkers for the connector_list).
>
> For now this patch only converts all the list walking in the core,
> leaving helpers and drivers for later patches. The nice thing is that
> we can now finally remove 2 FIXME comments from the
> register/unregister functions.
>
> v2:
> - use irqsafe spinlocks, so that we can use this in drm_state_dump
> too.
> - nuke drm_modeset_lock_all from drm_connector_init, now entirely
> cargo-culted nonsense.
>
> v3:
> - do {} while (!kref_get_unless_zero), makes for a tidier loop (Dave).
> - pretty kerneldoc
> - add EXPORT_SYMBOL, helpers&drivers are supposed to use this.
>
> v4: Change lockdep annotations to only check whether we release the
> iter fake lock again (i.e. make sure that iter_put is called), but
> not check any locking dependecies itself. That seams to require a
> recursive read lock in trylock mode.
>
> Cc: Dave Airlie
> Cc: Chris Wilson
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_atomic.c | 14 -
> drivers/gpu/drm/drm_connector.c | 116
> --
> drivers/gpu/drm/drm_encoder.c | 6 +-
> drivers/gpu/drm/drm_mode_config.c | 34 +--
> include/drm/drm_connector.h | 38 +
> include/drm/drm_mode_config.h | 12 +++-
> 6 files changed, 177 insertions(+), 43 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 60697482b94c..b23b4abd67be 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -1417,6 +1417,7 @@ drm_atomic_add_affected_connectors(struct
> drm_atomic_state *state,
> struct drm_mode_config *config = &state->dev->mode_config;
> struct drm_connector *connector;
> struct drm_connector_state *conn_state;
> + struct drm_connector_list_iter conn_iter;
> int ret;
>
> ret = drm_modeset_lock(&config->connection_mutex, state->acquire_ctx);
> @@ -1430,14 +1431,18 @@ drm_atomic_add_affected_connectors(struct
> drm_atomic_state *state,
>* Changed connectors are already in @state, so only need to look at the
>* current configuration.
>*/
> - drm_for_each_connector(connector, state->dev) {
> + drm_connector_list_iter_get(state->dev, &conn_iter);
> + drm_for_each_connector_iter(connector, &conn_iter) {
> if (connector->state->crtc != crtc)
> continue;
>
> conn_state = drm_atomic_get_con
[PATCH] drm: Move vblank cleanup from unregister to release
On 14/12/16 12:48, Laurent Pinchart wrote: > Calling drm_vblank_cleanup() in drm_dev_unregister() causes issues with > drivers that have moved away from the .load() and .unload() midlayer. > Those drivers call drm_dev_unregister() as the first operation at unbind > time, before shutting down the device. This results in warnings due to > drm_vblank_cleanup() being called with vblank interrupts still active, > and then to vblank events being sent after cleanup. > > Fix the problem by moving vblank cleanup from drm_dev_unregister() to > drm_dev_release() that is guaranteed to be called after drivers shut > down the device. > > Suggested-by: Daniel Vetter > Signed-off-by: Laurent Pinchart Tested-by: Tomi Valkeinen Tomi -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161214/88d603a4/attachment.sig>
[PATCH v2 7/7] arm64: tegra: Enable IOMMU for Host1x on Tegra210
The Host1x driver now supports operation behind an IOMMU,
so add its IOMMU domain to the device tree.
Signed-off-by: Mikko Perttunen
---
arch/arm64/boot/dts/nvidia/tegra210.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/boot/dts/nvidia/tegra210.dtsi
b/arch/arm64/boot/dts/nvidia/tegra210.dtsi
index e12390f..8d229c7 100644
--- a/arch/arm64/boot/dts/nvidia/tegra210.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra210.dtsi
@@ -26,6 +26,8 @@
ranges = <0x0 0x5400 0x0 0x5400 0x0 0x0100>;
+ iommus = <&mc TEGRA_SWGROUP_HC>;
+
dpaux1: dpaux at 5404 {
compatible = "nvidia,tegra210-dpaux";
reg = <0x0 0x5404 0x0 0x0004>;
--
2.10.2
[PATCH v2 6/7] arm64: tegra: Enable VIC on T210
Enable the VIC (Video Image Compositor) host1x
unit on Tegra210 systems.
Signed-off-by: Mikko Perttunen
---
arch/arm64/boot/dts/nvidia/tegra210.dtsi | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/nvidia/tegra210.dtsi
b/arch/arm64/boot/dts/nvidia/tegra210.dtsi
index 46045fe..e12390f 100644
--- a/arch/arm64/boot/dts/nvidia/tegra210.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra210.dtsi
@@ -122,7 +122,14 @@
vic at 5434 {
compatible = "nvidia,tegra210-vic";
reg = <0x0 0x5434 0x0 0x0004>;
- status = "disabled";
+ interrupts = ;
+ clocks = <&tegra_car TEGRA210_CLK_VIC03>;
+ clock-names = "vic";
+ resets = <&tegra_car 178>;
+ reset-names = "vic";
+
+ iommus = <&mc TEGRA_SWGROUP_VIC>;
+ power-domains = <&pd_vic>;
};
nvjpg at 5438 {
@@ -692,6 +699,14 @@
resets = <&tegra_car TEGRA210_CLK_XUSB_HOST>;
#power-domain-cells = <0>;
};
+
+ pd_vic: vic {
+ clocks = <&tegra_car TEGRA210_CLK_VIC03>;
+ clock-names = "vic";
+ resets = <&tegra_car TEGRA210_CLK_VIC03>;
+ reset-names = "vic";
+ #power-domain-cells = <0>;
+ };
};
};
--
2.10.2
[PATCH v2 5/7] dt-bindings: Add bindings for the Tegra VIC
The VIC (Video Image Compositor) is a Host1x client unit
that can do various 2D composition and transform operations.
Signed-off-by: Mikko Perttunen
---
.../bindings/display/tegra/nvidia,tegra20-host1x.txt| 13 +
1 file changed, 13 insertions(+)
diff --git
a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt
b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt
index 0fad7ed..74e1e8a 100644
--- a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt
+++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt
@@ -249,6 +249,19 @@ of the following host1x client modules:
See ../pinctrl/nvidia,tegra124-dpaux-padctl.txt for information
regarding the DPAUX pad controller bindings.
+- vic: Video Image Compositor
+ - compatible : "nvidia,tegra-vic"
+ - reg: Physical base address and length of the controller's registers.
+ - interrupts: The interrupt outputs from the controller.
+ - clocks: Must contain an entry for each entry in clock-names.
+See ../clocks/clock-bindings.txt for details.
+ - clock-names: Must include the following entries:
+- vic: clock input for the VIC hardware
+ - resets: Must contain an entry for each entry in reset-names.
+See ../reset/reset.txt for details.
+ - reset-names: Must include the following entries:
+- vic
+
Example:
/ {
--
2.10.2
[PATCH v2 4/7] gpu: host1x: Add IOMMU support
Add support for the Host1x unit to be located behind
an IOMMU. This is required when gather buffers may be
allocated non-contiguously in physical memory, as can
be the case when TegraDRM is also using the IOMMU.
Signed-off-by: Mikko Perttunen
---
drivers/gpu/host1x/cdma.c | 74 -
drivers/gpu/host1x/cdma.h | 6 ++--
drivers/gpu/host1x/dev.c| 40 --
drivers/gpu/host1x/dev.h| 6
drivers/gpu/host1x/hw/cdma_hw.c | 16 -
drivers/gpu/host1x/job.c| 72 +--
drivers/gpu/host1x/job.h| 1 +
7 files changed, 176 insertions(+), 39 deletions(-)
diff --git a/drivers/gpu/host1x/cdma.c b/drivers/gpu/host1x/cdma.c
index c5d82a8..28541b2 100644
--- a/drivers/gpu/host1x/cdma.c
+++ b/drivers/gpu/host1x/cdma.c
@@ -51,9 +51,15 @@ static void host1x_pushbuffer_destroy(struct push_buffer *pb)
struct host1x_cdma *cdma = pb_to_cdma(pb);
struct host1x *host1x = cdma_to_host1x(cdma);
- if (pb->phys != 0)
- dma_free_wc(host1x->dev, pb->size_bytes + 4, pb->mapped,
- pb->phys);
+ if (!pb->phys)
+ return;
+
+ if (host1x->domain) {
+ iommu_unmap(host1x->domain, pb->dma, pb->alloc_size);
+ free_iova(&host1x->iova, iova_pfn(&host1x->iova, pb->dma));
+ }
+
+ dma_free_wc(host1x->dev, pb->alloc_size, pb->mapped, pb->phys);
pb->mapped = NULL;
pb->phys = 0;
@@ -66,28 +72,64 @@ static int host1x_pushbuffer_init(struct push_buffer *pb)
{
struct host1x_cdma *cdma = pb_to_cdma(pb);
struct host1x *host1x = cdma_to_host1x(cdma);
+ struct iova *alloc;
+ u32 size;
+ int err;
pb->mapped = NULL;
pb->phys = 0;
- pb->size_bytes = HOST1X_PUSHBUFFER_SLOTS * 8;
+ pb->size = HOST1X_PUSHBUFFER_SLOTS * 8;
+
+ size = pb->size + 4;
/* initialize buffer pointers */
- pb->fence = pb->size_bytes - 8;
+ pb->fence = pb->size - 8;
pb->pos = 0;
- /* allocate and map pushbuffer memory */
- pb->mapped = dma_alloc_wc(host1x->dev, pb->size_bytes + 4, &pb->phys,
- GFP_KERNEL);
- if (!pb->mapped)
- goto fail;
+ if (host1x->domain) {
+ unsigned long shift;
+
+ size = iova_align(&host1x->iova, size);
+
+ pb->mapped = dma_alloc_wc(host1x->dev, size, &pb->phys,
+ GFP_KERNEL);
+ if (!pb->mapped)
+ return -ENOMEM;
+
+ shift = iova_shift(&host1x->iova);
+ alloc = alloc_iova(&host1x->iova, size >> shift,
+ host1x->iova_end >> shift, true);
+ if (!alloc) {
+ err = -ENOMEM;
+ goto iommu_free_mem;
+ }
+
+ pb->dma = iova_dma_addr(&host1x->iova, alloc);
+ err = iommu_map(host1x->domain, pb->dma, pb->phys, size,
+ IOMMU_READ);
+ if (err)
+ goto iommu_free_iova;
+ } else {
+ pb->mapped = dma_alloc_wc(host1x->dev, size, &pb->phys,
+ GFP_KERNEL);
+ if (!pb->mapped)
+ return -ENOMEM;
+
+ pb->dma = pb->phys;
+ }
+
+ pb->alloc_size = size;
host1x_hw_pushbuffer_init(host1x, pb);
return 0;
-fail:
- host1x_pushbuffer_destroy(pb);
- return -ENOMEM;
+iommu_free_iova:
+ __free_iova(&host1x->iova, alloc);
+iommu_free_mem:
+ dma_free_wc(host1x->dev, pb->alloc_size, pb->mapped, pb->phys);
+
+ return err;
}
/*
@@ -101,7 +143,7 @@ static void host1x_pushbuffer_push(struct push_buffer *pb,
u32 op1, u32 op2)
WARN_ON(pb->pos == pb->fence);
*(p++) = op1;
*(p++) = op2;
- pb->pos = (pb->pos + 8) & (pb->size_bytes - 1);
+ pb->pos = (pb->pos + 8) & (pb->size - 1);
}
/*
@@ -111,7 +153,7 @@ static void host1x_pushbuffer_push(struct push_buffer *pb,
u32 op1, u32 op2)
static void host1x_pushbuffer_pop(struct push_buffer *pb, unsigned int slots)
{
/* Advance the next write position */
- pb->fence = (pb->fence + slots * 8) & (pb->size_bytes - 1);
+ pb->fence = (pb->fence + slots * 8) & (pb->size - 1);
}
/*
@@ -119,7 +161,7 @@ static void host1x_pushbuffer_pop(struct push_buffer *pb,
unsigned int slots)
*/
static u32 host1x_pushbuffer_space(struct push_buffer *pb)
{
- return ((pb->fence - pb->pos) & (pb->size_bytes - 1)) / 8;
+ return ((pb->fence - pb->pos) & (pb->size - 1)) / 8;
}
/*
diff --git a/drivers/gpu/host1x/cdma.h b/drivers/gpu/host1x/cdma.h
index 470087a..ec170a7 100644
--- a/drivers/gpu/host1x/cdma.h
+++ b/drivers/gpu/host1x/cdma.h
@@ -43,10 +43,12 @@ st
[PATCH v2 3/7] drm/tegra: Add VIC support
From: Arto Merilainen
This patch adds support for Video Image Compositor engine which
can be used for 2d operations.
Signed-off-by: Andrew Chew
Signed-off-by: Arto Merilainen
Signed-off-by: Mikko Perttunen
---
drivers/gpu/drm/tegra/Makefile | 3 +-
drivers/gpu/drm/tegra/drm.c| 3 +
drivers/gpu/drm/tegra/drm.h| 1 +
drivers/gpu/drm/tegra/vic.c| 396 +
drivers/gpu/drm/tegra/vic.h| 31
include/linux/host1x.h | 1 +
6 files changed, 434 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/tegra/vic.c
create mode 100644 drivers/gpu/drm/tegra/vic.h
diff --git a/drivers/gpu/drm/tegra/Makefile b/drivers/gpu/drm/tegra/Makefile
index 93e9a4a..6af3a9a 100644
--- a/drivers/gpu/drm/tegra/Makefile
+++ b/drivers/gpu/drm/tegra/Makefile
@@ -14,6 +14,7 @@ tegra-drm-y := \
dpaux.o \
gr2d.o \
gr3d.o \
- falcon.o
+ falcon.o \
+ vic.o
obj-$(CONFIG_DRM_TEGRA) += tegra-drm.o
diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index cf714c6..f47692e 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -1160,11 +1160,13 @@ static const struct of_device_id host1x_drm_subdevs[] =
{
{ .compatible = "nvidia,tegra124-sor", },
{ .compatible = "nvidia,tegra124-hdmi", },
{ .compatible = "nvidia,tegra124-dsi", },
+ { .compatible = "nvidia,tegra124-vic", },
{ .compatible = "nvidia,tegra132-dsi", },
{ .compatible = "nvidia,tegra210-dc", },
{ .compatible = "nvidia,tegra210-dsi", },
{ .compatible = "nvidia,tegra210-sor", },
{ .compatible = "nvidia,tegra210-sor1", },
+ { .compatible = "nvidia,tegra210-vic", },
{ /* sentinel */ }
};
@@ -1186,6 +1188,7 @@ static struct platform_driver * const drivers[] = {
&tegra_sor_driver,
&tegra_gr2d_driver,
&tegra_gr3d_driver,
+ &tegra_vic_driver,
};
static int __init host1x_drm_init(void)
diff --git a/drivers/gpu/drm/tegra/drm.h b/drivers/gpu/drm/tegra/drm.h
index 7351dee..6a57e66 100644
--- a/drivers/gpu/drm/tegra/drm.h
+++ b/drivers/gpu/drm/tegra/drm.h
@@ -296,5 +296,6 @@ extern struct platform_driver tegra_dpaux_driver;
extern struct platform_driver tegra_sor_driver;
extern struct platform_driver tegra_gr2d_driver;
extern struct platform_driver tegra_gr3d_driver;
+extern struct platform_driver tegra_vic_driver;
#endif /* HOST1X_DRM_H */
diff --git a/drivers/gpu/drm/tegra/vic.c b/drivers/gpu/drm/tegra/vic.c
new file mode 100644
index 000..cd804e4
--- /dev/null
+++ b/drivers/gpu/drm/tegra/vic.c
@@ -0,0 +1,396 @@
+/*
+ * Copyright (c) 2015, NVIDIA Corporation.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include "drm.h"
+#include "falcon.h"
+#include "vic.h"
+
+struct vic_config {
+ const char *firmware;
+};
+
+struct vic {
+ struct falcon falcon;
+ bool booted;
+
+ void __iomem *regs;
+ struct tegra_drm_client client;
+ struct host1x_channel *channel;
+ struct iommu_domain *domain;
+ struct device *dev;
+ struct clk *clk;
+
+ /* Platform configuration */
+ const struct vic_config *config;
+};
+
+static inline struct vic *to_vic(struct tegra_drm_client *client)
+{
+ return container_of(client, struct vic, client);
+}
+
+static void vic_writel(struct vic *vic, u32 value, unsigned int offset)
+{
+ writel(value, vic->regs + offset);
+}
+
+static int vic_runtime_resume(struct device *dev)
+{
+ struct vic *vic = dev_get_drvdata(dev);
+
+ return clk_prepare_enable(vic->clk);
+}
+
+static int vic_runtime_suspend(struct device *dev)
+{
+ struct vic *vic = dev_get_drvdata(dev);
+
+ clk_disable_unprepare(vic->clk);
+
+ vic->booted = false;
+
+ return 0;
+}
+
+static int vic_boot(struct vic *vic)
+{
+ u32 fce_ucode_size, fce_bin_data_offset;
+ void *hdr;
+ int err = 0;
+
+ if (vic->booted)
+ return 0;
+
+ /* setup clockgating registers */
+ vic_writel(vic, CG_IDLE_CG_DLY_CNT(4) |
+ CG_IDLE_CG_EN |
+ CG_WAKEUP_DLY_CNT(4),
+ NV_PVIC_MISC_PRI_VIC_CG);
+
+ err = falcon_boot(&vic->falcon);
+ if (err < 0)
+ return err;
+
+ hdr = vic->falcon.firmware.vaddr;
+ fce_bin_data_offset = *(u32 *)(hdr + VIC_UCODE_FCE_DATA_OFFSET);
+ hdr = vic->falcon.firmware.vaddr +
+ *(u32 *)(hdr + VIC_UCODE_FCE_HEADER_OFFSET);
+ fce_ucode_size = *(u32 *)(hdr + FCE_UCODE_SIZE_OFFSET);
+
+ falcon_execute_method(&vic->falcon, VIC_SET_APPLICATION_ID, 1);
+ falcon_execut
[PATCH v2 2/7] drm/tegra: Add falcon helper library
From: Arto Merilainen
Add a set of falcon helper routines for use by the tegradrm client drivers
of the various falcon-based engines.
The falcon is a microcontroller that acts as a frontend for the rest of a
particular Tegra engine. In order to properly utilize these engines, the
frontend must be booted before pushing any commands.
Based on work by Andrew Chew
Signed-off-by: Andrew Chew
Signed-off-by: Arto Merilainen
Signed-off-by: Mikko Perttunen
---
drivers/gpu/drm/tegra/Makefile | 3 +-
drivers/gpu/drm/tegra/falcon.c | 259 +
drivers/gpu/drm/tegra/falcon.h | 127
3 files changed, 388 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/tegra/falcon.c
create mode 100644 drivers/gpu/drm/tegra/falcon.h
diff --git a/drivers/gpu/drm/tegra/Makefile b/drivers/gpu/drm/tegra/Makefile
index 2c66a8d..93e9a4a 100644
--- a/drivers/gpu/drm/tegra/Makefile
+++ b/drivers/gpu/drm/tegra/Makefile
@@ -13,6 +13,7 @@ tegra-drm-y := \
sor.o \
dpaux.o \
gr2d.o \
- gr3d.o
+ gr3d.o \
+ falcon.o
obj-$(CONFIG_DRM_TEGRA) += tegra-drm.o
diff --git a/drivers/gpu/drm/tegra/falcon.c b/drivers/gpu/drm/tegra/falcon.c
new file mode 100644
index 000..f685e729
--- /dev/null
+++ b/drivers/gpu/drm/tegra/falcon.c
@@ -0,0 +1,259 @@
+/*
+ * Copyright (c) 2015, NVIDIA Corporation.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include "falcon.h"
+#include "drm.h"
+
+enum falcon_memory {
+ FALCON_MEMORY_IMEM,
+ FALCON_MEMORY_DATA,
+};
+
+static void falcon_writel(struct falcon *falcon, u32 value, u32 offset)
+{
+ writel(value, falcon->regs + offset);
+}
+
+int falcon_wait_idle(struct falcon *falcon)
+{
+ u32 value;
+
+ return readl_poll_timeout(falcon->regs + FALCON_IDLESTATE, value,
+ (value == 0), 10, 10);
+}
+
+static int falcon_dma_wait_idle(struct falcon *falcon)
+{
+ u32 value;
+
+ return readl_poll_timeout(falcon->regs + FALCON_DMATRFCMD, value,
+ (value & FALCON_DMATRFCMD_IDLE), 10, 10);
+}
+
+static int falcon_copy_chunk(struct falcon *falcon,
+phys_addr_t base,
+unsigned long offset,
+enum falcon_memory target)
+{
+ u32 cmd = FALCON_DMATRFCMD_SIZE_256B;
+
+ if (target == FALCON_MEMORY_IMEM)
+ cmd |= FALCON_DMATRFCMD_IMEM;
+
+ falcon_writel(falcon, offset, FALCON_DMATRFMOFFS);
+ falcon_writel(falcon, base, FALCON_DMATRFFBOFFS);
+ falcon_writel(falcon, cmd, FALCON_DMATRFCMD);
+
+ return falcon_dma_wait_idle(falcon);
+}
+
+static void falcon_copy_firmware_image(struct falcon *falcon,
+ const struct firmware *firmware)
+{
+ u32 *firmware_vaddr = falcon->firmware.vaddr;
+ dma_addr_t daddr;
+ size_t i;
+ int err;
+
+ /* copy the whole thing taking into account endianness */
+ for (i = 0; i < firmware->size / sizeof(u32); i++)
+ firmware_vaddr[i] = le32_to_cpu(((u32 *)firmware->data)[i]);
+
+ /* ensure that caches are flushed and falcon can see the firmware */
+ daddr = dma_map_single(falcon->dev, firmware_vaddr,
+ falcon->firmware.size, DMA_TO_DEVICE);
+ err = dma_mapping_error(falcon->dev, daddr);
+ if (err) {
+ dev_err(falcon->dev, "failed to map firmware: %d\n", err);
+ return;
+ }
+ dma_sync_single_for_device(falcon->dev, daddr,
+ falcon->firmware.size, DMA_TO_DEVICE);
+ dma_unmap_single(falcon->dev, daddr, falcon->firmware.size,
+DMA_TO_DEVICE);
+}
+
+static int falcon_parse_firmware_image(struct falcon *falcon)
+{
+ struct falcon_fw_bin_header_v1 *bin = (void *)falcon->firmware.vaddr;
+ struct falcon_fw_os_header_v1 *os;
+
+ /* endian problems would show up right here */
+ if (bin->magic != PCI_VENDOR_ID_NVIDIA) {
+ dev_err(falcon->dev, "incorrect firmware magic\n");
+ return -EINVAL;
+ }
+
+ /* currently only version 1 is supported */
+ if (bin->version != 1) {
+ dev_err(falcon->dev, "unsupported firmware version\n");
+ return -EINVAL;
+ }
+
+ /* check that the firmware size is consistent */
+ if (bin->size > falcon->firmware.size) {
+ dev_err(falcon->dev, "firmware image size inconsistency\n");
+ return -EINVAL;
+ }
+
+ os = falcon->firmware.vaddr + bin->os_header_offset;
+
+ falcon->firmware.bin_data.size = bin->os_size;
+ falcon->firmware.bin_dat
[PATCH v2 1/7] drm/tegra: Add Tegra DRM allocation API
Add a new IO virtual memory allocation API to allow clients to
allocate non-GEM memory in the Tegra DRM IOMMU domain. This is
required e.g. for loading client firmware when clients are attached
to the IOMMU domain.
The allocator allocates contiguous physical pages that are then
mapped contiguously to the IOMMU domain using the iova_domain
library provided by the kernel. Contiguous physical pages are
used so that the same allocator works also when IOMMU support
is disabled and therefore devices access physical memory directly.
Signed-off-by: Mikko Perttunen
---
drivers/gpu/drm/tegra/drm.c | 111 +---
drivers/gpu/drm/tegra/drm.h | 11 +
2 files changed, 115 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index b8be3ee..cf714c6 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -1,12 +1,13 @@
/*
* Copyright (C) 2012 Avionic Design GmbH
- * Copyright (C) 2012-2013 NVIDIA CORPORATION. All rights reserved.
+ * Copyright (C) 2012-2016 NVIDIA CORPORATION. All rights reserved.
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*/
+#include
#include
#include
@@ -23,6 +24,8 @@
#define DRIVER_MINOR 0
#define DRIVER_PATCHLEVEL 0
+#define CARVEOUT_SZ SZ_64M
+
struct tegra_drm_file {
struct list_head contexts;
};
@@ -127,7 +130,8 @@ static int tegra_drm_load(struct drm_device *drm, unsigned
long flags)
if (iommu_present(&platform_bus_type)) {
struct iommu_domain_geometry *geometry;
- u64 start, end;
+ unsigned long order;
+ u64 carveout_start, carveout_end, gem_start, gem_end;
tegra->domain = iommu_domain_alloc(&platform_bus_type);
if (!tegra->domain) {
@@ -136,12 +140,25 @@ static int tegra_drm_load(struct drm_device *drm,
unsigned long flags)
}
geometry = &tegra->domain->geometry;
- start = geometry->aperture_start;
- end = geometry->aperture_end;
+ gem_start = geometry->aperture_start;
+ gem_end = geometry->aperture_end - CARVEOUT_SZ;
+ carveout_start = gem_end + 1;
+ carveout_end = geometry->aperture_end;
+
+ order = __ffs(tegra->domain->pgsize_bitmap);
+ init_iova_domain(&tegra->carveout.domain, 1UL << order,
+carveout_start >> order,
+carveout_end >> order);
+
+ tegra->carveout.shift = iova_shift(&tegra->carveout.domain);
+ tegra->carveout.limit = carveout_end >> tegra->carveout.shift;
+
+ drm_mm_init(&tegra->mm, gem_start, gem_end - gem_start + 1);
- DRM_DEBUG_DRIVER("IOMMU aperture initialized (%#llx-%#llx)\n",
-start, end);
- drm_mm_init(&tegra->mm, start, end - start + 1);
+ DRM_DEBUG("IOMMU apertures:\n");
+ DRM_DEBUG(" GEM: %#llx-%#llx\n", gem_start, gem_end);
+ DRM_DEBUG(" Carveout: %#llx-%#llx\n", carveout_start,
+ carveout_end);
}
mutex_init(&tegra->clients_lock);
@@ -208,6 +225,7 @@ static int tegra_drm_load(struct drm_device *drm, unsigned
long flags)
if (tegra->domain) {
iommu_domain_free(tegra->domain);
drm_mm_takedown(&tegra->mm);
+ put_iova_domain(&tegra->carveout.domain);
}
free:
kfree(tegra);
@@ -232,6 +250,7 @@ static int tegra_drm_unload(struct drm_device *drm)
if (tegra->domain) {
iommu_domain_free(tegra->domain);
drm_mm_takedown(&tegra->mm);
+ put_iova_domain(&tegra->carveout.domain);
}
kfree(tegra);
@@ -975,6 +994,84 @@ int tegra_drm_unregister_client(struct tegra_drm *tegra,
return 0;
}
+void *tegra_drm_alloc(struct tegra_drm *tegra, size_t size,
+ dma_addr_t *dma)
+{
+ struct iova *alloc;
+ void *virt;
+ gfp_t gfp;
+ int err;
+
+ if (tegra->domain)
+ size = iova_align(&tegra->carveout.domain, size);
+ else
+ size = PAGE_ALIGN(size);
+
+ gfp = GFP_KERNEL | __GFP_ZERO;
+ if (!tegra->domain) {
+ /*
+* Many units only support 32-bit addresses, even on 64-bit
+* SoCs. If there is no IOMMU to translate into a 32-bit IO
+* virtual address space, force allocations to be in the
+* lower 32-bit range.
+*/
+ gfp |= GFP_DMA;
+ }
+
+ virt = (void *)__get_free_pages(gfp, get_order(size));
+ if (!virt)
+ return ERR_PTR(-ENOMEM);
+
+
