- Linaro-mm-sig - lists.linaro.org

[PATCH v3 00/19] Exynos SYSMMU (IOMMU) integration with DT and DMA-mapping subsystem

by Marek Szyprowski

Hello Everyone, This is another attempt to finally make Exynos SYSMMU driver fully integrated with DMA-mapping subsystem. The main change from previous version is a rebase onto latest "automatic DMA configuration for IOMMU masters" patches from Will Deacon. This patchset demonstrates that Will's proposal works fine and significantly simplifies the driver code. Best regards Marek Szyprowski Samsung R&D Institute Poland Changelog: v3: - rebased onto "[RFC PATCH v4 0/8] Introduce automatic DMA configuration for IOMMU masters" - added some minor fixes for iommu and dma-mapping frameworks v2: http://thread.gmane.org/gmane.linux.kernel.iommu/6472/ - rebased onto "[RFC PATCH v3 0/7] Introduce automatic DMA configuration for IOMMU masters" patches: http://www.spinics.net/lists/arm-kernel/msg362076.html - changed initialization from bus notifiers to DT related callbacks - removed support for separate IO address spaces - this will be discussed separately after the basic support gets merged - removed support for power domain notifier-based runtime power management - this also will be discussed separately later v1: https://lkml.org/lkml/2014/8/5/183 - initial version, feature complete, completely rewrote integration approach Patch summary: Marek Szyprowski (19): iommu: fix const qualifier in of_iommu_set_ops iommu: fix initialization without 'add_device' callback arm: dma-mapping: add missing check for iommu drm: exynos: detach from default dma-mapping domain on init arm: exynos: pm_domains: add support for devices registered before arch_initcall ARM: dts: exynos4: add sysmmu nodes iommu: exynos: don't read version register on every tlb operation iommu: exynos: remove unused functions iommu: exynos: remove useless spinlock iommu: exynos: refactor function parameters to simplify code iommu: exynos: remove unused functions, part 2 iommu: exynos: remove useless device_add/remove callbacks iommu: exynos: add support for binding more than one sysmmu to master device iommu: exynos: add support for runtime_pm iommu: exynos: rename variables to reflect their purpose iommu: exynos: document internal structures iommu: exynos: remove excessive includes and sort others alphabetically iommu: exynos: init from dt-specific callback instead of initcall iommu: exynos: add callback for initializing devices from device tree arch/arm/boot/dts/exynos4.dtsi | 117 +++++++ arch/arm/boot/dts/exynos4210.dtsi | 23 ++ arch/arm/boot/dts/exynos4x12.dtsi | 82 +++++ arch/arm/mach-exynos/pm_domains.c | 9 +- arch/arm/mm/dma-mapping.c | 2 +- drivers/gpu/drm/exynos/exynos_drm_iommu.c | 3 + drivers/iommu/exynos-iommu.c | 490 ++++++++++++++---------------- drivers/iommu/iommu.c | 2 +- include/linux/of_iommu.h | 4 +- 9 files changed, 459 insertions(+), 273 deletions(-) -- 1.9.2

10 years, 4 months

10
62
0 0

[GIT PULL] drm: sti: add DVO output connector

by Benjamin Gaignard

Hello Dave, This patch enable the last big hardware feature of my driver: the connector for panel. Like for HMDI and HDA, Digital Video Out (DVO) create brige, encoder and connector drm objects. The following changes since commit 4e0cd68115620bc3236ff4e58e4c073948629b41: drm: sti: fix module compilation issue (2014-12-15 17:07:57 +1000) are available in the git repository at: http://git.linaro.org/people/benjamin.gaignard/kernel.git drm-sti-next-add-dvo for you to fetch changes up to f32c4c506f9b197f24d4be4ee7283bd549e3a30f: drm: sti: add DVO output connector (2014-12-30 15:08:16 +0100) ---------------------------------------------------------------- Benjamin Gaignard (1): drm: sti: add DVO output connector .../devicetree/bindings/gpu/st,stih4xx.txt | 29 ++ drivers/gpu/drm/sti/Makefile | 4 + drivers/gpu/drm/sti/sti_awg_utils.c | 184 +++++++ drivers/gpu/drm/sti/sti_awg_utils.h | 34 ++ drivers/gpu/drm/sti/sti_dvo.c | 551 +++++++++++++++++++++ drivers/gpu/drm/sti/sti_tvout.c | 118 +++++ 6 files changed, 920 insertions(+) create mode 100644 drivers/gpu/drm/sti/sti_awg_utils.c create mode 100644 drivers/gpu/drm/sti/sti_awg_utils.h create mode 100644 drivers/gpu/drm/sti/sti_dvo.c

10 years, 5 months

1
0
0 0

[RFC 0/4] dma-buf Constraints-Enabled Allocation helpers

by Sumit Semwal

Hi, Why: ==== While sharing buffers using dma-buf, currently there's no mechanism to let devices share their memory access constraints with each other to allow for delayed allocation of backing storage. This RFC attempts to introduce the idea of memory constraints of a device, and how these constraints can be shared and used to help allocate buffers that can satisfy requirements of all devices attached to a particular dma-buf. How: ==== A constraints_mask is added to dma_parms of the device, and at the time of each device attachment to a dma-buf, the dma-buf uses this constraints_mask to calculate the access_mask for the dma-buf. Allocators can be defined for each of these constraints_masks, and then helper functions can be used to allocate the backing storage from the matching allocator satisfying the constraints of all devices interested. A new miscdevice, /dev/cenalloc [1] is created, which acts as the dma-buf exporter to make this transparent to the devices. More details in the patch description of "cenalloc: Constraint-Enabled Allocation helpers for dma-buf". At present, the constraint_mask is only a bitmask, but it should be possible to change it to a struct and adapt the constraint_mask calculation accordingly, based on discussion. Important requirement: ====================== Of course, delayed allocation can only work if all participating devices will wait for other devices to have 'attached' before mapping the buffer for the first time. As of now, users of dma-buf(drm prime, v4l2 etc) call the attach() and then map_attachment() almost immediately after it. This would need to be changed if they were to benefit from constraints. What 'cenalloc' is not: ======================= - not 'general' allocator helpers - useful only for constraints-enabled devices that share buffers with others using dma-buf. - not a replacement for existing allocation mechanisms inside various subsystems; merely a possible alternative. - no page-migration - it would be very complementary to the delayed allocation suggested here. TODOs: ====== - demonstration test cases - vma helpers for allocators - more sample allocators - userspace ioctl (It should be a simple one, and we have one ready, but wanted to agree on the kernel side of things first) May the brickbats begin, please! :) Best regards, ~Sumit. [1]: 'C'onstraints 'EN'abled 'ALLOC'ation helpers = cenalloc: it might not be a very appealing name, so suggestions are very welcome! Benjamin Gaignard (1): cenalloc: a sample allocator for contiguous page allocation Sumit Semwal (3): dma-buf: Add constraints sharing information cenalloc: Constraint-Enabled Allocation helpers for dma-buf cenalloc: Build files for constraint-enabled allocation helpers MAINTAINERS | 1 + drivers/Kconfig | 2 + drivers/Makefile | 1 + drivers/cenalloc/Kconfig | 8 + drivers/cenalloc/Makefile | 3 + drivers/cenalloc/cenalloc.c | 597 ++++++++++++++++++++++++++++++ drivers/cenalloc/cenalloc.h | 99 +++++ drivers/cenalloc/cenalloc_priv.h | 188 ++++++++++ drivers/cenalloc/cenalloc_system_contig.c | 225 +++++++++++ drivers/dma-buf/dma-buf.c | 50 ++- include/linux/device.h | 7 +- include/linux/dma-buf.h | 14 + 12 files changed, 1189 insertions(+), 6 deletions(-) create mode 100644 drivers/cenalloc/Kconfig create mode 100644 drivers/cenalloc/Makefile create mode 100644 drivers/cenalloc/cenalloc.c create mode 100644 drivers/cenalloc/cenalloc.h create mode 100644 drivers/cenalloc/cenalloc_priv.h create mode 100644 drivers/cenalloc/cenalloc_system_contig.c -- 1.9.1

10 years, 5 months

5
17
0 0

arm64 - IOMMU

by Jorge Ramirez-Ortiz

Hi, I need some some pointers on how to write a IOMMU driver on arm64 for a new SoC. The iommu interface is currently not being provided in dma-mappings.c (the DMA API is SWIOTLB-based) what is the alternative? thanks Jorge

10 years, 5 months

2
1
0 0

[PATCH] drm: sti: add DVO output connector

by Benjamin Gaignard

