Re: [PATCH 1/2] dt-bindings: Add DT bindings for Toshiba TC358762 DSI-to-DPI bridge
Hi Marek.
On Sat, Jul 25, 2020 at 11:14:56PM +0200, Marek Vasut wrote:
> Add DT bindings for Toshiba TC358762 DSI-to-DPI bridge, this
> one is used in the Raspberry Pi 7" touchscreen display unit.
>
> Signed-off-by: Marek Vasut
> To: dri-devel@lists.freedesktop.org
> Cc: Eric Anholt
> Cc: Rob Herring
> Cc: Sam Ravnborg
> Cc: devicet...@vger.kernel.org
This looks like a candidate for the simple-bridge-yaml binding.
Did you check if this is sufficient or we really need a new binding?
If we need a new binding then they to take a look at how simple-bridge
define the ports. You can do this in a simple way than what is used
here.
It looks like this was copied from toshiba,tc358768.yaml, but there are
better examples to follow.
Sam
> ---
> .../display/bridge/toshiba,tc358762.yaml | 116 ++
> 1 file changed, 116 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/bridge/toshiba,tc358762.yaml
>
> diff --git
> a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358762.yaml
> b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358762.yaml
> new file mode 100644
> index ..40098ca761a3
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358762.yaml
> @@ -0,0 +1,116 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/bridge/toshiba,tc358762.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Toshiba TC358762 MIPI DSI to MIPI DPI bridge
> +
> +maintainers:
> + - Marek Vasut
> +
> +description: |
> + The TC358762 is bridge device which converts MIPI DSI to MIPI DPI.
> +
> +properties:
> + compatible:
> +enum:
> + - toshiba,tc358762
> +
> + reg:
> +maxItems: 1
> +description: virtual channel number of a DSI peripheral
> +
> + vddc-supply:
> +description: Regulator for 1.2V internal core power.
> +
> + ports:
> +type: object
> +
> +properties:
> + "#address-cells":
> +const: 1
> +
> + "#size-cells":
> +const: 0
> +
> + port@0:
> +type: object
> +additionalProperties: false
> +
> +description: |
> + Video port for MIPI DSI input
> +
> +properties:
> + reg:
> +const: 0
> +
> +patternProperties:
> + endpoint:
> +type: object
> +additionalProperties: false
> +
> +properties:
> + remote-endpoint: true
> +
> +required:
> + - reg
> +
> + port@1:
> +type: object
> +additionalProperties: false
> +
> +description: |
> + Video port for MIPI DPI output (panel or connector).
> +
> +properties:
> + reg:
> +const: 1
> +
> +patternProperties:
> + endpoint:
> +type: object
> +additionalProperties: false
> +
> +properties:
> + remote-endpoint: true
> +
> +required:
> + - reg
> +
> +required:
> + - "#address-cells"
> + - "#size-cells"
> + - port@0
> + - port@1
> +
> +required:
> + - compatible
> + - reg
> + - vddc-supply
> + - ports
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +bridge@0 {
> +reg = <0>;
> +compatible = "toshiba,tc358762";
> +vddc-supply = <&vcc_1v2_reg>;
> +#address-cells = <1>;
> +#size-cells = <0>;
> +port@0 {
> +reg = <0>;
> +bridge_in: endpoint {
> +remote-endpoint = <&dsi_out>;
> +};
> +};
> +
> +port@1 {
> +reg = <1>;
> +bridge_out: endpoint {
> +remote-endpoint = <&panel_in>;
> +};
> +};
> +};
> --
> 2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/bridge: tc358762: Add basic driver for Toshiba TC358762 DSI-to-DPI bridge
Hi Marek.
On Sat, Jul 25, 2020 at 11:14:57PM +0200, Marek Vasut wrote:
> Add very basic driver for Toshiba TC358762 DSI-to-DPI bridge, derived
> from tc358764 driver and panel-raspberrypi-touchscreen. This driver is
> meant to replace the panel-raspberrypi-touchscreen too, as the bridge
> connection can be described in DT too.
>
> Signed-off-by: Marek Vasut
> To: dri-devel@lists.freedesktop.org
> Cc: Eric Anholt
> Cc: Rob Herring
> Cc: Sam Ravnborg
> Cc: devicet...@vger.kernel.org
> ---
Two general comments.
- This driver should use the bridge panel - this will simplify the
driver in many places. We already have several good examples in-tree
that does this.
- The driver does not respect the "flags" argument in the attach
operation. All new bridge drivers shall respect the flags operation to
prepare for use in a setup with chained bridges.
In short the flags is used to determine if the display driver or the
bridge creates the connector.
When the bridge panel is introduced you can drop all the connector
creation code and just pass the flag to the bridge panel.
The bridge panel will then create the connector if requested.
This is possible because this simple bridge driver does not add
anything to the connector that the bridge panel does not know.
Sam
> drivers/gpu/drm/bridge/Kconfig| 9 +
> drivers/gpu/drm/bridge/Makefile | 1 +
> drivers/gpu/drm/bridge/tc358762.c | 352 ++
> 3 files changed, 362 insertions(+)
> create mode 100644 drivers/gpu/drm/bridge/tc358762.c
>
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index 43271c21d3fc..3e76e3fccb78 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -153,6 +153,15 @@ config DRM_THINE_THC63LVD1024
> help
> Thine THC63LVD1024 LVDS/parallel converter driver.
>
> +config DRM_TOSHIBA_TC358762
> + tristate "TC358762 DSI/DPI bridge"
> + depends on OF
> + select DRM_MIPI_DSI
> + select DRM_KMS_HELPER
> + select DRM_PANEL
> + help
> + Toshiba TC358762 DSI/DPI bridge driver.
> +
> config DRM_TOSHIBA_TC358764
> tristate "TC358764 DSI/LVDS bridge"
> depends on OF
> diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
> index d63d4b7e4347..b341c60ee96a 100644
> --- a/drivers/gpu/drm/bridge/Makefile
> +++ b/drivers/gpu/drm/bridge/Makefile
> @@ -12,6 +12,7 @@ obj-$(CONFIG_DRM_SII902X) += sii902x.o
> obj-$(CONFIG_DRM_SII9234) += sii9234.o
> obj-$(CONFIG_DRM_SIMPLE_BRIDGE) += simple-bridge.o
> obj-$(CONFIG_DRM_THINE_THC63LVD1024) += thc63lvd1024.o
> +obj-$(CONFIG_DRM_TOSHIBA_TC358762) += tc358762.o
> obj-$(CONFIG_DRM_TOSHIBA_TC358764) += tc358764.o
> obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o
> obj-$(CONFIG_DRM_TOSHIBA_TC358768) += tc358768.o
> diff --git a/drivers/gpu/drm/bridge/tc358762.c
> b/drivers/gpu/drm/bridge/tc358762.c
> new file mode 100644
> index ..6eb0c0c10623
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/tc358762.c
> @@ -0,0 +1,352 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2020 Marek Vasut
> + *
> + * Based on tc358764.c by
> + * Andrzej Hajda
> + * Maciej Purski
Someone should finish the conversion of tc358764.c to the new bridge API
(that someone is me).
> + *
> + * Based on rpi_touchscreen.c by
> + * Eric Anholt
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +/* PPI layer registers */
> +#define PPI_STARTPPI 0x0104 /* START control bit */
> +#define PPI_LPTXTIMECNT 0x0114 /* LPTX timing signal */
> +#define PPI_D0S_ATMR 0x0144
> +#define PPI_D1S_ATMR 0x0148
> +#define PPI_D0S_CLRSIPOCOUNT 0x0164 /* Assertion timer for Lane 0 */
> +#define PPI_D1S_CLRSIPOCOUNT 0x0168 /* Assertion timer for Lane 1 */
> +#define PPI_START_FUNCTION 1
> +
> +/* DSI layer registers */
> +#define DSI_STARTDSI 0x0204 /* START control bit of DSI-TX */
> +#define DSI_LANEENABLE 0x0210 /* Enables each lane */
> +#define DSI_RX_START 1
> +
> +/* LCDC/DPI Host Registers */
> +#define LCDCTRL 0x0420
> +
> +/* SPI Master Registers */
> +#define SPICMR 0x0450
> +#define SPITCR 0x0454
> +
> +/* System Controller Registers */
> +#define SYSCTRL 0x0464
> +
> +/* System registers */
> +#define LPX_PERIOD 3
> +
> +/* Lane enable PPI and DSI register bits */
> +#define LANEENABLE_CLEN BIT(0)
> +#define LANEENABLE_L0EN BIT(1)
> +#define LANEENABLE_L1EN BIT(2)
> +
> +struct tc358762 {
> + struct device *dev;
> + struct drm_bridge bridge;
> + struct drm_connector connector;
> + struct regulator *regulator;
> + struct drm_panel *panel;
> + bool
Re: [PATCH] [video/fbdev] mbxfb_remove: fix null pointer dereference
On Sun, Jul 26, 2020 at 8:26 AM Gaurav Singh wrote:
>
> Function mbxfb_debugfs_remove() accesses fbi->par without NULL check,
> hence do the NULL check in the caller mbxfb_remove().
...
> @@ -1012,11 +1012,10 @@ static int mbxfb_remove(struct platform_device *dev)
>
> write_reg_dly(SYSRST_RST, SYSRST);
>
> - mbxfb_debugfs_remove(fbi);
> -
> if (fbi) {
Can you explain how this is NULL on ->remove()?
I bet this check is simply redundant. But you have to check and update
commit message accordingly.
> struct mbxfb_info *mfbi = fbi->par;
>
> + mbxfb_debugfs_remove(fbi);
> unregister_framebuffer(fbi);
> if (mfbi) {
> if (mfbi->platform_remove)
--
With Best Regards,
Andy Shevchenko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] [video/fbdev] fb_flashcursor: Remove redundant null check
On Sun, Jul 26, 2020 at 8:17 AM Gaurav Singh wrote: > > ops cannot be NULL as its being accessed later without it's > checks. Remove the redundant NULL check. Commit message doesn't clarify why your fix is the correct one. Maybe it's the other way around, missed check in the rest of the code there? -- With Best Regards, Andy Shevchenko ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/vkms: add missing drm_crtc_vblank_put to the get/put pair on flush
On Sat, Jul 25, 2020 at 9:29 PM Melissa Wen wrote: > > On Sat, Jul 25, 2020 at 4:19 PM Melissa Wen wrote: > > > > > No, this very first warning continues (only once) :( > > > From here (drm_crtc_vblank_on): > > > if (atomic_read(&vblank->refcount) != 0 || drm_vblank_offdelay == > > > 0) > > > drm_WARN_ON(dev, drm_vblank_enable(dev, pipe)); > > > > Sorry, not sure when this warning is triggered. > > Again, I just had to look at the trace: > [ 52.299388] drm_get_last_vbltimestamp+0xaa/0xc0 [drm] > [ 52.299389] drm_reset_vblank_timestamp+0x5b/0xd0 [drm] > [ 52.299389] drm_crtc_vblank_on.cold+0x37/0x103 [drm] > [ 52.299390] drm_atomic_helper_commit_modeset_enable Yeah I think vkms can't generate a reasonable timestamp when the hrtimer is off. I thought the warning comes from a different callchain, but seems to be a general problem. I guess in the vkms timestamp function we should check whether the timer is running, and if it's not running, then we just grab the current time and done. -Daniel > > > > > > > > > But I'm still wondering why after step 3 we don't get -EINVAL from > > > > vblank_get() - after vblank_off() vblank->enabled should be false > > > > again, getting us back to the same state as after 1. Is that not > > > > happening? > > > > > > Yes (sorry if it got confused), we got -EINVAL after setp 3: > > > > > > In step 3, at the end of the 2nd running, we have: > > > atomic_disable > > > --> vblank_off [!vblank->inmodeset + refcount going 0->1 + inmodeset=1] > > > and then in next vblank_get: -EINVAL (!vblank->enabled + refcount ends 1) > > > as in the first step. > > > > > > Melissa > > > > > > > -Daniel > > > > > > > > > > > > > > > > > > > > > > > Thanks > > > > > > > -Sidong > > > > > > > > > > > > > > > > > > > > > > > > > > > > crtc->state->event = NULL; > > > > > > > > > > > } > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > 2.27.0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > Daniel Vetter > > > > > > > > > > Software Engineer, Intel Corporation > > > > > > > > > > http://blog.ffwll.ch > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > Daniel Vetter > > > > > > > > Software Engineer, Intel Corporation > > > > > > > > http://blog.ffwll.ch > > > > > > > > ___ > > > > > > > > dri-devel mailing list > > > > > > > > dri-devel@lists.freedesktop.org > > > > > > > > https://lists.freedesktop.org/mailman/listinfo/dri-devel > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > Daniel Vetter > > > > > > Software Engineer, Intel Corporation > > > > > > http://blog.ffwll.ch > > > > > > > > > > > > > > > > -- > > > > Daniel Vetter > > > > Software Engineer, Intel Corporation > > > > http://blog.ffwll.ch -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 0/5] drm: rockchip: various ports for older VOPs
On Sat, Jul 25, 2020 at 8:48 PM Alex Bee wrote: > > > Am 25.07.20 um 17:54 schrieb Daniel Vetter: > > On Sat, Jul 25, 2020 at 3:52 PM Alex Bee wrote: > >> > >> Am 22.07.20 um 23:43 schrieb Daniel Vetter: > >>> On Wed, Jul 22, 2020 at 8:13 PM Alex Bee wrote: > Hi, > > this series mainly ports existining functionality to older SoCs - most > importantly enables alpha blending for RK3036, RK3066, RK3126 and > RK3188. > Besides that, it also changes the window type from DRM_PLANE_TYPE_CURSOR > to DRM_PLANE_TYPE_OVERLAY for VOPs that have only one (1) overlay window. > >>> This doesn't make much sense, the cursor overlay is really just a hint > >>> for legacy ioctls that this is the overlay that should be used for > >>> cursors. Compositors should try to use such planes as full overlays > >>> (if they don't want to use them as a cursor). So sounds like a case of > >>> "fix your compositor". > >> I agree here - but: If HWC windows would have been implemented in this > >> particular driver, their max size would be 128x128 on some SoCs - so > >> they woudn't be really suitable to create an OSD overlay at 4K, for > >> example. I don't know, but I guess other vendors implement their HWC > >> windows on this reduced HW resources as well. I guess that is one of the > >> reasons, why userspace, which aims to be cross-plattfrom, avoids > >> DRM_PLANE_TYPE_CURSOR when its looking for an usable overlay plane. (a > >> heuristic, indeed) > > Which userspace does that? > kodi-gbm: > https://github.com/xbmc/xbmc/blob/master/xbmc/windowing/gbm/DRMUtils.cpp#L406 Can you pls file a bug report, linking to this thread here? Maybe also link to the docs: https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html?highlight=drm_plane#c.drm_plane_type "For userspace which is universal plane aware and which is using that atomic IOCTL there’s no difference between these planes (beyong what the driver and hardware can support of course)." Also feel free to cc me on the github issue (I'm @danvet over there) in case there's more questions. Cheers, Daniel > > > We should fix that, not try to work around > > that in all the drivers in upstream, that wont work. > You're right I'll drop this part. > > -Daniel > > > >>> For atomic there's 0 difference between a overlay or a cursor (primary > >>> plane is still treated somewhat special in the RMFB ioctl, but again > >>> that's for backwards compat reasons with existing uapi, not because > >>> the primary plane is different). > >>> > >>> What does happen though is that this breaks cursor for legacy > >>> userspace, which is probably not really what you want. > >> Indeed not. > >> > >> Beforhand I was submiiting this, I looked arround and couldn't find > >> anything which relies or even depends of a cursor window to be > >> available. Even if: as per spec only one DRM_PLANE_TYPE_PRIMARY is > >> mandatory, everything else is optional. > >> > >>> -Daniel > >>> > >>> > Regards, > Alex > > Changes in v2: > - drop not yet upstreamed dsp_data_swap from RK3188 regs > - rephrase most commit messages > > Alex Bee (5): > drm: rockchip: add scaling for RK3036 win1 > drm: rockchip: add missing registers for RK3188 > drm: rockchip: add alpha support for RK3036, RK3066, RK3126 and > RK3188 > drm: rockchip: set alpha_en to 0 if it is not used > drm: rockchip: use overlay windows as such > > drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 1 + > drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 42 ++--- > drivers/gpu/drm/rockchip/rockchip_vop_reg.h | 1 + > 3 files changed, 38 insertions(+), 6 deletions(-) > > -- > 2.17.1 > > >>> -- > >>> Daniel Vetter > >>> Software Engineer, Intel Corporation > >>> http://blog.ffwll.ch > >> Best Regards > >> > > > Best regards -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 9/9] soc/qcom: Add REVID driver
On Sun, Jul 26, 2020 at 01:12:06PM +0200, Konrad Dybcio wrote:
> From: Xiaozhe Shi
>
> Add the REVID device driver. The REVID driver will print out the PMIC
> revision at probe time.
Why do we need this noise in the kernel log?
> --- /dev/null
> +++ b/drivers/soc/qcom/qpnp-revid.c
> @@ -0,0 +1,288 @@
> +/* Copyright (c) 2013-2019, The Linux Foundation. All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 and
> + * only version 2 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
You can drop the GPL boilerplate text and add a proper SPDX line at the
top.
Didn't checkpatch ask for that?
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define REVID_REVISION1 0x0
> +#define REVID_REVISION2 0x1
> +#define REVID_REVISION3 0x2
> +#define REVID_REVISION4 0x3
> +#define REVID_TYPE 0x4
> +#define REVID_SUBTYPE0x5
> +#define REVID_STATUS10x8
> +#define REVID_SPARE_00x60
> +#define REVID_TP_REV 0xf1
> +#define REVID_FAB_ID 0xf2
> +
> +#define QPNP_REVID_DEV_NAME "qcom,qpnp-revid"
> +
> +static const char *const pmic_names[] = {
> + [0] = "Unknown PMIC",
> + [PM8941_SUBTYPE] = "PM8941",
> + [PM8841_SUBTYPE] = "PM8841",
> + [PM8019_SUBTYPE] = "PM8019",
> + [PM8226_SUBTYPE] = "PM8226",
> + [PM8110_SUBTYPE] = "PM8110",
> + [PMA8084_SUBTYPE] = "PMA8084",
> + [PMI8962_SUBTYPE] = "PMI8962",
> + [PMD9635_SUBTYPE] = "PMD9635",
> + [PM8994_SUBTYPE] = "PM8994",
> + [PMI8994_SUBTYPE] = "PMI8994",
> + [PM8916_SUBTYPE] = "PM8916",
> + [PM8004_SUBTYPE] = "PM8004",
> + [PM8909_SUBTYPE] = "PM8909",
> + [PM2433_SUBTYPE] = "PM2433",
> + [PMD9655_SUBTYPE] = "PMD9655",
> + [PM8950_SUBTYPE] = "PM8950",
> + [PMI8950_SUBTYPE] = "PMI8950",
> + [PMK8001_SUBTYPE] = "PMK8001",
> + [PMI8996_SUBTYPE] = "PMI8996",
> + [PM8998_SUBTYPE] = "PM8998",
> + [PMI8998_SUBTYPE] = "PMI8998",
> + [PM8005_SUBTYPE] = "PM8005",
> + [PM8937_SUBTYPE] = "PM8937",
> + [PM660L_SUBTYPE] = "PM660L",
> + [PM660_SUBTYPE] = "PM660",
> + [PMI632_SUBTYPE] = "PMI632",
> + [PMI8937_SUBTYPE] = "PMI8937",
> + [PM8150_SUBTYPE] = "PM8150",
> + [PM8150B_SUBTYPE] = "PM8150B",
> + [PM8150L_SUBTYPE] = "PM8150L",
> + [PM6150_SUBTYPE] = "PM6150",
> + [PM8150A_SUBTYPE] = "PM8150A",
> + [PME9205_SUBTYPE] = "PME9205",
> + [PM6125_SUBTYPE] = "PM6125",
> + [PM8008_SUBTYPE] = "PM8008",
> + [SMB1355_SUBTYPE] = "SMB1355",
> + [SMB1390_SUBTYPE] = "SMB1390",
> +};
> +
> +struct revid_chip {
> + struct list_headlink;
> + struct device_node *dev_node;
> + struct pmic_revid_data data;
> +};
> +
> +static LIST_HEAD(revid_chips);
> +static DEFINE_MUTEX(revid_chips_lock);
> +
> +static const struct of_device_id qpnp_revid_match_table[] = {
> + { .compatible = QPNP_REVID_DEV_NAME },
> + {}
> +};
> +
> +static u8 qpnp_read_byte(struct regmap *regmap, u16 addr)
> +{
> + int rc;
> + int val;
> +
> + rc = regmap_read(regmap, addr, &val);
> + if (rc) {
> + pr_err("read failed rc=%d\n", rc);
Drivers should always use dev_err() and friends, as you have access to a
struct device * always. Please fix up the driver here to use that api
instead, no pr_* should be needed at all.
> + return 0;
> + }
> + return (u8)val;
> +}
> +
> +/**
> + * get_revid_data - Return the revision information of PMIC
> + * @dev_node: Pointer to the revid peripheral of the PMIC for which
> + * revision information is seeked
> + *
> + * CONTEXT: Should be called in non atomic context
> + *
> + * RETURNS: pointer to struct pmic_revid_data filled with the information
> + * about the PMIC revision
> + */
> +struct pmic_revid_data *get_revid_data(struct device_node *dev_node)
> +{
> + struct revid_chip *revid_chip;
> +
> + if (!dev_node)
> + return ERR_PTR(-EINVAL);
> +
> + mutex_lock(&revid_chips_lock);
> + list_for_each_entry(revid_chip, &revid_chips, link) {
> + if (dev_node == revid_chip->dev_node) {
> + mutex_unlock(&revid_chips_lock);
> + return &revid_chip->data;
> + }
> + }
> + mutex_unlock(&revid_chips_lock);
> + return ERR_PTR(-EINVAL);
> +}
> +EXPORT_SYMBOL(get_revid_data);
Horrible global symbol name. Who calls this? This is the last patch in
the series, so if there is no user for this, please don't export it.
> +
> +#define PM8941_PERIPHERAL_SUBTYPE0x01
> +#define PM8226
Re: [PATCH 9/9] soc/qcom: Add REVID driver
On Sun, Jul 26, 2020 at 01:40:46PM +0200, Konrad Dybcio wrote: > >Horrible global symbol name. Who calls this? > > Welcome to development on qcom platforms :D Yeah, I have seen :( > >This is the last patch in > >the series, so if there is no user for this, please don't export it. > > Other downstream drivers make use of it.. need to get this up first, sorry :V Then use a proper name for it, with a correct prefix, and export it with EXPORT_SYMBOL_GPL() please. > >Why do you need a .h file in the include directory if only a single .c > >file needs it? Just put that info in the .c file itself. > > Again, other downstream drivers which some people and I intend to > bring to upstream standards use that to access the PMIC model/hw revision. But all of those defines are not needed, just the function name, right? > >But again, who uses this module? If it's only good for a single line in > >the kernel log, that feels like a huge waste to me. > > downstream-kernel-dir$ rg -l qpnp-revid.h | wc -l > 25 > > So yeah, quite a bunch of other qcom-specific drivers. > > I'll try to fix these and send a v2. Hold off on this and wait until there is a real user for it, as we can not take api additions without a user, otherwise we will just come along and delete the code. Submit it as part of a series that actually uses the function, so we can at least see if the function makes sense to be used in that way as well, right now we have no clue. thanks, greg k-h ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] [video/fbdev] fb_flashcursor: Remove redundant null check
ops cannot be NULL as its being accessed later without checks. Remove the redundant NULL check. Signed-off-by: Gaurav Singh --- drivers/video/fbdev/core/fbcon.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c index e2a490c5ae08..9551f40c6d14 100644 --- a/drivers/video/fbdev/core/fbcon.c +++ b/drivers/video/fbdev/core/fbcon.c @@ -401,7 +401,7 @@ static void fb_flashcursor(struct work_struct *work) if (ret == 0) return; - if (ops && ops->currcon != -1) + if (ops->currcon != -1) vc = vc_cons[ops->currcon].d; if (!vc || !con_is_visible(vc) || -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] [video/fbdev] mbxfb_remove: fix null pointer dereference
Function mbxfb_debugfs_remove() accesses fbi->par without NULL check,
hence do the NULL check in the caller mbxfb_remove().
Signed-off-by: Gaurav Singh
---
drivers/video/fbdev/mbx/mbxfb.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/mbx/mbxfb.c b/drivers/video/fbdev/mbx/mbxfb.c
index 6dc287c819cb..515c0cda1994 100644
--- a/drivers/video/fbdev/mbx/mbxfb.c
+++ b/drivers/video/fbdev/mbx/mbxfb.c
@@ -1012,11 +1012,10 @@ static int mbxfb_remove(struct platform_device *dev)
write_reg_dly(SYSRST_RST, SYSRST);
- mbxfb_debugfs_remove(fbi);
-
if (fbi) {
struct mbxfb_info *mfbi = fbi->par;
+ mbxfb_debugfs_remove(fbi);
unregister_framebuffer(fbi);
if (mfbi) {
if (mfbi->platform_remove)
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 7/9] drm/msm/mdp5: Add MDP5 configuration for SDM636/660
This commit adds support for the MDP5 IP on Snapdragon
636/660.
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c | 105 +++
1 file changed, 105 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c
index 2e02de8a7e41..df10c1ac7591 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c
@@ -1002,6 +1002,110 @@ static const struct mdp5_cfg_hw sdm630_config = {
.max_clk = 41250,
};
+static const struct mdp5_cfg_hw sdm660_config = {
+ .name = "sdm660",
+ .mdp = {
+ .count = 1,
+ .caps = MDP_CAP_DSC |
+ MDP_CAP_CDM |
+ MDP_CAP_SRC_SPLIT |
+ 0,
+ },
+ .ctl = {
+ .count = 5,
+ .base = { 0x01000, 0x01200, 0x01400, 0x01600, 0x01800 },
+ .flush_hw_mask = 0xf4ff,
+ },
+ .pipe_vig = {
+ .count = 2,
+ .base = { 0x04000, 0x6000 },
+ .caps = MDP_PIPE_CAP_HFLIP |
+ MDP_PIPE_CAP_VFLIP |
+ MDP_PIPE_CAP_SCALE |
+ MDP_PIPE_CAP_CSC|
+ MDP_PIPE_CAP_DECIMATION |
+ MDP_PIPE_CAP_SW_PIX_EXT |
+ 0,
+ },
+ .pipe_rgb = {
+ .count = 4,
+ .base = { 0x14000, 0x16000, 0x18000, 0x1a000 },
+ .caps = MDP_PIPE_CAP_HFLIP |
+ MDP_PIPE_CAP_VFLIP |
+ MDP_PIPE_CAP_SCALE |
+ MDP_PIPE_CAP_DECIMATION |
+ MDP_PIPE_CAP_SW_PIX_EXT |
+ 0,
+ },
+ .pipe_dma = {
+ .count = 2, /* driver supports max of 2 currently */
+ .base = { 0x24000, 0x26000, 0x28000 },
+ .caps = MDP_PIPE_CAP_HFLIP |
+ MDP_PIPE_CAP_VFLIP |
+ MDP_PIPE_CAP_SW_PIX_EXT |
+ 0,
+ },
+ .pipe_cursor = {
+ .count = 1,
+ .base = { 0x34000 },
+ .caps = MDP_PIPE_CAP_HFLIP |
+ MDP_PIPE_CAP_VFLIP |
+ MDP_PIPE_CAP_SW_PIX_EXT |
+ MDP_PIPE_CAP_CURSOR |
+ 0,
+ },
+
+ .lm = {
+ .count = 4,
+ .base = { 0x44000, 0x45000, 0x46000, 0x49000 },
+ .instances = {
+ { .id = 0, .pp = 0, .dspp = 0,
+ .caps = MDP_LM_CAP_DISPLAY |
+ MDP_LM_CAP_PAIR, },
+ { .id = 1, .pp = 1, .dspp = 1,
+ .caps = MDP_LM_CAP_DISPLAY, },
+ { .id = 2, .pp = 2, .dspp = -1,
+ .caps = MDP_LM_CAP_DISPLAY |
+ MDP_LM_CAP_PAIR, },
+ { .id = 3, .pp = 3, .dspp = -1,
+ .caps = MDP_LM_CAP_WB, },
+ },
+ .nb_stages = 8,
+ .max_width = 2560,
+ .max_height = 0x,
+ },
+ .dspp = {
+ .count = 2,
+ .base = { 0x54000, 0x56000 },
+ },
+ .ad = {
+ .count = 2,
+ .base = { 0x78000, 0x78800 },
+ },
+ .pp = {
+ .count = 5,
+ .base = { 0x7, 0x70800, 0x71000, 0x71800, 0x72000 },
+ },
+ .cdm = {
+ .count = 1,
+ .base = { 0x79200 },
+ },
+ .dsc = {
+ .count = 2,
+ .base = { 0x8, 0x80400 },
+ },
+ .intf = {
+ .base = { 0x6a000, 0x6a800, 0x6b000, 0x6b800 },
+ .connect = {
+ [0] = INTF_DISABLED,
+ [1] = INTF_DSI,
+ [2] = INTF_DSI,
+ [3] = INTF_HDMI,
+ },
+ },
+ .max_clk = 41250,
+};
+
static const struct mdp5_cfg_handler cfg_handlers_v1[] = {
{ .revision = 0, .config = { .hw = &msm8x74v1_config } },
{ .revision = 2, .config = { .hw = &msm8x74v2_config } },
@@ -1016,6 +1120,7 @@ static const struct mdp5_cfg_handler cfg_handlers_v1[] = {
static const struct mdp5_cfg_handler cfg_handlers_v3[] = {
{ .revision = 0, .config = { .hw = &msm8998_config } },
+ { .revision = 2, .config = { .hw = &sdm660_config } },
{ .revision = 3, .config = { .hw = &sdm630_config } },
};
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH -next] drm: xlnx: Fix typo in parameter description
Fix typo in parameter description.
Fixes: d76271d22694 ("drm: xlnx: DRM/KMS driver for Xilinx ZynqMP DisplayPort
Subsystem")
Reported-by: Hulk Robot
Signed-off-by: Wei Yongjun
---
drivers/gpu/drm/xlnx/zynqmp_dp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/xlnx/zynqmp_dp.c b/drivers/gpu/drm/xlnx/zynqmp_dp.c
index 821f7a71e182..3d53638ab15e 100644
--- a/drivers/gpu/drm/xlnx/zynqmp_dp.c
+++ b/drivers/gpu/drm/xlnx/zynqmp_dp.c
@@ -44,7 +44,7 @@ MODULE_PARM_DESC(aux_timeout_ms, "DP aux timeout value in
msec (default: 50)");
*/
static uint zynqmp_dp_power_on_delay_ms = 4;
module_param_named(power_on_delay_ms, zynqmp_dp_power_on_delay_ms, uint, 0444);
-MODULE_PARM_DESC(aux_timeout_ms, "DP power on delay in msec (default: 4)");
+MODULE_PARM_DESC(power_on_delay_ms, "DP power on delay in msec (default: 4)");
/* Link configuration registers */
#define ZYNQMP_DP_LINK_BW_SET 0x0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/9] drm/msm/dsi: Add phy configuration for SDM630/636/660
These SoCs make use of the 14nm phy, but at different
addresses than other 14nm units.
Signed-off-by: Konrad Dybcio
---
.../devicetree/bindings/display/msm/dsi.txt| 1 +
drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 2 ++
drivers/gpu/drm/msm/dsi/phy/dsi_phy.h | 1 +
drivers/gpu/drm/msm/dsi/phy/dsi_phy_14nm.c | 18 ++
4 files changed, 22 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/msm/dsi.txt
b/Documentation/devicetree/bindings/display/msm/dsi.txt
index af95586c898f..7884fd7a85c1 100644
--- a/Documentation/devicetree/bindings/display/msm/dsi.txt
+++ b/Documentation/devicetree/bindings/display/msm/dsi.txt
@@ -87,6 +87,7 @@ Required properties:
* "qcom,dsi-phy-20nm"
* "qcom,dsi-phy-28nm-8960"
* "qcom,dsi-phy-14nm"
+ * "qcom,dsi-phy-14nm-660"
* "qcom,dsi-phy-10nm"
* "qcom,dsi-phy-10nm-8998"
- reg: Physical base address and length of the registers of PLL, PHY. Some
diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
index f509ebd77500..009f5b843dd1 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
@@ -499,6 +499,8 @@ static const struct of_device_id dsi_phy_dt_match[] = {
#ifdef CONFIG_DRM_MSM_DSI_14NM_PHY
{ .compatible = "qcom,dsi-phy-14nm",
.data = &dsi_phy_14nm_cfgs },
+ { .compatible = "qcom,dsi-phy-14nm-660",
+ .data = &dsi_phy_14nm_660_cfgs },
#endif
#ifdef CONFIG_DRM_MSM_DSI_10NM_PHY
{ .compatible = "qcom,dsi-phy-10nm",
diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
index 24b294ed3059..ef8672d7b123 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
@@ -45,6 +45,7 @@ extern const struct msm_dsi_phy_cfg dsi_phy_28nm_lp_cfgs;
extern const struct msm_dsi_phy_cfg dsi_phy_20nm_cfgs;
extern const struct msm_dsi_phy_cfg dsi_phy_28nm_8960_cfgs;
extern const struct msm_dsi_phy_cfg dsi_phy_14nm_cfgs;
+extern const struct msm_dsi_phy_cfg dsi_phy_14nm_660_cfgs;
extern const struct msm_dsi_phy_cfg dsi_phy_10nm_cfgs;
extern const struct msm_dsi_phy_cfg dsi_phy_10nm_8998_cfgs;
diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_14nm.c
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_14nm.c
index 1594f1422372..519400501bcd 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_14nm.c
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_14nm.c
@@ -161,3 +161,21 @@ const struct msm_dsi_phy_cfg dsi_phy_14nm_cfgs = {
.io_start = { 0x994400, 0x996400 },
.num_dsi_phy = 2,
};
+
+const struct msm_dsi_phy_cfg dsi_phy_14nm_660_cfgs = {
+ .type = MSM_DSI_PHY_14NM,
+ .src_pll_truthtable = { {false, false}, {true, false} },
+ .reg_cfg = {
+ .num = 1,
+ .regs = {
+ {"vcca", 17000, 32},
+ },
+ },
+ .ops = {
+ .enable = dsi_14nm_phy_enable,
+ .disable = dsi_14nm_phy_disable,
+ .init = dsi_14nm_phy_init,
+ },
+ .io_start = { 0xc994400, 0xc996000 },
+ .num_dsi_phy = 2,
+};
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] amdgpu_dm: fix nonblocking atomic commit use-after-free
Dear Kees,
Am 24.07.20 um 00:32 schrieb Kees Cook:
On Thu, Jul 23, 2020 at 09:10:15PM +, Mazin Rezk wrote:
When amdgpu_dm_atomic_commit_tail is running in the workqueue,
drm_atomic_state_put will get called while amdgpu_dm_atomic_commit_tail is
running, causing a race condition where state (and then dm_state) is
sometimes freed while amdgpu_dm_atomic_commit_tail is running. This bug has
occurred since 5.7-rc1 and is well documented among polaris11 users [1].
Prior to 5.7, this was not a noticeable issue since the freelist pointer
was stored at the beginning of dm_state (base), which was unused. After
changing the freelist pointer to be stored in the middle of the struct, the
freelist pointer overwrote the context, causing dc_state to become garbage
data and made the call to dm_enable_per_frame_crtc_master_sync dereference
a freelist pointer.
This patch fixes the aforementioned issue by calling drm_atomic_state_get
in amdgpu_dm_atomic_commit before drm_atomic_helper_commit is called and
drm_atomic_state_put after amdgpu_dm_atomic_commit_tail is complete.
According to my testing on 5.8.0-rc6, this should fix bug 207383 on
Bugzilla [1].
[1] https://bugzilla.kernel.org/show_bug.cgi?id=207383
Nice work tracking this down!
Fixes: 3202fa62f ("slub: relocate freelist pointer to middle of object")
I do, however, object to this Fixes tag. :) The flaw appears to have
been with amdgpu_dm's reference tracking of "state" in the nonblocking
case. (How this reference counting is supposed to work correctly, though,
I'm not sure.) If I look at where the drm helper was split from being
the default callback, it looks like this was what introduced the bug:
da5c47f682ab ("drm/amd/display: Remove acrtc->stream")
? 3202fa62f certainly exposed it much more quickly, but there was a race
even without 3202fa62f where something could have realloced the memory
and written over it.
I understand the Fixes tag mainly a help when backporting commits.
As Linux 5.8-rc7 is going to be released this Sunday, I wonder, if
commit 3202fa62f ("slub: relocate freelist pointer to middle of object")
should be reverted for now to fix the regression for the users according
to Linux’ no regression policy. Once the AMDGPU/DRM driver issue is
fixed, it can be reapplied. I know it’s not optimal, but as some testing
is going to be involved for the fix, I’d argue it’s the best option for
the users.
Kind regards,
Paul
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [v7, PATCH 7/7] drm/mediatek: add support for mediatek SOC MT8183
On Thu, 2020-07-23 at 17:40 +0200, Matthias Brugger wrote:
>
> On 23/07/2020 04:03, Yongqiang Niu wrote:
> > This patch add support for mediatek SOC MT8183
> > 1.ovl_2l share driver with ovl
> > 2.rdma1 share drive with rdma0, but fifo size is different
> > 3.add mt8183 mutex private data, and mmsys private data
> > 4.add mt8183 main and external path module for crtc create
>
> Please fix your commit message, this is seems to describe what the whole
> series
> is doing.
will fix in next version
>
> Regards,
> Matthias
>
> >
> > Signed-off-by: Yongqiang Niu
> > ---
> > drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 18
> > drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 6
> > drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 47
> >
> > drivers/gpu/drm/mediatek/mtk_drm_drv.c | 43
> > +
> > 4 files changed, 114 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> > b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> > index 28651bc..8cf9f3b 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> > @@ -430,11 +430,29 @@ static int mtk_disp_ovl_remove(struct platform_device
> > *pdev)
> > .fmt_rgb565_is_0 = true,
> > };
> >
> > +static const struct mtk_disp_ovl_data mt8183_ovl_driver_data = {
> > + .addr = DISP_REG_OVL_ADDR_MT8173,
> > + .gmc_bits = 10,
> > + .layer_nr = 4,
> > + .fmt_rgb565_is_0 = true,
> > +};
> > +
> > +static const struct mtk_disp_ovl_data mt8183_ovl_2l_driver_data = {
> > + .addr = DISP_REG_OVL_ADDR_MT8173,
> > + .gmc_bits = 10,
> > + .layer_nr = 2,
> > + .fmt_rgb565_is_0 = true,
> > +};
> > +
> > static const struct of_device_id mtk_disp_ovl_driver_dt_match[] = {
> > { .compatible = "mediatek,mt2701-disp-ovl",
> > .data = &mt2701_ovl_driver_data},
> > { .compatible = "mediatek,mt8173-disp-ovl",
> > .data = &mt8173_ovl_driver_data},
> > + { .compatible = "mediatek,mt8183-disp-ovl",
> > + .data = &mt8183_ovl_driver_data},
> > + { .compatible = "mediatek,mt8183-disp-ovl-2l",
> > + .data = &mt8183_ovl_2l_driver_data},
> > {},
> > };
> > MODULE_DEVICE_TABLE(of, mtk_disp_ovl_driver_dt_match);
> > diff --git a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> > b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> > index 794acc5..51f2a0c 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> > @@ -355,11 +355,17 @@ static int mtk_disp_rdma_remove(struct
> > platform_device *pdev)
> > .fifo_size = SZ_8K,
> > };
> >
> > +static const struct mtk_disp_rdma_data mt8183_rdma_driver_data = {
> > + .fifo_size = 5 * SZ_1K,
> > +};
> > +
> > static const struct of_device_id mtk_disp_rdma_driver_dt_match[] = {
> > { .compatible = "mediatek,mt2701-disp-rdma",
> > .data = &mt2701_rdma_driver_data},
> > { .compatible = "mediatek,mt8173-disp-rdma",
> > .data = &mt8173_rdma_driver_data},
> > + { .compatible = "mediatek,mt8183-disp-rdma",
> > + .data = &mt8183_rdma_driver_data},
> > {},
> > };
> > MODULE_DEVICE_TABLE(of, mtk_disp_rdma_driver_dt_match);
> > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> > b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> > index 014c1bb..60788c1 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> > @@ -15,6 +15,8 @@
> >
> > #define MT2701_DISP_MUTEX0_MOD0 0x2c
> > #define MT2701_DISP_MUTEX0_SOF0 0x30
> > +#define MT8183_DISP_MUTEX0_MOD00x30
> > +#define MT8183_DISP_MUTEX0_SOF00x2c
> >
> > #define DISP_REG_MUTEX_EN(n) (0x20 + 0x20 * (n))
> > #define DISP_REG_MUTEX(n) (0x24 + 0x20 * (n))
> > @@ -25,6 +27,18 @@
> >
> > #define INT_MUTEX BIT(1)
> >
> > +#define MT8183_MUTEX_MOD_DISP_RDMA00
> > +#define MT8183_MUTEX_MOD_DISP_RDMA11
> > +#define MT8183_MUTEX_MOD_DISP_OVL0 9
> > +#define MT8183_MUTEX_MOD_DISP_OVL0_2L 10
> > +#define MT8183_MUTEX_MOD_DISP_OVL1_2L 11
> > +#define MT8183_MUTEX_MOD_DISP_WDMA012
> > +#define MT8183_MUTEX_MOD_DISP_COLOR0 13
> > +#define MT8183_MUTEX_MOD_DISP_CCORR0 14
> > +#define MT8183_MUTEX_MOD_DISP_AAL0 15
> > +#define MT8183_MUTEX_MOD_DISP_GAMMA0 16
> > +#define MT8183_MUTEX_MOD_DISP_DITHER0 17
> > +
> > #define MT8173_MUTEX_MOD_DISP_OVL011
> > #define MT8173_MUTEX_MOD_DISP_OVL112
> > #define MT8173_MUTEX_MOD_DISP_RDMA0 13
> > @@ -74,6 +88,10 @@
> > #define MUTEX_SOF_DSI25
> > #define MUTEX_SOF_DSI36
> >
> > +#define MT8183_MUTEX_SOF_DPI0 2
> > +#define MT8183_MUTEX_EOF_DSI0
[PATCH v2 4/4] xen: add helpers to allocate unpopulated memory
To be used in order to create foreign mappings. This is based on the
ZONE_DEVICE facility which is used by persistent memory devices in
order to create struct pages and kernel virtual mappings for the IOMEM
areas of such devices. Note that on kernels without support for
ZONE_DEVICE Xen will fallback to use ballooned pages in order to
create foreign mappings.
The newly added helpers use the same parameters as the existing
{alloc/free}_xenballooned_pages functions, which allows for in-place
replacement of the callers. Once a memory region has been added to be
used as scratch mapping space it will no longer be released, and pages
returned are kept in a linked list. This allows to have a buffer of
pages and prevents resorting to frequent additions and removals of
regions.
If enabled (because ZONE_DEVICE is supported) the usage of the new
functionality untangles Xen balloon and RAM hotplug from the usage of
unpopulated physical memory ranges to map foreign pages, which is the
correct thing to do in order to avoid mappings of foreign pages depend
on memory hotplug.
Signed-off-by: Roger Pau Monné
---
I've not added a new memory_type type and just used
MEMORY_DEVICE_DEVDAX which seems to be what we want for such memory
regions. I'm unsure whether abusing this type is fine, or if I should
instead add a specific type, maybe MEMORY_DEVICE_GENERIC? I don't
think we should be using a specific Xen type at all.
---
Cc: Oleksandr Andrushchenko
Cc: David Airlie
Cc: Daniel Vetter
Cc: Boris Ostrovsky
Cc: Juergen Gross
Cc: Stefano Stabellini
Cc: Dan Carpenter
Cc: Roger Pau Monne
Cc: Wei Liu
Cc: Yan Yankovskyi
Cc: dri-devel@lists.freedesktop.org
Cc: xen-de...@lists.xenproject.org
Cc: linux...@kvack.org
Cc: David Hildenbrand
Cc: Michal Hocko
---
drivers/gpu/drm/xen/xen_drm_front_gem.c | 8 +-
drivers/xen/Makefile| 1 +
drivers/xen/balloon.c | 4 +-
drivers/xen/grant-table.c | 4 +-
drivers/xen/privcmd.c | 4 +-
drivers/xen/unpopulated-alloc.c | 222
drivers/xen/xenbus/xenbus_client.c | 6 +-
drivers/xen/xlate_mmu.c | 4 +-
include/xen/xen.h | 8 +
9 files changed, 246 insertions(+), 15 deletions(-)
create mode 100644 drivers/xen/unpopulated-alloc.c
diff --git a/drivers/gpu/drm/xen/xen_drm_front_gem.c
b/drivers/gpu/drm/xen/xen_drm_front_gem.c
index f0b85e094111..9dd06eae767a 100644
--- a/drivers/gpu/drm/xen/xen_drm_front_gem.c
+++ b/drivers/gpu/drm/xen/xen_drm_front_gem.c
@@ -99,8 +99,8 @@ static struct xen_gem_object *gem_create(struct drm_device
*dev, size_t size)
* allocate ballooned pages which will be used to map
* grant references provided by the backend
*/
- ret = alloc_xenballooned_pages(xen_obj->num_pages,
- xen_obj->pages);
+ ret = xen_alloc_unpopulated_pages(xen_obj->num_pages,
+ xen_obj->pages);
if (ret < 0) {
DRM_ERROR("Cannot allocate %zu ballooned pages: %d\n",
xen_obj->num_pages, ret);
@@ -152,8 +152,8 @@ void xen_drm_front_gem_free_object_unlocked(struct
drm_gem_object *gem_obj)
} else {
if (xen_obj->pages) {
if (xen_obj->be_alloc) {
- free_xenballooned_pages(xen_obj->num_pages,
- xen_obj->pages);
+ xen_free_unpopulated_pages(xen_obj->num_pages,
+ xen_obj->pages);
gem_free_pages_array(xen_obj);
} else {
drm_gem_put_pages(&xen_obj->base,
diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index 0d322f3d90cd..788a5d9c8ef0 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -42,3 +42,4 @@ xen-gntdev-$(CONFIG_XEN_GNTDEV_DMABUF)+=
gntdev-dmabuf.o
xen-gntalloc-y := gntalloc.o
xen-privcmd-y := privcmd.o privcmd-buf.o
obj-$(CONFIG_XEN_FRONT_PGDIR_SHBUF)+= xen-front-pgdir-shbuf.o
+obj-$(CONFIG_ZONE_DEVICE) += unpopulated-alloc.o
diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
index b1d8b028bf80..815ef10eb2ff 100644
--- a/drivers/xen/balloon.c
+++ b/drivers/xen/balloon.c
@@ -654,7 +654,7 @@ void free_xenballooned_pages(int nr_pages, struct page
**pages)
}
EXPORT_SYMBOL(free_xenballooned_pages);
-#ifdef CONFIG_XEN_PV
+#if defined(CONFIG_XEN_PV) && !defined(CONFIG_ZONE_DEVICE)
static void __init balloon_add_region(unsigned long start_pfn,
unsigned long pages)
{
@@ -708,7 +708,7 @@ static int __init balloon_init(void)
register_sysctl_table(xen_ro
Re: [PATCH 1/2] dt-bindings: Add DT bindings for Toshiba TC358762 DSI-to-DPI bridge
On 7/26/20 9:06 AM, Sam Ravnborg wrote: > Hi Marek. Hi, > On Sat, Jul 25, 2020 at 11:14:56PM +0200, Marek Vasut wrote: >> Add DT bindings for Toshiba TC358762 DSI-to-DPI bridge, this >> one is used in the Raspberry Pi 7" touchscreen display unit. [...] > This looks like a candidate for the simple-bridge-yaml binding. > Did you check if this is sufficient or we really need a new binding? The binding says "Transparent non-programmable DRM bridges", but this TC358762 one is programmable, so I would expect a separate binding file is better in case the driver evolves and needs more DT properties. > If we need a new binding then they to take a look at how simple-bridge > define the ports. You can do this in a simple way than what is used > here. > It looks like this was copied from toshiba,tc358768.yaml, but there are > better examples to follow. I took a subset of the file. [...] ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/3] drm/panel: simple: Add DT bindings for Powertip PH800480T013
Add support for Powertip PH800480T013 800x480 parallel LCD, this
one is used in the Raspberry Pi 7" touchscreen display unit.
Signed-off-by: Marek Vasut
To: dri-devel@lists.freedesktop.org
Cc: Eric Anholt
Cc: Rob Herring
Cc: Sam Ravnborg
Cc: devicet...@vger.kernel.org
---
drivers/gpu/drm/panel/panel-simple.c | 24
1 file changed, 24 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index af6ea5480c81..6bf6604ca78e 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -2986,6 +2986,27 @@ static const struct panel_desc pda_91_00156_a0 = {
.bus_format = MEDIA_BUS_FMT_RGB888_1X24,
};
+static const struct drm_display_mode powertip_ph800480t013_idf02_mode = {
+ .clock = 24750,
+ .hdisplay = 800,
+ .hsync_start = 800 + 54,
+ .hsync_end = 800 + 54 + 2,
+ .htotal = 800 + 54 + 2 + 44,
+ .vdisplay = 480,
+ .vsync_start = 480 + 49,
+ .vsync_end = 480 + 49 + 2,
+ .vtotal = 480 + 49 + 2 + 22,
+};
+
+static const struct panel_desc powertip_ph800480t013_idf02 = {
+ .modes = &powertip_ph800480t013_idf02_mode,
+ .num_modes = 1,
+ .size = {
+ .width = 152,
+ .height = 91,
+ },
+ .bus_format = MEDIA_BUS_FMT_RGB888_1X24,
+};
static const struct drm_display_mode qd43003c0_40_mode = {
.clock = 9000,
@@ -3998,6 +4019,9 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "pda,91-00156-a0",
.data = &pda_91_00156_a0,
+ }, {
+ .compatible = "powertip,ph800480t013-idf02",
+ .data = &powertip_ph800480t013_idf02,
}, {
.compatible = "qiaodian,qd43003c0-40",
.data = &qd43003c0_40,
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 9/9] soc/qcom: Add REVID driver
From: Xiaozhe Shi
Add the REVID device driver. The REVID driver will print out the PMIC
revision at probe time.
Signed-off-by: Xiaozhe Shi
[konradyb...@gmail.com: Fast-forward the driver from kernel 4.14 to 5.8,
convert binding to yaml]
Signed-off-by: Konrad Dybcio
---
.../bindings/soc/qcom/qcom,qpnp-revid.yaml| 38 ++
drivers/soc/qcom/Kconfig | 9 +
drivers/soc/qcom/Makefile | 1 +
drivers/soc/qcom/qpnp-revid.c | 288 ++
include/linux/qpnp/qpnp-revid.h | 369 ++
5 files changed, 705 insertions(+)
create mode 100644
Documentation/devicetree/bindings/soc/qcom/qcom,qpnp-revid.yaml
create mode 100644 drivers/soc/qcom/qpnp-revid.c
create mode 100644 include/linux/qpnp/qpnp-revid.h
diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,qpnp-revid.yaml
b/Documentation/devicetree/bindings/soc/qcom/qcom,qpnp-revid.yaml
new file mode 100644
index ..fa4a15d7cc15
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,qpnp-revid.yaml
@@ -0,0 +1,38 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/soc/qcom/qcom,qpnp-revid.yaml#";
+$schema: "http://devicetree.org/meta-schemas/core.yaml#";
+
+title: QPNP-REVID
+
+description: |
+ QPNP-REVID provides a way to read the PMIC part number and revision.
+
+properties:
+ compatible:
+enum:
+ - qcom,qpnp-revid
+
+ reg:
+description: Offset and length of the PMIC peripheral register map.
+maxItems: 1
+
+ qcom,fab-id-valid:
+description: |
+ Use this property when support to read Fab
+ identification from REV ID peripheral is available.
+
+ qcom,tp-rev-valid:
+description: |
+ Use this property when support to read TP
+ revision identification from REV ID peripheral.
+
+examples:
+ - |
+qcom,revid@100 {
+compatible = "qcom,qpnp-revid";
+reg = <0x100 0x100>;
+};
+
+...
diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
index 07bb261a63d2..03a024acdb37 100644
--- a/drivers/soc/qcom/Kconfig
+++ b/drivers/soc/qcom/Kconfig
@@ -75,6 +75,15 @@ config QCOM_QMI_HELPERS
tristate
depends on NET
+config QCOM_QPNP_REVID
+ tristate "QPNP Revision ID Peripheral"
+ depends on SPMI
+ help
+ Say 'y' here to include support for the Qualcomm Technologies, Inc.
+ QPNP REVID peripheral. REVID prints out the PMIC type and revision
+ numbers in the kernel log along with the PMIC option status. The PMIC
+ type is mapped to a QTI chip part number and logged as well.
+
config QCOM_RMTFS_MEM
tristate "Qualcomm Remote Filesystem memory driver"
depends on ARCH_QCOM
diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile
index 7d7e2ecbdce6..d7a4c6b85ede 100644
--- a/drivers/soc/qcom/Makefile
+++ b/drivers/soc/qcom/Makefile
@@ -9,6 +9,7 @@ obj-$(CONFIG_QCOM_OCMEM)+= ocmem.o
obj-$(CONFIG_QCOM_PDR_HELPERS) += pdr_interface.o
obj-$(CONFIG_QCOM_QMI_HELPERS) += qmi_helpers.o
qmi_helpers-y += qmi_encdec.o qmi_interface.o
+obj-$(CONFIG_QCOM_QPNP_REVID) += qpnp-revid.o
obj-$(CONFIG_QCOM_RMTFS_MEM) += rmtfs_mem.o
obj-$(CONFIG_QCOM_RPMH)+= qcom_rpmh.o
qcom_rpmh-y+= rpmh-rsc.o
diff --git a/drivers/soc/qcom/qpnp-revid.c b/drivers/soc/qcom/qpnp-revid.c
new file mode 100644
index ..edae0b299847
--- /dev/null
+++ b/drivers/soc/qcom/qpnp-revid.c
@@ -0,0 +1,288 @@
+/* Copyright (c) 2013-2019, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define REVID_REVISION10x0
+#define REVID_REVISION20x1
+#define REVID_REVISION30x2
+#define REVID_REVISION40x3
+#define REVID_TYPE 0x4
+#define REVID_SUBTYPE 0x5
+#define REVID_STATUS1 0x8
+#define REVID_SPARE_0 0x60
+#define REVID_TP_REV 0xf1
+#define REVID_FAB_ID 0xf2
+
+#define QPNP_REVID_DEV_NAME "qcom,qpnp-revid"
+
+static const char *const pmic_names[] = {
+ [0] = "Unknown PMIC",
+ [PM8941_SUBTYPE] = "PM8941",
+ [PM8841_SUBTYPE] = "PM8841",
+ [PM8019_SUBTYPE] = "PM8019",
+ [PM8226_SUBTYPE] = "PM8226",
+ [PM8110_SUBTYPE] = "PM8110",
+ [PMA8084_SUBTYPE] = "PMA8084",
+ [PMI8962_SUBTYPE] = "PMI8962",
+ [PMD9635_SUBTYPE] = "PMD9635",
+ [PM8994_SUBTYPE] = "PM8994",
+ [PMI8994_S
Re: [PATCH] amdgpu_dm: fix nonblocking atomic commit use-after-free
Dear Kees,
Am 24.07.20 um 19:33 schrieb Kees Cook:
On Fri, Jul 24, 2020 at 09:45:18AM +0200, Paul Menzel wrote:
Am 24.07.20 um 00:32 schrieb Kees Cook:
On Thu, Jul 23, 2020 at 09:10:15PM +, Mazin Rezk wrote:
As Linux 5.8-rc7 is going to be released this Sunday, I wonder, if commit
3202fa62f ("slub: relocate freelist pointer to middle of object") should be
reverted for now to fix the regression for the users according to Linux’ no
regression policy. Once the AMDGPU/DRM driver issue is fixed, it can be
reapplied. I know it’s not optimal, but as some testing is going to be
involved for the fix, I’d argue it’s the best option for the users.
Well, the SLUB defense was already released in v5.7, so I'm not sure it
really helps for amdgpu_dm users seeing it there too.
In my opinion, it would help, as the stable release could pick up the
revert, ones it’s in Linus’ master branch.
There was a fix to disable the async path for this driver that worked
around the bug too, yes? That seems like a safer and more focused
change that doesn't revert the SLUB defense for all users, and would
actually provide a complete, I think, workaround whereas reverting
the SLUB change means the race still exists. For example, it would be
hit with slab poisoning, etc.
I do not know. If there is such a fix, that would be great. But if you
do not know, how should a normal user? ;-)
Kind regards,
Paul
Kind regards,
Paul
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [v7, PATCH 7/7] drm/mediatek: add support for mediatek SOC MT8183
On Sat, 2020-07-25 at 07:24 +0800, Chun-Kuang Hu wrote:
> Hi Yongqiang:
>
> Yongqiang Niu 於 2020年7月23日 週四 上午10:15寫道：
> >
> > This patch add support for mediatek SOC MT8183
> > 1.ovl_2l share driver with ovl
>
> I think this is done in [1], [2], [3], this patch just add the support
> of mt8183-ovl and mt8183-ovl-2l.
>
> [1]
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/gpu/drm/mediatek?h=v5.8-rc6&id=132c6e250ed745443973cada8db17cdbaebdf551
> [2]
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/gpu/drm/mediatek?h=v5.8-rc6&id=318462d1a568634ba09263cc730cb0fb1d56c2b3
> [3]
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/gpu/drm/mediatek?h=v5.8-rc6&id=57148baac8b78461e394953cfd5317bde8f795ab
>
> > 2.rdma1 share drive with rdma0, but fifo size is different
>
> I think this is done in [4], this patch just add the support of mt8183-rdma.
>
> [4] https://patchwork.kernel.org/patch/11679549/
>
> > 3.add mt8183 mutex private data, and mmsys private data
> > 4.add mt8183 main and external path module for crtc create
>
> The fourth item is the mmsys private data in third item, so you need
> not to repeat it.
>
i will remove some useless description in next version.
> >
> > Signed-off-by: Yongqiang Niu
> > ---
> > drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 18
> > drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 6
> > drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 47
> >
> > drivers/gpu/drm/mediatek/mtk_drm_drv.c | 43 +
> > 4 files changed, 114 insertions(+)
> >
>
> [snip]
>
> > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> > b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> > index 014c1bb..60788c1 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> > @@ -15,6 +15,8 @@
> >
> > #define MT2701_DISP_MUTEX0_MOD00x2c
> > #define MT2701_DISP_MUTEX0_SOF00x30
> > +#define MT8183_DISP_MUTEX0_MOD00x30
> > +#define MT8183_DISP_MUTEX0_SOF00x2c
> >
> > #define DISP_REG_MUTEX_EN(n) (0x20 + 0x20 * (n))
> > #define DISP_REG_MUTEX(n) (0x24 + 0x20 * (n))
> > @@ -25,6 +27,18 @@
> >
> > #define INT_MUTEX BIT(1)
> >
> > +#define MT8183_MUTEX_MOD_DISP_RDMA00
> > +#define MT8183_MUTEX_MOD_DISP_RDMA11
> > +#define MT8183_MUTEX_MOD_DISP_OVL0 9
> > +#define MT8183_MUTEX_MOD_DISP_OVL0_2L 10
> > +#define MT8183_MUTEX_MOD_DISP_OVL1_2L 11
> > +#define MT8183_MUTEX_MOD_DISP_WDMA012
> > +#define MT8183_MUTEX_MOD_DISP_COLOR0 13
> > +#define MT8183_MUTEX_MOD_DISP_CCORR0 14
> > +#define MT8183_MUTEX_MOD_DISP_AAL0 15
> > +#define MT8183_MUTEX_MOD_DISP_GAMMA0 16
> > +#define MT8183_MUTEX_MOD_DISP_DITHER0 17
> > +
> > #define MT8173_MUTEX_MOD_DISP_OVL0 11
> > #define MT8173_MUTEX_MOD_DISP_OVL1 12
> > #define MT8173_MUTEX_MOD_DISP_RDMA013
> > @@ -74,6 +88,10 @@
> > #define MUTEX_SOF_DSI2 5
> > #define MUTEX_SOF_DSI3 6
> >
> > +#define MT8183_MUTEX_SOF_DPI0 2
> > +#define MT8183_MUTEX_EOF_DSI0 (MUTEX_SOF_DSI0 << 6)
> > +#define MT8183_MUTEX_EOF_DPI0 (MT8183_MUTEX_SOF_DPI0 << 6)
> > +
> >
> > struct mtk_disp_mutex {
> > int id;
> > @@ -153,6 +171,20 @@ struct mtk_ddp {
> > [DDP_COMPONENT_WDMA1] = MT8173_MUTEX_MOD_DISP_WDMA1,
> > };
> >
> > +static const unsigned int mt8183_mutex_mod[DDP_COMPONENT_ID_MAX] = {
> > + [DDP_COMPONENT_AAL0] = MT8183_MUTEX_MOD_DISP_AAL0,
> > + [DDP_COMPONENT_CCORR] = MT8183_MUTEX_MOD_DISP_CCORR0,
> > + [DDP_COMPONENT_COLOR0] = MT8183_MUTEX_MOD_DISP_COLOR0,
> > + [DDP_COMPONENT_DITHER] = MT8183_MUTEX_MOD_DISP_DITHER0,
> > + [DDP_COMPONENT_GAMMA] = MT8183_MUTEX_MOD_DISP_GAMMA0,
> > + [DDP_COMPONENT_OVL0] = MT8183_MUTEX_MOD_DISP_OVL0,
> > + [DDP_COMPONENT_OVL_2L0] = MT8183_MUTEX_MOD_DISP_OVL0_2L,
> > + [DDP_COMPONENT_OVL_2L1] = MT8183_MUTEX_MOD_DISP_OVL1_2L,
> > + [DDP_COMPONENT_RDMA0] = MT8183_MUTEX_MOD_DISP_RDMA0,
> > + [DDP_COMPONENT_RDMA1] = MT8183_MUTEX_MOD_DISP_RDMA1,
> > + [DDP_COMPONENT_WDMA0] = MT8183_MUTEX_MOD_DISP_WDMA0,
> > +};
> > +
> > static const unsigned int mt2712_mutex_sof[DDP_MUTEX_SOF_DSI3 + 1] = {
> > [DDP_MUTEX_SOF_SINGLE_MODE] = MUTEX_SOF_SINGLE_MODE,
> > [DDP_MUTEX_SOF_DSI0] = MUTEX_SOF_DSI0,
> > @@ -163,6 +195,12 @@ struct mtk_ddp {
> > [DDP_MUTEX_SOF_DSI3] = MUTEX_SOF_DSI3,
> > };
> >
> > +static const unsigned int mt8183_mutex_sof[DDP_MUTEX_SOF_DSI3 + 1] = {
> > + [DDP_MUTEX_SOF_SINGLE_MODE] = MUTEX_SOF_SINGLE_MODE,
> > + [DDP_MUTE
[PATCH -next] vc: Fix build errors
Build errors are seen on MIPS platforms because of
vc state separation and the following build erros
were reported.
../linux/drivers/video/console/newport_con.c: In function ‘newport_clear’:
../linux/drivers/video/console/newport_con.c:365:15: error:
‘struct vc_data’ has no member named ‘vc_color’; did you mean ‘vc_cols’?
(vc->vc_color & 0xf0) >> 4);
^~~~
vc_cols
../linux/drivers/video/console/newport_con.c:368:15: error:
‘struct vc_data’ has no member named ‘vc_color’; did you mean ‘vc_cols’?
(vc->vc_color & 0xf0) >> 4);
^~~~
vc_cols
../linux/drivers/video/console/newport_con.c:370:15: error:
‘struct vc_data’ has no member named ‘vc_color’; did you mean ‘vc_cols’?
(vc->vc_color & 0xf0) >> 4);
^~~~
vc_cols
../linux/drivers/video/console/newport_con.c: In function ‘newport_scroll’:
../linux/drivers/video/console/newport_con.c:594:15: error:
‘struct vc_data’ has no member named ‘vc_color’; did you mean ‘vc_cols’?
(vc->vc_color & 0xf0) >> 4);
^~~~
vc_cols
../linux/drivers/video/console/newport_con.c:598:15: error:
‘struct vc_data’ has no member named ‘vc_color’; did you mean ‘vc_cols’?
(vc->vc_color & 0xf0) >> 4);
^~~~
vc_cols
make[4]: *** [/scratch/linux/scripts/Makefile.build:280:
drivers/video/console/newport_con.o] Error 1
make[3]: *** [/scratch/linux/scripts/Makefile.build:497: drivers/video/console]
Error 2
make[3]: *** Waiting for unfinished jobs
Fixes: 28bc24fc46f9 ("vc: separate state")
Signed-off-by: Ming Li
Cc: Jiri Slaby
Cc: Greg Kroah-Hartman
Cc: Bartlomiej Zolnierkiewicz
---
drivers/video/console/newport_con.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/video/console/newport_con.c
b/drivers/video/console/newport_con.c
index df3c52d72159..72f146d047d9 100644
--- a/drivers/video/console/newport_con.c
+++ b/drivers/video/console/newport_con.c
@@ -362,12 +362,12 @@ static void newport_clear(struct vc_data *vc, int sy, int
sx, int height,
if (ystart < yend) {
newport_clear_screen(sx << 3, ystart, xend, yend,
-(vc->vc_color & 0xf0) >> 4);
+(vc->state.color & 0xf0) >> 4);
} else {
newport_clear_screen(sx << 3, ystart, xend, 1023,
-(vc->vc_color & 0xf0) >> 4);
+(vc->state.color & 0xf0) >> 4);
newport_clear_screen(sx << 3, 0, xend, yend,
-(vc->vc_color & 0xf0) >> 4);
+(vc->state.color & 0xf0) >> 4);
}
}
@@ -591,11 +591,11 @@ static bool newport_scroll(struct vc_data *vc, unsigned
int t, unsigned int b,
topscan = (topscan + (lines << 4)) & 0x3ff;
newport_clear_lines(vc->vc_rows - lines,
vc->vc_rows - 1,
- (vc->vc_color & 0xf0) >> 4);
+ (vc->state.color & 0xf0) >> 4);
} else {
topscan = (topscan + (-lines << 4)) & 0x3ff;
newport_clear_lines(0, lines - 1,
- (vc->vc_color & 0xf0) >> 4);
+ (vc->state.color & 0xf0) >> 4);
}
npregs->cset.topscan = (topscan - 1) & 0x3ff;
return false;
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: nouveau regression with 5.7 caused by "PCI/PM: Assume ports without DLL Link Active train links in 100 ms"
On Thu, Jul 23, 2020 at 10:30:58PM +0200, Karol Herbst wrote: > On Wed, Jul 22, 2020 at 11:25 AM Mika Westerberg > wrote: > > > > On Tue, Jul 21, 2020 at 01:37:12PM -0500, Patrick Volkerding wrote: > > > On 7/21/20 10:27 AM, Mika Westerberg wrote: > > > > On Tue, Jul 21, 2020 at 11:01:55AM -0400, Lyude Paul wrote: > > > >> Sure thing. Also, feel free to let me know if you'd like access to one > > > >> of the > > > >> systems we saw breaking with this patch - I'm fairly sure I've got one > > > >> of them > > > >> locally at my apartment and don't mind setting up AMT/KVM/SSH > > > > Probably no need for remote access (thanks for the offer, though). I > > > > attached a test patch to the bug report: > > > > > > > > https://bugzilla.kernel.org/show_bug.cgi?id=208597 > > > > > > > > that tries to work it around (based on the ->pm_cap == 0). I wonder if > > > > anyone would have time to try it out. > > > > > > > > > Hi Mika, > > > > > > I can confirm that this patch applied to 5.4.52 fixes the issue with > > > hybrid graphics on the Thinkpad X1 Extreme gen2. > > > > Great, thanks for testing! > > > > yeah, works on the P1G2 as well. Thanks for testing! Since we have the revert queued for this release cycle, I think I will send an updated version of "PCI/PM: Assume ports without DLL Link Active train links in 100 ms" after v5.9-rc1 is released that has this workaround in place. (I'm continuing my vacation so will be offline next week). ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/bridge: tc358762: Add basic driver for Toshiba TC358762 DSI-to-DPI bridge
Add very basic driver for Toshiba TC358762 DSI-to-DPI bridge, derived
from tc358764 driver and panel-raspberrypi-touchscreen. This driver is
meant to replace the panel-raspberrypi-touchscreen too, as the bridge
connection can be described in DT too.
Signed-off-by: Marek Vasut
To: dri-devel@lists.freedesktop.org
Cc: Eric Anholt
Cc: Rob Herring
Cc: Sam Ravnborg
Cc: devicet...@vger.kernel.org
---
drivers/gpu/drm/bridge/Kconfig| 9 +
drivers/gpu/drm/bridge/Makefile | 1 +
drivers/gpu/drm/bridge/tc358762.c | 352 ++
3 files changed, 362 insertions(+)
create mode 100644 drivers/gpu/drm/bridge/tc358762.c
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 43271c21d3fc..3e76e3fccb78 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -153,6 +153,15 @@ config DRM_THINE_THC63LVD1024
help
Thine THC63LVD1024 LVDS/parallel converter driver.
+config DRM_TOSHIBA_TC358762
+ tristate "TC358762 DSI/DPI bridge"
+ depends on OF
+ select DRM_MIPI_DSI
+ select DRM_KMS_HELPER
+ select DRM_PANEL
+ help
+ Toshiba TC358762 DSI/DPI bridge driver.
+
config DRM_TOSHIBA_TC358764
tristate "TC358764 DSI/LVDS bridge"
depends on OF
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index d63d4b7e4347..b341c60ee96a 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_DRM_SII902X) += sii902x.o
obj-$(CONFIG_DRM_SII9234) += sii9234.o
obj-$(CONFIG_DRM_SIMPLE_BRIDGE) += simple-bridge.o
obj-$(CONFIG_DRM_THINE_THC63LVD1024) += thc63lvd1024.o
+obj-$(CONFIG_DRM_TOSHIBA_TC358762) += tc358762.o
obj-$(CONFIG_DRM_TOSHIBA_TC358764) += tc358764.o
obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o
obj-$(CONFIG_DRM_TOSHIBA_TC358768) += tc358768.o
diff --git a/drivers/gpu/drm/bridge/tc358762.c
b/drivers/gpu/drm/bridge/tc358762.c
new file mode 100644
index ..6eb0c0c10623
--- /dev/null
+++ b/drivers/gpu/drm/bridge/tc358762.c
@@ -0,0 +1,352 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2020 Marek Vasut
+ *
+ * Based on tc358764.c by
+ * Andrzej Hajda
+ * Maciej Purski
+ *
+ * Based on rpi_touchscreen.c by
+ * Eric Anholt
+ */
+
+#include
+#include
+#include
+#include
+
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* PPI layer registers */
+#define PPI_STARTPPI 0x0104 /* START control bit */
+#define PPI_LPTXTIMECNT0x0114 /* LPTX timing signal */
+#define PPI_D0S_ATMR 0x0144
+#define PPI_D1S_ATMR 0x0148
+#define PPI_D0S_CLRSIPOCOUNT 0x0164 /* Assertion timer for Lane 0 */
+#define PPI_D1S_CLRSIPOCOUNT 0x0168 /* Assertion timer for Lane 1 */
+#define PPI_START_FUNCTION 1
+
+/* DSI layer registers */
+#define DSI_STARTDSI 0x0204 /* START control bit of DSI-TX */
+#define DSI_LANEENABLE 0x0210 /* Enables each lane */
+#define DSI_RX_START 1
+
+/* LCDC/DPI Host Registers */
+#define LCDCTRL0x0420
+
+/* SPI Master Registers */
+#define SPICMR 0x0450
+#define SPITCR 0x0454
+
+/* System Controller Registers */
+#define SYSCTRL0x0464
+
+/* System registers */
+#define LPX_PERIOD 3
+
+/* Lane enable PPI and DSI register bits */
+#define LANEENABLE_CLENBIT(0)
+#define LANEENABLE_L0ENBIT(1)
+#define LANEENABLE_L1ENBIT(2)
+
+struct tc358762 {
+ struct device *dev;
+ struct drm_bridge bridge;
+ struct drm_connector connector;
+ struct regulator *regulator;
+ struct drm_panel *panel;
+ bool pre_enabled;
+ int error;
+};
+
+static int tc358762_clear_error(struct tc358762 *ctx)
+{
+ int ret = ctx->error;
+
+ ctx->error = 0;
+ return ret;
+}
+
+static void tc358762_write(struct tc358762 *ctx, u16 addr, u32 val)
+{
+ struct mipi_dsi_device *dsi = to_mipi_dsi_device(ctx->dev);
+ ssize_t ret;
+ u8 data[6];
+
+ if (ctx->error)
+ return;
+
+ data[0] = addr;
+ data[1] = addr >> 8;
+ data[2] = val;
+ data[3] = val >> 8;
+ data[4] = val >> 16;
+ data[5] = val >> 24;
+
+ ret = mipi_dsi_generic_write(dsi, data, sizeof(data));
+ if (ret < 0)
+ ctx->error = ret;
+}
+
+static inline struct tc358762 *bridge_to_tc358762(struct drm_bridge *bridge)
+{
+ return container_of(bridge, struct tc358762, bridge);
+}
+
+static inline
+struct tc358762 *connector_to_tc358762(struct drm_connector *connector)
+{
+ return container_of(connector, struct tc358762, connector);
+}
+
+static int tc358762_init(struct tc358762 *ctx)
+{
+ tc358762_write(ctx, DSI_LANEENABLE,
+ LANEENABLE_L0EN | LANEENABLE_CLEN);
+ tc358762_
[PATCH] drm/sun4i: mixer: Enable register value caching
It was discovered in the past by Ondrej Jirman that mixer register read
may occasionally return wrong value, most likely zero. It turns out
that all mixer units are affected by this issue. This becomes especially
obvious with applications like video player. After a few minutes of a
playback visual glitches appeared but not always in the same way. After
register inspection it was clear that some bits are not set even when
they should be.
Best solution would be to shuffle the code a bit to avoid
read-modify-write operations and use only register writes. However,
quicker solution is to enable caching support in regmap which is also
used here. Such fix is also easier to backport in stable kernels.
Fixes: 9d75b8c0b999 ("drm/sun4i: add support for Allwinner DE2 mixers")
Signed-off-by: Jernej Skrabec
---
drivers/gpu/drm/sun4i/sun8i_mixer.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.c
b/drivers/gpu/drm/sun4i/sun8i_mixer.c
index cc4fb916318f..f8f17c51c96d 100644
--- a/drivers/gpu/drm/sun4i/sun8i_mixer.c
+++ b/drivers/gpu/drm/sun4i/sun8i_mixer.c
@@ -303,11 +303,23 @@ static const struct sunxi_engine_ops sun8i_engine_ops = {
.layers_init= sun8i_layers_init,
};
+static bool sun8i_mixer_volatile_reg(struct device *dev, unsigned int reg)
+{
+ switch (reg) {
+ case SUN8I_MIXER_GLOBAL_STATUS:
+ case SUN8I_MIXER_GLOBAL_DBUFF:
+ return true;
+ }
+ return false;
+}
+
static struct regmap_config sun8i_mixer_regmap_config = {
+ .cache_type = REGCACHE_FLAT,
.reg_bits = 32,
.val_bits = 32,
.reg_stride = 4,
.max_register = 0xbfffc, /* guessed */
+ .volatile_reg = sun8i_mixer_volatile_reg,
};
static int sun8i_mixer_of_get_id(struct device_node *node)
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 5/5] drm: rockchip: use overlay windows as such
On 18/07/20 22:03, Alex Bee wrote:
static const int rk3188_vop_intrs[] = {
@@ -980,7 +980,7 @@ static const struct vop_win_data rk3228_vop_win_data[] = {
{ .base = 0x00, .phy = &rk3288_win01_data,
.type = DRM_PLANE_TYPE_PRIMARY },
{ .base = 0x40, .phy = &rk3288_win01_data,
- .type = DRM_PLANE_TYPE_CURSOR },
+ .type = DRM_PLANE_TYPE_OVERLAY },
};
static const struct vop_data rk3228_vop = {
Tried on several rk322x boards, it worked fine.
Tested-by: Paolo Sabatino
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 9/9] soc/qcom: Add REVID driver
Hi Greg, thanks for your review! >Why do we need this noise in the kernel log? I guess it could be left there as a debug print? Knowing your hardware revision seems like a good, but yeah, not a necessary thing. >You can drop the GPL boilerplate text and add a proper SPDX line at the >top. Seems I only did that in my other local tree.. whoops! >Drivers should always use dev_err() and friends, as you have access to a >struct device * always. Please fix up the driver here to use that api >instead, no pr_* should be needed at all. Will do. >Horrible global symbol name. Who calls this? Welcome to development on qcom platforms :D >This is the last patch in >the series, so if there is no user for this, please don't export it. Other downstream drivers make use of it.. need to get this up first, sorry :V >Why do you need a .h file in the include directory if only a single .c >file needs it? Just put that info in the .c file itself. Again, other downstream drivers which some people and I intend to bring to upstream standards use that to access the PMIC model/hw revision. >But again, who uses this module? If it's only good for a single line in >the kernel log, that feels like a huge waste to me. downstream-kernel-dir$ rg -l qpnp-revid.h | wc -l 25 So yeah, quite a bunch of other qcom-specific drivers. I'll try to fix these and send a v2. Regards Konrad ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/bridge: tc358762: Add basic driver for Toshiba TC358762 DSI-to-DPI bridge
On 7/26/20 9:15 AM, Sam Ravnborg wrote: > Hi Marek. Hi, > On Sat, Jul 25, 2020 at 11:14:57PM +0200, Marek Vasut wrote: >> Add very basic driver for Toshiba TC358762 DSI-to-DPI bridge, derived >> from tc358764 driver and panel-raspberrypi-touchscreen. This driver is >> meant to replace the panel-raspberrypi-touchscreen too, as the bridge >> connection can be described in DT too. >> >> Signed-off-by: Marek Vasut >> To: dri-devel@lists.freedesktop.org >> Cc: Eric Anholt >> Cc: Rob Herring >> Cc: Sam Ravnborg >> Cc: devicet...@vger.kernel.org >> --- > > Two general comments. > - This driver should use the bridge panel - this will simplify the > driver in many places. We already have several good examples in-tree > that does this. Can you list such an example ? > - The driver does not respect the "flags" argument in the attach > operation. All new bridge drivers shall respect the flags operation to > prepare for use in a setup with chained bridges. > In short the flags is used to determine if the display driver or the > bridge creates the connector. > When the bridge panel is introduced you can drop all the connector > creation code and just pass the flag to the bridge panel. > The bridge panel will then create the connector if requested. > This is possible because this simple bridge driver does not add > anything to the connector that the bridge panel does not know. OK ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/9] clk: qcom: gcc-sdm660: Add missing modem reset
This will be required in order to support the
modem upstream.
Signed-off-by: Konrad Dybcio
---
drivers/clk/qcom/gcc-sdm660.c | 1 +
include/dt-bindings/clock/qcom,gcc-sdm660.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/clk/qcom/gcc-sdm660.c b/drivers/clk/qcom/gcc-sdm660.c
index bf5730832ef3..a85283786278 100644
--- a/drivers/clk/qcom/gcc-sdm660.c
+++ b/drivers/clk/qcom/gcc-sdm660.c
@@ -2402,6 +2402,7 @@ static const struct qcom_reset_map gcc_sdm660_resets[] = {
[GCC_USB_20_BCR] = { 0x2f000 },
[GCC_USB_30_BCR] = { 0xf000 },
[GCC_USB_PHY_CFG_AHB2PHY_BCR] = { 0x6a000 },
+ [GCC_MSS_RESTART] = { 0x79000 },
};
static const struct regmap_config gcc_sdm660_regmap_config = {
diff --git a/include/dt-bindings/clock/qcom,gcc-sdm660.h
b/include/dt-bindings/clock/qcom,gcc-sdm660.h
index 468302282913..df8a6f3d367e 100644
--- a/include/dt-bindings/clock/qcom,gcc-sdm660.h
+++ b/include/dt-bindings/clock/qcom,gcc-sdm660.h
@@ -152,5 +152,6 @@
#define GCC_USB_20_BCR 6
#define GCC_USB_30_BCR 7
#define GCC_USB_PHY_CFG_AHB2PHY_BCR8
+#define GCC_MSS_RESTART9
#endif
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] newport_con: vc_color is now in state
On 24.07.2020 9:27, Jiri Slaby wrote:
Since commit 28bc24fc46f9 (vc: separate state), vc->vc_color is known as
Cgit says "Bad object id: 28bc24fc46f9" (in Linus' repo). Also, you should
enclose the commit summary in (""), not just ()...
vc->state.color. Somehow both me and 0-day bot missed this driver during
the conversion.
So fix the driver now.
Signed-off-by: Jiri Slaby
Cc: Bartlomiej Zolnierkiewicz
Cc: dri-devel@lists.freedesktop.org
Cc: linux-fb...@vger.kernel.org
Cc: linux-m...@vger.kernel.org
[...]
MBR, Sergei
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 0/5] drm: rockchip: various ports for older VOPs
Am 25.07.20 um 17:54 schrieb Daniel Vetter: On Sat, Jul 25, 2020 at 3:52 PM Alex Bee wrote: Am 22.07.20 um 23:43 schrieb Daniel Vetter: On Wed, Jul 22, 2020 at 8:13 PM Alex Bee wrote: Hi, this series mainly ports existining functionality to older SoCs - most importantly enables alpha blending for RK3036, RK3066, RK3126 and RK3188. Besides that, it also changes the window type from DRM_PLANE_TYPE_CURSOR to DRM_PLANE_TYPE_OVERLAY for VOPs that have only one (1) overlay window. This doesn't make much sense, the cursor overlay is really just a hint for legacy ioctls that this is the overlay that should be used for cursors. Compositors should try to use such planes as full overlays (if they don't want to use them as a cursor). So sounds like a case of "fix your compositor". I agree here - but: If HWC windows would have been implemented in this particular driver, their max size would be 128x128 on some SoCs - so they woudn't be really suitable to create an OSD overlay at 4K, for example. I don't know, but I guess other vendors implement their HWC windows on this reduced HW resources as well. I guess that is one of the reasons, why userspace, which aims to be cross-plattfrom, avoids DRM_PLANE_TYPE_CURSOR when its looking for an usable overlay plane. (a heuristic, indeed) Which userspace does that? kodi-gbm: https://github.com/xbmc/xbmc/blob/master/xbmc/windowing/gbm/DRMUtils.cpp#L406 We should fix that, not try to work around that in all the drivers in upstream, that wont work. You're right I'll drop this part. -Daniel For atomic there's 0 difference between a overlay or a cursor (primary plane is still treated somewhat special in the RMFB ioctl, but again that's for backwards compat reasons with existing uapi, not because the primary plane is different). What does happen though is that this breaks cursor for legacy userspace, which is probably not really what you want. Indeed not. Beforhand I was submiiting this, I looked arround and couldn't find anything which relies or even depends of a cursor window to be available. Even if: as per spec only one DRM_PLANE_TYPE_PRIMARY is mandatory, everything else is optional. -Daniel Regards, Alex Changes in v2: - drop not yet upstreamed dsp_data_swap from RK3188 regs - rephrase most commit messages Alex Bee (5): drm: rockchip: add scaling for RK3036 win1 drm: rockchip: add missing registers for RK3188 drm: rockchip: add alpha support for RK3036, RK3066, RK3126 and RK3188 drm: rockchip: set alpha_en to 0 if it is not used drm: rockchip: use overlay windows as such drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 1 + drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 42 ++--- drivers/gpu/drm/rockchip/rockchip_vop_reg.h | 1 + 3 files changed, 38 insertions(+), 6 deletions(-) -- 2.17.1 -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch Best Regards Best regards ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] video: fbdev: added driver for sharp memory lcd displays
The supported displays are ls027b7dh01 (tested), ls044q7dh01,
ls013b7dh05, ls013b7dh03
Signed-off-by: Rodrigo Alencar <455.rodrigo.alen...@gmail.com>
---
.../devicetree/bindings/display/smemlcdfb.txt | 46 ++
drivers/video/fbdev/Kconfig | 14 +
drivers/video/fbdev/Makefile | 1 +
drivers/video/fbdev/smemlcdfb.c | 485 ++
4 files changed, 546 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/smemlcdfb.txt
create mode 100644 drivers/video/fbdev/smemlcdfb.c
diff --git a/Documentation/devicetree/bindings/display/smemlcdfb.txt
b/Documentation/devicetree/bindings/display/smemlcdfb.txt
new file mode 100644
index ..e33025dd3374
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/smemlcdfb.txt
@@ -0,0 +1,46 @@
+Sharp Memory LCD Linux Framebuffer Driver
+
+Required properties:
+ - compatible: It should be "sharp,". The supported displays are
+ ls027b7dh01, ls044q7dh01, ls013b7dh05, ls013b7dh03. Maybe other
+ monochromatic models can be supported with the current code.
+ - reg: SPI chip select number for the device.
+ - spi-max-frequency: Max SPI frequency to use. One must verify the datasheet.
+ - spi-cs-high: Sharp Memory LCD needs chipselect high.
+
+Optional properties:
+ - sharp,frames-per-sec: It should contain the desired frames per second.
+ It does not represent the actual frame rate. Default: 10
+ - sharp,extmode-high: External COM Input signal is expected in EXTCOMIN port.
+ This is recommended to reduce CPU and SPI Load.
+ - pwm: If property "sharp,extmode-high" is specified, this is recommended.
+ It should contain the pwm to use, according to
+ Documentation/devicetree/bindings/pwm/pwm.txt
+ Verify the display datasheet for the EXTCOMIN signal period
+ - disp-gpios: The GPIO used to enable the display, if available. See
+ Documentation/devicetree/bindings/gpio/gpio.txt for details.
+
+Examples:
+
+ls027b7dh01: smemlcd@0 {
+compatible = "sharp,ls027b7dh01";
+reg = <0>;
+spi-max-frequency = <100>;
+spi-cs-high;
+disp-gpios = <&gpio0 7>;
+disp-active-high;
+sharp,extmode-high;
+pwms = <&pwm 0 1>;
+};
+
+ls013b7dh05: smemlcd@3 {
+compatible = "sharp,ls013b7dh05";
+reg = <3>;
+spi-max-frequency = <100>;
+spi-cs-high;
+disp-gpios = <&gpio0 13>;
+disp-active-high;
+sharp,extmode-high;
+pwms = <&pwm 0 5000>;
+sharp,frames-per-sec = <20>;
+};
diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index b2c9dd4f0cb5..0fff47a59d8b 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -2221,6 +2221,20 @@ config FB_SSD1307
This driver implements support for the Solomon SSD1307
OLED controller over I2C.
+config FB_SMEMLCD
+ tristate "Sharp Memory LCD framebuffer support"
+ depends on FB && SPI
+ depends on OF
+ depends on GPIOLIB || COMPILE_TEST
+ select FB_SYS_FOPS
+ select FB_SYS_FILLRECT
+ select FB_SYS_COPYAREA
+ select FB_SYS_IMAGEBLIT
+ select FB_DEFERRED_IO
+ select PWM
+ help
+ This driver implements support for the Sharp Memory LCD
+
config FB_SM712
tristate "Silicon Motion SM712 framebuffer support"
depends on FB && PCI
diff --git a/drivers/video/fbdev/Makefile b/drivers/video/fbdev/Makefile
index cad4fb64442a..5c58dfd8ac08 100644
--- a/drivers/video/fbdev/Makefile
+++ b/drivers/video/fbdev/Makefile
@@ -128,6 +128,7 @@ obj-$(CONFIG_FB_OF) += offb.o
obj-$(CONFIG_FB_MX3) += mx3fb.o
obj-$(CONFIG_FB_DA8XX) += da8xx-fb.o
obj-$(CONFIG_FB_SSD1307) += ssd1307fb.o
+obj-$(CONFIG_FB_SMEMLCD) += smemlcdfb.o
obj-$(CONFIG_FB_SIMPLE) += simplefb.o
# the test framebuffer is last
diff --git a/drivers/video/fbdev/smemlcdfb.c b/drivers/video/fbdev/smemlcdfb.c
new file mode 100644
index ..54a0c57b6713
--- /dev/null
+++ b/drivers/video/fbdev/smemlcdfb.c
@@ -0,0 +1,485 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright (C) 2019 IMBEL http://www.imbel.gov.br
+ * Rodrigo Alencar
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define SMEMLCD_DATA_UPDATE0x80
+#define SMEMLCD_FRAME_INVERSION0x40
+#define SMEMLCD_ALL_CLEAR 0x20
+#define SMEMLCD_DUMMY_DATA 0x00
+
+struct smemlcd_info {
+ u32 width;
+ u32 height;
+};
+
+struct smemlcd_par {
+ struct spi_device *spi;
+ struct fb_info *info;
+ struct pwm_device *extcomin_pwm;
+ struct gpio_desc *disp;
+ struct delayed_work d_work;
+ struct mutex update_lock;
+
+ u8 *spi_buf;
+
+ bool extmode;
+ u32 spi_width;
+ u32 vmem_w
[PATCH 1/2] dt-bindings: Add DT bindings for Toshiba TC358762 DSI-to-DPI bridge
Add DT bindings for Toshiba TC358762 DSI-to-DPI bridge, this
one is used in the Raspberry Pi 7" touchscreen display unit.
Signed-off-by: Marek Vasut
To: dri-devel@lists.freedesktop.org
Cc: Eric Anholt
Cc: Rob Herring
Cc: Sam Ravnborg
Cc: devicet...@vger.kernel.org
---
.../display/bridge/toshiba,tc358762.yaml | 116 ++
1 file changed, 116 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/bridge/toshiba,tc358762.yaml
diff --git
a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358762.yaml
b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358762.yaml
new file mode 100644
index ..40098ca761a3
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358762.yaml
@@ -0,0 +1,116 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/toshiba,tc358762.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Toshiba TC358762 MIPI DSI to MIPI DPI bridge
+
+maintainers:
+ - Marek Vasut
+
+description: |
+ The TC358762 is bridge device which converts MIPI DSI to MIPI DPI.
+
+properties:
+ compatible:
+enum:
+ - toshiba,tc358762
+
+ reg:
+maxItems: 1
+description: virtual channel number of a DSI peripheral
+
+ vddc-supply:
+description: Regulator for 1.2V internal core power.
+
+ ports:
+type: object
+
+properties:
+ "#address-cells":
+const: 1
+
+ "#size-cells":
+const: 0
+
+ port@0:
+type: object
+additionalProperties: false
+
+description: |
+ Video port for MIPI DSI input
+
+properties:
+ reg:
+const: 0
+
+patternProperties:
+ endpoint:
+type: object
+additionalProperties: false
+
+properties:
+ remote-endpoint: true
+
+required:
+ - reg
+
+ port@1:
+type: object
+additionalProperties: false
+
+description: |
+ Video port for MIPI DPI output (panel or connector).
+
+properties:
+ reg:
+const: 1
+
+patternProperties:
+ endpoint:
+type: object
+additionalProperties: false
+
+properties:
+ remote-endpoint: true
+
+required:
+ - reg
+
+required:
+ - "#address-cells"
+ - "#size-cells"
+ - port@0
+ - port@1
+
+required:
+ - compatible
+ - reg
+ - vddc-supply
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+bridge@0 {
+reg = <0>;
+compatible = "toshiba,tc358762";
+vddc-supply = <&vcc_1v2_reg>;
+#address-cells = <1>;
+#size-cells = <0>;
+port@0 {
+reg = <0>;
+bridge_in: endpoint {
+remote-endpoint = <&dsi_out>;
+};
+};
+
+port@1 {
+reg = <1>;
+bridge_out: endpoint {
+remote-endpoint = <&panel_in>;
+};
+};
+};
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [v7, PATCH 2/7] mtk-mmsys: add mmsys private data
On Thu, 2020-07-23 at 11:32 +0200, Enric Balletbo Serra wrote: > Hi Yongqiang Niu, > > Thank you for your patch. > > Missatge de Yongqiang Niu del dia dj., 23 > de jul. 2020 a les 4:05: > > > > add mmsys private data > > > > I think this change requires a better explanation of what you are > doing. Although I'm really uncomfortable with this change, why you > need to create a new mt2701-mmsys file? reason: 1.there will more and more Mediatek Soc upstream, and the display path connection function mtk_mmsys_ddp_mout_en, mtk_mmsys_ddp_sel_in and mtk_mmsys_ddp_sout_sel will complicated more and more, 2. many of the connection are only used in some SoC, and useless for other SoC and not readable, 3. if we add a new SoC connection, we need check is this affect other Soc, > > > Feature: drm/mediatek > > Remove this. next version will remove this > > > Signed-off-by: Yongqiang Niu > > --- > > drivers/soc/mediatek/Makefile | 1 + > > drivers/soc/mediatek/mmsys/Makefile | 2 + > > drivers/soc/mediatek/mmsys/mt2701-mmsys.c | 250 +++ > > drivers/soc/mediatek/mtk-mmsys.c | 271 > > +- > > include/linux/soc/mediatek/mtk-mmsys.h| 15 ++ > > 5 files changed, 314 insertions(+), 225 deletions(-) > > create mode 100644 drivers/soc/mediatek/mmsys/Makefile > > create mode 100644 drivers/soc/mediatek/mmsys/mt2701-mmsys.c > > > > diff --git a/drivers/soc/mediatek/Makefile b/drivers/soc/mediatek/Makefile > > index 2afa7b9..b37ac2c 100644 > > --- a/drivers/soc/mediatek/Makefile > > +++ b/drivers/soc/mediatek/Makefile > > @@ -3,3 +3,4 @@ obj-$(CONFIG_MTK_CMDQ) += mtk-cmdq-helper.o > > obj-$(CONFIG_MTK_PMIC_WRAP) += mtk-pmic-wrap.o > > obj-$(CONFIG_MTK_SCPSYS) += mtk-scpsys.o > > obj-$(CONFIG_MTK_MMSYS) += mtk-mmsys.o > > +obj-$(CONFIG_MTK_MMSYS) += mmsys/ > > diff --git a/drivers/soc/mediatek/mmsys/Makefile > > b/drivers/soc/mediatek/mmsys/Makefile > > new file mode 100644 > > index 000..33b0dab > > --- /dev/null > > +++ b/drivers/soc/mediatek/mmsys/Makefile > > @@ -0,0 +1,2 @@ > > +# SPDX-License-Identifier: GPL-2.0-only > > +obj-y += mt2701-mmsys.o > > diff --git a/drivers/soc/mediatek/mmsys/mt2701-mmsys.c > > b/drivers/soc/mediatek/mmsys/mt2701-mmsys.c > > new file mode 100644 > > index 000..b8e53b0 > > --- /dev/null > > +++ b/drivers/soc/mediatek/mmsys/mt2701-mmsys.c > > @@ -0,0 +1,250 @@ > > +// SPDX-License-Identifier: GPL-2.0 > > +// > > +// Copyright (c) 2020 MediaTek Inc. > > + > > +#include > > +#include > > +#include > > +#include > > +#include > > + > > +#define DISP_REG_CONFIG_DISP_OVL0_MOUT_EN 0x040 > > +#define DISP_REG_CONFIG_DISP_OVL1_MOUT_EN 0x044 > > +#define DISP_REG_CONFIG_DISP_OD_MOUT_EN0x048 > > +#define DISP_REG_CONFIG_DISP_GAMMA_MOUT_EN 0x04c > > +#define DISP_REG_CONFIG_DISP_UFOE_MOUT_EN 0x050 > > +#define DISP_REG_CONFIG_DISP_COLOR0_SEL_IN 0x084 > > +#define DISP_REG_CONFIG_DISP_COLOR1_SEL_IN 0x088 > > +#define DISP_REG_CONFIG_DSIE_SEL_IN0x0a4 > > +#define DISP_REG_CONFIG_DSIO_SEL_IN0x0a8 > > +#define DISP_REG_CONFIG_DPI_SEL_IN 0x0ac > > +#define DISP_REG_CONFIG_DISP_RDMA2_SOUT0x0b8 > > +#define DISP_REG_CONFIG_DISP_RDMA0_SOUT_EN 0x0c4 > > +#define DISP_REG_CONFIG_DISP_RDMA1_SOUT_EN 0x0c8 > > +#define DISP_REG_CONFIG_MMSYS_CG_CON0 0x100 > > + > > +#define DISP_REG_CONFIG_DISP_OVL_MOUT_EN 0x030 > > +#define DISP_REG_CONFIG_OUT_SEL0x04c > > +#define DISP_REG_CONFIG_DSI_SEL0x050 > > +#define DISP_REG_CONFIG_DPI_SEL0x064 > > + > > +#define OVL0_MOUT_EN_COLOR00x1 > > +#define OD_MOUT_EN_RDMA0 0x1 > > +#define OD1_MOUT_EN_RDMA1 BIT(16) > > +#define UFOE_MOUT_EN_DSI0 0x1 > > +#define COLOR0_SEL_IN_OVL0 0x1 > > +#define OVL1_MOUT_EN_COLOR10x1 > > +#define GAMMA_MOUT_EN_RDMA10x1 > > +#define RDMA0_SOUT_DPI00x2 > > +#define RDMA0_SOUT_DPI10x3 > > +#define RDMA0_SOUT_DSI10x1 > > +#define RDMA0_SOUT_DSI20x4 > > +#define RDMA0_SOUT_DSI30x5 > > +#define RDMA1_SOUT_DPI00x2 > > +#define RDMA1_SOUT_DPI10x3 > > +#define RDMA1_SOUT_DSI10x1 > > +#define RDMA1_SOUT_DSI20x4 > > +#define RDMA1_SOUT_DSI30x5 > > +#define RDMA2_SOUT_DPI00x2 > > +#define RDMA2_SOUT_DPI10x3 > > +#define RDMA2_SOUT_DSI10x1 > > +#define RDMA2_SOUT_DSI20x4 > > +#defi
[PATCH 0/9] SDM630/36/60 driver enablement
Hi! This series brings most of the changes that have been brought to sdm630/636/660 SoCs apart from device tree part (I cannot add anything unless some [1] smmu quirks are merged.. blame qcom!) So far, the platform is shaping up nicely, though some peripherals seem to be living their own lives (I'm looking at you, modem!) The QPNP-REVID driver is taken from downstream but seems to work fine upstream. I understand it may need some cleaning-up before it's merged. Current out-of-tree progress can be seen at [2]. [1] https://patchwork.kernel.org/patch/11643603/ [2] https://github.com/konradybcio/linux/commits/ninges_labs Konrad Dybcio (8): clk: qcom: gcc-sdm660: Add missing modem reset phy: qcom-qusb2: Add support for SDM630/660 drivers: usb: dwc3-qcom: Add sdm660 compatible drm/msm/dsi: Add phy configuration for SDM630/636/660 drm/msm/mdp5: Add MDP5 configuration for SDM630 drm/msm/dsi: Add DSI configuration for SDM660 drm/msm/mdp5: Add MDP5 configuration for SDM636/660 clk: qcom: gcc-sdm660: Fix up gcc_mss_mnoc_bimc_axi_clk Xiaozhe Shi (1): soc/qcom: Add REVID driver .../devicetree/bindings/display/msm/dsi.txt | 1 + .../bindings/phy/qcom,qusb2-phy.yaml | 1 + .../bindings/soc/qcom/qcom,qpnp-revid.yaml| 38 ++ .../devicetree/bindings/usb/qcom,dwc3.yaml| 1 + drivers/clk/qcom/gcc-sdm660.c | 4 + drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c | 198 ++ drivers/gpu/drm/msm/dsi/dsi_cfg.c | 21 + drivers/gpu/drm/msm/dsi/dsi_cfg.h | 1 + drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 2 + drivers/gpu/drm/msm/dsi/phy/dsi_phy.h | 1 + drivers/gpu/drm/msm/dsi/phy/dsi_phy_14nm.c| 18 + drivers/phy/qualcomm/phy-qcom-qusb2.c | 7 +- drivers/soc/qcom/Kconfig | 9 + drivers/soc/qcom/Makefile | 1 + drivers/soc/qcom/qpnp-revid.c | 288 ++ drivers/usb/dwc3/dwc3-qcom.c | 1 + include/dt-bindings/clock/qcom,gcc-sdm660.h | 1 + include/linux/qpnp/qpnp-revid.h | 369 ++ 18 files changed, 961 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,qpnp-revid.yaml create mode 100644 drivers/soc/qcom/qpnp-revid.c create mode 100644 include/linux/qpnp/qpnp-revid.h -- 2.27.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] amdgpu_dm: fix nonblocking atomic commit use-after-free
On Sat, 25 Jul 2020 03:03:52 + Mazin Rezk wrote: > > Am 24.07.20 um 19:33 schrieb Kees Cook: > > > > > There was a fix to disable the async path for this driver that > > > worked around the bug too, yes? That seems like a safer and more > > > focused change that doesn't revert the SLUB defense for all > > > users, and would actually provide a complete, I think, workaround > > That said, I haven't seen the async disabling patch. If you could > link to it, I'd be glad to test it out and perhaps we can use that > instead. I'm confused. Not to put words in Kees' mouth; /I/ am confused (which admittedly could well be just because I make no claims to be a coder and am simply reading the bug and thread, but I'd appreciate some "unconfusing" anyway). My interpretation of the "async disabling" reference was that it was to comment #30 on the bug: https://bugzilla.kernel.org/show_bug.cgi?id=207383#c30 ... which (if I'm not confused on this point too) appears to be yours. There it was stated... I've also found that this bug exclusively occurs when commit_work is on the workqueue. After forcing drm_atomic_helper_commit to run all of the commits without adding to the workqueue and running the OS, the issue seems to have disappeared. Would not forcing all commits to run directly, without placing them on the workqueue, be "async disabling"? That's what I /thought/ he was referencing. OTOH your base/context swap idea sounds like a possibly "less disturbance" workaround, if it works, and given the point in the commit cycle... (But if it's out Sunday it's likely too late to test and get it in now anyway; if it's another week, tho...) -- Duncan - No HTML messages please; they are filtered as spam. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/9] drm/msm/mdp5: Add MDP5 configuration for SDM630
This commit adds support for the MDP5 IP on Snapdragon
630. The configuration is different from SDM660's, as
the latter one has two DSI outputs.
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c | 93
1 file changed, 93 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c
index 25a13a2a57a9..2e02de8a7e41 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c
@@ -910,6 +910,98 @@ static const struct mdp5_cfg_hw msm8998_config = {
.max_clk = 41250,
};
+static const struct mdp5_cfg_hw sdm630_config = {
+ .name = "sdm630",
+ .mdp = {
+ .count = 1,
+ .caps = MDP_CAP_CDM |
+ MDP_CAP_SRC_SPLIT |
+ 0,
+ },
+ .ctl = {
+ .count = 5,
+ .base = { 0x01000, 0x01200, 0x01400, 0x01600, 0x01800 },
+ .flush_hw_mask = 0xf4ff,
+ },
+ .pipe_vig = {
+ .count = 1,
+ .base = { 0x04000 },
+ .caps = MDP_PIPE_CAP_HFLIP |
+ MDP_PIPE_CAP_VFLIP |
+ MDP_PIPE_CAP_SCALE |
+ MDP_PIPE_CAP_CSC|
+ MDP_PIPE_CAP_DECIMATION |
+ MDP_PIPE_CAP_SW_PIX_EXT |
+ 0,
+ },
+ .pipe_rgb = {
+ .count = 4,
+ .base = { 0x14000, 0x16000, 0x18000, 0x1a000 },
+ .caps = MDP_PIPE_CAP_HFLIP |
+ MDP_PIPE_CAP_VFLIP |
+ MDP_PIPE_CAP_SCALE |
+ MDP_PIPE_CAP_DECIMATION |
+ MDP_PIPE_CAP_SW_PIX_EXT |
+ 0,
+ },
+ .pipe_dma = {
+ .count = 2, /* driver supports max of 2 currently */
+ .base = { 0x24000, 0x26000, 0x28000 },
+ .caps = MDP_PIPE_CAP_HFLIP |
+ MDP_PIPE_CAP_VFLIP |
+ MDP_PIPE_CAP_SW_PIX_EXT |
+ 0,
+ },
+ .pipe_cursor = {
+ .count = 1,
+ .base = { 0x34000 },
+ .caps = MDP_PIPE_CAP_HFLIP |
+ MDP_PIPE_CAP_VFLIP |
+ MDP_PIPE_CAP_SW_PIX_EXT |
+ MDP_PIPE_CAP_CURSOR |
+ 0,
+ },
+
+ .lm = {
+ .count = 2,
+ .base = { 0x44000, 0x46000 },
+ .instances = {
+ { .id = 0, .pp = 0, .dspp = 0,
+ .caps = MDP_LM_CAP_DISPLAY |
+ MDP_LM_CAP_PAIR, },
+ { .id = 1, .pp = 1, .dspp = -1,
+ .caps = MDP_LM_CAP_WB, },
+ },
+ .nb_stages = 8,
+ .max_width = 2048,
+ .max_height = 0x,
+ },
+ .dspp = {
+ .count = 1,
+ .base = { 0x54000 },
+ },
+ .ad = {
+ .count = 2,
+ .base = { 0x78000, 0x78800 },
+ },
+ .pp = {
+ .count = 3,
+ .base = { 0x7, 0x71000, 0x72000 },
+ },
+ .cdm = {
+ .count = 1,
+ .base = { 0x79200 },
+ },
+ .intf = {
+ .base = { 0x6a000, 0x6a800 },
+ .connect = {
+ [0] = INTF_DISABLED,
+ [1] = INTF_DSI,
+ },
+ },
+ .max_clk = 41250,
+};
+
static const struct mdp5_cfg_handler cfg_handlers_v1[] = {
{ .revision = 0, .config = { .hw = &msm8x74v1_config } },
{ .revision = 2, .config = { .hw = &msm8x74v2_config } },
@@ -924,6 +1016,7 @@ static const struct mdp5_cfg_handler cfg_handlers_v1[] = {
static const struct mdp5_cfg_handler cfg_handlers_v3[] = {
{ .revision = 0, .config = { .hw = &msm8998_config } },
+ { .revision = 3, .config = { .hw = &sdm630_config } },
};
static struct mdp5_cfg_platform *mdp5_get_config(struct platform_device *dev);
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 6/9] drm/msm/dsi: Add DSI configuration for SDM660
This also applies to sdm630/636 and their SDA
counterparts.
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/dsi/dsi_cfg.c | 21 +
drivers/gpu/drm/msm/dsi/dsi_cfg.h | 1 +
2 files changed, 22 insertions(+)
diff --git a/drivers/gpu/drm/msm/dsi/dsi_cfg.c
b/drivers/gpu/drm/msm/dsi/dsi_cfg.c
index 813d69deb5e8..f892f2cbe8bb 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_cfg.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_cfg.c
@@ -149,6 +149,25 @@ static const struct msm_dsi_config msm8998_dsi_cfg = {
.num_dsi = 2,
};
+static const char * const dsi_sdm660_bus_clk_names[] = {
+ "iface", "bus", "core", "core_mmss",
+};
+
+static const struct msm_dsi_config sdm660_dsi_cfg = {
+ .io_offset = DSI_6G_REG_SHIFT,
+ .reg_cfg = {
+ .num = 2,
+ .regs = {
+ {"vdd", 73400, 32 },/* 0.9 V */
+ {"vdda", 12560, 4 },/* 1.2 V */
+ },
+ },
+ .bus_clk_names = dsi_sdm660_bus_clk_names,
+ .num_bus_clks = ARRAY_SIZE(dsi_sdm660_bus_clk_names),
+ .io_start = { 0xc994000, 0xc996000 },
+ .num_dsi = 2,
+};
+
static const char * const dsi_sdm845_bus_clk_names[] = {
"iface", "bus",
};
@@ -240,6 +259,8 @@ static const struct msm_dsi_cfg_handler dsi_cfg_handlers[]
= {
&msm8996_dsi_cfg, &msm_dsi_6g_host_ops},
{MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V1_4_2,
&msm8976_dsi_cfg, &msm_dsi_6g_host_ops},
+ {MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V2_1_0,
+ &sdm660_dsi_cfg, &msm_dsi_6g_v2_host_ops},
{MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V2_2_0,
&msm8998_dsi_cfg, &msm_dsi_6g_v2_host_ops},
{MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V2_2_1,
diff --git a/drivers/gpu/drm/msm/dsi/dsi_cfg.h
b/drivers/gpu/drm/msm/dsi/dsi_cfg.h
index 217e24a65178..efd469d1db45 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_cfg.h
+++ b/drivers/gpu/drm/msm/dsi/dsi_cfg.h
@@ -18,6 +18,7 @@
#define MSM_DSI_6G_VER_MINOR_V1_3_10x10030001
#define MSM_DSI_6G_VER_MINOR_V1_4_10x10040001
#define MSM_DSI_6G_VER_MINOR_V1_4_20x10040002
+#define MSM_DSI_6G_VER_MINOR_V2_1_00x2001
#define MSM_DSI_6G_VER_MINOR_V2_2_00x2000
#define MSM_DSI_6G_VER_MINOR_V2_2_10x20020001
#define MSM_DSI_6G_VER_MINOR_V2_4_10x20040001
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/3] dt-bindings: Add vendor prefix for Powertip
The Powertip Tech. Corp. is an LCD panel manufacturer. Signed-off-by: Marek Vasut To: dri-devel@lists.freedesktop.org Cc: Eric Anholt Cc: Rob Herring Cc: Sam Ravnborg Cc: devicet...@vger.kernel.org --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 30d2232ccc0f..0f8894e54878 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -826,6 +826,8 @@ patternProperties: description: Poslab Technology Co., Ltd. "^pov,.*": description: Point of View International B.V. + "^powertip,.*": +description: Powertip Tech. Corp. "^powervr,.*": description: PowerVR (deprecated, use img) "^primux,.*": -- 2.27.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/3] dt-bindings: Add DT bindings for Powertip PH800480T013
Add DT bindings for Powertip PH800480T013 800x480 parallel LCD, this one is used in the Raspberry Pi 7" touchscreen display unit. Signed-off-by: Marek Vasut To: dri-devel@lists.freedesktop.org Cc: Eric Anholt Cc: Rob Herring Cc: Sam Ravnborg Cc: devicet...@vger.kernel.org --- .../panel/powertip,ph800480t013-idf02.yaml| 28 +++ 1 file changed, 28 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/powertip,ph800480t013-idf02.yaml diff --git a/Documentation/devicetree/bindings/display/panel/powertip,ph800480t013-idf02.yaml b/Documentation/devicetree/bindings/display/panel/powertip,ph800480t013-idf02.yaml new file mode 100644 index ..8a2a4f79f365 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/powertip,ph800480t013-idf02.yaml @@ -0,0 +1,28 @@ +# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/powertip,ph800480t013-idf02# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: POWERTIP PH800480T013-IDF2 7.0" WVGA TFT LCD panel + +maintainers: + - Marek Vasut + +allOf: + - $ref: panel-common.yaml# + +properties: + compatible: +const: powertip,ph800480t013-idf02 + + power-supply: true + backlight: true + port: true + +additionalProperties: false + +required: + - compatible + +... -- 2.27.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 8/9] clk: qcom: gcc-sdm660: Fix up gcc_mss_mnoc_bimc_axi_clk
Add missing halt_check, hwcg_reg and hwcg_bit properties.
These were likely omitted when porting the driver upstream.
Signed-off-by: Konrad Dybcio
---
drivers/clk/qcom/gcc-sdm660.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/clk/qcom/gcc-sdm660.c b/drivers/clk/qcom/gcc-sdm660.c
index a85283786278..f0b47b7d50ca 100644
--- a/drivers/clk/qcom/gcc-sdm660.c
+++ b/drivers/clk/qcom/gcc-sdm660.c
@@ -1715,6 +1715,9 @@ static struct clk_branch gcc_mss_cfg_ahb_clk = {
static struct clk_branch gcc_mss_mnoc_bimc_axi_clk = {
.halt_reg = 0x8a004,
+ .halt_check = BRANCH_HALT,
+ .hwcg_reg = 0x8a004,
+ .hwcg_bit = 1,
.clkr = {
.enable_reg = 0x8a004,
.enable_mask = BIT(0),
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/9] drivers: usb: dwc3-qcom: Add sdm660 compatible
Signed-off-by: Konrad Dybcio
---
Documentation/devicetree/bindings/usb/qcom,dwc3.yaml | 1 +
drivers/usb/dwc3/dwc3-qcom.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml
b/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml
index dac10848dd7f..c5280d6406ec 100644
--- a/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml
+++ b/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml
@@ -16,6 +16,7 @@ properties:
- qcom,msm8996-dwc3
- qcom,msm8998-dwc3
- qcom,sc7180-dwc3
+ - qcom,sdm660-dwc3
- qcom,sdm845-dwc3
- const: qcom,dwc3
diff --git a/drivers/usb/dwc3/dwc3-qcom.c b/drivers/usb/dwc3/dwc3-qcom.c
index 1dfd024cd06b..d6b3e1bb550a 100644
--- a/drivers/usb/dwc3/dwc3-qcom.c
+++ b/drivers/usb/dwc3/dwc3-qcom.c
@@ -753,6 +753,7 @@ static const struct of_device_id dwc3_qcom_of_match[] = {
{ .compatible = "qcom,dwc3" },
{ .compatible = "qcom,msm8996-dwc3" },
{ .compatible = "qcom,msm8998-dwc3" },
+ { .compatible = "qcom,sdm660-dwc3" },
{ .compatible = "qcom,sdm845-dwc3" },
{ }
};
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [v7, PATCH 2/7] mtk-mmsys: add mmsys private data
On Sat, 2020-07-25 at 10:11 +0800, Chun-Kuang Hu wrote: > Hi, Yongqiang: > > Yongqiang Niu 於 2020年7月23日 週四 上午10:05寫道： > > > > add mmsys private data > > > > Feature: drm/mediatek > > Signed-off-by: Yongqiang Niu > > --- > > drivers/soc/mediatek/Makefile | 1 + > > drivers/soc/mediatek/mmsys/Makefile | 2 + > > drivers/soc/mediatek/mmsys/mt2701-mmsys.c | 250 +++ > > drivers/soc/mediatek/mtk-mmsys.c | 271 > > +- > > include/linux/soc/mediatek/mtk-mmsys.h| 15 ++ > > 5 files changed, 314 insertions(+), 225 deletions(-) > > create mode 100644 drivers/soc/mediatek/mmsys/Makefile > > create mode 100644 drivers/soc/mediatek/mmsys/mt2701-mmsys.c > > > > diff --git a/drivers/soc/mediatek/Makefile b/drivers/soc/mediatek/Makefile > > index 2afa7b9..b37ac2c 100644 > > --- a/drivers/soc/mediatek/Makefile > > +++ b/drivers/soc/mediatek/Makefile > > @@ -3,3 +3,4 @@ obj-$(CONFIG_MTK_CMDQ) += mtk-cmdq-helper.o > > obj-$(CONFIG_MTK_PMIC_WRAP) += mtk-pmic-wrap.o > > obj-$(CONFIG_MTK_SCPSYS) += mtk-scpsys.o > > obj-$(CONFIG_MTK_MMSYS) += mtk-mmsys.o > > +obj-$(CONFIG_MTK_MMSYS) += mmsys/ > > diff --git a/drivers/soc/mediatek/mmsys/Makefile > > b/drivers/soc/mediatek/mmsys/Makefile > > new file mode 100644 > > index 000..33b0dab > > --- /dev/null > > +++ b/drivers/soc/mediatek/mmsys/Makefile > > @@ -0,0 +1,2 @@ > > +# SPDX-License-Identifier: GPL-2.0-only > > +obj-y += mt2701-mmsys.o > > diff --git a/drivers/soc/mediatek/mmsys/mt2701-mmsys.c > > b/drivers/soc/mediatek/mmsys/mt2701-mmsys.c > > new file mode 100644 > > index 000..b8e53b0 > > --- /dev/null > > +++ b/drivers/soc/mediatek/mmsys/mt2701-mmsys.c > > @@ -0,0 +1,250 @@ > > +// SPDX-License-Identifier: GPL-2.0 > > +// > > +// Copyright (c) 2020 MediaTek Inc. > > + > > +#include > > +#include > > +#include > > +#include > > +#include > > + > > +#define DISP_REG_CONFIG_DISP_OVL0_MOUT_EN 0x040 > > +#define DISP_REG_CONFIG_DISP_OVL1_MOUT_EN 0x044 > > +#define DISP_REG_CONFIG_DISP_OD_MOUT_EN0x048 > > +#define DISP_REG_CONFIG_DISP_GAMMA_MOUT_EN 0x04c > > +#define DISP_REG_CONFIG_DISP_UFOE_MOUT_EN 0x050 > > +#define DISP_REG_CONFIG_DISP_COLOR0_SEL_IN 0x084 > > +#define DISP_REG_CONFIG_DISP_COLOR1_SEL_IN 0x088 > > +#define DISP_REG_CONFIG_DSIE_SEL_IN0x0a4 > > +#define DISP_REG_CONFIG_DSIO_SEL_IN0x0a8 > > +#define DISP_REG_CONFIG_DPI_SEL_IN 0x0ac > > +#define DISP_REG_CONFIG_DISP_RDMA2_SOUT0x0b8 > > +#define DISP_REG_CONFIG_DISP_RDMA0_SOUT_EN 0x0c4 > > +#define DISP_REG_CONFIG_DISP_RDMA1_SOUT_EN 0x0c8 > > +#define DISP_REG_CONFIG_MMSYS_CG_CON0 0x100 > > + > > +#define DISP_REG_CONFIG_DISP_OVL_MOUT_EN 0x030 > > +#define DISP_REG_CONFIG_OUT_SEL0x04c > > +#define DISP_REG_CONFIG_DSI_SEL0x050 > > +#define DISP_REG_CONFIG_DPI_SEL0x064 > > + > > +#define OVL0_MOUT_EN_COLOR00x1 > > +#define OD_MOUT_EN_RDMA0 0x1 > > +#define OD1_MOUT_EN_RDMA1 BIT(16) > > +#define UFOE_MOUT_EN_DSI0 0x1 > > +#define COLOR0_SEL_IN_OVL0 0x1 > > +#define OVL1_MOUT_EN_COLOR10x1 > > +#define GAMMA_MOUT_EN_RDMA10x1 > > +#define RDMA0_SOUT_DPI00x2 > > +#define RDMA0_SOUT_DPI10x3 > > +#define RDMA0_SOUT_DSI10x1 > > +#define RDMA0_SOUT_DSI20x4 > > +#define RDMA0_SOUT_DSI30x5 > > +#define RDMA1_SOUT_DPI00x2 > > +#define RDMA1_SOUT_DPI10x3 > > +#define RDMA1_SOUT_DSI10x1 > > +#define RDMA1_SOUT_DSI20x4 > > +#define RDMA1_SOUT_DSI30x5 > > +#define RDMA2_SOUT_DPI00x2 > > +#define RDMA2_SOUT_DPI10x3 > > +#define RDMA2_SOUT_DSI10x1 > > +#define RDMA2_SOUT_DSI20x4 > > +#define RDMA2_SOUT_DSI30x5 > > +#define DPI0_SEL_IN_RDMA1 0x1 > > +#define DPI0_SEL_IN_RDMA2 0x3 > > +#define DPI1_SEL_IN_RDMA1 (0x1 << 8) > > +#define DPI1_SEL_IN_RDMA2 (0x3 << 8) > > +#define DSI0_SEL_IN_RDMA1 0x1 > > +#define DSI0_SEL_IN_RDMA2 0x4 > > +#define DSI1_SEL_IN_RDMA1 0x1 > > +#define DSI1_SEL_IN_RDMA2 0x4 > > +#define DSI2_SEL_IN_RDMA1 (0x1 << 16) > > +#define DSI2_SEL_IN_RDMA2 (0x4 << 16) > > +#define DSI3_SEL_IN_RDMA1
[PATCH 2/9] phy: qcom-qusb2: Add support for SDM630/660
QUSB on these SoCs actually uses *almost* the same
configuration that msm8996 does, so we can reuse
the phy_cfg from there with just a single change
(se clock scheme).
Signed-off-by: Konrad Dybcio
---
Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml | 1 +
drivers/phy/qualcomm/phy-qcom-qusb2.c | 7 ++-
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml
b/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml
index b5a6195de7ff..e61a3ca3deba 100644
--- a/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml
@@ -20,6 +20,7 @@ properties:
- enum:
- qcom,msm8996-qusb2-phy
- qcom,msm8998-qusb2-phy
+ - qcom,sdm660-qusb2-phy
- items:
- enum:
- qcom,sc7180-qusb2-phy
diff --git a/drivers/phy/qualcomm/phy-qcom-qusb2.c
b/drivers/phy/qualcomm/phy-qcom-qusb2.c
index 393011a05b48..11852ebe9e49 100644
--- a/drivers/phy/qualcomm/phy-qcom-qusb2.c
+++ b/drivers/phy/qualcomm/phy-qcom-qusb2.c
@@ -702,7 +702,8 @@ static int qusb2_phy_init(struct phy *phy)
usleep_range(150, 160);
/* Default is single-ended clock on msm8996 */
- qphy->has_se_clk_scheme = true;
+ if (!of_device_is_compatible(phy->dev.of_node, "qcom,sdm660-qusb2-phy"))
+ qphy->has_se_clk_scheme = true;
/*
* read TCSR_PHY_CLK_SCHEME register to check if single-ended
* clock scheme is selected. If yes, then disable differential
@@ -815,6 +816,10 @@ static const struct of_device_id
qusb2_phy_of_match_table[] = {
}, {
.compatible = "qcom,msm8998-qusb2-phy",
.data = &msm8998_phy_cfg,
+ }, {
+ .compatible = "qcom,sdm660-qusb2-phy",
+ /* sdm630/660 use the same config as msm8996. */
+ .data = &msm8996_phy_cfg,
}, {
/*
* Deprecated. Only here to support legacy device
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 0/5] drm: rockchip: various ports for older VOPs
Am 22.07.20 um 23:43 schrieb Daniel Vetter: On Wed, Jul 22, 2020 at 8:13 PM Alex Bee wrote: Hi, this series mainly ports existining functionality to older SoCs - most importantly enables alpha blending for RK3036, RK3066, RK3126 and RK3188. Besides that, it also changes the window type from DRM_PLANE_TYPE_CURSOR to DRM_PLANE_TYPE_OVERLAY for VOPs that have only one (1) overlay window. This doesn't make much sense, the cursor overlay is really just a hint for legacy ioctls that this is the overlay that should be used for cursors. Compositors should try to use such planes as full overlays (if they don't want to use them as a cursor). So sounds like a case of "fix your compositor". I agree here - but: If HWC windows would have been implemented in this particular driver, their max size would be 128x128 on some SoCs - so they woudn't be really suitable to create an OSD overlay at 4K, for example. I don't know, but I guess other vendors implement their HWC windows on this reduced HW resources as well. I guess that is one of the reasons, why userspace, which aims to be cross-plattfrom, avoids DRM_PLANE_TYPE_CURSOR when its looking for an usable overlay plane. (a heuristic, indeed) For atomic there's 0 difference between a overlay or a cursor (primary plane is still treated somewhat special in the RMFB ioctl, but again that's for backwards compat reasons with existing uapi, not because the primary plane is different). What does happen though is that this breaks cursor for legacy userspace, which is probably not really what you want. Indeed not. Beforhand I was submiiting this, I looked arround and couldn't find anything which relies or even depends of a cursor window to be available. Even if: as per spec only one DRM_PLANE_TYPE_PRIMARY is mandatory, everything else is optional. -Daniel Regards, Alex Changes in v2: - drop not yet upstreamed dsp_data_swap from RK3188 regs - rephrase most commit messages Alex Bee (5): drm: rockchip: add scaling for RK3036 win1 drm: rockchip: add missing registers for RK3188 drm: rockchip: add alpha support for RK3036, RK3066, RK3126 and RK3188 drm: rockchip: set alpha_en to 0 if it is not used drm: rockchip: use overlay windows as such drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 1 + drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 42 ++--- drivers/gpu/drm/rockchip/rockchip_vop_reg.h | 1 + 3 files changed, 38 insertions(+), 6 deletions(-) -- 2.17.1 -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch Best Regards ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 0/3] Add LT9611 DSI to HDMI bridge
Hi Vinod. On Thu, Jul 23, 2020 at 10:04:39PM +0530, Vinod Koul wrote: > Hi, > > This series adds driver and bindings for Lontium LT9611 bridge chip which > takes MIPI DSI as input and HDMI as output. > > This chip can be found in 96boards RB3 platform [1] commonly called DB845c. > > [1]: https://www.96boards.org/product/rb3-platform/ > > Changes in v6: > - Drop msm/dsi patch as we need to get more bridges fixed before we add that > - Bring back support for DRM_BRIDGE_ATTACH_NO_CONNECTOR not set, now driver > supports both > - Fix nits found by Sam > > Changes in v5: > - make symbol static, reported by kbuild-bot > > Changes in v4: > - Add msm/dsi patch to create connector and support > DRM_BRIDGE_ATTACH_NO_CONNECTOR > - Fix comments provided by Sam > > Changes in v3: > - fix kbuild reported error > - rebase on v5.8-rc1 > > Changes in v2: > - Add acks by Rob > - Fix comments reported by Emil and rename the file to lontium-lt9611.c > - Fix comments reported by Laurent on binding and driver > - Add HDMI audio support > > Vinod Koul (3): > dt-bindings: vendor-prefixes: Add Lontium vendor prefix > dt-bindings: display: bridge: Add documentation for LT9611 > drm/bridge: Introduce LT9611 DSI to HDMI bridge Fixed prototype for lt9611_bridge_mode_valid() and applied the series to drm-misc-next. Sam > > .../display/bridge/lontium,lt9611.yaml| 176 +++ > .../devicetree/bindings/vendor-prefixes.yaml |2 + > drivers/gpu/drm/bridge/Kconfig| 13 + > drivers/gpu/drm/bridge/Makefile |1 + > drivers/gpu/drm/bridge/lontium-lt9611.c | 1229 + > 5 files changed, 1421 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml > create mode 100644 drivers/gpu/drm/bridge/lontium-lt9611.c > > -- > 2.26.2 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/ttm: fix pipelined gutting for evictions v2
On 7/24/2020 10:01 AM, Felix Kuehling wrote:
Am 2020-07-24 um 7:56 a.m. schrieb Christian König:
We can't pipeline that during eviction because the memory needs
to be available immediately.
v2: fix how we cleanup the BOs resources
Signed-off-by: Christian König
Reviewed-by: Felix Kuehling
It would be good to get a Tested-by from Alex as well.
Thanks,
Felix
Tested-by: Alex Sierra
Regards,
Alex Sierra
---
drivers/gpu/drm/ttm/ttm_bo.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 0768a054a916..469aa93ea317 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -652,8 +652,12 @@ static int ttm_bo_evict(struct ttm_buffer_object *bo,
placement.num_busy_placement = 0;
bdev->driver->evict_flags(bo, &placement);
- if (!placement.num_placement && !placement.num_busy_placement)
- return ttm_bo_pipeline_gutting(bo);
+ if (!placement.num_placement && !placement.num_busy_placement) {
+ ttm_bo_wait(bo, false, false);
+
+ ttm_bo_cleanup_memtype_use(bo);
+ return 0;
+ }
evict_mem = bo->mem;
evict_mem.mm_node = NULL;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/panel: Fix auo, kd101n80-45na horizontal noise on edges of panel
On Tue, Jul 14, 2020 at 08:33:32PM +0800, Jitao Shi wrote:
> Fine tune the HBP and HFP to avoid the dot noise on the left and right edges.
>
> Signed-off-by: Jitao Shi
> ---
> drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
> b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
> index 48a164257d18..3edb33e61908 100644
> --- a/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
> +++ b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
> @@ -615,9 +615,9 @@ static const struct panel_desc boe_tv101wum_nl6_desc = {
> static const struct drm_display_mode auo_kd101n80_45na_default_mode = {
> .clock = 157000,
> .hdisplay = 1200,
> - .hsync_start = 1200 + 80,
> - .hsync_end = 1200 + 80 + 24,
> - .htotal = 1200 + 80 + 24 + 36,
> + .hsync_start = 1200 + 60,
> + .hsync_end = 1200 + 60 + 24,
> + .htotal = 1200 + 60 + 24 + 56,
> .vdisplay = 1920,
> .vsync_start = 1920 + 16,
> .vsync_end = 1920 + 16 + 4,
Applied to drm-misc-fixes.
Sam
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: panel: simple: Delay HPD checking on boe_nv133fhm_n61 for 15 ms
On Thu, Jul 16, 2020 at 01:21:22PM -0700, Douglas Anderson wrote:
> On boe_nv133fhm_n62 (and presumably on boe_nv133fhm_n61) a scope shows
> a small spike on the HPD line right when you power the panel on. The
> picture looks something like this:
>
> +--
> |
> |
> |
> Power ---+
>+---
>|
> ++ |
> ++| |
> HPD -+ +---+
>
> So right when power is applied there's a little bump in HPD and then
> there's small spike right before it goes low. The total time of the
> little bump plus the spike was measured on one panel as being 8 ms
> long. The total time for the HPD to go high on the same panel was
> 51.2 ms, though the datasheet only promises it is < 200 ms.
>
> When asked about this glitch, BOE indicated that it was expected and
> persisted until the TCON has been initialized.
>
> If this was a real hotpluggable DP panel then this wouldn't matter a
> whole lot. We'd debounce the HPD signal for a really long time and so
> the little blip wouldn't hurt. However, this is not a hotpluggable DP
> panel and the the debouncing logic isn't needed and just shows down
> the time needed to get the display working. This is why the code in
> panel_simple_prepare() doesn't do debouncing and just waits for HPD to
> go high once. Unfortunately if we get unlucky and happen to poll the
> HPD line right at the spike we can try talking to the panel before
> it's ready.
>
> Let's handle this situation by putting in a 15 ms prepare delay and
> decreasing the "hpd absent delay" by 15 ms. That means:
> * If you don't have HPD hooked up at all you've still got the
> hardcoded 200 ms delay.
> * If you've got HPD hooked up you will always wait at least 15 ms
> before checking HPD. The only case where this could be bad is if
> the panel is sharing a voltage rail with something else in the
> system and was already turned on long before the panel came up. In
> such a case we'll be delaying 15 ms for no reason, but it's not a
> huge delay and I don't see any other good solution to handle that
> case.
>
> Even though the delay was measured as 8 ms, 15 ms was chosen to give a
> bit of margin.
>
> Signed-off-by: Douglas Anderson
Nice drawing and good explanation.
Applied to drm-misc-fixes.
Sam
> ---
> I don't actually have a device in front of me that is exhibiting these
> problems. I believe that it is only some devices and some of the
> time. Still, this patch seems safe and seems likely to fix the issue
> given the scope shots.
>
> drivers/gpu/drm/panel/panel-simple.c | 16 +++-
> 1 file changed, 15 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/panel/panel-simple.c
> b/drivers/gpu/drm/panel/panel-simple.c
> index 88493538a147..046a06b55800 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -1260,7 +1260,21 @@ static const struct panel_desc boe_nv133fhm_n61 = {
> .height = 165,
> },
> .delay = {
> - .hpd_absent_delay = 200,
> + /*
> + * When power is first given to the panel there's a short
> + * spike on the HPD line. It was explained that this spike
> + * was until the TCON data download was complete. On
> + * one system this was measured at 8 ms. We'll put 15 ms
> + * in the prepare delay just to be safe and take it away
> + * from the hpd_absent_delay (which would otherwise be 200 ms)
> + * to handle this. That means:
> + * - If HPD isn't hooked up you still have 200 ms delay.
> + * - If HPD is hooked up we won't try to look at it for the
> + * first 15 ms.
> + */
> + .prepare = 15,
> + .hpd_absent_delay = 185,
> +
> .unprepare = 500,
> },
> .bus_format = MEDIA_BUS_FMT_RGB888_1X24,
> --
> 2.28.0.rc0.105.gf9edc3c819-goog
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 0/1] drm/bridge: nwl-dsi: Drop DRM_BRIDGE_ATTACH_NO_CONNECTOR check.
Hi Guido. On Sat, Jul 18, 2020 at 08:26:36PM +0200, Guido Günther wrote: > > We don't create a connector but let panel_bridge handle that so there's > no point in rejecting DRM_BRIDGE_ATTACH_NO_CONNECTOR. > > This was prompted by Sam in > https://lore.kernel.org/dri-devel/20200718115734.ga2989...@ravnborg.org/ > > Signed-off-by: Guido Günther Now applied to drm-misc-fixes. Sam > > Guido Günther (1): > drm/bridge: nwl-dsi: Drop DRM_BRIDGE_ATTACH_NO_CONNECTOR check. > > drivers/gpu/drm/bridge/nwl-dsi.c | 5 - > 1 file changed, 5 deletions(-) > > -- > 2.26.2 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/mcde: Fix stability issue
Hi Linus.
On Sun, Jul 19, 2020 at 01:33:22AM +0200, Linus Walleij wrote:
> Whenener a display update was sent, apart from updating
s/Whenener/Whenever
> the memory base address we called mcde_display_send_one_frame()
^ insert comma?
> which also sent a command to the display requesting the TE IRQ
> and enabling the FIFO.
>
> When continous updates are running this is wrong: we need
> to only send this to start the flow to the display on
> the very first update. This lead to the display pipeline
> locking up and crashing.
>
> Check if the flow is already running and in that case
> do not call mcde_display_send_one_frame().
>
> This fixes crashes on the Samsung GT-S7710 (Skomer).
>
> Cc: Stephan Gerhold
> Cc: sta...@vger.kernel.org
> Signed-off-by: Linus Walleij
Patch looks fine.
Acked-by: Sam Ravnborg
> ---
> drivers/gpu/drm/mcde/mcde_display.c | 11 ---
> 1 file changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/mcde/mcde_display.c
> b/drivers/gpu/drm/mcde/mcde_display.c
> index 212aee60cf61..1d8ea8830a17 100644
> --- a/drivers/gpu/drm/mcde/mcde_display.c
> +++ b/drivers/gpu/drm/mcde/mcde_display.c
> @@ -1086,9 +1086,14 @@ static void mcde_display_update(struct
> drm_simple_display_pipe *pipe,
>*/
> if (fb) {
> mcde_set_extsrc(mcde, drm_fb_cma_get_gem_addr(fb, pstate, 0));
> - if (!mcde->video_mode)
> - /* Send a single frame using software sync */
> - mcde_display_send_one_frame(mcde);
> + if (!mcde->video_mode) {
> + /*
> + * Send a single frame using software sync if the flow
> + * is not active yet.
> + */
> + if (mcde->flow_active == 0)
> + mcde_display_send_one_frame(mcde);
> + }
> dev_info_once(mcde->dev, "sent first display update\n");
> } else {
> /*
> --
> 2.26.2
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/bridge/adv7511: set the bridge type properly
On Mon, Jul 20, 2020 at 03:42:27PM +0300, Laurentiu Palcu wrote: > From: Laurentiu Palcu > > After the drm_bridge_connector_init() helper function has been added, the ADV > driver has been changed accordingly. However, the 'type' field of the bridge > structure was left unset, which makes the helper function always return > -EINVAL. > > Signed-off-by: Laurentiu Palcu Thanks, applied to drm-misc-fixes. Sam > --- > Hi, > > I've hit this while trying to use this helper in the new i.MX8MQ DCSS > driver, as suggested by Sam, and I wanted to test it with NWL MIPI_DSI and > ADV since support is already in mainline. > > Thanks, > laurentiu > > > drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c > b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c > index f45cdca9cce5..a0d392c338da 100644 > --- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c > +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c > @@ -1283,6 +1283,7 @@ static int adv7511_probe(struct i2c_client *i2c, const > struct i2c_device_id *id) > adv7511->bridge.ops = DRM_BRIDGE_OP_DETECT | DRM_BRIDGE_OP_EDID > | DRM_BRIDGE_OP_HPD; > adv7511->bridge.of_node = dev->of_node; > + adv7511->bridge.type = DRM_MODE_CONNECTOR_HDMIA; > > drm_bridge_add(&adv7511->bridge); > > -- > 2.23.0 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v10 08/13] drm/msm: Add a context pointer to the submitqueue
On Mon, Jul 20, 2020 at 8:41 AM Jordan Crouse wrote:
>
> Each submitqueue is attached to a context. Add a pointer to the
> context to the submitqueue at create time and refcount it so
> that it stays around through the life of the queue.
>
> GPU submissions can access the active context via the submitqueue
> instead of requiring it to be passed around from function to
> function.
>
> Signed-off-by: Jordan Crouse
> ---
>
> drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 12 +---
> drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 5 ++---
> drivers/gpu/drm/msm/adreno/adreno_gpu.c | 5 ++---
> drivers/gpu/drm/msm/adreno/adreno_gpu.h | 3 +--
> drivers/gpu/drm/msm/msm_drv.c | 3 ++-
> drivers/gpu/drm/msm/msm_drv.h | 8
> drivers/gpu/drm/msm/msm_gem.h | 1 +
> drivers/gpu/drm/msm/msm_gem_submit.c| 8
> drivers/gpu/drm/msm/msm_gpu.c | 9 -
> drivers/gpu/drm/msm/msm_gpu.h | 7 +++
> drivers/gpu/drm/msm/msm_submitqueue.c | 8 +++-
> 11 files changed, 39 insertions(+), 30 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
> b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
> index 9e63a190642c..eff2439ea57b 100644
> --- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
> @@ -43,8 +43,7 @@ static void a5xx_flush(struct msm_gpu *gpu, struct
> msm_ringbuffer *ring)
> gpu_write(gpu, REG_A5XX_CP_RB_WPTR, wptr);
> }
>
> -static void a5xx_submit_in_rb(struct msm_gpu *gpu, struct msm_gem_submit
> *submit,
> - struct msm_file_private *ctx)
> +static void a5xx_submit_in_rb(struct msm_gpu *gpu, struct msm_gem_submit
> *submit)
> {
> struct msm_drm_private *priv = gpu->dev->dev_private;
> struct msm_ringbuffer *ring = submit->ring;
> @@ -57,7 +56,7 @@ static void a5xx_submit_in_rb(struct msm_gpu *gpu, struct
> msm_gem_submit *submit
> case MSM_SUBMIT_CMD_IB_TARGET_BUF:
> break;
> case MSM_SUBMIT_CMD_CTX_RESTORE_BUF:
> - if (priv->lastctx == ctx)
> + if (priv->lastctx == submit->queue->ctx)
> break;
> /* fall-thru */
> case MSM_SUBMIT_CMD_BUF:
> @@ -103,8 +102,7 @@ static void a5xx_submit_in_rb(struct msm_gpu *gpu, struct
> msm_gem_submit *submit
> msm_gpu_retire(gpu);
> }
>
> -static void a5xx_submit(struct msm_gpu *gpu, struct msm_gem_submit *submit,
> - struct msm_file_private *ctx)
> +static void a5xx_submit(struct msm_gpu *gpu, struct msm_gem_submit *submit)
> {
> struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
> struct a5xx_gpu *a5xx_gpu = to_a5xx_gpu(adreno_gpu);
> @@ -114,7 +112,7 @@ static void a5xx_submit(struct msm_gpu *gpu, struct
> msm_gem_submit *submit,
>
> if (IS_ENABLED(CONFIG_DRM_MSM_GPU_SUDO) && submit->in_rb) {
> priv->lastctx = NULL;
> - a5xx_submit_in_rb(gpu, submit, ctx);
> + a5xx_submit_in_rb(gpu, submit);
> return;
> }
>
> @@ -148,7 +146,7 @@ static void a5xx_submit(struct msm_gpu *gpu, struct
> msm_gem_submit *submit,
> case MSM_SUBMIT_CMD_IB_TARGET_BUF:
> break;
> case MSM_SUBMIT_CMD_CTX_RESTORE_BUF:
> - if (priv->lastctx == ctx)
> + if (priv->lastctx == submit->queue->ctx)
> break;
> /* fall-thru */
> case MSM_SUBMIT_CMD_BUF:
> diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> index c5a3e4d4c007..5eabb0109577 100644
> --- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> @@ -81,8 +81,7 @@ static void get_stats_counter(struct msm_ringbuffer *ring,
> u32 counter,
> OUT_RING(ring, upper_32_bits(iova));
> }
>
> -static void a6xx_submit(struct msm_gpu *gpu, struct msm_gem_submit *submit,
> - struct msm_file_private *ctx)
> +static void a6xx_submit(struct msm_gpu *gpu, struct msm_gem_submit *submit)
> {
> unsigned int index = submit->seqno % MSM_GPU_SUBMIT_STATS_COUNT;
> struct msm_drm_private *priv = gpu->dev->dev_private;
> @@ -115,7 +114,7 @@ static void a6xx_submit(struct msm_gpu *gpu, struct
> msm_gem_submit *submit,
> case MSM_SUBMIT_CMD_IB_TARGET_BUF:
> break;
> case MSM_SUBMIT_CMD_CTX_RESTORE_BUF:
> - if (priv->lastctx == ctx)
> + if (priv->lastctx == submit->queue->ctx)
> break;
> /* fall-thru */
> case MSM_SUBMIT_CMD_BUF:
> diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> index e23641a5ec84..b38a8126541a 100644
> --- a/drivers/gp
Re: [PATCH] drm: of: Fix double-free bug
Hi Biju
On Thu, Jul 23, 2020 at 12:10:54PM +0100, Biju Das wrote:
> Fix double-free bug in the error path.
>
> Fixes: 6529007522de ("drm: of: Add drm_of_lvds_get_dual_link_pixel_order")
> Reported-by: Pavel Machek
> Signed-off-by: Biju Das
> Cc: sta...@vger.kernel.org
Thanks, applied to drm-misc-fixes.
Sam
> ---
> This patch is tested against drm-fixes and drm-next.
> ---
> drivers/gpu/drm/drm_of.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c
> index fdb05fb..ca04c34 100644
> --- a/drivers/gpu/drm/drm_of.c
> +++ b/drivers/gpu/drm/drm_of.c
> @@ -331,10 +331,8 @@ static int drm_of_lvds_get_remote_pixels_type(
>* configurations by passing the endpoints explicitly to
>* drm_of_lvds_get_dual_link_pixel_order().
>*/
> - if (!current_pt || pixels_type != current_pt) {
> - of_node_put(remote_port);
> + if (!current_pt || pixels_type != current_pt)
> return -EINVAL;
> - }
> }
>
> return pixels_type;
> --
> 2.7.4
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] video: fbdev: added driver for sharp memory lcd displays
Hi Rodrigo.
On Fri, Jul 24, 2020 at 05:34:04PM -0300, Rodrigo Alencar wrote:
> The supported displays are ls027b7dh01 (tested), ls044q7dh01,
> ls013b7dh05, ls013b7dh03
>
> Signed-off-by: Rodrigo Alencar <455.rodrigo.alen...@gmail.com>
Thanks for submitting this driver.
Unfortunately I have some bad news for you...
The binding needs to be submitted as a seperate patch, and all new
bindings must use the DT schema format (.yaml files).
See Documentation/devicetree/bindings/*.rst for more info.
And on top of this fbdev/ is in maintenance mode so no new drivers.
New display drivers and panel drivers must go to gpu/drm/
and use the frameworks available there.
It looks like what we have here is a panel driver.
Look for other similar sharp panels in drm/panel/ to get an idea how to
add support for these new panels.
Soory, but looks forward for an updated patch.
Sam
> ---
> .../devicetree/bindings/display/smemlcdfb.txt | 46 ++
> drivers/video/fbdev/Kconfig | 14 +
> drivers/video/fbdev/Makefile | 1 +
> drivers/video/fbdev/smemlcdfb.c | 485 ++
> 4 files changed, 546 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/display/smemlcdfb.txt
> create mode 100644 drivers/video/fbdev/smemlcdfb.c
>
> diff --git a/Documentation/devicetree/bindings/display/smemlcdfb.txt
> b/Documentation/devicetree/bindings/display/smemlcdfb.txt
> new file mode 100644
> index ..e33025dd3374
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/smemlcdfb.txt
> @@ -0,0 +1,46 @@
> +Sharp Memory LCD Linux Framebuffer Driver
> +
> +Required properties:
> + - compatible: It should be "sharp,". The supported displays are
> + ls027b7dh01, ls044q7dh01, ls013b7dh05, ls013b7dh03. Maybe other
> + monochromatic models can be supported with the current code.
> + - reg: SPI chip select number for the device.
> + - spi-max-frequency: Max SPI frequency to use. One must verify the
> datasheet.
> + - spi-cs-high: Sharp Memory LCD needs chipselect high.
> +
> +Optional properties:
> + - sharp,frames-per-sec: It should contain the desired frames per second.
> + It does not represent the actual frame rate. Default: 10
> + - sharp,extmode-high: External COM Input signal is expected in EXTCOMIN
> port.
> + This is recommended to reduce CPU and SPI Load.
> + - pwm: If property "sharp,extmode-high" is specified, this is recommended.
> + It should contain the pwm to use, according to
> + Documentation/devicetree/bindings/pwm/pwm.txt
> + Verify the display datasheet for the EXTCOMIN signal period
> + - disp-gpios: The GPIO used to enable the display, if available. See
> + Documentation/devicetree/bindings/gpio/gpio.txt for details.
> +
> +Examples:
> +
> +ls027b7dh01: smemlcd@0 {
> +compatible = "sharp,ls027b7dh01";
> +reg = <0>;
> +spi-max-frequency = <100>;
> +spi-cs-high;
> +disp-gpios = <&gpio0 7>;
> +disp-active-high;
> +sharp,extmode-high;
> +pwms = <&pwm 0 1>;
> +};
> +
> +ls013b7dh05: smemlcd@3 {
> +compatible = "sharp,ls013b7dh05";
> +reg = <3>;
> +spi-max-frequency = <100>;
> +spi-cs-high;
> +disp-gpios = <&gpio0 13>;
> +disp-active-high;
> +sharp,extmode-high;
> +pwms = <&pwm 0 5000>;
> +sharp,frames-per-sec = <20>;
> +};
> diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
> index b2c9dd4f0cb5..0fff47a59d8b 100644
> --- a/drivers/video/fbdev/Kconfig
> +++ b/drivers/video/fbdev/Kconfig
> @@ -2221,6 +2221,20 @@ config FB_SSD1307
> This driver implements support for the Solomon SSD1307
> OLED controller over I2C.
>
> +config FB_SMEMLCD
> + tristate "Sharp Memory LCD framebuffer support"
> + depends on FB && SPI
> + depends on OF
> + depends on GPIOLIB || COMPILE_TEST
> + select FB_SYS_FOPS
> + select FB_SYS_FILLRECT
> + select FB_SYS_COPYAREA
> + select FB_SYS_IMAGEBLIT
> + select FB_DEFERRED_IO
> + select PWM
> + help
> + This driver implements support for the Sharp Memory LCD
> +
> config FB_SM712
> tristate "Silicon Motion SM712 framebuffer support"
> depends on FB && PCI
> diff --git a/drivers/video/fbdev/Makefile b/drivers/video/fbdev/Makefile
> index cad4fb64442a..5c58dfd8ac08 100644
> --- a/drivers/video/fbdev/Makefile
> +++ b/drivers/video/fbdev/Makefile
> @@ -128,6 +128,7 @@ obj-$(CONFIG_FB_OF) += offb.o
> obj-$(CONFIG_FB_MX3) += mx3fb.o
> obj-$(CONFIG_FB_DA8XX) += da8xx-fb.o
> obj-$(CONFIG_FB_SSD1307) += ssd1307fb.o
> +obj-$(CONFIG_FB_SMEMLCD) += smemlcdfb.o
> obj-$(CONFIG_FB_SIMPLE) += simplefb.o
>
> # the test framebuffer is last
> diff --git a/drivers/video/fbdev/smemlcdfb.c b/drivers/video/fbdev/smemlcdfb.c
Re: [PATCH 1/2] drm/fourcc: fix Amlogic Video Framebuffer Compression macro
Hi Neil.
On Thu, Jul 23, 2020 at 11:05:50AM +0200, Neil Armstrong wrote:
> Fix the Amlogic Video Framebuffer Compression modifier macro to
> correctly add the layout options, a pair of parenthesis was missing.
>
> Fixes: d6528ec88309 ("drm/fourcc: Add modifier definitions for describing
> Amlogic Video Framebuffer Compression")
> Signed-off-by: Neil Armstrong
Looks correct just looking at the patch below.
Acked-by: Sam Ravnborg
I assume you will apply the patch.
Sam
> ---
> include/uapi/drm/drm_fourcc.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index 4bee7de5f306..82f327801267 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -1004,7 +1004,7 @@ drm_fourcc_canonicalize_nvidia_format_mod(__u64
> modifier)
> #define DRM_FORMAT_MOD_AMLOGIC_FBC(__layout, __options) \
> fourcc_mod_code(AMLOGIC, \
> ((__layout) & __fourcc_mod_amlogic_layout_mask) | \
> - ((__options) & __fourcc_mod_amlogic_options_mask \
> + (((__options) & __fourcc_mod_amlogic_options_mask) \
><< __fourcc_mod_amlogic_options_shift))
>
> /* Amlogic FBC Layouts */
> --
> 2.22.0
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7 1/3] dt-bindings: drm/bridge: Document Cadence MHDP bridge bindings
Hi Swapnil.
On Wed, Jul 22, 2020 at 09:40:38AM +0200, Swapnil Jakhade wrote:
> From: Yuti Amonkar
>
> Document the bindings used for the Cadence MHDP DPI/DP bridge in
> yaml format.
>
> Signed-off-by: Yuti Amonkar
> Signed-off-by: Swapnil Jakhade
> Reviewed-by: Rob Herring
> Reviewed-by: Laurent Pinchart
> ---
> .../bindings/display/bridge/cdns,mhdp.yaml| 127 ++
> 1 file changed, 127 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/bridge/cdns,mhdp.yaml
>
> diff --git a/Documentation/devicetree/bindings/display/bridge/cdns,mhdp.yaml
> b/Documentation/devicetree/bindings/display/bridge/cdns,mhdp.yaml
> new file mode 100644
> index ..cdf5760d4ec5
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/cdns,mhdp.yaml
> @@ -0,0 +1,127 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: "http://devicetree.org/schemas/display/bridge/cdns,mhdp.yaml#";
> +$schema: "http://devicetree.org/meta-schemas/core.yaml#";
> +
> +title: Cadence MHDP bridge
> +
> +maintainers:
> + - Swapnil Jakhade
> + - Yuti Amonkar
> +
> +properties:
> + compatible:
> +enum:
> + - cdns,mhdp8546
> + - ti,j721e-mhdp8546
> +
> + reg:
> +minItems: 1
> +maxItems: 2
> +items:
> + - description:
> + Register block of mhdptx apb registers up to PHY mapped area
> (AUX_CONFIG_P).
> + The AUX and PMA registers are not part of this range, they are
> instead
> + included in the associated PHY.
> + - description:
> + Register block for DSS_EDP0_INTG_CFG_VP registers in case of TI J7
> SoCs.
> +
> + reg-names:
> +minItems: 1
> +maxItems: 2
> +items:
> + - const: mhdptx
> + - const: j721e-intg
> +
> + clocks:
> +maxItems: 1
> +description:
> + DP bridge clock, used by the IP to know how to translate a number of
> + clock cycles into a time (which is used to comply with DP standard
> timings
> + and delays).
> +
> + phys:
> +description:
> + phandle to the DisplayPort PHY.
> +
> + ports:
> +type: object
> +description:
> + Ports as described in Documentation/devicetree/bindings/graph.txt.
> +
> +properties:
> + '#address-cells':
> +const: 1
> +
> + '#size-cells':
> +const: 0
> +
> + port@0:
> +type: object
> +description:
> + Input port representing the DP bridge input.
> +
> + port@1:
> +type: object
> +description:
> + Output port representing the DP bridge output.
> +
> +required:
> + - port@0
> + - port@1
> + - '#address-cells'
> + - '#size-cells'
> +
> +allOf:
> + - if:
> + properties:
> +compatible:
> + contains:
> +const: ti,j721e-mhdp8546
> +then:
> + properties:
> +reg:
> + minItems: 2
> +reg-names:
> + minItems: 2
> +
> +required:
> + - compatible
> + - clocks
> + - reg
> + - reg-names
> + - phys
> + - ports
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +mhdp: dp-bridge@f0fb00 {
> +compatible = "cdns,mhdp8546";
> +reg = <0xf0 0xfb00 0x0 0x100>;
> +reg-names = "mhdptx";
> +clocks = <&mhdp_clock>;
> +phys = <&dp_phy>;
> +
> +ports {
Please be consistent in indent.
We do not aling below '{'.
Keep using 4 spaces for indent for the full example.
Sam
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + dp_bridge_input: endpoint {
> +remote-endpoint = <&xxx_dpi_output>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> + dp_bridge_output: endpoint {
> +remote-endpoint = <&xxx_dp_connector_input>;
> + };
> + };
> +};
> +};
> +...
> --
> 2.26.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7 2/3] drm: bridge: Add support for Cadence MHDP DPI/DP bridge
Hi Swapnil Thanks for submitting this driver. A few highlevel things. New bridge drivers shall be prepare for use in a chained bridge driver setup. This prompts you to add the following: - Reelvant bridge operations I noticed at least get_edid, and detect seems applicable. - Support the flags argument and only create the connector if requested to do so. Take a look at other bridge drivers that set DRM_BRIDGE_OP_EDID and DRM_BRIDGE_OP_DETECT for examples. A few notes follows but I did not look at the full driver. Sam On Wed, Jul 22, 2020 at 09:40:39AM +0200, Swapnil Jakhade wrote: > Add a new DRM bridge driver for Cadence MHDP DPTX IP used in TI J721e SoC. > MHDP DPTX IP is the component that complies with VESA DisplayPort (DP) and > embedded Display Port (eDP) standards. It integrates uCPU running the > embedded Firmware (FW) interfaced over APB interface. > > Basically, it takes a DPI stream as input and outputs it encoded in DP > format. Currently, it supports only SST mode. > > Co-developed-by: Tomi Valkeinen > Signed-off-by: Tomi Valkeinen > Co-developed-by: Jyri Sarha > Signed-off-by: Jyri Sarha > Signed-off-by: Quentin Schulz > Signed-off-by: Yuti Amonkar > Signed-off-by: Swapnil Jakhade > --- > drivers/gpu/drm/bridge/Kconfig | 11 + > drivers/gpu/drm/bridge/Makefile |2 + > drivers/gpu/drm/bridge/cdns-mhdp-core.c | 2493 +++ > drivers/gpu/drm/bridge/cdns-mhdp-core.h | 396 > 4 files changed, 2902 insertions(+) > create mode 100644 drivers/gpu/drm/bridge/cdns-mhdp-core.c > create mode 100644 drivers/gpu/drm/bridge/cdns-mhdp-core.h > > diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig > index 43271c21d3fc..6a4c324302a8 100644 > --- a/drivers/gpu/drm/bridge/Kconfig > +++ b/drivers/gpu/drm/bridge/Kconfig > @@ -27,6 +27,17 @@ config DRM_CDNS_DSI > Support Cadence DPI to DSI bridge. This is an internal > bridge and is meant to be directly embedded in a SoC. > > +config DRM_CDNS_MHDP > + tristate "Cadence DPI/DP bridge" > + select DRM_KMS_HELPER > + select DRM_PANEL_BRIDGE > + depends on OF > + help > + Support Cadence DPI to DP bridge. This is an internal > + bridge and is meant to be directly embedded in a SoC. > + It takes a DPI stream as input and outputs it encoded > + in DP format. > + > config DRM_CHRONTEL_CH7033 > tristate "Chrontel CH7033 Video Encoder" > depends on OF > diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile > index d63d4b7e4347..0080a9f80f29 100644 > --- a/drivers/gpu/drm/bridge/Makefile > +++ b/drivers/gpu/drm/bridge/Makefile > @@ -1,5 +1,7 @@ > # SPDX-License-Identifier: GPL-2.0 > obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o > +obj-$(CONFIG_DRM_CDNS_MHDP) += cdns-mhdp.o > +cdns-mhdp-objs := cdns-mhdp-core.o As the bridge driver is a sinlge file there is no need for the extra indirection. If you plan to add extra files later use: cdns-mhdp-y := cdns-mhdp-core.o The "-y" syntax is recommended today. > obj-$(CONFIG_DRM_CHRONTEL_CH7033) += chrontel-ch7033.o > obj-$(CONFIG_DRM_DISPLAY_CONNECTOR) += display-connector.o > obj-$(CONFIG_DRM_LVDS_CODEC) += lvds-codec.o > diff --git a/drivers/gpu/drm/bridge/cdns-mhdp-core.c > b/drivers/gpu/drm/bridge/cdns-mhdp-core.c > new file mode 100644 > index ..b16c5503cef1 > --- /dev/null > +++ b/drivers/gpu/drm/bridge/cdns-mhdp-core.c > @@ -0,0 +1,2493 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * Cadence MHDP DP bridge driver. > + * > + * Copyright: 2019 Cadence Design Systems, Inc. 2020? > + * > + * Author: Quentin Schulz Does not match changelog description - several more authors are listed. > +++ b/drivers/gpu/drm/bridge/cdns-mhdp-core.h > @@ -0,0 +1,396 @@ > +/* SPDX-License-Identifier: GPL-2.0 */ > +/* > + * Cadence MHDP DP bridge driver. > + * > + * Copyright: 2019 Cadence Design Systems, Inc. > + * > + * Author: Quentin Schulz > + * Swapnil Jakhade > + */ > + > +#ifndef CDNS_MHDP_CORE_H > +#define CDNS_MHDP_CORE_H > + > +#include > +#include > +#include > + > +#include > +#include > +#include > + > +struct clk; > +struct device; > +struct phy; > + > +/* Register offsets */ > +#define CDNS_APB_CTRL0x0 > +#define CDNS_CPU_STALL BIT(3) > + > +#define CDNS_MAILBOX_FULL0x8 > +#define CDNS_MAILBOX_EMPTY 0xc > +#define CDNS_MAILBOX_TX_DATA 0x00010 > +#define CDNS_MAILBOX_RX_DATA 0x00014 > +#define CDNS_KEEP_ALIVE 0x00018 > +#define CDNS_KEEP_ALIVE_MASK GENMASK(7, 0) > + > +#define CDNS_VER_L 0x0001C > +#define CDNS_VER_H 0x00020 > +#define CDNS_LIB_L_ADDR 0x00024 > +#define CDNS_LIB_H_ADDR 0x00028 > +
Re: [PATCH v7 3/3] drm: bridge: cdns-mhdp: Add j721e wrapper
Hi Swapnil
Small nits in the following.
Sam
On Wed, Jul 22, 2020 at 09:40:40AM +0200, Swapnil Jakhade wrote:
> Add j721e wrapper for mhdp, which sets up the clock and data muxes.
>
> Signed-off-by: Jyri Sarha
> Signed-off-by: Yuti Amonkar
> Signed-off-by: Swapnil Jakhade
> Reviewed-by: Tomi Valkeinen
> Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/bridge/Kconfig | 13
> drivers/gpu/drm/bridge/Makefile | 5 ++
> drivers/gpu/drm/bridge/cdns-mhdp-core.c | 15 +
> drivers/gpu/drm/bridge/cdns-mhdp-core.h | 1 +
> drivers/gpu/drm/bridge/cdns-mhdp-j721e.c | 75
> drivers/gpu/drm/bridge/cdns-mhdp-j721e.h | 19 ++
> 6 files changed, 128 insertions(+)
> create mode 100644 drivers/gpu/drm/bridge/cdns-mhdp-j721e.c
> create mode 100644 drivers/gpu/drm/bridge/cdns-mhdp-j721e.h
>
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index 6a4c324302a8..8c1738653b7e 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -38,6 +38,19 @@ config DRM_CDNS_MHDP
> It takes a DPI stream as input and outputs it encoded
> in DP format.
>
> +if DRM_CDNS_MHDP
> +
> +config DRM_CDNS_MHDP_J721E
> + depends on ARCH_K3_J721E_SOC
> + bool "J721E Cadence DPI/DP wrapper support"
> + default y
> + help
> + Support J721E Cadence DPI/DP wrapper. This is a wrapper
> + which adds support for J721E related platform ops. It
> + initializes the J721e Display Port and sets up the
> + clock and data muxes.
> +endif
> +
> config DRM_CHRONTEL_CH7033
> tristate "Chrontel CH7033 Video Encoder"
> depends on OF
> diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
> index 0080a9f80f29..f81d606e9598 100644
> --- a/drivers/gpu/drm/bridge/Makefile
> +++ b/drivers/gpu/drm/bridge/Makefile
> @@ -2,6 +2,11 @@
> obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o
> obj-$(CONFIG_DRM_CDNS_MHDP) += cdns-mhdp.o
> cdns-mhdp-objs := cdns-mhdp-core.o
> +
> +ifeq ($(CONFIG_DRM_CDNS_MHDP_J721E),y)
> + cdns-mhdp-objs += cdns-mhdp-j721e.o
> +endif
Use the idiomatic:
cdns-mhdp-$(CONFIG_DRM_CDNS_MHDP_J721E) += cdns-mhdp-j721e.o
> +
> obj-$(CONFIG_DRM_CHRONTEL_CH7033) += chrontel-ch7033.o
> obj-$(CONFIG_DRM_DISPLAY_CONNECTOR) += display-connector.o
> obj-$(CONFIG_DRM_LVDS_CODEC) += lvds-codec.o
> diff --git a/drivers/gpu/drm/bridge/cdns-mhdp-core.c
> b/drivers/gpu/drm/bridge/cdns-mhdp-core.c
> index b16c5503cef1..eeb33c54334f 100644
> --- a/drivers/gpu/drm/bridge/cdns-mhdp-core.c
> +++ b/drivers/gpu/drm/bridge/cdns-mhdp-core.c
> @@ -38,6 +38,8 @@
>
> #include "cdns-mhdp-core.h"
>
> +#include "cdns-mhdp-j721e.h"
> +
> static DECLARE_WAIT_QUEUE_HEAD(fw_load_wq);
>
> static int cdns_mhdp_mailbox_read(struct cdns_mhdp_device *mhdp)
> @@ -1691,6 +1693,16 @@ static int cdns_mhdp_attach(struct drm_bridge *bridge,
>
> conn->display_info.bus_flags = DRM_BUS_FLAG_DE_HIGH;
>
> + if (of_device_is_compatible(mhdp->dev->of_node, "ti,j721e-mhdp8546"))
> + /*
> + * DP is internal to J7 SoC and we need to use DRIVE_POSEDGE
> + * in the display controller. This is achieved for the time being
> + * by defining SAMPLE_NEGEDGE here.
> + */
> + conn->display_info.bus_flags |=
> + DRM_BUS_FLAG_PIXDATA_SAMPLE_NEGEDGE |
> + DRM_BUS_FLAG_SYNC_SAMPLE_NEGEDGE;
> +
> ret = drm_connector_attach_encoder(conn, bridge->encoder);
> if (ret) {
> dev_err(mhdp->dev, "failed to attach connector to encoder\n");
> @@ -2470,6 +2482,9 @@ static int cdns_mhdp_remove(struct platform_device
> *pdev)
>
> static const struct of_device_id mhdp_ids[] = {
> { .compatible = "cdns,mhdp8546", },
> +#ifdef CONFIG_DRM_CDNS_MHDP_J721E
> + { .compatible = "ti,j721e-mhdp8546", .data = &mhdp_ti_j721e_ops },
> +#endif
> { /* sentinel */ }
> };
> MODULE_DEVICE_TABLE(of, mhdp_ids);
> diff --git a/drivers/gpu/drm/bridge/cdns-mhdp-core.h
> b/drivers/gpu/drm/bridge/cdns-mhdp-core.h
> index d1bfcdef4249..4e176698caca 100644
> --- a/drivers/gpu/drm/bridge/cdns-mhdp-core.h
> +++ b/drivers/gpu/drm/bridge/cdns-mhdp-core.h
> @@ -343,6 +343,7 @@ struct cdns_mhdp_bridge_state {
>
> struct cdns_mhdp_device {
> void __iomem *regs;
> + void __iomem *j721e_regs;
>
> struct device *dev;
> struct clk *clk;
> diff --git a/drivers/gpu/drm/bridge/cdns-mhdp-j721e.c
> b/drivers/gpu/drm/bridge/cdns-mhdp-j721e.c
> new file mode 100644
> index ..7555c217c9a0
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/cdns-mhdp-j721e.c
> @@ -0,0 +1,75 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * TI j721e Cadence MHDP DP wrapper
> + *
> + * Copyright (C) 2019 Texas Instruments Incorporated - http://www.ti.com/
> + * Author: Jyri Sarha + */
> +
> +#include
> +#include
> +
> +#include "cdns-mhdp-j721e.h
Re: [PATCH] drm/mcde: Fix stability issue
On Sun, Jul 19, 2020 at 01:33:22AM +0200, Linus Walleij wrote:
> Whenener a display update was sent, apart from updating
> the memory base address we called mcde_display_send_one_frame()
> which also sent a command to the display requesting the TE IRQ
> and enabling the FIFO.
>
> When continous updates are running this is wrong: we need
> to only send this to start the flow to the display on
> the very first update. This lead to the display pipeline
> locking up and crashing.
>
> Check if the flow is already running and in that case
> do not call mcde_display_send_one_frame().
>
> This fixes crashes on the Samsung GT-S7710 (Skomer).
>
> Cc: Stephan Gerhold
> Cc: sta...@vger.kernel.org
> Signed-off-by: Linus Walleij
> ---
> drivers/gpu/drm/mcde/mcde_display.c | 11 ---
> 1 file changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/mcde/mcde_display.c
> b/drivers/gpu/drm/mcde/mcde_display.c
> index 212aee60cf61..1d8ea8830a17 100644
> --- a/drivers/gpu/drm/mcde/mcde_display.c
> +++ b/drivers/gpu/drm/mcde/mcde_display.c
> @@ -1086,9 +1086,14 @@ static void mcde_display_update(struct
> drm_simple_display_pipe *pipe,
>*/
> if (fb) {
> mcde_set_extsrc(mcde, drm_fb_cma_get_gem_addr(fb, pstate, 0));
> - if (!mcde->video_mode)
> - /* Send a single frame using software sync */
> - mcde_display_send_one_frame(mcde);
> + if (!mcde->video_mode) {
> + /*
> + * Send a single frame using software sync if the flow
> + * is not active yet.
> + */
> + if (mcde->flow_active == 0)
> + mcde_display_send_one_frame(mcde);
> + }
I think this makes sense as a fix for the issue you described, so FWIW:
Acked-by: Stephan Gerhold
While looking at this I had a few thoughts for potential future patches:
- Clearly mcde_display_send_one_frame() does not only send a single
frame only in some cases (when te_sync = true), so maybe it should
be named differently?
- I was a bit confused because with this change we also call
mcde_dsi_te_request() only once. Looking at the vendor driver the
nova_dsilink_te_request() function that is very similar is only
called within mcde_add_bta_te_oneshot_listener(), which is only
called for MCDE_SYNCSRC_BTA.
However, the rest of the MCDE code looks more similar to
MCDE_SYNCSRC_TE0, which does not call that function in the vendor
driver. I wonder if mcde_dsi_te_request() is needed at all?
Thanks,
Stephan
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 11/22] drm: mxsfb: Stop using DRM simple display pipeline helper
Hi Stefan,
On Fri, Jul 17, 2020 at 05:06:55AM +0300, Laurent Pinchart wrote:
> On Thu, Jul 09, 2020 at 12:25:42PM +0200, Stefan Agner wrote:
> > On 2020-06-16 03:50, Laurent Pinchart wrote:
> >> On Thu, Jun 11, 2020 at 09:33:11PM +0200, Stefan Agner wrote:
> >>> On 2020-05-30 05:10, Laurent Pinchart wrote:
> The DRM simple display pipeline helper only supports a single plane. In
> order to prepare for support of the alpha plane on i.MX6SX and i.MX7,
> move away from the helper. No new feature is added.
>
> Signed-off-by: Laurent Pinchart
> ---
> Changes since v1:
>
> - Move after mxsfb_crtc.c rename to mxsfb_kms.c
> ---
> drivers/gpu/drm/mxsfb/mxsfb_drv.c | 108 +++---
> drivers/gpu/drm/mxsfb/mxsfb_drv.h | 23 ++--
> drivers/gpu/drm/mxsfb/mxsfb_kms.c | 184 +++---
> 3 files changed, 197 insertions(+), 118 deletions(-)
>
> diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
> b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
> index 204c1e52e9aa..a8da92976d13 100644
> --- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
> +++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
> @@ -10,22 +10,23 @@
>
> #include
> #include
> +#include
> #include
> #include
> +#include
> #include
> -#include
>
> -#include
> #include
> -#include
> +#include
> +#include
> #include
> #include
> #include
> #include
> #include
> +#include
> #include
> #include
> -#include
> #include
>
> #include "mxsfb_drv.h"
> @@ -57,17 +58,6 @@ static const struct mxsfb_devdata mxsfb_devdata[] = {
> },
> };
>
> -static const uint32_t mxsfb_formats[] = {
> -DRM_FORMAT_XRGB,
> -DRM_FORMAT_RGB565
> -};
> -
> -static struct mxsfb_drm_private *
> -drm_pipe_to_mxsfb_drm_private(struct drm_simple_display_pipe *pipe)
> -{
> -return container_of(pipe, struct mxsfb_drm_private, pipe);
> -}
> -
> void mxsfb_enable_axi_clk(struct mxsfb_drm_private *mxsfb)
> {
> if (mxsfb->clk_axi)
> @@ -90,77 +80,6 @@ static const struct drm_mode_config_helper_funcs
> mxsfb_mode_config_helpers = {
> .atomic_commit_tail = drm_atomic_helper_commit_tail_rpm,
> };
>
> -static void mxsfb_pipe_enable(struct drm_simple_display_pipe *pipe,
> - struct drm_crtc_state *crtc_state,
> - struct drm_plane_state *plane_state)
> -{
> -struct mxsfb_drm_private *mxsfb =
> drm_pipe_to_mxsfb_drm_private(pipe);
> -struct drm_device *drm = pipe->plane.dev;
> -
> -pm_runtime_get_sync(drm->dev);
> -mxsfb_crtc_enable(mxsfb);
> -}
> -
> -static void mxsfb_pipe_disable(struct drm_simple_display_pipe *pipe)
> -{
> -struct mxsfb_drm_private *mxsfb =
> drm_pipe_to_mxsfb_drm_private(pipe);
> -struct drm_device *drm = pipe->plane.dev;
> -struct drm_crtc *crtc = &pipe->crtc;
> -struct drm_pending_vblank_event *event;
> -
> -mxsfb_crtc_disable(mxsfb);
> -pm_runtime_put_sync(drm->dev);
> -
> -spin_lock_irq(&drm->event_lock);
> -event = crtc->state->event;
> -if (event) {
> -crtc->state->event = NULL;
> -drm_crtc_send_vblank_event(crtc, event);
> -}
> -spin_unlock_irq(&drm->event_lock);
> -}
> -
> -static void mxsfb_pipe_update(struct drm_simple_display_pipe *pipe,
> - struct drm_plane_state *plane_state)
> -{
> -struct mxsfb_drm_private *mxsfb =
> drm_pipe_to_mxsfb_drm_private(pipe);
> -
> -mxsfb_plane_atomic_update(mxsfb, plane_state);
> -}
> -
> -static int mxsfb_pipe_enable_vblank(struct drm_simple_display_pipe
> *pipe)
> -{
> -struct mxsfb_drm_private *mxsfb =
> drm_pipe_to_mxsfb_drm_private(pipe);
> -
> -/* Clear and enable VBLANK IRQ */
> -mxsfb_enable_axi_clk(mxsfb);
> -writel(CTRL1_CUR_FRAME_DONE_IRQ, mxsfb->base + LCDC_CTRL1 +
> REG_CLR);
> -writel(CTRL1_CUR_FRAME_DONE_IRQ_EN, mxsfb->base + LCDC_CTRL1 +
> REG_SET);
> -mxsfb_disable_axi_clk(mxsfb);
> -
> -return 0;
> -}
> -
> -static void mxsfb_pipe_disable_vblank(struct drm_simple_display_pipe
> *pipe)
> -{
> -struct mxsfb_drm_private *mxsfb =
> drm_pipe_to_mxsfb_drm_private(pipe);
> -
> -/* Disable and clear VBLANK IRQ */
> -mxsfb_enable_axi_clk(mxsfb);
[Bug 207383] [Regression] 5.7 amdgpu/polaris11 gpf: amdgpu_atomic_commit_tail
https://bugzilla.kernel.org/show_bug.cgi?id=207383 --- Comment #95 from Nicholas Kazlauskas (nicholas.kazlaus...@amd.com) --- Created attachment 290583 --> https://bugzilla.kernel.org/attachment.cgi?id=290583&action=edit 0001-drm-amd-display-Force-add-all-CRTCs-to-state-when-us.patch So the sequence looks like the following: 1. Non-blocking commit #1 requested, checked, swaps state and deferred to work queue. 2. Non-blocking commit #2 requested, checked, swaps state and deferred to work queue. Commits #1 and #2 don't touch any of the same core DRM objects (CRTCs, Planes, Connectors) so Commit #2 does not stall for Commit #1. DRM Private Objects have always been avoided in stall checks, so we have no safety from DRM core in this regard. 3. Due to system load commit #2 executes first and finishes its commit tail work. At the end of commit tail, as part of DRM core, it calls drm_atomic_state_put(). Since this was the pageflip IOCTL we likely already dropped the reference on the state held by the IOCTL itself. So it's going to actually free at this point. This eventually calls drm_atomic_state_clear() which does the following: obj->funcs->atomic_destroy_state(obj, state->private_objs[i].state); Note that it clears "state" here. Commit sets "state" to the following: state->private_objs[i].state = old_obj_state; obj->state = new_obj_state; Since Commit #1 swapped first this means Commit #2 actually does free Commit #1's private object. 4. Commit #1 then executes and we get a use after free. Same bug, it's just this was never corrupted before by the slab changes. It's been sitting dormant for 5.0~5.8. Attached is a patch that might help resolve this. -- 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
[PATCH v9 08/12] device core: Introduce DMA range map, supplanting dma_pfn_offset
The new field 'dma_range_map' in struct device is used to facilitate the
use of single or multiple offsets between mapping regions of cpu addrs and
dma addrs. It subsumes the role of "dev->dma_pfn_offset" which was only
capable of holding a single uniform offset and had no region bounds
checking.
The function of_dma_get_range() has been modified so that it takes a single
argument -- the device node -- and returns a map, NULL, or an error code.
The map is an array that holds the information regarding the DMA regions.
Each range entry contains the address offset, the cpu_start address, the
dma_start address, and the size of the region.
of_dma_configure() is the typical manner to set range offsets but there are
a number of ad hoc assignments to "dev->dma_pfn_offset" in the kernel
driver code. These cases now invoke the function
dma_attach_offset_range(dev, cpu_addr, dma_addr, size).
Signed-off-by: Jim Quinlan
---
arch/arm/include/asm/dma-mapping.h| 10 +--
arch/arm/mach-keystone/keystone.c | 17 +++--
arch/sh/drivers/pci/pcie-sh7786.c | 9 +--
arch/sh/kernel/dma-coherent.c | 15 ++--
arch/x86/pci/sta2x11-fixup.c | 7 +-
drivers/acpi/arm64/iort.c | 5 +-
drivers/gpu/drm/sun4i/sun4i_backend.c | 5 +-
drivers/iommu/io-pgtable-arm.c| 2 +-
.../platform/sunxi/sun4i-csi/sun4i_csi.c | 5 +-
.../platform/sunxi/sun6i-csi/sun6i_csi.c | 4 +-
drivers/of/address.c | 71 ---
drivers/of/device.c | 43 ++-
drivers/of/of_private.h | 10 +--
drivers/of/unittest.c | 32 ++---
drivers/pci/controller/pcie-brcmstb.c | 1 +
drivers/remoteproc/remoteproc_core.c | 2 +-
.../staging/media/sunxi/cedrus/cedrus_hw.c| 7 +-
drivers/usb/core/message.c| 4 +-
drivers/usb/core/usb.c| 2 +-
include/linux/device.h| 4 +-
include/linux/dma-direct.h| 8 +--
include/linux/dma-mapping.h | 34 +
kernel/dma/coherent.c | 10 +--
kernel/dma/mapping.c | 63
24 files changed, 248 insertions(+), 122 deletions(-)
diff --git a/arch/arm/include/asm/dma-mapping.h
b/arch/arm/include/asm/dma-mapping.h
index bdd80ddbca34..2405afeb7957 100644
--- a/arch/arm/include/asm/dma-mapping.h
+++ b/arch/arm/include/asm/dma-mapping.h
@@ -35,8 +35,11 @@ static inline const struct dma_map_ops
*get_arch_dma_ops(struct bus_type *bus)
#ifndef __arch_pfn_to_dma
static inline dma_addr_t pfn_to_dma(struct device *dev, unsigned long pfn)
{
- if (dev)
- pfn -= dev->dma_pfn_offset;
+ if (dev) {
+ phys_addr_t paddr = PFN_PHYS(pfn);
+
+ pfn -= (dma_offset_from_phys_addr(dev, paddr) >> PAGE_SHIFT);
+ }
return (dma_addr_t)__pfn_to_bus(pfn);
}
@@ -45,8 +48,7 @@ static inline unsigned long dma_to_pfn(struct device *dev,
dma_addr_t addr)
unsigned long pfn = __bus_to_pfn(addr);
if (dev)
- pfn += dev->dma_pfn_offset;
-
+ pfn += (dma_offset_from_dma_addr(dev, addr) >> PAGE_SHIFT);
return pfn;
}
diff --git a/arch/arm/mach-keystone/keystone.c
b/arch/arm/mach-keystone/keystone.c
index 638808c4e122..78808942ad1c 100644
--- a/arch/arm/mach-keystone/keystone.c
+++ b/arch/arm/mach-keystone/keystone.c
@@ -8,6 +8,7 @@
*/
#include
#include
+#include
#include
#include
#include
@@ -24,8 +25,6 @@
#include "keystone.h"
-static unsigned long keystone_dma_pfn_offset __read_mostly;
-
static int keystone_platform_notifier(struct notifier_block *nb,
unsigned long event, void *data)
{
@@ -38,9 +37,12 @@ static int keystone_platform_notifier(struct notifier_block
*nb,
return NOTIFY_BAD;
if (!dev->of_node) {
- dev->dma_pfn_offset = keystone_dma_pfn_offset;
- dev_err(dev, "set dma_pfn_offset%08lx\n",
- dev->dma_pfn_offset);
+ int ret = dma_set_offset_range(dev, KEYSTONE_HIGH_PHYS_START,
+ KEYSTONE_LOW_PHYS_START,
+ KEYSTONE_HIGH_PHYS_SIZE);
+ dev_err(dev, "set dma_offset%08llx%s\n",
+ KEYSTONE_HIGH_PHYS_START - KEYSTONE_LOW_PHYS_START,
+ ret ? " failed" : "");
}
return NOTIFY_OK;
}
@@ -51,11 +53,8 @@ static struct notifier_block platform_nb = {
static void __init keystone_init(void)
{
- if (PHYS_OFFSET >= KEYSTONE_HIGH_PHYS_START) {
- keystone_dma_pfn_offset = PFN_DOWN(KEYSTONE_HIGH_PHYS_START -
- KEYSTONE_LOW_PHYS_START);
+ if (PHYS_O
[PATCH v9 00/12] PCI: brcmstb: enable PCIe for STB chips
Patchset Summary:
Enhance a PCIe host controller driver. Because of its unusual design
we are foced to change dev->dma_pfn_offset into a more general role
allowing multiple offsets. See the 'v1' notes below for more info.
NOTE: ChristophH wanted the dma_set_offset_range() function
to have a range from [0...~(phys_addr_t)0], i.e. no specific
bounds. RobinM requested this function to have specific bounds,
which has been implemented since v6. If I do not hear from
Robin in the near future about this request, I will submit
v10 which will have no specific bounds.
v9:
Commit: "device core: Introduce DMA range map, supplanting ..."
-- A number of code improvements were implemented as suggested by
ChristophH. Unfortunately, some of these changes reversed the
implemented suggestions of other reviewers; for example, the new
macros PFN_DMA_ADDR(), DMA_ADDR_PFN() have been pulled.
v8:
Commit: "device core: Introduce DMA range map, supplanting ..."
-- To satisfy a specific m68 compile configuration, I moved the 'struct
bus_dma_region; definition out of #ifdef CONFIG_HAS_DMA and also defined
three inline functions for !CONFIG_HAS_DMA (kernel test robot).
-- The sunXi drivers -- suc4i_csi, sun6i_csi, cedrus_hw -- set
a pfn_offset outside of_dma_configure() but the code offers no
insight on the size of the translation window. V7 had me using
SIZE_MAX as the size. I have since contacted the sunXi maintainer and
he said that using a size of SZ_4G would cover sunXi configurations.
v7:
Commit: "device core: Introduce DMA range map, supplanting ..."
-- remove second kcalloc/copy in device.c (AndyS)
-- use PTR_ERR_OR_ZERO() and PHYS_PFN() (AndyS)
-- indentation, sizeof(struct ...) => sizeof(*r) (AndyS)
-- add pfn.h definitions: PFN_DMA_ADDR(), DMA_ADDR_PFN() (AndyS)
-- Fixed compile error in "sun6i_csi.c" (kernel test robot)
Commit "ata: ahci_brcm: Fix use of BCM7216 reset controller"
-- correct name of function in the commit msg (SergeiS)
v6:
Commit "device core: Introduce DMA range map":
-- of_dma_get_range() now takes a single argument and returns either
NULL, a valid map, or an ERR_PTR. (Robin)
-- offsets are no longer a PFN value but an actual address. (Robin)
-- the bus_dma_region struct stores the range size instead of
the cpu_end and pci_end values. (Robin)
-- devices that were setting a single offset with no boundaries
have been modified to have boundaries; in a few places
where this information was unavilable a /* FIXME: ... */
comment was added. (Robin)
-- dma_attach_offset_range() can be called when an offset
map already exists; if it's range is already present
nothing is done and success is returned. (Robin)
All commits:
-- Man name/style/corrections/etc changed (Bjorn)
-- rebase to Torvalds master
v5:
Commit "device core: Introduce multiple dma pfn offsets"
-- in of/address.c: "map_size = 0" => "*map_size = 0"
-- use kcalloc instead of kzalloc (AndyS)
-- use PHYS_ADDR_MAX instead of "~(phys_addr_t)0"
Commit "PCI: brcmstb: Set internal memory viewport sizes"
-- now gives error on missing dma-ranges property.
Commit "dt-bindings: PCI: Add bindings for more Brcmstb chips"
-- removed "Allof:" from brcm,scb-sizes definition (RobH)
All Commits:
-- indentation style, use max chars 100 (AndyS)
-- rebased to torvalds master
v4:
Commit "device core: Introduce multiple dma pfn offsets"
-- of_dma_get_range() does not take a dev param but instead
takes two "out" params: map and map_size. We do this so
that the code that parses dma-ranges is separate from
the code that modifies 'dev'. (Nicolas)
-- the separate case of having a single pfn offset has
been removed and is now processed by going through the
map array. (Nicolas)
-- move attach_uniform_dma_pfn_offset() from of/address.c to
dma/mapping.c so that it does not depend on CONFIG_OF. (Nicolas)
-- devm_kcalloc => devm_kzalloc (DanC)
-- add/fix assignment to dev->dma_pfn_offset_map for func
attach_uniform_dma_pfn_offset() (DanC, Nicolas)
-- s/struct dma_pfn_offset_region/struct bus_dma_region/ (Nicolas)
-- s/attach_uniform_dma_pfn_offset/dma_attach_uniform_pfn_offset/
-- s/attach_dma_pfn_offset_map/dma_attach_pfn_offset_map/
-- More use of PFN_{PHYS,DOWN,UP}. (AndyS)
Commit "of: Include a dev param in of_dma_get_range()"
-- this commit was sqaushed with "device core: Introduce ..."
v3:
Commit "device core: Introduce multiple dma pfn offsets"
Commit "arm: dma-mapping: Invoke dma offset func if needed"
-- The above two commits have been squashed. More importantly,
the code has been modified so that the functionality for
multiple pfn offsets subsumes the use of dev->dma_pfn_offset.
In fact, dma_pfn_offset is removed and supplanted by
dma_pfn_offset_map, which is a pointer to an array. The
Re: [PATCH] amdgpu_dm: fix nonblocking atomic commit use-after-free
On Saturday, July 25, 2020 12:59 AM, Duncan <1i5t5.dun...@cox.net> wrote: > On Sat, 25 Jul 2020 03:03:52 + > Mazin Rezk mn...@protonmail.com wrote: > > > > Am 24.07.20 um 19:33 schrieb Kees Cook: > > > > > > > There was a fix to disable the async path for this driver that > > > > worked around the bug too, yes? That seems like a safer and more > > > > focused change that doesn't revert the SLUB defense for all > > > > users, and would actually provide a complete, I think, workaround > > > > That said, I haven't seen the async disabling patch. If you could > > link to it, I'd be glad to test it out and perhaps we can use that > > instead. > > I'm confused. Not to put words in Kees' mouth; /I/ am confused (which > admittedly could well be just because I make no claims to be a > coder and am simply reading the bug and thread, but I'd appreciate some > "unconfusing" anyway). > > My interpretation of the "async disabling" reference was that it was to > comment #30 on the bug: > > https://bugzilla.kernel.org/show_bug.cgi?id=207383#c30 > > ... which (if I'm not confused on this point too) appears to be yours. > There it was stated... > > > > > > > > I've also found that this bug exclusively occurs when commit_work is on > the workqueue. After forcing drm_atomic_helper_commit to run all of the > commits without adding to the workqueue and running the OS, the issue > seems to have disappeared. > > > Would not forcing all commits to run directly, without placing them on > the workqueue, be "async disabling"? That's what I /thought/ he was > referencing. Oh, I thought he was referring to a different patch. Kees, could I get your confirmation on this? The change I made actually affected all of the DRM code, although this could easily be changed to be specific to amdgpu. (By forcing blocking on amdgpu_dm's non-blocking commit code) That said, I'd still need to test further because I only did test it for a couple of hours then. Although it should work in theory. > > OTOH your base/context swap idea sounds like a possibly "less > disturbance" workaround, if it works, and given the point in the > commit cycle... (But if it's out Sunday it's likely too late to test > and get it in now anyway; if it's another week, tho...) The base/context swap idea should make the use-after-free behave how it did in 5.6. Since the bug doesn't cause an issue in 5.6, it's less of a "less disturbance" workaround and more of a "no disturbance" workaround. Thanks, Mazin Rezk > > > > Duncan - No HTML messages please; they are filtered as spam. > "Every nonfree program has a lord, a master -- > and if you use the program, he is your master." Richard Stallman ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] amdgpu_dm: fix nonblocking atomic commit use-after-free
On Friday, July 24, 2020 5:19 PM, Paul Menzel wrote:
> Dear Kees,
>
> Am 24.07.20 um 19:33 schrieb Kees Cook:
>
> > On Fri, Jul 24, 2020 at 09:45:18AM +0200, Paul Menzel wrote:
> >
> > > Am 24.07.20 um 00:32 schrieb Kees Cook:
> > >
> > > > On Thu, Jul 23, 2020 at 09:10:15PM +, Mazin Rezk wrote:
> > > > As Linux 5.8-rc7 is going to be released this Sunday, I wonder, if
> > > > commit
> > > > 3202fa62f ("slub: relocate freelist pointer to middle of object")
> > > > should be
> > > > reverted for now to fix the regression for the users according to
> > > > Linux’ no
> > > > regression policy. Once the AMDGPU/DRM driver issue is fixed, it can be
> > > > reapplied. I know it’s not optimal, but as some testing is going to be
> > > > involved for the fix, I’d argue it’s the best option for the users.
> >
> > Well, the SLUB defense was already released in v5.7, so I'm not sure it
> > really helps for amdgpu_dm users seeing it there too.
>
> In my opinion, it would help, as the stable release could pick up the
> revert, ones it’s in Linus’ master branch.
>
> > There was a fix to disable the async path for this driver that worked
> > around the bug too, yes? That seems like a safer and more focused
> > change that doesn't revert the SLUB defense for all users, and would
> > actually provide a complete, I think, workaround whereas reverting
> > the SLUB change means the race still exists. For example, it would be
> > hit with slab poisoning, etc.
>
> I do not know. If there is such a fix, that would be great. But if you
> do not know, how should a normal user? ;-)
>
> Kind regards,
>
> Paul
>
> Kind regards,
>
> Paul
If we're talking about workarounds now, I suggest simply swapping the base
and context variables in struct dm_atomic_state. By that way, we won't need
to change non-amdgpu parts of the code (e.g. by reverting the SLUB patch).
Prior to 3202fa62f, the freelist pointer was stored in dm_state->base which
was never dereferenced and therefore caused no noticeable issue. After
3202fa62f, the freelist pointer is stored in the middle of the struct (i.e.
dm_state->context).
Swapping the position of the base and context variables in dm_atomic_state
should, in theory, revert this code back to it's pre-5.7 state since the
code would be back to overwriting base instead.
If we decide to use this workaround, I can write the patch and do more
extended tests to confirm it works around the issues.
That said, I haven't seen the async disabling patch. If you could link to
it, I'd be glad to test it out and perhaps we can use that instead.
Thanks,
Mazin Rezk
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] amdgpu_dm: fix nonblocking atomic commit use-after-free
On Thursday, July 23, 2020 6:57 PM, Mazin Rezk wrote:
> It seems that I spoke too soon. I ran the system for another hour after
> submitting the patch and the bug just occurred. :/
>
> Sadly, that means the bug isn't really fixed and that I have to go
> investigate further.
>
> At the very least, this patch seems to delay the occurrence of the bug
> significantly which may help in further discovering the cause.
>
> On Thursday, July 23, 2020 6:16 PM, Kazlauskas, Nicholas
> nicholas.kazlaus...@amd.com wrote:
>
> > On 2020-07-23 5:10 p.m., Mazin Rezk wrote:
> >
> > > When amdgpu_dm_atomic_commit_tail is running in the workqueue,
> > > drm_atomic_state_put will get called while amdgpu_dm_atomic_commit_tail is
> > > running, causing a race condition where state (and then dm_state) is
> > > sometimes freed while amdgpu_dm_atomic_commit_tail is running. This bug
> > > has
> > > occurred since 5.7-rc1 and is well documented among polaris11 users [1].
> > > Prior to 5.7, this was not a noticeable issue since the freelist pointer
> > > was stored at the beginning of dm_state (base), which was unused. After
> > > changing the freelist pointer to be stored in the middle of the struct,
> > > the
> > > freelist pointer overwrote the context, causing dc_state to become garbage
> > > data and made the call to dm_enable_per_frame_crtc_master_sync dereference
> > > a freelist pointer.
> > > This patch fixes the aforementioned issue by calling drm_atomic_state_get
> > > in amdgpu_dm_atomic_commit before drm_atomic_helper_commit is called and
> > > drm_atomic_state_put after amdgpu_dm_atomic_commit_tail is complete.
> > > According to my testing on 5.8.0-rc6, this should fix bug 207383 on
> > > Bugzilla [1].
> > > [1] https://bugzilla.kernel.org/show_bug.cgi?id=207383
> > > Fixes: 3202fa62f ("slub: relocate freelist pointer to middle of object")
> > > Reported-by: Duncan 1i5t5.dun...@cox.net
> > > Signed-off-by: Mazin Rezk mn...@protonmail.com
> >
> > Thanks for the investigation and your patch. I appreciate the help in
> > trying to narrow down the root cause as this issue has been difficult to
> > reproduce on my setups.
> > Though I'm not sure this really resolves the issue - we make use of the
> > drm_atomic_helper_commit helper function from DRM which internally does
> > what you're doing with this patch:
> > drm_atomic_state_get(state);
> > if (nonblock)
> > queue_work(system_unbound_wq, &state->commit_work);
> >
> > else
> > commit_tail(state);
> >
> >
> > So even when it gets queued off to the unbound workqueue we still have a
> > reference on the state.
> > That reference gets dropped as part of commit tail helper in DRM as well:
> > if (funcs && funcs->atomic_commit_tail)
> >
> > funcs->atomic_commit_tail(old_state);
> >
> > else
> > drm_atomic_helper_commit_tail(old_state);
> >
> >
> > commit_time_ms = ktime_ms_delta(ktime_get(), start);
> > if (commit_time_ms > 0)
> >
> > drm_self_refresh_helper_update_avg_times(old_state,
> > (unsigned long)commit_time_ms,
> > new_self_refresh_mask);
> >
> >
> > drm_atomic_helper_commit_cleanup_done(old_state);
> > drm_atomic_state_put(old_state);
>
> I initially noticed that right after I wrote this patch so I was expecting
> the patch to fail. However, after several hours of testing, the crash just
> didn't occur so I believed the bug was fixed.
>
> > So instead of a use after free happening when we access the state we get
> > a double-free happening later at the end of commit tail in DRM.
> > What I think would be the right next step here is to actually determine
> > what sequence of IOCTLs and atomic commits are happening under your
> > setup with a very verbose dmesg log. You can set a debug level for DRM
> > in your kernel parameters with something like:
> > drm.debug=0x54
> > I don't see anything in amdgpu_dm.c that looks like it would be freeing
> > the state so I suspect something in the core is this doing this.
>
> Going through the KASAN use-after-free bug report in the Bugzilla
> attachments, it appears that the state is being freed at the end of
> commit_tail. Perhaps amdgpu_dm_atomic_commit_tail is being called on the
> the same old state twice? I can't quite think of any other possible
> explanation as to why that happens.
I think I've more or less confirmed that this is the case.
I created two padding variables, one to store debug magic numbers and one
to store the freelist pointer. I had magic numbers for initialised,
preuse, and used states. When the dm_atomic_state is initialised, the
padding is set to the init magic number. Right before commit_tail is
called, the padding is set to the preuse magic number. During
dm_atomic_get_new_state checks the magic number to confirm that it
was in the preuse state and then set it to used. If it failed that check
and it was already in a used state, there was a breakpoint s
[Bug 207383] [Regression] 5.7 amdgpu/polaris11 gpf: amdgpu_atomic_commit_tail
https://bugzilla.kernel.org/show_bug.cgi?id=207383 --- Comment #96 from mn...@protonmail.com --- (In reply to Nicholas Kazlauskas from comment #95) > Created attachment 290583 [details] > 0001-drm-amd-display-Force-add-all-CRTCs-to-state-when-us.patch > > So the sequence looks like the following: > > 1. Non-blocking commit #1 requested, checked, swaps state and deferred to > work queue. > > 2. Non-blocking commit #2 requested, checked, swaps state and deferred to > work queue. > > Commits #1 and #2 don't touch any of the same core DRM objects (CRTCs, > Planes, Connectors) so Commit #2 does not stall for Commit #1. DRM Private > Objects have always been avoided in stall checks, so we have no safety from > DRM core in this regard. > > 3. Due to system load commit #2 executes first and finishes its commit tail > work. At the end of commit tail, as part of DRM core, it calls > drm_atomic_state_put(). > > Since this was the pageflip IOCTL we likely already dropped the reference on > the state held by the IOCTL itself. So it's going to actually free at this > point. > > This eventually calls drm_atomic_state_clear() which does the following: > > obj->funcs->atomic_destroy_state(obj, state->private_objs[i].state); > > Note that it clears "state" here. Commit sets "state" to the following: > > state->private_objs[i].state = old_obj_state; > obj->state = new_obj_state; What line number roughly does that happen on? I can't seem to find that anywhere in amdgpu_dm.c > > Since Commit #1 swapped first this means Commit #2 actually does free Commit > #1's private object. > > 4. Commit #1 then executes and we get a use after free. > > Same bug, it's just this was never corrupted before by the slab changes. > It's been sitting dormant for 5.0~5.8. > > Attached is a patch that might help resolve this. I actually just started testing my own patch, but I'll apply your patch and see if it works though. My patch is based on how you solved bug 204181 [1] and instead of setting the new dc_state to the old dc_state, it frees the dm_state and removes the associated private object. If I understand correctly, if dm_state is set to NULL (i.e. new state cannot be found), commit_tail retains the current state and context. Since dm_state only contains the context (which is unused), I don't see why freeing the state and clearing the private object beforehand would be an issue. I would attach the patch but I'll need to clean up my code first. If the patch works for the next few hours, I'll clean it up and attach it. [1] https://patchwork.freedesktop.org/patch/320797/ -- 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 13/21] drm/bridge: megachips: add helper to create connector
On Sat, Jul 11, 2020 at 01:34:30AM +0300, Laurent Pinchart wrote:
> Hi Sam,
>
> Thank you for the patch.
>
> On Fri, Jul 03, 2020 at 09:24:09PM +0200, Sam Ravnborg wrote:
> > Factor out connector creation to a small helper function.
> >
> > Signed-off-by: Sam Ravnborg
> > Cc: Peter Senna Tschudin
> > Cc: Martin Donnelly
> > Cc: Martyn Welch
> > Cc: Andrzej Hajda
> > Cc: Neil Armstrong
> > Cc: Laurent Pinchart
> > Cc: Jonas Karlman
> > Cc: Jernej Skrabec
> > ---
> > .../bridge/megachips-stdp-ge-b850v3-fw.c | 47 +++
> > 1 file changed, 27 insertions(+), 20 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c
> > b/drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c
> > index 6200f12a37e6..258e0525cdcc 100644
> > --- a/drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c
> > +++ b/drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c
> > @@ -191,6 +191,32 @@ static const struct drm_connector_funcs
> > ge_b850v3_lvds_connector_funcs = {
> > .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
> > };
> >
> > +static int ge_b850v3_lvds_create_connector(struct drm_bridge *bridge)
> > +{
> > + struct drm_connector *connector = &ge_b850v3_lvds_ptr->connector;
>
> Wow, storing device state in a global variable... :-( How did this go
> past review ?
Took a short look at eliminating this.
But there are two module entries involved so I droppet it again.
>
> Reviewed-by: Laurent Pinchart
>
> > + int ret;
> > +
> > + if (!bridge->encoder) {
> > + DRM_ERROR("Parent encoder object not found");
> > + return -ENODEV;
> > + }
> > +
> > + connector->polled = DRM_CONNECTOR_POLL_HPD;
> > +
> > + drm_connector_helper_add(connector,
> > +&ge_b850v3_lvds_connector_helper_funcs);
> > +
> > + ret = drm_connector_init(bridge->dev, connector,
> > +&ge_b850v3_lvds_connector_funcs,
> > +DRM_MODE_CONNECTOR_DisplayPort);
> > + if (ret) {
> > + DRM_ERROR("Failed to initialize connector with drm\n");
> > + return ret;
> > + }
> > +
> > + return drm_connector_attach_encoder(connector, bridge->encoder);
> > +}
> > +
> > static irqreturn_t ge_b850v3_lvds_irq_handler(int irq, void *dev_id)
> > {
> > struct i2c_client *stdp4028_i2c
> > @@ -209,7 +235,6 @@ static irqreturn_t ge_b850v3_lvds_irq_handler(int irq,
> > void *dev_id)
> > static int ge_b850v3_lvds_attach(struct drm_bridge *bridge,
> > enum drm_bridge_attach_flags flags)
> > {
> > - struct drm_connector *connector = &ge_b850v3_lvds_ptr->connector;
> > struct i2c_client *stdp4028_i2c
> > = ge_b850v3_lvds_ptr->stdp4028_i2c;
> > int ret;
> > @@ -219,25 +244,7 @@ static int ge_b850v3_lvds_attach(struct drm_bridge
> > *bridge,
> > return -EINVAL;
> > }
> >
> > - if (!bridge->encoder) {
> > - DRM_ERROR("Parent encoder object not found");
> > - return -ENODEV;
> > - }
> > -
> > - connector->polled = DRM_CONNECTOR_POLL_HPD;
> > -
> > - drm_connector_helper_add(connector,
> > -&ge_b850v3_lvds_connector_helper_funcs);
> > -
> > - ret = drm_connector_init(bridge->dev, connector,
> > -&ge_b850v3_lvds_connector_funcs,
> > -DRM_MODE_CONNECTOR_DisplayPort);
> > - if (ret) {
> > - DRM_ERROR("Failed to initialize connector with drm\n");
> > - return ret;
> > - }
> > -
> > - ret = drm_connector_attach_encoder(connector, bridge->encoder);
> > + ret = ge_b850v3_lvds_create_connector(bridge);
> > if (ret)
> > return ret;
> >
>
> --
> Regards,
>
> Laurent Pinchart
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 09/15] drm/bridge: megachips: add helper to create connector
Factor out connector creation to a small helper function.
Signed-off-by: Sam Ravnborg
Reviewed-by: Laurent Pinchart
Cc: Peter Senna Tschudin
Cc: Martin Donnelly
Cc: Martyn Welch
Cc: Andrzej Hajda
Cc: Neil Armstrong
Cc: Laurent Pinchart
Cc: Jonas Karlman
Cc: Jernej Skrabec
---
.../bridge/megachips-stdp-ge-b850v3-fw.c | 47 +++
1 file changed, 27 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c
b/drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c
index 6200f12a37e6..258e0525cdcc 100644
--- a/drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c
+++ b/drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c
@@ -191,6 +191,32 @@ static const struct drm_connector_funcs
ge_b850v3_lvds_connector_funcs = {
.atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
};
+static int ge_b850v3_lvds_create_connector(struct drm_bridge *bridge)
+{
+ struct drm_connector *connector = &ge_b850v3_lvds_ptr->connector;
+ int ret;
+
+ if (!bridge->encoder) {
+ DRM_ERROR("Parent encoder object not found");
+ return -ENODEV;
+ }
+
+ connector->polled = DRM_CONNECTOR_POLL_HPD;
+
+ drm_connector_helper_add(connector,
+&ge_b850v3_lvds_connector_helper_funcs);
+
+ ret = drm_connector_init(bridge->dev, connector,
+&ge_b850v3_lvds_connector_funcs,
+DRM_MODE_CONNECTOR_DisplayPort);
+ if (ret) {
+ DRM_ERROR("Failed to initialize connector with drm\n");
+ return ret;
+ }
+
+ return drm_connector_attach_encoder(connector, bridge->encoder);
+}
+
static irqreturn_t ge_b850v3_lvds_irq_handler(int irq, void *dev_id)
{
struct i2c_client *stdp4028_i2c
@@ -209,7 +235,6 @@ static irqreturn_t ge_b850v3_lvds_irq_handler(int irq, void
*dev_id)
static int ge_b850v3_lvds_attach(struct drm_bridge *bridge,
enum drm_bridge_attach_flags flags)
{
- struct drm_connector *connector = &ge_b850v3_lvds_ptr->connector;
struct i2c_client *stdp4028_i2c
= ge_b850v3_lvds_ptr->stdp4028_i2c;
int ret;
@@ -219,25 +244,7 @@ static int ge_b850v3_lvds_attach(struct drm_bridge *bridge,
return -EINVAL;
}
- if (!bridge->encoder) {
- DRM_ERROR("Parent encoder object not found");
- return -ENODEV;
- }
-
- connector->polled = DRM_CONNECTOR_POLL_HPD;
-
- drm_connector_helper_add(connector,
-&ge_b850v3_lvds_connector_helper_funcs);
-
- ret = drm_connector_init(bridge->dev, connector,
-&ge_b850v3_lvds_connector_funcs,
-DRM_MODE_CONNECTOR_DisplayPort);
- if (ret) {
- DRM_ERROR("Failed to initialize connector with drm\n");
- return ret;
- }
-
- ret = drm_connector_attach_encoder(connector, bridge->encoder);
+ ret = ge_b850v3_lvds_create_connector(bridge);
if (ret)
return ret;
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 07/15] drm/bridge: tc358767: add drm_panel_bridge support
With the bridge operations implemented the last step to prepare
this driver for a chained setup is the use of the bridge panel driver.
The bridge panel driver is only used when a prot@2 is present in
the DT. So when the display driver request a connector
support both situations:
- connector created by bridge panel driver
- connector created by this driver
And on top, support that the display driver creates the connector,
which is the preferred setup.
Note: the bridge panel will use the connector type from the panel.
v2:
- Merge connector and drm_panel_bridge patches
and fix so we do not create two connectors (Laurent)
Signed-off-by: Sam Ravnborg
Cc: Laurent Pinchart
Cc: Andrzej Hajda
Cc: Neil Armstrong
Cc: Jonas Karlman
Cc: Jernej Skrabec
---
drivers/gpu/drm/bridge/tc358767.c | 70 +++
1 file changed, 35 insertions(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/bridge/tc358767.c
b/drivers/gpu/drm/bridge/tc358767.c
index d86d7f06bebb..75a2cd792ccc 100644
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -244,8 +244,8 @@ struct tc_data {
struct drm_dp_aux aux;
struct drm_bridge bridge;
+ struct drm_bridge *panel_bridge;
struct drm_connectorconnector;
- struct drm_panel*panel;
/* link settings */
struct tc_edp_link link;
@@ -1234,13 +1234,6 @@ static int tc_stream_disable(struct tc_data *tc)
return 0;
}
-static void tc_bridge_pre_enable(struct drm_bridge *bridge)
-{
- struct tc_data *tc = bridge_to_tc(bridge);
-
- drm_panel_prepare(tc->panel);
-}
-
static void tc_bridge_enable(struct drm_bridge *bridge)
{
struct tc_data *tc = bridge_to_tc(bridge);
@@ -1264,8 +1257,6 @@ static void tc_bridge_enable(struct drm_bridge *bridge)
tc_main_link_disable(tc);
return;
}
-
- drm_panel_enable(tc->panel);
}
static void tc_bridge_disable(struct drm_bridge *bridge)
@@ -1273,8 +1264,6 @@ static void tc_bridge_disable(struct drm_bridge *bridge)
struct tc_data *tc = bridge_to_tc(bridge);
int ret;
- drm_panel_disable(tc->panel);
-
ret = tc_stream_disable(tc);
if (ret < 0)
dev_err(tc->dev, "main link stream stop error: %d\n", ret);
@@ -1284,13 +1273,6 @@ static void tc_bridge_disable(struct drm_bridge *bridge)
dev_err(tc->dev, "main link disable error: %d\n", ret);
}
-static void tc_bridge_post_disable(struct drm_bridge *bridge)
-{
- struct tc_data *tc = bridge_to_tc(bridge);
-
- drm_panel_unprepare(tc->panel);
-}
-
static bool tc_bridge_mode_fixup(struct drm_bridge *bridge,
const struct drm_display_mode *mode,
struct drm_display_mode *adj)
@@ -1354,9 +1336,11 @@ static int tc_connector_get_modes(struct drm_connector
*connector)
return 0;
}
- num_modes = drm_panel_get_modes(tc->panel, connector);
- if (num_modes > 0)
- return num_modes;
+ if (tc->panel_bridge) {
+ num_modes = drm_bridge_get_modes(tc->panel_bridge, connector);
+ if (num_modes > 0)
+ return num_modes;
+ }
edid = tc_get_edid(&tc->bridge, connector);
num_modes = drm_add_edid_modes(connector, edid);
@@ -1396,7 +1380,7 @@ tc_connector_detect(struct drm_connector *connector, bool
force)
if (tc->hpd_pin >= 0)
return tc_bridge_detect(&tc->bridge);
else
- if (tc->panel)
+ if (tc->panel_bridge)
return connector_status_connected;
return connector_status_unknown;
@@ -1419,16 +1403,23 @@ static int tc_bridge_attach(struct drm_bridge *bridge,
struct drm_device *drm = bridge->dev;
int ret;
- if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR) {
- DRM_ERROR("Fix bridge driver to make connector optional!");
- return -EINVAL;
+ if (tc->panel_bridge) {
+ enum drm_bridge_attach_flags panel_flags;
+
+ /* If a connector is required then this driver shall create it
*/
+ panel_flags = flags & ~DRM_BRIDGE_ATTACH_NO_CONNECTOR;
+ ret = drm_bridge_attach(tc->bridge.encoder, tc->panel_bridge,
+ &tc->bridge, panel_flags);
+ if (ret)
+ return ret;
}
+ if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR)
+ return 0;
+
/* Create DP/eDP connector */
drm_connector_helper_add(&tc->connector, &tc_connector_helper_funcs);
- ret = drm_connector_init(drm, &tc->connector, &tc_connector_funcs,
-tc->panel ? DRM_MODE_CONNECTOR_eDP :
-DRM_MODE_CONNECTOR_DisplayPort);
+ ret = drm_connector_init
[PATCH v4 12/15] drm/bridge: megachips: add get_edid bridge operation
To prepare for a chained bridge setup add support for the
get_edid bridge operation.
There is no need for a copy of the edid - so drop
the pointer to the copy.
v2:
- Fix so we do not leak memory (Laurent)
Signed-off-by: Sam Ravnborg
Cc: Peter Senna Tschudin
Cc: Martin Donnelly
Cc: Martyn Welch
Cc: Andrzej Hajda
Cc: Neil Armstrong
Cc: Laurent Pinchart
Cc: Jonas Karlman
Cc: Jernej Skrabec
---
.../bridge/megachips-stdp-ge-b850v3-fw.c | 31 ++-
1 file changed, 17 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c
b/drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c
index 450dca33ea48..f7b55dc374ac 100644
--- a/drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c
+++ b/drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c
@@ -61,7 +61,6 @@ struct ge_b850v3_lvds {
struct drm_bridge bridge;
struct i2c_client *stdp4028_i2c;
struct i2c_client *stdp2690_i2c;
- struct edid *edid;
};
static struct ge_b850v3_lvds *ge_b850v3_lvds_ptr;
@@ -131,22 +130,26 @@ static u8 *stdp2690_get_edid(struct i2c_client *client)
return NULL;
}
-static int ge_b850v3_lvds_get_modes(struct drm_connector *connector)
+static struct edid *ge_b850v3_lvds_get_edid(struct drm_bridge *bridge,
+ struct drm_connector *connector)
{
struct i2c_client *client;
- int num_modes = 0;
client = ge_b850v3_lvds_ptr->stdp2690_i2c;
- kfree(ge_b850v3_lvds_ptr->edid);
- ge_b850v3_lvds_ptr->edid = (struct edid *)stdp2690_get_edid(client);
+ return (struct edid *)stdp2690_get_edid(client);
+}
- if (ge_b850v3_lvds_ptr->edid) {
- drm_connector_update_edid_property(connector,
- ge_b850v3_lvds_ptr->edid);
- num_modes = drm_add_edid_modes(connector,
- ge_b850v3_lvds_ptr->edid);
- }
+static int ge_b850v3_lvds_get_modes(struct drm_connector *connector)
+{
+ struct edid *edid;
+ int num_modes;
+
+ edid = ge_b850v3_lvds_get_edid(&ge_b850v3_lvds_ptr->bridge, connector);
+
+ drm_connector_update_edid_property(connector, edid);
+ num_modes = drm_add_edid_modes(connector, edid);
+ kfree(edid);
return num_modes;
}
@@ -269,6 +272,7 @@ static int ge_b850v3_lvds_attach(struct drm_bridge *bridge,
static const struct drm_bridge_funcs ge_b850v3_lvds_funcs = {
.attach = ge_b850v3_lvds_attach,
.detect = ge_b850v3_lvds_bridge_detect,
+ .get_edid = ge_b850v3_lvds_get_edid,
};
static int ge_b850v3_lvds_init(struct device *dev)
@@ -304,8 +308,6 @@ static void ge_b850v3_lvds_remove(void)
drm_bridge_remove(&ge_b850v3_lvds_ptr->bridge);
- kfree(ge_b850v3_lvds_ptr->edid);
-
ge_b850v3_lvds_ptr = NULL;
out:
mutex_unlock(&ge_b850v3_lvds_dev_mutex);
@@ -323,7 +325,8 @@ static int stdp4028_ge_b850v3_fw_probe(struct i2c_client
*stdp4028_i2c,
/* drm bridge initialization */
ge_b850v3_lvds_ptr->bridge.funcs = &ge_b850v3_lvds_funcs;
- ge_b850v3_lvds_ptr->bridge.ops = DRM_BRIDGE_OP_DETECT;
+ ge_b850v3_lvds_ptr->bridge.ops = DRM_BRIDGE_OP_DETECT |
+DRM_BRIDGE_OP_EDID;
ge_b850v3_lvds_ptr->bridge.of_node = dev->of_node;
drm_bridge_add(&ge_b850v3_lvds_ptr->bridge);
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 0/15] drm/bridge: support chained bridges + panel updates
The objective is that all bridge drivers shall support a chained setup connector creation is moved to the display drivers. This is just one step on this path. The general approach for the bridge drivers: - Introduce bridge operations - Introduce use of panel bridge and make connector creation optional v4: - Dropped patch for ti-sn65dsi86. Await full conversion. - Dropped patch for ti-tpd12s015. It was wrong (Laurent) - Drop boe,hv070wsa-100 patch, it was applied - Combined a few patches to fix connector created twice (Laurent) - Fix memory leak in get_edid in several drivers (Laurent) - Added patch to validate panel descriptions in panel-simple - Set bridge.type in relevant drivers v3: - Rebase on top of drm-misc-next - Address kbuild test robot feedback v2: - Updated bus_flags for boe,hv070wsa-100 - Collected r-b, but did not apply patches yet - On the panel side the panel-simple driver gained a default connector type for all the dumb panels that do not include so in their description. With this change panels always provide a connector type, and we have the potential to drop most uses of devm_drm_panel_bridge_add_typed(). - Added conversion of a few more bridge drivers Patches can build but no run-time testing. So both test and review feedback appreciated! Sam Sam Ravnborg (15): drm/panel: panel-simple: validate panel description drm/panel: panel-simple: add default connector_type drm/bridge: tc358764: drop drm_connector_(un)register drm/bridge: tc358764: add drm_panel_bridge support drm/bridge: tc358767: add detect bridge operation drm/bridge: tc358767: add get_edid bridge operation drm/bridge: tc358767: add drm_panel_bridge support drm/bridge: parade-ps8622: add drm_panel_bridge support drm/bridge: megachips: add helper to create connector drm/bridge: megachips: get drm_device from bridge drm/bridge: megachips: enable detect bridge operation drm/bridge: megachips: add get_edid bridge operation drm/bridge: megachips: make connector creation optional drm/bridge: nxp-ptn3460: add get_edid bridge operation drm/bridge: nxp-ptn3460: add drm_panel_bridge support .../drm/bridge/megachips-stdp-ge-b850v3-fw.c | 97 +--- drivers/gpu/drm/bridge/nxp-ptn3460.c | 103 - drivers/gpu/drm/bridge/parade-ps8622.c | 100 +++- drivers/gpu/drm/bridge/tc358764.c | 110 +++--- drivers/gpu/drm/bridge/tc358767.c | 126 +++-- drivers/gpu/drm/panel/panel-simple.c | 48 +++- 6 files changed, 242 insertions(+), 342 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 06/15] drm/bridge: tc358767: add get_edid bridge operation
Prepare for chained bridge with the addition of
get_edid support.
v2:
- Fixed handling of edid storage (Laurent)
Signed-off-by: Sam Ravnborg
Cc: Andrzej Hajda
Cc: Neil Armstrong
Cc: Laurent Pinchart
Cc: Jonas Karlman
Cc: Jernej Skrabec
---
drivers/gpu/drm/bridge/tc358767.c | 34 ---
1 file changed, 18 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/bridge/tc358767.c
b/drivers/gpu/drm/bridge/tc358767.c
index e8ba713bedac..d86d7f06bebb 100644
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -250,8 +250,6 @@ struct tc_data {
/* link settings */
struct tc_edp_link link;
- /* display edid */
- struct edid *edid;
/* current mode */
struct drm_display_mode mode;
@@ -1335,11 +1333,19 @@ static void tc_bridge_mode_set(struct drm_bridge
*bridge,
tc->mode = *mode;
}
+static struct edid *tc_get_edid(struct drm_bridge *bridge,
+ struct drm_connector *connector)
+{
+ struct tc_data *tc = bridge_to_tc(bridge);
+
+ return drm_get_edid(connector, &tc->aux.ddc);
+}
+
static int tc_connector_get_modes(struct drm_connector *connector)
{
struct tc_data *tc = connector_to_tc(connector);
+ int num_modes;
struct edid *edid;
- int count;
int ret;
ret = tc_get_display_props(tc);
@@ -1348,21 +1354,15 @@ static int tc_connector_get_modes(struct drm_connector
*connector)
return 0;
}
- count = drm_panel_get_modes(tc->panel, connector);
- if (count > 0)
- return count;
-
- edid = drm_get_edid(connector, &tc->aux.ddc);
-
- kfree(tc->edid);
- tc->edid = edid;
- if (!edid)
- return 0;
+ num_modes = drm_panel_get_modes(tc->panel, connector);
+ if (num_modes > 0)
+ return num_modes;
- drm_connector_update_edid_property(connector, edid);
- count = drm_add_edid_modes(connector, edid);
+ edid = tc_get_edid(&tc->bridge, connector);
+ num_modes = drm_add_edid_modes(connector, edid);
+ kfree(edid);
- return count;
+ return num_modes;
}
static const struct drm_connector_helper_funcs tc_connector_helper_funcs = {
@@ -1465,6 +1465,7 @@ static const struct drm_bridge_funcs tc_bridge_funcs = {
.post_disable = tc_bridge_post_disable,
.mode_fixup = tc_bridge_mode_fixup,
.detect = tc_bridge_detect,
+ .get_edid = tc_get_edid,
};
static bool tc_readable_reg(struct device *dev, unsigned int reg)
@@ -1689,6 +1690,7 @@ static int tc_probe(struct i2c_client *client, const
struct i2c_device_id *id)
tc->bridge.funcs = &tc_bridge_funcs;
if (tc->hpd_pin >= 0)
tc->bridge.ops |= DRM_BRIDGE_OP_DETECT;
+ tc->bridge.ops |= DRM_BRIDGE_OP_EDID;
tc->bridge.of_node = dev->of_node;
drm_bridge_add(&tc->bridge);
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 14/15] drm/bridge: nxp-ptn3460: add get_edid bridge operation
Add the get_edid() bridge operation to prepare for
use as a chained bridge.
Add helper function that is also used by the connector.
v2:
- Fix memory leak (Laurent)
- Do not save a copy of edid, read it when needed
Signed-off-by: Sam Ravnborg
Cc: Andrzej Hajda
Cc: Neil Armstrong
Cc: Laurent Pinchart
Cc: Jonas Karlman
Cc: Jernej Skrabec
---
drivers/gpu/drm/bridge/nxp-ptn3460.c | 43
1 file changed, 25 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/bridge/nxp-ptn3460.c
b/drivers/gpu/drm/bridge/nxp-ptn3460.c
index 438e566ce0a4..2805c8938f98 100644
--- a/drivers/gpu/drm/bridge/nxp-ptn3460.c
+++ b/drivers/gpu/drm/bridge/nxp-ptn3460.c
@@ -29,7 +29,6 @@ struct ptn3460_bridge {
struct drm_connector connector;
struct i2c_client *client;
struct drm_bridge bridge;
- struct edid *edid;
struct drm_panel *panel;
struct gpio_desc *gpio_pd_n;
struct gpio_desc *gpio_rst_n;
@@ -184,17 +183,13 @@ static void ptn3460_post_disable(struct drm_bridge
*bridge)
}
}
-static int ptn3460_get_modes(struct drm_connector *connector)
+static struct edid *ptn3460_get_edid(struct drm_bridge *bridge,
+struct drm_connector *connector)
{
- struct ptn3460_bridge *ptn_bridge;
- u8 *edid;
- int ret, num_modes = 0;
+ struct ptn3460_bridge *ptn_bridge = bridge_to_ptn3460(bridge);
bool power_off;
-
- ptn_bridge = connector_to_ptn3460(connector);
-
- if (ptn_bridge->edid)
- return drm_add_edid_modes(connector, ptn_bridge->edid);
+ u8 *edid;
+ int ret;
power_off = !ptn_bridge->enabled;
ptn3460_pre_enable(&ptn_bridge->bridge);
@@ -202,30 +197,40 @@ static int ptn3460_get_modes(struct drm_connector
*connector)
edid = kmalloc(EDID_LENGTH, GFP_KERNEL);
if (!edid) {
DRM_ERROR("Failed to allocate EDID\n");
- return 0;
+ goto out;
}
ret = ptn3460_read_bytes(ptn_bridge, PTN3460_EDID_ADDR, edid,
- EDID_LENGTH);
+EDID_LENGTH);
if (ret) {
kfree(edid);
+ edid = NULL;
goto out;
}
- ptn_bridge->edid = (struct edid *)edid;
- drm_connector_update_edid_property(connector, ptn_bridge->edid);
-
- num_modes = drm_add_edid_modes(connector, ptn_bridge->edid);
-
out:
if (power_off)
ptn3460_disable(&ptn_bridge->bridge);
+ return (struct edid *)edid;
+}
+
+static int ptn3460_connector_get_modes(struct drm_connector *connector)
+{
+ struct ptn3460_bridge *ptn_bridge = connector_to_ptn3460(connector);
+ struct edid *edid;
+ int num_modes;
+
+ edid = ptn3460_get_edid(&ptn_bridge->bridge, connector);
+ drm_connector_update_edid_property(connector, edid);
+ num_modes = drm_add_edid_modes(connector, edid);
+ kfree(edid);
+
return num_modes;
}
static const struct drm_connector_helper_funcs ptn3460_connector_helper_funcs
= {
- .get_modes = ptn3460_get_modes,
+ .get_modes = ptn3460_connector_get_modes,
};
static const struct drm_connector_funcs ptn3460_connector_funcs = {
@@ -279,6 +284,7 @@ static const struct drm_bridge_funcs ptn3460_bridge_funcs =
{
.disable = ptn3460_disable,
.post_disable = ptn3460_post_disable,
.attach = ptn3460_bridge_attach,
+ .get_edid = ptn3460_get_edid,
};
static int ptn3460_probe(struct i2c_client *client,
@@ -327,6 +333,7 @@ static int ptn3460_probe(struct i2c_client *client,
}
ptn_bridge->bridge.funcs = &ptn3460_bridge_funcs;
+ ptn_bridge->bridge.ops = DRM_BRIDGE_OP_EDID;
ptn_bridge->bridge.of_node = dev->of_node;
drm_bridge_add(&ptn_bridge->bridge);
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 10/15] drm/bridge: megachips: get drm_device from bridge
Fix so drm_device is read from the bridge. This is a preparation for the connector being optional. Signed-off-by: Sam Ravnborg Reviewed-by: Laurent Pinchart Cc: Peter Senna Tschudin Cc: Martin Donnelly Cc: Martyn Welch Cc: Andrzej Hajda Cc: Neil Armstrong Cc: Laurent Pinchart Cc: Jonas Karlman Cc: Jernej Skrabec --- drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c b/drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c index 258e0525cdcc..cf1dfbc88acf 100644 --- a/drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c +++ b/drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c @@ -226,8 +226,8 @@ static irqreturn_t ge_b850v3_lvds_irq_handler(int irq, void *dev_id) STDP4028_DPTX_IRQ_STS_REG, STDP4028_DPTX_IRQ_CLEAR); - if (ge_b850v3_lvds_ptr->connector.dev) - drm_kms_helper_hotplug_event(ge_b850v3_lvds_ptr->connector.dev); + if (ge_b850v3_lvds_ptr->bridge.dev) + drm_kms_helper_hotplug_event(ge_b850v3_lvds_ptr->bridge.dev); return IRQ_HANDLED; } -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 13/15] drm/bridge: megachips: make connector creation optional
Make the connector creation optional to enable usage of the
megachips-stdp-ge-b850v3-fw bridge with the DRM bridge connector
helper.
v2:
- Set bridge.type to DRM_MODE_CONNECTOR_DisplayPort
Signed-off-by: Sam Ravnborg
Cc: Peter Senna Tschudin
Cc: Martin Donnelly
Cc: Martyn Welch
Cc: Andrzej Hajda
Cc: Neil Armstrong
Cc: Laurent Pinchart
Cc: Jonas Karlman
Cc: Jernej Skrabec
---
.../drm/bridge/megachips-stdp-ge-b850v3-fw.c | 16 +---
1 file changed, 5 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c
b/drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c
index f7b55dc374ac..61a24f265c7a 100644
--- a/drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c
+++ b/drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c
@@ -245,16 +245,6 @@ static int ge_b850v3_lvds_attach(struct drm_bridge *bridge,
{
struct i2c_client *stdp4028_i2c
= ge_b850v3_lvds_ptr->stdp4028_i2c;
- int ret;
-
- if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR) {
- DRM_ERROR("Fix bridge driver to make connector optional!");
- return -EINVAL;
- }
-
- ret = ge_b850v3_lvds_create_connector(bridge);
- if (ret)
- return ret;
/* Configures the bridge to re-enable interrupts after each ack. */
i2c_smbus_write_word_data(stdp4028_i2c,
@@ -266,7 +256,10 @@ static int ge_b850v3_lvds_attach(struct drm_bridge *bridge,
STDP4028_DPTX_IRQ_EN_REG,
STDP4028_DPTX_IRQ_CONFIG);
- return 0;
+ if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR)
+ return 0;
+
+ return ge_b850v3_lvds_create_connector(bridge);
}
static const struct drm_bridge_funcs ge_b850v3_lvds_funcs = {
@@ -327,6 +320,7 @@ static int stdp4028_ge_b850v3_fw_probe(struct i2c_client
*stdp4028_i2c,
ge_b850v3_lvds_ptr->bridge.funcs = &ge_b850v3_lvds_funcs;
ge_b850v3_lvds_ptr->bridge.ops = DRM_BRIDGE_OP_DETECT |
DRM_BRIDGE_OP_EDID;
+ ge_b850v3_lvds_ptr->bridge.type = DRM_MODE_CONNECTOR_DisplayPort;
ge_b850v3_lvds_ptr->bridge.of_node = dev->of_node;
drm_bridge_add(&ge_b850v3_lvds_ptr->bridge);
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 03/15] drm/bridge: tc358764: drop drm_connector_(un)register
Drop drm_connector handling that is not needed:
- drm_dev_register() in the display controller driver takes
care of registering connectors.
So the call to drm_connector_register() call is not needed in the bridge
driver.
- Use of drm_connector_unregister() is only required for drivers that
explicit have called drm_dev_register.
- The reference counting using drm_connector_put() is likewise not needed.
Signed-off-by: Sam Ravnborg
Reviewed-by: Laurent Pinchart
Cc: Andrzej Hajda
Cc: Neil Armstrong
Cc: Laurent Pinchart
Cc: Jonas Karlman
Cc: Jernej Skrabec
---
drivers/gpu/drm/bridge/tc358764.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/bridge/tc358764.c
b/drivers/gpu/drm/bridge/tc358764.c
index 5ac1430fab04..a277739fab58 100644
--- a/drivers/gpu/drm/bridge/tc358764.c
+++ b/drivers/gpu/drm/bridge/tc358764.c
@@ -375,7 +375,6 @@ static int tc358764_attach(struct drm_bridge *bridge,
drm_connector_attach_encoder(&ctx->connector, bridge->encoder);
drm_panel_attach(ctx->panel, &ctx->connector);
ctx->connector.funcs->reset(&ctx->connector);
- drm_connector_register(&ctx->connector);
return 0;
}
@@ -384,10 +383,8 @@ static void tc358764_detach(struct drm_bridge *bridge)
{
struct tc358764 *ctx = bridge_to_tc358764(bridge);
- drm_connector_unregister(&ctx->connector);
drm_panel_detach(ctx->panel);
ctx->panel = NULL;
- drm_connector_put(&ctx->connector);
}
static const struct drm_bridge_funcs tc358764_bridge_funcs = {
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 04/15] drm/bridge: tc358764: add drm_panel_bridge support
Prepare the tc358764 bridge driver for use in a chained setup by
replacing direct use of drm_panel with drm_panel_bridge support.
The bridge panel will use the connector type reported by the panel,
where the connector for this driver hardcodes DRM_MODE_CONNECTOR_LVDS.
The tc358764 did not any additional info the the connector so the
connector creation is passed to the bridge panel driver.
v3:
- Merge with patch to make connector creation optional to avoid
creating two connectors (Laurent)
- Pass connector creation to bridge panel, as this bridge driver
did not add any extra info to the connector.
- Set bridge.type to DRM_MODE_CONNECTOR_LVDS.
v2:
- Use PTR_ERR_OR_ZERO() (kbuild test robot)
Signed-off-by: Sam Ravnborg
Cc: Laurent Pinchart
Cc: kbuild test robot
Cc: Andrzej Hajda
Cc: Neil Armstrong
Cc: Jonas Karlman
Cc: Jernej Skrabec
---
drivers/gpu/drm/bridge/tc358764.c | 107 +-
1 file changed, 16 insertions(+), 91 deletions(-)
diff --git a/drivers/gpu/drm/bridge/tc358764.c
b/drivers/gpu/drm/bridge/tc358764.c
index a277739fab58..fdde4cfdc724 100644
--- a/drivers/gpu/drm/bridge/tc358764.c
+++ b/drivers/gpu/drm/bridge/tc358764.c
@@ -153,10 +153,9 @@ static const char * const tc358764_supplies[] = {
struct tc358764 {
struct device *dev;
struct drm_bridge bridge;
- struct drm_connector connector;
struct regulator_bulk_data supplies[ARRAY_SIZE(tc358764_supplies)];
struct gpio_desc *gpio_reset;
- struct drm_panel *panel;
+ struct drm_bridge *panel_bridge;
int error;
};
@@ -210,12 +209,6 @@ static inline struct tc358764 *bridge_to_tc358764(struct
drm_bridge *bridge)
return container_of(bridge, struct tc358764, bridge);
}
-static inline
-struct tc358764 *connector_to_tc358764(struct drm_connector *connector)
-{
- return container_of(connector, struct tc358764, connector);
-}
-
static int tc358764_init(struct tc358764 *ctx)
{
u32 v = 0;
@@ -278,43 +271,11 @@ static void tc358764_reset(struct tc358764 *ctx)
usleep_range(1000, 2000);
}
-static int tc358764_get_modes(struct drm_connector *connector)
-{
- struct tc358764 *ctx = connector_to_tc358764(connector);
-
- return drm_panel_get_modes(ctx->panel, connector);
-}
-
-static const
-struct drm_connector_helper_funcs tc358764_connector_helper_funcs = {
- .get_modes = tc358764_get_modes,
-};
-
-static const struct drm_connector_funcs tc358764_connector_funcs = {
- .fill_modes = drm_helper_probe_single_connector_modes,
- .destroy = drm_connector_cleanup,
- .reset = drm_atomic_helper_connector_reset,
- .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
- .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
-};
-
-static void tc358764_disable(struct drm_bridge *bridge)
-{
- struct tc358764 *ctx = bridge_to_tc358764(bridge);
- int ret = drm_panel_disable(bridge_to_tc358764(bridge)->panel);
-
- if (ret < 0)
- dev_err(ctx->dev, "error disabling panel (%d)\n", ret);
-}
-
static void tc358764_post_disable(struct drm_bridge *bridge)
{
struct tc358764 *ctx = bridge_to_tc358764(bridge);
int ret;
- ret = drm_panel_unprepare(ctx->panel);
- if (ret < 0)
- dev_err(ctx->dev, "error unpreparing panel (%d)\n", ret);
tc358764_reset(ctx);
usleep_range(1, 15000);
ret = regulator_bulk_disable(ARRAY_SIZE(ctx->supplies), ctx->supplies);
@@ -335,70 +296,28 @@ static void tc358764_pre_enable(struct drm_bridge *bridge)
ret = tc358764_init(ctx);
if (ret < 0)
dev_err(ctx->dev, "error initializing bridge (%d)\n", ret);
- ret = drm_panel_prepare(ctx->panel);
- if (ret < 0)
- dev_err(ctx->dev, "error preparing panel (%d)\n", ret);
-}
-
-static void tc358764_enable(struct drm_bridge *bridge)
-{
- struct tc358764 *ctx = bridge_to_tc358764(bridge);
- int ret = drm_panel_enable(ctx->panel);
-
- if (ret < 0)
- dev_err(ctx->dev, "error enabling panel (%d)\n", ret);
}
static int tc358764_attach(struct drm_bridge *bridge,
enum drm_bridge_attach_flags flags)
-{
- struct tc358764 *ctx = bridge_to_tc358764(bridge);
- struct drm_device *drm = bridge->dev;
- int ret;
-
- if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR) {
- DRM_ERROR("Fix bridge driver to make connector optional!");
- return -EINVAL;
- }
-
- ctx->connector.polled = DRM_CONNECTOR_POLL_HPD;
- ret = drm_connector_init(drm, &ctx->connector,
-&tc358764_connector_funcs,
-DRM_MODE_CONNECTOR_LVDS);
- if (ret) {
- DRM_ERROR("Failed to initialize connector\n");
- return ret;
- }
-
- drm_connector_helper_add(&ctx->connector,
-
[PATCH v4 08/15] drm/bridge: parade-ps8622: add drm_panel_bridge support
Prepare the bridge driver for use in a chained setup by
replacing direct use of drm_panel with drm_panel_bridge support.
The connecter is now either created by the panel bridge or the display
driver. So all code for connector creation in this driver is no longer
relevant and thus dropped.
The connector code had some special polling handling:
connector.polled = DRM_CONNECTOR_POLL_HPD;
drm_helper_hpd_irq_event(ps8622->bridge.dev);
This code was most likely added to speed up detection of the connector.
If really needed then this functionality belongs somewhere else.
Note: the bridge panel will use the connector type from the panel.
v2:
- Fix to avoid creating connector twice (Laurent)
- Drop all connector code - defer to bridge panel
- Use panel_bridge for local variable to align with other drivers
- Set bridge.type to DRM_MODE_CONNECTOR_LVDS;
Signed-off-by: Sam Ravnborg
Cc: Andrzej Hajda
Cc: Neil Armstrong
Cc: Laurent Pinchart
Cc: Jonas Karlman
Cc: Jernej Skrabec
---
drivers/gpu/drm/bridge/parade-ps8622.c | 100 -
1 file changed, 13 insertions(+), 87 deletions(-)
diff --git a/drivers/gpu/drm/bridge/parade-ps8622.c
b/drivers/gpu/drm/bridge/parade-ps8622.c
index d789ea2a7fb9..614b19f0f1b7 100644
--- a/drivers/gpu/drm/bridge/parade-ps8622.c
+++ b/drivers/gpu/drm/bridge/parade-ps8622.c
@@ -42,10 +42,9 @@
#endif
struct ps8622_bridge {
- struct drm_connector connector;
struct i2c_client *client;
struct drm_bridge bridge;
- struct drm_panel *panel;
+ struct drm_bridge *panel_bridge;
struct regulator *v12;
struct backlight_device *bl;
@@ -64,12 +63,6 @@ static inline struct ps8622_bridge *
return container_of(bridge, struct ps8622_bridge, bridge);
}
-static inline struct ps8622_bridge *
- connector_to_ps8622(struct drm_connector *connector)
-{
- return container_of(connector, struct ps8622_bridge, connector);
-}
-
static int ps8622_set(struct i2c_client *client, u8 page, u8 reg, u8 val)
{
int ret;
@@ -365,11 +358,6 @@ static void ps8622_pre_enable(struct drm_bridge *bridge)
DRM_ERROR("fails to enable ps8622->v12");
}
- if (drm_panel_prepare(ps8622->panel)) {
- DRM_ERROR("failed to prepare panel\n");
- return;
- }
-
gpiod_set_value(ps8622->gpio_slp, 1);
/*
@@ -399,24 +387,9 @@ static void ps8622_pre_enable(struct drm_bridge *bridge)
ps8622->enabled = true;
}
-static void ps8622_enable(struct drm_bridge *bridge)
-{
- struct ps8622_bridge *ps8622 = bridge_to_ps8622(bridge);
-
- if (drm_panel_enable(ps8622->panel)) {
- DRM_ERROR("failed to enable panel\n");
- return;
- }
-}
-
static void ps8622_disable(struct drm_bridge *bridge)
{
- struct ps8622_bridge *ps8622 = bridge_to_ps8622(bridge);
-
- if (drm_panel_disable(ps8622->panel)) {
- DRM_ERROR("failed to disable panel\n");
- return;
- }
+ /* Delay after panel is disabled */
msleep(PS8622_PWMO_END_T12_MS);
}
@@ -436,11 +409,6 @@ static void ps8622_post_disable(struct drm_bridge *bridge)
*/
gpiod_set_value(ps8622->gpio_slp, 0);
- if (drm_panel_unprepare(ps8622->panel)) {
- DRM_ERROR("failed to unprepare panel\n");
- return;
- }
-
if (ps8622->v12)
regulator_disable(ps8622->v12);
@@ -455,67 +423,17 @@ static void ps8622_post_disable(struct drm_bridge *bridge)
msleep(PS8622_POWER_OFF_T17_MS);
}
-static int ps8622_get_modes(struct drm_connector *connector)
-{
- struct ps8622_bridge *ps8622;
-
- ps8622 = connector_to_ps8622(connector);
-
- return drm_panel_get_modes(ps8622->panel, connector);
-}
-
-static const struct drm_connector_helper_funcs ps8622_connector_helper_funcs =
{
- .get_modes = ps8622_get_modes,
-};
-
-static const struct drm_connector_funcs ps8622_connector_funcs = {
- .fill_modes = drm_helper_probe_single_connector_modes,
- .destroy = drm_connector_cleanup,
- .reset = drm_atomic_helper_connector_reset,
- .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
- .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
-};
-
static int ps8622_attach(struct drm_bridge *bridge,
enum drm_bridge_attach_flags flags)
{
struct ps8622_bridge *ps8622 = bridge_to_ps8622(bridge);
- int ret;
-
- if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR) {
- DRM_ERROR("Fix bridge driver to make connector optional!");
- return -EINVAL;
- }
- if (!bridge->encoder) {
- DRM_ERROR("Parent encoder object not found");
- return -ENODEV;
- }
-
- ps8622->connector.polled = DRM_CONNECTOR_POLL_HPD;
- ret = drm_connector_init(bridge->dev,
[PATCH v4 02/15] drm/panel: panel-simple: add default connector_type
All panels shall report a connector type.
panel-simple has a lot of panels with no connector_type,
and for these fall back to DPI as the default.
v2:
- Rebased on top of validation of panel description
Signed-off-by: Sam Ravnborg
Cc: Laurent Pinchart
Cc: Thierry Reding
Cc: Sam Ravnborg
---
drivers/gpu/drm/panel/panel-simple.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index a8d68102931e..56ab073e4e6e 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -500,6 +500,7 @@ static int panel_simple_probe(struct device *dev, const
struct panel_desc *desc)
struct panel_simple *panel;
struct display_timing dt;
struct device_node *ddc;
+ int connector_type;
u32 bus_flags;
int err;
@@ -550,10 +551,12 @@ static int panel_simple_probe(struct device *dev, const
struct panel_desc *desc)
panel_simple_parse_panel_timing_node(dev, panel, &dt);
}
+ connector_type = desc->connector_type;
/* Catch common mistakes for panels. */
- switch (desc->connector_type) {
+ switch (connector_type) {
case 0:
dev_warn(dev, "Specify missing connector_type\n");
+ connector_type = DRM_MODE_CONNECTOR_DPI;
break;
case DRM_MODE_CONNECTOR_LVDS:
WARN_ON(desc->bus_flags &
@@ -600,11 +603,11 @@ static int panel_simple_probe(struct device *dev, const
struct panel_desc *desc)
break;
default:
dev_warn(dev, "Specify a valid connector_type: %d\n",
desc->connector_type);
+ connector_type = DRM_MODE_CONNECTOR_DPI;
break;
}
- drm_panel_init(&panel->base, dev, &panel_simple_funcs,
- desc->connector_type);
+ drm_panel_init(&panel->base, dev, &panel_simple_funcs, connector_type);
err = drm_panel_of_backlight(&panel->base);
if (err)
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 11/15] drm/bridge: megachips: enable detect bridge operation
To prepare for use in a chained bridge setup enable the
detect operation.
Signed-off-by: Sam Ravnborg
Reviewed-by: Laurent Pinchart
Cc: Peter Senna Tschudin
Cc: Martin Donnelly
Cc: Martyn Welch
Cc: Andrzej Hajda
Cc: Neil Armstrong
Cc: Laurent Pinchart
Cc: Jonas Karlman
Cc: Jernej Skrabec
---
.../gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c
b/drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c
index cf1dfbc88acf..450dca33ea48 100644
--- a/drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c
+++ b/drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c
@@ -163,8 +163,7 @@ drm_connector_helper_funcs
ge_b850v3_lvds_connector_helper_funcs = {
.mode_valid = ge_b850v3_lvds_mode_valid,
};
-static enum drm_connector_status ge_b850v3_lvds_detect(
- struct drm_connector *connector, bool force)
+static enum drm_connector_status ge_b850v3_lvds_bridge_detect(struct
drm_bridge *bridge)
{
struct i2c_client *stdp4028_i2c =
ge_b850v3_lvds_ptr->stdp4028_i2c;
@@ -182,6 +181,12 @@ static enum drm_connector_status ge_b850v3_lvds_detect(
return connector_status_unknown;
}
+static enum drm_connector_status ge_b850v3_lvds_detect(struct drm_connector
*connector,
+ bool force)
+{
+ return ge_b850v3_lvds_bridge_detect(&ge_b850v3_lvds_ptr->bridge);
+}
+
static const struct drm_connector_funcs ge_b850v3_lvds_connector_funcs = {
.fill_modes = drm_helper_probe_single_connector_modes,
.detect = ge_b850v3_lvds_detect,
@@ -263,6 +268,7 @@ static int ge_b850v3_lvds_attach(struct drm_bridge *bridge,
static const struct drm_bridge_funcs ge_b850v3_lvds_funcs = {
.attach = ge_b850v3_lvds_attach,
+ .detect = ge_b850v3_lvds_bridge_detect,
};
static int ge_b850v3_lvds_init(struct device *dev)
@@ -317,6 +323,7 @@ static int stdp4028_ge_b850v3_fw_probe(struct i2c_client
*stdp4028_i2c,
/* drm bridge initialization */
ge_b850v3_lvds_ptr->bridge.funcs = &ge_b850v3_lvds_funcs;
+ ge_b850v3_lvds_ptr->bridge.ops = DRM_BRIDGE_OP_DETECT;
ge_b850v3_lvds_ptr->bridge.of_node = dev->of_node;
drm_bridge_add(&ge_b850v3_lvds_ptr->bridge);
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 05/15] drm/bridge: tc358767: add detect bridge operation
Prepare the bridge driver for chained operation by adding
support for the detect operation.
v2:
- Do not announce detect operation if there is no hpd pin (Laurent)
Signed-off-by: Sam Ravnborg
Cc: Andrzej Hajda
Cc: Neil Armstrong
Cc: Laurent Pinchart
Cc: Jonas Karlman
Cc: Jernej Skrabec
---
drivers/gpu/drm/bridge/tc358767.c | 30 --
1 file changed, 20 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/bridge/tc358767.c
b/drivers/gpu/drm/bridge/tc358767.c
index c2777b226c75..e8ba713bedac 100644
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -1369,21 +1369,13 @@ static const struct drm_connector_helper_funcs
tc_connector_helper_funcs = {
.get_modes = tc_connector_get_modes,
};
-static enum drm_connector_status tc_connector_detect(struct drm_connector
*connector,
-bool force)
+static enum drm_connector_status tc_bridge_detect(struct drm_bridge *bridge)
{
- struct tc_data *tc = connector_to_tc(connector);
+ struct tc_data *tc = bridge_to_tc(bridge);
bool conn;
u32 val;
int ret;
- if (tc->hpd_pin < 0) {
- if (tc->panel)
- return connector_status_connected;
- else
- return connector_status_unknown;
- }
-
ret = regmap_read(tc->regmap, GPIOI, &val);
if (ret)
return connector_status_unknown;
@@ -1396,6 +1388,20 @@ static enum drm_connector_status
tc_connector_detect(struct drm_connector *conne
return connector_status_disconnected;
}
+static enum drm_connector_status
+tc_connector_detect(struct drm_connector *connector, bool force)
+{
+ struct tc_data *tc = connector_to_tc(connector);
+
+ if (tc->hpd_pin >= 0)
+ return tc_bridge_detect(&tc->bridge);
+ else
+ if (tc->panel)
+ return connector_status_connected;
+
+ return connector_status_unknown;
+}
+
static const struct drm_connector_funcs tc_connector_funcs = {
.detect = tc_connector_detect,
.fill_modes = drm_helper_probe_single_connector_modes,
@@ -1458,6 +1464,7 @@ static const struct drm_bridge_funcs tc_bridge_funcs = {
.disable = tc_bridge_disable,
.post_disable = tc_bridge_post_disable,
.mode_fixup = tc_bridge_mode_fixup,
+ .detect = tc_bridge_detect,
};
static bool tc_readable_reg(struct device *dev, unsigned int reg)
@@ -1680,6 +1687,9 @@ static int tc_probe(struct i2c_client *client, const
struct i2c_device_id *id)
return ret;
tc->bridge.funcs = &tc_bridge_funcs;
+ if (tc->hpd_pin >= 0)
+ tc->bridge.ops |= DRM_BRIDGE_OP_DETECT;
+
tc->bridge.of_node = dev->of_node;
drm_bridge_add(&tc->bridge);
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 15/15] drm/bridge: nxp-ptn3460: add drm_panel_bridge support
Prepare the bridge driver for use in a chained setup.
- Replacing direct use of drm_panel with drm_panel_bridge support.
- Make the connector creation optional
Note: the bridge panel will use the connector type from the panel.
v2:
- Use panel_bridge for local variable name to align with other drivers
- Fix that connector was created twice (Laurent)
- Set bridge.type to DRM_MODE_CONNECTOR_LVDS.
Signed-off-by: Sam Ravnborg
Cc: Andrzej Hajda
Cc: Neil Armstrong
Cc: Laurent Pinchart
Cc: Jonas Karlman
Cc: Jernej Skrabec
---
drivers/gpu/drm/bridge/nxp-ptn3460.c | 60 ++--
1 file changed, 20 insertions(+), 40 deletions(-)
diff --git a/drivers/gpu/drm/bridge/nxp-ptn3460.c
b/drivers/gpu/drm/bridge/nxp-ptn3460.c
index 2805c8938f98..a49616855dd3 100644
--- a/drivers/gpu/drm/bridge/nxp-ptn3460.c
+++ b/drivers/gpu/drm/bridge/nxp-ptn3460.c
@@ -29,7 +29,7 @@ struct ptn3460_bridge {
struct drm_connector connector;
struct i2c_client *client;
struct drm_bridge bridge;
- struct drm_panel *panel;
+ struct drm_bridge *panel_bridge;
struct gpio_desc *gpio_pd_n;
struct gpio_desc *gpio_rst_n;
u32 edid_emulation;
@@ -126,11 +126,6 @@ static void ptn3460_pre_enable(struct drm_bridge *bridge)
usleep_range(10, 20);
gpiod_set_value(ptn_bridge->gpio_rst_n, 1);
- if (drm_panel_prepare(ptn_bridge->panel)) {
- DRM_ERROR("failed to prepare panel\n");
- return;
- }
-
/*
* There's a bug in the PTN chip where it falsely asserts hotplug before
* it is fully functional. We're forced to wait for the maximum start up
@@ -145,16 +140,6 @@ static void ptn3460_pre_enable(struct drm_bridge *bridge)
ptn_bridge->enabled = true;
}
-static void ptn3460_enable(struct drm_bridge *bridge)
-{
- struct ptn3460_bridge *ptn_bridge = bridge_to_ptn3460(bridge);
-
- if (drm_panel_enable(ptn_bridge->panel)) {
- DRM_ERROR("failed to enable panel\n");
- return;
- }
-}
-
static void ptn3460_disable(struct drm_bridge *bridge)
{
struct ptn3460_bridge *ptn_bridge = bridge_to_ptn3460(bridge);
@@ -164,24 +149,10 @@ static void ptn3460_disable(struct drm_bridge *bridge)
ptn_bridge->enabled = false;
- if (drm_panel_disable(ptn_bridge->panel)) {
- DRM_ERROR("failed to disable panel\n");
- return;
- }
-
gpiod_set_value(ptn_bridge->gpio_rst_n, 1);
gpiod_set_value(ptn_bridge->gpio_pd_n, 0);
}
-static void ptn3460_post_disable(struct drm_bridge *bridge)
-{
- struct ptn3460_bridge *ptn_bridge = bridge_to_ptn3460(bridge);
-
- if (drm_panel_unprepare(ptn_bridge->panel)) {
- DRM_ERROR("failed to unprepare panel\n");
- return;
- }
-}
static struct edid *ptn3460_get_edid(struct drm_bridge *bridge,
struct drm_connector *connector)
@@ -245,12 +216,18 @@ static int ptn3460_bridge_attach(struct drm_bridge
*bridge,
enum drm_bridge_attach_flags flags)
{
struct ptn3460_bridge *ptn_bridge = bridge_to_ptn3460(bridge);
+ enum drm_bridge_attach_flags panel_flags;
int ret;
- if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR) {
- DRM_ERROR("Fix bridge driver to make connector optional!");
- return -EINVAL;
- }
+ /* Let this driver create connector if requested */
+ panel_flags = flags & ~DRM_BRIDGE_ATTACH_NO_CONNECTOR;
+ ret = drm_bridge_attach(bridge->encoder, ptn_bridge->panel_bridge,
+ bridge, panel_flags);
+ if (ret < 0)
+ return ret;
+
+ if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR)
+ return 0;
if (!bridge->encoder) {
DRM_ERROR("Parent encoder object not found");
@@ -270,9 +247,6 @@ static int ptn3460_bridge_attach(struct drm_bridge *bridge,
drm_connector_attach_encoder(&ptn_bridge->connector,
bridge->encoder);
- if (ptn_bridge->panel)
- drm_panel_attach(ptn_bridge->panel, &ptn_bridge->connector);
-
drm_helper_hpd_irq_event(ptn_bridge->connector.dev);
return ret;
@@ -280,9 +254,7 @@ static int ptn3460_bridge_attach(struct drm_bridge *bridge,
static const struct drm_bridge_funcs ptn3460_bridge_funcs = {
.pre_enable = ptn3460_pre_enable,
- .enable = ptn3460_enable,
.disable = ptn3460_disable,
- .post_disable = ptn3460_post_disable,
.attach = ptn3460_bridge_attach,
.get_edid = ptn3460_get_edid,
};
@@ -292,6 +264,8 @@ static int ptn3460_probe(struct i2c_client *client,
{
struct device *dev = &client->dev;
struct ptn3460_bridge *ptn_bridge;
+ struct drm_bridge *panel_bridge;
+ struct drm_panel *panel;
int ret;
[PATCH v4 01/15] drm/panel: panel-simple: validate panel description
Warn if we detect a panel with incomplete/wrong description.
This is inspired by a similar patch by Laurent that introduced checks
for LVDS panels - this extends the checks to the remaining type of
connectors.
This is known to warn for some of the existing panels but added
despite this as we need help from people using the panels to
add the missing info.
The checks are not complete but will catch the most common mistakes.
The checks at the same time serves as documentation for the minimum
required description for a panel.
The checks uses dev_warn() as we know this will hit. WARN() was
too noisy at the moment for anything else than LVDS.
v2:
- Use dev_warn (Laurent)
- Check for empty bus_flags
Signed-off-by: Sam Ravnborg
Cc: Laurent Pinchart
Cc: Thierry Reding
Cc: Sam Ravnborg
---
drivers/gpu/drm/panel/panel-simple.c | 41 ++--
1 file changed, 39 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 54323515ca2c..a8d68102931e 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -500,6 +500,7 @@ static int panel_simple_probe(struct device *dev, const
struct panel_desc *desc)
struct panel_simple *panel;
struct display_timing dt;
struct device_node *ddc;
+ u32 bus_flags;
int err;
panel = devm_kzalloc(dev, sizeof(*panel), GFP_KERNEL);
@@ -549,8 +550,12 @@ static int panel_simple_probe(struct device *dev, const
struct panel_desc *desc)
panel_simple_parse_panel_timing_node(dev, panel, &dt);
}
- if (desc->connector_type == DRM_MODE_CONNECTOR_LVDS) {
- /* Catch common mistakes for LVDS panels. */
+ /* Catch common mistakes for panels. */
+ switch (desc->connector_type) {
+ case 0:
+ dev_warn(dev, "Specify missing connector_type\n");
+ break;
+ case DRM_MODE_CONNECTOR_LVDS:
WARN_ON(desc->bus_flags &
~(DRM_BUS_FLAG_DE_LOW |
DRM_BUS_FLAG_DE_HIGH |
@@ -564,6 +569,38 @@ static int panel_simple_probe(struct device *dev, const
struct panel_desc *desc)
WARN_ON((desc->bus_format == MEDIA_BUS_FMT_RGB888_1X7X4_SPWG ||
desc->bus_format == MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA)
&&
desc->bpc != 8);
+ break;
+ case DRM_MODE_CONNECTOR_eDP:
+ if (desc->bus_format == 0)
+ dev_warn(dev, "Specify missing bus_format\n");
+ if (desc->bpc != 6 && desc->bpc != 8)
+ dev_warn(dev, "Expected bpc in {6,8} but got: %d\n",
desc->bpc);
+ break;
+ case DRM_MODE_CONNECTOR_DSI:
+ if (desc->bpc != 6 && desc->bpc != 8)
+ dev_warn(dev, "Expected bpc in {6,8} but got: %d\n",
desc->bpc);
+ break;
+ case DRM_MODE_CONNECTOR_DPI:
+ bus_flags = DRM_BUS_FLAG_DE_LOW |
+ DRM_BUS_FLAG_DE_HIGH |
+ DRM_BUS_FLAG_PIXDATA_SAMPLE_POSEDGE |
+ DRM_BUS_FLAG_PIXDATA_SAMPLE_NEGEDGE |
+ DRM_BUS_FLAG_DATA_MSB_TO_LSB |
+ DRM_BUS_FLAG_DATA_LSB_TO_MSB |
+ DRM_BUS_FLAG_SYNC_SAMPLE_POSEDGE |
+ DRM_BUS_FLAG_SYNC_SAMPLE_NEGEDGE;
+ if (desc->bus_flags & ~bus_flags)
+ dev_warn(dev, "Unexpected bus_flags(%d)\n",
desc->bus_flags & ~bus_flags);
+ if (!(desc->bus_flags & bus_flags))
+ dev_warn(dev, "Specify missing bus_flags\n");
+ if (desc->bus_format == 0)
+ dev_warn(dev, "Specify missing bus_format\n");
+ if (desc->bpc != 6 && desc->bpc != 8)
+ dev_warn(dev, "Expected bpc in {6,8} but got: %d\n",
desc->bpc);
+ break;
+ default:
+ dev_warn(dev, "Specify a valid connector_type: %d\n",
desc->connector_type);
+ break;
}
drm_panel_init(&panel->base, dev, &panel_simple_funcs,
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/bridge: tc358762: Add basic driver for Toshiba TC358762 DSI-to-DPI bridge
Hi Marek. On Sun, Jul 26, 2020 at 12:17:46PM +0200, Marek Vasut wrote: > On 7/26/20 9:15 AM, Sam Ravnborg wrote: > > Hi Marek. > > Hi, > > > On Sat, Jul 25, 2020 at 11:14:57PM +0200, Marek Vasut wrote: > >> Add very basic driver for Toshiba TC358762 DSI-to-DPI bridge, derived > >> from tc358764 driver and panel-raspberrypi-touchscreen. This driver is > >> meant to replace the panel-raspberrypi-touchscreen too, as the bridge > >> connection can be described in DT too. > >> > >> Signed-off-by: Marek Vasut > >> To: dri-devel@lists.freedesktop.org > >> Cc: Eric Anholt > >> Cc: Rob Herring > >> Cc: Sam Ravnborg > >> Cc: devicet...@vger.kernel.org > >> --- > > > > Two general comments. > > - This driver should use the bridge panel - this will simplify the > > driver in many places. We already have several good examples in-tree > > that does this. > > Can you list such an example ? Take a look at tc358764.c in following patch-set: https://lore.kernel.org/dri-devel/20200726203324.3722593-1-...@ravnborg.org/ Your current driver will be even smaller after implmenting these changes. Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 01/15] drm/panel: panel-simple: validate panel description
Hi Sam,
Thank you for the patch.
On Sun, Jul 26, 2020 at 10:33:10PM +0200, Sam Ravnborg wrote:
> Warn if we detect a panel with incomplete/wrong description.
> This is inspired by a similar patch by Laurent that introduced checks
> for LVDS panels - this extends the checks to the remaining type of
> connectors.
>
> This is known to warn for some of the existing panels but added
> despite this as we need help from people using the panels to
> add the missing info.
> The checks are not complete but will catch the most common mistakes.
>
> The checks at the same time serves as documentation for the minimum
s/serves/serve/
> required description for a panel.
>
> The checks uses dev_warn() as we know this will hit. WARN() was
> too noisy at the moment for anything else than LVDS.
>
> v2:
> - Use dev_warn (Laurent)
> - Check for empty bus_flags
>
> Signed-off-by: Sam Ravnborg
> Cc: Laurent Pinchart
> Cc: Thierry Reding
> Cc: Sam Ravnborg
> ---
> drivers/gpu/drm/panel/panel-simple.c | 41 ++--
> 1 file changed, 39 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/panel/panel-simple.c
> b/drivers/gpu/drm/panel/panel-simple.c
> index 54323515ca2c..a8d68102931e 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -500,6 +500,7 @@ static int panel_simple_probe(struct device *dev, const
> struct panel_desc *desc)
> struct panel_simple *panel;
> struct display_timing dt;
> struct device_node *ddc;
> + u32 bus_flags;
> int err;
>
> panel = devm_kzalloc(dev, sizeof(*panel), GFP_KERNEL);
> @@ -549,8 +550,12 @@ static int panel_simple_probe(struct device *dev, const
> struct panel_desc *desc)
> panel_simple_parse_panel_timing_node(dev, panel, &dt);
> }
>
> - if (desc->connector_type == DRM_MODE_CONNECTOR_LVDS) {
> - /* Catch common mistakes for LVDS panels. */
> + /* Catch common mistakes for panels. */
> + switch (desc->connector_type) {
> + case 0:
> + dev_warn(dev, "Specify missing connector_type\n");
> + break;
> + case DRM_MODE_CONNECTOR_LVDS:
> WARN_ON(desc->bus_flags &
> ~(DRM_BUS_FLAG_DE_LOW |
> DRM_BUS_FLAG_DE_HIGH |
> @@ -564,6 +569,38 @@ static int panel_simple_probe(struct device *dev, const
> struct panel_desc *desc)
> WARN_ON((desc->bus_format == MEDIA_BUS_FMT_RGB888_1X7X4_SPWG ||
>desc->bus_format == MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA)
> &&
> desc->bpc != 8);
> + break;
> + case DRM_MODE_CONNECTOR_eDP:
> + if (desc->bus_format == 0)
> + dev_warn(dev, "Specify missing bus_format\n");
> + if (desc->bpc != 6 && desc->bpc != 8)
> + dev_warn(dev, "Expected bpc in {6,8} but got: %d\n",
> desc->bpc);
bpc is unsigned, so s/%d/%u/
> + break;
> + case DRM_MODE_CONNECTOR_DSI:
> + if (desc->bpc != 6 && desc->bpc != 8)
> + dev_warn(dev, "Expected bpc in {6,8} but got: %d\n",
> desc->bpc);
Same here.
> + break;
> + case DRM_MODE_CONNECTOR_DPI:
> + bus_flags = DRM_BUS_FLAG_DE_LOW |
> + DRM_BUS_FLAG_DE_HIGH |
> + DRM_BUS_FLAG_PIXDATA_SAMPLE_POSEDGE |
> + DRM_BUS_FLAG_PIXDATA_SAMPLE_NEGEDGE |
> + DRM_BUS_FLAG_DATA_MSB_TO_LSB |
> + DRM_BUS_FLAG_DATA_LSB_TO_MSB |
> + DRM_BUS_FLAG_SYNC_SAMPLE_POSEDGE |
> + DRM_BUS_FLAG_SYNC_SAMPLE_NEGEDGE;
> + if (desc->bus_flags & ~bus_flags)
> + dev_warn(dev, "Unexpected bus_flags(%d)\n",
> desc->bus_flags & ~bus_flags);
> + if (!(desc->bus_flags & bus_flags))
> + dev_warn(dev, "Specify missing bus_flags\n");
> + if (desc->bus_format == 0)
> + dev_warn(dev, "Specify missing bus_format\n");
> + if (desc->bpc != 6 && desc->bpc != 8)
> + dev_warn(dev, "Expected bpc in {6,8} but got: %d\n",
> desc->bpc);
And here too.
Reviewed-by: Laurent Pinchart
> + break;
> + default:
> + dev_warn(dev, "Specify a valid connector_type: %d\n",
> desc->connector_type);
> + break;
> }
>
> drm_panel_init(&panel->base, dev, &panel_simple_funcs,
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 02/15] drm/panel: panel-simple: add default connector_type
Hi Sam,
Thank you for the patch.
On Sun, Jul 26, 2020 at 10:33:11PM +0200, Sam Ravnborg wrote:
> All panels shall report a connector type.
> panel-simple has a lot of panels with no connector_type,
> and for these fall back to DPI as the default.
>
> v2:
> - Rebased on top of validation of panel description
>
> Signed-off-by: Sam Ravnborg
> Cc: Laurent Pinchart
> Cc: Thierry Reding
> Cc: Sam Ravnborg
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/panel/panel-simple.c | 9 ++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/panel/panel-simple.c
> b/drivers/gpu/drm/panel/panel-simple.c
> index a8d68102931e..56ab073e4e6e 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -500,6 +500,7 @@ static int panel_simple_probe(struct device *dev, const
> struct panel_desc *desc)
> struct panel_simple *panel;
> struct display_timing dt;
> struct device_node *ddc;
> + int connector_type;
> u32 bus_flags;
> int err;
>
> @@ -550,10 +551,12 @@ static int panel_simple_probe(struct device *dev, const
> struct panel_desc *desc)
> panel_simple_parse_panel_timing_node(dev, panel, &dt);
> }
>
> + connector_type = desc->connector_type;
> /* Catch common mistakes for panels. */
> - switch (desc->connector_type) {
> + switch (connector_type) {
> case 0:
> dev_warn(dev, "Specify missing connector_type\n");
> + connector_type = DRM_MODE_CONNECTOR_DPI;
> break;
> case DRM_MODE_CONNECTOR_LVDS:
> WARN_ON(desc->bus_flags &
> @@ -600,11 +603,11 @@ static int panel_simple_probe(struct device *dev, const
> struct panel_desc *desc)
> break;
> default:
> dev_warn(dev, "Specify a valid connector_type: %d\n",
> desc->connector_type);
> + connector_type = DRM_MODE_CONNECTOR_DPI;
> break;
> }
>
> - drm_panel_init(&panel->base, dev, &panel_simple_funcs,
> -desc->connector_type);
> + drm_panel_init(&panel->base, dev, &panel_simple_funcs, connector_type);
>
> err = drm_panel_of_backlight(&panel->base);
> if (err)
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 05/15] drm/bridge: tc358767: add detect bridge operation
Hi Sam,
Thank you for the patch.
On Sun, Jul 26, 2020 at 10:33:14PM +0200, Sam Ravnborg wrote:
> Prepare the bridge driver for chained operation by adding
> support for the detect operation.
>
> v2:
> - Do not announce detect operation if there is no hpd pin (Laurent)
>
> Signed-off-by: Sam Ravnborg
> Cc: Andrzej Hajda
> Cc: Neil Armstrong
> Cc: Laurent Pinchart
> Cc: Jonas Karlman
> Cc: Jernej Skrabec
> ---
> drivers/gpu/drm/bridge/tc358767.c | 30 --
> 1 file changed, 20 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/tc358767.c
> b/drivers/gpu/drm/bridge/tc358767.c
> index c2777b226c75..e8ba713bedac 100644
> --- a/drivers/gpu/drm/bridge/tc358767.c
> +++ b/drivers/gpu/drm/bridge/tc358767.c
> @@ -1369,21 +1369,13 @@ static const struct drm_connector_helper_funcs
> tc_connector_helper_funcs = {
> .get_modes = tc_connector_get_modes,
> };
>
> -static enum drm_connector_status tc_connector_detect(struct drm_connector
> *connector,
> - bool force)
> +static enum drm_connector_status tc_bridge_detect(struct drm_bridge *bridge)
> {
> - struct tc_data *tc = connector_to_tc(connector);
> + struct tc_data *tc = bridge_to_tc(bridge);
> bool conn;
> u32 val;
> int ret;
>
> - if (tc->hpd_pin < 0) {
> - if (tc->panel)
> - return connector_status_connected;
> - else
> - return connector_status_unknown;
> - }
> -
> ret = regmap_read(tc->regmap, GPIOI, &val);
> if (ret)
> return connector_status_unknown;
> @@ -1396,6 +1388,20 @@ static enum drm_connector_status
> tc_connector_detect(struct drm_connector *conne
> return connector_status_disconnected;
> }
>
> +static enum drm_connector_status
> +tc_connector_detect(struct drm_connector *connector, bool force)
> +{
> + struct tc_data *tc = connector_to_tc(connector);
> +
> + if (tc->hpd_pin >= 0)
> + return tc_bridge_detect(&tc->bridge);
> + else
> + if (tc->panel)
> + return connector_status_connected;
> +
> + return connector_status_unknown;
I'd write this
if (tc->hpd_pin >= 0)
return tc_bridge_detect(&tc->bridge);
if (tc->panel)
return connector_status_connected;
else
return connector_status_unknown;
Reviewed-by: Laurent Pinchart
> +}
> +
> static const struct drm_connector_funcs tc_connector_funcs = {
> .detect = tc_connector_detect,
> .fill_modes = drm_helper_probe_single_connector_modes,
> @@ -1458,6 +1464,7 @@ static const struct drm_bridge_funcs tc_bridge_funcs = {
> .disable = tc_bridge_disable,
> .post_disable = tc_bridge_post_disable,
> .mode_fixup = tc_bridge_mode_fixup,
> + .detect = tc_bridge_detect,
> };
>
> static bool tc_readable_reg(struct device *dev, unsigned int reg)
> @@ -1680,6 +1687,9 @@ static int tc_probe(struct i2c_client *client, const
> struct i2c_device_id *id)
> return ret;
>
> tc->bridge.funcs = &tc_bridge_funcs;
> + if (tc->hpd_pin >= 0)
> + tc->bridge.ops |= DRM_BRIDGE_OP_DETECT;
> +
> tc->bridge.of_node = dev->of_node;
> drm_bridge_add(&tc->bridge);
>
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 04/15] drm/bridge: tc358764: add drm_panel_bridge support
Hi Sam,
Thank you for the patch.
On Sun, Jul 26, 2020 at 10:33:13PM +0200, Sam Ravnborg wrote:
> Prepare the tc358764 bridge driver for use in a chained setup by
> replacing direct use of drm_panel with drm_panel_bridge support.
>
> The bridge panel will use the connector type reported by the panel,
> where the connector for this driver hardcodes DRM_MODE_CONNECTOR_LVDS.
>
> The tc358764 did not any additional info the the connector so the
Did you mean s/did not any/did not add any/ ?
s/the the/to the/
> connector creation is passed to the bridge panel driver.
>
> v3:
> - Merge with patch to make connector creation optional to avoid
> creating two connectors (Laurent)
> - Pass connector creation to bridge panel, as this bridge driver
> did not add any extra info to the connector.
> - Set bridge.type to DRM_MODE_CONNECTOR_LVDS.
>
> v2:
> - Use PTR_ERR_OR_ZERO() (kbuild test robot)
>
> Signed-off-by: Sam Ravnborg
> Cc: Laurent Pinchart
> Cc: kbuild test robot
> Cc: Andrzej Hajda
> Cc: Neil Armstrong
> Cc: Jonas Karlman
> Cc: Jernej Skrabec
> ---
> drivers/gpu/drm/bridge/tc358764.c | 107 +-
> 1 file changed, 16 insertions(+), 91 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/tc358764.c
> b/drivers/gpu/drm/bridge/tc358764.c
> index a277739fab58..fdde4cfdc724 100644
> --- a/drivers/gpu/drm/bridge/tc358764.c
> +++ b/drivers/gpu/drm/bridge/tc358764.c
> @@ -153,10 +153,9 @@ static const char * const tc358764_supplies[] = {
> struct tc358764 {
> struct device *dev;
> struct drm_bridge bridge;
> - struct drm_connector connector;
> struct regulator_bulk_data supplies[ARRAY_SIZE(tc358764_supplies)];
> struct gpio_desc *gpio_reset;
> - struct drm_panel *panel;
> + struct drm_bridge *panel_bridge;
> int error;
> };
>
> @@ -210,12 +209,6 @@ static inline struct tc358764 *bridge_to_tc358764(struct
> drm_bridge *bridge)
> return container_of(bridge, struct tc358764, bridge);
> }
>
> -static inline
> -struct tc358764 *connector_to_tc358764(struct drm_connector *connector)
> -{
> - return container_of(connector, struct tc358764, connector);
> -}
> -
> static int tc358764_init(struct tc358764 *ctx)
> {
> u32 v = 0;
> @@ -278,43 +271,11 @@ static void tc358764_reset(struct tc358764 *ctx)
> usleep_range(1000, 2000);
> }
>
> -static int tc358764_get_modes(struct drm_connector *connector)
> -{
> - struct tc358764 *ctx = connector_to_tc358764(connector);
> -
> - return drm_panel_get_modes(ctx->panel, connector);
> -}
> -
> -static const
> -struct drm_connector_helper_funcs tc358764_connector_helper_funcs = {
> - .get_modes = tc358764_get_modes,
> -};
> -
> -static const struct drm_connector_funcs tc358764_connector_funcs = {
> - .fill_modes = drm_helper_probe_single_connector_modes,
> - .destroy = drm_connector_cleanup,
> - .reset = drm_atomic_helper_connector_reset,
> - .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
> - .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
> -};
> -
> -static void tc358764_disable(struct drm_bridge *bridge)
> -{
> - struct tc358764 *ctx = bridge_to_tc358764(bridge);
> - int ret = drm_panel_disable(bridge_to_tc358764(bridge)->panel);
> -
> - if (ret < 0)
> - dev_err(ctx->dev, "error disabling panel (%d)\n", ret);
> -}
> -
> static void tc358764_post_disable(struct drm_bridge *bridge)
> {
> struct tc358764 *ctx = bridge_to_tc358764(bridge);
> int ret;
>
> - ret = drm_panel_unprepare(ctx->panel);
> - if (ret < 0)
> - dev_err(ctx->dev, "error unpreparing panel (%d)\n", ret);
> tc358764_reset(ctx);
> usleep_range(1, 15000);
> ret = regulator_bulk_disable(ARRAY_SIZE(ctx->supplies), ctx->supplies);
> @@ -335,70 +296,28 @@ static void tc358764_pre_enable(struct drm_bridge
> *bridge)
> ret = tc358764_init(ctx);
> if (ret < 0)
> dev_err(ctx->dev, "error initializing bridge (%d)\n", ret);
> - ret = drm_panel_prepare(ctx->panel);
> - if (ret < 0)
> - dev_err(ctx->dev, "error preparing panel (%d)\n", ret);
> -}
> -
> -static void tc358764_enable(struct drm_bridge *bridge)
> -{
> - struct tc358764 *ctx = bridge_to_tc358764(bridge);
> - int ret = drm_panel_enable(ctx->panel);
> -
> - if (ret < 0)
> - dev_err(ctx->dev, "error enabling panel (%d)\n", ret);
> }
>
> static int tc358764_attach(struct drm_bridge *bridge,
> enum drm_bridge_attach_flags flags)
> -{
> - struct tc358764 *ctx = bridge_to_tc358764(bridge);
> - struct drm_device *drm = bridge->dev;
> - int ret;
> -
> - if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR) {
> - DRM_ERROR("Fix bridge driver to make connector optional!");
> - return -EINVAL;
> - }
> -
> - ctx->connector.polled = DRM_CONNECTOR_POLL_HPD;
> - ret
Re: [PATCH v4 06/15] drm/bridge: tc358767: add get_edid bridge operation
Hi Sam,
Thank you for the patch.
On Sun, Jul 26, 2020 at 10:33:15PM +0200, Sam Ravnborg wrote:
> Prepare for chained bridge with the addition of
> get_edid support.
>
> v2:
> - Fixed handling of edid storage (Laurent)
>
> Signed-off-by: Sam Ravnborg
> Cc: Andrzej Hajda
> Cc: Neil Armstrong
> Cc: Laurent Pinchart
> Cc: Jonas Karlman
> Cc: Jernej Skrabec
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/bridge/tc358767.c | 34 ---
> 1 file changed, 18 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/tc358767.c
> b/drivers/gpu/drm/bridge/tc358767.c
> index e8ba713bedac..d86d7f06bebb 100644
> --- a/drivers/gpu/drm/bridge/tc358767.c
> +++ b/drivers/gpu/drm/bridge/tc358767.c
> @@ -250,8 +250,6 @@ struct tc_data {
> /* link settings */
> struct tc_edp_link link;
>
> - /* display edid */
> - struct edid *edid;
> /* current mode */
> struct drm_display_mode mode;
>
> @@ -1335,11 +1333,19 @@ static void tc_bridge_mode_set(struct drm_bridge
> *bridge,
> tc->mode = *mode;
> }
>
> +static struct edid *tc_get_edid(struct drm_bridge *bridge,
> + struct drm_connector *connector)
> +{
> + struct tc_data *tc = bridge_to_tc(bridge);
> +
> + return drm_get_edid(connector, &tc->aux.ddc);
> +}
> +
> static int tc_connector_get_modes(struct drm_connector *connector)
> {
> struct tc_data *tc = connector_to_tc(connector);
> + int num_modes;
> struct edid *edid;
> - int count;
> int ret;
>
> ret = tc_get_display_props(tc);
> @@ -1348,21 +1354,15 @@ static int tc_connector_get_modes(struct
> drm_connector *connector)
> return 0;
> }
>
> - count = drm_panel_get_modes(tc->panel, connector);
> - if (count > 0)
> - return count;
> -
> - edid = drm_get_edid(connector, &tc->aux.ddc);
> -
> - kfree(tc->edid);
> - tc->edid = edid;
> - if (!edid)
> - return 0;
> + num_modes = drm_panel_get_modes(tc->panel, connector);
> + if (num_modes > 0)
> + return num_modes;
>
> - drm_connector_update_edid_property(connector, edid);
> - count = drm_add_edid_modes(connector, edid);
> + edid = tc_get_edid(&tc->bridge, connector);
> + num_modes = drm_add_edid_modes(connector, edid);
> + kfree(edid);
>
> - return count;
> + return num_modes;
> }
>
> static const struct drm_connector_helper_funcs tc_connector_helper_funcs = {
> @@ -1465,6 +1465,7 @@ static const struct drm_bridge_funcs tc_bridge_funcs = {
> .post_disable = tc_bridge_post_disable,
> .mode_fixup = tc_bridge_mode_fixup,
> .detect = tc_bridge_detect,
> + .get_edid = tc_get_edid,
> };
>
> static bool tc_readable_reg(struct device *dev, unsigned int reg)
> @@ -1689,6 +1690,7 @@ static int tc_probe(struct i2c_client *client, const
> struct i2c_device_id *id)
> tc->bridge.funcs = &tc_bridge_funcs;
> if (tc->hpd_pin >= 0)
> tc->bridge.ops |= DRM_BRIDGE_OP_DETECT;
> + tc->bridge.ops |= DRM_BRIDGE_OP_EDID;
>
> tc->bridge.of_node = dev->of_node;
> drm_bridge_add(&tc->bridge);
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 07/15] drm/bridge: tc358767: add drm_panel_bridge support
Hi Sam,
Thank you for the patch.
On Sun, Jul 26, 2020 at 10:33:16PM +0200, Sam Ravnborg wrote:
> With the bridge operations implemented the last step to prepare
> this driver for a chained setup is the use of the bridge panel driver.
>
> The bridge panel driver is only used when a prot@2 is present in
s/prot/port/
> the DT. So when the display driver request a connector
s/request/requests/
> support both situations:
> - connector created by bridge panel driver
> - connector created by this driver
>
> And on top, support that the display driver creates the connector,
> which is the preferred setup.
>
> Note: the bridge panel will use the connector type from the panel.
>
> v2:
> - Merge connector and drm_panel_bridge patches
> and fix so we do not create two connectors (Laurent)
>
> Signed-off-by: Sam Ravnborg
> Cc: Laurent Pinchart
> Cc: Andrzej Hajda
> Cc: Neil Armstrong
> Cc: Jonas Karlman
> Cc: Jernej Skrabec
> ---
> drivers/gpu/drm/bridge/tc358767.c | 70 +++
> 1 file changed, 35 insertions(+), 35 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/tc358767.c
> b/drivers/gpu/drm/bridge/tc358767.c
> index d86d7f06bebb..75a2cd792ccc 100644
> --- a/drivers/gpu/drm/bridge/tc358767.c
> +++ b/drivers/gpu/drm/bridge/tc358767.c
> @@ -244,8 +244,8 @@ struct tc_data {
> struct drm_dp_aux aux;
>
> struct drm_bridge bridge;
> + struct drm_bridge *panel_bridge;
> struct drm_connectorconnector;
> - struct drm_panel*panel;
>
> /* link settings */
> struct tc_edp_link link;
> @@ -1234,13 +1234,6 @@ static int tc_stream_disable(struct tc_data *tc)
> return 0;
> }
>
> -static void tc_bridge_pre_enable(struct drm_bridge *bridge)
> -{
> - struct tc_data *tc = bridge_to_tc(bridge);
> -
> - drm_panel_prepare(tc->panel);
> -}
> -
> static void tc_bridge_enable(struct drm_bridge *bridge)
> {
> struct tc_data *tc = bridge_to_tc(bridge);
> @@ -1264,8 +1257,6 @@ static void tc_bridge_enable(struct drm_bridge *bridge)
> tc_main_link_disable(tc);
> return;
> }
> -
> - drm_panel_enable(tc->panel);
> }
>
> static void tc_bridge_disable(struct drm_bridge *bridge)
> @@ -1273,8 +1264,6 @@ static void tc_bridge_disable(struct drm_bridge *bridge)
> struct tc_data *tc = bridge_to_tc(bridge);
> int ret;
>
> - drm_panel_disable(tc->panel);
> -
> ret = tc_stream_disable(tc);
> if (ret < 0)
> dev_err(tc->dev, "main link stream stop error: %d\n", ret);
> @@ -1284,13 +1273,6 @@ static void tc_bridge_disable(struct drm_bridge
> *bridge)
> dev_err(tc->dev, "main link disable error: %d\n", ret);
> }
>
> -static void tc_bridge_post_disable(struct drm_bridge *bridge)
> -{
> - struct tc_data *tc = bridge_to_tc(bridge);
> -
> - drm_panel_unprepare(tc->panel);
> -}
> -
> static bool tc_bridge_mode_fixup(struct drm_bridge *bridge,
>const struct drm_display_mode *mode,
>struct drm_display_mode *adj)
> @@ -1354,9 +1336,11 @@ static int tc_connector_get_modes(struct drm_connector
> *connector)
> return 0;
> }
>
> - num_modes = drm_panel_get_modes(tc->panel, connector);
> - if (num_modes > 0)
> - return num_modes;
> + if (tc->panel_bridge) {
> + num_modes = drm_bridge_get_modes(tc->panel_bridge, connector);
> + if (num_modes > 0)
> + return num_modes;
> + }
>
> edid = tc_get_edid(&tc->bridge, connector);
> num_modes = drm_add_edid_modes(connector, edid);
> @@ -1396,7 +1380,7 @@ tc_connector_detect(struct drm_connector *connector,
> bool force)
> if (tc->hpd_pin >= 0)
> return tc_bridge_detect(&tc->bridge);
> else
> - if (tc->panel)
> + if (tc->panel_bridge)
> return connector_status_connected;
>
> return connector_status_unknown;
> @@ -1419,16 +1403,23 @@ static int tc_bridge_attach(struct drm_bridge *bridge,
> struct drm_device *drm = bridge->dev;
> int ret;
>
> - if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR) {
> - DRM_ERROR("Fix bridge driver to make connector optional!");
> - return -EINVAL;
> + if (tc->panel_bridge) {
> + enum drm_bridge_attach_flags panel_flags;
> +
> + /* If a connector is required then this driver shall create it
> */
> + panel_flags = flags & ~DRM_BRIDGE_ATTACH_NO_CONNECTOR;
Shouldn't this be
panel_flags = flags | DRM_BRIDGE_ATTACH_NO_CONNECTOR;
to ensure that the panel driver will not create a connector ?
> + ret = drm_bridge_attach(tc->bridge.encoder, tc->panel_bridge,
> + &tc->bridge, panel_flags);
> + if (ret)
> + return ret;
> }
>
Re: [PATCH v4 08/15] drm/bridge: parade-ps8622: add drm_panel_bridge support
Hi Sam,
Thank you for the patch.
On Sun, Jul 26, 2020 at 10:33:17PM +0200, Sam Ravnborg wrote:
> Prepare the bridge driver for use in a chained setup by
> replacing direct use of drm_panel with drm_panel_bridge support.
>
> The connecter is now either created by the panel bridge or the display
> driver. So all code for connector creation in this driver is no longer
> relevant and thus dropped.
>
> The connector code had some special polling handling:
> connector.polled = DRM_CONNECTOR_POLL_HPD;
> drm_helper_hpd_irq_event(ps8622->bridge.dev);
>
> This code was most likely added to speed up detection of the connector.
> If really needed then this functionality belongs somewhere else.
>
> Note: the bridge panel will use the connector type from the panel.
>
> v2:
> - Fix to avoid creating connector twice (Laurent)
> - Drop all connector code - defer to bridge panel
> - Use panel_bridge for local variable to align with other drivers
> - Set bridge.type to DRM_MODE_CONNECTOR_LVDS;
>
> Signed-off-by: Sam Ravnborg
> Cc: Andrzej Hajda
> Cc: Neil Armstrong
> Cc: Laurent Pinchart
> Cc: Jonas Karlman
> Cc: Jernej Skrabec
> ---
> drivers/gpu/drm/bridge/parade-ps8622.c | 100 -
> 1 file changed, 13 insertions(+), 87 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/parade-ps8622.c
> b/drivers/gpu/drm/bridge/parade-ps8622.c
> index d789ea2a7fb9..614b19f0f1b7 100644
> --- a/drivers/gpu/drm/bridge/parade-ps8622.c
> +++ b/drivers/gpu/drm/bridge/parade-ps8622.c
> @@ -42,10 +42,9 @@
> #endif
>
> struct ps8622_bridge {
> - struct drm_connector connector;
> struct i2c_client *client;
> struct drm_bridge bridge;
> - struct drm_panel *panel;
> + struct drm_bridge *panel_bridge;
> struct regulator *v12;
> struct backlight_device *bl;
>
> @@ -64,12 +63,6 @@ static inline struct ps8622_bridge *
> return container_of(bridge, struct ps8622_bridge, bridge);
> }
>
> -static inline struct ps8622_bridge *
> - connector_to_ps8622(struct drm_connector *connector)
> -{
> - return container_of(connector, struct ps8622_bridge, connector);
> -}
> -
> static int ps8622_set(struct i2c_client *client, u8 page, u8 reg, u8 val)
> {
> int ret;
> @@ -365,11 +358,6 @@ static void ps8622_pre_enable(struct drm_bridge *bridge)
> DRM_ERROR("fails to enable ps8622->v12");
> }
>
> - if (drm_panel_prepare(ps8622->panel)) {
> - DRM_ERROR("failed to prepare panel\n");
> - return;
> - }
> -
> gpiod_set_value(ps8622->gpio_slp, 1);
>
> /*
> @@ -399,24 +387,9 @@ static void ps8622_pre_enable(struct drm_bridge *bridge)
> ps8622->enabled = true;
> }
>
> -static void ps8622_enable(struct drm_bridge *bridge)
> -{
> - struct ps8622_bridge *ps8622 = bridge_to_ps8622(bridge);
> -
> - if (drm_panel_enable(ps8622->panel)) {
> - DRM_ERROR("failed to enable panel\n");
> - return;
> - }
> -}
> -
> static void ps8622_disable(struct drm_bridge *bridge)
> {
> - struct ps8622_bridge *ps8622 = bridge_to_ps8622(bridge);
> -
> - if (drm_panel_disable(ps8622->panel)) {
> - DRM_ERROR("failed to disable panel\n");
> - return;
> - }
> + /* Delay after panel is disabled */
> msleep(PS8622_PWMO_END_T12_MS);
I really don't understand why a delay would be needed here.
Reviewed-by: Laurent Pinchart
> }
>
> @@ -436,11 +409,6 @@ static void ps8622_post_disable(struct drm_bridge
> *bridge)
>*/
> gpiod_set_value(ps8622->gpio_slp, 0);
>
> - if (drm_panel_unprepare(ps8622->panel)) {
> - DRM_ERROR("failed to unprepare panel\n");
> - return;
> - }
> -
> if (ps8622->v12)
> regulator_disable(ps8622->v12);
>
> @@ -455,67 +423,17 @@ static void ps8622_post_disable(struct drm_bridge
> *bridge)
> msleep(PS8622_POWER_OFF_T17_MS);
> }
>
> -static int ps8622_get_modes(struct drm_connector *connector)
> -{
> - struct ps8622_bridge *ps8622;
> -
> - ps8622 = connector_to_ps8622(connector);
> -
> - return drm_panel_get_modes(ps8622->panel, connector);
> -}
> -
> -static const struct drm_connector_helper_funcs ps8622_connector_helper_funcs
> = {
> - .get_modes = ps8622_get_modes,
> -};
> -
> -static const struct drm_connector_funcs ps8622_connector_funcs = {
> - .fill_modes = drm_helper_probe_single_connector_modes,
> - .destroy = drm_connector_cleanup,
> - .reset = drm_atomic_helper_connector_reset,
> - .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
> - .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
> -};
> -
> static int ps8622_attach(struct drm_bridge *bridge,
>enum drm_bridge_attach_flags flags)
> {
> struct ps8622_bridge *ps8622 = bridge_to_ps8622(bridge);
> - int ret;
> -
> - if (flags & DRM_BRIDGE_ATTACH
Re: [PATCH v4 12/15] drm/bridge: megachips: add get_edid bridge operation
Hi Sam,
Thank you for the patch.
On Sun, Jul 26, 2020 at 10:33:21PM +0200, Sam Ravnborg wrote:
> To prepare for a chained bridge setup add support for the
> get_edid bridge operation.
> There is no need for a copy of the edid - so drop
> the pointer to the copy.
>
> v2:
> - Fix so we do not leak memory (Laurent)
>
> Signed-off-by: Sam Ravnborg
> Cc: Peter Senna Tschudin
> Cc: Martin Donnelly
> Cc: Martyn Welch
> Cc: Andrzej Hajda
> Cc: Neil Armstrong
> Cc: Laurent Pinchart
> Cc: Jonas Karlman
> Cc: Jernej Skrabec
Reviewed-by: Laurent Pinchart
> ---
> .../bridge/megachips-stdp-ge-b850v3-fw.c | 31 ++-
> 1 file changed, 17 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c
> b/drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c
> index 450dca33ea48..f7b55dc374ac 100644
> --- a/drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c
> +++ b/drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c
> @@ -61,7 +61,6 @@ struct ge_b850v3_lvds {
> struct drm_bridge bridge;
> struct i2c_client *stdp4028_i2c;
> struct i2c_client *stdp2690_i2c;
> - struct edid *edid;
> };
>
> static struct ge_b850v3_lvds *ge_b850v3_lvds_ptr;
> @@ -131,22 +130,26 @@ static u8 *stdp2690_get_edid(struct i2c_client *client)
> return NULL;
> }
>
> -static int ge_b850v3_lvds_get_modes(struct drm_connector *connector)
> +static struct edid *ge_b850v3_lvds_get_edid(struct drm_bridge *bridge,
> + struct drm_connector *connector)
> {
> struct i2c_client *client;
> - int num_modes = 0;
>
> client = ge_b850v3_lvds_ptr->stdp2690_i2c;
>
> - kfree(ge_b850v3_lvds_ptr->edid);
> - ge_b850v3_lvds_ptr->edid = (struct edid *)stdp2690_get_edid(client);
> + return (struct edid *)stdp2690_get_edid(client);
> +}
>
> - if (ge_b850v3_lvds_ptr->edid) {
> - drm_connector_update_edid_property(connector,
> - ge_b850v3_lvds_ptr->edid);
> - num_modes = drm_add_edid_modes(connector,
> -ge_b850v3_lvds_ptr->edid);
> - }
> +static int ge_b850v3_lvds_get_modes(struct drm_connector *connector)
> +{
> + struct edid *edid;
> + int num_modes;
> +
> + edid = ge_b850v3_lvds_get_edid(&ge_b850v3_lvds_ptr->bridge, connector);
> +
> + drm_connector_update_edid_property(connector, edid);
> + num_modes = drm_add_edid_modes(connector, edid);
> + kfree(edid);
>
> return num_modes;
> }
> @@ -269,6 +272,7 @@ static int ge_b850v3_lvds_attach(struct drm_bridge
> *bridge,
> static const struct drm_bridge_funcs ge_b850v3_lvds_funcs = {
> .attach = ge_b850v3_lvds_attach,
> .detect = ge_b850v3_lvds_bridge_detect,
> + .get_edid = ge_b850v3_lvds_get_edid,
> };
>
> static int ge_b850v3_lvds_init(struct device *dev)
> @@ -304,8 +308,6 @@ static void ge_b850v3_lvds_remove(void)
>
> drm_bridge_remove(&ge_b850v3_lvds_ptr->bridge);
>
> - kfree(ge_b850v3_lvds_ptr->edid);
> -
> ge_b850v3_lvds_ptr = NULL;
> out:
> mutex_unlock(&ge_b850v3_lvds_dev_mutex);
> @@ -323,7 +325,8 @@ static int stdp4028_ge_b850v3_fw_probe(struct i2c_client
> *stdp4028_i2c,
>
> /* drm bridge initialization */
> ge_b850v3_lvds_ptr->bridge.funcs = &ge_b850v3_lvds_funcs;
> - ge_b850v3_lvds_ptr->bridge.ops = DRM_BRIDGE_OP_DETECT;
> + ge_b850v3_lvds_ptr->bridge.ops = DRM_BRIDGE_OP_DETECT |
> + DRM_BRIDGE_OP_EDID;
> ge_b850v3_lvds_ptr->bridge.of_node = dev->of_node;
> drm_bridge_add(&ge_b850v3_lvds_ptr->bridge);
>
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 13/15] drm/bridge: megachips: make connector creation optional
Hi Sam,
Thank you for the patch.
On Sun, Jul 26, 2020 at 10:33:22PM +0200, Sam Ravnborg wrote:
> Make the connector creation optional to enable usage of the
> megachips-stdp-ge-b850v3-fw bridge with the DRM bridge connector
> helper.
>
> v2:
> - Set bridge.type to DRM_MODE_CONNECTOR_DisplayPort
>
> Signed-off-by: Sam Ravnborg
> Cc: Peter Senna Tschudin
> Cc: Martin Donnelly
> Cc: Martyn Welch
> Cc: Andrzej Hajda
> Cc: Neil Armstrong
> Cc: Laurent Pinchart
> Cc: Jonas Karlman
> Cc: Jernej Skrabec
Reviewed-by: Laurent Pinchart
> ---
> .../drm/bridge/megachips-stdp-ge-b850v3-fw.c | 16 +---
> 1 file changed, 5 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c
> b/drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c
> index f7b55dc374ac..61a24f265c7a 100644
> --- a/drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c
> +++ b/drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c
> @@ -245,16 +245,6 @@ static int ge_b850v3_lvds_attach(struct drm_bridge
> *bridge,
> {
> struct i2c_client *stdp4028_i2c
> = ge_b850v3_lvds_ptr->stdp4028_i2c;
> - int ret;
> -
> - if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR) {
> - DRM_ERROR("Fix bridge driver to make connector optional!");
> - return -EINVAL;
> - }
> -
> - ret = ge_b850v3_lvds_create_connector(bridge);
> - if (ret)
> - return ret;
>
> /* Configures the bridge to re-enable interrupts after each ack. */
> i2c_smbus_write_word_data(stdp4028_i2c,
> @@ -266,7 +256,10 @@ static int ge_b850v3_lvds_attach(struct drm_bridge
> *bridge,
> STDP4028_DPTX_IRQ_EN_REG,
> STDP4028_DPTX_IRQ_CONFIG);
>
> - return 0;
> + if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR)
> + return 0;
> +
> + return ge_b850v3_lvds_create_connector(bridge);
> }
>
> static const struct drm_bridge_funcs ge_b850v3_lvds_funcs = {
> @@ -327,6 +320,7 @@ static int stdp4028_ge_b850v3_fw_probe(struct i2c_client
> *stdp4028_i2c,
> ge_b850v3_lvds_ptr->bridge.funcs = &ge_b850v3_lvds_funcs;
> ge_b850v3_lvds_ptr->bridge.ops = DRM_BRIDGE_OP_DETECT |
>DRM_BRIDGE_OP_EDID;
> + ge_b850v3_lvds_ptr->bridge.type = DRM_MODE_CONNECTOR_DisplayPort;
> ge_b850v3_lvds_ptr->bridge.of_node = dev->of_node;
> drm_bridge_add(&ge_b850v3_lvds_ptr->bridge);
>
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 14/15] drm/bridge: nxp-ptn3460: add get_edid bridge operation
Hi Sam,
Thank you for the patch.
On Sun, Jul 26, 2020 at 10:33:23PM +0200, Sam Ravnborg wrote:
> Add the get_edid() bridge operation to prepare for
> use as a chained bridge.
> Add helper function that is also used by the connector.
>
> v2:
> - Fix memory leak (Laurent)
> - Do not save a copy of edid, read it when needed
>
> Signed-off-by: Sam Ravnborg
> Cc: Andrzej Hajda
> Cc: Neil Armstrong
> Cc: Laurent Pinchart
> Cc: Jonas Karlman
> Cc: Jernej Skrabec
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/bridge/nxp-ptn3460.c | 43
> 1 file changed, 25 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/nxp-ptn3460.c
> b/drivers/gpu/drm/bridge/nxp-ptn3460.c
> index 438e566ce0a4..2805c8938f98 100644
> --- a/drivers/gpu/drm/bridge/nxp-ptn3460.c
> +++ b/drivers/gpu/drm/bridge/nxp-ptn3460.c
> @@ -29,7 +29,6 @@ struct ptn3460_bridge {
> struct drm_connector connector;
> struct i2c_client *client;
> struct drm_bridge bridge;
> - struct edid *edid;
> struct drm_panel *panel;
> struct gpio_desc *gpio_pd_n;
> struct gpio_desc *gpio_rst_n;
> @@ -184,17 +183,13 @@ static void ptn3460_post_disable(struct drm_bridge
> *bridge)
> }
> }
>
> -static int ptn3460_get_modes(struct drm_connector *connector)
> +static struct edid *ptn3460_get_edid(struct drm_bridge *bridge,
> + struct drm_connector *connector)
> {
> - struct ptn3460_bridge *ptn_bridge;
> - u8 *edid;
> - int ret, num_modes = 0;
> + struct ptn3460_bridge *ptn_bridge = bridge_to_ptn3460(bridge);
> bool power_off;
> -
> - ptn_bridge = connector_to_ptn3460(connector);
> -
> - if (ptn_bridge->edid)
> - return drm_add_edid_modes(connector, ptn_bridge->edid);
> + u8 *edid;
> + int ret;
>
> power_off = !ptn_bridge->enabled;
> ptn3460_pre_enable(&ptn_bridge->bridge);
> @@ -202,30 +197,40 @@ static int ptn3460_get_modes(struct drm_connector
> *connector)
> edid = kmalloc(EDID_LENGTH, GFP_KERNEL);
> if (!edid) {
> DRM_ERROR("Failed to allocate EDID\n");
> - return 0;
> + goto out;
> }
>
> ret = ptn3460_read_bytes(ptn_bridge, PTN3460_EDID_ADDR, edid,
> - EDID_LENGTH);
> + EDID_LENGTH);
> if (ret) {
> kfree(edid);
> + edid = NULL;
> goto out;
> }
>
> - ptn_bridge->edid = (struct edid *)edid;
> - drm_connector_update_edid_property(connector, ptn_bridge->edid);
> -
> - num_modes = drm_add_edid_modes(connector, ptn_bridge->edid);
> -
> out:
> if (power_off)
> ptn3460_disable(&ptn_bridge->bridge);
>
> + return (struct edid *)edid;
> +}
> +
> +static int ptn3460_connector_get_modes(struct drm_connector *connector)
> +{
> + struct ptn3460_bridge *ptn_bridge = connector_to_ptn3460(connector);
> + struct edid *edid;
> + int num_modes;
> +
> + edid = ptn3460_get_edid(&ptn_bridge->bridge, connector);
> + drm_connector_update_edid_property(connector, edid);
> + num_modes = drm_add_edid_modes(connector, edid);
> + kfree(edid);
> +
> return num_modes;
> }
>
> static const struct drm_connector_helper_funcs
> ptn3460_connector_helper_funcs = {
> - .get_modes = ptn3460_get_modes,
> + .get_modes = ptn3460_connector_get_modes,
> };
>
> static const struct drm_connector_funcs ptn3460_connector_funcs = {
> @@ -279,6 +284,7 @@ static const struct drm_bridge_funcs ptn3460_bridge_funcs
> = {
> .disable = ptn3460_disable,
> .post_disable = ptn3460_post_disable,
> .attach = ptn3460_bridge_attach,
> + .get_edid = ptn3460_get_edid,
> };
>
> static int ptn3460_probe(struct i2c_client *client,
> @@ -327,6 +333,7 @@ static int ptn3460_probe(struct i2c_client *client,
> }
>
> ptn_bridge->bridge.funcs = &ptn3460_bridge_funcs;
> + ptn_bridge->bridge.ops = DRM_BRIDGE_OP_EDID;
> ptn_bridge->bridge.of_node = dev->of_node;
> drm_bridge_add(&ptn_bridge->bridge);
>
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 15/15] drm/bridge: nxp-ptn3460: add drm_panel_bridge support
Hi Sam,
Thank you for the patch.
On Sun, Jul 26, 2020 at 10:33:24PM +0200, Sam Ravnborg wrote:
> Prepare the bridge driver for use in a chained setup.
>
> - Replacing direct use of drm_panel with drm_panel_bridge support.
> - Make the connector creation optional
>
> Note: the bridge panel will use the connector type from the panel.
>
> v2:
> - Use panel_bridge for local variable name to align with other drivers
> - Fix that connector was created twice (Laurent)
> - Set bridge.type to DRM_MODE_CONNECTOR_LVDS.
>
> Signed-off-by: Sam Ravnborg
> Cc: Andrzej Hajda
> Cc: Neil Armstrong
> Cc: Laurent Pinchart
> Cc: Jonas Karlman
> Cc: Jernej Skrabec
> ---
> drivers/gpu/drm/bridge/nxp-ptn3460.c | 60 ++--
> 1 file changed, 20 insertions(+), 40 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/nxp-ptn3460.c
> b/drivers/gpu/drm/bridge/nxp-ptn3460.c
> index 2805c8938f98..a49616855dd3 100644
> --- a/drivers/gpu/drm/bridge/nxp-ptn3460.c
> +++ b/drivers/gpu/drm/bridge/nxp-ptn3460.c
> @@ -29,7 +29,7 @@ struct ptn3460_bridge {
> struct drm_connector connector;
> struct i2c_client *client;
> struct drm_bridge bridge;
> - struct drm_panel *panel;
> + struct drm_bridge *panel_bridge;
> struct gpio_desc *gpio_pd_n;
> struct gpio_desc *gpio_rst_n;
> u32 edid_emulation;
> @@ -126,11 +126,6 @@ static void ptn3460_pre_enable(struct drm_bridge *bridge)
> usleep_range(10, 20);
> gpiod_set_value(ptn_bridge->gpio_rst_n, 1);
>
> - if (drm_panel_prepare(ptn_bridge->panel)) {
> - DRM_ERROR("failed to prepare panel\n");
> - return;
> - }
> -
> /*
>* There's a bug in the PTN chip where it falsely asserts hotplug before
>* it is fully functional. We're forced to wait for the maximum start up
> @@ -145,16 +140,6 @@ static void ptn3460_pre_enable(struct drm_bridge *bridge)
> ptn_bridge->enabled = true;
> }
>
> -static void ptn3460_enable(struct drm_bridge *bridge)
> -{
> - struct ptn3460_bridge *ptn_bridge = bridge_to_ptn3460(bridge);
> -
> - if (drm_panel_enable(ptn_bridge->panel)) {
> - DRM_ERROR("failed to enable panel\n");
> - return;
> - }
> -}
> -
> static void ptn3460_disable(struct drm_bridge *bridge)
> {
> struct ptn3460_bridge *ptn_bridge = bridge_to_ptn3460(bridge);
> @@ -164,24 +149,10 @@ static void ptn3460_disable(struct drm_bridge *bridge)
>
> ptn_bridge->enabled = false;
>
> - if (drm_panel_disable(ptn_bridge->panel)) {
> - DRM_ERROR("failed to disable panel\n");
> - return;
> - }
> -
> gpiod_set_value(ptn_bridge->gpio_rst_n, 1);
> gpiod_set_value(ptn_bridge->gpio_pd_n, 0);
> }
>
> -static void ptn3460_post_disable(struct drm_bridge *bridge)
> -{
> - struct ptn3460_bridge *ptn_bridge = bridge_to_ptn3460(bridge);
> -
> - if (drm_panel_unprepare(ptn_bridge->panel)) {
> - DRM_ERROR("failed to unprepare panel\n");
> - return;
> - }
> -}
>
Extra blank line.
> static struct edid *ptn3460_get_edid(struct drm_bridge *bridge,
>struct drm_connector *connector)
> @@ -245,12 +216,18 @@ static int ptn3460_bridge_attach(struct drm_bridge
> *bridge,
>enum drm_bridge_attach_flags flags)
> {
> struct ptn3460_bridge *ptn_bridge = bridge_to_ptn3460(bridge);
> + enum drm_bridge_attach_flags panel_flags;
> int ret;
>
> - if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR) {
> - DRM_ERROR("Fix bridge driver to make connector optional!");
> - return -EINVAL;
> - }
> + /* Let this driver create connector if requested */
> + panel_flags = flags & ~DRM_BRIDGE_ATTACH_NO_CONNECTOR;
Same as in a previous patch, should this be
panel_flags = flags | DRM_BRIDGE_ATTACH_NO_CONNECTOR;
?
> + ret = drm_bridge_attach(bridge->encoder, ptn_bridge->panel_bridge,
> + bridge, panel_flags);
> + if (ret < 0)
> + return ret;
> +
> + if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR)
> + return 0;
>
> if (!bridge->encoder) {
> DRM_ERROR("Parent encoder object not found");
> @@ -270,9 +247,6 @@ static int ptn3460_bridge_attach(struct drm_bridge
> *bridge,
> drm_connector_attach_encoder(&ptn_bridge->connector,
> bridge->encoder);
>
> - if (ptn_bridge->panel)
> - drm_panel_attach(ptn_bridge->panel, &ptn_bridge->connector);
> -
> drm_helper_hpd_irq_event(ptn_bridge->connector.dev);
>
> return ret;
> @@ -280,9 +254,7 @@ static int ptn3460_bridge_attach(struct drm_bridge
> *bridge,
>
> static const struct drm_bridge_funcs ptn3460_bridge_funcs = {
> .pre_enable = ptn3460_pre_enable,
> - .enable = ptn3460_enable,
> .disable = ptn3460_disable,
> - .post_
[Bug 204181] NULL pointer dereference regression in amdgpu
https://bugzilla.kernel.org/show_bug.cgi?id=204181 mn...@protonmail.com changed: What|Removed |Added CC||mn...@protonmail.com --- Comment #66 from mn...@protonmail.com --- Created attachment 290589 --> https://bugzilla.kernel.org/attachment.cgi?id=290589&action=edit drm/amd/display: Clear dm_state for fast updates Alright, the bug patch I mentioned in the last comment seems to be good after a few hours of testing. Please try out this patch and see if it fixes the issue for the rest of you. In the meantime, I'm doing more extended tests on this patch to confirm it works well enough before posting it on LKML. Nicholas, I haven't tested your commit since I was too busy with this. I'll try it out if this one fails though. Also, can you please review this patch to confirm that I'm not doing anything wrong here? -- 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 204181] NULL pointer dereference regression in amdgpu
https://bugzilla.kernel.org/show_bug.cgi?id=204181 --- Comment #67 from mn...@protonmail.com --- (In reply to mnrzk from comment #66) > Created attachment 290589 [details] > drm/amd/display: Clear dm_state for fast updates > > Alright, the bug patch I mentioned in the last comment seems to be good > after a few hours of testing. > > Please try out this patch and see if it fixes the issue for the rest of > you. > > In the meantime, I'm doing more extended tests on this patch to confirm it > works well enough before posting it on LKML. > > Nicholas, I haven't tested your commit since I was too busy with this. I'll > try it out if this one fails though. > > Also, can you please review this patch to confirm that I'm not doing > anything wrong here? Oh my god, I just responded to the wrong thread by accident, so sorry. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 207383] [Regression] 5.7 amdgpu/polaris11 gpf: amdgpu_atomic_commit_tail
https://bugzilla.kernel.org/show_bug.cgi?id=207383 mn...@protonmail.com changed: What|Removed |Added Attachment #290485|0 |1 is obsolete|| --- Comment #97 from mn...@protonmail.com --- Created attachment 290591 --> https://bugzilla.kernel.org/attachment.cgi?id=290591&action=edit drm/amd/display: Clear dm_state for fast updates drm/amd/display: Clear dm_state for fast updates Alright, the bug patch I mentioned in the last comment seems to be good after a few hours of testing. Please try out this patch and see if it fixes the issue for the rest of you. In the meantime, I'm doing more extended tests on this patch to confirm it works well enough before posting it on LKML. Nicholas, I haven't tested your commit since I was too busy with this. I'll try it out if this one fails though. Also, can you please review this patch to confirm that I'm not doing anything wrong here? -- 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
