Re: [PATCH v2 01/26] drm/bridge: allow optionally specifying an owner .odev device
On 10.05.2018 00:21, Peter Rosin wrote: > On 2018-05-09 17:53, Peter Rosin wrote: >> On 2018-05-09 17:08, Andrzej Hajda wrote: >>> On 04.05.2018 15:51, Peter Rosin wrote: Bridge drivers can now (temporarily, in a transition phase) select if they want to provide a full owner device or keep just providing an of_node. By providing a full owner device, the bridge drivers no longer need to provide an of_node since that node is available via the owner device. When all bridge drivers provide an owner device, that will become mandatory and the .of_node member will be removed. Signed-off-by: Peter Rosin --- drivers/gpu/drm/drm_bridge.c | 3 ++- drivers/gpu/drm/rockchip/rockchip_lvds.c | 4 +++- >>> What is the reason to put rockchip here? Shouldn't be in separate patch? >> Because the rockchip driver peeks into the bridge struct and all the >> changes in this patch relate to making the new .odev member optional in >> the transition phase, when the bridge can have either a new-style odev >> or an old style of_node. >> >> I guess this rockchip change could be patch 2, but it has to come first >> after this patch and it makes no sense on its own. Hence, one patch. >> >> This rockchip_lvds interaction is also present in patch 24/26 >> drm/bridge: remove the .of_node member >> >> I can split them if you want, but I personally don't see the point. > I had a second look, and maybe the series should start with a patch like > this instead, so that the rockchip_lvds.c hunks can be removed from > patch 1/26 and 24/26. That would perhaps be slightly cleaner? > > On the other hand, it's orthogonal and this series can be left as is > (with the benefit of me not having to do another iteration and you all > not having another bunch of messages to sift through). The below > patch could easily be (adjusted and) applied later instead. Or not, > since the right fix is to do this with the newfangled static image > format mechanism from Jacopo Mondi, and it might be easier to just do > it right. > > State your preference. For me the current version is OK, it maybe lacks explanation why do you need to touch rockchip, from my PoV it did not seem so obvious. Somebody should fix rockchip to use Jacopo's approach instead of violating abstractions, but this is another story. With or without added missing explanation: Reviewed-by: Andrzej Hajda -- Regards Andrzej > > Cheers, > Peter > > >From dee27b36a36acd271459d1489336b56132097425 Mon Sep 17 00:00:00 2001 > From: Peter Rosin > Date: Wed, 9 May 2018 23:58:24 +0200 > Subject: [PATCH] drm/rockchip: lvds: do not dig into the DT of remote bridges > > The driver is trying to find the needed "data-mapping" for > interacting with the following bridge in the graphics chain. > But, doing so is bad since it is done w/o regard of the > compatible of the remote bridge, so the value of "data-mapping" > might not mean what this driver assumes. It is also pointless > since no bridge has any documented "data-mapping" DT property > and no dts file show any undocumented use. > > Just remove the inappropriate code. > > Signed-off-by: Peter Rosin > --- > drivers/gpu/drm/rockchip/rockchip_lvds.c | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/drivers/gpu/drm/rockchip/rockchip_lvds.c > b/drivers/gpu/drm/rockchip/rockchip_lvds.c > index 4bd94b167d2c..fa3f4bf9712f 100644 > --- a/drivers/gpu/drm/rockchip/rockchip_lvds.c > +++ b/drivers/gpu/drm/rockchip/rockchip_lvds.c > @@ -377,8 +377,6 @@ static int rockchip_lvds_bind(struct device *dev, struct > device *master, > } > if (lvds->panel) > remote = lvds->panel->dev->of_node; > - else > - remote = lvds->bridge->of_node; > if (of_property_read_string(dev->of_node, "rockchip,output", &name)) > /* default set it as output rgb */ > lvds->output = DISPLAY_OUTPUT_RGB; ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 105684] Loading amdgpu hits general protection fault: 0000 [#1] SMP NOPTI
https://bugs.freedesktop.org/show_bug.cgi?id=105684 --- Comment #20 from jian-h...@endlessm.com --- Created attachment 139456 --> https://bugs.freedesktop.org/attachment.cgi?id=139456&action=edit amdgpu_vbios This is the amdgpu_vbios copied from /sys/kernel/debug/dri/0/amdgpu_vbios on this ACER desktop. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 25/26] drm/bridge: require the owner .odev to be filled in on drm_bridge_add/attach
On 04.05.2018 15:52, Peter Rosin wrote:
> The .odev owner device will be handy to have around.
>
> Signed-off-by: Peter Rosin
Reviewed-by: Andrzej Hajda
--
Regards
Andrzej
> ---
> drivers/gpu/drm/drm_bridge.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> index df084db33494..78d186b6831b 100644
> --- a/drivers/gpu/drm/drm_bridge.c
> +++ b/drivers/gpu/drm/drm_bridge.c
> @@ -70,6 +70,9 @@ static LIST_HEAD(bridge_list);
> */
> void drm_bridge_add(struct drm_bridge *bridge)
> {
> + if (WARN_ON(!bridge->odev))
> + return;
> +
> mutex_lock(&bridge_lock);
> list_add_tail(&bridge->list, &bridge_list);
> mutex_unlock(&bridge_lock);
> @@ -115,6 +118,9 @@ int drm_bridge_attach(struct drm_encoder *encoder, struct
> drm_bridge *bridge,
> if (!encoder || !bridge)
> return -EINVAL;
>
> + if (WARN_ON(!bridge->odev))
> + return -EINVAL;
> +
> if (previous && (!previous->dev || previous->encoder != encoder))
> return -EINVAL;
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 26/26] drm/bridge: establish a link between the bridge supplier and consumer
On 04.05.2018 15:52, Peter Rosin wrote:
> If the bridge supplier is unbound, this will bring the bridge consumer
> down along with the bridge. Thus, there will no longer linger any
> dangling pointers from the bridge consumer (the drm_device) to some
> non-existent bridge supplier.
>
> Signed-off-by: Peter Rosin
> ---
> drivers/gpu/drm/drm_bridge.c | 18 ++
> include/drm/drm_bridge.h | 2 ++
> 2 files changed, 20 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> index 78d186b6831b..0259f0a3ff27 100644
> --- a/drivers/gpu/drm/drm_bridge.c
> +++ b/drivers/gpu/drm/drm_bridge.c
> @@ -26,6 +26,7 @@
> #include
>
> #include
> +#include
> #include
>
> #include "drm_crtc_internal.h"
> @@ -127,12 +128,25 @@ int drm_bridge_attach(struct drm_encoder *encoder,
> struct drm_bridge *bridge,
> if (bridge->dev)
> return -EBUSY;
>
> + if (encoder->dev->dev != bridge->odev) {
I wonder why device_link_add does not handle this case (self dependency)
silently as noop, as it seems to be a correct behavior.
> + bridge->link = device_link_add(encoder->dev->dev,
> +bridge->odev, 0);
> + if (!bridge->link) {
> + dev_err(bridge->odev, "failed to link bridge to %s\n",
> + dev_name(encoder->dev->dev));
> + return -EINVAL;
> + }
> + }
> +
> bridge->dev = encoder->dev;
> bridge->encoder = encoder;
>
> if (bridge->funcs->attach) {
> ret = bridge->funcs->attach(bridge);
> if (ret < 0) {
> + if (bridge->link)
> + device_link_del(bridge->link);
> + bridge->link = NULL;
> bridge->dev = NULL;
> bridge->encoder = NULL;
> return ret;
> @@ -159,6 +173,10 @@ void drm_bridge_detach(struct drm_bridge *bridge)
> if (bridge->funcs->detach)
> bridge->funcs->detach(bridge);
>
> + if (bridge->link)
> + device_link_del(bridge->link);
> + bridge->link = NULL;
> +
> bridge->dev = NULL;
> }
>
> diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
> index b656e505d11e..804189c63a4c 100644
> --- a/include/drm/drm_bridge.h
> +++ b/include/drm/drm_bridge.h
> @@ -261,6 +261,7 @@ struct drm_bridge_timings {
> * @list: to keep track of all added bridges
> * @timings: the timing specification for the bridge, if any (may
> * be NULL)
> + * @link: drm consumer <-> bridge supplier
Nitpick: "<->" suggests symmetry, maybe "device link from drm consumer
to the bridge" would be better.
Anyway:
Reviewed-by: Andrzej Hajda
--
Regards
Andrzej
> * @funcs: control functions
> * @driver_private: pointer to the bridge driver's internal context
> */
> @@ -271,6 +272,7 @@ struct drm_bridge {
> struct drm_bridge *next;
> struct list_head list;
> const struct drm_bridge_timings *timings;
> + struct device_link *link;
>
> const struct drm_bridge_funcs *funcs;
> void *driver_private;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[DPU PATCH 01/11] drm/msm: remove redundant pm_runtime_enable call from msm_drv
MDSS top level device includes the common power resources and it's corresponding driver (i.e. mdp5_mdss) handles call to enable/disable runtime_pm for enabling these resources. Remove redundant pm_runtime_enable call from msm_drv. Signed-off-by: Rajesh Yadav --- drivers/gpu/drm/msm/msm_drv.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c index ebc40a9..9bb436f 100644 --- a/drivers/gpu/drm/msm/msm_drv.c +++ b/drivers/gpu/drm/msm/msm_drv.c @@ -581,7 +581,6 @@ static int msm_drm_init(struct device *dev, struct drm_driver *drv) goto fail; } priv->kms = kms; - pm_runtime_enable(dev); /** * Since kms->funcs->hw_init(kms) might call -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[DPU PATCH 03/11] drm/msm/dpu: add MDSS top level driver for dpu
SoCs containing dpu have a MDSS top level wrapper
which includes sub-blocks as dpu, dsi, phy, dp etc.
MDSS top level wrapper manages common resources like
common clocks, power and irq for its sub-blocks.
Currently, in dpu driver, all the power resource
management is part of power_handle which manages
these resources via a custom implementation. And
the resource relationships are not modelled properly
in dt. Moreover the irq domain handling code is part
of dpu device (which is a child device) due to lack
of a dedicated driver for MDSS top level wrapper
device.
This change adds dpu_mdss top level driver to handle
common clock like - core clock, ahb clock
(for register access), main power supply (i.e. gdsc)
and irq management.
The top level mdss device/driver acts as an interrupt
controller and manage hwirq mapping for its child
devices.
It implements runtime_pm support for resource management.
Child nodes can control these resources via runtime_pm
get/put calls on their corresponding devices due to parent
child relationship defined in dt.
Signed-off-by: Rajesh Yadav
---
drivers/gpu/drm/msm/Makefile | 1 +
drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c | 97 ---
drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.h | 14 -
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 9 -
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h| 7 -
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c | 29 +--
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.h | 11 -
drivers/gpu/drm/msm/disp/dpu1/dpu_irq.c | 48 +---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 6 -
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 2 -
drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c | 301 ++
drivers/gpu/drm/msm/dpu_io_util.c | 55
drivers/gpu/drm/msm/msm_drv.c | 26 +-
drivers/gpu/drm/msm/msm_drv.h | 2 +-
drivers/gpu/drm/msm/msm_kms.h | 2 +
include/linux/dpu_io_util.h | 2 +
16 files changed, 390 insertions(+), 222 deletions(-)
create mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c
diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index d7558ed..d9826c1 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -81,6 +81,7 @@ msm-y := \
disp/dpu1/dpu_reg_dma.o \
disp/dpu1/dpu_rm.o \
disp/dpu1/dpu_vbif.o \
+ disp/dpu1/dpu_mdss.o \
dpu_dbg.o \
dpu_io_util.o \
dpu_dbg_evtlog.o \
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c
index fe33013..977adc4 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c
@@ -515,103 +515,6 @@ void dpu_core_irq_uninstall(struct dpu_kms *dpu_kms)
dpu_kms->irq_obj.total_irqs = 0;
}
-static void dpu_core_irq_mask(struct irq_data *irqd)
-{
- struct dpu_kms *dpu_kms;
-
- if (!irqd || !irq_data_get_irq_chip_data(irqd)) {
- DPU_ERROR("invalid parameters irqd %d\n", irqd != NULL);
- return;
- }
- dpu_kms = irq_data_get_irq_chip_data(irqd);
-
- /* memory barrier */
- smp_mb__before_atomic();
- clear_bit(irqd->hwirq, &dpu_kms->irq_controller.enabled_mask);
- /* memory barrier */
- smp_mb__after_atomic();
-}
-
-static void dpu_core_irq_unmask(struct irq_data *irqd)
-{
- struct dpu_kms *dpu_kms;
-
- if (!irqd || !irq_data_get_irq_chip_data(irqd)) {
- DPU_ERROR("invalid parameters irqd %d\n", irqd != NULL);
- return;
- }
- dpu_kms = irq_data_get_irq_chip_data(irqd);
-
- /* memory barrier */
- smp_mb__before_atomic();
- set_bit(irqd->hwirq, &dpu_kms->irq_controller.enabled_mask);
- /* memory barrier */
- smp_mb__after_atomic();
-}
-
-static struct irq_chip dpu_core_irq_chip = {
- .name = "dpu",
- .irq_mask = dpu_core_irq_mask,
- .irq_unmask = dpu_core_irq_unmask,
-};
-
-static int dpu_core_irqdomain_map(struct irq_domain *domain,
- unsigned int irq, irq_hw_number_t hwirq)
-{
- struct dpu_kms *dpu_kms;
- int rc;
-
- if (!domain || !domain->host_data) {
- DPU_ERROR("invalid parameters domain %d\n", domain != NULL);
- return -EINVAL;
- }
- dpu_kms = domain->host_data;
-
- irq_set_chip_and_handler(irq, &dpu_core_irq_chip, handle_level_irq);
- rc = irq_set_chip_data(irq, dpu_kms);
-
- return rc;
-}
-
-static const struct irq_domain_ops dpu_core_irqdomain_ops = {
- .map = dpu_core_irqdomain_map,
- .xlate = irq_domain_xlate_onecell,
-};
-
-int dpu_core_irq_domain_add(struct dpu_kms *dpu_kms)
-{
- struct device *dev;
- struct irq_domain *domain;
-
- if (!dpu_kms->dev || !dpu_kms->dev->dev) {
- pr_err("inv
[DPU PATCH 04/11] drm/msm/dpu: create new platform driver for dpu device
Current MSM display controller HW matches a tree like
hierarchy where MDSS top level wrapper is parent device
and mdp5/dpu, dsi, dp are child devices.
Each child device like mdp5, dsi etc. have a separate driver,
but currently dpu handling is tied to a single driver which
was managing both mdss and dpu resources.
Inorder to have the cleaner one to one device and driver
association, this change adds a new platform_driver for dpu
child device node which implements the kms functionality.
The dpu driver implements runtime_pm support for managing clocks
and bus bandwidth etc.
Signed-off-by: Rajesh Yadav
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 251 ++--
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 4 +
drivers/gpu/drm/msm/msm_drv.c | 2 +
drivers/gpu/drm/msm/msm_drv.h | 3 +
4 files changed, 214 insertions(+), 46 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index e4ab753..2cd51fc 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -1030,14 +1030,13 @@ static long dpu_kms_round_pixclk(struct msm_kms *kms,
unsigned long rate,
return rate;
}
-static void _dpu_kms_hw_destroy(struct dpu_kms *dpu_kms,
- struct platform_device *pdev)
+static void _dpu_kms_hw_destroy(struct dpu_kms *dpu_kms)
{
struct drm_device *dev;
struct msm_drm_private *priv;
int i;
- if (!dpu_kms || !pdev)
+ if (!dpu_kms)
return;
dev = dpu_kms->dev;
@@ -1091,15 +1090,15 @@ static void _dpu_kms_hw_destroy(struct dpu_kms *dpu_kms,
dpu_kms->core_client = NULL;
if (dpu_kms->vbif[VBIF_NRT])
- msm_iounmap(pdev, dpu_kms->vbif[VBIF_NRT]);
+ msm_iounmap(dpu_kms->pdev, dpu_kms->vbif[VBIF_NRT]);
dpu_kms->vbif[VBIF_NRT] = NULL;
if (dpu_kms->vbif[VBIF_RT])
- msm_iounmap(pdev, dpu_kms->vbif[VBIF_RT]);
+ msm_iounmap(dpu_kms->pdev, dpu_kms->vbif[VBIF_RT]);
dpu_kms->vbif[VBIF_RT] = NULL;
if (dpu_kms->mmio)
- msm_iounmap(pdev, dpu_kms->mmio);
+ msm_iounmap(dpu_kms->pdev, dpu_kms->mmio);
dpu_kms->mmio = NULL;
dpu_reg_dma_deinit();
@@ -1172,8 +1171,6 @@ int dpu_kms_mmu_attach(struct dpu_kms *dpu_kms, bool
secure_only)
static void dpu_kms_destroy(struct msm_kms *kms)
{
struct dpu_kms *dpu_kms;
- struct drm_device *dev;
- struct platform_device *platformdev;
if (!kms) {
DPU_ERROR("invalid kms\n");
@@ -1181,20 +1178,7 @@ static void dpu_kms_destroy(struct msm_kms *kms)
}
dpu_kms = to_dpu_kms(kms);
- dev = dpu_kms->dev;
- if (!dev) {
- DPU_ERROR("invalid device\n");
- return;
- }
-
- platformdev = to_platform_device(dev->dev);
- if (!platformdev) {
- DPU_ERROR("invalid platform device\n");
- return;
- }
-
- _dpu_kms_hw_destroy(dpu_kms, platformdev);
- kfree(dpu_kms);
+ _dpu_kms_hw_destroy(dpu_kms);
}
static void dpu_kms_preclose(struct msm_kms *kms, struct drm_file *file)
@@ -1550,7 +1534,6 @@ static int dpu_kms_hw_init(struct msm_kms *kms)
struct dpu_kms *dpu_kms;
struct drm_device *dev;
struct msm_drm_private *priv;
- struct platform_device *platformdev;
int i, rc = -EINVAL;
if (!kms) {
@@ -1565,34 +1548,28 @@ static int dpu_kms_hw_init(struct msm_kms *kms)
goto end;
}
- platformdev = to_platform_device(dev->dev);
- if (!platformdev) {
- DPU_ERROR("invalid platform device\n");
- goto end;
- }
-
priv = dev->dev_private;
if (!priv) {
DPU_ERROR("invalid private data\n");
goto end;
}
- dpu_kms->mmio = msm_ioremap(platformdev, "mdp_phys", "mdp_phys");
+ dpu_kms->mmio = msm_ioremap(dpu_kms->pdev, "mdp_phys", "mdp_phys");
if (IS_ERR(dpu_kms->mmio)) {
rc = PTR_ERR(dpu_kms->mmio);
DPU_ERROR("mdp register memory map failed: %d\n", rc);
dpu_kms->mmio = NULL;
goto error;
}
- DRM_INFO("mapped mdp address space @%p\n", dpu_kms->mmio);
- dpu_kms->mmio_len = msm_iomap_size(platformdev, "mdp_phys");
+ DRM_INFO("mapped dpu address space @%p\n", dpu_kms->mmio);
+ dpu_kms->mmio_len = msm_iomap_size(dpu_kms->pdev, "mdp_phys");
rc = dpu_dbg_reg_register_base(DPU_DBG_NAME, dpu_kms->mmio,
dpu_kms->mmio_len);
if (rc)
DPU_ERROR("dbg base register kms failed: %d\n", rc);
- dpu_kms->vbif[VBIF_RT] = msm_ioremap(platformdev, "vbif_phys",
+ dpu_kms->vbif[VBIF_RT] = msm_ioremap(dpu_kms->pdev, "vbif_phys",
[DPU PATCH 00/11] Refactor DPU device/driver hierarchy and add runtime_pm support
SoCs containing mdp5 or dpu have a MDSS top level wrapper which includes sub-blocks as mdp5/dpu, dsi, dp, hdmi etc. The MDSS top level wrapper manages common resources like common clocks, main power supply and interrupts for its sub-blocks. But current dpu driver implementation is based on a flat device hierarchy where MDSS/DPU HW blocks were represented by single device and DSI/DP etc. are represented as independent devices w/o any relationships b/t these nodes which doesn't model the HW associations precisely. A minimal MDSS and DPU controller device separation is done in following patch series [1] but currently both these devices match to a single driver which is getting probed two times and all the resources are still tied to DPU device. Moreover, all the power resource management in DPU driver is part of power_handle module which manages these resources via a custom implementation. Irq domain handling is part of DPU device, due to lack of a dedicated driver for MDSS top level wrapper device. This patch series aims at adding separate drivers for MDSS top level wrapper device and DPU child device. MDP5 device/driver is used as a reference for this refactoring effort. Both the drivers implement runtime_pm support for their power resource management. Child nodes can control common resources managed by parent device due to parent child relationship defined in dt. The top level MDSS device acts as an interrupt controller and manages hwirq mappings for its child devices. Inorder to add MDP5 and DPU specific MDSS driver implementation, this patch series also subclasses existing msm_mdss define. A helper interface (msm_mdss_funcs) is added to invoke the platform specific implementations. This change also corrects hw catalog offsets for all sub blocks present within DPU device. The offset are now defined wrt DPU base address (instead of using MDSS base address). Clock and Power handling code have been removed from dpu_power_handle since each device manages it's resources via runtime_pm. Now, since dpu_power_handle manages only bus scaling and power enable/disable notifications and it's usage is restricted to DPU driver only, moved dpu_power_handle code to DPU folder. This patch series depends on [1]. 1 - https://lists.freedesktop.org/archives/freedreno/2018-April/002354.html Rajesh Yadav (11): drm/msm: remove pm_runtime_enable call from msm_drv drm/msm/mdp5: subclass msm_mdss for mdp5 drm/msm/dpu: add MDSS top level driver for dpu drm/msm/dpu: create new platform driver for dpu device drm/msm/dpu: update dpu sub-block offsets wrt dpu base address drm/msm/dpu: use runtime_pm calls on dpu device drm/msm/dpu: remove clock management code from dpu_power_handle drm/msm/dpu: remove power management code from dpu_power_handle drm/msm/dp: remove dpu_power_handle calls from dp driver drm/msm/dpu: use runtime_pm calls in dpu_dbg drm/msm/dpu: move dpu_power_handle to dpu folder drivers/gpu/drm/msm/Makefile |3 +- drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c | 106 +- drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.h | 14 - drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 51 +- drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h | 12 +- drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 19 +- drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h |2 + drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c| 17 +- .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c |5 +- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 77 +- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h |7 - drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c | 47 +- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.h | 11 - drivers/gpu/drm/msm/disp/dpu1/dpu_irq.c| 48 +- drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c| 354 +-- drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h| 16 +- drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c | 301 ++ drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c |6 +- drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.c | 694 + drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.h | 288 ++ drivers/gpu/drm/msm/disp/mdp5/mdp5_mdss.c | 154 +-- drivers/gpu/drm/msm/dp/dp_power.c | 32 +- drivers/gpu/drm/msm/dp/dp_power.h |4 +- drivers/gpu/drm/msm/dpu_dbg.c | 18 +- drivers/gpu/drm/msm/dpu_dbg.h | 13 +- drivers/gpu/drm/msm/dpu_io_util.c | 55 + drivers/gpu/drm/msm/dpu_power_handle.c | 1075 drivers/gpu/drm/msm/dpu_power_handle.h | 330 -- drivers/gpu/drm/msm/msm_drv.c | 86 +- drivers/gpu/drm/msm/msm_drv.h | 10 +- drivers/gpu/drm/msm/msm_kms.h | 22 +- include/linux/dpu_io_util.h|2 + 32 files changed, 1871
[DPU PATCH 07/11] drm/msm/dpu: remove clock management code from dpu_power_handle
MDSS and dpu drivers manage their respective clocks via
runtime_pm. Remove custom clock management code from
dpu_power_handle.
Also dpu core clock management code is restricted to
dpu_core_perf module.
Signed-off-by: Rajesh Yadav
---
drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 44 ++---
drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h | 8 +-
.../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 5 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c| 32 +++-
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h| 9 +
drivers/gpu/drm/msm/dpu_power_handle.c | 195 +
drivers/gpu/drm/msm/dpu_power_handle.h | 40 -
7 files changed, 69 insertions(+), 264 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
index 981f77f..d1364fa 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
@@ -365,6 +365,20 @@ void dpu_core_perf_crtc_release_bw(struct drm_crtc *crtc)
}
}
+static int _dpu_core_perf_set_core_clk_rate(struct dpu_kms *kms, u64 rate)
+{
+ struct dss_clk *core_clk = kms->perf.core_clk;
+ int rc = -EINVAL;
+
+ if (core_clk->max_rate && (rate > core_clk->max_rate))
+ rate = core_clk->max_rate;
+
+ core_clk->rate = rate;
+ rc = msm_dss_clk_set_rate(core_clk, 1);
+
+ return rc;
+}
+
static u64 _dpu_core_perf_get_core_clk_rate(struct dpu_kms *kms)
{
u64 clk_rate = kms->perf.perf_tune.min_core_clk;
@@ -376,7 +390,8 @@ static u64 _dpu_core_perf_get_core_clk_rate(struct dpu_kms
*kms)
dpu_cstate = to_dpu_crtc_state(crtc->state);
clk_rate = max(dpu_cstate->new_perf.core_clk_rate,
clk_rate);
- clk_rate = clk_round_rate(kms->perf.core_clk, clk_rate);
+ clk_rate = clk_round_rate(kms->perf.core_clk->clk,
+ clk_rate);
}
}
@@ -484,15 +499,11 @@ void dpu_core_perf_crtc_update(struct drm_crtc *crtc,
DPU_EVT32(kms->dev, stop_req, clk_rate);
- /* Temp change to avoid crash in clk_set_rate API. */
-#ifdef QCOM_DPU_SET_CLK
- if (dpu_power_clk_set_rate(&priv->phandle,
- kms->perf.clk_name, clk_rate)) {
+ if (_dpu_core_perf_set_core_clk_rate(kms, clk_rate)) {
DPU_ERROR("failed to set %s clock rate %llu\n",
- kms->perf.clk_name, clk_rate);
+ kms->perf.core_clk->clk_name, clk_rate);
return;
}
-#endif
kms->perf.core_clk_rate = clk_rate;
DPU_DEBUG("update clk rate = %lld HZ\n", clk_rate);
@@ -656,7 +667,6 @@ void dpu_core_perf_destroy(struct dpu_core_perf *perf)
dpu_core_perf_debugfs_destroy(perf);
perf->max_core_clk_rate = 0;
perf->core_clk = NULL;
- perf->clk_name = NULL;
perf->phandle = NULL;
perf->catalog = NULL;
perf->dev = NULL;
@@ -667,9 +677,9 @@ int dpu_core_perf_init(struct dpu_core_perf *perf,
struct dpu_mdss_cfg *catalog,
struct dpu_power_handle *phandle,
struct dpu_power_client *pclient,
- char *clk_name)
+ struct dss_clk *core_clk)
{
- if (!perf || !dev || !catalog || !phandle || !pclient || !clk_name) {
+ if (!perf || !dev || !catalog || !phandle || !pclient || !core_clk) {
DPU_ERROR("invalid parameters\n");
return -EINVAL;
}
@@ -678,23 +688,13 @@ int dpu_core_perf_init(struct dpu_core_perf *perf,
perf->catalog = catalog;
perf->phandle = phandle;
perf->pclient = pclient;
- perf->clk_name = clk_name;
+ perf->core_clk = core_clk;
- perf->core_clk = dpu_power_clk_get_clk(phandle, clk_name);
- if (!perf->core_clk) {
- DPU_ERROR("invalid core clk\n");
- goto err;
- }
-
- perf->max_core_clk_rate = dpu_power_clk_get_max_rate(phandle, clk_name);
+ perf->max_core_clk_rate = core_clk->max_rate;
if (!perf->max_core_clk_rate) {
DPU_DEBUG("optional max core clk rate, use default\n");
perf->max_core_clk_rate = DPU_PERF_DEFAULT_MAX_CORE_CLK_RATE;
}
return 0;
-
-err:
- dpu_core_perf_destroy(perf);
- return -ENODEV;
}
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h
index 1965ff5..9c1a719 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h
@@ -54,7 +54,6 @@ struct dpu_core_perf_tune {
* @catalog: Pointer to catalog configuration
*
[DPU PATCH 06/11] drm/msm/dpu: use runtime_pm calls on dpu device
The dpu driver implements runtime_pm support for managing
dpu specific resources like - clocks, bus bandwidth etc.
Use pm_runtime_get/put_sync calls on dpu device.
The common clocks and power management for all child nodes
(mdp5/dpu, dsi, dp etc) is done by parent MDSS device/driver
via runtime_pm due to parent child relationship.
Signed-off-by: Rajesh Yadav
---
drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c | 8 ++---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 12
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 16 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 45 +++-
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c| 6 ++--
5 files changed, 31 insertions(+), 56 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c
index 977adc4..5c5cc56 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c
@@ -452,10 +452,10 @@ void dpu_core_irq_preinstall(struct dpu_kms *dpu_kms)
}
priv = dpu_kms->dev->dev_private;
- dpu_power_resource_enable(&priv->phandle, dpu_kms->core_client, true);
+ pm_runtime_get_sync(&dpu_kms->pdev->dev);
dpu_clear_all_irqs(dpu_kms);
dpu_disable_all_irqs(dpu_kms);
- dpu_power_resource_enable(&priv->phandle, dpu_kms->core_client, false);
+ pm_runtime_put_sync(&dpu_kms->pdev->dev);
spin_lock_init(&dpu_kms->irq_obj.cb_lock);
@@ -496,7 +496,7 @@ void dpu_core_irq_uninstall(struct dpu_kms *dpu_kms)
}
priv = dpu_kms->dev->dev_private;
- dpu_power_resource_enable(&priv->phandle, dpu_kms->core_client, true);
+ pm_runtime_get_sync(&dpu_kms->pdev->dev);
for (i = 0; i < dpu_kms->irq_obj.total_irqs; i++)
if (atomic_read(&dpu_kms->irq_obj.enable_counts[i]) ||
!list_empty(&dpu_kms->irq_obj.irq_cb_tbl[i]))
@@ -504,7 +504,7 @@ void dpu_core_irq_uninstall(struct dpu_kms *dpu_kms)
dpu_clear_all_irqs(dpu_kms);
dpu_disable_all_irqs(dpu_kms);
- dpu_power_resource_enable(&priv->phandle, dpu_kms->core_client, false);
+ pm_runtime_put_sync(&dpu_kms->pdev->dev);
kfree(dpu_kms->irq_obj.irq_cb_tbl);
kfree(dpu_kms->irq_obj.enable_counts);
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index 48920b05..e2d2e32 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -86,8 +86,12 @@ static inline int _dpu_crtc_power_enable(struct dpu_crtc
*dpu_crtc, bool enable)
dpu_kms = to_dpu_kms(priv->kms);
- return dpu_power_resource_enable(&priv->phandle, dpu_kms->core_client,
- enable);
+ if (enable)
+ pm_runtime_get_sync(&dpu_kms->pdev->dev);
+ else
+ pm_runtime_put_sync(&dpu_kms->pdev->dev);
+
+ return 0;
}
/**
@@ -2250,7 +2254,6 @@ static int _dpu_crtc_vblank_enable_no_lock(
/* drop lock since power crtc cb may try to re-acquire lock */
mutex_unlock(&dpu_crtc->crtc_lock);
- pm_runtime_get_sync(dev->dev);
ret = _dpu_crtc_power_enable(dpu_crtc, true);
mutex_lock(&dpu_crtc->crtc_lock);
if (ret)
@@ -2580,7 +2583,6 @@ static void dpu_crtc_disable(struct drm_crtc *crtc)
/* disable clk & bw control until clk & bw properties are set */
cstate->bw_control = false;
cstate->bw_split_vote = false;
- pm_runtime_put_sync(crtc->dev->dev);
mutex_unlock(&dpu_crtc->crtc_lock);
}
@@ -2611,8 +2613,6 @@ static void dpu_crtc_enable(struct drm_crtc *crtc,
return;
}
- pm_runtime_get_sync(crtc->dev->dev);
-
drm_for_each_encoder(encoder, crtc->dev) {
if (encoder->crtc != crtc)
continue;
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 4386360..298a6ef 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -268,8 +268,12 @@ static inline int _dpu_encoder_power_enable(struct
dpu_encoder_virt *dpu_enc,
dpu_kms = to_dpu_kms(priv->kms);
- return dpu_power_resource_enable(&priv->phandle, dpu_kms->core_client,
- enable);
+ if (enable)
+ pm_runtime_get_sync(&dpu_kms->pdev->dev);
+ else
+ pm_runtime_put_sync(&dpu_kms->pdev->dev);
+
+ return 0;
}
void dpu_encoder_helper_report_irq_timeout(struct dpu_encoder_phys *phys_enc,
@@ -796,10 +800,8 @@ static void _dpu_encoder_resource_control_helper(struct
drm_encoder *drm_enc,
}
if (enable) {
- pm_runtime_get_sync(dpu_kms->dev->
[DPU PATCH 02/11] drm/msm/mdp5: subclass msm_mdss for mdp5
SoCs having mdp5 or dpu have identical tree like
device hierarchy where MDSS top level wrapper manages
common power resources for all child devices.
Subclass msm_mdss so that msm_mdss includes common defines
and mdp5/dpu mdss derivations to include any extensions.
Add mdss helper interface (msm_mdss_funcs) to msm_mdss
base for mdp5/dpu mdss specific implementation calls.
This change subclasses msm_mdss for mdp5, dpu specific
changes will be done separately.
Signed-off-by: Rajesh Yadav
---
drivers/gpu/drm/msm/disp/mdp5/mdp5_mdss.c | 154 --
drivers/gpu/drm/msm/msm_drv.c | 23 +++--
drivers/gpu/drm/msm/msm_kms.h | 20 ++--
3 files changed, 110 insertions(+), 87 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_mdss.c
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_mdss.c
index f2a0db7..88190e3 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_mdss.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_mdss.c
@@ -20,12 +20,10 @@
#include "msm_drv.h"
#include "mdp5_kms.h"
-/*
- * If needed, this can become more specific: something like struct mdp5_mdss,
- * which contains a 'struct msm_mdss base' member.
- */
-struct msm_mdss {
- struct drm_device *dev;
+#define to_mdp5_mdss(x) container_of(x, struct mdp5_mdss, base)
+
+struct mdp5_mdss {
+ struct msm_mdss base;
void __iomem *mmio, *vbif;
@@ -41,22 +39,22 @@ struct msm_mdss {
} irqcontroller;
};
-static inline void mdss_write(struct msm_mdss *mdss, u32 reg, u32 data)
+static inline void mdss_write(struct mdp5_mdss *mdp5_mdss, u32 reg, u32 data)
{
- msm_writel(data, mdss->mmio + reg);
+ msm_writel(data, mdp5_mdss->mmio + reg);
}
-static inline u32 mdss_read(struct msm_mdss *mdss, u32 reg)
+static inline u32 mdss_read(struct mdp5_mdss *mdp5_mdss, u32 reg)
{
- return msm_readl(mdss->mmio + reg);
+ return msm_readl(mdp5_mdss->mmio + reg);
}
static irqreturn_t mdss_irq(int irq, void *arg)
{
- struct msm_mdss *mdss = arg;
+ struct mdp5_mdss *mdp5_mdss = arg;
u32 intr;
- intr = mdss_read(mdss, REG_MDSS_HW_INTR_STATUS);
+ intr = mdss_read(mdp5_mdss, REG_MDSS_HW_INTR_STATUS);
VERB("intr=%08x", intr);
@@ -64,7 +62,7 @@ static irqreturn_t mdss_irq(int irq, void *arg)
irq_hw_number_t hwirq = fls(intr) - 1;
generic_handle_irq(irq_find_mapping(
- mdss->irqcontroller.domain, hwirq));
+ mdp5_mdss->irqcontroller.domain, hwirq));
intr &= ~(1 << hwirq);
}
@@ -84,19 +82,19 @@ static irqreturn_t mdss_irq(int irq, void *arg)
static void mdss_hw_mask_irq(struct irq_data *irqd)
{
- struct msm_mdss *mdss = irq_data_get_irq_chip_data(irqd);
+ struct mdp5_mdss *mdp5_mdss = irq_data_get_irq_chip_data(irqd);
smp_mb__before_atomic();
- clear_bit(irqd->hwirq, &mdss->irqcontroller.enabled_mask);
+ clear_bit(irqd->hwirq, &mdp5_mdss->irqcontroller.enabled_mask);
smp_mb__after_atomic();
}
static void mdss_hw_unmask_irq(struct irq_data *irqd)
{
- struct msm_mdss *mdss = irq_data_get_irq_chip_data(irqd);
+ struct mdp5_mdss *mdp5_mdss = irq_data_get_irq_chip_data(irqd);
smp_mb__before_atomic();
- set_bit(irqd->hwirq, &mdss->irqcontroller.enabled_mask);
+ set_bit(irqd->hwirq, &mdp5_mdss->irqcontroller.enabled_mask);
smp_mb__after_atomic();
}
@@ -109,13 +107,13 @@ static void mdss_hw_unmask_irq(struct irq_data *irqd)
static int mdss_hw_irqdomain_map(struct irq_domain *d, unsigned int irq,
irq_hw_number_t hwirq)
{
- struct msm_mdss *mdss = d->host_data;
+ struct mdp5_mdss *mdp5_mdss = d->host_data;
if (!(VALID_IRQS & (1 << hwirq)))
return -EPERM;
irq_set_chip_and_handler(irq, &mdss_hw_irq_chip, handle_level_irq);
- irq_set_chip_data(irq, mdss);
+ irq_set_chip_data(irq, mdp5_mdss);
return 0;
}
@@ -126,90 +124,99 @@ static int mdss_hw_irqdomain_map(struct irq_domain *d,
unsigned int irq,
};
-static int mdss_irq_domain_init(struct msm_mdss *mdss)
+static int mdss_irq_domain_init(struct mdp5_mdss *mdp5_mdss)
{
- struct device *dev = mdss->dev->dev;
+ struct device *dev = mdp5_mdss->base.dev->dev;
struct irq_domain *d;
d = irq_domain_add_linear(dev->of_node, 32, &mdss_hw_irqdomain_ops,
- mdss);
+ mdp5_mdss);
if (!d) {
dev_err(dev, "mdss irq domain add failed\n");
return -ENXIO;
}
- mdss->irqcontroller.enabled_mask = 0;
- mdss->irqcontroller.domain = d;
+ mdp5_mdss->irqcontroller.enabled_mask = 0;
+ mdp5_mdss->irqcontroller.domain = d;
return 0;
}
-int msm_mdss_enable(struct msm_mdss *mdss)
+static int mdp5_mdss_enable(struct msm_mdss *mdss)
{
+
[DPU PATCH 10/11] drm/msm/dpu: use runtime_pm calls in dpu_dbg
Currently, msm_drv was creating dpu_power_handle client
which was used by dpu_dbg module to enable power resources
before register debug dumping.
Now since, the mdss core power resource handling is
implemented via runtime_pm and same has been removed
from dpu_power_handle. Remove dpu_power_handle dependency
from msm_drv and use pm_runtime_get/put_sync calls from
dpu_dbg module on dpu_mdss top level device for core,
ahb clock and power resource management (for register access).
Signed-off-by: Rajesh Yadav
---
drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 4 +---
drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h | 4
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 3 +--
drivers/gpu/drm/msm/dpu_dbg.c | 18 +++---
drivers/gpu/drm/msm/dpu_dbg.h | 13 ++---
drivers/gpu/drm/msm/msm_drv.c | 27 +--
drivers/gpu/drm/msm/msm_drv.h | 1 -
7 files changed, 12 insertions(+), 58 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
index d1364fa..e2e7c06 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
@@ -676,10 +676,9 @@ int dpu_core_perf_init(struct dpu_core_perf *perf,
struct drm_device *dev,
struct dpu_mdss_cfg *catalog,
struct dpu_power_handle *phandle,
- struct dpu_power_client *pclient,
struct dss_clk *core_clk)
{
- if (!perf || !dev || !catalog || !phandle || !pclient || !core_clk) {
+ if (!perf || !dev || !catalog || !phandle || !core_clk) {
DPU_ERROR("invalid parameters\n");
return -EINVAL;
}
@@ -687,7 +686,6 @@ int dpu_core_perf_init(struct dpu_core_perf *perf,
perf->dev = dev;
perf->catalog = catalog;
perf->phandle = phandle;
- perf->pclient = pclient;
perf->core_clk = core_clk;
perf->max_core_clk_rate = core_clk->max_rate;
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h
index 9c1a719..cde48df 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h
@@ -53,7 +53,6 @@ struct dpu_core_perf_tune {
* @debugfs_root: top level debug folder
* @catalog: Pointer to catalog configuration
* @phandle: Pointer to power handler
- * @pclient: Pointer to power client
* @core_clk: Pointer to core clock structure
* @core_clk_rate: current core clock rate
* @max_core_clk_rate: maximum allowable core clock rate
@@ -68,7 +67,6 @@ struct dpu_core_perf {
struct dentry *debugfs_root;
struct dpu_mdss_cfg *catalog;
struct dpu_power_handle *phandle;
- struct dpu_power_client *pclient;
struct dss_clk *core_clk;
u64 core_clk_rate;
u64 max_core_clk_rate;
@@ -115,14 +113,12 @@ void dpu_core_perf_crtc_update(struct drm_crtc *crtc,
* @dev: Pointer to drm device
* @catalog: Pointer to catalog
* @phandle: Pointer to power handle
- * @pclient: Pointer to power client
* @core_clk: pointer to core clock
*/
int dpu_core_perf_init(struct dpu_core_perf *perf,
struct drm_device *dev,
struct dpu_mdss_cfg *catalog,
struct dpu_power_handle *phandle,
- struct dpu_power_client *pclient,
struct dss_clk *core_clk);
/**
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index f6511c9..67bef32 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -1728,8 +1728,7 @@ static int dpu_kms_hw_init(struct msm_kms *kms)
#endif
rc = dpu_core_perf_init(&dpu_kms->perf, dev, dpu_kms->catalog,
- &priv->phandle, priv->pclient,
- _dpu_kms_get_clk(dpu_kms, "core_clk"));
+ &priv->phandle, _dpu_kms_get_clk(dpu_kms, "core_clk"));
if (rc) {
DPU_ERROR("failed to init perf %d\n", rc);
goto perf_err;
diff --git a/drivers/gpu/drm/msm/dpu_dbg.c b/drivers/gpu/drm/msm/dpu_dbg.c
index 4a39b82..27538bc 100644
--- a/drivers/gpu/drm/msm/dpu_dbg.c
+++ b/drivers/gpu/drm/msm/dpu_dbg.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include "dpu_dbg.h"
#include "disp/dpu1/dpu_hw_catalog.h"
@@ -167,7 +168,6 @@ struct dpu_dbg_vbif_debug_bus {
* @evtlog: event log instance
* @reg_base_list: list of register dumping regions
* @dev: device pointer
- * @power_ctrl: callback structure for enabling power for reading hw registers
* @req_dump_blks: list of blocks requested for dumping
* @panic_on_err: whether to kernel panic after triggering dump via debugfs
* @dump_work: work struct for deferring register dump work to separate thread
@@ -182,7 +182,6 @@ struct dpu_dbg_vbif_debu
[DPU PATCH 05/11] drm/msm/dpu: update dpu sub-block offsets wrt dpu base address
The dpu sub-block offsets were defined wrt mdss base address
instead of dpu base address.
Since, dpu is now defined as a separate device, update hw catalog
offsets for all dpu sub blocks wrt dpu base address.
Signed-off-by: Rajesh Yadav
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 68 +++
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c | 18 +++---
2 files changed, 43 insertions(+), 43 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
index c5b370f..2fd3254 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -80,7 +80,7 @@
static struct dpu_mdp_cfg sdm845_mdp[] = {
{
.name = "top_0", .id = MDP_TOP,
- .base = 0x1000, .len = 0x45C,
+ .base = 0x0, .len = 0x45C,
.features = 0,
.highest_bank_bit = 0x2,
.has_dest_scaler = true,
@@ -111,27 +111,27 @@
static struct dpu_ctl_cfg sdm845_ctl[] = {
{
.name = "ctl_0", .id = CTL_0,
- .base = 0x2000, .len = 0xE4,
+ .base = 0x1000, .len = 0xE4,
.features = BIT(DPU_CTL_SPLIT_DISPLAY)
},
{
.name = "ctl_1", .id = CTL_1,
- .base = 0x2200, .len = 0xE4,
+ .base = 0x1200, .len = 0xE4,
.features = BIT(DPU_CTL_SPLIT_DISPLAY)
},
{
.name = "ctl_2", .id = CTL_2,
- .base = 0x2400, .len = 0xE4,
+ .base = 0x1400, .len = 0xE4,
.features = 0
},
{
.name = "ctl_3", .id = CTL_3,
- .base = 0x2600, .len = 0xE4,
+ .base = 0x1600, .len = 0xE4,
.features = 0
},
{
.name = "ctl_4", .id = CTL_4,
- .base = 0x2800, .len = 0xE4,
+ .base = 0x1800, .len = 0xE4,
.features = 0
},
};
@@ -211,21 +211,21 @@
}
static struct dpu_sspp_cfg sdm845_sspp[] = {
- SSPP_VIG_BLK("sspp_0", SSPP_VIG0, 0x5000,
+ SSPP_VIG_BLK("sspp_0", SSPP_VIG0, 0x4000,
sdm845_vig_sblk_0, 0, DPU_CLK_CTRL_VIG0),
- SSPP_VIG_BLK("sspp_1", SSPP_VIG1, 0x7000,
+ SSPP_VIG_BLK("sspp_1", SSPP_VIG1, 0x6000,
sdm845_vig_sblk_1, 4, DPU_CLK_CTRL_VIG1),
- SSPP_VIG_BLK("sspp_2", SSPP_VIG2, 0x9000,
+ SSPP_VIG_BLK("sspp_2", SSPP_VIG2, 0x8000,
sdm845_vig_sblk_2, 8, DPU_CLK_CTRL_VIG2),
- SSPP_VIG_BLK("sspp_3", SSPP_VIG3, 0xb000,
+ SSPP_VIG_BLK("sspp_3", SSPP_VIG3, 0xa000,
sdm845_vig_sblk_3, 12, DPU_CLK_CTRL_VIG3),
- SSPP_DMA_BLK("sspp_8", SSPP_DMA0, 0x25000,
+ SSPP_DMA_BLK("sspp_8", SSPP_DMA0, 0x24000,
sdm845_dma_sblk_0, 1, DPU_CLK_CTRL_DMA0),
- SSPP_DMA_BLK("sspp_9", SSPP_DMA1, 0x27000,
+ SSPP_DMA_BLK("sspp_9", SSPP_DMA1, 0x26000,
sdm845_dma_sblk_1, 5, DPU_CLK_CTRL_DMA1),
- SSPP_DMA_BLK("sspp_10", SSPP_DMA2, 0x29000,
+ SSPP_DMA_BLK("sspp_10", SSPP_DMA2, 0x28000,
sdm845_dma_sblk_2, 9, DPU_CLK_CTRL_CURSOR0),
- SSPP_DMA_BLK("sspp_11", SSPP_DMA3, 0x2b000,
+ SSPP_DMA_BLK("sspp_11", SSPP_DMA3, 0x2a000,
sdm845_dma_sblk_3, 13, DPU_CLK_CTRL_CURSOR1),
};
@@ -252,17 +252,17 @@
.lm_pair_mask = (1 << _lmpair) \
}
static struct dpu_lm_cfg sdm845_lm[] = {
- LM_BLK("lm_0", LM_0, 0x45000, DSPP_0,
+ LM_BLK("lm_0", LM_0, 0x44000, DSPP_0,
DS_0, PINGPONG_0, LM_1),
- LM_BLK("lm_1", LM_1, 0x46000, DSPP_1,
+ LM_BLK("lm_1", LM_1, 0x45000, DSPP_1,
DS_1, PINGPONG_1, LM_0),
- LM_BLK("lm_2", LM_2, 0x47000, DSPP_2,
+ LM_BLK("lm_2", LM_2, 0x46000, DSPP_2,
DS_MAX, PINGPONG_2, LM_5),
LM_BLK("lm_3", LM_3, 0x0, DSPP_MAX,
DS_MAX, PINGPONG_MAX, 0),
LM_BLK("lm_4", LM_4, 0x0, DSPP_MAX,
DS_MAX, PINGPONG_MAX, 0),
- LM_BLK("lm_5", LM_5, 0x4a000, DSPP_3,
+ LM_BLK("lm_5", LM_5, 0x49000, DSPP_3,
DS_MAX, PINGPONG_3, LM_2),
};
@@ -270,7 +270,7 @@
* DSPP sub blocks config
*/
static struct dpu_dspp_top_cfg sdm845_dspp_top = {
- .name = "dspp_top", .base = 0x1300, .len = 0xc
+ .name = "dspp_top", .base = 0x300, .len = 0xc
};
static const struct dpu_dspp_sub_blks sdm845_dspp_sblk = {
@@ -304,10 +304,10 @@
}
static struct dpu_dspp_cfg sdm845_dspp[] = {
- DSPP_BLK("dspp_0", DSPP_0, 0x55000),
- DSPP_BLK("dspp_1", DSPP_1, 0x57000),
- DSPP_BLK("dspp_2", DSPP_2, 0x59000),
- DSPP_BLK("dspp_3", DSPP_3, 0x5b000),
+ DSPP_BLK("dspp_0", DSPP_0, 0x54000),
+ DSPP_BLK("dspp_1", DSPP_1, 0x56000),
+ DSPP_BLK("dspp_2", DSPP_2, 0x58000),
+ DSPP_BLK("dspp_3", DSPP_3, 0x5a000),
};
/*
@@ -315,7 +315,7 @@
*/
static cons
[DPU PATCH 08/11] drm/msm/dpu: remove power management code from dpu_power_handle
Mdss main power supply (mdss_gdsc) is implemented as a
generic power domain and mdss top level wrapper device
manage it via runtime_pm. Remove custom power management
code from dpu_power_handle.
Signed-off-by: Rajesh Yadav
---
drivers/gpu/drm/msm/dpu_power_handle.c | 190 +
drivers/gpu/drm/msm/dpu_power_handle.h | 2 -
2 files changed, 1 insertion(+), 191 deletions(-)
diff --git a/drivers/gpu/drm/msm/dpu_power_handle.c
b/drivers/gpu/drm/msm/dpu_power_handle.c
index 17bae4b..909fbb8 100644
--- a/drivers/gpu/drm/msm/dpu_power_handle.c
+++ b/drivers/gpu/drm/msm/dpu_power_handle.c
@@ -101,150 +101,6 @@ void dpu_power_client_destroy(struct dpu_power_handle
*phandle,
}
}
-static int dpu_power_parse_dt_supply(struct platform_device *pdev,
- struct dss_module_power *mp)
-{
- int i = 0, rc = 0;
- u32 tmp = 0;
- struct device_node *of_node = NULL, *supply_root_node = NULL;
- struct device_node *supply_node = NULL;
-
- if (!pdev || !mp) {
- pr_err("invalid input param pdev:%pK mp:%pK\n", pdev, mp);
- return -EINVAL;
- }
-
- of_node = pdev->dev.of_node;
-
- mp->num_vreg = 0;
- supply_root_node = of_get_child_by_name(of_node,
- "qcom,platform-supply-entries");
- if (!supply_root_node) {
- pr_debug("no supply entry present\n");
- return rc;
- }
-
- for_each_child_of_node(supply_root_node, supply_node)
- mp->num_vreg++;
-
- if (mp->num_vreg == 0) {
- pr_debug("no vreg\n");
- return rc;
- }
-
- pr_debug("vreg found. count=%d\n", mp->num_vreg);
- mp->vreg_config = devm_kzalloc(&pdev->dev, sizeof(struct dss_vreg) *
- mp->num_vreg, GFP_KERNEL);
- if (!mp->vreg_config) {
- rc = -ENOMEM;
- return rc;
- }
-
- for_each_child_of_node(supply_root_node, supply_node) {
-
- const char *st = NULL;
-
- rc = of_property_read_string(supply_node,
- "qcom,supply-name", &st);
- if (rc) {
- pr_err("error reading name. rc=%d\n", rc);
- goto error;
- }
-
- strlcpy(mp->vreg_config[i].vreg_name, st,
- sizeof(mp->vreg_config[i].vreg_name));
-
- rc = of_property_read_u32(supply_node,
- "qcom,supply-min-voltage", &tmp);
- if (rc) {
- pr_err("error reading min volt. rc=%d\n", rc);
- goto error;
- }
- mp->vreg_config[i].min_voltage = tmp;
-
- rc = of_property_read_u32(supply_node,
- "qcom,supply-max-voltage", &tmp);
- if (rc) {
- pr_err("error reading max volt. rc=%d\n", rc);
- goto error;
- }
- mp->vreg_config[i].max_voltage = tmp;
-
- rc = of_property_read_u32(supply_node,
- "qcom,supply-enable-load", &tmp);
- if (rc) {
- pr_err("error reading enable load. rc=%d\n", rc);
- goto error;
- }
- mp->vreg_config[i].enable_load = tmp;
-
- rc = of_property_read_u32(supply_node,
- "qcom,supply-disable-load", &tmp);
- if (rc) {
- pr_err("error reading disable load. rc=%d\n", rc);
- goto error;
- }
- mp->vreg_config[i].disable_load = tmp;
-
- rc = of_property_read_u32(supply_node,
- "qcom,supply-pre-on-sleep", &tmp);
- if (rc)
- pr_debug("error reading supply pre sleep value.
rc=%d\n",
- rc);
-
- mp->vreg_config[i].pre_on_sleep = (!rc ? tmp : 0);
-
- rc = of_property_read_u32(supply_node,
- "qcom,supply-pre-off-sleep", &tmp);
- if (rc)
- pr_debug("error reading supply pre sleep value.
rc=%d\n",
- rc);
-
- mp->vreg_config[i].pre_off_sleep = (!rc ? tmp : 0);
-
- rc = of_property_read_u32(supply_node,
- "qcom,supply-post-on-sleep", &tmp);
- if (rc)
- pr_debug("error reading supply post sleep value.
rc=%d\n",
- rc);
-
- mp->vreg_config[i].post_on_sleep = (!rc ?
[DPU PATCH 11/11] drm/msm/dpu: move dpu_power_handle to dpu folder
Now, since dpu_power_handle manages only bus scaling
and power enable/disable notifications which are restricted
to dpu driver, move dpu_power_handle to dpu folder.
Signed-off-by: Rajesh Yadav
---
drivers/gpu/drm/msm/Makefile | 2 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c | 1 -
drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c| 5 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 7 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h | 2 +
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 1 -
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 39 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 1 +
drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.c | 694 +++
drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.h | 288 ++
drivers/gpu/drm/msm/dpu_power_handle.c | 694 ---
drivers/gpu/drm/msm/dpu_power_handle.h | 288 --
drivers/gpu/drm/msm/msm_drv.c| 9 -
drivers/gpu/drm/msm/msm_drv.h| 4 -
14 files changed, 1014 insertions(+), 1021 deletions(-)
create mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.c
create mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.h
delete mode 100644 drivers/gpu/drm/msm/dpu_power_handle.c
delete mode 100644 drivers/gpu/drm/msm/dpu_power_handle.h
diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index d9826c1..f578d5a 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -82,10 +82,10 @@ msm-y := \
disp/dpu1/dpu_rm.o \
disp/dpu1/dpu_vbif.o \
disp/dpu1/dpu_mdss.o \
+ disp/dpu1/dpu_power_handle.o \
dpu_dbg.o \
dpu_io_util.o \
dpu_dbg_evtlog.o \
- dpu_power_handle.o \
msm_prop.o \
msm_atomic.o \
msm_debugfs.o \
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c
index 5c5cc56..33ab2ac 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c
@@ -18,7 +18,6 @@
#include
#include "dpu_core_irq.h"
-#include "dpu_power_handle.h"
/**
* dpu_core_irq_callback_handler - dispatch core interrupts
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
index e2e7c06..18da169 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
@@ -257,7 +257,6 @@ static void _dpu_core_perf_crtc_update_bus(struct dpu_kms
*kms,
= dpu_crtc_get_client_type(crtc);
struct drm_crtc *tmp_crtc;
struct dpu_crtc_state *dpu_cstate;
- struct msm_drm_private *priv = kms->dev->dev_private;
drm_for_each_crtc(tmp_crtc, crtc->dev) {
if (_dpu_core_perf_crtc_is_power_on(tmp_crtc) &&
@@ -287,7 +286,7 @@ static void _dpu_core_perf_crtc_update_bus(struct dpu_kms
*kms,
switch (curr_client_type) {
case NRT_CLIENT:
- dpu_power_data_bus_set_quota(&priv->phandle, kms->core_client,
+ dpu_power_data_bus_set_quota(&kms->phandle, kms->core_client,
DPU_POWER_HANDLE_DATA_BUS_CLIENT_NRT,
bus_id, bus_ab_quota, bus_ib_quota);
DPU_DEBUG("client:%s bus_id=%d ab=%llu ib=%llu\n", "nrt",
@@ -295,7 +294,7 @@ static void _dpu_core_perf_crtc_update_bus(struct dpu_kms
*kms,
break;
case RT_CLIENT:
- dpu_power_data_bus_set_quota(&priv->phandle, kms->core_client,
+ dpu_power_data_bus_set_quota(&kms->phandle, kms->core_client,
DPU_POWER_HANDLE_DATA_BUS_CLIENT_RT,
bus_id, bus_ab_quota, bus_ib_quota);
DPU_DEBUG("client:%s bus_id=%d ab=%llu ib=%llu\n", "rt",
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index e2d2e32..99c5e75 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -598,6 +598,7 @@ static void dpu_crtc_destroy(struct drm_crtc *crtc)
_dpu_crtc_destroy_dest_scaler(dpu_crtc);
_dpu_crtc_deinit_events(dpu_crtc);
+ dpu_crtc->phandle = NULL;
drm_crtc_cleanup(crtc);
mutex_destroy(&dpu_crtc->crtc_lock);
@@ -2572,7 +2573,7 @@ static void dpu_crtc_disable(struct drm_crtc *crtc)
}
if (dpu_crtc->power_event)
- dpu_power_handle_unregister_event(&priv->phandle,
+ dpu_power_handle_unregister_event(dpu_crtc->phandle,
dpu_crtc->power_event);
@@ -2643,7 +2644,7 @@ static void dpu_crtc_enable(struct drm_crtc *crtc,
mutex_unlock(&dpu_crtc->crtc_lock);
dpu_crtc->power_event = dpu_power_handle_register_event(
- &priv->phandle,
+
[DPU PATCH 09/11] drm/msm/dp: remove dpu_power_handle calls from dp driver
DP driver was dependent on dpu_power_handle for MDSS
common clocks and gdsc (main power supply).
The common clocks and power is managed by MDSS top
wrapper device now which is parent of all sub-devices
like DP device.
For same reason, clock and power management code is
removed from dpu_power_handle. Hence, remove the
dpu_power_handle calls from dp driver.
Signed-off-by: Rajesh Yadav
---
drivers/gpu/drm/msm/dp/dp_power.c | 32 +---
drivers/gpu/drm/msm/dp/dp_power.h | 4 +---
2 files changed, 2 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_power.c
b/drivers/gpu/drm/msm/dp/dp_power.c
index f6e341b..2a85b38 100644
--- a/drivers/gpu/drm/msm/dp/dp_power.c
+++ b/drivers/gpu/drm/msm/dp/dp_power.c
@@ -26,8 +26,6 @@ struct dp_power_private {
struct clk *pixel_parent;
struct dp_power dp_power;
- struct dpu_power_client *dp_core_client;
- struct dpu_power_handle *phandle;
bool core_clks_on;
bool link_clks_on;
@@ -410,8 +408,7 @@ static int dp_power_config_gpios(struct dp_power_private
*power, bool flip,
return 0;
}
-static int dp_power_client_init(struct dp_power *dp_power,
- struct dpu_power_handle *phandle)
+static int dp_power_client_init(struct dp_power *dp_power)
{
int rc = 0;
struct dp_power_private *power;
@@ -436,19 +433,8 @@ static int dp_power_client_init(struct dp_power *dp_power,
goto error_clk;
}
- power->phandle = phandle;
- snprintf(dp_client_name, DP_CLIENT_NAME_SIZE, "dp_core_client");
- power->dp_core_client = dpu_power_client_create(phandle,
- dp_client_name);
- if (IS_ERR_OR_NULL(power->dp_core_client)) {
- pr_err("[%s] client creation failed for DP", dp_client_name);
- rc = -EINVAL;
- goto error_client;
- }
return 0;
-error_client:
- dp_power_clk_init(power, false);
error_clk:
dp_power_regulator_deinit(power);
error_power:
@@ -466,7 +452,6 @@ static void dp_power_client_deinit(struct dp_power
*dp_power)
power = container_of(dp_power, struct dp_power_private, dp_power);
- dpu_power_client_destroy(power->phandle, power->dp_core_client);
dp_power_clk_init(power, false);
dp_power_regulator_deinit(power);
}
@@ -521,13 +506,6 @@ static int dp_power_init(struct dp_power *dp_power, bool
flip)
goto err_gpio;
}
- rc = dpu_power_resource_enable(power->phandle,
- power->dp_core_client, true);
- if (rc) {
- pr_err("Power resource enable failed\n");
- goto err_dpu_power;
- }
-
rc = dp_power_clk_enable(dp_power, DP_CORE_PM, true);
if (rc) {
pr_err("failed to enable DP core clocks\n");
@@ -537,8 +515,6 @@ static int dp_power_init(struct dp_power *dp_power, bool
flip)
return 0;
err_clk:
- dpu_power_resource_enable(power->phandle, power->dp_core_client, false);
-err_dpu_power:
dp_power_config_gpios(power, flip, false);
err_gpio:
dp_power_pinctrl_set(power, false);
@@ -562,12 +538,6 @@ static int dp_power_deinit(struct dp_power *dp_power)
power = container_of(dp_power, struct dp_power_private, dp_power);
dp_power_clk_enable(dp_power, DP_CORE_PM, false);
- rc = dpu_power_resource_enable(power->phandle,
- power->dp_core_client, false);
- if (rc) {
- pr_err("Power resource enable failed, rc=%d\n", rc);
- goto exit;
- }
dp_power_config_gpios(power, false, false);
dp_power_pinctrl_set(power, false);
dp_power_regulator_ctrl(power, false);
diff --git a/drivers/gpu/drm/msm/dp/dp_power.h
b/drivers/gpu/drm/msm/dp/dp_power.h
index 84fe01d..d9dab72 100644
--- a/drivers/gpu/drm/msm/dp/dp_power.h
+++ b/drivers/gpu/drm/msm/dp/dp_power.h
@@ -16,7 +16,6 @@
#define _DP_POWER_H_
#include "dp_parser.h"
-#include "dpu_power_handle.h"
/**
* sruct dp_power - DisplayPort's power related data
@@ -32,8 +31,7 @@ struct dp_power {
int (*clk_enable)(struct dp_power *power, enum dp_pm_type pm_type,
bool enable);
int (*set_pixel_clk_parent)(struct dp_power *power);
- int (*power_client_init)(struct dp_power *power,
- struct dpu_power_handle *phandle);
+ int (*power_client_init)(struct dp_power *power);
void (*power_client_deinit)(struct dp_power *power);
};
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 00/13] *** per vm lru ***
On 2018年05月10日 13:07, Zhang, Jerry (Junwei) wrote: On 05/09/2018 02:45 PM, Chunming Zhou wrote: move implemenation from ttm to amdgpu driver. (suggested by Christian) per-vm-lru is because of per-vm-bo, which has no chance to refresh lru, the nagtive effect is game performance isn't stable. so all per-vm-bo should have a default order, every per-vm-bo has its priority, relying on its creation index. When doing CS, if any normal bo is used, then all per-vm-bo should be used, so per-vm-bo prioirty >= normal bo priority. Above is per-vm-lru starting point. How do you think that we create the per vm bo as priority 1 and kernel bo as priority 2 accordingly? Yeah, then how to fix per-vm-bo order? I think we need set priority for every per-vm-bo. Because of lacking bo list, the per-vm-bo lru can only depend on priority. Regards, David Zhou Will that help to make some improvement? Jerry Chunming Zhou (13): ttm: abstruct evictable bo ttm: allow driver has own lru policy drm/amdgpu: add lru backend for amdgpu driver drm/amdgpu: init/fini vm lru drm/amdgpu: pass vm lru to buffer object drm/amdgpu: add amdgpu lru implementation drm/ttm: export ttm_bo_ref_bug drm/amdgpu: use RB tree instead of link list drm/amdgpu: add bo index counter drm/amdgpu: bulk move per vm bo ttm: export ttm_transfered_destroy drm/amdgpu: transferred bo doesn't use vm lru drm/amdgpu: free vm lru when vm fini drivers/gpu/drm/amd/amdgpu/amdgpu.h | 5 +- drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 1 + drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 14 +- drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 9 +- drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 4 + drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 7 + drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 242 - drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h | 25 +++ drivers/gpu/drm/ttm/ttm_bo.c | 92 +++ drivers/gpu/drm/ttm/ttm_bo_util.c | 3 +- include/drm/ttm/ttm_bo_driver.h | 52 +++ 12 files changed, 419 insertions(+), 37 deletions(-) ___ amd-gfx mailing list amd-...@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] drm/dp: add module parameter for the dpcd access max retries
On Wed, May 09, 2018 at 12:28:15PM +0300, Jani Nikula wrote: > On Wed, 09 May 2018, Feng Tang wrote: > > On Wed, May 09, 2018 at 10:53:53AM +0300, Jani Nikula wrote: > >> On Wed, 09 May 2018, Feng Tang wrote: > >> > On Tue, May 08, 2018 at 10:30:19PM +0300, Jani Nikula wrote: > >> >> On Wed, 09 May 2018, Feng Tang wrote: > >> >> >> Well if it's edp probing, then atm we do need to block since we have > >> >> >> no support for panel hotplugging. And userspace generally no > >> >> >> expectations that built-in panels come&go. async_synchronize_full > >> >> >> making our fbdev code less async than desired is kinda a different > >> >> >> story I think here. First step would be trying to figure out why we > >> >> >> even bother with edp probing on this platform, when the thing isn't > >> >> >> there. Sounds like broken VBT. > >> >> > > >> >> > Hi Daniel, > >> >> > > >> >> > Here are some of the VBT and DPCD related logs on my A3900 (bxt + > >> >> > GEN9 LP) > >> >> > based NUC. but I don't have the knowledge to tell if the VBT is > >> >> > broken :) > >> >> > >> >> Please run current upstream drm-tip when you're suggesting changes to > >> >> upstream code. Looks like you're running at most v4.14. This can't be > >> >> emphasized enough. We can't and won't merge the changes unless they make > >> >> sense with current code. > >> > > >> > Yes, I understand, the patch posted was created right after git-pulling > >> > Linus' tree, and back-ported to test with 4.14 kernel. > >> > > >> >> > >> >> As to vbt, please send me /sys/kernel/debug/dri/0/i915_vbt. > >> > > >> > Sure. as attached > >> > >> Your VBT claims the device has an eDP panel. Does it have one or not? > > > > After asking around, our platform (BXT NUC) does have a eDP interface > > (someone > > has tested with a eDP screen), but most of our platforms are connected > > with 2 HDMI LCD monitors. > > Sounds like you should have a different VBT for the cases where you ship > with/without eDP connected. As you've noticed, we generally try pretty Yep, this is a good idea. Currently I'm not able to change VBT, so I hacked the code to simulating a no-eDP VBT like: --- a/drivers/gpu/drm/i915/intel_bios.c +++ b/drivers/gpu/drm/i915/intel_bios.c @@ -1261,7 +1261,8 @@ static void parse_ddi_port(struct drm_i915_private *dev_priv, enum port port, is_crt = child->device_type & DEVICE_TYPE_ANALOG_OUTPUT; is_hdmi = is_dvi && (child->device_type & DEVICE_TYPE_NOT_HDMI_OUTPUT) == 0; - is_edp = is_dp && (child->device_type & DEVICE_TYPE_INTERNAL_CONNECTOR); + is_edp = 0; And it does cut the boottime a lot!! as avoiding the dpcd access. And later i915_hpd_poll_init_work() will still call intel_dp_detect() and call the time-eater drm_dp_dpcd_access() finally, but the situation is better as it runs in an async way at this point. Thanks, Feng ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 105684] Loading amdgpu hits general protection fault: 0000 [#1] SMP NOPTI
https://bugs.freedesktop.org/show_bug.cgi?id=105684 --- Comment #21 from jian-h...@endlessm.com --- For the question "What physical display connectors are on the board?" There are one HDMI and one VGA connectors on this mother board. I have tried both connectors and both of them hit this bug. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 105684] Loading amdgpu hits general protection fault: 0000 [#1] SMP NOPTI
https://bugs.freedesktop.org/show_bug.cgi?id=105684 --- Comment #22 from jian-h...@endlessm.com --- Created attachment 139462 --> https://bugs.freedesktop.org/attachment.cgi?id=139462&action=edit dmesg of loading amdgpu module with patch 218586 I tried git://people.freedesktop.org/~agd5f/linux on amd-staging-drm-next branch. The last commit is "905aa01b240f9216b6dbba3226bf10b2d96eebb7 drm/amd/display: clean up assignment of amdgpu_crtc" which contains the patch https://patchwork.freedesktop.org/patch/218586/ . However, the system still hung up with the following error. The attachment is the full dmesg. [ 45.184948] amdgpu: [powerplay] dpm has been enabled [ 45.185017] general protection fault: [#1] SMP NOPTI [ 45.185021] Modules linked in: amdkfd amd_iommu_v2 amdgpu(+) chash gpu_sched ttm drm_kms_helper drm i2c_algo_bit fb_sys_fops syscopyarea sysfillrect sysimgblt efi_pstore cmac bnep edac_mce_amd arc4 btusb snd_hda_codec_realtek snd_hda_codec_hdmi kvm_amd btrtl btbcm ccp btintel kvm bluetooth snd_hda_codec_generic snd_hda_intel snd_hda_codec irqbypass crct10dif_pclmul crc32_pclmul snd_hda_core snd_hwdep ghash_clmulni_intel pcbc input_leds aesni_intel aes_x86_64 snd_pcm ecdh_generic crypto_simd wmi_bmof sparse_keymap snd_timer glue_helper r8169 cryptd snd soundcore mii ahci ath10k_pci ath10k_core psmouse ath mac80211 cfg80211 libahci shpchp wmi i2c_piix4 tpm_crb mac_hid zram ip_tables x_tables hid_generic usbhid hid serio_raw video uas usb_storage [ 45.185098] CPU: 4 PID: 848 Comm: modprobe Not tainted 4.16.0-rc7+ #1 [ 45.185102] Hardware name: Acer Aspire TC-380/Aspire TC-380, BIOS D05 02/01/2018 [ 45.185113] RIP: 0010:prefetch_freepointer+0x15/0x30 [ 45.185117] RSP: 0018:afb583d97730 EFLAGS: 00010206 [ 45.185121] RAX: RBX: 9c429b792400 RCX: 0cc8 [ 45.185124] RDX: 0cc7 RSI: 7c4c9a908a85a5b1 RDI: 9c42bf006e80 [ 45.185128] RBP: afb583d97730 R08: 9c42bf727160 R09: c08c9d31 [ 45.185131] R10: afb583d97738 R11: R12: 014080c0 [ 45.185135] R13: 9c42bf006e80 R14: 9c429b792400 R15: 9c42bf006e80 [ 45.185139] FS: 7f43bfa74700() GS:9c42bf70() knlGS: [ 45.185143] CS: 0010 DS: ES: CR0: 80050033 [ 45.185146] CR2: 7f65fb3c1740 CR3: 0007db678000 CR4: 003406e0 [ 45.185150] Call Trace: [ 45.185157] kmem_cache_alloc_trace+0xa5/0x1b0 [ 45.185259] ? dcn10_create_resource_pool+0x41/0x9d0 [amdgpu] [ 45.185345] dcn10_create_resource_pool+0x41/0x9d0 [amdgpu] [ 45.185430] ? dal_aux_engine_construct+0x12/0x30 [amdgpu] [ 45.185511] ? dal_aux_engine_dce110_create+0x3f/0x80 [amdgpu] [ 45.185593] dc_create_resource_pool+0x40/0x170 [amdgpu] [ 45.185598] ? _cond_resched+0x1a/0x50 [ 45.185602] ? __kmalloc+0x1d5/0x210 [ 45.185685] ? dal_gpio_service_create+0x97/0x110 [amdgpu] [ 45.185765] dc_create+0x22f/0x660 [amdgpu] [ 45.185848] dm_hw_init+0xc3/0x250 [amdgpu] [ 45.185897] amdgpu_device_init+0x13a6/0x1470 [amdgpu] [ 45.185947] amdgpu_driver_load_kms+0x8b/0x2c0 [amdgpu] [ 45.185966] drm_dev_register+0x146/0x1d0 [drm] [ 45.186010] amdgpu_pci_probe+0x13f/0x1f0 [amdgpu] [ 45.186015] local_pci_probe+0x45/0xa0 [ 45.186018] pci_device_probe+0x109/0x1b0 [ 45.186022] driver_probe_device+0x2b2/0x490 [ 45.186024] __driver_attach+0xdf/0xf0 [ 45.186026] ? driver_probe_device+0x490/0x490 [ 45.186030] bus_for_each_dev+0x64/0xb0 [ 45.186032] ? kmem_cache_alloc_trace+0x1a4/0x1b0 [ 45.186034] driver_attach+0x1e/0x20 [ 45.186037] bus_add_driver+0x170/0x260 [ 45.186039] driver_register+0x60/0xe0 [ 45.186042] ? 0xc0a26000 [ 45.186045] __pci_register_driver+0x5a/0x60 [ 45.186087] amdgpu_init+0x7a/0x89 [amdgpu] [ 45.186091] do_one_initcall+0x52/0x193 [ 45.186094] ? __vunmap+0x81/0xb0 [ 45.186096] ? _cond_resched+0x1a/0x50 [ 45.186098] ? kmem_cache_alloc_trace+0xa5/0x1b0 [ 45.186102] ? do_init_module+0x27/0x219 [ 45.186104] do_init_module+0x5f/0x219 [ 45.186106] load_module+0x25b5/0x2dd0 [ 45.186111] ? ima_post_read_file+0x83/0xa0 [ 45.186114] SYSC_finit_module+0xe5/0x120 [ 45.186117] ? SYSC_finit_module+0xe5/0x120 [ 45.186120] SyS_finit_module+0xe/0x10 [ 45.186122] do_syscall_64+0x6d/0x120 [ 45.186126] entry_SYSCALL_64_after_hwframe+0x3d/0xa2 [ 45.186128] RIP: 0033:0x7f43bf5b7229 [ 45.186130] RSP: 002b:7ffcd696fdf8 EFLAGS: 0246 ORIG_RAX: 0139 [ 45.186133] RAX: ffda RBX: 55974fddf420 RCX: 7f43bf5b7229 [ 45.186135] RDX: RSI: 55974ecf8638 RDI: 000d [ 45.186137] RBP: 55974ecf8638 R08: R09: [ 45.186139] R10: 000d R11: 0246 R12: [ 45.186141] R13: 55974fddf550 R14: 0004 R15: [ 45.186144] Code: 49 8b 74 24 60 48 c7 c7 f0
[PATCH v2 3/4] Documentation: bindings: add phy_config for Rockchip USB Type-C PHY
If want to do training outside DP Firmware, need phy voltage swing and pre_emphasis value. Signed-off-by: Lin Huang --- Changes in v2: - rebase Documentation/devicetree/bindings/phy/phy-rockchip-typec.txt | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/phy/phy-rockchip-typec.txt b/Documentation/devicetree/bindings/phy/phy-rockchip-typec.txt index 960da7f..eda26dd 100644 --- a/Documentation/devicetree/bindings/phy/phy-rockchip-typec.txt +++ b/Documentation/devicetree/bindings/phy/phy-rockchip-typec.txt @@ -17,7 +17,9 @@ Required properties: Optional properties: - extcon : extcon specifier for the Power Delivery - + - rockchip,phy_config : That's phy voltage swing and pre_emphasis +setting, if want to do dp training outside +dp firmware, need to add these value. Required nodes : a sub-node is required for each port the phy provides. The sub-node name is used to identify dp or usb3 port, and shall be the following entries: -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/2] gpu: drm/panel: Add DLC DLC0700YZG-1 panel
From: Philipp Zabel
This patch adds support for DLC DLC0700YZG-1 1024x600 LVDS panels
to the simple-panel driver.
Signed-off-by: Philipp Zabel
[m.fel...@pengutronix.de: fix typo in compatible dt-binding]
Signed-off-by: Marco Felsch
---
.../display/panel/dlc,dlc0700yzg-1.txt| 7
drivers/gpu/drm/panel/panel-simple.c | 32 +++
2 files changed, 39 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/dlc,dlc0700yzg-1.txt
diff --git
a/Documentation/devicetree/bindings/display/panel/dlc,dlc0700yzg-1.txt
b/Documentation/devicetree/bindings/display/panel/dlc,dlc0700yzg-1.txt
new file mode 100644
index ..3cfafe26eb35
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/dlc,dlc0700yzg-1.txt
@@ -0,0 +1,7 @@
+DLC Display Co. DLC0700YZG-1 7.0" WSVGA TFT LCD panel
+
+Required properties:
+- compatible: should be "dlc,dlc0700yzg-1"
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index cbf1ab404ee7..a916754b2afa 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -857,6 +857,35 @@ static const struct panel_desc chunghwa_claa101wb01 = {
},
};
+static const struct display_timing dlc_dlc0700yzg_1_timing = {
+ .pixelclock = { 4500, 5120, 5700 },
+ .hactive = { 1024, 1024, 1024 },
+ .hfront_porch = { 100, 106, 113 },
+ .hback_porch = { 100, 106, 113 },
+ .hsync_len = { 100, 108, 114 },
+ .vactive = { 600, 600, 600 },
+ .vfront_porch = { 8, 11, 15 },
+ .vback_porch = { 8, 11, 15 },
+ .vsync_len = { 9, 13, 15 },
+ .flags = DISPLAY_FLAGS_DE_HIGH,
+};
+
+static const struct panel_desc dlc_dlc0700yzg_1 = {
+ .timings = &dlc_dlc0700yzg_1_timing,
+ .num_timings = 1,
+ .bpc = 6,
+ .size = {
+ .width = 154,
+ .height = 86,
+ },
+ .delay = {
+ .prepare = 30,
+ .enable = 200,
+ .disable = 200,
+ },
+ .bus_format = MEDIA_BUS_FMT_RGB666_1X7X3_SPWG,
+};
+
static const struct drm_display_mode edt_et057090dhu_mode = {
.clock = 25175,
.hdisplay = 640,
@@ -2124,6 +2153,9 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "chunghwa,claa101wb01",
.data = &chunghwa_claa101wb01
+ }, {
+ .compatible = "dlc,dlc0700yzg-1",
+ .data = &dlc_dlc0700yzg_1,
}, {
.compatible = "edt,et057090dhu",
.data = &edt_et057090dhu,
--
2.17.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V1 5/5] backlight: qcom-wled: Add auto string detection logic
On 2018-05-07 23:40, Bjorn Andersson wrote:
On Thu 03 May 02:57 PDT 2018, Kiran Gunda wrote:
[..]
+
+#define WLED_AUTO_DETECT_OVP_COUNT 5
+#define WLED_AUTO_DETECT_CNT_DLY_USHZ /* 1 second */
+static bool wled_auto_detection_required(struct wled *wled)
So cfg.auto_detection_enabled is set, but we didn't have a fault during
wled_auto_detection_at_init(), which I presume indicates that the boot
loader configured the strings appropriately (or didn't enable the BL).
Then first time we try to enable the backlight we will hit the ovp irq,
which will enter here a few times to figure out that the strings are
incorrectly configured and then we will do the same thing that would
have been done if we probed with a fault.
This is convoluted!
If auto-detection is a feature allowing the developer to omit the
string
configuration then just do the auto detection explicitly in probe when
the developer did so and then never do it again.
As explained in the previous patch, the auto-detection is needed later,
because are also cases where one/more of the connected LED string of the
display-backlight is malfunctioning (because of damage) and requires the
damaged string to be turned off to prevent the complete panel and/or
board
from being damaged.
+{
+ s64 elapsed_time_us;
+
+ if (*wled->version == WLED_PM8941)
+ return false;
+ /*
+* Check if the OVP fault was an occasional one
+* or if it's firing continuously, the latter qualifies
+* for an auto-detection check.
+*/
+ if (!wled->auto_detection_ovp_count) {
+ wled->start_ovp_fault_time = ktime_get();
+ wled->auto_detection_ovp_count++;
+ } else {
+ elapsed_time_us = ktime_us_delta(ktime_get(),
+wled->start_ovp_fault_time);
+ if (elapsed_time_us > WLED_AUTO_DETECT_CNT_DLY_US)
+ wled->auto_detection_ovp_count = 0;
+ else
+ wled->auto_detection_ovp_count++;
+
+ if (wled->auto_detection_ovp_count >=
+ WLED_AUTO_DETECT_OVP_COUNT) {
+ wled->auto_detection_ovp_count = 0;
+ return true;
+ }
+ }
+
+ return false;
+}
+
+static int wled_auto_detection_at_init(struct wled *wled)
+{
+ int rc;
+ u32 fault_status = 0, rt_status = 0;
+
+ if (*wled->version == WLED_PM8941)
+ return 0;
cfg.auto_detection_enabled will be false in this case, so there's no
need for the extra check.
Ok. I will remove it in the next series.
+
+ if (!wled->cfg.auto_detection_enabled)
+ return 0;
+
+ rc = regmap_read(wled->regmap,
+wled->ctrl_addr + WLED3_CTRL_REG_INT_RT_STS,
+&rt_status);
+ if (rc < 0) {
+ pr_err("Failed to read RT status rc=%d\n", rc);
+ return rc;
+ }
+
+ rc = regmap_read(wled->regmap,
+wled->ctrl_addr + WLED3_CTRL_REG_FAULT_STATUS,
+&fault_status);
+ if (rc < 0) {
+ pr_err("Failed to read fault status rc=%d\n", rc);
+ return rc;
+ }
+
+ if ((rt_status & WLED3_CTRL_REG_OVP_FAULT_STATUS) ||
+ (fault_status & WLED3_CTRL_REG_OVP_FAULT_BIT)) {
So this would only happen if the boot loader set an invalid string
configuration, as we have yet to enable the module here?
Yes.
+ mutex_lock(&wled->lock);
+ rc = wled_auto_string_detection(wled);
+ if (!rc)
+ wled->auto_detection_done = true;
+ mutex_unlock(&wled->lock);
+ }
+
+ return rc;
+}
+
+static void handle_ovp_fault(struct wled *wled)
+{
+ if (!wled->cfg.auto_detection_enabled)
As this is the only reason for requesting the ovp_irq, how about just
not requesting it in this case?
This is also needed for information purpose if there is any other reason
and also discussing with HW systems what needs to do if the OVP keep on
triggering.
+ return;
+
+ mutex_lock(&wled->lock);
+ if (wled->ovp_irq > 0 && !wled->ovp_irq_disabled) {
The logic here is unnecessary, the only way handle_ovp_fault() is ever
executed is if wled_ovp_irq_handler() was called, which is a really
good
indication that ovp_irq is valid and !ovp_irq_disabled. So this is
always going to be entered.
Ok. I will remove this logic in the next series.
+ disable_irq_nosync(wled->ovp_irq);
+ wled->ovp_irq_disabled = true;
+ }
+
+ if (wled_auto_detection_required(wled))
+ wled_auto_string_detection(wled);
+
+ if (wled->ovp_irq > 0 && wled->ovp_irq_disabled) {
Again, ovp_irq is valid and we entered the function with either
ovp_irq_disabled = true due to some bug or
[PATCH v2 2/4] phy: rockchip-typec: support variable phy config value
the phy config values used to fix in dp firmware, but some boards
need change these values to do training and get the better eye diagram
result. So support that in phy driver.
Signed-off-by: Chris Zhong
Signed-off-by: Lin Huang
---
Changes in v2:
- update patch following Enric suggest
drivers/phy/rockchip/phy-rockchip-typec.c | 284 +++---
include/soc/rockchip/rockchip_phy_typec.h | 64 +++
2 files changed, 250 insertions(+), 98 deletions(-)
create mode 100644 include/soc/rockchip/rockchip_phy_typec.h
diff --git a/drivers/phy/rockchip/phy-rockchip-typec.c
b/drivers/phy/rockchip/phy-rockchip-typec.c
index 76a4b58..86cbd6c 100644
--- a/drivers/phy/rockchip/phy-rockchip-typec.c
+++ b/drivers/phy/rockchip/phy-rockchip-typec.c
@@ -63,6 +63,7 @@
#include
#include
+#include
#define CMN_SSM_BANDGAP(0x21 << 2)
#define CMN_SSM_BIAS (0x22 << 2)
@@ -323,21 +324,29 @@
* clock 0: PLL 0 div 1
* clock 1: PLL 1 div 2
*/
-#define CLK_PLL_CONFIG 0X30
+#define CLK_PLL1_DIV1 0x20
+#define CLK_PLL1_DIV2 0x30
#define CLK_PLL_MASK 0x33
#define CMN_READY BIT(0)
+#define DP_PLL_CLOCK_ENABLE_ACKBIT(3)
#define DP_PLL_CLOCK_ENABLEBIT(2)
+#define DP_PLL_ENABLE_ACK BIT(1)
#define DP_PLL_ENABLE BIT(0)
#define DP_PLL_DATA_RATE_RBR ((2 << 12) | (4 << 8))
#define DP_PLL_DATA_RATE_HBR ((2 << 12) | (4 << 8))
#define DP_PLL_DATA_RATE_HBR2 ((1 << 12) | (2 << 8))
+#define DP_PLL_DATA_RATE_MASK 0xff00
-#define DP_MODE_A0 BIT(4)
-#define DP_MODE_A2 BIT(6)
-#define DP_MODE_ENTER_A0 0xc101
-#define DP_MODE_ENTER_A2 0xc104
+#define DP_MODE_MASK 0xf
+#define DP_MODE_ENTER_A0 BIT(0)
+#define DP_MODE_ENTER_A2 BIT(2)
+#define DP_MODE_ENTER_A3 BIT(3)
+#define DP_MODE_A0_ACK BIT(4)
+#define DP_MODE_A2_ACK BIT(6)
+#define DP_MODE_A3_ACK BIT(7)
+#define DP_LINK_RESET_DEASSERTED BIT(8)
#define PHY_MODE_SET_TIMEOUT 10
@@ -349,51 +358,7 @@
#define MODE_DFP_USB BIT(1)
#define MODE_DFP_DPBIT(2)
-struct usb3phy_reg {
- u32 offset;
- u32 enable_bit;
- u32 write_enable;
-};
-
-/**
- * struct rockchip_usb3phy_port_cfg: usb3-phy port configuration.
- * @reg: the base address for usb3-phy config.
- * @typec_conn_dir: the register of type-c connector direction.
- * @usb3tousb2_en: the register of type-c force usb2 to usb2 enable.
- * @external_psm: the register of type-c phy external psm clock.
- * @pipe_status: the register of type-c phy pipe status.
- * @usb3_host_disable: the register of type-c usb3 host disable.
- * @usb3_host_port: the register of type-c usb3 host port.
- * @uphy_dp_sel: the register of type-c phy DP select control.
- */
-struct rockchip_usb3phy_port_cfg {
- unsigned int reg;
- struct usb3phy_reg typec_conn_dir;
- struct usb3phy_reg usb3tousb2_en;
- struct usb3phy_reg external_psm;
- struct usb3phy_reg pipe_status;
- struct usb3phy_reg usb3_host_disable;
- struct usb3phy_reg usb3_host_port;
- struct usb3phy_reg uphy_dp_sel;
-};
-
-struct rockchip_typec_phy {
- struct device *dev;
- void __iomem *base;
- struct extcon_dev *extcon;
- struct regmap *grf_regs;
- struct clk *clk_core;
- struct clk *clk_ref;
- struct reset_control *uphy_rst;
- struct reset_control *pipe_rst;
- struct reset_control *tcphy_rst;
- const struct rockchip_usb3phy_port_cfg *port_cfgs;
- /* mutex to protect access to individual PHYs */
- struct mutex lock;
-
- bool flip;
- u8 mode;
-};
+#define DP_DEFAULT_RATE162000
struct phy_reg {
u16 value;
@@ -417,15 +382,15 @@ struct phy_reg usb3_pll_cfg[] = {
{ 0x8, CMN_DIAG_PLL0_LF_PROG },
};
-struct phy_reg dp_pll_cfg[] = {
+struct phy_reg dp_pll_rbr_cfg[] = {
{ 0xf0, CMN_PLL1_VCOCAL_INIT },
{ 0x18, CMN_PLL1_VCOCAL_ITER },
{ 0x30b9, CMN_PLL1_VCOCAL_START },
- { 0x21c,CMN_PLL1_INTDIV },
+ { 0x87, CMN_PLL1_INTDIV },
{ 0,CMN_PLL1_FRACDIV },
- { 0x5, CMN_PLL1_HIGH_THR },
- { 0x35, CMN_PLL1_SS_CTRL1 },
- { 0x7f1e, CMN_PLL1_SS_CTRL2 },
+ { 0x22, CMN_PLL1_HIGH_THR },
+ { 0x8000, CMN_PLL1_SS_CTRL1 },
+ { 0,CMN_PLL1_SS_CTRL2 },
{ 0x20, CMN_PLL1_DSM_DIAG },
{ 0,CMN_PLLSM1_USER_DEF_CTRL },
{ 0,CMN_DIAG_PLL1_OVRD },
@@ -436,9 +401,52 @@ struct phy_reg dp_pll_cfg[] = {
{ 0x8, CMN_DIA
[PATCH v2 2/2] gpu: drm/panel: Add DLC DLC0700YZG-1 panel
From: Philipp Zabel
This patch adds support for DLC DLC0700YZG-1 1024x600 LVDS panels
to the simple-panel driver.
Signed-off-by: Philipp Zabel
[m.fel...@pengutronix.de: fix typo in compatible dt-binding]
Signed-off-by: Marco Felsch
---
.../display/panel/dlc,dlc0700yzg-1.txt| 7
drivers/gpu/drm/panel/panel-simple.c | 32 +++
2 files changed, 39 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/dlc,dlc0700yzg-1.txt
diff --git
a/Documentation/devicetree/bindings/display/panel/dlc,dlc0700yzg-1.txt
b/Documentation/devicetree/bindings/display/panel/dlc,dlc0700yzg-1.txt
new file mode 100644
index ..3cfafe26eb35
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/dlc,dlc0700yzg-1.txt
@@ -0,0 +1,7 @@
+DLC Display Co. DLC0700YZG-1 7.0" WSVGA TFT LCD panel
+
+Required properties:
+- compatible: should be "dlc,dlc0700yzg-1"
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index cbf1ab404ee7..a916754b2afa 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -857,6 +857,35 @@ static const struct panel_desc chunghwa_claa101wb01 = {
},
};
+static const struct display_timing dlc_dlc0700yzg_1_timing = {
+ .pixelclock = { 4500, 5120, 5700 },
+ .hactive = { 1024, 1024, 1024 },
+ .hfront_porch = { 100, 106, 113 },
+ .hback_porch = { 100, 106, 113 },
+ .hsync_len = { 100, 108, 114 },
+ .vactive = { 600, 600, 600 },
+ .vfront_porch = { 8, 11, 15 },
+ .vback_porch = { 8, 11, 15 },
+ .vsync_len = { 9, 13, 15 },
+ .flags = DISPLAY_FLAGS_DE_HIGH,
+};
+
+static const struct panel_desc dlc_dlc0700yzg_1 = {
+ .timings = &dlc_dlc0700yzg_1_timing,
+ .num_timings = 1,
+ .bpc = 6,
+ .size = {
+ .width = 154,
+ .height = 86,
+ },
+ .delay = {
+ .prepare = 30,
+ .enable = 200,
+ .disable = 200,
+ },
+ .bus_format = MEDIA_BUS_FMT_RGB666_1X7X3_SPWG,
+};
+
static const struct drm_display_mode edt_et057090dhu_mode = {
.clock = 25175,
.hdisplay = 640,
@@ -2124,6 +2153,9 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "chunghwa,claa101wb01",
.data = &chunghwa_claa101wb01
+ }, {
+ .compatible = "dlc,dlc0700yzg-1",
+ .data = &dlc_dlc0700yzg_1,
}, {
.compatible = "edt,et057090dhu",
.data = &edt_et057090dhu,
--
2.17.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] display: panel: Add AUO g070vvn01 display support (800x480)
Hi Rob, > On Tue, Apr 10, 2018 at 5:29 AM, Lukasz Majewski > wrote: > > This commit adds support for AUO's 7.0" display. > > > > Signed-off-by: Lukasz Majewski > > > > --- > > Changes for v2: > > - Add *.txt suffix to the auo,g070wn01 file > > - Remove not needed bus-format-override = "rgb565"; property > > --- > > .../bindings/display/panel/auo,g070vvn01.txt | 30 > > + > > drivers/gpu/drm/panel/panel-simple.c | 31 > > ++ 2 files changed, 61 insertions(+) create > > mode 100644 > > Documentation/devicetree/bindings/display/panel/auo,g070vvn01.txt > > Reviewed-by: Rob Herring Gentle ping on this patch It is almost month now... Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de pgpTKHf84_4uY.pgp Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 RESEND] display: panel: Add AUO g070vvn01 display support (800x480)
This commit adds support for AUO's 7.0" display.
Signed-off-by: Lukasz Majewski
---
.../bindings/display/panel/auo,g070vvn01 | 30 +
drivers/gpu/drm/panel/panel-simple.c | 31 ++
2 files changed, 61 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/auo,g070vvn01
diff --git a/Documentation/devicetree/bindings/display/panel/auo,g070vvn01
b/Documentation/devicetree/bindings/display/panel/auo,g070vvn01
new file mode 100644
index ..bd4017362094
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/auo,g070vvn01
@@ -0,0 +1,30 @@
+AU Optronics Corporation 7.0" FHD (800 x 480) TFT LCD panel
+
+Required properties:
+- compatible: should be "auo,g070vvn01"
+- backlight: phandle of the backlight device attached to the panel
+- power-supply: single regulator to provide the supply voltage
+
+Required nodes:
+- port: Parallel port mapping to connect this display
+
+This panel needs single power supply voltage. Its backlight is conntrolled
+via PWM signal.
+
+Example:
+
+
+Example device-tree definition when connected to iMX6Q based board
+
+ lcd_panel: lcd-panel {
+ compatible = "auo,g070vvn01";
+ backlight = <&backlight_lcd>;
+ bus-format-override = "rgb565";
+ power-supply = <®_display>;
+
+ port {
+ lcd_panel_in: endpoint {
+ remote-endpoint = <&lcd_display_out>;
+ };
+ };
+ };
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index cbf1ab404ee7..d9984bdb5bb5 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -581,6 +581,34 @@ static const struct panel_desc auo_b133htn01 = {
},
};
+static const struct display_timing auo_g070vvn01_timings = {
+ .pixelclock = { 3330, 34209000, 4500 },
+ .hactive = { 800, 800, 800 },
+ .hfront_porch = { 20, 40, 200 },
+ .hback_porch = { 87, 40, 1 },
+ .hsync_len = { 1, 48, 87 },
+ .vactive = { 480, 480, 480 },
+ .vfront_porch = { 5, 13, 200 },
+ .vback_porch = { 31, 31, 29 },
+ .vsync_len = { 1, 1, 3 },
+};
+
+static const struct panel_desc auo_g070vvn01 = {
+ .timings = &auo_g070vvn01_timings,
+ .num_timings = 1,
+ .bpc = 8,
+ .size = {
+ .width = 152,
+ .height = 91,
+ },
+ .delay = {
+ .prepare = 200,
+ .enable = 50,
+ .disable = 50,
+ .unprepare = 1000,
+ },
+};
+
static const struct drm_display_mode auo_g104sn02_mode = {
.clock = 4,
.hdisplay = 800,
@@ -2095,6 +2123,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "auo,b133xtn01",
.data = &auo_b133xtn01,
}, {
+ .compatible = "auo,g070vvn01",
+ .data = &auo_g070vvn01,
+ }, {
.compatible = "auo,g104sn02",
.data = &auo_g104sn02,
}, {
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/4] drm/rockchip: add transfer function for cdn-dp
From: Chris Zhong
We may support training outside firmware, so we need support
dpcd read/write to get the message or do some setting with
display.
Signed-off-by: Chris Zhong
Signed-off-by: Lin Huang
---
Changes in v2:
- update patch following Enric suggest
drivers/gpu/drm/rockchip/cdn-dp-core.c | 55
drivers/gpu/drm/rockchip/cdn-dp-core.h | 1 +
drivers/gpu/drm/rockchip/cdn-dp-reg.c | 67 ++
drivers/gpu/drm/rockchip/cdn-dp-reg.h | 14 ++-
4 files changed, 120 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c
b/drivers/gpu/drm/rockchip/cdn-dp-core.c
index c6fbdcd..cce64c1 100644
--- a/drivers/gpu/drm/rockchip/cdn-dp-core.c
+++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c
@@ -176,8 +176,8 @@ static int cdn_dp_get_sink_count(struct cdn_dp_device *dp,
u8 *sink_count)
u8 value;
*sink_count = 0;
- ret = cdn_dp_dpcd_read(dp, DP_SINK_COUNT, &value, 1);
- if (ret)
+ ret = drm_dp_dpcd_read(&dp->aux, DP_SINK_COUNT, &value, 1);
+ if (ret < 0)
return ret;
*sink_count = DP_GET_SINK_COUNT(value);
@@ -374,9 +374,9 @@ static int cdn_dp_get_sink_capability(struct cdn_dp_device
*dp)
if (!cdn_dp_check_sink_connection(dp))
return -ENODEV;
- ret = cdn_dp_dpcd_read(dp, DP_DPCD_REV, dp->dpcd,
- DP_RECEIVER_CAP_SIZE);
- if (ret) {
+ ret = drm_dp_dpcd_read(&dp->aux, DP_DPCD_REV, dp->dpcd,
+ sizeof(dp->dpcd));
+ if (ret < 0) {
DRM_DEV_ERROR(dp->dev, "Failed to get caps %d\n", ret);
return ret;
}
@@ -582,8 +582,8 @@ static bool cdn_dp_check_link_status(struct cdn_dp_device
*dp)
if (!port || !dp->link.rate || !dp->link.num_lanes)
return false;
- if (cdn_dp_dpcd_read(dp, DP_LANE0_1_STATUS, link_status,
-DP_LINK_STATUS_SIZE)) {
+ if (drm_dp_dpcd_read_link_status(&dp->aux, link_status) !=
+ DP_LINK_STATUS_SIZE) {
DRM_ERROR("Failed to get link status\n");
return false;
}
@@ -1012,6 +1012,40 @@ static int cdn_dp_pd_event(struct notifier_block *nb,
return NOTIFY_DONE;
}
+static ssize_t cdn_dp_aux_transfer(struct drm_dp_aux *aux,
+ struct drm_dp_aux_msg *msg)
+{
+ struct cdn_dp_device *dp = container_of(aux, struct cdn_dp_device, aux);
+ int ret;
+ u8 status;
+
+ switch (msg->request & ~DP_AUX_I2C_MOT) {
+ case DP_AUX_NATIVE_WRITE:
+ case DP_AUX_I2C_WRITE:
+ case DP_AUX_I2C_WRITE_STATUS_UPDATE:
+ ret = cdn_dp_dpcd_write(dp, msg->address, msg->buffer,
+ msg->size);
+ break;
+ case DP_AUX_NATIVE_READ:
+ case DP_AUX_I2C_READ:
+ ret = cdn_dp_dpcd_read(dp, msg->address, msg->buffer,
+ msg->size);
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ status = cdn_dp_get_aux_status(dp);
+ if (status == AUX_STATUS_ACK)
+ msg->reply = DP_AUX_NATIVE_REPLY_ACK;
+ else if (status == AUX_STATUS_NACK)
+ msg->reply = DP_AUX_NATIVE_REPLY_NACK;
+ else if (status == AUX_STATUS_DEFER)
+ msg->reply = DP_AUX_NATIVE_REPLY_DEFER;
+
+ return ret;
+}
+
static int cdn_dp_bind(struct device *dev, struct device *master, void *data)
{
struct cdn_dp_device *dp = dev_get_drvdata(dev);
@@ -1030,6 +1064,13 @@ static int cdn_dp_bind(struct device *dev, struct device
*master, void *data)
dp->active = false;
dp->active_port = -1;
dp->fw_loaded = false;
+ dp->aux.name = "DP-AUX";
+ dp->aux.transfer = cdn_dp_aux_transfer;
+ dp->aux.dev = dev;
+
+ ret = drm_dp_aux_register(&dp->aux);
+ if (ret)
+ return ret;
INIT_WORK(&dp->event_work, cdn_dp_pd_event_work);
diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.h
b/drivers/gpu/drm/rockchip/cdn-dp-core.h
index f57e296..46159b2 100644
--- a/drivers/gpu/drm/rockchip/cdn-dp-core.h
+++ b/drivers/gpu/drm/rockchip/cdn-dp-core.h
@@ -78,6 +78,7 @@ struct cdn_dp_device {
struct platform_device *audio_pdev;
struct work_struct event_work;
struct edid *edid;
+ struct drm_dp_aux aux;
struct mutex lock;
bool connected;
diff --git a/drivers/gpu/drm/rockchip/cdn-dp-reg.c
b/drivers/gpu/drm/rockchip/cdn-dp-reg.c
index eb3042c..afdfda0 100644
--- a/drivers/gpu/drm/rockchip/cdn-dp-reg.c
+++ b/drivers/gpu/drm/rockchip/cdn-dp-reg.c
@@ -221,7 +221,11 @@ static int cdn_dp_reg_write_bit(struct cdn_dp_device *dp,
u16 addr,
sizeof(field), field);
}
-int cdn_dp_dpcd_read(struct cdn_dp_device *dp, u32 addr, u8 *data, u16 len)
+/*
+ * Return
[PATCH] gpu: drm/panel: Add DLC DLC0700YZG-1 panel
From: Philipp Zabel
From: Philipp Zabel
This patch adds support for DLC DLC0700YZG-1 1024x600 LVDS panels
to the simple-panel driver.
Signed-off-by: Philipp Zabel
Tested-by: Marco Felsch
---
.../bindings/panel/dlc,dlc0700yzg-1.txt | 7
.../devicetree/bindings/vendor-prefixes.txt | 1 +
drivers/gpu/drm/panel/panel-simple.c | 32 +++
3 files changed, 40 insertions(+)
create mode 100644 Documentation/devicetree/bindings/panel/dlc,dlc0700yzg-1.txt
diff --git a/Documentation/devicetree/bindings/panel/dlc,dlc0700yzg-1.txt
b/Documentation/devicetree/bindings/panel/dlc,dlc0700yzg-1.txt
new file mode 100644
index ..30ad3087542f
--- /dev/null
+++ b/Documentation/devicetree/bindings/panel/dlc,dlc0700yzg-1.txt
@@ -0,0 +1,7 @@
+DLC Display Co. DLC0700YZG-1 7.0" WSVGA TFT LCD panel
+
+Required properties:
+- compatible: should be "dlc,dlc070yzg-1"
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index b5f978a4cac6..52de5eed11bf 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -89,6 +89,7 @@ dhDH electronics GmbH
digi Digi International Inc.
digilent Diglent, Inc.
dioo Dioo Microcircuit Co., Ltd
+dlcDLC Display Co., Ltd.
dlgDialog Semiconductor
dlink D-Link Corporation
dmoData Modul AG
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index cbf1ab404ee7..a916754b2afa 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -857,6 +857,35 @@ static const struct panel_desc chunghwa_claa101wb01 = {
},
};
+static const struct display_timing dlc_dlc0700yzg_1_timing = {
+ .pixelclock = { 4500, 5120, 5700 },
+ .hactive = { 1024, 1024, 1024 },
+ .hfront_porch = { 100, 106, 113 },
+ .hback_porch = { 100, 106, 113 },
+ .hsync_len = { 100, 108, 114 },
+ .vactive = { 600, 600, 600 },
+ .vfront_porch = { 8, 11, 15 },
+ .vback_porch = { 8, 11, 15 },
+ .vsync_len = { 9, 13, 15 },
+ .flags = DISPLAY_FLAGS_DE_HIGH,
+};
+
+static const struct panel_desc dlc_dlc0700yzg_1 = {
+ .timings = &dlc_dlc0700yzg_1_timing,
+ .num_timings = 1,
+ .bpc = 6,
+ .size = {
+ .width = 154,
+ .height = 86,
+ },
+ .delay = {
+ .prepare = 30,
+ .enable = 200,
+ .disable = 200,
+ },
+ .bus_format = MEDIA_BUS_FMT_RGB666_1X7X3_SPWG,
+};
+
static const struct drm_display_mode edt_et057090dhu_mode = {
.clock = 25175,
.hdisplay = 640,
@@ -2124,6 +2153,9 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "chunghwa,claa101wb01",
.data = &chunghwa_claa101wb01
+ }, {
+ .compatible = "dlc,dlc0700yzg-1",
+ .data = &dlc_dlc0700yzg_1,
}, {
.compatible = "edt,et057090dhu",
.data = &edt_et057090dhu,
--
2.17.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3] display: panel: Add AUO g070vvn01 display support (800x480)
This commit adds support for AUO's 7.0" display.
Signed-off-by: Lukasz Majewski
---
Changes for v3:
- Remove not used 'bus-format-override = "rgb565";' property
Changes for v2:
- Add *.txt suffix to the auo,g070wn01 file
---
.../bindings/display/panel/auo,g070vvn01.txt | 29
drivers/gpu/drm/panel/panel-simple.c | 31 ++
2 files changed, 60 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/auo,g070vvn01.txt
diff --git a/Documentation/devicetree/bindings/display/panel/auo,g070vvn01.txt
b/Documentation/devicetree/bindings/display/panel/auo,g070vvn01.txt
new file mode 100644
index ..49e4105378f6
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/auo,g070vvn01.txt
@@ -0,0 +1,29 @@
+AU Optronics Corporation 7.0" FHD (800 x 480) TFT LCD panel
+
+Required properties:
+- compatible: should be "auo,g070vvn01"
+- backlight: phandle of the backlight device attached to the panel
+- power-supply: single regulator to provide the supply voltage
+
+Required nodes:
+- port: Parallel port mapping to connect this display
+
+This panel needs single power supply voltage. Its backlight is conntrolled
+via PWM signal.
+
+Example:
+
+
+Example device-tree definition when connected to iMX6Q based board
+
+ lcd_panel: lcd-panel {
+ compatible = "auo,g070vvn01";
+ backlight = <&backlight_lcd>;
+ power-supply = <®_display>;
+
+ port {
+ lcd_panel_in: endpoint {
+ remote-endpoint = <&lcd_display_out>;
+ };
+ };
+ };
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index cbf1ab404ee7..d9984bdb5bb5 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -581,6 +581,34 @@ static const struct panel_desc auo_b133htn01 = {
},
};
+static const struct display_timing auo_g070vvn01_timings = {
+ .pixelclock = { 3330, 34209000, 4500 },
+ .hactive = { 800, 800, 800 },
+ .hfront_porch = { 20, 40, 200 },
+ .hback_porch = { 87, 40, 1 },
+ .hsync_len = { 1, 48, 87 },
+ .vactive = { 480, 480, 480 },
+ .vfront_porch = { 5, 13, 200 },
+ .vback_porch = { 31, 31, 29 },
+ .vsync_len = { 1, 1, 3 },
+};
+
+static const struct panel_desc auo_g070vvn01 = {
+ .timings = &auo_g070vvn01_timings,
+ .num_timings = 1,
+ .bpc = 8,
+ .size = {
+ .width = 152,
+ .height = 91,
+ },
+ .delay = {
+ .prepare = 200,
+ .enable = 50,
+ .disable = 50,
+ .unprepare = 1000,
+ },
+};
+
static const struct drm_display_mode auo_g104sn02_mode = {
.clock = 4,
.hdisplay = 800,
@@ -2095,6 +2123,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "auo,b133xtn01",
.data = &auo_b133xtn01,
}, {
+ .compatible = "auo,g070vvn01",
+ .data = &auo_g070vvn01,
+ }, {
.compatible = "auo,g104sn02",
.data = &auo_g104sn02,
}, {
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] dma-fence: Make dma_fence_add_callback() fail if signaled with error
Change how dma_fence_add_callback() behaves, when the fence
has error-signaled by the time it is being add. After this commit,
dma_fence_add_callback() returns the fence error, if it
has error-signaled before dma_fence_add_callback() is called.
Signed-off-by: Ezequiel Garcia
---
drivers/dma-buf/dma-fence.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
index 4edb9fd3cf47..298b440c5b68 100644
--- a/drivers/dma-buf/dma-fence.c
+++ b/drivers/dma-buf/dma-fence.c
@@ -226,7 +226,8 @@ EXPORT_SYMBOL(dma_fence_enable_sw_signaling);
*
* Note that the callback can be called from an atomic context. If
* fence is already signaled, this function will return -ENOENT (and
- * *not* call the callback)
+ * *not* call the callback). If the fence is error-signaled, this
+ * function returns the fence error.
*
* Add a software callback to the fence. Same restrictions apply to
* refcount as it does to dma_fence_wait, however the caller doesn't need to
@@ -235,8 +236,8 @@ EXPORT_SYMBOL(dma_fence_enable_sw_signaling);
* after it signals with dma_fence_signal. The callback itself can be called
* from irq context.
*
- * Returns 0 in case of success, -ENOENT if the fence is already signaled
- * and -EINVAL in case of error.
+ * Returns 0 in case of success, -ENOENT (or the error value) if the fence is
+ * already signaled and -EINVAL in case of error.
*/
int dma_fence_add_callback(struct dma_fence *fence, struct dma_fence_cb *cb,
dma_fence_func_t func)
@@ -250,7 +251,8 @@ int dma_fence_add_callback(struct dma_fence *fence, struct
dma_fence_cb *cb,
if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags)) {
INIT_LIST_HEAD(&cb->node);
- return -ENOENT;
+ ret = (fence->error < 0) ? fence->error : -ENOENT;
+ return ret;
}
spin_lock_irqsave(fence->lock, flags);
--
2.16.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 11/11] docs: fix broken references with multiple hints
On Wed, 9 May 2018, Mauro Carvalho Chehab wrote: > The script: > ./scripts/documentation-file-ref-check --fix-rst > > Gives multiple hints for broken references on some files. > Manually use the one that applies for some files. > > Signed-off-by: Mauro Carvalho Chehab Acked-by: James Morris -- James Morris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/2] dt-bindings: Add vendor prefix for DLC Display Co., Ltd.
From: Philipp Zabel DLC provides a wide range of display solutions. Website: http://www.dlcdisplay.com/ Signed-off-by: Philipp Zabel Signed-off-by: Marco Felsch --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index b5f978a4cac6..52de5eed11bf 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -89,6 +89,7 @@ dhDH electronics GmbH digi Digi International Inc. digilent Diglent, Inc. dioo Dioo Microcircuit Co., Ltd +dlcDLC Display Co., Ltd. dlgDialog Semiconductor dlink D-Link Corporation dmoData Modul AG -- 2.17.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 09/11] docs: Fix some broken references
On Wed, May 09, 2018 at 03:20:45PM -0300, Mauro Carvalho Chehab wrote: > Em Wed, 9 May 2018 19:15:01 +0200 > Andrea Parri escreveu: > > > On Wed, May 09, 2018 at 10:18:52AM -0300, Mauro Carvalho Chehab wrote: > > > As we move stuff around, some doc references are broken. Fix some of > > > them via this script: > > > ./scripts/documentation-file-ref-check --fix-rst > > > > > > Manually checked if the produced result is valid, removing a few > > > false-positives. > > > > > > Signed-off-by: Mauro Carvalho Chehab > > > > Thank you again for doing this, > > > > > > > --- > > > .../admin-guide/kernel-parameters.txt | 4 ++-- > > > .../bindings/input/rotary-encoder.txt | 2 +- > > > Documentation/driver-api/gpio/consumer.rst| 2 +- > > > Documentation/kprobes.txt | 4 ++-- > > > Documentation/trace/coresight.txt | 2 +- > > > Documentation/trace/events.rst| 2 +- > > > Documentation/trace/ftrace-uses.rst | 2 +- > > > Documentation/trace/histogram.txt | 2 +- > > > Documentation/trace/intel_th.rst | 2 +- > > > Documentation/trace/tracepoint-analysis.rst | 6 +++--- > > > Documentation/translations/ja_JP/howto.rst| 4 ++-- > > > .../translations/zh_CN/magic-number.txt | 4 ++-- > > > .../zh_CN/video4linux/omap3isp.txt| 4 ++-- > > > MAINTAINERS | 20 +-- > > > arch/Kconfig | 2 +- > > > arch/arm/include/asm/cacheflush.h | 2 +- > > > arch/arm64/include/asm/cacheflush.h | 2 +- > > > arch/microblaze/include/asm/cacheflush.h | 2 +- > > > arch/um/Kconfig.um| 2 +- > > > arch/unicore32/include/asm/cacheflush.h | 2 +- > > > arch/x86/entry/vsyscall/vsyscall_64.c | 2 +- > > > arch/xtensa/include/asm/cacheflush.h | 4 ++-- > > > block/Kconfig | 2 +- > > > certs/Kconfig | 2 +- > > > crypto/asymmetric_keys/asymmetric_type.c | 2 +- > > > crypto/asymmetric_keys/signature.c| 2 +- > > > drivers/char/Kconfig | 2 +- > > > drivers/clk/clk.c | 4 ++-- > > > drivers/clk/ingenic/cgu.h | 2 +- > > > drivers/gpu/vga/Kconfig | 2 +- > > > drivers/gpu/vga/vgaarb.c | 2 +- > > > drivers/input/joystick/Kconfig| 10 +- > > > drivers/input/joystick/iforce/Kconfig | 2 +- > > > drivers/input/joystick/walkera0701.c | 2 +- > > > drivers/input/misc/Kconfig| 4 ++-- > > > drivers/input/misc/rotary_encoder.c | 2 +- > > > drivers/input/mouse/Kconfig | 6 +++--- > > > drivers/input/mouse/alps.c| 2 +- > > > drivers/input/touchscreen/wm97xx-core.c | 2 +- > > > drivers/lightnvm/pblk-rb.c| 2 +- > > > drivers/md/bcache/Kconfig | 2 +- > > > drivers/md/bcache/btree.c | 2 +- > > > drivers/md/bcache/extents.c | 2 +- > > > drivers/media/dvb-core/dvb_ringbuffer.c | 2 +- > > > drivers/media/pci/meye/Kconfig| 2 +- > > > drivers/media/platform/pxa_camera.c | 4 ++-- > > > .../soc_camera/sh_mobile_ceu_camera.c | 2 +- > > > drivers/media/radio/Kconfig | 2 +- > > > drivers/media/radio/si470x/Kconfig| 2 +- > > > drivers/media/usb/dvb-usb-v2/lmedm04.c| 2 +- > > > drivers/media/usb/zr364xx/Kconfig | 2 +- > > > drivers/parport/Kconfig | 6 +++--- > > > drivers/staging/media/bcm2048/TODO| 2 +- > > > include/keys/asymmetric-subtype.h | 2 +- > > > include/keys/asymmetric-type.h| 2 +- > > > include/linux/assoc_array.h | 2 +- > > > include/linux/assoc_array_priv.h | 2 +- > > > include/linux/circ_buf.h | 2 +- > > > include/linux/ftrace.h| 2 +- > > > include/linux/rculist_nulls.h | 2 +- > > > include/uapi/linux/prctl.h| 2 +- > > > include/xen/interface/io/kbdif.h | 2 +- > > > kernel/cgroup/cpuset.c| 2 +- > > > kernel/trace/Kconfig | 16 +++ > > > lib/Kconfig | 2 +- > > > security/selinux/hooks.c | 2 +- > > > sound/core/Kconfig| 4 ++-- > > > sound/drivers/Kconfig | 4 ++-- > > > sound/pci/Kconfig | 10 +- > > > tools/include/uapi/linux/prctl.h | 2 +- > > > tools/lib/api/fs/fs.c | 2 +- >
Re: [PATCH 1/2] ARM: dts: Restructure Vexpress motherboard includes
On 27/04/18 19:54, Linus Walleij wrote: > It is a bit unorthodox to just include a file in the middle > of a another DTS file, it breaks the pattern from other device > trees and also makes it really hard to reference things > across the files with phandles. > > Restructure the include for the Versatile Express motherboards > to happen at the top of the file, reference the target nodes > directly, and indent the motherboard .dtsi files to reflect > their actual depth in the hiearchy. > > This is a purely syntactic change that result in the same > DTB files from the DTS/DTSI files. > Please copy me and Lorenzo also in future. Applied now(with typo in hierarchy fixed), thanks. -- Regards, Sudeep ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 4/4] drm/rockchip: support dp training outside dp firmware
DP firmware uses fixed phy config values to do training, but some
boards need to adjust these values to fit for their unique hardware
design. So if the phy is using custom config values, do software
link training instead of relying on firmware, if software training
fail, keep firmware training as a fallback if sw training fails.
Signed-off-by: Chris Zhong
Signed-off-by: Lin Huang
---
Changes in v2:
- update patch following Enric suggest
drivers/gpu/drm/rockchip/Makefile | 3 +-
drivers/gpu/drm/rockchip/cdn-dp-core.c | 24 +-
drivers/gpu/drm/rockchip/cdn-dp-core.h | 2 +
drivers/gpu/drm/rockchip/cdn-dp-link-training.c | 391
drivers/gpu/drm/rockchip/cdn-dp-reg.c | 34 ++-
drivers/gpu/drm/rockchip/cdn-dp-reg.h | 38 ++-
6 files changed, 479 insertions(+), 13 deletions(-)
create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-link-training.c
diff --git a/drivers/gpu/drm/rockchip/Makefile
b/drivers/gpu/drm/rockchip/Makefile
index a314e21..b932f62 100644
--- a/drivers/gpu/drm/rockchip/Makefile
+++ b/drivers/gpu/drm/rockchip/Makefile
@@ -9,7 +9,8 @@ rockchipdrm-y := rockchip_drm_drv.o rockchip_drm_fb.o \
rockchipdrm-$(CONFIG_DRM_FBDEV_EMULATION) += rockchip_drm_fbdev.o
rockchipdrm-$(CONFIG_ROCKCHIP_ANALOGIX_DP) += analogix_dp-rockchip.o
-rockchipdrm-$(CONFIG_ROCKCHIP_CDN_DP) += cdn-dp-core.o cdn-dp-reg.o
+rockchipdrm-$(CONFIG_ROCKCHIP_CDN_DP) += cdn-dp-core.o cdn-dp-reg.o \
+ cdn-dp-link-training.o
rockchipdrm-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o
rockchipdrm-$(CONFIG_ROCKCHIP_DW_MIPI_DSI) += dw-mipi-dsi.o
rockchipdrm-$(CONFIG_ROCKCHIP_INNO_HDMI) += inno_hdmi.o
diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c
b/drivers/gpu/drm/rockchip/cdn-dp-core.c
index cce64c1..2359d82 100644
--- a/drivers/gpu/drm/rockchip/cdn-dp-core.c
+++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c
@@ -629,11 +629,13 @@ static void cdn_dp_encoder_enable(struct drm_encoder
*encoder)
goto out;
}
}
-
- ret = cdn_dp_set_video_status(dp, CONTROL_VIDEO_IDLE);
- if (ret) {
- DRM_DEV_ERROR(dp->dev, "Failed to idle video %d\n", ret);
- goto out;
+ if (dp->sw_training_success == false) {
+ ret = cdn_dp_set_video_status(dp, CONTROL_VIDEO_IDLE);
+ if (ret) {
+ DRM_DEV_ERROR(dp->dev,
+ "Failed to idle video %d\n", ret);
+ goto out;
+ }
}
ret = cdn_dp_config_video(dp);
@@ -642,11 +644,15 @@ static void cdn_dp_encoder_enable(struct drm_encoder
*encoder)
goto out;
}
- ret = cdn_dp_set_video_status(dp, CONTROL_VIDEO_VALID);
- if (ret) {
- DRM_DEV_ERROR(dp->dev, "Failed to valid video %d\n", ret);
- goto out;
+ if (dp->sw_training_success == false) {
+ ret = cdn_dp_set_video_status(dp, CONTROL_VIDEO_VALID);
+ if (ret) {
+ DRM_DEV_ERROR(dp->dev,
+ "Failed to valid video %d\n", ret);
+ goto out;
+ }
}
+
out:
mutex_unlock(&dp->lock);
}
diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.h
b/drivers/gpu/drm/rockchip/cdn-dp-core.h
index 46159b2..c6050ab 100644
--- a/drivers/gpu/drm/rockchip/cdn-dp-core.h
+++ b/drivers/gpu/drm/rockchip/cdn-dp-core.h
@@ -84,6 +84,7 @@ struct cdn_dp_device {
bool connected;
bool active;
bool suspended;
+ bool sw_training_success;
const struct firmware *fw; /* cdn dp firmware */
unsigned int fw_version;/* cdn fw version */
@@ -106,6 +107,7 @@ struct cdn_dp_device {
u8 ports;
u8 lanes;
int active_port;
+ u8 train_set[4];
u8 dpcd[DP_RECEIVER_CAP_SIZE];
bool sink_has_audio;
diff --git a/drivers/gpu/drm/rockchip/cdn-dp-link-training.c
b/drivers/gpu/drm/rockchip/cdn-dp-link-training.c
new file mode 100644
index 000..25282de
--- /dev/null
+++ b/drivers/gpu/drm/rockchip/cdn-dp-link-training.c
@@ -0,0 +1,391 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) Fuzhou Rockchip Electronics Co.Ltd
+ * Author: Chris Zhong
+ */
+
+#include
+#include
+#include
+#include
+
+#include "cdn-dp-core.h"
+#include "cdn-dp-reg.h"
+
+static void cdn_dp_set_signal_levels(struct cdn_dp_device *dp)
+{
+ struct cdn_dp_port *port = dp->port[dp->active_port];
+ struct rockchip_typec_phy *tcphy = phy_get_drvdata(port->phy);
+
+ int rate = drm_dp_bw_code_to_link_rate(dp->link.rate);
+ u8 swing = (dp->train_set[0] & DP_TRAIN_VOLTAGE_SWING_MASK) >>
+ DP_TRAIN_VOLTAGE_SWING_SHIFT;
+ u8 pre_emphasis = (dp->train_set[0] & DP_TRAIN_PRE_EMPHASIS_MASK)
+ >> DP_TRAIN_PRE_EMPHASIS_SHIFT;
+
+ tcphy-
[PATCH v2 0/2] gpu: drm/panel: Add DLC DLC0700YZG-1 support
This serie adds support for the DLC Display Co. DLC0700YZG-1 7.0" WSVGA TFT LCD panel. The customer isn't listed as vendor so we have to add the vendor prefix too. Philipp Zabel (2): dt-bindings: Add vendor prefix for DLC Display Co., Ltd. gpu: drm/panel: Add DLC DLC0700YZG-1 panel .../display/panel/dlc,dlc0700yzg-1.txt| 7 .../devicetree/bindings/vendor-prefixes.txt | 1 + drivers/gpu/drm/panel/panel-simple.c | 32 +++ 3 files changed, 40 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/dlc,dlc0700yzg-1.txt -- 2.17.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 09/11] docs: Fix some broken references
On Wed, May 09, 2018 at 10:18:52AM -0300, Mauro Carvalho Chehab wrote: > As we move stuff around, some doc references are broken. Fix some of > them via this script: > ./scripts/documentation-file-ref-check --fix-rst > > Manually checked if the produced result is valid, removing a few > false-positives. > > Signed-off-by: Mauro Carvalho Chehab Thank you again for doing this, > --- > .../admin-guide/kernel-parameters.txt | 4 ++-- > .../bindings/input/rotary-encoder.txt | 2 +- > Documentation/driver-api/gpio/consumer.rst| 2 +- > Documentation/kprobes.txt | 4 ++-- > Documentation/trace/coresight.txt | 2 +- > Documentation/trace/events.rst| 2 +- > Documentation/trace/ftrace-uses.rst | 2 +- > Documentation/trace/histogram.txt | 2 +- > Documentation/trace/intel_th.rst | 2 +- > Documentation/trace/tracepoint-analysis.rst | 6 +++--- > Documentation/translations/ja_JP/howto.rst| 4 ++-- > .../translations/zh_CN/magic-number.txt | 4 ++-- > .../zh_CN/video4linux/omap3isp.txt| 4 ++-- > MAINTAINERS | 20 +-- > arch/Kconfig | 2 +- > arch/arm/include/asm/cacheflush.h | 2 +- > arch/arm64/include/asm/cacheflush.h | 2 +- > arch/microblaze/include/asm/cacheflush.h | 2 +- > arch/um/Kconfig.um| 2 +- > arch/unicore32/include/asm/cacheflush.h | 2 +- > arch/x86/entry/vsyscall/vsyscall_64.c | 2 +- > arch/xtensa/include/asm/cacheflush.h | 4 ++-- > block/Kconfig | 2 +- > certs/Kconfig | 2 +- > crypto/asymmetric_keys/asymmetric_type.c | 2 +- > crypto/asymmetric_keys/signature.c| 2 +- > drivers/char/Kconfig | 2 +- > drivers/clk/clk.c | 4 ++-- > drivers/clk/ingenic/cgu.h | 2 +- > drivers/gpu/vga/Kconfig | 2 +- > drivers/gpu/vga/vgaarb.c | 2 +- > drivers/input/joystick/Kconfig| 10 +- > drivers/input/joystick/iforce/Kconfig | 2 +- > drivers/input/joystick/walkera0701.c | 2 +- > drivers/input/misc/Kconfig| 4 ++-- > drivers/input/misc/rotary_encoder.c | 2 +- > drivers/input/mouse/Kconfig | 6 +++--- > drivers/input/mouse/alps.c| 2 +- > drivers/input/touchscreen/wm97xx-core.c | 2 +- > drivers/lightnvm/pblk-rb.c| 2 +- > drivers/md/bcache/Kconfig | 2 +- > drivers/md/bcache/btree.c | 2 +- > drivers/md/bcache/extents.c | 2 +- > drivers/media/dvb-core/dvb_ringbuffer.c | 2 +- > drivers/media/pci/meye/Kconfig| 2 +- > drivers/media/platform/pxa_camera.c | 4 ++-- > .../soc_camera/sh_mobile_ceu_camera.c | 2 +- > drivers/media/radio/Kconfig | 2 +- > drivers/media/radio/si470x/Kconfig| 2 +- > drivers/media/usb/dvb-usb-v2/lmedm04.c| 2 +- > drivers/media/usb/zr364xx/Kconfig | 2 +- > drivers/parport/Kconfig | 6 +++--- > drivers/staging/media/bcm2048/TODO| 2 +- > include/keys/asymmetric-subtype.h | 2 +- > include/keys/asymmetric-type.h| 2 +- > include/linux/assoc_array.h | 2 +- > include/linux/assoc_array_priv.h | 2 +- > include/linux/circ_buf.h | 2 +- > include/linux/ftrace.h| 2 +- > include/linux/rculist_nulls.h | 2 +- > include/uapi/linux/prctl.h| 2 +- > include/xen/interface/io/kbdif.h | 2 +- > kernel/cgroup/cpuset.c| 2 +- > kernel/trace/Kconfig | 16 +++ > lib/Kconfig | 2 +- > security/selinux/hooks.c | 2 +- > sound/core/Kconfig| 4 ++-- > sound/drivers/Kconfig | 4 ++-- > sound/pci/Kconfig | 10 +- > tools/include/uapi/linux/prctl.h | 2 +- > tools/lib/api/fs/fs.c | 2 +- > tools/memory-model/README | 10 +- As mentioned in the previous thread, I am for keeping the current references: the REAMDE is listing the doc files, as well as other files in tools/memory-model/, relatively to that directory. Andrea ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/2] dt-bindings: Add vendor prefix for DLC Display Co., Ltd.
From: Philipp Zabel DLC provides a wide range of display solutions. Website: http://www.dlcdisplay.com/ Signed-off-by: Philipp Zabel Signed-off-by: Marco Felsch --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index b5f978a4cac6..52de5eed11bf 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -89,6 +89,7 @@ dhDH electronics GmbH digi Digi International Inc. digilent Diglent, Inc. dioo Dioo Microcircuit Co., Ltd +dlcDLC Display Co., Ltd. dlgDialog Semiconductor dlink D-Link Corporation dmoData Modul AG -- 2.17.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH RESEND] display: panel: Add KOE tx14d24vm1bpa display support (320x240)
This commit adds support for KOE's 5.7" display.
Signed-off-by: Lukasz Majewski
---
.../bindings/display/panel/koe,tx14d24vm1bpa.txt | 42 ++
drivers/gpu/drm/panel/panel-simple.c | 26 ++
2 files changed, 68 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/koe,tx14d24vm1bpa.txt
diff --git
a/Documentation/devicetree/bindings/display/panel/koe,tx14d24vm1bpa.txt
b/Documentation/devicetree/bindings/display/panel/koe,tx14d24vm1bpa.txt
new file mode 100644
index ..be7ac666807b
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/koe,tx14d24vm1bpa.txt
@@ -0,0 +1,42 @@
+Kaohsiung Opto-Electronics Inc. 5.7" QVGA (320 x 240) TFT LCD panel
+
+Required properties:
+- compatible: should be "koe,tx14d24vm1bpa"
+- backlight: phandle of the backlight device attached to the panel
+- power-supply: single regulator to provide the supply voltage
+
+Required nodes:
+- port: Parallel port mapping to connect this display
+
+This panel needs single power supply voltage. Its backlight is conntrolled
+via PWM signal.
+
+Example:
+
+
+Example device-tree definition when connected to iMX53 based board
+
+ lcd_panel: lcd-panel {
+ compatible = "koe,tx14d24vm1bpa";
+ backlight = <&backlight_lcd>;
+ power-supply = <®_3v3>;
+
+ port {
+ lcd_panel_in: endpoint {
+ remote-endpoint = <&lcd_display_out>;
+ };
+ };
+ };
+
+Then one needs to extend the dispX node:
+
+ lcd_display: disp1 {
+
+ port@1 {
+ reg = <1>;
+
+ lcd_display_out: endpoint {
+ remote-endpoint = <&lcd_panel_in>;
+ };
+ };
+ };
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index d9984bdb5bb5..103b43ce7dee 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1268,6 +1268,29 @@ static const struct panel_desc innolux_zj070na_01p = {
},
};
+static const struct display_timing koe_tx14d24vm1bpa_timing = {
+ .pixelclock = { 558, 585, 620 },
+ .hactive = { 320, 320, 320 },
+ .hfront_porch = { 30, 30, 30 },
+ .hback_porch = { 30, 30, 30 },
+ .hsync_len = { 1, 5, 17 },
+ .vactive = { 240, 240, 240 },
+ .vfront_porch = { 6, 6, 6 },
+ .vback_porch = { 5, 5, 5 },
+ .vsync_len = { 1, 2, 11 },
+ .flags = DISPLAY_FLAGS_DE_HIGH,
+};
+
+static const struct panel_desc koe_tx14d24vm1bpa = {
+ .timings = &koe_tx14d24vm1bpa_timing,
+ .num_timings = 1,
+ .bpc = 6,
+ .size = {
+ .width = 115,
+ .height = 86,
+ },
+};
+
static const struct display_timing koe_tx31d200vm0baa_timing = {
.pixelclock = { 3960, 4320, 4800 },
.hactive = { 1280, 1280, 1280 },
@@ -2204,6 +2227,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "innolux,zj070na-01p",
.data = &innolux_zj070na_01p,
}, {
+ .compatible = "koe,tx14d24vm1bpa",
+ .data = &koe_tx14d24vm1bpa,
+ }, {
.compatible = "koe,tx31d200vm0baa",
.data = &koe_tx31d200vm0baa,
}, {
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 09/11] docs: Fix some broken references
On Wed, May 09, 2018 at 04:41:53PM -0300, Mauro Carvalho Chehab wrote:
> Em Wed, 9 May 2018 15:11:07 -0400 (EDT)
> Alan Stern escreveu:
>
> > On Wed, 9 May 2018, Mauro Carvalho Chehab wrote:
> >
> > > Em Wed, 9 May 2018 19:15:01 +0200
> > > Andrea Parri escreveu:
> >
> > > > > tools/memory-model/README | 10 +-
> > > >
> > > > As mentioned in the previous thread, I am for keeping the current
> > > > references: the REAMDE is listing the doc files, as well as other
> > > > files in tools/memory-model/, relatively to that directory.
> > >
> > > Yeah, at least this hunk deserves some rework, as now some
> > > references are Documentation/.../foo, while others are just
> > > bar.
> > >
> > > As on (almost) all other places (except for tools/memory-model/README),
> > > the references are always from the main directory, I would make all
> > > patches there also relative to main dir. If you're afraid of
> > > not being too clearer, we could prefix all of them with something
> > > like:
> > >
> > > ${LINUX}/tools/memory-model/...
> > >
> > > just like some DT binding files do:
> > >
> > > Documentation/devicetree/bindings/sound/audio-graph-card.txt:see
> > > ${LINUX}/Documentation/devicetree/bindings/graph.txt
> > >
> > > A bonus of doing that is that the broken reference detect script can
> > > keep parsing it without changes (well, it wouldn't be hard to make
> > > it also accept a relative file, but doing that just due to
> > > tools/memory-model/README seems overkill).
> > >
> > > Another advantage is that it would allow to easily add references
> > > there from the main kernel Documentation, if needed in the future,
> > > without messing with local x non-local relative namespace.
> >
> > How about changing the relative references so that something like
> > Documentation/recipes.txt becomes ./Documentation/recipes.txt?
>
> Sounds a good idea to me. Andrea?
Counterintuitive ;-) Documentation/abc.txt vs. ./Documentation/abc.txt
But let me sleep over this ;-) for the time being, I renew my vote for
"just don't commit these changes (and keep checking automated changes)".
Andrea
>
> Thanks,
> Mauro
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 0/2] gpu: drm/panel: Add DLC DLC0700YZG-1 support
This serie adds support for the DLC Display Co. DLC0700YZG-1 7.0" WSVGA TFT LCD panel. The customer isn't listed as vendor so we have to add the vendor prefix too. Philipp Zabel (2): dt-bindings: Add vendor prefix for DLC Display Co., Ltd. gpu: drm/panel: Add DLC DLC0700YZG-1 panel .../display/panel/dlc,dlc0700yzg-1.txt| 7 .../devicetree/bindings/vendor-prefixes.txt | 1 + drivers/gpu/drm/panel/panel-simple.c | 32 +++ 3 files changed, 40 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/dlc,dlc0700yzg-1.txt -- 2.17.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 00/13] drm/kms/mode: using helper func drm_display_mode_to/from_videomode for calculating timing parameters
On Thu, May 08, 2018 at 16:28:30 +0530, Satendra Singh Thakur wrote:
> On Thu, May 07, 2018 at 15:46:02 +0200, Daniel Vetter wrote:
> > On Thu, May 03, 2018 at 01:53:55PM +0530, Satendra Singh Thakur wrote:
> > > 1.There is a function in drm-core to calculate display timing parameters:
> > > horizontal front porch, back porch, sync length,
> > > vertical front porch, back porch, sync length and
> > > clock in Hz.
> > > However, some drivers are still calculating these parameters themselves.
> > > Therefore, there is a duplication of the code.
> > > This patch series replaces this redundant code with the function
> > > drm_display_mode_to_videomode.
> > > This removes nearly 100 redundant lines from the related drivers.
> > > 2.For some drivers (sun4i) the reverse helper
> > > drm_display_mode_from_videomode is used.
> > > 3.For some drivers it replaces arithmatic operators (*, /) with shifting
> > > operators (>>, <<).
> > > 4.For some drivers DRM_MODE_FLAG_* are replaced with DISPLAY_FLAGS_*
> > > flags.
> > > 5.These changes apply to following crtc and encoder drivers:
> > > atmel-hlcdc
> > > bridge-tc358767
> > > exynos-dsi
> > > fsl-dcu
> > > gma500-mdfld_dsi_dpi
> > > hisilicon-kirin_dsi, ade
> > > meson-encoder
> > > pl111-display
> > > sun4i-tv
> > > ti lcdc
> > > tegra dc
> > > mediatek dpi dsi
> > > bridge-adv7533
> >
> > The drm_mode_to_videomode helper is meant for interop between drm and v4l,
> > which have different internal structures to represent modes.
> >
> > For drivers that only use drm I think the better option would be to add
> > these fields to struct drm_display_mode as another set of crtc_* values
> > (the computed values are stored in crtc_ prefixed members). And compute
> > front/back porch in drm_mode_set_crtcinfo.
> >
> > Then we can use these new drm_display_mode->crtc_h|vfront|back_porch
> > fields in all the drivers you're changing. This way you avoid having to
> > change all the drm drivers to use v4l #defines.
> >
> > Thanks,
> > Daniel
>
> Hi Daniel,
> Thanks for the comments.
> I will look into it.
>
> Thanks
> -Satendra
Hi Daniel,
Thanks for the comments.
Please find below my understanding in this direction.
1. Currently struct videomode is being used in 50 drm drivers and 14 fbdev
drivers.
Since, it's already being used by so many drm drivers, that is the reason
these fbdev objects (struct videmode and func drm_display_mode_to_videomode)
were used in this patch series.
2. Anyway, if fbdev related objects (struct/func) are not encouraged in drm
drivers, then we may add
h/v front/back porches in struct drm_display_mode as adviced by you.
3. We can calculate these params in func drm_mode_set_crtcinfo at the end of it.
int drm_mode_set_crtcinfo ()
{
.
.
crtc_hfront_porch = crtc_hsync_start - crtc_hdisplay;
crtc_vfront_porch = crtc_vsync_start - crtc_vdisplay;
.
.
crtc_clock_hz = crtc_clock*1000;
};
4. Normally mode is programmed in HW in following callbacks of crtc and encoder
drivers
-mode_set
-mode_set_nofb
-atomic_enable
Normally drm_mode_set_crtcinfo is used in
-mode_fixup callbacks (CBs)
of encoder and crtc drivers.
if mode_fixup CBs are called before mode_set CBs then
drm_mode_set_crtcinfo is right place to calculate sync/porch params.
We can use crtc_hfront/back_porches directly and program them to HW
in above mentioned callbacks.
int my_mode_set ()
{
REG_WRITE(crtc_hfront_porch);
REG_WRITE(crtc_hback_porch);
.
.
}
6. However, if these params are being modified after calling drm_set_crtcinfo
as mentioned below:
bool amdgpu_atombios_encoder_mode_fixup(struct drm_encoder *encoder,
const struct drm_display_mode *mode,
struct drm_display_mode *adjusted_mode)
{
struct amdgpu_encoder *amdgpu_encoder = to_amdgpu_encoder(encoder);
/* set the active encoder to connector routing */
amdgpu_encoder_set_active_device(encoder);
***drm_mode_set_crtcinfo(adjusted_mode, 0);
/* hw bug */
if ((mode->flags & DRM_MODE_FLAG_INTERLACE)
&& (mode->crtc_vsync_start < (mode->crtc_vdisplay + 2)))
adjusted_mode->crtc_vsync_start = adjusted_mode->crtc_vdisplay
+ 2;
Then we may need to define new func like
void drm_calc_hv_porches_sync()
{
crtc_hfront_porch = crtc_hsync_start - crtc_hdisplay;
crtc_vfront_porch = crtc_vsync_start - crtc_vdisplay;
.
.
crtc_clock_hz = crtc_clock*1000;
} and call this func in mode_set*, atomic_enable CBS before programming the
HW with this mode.
Should I create patches around this idea ?
Please let me know your comments.
Thanks
-Satendra
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/4] drm/rockchip: support dp training outside dp firmware
On Monday, May 07, 2018 07:29 PM, Enric Balletbo Serra wrote:
Hi Lin,
Thanks for the patch.
2018-05-04 10:08 GMT+02:00 Lin Huang :
DP firware use fix phy config value to do training, but some
s/fiware/firmware/
board need to adjust these value to fit for their hardware design,
so we use new phy config to do training outside firmware to meet
this situation, if there have new phy config pass from dts, it will
use training outside firmware.
maybe you can rewrite all this in a better way.
ooi, which boards needs this?
Signed-off-by: Chris Zhong
Signed-off-by: Lin Huang
---
drivers/gpu/drm/rockchip/Makefile | 3 +-
drivers/gpu/drm/rockchip/cdn-dp-core.c | 23 +-
drivers/gpu/drm/rockchip/cdn-dp-core.h | 2 +
drivers/gpu/drm/rockchip/cdn-dp-link-training.c | 398
drivers/gpu/drm/rockchip/cdn-dp-reg.c | 33 +-
drivers/gpu/drm/rockchip/cdn-dp-reg.h | 38 ++-
6 files changed, 480 insertions(+), 17 deletions(-)
create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-link-training.c
diff --git a/drivers/gpu/drm/rockchip/Makefile
b/drivers/gpu/drm/rockchip/Makefile
index a314e21..b932f62 100644
--- a/drivers/gpu/drm/rockchip/Makefile
+++ b/drivers/gpu/drm/rockchip/Makefile
@@ -9,7 +9,8 @@ rockchipdrm-y := rockchip_drm_drv.o rockchip_drm_fb.o \
rockchipdrm-$(CONFIG_DRM_FBDEV_EMULATION) += rockchip_drm_fbdev.o
rockchipdrm-$(CONFIG_ROCKCHIP_ANALOGIX_DP) += analogix_dp-rockchip.o
-rockchipdrm-$(CONFIG_ROCKCHIP_CDN_DP) += cdn-dp-core.o cdn-dp-reg.o
+rockchipdrm-$(CONFIG_ROCKCHIP_CDN_DP) += cdn-dp-core.o cdn-dp-reg.o \
+ cdn-dp-link-training.o
rockchipdrm-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o
rockchipdrm-$(CONFIG_ROCKCHIP_DW_MIPI_DSI) += dw-mipi-dsi.o
rockchipdrm-$(CONFIG_ROCKCHIP_INNO_HDMI) += inno_hdmi.o
diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c
b/drivers/gpu/drm/rockchip/cdn-dp-core.c
index 268c190..a2a4208 100644
--- a/drivers/gpu/drm/rockchip/cdn-dp-core.c
+++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c
@@ -629,11 +629,13 @@ static void cdn_dp_encoder_enable(struct drm_encoder
*encoder)
goto out;
}
}
-
- ret = cdn_dp_set_video_status(dp, CONTROL_VIDEO_IDLE);
- if (ret) {
- DRM_DEV_ERROR(dp->dev, "Failed to idle video %d\n", ret);
- goto out;
+ if (dp->sw_training_success == false) {
+ ret = cdn_dp_set_video_status(dp, CONTROL_VIDEO_IDLE);
+ if (ret) {
+ DRM_DEV_ERROR(dp->dev,
+ "Failed to idle video %d\n", ret);
+ goto out;
+ }
}
ret = cdn_dp_config_video(dp);
@@ -642,11 +644,14 @@ static void cdn_dp_encoder_enable(struct drm_encoder
*encoder)
goto out;
}
- ret = cdn_dp_set_video_status(dp, CONTROL_VIDEO_VALID);
- if (ret) {
- DRM_DEV_ERROR(dp->dev, "Failed to valid video %d\n", ret);
- goto out;
+ if (dp->sw_training_success == false) {
+ ret = cdn_dp_set_video_status(dp, CONTROL_VIDEO_VALID);
+ if (ret) {
+ DRM_DEV_ERROR(dp->dev, "Failed to valid video %d\n",
ret);
+ goto out;
+ }
}
+
out:
mutex_unlock(&dp->lock);
}
diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.h
b/drivers/gpu/drm/rockchip/cdn-dp-core.h
index 46159b2..c6050ab 100644
--- a/drivers/gpu/drm/rockchip/cdn-dp-core.h
+++ b/drivers/gpu/drm/rockchip/cdn-dp-core.h
@@ -84,6 +84,7 @@ struct cdn_dp_device {
bool connected;
bool active;
bool suspended;
+ bool sw_training_success;
const struct firmware *fw; /* cdn dp firmware */
unsigned int fw_version;/* cdn fw version */
@@ -106,6 +107,7 @@ struct cdn_dp_device {
u8 ports;
u8 lanes;
int active_port;
+ u8 train_set[4];
u8 dpcd[DP_RECEIVER_CAP_SIZE];
bool sink_has_audio;
diff --git a/drivers/gpu/drm/rockchip/cdn-dp-link-training.c
b/drivers/gpu/drm/rockchip/cdn-dp-link-training.c
new file mode 100644
index 000..558c945
--- /dev/null
+++ b/drivers/gpu/drm/rockchip/cdn-dp-link-training.c
@@ -0,0 +1,398 @@
+/* SPDX-License-Identifier: GPL-2.0 */
For a C source file the format is:
(https://www.kernel.org/doc/html/latest/process/license-rules.html)
// SPDX-License-Identifier:
Thanks for pointing it, will fix it.
+/*
+ * Copyright (C) Fuzhou Rockchip Electronics Co.Ltd
+ * Author: Chris Zhong
+ */
+
+#include
Why you need this include?
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
In fact, I think that there are other includes that can be removed,
please review.
+#include "cdn-dp-core.h"
+#include "cdn-dp-reg.h"
+
+static void cdn_dp_set_signal_levels(st
Re: [PATCH v2 01/26] drm/bridge: allow optionally specifying an owner .odev device
On 2018-05-09 17:08, Andrzej Hajda wrote:
> On 04.05.2018 15:51, Peter Rosin wrote:
>> Bridge drivers can now (temporarily, in a transition phase) select if
>> they want to provide a full owner device or keep just providing an
>> of_node.
>>
>> By providing a full owner device, the bridge drivers no longer need
>> to provide an of_node since that node is available via the owner
>> device.
>>
>> When all bridge drivers provide an owner device, that will become
>> mandatory and the .of_node member will be removed.
>>
>> Signed-off-by: Peter Rosin
>> ---
>> drivers/gpu/drm/drm_bridge.c | 3 ++-
>> drivers/gpu/drm/rockchip/rockchip_lvds.c | 4 +++-
>
> What is the reason to put rockchip here? Shouldn't be in separate patch?
Because the rockchip driver peeks into the bridge struct and all the
changes in this patch relate to making the new .odev member optional in
the transition phase, when the bridge can have either a new-style odev
or an old style of_node.
I guess this rockchip change could be patch 2, but it has to come first
after this patch and it makes no sense on its own. Hence, one patch.
This rockchip_lvds interaction is also present in patch 24/26
drm/bridge: remove the .of_node member
I can split them if you want, but I personally don't see the point.
>> include/drm/drm_bridge.h | 2 ++
>> 3 files changed, 7 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
>> index 1638bfe9627c..3872f5379998 100644
>> --- a/drivers/gpu/drm/drm_bridge.c
>> +++ b/drivers/gpu/drm/drm_bridge.c
>> @@ -365,7 +365,8 @@ struct drm_bridge *of_drm_find_bridge(struct device_node
>> *np)
>> mutex_lock(&bridge_lock);
>>
>> list_for_each_entry(bridge, &bridge_list, list) {
>> -if (bridge->of_node == np) {
>> +if ((bridge->odev && bridge->odev->of_node == np) ||
>> +bridge->of_node == np) {
>> mutex_unlock(&bridge_lock);
>> return bridge;
>> }
>> diff --git a/drivers/gpu/drm/rockchip/rockchip_lvds.c
>> b/drivers/gpu/drm/rockchip/rockchip_lvds.c
>> index 4bd94b167d2c..557e0079c98d 100644
>> --- a/drivers/gpu/drm/rockchip/rockchip_lvds.c
>> +++ b/drivers/gpu/drm/rockchip/rockchip_lvds.c
>> @@ -377,8 +377,10 @@ static int rockchip_lvds_bind(struct device *dev,
>> struct device *master,
>> }
>> if (lvds->panel)
>> remote = lvds->panel->dev->of_node;
>> -else
>> +else if (lvds->bridge->of_node)
>> remote = lvds->bridge->of_node;
>> +else
>> +remote = lvds->bridge->odev->of_node;
>
> I guess odev should be NULL here, or have I missed something.
s/should/could/ ???
Assuming that was what you meant and answering accordingly...
No, .odev cannot be NULL in that else branch. drm_of_find_panel_or_bridge
either found a panel or a bridge (or it failed). If it found a bridge
(which is the relevant branch for this question) that bridge would have
to have either an of_node (in the transition phase) or a valid .odev.
Otherwise the bridge could not have been found by
drm_of_find_panel_or_bridge.
*time passes*
Ahh, yes, .odev is always NULL here so you probably did mean "should".
But after patches 2-23 when bridges start populating .odev *instead*
of .of_node, .odev will not remain NULL. But as I said above, while
.odev is NULL, .of_node will never be NULL and vice versa (or
drm_of_find_panel_or_bridge could not have found the bridge) so there
is no risk of a NULL dereference.
Cheers,
Peter
>
> Regards
> Andrzej
>
>> if (of_property_read_string(dev->of_node, "rockchip,output", &name))
>> /* default set it as output rgb */
>> lvds->output = DISPLAY_OUTPUT_RGB;
>> diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
>> index 3270fec46979..7c17977c3537 100644
>> --- a/include/drm/drm_bridge.h
>> +++ b/include/drm/drm_bridge.h
>> @@ -254,6 +254,7 @@ struct drm_bridge_timings {
>>
>> /**
>> * struct drm_bridge - central DRM bridge control structure
>> + * @odev: device that owns the bridge
>> * @dev: DRM device this bridge belongs to
>> * @encoder: encoder to which this bridge is connected
>> * @next: the next bridge in the encoder chain
>> @@ -265,6 +266,7 @@ struct drm_bridge_timings {
>> * @driver_private: pointer to the bridge driver's internal context
>> */
>> struct drm_bridge {
>> +struct device *odev;
>> struct drm_device *dev;
>> struct drm_encoder *encoder;
>> struct drm_bridge *next;
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 01/26] drm/bridge: allow optionally specifying an owner .odev device
On 2018-05-09 17:53, Peter Rosin wrote: > On 2018-05-09 17:08, Andrzej Hajda wrote: >> On 04.05.2018 15:51, Peter Rosin wrote: >>> Bridge drivers can now (temporarily, in a transition phase) select if >>> they want to provide a full owner device or keep just providing an >>> of_node. >>> >>> By providing a full owner device, the bridge drivers no longer need >>> to provide an of_node since that node is available via the owner >>> device. >>> >>> When all bridge drivers provide an owner device, that will become >>> mandatory and the .of_node member will be removed. >>> >>> Signed-off-by: Peter Rosin >>> --- >>> drivers/gpu/drm/drm_bridge.c | 3 ++- >>> drivers/gpu/drm/rockchip/rockchip_lvds.c | 4 +++- >> >> What is the reason to put rockchip here? Shouldn't be in separate patch? > > Because the rockchip driver peeks into the bridge struct and all the > changes in this patch relate to making the new .odev member optional in > the transition phase, when the bridge can have either a new-style odev > or an old style of_node. > > I guess this rockchip change could be patch 2, but it has to come first > after this patch and it makes no sense on its own. Hence, one patch. > > This rockchip_lvds interaction is also present in patch 24/26 > drm/bridge: remove the .of_node member > > I can split them if you want, but I personally don't see the point. I had a second look, and maybe the series should start with a patch like this instead, so that the rockchip_lvds.c hunks can be removed from patch 1/26 and 24/26. That would perhaps be slightly cleaner? On the other hand, it's orthogonal and this series can be left as is (with the benefit of me not having to do another iteration and you all not having another bunch of messages to sift through). The below patch could easily be (adjusted and) applied later instead. Or not, since the right fix is to do this with the newfangled static image format mechanism from Jacopo Mondi, and it might be easier to just do it right. State your preference. Cheers, Peter From dee27b36a36acd271459d1489336b56132097425 Mon Sep 17 00:00:00 2001 From: Peter Rosin Date: Wed, 9 May 2018 23:58:24 +0200 Subject: [PATCH] drm/rockchip: lvds: do not dig into the DT of remote bridges The driver is trying to find the needed "data-mapping" for interacting with the following bridge in the graphics chain. But, doing so is bad since it is done w/o regard of the compatible of the remote bridge, so the value of "data-mapping" might not mean what this driver assumes. It is also pointless since no bridge has any documented "data-mapping" DT property and no dts file show any undocumented use. Just remove the inappropriate code. Signed-off-by: Peter Rosin --- drivers/gpu/drm/rockchip/rockchip_lvds.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/rockchip/rockchip_lvds.c b/drivers/gpu/drm/rockchip/rockchip_lvds.c index 4bd94b167d2c..fa3f4bf9712f 100644 --- a/drivers/gpu/drm/rockchip/rockchip_lvds.c +++ b/drivers/gpu/drm/rockchip/rockchip_lvds.c @@ -377,8 +377,6 @@ static int rockchip_lvds_bind(struct device *dev, struct device *master, } if (lvds->panel) remote = lvds->panel->dev->of_node; - else - remote = lvds->bridge->of_node; if (of_property_read_string(dev->of_node, "rockchip,output", &name)) /* default set it as output rgb */ lvds->output = DISPLAY_OUTPUT_RGB; -- 2.11.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V1 1/5] qcom: wled: Rename pm8941-wled.c to qcom-wled.c
On Thu 2018-05-03 15:27:08, Kiran Gunda wrote: > pm8941-wled.c driver is supporting the WLED peripheral > on pm8941. Rename it to qcom-wled.c so that it can support > WLED on multiple PMICs. > > Signed-off-by: Kiran Gunda Acked-by: Pavel Machek -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106402] amdgpu causes kernel Oops: 0002 [#1] SMP PTI
https://bugs.freedesktop.org/show_bug.cgi?id=106402 --- Comment #2 from Tim Cuthbertson --- I am running Wayland, so no Xorg log. I do not know how to get dmesg from a previous crashed session, so I am attaching dmesg from a session that was started with amdgpu.dpm=0. If this is not what you need, I will need help to find what you need. When the kernel OOPS occurs, the system is completely frozen, and I have to power off with the hardware power button to get back up. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106402] amdgpu causes kernel Oops: 0002 [#1] SMP PTI
https://bugs.freedesktop.org/show_bug.cgi?id=106402 --- Comment #3 from Tim Cuthbertson --- Created attachment 139464 --> https://bugs.freedesktop.org/attachment.cgi?id=139464&action=edit Full dmesg output after reboot -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 105684] Loading amdgpu hits general protection fault: 0000 [#1] SMP NOPTI
https://bugs.freedesktop.org/show_bug.cgi?id=105684 --- Comment #23 from Daniel Drake --- > Is this a regression? If so, when was the last time it worked correctly? Thanks for looking at this. It is not a regression, we have yet to find a kernel which is able to load amdgpu without crashing on these platforms. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [DPU PATCH 02/11] drm/msm/mdp5: subclass msm_mdss for mdp5
On Thu, May 10, 2018 at 01:59:36PM +0530, Rajesh Yadav wrote:
> SoCs having mdp5 or dpu have identical tree like
> device hierarchy where MDSS top level wrapper manages
> common power resources for all child devices.
>
> Subclass msm_mdss so that msm_mdss includes common defines
> and mdp5/dpu mdss derivations to include any extensions.
>
> Add mdss helper interface (msm_mdss_funcs) to msm_mdss
> base for mdp5/dpu mdss specific implementation calls.
>
> This change subclasses msm_mdss for mdp5, dpu specific
> changes will be done separately.
>
> Signed-off-by: Rajesh Yadav
Hi Rajesh,
Thanks for the patch, everything looks good to me aside from one tiny indent
fix. With that resolved, please add my
Reviewed-by: Sean Paul
> ---
> drivers/gpu/drm/msm/disp/mdp5/mdp5_mdss.c | 154
> --
> drivers/gpu/drm/msm/msm_drv.c | 23 +++--
> drivers/gpu/drm/msm/msm_kms.h | 20 ++--
> 3 files changed, 110 insertions(+), 87 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_mdss.c
> b/drivers/gpu/drm/msm/disp/mdp5/mdp5_mdss.c
> index f2a0db7..88190e3 100644
> --- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_mdss.c
> +++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_mdss.c
> -static int mdss_irq_domain_init(struct msm_mdss *mdss)
> +static int mdss_irq_domain_init(struct mdp5_mdss *mdp5_mdss)
> {
> - struct device *dev = mdss->dev->dev;
> + struct device *dev = mdp5_mdss->base.dev->dev;
> struct irq_domain *d;
>
> d = irq_domain_add_linear(dev->of_node, 32, &mdss_hw_irqdomain_ops,
> - mdss);
> + mdp5_mdss);
nit: indent change here
> if (!d) {
> dev_err(dev, "mdss irq domain add failed\n");
> return -ENXIO;
> }
>
> - mdss->irqcontroller.enabled_mask = 0;
> - mdss->irqcontroller.domain = d;
> + mdp5_mdss->irqcontroller.enabled_mask = 0;
> + mdp5_mdss->irqcontroller.domain = d;
>
> return 0;
> }
>
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106428] reported VDDGFX GPU voltage jumps above set limits in pp_od_clk_voltage when UVD is used for VAAPI/VDPAU
https://bugs.freedesktop.org/show_bug.cgi?id=106428 --- Comment #1 from tempel.jul...@gmail.com --- I did some more tests and now I'm very sure that the voltage is just reported wrong when using UVD, and not being actually that high. I also jumps to reported 1.1V without any pstate adjustments or overclock, while the ASIC's default maximum voltage is actually 0.986V. Maybe the UVD got its own voltage of 1.1V, and that is sporadically reported instead of the core GPU voltage when UVD is used? Anyway, not really important since it's just a little glitch and not a real problem. :) -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[pull] amdgpu drm-fixes-4.17
Hi Dave, Regression fix for Fiji cards with high TDP. The following changes since commit 7c2b134110a6af3bfe574efdb23ee04c047dc311: Merge branch 'linux-4.17' of git://github.com/skeggsb/linux into drm-fixes (2018-05-10 13:48:52 +1000) are available in the git repository at: git://people.freedesktop.org/~agd5f/linux drm-fixes-4.17 for you to fetch changes up to 7fc6311b174091e3283c28381e58bed3d12b6591: drm/amd/pp: Fix performance drop on Fiji (2018-05-10 08:25:22 -0500) Rex Zhu (1): drm/amd/pp: Fix performance drop on Fiji drivers/gpu/drm/amd/powerplay/hwmgr/smu7_powertune.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [DPU PATCH 03/11] drm/msm/dpu: add MDSS top level driver for dpu
On Thu, May 10, 2018 at 01:59:37PM +0530, Rajesh Yadav wrote:
> SoCs containing dpu have a MDSS top level wrapper
> which includes sub-blocks as dpu, dsi, phy, dp etc.
> MDSS top level wrapper manages common resources like
> common clocks, power and irq for its sub-blocks.
>
> Currently, in dpu driver, all the power resource
> management is part of power_handle which manages
> these resources via a custom implementation. And
> the resource relationships are not modelled properly
> in dt. Moreover the irq domain handling code is part
> of dpu device (which is a child device) due to lack
> of a dedicated driver for MDSS top level wrapper
> device.
>
> This change adds dpu_mdss top level driver to handle
> common clock like - core clock, ahb clock
> (for register access), main power supply (i.e. gdsc)
> and irq management.
> The top level mdss device/driver acts as an interrupt
> controller and manage hwirq mapping for its child
> devices.
>
> It implements runtime_pm support for resource management.
> Child nodes can control these resources via runtime_pm
> get/put calls on their corresponding devices due to parent
> child relationship defined in dt.
>
> Signed-off-by: Rajesh Yadav
> ---
> drivers/gpu/drm/msm/Makefile | 1 +
> drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c | 97 ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.h | 14 -
> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 9 -
> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h| 7 -
> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c | 29 +--
> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.h | 11 -
> drivers/gpu/drm/msm/disp/dpu1/dpu_irq.c | 48 +---
> drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 6 -
> drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 2 -
> drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c | 301
> ++
> drivers/gpu/drm/msm/dpu_io_util.c | 55
> drivers/gpu/drm/msm/msm_drv.c | 26 +-
> drivers/gpu/drm/msm/msm_drv.h | 2 +-
> drivers/gpu/drm/msm/msm_kms.h | 2 +
> include/linux/dpu_io_util.h | 2 +
> 16 files changed, 390 insertions(+), 222 deletions(-)
> create mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c
> new file mode 100644
> index 000..26bf2c1
> --- /dev/null
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c
> @@ -0,0 +1,301 @@
> +/*
> + * SPDX-License-Identifier: GPL-2.0
> + * Copyright (c) 2018, The Linux Foundation
> + */
> +
> +#include "dpu_kms.h"
> +
> +#define to_dpu_mdss(x) container_of(x, struct dpu_mdss, base)
> +
> +#define HW_INTR_STATUS 0x0010
> +
> +struct dpu_mdss {
> + struct msm_mdss base;
> + void __iomem *mmio;
> + unsigned long mmio_len;
> + u32 hwversion;
> + struct dss_module_power mp;
> + struct dpu_irq_controller irq_controller;
> +};
> +
> +static inline void _dpu_mdss_hw_rev_init(struct dpu_mdss *dpu_mdss)
> +{
> + dpu_mdss->hwversion = readl_relaxed(dpu_mdss->mmio + 0x0);
> +}
This function probably doesn't need to exist, just put the assignment in
dpu_mdss_init()
> +
> +static int _dpu_mdss_get_intr_sources(struct dpu_mdss *dpu_mdss,
> + uint32_t *sources)
> +{
> + *sources = readl_relaxed(dpu_mdss->mmio + HW_INTR_STATUS);
> + return 0;
> +}
Same here. Additionally, this function returns an errval that is always
successful and never checked, so you won't have to worry about that :)
> +
> +static irqreturn_t dpu_mdss_irq(int irq, void *arg)
> +{
> + struct dpu_mdss *dpu_mdss = arg;
> + u32 interrupts;
> +
> + if (!arg)
> + return IRQ_NONE;
> +
> + _dpu_mdss_get_intr_sources(dpu_mdss, &interrupts);
> +
> + while (interrupts) {
> + irq_hw_number_t hwirq = fls(interrupts) - 1;
> + unsigned int mapping;
> + int rc;
> +
> + mapping = irq_find_mapping(dpu_mdss->irq_controller.domain,
> + hwirq);
Line this up with dpu_mdss->irq_controller.domain
> + if (mapping == 0) {
> + DPU_EVT32(hwirq, DPU_EVTLOG_ERROR);
> + goto error;
Just return IRQ_NONE
> + }
> +
> + rc = generic_handle_irq(mapping);
> + if (rc < 0) {
> + DPU_EVT32(hwirq, mapping, rc, DPU_EVTLOG_ERROR);
> + goto error;
Same here, and remove the label
> + }
> +
> + interrupts &= ~(1 << hwirq);
> + }
> +
> + return IRQ_HANDLED;
> +
> +error:
> + /* bad situation, inform irq system, it may disable overall MDSS irq */
> + return IRQ_NONE;
> +}
> +
> +static void dpu_mdss_irq_mask(struct irq_data *irqd)
> +{
> + struct dpu_mdss *dpu_mdss;
> +
> + if (!irqd || !ir
Re: [PATCH] display: panel: Add KOE tx14d24vm1bpa display support (320x240)
On Fri, May 4, 2018 at 5:28 AM, Lukasz Majewski wrote: > Hi Rob, > >> On Thu, Apr 12, 2018 at 04:37:15PM +0200, Lukasz Majewski wrote: >> > This commit adds support for KOE's 5.7" display. >> > >> > Signed-off-by: Lukasz Majewski >> > --- >> > .../bindings/display/panel/koe,tx14d24vm1bpa.txt | 42 >> > ++ >> > drivers/gpu/drm/panel/panel-simple.c | 26 >> > ++ 2 files changed, 68 insertions(+) create mode 100644 >> > Documentation/devicetree/bindings/display/panel/koe,tx14d24vm1bpa.txt >> >> Reviewed-by: Rob Herring >> > > Gentle ping on this - as I don't know if this patch been applied. This should go thru DRM tree via Thierry. Rob ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RESEND] display: panel: Add KOE tx14d24vm1bpa display support (320x240)
On Wed, May 9, 2018 at 10:43 AM, Lukasz Majewski wrote: > This commit adds support for KOE's 5.7" display. > > Signed-off-by: Lukasz Majewski Please add ack/reviewed-by's when posting new versions. Rob ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/ttm: specify bo priority when initializing ttm bo
Am 10.05.2018 um 07:01 schrieb Junwei Zhang:
Expect to add an evitable bo who has reservation object
to the correct lru[bo->priority] list
Nice catch, but since this affects only a very small use case can we
just remove and readd the BO to the LRU?
A call to ttm_bo_move_to_lru_tail() after setting the priority should be
sufficient.
Thanks,
Christian.
Signed-off-by: Junwei Zhang
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 11 ++-
drivers/gpu/drm/ast/ast_ttm.c | 2 +-
drivers/gpu/drm/bochs/bochs_mm.c| 2 +-
drivers/gpu/drm/cirrus/cirrus_ttm.c | 2 +-
drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c | 2 +-
drivers/gpu/drm/mgag200/mgag200_ttm.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_bo.c| 2 +-
drivers/gpu/drm/qxl/qxl_object.c| 2 +-
drivers/gpu/drm/radeon/radeon_object.c | 2 +-
drivers/gpu/drm/ttm/ttm_bo.c| 8 +---
drivers/gpu/drm/virtio/virtgpu_object.c | 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_resource.c| 2 +-
drivers/staging/vboxvideo/vbox_ttm.c| 2 +-
include/drm/ttm/ttm_bo_api.h| 5 -
14 files changed, 26 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index e62153a..9a25ecb 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -360,6 +360,7 @@ static int amdgpu_bo_do_create(struct amdgpu_device *adev,
};
struct amdgpu_bo *bo;
unsigned long page_align, size = bp->size;
+ uint32_t prio = 0;
size_t acc_size;
int r;
@@ -419,10 +420,13 @@ static int amdgpu_bo_do_create(struct amdgpu_device *adev,
bo->tbo.bdev = &adev->mman.bdev;
amdgpu_ttm_placement_from_domain(bo, bp->domain);
+ if (bp->type == ttm_bo_type_kernel)
+ prio = 1;
r = ttm_bo_init_reserved(&adev->mman.bdev, &bo->tbo, size, bp->type,
-&bo->placement, page_align, &ctx, acc_size,
-NULL, bp->resv, &amdgpu_ttm_bo_destroy);
+prio, &bo->placement, page_align, &ctx,
+acc_size, NULL, bp->resv,
+&amdgpu_ttm_bo_destroy);
if (unlikely(r != 0))
return r;
@@ -434,9 +438,6 @@ static int amdgpu_bo_do_create(struct amdgpu_device *adev,
else
amdgpu_cs_report_moved_bytes(adev, ctx.bytes_moved, 0);
- if (bp->type == ttm_bo_type_kernel)
- bo->tbo.priority = 1;
-
if (bp->flags & AMDGPU_GEM_CREATE_VRAM_CLEARED &&
bo->tbo.mem.placement & TTM_PL_FLAG_VRAM) {
struct dma_fence *fence;
diff --git a/drivers/gpu/drm/ast/ast_ttm.c b/drivers/gpu/drm/ast/ast_ttm.c
index fe354eb..aabb96a 100644
--- a/drivers/gpu/drm/ast/ast_ttm.c
+++ b/drivers/gpu/drm/ast/ast_ttm.c
@@ -320,7 +320,7 @@ int ast_bo_create(struct drm_device *dev, int size, int
align,
sizeof(struct ast_bo));
ret = ttm_bo_init(&ast->ttm.bdev, &astbo->bo, size,
- ttm_bo_type_device, &astbo->placement,
+ ttm_bo_type_device, 0, &astbo->placement,
align >> PAGE_SHIFT, false, acc_size,
NULL, NULL, ast_bo_ttm_destroy);
if (ret)
diff --git a/drivers/gpu/drm/bochs/bochs_mm.c b/drivers/gpu/drm/bochs/bochs_mm.c
index 39cd084..9693109 100644
--- a/drivers/gpu/drm/bochs/bochs_mm.c
+++ b/drivers/gpu/drm/bochs/bochs_mm.c
@@ -366,7 +366,7 @@ static int bochs_bo_create(struct drm_device *dev, int
size, int align,
sizeof(struct bochs_bo));
ret = ttm_bo_init(&bochs->ttm.bdev, &bochsbo->bo, size,
- ttm_bo_type_device, &bochsbo->placement,
+ ttm_bo_type_device, 0, &bochsbo->placement,
align >> PAGE_SHIFT, false, acc_size,
NULL, NULL, bochs_bo_ttm_destroy);
if (ret)
diff --git a/drivers/gpu/drm/cirrus/cirrus_ttm.c
b/drivers/gpu/drm/cirrus/cirrus_ttm.c
index f219532..c1d85f8 100644
--- a/drivers/gpu/drm/cirrus/cirrus_ttm.c
+++ b/drivers/gpu/drm/cirrus/cirrus_ttm.c
@@ -327,7 +327,7 @@ int cirrus_bo_create(struct drm_device *dev, int size, int
align,
sizeof(struct cirrus_bo));
ret = ttm_bo_init(&cirrus->ttm.bdev, &cirrusbo->bo, size,
- ttm_bo_type_device, &cirrusbo->placement,
+ ttm_bo_type_device, 0, &cirrusbo->placement,
align >> PAGE_SHIFT, false, acc_size,
NULL, NULL, cirrus_bo_ttm_destroy);
if (ret)
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c
index 4871025..8c24731
Re: [DPU PATCH 04/11] drm/msm/dpu: create new platform driver for dpu device
On Thu, May 10, 2018 at 01:59:38PM +0530, Rajesh Yadav wrote:
> Current MSM display controller HW matches a tree like
> hierarchy where MDSS top level wrapper is parent device
> and mdp5/dpu, dsi, dp are child devices.
>
> Each child device like mdp5, dsi etc. have a separate driver,
> but currently dpu handling is tied to a single driver which
> was managing both mdss and dpu resources.
>
> Inorder to have the cleaner one to one device and driver
> association, this change adds a new platform_driver for dpu
> child device node which implements the kms functionality.
>
> The dpu driver implements runtime_pm support for managing clocks
> and bus bandwidth etc.
>
> Signed-off-by: Rajesh Yadav
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 251
> ++--
> drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 4 +
> drivers/gpu/drm/msm/msm_drv.c | 2 +
> drivers/gpu/drm/msm/msm_drv.h | 3 +
> 4 files changed, 214 insertions(+), 46 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> index e4ab753..2cd51fc 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> @@ -1030,14 +1030,13 @@ static long dpu_kms_round_pixclk(struct msm_kms *kms,
> unsigned long rate,
> return rate;
> }
>
> -static void _dpu_kms_hw_destroy(struct dpu_kms *dpu_kms,
> - struct platform_device *pdev)
> +static void _dpu_kms_hw_destroy(struct dpu_kms *dpu_kms)
> {
> struct drm_device *dev;
> struct msm_drm_private *priv;
> int i;
>
> - if (!dpu_kms || !pdev)
> + if (!dpu_kms)
This isn't possible, please remove.
> return;
>
> dev = dpu_kms->dev;
> @@ -1091,15 +1090,15 @@ static void _dpu_kms_hw_destroy(struct dpu_kms
> *dpu_kms,
> dpu_kms->core_client = NULL;
>
> if (dpu_kms->vbif[VBIF_NRT])
> - msm_iounmap(pdev, dpu_kms->vbif[VBIF_NRT]);
> + msm_iounmap(dpu_kms->pdev, dpu_kms->vbif[VBIF_NRT]);
> dpu_kms->vbif[VBIF_NRT] = NULL;
>
> if (dpu_kms->vbif[VBIF_RT])
> - msm_iounmap(pdev, dpu_kms->vbif[VBIF_RT]);
> + msm_iounmap(dpu_kms->pdev, dpu_kms->vbif[VBIF_RT]);
> dpu_kms->vbif[VBIF_RT] = NULL;
>
> if (dpu_kms->mmio)
> - msm_iounmap(pdev, dpu_kms->mmio);
> + msm_iounmap(dpu_kms->pdev, dpu_kms->mmio);
> dpu_kms->mmio = NULL;
>
> dpu_reg_dma_deinit();
> +static void dpu_destroy(struct platform_device *pdev)
> +{
> + struct dpu_kms *dpu_kms = platform_get_drvdata(pdev);
> + struct dss_module_power *mp = &dpu_kms->mp;
> +
> + msm_dss_put_clk(mp->clk_config, mp->num_clk);
> + devm_kfree(&pdev->dev, mp->clk_config);
> + mp->num_clk = 0;
> +
> + if (dpu_kms->rpm_enabled)
> + pm_runtime_disable(&pdev->dev);
> +
> + devm_kfree(&pdev->dev, dpu_kms);
devm_kfrees are not necessary
> +}
>
> - dpu_kms = kzalloc(sizeof(*dpu_kms), GFP_KERNEL);
> +static int dpu_init(struct platform_device *pdev, struct drm_device *dev)
> +{
> + struct msm_drm_private *priv = dev->dev_private;
> + struct dpu_kms *dpu_kms;
> + struct dss_module_power *mp;
> + int ret = 0;
> +
> + dpu_kms = devm_kzalloc(&pdev->dev, sizeof(*dpu_kms), GFP_KERNEL);
> if (!dpu_kms) {
> DPU_ERROR("failed to allocate dpu kms\n");
> - return ERR_PTR(-ENOMEM);
> + return -ENOMEM;
> + }
> +
> + mp = &dpu_kms->mp;
> + ret = msm_dss_parse_clock(pdev, mp);
> + if (ret) {
> + DPU_ERROR("failed to parse clocks, ret=%d\n", ret);
> + goto clk_parse_error;
> + }
> +
> + ret = msm_dss_get_clk(&pdev->dev, mp->clk_config, mp->num_clk);
> + if (ret) {
> + pr_err("failed to get clocks, ret=%d\n", ret);
> + goto clk_get_error;
> + }
> +
> + ret = msm_dss_clk_set_rate(mp->clk_config, mp->num_clk);
> + if (ret) {
> + pr_err("failed to set clock rate, ret=%d\n", ret);
> + goto clk_rate_error;
> }
>
> + platform_set_drvdata(pdev, dpu_kms);
> +
> msm_kms_init(&dpu_kms->base, &kms_funcs);
> dpu_kms->dev = dev;
> - dpu_kms->base.irq = irq;
> + dpu_kms->pdev = pdev;
>
> - return &dpu_kms->base;
> + pm_runtime_enable(&pdev->dev);
> + dpu_kms->rpm_enabled = true;
> +
> + priv->kms = &dpu_kms->base;
> +
> + return ret;
> +
> +clk_rate_error:
> + msm_dss_put_clk(mp->clk_config, mp->num_clk);
> +clk_get_error:
> + devm_kfree(&pdev->dev, mp->clk_config);
> + mp->num_clk = 0;
> +clk_parse_error:
> + devm_kfree(&pdev->dev, dpu_kms);
> +
> + return ret;
> +}
> +
> +static int dpu_bind(struct device *dev, struct device *master, void *data)
> +{
> + struct drm_device *ddev = dev_get_drvdata(master);
> + struct platform_device *pdev = to_platform_device(dev);
> +
> + re
Re: [DPU PATCH 01/11] drm/msm: remove redundant pm_runtime_enable call from msm_drv
On Thu, May 10, 2018 at 01:59:35PM +0530, Rajesh Yadav wrote: > MDSS top level device includes the common power resources > and it's corresponding driver (i.e. mdp5_mdss) handles call > to enable/disable runtime_pm for enabling these resources. > Remove redundant pm_runtime_enable call from msm_drv. > > Signed-off-by: Rajesh Yadav Reviewed-by: Sean Paul > --- > drivers/gpu/drm/msm/msm_drv.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c > index ebc40a9..9bb436f 100644 > --- a/drivers/gpu/drm/msm/msm_drv.c > +++ b/drivers/gpu/drm/msm/msm_drv.c > @@ -581,7 +581,6 @@ static int msm_drm_init(struct device *dev, struct > drm_driver *drv) > goto fail; > } > priv->kms = kms; > - pm_runtime_enable(dev); > > /** >* Since kms->funcs->hw_init(kms) might call > -- > The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, > a Linux Foundation Collaborative Project > -- Sean Paul, Software Engineer, Google / Chromium OS ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [DPU PATCH 05/11] drm/msm/dpu: update dpu sub-block offsets wrt dpu base address
On Thu, May 10, 2018 at 01:59:39PM +0530, Rajesh Yadav wrote:
> The dpu sub-block offsets were defined wrt mdss base address
> instead of dpu base address.
> Since, dpu is now defined as a separate device, update hw catalog
> offsets for all dpu sub blocks wrt dpu base address.
>
> Signed-off-by: Rajesh Yadav
Reviewed-by: Sean Paul
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 68
> +++
> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c | 18 +++---
> 2 files changed, 43 insertions(+), 43 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> index c5b370f..2fd3254 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> @@ -80,7 +80,7 @@
> static struct dpu_mdp_cfg sdm845_mdp[] = {
> {
> .name = "top_0", .id = MDP_TOP,
> - .base = 0x1000, .len = 0x45C,
> + .base = 0x0, .len = 0x45C,
> .features = 0,
> .highest_bank_bit = 0x2,
> .has_dest_scaler = true,
> @@ -111,27 +111,27 @@
> static struct dpu_ctl_cfg sdm845_ctl[] = {
> {
> .name = "ctl_0", .id = CTL_0,
> - .base = 0x2000, .len = 0xE4,
> + .base = 0x1000, .len = 0xE4,
> .features = BIT(DPU_CTL_SPLIT_DISPLAY)
> },
> {
> .name = "ctl_1", .id = CTL_1,
> - .base = 0x2200, .len = 0xE4,
> + .base = 0x1200, .len = 0xE4,
> .features = BIT(DPU_CTL_SPLIT_DISPLAY)
> },
> {
> .name = "ctl_2", .id = CTL_2,
> - .base = 0x2400, .len = 0xE4,
> + .base = 0x1400, .len = 0xE4,
> .features = 0
> },
> {
> .name = "ctl_3", .id = CTL_3,
> - .base = 0x2600, .len = 0xE4,
> + .base = 0x1600, .len = 0xE4,
> .features = 0
> },
> {
> .name = "ctl_4", .id = CTL_4,
> - .base = 0x2800, .len = 0xE4,
> + .base = 0x1800, .len = 0xE4,
> .features = 0
> },
> };
> @@ -211,21 +211,21 @@
> }
>
> static struct dpu_sspp_cfg sdm845_sspp[] = {
> - SSPP_VIG_BLK("sspp_0", SSPP_VIG0, 0x5000,
> + SSPP_VIG_BLK("sspp_0", SSPP_VIG0, 0x4000,
> sdm845_vig_sblk_0, 0, DPU_CLK_CTRL_VIG0),
> - SSPP_VIG_BLK("sspp_1", SSPP_VIG1, 0x7000,
> + SSPP_VIG_BLK("sspp_1", SSPP_VIG1, 0x6000,
> sdm845_vig_sblk_1, 4, DPU_CLK_CTRL_VIG1),
> - SSPP_VIG_BLK("sspp_2", SSPP_VIG2, 0x9000,
> + SSPP_VIG_BLK("sspp_2", SSPP_VIG2, 0x8000,
> sdm845_vig_sblk_2, 8, DPU_CLK_CTRL_VIG2),
> - SSPP_VIG_BLK("sspp_3", SSPP_VIG3, 0xb000,
> + SSPP_VIG_BLK("sspp_3", SSPP_VIG3, 0xa000,
> sdm845_vig_sblk_3, 12, DPU_CLK_CTRL_VIG3),
> - SSPP_DMA_BLK("sspp_8", SSPP_DMA0, 0x25000,
> + SSPP_DMA_BLK("sspp_8", SSPP_DMA0, 0x24000,
> sdm845_dma_sblk_0, 1, DPU_CLK_CTRL_DMA0),
> - SSPP_DMA_BLK("sspp_9", SSPP_DMA1, 0x27000,
> + SSPP_DMA_BLK("sspp_9", SSPP_DMA1, 0x26000,
> sdm845_dma_sblk_1, 5, DPU_CLK_CTRL_DMA1),
> - SSPP_DMA_BLK("sspp_10", SSPP_DMA2, 0x29000,
> + SSPP_DMA_BLK("sspp_10", SSPP_DMA2, 0x28000,
> sdm845_dma_sblk_2, 9, DPU_CLK_CTRL_CURSOR0),
> - SSPP_DMA_BLK("sspp_11", SSPP_DMA3, 0x2b000,
> + SSPP_DMA_BLK("sspp_11", SSPP_DMA3, 0x2a000,
> sdm845_dma_sblk_3, 13, DPU_CLK_CTRL_CURSOR1),
> };
>
> @@ -252,17 +252,17 @@
> .lm_pair_mask = (1 << _lmpair) \
> }
> static struct dpu_lm_cfg sdm845_lm[] = {
> - LM_BLK("lm_0", LM_0, 0x45000, DSPP_0,
> + LM_BLK("lm_0", LM_0, 0x44000, DSPP_0,
> DS_0, PINGPONG_0, LM_1),
> - LM_BLK("lm_1", LM_1, 0x46000, DSPP_1,
> + LM_BLK("lm_1", LM_1, 0x45000, DSPP_1,
> DS_1, PINGPONG_1, LM_0),
> - LM_BLK("lm_2", LM_2, 0x47000, DSPP_2,
> + LM_BLK("lm_2", LM_2, 0x46000, DSPP_2,
> DS_MAX, PINGPONG_2, LM_5),
> LM_BLK("lm_3", LM_3, 0x0, DSPP_MAX,
> DS_MAX, PINGPONG_MAX, 0),
> LM_BLK("lm_4", LM_4, 0x0, DSPP_MAX,
> DS_MAX, PINGPONG_MAX, 0),
> - LM_BLK("lm_5", LM_5, 0x4a000, DSPP_3,
> + LM_BLK("lm_5", LM_5, 0x49000, DSPP_3,
> DS_MAX, PINGPONG_3, LM_2),
> };
>
> @@ -270,7 +270,7 @@
> * DSPP sub blocks config
> */
> static struct dpu_dspp_top_cfg sdm845_dspp_top = {
> - .name = "dspp_top", .base = 0x1300, .len = 0xc
> + .name = "dspp_top", .base = 0x300, .len = 0xc
> };
>
> static const struct dpu_dspp_sub_blks sdm845_dspp_sblk = {
> @@ -304,10 +304,10 @@
> }
>
> static struct dpu_dspp_cfg sdm845_dspp[] = {
> - DSPP_BLK("dspp_0", DSPP_0, 0x55000),
> - DSPP_BLK("dspp_1", DSPP_1, 0x57000),
> - DSPP_BLK("dspp_2", DSPP_2, 0x59000),
> - DSPP_BLK("dspp_3", DSPP_3, 0x5b000),
> + DSPP_BLK("dspp_0", DSPP_0, 0x54000),
> + DSPP_BLK("dspp_1", DSPP_1, 0x56000),
> + DSPP_BLK("dspp_2", DSPP_2, 0x58000),
> + DSPP_BLK("dspp_3", DSPP_3, 0x5a00
Re: [DPU PATCH 06/11] drm/msm/dpu: use runtime_pm calls on dpu device
On Thu, May 10, 2018 at 01:59:40PM +0530, Rajesh Yadav wrote:
> The dpu driver implements runtime_pm support for managing
> dpu specific resources like - clocks, bus bandwidth etc.
>
> Use pm_runtime_get/put_sync calls on dpu device.
>
> The common clocks and power management for all child nodes
> (mdp5/dpu, dsi, dp etc) is done by parent MDSS device/driver
> via runtime_pm due to parent child relationship.
>
> Signed-off-by: Rajesh Yadav
Reviewed-by: Sean Paul
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c | 8 ++---
> drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 12
> drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 16 +-
> drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 45
> +++-
> drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c| 6 ++--
> 5 files changed, 31 insertions(+), 56 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c
> index 977adc4..5c5cc56 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c
> @@ -452,10 +452,10 @@ void dpu_core_irq_preinstall(struct dpu_kms *dpu_kms)
> }
> priv = dpu_kms->dev->dev_private;
>
> - dpu_power_resource_enable(&priv->phandle, dpu_kms->core_client, true);
> + pm_runtime_get_sync(&dpu_kms->pdev->dev);
> dpu_clear_all_irqs(dpu_kms);
> dpu_disable_all_irqs(dpu_kms);
> - dpu_power_resource_enable(&priv->phandle, dpu_kms->core_client, false);
> + pm_runtime_put_sync(&dpu_kms->pdev->dev);
>
> spin_lock_init(&dpu_kms->irq_obj.cb_lock);
>
> @@ -496,7 +496,7 @@ void dpu_core_irq_uninstall(struct dpu_kms *dpu_kms)
> }
> priv = dpu_kms->dev->dev_private;
>
> - dpu_power_resource_enable(&priv->phandle, dpu_kms->core_client, true);
> + pm_runtime_get_sync(&dpu_kms->pdev->dev);
> for (i = 0; i < dpu_kms->irq_obj.total_irqs; i++)
> if (atomic_read(&dpu_kms->irq_obj.enable_counts[i]) ||
> !list_empty(&dpu_kms->irq_obj.irq_cb_tbl[i]))
> @@ -504,7 +504,7 @@ void dpu_core_irq_uninstall(struct dpu_kms *dpu_kms)
>
> dpu_clear_all_irqs(dpu_kms);
> dpu_disable_all_irqs(dpu_kms);
> - dpu_power_resource_enable(&priv->phandle, dpu_kms->core_client, false);
> + pm_runtime_put_sync(&dpu_kms->pdev->dev);
>
> kfree(dpu_kms->irq_obj.irq_cb_tbl);
> kfree(dpu_kms->irq_obj.enable_counts);
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> index 48920b05..e2d2e32 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> @@ -86,8 +86,12 @@ static inline int _dpu_crtc_power_enable(struct dpu_crtc
> *dpu_crtc, bool enable)
>
> dpu_kms = to_dpu_kms(priv->kms);
>
> - return dpu_power_resource_enable(&priv->phandle, dpu_kms->core_client,
> - enable);
> + if (enable)
> + pm_runtime_get_sync(&dpu_kms->pdev->dev);
> + else
> + pm_runtime_put_sync(&dpu_kms->pdev->dev);
> +
> + return 0;
> }
>
> /**
> @@ -2250,7 +2254,6 @@ static int _dpu_crtc_vblank_enable_no_lock(
>
> /* drop lock since power crtc cb may try to re-acquire lock */
> mutex_unlock(&dpu_crtc->crtc_lock);
> - pm_runtime_get_sync(dev->dev);
> ret = _dpu_crtc_power_enable(dpu_crtc, true);
> mutex_lock(&dpu_crtc->crtc_lock);
> if (ret)
> @@ -2580,7 +2583,6 @@ static void dpu_crtc_disable(struct drm_crtc *crtc)
> /* disable clk & bw control until clk & bw properties are set */
> cstate->bw_control = false;
> cstate->bw_split_vote = false;
> - pm_runtime_put_sync(crtc->dev->dev);
>
> mutex_unlock(&dpu_crtc->crtc_lock);
> }
> @@ -2611,8 +2613,6 @@ static void dpu_crtc_enable(struct drm_crtc *crtc,
> return;
> }
>
> - pm_runtime_get_sync(crtc->dev->dev);
> -
> drm_for_each_encoder(encoder, crtc->dev) {
> if (encoder->crtc != crtc)
> continue;
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> index 4386360..298a6ef 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> @@ -268,8 +268,12 @@ static inline int _dpu_encoder_power_enable(struct
> dpu_encoder_virt *dpu_enc,
>
> dpu_kms = to_dpu_kms(priv->kms);
>
> - return dpu_power_resource_enable(&priv->phandle, dpu_kms->core_client,
> - enable);
> + if (enable)
> + pm_runtime_get_sync(&dpu_kms->pdev->dev);
> + else
> + pm_runtime_put_sync(&dpu_kms->pdev->dev);
> +
> + return 0;
> }
>
> void dpu_encoder_helper_report_irq_time
Re: [DPU PATCH 07/11] drm/msm/dpu: remove clock management code from dpu_power_handle
On Thu, May 10, 2018 at 01:59:41PM +0530, Rajesh Yadav wrote:
> MDSS and dpu drivers manage their respective clocks via
> runtime_pm. Remove custom clock management code from
> dpu_power_handle.
>
> Also dpu core clock management code is restricted to
> dpu_core_perf module.
>
> Signed-off-by: Rajesh Yadav
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 44 ++---
> drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h | 8 +-
> .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 5 +-
> drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c| 32 +++-
> drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h| 9 +
> drivers/gpu/drm/msm/dpu_power_handle.c | 195
> +
> drivers/gpu/drm/msm/dpu_power_handle.h | 40 -
> 7 files changed, 69 insertions(+), 264 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
> index 981f77f..d1364fa 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
> @@ -365,6 +365,20 @@ void dpu_core_perf_crtc_release_bw(struct drm_crtc *crtc)
> }
> }
>
> +static int _dpu_core_perf_set_core_clk_rate(struct dpu_kms *kms, u64 rate)
> +{
> + struct dss_clk *core_clk = kms->perf.core_clk;
> + int rc = -EINVAL;
No need to initialize this.
> +
> + if (core_clk->max_rate && (rate > core_clk->max_rate))
> + rate = core_clk->max_rate;
> +
> + core_clk->rate = rate;
> + rc = msm_dss_clk_set_rate(core_clk, 1);
> +
> + return rc;
return msm_dss_clk_set_rate(core_clk, 1);
and get rid of rc entirely
> +}
> +
> static u64 _dpu_core_perf_get_core_clk_rate(struct dpu_kms *kms)
> {
> u64 clk_rate = kms->perf.perf_tune.min_core_clk;
> @@ -376,7 +390,8 @@ static u64 _dpu_core_perf_get_core_clk_rate(struct
> dpu_kms *kms)
> dpu_cstate = to_dpu_crtc_state(crtc->state);
> clk_rate = max(dpu_cstate->new_perf.core_clk_rate,
> clk_rate);
> - clk_rate = clk_round_rate(kms->perf.core_clk, clk_rate);
> + clk_rate = clk_round_rate(kms->perf.core_clk->clk,
> + clk_rate);
> }
> }
>
> @@ -484,15 +499,11 @@ void dpu_core_perf_crtc_update(struct drm_crtc *crtc,
This function should really propagate the errors. I realize they're eventually
dropped in the frame event worker, but we should still return an error here in
case the worker ever wants to use it (and it should be the one to decide to drop
it if that's the best decision). Although this wasn't introduced with your
patch, could you please add a small patch to the v2 to add this?
>
> DPU_EVT32(kms->dev, stop_req, clk_rate);
>
> - /* Temp change to avoid crash in clk_set_rate API. */
> -#ifdef QCOM_DPU_SET_CLK
> - if (dpu_power_clk_set_rate(&priv->phandle,
> -kms->perf.clk_name, clk_rate)) {
> + if (_dpu_core_perf_set_core_clk_rate(kms, clk_rate)) {
> DPU_ERROR("failed to set %s clock rate %llu\n",
> - kms->perf.clk_name, clk_rate);
> + kms->perf.core_clk->clk_name, clk_rate);
> return;
> }
> -#endif
>
> kms->perf.core_clk_rate = clk_rate;
> DPU_DEBUG("update clk rate = %lld HZ\n", clk_rate);
> @@ -656,7 +667,6 @@ void dpu_core_perf_destroy(struct dpu_core_perf *perf)
> dpu_core_perf_debugfs_destroy(perf);
> perf->max_core_clk_rate = 0;
> perf->core_clk = NULL;
> - perf->clk_name = NULL;
> perf->phandle = NULL;
> perf->catalog = NULL;
> perf->dev = NULL;
> @@ -667,9 +677,9 @@ int dpu_core_perf_init(struct dpu_core_perf *perf,
> struct dpu_mdss_cfg *catalog,
> struct dpu_power_handle *phandle,
> struct dpu_power_client *pclient,
> - char *clk_name)
> + struct dss_clk *core_clk)
> {
> - if (!perf || !dev || !catalog || !phandle || !pclient || !clk_name) {
> + if (!perf || !dev || !catalog || !phandle || !pclient || !core_clk) {
These blind NULL checks drive me a little crazy. How many of these can
_actually_ be NULL? When we encounter these, we should evaluate and trim them so
as not to clutter up every function with superfluous checks.
> DPU_ERROR("invalid parameters\n");
> return -EINVAL;
> }
> @@ -678,23 +688,13 @@ int dpu_core_perf_init(struct dpu_core_perf *perf,
> perf->catalog = catalog;
> perf->phandle = phandle;
> perf->pclient = pclient;
> - perf->clk_name = clk_name;
> + perf->core_clk = core_clk;
>
> - perf->core_clk = dpu_power_clk_get_clk(phandle, clk_name);
> - if (!perf->co
Re: [DPU PATCH 08/11] drm/msm/dpu: remove power management code from dpu_power_handle
On Thu, May 10, 2018 at 01:59:42PM +0530, Rajesh Yadav wrote:
> Mdss main power supply (mdss_gdsc) is implemented as a
> generic power domain and mdss top level wrapper device
> manage it via runtime_pm. Remove custom power management
> code from dpu_power_handle.
>
> Signed-off-by: Rajesh Yadav
Reviewed-by: Sean Paul
> ---
> drivers/gpu/drm/msm/dpu_power_handle.c | 190
> +
> drivers/gpu/drm/msm/dpu_power_handle.h | 2 -
> 2 files changed, 1 insertion(+), 191 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/dpu_power_handle.c
> b/drivers/gpu/drm/msm/dpu_power_handle.c
> index 17bae4b..909fbb8 100644
> --- a/drivers/gpu/drm/msm/dpu_power_handle.c
> +++ b/drivers/gpu/drm/msm/dpu_power_handle.c
> @@ -101,150 +101,6 @@ void dpu_power_client_destroy(struct dpu_power_handle
> *phandle,
> }
> }
>
> -static int dpu_power_parse_dt_supply(struct platform_device *pdev,
> - struct dss_module_power *mp)
> -{
> - int i = 0, rc = 0;
> - u32 tmp = 0;
> - struct device_node *of_node = NULL, *supply_root_node = NULL;
> - struct device_node *supply_node = NULL;
> -
> - if (!pdev || !mp) {
> - pr_err("invalid input param pdev:%pK mp:%pK\n", pdev, mp);
> - return -EINVAL;
> - }
> -
> - of_node = pdev->dev.of_node;
> -
> - mp->num_vreg = 0;
> - supply_root_node = of_get_child_by_name(of_node,
> - "qcom,platform-supply-entries");
> - if (!supply_root_node) {
> - pr_debug("no supply entry present\n");
> - return rc;
> - }
> -
> - for_each_child_of_node(supply_root_node, supply_node)
> - mp->num_vreg++;
> -
> - if (mp->num_vreg == 0) {
> - pr_debug("no vreg\n");
> - return rc;
> - }
> -
> - pr_debug("vreg found. count=%d\n", mp->num_vreg);
> - mp->vreg_config = devm_kzalloc(&pdev->dev, sizeof(struct dss_vreg) *
> - mp->num_vreg, GFP_KERNEL);
> - if (!mp->vreg_config) {
> - rc = -ENOMEM;
> - return rc;
> - }
> -
> - for_each_child_of_node(supply_root_node, supply_node) {
> -
> - const char *st = NULL;
> -
> - rc = of_property_read_string(supply_node,
> - "qcom,supply-name", &st);
> - if (rc) {
> - pr_err("error reading name. rc=%d\n", rc);
> - goto error;
> - }
> -
> - strlcpy(mp->vreg_config[i].vreg_name, st,
> - sizeof(mp->vreg_config[i].vreg_name));
> -
> - rc = of_property_read_u32(supply_node,
> - "qcom,supply-min-voltage", &tmp);
> - if (rc) {
> - pr_err("error reading min volt. rc=%d\n", rc);
> - goto error;
> - }
> - mp->vreg_config[i].min_voltage = tmp;
> -
> - rc = of_property_read_u32(supply_node,
> - "qcom,supply-max-voltage", &tmp);
> - if (rc) {
> - pr_err("error reading max volt. rc=%d\n", rc);
> - goto error;
> - }
> - mp->vreg_config[i].max_voltage = tmp;
> -
> - rc = of_property_read_u32(supply_node,
> - "qcom,supply-enable-load", &tmp);
> - if (rc) {
> - pr_err("error reading enable load. rc=%d\n", rc);
> - goto error;
> - }
> - mp->vreg_config[i].enable_load = tmp;
> -
> - rc = of_property_read_u32(supply_node,
> - "qcom,supply-disable-load", &tmp);
> - if (rc) {
> - pr_err("error reading disable load. rc=%d\n", rc);
> - goto error;
> - }
> - mp->vreg_config[i].disable_load = tmp;
> -
> - rc = of_property_read_u32(supply_node,
> - "qcom,supply-pre-on-sleep", &tmp);
> - if (rc)
> - pr_debug("error reading supply pre sleep value.
> rc=%d\n",
> - rc);
> -
> - mp->vreg_config[i].pre_on_sleep = (!rc ? tmp : 0);
> -
> - rc = of_property_read_u32(supply_node,
> - "qcom,supply-pre-off-sleep", &tmp);
> - if (rc)
> - pr_debug("error reading supply pre sleep value.
> rc=%d\n",
> - rc);
> -
> - mp->vreg_config[i].pre_off_sleep = (!rc ? tmp : 0);
> -
> - rc = of_property_read_u32(supply_node,
> - "qcom,supply-post-on-sleep", &tmp);
> - if (rc)
> - pr_
Re: [DPU PATCH 09/11] drm/msm/dp: remove dpu_power_handle calls from dp driver
On Thu, May 10, 2018 at 01:59:43PM +0530, Rajesh Yadav wrote:
> DP driver was dependent on dpu_power_handle for MDSS
> common clocks and gdsc (main power supply).
> The common clocks and power is managed by MDSS top
> wrapper device now which is parent of all sub-devices
> like DP device.
> For same reason, clock and power management code is
> removed from dpu_power_handle. Hence, remove the
> dpu_power_handle calls from dp driver.
>
> Signed-off-by: Rajesh Yadav
Reviewed-by: Sean Paul
> ---
> drivers/gpu/drm/msm/dp/dp_power.c | 32 +---
> drivers/gpu/drm/msm/dp/dp_power.h | 4 +---
> 2 files changed, 2 insertions(+), 34 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/dp/dp_power.c
> b/drivers/gpu/drm/msm/dp/dp_power.c
> index f6e341b..2a85b38 100644
> --- a/drivers/gpu/drm/msm/dp/dp_power.c
> +++ b/drivers/gpu/drm/msm/dp/dp_power.c
> @@ -26,8 +26,6 @@ struct dp_power_private {
> struct clk *pixel_parent;
>
> struct dp_power dp_power;
> - struct dpu_power_client *dp_core_client;
> - struct dpu_power_handle *phandle;
>
> bool core_clks_on;
> bool link_clks_on;
> @@ -410,8 +408,7 @@ static int dp_power_config_gpios(struct dp_power_private
> *power, bool flip,
> return 0;
> }
>
> -static int dp_power_client_init(struct dp_power *dp_power,
> - struct dpu_power_handle *phandle)
> +static int dp_power_client_init(struct dp_power *dp_power)
> {
> int rc = 0;
> struct dp_power_private *power;
> @@ -436,19 +433,8 @@ static int dp_power_client_init(struct dp_power
> *dp_power,
> goto error_clk;
> }
>
> - power->phandle = phandle;
> - snprintf(dp_client_name, DP_CLIENT_NAME_SIZE, "dp_core_client");
> - power->dp_core_client = dpu_power_client_create(phandle,
> - dp_client_name);
> - if (IS_ERR_OR_NULL(power->dp_core_client)) {
> - pr_err("[%s] client creation failed for DP", dp_client_name);
> - rc = -EINVAL;
> - goto error_client;
> - }
> return 0;
>
> -error_client:
> - dp_power_clk_init(power, false);
> error_clk:
> dp_power_regulator_deinit(power);
> error_power:
> @@ -466,7 +452,6 @@ static void dp_power_client_deinit(struct dp_power
> *dp_power)
>
> power = container_of(dp_power, struct dp_power_private, dp_power);
>
> - dpu_power_client_destroy(power->phandle, power->dp_core_client);
> dp_power_clk_init(power, false);
> dp_power_regulator_deinit(power);
> }
> @@ -521,13 +506,6 @@ static int dp_power_init(struct dp_power *dp_power, bool
> flip)
> goto err_gpio;
> }
>
> - rc = dpu_power_resource_enable(power->phandle,
> - power->dp_core_client, true);
> - if (rc) {
> - pr_err("Power resource enable failed\n");
> - goto err_dpu_power;
> - }
> -
> rc = dp_power_clk_enable(dp_power, DP_CORE_PM, true);
> if (rc) {
> pr_err("failed to enable DP core clocks\n");
> @@ -537,8 +515,6 @@ static int dp_power_init(struct dp_power *dp_power, bool
> flip)
> return 0;
>
> err_clk:
> - dpu_power_resource_enable(power->phandle, power->dp_core_client, false);
> -err_dpu_power:
> dp_power_config_gpios(power, flip, false);
> err_gpio:
> dp_power_pinctrl_set(power, false);
> @@ -562,12 +538,6 @@ static int dp_power_deinit(struct dp_power *dp_power)
> power = container_of(dp_power, struct dp_power_private, dp_power);
>
> dp_power_clk_enable(dp_power, DP_CORE_PM, false);
> - rc = dpu_power_resource_enable(power->phandle,
> - power->dp_core_client, false);
> - if (rc) {
> - pr_err("Power resource enable failed, rc=%d\n", rc);
> - goto exit;
> - }
> dp_power_config_gpios(power, false, false);
> dp_power_pinctrl_set(power, false);
> dp_power_regulator_ctrl(power, false);
> diff --git a/drivers/gpu/drm/msm/dp/dp_power.h
> b/drivers/gpu/drm/msm/dp/dp_power.h
> index 84fe01d..d9dab72 100644
> --- a/drivers/gpu/drm/msm/dp/dp_power.h
> +++ b/drivers/gpu/drm/msm/dp/dp_power.h
> @@ -16,7 +16,6 @@
> #define _DP_POWER_H_
>
> #include "dp_parser.h"
> -#include "dpu_power_handle.h"
>
> /**
> * sruct dp_power - DisplayPort's power related data
> @@ -32,8 +31,7 @@ struct dp_power {
> int (*clk_enable)(struct dp_power *power, enum dp_pm_type pm_type,
> bool enable);
> int (*set_pixel_clk_parent)(struct dp_power *power);
> - int (*power_client_init)(struct dp_power *power,
> - struct dpu_power_handle *phandle);
> + int (*power_client_init)(struct dp_power *power);
> void (*power_client_deinit)(struct dp_power *power);
> };
>
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
>
--
Sean Paul, Software Engineer, Google / Ch
[Bug 99403] Graphical glitches in witcher-1 with wine nine and r600g (rv740).
https://bugs.freedesktop.org/show_bug.cgi?id=99403 --- Comment #9 from i...@yahoo.com --- The fix for r600/Evergreen has been committed: https://cgit.freedesktop.org/mesa/mesa/commit/?id=ce027ac5c798b39582288e5d7d9973b3cdda591e The Tahiti issue remains under investigation. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [DPU PATCH 10/11] drm/msm/dpu: use runtime_pm calls in dpu_dbg
On Thu, May 10, 2018 at 01:59:44PM +0530, Rajesh Yadav wrote:
> Currently, msm_drv was creating dpu_power_handle client
> which was used by dpu_dbg module to enable power resources
> before register debug dumping.
>
> Now since, the mdss core power resource handling is
> implemented via runtime_pm and same has been removed
> from dpu_power_handle. Remove dpu_power_handle dependency
> from msm_drv and use pm_runtime_get/put_sync calls from
> dpu_dbg module on dpu_mdss top level device for core,
> ahb clock and power resource management (for register access).
>
> Signed-off-by: Rajesh Yadav
Reviewed-by: Sean Paul
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 4 +---
> drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h | 4
> drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 3 +--
> drivers/gpu/drm/msm/dpu_dbg.c | 18 +++---
> drivers/gpu/drm/msm/dpu_dbg.h | 13 ++---
> drivers/gpu/drm/msm/msm_drv.c | 27
> +--
> drivers/gpu/drm/msm/msm_drv.h | 1 -
> 7 files changed, 12 insertions(+), 58 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
> index d1364fa..e2e7c06 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
> @@ -676,10 +676,9 @@ int dpu_core_perf_init(struct dpu_core_perf *perf,
> struct drm_device *dev,
> struct dpu_mdss_cfg *catalog,
> struct dpu_power_handle *phandle,
> - struct dpu_power_client *pclient,
> struct dss_clk *core_clk)
> {
> - if (!perf || !dev || !catalog || !phandle || !pclient || !core_clk) {
> + if (!perf || !dev || !catalog || !phandle || !core_clk) {
> DPU_ERROR("invalid parameters\n");
> return -EINVAL;
> }
> @@ -687,7 +686,6 @@ int dpu_core_perf_init(struct dpu_core_perf *perf,
> perf->dev = dev;
> perf->catalog = catalog;
> perf->phandle = phandle;
> - perf->pclient = pclient;
> perf->core_clk = core_clk;
>
> perf->max_core_clk_rate = core_clk->max_rate;
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h
> index 9c1a719..cde48df 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h
> @@ -53,7 +53,6 @@ struct dpu_core_perf_tune {
> * @debugfs_root: top level debug folder
> * @catalog: Pointer to catalog configuration
> * @phandle: Pointer to power handler
> - * @pclient: Pointer to power client
> * @core_clk: Pointer to core clock structure
> * @core_clk_rate: current core clock rate
> * @max_core_clk_rate: maximum allowable core clock rate
> @@ -68,7 +67,6 @@ struct dpu_core_perf {
> struct dentry *debugfs_root;
> struct dpu_mdss_cfg *catalog;
> struct dpu_power_handle *phandle;
> - struct dpu_power_client *pclient;
> struct dss_clk *core_clk;
> u64 core_clk_rate;
> u64 max_core_clk_rate;
> @@ -115,14 +113,12 @@ void dpu_core_perf_crtc_update(struct drm_crtc *crtc,
> * @dev: Pointer to drm device
> * @catalog: Pointer to catalog
> * @phandle: Pointer to power handle
> - * @pclient: Pointer to power client
> * @core_clk: pointer to core clock
> */
> int dpu_core_perf_init(struct dpu_core_perf *perf,
> struct drm_device *dev,
> struct dpu_mdss_cfg *catalog,
> struct dpu_power_handle *phandle,
> - struct dpu_power_client *pclient,
> struct dss_clk *core_clk);
>
> /**
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> index f6511c9..67bef32 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> @@ -1728,8 +1728,7 @@ static int dpu_kms_hw_init(struct msm_kms *kms)
> #endif
>
> rc = dpu_core_perf_init(&dpu_kms->perf, dev, dpu_kms->catalog,
> - &priv->phandle, priv->pclient,
> - _dpu_kms_get_clk(dpu_kms, "core_clk"));
> + &priv->phandle, _dpu_kms_get_clk(dpu_kms, "core_clk"));
> if (rc) {
> DPU_ERROR("failed to init perf %d\n", rc);
> goto perf_err;
> diff --git a/drivers/gpu/drm/msm/dpu_dbg.c b/drivers/gpu/drm/msm/dpu_dbg.c
> index 4a39b82..27538bc 100644
> --- a/drivers/gpu/drm/msm/dpu_dbg.c
> +++ b/drivers/gpu/drm/msm/dpu_dbg.c
> @@ -20,6 +20,7 @@
> #include
> #include
> #include
> +#include
>
> #include "dpu_dbg.h"
> #include "disp/dpu1/dpu_hw_catalog.h"
> @@ -167,7 +168,6 @@ struct dpu_dbg_vbif_debug_bus {
> * @evtlog: event log instance
> * @reg_base_list: list of register dumping regions
> * @dev: device pointer
> - * @power_ctrl: callback structure for enabling power for reading hw
> registers
>
Re: [DPU PATCH 11/11] drm/msm/dpu: move dpu_power_handle to dpu folder
On Thu, May 10, 2018 at 01:59:45PM +0530, Rajesh Yadav wrote:
> Now, since dpu_power_handle manages only bus scaling
> and power enable/disable notifications which are restricted
> to dpu driver, move dpu_power_handle to dpu folder.
>
> Signed-off-by: Rajesh Yadav
> ---
> drivers/gpu/drm/msm/Makefile | 2 +-
> drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c | 1 -
> drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c| 5 +-
> drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 7 +-
> drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h | 2 +
> drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 1 -
> drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 39 +-
> drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 1 +
> drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.c | 694
> +++
> drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.h | 288 ++
> drivers/gpu/drm/msm/dpu_power_handle.c | 694
> ---
> drivers/gpu/drm/msm/dpu_power_handle.h | 288 --
> drivers/gpu/drm/msm/msm_drv.c| 9 -
> drivers/gpu/drm/msm/msm_drv.h| 4 -
> 14 files changed, 1014 insertions(+), 1021 deletions(-)
> create mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.c
> create mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.h
> delete mode 100644 drivers/gpu/drm/msm/dpu_power_handle.c
> delete mode 100644 drivers/gpu/drm/msm/dpu_power_handle.h
>
> @@ -1863,6 +1863,12 @@ static int dpu_init(struct platform_device *pdev,
> struct drm_device *dev)
> goto clk_rate_error;
> }
>
> + ret = dpu_power_resource_init(pdev, &dpu_kms->phandle);
> + if (ret) {
> + pr_err("dpu power resource init failed\n");
> + goto power_init_fail;
> + }
> +
> platform_set_drvdata(pdev, dpu_kms);
>
> msm_kms_init(&dpu_kms->base, &kms_funcs);
> @@ -1876,6 +1882,7 @@ static int dpu_init(struct platform_device *pdev,
> struct drm_device *dev)
>
> return ret;
>
> +power_init_fail:
Nit: No need to add an empty label, just use clk_rate_error above.
With that fixed,
Reviewed-by: Sean Paul
> clk_rate_error:
> msm_dss_put_clk(mp->clk_config, mp->num_clk);
> clk_get_error:
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 00/18] Convert default pr_fmt from empty to KBUILD_MODNAME
pr_ logging uses allow a prefix to be specified with a
specific #define pr_fmt
The default of pr_fmt in printk.h is #define pr_fmt(fmt) fmt
so no prefixing of logging output is generically done.
There are several output logging uses like dump_stack() that are
unprefixed and should remain unprefixed.
This patch series attempts to convert the default #define of pr_fmt to
KBUILD_MODNAME ": " fmt and as well update the various bits of the kernel
that should _not_ be prefixed by adding #define pr_fmt(fmt) fmt to those
compilation units that do not want output message prefixing.
There are about 1200 uses of #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
that could be removed if the default is changed.
A script that does this removal (and removes any blank lines that follow)
for the linux-kernel tree is included below:
$ git grep -P --name-only "define\s+pr_fmt\b" | \
grep -v include/linux/printk.h | \
xargs perl -i -e 'local $/; while (<>) {s/(\n)*[ \t]*#[ \t]*define[
\t]+pr_fmt[ \t]*\([ \t]*(\w+)[ \t]*\)[ \t]*KBUILD_MODNAME[ \t]*\": \"[ \t]*\2[
\t]*\n\s*/\1\n/; s/^\n//; print;}'
This script should be run after this patch series is applied.
The above script output diff is currently:
1198 files changed, 70 insertions(+), 2241 deletions(-)
Joe Perches (18):
kernel: Use pr_fmt
lib: Use pr_fmt
printk: Convert pr_fmt from blank define to KBUILD_MODNAME
x86: Remove pr_fmt duplicate logging prefixes
x86/mtrr: Rename main.c to mtrr.c and remove duplicate prefixes
net: Remove pr_fmt duplicate logging prefixes
blk-mq: Remove pr_fmt duplicate logging prefixes
random: Remove pr_fmt duplicate logging prefixes
ptp: Remove pr_fmt duplicate logging prefixes
efifb: Remove pr_fmt duplicate logging prefixes
proc: Remove pr_fmt duplicate logging prefixes
uprobes: Remove pr_fmt duplicate logging prefixes
printk: Remove pr_fmt duplicate logging prefixes
lib/mpi: Remove pr_fmt duplicate logging prefixes
security: Remove pr_fmt duplicate logging prefixes
aoe: Remove pr_fmt duplicate logging prefixes
security: encrypted-keys: Remove pr_fmt duplicate logging prefixes
rcu: Use pr_fmt to prefix "rcu: " to logging output
arch/x86/events/amd/ibs.c | 2 +-
arch/x86/kernel/cpu/mtrr/Makefile | 2 +-
arch/x86/kernel/cpu/mtrr/{main.c => mtrr.c}| 33 ++---
arch/x86/kernel/e820.c | 32 ++--
arch/x86/kernel/hpet.c | 5 +-
arch/x86/kernel/uprobes.c | 4 +-
arch/x86/mm/numa.c | 22 -
block/blk-mq.c | 9 ++--
drivers/block/aoe/aoeblk.c | 29 ++-
drivers/block/aoe/aoechr.c | 11 ++---
drivers/block/aoe/aoecmd.c | 34 ++---
drivers/block/aoe/aoedev.c | 19 +++-
drivers/block/aoe/aoemain.c| 6 +--
drivers/block/aoe/aoenet.c | 19 +++-
drivers/char/hw_random/via-rng.c | 10 ++--
drivers/char/random.c | 16 +++---
drivers/ptp/ptp_clock.c| 4 +-
drivers/video/fbdev/efifb.c| 48 +-
fs/proc/root.c | 6 +--
include/linux/printk.h | 2 +-
kernel/acct.c | 2 +
kernel/async.c | 14 +++---
kernel/audit_tree.c| 2 +-
kernel/backtracetest.c | 8 +--
kernel/crash_core.c| 29 ++-
kernel/events/uprobes.c| 3 +-
kernel/exit.c | 2 +
kernel/hung_task.c | 13 +++--
kernel/kprobes.c | 20 +---
kernel/module.c| 59 +++
kernel/panic.c | 3 ++
kernel/params.c| 13 +++--
kernel/pid.c | 2 +
kernel/printk/printk.c | 2 +-
kernel/profile.c | 2 +
kernel/range.c | 2 +-
kernel/rcu/rcu_segcblist.c | 2 +
kernel/rcu/rcuperf.c | 10 ++--
kernel/rcu/rcutorture.c| 46 +-
kernel/rcu/srcutiny.c | 2 +
kernel/rcu/srcutree.c | 5 +-
kernel/rcu/tiny.c | 3 ++
kernel/rcu/tree.c | 8 +--
kernel/rcu/tree_plugin.h | 67 +++---
kernel/rcu/update.c| 19 +---
kernel/relay.c | 5 +-
kernel/seccomp.c | 4 +-
kernel/signal
[PATCH 10/18] efifb: Remove pr_fmt duplicate logging prefixes
Converting pr_fmt from a simple define to use KBUILD_MODNAME added
some duplicate logging prefixes to existing uses.
Remove them.
Signed-off-by: Joe Perches
---
drivers/video/fbdev/efifb.c | 48 ++---
1 file changed, 23 insertions(+), 25 deletions(-)
diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c
index 46a4484e3da7..3a11174f194b 100644
--- a/drivers/video/fbdev/efifb.c
+++ b/drivers/video/fbdev/efifb.c
@@ -250,13 +250,13 @@ static int efifb_probe(struct platform_device *dev)
} else {
/* We cannot make this fatal. Sometimes this comes from magic
spaces our resource handlers simply don't know about */
- pr_warn("efifb: cannot reserve video memory at 0x%lx\n",
+ pr_warn("cannot reserve video memory at 0x%lx\n",
efifb_fix.smem_start);
}
info = framebuffer_alloc(sizeof(u32) * 16, &dev->dev);
if (!info) {
- pr_err("efifb: cannot allocate framebuffer\n");
+ pr_err("cannot allocate framebuffer\n");
err = -ENOMEM;
goto err_release_mem;
}
@@ -277,23 +277,23 @@ static int efifb_probe(struct platform_device *dev)
else
info->screen_base = ioremap_wc(efifb_fix.smem_start,
efifb_fix.smem_len);
if (!info->screen_base) {
- pr_err("efifb: abort, cannot ioremap video memory 0x%x @
0x%lx\n",
- efifb_fix.smem_len, efifb_fix.smem_start);
+ pr_err("abort, cannot ioremap video memory 0x%x @ 0x%lx\n",
+ efifb_fix.smem_len, efifb_fix.smem_start);
err = -EIO;
goto err_release_fb;
}
- pr_info("efifb: framebuffer at 0x%lx, using %dk, total %dk\n",
- efifb_fix.smem_start, size_remap/1024, size_total/1024);
- pr_info("efifb: mode is %dx%dx%d, linelength=%d, pages=%d\n",
- efifb_defined.xres, efifb_defined.yres,
- efifb_defined.bits_per_pixel, efifb_fix.line_length,
- screen_info.pages);
+ pr_info("framebuffer at 0x%lx, using %dk, total %dk\n",
+ efifb_fix.smem_start, size_remap/1024, size_total/1024);
+ pr_info("mode is %dx%dx%d, linelength=%d, pages=%d\n",
+ efifb_defined.xres, efifb_defined.yres,
+ efifb_defined.bits_per_pixel, efifb_fix.line_length,
+ screen_info.pages);
efifb_defined.xres_virtual = efifb_defined.xres;
efifb_defined.yres_virtual = efifb_fix.smem_len /
efifb_fix.line_length;
- pr_info("efifb: scrolling: redraw\n");
+ pr_info("scrolling: redraw\n");
efifb_defined.yres_virtual = efifb_defined.yres;
/* some dummy values for timing to make fbset happy */
@@ -311,17 +311,15 @@ static int efifb_probe(struct platform_device *dev)
efifb_defined.transp.offset = screen_info.rsvd_pos;
efifb_defined.transp.length = screen_info.rsvd_size;
- pr_info("efifb: %s: "
- "size=%d:%d:%d:%d, shift=%d:%d:%d:%d\n",
- "Truecolor",
- screen_info.rsvd_size,
- screen_info.red_size,
- screen_info.green_size,
- screen_info.blue_size,
- screen_info.rsvd_pos,
- screen_info.red_pos,
- screen_info.green_pos,
- screen_info.blue_pos);
+ pr_info("Truecolor: size=%d:%d:%d:%d, shift=%d:%d:%d:%d\n",
+ screen_info.rsvd_size,
+ screen_info.red_size,
+ screen_info.green_size,
+ screen_info.blue_size,
+ screen_info.rsvd_pos,
+ screen_info.red_pos,
+ screen_info.green_pos,
+ screen_info.blue_pos);
efifb_fix.ypanstep = 0;
efifb_fix.ywrapstep = 0;
@@ -350,17 +348,17 @@ static int efifb_probe(struct platform_device *dev)
err = sysfs_create_groups(&dev->dev.kobj, efifb_groups);
if (err) {
- pr_err("efifb: cannot add sysfs attrs\n");
+ pr_err("cannot add sysfs attrs\n");
goto err_unmap;
}
err = fb_alloc_cmap(&info->cmap, 256, 0);
if (err < 0) {
- pr_err("efifb: cannot allocate colormap\n");
+ pr_err("cannot allocate colormap\n");
goto err_groups;
}
err = register_framebuffer(info);
if (err < 0) {
- pr_err("efifb: cannot register framebuffer\n");
+ pr_err("cannot register framebuffer\n");
goto err_fb_dealoc;
}
fb_info(info, "%s frame buffer device\n", info->fix.id);
--
2.15.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Freedreno] [DPU PATCH 03/11] drm/msm/dpu: add MDSS top level driver for dpu
On Thu, May 10, 2018 at 01:59:37PM +0530, Rajesh Yadav wrote:
> SoCs containing dpu have a MDSS top level wrapper
> which includes sub-blocks as dpu, dsi, phy, dp etc.
> MDSS top level wrapper manages common resources like
> common clocks, power and irq for its sub-blocks.
>
> Currently, in dpu driver, all the power resource
> management is part of power_handle which manages
> these resources via a custom implementation. And
> the resource relationships are not modelled properly
> in dt. Moreover the irq domain handling code is part
> of dpu device (which is a child device) due to lack
> of a dedicated driver for MDSS top level wrapper
> device.
>
> This change adds dpu_mdss top level driver to handle
> common clock like - core clock, ahb clock
> (for register access), main power supply (i.e. gdsc)
> and irq management.
> The top level mdss device/driver acts as an interrupt
> controller and manage hwirq mapping for its child
> devices.
>
> It implements runtime_pm support for resource management.
> Child nodes can control these resources via runtime_pm
> get/put calls on their corresponding devices due to parent
> child relationship defined in dt.
>
> Signed-off-by: Rajesh Yadav
> ---
> drivers/gpu/drm/msm/Makefile | 1 +
> drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c | 97 ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.h | 14 -
> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 9 -
> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h| 7 -
> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c | 29 +--
> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.h | 11 -
> drivers/gpu/drm/msm/disp/dpu1/dpu_irq.c | 48 +---
> drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 6 -
> drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 2 -
> drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c | 301
> ++
> drivers/gpu/drm/msm/dpu_io_util.c | 55
> drivers/gpu/drm/msm/msm_drv.c | 26 +-
> drivers/gpu/drm/msm/msm_drv.h | 2 +-
> drivers/gpu/drm/msm/msm_kms.h | 2 +
> include/linux/dpu_io_util.h | 2 +
> 16 files changed, 390 insertions(+), 222 deletions(-)
> create mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c
> -static struct dpu_mdss_base_cfg *__intr_offset(struct dpu_mdss_cfg *m,
> +static int __intr_offset(struct dpu_mdss_cfg *m,
> void __iomem *addr, struct dpu_hw_blk_reg_map *hw)
> {
> if (!m || !addr || !hw || m->mdp_count == 0)
> - return NULL;
> + return -EINVAL;
It looks like this is only used by dpu_hw_intr_init and you know that m, addr
and hw will all be valid and I'm assuming that if we get this far there is at
least some assumption that mdp_count is set so it looks like you can skip this
error path and make this a void function.
> hw->base_off = addr;
> - hw->blk_off = m->mdss[0].base;
> + hw->blk_off = m->mdp[0].base;
> hw->hwversion = m->hwversion;
> - return &m->mdss[0];
> + return 0;
> }
>
> struct dpu_hw_intr *dpu_hw_intr_init(void __iomem *addr,
> struct dpu_mdss_cfg *m)
> {
> struct dpu_hw_intr *intr;
> - struct dpu_mdss_base_cfg *cfg;
> + int ret;
>
> if (!addr || !m)
> return ERR_PTR(-EINVAL);
> @@ -1195,10 +1182,10 @@ struct dpu_hw_intr *dpu_hw_intr_init(void __iomem
> *addr,
> if (!intr)
> return ERR_PTR(-ENOMEM);
>
> - cfg = __intr_offset(m, addr, &intr->hw);
> - if (!cfg) {
> + ret = __intr_offset(m, addr, &intr->hw);
> + if (ret) {
> kfree(intr);
> - return ERR_PTR(-EINVAL);
> + return ERR_PTR(ret);
> }
And making that a void function has the added benefit of skipping all of this
> __setup_intr_ops(&intr->ops);
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c
> new file mode 100644
> index 000..26bf2c1
> --- /dev/null
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c
> @@ -0,0 +1,301 @@
> +/*
> + * SPDX-License-Identifier: GPL-2.0
> + * Copyright (c) 2018, The Linux Foundation
> + */
> +
> +#include "dpu_kms.h"
> +
> +#define to_dpu_mdss(x) container_of(x, struct dpu_mdss, base)
> +
> +#define HW_INTR_STATUS 0x0010
> +
> +struct dpu_mdss {
> + struct msm_mdss base;
> + void __iomem *mmio;
> + unsigned long mmio_len;
> + u32 hwversion;
> + struct dss_module_power mp;
> + struct dpu_irq_controller irq_controller;
> +};
> +
> +static inline void _dpu_mdss_hw_rev_init(struct dpu_mdss *dpu_mdss)
> +{
> + dpu_mdss->hwversion = readl_relaxed(dpu_mdss->mmio + 0x0);
> +}
> +
> +static int _dpu_mdss_get_intr_sources(struct dpu_mdss *dpu_mdss,
> + uint32_t *sources)
> +{
> + *sources = readl_relaxed(dpu_mdss->mmio + HW_INTR_STATUS);
> + return
Re: [Freedreno] [DPU PATCH 04/11] drm/msm/dpu: create new platform driver for dpu device
On Thu, May 10, 2018 at 01:59:38PM +0530, Rajesh Yadav wrote:
> Current MSM display controller HW matches a tree like
> hierarchy where MDSS top level wrapper is parent device
> and mdp5/dpu, dsi, dp are child devices.
>
> Each child device like mdp5, dsi etc. have a separate driver,
> but currently dpu handling is tied to a single driver which
> was managing both mdss and dpu resources.
>
> Inorder to have the cleaner one to one device and driver
> association, this change adds a new platform_driver for dpu
> child device node which implements the kms functionality.
>
> The dpu driver implements runtime_pm support for managing clocks
> and bus bandwidth etc.
>
> Signed-off-by: Rajesh Yadav
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 251
> ++--
> drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 4 +
> drivers/gpu/drm/msm/msm_drv.c | 2 +
> drivers/gpu/drm/msm/msm_drv.h | 3 +
> 4 files changed, 214 insertions(+), 46 deletions(-)
> if (!kms) {
> @@ -1565,34 +1548,28 @@ static int dpu_kms_hw_init(struct msm_kms *kms)
> goto end;
> }
>
> - platformdev = to_platform_device(dev->dev);
> - if (!platformdev) {
> - DPU_ERROR("invalid platform device\n");
> - goto end;
> - }
> -
> priv = dev->dev_private;
> if (!priv) {
> DPU_ERROR("invalid private data\n");
> goto end;
> }
>
> - dpu_kms->mmio = msm_ioremap(platformdev, "mdp_phys", "mdp_phys");
> + dpu_kms->mmio = msm_ioremap(dpu_kms->pdev, "mdp_phys", "mdp_phys");
> if (IS_ERR(dpu_kms->mmio)) {
> rc = PTR_ERR(dpu_kms->mmio);
> DPU_ERROR("mdp register memory map failed: %d\n", rc);
> dpu_kms->mmio = NULL;
> goto error;
> }
> - DRM_INFO("mapped mdp address space @%p\n", dpu_kms->mmio);
> - dpu_kms->mmio_len = msm_iomap_size(platformdev, "mdp_phys");
> + DRM_INFO("mapped dpu address space @%p\n", dpu_kms->mmio);
This is not a useful message - move to debug or remove. In any event, please
don't use %p.
> + dpu_kms->mmio_len = msm_iomap_size(dpu_kms->pdev, "mdp_phys");
> rc = dpu_dbg_reg_register_base(DPU_DBG_NAME, dpu_kms->mmio,
> dpu_kms->mmio_len);
> if (rc)
> DPU_ERROR("dbg base register kms failed: %d\n", rc);
>
> - dpu_kms->vbif[VBIF_RT] = msm_ioremap(platformdev, "vbif_phys",
> + dpu_kms->vbif[VBIF_RT] = msm_ioremap(dpu_kms->pdev, "vbif_phys",
> "vbif_phys");
> if (IS_ERR(dpu_kms->vbif[VBIF_RT])) {
> rc = PTR_ERR(dpu_kms->vbif[VBIF_RT]);
> @@ -1600,20 +1577,20 @@ static int dpu_kms_hw_init(struct msm_kms *kms)
> dpu_kms->vbif[VBIF_RT] = NULL;
> goto error;
> }
> - dpu_kms->vbif_len[VBIF_RT] = msm_iomap_size(platformdev,
> + dpu_kms->vbif_len[VBIF_RT] = msm_iomap_size(dpu_kms->pdev,
> "vbif_phys");
> rc = dpu_dbg_reg_register_base("vbif_rt", dpu_kms->vbif[VBIF_RT],
> dpu_kms->vbif_len[VBIF_RT]);
> if (rc)
> DPU_ERROR("dbg base register vbif_rt failed: %d\n", rc);
>
> - dpu_kms->vbif[VBIF_NRT] = msm_ioremap(platformdev, "vbif_nrt_phys",
> + dpu_kms->vbif[VBIF_NRT] = msm_ioremap(dpu_kms->pdev, "vbif_nrt_phys",
>
> "vbif_nrt_phys");
> if (IS_ERR(dpu_kms->vbif[VBIF_NRT])) {
> dpu_kms->vbif[VBIF_NRT] = NULL;
> DPU_DEBUG("VBIF NRT is not defined");
> } else {
> - dpu_kms->vbif_len[VBIF_NRT] = msm_iomap_size(platformdev,
> + dpu_kms->vbif_len[VBIF_NRT] = msm_iomap_size(dpu_kms->pdev,
> "vbif_nrt_phys");
> rc = dpu_dbg_reg_register_base("vbif_nrt",
> dpu_kms->vbif[VBIF_NRT],
> @@ -1624,13 +1601,13 @@ static int dpu_kms_hw_init(struct msm_kms *kms)
> }
>
> #ifdef CONFIG_CHROME_REGDMA
> - dpu_kms->reg_dma = msm_ioremap(platformdev, "regdma_phys",
> + dpu_kms->reg_dma = msm_ioremap(dpu_kms->pdev, "regdma_phys",
> "regdma_phys");
> if (IS_ERR(dpu_kms->reg_dma)) {
> dpu_kms->reg_dma = NULL;
> DPU_DEBUG("REG_DMA is not defined");
> } else {
> - dpu_kms->reg_dma_len = msm_iomap_size(platformdev,
> + dpu_kms->reg_dma_len = msm_iomap_size(dpu_kms->pdev,
> "regdma_phys");
> rc = dpu_dbg_reg_register_base("reg_dma",
> dpu_kms->reg_dma,
> @@ -1804,14 +1781,13 @@ static int dpu_kms_hw_init(struct msm_kms *kms)
> dpu_power_resource_ena
[Bug 74973] [radeonsi] Gimp OpenCL does not work
https://bugs.freedesktop.org/show_bug.cgi?id=74973 --- Comment #8 from Jan Vesely --- (In reply to darkbasic from comment #7) > I will be able to test within a couple of months, at the moment I don't have > access to a pc with such hardware. Is this still an issue? gegl testsuite mostly passes with only 3 remaining tests: contrast-curve -- 7 wrong pixels clones -- 1 wrong pixel noise-cell -- fail (many wrong pixels, I think their algorithm is wrong) comment #2 also mentions that this works OK -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] gpu: drm: vgem: Change return type to vm_fault_t
On Thu, May 10, 2018 at 07:58:11PM +0530, Souptick Joarder wrote:
> Hi Sean,
>
> On Mon, Apr 16, 2018 at 8:32 PM, Souptick Joarder
> wrote:
> > Use new return type vm_fault_t for fault handler.
> >
> > Signed-off-by: Souptick Joarder
> > Reviewed-by: Matthew Wilcox
> > ---
> > drivers/gpu/drm/vgem/vgem_drv.c | 5 ++---
> > 1 file changed, 2 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/vgem/vgem_drv.c
> > b/drivers/gpu/drm/vgem/vgem_drv.c
> > index 2524ff1..c64a859 100644
> > --- a/drivers/gpu/drm/vgem/vgem_drv.c
> > +++ b/drivers/gpu/drm/vgem/vgem_drv.c
> > @@ -61,13 +61,13 @@ static void vgem_gem_free_object(struct drm_gem_object
> > *obj)
> > kfree(vgem_obj);
> > }
> >
> > -static int vgem_gem_fault(struct vm_fault *vmf)
> > +static vm_fault_t vgem_gem_fault(struct vm_fault *vmf)
> > {
> > struct vm_area_struct *vma = vmf->vma;
> > struct drm_vgem_gem_object *obj = vma->vm_private_data;
> > /* We don't use vmf->pgoff since that has the fake offset */
> > unsigned long vaddr = vmf->address;
> > - int ret;
> > + vm_fault_t ret = VM_FAULT_SIGBUS;
> > loff_t num_pages;
> > pgoff_t page_offset;
> > page_offset = (vaddr - vma->vm_start) >> PAGE_SHIFT;
> > @@ -77,7 +77,6 @@ static int vgem_gem_fault(struct vm_fault *vmf)
> > if (page_offset > num_pages)
> > return VM_FAULT_SIGBUS;
> >
> > - ret = -ENOENT;
> > mutex_lock(&obj->pages_lock);
> > if (obj->pages) {
> > get_page(obj->pages[page_offset]);
> > --
> > 1.9.1
> >
>
> Any further comment on this patch ?
Patch looks good to me. My build test fails, though, since vm_fault_t doesn't
exist in drm-misc-next yet.
So, for now,
Reviewed-by: Sean Paul
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1] drm: panel-orientation-quirks: Convert to use match_string() helper
On Mon, May 07, 2018 at 10:12:47AM +0200, Hans de Goede wrote:
> Hi,
>
> On 03-05-18 20:41, Andy Shevchenko wrote:
> > The new helper returns index of the matching string in an array.
> > We are going to use it here.
> >
> > Signed-off-by: Andy Shevchenko
>
> Thanks, LGTM:
>
> Acked-by: Hans de Goede
Applied to drm-misc-next with Hans' Ack.
Thanks for the patch!
Sean
>
> Regards,
>
> Hans
>
>
>
> > ---
> > drivers/gpu/drm/drm_panel_orientation_quirks.c | 7 +++
> > 1 file changed, 3 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_panel_orientation_quirks.c
> > b/drivers/gpu/drm/drm_panel_orientation_quirks.c
> > index caebddda8bce..fe9c6c731e87 100644
> > --- a/drivers/gpu/drm/drm_panel_orientation_quirks.c
> > +++ b/drivers/gpu/drm/drm_panel_orientation_quirks.c
> > @@ -172,10 +172,9 @@ int drm_get_panel_orientation_quirk(int width, int
> > height)
> > if (!bios_date)
> > continue;
> > - for (i = 0; data->bios_dates[i]; i++) {
> > - if (!strcmp(data->bios_dates[i], bios_date))
> > - return data->orientation;
> > - }
> > + i = match_string(data->bios_dates, -1, bios_date);
> > + if (i >= 0)
> > + return data->orientation;
> > }
> > return DRM_MODE_PANEL_ORIENTATION_UNKNOWN;
> >
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 102233] OpenCL segmentation fault on AMD Radeon (Kaveri+R7) with memtestCL
https://bugs.freedesktop.org/show_bug.cgi?id=102233 Jan Vesely changed: What|Removed |Added Resolution|--- |NOTOURBUG Status|NEEDINFO|RESOLVED --- Comment #4 from Jan Vesely --- This PR should fix memtestCL: https://github.com/ihaque/memtestCL/pull/9 feel free to reopen if you still see the problem. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 99553] Tracker bug for runnning OpenCL applications on Clover
https://bugs.freedesktop.org/show_bug.cgi?id=99553 Bug 99553 depends on bug 102233, which changed state. Bug 102233 Summary: OpenCL segmentation fault on AMD Radeon (Kaveri+R7) with memtestCL https://bugs.freedesktop.org/show_bug.cgi?id=102233 What|Removed |Added Status|NEEDINFO|RESOLVED Resolution|--- |NOTOURBUG -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106466] GPU recovery fails on Vega 64
https://bugs.freedesktop.org/show_bug.cgi?id=106466
Bug ID: 106466
Summary: GPU recovery fails on Vega 64
Product: DRI
Version: unspecified
Hardware: Other
OS: All
Status: NEW
Severity: normal
Priority: medium
Component: DRM/AMDgpu
Assignee: dri-devel@lists.freedesktop.org
Reporter: b...@basnieuwenhuizen.nl
Created attachment 139474
--> https://bugs.freedesktop.org/attachment.cgi?id=139474&action=edit
dmesg
Reproduce:
1) boot
2) Start X
3) Stop X
4) cat /sys/kernel/debug/dri/2/amdgpu_gpu_recovery
5) Wait till finished
6) Start X
7) Notice slowness
8) Stop X
The dmesg says that the reset failed, but the screen comes back with some
artifacts. drawing in X is very slow event though pp_dpm_sclk seems to be
indicating reasonable speeds.
I use amd-staging-drm-next as of today with as last commit
commit 905aa01b240f9216b6dbba3226bf10b2d96eebb7 (origin/amd-staging-drm-next)
Author: Colin Ian King
Date: Wed May 2 15:43:16 2018 +0100
drm/amd/display: clean up assignment of amdgpu_crtc
The declaration of pointer amdgpu_crtc has a redundant assignment to
amdgpu_crtc. Clean this up by removing it.
Detected by CoverityScan, CID#1460299 ("Evaluation order violation")
Reviewed-by: Harry Wentland
Signed-off-by: Colin Ian King
Signed-off-by: Alex Deucher
plus a patch of my own adding some more dev_info messages to the reset process.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 84740] black screen after Grub loads a kernel entry (Intel Atom D2xxx/N2xxx Integrated Graphics Controller)
https://bugs.freedesktop.org/show_bug.cgi?id=84740 Germano Massullo changed: What|Removed |Added Resolution|--- |WONTFIX Status|NEW |RESOLVED --- Comment #10 from Germano Massullo --- I have no longer access to the affected machine, nor I had any feedback from component developers. I close the bugreport as wontfix -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106306] amdgpu CIK power management issues (overdrive and wattman)
https://bugs.freedesktop.org/show_bug.cgi?id=106306 --- Comment #3 from gr...@sub.red --- Thanks, I wasn't aware of that. The old overdrive functionality indeed works with amdgpu.dpm=1 on 4.16. However, it doesn't on 4.17. And wattman functionality doesn't work at all; pp_od_clk_voltage prints nothing and doesn't accept anything. Is wattman even implemented for CI? Also, do you consider enabling amdgpu.dpm for CI by default? I found the big advantage that the VRAM/MC is finally back to the lower dpm state in idle while driving a WQHD 144 Hz monitor. That saves solid 40 Watts on desktop usage. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 199115] [gma500] BUG: unable to handle kernel NULL pointer dereference at 0000000000000081
https://bugzilla.kernel.org/show_bug.cgi?id=199115 Dominik Mierzejewski (domi...@greysector.net) changed: What|Removed |Added See Also||https://bugs.freedesktop.or ||g/show_bug.cgi?id=106470 -- 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 106470] [gma500] BUG: unable to handle kernel NULL pointer dereference at 0000000000000081
https://bugs.freedesktop.org/show_bug.cgi?id=106470 Bug ID: 106470 Summary: [gma500] BUG: unable to handle kernel NULL pointer dereference at 0081 Product: DRI Version: unspecified Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: DRM/other Assignee: dri-devel@lists.freedesktop.org Reporter: domi...@greysector.net Created attachment 139482 --> https://bugs.freedesktop.org/attachment.cgi?id=139482&action=edit journalctl -k --no-hostname --no-pager output I'm consistently getting this kernel NULL pointer dereference on a Thecus N5550 NAS box (Intel Atom D2550 CPU) on every boot if gma500_gfx module is not blacklisted: Mar 14 13:44:02 kernel: BUG: unable to handle kernel NULL pointer dereference at 0081 Mar 14 13:44:02 kernel: IP: drm_fb_helper_is_bound.isra.16+0x5/0xa0 [drm_kms_helper] Mar 14 13:44:03 kernel: PGD 0 P4D 0 Mar 14 13:44:03 kernel: Oops: [#1] SMP NOPTI Mar 14 13:44:03 kernel: Modules linked in: it87 hwmon_vid vfat fat snd_hda_codec_realtek snd_hda_codec_generic gma500_gfx snd_hda_codec_hdmi iTCO_wdt iTCO_vendor_support snd Mar 14 13:44:03 kernel: CPU: 0 PID: 277 Comm: kworker/0:2 Not tainted 4.15.7-300.fc27.x86_64 #1 Mar 14 13:44:03 kernel: Hardware name: Intel Corporation Milstead Platform/Granite Well, BIOS CDV_T30 X64 09/17/2012 Mar 14 13:44:03 kernel: Workqueue: events output_poll_execute [drm_kms_helper] Mar 14 13:44:03 kernel: RIP: 0010:drm_fb_helper_is_bound.isra.16+0x5/0xa0 [drm_kms_helper] Mar 14 13:44:03 kernel: RSP: 0018:b118005ebe28 EFLAGS: 00010286 Mar 14 13:44:03 kernel: RAX: RBX: 9da9b656c800 RCX: e800 Mar 14 13:44:03 kernel: RDX: 9da9b632da00 RSI: 0031 RDI: 9da9b656c800 Mar 14 13:44:03 kernel: RBP: 9da9b656c8d0 R08: 000251a0 R09: Mar 14 13:44:03 kernel: R10: f2ca40f61c00 R11: R12: 0001 Mar 14 13:44:03 kernel: R13: 9da9b71e7800 R14: 9da9b71e79f8 R15: Mar 14 13:44:03 kernel: FS: () GS:9da9bb40() knlGS: Mar 14 13:44:03 kernel: CS: 0010 DS: ES: CR0: 80050033 Mar 14 13:44:03 kernel: CR2: 0081 CR3: 7b2a CR4: 06f0 Mar 14 13:44:03 kernel: Call Trace: Mar 14 13:44:03 kernel: drm_fb_helper_hotplug_event.part.29+0x34/0xb0 [drm_kms_helper] Mar 14 13:44:03 kernel: output_poll_execute+0x185/0x1b0 [drm_kms_helper] Mar 14 13:44:03 kernel: process_one_work+0x175/0x390 Mar 14 13:44:03 kernel: worker_thread+0x2e/0x380 Mar 14 13:44:03 kernel: ? process_one_work+0x390/0x390 Mar 14 13:44:03 kernel: kthread+0x113/0x130 Mar 14 13:44:03 kernel: ? kthread_create_worker_on_cpu+0x70/0x70 Mar 14 13:44:03 kernel: ret_from_fork+0x1f/0x40 Mar 14 13:44:03 kernel: Code: 4c d0 f8 8b 45 20 39 c3 7c e6 83 e8 01 4c 89 ef 31 db 89 45 20 e8 6c b0 ea c4 eb 9f 83 c3 02 eb bf 0f 1f 44 00 00 0f 1f 44 00 00 <48> 8b 56 50 Mar 14 13:44:03 kernel: RIP: drm_fb_helper_is_bound.isra.16+0x5/0xa0 [drm_kms_helper] RSP: b118005ebe28 Mar 14 13:44:03 kernel: CR2: 0081 Mar 14 13:44:03 kernel: ---[ end trace 0bc03676f9e43f5d ]--- Full dmesg attached. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106470] [gma500] BUG: unable to handle kernel NULL pointer dereference at 0000000000000081
https://bugs.freedesktop.org/show_bug.cgi?id=106470 Dominik 'Rathann' Mierzejewski changed: What|Removed |Added See Also||https://bugzilla.kernel.org ||/show_bug.cgi?id=199115 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH libdrm 1/1] amdgpu: Take lock before removing devices from fd_tab hash table.
Close the file descriptors under lock as well.
Signed-off-by: Jan Vesely
---
amdgpu/amdgpu_device.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/amdgpu/amdgpu_device.c b/amdgpu/amdgpu_device.c
index 983b19ab..f71fc050 100644
--- a/amdgpu/amdgpu_device.c
+++ b/amdgpu/amdgpu_device.c
@@ -126,6 +126,13 @@ static int amdgpu_get_auth(int fd, int *auth)
static void amdgpu_device_free_internal(amdgpu_device_handle dev)
{
+ pthread_mutex_lock(&fd_mutex);
+ close(dev->fd);
+ if ((dev->flink_fd >= 0) && (dev->fd != dev->flink_fd))
+ close(dev->flink_fd);
+ util_hash_table_remove(fd_tab, UINT_TO_PTR(dev->fd));
+ pthread_mutex_unlock(&fd_mutex);
+
amdgpu_vamgr_deinit(&dev->vamgr_32);
amdgpu_vamgr_deinit(&dev->vamgr);
amdgpu_vamgr_deinit(&dev->vamgr_high_32);
@@ -133,10 +140,6 @@ static void
amdgpu_device_free_internal(amdgpu_device_handle dev)
util_hash_table_destroy(dev->bo_flink_names);
util_hash_table_destroy(dev->bo_handles);
pthread_mutex_destroy(&dev->bo_table_mutex);
- util_hash_table_remove(fd_tab, UINT_TO_PTR(dev->fd));
- close(dev->fd);
- if ((dev->flink_fd >= 0) && (dev->fd != dev->flink_fd))
- close(dev->flink_fd);
free(dev->marketing_name);
free(dev);
}
--
2.17.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/ttm: specify bo priority when initializing ttm bo
On 05/10/2018 10:40 PM, Christian König wrote:
Am 10.05.2018 um 07:01 schrieb Junwei Zhang:
Expect to add an evitable bo who has reservation object
to the correct lru[bo->priority] list
Nice catch, but since this affects only a very small use case can we just remove
and readd the BO to the LRU?
A call to ttm_bo_move_to_lru_tail() after setting the priority should be
sufficient.
Yeah, at that moment, I thought setting a priority for tbo at initialization is
a general way, which may help all associated modules to get out of potential
pain if more priorities are adopted.
Agree.
The most simple way is to move the bo back to expected lru after priority
setting. Going to prepare a patch.
(in this case, include amd-gfx mail only)
Regards,
Jerry
Thanks,
Christian.
Signed-off-by: Junwei Zhang
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 11 ++-
drivers/gpu/drm/ast/ast_ttm.c | 2 +-
drivers/gpu/drm/bochs/bochs_mm.c| 2 +-
drivers/gpu/drm/cirrus/cirrus_ttm.c | 2 +-
drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c | 2 +-
drivers/gpu/drm/mgag200/mgag200_ttm.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_bo.c| 2 +-
drivers/gpu/drm/qxl/qxl_object.c| 2 +-
drivers/gpu/drm/radeon/radeon_object.c | 2 +-
drivers/gpu/drm/ttm/ttm_bo.c| 8 +---
drivers/gpu/drm/virtio/virtgpu_object.c | 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_resource.c| 2 +-
drivers/staging/vboxvideo/vbox_ttm.c| 2 +-
include/drm/ttm/ttm_bo_api.h| 5 -
14 files changed, 26 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index e62153a..9a25ecb 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -360,6 +360,7 @@ static int amdgpu_bo_do_create(struct amdgpu_device *adev,
};
struct amdgpu_bo *bo;
unsigned long page_align, size = bp->size;
+uint32_t prio = 0;
size_t acc_size;
int r;
@@ -419,10 +420,13 @@ static int amdgpu_bo_do_create(struct amdgpu_device *adev,
bo->tbo.bdev = &adev->mman.bdev;
amdgpu_ttm_placement_from_domain(bo, bp->domain);
+if (bp->type == ttm_bo_type_kernel)
+prio = 1;
r = ttm_bo_init_reserved(&adev->mman.bdev, &bo->tbo, size, bp->type,
- &bo->placement, page_align, &ctx, acc_size,
- NULL, bp->resv, &amdgpu_ttm_bo_destroy);
+ prio, &bo->placement, page_align, &ctx,
+ acc_size, NULL, bp->resv,
+ &amdgpu_ttm_bo_destroy);
if (unlikely(r != 0))
return r;
@@ -434,9 +438,6 @@ static int amdgpu_bo_do_create(struct amdgpu_device *adev,
else
amdgpu_cs_report_moved_bytes(adev, ctx.bytes_moved, 0);
-if (bp->type == ttm_bo_type_kernel)
-bo->tbo.priority = 1;
-
if (bp->flags & AMDGPU_GEM_CREATE_VRAM_CLEARED &&
bo->tbo.mem.placement & TTM_PL_FLAG_VRAM) {
struct dma_fence *fence;
diff --git a/drivers/gpu/drm/ast/ast_ttm.c b/drivers/gpu/drm/ast/ast_ttm.c
index fe354eb..aabb96a 100644
--- a/drivers/gpu/drm/ast/ast_ttm.c
+++ b/drivers/gpu/drm/ast/ast_ttm.c
@@ -320,7 +320,7 @@ int ast_bo_create(struct drm_device *dev, int size, int
align,
sizeof(struct ast_bo));
ret = ttm_bo_init(&ast->ttm.bdev, &astbo->bo, size,
- ttm_bo_type_device, &astbo->placement,
+ ttm_bo_type_device, 0, &astbo->placement,
align >> PAGE_SHIFT, false, acc_size,
NULL, NULL, ast_bo_ttm_destroy);
if (ret)
diff --git a/drivers/gpu/drm/bochs/bochs_mm.c b/drivers/gpu/drm/bochs/bochs_mm.c
index 39cd084..9693109 100644
--- a/drivers/gpu/drm/bochs/bochs_mm.c
+++ b/drivers/gpu/drm/bochs/bochs_mm.c
@@ -366,7 +366,7 @@ static int bochs_bo_create(struct drm_device *dev, int
size, int align,
sizeof(struct bochs_bo));
ret = ttm_bo_init(&bochs->ttm.bdev, &bochsbo->bo, size,
- ttm_bo_type_device, &bochsbo->placement,
+ ttm_bo_type_device, 0, &bochsbo->placement,
align >> PAGE_SHIFT, false, acc_size,
NULL, NULL, bochs_bo_ttm_destroy);
if (ret)
diff --git a/drivers/gpu/drm/cirrus/cirrus_ttm.c
b/drivers/gpu/drm/cirrus/cirrus_ttm.c
index f219532..c1d85f8 100644
--- a/drivers/gpu/drm/cirrus/cirrus_ttm.c
+++ b/drivers/gpu/drm/cirrus/cirrus_ttm.c
@@ -327,7 +327,7 @@ int cirrus_bo_create(struct drm_device *dev, int size, int
align,
sizeof(struct cirrus_bo));
ret = ttm_bo_init(&cirrus->ttm.bdev, &cirrusbo->bo, size,
- ttm_bo_type_device, &cirrusbo->placement,
+ ttm_bo_type_device, 0, &cirrusbo->placement,
align >> PAGE_SHIFT, false, acc_size,
NULL, NULL, cirrus_bo_ttm_destroy);
if (ret)
diff --git a/drivers/gpu/drm/
[Bug 106471] Radeon HD 3450 acceleration not working
https://bugs.freedesktop.org/show_bug.cgi?id=106471 Bug ID: 106471 Summary: Radeon HD 3450 acceleration not working Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/Radeon Assignee: dri-devel@lists.freedesktop.org Reporter: jjcogliati...@yahoo.com Created attachment 139483 --> https://bugs.freedesktop.org/attachment.cgi?id=139483&action=edit full dmesg The Radeon HD 3450 acceleration support does not work on my computer. uname -a: Linux mouse 4.17.0-041700rc4-generic #201805070430 SMP Mon May 7 04:31:46 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux In the dmesg I get: [ 4.007419] [drm:r600_ring_test [radeon]] *ERROR* radeon: ring 0 test failed (scratch(0x8504)=0xCAFEDEAD) [ 4.007433] radeon :02:00.0: disabling GPU acceleration -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/ttm: specify bo priority when initializing ttm bo
On 2018年05月11日 09:21, Zhang, Jerry (Junwei) wrote:
On 05/10/2018 10:40 PM, Christian König wrote:
Am 10.05.2018 um 07:01 schrieb Junwei Zhang:
Expect to add an evitable bo who has reservation object
to the correct lru[bo->priority] list
Nice catch, but since this affects only a very small use case can we
just remove
and readd the BO to the LRU?
A call to ttm_bo_move_to_lru_tail() after setting the priority should be
sufficient.
Yeah, at that moment, I thought setting a priority for tbo at
initialization is a general way, which may help all associated modules
to get out of potential pain if more priorities are adopted.
Agree.
The most simple way is to move the bo back to expected lru after
priority setting. Going to prepare a patch.
No, there is more simpler way. see inline...
(in this case, include amd-gfx mail only)
Regards,
Jerry
Thanks,
Christian.
Signed-off-by: Junwei Zhang
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 11 ++-
drivers/gpu/drm/ast/ast_ttm.c | 2 +-
drivers/gpu/drm/bochs/bochs_mm.c | 2 +-
drivers/gpu/drm/cirrus/cirrus_ttm.c | 2 +-
drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c | 2 +-
drivers/gpu/drm/mgag200/mgag200_ttm.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_bo.c | 2 +-
drivers/gpu/drm/qxl/qxl_object.c | 2 +-
drivers/gpu/drm/radeon/radeon_object.c | 2 +-
drivers/gpu/drm/ttm/ttm_bo.c | 8 +---
drivers/gpu/drm/virtio/virtgpu_object.c | 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 2 +-
drivers/staging/vboxvideo/vbox_ttm.c | 2 +-
include/drm/ttm/ttm_bo_api.h | 5 -
14 files changed, 26 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index e62153a..9a25ecb 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -360,6 +360,7 @@ static int amdgpu_bo_do_create(struct
amdgpu_device *adev,
};
struct amdgpu_bo *bo;
unsigned long page_align, size = bp->size;
+ uint32_t prio = 0;
size_t acc_size;
int r;
@@ -419,10 +420,13 @@ static int amdgpu_bo_do_create(struct
amdgpu_device *adev,
bo->tbo.bdev = &adev->mman.bdev;
amdgpu_ttm_placement_from_domain(bo, bp->domain);
+ if (bp->type == ttm_bo_type_kernel)
+ prio = 1;
Why not just bo->tbo.priority = 1? In that case, you don't need to add
more parameter to ttm_bo_init_reserved.
In fact, this change is already in my per-vm-lru patch set.
Regards,
David Zhou
r = ttm_bo_init_reserved(&adev->mman.bdev, &bo->tbo, size,
bp->type,
- &bo->placement, page_align, &ctx, acc_size,
- NULL, bp->resv, &amdgpu_ttm_bo_destroy);
+ prio, &bo->placement, page_align, &ctx,
+ acc_size, NULL, bp->resv,
+ &amdgpu_ttm_bo_destroy);
if (unlikely(r != 0))
return r;
@@ -434,9 +438,6 @@ static int amdgpu_bo_do_create(struct
amdgpu_device *adev,
else
amdgpu_cs_report_moved_bytes(adev, ctx.bytes_moved, 0);
- if (bp->type == ttm_bo_type_kernel)
- bo->tbo.priority = 1;
-
if (bp->flags & AMDGPU_GEM_CREATE_VRAM_CLEARED &&
bo->tbo.mem.placement & TTM_PL_FLAG_VRAM) {
struct dma_fence *fence;
diff --git a/drivers/gpu/drm/ast/ast_ttm.c
b/drivers/gpu/drm/ast/ast_ttm.c
index fe354eb..aabb96a 100644
--- a/drivers/gpu/drm/ast/ast_ttm.c
+++ b/drivers/gpu/drm/ast/ast_ttm.c
@@ -320,7 +320,7 @@ int ast_bo_create(struct drm_device *dev, int
size, int
align,
sizeof(struct ast_bo));
ret = ttm_bo_init(&ast->ttm.bdev, &astbo->bo, size,
- ttm_bo_type_device, &astbo->placement,
+ ttm_bo_type_device, 0, &astbo->placement,
align >> PAGE_SHIFT, false, acc_size,
NULL, NULL, ast_bo_ttm_destroy);
if (ret)
diff --git a/drivers/gpu/drm/bochs/bochs_mm.c
b/drivers/gpu/drm/bochs/bochs_mm.c
index 39cd084..9693109 100644
--- a/drivers/gpu/drm/bochs/bochs_mm.c
+++ b/drivers/gpu/drm/bochs/bochs_mm.c
@@ -366,7 +366,7 @@ static int bochs_bo_create(struct drm_device
*dev, int
size, int align,
sizeof(struct bochs_bo));
ret = ttm_bo_init(&bochs->ttm.bdev, &bochsbo->bo, size,
- ttm_bo_type_device, &bochsbo->placement,
+ ttm_bo_type_device, 0, &bochsbo->placement,
align >> PAGE_SHIFT, false, acc_size,
NULL, NULL, bochs_bo_ttm_destroy);
if (ret)
diff --git a/drivers/gpu/drm/cirrus/cirrus_ttm.c
b/drivers/gpu/drm/cirrus/cirrus_ttm.c
index f219532..c1d85f8 100644
--- a/drivers/gpu/drm/cirrus/cirrus_ttm.c
+++ b/drivers/gpu/drm/cirrus/cirrus_ttm.c
@@ -327,7 +327,7 @@ int cirrus_bo_create(struct drm_device *dev, int
size, int
align,
sizeof(struct cirrus_bo));
ret = ttm
Re: [PATCH] drm/ttm: specify bo priority when initializing ttm bo
On 05/11/2018 10:11 AM, zhoucm1 wrote:
On 2018年05月11日 09:21, Zhang, Jerry (Junwei) wrote:
On 05/10/2018 10:40 PM, Christian König wrote:
Am 10.05.2018 um 07:01 schrieb Junwei Zhang:
Expect to add an evitable bo who has reservation object
to the correct lru[bo->priority] list
Nice catch, but since this affects only a very small use case can we just remove
and readd the BO to the LRU?
A call to ttm_bo_move_to_lru_tail() after setting the priority should be
sufficient.
Yeah, at that moment, I thought setting a priority for tbo at initialization
is a general way, which may help all associated modules to get out of
potential pain if more priorities are adopted.
Agree.
The most simple way is to move the bo back to expected lru after priority
setting. Going to prepare a patch.
No, there is more simpler way. see inline...
(in this case, include amd-gfx mail only)
Regards,
Jerry
Thanks,
Christian.
Signed-off-by: Junwei Zhang
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 11 ++-
drivers/gpu/drm/ast/ast_ttm.c | 2 +-
drivers/gpu/drm/bochs/bochs_mm.c| 2 +-
drivers/gpu/drm/cirrus/cirrus_ttm.c | 2 +-
drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c | 2 +-
drivers/gpu/drm/mgag200/mgag200_ttm.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_bo.c| 2 +-
drivers/gpu/drm/qxl/qxl_object.c| 2 +-
drivers/gpu/drm/radeon/radeon_object.c | 2 +-
drivers/gpu/drm/ttm/ttm_bo.c| 8 +---
drivers/gpu/drm/virtio/virtgpu_object.c | 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_resource.c| 2 +-
drivers/staging/vboxvideo/vbox_ttm.c| 2 +-
include/drm/ttm/ttm_bo_api.h| 5 -
14 files changed, 26 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index e62153a..9a25ecb 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -360,6 +360,7 @@ static int amdgpu_bo_do_create(struct amdgpu_device *adev,
};
struct amdgpu_bo *bo;
unsigned long page_align, size = bp->size;
+uint32_t prio = 0;
size_t acc_size;
int r;
@@ -419,10 +420,13 @@ static int amdgpu_bo_do_create(struct amdgpu_device
*adev,
bo->tbo.bdev = &adev->mman.bdev;
amdgpu_ttm_placement_from_domain(bo, bp->domain);
+if (bp->type == ttm_bo_type_kernel)
+prio = 1;
Why not just bo->tbo.priority = 1? In that case, you don't need to add more
parameter to ttm_bo_init_reserved.
In fact, this change is already in my per-vm-lru patch set.
Do you mean specify 1 before ttm_bo_init_reserved()?
ttm_bo_init_reserved() will overwrite it to 0 again inside.
Jerry
Regards,
David Zhou
r = ttm_bo_init_reserved(&adev->mman.bdev, &bo->tbo, size, bp->type,
- &bo->placement, page_align, &ctx, acc_size,
- NULL, bp->resv, &amdgpu_ttm_bo_destroy);
+ prio, &bo->placement, page_align, &ctx,
+ acc_size, NULL, bp->resv,
+ &amdgpu_ttm_bo_destroy);
if (unlikely(r != 0))
return r;
@@ -434,9 +438,6 @@ static int amdgpu_bo_do_create(struct amdgpu_device *adev,
else
amdgpu_cs_report_moved_bytes(adev, ctx.bytes_moved, 0);
-if (bp->type == ttm_bo_type_kernel)
-bo->tbo.priority = 1;
-
if (bp->flags & AMDGPU_GEM_CREATE_VRAM_CLEARED &&
bo->tbo.mem.placement & TTM_PL_FLAG_VRAM) {
struct dma_fence *fence;
diff --git a/drivers/gpu/drm/ast/ast_ttm.c b/drivers/gpu/drm/ast/ast_ttm.c
index fe354eb..aabb96a 100644
--- a/drivers/gpu/drm/ast/ast_ttm.c
+++ b/drivers/gpu/drm/ast/ast_ttm.c
@@ -320,7 +320,7 @@ int ast_bo_create(struct drm_device *dev, int size, int
align,
sizeof(struct ast_bo));
ret = ttm_bo_init(&ast->ttm.bdev, &astbo->bo, size,
- ttm_bo_type_device, &astbo->placement,
+ ttm_bo_type_device, 0, &astbo->placement,
align >> PAGE_SHIFT, false, acc_size,
NULL, NULL, ast_bo_ttm_destroy);
if (ret)
diff --git a/drivers/gpu/drm/bochs/bochs_mm.c
b/drivers/gpu/drm/bochs/bochs_mm.c
index 39cd084..9693109 100644
--- a/drivers/gpu/drm/bochs/bochs_mm.c
+++ b/drivers/gpu/drm/bochs/bochs_mm.c
@@ -366,7 +366,7 @@ static int bochs_bo_create(struct drm_device *dev, int
size, int align,
sizeof(struct bochs_bo));
ret = ttm_bo_init(&bochs->ttm.bdev, &bochsbo->bo, size,
- ttm_bo_type_device, &bochsbo->placement,
+ ttm_bo_type_device, 0, &bochsbo->placement,
align >> PAGE_SHIFT, false, acc_size,
NULL, NULL, bochs_bo_ttm_destroy);
if (ret)
diff --git a/drivers/gpu/drm/cirrus/cirrus_ttm.c
b/drivers/gpu/drm/cirrus/cirrus_ttm.c
index f219532..c1d85f8 100644
--- a/drivers/gpu/drm/cirrus/cirrus_ttm.c
+++ b/drivers/gpu/drm/cirrus/cirrus_ttm.c
@@ -327,7 +3
Re: [PATCH] drm/ttm: specify bo priority when initializing ttm bo
On 2018年05月11日 10:19, Zhang, Jerry (Junwei) wrote:
On 05/11/2018 10:11 AM, zhoucm1 wrote:
On 2018年05月11日 09:21, Zhang, Jerry (Junwei) wrote:
On 05/10/2018 10:40 PM, Christian König wrote:
Am 10.05.2018 um 07:01 schrieb Junwei Zhang:
Expect to add an evitable bo who has reservation object
to the correct lru[bo->priority] list
Nice catch, but since this affects only a very small use case can
we just remove
and readd the BO to the LRU?
A call to ttm_bo_move_to_lru_tail() after setting the priority
should be
sufficient.
Yeah, at that moment, I thought setting a priority for tbo at
initialization
is a general way, which may help all associated modules to get out of
potential pain if more priorities are adopted.
Agree.
The most simple way is to move the bo back to expected lru after
priority
setting. Going to prepare a patch.
No, there is more simpler way. see inline...
(in this case, include amd-gfx mail only)
Regards,
Jerry
Thanks,
Christian.
Signed-off-by: Junwei Zhang
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 11 ++-
drivers/gpu/drm/ast/ast_ttm.c | 2 +-
drivers/gpu/drm/bochs/bochs_mm.c | 2 +-
drivers/gpu/drm/cirrus/cirrus_ttm.c | 2 +-
drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c | 2 +-
drivers/gpu/drm/mgag200/mgag200_ttm.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_bo.c | 2 +-
drivers/gpu/drm/qxl/qxl_object.c | 2 +-
drivers/gpu/drm/radeon/radeon_object.c | 2 +-
drivers/gpu/drm/ttm/ttm_bo.c | 8 +---
drivers/gpu/drm/virtio/virtgpu_object.c | 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 2 +-
drivers/staging/vboxvideo/vbox_ttm.c | 2 +-
include/drm/ttm/ttm_bo_api.h | 5 -
14 files changed, 26 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index e62153a..9a25ecb 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -360,6 +360,7 @@ static int amdgpu_bo_do_create(struct
amdgpu_device *adev,
};
struct amdgpu_bo *bo;
unsigned long page_align, size = bp->size;
+ uint32_t prio = 0;
size_t acc_size;
int r;
@@ -419,10 +420,13 @@ static int amdgpu_bo_do_create(struct
amdgpu_device
*adev,
bo->tbo.bdev = &adev->mman.bdev;
amdgpu_ttm_placement_from_domain(bo, bp->domain);
+ if (bp->type == ttm_bo_type_kernel)
+ prio = 1;
Why not just bo->tbo.priority = 1? In that case, you don't need to
add more
parameter to ttm_bo_init_reserved.
In fact, this change is already in my per-vm-lru patch set.
Do you mean specify 1 before ttm_bo_init_reserved()?
ttm_bo_init_reserved() will overwrite it to 0 again inside.
If it can set outside of ttm, you can remove that overwriting. tbo
allocation is from kzalloc.
Regards,
David Zhou
Jerry
Regards,
David Zhou
r = ttm_bo_init_reserved(&adev->mman.bdev, &bo->tbo, size,
bp->type,
- &bo->placement, page_align, &ctx, acc_size,
- NULL, bp->resv, &amdgpu_ttm_bo_destroy);
+ prio, &bo->placement, page_align, &ctx,
+ acc_size, NULL, bp->resv,
+ &amdgpu_ttm_bo_destroy);
if (unlikely(r != 0))
return r;
@@ -434,9 +438,6 @@ static int amdgpu_bo_do_create(struct
amdgpu_device *adev,
else
amdgpu_cs_report_moved_bytes(adev, ctx.bytes_moved, 0);
- if (bp->type == ttm_bo_type_kernel)
- bo->tbo.priority = 1;
-
if (bp->flags & AMDGPU_GEM_CREATE_VRAM_CLEARED &&
bo->tbo.mem.placement & TTM_PL_FLAG_VRAM) {
struct dma_fence *fence;
diff --git a/drivers/gpu/drm/ast/ast_ttm.c
b/drivers/gpu/drm/ast/ast_ttm.c
index fe354eb..aabb96a 100644
--- a/drivers/gpu/drm/ast/ast_ttm.c
+++ b/drivers/gpu/drm/ast/ast_ttm.c
@@ -320,7 +320,7 @@ int ast_bo_create(struct drm_device *dev, int
size, int
align,
sizeof(struct ast_bo));
ret = ttm_bo_init(&ast->ttm.bdev, &astbo->bo, size,
- ttm_bo_type_device, &astbo->placement,
+ ttm_bo_type_device, 0, &astbo->placement,
align >> PAGE_SHIFT, false, acc_size,
NULL, NULL, ast_bo_ttm_destroy);
if (ret)
diff --git a/drivers/gpu/drm/bochs/bochs_mm.c
b/drivers/gpu/drm/bochs/bochs_mm.c
index 39cd084..9693109 100644
--- a/drivers/gpu/drm/bochs/bochs_mm.c
+++ b/drivers/gpu/drm/bochs/bochs_mm.c
@@ -366,7 +366,7 @@ static int bochs_bo_create(struct drm_device
*dev, int
size, int align,
sizeof(struct bochs_bo));
ret = ttm_bo_init(&bochs->ttm.bdev, &bochsbo->bo, size,
- ttm_bo_type_device, &bochsbo->placement,
+ ttm_bo_type_device, 0, &bochsbo->placement,
align >> PAGE_SHIFT, false, acc_size,
NULL, NULL, bochs_bo_ttm_destroy);
if (ret)
diff --git a/drive
Re: [PATCH] drm/ttm: specify bo priority when initializing ttm bo
On 05/11/2018 10:26 AM, zhoucm1 wrote:
On 2018年05月11日 10:19, Zhang, Jerry (Junwei) wrote:
On 05/11/2018 10:11 AM, zhoucm1 wrote:
On 2018年05月11日 09:21, Zhang, Jerry (Junwei) wrote:
On 05/10/2018 10:40 PM, Christian König wrote:
Am 10.05.2018 um 07:01 schrieb Junwei Zhang:
Expect to add an evitable bo who has reservation object
to the correct lru[bo->priority] list
Nice catch, but since this affects only a very small use case can we just
remove
and readd the BO to the LRU?
A call to ttm_bo_move_to_lru_tail() after setting the priority should be
sufficient.
Yeah, at that moment, I thought setting a priority for tbo at initialization
is a general way, which may help all associated modules to get out of
potential pain if more priorities are adopted.
Agree.
The most simple way is to move the bo back to expected lru after priority
setting. Going to prepare a patch.
No, there is more simpler way. see inline...
(in this case, include amd-gfx mail only)
Regards,
Jerry
Thanks,
Christian.
Signed-off-by: Junwei Zhang
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 11 ++-
drivers/gpu/drm/ast/ast_ttm.c | 2 +-
drivers/gpu/drm/bochs/bochs_mm.c| 2 +-
drivers/gpu/drm/cirrus/cirrus_ttm.c | 2 +-
drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c | 2 +-
drivers/gpu/drm/mgag200/mgag200_ttm.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_bo.c| 2 +-
drivers/gpu/drm/qxl/qxl_object.c| 2 +-
drivers/gpu/drm/radeon/radeon_object.c | 2 +-
drivers/gpu/drm/ttm/ttm_bo.c| 8 +---
drivers/gpu/drm/virtio/virtgpu_object.c | 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_resource.c| 2 +-
drivers/staging/vboxvideo/vbox_ttm.c| 2 +-
include/drm/ttm/ttm_bo_api.h| 5 -
14 files changed, 26 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index e62153a..9a25ecb 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -360,6 +360,7 @@ static int amdgpu_bo_do_create(struct amdgpu_device
*adev,
};
struct amdgpu_bo *bo;
unsigned long page_align, size = bp->size;
+uint32_t prio = 0;
size_t acc_size;
int r;
@@ -419,10 +420,13 @@ static int amdgpu_bo_do_create(struct amdgpu_device
*adev,
bo->tbo.bdev = &adev->mman.bdev;
amdgpu_ttm_placement_from_domain(bo, bp->domain);
+if (bp->type == ttm_bo_type_kernel)
+prio = 1;
Why not just bo->tbo.priority = 1? In that case, you don't need to add more
parameter to ttm_bo_init_reserved.
In fact, this change is already in my per-vm-lru patch set.
Do you mean specify 1 before ttm_bo_init_reserved()?
ttm_bo_init_reserved() will overwrite it to 0 again inside.
If it can set outside of ttm, you can remove that overwriting. tbo allocation is
from kzalloc.
Yeah, that bases on different coding idea, I think.
1) always to clear the tbo memory before tbo init (mostly, we do so)
2) make sure the key(all) members are initialized as expected always inside init
function.
anyway, I will sent it out firstly and RFC.
Jerry
Regards,
David Zhou
Jerry
Regards,
David Zhou
r = ttm_bo_init_reserved(&adev->mman.bdev, &bo->tbo, size, bp->type,
- &bo->placement, page_align, &ctx, acc_size,
- NULL, bp->resv, &amdgpu_ttm_bo_destroy);
+ prio, &bo->placement, page_align, &ctx,
+ acc_size, NULL, bp->resv,
+ &amdgpu_ttm_bo_destroy);
if (unlikely(r != 0))
return r;
@@ -434,9 +438,6 @@ static int amdgpu_bo_do_create(struct amdgpu_device
*adev,
else
amdgpu_cs_report_moved_bytes(adev, ctx.bytes_moved, 0);
-if (bp->type == ttm_bo_type_kernel)
-bo->tbo.priority = 1;
-
if (bp->flags & AMDGPU_GEM_CREATE_VRAM_CLEARED &&
bo->tbo.mem.placement & TTM_PL_FLAG_VRAM) {
struct dma_fence *fence;
diff --git a/drivers/gpu/drm/ast/ast_ttm.c b/drivers/gpu/drm/ast/ast_ttm.c
index fe354eb..aabb96a 100644
--- a/drivers/gpu/drm/ast/ast_ttm.c
+++ b/drivers/gpu/drm/ast/ast_ttm.c
@@ -320,7 +320,7 @@ int ast_bo_create(struct drm_device *dev, int size, int
align,
sizeof(struct ast_bo));
ret = ttm_bo_init(&ast->ttm.bdev, &astbo->bo, size,
- ttm_bo_type_device, &astbo->placement,
+ ttm_bo_type_device, 0, &astbo->placement,
align >> PAGE_SHIFT, false, acc_size,
NULL, NULL, ast_bo_ttm_destroy);
if (ret)
diff --git a/drivers/gpu/drm/bochs/bochs_mm.c
b/drivers/gpu/drm/bochs/bochs_mm.c
index 39cd084..9693109 100644
--- a/drivers/gpu/drm/bochs/bochs_mm.c
+++ b/drivers/gpu/drm/bochs/bochs_mm.c
@@ -366,7 +366,7 @@ static int bochs_bo_create(struct drm_device *dev, int
size, int align,
sizeof(struct bochs_bo));
ret = ttm_bo_init(&boc
[Bug 105684] Loading amdgpu hits general protection fault: 0000 [#1] SMP NOPTI
https://bugs.freedesktop.org/show_bug.cgi?id=105684 --- Comment #24 from jian-h...@endlessm.com --- Created attachment 139485 --> https://bugs.freedesktop.org/attachment.cgi?id=139485&action=edit dmesg of loading amdgpu module - tested in 4.17-rc4 I also tried Linux kernel 4.17-rc4 again. However, the system still hung up with the following error. The attachment is the full dmesg. [ 81.260098] [drm] use_doorbell being set to: [true] [ 81.270714] [drm] Found VCN firmware Version: 1.45 Family ID: 18 [ 81.435566] amdgpu: [powerplay] dpm has been enabled [ 81.435840] general protection fault: [#1] SMP NOPTI [ 81.435844] Modules linked in: amdkfd amd_iommu_v2 amdgpu(+) chash gpu_sched ttm drm_kms_helper drm i2c_algo_bit fb_sys_fops syscopyarea sysfillrect sysimgblt deflate efi_pstore cmac bnep arc4 edac_mce_amd kvm_amd ccp kvm btusb btrtl btbcm btintel bluetooth ecdh_generic input_leds irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pcbc snd_hda_codec_realtek ath10k_pci aesni_intel snd_hda_codec_generic snd_hda_codec_hdmi snd_hda_intel aes_x86_64 ath10k_core ath r8169 sparse_keymap mii crypto_simd mac80211 cfg80211 wmi_bmof snd_hda_codec snd_hda_core snd_hwdep snd_pcm snd_timer cryptd snd glue_helper psmouse soundcore i2c_piix4 shpchp k10temp video wmi mac_hid zram ip_tables x_tables hid_generic serio_raw usbhid hid uas usb_storage ahci libahci [ 81.435919] CPU: 4 PID: 877 Comm: modprobe Not tainted 4.17.0-rc4+ #1 [ 81.435922] Hardware name: Acer Aspire TC-380/Aspire TC-380, BIOS D05 02/01/2018 [ 81.435932] RIP: 0010:prefetch_freepointer+0x14/0x30 [ 81.435936] RSP: 0018:99ec83ee33d8 EFLAGS: 00010202 [ 81.435940] RAX: RBX: 88ad20ced800 RCX: 0fe4 [ 81.435943] RDX: 0fe3 RSI: 0d95bdbe4f99878a RDI: 88ad3f006e80 [ 81.435946] RBP: 99ec83ee33d8 R08: 88ad3f727160 R09: c08abb4b [ 81.435950] R10: c456df68a140 R11: 0001 R12: 014080c0 [ 81.435953] R13: 88ad3f006e80 R14: 88ad20ced800 R15: 88ad3f006e80 [ 81.435957] FS: 7f108441d700() GS:88ad3f70() knlGS: [ 81.435961] CS: 0010 DS: ES: CR0: 80050033 [ 81.435964] CR2: 7f9eab130740 CR3: 0007f66ac000 CR4: 003406e0 [ 81.435968] Call Trace: [ 81.435976] kmem_cache_alloc_trace+0xbb/0x1d0 [ 81.436062] ? dal_ddc_service_create+0x3c/0x120 [amdgpu] [ 81.436139] dal_ddc_service_create+0x3c/0x120 [amdgpu] [ 81.436221] ? dal_gpio_service_create_irq+0x44/0x70 [amdgpu] [ 81.436296] construct+0x249/0x750 [amdgpu] [ 81.436373] link_create+0x38/0x60 [amdgpu] [ 81.436437] dc_create+0x2dd/0x670 [amdgpu] [ 81.436488] dm_hw_init+0xe8/0xe50 [amdgpu] [ 81.436493] ? vprintk_func+0x27/0x60 [ 81.436496] ? printk+0x52/0x6e [ 81.436537] amdgpu_device_init+0x13a4/0x1470 [amdgpu] [ 81.436579] amdgpu_driver_load_kms+0x8b/0x2c0 [amdgpu] [ 81.436594] drm_dev_register+0x146/0x1d0 [drm] [ 81.436635] amdgpu_pci_probe+0x13f/0x1f0 [amdgpu] [ 81.436641] local_pci_probe+0x45/0xa0 [ 81.436643] pci_device_probe+0x109/0x1b0 [ 81.436647] driver_probe_device+0x2b2/0x490 [ 81.436650] __driver_attach+0xdf/0xf0 [ 81.436652] ? driver_probe_device+0x490/0x490 [ 81.436656] bus_for_each_dev+0x64/0xb0 [ 81.436658] ? kmem_cache_alloc_trace+0x1bf/0x1d0 [ 81.436661] driver_attach+0x1e/0x20 [ 81.436663] bus_add_driver+0x170/0x260 [ 81.436665] driver_register+0x60/0xe0 [ 81.436668] ? 0xc09f [ 81.436671] __pci_register_driver+0x5a/0x60 [ 81.436712] amdgpu_init+0x7a/0x89 [amdgpu] [ 81.436716] do_one_initcall+0x4f/0x1c4 [ 81.436719] ? __vunmap+0x81/0xb0 [ 81.436722] ? _cond_resched+0x1a/0x50 [ 81.436725] ? kmem_cache_alloc_trace+0xbb/0x1d0 [ 81.436728] ? do_init_module+0x27/0x219 [ 81.436731] do_init_module+0x5f/0x219 [ 81.436733] load_module+0x25b5/0x2dd0 [ 81.436737] __do_sys_finit_module+0xe5/0x120 [ 81.436739] ? __do_sys_finit_module+0xe5/0x120 [ 81.436742] __x64_sys_finit_module+0x1a/0x20 [ 81.436745] do_syscall_64+0x54/0x110 [ 81.436749] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 81.436751] RIP: 0033:0x7f1083f60229 [ 81.436753] RSP: 002b:7ffeb5502ca8 EFLAGS: 0246 ORIG_RAX: 0139 [ 81.436756] RAX: ffda RBX: 559dfae99480 RCX: 7f1083f60229 [ 81.436758] RDX: RSI: 559df9088638 RDI: 000d [ 81.436760] RBP: 559df9088638 R08: R09: [ 81.436762] R10: 000d R11: 0246 R12: [ 81.436764] R13: 559dfae995b0 R14: 0004 R15: [ 81.436767] Code: 58 30 b2 e8 72 f0 e9 ff eb 91 0f 1f 00 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 55 48 85 f6 48 89 e5 74 13 8b 47 20 48 01 c6 <48> 33 36 48 33 b7 38 01 00 00 0f 18 0e 5d c3 0f 1f 00 66 2e 0f [ 81.436794] RIP: prefetch_freepointer+0x14/0x30 RSP: 99ec
[Bug 106473] Mesa/Gallium segfaults in pipe_resource_reference (dri2_destroy_image) on KDE Plasma screen locker
https://bugs.freedesktop.org/show_bug.cgi?id=106473 Bug ID: 106473 Summary: Mesa/Gallium segfaults in pipe_resource_reference (dri2_destroy_image) on KDE Plasma screen locker Product: Mesa Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel@lists.freedesktop.org Reporter: freedesk...@mattwhitlock.name QA Contact: dri-devel@lists.freedesktop.org This crash has happened to me three times now: once on Mesa 18.1.0-rc2 and twice on Mesa 18.1.0-rc3. After the second crash, I rebuilt Mesa with debugging enabled, so I now have a decently complete stack trace. The crash occurs when I return to my computer after having left it for a while. The monitor has turned off, although I don't know whether that's relevant. When I move the mouse to wake up the monitor, I see Plasma's screen locker and a momentary flash of garbage from various windows that were open on my desktop, and then the screen is repainted with the screen locker as normal. When I enter my password and unlock my session, Plasma is telling me that KWin crashed. (KWin automatically restarts.) The stack trace points deep into Mesa, so I assume this is the place to report a bug. Thread 1 (Thread 0x7ff57e76a800 (LWP 2690)): [KCrash Handler] #6 pipe_resource_reference (tex=0x0, ptr=0x0) at ../../../../../mesa-18.1.0-rc3/src/gallium/auxiliary/util/u_inlines.h:136 #7 dri2_destroy_image (img=0x0) at ../../../../../mesa-18.1.0-rc3/src/gallium/state_trackers/dri/dri_helpers.c:317 #8 0x7ff5821241d0 in dri3_free_render_buffer (draw=draw@entry=0x5622c4a91278, buffer=buffer@entry=0x5622c526ac60) at ../../../mesa-18.1.0-rc3/src/loader/loader_dri3_helper.c:226 #9 0x7ff58212691b in dri3_get_buffer (driDrawable=driDrawable@entry=0x5622c4aa8560, format=format@entry=4098, buffer_type=buffer_type@entry=loader_dri3_buffer_back, draw=draw@entry=0x5622c4a91278) at ../../../mesa-18.1.0-rc3/src/loader/loader_dri3_helper.c:1708 #10 0x7ff582126bb8 in loader_dri3_get_buffers (driDrawable=0x5622c4aa8560, format=4098, stamp=0x5622c4a92e90, loaderPrivate=0x5622c4a91278, buffer_mask=1, buffers=0x7fff88abb8e0) at ../../../mesa-18.1.0-rc3/src/loader/loader_dri3_helper.c:1861 #11 0x7ff5754dec21 in dri_image_drawable_get_buffers (drawable=drawable@entry=0x5622c4a92e90, images=images@entry=0x7fff88abb8e0, statts=statts@entry=0x5622c4b346f0, statts_count=statts_count@entry=1) at ../../../../../mesa-18.1.0-rc3/src/gallium/state_trackers/dri/dri2.c:547 #12 0x7ff5754e089a in dri2_allocate_textures (ctx=0x5622c4a8fdd0, drawable=0x5622c4a92e90, statts=0x5622c4b346f0, statts_count=1) at ../../../../../mesa-18.1.0-rc3/src/gallium/state_trackers/dri/dri2.c:674 #13 0x7ff5754db27c in dri_st_framebuffer_validate (stctx=, stfbi=, statts=0x5622c4b346f0, count=1, out=0x7fff88abba30) at ../../../../../mesa-18.1.0-rc3/src/gallium/state_trackers/dri/dri_drawable.c:85 #14 0x7ff5752e2821 in st_framebuffer_validate (stfb=stfb@entry=0x5622c4b342c0, st=st@entry=0x5622c4d828f0) at ../../../mesa-18.1.0-rc3/src/mesa/state_tracker/st_manager.c:201 #15 0x7ff5752e4e23 in st_manager_validate_framebuffers (st=st@entry=0x5622c4d828f0) at ../../../mesa-18.1.0-rc3/src/mesa/state_tracker/st_manager.c:1117 #16 0x7ff575294b72 in st_validate_state (st=st@entry=0x5622c4d828f0, pipeline=pipeline@entry=ST_PIPELINE_RENDER) at ../../../mesa-18.1.0-rc3/src/mesa/state_tracker/st_atom.c:197 #17 0x7ff5752b9bae in prepare_draw (ctx=0x5622c4d65550, st=0x5622c4d828f0) at ../../../mesa-18.1.0-rc3/src/mesa/state_tracker/st_draw.c:123 #18 st_draw_vbo (ctx=0x5622c4d65550, prims=0x7fff88abbbc0, nr_prims=1, ib=0x0, index_bounds_valid=, min_index=, max_index=, tfb_vertcount=0x0, stream=0, indirect=0x0) at ../../../mesa-18.1.0-rc3/src/mesa/state_tracker/st_draw.c:153 #19 0x7ff575271e09 in vbo_draw_arrays (ctx=ctx@entry=0x5622c4d65550, mode=mode@entry=4, start=start@entry=0, count=count@entry=36, numInstances=numInstances@entry=1, baseInstance=baseInstance@entry=0, drawID=0) at ../../../mesa-18.1.0-rc3/src/mesa/vbo/vbo_exec_array.c:391 #20 0x7ff5752722d6 in vbo_exec_DrawArrays (mode=4, start=0, count=36) at ../../../mesa-18.1.0-rc3/src/mesa/vbo/vbo_exec_array.c:550 #21 0x7ff5832d2f07 in KWin::GLVertexBuffer::render (this=this@entry=0x5622c4b159c0, region=..., primitiveMode=primitiveMode@entry=4, hardwareClipping=hardwareClipping@entry=false) at ../../kwin-5.12.5/libkwineffects/kwinglutils.cpp:2090 #22 0x7ff5832d2f9f in KWin::GLVertexBuffer::render (this=this@entry=0x5622c4b159c0, primitiveMode=primitiveMode@entry=4) at ../../kwin-5.12.5/libkwineffects/kwinglutils.cpp:2084 #23 0x7ff57c037a21 in KWin::SceneOpenGL2::doPaintBackground (this=0x5622c4942db0, vertices=...) at ../../../../kwin-5.12.5/plugins/scenes/opengl/scen
[git pull] drm fixes for v4.17-rc5
Hi Linus, As last week seemed a bit slow, we got a few more fixes this week. The main stuff is 2 weeks of fixes for amdgpu, some missing bits of vega12 atom firmware support were added, and some power management fixes. Nouveau got two regression fixes for an DP MST deadlock and a random oops fix. i915 got an LVDS panel timeout fix 2 WARN fixes. exynos fixed a pagefault issue in the mixer driver. vc4 has an oops fix. omap had a bunch of uninit var and error-checking fixes. Two atomic modesetting state fixes. One minor agp cleanup patch Regards, Dave. The following changes since commit 75bc37fefc4471e718ba8e651aa74673d4e0a9eb: Linux 4.17-rc4 (2018-05-06 16:57:38 -1000) are available in the Git repository at: git://people.freedesktop.org/~airlied/linux tags/drm-fixes-for-v4.17-rc5 for you to fetch changes up to 72777fe79768ec30ac2163d26de68a89edc9849f: Merge branch 'drm-fixes-4.17' of git://people.freedesktop.org/~agd5f/linux into drm-fixes (2018-05-11 10:37:17 +1000) nouveau, amdgpu, i915, vc4, omap, exynos and atomic fixes Andrey Grodzovsky (1): drm/amdgpu: Switch to interruptable wait to recover from ring hang. Andrzej Hajda (2): drm/exynos/mixer: fix synchronization check in interlaced mode drm/bridge/sii8620: add Kconfig dependency on extcon Ben Skeggs (1): drm/nouveau/ttm: don't dereference nvbo::cli, it can outlive client Boris Brezillon (1): drm/vc4: Fix scaling of uni-planar formats Dan Carpenter (1): drm/omap: silence unititialized variable warning Dave Airlie (6): Merge tag 'exynos-drm-fixes-for-v4.17-rc5' of git://git.kernel.org/.../daeinki/drm-exynos into drm-fixes Merge tag 'drm-intel-fixes-2018-05-09' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixes Merge tag 'drm-misc-fixes-2018-05-09' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes Merge branch 'drm-fixes-4.17' of git://people.freedesktop.org/~agd5f/linux into drm-fixes Merge branch 'linux-4.17' of git://github.com/skeggsb/linux into drm-fixes Merge branch 'drm-fixes-4.17' of git://people.freedesktop.org/~agd5f/linux into drm-fixes Eric Anholt (1): drm/vc4: Fix oops dereferencing DPI's connector since panel_bridge. Florent Flament (1): drm/i915: Fix drm:intel_enable_lvds ERROR message in kernel log Harry Wentland (3): drm/amd/display: Add VG12 ASIC IDs drm/amd/display: Add get_firmware_info_v3_2 for VG12 drm/amd/display: Don't return ddc result and read_bytes in same return value Jerry (Fangzhi) Zuo (1): drm/amd: Add BIOS smu_info v3_3 required struct def. Lyude Paul (1): drm/nouveau: Fix deadlock in nv50_mstm_register_connector() Mathieu Malaterre (1): agp: uninorth: make two functions static Michel Dänzer (2): drm/amd/display: Use kvzalloc for potentially large allocations drm/ttm: Use GFP_TRANSHUGE_LIGHT for allocating huge pages Peter Rosin (1): drm/exynos: hdmi: avoid duplicating drm_bridge_attach Rex Zhu (2): drm/amd/pp: Refine the output of pp_power_profile_mode on VI drm/amd/pp: Fix performance drop on Fiji Rodrigo Vivi (1): drm/i915: Adjust eDP's logical vco in a reliable place. Tobias Jakobi (1): drm/exynos: mixer: avoid Oops in vp_video_buffer() Tomi Valkeinen (6): drm/omap: fix uninitialized ret variable drm/omap: fix possible NULL ref issue in tiler_reserve_2d drm/omap: check return value from soc_device_match drm/omap: handle error if scale coefs are not found drm/omap: add missing linefeeds to prints drm/omap: handle alloc failures in omap_connector Ville Syrjälä (3): drm/atomic: Clean old_state/new_state in drm_atomic_state_default_clear() drm/atomic: Clean private obj old_state/new_state in drm_atomic_state_default_clear() drm/i915: Correctly populate user mode h/vdisplay with pipe src size during readout drivers/char/agp/uninorth-agp.c| 4 +- drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c| 6 +- .../amd/display/amdgpu_dm/amdgpu_dm_mst_types.c| 20 ++- drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c | 86 ++- drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c | 10 +- drivers/gpu/drm/amd/display/dc/core/dc_surface.c | 14 +- drivers/gpu/drm/amd/display/dc/inc/dc_link_ddc.h | 5 +- drivers/gpu/drm/amd/display/include/dal_asic_id.h | 9 +- .../drm/amd/display/modules/color/color_gamma.c| 72 - drivers/gpu/drm/amd/include/atomfirmware.h | 170 - drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c | 52 +++ drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.h | 1 - .../gpu/drm/amd/powerplay/hwmgr/smu7_powertune.c | 4 +- drivers/gpu/drm/bridge/Kconfig | 1 + drivers/gpu/drm/drm_atomic.c
[PATCH 1/2] drm/ttm: remove priority hard code when initializing ttm bo
Then priority could be set before initialization. By default, it requires to kzalloc ttm bo. In fact, we always do so. Signed-off-by: Junwei Zhang --- drivers/gpu/drm/ttm/ttm_bo.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c index 98e06f8..cba5015 100644 --- a/drivers/gpu/drm/ttm/ttm_bo.c +++ b/drivers/gpu/drm/ttm/ttm_bo.c @@ -1175,7 +1175,6 @@ int ttm_bo_init_reserved(struct ttm_bo_device *bdev, reservation_object_init(&bo->ttm_resv); atomic_inc(&bo->bdev->glob->bo_count); drm_vma_node_reset(&bo->vma_node); - bo->priority = 0; /* * For ttm_bo_type_device buffers, allocate -- 1.9.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/amdgpu: set ttm bo priority before initialization
Signed-off-by: Junwei Zhang
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index e62153a..6a9e46a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -419,6 +419,8 @@ static int amdgpu_bo_do_create(struct amdgpu_device *adev,
bo->tbo.bdev = &adev->mman.bdev;
amdgpu_ttm_placement_from_domain(bo, bp->domain);
+ if (bp->type == ttm_bo_type_kernel)
+ bo->tbo.priority = 1;
r = ttm_bo_init_reserved(&adev->mman.bdev, &bo->tbo, size, bp->type,
&bo->placement, page_align, &ctx, acc_size,
@@ -434,9 +436,6 @@ static int amdgpu_bo_do_create(struct amdgpu_device *adev,
else
amdgpu_cs_report_moved_bytes(adev, ctx.bytes_moved, 0);
- if (bp->type == ttm_bo_type_kernel)
- bo->tbo.priority = 1;
-
if (bp->flags & AMDGPU_GEM_CREATE_VRAM_CLEARED &&
bo->tbo.mem.placement & TTM_PL_FLAG_VRAM) {
struct dma_fence *fence;
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH 2/2] drm/amdgpu: set ttm bo priority before initialization
The series is OK to me, Reviewed-by: Chunming Zhou
It is better to wait Christian to have a look before pushing patch.
Regards,
David Zhou
-Original Message-
From: Junwei Zhang [mailto:jerry.zh...@amd.com]
Sent: Friday, May 11, 2018 12:58 PM
To: amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
Cc: Koenig, Christian ; Zhou, David(ChunMing)
; Zhang, Jerry
Subject: [PATCH 2/2] drm/amdgpu: set ttm bo priority before initialization
Signed-off-by: Junwei Zhang
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index e62153a..6a9e46a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -419,6 +419,8 @@ static int amdgpu_bo_do_create(struct amdgpu_device *adev,
bo->tbo.bdev = &adev->mman.bdev;
amdgpu_ttm_placement_from_domain(bo, bp->domain);
+ if (bp->type == ttm_bo_type_kernel)
+ bo->tbo.priority = 1;
r = ttm_bo_init_reserved(&adev->mman.bdev, &bo->tbo, size, bp->type,
&bo->placement, page_align, &ctx, acc_size, @@
-434,9 +436,6 @@ static int amdgpu_bo_do_create(struct amdgpu_device *adev,
else
amdgpu_cs_report_moved_bytes(adev, ctx.bytes_moved, 0);
- if (bp->type == ttm_bo_type_kernel)
- bo->tbo.priority = 1;
-
if (bp->flags & AMDGPU_GEM_CREATE_VRAM_CLEARED &&
bo->tbo.mem.placement & TTM_PL_FLAG_VRAM) {
struct dma_fence *fence;
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106474] "CPU1 stuck for XXs: Xorg" since update to linux-4.16.x
https://bugs.freedesktop.org/show_bug.cgi?id=106474 Bug ID: 106474 Summary: "CPU1 stuck for XXs: Xorg" since update to linux-4.16.x Product: DRI Version: XOrg git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: DRM/Radeon Assignee: dri-devel@lists.freedesktop.org Reporter: linuxhi...@gmail.com Created attachment 139489 --> https://bugs.freedesktop.org/attachment.cgi?id=139489&action=edit screenshot After updating the Laptop of a friend running Fedora 27 to linux-4.16.4/5/6 it frequently gets stuck when starting Xorg - please see the attached screenshot. The machine is a AMD Beema based Hewlett-Packard HP 355 G2/22C1, BIOS F.10 02/12/2015 running the latest Fedora 27 packages. Graphics stack is default (glamor, radeon kernel module). Linux-4.15.17 works absolutly flawless. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106474] "CPU1 stuck for XXs: Xorg" since update to linux-4.16.x
https://bugs.freedesktop.org/show_bug.cgi?id=106474 --- Comment #1 from Clemens Eisserer --- Created attachment 139490 --> https://bugs.freedesktop.org/attachment.cgi?id=139490&action=edit dmesg of the affected machine running 4.15.17 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/amdgpu: set ttm bo priority before initialization
Looks like a good idea to me as well. Reviewed-by: Christian König
for the series.
Regards,
Christian.
Am 11.05.2018 um 07:27 schrieb Zhou, David(ChunMing):
The series is OK to me, Reviewed-by: Chunming Zhou
It is better to wait Christian to have a look before pushing patch.
Regards,
David Zhou
-Original Message-
From: Junwei Zhang [mailto:jerry.zh...@amd.com]
Sent: Friday, May 11, 2018 12:58 PM
To: amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
Cc: Koenig, Christian ; Zhou, David(ChunMing)
; Zhang, Jerry
Subject: [PATCH 2/2] drm/amdgpu: set ttm bo priority before initialization
Signed-off-by: Junwei Zhang
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index e62153a..6a9e46a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -419,6 +419,8 @@ static int amdgpu_bo_do_create(struct amdgpu_device *adev,
bo->tbo.bdev = &adev->mman.bdev;
amdgpu_ttm_placement_from_domain(bo, bp->domain);
+ if (bp->type == ttm_bo_type_kernel)
+ bo->tbo.priority = 1;
r = ttm_bo_init_reserved(&adev->mman.bdev, &bo->tbo, size, bp->type,
&bo->placement, page_align, &ctx, acc_size, @@
-434,9 +436,6 @@ static int amdgpu_bo_do_create(struct amdgpu_device *adev,
else
amdgpu_cs_report_moved_bytes(adev, ctx.bytes_moved, 0);
- if (bp->type == ttm_bo_type_kernel)
- bo->tbo.priority = 1;
-
if (bp->flags & AMDGPU_GEM_CREATE_VRAM_CLEARED &&
bo->tbo.mem.placement & TTM_PL_FLAG_VRAM) {
struct dma_fence *fence;
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