Digital Video Out connector driver LCD panels. Like HDMI and HDA it create bridge, encoder and connector drm object. Add binding descrition. Signed-off-by: Benjamin Gaignard <benjamin.gaignard(a)linaro.org> --- .../devicetree/bindings/gpu/st,stih4xx.txt | 29 ++ drivers/gpu/drm/sti/Makefile | 4 + drivers/gpu/drm/sti/sti_awg_utils.c | 184 +++++++ drivers/gpu/drm/sti/sti_awg_utils.h | 34 ++ drivers/gpu/drm/sti/sti_dvo.c | 551 +++++++++++++++++++++ drivers/gpu/drm/sti/sti_tvout.c | 118 +++++ 6 files changed, 920 insertions(+) create mode 100644 drivers/gpu/drm/sti/sti_awg_utils.c create mode 100644 drivers/gpu/drm/sti/sti_awg_utils.h create mode 100644 drivers/gpu/drm/sti/sti_dvo.c diff --git a/Documentation/devicetree/bindings/gpu/st,stih4xx.txt b/Documentation/devicetree/bindings/gpu/st,stih4xx.txt index c99eb34..6b1d75f 100644 --- a/Documentation/devicetree/bindings/gpu/st,stih4xx.txt +++ b/Documentation/devicetree/bindings/gpu/st,stih4xx.txt @@ -83,6 +83,22 @@ sti-hda: - clock-names: names of the clocks listed in clocks property in the same order. +sti-dvo: + Required properties: + must be a child of sti-tvout + - compatible: "st,stih<chip>-dvo" + - reg: Physical base address of the IP registers and length of memory mapped region. + - reg-names: names of the mapped memory regions listed in regs property in + the same order. + - clocks: from common clock binding: handle hardware IP needed clocks, the + number of clocks may depend of the SoC type. + See ../clocks/clock-bindings.txt for details. + - clock-names: names of the clocks listed in clocks property in the same + order. + - pinctrl-0: pin control handle + - pinctrl-name: names of the pin control to use + - sti,panel: phandle of the panel connected to the DVO output + sti-hqvdp: must be a child of sti-display-subsystem Required properties: @@ -198,6 +214,19 @@ Example: clock-names = "pix", "hddac"; clocks = <&clockgen_c_vcc CLK_S_PIX_HD>, <&clockgen_c_vcc CLK_S_HDDAC>; }; + + sti-dvo@8d00400 { + compatible = "st,stih407-dvo"; + reg = <0x8d00400 0x200>; + reg-names = "dvo-reg"; + clock-names = "dvo_pix", "dvo", + "main_parent", "aux_parent"; + clocks = <&clk_s_d2_flexgen CLK_PIX_DVO>, <&clk_s_d2_flexgen CLK_DVO>, + <&clk_s_d2_quadfs 0>, <&clk_s_d2_quadfs 1>; + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_dvo>; + sti,panel = <&panel_dvo>; + }; }; sti-hqvdp@9c000000 { diff --git a/drivers/gpu/drm/sti/Makefile b/drivers/gpu/drm/sti/Makefile index 6ba9d27..f0f1e4e 100644 --- a/drivers/gpu/drm/sti/Makefile +++ b/drivers/gpu/drm/sti/Makefile @@ -12,6 +12,9 @@ stihdmi-y := sti_hdmi.o \ sti_hdmi_tx3g0c55phy.o \ sti_hdmi_tx3g4c28phy.o \ +stidvo-y := sti_dvo.o \ + sti_awg_utils.o + obj-$(CONFIG_DRM_STI) = \ sti_vtg.o \ sti_vtac.o \ @@ -20,4 +23,5 @@ obj-$(CONFIG_DRM_STI) = \ sti_tvout.o \ sticompositor.o \ sti_hqvdp.o \ + stidvo.o \ sti_drm_drv.o diff --git a/drivers/gpu/drm/sti/sti_awg_utils.c b/drivers/gpu/drm/sti/sti_awg_utils.c new file mode 100644 index 0000000..9fde3ee --- /dev/null +++ b/drivers/gpu/drm/sti/sti_awg_utils.c @@ -0,0 +1,184 @@ +/* + * Copyright (C) STMicroelectronics SA 2014 + * Author: Vincent Abriou <vincent.abriou(a)st.com> for STMicroelectronics. + * License terms: GNU General Public License (GPL), version 2 + */ + +#include "sti_awg_utils.h" + +#define AWG_OPCODE_OFFSET 10 + +enum opcode { + SET, + RPTSET, + RPLSET, + SKIP, + STOP, + REPEAT, + REPLAY, + JUMP, + HOLD, +}; + +static int awg_generate_instr(enum opcode opcode, + long int arg, + long int mux_sel, + long int data_en, + struct awg_code_generation_params *fwparams) +{ + u32 instruction = 0; + u32 mux = (mux_sel << 8) & 0x1ff; + u32 data_enable = (data_en << 9) & 0x2ff; + long int arg_tmp = arg; + + /* skip, repeat and replay arg should not exceed 1023. + * If user wants to exceed this value, the instruction should be + * duplicate and arg should be adjust for each duplicated instruction. + */ + + while (arg_tmp > 0) { + arg = arg_tmp; + if (fwparams->instruction_offset >= AWG_MAX_INST) { + DRM_ERROR("too many number of instructions\n"); + return -EINVAL; + } + + switch (opcode) { + case SKIP: + /* leave 'arg' + 1 pixel elapsing without changing + * output bus */ + arg--; /* pixel adjustment */ + arg_tmp--; + + if (arg < 0) { + /* SKIP instruction not needed */ + return 0; + } + + if (arg == 0) { + /* SKIP 0 not permitted but we want to skip 1 + * pixel. So we transform SKIP into SET + * instruction */ + opcode = SET; + arg = (arg << 24) >> 24; + arg &= (0x0ff); + break; + } + + mux = 0; + data_enable = 0; + arg = (arg << 22) >> 22; + arg &= (0x3ff); + break; + case REPEAT: + case REPLAY: + if (arg == 0) { + /* REPEAT or REPLAY instruction not needed */ + return 0; + } + + mux = 0; + data_enable = 0; + arg = (arg << 22) >> 22; + arg &= (0x3ff); + break; + case JUMP: + mux = 0; + data_enable = 0; + arg |= 0x40; /* for jump instruction 7th bit is 1 */ + arg = (arg << 22) >> 22; + arg &= 0x3ff; + break; + case STOP: + arg = 0; + break; + case SET: + case RPTSET: + case RPLSET: + case HOLD: + arg = (arg << 24) >> 24; + arg &= (0x0ff); + break; + default: + DRM_ERROR("instruction %d does not exist\n", opcode); + return -EINVAL; + } + + arg_tmp = arg_tmp - arg; + + arg = ((arg + mux) + data_enable); + + instruction = ((opcode) << AWG_OPCODE_OFFSET) | arg; + fwparams->ram_code[fwparams->instruction_offset] = + instruction & (0x3fff); + fwparams->instruction_offset++; + } + return 0; +} + +int sti_awg_generate_code_data_enable_mode( + struct awg_code_generation_params *fwparams, + struct awg_timing *timing) +{ + long int val; + long int data_en; + int ret = 0; + + if (timing->trailing_lines > 0) { + /* skip trailing lines */ + val = timing->blanking_level; + data_en = 0; + ret |= awg_generate_instr(RPLSET, val, 0, data_en, fwparams); + + val = timing->trailing_lines - 1; + data_en = 0; + ret |= awg_generate_instr(REPLAY, val, 0, data_en, fwparams); + } + + if (timing->trailing_pixels > 0) { + /* skip trailing pixel */ + val = timing->blanking_level; + data_en = 0; + ret |= awg_generate_instr(RPLSET, val, 0, data_en, fwparams); + + val = timing->trailing_pixels - 1; + data_en = 0; + ret |= awg_generate_instr(SKIP, val, 0, data_en, fwparams); + } + + /* set DE signal high */ + val = timing->blanking_level; + data_en = 1; + ret |= awg_generate_instr((timing->trailing_pixels > 0) ? SET : RPLSET, + val, 0, data_en, fwparams); + + if (timing->blanking_pixels > 0) { + /* skip the number of active pixel */ + val = timing->active_pixels - 1; + data_en = 1; + ret |= awg_generate_instr(SKIP, val, 0, data_en, fwparams); + + /* set DE signal low */ + val = timing->blanking_level; + data_en = 0; + ret |= awg_generate_instr(SET, val, 0, data_en, fwparams); + } + + /* replay the sequence as many active lines defined */ + val = timing->active_lines - 1; + data_en = 0; + ret |= awg_generate_instr(REPLAY, val, 0, data_en, fwparams); + + if (timing->blanking_lines > 0) { + /* skip blanking lines */ + val = timing->blanking_level; + data_en = 0; + ret |= awg_generate_instr(RPLSET, val, 0, data_en, fwparams); + + val = timing->blanking_lines - 1; + data_en = 0; + ret |= awg_generate_instr(REPLAY, val, 0, data_en, fwparams); + } + + return ret; +} diff --git a/drivers/gpu/drm/sti/sti_awg_utils.h b/drivers/gpu/drm/sti/sti_awg_utils.h new file mode 100644 index 0000000..45d599b --- /dev/null +++ b/drivers/gpu/drm/sti/sti_awg_utils.h @@ -0,0 +1,34 @@ +/* + * Copyright (C) STMicroelectronics SA 2014 + * Author: Vincent Abriou <vincent.abriou(a)st.com> for STMicroelectronics. + * License terms: GNU General Public License (GPL), version 2 + */ + +#ifndef _STI_AWG_UTILS_H_ +#define _STI_AWG_UTILS_H_ + +#include <drm/drmP.h> + +#define AWG_MAX_INST 64 + +struct awg_code_generation_params { + u32 *ram_code; + u8 instruction_offset; +}; + +struct awg_timing { + u32 total_lines; + u32 active_lines; + u32 blanking_lines; + u32 trailing_lines; + u32 total_pixels; + u32 active_pixels; + u32 blanking_pixels; + u32 trailing_pixels; + u32 blanking_level; +}; + +int sti_awg_generate_code_data_enable_mode( + struct awg_code_generation_params *fw_gen_params, + struct awg_timing *timing); +#endif diff --git a/drivers/gpu/drm/sti/sti_dvo.c b/drivers/gpu/drm/sti/sti_dvo.c new file mode 100644 index 0000000..651afad --- /dev/null +++ b/drivers/gpu/drm/sti/sti_dvo.c @@ -0,0 +1,551 @@ +/* + * Copyright (C) STMicroelectronics SA 2014 + * Author: Vincent Abriou <vincent.abriou(a)st.com> for STMicroelectronics. + * License terms: GNU General Public License (GPL), version 2 + */ + +#include <linux/clk.h> +#include <linux/component.h> +#include <linux/module.h> +#include <linux/of_gpio.h> +#include <linux/platform_device.h> + +#include <drm/drmP.h> +#include <drm/drm_crtc_helper.h> +#include <drm/drm_panel.h> + +#include "sti_awg_utils.h" +#include "sti_mixer.h" + +/* DVO registers */ +#define DVO_AWG_DIGSYNC_CTRL 0x0000 +#define DVO_DOF_CFG 0x0004 +#define DVO_LUT_PROG_LOW 0x0008 +#define DVO_LUT_PROG_MID 0x000C +#define DVO_LUT_PROG_HIGH 0x0010 +#define DVO_DIGSYNC_INSTR_I 0x0100 + +#define DVO_AWG_CTRL_EN BIT(0) +#define DVO_AWG_FRAME_BASED_SYNC BIT(2) + +#define DVO_DOF_EN_LOWBYTE BIT(0) +#define DVO_DOF_EN_MIDBYTE BIT(1) +#define DVO_DOF_EN_HIGHBYTE BIT(2) +#define DVO_DOF_EN BIT(6) +#define DVO_DOF_MOD_COUNT_SHIFT 8 + +#define DVO_LUT_ZERO 0 +#define DVO_LUT_Y_G 1 +#define DVO_LUT_Y_G_DEL 2 +#define DVO_LUT_CB_B 3 +#define DVO_LUT_CB_B_DEL 4 +#define DVO_LUT_CR_R 5 +#define DVO_LUT_CR_R_DEL 6 +#define DVO_LUT_HOLD 7 + +struct dvo_config { + u32 flags; + u32 lowbyte; + u32 midbyte; + u32 highbyte; + int (*awg_fwgen_fct)( + struct awg_code_generation_params *fw_gen_params, + struct awg_timing *timing); +}; + +static struct dvo_config rgb_24bit_de_cfg = { + .flags = (0L << DVO_DOF_MOD_COUNT_SHIFT), + .lowbyte = DVO_LUT_CR_R, + .midbyte = DVO_LUT_Y_G, + .highbyte = DVO_LUT_CB_B, + .awg_fwgen_fct = sti_awg_generate_code_data_enable_mode, +}; + +/** + * STI digital video output structure + * + * @dev: driver device + * @drm_dev: pointer to drm device + * @mode: current display mode selected + * @regs: dvo registers + * @clk_pix: pixel clock for dvo + * @clk: clock for dvo + * @clk_main_parent: dvo parent clock if main path used + * @clk_aux_parent: dvo parent clock if aux path used + * @panel_node: panel node reference from device tree + * @panel: reference to the panel connected to the dvo + * @enabled: true if dvo is enabled else false + * @encoder: drm_encoder it is bound + */ +struct sti_dvo { + struct device dev; + struct drm_device *drm_dev; + struct drm_display_mode mode; + void __iomem *regs; + struct clk *clk_pix; + struct clk *clk; + struct clk *clk_main_parent; + struct clk *clk_aux_parent; + struct device_node *panel_node; + struct drm_panel *panel; + struct dvo_config *config; + bool enabled; + struct drm_encoder *encoder; +}; + +struct sti_dvo_connector { + struct drm_connector drm_connector; + struct drm_encoder *encoder; + struct sti_dvo *dvo; +}; + +#define to_sti_dvo_connector(x) \ + container_of(x, struct sti_dvo_connector, drm_connector) + +#define BLANKING_LEVEL 16 +int dvo_awg_generate_code(struct sti_dvo *dvo, u8 *ram_size, u32 *ram_code) +{ + struct drm_display_mode *mode = &dvo->mode; + struct dvo_config *config = dvo->config; + struct awg_code_generation_params fw_gen_params; + struct awg_timing timing; + + fw_gen_params.ram_code = ram_code; + fw_gen_params.instruction_offset = 0; + + timing.total_lines = mode->vtotal; + timing.active_lines = mode->vdisplay; + timing.blanking_lines = mode->vsync_start - mode->vdisplay; + timing.trailing_lines = mode->vtotal - mode->vsync_start; + timing.total_pixels = mode->htotal; + timing.active_pixels = mode->hdisplay; + timing.blanking_pixels = mode->hsync_start - mode->hdisplay; + timing.trailing_pixels = mode->htotal - mode->hsync_start; + timing.blanking_level = BLANKING_LEVEL; + + if (config->awg_fwgen_fct(&fw_gen_params, &timing)) { + DRM_ERROR("AWG firmware not properly generated\n"); + return -EINVAL; + } + + *ram_size = fw_gen_params.instruction_offset; + + return 0; +} + +/* Configure AWG, writing instructions + * + * @dvo: pointer to DVO structure + * @awg_ram_code: pointer to AWG instructions table + * @nb: nb of AWG instructions + */ +static void dvo_awg_configure(struct sti_dvo *dvo, u32 *awg_ram_code, int nb) +{ + int i; + + DRM_DEBUG_DRIVER("\n"); + + for (i = 0; i < nb; i++) + writel(awg_ram_code[i], + dvo->regs + DVO_DIGSYNC_INSTR_I + i * 4); + for (i = nb; i < AWG_MAX_INST; i++) + writel(0, dvo->regs + DVO_DIGSYNC_INSTR_I + i * 4); + + writel(DVO_AWG_CTRL_EN, dvo->regs + DVO_AWG_DIGSYNC_CTRL); +} + +static void sti_dvo_disable(struct drm_bridge *bridge) +{ + struct sti_dvo *dvo = bridge->driver_private; + + if (!dvo->enabled) + return; + + DRM_DEBUG_DRIVER("\n"); + + if (dvo->config->awg_fwgen_fct) + writel(0x00000000, dvo->regs + DVO_AWG_DIGSYNC_CTRL); + + writel(0x00000000, dvo->regs + DVO_DOF_CFG); + + if (dvo->panel) + dvo->panel->funcs->disable(dvo->panel); + + /* Disable/unprepare dvo clock */ + clk_disable_unprepare(dvo->clk_pix); + clk_disable_unprepare(dvo->clk); + + dvo->enabled = false; +} + +static void sti_dvo_pre_enable(struct drm_bridge *bridge) +{ + struct sti_dvo *dvo = bridge->driver_private; + struct dvo_config *config = dvo->config; + u32 val; + + DRM_DEBUG_DRIVER("\n"); + + if (dvo->enabled) + return; + + /* Make sure DVO is disabled */ + writel(0x00000000, dvo->regs + DVO_DOF_CFG); + writel(0x00000000, dvo->regs + DVO_AWG_DIGSYNC_CTRL); + + if (config->awg_fwgen_fct) { + u8 nb_instr; + u32 awg_ram_code[AWG_MAX_INST]; + /* Configure AWG */ + if (!dvo_awg_generate_code(dvo, &nb_instr, awg_ram_code)) + dvo_awg_configure(dvo, awg_ram_code, nb_instr); + else + return; + } + + /* Prepare/enable clocks */ + if (clk_prepare_enable(dvo->clk_pix)) + DRM_ERROR("Failed to prepare/enable dvo_pix clk\n"); + if (clk_prepare_enable(dvo->clk)) + DRM_ERROR("Failed to prepare/enable dvo clk\n"); + + if (dvo->panel) + dvo->panel->funcs->enable(dvo->panel); + + /* Set LUT */ + writel(config->lowbyte, dvo->regs + DVO_LUT_PROG_LOW); + writel(config->midbyte, dvo->regs + DVO_LUT_PROG_MID); + writel(config->highbyte, dvo->regs + DVO_LUT_PROG_HIGH); + + /* Digital output formatter config */ + val = (config->flags | DVO_DOF_EN); + writel(val, dvo->regs + DVO_DOF_CFG); + + dvo->enabled = true; +} + +static void sti_dvo_set_mode(struct drm_bridge *bridge, + struct drm_display_mode *mode, + struct drm_display_mode *adjusted_mode) +{ + struct sti_dvo *dvo = bridge->driver_private; + struct sti_mixer *mixer = to_sti_mixer(dvo->encoder->crtc); + int rate = mode->clock * 1000; + struct clk *clkp; + int ret; + + DRM_DEBUG_DRIVER("\n"); + + memcpy(&dvo->mode, mode, sizeof(struct drm_display_mode)); + + /* According to the path used (main or aux), the dvo clocks should + * have a different parent clock. */ + if (mixer->id == STI_MIXER_MAIN) + clkp = dvo->clk_main_parent; + else + clkp = dvo->clk_aux_parent; + + if (clkp) { + clk_set_parent(dvo->clk_pix, clkp); + clk_set_parent(dvo->clk, clkp); + } + + /* DVO clocks = compositor clock */ + ret = clk_set_rate(dvo->clk_pix, rate); + if (ret < 0) { + DRM_ERROR("Cannot set rate (%dHz) for dvo_pix clk\n", rate); + return; + } + + ret = clk_set_rate(dvo->clk, rate); + if (ret < 0) { + DRM_ERROR("Cannot set rate (%dHz) for dvo clk\n", rate); + return; + } + + /* For now, we only support 24bit data enable (DE) synchro format */ + dvo->config = &rgb_24bit_de_cfg; +} + +static void sti_dvo_bridge_nope(struct drm_bridge *bridge) +{ + /* do nothing */ +} + +static void sti_dvo_brigde_destroy(struct drm_bridge *bridge) +{ + drm_bridge_cleanup(bridge); + kfree(bridge); +} + +static const struct drm_bridge_funcs sti_dvo_bridge_funcs = { + .pre_enable = sti_dvo_pre_enable, + .enable = sti_dvo_bridge_nope, + .disable = sti_dvo_disable, + .post_disable = sti_dvo_bridge_nope, + .mode_set = sti_dvo_set_mode, + .destroy = sti_dvo_brigde_destroy, +}; + +static int sti_dvo_connector_get_modes(struct drm_connector *connector) +{ + struct sti_dvo_connector *dvo_connector + = to_sti_dvo_connector(connector); + struct sti_dvo *dvo = dvo_connector->dvo; + + if (dvo->panel) + return dvo->panel->funcs->get_modes(dvo->panel); + + return 0; +} + +#define CLK_TOLERANCE_HZ 50 + +static int sti_dvo_connector_mode_valid(struct drm_connector *connector, + struct drm_display_mode *mode) +{ + int target = mode->clock * 1000; + int target_min = target - CLK_TOLERANCE_HZ; + int target_max = target + CLK_TOLERANCE_HZ; + int result; + struct sti_dvo_connector *dvo_connector + = to_sti_dvo_connector(connector); + struct sti_dvo *dvo = dvo_connector->dvo; + + result = clk_round_rate(dvo->clk_pix, target); + + DRM_DEBUG_DRIVER("target rate = %d => available rate = %d\n", + target, result); + + if ((result < target_min) || (result > target_max)) { + DRM_DEBUG_DRIVER("dvo pixclk=%d not supported\n", target); + return MODE_BAD; + } + + return MODE_OK; +} + +struct drm_encoder *sti_dvo_best_encoder(struct drm_connector *connector) +{ + struct sti_dvo_connector *dvo_connector + = to_sti_dvo_connector(connector); + + /* Best encoder is the one associated during connector creation */ + return dvo_connector->encoder; +} + +static struct drm_connector_helper_funcs sti_dvo_connector_helper_funcs = { + .get_modes = sti_dvo_connector_get_modes, + .mode_valid = sti_dvo_connector_mode_valid, + .best_encoder = sti_dvo_best_encoder, +}; + +static enum drm_connector_status +sti_dvo_connector_detect(struct drm_connector *connector, bool force) +{ + struct sti_dvo_connector *dvo_connector + = to_sti_dvo_connector(connector); + struct sti_dvo *dvo = dvo_connector->dvo; + + DRM_DEBUG_DRIVER("\n"); + + if (!dvo->panel) + dvo->panel = of_drm_find_panel(dvo->panel_node); + + if (dvo->panel) + if (!drm_panel_attach(dvo->panel, connector)) + return connector_status_connected; + + return connector_status_disconnected; +} + +static void sti_dvo_connector_destroy(struct drm_connector *connector) +{ + struct sti_dvo_connector *dvo_connector + = to_sti_dvo_connector(connector); + + drm_connector_unregister(connector); + drm_connector_cleanup(connector); + kfree(dvo_connector); +} + +static struct drm_connector_funcs sti_dvo_connector_funcs = { + .dpms = drm_helper_connector_dpms, + .fill_modes = drm_helper_probe_single_connector_modes, + .detect = sti_dvo_connector_detect, + .destroy = sti_dvo_connector_destroy, +}; + +static struct drm_encoder *sti_dvo_find_encoder(struct drm_device *dev) +{ + struct drm_encoder *encoder; + + list_for_each_entry(encoder, &dev->mode_config.encoder_list, head) { + if (encoder->encoder_type == DRM_MODE_ENCODER_LVDS) + return encoder; + } + + return NULL; +} + +static int sti_dvo_bind(struct device *dev, struct device *master, void *data) +{ + struct sti_dvo *dvo = dev_get_drvdata(dev); + struct drm_device *drm_dev = data; + struct drm_encoder *encoder; + struct sti_dvo_connector *connector; + struct drm_connector *drm_connector; + struct drm_bridge *bridge; + int err; + + /* Set the drm device handle */ + dvo->drm_dev = drm_dev; + + encoder = sti_dvo_find_encoder(drm_dev); + if (!encoder) + return -ENOMEM; + + connector = devm_kzalloc(dev, sizeof(*connector), GFP_KERNEL); + if (!connector) + return -ENOMEM; + + connector->dvo = dvo; + + bridge = devm_kzalloc(dev, sizeof(*bridge), GFP_KERNEL); + if (!bridge) + return -ENOMEM; + + bridge->driver_private = dvo; + drm_bridge_init(drm_dev, bridge, &sti_dvo_bridge_funcs); + + encoder->bridge = bridge; + connector->encoder = encoder; + dvo->encoder = encoder; + + drm_connector = (struct drm_connector *)connector; + + drm_connector->polled = DRM_CONNECTOR_POLL_HPD; + + drm_connector_init(drm_dev, drm_connector, + &sti_dvo_connector_funcs, DRM_MODE_CONNECTOR_LVDS); + drm_connector_helper_add(drm_connector, + &sti_dvo_connector_helper_funcs); + + err = drm_connector_register(drm_connector); + if (err) + goto err_connector; + + err = drm_mode_connector_attach_encoder(drm_connector, encoder); + if (err) { + DRM_ERROR("Failed to attach a connector to a encoder\n"); + goto err_sysfs; + } + + return 0; + +err_sysfs: + drm_connector_unregister(drm_connector); +err_connector: + drm_bridge_cleanup(bridge); + drm_connector_cleanup(drm_connector); + return -EINVAL; +} + +static void sti_dvo_unbind(struct device *dev, + struct device *master, void *data) +{ + /* do nothing */ +} + +static const struct component_ops sti_dvo_ops = { + .bind = sti_dvo_bind, + .unbind = sti_dvo_unbind, +}; + +static int sti_dvo_probe(struct platform_device *pdev) +{ + struct device *dev = &pdev->dev; + struct sti_dvo *dvo; + struct resource *res; + struct device_node *np = dev->of_node; + + DRM_INFO("%s\n", __func__); + + dvo = devm_kzalloc(dev, sizeof(*dvo), GFP_KERNEL); + if (!dvo) { + DRM_ERROR("Failed to allocate memory for DVO\n"); + return -ENOMEM; + } + + dvo->dev = pdev->dev; + + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "dvo-reg"); + if (!res) { + DRM_ERROR("Invalid dvo resource\n"); + return -ENOMEM; + } + dvo->regs = devm_ioremap_nocache(dev, res->start, + resource_size(res)); + if (IS_ERR(dvo->regs)) + return PTR_ERR(dvo->regs); + + dvo->clk_pix = devm_clk_get(dev, "dvo_pix"); + if (IS_ERR(dvo->clk_pix)) { + DRM_ERROR("Cannot get dvo_pix clock\n"); + return PTR_ERR(dvo->clk_pix); + } + + dvo->clk = devm_clk_get(dev, "dvo"); + if (IS_ERR(dvo->clk)) { + DRM_ERROR("Cannot get dvo clock\n"); + return PTR_ERR(dvo->clk); + } + + dvo->clk_main_parent = devm_clk_get(dev, "main_parent"); + if (IS_ERR(dvo->clk_main_parent)) { + DRM_DEBUG_DRIVER("Cannot get main_parent clock\n"); + dvo->clk_main_parent = NULL; + } + + dvo->clk_aux_parent = devm_clk_get(dev, "aux_parent"); + if (IS_ERR(dvo->clk_aux_parent)) { + DRM_DEBUG_DRIVER("Cannot get aux_parent clock\n"); + dvo->clk_aux_parent = NULL; + } + + dvo->panel_node = of_parse_phandle(np, "sti,panel", 0); + if (!dvo->panel_node) + DRM_ERROR("No panel associated to the dvo output\n"); + + platform_set_drvdata(pdev, dvo); + + return component_add(&pdev->dev, &sti_dvo_ops); +} + +static int sti_dvo_remove(struct platform_device *pdev) +{ + component_del(&pdev->dev, &sti_dvo_ops); + return 0; +} + +static struct of_device_id dvo_of_match[] = { + { .compatible = "st,stih407-dvo", }, + { /* end node */ } +}; +MODULE_DEVICE_TABLE(of, dvo_of_match); + +struct platform_driver sti_dvo_driver = { + .driver = { + .name = "sti-dvo", + .owner = THIS_MODULE, + .of_match_table = dvo_of_match, + }, + .probe = sti_dvo_probe, + .remove = sti_dvo_remove, +}; + +module_platform_driver(sti_dvo_driver); + +MODULE_AUTHOR("Benjamin Gaignard <benjamin.gaignard(a)st.com>"); +MODULE_DESCRIPTION("STMicroelectronics SoC DRM driver"); +MODULE_LICENSE("GPL"); diff --git a/drivers/gpu/drm/sti/sti_tvout.c b/drivers/gpu/drm/sti/sti_tvout.c index cb924aa..5cc5311 100644 --- a/drivers/gpu/drm/sti/sti_tvout.c +++ b/drivers/gpu/drm/sti/sti_tvout.c @@ -48,6 +48,9 @@ #define TVO_HDMI_CLIP_VALUE_R_CR 0x514 #define TVO_HDMI_SYNC_SEL 0x518 #define TVO_HDMI_DFV_OBS 0x540 +#define TVO_VIP_DVO 0x600 +#define TVO_DVO_SYNC_SEL 0x618 +#define TVO_DVO_CONFIG 0x620 #define TVO_IN_FMT_SIGNED BIT(0) #define TVO_SYNC_EXT BIT(4) @@ -98,6 +101,9 @@ #define TVO_SYNC_HD_DCS_SHIFT 8 +#define TVO_SYNC_DVO_PAD_HSYNC_SHIFT 8 +#define TVO_SYNC_DVO_PAD_VSYNC_SHIFT 16 + #define ENCODER_CRTC_MASK (BIT(0) | BIT(1)) /* enum listing the supported output data format */ @@ -113,6 +119,7 @@ struct sti_tvout { struct reset_control *reset; struct drm_encoder *hdmi; struct drm_encoder *hda; + struct drm_encoder *dvo; }; struct sti_tvout_encoder { @@ -262,6 +269,66 @@ static void tvout_vip_set_in_vid_fmt(struct sti_tvout *tvout, } /** + * Start VIP block for DVO output + * + * @tvout: pointer on tvout structure + * @main_path: true if main path has to be used in the vip configuration + * else aux path is used. + */ +static void tvout_dvo_start(struct sti_tvout *tvout, bool main_path) +{ + struct device_node *node = tvout->dev->of_node; + bool sel_input_logic_inverted = false; + u32 tvo_in_vid_format; + int val; + + dev_dbg(tvout->dev, "%s\n", __func__); + + if (main_path) { + DRM_DEBUG_DRIVER("main vip for DVO\n"); + /* Select the input sync for dvo = VTG set 4 */ + val = TVO_SYNC_MAIN_VTG_SET_4 << TVO_SYNC_DVO_PAD_VSYNC_SHIFT; + val |= TVO_SYNC_MAIN_VTG_SET_4 << TVO_SYNC_DVO_PAD_HSYNC_SHIFT; + val |= TVO_SYNC_MAIN_VTG_SET_4; + tvout_write(tvout, val, TVO_DVO_SYNC_SEL); + tvo_in_vid_format = TVO_MAIN_IN_VID_FORMAT; + } else { + DRM_DEBUG_DRIVER("aux vip for DVO\n"); + /* Select the input sync for dvo = VTG set 4 */ + val = TVO_SYNC_AUX_VTG_SET_4 << TVO_SYNC_DVO_PAD_VSYNC_SHIFT; + val |= TVO_SYNC_AUX_VTG_SET_4 << TVO_SYNC_DVO_PAD_HSYNC_SHIFT; + val |= TVO_SYNC_AUX_VTG_SET_4; + tvout_write(tvout, val, TVO_DVO_SYNC_SEL); + tvo_in_vid_format = TVO_AUX_IN_VID_FORMAT; + } + + /* Set color channel order */ + tvout_vip_set_color_order(tvout, TVO_VIP_DVO, + TVO_VIP_REORDER_CR_R_SEL, + TVO_VIP_REORDER_Y_G_SEL, + TVO_VIP_REORDER_CB_B_SEL); + + /* Set clipping mode (Limited range RGB/Y) */ + tvout_vip_set_clip_mode(tvout, TVO_VIP_DVO, + TVO_VIP_CLIP_LIMITED_RANGE_RGB_Y); + + /* Set round mode (rounded to 8-bit per component) */ + tvout_vip_set_rnd(tvout, TVO_VIP_DVO, TVO_VIP_RND_8BIT_ROUNDED); + + if (of_device_is_compatible(node, "st,stih407-tvout")) { + /* Set input video format */ + tvout_vip_set_in_vid_fmt(tvout, tvo_in_vid_format, + TVO_IN_FMT_SIGNED); + sel_input_logic_inverted = true; + } + + /* Input selection */ + tvout_vip_set_sel_input(tvout, TVO_VIP_DVO, main_path, + sel_input_logic_inverted, + STI_TVOUT_VIDEO_OUT_RGB); +} + +/** * Start VIP block for HDMI output * * @tvout: pointer on tvout structure @@ -402,6 +469,56 @@ static const struct drm_encoder_funcs sti_tvout_encoder_funcs = { .destroy = sti_tvout_encoder_destroy, }; +static void sti_dvo_encoder_commit(struct drm_encoder *encoder) +{ + struct sti_tvout *tvout = to_sti_tvout(encoder); + + tvout_dvo_start(tvout, sti_drm_crtc_is_main(encoder->crtc)); +} + +static void sti_dvo_encoder_disable(struct drm_encoder *encoder) +{ + struct sti_tvout *tvout = to_sti_tvout(encoder); + + /* Reset VIP register */ + tvout_write(tvout, 0x0, TVO_VIP_DVO); +} + +static const struct drm_encoder_helper_funcs sti_dvo_encoder_helper_funcs = { + .dpms = sti_tvout_encoder_dpms, + .mode_fixup = sti_tvout_encoder_mode_fixup, + .mode_set = sti_tvout_encoder_mode_set, + .prepare = sti_tvout_encoder_prepare, + .commit = sti_dvo_encoder_commit, + .disable = sti_dvo_encoder_disable, +}; + +static struct drm_encoder * +sti_tvout_create_dvo_encoder(struct drm_device *dev, + struct sti_tvout *tvout) +{ + struct sti_tvout_encoder *encoder; + struct drm_encoder *drm_encoder; + + encoder = devm_kzalloc(tvout->dev, sizeof(*encoder), GFP_KERNEL); + if (!encoder) + return NULL; + + encoder->tvout = tvout; + + drm_encoder = (struct drm_encoder *)encoder; + + drm_encoder->possible_crtcs = ENCODER_CRTC_MASK; + drm_encoder->possible_clones = 1 << 0; + + drm_encoder_init(dev, drm_encoder, + &sti_tvout_encoder_funcs, DRM_MODE_ENCODER_LVDS); + + drm_encoder_helper_add(drm_encoder, &sti_dvo_encoder_helper_funcs); + + return drm_encoder; +} + static void sti_hda_encoder_commit(struct drm_encoder *encoder) { struct sti_tvout *tvout = to_sti_tvout(encoder); @@ -508,6 +625,7 @@ static void sti_tvout_create_encoders(struct drm_device *dev, { tvout->hdmi = sti_tvout_create_hdmi_encoder(dev, tvout); tvout->hda = sti_tvout_create_hda_encoder(dev, tvout); + tvout->dvo = sti_tvout_create_dvo_encoder(dev, tvout); } static void sti_tvout_destroy_encoders(struct sti_tvout *tvout) -- 1.9.1

10 years, 5 months

1
0
0 0

Re: [Linaro-mm-sig] [PATCH 0/7] Generic dmabuf protocol RFCv1

by Pekka Paalanen

Hi, I'm adding more people to CC who have commented on Wayland dmabuf attempts before and might be interested. If you want to keep updated without monitoring wayland-devel@, you could subscribe to https://bugs.freedesktop.org/show_bug.cgi?id=83881 Thanks, pq On Fri, 12 Dec 2014 16:51:01 -0500 Louis-Francis Ratté-Boulianne <lfrb(a)collabora.com> wrote: > This serie of patches by Pekka and George contains an experimental > implementation of "zlinux_dmabuf" protocol. > > See these links for more information about the design and failed previous > attempts: > > http://lists.freedesktop.org/archives/wayland-devel/2014-June/015362.html > https://bugs.freedesktop.org/show_bug.cgi?id=83881 > > This protocol allows clients to wrap a dmabuf into a wl_buffer, and push that > into the compositor for display. The compositor then uses GBM to import that > wl_buffer as a bo for compositing with GL (via EGLImage) or direct scanout as a > DRM FB object. > > Note that a round-trip is needed when creating the buffer because there is no > way to communicate all dmabuf constraints from the compositor to a client > before-hand. They are simply too complicated and changing to be described in > a Wayland protocol extension. In fact, there are existing APIs like EGL (the > dmabuf import extension) that are based on trial-and-error rather than knowing > the constraints before-hand. > > However, the protocol design is far far away from complete. Even the kernel > developers are still discussing, how cross-device support for dmabufs should > work, and what is the proper information split between the kernel and the user > space. How do you communicate, or even describe, things like tiling formats. > > But, we should start from somewhere, and this patch is pushing the user space > part forward a bit. > > The extension is especially useful for video players and this pipeline has been > demonstrated to work with GStreamer: > > http://cgit.collabora.com/git/user/gkiagia/gst-plugins-bad.git/commit/?h=in… > > > George Kiagiadakis (1): > clients: add simple-dmabuf client > > Pekka Paalanen (6): > protocol: add linux_dmabuf extension RFCv1 > dmabuf: implement linux_dmabuf extension > gl-renderer: add dmabuf import > compositor-x11: init linux_dmabuf support > compositor-drm: init linux_dmabuf support > compositor-drm: dmabuf GBM import > > .gitignore | 1 + > Makefile.am | 24 +- > clients/simple-dmabuf.c | 578 ++++++++++++++++++++++++++++++++++++++++++++++ > configure.ac | 9 + > protocol/linux-dmabuf.xml | 224 ++++++++++++++++++ > src/compositor-drm.c | 31 ++- > src/compositor-x11.c | 5 + > src/gl-renderer.c | 103 +++++++++ > src/linux-dmabuf.c | 322 ++++++++++++++++++++++++++ > src/linux-dmabuf.h | 45 ++++ > 10 files changed, 1336 insertions(+), 6 deletions(-) > create mode 100644 clients/simple-dmabuf.c > create mode 100644 protocol/linux-dmabuf.xml > create mode 100644 src/linux-dmabuf.c > create mode 100644 src/linux-dmabuf.h >

10 years, 5 months

1
0
0 0

[PATCH] drm: sti: fix module compilation issue

by Benjamin Gaignard

When compiling in module some symbol aren't missing, export them correctly. Signed-off-by: Benjamin Gaignard <benjamin.gaignard(a)linaro.org> --- drivers/gpu/drm/sti/sti_drm_plane.c | 1 + drivers/gpu/drm/sti/sti_hqvdp.c | 1 + drivers/gpu/drm/sti/sti_layer.c | 2 ++ 3 files changed, 4 insertions(+) diff --git a/drivers/gpu/drm/sti/sti_drm_plane.c b/drivers/gpu/drm/sti/sti_drm_plane.c index c9dd0e5..bb6a293 100644 --- a/drivers/gpu/drm/sti/sti_drm_plane.c +++ b/drivers/gpu/drm/sti/sti_drm_plane.c @@ -194,3 +194,4 @@ struct drm_plane *sti_drm_plane_init(struct drm_device *dev, return &layer->plane; } +EXPORT_SYMBOL(sti_drm_plane_init); diff --git a/drivers/gpu/drm/sti/sti_hqvdp.c b/drivers/gpu/drm/sti/sti_hqvdp.c index 200d020..f3db05d 100644 --- a/drivers/gpu/drm/sti/sti_hqvdp.c +++ b/drivers/gpu/drm/sti/sti_hqvdp.c @@ -816,6 +816,7 @@ struct sti_layer *sti_hqvdp_create(struct device *dev) return &hqvdp->layer; } +EXPORT_SYMBOL(sti_hqvdp_create); static void sti_hqvdp_init_plugs(struct sti_hqvdp *hqvdp) { diff --git a/drivers/gpu/drm/sti/sti_layer.c b/drivers/gpu/drm/sti/sti_layer.c index 480ec1c..899104f 100644 --- a/drivers/gpu/drm/sti/sti_layer.c +++ b/drivers/gpu/drm/sti/sti_layer.c @@ -40,6 +40,7 @@ const char *sti_layer_to_str(struct sti_layer *layer) return "<UNKNOWN LAYER>"; } } +EXPORT_SYMBOL(sti_layer_to_str); struct sti_layer *sti_layer_create(struct device *dev, int desc, void __iomem *baseaddr) @@ -77,6 +78,7 @@ struct sti_layer *sti_layer_create(struct device *dev, int desc, return layer; } +EXPORT_SYMBOL(sti_layer_create); int sti_layer_prepare(struct sti_layer *layer, struct drm_crtc *crtc, -- 1.9.1

10 years, 5 months

1
0
0 0

[PATCH 0/9] fixes for STI drm driver

by Benjamin Gaignard

This series of patches fix various issues in STI drm driver. Now HDMI i2c adapter could be selected in device tree and plug detection doesn't use gpio anymore. I also had fix some signal timing problems after testing the driver on more hardware. The remaining patches attemps to simplify the code and prepare the next evolutions like DVO and auxiliary CRTC support The changes could be fetch here: http://git.linaro.org/people/benjamin.gaignard/kernel.git on drm-sti-fixes-2014-12-04 branch Benjamin Gaignard (9): drm: sti: allow to change hdmi ddc i2c adapter drm: sti: remove gpio for HDMI hot plug detection drm: sti: clear all mixer control drm: sti: simplify gdp code drm: sti: remove event lock while disabling vblank drm: sti: fix hdmi avi infoframe drm: sti: use drm_crtc_vblank_{on/off} instead of drm_vblank_{on/off} drm: sti: prepare sti_tvout to support auxiliary crtc drm: sti: fix delay in VTG programming .../devicetree/bindings/gpu/st,stih4xx.txt | 3 +- drivers/gpu/drm/sti/sti_drm_crtc.c | 10 +-- drivers/gpu/drm/sti/sti_gdp.c | 39 ++++----- drivers/gpu/drm/sti/sti_hdmi.c | 84 +++++++++++--------- drivers/gpu/drm/sti/sti_hdmi.h | 6 +- drivers/gpu/drm/sti/sti_mixer.c | 9 +++ drivers/gpu/drm/sti/sti_mixer.h | 1 + drivers/gpu/drm/sti/sti_tvout.c | 92 ++++++++++++---------- drivers/gpu/drm/sti/sti_vtg.c | 25 +++++- 9 files changed, 160 insertions(+), 109 deletions(-) -- 1.9.1

10 years, 6 months

1
9
0 0

[PATCH v2 00/18] Exynos SYSMMU (IOMMU) integration with DT and DMA-mapping subsystem

by Marek Szyprowski

Hello Everyone, This is yet another attempt to finally make Exynos SYSMMU driver fully integrated with DMA-mapping subsystem. Previous approach is available here: https://lkml.org/lkml/2014/8/5/183 I meantime, there have been a discussion about the way the iommu driver should be integrated with dma-mapping subsystem, which resulted in "[RFC PATCH v3 0/7] Introduce automatic DMA configuration for IOMMU masters" patches prepared by Will Deacon: http://www.spinics.net/lists/arm-kernel/msg362076.html Those patches removed the need to use bus-specific notifiers for initialization. Main changes since previous version of my patches: 1. rebased onto "[RFC PATCH v3 0/7] Introduce automatic DMA configuration for IOMMU masters" patches, changed initialization from bus notifiers to DT related callbacks 2. removed support for separate IO address spaces - this will be discussed separately after the basic support gets merged 3. removed support for power domain notifier-based runtime power management - this also will be discussed separately later I hope that the driver with above changes will be easier to be merged to v3.18. Best regards Marek Szyprowski Samsung R&D Institute Poland Patch summary: Marek Szyprowski (18): arm: dma-mapping: arm_iommu_attach_device: automatically set max_seg_size arm: exynos: bind power domains earlier, on device creation drm: exynos: detach from default dma-mapping domain on init clk: exynos: add missing smmu_g2d clock and update comments ARM: DTS: Exynos4: add System MMU nodes iommu: exynos: don't read version register on every tlb operation iommu: exynos: remove unused functions iommu: exynos: remove useless spinlock iommu: exynos: refactor function parameters to simplify code iommu: exynos: remove unused functions, part 2 iommu: exynos: remove useless device_add/remove callbacks iommu: exynos: add support for binding more than one sysmmu to master device iommu: exynos: add support for runtime_pm iommu: exynos: rename variables to reflect their purpose iommu: exynos: document internal structures iommu: exynos: remove excessive includes and sort others alphabetically iommu: exynos: init from dt-specific callback instead of initcall iommu: exynos: add callback for initializing devices from device tree arch/arm/boot/dts/exynos4.dtsi | 117 +++++++ arch/arm/boot/dts/exynos4210.dtsi | 23 ++ arch/arm/boot/dts/exynos4x12.dtsi | 82 +++++ arch/arm/mach-exynos/pm_domains.c | 12 +- arch/arm/mm/dma-mapping.c | 16 + drivers/clk/samsung/clk-exynos4.c | 1 + drivers/gpu/drm/exynos/exynos_drm_iommu.c | 3 + drivers/iommu/exynos-iommu.c | 494 ++++++++++++++---------------- include/dt-bindings/clock/exynos4.h | 10 +- 9 files changed, 483 insertions(+), 275 deletions(-) -- 1.9.2

10 years, 7 months

4
23
0 0

[PATCH v2 0/3] CMA & device tree, another approach

by Marek Szyprowski

Hello, This is another approach to finish support for reserved memory regions defined in device tree. Previous attempts (http://lists.linaro.org/pipermail/linaro-mm-sig/2014-February/003738.html and https://lkml.org/lkml/2014/7/14/108) ended in merging parts of the code and documentation. Merged patches allow to reserve memory, but there is still no reserved memory drivers nor any code that actually uses reserved memory regions. The final conclusion from the above mentioned threads is that there is no automated reserved memory initialization. All drivers that want to use reserved memory, should initialize it on their own. This patch series provides two driver for reserved memory regions (one based on CMA and one based on dma_coherent allocator). The main improvement comparing to the previous version is removal of automated reserved memory for every device and support for named memory regions. Those patches are for merging, rebased on top of recent linux-next tree. Best regards Marek Szyprowski Samsung R&D Institute Poland Changes since v1 (https://lkml.org/lkml/2014/8/26/339): - removed patches for named reserved regions - they will be discussed separately - added a check for 'no-map' property to dma coherent allocator (suggested by Laura Abbott) - removed example code for s5p-mfc driver Changes since '[PATCH v2 RESEND 0/4] CMA & device tree, once again' version: (https://lkml.org/lkml/2014/7/14/108) - added return error value to of_reserved_mem_device_init() - added support for named memory regions (so more than one region can be defined per device) - added usage example - converted custom reserved memory code used by s5p-mfc driver to the generic reserved memory handling code Patch summary: Marek Szyprowski (3): drivers: of: add return value to of_reserved_mem_device_init drivers: dma-coherent: add initialization from device tree drivers: dma-contiguous: add initialization from device tree drivers/base/dma-coherent.c | 145 ++++++++++++++++++++++++++++++++++------ drivers/base/dma-contiguous.c | 71 ++++++++++++++++++++ drivers/of/of_reserved_mem.c | 3 +- include/linux/cma.h | 3 + include/linux/of_reserved_mem.h | 9 ++- mm/cma.c | 62 ++++++++++++++--- 6 files changed, 259 insertions(+), 34 deletions(-) -- 1.9.2

10 years, 7 months

3
12
0 0

[PATCH] drm: sti: remove gpio for HDMI hot plug detection

by Benjamin Gaignard

gpio used for HDMI hot plug detection is useless, HDMI_STI register contains an hot plug detection status bit. Fix binding documentation. Signed-off-by: Benjamin Gaignard <benjamin.gaignard(a)linaro.org> --- Documentation/devicetree/bindings/gpu/st,stih4xx.txt | 2 -- drivers/gpu/drm/sti/sti_hdmi.c | 11 ++--------- drivers/gpu/drm/sti/sti_hdmi.h | 5 +++-- 3 files changed, 5 insertions(+), 13 deletions(-) diff --git a/Documentation/devicetree/bindings/gpu/st,stih4xx.txt b/Documentation/devicetree/bindings/gpu/st,stih4xx.txt index 8885d9e..32cfc7b 100644 --- a/Documentation/devicetree/bindings/gpu/st,stih4xx.txt +++ b/Documentation/devicetree/bindings/gpu/st,stih4xx.txt @@ -68,7 +68,6 @@ STMicroelectronics stih4xx platforms number of clocks may depend of the SoC type. - clock-names: names of the clocks listed in clocks property in the same order. - - hdmi,hpd-gpio: gpio id to detect if an hdmi cable is plugged or not. - ddc: phandle of an I2C controller used for DDC EDID probing sti-hda: @@ -174,7 +173,6 @@ Example: interrupt-names = "irq"; clock-names = "pix", "tmds", "phy", "audio"; clocks = <&clockgen_c_vcc CLK_S_PIX_HDMI>, <&clockgen_c_vcc CLK_S_TMDS_HDMI>, <&clockgen_c_vcc CLK_S_HDMI_REJECT_PLL>, <&clockgen_b1 CLK_S_PCM_0>; - hdmi,hpd-gpio = <&PIO2 5>; }; sti-hda@fe85a000 { diff --git a/drivers/gpu/drm/sti/sti_hdmi.c b/drivers/gpu/drm/sti/sti_hdmi.c index 7673189..09f39c5 100644 --- a/drivers/gpu/drm/sti/sti_hdmi.c +++ b/drivers/gpu/drm/sti/sti_hdmi.c @@ -130,8 +130,7 @@ static irqreturn_t hdmi_irq_thread(int irq, void *arg) /* Hot plug/unplug IRQ */ if (hdmi->irq_status & HDMI_INT_HOT_PLUG) { - /* read gpio to get the status */ - hdmi->hpd = gpio_get_value(hdmi->hpd_gpio); + hdmi->hpd = readl(hdmi->regs + HDMI_STA) & HDMI_STA_HOT_PLUG; if (hdmi->drm_dev) drm_helper_hpd_irq_event(hdmi->drm_dev); } @@ -767,13 +766,7 @@ static int sti_hdmi_probe(struct platform_device *pdev) return PTR_ERR(hdmi->clk_audio); } - hdmi->hpd_gpio = of_get_named_gpio(np, "hdmi,hpd-gpio", 0); - if (hdmi->hpd_gpio < 0) { - DRM_ERROR("Failed to get hdmi hpd-gpio\n"); - return -EIO; - } - - hdmi->hpd = gpio_get_value(hdmi->hpd_gpio); + hdmi->hpd = readl(hdmi->regs + HDMI_STA) & HDMI_STA_HOT_PLUG; init_waitqueue_head(&hdmi->wait_event); diff --git a/drivers/gpu/drm/sti/sti_hdmi.h b/drivers/gpu/drm/sti/sti_hdmi.h index d00a3e0..3d22390 100644 --- a/drivers/gpu/drm/sti/sti_hdmi.h +++ b/drivers/gpu/drm/sti/sti_hdmi.h @@ -14,6 +14,9 @@ #define HDMI_STA 0x0010 #define HDMI_STA_DLL_LCK BIT(5) +#define HDMI_STA_HOT_PLUG_SHIFT 4 +#define HDMI_STA_HOT_PLUG (1 << HDMI_STA_HOT_PLUG_SHIFT) + struct sti_hdmi; struct hdmi_phy_ops { @@ -37,7 +40,6 @@ struct hdmi_phy_ops { * @irq_status: interrupt status register * @phy_ops: phy start/stop operations * @enabled: true if hdmi is enabled else false - * @hpd_gpio: hdmi hot plug detect gpio number * @hpd: hot plug detect status * @wait_event: wait event * @event_received: wait event status @@ -57,7 +59,6 @@ struct sti_hdmi { u32 irq_status; struct hdmi_phy_ops *phy_ops; bool enabled; - int hpd_gpio; bool hpd; wait_queue_head_t wait_event; bool event_received; -- 1.9.1

10 years, 8 months

2
2
0 0

[PATCH] drm: sti: allow to change hdmi ddc i2c adapter

by Benjamin Gaignard

Depending of the board configuration i2c for ddc could change, this patch allow to use a phandle to specify which i2c controller to use. Signed-off-by: Benjamin Gaignard <benjamin.gaignard(a)linaro.org> --- .../devicetree/bindings/gpu/st,stih4xx.txt | 1 + drivers/gpu/drm/sti/sti_hdmi.c | 40 +++++++++++++++------- drivers/gpu/drm/sti/sti_hdmi.h | 1 + 3 files changed, 29 insertions(+), 13 deletions(-) diff --git a/Documentation/devicetree/bindings/gpu/st,stih4xx.txt b/Documentation/devicetree/bindings/gpu/st,stih4xx.txt index 2d150c3..8885d9e 100644 --- a/Documentation/devicetree/bindings/gpu/st,stih4xx.txt +++ b/Documentation/devicetree/bindings/gpu/st,stih4xx.txt @@ -69,6 +69,7 @@ STMicroelectronics stih4xx platforms - clock-names: names of the clocks listed in clocks property in the same order. - hdmi,hpd-gpio: gpio id to detect if an hdmi cable is plugged or not. + - ddc: phandle of an I2C controller used for DDC EDID probing sti-hda: Required properties: diff --git a/drivers/gpu/drm/sti/sti_hdmi.c b/drivers/gpu/drm/sti/sti_hdmi.c index ef93156..7673189 100644 --- a/drivers/gpu/drm/sti/sti_hdmi.c +++ b/drivers/gpu/drm/sti/sti_hdmi.c @@ -481,17 +481,15 @@ static const struct drm_bridge_funcs sti_hdmi_bridge_funcs = { static int sti_hdmi_connector_get_modes(struct drm_connector *connector) { - struct i2c_adapter *i2c_adap; + struct sti_hdmi_connector *hdmi_connector + = to_sti_hdmi_connector(connector); + struct sti_hdmi *hdmi = hdmi_connector->hdmi; struct edid *edid; int count; DRM_DEBUG_DRIVER("\n"); - i2c_adap = i2c_get_adapter(1); - if (!i2c_adap) - goto fail; - - edid = drm_get_edid(connector, i2c_adap); + edid = drm_get_edid(connector, hdmi->ddc_adapt); if (!edid) goto fail; @@ -604,29 +602,38 @@ static int sti_hdmi_bind(struct device *dev, struct device *master, void *data) struct sti_hdmi_connector *connector; struct drm_connector *drm_connector; struct drm_bridge *bridge; - struct i2c_adapter *i2c_adap; + struct device_node *ddc; int err; - i2c_adap = i2c_get_adapter(1); - if (!i2c_adap) - return -EPROBE_DEFER; + ddc = of_parse_phandle(dev->of_node, "ddc", 0); + if (ddc) { + hdmi->ddc_adapt = of_find_i2c_adapter_by_node(ddc); + if (!hdmi->ddc_adapt) { + err = -EPROBE_DEFER; + of_node_put(ddc); + return err; + } + + of_node_put(ddc); + } /* Set the drm device handle */ hdmi->drm_dev = drm_dev; encoder = sti_hdmi_find_encoder(drm_dev); if (!encoder) - return -ENOMEM; + goto err_adapt; connector = devm_kzalloc(dev, sizeof(*connector), GFP_KERNEL); if (!connector) - return -ENOMEM; + goto err_adapt; + connector->hdmi = hdmi; bridge = devm_kzalloc(dev, sizeof(*bridge), GFP_KERNEL); if (!bridge) - return -ENOMEM; + goto err_adapt; bridge->driver_private = hdmi; drm_bridge_init(drm_dev, bridge, &sti_hdmi_bridge_funcs); @@ -663,6 +670,8 @@ err_sysfs: err_connector: drm_bridge_cleanup(bridge); drm_connector_cleanup(drm_connector); +err_adapt: + put_device(&hdmi->ddc_adapt->dev); return -EINVAL; } @@ -789,6 +798,11 @@ static int sti_hdmi_probe(struct platform_device *pdev) static int sti_hdmi_remove(struct platform_device *pdev) { + struct sti_hdmi *hdmi = dev_get_drvdata(&pdev->dev); + + if (hdmi->ddc_adapt) + put_device(&hdmi->ddc_adapt->dev); + component_del(&pdev->dev, &sti_hdmi_ops); return 0; } diff --git a/drivers/gpu/drm/sti/sti_hdmi.h b/drivers/gpu/drm/sti/sti_hdmi.h index 61bec65..d00a3e0 100644 --- a/drivers/gpu/drm/sti/sti_hdmi.h +++ b/drivers/gpu/drm/sti/sti_hdmi.h @@ -62,6 +62,7 @@ struct sti_hdmi { wait_queue_head_t wait_event; bool event_received; struct reset_control *reset; + struct i2c_adapter *ddc_adapt; }; u32 hdmi_read(struct sti_hdmi *hdmi, int offset); -- 1.9.1

10 years, 8 months

1
0
0 0

[PATCH] drm: sti: use drm_crtc_vblank_{on/off} instead of drm_vblank_{on/off}

by Benjamin Gaignard

Make sure that vblank is enabled when crtc commit is call. Replace drm_vblank_off() by drm_crtc_vblank_off() Signed-off-by: Benjamin Gaignard <benjamin.gaignard(a)linaro.org> --- drivers/gpu/drm/sti/sti_drm_crtc.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/sti/sti_drm_crtc.c b/drivers/gpu/drm/sti/sti_drm_crtc.c index d2ae0c0..38c4799 100644 --- a/drivers/gpu/drm/sti/sti_drm_crtc.c +++ b/drivers/gpu/drm/sti/sti_drm_crtc.c @@ -61,6 +61,8 @@ static void sti_drm_crtc_commit(struct drm_crtc *crtc) /* Enable layer on mixer */ if (sti_mixer_set_layer_status(mixer, layer, true)) DRM_ERROR("Can not enable layer at mixer\n"); + + drm_crtc_vblank_on(crtc); } static bool sti_drm_crtc_mode_fixup(struct drm_crtc *crtc, @@ -221,7 +223,7 @@ static void sti_drm_crtc_disable(struct drm_crtc *crtc) /* Then disable layer itself */ sti_layer_disable(layer); - drm_vblank_off(crtc->dev, mixer->id); + drm_crtc_vblank_off(crtc); /* Disable pixel clock and compo IP clocks */ if (mixer->id == STI_MIXER_MAIN) { -- 1.9.1

10 years, 8 months

1
0
0 0

Ideal Android device to do Audio Multimedia Android stuff

by Viswanath Puttagunta

Hi All, I lost the only Android Tablet that I had to hack around and in the market for new Android Tablet. Needs to be stuff I can buy personally, so Juno / Vexpress is out the window. What would you recommend I buy? Below are specific use cases i. Work on NEON optimizations for Audio libraries (Vorbis, FLAC etc) in **Android** context. ii. So, would obviously like to have a reference Android baseline build that is actively used in Linaro. Is anyone in LMG using builds available for Nexus10 <http://releases.linaro.org/14.09/android/nexus10> and Nexus7 <http://releases.linaro.org/14.09/android/nexus7-2013> actively right now? How official are these builds? Regards, Vish (Viswanath Puttagunta) Cell: 972-342-0205 Technical Program Manager Member Services, Linaro

10 years, 8 months

1
0
0 0

Install Ubuntu on Samsung Chromebook 2

by Viswanath Puttagunta

Hi All, Does any one have instructions to install Ubuntu natively on Samsung Chromebook2 that worked for you? Regards, Vish (Viswanath Puttagunta) Cell: 972-342-0205 Technical Program Manager Member Services, Linaro

10 years, 8 months

1
0
0 0

Changing PAGE_ALLOC_COSTLY_ORDER from 3 to 2

by Pintu Kumar

Hi, I wanted to know about the impact of changing PAGE_ALLOC_COSTLY_ORDER value from 3 to 2. This macro is defined in include/linux/mmzone.h #define PAGE_ALLOC_COSTLY_ORDER 3 As I know this value should never be changed irrespective of the type of the system. Is it good to change this value for RAM size: 512MB, 256MB or 128MB? If anybody have changed this value and experience any kind of problem or benefits please let us know. We noticed that for one of the Android product with 512MB RAM, the PAGE_ALLOC_COSTLY_ORDER was set to 2. We could not figure out why this value was decreased from 3 to 2. As per my analysis, I observed that kmalloc fails little early, if we change this value to 2. This is also visible from the _slowpath_ in page_alloc.c Apart from this we could not find any other impact. If anybody is aware of any other impact, please let us know. Thank you! Regards, Pintu Kumar

10 years, 8 months

1
0
0 0

Re: [Linaro-mm-sig] Question on UAPI for fences

by Daniel Vetter

On Sun, Sep 14, 2014 at 12:36:43PM +0200, Christian König wrote: > Yeah, right. Providing the fd to reassign to a fence would indeed reduce the > create/close overhead. > > But it would still be more overhead than for example a simple on demand > growing ring buffer which then uses 64bit sequence numbers in userspace to > refer to a fence in the kernel. > > Apart from that I'm pretty sure that when we do the syncing completely in > userspace we need more fences open at the same time than fds are available > by default. If you do the syncing completely in userspace you don't need kernel fences at all. Kernel fences are only required if you sync with a different process (where the pure userspace syncing might not work out) or with different devices. tbh I don't see any use-case at all where you'd need 10k such fences. That means your driver gets to deal with 2 kinds of fences, but so be it. Since not using fds for cross-device or cross-process syncing imo just doesn't make sense, so that one pretty much will have to stick. > As long as our internal handle or sequence based fence are easily > convertible to a fence fd I actually don't really see a problem with that. > Going to hack that approach into my prototype and then we can see how bad > the code looks after all. My plan for i915 is to start out with fd fences only, and once we have some clarity on the exact requirements probably add some pure userspace-controlled fences for tightly coupled stuff. Those might be fully internal to the opencl userspace driver though and never get out of there, ever. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch

10 years, 8 months

1
0
0 0

Re: [Linaro-mm-sig] Question on UAPI for fences

by Jesse Barnes

On Fri, 12 Sep 2014 18:08:23 +0200 Christian König <christian.koenig(a)amd.com> wrote: > > As Daniel said using fd is most likely the way we want to do it but this > > remains vague. > Separating the discussion if it should be an fd or not. Using an fd > sounds fine to me in general, but I have some concerns as well. > > For example what was the maximum number of opened FDs per process again? > Could that become a problem? etc... You can check out the i915 patches I posted if you want to see examples. Max fds may be an issue if userspace doesn't clean up its fences. The implementation is pretty easy with the stuff Maarten has done recently. The changes I still need to make to mine: - sit on top of Chris's request/seqno changes (driver internals really) - switch over to execbuf as the main API on the render side (like you're doing) - add support for display and other timelines As far as compat goes, I don't think it should be too hard. Even with GPU scheduling, a given context's buffers should all be in-order with respect to one another, so we ought to be able to mix & match clients using explicit fencing and implicit fencing. Though in Mesa I still haven't looked at how to handle server vs client side arb_sync with the scheduler and explicit fencing in place; might need some extra work there... -- Jesse Barnes, Intel Open Source Technology Center

10 years, 8 months

1
0
0 0

Re: [Linaro-mm-sig] Question on UAPI for fences

by Jerome Glisse

On Fri, Sep 12, 2014 at 05:58:09PM +0200, Christian König wrote: > Am 12.09.2014 um 17:48 schrieb Jerome Glisse: > >On Fri, Sep 12, 2014 at 05:42:57PM +0200, Christian König wrote: > >>Am 12.09.2014 um 17:33 schrieb Jerome Glisse: > >>>On Fri, Sep 12, 2014 at 11:25:12AM -0400, Alex Deucher wrote: > >>>>On Fri, Sep 12, 2014 at 10:50 AM, Jerome Glisse <j.glisse(a)gmail.com> wrote: > >>>>>On Fri, Sep 12, 2014 at 04:43:44PM +0200, Daniel Vetter wrote: > >>>>>>On Fri, Sep 12, 2014 at 4:09 PM, Daniel Vetter <daniel(a)ffwll.ch> wrote: > >>>>>>>On Fri, Sep 12, 2014 at 03:23:22PM +0200, Christian König wrote: > >>>>>>>>Hello everyone, > >>>>>>>> > >>>>>>>>to allow concurrent buffer access by different engines beyond the multiple > >>>>>>>>readers/single writer model that we currently use in radeon and other > >>>>>>>>drivers we need some kind of synchonization object exposed to userspace. > >>>>>>>> > >>>>>>>>My initial patch set for this used (or rather abused) zero sized GEM buffers > >>>>>>>>as fence handles. This is obviously isn't the best way of doing this (to > >>>>>>>>much overhead, rather ugly etc...), Jerome commented on this accordingly. > >>>>>>>> > >>>>>>>>So what should a driver expose instead? Android sync points? Something else? > >>>>>>>I think actually exposing the struct fence objects as a fd, using android > >>>>>>>syncpts (or at least something compatible to it) is the way to go. Problem > >>>>>>>is that it's super-hard to get the android guys out of hiding for this :( > >>>>>>> > >>>>>>>Adding a bunch of people in the hopes that something sticks. > >>>>>>More people. > >>>>>Just to re-iterate, exposing such thing while still using command stream > >>>>>ioctl that use implicit synchronization is a waste and you can only get > >>>>>the lowest common denominator which is implicit synchronization. So i do > >>>>>not see the point of such api if you are not also adding a new cs ioctl > >>>>>with explicit contract that it does not do any kind of synchronization > >>>>>(it could be almost the exact same code modulo the do not wait for > >>>>>previous cmd to complete). > >>>>Our thinking was to allow explicit sync from a single process, but > >>>>implicitly sync between processes. > >>>This is a BIG NAK if you are using the same ioctl as it would mean you are > >>>changing userspace API, well at least userspace expectation. Adding a new > >>>cs flag might do the trick but it should not be about inter-process, or any > >>>thing special, it's just implicit sync or no synchronization. Converting > >>>userspace is not that much of a big deal either, it can be broken into > >>>several step. Like mesa use explicit synchronization all time but ddx use > >>>implicit. > >>The thinking here is that we need to be backward compatible for DRI2/3 and > >>support all kind of different use cases like old DDX and new Mesa, or old > >>Mesa and new DDX etc... > >> > >>So for my prototype if the kernel sees any access of a BO from two different > >>clients it falls back to the old behavior of implicit synchronization of > >>access to the same buffer object. That might not be the fastest approach, > >>but is as far as I can see conservative and so should work under all > >>conditions. > >> > >>Apart from that the planning so far was that we just hide this feature > >>behind a couple of command submission flags and new chunks. > >Just to reproduce IRC discussion, i think it's a lot simpler and not that > >complex. For explicit cs ioctl you do not wait for any previous fence of > >any of the buffer referenced in the cs ioctl, but you still associate a > >new fence with all the buffer object referenced in the cs ioctl. So if the > >next ioctl is an implicit sync ioctl it will wait properly and synchronize > >properly with previous explicit cs ioctl. Hence you can easily have a mix > >in userspace thing is you only get benefit once enough of your userspace > >is using explicit. > > Yes, that's exactly what my patches currently implement. > > The only difference is that by current planning I implemented it as a per BO > flag for the command submission, but that was just for testing. Having a > single flag to switch between implicit and explicit synchronization for > whole CS IOCTL would do equally well. Doing it per BO sounds bogus to me. But otherwise yes we are in agreement. As Daniel said using fd is most likely the way we want to do it but this remains vague. > > >Note that you still need a way to have explicit cs ioctl to wait on a > >previos "explicit" fence so you need some api to expose fence per cs > >submission. > > Exactly, that's what this mail thread is all about. > > As Daniel correctly noted you need something like a functionality to get a > fence as the result of a command submission as well as pass in a list of > fences to wait for before beginning a command submission. > > At least it looks like we are all on the same general line here, its just > nobody has a good idea how the details should look like. > > Regards, > Christian. > > > > >Cheers, > >Jérôme > > > >>Regards, > >>Christian. > >> > >>>Cheers, > >>>Jérôme > >>> > >>>>Alex > >>>> > >>>>>Also one thing that the Android sync point does not have, AFAICT, is a > >>>>>way to schedule synchronization as part of a cs ioctl so cpu never have > >>>>>to be involve for cmd stream that deal only one gpu (assuming the driver > >>>>>and hw can do such trick). > >>>>> > >>>>>Cheers, > >>>>>Jérôme > >>>>> > >>>>>>-Daniel > >>>>>>-- > >>>>>>Daniel Vetter > >>>>>>Software Engineer, Intel Corporation > >>>>>>+41 (0) 79 365 57 48 - http://blog.ffwll.ch > >>>>>_______________________________________________ > >>>>>dri-devel mailing list > >>>>>dri-devel(a)lists.freedesktop.org > >>>>>http://lists.freedesktop.org/mailman/listinfo/dri-devel >

10 years, 8 months

1
0
0 0

Re: [Linaro-mm-sig] Question on UAPI for fences

by Jerome Glisse

On Fri, Sep 12, 2014 at 05:42:57PM +0200, Christian König wrote: > Am 12.09.2014 um 17:33 schrieb Jerome Glisse: > >On Fri, Sep 12, 2014 at 11:25:12AM -0400, Alex Deucher wrote: > >>On Fri, Sep 12, 2014 at 10:50 AM, Jerome Glisse <j.glisse(a)gmail.com> wrote: > >>>On Fri, Sep 12, 2014 at 04:43:44PM +0200, Daniel Vetter wrote: > >>>>On Fri, Sep 12, 2014 at 4:09 PM, Daniel Vetter <daniel(a)ffwll.ch> wrote: > >>>>>On Fri, Sep 12, 2014 at 03:23:22PM +0200, Christian König wrote: > >>>>>>Hello everyone, > >>>>>> > >>>>>>to allow concurrent buffer access by different engines beyond the multiple > >>>>>>readers/single writer model that we currently use in radeon and other > >>>>>>drivers we need some kind of synchonization object exposed to userspace. > >>>>>> > >>>>>>My initial patch set for this used (or rather abused) zero sized GEM buffers > >>>>>>as fence handles. This is obviously isn't the best way of doing this (to > >>>>>>much overhead, rather ugly etc...), Jerome commented on this accordingly. > >>>>>> > >>>>>>So what should a driver expose instead? Android sync points? Something else? > >>>>>I think actually exposing the struct fence objects as a fd, using android > >>>>>syncpts (or at least something compatible to it) is the way to go. Problem > >>>>>is that it's super-hard to get the android guys out of hiding for this :( > >>>>> > >>>>>Adding a bunch of people in the hopes that something sticks. > >>>>More people. > >>>Just to re-iterate, exposing such thing while still using command stream > >>>ioctl that use implicit synchronization is a waste and you can only get > >>>the lowest common denominator which is implicit synchronization. So i do > >>>not see the point of such api if you are not also adding a new cs ioctl > >>>with explicit contract that it does not do any kind of synchronization > >>>(it could be almost the exact same code modulo the do not wait for > >>>previous cmd to complete). > >>Our thinking was to allow explicit sync from a single process, but > >>implicitly sync between processes. > >This is a BIG NAK if you are using the same ioctl as it would mean you are > >changing userspace API, well at least userspace expectation. Adding a new > >cs flag might do the trick but it should not be about inter-process, or any > >thing special, it's just implicit sync or no synchronization. Converting > >userspace is not that much of a big deal either, it can be broken into > >several step. Like mesa use explicit synchronization all time but ddx use > >implicit. > > The thinking here is that we need to be backward compatible for DRI2/3 and > support all kind of different use cases like old DDX and new Mesa, or old > Mesa and new DDX etc... > > So for my prototype if the kernel sees any access of a BO from two different > clients it falls back to the old behavior of implicit synchronization of > access to the same buffer object. That might not be the fastest approach, > but is as far as I can see conservative and so should work under all > conditions. > > Apart from that the planning so far was that we just hide this feature > behind a couple of command submission flags and new chunks. Just to reproduce IRC discussion, i think it's a lot simpler and not that complex. For explicit cs ioctl you do not wait for any previous fence of any of the buffer referenced in the cs ioctl, but you still associate a new fence with all the buffer object referenced in the cs ioctl. So if the next ioctl is an implicit sync ioctl it will wait properly and synchronize properly with previous explicit cs ioctl. Hence you can easily have a mix in userspace thing is you only get benefit once enough of your userspace is using explicit. Note that you still need a way to have explicit cs ioctl to wait on a previos "explicit" fence so you need some api to expose fence per cs submission. Cheers, Jérôme > > Regards, > Christian. > > > > >Cheers, > >Jérôme > > > >>Alex > >> > >>>Also one thing that the Android sync point does not have, AFAICT, is a > >>>way to schedule synchronization as part of a cs ioctl so cpu never have > >>>to be involve for cmd stream that deal only one gpu (assuming the driver > >>>and hw can do such trick). > >>> > >>>Cheers, > >>>Jérôme > >>> > >>>>-Daniel > >>>>-- > >>>>Daniel Vetter > >>>>Software Engineer, Intel Corporation > >>>>+41 (0) 79 365 57 48 - http://blog.ffwll.ch > >>>_______________________________________________ > >>>dri-devel mailing list > >>>dri-devel(a)lists.freedesktop.org > >>>http://lists.freedesktop.org/mailman/listinfo/dri-devel >

10 years, 8 months

1
0
0 0

Re: [Linaro-mm-sig] Question on UAPI for fences

by Daniel Vetter

On Fri, Sep 12, 2014 at 03:23:22PM +0200, Christian König wrote: > Hello everyone, > > to allow concurrent buffer access by different engines beyond the multiple > readers/single writer model that we currently use in radeon and other > drivers we need some kind of synchonization object exposed to userspace. > > My initial patch set for this used (or rather abused) zero sized GEM buffers > as fence handles. This is obviously isn't the best way of doing this (to > much overhead, rather ugly etc...), Jerome commented on this accordingly. > > So what should a driver expose instead? Android sync points? Something else? I think actually exposing the struct fence objects as a fd, using android syncpts (or at least something compatible to it) is the way to go. Problem is that it's super-hard to get the android guys out of hiding for this :( Adding a bunch of people in the hopes that something sticks. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch

10 years, 8 months

3
6
0 0

[PATCH] drm: sti: do not iterate over the info frame array

by Benjamin Gaignard

avi infoframe is a 13 bytes array, do not read after this limite. Signed-off-by: Benjamin Gaignard <benjamin.gaignard(a)linaro.org> --- drivers/gpu/drm/sti/sti_hdmi.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/sti/sti_hdmi.c b/drivers/gpu/drm/sti/sti_hdmi.c index 284e541..90ee20a 100644 --- a/drivers/gpu/drm/sti/sti_hdmi.c +++ b/drivers/gpu/drm/sti/sti_hdmi.c @@ -298,7 +298,6 @@ static int hdmi_avi_infoframe_config(struct sti_hdmi *hdmi) hdmi_write(hdmi, val, HDMI_SW_DI_N_PKT_WORD2(HDMI_IFRAME_SLOT_AVI)); val = frame[0xC]; - val |= frame[0xD] << 8; hdmi_write(hdmi, val, HDMI_SW_DI_N_PKT_WORD3(HDMI_IFRAME_SLOT_AVI)); /* Enable transmission slot for AVI infoframe -- 1.9.1

10 years, 9 months

1
0
0 0

[PATCH 00/29] Exynos SYSMMU (IOMMU) integration with DT and DMA-mapping subsystem

by Marek Szyprowski

Hello Everyone, A lot of things has happened in the area of improving Exynos IOMMU driver and discussion about generic IOMMU bindings, which finally motivated me to get back to IOMMU related tasks. Just to remind, here are those 2 important threads: 1. [PATCH v13 00/19] iommu/exynos: Fixes and Enhancements of System MMU driver with DT: https://lkml.org/lkml/2014/5/12/34 2. [PATCH v4] devicetree: Add generic IOMMU device tree bindings: https://lkml.org/lkml/2014/7/4/349 As a follow up of those discussions I've decided to finish our internal code, which adapts Exynos SYSMMU driver to meet generic IOMMU bindings requirements and implement all needed glue code to finally demonstare seemless integration IOMMU controller with DMA-mapping subsystem for the drivers available on Exynos SoCs. 1. Introduction - a few words for those who are not fully aware of the Exynos SoC hardware Exynos SoC consists of various devices integrated directly into SoCs. Most of them are multimedia devices, which usually process large buffers. Some of them (like i.e. MFC - a multimedia codec or FIMD - a multi-window framebuffer device & lcd panel controller) are equipped with more than one memory interface for higher processing performance. There are also really complex subsystems (like ISP, the camera sensor interface & processor), which consist of many sub-blocks, each having its own memory interface/channel/bus (different names are used for the same thing). Each such memory controller might be equipped with SYSMMU device, which acts as IOMMU controller for the parent device (called master device, a device which that memory interface belongs to). Each SYSMMU controller has its own register set and clock, belongs to the same power domain as master device. There is also some non-direct relation from master's device gate clock - SYSMMU registers can be accessed only when master's gate clock is enabled. Basically we have following dependencies between hardware and drivers: - each multimedia device might have 1 or more SYSMMU controller - each SYSMMU controller belongs only to 1 master device - all SYSMMU controllers are independent of each other, there is no global hardware ID that must be assigned to enable given SYSMMU controller - multimedia devices are modeled usually by a separate node in device tree with it's own compatible string and separate driver for them - sub-blocks of complex devices right now are not modeled by a separate device tree nodes, but this might be changed in the future - some multimedia devices have limited address space per each memory controller/channel (i.e. codec might access buffers only in a 256MiB window for each of it's memory channels) - some drivers for independent device are used together to provide a more complex subsystem, i.e. FIMD, HDMI-mixer and others form together Exynos DRM subsystem; it is highly welcome to let them to operate in the same, shared DMA address space to simplify buffer sharing 2. Introduction part 2 - a few word of summary of the discussions about generic IOMMU DT bindings There have been a lot of discussions on the method of modeling IOMMU controllers in device tree. The approach which has been selected as the generic IOMMU binding candidate has been described in the '[PATCH v4] devicetree: Add generic IOMMU device tree bindings' thread. Those bindings describe how to link an IOMMU controller with its master device. Basically an 'iommus' property placed in the master's device node has been introduced. This property contains phandle to IOMMU controller node. Optional properties of the particular binding can also be specified after the phandle, assuming that IOMMU controller node contains '#iommu-cells' property, which defines number of cells used for those parameters. Those parameters are then interpreted by particular IOMMU controller driver. Those parameters might be some hw channel id required for correct hardware setup, base address and size pair for limited IO address space window or others hardware dependant properties. 3. IOMMU integration to DMA-mapping subsystem By default we assume that each master device, which has been equipped with IOMMU controller gets its own DMA (IO) address space. This is created automatically and transparently without any changes in the device driver code. All DMA-mapping functions are replaced with the IOMMU aware versions. This has to be done somewhere by the architecture or SoC startup code, so when master's driver probe() function is called, everything is in place. However some device drivers might need (for various reasons) to manually manage DMA (IO) address space. For this case a driver need to notify kernel about that and do the management of DMA address space on its own. This has been achieved by introducing DRIVER_HAS_OWN_IOMMU_MANAGER flag, which can be set in struct device_driver. This way the startup code can easily determine if creating the default per-device separate DMA address space is required for a given driver or not without any unneeded alloc/free call sequences. 4. Linux DMA-mapping subsystem and more than one DMA address space DMA-mapping subsystem assumes that there is only one DMA (IO) address space associated with the given struct device entity. Usually struct device is mapped in one-to-one relation to a node describing given device in device tree. To let driver to access other DMA (IO) address spaces a sub-device has been introduced. This approach has been already used by s5p-mfc driver (drivers/media/platform/s5p-mfc/s5p_mfc.c). The only question is how and when sub-devices are created. In the proposed approach, such additional address spaces are named with the names of the respective IOMMU controllers (iommu-names property in master's DT node). To let driver to access an address space, a sub-device named 'parent_device_name:address_space_name' need to be created and added as a child to master's struct device. A good example is codec device, which on Exynos4412 SoC is instantiated as '13400000.codec' device. It has 2 memory interfaces ('left' and 'right'), so the sub-devices called '13400000.codec:left' and '13400000.codec:right' must be created by a driver and added as children of '13400000.codec' device. Once then the driver is allowed to allocate 2 separate dma-mapping address spaces by calling arm_iommu_create_mapping() and arm_iommu_detach_device() functions or newly introduced helper arm_iommu_create_default_mapping(). For more details, please refer to the last patch in this series. Exactly the same approach is planned to be done for memory regions and DMA-mapping implemented on top of CMA or DMA-coherent memory allocators. When driver doesn't specify that it wants to manage its DMA (IO) address spaces, a default DMA (IO) address space will be created and all SYSMMU controllers will be bound to it, so this space will be shared across master's device IO channels / memory interfaces. This way IOMMU support might be added only to drivers which really benefit from having separate IO address space per memory interface without a need to alter the other drivers. Why driver might need to manage the IO address space on its own? Once again the codec device on Exynos4 series is a good example. Memory interfaces found in the mentioned codec device are limited and can address only 256MiB window. If we bind both interfaces to common address space, driver is able only to access memory buffers, which fits into 256MiB window. If we use separate spaces for each memory interface, codec device will be able to access buffers of total 2*256MiB=512MiB, which is a significant advantage over the default case of shared address space. 5. Power management (runtime) Runtime power management is the most tricky part of the proposed solution. I assumed that it is a sane requirement that from the master's device driver the operation without IOMMU and with IOMMU (with default, per-device mapping) should be exactly the same. The runtime power management, which is now mainly limited to enabling and disabling hardware power domains is done by the master's device driver. However from the hardware perspective, there is also a need to save SYSMMU context before switch pm domain off and restore it after switching pm domain on. To achieve this way of SYSMMU operation, a notifiers for power domains have been introduces. With such an approach no changes are needed in master's device driver and SYSMMU driver seamlessly integrates with master's device runtime pm operations. 6. Proposed patches and changes Patch 0001 "pm: Add PM domain notifications" adds support for power domain notifiers (see chapter 5 above). Patch 0002 "ARM: Exynos: bind power domains earlier, on device creation" changes the time, when Exynos power domains are bound to the device. Now this happens on DEVICE_ADD event instead of DRIVER_BIND, so when SYSMMU driver is being initialized, the power domains are already bound and notifiers can be added. Patch 0003 "clk: exynos: add missing smmu_g2d clock and update comments" simply simply adds missing sysmmu related entities to Exynos clock driver. Patch 0004 "drivers: base: add notifier for failed driver bind" add event for failed driver bind, so things prepared in DRIVER_BIND event can be cleaned up, similar to DRIVER_UNBOUND. Patch 0005 "drivers: convert suppress_bind_attrs parameter into flags" is preparation for adding new flags to struct device_driver. Patch 0006 "drivers: iommu: add notify about failed bind" adds support for recently introduced failed driver bind event to IOMMU subsystem. Patch 0007 "ARM: dma-mapping: arm_iommu_attach_device: automatically set max_seg_size" moves common operation of setting dma max_seg_size directly to arm_iommu_attach_device function. Patch 0008 "ARM: dma-mapping: add helpers for managing default per-device dma mappings" adds convenient helpers for the most common case of setting up per-device, separate DMA (IO) address space. Patch 0009 "ARM: dma-mapping: provide stubs if no ARM_DMA_USE_IOMMU has been selected" fixes usage of IOMMU related ARM DMA-mapping functions in common code. Patch 0010 "drivers: add DRIVER_HAS_OWN_IOMMU_MANAGER flag" adds a flag described in chapter 3. Patch 0011 "DRM: exynos: add DRIVER_HAS_OWN_IOMMU_MANAGER flag to all sub-drivers" marks all Exynos DRM sub-drivers with a flag notifying that they perform own management of DMA (IO) address space. All the code to setup dma-mapping and attach all devices is realy there. Patch 0012 "DRM: Exynos: fix window clear code" is a simple bugfix of broken init code, which triggers issues when used with IOMMU (page fault happens on systems, where bootloader has left framebuffer enabled). Patch 0013 "temporary: media: s5p-mfc: remove DT hacks & initialization custom memory init code" removes all custom memory region handling, to let later demonstrate how to use separate DMA (IO) address spaces from master's device driver. Patch 0014 "devicetree: Update Exynos SYSMMU device tree bindings" adds a few words about proposed solution to SYSMMU device tree bindings documentation. Patch 0015 "ARM: DTS: Exynos4: add System MMU nodes" adds device tree nodes for all SYSMMU controllers found in Exynos 4210 and 4x12 SoC and respective properties to their master devices. Patch 0016-0021 are simple bugfixes and code refactoring to simplify the driver: "iommu: exynos: make driver multiarch friendly", "iommu: exynos: don't read version register on every tlb", "iommu: exynos: remove unused functions", "iommu: exynos: remove useless spinlock", "iommu: exynos: refactor function parameters to simplify code", "iommu: exynos: remove unused functions, part 2". Patch 0022 "iommu: exynos: add support for binding more than one sysmmu to master device" adds support for storing a list of SYSMMU controllers in the master's iommu arch data structure. Patch 0023 "iommu: exynos: init iommu controllers from device tree" finally implements bindings described in patch 0015 and access to particular DMA address space managed by SYSMMU controller via sub-device of predefined name (see chapter 4). Patch 0024 "iommu: exynos: create default iommu-based dma-mapping for master devices" does what patch title says. Patch 0025 "iommu: exynos: add support for runtime_pm" implements power management scheme described in chapter 5. Patch 0026-0028 are cleanup and refactoring to make the code easier to understand: "iommu: exynos: rename variables to reflect their purpose", "iommu: exynos: document internal structures", "iommu: exynos: remove excessive includes and sort others alphabetically". Patch 0029 "temporary: media: s5p-mfc: add support for IOMMU" demonstrates how to use sub-devices to get access to separate DMA (IO) address spaces. The driver is able to work both with and without this patch. Without this patch a common shared address space is created for both SYSMMU controllers (so only 256MiB of total address space is available, see end of chapter 4). 7. Summary All the development of those patches have been done on Exynos4412-based OdroidU3 board and Exynos4210-based UniversalC210, on top of v3.16 kernel with some additional patches to enable HDMI support on Odroid board. This version is available in the following GIT repository: http://git.linaro.org/git/people/marek.szyprowski/linux-dma-mapping.git on branch v3.16-odroid-iommu. However, the version posted here has been rebased on top of linux-next kernel (next-20140804 tag), to make marging the easier once v3.17-rc1 is out. 8. Diffstat .../devicetree/bindings/iommu/samsung,sysmmu.txt | 93 ++- Documentation/power/notifiers.txt | 14 + arch/arm/boot/dts/exynos4.dtsi | 118 ++++ arch/arm/boot/dts/exynos4210.dtsi | 23 + arch/arm/boot/dts/exynos4x12.dtsi | 82 +++ arch/arm/include/asm/dma-iommu.h | 36 ++ arch/arm/mach-exynos/pm_domains.c | 12 +- arch/arm/mach-integrator/impd1.c | 2 +- arch/arm/mm/dma-mapping.c | 47 ++ drivers/base/bus.c | 4 +- drivers/base/dd.c | 10 +- drivers/base/platform.c | 2 +- drivers/base/power/domain.c | 70 ++- drivers/clk/samsung/clk-exynos4.c | 1 + drivers/gpu/drm/exynos/exynos_drm_fimc.c | 1 + drivers/gpu/drm/exynos/exynos_drm_fimd.c | 26 +- drivers/gpu/drm/exynos/exynos_drm_g2d.c | 1 + drivers/gpu/drm/exynos/exynos_drm_gsc.c | 1 + drivers/gpu/drm/exynos/exynos_drm_rotator.c | 1 + drivers/gpu/drm/exynos/exynos_mixer.c | 1 + drivers/iommu/exynos-iommu.c | 663 +++++++++++++-------- drivers/iommu/iommu.c | 3 + drivers/media/platform/s5p-mfc/s5p_mfc.c | 107 ++-- drivers/pci/host/pci-mvebu.c | 2 +- drivers/pci/host/pci-rcar-gen2.c | 2 +- drivers/pci/host/pci-tegra.c | 2 +- drivers/pci/host/pcie-rcar.c | 2 +- drivers/soc/tegra/pmc.c | 2 +- include/dt-bindings/clock/exynos4.h | 10 +- include/linux/device.h | 12 +- include/linux/iommu.h | 1 + include/linux/pm.h | 2 + include/linux/pm_domain.h | 19 + 33 files changed, 1016 insertions(+), 356 deletions(-) Best regards Marek Szyprowski Samsung R&D Institute Poland

10 years, 9 months

9
49
0 0

[PATCH] android: fix reference leak in sync_fence_create

by Maarten Lankhorst

According to the documentation sync_fence_create takes ownership of the point, not a reference on the point. This fixes a memory leak introduced in 3.17's android fence rework. Signed-off-by: Maarten Lankhorst <maarten.lankhorst(a)canonical.com> Cc: Colin Cross <ccross(a)google.com> Cc: Dan Carpenter <dan.carpenter(a)oracle.com> --- drivers/staging/android/sync.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c index e7b2e0234196..69139ce7420d 100644 --- a/drivers/staging/android/sync.c +++ b/drivers/staging/android/sync.c @@ -199,7 +199,6 @@ struct sync_fence *sync_fence_create(const char *name, struct sync_pt *pt) fence->num_fences = 1; atomic_set(&fence->status, 1); - fence_get(&pt->base); fence->cbs[0].sync_pt = &pt->base; fence->cbs[0].fence = fence; if (fence_add_callback(&pt->base, &fence->cbs[0].cb, -- 2.0.4

10 years, 9 months

1
0
0 0

[PATCH 1/2] android: fix reference leak in sync_fence_create

by Maarten Lankhorst

According to the documentation sync_fence_create takes ownership of the point, not a reference on the point. Signed-off-by: Maarten Lankhorst <maarten.lankhorst(a)canonical.com> Cc: Colin Cross <ccross(a)google.com> --- drivers/staging/android/sync.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c index e7b2e0234196..69139ce7420d 100644 --- a/drivers/staging/android/sync.c +++ b/drivers/staging/android/sync.c @@ -199,7 +199,6 @@ struct sync_fence *sync_fence_create(const char *name, struct sync_pt *pt) fence->num_fences = 1; atomic_set(&fence->status, 1); - fence_get(&pt->base); fence->cbs[0].sync_pt = &pt->base; fence->cbs[0].fence = fence; if (fence_add_callback(&pt->base, &fence->cbs[0].cb, -- 2.0.4

10 years, 9 months

4
10
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig