Re: [PATCH V1 5/5] backlight: qcom-wled: Add auto string detection logic
On Wed 09 May 00:14 PDT 2018, kgu...@codeaurora.org wrote: > On 2018-05-07 23:40, Bjorn Andersson wrote: > > On Thu 03 May 02:57 PDT 2018, Kiran Gunda wrote: > > > > [..] > > > + > > > +#define WLED_AUTO_DETECT_OVP_COUNT 5 > > > +#define WLED_AUTO_DETECT_CNT_DLY_US HZ /* 1 second */ > > > +static bool wled_auto_detection_required(struct wled *wled) > > > > So cfg.auto_detection_enabled is set, but we didn't have a fault during > > wled_auto_detection_at_init(), which I presume indicates that the boot > > loader configured the strings appropriately (or didn't enable the BL). > > Then first time we try to enable the backlight we will hit the ovp irq, > > which will enter here a few times to figure out that the strings are > > incorrectly configured and then we will do the same thing that would > > have been done if we probed with a fault. > > > > This is convoluted! > > > > If auto-detection is a feature allowing the developer to omit the string > > configuration then just do the auto detection explicitly in probe when > > the developer did so and then never do it again. > > > As explained in the previous patch, the auto-detection is needed later, > because are also cases where one/more of the connected LED string of the > display-backlight is malfunctioning (because of damage) and requires the > damaged string to be turned off to prevent the complete panel and/or board > from being damaged. Okay, that sounds very reasonable. Please ensure that it's clearly described in the commit message, so that we have this documented if someone wonders in the future. Regards, Bjorn ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH 02/10] dt-bindings: devfreq: rk3399_dmc: Add rockchip, pmu phandle.
The Rockchip DMC (Dynamic Memory Interface) needs to access to the PMU general register files to know the DRAM type, so add a phandle to the syscon that manages these registers. Signed-off-by: Enric Balletbo i Serra --- Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt b/Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt index 0ec68141f85a..951789c0cdd6 100644 --- a/Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt +++ b/Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt @@ -12,6 +12,8 @@ Required properties: for details. - center-supply:DMC supply node. - status: Marks the node enabled/disabled. +- rockchip,pmu: Phandle to the syscon managing the "PMU general register +files". Optional properties: - interrupts: The CPU interrupt number. The interrupt specifier -- 2.17.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/vkms: Introduce basic VKMS driver
This patch introduces Virtual Kernel Mode-Setting (VKMS) driver. It
creates a very basic kms driver with 1 crtc/encoder/connector/plane.
VKMS driver would be useful for testing, or for running X (or similar)
on headless machines and be able to still use the GPU. Thus it enables
a virtual display without the need for hardware display capability.
Signed-off-by: Haneen Mohammed
---
drivers/gpu/drm/Kconfig | 6 ++
drivers/gpu/drm/Makefile| 1 +
drivers/gpu/drm/vkms/Makefile | 3 +
drivers/gpu/drm/vkms/vkms_drv.c | 146
drivers/gpu/drm/vkms/vkms_drv.h | 13 +++
5 files changed, 169 insertions(+)
create mode 100644 drivers/gpu/drm/vkms/Makefile
create mode 100644 drivers/gpu/drm/vkms/vkms_drv.c
create mode 100644 drivers/gpu/drm/vkms/vkms_drv.h
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 2a72d2feb76d..7db3d82cbb27 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -213,6 +213,12 @@ config DRM_VGEM
as used by Mesa's software renderer for enhanced performance.
If M is selected the module will be called vgem.
+config DRM_VKMS
+ tristate "Virtual KMS"
+ depends on DRM
+ help
+ Choose this option to get a virtual kernal mode-setting driver.
+ If M is selected the module will be called vkms.
source "drivers/gpu/drm/exynos/Kconfig"
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index ef9f3dab287f..8873d4769116 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -69,6 +69,7 @@ obj-$(CONFIG_DRM_SAVAGE)+= savage/
obj-$(CONFIG_DRM_VMWGFX)+= vmwgfx/
obj-$(CONFIG_DRM_VIA) +=via/
obj-$(CONFIG_DRM_VGEM) += vgem/
+obj-$(CONFIG_DRM_VKMS) += vkms/
obj-$(CONFIG_DRM_NOUVEAU) +=nouveau/
obj-$(CONFIG_DRM_EXYNOS) +=exynos/
obj-$(CONFIG_DRM_ROCKCHIP) +=rockchip/
diff --git a/drivers/gpu/drm/vkms/Makefile b/drivers/gpu/drm/vkms/Makefile
new file mode 100644
index ..2aef948d3a34
--- /dev/null
+++ b/drivers/gpu/drm/vkms/Makefile
@@ -0,0 +1,3 @@
+vkms-y := vkms_drv.o
+
+obj-$(CONFIG_DRM_VKMS) += vkms.o
diff --git a/drivers/gpu/drm/vkms/vkms_drv.c b/drivers/gpu/drm/vkms/vkms_drv.c
new file mode 100644
index ..b1df08ed23a0
--- /dev/null
+++ b/drivers/gpu/drm/vkms/vkms_drv.c
@@ -0,0 +1,146 @@
+/*
+ * 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.
+ */
+
+#include
+#include
+#include
+#include
+#include "vkms_drv.h"
+
+#define DRIVER_NAME"vkms"
+#define DRIVER_DESC"Virtual Kernel Mode Setting"
+#define DRIVER_DATE"20180514"
+#define DRIVER_MAJOR 1
+#define DRIVER_MINOR 0
+
+static struct vkms_device *vkms_device;
+
+static const struct file_operations vkms_driver_fops = {
+ .owner = THIS_MODULE,
+ .open = drm_open,
+ .mmap = drm_gem_mmap,
+ .unlocked_ioctl = drm_ioctl,
+ .compat_ioctl = drm_compat_ioctl,
+ .poll = drm_poll,
+ .read = drm_read,
+ .llseek = no_llseek,
+ .release= drm_release,
+};
+
+static void vkms_release(struct drm_device *dev)
+{
+ struct vkms_device *vkms = container_of(dev, struct vkms_device, drm);
+
+ platform_device_unregister(vkms->platform);
+ drm_mode_config_cleanup(&vkms->drm);
+ drm_dev_fini(&vkms->drm);
+}
+
+struct drm_driver vkms_driver = {
+ .driver_features= DRIVER_MODESET | DRIVER_ATOMIC | DRIVER_GEM,
+ .release= vkms_release,
+ .fops = &vkms_driver_fops,
+
+ .name = DRIVER_NAME,
+ .desc = DRIVER_DESC,
+ .date = DRIVER_DATE,
+ .major = DRIVER_MAJOR,
+ .minor = DRIVER_MINOR,
+};
+
+static const u32 vkms_formats[] = {
+ DRM_FORMAT_XRGB,
+};
+
+static void vkms_connector_destroy(struct drm_connector *connector)
+{
+ drm_connector_unregister(connector);
+ drm_connector_cleanup(connector);
+}
+
+static const struct drm_connector_funcs vkms_connector_funcs = {
+ .fill_modes = drm_helper_probe_single_connector_modes,
+ .destroy = vkms_connector_destroy,
+};
+
+static int __init vkms_init(void)
+{
+ int ret;
+
+ vkms_device = kzalloc(sizeof(*vkms_device), GFP_KERNEL);
+ if (!vkms_device)
+ return -ENOMEM;
+
+ ret = drm_dev_init(&vkms_device->drm, &vkms_driver, NULL);
+ if (ret)
+ goto out_free;
+
+ vkms_device->platform =
+ platform_device_register_simple(DRIVER_NAME, -1, NULL, 0);
+ if (IS_ERR(vkms_device->platform)) {
+ ret = PTR_ERR(vkms_device->platform);
+ goto out_fini;
+ }
+
+ drm_m
Re: [PATCH 09/21] arm64: dts: allwinner: a64: Add HDMI support
On Mon, May 14, 2018 at 2:10 PM, Maxime Ripard
wrote:
> On Mon, May 14, 2018 at 02:03:36PM +0530, Jagan Teki wrote:
>> On Wed, May 2, 2018 at 5:04 PM, Maxime Ripard
>> wrote:
>> > Hi,
>> >
>> > On Mon, Apr 30, 2018 at 05:10:46PM +0530, Jagan Teki wrote:
>> >> + hdmi_phy: hdmi-phy@1ef {
>> >> + compatible = "allwinner,sun50i-a64-hdmi-phy",
>> >> + "allwinner,sun8i-h3-hdmi-phy";
>> >> + reg = <0x01ef 0x1>;
>> >> + clocks = <&ccu CLK_BUS_HDMI>, <&ccu CLK_HDMI_DDC>,
>> >> + <&ccu CLK_PLL_VIDEO1>;
>> >
>> > You were discussing that the PLL0 could also be used to clock the PHY,
>> > has that been figured out?
>>
>> This is what I understand from Fig: 3-3. Module Clock Diagram, both
>> tcon0 and tcon1 are using HDMI. I'm thinking based on the tcon
>> configuration we need use proper PLL or some logic to get common PLL
>> don't know yet. Since this series adding tcon1 I've attached PLL1.
>
> You're not describing the TCON node here though, but the HDMI one, and
> the HDMI block is listed in both the PLL video 0 and 1.
So how can we attach particular PLL with particular HDMI(PLL0 to HDMI0
and so-on) or do we need to attached both the PLL's any suggestion?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 03/21] clk: sunxi-ng: Enable DE2_CCU for Allwinner 64-bit SoCs
On Tue, May 1, 2018 at 9:53 PM, Chen-Yu Tsai wrote: > On Mon, Apr 30, 2018 at 7:40 PM, Jagan Teki > wrote: >> Allwinner 64-bit SoC like H5/A64 has DE2 CCU so enable them >> as default. >> >> Signed-off-by: Jagan Teki >> --- >> drivers/clk/sunxi-ng/Kconfig | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/drivers/clk/sunxi-ng/Kconfig b/drivers/clk/sunxi-ng/Kconfig >> index 79dfd296c3d1..1fffd3bf6ff3 100644 >> --- a/drivers/clk/sunxi-ng/Kconfig >> +++ b/drivers/clk/sunxi-ng/Kconfig >> @@ -58,6 +58,8 @@ config SUN8I_V3S_CCU >> >> config SUN8I_DE2_CCU >> bool "Support for the Allwinner SoCs DE2 CCU" >> + default ARM64 && ARCH_SUNXI >> + depends on (DRM_SUN4I && (ARM64 && ARCH_SUNXI)) || COMPILE_TEST > > There is no reason to depend on DRM_SUN4I. There is no compile dependency. Since this CCU is for DE2 I've make DRM_SUN4I for that matter, any problem? > > Also, this is needed on SUN8I as well, pretty much anything with DE 2.0. > So you shouldn't limit it to ARM64. That pretty much breaks things for > people with A83T's or H3's. In fact you should enable it by default for > these as well. True, I've skipped SUN8I since this series for A64. Jagan. -- Jagan Teki Senior Linux Kernel Engineer | Amarula Solutions U-Boot, Linux | Upstream Maintainer Hyderabad, India. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3] display: panel: Add AUO g070vvn01 display support (800x480)
Dear All,
> This commit adds support for AUO's 7.0" display.
If I may gentle remind about this patch
>
> Signed-off-by: Lukasz Majewski
>
> ---
> Changes for v3:
> - Remove not used 'bus-format-override = "rgb565";' property
>
> Changes for v2:
> - Add *.txt suffix to the auo,g070wn01 file
> ---
> .../bindings/display/panel/auo,g070vvn01.txt | 29
>
> drivers/gpu/drm/panel/panel-simple.c | 31
> ++ 2 files changed, 60 insertions(+) create mode
> 100644
> Documentation/devicetree/bindings/display/panel/auo,g070vvn01.txt
>
> diff --git
> a/Documentation/devicetree/bindings/display/panel/auo,g070vvn01.txt
> b/Documentation/devicetree/bindings/display/panel/auo,g070vvn01.txt
> new file mode 100644 index ..49e4105378f6 --- /dev/null
> +++
> b/Documentation/devicetree/bindings/display/panel/auo,g070vvn01.txt
> @@ -0,0 +1,29 @@ +AU Optronics Corporation 7.0" FHD (800 x 480) TFT
> LCD panel +
> +Required properties:
> +- compatible: should be "auo,g070vvn01"
> +- backlight: phandle of the backlight device attached to the panel
> +- power-supply: single regulator to provide the supply voltage
> +
> +Required nodes:
> +- port: Parallel port mapping to connect this display
> +
> +This panel needs single power supply voltage. Its backlight is
> conntrolled +via PWM signal.
> +
> +Example:
> +
> +
> +Example device-tree definition when connected to iMX6Q based board
> +
> + lcd_panel: lcd-panel {
> + compatible = "auo,g070vvn01";
> + backlight = <&backlight_lcd>;
> + power-supply = <®_display>;
> +
> + port {
> + lcd_panel_in: endpoint {
> + remote-endpoint = <&lcd_display_out>;
> + };
> + };
> + };
> diff --git a/drivers/gpu/drm/panel/panel-simple.c
> b/drivers/gpu/drm/panel/panel-simple.c index
> cbf1ab404ee7..d9984bdb5bb5 100644 ---
> a/drivers/gpu/drm/panel/panel-simple.c +++
> b/drivers/gpu/drm/panel/panel-simple.c @@ -581,6 +581,34 @@ static
> const struct panel_desc auo_b133htn01 = { },
> };
>
> +static const struct display_timing auo_g070vvn01_timings = {
> + .pixelclock = { 3330, 34209000, 4500 },
> + .hactive = { 800, 800, 800 },
> + .hfront_porch = { 20, 40, 200 },
> + .hback_porch = { 87, 40, 1 },
> + .hsync_len = { 1, 48, 87 },
> + .vactive = { 480, 480, 480 },
> + .vfront_porch = { 5, 13, 200 },
> + .vback_porch = { 31, 31, 29 },
> + .vsync_len = { 1, 1, 3 },
> +};
> +
> +static const struct panel_desc auo_g070vvn01 = {
> + .timings = &auo_g070vvn01_timings,
> + .num_timings = 1,
> + .bpc = 8,
> + .size = {
> + .width = 152,
> + .height = 91,
> + },
> + .delay = {
> + .prepare = 200,
> + .enable = 50,
> + .disable = 50,
> + .unprepare = 1000,
> + },
> +};
> +
> static const struct drm_display_mode auo_g104sn02_mode = {
> .clock = 4,
> .hdisplay = 800,
> @@ -2095,6 +2123,9 @@ static const struct of_device_id
> platform_of_match[] = { .compatible = "auo,b133xtn01",
> .data = &auo_b133xtn01,
> }, {
> + .compatible = "auo,g070vvn01",
> + .data = &auo_g070vvn01,
> + }, {
> .compatible = "auo,g104sn02",
> .data = &auo_g104sn02,
> }, {
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
pgpJ9eeOFfACl.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH rdma-next 01/21] drm/i915: Move u64-to-ptr helpers to general header
On Thu, May 03, 2018 at 04:36:55PM +0300, Leon Romanovsky wrote: > From: Leon Romanovsky > > The macro u64_to_ptr() and function ptr_to_u64() are useful enough > to be part of general header, so move them there and allow RDMA > subsystem reuse them. > > Signed-off-by: Leon Romanovsky > --- > drivers/gpu/drm/i915/i915_utils.h | 12 ++-- > include/linux/kernel.h| 12 > 2 files changed, 14 insertions(+), 10 deletions(-) This patch and the next one to kernel.h will need to be Ack'd be someone.. But I am not sure who.. AndrewM perhaps? Jason ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 3/4] phy: rockchip-typec: support variable phy config value
the phy config values used to fix in dp firmware, but some boards
need change these values to do training and get the better eye diagram
result. So support that in phy driver.
Signed-off-by: Chris Zhong
Signed-off-by: Lin Huang
---
Changes in v2:
- update patch following Enric suggest
Changes in v3:
- delete need_software_training variable
- add default phy config value, if dts do not define phy config value, use
these value
drivers/phy/rockchip/phy-rockchip-typec.c | 305 --
include/soc/rockchip/rockchip_phy_typec.h | 63 ++
2 files changed, 270 insertions(+), 98 deletions(-)
create mode 100644 include/soc/rockchip/rockchip_phy_typec.h
diff --git a/drivers/phy/rockchip/phy-rockchip-typec.c
b/drivers/phy/rockchip/phy-rockchip-typec.c
index 76a4b58..10253ad 100644
--- a/drivers/phy/rockchip/phy-rockchip-typec.c
+++ b/drivers/phy/rockchip/phy-rockchip-typec.c
@@ -63,6 +63,7 @@
#include
#include
+#include
#define CMN_SSM_BANDGAP(0x21 << 2)
#define CMN_SSM_BIAS (0x22 << 2)
@@ -323,21 +324,29 @@
* clock 0: PLL 0 div 1
* clock 1: PLL 1 div 2
*/
-#define CLK_PLL_CONFIG 0X30
+#define CLK_PLL1_DIV1 0x20
+#define CLK_PLL1_DIV2 0x30
#define CLK_PLL_MASK 0x33
#define CMN_READY BIT(0)
+#define DP_PLL_CLOCK_ENABLE_ACKBIT(3)
#define DP_PLL_CLOCK_ENABLEBIT(2)
+#define DP_PLL_ENABLE_ACK BIT(1)
#define DP_PLL_ENABLE BIT(0)
#define DP_PLL_DATA_RATE_RBR ((2 << 12) | (4 << 8))
#define DP_PLL_DATA_RATE_HBR ((2 << 12) | (4 << 8))
#define DP_PLL_DATA_RATE_HBR2 ((1 << 12) | (2 << 8))
+#define DP_PLL_DATA_RATE_MASK 0xff00
-#define DP_MODE_A0 BIT(4)
-#define DP_MODE_A2 BIT(6)
-#define DP_MODE_ENTER_A0 0xc101
-#define DP_MODE_ENTER_A2 0xc104
+#define DP_MODE_MASK 0xf
+#define DP_MODE_ENTER_A0 BIT(0)
+#define DP_MODE_ENTER_A2 BIT(2)
+#define DP_MODE_ENTER_A3 BIT(3)
+#define DP_MODE_A0_ACK BIT(4)
+#define DP_MODE_A2_ACK BIT(6)
+#define DP_MODE_A3_ACK BIT(7)
+#define DP_LINK_RESET_DEASSERTED BIT(8)
#define PHY_MODE_SET_TIMEOUT 10
@@ -349,51 +358,7 @@
#define MODE_DFP_USB BIT(1)
#define MODE_DFP_DPBIT(2)
-struct usb3phy_reg {
- u32 offset;
- u32 enable_bit;
- u32 write_enable;
-};
-
-/**
- * struct rockchip_usb3phy_port_cfg: usb3-phy port configuration.
- * @reg: the base address for usb3-phy config.
- * @typec_conn_dir: the register of type-c connector direction.
- * @usb3tousb2_en: the register of type-c force usb2 to usb2 enable.
- * @external_psm: the register of type-c phy external psm clock.
- * @pipe_status: the register of type-c phy pipe status.
- * @usb3_host_disable: the register of type-c usb3 host disable.
- * @usb3_host_port: the register of type-c usb3 host port.
- * @uphy_dp_sel: the register of type-c phy DP select control.
- */
-struct rockchip_usb3phy_port_cfg {
- unsigned int reg;
- struct usb3phy_reg typec_conn_dir;
- struct usb3phy_reg usb3tousb2_en;
- struct usb3phy_reg external_psm;
- struct usb3phy_reg pipe_status;
- struct usb3phy_reg usb3_host_disable;
- struct usb3phy_reg usb3_host_port;
- struct usb3phy_reg uphy_dp_sel;
-};
-
-struct rockchip_typec_phy {
- struct device *dev;
- void __iomem *base;
- struct extcon_dev *extcon;
- struct regmap *grf_regs;
- struct clk *clk_core;
- struct clk *clk_ref;
- struct reset_control *uphy_rst;
- struct reset_control *pipe_rst;
- struct reset_control *tcphy_rst;
- const struct rockchip_usb3phy_port_cfg *port_cfgs;
- /* mutex to protect access to individual PHYs */
- struct mutex lock;
-
- bool flip;
- u8 mode;
-};
+#define DP_DEFAULT_RATE162000
struct phy_reg {
u16 value;
@@ -417,15 +382,15 @@ struct phy_reg usb3_pll_cfg[] = {
{ 0x8, CMN_DIAG_PLL0_LF_PROG },
};
-struct phy_reg dp_pll_cfg[] = {
+struct phy_reg dp_pll_rbr_cfg[] = {
{ 0xf0, CMN_PLL1_VCOCAL_INIT },
{ 0x18, CMN_PLL1_VCOCAL_ITER },
{ 0x30b9, CMN_PLL1_VCOCAL_START },
- { 0x21c,CMN_PLL1_INTDIV },
+ { 0x87, CMN_PLL1_INTDIV },
{ 0,CMN_PLL1_FRACDIV },
- { 0x5, CMN_PLL1_HIGH_THR },
- { 0x35, CMN_PLL1_SS_CTRL1 },
- { 0x7f1e, CMN_PLL1_SS_CTRL2 },
+ { 0x22, CMN_PLL1_HIGH_THR },
+ { 0x8000, CMN_PLL1_SS_CTRL1 },
+ { 0,CMN_PLL1_SS_CTRL2 },
{ 0x20, CMN_PLL1_DSM_DIAG },
{ 0,CMN_PLLSM1_USER
Re: [PATCH 4/6] drm/panel: simple: Add support for Banana Pi 7" S070WV20-CT16 panel
On Thu, Apr 19, 2018 at 3:02 PM, Chen-Yu Tsai wrote:
> 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,
> + },
> +};
I think this parallel RGB interface right? I too have same display
with DSI I'm sure these setting will not useful right? do we need to
write separate panel driver for that?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH 08/10] drm: rockchip: Add DDR devfreq support.
From: Sean Paul
Add support for devfreq to dynamically control the DDR frequency. It
will activate when there is one CRTC active, and disable if more than
one becomes active (to avoid flickering on one of the screens).
Signed-off-by: Sean Paul
Signed-off-by: Enric Balletbo i Serra
---
drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 46 +
drivers/gpu/drm/rockchip/rockchip_drm_drv.h | 9
drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 35
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 34 +++
4 files changed, 124 insertions(+)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
index f814d37b1db2..e774f3c7c325 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
@@ -19,6 +19,8 @@
#include
#include
#include
+#include
+#include
#include
#include
#include
@@ -77,6 +79,46 @@ void rockchip_drm_dma_detach_device(struct drm_device
*drm_dev,
iommu_detach_device(domain, dev);
}
+#if IS_ENABLED(CONFIG_ARM_RK3399_DMC_DEVFREQ)
+static int rockchip_drm_init_devfreq(struct device *dev,
+struct rockchip_drm_private *priv)
+{
+ struct devfreq *devfreq;
+ struct devfreq_event_dev *edev;
+ int ret;
+
+ devfreq = devfreq_get_devfreq_by_phandle(dev, 0);
+ if (IS_ERR(devfreq)) {
+ ret = PTR_ERR(devfreq);
+ if (ret == -ENODEV) {
+ DRM_DEV_INFO(dev, "devfreq missing, skip\n");
+ return 0;
+ }
+ return ret;
+ }
+
+ edev = devfreq_event_get_edev_by_phandle(devfreq->dev.parent, 0);
+ if (IS_ERR(edev)) {
+ ret = PTR_ERR(edev);
+ if (ret == -ENODEV) {
+ DRM_DEV_INFO(dev, "devfreq edev missing, skip\n");
+ return 0;
+ }
+ return ret;
+ }
+
+ priv->devfreq = devfreq;
+ priv->devfreq_event_dev = edev;
+ return 0;
+}
+#else
+static int rockchip_drm_init_devfreq(struct device *dev,
+struct rockchip_drm_private *priv)
+{
+ return 0;
+}
+#endif
+
static int rockchip_drm_init_iommu(struct drm_device *drm_dev)
{
struct rockchip_drm_private *private = drm_dev->dev_private;
@@ -136,6 +178,10 @@ static int rockchip_drm_bind(struct device *dev)
INIT_LIST_HEAD(&private->psr_list);
mutex_init(&private->psr_list_lock);
+ ret = rockchip_drm_init_devfreq(dev, private);
+ if (ret)
+ goto err_free;
+
ret = rockchip_drm_init_iommu(drm_dev);
if (ret)
goto err_free;
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
index 3a6ebfc26036..cc13fac59644 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
@@ -57,6 +57,10 @@ struct rockchip_drm_private {
struct drm_mm mm;
struct list_head psr_list;
struct mutex psr_list_lock;
+
+ struct devfreq *devfreq;
+ struct devfreq_event_dev *devfreq_event_dev;
+ bool dmc_disable_flag;
};
int rockchip_drm_dma_attach_device(struct drm_device *drm_dev,
@@ -65,6 +69,11 @@ void rockchip_drm_dma_detach_device(struct drm_device
*drm_dev,
struct device *dev);
int rockchip_drm_wait_vact_end(struct drm_crtc *crtc, unsigned int mstimeout);
+uint32_t rockchip_drm_get_vblank_ns(struct drm_display_mode *mode);
+
+void rockchip_drm_enable_dmc(struct rockchip_drm_private *priv);
+void rockchip_drm_disable_dmc(struct rockchip_drm_private *priv);
+
extern struct platform_driver cdn_dp_driver;
extern struct platform_driver dw_hdmi_rockchip_pltfm_driver;
extern struct platform_driver dw_mipi_dsi_driver;
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
index d4f4118b482d..bf10f7982278 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include "rockchip_drm_drv.h"
#include "rockchip_drm_fb.h"
@@ -185,6 +186,16 @@ rockchip_drm_psr_inhibit_get_state(struct drm_atomic_state
*state)
rockchip_drm_psr_inhibit_get(encoder);
}
+uint32_t rockchip_drm_get_vblank_ns(struct drm_display_mode *mode)
+{
+ uint64_t vblank_time = mode->vtotal - mode->vdisplay;
+
+ vblank_time *= (uint64_t)NSEC_PER_SEC * mode->htotal;
+ do_div(vblank_time, mode->clock * 1000);
+
+ return vblank_time;
+}
+
static void
rockchip_drm_psr_inhibit_put_state(struct drm_atomic_state *state)
{
@@ -207,9 +218,28 @@ static void
rockchip_atomic_helper_commit_tail_rpm(struct drm_atomic_state *old_state)
{
struct drm_device *dev = old_state->dev;
+ struct
[PATCH v4 2/4] Documentation: bindings: add phy_config for Rockchip USB Type-C PHY
If want to do training outside DP Firmware, need phy voltage swing
and pre_emphasis value.
Signed-off-by: Lin Huang
---
Changes in v2:
- None
Changes in v3:
- modify property description and add this property to Example
Change in v4:
- None
.../devicetree/bindings/phy/phy-rockchip-typec.txt | 29 +-
1 file changed, 28 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/phy/phy-rockchip-typec.txt
b/Documentation/devicetree/bindings/phy/phy-rockchip-typec.txt
index 960da7f..af298f2 100644
--- a/Documentation/devicetree/bindings/phy/phy-rockchip-typec.txt
+++ b/Documentation/devicetree/bindings/phy/phy-rockchip-typec.txt
@@ -17,7 +17,8 @@ Required properties:
Optional properties:
- extcon : extcon specifier for the Power Delivery
-
+ - rockchip,phy_config : A list of voltage swing(mv) and pre-emphasis
+ (dB) pairs.
Required nodes : a sub-node is required for each port the phy provides.
The sub-node name is used to identify dp or usb3 port,
and shall be the following entries:
@@ -50,6 +51,19 @@ Example:
<&cru SRST_P_UPHY0_TCPHY>;
reset-names = "uphy", "uphy-pipe", "uphy-tcphy";
+ rockchip,phy_config =<0x2a 0x00
+ 0x1f 0x15
+ 0x14 0x22
+ 0x02 0x2b
+ 0x21 0x00
+ 0x12 0x15
+ 0x02 0x22
+ 0 0
+ 0x15 0x00
+ 0x00 0x15
+ 0 0
+ 0 0>;
+
tcphy0_dp: dp-port {
#phy-cells = <0>;
};
@@ -74,6 +88,19 @@ Example:
<&cru SRST_P_UPHY1_TCPHY>;
reset-names = "uphy", "uphy-pipe", "uphy-tcphy";
+ rockchip,phy_config =<0x2a 0x00
+ 0x1f 0x15
+ 0x14 0x22
+ 0x02 0x2b
+ 0x21 0x00
+ 0x12 0x15
+ 0x02 0x22
+ 0 0
+ 0x15 0x00
+ 0x00 0x15
+ 0 0
+ 0 0>;
+
tcphy1_dp: dp-port {
#phy-cells = <0>;
};
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 RESEND] display: panel: Add AUO g070vvn01 display support (800x480)
This commit adds support for AUO's 7.0" display.
Signed-off-by: Lukasz Majewski
Reviewed-by: Rob Herring
---
Changes for v3:
- Remove not used 'bus-format-override = "rgb565";' property
Changes for v2:
- Add *.txt suffix to the auo,g070wn01 file
---
.../bindings/display/panel/auo,g070vvn01.txt | 29
drivers/gpu/drm/panel/panel-simple.c | 31 ++
2 files changed, 60 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/auo,g070vvn01.txt
diff --git a/Documentation/devicetree/bindings/display/panel/auo,g070vvn01.txt
b/Documentation/devicetree/bindings/display/panel/auo,g070vvn01.txt
new file mode 100644
index ..49e4105378f6
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/auo,g070vvn01.txt
@@ -0,0 +1,29 @@
+AU Optronics Corporation 7.0" FHD (800 x 480) TFT LCD panel
+
+Required properties:
+- compatible: should be "auo,g070vvn01"
+- backlight: phandle of the backlight device attached to the panel
+- power-supply: single regulator to provide the supply voltage
+
+Required nodes:
+- port: Parallel port mapping to connect this display
+
+This panel needs single power supply voltage. Its backlight is conntrolled
+via PWM signal.
+
+Example:
+
+
+Example device-tree definition when connected to iMX6Q based board
+
+ lcd_panel: lcd-panel {
+ compatible = "auo,g070vvn01";
+ backlight = <&backlight_lcd>;
+ power-supply = <®_display>;
+
+ port {
+ lcd_panel_in: endpoint {
+ remote-endpoint = <&lcd_display_out>;
+ };
+ };
+ };
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index cbf1ab404ee7..d9984bdb5bb5 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -581,6 +581,34 @@ static const struct panel_desc auo_b133htn01 = {
},
};
+static const struct display_timing auo_g070vvn01_timings = {
+ .pixelclock = { 3330, 34209000, 4500 },
+ .hactive = { 800, 800, 800 },
+ .hfront_porch = { 20, 40, 200 },
+ .hback_porch = { 87, 40, 1 },
+ .hsync_len = { 1, 48, 87 },
+ .vactive = { 480, 480, 480 },
+ .vfront_porch = { 5, 13, 200 },
+ .vback_porch = { 31, 31, 29 },
+ .vsync_len = { 1, 1, 3 },
+};
+
+static const struct panel_desc auo_g070vvn01 = {
+ .timings = &auo_g070vvn01_timings,
+ .num_timings = 1,
+ .bpc = 8,
+ .size = {
+ .width = 152,
+ .height = 91,
+ },
+ .delay = {
+ .prepare = 200,
+ .enable = 50,
+ .disable = 50,
+ .unprepare = 1000,
+ },
+};
+
static const struct drm_display_mode auo_g104sn02_mode = {
.clock = 4,
.hdisplay = 800,
@@ -2095,6 +2123,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "auo,b133xtn01",
.data = &auo_b133xtn01,
}, {
+ .compatible = "auo,g070vvn01",
+ .data = &auo_g070vvn01,
+ }, {
.compatible = "auo,g104sn02",
.data = &auo_g104sn02,
}, {
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 1/4] drm/bridge: add support for sn65dsi86 bridge driver
On 2018-05-03 00:33, Sean Paul wrote: On Wed, May 02, 2018 at 10:01:59AM +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. Changes in v1: - Split the dt-bindings and the driver support into separate patches (Andrzej Hajda). - Use of gpiod APIs to parse and configure gpios instead of obsolete ones (Andrzej Hajda). - Use macros to define the register offsets (Andrzej Hajda). Changes in v2: - Separate out edp panel specific HW resource handling from bridge driver and create a separate edp panel drivers to handle panel specific mode information and HW resources (Sean Paul). - Replace pr_* APIs to DRM_* APIs to log error or debug information (Sean Paul). - Remove some of the unnecessary structure/variable from driver (Sean Paul). - Rename the function and structure prefix "sn65dsi86" to "ti_sn_bridge" (Sean Paul / Rob Herring). - Remove most of the hard-coding and modified the bridge init sequence based on current mode (Sean Paul). - Remove the existing function to retrieve the EDID data and implemented this as an i2c_adapter and use drm_get_edid() (Sean Paul). - Remove the dummy irq handler implementation, will add back the proper irq handling later (Sean Paul). - Capture the required enable gpios in a single array based on dt entry instead of having individual descriptor for each gpio (Sean Paul). Changes in v3: - Remove usage of irq_gpio and replace it as "interrupts" property (Rob Herring). - Remove the unnecessary header file inclusions (Sean Paul). - Rearrange the header files in alphabetical order (Sean Paul). - Use regmap interface to perform i2c transactions. - Update Copyright/License field and address other review comments (Jordan Crouse). Changes in v4: - Update License/Copyright (Sean Paul). - Add Kconfig and Makefile changes (Sean Paul). - Drop i2c gpio handling from this bridge driver, since i2c sda/scl gpios will be handled by i2c master. - Remove unnecessary goto statements (Sean Paul). - Add mutex lock to power_ctrl API to avoid race conditions (Sean Paul). - Add support to parse reference clk frequency from dt(optional). - Update the bridge chip enable/disable sequence. It seems like you also added 2 new supply names, as well as remove the configurable gpios? Changes in v5: - Fixed Kbuild test service reported warnings. Signed-off-by: Sandeep Panda --- drivers/gpu/drm/bridge/Kconfig| 9 + drivers/gpu/drm/bridge/Makefile | 1 + drivers/gpu/drm/bridge/ti-sn65dsi86.c | 725 ++ 3 files changed, 735 insertions(+) create mode 100644 drivers/gpu/drm/bridge/ti-sn65dsi86.c diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig index 3b99d5a..8153150 100644 --- a/drivers/gpu/drm/bridge/Kconfig +++ b/drivers/gpu/drm/bridge/Kconfig @@ -108,6 +108,15 @@ config DRM_TI_TFP410 ---help--- Texas Instruments TFP410 DVI/HDMI Transmitter driver +config DRM_TI_SN65DSI86 + tristate "TI SN65DSI86 DSI to eDP bridge" + depends on OF + select DRM_KMS_HELPER + select REGMAP_I2C + select DRM_PANEL + ---help--- + Texas Instruments SN65DSI86 DSI to eDP Bridge driver + source "drivers/gpu/drm/bridge/analogix/Kconfig" source "drivers/gpu/drm/bridge/adv7511/Kconfig" diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile index 373eb28..3711be8 100644 --- a/drivers/gpu/drm/bridge/Makefile +++ b/drivers/gpu/drm/bridge/Makefile @@ -12,4 +12,5 @@ obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/ obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/ obj-$(CONFIG_DRM_TI_TFP410) += ti-tfp410.o +obj-$(CONFIG_DRM_TI_SN65DSI86) += ti-sn65dsi86.o obj-y += synopsys/ diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c b/drivers/gpu/drm/bridge/ti-sn65dsi86.c new file mode 100644 index 000..019c7cd --- /dev/null +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c @@ -0,0 +1,725 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Copyright (c) 2018, The Linux Foundation. All rights reserved. + */ + +#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_HPD_DISABLE_REG 0x5C +#define SN_REFCLK_FREQ_REG 0x0A +#define SN_DSI_LANES_REG 0x10 +#define SN_DSIA_CLK_FREQ_REG 0x12 +#define SN_ENH_FRAME_REG
Re: [PATCH] dma-fence: Make dma_fence_add_callback() fail if signaled with error
On Mon, 2018-05-14 at 18:48 +0200, Daniel Vetter wrote:
> On Fri, May 11, 2018 at 08:27:41AM +0100, Chris Wilson wrote:
> > Quoting Ezequiel Garcia (2018-05-09 21:14:49)
> > > Change how dma_fence_add_callback() behaves, when the fence
> > > has error-signaled by the time it is being add. After this commit,
> > > dma_fence_add_callback() returns the fence error, if it
> > > has error-signaled before dma_fence_add_callback() is called.
> >
> > Why? What problem are you trying to solve? fence->error does not imply
> > that the fence has yet been signaled, and the caller wants a callback
> > when it is signaled.
>
> On top this is incosistent, e.g. we don't do the same for any of the other
> dma_fence interfaces. Plus there's the issue that you might alias errno
> values with fence errno values.
>
Right.
> I think keeping the error codes from the functions you're calling distinct
> from the error code of the fence itself makes a lot of sense. The first
> tells you whether your request worked out (or why not), the second tells
> you whether the asynchronous dma operation (gpu rendering, page flip,
> whatever) that the dma_fence represents worked out (or why not). That's 2
> distinct things imo.
>
> Might be good to show us the driver code that needs this behaviour so we
> can discuss how to best handle your use-case.
>
This change arose while discussing the in-fences support for video4linux.
Here's the patch that calls dma_fence_add_callback
https://lkml.org/lkml/2018/5/4/766.
The code snippet currently looks something like this:
if (vb->in_fence) {
ret = dma_fence_add_callback(vb->in_fence, &vb->fence_cb,
vb2_qbuf_fence_cb);
/* is the fence signaled? */
if (ret == -ENOENT) {
dma_fence_put(vb->in_fence);
vb->in_fence = NULL;
} else if (ret)
{
goto unlock;
}
}
In this use case, if the callback is added successfully,
the video4linux core defers the activation of the buffer
until the fence signals.
If the fence is signaled (currently disregarding of errors)
then the buffer is assumed to be ready to be activated,
and so it gets queued for hardware usage.
Giving some more thought to this, I'm not so sure what is
the right action if a fence signaled with error. In this case,
it appears to me that we shouldn't be using this buffer
if its in-fence is in error, but perhaps I'm missing
something.
Thanks!
Eze
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH 01/10] devfreq: rockchip-dfi: Move GRF definitions to a common place.
Some rk3399 GRF (Generic Register Files) definitions can be used for
different drivers. Move these definitions to a common include so we
don't need to duplicate these definitions.
Signed-off-by: Enric Balletbo i Serra
---
drivers/devfreq/event/rockchip-dfi.c | 23 +++
include/soc/rockchip/rk3399_grf.h| 21 +
2 files changed, 28 insertions(+), 16 deletions(-)
create mode 100644 include/soc/rockchip/rk3399_grf.h
diff --git a/drivers/devfreq/event/rockchip-dfi.c
b/drivers/devfreq/event/rockchip-dfi.c
index 22b113363ffc..2fbbcbeb644f 100644
--- a/drivers/devfreq/event/rockchip-dfi.c
+++ b/drivers/devfreq/event/rockchip-dfi.c
@@ -26,6 +26,8 @@
#include
#include
+#include
+
#define RK3399_DMC_NUM_CH 2
/* DDRMON_CTRL */
@@ -43,18 +45,6 @@
#define DDRMON_CH1_COUNT_NUM 0x3c
#define DDRMON_CH1_DFI_ACCESS_NUM 0x40
-/* pmu grf */
-#define PMUGRF_OS_REG2 0x308
-#define DDRTYPE_SHIFT 13
-#define DDRTYPE_MASK 7
-
-enum {
- DDR3 = 3,
- LPDDR3 = 6,
- LPDDR4 = 7,
- UNUSED = 0xFF
-};
-
struct dmc_usage {
u32 access;
u32 total;
@@ -83,16 +73,17 @@ static void rockchip_dfi_start_hardware_counter(struct
devfreq_event_dev *edev)
u32 ddr_type;
/* get ddr type */
- regmap_read(info->regmap_pmu, PMUGRF_OS_REG2, &val);
- ddr_type = (val >> DDRTYPE_SHIFT) & DDRTYPE_MASK;
+ regmap_read(info->regmap_pmu, RK3399_PMUGRF_OS_REG2, &val);
+ ddr_type = (val >> RK3399_PMUGRF_DDRTYPE_SHIFT) &
+ RK3399_PMUGRF_DDRTYPE_MASK;
/* clear DDRMON_CTRL setting */
writel_relaxed(CLR_DDRMON_CTRL, dfi_regs + DDRMON_CTRL);
/* set ddr type to dfi */
- if (ddr_type == LPDDR3)
+ if (ddr_type == RK3399_PMUGRF_DDRTYPE_LPDDR3)
writel_relaxed(LPDDR3_EN, dfi_regs + DDRMON_CTRL);
- else if (ddr_type == LPDDR4)
+ else if (ddr_type == RK3399_PMUGRF_DDRTYPE_LPDDR4)
writel_relaxed(LPDDR4_EN, dfi_regs + DDRMON_CTRL);
/* enable count, use software mode */
diff --git a/include/soc/rockchip/rk3399_grf.h
b/include/soc/rockchip/rk3399_grf.h
new file mode 100644
index ..0f94034e2e9a
--- /dev/null
+++ b/include/soc/rockchip/rk3399_grf.h
@@ -0,0 +1,21 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Rockchip Generic Register Files definitions
+ *
+ * Copyright (c) 2018, Collabora Ltd.
+ * Author: Enric Balletbo i Serra
+ */
+
+#ifndef __SOC_RK3399_GRF_H
+#define __SOC_RK3399_GRF_H
+
+/* PMU GRF Registers */
+#define RK3399_PMUGRF_OS_REG2 0x308
+#define RK3399_PMUGRF_DDRTYPE_SHIFT13
+#define RK3399_PMUGRF_DDRTYPE_MASK 7
+#define RK3399_PMUGRF_DDRTYPE_DDR3 3
+#define RK3399_PMUGRF_DDRTYPE_LPDDR2 5
+#define RK3399_PMUGRF_DDRTYPE_LPDDR3 6
+#define RK3399_PMUGRF_DDRTYPE_LPDDR4 7
+
+#endif
--
2.17.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH 05/10] devfreq: rk3399_dmc / clk: rockchip: Sync with vblank in the kernel for DDRfreq.
From: Derek Basehore
This changes the kernel to sync with vblank for the display in the
kernel. This was done in Trusted Firmware-A (TF-A) before, but that locks
up one CPU for up to one display frame (1/60 second). That's bad for
performance and power, so this moves waiting to the kernel where the
waiting thread can properly wait on a completion.
Signed-off-by: Derek Basehore
Signed-off-by: Enric Balletbo i Serra
---
drivers/clk/rockchip/clk-ddr.c| 142 +-
drivers/clk/rockchip/clk.c| 2 +-
drivers/clk/rockchip/clk.h| 3 +-
drivers/devfreq/rk3399_dmc.c | 124 --
drivers/devfreq/rk3399_dmc_priv.h | 15
include/soc/rockchip/rk3399_dmc.h | 30 +++
6 files changed, 264 insertions(+), 52 deletions(-)
create mode 100644 drivers/devfreq/rk3399_dmc_priv.h
diff --git a/drivers/clk/rockchip/clk-ddr.c b/drivers/clk/rockchip/clk-ddr.c
index e8075359366b..707be1bd8910 100644
--- a/drivers/clk/rockchip/clk-ddr.c
+++ b/drivers/clk/rockchip/clk-ddr.c
@@ -17,7 +17,9 @@
#include
#include
#include
+#include
#include
+#include
#include
#include "clk.h"
@@ -30,39 +32,104 @@ struct rockchip_ddrclk {
int div_shift;
int div_width;
int ddr_flag;
- spinlock_t *lock;
+ unsigned long cached_rate;
+ struct work_struct set_rate_work;
+ struct mutexlock;
+ struct raw_notifier_head sync_chain;
};
#define to_rockchip_ddrclk_hw(hw) container_of(hw, struct rockchip_ddrclk, hw)
+#define DMC_DEFAULT_TIMEOUT_NS NSEC_PER_SEC
+#define DDRCLK_SET_RATE_MAX_RETRIES3
-static int rockchip_ddrclk_sip_set_rate(struct clk_hw *hw, unsigned long drate,
- unsigned long prate)
+static void rockchip_ddrclk_set_rate_func(struct work_struct *work)
{
- struct rockchip_ddrclk *ddrclk = to_rockchip_ddrclk_hw(hw);
- unsigned long flags;
+ struct rockchip_ddrclk *ddrclk = container_of(work,
+ struct rockchip_ddrclk, set_rate_work);
+ ktime_t timeout = ktime_add_ns(ktime_get(), DMC_DEFAULT_TIMEOUT_NS);
struct arm_smccc_res res;
+ int ret, i;
+
+ mutex_lock(&ddrclk->lock);
+ for (i = 0; i < DDRCLK_SET_RATE_MAX_RETRIES; i++) {
+ ret = raw_notifier_call_chain(&ddrclk->sync_chain, 0, &timeout);
+ if (ret == NOTIFY_BAD)
+ goto out;
+
+ /*
+* Check the timeout with irqs disabled. This is so we don't get
+* preempted after checking the timeout. That could cause things
+* like garbage values for the display if we change the DDR rate
+* at the wrong time.
+*/
+ local_irq_disable();
+ if (ktime_after(ktime_add_ns(ktime_get(), DMC_MIN_VBLANK_NS),
+ timeout)) {
+ local_irq_enable();
+ continue;
+ }
+
+ arm_smccc_smc(ROCKCHIP_SIP_DRAM_FREQ, ddrclk->cached_rate, 0,
+ ROCKCHIP_SIP_CONFIG_DRAM_SET_RATE,
+ 0, 0, 0, 0, &res);
+ local_irq_enable();
+ break;
+ }
+out:
+ mutex_unlock(&ddrclk->lock);
+}
- spin_lock_irqsave(ddrclk->lock, flags);
- arm_smccc_smc(ROCKCHIP_SIP_DRAM_FREQ, drate, 0,
- ROCKCHIP_SIP_CONFIG_DRAM_SET_RATE,
- 0, 0, 0, 0, &res);
- spin_unlock_irqrestore(ddrclk->lock, flags);
+int rockchip_ddrclk_register_sync_nb(struct clk *clk, struct notifier_block
*nb)
+{
+ struct clk_hw *hw = __clk_get_hw(clk);
+ struct rockchip_ddrclk *ddrclk;
+ int ret;
- return res.a0;
+ if (!hw || !nb)
+ return -EINVAL;
+
+ ddrclk = to_rockchip_ddrclk_hw(hw);
+ if (!ddrclk)
+ return -EINVAL;
+
+ mutex_lock(&ddrclk->lock);
+ ret = raw_notifier_chain_register(&ddrclk->sync_chain, nb);
+ mutex_unlock(&ddrclk->lock);
+
+ return ret;
}
+EXPORT_SYMBOL_GPL(rockchip_ddrclk_register_sync_nb);
-static unsigned long
-rockchip_ddrclk_sip_recalc_rate(struct clk_hw *hw,
- unsigned long parent_rate)
+int rockchip_ddrclk_unregister_sync_nb(struct clk *clk,
+ struct notifier_block *nb)
{
- struct arm_smccc_res res;
+ struct clk_hw *hw = __clk_get_hw(clk);
+ struct rockchip_ddrclk *ddrclk;
+ int ret;
- arm_smccc_smc(ROCKCHIP_SIP_DRAM_FREQ, 0, 0,
- ROCKCHIP_SIP_CONFIG_DRAM_GET_RATE,
- 0, 0, 0, 0, &res);
+ if (!hw || !nb)
+ return -EINVAL;
- return res.a0;
+ ddrclk = to_rockchip_ddrclk_hw(hw);
+ if (!ddrclk)
+ return -EINVAL;
+
+ mutex_lock(&ddrclk->lock);
[PATCH v6 3/4] drm/panel: add Innolux TV123WAM panel driver support
Add support for Innolux TV123WAM, which is a 12.3" eDP
display panel with 2160x1440 resolution.
Changes in v1:
- Add the compatibility string, display_mode and panel_desc
structures in alphabetical order (Sean Paul).
Signed-off-by: Sandeep Panda
---
drivers/gpu/drm/panel/panel-simple.c | 27 +++
1 file changed, 27 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 234af81..8c72270 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1190,6 +1190,30 @@ static void panel_simple_shutdown(struct device *dev)
},
};
+static const struct drm_display_mode innolux_tv123wam_mode = {
+ .clock = 206016,
+ .hdisplay = 2160,
+ .hsync_start = 2160 + 48,
+ .hsync_end = 2160 + 48 + 32,
+ .htotal = 2160 + 48 + 32 + 80,
+ .vdisplay = 1440,
+ .vsync_start = 1440 + 3,
+ .vsync_end = 1440 + 3 + 10,
+ .vtotal = 1440 + 3 + 10 + 27,
+ .vrefresh = 60,
+ .flags = DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC,
+};
+
+static const struct panel_desc innolux_tv123wam = {
+ .modes = &innolux_tv123wam_mode,
+ .num_modes = 1,
+ .bpc = 8,
+ .size = {
+ .width = 259,
+ .height = 173,
+ },
+};
+
static const struct drm_display_mode innolux_zj070na_01p_mode = {
.clock = 51501,
.hdisplay = 1024,
@@ -2037,6 +2061,9 @@ static void panel_simple_shutdown(struct device *dev)
.compatible = "innolux,n156bge-l21",
.data = &innolux_n156bge_l21,
}, {
+ .compatible = "innolux,tv123wam",
+ .data = &innolux_tv123wam,
+ }, {
.compatible = "innolux,zj070na-01p",
.data = &innolux_zj070na_01p,
}, {
--
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: drm SPDX updates
On Mon, May 14, 2018 at 05:01:43PM +0200, Thomas Hellstrom wrote: > > I haven't seen any comments in the week since I wrote this. I'm not > > familiar with the process for the drm changes - so what are the usual next > > steps? Do I need to submit all or part of this somewhere else? Or does > > Dave simply take the series (since it has no executable code changes at > > all)? > > There are a number of teams sending pull requests to Dave. One option would > be to have it all go through the drm-misc tree. (CC'ing Daniel Vetter about > that). Another option would perhaps be to send a pull request directly to > Dave (Dave?) And finally, one option would be to rely on the maintainers of > each submodule to take the patches that touch that module. If you go for > this last option, I can surely take the patches that touch vmwgfx, and > Christian the TTM patches. Again, since this involves no code changes, I think I'd prefer the path directly via Dave, simply as it makes it more likely that none of them get lost... assuming you are willing to do that, Dave, where would you like that PR? /D ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 01/10] devfreq: rockchip-dfi: Move GRF definitions to a common place.
Hi Enric,
On 2018년 05월 15일 06:16, Enric Balletbo i Serra wrote:
> Some rk3399 GRF (Generic Register Files) definitions can be used for
> different drivers. Move these definitions to a common include so we
> don't need to duplicate these definitions.
>
> Signed-off-by: Enric Balletbo i Serra
> ---
>
> drivers/devfreq/event/rockchip-dfi.c | 23 +++
> include/soc/rockchip/rk3399_grf.h| 21 +
> 2 files changed, 28 insertions(+), 16 deletions(-)
> create mode 100644 include/soc/rockchip/rk3399_grf.h
>
> diff --git a/drivers/devfreq/event/rockchip-dfi.c
> b/drivers/devfreq/event/rockchip-dfi.c
> index 22b113363ffc..2fbbcbeb644f 100644
> --- a/drivers/devfreq/event/rockchip-dfi.c
> +++ b/drivers/devfreq/event/rockchip-dfi.c
> @@ -26,6 +26,8 @@
> #include
> #include
>
> +#include
> +
> #define RK3399_DMC_NUM_CH2
>
> /* DDRMON_CTRL */
> @@ -43,18 +45,6 @@
> #define DDRMON_CH1_COUNT_NUM 0x3c
> #define DDRMON_CH1_DFI_ACCESS_NUM0x40
>
> -/* pmu grf */
> -#define PMUGRF_OS_REG2 0x308
> -#define DDRTYPE_SHIFT13
> -#define DDRTYPE_MASK 7
> -
> -enum {
> - DDR3 = 3,
> - LPDDR3 = 6,
> - LPDDR4 = 7,
> - UNUSED = 0xFF
> -};
> -
> struct dmc_usage {
> u32 access;
> u32 total;
> @@ -83,16 +73,17 @@ static void rockchip_dfi_start_hardware_counter(struct
> devfreq_event_dev *edev)
> u32 ddr_type;
>
> /* get ddr type */
> - regmap_read(info->regmap_pmu, PMUGRF_OS_REG2, &val);
> - ddr_type = (val >> DDRTYPE_SHIFT) & DDRTYPE_MASK;
> + regmap_read(info->regmap_pmu, RK3399_PMUGRF_OS_REG2, &val);
> + ddr_type = (val >> RK3399_PMUGRF_DDRTYPE_SHIFT) &
> + RK3399_PMUGRF_DDRTYPE_MASK;
>
> /* clear DDRMON_CTRL setting */
> writel_relaxed(CLR_DDRMON_CTRL, dfi_regs + DDRMON_CTRL);
>
> /* set ddr type to dfi */
> - if (ddr_type == LPDDR3)
> + if (ddr_type == RK3399_PMUGRF_DDRTYPE_LPDDR3)
> writel_relaxed(LPDDR3_EN, dfi_regs + DDRMON_CTRL);
> - else if (ddr_type == LPDDR4)
> + else if (ddr_type == RK3399_PMUGRF_DDRTYPE_LPDDR4)
> writel_relaxed(LPDDR4_EN, dfi_regs + DDRMON_CTRL);
>
> /* enable count, use software mode */
> diff --git a/include/soc/rockchip/rk3399_grf.h
> b/include/soc/rockchip/rk3399_grf.h
> new file mode 100644
> index ..0f94034e2e9a
> --- /dev/null
> +++ b/include/soc/rockchip/rk3399_grf.h
> @@ -0,0 +1,21 @@
> +/* SPDX-License-Identifier: GPL-2.0+ */
> +/*
> + * Rockchip Generic Register Files definitions
> + *
> + * Copyright (c) 2018, Collabora Ltd.
> + * Author: Enric Balletbo i Serra
> + */
> +
> +#ifndef __SOC_RK3399_GRF_H
> +#define __SOC_RK3399_GRF_H
> +
> +/* PMU GRF Registers */
> +#define RK3399_PMUGRF_OS_REG20x308
> +#define RK3399_PMUGRF_DDRTYPE_SHIFT 13
> +#define RK3399_PMUGRF_DDRTYPE_MASK 7
> +#define RK3399_PMUGRF_DDRTYPE_DDR3 3
> +#define RK3399_PMUGRF_DDRTYPE_LPDDR2 5
> +#define RK3399_PMUGRF_DDRTYPE_LPDDR3 6
> +#define RK3399_PMUGRF_DDRTYPE_LPDDR4 7
> +
> +#endif
>
Looks good to me.
Acked-by: Chanwoo Choi
--
Best Regards,
Chanwoo Choi
Samsung Electronics
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V1 5/5] backlight: qcom-wled: Add auto string detection logic
On 2018-05-14 22:32, Bjorn Andersson wrote: On Wed 09 May 00:14 PDT 2018, kgu...@codeaurora.org wrote: On 2018-05-07 23:40, Bjorn Andersson wrote: > On Thu 03 May 02:57 PDT 2018, Kiran Gunda wrote: > > [..] > > + > > +#define WLED_AUTO_DETECT_OVP_COUNT 5 > > +#define WLED_AUTO_DETECT_CNT_DLY_US HZ /* 1 second */ > > +static bool wled_auto_detection_required(struct wled *wled) > > So cfg.auto_detection_enabled is set, but we didn't have a fault during > wled_auto_detection_at_init(), which I presume indicates that the boot > loader configured the strings appropriately (or didn't enable the BL). > Then first time we try to enable the backlight we will hit the ovp irq, > which will enter here a few times to figure out that the strings are > incorrectly configured and then we will do the same thing that would > have been done if we probed with a fault. > > This is convoluted! > > If auto-detection is a feature allowing the developer to omit the string > configuration then just do the auto detection explicitly in probe when > the developer did so and then never do it again. > As explained in the previous patch, the auto-detection is needed later, because are also cases where one/more of the connected LED string of the display-backlight is malfunctioning (because of damage) and requires the damaged string to be turned off to prevent the complete panel and/or board from being damaged. Okay, that sounds very reasonable. Please ensure that it's clearly described in the commit message, so that we have this documented if someone wonders in the future. Regards, Bjorn -- Thanks for that ! Sure I will describe it in the commit message. To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" 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
Re: [PATCH] gpu: drm: qxl: Adding new typedef vm_fault_t
On Mon, May 14, 2018 at 2:32 PM, Gerd Hoffmann wrote: > Hi, > >> > So my expectation that a backmerge happens anyway after -rc1/2 is in >> > line with reality, it is just to be delayed this time. I'll stay >> > tuned ;) >> >> Is this patch already merged in drm-misc-next tree ? > > Pushed now. > Thanks Gerd :) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] staging: android: ion: Check return value of ion_buffer_kmap_get
GCC warns that vaddr is set but unused. Check the return value of
ion_buffer_kmap_get to make vaddr useful and make sure everything
is properly configured before beginning a DMA.
Suggested-by: Laura Abbott
Signed-off-by: Nathan Chancellor
---
drivers/staging/android/ion/ion.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/android/ion/ion.c
b/drivers/staging/android/ion/ion.c
index d10b60fe4a29..af682cbde767 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -315,6 +315,7 @@ static int ion_dma_buf_begin_cpu_access(struct dma_buf
*dmabuf,
struct ion_buffer *buffer = dmabuf->priv;
void *vaddr;
struct ion_dma_buf_attachment *a;
+ int ret = 0;
/*
* TODO: Move this elsewhere because we don't always need a vaddr
@@ -322,6 +323,10 @@ static int ion_dma_buf_begin_cpu_access(struct dma_buf
*dmabuf,
if (buffer->heap->ops->map_kernel) {
mutex_lock(&buffer->lock);
vaddr = ion_buffer_kmap_get(buffer);
+ if (IS_ERR(vaddr)) {
+ ret = PTR_ERR(vaddr);
+ goto unlock;
+ }
mutex_unlock(&buffer->lock);
}
@@ -330,9 +335,10 @@ static int ion_dma_buf_begin_cpu_access(struct dma_buf
*dmabuf,
dma_sync_sg_for_cpu(a->dev, a->table->sgl, a->table->nents,
direction);
}
- mutex_unlock(&buffer->lock);
- return 0;
+unlock:
+ mutex_unlock(&buffer->lock);
+ return ret;
}
static int ion_dma_buf_end_cpu_access(struct dma_buf *dmabuf,
--
2.17.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 26/26] drm/bridge: establish a link between the bridge supplier and consumer
On 2018-05-14 18:28, Daniel Vetter wrote:
> On Fri, May 11, 2018 at 09:37:47AM +0200, Peter Rosin wrote:
>> On 2018-05-10 10:10, Andrzej Hajda wrote:
>>> On 04.05.2018 15:52, Peter Rosin wrote:
If the bridge supplier is unbound, this will bring the bridge consumer
down along with the bridge. Thus, there will no longer linger any
dangling pointers from the bridge consumer (the drm_device) to some
non-existent bridge supplier.
Signed-off-by: Peter Rosin
---
drivers/gpu/drm/drm_bridge.c | 18 ++
include/drm/drm_bridge.h | 2 ++
2 files changed, 20 insertions(+)
diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
index 78d186b6831b..0259f0a3ff27 100644
--- a/drivers/gpu/drm/drm_bridge.c
+++ b/drivers/gpu/drm/drm_bridge.c
@@ -26,6 +26,7 @@
#include
#include
+#include
#include
#include "drm_crtc_internal.h"
@@ -127,12 +128,25 @@ int drm_bridge_attach(struct drm_encoder *encoder,
struct drm_bridge *bridge,
if (bridge->dev)
return -EBUSY;
+ if (encoder->dev->dev != bridge->odev) {
>>>
>>> I wonder why device_link_add does not handle this case (self dependency)
>>> silently as noop, as it seems to be a correct behavior.
>>
>> It's kind-of a silly corner-case though, so perfectly understandable
>> that it isn't handled.
>>
+ bridge->link = device_link_add(encoder->dev->dev,
+ bridge->odev, 0);
+ if (!bridge->link) {
+ dev_err(bridge->odev, "failed to link bridge to %s\n",
+ dev_name(encoder->dev->dev));
+ return -EINVAL;
+ }
+ }
+
bridge->dev = encoder->dev;
bridge->encoder = encoder;
if (bridge->funcs->attach) {
ret = bridge->funcs->attach(bridge);
if (ret < 0) {
+ if (bridge->link)
+ device_link_del(bridge->link);
+ bridge->link = NULL;
bridge->dev = NULL;
bridge->encoder = NULL;
return ret;
@@ -159,6 +173,10 @@ void drm_bridge_detach(struct drm_bridge *bridge)
if (bridge->funcs->detach)
bridge->funcs->detach(bridge);
+ if (bridge->link)
+ device_link_del(bridge->link);
+ bridge->link = NULL;
+
bridge->dev = NULL;
}
diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
index b656e505d11e..804189c63a4c 100644
--- a/include/drm/drm_bridge.h
+++ b/include/drm/drm_bridge.h
@@ -261,6 +261,7 @@ struct drm_bridge_timings {
* @list: to keep track of all added bridges
* @timings: the timing specification for the bridge, if any (may
* be NULL)
+ * @link: drm consumer <-> bridge supplier
>>>
>>> Nitpick: "<->" suggests symmetry, maybe "device link from drm consumer
>>> to the bridge" would be better.
>>
>> I meant "<->" to indicate that the link is bidirectional, not that the
>> relationship is in any way symmetric. I wasn't aware of any implication
>> of a symmetric relationship when using "<->", do you have a reference?
>> But I guess the different arrow notations in math are somewhat overloaded
>> and that someone at some point must have used "<->" to indicate a
>> symmetric relationship...
>
> Yeah I agree with Andrzej here, for me <-> implies a symmetric
> relationship. Spelling it out like Andrzej suggested sounds like the
> better idea.
> -Daniel
Ok, I guess that means I have to do a v3 after all. Or can this
trivial documentation update be done by the committer? I hate to
spam everyone with another volley...
Or perhaps I should squash patches 2-23 that are all rather similar
and mechanic? I separated them to allow for easier review from
individual driver maintainers, but that didn't seem to happen
anyway...
Cheers,
Peter
>
>>
>>> Anyway:
>>> Reviewed-by: Andrzej Hajda
>>
>> Thanks!
>>
>> Cheers,
>> Peter
>>
>>> --
>>> Regards
>>> Andrzej
>>>
* @funcs: control functions
* @driver_private: pointer to the bridge driver's internal context
*/
@@ -271,6 +272,7 @@ struct drm_bridge {
struct drm_bridge *next;
struct list_head list;
const struct drm_bridge_timings *timings;
+ struct device_link *link;
const struct drm_bridge_funcs *funcs;
void *driver_private;
>>>
>>>
>>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V1 2/5] backlight: qcom-wled: Add support for WLED4 peripheral
On 2018-05-14 22:27, Pavel Machek wrote: Hi! WLED4 peripheral is present on some PMICs like pmi8998 and pm660l. It has a different register map and also configurations are different. Add support for it. Signed-off-by: Kiran Gunda --- .../bindings/leds/backlight/qcom-wled.txt | 172 - drivers/video/backlight/qcom-wled.c| 749 +++-- 2 files changed, 696 insertions(+), 225 deletions(-) diff --git a/Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt b/Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt index fb39e32..0ceffa1 100644 --- a/Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt +++ b/Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt @@ -1,30 +1,129 @@ Binding for Qualcomm Technologies, Inc. WLED driver -Required properties: -- compatible: should be "qcom,pm8941-wled" -- reg: slave address - -Optional properties: -- default-brightness: brightness value on boot, value from: 0-4095 - default: 2048 +- compatible + Usage:required + Value type: + Definition: should be "qcom,pm8941-wled" or "qcom,pmi8998-wled". + or "qcom,pm660l-wled". + +- reg + Usage:required + Value type: + Definition: Base address of the WLED modules. I'm not sure if this change of format is good idea here... Pavel -- This format is clean and easily readable. That's why I have moved to this format. To avoid confusion, I will move out the existing properties (pm8941-wled.c) to other patch. So that it will be easy to review. To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" 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
Re: [PATCH v5 3/4] drm/panel: add Innolux TV123WAM panel driver support
On 2018-05-03 00:35, Sean Paul wrote:
On Wed, May 02, 2018 at 10:02:01AM +0530, Sandeep Panda wrote:
Add support for Innolux TV123WAM, which is a 12.3" eDP
display panel with 2160x1440 resolution.
Signed-off-by: Sandeep Panda
---
drivers/gpu/drm/panel/panel-simple.c | 27 +++
1 file changed, 27 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 234af81..52bbcfb 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1939,6 +1939,30 @@ static void panel_simple_shutdown(struct device
*dev)
.bus_format = MEDIA_BUS_FMT_RGB888_1X24,
};
+static const struct drm_display_mode innolux_tv123wam_mode = {
+ .clock = 206016,
+ .hdisplay = 2160,
+ .hsync_start = 2160 + 48,
+ .hsync_end = 2160 + 48 + 32,
+ .htotal = 2160 + 48 + 32 + 80,
+ .vdisplay = 1440,
+ .vsync_start = 1440 + 3,
+ .vsync_end = 1440 + 3 + 10,
+ .vtotal = 1440 + 3 + 10 + 27,
+ .vrefresh = 60,
+ .flags = DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC,
+};
+
+static const struct panel_desc innolux_tv123wam = {
+ .modes = &innolux_tv123wam_mode,
+ .num_modes = 1,
+ .bpc = 8,
+ .size = {
+ .width = 259,
+ .height = 173,
+ },
+};
+
static const struct of_device_id platform_of_match[] = {
{
.compatible = "ampire,am-480272h3tmqw-t01h",
@@ -2142,6 +2166,9 @@ static void panel_simple_shutdown(struct device
*dev)
.compatible = "winstar,wf35ltiacd",
.data = &winstar_wf35ltiacd,
}, {
+ .compatible = "innolux,tv123wam",
+ .data = &innolux_tv123wam,
+ }, {
These are alphabetically ordered, as are the
drm_display_mode/panel_desc
structs.
Sean
Done.
/* sentinel */
}
};
--
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 v4 1/4] drm/rockchip: add transfer function for cdn-dp
From: Chris Zhong
We may support training outside firmware, so we need support
dpcd read/write to get the message or do some setting with
display.
Signed-off-by: Chris Zhong
Signed-off-by: Lin Huang
Reviewed-by: Sean Paul
Reviewed-by: Enric Balletbo
---
Changes in v2:
- update patch following Enric suggest
Changes in v3:
- None
Changes in v4:
- None
drivers/gpu/drm/rockchip/cdn-dp-core.c | 55 +++
drivers/gpu/drm/rockchip/cdn-dp-core.h | 1 +
drivers/gpu/drm/rockchip/cdn-dp-reg.c | 69 ++
drivers/gpu/drm/rockchip/cdn-dp-reg.h | 14 ++-
4 files changed, 122 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c
b/drivers/gpu/drm/rockchip/cdn-dp-core.c
index c6fbdcd..cce64c1 100644
--- a/drivers/gpu/drm/rockchip/cdn-dp-core.c
+++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c
@@ -176,8 +176,8 @@ static int cdn_dp_get_sink_count(struct cdn_dp_device *dp,
u8 *sink_count)
u8 value;
*sink_count = 0;
- ret = cdn_dp_dpcd_read(dp, DP_SINK_COUNT, &value, 1);
- if (ret)
+ ret = drm_dp_dpcd_read(&dp->aux, DP_SINK_COUNT, &value, 1);
+ if (ret < 0)
return ret;
*sink_count = DP_GET_SINK_COUNT(value);
@@ -374,9 +374,9 @@ static int cdn_dp_get_sink_capability(struct cdn_dp_device
*dp)
if (!cdn_dp_check_sink_connection(dp))
return -ENODEV;
- ret = cdn_dp_dpcd_read(dp, DP_DPCD_REV, dp->dpcd,
- DP_RECEIVER_CAP_SIZE);
- if (ret) {
+ ret = drm_dp_dpcd_read(&dp->aux, DP_DPCD_REV, dp->dpcd,
+ sizeof(dp->dpcd));
+ if (ret < 0) {
DRM_DEV_ERROR(dp->dev, "Failed to get caps %d\n", ret);
return ret;
}
@@ -582,8 +582,8 @@ static bool cdn_dp_check_link_status(struct cdn_dp_device
*dp)
if (!port || !dp->link.rate || !dp->link.num_lanes)
return false;
- if (cdn_dp_dpcd_read(dp, DP_LANE0_1_STATUS, link_status,
-DP_LINK_STATUS_SIZE)) {
+ if (drm_dp_dpcd_read_link_status(&dp->aux, link_status) !=
+ DP_LINK_STATUS_SIZE) {
DRM_ERROR("Failed to get link status\n");
return false;
}
@@ -1012,6 +1012,40 @@ static int cdn_dp_pd_event(struct notifier_block *nb,
return NOTIFY_DONE;
}
+static ssize_t cdn_dp_aux_transfer(struct drm_dp_aux *aux,
+ struct drm_dp_aux_msg *msg)
+{
+ struct cdn_dp_device *dp = container_of(aux, struct cdn_dp_device, aux);
+ int ret;
+ u8 status;
+
+ switch (msg->request & ~DP_AUX_I2C_MOT) {
+ case DP_AUX_NATIVE_WRITE:
+ case DP_AUX_I2C_WRITE:
+ case DP_AUX_I2C_WRITE_STATUS_UPDATE:
+ ret = cdn_dp_dpcd_write(dp, msg->address, msg->buffer,
+ msg->size);
+ break;
+ case DP_AUX_NATIVE_READ:
+ case DP_AUX_I2C_READ:
+ ret = cdn_dp_dpcd_read(dp, msg->address, msg->buffer,
+ msg->size);
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ status = cdn_dp_get_aux_status(dp);
+ if (status == AUX_STATUS_ACK)
+ msg->reply = DP_AUX_NATIVE_REPLY_ACK;
+ else if (status == AUX_STATUS_NACK)
+ msg->reply = DP_AUX_NATIVE_REPLY_NACK;
+ else if (status == AUX_STATUS_DEFER)
+ msg->reply = DP_AUX_NATIVE_REPLY_DEFER;
+
+ return ret;
+}
+
static int cdn_dp_bind(struct device *dev, struct device *master, void *data)
{
struct cdn_dp_device *dp = dev_get_drvdata(dev);
@@ -1030,6 +1064,13 @@ static int cdn_dp_bind(struct device *dev, struct device
*master, void *data)
dp->active = false;
dp->active_port = -1;
dp->fw_loaded = false;
+ dp->aux.name = "DP-AUX";
+ dp->aux.transfer = cdn_dp_aux_transfer;
+ dp->aux.dev = dev;
+
+ ret = drm_dp_aux_register(&dp->aux);
+ if (ret)
+ return ret;
INIT_WORK(&dp->event_work, cdn_dp_pd_event_work);
diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.h
b/drivers/gpu/drm/rockchip/cdn-dp-core.h
index f57e296..46159b2 100644
--- a/drivers/gpu/drm/rockchip/cdn-dp-core.h
+++ b/drivers/gpu/drm/rockchip/cdn-dp-core.h
@@ -78,6 +78,7 @@ struct cdn_dp_device {
struct platform_device *audio_pdev;
struct work_struct event_work;
struct edid *edid;
+ struct drm_dp_aux aux;
struct mutex lock;
bool connected;
diff --git a/drivers/gpu/drm/rockchip/cdn-dp-reg.c
b/drivers/gpu/drm/rockchip/cdn-dp-reg.c
index eb3042c..979355d 100644
--- a/drivers/gpu/drm/rockchip/cdn-dp-reg.c
+++ b/drivers/gpu/drm/rockchip/cdn-dp-reg.c
@@ -221,7 +221,12 @@ static int cdn_dp_reg_write_bit(struct cdn_dp_device *dp,
u16 addr,
sizeof(field), field);
}
Re: [RFC PATCH 02/10] dt-bindings: devfreq: rk3399_dmc: Add rockchip,pmu phandle.
Hi, On 2018년 05월 15일 06:16, Enric Balletbo i Serra wrote: > The Rockchip DMC (Dynamic Memory Interface) needs to access to the PMU > general register files to know the DRAM type, so add a phandle to the > syscon that manages these registers. > > Signed-off-by: Enric Balletbo i Serra > --- > > Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt > b/Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt > index 0ec68141f85a..951789c0cdd6 100644 > --- a/Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt > +++ b/Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt > @@ -12,6 +12,8 @@ Required properties: >for details. > - center-supply: DMC supply node. > - status: Marks the node enabled/disabled. > +- rockchip,pmu: Phandle to the syscon managing the "PMU > general register > + files". > > Optional properties: > - interrupts: The CPU interrupt number. The interrupt > specifier > Reviewed-by: Chanwoo Choi -- Best Regards, Chanwoo Choi Samsung Electronics ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH 04/10] devfreq: rk3399_dmc / rockchip: pm_domains: Register notify to DMC driver.
From: Lin Huang
The DMC (Dynamic Memory Interface) controller does a SiP call to the
Trusted Firmware-A (TF-A) to change the DDR clock frequency. When this
happens the TF-A writes to the PMU bus idle request register
(PMU_BUS_IDLE_REQ) but at the same time it is possible that the Rockchip
power domain driver writes to the same register. So, add a notification
mechanism to ensure that the DMC and the PD driver does not access to this
register at the same time.
Signed-off-by: Lin Huang
[rewrite commit message]
Signed-off-by: Enric Balletbo i Serra
---
As I explained in the cover letter I have doubts regarding this patch
but I did not find another way to do it. So I will appreciate any
feedback on this.
drivers/devfreq/rk3399_dmc.c | 7 ++
drivers/soc/rockchip/pm_domains.c | 36 +++
include/soc/rockchip/rk3399_dmc.h | 14
3 files changed, 57 insertions(+)
create mode 100644 include/soc/rockchip/rk3399_dmc.h
diff --git a/drivers/devfreq/rk3399_dmc.c b/drivers/devfreq/rk3399_dmc.c
index cc1bbca3fb15..2c4985a501cb 100644
--- a/drivers/devfreq/rk3399_dmc.c
+++ b/drivers/devfreq/rk3399_dmc.c
@@ -28,6 +28,7 @@
#include
#include
+#include
#include
#include
@@ -443,6 +444,12 @@ static int rk3399_dmcfreq_probe(struct platform_device
*pdev)
data->dev = dev;
platform_set_drvdata(pdev, data);
+ rockchip_pm_register_dmcfreq_notifier(data->devfreq);
+ if (ret < 0) {
+ dev_err(dev, "Failed to register dmcfreq notifier\n");
+ return ret;
+ }
+
return 0;
}
diff --git a/drivers/soc/rockchip/pm_domains.c
b/drivers/soc/rockchip/pm_domains.c
index 53efc386b1ad..b0e66f24b3e3 100644
--- a/drivers/soc/rockchip/pm_domains.c
+++ b/drivers/soc/rockchip/pm_domains.c
@@ -8,6 +8,7 @@
* published by the Free Software Foundation.
*/
+#include
#include
#include
#include
@@ -76,9 +77,13 @@ struct rockchip_pmu {
const struct rockchip_pmu_info *info;
struct mutex mutex; /* mutex lock for pmu */
struct genpd_onecell_data genpd_data;
+ struct devfreq *devfreq;
+ struct notifier_block dmc_nb;
struct generic_pm_domain *domains[];
};
+static struct rockchip_pmu *dmc_pmu;
+
#define to_rockchip_pd(gpd) container_of(gpd, struct rockchip_pm_domain, genpd)
#define DOMAIN(pwr, status, req, idle, ack, wakeup)\
@@ -601,6 +606,35 @@ static int rockchip_pm_add_subdomain(struct rockchip_pmu
*pmu,
return error;
}
+static int rk3399_dmcfreq_notify(struct notifier_block *nb,
+unsigned long event, void *data)
+{
+ if (event == DEVFREQ_PRECHANGE)
+ mutex_lock(&dmc_pmu->mutex);
+ else if (event == DEVFREQ_POSTCHANGE)
+ mutex_unlock(&dmc_pmu->mutex);
+
+ return NOTIFY_OK;
+}
+
+int rockchip_pm_register_dmcfreq_notifier(struct devfreq *devfreq)
+{
+ int ret;
+
+ if (!dmc_pmu)
+ return -EPROBE_DEFER;
+
+ dmc_pmu->devfreq = devfreq;
+ dmc_pmu->dmc_nb.notifier_call = rk3399_dmcfreq_notify;
+ ret = devm_devfreq_register_notifier(devfreq->dev.parent,
+dmc_pmu->devfreq,
+&dmc_pmu->dmc_nb,
+DEVFREQ_TRANSITION_NOTIFIER);
+
+ return ret;
+}
+EXPORT_SYMBOL(rockchip_pm_register_dmcfreq_notifier);
+
static int rockchip_pm_domain_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
@@ -694,6 +728,8 @@ static int rockchip_pm_domain_probe(struct platform_device
*pdev)
goto err_out;
}
+ dmc_pmu = pmu;
+
return 0;
err_out:
diff --git a/include/soc/rockchip/rk3399_dmc.h
b/include/soc/rockchip/rk3399_dmc.h
new file mode 100644
index ..031a62607f61
--- /dev/null
+++ b/include/soc/rockchip/rk3399_dmc.h
@@ -0,0 +1,14 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (c) 2016-2018, Fuzhou Rockchip Electronics Co., Ltd
+ * Author: Lin Huang
+ */
+
+#ifndef __SOC_RK3399_DMC_H
+#define __SOC_RK3399_DMC_H
+
+#include
+
+int rockchip_pm_register_dmcfreq_notifier(struct devfreq *devfreq);
+
+#endif
--
2.17.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH 09/10] arm64: dts: rk3399: Add dfi and dmc nodes.
From: Lin Huang
These are required to support DDR DVFS on rk3399 platform. The patch also
introduces two new files (rk3399-dram.h and rk3399-dram-default-timing)
with default DRAM settings.
Signed-off-by: Lin Huang
Signed-off-by: Enric Balletbo i Serra
---
.../rockchip/rk3399-dram-default-timing.dtsi | 38 ++
arch/arm64/boot/dts/rockchip/rk3399-dram.h| 73 +++
.../boot/dts/rockchip/rk3399-op1-opp.dtsi | 29
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 20 +
4 files changed, 160 insertions(+)
create mode 100644 arch/arm64/boot/dts/rockchip/rk3399-dram-default-timing.dtsi
create mode 100644 arch/arm64/boot/dts/rockchip/rk3399-dram.h
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-dram-default-timing.dtsi
b/arch/arm64/boot/dts/rockchip/rk3399-dram-default-timing.dtsi
new file mode 100644
index ..4dfe3e1d8bdf
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3399-dram-default-timing.dtsi
@@ -0,0 +1,38 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR X11)
+/*
+ * Copyright (c) 2016-2018, Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * Author: Lin Huang
+ */
+
+#include "rk3399-dram.h"
+
+rockchip,ddr3_speed_bin = <21>;
+rockchip,pd_idle = <0x40>;
+rockchip,sr_idle = <0x2>;
+rockchip,sr_mc_gate_idle = <0x3>;
+rockchip,srpd_lite_idle= <0x4>;
+rockchip,standby_idle = <0x2000>;
+rockchip,dram_dll_dis_freq = <3>;
+rockchip,phy_dll_dis_freq = <12500>;
+rockchip,auto_pd_dis_freq = <66600>;
+rockchip,ddr3_odt_dis_freq = <33300>;
+rockchip,ddr3_drv = ;
+rockchip,ddr3_odt = ;
+rockchip,phy_ddr3_ca_drv = ;
+rockchip,phy_ddr3_dq_drv = ;
+rockchip,phy_ddr3_odt = ;
+rockchip,lpddr3_odt_dis_freq = <33300>;
+rockchip,lpddr3_drv = ;
+rockchip,lpddr3_odt = ;
+rockchip,phy_lpddr3_ca_drv = ;
+rockchip,phy_lpddr3_dq_drv = ;
+rockchip,phy_lpddr3_odt = ;
+rockchip,lpddr4_odt_dis_freq = <33300>;
+rockchip,lpddr4_drv = ;
+rockchip,lpddr4_dq_odt = ;
+rockchip,lpddr4_ca_odt = ;
+rockchip,phy_lpddr4_ca_drv = ;
+rockchip,phy_lpddr4_ck_cs_drv = ;
+rockchip,phy_lpddr4_dq_drv = ;
+rockchip,phy_lpddr4_odt = ;
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-dram.h
b/arch/arm64/boot/dts/rockchip/rk3399-dram.h
new file mode 100644
index ..4b3d4a79923b
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3399-dram.h
@@ -0,0 +1,73 @@
+/* SPDX-License-Identifier: (GPL-2.0+ OR X11) */
+/*
+ * Copyright (c) 2016-2018, Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * Author: Lin Huang
+ */
+
+#ifndef _DTS_DRAM_ROCKCHIP_RK3399_H
+#define _DTS_DRAM_ROCKCHIP_RK3399_H
+
+#define DDR3_DS_34ohm 34
+#define DDR3_DS_40ohm 40
+
+#define DDR3_ODT_DIS 0
+#define DDR3_ODT_40ohm 40
+#define DDR3_ODT_60ohm 60
+#define DDR3_ODT_120ohm120
+
+#define LP2_DS_34ohm 34
+#define LP2_DS_40ohm 40
+#define LP2_DS_48ohm 48
+#define LP2_DS_60ohm 60
+#define LP2_DS_68_6ohm 68 /* optional */
+#define LP2_DS_80ohm 80
+#define LP2_DS_120ohm 120 /* optional */
+
+#define LP3_DS_34ohm 34
+#define LP3_DS_40ohm 40
+#define LP3_DS_48ohm 48
+#define LP3_DS_60ohm 60
+#define LP3_DS_80ohm 80
+#define LP3_DS_34D_40U 3440
+#define LP3_DS_40D_48U 4048
+#define LP3_DS_34D_48U 3448
+
+#define LP3_ODT_DIS0
+#define LP3_ODT_60ohm 60
+#define LP3_ODT_120ohm 120
+#define LP3_ODT_240ohm 240
+
+#define LP4_PDDS_40ohm 40
+#define LP4_PDDS_48ohm 48
+#define LP4_PDDS_60ohm 60
+#define LP4_PDDS_80ohm 80
+#define LP4_PDDS_120ohm120
+#define LP4_PDDS_240ohm240
+
+#define LP4_DQ_ODT_40ohm 40
+#define LP4_DQ_ODT_48ohm 48
+#define LP4_DQ_ODT_60ohm 60
+#define LP4_DQ_ODT_80ohm 80
+#define LP4_DQ_ODT_120ohm 120
+#define LP4_DQ_ODT_240ohm 240
+#define LP4_DQ_ODT_DIS 0
+
+#define LP4_CA_ODT_40ohm 40
+#define LP4_CA_ODT_48ohm 48
+#define LP4_CA_ODT_60ohm 60
+#define LP4_CA_ODT_80ohm 80
+#define LP4_CA_ODT_120ohm 120
+#define LP4_CA_ODT_240ohm 240
+#define LP4_CA_ODT_DIS 0
+
+#define PHY_DRV_ODT_Hi_Z 0
+#define PHY_DRV_ODT_240240
+#define PHY_DRV_ODT_120120
+#define PHY_DRV_ODT_80 80
+#define PHY_DRV_ODT_60 60
+#define PHY_DRV_ODT_48 48
+#define PHY_DRV_ODT_40 40
+#define PHY_DRV_ODT_34_3 34
+
+#endif /* _DTS_DRAM_ROCKCHIP_RK3399_H */
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-op1-opp.dtsi
b/arch/arm64/boot/dts/rockchip/rk3399-op1-opp.dtsi
index d8a120f945c8..4c634e58425d 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-op1-opp.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-op1-opp.dtsi
@@ -147,6 +147,31 @@
opp-microvolt = <1075000>;
};
};
+
+ dmc_opp_table: dmc_opp_table {
+
[PATCH v3 4/4] drm/rockchip: support dp training outside dp firmware
DP firmware uses fixed phy config values to do training, but some
boards need to adjust these values to fit for their unique hardware
design. So if the phy is using custom config values, do software
link training instead of relying on firmware, if software training
fail, keep firmware training as a fallback if sw training fails.
Signed-off-by: Chris Zhong
Signed-off-by: Lin Huang
---
Changes in v2:
- update patch following Enric suggest
Changes in v3:
- use variable fw_training instead sw_training_success
- base on DP SPCE, if training fail use lower link rate to retry training
drivers/gpu/drm/rockchip/Makefile | 3 +-
drivers/gpu/drm/rockchip/cdn-dp-core.c | 24 +-
drivers/gpu/drm/rockchip/cdn-dp-core.h | 2 +
drivers/gpu/drm/rockchip/cdn-dp-link-training.c | 416
drivers/gpu/drm/rockchip/cdn-dp-reg.c | 31 +-
drivers/gpu/drm/rockchip/cdn-dp-reg.h | 38 ++-
6 files changed, 501 insertions(+), 13 deletions(-)
create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-link-training.c
diff --git a/drivers/gpu/drm/rockchip/Makefile
b/drivers/gpu/drm/rockchip/Makefile
index a314e21..b932f62 100644
--- a/drivers/gpu/drm/rockchip/Makefile
+++ b/drivers/gpu/drm/rockchip/Makefile
@@ -9,7 +9,8 @@ rockchipdrm-y := rockchip_drm_drv.o rockchip_drm_fb.o \
rockchipdrm-$(CONFIG_DRM_FBDEV_EMULATION) += rockchip_drm_fbdev.o
rockchipdrm-$(CONFIG_ROCKCHIP_ANALOGIX_DP) += analogix_dp-rockchip.o
-rockchipdrm-$(CONFIG_ROCKCHIP_CDN_DP) += cdn-dp-core.o cdn-dp-reg.o
+rockchipdrm-$(CONFIG_ROCKCHIP_CDN_DP) += cdn-dp-core.o cdn-dp-reg.o \
+ cdn-dp-link-training.o
rockchipdrm-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o
rockchipdrm-$(CONFIG_ROCKCHIP_DW_MIPI_DSI) += dw-mipi-dsi.o
rockchipdrm-$(CONFIG_ROCKCHIP_INNO_HDMI) += inno_hdmi.o
diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c
b/drivers/gpu/drm/rockchip/cdn-dp-core.c
index cce64c1..d9d0d4d 100644
--- a/drivers/gpu/drm/rockchip/cdn-dp-core.c
+++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c
@@ -629,11 +629,13 @@ static void cdn_dp_encoder_enable(struct drm_encoder
*encoder)
goto out;
}
}
-
- ret = cdn_dp_set_video_status(dp, CONTROL_VIDEO_IDLE);
- if (ret) {
- DRM_DEV_ERROR(dp->dev, "Failed to idle video %d\n", ret);
- goto out;
+ if (dp->use_fw_training == true) {
+ ret = cdn_dp_set_video_status(dp, CONTROL_VIDEO_IDLE);
+ if (ret) {
+ DRM_DEV_ERROR(dp->dev,
+ "Failed to idle video %d\n", ret);
+ goto out;
+ }
}
ret = cdn_dp_config_video(dp);
@@ -642,11 +644,15 @@ static void cdn_dp_encoder_enable(struct drm_encoder
*encoder)
goto out;
}
- ret = cdn_dp_set_video_status(dp, CONTROL_VIDEO_VALID);
- if (ret) {
- DRM_DEV_ERROR(dp->dev, "Failed to valid video %d\n", ret);
- goto out;
+ if (dp->use_fw_training == true) {
+ ret = cdn_dp_set_video_status(dp, CONTROL_VIDEO_VALID);
+ if (ret) {
+ DRM_DEV_ERROR(dp->dev,
+ "Failed to valid video %d\n", ret);
+ goto out;
+ }
}
+
out:
mutex_unlock(&dp->lock);
}
diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.h
b/drivers/gpu/drm/rockchip/cdn-dp-core.h
index 46159b2..77a9793 100644
--- a/drivers/gpu/drm/rockchip/cdn-dp-core.h
+++ b/drivers/gpu/drm/rockchip/cdn-dp-core.h
@@ -84,6 +84,7 @@ struct cdn_dp_device {
bool connected;
bool active;
bool suspended;
+ bool use_fw_training;
const struct firmware *fw; /* cdn dp firmware */
unsigned int fw_version;/* cdn fw version */
@@ -106,6 +107,7 @@ struct cdn_dp_device {
u8 ports;
u8 lanes;
int active_port;
+ u8 train_set[4];
u8 dpcd[DP_RECEIVER_CAP_SIZE];
bool sink_has_audio;
diff --git a/drivers/gpu/drm/rockchip/cdn-dp-link-training.c
b/drivers/gpu/drm/rockchip/cdn-dp-link-training.c
new file mode 100644
index 000..b8fd5bc
--- /dev/null
+++ b/drivers/gpu/drm/rockchip/cdn-dp-link-training.c
@@ -0,0 +1,416 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) Fuzhou Rockchip Electronics Co.Ltd
+ * Author: Chris Zhong
+ */
+
+#include
+#include
+#include
+#include
+
+#include "cdn-dp-core.h"
+#include "cdn-dp-reg.h"
+
+static void cdn_dp_set_signal_levels(struct cdn_dp_device *dp)
+{
+ struct cdn_dp_port *port = dp->port[dp->active_port];
+ struct rockchip_typec_phy *tcphy = phy_get_drvdata(port->phy);
+
+ int rate = drm_dp_bw_code_to_link_rate(dp->link.rate);
+ u8 swing = (dp->train_set[0] & DP_TRAIN_VOLTAGE_SWING_MASK) >>
+ DP_TRAIN_VOLTAGE_SWING_SHIFT;
+ u8 pre_emph
[PATCH v6 4/4] dt-bindings: drm/panel: Document Innolux TV123WAM panel bindings
Innolux TV123WAM is a 12.3" eDP display panel with
2160x1440 resolution, which can be supported by simple
panel driver.
Changes in v1:
- Make use of simple panel driver instead of creating
a new driver for this panel (Sean Paul).
- Combine dt-binding and driver changes into one patch
as done by other existing panel support changes.
Changes in v2:
- Separate driver change from dt-binding documentation (Rob Herring).
- Add the properties from simple-panel binding that are applicable to
this panel (Rob Herring).
Signed-off-by: Sandeep Panda
Reviewed-by: Rob Herring
---
.../bindings/display/panel/innolux,tv123wam.txt | 20
1 file changed, 20 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/innolux,tv123wam.txt
diff --git
a/Documentation/devicetree/bindings/display/panel/innolux,tv123wam.txt
b/Documentation/devicetree/bindings/display/panel/innolux,tv123wam.txt
new file mode 100644
index 000..a9b3526
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/innolux,tv123wam.txt
@@ -0,0 +1,20 @@
+Innolux TV123WAM 12.3 inch eDP 2K display panel
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
+
+Required properties:
+- compatible: should be "innolux,tv123wam"
+- power-supply: regulator to provide the supply voltage
+
+Optional properties:
+- enable-gpios: GPIO pin to enable or disable the panel
+- backlight: phandle of the backlight device attached to the panel
+
+Example:
+ panel_edp: panel-edp {
+ compatible = "innolux,tv123wam";
+ enable-gpios = <&msmgpio 31 GPIO_ACTIVE_LOW>;
+ power-supply = <&pm8916_l2>;
+ 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
[PATCH v6 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. Changes in v1: - Split the dt-bindings and the driver support into separate patches (Andrzej Hajda). - Use of gpiod APIs to parse and configure gpios instead of obsolete ones (Andrzej Hajda). - Use macros to define the register offsets (Andrzej Hajda). Changes in v2: - Separate out edp panel specific HW resource handling from bridge driver and create a separate edp panel drivers to handle panel specific mode information and HW resources (Sean Paul). - Replace pr_* APIs to DRM_* APIs to log error or debug information (Sean Paul). - Remove some of the unnecessary structure/variable from driver (Sean Paul). - Rename the function and structure prefix "sn65dsi86" to "ti_sn_bridge" (Sean Paul / Rob Herring). - Remove most of the hard-coding and modified the bridge init sequence based on current mode (Sean Paul). - Remove the existing function to retrieve the EDID data and implemented this as an i2c_adapter and use drm_get_edid() (Sean Paul). - Remove the dummy irq handler implementation, will add back the proper irq handling later (Sean Paul). - Capture the required enable gpios in a single array based on dt entry instead of having individual descriptor for each gpio (Sean Paul). Changes in v3: - Remove usage of irq_gpio and replace it as "interrupts" property (Rob Herring). - Remove the unnecessary header file inclusions (Sean Paul). - Rearrange the header files in alphabetical order (Sean Paul). - Use regmap interface to perform i2c transactions. - Update Copyright/License field and address other review comments (Jordan Crouse). Changes in v4: - Update License/Copyright (Sean Paul). - Add Kconfig and Makefile changes (Sean Paul). - Drop i2c gpio handling from this bridge driver, since i2c sda/scl gpios will be handled by i2c master. - Update required supplies names. - Remove unnecessary goto statements (Sean Paul). - Add mutex lock to power_ctrl API to avoid race conditions (Sean Paul). - Add support to parse reference clk frequency from dt(optional). - Update the bridge chip enable/disable sequence. Changes in v5: - Fixed Kbuild test service reported warnings. Changes in v6: - Use PM runtime based ref-counting instead of local ref_count mechanism (Stephen Boyd). - Clean up some debug logs and indentations (Sean Paul). - Simplify dp rate calculation (Sean Paul). - Add support to configure refclk based on input REFCLK pin or DACP/N pin (Stephen Boyd). Signed-off-by: Sandeep Panda --- drivers/gpu/drm/bridge/Kconfig| 9 + drivers/gpu/drm/bridge/Makefile | 1 + drivers/gpu/drm/bridge/ti-sn65dsi86.c | 766 ++ 3 files changed, 776 insertions(+) create mode 100644 drivers/gpu/drm/bridge/ti-sn65dsi86.c diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig index 3b99d5a..8153150 100644 --- a/drivers/gpu/drm/bridge/Kconfig +++ b/drivers/gpu/drm/bridge/Kconfig @@ -108,6 +108,15 @@ config DRM_TI_TFP410 ---help--- Texas Instruments TFP410 DVI/HDMI Transmitter driver +config DRM_TI_SN65DSI86 + tristate "TI SN65DSI86 DSI to eDP bridge" + depends on OF + select DRM_KMS_HELPER + select REGMAP_I2C + select DRM_PANEL + ---help--- + Texas Instruments SN65DSI86 DSI to eDP Bridge driver + source "drivers/gpu/drm/bridge/analogix/Kconfig" source "drivers/gpu/drm/bridge/adv7511/Kconfig" diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile index 373eb28..3711be8 100644 --- a/drivers/gpu/drm/bridge/Makefile +++ b/drivers/gpu/drm/bridge/Makefile @@ -12,4 +12,5 @@ obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/ obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/ obj-$(CONFIG_DRM_TI_TFP410) += ti-tfp410.o +obj-$(CONFIG_DRM_TI_SN65DSI86) += ti-sn65dsi86.o obj-y += synopsys/ diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c b/drivers/gpu/drm/bridge/ti-sn65dsi86.c new file mode 100644 index 000..1d3e549 --- /dev/null +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c @@ -0,0 +1,766 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Copyright (c) 2018, The Linux Foundation. All rights reserved. + */ + +#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_HPD_DISABLE_REG 0x5C +#define SN_REFCLK_FREQ_REG
[PATCH v3 2/4] Documentation: bindings: add phy_config for Rockchip USB Type-C PHY
If want to do training outside DP Firmware, need phy voltage swing
and pre_emphasis value.
Signed-off-by: Lin Huang
---
Changes in v2:
- rebase
Changes in v3:
- modify property description and add this property to example
.../devicetree/bindings/phy/phy-rockchip-typec.txt | 29 +-
1 file changed, 28 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/phy/phy-rockchip-typec.txt
b/Documentation/devicetree/bindings/phy/phy-rockchip-typec.txt
index 960da7f..af298f2 100644
--- a/Documentation/devicetree/bindings/phy/phy-rockchip-typec.txt
+++ b/Documentation/devicetree/bindings/phy/phy-rockchip-typec.txt
@@ -17,7 +17,8 @@ Required properties:
Optional properties:
- extcon : extcon specifier for the Power Delivery
-
+ - rockchip,phy_config : A list of voltage swing(mv) and pre-emphasis
+ (dB) pairs.
Required nodes : a sub-node is required for each port the phy provides.
The sub-node name is used to identify dp or usb3 port,
and shall be the following entries:
@@ -50,6 +51,19 @@ Example:
<&cru SRST_P_UPHY0_TCPHY>;
reset-names = "uphy", "uphy-pipe", "uphy-tcphy";
+ rockchip,phy_config =<0x2a 0x00
+ 0x1f 0x15
+ 0x14 0x22
+ 0x02 0x2b
+ 0x21 0x00
+ 0x12 0x15
+ 0x02 0x22
+ 0 0
+ 0x15 0x00
+ 0x00 0x15
+ 0 0
+ 0 0>;
+
tcphy0_dp: dp-port {
#phy-cells = <0>;
};
@@ -74,6 +88,19 @@ Example:
<&cru SRST_P_UPHY1_TCPHY>;
reset-names = "uphy", "uphy-pipe", "uphy-tcphy";
+ rockchip,phy_config =<0x2a 0x00
+ 0x1f 0x15
+ 0x14 0x22
+ 0x02 0x2b
+ 0x21 0x00
+ 0x12 0x15
+ 0x02 0x22
+ 0 0
+ 0x15 0x00
+ 0x00 0x15
+ 0 0
+ 0 0>;
+
tcphy1_dp: dp-port {
#phy-cells = <0>;
};
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 4/4] drm/rockchip: support dp training outside dp firmware
DP firmware uses fixed phy config values to do training, but some
boards need to adjust these values to fit for their unique hardware
design. So get phy config values from dts and use software link training
instead of relying on firmware, if software training fail, keep firmware
training as a fallback if sw training fails.
Signed-off-by: Chris Zhong
Signed-off-by: Lin Huang
---
Changes in v2:
- update patch following Enric suggest
Changes in v3:
- use variable fw_training instead sw_training_success
- base on DP SPCE, if training fail use lower link rate to retry training
Changes in v4:
- improve cdn_dp_get_lower_link_rate() and cdn_dp_software_train_link() follow
Sean suggest
drivers/gpu/drm/rockchip/Makefile | 3 +-
drivers/gpu/drm/rockchip/cdn-dp-core.c | 24 +-
drivers/gpu/drm/rockchip/cdn-dp-core.h | 2 +
drivers/gpu/drm/rockchip/cdn-dp-link-training.c | 420
drivers/gpu/drm/rockchip/cdn-dp-reg.c | 31 +-
drivers/gpu/drm/rockchip/cdn-dp-reg.h | 38 ++-
6 files changed, 505 insertions(+), 13 deletions(-)
create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-link-training.c
diff --git a/drivers/gpu/drm/rockchip/Makefile
b/drivers/gpu/drm/rockchip/Makefile
index a314e21..b932f62 100644
--- a/drivers/gpu/drm/rockchip/Makefile
+++ b/drivers/gpu/drm/rockchip/Makefile
@@ -9,7 +9,8 @@ rockchipdrm-y := rockchip_drm_drv.o rockchip_drm_fb.o \
rockchipdrm-$(CONFIG_DRM_FBDEV_EMULATION) += rockchip_drm_fbdev.o
rockchipdrm-$(CONFIG_ROCKCHIP_ANALOGIX_DP) += analogix_dp-rockchip.o
-rockchipdrm-$(CONFIG_ROCKCHIP_CDN_DP) += cdn-dp-core.o cdn-dp-reg.o
+rockchipdrm-$(CONFIG_ROCKCHIP_CDN_DP) += cdn-dp-core.o cdn-dp-reg.o \
+ cdn-dp-link-training.o
rockchipdrm-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o
rockchipdrm-$(CONFIG_ROCKCHIP_DW_MIPI_DSI) += dw-mipi-dsi.o
rockchipdrm-$(CONFIG_ROCKCHIP_INNO_HDMI) += inno_hdmi.o
diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c
b/drivers/gpu/drm/rockchip/cdn-dp-core.c
index cce64c1..d9d0d4d 100644
--- a/drivers/gpu/drm/rockchip/cdn-dp-core.c
+++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c
@@ -629,11 +629,13 @@ static void cdn_dp_encoder_enable(struct drm_encoder
*encoder)
goto out;
}
}
-
- ret = cdn_dp_set_video_status(dp, CONTROL_VIDEO_IDLE);
- if (ret) {
- DRM_DEV_ERROR(dp->dev, "Failed to idle video %d\n", ret);
- goto out;
+ if (dp->use_fw_training == true) {
+ ret = cdn_dp_set_video_status(dp, CONTROL_VIDEO_IDLE);
+ if (ret) {
+ DRM_DEV_ERROR(dp->dev,
+ "Failed to idle video %d\n", ret);
+ goto out;
+ }
}
ret = cdn_dp_config_video(dp);
@@ -642,11 +644,15 @@ static void cdn_dp_encoder_enable(struct drm_encoder
*encoder)
goto out;
}
- ret = cdn_dp_set_video_status(dp, CONTROL_VIDEO_VALID);
- if (ret) {
- DRM_DEV_ERROR(dp->dev, "Failed to valid video %d\n", ret);
- goto out;
+ if (dp->use_fw_training == true) {
+ ret = cdn_dp_set_video_status(dp, CONTROL_VIDEO_VALID);
+ if (ret) {
+ DRM_DEV_ERROR(dp->dev,
+ "Failed to valid video %d\n", ret);
+ goto out;
+ }
}
+
out:
mutex_unlock(&dp->lock);
}
diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.h
b/drivers/gpu/drm/rockchip/cdn-dp-core.h
index 46159b2..77a9793 100644
--- a/drivers/gpu/drm/rockchip/cdn-dp-core.h
+++ b/drivers/gpu/drm/rockchip/cdn-dp-core.h
@@ -84,6 +84,7 @@ struct cdn_dp_device {
bool connected;
bool active;
bool suspended;
+ bool use_fw_training;
const struct firmware *fw; /* cdn dp firmware */
unsigned int fw_version;/* cdn fw version */
@@ -106,6 +107,7 @@ struct cdn_dp_device {
u8 ports;
u8 lanes;
int active_port;
+ u8 train_set[4];
u8 dpcd[DP_RECEIVER_CAP_SIZE];
bool sink_has_audio;
diff --git a/drivers/gpu/drm/rockchip/cdn-dp-link-training.c
b/drivers/gpu/drm/rockchip/cdn-dp-link-training.c
new file mode 100644
index 000..7efd070
--- /dev/null
+++ b/drivers/gpu/drm/rockchip/cdn-dp-link-training.c
@@ -0,0 +1,420 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) Fuzhou Rockchip Electronics Co.Ltd
+ * Author: Chris Zhong
+ */
+
+#include
+#include
+#include
+#include
+
+#include "cdn-dp-core.h"
+#include "cdn-dp-reg.h"
+
+static void cdn_dp_set_signal_levels(struct cdn_dp_device *dp)
+{
+ struct cdn_dp_port *port = dp->port[dp->active_port];
+ struct rockchip_typec_phy *tcphy = phy_get_drvdata(port->phy);
+
+ int rate = drm_dp_bw_code_to_link_rate(dp->link.rate);
+ u8 swing = (dp->train_set[0]
[RFC PATCH 07/10] clk: rockchip: set clk-ddr to GET_RATE_NOCACHE.
From: Derek Basehore
This adds the flag to the clk-ddr in rockchip to not use the cached
rate for get_rate. This is to handle timeout error conditions in SMC
for the set rate function.
Signed-off-by: Derek Basehore
Signed-off-by: Enric Balletbo i Serra
---
drivers/clk/rockchip/clk-ddr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/rockchip/clk-ddr.c b/drivers/clk/rockchip/clk-ddr.c
index de00590af167..dffd5ac5847b 100644
--- a/drivers/clk/rockchip/clk-ddr.c
+++ b/drivers/clk/rockchip/clk-ddr.c
@@ -226,7 +226,7 @@ struct clk *rockchip_clk_register_ddrclk(const char *name,
int flags,
init.num_parents = num_parents;
init.flags = flags;
- init.flags |= CLK_SET_RATE_NO_REPARENT;
+ init.flags |= CLK_SET_RATE_NO_REPARENT | CLK_GET_RATE_NOCACHE;
switch (ddr_flag) {
case ROCKCHIP_DDRCLK_SIP:
--
2.17.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH 06/10] devfreq: rk3399_dmc / clk: rockchip: Disable DDR clk timeout on suspend.
From: Derek Basehore
This disables the timeout for the DDR clk when the governor is
suspended or stopped. This makes sure that the suspend frequency is
set. It also makes sure that the userspace governor will be able to
change the frequency without failing.
Signed-off-by: Derek Basehore
Signed-off-by: Enric Balletbo i Serra
---
drivers/clk/rockchip/clk-ddr.c| 21 ++---
drivers/devfreq/rk3399_dmc.c | 20 +++-
drivers/devfreq/rk3399_dmc_priv.h | 1 +
3 files changed, 34 insertions(+), 8 deletions(-)
diff --git a/drivers/clk/rockchip/clk-ddr.c b/drivers/clk/rockchip/clk-ddr.c
index 707be1bd8910..de00590af167 100644
--- a/drivers/clk/rockchip/clk-ddr.c
+++ b/drivers/clk/rockchip/clk-ddr.c
@@ -32,6 +32,7 @@ struct rockchip_ddrclk {
int div_shift;
int div_width;
int ddr_flag;
+ booltimeout_en;
unsigned long cached_rate;
struct work_struct set_rate_work;
struct mutexlock;
@@ -52,8 +53,9 @@ static void rockchip_ddrclk_set_rate_func(struct work_struct
*work)
mutex_lock(&ddrclk->lock);
for (i = 0; i < DDRCLK_SET_RATE_MAX_RETRIES; i++) {
- ret = raw_notifier_call_chain(&ddrclk->sync_chain, 0, &timeout);
- if (ret == NOTIFY_BAD)
+ ret = raw_notifier_call_chain(&ddrclk->sync_chain, 0,
+ &timeout);
+ if (ddrclk->timeout_en && ret == NOTIFY_BAD)
goto out;
/*
@@ -63,7 +65,8 @@ static void rockchip_ddrclk_set_rate_func(struct work_struct
*work)
* at the wrong time.
*/
local_irq_disable();
- if (ktime_after(ktime_add_ns(ktime_get(), DMC_MIN_VBLANK_NS),
+ if (ddrclk->timeout_en &&
+ ktime_after(ktime_add_ns(ktime_get(), DMC_MIN_VBLANK_NS),
timeout)) {
local_irq_enable();
continue;
@@ -79,6 +82,17 @@ static void rockchip_ddrclk_set_rate_func(struct work_struct
*work)
mutex_unlock(&ddrclk->lock);
}
+void rockchip_ddrclk_set_timeout_en(struct clk *clk, bool enable)
+{
+ struct clk_hw *hw = __clk_get_hw(clk);
+ struct rockchip_ddrclk *ddrclk = to_rockchip_ddrclk_hw(hw);
+
+ mutex_lock(&ddrclk->lock);
+ ddrclk->timeout_en = enable;
+ mutex_unlock(&ddrclk->lock);
+}
+EXPORT_SYMBOL(rockchip_ddrclk_set_timeout_en);
+
int rockchip_ddrclk_register_sync_nb(struct clk *clk, struct notifier_block
*nb)
{
struct clk_hw *hw = __clk_get_hw(clk);
@@ -232,6 +246,7 @@ struct clk *rockchip_clk_register_ddrclk(const char *name,
int flags,
ddrclk->div_shift = div_shift;
ddrclk->div_width = div_width;
ddrclk->ddr_flag = ddr_flag;
+ ddrclk->timeout_en = true;
mutex_init(&ddrclk->lock);
INIT_WORK(&ddrclk->set_rate_work, rockchip_ddrclk_set_rate_func);
RAW_INIT_NOTIFIER_HEAD(&ddrclk->sync_chain);
diff --git a/drivers/devfreq/rk3399_dmc.c b/drivers/devfreq/rk3399_dmc.c
index c174d13afe92..2fa4ab653c35 100644
--- a/drivers/devfreq/rk3399_dmc.c
+++ b/drivers/devfreq/rk3399_dmc.c
@@ -308,14 +308,18 @@ int rockchip_dmcfreq_register_clk_sync_nb(struct devfreq
*devfreq,
* one notifier is not generally possible. Thus, if more than one sync
* notifier is registered, disable dmcfreq.
*/
- if (dmcfreq->num_sync_nb == 1 && dmcfreq->disable_count <= 0)
+ if (dmcfreq->num_sync_nb == 1 && dmcfreq->disable_count <= 0) {
+ rockchip_ddrclk_set_timeout_en(dmcfreq->dmc_clk, false);
devfreq_suspend_device(devfreq);
+ }
ret = rockchip_ddrclk_register_sync_nb(dmcfreq->dmc_clk, nb);
if (ret == 0)
dmcfreq->num_sync_nb++;
- else if (dmcfreq->num_sync_nb == 1 && dmcfreq->disable_count <= 0)
+ else if (dmcfreq->num_sync_nb == 1 && dmcfreq->disable_count <= 0) {
+ rockchip_ddrclk_set_timeout_en(dmcfreq->dmc_clk, true);
devfreq_resume_device(devfreq);
+ }
mutex_unlock(&dmcfreq->en_lock);
return ret;
@@ -332,8 +336,10 @@ int rockchip_dmcfreq_unregister_clk_sync_nb(struct devfreq
*devfreq,
ret = rockchip_ddrclk_unregister_sync_nb(dmcfreq->dmc_clk, nb);
if (ret == 0) {
dmcfreq->num_sync_nb--;
- if (dmcfreq->num_sync_nb == 1 && dmcfreq->disable_count <= 0)
+ if (dmcfreq->num_sync_nb == 1 && dmcfreq->disable_count <= 0) {
+ rockchip_ddrclk_set_timeout_en(dmcfreq->dmc_clk, true);
devfreq_resume_device(devfreq);
+ }
}
mutex_unlock(&dmcfreq->en_lock);
@@ -348,8 +354,10 @@ int rockchip_dmcfreq_block(struct devfreq *devfreq)
int ret = 0;
mutex_lock(&dmcfreq->en_lock);
-
[PATCH v6 0/4] Add suppport for sn65dsi86 bridge chip and Innolux 2k edp panel
Changes in current patchset: - Use PM runtime based ref-counting instead of local ref_count mechanism. - Simplify dp rate calculation. - Add support to configure refclk based on input REFCLK pin or DACP/N pin. - Add compatibility string and display_mode structure to simple panel driver in alphabetical order. Sandeep Panda (4): drm/bridge: add support for sn65dsi86 bridge driver dt-bindings: drm/bridge: Document sn65dsi86 bridge bindings drm/panel: add Innolux TV123WAM panel driver support dt-bindings: drm/panel: Document Innolux TV123WAM panel bindings .../bindings/display/bridge/ti,sn65dsi86.txt | 81 +++ .../bindings/display/panel/innolux,tv123wam.txt| 20 + drivers/gpu/drm/bridge/Kconfig | 9 + drivers/gpu/drm/bridge/Makefile| 1 + drivers/gpu/drm/bridge/ti-sn65dsi86.c | 766 + drivers/gpu/drm/panel/panel-simple.c | 27 + 6 files changed, 904 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt create mode 100644 Documentation/devicetree/bindings/display/panel/innolux,tv123wam.txt create mode 100644 drivers/gpu/drm/bridge/ti-sn65dsi86.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
[RFC PATCH 10/10] arm64: dts: rockchip: Enable dmc and dfi nodes on gru.
From: Lin Huang
Enable the DMC (Dynamic Memory Controller) and the DFI (DDR PHY Interface)
nodes on gru/kevin boards so we can support DDR DVFS.
Signed-off-by: Lin Huang
Signed-off-by: Enric Balletbo i Serra
---
arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi | 21
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 2 +-
2 files changed, 22 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
b/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
index 18f546f2dfd1..ba2cfdd082b8 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
@@ -525,6 +525,12 @@
extcon = <&usbc_extcon0>, <&usbc_extcon1>;
};
+&dmc_opp_table {
+ opp04 {
+ opp-suspend;
+ };
+};
+
/*
* Set some suspend operating points to avoid OVP in suspend
*
@@ -600,6 +606,10 @@
<4>;
};
+&display_subsystem {
+ devfreq = <&dmc>;
+};
+
&emmc_phy {
status = "okay";
};
@@ -766,6 +776,17 @@ ap_i2c_audio: &i2c8 {
status = "okay";
};
+&dfi {
+ status = "okay";
+};
+
+&dmc {
+ status = "okay";
+ center-supply = <&ppvar_centerlogic>;
+ upthreshold = <25>;
+ downdifferential = <15>;
+};
+
&sdhci {
/*
* Signal integrity isn't great at 200 MHz and 150 MHz (DDR) gives the
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index e012cc8ae3d4..518c742293fc 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -160,7 +160,7 @@
};
};
- display-subsystem {
+ display_subsystem: display-subsystem {
compatible = "rockchip,display-subsystem";
ports = <&vopl_out>, <&vopb_out>;
};
--
2.17.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] gpu: host1x: Acquire a reference to the IOVA cache
On 14.05.2018 13:13, Thierry Reding wrote:
> From: Thierry Reding
>
> The IOVA API uses a memory cache to allocate IOVA nodes from. To make
> sure that this cache is available, obtain a reference to it and release
> the reference when the cache is no longer needed.
>
> On 64-bit ARM this is hidden by the fact that the DMA mapping API gets
> that reference and never releases it. On 32-bit ARM, this is papered
> over by the Tegra DRM driver (the sole user of the host1x API requiring
> the cache) acquiring a reference to the IOVA cache for its own purposes.
> However, there may be additional users of this API in the future, so fix
> this upfront to avoid surprises.
>
> Fixes: 404bfb78daf3 ("gpu: host1x: Add IOMMU support")
> Signed-off-by: Thierry Reding
> ---
> drivers/gpu/host1x/dev.c | 11 ++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/host1x/dev.c b/drivers/gpu/host1x/dev.c
> index 03db71173f5d..f1d5f76e9c33 100644
> --- a/drivers/gpu/host1x/dev.c
> +++ b/drivers/gpu/host1x/dev.c
> @@ -223,10 +223,14 @@ static int host1x_probe(struct platform_device *pdev)
> struct iommu_domain_geometry *geometry;
> unsigned long order;
>
> + err = iova_cache_get();
> + if (err < 0)
> + goto put_group;
> +
> host->domain = iommu_domain_alloc(&platform_bus_type);
> if (!host->domain) {
> err = -ENOMEM;
> - goto put_group;
> + goto put_cache;
> }
>
> err = iommu_attach_group(host->domain, host->group);
> @@ -234,6 +238,7 @@ static int host1x_probe(struct platform_device *pdev)
> if (err == -ENODEV) {
> iommu_domain_free(host->domain);
> host->domain = NULL;
> + iova_cache_put();
> iommu_group_put(host->group);
> host->group = NULL;
> goto skip_iommu;
> @@ -308,6 +313,9 @@ static int host1x_probe(struct platform_device *pdev)
> fail_free_domain:
> if (host->domain)
> iommu_domain_free(host->domain);
> +put_cache:
> + if (host->group)
> + iova_cache_put();
> put_group:
> iommu_group_put(host->group);
>
> @@ -328,6 +336,7 @@ static int host1x_remove(struct platform_device *pdev)
> put_iova_domain(&host->iova);
> iommu_detach_group(host->domain, host->group);
> iommu_domain_free(host->domain);
> + iova_cache_put();
> iommu_group_put(host->group);
> }
>
>
Reviewed-by: Dmitry Osipenko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 2/4] dt-bindings: drm/bridge: Document sn65dsi86 bridge bindings
Document the bindings used for the sn65dsi86 DSI to eDP bridge.
Changes in v1:
- Rephrase the dt-binding descriptions to be more inline with existing
bindings (Andrzej Hajda).
- Add missing dt-binding that are parsed by corresponding driver
(Andrzej Hajda).
Changes in v2:
- Remove edp panel specific dt-binding entries. Only keep bridge
specific entries (Sean Paul).
- Remove custom-modes dt entry since its usage is removed from driver also
(Sean Paul).
- Remove is-pluggable dt entry since this will not be needed anymore (Sean
Paul).
Changes in v3:
- Remove irq-gpio dt entry and instead populate is an interrupt
property (Rob Herring).
Changes in v4:
- Add link to bridge chip datasheet (Stephen Boyd)
- Add vpll and vcc regulator supply bindings (Stephen Boyd)
- Add ref clk optional dt binding (Stephen Boyd)
- Add gpio-controller optional dt binding (Stephen Boyd)
Changes in v5:
- Use clock property to specify the input refclk (Stephen Boyd).
- Update gpio cell and pwm cell numbers (Stephen Boyd).
Signed-off-by: Sandeep Panda
---
.../bindings/display/bridge/ti,sn65dsi86.txt | 81 ++
1 file changed, 81 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..b82bb56
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt
@@ -0,0 +1,81 @@
+SN65DSI86 DSI to eDP bridge chip
+
+
+This is the binding for Texas Instruments SN65DSI86 bridge.
+http://www.ti.com/general/docs/lit/getliterature.tsp?genericPartNumber=sn65dsi86&fileType=pdf
+
+Required properties:
+- compatible: Must be "ti,sn65dsi86"
+- reg: i2c address of the chip, 0x2d as per datasheet
+- enable-gpios: OF device-tree gpio specification for bridge_en pin
+
+- vccio-supply: A 1.8V supply that powers up the digital IOs.
+- vpll-supply: A 1.8V supply that powers up the displayport PLL.
+- vcca-supply: A 1.2V supply that powers up the analog circuits.
+- vcc-supply: A 1.2V supply that powers up the digital core.
+
+Optional properties:
+- interrupts: Specifier for the SN65DSI86 interrupt line.
+- hpd-gpios: OF device-tree gpio specifications for HPD pin.
+
+- gpio-controller: Marks the device has a GPIO controller.
+- #gpio-cells: Should be two. The first cell is the pin number and
+ the second cell is used to specify flags.
+ See ../../gpio/gpio.txt for more information.
+- #pwm-cells : Should be one. See ../../pwm/pwm.txt for description of
+ the cell formats.
+
+- clock-names: should be "refclk"
+- clocks: OF device-tree clock specification for refclk input. The reference
+ clock rate must be 12 MHz, 19.2 MHz, 26 MHz, 27 MHz or 38.4 MHz.
+
+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>;
+ interrupt-parent = <&gpio3>;
+ interrupts = <4 IRQ_TYPE_EDGE_FALLING>;
+
+ vccio-supply = <&pm8916_l17>;
+ vcca-supply = <&pm8916_l6>;
+ vpll-supply = <&pm8916_l17>;
+ vcc-supply = <&pm8916_l6>;
+
+ clock-names = "refclk";
+ clocks = <&input_refclk>;
+
+ 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
[RFC PATCH 00/10] Add support for drm/rockchip to dynamically control the DDR frequency.
Dear all, The rk3399 platform has a DFI controller that can monitor DDR load and a DMC driver that talks with the TF-A (Trusted Firmware-A) to dynamically set the DDR frequency with following flow. kernel Trusted Firmware-A (bl31) monitor ddr load | | get_target_rate | | pass rate to TF-A clk_set_rate(ddr) ->run ddr dvs flow | | <--end ddr dvs flow | | return These patches add support for devfreq to dynamically control the DDR frequency into the drm rockchip driver. By default it uses the 'simple_ondemand' governor which can adjust the frequency based on the DDR load. Although the patches were present in the chromeos kernel for long time I am sending this as a RFC because I have doubts on some of them, specially patch 4/10 that tries to sync the TF-A with the kernel using a mutex, to be honest I did not find another way to do it so feedback is more than welcome. The patches apply on top of current 4.17-rc5 and depends on the following series to apply cleanly. 1. https://lkml.org/lkml/2018/5/9/464 2. https://lkml.org/lkml/2018/4/23/354 Waiting for your feedback. Best regards, Enric Derek Basehore (3): devfreq: rk3399_dmc / clk: rockchip: Sync with vblank in the kernel for DDRfreq. devfreq: rk3399_dmc / clk: rockchip: Disable DDR clk timeout on suspend. clk: rockchip: set clk-ddr to GET_RATE_NOCACHE. Enric Balletbo i Serra (3): devfreq: rockchip-dfi: Move GRF definitions to a common place. dt-bindings: devfreq: rk3399_dmc: Add rockchip,pmu phandle. devfreq: rk3399_dmc: Pass ODT and auto power down parameters to TF-A. Lin Huang (3): devfreq: rk3399_dmc / rockchip: pm_domains: Register notify to DMC driver. arm64: dts: rk3399: Add dfi and dmc nodes. arm64: dts: rockchip: Enable dmc and dfi nodes on gru. Sean Paul (1): drm: rockchip: Add DDR devfreq support. .../bindings/devfreq/rk3399_dmc.txt | 2 + .../rockchip/rk3399-dram-default-timing.dtsi | 38 arch/arm64/boot/dts/rockchip/rk3399-dram.h| 73 +++ arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi | 21 ++ .../boot/dts/rockchip/rk3399-op1-opp.dtsi | 29 +++ arch/arm64/boot/dts/rockchip/rk3399.dtsi | 22 +- drivers/clk/rockchip/clk-ddr.c| 159 --- drivers/clk/rockchip/clk.c| 2 +- drivers/clk/rockchip/clk.h| 3 +- drivers/devfreq/event/rockchip-dfi.c | 23 +-- drivers/devfreq/rk3399_dmc.c | 191 +++--- drivers/devfreq/rk3399_dmc_priv.h | 16 ++ drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 46 + drivers/gpu/drm/rockchip/rockchip_drm_drv.h | 9 + drivers/gpu/drm/rockchip/rockchip_drm_fb.c| 35 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 34 drivers/soc/rockchip/pm_domains.c | 36 include/soc/rockchip/rk3399_dmc.h | 44 include/soc/rockchip/rk3399_grf.h | 21 ++ include/soc/rockchip/rockchip_sip.h | 1 + 20 files changed, 734 insertions(+), 71 deletions(-) create mode 100644 arch/arm64/boot/dts/rockchip/rk3399-dram-default-timing.dtsi create mode 100644 arch/arm64/boot/dts/rockchip/rk3399-dram.h create mode 100644 drivers/devfreq/rk3399_dmc_priv.h create mode 100644 include/soc/rockchip/rk3399_dmc.h create mode 100644 include/soc/rockchip/rk3399_grf.h -- 2.17.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 1/4] drm/rockchip: add transfer function for cdn-dp
From: Chris Zhong
We may support training outside firmware, so we need support
dpcd read/write to get the message or do some setting with
display.
Signed-off-by: Chris Zhong
Signed-off-by: Lin Huang
Reviewed-by: Sean Paul
Reviewed-by: Enric Balletbo
---
Changes in v2:
- update patch following Enric suggest
- None
drivers/gpu/drm/rockchip/cdn-dp-core.c | 55 +++
drivers/gpu/drm/rockchip/cdn-dp-core.h | 1 +
drivers/gpu/drm/rockchip/cdn-dp-reg.c | 69 ++
drivers/gpu/drm/rockchip/cdn-dp-reg.h | 14 ++-
4 files changed, 122 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c
b/drivers/gpu/drm/rockchip/cdn-dp-core.c
index c6fbdcd..cce64c1 100644
--- a/drivers/gpu/drm/rockchip/cdn-dp-core.c
+++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c
@@ -176,8 +176,8 @@ static int cdn_dp_get_sink_count(struct cdn_dp_device *dp,
u8 *sink_count)
u8 value;
*sink_count = 0;
- ret = cdn_dp_dpcd_read(dp, DP_SINK_COUNT, &value, 1);
- if (ret)
+ ret = drm_dp_dpcd_read(&dp->aux, DP_SINK_COUNT, &value, 1);
+ if (ret < 0)
return ret;
*sink_count = DP_GET_SINK_COUNT(value);
@@ -374,9 +374,9 @@ static int cdn_dp_get_sink_capability(struct cdn_dp_device
*dp)
if (!cdn_dp_check_sink_connection(dp))
return -ENODEV;
- ret = cdn_dp_dpcd_read(dp, DP_DPCD_REV, dp->dpcd,
- DP_RECEIVER_CAP_SIZE);
- if (ret) {
+ ret = drm_dp_dpcd_read(&dp->aux, DP_DPCD_REV, dp->dpcd,
+ sizeof(dp->dpcd));
+ if (ret < 0) {
DRM_DEV_ERROR(dp->dev, "Failed to get caps %d\n", ret);
return ret;
}
@@ -582,8 +582,8 @@ static bool cdn_dp_check_link_status(struct cdn_dp_device
*dp)
if (!port || !dp->link.rate || !dp->link.num_lanes)
return false;
- if (cdn_dp_dpcd_read(dp, DP_LANE0_1_STATUS, link_status,
-DP_LINK_STATUS_SIZE)) {
+ if (drm_dp_dpcd_read_link_status(&dp->aux, link_status) !=
+ DP_LINK_STATUS_SIZE) {
DRM_ERROR("Failed to get link status\n");
return false;
}
@@ -1012,6 +1012,40 @@ static int cdn_dp_pd_event(struct notifier_block *nb,
return NOTIFY_DONE;
}
+static ssize_t cdn_dp_aux_transfer(struct drm_dp_aux *aux,
+ struct drm_dp_aux_msg *msg)
+{
+ struct cdn_dp_device *dp = container_of(aux, struct cdn_dp_device, aux);
+ int ret;
+ u8 status;
+
+ switch (msg->request & ~DP_AUX_I2C_MOT) {
+ case DP_AUX_NATIVE_WRITE:
+ case DP_AUX_I2C_WRITE:
+ case DP_AUX_I2C_WRITE_STATUS_UPDATE:
+ ret = cdn_dp_dpcd_write(dp, msg->address, msg->buffer,
+ msg->size);
+ break;
+ case DP_AUX_NATIVE_READ:
+ case DP_AUX_I2C_READ:
+ ret = cdn_dp_dpcd_read(dp, msg->address, msg->buffer,
+ msg->size);
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ status = cdn_dp_get_aux_status(dp);
+ if (status == AUX_STATUS_ACK)
+ msg->reply = DP_AUX_NATIVE_REPLY_ACK;
+ else if (status == AUX_STATUS_NACK)
+ msg->reply = DP_AUX_NATIVE_REPLY_NACK;
+ else if (status == AUX_STATUS_DEFER)
+ msg->reply = DP_AUX_NATIVE_REPLY_DEFER;
+
+ return ret;
+}
+
static int cdn_dp_bind(struct device *dev, struct device *master, void *data)
{
struct cdn_dp_device *dp = dev_get_drvdata(dev);
@@ -1030,6 +1064,13 @@ static int cdn_dp_bind(struct device *dev, struct device
*master, void *data)
dp->active = false;
dp->active_port = -1;
dp->fw_loaded = false;
+ dp->aux.name = "DP-AUX";
+ dp->aux.transfer = cdn_dp_aux_transfer;
+ dp->aux.dev = dev;
+
+ ret = drm_dp_aux_register(&dp->aux);
+ if (ret)
+ return ret;
INIT_WORK(&dp->event_work, cdn_dp_pd_event_work);
diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.h
b/drivers/gpu/drm/rockchip/cdn-dp-core.h
index f57e296..46159b2 100644
--- a/drivers/gpu/drm/rockchip/cdn-dp-core.h
+++ b/drivers/gpu/drm/rockchip/cdn-dp-core.h
@@ -78,6 +78,7 @@ struct cdn_dp_device {
struct platform_device *audio_pdev;
struct work_struct event_work;
struct edid *edid;
+ struct drm_dp_aux aux;
struct mutex lock;
bool connected;
diff --git a/drivers/gpu/drm/rockchip/cdn-dp-reg.c
b/drivers/gpu/drm/rockchip/cdn-dp-reg.c
index eb3042c..979355d 100644
--- a/drivers/gpu/drm/rockchip/cdn-dp-reg.c
+++ b/drivers/gpu/drm/rockchip/cdn-dp-reg.c
@@ -221,7 +221,12 @@ static int cdn_dp_reg_write_bit(struct cdn_dp_device *dp,
u16 addr,
sizeof(field), field);
}
-int cdn_dp_dpcd_read(struct cdn_dp
[RFC PATCH 03/10] devfreq: rk3399_dmc: Pass ODT and auto power down parameters to TF-A.
Trusted Firmware-A (TF-A) for rk3399 implements a SiP call to get the
on-die termination (ODT) and auto power down parameters from kernel,
this patch adds the functionality to do this. Also, if DDR clock
frequency is lower than the on-die termination (ODT) disable frequency
this driver should disable the DDR ODT.
Signed-off-by: Enric Balletbo i Serra
---
drivers/devfreq/rk3399_dmc.c| 50 -
include/soc/rockchip/rockchip_sip.h | 1 +
2 files changed, 50 insertions(+), 1 deletion(-)
diff --git a/drivers/devfreq/rk3399_dmc.c b/drivers/devfreq/rk3399_dmc.c
index d5c03e5abe13..cc1bbca3fb15 100644
--- a/drivers/devfreq/rk3399_dmc.c
+++ b/drivers/devfreq/rk3399_dmc.c
@@ -18,14 +18,17 @@
#include
#include
#include
+#include
#include
#include
#include
#include
+#include
#include
#include
#include
+#include
#include
struct dram_timing {
@@ -69,8 +72,11 @@ struct rk3399_dmcfreq {
struct mutex lock;
struct dram_timing timing;
struct regulator *vdd_center;
+ struct regmap *regmap_pmu;
unsigned long rate, target_rate;
unsigned long volt, target_volt;
+ unsigned int odt_dis_freq;
+ int odt_pd_arg0, odt_pd_arg1;
};
static int rk3399_dmcfreq_target(struct device *dev, unsigned long *freq,
@@ -80,6 +86,8 @@ static int rk3399_dmcfreq_target(struct device *dev, unsigned
long *freq,
struct dev_pm_opp *opp;
unsigned long old_clk_rate = dmcfreq->rate;
unsigned long target_volt, target_rate;
+ struct arm_smccc_res res;
+ int dram_flag;
int err;
opp = devfreq_recommended_opp(dev, freq, flags);
@@ -95,6 +103,15 @@ static int rk3399_dmcfreq_target(struct device *dev,
unsigned long *freq,
mutex_lock(&dmcfreq->lock);
+ dram_flag = 0;
+ if (target_rate >= dmcfreq->odt_dis_freq)
+ dram_flag = 1;
+
+ arm_smccc_smc(ROCKCHIP_SIP_DRAM_FREQ, dmcfreq->odt_pd_arg0,
+ dmcfreq->odt_pd_arg1,
+ ROCKCHIP_SIP_CONFIG_DRAM_SET_ODT_PD,
+ dram_flag, 0, 0, 0, &res);
+
/*
* If frequency scaling from low to high, adjust voltage first.
* If frequency scaling from high to low, adjust frequency first.
@@ -294,11 +311,13 @@ static int rk3399_dmcfreq_probe(struct platform_device
*pdev)
{
struct arm_smccc_res res;
struct device *dev = &pdev->dev;
- struct device_node *np = pdev->dev.of_node;
+ struct device_node *np = pdev->dev.of_node, *node;
struct rk3399_dmcfreq *data;
int ret, index, size;
uint32_t *timing;
struct dev_pm_opp *opp;
+ u32 ddr_type;
+ u32 val;
data = devm_kzalloc(dev, sizeof(struct rk3399_dmcfreq), GFP_KERNEL);
if (!data)
@@ -334,6 +353,29 @@ static int rk3399_dmcfreq_probe(struct platform_device
*pdev)
return ret;
}
+ /* Try to find the optional reference to the pmu syscon */
+ node = of_parse_phandle(np, "rockchip,pmu", 0);
+ if (node) {
+ data->regmap_pmu = syscon_node_to_regmap(node);
+ if (IS_ERR(data->regmap_pmu))
+ return PTR_ERR(data->regmap_pmu);
+ }
+
+ /* Get DDR type */
+ regmap_read(data->regmap_pmu, RK3399_PMUGRF_OS_REG2, &val);
+ ddr_type = (val >> RK3399_PMUGRF_DDRTYPE_SHIFT) &
+ RK3399_PMUGRF_DDRTYPE_MASK;
+
+ /* Get the odt_dis_freq parameter in function of the DDR type */
+ if (ddr_type == RK3399_PMUGRF_DDRTYPE_DDR3)
+ data->odt_dis_freq = data->timing.ddr3_odt_dis_freq;
+ else if (ddr_type == RK3399_PMUGRF_DDRTYPE_LPDDR3)
+ data->odt_dis_freq = data->timing.lpddr3_odt_dis_freq;
+ else if (ddr_type == RK3399_PMUGRF_DDRTYPE_LPDDR4)
+ data->odt_dis_freq = data->timing.lpddr4_odt_dis_freq;
+ else
+ return -EINVAL;
+
/*
* Get dram timing and pass it to arm trust firmware,
* the dram drvier in arm trust firmware will get these
@@ -358,6 +400,12 @@ static int rk3399_dmcfreq_probe(struct platform_device
*pdev)
ROCKCHIP_SIP_CONFIG_DRAM_INIT,
0, 0, 0, 0, &res);
+ data->odt_pd_arg0 = (data->timing.sr_idle & 0xff) |
+ ((data->timing.sr_mc_gate_idle & 0xff) << 8) |
+ ((data->timing.standby_idle & 0x) << 16);
+ data->odt_pd_arg1 = (data->timing.pd_idle & 0xfff) |
+ ((data->timing.srpd_lite_idle & 0xfff) << 16);
+
/*
* We add a devfreq driver to our parent since it has a device tree node
* with operating points.
diff --git a/include/soc/rockchip/rockchip_sip.h
b/include/soc/rockchip/rockchip_sip.h
index 7e28092c4d3d..ad9482c56797 100644
--- a/include/soc/rockchip/rockchip_sip.h
+++ b/include/soc/rockchip/rockchip_sip.h
@@ -23,5
[PATCH v4 3/4] phy: rockchip-typec: support variable phy config value
the phy config values used to fix in dp firmware, but some boards
need change these values to do training and get the better eye diagram
result. So support that in phy driver.
Signed-off-by: Chris Zhong
Signed-off-by: Lin Huang
---
Changes in v2:
- update patch following Enric suggest
Changes in v3:
- delete need_software_training variable
- add default phy config value, if dts do not define phy config value, use
these value
Changes in v4:
- rename variable config to tcphy_default_config
drivers/phy/rockchip/phy-rockchip-typec.c | 306 --
include/soc/rockchip/rockchip_phy_typec.h | 63 ++
2 files changed, 271 insertions(+), 98 deletions(-)
create mode 100644 include/soc/rockchip/rockchip_phy_typec.h
diff --git a/drivers/phy/rockchip/phy-rockchip-typec.c
b/drivers/phy/rockchip/phy-rockchip-typec.c
index 76a4b58..5d8692d 100644
--- a/drivers/phy/rockchip/phy-rockchip-typec.c
+++ b/drivers/phy/rockchip/phy-rockchip-typec.c
@@ -63,6 +63,7 @@
#include
#include
+#include
#define CMN_SSM_BANDGAP(0x21 << 2)
#define CMN_SSM_BIAS (0x22 << 2)
@@ -323,21 +324,29 @@
* clock 0: PLL 0 div 1
* clock 1: PLL 1 div 2
*/
-#define CLK_PLL_CONFIG 0X30
+#define CLK_PLL1_DIV1 0x20
+#define CLK_PLL1_DIV2 0x30
#define CLK_PLL_MASK 0x33
#define CMN_READY BIT(0)
+#define DP_PLL_CLOCK_ENABLE_ACKBIT(3)
#define DP_PLL_CLOCK_ENABLEBIT(2)
+#define DP_PLL_ENABLE_ACK BIT(1)
#define DP_PLL_ENABLE BIT(0)
#define DP_PLL_DATA_RATE_RBR ((2 << 12) | (4 << 8))
#define DP_PLL_DATA_RATE_HBR ((2 << 12) | (4 << 8))
#define DP_PLL_DATA_RATE_HBR2 ((1 << 12) | (2 << 8))
+#define DP_PLL_DATA_RATE_MASK 0xff00
-#define DP_MODE_A0 BIT(4)
-#define DP_MODE_A2 BIT(6)
-#define DP_MODE_ENTER_A0 0xc101
-#define DP_MODE_ENTER_A2 0xc104
+#define DP_MODE_MASK 0xf
+#define DP_MODE_ENTER_A0 BIT(0)
+#define DP_MODE_ENTER_A2 BIT(2)
+#define DP_MODE_ENTER_A3 BIT(3)
+#define DP_MODE_A0_ACK BIT(4)
+#define DP_MODE_A2_ACK BIT(6)
+#define DP_MODE_A3_ACK BIT(7)
+#define DP_LINK_RESET_DEASSERTED BIT(8)
#define PHY_MODE_SET_TIMEOUT 10
@@ -349,51 +358,7 @@
#define MODE_DFP_USB BIT(1)
#define MODE_DFP_DPBIT(2)
-struct usb3phy_reg {
- u32 offset;
- u32 enable_bit;
- u32 write_enable;
-};
-
-/**
- * struct rockchip_usb3phy_port_cfg: usb3-phy port configuration.
- * @reg: the base address for usb3-phy config.
- * @typec_conn_dir: the register of type-c connector direction.
- * @usb3tousb2_en: the register of type-c force usb2 to usb2 enable.
- * @external_psm: the register of type-c phy external psm clock.
- * @pipe_status: the register of type-c phy pipe status.
- * @usb3_host_disable: the register of type-c usb3 host disable.
- * @usb3_host_port: the register of type-c usb3 host port.
- * @uphy_dp_sel: the register of type-c phy DP select control.
- */
-struct rockchip_usb3phy_port_cfg {
- unsigned int reg;
- struct usb3phy_reg typec_conn_dir;
- struct usb3phy_reg usb3tousb2_en;
- struct usb3phy_reg external_psm;
- struct usb3phy_reg pipe_status;
- struct usb3phy_reg usb3_host_disable;
- struct usb3phy_reg usb3_host_port;
- struct usb3phy_reg uphy_dp_sel;
-};
-
-struct rockchip_typec_phy {
- struct device *dev;
- void __iomem *base;
- struct extcon_dev *extcon;
- struct regmap *grf_regs;
- struct clk *clk_core;
- struct clk *clk_ref;
- struct reset_control *uphy_rst;
- struct reset_control *pipe_rst;
- struct reset_control *tcphy_rst;
- const struct rockchip_usb3phy_port_cfg *port_cfgs;
- /* mutex to protect access to individual PHYs */
- struct mutex lock;
-
- bool flip;
- u8 mode;
-};
+#define DP_DEFAULT_RATE162000
struct phy_reg {
u16 value;
@@ -417,15 +382,15 @@ struct phy_reg usb3_pll_cfg[] = {
{ 0x8, CMN_DIAG_PLL0_LF_PROG },
};
-struct phy_reg dp_pll_cfg[] = {
+struct phy_reg dp_pll_rbr_cfg[] = {
{ 0xf0, CMN_PLL1_VCOCAL_INIT },
{ 0x18, CMN_PLL1_VCOCAL_ITER },
{ 0x30b9, CMN_PLL1_VCOCAL_START },
- { 0x21c,CMN_PLL1_INTDIV },
+ { 0x87, CMN_PLL1_INTDIV },
{ 0,CMN_PLL1_FRACDIV },
- { 0x5, CMN_PLL1_HIGH_THR },
- { 0x35, CMN_PLL1_SS_CTRL1 },
- { 0x7f1e, CMN_PLL1_SS_CTRL2 },
+ { 0x22, CMN_PLL1_HIGH_THR },
+ { 0x8000, CMN_PLL1_SS_CTRL1 },
+ { 0,CMN_PLL1_SS_CTRL2 },
{ 0x20,
Re: [RFC PATCH 03/10] devfreq: rk3399_dmc: Pass ODT and auto power down parameters to TF-A.
Hi,
On 2018년 05월 15일 06:16, Enric Balletbo i Serra wrote:
> Trusted Firmware-A (TF-A) for rk3399 implements a SiP call to get the
> on-die termination (ODT) and auto power down parameters from kernel,
> this patch adds the functionality to do this. Also, if DDR clock
> frequency is lower than the on-die termination (ODT) disable frequency
> this driver should disable the DDR ODT.
I have a question.
'disable frequency' is the same meaning of 'disable the DDR ODT'?
>
> Signed-off-by: Enric Balletbo i Serra
> ---
>
> drivers/devfreq/rk3399_dmc.c| 50 -
> include/soc/rockchip/rockchip_sip.h | 1 +
> 2 files changed, 50 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/devfreq/rk3399_dmc.c b/drivers/devfreq/rk3399_dmc.c
> index d5c03e5abe13..cc1bbca3fb15 100644
> --- a/drivers/devfreq/rk3399_dmc.c
> +++ b/drivers/devfreq/rk3399_dmc.c
> @@ -18,14 +18,17 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
>
> +#include
> #include
>
> struct dram_timing {
> @@ -69,8 +72,11 @@ struct rk3399_dmcfreq {
> struct mutex lock;
> struct dram_timing timing;
> struct regulator *vdd_center;
> + struct regmap *regmap_pmu;
> unsigned long rate, target_rate;
> unsigned long volt, target_volt;
> + unsigned int odt_dis_freq;
> + int odt_pd_arg0, odt_pd_arg1;
> };
>
> static int rk3399_dmcfreq_target(struct device *dev, unsigned long *freq,
> @@ -80,6 +86,8 @@ static int rk3399_dmcfreq_target(struct device *dev,
> unsigned long *freq,
> struct dev_pm_opp *opp;
> unsigned long old_clk_rate = dmcfreq->rate;
> unsigned long target_volt, target_rate;
> + struct arm_smccc_res res;
> + int dram_flag;
> int err;
>
> opp = devfreq_recommended_opp(dev, freq, flags);
> @@ -95,6 +103,15 @@ static int rk3399_dmcfreq_target(struct device *dev,
> unsigned long *freq,
>
> mutex_lock(&dmcfreq->lock);
>
> + dram_flag = 0;
Also, if dram_flag is 0, it mean that disable ODT frequency?
If it's right, you better to define the precise variables as following
instead of just integer(0 or 1).
For example,
- ROCKCHIP_SIP_DRAM_FREQ_ENABLE
- ROCKCHIP_SIP_DRAM_FREQ_DISABLE
> + if (target_rate >= dmcfreq->odt_dis_freq)
> + dram_flag = 1;
> +
> + arm_smccc_smc(ROCKCHIP_SIP_DRAM_FREQ, dmcfreq->odt_pd_arg0,
> + dmcfreq->odt_pd_arg1,
> + ROCKCHIP_SIP_CONFIG_DRAM_SET_ODT_PD,
> + dram_flag, 0, 0, 0, &res);
> +
This operation is special for only rk3399_dmc. It is difficult
to understand what to do. I recommend you better to add the detailed comment
with code.
> /*
>* If frequency scaling from low to high, adjust voltage first.
>* If frequency scaling from high to low, adjust frequency first.
> @@ -294,11 +311,13 @@ static int rk3399_dmcfreq_probe(struct platform_device
> *pdev)
> {
> struct arm_smccc_res res;
> struct device *dev = &pdev->dev;
> - struct device_node *np = pdev->dev.of_node;
> + struct device_node *np = pdev->dev.of_node, *node;
> struct rk3399_dmcfreq *data;
> int ret, index, size;
> uint32_t *timing;
> struct dev_pm_opp *opp;
> + u32 ddr_type;
> + u32 val;
>
> data = devm_kzalloc(dev, sizeof(struct rk3399_dmcfreq), GFP_KERNEL);
> if (!data)
> @@ -334,6 +353,29 @@ static int rk3399_dmcfreq_probe(struct platform_device
> *pdev)
> return ret;
> }
>
> + /* Try to find the optional reference to the pmu syscon */
> + node = of_parse_phandle(np, "rockchip,pmu", 0);
> + if (node) {
> + data->regmap_pmu = syscon_node_to_regmap(node);
> + if (IS_ERR(data->regmap_pmu))
> + return PTR_ERR(data->regmap_pmu);
> + }
> +
> + /* Get DDR type */
> + regmap_read(data->regmap_pmu, RK3399_PMUGRF_OS_REG2, &val);
> + ddr_type = (val >> RK3399_PMUGRF_DDRTYPE_SHIFT) &
> + RK3399_PMUGRF_DDRTYPE_MASK;
> +
> + /* Get the odt_dis_freq parameter in function of the DDR type */
> + if (ddr_type == RK3399_PMUGRF_DDRTYPE_DDR3)
> + data->odt_dis_freq = data->timing.ddr3_odt_dis_freq;
> + else if (ddr_type == RK3399_PMUGRF_DDRTYPE_LPDDR3)
> + data->odt_dis_freq = data->timing.lpddr3_odt_dis_freq;
> + else if (ddr_type == RK3399_PMUGRF_DDRTYPE_LPDDR4)
> + data->odt_dis_freq = data->timing.lpddr4_odt_dis_freq;
> + else
> + return -EINVAL;
> +
how about using 'switch' statement?
> /*
>* Get dram timing and pass it to arm trust firmware,
>* the dram drvier in arm trust firmware will get these
> @@ -358,6 +400,12 @@ static int rk3399_dmcfreq_probe(struct platform_device
> *pdev)
> ROCKCHIP_SIP_CONFIG_DRAM_INIT,
> 0, 0, 0, 0,
Re: drm SPDX updates
On Mon, May 14, 2018 at 07:59:56AM +0200, Thomas Gleixner wrote: > Dirk, > > On Mon, 7 May 2018, Dirk Hohndel (VMware) wrote: > > > License clarifications and SPDX headers for a bunch of files which were > > authored by VMware. > > > > This should address the comments made on the previous series. > > I added Thomas as Cc (sorry, forgot on the first version) and added a > > couple of SOBs that I had received in the meantime. > > Thanks for cleaning that up. > > FWIW: Acked-by: Thomas Gleixner I haven't seen any comments in the week since I wrote this. I'm not familiar with the process for the drm changes - so what are the usual next steps? Do I need to submit all or part of this somewhere else? Or does Dave simply take the series (since it has no executable code changes at all)? /D ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 09/21] arm64: dts: allwinner: a64: Add HDMI support
On Wed, May 2, 2018 at 5:04 PM, Maxime Ripard wrote:
> Hi,
>
> On Mon, Apr 30, 2018 at 05:10:46PM +0530, Jagan Teki wrote:
>> + hdmi_phy: hdmi-phy@1ef {
>> + compatible = "allwinner,sun50i-a64-hdmi-phy",
>> + "allwinner,sun8i-h3-hdmi-phy";
>> + reg = <0x01ef 0x1>;
>> + clocks = <&ccu CLK_BUS_HDMI>, <&ccu CLK_HDMI_DDC>,
>> + <&ccu CLK_PLL_VIDEO1>;
>
> You were discussing that the PLL0 could also be used to clock the PHY,
> has that been figured out?
This is what I understand from Fig: 3-3. Module Clock Diagram, both
tcon0 and tcon1 are using HDMI. I'm thinking based on the tcon
configuration we need use proper PLL or some logic to get common PLL
don't know yet. Since this series adding tcon1 I've attached PLL1.
Jagan.
--
Jagan Teki
Senior Linux Kernel Engineer | Amarula Solutions
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106519] Is it normal that the 4K video on the Vega 56 GPU played with loud turbine noise, 200% load of the desktop Core i7 CPU and at the same time playable with jerks and dropping frames?
https://bugs.freedesktop.org/show_bug.cgi?id=106519 --- Comment #3 from Christian König --- > $ mpv --hwdec=vaapi Downloads/WE\ GOT\ INTEL\'S\ PROTOTYPE\ GRAPHICS\ > CARD.webm > Playing: Downloads/WE GOT INTEL'S PROTOTYPE GRAPHICS CARD.webm > (+) Video --vid=1 (*) (vp9 3840x2160 29.970fps) > Failed to open VDPAU backend libvdpau_nvidia.so: cannot open shared object > file: No such file or directory "--hwdec=vaapi" and "Failed to open VDPAU backend"? Could it be that you have a setting which says to use VDPAU for displaying? -- 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
Re: [RFC PATCH 5/5] media: platform: Add Chrome OS EC CEC driver
Hi Hans,
Thanks for the extensive review.
On 15/05/2018 08:58, Hans Verkuil wrote:
> On 05/15/2018 12:40 AM, Neil Armstrong wrote:
>> The Chrome OS Embedded Controller can expose a CEC bus, this patch add the
>> driver for such feature of the Embedded Controller.
>>
>> This driver is part of the cros-ec MFD and will be add as a sub-device when
>> the feature bit is exposed by the EC.
>>
>> The controller will only handle a single logical address and handles
>> all the messages retries and will only expose Success or Error.
>>
>> When the logical address is invalid, the controller will act as a CEC sniffer
>> and transfer all messages on the bus.
>
> I did not see any support for this. If this works as you state here, then
> adding
> support for CEC_CAP_MONITOR_ALL is highly recommended.
Oops, I forgot to remove this phrase, the FW will maybe support it, but it has
been
dropped for the first revision.
>
>>
>> Signed-off-by: Neil Armstrong
>> ---
>> drivers/media/platform/Kconfig | 11 +
>> drivers/media/platform/Makefile | 2 +
>> drivers/media/platform/cros-ec/Makefile | 1 +
>> drivers/media/platform/cros-ec/cros-ec-cec.c | 331
>> +++
>> 4 files changed, 345 insertions(+)
>> create mode 100644 drivers/media/platform/cros-ec/Makefile
>> create mode 100644 drivers/media/platform/cros-ec/cros-ec-cec.c
>
> Shouldn't the directory be called cros-ec-cec?
>
>>
>> diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
>> index c7a1cf8..e55a8ed2 100644
>> --- a/drivers/media/platform/Kconfig
>> +++ b/drivers/media/platform/Kconfig
>> @@ -546,6 +546,17 @@ menuconfig CEC_PLATFORM_DRIVERS
>>
>> if CEC_PLATFORM_DRIVERS
>>
>> +config VIDEO_CROS_EC_CEC
>> +tristate "Chrome OS EC CEC driver"
>> +depends on MFD_CROS_EC || COMPILE_TEST
>> +select CEC_CORE
>> +select CEC_NOTIFIER
>> +---help---
>> + If you say yes here you will get support for the
>> + Chrome OS Embedded Controller's CEC.
>> + The CEC bus is present in the HDMI connector and enables communication
>> + between compatible devices.
>> +
>> config VIDEO_MESON_AO_CEC
>> tristate "Amlogic Meson AO CEC driver"
>> depends on ARCH_MESON || COMPILE_TEST
>> diff --git a/drivers/media/platform/Makefile
>> b/drivers/media/platform/Makefile
>> index 932515d..0e0582e 100644
>> --- a/drivers/media/platform/Makefile
>> +++ b/drivers/media/platform/Makefile
>> @@ -92,3 +92,5 @@ obj-$(CONFIG_VIDEO_QCOM_CAMSS) +=
>> qcom/camss-8x16/
>> obj-$(CONFIG_VIDEO_QCOM_VENUS) += qcom/venus/
>>
>> obj-y += meson/
>> +
>> +obj-y += cros-ec/
>> diff --git a/drivers/media/platform/cros-ec/Makefile
>> b/drivers/media/platform/cros-ec/Makefile
>> new file mode 100644
>> index 000..9ce97f9
>> --- /dev/null
>> +++ b/drivers/media/platform/cros-ec/Makefile
>> @@ -0,0 +1 @@
>> +obj-$(CONFIG_VIDEO_CROS_EC_CEC) += cros-ec-cec.o
>> diff --git a/drivers/media/platform/cros-ec/cros-ec-cec.c
>> b/drivers/media/platform/cros-ec/cros-ec-cec.c
>> new file mode 100644
>> index 000..fea90da
>> --- /dev/null
>> +++ b/drivers/media/platform/cros-ec/cros-ec-cec.c
>> @@ -0,0 +1,331 @@
>> +// SPDX-License-Identifier: GPL-2.0+
>> +/*
>> + * CEC driver for Chrome OS Embedded Controller
>> + *
>> + * Copyright (c) 2018 BayLibre, SAS
>> + * Author: Neil Armstrong
>> + */
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +#define DRV_NAME"cros-ec-cec"
>> +
>> +/**
>> + * struct cros_ec_cec - Driver data for EC CEC
>> + *
>> + * @cros_ec: Pointer to EC device
>> + * @notifier: Notifier info for responding to EC events
>> + * @adap: CEC adapter
>> + * @notify: CEC notifier pointer
>> + * @rc_msg: storage for a received message
>> + */
>> +struct cros_ec_cec {
>> +struct cros_ec_device *cros_ec;
>> +struct notifier_block notifier;
>> +struct cec_adapter *adap;
>> +struct cec_notifier *notify;
>> +struct cec_msg rx_msg;
>> +};
>> +
>> +static void handle_cec_message(struct cros_ec_cec *cros_ec_cec)
>> +{
>> +struct cros_ec_device *cros_ec = cros_ec_cec->cros_ec;
>> +uint8_t *cec_message = cros_ec->event_data.data.cec_message;
>> +unsigned int len = cros_ec->event_size;
>> +
>> +cros_ec_cec->rx_msg.len = len;
>
> How robust is the underlying code and hardware? What happens if a
> CEC message with more than 16 bytes is received?
>
> Hard to test unless you have an RPi3 set up as a CEC debugger. See
> last section in https://hverkuil.home.xs4all.nl/cec-status.txt.
>
> Since you worked with CEC for a while now I recommend you set up such
> a system. It's cheap and very useful.
I will definitely setup this kind of system, I tried using am Amlogic SoC, but
it really can't monitor the bus
But I a
[Bug 199693] System freeze after resuming from suspend (amdgpu)
https://bugzilla.kernel.org/show_bug.cgi?id=199693 Zhang Rui (rui.zh...@intel.com) changed: What|Removed |Added Status|NEW |RESOLVED Component|Hibernation/Suspend |Video(DRI - non Intel) Resolution|--- |DUPLICATE Assignee|r...@rjwysocki.net |drivers_video-dri@kernel-bu ||gs.osdl.org Product|Power Management|Drivers --- Comment #1 from Zhang Rui (rui.zh...@intel.com) --- *** This bug has been marked as a duplicate of bug 199609 *** -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 2/5] media: cec-notifier: Get notifier by device and connector name
On 15/05/2018 08:27, Hans Verkuil wrote:
> Hi Neil,
>
> Thanks for this patch series!
>
> Some comments below:
>
> On 05/15/2018 12:40 AM, Neil Armstrong wrote:
>> In non device-tree world, we can need to get the notifier by the driver
>> name directly and eventually defer probe if not yet created.
>>
>> This patch adds a variant of the get function by using the device name
>> instead and will not create a notifier if not yet created.
>>
>> But the i915 driver exposes at least 2 HDMI connectors, this patch also
>> adds the possibility to add a connector name tied to the notifier device
>> to form a tuple and associate different CEC controllers for each HDMI
>> connectors.
>>
>> Signed-off-by: Neil Armstrong
>> ---
>> drivers/media/cec/cec-notifier.c | 30 ---
>> include/media/cec-notifier.h | 44
>> ++--
>> 2 files changed, 69 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/media/cec/cec-notifier.c
>> b/drivers/media/cec/cec-notifier.c
>> index 16dffa0..716070a 100644
>> --- a/drivers/media/cec/cec-notifier.c
>> +++ b/drivers/media/cec/cec-notifier.c
>> @@ -21,6 +21,7 @@ struct cec_notifier {
>> struct list_head head;
>> struct kref kref;
>> struct device *dev;
>> +const char *conn;
>> struct cec_adapter *cec_adap;
>> void (*callback)(struct cec_adapter *adap, u16 pa);
>>
>> @@ -30,13 +31,34 @@ struct cec_notifier {
>> static LIST_HEAD(cec_notifiers);
>> static DEFINE_MUTEX(cec_notifiers_lock);
>>
>> -struct cec_notifier *cec_notifier_get(struct device *dev)
>> +struct cec_notifier *cec_notifier_get_byname(const char *name,
>> + const char *conn)
>> {
>> struct cec_notifier *n;
>>
>> mutex_lock(&cec_notifiers_lock);
>> list_for_each_entry(n, &cec_notifiers, head) {
>> -if (n->dev == dev) {
>> +if (!strcmp(dev_name(n->dev), name) &&
>> +(!conn || !strcmp(n->conn, conn))) {
>> +kref_get(&n->kref);
>> +mutex_unlock(&cec_notifiers_lock);
>> +return n;
>> +}
>> +}
>> +mutex_unlock(&cec_notifiers_lock);
>> +
>> +return NULL;
>
> This doesn't seem right. For one it doesn't act like the other
> cec_notifier_get*
> functions in that it doesn't make a new notifier if it wasn't found yet in the
> list.
>
> For another, I think this function shouldn't be here at all. How about calling
> bus_find_device_by_name(), then use cec_notifier_get_conn()?
Yes, it's safer and will keep the original cec_notifier_get() behavior.
>
>> +}
>> +EXPORT_SYMBOL_GPL(cec_notifier_get_byname);
>> +
>> +struct cec_notifier *cec_notifier_get_conn(struct device *dev, const char
>> *conn)
>> +{
>> +struct cec_notifier *n;
>> +
>> +mutex_lock(&cec_notifiers_lock);
>> +list_for_each_entry(n, &cec_notifiers, head) {
>> +if (n->dev == dev &&
>> +(!conn || !strcmp(n->conn, conn))) {
>> kref_get(&n->kref);
>> mutex_unlock(&cec_notifiers_lock);
>> return n;
>> @@ -46,6 +68,8 @@ struct cec_notifier *cec_notifier_get(struct device *dev)
>> if (!n)
>> goto unlock;
>> n->dev = dev;
>> +if (conn)
>> +n->conn = devm_kstrdup(dev, conn, GFP_KERNEL);
>
> The use of devm_kstrdup worries me. The problem is that when the 'dev' device
> is removed, this memory is also automatically freed. But the notifier might
> still have a reference through the CEC driver, so you end up with a n->conn
> pointer that points to freed memory.
>
> I think it is better to just use kstrdup and kfree it when the last notifier
> reference is released.
Ok
>
>> n->phys_addr = CEC_PHYS_ADDR_INVALID;
>> mutex_init(&n->lock);
>> kref_init(&n->kref);
>> @@ -54,7 +78,7 @@ struct cec_notifier *cec_notifier_get(struct device *dev)
>> mutex_unlock(&cec_notifiers_lock);
>> return n;
>> }
>> -EXPORT_SYMBOL_GPL(cec_notifier_get);
>> +EXPORT_SYMBOL_GPL(cec_notifier_get_conn);
>>
>> static void cec_notifier_release(struct kref *kref)
>> {
>> diff --git a/include/media/cec-notifier.h b/include/media/cec-notifier.h
>> index cf0add7..70f2974 100644
>> --- a/include/media/cec-notifier.h
>> +++ b/include/media/cec-notifier.h
>> @@ -20,6 +20,37 @@ struct cec_notifier;
>> #if IS_REACHABLE(CONFIG_CEC_CORE) && IS_ENABLED(CONFIG_CEC_NOTIFIER)
>>
>> /**
>> + * cec_notifier_get_byname - find a cec_notifier for the given device name
>> + * and connector tuple.
>> + * @name: device name that sends the events.
>> + * @conn: the connector name from which the event occurs
>> + *
>> + * If a notifier for device @name exists, then increase the refcount and
>> + * return that notifier.
>> + *
>> + * If it doesn't exist, return NULL
>> + */
>> +struct cec_notifier *cec_notifier_get_byname(const char *name,
>> +
Re: [RFC PATCH 3/5] drm/i915: hdmi: add CEC notifier to intel_hdmi
On 15/05/2018 08:34, Hans Verkuil wrote: > On 05/15/2018 12:40 AM, Neil Armstrong wrote: >> This patchs adds the cec_notifier feature to the intel_hdmi part >> of the i915 DRM driver. It uses the HDMI DRM connector name to differentiate >> between each HDMI ports. >> The changes will allow the i915 HDMI code to notify EDID and HPD changes >> to an eventual CEC adapter. >> >> Signed-off-by: Neil Armstrong >> --- >> drivers/gpu/drm/i915/intel_drv.h | 2 ++ >> drivers/gpu/drm/i915/intel_hdmi.c | 10 ++ > > The Kconfig also needs to be changed. In the DRM_I915 you need to add: > > select CEC_CORE if CEC_NOTIFIER OK, thanks > > Otherwise you'll get problems if the cec driver is a module and i915 is > built-in. > > Regards, > > Hans > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 3/5] drm/i915: hdmi: add CEC notifier to intel_hdmi
On 15/05/2018 08:29, Hans Verkuil wrote:
> On 05/15/2018 12:40 AM, Neil Armstrong wrote:
>> This patchs adds the cec_notifier feature to the intel_hdmi part
>> of the i915 DRM driver. It uses the HDMI DRM connector name to differentiate
>> between each HDMI ports.
>> The changes will allow the i915 HDMI code to notify EDID and HPD changes
>> to an eventual CEC adapter.
>>
>> Signed-off-by: Neil Armstrong
>> ---
>> drivers/gpu/drm/i915/intel_drv.h | 2 ++
>> drivers/gpu/drm/i915/intel_hdmi.c | 10 ++
>> 2 files changed, 12 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_drv.h
>> b/drivers/gpu/drm/i915/intel_drv.h
>> index d436858..b50e51b 100644
>> --- a/drivers/gpu/drm/i915/intel_drv.h
>> +++ b/drivers/gpu/drm/i915/intel_drv.h
>> @@ -39,6 +39,7 @@
>> #include
>> #include
>> #include
>> +#include
>>
>> /**
>> * __wait_for - magic wait macro
>> @@ -1001,6 +1002,7 @@ struct intel_hdmi {
>> bool has_audio;
>> bool rgb_quant_range_selectable;
>> struct intel_connector *attached_connector;
>> +struct cec_notifier *notifier;
>> };
>>
>> struct intel_dp_mst_encoder;
>> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
>> b/drivers/gpu/drm/i915/intel_hdmi.c
>> index 1baef4a..9b94d72 100644
>> --- a/drivers/gpu/drm/i915/intel_hdmi.c
>> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
>> @@ -1868,6 +1868,8 @@ intel_hdmi_set_edid(struct drm_connector *connector)
>> connected = true;
>> }
>>
>> +cec_notifier_set_phys_addr_from_edid(intel_hdmi->notifier, edid);
>> +
>> return connected;
>> }
>>
>> @@ -1876,6 +1878,7 @@ intel_hdmi_detect(struct drm_connector *connector,
>> bool force)
>> {
>> enum drm_connector_status status;
>> struct drm_i915_private *dev_priv = to_i915(connector->dev);
>> +struct intel_hdmi *intel_hdmi = intel_attached_hdmi(connector);
>>
>> DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n",
>>connector->base.id, connector->name);
>> @@ -1891,6 +1894,9 @@ intel_hdmi_detect(struct drm_connector *connector,
>> bool force)
>>
>> intel_display_power_put(dev_priv, POWER_DOMAIN_GMBUS);
>>
>> +if (status != connector_status_connected)
>> +cec_notifier_phys_addr_invalidate(intel_hdmi->notifier);
>> +
>> return status;
>> }
>>
>> @@ -2358,6 +2364,10 @@ void intel_hdmi_init_connector(struct
>> intel_digital_port *intel_dig_port,
>> u32 temp = I915_READ(PEG_BAND_GAP_DATA);
>> I915_WRITE(PEG_BAND_GAP_DATA, (temp & ~0xf) | 0xd);
>> }
>> +
>> +intel_hdmi->notifier = cec_notifier_get_conn(dev->dev, connector->name);
>> +if (!intel_hdmi->notifier)
>> +DRM_DEBUG_KMS("CEC notifier get failed\n");
>
> You 'get' the notifier here, but where is the cec_notifier_put when the
> connector is deleted?
Because I failed to find a safe place for this !
I will have a second look...
>
> Regards,
>
> Hans
>
>> }
>>
>> void intel_hdmi_init(struct drm_i915_private *dev_priv,
>>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106522] QA Notice
https://bugs.freedesktop.org/show_bug.cgi?id=106522 Michel Dänzer changed: What|Removed |Added QA Contact|mesa-dev@lists.freedesktop. |dri-devel@lists.freedesktop |org |.org Component|Drivers/X11 |Drivers/Gallium/radeonsi Assignee|mesa-dev@lists.freedesktop. |dri-devel@lists.freedesktop |org |.org -- 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
Re: [PATCH v2 2/2] drm/bridge: sii902x: add optional power supplies
Hi Philippe, On Monday, 14 May 2018 21:58:48 EEST Philippe CORNU wrote: > On 05/14/2018 12:33 PM, Andrzej Hajda wrote: > > On 14.05.2018 11:38, Philippe CORNU wrote: > >> On 04/25/2018 09:53 AM, Philippe Cornu wrote: > >>> Add the optional power supplies using the description found in > >>> "SiI9022A/SiI9024A HDMI Transmitter Data Sheet (August 2016)". > >>> > >>> The sii902x input IOs are not "io safe" so it is important to > >>> enable/disable voltage regulators during probe/remove phases to > >>> avoid damages. > > > > What exactly does it mean? Ie I understand that the chip has some > > limitations, but why enabling/disabling regulators in probe/remove > > should solve it? > > thank you for your comment. > > And sorry for the "bad" explanation in the 2nd paragraph about the fact > that inputs are not "io safe". I added this 2nd paragraph in v2 > following a good comment from Laurent on adding the management of the > regulators outside the probe/remove for a better power consumption > management (enable/disable regulators only when the ic is used for > displaying something for instance...). But after a deeper analysis, I > realized that the only way to improve the power consumption is to > implement & test the sii902x various sleep modes, that is out-of-scope > of this small patch and also out-of-scope of my test board I use on > which the sii902x bridge ic power consumption is very low compare to the > rest of the system... > > I will remove this "explanation" in v3 as it creates confusion. I'd rather keep it and expand it explain why enabling/disabling regulators at probe/remove solves the problem. Your patch otherwise looks OK (although if you submit a v3 anyway you could also rename err_disable_regulator to err_disable_regulators). > >>> Signed-off-by: Philippe Cornu > >>> --- > >>> > >>> drivers/gpu/drm/bridge/sii902x.c | 38 ++ > >>> 1 file changed, 34 insertions(+), 4 deletions(-) -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 5/5] media: platform: Add Chrome OS EC CEC driver
On 05/15/18 09:25, Neil Armstrong wrote:
> Hi Hans,
>
> Thanks for the extensive review.
>
> On 15/05/2018 08:58, Hans Verkuil wrote:
>> On 05/15/2018 12:40 AM, Neil Armstrong wrote:
>>> The Chrome OS Embedded Controller can expose a CEC bus, this patch add the
>>> driver for such feature of the Embedded Controller.
>>>
>>> This driver is part of the cros-ec MFD and will be add as a sub-device when
>>> the feature bit is exposed by the EC.
>>>
>>> The controller will only handle a single logical address and handles
>>> all the messages retries and will only expose Success or Error.
>>>
>>> When the logical address is invalid, the controller will act as a CEC
>>> sniffer
>>> and transfer all messages on the bus.
>>
>> I did not see any support for this. If this works as you state here, then
>> adding
>> support for CEC_CAP_MONITOR_ALL is highly recommended.
>
> Oops, I forgot to remove this phrase, the FW will maybe support it, but it
> has been
> dropped for the first revision.
>
>>
>>>
>>> Signed-off-by: Neil Armstrong
>>> ---
>>> drivers/media/platform/Kconfig | 11 +
>>> drivers/media/platform/Makefile | 2 +
>>> drivers/media/platform/cros-ec/Makefile | 1 +
>>> drivers/media/platform/cros-ec/cros-ec-cec.c | 331
>>> +++
>>> 4 files changed, 345 insertions(+)
>>> create mode 100644 drivers/media/platform/cros-ec/Makefile
>>> create mode 100644 drivers/media/platform/cros-ec/cros-ec-cec.c
>>
>> Shouldn't the directory be called cros-ec-cec?
>>
>>>
>>> diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
>>> index c7a1cf8..e55a8ed2 100644
>>> --- a/drivers/media/platform/Kconfig
>>> +++ b/drivers/media/platform/Kconfig
>>> @@ -546,6 +546,17 @@ menuconfig CEC_PLATFORM_DRIVERS
>>>
>>> if CEC_PLATFORM_DRIVERS
>>>
>>> +config VIDEO_CROS_EC_CEC
>>> + tristate "Chrome OS EC CEC driver"
>>> + depends on MFD_CROS_EC || COMPILE_TEST
>>> + select CEC_CORE
>>> + select CEC_NOTIFIER
>>> + ---help---
>>> + If you say yes here you will get support for the
>>> + Chrome OS Embedded Controller's CEC.
>>> + The CEC bus is present in the HDMI connector and enables communication
>>> + between compatible devices.
>>> +
>>> config VIDEO_MESON_AO_CEC
>>> tristate "Amlogic Meson AO CEC driver"
>>> depends on ARCH_MESON || COMPILE_TEST
>>> diff --git a/drivers/media/platform/Makefile
>>> b/drivers/media/platform/Makefile
>>> index 932515d..0e0582e 100644
>>> --- a/drivers/media/platform/Makefile
>>> +++ b/drivers/media/platform/Makefile
>>> @@ -92,3 +92,5 @@ obj-$(CONFIG_VIDEO_QCOM_CAMSS)+=
>>> qcom/camss-8x16/
>>> obj-$(CONFIG_VIDEO_QCOM_VENUS) += qcom/venus/
>>>
>>> obj-y += meson/
>>> +
>>> +obj-y += cros-ec/
>>> diff --git a/drivers/media/platform/cros-ec/Makefile
>>> b/drivers/media/platform/cros-ec/Makefile
>>> new file mode 100644
>>> index 000..9ce97f9
>>> --- /dev/null
>>> +++ b/drivers/media/platform/cros-ec/Makefile
>>> @@ -0,0 +1 @@
>>> +obj-$(CONFIG_VIDEO_CROS_EC_CEC) += cros-ec-cec.o
>>> diff --git a/drivers/media/platform/cros-ec/cros-ec-cec.c
>>> b/drivers/media/platform/cros-ec/cros-ec-cec.c
>>> new file mode 100644
>>> index 000..fea90da
>>> --- /dev/null
>>> +++ b/drivers/media/platform/cros-ec/cros-ec-cec.c
>>> @@ -0,0 +1,331 @@
>>> +// SPDX-License-Identifier: GPL-2.0+
>>> +/*
>>> + * CEC driver for Chrome OS Embedded Controller
>>> + *
>>> + * Copyright (c) 2018 BayLibre, SAS
>>> + * Author: Neil Armstrong
>>> + */
>>> +
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +
>>> +#define DRV_NAME "cros-ec-cec"
>>> +
>>> +/**
>>> + * struct cros_ec_cec - Driver data for EC CEC
>>> + *
>>> + * @cros_ec: Pointer to EC device
>>> + * @notifier: Notifier info for responding to EC events
>>> + * @adap: CEC adapter
>>> + * @notify: CEC notifier pointer
>>> + * @rc_msg: storage for a received message
>>> + */
>>> +struct cros_ec_cec {
>>> + struct cros_ec_device *cros_ec;
>>> + struct notifier_block notifier;
>>> + struct cec_adapter *adap;
>>> + struct cec_notifier *notify;
>>> + struct cec_msg rx_msg;
>>> +};
>>> +
>>> +static void handle_cec_message(struct cros_ec_cec *cros_ec_cec)
>>> +{
>>> + struct cros_ec_device *cros_ec = cros_ec_cec->cros_ec;
>>> + uint8_t *cec_message = cros_ec->event_data.data.cec_message;
>>> + unsigned int len = cros_ec->event_size;
>>> +
>>> + cros_ec_cec->rx_msg.len = len;
>>
>> How robust is the underlying code and hardware? What happens if a
>> CEC message with more than 16 bytes is received?
>>
>> Hard to test unless you have an RPi3 set up as a CEC debugger. See
>> last section in https://hverkuil.home.xs4all.nl/cec-status.txt.
>>
>> Since you worked with CEC for a while now I recommend you set up s
Re: [RFC PATCH 5/5] media: platform: Add Chrome OS EC CEC driver
On 15/05/2018 10:10, Hans Verkuil wrote:
> On 05/15/18 09:25, Neil Armstrong wrote:
>> Hi Hans,
>>
>> Thanks for the extensive review.
>>
>> On 15/05/2018 08:58, Hans Verkuil wrote:
>>> On 05/15/2018 12:40 AM, Neil Armstrong wrote:
The Chrome OS Embedded Controller can expose a CEC bus, this patch add the
driver for such feature of the Embedded Controller.
This driver is part of the cros-ec MFD and will be add as a sub-device when
the feature bit is exposed by the EC.
The controller will only handle a single logical address and handles
all the messages retries and will only expose Success or Error.
When the logical address is invalid, the controller will act as a CEC
sniffer
and transfer all messages on the bus.
>>>
>>> I did not see any support for this. If this works as you state here, then
>>> adding
>>> support for CEC_CAP_MONITOR_ALL is highly recommended.
>>
>> Oops, I forgot to remove this phrase, the FW will maybe support it, but it
>> has been
>> dropped for the first revision.
>>
>>>
Signed-off-by: Neil Armstrong
---
drivers/media/platform/Kconfig | 11 +
drivers/media/platform/Makefile | 2 +
drivers/media/platform/cros-ec/Makefile | 1 +
drivers/media/platform/cros-ec/cros-ec-cec.c | 331
+++
4 files changed, 345 insertions(+)
create mode 100644 drivers/media/platform/cros-ec/Makefile
create mode 100644 drivers/media/platform/cros-ec/cros-ec-cec.c
>>>
>>> Shouldn't the directory be called cros-ec-cec?
Forgot this one, moved to cros-ec-cec directory.
>>>
diff --git a/drivers/media/platform/Kconfig
b/drivers/media/platform/Kconfig
index c7a1cf8..e55a8ed2 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -546,6 +546,17 @@ menuconfig CEC_PLATFORM_DRIVERS
if CEC_PLATFORM_DRIVERS
+config VIDEO_CROS_EC_CEC
+ tristate "Chrome OS EC CEC driver"
+ depends on MFD_CROS_EC || COMPILE_TEST
+ select CEC_CORE
+ select CEC_NOTIFIER
+ ---help---
+If you say yes here you will get support for the
+Chrome OS Embedded Controller's CEC.
+The CEC bus is present in the HDMI connector and enables communication
+between compatible devices.
+
config VIDEO_MESON_AO_CEC
tristate "Amlogic Meson AO CEC driver"
depends on ARCH_MESON || COMPILE_TEST
diff --git a/drivers/media/platform/Makefile
b/drivers/media/platform/Makefile
index 932515d..0e0582e 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -92,3 +92,5 @@ obj-$(CONFIG_VIDEO_QCOM_CAMSS) +=
qcom/camss-8x16/
obj-$(CONFIG_VIDEO_QCOM_VENUS)+= qcom/venus/
obj-y += meson/
+
+obj-y += cros-ec/
diff --git a/drivers/media/platform/cros-ec/Makefile
b/drivers/media/platform/cros-ec/Makefile
new file mode 100644
index 000..9ce97f9
--- /dev/null
+++ b/drivers/media/platform/cros-ec/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_VIDEO_CROS_EC_CEC) += cros-ec-cec.o
diff --git a/drivers/media/platform/cros-ec/cros-ec-cec.c
b/drivers/media/platform/cros-ec/cros-ec-cec.c
new file mode 100644
index 000..fea90da
--- /dev/null
+++ b/drivers/media/platform/cros-ec/cros-ec-cec.c
@@ -0,0 +1,331 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * CEC driver for Chrome OS Embedded Controller
+ *
+ * Copyright (c) 2018 BayLibre, SAS
+ * Author: Neil Armstrong
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define DRV_NAME "cros-ec-cec"
+
+/**
+ * struct cros_ec_cec - Driver data for EC CEC
+ *
+ * @cros_ec: Pointer to EC device
+ * @notifier: Notifier info for responding to EC events
+ * @adap: CEC adapter
+ * @notify: CEC notifier pointer
+ * @rc_msg: storage for a received message
+ */
+struct cros_ec_cec {
+ struct cros_ec_device *cros_ec;
+ struct notifier_block notifier;
+ struct cec_adapter *adap;
+ struct cec_notifier *notify;
+ struct cec_msg rx_msg;
+};
+
+static void handle_cec_message(struct cros_ec_cec *cros_ec_cec)
+{
+ struct cros_ec_device *cros_ec = cros_ec_cec->cros_ec;
+ uint8_t *cec_message = cros_ec->event_data.data.cec_message;
+ unsigned int len = cros_ec->event_size;
+
+ cros_ec_cec->rx_msg.len = len;
>>>
>>> How robust is the underlying code and hardware? What happens if a
>>> CEC message with more than 16 bytes is received?
Re: [RFC PATCH 5/5] media: platform: Add Chrome OS EC CEC driver
On 05/15/18 10:28, Neil Armstrong wrote:
> + int ret;
> +
> + cros_ec_cec = devm_kzalloc(&pdev->dev, sizeof(*cros_ec_cec),
> +GFP_KERNEL);
> + if (!cros_ec_cec)
> + return -ENOMEM;
> +
> + platform_set_drvdata(pdev, cros_ec_cec);
> + cros_ec_cec->cros_ec = cros_ec;
> +
> + ret = cros_ec_cec_get_notifier(&cros_ec_cec->notify);
> + if (ret) {
> + dev_warn(&pdev->dev, "no CEC notifier available\n");
> + cec_caps |= CEC_CAP_PHYS_ADDR;
Can this happen? What hardware has this? I am strongly opposed to CEC
drivers
using this capability unless there is no other option. It's a pain for
userspace.
>>>
>>> It's in case an HW having a CEC capable FW but not in the
>>> cec_dmi_match_table, in this case
>>> it won't fail but still enable the CEC interface without a notifier.
>>
>> I don't think that's a good idea. CAP_PHYS_ADDR should *only* be used in
>> situations
>> where it is truly impossible to tell which output is connected to the CEC
>> adapter.
>> That's the case with e.g. USB CEC dongles where you have no idea how the user
>> connected the HDMI cables.
>>
>> But I assume that in this case it just means that the cec_dmi_match_table
>> needs
>> to be updated, i.e. it is a driver bug.
>
> Yep, maybe a dev_warn should be added to notify this bug ?
Yes, a dev_warn and then return -ENODEV.
>
>>
>> Another thing: this driver assumes that there is only one CEC adapter for
>> only
>> one HDMI output. But what if there are more HDMI outputs? Will there be one
>> CEC adapter for each output? Or does the hardware have no provisions for
>> that?
>
> The current EC interface only exposes a single CEC interface for now, there
> is no
> plan yet for multiple HDMI outputs handling.
>
>>
>> Something should be mentioned about this in a comment.
>
> Ok
Thanks!
Hans
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH][next] drm/xen-front: fix spelling mistake: "conector" -> "connector"
From: Colin Ian King
Trivial fix to spelling mistake in DRM_INFO message.
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/xen/xen_drm_front.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/xen/xen_drm_front.c
b/drivers/gpu/drm/xen/xen_drm_front.c
index 0e486cb1c10c..3725de4c4da8 100644
--- a/drivers/gpu/drm/xen/xen_drm_front.c
+++ b/drivers/gpu/drm/xen/xen_drm_front.c
@@ -623,7 +623,7 @@ static int displback_initwait(struct xen_drm_front_info
*front_info)
if (ret < 0)
return ret;
- DRM_INFO("Have %d conector(s)\n", cfg->num_connectors);
+ DRM_INFO("Have %d connector(s)\n", cfg->num_connectors);
/* Create event channels for all connectors and publish */
ret = xen_drm_front_evtchnl_create_all(front_info);
if (ret < 0)
--
2.17.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: linux-next: Signed-off-by missing for commits in the drm-intel tree
On Tue, 15 May 2018, Stephen Rothwell wrote:
> Hi all,
>
> Commits
>
> cb8ba171ae6c ("drm/i915/gvt: let force_to_nonpriv cmd handler only valid
> for LRI cmd")
> 0438a1059877 ("drm/i915/gvt: do not return error on handling
> force_to_nonpriv registers")
> 3d8b9e258b9d ("drm/i915/gvt: let NOPID be the default value of
> force_to_nonpriv registers")
> b99f514f5dfa ("drm/i915/gvt: Remove disable_warn_untrack and print
> untracked mmio with debug level")
>
> are missing a Signed-off-by from their committer.
Zhi's rebase fail leading to change of committer that I failed to
reject. :(
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH rdma-next 01/21] drm/i915: Move u64-to-ptr helpers to general header
On Mon, May 14, 2018 at 02:10:54PM -0600, Jason Gunthorpe wrote: > On Thu, May 03, 2018 at 04:36:55PM +0300, Leon Romanovsky wrote: > > From: Leon Romanovsky > > > > The macro u64_to_ptr() and function ptr_to_u64() are useful enough > > to be part of general header, so move them there and allow RDMA > > subsystem reuse them. > > > > Signed-off-by: Leon Romanovsky > > --- > > drivers/gpu/drm/i915/i915_utils.h | 12 ++-- > > include/linux/kernel.h| 12 > > 2 files changed, 14 insertions(+), 10 deletions(-) > > This patch and the next one to kernel.h will need to be Ack'd be > someone.. But I am not sure who.. AndrewM perhaps? Why is that? The kernel.h doesn't have explicit maintainer and is managed by community effort. Thanks > > Jason signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH][next] drm/xen-front: fix spelling mistake: "conector" -> "connector"
On 05/15/2018 11:54 AM, Colin King wrote:
From: Colin Ian King
Trivial fix to spelling mistake in DRM_INFO message.
Signed-off-by: Colin Ian King
Thank you,
Reviewed-by: Oleksandr Andrushchenko
Will apply to drm-misc-next
---
drivers/gpu/drm/xen/xen_drm_front.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/xen/xen_drm_front.c
b/drivers/gpu/drm/xen/xen_drm_front.c
index 0e486cb1c10c..3725de4c4da8 100644
--- a/drivers/gpu/drm/xen/xen_drm_front.c
+++ b/drivers/gpu/drm/xen/xen_drm_front.c
@@ -623,7 +623,7 @@ static int displback_initwait(struct xen_drm_front_info
*front_info)
if (ret < 0)
return ret;
- DRM_INFO("Have %d conector(s)\n", cfg->num_connectors);
+ DRM_INFO("Have %d connector(s)\n", cfg->num_connectors);
/* Create event channels for all connectors and publish */
ret = xen_drm_front_evtchnl_create_all(front_info);
if (ret < 0)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 199693] System freeze after resuming from suspend (amdgpu)
https://bugzilla.kernel.org/show_bug.cgi?id=199693 Thomas Martitz (ku...@rockbox.org) changed: What|Removed |Added Status|RESOLVED|REOPENED CC||ku...@rockbox.org Resolution|DUPLICATE |--- --- Comment #2 from Thomas Martitz (ku...@rockbox.org) --- This is not the same as bug 199609 I'm afraid. This bug describes a behavior where the very first resume. However, if I make a fix (I'll post it later this day hopefully) for this bug, then I start seeing bug 199609 too. In fact, amdgpu developers asked me to file a bug report against the kernel while bug 199609 was moved to amdgpu. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 199693] System freeze after resuming from suspend (amdgpu)
https://bugzilla.kernel.org/show_bug.cgi?id=199693 Thomas Martitz (ku...@rockbox.org) changed: What|Removed |Added Kernel Version|v4.17-rc4 |v4.17-rc5 -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 199693] System freeze after resuming from suspend (amdgpu)
https://bugzilla.kernel.org/show_bug.cgi?id=199693 Thomas Martitz (ku...@rockbox.org) changed: What|Removed |Added Component|Video(DRI - non Intel) |Hibernation/Suspend Product|Drivers |Power Management -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 5/5] drm/arm/malidp: Added the late system pm functions
On 5/14/2018 12:01 PM, Ayan Halder wrote: On Wed, Apr 25, 2018 at 01:49:35PM +0200, Daniel Vetter wrote: Hi Daniel, On Wed, Apr 25, 2018 at 1:26 PM, Liviu Dudau wrote: On Wed, Apr 25, 2018 at 09:17:22AM +0200, Daniel Vetter wrote: On Tue, Apr 24, 2018 at 07:12:47PM +0100, Ayan Kumar Halder wrote: malidp_pm_suspend_late checks if the runtime status is not suspended and if so, invokes malidp_runtime_pm_suspend which disables the display engine/core interrupts and the clocks. It sets the runtime status as suspended. The difference between suspend() and suspend_late() is as follows:- 1. suspend() makes the device quiescent. In our case, we invoke the DRM helper which disables the CRTC. This would have invoked runtime pm suspend but the system suspend process disables runtime pm. 2. suspend_late() It continues the suspend operations of the drm device which was started by suspend(). In our case, it performs the same functionality as runtime_suspend(). The complimentary functions are resume() and resume_early(). In the case of resume_early(), we invoke malidp_runtime_pm_resume() which enables the clocks and the interrupts. It sets the runtime status as active. If the device was in runtime suspend mode before system suspend was called, pm_runtime_work() will put the device back in runtime suspended mode( after the complete system has been resumed). Signed-off-by: Ayan Kumar Halder Afaiui we still haven't bottomed out on the discussion on v1. Did you get hold of Rafael? No, there was no reply from him. Lets try again: Rafael, we are debating on what the proper approach is for handling the suspend/resume callbacks for a DRM driver that is likely to not be runtime suspended when the power-down happens (because we are driving the display output). We are using in this patch the LATE_SYSTEM_SLEEP_PM_OPS in order to do the work that we also do during runtime suspend, which is turning off the output and the clocks driving it. The reason for doing that is because the PM core takes a runtime reference during system suspend for all devices that are not already runtime suspended, so our runtime_pm_suspend() hook is never called. Daniel's argument is that we should not be doing this from LATE hooks, but from the normal suspend hooks, however kernel doc seems to suggest otherwise. For more context: I thought the reason behind the recommendation to stuff the rpm callbacks into the late/early hooks was to solve cross-device ordering issues. That way everyone shuts down the device functionality in the normal hooks, but only powers them off in the late hook (to allow other drivers to keep using the clock/i2c master/whatever). But we now have device_link to solve that since a while, so I'm not sure the recommendation to stuff the rpm hooks into late/early callbacks is still correct. -Daniel It has been more than two weeks and we have not got any response from Rafael. Can you ping him personally or suggest any way by which ask him to respond? It is in my queue though, sorry for the delay. It would help if you resent the series with a CC to linux...@vger.kernel.org as it would be easier for me to review it then. Thanks, Rafael ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] drm-intel-next
Hi Dave - So this one contains the problematic pull from gvt. It's got both a backmerge and a rebase. I spotted the rebase, but intentionally let it slide due to the deadline closing, and then completely missed the backmerge. I don't know what I was thinking. My bad, sorry. We'll need to improve our workflows with the gvt team. Anyway, here's the pull, wrinkles and all, as discussed on IRC. Let us know if you can tolerate it, or if we need to rewrite history. BR, Jani. PS. Regarding the changelog, Vidya Srinivas had a huge role in the NV12 work, but alas I failed to give proper credit because the patches were based on earlier work by Chandra. drm-intel-next-2018-05-14: Last drm/i915 changes for v4.18: - NV12 enabling (Chandra, Maarten) - ICL workarounds (Oscar) - ICL basic DPLL enabling (Paulo) - GVT updates - DP link config refactoring (Jani) - Module parameter to override DMC firmware (Jani) - PSR updates (José, DK, Daniel, Ville) - ICL DP vswing programming (Manasi) - ICL DBuf slice updates (Mahesh) - Selftest fixes and updates (Chris, Matthew, Oscar) - Execlist fixes and updates (Chris) - Stolen memory first 4k fix (Hans de Goede) - wait_for fixes (Mika) - Tons of GEM improvements (Chris) - Plenty of other fixes and improvements (Everyone) - Crappy changelog (Me) BR, Jani. The following changes since commit 0ab390262c4920f26f8202063a268d5fc829728e: Merge tag 'drm-misc-next-2018-04-26' of git://anongit.freedesktop.org/drm/drm-misc into drm-next (2018-04-30 09:32:43 +1000) are available in the git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-2018-05-14 for you to fetch changes up to 01f83786f9ab9c8883ce634cb9a0de51086ad7ea: drm/i915: Update DRIVER_DATE to 20180514 (2018-05-14 15:28:05 +0300) Last drm/i915 changes for v4.18: - NV12 enabling (Chandra, Maarten) - ICL workarounds (Oscar) - ICL basic DPLL enabling (Paulo) - GVT updates - DP link config refactoring (Jani) - Module parameter to override DMC firmware (Jani) - PSR updates (José, DK, Daniel, Ville) - ICL DP vswing programming (Manasi) - ICL DBuf slice updates (Mahesh) - Selftest fixes and updates (Chris, Matthew, Oscar) - Execlist fixes and updates (Chris) - Stolen memory first 4k fix (Hans de Goede) - wait_for fixes (Mika) - Tons of GEM improvements (Chris) - Plenty of other fixes and improvements (Everyone) - Crappy changelog (Me) Abhay Kumar (1): drm/i915/audio: set minimum CD clock to twice the BCLK Andy Shevchenko (1): i915: Convert to use match_string() helper Anusha Srivatsa (1): drm/i915/firmware: Correct URL for firmware Chandra Konduru (3): drm/i915: Add NV12 support to intel_framebuffer_init drm/i915: Add NV12 as supported format for primary plane drm/i915: Add NV12 as supported format for sprite plane Changbin Du (1): drm/i915/gvt: Remove disable_warn_untrack and print untracked mmio with debug level Chris Wilson (53): drm/i915: Check whitelist registers across resets drm/i915: Call i915_perf_fini() on init_hw error unwind drm/i915: Move the priotree struct to its own headers drm/i915: Rename priotree to sched drm/i915: Pack params to engine->schedule() into a struct drm/i915: Build request info on stack before printk drm/i915: Don't dump umpteen thousand requests drm/i915: Skip printing global offsets for per-engine scratch pages drm/i915/breadcrumbs: Keep the fake irq armed across reset drm/i915: Use memset64() to align the ring with MI_NOOP drm/i915: Remove obsolete min/max freq setters from debugfs drm/i915: Compile out engine debug for release drm/i915/selftests: Wait for idle between idle resets as well drm/i915/lrc: Scrub the GPU state of the guilty hanging request drm/i915: Stop tracking timeline->inflight_seqnos drm/i915: Wrap engine->context_pin() and engine->context_unpin() drm/i915: Retire requests along rings drm/i915: Only track live rings for retiring drm/i915/execlists: Don't trigger preemption if complete drm/i915/selftests: Fix error checking for wait_var_timeout drm/i915: Show ring->start for the ELSP context/request queue drm/i915/guc: Assert we have the doorbell before setting it up drm/i915: Move timeline from GTT to ring drm/i915: Split i915_gem_timeline into individual timelines drm/i915/execlists: Emit i915_trace_request_out for preemption drm/i915: Silence debugging DRM_ERROR for failing to suspend vlv powerwells drm/i915: Reset the hangcheck timestamp before repeating a seqno drm/i915: Mark the hangcheck as idle when unparking the engines drm/i915: Lazily unbind vma on close drm/i915: Keep one request in our ring_list drm/i915/execlists: Drop preemption arbitrations points along the ring
RE: [PULL] drm-intel-next
> -Original Message- > From: Nikula, Jani > Sent: Tuesday, May 15, 2018 3:26 PM > To: Dave Airlie > Cc: Daniel Vetter ; Jani Nikula > ; Joonas Lahtinen > ; Vivi, Rodrigo ; > Sean Paul ; Gustavo Padovan > ; Maarten Lankhorst > ; dri-devel@lists.freedesktop.org; > intel-...@lists.freedesktop.org; dim-to...@lists.freedesktop.org; Wang, Zhi > A ; Zhenyu Wang ; > Srinivas, Vidya > Subject: [PULL] drm-intel-next > > > Hi Dave - > > So this one contains the problematic pull from gvt. It's got both a backmerge > and a rebase. I spotted the rebase, but intentionally let it slide due to the > deadline closing, and then completely missed the backmerge. I don't know > what I was thinking. My bad, sorry. > > We'll need to improve our workflows with the gvt team. > > Anyway, here's the pull, wrinkles and all, as discussed on IRC. Let us know if > you can tolerate it, or if we need to rewrite history. > > BR, > Jani. > > > PS. Regarding the changelog, Vidya Srinivas had a > huge role in the NV12 work, but alas I failed to give proper credit because > the > patches were based on earlier work by Chandra. No problem at all :) Sincerely, Thank you so much. It was based on Chandra's original work and without Maarten It would never reach the merge stage :) > > > drm-intel-next-2018-05-14: > Last drm/i915 changes for v4.18: > > - NV12 enabling (Chandra, Maarten) > - ICL workarounds (Oscar) > - ICL basic DPLL enabling (Paulo) > - GVT updates > - DP link config refactoring (Jani) > - Module parameter to override DMC firmware (Jani) > - PSR updates (José, DK, Daniel, Ville) > - ICL DP vswing programming (Manasi) > - ICL DBuf slice updates (Mahesh) > - Selftest fixes and updates (Chris, Matthew, Oscar) > - Execlist fixes and updates (Chris) > - Stolen memory first 4k fix (Hans de Goede) > - wait_for fixes (Mika) > - Tons of GEM improvements (Chris) > - Plenty of other fixes and improvements (Everyone) > - Crappy changelog (Me) > > BR, > Jani. > > The following changes since commit > 0ab390262c4920f26f8202063a268d5fc829728e: > > Merge tag 'drm-misc-next-2018-04-26' of > git://anongit.freedesktop.org/drm/drm-misc into drm-next (2018-04-30 > 09:32:43 +1000) > > are available in the git repository at: > > git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-2018-05- > 14 > > for you to fetch changes up to 01f83786f9ab9c8883ce634cb9a0de51086ad7ea: > > drm/i915: Update DRIVER_DATE to 20180514 (2018-05-14 15:28:05 +0300) > > > Last drm/i915 changes for v4.18: > > - NV12 enabling (Chandra, Maarten) > - ICL workarounds (Oscar) > - ICL basic DPLL enabling (Paulo) > - GVT updates > - DP link config refactoring (Jani) > - Module parameter to override DMC firmware (Jani) > - PSR updates (José, DK, Daniel, Ville) > - ICL DP vswing programming (Manasi) > - ICL DBuf slice updates (Mahesh) > - Selftest fixes and updates (Chris, Matthew, Oscar) > - Execlist fixes and updates (Chris) > - Stolen memory first 4k fix (Hans de Goede) > - wait_for fixes (Mika) > - Tons of GEM improvements (Chris) > - Plenty of other fixes and improvements (Everyone) > - Crappy changelog (Me) > > > Abhay Kumar (1): > drm/i915/audio: set minimum CD clock to twice the BCLK > > Andy Shevchenko (1): > i915: Convert to use match_string() helper > > Anusha Srivatsa (1): > drm/i915/firmware: Correct URL for firmware > > Chandra Konduru (3): > drm/i915: Add NV12 support to intel_framebuffer_init > drm/i915: Add NV12 as supported format for primary plane > drm/i915: Add NV12 as supported format for sprite plane > > Changbin Du (1): > drm/i915/gvt: Remove disable_warn_untrack and print untracked mmio > with debug level > > Chris Wilson (53): > drm/i915: Check whitelist registers across resets > drm/i915: Call i915_perf_fini() on init_hw error unwind > drm/i915: Move the priotree struct to its own headers > drm/i915: Rename priotree to sched > drm/i915: Pack params to engine->schedule() into a struct > drm/i915: Build request info on stack before printk > drm/i915: Don't dump umpteen thousand requests > drm/i915: Skip printing global offsets for per-engine scratch pages > drm/i915/breadcrumbs: Keep the fake irq armed across reset > drm/i915: Use memset64() to align the ring with MI_NOOP > drm/i915: Remove obsolete min/max freq setters from debugfs > drm/i915: Compile out engine debug for release > drm/i915/selftests: Wait for idle between idle resets as well > drm/i915/lrc: Scrub the GPU state of the guilty hanging request > drm/i915: Stop tracking timeline->inflight_seqnos > drm/i915: Wrap engine->context_pin() and engine->context_unpin() > drm/i915: Retire requests along rings > drm/i915: Only track live rings for retiring > drm/i915/execlist
[PATCH v2] drm: mali-dp: Add debugfs file for reporting internal errors
Status register contains a lot of bits for reporting internal errors
inside Mali DP. Currently, we just silently ignore all of the errors,
that doesn't help when we are investigating different bugs, especially
on the FPGA models which have a lot of constraints, so we could easily
end up in AXI or underrun errors.
Add a new file called debug that contains an aggregate of the
errors reported by the Mali DP hardware.
E.g:
[root@alarm ~]# cat /sys/kernel/debug/dri/1/debug
[DE] num_errors : 167
[DE] last_error_status : 0x0001
[DE] last_error_vblank : 385
[SE] num_errors : 3
[SE] last_error_status : 0x00e23001
[SE] last_error_vblank : 201
Changes since v2:
- Add lock to protect the errors stats.
- Add possibility to reset the error stats by writing anything to the
debug file.
Signed-off-by: Alexandru Gheorghe
---
drivers/gpu/drm/arm/malidp_drv.c | 104 ++
drivers/gpu/drm/arm/malidp_drv.h | 19 +++
drivers/gpu/drm/arm/malidp_hw.c | 46 ++---
drivers/gpu/drm/arm/malidp_hw.h | 1 +
drivers/gpu/drm/arm/malidp_regs.h | 6 +++
5 files changed, 169 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index 8d20faa..8bfeb46 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include
#include
@@ -327,6 +328,106 @@ static int malidp_dumb_create(struct drm_file *file_priv,
return drm_gem_cma_dumb_create_internal(file_priv, drm, args);
}
+#ifdef CONFIG_DEBUG_FS
+
+static void malidp_error_stats_init(struct malidp_error_stats *error_stats)
+{
+ error_stats->num_errors = 0;
+ error_stats->last_error_status = 0;
+ error_stats->last_error_vblank = -1;
+}
+
+void malidp_error(struct malidp_drm *malidp,
+ struct malidp_error_stats *error_stats, u32 status,
+ u64 vblank)
+{
+ unsigned long irqflags;
+
+ spin_lock_irqsave(&malidp->errors_lock, irqflags);
+ error_stats->last_error_status = status;
+ error_stats->last_error_vblank = vblank;
+ error_stats->num_errors++;
+ spin_unlock_irqrestore(&malidp->errors_lock, irqflags);
+}
+
+void malidp_error_stats_dump(const char *prefix,
+struct malidp_error_stats error_stats,
+struct seq_file *m)
+{
+ seq_printf(m, "[%s] num_errors : %d\n", prefix,
+ error_stats.num_errors);
+ seq_printf(m, "[%s] last_error_status : 0x%08x\n", prefix,
+ error_stats.last_error_status);
+ seq_printf(m, "[%s] last_error_vblank : %lld\n", prefix,
+ error_stats.last_error_vblank);
+}
+
+static int malidp_show_stats(struct seq_file *m, void *arg)
+{
+ struct drm_device *drm = m->private;
+ struct malidp_drm *malidp = drm->dev_private;
+ unsigned long irqflags;
+ struct malidp_error_stats de_errors, se_errors;
+
+ spin_lock_irqsave(&malidp->errors_lock, irqflags);
+ de_errors = malidp->de_errors;
+ se_errors = malidp->se_errors;
+ spin_unlock_irqrestore(&malidp->errors_lock, irqflags);
+ malidp_error_stats_dump("DE", de_errors, m);
+ malidp_error_stats_dump("SE", se_errors, m);
+ return 0;
+}
+
+static int malidp_debugfs_open(struct inode *inode, struct file *file)
+{
+ return single_open(file, malidp_show_stats, inode->i_private);
+}
+
+static ssize_t malidp_debugfs_write(struct file *file, const char __user *ubuf,
+ size_t len, loff_t *offp)
+{
+ struct seq_file *m = file->private_data;
+ struct drm_device *drm = m->private;
+ struct malidp_drm *malidp = drm->dev_private;
+ unsigned long irqflags;
+
+ spin_lock_irqsave(&malidp->errors_lock, irqflags);
+ malidp_error_stats_init(&malidp->de_errors);
+ malidp_error_stats_init(&malidp->se_errors);
+ spin_unlock_irqrestore(&malidp->errors_lock, irqflags);
+ return len;
+}
+
+static const struct file_operations malidp_debugfs_fops = {
+ .owner = THIS_MODULE,
+ .open = malidp_debugfs_open,
+ .read = seq_read,
+ .write = malidp_debugfs_write,
+ .llseek = seq_lseek,
+ .release = single_release,
+};
+
+static int malidp_debugfs_init(struct drm_minor *minor)
+{
+ struct malidp_drm *malidp = minor->dev->dev_private;
+ struct dentry *dentry = NULL;
+
+ malidp_error_stats_init(&malidp->de_errors);
+ malidp_error_stats_init(&malidp->se_errors);
+ spin_lock_init(&malidp->errors_lock);
+ dentry = debugfs_create_file("debug",
+S_IRUGO | S_IWUSR,
+minor->debugfs_root, minor->dev,
+&malidp_debugfs_fops);
+ if (!dentry) {
+ DRM_ERROR("Cannot create debug file\n");
+
Re: [PATCH 14/18] fbdev: modedb.c: fix a kernel-doc markup
On Monday, May 07, 2018 06:35:50 AM Mauro Carvalho Chehab wrote: > Use code blocks to avoid those warnings and make it look nicer. > > ./drivers/video/fbdev/core/modedb.c:647: WARNING: Inline strong > start-string without end-string. > ./drivers/video/fbdev/core/modedb.c:647: WARNING: Inline strong > start-string without end-string. > ./drivers/video/fbdev/core/modedb.c:647: WARNING: Inline strong > start-string without end-string. > ./drivers/video/fbdev/core/modedb.c:647: WARNING: Inline strong > start-string without end-string. > > Signed-off-by: Mauro Carvalho Chehab Acked-by: Bartlomiej Zolnierkiewicz Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 26/26] drm/bridge: establish a link between the bridge supplier and consumer
On Mon, May 14, 2018 at 10:40 PM, Peter Rosin wrote:
> On 2018-05-14 18:28, Daniel Vetter wrote:
>> On Fri, May 11, 2018 at 09:37:47AM +0200, Peter Rosin wrote:
>>> On 2018-05-10 10:10, Andrzej Hajda wrote:
On 04.05.2018 15:52, Peter Rosin wrote:
> If the bridge supplier is unbound, this will bring the bridge consumer
> down along with the bridge. Thus, there will no longer linger any
> dangling pointers from the bridge consumer (the drm_device) to some
> non-existent bridge supplier.
>
> Signed-off-by: Peter Rosin
> ---
> drivers/gpu/drm/drm_bridge.c | 18 ++
> include/drm/drm_bridge.h | 2 ++
> 2 files changed, 20 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> index 78d186b6831b..0259f0a3ff27 100644
> --- a/drivers/gpu/drm/drm_bridge.c
> +++ b/drivers/gpu/drm/drm_bridge.c
> @@ -26,6 +26,7 @@
> #include
>
> #include
> +#include
> #include
>
> #include "drm_crtc_internal.h"
> @@ -127,12 +128,25 @@ int drm_bridge_attach(struct drm_encoder *encoder,
> struct drm_bridge *bridge,
>if (bridge->dev)
>return -EBUSY;
>
> + if (encoder->dev->dev != bridge->odev) {
I wonder why device_link_add does not handle this case (self dependency)
silently as noop, as it seems to be a correct behavior.
>>>
>>> It's kind-of a silly corner-case though, so perfectly understandable
>>> that it isn't handled.
>>>
> + bridge->link = device_link_add(encoder->dev->dev,
> + bridge->odev, 0);
> + if (!bridge->link) {
> + dev_err(bridge->odev, "failed to link bridge to %s\n",
> + dev_name(encoder->dev->dev));
> + return -EINVAL;
> + }
> + }
> +
>bridge->dev = encoder->dev;
>bridge->encoder = encoder;
>
>if (bridge->funcs->attach) {
>ret = bridge->funcs->attach(bridge);
>if (ret < 0) {
> + if (bridge->link)
> + device_link_del(bridge->link);
> + bridge->link = NULL;
>bridge->dev = NULL;
>bridge->encoder = NULL;
>return ret;
> @@ -159,6 +173,10 @@ void drm_bridge_detach(struct drm_bridge *bridge)
>if (bridge->funcs->detach)
>bridge->funcs->detach(bridge);
>
> + if (bridge->link)
> + device_link_del(bridge->link);
> + bridge->link = NULL;
> +
>bridge->dev = NULL;
> }
>
> diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
> index b656e505d11e..804189c63a4c 100644
> --- a/include/drm/drm_bridge.h
> +++ b/include/drm/drm_bridge.h
> @@ -261,6 +261,7 @@ struct drm_bridge_timings {
> * @list: to keep track of all added bridges
> * @timings: the timing specification for the bridge, if any (may
> * be NULL)
> + * @link: drm consumer <-> bridge supplier
Nitpick: "<->" suggests symmetry, maybe "device link from drm consumer
to the bridge" would be better.
>>>
>>> I meant "<->" to indicate that the link is bidirectional, not that the
>>> relationship is in any way symmetric. I wasn't aware of any implication
>>> of a symmetric relationship when using "<->", do you have a reference?
>>> But I guess the different arrow notations in math are somewhat overloaded
>>> and that someone at some point must have used "<->" to indicate a
>>> symmetric relationship...
>>
>> Yeah I agree with Andrzej here, for me <-> implies a symmetric
>> relationship. Spelling it out like Andrzej suggested sounds like the
>> better idea.
>> -Daniel
>
> Ok, I guess that means I have to do a v3 after all. Or can this
> trivial documentation update be done by the committer? I hate to
> spam everyone with another volley...
>
> Or perhaps I should squash patches 2-23 that are all rather similar
> and mechanic? I separated them to allow for easier review from
> individual driver maintainers, but that didn't seem to happen
> anyway...
Do another volley of the full set, or in-reply-to to just replace the
patch that needs to be respun (but some people don't like that).
When resending just make sure you're picking up all the acks/r-bs you
have already.
-Daniel
> Cheers,
> Peter
>
>>
>>>
Anyway:
Reviewed-by: Andrzej Hajda
>>>
>>> Thanks!
>>>
>>> Cheers,
>>> Peter
>>>
--
Regards
Andrzej
> * @funcs: control functions
> * @driver_private: pointer to the bridge driver's internal context
> */
> @@ -271,6 +272,7 @@ struct drm_bridge {
>struct drm_bridge *next;
>struct list_head list;
>const struct drm_bridge_timings *timings;
> + struct device_link *link;
>
>const struc
Re: [PATCH v2 11/11] docs: fix broken references with multiple hints
On Wednesday, May 09, 2018 10:18:54 AM Mauro Carvalho Chehab wrote: > The script: > ./scripts/documentation-file-ref-check --fix-rst > > Gives multiple hints for broken references on some files. > Manually use the one that applies for some files. > > Signed-off-by: Mauro Carvalho Chehab Acked-by: Bartlomiej Zolnierkiewicz # for fbdev part Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] video: fbdev: fix spelling mistake: "frambuffer" -> "framebuffer"
On Tuesday, May 01, 2018 09:37:42 AM Colin King wrote: > From: Colin Ian King > > Trivial fix to spelling mistake in error messages > > Signed-off-by: Colin Ian King Patch queued for 4.18, thanks. Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] video: fbdev: nvidia: fix spelling mistake: "scaleing" -> "scaling"
On Tuesday, May 08, 2018 11:36:19 PM Colin King wrote: > From: Colin Ian King > > Trivial fix to spelling mistake in module parameter description text > > Signed-off-by: Colin Ian King Patch queued for 4.18, thanks. Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 09/21] arm64: dts: allwinner: a64: Add HDMI support
On Mon, May 14, 2018 at 04:01:15PM +0530, Jagan Teki wrote:
> On Mon, May 14, 2018 at 2:10 PM, Maxime Ripard
> wrote:
> > On Mon, May 14, 2018 at 02:03:36PM +0530, Jagan Teki wrote:
> >> On Wed, May 2, 2018 at 5:04 PM, Maxime Ripard
> >> wrote:
> >> > Hi,
> >> >
> >> > On Mon, Apr 30, 2018 at 05:10:46PM +0530, Jagan Teki wrote:
> >> >> + hdmi_phy: hdmi-phy@1ef {
> >> >> + compatible = "allwinner,sun50i-a64-hdmi-phy",
> >> >> + "allwinner,sun8i-h3-hdmi-phy";
> >> >> + reg = <0x01ef 0x1>;
> >> >> + clocks = <&ccu CLK_BUS_HDMI>, <&ccu CLK_HDMI_DDC>,
> >> >> + <&ccu CLK_PLL_VIDEO1>;
> >> >
> >> > You were discussing that the PLL0 could also be used to clock the PHY,
> >> > has that been figured out?
> >>
> >> This is what I understand from Fig: 3-3. Module Clock Diagram, both
> >> tcon0 and tcon1 are using HDMI. I'm thinking based on the tcon
> >> configuration we need use proper PLL or some logic to get common PLL
> >> don't know yet. Since this series adding tcon1 I've attached PLL1.
> >
> > You're not describing the TCON node here though, but the HDMI one, and
> > the HDMI block is listed in both the PLL video 0 and 1.
>
> So how can we attach particular PLL with particular HDMI(PLL0 to HDMI0
> and so-on) or do we need to attached both the PLL's any suggestion?
I'm not sure what your question is here, just add the possibility to
have an extra PLL if that makes sense to the binding.
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 PATCH 01/10] devfreq: rockchip-dfi: Move GRF definitions to a common place.
Hi Enric,
On 14/05/18 22:16, Enric Balletbo i Serra wrote:
Some rk3399 GRF (Generic Register Files) definitions can be used for
different drivers. Move these definitions to a common include so we
don't need to duplicate these definitions.
Signed-off-by: Enric Balletbo i Serra
---
drivers/devfreq/event/rockchip-dfi.c | 23 +++
include/soc/rockchip/rk3399_grf.h| 21 +
2 files changed, 28 insertions(+), 16 deletions(-)
create mode 100644 include/soc/rockchip/rk3399_grf.h
diff --git a/drivers/devfreq/event/rockchip-dfi.c
b/drivers/devfreq/event/rockchip-dfi.c
index 22b113363ffc..2fbbcbeb644f 100644
--- a/drivers/devfreq/event/rockchip-dfi.c
+++ b/drivers/devfreq/event/rockchip-dfi.c
@@ -26,6 +26,8 @@
#include
#include
+#include
+
#define RK3399_DMC_NUM_CH 2
/* DDRMON_CTRL */
@@ -43,18 +45,6 @@
#define DDRMON_CH1_COUNT_NUM 0x3c
#define DDRMON_CH1_DFI_ACCESS_NUM 0x40
-/* pmu grf */
-#define PMUGRF_OS_REG2 0x308
-#define DDRTYPE_SHIFT 13
-#define DDRTYPE_MASK 7
-
-enum {
- DDR3 = 3,
- LPDDR3 = 6,
- LPDDR4 = 7,
- UNUSED = 0xFF
-};
-
struct dmc_usage {
u32 access;
u32 total;
@@ -83,16 +73,17 @@ static void rockchip_dfi_start_hardware_counter(struct
devfreq_event_dev *edev)
u32 ddr_type;
/* get ddr type */
- regmap_read(info->regmap_pmu, PMUGRF_OS_REG2, &val);
- ddr_type = (val >> DDRTYPE_SHIFT) & DDRTYPE_MASK;
+ regmap_read(info->regmap_pmu, RK3399_PMUGRF_OS_REG2, &val);
+ ddr_type = (val >> RK3399_PMUGRF_DDRTYPE_SHIFT) &
+ RK3399_PMUGRF_DDRTYPE_MASK;
/* clear DDRMON_CTRL setting */
writel_relaxed(CLR_DDRMON_CTRL, dfi_regs + DDRMON_CTRL);
/* set ddr type to dfi */
- if (ddr_type == LPDDR3)
+ if (ddr_type == RK3399_PMUGRF_DDRTYPE_LPDDR3)
writel_relaxed(LPDDR3_EN, dfi_regs + DDRMON_CTRL);
- else if (ddr_type == LPDDR4)
+ else if (ddr_type == RK3399_PMUGRF_DDRTYPE_LPDDR4)
writel_relaxed(LPDDR4_EN, dfi_regs + DDRMON_CTRL);
/* enable count, use software mode */
diff --git a/include/soc/rockchip/rk3399_grf.h
b/include/soc/rockchip/rk3399_grf.h
new file mode 100644
index ..0f94034e2e9a
--- /dev/null
+++ b/include/soc/rockchip/rk3399_grf.h
@@ -0,0 +1,21 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Rockchip Generic Register Files definitions
Nit: s/Generic/General/
(that's what the TRMs say)
Robin.
+ *
+ * Copyright (c) 2018, Collabora Ltd.
+ * Author: Enric Balletbo i Serra
+ */
+
+#ifndef __SOC_RK3399_GRF_H
+#define __SOC_RK3399_GRF_H
+
+/* PMU GRF Registers */
+#define RK3399_PMUGRF_OS_REG2 0x308
+#define RK3399_PMUGRF_DDRTYPE_SHIFT13
+#define RK3399_PMUGRF_DDRTYPE_MASK 7
+#define RK3399_PMUGRF_DDRTYPE_DDR3 3
+#define RK3399_PMUGRF_DDRTYPE_LPDDR2 5
+#define RK3399_PMUGRF_DDRTYPE_LPDDR3 6
+#define RK3399_PMUGRF_DDRTYPE_LPDDR4 7
+
+#endif
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH] drm/vkms: vkms_driver can be static
Fixes: 58d8108f080c ("drm/vkms: Introduce basic VKMS driver")
Signed-off-by: Fengguang Wu
---
vkms_drv.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vkms/vkms_drv.c b/drivers/gpu/drm/vkms/vkms_drv.c
index b1df08e..35517b09 100644
--- a/drivers/gpu/drm/vkms/vkms_drv.c
+++ b/drivers/gpu/drm/vkms/vkms_drv.c
@@ -40,7 +40,7 @@ static void vkms_release(struct drm_device *dev)
drm_dev_fini(&vkms->drm);
}
-struct drm_driver vkms_driver = {
+static struct drm_driver vkms_driver = {
.driver_features= DRIVER_MODESET | DRIVER_ATOMIC | DRIVER_GEM,
.release= vkms_release,
.fops = &vkms_driver_fops,
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/vkms: Introduce basic VKMS driver
Hi Haneen, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on drm/drm-next] [also build test WARNING on v4.17-rc5 next-20180514] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Haneen-Mohammed/drm-vkms-Introduce-basic-VKMS-driver/20180515-165648 base: git://people.freedesktop.org/~airlied/linux.git drm-next reproduce: # apt-get install sparse make ARCH=x86_64 allmodconfig make C=1 CF=-D__CHECK_ENDIAN__ sparse warnings: (new ones prefixed by >>) >> drivers/gpu/drm/vkms/vkms_drv.c:43:19: sparse: symbol 'vkms_driver' was not >> declared. Should it be static? Please review and possibly fold the followup patch. --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/vkms: Introduce basic VKMS driver
On Mon, May 14, 2018 at 05:33:46PM +0300, Haneen Mohammed wrote:
> This patch introduces Virtual Kernel Mode-Setting (VKMS) driver. It
> creates a very basic kms driver with 1 crtc/encoder/connector/plane.
>
> VKMS driver would be useful for testing, or for running X (or similar)
> on headless machines and be able to still use the GPU. Thus it enables
> a virtual display without the need for hardware display capability.
>
> Signed-off-by: Haneen Mohammed
Created a new topic branch topic/vkms in drm-misc and pushed it there.
Thanks, Daniel
> ---
> drivers/gpu/drm/Kconfig | 6 ++
> drivers/gpu/drm/Makefile| 1 +
> drivers/gpu/drm/vkms/Makefile | 3 +
> drivers/gpu/drm/vkms/vkms_drv.c | 146
> drivers/gpu/drm/vkms/vkms_drv.h | 13 +++
> 5 files changed, 169 insertions(+)
> create mode 100644 drivers/gpu/drm/vkms/Makefile
> create mode 100644 drivers/gpu/drm/vkms/vkms_drv.c
> create mode 100644 drivers/gpu/drm/vkms/vkms_drv.h
>
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index 2a72d2feb76d..7db3d82cbb27 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -213,6 +213,12 @@ config DRM_VGEM
> as used by Mesa's software renderer for enhanced performance.
> If M is selected the module will be called vgem.
>
> +config DRM_VKMS
> + tristate "Virtual KMS"
> + depends on DRM
> + help
> + Choose this option to get a virtual kernal mode-setting driver.
> + If M is selected the module will be called vkms.
>
> source "drivers/gpu/drm/exynos/Kconfig"
>
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index ef9f3dab287f..8873d4769116 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -69,6 +69,7 @@ obj-$(CONFIG_DRM_SAVAGE)+= savage/
> obj-$(CONFIG_DRM_VMWGFX)+= vmwgfx/
> obj-$(CONFIG_DRM_VIA)+=via/
> obj-$(CONFIG_DRM_VGEM) += vgem/
> +obj-$(CONFIG_DRM_VKMS) += vkms/
> obj-$(CONFIG_DRM_NOUVEAU) +=nouveau/
> obj-$(CONFIG_DRM_EXYNOS) +=exynos/
> obj-$(CONFIG_DRM_ROCKCHIP) +=rockchip/
> diff --git a/drivers/gpu/drm/vkms/Makefile b/drivers/gpu/drm/vkms/Makefile
> new file mode 100644
> index ..2aef948d3a34
> --- /dev/null
> +++ b/drivers/gpu/drm/vkms/Makefile
> @@ -0,0 +1,3 @@
> +vkms-y := vkms_drv.o
> +
> +obj-$(CONFIG_DRM_VKMS) += vkms.o
> diff --git a/drivers/gpu/drm/vkms/vkms_drv.c b/drivers/gpu/drm/vkms/vkms_drv.c
> new file mode 100644
> index ..b1df08ed23a0
> --- /dev/null
> +++ b/drivers/gpu/drm/vkms/vkms_drv.c
> @@ -0,0 +1,146 @@
> +/*
> + * 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.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include "vkms_drv.h"
> +
> +#define DRIVER_NAME "vkms"
> +#define DRIVER_DESC "Virtual Kernel Mode Setting"
> +#define DRIVER_DATE "20180514"
> +#define DRIVER_MAJOR 1
> +#define DRIVER_MINOR 0
> +
> +static struct vkms_device *vkms_device;
> +
> +static const struct file_operations vkms_driver_fops = {
> + .owner = THIS_MODULE,
> + .open = drm_open,
> + .mmap = drm_gem_mmap,
> + .unlocked_ioctl = drm_ioctl,
> + .compat_ioctl = drm_compat_ioctl,
> + .poll = drm_poll,
> + .read = drm_read,
> + .llseek = no_llseek,
> + .release= drm_release,
> +};
> +
> +static void vkms_release(struct drm_device *dev)
> +{
> + struct vkms_device *vkms = container_of(dev, struct vkms_device, drm);
> +
> + platform_device_unregister(vkms->platform);
> + drm_mode_config_cleanup(&vkms->drm);
> + drm_dev_fini(&vkms->drm);
> +}
> +
> +struct drm_driver vkms_driver = {
> + .driver_features= DRIVER_MODESET | DRIVER_ATOMIC | DRIVER_GEM,
> + .release= vkms_release,
> + .fops = &vkms_driver_fops,
> +
> + .name = DRIVER_NAME,
> + .desc = DRIVER_DESC,
> + .date = DRIVER_DATE,
> + .major = DRIVER_MAJOR,
> + .minor = DRIVER_MINOR,
> +};
> +
> +static const u32 vkms_formats[] = {
> + DRM_FORMAT_XRGB,
> +};
> +
> +static void vkms_connector_destroy(struct drm_connector *connector)
> +{
> + drm_connector_unregister(connector);
> + drm_connector_cleanup(connector);
> +}
> +
> +static const struct drm_connector_funcs vkms_connector_funcs = {
> + .fill_modes = drm_helper_probe_single_connector_modes,
> + .destroy = vkms_connector_destroy,
> +};
> +
> +static int __init vkms_init(void)
> +{
> + int ret;
> +
> + vkms_device = kzalloc(sizeof(*vkms_device), GFP_KERNEL);
> + if (!vkms_device)
> + return -ENOMEM;
> +
> + ret
[Bug 106258] AMD Xorg start failes with non-4K page sizes
https://bugs.freedesktop.org/show_bug.cgi?id=106258 --- Comment #16 from Timothy Pearson --- (In reply to Ben Crocker from comment #15) > Hello Matt, Timothy, Michel, Andrey, and Dan, > > I have been testing some older cards (FirePro 2270, Embedded Radeon > E6465) on a Power8 system with no problems of the type you're > describing; I've run the Piglit test suite and the Khronos OpenGL > Conformance Test Suite. > > Direct access to a Talos machine could be beneficial, OR perhaps one > of you (Timothy, Michel, Andrey) could send me a WX 7100 for testing; > I've been meaning to ask for one of these anyway for a while now. > > Just out of curiosity, what (other) differences in behavior do you see > between PPC64LE systems configured for 64K pages and systems > configured for 4K pages? OK, I have a Talos II machine up with a WX4100 installed. Debian is loaded on it right now, and I can grant direct BMC access if anyone wants to take a crack at debug. Email me directly for login credentials. Thanks! -- 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
Re: [PATCH] dma-fence: Make dma_fence_add_callback() fail if signaled with error
Quoting Ezequiel Garcia (2018-05-14 22:28:31)
> On Mon, 2018-05-14 at 18:48 +0200, Daniel Vetter wrote:
> > On Fri, May 11, 2018 at 08:27:41AM +0100, Chris Wilson wrote:
> > > Quoting Ezequiel Garcia (2018-05-09 21:14:49)
> > > > Change how dma_fence_add_callback() behaves, when the fence
> > > > has error-signaled by the time it is being add. After this commit,
> > > > dma_fence_add_callback() returns the fence error, if it
> > > > has error-signaled before dma_fence_add_callback() is called.
> > >
> > > Why? What problem are you trying to solve? fence->error does not imply
> > > that the fence has yet been signaled, and the caller wants a callback
> > > when it is signaled.
> >
> > On top this is incosistent, e.g. we don't do the same for any of the other
> > dma_fence interfaces. Plus there's the issue that you might alias errno
> > values with fence errno values.
> >
>
> Right.
>
> > I think keeping the error codes from the functions you're calling distinct
> > from the error code of the fence itself makes a lot of sense. The first
> > tells you whether your request worked out (or why not), the second tells
> > you whether the asynchronous dma operation (gpu rendering, page flip,
> > whatever) that the dma_fence represents worked out (or why not). That's 2
> > distinct things imo.
> >
> > Might be good to show us the driver code that needs this behaviour so we
> > can discuss how to best handle your use-case.
> >
>
> This change arose while discussing the in-fences support for video4linux.
> Here's the patch that calls dma_fence_add_callback
> https://lkml.org/lkml/2018/5/4/766.
>
> The code snippet currently looks something like this:
>
> if (vb->in_fence) {
> ret = dma_fence_add_callback(vb->in_fence, &vb->fence_cb,
>
> vb2_qbuf_fence_cb);
> /* is the fence signaled? */
> if (ret == -ENOENT) {
>
> dma_fence_put(vb->in_fence);
> vb->in_fence = NULL;
> } else if (ret)
> {
> goto unlock;
> }
> }
>
> In this use case, if the callback is added successfully,
> the video4linux core defers the activation of the buffer
> until the fence signals.
>
> If the fence is signaled (currently disregarding of errors)
> then the buffer is assumed to be ready to be activated,
> and so it gets queued for hardware usage.
>
> Giving some more thought to this, I'm not so sure what is
> the right action if a fence signaled with error. In this case,
> it appears to me that we shouldn't be using this buffer
> if its in-fence is in error, but perhaps I'm missing
> something.
What I have in mind for async errors is to skip the operation and
propagate the error onto the next fence. Mostly because those async
errors may include fatal errors such as unable to pin the backing
storage for the operation, but even "trivial" errors such as an early
operation failing means that this request is then subject to garbage-in,
garbage-out. However, for trivial errors I would just propagate the
error status (so the caller knows something went wrong if they care, but
in all likelihood no one will notice) and continue on with the glitchy
operation.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/5] Add ChromeOS EC CEC Support
Hi All, The new Google "Fizz" Intel-based ChromeOS device is gaining CEC support throught it's Embedded Controller, to enable the Linux CEC Core to communicate with it and get the CEC Physical Address from the correct HDMI Connector, the following must be added/changed: - Add the CEC sub-device registration in the ChromeOS EC MFD Driver - Add the CEC related commands and events definitions into the EC MFD driver - Add a way to get a CEC notifier with it's (optional) connector name - Add the CEC notifier to the i915 HDMI driver - Add the proper ChromeOS EC CEC Driver The CEC notifier with the connector name is the tricky point, since even on Device-Tree platforms, there is no way to distinguish between multiple HDMI connectors from the same DRM driver. The solution I implemented is pretty simple and only adds an optional connector name to eventually distinguish an HDMI connector notifier from another if they share the same device. Feel free to comment this patchset ! Changes since RFC: - Moved CEC sub-device registration after CEC commands and events definitions patch - Removed get_notifier_get_byname - Added CEC_CORE select into i915 Kconfig - Removed CEC driver fallback if notifier is not configured on HW, added explicit warn - Fixed CEC core return type on error - Moved to cros-ec-cec media platform directory - Use bus_find_device() to find the pci i915 device instead of get_notifier_get_byname() - Fix Logical Address setup - Added comment about HW support - Removed memset of msg structures Neil Armstrong (5): media: cec-notifier: Get notifier by device and connector name drm/i915: hdmi: add CEC notifier to intel_hdmi mfd: cros-ec: Introduce CEC commands and events definitions. mfd: cros_ec_dev: Add CEC sub-device registration media: platform: Add Chrome OS EC CEC driver drivers/gpu/drm/i915/Kconfig | 1 + drivers/gpu/drm/i915/intel_drv.h | 2 + drivers/gpu/drm/i915/intel_hdmi.c| 10 + drivers/media/cec/cec-notifier.c | 12 +- drivers/media/platform/Kconfig | 11 + drivers/media/platform/Makefile | 2 + drivers/media/platform/cros-ec-cec/Makefile | 1 + drivers/media/platform/cros-ec-cec/cros-ec-cec.c | 336 +++ drivers/mfd/cros_ec_dev.c| 16 ++ drivers/platform/chrome/cros_ec_proto.c | 42 ++- include/linux/mfd/cros_ec.h | 2 +- include/linux/mfd/cros_ec_commands.h | 80 ++ include/media/cec-notifier.h | 30 +- 13 files changed, 530 insertions(+), 15 deletions(-) create mode 100644 drivers/media/platform/cros-ec-cec/Makefile create mode 100644 drivers/media/platform/cros-ec-cec/cros-ec-cec.c -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/5] drm/i915: hdmi: add CEC notifier to intel_hdmi
This patchs adds the cec_notifier feature to the intel_hdmi part
of the i915 DRM driver. It uses the HDMI DRM connector name to differentiate
between each HDMI ports.
The changes will allow the i915 HDMI code to notify EDID and HPD changes
to an eventual CEC adapter.
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/i915/Kconfig | 1 +
drivers/gpu/drm/i915/intel_drv.h | 2 ++
drivers/gpu/drm/i915/intel_hdmi.c | 10 ++
3 files changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
index dfd9588..2d65d56 100644
--- a/drivers/gpu/drm/i915/Kconfig
+++ b/drivers/gpu/drm/i915/Kconfig
@@ -23,6 +23,7 @@ config DRM_I915
select SYNC_FILE
select IOSF_MBI
select CRC32
+ select CEC_CORE if CEC_NOTIFIER
help
Choose this option if you have a system that has "Intel Graphics
Media Accelerator" or "HD Graphics" integrated graphics,
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index d436858..b50e51b 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -39,6 +39,7 @@
#include
#include
#include
+#include
/**
* __wait_for - magic wait macro
@@ -1001,6 +1002,7 @@ struct intel_hdmi {
bool has_audio;
bool rgb_quant_range_selectable;
struct intel_connector *attached_connector;
+ struct cec_notifier *notifier;
};
struct intel_dp_mst_encoder;
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index 1baef4a..9b94d72 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1868,6 +1868,8 @@ intel_hdmi_set_edid(struct drm_connector *connector)
connected = true;
}
+ cec_notifier_set_phys_addr_from_edid(intel_hdmi->notifier, edid);
+
return connected;
}
@@ -1876,6 +1878,7 @@ intel_hdmi_detect(struct drm_connector *connector, bool
force)
{
enum drm_connector_status status;
struct drm_i915_private *dev_priv = to_i915(connector->dev);
+ struct intel_hdmi *intel_hdmi = intel_attached_hdmi(connector);
DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n",
connector->base.id, connector->name);
@@ -1891,6 +1894,9 @@ intel_hdmi_detect(struct drm_connector *connector, bool
force)
intel_display_power_put(dev_priv, POWER_DOMAIN_GMBUS);
+ if (status != connector_status_connected)
+ cec_notifier_phys_addr_invalidate(intel_hdmi->notifier);
+
return status;
}
@@ -2358,6 +2364,10 @@ void intel_hdmi_init_connector(struct intel_digital_port
*intel_dig_port,
u32 temp = I915_READ(PEG_BAND_GAP_DATA);
I915_WRITE(PEG_BAND_GAP_DATA, (temp & ~0xf) | 0xd);
}
+
+ intel_hdmi->notifier = cec_notifier_get_conn(dev->dev, connector->name);
+ if (!intel_hdmi->notifier)
+ DRM_DEBUG_KMS("CEC notifier get failed\n");
}
void intel_hdmi_init(struct drm_i915_private *dev_priv,
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/5] media: cec-notifier: Get notifier by device and connector name
In non device-tree world, we can need to get the notifier by the driver
name directly and eventually defer probe if not yet created.
This patch adds a variant of the get function by using the device name
instead and will not create a notifier if not yet created.
But the i915 driver exposes at least 2 HDMI connectors, this patch also
adds the possibility to add a connector name tied to the notifier device
to form a tuple and associate different CEC controllers for each HDMI
connectors.
Signed-off-by: Neil Armstrong
---
drivers/media/cec/cec-notifier.c | 12 +---
include/media/cec-notifier.h | 30 --
2 files changed, 37 insertions(+), 5 deletions(-)
diff --git a/drivers/media/cec/cec-notifier.c b/drivers/media/cec/cec-notifier.c
index 16dffa0..7038abae1 100644
--- a/drivers/media/cec/cec-notifier.c
+++ b/drivers/media/cec/cec-notifier.c
@@ -21,6 +21,7 @@ struct cec_notifier {
struct list_head head;
struct kref kref;
struct device *dev;
+ const char *conn;
struct cec_adapter *cec_adap;
void (*callback)(struct cec_adapter *adap, u16 pa);
@@ -30,13 +31,14 @@ struct cec_notifier {
static LIST_HEAD(cec_notifiers);
static DEFINE_MUTEX(cec_notifiers_lock);
-struct cec_notifier *cec_notifier_get(struct device *dev)
+struct cec_notifier *cec_notifier_get_conn(struct device *dev, const char
*conn)
{
struct cec_notifier *n;
mutex_lock(&cec_notifiers_lock);
list_for_each_entry(n, &cec_notifiers, head) {
- if (n->dev == dev) {
+ if (n->dev == dev &&
+ (!conn || !strcmp(n->conn, conn))) {
kref_get(&n->kref);
mutex_unlock(&cec_notifiers_lock);
return n;
@@ -46,6 +48,8 @@ struct cec_notifier *cec_notifier_get(struct device *dev)
if (!n)
goto unlock;
n->dev = dev;
+ if (conn)
+ n->conn = kstrdup(conn, GFP_KERNEL);
n->phys_addr = CEC_PHYS_ADDR_INVALID;
mutex_init(&n->lock);
kref_init(&n->kref);
@@ -54,7 +58,7 @@ struct cec_notifier *cec_notifier_get(struct device *dev)
mutex_unlock(&cec_notifiers_lock);
return n;
}
-EXPORT_SYMBOL_GPL(cec_notifier_get);
+EXPORT_SYMBOL_GPL(cec_notifier_get_conn);
static void cec_notifier_release(struct kref *kref)
{
@@ -62,6 +66,8 @@ static void cec_notifier_release(struct kref *kref)
container_of(kref, struct cec_notifier, kref);
list_del(&n->head);
+ if (n->conn)
+ kfree(n->conn);
kfree(n);
}
diff --git a/include/media/cec-notifier.h b/include/media/cec-notifier.h
index cf0add7..73f92c7 100644
--- a/include/media/cec-notifier.h
+++ b/include/media/cec-notifier.h
@@ -20,6 +20,23 @@ struct cec_notifier;
#if IS_REACHABLE(CONFIG_CEC_CORE) && IS_ENABLED(CONFIG_CEC_NOTIFIER)
/**
+ * cec_notifier_get_conn - find or create a new cec_notifier for the given
+ * device and connector tuple.
+ * @dev: device that sends the events.
+ * @conn: the connector name from which the event occurs
+ *
+ * If a notifier for device @dev already exists, then increase the refcount
+ * and return that notifier.
+ *
+ * If it doesn't exist, then allocate a new notifier struct and return a
+ * pointer to that new struct.
+ *
+ * Return NULL if the memory could not be allocated.
+ */
+struct cec_notifier *cec_notifier_get_conn(struct device *dev,
+ const char *conn);
+
+/**
* cec_notifier_get - find or create a new cec_notifier for the given device.
* @dev: device that sends the events.
*
@@ -31,7 +48,10 @@ struct cec_notifier;
*
* Return NULL if the memory could not be allocated.
*/
-struct cec_notifier *cec_notifier_get(struct device *dev);
+static inline struct cec_notifier *cec_notifier_get(struct device *dev)
+{
+ return cec_notifier_get_conn(dev, NULL);
+}
/**
* cec_notifier_put - decrease refcount and delete when the refcount reaches 0.
@@ -85,12 +105,18 @@ void cec_register_cec_notifier(struct cec_adapter *adap,
struct cec_notifier *notifier);
#else
-static inline struct cec_notifier *cec_notifier_get(struct device *dev)
+static inline struct cec_notifier *cec_notifier_get_conn(struct device *dev,
+const char *conn)
{
/* A non-NULL pointer is expected on success */
return (struct cec_notifier *)0xdeadfeed;
}
+static inline struct cec_notifier *cec_notifier_get(struct device *dev)
+{
+ return cec_notifier_get_conn(dev, NULL);
+}
+
static inline void cec_notifier_put(struct cec_notifier *n)
{
}
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/5] mfd: cros-ec: Introduce CEC commands and events definitions.
The EC can expose a CEC bus, this patch adds the CEC related definitions
needed by the cros-ec-cec driver.
Having a 16 byte mkbp event size makes it possible to send CEC
messages from the EC to the AP directly inside the mkbp event
instead of first doing a notification and then a read.
Signed-off-by: Stefan Adolfsson
Signed-off-by: Neil Armstrong
---
drivers/platform/chrome/cros_ec_proto.c | 42 +
include/linux/mfd/cros_ec.h | 2 +-
include/linux/mfd/cros_ec_commands.h| 80 +
3 files changed, 114 insertions(+), 10 deletions(-)
diff --git a/drivers/platform/chrome/cros_ec_proto.c
b/drivers/platform/chrome/cros_ec_proto.c
index e7bbdf9..ba47f79 100644
--- a/drivers/platform/chrome/cros_ec_proto.c
+++ b/drivers/platform/chrome/cros_ec_proto.c
@@ -504,29 +504,53 @@ int cros_ec_cmd_xfer_status(struct cros_ec_device *ec_dev,
}
EXPORT_SYMBOL(cros_ec_cmd_xfer_status);
+static int get_next_event_xfer(struct cros_ec_device *ec_dev,
+ struct cros_ec_command *msg,
+ int version, uint32_t size)
+{
+ int ret;
+
+ msg->version = version;
+ msg->command = EC_CMD_GET_NEXT_EVENT;
+ msg->insize = size;
+ msg->outsize = 0;
+
+ ret = cros_ec_cmd_xfer(ec_dev, msg);
+ if (ret > 0) {
+ ec_dev->event_size = ret - 1;
+ memcpy(&ec_dev->event_data, msg->data, size);
+ }
+
+ return ret;
+}
+
static int get_next_event(struct cros_ec_device *ec_dev)
{
u8 buffer[sizeof(struct cros_ec_command) + sizeof(ec_dev->event_data)];
struct cros_ec_command *msg = (struct cros_ec_command *)&buffer;
+ static int cmd_version = 1;
int ret;
+ BUILD_BUG_ON(sizeof(union ec_response_get_next_data_v1) != 16);
+
if (ec_dev->suspended) {
dev_dbg(ec_dev->dev, "Device suspended.\n");
return -EHOSTDOWN;
}
- msg->version = 0;
- msg->command = EC_CMD_GET_NEXT_EVENT;
- msg->insize = sizeof(ec_dev->event_data);
- msg->outsize = 0;
+ if (cmd_version == 1) {
+ ret = get_next_event_xfer(ec_dev, msg, cmd_version,
+ sizeof(ec_dev->event_data));
+ if (ret != EC_RES_INVALID_VERSION)
+ return ret;
- ret = cros_ec_cmd_xfer(ec_dev, msg);
- if (ret > 0) {
- ec_dev->event_size = ret - 1;
- memcpy(&ec_dev->event_data, msg->data,
- sizeof(ec_dev->event_data));
+ /* Fallback to version 0 for future send attempts */
+ cmd_version = 0;
}
+ ret = get_next_event_xfer(ec_dev, msg, cmd_version,
+ sizeof(struct ec_response_get_next_event));
+
return ret;
}
diff --git a/include/linux/mfd/cros_ec.h b/include/linux/mfd/cros_ec.h
index 2d4e23c..f3415eb 100644
--- a/include/linux/mfd/cros_ec.h
+++ b/include/linux/mfd/cros_ec.h
@@ -147,7 +147,7 @@ struct cros_ec_device {
bool mkbp_event_supported;
struct blocking_notifier_head event_notifier;
- struct ec_response_get_next_event event_data;
+ struct ec_response_get_next_event_v1 event_data;
int event_size;
u32 host_event_wake_mask;
};
diff --git a/include/linux/mfd/cros_ec_commands.h
b/include/linux/mfd/cros_ec_commands.h
index f2edd99..18df466 100644
--- a/include/linux/mfd/cros_ec_commands.h
+++ b/include/linux/mfd/cros_ec_commands.h
@@ -804,6 +804,8 @@ enum ec_feature_code {
EC_FEATURE_MOTION_SENSE_FIFO = 24,
/* EC has RTC feature that can be controlled by host commands */
EC_FEATURE_RTC = 27,
+ /* EC supports CEC commands */
+ EC_FEATURE_CEC = 35,
};
#define EC_FEATURE_MASK_0(event_code) (1UL << (event_code % 32))
@@ -2078,6 +2080,12 @@ enum ec_mkbp_event {
/* EC sent a sysrq command */
EC_MKBP_EVENT_SYSRQ = 6,
+ /* Notify the AP that something happened on CEC */
+ EC_MKBP_CEC_EVENT = 8,
+
+ /* Send an incoming CEC message to the AP */
+ EC_MKBP_EVENT_CEC_MESSAGE = 9,
+
/* Number of MKBP events */
EC_MKBP_EVENT_COUNT,
};
@@ -2093,12 +2101,31 @@ union ec_response_get_next_data {
uint32_t sysrq;
} __packed;
+union ec_response_get_next_data_v1 {
+ uint8_t key_matrix[16];
+
+ /* Unaligned */
+ uint32_t host_event;
+
+ uint32_t buttons;
+ uint32_t switches;
+ uint32_t sysrq;
+ uint32_t cec_events;
+ uint8_tcec_message[16];
+} __packed;
+
struct ec_response_get_next_event {
uint8_t event_type;
/* Followed by event data if any */
union ec_response_get_next_data data;
} __packed;
+struct ec_response_get_next_event_v1 {
+ uint8_t event_type;
+ /* Followed by event data if any */
+ union ec_response_get_next_data_v1 data;
[PATCH 4/5] mfd: cros_ec_dev: Add CEC sub-device registration
The EC can expose a CEC bus, thus add the cros-ec-cec MFD sub-device
when the CEC feature bit is present.
Signed-off-by: Neil Armstrong
---
drivers/mfd/cros_ec_dev.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/mfd/cros_ec_dev.c b/drivers/mfd/cros_ec_dev.c
index eafd06f..57064ec 100644
--- a/drivers/mfd/cros_ec_dev.c
+++ b/drivers/mfd/cros_ec_dev.c
@@ -383,6 +383,18 @@ static void cros_ec_sensors_register(struct cros_ec_dev
*ec)
kfree(msg);
}
+static void cros_ec_cec_register(struct cros_ec_dev *ec)
+{
+ int ret;
+ struct mfd_cell cec_cell = {
+ .name = "cros-ec-cec",
+ };
+
+ ret = mfd_add_devices(ec->dev, 0, &cec_cell, 1, NULL, 0, NULL);
+ if (ret)
+ dev_err(ec->dev, "failed to add EC CEC\n");
+}
+
static int ec_device_probe(struct platform_device *pdev)
{
int retval = -ENOMEM;
@@ -422,6 +434,10 @@ static int ec_device_probe(struct platform_device *pdev)
if (cros_ec_check_features(ec, EC_FEATURE_MOTION_SENSE))
cros_ec_sensors_register(ec);
+ /* check whether this EC handles CEC. */
+ if (cros_ec_check_features(ec, EC_FEATURE_CEC))
+ cros_ec_cec_register(ec);
+
/* Take control of the lightbar from the EC. */
lb_manual_suspend_ctrl(ec, 1);
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/5] media: platform: Add Chrome OS EC CEC driver
The Chrome OS Embedded Controller can expose a CEC bus, this patch add the
driver for such feature of the Embedded Controller.
This driver is part of the cros-ec MFD and will be add as a sub-device when
the feature bit is exposed by the EC.
The controller will only handle a single logical address and handles
all the messages retries and will only expose Success or Error.
The controller will be tied to the HDMI CEC notifier by using the platform
DMI Data and the i915 device name and connector name.
Signed-off-by: Neil Armstrong
---
drivers/media/platform/Kconfig | 11 +
drivers/media/platform/Makefile | 2 +
drivers/media/platform/cros-ec-cec/Makefile | 1 +
drivers/media/platform/cros-ec-cec/cros-ec-cec.c | 336 +++
4 files changed, 350 insertions(+)
create mode 100644 drivers/media/platform/cros-ec-cec/Makefile
create mode 100644 drivers/media/platform/cros-ec-cec/cros-ec-cec.c
diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index c7a1cf8..e55a8ed2 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -546,6 +546,17 @@ menuconfig CEC_PLATFORM_DRIVERS
if CEC_PLATFORM_DRIVERS
+config VIDEO_CROS_EC_CEC
+ tristate "Chrome OS EC CEC driver"
+ depends on MFD_CROS_EC || COMPILE_TEST
+ select CEC_CORE
+ select CEC_NOTIFIER
+ ---help---
+ If you say yes here you will get support for the
+ Chrome OS Embedded Controller's CEC.
+ The CEC bus is present in the HDMI connector and enables communication
+ between compatible devices.
+
config VIDEO_MESON_AO_CEC
tristate "Amlogic Meson AO CEC driver"
depends on ARCH_MESON || COMPILE_TEST
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index 932515d..830696f 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -92,3 +92,5 @@ obj-$(CONFIG_VIDEO_QCOM_CAMSS)+=
qcom/camss-8x16/
obj-$(CONFIG_VIDEO_QCOM_VENUS) += qcom/venus/
obj-y += meson/
+
+obj-y += cros-ec-cec/
diff --git a/drivers/media/platform/cros-ec-cec/Makefile
b/drivers/media/platform/cros-ec-cec/Makefile
new file mode 100644
index 000..9ce97f9
--- /dev/null
+++ b/drivers/media/platform/cros-ec-cec/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_VIDEO_CROS_EC_CEC) += cros-ec-cec.o
diff --git a/drivers/media/platform/cros-ec-cec/cros-ec-cec.c
b/drivers/media/platform/cros-ec-cec/cros-ec-cec.c
new file mode 100644
index 000..bbff5d6
--- /dev/null
+++ b/drivers/media/platform/cros-ec-cec/cros-ec-cec.c
@@ -0,0 +1,336 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * CEC driver for Chrome OS Embedded Controller
+ *
+ * Copyright (c) 2018 BayLibre, SAS
+ * Author: Neil Armstrong
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/*
+ * This handles the CEC interface to the ChromeOS Embedded Controller,
+ * but only a single CEC line tied to a single HDMI output is handled now.
+ */
+
+#define DRV_NAME "cros-ec-cec"
+
+/**
+ * struct cros_ec_cec - Driver data for EC CEC
+ *
+ * @cros_ec: Pointer to EC device
+ * @notifier: Notifier info for responding to EC events
+ * @adap: CEC adapter
+ * @notify: CEC notifier pointer
+ * @rx_msg: storage for a received message
+ */
+struct cros_ec_cec {
+ struct cros_ec_device *cros_ec;
+ struct notifier_block notifier;
+ struct cec_adapter *adap;
+ struct cec_notifier *notify;
+ struct cec_msg rx_msg;
+};
+
+static void handle_cec_message(struct cros_ec_cec *cros_ec_cec)
+{
+ struct cros_ec_device *cros_ec = cros_ec_cec->cros_ec;
+ uint8_t *cec_message = cros_ec->event_data.data.cec_message;
+ unsigned int len = cros_ec->event_size;
+
+ cros_ec_cec->rx_msg.len = len;
+ memcpy(cros_ec_cec->rx_msg.msg, cec_message, len);
+
+ cec_received_msg(cros_ec_cec->adap, &cros_ec_cec->rx_msg);
+}
+
+static void handle_cec_event(struct cros_ec_cec *cros_ec_cec)
+{
+ struct cros_ec_device *cros_ec = cros_ec_cec->cros_ec;
+ uint32_t events = cros_ec->event_data.data.cec_events;
+
+ if (events & EC_MKBP_CEC_SEND_OK)
+ cec_transmit_attempt_done(cros_ec_cec->adap,
+ CEC_TX_STATUS_OK);
+
+ /* FW takes care of all retries, tell core to avoid more retries */
+ if (events & EC_MKBP_CEC_SEND_FAILED)
+ cec_transmit_attempt_done(cros_ec_cec->adap,
+ CEC_TX_STATUS_MAX_RETRIES |
+ CEC_TX_STATUS_NACK);
+}
+
+static int cros_ec_cec_event(struct notifier_block *nb,
+ unsigned long queued_during_suspend, void *_notify)
+{
+ struct cros_ec_cec *cros_ec_cec;
+ struct cros_ec_device *cros_ec;
+
+
Re: [PATCH 2/5] drm/i915: hdmi: add CEC notifier to intel_hdmi
On 05/15/18 14:46, Neil Armstrong wrote:
> This patchs adds the cec_notifier feature to the intel_hdmi part
> of the i915 DRM driver. It uses the HDMI DRM connector name to differentiate
> between each HDMI ports.
> The changes will allow the i915 HDMI code to notify EDID and HPD changes
> to an eventual CEC adapter.
You haven't figured yet out where to place the cec_notifier_put() call?
Or did you forget?
Regards,
Hans
>
> Signed-off-by: Neil Armstrong
> ---
> drivers/gpu/drm/i915/Kconfig | 1 +
> drivers/gpu/drm/i915/intel_drv.h | 2 ++
> drivers/gpu/drm/i915/intel_hdmi.c | 10 ++
> 3 files changed, 13 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
> index dfd9588..2d65d56 100644
> --- a/drivers/gpu/drm/i915/Kconfig
> +++ b/drivers/gpu/drm/i915/Kconfig
> @@ -23,6 +23,7 @@ config DRM_I915
> select SYNC_FILE
> select IOSF_MBI
> select CRC32
> + select CEC_CORE if CEC_NOTIFIER
> help
> Choose this option if you have a system that has "Intel Graphics
> Media Accelerator" or "HD Graphics" integrated graphics,
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index d436858..b50e51b 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -39,6 +39,7 @@
> #include
> #include
> #include
> +#include
>
> /**
> * __wait_for - magic wait macro
> @@ -1001,6 +1002,7 @@ struct intel_hdmi {
> bool has_audio;
> bool rgb_quant_range_selectable;
> struct intel_connector *attached_connector;
> + struct cec_notifier *notifier;
> };
>
> struct intel_dp_mst_encoder;
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index 1baef4a..9b94d72 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -1868,6 +1868,8 @@ intel_hdmi_set_edid(struct drm_connector *connector)
> connected = true;
> }
>
> + cec_notifier_set_phys_addr_from_edid(intel_hdmi->notifier, edid);
> +
> return connected;
> }
>
> @@ -1876,6 +1878,7 @@ intel_hdmi_detect(struct drm_connector *connector, bool
> force)
> {
> enum drm_connector_status status;
> struct drm_i915_private *dev_priv = to_i915(connector->dev);
> + struct intel_hdmi *intel_hdmi = intel_attached_hdmi(connector);
>
> DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n",
> connector->base.id, connector->name);
> @@ -1891,6 +1894,9 @@ intel_hdmi_detect(struct drm_connector *connector, bool
> force)
>
> intel_display_power_put(dev_priv, POWER_DOMAIN_GMBUS);
>
> + if (status != connector_status_connected)
> + cec_notifier_phys_addr_invalidate(intel_hdmi->notifier);
> +
> return status;
> }
>
> @@ -2358,6 +2364,10 @@ void intel_hdmi_init_connector(struct
> intel_digital_port *intel_dig_port,
> u32 temp = I915_READ(PEG_BAND_GAP_DATA);
> I915_WRITE(PEG_BAND_GAP_DATA, (temp & ~0xf) | 0xd);
> }
> +
> + intel_hdmi->notifier = cec_notifier_get_conn(dev->dev, connector->name);
> + if (!intel_hdmi->notifier)
> + DRM_DEBUG_KMS("CEC notifier get failed\n");
> }
>
> void intel_hdmi_init(struct drm_i915_private *dev_priv,
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 5/5] media: platform: Add Chrome OS EC CEC driver
Some small comments below:
On 05/15/18 14:47, Neil Armstrong wrote:
> The Chrome OS Embedded Controller can expose a CEC bus, this patch add the
> driver for such feature of the Embedded Controller.
>
> This driver is part of the cros-ec MFD and will be add as a sub-device when
> the feature bit is exposed by the EC.
>
> The controller will only handle a single logical address and handles
> all the messages retries and will only expose Success or Error.
>
> The controller will be tied to the HDMI CEC notifier by using the platform
> DMI Data and the i915 device name and connector name.
>
> Signed-off-by: Neil Armstrong
> ---
> drivers/media/platform/Kconfig | 11 +
> drivers/media/platform/Makefile | 2 +
> drivers/media/platform/cros-ec-cec/Makefile | 1 +
> drivers/media/platform/cros-ec-cec/cros-ec-cec.c | 336
> +++
> 4 files changed, 350 insertions(+)
> create mode 100644 drivers/media/platform/cros-ec-cec/Makefile
> create mode 100644 drivers/media/platform/cros-ec-cec/cros-ec-cec.c
>
> diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
> index c7a1cf8..e55a8ed2 100644
> --- a/drivers/media/platform/Kconfig
> +++ b/drivers/media/platform/Kconfig
> @@ -546,6 +546,17 @@ menuconfig CEC_PLATFORM_DRIVERS
>
> if CEC_PLATFORM_DRIVERS
>
> +config VIDEO_CROS_EC_CEC
> + tristate "Chrome OS EC CEC driver"
> + depends on MFD_CROS_EC || COMPILE_TEST
> + select CEC_CORE
> + select CEC_NOTIFIER
> + ---help---
> + If you say yes here you will get support for the
> + Chrome OS Embedded Controller's CEC.
> + The CEC bus is present in the HDMI connector and enables communication
> + between compatible devices.
> +
> config VIDEO_MESON_AO_CEC
> tristate "Amlogic Meson AO CEC driver"
> depends on ARCH_MESON || COMPILE_TEST
> diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
> index 932515d..830696f 100644
> --- a/drivers/media/platform/Makefile
> +++ b/drivers/media/platform/Makefile
> @@ -92,3 +92,5 @@ obj-$(CONFIG_VIDEO_QCOM_CAMSS) +=
> qcom/camss-8x16/
> obj-$(CONFIG_VIDEO_QCOM_VENUS) += qcom/venus/
>
> obj-y+= meson/
> +
> +obj-y+= cros-ec-cec/
> diff --git a/drivers/media/platform/cros-ec-cec/Makefile
> b/drivers/media/platform/cros-ec-cec/Makefile
> new file mode 100644
> index 000..9ce97f9
> --- /dev/null
> +++ b/drivers/media/platform/cros-ec-cec/Makefile
> @@ -0,0 +1 @@
> +obj-$(CONFIG_VIDEO_CROS_EC_CEC) += cros-ec-cec.o
> diff --git a/drivers/media/platform/cros-ec-cec/cros-ec-cec.c
> b/drivers/media/platform/cros-ec-cec/cros-ec-cec.c
> new file mode 100644
> index 000..bbff5d6
> --- /dev/null
> +++ b/drivers/media/platform/cros-ec-cec/cros-ec-cec.c
> @@ -0,0 +1,336 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * CEC driver for Chrome OS Embedded Controller
> + *
> + * Copyright (c) 2018 BayLibre, SAS
> + * Author: Neil Armstrong
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +/*
> + * This handles the CEC interface to the ChromeOS Embedded Controller,
> + * but only a single CEC line tied to a single HDMI output is handled now.
> + */
> +
> +#define DRV_NAME "cros-ec-cec"
> +
> +/**
> + * struct cros_ec_cec - Driver data for EC CEC
> + *
> + * @cros_ec: Pointer to EC device
> + * @notifier: Notifier info for responding to EC events
> + * @adap: CEC adapter
> + * @notify: CEC notifier pointer
> + * @rx_msg: storage for a received message
> + */
> +struct cros_ec_cec {
> + struct cros_ec_device *cros_ec;
> + struct notifier_block notifier;
> + struct cec_adapter *adap;
> + struct cec_notifier *notify;
> + struct cec_msg rx_msg;
> +};
> +
> +static void handle_cec_message(struct cros_ec_cec *cros_ec_cec)
> +{
> + struct cros_ec_device *cros_ec = cros_ec_cec->cros_ec;
> + uint8_t *cec_message = cros_ec->event_data.data.cec_message;
> + unsigned int len = cros_ec->event_size;
> +
> + cros_ec_cec->rx_msg.len = len;
> + memcpy(cros_ec_cec->rx_msg.msg, cec_message, len);
> +
> + cec_received_msg(cros_ec_cec->adap, &cros_ec_cec->rx_msg);
> +}
> +
> +static void handle_cec_event(struct cros_ec_cec *cros_ec_cec)
> +{
> + struct cros_ec_device *cros_ec = cros_ec_cec->cros_ec;
> + uint32_t events = cros_ec->event_data.data.cec_events;
> +
> + if (events & EC_MKBP_CEC_SEND_OK)
> + cec_transmit_attempt_done(cros_ec_cec->adap,
> + CEC_TX_STATUS_OK);
> +
> + /* FW takes care of all retries, tell core to avoid more retries */
> + if (events & EC_MKBP_CEC_SEND_FAILED)
> + cec_transmit_attempt_done(cros_ec_cec->adap,
> + CEC
Re: [PATCH 1/5] media: cec-notifier: Get notifier by device and connector name
Hi Neil,
Two small comments below:
On 05/15/18 14:46, Neil Armstrong wrote:
> In non device-tree world, we can need to get the notifier by the driver
> name directly and eventually defer probe if not yet created.
>
> This patch adds a variant of the get function by using the device name
> instead and will not create a notifier if not yet created.
>
> But the i915 driver exposes at least 2 HDMI connectors, this patch also
> adds the possibility to add a connector name tied to the notifier device
> to form a tuple and associate different CEC controllers for each HDMI
> connectors.
>
> Signed-off-by: Neil Armstrong
> ---
> drivers/media/cec/cec-notifier.c | 12 +---
> include/media/cec-notifier.h | 30 --
> 2 files changed, 37 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/media/cec/cec-notifier.c
> b/drivers/media/cec/cec-notifier.c
> index 16dffa0..7038abae1 100644
> --- a/drivers/media/cec/cec-notifier.c
> +++ b/drivers/media/cec/cec-notifier.c
> @@ -21,6 +21,7 @@ struct cec_notifier {
> struct list_head head;
> struct kref kref;
> struct device *dev;
> + const char *conn;
> struct cec_adapter *cec_adap;
> void (*callback)(struct cec_adapter *adap, u16 pa);
>
> @@ -30,13 +31,14 @@ struct cec_notifier {
> static LIST_HEAD(cec_notifiers);
> static DEFINE_MUTEX(cec_notifiers_lock);
>
> -struct cec_notifier *cec_notifier_get(struct device *dev)
> +struct cec_notifier *cec_notifier_get_conn(struct device *dev, const char
> *conn)
> {
> struct cec_notifier *n;
>
> mutex_lock(&cec_notifiers_lock);
> list_for_each_entry(n, &cec_notifiers, head) {
> - if (n->dev == dev) {
> + if (n->dev == dev &&
> + (!conn || !strcmp(n->conn, conn))) {
> kref_get(&n->kref);
> mutex_unlock(&cec_notifiers_lock);
> return n;
> @@ -46,6 +48,8 @@ struct cec_notifier *cec_notifier_get(struct device *dev)
> if (!n)
> goto unlock;
> n->dev = dev;
> + if (conn)
> + n->conn = kstrdup(conn, GFP_KERNEL);
> n->phys_addr = CEC_PHYS_ADDR_INVALID;
> mutex_init(&n->lock);
> kref_init(&n->kref);
> @@ -54,7 +58,7 @@ struct cec_notifier *cec_notifier_get(struct device *dev)
> mutex_unlock(&cec_notifiers_lock);
> return n;
> }
> -EXPORT_SYMBOL_GPL(cec_notifier_get);
> +EXPORT_SYMBOL_GPL(cec_notifier_get_conn);
>
> static void cec_notifier_release(struct kref *kref)
> {
> @@ -62,6 +66,8 @@ static void cec_notifier_release(struct kref *kref)
> container_of(kref, struct cec_notifier, kref);
>
> list_del(&n->head);
> + if (n->conn)
No need for this if, kfree already tests the pointer.
> + kfree(n->conn);
> kfree(n);
> }
>
> diff --git a/include/media/cec-notifier.h b/include/media/cec-notifier.h
> index cf0add7..73f92c7 100644
> --- a/include/media/cec-notifier.h
> +++ b/include/media/cec-notifier.h
> @@ -20,6 +20,23 @@ struct cec_notifier;
> #if IS_REACHABLE(CONFIG_CEC_CORE) && IS_ENABLED(CONFIG_CEC_NOTIFIER)
>
> /**
> + * cec_notifier_get_conn - find or create a new cec_notifier for the given
> + * device and connector tuple.
> + * @dev: device that sends the events.
> + * @conn: the connector name from which the event occurs
> + *
> + * If a notifier for device @dev already exists, then increase the refcount
> + * and return that notifier.
> + *
> + * If it doesn't exist, then allocate a new notifier struct and return a
> + * pointer to that new struct.
> + *
> + * Return NULL if the memory could not be allocated.
> + */
> +struct cec_notifier *cec_notifier_get_conn(struct device *dev,
> +const char *conn);
> +
> +/**
> * cec_notifier_get - find or create a new cec_notifier for the given device.
> * @dev: device that sends the events.
> *
> @@ -31,7 +48,10 @@ struct cec_notifier;
> *
> * Return NULL if the memory could not be allocated.
> */
> -struct cec_notifier *cec_notifier_get(struct device *dev);
> +static inline struct cec_notifier *cec_notifier_get(struct device *dev)
> +{
> + return cec_notifier_get_conn(dev, NULL);
> +}
>
> /**
> * cec_notifier_put - decrease refcount and delete when the refcount reaches
> 0.
> @@ -85,12 +105,18 @@ void cec_register_cec_notifier(struct cec_adapter *adap,
> struct cec_notifier *notifier);
>
> #else
> -static inline struct cec_notifier *cec_notifier_get(struct device *dev)
> +static inline struct cec_notifier *cec_notifier_get_conn(struct device *dev,
> + const char *conn)
> {
> /* A non-NULL pointer is expected on success */
> return (struct cec_notifier *)0xdeadfeed;
> }
>
> +static inline struct cec_notifier *cec_notifier_get(struct device *dev)
> +{
> + return cec_notifier_get_conn(dev, NULL);
>
RE: [PULL] drm-intel-next
Hi: I am truly sorry for the mess. It's actual my fault of solving a patch dependency by rebasing. Jani was trying to help me to catch the deadline, I am very appreciated for Jani's help and I am quite sorry for letting Jani experience this failure. He tried to help but I fail him. As a new guy of managing the pull request and maintenance, I need to learn more and improve our working flow to prevent this happen in future. Sorry for the inconvenience. Thanks, Zhi. -Original Message- From: Nikula, Jani Sent: Tuesday, May 15, 2018 12:56 PM To: Dave Airlie Cc: Daniel Vetter ; Jani Nikula ; Joonas Lahtinen ; Vivi, Rodrigo ; Sean Paul ; Gustavo Padovan ; Maarten Lankhorst ; dri-devel@lists.freedesktop.org; intel-...@lists.freedesktop.org; dim-to...@lists.freedesktop.org; Wang, Zhi A ; Zhenyu Wang ; Srinivas, Vidya Subject: [PULL] drm-intel-next Hi Dave - So this one contains the problematic pull from gvt. It's got both a backmerge and a rebase. I spotted the rebase, but intentionally let it slide due to the deadline closing, and then completely missed the backmerge. I don't know what I was thinking. My bad, sorry. We'll need to improve our workflows with the gvt team. Anyway, here's the pull, wrinkles and all, as discussed on IRC. Let us know if you can tolerate it, or if we need to rewrite history. BR, Jani. PS. Regarding the changelog, Vidya Srinivas had a huge role in the NV12 work, but alas I failed to give proper credit because the patches were based on earlier work by Chandra. drm-intel-next-2018-05-14: Last drm/i915 changes for v4.18: - NV12 enabling (Chandra, Maarten) - ICL workarounds (Oscar) - ICL basic DPLL enabling (Paulo) - GVT updates - DP link config refactoring (Jani) - Module parameter to override DMC firmware (Jani) - PSR updates (José, DK, Daniel, Ville) - ICL DP vswing programming (Manasi) - ICL DBuf slice updates (Mahesh) - Selftest fixes and updates (Chris, Matthew, Oscar) - Execlist fixes and updates (Chris) - Stolen memory first 4k fix (Hans de Goede) - wait_for fixes (Mika) - Tons of GEM improvements (Chris) - Plenty of other fixes and improvements (Everyone) - Crappy changelog (Me) BR, Jani. The following changes since commit 0ab390262c4920f26f8202063a268d5fc829728e: Merge tag 'drm-misc-next-2018-04-26' of git://anongit.freedesktop.org/drm/drm-misc into drm-next (2018-04-30 09:32:43 +1000) are available in the git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-2018-05-14 for you to fetch changes up to 01f83786f9ab9c8883ce634cb9a0de51086ad7ea: drm/i915: Update DRIVER_DATE to 20180514 (2018-05-14 15:28:05 +0300) Last drm/i915 changes for v4.18: - NV12 enabling (Chandra, Maarten) - ICL workarounds (Oscar) - ICL basic DPLL enabling (Paulo) - GVT updates - DP link config refactoring (Jani) - Module parameter to override DMC firmware (Jani) - PSR updates (José, DK, Daniel, Ville) - ICL DP vswing programming (Manasi) - ICL DBuf slice updates (Mahesh) - Selftest fixes and updates (Chris, Matthew, Oscar) - Execlist fixes and updates (Chris) - Stolen memory first 4k fix (Hans de Goede) - wait_for fixes (Mika) - Tons of GEM improvements (Chris) - Plenty of other fixes and improvements (Everyone) - Crappy changelog (Me) Abhay Kumar (1): drm/i915/audio: set minimum CD clock to twice the BCLK Andy Shevchenko (1): i915: Convert to use match_string() helper Anusha Srivatsa (1): drm/i915/firmware: Correct URL for firmware Chandra Konduru (3): drm/i915: Add NV12 support to intel_framebuffer_init drm/i915: Add NV12 as supported format for primary plane drm/i915: Add NV12 as supported format for sprite plane Changbin Du (1): drm/i915/gvt: Remove disable_warn_untrack and print untracked mmio with debug level Chris Wilson (53): drm/i915: Check whitelist registers across resets drm/i915: Call i915_perf_fini() on init_hw error unwind drm/i915: Move the priotree struct to its own headers drm/i915: Rename priotree to sched drm/i915: Pack params to engine->schedule() into a struct drm/i915: Build request info on stack before printk drm/i915: Don't dump umpteen thousand requests drm/i915: Skip printing global offsets for per-engine scratch pages drm/i915/breadcrumbs: Keep the fake irq armed across reset drm/i915: Use memset64() to align the ring with MI_NOOP drm/i915: Remove obsolete min/max freq setters from debugfs drm/i915: Compile out engine debug for release drm/i915/selftests: Wait for idle between idle resets as well drm/i915/lrc: Scrub the GPU state of the guilty hanging request drm/i915: Stop tracking timeline->inflight_seqnos drm/i915: Wrap engine->context_pin() and engine->context_unpin() drm/i915: Retire requests along rings drm/
[Bug 105910] Graphical artifacts on unresponsible surfaces on AMD Radeon RX 570
https://bugs.freedesktop.org/show_bug.cgi?id=105910 Ivan Chebykin changed: What|Removed |Added Severity|normal |major -- 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
Re: [PATCH v4 1/3] drm/panel: Add RGB666 variant of Innolux AT070TN90
On Mon, May 14, 2018 at 10:40:15PM +0200, Paul Kocialkowski wrote:
> Le vendredi 11 mai 2018 à 10:59 +0200, Maxime Ripard a écrit :
> > On Wed, May 09, 2018 at 01:31:23PM +0200, Paul Kocialkowski wrote:
> > > On Wed, 2018-05-09 at 09:12 +0200, Maxime Ripard wrote:
> > > > On Tue, May 08, 2018 at 12:04:11AM +0200, Paul Kocialkowski wrote:
> > > > > This adds timings for the RGB666 variant of the Innolux AT070TN90
> > > > > panel,
> > > > > as found on the Ainol AW1 tablet.
> > > > >
> > > > > The panel also supports RGB888 output. When RGB666 mode is used
> > > > > instead,
> > > > > the two extra lanes per component are grounded.
> > > > >
> > > > > In the future, it might become necessary to introduce a dedicated
> > > > > device-tree property to specify the bus format to use instead of the
> > > > > default one for the panel. This will allow supporting different bus
> > > > > formats for the same panel modes.
> > > > >
> > > > > Signed-off-by: Paul Kocialkowski
> > > > > ---
> > > > > drivers/gpu/drm/panel/panel-simple.c | 26 ++
> > > > > 1 file changed, 26 insertions(+)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/panel/panel-simple.c
> > > > > b/drivers/gpu/drm/panel/panel-simple.c
> > > > > index cbf1ab404ee7..32e30d5a8f08 100644
> > > > > --- a/drivers/gpu/drm/panel/panel-simple.c
> > > > > +++ b/drivers/gpu/drm/panel/panel-simple.c
> > > > > @@ -1063,6 +1063,29 @@ static const struct panel_desc
> > > > > innolux_at043tn24 = {
> > > > > .bus_flags = DRM_BUS_FLAG_DE_HIGH |
> > > > > DRM_BUS_FLAG_PIXDATA_POSEDGE,
> > > > > };
> > > > >
> > > > > +static const struct drm_display_mode innolux_at070tn90_mode = {
> > > > > + .clock = 4,
> > > > > + .hdisplay = 800,
> > > > > + .hsync_start = 800 + 112,
> > > > > + .hsync_end = 800 + 112 + 1,
> > > > > + .htotal = 800 + 112 + 1 + 87,
> > > > > + .vdisplay = 480,
> > > > > + .vsync_start = 480 + 141,
> > > > > + .vsync_end = 480 + 141 + 1,
> > > > > + .vtotal = 480 + 141 + 1 + 38,
> > > > > + .vrefresh = 60,
> > > > > +};
> > > > > +
> > > > > +static const struct panel_desc innolux_at070tn90 = {
> > > > > + .modes = &innolux_at070tn90_mode,
> > > > > + .num_modes = 1,
> > > > > + .size = {
> > > > > + .width = 154,
> > > > > + .height = 86,
> > > > > + },
> > > > > + .bus_format = MEDIA_BUS_FMT_RGB666_1X18,
> > > > > +};
> > > > > +
> > > >
> > > > I'm not really convinced this is the right approach. You said it
> > > > yourself, the panel is using a 24-bits interface, and you just happen
> > > > to have a tablet that routed it using a 18-bits interface instead.
> > > >
> > > > That doesn't belong in the driver, especially associated to the
> > > > compatible, but where the routing is described: in the device
> > > > tree. And given that the panel interface is a 24 bits panel, if we
> > > > were to have a default, we should have this one, and not the one
> > > > fitting your use case.
> > >
> > > I fully agree, this is why I suggested introducing a dedicated dt
> > > property for selecting the bus format (in the commit message). I still
> > > proposed this patch as a temporary solution, but I'm definitely willing
> > > to craft a proper solution as well.
> > >
> > > Here is an initial proposition:
> > > 1. Making bus_format an array in struct panel_desc and listing all the
> > > relevant bus formats that the panel can support there;
> >
> > I'm not sure this is needed, the input format is always the same in
> > your case, the panel will always take a 24 bits RGB value. What you
> > want to change is the encoder output format (and I guess you want that
> > to be meaningful to enable or not the dithering).
>
> Isn't the panel format supposed to match what the encoder's output
> should be aiming for? In my case, that would be RGB666, so the idea
> would be specifying both MEDIA_BUS_FMT_RGB666_1X18 and
> MEDIA_BUS_FMT_RGB888_1X24 in a list of supported bus formats for the
> panel.
The width your panel has in input is in 24 bits. The width the encoder
outputs in is 16 bits. This is the panel driver, you should expose the
panel capabilities.
> This way, both my setup and RGB888 setups can be supported.
I don't see what prevents you to do that with my suggestion either.
> > > 2. Introducing an optional "bus-format" dt property that indicates which
> > > bus format to use, and using the first index of the bus formats array if
> > > the property is not present;
> >
> > I guess the width would be enough, and that way we can take the
> > bus-width format that is already defined (but used in the v4l2
> > framework, not in DRM yet).
>
> Well, we already have bus-format defines on the DRM side and it feels
> like mapping these directly in device-tree would be more useful as a
> description of the hardware than just having the bus width.
Having the format in the DT doesn't make much sense. A given panel can
support multiple
[gabbayo:amdkfd-next 6/28] drivers/gpu//drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c:632:3: error: implicit declaration of function 'release_pages'; did you mean 'release_task'?
tree: git://people.freedesktop.org/~gabbayo/linux amdkfd-next
head: 8feaccf71dd61f2201493068055e0d1d699014df
commit: 5ae0283e831a94c714fce61063e4724baf364ef3 [6/28] drm/amdgpu: Add userptr
support for KFD
config: sparc64-allmodconfig (attached as .config)
compiler: sparc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 5ae0283e831a94c714fce61063e4724baf364ef3
# save the attached .config to linux build tree
make.cross ARCH=sparc64
All errors (new ones prefixed by >>):
drivers/gpu//drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c: In function
'init_user_pages':
>> drivers/gpu//drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c:632:3: error: implicit
>> declaration of function 'release_pages'; did you mean 'release_task'?
>> [-Werror=implicit-function-declaration]
release_pages(mem->user_pages, bo->tbo.ttm->num_pages);
^
release_task
cc1: some warnings being treated as errors
vim +632 drivers/gpu//drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
561
562 /* Initializes user pages. It registers the MMU notifier and validates
563 * the userptr BO in the GTT domain.
564 *
565 * The BO must already be on the userptr_valid_list. Otherwise an
566 * eviction and restore may happen that leaves the new BO unmapped
567 * with the user mode queues running.
568 *
569 * Takes the process_info->lock to protect against concurrent restore
570 * workers.
571 *
572 * Returns 0 for success, negative errno for errors.
573 */
574 static int init_user_pages(struct kgd_mem *mem, struct mm_struct *mm,
575 uint64_t user_addr)
576 {
577 struct amdkfd_process_info *process_info = mem->process_info;
578 struct amdgpu_bo *bo = mem->bo;
579 struct ttm_operation_ctx ctx = { true, false };
580 int ret = 0;
581
582 mutex_lock(&process_info->lock);
583
584 ret = amdgpu_ttm_tt_set_userptr(bo->tbo.ttm, user_addr, 0);
585 if (ret) {
586 pr_err("%s: Failed to set userptr: %d\n", __func__,
ret);
587 goto out;
588 }
589
590 ret = amdgpu_mn_register(bo, user_addr);
591 if (ret) {
592 pr_err("%s: Failed to register MMU notifier: %d\n",
593 __func__, ret);
594 goto out;
595 }
596
597 /* If no restore worker is running concurrently, user_pages
598 * should not be allocated
599 */
600 WARN(mem->user_pages, "Leaking user_pages array");
601
602 mem->user_pages = kvmalloc_array(bo->tbo.ttm->num_pages,
603 sizeof(struct page *),
604 GFP_KERNEL | __GFP_ZERO);
605 if (!mem->user_pages) {
606 pr_err("%s: Failed to allocate pages array\n",
__func__);
607 ret = -ENOMEM;
608 goto unregister_out;
609 }
610
611 ret = amdgpu_ttm_tt_get_user_pages(bo->tbo.ttm,
mem->user_pages);
612 if (ret) {
613 pr_err("%s: Failed to get user pages: %d\n", __func__,
ret);
614 goto free_out;
615 }
616
617 amdgpu_ttm_tt_set_user_pages(bo->tbo.ttm, mem->user_pages);
618
619 ret = amdgpu_bo_reserve(bo, true);
620 if (ret) {
621 pr_err("%s: Failed to reserve BO\n", __func__);
622 goto release_out;
623 }
624 amdgpu_ttm_placement_from_domain(bo, mem->domain);
625 ret = ttm_bo_validate(&bo->tbo, &bo->placement, &ctx);
626 if (ret)
627 pr_err("%s: failed to validate BO\n", __func__);
628 amdgpu_bo_unreserve(bo);
629
630 release_out:
631 if (ret)
> 632 release_pages(mem->user_pages, bo->tbo.ttm->num_pages);
633 free_out:
634 kvfree(mem->user_pages);
635 mem->user_pages = NULL;
636 unregister_out:
637 if (ret)
638 amdgpu_mn_unregister(bo);
639 out:
640 mutex_unlock(&process_info->lock);
641 return ret;
642 }
643
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 4/6] drm/rockchip: dw_hdmi: allow including external phys
Some variants of the dw-hdmi on Rockchip socs use a separate phy block
accessed via the generic phy framework, so allow them to be included
if such a phy reference is found.
Signed-off-by: Heiko Stuebner
Tested-by: Robin Murphy
---
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index b09c3531305b..57e76dfd5f6d 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
#include
#include
@@ -49,6 +50,7 @@ struct rockchip_hdmi {
struct clk *vpll_clk;
struct clk *grf_clk;
struct dw_hdmi *hdmi;
+ struct phy *phy;
};
#define to_rockchip_hdmi(x)container_of(x, struct rockchip_hdmi, x)
@@ -376,6 +378,14 @@ static int dw_hdmi_rockchip_bind(struct device *dev,
struct device *master,
return ret;
}
+ hdmi->phy = devm_phy_optional_get(dev, "hdmi");
+ if (IS_ERR(hdmi->phy)) {
+ ret = PTR_ERR(hdmi->phy);
+ if (ret != -EPROBE_DEFER)
+ DRM_DEV_ERROR(hdmi->dev, "failed to get phy\n");
+ return ret;
+ }
+
drm_encoder_helper_add(encoder, &dw_hdmi_rockchip_encoder_helper_funcs);
drm_encoder_init(drm, encoder, &dw_hdmi_rockchip_encoder_funcs,
DRM_MODE_ENCODER_TMDS, NULL);
--
2.17.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 2/6] drm/rockchip: dw_hdmi: Allow outputs that don't need output switching
So far we always encountered socs with 2 output crtcs needing the driver
to tell the hdmi block which output to connect to. But there also exist
socs with only one crtc like the rk3228, rk3328 and rk3368.
So adapt the register field to simply carry a negative value to signal
that no output-switching is necessary.
Signed-off-by: Heiko Stuebner
Tested-by: Robin Murphy
---
changes in v3:
- fixed wording issue found by Robin Murphy
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index 11309a2a4e43..b09c3531305b 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -36,7 +36,7 @@
* @lcdsel_lit: reg value of selecting vop little for HDMI
*/
struct rockchip_hdmi_chip_data {
- u32 lcdsel_grf_reg;
+ int lcdsel_grf_reg;
u32 lcdsel_big;
u32 lcdsel_lit;
};
@@ -245,6 +245,9 @@ static void dw_hdmi_rockchip_encoder_enable(struct
drm_encoder *encoder)
u32 val;
int ret;
+ if (hdmi->chip_data->lcdsel_grf_reg < 0)
+ return;
+
ret = drm_of_encoder_active_endpoint_id(hdmi->dev->of_node, encoder);
if (ret)
val = hdmi->chip_data->lcdsel_lit;
--
2.17.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 5/6] drm/rockchip: dw_hdmi: store rockchip_hdmi reference in phy_data object
When using special phy handling operations we'll often need access to
the rockchip_hdmi struct.
As the chip-data that occupies the phy_data pointer initially gets
assigned to the rockchip_hdmi struct, we can now re-use this phy_data
pointer to hold the reference to the rockchip_hdmi struct and use this
reference later on.
Inspiration for this comes from meson and sunxi dw-hdmi, which are using
the same method.
Signed-off-by: Heiko Stuebner
Tested-by: Robin Murphy
---
changes in v3:
- reword commit message
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index 57e76dfd5f6d..19f002fa0a09 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -335,7 +335,7 @@ static int dw_hdmi_rockchip_bind(struct device *dev, struct
device *master,
void *data)
{
struct platform_device *pdev = to_platform_device(dev);
- const struct dw_hdmi_plat_data *plat_data;
+ struct dw_hdmi_plat_data *plat_data;
const struct of_device_id *match;
struct drm_device *drm = data;
struct drm_encoder *encoder;
@@ -350,9 +350,14 @@ static int dw_hdmi_rockchip_bind(struct device *dev,
struct device *master,
return -ENOMEM;
match = of_match_node(dw_hdmi_rockchip_dt_ids, pdev->dev.of_node);
- plat_data = match->data;
+ plat_data = devm_kmemdup(&pdev->dev, match->data,
+sizeof(*plat_data), GFP_KERNEL);
+ if (!plat_data)
+ return -ENOMEM;
+
hdmi->dev = &pdev->dev;
hdmi->chip_data = plat_data->phy_data;
+ plat_data->phy_data = hdmi;
encoder = &hdmi->encoder;
encoder->possible_crtcs = drm_of_find_possible_crtcs(drm, dev->of_node);
--
2.17.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 6/6] drm/rockchip: dw_hdmi: add dw-hdmi support for the rk3328
The rk3328 uses a dw-hdmi controller with an external hdmi phy from
Innosilicon which uses the generic phy framework for access.
Add the necessary data and the compatible for the rk3328 to the
rockchip dw-hdmi driver.
Signed-off-by: Heiko Stuebner
Tested-by: Robin Murphy
---
changes in v3:
- reword as suggested by Rob to show that it's a dw-hdmi + Inno phy
.../display/rockchip/dw_hdmi-rockchip.txt | 1 +
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 106 ++
2 files changed, 107 insertions(+)
diff --git
a/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt
b/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt
index 937bfb472e1d..39143424a474 100644
--- a/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt
+++ b/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt
@@ -13,6 +13,7 @@ Required properties:
- compatible: should be one of the following:
"rockchip,rk3288-dw-hdmi"
+ "rockchip,rk3328-dw-hdmi"
"rockchip,rk3399-dw-hdmi"
- reg: See dw_hdmi.txt.
- reg-io-width: See dw_hdmi.txt. Shall be 4.
diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index 19f002fa0a09..237f31fd8403 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -25,6 +25,24 @@
#define RK3288_GRF_SOC_CON60x025C
#define RK3288_HDMI_LCDC_SEL BIT(4)
+#define RK3328_GRF_SOC_CON20x0408
+
+#define RK3328_HDMI_SDAIN_MSK BIT(11)
+#define RK3328_HDMI_SCLIN_MSK BIT(10)
+#define RK3328_HDMI_HPD_IOEBIT(2)
+#define RK3328_GRF_SOC_CON30x040c
+/* need to be unset if hdmi or i2c should control voltage */
+#define RK3328_HDMI_SDA5V_GRF BIT(15)
+#define RK3328_HDMI_SCL5V_GRF BIT(14)
+#define RK3328_HDMI_HPD5V_GRF BIT(13)
+#define RK3328_HDMI_CEC5V_GRF BIT(12)
+#define RK3328_GRF_SOC_CON40x0410
+#define RK3328_HDMI_HPD_SARADC BIT(13)
+#define RK3328_HDMI_CEC_5V BIT(11)
+#define RK3328_HDMI_SDA_5V BIT(10)
+#define RK3328_HDMI_SCL_5V BIT(9)
+#define RK3328_HDMI_HPD_5V BIT(8)
+
#define RK3399_GRF_SOC_CON20 0x6250
#define RK3399_HDMI_LCDC_SEL BIT(6)
@@ -292,6 +310,68 @@ static const struct drm_encoder_helper_funcs
dw_hdmi_rockchip_encoder_helper_fun
.atomic_check = dw_hdmi_rockchip_encoder_atomic_check,
};
+static int dw_hdmi_rockchip_genphy_init(struct dw_hdmi *dw_hdmi, void *data,
+struct drm_display_mode *mode)
+{
+ struct rockchip_hdmi *hdmi = (struct rockchip_hdmi *)data;
+
+ return phy_power_on(hdmi->phy);
+}
+
+static void dw_hdmi_rockchip_genphy_disable(struct dw_hdmi *dw_hdmi, void
*data)
+{
+ struct rockchip_hdmi *hdmi = (struct rockchip_hdmi *)data;
+
+ phy_power_off(hdmi->phy);
+}
+
+static enum drm_connector_status
+dw_hdmi_rk3328_read_hpd(struct dw_hdmi *dw_hdmi, void *data)
+{
+ struct rockchip_hdmi *hdmi = (struct rockchip_hdmi *)data;
+ enum drm_connector_status status;
+
+ status = dw_hdmi_phy_read_hpd(dw_hdmi, data);
+
+ if (status == connector_status_connected)
+ regmap_write(hdmi->regmap,
+ RK3328_GRF_SOC_CON4,
+ HIWORD_UPDATE(RK3328_HDMI_CEC_5V | RK3328_HDMI_SDA_5V |
+ RK3328_HDMI_SCL_5V,
+ RK3328_HDMI_CEC_5V | RK3328_HDMI_SDA_5V |
+ RK3328_HDMI_SCL_5V));
+ else
+ regmap_write(hdmi->regmap,
+ RK3328_GRF_SOC_CON4,
+ HIWORD_UPDATE(0,
+ RK3328_HDMI_CEC_5V | RK3328_HDMI_SDA_5V |
+ RK3328_HDMI_SCL_5V));
+ return status;
+}
+
+static void dw_hdmi_rk3328_setup_hpd(struct dw_hdmi *dw_hdmi, void *data)
+{
+ struct rockchip_hdmi *hdmi = (struct rockchip_hdmi *)data;
+
+ dw_hdmi_phy_setup_hpd(dw_hdmi, data);
+
+ /* Enable and map pins to 3V grf-controlled io-voltage */
+ regmap_write(hdmi->regmap,
+ RK3328_GRF_SOC_CON4,
+ HIWORD_UPDATE(0, RK3328_HDMI_HPD_SARADC | RK3328_HDMI_CEC_5V |
+RK3328_HDMI_SDA_5V | RK3328_HDMI_SCL_5V |
+RK3328_HDMI_HPD_5V));
+ regmap_write(hdmi->regmap,
+ RK3328_GRF_SOC_CON3,
+ HIWORD_UPDATE(0, RK3328_HDMI_SDA5V_GRF | RK3328_HDMI_SCL5V_GRF |
+RK3328_HDMI_HPD5V_GRF |
RK3328_HDMI_CEC5V_GRF));
+ regmap_write(hdmi->regmap,
+ RK3328_GRF_SOC_CON2,
+ HIWORD_UPDATE(RK3328_HDMI_SDAIN_MSK | RK3328_HDMI_SCLIN_MSK,
+ RK3328_HDMI_SDAIN_MSK | R
[PATCH v3 0/6] drm/rockchip: hdmi support for rk3328
The rk3228/rk3229 and rk3328 socs started using a new type of hdmi-phy from Innosilicon that resides completely separate from the dw-hdmi block and gets accessed via mmio. Additionally the rk3328 dw-hdmi does not report the vendor-phy type but a different one instead, so add the possibility to override the phy type when the glue driver knows better than the ip block itself. changes in v3: - split off phy driver into a separate series - only allow forcing vendor phy type - wording fixes and other nits changes in v2: - phy: prevent overflow in tmdsclk calculation as reported by Martin Cerveny - phy: use unsigned long for all tmdsclk rate uses - phy: simplify tmds rate calculation - dropped patch exporting some dw-hdmi phy functions as a similar patch entered drm-misc already Heiko Stuebner (6): drm/bridge: dw-hdmi: allow forcing vendor phy-type drm/rockchip: dw_hdmi: Allow outputs that don't need output switching dt-bindings: allow optional phys in Rockchip dw_hdmi binding drm/rockchip: dw_hdmi: allow including external phys drm/rockchip: dw_hdmi: store rockchip_hdmi reference in phy_data object drm/rockchip: dw_hdmi: add dw-hdmi support for the rk3328 .../display/rockchip/dw_hdmi-rockchip.txt | 3 + drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 4 +- drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 130 +- include/drm/bridge/dw_hdmi.h | 1 + 4 files changed, 134 insertions(+), 4 deletions(-) -- 2.17.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 3/6] dt-bindings: allow optional phys in Rockchip dw_hdmi binding
Some newer Rockchip SoCs use an Innosilicon hdmiphy accessed via general mmio, so allow these to be referenced via the regular phy interfaces and therefore add optional phy-related properties to the binding. Signed-off-by: Heiko Stuebner Reviewed-by: Rob Herring --- .../devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt b/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt index adc94fc3c9f8..937bfb472e1d 100644 --- a/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt +++ b/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt @@ -34,6 +34,8 @@ Optional properties - clock-names: May contain "cec" as defined in dw_hdmi.txt. - clock-names: May contain "grf", power for grf io. - clock-names: May contain "vpll", external clock for some hdmi phy. +- phys: from general PHY binding: the phandle for the PHY device. +- phy-names: Should be "hdmi" if phys references an external phy. Example: -- 2.17.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
