Re: [Patch 2/4] dt-bindings: display/ti: Add plane binding to dispc node
On 19/04/18 09:34, Daniel Vetter wrote: >> But the kernel cannot know what the user wants to do, so it cannot >> configure the planes. If we have an HDMI output which supports 2k+ and a >> -2k LCD, and 4 hw planes, we can set up the planes at least in the >> following ways: >> >> - One virtual plane on HDMI, two normal planes on LCD. Here the normal >> planes can also be used on the HDMI, as long as the input width is -2k. >> >> - One virtual plane on HDMI, one virtual plane on LCD, but sometimes >> both planes on the same display (either HDMI or LCD). >> >> - No virtual planes (and fbdev support disabled). This needs the >> userspace to take care not to configure 2k+ planes. But considering that >> the modes supported are still quit close to 2k in width, I believe >> upscaling a 2k plane cover the whole display would provide quite ok image. >> >> Each of those requires a different virtual plane setup. > > Why do you want to hardcode this in DT? The recommended approach is to > have a bunch of virtual planes, and runtime assign whatever hw resources > you need to get there. If you run out of hw planes you just fail with > -EINVAL in atomic_check. That is possible, but how many userspace apps will work correctly if the planes work or don't work in a random manner (from userspace's point of view)? I like the idea more that the DRM driver exposes a lesser number of planes which always work, instead of exposing larger number of planes which sometimes do not work. And with userspace apps, I don't mainly mean Weston and X, but instead the numerous custom applications the customers write themselves. Perhaps I'm worrying too much, but I can imagine a flood of support requests about why plane setup is not working when one does this or that simple setup. Also one complication with runtime assignment is that the hw planes are not identical: some support YUV modes, some don't, some support scaling, some don't. That's probably not a show stopper, but it does limit the options as e.g. we can't have all virtual planes advertising YUV support when we have a hw plane that doesn't support YUV. Tomi -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[[RFC]DPU PATCH 3/4] drm/panel: add Innolux TV123WAM eDP panel driver
Add support for Innolux TV123WAM 12.3" panel which
is an eDP panel.
Signed-off-by: Sandeep Panda
---
drivers/gpu/drm/panel/panel-innolux-tv123wam.c | 299 +
1 file changed, 299 insertions(+)
create mode 100644 drivers/gpu/drm/panel/panel-innolux-tv123wam.c
diff --git a/drivers/gpu/drm/panel/panel-innolux-tv123wam.c
b/drivers/gpu/drm/panel/panel-innolux-tv123wam.c
new file mode 100644
index 000..f149fa9
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-innolux-tv123wam.c
@@ -0,0 +1,299 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct panel_edp_2k_desc {
+ const struct drm_display_mode *modes;
+ unsigned int num_modes;
+ struct {
+ unsigned int width;
+ unsigned int height;
+ } size;
+ u32 bpc;
+ u32 bus_flags;
+};
+
+struct panel_edp_2k_data {
+ struct drm_panel base;
+ bool enabled;
+ bool prepared;
+
+ const struct panel_edp_2k_desc *desc;
+
+ struct regulator *supply;
+ struct gpio_desc *enable_gpio;
+ struct backlight_device *backlight;
+};
+
+static const struct drm_display_mode innolux_edp_2k_mode = {
+ .clock = 206016,
+ .hdisplay = 2160,
+ .hsync_start = 2160 + 80,
+ .hsync_end = 2160 + 80 + 48,
+ .htotal = 2160 + 80 + 48 + 32,
+ .vdisplay = 1440,
+ .vsync_start = 1440 + 27,
+ .vsync_end = 1440 + 27 + 3,
+ .vtotal = 1440 + 27 + 3 + 10,
+ .vrefresh = 60,
+ .flags = DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC,
+};
+
+static const struct panel_edp_2k_desc innolux_edp_2k = {
+ .modes = &innolux_edp_2k_mode,
+ .num_modes = 1,
+ .size = {
+ .width = 223,
+ .height = 125,
+ },
+ .bpc = 8,
+ .bus_flags = DRM_BUS_FLAG_PIXDATA_POSEDGE,
+};
+
+static const struct of_device_id platform_of_match[] = {
+ {
+ .compatible = "innolux, edp_2k_panel",
+ .data = &innolux_edp_2k,
+ },
+};
+
+static inline struct panel_edp_2k_data *
+to_panel_edp_2k_data(struct drm_panel *panel)
+{
+ return container_of(panel, struct panel_edp_2k_data, base);
+}
+
+static int panel_edp_2k_disable(struct drm_panel *panel)
+{
+ struct panel_edp_2k_data *pdata = to_panel_edp_2k_data(panel);
+
+ if (!pdata->enabled)
+ return 0;
+
+ if (pdata->backlight) {
+ pdata->backlight->props.power = FB_BLANK_POWERDOWN;
+ pdata->backlight->props.state |= BL_CORE_FBBLANK;
+ backlight_update_status(pdata->backlight);
+ }
+
+ pdata->enabled = false;
+
+ return 0;
+}
+
+static int panel_edp_2k_unprepare(struct drm_panel *panel)
+{
+ struct panel_edp_2k_data *pdata = to_panel_edp_2k_data(panel);
+
+ if (!pdata->prepared)
+ return 0;
+
+ if (pdata->enable_gpio)
+ gpiod_set_value_cansleep(pdata->enable_gpio, 0);
+
+ regulator_disable(pdata->supply);
+
+ pdata->prepared = false;
+
+ return 0;
+}
+
+static int panel_edp_2k_prepare(struct drm_panel *panel)
+{
+ struct panel_edp_2k_data *pdata = to_panel_edp_2k_data(panel);
+ int ret;
+
+ if (pdata->prepared)
+ return 0;
+
+ ret = regulator_enable(pdata->supply);
+ if (ret < 0) {
+ dev_err(panel->dev, "failed to enable supply: %d\n", ret);
+ return ret;
+ }
+
+ if (pdata->enable_gpio)
+ gpiod_set_value_cansleep(pdata->enable_gpio, 1);
+
+ pdata->prepared = true;
+
+ return 0;
+}
+
+static int panel_edp_2k_enable(struct drm_panel *panel)
+{
+ struct panel_edp_2k_data *pdata = to_panel_edp_2k_data(panel);
+
+ if (pdata->enabled)
+ return 0;
+
+ if (pdata->backlight) {
+ pdata->backlight->props.state &= ~BL_CORE_FBBLANK;
+ pdata->backlight->props.power = FB_BLANK_UNBLANK;
+ backlight_update_status(pdata->backlight);
+ }
+
+ pdata->enabled = true;
+
+ return 0;
+}
+
+static int panel_edp_2k_get_modes(struct drm_panel *panel)
+{
+ struct panel_edp_2k_data *pdata = to_panel_edp_2k_data(panel);
+ struct drm_connector *connector = pdata->base.connector;
+ struct drm_device *drm = pdata->base.drm;
+ struct drm_display_mode *mode;
+ unsigned int i, num = 0;
+
+ if (!pdata->desc || !connector || !drm)
+ return 0;
+
+ for (i = 0; i < pdata->desc->num_modes; i++) {
+ const struct drm_display_mode *m = &pdata->desc->modes[i];
+
+ mode = drm_mode_duplicate(drm, m);
+ if (!mode) {
+ dev_err(drm->dev, "failed to add mode %ux%u@%u\n",
+ m->hdisplay, m->vdisplay, m->vrefresh);
+ continue;
+
Re: [Xen-devel] [PATCH 0/1] drm/xen-zcopy: Add Xen zero-copy helper DRM driver
On Wed, Apr 18, 2018 at 11:01:12AM +0300, Oleksandr Andrushchenko wrote: > On 04/18/2018 10:35 AM, Roger Pau Monné wrote: > > On Wed, Apr 18, 2018 at 09:38:39AM +0300, Oleksandr Andrushchenko wrote: > > > On 04/17/2018 11:57 PM, Dongwon Kim wrote: > > > > On Tue, Apr 17, 2018 at 09:59:28AM +0200, Daniel Vetter wrote: > > > > > On Mon, Apr 16, 2018 at 12:29:05PM -0700, Dongwon Kim wrote: > > > 3.2 Backend exports dma-buf to xen-front > > > > > > In this case Dom0 pages are shared with DomU. As before, DomU can only > > > write > > > to these pages, not any other page from Dom0, so it can be still > > > considered > > > safe. > > > But, the following must be considered (highlighted in xen-front's Kernel > > > documentation): > > > - If guest domain dies then pages/grants received from the backend > > > cannot > > > be claimed back - think of it as memory lost to Dom0 (won't be used > > > for > > > any > > > other guest) > > > - Misbehaving guest may send too many requests to the backend exhausting > > > its grant references and memory (consider this from security POV). As > > > the > > > backend runs in the trusted domain we also assume that it is trusted > > > as > > > well, > > > e.g. must take measures to prevent DDoS attacks. > > I cannot parse the above sentence: > > > > "As the backend runs in the trusted domain we also assume that it is > > trusted as well, e.g. must take measures to prevent DDoS attacks." > > > > What's the relation between being trusted and protecting from DoS > > attacks? > I mean that we trust the backend that it can prevent Dom0 > from crashing in case DomU's frontend misbehaves, e.g. > if the frontend sends too many memory requests etc. > > In any case, all? PV protocols are implemented with the frontend > > sharing pages to the backend, and I think there's a reason why this > > model is used, and it should continue to be used. > This is the first use-case above. But there are real-world > use-cases (embedded in my case) when physically contiguous memory > needs to be shared, one of the possible ways to achieve this is > to share contiguous memory from Dom0 to DomU (the second use-case above) > > Having to add logic in the backend to prevent such attacks means > > that: > > > > - We need more code in the backend, which increases complexity and > > chances of bugs. > > - Such code/logic could be wrong, thus allowing DoS. > You can live without this code at all, but this is then up to > backend which may make Dom0 down because of DomU's frontend doing evil > things IMO we should design protocols that do not allow such attacks instead of having to defend against them. > > > 4. xen-front/backend/xen-zcopy synchronization > > > > > > 4.1. As I already said in 2) all the inter VM communication happens > > > between > > > xen-front and the backend, xen-zcopy is NOT involved in that. > > > When xen-front wants to destroy a display buffer (dumb/dma-buf) it issues > > > a > > > XENDISPL_OP_DBUF_DESTROY command (opposite to XENDISPL_OP_DBUF_CREATE). > > > This call is synchronous, so xen-front expects that backend does free the > > > buffer pages on return. > > > > > > 4.2. Backend, on XENDISPL_OP_DBUF_DESTROY: > > > - closes all dumb handles/fd's of the buffer according to [3] > > > - issues DRM_IOCTL_XEN_ZCOPY_DUMB_WAIT_FREE IOCTL to xen-zcopy to make > > > sure > > > the buffer is freed (think of it as it waits for dma-buf->release > > > callback) > > So this zcopy thing keeps some kind of track of the memory usage? Why > > can't the user-space backend keep track of the buffer usage? > Because there is no dma-buf UAPI which allows to track the buffer life cycle > (e.g. wait until dma-buf's .release callback is called) > > > - replies to xen-front that the buffer can be destroyed. > > > This way deletion of the buffer happens synchronously on both Dom0 and > > > DomU > > > sides. In case if DRM_IOCTL_XEN_ZCOPY_DUMB_WAIT_FREE returns with time-out > > > error > > > (BTW, wait time is a parameter of this IOCTL), Xen will defer grant > > > reference > > > removal and will retry later until those are free. > > > > > > Hope this helps understand how buffers are synchronously deleted in case > > > of xen-zcopy with a single protocol command. > > > > > > I think the above logic can also be re-used by the hyper-dmabuf driver > > > with > > > some additional work: > > > > > > 1. xen-zcopy can be split into 2 parts and extend: > > > 1.1. Xen gntdev driver [4], [5] to allow creating dma-buf from grefs and > > > vise versa, > > I don't know much about the dma-buf implementation in Linux, but > > gntdev is a user-space device, and AFAICT user-space applications > > don't have any notion of dma buffers. How are such buffers useful for > > user-space? Why can't this just be called memory? > A dma-buf is seen by user-space as a file descriptor and you can > pass it to different drivers then. For example, you can share a buffer > used by
[[RFC]DPU PATCH 1/4] drm/bridge: add support for sn65dsi86 bridge driver
Add support for TI's sn65dsi86 dsi2edp bridge chip.
The chip converts DSI transmitted signal to eDP signal,
which is fed to the connected eDP panel.
This chip can be controlled via either i2c interface or
dsi interface. Currently in driver all the control registers
are being accessed through i2c interface only.
Also as of now HPD support has not been added to bridge
chip driver.
Signed-off-by: Sandeep Panda
---
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 742 ++
1 file changed, 742 insertions(+)
create mode 100644 drivers/gpu/drm/bridge/ti-sn65dsi86.c
diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
new file mode 100644
index 000..c798f2f
--- /dev/null
+++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
@@ -0,0 +1,742 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define SN_BRIDGE_REVISION_ID 0x2
+
+/* Link Training specific registers */
+#define SN_DEVICE_REV_REG 0x08
+#define SN_REFCLK_FREQ_REG 0x0A
+#define SN_DSI_LANES_REG 0x10
+#define SN_DSIA_CLK_FREQ_REG 0x12
+#define SN_ENH_FRAME_REG 0x5A
+#define SN_SSC_CONFIG_REG 0x93
+#define SN_DATARATE_CONFIG_REG 0x94
+#define SN_PLL_ENABLE_REG 0x0D
+#define SN_SCRAMBLE_CONFIG_REG 0x95
+#define SN_AUX_WDATA0_REG 0x64
+#define SN_AUX_ADDR_19_16_REG 0x74
+#define SN_AUX_ADDR_15_8_REG 0x75
+#define SN_AUX_ADDR_7_0_REG0x76
+#define SN_AUX_LENGTH_REG 0x77
+#define SN_AUX_CMD_REG 0x78
+#define SN_ML_TX_MODE_REG 0x96
+#define SN_PAGE_SELECT_REG 0xFF
+#define SN_AUX_RDATA0_REG 0x79
+/* video config specific registers */
+#define SN_CHA_ACTIVE_LINE_LENGTH_LOW_REG 0x20
+#define SN_CHA_ACTIVE_LINE_LENGTH_HIGH_REG 0x21
+#define SN_CHA_VERTICAL_DISPLAY_SIZE_LOW_REG 0x24
+#define SN_CHA_VERTICAL_DISPLAY_SIZE_HIGH_REG 0x25
+#define SN_CHA_HSYNC_PULSE_WIDTH_LOW_REG 0x2C
+#define SN_CHA_HSYNC_PULSE_WIDTH_HIGH_REG 0x2D
+#define SN_CHA_VSYNC_PULSE_WIDTH_LOW_REG 0x30
+#define SN_CHA_VSYNC_PULSE_WIDTH_HIGH_REG 0x31
+#define SN_CHA_HORIZONTAL_BACK_PORCH_REG 0x34
+#define SN_CHA_VERTICAL_BACK_PORCH_REG 0x36
+#define SN_CHA_HORIZONTAL_FRONT_PORCH_REG 0x38
+#define SN_CHA_VERTICAL_FRONT_PORCH_REG0x3A
+#define SN_DATA_FORMAT_REG 0x5B
+#define SN_COLOR_BAR_CONFIG_REG0x3C
+
+#define DPPLL_CLK_SRC_REFCLK 0
+#define DPPLL_CLK_SRC_DSICLK 1
+#define MIN_DSI_CLK_FREQ_MHZ 40
+
+enum ti_sn_bridge_ref_clks {
+ SN_REF_CLK_12_MHZ = 0,
+ SN_REF_CLK_19_2_MHZ,
+ SN_REF_CLK_26_MHZ,
+ SN_REF_CLK_27_MHZ,
+ SN_REF_CLK_38_4_MHZ,
+ SN_REF_CLK_MAX,
+};
+
+struct ti_sn_bridge {
+ struct device *dev;
+ struct drm_bridge bridge;
+ struct drm_connector connector;
+ struct device_node *host_node;
+ struct mipi_dsi_device *dsi;
+ /* handle to the connected eDP panel */
+ struct drm_panel *panel;
+ int irq;
+ struct gpio_desc *irq_gpio;
+ /* list of gpios needed to enable the bridge functionality */
+ struct gpio_descs *enable_gpios;
+ unsigned int num_supplies;
+ struct regulator_bulk_data *supplies;
+ struct i2c_client *i2c_client;
+ struct i2c_adapter *ddc;
+ bool power_on;
+ u32 num_modes;
+ struct drm_display_mode curr_mode;
+};
+
+static int ti_sn_bridge_write(struct ti_sn_bridge *pdata, u8 reg, u8 val)
+{
+ struct i2c_client *client = pdata->i2c_client;
+ u8 buf[2] = {reg, val};
+ struct i2c_msg msg = {
+ .addr = client->addr,
+ .flags = 0,
+ .len = 2,
+ .buf = buf,
+ };
+
+ if (i2c_transfer(client->adapter, &msg, 1) < 1) {
+ DRM_ERROR("i2c write failed\n");
+ return -EIO;
+ }
+
+ return 0;
+}
+
+static int ti_sn_bridge_read(struct ti_sn_bridge *pdata,
+ u8 reg, char *buf, u32 size)
+{
+ struct i2c_client *client = pdata->i2c_client;
+ struct i2c_msg msg[2] = {
+ {
+ .addr = client->addr,
+ .flags = 0,
+ .len = 1,
+ .buf = ®,
+ },
+ {
+ .addr = client->addr,
+ .flags = I2C_M_RD,
+ .len = size,
+ .buf = buf,
+ }
+ };
+
+
[PATCH v1 4/4] arm: dts: mt7623: add Mali-450 and related device nodes
From: Sean Wang
Add nodes for Mali-450 device, g3dsys device providing required clock
gate and reset control and larb3 offering an arbiter through iommu for
controlling access to external memory requested from Mali-450.
Signed-off-by: Sean Wang
---
arch/arm/boot/dts/mt7623.dtsi | 70 ++
arch/arm/boot/dts/mt7623a.dtsi | 4 +++
2 files changed, 74 insertions(+)
diff --git a/arch/arm/boot/dts/mt7623.dtsi b/arch/arm/boot/dts/mt7623.dtsi
index d1eb123..ace92b3 100644
--- a/arch/arm/boot/dts/mt7623.dtsi
+++ b/arch/arm/boot/dts/mt7623.dtsi
@@ -274,6 +274,17 @@
clock-names = "system-clk", "rtc-clk";
};
+ smi_common: smi@1000c000 {
+ compatible = "mediatek,mt7623-smi-common",
+"mediatek,mt2701-smi-common";
+ reg = <0 0x1000c000 0 0x1000>;
+ clocks = <&infracfg CLK_INFRA_SMI>,
+<&mmsys CLK_MM_SMI_COMMON>,
+<&infracfg CLK_INFRA_SMI>;
+ clock-names = "apb", "smi", "async";
+ power-domains = <&scpsys MT2701_POWER_DOMAIN_DISP>;
+ };
+
pwrap: pwrap@1000d000 {
compatible = "mediatek,mt7623-pwrap",
"mediatek,mt2701-pwrap";
@@ -305,6 +316,17 @@
reg = <0 0x10200100 0 0x1c>;
};
+ iommu: iommu@10205000 {
+ compatible = "mediatek,mt7623-m4u",
+"mediatek,mt2701-m4u";
+ reg = <0 0x10205000 0 0x1000>;
+ interrupts = ;
+ clocks = <&infracfg CLK_INFRA_M4U>;
+ clock-names = "bclk";
+ mediatek,larbs = <&larb3>;
+ #iommu-cells = <1>;
+ };
+
efuse: efuse@10206000 {
compatible = "mediatek,mt7623-efuse",
"mediatek,mt8173-efuse";
@@ -680,6 +702,54 @@
status = "disabled";
};
+ g3dsys: clock-controller@1300 {
+ compatible = "mediatek,mt7623-g3dsys",
+"mediatek,mt2701-g3dsys",
+"syscon";
+ reg = <0 0x1300 0 0x200>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ };
+
+ larb3: larb@1301 {
+ compatible = "mediatek,mt7623-smi-larb",
+"mediatek,mt2701-smi-larb";
+ reg = <0 0x1301 0 0x1000>;
+ mediatek,smi = <&smi_common>;
+ mediatek,larb-id = <3>;
+ clocks = <&clk26m>, <&clk26m>;
+ clock-names = "apb", "smi";
+ power-domains = <&scpsys MT2701_POWER_DOMAIN_MFG>;
+ };
+
+ mali: gpu@1304 {
+ compatible = "mediatek,mt7623-mali", "arm,mali-450";
+ reg = <0 0x1304 0 0x3>;
+ interrupts = ,
+,
+,
+,
+,
+,
+,
+,
+;
+ interrupt-names = "gp", "gpmmu", "pp0", "ppmmu0", "pp1",
+ "ppmmu1", "pp2", "ppmmu2", "pp";
+ clocks = <&topckgen CLK_TOP_MMPLL>,
+<&g3dsys CLK_G3DSYS_CORE>;
+ clock-names = "bus", "core";
+ power-domains = <&scpsys MT2701_POWER_DOMAIN_MFG>;
+ mediatek,larb = <&larb3>;
+ resets = <&g3dsys MT2701_G3DSYS_CORE_RST>;
+ };
+
+ mmsys: syscon@1400 {
+ compatible = "mediatek,mt2701-mmsys", "syscon";
+ reg = <0 0x1400 0 0x1000>;
+ #clock-cells = <1>;
+ };
+
hifsys: syscon@1a00 {
compatible = "mediatek,mt7623-hifsys",
"mediatek,mt2701-hifsys",
diff --git a/arch/arm/boot/dts/mt7623a.dtsi b/arch/arm/boot/dts/mt7623a.dtsi
index 0735a1fb8..a42fd46 100644
--- a/arch/arm/boot/dts/mt7623a.dtsi
+++ b/arch/arm/boot/dts/mt7623a.dtsi
@@ -21,6 +21,10 @@
power-domains = <&scpsys MT7623A_POWER_DOMAIN_ETH>;
};
+&mali {
+ status = "disabled";
+};
+
&nandc {
power-domains = <&scpsys MT7623A_POWER_DOMAIN_IFR_MSC>;
};
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [Xen-devel] [PATCH 0/1] drm/xen-zcopy: Add Xen zero-copy helper DRM driver
> -Original Message- > From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf > Of Roger Pau Monné > Sent: 18 April 2018 11:11 > To: Oleksandr Andrushchenko > Cc: jgr...@suse.com; Artem Mygaiev ; > Dongwon Kim ; airl...@linux.ie; > oleksandr_andrushche...@epam.com; linux-ker...@vger.kernel.org; dri- > de...@lists.freedesktop.org; Potrola, MateuszX > ; xen-de...@lists.xenproject.org; > daniel.vet...@intel.com; boris.ostrov...@oracle.com; Matt Roper > > Subject: Re: [Xen-devel] [PATCH 0/1] drm/xen-zcopy: Add Xen zero-copy > helper DRM driver > > On Wed, Apr 18, 2018 at 11:01:12AM +0300, Oleksandr Andrushchenko > wrote: > > On 04/18/2018 10:35 AM, Roger Pau Monné wrote: > > > On Wed, Apr 18, 2018 at 09:38:39AM +0300, Oleksandr Andrushchenko > wrote: > > > > On 04/17/2018 11:57 PM, Dongwon Kim wrote: > > > > > On Tue, Apr 17, 2018 at 09:59:28AM +0200, Daniel Vetter wrote: > > > > > > On Mon, Apr 16, 2018 at 12:29:05PM -0700, Dongwon Kim wrote: > > > > 3.2 Backend exports dma-buf to xen-front > > > > > > > > In this case Dom0 pages are shared with DomU. As before, DomU can > only write > > > > to these pages, not any other page from Dom0, so it can be still > considered > > > > safe. > > > > But, the following must be considered (highlighted in xen-front's Kernel > > > > documentation): > > > > - If guest domain dies then pages/grants received from the backend > cannot > > > > be claimed back - think of it as memory lost to Dom0 (won't be used > for > > > > any > > > > other guest) > > > > - Misbehaving guest may send too many requests to the backend > exhausting > > > > its grant references and memory (consider this from security POV). > As the > > > > backend runs in the trusted domain we also assume that it is trusted > as > > > > well, > > > > e.g. must take measures to prevent DDoS attacks. > > > I cannot parse the above sentence: > > > > > > "As the backend runs in the trusted domain we also assume that it is > > > trusted as well, e.g. must take measures to prevent DDoS attacks." > > > > > > What's the relation between being trusted and protecting from DoS > > > attacks? > > I mean that we trust the backend that it can prevent Dom0 > > from crashing in case DomU's frontend misbehaves, e.g. > > if the frontend sends too many memory requests etc. > > > In any case, all? PV protocols are implemented with the frontend > > > sharing pages to the backend, and I think there's a reason why this > > > model is used, and it should continue to be used. > > This is the first use-case above. But there are real-world > > use-cases (embedded in my case) when physically contiguous memory > > needs to be shared, one of the possible ways to achieve this is > > to share contiguous memory from Dom0 to DomU (the second use-case > above) > > > Having to add logic in the backend to prevent such attacks means > > > that: > > > > > > - We need more code in the backend, which increases complexity and > > > chances of bugs. > > > - Such code/logic could be wrong, thus allowing DoS. > > You can live without this code at all, but this is then up to > > backend which may make Dom0 down because of DomU's frontend doing > evil > > things > > IMO we should design protocols that do not allow such attacks instead > of having to defend against them. > > > > > 4. xen-front/backend/xen-zcopy synchronization > > > > > > > > 4.1. As I already said in 2) all the inter VM communication happens > between > > > > xen-front and the backend, xen-zcopy is NOT involved in that. > > > > When xen-front wants to destroy a display buffer (dumb/dma-buf) it > issues a > > > > XENDISPL_OP_DBUF_DESTROY command (opposite to > XENDISPL_OP_DBUF_CREATE). > > > > This call is synchronous, so xen-front expects that backend does free > the > > > > buffer pages on return. > > > > > > > > 4.2. Backend, on XENDISPL_OP_DBUF_DESTROY: > > > > - closes all dumb handles/fd's of the buffer according to [3] > > > > - issues DRM_IOCTL_XEN_ZCOPY_DUMB_WAIT_FREE IOCTL to xen- > zcopy to make > > > > sure > > > > the buffer is freed (think of it as it waits for dma-buf->release > > > > callback) > > > So this zcopy thing keeps some kind of track of the memory usage? Why > > > can't the user-space backend keep track of the buffer usage? > > Because there is no dma-buf UAPI which allows to track the buffer life cycle > > (e.g. wait until dma-buf's .release callback is called) > > > > - replies to xen-front that the buffer can be destroyed. > > > > This way deletion of the buffer happens synchronously on both Dom0 > and DomU > > > > sides. In case if DRM_IOCTL_XEN_ZCOPY_DUMB_WAIT_FREE returns > with time-out > > > > error > > > > (BTW, wait time is a parameter of this IOCTL), Xen will defer grant > > > > reference > > > > removal and will retry later until those are free. > > > > > > > > Hope this helps understand how buffers are synchronously deleted in > case > > > > of xen-zcopy with a single protocol co
Re: [Xen-devel] [PATCH 0/1] drm/xen-zcopy: Add Xen zero-copy helper DRM driver
On 04/18/2018 01:23 PM, Paul Durrant wrote: -Original Message- From: Oleksandr Andrushchenko [mailto:andr2...@gmail.com] Sent: 18 April 2018 11:21 To: Paul Durrant ; Roger Pau Monne Cc: jgr...@suse.com; Artem Mygaiev ; Dongwon Kim ; airl...@linux.ie; oleksandr_andrushche...@epam.com; linux-ker...@vger.kernel.org; dri- de...@lists.freedesktop.org; Potrola, MateuszX ; xen-de...@lists.xenproject.org; daniel.vet...@intel.com; boris.ostrov...@oracle.com; Matt Roper Subject: Re: [Xen-devel] [PATCH 0/1] drm/xen-zcopy: Add Xen zero-copy helper DRM driver On 04/18/2018 01:18 PM, Paul Durrant wrote: -Original Message- From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf Of Roger Pau Monné Sent: 18 April 2018 11:11 To: Oleksandr Andrushchenko Cc: jgr...@suse.com; Artem Mygaiev ; Dongwon Kim ; airl...@linux.ie; oleksandr_andrushche...@epam.com; linux-ker...@vger.kernel.org; dri- de...@lists.freedesktop.org; Potrola, MateuszX ; xen-de...@lists.xenproject.org; daniel.vet...@intel.com; boris.ostrov...@oracle.com; Matt Roper Subject: Re: [Xen-devel] [PATCH 0/1] drm/xen-zcopy: Add Xen zero-copy helper DRM driver On Wed, Apr 18, 2018 at 11:01:12AM +0300, Oleksandr Andrushchenko wrote: On 04/18/2018 10:35 AM, Roger Pau Monné wrote: On Wed, Apr 18, 2018 at 09:38:39AM +0300, Oleksandr Andrushchenko wrote: On 04/17/2018 11:57 PM, Dongwon Kim wrote: On Tue, Apr 17, 2018 at 09:59:28AM +0200, Daniel Vetter wrote: On Mon, Apr 16, 2018 at 12:29:05PM -0700, Dongwon Kim wrote: 3.2 Backend exports dma-buf to xen-front In this case Dom0 pages are shared with DomU. As before, DomU can only write to these pages, not any other page from Dom0, so it can be still considered safe. But, the following must be considered (highlighted in xen-front's Kernel documentation): - If guest domain dies then pages/grants received from the backend cannot be claimed back - think of it as memory lost to Dom0 (won't be used for any other guest) - Misbehaving guest may send too many requests to the backend exhausting its grant references and memory (consider this from security POV). As the backend runs in the trusted domain we also assume that it is trusted as well, e.g. must take measures to prevent DDoS attacks. I cannot parse the above sentence: "As the backend runs in the trusted domain we also assume that it is trusted as well, e.g. must take measures to prevent DDoS attacks." What's the relation between being trusted and protecting from DoS attacks? I mean that we trust the backend that it can prevent Dom0 from crashing in case DomU's frontend misbehaves, e.g. if the frontend sends too many memory requests etc. In any case, all? PV protocols are implemented with the frontend sharing pages to the backend, and I think there's a reason why this model is used, and it should continue to be used. This is the first use-case above. But there are real-world use-cases (embedded in my case) when physically contiguous memory needs to be shared, one of the possible ways to achieve this is to share contiguous memory from Dom0 to DomU (the second use-case above) Having to add logic in the backend to prevent such attacks means that: - We need more code in the backend, which increases complexity and chances of bugs. - Such code/logic could be wrong, thus allowing DoS. You can live without this code at all, but this is then up to backend which may make Dom0 down because of DomU's frontend doing evil things IMO we should design protocols that do not allow such attacks instead of having to defend against them. 4. xen-front/backend/xen-zcopy synchronization 4.1. As I already said in 2) all the inter VM communication happens between xen-front and the backend, xen-zcopy is NOT involved in that. When xen-front wants to destroy a display buffer (dumb/dma-buf) it issues a XENDISPL_OP_DBUF_DESTROY command (opposite to XENDISPL_OP_DBUF_CREATE). This call is synchronous, so xen-front expects that backend does free the buffer pages on return. 4.2. Backend, on XENDISPL_OP_DBUF_DESTROY: - closes all dumb handles/fd's of the buffer according to [3] - issues DRM_IOCTL_XEN_ZCOPY_DUMB_WAIT_FREE IOCTL to xen- zcopy to make sure the buffer is freed (think of it as it waits for dma-buf->release callback) So this zcopy thing keeps some kind of track of the memory usage? Why can't the user-space backend keep track of the buffer usage? Because there is no dma-buf UAPI which allows to track the buffer life cycle (e.g. wait until dma-buf's .release callback is called) - replies to xen-front that the buffer can be destroyed. This way deletion of the buffer happens synchronously on both Dom0 and DomU sides. In case if DRM_IOCTL_XEN_ZCOPY_DUMB_WAIT_FREE returns with time-out error (BTW, wait time is a parameter of this IOCTL), Xen will defer grant reference removal and will retry later until those are free. Hope th
Re: GPU/DRM issue with DSI commands on msm 8916
On Wednesday, April 18, 2018 10:53 AM, Archit Taneja wrote:
> On Wednesday 18 April 2018 01:58 PM, Daniel Mack wrote:
>> On Wednesday, April 18, 2018 10:06 AM, Archit Taneja wrote:
>>> One easy way to get around this would be to not try to set the clock
>>> rates every time we try to send a command. We just enable/disable them.
>>
>> Yes, that could work as well, but how about rounding the rates in the
>> callback that exists for that purpose? We're off by a fraction of a
>> permille only, after all.
>
> Sorry, forgot to respond to that in your last mail. I wasn't fully
> clear about how we'd do it.
>
> Do you mean that we call clk_round_rate() on the byte and pixel
> clocks in dsi_link_clk_enable_6g() after we set the rates?
No, before. AFAIU, the clk core calls into the clock provider's
.round_rate() callback if it exists to determine the exact rate that it
is about to set. With this, the driver can return a rate that it
actually supports.
The MSM PLL driver currently only clamps the values in that callback,
but it could be smarter than that and return the closest rate to the
desired rate they can actually generate. The calculations based on the
various registers in dsi_pll_{14,28}nm_clk_recalc_rate() beat me though,
so it's not immediately clear how to get the math right to implement
that properly.
Thanks,
Daniel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: DRI3 WSEGL plugin for TI SGX
* Tomi Valkeinen [180416 07:51]: > Hi All, > > I have implemented a WSEGL plugin library for Imagination's PVR driver > for SGX, which allows using SGX via DRI3. In other words, it is one > piece in the puzzle of using SGX with X11. > > The project is not production quality, as I have not had time to perfect > it (and, to be honest, I'm not exactly an expert on X), but now that I > finally got all the permissions to publish it, I'm doing just that to > allow other people to use it and help making it fully usable. > > You can find the code and a more detailed description here: > > https://github.com/TexasInstruments/dri3wsegl > > Hopefully with this code now public, we can get an SGX and GC320 > accelerated X11 on TI devices. Hey this is great news :) For the dts binding, sgx binding can be generic as we can put sgx as a child of ti-sysc. Then we just need the reset driver entry to power up sgx. And that way we should be able to get the kernel driver merged too even if it initially just powers and idles the sgx. Then we can maybe recycle some of the existing PSB_RSGX32 defines in the kernel for adding (slow) 2D acceleration like drivers/gpu/drm/gma500/accel_2d.c does.. Regards, Tony ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 3/4] clk: mediatek: add g3dsys support for MT2701 and MT7623
From: Sean Wang
Add clock driver support for g3dsys on MT2701 and MT7623, which is
providing essential clock gate and reset controller to Mali-450.
Signed-off-by: Sean Wang
---
drivers/clk/mediatek/Kconfig | 6 ++
drivers/clk/mediatek/Makefile | 1 +
drivers/clk/mediatek/clk-mt2701-g3d.c | 95 +++
include/dt-bindings/clock/mt2701-clk.h| 4 ++
include/dt-bindings/reset/mt2701-resets.h | 3 +
5 files changed, 109 insertions(+)
create mode 100644 drivers/clk/mediatek/clk-mt2701-g3d.c
diff --git a/drivers/clk/mediatek/Kconfig b/drivers/clk/mediatek/Kconfig
index 92afe59..3dd1dab 100644
--- a/drivers/clk/mediatek/Kconfig
+++ b/drivers/clk/mediatek/Kconfig
@@ -60,6 +60,12 @@ config COMMON_CLK_MT2701_AUDSYS
---help---
This driver supports Mediatek MT2701 audsys clocks.
+config COMMON_CLK_MT2701_G3DSYS
+ bool "Clock driver for MediaTek MT2701 g3dsys"
+ depends on COMMON_CLK_MT2701
+ ---help---
+ This driver supports MediaTek MT2701 g3dsys clocks.
+
config COMMON_CLK_MT2712
bool "Clock driver for MediaTek MT2712"
depends on (ARCH_MEDIATEK && ARM64) || COMPILE_TEST
diff --git a/drivers/clk/mediatek/Makefile b/drivers/clk/mediatek/Makefile
index b80eff2..844b55d 100644
--- a/drivers/clk/mediatek/Makefile
+++ b/drivers/clk/mediatek/Makefile
@@ -9,6 +9,7 @@ obj-$(CONFIG_COMMON_CLK_MT2701) += clk-mt2701.o
obj-$(CONFIG_COMMON_CLK_MT2701_AUDSYS) += clk-mt2701-aud.o
obj-$(CONFIG_COMMON_CLK_MT2701_BDPSYS) += clk-mt2701-bdp.o
obj-$(CONFIG_COMMON_CLK_MT2701_ETHSYS) += clk-mt2701-eth.o
+obj-$(CONFIG_COMMON_CLK_MT2701_G3DSYS) += clk-mt2701-g3d.o
obj-$(CONFIG_COMMON_CLK_MT2701_HIFSYS) += clk-mt2701-hif.o
obj-$(CONFIG_COMMON_CLK_MT2701_IMGSYS) += clk-mt2701-img.o
obj-$(CONFIG_COMMON_CLK_MT2701_MMSYS) += clk-mt2701-mm.o
diff --git a/drivers/clk/mediatek/clk-mt2701-g3d.c
b/drivers/clk/mediatek/clk-mt2701-g3d.c
new file mode 100644
index 000..1328c11
--- /dev/null
+++ b/drivers/clk/mediatek/clk-mt2701-g3d.c
@@ -0,0 +1,95 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2018 MediaTek Inc.
+ * Author: Sean Wang
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include "clk-mtk.h"
+#include "clk-gate.h"
+
+#include
+
+#define GATE_G3D(_id, _name, _parent, _shift) {\
+ .id = _id, \
+ .name = _name, \
+ .parent_name = _parent, \
+ .regs = &g3d_cg_regs, \
+ .shift = _shift,\
+ .ops = &mtk_clk_gate_ops_setclr,\
+ }
+
+static const struct mtk_gate_regs g3d_cg_regs = {
+ .sta_ofs = 0x0,
+ .set_ofs = 0x4,
+ .clr_ofs = 0x8,
+};
+
+static const struct mtk_gate g3d_clks[] = {
+ GATE_G3D(CLK_G3DSYS_CORE, "g3d_core", "mfg_sel", 0),
+};
+
+static int clk_mt2701_g3dsys_init(struct platform_device *pdev)
+{
+ struct clk_onecell_data *clk_data;
+ struct device_node *node = pdev->dev.of_node;
+ int r;
+
+ clk_data = mtk_alloc_clk_data(CLK_G3DSYS_NR);
+
+ mtk_clk_register_gates(node, g3d_clks, ARRAY_SIZE(g3d_clks),
+ clk_data);
+
+ r = of_clk_add_provider(node, of_clk_src_onecell_get, clk_data);
+ if (r)
+ dev_err(&pdev->dev,
+ "could not register clock provider: %s: %d\n",
+ pdev->name, r);
+
+ mtk_register_reset_controller(node, 1, 0xc);
+
+ return r;
+}
+
+static const struct of_device_id of_match_clk_mt2701_g3d[] = {
+ {
+ .compatible = "mediatek,mt2701-g3dsys",
+ .data = clk_mt2701_g3dsys_init,
+ }, {
+ /* sentinel */
+ }
+};
+
+static int clk_mt2701_g3d_probe(struct platform_device *pdev)
+{
+ int (*clk_init)(struct platform_device *);
+ int r;
+
+ clk_init = of_device_get_match_data(&pdev->dev);
+ if (!clk_init)
+ return -EINVAL;
+
+ r = clk_init(pdev);
+ if (r)
+ dev_err(&pdev->dev,
+ "could not register clock provider: %s: %d\n",
+ pdev->name, r);
+
+ return r;
+}
+
+static struct platform_driver clk_mt2701_g3d_drv = {
+ .probe = clk_mt2701_g3d_probe,
+ .driver = {
+ .name = "clk-mt2701-g3d",
+ .of_match_table = of_match_clk_mt2701_g3d,
+ },
+};
+
+builtin_platform_driver(clk_mt2701_g3d_drv);
diff --git a/include/dt-bindings/clock/mt2701-clk.h
b/include/dt-bindings/clock/mt2701-clk.h
index 24e93df..2ac62a6 100644
--- a/include/dt-bindings/clock/mt2701-clk.h
+++ b/include/dt-bindings/clock/mt2701-clk.h
@@ -431,6 +431,10 @@
#define CLK_ETHSYS_CRYPTO 8
#define CLK_ETHSYS_NR 9
+/* G3DSYS */
+#define CLK_G3DSYS_CORE
[PATCH v1 0/4] add Mali-450 support to MT7623 SoC
From: Sean Wang Hi, The series adds a required resource setup to allow Mali-450 to work on MT7623. This also can benefits other MediaTek SoCs having Mali-450 device. In order to prove the setup is proper, I also have added mediatek port to linux-lima at [1] and make a few of tests along with off-screen rendering [2][3][4][5][6][7] through mesa-lima [8]. All work correctly. [1] https://github.com/objelf/linux-lima/tree/mediatek-lima-4.16-rc5 [2] simple triangle: https://github.com/yuq/gfx/tree/master/gbm-surface [3] vertex shader uniform: https://github.com/yuq/gfx/tree/master/gbm-surface-move [4] multi varying: https://github.com/yuq/gfx/tree/master/gbm-surface-color [5] multi draw: https://github.com/yuq/gfx/tree/master/gbm-surface-draw [6] FBO: https://github.com/yuq/gfx/tree/master/gbm-surface-fbo [7] kmscube: https://github.com/yuq/kmscube [8] https://github.com/yuq/mesa-lima Hope these patches can help people working on BPI-R2. Sean Sean Wang (4): dt-bindings: gpu: mali-utgard: add mediatek,mt7623-mali compatible dt-bindings: clock: mediatek: add g3dsys bindings clk: mediatek: add g3dsys support for MT2701 and MT7623 arm: dts: mt7623: add Mali-450 and related device nodes .../bindings/arm/mediatek/mediatek,g3dsys.txt | 30 +++ .../devicetree/bindings/gpu/arm,mali-utgard.txt| 9 ++ arch/arm/boot/dts/mt7623.dtsi | 70 arch/arm/boot/dts/mt7623a.dtsi | 4 + drivers/clk/mediatek/Kconfig | 6 ++ drivers/clk/mediatek/Makefile | 1 + drivers/clk/mediatek/clk-mt2701-g3d.c | 95 ++ include/dt-bindings/clock/mt2701-clk.h | 4 + include/dt-bindings/reset/mt2701-resets.h | 3 + 9 files changed, 222 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/mediatek/mediatek,g3dsys.txt create mode 100644 drivers/clk/mediatek/clk-mt2701-g3d.c -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 2/4] dt-bindings: clock: mediatek: add g3dsys bindings
From: Sean Wang
Add bindings to g3dsys providing necessary clock and reset control to
Mali-450.
Signed-off-by: Sean Wang
---
.../bindings/arm/mediatek/mediatek,g3dsys.txt | 30 ++
1 file changed, 30 insertions(+)
create mode 100644
Documentation/devicetree/bindings/arm/mediatek/mediatek,g3dsys.txt
diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,g3dsys.txt
b/Documentation/devicetree/bindings/arm/mediatek/mediatek,g3dsys.txt
new file mode 100644
index 000..ff2d70c
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,g3dsys.txt
@@ -0,0 +1,30 @@
+MediaTek g3dsys controller
+
+
+The MediaTek g3dsys controller provides various clocks and reset controller to
+the GPU.
+
+Required Properties:
+
+- compatible: Should be:
+ - "mediatek,mt2701-g3dsys", "syscon":
+ for MT2701 SoC
+ - "mediatek,mt7623-ethsys", "mediatek,mt2701-g3dsys", "syscon":
+ for MT7623 SoC
+- #clock-cells: Must be 1
+- #reset-cells: Must be 1
+
+The ethsys controller uses the common clk binding from
+Documentation/devicetree/bindings/clock/clock-bindings.txt
+The available clocks are defined in dt-bindings/clock/mt*-clk.h.
+
+Example:
+
+g3dsys: clock-controller@1300 {
+ compatible = "mediatek,mt7623-g3dsys",
+"mediatek,mt2701-g3dsys",
+"syscon";
+ reg = <0 0x1300 0 0x200>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+};
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 2/4] dt-bindings: clock: mediatek: add g3dsys bindings
On Wed, 2018-04-18 at 20:18 -0700, Stephen Boyd wrote: > Quoting sean.w...@mediatek.com (2018-04-18 03:24:54) > > From: Sean Wang > > > > Add bindings to g3dsys providing necessary clock and reset control to > > Mali-450. > > > > Signed-off-by: Sean Wang > > --- > > .../bindings/arm/mediatek/mediatek,g3dsys.txt | 30 > > ++ > > Why isn't this under bindings/clock/ ? > Tons of bindings for clock controller have been present at binding/arm/mediatek. g3dsys just have a follow-up to them. It's worth another patch moving them all from bindings/arm/mediatek/ to bindings/clock/mediatek. what's your opinion for either doing it prior to g3dsys binding being added or doing it in the future ? > > ___ > Linux-mediatek mailing list > linux-media...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-mediatek ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Xen-devel] [PATCH 0/1] drm/xen-zcopy: Add Xen zero-copy helper DRM driver
On Wed, Apr 18, 2018 at 01:39:35PM +0300, Oleksandr Andrushchenko wrote: > On 04/18/2018 01:18 PM, Paul Durrant wrote: > > > -Original Message- > > > From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf > > > Of Roger Pau Monné > > > Sent: 18 April 2018 11:11 > > > To: Oleksandr Andrushchenko > > > Cc: jgr...@suse.com; Artem Mygaiev ; > > > Dongwon Kim ; airl...@linux.ie; > > > oleksandr_andrushche...@epam.com; linux-ker...@vger.kernel.org; dri- > > > de...@lists.freedesktop.org; Potrola, MateuszX > > > ; xen-de...@lists.xenproject.org; > > > daniel.vet...@intel.com; boris.ostrov...@oracle.com; Matt Roper > > > > > > Subject: Re: [Xen-devel] [PATCH 0/1] drm/xen-zcopy: Add Xen zero-copy > > > helper DRM driver > > > > > > On Wed, Apr 18, 2018 at 11:01:12AM +0300, Oleksandr Andrushchenko > > > wrote: > > > > On 04/18/2018 10:35 AM, Roger Pau Monné wrote: > > > After speaking with Oleksandr on IRC, I think the main usage of the > > > gntdev extension is to: > > > > > > 1. Create a dma-buf from a set of grant references. > > > 2. Share dma-buf and get a list of grant references. > > > > > > I think this set of operations could be broken into: > > > > > > 1.1 Map grant references into user-space using the gntdev. > > > 1.2 Create a dma-buf out of a set of user-space virtual addresses. > > > > > > 2.1 Map a dma-buf into user-space. > > > 2.2 Get grefs out of the user-space addresses where the dma-buf is > > > mapped. > > > > > > So it seems like what's actually missing is a way to: > > > > > > - Create a dma-buf from a list of user-space virtual addresses. > > > - Allow to map a dma-buf into user-space, so it can then be used with > > > the gntdev. > > > > > > I think this is generic enough that it could be implemented by a > > > device not tied to Xen. AFAICT the hyper_dma guys also wanted > > > something similar to this. > Ok, so just to summarize, xen-zcopy/hyper-dmabuf as they are now, > are no go from your POV? My opinion is that there seems to be a more generic way to implement this, and thus I would prefer that one. > Instead, we have to make all that fancy stuff > with VAs <-> device-X and have that device-X driver live out of drivers/xen > as it is not a Xen specific driver? That would be my preference if feasible, simply because it can be reused by other use-cases that need to create dma-bufs in user-space. In any case I just knew about dma-bufs this morning, there might be things that I'm missing. Roger. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] gpu: drm: tegra: Adding new typedef vm_fault_t
> This new function returns VM_FAULT_NOPAGE only for 0 and -EBUSY, whereas > we used to return VM_FAULT_NOPAGE for -EAGAIN, -ERESTARTSYS and -EINTR > as well. Previously vm_insert_page unable to return VM_FAULT_ type due to which different drivers have their own mapping from err to VM_FAULT_ type. With new vmf_insert_page() introduce in 4.17-rc1 we have a common mapping for err to VM_FAULT_ which remain same for every drivers/file systems. Was this previously wrong? I think Matthew is the right person to answer this. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v9 2/2] drm: bridge: Add thc63lvd1024 LVDS decoder driver
Add DRM bridge driver for Thine THC63LVD1024 LVDS to digital parallel
output converter.
Signed-off-by: Jacopo Mondi
Reviewed-by: Andrzej Hajda
Reviewed-by: Niklas Söderlund
Reviewed-by: Laurent Pinchart
---
drivers/gpu/drm/bridge/Kconfig| 6 +
drivers/gpu/drm/bridge/Makefile | 1 +
drivers/gpu/drm/bridge/thc63lvd1024.c | 206 ++
3 files changed, 213 insertions(+)
create mode 100644 drivers/gpu/drm/bridge/thc63lvd1024.c
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 3aa65bd..42c9c2d 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -93,6 +93,12 @@ config DRM_SII9234
It is an I2C driver, that detects connection of MHL bridge
and starts encapsulation of HDMI signal.
+config DRM_THINE_THC63LVD1024
+ tristate "Thine THC63LVD1024 LVDS decoder bridge"
+ depends on OF
+ ---help---
+ Thine THC63LVD1024 LVDS/parallel converter driver.
+
config DRM_TOSHIBA_TC358767
tristate "Toshiba TC358767 eDP bridge"
depends on OF
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index 373eb28..fd90b16 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
obj-$(CONFIG_DRM_SIL_SII8620) += sil-sii8620.o
obj-$(CONFIG_DRM_SII902X) += sii902x.o
obj-$(CONFIG_DRM_SII9234) += sii9234.o
+obj-$(CONFIG_DRM_THINE_THC63LVD1024) += thc63lvd1024.o
obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o
obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/
diff --git a/drivers/gpu/drm/bridge/thc63lvd1024.c
b/drivers/gpu/drm/bridge/thc63lvd1024.c
new file mode 100644
index 000..c8b9edd
--- /dev/null
+++ b/drivers/gpu/drm/bridge/thc63lvd1024.c
@@ -0,0 +1,206 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * THC63LVD1024 LVDS to parallel data DRM bridge driver.
+ *
+ * Copyright (C) 2018 Jacopo Mondi
+ */
+
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+enum thc63_ports {
+ THC63_LVDS_IN0,
+ THC63_LVDS_IN1,
+ THC63_RGB_OUT0,
+ THC63_RGB_OUT1,
+};
+
+struct thc63_dev {
+ struct device *dev;
+
+ struct regulator *vcc;
+
+ struct gpio_desc *pdwn;
+ struct gpio_desc *oe;
+
+ struct drm_bridge bridge;
+ struct drm_bridge *next;
+};
+
+static inline struct thc63_dev *to_thc63(struct drm_bridge *bridge)
+{
+ return container_of(bridge, struct thc63_dev, bridge);
+}
+
+static int thc63_attach(struct drm_bridge *bridge)
+{
+ struct thc63_dev *thc63 = to_thc63(bridge);
+
+ return drm_bridge_attach(bridge->encoder, thc63->next, bridge);
+}
+
+static void thc63_enable(struct drm_bridge *bridge)
+{
+ struct thc63_dev *thc63 = to_thc63(bridge);
+ int ret;
+
+ ret = regulator_enable(thc63->vcc);
+ if (ret) {
+ dev_err(thc63->dev,
+ "Failed to enable regulator \"vcc\": %d\n", ret);
+ return;
+ }
+
+ gpiod_set_value(thc63->pdwn, 0);
+ gpiod_set_value(thc63->oe, 1);
+}
+
+static void thc63_disable(struct drm_bridge *bridge)
+{
+ struct thc63_dev *thc63 = to_thc63(bridge);
+ int ret;
+
+ gpiod_set_value(thc63->oe, 0);
+ gpiod_set_value(thc63->pdwn, 1);
+
+ ret = regulator_disable(thc63->vcc);
+ if (ret)
+ dev_err(thc63->dev,
+ "Failed to disable regulator \"vcc\": %d\n", ret);
+}
+
+static const struct drm_bridge_funcs thc63_bridge_func = {
+ .attach = thc63_attach,
+ .enable = thc63_enable,
+ .disable = thc63_disable,
+};
+
+static int thc63_parse_dt(struct thc63_dev *thc63)
+{
+ struct device_node *thc63_out;
+ struct device_node *remote;
+
+ thc63_out = of_graph_get_endpoint_by_regs(thc63->dev->of_node,
+ THC63_RGB_OUT0, -1);
+ if (!thc63_out) {
+ dev_err(thc63->dev, "Missing endpoint in port@%u\n",
+ THC63_RGB_OUT0);
+ return -ENODEV;
+ }
+
+ remote = of_graph_get_remote_port_parent(thc63_out);
+ of_node_put(thc63_out);
+ if (!remote) {
+ dev_err(thc63->dev, "Endpoint in port@%u unconnected\n",
+ THC63_RGB_OUT0);
+ return -ENODEV;
+ }
+
+ if (!of_device_is_available(remote)) {
+ dev_err(thc63->dev, "port@%u remote endpoint is disabled\n",
+ THC63_RGB_OUT0);
+ of_node_put(remote);
+ return -ENODEV;
+ }
+
+ thc63->next = of_drm_find_bridge(remote);
+ of_node_put(remote);
+ if (!thc63->next)
+ return -EPROBE_DEFER;
+
+ return 0;
+}
+
+static int thc63_gpio_init(struct thc63_dev *thc63)
+{
+ thc63->oe = devm_gpiod_get
[PATCH v9 0/2] drm: Add Thine THC63LVD1024 LVDS decoder bridge
As I have another series which is based on this one + Eagle board display support, I'm re-sending this one to fix the small issue I pointed out in my reply to v8. Simon: no changes to Eagle DTS series, so the last one sent is still the good one. DRM: I have collected several reviewed-by tags both on driver and bindings. Can I send out incremental patches on this series and consider this one to be ready to be collected? Thanks j v8 -> v9: - Put 'remote' OF node after usage not just in error path during device tree parsing routine - Add Rob's Reviewed-by tag to the device tree bindings documentation v7 -> b8: - Make 'vcc' supply mandatory - Use 'oe' property name to describe "OE" pin - Minor fixes as suggested by Laurent on bindings and driver v6 -> v7: - Use semi-standard names for powerdown and output enable GPIOs as suggested by Rob and Vladimir - Use 'regulator_get()' not the optional version, and list only 'vcc' as requested supply - Addressed Laurent's review comments and removed Eagle display enablement patch to be sent separately v5 -> v6: - Drop check for CONFIG_OF as it is a Kconfig dependency - Add Niklas Reviewed-by tags - List [3/3] depenencies below commit message to ease integration v4 -> v5: - Fix punctuation in bindings documentation - Add small statement to bindings document to clarify the chip has no control bus - Print regulator name in enable/disable routines error path - Add Andrzej Reviewed-by tag v3 -> v4: - Rename permutations of "pdwn" to just "pdwn" everywhere in the series - Improve power enable/disable routines as suggested by Andrzej and Sergei - Change "pdwn" gpio initialization to use the logical output level - Change Kconfig description v2 -> v3: - Drop support for "lvds-decoder" and make the driver THC63LVD1024 specific -- Rework bindings to describe multiple input/output ports -- Rename driver and remove "lvds-decoder" references -- Rework Eagle DTS to use new bindings v1 -> v2: - Drop support for THC63LVD1024 Jacopo Mondi (2): dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder drm: bridge: Add thc63lvd1024 LVDS decoder driver .../bindings/display/bridge/thine,thc63lvd1024.txt | 60 ++ drivers/gpu/drm/bridge/Kconfig | 6 + drivers/gpu/drm/bridge/Makefile| 1 + drivers/gpu/drm/bridge/thc63lvd1024.c | 205 + 4 files changed, 272 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt create mode 100644 drivers/gpu/drm/bridge/thc63lvd1024.c -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: Print unadorned pointers
After commit ad67b74 ("printk: hash addresses printed with %p")
pointers are being hashed when printed. However, this makes
debug output completely useless. Switch to %px in order to see the
unadorned kernel pointers.
This was done with the following one-liner:
find drivers/gpu/drm -type f -name "*.c" -exec sed -r -i
'/DRM_DEBUG|KERN_DEBUG|pr_debug/ s/%p\b/%px/g' {} +
Signed-off-by: Alexey Brodkin
Cc: Borislav Petkov
Cc: Tobin C. Harding
Cc: Alex Deucher
Cc: Andrey Grodzovsky
Cc: Arnd Bergmann
Cc: Benjamin Gaignard
Cc: Chen-Yu Tsai
Cc: Christian Gmeiner
Cc: "Christian König"
Cc: Cihangir Akturk
Cc: CK Hu
Cc: Daniel Vetter
Cc: Dave Airlie
Cc: David Airlie
Cc: "David (ChunMing) Zhou"
Cc: Gerd Hoffmann
Cc: Greg Kroah-Hartman
Cc: Gustavo Padovan
Cc: Harry Wentland
Cc: "Heiko Stübner"
Cc: Ingo Molnar
Cc: Jani Nikula
Cc: "Jerry (Fangzhi) Zuo"
Cc: Joonas Lahtinen
Cc: Krzysztof Kozlowski
Cc: "Leo (Sunpeng) Li"
Cc: Lucas Stach
Cc: Maarten Lankhorst
Cc: Matthias Brugger
Cc: Maxime Ripard
Cc: "Michel Dänzer"
Cc: Oded Gabbay
Cc: Philipp Zabel
Cc: Rob Clark
Cc: Rodrigo Vivi
Cc: Roger He
Cc: Roman Li
Cc: Russell King
Cc: Samuel Li
Cc: Sandy Huang
Cc: Sean Paul
Cc: Shirish S
Cc: Sinclair Yeh
Cc: Thomas Hellstrom
Cc: Tom Lendacky
Cc: Tony Cheng
Cc: Vincent Abriou
Cc: VMware Graphics
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-arm-...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: linux-media...@lists.infradead.org
Cc: linux-rockc...@lists.infradead.org
Cc: etna...@lists.freedesktop.org
Cc: freedr...@lists.freedesktop.org
Cc: amd-...@lists.freedesktop.org
Cc: intel-...@lists.freedesktop.org
Cc: virtualizat...@lists.linux-foundation.org
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 14 +++
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c| 4 +-
drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 4 +-
drivers/gpu/drm/amd/amdkfd/kfd_dbgdev.c| 2 +-
drivers/gpu/drm/amd/amdkfd/kfd_device.c| 10 ++---
drivers/gpu/drm/amd/amdkfd/kfd_doorbell.c | 4 +-
drivers/gpu/drm/amd/amdkfd/kfd_events.c| 4 +-
drivers/gpu/drm/amd/amdkfd/kfd_kernel_queue.c | 2 +-
drivers/gpu/drm/amd/amdkfd/kfd_process.c | 4 +-
drivers/gpu/drm/amd/amdkfd/kfd_queue.c | 18 -
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 14 +++
.../amd/display/amdgpu_dm/amdgpu_dm_mst_types.c| 2 +-
drivers/gpu/drm/armada/armada_gem.c| 12 +++---
drivers/gpu/drm/drm_atomic.c | 44 +++---
drivers/gpu/drm/drm_bufs.c | 8 ++--
drivers/gpu/drm/drm_dp_mst_topology.c | 4 +-
drivers/gpu/drm/drm_lease.c| 6 +--
drivers/gpu/drm/drm_lock.c | 2 +-
drivers/gpu/drm/drm_scatter.c | 4 +-
drivers/gpu/drm/etnaviv/etnaviv_drv.c | 6 +--
drivers/gpu/drm/i810/i810_dma.c| 2 +-
drivers/gpu/drm/i915/i915_perf.c | 2 +-
drivers/gpu/drm/i915/intel_display.c | 2 +-
drivers/gpu/drm/i915/intel_guc_ct.c| 4 +-
drivers/gpu/drm/i915/intel_guc_submission.c| 2 +-
drivers/gpu/drm/i915/intel_uc_fw.c | 2 +-
drivers/gpu/drm/mediatek/mtk_drm_gem.c | 2 +-
drivers/gpu/drm/mga/mga_warp.c | 2 +-
drivers/gpu/drm/msm/msm_drv.c | 4 +-
drivers/gpu/drm/qxl/qxl_cmd.c | 4 +-
drivers/gpu/drm/qxl/qxl_fb.c | 2 +-
drivers/gpu/drm/qxl/qxl_ttm.c | 2 +-
drivers/gpu/drm/radeon/radeon_display.c| 2 +-
drivers/gpu/drm/radeon/radeon_dp_mst.c | 12 +++---
drivers/gpu/drm/radeon/radeon_object.c | 2 +-
drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c | 2 +-
drivers/gpu/drm/savage/savage_bci.c| 2 +-
drivers/gpu/drm/sti/sti_gdp.c | 4 +-
drivers/gpu/drm/sti/sti_mixer.c| 2 +-
drivers/gpu/drm/sun4i/sun4i_crtc.c | 4 +-
drivers/gpu/drm/ttm/ttm_page_alloc.c | 2 +-
drivers/gpu/drm/udl/udl_fb.c | 2 +-
drivers/gpu/drm/via/via_dma.c | 4 +-
drivers/gpu/drm/via/via_irq.c | 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c| 2 +-
45 files changed, 120 insertions(+), 120 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
index 1d6e1479da38..32e85fe83152 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -438,7 +438,7 @@ static int add_bo_to_vm(struct amdgpu_device *adev, struct
kgd_mem *mem,
if (!bo_va_entry)
return -ENOMEM;
- pr_debug("\t add VA 0x%llx - 0x%llx to vm %p\n",
Re: [PATCH v2 4/6] drm/atmel-hlcdc: support bus-width (12/16/18/24) in endpoint nodes
On 2018-04-18 09:29, Boris Brezillon wrote:
> On Tue, 17 Apr 2018 15:10:50 +0200
> Peter Rosin wrote:
>
>> This beats the heuristic that the connector is involved in what format
>> should be output for cases where this fails.
>>
>> E.g. if there is a bridge that changes format between the encoder and the
>> connector, or if some of the RGB pins between the lcd controller and the
>> encoder are not routed on the PCB.
>>
>> This is critical for the devices that have the "conflicting output
>> formats" issue (SAM9N12, SAM9X5, SAMA5D3), since the most significant
>> RGB bits move around depending on the selected output mode. For
>> devices that do not have the "conflicting output formats" issue
>> (SAMA5D2, SAMA5D4), this is completely irrelevant.
>>
>> Signed-off-by: Peter Rosin
>> ---
>> drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 85
>> --
>> 1 file changed, 65 insertions(+), 20 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
>> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
>> index d73281095fac..2e718959981e 100644
>> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
>> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
>> @@ -19,12 +19,14 @@
>> */
>>
>> #include
>> +#include
>> #include
>> #include
>> #include
>>
>> #include
>> #include
>> +#include
>> #include
>>
>> #include
>> @@ -226,6 +228,68 @@ static void atmel_hlcdc_crtc_atomic_enable(struct
>> drm_crtc *c,
>> #define ATMEL_HLCDC_RGB888_OUTPUT BIT(3)
>> #define ATMEL_HLCDC_OUTPUT_MODE_MASKGENMASK(3, 0)
>>
>> +static int atmel_hlcdc_connector_output_mode(struct drm_connector_state
>> *state)
>> +{
>> +struct drm_connector *connector = state->connector;
>> +struct drm_display_info *info = &connector->display_info;
>> +unsigned int supported_fmts = 0;
>> +struct device_node *ep;
>> +int j;
>> +
>> +/*
>> + * Use the connector index as an approximation of the
>> + * endpoint node index. We know it's true for our case
>> + * depending on the driver implementation.
>> + */
>> +ep = of_graph_get_endpoint_by_regs(connector->dev->dev->of_node, 0,
>> + connector->index);
>> +
>
> Hm, this sounds a bit fragile. Can't we have a reference to the of_node
> attached to the connector? Or maybe we can parse this earlier and set a
> constraint on the accepted modes.
>
>> +if (ep) {
>> +int bus_fmt = drm_of_media_bus_fmt(ep);
>
> Hm, you're extracting this piece of information from the DT every time
> an atomic modeset is done. I'd really prefer to have this done once at
Yes, not happy about it either. I looked for other sensible places too
hook the info at probe time, but this was just the simplest. I'll take
another look...
> probe time. Since this property is attached to the connector, maybe we
> should overwrite the info->bus_formats[] array or mark some of its
> entries as invalid.
I find it very wrong to mix the connector format with what you want to
output. In my mind it's a broken assumption that they are related. It is
only correct for trivial cases. Also note my comment about the connector
index and the endpoint index, they are only coincidentally the same
based on our implementation. If the driver has more than one port or
initializes endpoints out of order for some reason, this is no longer
true.
I think it would be better to store this info somewhere near the encoder,
since that is what I find closest to what I'm trying to change.
As I said, I'll take another look and see if I can hook this in at some
other place.
>> +
>> +of_node_put(ep);
>> +
>> +if (bus_fmt < 0)
>> +return bus_fmt;
>> +
>> +switch (bus_fmt) {
>> +case 0:
>> +break;
>> +case MEDIA_BUS_FMT_RGB444_1X12:
>> +return ATMEL_HLCDC_RGB444_OUTPUT;
>> +case MEDIA_BUS_FMT_RGB565_1X16:
>> +return ATMEL_HLCDC_RGB565_OUTPUT;
>> +case MEDIA_BUS_FMT_RGB666_1X18:
>> +return ATMEL_HLCDC_RGB666_OUTPUT;
>> +case MEDIA_BUS_FMT_RGB888_1X24:
>> +return ATMEL_HLCDC_RGB888_OUTPUT;
>> +default:
>> +return -EINVAL;
>> +}
>> +}
>> +
>> +for (j = 0; j < info->num_bus_formats; j++) {
>> +switch (info->bus_formats[j]) {
>> +case MEDIA_BUS_FMT_RGB444_1X12:
>> +supported_fmts |= ATMEL_HLCDC_RGB444_OUTPUT;
>> +break;
>> +case MEDIA_BUS_FMT_RGB565_1X16:
>> +supported_fmts |= ATMEL_HLCDC_RGB565_OUTPUT;
>> +break;
>> +case MEDIA_BUS_FMT_RGB666_1X18:
>> +supported_fmts |= ATMEL_HLCDC_RGB666_OUTPUT;
>> +break;
>> +case MEDIA_BUS_FMT_RGB888_1X24:
>> +
[[RFC]DPU PATCH 0/4] Add suppport for sn65dsi86 bridge chip and Innolux 2k edp panel driver
Changelog: v3 -> v4: Current patchset separates out eDP panel specific resources from sn65dsi86 bridge driver and creates a separate driver for the innloux edp panel. Now bridge driver check if any panel is attached or not to get the supported modes. If any panel is attached then query from panel driver to get the modes, or else probe the provided i2c adapter to read the modes from EDID. Removed hardcoding of bridge init sequence. With this patchset bridge driver now will program the init sequence based on the current mode set by drm framework. Current patchset is not tested on actual bridge chip/panel. Sandeep Panda (4): drm/bridge: add support for sn65dsi86 bridge driver dt-bindings: drm/bridge: Document sn65dsi86 bridge bindings drm/panel: add Innolux TV123WAM eDP panel driver dt-bindings: Add Innolux TV123WAM panel bindings .../bindings/display/bridge/ti,sn65dsi86.txt | 60 ++ .../display/panel/innolux,edp-2k-panel.txt | 21 + drivers/gpu/drm/bridge/ti-sn65dsi86.c | 742 + drivers/gpu/drm/panel/panel-innolux-tv123wam.c | 299 + 4 files changed, 1122 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt create mode 100644 Documentation/devicetree/bindings/display/panel/innolux,edp-2k-panel.txt create mode 100644 drivers/gpu/drm/bridge/ti-sn65dsi86.c create mode 100644 drivers/gpu/drm/panel/panel-innolux-tv123wam.c -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 6/6] drm/atmel-hlcdc: fix broken release date
On 2018-04-18 09:44, Boris Brezillon wrote:
> On Tue, 17 Apr 2018 15:10:52 +0200
> Peter Rosin wrote:
>
>> Bump the minor version while at it.
>>
>> Signed-off-by: Peter Rosin
>> ---
>> drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
>> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
>> index 8523c40fac94..aa48f287b5ca 100644
>> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
>> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
>> @@ -763,9 +763,9 @@ static struct drm_driver atmel_hlcdc_dc_driver = {
>> .fops = &fops,
>> .name = "atmel-hlcdc",
>> .desc = "Atmel HLCD Controller DRM",
>> -.date = "20141504",
>
> I guess I used DDMM format :-).
>
>> +.date = "20180409",
>> .major = 1,
>> -.minor = 0,
>> +.minor = 1,
>
> Don't know what the strategy is regarding date and minor version
> updates. I never had to update that before, so I guess it's not
> important to userspace anyway.
I have no clue what strategy should be employed. I assume it's
for easier communication when features are backported into stable
or distro kernels and users wonder what to expect or for easier
triage of bug reports or something?? Anyway, I don't really care,
the date just looked really odd. So feel free to only patch the
.date to 20140415 or whatever. I'll drop this patch.
Cheers,
Peter
>> };
>>
>> static int atmel_hlcdc_dc_drm_init(struct platform_device *pdev)
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [[RFC]DPU PATCH 1/4] drm/bridge: add support for sn65dsi86 bridge driver
On 2018-04-18 19:41, Sean Paul wrote:
On Wed, Apr 18, 2018 at 05:49:59PM +0530, Sandeep Panda wrote:
Add support for TI's sn65dsi86 dsi2edp bridge chip.
The chip converts DSI transmitted signal to eDP signal,
which is fed to the connected eDP panel.
This chip can be controlled via either i2c interface or
dsi interface. Currently in driver all the control registers
are being accessed through i2c interface only.
Also as of now HPD support has not been added to bridge
chip driver.
Signed-off-by: Sandeep Panda
---
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 742
++
1 file changed, 742 insertions(+)
create mode 100644 drivers/gpu/drm/bridge/ti-sn65dsi86.c
diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
new file mode 100644
index 000..c798f2f
--- /dev/null
+++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
@@ -0,0 +1,742 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
I have a hard time believing that you need all of these includes. Off
the top of
my head, you could probably remove types, kernel, init,
platform_device, delay,
drmP, drm_atomic, drm_crtc_helper. You could probably trim it even
further with
the help of your compiler. These should also be in alphabetical order.
+
+#define SN_BRIDGE_REVISION_ID 0x2
+
+/* Link Training specific registers */
+#define SN_DEVICE_REV_REG 0x08
+#define SN_REFCLK_FREQ_REG 0x0A
+#define SN_DSI_LANES_REG 0x10
+#define SN_DSIA_CLK_FREQ_REG 0x12
+#define SN_ENH_FRAME_REG 0x5A
+#define SN_SSC_CONFIG_REG 0x93
+#define SN_DATARATE_CONFIG_REG 0x94
+#define SN_PLL_ENABLE_REG 0x0D
+#define SN_SCRAMBLE_CONFIG_REG 0x95
+#define SN_AUX_WDATA0_REG 0x64
+#define SN_AUX_ADDR_19_16_REG 0x74
+#define SN_AUX_ADDR_15_8_REG 0x75
+#define SN_AUX_ADDR_7_0_REG0x76
+#define SN_AUX_LENGTH_REG 0x77
+#define SN_AUX_CMD_REG 0x78
+#define SN_ML_TX_MODE_REG 0x96
+#define SN_PAGE_SELECT_REG 0xFF
+#define SN_AUX_RDATA0_REG 0x79
+/* video config specific registers */
+#define SN_CHA_ACTIVE_LINE_LENGTH_LOW_REG 0x20
+#define SN_CHA_ACTIVE_LINE_LENGTH_HIGH_REG 0x21
+#define SN_CHA_VERTICAL_DISPLAY_SIZE_LOW_REG 0x24
+#define SN_CHA_VERTICAL_DISPLAY_SIZE_HIGH_REG 0x25
+#define SN_CHA_HSYNC_PULSE_WIDTH_LOW_REG 0x2C
+#define SN_CHA_HSYNC_PULSE_WIDTH_HIGH_REG 0x2D
+#define SN_CHA_VSYNC_PULSE_WIDTH_LOW_REG 0x30
+#define SN_CHA_VSYNC_PULSE_WIDTH_HIGH_REG 0x31
+#define SN_CHA_HORIZONTAL_BACK_PORCH_REG 0x34
+#define SN_CHA_VERTICAL_BACK_PORCH_REG 0x36
+#define SN_CHA_HORIZONTAL_FRONT_PORCH_REG 0x38
+#define SN_CHA_VERTICAL_FRONT_PORCH_REG0x3A
+#define SN_DATA_FORMAT_REG 0x5B
+#define SN_COLOR_BAR_CONFIG_REG0x3C
+
+#define DPPLL_CLK_SRC_REFCLK 0
+#define DPPLL_CLK_SRC_DSICLK 1
+#define MIN_DSI_CLK_FREQ_MHZ 40
+
+enum ti_sn_bridge_ref_clks {
+ SN_REF_CLK_12_MHZ = 0,
+ SN_REF_CLK_19_2_MHZ,
+ SN_REF_CLK_26_MHZ,
+ SN_REF_CLK_27_MHZ,
+ SN_REF_CLK_38_4_MHZ,
+ SN_REF_CLK_MAX,
+};
+
+struct ti_sn_bridge {
+ struct device *dev;
+ struct drm_bridge bridge;
+ struct drm_connector connector;
+ struct device_node *host_node;
+ struct mipi_dsi_device *dsi;
+ /* handle to the connected eDP panel */
+ struct drm_panel *panel;
+ int irq;
+ struct gpio_desc *irq_gpio;
+ /* list of gpios needed to enable the bridge functionality */
+ struct gpio_descs *enable_gpios;
Why are the enable gpios a list?
This as per the review comment in previous patchset
"I see IRQ and EN in the datasheet, but not the others. It seems like
the aux_*
and edp_* gpios are always equal to en. So if you actually need them,
don't
specify a new struct, just add irq_gpio to the main struct and add an
array of
en_gpios to handle the rest."
I see in schematic 2 more gpios are needed to enable aux_channel
communication
through the ddc. So i have put an array of enable gpios. Based on dt it
will dynamically
parse one or more gpios.
+ unsigned int num_supplies;
+ struct regulator_bulk_data *supplies;
+ struct i2c_client *i2c_client;
+ struct i2c_adapter *ddc;
+ bool power_on;
+ u32 num_modes;
+ struct drm_display_mode curr_mode;
+};
+
+static int ti_sn_bridge_write(struct ti_sn_bridge *pdata, u8 reg, u8
val)
+{
+ struct i2c_client *client = pdata->i2c_client;
Re: [Xen-devel] [PATCH 0/1] drm/xen-zcopy: Add Xen zero-copy helper DRM driver
On Wed, Apr 18, 2018 at 09:38:39AM +0300, Oleksandr Andrushchenko wrote: > On 04/17/2018 11:57 PM, Dongwon Kim wrote: > > On Tue, Apr 17, 2018 at 09:59:28AM +0200, Daniel Vetter wrote: > > > On Mon, Apr 16, 2018 at 12:29:05PM -0700, Dongwon Kim wrote: > 3.2 Backend exports dma-buf to xen-front > > In this case Dom0 pages are shared with DomU. As before, DomU can only write > to these pages, not any other page from Dom0, so it can be still considered > safe. > But, the following must be considered (highlighted in xen-front's Kernel > documentation): > - If guest domain dies then pages/grants received from the backend cannot > be claimed back - think of it as memory lost to Dom0 (won't be used for > any > other guest) > - Misbehaving guest may send too many requests to the backend exhausting > its grant references and memory (consider this from security POV). As the > backend runs in the trusted domain we also assume that it is trusted as > well, > e.g. must take measures to prevent DDoS attacks. I cannot parse the above sentence: "As the backend runs in the trusted domain we also assume that it is trusted as well, e.g. must take measures to prevent DDoS attacks." What's the relation between being trusted and protecting from DoS attacks? In any case, all? PV protocols are implemented with the frontend sharing pages to the backend, and I think there's a reason why this model is used, and it should continue to be used. Having to add logic in the backend to prevent such attacks means that: - We need more code in the backend, which increases complexity and chances of bugs. - Such code/logic could be wrong, thus allowing DoS. > 4. xen-front/backend/xen-zcopy synchronization > > 4.1. As I already said in 2) all the inter VM communication happens between > xen-front and the backend, xen-zcopy is NOT involved in that. > When xen-front wants to destroy a display buffer (dumb/dma-buf) it issues a > XENDISPL_OP_DBUF_DESTROY command (opposite to XENDISPL_OP_DBUF_CREATE). > This call is synchronous, so xen-front expects that backend does free the > buffer pages on return. > > 4.2. Backend, on XENDISPL_OP_DBUF_DESTROY: > - closes all dumb handles/fd's of the buffer according to [3] > - issues DRM_IOCTL_XEN_ZCOPY_DUMB_WAIT_FREE IOCTL to xen-zcopy to make > sure > the buffer is freed (think of it as it waits for dma-buf->release > callback) So this zcopy thing keeps some kind of track of the memory usage? Why can't the user-space backend keep track of the buffer usage? > - replies to xen-front that the buffer can be destroyed. > This way deletion of the buffer happens synchronously on both Dom0 and DomU > sides. In case if DRM_IOCTL_XEN_ZCOPY_DUMB_WAIT_FREE returns with time-out > error > (BTW, wait time is a parameter of this IOCTL), Xen will defer grant > reference > removal and will retry later until those are free. > > Hope this helps understand how buffers are synchronously deleted in case > of xen-zcopy with a single protocol command. > > I think the above logic can also be re-used by the hyper-dmabuf driver with > some additional work: > > 1. xen-zcopy can be split into 2 parts and extend: > 1.1. Xen gntdev driver [4], [5] to allow creating dma-buf from grefs and > vise versa, I don't know much about the dma-buf implementation in Linux, but gntdev is a user-space device, and AFAICT user-space applications don't have any notion of dma buffers. How are such buffers useful for user-space? Why can't this just be called memory? Also, (with my FreeBSD maintainer hat) how is this going to translate to other OSes? So far the operations performed by the gntdev device are mostly OS-agnostic because this just map/unmap memory, and in fact they are implemented by Linux and FreeBSD. > implement "wait" ioctl (wait for dma-buf->release): currently these are > DRM_XEN_ZCOPY_DUMB_FROM_REFS, DRM_XEN_ZCOPY_DUMB_TO_REFS and > DRM_XEN_ZCOPY_DUMB_WAIT_FREE > 1.2. Xen balloon driver [6] to allow allocating contiguous buffers (not > needed > by current hyper-dmabuf, but is a must for xen-zcopy use-cases) I think this needs clarifying. In which memory space do you need those regions to be contiguous? Do they need to be contiguous in host physical memory, or guest physical memory? If it's in guest memory space, isn't there any generic interface that you can use? If it's in host physical memory space, why do you need this buffer to be contiguous in host physical memory space? The IOMMU should hide all this. Thanks, Roger. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: GPU/DRM issue with DSI commands on msm 8916
On Wednesday, April 18, 2018 10:06 AM, Archit Taneja wrote: > On Tuesday 17 April 2018 05:51 PM, Daniel Mack wrote: > Thanks for debugging this so thoroughly. > >> It shows an underlying problem in the msm driver's clock components >> though, because without this patch, the clocks will be effectively >> slightly off from what was requested. For instance, when >> gcc_mdss_byte0_clk is configured to 5625 Hz by the msm drm driver, >> the clk core will let the DSI PLL recalculate its actual rate which is >> 56246337 Hz. Hence, clk_set_rate() will always end up fiddling with the >> knobs of that clock provider. That's what happens every time DSI >> commands are sent, and that causes the image to flicker. > > If I understood right, the main cause of the flicker is that we always > end up re-locking/reconfiguring the DSI PLL every time we send a command > (since dsi_link_clk_enable() is called in msm_dsi_host_xfer_prepare())? > The re-configuration results in a glitch on the DSI clock, which is > probably unacceptable for DSI Video mode transfer, especially for panels > that don't have their own timing generators, which rely entirely on > DSI clock lanes for scanning out the pixel data. > > According to you, the reason why the reconfiguration happens is because > the DSI PLL was never set exactly to 56.25 Mhz in the first place, and > the core clock framework notices a difference in the requested rate and > the current rate (56.246 Mhz), and goes ahead to configure the PLL > again when it's not needed. And this was averted in the downstream > patch you mentioned as a side affect? Yes, exactly. >> The same problem applies to other clocks too. dsi0vco_clk for example >> will be 449970703 rather than the requested 45000 etc. >> > > One easy way to get around this would be to not try to set the clock > rates every time we try to send a command. We just enable/disable them. Yes, that could work as well, but how about rounding the rates in the callback that exists for that purpose? We're off by a fraction of a permille only, after all. Thanks, Daniel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [Xen-devel] [PATCH 0/1] drm/xen-zcopy: Add Xen zero-copy helper DRM driver
> -Original Message- > From: Oleksandr Andrushchenko [mailto:andr2...@gmail.com] > Sent: 18 April 2018 11:21 > To: Paul Durrant ; Roger Pau Monne > > Cc: jgr...@suse.com; Artem Mygaiev ; > Dongwon Kim ; airl...@linux.ie; > oleksandr_andrushche...@epam.com; linux-ker...@vger.kernel.org; dri- > de...@lists.freedesktop.org; Potrola, MateuszX > ; xen-de...@lists.xenproject.org; > daniel.vet...@intel.com; boris.ostrov...@oracle.com; Matt Roper > > Subject: Re: [Xen-devel] [PATCH 0/1] drm/xen-zcopy: Add Xen zero-copy > helper DRM driver > > On 04/18/2018 01:18 PM, Paul Durrant wrote: > >> -Original Message- > >> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On > Behalf > >> Of Roger Pau Monné > >> Sent: 18 April 2018 11:11 > >> To: Oleksandr Andrushchenko > >> Cc: jgr...@suse.com; Artem Mygaiev ; > >> Dongwon Kim ; airl...@linux.ie; > >> oleksandr_andrushche...@epam.com; linux-ker...@vger.kernel.org; > dri- > >> de...@lists.freedesktop.org; Potrola, MateuszX > >> ; xen-de...@lists.xenproject.org; > >> daniel.vet...@intel.com; boris.ostrov...@oracle.com; Matt Roper > >> > >> Subject: Re: [Xen-devel] [PATCH 0/1] drm/xen-zcopy: Add Xen zero-copy > >> helper DRM driver > >> > >> On Wed, Apr 18, 2018 at 11:01:12AM +0300, Oleksandr Andrushchenko > >> wrote: > >>> On 04/18/2018 10:35 AM, Roger Pau Monné wrote: > On Wed, Apr 18, 2018 at 09:38:39AM +0300, Oleksandr Andrushchenko > >> wrote: > > On 04/17/2018 11:57 PM, Dongwon Kim wrote: > >> On Tue, Apr 17, 2018 at 09:59:28AM +0200, Daniel Vetter wrote: > >>> On Mon, Apr 16, 2018 at 12:29:05PM -0700, Dongwon Kim wrote: > > 3.2 Backend exports dma-buf to xen-front > > > > In this case Dom0 pages are shared with DomU. As before, DomU can > >> only write > > to these pages, not any other page from Dom0, so it can be still > >> considered > > safe. > > But, the following must be considered (highlighted in xen-front's > Kernel > > documentation): > > - If guest domain dies then pages/grants received from the backend > >> cannot > > be claimed back - think of it as memory lost to Dom0 (won't be used > >> for > > any > > other guest) > > - Misbehaving guest may send too many requests to the backend > >> exhausting > > its grant references and memory (consider this from security POV). > >> As the > > backend runs in the trusted domain we also assume that it is > trusted > >> as > > well, > > e.g. must take measures to prevent DDoS attacks. > I cannot parse the above sentence: > > "As the backend runs in the trusted domain we also assume that it is > trusted as well, e.g. must take measures to prevent DDoS attacks." > > What's the relation between being trusted and protecting from DoS > attacks? > >>> I mean that we trust the backend that it can prevent Dom0 > >>> from crashing in case DomU's frontend misbehaves, e.g. > >>> if the frontend sends too many memory requests etc. > In any case, all? PV protocols are implemented with the frontend > sharing pages to the backend, and I think there's a reason why this > model is used, and it should continue to be used. > >>> This is the first use-case above. But there are real-world > >>> use-cases (embedded in my case) when physically contiguous memory > >>> needs to be shared, one of the possible ways to achieve this is > >>> to share contiguous memory from Dom0 to DomU (the second use-case > >> above) > Having to add logic in the backend to prevent such attacks means > that: > > - We need more code in the backend, which increases complexity and > chances of bugs. > - Such code/logic could be wrong, thus allowing DoS. > >>> You can live without this code at all, but this is then up to > >>> backend which may make Dom0 down because of DomU's frontend > doing > >> evil > >>> things > >> IMO we should design protocols that do not allow such attacks instead > >> of having to defend against them. > >> > > 4. xen-front/backend/xen-zcopy synchronization > > > > 4.1. As I already said in 2) all the inter VM communication happens > >> between > > xen-front and the backend, xen-zcopy is NOT involved in that. > > When xen-front wants to destroy a display buffer (dumb/dma-buf) it > >> issues a > > XENDISPL_OP_DBUF_DESTROY command (opposite to > >> XENDISPL_OP_DBUF_CREATE). > > This call is synchronous, so xen-front expects that backend does free > >> the > > buffer pages on return. > > > > 4.2. Backend, on XENDISPL_OP_DBUF_DESTROY: > > - closes all dumb handles/fd's of the buffer according to [3] > > - issues DRM_IOCTL_XEN_ZCOPY_DUMB_WAIT_FREE IOCTL to xen- > >> zcopy to make > > sure > > the buffer is freed (think of it as it waits for dma-buf->release > > callback) > So this zcopy thing keeps some kind of track of the memory usage?
Re: [[RFC]DPU PATCH 2/4] dt-bindings: drm/bridge: Document sn65dsi86 bridge bindings
On 2018-04-18 19:28, Sean Paul wrote:
On Wed, Apr 18, 2018 at 05:50:00PM +0530, Sandeep Panda wrote:
Document the bindings used for the sn65dsi86 DSI to eDP bridge.
Please add a changelog to your patches so reviewers know what has
changed
between patch versions.
I will update the change log in the commit text of the patches.
Signed-off-by: Sandeep Panda
---
.../bindings/display/bridge/ti,sn65dsi86.txt | 60
++
1 file changed, 60 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt
diff --git
a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt
b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt
new file mode 100644
index 000..9e2612e
--- /dev/null
+++
b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt
@@ -0,0 +1,60 @@
+SN65DSI86 DSI to eDP bridge chip
+
+
+This is the binding for Texas Instruments SN65DSI86 bridge.
+
+Required properties:
+- compatible: Must be "ti,sn65dsi86"
+- reg: i2c address of the chip, 0x2d as per datasheet
+- enable-gpios: OF device-tree gpio specifications for bridge_en pin
The datasheet only has one enable pin, why gpios?
This is the convention followed by other bridge drivers also.
https://www.kernel.org/doc/Documentation/devicetree/bindings/gpio/gpio.txt
please the example mentioned here,
Example of a node using GPIOs:
node {
enable-gpios = <&qe_pio_e 18 GPIO_ACTIVE_HIGH>;
};
+
+- vccio-supply: A 1.8V supply that powers up the digital IOs.
+- vcca-supply: A 1.2V supply that powers up the analog circuits.
+
+Optional properties:
+
+- irq-gpios: OF device-tree gpio specification for interrupt pin
From the last review, Rob said, 'Use "interrupts" property instead.'
You didn't provide responses to prior review comments, so it's unclear
whether
you've intentionally or unintentionally ignored him :)
Sorry missed it completely while addressing other review comments.
Sean
+
+Required nodes:
+
+This device has two video ports. Their connections are modelled using
the
+OF graph bindings specified in
Documentation/devicetree/bindings/graph.txt.
+
+- Video port 0 for DSI input
+- Video port 1 for eDP output
+
+Example
+---
+
+edp-bridge@2d {
+ compatible = "ti,sn65dsi86";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x2d>;
+
+ enable-gpios = <&msmgpio 33 GPIO_ACTIVE_HIGH>;
+
+ vccio-supply = <&pm8916_l17>;
+ vcca-supply = <&pm8916_l6>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ edp_bridge_in: endpoint {
+ remote-endpoint = <&dsi_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ edp_bridge_out: endpoint {
+ remote-endpoint = <&edp_panel_in>;
+ };
+ };
+ };
+}
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [[RFC]DPU PATCH 1/4] drm/bridge: add support for sn65dsi86 bridge driver
On 2018-04-18 19:41, Sean Paul wrote:
On Wed, Apr 18, 2018 at 05:49:59PM +0530, Sandeep Panda wrote:
Add support for TI's sn65dsi86 dsi2edp bridge chip.
The chip converts DSI transmitted signal to eDP signal,
which is fed to the connected eDP panel.
This chip can be controlled via either i2c interface or
dsi interface. Currently in driver all the control registers
are being accessed through i2c interface only.
Also as of now HPD support has not been added to bridge
chip driver.
Signed-off-by: Sandeep Panda
---
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 742
++
1 file changed, 742 insertions(+)
create mode 100644 drivers/gpu/drm/bridge/ti-sn65dsi86.c
diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
new file mode 100644
index 000..c798f2f
--- /dev/null
+++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
@@ -0,0 +1,742 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
I have a hard time believing that you need all of these includes. Off
the top of
my head, you could probably remove types, kernel, init,
platform_device, delay,
drmP, drm_atomic, drm_crtc_helper. You could probably trim it even
further with
the help of your compiler. These should also be in alphabetical order.
I will take care of alphabetical order and generic kernel header file
inclusion. But the header files of
drmP, drm_atomic, drm_crtc_helper are required here.
drmP, drm_atomic, drm_crtc_helper all these are needed because of the
drm api that we using in this driver
for modes, connectors and bridges. the drm header files i have already
checked with compiler.
+
+#define SN_BRIDGE_REVISION_ID 0x2
+
+/* Link Training specific registers */
+#define SN_DEVICE_REV_REG 0x08
+#define SN_REFCLK_FREQ_REG 0x0A
+#define SN_DSI_LANES_REG 0x10
+#define SN_DSIA_CLK_FREQ_REG 0x12
+#define SN_ENH_FRAME_REG 0x5A
+#define SN_SSC_CONFIG_REG 0x93
+#define SN_DATARATE_CONFIG_REG 0x94
+#define SN_PLL_ENABLE_REG 0x0D
+#define SN_SCRAMBLE_CONFIG_REG 0x95
+#define SN_AUX_WDATA0_REG 0x64
+#define SN_AUX_ADDR_19_16_REG 0x74
+#define SN_AUX_ADDR_15_8_REG 0x75
+#define SN_AUX_ADDR_7_0_REG0x76
+#define SN_AUX_LENGTH_REG 0x77
+#define SN_AUX_CMD_REG 0x78
+#define SN_ML_TX_MODE_REG 0x96
+#define SN_PAGE_SELECT_REG 0xFF
+#define SN_AUX_RDATA0_REG 0x79
+/* video config specific registers */
+#define SN_CHA_ACTIVE_LINE_LENGTH_LOW_REG 0x20
+#define SN_CHA_ACTIVE_LINE_LENGTH_HIGH_REG 0x21
+#define SN_CHA_VERTICAL_DISPLAY_SIZE_LOW_REG 0x24
+#define SN_CHA_VERTICAL_DISPLAY_SIZE_HIGH_REG 0x25
+#define SN_CHA_HSYNC_PULSE_WIDTH_LOW_REG 0x2C
+#define SN_CHA_HSYNC_PULSE_WIDTH_HIGH_REG 0x2D
+#define SN_CHA_VSYNC_PULSE_WIDTH_LOW_REG 0x30
+#define SN_CHA_VSYNC_PULSE_WIDTH_HIGH_REG 0x31
+#define SN_CHA_HORIZONTAL_BACK_PORCH_REG 0x34
+#define SN_CHA_VERTICAL_BACK_PORCH_REG 0x36
+#define SN_CHA_HORIZONTAL_FRONT_PORCH_REG 0x38
+#define SN_CHA_VERTICAL_FRONT_PORCH_REG0x3A
+#define SN_DATA_FORMAT_REG 0x5B
+#define SN_COLOR_BAR_CONFIG_REG0x3C
+
+#define DPPLL_CLK_SRC_REFCLK 0
+#define DPPLL_CLK_SRC_DSICLK 1
+#define MIN_DSI_CLK_FREQ_MHZ 40
+
+enum ti_sn_bridge_ref_clks {
+ SN_REF_CLK_12_MHZ = 0,
+ SN_REF_CLK_19_2_MHZ,
+ SN_REF_CLK_26_MHZ,
+ SN_REF_CLK_27_MHZ,
+ SN_REF_CLK_38_4_MHZ,
+ SN_REF_CLK_MAX,
+};
+
+struct ti_sn_bridge {
+ struct device *dev;
+ struct drm_bridge bridge;
+ struct drm_connector connector;
+ struct device_node *host_node;
+ struct mipi_dsi_device *dsi;
+ /* handle to the connected eDP panel */
+ struct drm_panel *panel;
+ int irq;
+ struct gpio_desc *irq_gpio;
+ /* list of gpios needed to enable the bridge functionality */
+ struct gpio_descs *enable_gpios;
Why are the enable gpios a list?
+ unsigned int num_supplies;
+ struct regulator_bulk_data *supplies;
+ struct i2c_client *i2c_client;
+ struct i2c_adapter *ddc;
+ bool power_on;
+ u32 num_modes;
+ struct drm_display_mode curr_mode;
+};
+
+static int ti_sn_bridge_write(struct ti_sn_bridge *pdata, u8 reg, u8
val)
+{
+ struct i2c_client *client = pdata->i2c_client;
+ u8 buf[2] = {reg, val};
+ struct i2c_msg msg = {
+ .addr = client->addr,
+ .flags = 0,
+ .len = 2,
Re: [Freedreno] [DPU PATCH v2 2/2] drm/panel: add backlight control support for truly panel
On Tue 17 Apr 17:42 PDT 2018, abhin...@codeaurora.org wrote: > Adding another point. > > On 2018-04-17 17:04, abhin...@codeaurora.org wrote: > > Hi Bjorn > > > > Apologies if the prev reply wasnt clear. > > > > Hope this one is. > > > > reply inline. > > > > On 2018-04-17 14:29, Bjorn Andersson wrote: > > > On Tue 17 Apr 11:21 PDT 2018, abhin...@codeaurora.org wrote: > > > > On 2018-04-16 23:13, Bjorn Andersson wrote: > > > [..] > > > > > If the panel isn't actually a piece of backlight hardware then it > > > > > should > > > > > not register a backlight device. Why do you need your own sysfs? > > > > > > > > > > Regards, > > > > > Bjorn > > > > [Abhinav] This particular panel isnt a piece of backlight hardware. > > > > But, we want to have our own sysfs to give flexibility to our > > > > userspace > > > > to write and read stuff for its proprietary uses. > > > > > > Please be more specific in your replies, no one will accept code that > > > "does stuff" and expecting a reviewer to spend time guessing or > > > pulling > > > the information out of you is a sure way to get your patches ignored. > > > > > > Exactly what kind of stuff are you talking about here and exactly > > > which > > > problem are you solving. > > > > > > > Thats how our downstream has been working so far and hence to > > > > maintain > > > > the compatibility would like to have it. > > > > > > Make your proprietary code work with the upstream kernel and you > > > shouldn't ever have to modify it. > > > > > > Regards, > > > Bjorn > > > > [Abhinav] We have a few userspace clients today for the backlight sysfs > > node > > which read/write directly to > > "/sys/class/backlight/panel0-backlight/brightness" > > When I said "stuff" I was only referring to the brightness value. > > This separate sysfs node allows us to validate those userspace features > > of ours > > which directly edit the backlight value on our reference platform. > > Since our reference platform uses this panel,hence having our own > > sysfs alias helps. > > Otherwise, whenever we try to use this panel with upstream code we > > will have to end up > > changing all those places in our userspace/framework to change the sysfs > > path. > > Hence we wanted to preserve that sysfs node name. > > The wled device is not created under /sys/class/backlight but under > > /sys/class/leds/wled. > > So we will have to change the name of this node across all our > > userspace. > > > > If this isnt a convincing reason enough to have its own sysfs node > > path, I will use > > your approach. > > > > Let me know your comments or if this is still not clear. > > > [Abhinav] We also might not be using the brightness value "as-it-is". > > We will potentially scale it up/down based on some requirements. > > If we do not have our own sysfs alias for this, how do we account for > providing this interface for our chipset specific backlight dependent > feature. > > Can you please comment on this? > What kind of requirements would this be and what do you mean with scale it up/down? As the current implementation is proposed any magic added on top would work for this panel driver and wouldn't be available for any other panel, which doesn't sounds optimal. Regards, Bjorn ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 5/6] drm/atmel-hlcdc: add support for connecting to tda998x HDMI encoder
On 2018-04-18 09:36, Boris Brezillon wrote: > On Tue, 17 Apr 2018 15:10:51 +0200 > Peter Rosin wrote: > >> When the of-graph points to a tda998x-compatible HDMI encoder, register >> as a component master and bind to the encoder/connector provided by >> the tda998x driver. > > Can't we do the opposite: make the tda998x driver expose its devices as > drm bridges. I'd rather not add another way to connect external > encoders (or bridges) to display controller drivers, especially since, > when I asked DRM maintainers/devs what was the good approach to > represent such external encoders they pointed me to the drm_bridge > interface. From the cover letter: "However, I don't know if the tilcdc driver is interfacing with the tda998x driver in a sane and modern way" So, which way is the future? Should bridges become components or should existing bridge-like components no longer be components? Are there others? Cheers, Peter ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Freedreno] [DPU PATCH v2 2/2] drm/panel: add backlight control support for truly panel
On Tue 17 Apr 17:04 PDT 2018, abhin...@codeaurora.org wrote: > Hi Bjorn > > Apologies if the prev reply wasnt clear. > > Hope this one is. > Much better, now we can discuss the actual issues :) > reply inline. > > On 2018-04-17 14:29, Bjorn Andersson wrote: > > On Tue 17 Apr 11:21 PDT 2018, abhin...@codeaurora.org wrote: > > > On 2018-04-16 23:13, Bjorn Andersson wrote: > > [..] > > > > If the panel isn't actually a piece of backlight hardware then it should > > > > not register a backlight device. Why do you need your own sysfs? > > > > > > > > Regards, > > > > Bjorn > > > [Abhinav] This particular panel isnt a piece of backlight hardware. > > > But, we want to have our own sysfs to give flexibility to our > > > userspace > > > to write and read stuff for its proprietary uses. > > > > Please be more specific in your replies, no one will accept code that > > "does stuff" and expecting a reviewer to spend time guessing or pulling > > the information out of you is a sure way to get your patches ignored. > > > > Exactly what kind of stuff are you talking about here and exactly which > > problem are you solving. > > > > > Thats how our downstream has been working so far and hence to maintain > > > the compatibility would like to have it. > > > > Make your proprietary code work with the upstream kernel and you > > shouldn't ever have to modify it. > > > > Regards, > > Bjorn > > [Abhinav] We have a few userspace clients today for the backlight sysfs node > which read/write directly to > "/sys/class/backlight/panel0-backlight/brightness" > When I said "stuff" I was only referring to the brightness value. > This separate sysfs node allows us to validate those userspace > features of ours which directly edit the backlight value on our > reference platform. That's nice, but you're enforcing that either all panel drivers must implement this backlight wrapper or that your customers must modify their user space to match their backlight implementation. > Since our reference platform uses this panel,hence having our own > sysfs alias helps. Otherwise, whenever we try to use this panel with > upstream code we will have to end up changing all those places in our > userspace/framework to change the sysfs path. The actual problem comes down to "how does user space know the name of the backlight instance associated with the panel" and this is a valid question to pursue. But given your current design you could just scan for the one and only backlight device available in the system; as your use of the static name "panel0-backlight" doesn't allow multiple backlights anyway. If your goal is simply to ship your reference with something that you can show work, then just replace the hard coded panel0-backlight with the name of the wled backlight device. Customers can change panels as they wish, but in the event that they plug in a different backlight controller they would need to modify the code. > Hence we wanted to preserve that sysfs node name. > The wled device is not created under /sys/class/backlight but under > /sys/class/leds/wled. > So we will have to change the name of this node across all our userspace. > Hard coding /sys/class/backlight/panel0-backlight in your user space instead of /sys/class/leds/wled is hardly a gain, in particular since the cost is 94 insertions - per panel driver. Regards, Bjorn ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/6] dt-bindings: display: atmel: optional video-interface of endpoints
On 2018-04-18 09:16, Boris Brezillon wrote:
> Hi Peter,
>
> On Tue, 17 Apr 2018 15:10:48 +0200
> Peter Rosin wrote:
>
>> With bus-type/bus-width properties in the endpoint nodes, the video-
>> interface of the connection can be specified for cases where the
>> heuristic fails to select the correct output mode. This can happen
>> e.g. if not all RGB pins are routed on the PCB; the driver has no
>> way of knowing this, and needs to be told explicitly.
>>
>> This is critical for the devices that have the "conflicting output
>> formats" issue (SAM9N12, SAM9X5, SAMA5D3), since the most significant
>> RGB bits move around depending on the selected output mode. For
>> devices that do not have the "conflicting output formats" issue
>> (SAMA5D2, SAMA5D4), this is completely irrelevant.
>>
>> Signed-off-by: Peter Rosin
>> ---
>> Documentation/devicetree/bindings/display/atmel/hlcdc-dc.txt | 8
>> 1 file changed, 8 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/display/atmel/hlcdc-dc.txt
>> b/Documentation/devicetree/bindings/display/atmel/hlcdc-dc.txt
>> index 82f2acb3d374..244b48869eb4 100644
>> --- a/Documentation/devicetree/bindings/display/atmel/hlcdc-dc.txt
>> +++ b/Documentation/devicetree/bindings/display/atmel/hlcdc-dc.txt
>> @@ -15,6 +15,14 @@ Required children nodes:
>> to external devices using the OF graph reprensentation (see ../graph.txt).
>> At least one port node is required.
>>
>> +Optional properties in grandchild nodes:
>> + Any endpoint grandchild node may specify a desired video interface
>> + according to ../../media/video-interfaces.txt, specifically
>> + - bus-type: must be <0>.
>> + - bus-width: recognized values are <12>, <16>, <18> and <24>, and
>> + override any output mode selection hueristic, forcing "rgb444",
heuristic, I'll fix that for v3, so please review as if it wasn't there...
>> + "rgb565", "rgb666" and "rgb888" respectively.
>> +
>
> Can you add an example or update the existing one to show how this
> should be defined?
For v3, I'll extend the binding with this after the preexisting example:
--8<-
Example 2: With a video interface override to force rgb565, as above
but with these changes/additions:
&hlcdc {
hlcdc-display-controller {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_lcd_base &pinctrl_lcd_rgb565>;
port@0 {
hlcdc_panel_output: endpoint@0 {
bus-type = <0>;
bus-width = <16>;
};
};
};
};
--8<-
Is that a good plan, or should I perhaps duplicate the whole example?
Cheers,
Peter
>> Example:
>>
>> hlcdc: hlcdc@f003 {
>
>
> Thanks,
>
> Boris
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[[RFC]DPU PATCH 4/4] dt-bindings: Add Innolux TV123WAM panel bindings
The Innolux TV123WAM is a 12.3" eDP display panel
with 2160x1440 resolution.
Signed-off-by: Sandeep Panda
---
.../bindings/display/panel/innolux,edp-2k-panel.txt | 21 +
1 file changed, 21 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/innolux,edp-2k-panel.txt
diff --git
a/Documentation/devicetree/bindings/display/panel/innolux,edp-2k-panel.txt
b/Documentation/devicetree/bindings/display/panel/innolux,edp-2k-panel.txt
new file mode 100644
index 000..19f271c
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/innolux,edp-2k-panel.txt
@@ -0,0 +1,21 @@
+Innolux TV123WAM 12.3 inch eDP display panel
+
+Required properties:
+- power-supply: regulator to provide the supply voltage
+- enable-gpios: GPIO pin to enable or disable the panel
+
+Optional properties:
+- backlight: phandle of the backlight device attached to the panel
+
+Example:
+
+ edp_panel: edp_panel {
+ compatible = "innolux, edp_2k_panel";
+ reg = <0>;
+
+ enable-gpios = <&msmgpio 32 GPIO_ACTIVE_HIGH>;
+
+ power-supply = <&pm8916_l8>;
+
+ backlight = <&backlight>;
+ };
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [[RFC]DPU PATCH 0/4] Add suppport for sn65dsi86 bridge chip and Innolux 2k edp panel driver
On 2018-04-18 19:42, Sean Paul wrote: On Wed, Apr 18, 2018 at 05:49:58PM +0530, Sandeep Panda wrote: Changelog: v3 -> v4: I didn't really bother to do a thorough review given that there are obvious mistakes and ignored feedback, it's a waste of time, tbh. Please go through the previous reviews and resend a more polished version. I have replied to your review comments. Please review the edp driver, so that i can address all the comments together while uploading next patchset. Sean Current patchset separates out eDP panel specific resources from sn65dsi86 bridge driver and creates a separate driver for the innloux edp panel. Now bridge driver check if any panel is attached or not to get the supported modes. If any panel is attached then query from panel driver to get the modes, or else probe the provided i2c adapter to read the modes from EDID. Removed hardcoding of bridge init sequence. With this patchset bridge driver now will program the init sequence based on the current mode set by drm framework. Current patchset is not tested on actual bridge chip/panel. Sandeep Panda (4): drm/bridge: add support for sn65dsi86 bridge driver dt-bindings: drm/bridge: Document sn65dsi86 bridge bindings drm/panel: add Innolux TV123WAM eDP panel driver dt-bindings: Add Innolux TV123WAM panel bindings .../bindings/display/bridge/ti,sn65dsi86.txt | 60 ++ .../display/panel/innolux,edp-2k-panel.txt | 21 + drivers/gpu/drm/bridge/ti-sn65dsi86.c | 742 + drivers/gpu/drm/panel/panel-innolux-tv123wam.c | 299 + 4 files changed, 1122 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt create mode 100644 Documentation/devicetree/bindings/display/panel/innolux,edp-2k-panel.txt create mode 100644 drivers/gpu/drm/bridge/ti-sn65dsi86.c create mode 100644 drivers/gpu/drm/panel/panel-innolux-tv123wam.c -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v9 1/2] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder
Document Thine THC63LVD1024 LVDS decoder device tree bindings.
Signed-off-by: Jacopo Mondi
Reviewed-by: Andrzej Hajda
Reviewed-by: Niklas Söderlund
Reviewed-by: Laurent Pinchart
Reviewed-by: Rob Herring
---
.../bindings/display/bridge/thine,thc63lvd1024.txt | 60 ++
1 file changed, 60 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
diff --git
a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
new file mode 100644
index 000..37f0c04
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
@@ -0,0 +1,60 @@
+Thine Electronics THC63LVD1024 LVDS decoder
+---
+
+The THC63LVD1024 is a dual link LVDS receiver designed to convert LVDS streams
+to parallel data outputs. The chip supports single/dual input/output modes,
+handling up to two LVDS input streams and up to two digital CMOS/TTL outputs.
+
+Single or dual operation mode, output data mapping and DDR output modes are
+configured through input signals and the chip does not expose any control bus.
+
+Required properties:
+- compatible: Shall be "thine,thc63lvd1024"
+- vcc-supply: Power supply for TTL output, TTL CLOCKOUT signal, LVDS input,
+ PPL and digital circuitry
+
+Optional properties:
+- powerdown-gpios: Power down GPIO signal, pin name "/PDWN". Active low
+- oe-gpios: Output enable GPIO signal, pin name "OE". Active high
+
+The THC63LVD1024 video port connections are modeled according
+to OF graph bindings specified by Documentation/devicetree/bindings/graph.txt
+
+Required video port nodes:
+- port@0: First LVDS input port
+- port@2: First digital CMOS/TTL parallel output
+
+Optional video port nodes:
+- port@1: Second LVDS input port
+- port@3: Second digital CMOS/TTL parallel output
+
+Example:
+
+
+ thc63lvd1024: lvds-decoder {
+ compatible = "thine,thc63lvd1024";
+
+ vcc-supply = <®_lvds_vcc>;
+ powerdown-gpios = <&gpio4 15 GPIO_ACTIVE_LOW>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ lvds_dec_in_0: endpoint {
+ remote-endpoint = <&lvds_out>;
+ };
+ };
+
+ port@2{
+ reg = <2>;
+
+ lvds_dec_out_2: endpoint {
+ remote-endpoint = <&adv7511_in>;
+ };
+ };
+ };
+ };
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[[RFC]DPU PATCH 2/4] dt-bindings: drm/bridge: Document sn65dsi86 bridge bindings
Document the bindings used for the sn65dsi86 DSI to eDP bridge.
Signed-off-by: Sandeep Panda
---
.../bindings/display/bridge/ti,sn65dsi86.txt | 60 ++
1 file changed, 60 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt
diff --git a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt
b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt
new file mode 100644
index 000..9e2612e
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt
@@ -0,0 +1,60 @@
+SN65DSI86 DSI to eDP bridge chip
+
+
+This is the binding for Texas Instruments SN65DSI86 bridge.
+
+Required properties:
+- compatible: Must be "ti,sn65dsi86"
+- reg: i2c address of the chip, 0x2d as per datasheet
+- enable-gpios: OF device-tree gpio specifications for bridge_en pin
+
+- vccio-supply: A 1.8V supply that powers up the digital IOs.
+- vcca-supply: A 1.2V supply that powers up the analog circuits.
+
+Optional properties:
+
+- irq-gpios: OF device-tree gpio specification for interrupt pin
+
+Required nodes:
+
+This device has two video ports. Their connections are modelled using the
+OF graph bindings specified in Documentation/devicetree/bindings/graph.txt.
+
+- Video port 0 for DSI input
+- Video port 1 for eDP output
+
+Example
+---
+
+edp-bridge@2d {
+ compatible = "ti,sn65dsi86";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x2d>;
+
+ enable-gpios = <&msmgpio 33 GPIO_ACTIVE_HIGH>;
+
+ vccio-supply = <&pm8916_l17>;
+ vcca-supply = <&pm8916_l6>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ edp_bridge_in: endpoint {
+ remote-endpoint = <&dsi_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ edp_bridge_out: endpoint {
+ remote-endpoint = <&edp_panel_in>;
+ };
+ };
+ };
+}
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 1/4] dt-bindings: gpu: mali-utgard: add mediatek, mt7623-mali compatible
From: Sean Wang
The MediaTek MT7623 SoC contains a Mali-450, so add a compatible for it
and define its own vendor-specific properties.
Signed-off-by: Sean Wang
---
Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt | 9 +
1 file changed, 9 insertions(+)
diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt
b/Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt
index c1f65d1..e149995 100644
--- a/Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt
+++ b/Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt
@@ -20,6 +20,7 @@ Required properties:
+ rockchip,rk3228-mali
+ rockchip,rk3328-mali
+ stericsson,db8500-mali
+ + mediatek,mt7623-mali
- reg: Physical base address and length of the GPU registers
@@ -86,6 +87,14 @@ to specify one more vendor-specific compatible, among:
* interrupt-names and interrupts:
+ combined: combined interrupt of all of the above lines
+ - mediatek,mt7623-mali
+ Required properties:
+ * resets: phandle to the reset line for the GPU
+ * mediatek,larb: phandle pointed to the local arbiter used to control the
+ access to external memory on the SoC.
+ see
Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt
+ for details
+
Example:
mali: gpu@1c4 {
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Print unadorned pointers
On Wed, 2018-04-18 at 11:29 +0200, Maarten Lankhorst wrote:
> Op 18-04-18 om 11:24 schreef Alexey Brodkin:
> > After commit ad67b74 ("printk: hash addresses printed with %p")
> > pointers are being hashed when printed. However, this makes
> > debug output completely useless. Switch to %px in order to see the
> > unadorned kernel pointers.
> >
> > This was done with the following one-liner:
> > find drivers/gpu/drm -type f -name "*.c" -exec sed -r -i
> > '/DRM_DEBUG|KERN_DEBUG|pr_debug/ s/%p\b/%px/g' {} +
>
> So first we plug a kernel information leak hole, then we introduce it again?
> Seems like a terrible idea..
Well security concerns are good but what about us poor kernel developers?
Those debug prints are supposed to help us to deal with stuff we develop or fix.
Frankly I was quite surprised when first saw what was "unique hashed ID" instead
of real pointer value. And what's worse there's no way to get previous behavior
back.
So now we have to manually patch sources here and there to get meaningful data,
right?
I wouldn't bother sending this patch if there was Kconfig option reverting %p
behavior
but that was never implemented.
-Alexey
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Freedreno] [DPU PATCH v2 2/2] drm/panel: add backlight control support for truly panel
On Wed 18 Apr 21:23 PDT 2018, abhin...@codeaurora.org wrote: > Hi Bjorn > Hi Abhinav, > Thanks very much for the detailed response. > You're welcome. > Yes, we decided that userspace hardcoding this node name is not a > strong enough reason to register as another backlight device. > > Had one follow up question though. > > The QC WLED driver, drivers/leds/leds-qpnp-wled.c is not registering itself > as a backlight device. > > It only registers as a led device. > > In that case, we cannot invoke of_find_backlight_by_node to get a handle on > it. > > One question we have is , is it required that every WLED driver register > itself as a backlight device too? > > In this case since it is not doing so, but we need to trigger it for the > backlight. > > Is there any way we can do this? > It seems I answered this in private, so let me summarize my answer for the record. The downstream driver for the Qualcomm WLED registers a LED, but the WLED driver should register a backlight device. There is a driver (drivers/video/backlight/pm8941-wled.c) that does that for the WLED version found in PM8941, so the appropriate solution to this problem is to extend that to support the PMIC you're looking at. > OR shall we just abandon the backlight control out of this driver entirely. > The backlight handling in the panel driver serves the purpose of blanking and unblanking the associated backlight device, given the status of the panel. And this is still considered valuable. It does sounds like a reasonable idea to extend this to also cover brightness management, but as you might guess this becomes a larger and completely generic issue. Regards, Bjorn > Thanks > > Abhinav > > On 2018-04-18 21:00, Bjorn Andersson wrote: > > On Tue 17 Apr 17:04 PDT 2018, abhin...@codeaurora.org wrote: > > > > > Hi Bjorn > > > > > > Apologies if the prev reply wasnt clear. > > > > > > Hope this one is. > > > > > > > Much better, now we can discuss the actual issues :) > > > > > reply inline. > > > > > > On 2018-04-17 14:29, Bjorn Andersson wrote: > > > > On Tue 17 Apr 11:21 PDT 2018, abhin...@codeaurora.org wrote: > > > > > On 2018-04-16 23:13, Bjorn Andersson wrote: > > > > [..] > > > > > > If the panel isn't actually a piece of backlight hardware then it > > > > > > should > > > > > > not register a backlight device. Why do you need your own sysfs? > > > > > > > > > > > > Regards, > > > > > > Bjorn > > > > > [Abhinav] This particular panel isnt a piece of backlight hardware. > > > > > But, we want to have our own sysfs to give flexibility to our > > > > > userspace > > > > > to write and read stuff for its proprietary uses. > > > > > > > > Please be more specific in your replies, no one will accept code that > > > > "does stuff" and expecting a reviewer to spend time guessing or pulling > > > > the information out of you is a sure way to get your patches ignored. > > > > > > > > Exactly what kind of stuff are you talking about here and exactly which > > > > problem are you solving. > > > > > > > > > Thats how our downstream has been working so far and hence to maintain > > > > > the compatibility would like to have it. > > > > > > > > Make your proprietary code work with the upstream kernel and you > > > > shouldn't ever have to modify it. > > > > > > > > Regards, > > > > Bjorn > > > > > > [Abhinav] We have a few userspace clients today for the backlight > > > sysfs node > > > which read/write directly to > > > "/sys/class/backlight/panel0-backlight/brightness" > > > When I said "stuff" I was only referring to the brightness value. > > > This separate sysfs node allows us to validate those userspace > > > features of ours which directly edit the backlight value on our > > > reference platform. > > > > That's nice, but you're enforcing that either all panel drivers must > > implement this backlight wrapper or that your customers must modify > > their user space to match their backlight implementation. > > > > > Since our reference platform uses this panel,hence having our own > > > sysfs alias helps. Otherwise, whenever we try to use this panel with > > > upstream code we will have to end up changing all those places in our > > > userspace/framework to change the sysfs path. > > > > The actual problem comes down to "how does user space know the name of > > the backlight instance associated with the panel" and this is a valid > > question to pursue. > > > > But given your current design you could just scan for the one and only > > backlight device available in the system; as your use of the static name > > "panel0-backlight" doesn't allow multiple backlights anyway. > > > > > > If your goal is simply to ship your reference with something that you > > can show work, then just replace the hard coded panel0-backlight with > > the name of the wled backlight device. Customers can change panels as > > they wish, but in the event that they plug in a different backlight > > controller they would need to modify the c
Re: [PATCH] drm/amd/display: Disallow enabling CRTC without primary plane with FB
[ Dropping stable@ (fixes with Cc: stable are picked up for stable
branches once they land in Linus' tree, there's no point sending them to
stable@ during review), adding dri-devel ]
On 2018-04-18 10:26 PM, Harry Wentland wrote:
> The below commit
>
> "drm/atomic: Try to preserve the crtc enabled state in
> drm_atomic_remove_fb, v2"
>
> introduces a slight behavioral change to rmfb. Instead of disabling a crtc
> when the primary plane is disabled, it now preserves it.
>
> Since DC is currently not equipped to handle this we need to fail such
> a commit, otherwise we might see a corrupted screen.
How does the caller react to failing such a commit?
> This is based on Shirish's previous approach but avoids adding all
> planes to the new atomic state which leads to a full update in DC for
> any commit, and is not what we intend.
>
> Theoretically DM should be able to deal with states with fully populated
> planes,
> even for simple updates, such as cursor updates. This should still be
> addressed in the future.
>
> Signed-off-by: Harry Wentland
> Cc: sta...@vger.kernel.org
> ---
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 10 +-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index 6f92a19bebd6..0bdc6b484bad 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -4683,6 +4683,7 @@ static int dm_update_crtcs_state(struct
> amdgpu_display_manager *dm,
> struct amdgpu_dm_connector *aconnector = NULL;
> struct drm_connector_state *new_con_state = NULL;
> struct dm_connector_state *dm_conn_state = NULL;
> + struct drm_plane_state *new_plane_state = NULL;
>
> new_stream = NULL;
>
> @@ -4690,6 +4691,13 @@ static int dm_update_crtcs_state(struct
> amdgpu_display_manager *dm,
> dm_new_crtc_state = to_dm_crtc_state(new_crtc_state);
> acrtc = to_amdgpu_crtc(crtc);
>
> + new_plane_state = drm_atomic_get_new_plane_state(state,
> new_crtc_state->crtc->primary);
> +
> + if (new_crtc_state->enable && new_plane_state &&
> !new_plane_state->fb) {
> + ret = -EINVAL;
> + goto fail;
> + }
> +
> aconnector =
> amdgpu_dm_find_first_crtc_matching_connector(state, crtc);
>
> /* TODO This hack should go away */
> @@ -4894,7 +4902,7 @@ static int dm_update_planes_state(struct dc *dc,
> if (!dm_old_crtc_state->stream)
> continue;
>
> - DRM_DEBUG_DRIVER("Disabling DRM plane: %d on DRM crtc
> %d\n",
> + DRM_DEBUG_ATOMIC("Disabling DRM plane: %d on DRM crtc
> %d\n",
> plane->base.id,
> old_plane_crtc->base.id);
>
> if (!dc_remove_plane_from_context(
>
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 101739] An issue with alpha-to-coverage handling is causing Arma 3 64-bit Linux port to render trees incorrectly
https://bugs.freedesktop.org/show_bug.cgi?id=101739 --- Comment #14 from Krystian Gałaj --- (In reply to Gregor Münch from comment #10) > Some comments from a VP dev: > https://www.gamingonlinux.com/articles/the-linux-beta-of-arma-3-has-been- > updated-to-180-compatible-with-windows-again-for-a-time.11349/ > comment_id=118838 > > Seems to be that it's not clear if the bug is on Mesa or VPs side. Maybe > some Mesa dev could comment. I am not sure what we could do on VP side to work around the bug. It happens in a single execution of fragment shader on a multisampled color buffer and depth buffer. The same execution is writing a color value, and it's supposed to write a depth value into the corresponding sample of depth buffer. I don't know of any additional keywords in GLSL that we could specify to make sure this is the case. If anyone knows about something we're specifying wrong, please advise. As for rendering techniques used, we are only converting the rendering technique used by the original Arma 3 developer team from Direct3D API to OpenGL. So one way of working around the problem would be to ask them to do LOD switching in another way in future release - and then we could port that new version. But since it's not happening on the same graphics cards on Windows or Mac, only on Linux, it isn't likely this rework would be given any high priority. And we are good at API knowledge and conversion between them, but inventing another technique to swap in for existing technique in not our game requires slightly different approach, and, above all, good knowledge of the entire complicated rendering engine used in the game, so as not to break anything. I don't think that working around the problem is a good thing to mention in a bug ticket... this thing might be happening in other games, maybe not so high profile, so it would make sense to fix it in driver. It can be done, if it's working on the same cards using Windows drivers... -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 0/2] Enabling content-type setting for HDMI displays.
From: Stanislav Lisovskiy Rev 1: Added content type setting property to drm_connector(part 1) and enabled transmitting it with HDMI AVI infoframes for i915(part 2). Rev 2: Moved helper function which attaches content type property to the drm core, as was suggested. Removed redundant connector state initialization. Rev 3: Removed caps in drm_content_type_enum_list. After some discussion it turned out that HDMI Spec 1.4 was wrongly assuming that IT Content(itc) bit doesn't affect Content type states, however itc bit needs to be manupulated as well. In order to not expose additional property for itc, for sake of simplicity it was decided to bind those together in same "content type" property. Stanislav Lisovskiy (2): drm: content-type property for HDMI connector i915: content-type property for HDMI connector Documentation/gpu/kms-properties.csv | 1 + drivers/gpu/drm/drm_atomic.c | 5 +++ drivers/gpu/drm/drm_connector.c | 51 drivers/gpu/drm/drm_edid.c | 2 ++ drivers/gpu/drm/i915/intel_atomic.c | 1 + drivers/gpu/drm/i915/intel_hdmi.c| 4 +++ include/drm/drm_connector.h | 17 ++ include/drm/drm_mode_config.h| 5 +++ include/uapi/drm/drm_mode.h | 7 9 files changed, 93 insertions(+) -- 2.17.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 2/2] i915: content-type property for HDMI connector
From: Stanislav Lisovskiy Added encoding of drm content_type property from drm_connector_state within AVI infoframe in order to properly handle external HDMI TV content-type setting. This requires also manipulationg ITC bit, as stated in HDMI spec. Signed-off-by: Stanislav Lisovskiy --- drivers/gpu/drm/i915/intel_atomic.c | 1 + drivers/gpu/drm/i915/intel_hdmi.c | 4 2 files changed, 5 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_atomic.c b/drivers/gpu/drm/i915/intel_atomic.c index 40285d1b91b7..61ddb5871d8a 100644 --- a/drivers/gpu/drm/i915/intel_atomic.c +++ b/drivers/gpu/drm/i915/intel_atomic.c @@ -124,6 +124,7 @@ int intel_digital_connector_atomic_check(struct drm_connector *conn, if (new_conn_state->force_audio != old_conn_state->force_audio || new_conn_state->broadcast_rgb != old_conn_state->broadcast_rgb || new_conn_state->base.picture_aspect_ratio != old_conn_state->base.picture_aspect_ratio || + new_conn_state->base.content_type != old_conn_state->base.content_type || new_conn_state->base.scaling_mode != old_conn_state->base.scaling_mode) crtc_state->mode_changed = true; diff --git a/drivers/gpu/drm/i915/intel_hdmi.c b/drivers/gpu/drm/i915/intel_hdmi.c index ee929f31f7db..078200908b7a 100644 --- a/drivers/gpu/drm/i915/intel_hdmi.c +++ b/drivers/gpu/drm/i915/intel_hdmi.c @@ -491,6 +491,9 @@ static void intel_hdmi_set_avi_infoframe(struct drm_encoder *encoder, intel_hdmi->rgb_quant_range_selectable, is_hdmi2_sink); + frame.avi.content_type = connector->state->content_type; + frame.avi.itc = connector->state->it_content; + /* TODO: handle pixel repetition for YCBCR420 outputs */ intel_write_infoframe(encoder, crtc_state, &frame); } @@ -2065,6 +2068,7 @@ intel_hdmi_add_properties(struct intel_hdmi *intel_hdmi, struct drm_connector *c intel_attach_force_audio_property(connector); intel_attach_broadcast_rgb_property(connector); intel_attach_aspect_ratio_property(connector); + drm_connector_attach_content_type_property(connector); connector->state->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE; } -- 2.17.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 1/2] drm: content-type property for HDMI connector
From: Stanislav Lisovskiy
Added content_type property to
drm_connector_state in order to properly handle
external HDMI TV content-type setting.
Signed-off-by: Stanislav Lisovskiy
---
Documentation/gpu/kms-properties.csv | 1 +
drivers/gpu/drm/drm_atomic.c | 5 +++
drivers/gpu/drm/drm_connector.c | 51
drivers/gpu/drm/drm_edid.c | 2 ++
include/drm/drm_connector.h | 17 ++
include/drm/drm_mode_config.h| 5 +++
include/uapi/drm/drm_mode.h | 7
7 files changed, 88 insertions(+)
diff --git a/Documentation/gpu/kms-properties.csv
b/Documentation/gpu/kms-properties.csv
index 6b28b014cb7d..ba71184708f3 100644
--- a/Documentation/gpu/kms-properties.csv
+++ b/Documentation/gpu/kms-properties.csv
@@ -17,6 +17,7 @@ Owner Module/Drivers,Group,Property Name,Type,Property
Values,Object attached,De
,Virtual GPU,“suggested X”,RANGE,"Min=0, Max=0x",Connector,property to
suggest an X offset for a connector
,,“suggested Y”,RANGE,"Min=0, Max=0x",Connector,property to suggest an
Y offset for a connector
,Optional,"""aspect ratio""",ENUM,"{ ""None"", ""4:3"", ""16:9""
}",Connector,TDB
+,Optional,"""content type""",ENUM,"{ ""Graphics"", ""Photo"", ""Cinema"",
""Game"" }",Connector,TBD
i915,Generic,"""Broadcast RGB""",ENUM,"{ ""Automatic"", ""Full"", ""Limited
16:235"" }",Connector,"When this property is set to Limited 16:235 and CTM is
set, the hardware will be programmed with the result of the multiplication of
CTM by the limited range matrix to ensure the pixels normaly in the range
0..1.0 are remapped to the range 16/255..235/255."
,,“audio”,ENUM,"{ ""force-dvi"", ""off"", ""auto"", ""on"" }",Connector,TBD
,SDVO-TV,“mode”,ENUM,"{ ""NTSC_M"", ""NTSC_J"", ""NTSC_443"", ""PAL_B"" }
etc.",Connector,TBD
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 7d25c42f22db..8e0f788283f8 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1266,6 +1266,9 @@ static int drm_atomic_connector_set_property(struct
drm_connector *connector,
state->link_status = val;
} else if (property == config->aspect_ratio_property) {
state->picture_aspect_ratio = val;
+ } else if (property == config->content_type_property) {
+ state->content_type = val & 3;
+ state->it_content = val >> 2;
} else if (property == connector->scaling_mode_property) {
state->scaling_mode = val;
} else if (property == connector->content_protection_property) {
@@ -1351,6 +1354,8 @@ drm_atomic_connector_get_property(struct drm_connector
*connector,
*val = state->link_status;
} else if (property == config->aspect_ratio_property) {
*val = state->picture_aspect_ratio;
+ } else if (property == config->content_type_property) {
+ *val = state->content_type | (state->it_content << 2);
} else if (property == connector->scaling_mode_property) {
*val = state->scaling_mode;
} else if (property == connector->content_protection_property) {
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index b3cde897cd80..757a0712f7c1 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -720,6 +720,14 @@ static const struct drm_prop_enum_list
drm_aspect_ratio_enum_list[] = {
{ DRM_MODE_PICTURE_ASPECT_16_9, "16:9" },
};
+static const struct drm_prop_enum_list drm_content_type_enum_list[] = {
+ { DRM_MODE_CONTENT_TYPE_NO_DATA, "No data" },
+ { DRM_MODE_CONTENT_TYPE_GRAPHICS, "Graphics" },
+ { DRM_MODE_CONTENT_TYPE_PHOTO, "Photo" },
+ { DRM_MODE_CONTENT_TYPE_CINEMA, "Cinema" },
+ { DRM_MODE_CONTENT_TYPE_GAME, "Game" },
+};
+
static const struct drm_prop_enum_list drm_panel_orientation_enum_list[] = {
{ DRM_MODE_PANEL_ORIENTATION_NORMAL,"Normal"},
{ DRM_MODE_PANEL_ORIENTATION_BOTTOM_UP, "Upside Down" },
@@ -996,6 +1004,22 @@ int drm_mode_create_dvi_i_properties(struct drm_device
*dev)
}
EXPORT_SYMBOL(drm_mode_create_dvi_i_properties);
+/**
+ * drm_connector_attach_content_type_property - attach content-type property
+ * @dev: DRM device
+ *
+ * Called by a driver the first time a HDMI connector is made.
+ */
+int drm_connector_attach_content_type_property(struct drm_connector *connector)
+{
+ if (!drm_mode_create_content_type_property(connector->dev))
+ drm_object_attach_property(&connector->base,
+ connector->dev->mode_config.content_type_property,
+ DRM_MODE_CONTENT_TYPE_NO_DATA);
+ return 0;
+}
+EXPORT_SYMBOL(drm_connector_attach_content_type_property);
+
/**
* drm_create_tv_properties - create TV specific connector properties
* @dev: DRM device
@@ -1260,6 +1284,33 @@ int drm_mode_create_aspect_ratio_propert
Re: [PATCH 0/1] drm/xen-zcopy: Add Xen zero-copy helper DRM driver
On 04/18/2018 08:01 PM, Dongwon Kim wrote:
On Wed, Apr 18, 2018 at 09:38:39AM +0300, Oleksandr Andrushchenko wrote:
On 04/17/2018 11:57 PM, Dongwon Kim wrote:
On Tue, Apr 17, 2018 at 09:59:28AM +0200, Daniel Vetter wrote:
On Mon, Apr 16, 2018 at 12:29:05PM -0700, Dongwon Kim wrote:
Yeah, I definitely agree on the idea of expanding the use case to the
general domain where dmabuf sharing is used. However, what you are
targetting with proposed changes is identical to the core design of
hyper_dmabuf.
On top of this basic functionalities, hyper_dmabuf has driver level
inter-domain communication, that is needed for dma-buf remote tracking
(no fence forwarding though), event triggering and event handling, extra
meta data exchange and hyper_dmabuf_id that represents grefs
(grefs are shared implicitly on driver level)
This really isn't a positive design aspect of hyperdmabuf imo. The core
code in xen-zcopy (ignoring the ioctl side, which will be cleaned up) is
very simple & clean.
If there's a clear need later on we can extend that. But for now xen-zcopy
seems to cover the basic use-case needs, so gets the job done.
Also it is designed with frontend (common core framework) + backend
(hyper visor specific comm and memory sharing) structure for portability.
We just can't limit this feature to Xen because we want to use the same
uapis not only for Xen but also other applicable hypervisor, like ACORN.
See the discussion around udmabuf and the needs for kvm. I think trying to
make an ioctl/uapi that works for multiple hypervisors is misguided - it
likely won't work.
On top of that the 2nd hypervisor you're aiming to support is ACRN. That's
not even upstream yet, nor have I seen any patches proposing to land linux
support for ACRN. Since it's not upstream, it doesn't really matter for
upstream consideration. I'm doubting that ACRN will use the same grant
references as xen, so the same uapi won't work on ACRN as on Xen anyway.
Yeah, ACRN doesn't have grant-table. Only Xen supports it. But that is why
hyper_dmabuf has been architectured with the concept of backend.
If you look at the structure of backend, you will find that
backend is just a set of standard function calls as shown here:
struct hyper_dmabuf_bknd_ops {
/* backend initialization routine (optional) */
int (*init)(void);
/* backend cleanup routine (optional) */
int (*cleanup)(void);
/* retreiving id of current virtual machine */
int (*get_vm_id)(void);
/* get pages shared via hypervisor-specific method */
int (*share_pages)(struct page **pages, int vm_id,
int nents, void **refs_info);
/* make shared pages unshared via hypervisor specific method */
int (*unshare_pages)(void **refs_info, int nents);
/* map remotely shared pages on importer's side via
* hypervisor-specific method
*/
struct page ** (*map_shared_pages)(unsigned long ref, int vm_id,
int nents, void **refs_info);
/* unmap and free shared pages on importer's side via
* hypervisor-specific method
*/
int (*unmap_shared_pages)(void **refs_info, int nents);
/* initialize communication environment */
int (*init_comm_env)(void);
void (*destroy_comm)(void);
/* upstream ch setup (receiving and responding) */
int (*init_rx_ch)(int vm_id);
/* downstream ch setup (transmitting and parsing responses) */
int (*init_tx_ch)(int vm_id);
int (*send_req)(int vm_id, struct hyper_dmabuf_req *req, int wait);
};
All of these can be mapped with any hypervisor specific implementation.
We designed backend implementation for Xen using grant-table, Xen event
and ring buffer communication. For ACRN, we have another backend using Virt-IO
for both memory sharing and communication.
We tried to define this structure of backend to make it general enough (or
it can be even modified or extended to support more cases.) so that it can
fit to other hypervisor cases. Only requirements/expectation on the hypervisor
are page-level memory sharing and inter-domain communication, which I think
are standard features of modern hypervisor.
And please review common UAPIs that hyper_dmabuf and xen-zcopy supports. They
are very general. One is getting FD (dmabuf) and get those shared. The other
is generating dmabuf from global handle (secure handle hiding gref behind it).
On top of this, hyper_dmabuf has "unshare" and "query" which are also useful
for any cases.
So I don't know why we wouldn't want to try to make these standard in most of
hypervisor cases instead of limiting it to certain hypervisor like Xen.
Frontend-backend structre is optimal for this I think.
So I am wondering we can start with this hyper_dmabuf then modify it for
your use-case if needed and polish and fix any glitches if we want to
to use this
Re: [PATCH 4/8] dma-buf: add peer2peer flag
On Mon, Apr 16, 2018 at 03:38:56PM +0200, Daniel Vetter wrote: > We've broken that assumption in i915 years ago. Not struct page backed > gpu memory is very real. > > Of course we'll never feed such a strange sg table to a driver which > doesn't understand it, but allowing sg_page == NULL works perfectly > fine. At least for gpu drivers. For GPU drivers on x86 with no dma coherency problems, sure. But not all the world is x86. We already have problems due to dmabugs use of the awkward get_sgtable interface (see the common on arm_dma_get_sgtable that I fully agree with), and doing this for memory that doesn't have a struct page at all will make things even worse. > If that's not acceptable then I guess we could go over the entire tree > and frob all the gpu related code to switch over to a new struct > sg_table_might_not_be_struct_page_backed, including all the other > functions we added over the past few years to iterate over sg tables. > But seems slightly silly, given that sg tables seem to do exactly what > we need. It isn't silly. We will have to do some surgery like that anyway because the current APIs don't work. So relax, sit back and come up with an API that solves the existing issues and serves us well in the future. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: bridge: dw-hdmi: Fix overflow workaround for Amlogic Meson GX SoCs
Hi Greg,
On 23/02/2018 12:44, Neil Armstrong wrote:
> The Amlogic Meson GX SoCs, embedded the v2.01a controller, has been also
> identified needing this workaround.
> This patch adds the corresponding version to enable a single iteration for
> this specific version.
>
> Fixes: be41fc55f1aa ("drm: bridge: dw-hdmi: Handle overflow workaround based
> on device version")
> Signed-off-by: Neil Armstrong
This patch is now present in linux master as commit
9c305eb442f3b371fc722ade827bbf673514123e
Could it be selected for 4.14 ?
The patch has been reworked to apply for 4.17 as indicated in the commit log,
but the original patch will apply over 4.14.
Thanks,
Neil
> ---
> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> index a38db40..f5018f9 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> @@ -1637,6 +1637,8 @@ static void dw_hdmi_clear_overflow(struct dw_hdmi *hdmi)
>* (and possibly on the platform). So far only i.MX6Q (v1.30a) and
>* i.MX6DL (v1.31a) have been identified as needing the workaround, with
>* 4 and 1 iterations respectively.
> + * The Amlogic Meson GX SoCs (v2.01a) have been identifies as needing
> + * the workaround with a single iteration.
>*/
>
> switch (hdmi->version) {
> @@ -1644,6 +1646,7 @@ static void dw_hdmi_clear_overflow(struct dw_hdmi *hdmi)
> count = 4;
> break;
> case 0x131a:
> + case 0x201a:
> count = 1;
> break;
> default:
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] dt-bindings/display/bridge: sii902x: add optional power supplies
Hi Philippe, Thank you for the patch. On Tuesday, 10 April 2018 08:19:26 EEST Philippe Cornu wrote: > Add the 3 optional power supplies using the exact description > found in the document named > "SiI9022A/SiI9024A HDMI Transmitter Data Sheet (August 2016)". > > Signed-off-by: Philippe Cornu > --- > Documentation/devicetree/bindings/display/bridge/sii902x.txt | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/Documentation/devicetree/bindings/display/bridge/sii902x.txt > b/Documentation/devicetree/bindings/display/bridge/sii902x.txt index > 56a3e68ccb80..cf53678fe574 100644 > --- a/Documentation/devicetree/bindings/display/bridge/sii902x.txt > +++ b/Documentation/devicetree/bindings/display/bridge/sii902x.txt > @@ -8,6 +8,9 @@ Optional properties: > - interrupts-extended or interrupt-parent + interrupts: describe > the interrupt line used to inform the host about hotplug events. > - reset-gpios: OF device-tree gpio specification for RST_N pin. > + - iovcc-supply: I/O supply voltage (1.8V or 3.3V, host-dependent). > + - avcc12-supply: TMDS analog supply voltage (1.2V). > + - cvcc12-supply: Digital core supply voltage (1.2V). It seems that the AVCC12 and CVCC12 power supplies are usually derived from the same source. How about starting with one DT property for both, and adding a second one later if needed ? > Optional subnodes: > - video input: this subnode can contain a video input port node -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Xen-devel] [PATCH 0/1] drm/xen-zcopy: Add Xen zero-copy helper DRM driver
On 04/18/2018 07:01 PM, Dongwon Kim wrote: On Wed, Apr 18, 2018 at 03:42:29PM +0300, Oleksandr Andrushchenko wrote: On 04/18/2018 01:55 PM, Roger Pau Monné wrote: On Wed, Apr 18, 2018 at 01:39:35PM +0300, Oleksandr Andrushchenko wrote: On 04/18/2018 01:18 PM, Paul Durrant wrote: -Original Message- From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf Of Roger Pau Monné Sent: 18 April 2018 11:11 To: Oleksandr Andrushchenko Cc: jgr...@suse.com; Artem Mygaiev ; Dongwon Kim ; airl...@linux.ie; oleksandr_andrushche...@epam.com; linux-ker...@vger.kernel.org; dri- de...@lists.freedesktop.org; Potrola, MateuszX ; xen-de...@lists.xenproject.org; daniel.vet...@intel.com; boris.ostrov...@oracle.com; Matt Roper Subject: Re: [Xen-devel] [PATCH 0/1] drm/xen-zcopy: Add Xen zero-copy helper DRM driver On Wed, Apr 18, 2018 at 11:01:12AM +0300, Oleksandr Andrushchenko wrote: On 04/18/2018 10:35 AM, Roger Pau Monné wrote: After speaking with Oleksandr on IRC, I think the main usage of the gntdev extension is to: 1. Create a dma-buf from a set of grant references. 2. Share dma-buf and get a list of grant references. I think this set of operations could be broken into: 1.1 Map grant references into user-space using the gntdev. 1.2 Create a dma-buf out of a set of user-space virtual addresses. 2.1 Map a dma-buf into user-space. 2.2 Get grefs out of the user-space addresses where the dma-buf is mapped. So it seems like what's actually missing is a way to: - Create a dma-buf from a list of user-space virtual addresses. - Allow to map a dma-buf into user-space, so it can then be used with the gntdev. I think this is generic enough that it could be implemented by a device not tied to Xen. AFAICT the hyper_dma guys also wanted something similar to this. Ok, so just to summarize, xen-zcopy/hyper-dmabuf as they are now, are no go from your POV? FYI, our use-case is "surface sharing" or "graphic obj sharing" where a client application in one guest renders and export this render target(e.g. EGL surface) as dma-buf. This dma-buf is then exported to another guest/host via hyper_dmabuf drv where a compositor is running. This importing domain creates a dmabuf with shared reference then it is imported as EGL image that later can be used as texture object via EGL api. Mapping dmabuf to the userspace or vice versa might be possible with modifying user space drivers/applications but it is an unnecessary extra step from our perspective. +1. I also feel like if it is implemented in the kernel space it will be *much* more easier then inventing workarounds with gntdev, user-space and helper dma-buf driver (which obviously can be implemented). Of course, this approach is easier for Xen as we do not touch its kernel code ;) But there is a demand for changes as number of embedded/multimedia use-cases is constantly growing and we have to react. Also, we want to keep all objects in the kernel level. My opinion is that there seems to be a more generic way to implement this, and thus I would prefer that one. Instead, we have to make all that fancy stuff with VAs <-> device-X and have that device-X driver live out of drivers/xen as it is not a Xen specific driver? That would be my preference if feasible, simply because it can be reused by other use-cases that need to create dma-bufs in user-space. There is a use-case I have: a display unit on my target has a DMA controller which can't do scatter-gather, e.g. it only expects a single starting address of the buffer. In order to create a dma-buf from grefs in this case I allocate memory with dma_alloc_xxx and then balloon pages of the buffer and finally map grefs onto this DMA buffer. This way I can give this shared buffer to the display unit as its bus addresses are contiguous. With the proposed solution (gntdev + device-X) I won't be able to achieve this, as I have no control over from where gntdev/balloon drivers get the pages (even more, those can easily be out of DMA address space of the display unit). Thus, even if implemented, I can't use this approach. In any case I just knew about dma-bufs this morning, there might be things that I'm missing. Roger. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/bridge: sii902x: add optional power supplies
Hi Philippe,
Thank you for the patch.
On Tuesday, 10 April 2018 08:19:27 EEST Philippe Cornu wrote:
> Add the 3 optional power supplies using the exact description
> found in the document named
> "SiI9022A/SiI9024A HDMI Transmitter Data Sheet (August 2016)".
>
> Signed-off-by: Philippe Cornu
> ---
> drivers/gpu/drm/bridge/sii902x.c | 39 +
> 1 file changed, 35 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/sii902x.c
> b/drivers/gpu/drm/bridge/sii902x.c index 60373d7eb220..e17ba6db1ec8 100644
> --- a/drivers/gpu/drm/bridge/sii902x.c
> +++ b/drivers/gpu/drm/bridge/sii902x.c
> @@ -24,6 +24,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -86,6 +87,7 @@ struct sii902x {
> struct drm_bridge bridge;
> struct drm_connector connector;
> struct gpio_desc *reset_gpio;
> + struct regulator_bulk_data supplies[3];
> };
>
> static inline struct sii902x *bridge_to_sii902x(struct drm_bridge *bridge)
> @@ -392,23 +394,43 @@ static int sii902x_probe(struct i2c_client *client,
> return PTR_ERR(sii902x->reset_gpio);
> }
>
> + sii902x->supplies[0].supply = "iovcc";
> + sii902x->supplies[1].supply = "avcc12";
> + sii902x->supplies[2].supply = "cvcc12";
> + ret = devm_regulator_bulk_get(dev, ARRAY_SIZE(sii902x->supplies),
> + sii902x->supplies);
> + if (ret) {
> + dev_err(dev, "regulator_bulk_get failed\n");
Maybe "failed to get power supplies" to be a bit more explicit ? And while at
it, printing the value of ret too ?
> + return ret;
> + }
> +
> + ret = regulator_bulk_enable(ARRAY_SIZE(sii902x->supplies),
> + sii902x->supplies);
> + if (ret) {
> + dev_err(dev, "regulator_bulk_enable failed\n");
Same here ?
> + return ret;
> + }
> +
> + usleep_range(1, 2);
> +
> sii902x_reset(sii902x);
>
> ret = regmap_write(sii902x->regmap, SII902X_REG_TPI_RQB, 0x0);
> if (ret)
> - return ret;
> + goto err_disable_regulator;
>
> ret = regmap_bulk_read(sii902x->regmap, SII902X_REG_CHIPID(0),
> &chipid, 4);
> if (ret) {
> dev_err(dev, "regmap_read failed %d\n", ret);
> - return ret;
> + goto err_disable_regulator;
> }
>
> if (chipid[0] != 0xb0) {
> dev_err(dev, "Invalid chipid: %02x (expecting 0xb0)\n",
> chipid[0]);
> - return -EINVAL;
> + ret = -EINVAL;
> + goto err_disable_regulator;
> }
>
> /* Clear all pending interrupts */
> @@ -424,7 +446,7 @@ static int sii902x_probe(struct i2c_client *client,
> IRQF_ONESHOT, dev_name(dev),
> sii902x);
> if (ret)
> - return ret;
> + goto err_disable_regulator;
> }
>
> sii902x->bridge.funcs = &sii902x_bridge_funcs;
> @@ -434,6 +456,12 @@ static int sii902x_probe(struct i2c_client *client,
> i2c_set_clientdata(client, sii902x);
>
> return 0;
> +
> +err_disable_regulator:
> + regulator_bulk_disable(ARRAY_SIZE(sii902x->supplies),
> +sii902x->supplies);
> +
> + return ret;
> }
>
> static int sii902x_remove(struct i2c_client *client)
> @@ -443,6 +471,9 @@ static int sii902x_remove(struct i2c_client *client)
>
> drm_bridge_remove(&sii902x->bridge);
>
> + regulator_bulk_disable(ARRAY_SIZE(sii902x->supplies),
> +sii902x->supplies);
> +
While this seems functionally correct, would it be useful to only enable power
supplies when needed to save power ?
> return 0;
> }
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: bridge: dw-hdmi: Fix overflow workaround for Amlogic Meson GX SoCs
On Thu, Apr 19, 2018 at 10:18:35AM +0200, Neil Armstrong wrote:
> Hi Greg,
>
> On 23/02/2018 12:44, Neil Armstrong wrote:
> > The Amlogic Meson GX SoCs, embedded the v2.01a controller, has been also
> > identified needing this workaround.
> > This patch adds the corresponding version to enable a single iteration for
> > this specific version.
> >
> > Fixes: be41fc55f1aa ("drm: bridge: dw-hdmi: Handle overflow workaround
> > based on device version")
> > Signed-off-by: Neil Armstrong
>
> This patch is now present in linux master as commit
> 9c305eb442f3b371fc722ade827bbf673514123e
> Could it be selected for 4.14 ?
> The patch has been reworked to apply for 4.17 as indicated in the commit log,
> but the original patch will apply over 4.14.
I don't have any "original" patch here, I just tried applying it to
4.16.y and 4.14.y and it did not work. Can you please provide a working
backport?
thanks,
greg k-h
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] drm-intel-next-fixes
Hi Dave, I was travelling last week, and thought you wouldn't be back until this week, but you were :) So, my PR is against older drm-next for that I don't want to make GVT folks redo their PR twice. It's looking good on CI. Biggest things are the fix to be tolerant against bad BIOSes (FDO #105549) and fix on GVT regression. Next week should be a normal PR, then! Regards, Joonas drm-intel-next-fixes-2018-04-19: - Fix for FDO #105549: Avoid OOPS on bad VBT (Jani) - Fix rare pre-emption race (Chris) - Fix RC6 race against PM transitions (Tvrtko) gvt-fixes-2018-04-03 - fix unhandled vfio ioctl return value (Gerd) - no-op user interrupt for vGPU (Zhipeng) - fix ggtt dma unmap (Changbin) - fix warning in fb decoder (Xiong) - dmabuf drm_format_mod fix (Tina) - misc cleanup The following changes since commit 694f54f680f7fd8e9561928fbfc537d9afbc3d79: Merge branch 'drm-misc-next-fixes' of git://anongit.freedesktop.org/drm/drm-misc into drm-next (2018-03-29 09:25:13 +1000) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-fixes-2018-04-19 for you to fetch changes up to b4615730530be85fc45ab4631c2ad6d8e2d0b97d: drm/i915/audio: Fix audio detection issue on GLK (2018-04-18 14:26:15 +0300) - Fix for FDO #105549: Avoid OOPS on bad VBT (Jani) - Fix rare pre-emption race (Chris) - Fix RC6 race against PM transitions (Tvrtko) Changbin Du (2): drm/i915/gvt: Missed to cancel dma map for ggtt entries drm/i915/gvt: Cancel dma map when resetting ggtt entries Chris Wilson (2): drm/i915/execlists: Clear user-active flag on preemption completion drm/i915: Call i915_perf_fini() on init_hw error unwind Gaurav K Singh (1): drm/i915/audio: Fix audio detection issue on GLK Gerd Hoffmann (1): drm/i915/gvt: throw error on unhandled vfio ioctls Gustavo A. R. Silva (1): drm/i915/gvt: Mark expected switch fall-through in handle_g2v_notification Jani Nikula (1): drm/i915/bios: filter out invalid DDC pins from VBT child devices Joonas Lahtinen (1): Merge tag 'gvt-fixes-2018-04-03' of https://github.com/intel/gvt-linux into drm-intel-next-fixes Tina Zhang (1): drm/i915/gvt: Add drm_format_mod update Tvrtko Ursulin (1): drm/i915/pmu: Inspect runtime PM state more carefully while estimating RC6 Xidong Wang (1): drm/i915: Do no use kfree() to free a kmem_cache_alloc() return value Xiong Zhang (2): drm/i915/gvt: Delete redundant error message in fb_decode.c drm/i915/gvt: Disable primary/sprite/cursor plane at virtual display initialization Zhipeng Gong (1): drm/i915/gvt: Make MI_USER_INTERRUPT nop in cmd parser drivers/gpu/drm/i915/gvt/cmd_parser.c | 1 + drivers/gpu/drm/i915/gvt/display.c | 10 ++ drivers/gpu/drm/i915/gvt/dmabuf.c | 1 + drivers/gpu/drm/i915/gvt/fb_decoder.c | 27 ++-- drivers/gpu/drm/i915/gvt/gtt.c | 52 ++ drivers/gpu/drm/i915/gvt/gtt.h | 2 +- drivers/gpu/drm/i915/gvt/handlers.c| 1 + drivers/gpu/drm/i915/gvt/kvmgt.c | 2 +- drivers/gpu/drm/i915/i915_drv.c| 27 +--- drivers/gpu/drm/i915/i915_gem_execbuffer.c | 2 +- drivers/gpu/drm/i915/i915_pmu.c| 37 +++-- drivers/gpu/drm/i915/intel_audio.c | 2 +- drivers/gpu/drm/i915/intel_bios.c | 13 +--- drivers/gpu/drm/i915/intel_lrc.c | 9 ++ 14 files changed, 131 insertions(+), 55 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] dt-bindings/display/bridge: sii902x: add optional power supplies
Hi Laurent : ) On 04/19/2018 10:11 AM, Laurent Pinchart wrote: > Hi Philippe, > > Thank you for the patch. > > On Tuesday, 10 April 2018 08:19:26 EEST Philippe Cornu wrote: >> Add the 3 optional power supplies using the exact description >> found in the document named >> "SiI9022A/SiI9024A HDMI Transmitter Data Sheet (August 2016)". >> >> Signed-off-by: Philippe Cornu >> --- >> Documentation/devicetree/bindings/display/bridge/sii902x.txt | 3 +++ >> 1 file changed, 3 insertions(+) >> >> diff --git a/Documentation/devicetree/bindings/display/bridge/sii902x.txt >> b/Documentation/devicetree/bindings/display/bridge/sii902x.txt index >> 56a3e68ccb80..cf53678fe574 100644 >> --- a/Documentation/devicetree/bindings/display/bridge/sii902x.txt >> +++ b/Documentation/devicetree/bindings/display/bridge/sii902x.txt >> @@ -8,6 +8,9 @@ Optional properties: >> - interrupts-extended or interrupt-parent + interrupts: describe >>the interrupt line used to inform the host about hotplug events. >> - reset-gpios: OF device-tree gpio specification for RST_N pin. >> +- iovcc-supply: I/O supply voltage (1.8V or 3.3V, host-dependent). >> +- avcc12-supply: TMDS analog supply voltage (1.2V). >> +- cvcc12-supply: Digital core supply voltage (1.2V). > > It seems that the AVCC12 and CVCC12 power supplies are usually derived from > the same source. How about starting with one DT property for both, and adding > a second one later if needed ? > Well, I do not know what is the best. Here I took the description from the documentation, and to allow all possible board configurations, I added these supplies as "optional" properties: if there is only one 1v2 regulator on the board, the dt will contain only avcc12 or cvcc12 and everything will work fine (we will have a dummy regulator for the missing optional 1v2 reg), if both regulators are there for any reasons (stability, noise, whatever...) then both entries will be in the dt. If you confirm you prefer a single 1v2 supply (named for instance "vcc12-supply") then I will do :-) Many thanks, Philippe >> Optional subnodes: >> - video input: this subnode can contain a video input port node > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/6] drm/sun4i: tcon: Add dithering support for RGB565/RGB666 LCD panels
From: Jonathan Liu
The hardware supports dithering on TCON channel 0 which is used for LCD
panels.
Dithering is a method of approximating a color from a mixture of other
colors when the required color isn't available. It reduces color
banding artifacts that can be observed when displaying gradients
(e.g. grayscale gradients). This may occur when the image that needs
to be displayed is 24-bit but the LCD panel is a lower bit depth and
does not perform dithering on its own.
Signed-off-by: Jonathan Liu
[w...@csie.org: check display_info.bpc first; handle LVDS and MIPI DSI]
Signed-off-by: Chen-Yu Tsai
---
Hi Maxime,
The dithering parameters used here are different from the ones you used
in your MIPI DSI series. You might want to check if it still works for
you.
---
drivers/gpu/drm/sun4i/sun4i_tcon.c | 63 +-
1 file changed, 62 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index 2bd53ef7d4b8..827518f4790e 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -12,6 +12,7 @@
#include
#include
+#include
#include
#include
#include
@@ -276,8 +277,59 @@ static void sun4i_tcon0_mode_set_common(struct sun4i_tcon
*tcon,
SUN4I_TCON0_BASIC0_Y(mode->crtc_vdisplay));
}
+static void sun4i_tcon0_mode_set_dithering(struct sun4i_tcon *tcon,
+ const struct drm_connector
*connector)
+{
+ u32 bus_format = 0;
+ u32 val = 0;
+
+ /* XXX Would this ever happen? */
+ if (!connector)
+ return;
+
+ /*
+* FIXME: Undocumented bits
+*
+* The whole dithering process and these parameters are not
+* explained in the vendor documents or BSP kernel code.
+*/
+ regmap_write(tcon->regs, SUN4I_TCON0_FRM_SEED_PR_REG, 0x);
+ regmap_write(tcon->regs, SUN4I_TCON0_FRM_SEED_PG_REG, 0x);
+ regmap_write(tcon->regs, SUN4I_TCON0_FRM_SEED_PB_REG, 0x);
+ regmap_write(tcon->regs, SUN4I_TCON0_FRM_SEED_LR_REG, 0x);
+ regmap_write(tcon->regs, SUN4I_TCON0_FRM_SEED_LG_REG, 0x);
+ regmap_write(tcon->regs, SUN4I_TCON0_FRM_SEED_LB_REG, 0x);
+ regmap_write(tcon->regs, SUN4I_TCON0_FRM_TBL0_REG, 0x0101);
+ regmap_write(tcon->regs, SUN4I_TCON0_FRM_TBL1_REG, 0x1515);
+ regmap_write(tcon->regs, SUN4I_TCON0_FRM_TBL2_REG, 0x5757);
+ regmap_write(tcon->regs, SUN4I_TCON0_FRM_TBL3_REG, 0x7f7f);
+
+ /* Do dithering if panel only supports 6 bits per color */
+ if (connector->display_info.bpc == 6)
+ val |= SUN4I_TCON0_FRM_CTL_EN;
+
+ if (connector->display_info.num_bus_formats == 1)
+ bus_format = connector->display_info.bus_formats[0];
+
+ /* Check the connection format */
+ switch (bus_format) {
+ case MEDIA_BUS_FMT_RGB565_1X16:
+ /* R and B components are only 5 bits deep */
+ val |= SUN4I_TCON0_FRM_CTL_MODE_R;
+ val |= SUN4I_TCON0_FRM_CTL_MODE_B;
+ case MEDIA_BUS_FMT_RGB666_1X18:
+ case MEDIA_BUS_FMT_RGB666_1X7X3_SPWG:
+ /* Fall through: enable dithering */
+ val |= SUN4I_TCON0_FRM_CTL_EN;
+ break;
+ }
+
+ /* Write dithering settings */
+ regmap_write(tcon->regs, SUN4I_TCON_FRM_CTL_REG, val);
+}
+
static void sun4i_tcon0_mode_set_cpu(struct sun4i_tcon *tcon,
-struct drm_encoder *encoder,
+const struct drm_encoder *encoder,
const struct drm_display_mode *mode)
{
/* TODO support normal CPU interface modes */
@@ -293,6 +345,9 @@ static void sun4i_tcon0_mode_set_cpu(struct sun4i_tcon
*tcon,
sun4i_tcon0_mode_set_common(tcon, mode);
+ /* Set dithering if needed */
+ sun4i_tcon0_mode_set_dithering(tcon, sun4i_tcon_get_connector(encoder));
+
regmap_update_bits(tcon->regs, SUN4I_TCON0_CTL_REG,
SUN4I_TCON0_CTL_IF_MASK,
SUN4I_TCON0_CTL_IF_8080);
@@ -358,6 +413,9 @@ static void sun4i_tcon0_mode_set_lvds(struct sun4i_tcon
*tcon,
tcon->dclk_max_div = 7;
sun4i_tcon0_mode_set_common(tcon, mode);
+ /* Set dithering if needed */
+ sun4i_tcon0_mode_set_dithering(tcon, sun4i_tcon_get_connector(encoder));
+
/* Adjust clock delay */
clk_delay = sun4i_tcon_get_clk_delay(mode, 0);
regmap_update_bits(tcon->regs, SUN4I_TCON0_CTL_REG,
@@ -434,6 +492,9 @@ static void sun4i_tcon0_mode_set_rgb(struct sun4i_tcon
*tcon,
tcon->dclk_max_div = 127;
sun4i_tcon0_mode_set_common(tcon, mode);
+ /* Set dithering if needed */
+ sun4i_tcon0_mode_set_dithering(tcon, tcon->panel->connector);
+
/* Adjust clock delay */
[PATCH 2/6] drm/sun4i: tcon: Rename Dithering related register macros
Dithering is only supported for TCON channel 0. Throughout the datasheet all the names associated with these register are prefixed "TCON0", instead of "TCON". The only exception is the control register "TCON_FRM_CTL_REG". Rename the macros to reflect this. Signed-off-by: Chen-Yu Tsai --- drivers/gpu/drm/sun4i/sun4i_tcon.h | 27 +++ 1 file changed, 15 insertions(+), 12 deletions(-) diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.h b/drivers/gpu/drm/sun4i/sun4i_tcon.h index f6a071cd5a6f..3d492c8be1fc 100644 --- a/drivers/gpu/drm/sun4i/sun4i_tcon.h +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.h @@ -37,18 +37,21 @@ #define SUN4I_TCON_GINT1_REG 0x8 #define SUN4I_TCON_FRM_CTL_REG 0x10 -#define SUN4I_TCON_FRM_CTL_EN BIT(31) - -#define SUN4I_TCON_FRM_SEED_PR_REG 0x14 -#define SUN4I_TCON_FRM_SEED_PG_REG 0x18 -#define SUN4I_TCON_FRM_SEED_PB_REG 0x1c -#define SUN4I_TCON_FRM_SEED_LR_REG 0x20 -#define SUN4I_TCON_FRM_SEED_LG_REG 0x24 -#define SUN4I_TCON_FRM_SEED_LB_REG 0x28 -#define SUN4I_TCON_FRM_TBL0_REG0x2c -#define SUN4I_TCON_FRM_TBL1_REG0x30 -#define SUN4I_TCON_FRM_TBL2_REG0x34 -#define SUN4I_TCON_FRM_TBL3_REG0x38 +#define SUN4I_TCON0_FRM_CTL_EN BIT(31) +#define SUN4I_TCON0_FRM_CTL_MODE_R BIT(6) +#define SUN4I_TCON0_FRM_CTL_MODE_G BIT(5) +#define SUN4I_TCON0_FRM_CTL_MODE_B BIT(4) + +#define SUN4I_TCON0_FRM_SEED_PR_REG0x14 +#define SUN4I_TCON0_FRM_SEED_PG_REG0x18 +#define SUN4I_TCON0_FRM_SEED_PB_REG0x1c +#define SUN4I_TCON0_FRM_SEED_LR_REG0x20 +#define SUN4I_TCON0_FRM_SEED_LG_REG0x24 +#define SUN4I_TCON0_FRM_SEED_LB_REG0x28 +#define SUN4I_TCON0_FRM_TBL0_REG 0x2c +#define SUN4I_TCON0_FRM_TBL1_REG 0x30 +#define SUN4I_TCON0_FRM_TBL2_REG 0x34 +#define SUN4I_TCON0_FRM_TBL3_REG 0x38 #define SUN4I_TCON0_CTL_REG0x40 #define SUN4I_TCON0_CTL_TCON_ENABLEBIT(31) -- 2.17.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/6] drm/panel: simple: Add support for Banana Pi 7" S070WV20-CT16 panel
This panel is marketed as Banana Pi 7" LCD display. On the back is
a sticker denoting the model name S070WV20-CT16.
This is a 7" 800x480 panel connected through a 24-bit RGB interface.
However the panel only does 262k colors.
Signed-off-by: Chen-Yu Tsai
---
.../display/panel/bananapi,s070wv20-ct16.txt | 7 ++
drivers/gpu/drm/panel/panel-simple.c | 25 +++
2 files changed, 32 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.txt
diff --git
a/Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.txt
b/Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.txt
new file mode 100644
index ..2ec35ce36e9a
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.txt
@@ -0,0 +1,7 @@
+Banana Pi 7" (S070WV20-CT16) TFT LCD Panel
+
+Required properties:
+- compatible: should be "bananapi,s070wv20-ct16"
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index cbf1ab404ee7..9bc037f74d6c 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -745,6 +745,28 @@ static const struct panel_desc avic_tm070ddh03 = {
},
};
+static const struct drm_display_mode bananapi_s070wv20_ct16_mode = {
+ .clock = 3,
+ .hdisplay = 800,
+ .hsync_start = 800 + 40,
+ .hsync_end = 800 + 40 + 48,
+ .htotal = 800 + 40 + 48 + 40,
+ .vdisplay = 480,
+ .vsync_start = 480 + 13,
+ .vsync_end = 480 + 13 + 3,
+ .vtotal = 480 + 13 + 3 + 29,
+};
+
+static const struct panel_desc bananapi_s070wv20_ct16 = {
+ .modes = &bananapi_s070wv20_ct16_mode,
+ .num_modes = 1,
+ .bpc = 6,
+ .size = {
+ .width = 154,
+ .height = 86,
+ },
+};
+
static const struct drm_display_mode boe_nv101wxmn51_modes[] = {
{
.clock = 71900,
@@ -2112,6 +2134,9 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "avic,tm070ddh03",
.data = &avic_tm070ddh03,
+ }, {
+ .compatible = "bananapi,s070wv20-ct16",
+ .data = &bananapi_s070wv20_ct16,
}, {
.compatible = "boe,nv101wxmn51",
.data = &boe_nv101wxmn51,
--
2.17.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 6/6] [DO NOT MERGE] ARM: dts: sun7i: bananapi-m1-plus: Enable Bananapi 7" 800x480 RGB LCD panel
The BPI-M1+ has an FPC connector for connecting an RGB (parallel) or
LVDS LCD panel. One of the compatible panels is a 7" 800x480 RGB panel
from Bananapi. The backlight can be controlled by driving a PWM signal
from the SoC at different duty cycles. The LCD enable pin does not seem
to do anything, but it is nevertheless included for completeness. There
is also a FT5306 capacitive touchscreen controller.
This should not be confused with the other 7" LCD that is LVDS based
and has a resolution of 1024x600.
This patch enables all of the above for the BPI-M1+.
Signed-off-by: Chen-Yu Tsai
---
.../boot/dts/sun7i-a20-bananapi-m1-plus.dts | 61 +++
1 file changed, 61 insertions(+)
diff --git a/arch/arm/boot/dts/sun7i-a20-bananapi-m1-plus.dts
b/arch/arm/boot/dts/sun7i-a20-bananapi-m1-plus.dts
index 763cb03033c4..58a923bfa6ef 100644
--- a/arch/arm/boot/dts/sun7i-a20-bananapi-m1-plus.dts
+++ b/arch/arm/boot/dts/sun7i-a20-bananapi-m1-plus.dts
@@ -47,6 +47,7 @@
#include "sunxi-common-regulators.dtsi"
#include
#include
+#include
/ {
model = "Banana Pi BPI-M1-Plus";
@@ -71,6 +72,34 @@
};
};
+ lcd_backlight: lcd-backlight {
+ compatible = "pwm-backlight";
+ pwms = <&pwm 0 2 PWM_POLARITY_INVERTED>; /* 50 kHz */
+ enable-gpios = <&pio 7 9 GPIO_ACTIVE_HIGH>; /* PH9 */
+ brightness-levels = <0 10 20 30 40 50 60 70 80 90 100>;
+ default-brightness-level = <8>;
+ };
+
+ lcd_panel: lcd-panel {
+ compatible = "bananapi,s070wv20-ct16", "simple-panel";
+ /* This doesn't do anything for this particular panel */
+ enable-gpios = <&pio 7 12 GPIO_ACTIVE_HIGH>; /* PH12 */
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ backlight = <&lcd_backlight>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ lcd_panel_input: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&tcon0_out_lcd>;
+ };
+ };
+ };
+
leds {
compatible = "gpio-leds";
pinctrl-names = "default";
@@ -173,6 +202,20 @@
status = "okay";
};
+&i2c3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c3_pins_a>;
+ status = "okay";
+
+ touchscreen@38 {
+ compatible = "edt,edt-ft5306", "edt,edt-ft5x06";
+ reg = <0x38>;
+ interrupt-parent = <&pio>;
+ interrupts = <7 7 IRQ_TYPE_EDGE_FALLING>; /* PH7 */
+ reset-gpios = <&pio 7 8 GPIO_ACTIVE_LOW>; /* PH8 */
+ };
+};
+
&ir0 {
pinctrl-names = "default";
pinctrl-0 = <&ir0_rx_pins_a>;
@@ -249,6 +292,12 @@
};
};
+&pwm {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pwm0_pins_a>;
+ status = "okay";
+};
+
®_dcdc2 {
regulator-always-on;
regulator-min-microvolt = <100>;
@@ -278,6 +327,18 @@
status = "okay";
};
+&tcon0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&lcd0_rgb888_pins>;
+};
+
+&tcon0_out {
+ tcon0_out_lcd: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&lcd_panel_input>;
+ };
+};
+
&uart0 {
pinctrl-names = "default";
pinctrl-0 = <&uart0_pins_a>;
--
2.17.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/6] drm/sun4i: Support color dithering for LCD panels
Dithering is a method of approximating a color from a mixture of other colors when the required color isn't available. It reduces color banding artifacts that can be observed when displaying gradients (e.g. grayscale gradients). This may occur when the image that needs to be displayed is 24-bit but the LCD panel is a lower bit depth and does not perform dithering on its own. The TCON (LCD controller) found in Allwinner SoCs has hardware support for dithering on channel 0, the channel used to feed LCD panels. This series adds support for it. Patch 1 reworks the mode set function for the CPU interface to pass the encoder object, so it can be passed to other helper functions. Patch 2 renames the dithering related register macros to reflect the fact that dithering is only supported on channel 0. Patch 3 adds support for dithering on all LCD panel output types. Patch 4 adds support for Banana Pi's 7" DPI LCD panel. Patch 5 adds a pinmux setting for RGB888 for the Allwinner A20 SoC. This change has been sent by others before. Patch 6 provides an example for enabling the Banana Pi 7" DPI LCD panel on the Banana Pi M1+. This should not be merged. I will likely rework this into an overlay in the future. Note that I was only able to test dithering with DPI, as I do not have other panel types. However the underlying concept and core code is the same, as are the drm objects accessed. Nevertheless I'm hoping Jonathan can test LVDS and Maxime can test MIPI DSI. Also it seems pwm-backlight hardware is unusable at the moment. I'm not sure whether the pwm-backlight or sun4i-pwm driver is to blame. I had to manually poke the pwm registers so the LCD backlight wouldn't be completely black. Regards ChenYu Chen-Yu Tsai (5): drm/sun4i: tcon: Pass drm_encoder * into sun4i_tcon0_mode_set_cpu drm/sun4i: tcon: Rename Dithering related register macros drm/panel: simple: Add support for Banana Pi 7" S070WV20-CT16 panel ARM: dts: sun7i: add pinmux setting for RGB888 output for LCD0 [DO NOT MERGE] ARM: dts: sun7i: bananapi-m1-plus: Enable Bananapi 7" 800x480 RGB LCD panel Jonathan Liu (1): drm/sun4i: tcon: Add dithering support for RGB565/RGB666 LCD panels .../display/panel/bananapi,s070wv20-ct16.txt | 7 ++ .../boot/dts/sun7i-a20-bananapi-m1-plus.dts | 61 +++ arch/arm/boot/dts/sun7i-a20.dtsi | 11 +++ drivers/gpu/drm/panel/panel-simple.c | 25 ++ drivers/gpu/drm/sun4i/sun4i_tcon.c| 76 --- drivers/gpu/drm/sun4i/sun4i_tcon.h| 27 --- 6 files changed, 186 insertions(+), 21 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.txt -- 2.17.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/6] drm/sun4i: tcon: Pass drm_encoder * into sun4i_tcon0_mode_set_cpu
sun4i_tcon0_mode_set_cpu() currently accepts struct mipi_dsi_device *
as its second parameter. This is derived from drm_encoder.
The DSI encoder is tied to the CPU interface mode of the TCON as a
special case. In theory, if hardware were available, we could also
support normal CPU interface modes. It is better to pass the generic
encoder instead of the specialized mipi_dsi_device, and handle the
differences inside the function.
Passing the encoder would also enable the function to pass it, or any
other data structures related to it, to other functions expecting it.
One such example would be dithering support that will be added in a
later patch, which looks at properties tied to the connector to
determine whether dithering should be enabled or not.
Signed-off-by: Chen-Yu Tsai
---
drivers/gpu/drm/sun4i/sun4i_tcon.c | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index 08747fc3ee71..2bd53ef7d4b8 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -277,9 +277,12 @@ static void sun4i_tcon0_mode_set_common(struct sun4i_tcon
*tcon,
}
static void sun4i_tcon0_mode_set_cpu(struct sun4i_tcon *tcon,
-struct mipi_dsi_device *device,
+struct drm_encoder *encoder,
const struct drm_display_mode *mode)
{
+ /* TODO support normal CPU interface modes */
+ struct sun6i_dsi *dsi = encoder_to_sun6i_dsi(encoder);
+ struct mipi_dsi_device *device = dsi->device;
u8 bpp = mipi_dsi_pixel_format_to_bpp(device->format);
u8 lanes = device->lanes;
u32 block_space, start_delay;
@@ -606,16 +609,10 @@ void sun4i_tcon_mode_set(struct sun4i_tcon *tcon,
const struct drm_encoder *encoder,
const struct drm_display_mode *mode)
{
- struct sun6i_dsi *dsi;
-
switch (encoder->encoder_type) {
case DRM_MODE_ENCODER_DSI:
- /*
-* This is not really elegant, but it's the "cleaner"
-* way I could think of...
-*/
- dsi = encoder_to_sun6i_dsi(encoder);
- sun4i_tcon0_mode_set_cpu(tcon, dsi->device, mode);
+ /* DSI is tied to special case of CPU interface */
+ sun4i_tcon0_mode_set_cpu(tcon, encoder, mode);
break;
case DRM_MODE_ENCODER_LVDS:
sun4i_tcon0_mode_set_lvds(tcon, encoder, mode);
--
2.17.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/6] ARM: dts: sun7i: add pinmux setting for RGB888 output for LCD0
On the A20, as well as many other Allwinner SoCs, the PD pingroup has
the LCD0 RGB output functions.
Add a pinmux setting for RGB888 output from LCD0, so boards and tablets
with parallel RGB LCD panels may reference it.
Signed-off-by: Chen-Yu Tsai
---
arch/arm/boot/dts/sun7i-a20.dtsi | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
index e529e4ff2174..e06c14649d22 100644
--- a/arch/arm/boot/dts/sun7i-a20.dtsi
+++ b/arch/arm/boot/dts/sun7i-a20.dtsi
@@ -920,6 +920,17 @@
pins = "PI20", "PI21";
function = "uart7";
};
+
+ lcd0_rgb888_pins: lcd0-rgb888-pins {
+ pins = "PD0", "PD1", "PD2", "PD3", "PD4",
+ "PD5", "PD6", "PD7", "PD8", "PD9",
+ "PD10", "PD11", "PD12", "PD13",
+ "PD14", "PD15", "PD16", "PD17",
+ "PD18", "PD19", "PD20", "PD21",
+ "PD22", "PD23", "PD24", "PD25",
+ "PD26", "PD27";
+ function = "lcd0";
+ };
};
timer@1c20c00 {
--
2.17.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 2/2] i915: content-type property for HDMI connector
From: Stanislav Lisovskiy Added encoding of drm content_type property from drm_connector_state within AVI infoframe in order to properly handle external HDMI TV content-type setting. This requires also manipulationg ITC bit, as stated in HDMI spec. Signed-off-by: Stanislav Lisovskiy --- drivers/gpu/drm/i915/intel_atomic.c | 2 ++ drivers/gpu/drm/i915/intel_hdmi.c | 4 2 files changed, 6 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_atomic.c b/drivers/gpu/drm/i915/intel_atomic.c index 40285d1b91b7..96a42eb457c5 100644 --- a/drivers/gpu/drm/i915/intel_atomic.c +++ b/drivers/gpu/drm/i915/intel_atomic.c @@ -124,6 +124,8 @@ int intel_digital_connector_atomic_check(struct drm_connector *conn, if (new_conn_state->force_audio != old_conn_state->force_audio || new_conn_state->broadcast_rgb != old_conn_state->broadcast_rgb || new_conn_state->base.picture_aspect_ratio != old_conn_state->base.picture_aspect_ratio || + new_conn_state->base.content_type != old_conn_state->base.content_type || + new_conn_state->base.it_content != old_conn_state->base.it_content || new_conn_state->base.scaling_mode != old_conn_state->base.scaling_mode) crtc_state->mode_changed = true; diff --git a/drivers/gpu/drm/i915/intel_hdmi.c b/drivers/gpu/drm/i915/intel_hdmi.c index ee929f31f7db..078200908b7a 100644 --- a/drivers/gpu/drm/i915/intel_hdmi.c +++ b/drivers/gpu/drm/i915/intel_hdmi.c @@ -491,6 +491,9 @@ static void intel_hdmi_set_avi_infoframe(struct drm_encoder *encoder, intel_hdmi->rgb_quant_range_selectable, is_hdmi2_sink); + frame.avi.content_type = connector->state->content_type; + frame.avi.itc = connector->state->it_content; + /* TODO: handle pixel repetition for YCBCR420 outputs */ intel_write_infoframe(encoder, crtc_state, &frame); } @@ -2065,6 +2068,7 @@ intel_hdmi_add_properties(struct intel_hdmi *intel_hdmi, struct drm_connector *c intel_attach_force_audio_property(connector); intel_attach_broadcast_rgb_property(connector); intel_attach_aspect_ratio_property(connector); + drm_connector_attach_content_type_property(connector); connector->state->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE; } -- 2.17.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 1/2] drm: content-type property for HDMI connector
From: Stanislav Lisovskiy
Added content_type property to
drm_connector_state in order to properly handle
external HDMI TV content-type setting.
Signed-off-by: Stanislav Lisovskiy
---
Documentation/gpu/kms-properties.csv | 1 +
drivers/gpu/drm/drm_atomic.c | 17 ++
drivers/gpu/drm/drm_connector.c | 51
drivers/gpu/drm/drm_edid.c | 2 ++
include/drm/drm_connector.h | 18 ++
include/drm/drm_mode_config.h| 5 +++
include/uapi/drm/drm_mode.h | 7
7 files changed, 101 insertions(+)
diff --git a/Documentation/gpu/kms-properties.csv
b/Documentation/gpu/kms-properties.csv
index 6b28b014cb7d..a91c9211b8d6 100644
--- a/Documentation/gpu/kms-properties.csv
+++ b/Documentation/gpu/kms-properties.csv
@@ -17,6 +17,7 @@ Owner Module/Drivers,Group,Property Name,Type,Property
Values,Object attached,De
,Virtual GPU,“suggested X”,RANGE,"Min=0, Max=0x",Connector,property to
suggest an X offset for a connector
,,“suggested Y”,RANGE,"Min=0, Max=0x",Connector,property to suggest an
Y offset for a connector
,Optional,"""aspect ratio""",ENUM,"{ ""None"", ""4:3"", ""16:9""
}",Connector,TDB
+,Optional,"""content type""",ENUM,"{ ""No data"", ""Graphics"", ""Photo"",
""Cinema"", ""Game"" }",Connector,TBD
i915,Generic,"""Broadcast RGB""",ENUM,"{ ""Automatic"", ""Full"", ""Limited
16:235"" }",Connector,"When this property is set to Limited 16:235 and CTM is
set, the hardware will be programmed with the result of the multiplication of
CTM by the limited range matrix to ensure the pixels normaly in the range
0..1.0 are remapped to the range 16/255..235/255."
,,“audio”,ENUM,"{ ""force-dvi"", ""off"", ""auto"", ""on"" }",Connector,TBD
,SDVO-TV,“mode”,ENUM,"{ ""NTSC_M"", ""NTSC_J"", ""NTSC_443"", ""PAL_B"" }
etc.",Connector,TBD
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 7d25c42f22db..479499f5848e 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1266,6 +1266,15 @@ static int drm_atomic_connector_set_property(struct
drm_connector *connector,
state->link_status = val;
} else if (property == config->aspect_ratio_property) {
state->picture_aspect_ratio = val;
+ } else if (property == config->content_type_property) {
+ /*
+* Lowest two bits of content_type property control
+* content_type, bit 2 controls itc bit.
+* It was decided to have a single property called
+* content_type, instead of content_type and itc.
+*/
+ state->content_type = val & 3;
+ state->it_content = val >> 2;
} else if (property == connector->scaling_mode_property) {
state->scaling_mode = val;
} else if (property == connector->content_protection_property) {
@@ -1351,6 +1360,14 @@ drm_atomic_connector_get_property(struct drm_connector
*connector,
*val = state->link_status;
} else if (property == config->aspect_ratio_property) {
*val = state->picture_aspect_ratio;
+ } else if (property == config->content_type_property) {
+ /*
+* Lowest two bits of content_type property control
+* content_type, bit 2 controls itc bit.
+* It was decided to have a single property called
+* content_type, instead of content_type and itc.
+*/
+ *val = state->content_type | (state->it_content << 2);
} else if (property == connector->scaling_mode_property) {
*val = state->scaling_mode;
} else if (property == connector->content_protection_property) {
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index b3cde897cd80..757a0712f7c1 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -720,6 +720,14 @@ static const struct drm_prop_enum_list
drm_aspect_ratio_enum_list[] = {
{ DRM_MODE_PICTURE_ASPECT_16_9, "16:9" },
};
+static const struct drm_prop_enum_list drm_content_type_enum_list[] = {
+ { DRM_MODE_CONTENT_TYPE_NO_DATA, "No data" },
+ { DRM_MODE_CONTENT_TYPE_GRAPHICS, "Graphics" },
+ { DRM_MODE_CONTENT_TYPE_PHOTO, "Photo" },
+ { DRM_MODE_CONTENT_TYPE_CINEMA, "Cinema" },
+ { DRM_MODE_CONTENT_TYPE_GAME, "Game" },
+};
+
static const struct drm_prop_enum_list drm_panel_orientation_enum_list[] = {
{ DRM_MODE_PANEL_ORIENTATION_NORMAL,"Normal"},
{ DRM_MODE_PANEL_ORIENTATION_BOTTOM_UP, "Upside Down" },
@@ -996,6 +1004,22 @@ int drm_mode_create_dvi_i_properties(struct drm_device
*dev)
}
EXPORT_SYMBOL(drm_mode_create_dvi_i_properties);
+/**
+ * drm_connector_attach_content_type_property - attach content-type property
+ * @dev: DRM device
+ *
+ * Called by a driver the first time a
[PATCH v4 0/2] Enabling content-type setting for HDMI displays.
From: Stanislav Lisovskiy Rev 1: Added content type setting property to drm_connector(part 1) and enabled transmitting it with HDMI AVI infoframes for i915(part 2). Rev 2: Moved helper function which attaches content type property to the drm core, as was suggested. Removed redundant connector state initialization. Rev 3: Removed caps in drm_content_type_enum_list. After some discussion it turned out that HDMI Spec 1.4 was wrongly assuming that IT Content(itc) bit doesn't affect Content type states, however itc bit needs to be manupulated as well. In order to not expose additional property for itc, for sake of simplicity it was decided to bind those together in same "content type" property. Rev 4: Added it_content checking in intel_digital_connector_atomic_check. Fixed documentation for new content type enum. Stanislav Lisovskiy (2): drm: content-type property for HDMI connector i915: content-type property for HDMI connector Documentation/gpu/kms-properties.csv | 1 + drivers/gpu/drm/drm_atomic.c | 17 ++ drivers/gpu/drm/drm_connector.c | 51 drivers/gpu/drm/drm_edid.c | 2 ++ drivers/gpu/drm/i915/intel_atomic.c | 2 ++ drivers/gpu/drm/i915/intel_hdmi.c| 4 +++ include/drm/drm_connector.h | 18 ++ include/drm/drm_mode_config.h| 5 +++ include/uapi/drm/drm_mode.h | 7 9 files changed, 107 insertions(+) -- 2.17.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v8 1/2] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder
Hi Jacopo, Laurent, On 04/10/2018 01:53 PM, Jacopo Mondi wrote: > Document Thine THC63LVD1024 LVDS decoder device tree bindings. > > Signed-off-by: Jacopo Mondi > Reviewed-by: Andrzej Hajda > Reviewed-by: Niklas Söderlund > Reviewed-by: Laurent Pinchart Reviewed-by: Vladimir Zapolskiy > --- > .../bindings/display/bridge/thine,thc63lvd1024.txt | 60 > ++ > 1 file changed, 60 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt > > diff --git > a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt > b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt > new file mode 100644 > index 000..0b23e70 > --- /dev/null > +++ b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt > @@ -0,0 +1,60 @@ > +Thine Electronics THC63LVD1024 LVDS decoder > +--- > + > +The THC63LVD1024 is a dual link LVDS receiver designed to convert LVDS > streams > +to parallel data outputs. The chip supports single/dual input/output modes, > +handling up to two LVDS input streams and up to two digital CMOS/TTL outputs. > + > +Single or dual operation mode, output data mapping and DDR output modes are > +configured through input signals and the chip does not expose any control > bus. > + > +Required properties: > +- compatible: Shall be "thine,thc63lvd1024" > +- vcc-supply: Power supply for TTL output, TTL CLOCKOUT signal, LVDS input, > + PPL and digital circuitry > + > +Optional properties: > +- powerdown-gpios: Power down GPIO signal, pin name "/PDWN". Active low Thank you for the change. I would suggest to rename 'pwdn-gpios' property of THC63LVDM83D as well, as far as I understand it is only described in DT bindings documentation, and the property is unused in the driver or board DTS files at the moment. > +- oe-gpios: Output enable GPIO signal, pin name "OE". Active high Okay :) -- With best wishes, Vladimir ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/bridge: sii902x: add optional power supplies
Hi Laurent :-)
On 04/19/2018 10:20 AM, Laurent Pinchart wrote:
> Hi Philippe,
>
> Thank you for the patch.
>
> On Tuesday, 10 April 2018 08:19:27 EEST Philippe Cornu wrote:
>> Add the 3 optional power supplies using the exact description
>> found in the document named
>> "SiI9022A/SiI9024A HDMI Transmitter Data Sheet (August 2016)".
>>
>> Signed-off-by: Philippe Cornu
>> ---
>> drivers/gpu/drm/bridge/sii902x.c | 39 +
>> 1 file changed, 35 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/bridge/sii902x.c
>> b/drivers/gpu/drm/bridge/sii902x.c index 60373d7eb220..e17ba6db1ec8 100644
>> --- a/drivers/gpu/drm/bridge/sii902x.c
>> +++ b/drivers/gpu/drm/bridge/sii902x.c
>> @@ -24,6 +24,7 @@
>> #include
>> #include
>> #include
>> +#include
>>
>> #include
>> #include
>> @@ -86,6 +87,7 @@ struct sii902x {
>> struct drm_bridge bridge;
>> struct drm_connector connector;
>> struct gpio_desc *reset_gpio;
>> +struct regulator_bulk_data supplies[3];
>> };
>>
>> static inline struct sii902x *bridge_to_sii902x(struct drm_bridge *bridge)
>> @@ -392,23 +394,43 @@ static int sii902x_probe(struct i2c_client *client,
>> return PTR_ERR(sii902x->reset_gpio);
>> }
>>
>> +sii902x->supplies[0].supply = "iovcc";
>> +sii902x->supplies[1].supply = "avcc12";
>> +sii902x->supplies[2].supply = "cvcc12";
>> +ret = devm_regulator_bulk_get(dev, ARRAY_SIZE(sii902x->supplies),
>> + sii902x->supplies);
>> +if (ret) {
>> +dev_err(dev, "regulator_bulk_get failed\n");
>
> Maybe "failed to get power supplies" to be a bit more explicit ? And while at
> it, printing the value of ret too ?
>
good point, I will do that in v2
>> +return ret;
>> +}
>> +
>> +ret = regulator_bulk_enable(ARRAY_SIZE(sii902x->supplies),
>> +sii902x->supplies);
>> +if (ret) {
>> +dev_err(dev, "regulator_bulk_enable failed\n");
>
> Same here ?
>
agreed
>> +return ret;
>> +}
>> +
>> +usleep_range(1, 2);
>> +
>> sii902x_reset(sii902x);
>>
>> ret = regmap_write(sii902x->regmap, SII902X_REG_TPI_RQB, 0x0);
>> if (ret)
>> -return ret;
>> +goto err_disable_regulator;
>>
>> ret = regmap_bulk_read(sii902x->regmap, SII902X_REG_CHIPID(0),
>> &chipid, 4);
>> if (ret) {
>> dev_err(dev, "regmap_read failed %d\n", ret);
>> -return ret;
>> +goto err_disable_regulator;
>> }
>>
>> if (chipid[0] != 0xb0) {
>> dev_err(dev, "Invalid chipid: %02x (expecting 0xb0)\n",
>> chipid[0]);
>> -return -EINVAL;
>> +ret = -EINVAL;
>> +goto err_disable_regulator;
>> }
>>
>> /* Clear all pending interrupts */
>> @@ -424,7 +446,7 @@ static int sii902x_probe(struct i2c_client *client,
>> IRQF_ONESHOT, dev_name(dev),
>> sii902x);
>> if (ret)
>> -return ret;
>> +goto err_disable_regulator;
>> }
>>
>> sii902x->bridge.funcs = &sii902x_bridge_funcs;
>> @@ -434,6 +456,12 @@ static int sii902x_probe(struct i2c_client *client,
>> i2c_set_clientdata(client, sii902x);
>>
>> return 0;
>> +
>> +err_disable_regulator:
>> +regulator_bulk_disable(ARRAY_SIZE(sii902x->supplies),
>> + sii902x->supplies);
>> +
>> +return ret;
>> }
>>
>> static int sii902x_remove(struct i2c_client *client)
>> @@ -443,6 +471,9 @@ static int sii902x_remove(struct i2c_client *client)
>>
>> drm_bridge_remove(&sii902x->bridge);
>>
>> +regulator_bulk_disable(ARRAY_SIZE(sii902x->supplies),
>> + sii902x->supplies);
>> +
>
> While this seems functionally correct, would it be useful to only enable power
> supplies when needed to save power ?
>
that is a good point. I do not know well (yet) this bridge. Maybe I can
add a 3rd patch with bridge pre_enable() and post_disable() containing
reset & supplies management. Or I can put reset&supplies in bridge
enable() & disable() but it could be a little messy.
Any opinion/advice?
Many thanks,
Philippe :-)
>> return 0;
>> }
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v8 1/2] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder
Hi Jacopo, On 04/19/2018 12:44 PM, Vladimir Zapolskiy wrote: > Hi Jacopo, Laurent, > > On 04/10/2018 01:53 PM, Jacopo Mondi wrote: >> Document Thine THC63LVD1024 LVDS decoder device tree bindings. >> >> Signed-off-by: Jacopo Mondi >> Reviewed-by: Andrzej Hajda >> Reviewed-by: Niklas Söderlund >> Reviewed-by: Laurent Pinchart > > Reviewed-by: Vladimir Zapolskiy > >> --- >> .../bindings/display/bridge/thine,thc63lvd1024.txt | 60 >> ++ >> 1 file changed, 60 insertions(+) >> create mode 100644 >> Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt >> >> diff --git >> a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt >> b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt >> new file mode 100644 >> index 000..0b23e70 >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt >> @@ -0,0 +1,60 @@ >> +Thine Electronics THC63LVD1024 LVDS decoder >> +--- >> + >> +The THC63LVD1024 is a dual link LVDS receiver designed to convert LVDS >> streams >> +to parallel data outputs. The chip supports single/dual input/output modes, >> +handling up to two LVDS input streams and up to two digital CMOS/TTL >> outputs. >> + >> +Single or dual operation mode, output data mapping and DDR output modes are >> +configured through input signals and the chip does not expose any control >> bus. >> + >> +Required properties: >> +- compatible: Shall be "thine,thc63lvd1024" >> +- vcc-supply: Power supply for TTL output, TTL CLOCKOUT signal, LVDS input, >> + PPL and digital circuitry >> + >> +Optional properties: >> +- powerdown-gpios: Power down GPIO signal, pin name "/PDWN". Active low > sorry for a follow-up, I've just noticed it, could you please double check spelling PDWN vs PWDN? Thank you in advance. -- With best wishes, Vladimir ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v8 1/2] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder
Hi Jacopo, On 04/19/2018 12:48 PM, Vladimir Zapolskiy wrote: > Hi Jacopo, > > On 04/19/2018 12:44 PM, Vladimir Zapolskiy wrote: >> Hi Jacopo, Laurent, >> >> On 04/10/2018 01:53 PM, Jacopo Mondi wrote: >>> Document Thine THC63LVD1024 LVDS decoder device tree bindings. >>> >>> Signed-off-by: Jacopo Mondi >>> Reviewed-by: Andrzej Hajda >>> Reviewed-by: Niklas Söderlund >>> Reviewed-by: Laurent Pinchart >> >> Reviewed-by: Vladimir Zapolskiy >> >>> --- [snip] >>> +Optional properties: >>> +- powerdown-gpios: Power down GPIO signal, pin name "/PDWN". Active low >> > > sorry for a follow-up, I've just noticed it, could you please double check > spelling PDWN vs PWDN? Thank you in advance. > please ignore it, I did it myself and the datasheet describes pin as /PDWN, I won't exclude a typo in the datasheet though... -- With best wishes, Vladimir ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v8 1/2] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder
On Thu, Apr 19, 2018 at 12:44:32PM +0300, Vladimir Zapolskiy wrote: Hi Vladimir, > Hi Jacopo, Laurent, > > On 04/10/2018 01:53 PM, Jacopo Mondi wrote: > > Document Thine THC63LVD1024 LVDS decoder device tree bindings. > > > > Signed-off-by: Jacopo Mondi > > Reviewed-by: Andrzej Hajda > > Reviewed-by: Niklas Söderlund > > Reviewed-by: Laurent Pinchart > > Reviewed-by: Vladimir Zapolskiy > > > --- > > .../bindings/display/bridge/thine,thc63lvd1024.txt | 60 > > ++ > > 1 file changed, 60 insertions(+) > > create mode 100644 > > Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt > > > > diff --git > > a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt > > b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt > > new file mode 100644 > > index 000..0b23e70 > > --- /dev/null > > +++ > > b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt > > @@ -0,0 +1,60 @@ > > +Thine Electronics THC63LVD1024 LVDS decoder > > +--- > > + > > +The THC63LVD1024 is a dual link LVDS receiver designed to convert LVDS > > streams > > +to parallel data outputs. The chip supports single/dual input/output modes, > > +handling up to two LVDS input streams and up to two digital CMOS/TTL > > outputs. > > + > > +Single or dual operation mode, output data mapping and DDR output modes are > > +configured through input signals and the chip does not expose any control > > bus. > > + > > +Required properties: > > +- compatible: Shall be "thine,thc63lvd1024" > > +- vcc-supply: Power supply for TTL output, TTL CLOCKOUT signal, LVDS input, > > + PPL and digital circuitry > > + > > +Optional properties: > > +- powerdown-gpios: Power down GPIO signal, pin name "/PDWN". Active low > > Thank you for the change. > > I would suggest to rename 'pwdn-gpios' property of THC63LVDM83D as well, > as far as I understand it is only described in DT bindings documentation, > and the property is unused in the driver or board DTS files at the moment. Thanks for the suggestion, I'll do that! > > > +- oe-gpios: Output enable GPIO signal, pin name "OE". Active high > > Okay :) Yeah, please see Rob's and Laurent's reply to v7, where I renamed this to 'enable'. Thanks j > > -- > With best wishes, > Vladimir signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/stm: move enable/disable_vblank to crtc
Applied on drm-misc-next.
Many thanks,
Philippe :-)
On 04/16/2018 11:07 AM, Vincent ABRIOU wrote:
> Hi Philippe,
>
> Patch looks good to me.
>
> Reviewed-by: Vincent Abriou
>
> On 04/07/2018 11:29 PM, Philippe Cornu wrote:
>> enable/disable_vblank() functions at drm_driver level
>> are deprecated. Move them to the ltdc drm_crtc_funcs
>> structure.
>>
>> Signed-off-by: Philippe Cornu
>> ---
>>drivers/gpu/drm/stm/drv.c | 2 --
>>drivers/gpu/drm/stm/ltdc.c | 10 ++
>>drivers/gpu/drm/stm/ltdc.h | 2 --
>>3 files changed, 6 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/stm/drv.c b/drivers/gpu/drm/stm/drv.c
>> index 9ab00a87f7cc..8698e08313e1 100644
>> --- a/drivers/gpu/drm/stm/drv.c
>> +++ b/drivers/gpu/drm/stm/drv.c
>> @@ -72,8 +72,6 @@ static struct drm_driver drv_driver = {
>> .gem_prime_vmap = drm_gem_cma_prime_vmap,
>> .gem_prime_vunmap = drm_gem_cma_prime_vunmap,
>> .gem_prime_mmap = drm_gem_cma_prime_mmap,
>> -.enable_vblank = ltdc_crtc_enable_vblank,
>> -.disable_vblank = ltdc_crtc_disable_vblank,
>>};
>>
>>static int drv_load(struct drm_device *ddev)
>> diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c
>> index 1a3277e483d5..2b745cfc9000 100644
>> --- a/drivers/gpu/drm/stm/ltdc.c
>> +++ b/drivers/gpu/drm/stm/ltdc.c
>> @@ -569,9 +569,9 @@ static const struct drm_crtc_helper_funcs
>> ltdc_crtc_helper_funcs = {
>> .atomic_disable = ltdc_crtc_atomic_disable,
>>};
>>
>> -int ltdc_crtc_enable_vblank(struct drm_device *ddev, unsigned int pipe)
>> +static int ltdc_crtc_enable_vblank(struct drm_crtc *crtc)
>>{
>> -struct ltdc_device *ldev = ddev->dev_private;
>> +struct ltdc_device *ldev = crtc_to_ltdc(crtc);
>>
>> DRM_DEBUG_DRIVER("\n");
>> reg_set(ldev->regs, LTDC_IER, IER_LIE);
>> @@ -579,9 +579,9 @@ int ltdc_crtc_enable_vblank(struct drm_device *ddev,
>> unsigned int pipe)
>> return 0;
>>}
>>
>> -void ltdc_crtc_disable_vblank(struct drm_device *ddev, unsigned int pipe)
>> +static void ltdc_crtc_disable_vblank(struct drm_crtc *crtc)
>>{
>> -struct ltdc_device *ldev = ddev->dev_private;
>> +struct ltdc_device *ldev = crtc_to_ltdc(crtc);
>>
>> DRM_DEBUG_DRIVER("\n");
>> reg_clear(ldev->regs, LTDC_IER, IER_LIE);
>> @@ -594,6 +594,8 @@ static const struct drm_crtc_funcs ltdc_crtc_funcs = {
>> .reset = drm_atomic_helper_crtc_reset,
>> .atomic_duplicate_state = drm_atomic_helper_crtc_duplicate_state,
>> .atomic_destroy_state = drm_atomic_helper_crtc_destroy_state,
>> +.enable_vblank = ltdc_crtc_enable_vblank,
>> +.disable_vblank = ltdc_crtc_disable_vblank,
>> .gamma_set = drm_atomic_helper_legacy_gamma_set,
>>};
>>
>> diff --git a/drivers/gpu/drm/stm/ltdc.h b/drivers/gpu/drm/stm/ltdc.h
>> index edb268129c54..61a80d00bc3b 100644
>> --- a/drivers/gpu/drm/stm/ltdc.h
>> +++ b/drivers/gpu/drm/stm/ltdc.h
>> @@ -29,8 +29,6 @@ struct ltdc_device {
>> u32 irq_status;
>>};
>>
>> -int ltdc_crtc_enable_vblank(struct drm_device *dev, unsigned int pipe);
>> -void ltdc_crtc_disable_vblank(struct drm_device *dev, unsigned int pipe);
>>int ltdc_load(struct drm_device *ddev);
>>void ltdc_unload(struct drm_device *ddev);
>>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/stm: ltdc: add user update info in plane print state
Applied on drm-misc-next.
Many thanks,
Philippe :-)
On 04/16/2018 11:14 AM, Vincent ABRIOU wrote:
> Hi Philippe,
>
> Reviewed-by: Vincent Abriou
>
> On 04/07/2018 11:35 PM, Philippe Cornu wrote:
>> This patch adds the user update information in
>> frames-per-second into the drm debugfs plane state.
>>
>> Signed-off-by: Philippe Cornu
>> ---
>>drivers/gpu/drm/stm/ltdc.c | 22 ++
>>drivers/gpu/drm/stm/ltdc.h | 8
>>2 files changed, 30 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c
>> index 2b745cfc9000..061d2b6e5157 100644
>> --- a/drivers/gpu/drm/stm/ltdc.c
>> +++ b/drivers/gpu/drm/stm/ltdc.c
>> @@ -729,6 +729,8 @@ static void ltdc_plane_atomic_update(struct drm_plane
>> *plane,
>> reg_update_bits(ldev->regs, LTDC_L1CR + lofs,
>> LXCR_LEN | LXCR_CLUTEN, val);
>>
>> +ldev->plane_fpsi[plane->index].counter++;
>> +
>> mutex_lock(&ldev->err_lock);
>> if (ldev->error_status & ISR_FUIF) {
>> DRM_DEBUG_DRIVER("Fifo underrun\n");
>> @@ -754,6 +756,25 @@ static void ltdc_plane_atomic_disable(struct drm_plane
>> *plane,
>> oldstate->crtc->base.id, plane->base.id);
>>}
>>
>> +static void ltdc_plane_atomic_print_state(struct drm_printer *p,
>> + const struct drm_plane_state *state)
>> +{
>> +struct drm_plane *plane = state->plane;
>> +struct ltdc_device *ldev = plane_to_ltdc(plane);
>> +struct fps_info *fpsi = &ldev->plane_fpsi[plane->index];
>> +int ms_since_last;
>> +ktime_t now;
>> +
>> +now = ktime_get();
>> +ms_since_last = ktime_to_ms(ktime_sub(now, fpsi->last_timestamp));
>> +
>> +drm_printf(p, "\tuser_updates=%dfps\n",
>> + DIV_ROUND_CLOSEST(fpsi->counter * 1000, ms_since_last));
>> +
>> +fpsi->last_timestamp = now;
>> +fpsi->counter = 0;
>> +}
>> +
>>static const struct drm_plane_funcs ltdc_plane_funcs = {
>> .update_plane = drm_atomic_helper_update_plane,
>> .disable_plane = drm_atomic_helper_disable_plane,
>> @@ -761,6 +782,7 @@ static const struct drm_plane_funcs ltdc_plane_funcs = {
>> .reset = drm_atomic_helper_plane_reset,
>> .atomic_duplicate_state = drm_atomic_helper_plane_duplicate_state,
>> .atomic_destroy_state = drm_atomic_helper_plane_destroy_state,
>> +.atomic_print_state = ltdc_plane_atomic_print_state,
>>};
>>
>>static const struct drm_plane_helper_funcs ltdc_plane_helper_funcs = {
>> diff --git a/drivers/gpu/drm/stm/ltdc.h b/drivers/gpu/drm/stm/ltdc.h
>> index 61a80d00bc3b..1e16d6afb0d2 100644
>> --- a/drivers/gpu/drm/stm/ltdc.h
>> +++ b/drivers/gpu/drm/stm/ltdc.h
>> @@ -20,6 +20,13 @@ struct ltdc_caps {
>> bool non_alpha_only_l1; /* non-native no-alpha formats on layer 1 */
>>};
>>
>> +#define LTDC_MAX_LAYER 4
>> +
>> +struct fps_info {
>> +unsigned int counter;
>> +ktime_t last_timestamp;
>> +};
>> +
>>struct ltdc_device {
>> void __iomem *regs;
>> struct clk *pixel_clk; /* lcd pixel clock */
>> @@ -27,6 +34,7 @@ struct ltdc_device {
>> struct ltdc_caps caps;
>> u32 error_status;
>> u32 irq_status;
>> +struct fps_info plane_fpsi[LTDC_MAX_LAYER];
>>};
>>
>>int ltdc_load(struct drm_device *ddev);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/stm: ltdc: fix warning in ltdc_crtc_update_clut()
Applied on drm-misc-next. Many thanks, Philippe :-) On 04/16/2018 11:18 AM, Yannick FERTRE wrote: > Reviewed-by: yannick fertre > > > On 04/10/2018 03:53 PM, Philippe Cornu wrote: >> Fix the warning >> "warn: variable dereferenced before check 'crtc' (see line 390)" >> by removing unnecessary checks as ltdc_crtc_update_clut() is >> only called from ltdc_crtc_atomic_flush() where crtc and >> crtc->state are not NULL. >> >> Many thanks to Dan Carpenter for the bug report >> https://lists.freedesktop.org/archives/dri-devel/2018-February/166918.html >> >> Signed-off-by: Philippe Cornu >> Reported-by: Dan Carpenter >> --- >>drivers/gpu/drm/stm/ltdc.c | 3 --- >>1 file changed, 3 deletions(-) >> >> diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c >> index 061d2b6e5157..e3121d9e4230 100644 >> --- a/drivers/gpu/drm/stm/ltdc.c >> +++ b/drivers/gpu/drm/stm/ltdc.c >> @@ -392,9 +392,6 @@ static void ltdc_crtc_update_clut(struct drm_crtc *crtc) >> u32 val; >> int i; >> >> -if (!crtc || !crtc->state) >> -return; >> - >> if (!crtc->state->color_mgmt_changed || !crtc->state->gamma_lut) >> return; >> ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/bridge/synopsys: dsi: Adopt SPDX identifiers
Applied on drm-misc-next. Many thanks, Philippe :-) On 02/08/2018 05:46 PM, Laurent Pinchart wrote: > Hi Philippe, > > Thank you for the patch. > > On Thursday, 8 February 2018 16:58:05 EET Philippe Cornu wrote: >> Add SPDX identifiers to the Synopsys DesignWare MIPI DSI >> host controller driver. >> >> Signed-off-by: Philippe Cornu > > Reviewed-by: Laurent Pinchart > >> --- >> Changes in v2: Update to "GPL-2.0+" following comments from Laurent >> Pinchart, Benjamin Gaignard & Philippe Ombredanne. >> >> drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 6 +- >> 1 file changed, 1 insertion(+), 5 deletions(-) >> >> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c >> b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c index >> 7bac101c285c..99f0e4f51716 100644 >> --- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c >> +++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c >> @@ -1,12 +1,8 @@ >> +// SPDX-License-Identifier: GPL-2.0+ >> /* >>* Copyright (c) 2016, Fuzhou Rockchip Electronics Co., Ltd >>* Copyright (C) STMicroelectronics SA 2017 >>* >> - * This program is free software; you can redistribute it and/or modify >> - * it under the terms of the GNU General Public License as published by >> - * the Free Software Foundation; either version 2 of the License, or >> - * (at your option) any later version. >> - * >>* Modified by Philippe Cornu >>* This generic Synopsys DesignWare MIPI DSI host driver is based on the >>* Rockchip version from rockchip/dw-mipi-dsi.c with phy & bridge APIs. > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/bridge: sii902x: add optional power supplies
Hi Philippe, On Thursday, 19 April 2018 12:46:31 EEST Philippe CORNU wrote: > On 04/19/2018 10:20 AM, Laurent Pinchart wrote: > > On Tuesday, 10 April 2018 08:19:27 EEST Philippe Cornu wrote: > > > >> Add the 3 optional power supplies using the exact description > >> found in the document named > >> "SiI9022A/SiI9024A HDMI Transmitter Data Sheet (August 2016)". > >> > >> Signed-off-by: Philippe Cornu > >> --- > >> drivers/gpu/drm/bridge/sii902x.c | 39 +++ > >> 1 file changed, 35 insertions(+), 4 deletions(-) > >> > >> diff --git a/drivers/gpu/drm/bridge/sii902x.c > >> b/drivers/gpu/drm/bridge/sii902x.c index 60373d7eb220..e17ba6db1ec8 > >> 100644 > >> --- a/drivers/gpu/drm/bridge/sii902x.c > >> +++ b/drivers/gpu/drm/bridge/sii902x.c [snip] > >> @@ -443,6 +471,9 @@ static int sii902x_remove(struct i2c_client *client) > >> > >>drm_bridge_remove(&sii902x->bridge); > >> > >> + regulator_bulk_disable(ARRAY_SIZE(sii902x->supplies), > >> + sii902x->supplies); > >> + > > > > While this seems functionally correct, would it be useful to only enable > > power supplies when needed to save power ? > that is a good point. I do not know well (yet) this bridge. Maybe I can > add a 3rd patch with bridge pre_enable() and post_disable() containing > reset & supplies management. Or I can put reset&supplies in bridge > enable() & disable() but it could be a little messy. > > Any opinion/advice? I'm not familiar with this bridge yet, so we need to be careful. The first point you need to check is the hardware requirements regarding power supply sequencing. For instance could it damage the chip if the I/O supply is turned off while the I/O pins are externally driven ? Can the core supplies be turned off with the I/O supply on ? Then, based on the hardware limitations, you should pick the appropriate location for power handling. > >>return 0; > >> } -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] dt-bindings/display/bridge: sii902x: add optional power supplies
Hi Philippe, On Thursday, 19 April 2018 12:31:15 EEST Philippe CORNU wrote: > On 04/19/2018 10:11 AM, Laurent Pinchart wrote: > > On Tuesday, 10 April 2018 08:19:26 EEST Philippe Cornu wrote: > > > >> Add the 3 optional power supplies using the exact description > >> found in the document named > >> "SiI9022A/SiI9024A HDMI Transmitter Data Sheet (August 2016)". > >> > >> Signed-off-by: Philippe Cornu > >> --- > >> > >> Documentation/devicetree/bindings/display/bridge/sii902x.txt | 3 +++ > >> 1 file changed, 3 insertions(+) > >> > >> diff --git > >> a/Documentation/devicetree/bindings/display/bridge/sii902x.txt > >> b/Documentation/devicetree/bindings/display/bridge/sii902x.txt index > >> 56a3e68ccb80..cf53678fe574 100644 > >> --- a/Documentation/devicetree/bindings/display/bridge/sii902x.txt > >> +++ b/Documentation/devicetree/bindings/display/bridge/sii902x.txt > >> @@ -8,6 +8,9 @@ Optional properties: > >>- interrupts-extended or interrupt-parent + interrupts: describe > >> the interrupt line used to inform the host about hotplug events. > >>- reset-gpios: OF device-tree gpio specification for RST_N pin. > >> + - iovcc-supply: I/O supply voltage (1.8V or 3.3V, host-dependent). > >> + - avcc12-supply: TMDS analog supply voltage (1.2V). > >> + - cvcc12-supply: Digital core supply voltage (1.2V). > > > > It seems that the AVCC12 and CVCC12 power supplies are usually derived > > from the same source. How about starting with one DT property for both, > > and adding a second one later if needed ? > > Well, I do not know what is the best. Here I took the description from > the documentation, and to allow all possible board configurations, I > added these supplies as "optional" properties: if there is only one 1v2 > regulator on the board, the dt will contain only avcc12 or cvcc12 and > everything will work fine (we will have a dummy regulator for the > missing optional 1v2 reg), if both regulators are there for any reasons > (stability, noise, whatever...) then both entries will be in the dt. > > If you confirm you prefer a single 1v2 supply (named for instance > "vcc12-supply") then I will do :-) Please see https://lists.freedesktop.org/archives/dri-devel/2018-April/ 172400.html (and the messages that lead to it) and https:// lists.freedesktop.org/archives/dri-devel/2018-March/170763.html. > >> Optional subnodes: > >>- video input: this subnode can contain a video input port node -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v8 2/2] drm: bridge: Add thc63lvd1024 LVDS decoder driver
Hi Jacopo,
On 04/10/2018 01:53 PM, Jacopo Mondi wrote:
> Add DRM bridge driver for Thine THC63LVD1024 LVDS to digital parallel
> output converter.
>
> Signed-off-by: Jacopo Mondi
> Reviewed-by: Andrzej Hajda
> Reviewed-by: Niklas Söderlund
Reviewed-by: Vladimir Zapolskiy
Generally I have only one pretty ignorable comment.
> +
> +enum thc63_ports {
> + THC63_LVDS_IN0,
> + THC63_LVDS_IN1,
> + THC63_RGB_OUT0,
> + THC63_RGB_OUT1,
> +};
> +
The driver uses only THC63_RGB_OUT0 value, or port@2, and MODE{0,1,2} IC
configuration is ignored.
I don't know if right from the beginning it would be better to support
dual-out modes, preferably both single-in and dual-in ones. Will it
impact port enumeration?
I do understand that the extension is possible, and likely only hardware
accessibility postpones it.
--
With best wishes,
Vladimir
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 0/2] Enabling content-type setting for HDMI displays.
On Thu, Apr 19, 2018 at 10:58:44AM +0300, StanLis wrote: > From: Stanislav Lisovskiy > > Rev 1: > Added content type setting property to drm_connector(part 1) > and enabled transmitting it with HDMI AVI infoframes > for i915(part 2). > > Rev 2: > Moved helper function which attaches content type property > to the drm core, as was suggested. > Removed redundant connector state initialization. > > Rev 3: > Removed caps in drm_content_type_enum_list. > After some discussion it turned out that HDMI Spec 1.4 > was wrongly assuming that IT Content(itc) bit doesn't affect > Content type states, however itc bit needs to be manupulated > as well. In order to not expose additional property for itc, > for sake of simplicity it was decided to bind those together > in same "content type" property. Please put these changelogs into the commit messages themselves. Plenty of examples of that practice in git log -- drivers/gpu/drm > > Stanislav Lisovskiy (2): > drm: content-type property for HDMI connector > i915: content-type property for HDMI connector > > Documentation/gpu/kms-properties.csv | 1 + > drivers/gpu/drm/drm_atomic.c | 5 +++ > drivers/gpu/drm/drm_connector.c | 51 > drivers/gpu/drm/drm_edid.c | 2 ++ > drivers/gpu/drm/i915/intel_atomic.c | 1 + > drivers/gpu/drm/i915/intel_hdmi.c| 4 +++ > include/drm/drm_connector.h | 17 ++ > include/drm/drm_mode_config.h| 5 +++ > include/uapi/drm/drm_mode.h | 7 > 9 files changed, 93 insertions(+) > > -- > 2.17.0 -- Ville Syrjälä Intel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/rockchip: vop: fixup linebuffer mode calc error
在 2018/4/17 19:14, Heiko Stuebner 写道: Hi Sandy, Am Dienstag, 17. April 2018, 12:15:07 CEST schrieb Sandy Huang: When video width is bigger than 3840 the linebuffer mode should be LB_YUV_3840X5. Can you explain that a bit better? I.e. when looking at the code, the very first check is width > 2560. So it seems your change targets some YUV mode with width > 3840 which should be mentioned in the commit message, so people like me don't scratch their head in confusion ;-) Similarly that check is actually width > 1280 to set LB_YUV_3840X5, so I guess you're actually wanting any YUV mode bigger than 1280px should use LB_YUV_3840X5? Heiko Thanks heiko, I will make more description for this path at next version. Signed-off-by: Sandy Huang --- drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h index 56bbd2e..3e7501b 100644 --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h @@ -332,7 +332,7 @@ static inline int scl_vop_cal_lb_mode(int width, bool is_yuv) if (width > 2560) lb_mode = LB_RGB_3840X2; - else if (width > 1920) + else if (!is_yuv && width > 1920) lb_mode = LB_RGB_2560X4; else if (!is_yuv) lb_mode = LB_RGB_1920X5; ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v8 2/2] drm: bridge: Add thc63lvd1024 LVDS decoder driver
Hi Vladimir,
On Thu, Apr 19, 2018 at 02:18:30PM +0300, Vladimir Zapolskiy wrote:
> Hi Jacopo,
>
> On 04/10/2018 01:53 PM, Jacopo Mondi wrote:
> > Add DRM bridge driver for Thine THC63LVD1024 LVDS to digital parallel
> > output converter.
> >
> > Signed-off-by: Jacopo Mondi
> > Reviewed-by: Andrzej Hajda
> > Reviewed-by: Niklas Söderlund
>
> Reviewed-by: Vladimir Zapolskiy
>
Thanks. FYI I sent v9 yesterday with a minimal change compared to v8.
> Generally I have only one pretty ignorable comment.
>
> > +
> > +enum thc63_ports {
> > + THC63_LVDS_IN0,
> > + THC63_LVDS_IN1,
> > + THC63_RGB_OUT0,
> > + THC63_RGB_OUT1,
> > +};
> > +
>
> The driver uses only THC63_RGB_OUT0 value, or port@2, and MODE{0,1,2} IC
> configuration is ignored.
>
> I don't know if right from the beginning it would be better to support
> dual-out modes, preferably both single-in and dual-in ones. Will it
> impact port enumeration?
The bindings have been designed to support dual in/out modes, as you
can see there are 4 possible ports described there:
Required video port nodes:
- port@0: First LVDS input port
- port@2: First digital CMOS/TTL parallel output
Optional video port nodes:
- port@1: Second LVDS input port
- port@3: Second digital CMOS/TTL parallel output
Future extension should not require changing the port enumeration,
just add a property to specify the selected mode.
>
> I do understand that the extension is possible, and likely only hardware
> accessibility postpones it.
Yes, hardware on one side, but also what I think is a shortcoming of
DRM (which exists in other sub-systems, say v4l2) that matches devices
on their OF device nodes and makes cumbersome handling drivers wanting
to register on 'port' nodes instead, as it would happen if you have 2
input endpoints.
See my [1] note here: https://lkml.org/lkml/2018/3/9/422
And this reply to Archit's comment which has been left floating as it
is not a real issue (yet): https://lkml.org/lkml/2018/3/10/214
Thanks
j
>
> --
> With best wishes,
> Vladimir
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/6] drm/panel: simple: Add support for Banana Pi 7" S070WV20-CT16 panel
Hi,
Il 19/04/2018 11:32, Chen-Yu Tsai ha scritto:
This panel is marketed as Banana Pi 7" LCD display. On the back is
a sticker denoting the model name S070WV20-CT16.
Judging from the code, the real vendor should be CDTech.
Take a look at their website:
http://www.cdtech-lcd.com/en/standardscreen.html
I point you my patch for inserting another similar panel:
https://patchwork.freedesktop.org/patch/211914/
Maybe it would make sense to use CDTech as the vendor,
because maybe Bananapi resells only it.
Or maybe it is a custom panel done for them,
but the same is for other panels I've submitted patches.
Micronova srl custom, but vendor is CDTech.
What do you think?
--
Giulio Benetti
CTO
MICRONOVA SRL
Sede: Via A. Niedda 3 - 35010 Vigonza (PD)
Tel. 049/8931563 - Fax 049/8931346
Cod.Fiscale - P.IVA 02663420285
Capitale Sociale € 26.000 i.v.
Iscritta al Reg. Imprese di Padova N. 02663420285
Numero R.E.A. 258642
This is a 7" 800x480 panel connected through a 24-bit RGB interface.
However the panel only does 262k colors.
Signed-off-by: Chen-Yu Tsai
---
.../display/panel/bananapi,s070wv20-ct16.txt | 7 ++
drivers/gpu/drm/panel/panel-simple.c | 25 +++
2 files changed, 32 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.txt
diff --git
a/Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.txt
b/Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.txt
new file mode 100644
index ..2ec35ce36e9a
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.txt
@@ -0,0 +1,7 @@
+Banana Pi 7" (S070WV20-CT16) TFT LCD Panel
+
+Required properties:
+- compatible: should be "bananapi,s070wv20-ct16"
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index cbf1ab404ee7..9bc037f74d6c 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -745,6 +745,28 @@ static const struct panel_desc avic_tm070ddh03 = {
},
};
+static const struct drm_display_mode bananapi_s070wv20_ct16_mode = {
+ .clock = 3,
+ .hdisplay = 800,
+ .hsync_start = 800 + 40,
+ .hsync_end = 800 + 40 + 48,
+ .htotal = 800 + 40 + 48 + 40,
+ .vdisplay = 480,
+ .vsync_start = 480 + 13,
+ .vsync_end = 480 + 13 + 3,
+ .vtotal = 480 + 13 + 3 + 29,
+};
+
+static const struct panel_desc bananapi_s070wv20_ct16 = {
+ .modes = &bananapi_s070wv20_ct16_mode,
+ .num_modes = 1,
+ .bpc = 6,
+ .size = {
+ .width = 154,
+ .height = 86,
+ },
+};
+
static const struct drm_display_mode boe_nv101wxmn51_modes[] = {
{
.clock = 71900,
@@ -2112,6 +2134,9 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "avic,tm070ddh03",
.data = &avic_tm070ddh03,
+ }, {
+ .compatible = "bananapi,s070wv20-ct16",
+ .data = &bananapi_s070wv20_ct16,
}, {
.compatible = "boe,nv101wxmn51",
.data = &boe_nv101wxmn51,
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 2/2] i915: content-type property for HDMI connector
From: Stanislav Lisovskiy Added encoding of drm content_type property from drm_connector_state within AVI infoframe in order to properly handle external HDMI TV content-type setting. This requires also manipulationg ITC bit, as stated in HDMI spec. v2: * Moved helper function which attaches content type property to the drm core, as was suggested. Removed redundant connector state initialization. v3: * Removed caps in drm_content_type_enum_list. After some discussion it turned out that HDMI Spec 1.4 was wrongly assuming that IT Content(itc) bit doesn't affect Content type states, however itc bit needs to be manupulated as well. In order to not expose additional property for itc, for sake of simplicity it was decided to bind those together in same "content type" property. v4: * Added it_content checking in intel_digital_connector_atomic_check. Fixed documentation for new content type enum. v5: * Moved patch revision's description to commit messages. Signed-off-by: Stanislav Lisovskiy --- drivers/gpu/drm/i915/intel_atomic.c | 2 ++ drivers/gpu/drm/i915/intel_hdmi.c | 4 2 files changed, 6 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_atomic.c b/drivers/gpu/drm/i915/intel_atomic.c index 40285d1b91b7..96a42eb457c5 100644 --- a/drivers/gpu/drm/i915/intel_atomic.c +++ b/drivers/gpu/drm/i915/intel_atomic.c @@ -124,6 +124,8 @@ int intel_digital_connector_atomic_check(struct drm_connector *conn, if (new_conn_state->force_audio != old_conn_state->force_audio || new_conn_state->broadcast_rgb != old_conn_state->broadcast_rgb || new_conn_state->base.picture_aspect_ratio != old_conn_state->base.picture_aspect_ratio || + new_conn_state->base.content_type != old_conn_state->base.content_type || + new_conn_state->base.it_content != old_conn_state->base.it_content || new_conn_state->base.scaling_mode != old_conn_state->base.scaling_mode) crtc_state->mode_changed = true; diff --git a/drivers/gpu/drm/i915/intel_hdmi.c b/drivers/gpu/drm/i915/intel_hdmi.c index ee929f31f7db..078200908b7a 100644 --- a/drivers/gpu/drm/i915/intel_hdmi.c +++ b/drivers/gpu/drm/i915/intel_hdmi.c @@ -491,6 +491,9 @@ static void intel_hdmi_set_avi_infoframe(struct drm_encoder *encoder, intel_hdmi->rgb_quant_range_selectable, is_hdmi2_sink); + frame.avi.content_type = connector->state->content_type; + frame.avi.itc = connector->state->it_content; + /* TODO: handle pixel repetition for YCBCR420 outputs */ intel_write_infoframe(encoder, crtc_state, &frame); } @@ -2065,6 +2068,7 @@ intel_hdmi_add_properties(struct intel_hdmi *intel_hdmi, struct drm_connector *c intel_attach_force_audio_property(connector); intel_attach_broadcast_rgb_property(connector); intel_attach_aspect_ratio_property(connector); + drm_connector_attach_content_type_property(connector); connector->state->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE; } -- 2.17.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] dt-bindings/display/bridge: sii902x: add optional power supplies
Hi Laurent, On 04/19/2018 01:09 PM, Laurent Pinchart wrote: > Hi Philippe, > > On Thursday, 19 April 2018 12:31:15 EEST Philippe CORNU wrote: >> On 04/19/2018 10:11 AM, Laurent Pinchart wrote: >>> On Tuesday, 10 April 2018 08:19:26 EEST Philippe Cornu wrote: >>> Add the 3 optional power supplies using the exact description found in the document named "SiI9022A/SiI9024A HDMI Transmitter Data Sheet (August 2016)". Signed-off-by: Philippe Cornu --- Documentation/devicetree/bindings/display/bridge/sii902x.txt | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Documentation/devicetree/bindings/display/bridge/sii902x.txt b/Documentation/devicetree/bindings/display/bridge/sii902x.txt index 56a3e68ccb80..cf53678fe574 100644 --- a/Documentation/devicetree/bindings/display/bridge/sii902x.txt +++ b/Documentation/devicetree/bindings/display/bridge/sii902x.txt @@ -8,6 +8,9 @@ Optional properties: - interrupts-extended or interrupt-parent + interrupts: describe the interrupt line used to inform the host about hotplug events. - reset-gpios: OF device-tree gpio specification for RST_N pin. + - iovcc-supply: I/O supply voltage (1.8V or 3.3V, host-dependent). + - avcc12-supply: TMDS analog supply voltage (1.2V). + - cvcc12-supply: Digital core supply voltage (1.2V). >>> >>> It seems that the AVCC12 and CVCC12 power supplies are usually derived >>> from the same source. How about starting with one DT property for both, >>> and adding a second one later if needed ? >> >> Well, I do not know what is the best. Here I took the description from >> the documentation, and to allow all possible board configurations, I >> added these supplies as "optional" properties: if there is only one 1v2 >> regulator on the board, the dt will contain only avcc12 or cvcc12 and >> everything will work fine (we will have a dummy regulator for the >> missing optional 1v2 reg), if both regulators are there for any reasons >> (stability, noise, whatever...) then both entries will be in the dt. >> >> If you confirm you prefer a single 1v2 supply (named for instance >> "vcc12-supply") then I will do :-) > > Please see https://lists.freedesktop.org/archives/dri-devel/2018-April/ > 172400.html (and the messages that lead to it) and https:// > lists.freedesktop.org/archives/dri-devel/2018-March/170763.html. > Thanks for this discussion thread. On my side, I found "CVCC12 and AVCC12 can be derived from the same power source" written with a small font (august 2016 datasheet p13) so then your advice is clearly what we have to do :-) I will add this info in v2 too. Thank you, Philippe :-) Optional subnodes: - video input: this subnode can contain a video input port node > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/6] drm/panel: simple: Add support for Banana Pi 7" S070WV20-CT16 panel
On Thu, Apr 19, 2018 at 8:31 PM, Giulio Benetti
wrote:
> Hi,
>
> Il 19/04/2018 11:32, Chen-Yu Tsai ha scritto:
>>
>> This panel is marketed as Banana Pi 7" LCD display. On the back is
>> a sticker denoting the model name S070WV20-CT16.
>
>
> Judging from the code, the real vendor should be CDTech.
> Take a look at their website:
> http://www.cdtech-lcd.com/en/standardscreen.html
>
> I point you my patch for inserting another similar panel:
> https://patchwork.freedesktop.org/patch/211914/
>
> Maybe it would make sense to use CDTech as the vendor,
> because maybe Bananapi resells only it.
> Or maybe it is a custom panel done for them,
> but the same is for other panels I've submitted patches.
> Micronova srl custom, but vendor is CDTech.
>
> What do you think?
That might be true. But for people without access to the vendors,
this is horribly hard to figure out. People are only going to look
at whatever marking there is on the LCD panel, and whatever the
seller says. This panel has the model number stickered on, but the
PCB attached to it only has the Banana Pi logo.
And given it's a custom piece, probably OEM or ODM, the real
manufacturer matters less. You don't mention "Foxconn" as the
vendor of the iPhone, do you?
ChenYu
>
> --
> Giulio Benetti
> CTO
>
> MICRONOVA SRL
> Sede: Via A. Niedda 3 - 35010 Vigonza (PD)
> Tel. 049/8931563 - Fax 049/8931346
> Cod.Fiscale - P.IVA 02663420285
> Capitale Sociale € 26.000 i.v.
> Iscritta al Reg. Imprese di Padova N. 02663420285
> Numero R.E.A. 258642
>
>
>>
>> This is a 7" 800x480 panel connected through a 24-bit RGB interface.
>> However the panel only does 262k colors.
>>
>> Signed-off-by: Chen-Yu Tsai
>> ---
>> .../display/panel/bananapi,s070wv20-ct16.txt | 7 ++
>> drivers/gpu/drm/panel/panel-simple.c | 25 +++
>> 2 files changed, 32 insertions(+)
>> create mode 100644
>> Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.txt
>>
>> diff --git
>> a/Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.txt
>> b/Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.txt
>> new file mode 100644
>> index ..2ec35ce36e9a
>> --- /dev/null
>> +++
>> b/Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.txt
>> @@ -0,0 +1,7 @@
>> +Banana Pi 7" (S070WV20-CT16) TFT LCD Panel
>> +
>> +Required properties:
>> +- compatible: should be "bananapi,s070wv20-ct16"
>> +
>> +This binding is compatible with the simple-panel binding, which is
>> specified
>> +in simple-panel.txt in this directory.
>> diff --git a/drivers/gpu/drm/panel/panel-simple.c
>> b/drivers/gpu/drm/panel/panel-simple.c
>> index cbf1ab404ee7..9bc037f74d6c 100644
>> --- a/drivers/gpu/drm/panel/panel-simple.c
>> +++ b/drivers/gpu/drm/panel/panel-simple.c
>> @@ -745,6 +745,28 @@ static const struct panel_desc avic_tm070ddh03 = {
>> },
>> };
>> +static const struct drm_display_mode bananapi_s070wv20_ct16_mode = {
>> + .clock = 3,
>> + .hdisplay = 800,
>> + .hsync_start = 800 + 40,
>> + .hsync_end = 800 + 40 + 48,
>> + .htotal = 800 + 40 + 48 + 40,
>> + .vdisplay = 480,
>> + .vsync_start = 480 + 13,
>> + .vsync_end = 480 + 13 + 3,
>> + .vtotal = 480 + 13 + 3 + 29,
>> +};
>> +
>> +static const struct panel_desc bananapi_s070wv20_ct16 = {
>> + .modes = &bananapi_s070wv20_ct16_mode,
>> + .num_modes = 1,
>> + .bpc = 6,
>> + .size = {
>> + .width = 154,
>> + .height = 86,
>> + },
>> +};
>> +
>> static const struct drm_display_mode boe_nv101wxmn51_modes[] = {
>> {
>> .clock = 71900,
>> @@ -2112,6 +2134,9 @@ static const struct of_device_id platform_of_match[]
>> = {
>> }, {
>> .compatible = "avic,tm070ddh03",
>> .data = &avic_tm070ddh03,
>> + }, {
>> + .compatible = "bananapi,s070wv20-ct16",
>> + .data = &bananapi_s070wv20_ct16,
>> }, {
>> .compatible = "boe,nv101wxmn51",
>> .data = &boe_nv101wxmn51,
>>
>
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 1/2] drm: content-type property for HDMI connector
On 04/19/18 14:38, StanLis wrote:
> From: Stanislav Lisovskiy
>
> Added content_type property to drm_connector_state
> in order to properly handle external HDMI TV content-type setting.
>
> v2:
> * Moved helper function which attaches content type property
>to the drm core, as was suggested.
>Removed redundant connector state initialization.
>
> v3:
> * Removed caps in drm_content_type_enum_list.
>After some discussion it turned out that HDMI Spec 1.4
>was wrongly assuming that IT Content(itc) bit doesn't affect
>Content type states, however itc bit needs to be manupulated
>as well. In order to not expose additional property for itc,
>for sake of simplicity it was decided to bind those together
>in same "content type" property.
>
> v4:
> * Added it_content checking in intel_digital_connector_atomic_check.
>Fixed documentation for new content type enum.
>
> v5:
> * Moved patch revision's description to commit messages.
>
> Signed-off-by: Stanislav Lisovskiy
> ---
> Documentation/gpu/kms-properties.csv | 1 +
> drivers/gpu/drm/drm_atomic.c | 17 ++
> drivers/gpu/drm/drm_connector.c | 51
> drivers/gpu/drm/drm_edid.c | 2 ++
> include/drm/drm_connector.h | 18 ++
> include/drm/drm_mode_config.h| 5 +++
> include/uapi/drm/drm_mode.h | 7
> 7 files changed, 101 insertions(+)
>
> diff --git a/Documentation/gpu/kms-properties.csv
> b/Documentation/gpu/kms-properties.csv
> index 6b28b014cb7d..a91c9211b8d6 100644
> --- a/Documentation/gpu/kms-properties.csv
> +++ b/Documentation/gpu/kms-properties.csv
> @@ -17,6 +17,7 @@ Owner Module/Drivers,Group,Property Name,Type,Property
> Values,Object attached,De
> ,Virtual GPU,“suggested X”,RANGE,"Min=0, Max=0x",Connector,property
> to suggest an X offset for a connector
> ,,“suggested Y”,RANGE,"Min=0, Max=0x",Connector,property to suggest
> an Y offset for a connector
> ,Optional,"""aspect ratio""",ENUM,"{ ""None"", ""4:3"", ""16:9""
> }",Connector,TDB
> +,Optional,"""content type""",ENUM,"{ ""No data"", ""Graphics"", ""Photo"",
> ""Cinema"", ""Game"" }",Connector,TBD
> i915,Generic,"""Broadcast RGB""",ENUM,"{ ""Automatic"", ""Full"", ""Limited
> 16:235"" }",Connector,"When this property is set to Limited 16:235 and CTM is
> set, the hardware will be programmed with the result of the multiplication of
> CTM by the limited range matrix to ensure the pixels normaly in the range
> 0..1.0 are remapped to the range 16/255..235/255."
> ,,“audio”,ENUM,"{ ""force-dvi"", ""off"", ""auto"", ""on"" }",Connector,TBD
> ,SDVO-TV,“mode”,ENUM,"{ ""NTSC_M"", ""NTSC_J"", ""NTSC_443"", ""PAL_B"" }
> etc.",Connector,TBD
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 7d25c42f22db..479499f5848e 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -1266,6 +1266,15 @@ static int drm_atomic_connector_set_property(struct
> drm_connector *connector,
> state->link_status = val;
> } else if (property == config->aspect_ratio_property) {
> state->picture_aspect_ratio = val;
> + } else if (property == config->content_type_property) {
> + /*
> + * Lowest two bits of content_type property control
> + * content_type, bit 2 controls itc bit.
> + * It was decided to have a single property called
> + * content_type, instead of content_type and itc.
> + */
> + state->content_type = val & 3;
> + state->it_content = val >> 2;
> } else if (property == connector->scaling_mode_property) {
> state->scaling_mode = val;
> } else if (property == connector->content_protection_property) {
> @@ -1351,6 +1360,14 @@ drm_atomic_connector_get_property(struct drm_connector
> *connector,
> *val = state->link_status;
> } else if (property == config->aspect_ratio_property) {
> *val = state->picture_aspect_ratio;
> + } else if (property == config->content_type_property) {
> + /*
> + * Lowest two bits of content_type property control
> + * content_type, bit 2 controls itc bit.
> + * It was decided to have a single property called
> + * content_type, instead of content_type and itc.
> + */
> + *val = state->content_type | (state->it_content << 2);
> } else if (property == connector->scaling_mode_property) {
> *val = state->scaling_mode;
> } else if (property == connector->content_protection_property) {
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index b3cde897cd80..757a0712f7c1 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -720,6 +720,14 @@ static const struct drm_prop_enum_list
Re: [PATCH v5 2/2] i915: content-type property for HDMI connector
On 04/19/18 14:38, StanLis wrote: > From: Stanislav Lisovskiy > > Added encoding of drm content_type property from drm_connector_state > within AVI infoframe in order to properly handle external HDMI TV > content-type setting. > > This requires also manipulationg ITC bit, as stated in > HDMI spec. > > v2: > * Moved helper function which attaches content type property >to the drm core, as was suggested. >Removed redundant connector state initialization. > > v3: > * Removed caps in drm_content_type_enum_list. >After some discussion it turned out that HDMI Spec 1.4 >was wrongly assuming that IT Content(itc) bit doesn't affect >Content type states, however itc bit needs to be manupulated >as well. In order to not expose additional property for itc, >for sake of simplicity it was decided to bind those together >in same "content type" property. > > v4: > * Added it_content checking in intel_digital_connector_atomic_check. >Fixed documentation for new content type enum. > > v5: > * Moved patch revision's description to commit messages. > > Signed-off-by: Stanislav Lisovskiy Acked-by: Hans Verkuil Regards, Hans > --- > drivers/gpu/drm/i915/intel_atomic.c | 2 ++ > drivers/gpu/drm/i915/intel_hdmi.c | 4 > 2 files changed, 6 insertions(+) > > diff --git a/drivers/gpu/drm/i915/intel_atomic.c > b/drivers/gpu/drm/i915/intel_atomic.c > index 40285d1b91b7..96a42eb457c5 100644 > --- a/drivers/gpu/drm/i915/intel_atomic.c > +++ b/drivers/gpu/drm/i915/intel_atomic.c > @@ -124,6 +124,8 @@ int intel_digital_connector_atomic_check(struct > drm_connector *conn, > if (new_conn_state->force_audio != old_conn_state->force_audio || > new_conn_state->broadcast_rgb != old_conn_state->broadcast_rgb || > new_conn_state->base.picture_aspect_ratio != > old_conn_state->base.picture_aspect_ratio || > + new_conn_state->base.content_type != > old_conn_state->base.content_type || > + new_conn_state->base.it_content != old_conn_state->base.it_content > || > new_conn_state->base.scaling_mode != > old_conn_state->base.scaling_mode) > crtc_state->mode_changed = true; > > diff --git a/drivers/gpu/drm/i915/intel_hdmi.c > b/drivers/gpu/drm/i915/intel_hdmi.c > index ee929f31f7db..078200908b7a 100644 > --- a/drivers/gpu/drm/i915/intel_hdmi.c > +++ b/drivers/gpu/drm/i915/intel_hdmi.c > @@ -491,6 +491,9 @@ static void intel_hdmi_set_avi_infoframe(struct > drm_encoder *encoder, > > intel_hdmi->rgb_quant_range_selectable, > is_hdmi2_sink); > > + frame.avi.content_type = connector->state->content_type; > + frame.avi.itc = connector->state->it_content; > + > /* TODO: handle pixel repetition for YCBCR420 outputs */ > intel_write_infoframe(encoder, crtc_state, &frame); > } > @@ -2065,6 +2068,7 @@ intel_hdmi_add_properties(struct intel_hdmi > *intel_hdmi, struct drm_connector *c > intel_attach_force_audio_property(connector); > intel_attach_broadcast_rgb_property(connector); > intel_attach_aspect_ratio_property(connector); > + drm_connector_attach_content_type_property(connector); > connector->state->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE; > } > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 1/2] drm: content-type property for HDMI connector
From: Stanislav Lisovskiy
Added content_type property to drm_connector_state
in order to properly handle external HDMI TV content-type setting.
v2:
* Moved helper function which attaches content type property
to the drm core, as was suggested.
Removed redundant connector state initialization.
v3:
* Removed caps in drm_content_type_enum_list.
After some discussion it turned out that HDMI Spec 1.4
was wrongly assuming that IT Content(itc) bit doesn't affect
Content type states, however itc bit needs to be manupulated
as well. In order to not expose additional property for itc,
for sake of simplicity it was decided to bind those together
in same "content type" property.
v4:
* Added it_content checking in intel_digital_connector_atomic_check.
Fixed documentation for new content type enum.
v5:
* Moved patch revision's description to commit messages.
Signed-off-by: Stanislav Lisovskiy
---
Documentation/gpu/kms-properties.csv | 1 +
drivers/gpu/drm/drm_atomic.c | 17 ++
drivers/gpu/drm/drm_connector.c | 51
drivers/gpu/drm/drm_edid.c | 2 ++
include/drm/drm_connector.h | 18 ++
include/drm/drm_mode_config.h| 5 +++
include/uapi/drm/drm_mode.h | 7
7 files changed, 101 insertions(+)
diff --git a/Documentation/gpu/kms-properties.csv
b/Documentation/gpu/kms-properties.csv
index 6b28b014cb7d..a91c9211b8d6 100644
--- a/Documentation/gpu/kms-properties.csv
+++ b/Documentation/gpu/kms-properties.csv
@@ -17,6 +17,7 @@ Owner Module/Drivers,Group,Property Name,Type,Property
Values,Object attached,De
,Virtual GPU,“suggested X”,RANGE,"Min=0, Max=0x",Connector,property to
suggest an X offset for a connector
,,“suggested Y”,RANGE,"Min=0, Max=0x",Connector,property to suggest an
Y offset for a connector
,Optional,"""aspect ratio""",ENUM,"{ ""None"", ""4:3"", ""16:9""
}",Connector,TDB
+,Optional,"""content type""",ENUM,"{ ""No data"", ""Graphics"", ""Photo"",
""Cinema"", ""Game"" }",Connector,TBD
i915,Generic,"""Broadcast RGB""",ENUM,"{ ""Automatic"", ""Full"", ""Limited
16:235"" }",Connector,"When this property is set to Limited 16:235 and CTM is
set, the hardware will be programmed with the result of the multiplication of
CTM by the limited range matrix to ensure the pixels normaly in the range
0..1.0 are remapped to the range 16/255..235/255."
,,“audio”,ENUM,"{ ""force-dvi"", ""off"", ""auto"", ""on"" }",Connector,TBD
,SDVO-TV,“mode”,ENUM,"{ ""NTSC_M"", ""NTSC_J"", ""NTSC_443"", ""PAL_B"" }
etc.",Connector,TBD
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 7d25c42f22db..479499f5848e 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1266,6 +1266,15 @@ static int drm_atomic_connector_set_property(struct
drm_connector *connector,
state->link_status = val;
} else if (property == config->aspect_ratio_property) {
state->picture_aspect_ratio = val;
+ } else if (property == config->content_type_property) {
+ /*
+* Lowest two bits of content_type property control
+* content_type, bit 2 controls itc bit.
+* It was decided to have a single property called
+* content_type, instead of content_type and itc.
+*/
+ state->content_type = val & 3;
+ state->it_content = val >> 2;
} else if (property == connector->scaling_mode_property) {
state->scaling_mode = val;
} else if (property == connector->content_protection_property) {
@@ -1351,6 +1360,14 @@ drm_atomic_connector_get_property(struct drm_connector
*connector,
*val = state->link_status;
} else if (property == config->aspect_ratio_property) {
*val = state->picture_aspect_ratio;
+ } else if (property == config->content_type_property) {
+ /*
+* Lowest two bits of content_type property control
+* content_type, bit 2 controls itc bit.
+* It was decided to have a single property called
+* content_type, instead of content_type and itc.
+*/
+ *val = state->content_type | (state->it_content << 2);
} else if (property == connector->scaling_mode_property) {
*val = state->scaling_mode;
} else if (property == connector->content_protection_property) {
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index b3cde897cd80..757a0712f7c1 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -720,6 +720,14 @@ static const struct drm_prop_enum_list
drm_aspect_ratio_enum_list[] = {
{ DRM_MODE_PICTURE_ASPECT_16_9, "16:9" },
};
+static const struct drm_prop_enum_list drm_content_type_enum_list[] = {
+ { DRM_MOD
[PATCH v5 0/2] Enabling content-type setting for HDMI displays.
From: Stanislav Lisovskiy Added content type setting property to drm_connector(part 1) and enabled transmitting it with HDMI AVI infoframes for i915(part 2). Stanislav Lisovskiy (2): drm: content-type property for HDMI connector i915: content-type property for HDMI connector Documentation/gpu/kms-properties.csv | 1 + drivers/gpu/drm/drm_atomic.c | 17 ++ drivers/gpu/drm/drm_connector.c | 51 drivers/gpu/drm/drm_edid.c | 2 ++ drivers/gpu/drm/i915/intel_atomic.c | 2 ++ drivers/gpu/drm/i915/intel_hdmi.c| 4 +++ include/drm/drm_connector.h | 18 ++ include/drm/drm_mode_config.h| 5 +++ include/uapi/drm/drm_mode.h | 7 9 files changed, 107 insertions(+) -- 2.17.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] dt-bindings/display/bridge: sii902x: add optional power supplies
Hi Philippe, On Thursday, 19 April 2018 15:41:20 EEST Philippe CORNU wrote: > On 04/19/2018 01:09 PM, Laurent Pinchart wrote: > > On Thursday, 19 April 2018 12:31:15 EEST Philippe CORNU wrote: > >> On 04/19/2018 10:11 AM, Laurent Pinchart wrote: > >>> On Tuesday, 10 April 2018 08:19:26 EEST Philippe Cornu wrote: > Add the 3 optional power supplies using the exact description > found in the document named > "SiI9022A/SiI9024A HDMI Transmitter Data Sheet (August 2016)". > > Signed-off-by: Philippe Cornu > --- > > Documentation/devicetree/bindings/display/bridge/sii902x.txt | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git > a/Documentation/devicetree/bindings/display/bridge/sii902x.txt > b/Documentation/devicetree/bindings/display/bridge/sii902x.txt index > 56a3e68ccb80..cf53678fe574 100644 > --- a/Documentation/devicetree/bindings/display/bridge/sii902x.txt > +++ b/Documentation/devicetree/bindings/display/bridge/sii902x.txt > @@ -8,6 +8,9 @@ Optional properties: > - interrupts-extended or interrupt-parent + interrupts: describe > the interrupt line used to inform the host about hotplug > events. > - reset-gpios: OF device-tree gpio specification for RST_N pin. > +- iovcc-supply: I/O supply voltage (1.8V or 3.3V, > host-dependent). > +- avcc12-supply: TMDS analog supply voltage (1.2V). > +- cvcc12-supply: Digital core supply voltage (1.2V). > >>> > >>> It seems that the AVCC12 and CVCC12 power supplies are usually derived > >>> from the same source. How about starting with one DT property for both, > >>> and adding a second one later if needed ? > >> > >> Well, I do not know what is the best. Here I took the description from > >> the documentation, and to allow all possible board configurations, I > >> added these supplies as "optional" properties: if there is only one 1v2 > >> regulator on the board, the dt will contain only avcc12 or cvcc12 and > >> everything will work fine (we will have a dummy regulator for the > >> missing optional 1v2 reg), if both regulators are there for any reasons > >> (stability, noise, whatever...) then both entries will be in the dt. > >> > >> If you confirm you prefer a single 1v2 supply (named for instance > >> "vcc12-supply") then I will do :-) > > > > Please see https://lists.freedesktop.org/archives/dri-devel/2018-April/ > > 172400.html (and the messages that lead to it) and https:// > > lists.freedesktop.org/archives/dri-devel/2018-March/170763.html. > > Thanks for this discussion thread. > > On my side, I found "CVCC12 and AVCC12 can be derived from the same > power source" written with a small font (august 2016 datasheet p13) so > then your advice is clearly what we have to do :-) > I will add this info in v2 too. I have seen that too. While the datasheet only says that the two supplies *can* be derived from the same power source, I expect that to be the case in practice for a really vast majority of cases (I wouldn't be surprised to never hear of a system using two different supplies). That's why I think starting with one supply would be better. > Optional subnodes: > > - video input: this subnode can contain a video input port node -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/sun4i: Add missing frontend compatibles for A10, A13, A20 and A31
Although frontend nodes are defined in the device-trees of the
aforementioned platforms, there are no matching compatibles defined in
the driver. This makes it impossible to probe the frontend on these
platforms.
Adding the appropriate compatibles to the driver fixes the issue.
Signed-off-by: Paul Kocialkowski
---
drivers/gpu/drm/sun4i/sun4i_frontend.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/sun4i/sun4i_frontend.c
b/drivers/gpu/drm/sun4i/sun4i_frontend.c
index 85f75046712c..c5a3de11817d 100644
--- a/drivers/gpu/drm/sun4i/sun4i_frontend.c
+++ b/drivers/gpu/drm/sun4i/sun4i_frontend.c
@@ -658,6 +658,10 @@ static const struct dev_pm_ops sun4i_frontend_pm_ops = {
};
const struct of_device_id sun4i_frontend_of_table[] = {
+ { .compatible = "allwinner,sun7i-a10-display-frontend" },
+ { .compatible = "allwinner,sun7i-a13-display-frontend" },
+ { .compatible = "allwinner,sun7i-a20-display-frontend" },
+ { .compatible = "allwinner,sun7i-a31-display-frontend" },
{ .compatible = "allwinner,sun8i-a33-display-frontend" },
{ }
};
--
2.16.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/rockchip: vop: fixup linebuffer mode calc error
在 2018/4/17 19:14, Heiko Stuebner 写道: Hi Sandy, Am Dienstag, 17. April 2018, 12:15:07 CEST schrieb Sandy Huang: When video width is bigger than 3840 the linebuffer mode should be LB_YUV_3840X5. Can you explain that a bit better? I.e. when looking at the code, the very first check is width > 2560. So it seems your change targets some YUV mode with width > 3840 which should be mentioned in the commit message, so people like me don't scratch their head in confusion ;-) Similarly that check is actually width > 1280 to set LB_YUV_3840X5, so I guess you're actually wanting any YUV mode bigger than 1280px should use LB_YUV_3840X5? Heiko Thanks heiko, I will make more description for this path at next version. Signed-off-by: Sandy Huang --- drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h index 56bbd2e..3e7501b 100644 --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h @@ -332,7 +332,7 @@ static inline int scl_vop_cal_lb_mode(int width, bool is_yuv) if (width > 2560) lb_mode = LB_RGB_3840X2; - else if (width > 1920) + else if (!is_yuv && width > 1920) lb_mode = LB_RGB_2560X4; else if (!is_yuv) lb_mode = LB_RGB_1920X5; ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/6] drm/panel: simple: Add support for Banana Pi 7" S070WV20-CT16 panel
Hi,
Il 19/04/2018 14:45, Chen-Yu Tsai ha scritto:
On Thu, Apr 19, 2018 at 8:31 PM, Giulio Benetti
wrote:
Hi,
Il 19/04/2018 11:32, Chen-Yu Tsai ha scritto:
This panel is marketed as Banana Pi 7" LCD display. On the back is
a sticker denoting the model name S070WV20-CT16.
Judging from the code, the real vendor should be CDTech.
Take a look at their website:
http://www.cdtech-lcd.com/en/standardscreen.html
I point you my patch for inserting another similar panel:
https://patchwork.freedesktop.org/patch/211914/
Maybe it would make sense to use CDTech as the vendor,
because maybe Bananapi resells only it.
Or maybe it is a custom panel done for them,
but the same is for other panels I've submitted patches.
Micronova srl custom, but vendor is CDTech.
What do you think?
That might be true. But for people without access to the vendors,
this is horribly hard to figure out. People are only going to look
at whatever marking there is on the LCD panel, and whatever the
seller says. This panel has the model number stickered on, but the
PCB attached to it only has the Banana Pi logo.
Ah ok, my fault, I didn't see it has a PCB attached with Banana Pi logo.
Also it makes a lot of sense what you say about people looking for display.
And given it's a custom piece, probably OEM or ODM, the real
manufacturer matters less. You don't mention "Foxconn" as the
vendor of the iPhone, do you?
:) that's right.
Best regards
--
Giulio Benetti
CTO
MICRONOVA SRL
Sede: Via A. Niedda 3 - 35010 Vigonza (PD)
Tel. 049/8931563 - Fax 049/8931346
Cod.Fiscale - P.IVA 02663420285
Capitale Sociale € 26.000 i.v.
Iscritta al Reg. Imprese di Padova N. 02663420285
Numero R.E.A. 258642
ChenYu
--
Giulio Benetti
CTO
MICRONOVA SRL
Sede: Via A. Niedda 3 - 35010 Vigonza (PD)
Tel. 049/8931563 - Fax 049/8931346
Cod.Fiscale - P.IVA 02663420285
Capitale Sociale € 26.000 i.v.
Iscritta al Reg. Imprese di Padova N. 02663420285
Numero R.E.A. 258642
This is a 7" 800x480 panel connected through a 24-bit RGB interface.
However the panel only does 262k colors.
Signed-off-by: Chen-Yu Tsai
---
.../display/panel/bananapi,s070wv20-ct16.txt | 7 ++
drivers/gpu/drm/panel/panel-simple.c | 25 +++
2 files changed, 32 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.txt
diff --git
a/Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.txt
b/Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.txt
new file mode 100644
index ..2ec35ce36e9a
--- /dev/null
+++
b/Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.txt
@@ -0,0 +1,7 @@
+Banana Pi 7" (S070WV20-CT16) TFT LCD Panel
+
+Required properties:
+- compatible: should be "bananapi,s070wv20-ct16"
+
+This binding is compatible with the simple-panel binding, which is
specified
+in simple-panel.txt in this directory.
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index cbf1ab404ee7..9bc037f74d6c 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -745,6 +745,28 @@ static const struct panel_desc avic_tm070ddh03 = {
},
};
+static const struct drm_display_mode bananapi_s070wv20_ct16_mode = {
+ .clock = 3,
+ .hdisplay = 800,
+ .hsync_start = 800 + 40,
+ .hsync_end = 800 + 40 + 48,
+ .htotal = 800 + 40 + 48 + 40,
+ .vdisplay = 480,
+ .vsync_start = 480 + 13,
+ .vsync_end = 480 + 13 + 3,
+ .vtotal = 480 + 13 + 3 + 29,
+};
+
+static const struct panel_desc bananapi_s070wv20_ct16 = {
+ .modes = &bananapi_s070wv20_ct16_mode,
+ .num_modes = 1,
+ .bpc = 6,
+ .size = {
+ .width = 154,
+ .height = 86,
+ },
+};
+
static const struct drm_display_mode boe_nv101wxmn51_modes[] = {
{
.clock = 71900,
@@ -2112,6 +2134,9 @@ static const struct of_device_id platform_of_match[]
= {
}, {
.compatible = "avic,tm070ddh03",
.data = &avic_tm070ddh03,
+ }, {
+ .compatible = "bananapi,s070wv20-ct16",
+ .data = &bananapi_s070wv20_ct16,
}, {
.compatible = "boe,nv101wxmn51",
.data = &boe_nv101wxmn51,
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/stm: ltdc: fix warnings in ltdc_plane_create()
"make C=1" returns 2 warnings in ltdc_plane_create()
("Using plain integer as NULL pointer"). This patch
fixes them.
Signed-off-by: Philippe Cornu
---
drivers/gpu/drm/stm/ltdc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c
index 616191fe98ae..d997a6014d6c 100644
--- a/drivers/gpu/drm/stm/ltdc.c
+++ b/drivers/gpu/drm/stm/ltdc.c
@@ -860,13 +860,13 @@ static struct drm_plane *ltdc_plane_create(struct
drm_device *ddev,
plane = devm_kzalloc(dev, sizeof(*plane), GFP_KERNEL);
if (!plane)
- return 0;
+ return NULL;
ret = drm_universal_plane_init(ddev, plane, possible_crtcs,
Re: [PATCH 3/6] drm/sun4i: tcon: Add dithering support for RGB565/RGB666 LCD panels
Hi,
On Thu, Apr 19, 2018 at 05:32:22PM +0800, Chen-Yu Tsai wrote:
> From: Jonathan Liu
>
> The hardware supports dithering on TCON channel 0 which is used for LCD
> panels.
>
> Dithering is a method of approximating a color from a mixture of other
> colors when the required color isn't available. It reduces color
> banding artifacts that can be observed when displaying gradients
> (e.g. grayscale gradients). This may occur when the image that needs
> to be displayed is 24-bit but the LCD panel is a lower bit depth and
> does not perform dithering on its own.
>
> Signed-off-by: Jonathan Liu
> [w...@csie.org: check display_info.bpc first; handle LVDS and MIPI DSI]
> Signed-off-by: Chen-Yu Tsai
> ---
>
> Hi Maxime,
>
> The dithering parameters used here are different from the ones you used
> in your MIPI DSI series. You might want to check if it still works for
> you.
>
> ---
> drivers/gpu/drm/sun4i/sun4i_tcon.c | 63 +-
> 1 file changed, 62 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> index 2bd53ef7d4b8..827518f4790e 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> @@ -12,6 +12,7 @@
>
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -276,8 +277,59 @@ static void sun4i_tcon0_mode_set_common(struct
> sun4i_tcon *tcon,
>SUN4I_TCON0_BASIC0_Y(mode->crtc_vdisplay));
> }
>
> +static void sun4i_tcon0_mode_set_dithering(struct sun4i_tcon *tcon,
> +const struct drm_connector
> *connector)
> +{
> + u32 bus_format = 0;
> + u32 val = 0;
> +
> + /* XXX Would this ever happen? */
> + if (!connector)
> + return;
> +
> + /*
> + * FIXME: Undocumented bits
> + *
> + * The whole dithering process and these parameters are not
> + * explained in the vendor documents or BSP kernel code.
> + */
> + regmap_write(tcon->regs, SUN4I_TCON0_FRM_SEED_PR_REG, 0x);
> + regmap_write(tcon->regs, SUN4I_TCON0_FRM_SEED_PG_REG, 0x);
> + regmap_write(tcon->regs, SUN4I_TCON0_FRM_SEED_PB_REG, 0x);
> + regmap_write(tcon->regs, SUN4I_TCON0_FRM_SEED_LR_REG, 0x);
> + regmap_write(tcon->regs, SUN4I_TCON0_FRM_SEED_LG_REG, 0x);
> + regmap_write(tcon->regs, SUN4I_TCON0_FRM_SEED_LB_REG, 0x);
> + regmap_write(tcon->regs, SUN4I_TCON0_FRM_TBL0_REG, 0x0101);
> + regmap_write(tcon->regs, SUN4I_TCON0_FRM_TBL1_REG, 0x1515);
> + regmap_write(tcon->regs, SUN4I_TCON0_FRM_TBL2_REG, 0x5757);
> + regmap_write(tcon->regs, SUN4I_TCON0_FRM_TBL3_REG, 0x7f7f);
> +
> + /* Do dithering if panel only supports 6 bits per color */
> + if (connector->display_info.bpc == 6)
> + val |= SUN4I_TCON0_FRM_CTL_EN;
> +
> + if (connector->display_info.num_bus_formats == 1)
> + bus_format = connector->display_info.bus_formats[0];
> +
> + /* Check the connection format */
> + switch (bus_format) {
> + case MEDIA_BUS_FMT_RGB565_1X16:
> + /* R and B components are only 5 bits deep */
> + val |= SUN4I_TCON0_FRM_CTL_MODE_R;
> + val |= SUN4I_TCON0_FRM_CTL_MODE_B;
> + case MEDIA_BUS_FMT_RGB666_1X18:
> + case MEDIA_BUS_FMT_RGB666_1X7X3_SPWG:
> + /* Fall through: enable dithering */
> + val |= SUN4I_TCON0_FRM_CTL_EN;
> + break;
> + }
> +
> + /* Write dithering settings */
> + regmap_write(tcon->regs, SUN4I_TCON_FRM_CTL_REG, val);
> +}
> +
> static void sun4i_tcon0_mode_set_cpu(struct sun4i_tcon *tcon,
> - struct drm_encoder *encoder,
> + const struct drm_encoder *encoder,
The whole serie looks good, but that should probbaly be part of the
first patch?
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [v2] drm/sun4i: add lvds mode_valid function
On Thu, Apr 19, 2018 at 9:34 PM, Ondřej Jirman
wrote:
> Hello Giulio,
>
> this patch breaks LVDS output on A83T. Without it, modesetting works,
> with it there's no output.
>
> Some more info below...
>
> On Tue, Mar 13, 2018 at 12:20:19PM +0100, Giulio Benetti wrote:
>> mode_valid function is missing for lvds.
>>
>> Add it making it pointed by encoder helper functions.
>>
>> Signed-off-by: Giulio Benetti
>> ---
>> drivers/gpu/drm/sun4i/sun4i_lvds.c | 55
>> ++
>> 1 file changed, 55 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/sun4i/sun4i_lvds.c
>> b/drivers/gpu/drm/sun4i/sun4i_lvds.c
>> index be3f14d..b4c 100644
>> --- a/drivers/gpu/drm/sun4i/sun4i_lvds.c
>> +++ b/drivers/gpu/drm/sun4i/sun4i_lvds.c
>> @@ -94,9 +94,64 @@ static void sun4i_lvds_encoder_disable(struct drm_encoder
>> *encoder)
>> }
>> }
>>
>> +static enum drm_mode_status sun4i_lvds_encoder_mode_valid(struct
>> drm_encoder *crtc,
>> + const struct
>> drm_display_mode *mode)
>> +{
>> + struct sun4i_lvds *lvds = drm_encoder_to_sun4i_lvds(crtc);
>> + struct sun4i_tcon *tcon = lvds->tcon;
>> + u32 hsync = mode->hsync_end - mode->hsync_start;
>> + u32 vsync = mode->vsync_end - mode->vsync_start;
>> + unsigned long rate = mode->clock * 1000;
>> + long rounded_rate;
>> +
>> + DRM_DEBUG_DRIVER("Validating modes...\n");
>> +
>> + if (hsync < 1)
>> + return MODE_HSYNC_NARROW;
>> +
>> + if (hsync > 0x3ff)
>> + return MODE_HSYNC_WIDE;
>> +
>> + if ((mode->hdisplay < 1) || (mode->htotal < 1))
>> + return MODE_H_ILLEGAL;
>> +
>> + if ((mode->hdisplay > 0x7ff) || (mode->htotal > 0xfff))
>> + return MODE_BAD_HVALUE;
>> +
>> + DRM_DEBUG_DRIVER("Horizontal parameters OK\n");
>> +
>> + if (vsync < 1)
>> + return MODE_VSYNC_NARROW;
>> +
>> + if (vsync > 0x3ff)
>> + return MODE_VSYNC_WIDE;
>> +
>> + if ((mode->vdisplay < 1) || (mode->vtotal < 1))
>> + return MODE_V_ILLEGAL;
>> +
>> + if ((mode->vdisplay > 0x7ff) || (mode->vtotal > 0xfff))
>> + return MODE_BAD_VVALUE;
>> +
>> + DRM_DEBUG_DRIVER("Vertical parameters OK\n");
>> +
>> + tcon->dclk_min_div = 7;
>> + tcon->dclk_max_div = 7;
>
> Why would validation function change any state anywhere?
>
>> + rounded_rate = clk_round_rate(tcon->dclk, rate);
>
> The issue is here, on A83T TBS A711 tablet, I get...
>
> sun4i-tcon 1c0c000.lcd-controller: XXX: hsync=20 hdisplay=1024 htotal=1384
> vsync=5 vdisplay=600 vtotal=640 rate=5200 rounded_rate=51857142
>
>> + if (rounded_rate < rate)
>> + return MODE_CLOCK_LOW;
>> +
>> + if (rounded_rate > rate)
>> + return MODE_CLOCK_HIGH;
>
> ... while the previous conditions require an exact match for some reason.
>
> But HW works fine without an exact rate match. Why is exact match required
> here?
This thread might provide some more info, though we could never get an
agreement.
https://patchwork.kernel.org/patch/9446385/
ChenYu
>
> thank you,
> Ondrej
>
>> + DRM_DEBUG_DRIVER("Clock rate OK\n");
>> +
>> + return MODE_OK;
>> +}
>> +
>> static const struct drm_encoder_helper_funcs sun4i_lvds_enc_helper_funcs = {
>> .disable= sun4i_lvds_encoder_disable,
>> .enable = sun4i_lvds_encoder_enable,
>> + .mode_valid = sun4i_lvds_encoder_mode_valid,
>> };
>>
>> static const struct drm_encoder_funcs sun4i_lvds_enc_funcs = {
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] drm/i915: Do NOT skip the first 4k of stolen memory for pre-allocated buffers
Hi,
On 05-04-18 15:26, Daniel Vetter wrote:
On Thu, Apr 5, 2018 at 1:47 PM, Hans de Goede wrote:
Hi,
On 05-04-18 09:14, Daniel Vetter wrote:
On Fri, Mar 30, 2018 at 02:27:15PM +0200, Hans de Goede wrote:
Before this commit the WaSkipStolenMemoryFirstPage workaround code was
skipping the first 4k by passing 4096 as start of the address range
passed
to drm_mm_init(). This means that calling drm_mm_reserve_node() to try
and
reserve the firmware framebuffer so that we can inherit it would always
fail, as the firmware framebuffer starts at address 0.
Commit d43537610470 ("drm/i915: skip the first 4k of stolen memory on
everything >= gen8") says in its commit message: "This is confirmed to
fix
Skylake screen flickering issues (probably caused by the fact that we
initialized a ring in the first page of stolen, but I didn't 100% confirm
this theory)."
Which suggests that it is safe to use the first page for a linear
framebuffer as the firmware is doing.
This commit always passes 0 as start to drm_mm_init() and works around
WaSkipStolenMemoryFirstPage in i915_gem_stolen_insert_node_in_range()
by insuring the start address passed by to drm_mm_insert_node_in_range()
is always 4k or more. All entry points to i915_gem_stolen.c go through
i915_gem_stolen_insert_node_in_range(), so that any newly allocated
objects such as ring-buffers will not be allocated in the first 4k.
The one exception is i915_gem_object_create_stolen_for_preallocated()
which directly calls drm_mm_reserve_node() which now will be able to
use the first 4k.
This fixes the i915 driver no longer being able to inherit the firmware
framebuffer on gen8+, which fixes the video output changing from the
vendor logo to a black screen as soon as the i915 driver is loaded
(on systems without fbcon).
Signed-off-by: Hans de Goede
I think this is worth a shot. The only explanation I can think of why the
GOP could get away with this and still follow the w/a is if it doesn't
have a 1:1 mapping between GGTT and stolen.
My guess is that the GOP does not care about the w/a because the w/a
states that the command-streamers sometimes do a spurious flush (write)
to the first page, and the command-streamers are not used until much
later, so the GOP is probably ignoring the w/a all together.
At least that is my theory.
Atm we do not know whether the GOP actually implements the wa or not.
That it doesn't care is just a conjecture, but we have no proof. On
previous platforms the 1:1 mapping did hold, but there's no
fundamental reason why it sitll does.
Right.
Atm we hardcode that
assumption in intel_alloc_initial_plane_obj by passing the base_aligned as
both the stolen_offset and the gtt_offset (but it's only the gtt_offset
really). And since we're not re-writing the ptes it's not noticeable.
I think to decide whether this is the right approach we should
double-check whether that 1:1 assumption really holds true: Either read
back the ggtt ptes and check their addresses (but iirc on some platforms
their write-only, readback doesn't work), or we also rewrite the ptes
again for preallocated stuff, like when binding a normal object into the
gtt. If either of these approaches confirms that those affected gen8+
machines still use the 1:1 mapping, then I'm happy to put my r-b on this
patch. If not, well then we at least know what to fix: We need to read out
the real stolen_offset, instead of making assumptions.
I'm happy to give this a try on one or more affected machines, I can e.g.
try this on both a skylake desktop and a cherry-trail based tablet.
But I'm clueless about the whole PTE stuff, so I'm going to need someone
to provide me with a patch following either approach. If readback of the
PTEs works on skylake / cherrytrail I guess that would be the best way.
Note to test this I'm currently booting the kernel with the machine's
UEFI vendor logo still being displayed when efifb kicks in. I've added:
"fbcon=vc:2-62" to the kernel commandline to make fbcon not bind to
VC0 / VC1, so that the framebuffer contents stays intact, combined with
the patch we are discussing now, this makes the vendor logo stay on
the screen all the way till GDM loads, which looks rather nice actually :)
And on shutdown we fall back to the original framebuffer and the vendor
logo is back again. I cannot see any corruption in the display at either
boot or shutdown time.
It shouldn't matter whether efifb takes over or not, it's still the
GOP's framebuffer we're taking over. Different content for sure, logo
is gone, but we only care about which pages we're using.
Wrt the code:
- (Re)binding happens by calling i915_vma_bind, if you put a call to
that at the end of the stolen_preallocated functions you should get
that. Ofc needs the logo still there so you can see it jump/get
mangled.
- GGTT PTEs for gen8+ are written through e.g. gen8_ggttt_insert_page
or gen8_ggtt_insert_entries (which takes the vma). Since we only care
about the first entry a readq(dev_priv->ggtt->gsm)
Re: [v2] drm/sun4i: add lvds mode_valid function
Hi everybody,
Il 19/04/2018 15:36, Chen-Yu Tsai ha scritto:
On Thu, Apr 19, 2018 at 9:34 PM, Ondřej Jirman
wrote:
Hello Giulio,
this patch breaks LVDS output on A83T. Without it, modesetting works,
with it there's no output.
Some more info below...
On Tue, Mar 13, 2018 at 12:20:19PM +0100, Giulio Benetti wrote:
mode_valid function is missing for lvds.
Add it making it pointed by encoder helper functions.
Signed-off-by: Giulio Benetti
---
drivers/gpu/drm/sun4i/sun4i_lvds.c | 55 ++
1 file changed, 55 insertions(+)
diff --git a/drivers/gpu/drm/sun4i/sun4i_lvds.c
b/drivers/gpu/drm/sun4i/sun4i_lvds.c
index be3f14d..b4c 100644
--- a/drivers/gpu/drm/sun4i/sun4i_lvds.c
+++ b/drivers/gpu/drm/sun4i/sun4i_lvds.c
@@ -94,9 +94,64 @@ static void sun4i_lvds_encoder_disable(struct drm_encoder
*encoder)
}
}
+static enum drm_mode_status sun4i_lvds_encoder_mode_valid(struct drm_encoder
*crtc,
+ const struct
drm_display_mode *mode)
+{
+ struct sun4i_lvds *lvds = drm_encoder_to_sun4i_lvds(crtc);
+ struct sun4i_tcon *tcon = lvds->tcon;
+ u32 hsync = mode->hsync_end - mode->hsync_start;
+ u32 vsync = mode->vsync_end - mode->vsync_start;
+ unsigned long rate = mode->clock * 1000;
+ long rounded_rate;
+
+ DRM_DEBUG_DRIVER("Validating modes...\n");
+
+ if (hsync < 1)
+ return MODE_HSYNC_NARROW;
+
+ if (hsync > 0x3ff)
+ return MODE_HSYNC_WIDE;
+
+ if ((mode->hdisplay < 1) || (mode->htotal < 1))
+ return MODE_H_ILLEGAL;
+
+ if ((mode->hdisplay > 0x7ff) || (mode->htotal > 0xfff))
+ return MODE_BAD_HVALUE;
+
+ DRM_DEBUG_DRIVER("Horizontal parameters OK\n");
+
+ if (vsync < 1)
+ return MODE_VSYNC_NARROW;
+
+ if (vsync > 0x3ff)
+ return MODE_VSYNC_WIDE;
+
+ if ((mode->vdisplay < 1) || (mode->vtotal < 1))
+ return MODE_V_ILLEGAL;
+
+ if ((mode->vdisplay > 0x7ff) || (mode->vtotal > 0xfff))
+ return MODE_BAD_VVALUE;
+
+ DRM_DEBUG_DRIVER("Vertical parameters OK\n");
+
+ tcon->dclk_min_div = 7;
+ tcon->dclk_max_div = 7;
Why would validation function change any state anywhere?
+ rounded_rate = clk_round_rate(tcon->dclk, rate);
The issue is here, on A83T TBS A711 tablet, I get...
sun4i-tcon 1c0c000.lcd-controller: XXX: hsync=20 hdisplay=1024 htotal=1384
vsync=5 vdisplay=600 vtotal=640 rate=5200 rounded_rate=51857142
+ if (rounded_rate < rate)
+ return MODE_CLOCK_LOW;
+
+ if (rounded_rate > rate)
+ return MODE_CLOCK_HIGH;
... while the previous conditions require an exact match for some reason.
But HW works fine without an exact rate match. Why is exact match required here?
This thread might provide some more info, though we could never get an
agreement.
https://patchwork.kernel.org/patch/9446385/
Thanks for pointing that Thread ChenYu.
So the only chance is to trim frequency according to encoder capabilities.
I agree to block when encoder can't provide frequency specified,
otherwise you could drive you panel at the near the lowest(highest)
frequency and get out of limits for a few without knowing it.
Best regards
--
Giulio Benetti
CTO
MICRONOVA SRL
Sede: Via A. Niedda 3 - 35010 Vigonza (PD)
Tel. 049/8931563 - Fax 049/8931346
Cod.Fiscale - P.IVA 02663420285
Capitale Sociale € 26.000 i.v.
Iscritta al Reg. Imprese di Padova N. 02663420285
Numero R.E.A. 258642
ChenYu
thank you,
Ondrej
+ DRM_DEBUG_DRIVER("Clock rate OK\n");
+
+ return MODE_OK;
+}
+
static const struct drm_encoder_helper_funcs sun4i_lvds_enc_helper_funcs = {
.disable= sun4i_lvds_encoder_disable,
.enable = sun4i_lvds_encoder_enable,
+ .mode_valid = sun4i_lvds_encoder_mode_valid,
};
static const struct drm_encoder_funcs sun4i_lvds_enc_funcs = {
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amd/display: Disallow enabling CRTC without primary plane with FB
On 2018-04-19 03:43 AM, Michel Dänzer wrote:
>
> [ Dropping stable@ (fixes with Cc: stable are picked up for stable
> branches once they land in Linus' tree, there's no point sending them to
> stable@ during review), adding dri-devel ]
>
> On 2018-04-18 10:26 PM, Harry Wentland wrote:
>> The below commit
>>
>> "drm/atomic: Try to preserve the crtc enabled state in
>> drm_atomic_remove_fb, v2"
>>
>> introduces a slight behavioral change to rmfb. Instead of disabling a crtc
>> when the primary plane is disabled, it now preserves it.
>>
>> Since DC is currently not equipped to handle this we need to fail such
>> a commit, otherwise we might see a corrupted screen.
>
> How does the caller react to failing such a commit?
The caller (drm_atomic_remove_fb in this case) will retry with the old behavior
and disable the CRTC.
Harry
>
>
>> This is based on Shirish's previous approach but avoids adding all
>> planes to the new atomic state which leads to a full update in DC for
>> any commit, and is not what we intend.
>>
>> Theoretically DM should be able to deal with states with fully populated
>> planes,
>> even for simple updates, such as cursor updates. This should still be
>> addressed in the future.
>>
>> Signed-off-by: Harry Wentland
>> Cc: sta...@vger.kernel.org
>> ---
>> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 10 +-
>> 1 file changed, 9 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>> index 6f92a19bebd6..0bdc6b484bad 100644
>> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>> @@ -4683,6 +4683,7 @@ static int dm_update_crtcs_state(struct
>> amdgpu_display_manager *dm,
>> struct amdgpu_dm_connector *aconnector = NULL;
>> struct drm_connector_state *new_con_state = NULL;
>> struct dm_connector_state *dm_conn_state = NULL;
>> +struct drm_plane_state *new_plane_state = NULL;
>>
>> new_stream = NULL;
>>
>> @@ -4690,6 +4691,13 @@ static int dm_update_crtcs_state(struct
>> amdgpu_display_manager *dm,
>> dm_new_crtc_state = to_dm_crtc_state(new_crtc_state);
>> acrtc = to_amdgpu_crtc(crtc);
>>
>> +new_plane_state = drm_atomic_get_new_plane_state(state,
>> new_crtc_state->crtc->primary);
>> +
>> +if (new_crtc_state->enable && new_plane_state &&
>> !new_plane_state->fb) {
>> +ret = -EINVAL;
>> +goto fail;
>> +}
>> +
>> aconnector =
>> amdgpu_dm_find_first_crtc_matching_connector(state, crtc);
>>
>> /* TODO This hack should go away */
>> @@ -4894,7 +4902,7 @@ static int dm_update_planes_state(struct dc *dc,
>> if (!dm_old_crtc_state->stream)
>> continue;
>>
>> -DRM_DEBUG_DRIVER("Disabling DRM plane: %d on DRM crtc
>> %d\n",
>> +DRM_DEBUG_ATOMIC("Disabling DRM plane: %d on DRM crtc
>> %d\n",
>> plane->base.id,
>> old_plane_crtc->base.id);
>>
>> if (!dc_remove_plane_from_context(
>>
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [i915] WARNING: CPU: 2 PID: 183 at drivers/gpu/drm/i915/intel_display.c:14584 intel_modeset_init+0x3be/0x1060
Op 19-04-18 om 13:05 schreef Fengguang Wu: > Hi Maarten, > >> What extra dmesg output do you get when you boot with drm.debug=0x1f ? > > Attached is the dmesg with drm.debug=0x1f. > > Thanks, > Fengguang Ah so we're inheriting the FB 2x, once with 1280x1024, other with 1366x768: kern :debug : [ 74.880444] [drm:i9xx_get_initial_plane_config [i915]] pipe A/primary A with fb: size=1366x768@32, offset=61000, pitch 5504, size 0x408000 kern :debug : [ 74.881187] [drm:i915_gem_object_create_stolen_for_preallocated [i915]] creating preallocated stolen object: stolen_offset=0x00061000, gtt_offset=0x00061000, size=0x00408000 kern :debug : [ 74.882197] [drm:intel_alloc_initial_plane_obj.isra.126 [i915]] initial plane fb obj 5efa24f9 kern :debug : [ 74.883532] [drm:i9xx_get_initial_plane_config [i915]] pipe B/primary B with fb: size=1280x1024@32, offset=61000, pitch 5504, size 0x56 kern :debug : [ 74.884260] [drm:i915_gem_object_create_stolen_for_preallocated [i915]] creating preallocated stolen object: stolen_offset=0x00061000, gtt_offset=0x00061000, size=0x0056 kern :debug : [ 74.885295] [drm:i915_gem_object_create_stolen_for_preallocated [i915]] failed to allocate stolen space Which of course fails, but should be an interesting case to handle right. :) ~Maarten ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/sun4i: Add missing frontend compatibles for A10, A13, A20 and A31
On Thu, Apr 19, 2018 at 02:56:38PM +0200, Paul Kocialkowski wrote:
> Although frontend nodes are defined in the device-trees of the
> aforementioned platforms, there are no matching compatibles defined in
> the driver. This makes it impossible to probe the frontend on these
> platforms.
>
> Adding the appropriate compatibles to the driver fixes the issue.
>
> Signed-off-by: Paul Kocialkowski
> ---
> drivers/gpu/drm/sun4i/sun4i_frontend.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/sun4i/sun4i_frontend.c
> b/drivers/gpu/drm/sun4i/sun4i_frontend.c
> index 85f75046712c..c5a3de11817d 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_frontend.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_frontend.c
> @@ -658,6 +658,10 @@ static const struct dev_pm_ops sun4i_frontend_pm_ops = {
> };
>
> const struct of_device_id sun4i_frontend_of_table[] = {
> + { .compatible = "allwinner,sun7i-a10-display-frontend" },
> + { .compatible = "allwinner,sun7i-a13-display-frontend" },
> + { .compatible = "allwinner,sun7i-a20-display-frontend" },
> + { .compatible = "allwinner,sun7i-a31-display-frontend" },
Most of these compatibles are wrong, so it won't really work :)
If you only tested it on the A20, just add it. We didn't add all of
them because there's some slight variations between the generations
that are not yet taken into account.
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [[RFC]DPU PATCH 1/4] drm/bridge: add support for sn65dsi86 bridge driver
On Wed, Apr 18, 2018 at 05:49:59PM +0530, Sandeep Panda wrote:
> Add support for TI's sn65dsi86 dsi2edp bridge chip.
> The chip converts DSI transmitted signal to eDP signal,
> which is fed to the connected eDP panel.
>
> This chip can be controlled via either i2c interface or
> dsi interface. Currently in driver all the control registers
> are being accessed through i2c interface only.
> Also as of now HPD support has not been added to bridge
> chip driver.
>
> Signed-off-by: Sandeep Panda
> ---
> drivers/gpu/drm/bridge/ti-sn65dsi86.c | 742
> ++
> 1 file changed, 742 insertions(+)
> create mode 100644 drivers/gpu/drm/bridge/ti-sn65dsi86.c
>
> diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> new file mode 100644
> index 000..c798f2f
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> @@ -0,0 +1,742 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
There should be a copyright here.
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define SN_BRIDGE_REVISION_ID 0x2
> +
> +/* Link Training specific registers */
> +#define SN_DEVICE_REV_REG0x08
> +#define SN_REFCLK_FREQ_REG 0x0A
> +#define SN_DSI_LANES_REG 0x10
> +#define SN_DSIA_CLK_FREQ_REG 0x12
> +#define SN_ENH_FRAME_REG 0x5A
> +#define SN_SSC_CONFIG_REG0x93
> +#define SN_DATARATE_CONFIG_REG 0x94
> +#define SN_PLL_ENABLE_REG0x0D
> +#define SN_SCRAMBLE_CONFIG_REG 0x95
> +#define SN_AUX_WDATA0_REG0x64
> +#define SN_AUX_ADDR_19_16_REG0x74
> +#define SN_AUX_ADDR_15_8_REG 0x75
> +#define SN_AUX_ADDR_7_0_REG 0x76
> +#define SN_AUX_LENGTH_REG0x77
> +#define SN_AUX_CMD_REG 0x78
> +#define SN_ML_TX_MODE_REG0x96
> +#define SN_PAGE_SELECT_REG 0xFF
> +#define SN_AUX_RDATA0_REG0x79
> +/* video config specific registers */
> +#define SN_CHA_ACTIVE_LINE_LENGTH_LOW_REG0x20
> +#define SN_CHA_ACTIVE_LINE_LENGTH_HIGH_REG 0x21
> +#define SN_CHA_VERTICAL_DISPLAY_SIZE_LOW_REG 0x24
> +#define SN_CHA_VERTICAL_DISPLAY_SIZE_HIGH_REG0x25
> +#define SN_CHA_HSYNC_PULSE_WIDTH_LOW_REG 0x2C
> +#define SN_CHA_HSYNC_PULSE_WIDTH_HIGH_REG0x2D
> +#define SN_CHA_VSYNC_PULSE_WIDTH_LOW_REG 0x30
> +#define SN_CHA_VSYNC_PULSE_WIDTH_HIGH_REG0x31
> +#define SN_CHA_HORIZONTAL_BACK_PORCH_REG 0x34
> +#define SN_CHA_VERTICAL_BACK_PORCH_REG 0x36
> +#define SN_CHA_HORIZONTAL_FRONT_PORCH_REG0x38
> +#define SN_CHA_VERTICAL_FRONT_PORCH_REG 0x3A
> +#define SN_DATA_FORMAT_REG 0x5B
> +#define SN_COLOR_BAR_CONFIG_REG 0x3C
> +
> +#define DPPLL_CLK_SRC_REFCLK 0
> +#define DPPLL_CLK_SRC_DSICLK 1
> +#define MIN_DSI_CLK_FREQ_MHZ 40
> +
> +enum ti_sn_bridge_ref_clks {
> + SN_REF_CLK_12_MHZ = 0,
> + SN_REF_CLK_19_2_MHZ,
> + SN_REF_CLK_26_MHZ,
> + SN_REF_CLK_27_MHZ,
> + SN_REF_CLK_38_4_MHZ,
> + SN_REF_CLK_MAX,
> +};
> +
> +struct ti_sn_bridge {
> + struct device *dev;
> + struct drm_bridge bridge;
> + struct drm_connector connector;
> + struct device_node *host_node;
> + struct mipi_dsi_device *dsi;
> + /* handle to the connected eDP panel */
> + struct drm_panel *panel;
> + int irq;
> + struct gpio_desc *irq_gpio;
> + /* list of gpios needed to enable the bridge functionality */
> + struct gpio_descs *enable_gpios;
> + unsigned int num_supplies;
> + struct regulator_bulk_data *supplies;
> + struct i2c_client *i2c_client;
> + struct i2c_adapter *ddc;
> + bool power_on;
> + u32 num_modes;
> + struct drm_display_mode curr_mode;
> +};
> +
> +static int ti_sn_bridge_write(struct ti_sn_bridge *pdata, u8 reg, u8 val)
> +{
> + struct i2c_client *client = pdata->i2c_client;
> + u8 buf[2] = {reg, val};
> + struct i2c_msg msg = {
> + .addr = client->addr,
> + .flags = 0,
> + .len = 2,
> + .buf = buf,
> + };
> +
> + if (i2c_transfer(client->adapter, &msg, 1) < 1) {
> + DRM_ERROR("i2c write failed\n");
> + return -EIO;
> + }
> +
> + return 0;
> +}
> +
> +static int ti_sn_bridge_read(struct ti_sn_bridge *pdata,
> + u8 reg, char *buf, u32 size)
> +{
> + struct i2c_client *client = pdata->i2c_client;
> + struct i2c_msg msg[2] = {
> + {
> + .addr = client->addr,
> + .flags = 0,
> +
Re: [DPU PATCH 5/6] drm/msm: hook up DPU with upstream DSI
On Mon, Apr 16, 2018 at 11:22:20AM -0700, Jeykumar Sankaran wrote:
> Switch DPU from dsi-staging to upstream dsi driver. To make
> the switch atomic, this change includes:
> - remove dpu connector layers
> - clean up dpu connector dependencies in encoder/crtc
> - compile out writeback and display port drivers
> - compile out dsi-staging driver (separate patch submitted to
> remove the driver)
> - adapt upstream device hierarchy
>
> Signed-off-by: Jeykumar Sankaran
> ---
> .../config/arm64/chromiumos-arm64.flavour.config |4 +-
> .../arm64/chromiumos-qualcomm.flavour.config |4 +-
These files aren't in upstream.
> +
> +struct drm_encoder *dpu_encoder_init(struct drm_device *dev,
> + int drm_enc_mode)
> +{
> + struct dpu_encoder_virt *dpu_enc = NULL;
> +
> + dpu_enc = kzalloc(sizeof(*dpu_enc), GFP_KERNEL);
You should probably use devm_kzalloc.
> + if (!dpu_enc)
> + return ERR_PTR(ENOMEM);
> +
> + drm_encoder_init(dev, &dpu_enc->base, &dpu_encoder_funcs,
> + drm_enc_mode, NULL);
Check the return value?
> -#ifdef CONFIG_DRM_MSM_DSI_STAGING
> static void _dpu_kms_initialize_dsi(struct drm_device *dev,
> struct msm_drm_private *priv,
> - struct dpu_kms *dpu_kms,
> - unsigned max_encoders)
> + struct dpu_kms *dpu_kms)
> {
> - static const struct dpu_connector_ops dsi_ops = {
> - .post_init = dsi_conn_post_init,
> - .detect = dsi_conn_detect,
> - .get_modes = dsi_connector_get_modes,
> - .put_modes = dsi_connector_put_modes,
> - .mode_valid = dsi_conn_mode_valid,
> - .get_info = dsi_display_get_info,
> - .set_backlight = dsi_display_set_backlight,
> - .soft_reset = dsi_display_soft_reset,
> - .pre_kickoff = dsi_conn_pre_kickoff,
> - .clk_ctrl = dsi_display_clk_ctrl,
> - .set_power = dsi_display_set_power,
> - .get_mode_info = dsi_conn_get_mode_info,
> - .get_dst_format = dsi_display_get_dst_format,
> - .post_kickoff = dsi_conn_post_kickoff
> - };
> - struct msm_display_info info;
> - struct drm_encoder *encoder;
> - void *display, *connector;
> + struct drm_encoder *encoder = NULL;
> int i, rc;
>
> - /* dsi */
> - for (i = 0; i < dpu_kms->dsi_display_count &&
> - priv->num_encoders < max_encoders; ++i) {
> - display = dpu_kms->dsi_displays[i];
> - encoder = NULL;
> + /*TODO: Support two independent DSI connectors */
> + encoder = dpu_encoder_init(dev, DRM_MODE_CONNECTOR_DSI);
> + if (IS_ERR_OR_NULL(encoder)) {
> + DPU_ERROR("encoder init failed for dsi %d\n", i);
Is i meaningful here? It seems like it's uninitialized...
> + return;
> + }
>
> - memset(&info, 0x0, sizeof(info));
> - rc = dsi_display_get_info(&info, display);
> - if (rc) {
> - DPU_ERROR("dsi get_info %d failed\n", i);
> - continue;
> - }
> + priv->encoders[priv->num_encoders++] = encoder;
>
> - encoder = dpu_encoder_init(dev, &info);
> - if (IS_ERR_OR_NULL(encoder)) {
> - DPU_ERROR("encoder init failed for dsi %d\n", i);
> - continue;
> + for (i = 0; i < ARRAY_SIZE(priv->dsi); i++) {
> + if (!priv->dsi[i]) {
> + DPU_DEBUG("invalid msm_dsi for ctrl %d\n", i);
> + return;
> }
>
> - rc = dsi_display_drm_bridge_init(display, encoder);
> + rc = msm_dsi_modeset_init(priv->dsi[i], dev, encoder);
> if (rc) {
> - DPU_ERROR("dsi bridge %d init failed, %d\n", i, rc);
> - dpu_encoder_destroy(encoder);
> + DPU_ERROR("modeset_init failed for dsi[%d]\n", i);
Printing rc would be nice here, same for above.
> continue;
> }
> -
> - connector = dpu_connector_init(dev,
> - encoder,
> - 0,
> - display,
> - &dsi_ops,
> - DRM_CONNECTOR_POLL_HPD,
> - DRM_MODE_CONNECTOR_DSI);
> - if (connector) {
> - priv->encoders[priv->num_encoders++] = encoder;
> - } else {
> - DPU_ERROR("dsi %d connector init failed\n", i);
> - dsi_display_drm_bridge_deinit(display);
> - dpu_encoder_destroy(encoder);
> - }
> }
> }
> -#endif
> +
>
> #ifdef CONFIG_DRM_MSM_WRITEBACK
> stat
[pull] amdgpu drm-next-4.17
Hi Dave, A few fixes for 4.17: - Fix a dark screen issue in DC - Fix clk/voltage dependency tracking for wattman - Update SMU interface for vega12 The following changes since commit a10beabba213924d876f2d10ca9351aeab93f58a: Merge branch 'drm-next-4.17' of git://people.freedesktop.org/~agd5f/linux into drm-next (2018-04-13 09:25:21 +1000) are available in the git repository at: git://people.freedesktop.org/~agd5f/linux drm-next-4.17 for you to fetch changes up to cc9e992dfb5bb48f59f3fbc1268d3f38d2c86ef3: drm/amd/powerplay: header file interface to SMU update (2018-04-19 10:25:06 -0500) Harry Wentland (1): drm/amd/display: Don't program bypass on linear regamma LUT Kenneth Feng (1): drm/amd/powerplay: header file interface to SMU update Rex Zhu (1): drm/amd/pp: Fix bug voltage can't be OD separately on VI drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c | 7 --- drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c | 16 ++-- .../gpu/drm/amd/powerplay/inc/vega12/smu9_driver_if.h| 4 +++- 3 files changed, 13 insertions(+), 14 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
