[PATCH 3/4] phy: rockchip-typec: support DP phy switch

[Chris Zhong]

There are 2 Type-c PHYs in RK3399, but only one DP controller. Hence
only one PHY can connect to DP controller at one time, the other should
be disconnected. The GRF_SOC_CON26 register has a switch bit to do it,
set this bit means enable PHY 1, clear this bit means enable PHY 0.

Signed-off-by: Chris Zhong 
---

 drivers/phy/phy-rockchip-typec.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/phy/phy-rockchip-typec.c b/drivers/phy/phy-rockchip-typec.c
index 7cfb0f8..1604aaa 100644
--- a/drivers/phy/phy-rockchip-typec.c
+++ b/drivers/phy/phy-rockchip-typec.c
@@ -267,6 +267,7 @@ struct rockchip_usb3phy_port_cfg {
struct usb3phy_reg usb3tousb2_en;
struct usb3phy_reg external_psm;
struct usb3phy_reg pipe_status;
+   struct usb3phy_reg uphy_dp_sel;
 };
 
 struct rockchip_typec_phy {
@@ -736,6 +737,7 @@ static const struct phy_ops rockchip_usb3_phy_ops = {
 static int rockchip_dp_phy_power_on(struct phy *phy)
 {
struct rockchip_typec_phy *tcphy = phy_get_drvdata(phy);
+   struct rockchip_usb3phy_port_cfg *cfg = >port_cfgs;
int new_mode, ret = 0;
u32 val;
 
@@ -766,6 +768,8 @@ static int rockchip_dp_phy_power_on(struct phy *phy)
tcphy_phy_init(tcphy, new_mode);
}
 
+   property_enable(tcphy, >uphy_dp_sel, 1);
+
ret = readx_poll_timeout(readl, tcphy->base + DP_MODE_CTL,
 val, val & DP_MODE_A2, 1000,
 PHY_MODE_SET_TIMEOUT);
@@ -869,6 +873,11 @@ static int tcphy_parse_dt(struct rockchip_typec_phy *tcphy,
if (ret)
return ret;
 
+   ret = tcphy_get_param(dev, >uphy_dp_sel,
+ "rockchip,uphy-dp-sel");
+   if (ret)
+   return ret;
+
tcphy->grf_regs = syscon_regmap_lookup_by_phandle(dev->of_node,
  "rockchip,grf");
if (IS_ERR(tcphy->grf_regs)) {
-- 
2.6.3

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 4/4] drm/rockchip: cdn-dp: remove the DP phy switch

[Chris Zhong]

There are 2 Type-c PHYs in RK3399, but only one DP controller. Hence
only one PHY can connect to DP controller at one time, the other should
be disconnected. The GRF_SOC_CON26 register has a switch bit to do it,
set this bit means enable PHY 1, clear this bit means enable PHY 0.

If the board has 2 Type-C ports, the DP driver get the phy id from
devm_of_phy_get_by_index, and then control this switch according to
this id. But some others board only has one Type-C port, it may be PHY 0
or PHY 1. The dts node id can not tell us the correct PHY id. Hence move
this switch to PHY driver, the PHY driver can distinguish between PHY 0
and PHY 1, and then write the correct register bit.

Signed-off-by: Chris Zhong 
---

 drivers/gpu/drm/rockchip/cdn-dp-core.c | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c 
b/drivers/gpu/drm/rockchip/cdn-dp-core.c
index 9ab67a6..d3f6e6b 100644
--- a/drivers/gpu/drm/rockchip/cdn-dp-core.c
+++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c
@@ -43,8 +43,6 @@
 #define GRF_SOC_CON9   0x6224
 #define DP_SEL_VOP_LIT BIT(12)
 #define GRF_SOC_CON26  0x6268
-#define UPHY_SEL_BIT   3
-#define UPHY_SEL_MASK  BIT(19)
 #define DPTX_HPD_SEL   (3 << 12)
 #define DPTX_HPD_DEL   (2 << 12)
 #define DPTX_HPD_SEL_MASK  (3 << 28)
@@ -403,11 +401,6 @@ static int cdn_dp_enable_phy(struct cdn_dp_device *dp, 
struct cdn_dp_port *port)
union extcon_property_value property;
int ret;
 
-   ret = cdn_dp_grf_write(dp, GRF_SOC_CON26,
-  (port->id << UPHY_SEL_BIT) | UPHY_SEL_MASK);
-   if (ret)
-   return ret;
-
if (!port->phy_enabled) {
ret = phy_power_on(port->phy);
if (ret) {
-- 
2.6.3

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/4] Documentation: bindings: add uphy-dp-sel for Rockchip USB Type-C PHY

[Chris Zhong]

rockchip,uphy-dp-sel is the register of type-c phy enable DP function.

Signed-off-by: Chris Zhong 
---

 Documentation/devicetree/bindings/phy/phy-rockchip-typec.txt | 5 +
 1 file changed, 5 insertions(+)

diff --git a/Documentation/devicetree/bindings/phy/phy-rockchip-typec.txt 
b/Documentation/devicetree/bindings/phy/phy-rockchip-typec.txt
index 6ea867e..c3be83b 100644
--- a/Documentation/devicetree/bindings/phy/phy-rockchip-typec.txt
+++ b/Documentation/devicetree/bindings/phy/phy-rockchip-typec.txt
@@ -33,6 +33,9 @@ offset, enable bit, write mask bit.
  - rockchip,pipe-status : the register of type-c phy pipe status.
for type-c phy0, it must be <0xe5c0 0 0>;
for type-c phy1, it must be <0xe5c0 16 16>;
+ - rockchip,uphy-dp-sel : the register of type-c phy enable DP function
+   for type-c phy0, it must be <0x6268 19 19>;
+   for type-c phy1, it must be <0x6268 3 19>;
 
 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,
@@ -62,6 +65,7 @@ Example:
rockchip,usb3tousb2-en = <0xe580 3 19>;
rockchip,external-psm = <0xe588 14 30>;
rockchip,pipe-status = <0xe5c0 0 0>;
+   rockchip,uphy-dp-sel = <0x6268 19 19>;
 
tcphy0_dp: dp-port {
#phy-cells = <0>;
@@ -90,6 +94,7 @@ Example:
rockchip,usb3tousb2-en = <0xe58c 3 19>;
rockchip,external-psm = <0xe594 14 30>;
rockchip,pipe-status = <0xe5c0 16 16>;
+   rockchip,uphy-dp-sel = <0x6268 3 19>;
 
tcphy1_dp: dp-port {
#phy-cells = <0>;
-- 
2.6.3

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/4] arm64: dts: rockchip: add rockchip, uphy-dp-sel for Type-C phy

[Chris Zhong]

rockchip,uphy-dp-sel is the register of type-c phy enable DP function.

Signed-off-by: Chris Zhong 
---

 arch/arm64/boot/dts/rockchip/rk3399.dtsi | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index 8e6d1bd..7e8aa8c 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -1225,6 +1225,7 @@
rockchip,usb3tousb2-en = <0xe580 3 19>;
rockchip,external-psm = <0xe588 14 30>;
rockchip,pipe-status = <0xe5c0 0 0>;
+   rockchip,uphy-dp-sel = <0x6268 19 19>;
status = "disabled";
 
tcphy0_dp: dp-port {
@@ -1254,6 +1255,7 @@
rockchip,usb3tousb2-en = <0xe58c 3 19>;
rockchip,external-psm = <0xe594 14 30>;
rockchip,pipe-status = <0xe5c0 16 16>;
+   rockchip,uphy-dp-sel = <0x6268 3 19>;
status = "disabled";
 
tcphy1_dp: dp-port {
-- 
2.6.3

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 0/4] Move DP phy switch to PHY driver

[Chris Zhong]

There are 2 Type-c PHYs in RK3399, but only one DP controller. Hence
only one PHY can connect to DP controller at one time, the other should
be disconnected. The GRF_SOC_CON26 register has a switch bit to do it,
set this bit means enable PHY 1, clear this bit means enable PHY 0.

If the board has 2 Type-C ports, the DP driver get the phy id from
devm_of_phy_get_by_index, and then control this switch according to
this id. But some others board only has one Type-C port, it may be PHY 0
or PHY 1. The dts node id can not tell us the correct PHY id. Hence move
this switch to PHY driver, the PHY driver can distinguish between PHY 0
and PHY 1, and then write the correct register bit.



Chris Zhong (4):
  Documentation: bindings: add uphy-dp-sel for Rockchip USB Type-C PHY
  arm64: dts: rockchip: add rockchip,uphy-dp-sel for Type-C phy
  phy: rockchip-typec: support DP phy switch
  drm/rockchip: cdn-dp: remove the DP phy switch

 Documentation/devicetree/bindings/phy/phy-rockchip-typec.txt | 5 +
 arch/arm64/boot/dts/rockchip/rk3399.dtsi | 2 ++
 drivers/gpu/drm/rockchip/cdn-dp-core.c   | 7 ---
 drivers/phy/phy-rockchip-typec.c | 9 +
 4 files changed, 16 insertions(+), 7 deletions(-)

-- 
2.6.3

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/6] drm: Introduce consistent reference counting APIs

[Jani Nikula]

On Thu, 09 Feb 2017, Thierry Reding  wrote:
> On Thu, Feb 09, 2017 at 08:07:41PM +0100, Daniel Vetter wrote:
>> On Thu, Feb 09, 2017 at 07:39:33PM +0200, Jani Nikula wrote:
>> > On Thu, 09 Feb 2017, Daniel Vetter  wrote:
>> > > On Thu, Feb 09, 2017 at 04:10:12PM +0200, Jani Nikula wrote:
>> > >> On Wed, 08 Feb 2017, Thierry Reding  wrote:
>> > >> > This series introduces DRM reference counting APIs that are consistent
>> > >> > with other reference counting APIs in the kernel. They are also much
>> > >> > shorter. Compatibility aliases are added to keep existing code working
>> > >> > and will stay in place until all users of the old APIs are gone.
>> > >> 
>> > >> I like it.
>> > >> 
>> > >> But it makes drm_connector_list_iter_{get,put} stick out like a sore
>> > >> thumb. Something for the TODO list I guess.
>> > >
>> > > Hm, why is that one the sore thumb now? Just because it's really long? It
>> > > does acquire/drop references behind the scenes, that's why I went with 
>> > > the
>> > > _get/put postfixes ...
>> > 
>> > I think the assumption is that get/put work on an object, and you can
>> > get/put as many times as you like, as long as you keep them at
>> > balance. AFAICT this doesn't hold for iter.
>> 
>> Hm right. What else should we use instead? start/stop are confusing in the
>> context of list walking, create/destroy maybe?
>
> I rather like the _begin()/_end() suffix that I think iterators have in
> the C++ STL. Well, I guess it's really .end() and .begin() methods in
> C++.
>
> But the following reads rather nicely:
>
>   drm_connector_list_iter_begin(dev, );
>
>   drm_for_each_connector_iter(connector, )
>   ...
>
>   drm_connector_list_iter_end();
>
> Alternatively some other iterators simply use an _init() suffix to
> initialize the iterator. The kernel has a few of these, such as the
> of_phandle_iterator (see include/linux/of.h) or of_pci_range_parser (see
> include include/linux/of_address.h).
>
> EFI code uses _begin()/_end() in include/linux/efi.h, cgroups seems to
> have _start()/_end() in include/linux/cgroup.h. include/linux/klist.h
> uses klist_iter_init()/klist_iter_exit(). include/linux/rhashtable.h has
> rhashtable_walk_start()/rhashtable_walk_stop().
>
> A quick grep also shows other variants, one of them being _first(), but
> those don't have an explicit end function.
>
> So there's quite a few options to choose from, but I guess that doesn't
> make it any easier.
>
> If this was a poll, my vote would go to _begin()/_end().

I think begin/end are sensible.

An alternative is to make iter get/put work as get/put do, but I suppose
there's no real need for them to behave that way, i.e. it's
overengineering.

And if it wasn't clear, I didn't mean that this should block the patches
at hand in any way. Someone(tm) can follow up with the iter stuff later
on. It's not broken, it just feels slightly misleading after these
changes.

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 1/2] drm/rockchip: Do not use DMA mapping API if attached to IOMMU domain

[Mark Yao]

From: Tomasz Figa 

The API is not suitable for subsystems consisting of multiple devices
and requires severe hacks to use it. To mitigate this, this patch
implements allocation and address space management locally by using
helpers provided by DRM framework, like other DRM drivers do, e.g.
Tegra.

This patch should not introduce any functional changes until the driver
is made to attach subdevices into an IOMMU domain with the generic IOMMU
API, which will happen in following patch. Based heavily on GEM
implementation of Tegra DRM driver.

Signed-off-by: Tomasz Figa 
Signed-off-by: Shunqian Zheng 
Signed-off-by: Mark Yao 
Signed-off-by: rjan Eide 
Tested-by: Heiko Stuebner 
---
 drivers/gpu/drm/rockchip/rockchip_drm_drv.h |   6 +-
 drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 244 ++--
 drivers/gpu/drm/rockchip/rockchip_drm_gem.h |   8 +
 3 files changed, 244 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h 
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
index fb6226c..adc3930 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
@@ -30,6 +30,7 @@
 
 struct drm_device;
 struct drm_connector;
+struct iommu_domain;
 
 /*
  * Rockchip drm private crtc funcs.
@@ -60,7 +61,10 @@ struct rockchip_drm_private {
struct drm_gem_object *fbdev_bo;
const struct rockchip_crtc_funcs *crtc_funcs[ROCKCHIP_MAX_CRTC];
struct drm_atomic_state *state;
-
+   struct iommu_domain *domain;
+   /* protect drm_mm on multi-threads */
+   struct mutex mm_lock;
+   struct drm_mm mm;
struct list_head psr_list;
spinlock_t psr_list_lock;
 };
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
index b70f942..df9e570 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
@@ -16,11 +16,146 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "rockchip_drm_drv.h"
 #include "rockchip_drm_gem.h"
 
-static int rockchip_gem_alloc_buf(struct rockchip_gem_object *rk_obj,
+static int rockchip_gem_iommu_map(struct rockchip_gem_object *rk_obj)
+{
+   struct drm_device *drm = rk_obj->base.dev;
+   struct rockchip_drm_private *private = drm->dev_private;
+   int prot = IOMMU_READ | IOMMU_WRITE;
+   ssize_t ret;
+
+   mutex_lock(>mm_lock);
+
+   ret = drm_mm_insert_node_generic(>mm, _obj->mm,
+rk_obj->base.size, PAGE_SIZE,
+0, 0);
+
+   mutex_unlock(>mm_lock);
+   if (ret < 0) {
+   DRM_ERROR("out of I/O virtual memory: %zd\n", ret);
+   return ret;
+   }
+
+   rk_obj->dma_addr = rk_obj->mm.start;
+
+   ret = iommu_map_sg(private->domain, rk_obj->dma_addr, rk_obj->sgt->sgl,
+  rk_obj->sgt->nents, prot);
+   if (ret < rk_obj->base.size) {
+   DRM_ERROR("failed to map buffer: size=%zd request_size=%zd\n",
+ ret, rk_obj->base.size);
+   ret = -ENOMEM;
+   goto err_remove_node;
+   }
+
+   rk_obj->size = ret;
+
+   return 0;
+
+err_remove_node:
+   drm_mm_remove_node(_obj->mm);
+
+   return ret;
+}
+
+static int rockchip_gem_iommu_unmap(struct rockchip_gem_object *rk_obj)
+{
+   struct drm_device *drm = rk_obj->base.dev;
+   struct rockchip_drm_private *private = drm->dev_private;
+
+   iommu_unmap(private->domain, rk_obj->dma_addr, rk_obj->size);
+
+   mutex_lock(>mm_lock);
+
+   drm_mm_remove_node(_obj->mm);
+
+   mutex_unlock(>mm_lock);
+
+   return 0;
+}
+
+static int rockchip_gem_get_pages(struct rockchip_gem_object *rk_obj)
+{
+   struct drm_device *drm = rk_obj->base.dev;
+   int ret, i;
+   struct scatterlist *s;
+
+   rk_obj->pages = drm_gem_get_pages(_obj->base);
+   if (IS_ERR(rk_obj->pages))
+   return PTR_ERR(rk_obj->pages);
+
+   rk_obj->num_pages = rk_obj->base.size >> PAGE_SHIFT;
+
+   rk_obj->sgt = drm_prime_pages_to_sg(rk_obj->pages, rk_obj->num_pages);
+   if (IS_ERR(rk_obj->sgt)) {
+   ret = PTR_ERR(rk_obj->sgt);
+   goto err_put_pages;
+   }
+
+   /*
+* Fake up the SG table so that dma_sync_sg_for_device() can be used
+* to flush the pages associated with it.
+*
+* TODO: Replace this by drm_clflush_sg() once it can be implemented
+* without relying on symbols that are not exported.
+*/
+   for_each_sg(rk_obj->sgt->sgl, s, rk_obj->sgt->nents, i)
+   sg_dma_address(s) = sg_phys(s);
+
+   dma_sync_sg_for_device(drm->dev, rk_obj->sgt->sgl, rk_obj->sgt->nents,
+  DMA_TO_DEVICE);
+
+   return 

[PATCH v3 0/2] drm/rockchip: switch to drm_mm for support arm64 iommu

[Mark Yao]

Some iommu patches on the series[0] "iommu/rockchip: Fix bugs and
enable on ARM64" already landed, So drm/rockchip related patches [1] and [2]
ready to landed, this series just rebase them to lastest drm-next.

Thanks Heiko's Tested-by on rk3288 and rk3399 platform.

Changes in v3:
Advices by Tomasz and Thierry:
  merge fixes into origin patch.

Changes in v2:
Advices by Tomasz:
  add some fixes patches from chromeos project.

Shunqian Zheng (1):
  drm/rockchip: Use common IOMMU API to attach devices

Tomasz Figa (1):
  drm/rockchip: Do not use DMA mapping API if attached to IOMMU domain

 drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 101 ++--
 drivers/gpu/drm/rockchip/rockchip_drm_drv.h |   6 +-
 drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 244 ++--
 drivers/gpu/drm/rockchip/rockchip_drm_gem.h |   8 +
 4 files changed, 298 insertions(+), 61 deletions(-)

-- 
1.9.1


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 2/2] drm/rockchip: Use common IOMMU API to attach devices

[Mark Yao]

From: Shunqian Zheng 

Rockchip DRM used the arm special API, arm_iommu_*(), to attach
iommu for ARM32 SoCs. This patch convert to common iommu API
so it would support ARM64 like RK3399.

Since previous patch added support for direct IOMMU address space
management, there is no need to use DMA API anymore and this patch wires
things to use the new method.

Signed-off-by: Shunqian Zheng 
Signed-off-by: Tomasz Figa 
Signed-off-by: Mark Yao 
Tested-by: Heiko Stuebner 
---
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 101 +++-
 1 file changed, 54 insertions(+), 47 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
index c30d649..b360e62 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
@@ -14,19 +14,19 @@
  * GNU General Public License for more details.
  */
 
-#include 
-
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 
 #include "rockchip_drm_drv.h"
 #include "rockchip_drm_fb.h"
@@ -50,28 +50,31 @@
 int rockchip_drm_dma_attach_device(struct drm_device *drm_dev,
   struct device *dev)
 {
-   struct dma_iommu_mapping *mapping = drm_dev->dev->archdata.mapping;
+   struct rockchip_drm_private *private = drm_dev->dev_private;
int ret;
 
if (!is_support_iommu)
return 0;
 
-   ret = dma_set_coherent_mask(dev, DMA_BIT_MASK(32));
-   if (ret)
+   ret = iommu_attach_device(private->domain, dev);
+   if (ret) {
+   dev_err(dev, "Failed to attach iommu device\n");
return ret;
+   }
 
-   dma_set_max_seg_size(dev, DMA_BIT_MASK(32));
-
-   return arm_iommu_attach_device(dev, mapping);
+   return 0;
 }
 
 void rockchip_drm_dma_detach_device(struct drm_device *drm_dev,
struct device *dev)
 {
+   struct rockchip_drm_private *private = drm_dev->dev_private;
+   struct iommu_domain *domain = private->domain;
+
if (!is_support_iommu)
return;
 
-   arm_iommu_detach_device(dev);
+   iommu_detach_device(domain, dev);
 }
 
 int rockchip_register_crtc_funcs(struct drm_crtc *crtc,
@@ -123,11 +126,46 @@ static void rockchip_drm_crtc_disable_vblank(struct 
drm_device *dev,
priv->crtc_funcs[pipe]->disable_vblank(crtc);
 }
 
+static int rockchip_drm_init_iommu(struct drm_device *drm_dev)
+{
+   struct rockchip_drm_private *private = drm_dev->dev_private;
+   struct iommu_domain_geometry *geometry;
+   u64 start, end;
+
+   if (!is_support_iommu)
+   return 0;
+
+   private->domain = iommu_domain_alloc(_bus_type);
+   if (!private->domain)
+   return -ENOMEM;
+
+   geometry = >domain->geometry;
+   start = geometry->aperture_start;
+   end = geometry->aperture_end;
+
+   DRM_DEBUG("IOMMU context initialized (aperture: %#llx-%#llx)\n",
+ start, end);
+   drm_mm_init(>mm, start, end - start + 1);
+   mutex_init(>mm_lock);
+
+   return 0;
+}
+
+static void rockchip_iommu_cleanup(struct drm_device *drm_dev)
+{
+   struct rockchip_drm_private *private = drm_dev->dev_private;
+
+   if (!is_support_iommu)
+   return;
+
+   drm_mm_takedown(>mm);
+   iommu_domain_free(private->domain);
+}
+
 static int rockchip_drm_bind(struct device *dev)
 {
struct drm_device *drm_dev;
struct rockchip_drm_private *private;
-   struct dma_iommu_mapping *mapping = NULL;
int ret;
 
drm_dev = drm_dev_alloc(_drm_driver, dev);
@@ -151,38 +189,14 @@ static int rockchip_drm_bind(struct device *dev)
 
rockchip_drm_mode_config_init(drm_dev);
 
-   dev->dma_parms = devm_kzalloc(dev, sizeof(*dev->dma_parms),
- GFP_KERNEL);
-   if (!dev->dma_parms) {
-   ret = -ENOMEM;
+   ret = rockchip_drm_init_iommu(drm_dev);
+   if (ret)
goto err_config_cleanup;
-   }
-
-   if (is_support_iommu) {
-   /* TODO(djkurtz): fetch the mapping start/size from somewhere */
-   mapping = arm_iommu_create_mapping(_bus_type,
-  0x,
-  SZ_2G);
-   if (IS_ERR(mapping)) {
-   ret = PTR_ERR(mapping);
-   goto err_config_cleanup;
-   }
-
-   ret = dma_set_mask_and_coherent(dev, DMA_BIT_MASK(32));
-   if (ret)
-   goto err_release_mapping;
-
-   dma_set_max_seg_size(dev, DMA_BIT_MASK(32));
-
-   ret = arm_iommu_attach_device(dev, 

[Bug 190971] amdgpu (on Kabini) fails to resume, atombios stuck executing BA98

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=190971

gnube...@gmail.com changed:

   What|Removed |Added

 CC||gnube...@gmail.com

--- Comment #1 from gnube...@gmail.com ---
Still happening for me as well, currently at 4.9.8 on a Toshiba Satellite with
an HD 8400 Kabini, getting the same kernel messages and blank screen on resume.
System is otherwise responsive and the backlight comes on. Continuing to test
amdgpu, albeit with my lid set to hibernate.

-- 
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 194533] Invalid PCI ROM header signature: expecting 0xaa55, got 0x9125

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=194533

--- Comment #4 from Alex Deucher (alexdeuc...@gmail.com) ---
(In reply to nucrap from comment #3)
> So this error warning will never disappear?

Correct.  The message is not actually from the driver.  It's printed by the
core pci rom code.

-- 
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 194533] Invalid PCI ROM header signature: expecting 0xaa55, got 0x9125

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=194533

--- Comment #3 from nuc...@hotmail.com ---
So this error warning will never disappear?

-- 
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 194533] Invalid PCI ROM header signature: expecting 0xaa55, got 0x9125

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=194533

Alex Deucher (alexdeuc...@gmail.com) changed:

   What|Removed |Added

 CC||alexdeuc...@gmail.com

--- Comment #2 from Alex Deucher (alexdeuc...@gmail.com) ---
(In reply to nucrap from comment #0)
> I get "Invalid PCI ROM header signature: expecting 0xaa55, got 0x9125" upon
> booting my PC with my new Sapphire RX 470 OC graphics card.

This is harmless.  The driver is ultimately able to find the vbios image.  If
it was not able to, the driver would fail to load.  There is no bug here.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 99744] Bad crtc detection on Radeon Pro WX 4100

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=99744

--- Comment #7 from Alex Deucher  ---
Created attachment 129464
  --> https://bugs.freedesktop.org/attachment.cgi?id=129464=edit
possible fix

This patch should fix the issue.

-- 
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 99444] [radeonsi] The Witcher 3 (GOG/1.31) [Wine] starting menu is distorted

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=99444

--- Comment #20 from Shmerl  ---
FYI: I just tested it with wine-staging 2.1 with CSMT enabled (that version
allows using it with DX11 already), and corruption in the start menu is gone.

-- 
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 65968] Massive memory corruption in Planetary Annihilation Alpha

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=65968

--- Comment #9 from Timothy Arceri  ---
(In reply to Timothy Arceri from comment #8)
> Actually no I take that back it is using core profile.

It's requesting a core profile and using compat features.

-- 
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 65968] Massive memory corruption in Planetary Annihilation Alpha

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=65968

--- Comment #8 from Timothy Arceri  ---
Actually no I take that back it is using core profile.

-- 
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 99744] Bad crtc detection on Radeon Pro WX 4100

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=99744

--- Comment #6 from Matt Corallo  ---
Created attachment 129463
  --> https://bugs.freedesktop.org/attachment.cgi?id=129463=edit
xrandr --verbose

-- 
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 65968] Massive memory corruption in Planetary Annihilation Alpha

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=65968

--- Comment #7 from Timothy Arceri  ---
Planetary Annihilation is using compat profile. When I override the Mesa
version
with MESA_GL_VERSION_OVERRIDE=3.1COMPAT the corruptions are fixed but it later
crashes.

-- 
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 99744] Bad crtc detection on Radeon Pro WX 4100

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=99744

--- Comment #5 from Michel Dänzer  ---
This bugzilla is preferred for kernel driver issues as well. I reassigned this
report to the correct product and component.

Can you also attach the output of xrandr --verbose?

-- 
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 99744] Bad crtc detection on Radeon Pro WX 4100

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=99744

Michel Dänzer  changed:

   What|Removed |Added

 Attachment #129462|text/x-log  |text/plain
  mime type||

-- 
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 99744] Bad crtc detection on Radeon Pro WX 4100

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=99744

Michel Dänzer  changed:

   What|Removed |Added

 Attachment #129461|text/x-log  |text/plain
  mime type||

-- 
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 193981] AMDGPU: R9 380 Fan rotates all the time (loud!)

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=193981

--- Comment #8 from Michel Dänzer (mic...@daenzer.net) ---
(In reply to fin4478 from comment #5)

fin4...@hotmail.com, this kind of comment is essentially noise and makes the
lives of those of us working with bug reports and fixing problems harder.
Please stop, thanks.

-- 
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 99744] Bad crtc detection on Radeon Pro WX 4100

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=99744

--- Comment #4 from Matt Corallo  ---
Attached (possibly) relevant logs. Will test on the staging branch when I get a
chance (probably in a week or two). I figured the issue would be with the
kernel driver but didnt see an obviously better place to file a bug, should I
have filed on kernel bugzilla?

-- 
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 99744] Bad crtc detection on Radeon Pro WX 4100

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=99744

--- Comment #3 from Matt Corallo  ---
Created attachment 129462
  --> https://bugs.freedesktop.org/attachment.cgi?id=129462=edit
dmesg grep amd, drm, dmar (in case its relevant)

-- 
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 99744] Bad crtc detection on Radeon Pro WX 4100

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=99744

--- Comment #2 from Matt Corallo  ---
Created attachment 129461
  --> https://bugs.freedesktop.org/attachment.cgi?id=129461=edit
Xorg.log

-- 
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 97879] [amdgpu] Rocket League: long hangs (several seconds) when loading assets (models/textures/shaders?)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=97879

--- Comment #76 from fin4...@hotmail.com ---
I tested the game and with default video settings it did hang sometimes, but
dialing video settings down, the Rocket League works fine with Debian testing
Xfce. Oipaf ppa and custom adg5f drm-next-4.11-wip kernel. Rx 460 is my gpu and
I have tweaked the kernel to be fast and stable, see:
https://bugzilla.kernel.org/show_bug.cgi?id=193651

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2] drm/i915/debugfs: Add i915_hpd_storm_ctl

[Lyude]

This adds a file in i915's debugfs directory that allows userspace to
manually control HPD storm detection. This is mainly for hotplugging
tests, where we might want to test HPD storm functionality or disable
storm detection to speed up hotplugging tests without breaking anything.

Changes since v1:
- Make HPD storm interval configurable
- Misc code cleanup

Signed-off-by: Lyude 
Cc: Jani Nikula 
Cc: Tomeu Vizoso 
---
 drivers/gpu/drm/i915/i915_debugfs.c  | 78 +++-
 drivers/gpu/drm/i915/i915_drv.c  |  1 +
 drivers/gpu/drm/i915/i915_drv.h  |  4 ++
 drivers/gpu/drm/i915/i915_irq.c  |  2 +
 drivers/gpu/drm/i915/intel_hotplug.c | 15 ---
 5 files changed, 94 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 1ccc297..b55547d 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4641,6 +4641,81 @@ static int i915_forcewake_create(struct dentry *root, 
struct drm_minor *minor)
return drm_add_fake_info_node(minor, ent, _forcewake_fops);
 }
 
+static int i915_hpd_storm_ctl_show(struct seq_file *m, void *data)
+{
+   struct drm_i915_private *dev_priv = m->private;
+   struct i915_hotplug *hotplug = _priv->hotplug;
+
+   seq_printf(m, "Threshold: %d\n", hotplug->hpd_storm_threshold);
+   seq_printf(m, "Detected: %s\n",
+  yesno(delayed_work_pending(>reenable_work)));
+
+   return 0;
+}
+
+static ssize_t i915_hpd_storm_ctl_write(struct file *file,
+   const char __user *ubuf, size_t len,
+   loff_t *offp)
+{
+   struct seq_file *m = file->private_data;
+   struct drm_i915_private *dev_priv = m->private;
+   struct i915_hotplug *hotplug = _priv->hotplug;
+   unsigned int new_threshold;
+   int i;
+   char *newline;
+   char tmp[16];
+
+   if (len >= sizeof(tmp))
+   return -EINVAL;
+
+   if (copy_from_user(tmp, ubuf, len))
+   return -EFAULT;
+
+   tmp[len] = '\0';
+
+   /* Strip newline, if any */
+   newline = strchr(tmp, '\n');
+   if (newline)
+   *newline = '\0';
+
+   if (strcmp(tmp, "reset") == 0)
+   new_threshold = HPD_STORM_DEFAULT_THRESHOLD;
+   else if (kstrtouint(tmp, 10, _threshold) != 0)
+   return -EINVAL;
+
+   if (new_threshold > 0)
+   DRM_DEBUG_KMS("Setting HPD storm detection threshold to %d\n",
+ new_threshold);
+   else
+   DRM_DEBUG_KMS("Disabling HPD storm detection\n");
+
+   spin_lock_irq(_priv->irq_lock);
+   hotplug->hpd_storm_threshold = new_threshold;
+   /* Reset the HPD storm stats so we don't accidentally trigger a storm */
+   for_each_hpd_pin(i)
+   hotplug->stats[i].count = 0;
+   spin_unlock_irq(_priv->irq_lock);
+
+   /* Re-enable hpd immediately if we were in an irq storm */
+   flush_delayed_work(_priv->hotplug.reenable_work);
+
+   return len;
+}
+
+static int i915_hpd_storm_ctl_open(struct inode *inode, struct file *file)
+{
+   return single_open(file, i915_hpd_storm_ctl_show, inode->i_private);
+}
+
+static const struct file_operations i915_hpd_storm_ctl_fops = {
+   .owner = THIS_MODULE,
+   .open = i915_hpd_storm_ctl_open,
+   .read = seq_read,
+   .llseek = seq_lseek,
+   .release = single_release,
+   .write = i915_hpd_storm_ctl_write
+};
+
 static int i915_debugfs_create(struct dentry *root,
   struct drm_minor *minor,
   const char *name,
@@ -4734,7 +4809,8 @@ static const struct i915_debugfs_files {
{"i915_dp_test_data", _displayport_test_data_fops},
{"i915_dp_test_type", _displayport_test_type_fops},
{"i915_dp_test_active", _displayport_test_active_fops},
-   {"i915_guc_log_control", _guc_log_control_fops}
+   {"i915_guc_log_control", _guc_log_control_fops},
+   {"i915_hpd_storm_ctl", _hpd_storm_ctl_fops}
 };
 
 int i915_debugfs_register(struct drm_i915_private *dev_priv)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index d48c02a7..f23b568 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -827,6 +827,7 @@ static int i915_driver_init_early(struct drm_i915_private 
*dev_priv,
spin_lock_init(_priv->gpu_error.lock);
mutex_init(_priv->backlight_lock);
spin_lock_init(_priv->uncore.lock);
+
spin_lock_init(_priv->mm.object_stat_lock);
spin_lock_init(_priv->mmio_flip_lock);
spin_lock_init(_priv->wm.dsparb_lock);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 604b20f..2b7b317 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ 

[PATCH v3 6/8] drm/dp: Add DP MST helpers to atomically find and release vcpi slots

[Dhinakaran Pandiyan]

drm_dp_atomic_find_vcpi_slots() should be called from ->atomic_check() to
check there are sufficient vcpi slots for a mode and to add that to the
state. This should be followed by a call to drm_dp_mst_allocate_vcpi()
in ->atomic_commit() to initialize a struct vcpi for the port.

drm_dp_atomic_release_vcpi_slots() should be called from
->atomic_check() to release a port's vcpi slot allocation from the
state.

Drivers that do not make use of this atomic helper are expected to call
drm_dp_find_vcpi_slots() instead before calling
drm_dp_mst_allocate_vcpi().

v2:
Added checks for verifying the port reference is valid
Moved get_mst_topology_state() into the helpers (Daniel)
Changed find_vcpi_slots() to not depend on current allocation

Signed-off-by: Dhinakaran Pandiyan 
---
 drivers/gpu/drm/drm_dp_mst_topology.c | 75 +++
 include/drm/drm_dp_mst_helper.h   |  6 +++
 2 files changed, 81 insertions(+)

diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
b/drivers/gpu/drm/drm_dp_mst_topology.c
index a891c36..93de257 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -2498,6 +2498,81 @@ static int drm_dp_init_vcpi(struct 
drm_dp_mst_topology_mgr *mgr,
 }
 
 /**
+ * drm_dp_atomic_find_vcpi_slots() - Find and add vcpi slots to the state
+ * @state: global atomic state
+ * @mgr: MST topology manager for the port
+ * @port: port to find vcpi slots for
+ * @pbn: bandwidth required for the mode in PBN
+ *
+ * RETURNS:
+ * Total slots in the atomic state assigned for this port or error
+ */
+int drm_dp_atomic_find_vcpi_slots(struct drm_atomic_state *state,
+ struct drm_dp_mst_topology_mgr *mgr,
+ struct drm_dp_mst_port *port, int pbn)
+{
+   struct drm_dp_mst_topology_state *topology_state;
+   int req_slots;
+
+   topology_state = drm_atomic_get_mst_topology_state(state, mgr);
+   if (topology_state == NULL)
+   return -ENOMEM;
+
+   port = drm_dp_get_validated_port_ref(mgr, port);
+   if (port == NULL)
+   return -EINVAL;
+   req_slots = DIV_ROUND_UP(pbn, mgr->pbn_div);
+   DRM_DEBUG_KMS("vcpi slots req=%d, avail=%d\n",
+   req_slots, topology_state->avail_slots);
+
+   if (req_slots > topology_state->avail_slots) {
+   drm_dp_put_port(port);
+   return -ENOSPC;
+   }
+
+   topology_state->avail_slots -= req_slots;
+   DRM_DEBUG_KMS("vcpi slots avail=%d", topology_state->avail_slots);
+
+   drm_dp_put_port(port);
+   return req_slots;
+}
+EXPORT_SYMBOL(drm_dp_atomic_find_vcpi_slots);
+
+/**
+ * drm_dp_atomic_release_vcpi_slots() - Release allocated vcpi slots
+ * @state: global atomic state
+ * @mgr: MST topology manager for the port
+ * @port: port to release the vcpi slots for
+ *
+ * RETURNS:
+ * Number of slots released from the atomic state for this port
+ */
+int drm_dp_atomic_release_vcpi_slots(struct drm_atomic_state *state,
+struct drm_dp_mst_topology_mgr *mgr,
+struct drm_dp_mst_port *port)
+{
+   struct drm_dp_mst_topology_state *topology_state;
+   int curr_slots;
+
+   topology_state = drm_atomic_get_mst_topology_state(state, mgr);
+   if (topology_state == NULL)
+   return -ENOMEM;
+
+   port = drm_dp_get_validated_port_ref(mgr, port);
+   if (port == NULL)
+   return -EINVAL;
+
+   curr_slots = port->vcpi.num_slots;
+   topology_state->avail_slots += curr_slots;
+   DRM_DEBUG_KMS("vcpi slots released=%d, avail=%d\n",
+   curr_slots, topology_state->avail_slots);
+
+   drm_dp_put_port(port);
+   return curr_slots;
+}
+EXPORT_SYMBOL(drm_dp_atomic_release_vcpi_slots);
+
+/**
  * drm_dp_mst_allocate_vcpi() - Allocate a virtual channel
  * @mgr: manager for this port
  * @port: port to allocate a virtual channel for.
diff --git a/include/drm/drm_dp_mst_helper.h b/include/drm/drm_dp_mst_helper.h
index 0b371df..64e7dac 100644
--- a/include/drm/drm_dp_mst_helper.h
+++ b/include/drm/drm_dp_mst_helper.h
@@ -615,5 +615,11 @@ void drm_dp_mst_topology_mgr_suspend(struct 
drm_dp_mst_topology_mgr *mgr);
 int drm_dp_mst_topology_mgr_resume(struct drm_dp_mst_topology_mgr *mgr);
 struct drm_dp_mst_topology_state *drm_atomic_get_mst_topology_state(struct 
drm_atomic_state *state,
struct 
drm_dp_mst_topology_mgr *mgr);
+int drm_dp_atomic_find_vcpi_slots(struct drm_atomic_state *state,
+ struct drm_dp_mst_topology_mgr *mgr,
+ struct drm_dp_mst_port *port, int pbn);
+int drm_dp_atomic_release_vcpi_slots(struct drm_atomic_state *state,
+struct drm_dp_mst_topology_mgr *mgr,
+

[PATCH v3 4/8] drm: Add driver-private objects to atomic state

[Dhinakaran Pandiyan]

It is necessary to track states for objects other than connector, crtc
and plane for atomic modesets. But adding objects like DP MST link
bandwidth to drm_atomic_state would mean that a non-core object will be
modified by the core helper functions for swapping and clearing
it's state. So, lets add void * objects and helper functions that operate
on void * types to keep these objects and states private to the core.
Drivers can then implement specific functions to swap and clear states.
The other advantage having just void * for these objects in
drm_atomic_state is that objects of different types can be managed in the
same state array.

v2: Added docs and new iterator to filter private objects (Daniel)

Suggested-by: Daniel Vetter 
Signed-off-by: Dhinakaran Pandiyan 
---
 drivers/gpu/drm/drm_atomic.c| 68 +++
 drivers/gpu/drm/drm_atomic_helper.c |  5 ++
 include/drm/drm_atomic.h| 91 +
 3 files changed, 164 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index a567310..1a9ffe8 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -57,6 +57,7 @@ void drm_atomic_state_default_release(struct drm_atomic_state 
*state)
kfree(state->connectors);
kfree(state->crtcs);
kfree(state->planes);
+   kfree(state->private_objs);
 }
 EXPORT_SYMBOL(drm_atomic_state_default_release);
 
@@ -184,6 +185,20 @@ void drm_atomic_state_default_clear(struct 
drm_atomic_state *state)
state->planes[i].ptr = NULL;
state->planes[i].state = NULL;
}
+
+   for (i = 0; i < state->num_private_objs; i++) {
+   void *private_obj = state->private_objs[i].obj;
+   void *obj_state = state->private_objs[i].obj_state;
+
+   if (!private_obj)
+   continue;
+
+   state->private_objs[i].funcs->destroy_state(obj_state);
+   state->private_objs[i].obj = NULL;
+   state->private_objs[i].obj_state = NULL;
+   state->private_objs[i].funcs = NULL;
+   }
+
 }
 EXPORT_SYMBOL(drm_atomic_state_default_clear);
 
@@ -974,6 +989,59 @@ static void drm_atomic_plane_print_state(struct 
drm_printer *p,
 }
 
 /**
+ * drm_atomic_get_private_obj_state - get private object state
+ * @state: global atomic state
+ * @obj: private object to get the state for
+ * @funcs: pointer to the struct of function pointers that identify the object
+ * type
+ *
+ * This function returns the private object state for the given private object,
+ * allocating the state if needed. It does not grab any locks as the caller is
+ * expected to care of any required locking.
+ *
+ * RETURNS:
+ *
+ * Either the allocated state or the error code encoded into a pointer.
+ */
+void *
+drm_atomic_get_private_obj_state(struct drm_atomic_state *state, void *obj,
+ const struct drm_private_state_funcs *funcs)
+{
+   int index, num_objs, i;
+   size_t size;
+   struct __drm_private_objs_state *arr;
+
+   for (i = 0; i < state->num_private_objs; i++)
+   if (obj == state->private_objs[i].obj &&
+   state->private_objs[i].obj_state)
+   return state->private_objs[i].obj_state;
+
+   num_objs = state->num_private_objs + 1;
+   size = sizeof(*state->private_objs) * num_objs;
+   arr = krealloc(state->private_objs, size, GFP_KERNEL);
+   if (!arr)
+   return ERR_PTR(-ENOMEM);
+
+   state->private_objs = arr;
+   index = state->num_private_objs;
+   memset(>private_objs[index], 0, sizeof(*state->private_objs));
+
+   state->private_objs[index].obj_state = funcs->duplicate_state(state, 
obj);
+   if (!state->private_objs[index].obj_state)
+   return ERR_PTR(-ENOMEM);
+
+   state->private_objs[index].obj = obj;
+   state->private_objs[index].funcs = funcs;
+   state->num_private_objs = num_objs;
+
+   DRM_DEBUG_ATOMIC("Added new private object state %p to %p\n",
+state->private_objs[index].obj_state, state);
+
+   return state->private_objs[index].obj_state;
+}
+EXPORT_SYMBOL(drm_atomic_get_private_obj_state);
+
+/**
  * drm_atomic_get_connector_state - get connector state
  * @state: global atomic state object
  * @connector: connector to get state object for
diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 3a4383f..8795088 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1983,6 +1983,8 @@ void drm_atomic_helper_swap_state(struct drm_atomic_state 
*state,
struct drm_plane *plane;
struct drm_plane_state *plane_state;
struct drm_crtc_commit *commit;
+   void *obj, *obj_state;
+   const struct drm_private_state_funcs *funcs;
 
   

[PATCH -next] drm/bridge/tfp410: Make symbol tfp410_platform_driver static

[Wei Yongjun]

From: Wei Yongjun 

Fixes the following sparse warning:

drivers/gpu/drm/bridge/ti-tfp410.c:223:24: warning:
 symbol 'tfp410_platform_driver' was not declared. Should it be static?

Signed-off-by: Wei Yongjun 
---
 drivers/gpu/drm/bridge/ti-tfp410.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/ti-tfp410.c 
b/drivers/gpu/drm/bridge/ti-tfp410.c
index b054ea3..b379d04 100644
--- a/drivers/gpu/drm/bridge/ti-tfp410.c
+++ b/drivers/gpu/drm/bridge/ti-tfp410.c
@@ -220,7 +220,7 @@ static const struct of_device_id tfp410_match[] = {
 };
 MODULE_DEVICE_TABLE(of, tfp410_match);
 
-struct platform_driver tfp410_platform_driver = {
+static struct platform_driver tfp410_platform_driver = {
.probe  = tfp410_probe,
.remove = tfp410_remove,
.driver = {

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 2/6] drm: make of_drm_find_panel also depend on CONFIG_DRM_PANEL

[Rob Herring]

For drm_of_find_panel_or_bridge() added in the next commit, an empty
version of of_drm_find_panel is needed for !CONFIG_DRM_PANEL.

Signed-off-by: Rob Herring 
---
v2:
- new patch

 include/drm/drm_panel.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/drm/drm_panel.h b/include/drm/drm_panel.h
index 220d1e2b3db1..960b5fd5ed18 100644
--- a/include/drm/drm_panel.h
+++ b/include/drm/drm_panel.h
@@ -192,7 +192,7 @@ void drm_panel_remove(struct drm_panel *panel);
 int drm_panel_attach(struct drm_panel *panel, struct drm_connector *connector);
 int drm_panel_detach(struct drm_panel *panel);

-#ifdef CONFIG_OF
+#if defined(CONFIG_OF) && defined(CONFIG_DRM_PANEL)
 struct drm_panel *of_drm_find_panel(struct device_node *np);
 #else
 static inline struct drm_panel *of_drm_find_panel(struct device_node *np)
--
2.10.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH -next] drm/msm/dsi: fix error return code in msm_dsi_host_init()

[Wei Yongjun]

From: Wei Yongjun 

Fix to return error code -ENOMEM from the malloc error handling
case instead of 0, as done elsewhere in this function.

Signed-off-by: Wei Yongjun 
---
 drivers/gpu/drm/msm/dsi/dsi_host.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c 
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index 1fc07ce..4f79b10 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -1740,6 +1740,7 @@ int msm_dsi_host_init(struct msm_dsi *msm_dsi)
 
msm_host->rx_buf = devm_kzalloc(>dev, SZ_4K, GFP_KERNEL);
if (!msm_host->rx_buf) {
+   ret = -ENOMEM;
pr_err("%s: alloc rx temp buf failed\n", __func__);
goto fail;
}

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 7/8] drm: Connector helper function to release resources

[Dhinakaran Pandiyan]

Having a ->atomic_release callback is useful to release shared resources
that get allocated in compute_config(). This function is expected to be
called in the atomic_check() phase before new resources are acquired.

v2: Moved the caller hunk to this patch (Daniel)

Suggested-by: Daniel Vetter 
Signed-off-by: Dhinakaran Pandiyan 
---
 drivers/gpu/drm/drm_atomic_helper.c  | 19 +++
 include/drm/drm_modeset_helper_vtables.h | 13 +
 2 files changed, 32 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 8795088..92bd741 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -576,6 +576,25 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
}
}
 
+   for_each_connector_in_state(state, connector, connector_state, i) {
+   const struct drm_connector_helper_funcs *conn_funcs;
+   struct drm_crtc_state *crtc_state;
+
+   conn_funcs = connector->helper_private;
+   if (!conn_funcs->atomic_release)
+   continue;
+
+   if (!connector->state->crtc)
+   continue;
+
+   crtc_state = drm_atomic_get_existing_crtc_state(state, 
connector->state->crtc);
+
+   if (crtc_state->connectors_changed ||
+   crtc_state->mode_changed ||
+   (crtc_state->active_changed && !crtc_state->active))
+   conn_funcs->atomic_release(connector, connector_state);
+   }
+
return mode_fixup(state);
 }
 EXPORT_SYMBOL(drm_atomic_helper_check_modeset);
diff --git a/include/drm/drm_modeset_helper_vtables.h 
b/include/drm/drm_modeset_helper_vtables.h
index 091c422..394ec0c 100644
--- a/include/drm/drm_modeset_helper_vtables.h
+++ b/include/drm/drm_modeset_helper_vtables.h
@@ -836,6 +836,19 @@ struct drm_connector_helper_funcs {
 */
struct drm_encoder *(*atomic_best_encoder)(struct drm_connector 
*connector,
   struct drm_connector_state 
*connector_state);
+
+   /**
+* @atomic_release:
+*
+* This function is used to release shared resources that were
+* previously acquired.
+*
+* NOTE:
+*
+* This function is called in the check phase of an atomic update.
+*/
+   void (*atomic_release)(struct drm_connector *connector,
+  struct drm_connector_state *connector_state);
 };
 
 /**
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 3/8] mm: cma: Export a few symbols

[Michal Hocko]

[CC CMA people]

On Thu 09-02-17 17:39:17, Maxime Ripard wrote:
> Modules might want to check their CMA pool size and address for debugging
> and / or have additional checks.
> 
> The obvious way to do this would be through dev_get_cma_area and
> cma_get_base and cma_get_size, that are currently not exported, which
> results in a build failure.
> 
> Export them to prevent such a failure.

Who actually uses those exports. None of the follow up patches does
AFAICS.

> Signed-off-by: Maxime Ripard 
> ---
>  drivers/base/dma-contiguous.c | 1 +
>  mm/cma.c  | 2 ++
>  2 files changed, 3 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/base/dma-contiguous.c b/drivers/base/dma-contiguous.c
> index e167a1e1bccb..60f5c2591ccd 100644
> --- a/drivers/base/dma-contiguous.c
> +++ b/drivers/base/dma-contiguous.c
> @@ -35,6 +35,7 @@
>  #endif
>  
>  struct cma *dma_contiguous_default_area;
> +EXPORT_SYMBOL(dma_contiguous_default_area);
>  
>  /*
>   * Default global CMA area size can be defined in kernel's .config.
> diff --git a/mm/cma.c b/mm/cma.c
> index c960459eda7e..b50245282a18 100644
> --- a/mm/cma.c
> +++ b/mm/cma.c
> @@ -47,11 +47,13 @@ phys_addr_t cma_get_base(const struct cma *cma)
>  {
>   return PFN_PHYS(cma->base_pfn);
>  }
> +EXPORT_SYMBOL(cma_get_base);
>  
>  unsigned long cma_get_size(const struct cma *cma)
>  {
>   return cma->count << PAGE_SHIFT;
>  }
> +EXPORT_SYMBOL(cma_get_size);
>  
>  static unsigned long cma_bitmap_aligned_mask(const struct cma *cma,
>int align_order)
> -- 
> git-series 0.8.11
> 
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majord...@kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: mailto:"d...@kvack.org;> em...@kvack.org 

-- 
Michal Hocko
SUSE Labs
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 3/6] drm: of: introduce drm_of_find_panel_or_bridge

[Rob Herring]

Many drivers have a common pattern of searching the OF graph for either an
attached panel or bridge and then finding the DRM struct for the panel
or bridge. Also, most drivers need to handle deferred probing when the
DRM device is not yet instantiated. Create a common function,
drm_of_find_panel_or_bridge, to find the connected node and the
associated DRM panel or bridge device.

Signed-off-by: Rob Herring 
Acked-by: Philipp Zabel 
---
v2:
- Reworked code flow
- Added note that at least one of panel or bridge must not be NULL.

 drivers/gpu/drm/drm_of.c | 52 
 include/drm/drm_of.h | 13 
 2 files changed, 65 insertions(+)

diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c
index 47848ed8ca48..86b8b959587a 100644
--- a/drivers/gpu/drm/drm_of.c
+++ b/drivers/gpu/drm/drm_of.c
@@ -3,7 +3,9 @@
 #include 
 #include 
 #include 
+#include 
 #include 
+#include 
 #include 

 static void drm_release_of(struct device *dev, void *data)
@@ -207,3 +209,53 @@ int drm_of_encoder_active_endpoint(struct device_node 
*node,
return -EINVAL;
 }
 EXPORT_SYMBOL_GPL(drm_of_encoder_active_endpoint);
+
+/*
+ * drm_of_find_panel_or_bridge - return connected panel or bridge device
+ * @np: device tree node containing encoder input ports
+ * @panel: pointer to hold returned drm_panel
+ * @bridge: pointer to hold returned drm_bridge
+ *
+ * Given a DT node's port and endpoint number, find the connected node and
+ * return either the associated struct drm_panel or drm_bridge device. Either
+ * @panel or @bridge must not be NULL.
+ *
+ * Returns zero if successful, or one of the standard error codes if it fails.
+ */
+int drm_of_find_panel_or_bridge(const struct device_node *np,
+   int port, int endpoint,
+   struct drm_panel **panel,
+   struct drm_bridge **bridge)
+{
+   int ret = -EPROBE_DEFER;
+   struct device_node *remote;
+
+   if (!panel && !bridge)
+   return -EINVAL;
+
+   remote = of_graph_get_remote_node(np, port, endpoint);
+   if (!remote)
+   return -ENODEV;
+
+   if (panel) {
+   *panel = of_drm_find_panel(remote);
+   if (*panel)
+   ret = 0;
+   }
+
+   /* No panel found yet, check for a bridge next. */
+   if (bridge) {
+   if (ret) {
+   *bridge = of_drm_find_bridge(remote);
+   if (*bridge)
+   ret = 0;
+   } else {
+   *bridge = NULL;
+   }
+
+   }
+
+   of_node_put(remote);
+   return ret;
+}
+EXPORT_SYMBOL_GPL(drm_of_find_panel_or_bridge);
diff --git a/include/drm/drm_of.h b/include/drm/drm_of.h
index 26a64805cc15..f86507f0599b 100644
--- a/include/drm/drm_of.h
+++ b/include/drm/drm_of.h
@@ -8,6 +8,8 @@ struct component_match;
 struct device;
 struct drm_device;
 struct drm_encoder;
+struct drm_panel;
+struct drm_bridge;
 struct device_node;

 #ifdef CONFIG_OF
@@ -23,6 +25,10 @@ extern int drm_of_component_probe(struct device *dev,
 extern int drm_of_encoder_active_endpoint(struct device_node *node,
  struct drm_encoder *encoder,
  struct of_endpoint *endpoint);
+extern int drm_of_find_panel_or_bridge(const struct device_node *np,
+  int port, int endpoint,
+  struct drm_panel **panel,
+  struct drm_bridge **bridge);
 #else
 static inline uint32_t drm_of_find_possible_crtcs(struct drm_device *dev,
  struct device_node *port)
@@ -52,6 +58,13 @@ static inline int drm_of_encoder_active_endpoint(struct 
device_node *node,
 {
return -EINVAL;
 }
+static inline int drm_of_find_panel_or_bridge(const struct device_node *np,
+ int port, int endpoint,
+ struct drm_panel **panel,
+ struct drm_bridge **bridge)
+{
+   return -EINVAL;
+}
 #endif

 static inline int drm_of_encoder_active_endpoint_id(struct device_node *node,
--
2.10.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 6/6] drm: omap: use common OF graph helpers

[Rob Herring]

The OMAP driver has its own OF graph helpers that are similar to the
common helpers. This commit replaces most of the calls with the common
helpers. There's still a couple of custom helpers left, but the driver
needs more extensive changes to get rid of them.

In dss_init_ports, we invert the loop, looping through the known ports
and matching them to DT nodes rather than looping thru DT nodes and
matching them to the ports.

Signed-off-by: Rob Herring 
---
v2:
- build fixes in hdmi5 and sdi

 drivers/gpu/drm/omapdrm/dss/dpi.c |   2 +-
 drivers/gpu/drm/omapdrm/dss/dsi.c |   3 +-
 drivers/gpu/drm/omapdrm/dss/dss-of.c  | 102 +-
 drivers/gpu/drm/omapdrm/dss/dss.c |  61 +---
 drivers/gpu/drm/omapdrm/dss/hdmi4.c   |   3 +-
 drivers/gpu/drm/omapdrm/dss/hdmi5.c   |   3 +-
 drivers/gpu/drm/omapdrm/dss/omapdss.h |  11 
 drivers/gpu/drm/omapdrm/dss/sdi.c |   2 +-
 drivers/gpu/drm/omapdrm/dss/venc.c|   3 +-
 9 files changed, 26 insertions(+), 164 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/dss/dpi.c 
b/drivers/gpu/drm/omapdrm/dss/dpi.c
index e75162d26ac0..e5bb494d4689 100644
--- a/drivers/gpu/drm/omapdrm/dss/dpi.c
+++ b/drivers/gpu/drm/omapdrm/dss/dpi.c
@@ -855,7 +855,7 @@ int dpi_init_port(struct platform_device *pdev, struct 
device_node *port)
if (!dpi)
return -ENOMEM;

-   ep = omapdss_of_get_next_endpoint(port, NULL);
+   ep = of_get_next_child(port, NULL);
if (!ep)
return 0;

diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c 
b/drivers/gpu/drm/omapdrm/dss/dsi.c
index f060bda31235..d63e240513f1 100644
--- a/drivers/gpu/drm/omapdrm/dss/dsi.c
+++ b/drivers/gpu/drm/omapdrm/dss/dsi.c
@@ -39,6 +39,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 

@@ -5091,7 +5092,7 @@ static int dsi_probe_of(struct platform_device *pdev)
struct device_node *ep;
struct omap_dsi_pin_config pin_cfg;

-   ep = omapdss_of_get_first_endpoint(node);
+   ep = of_graph_get_endpoint_by_regs(node, 0, 0);
if (!ep)
return 0;

diff --git a/drivers/gpu/drm/omapdrm/dss/dss-of.c 
b/drivers/gpu/drm/omapdrm/dss/dss-of.c
index dfd4e9621e3b..eb520ab45ddd 100644
--- a/drivers/gpu/drm/omapdrm/dss/dss-of.c
+++ b/drivers/gpu/drm/omapdrm/dss/dss-of.c
@@ -16,77 +16,12 @@
 #include 
 #include 
 #include 
+#include 
 #include 

 #include "omapdss.h"
 #include "dss.h"

-struct device_node *
-omapdss_of_get_next_port(const struct device_node *parent,
-struct device_node *prev)
-{
-   struct device_node *port = NULL;
-
-   if (!parent)
-   return NULL;
-
-   if (!prev) {
-   struct device_node *ports;
-   /*
-* It's the first call, we have to find a port subnode
-* within this node or within an optional 'ports' node.
-*/
-   ports = of_get_child_by_name(parent, "ports");
-   if (ports)
-   parent = ports;
-
-   port = of_get_child_by_name(parent, "port");
-
-   /* release the 'ports' node */
-   of_node_put(ports);
-   } else {
-   struct device_node *ports;
-
-   ports = of_get_parent(prev);
-   if (!ports)
-   return NULL;
-
-   do {
-   port = of_get_next_child(ports, prev);
-   if (!port) {
-   of_node_put(ports);
-   return NULL;
-   }
-   prev = port;
-   } while (of_node_cmp(port->name, "port") != 0);
-
-   of_node_put(ports);
-   }
-
-   return port;
-}
-EXPORT_SYMBOL_GPL(omapdss_of_get_next_port);
-
-struct device_node *
-omapdss_of_get_next_endpoint(const struct device_node *parent,
-struct device_node *prev)
-{
-   struct device_node *ep = NULL;
-
-   if (!parent)
-   return NULL;
-
-   do {
-   ep = of_get_next_child(parent, prev);
-   if (!ep)
-   return NULL;
-   prev = ep;
-   } while (of_node_cmp(ep->name, "endpoint") != 0);
-
-   return ep;
-}
-EXPORT_SYMBOL_GPL(omapdss_of_get_next_endpoint);
-
 struct device_node *dss_of_port_get_parent_device(struct device_node *port)
 {
struct device_node *np;
@@ -123,37 +58,6 @@ u32 dss_of_port_get_port_number(struct device_node *port)
return reg;
 }

-static struct device_node *omapdss_of_get_remote_port(const struct device_node 
*node)
-{
-   struct device_node *np;
-
-   np = of_parse_phandle(node, "remote-endpoint", 0);
-   if (!np)
-   return NULL;
-
-   np = of_get_next_parent(np);
-
-   return np;
-}
-
-struct device_node *
-omapdss_of_get_first_endpoint(const struct device_node *parent)
-{
-  

[PATCH v2 5/5] arm: dts: Remove the OF graph from DSI node for exynos4210 dts

[Hoegeun Kwon]

The OF graph is not needed because the panel is a child of dsi. So
Remove the ports node and move burst and esc clock frequency
properties to the parent (DSI node).

Signed-off-by: Hoegeun Kwon 
---
 arch/arm/boot/dts/exynos4210-trats.dts | 23 ++-
 1 file changed, 2 insertions(+), 21 deletions(-)

diff --git a/arch/arm/boot/dts/exynos4210-trats.dts 
b/arch/arm/boot/dts/exynos4210-trats.dts
index 0ca1b4d..9452bed 100644
--- a/arch/arm/boot/dts/exynos4210-trats.dts
+++ b/arch/arm/boot/dts/exynos4210-trats.dts
@@ -197,24 +197,11 @@
 _0 {
vddcore-supply = <_reg>;
vddio-supply = <_reg>;
+   samsung,burst-clock-frequency = <5>;
+   samsung,esc-clock-frequency = <2000>;
samsung,pll-clock-frequency = <2400>;
status = "okay";
 
-   ports {
-   #address-cells = <1>;
-   #size-cells = <0>;
-
-   port@1 {
-   reg = <1>;
-
-   dsi_out: endpoint {
-   remote-endpoint = <_in>;
-   samsung,burst-clock-frequency = <5>;
-   samsung,esc-clock-frequency = <2000>;
-   };
-   };
-   };
-
panel@0 {
reg = <0>;
compatible = "samsung,s6e8aa0";
@@ -242,12 +229,6 @@
vsync-len = <2>;
};
};
-
-   port {
-   dsi_in: endpoint {
-   remote-endpoint = <_out>;
-   };
-   };
};
 };
 
-- 
1.9.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 1/5] drm/exynos: dsi: Fix the parse_dt function

[Hoegeun Kwon]

The dsi + panel is a parental relationship, so OF grpah is not needed.
Therefore, the current dsi_parse_dt function will throw an error,
because there is no linked OF graph for case such as fimd + dsi +
panel. So this patch parse the Pll, burst and esc clock frequency
properties in dsi_parse_dt and modified to create a bridge_node only
if there is an OF graph associated with dsi.
So I think the ABI breakage is needed.

Signed-off-by: Hoegeun Kwon 
---
 drivers/gpu/drm/exynos/exynos_drm_dsi.c | 32 
 1 file changed, 8 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index e07cb1f..214d486 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -1652,39 +1652,23 @@ static int exynos_dsi_parse_dt(struct exynos_dsi *dsi)
if (ret < 0)
return ret;
 
-   ep = of_graph_get_endpoint_by_regs(node, DSI_PORT_OUT, 0);
-   if (!ep) {
-   dev_err(dev, "no output port with endpoint specified\n");
-   return -EINVAL;
-   }
-
-   ret = exynos_dsi_of_read_u32(ep, "samsung,burst-clock-frequency",
+   ret = exynos_dsi_of_read_u32(node, "samsung,burst-clock-frequency",
 >burst_clk_rate);
if (ret < 0)
-   goto end;
+   return ret;
 
-   ret = exynos_dsi_of_read_u32(ep, "samsung,esc-clock-frequency",
+   ret = exynos_dsi_of_read_u32(node, "samsung,esc-clock-frequency",
 >esc_clk_rate);
if (ret < 0)
-   goto end;
-
-   of_node_put(ep);
+   return ret;
 
ep = of_graph_get_next_endpoint(node, NULL);
-   if (!ep) {
-   ret = -EINVAL;
-   goto end;
-   }
-
-   dsi->bridge_node = of_graph_get_remote_port_parent(ep);
-   if (!dsi->bridge_node) {
-   ret = -EINVAL;
-   goto end;
+   if (ep) {
+   dsi->bridge_node = of_graph_get_remote_port_parent(ep);
+   of_node_put(ep);
}
-end:
-   of_node_put(ep);
 
-   return ret;
+   return 0;
 }
 
 static int exynos_dsi_bind(struct device *dev, struct device *master,
-- 
1.9.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 2/5] arm64: dts: exynos: Remove the OF graph from DSI node for exynos5433 dts

[Hoegeun Kwon]

The OF graph is not needed because the panel is a child of dsi. So
Remove the ports node and move burst and esc clock frequency
properties to the parent (DSI node).

Signed-off-by: Hoegeun Kwon 
---
 arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi | 16 ++--
 1 file changed, 2 insertions(+), 14 deletions(-)

diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi 
b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
index 6ce93a3..77ba238 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
@@ -298,23 +298,11 @@
status = "okay";
vddcore-supply = <_reg>;
vddio-supply = <_reg>;
+   samsung,burst-clock-frequency = <51200>;
+   samsung,esc-clock-frequency = <1600>;
samsung,pll-clock-frequency = <2400>;
pinctrl-names = "default";
pinctrl-0 = <_irq>;
-
-   ports {
-   #address-cells = <1>;
-   #size-cells = <0>;
-
-   port@1 {
-   reg = <1>;
-
-   dsi_out: endpoint {
-   samsung,burst-clock-frequency = <51200>;
-   samsung,esc-clock-frequency = <1600>;
-   };
-   };
-   };
 };
 
  {
-- 
1.9.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 0/5] Fix the parse_dt of exynos dsi and remove the OF graph

[Hoegeun Kwon]

Hi,

The dsi + panel is a parental relationship, so OF grpah is not needed.
Therefore, the current dsi_parse_dt function will throw an error,
because there is no linked OF graph for case such as fimd + dsi +
panel.

So the 1/5 patch parse the Pll, burst and esc clock frequency
properties in dsi_parse_dt and modified to create a bridge_node only
if there is an OF graph associated with dsi.

Also fixed the dts, which depend on the 1/5 patch. So removed the
ports node and move burst and esc clock frequency properties to the
parent (DSI node).

Changes for V2:
- Added the clear explanation for commit. (1/5 patch)
- Fixed it to the same subject as the actual work. (2/5 ~ 5/5 patches)

Best Regards,
Hoegeun

Hoegeun Kwon (5):
  drm/exynos: dsi: Fix the parse_dt function
  arm64: dts: exynos: Remove the OF graph from DSI node for exynos5433
dts
  arm: dts: Remove the OF graph from DSI node for exynos3250 dts
  arm: dts: Remove the OF graph from DSI node for exynos4412 dts
  arm: dts: Remove the OF graph from DSI node for exynos4210 dts

 arch/arm/boot/dts/exynos3250-rinato.dts| 23 ++--
 arch/arm/boot/dts/exynos4210-trats.dts | 23 ++--
 arch/arm/boot/dts/exynos4412-trats2.dts| 23 ++--
 .../boot/dts/exynos/exynos5433-tm2-common.dtsi | 16 ++-
 drivers/gpu/drm/exynos/exynos_drm_dsi.c| 32 ++
 5 files changed, 16 insertions(+), 101 deletions(-)

-- 
1.9.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 3/5] drm: convert drivers to use of_graph_get_remote_node

[Eric Anholt]

Rob Herring  writes:

> Convert drivers to use the new of_graph_get_remote_node() helper
> instead of parsing the endpoint node and then getting the remote device
> node. Now drivers can just specify the device node and which
> port/endpoint and get back the connected remote device node. The details
> of the graph binding are nicely abstracted into the core OF graph code.
>
> This changes some error messages to debug messages (in the graph core).
> Graph connections are often "no connects" depending on the particular
> board, so we want to avoid spurious messages. Plus the kernel is not a
> DT validator.

For vc4,

Tested-by: Eric Anholt 

Thanks for making this easier.


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 4/5] arm: dts: Remove the OF graph from DSI node for exynos4412 dts

[Hoegeun Kwon]

The OF graph is not needed because the panel is a child of dsi. So
Remove the ports node and move burst and esc clock frequency
properties to the parent (DSI node).

Signed-off-by: Hoegeun Kwon 
---
 arch/arm/boot/dts/exynos4412-trats2.dts | 23 ++-
 1 file changed, 2 insertions(+), 21 deletions(-)

diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts 
b/arch/arm/boot/dts/exynos4412-trats2.dts
index 41ecd6d..86ce5e5 100644
--- a/arch/arm/boot/dts/exynos4412-trats2.dts
+++ b/arch/arm/boot/dts/exynos4412-trats2.dts
@@ -385,24 +385,11 @@
 _0 {
vddcore-supply = <_reg>;
vddio-supply = <_reg>;
+   samsung,burst-clock-frequency = <5>;
+   samsung,esc-clock-frequency = <2000>;
samsung,pll-clock-frequency = <2400>;
status = "okay";
 
-   ports {
-   #address-cells = <1>;
-   #size-cells = <0>;
-
-   port@1 {
-   reg = <1>;
-
-   dsi_out: endpoint {
-   remote-endpoint = <_in>;
-   samsung,burst-clock-frequency = <5>;
-   samsung,esc-clock-frequency = <2000>;
-   };
-   };
-   };
-
panel@0 {
compatible = "samsung,s6e8aa0";
reg = <0>;
@@ -430,12 +417,6 @@
vsync-len = <2>;
};
};
-
-   port {
-   dsi_in: endpoint {
-   remote-endpoint = <_out>;
-   };
-   };
};
 };
 
-- 
1.9.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v8 2/3] drm/panel: Add support for S6E3HA2 panel driver on TM2 board

[Andi Shyti]

Hi,

just for my knowledge and all those working on the tm2(e)
devices, is this patch going in or not?

If not, Thierry, could you please say what Hoegeun needs to do in
order to get this in?

Thanks,
Andi

On Wed, Jan 11, 2017 at 03:33:58PM +0900, Hoegeun Kwon wrote:
> This patch add support for MIPI-DSI based S6E3HA2 AMOLED panel
> driver. This panel has 1440x2560 resolution in 5.7-inch physical
> panel in the TM2 device.
> 
> Signed-off-by: Donghwa Lee 
> Signed-off-by: Hyungwon Hwang 
> Signed-off-by: Hoegeun Kwon 
> Tested-by: Chanwoo Choi 
> Reviewed-by: Andrzej Hajda 
> ---
>  drivers/gpu/drm/panel/Kconfig |   6 +
>  drivers/gpu/drm/panel/Makefile|   1 +
>  drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c | 754 
> ++
>  3 files changed, 761 insertions(+)
>  create mode 100644 drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
> 
> diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
> index 62aba97..d913c83 100644
> --- a/drivers/gpu/drm/panel/Kconfig
> +++ b/drivers/gpu/drm/panel/Kconfig
> @@ -52,6 +52,12 @@ config DRM_PANEL_PANASONIC_VVX10F034N00
> WUXGA (1920x1200) Novatek NT1397-based DSI panel as found in some
> Xperia Z2 tablets
>  
> +config DRM_PANEL_SAMSUNG_S6E3HA2
> + tristate "Samsung S6E3HA2 DSI video mode panel"
> + depends on OF
> + depends on DRM_MIPI_DSI
> + select VIDEOMODE_HELPERS
> +
>  config DRM_PANEL_SAMSUNG_S6E8AA0
>   tristate "Samsung S6E8AA0 DSI video mode panel"
>   depends on OF
> diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
> index a5c7ec0..1d483b0 100644
> --- a/drivers/gpu/drm/panel/Makefile
> +++ b/drivers/gpu/drm/panel/Makefile
> @@ -3,6 +3,7 @@ obj-$(CONFIG_DRM_PANEL_JDI_LT070ME05000) += 
> panel-jdi-lt070me05000.o
>  obj-$(CONFIG_DRM_PANEL_LG_LG4573) += panel-lg-lg4573.o
>  obj-$(CONFIG_DRM_PANEL_PANASONIC_VVX10F034N00) += 
> panel-panasonic-vvx10f034n00.o
>  obj-$(CONFIG_DRM_PANEL_SAMSUNG_LD9040) += panel-samsung-ld9040.o
> +obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E3HA2) += panel-samsung-s6e3ha2.o
>  obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E8AA0) += panel-samsung-s6e8aa0.o
>  obj-$(CONFIG_DRM_PANEL_SHARP_LQ101R1SX01) += panel-sharp-lq101r1sx01.o
>  obj-$(CONFIG_DRM_PANEL_SHARP_LS043T1LE01) += panel-sharp-ls043t1le01.o
> diff --git a/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c 
> b/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
> new file mode 100644
> index 000..0b9c6f4
> --- /dev/null
> +++ b/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
> @@ -0,0 +1,754 @@
> +/*
> + * MIPI-DSI based s6e3ha2 AMOLED 5.7 inch panel driver.
> + *
> + * Copyright (c) 2016 Samsung Electronics Co., Ltd.
> + * Donghwa Lee 
> + * Hyungwon Hwang 
> + * Hoegeun Kwon 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define S6E3HA2_MIN_BRIGHTNESS   0
> +#define S6E3HA2_MAX_BRIGHTNESS   100
> +#define S6E3HA2_DEFAULT_BRIGHTNESS   80
> +
> +#define S6E3HA2_NUM_GAMMA_STEPS  46
> +#define S6E3HA2_GAMMA_CMD_CNT35
> +#define S6E3HA2_VINT_STATUS_MAX  10
> +
> +static const u8 gamma_tbl[S6E3HA2_NUM_GAMMA_STEPS][S6E3HA2_GAMMA_CMD_CNT] = {
> + { 0x00, 0xb8, 0x00, 0xc3, 0x00, 0xb1, 0x89, 0x87, 0x87, 0x82, 0x83,
> +   0x85, 0x88, 0x8b, 0x8b, 0x84, 0x88, 0x82, 0x82, 0x89, 0x86, 0x8c,
> +   0x94, 0x84, 0xb1, 0xaf, 0x8e, 0xcf, 0xad, 0xc9, 0x00, 0x00, 0x00,
> +   0x00, 0x00 },
> + { 0x00, 0xb8, 0x00, 0xc3, 0x00, 0xb1, 0x89, 0x87, 0x87, 0x84, 0x84,
> +   0x85, 0x87, 0x8b, 0x8a, 0x84, 0x88, 0x82, 0x82, 0x89, 0x86, 0x8a,
> +   0x93, 0x84, 0xb0, 0xae, 0x8e, 0xc9, 0xa8, 0xc5, 0x00, 0x00, 0x00,
> +   0x00, 0x00 },
> + { 0x00, 0xb8, 0x00, 0xc3, 0x00, 0xb1, 0x89, 0x87, 0x87, 0x83, 0x83,
> +   0x85, 0x86, 0x8a, 0x8a, 0x84, 0x88, 0x81, 0x84, 0x8a, 0x88, 0x8a,
> +   0x91, 0x84, 0xb1, 0xae, 0x8b, 0xd5, 0xb2, 0xcc, 0x00, 0x00, 0x00,
> +   0x00, 0x00 },
> + { 0x00, 0xb8, 0x00, 0xc3, 0x00, 0xb1, 0x89, 0x87, 0x87, 0x83, 0x83,
> +   0x85, 0x86, 0x8a, 0x8a, 0x84, 0x87, 0x81, 0x84, 0x8a, 0x87, 0x8a,
> +   0x91, 0x85, 0xae, 0xac, 0x8a, 0xc3, 0xa3, 0xc0, 0x00, 0x00, 0x00,
> +   0x00, 0x00 },
> + { 0x00, 0xb8, 0x00, 0xc3, 0x00, 0xb1, 0x88, 0x86, 0x87, 0x85, 0x85,
> +   0x86, 0x85, 0x88, 0x89, 0x84, 0x89, 0x82, 0x84, 0x87, 0x85, 0x8b,
> +   0x91, 0x88, 0xad, 0xab, 0x8a, 0xb7, 0x9b, 0xb6, 0x00, 0x00, 0x00,
> +   0x00, 0x00 },
> + { 0x00, 0xb8, 0x00, 0xc3, 0x00, 0xb1, 0x89, 0x87, 0x87, 0x83, 0x83,
> +   0x85, 0x86, 

Re: [PATCH v3 7/8] drm: Connector helper function to release resources

[Lankhorst, Maarten]

Dhinakaran Pandiyan schreef op wo 08-02-2017 om 22:38 [-0800]:
> Having a ->atomic_release callback is useful to release shared
> resources
> that get allocated in compute_config(). This function is expected to
> be
> called in the atomic_check() phase before new resources are acquired.
> 
> v2: Moved the caller hunk to this patch (Daniel)
> 
> Suggested-by: Daniel Vetter 
> Signed-off-by: Dhinakaran Pandiyan 
> ---
>  drivers/gpu/drm/drm_atomic_helper.c  | 19 +++
>  include/drm/drm_modeset_helper_vtables.h | 13 +
>  2 files changed, 32 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 8795088..92bd741 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -576,6 +576,25 @@ drm_atomic_helper_check_modeset(struct
> drm_device *dev,
>   }
>   }
>  
> + for_each_connector_in_state(state, connector,
> connector_state, i) {
> + const struct drm_connector_helper_funcs *conn_funcs;
> + struct drm_crtc_state *crtc_state;
> +
> + conn_funcs = connector->helper_private;
> + if (!conn_funcs->atomic_release)
> + continue;
> +
> + if (!connector->state->crtc)
> + continue;
> +
> + crtc_state =
> drm_atomic_get_existing_crtc_state(state, connector->state->crtc);
> +
> + if (crtc_state->connectors_changed ||
> + crtc_state->mode_changed ||
> + (crtc_state->active_changed && !crtc_state-
> >active))
> + conn_funcs->atomic_release(connector,
> connector_state);
> + }

Could we deal with the VCPI state separately in intel_modeset_checks,
like we do with dpll?

Maybe implementing the relevant VCPI state could be done as an atomic
helper function too, so other atomic drivers can just plug it in.

Not sure how doable this is, but if it's not too hard, then it's
probably cleaner :)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 5/8] drm/dp: Introduce MST topology state to track available link bandwidth

[Dhinakaran Pandiyan]

Link bandwidth is shared between multiple display streams in DP MST
configurations. The DP MST topology manager structure maintains the
shared link bandwidth for a primary link directly connected to the GPU. For
atomic modesetting drivers, checking if there is sufficient link bandwidth
for a mode needs to be done during the atomic_check phase to avoid failed
modesets. Let's encapsulate the available link bw information in a
private state structure so that bw can be allocated and released atomically
for each of the ports sharing the primary link.

v2: Included kernel doc, moved state initialization and switched to
kmemdup() for allocation (Daniel)

Signed-off-by: Dhinakaran Pandiyan 
---
 drivers/gpu/drm/drm_dp_mst_topology.c | 71 +++
 include/drm/drm_dp_mst_helper.h   | 20 ++
 2 files changed, 91 insertions(+)

diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 37482b7..a891c36 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -2936,6 +2936,65 @@ static void drm_dp_destroy_connector_work(struct 
work_struct *work)
(*mgr->cbs->hotplug)(mgr);
 }
 
+void *drm_dp_mst_duplicate_state(struct drm_atomic_state *state, void *obj)
+{
+   struct drm_dp_mst_topology_mgr *mgr = obj;
+   struct drm_dp_mst_topology_state *new_mst_state;
+
+   if (WARN_ON(!mgr->state))
+   return NULL;
+
+   new_mst_state = kmemdup(mgr->state, sizeof(*new_mst_state), GFP_KERNEL);
+   if (new_mst_state)
+   new_mst_state->state = state;
+   return new_mst_state;
+}
+
+void drm_dp_mst_swap_state(void *obj, void **obj_state_ptr)
+{
+   struct drm_dp_mst_topology_mgr *mgr = obj;
+   struct drm_dp_mst_topology_state **topology_state_ptr;
+
+   topology_state_ptr = (struct drm_dp_mst_topology_state **)obj_state_ptr;
+
+   mgr->state->state = (*topology_state_ptr)->state;
+   swap(*topology_state_ptr, mgr->state);
+   mgr->state->state = NULL;
+}
+
+void drm_dp_mst_destroy_state(void *obj_state)
+{
+   kfree(obj_state);
+}
+
+static const struct drm_private_state_funcs mst_state_funcs = {
+   .duplicate_state = drm_dp_mst_duplicate_state,
+   .swap_state = drm_dp_mst_swap_state,
+   .destroy_state = drm_dp_mst_destroy_state,
+};
+
+/**
+ * drm_atomic_get_mst_topology_state: get MST topology state
+ *
+ * @state: global atomic state
+ * @mgr: MST topology manager, also the private object in this case
+ *
+ * This function wraps drm_atomic_get_priv_obj_state() passing in the MST 
atomic
+ * state vtable so that the private object state returned is that of a MST
+ * topology object.
+ *
+ * RETURNS:
+ *
+ * The MST topology state or error pointer.
+ */
+struct drm_dp_mst_topology_state *drm_atomic_get_mst_topology_state(struct 
drm_atomic_state *state,
+   struct 
drm_dp_mst_topology_mgr *mgr)
+{
+   return drm_atomic_get_private_obj_state(state, mgr,
+   _state_funcs);
+}
+EXPORT_SYMBOL(drm_atomic_get_mst_topology_state);
+
 /**
  * drm_dp_mst_topology_mgr_init - initialise a topology manager
  * @mgr: manager struct to initialise
@@ -2980,6 +3039,15 @@ int drm_dp_mst_topology_mgr_init(struct 
drm_dp_mst_topology_mgr *mgr,
if (test_calc_pbn_mode() < 0)
DRM_ERROR("MST PBN self-test failed\n");
 
+   mgr->state = kzalloc(sizeof(*mgr->state), GFP_KERNEL);
+   if (mgr->state == NULL)
+   return -ENOMEM;
+   mgr->state->mgr = mgr;
+
+   /* max. time slots - one slot for MTP header */
+   mgr->state->avail_slots = 63;
+   mgr->funcs = _state_funcs;
+
return 0;
 }
 EXPORT_SYMBOL(drm_dp_mst_topology_mgr_init);
@@ -3000,6 +3068,9 @@ void drm_dp_mst_topology_mgr_destroy(struct 
drm_dp_mst_topology_mgr *mgr)
mutex_unlock(>payload_lock);
mgr->dev = NULL;
mgr->aux = NULL;
+   kfree(mgr->state);
+   mgr->state = NULL;
+   mgr->funcs = NULL;
 }
 EXPORT_SYMBOL(drm_dp_mst_topology_mgr_destroy);
 
diff --git a/include/drm/drm_dp_mst_helper.h b/include/drm/drm_dp_mst_helper.h
index 5b02476..0b371df 100644
--- a/include/drm/drm_dp_mst_helper.h
+++ b/include/drm/drm_dp_mst_helper.h
@@ -24,6 +24,7 @@
 
 #include 
 #include 
+#include 
 
 struct drm_dp_mst_branch;
 
@@ -403,6 +404,12 @@ struct drm_dp_payload {
int vcpi;
 };
 
+struct drm_dp_mst_topology_state {
+   int avail_slots;
+   struct drm_atomic_state *state;
+   struct drm_dp_mst_topology_mgr *mgr;
+};
+
 /**
  * struct drm_dp_mst_topology_mgr - DisplayPort MST manager
  *
@@ -481,6 +488,16 @@ struct drm_dp_mst_topology_mgr {
int pbn_div;
 
/**
+* @state: State information for topology manager
+*/
+   struct drm_dp_mst_topology_state *state;
+
+   /**
+   

Re: [Intel-gfx] [PATCH v3 7/8] drm: Connector helper function to release resources

[Pandiyan, Dhinakaran]

On Thu, 2017-02-09 at 09:01 +, Lankhorst, Maarten wrote:
> Dhinakaran Pandiyan schreef op wo 08-02-2017 om 22:38 [-0800]:
> > Having a ->atomic_release callback is useful to release shared
> > resources
> > that get allocated in compute_config(). This function is expected to
> > be
> > called in the atomic_check() phase before new resources are acquired.
> > 
> > v2: Moved the caller hunk to this patch (Daniel)
> > 
> > Suggested-by: Daniel Vetter 
> > Signed-off-by: Dhinakaran Pandiyan 
> > ---
> >  drivers/gpu/drm/drm_atomic_helper.c  | 19 +++
> >  include/drm/drm_modeset_helper_vtables.h | 13 +
> >  2 files changed, 32 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> > b/drivers/gpu/drm/drm_atomic_helper.c
> > index 8795088..92bd741 100644
> > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > @@ -576,6 +576,25 @@ drm_atomic_helper_check_modeset(struct
> > drm_device *dev,
> > }
> > }
> >  
> > +   for_each_connector_in_state(state, connector,
> > connector_state, i) {
> > +   const struct drm_connector_helper_funcs *conn_funcs;
> > +   struct drm_crtc_state *crtc_state;
> > +
> > +   conn_funcs = connector->helper_private;
> > +   if (!conn_funcs->atomic_release)
> > +   continue;
> > +
> > +   if (!connector->state->crtc)
> > +   continue;
> > +
> > +   crtc_state =
> > drm_atomic_get_existing_crtc_state(state, connector->state->crtc);
> > +
> > +   if (crtc_state->connectors_changed ||
> > +   crtc_state->mode_changed ||
> > +   (crtc_state->active_changed && !crtc_state-
> > >active))
> > +   conn_funcs->atomic_release(connector,
> > connector_state);
> > +   }
> 
> Could we deal with the VCPI state separately in intel_modeset_checks,
> like we do with dpll?

We'd want to release the VCPI slots before they are acquired in
->compute_config(). intel_modeset_checks() will be too late to release
them. Are you suggesting both acquiring and releasing slots should be
done in intel_modeset_checks()?


> 
> Maybe implementing the relevant VCPI state could be done as an atomic
> helper function too, so other atomic drivers can just plug it in.
> 
The idea was to reduce boilerplate in the drivers and use the
private_obj state for different object types.


> Not sure how doable this is, but if it's not too hard, then it's
> probably cleaner :)
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 5/6] drm: convert drivers to use drm_of_find_panel_or_bridge

[Rob Herring]

Similar to the previous commit, convert drivers open coding OF graph
parsing to use drm_of_find_panel_or_bridge instead.

This changes some error messages to debug messages (in the graph core).
Graph connections are often "no connects" depending on the particular
board, so we want to avoid spurious messages. Plus the kernel is not a
DT validator.

Signed-off-by: Rob Herring 
---
v2:
- fix wrong node ptr in imx-ldb
- build fixes in kirin and imx drivers

 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c | 64 -
 drivers/gpu/drm/bridge/nxp-ptn3460.c | 16 ++---
 drivers/gpu/drm/bridge/parade-ps8622.c   | 16 ++---
 drivers/gpu/drm/bridge/tc358767.c| 27 +--
 drivers/gpu/drm/exynos/exynos_dp.c   | 35 -
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c| 49 -
 drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c | 27 ++-
 drivers/gpu/drm/imx/imx-ldb.c| 27 ++-
 drivers/gpu/drm/imx/parallel-display.c   | 36 ++
 drivers/gpu/drm/mediatek/mtk_dsi.c   | 23 ++
 drivers/gpu/drm/mxsfb/mxsfb_out.c| 36 ++
 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c  | 26 ++-
 drivers/gpu/drm/sun4i/sun4i_rgb.c| 13 ++--
 drivers/gpu/drm/sun4i/sun4i_tcon.c   | 90 ++--
 14 files changed, 88 insertions(+), 397 deletions(-)

diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
index 6119b5085501..4614048a4935 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
@@ -22,7 +22,7 @@
 #include 

 #include 
-#include 
+#include 

 #include "atmel_hlcdc_dc.h"

@@ -152,29 +152,11 @@ static const struct drm_connector_funcs 
atmel_hlcdc_panel_connector_funcs = {
.atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
 };

-static int atmel_hlcdc_check_endpoint(struct drm_device *dev,
- const struct of_endpoint *ep)
-{
-   struct device_node *np;
-   void *obj;
-
-   np = of_graph_get_remote_port_parent(ep->local_node);
-
-   obj = of_drm_find_panel(np);
-   if (!obj)
-   obj = of_drm_find_bridge(np);
-
-   of_node_put(np);
-
-   return obj ? 0 : -EPROBE_DEFER;
-}
-
 static int atmel_hlcdc_attach_endpoint(struct drm_device *dev,
-  const struct of_endpoint *ep)
+  const struct device_node *np)
 {
struct atmel_hlcdc_dc *dc = dev->dev_private;
struct atmel_hlcdc_rgb_output *output;
-   struct device_node *np;
struct drm_panel *panel;
struct drm_bridge *bridge;
int ret;
@@ -195,13 +177,11 @@ static int atmel_hlcdc_attach_endpoint(struct drm_device 
*dev,

output->encoder.possible_crtcs = 0x1;

-   np = of_graph_get_remote_port_parent(ep->local_node);
-
-   ret = -EPROBE_DEFER;
+   ret = drm_of_find_panel_or_bridge(np, 0, 0, , );
+   if (ret)
+   return ret;

-   panel = of_drm_find_panel(np);
if (panel) {
-   of_node_put(np);
output->connector.dpms = DRM_MODE_DPMS_OFF;
output->connector.polled = DRM_CONNECTOR_POLL_CONNECT;
drm_connector_helper_add(>connector,
@@ -226,9 +206,6 @@ static int atmel_hlcdc_attach_endpoint(struct drm_device 
*dev,
return 0;
}

-   bridge = of_drm_find_bridge(np);
-   of_node_put(np);
-
if (bridge) {
output->encoder.bridge = bridge;
bridge->encoder = >encoder;
@@ -245,31 +222,14 @@ static int atmel_hlcdc_attach_endpoint(struct drm_device 
*dev,

 int atmel_hlcdc_create_outputs(struct drm_device *dev)
 {
-   struct device_node *ep_np = NULL;
-   struct of_endpoint ep;
+   struct device_node *remote;
int ret;

-   for_each_endpoint_of_node(dev->dev->of_node, ep_np) {
-   ret = of_graph_parse_endpoint(ep_np, );
-   if (!ret)
-   ret = atmel_hlcdc_check_endpoint(dev, );
-
-   if (ret) {
-   of_node_put(ep_np);
-   return ret;
-   }
-   }
-
-   for_each_endpoint_of_node(dev->dev->of_node, ep_np) {
-   ret = of_graph_parse_endpoint(ep_np, );
-   if (!ret)
-   ret = atmel_hlcdc_attach_endpoint(dev, );
-
-   if (ret) {
-   of_node_put(ep_np);
-   return ret;
-   }
-   }
+   remote = of_graph_get_remote_node(dev->dev->of_node, 0, 0);
+   if (!remote)
+   return -ENODEV;

-   return 0;
+   ret = atmel_hlcdc_attach_endpoint(dev, remote);
+   of_node_put(remote);
+   return ret;
 }
diff --git 

[PATCH v3 2/8] drm/dp: Kill unused MST vcpi slot availability tracking

[Dhinakaran Pandiyan]

The avail_slots member in the MST topology manager is never updated to
reflect the available vcpi slots. The check is effectively against
total slots, 63. So, let's make that check obvious and remove
avail_slots. While at it, make debug messages more descriptive.

Signed-off-by: Dhinakaran Pandiyan 
---
 drivers/gpu/drm/drm_dp_mst_topology.c | 15 ---
 include/drm/drm_dp_mst_helper.h   |  5 -
 2 files changed, 8 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
b/drivers/gpu/drm/drm_dp_mst_topology.c
index cf4b866..d9edd84 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -2042,9 +2042,6 @@ int drm_dp_mst_topology_mgr_set_mst(struct 
drm_dp_mst_topology_mgr *mgr, bool ms
goto out_unlock;
}
 
-   /* max. time slots - one slot for MTP header */
-   mgr->avail_slots = 63;
-
/* add initial branch device at LCT 1 */
mstb = drm_dp_add_mst_branch_device(1, NULL);
if (mstb == NULL) {
@@ -2474,7 +2471,8 @@ int drm_dp_find_vcpi_slots(struct drm_dp_mst_topology_mgr 
*mgr,
 
num_slots = DIV_ROUND_UP(pbn, mgr->pbn_div);
 
-   if (num_slots > mgr->avail_slots)
+   /* max. time slots - one slot for MTP header */
+   if (num_slots > 63)
return -ENOSPC;
return num_slots;
 }
@@ -2488,7 +2486,8 @@ static int drm_dp_init_vcpi(struct 
drm_dp_mst_topology_mgr *mgr,
 
num_slots = DIV_ROUND_UP(pbn, mgr->pbn_div);
 
-   if (num_slots > mgr->avail_slots)
+   /* max. time slots - one slot for MTP header */
+   if (num_slots > 63)
return -ENOSPC;
 
vcpi->pbn = pbn;
@@ -2527,10 +2526,12 @@ bool drm_dp_mst_allocate_vcpi(struct 
drm_dp_mst_topology_mgr *mgr, struct drm_dp
 
ret = drm_dp_init_vcpi(mgr, >vcpi, pbn);
if (ret) {
-   DRM_DEBUG_KMS("failed to init vcpi %d %d %d\n", 
DIV_ROUND_UP(pbn, mgr->pbn_div), mgr->avail_slots, ret);
+   DRM_DEBUG_KMS("failed to init vcpi slots=%d max=63 ret=%d\n",
+   DIV_ROUND_UP(pbn, mgr->pbn_div), ret);
goto out;
}
-   DRM_DEBUG_KMS("initing vcpi for %d %d\n", pbn, port->vcpi.num_slots);
+   DRM_DEBUG_KMS("initing vcpi for pbn=%d slots=%d\n",
+   pbn, port->vcpi.num_slots);
*slots = port->vcpi.num_slots;
 
drm_dp_put_port(port);
diff --git a/include/drm/drm_dp_mst_helper.h b/include/drm/drm_dp_mst_helper.h
index 1a7e0f4..d836511 100644
--- a/include/drm/drm_dp_mst_helper.h
+++ b/include/drm/drm_dp_mst_helper.h
@@ -481,11 +481,6 @@ struct drm_dp_mst_topology_mgr {
int pbn_div;
 
/**
-* @avail_slots: Still available slots that can be allocated.
-*/
-   int avail_slots;
-
-   /**
 * @qlock: protects @tx_msg_downq, the _dp_mst_branch.txslost and
 * _dp_sideband_msg_tx.state once they are queued
 */
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 0/6] DRM OF graph clean-up

[Rob Herring]

I've been unhappy with the OF graph API for some time and decided to
do something about it. The problem is drivers have to do too much of the
graph parsing and walking themselves. This has led to the same pattern
duplicated over and over. This series adds 2 new helpers and adapts DRM
drivers to use them. It only adds one new graph helper, but reduces the
use of the others which I hope to remove at some point. But we're not
there yet.

I plan to apply patch #1 to the DT tree for v4.11. The rest I will respin
for 4.12 after -rc1 to avoid any cross tree dependencies.

The build coverage should be a bit better than v1. Testing appreciated. A
git branch is here[1].

Rob

[1] git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git 
of-graph-helpers

Rob Herring (6):
  of: introduce of_graph_get_remote_node
  drm: make of_drm_find_panel also depend on CONFIG_DRM_PANEL
  drm: of: introduce drm_of_find_panel_or_bridge
  drm: convert drivers to use of_graph_get_remote_node
  drm: convert drivers to use drm_of_find_panel_or_bridge
  drm: omap: use common OF graph helpers

 drivers/gpu/drm/arm/hdlcd_drv.c  |  22 +
 drivers/gpu/drm/arm/malidp_drv.c |  28 +--
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c |  64 +++---
 drivers/gpu/drm/bridge/adv7511/adv7533.c |  12 +--
 drivers/gpu/drm/bridge/dumb-vga-dac.c|  15 +---
 drivers/gpu/drm/bridge/nxp-ptn3460.c |  16 +---
 drivers/gpu/drm/bridge/parade-ps8622.c   |  16 +---
 drivers/gpu/drm/bridge/tc358767.c|  27 +-
 drivers/gpu/drm/bridge/ti-tfp410.c   |  15 ++--
 drivers/gpu/drm/drm_of.c |  52 
 drivers/gpu/drm/exynos/exynos_dp.c   |  35 +++-
 drivers/gpu/drm/exynos/exynos_drm_dpi.c  |  16 +---
 drivers/gpu/drm/exynos/exynos_drm_dsi.c  |  13 +--
 drivers/gpu/drm/exynos/exynos_drm_mic.c  |  27 +-
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c|  49 ---
 drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c |  27 +-
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c  |  30 +--
 drivers/gpu/drm/imx/imx-ldb.c|  27 ++
 drivers/gpu/drm/imx/parallel-display.c   |  36 +---
 drivers/gpu/drm/mediatek/mtk_dpi.c   |  12 +--
 drivers/gpu/drm/mediatek/mtk_dsi.c   |  23 ++---
 drivers/gpu/drm/mediatek/mtk_hdmi.c  |  26 +-
 drivers/gpu/drm/meson/meson_venc_cvbs.c  |  19 +
 drivers/gpu/drm/msm/dsi/dsi_host.c   |   3 +-
 drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c  |  28 +--
 drivers/gpu/drm/mxsfb/mxsfb_out.c|  36 ++--
 drivers/gpu/drm/omapdrm/dss/dpi.c|   2 +-
 drivers/gpu/drm/omapdrm/dss/dsi.c|   3 +-
 drivers/gpu/drm/omapdrm/dss/dss-of.c | 102 +--
 drivers/gpu/drm/omapdrm/dss/dss.c|  61 +++---
 drivers/gpu/drm/omapdrm/dss/hdmi4.c  |   3 +-
 drivers/gpu/drm/omapdrm/dss/hdmi5.c  |   3 +-
 drivers/gpu/drm/omapdrm/dss/omapdss.h|  11 ---
 drivers/gpu/drm/omapdrm/dss/sdi.c|   2 +-
 drivers/gpu/drm/omapdrm/dss/venc.c   |   3 +-
 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c  |  26 +-
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c  |  18 ++--
 drivers/gpu/drm/sun4i/sun4i_rgb.c|  13 ++-
 drivers/gpu/drm/sun4i/sun4i_tcon.c   |  90 ++--
 drivers/gpu/drm/tilcdc/tilcdc_crtc.c |  12 +--
 drivers/gpu/drm/tilcdc/tilcdc_external.c |  68 ++-
 drivers/gpu/drm/vc4/vc4_dpi.c|  15 +---
 drivers/of/base.c|  37 
 include/drm/drm_of.h |  13 +++
 include/drm/drm_panel.h  |   2 +-
 include/linux/of_graph.h |   8 ++
 46 files changed, 280 insertions(+), 886 deletions(-)

--
2.10.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 4/6] drm: convert drivers to use of_graph_get_remote_node

[Rob Herring]

Convert drivers to use the new of_graph_get_remote_node() helper
instead of parsing the endpoint node and then getting the remote device
node. Now drivers can just specify the device node and which
port/endpoint and get back the connected remote device node. The details
of the graph binding are nicely abstracted into the core OF graph code.

This changes some error messages to debug messages (in the graph core).
Graph connections are often "no connects" depending on the particular
board, so we want to avoid spurious messages. Plus the kernel is not a
DT validator.

Signed-off-by: Rob Herring 
Acked-by: Neil Armstrong 
Acked-by: Philipp Zabel 
Tested-by: Liviu Dudau 
Tested-by: Eric Anholt 
---
v2:
- tilcdc fix (Jyri Sarha)
- Dropped an incomplete meson change.

 drivers/gpu/drm/arm/hdlcd_drv.c | 22 ++--
 drivers/gpu/drm/arm/malidp_drv.c| 28 ++
 drivers/gpu/drm/bridge/adv7511/adv7533.c| 12 +
 drivers/gpu/drm/bridge/dumb-vga-dac.c   | 15 ++
 drivers/gpu/drm/bridge/ti-tfp410.c  | 15 ++
 drivers/gpu/drm/exynos/exynos_drm_dpi.c | 16 +-
 drivers/gpu/drm/exynos/exynos_drm_dsi.c | 13 ++---
 drivers/gpu/drm/exynos/exynos_drm_mic.c | 27 +-
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 30 +--
 drivers/gpu/drm/mediatek/mtk_dpi.c  | 12 ++---
 drivers/gpu/drm/mediatek/mtk_hdmi.c | 26 ++
 drivers/gpu/drm/meson/meson_venc_cvbs.c | 19 ++-
 drivers/gpu/drm/msm/dsi/dsi_host.c  |  3 +-
 drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c | 28 +-
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 18 +++
 drivers/gpu/drm/tilcdc/tilcdc_crtc.c| 12 +
 drivers/gpu/drm/tilcdc/tilcdc_external.c| 68 +++--
 drivers/gpu/drm/vc4/vc4_dpi.c   | 15 ++
 18 files changed, 55 insertions(+), 324 deletions(-)

diff --git a/drivers/gpu/drm/arm/hdlcd_drv.c b/drivers/gpu/drm/arm/hdlcd_drv.c
index e5f4f4a6546d..0f70f5fe9970 100644
--- a/drivers/gpu/drm/arm/hdlcd_drv.c
+++ b/drivers/gpu/drm/arm/hdlcd_drv.c
@@ -430,29 +430,13 @@ static int compare_dev(struct device *dev, void *data)

 static int hdlcd_probe(struct platform_device *pdev)
 {
-   struct device_node *port, *ep;
+   struct device_node *port;
struct component_match *match = NULL;

-   if (!pdev->dev.of_node)
-   return -ENODEV;
-
/* there is only one output port inside each device, find it */
-   ep = of_graph_get_next_endpoint(pdev->dev.of_node, NULL);
-   if (!ep)
-   return -ENODEV;
-
-   if (!of_device_is_available(ep)) {
-   of_node_put(ep);
+   port = of_graph_get_remote_node(pdev->dev.of_node, 0, 0);
+   if (!port)
return -ENODEV;
-   }
-
-   /* add the remote encoder port as component */
-   port = of_graph_get_remote_port_parent(ep);
-   of_node_put(ep);
-   if (!port || !of_device_is_available(port)) {
-   of_node_put(port);
-   return -EAGAIN;
-   }

drm_of_component_match_add(>dev, , compare_dev, port);
of_node_put(port);
diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index 32f746e31379..47b552f1337c 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -262,7 +262,6 @@ static int malidp_bind(struct device *dev)
 {
struct resource *res;
struct drm_device *drm;
-   struct device_node *ep;
struct malidp_drm *malidp;
struct malidp_hw_device *hwdev;
struct platform_device *pdev = to_platform_device(dev);
@@ -360,12 +359,7 @@ static int malidp_bind(struct device *dev)
goto init_fail;

/* Set the CRTC's port so that the encoder component can find it */
-   ep = of_graph_get_next_endpoint(dev->of_node, NULL);
-   if (!ep) {
-   ret = -EINVAL;
-   goto port_fail;
-   }
-   malidp->crtc.port = of_get_next_parent(ep);
+   malidp->crtc.port = of_graph_get_port_by_id(dev->of_node, 0);

ret = component_bind_all(dev, drm);
if (ret) {
@@ -420,7 +414,6 @@ static int malidp_bind(struct device *dev)
 bind_fail:
of_node_put(malidp->crtc.port);
malidp->crtc.port = NULL;
-port_fail:
malidp_fini(drm);
 init_fail:
drm->dev_private = NULL;
@@ -478,29 +471,16 @@ static int malidp_compare_dev(struct device *dev, void 
*data)

 static int malidp_platform_probe(struct platform_device *pdev)
 {
-   struct device_node *port, *ep;
+   struct device_node *port;
struct component_match *match = NULL;

if (!pdev->dev.of_node)
return -ENODEV;

/* there is only one output port inside each device, find it */
-   ep = 

Re: [PATCH 1/2] drm: refernce count event->completion

[Jim Rees]

Daniel Vetter wrote:

  Latest report just says that the revert isn't helping either. I suspect
  the report is a giantic conflagration of everything ever that kills
  various reporters boxes. I still believe that the patch here fixes the
  original bug, but there might be a lot more hiding.
  
  It's at least seen quite a pile of testing, so I think it's sounds, and we
  could cherry-pick it to dinf with cc: stable for 4.9+. Worst case it's not
  going to help for the other problems.

No, that's not what the latest report says. It says, "running for 2 weeks
... This is certainly way, way better than the current stock experience,
which results in my T460s entirely locking up daily." and "Less than a day
after I made that comment I got a hard lockup". So reverting the buggy
helper nonblock tracking commit took this reporter from locking up daily to
locking up once in two weeks. For everyone else, reverting the buggy commit
fixes all bugs. Also note that this most recent lockup appears to be a
different bug ("GPU HANG: ecode").

So we have a commit that is causing hard lockups and flip_done timeouts for
multiple users. Reverting this commit fixes the problem. But we did not push
the revert up for 4.9, and it looks like we're not going to push it up for
4.10 either.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 8/8] drm/dp: Track MST link bandwidth

[Dhinakaran Pandiyan]

Use the added helpers to track MST link bandwidth for atomic modesets.
Link bw is acquired in the ->atomic_check() phase when CRTCs are being
enabled with drm_atomic_find_vcpi_slots() instead of drm_find_vcpi_slots().
Similarly, link bw is released during ->atomic_check() with the connector
helper callback ->atomic_release() when CRTCs are disabled.

v2:
Squashed atomic_release() implementation and caller (Daniel)
Fixed logic for connector-crtc switching case (Daniel)
Fixed logic for suspend-resume case.

Signed-off-by: Dhinakaran Pandiyan 
---
 drivers/gpu/drm/i915/intel_dp_mst.c | 38 ++---
 1 file changed, 31 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c 
b/drivers/gpu/drm/i915/intel_dp_mst.c
index 9b9dda8..7aec0c7 100644
--- a/drivers/gpu/drm/i915/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/intel_dp_mst.c
@@ -39,9 +39,9 @@ static bool intel_dp_mst_compute_config(struct intel_encoder 
*encoder,
struct intel_dp *intel_dp = _dig_port->dp;
struct intel_connector *connector =
to_intel_connector(conn_state->connector);
-   struct drm_atomic_state *state;
+   struct drm_atomic_state *state = pipe_config->base.state;
int bpp;
-   int lane_count, slots;
+   int lane_count, slots = 0;
const struct drm_display_mode *adjusted_mode = 
_config->base.adjusted_mode;
int mst_pbn;
 
@@ -57,30 +57,53 @@ static bool intel_dp_mst_compute_config(struct 
intel_encoder *encoder,
 * seem to suggest we should do otherwise.
 */
lane_count = drm_dp_max_lane_count(intel_dp->dpcd);
-
pipe_config->lane_count = lane_count;
 
pipe_config->pipe_bpp = bpp;
pipe_config->port_clock = intel_dp_max_link_rate(intel_dp);
 
-   state = pipe_config->base.state;
-
if (drm_dp_mst_port_has_audio(_dp->mst_mgr, connector->port))
pipe_config->has_audio = true;
-   mst_pbn = drm_dp_calc_pbn_mode(adjusted_mode->crtc_clock, bpp);
 
+   mst_pbn = drm_dp_calc_pbn_mode(adjusted_mode->crtc_clock, bpp);
pipe_config->pbn = mst_pbn;
-   slots = drm_dp_find_vcpi_slots(_dp->mst_mgr, mst_pbn);
 
intel_link_compute_m_n(bpp, lane_count,
   adjusted_mode->crtc_clock,
   pipe_config->port_clock,
   _config->dp_m_n);
 
+   if (pipe_config->base.active) {
+   slots = drm_dp_atomic_find_vcpi_slots(state, _dp->mst_mgr,
+ connector->port, mst_pbn);
+   if (slots < 0) {
+   DRM_DEBUG_KMS("failed finding vcpi slots:%d\n", slots);
+   return false;
+   }
+   }
pipe_config->dp_m_n.tu = slots;
 
return true;
+}
+
+static void intel_dp_mst_atomic_release(struct drm_connector *connector,
+   struct drm_connector_state *conn_state)
+{
+   struct intel_dp_mst_encoder *intel_mst;
+   struct drm_dp_mst_topology_mgr *mgr;
+   struct drm_encoder *encoder;
+   struct intel_connector *intel_connector = to_intel_connector(connector);
+   struct drm_atomic_state *state = conn_state->state;
+   int slots;
+
+   encoder = connector->state->best_encoder;
+   intel_mst = enc_to_mst(encoder);
+   mgr = _mst->primary->dp.mst_mgr;
 
+   slots = drm_dp_atomic_release_vcpi_slots(state, mgr,
+intel_connector->port);
+   if (slots < 0)
+   DRM_DEBUG_KMS("failed releasing vcpi slots:%d\n", slots);
 }
 
 static void intel_mst_disable_dp(struct intel_encoder *encoder,
@@ -401,6 +424,7 @@ static const struct drm_connector_helper_funcs 
intel_dp_mst_connector_helper_fun
.mode_valid = intel_dp_mst_mode_valid,
.atomic_best_encoder = intel_mst_atomic_best_encoder,
.best_encoder = intel_mst_best_encoder,
+   .atomic_release = intel_dp_mst_atomic_release,
 };
 
 static void intel_dp_mst_encoder_destroy(struct drm_encoder *encoder)
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 0/8] Adding driver-private objects to atomic state

[Dhinakaran Pandiyan]

Link bandwidth is a shared resource between multiple displays in DP MST
configurations. For atomic modesetting drivers, checking if there is
sufficient link bandwidth for a mode needs to be done during the
atomic_check phase to avoid failed modesets when multiple CRTC's and
connectors are involved.

Managing shared resources like DP MST link bandwidth in the driver's
subclassed atomic_state will result in duplicating the code in each atomic
modesetting driver. But adding objects like DP MST link bandwidth to the
DRM core's drm_atomic_state would mean that an object that is not a core
modesetting object like connector, CRTC or a plane will be modified by the
helper functions for swapping and clearing state. So, this series
introduces void * type driver-private objects in drm_atomic_state and adds
helper functions that operate on these private objects. Drivers can then
implement object-specific functions to swap and clear states.
The advantage of having void * for these objects in drm_atomic_state is
that objects of different types can be managed in the same state array.

This version
1) splits and squashes patches
2) adds documentation
3) fixes vcpi slot accounting logic for suspend-resume and
connector switching

Dhinakaran Pandiyan (8):
  drm/dp: Kill total_pbn and total_slots in struct
drm_dp_mst_topology_mgr
  drm/dp: Kill unused MST vcpi slot availability tracking
  drm/dp: Split drm_dp_mst_allocate_vcpi
  drm: Add driver-private objects to atomic state
  drm/dp: Introduce MST topology state to track available link bandwidth
  drm/dp: Add DP MST helpers to atomically find and release vcpi slots
  drm: Connector helper function to release resources
  drm/dp: Track MST link bandwidth

 drivers/gpu/drm/drm_atomic.c |  68 
 drivers/gpu/drm/drm_atomic_helper.c  |  24 
 drivers/gpu/drm/drm_dp_mst_topology.c| 181 ---
 drivers/gpu/drm/i915/intel_dp_mst.c  |  42 +--
 drivers/gpu/drm/nouveau/nv50_display.c   |   3 +-
 drivers/gpu/drm/radeon/radeon_dp_mst.c   |   4 +-
 include/drm/drm_atomic.h |  91 
 include/drm/drm_dp_mst_helper.h  |  33 --
 include/drm/drm_modeset_helper_vtables.h |  13 +++
 9 files changed, 421 insertions(+), 38 deletions(-)

-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 3/5] arm: dts: Remove the OF graph from DSI node for exynos3250 dts

[Hoegeun Kwon]

The OF graph is not needed because the panel is a child of dsi. So
Remove the ports node and move burst and esc clock frequency
properties to the parent (DSI node).

Signed-off-by: Hoegeun Kwon 
---
 arch/arm/boot/dts/exynos3250-rinato.dts | 23 ++-
 1 file changed, 2 insertions(+), 21 deletions(-)

diff --git a/arch/arm/boot/dts/exynos3250-rinato.dts 
b/arch/arm/boot/dts/exynos3250-rinato.dts
index 548413e..82e676a 100644
--- a/arch/arm/boot/dts/exynos3250-rinato.dts
+++ b/arch/arm/boot/dts/exynos3250-rinato.dts
@@ -215,24 +215,11 @@
 _0 {
vddcore-supply = <_reg>;
vddio-supply = <_reg>;
+   samsung,burst-clock-frequency = <25000>;
+   samsung,esc-clock-frequency = <2000>;
samsung,pll-clock-frequency = <2400>;
status = "okay";
 
-   ports {
-   #address-cells = <1>;
-   #size-cells = <0>;
-
-   port@1 {
-   reg = <1>;
-
-   dsi_out: endpoint {
-   remote-endpoint = <_in>;
-   samsung,burst-clock-frequency = <25000>;
-   samsung,esc-clock-frequency = <2000>;
-   };
-   };
-   };
-
panel@0 {
compatible = "samsung,s6e63j0x03";
reg = <0>;
@@ -262,12 +249,6 @@
vsync-len = <2>;
};
};
-
-   port {
-   dsi_in: endpoint {
-   remote-endpoint = <_out>;
-   };
-   };
};
 };
 
-- 
1.9.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 1/6] of: introduce of_graph_get_remote_node

[Rob Herring]

The OF graph API leaves too much of the graph walking to clients when
in many cases the driver doesn't care about accessing the port or
endpoint nodes. The drivers typically just want the device connected via
a particular graph connection. of_graph_get_remote_node provides this
functionality.

Signed-off-by: Rob Herring 
Acked-by: Philipp Zabel 
---
v2:
- Fix of_node_put on endpoint node
- Added DocBook comments for function
- Made port/endpoint unsigned to disallow -1

 drivers/of/base.c| 37 +
 include/linux/of_graph.h |  8 
 2 files changed, 45 insertions(+)

diff --git a/drivers/of/base.c b/drivers/of/base.c
index d4bea3c797d6..525eb804f6ea 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -2469,3 +2469,40 @@ struct device_node *of_graph_get_remote_port(const 
struct device_node *node)
return of_get_next_parent(np);
 }
 EXPORT_SYMBOL(of_graph_get_remote_port);
+
+/**
+ * of_graph_get_remote_node() - get remote parent device_node for given 
port/endpoint
+ * @node: pointer to parent device_node containing graph port/endpoint
+ * @port: identifier (value of reg property) of the parent port node
+ * @endpoint: identifier (value of reg property) of the endpoint node
+ *
+ * Return: Remote device node associated with remote endpoint node linked
+ *to @node. Use of_node_put() on it when done.
+ */
+struct device_node *of_graph_get_remote_node(const struct device_node *node,
+u32 port, u32 endpoint)
+{
+   struct device_node *endpoint_node, *remote;
+
+   endpoint_node = of_graph_get_endpoint_by_regs(node, port, endpoint);
+   if (!endpoint_node) {
+   pr_debug("no valid endpoint (%d, %d) for node %s\n",
+port, endpoint, node->full_name);
+   return NULL;
+   }
+
+   remote = of_graph_get_remote_port_parent(endpoint_node);
+   of_node_put(endpoint_node);
+   if (!remote) {
+   pr_debug("no valid remote node\n");
+   return NULL;
+   }
+
+   if (!of_device_is_available(remote)) {
+   pr_debug("not available for remote node\n");
+   return NULL;
+   }
+
+   return remote;
+}
+EXPORT_SYMBOL(of_graph_get_remote_node);
diff --git a/include/linux/of_graph.h b/include/linux/of_graph.h
index bb3a5a2cd570..abdb02eaef06 100644
--- a/include/linux/of_graph.h
+++ b/include/linux/of_graph.h
@@ -51,6 +51,8 @@ struct device_node *of_graph_get_endpoint_by_regs(
 struct device_node *of_graph_get_remote_port_parent(
const struct device_node *node);
 struct device_node *of_graph_get_remote_port(const struct device_node *node);
+struct device_node *of_graph_get_remote_node(const struct device_node *node,
+u32 port, u32 endpoint);
 #else

 static inline int of_graph_parse_endpoint(const struct device_node *node,
@@ -89,6 +91,12 @@ static inline struct device_node *of_graph_get_remote_port(
 {
return NULL;
 }
+static inline struct device_node *of_graph_get_remote_node(
+   const struct device_node *node,
+   u32 port, u32 endpoint)
+{
+   return NULL;
+}

 #endif /* CONFIG_OF */

--
2.10.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC 0/4] Introduce drmfs pseudo filesystem for drm subsystem

[sourab gupta]

On Tue, 2016-12-20 at 01:44 -0800, Jani Nikula wrote:
> On Tue, 20 Dec 2016, Laurent Pinchart  
> wrote:
> > Hi Swati,
> >
> > On Monday 19 Dec 2016 16:12:22 swati.dhin...@intel.com wrote:
> >> From: Swati Dhingra 
> >>
> >> Currently, we don't have a stable ABI which can be used for the purpose of
> >> providing output debug/loggging/crc and other such data from DRM.
> >> The ABI in current use (filesystems, ioctls, et al.) have their own
> >> constraints and are intended to output a particular type of data.
> >> Few cases in point:
> >> sysfs- stable ABI, but constrained to one textual value per file
> >> debugfs  - unstable ABI, free-for-all
> >> ioctls   - not as suitable to many single purpose continuous data
> >>dumping, we would very quickly run out ioctl space; requires more
> >>userspace support than "cat"
> >> device nodes -  a real possibilty, kernel instantiation is more tricky,
> >>  requires udev (+udev.rules) or userspace discovery of the
> >>  dynamic major:minor (via sysfs) [mounting a registered
> >>  filesystem is easy in comparison]
> >> netlink  - stream based, therefore involves numerous copies.
> >>
> >> Debugfs is the lesser among the evils here, thereby we have grown used to
> >> the convenience and flexibility in presentation that debugfs gives us
> >> (including relayfs inodes) that we want some of that hierachy in stable 
> >> user
> >> ABI form.
> >
> > Seriously, why ? A subsystem growing its own file system sounds so wrong. It
> > seems that you want to have all the benefits of a stable ABI without going
> > through the standardization effort that this requires. I can see so many 
> > ways
> > that drmfs could be abused, with drivers throwing in new data with little or
> > no review. You'll need very compelling arguments to convince me.
> 
> This is not unlike my sentiments on the first version posted
> [1]. There's also the distinct feeling of [2]. Suffice it to say at this
> time that I'm dubious, not convinced enough to defend this.
> 
> Swati, please refrain from posting new versions of the patches until
> there's some consensus one way or the other; it's counter-productive to
> keep splitting off the discussion into several patch series threads at
> this stage. Let's have the discussion here.
> 
> 
> BR,
> Jani.
> 

Hi Jani,

One of the usecases we're exploring here is for pipe_crc to be
implemented over drmfs, instead of debugfs. But we're not sure whether
that'll also assuage the standardization questions/concerns.

Can you let us know how to proceed (since you've mentioned not to post
new version of patches). How do we address the standardization concerns
put forth on drmfs? Does simply having more *suitable* usecases suffice?
If not, What else should the arguments be in favor of drmfs?

Hi Chris,
Can you pitch in with your inputs in the discussion, and help address
the standardization concerns?

Regards,
Sourab

> 
> [1] http://mid.mail-archive.com/87lgw0xcf4.fsf@intel.com
> [2] https://xkcd.com/927/
> 
> >
> >> Due to these limitations, there is a need for a new pseudo filesytem, that
> >> would act as a stable 'free-for-all' ABI, with the heirarchial structure 
> >> and
> >> thus convenience of debugfs. This will be managed by drm, thus named
> >> 'drmfs'. DRM would register this filesystem to manage a canonical
> >> mountpoint, but this wouldn't limit everyone to only using that pseudofs
> >> underneath.
> >>
> >> This can serve to hold various kinds of output data from Linux DRM
> >> subsystems, for the files which can't truely fit anywhere else with
> >> existing ABI's but present so, for the lack of a better place.
> >>
> >> In this patch series, we have introduced a pseudo filesystem named as
> >> 'drmfs' for now. The filesystem is introduced in the first patch, and the
> >> subsequent patches make use of the filesystem interfaces, in drm driver,
> >> and making them available for use by the drm subsystem components, one of
> >> which is i915. We've moved the location of i915 GuC logs from debugfs to
> >> drmfs in the last patch. Subsequently, more such files such as pipe_crc,
> >> error states, memory stats, etc. can be move to this filesystem, if the
> >> idea introduced here is acceptable per se. The filesystem introduced is
> >> being used to house the data generated by i915 driver in this patch series,
> >> but will hopefully be generic enough to provide scope for usage by any
> >> other drm subsystem component.
> >>
> >> The patch series is being floated as RFC to gather feedback on the idea and
> >> infrastructure proposed here and it's suitability to address the specific
> >> problem statement/use case.
> >>
> >> v2: fix the bat failures caused due to missing config check
> >>
> >> v3: Changes made:
> >> - Move the location of drmfs from fs/ to drivers/gpu/drm/ (Chris)
> >> - Moving config checks to header 

[PATCH v3 3/8] drm/dp: Split drm_dp_mst_allocate_vcpi

[Dhinakaran Pandiyan]

drm_dp_mst_allocate_vcpi() apart from setting up the vcpi structure,
also finds if there are enough slots available. This check is a duplicate
of that implemented in drm_dp_mst_find_vcpi_slots(). Let's move this check
out and reuse the existing drm_dp_mst_find_vcpi_slots() function to check
if there are enough vcpi slots before allocating them.

This brings the check to one place. Additionally drivers that will use MST
state tracking for atomic modesets can use the atomic version of
find_vcpi_slots() and reuse drm_dp_mst_allocate_vcpi()

Signed-off-by: Dhinakaran Pandiyan 
Reviewed-by: Dave Airlie 
---
 drivers/gpu/drm/drm_dp_mst_topology.c  | 21 ++---
 drivers/gpu/drm/i915/intel_dp_mst.c|  4 ++--
 drivers/gpu/drm/nouveau/nv50_display.c |  3 ++-
 drivers/gpu/drm/radeon/radeon_dp_mst.c |  4 +++-
 include/drm/drm_dp_mst_helper.h|  3 ++-
 5 files changed, 19 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
b/drivers/gpu/drm/drm_dp_mst_topology.c
index d9edd84..37482b7 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -2479,20 +2479,17 @@ int drm_dp_find_vcpi_slots(struct 
drm_dp_mst_topology_mgr *mgr,
 EXPORT_SYMBOL(drm_dp_find_vcpi_slots);
 
 static int drm_dp_init_vcpi(struct drm_dp_mst_topology_mgr *mgr,
-   struct drm_dp_vcpi *vcpi, int pbn)
+   struct drm_dp_vcpi *vcpi, int pbn, int slots)
 {
-   int num_slots;
int ret;
 
-   num_slots = DIV_ROUND_UP(pbn, mgr->pbn_div);
-
/* max. time slots - one slot for MTP header */
-   if (num_slots > 63)
+   if (slots > 63)
return -ENOSPC;
 
vcpi->pbn = pbn;
-   vcpi->aligned_pbn = num_slots * mgr->pbn_div;
-   vcpi->num_slots = num_slots;
+   vcpi->aligned_pbn = slots * mgr->pbn_div;
+   vcpi->num_slots = slots;
 
ret = drm_dp_mst_assign_payload_id(mgr, vcpi);
if (ret < 0)
@@ -2507,7 +2504,8 @@ static int drm_dp_init_vcpi(struct 
drm_dp_mst_topology_mgr *mgr,
  * @pbn: payload bandwidth number to request
  * @slots: returned number of slots for this PBN.
  */
-bool drm_dp_mst_allocate_vcpi(struct drm_dp_mst_topology_mgr *mgr, struct 
drm_dp_mst_port *port, int pbn, int *slots)
+bool drm_dp_mst_allocate_vcpi(struct drm_dp_mst_topology_mgr *mgr,
+ struct drm_dp_mst_port *port, int pbn, int slots)
 {
int ret;
 
@@ -2515,16 +2513,18 @@ bool drm_dp_mst_allocate_vcpi(struct 
drm_dp_mst_topology_mgr *mgr, struct drm_dp
if (!port)
return false;
 
+   if (slots < 0)
+   return false;
+
if (port->vcpi.vcpi > 0) {
DRM_DEBUG_KMS("payload: vcpi %d already allocated for pbn %d - 
requested pbn %d\n", port->vcpi.vcpi, port->vcpi.pbn, pbn);
if (pbn == port->vcpi.pbn) {
-   *slots = port->vcpi.num_slots;
drm_dp_put_port(port);
return true;
}
}
 
-   ret = drm_dp_init_vcpi(mgr, >vcpi, pbn);
+   ret = drm_dp_init_vcpi(mgr, >vcpi, pbn, slots);
if (ret) {
DRM_DEBUG_KMS("failed to init vcpi slots=%d max=63 ret=%d\n",
DIV_ROUND_UP(pbn, mgr->pbn_div), ret);
@@ -2532,7 +2532,6 @@ bool drm_dp_mst_allocate_vcpi(struct 
drm_dp_mst_topology_mgr *mgr, struct drm_dp
}
DRM_DEBUG_KMS("initing vcpi for pbn=%d slots=%d\n",
pbn, port->vcpi.num_slots);
-   *slots = port->vcpi.num_slots;
 
drm_dp_put_port(port);
return true;
diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c 
b/drivers/gpu/drm/i915/intel_dp_mst.c
index 6a85d38..9b9dda8 100644
--- a/drivers/gpu/drm/i915/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/intel_dp_mst.c
@@ -149,7 +149,6 @@ static void intel_mst_pre_enable_dp(struct intel_encoder 
*encoder,
to_intel_connector(conn_state->connector);
int ret;
uint32_t temp;
-   int slots;
 
/* MST encoders are bound to a crtc, not to a connector,
 * force the mapping here for get_hw_state.
@@ -179,7 +178,8 @@ static void intel_mst_pre_enable_dp(struct intel_encoder 
*encoder,
 
ret = drm_dp_mst_allocate_vcpi(_dp->mst_mgr,
   connector->port,
-  pipe_config->pbn, );
+  pipe_config->pbn,
+  pipe_config->dp_m_n.tu);
if (ret == false) {
DRM_ERROR("failed to allocate vcpi\n");
return;
diff --git a/drivers/gpu/drm/nouveau/nv50_display.c 
b/drivers/gpu/drm/nouveau/nv50_display.c
index cd75413..6bfdf47 100644
--- a/drivers/gpu/drm/nouveau/nv50_display.c
+++ b/drivers/gpu/drm/nouveau/nv50_display.c
@@ -2895,7 +2895,8 @@ nv50_msto_enable(struct 

Re: [Intel-gfx] [PATCH v3 4/8] drm: Add driver-private objects to atomic state

[Pandiyan, Dhinakaran]

On Thu, 2017-02-09 at 08:08 +, Chris Wilson wrote:
> On Wed, Feb 08, 2017 at 10:38:07PM -0800, Dhinakaran Pandiyan wrote:
> > +#define for_each_private_obj(__state, obj_funcs, obj, obj_state, __i, 
> > __funcs) \
> > +   for ((__i) = 0; \
> > +(__i) < (__state)->num_private_objs && \
> > +((obj) = (__state)->private_objs[__i].obj, \
> > +(__funcs) = (__state)->private_objs[__i].funcs,\
> > +(obj_state) = (__state)->private_objs[__i].obj_state, 1);  \
> 
> Align to ( and put the trailing 1 on its own line so it stands out.

Sure, will do that. Looks like I have to change other macros in that
file too.

-DK
> 
>(__i) < (__state)->num_private_objs && \
>((obj) = (__state)->private_objs[__i].obj, \
> (__funcs) = (__state)->private_objs[__i].funcs,   \
> (obj_state) = (__state)->private_objs[__i].obj_state, \
> 1);   \
>(__i)++)   \
> > +   for_each_if (__funcs == obj_funcs)
> > +
> > +/**
> >   * drm_atomic_crtc_needs_modeset - compute combined modeset need
> >   * @state: _crtc_state for the CRTC
> >   *
> 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 1/8] drm/dp: Kill total_pbn and total_slots in struct drm_dp_mst_topology_mgr

[Dhinakaran Pandiyan]

The total vcpi time slots is always 63 and does not depend on the link BW,
remove total_slots from MST topology manager struct. The next change is to
remove total_pbn which is hardcoded to 2560. The total PBN that the
topology manager allocates from depends on the link rate and is not a
constant. So, fix this by removing the total_pbn member itself.

Signed-off-by: Dhinakaran Pandiyan 
---
 drivers/gpu/drm/drm_dp_mst_topology.c | 5 ++---
 include/drm/drm_dp_mst_helper.h   | 9 +
 2 files changed, 3 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 122a1b0..cf4b866 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -2042,9 +2042,8 @@ int drm_dp_mst_topology_mgr_set_mst(struct 
drm_dp_mst_topology_mgr *mgr, bool ms
goto out_unlock;
}
 
-   mgr->total_pbn = 2560;
-   mgr->total_slots = DIV_ROUND_UP(mgr->total_pbn, mgr->pbn_div);
-   mgr->avail_slots = mgr->total_slots;
+   /* max. time slots - one slot for MTP header */
+   mgr->avail_slots = 63;
 
/* add initial branch device at LCT 1 */
mstb = drm_dp_add_mst_branch_device(1, NULL);
diff --git a/include/drm/drm_dp_mst_helper.h b/include/drm/drm_dp_mst_helper.h
index f4b4d15..1a7e0f4 100644
--- a/include/drm/drm_dp_mst_helper.h
+++ b/include/drm/drm_dp_mst_helper.h
@@ -479,18 +479,11 @@ struct drm_dp_mst_topology_mgr {
 * @pbn_div: PBN to slots divisor.
 */
int pbn_div;
-   /**
-* @total_slots: Total slots that can be allocated.
-*/
-   int total_slots;
+
/**
 * @avail_slots: Still available slots that can be allocated.
 */
int avail_slots;
-   /**
-* @total_pbn: Total PBN count.
-*/
-   int total_pbn;
 
/**
 * @qlock: protects @tx_msg_downq, the _dp_mst_branch.txslost and
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 99744] Bad crtc detection on Radeon Pro WX 4100

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=99744

Michel Dänzer  changed:

   What|Removed |Added

   Assignee|xorg-driver-...@lists.x.org |dri-devel@lists.freedesktop
   ||.org
 QA Contact|xorg-t...@lists.x.org   |
  Component|Driver/AMDgpu   |DRM/AMDgpu
Product|xorg|DRI

--- Comment #1 from Michel Dänzer  ---
Please attach the Xorg log file and dmesg output corresponding to the problem.

This is up to the kernel driver. You could try the amd-staging-4.9 branch of
https://cgit.freedesktop.org/~agd5f/linux/ with CONFIG_DRM_AMD_DC enabled to
see if that works better.

-- 
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

[git pull] drm fixes for final v4.10

[Dave Airlie]

Hi Linus,

This should be the final set of drm fixes for 4.10, one vmwgfx boot
fix, one vc4 fix, and a few i915 fixes.

Hopefully haven't missed anything.

Dave.

The following changes since commit d5adbfcd5f7bcc6fa58a41c5c5ada0e5c826ce2c:

  Linux 4.10-rc7 (2017-02-05 15:10:58 -0800)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux tags/drm-fixes-for-v4.10-rc8

for you to fetch changes up to 697d3a21615672b2bf7724a65755799260325dda:

  Merge tag 'drm-intel-fixes-2017-02-09' of
git://anongit.freedesktop.org/git/drm-intel into drm-fixes (2017-02-10
10:14:24 +1000)


i915, vc4 and vmwgfx fix.


Andrey Ryabinin (1):
  drm/i915: fix use-after-free in page_flip_completed()

Andrzej Pietrasiewicz (1):
  drm: vc4: adapt to new behaviour of drm_crtc.c

Chris Wilson (2):
  drm/i915: Flush untouched framebuffers before display on !llc
  drm/i915: Remove overzealous fence warn on runtime suspend

Dave Airlie (3):
  Merge branch 'drm-vmwgfx-fixes-4_10' of
git://people.freedesktop.org/~syeh/repos_linux into drm-fixes
  Merge tag 'drm-misc-fixes-2017-02-09' of
git://anongit.freedesktop.org/git/drm-misc into drm-fixes
  Merge tag 'drm-intel-fixes-2017-02-09' of
git://anongit.freedesktop.org/git/drm-intel into drm-fixes

Jani Nikula (1):
  drm/i915: don't warn about Skylake CPU - KabyPoint PCH combo

Juergen Gross (1):
  drm/i915: fix i915 running as dom0 under Xen

Lee, Shawn C (1):
  drm/i915/bxt: Add MST support when do DPLL calculation

Michał Winiarski (1):
  drm/i915: Always convert incoming exec offsets to non-canonical

Sinclair Yeh (1):
  drm/vmwgfx: Fix depth input into drm_mode_legacy_fb_format

 drivers/gpu/drm/i915/i915_drv.c|  4 +++-
 drivers/gpu/drm/i915/i915_gem.c| 14 +++---
 drivers/gpu/drm/i915/i915_gem_execbuffer.c | 12 ++--
 drivers/gpu/drm/i915/i915_gem_internal.c   | 12 ++--
 drivers/gpu/drm/i915/intel_display.c   |  4 ++--
 drivers/gpu/drm/i915/intel_dpll_mgr.c  |  3 ++-
 drivers/gpu/drm/vc4/vc4_plane.c|  2 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_fb.c |  3 +--
 8 files changed, 36 insertions(+), 18 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 99747] Problems with mesa 13.0.x and ubuntu 17.04

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=99747

--- Comment #2 from Michel Dänzer  ---
What does

 apt-cache policy libllvm3.9

say?

-- 
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 99748] [radeonsi] Civ6 Assert in LLVM SIMachineScheduler.cpp with R600_DEBUG=sisched

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=99748

Bug ID: 99748
   Summary: [radeonsi] Civ6 Assert in LLVM SIMachineScheduler.cpp
with R600_DEBUG=sisched
   Product: Mesa
   Version: git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: m...@fireburn.co.uk
QA Contact: dri-devel@lists.freedesktop.org

When running Civ6 using LLVM from git (SHA1's tested
1648ceaabcea762590049a74ce8b934e3bfd4fb2 and
897444660daf9e94c020efc97b63aed7e61db7ac) with R600_DEBUG=sisched and the
latest Mesa it would assert with the following error:

Civ6:
/var/tmp/portage/sys-devel/llvm-/work/llvm-/lib/Target/AMDGPU/SIMachineScheduler.cpp:1584:
void llvm::SIScheduleBlockScheduler::blockScheduled(llvm::SIScheduleBlock*):
Assertion `LiveRegsConsumers[RegP.first] == 0' failed.

This doesn't happen with LLVM-4.0.0-rc1 even when using R600_DEBUG=sisched

-- 
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 95306] Random Blank(black) screens on "Carrizo"

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=95306

--- Comment #56 from Jaime Rodrigo  ---
I tried 4.10 RC7, and I could successfully login with this kernel. But after 5
mins of using it, I had a blackout again :/ . Guess I'll stick to RC5 for a
while

-- 
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 97879] [amdgpu] Rocket League: long hangs (several seconds) when loading assets (models/textures/shaders?)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=97879

--- Comment #75 from Michel Dänzer  ---
(In reply to Clemens Eisserer from comment #73)
> just to be curious, does it actually map the buffer with the READ flag?

According to Timothee and the apitrace it does, so
https://patchwork.freedesktop.org/patch/138047/ should help for this issue.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
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 97879] [amdgpu] Rocket League: long hangs (several seconds) when loading assets (models/textures/shaders?)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=97879

--- Comment #74 from i...@posteo.net ---
Do you need more testing?

Has anyone yet reported that to psyonix?

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 99747] Problems with mesa 13.0.x and ubuntu 17.04

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=99747

--- Comment #1 from APoliTech  ---
The links to the launchpad.net reports
https://bugs.launchpad.net/ubuntu-mate/+bug/1663379
https://bugs.launchpad.net/ubuntu-mate/+bug/1663391

-- 
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 99747] Problems with mesa 13.0.x and ubuntu 17.04

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=99747

APoliTech  changed:

   What|Removed |Added

  Component|Other   |Drivers/Gallium/radeonsi
 QA Contact|mesa-dev@lists.freedesktop. |dri-devel@lists.freedesktop
   |org |.org
   Assignee|mesa-dev@lists.freedesktop. |dri-devel@lists.freedesktop
   |org |.org

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 98869] Electronic Super Joy graphic artefacts (regression,bisected)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=98869

Grazvydas Ignotas  changed:

   What|Removed |Added

 CC||nota...@gmail.com

--- Comment #19 from Grazvydas Ignotas  ---
Created attachment 129459
  --> https://bugs.freedesktop.org/attachment.cgi?id=129459=edit
hack

I guess not many developers still have r300 hardware, so you'll have to test
some patches. Here is one you can try.

-- 
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/6] drm: Introduce drm_mode_object_{get,put}()

[Emil Velikov]

On 9 February 2017 at 20:41, Thierry Reding  wrote:
> On Thu, Feb 09, 2017 at 06:08:10PM +0100, Daniel Vetter wrote:
>> On Wed, Feb 08, 2017 at 02:28:14PM -0500, Sean Paul wrote:
>> > On Wed, Feb 08, 2017 at 07:24:04PM +0100, Thierry Reding wrote:
>> > > From: Thierry Reding 
>> > >
>> > > For consistency with other reference counting APIs in the kernel, add
>> > > drm_mode_object_get() and drm_mode_object_put() to reference count DRM
>> > > mode objects.
>> > >
>> > > Compatibility aliases are added to keep existing code working. To help
>> > > speed up the transition, all the instances of the old functions in the
>> > > DRM core are already replaced in this commit.
>> > >
>> >
>> > drm code looks good and is
>> >
>> > Reviewed-by: Sean Paul 
>> >
>> > > A semantic patch is provided that can be used to convert all drivers to
>> > > the new helpers.
>> >
>> > I'm not convinced we need to commit the cocci patch. I think including it 
>> > in
>> > your cover letter and then following up with a follow on series to 
>> > actually make
>> > the change is sufficient (See: ickle's s/fence/dma_fence/ series).
>>
>> Yeah, if you do a large-scale refactor anyway, I think it's best to just
>> store the cocci in the commit message. I think storing the cocci is ok if
>> you have thousands of hits among lots of subsystems, and it's clear it's
>> going to take at least a few release cycles or maybe even years to clean
>> it all up. drm is luckily not yet that big :-)
>>
>> I'll drop this while applying if no one minds ...
>
> I thought it was actually quite nice that this was part of the series.
> That way it doesn't get lost and it is really easy to rerun. Also it can
> trivially be removed once we've converted everyone to the new functions
> and removed the old ones.
>
Hidden bonus:
Some of the people who run those on semi-regular basis can update
some/all the drivers ;-)

-Emil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 99450] [amdgpu] Payday 2 visual glitches on some models

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=99450

--- Comment #5 from Samuel Pitoiset  ---
Okay, you hit a second issue that should be definitely fixed in mesa 17. I
confirm the visual glitches with 13.0.4, but not with latest mesa/llvm.

Fwiw, the commit previously mentionned should prevent VM faults and improve
stability.

Please close the bug when mesa 17 will be in your distro.
Thanks!

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 99136] Blood Effects Total War: Warhammer

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=99136

--- Comment #24 from Samuel Pitoiset  ---
I do have the blood dlc now. Unfortunately, after trying few minutes I can't
reproduce the issue with latest mesa/LLVM. Maybe it's on my side but I don't
really have much time to investigate into that issue. Sorry.

However, if you can record an apitrace which reproduces the issue, that would
be awesome and really easier for us.

https://github.com/apitrace/apitrace

Thanks in advancce.

-- 
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 194533] New: Invalid PCI ROM header signature: expecting 0xaa55, got 0x9125

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=194533

Bug ID: 194533
   Summary: Invalid PCI ROM header signature: expecting 0xaa55,
got 0x9125
   Product: Drivers
   Version: 2.5
Kernel Version: 4.9.8
  Hardware: All
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: high
  Priority: P1
 Component: Video(DRI - non Intel)
  Assignee: drivers_video-...@kernel-bugs.osdl.org
  Reporter: nuc...@hotmail.com
Regression: No

Created attachment 254691
  --> https://bugzilla.kernel.org/attachment.cgi?id=254691=edit
dmesg

I get "Invalid PCI ROM header signature: expecting 0xaa55, got 0x9125" upon
booting my PC with my new Sapphire RX 470 OC graphics card.
Also there seem to be numerous errors in the dmesg.
I do not experience any major issues, but I also haven't tested any heavy 3d
application so far...

-- 
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 194533] Invalid PCI ROM header signature: expecting 0xaa55, got 0x9125

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=194533

nuc...@hotmail.com changed:

   What|Removed |Added

 CC||nuc...@hotmail.com
   Hardware|All |x86-64

-- 
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 194533] Invalid PCI ROM header signature: expecting 0xaa55, got 0x9125

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=194533

--- Comment #1 from nuc...@hotmail.com ---
Created attachment 254693
  --> https://bugzilla.kernel.org/attachment.cgi?id=254693=edit
lspci -vv

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/6] drm: Introduce drm_mode_object_{get,put}()

[Thierry Reding]

On Thu, Feb 09, 2017 at 06:08:10PM +0100, Daniel Vetter wrote:
> On Wed, Feb 08, 2017 at 02:28:14PM -0500, Sean Paul wrote:
> > On Wed, Feb 08, 2017 at 07:24:04PM +0100, Thierry Reding wrote:
> > > From: Thierry Reding 
> > > 
> > > For consistency with other reference counting APIs in the kernel, add
> > > drm_mode_object_get() and drm_mode_object_put() to reference count DRM
> > > mode objects.
> > > 
> > > Compatibility aliases are added to keep existing code working. To help
> > > speed up the transition, all the instances of the old functions in the
> > > DRM core are already replaced in this commit.
> > > 
> > 
> > drm code looks good and is 
> > 
> > Reviewed-by: Sean Paul 
> > 
> > > A semantic patch is provided that can be used to convert all drivers to
> > > the new helpers.
> > 
> > I'm not convinced we need to commit the cocci patch. I think including it in
> > your cover letter and then following up with a follow on series to actually 
> > make
> > the change is sufficient (See: ickle's s/fence/dma_fence/ series).
> 
> Yeah, if you do a large-scale refactor anyway, I think it's best to just
> store the cocci in the commit message. I think storing the cocci is ok if
> you have thousands of hits among lots of subsystems, and it's clear it's
> going to take at least a few release cycles or maybe even years to clean
> it all up. drm is luckily not yet that big :-)
> 
> I'll drop this while applying if no one minds ...

I thought it was actually quite nice that this was part of the series.
That way it doesn't get lost and it is really easy to rerun. Also it can
trivially be removed once we've converted everyone to the new functions
and removed the old ones.

Thierry


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/6] drm: Introduce consistent reference counting APIs

[Thierry Reding]

On Thu, Feb 09, 2017 at 08:07:41PM +0100, Daniel Vetter wrote:
> On Thu, Feb 09, 2017 at 07:39:33PM +0200, Jani Nikula wrote:
> > On Thu, 09 Feb 2017, Daniel Vetter  wrote:
> > > On Thu, Feb 09, 2017 at 04:10:12PM +0200, Jani Nikula wrote:
> > >> On Wed, 08 Feb 2017, Thierry Reding  wrote:
> > >> > This series introduces DRM reference counting APIs that are consistent
> > >> > with other reference counting APIs in the kernel. They are also much
> > >> > shorter. Compatibility aliases are added to keep existing code working
> > >> > and will stay in place until all users of the old APIs are gone.
> > >> 
> > >> I like it.
> > >> 
> > >> But it makes drm_connector_list_iter_{get,put} stick out like a sore
> > >> thumb. Something for the TODO list I guess.
> > >
> > > Hm, why is that one the sore thumb now? Just because it's really long? It
> > > does acquire/drop references behind the scenes, that's why I went with the
> > > _get/put postfixes ...
> > 
> > I think the assumption is that get/put work on an object, and you can
> > get/put as many times as you like, as long as you keep them at
> > balance. AFAICT this doesn't hold for iter.
> 
> Hm right. What else should we use instead? start/stop are confusing in the
> context of list walking, create/destroy maybe?

I rather like the _begin()/_end() suffix that I think iterators have in
the C++ STL. Well, I guess it's really .end() and .begin() methods in
C++.

But the following reads rather nicely:

drm_connector_list_iter_begin(dev, );

drm_for_each_connector_iter(connector, )
...

drm_connector_list_iter_end();

Alternatively some other iterators simply use an _init() suffix to
initialize the iterator. The kernel has a few of these, such as the
of_phandle_iterator (see include/linux/of.h) or of_pci_range_parser (see
include include/linux/of_address.h).

EFI code uses _begin()/_end() in include/linux/efi.h, cgroups seems to
have _start()/_end() in include/linux/cgroup.h. include/linux/klist.h
uses klist_iter_init()/klist_iter_exit(). include/linux/rhashtable.h has
rhashtable_walk_start()/rhashtable_walk_stop().

A quick grep also shows other variants, one of them being _first(), but
those don't have an explicit end function.

So there's quite a few options to choose from, but I guess that doesn't
make it any easier.

If this was a poll, my vote would go to _begin()/_end().

Thierry


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[pull] radeon and amdgpu drm-next-4.11

[Alex Deucher]

Hi Dave,

Some additional fixes for 4.11.  Delayed a bit due to Chinese New Year. 
Highlights:
- Powerplay fixes
- VCE and UVD powergating fixes
- Clean up amdgpu SI gfx code to match CI and VI
- Misc bug fixes

The following changes since commit 18566acac18f5784347bc5fe636a26897d1c963b:

  Merge branch 'exynos-drm-next' of 
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-next 
(2017-02-01 08:43:42 +1000)

are available in the git repository at:

  git://people.freedesktop.org/~agd5f/linux drm-next-4.11

for you to fetch changes up to fad061270ac43ff9eed315f0eae7c40b694592de:

  drm/amdgpu: report the number of bytes moved at buffer creation (2017-02-09 
11:29:44 -0500)


Alex Deucher (1):
  drm/amdgpu: add support for new smc firmware on polaris

Arnd Bergmann (1):
  drm/amdgpu: shut up #warning for compile testing

Christian König (2):
  drm/amdgpu: fix race in GEM VA map IOCTL v2
  drm/amdgpu: stop reserving a shared fence for VA updates

Colin Ian King (1):
  drm/amdgpu/virt: fix double kfree on bo_va

Dan Carpenter (1):
  drm/radeon: remove some dead code

Flora Cui (7):
  drm/amdgpu/gfx6: clean up rb configuration
  drm/amdgpu/gfx6: clean up cu configuration
  drm/amdgpu/gfx6: clean up spi configuration
  drm/amdgpu: refine si_read_register
  drm/amdgpu: update VERDE_GB_ADDR_CONFIG_GOLDEN
  drm/amdgpu: update HAINAN_GB_ADDR_CONFIG_GOLDEN
  drm/amd/gfx6: update gb_addr_config

Jérôme Glisse (1):
  drm/radeon: avoid kernel segfault in vce when gpu fails to resume

Rex Zhu (14):
  drm/amdgpu: when dpm disabled, also can enable uvd cg/pg.
  drm/amdgpu: add current_pg_status register define for smu7.1
  drm/amdgpu: power down/up uvd4 when smu disabled.
  drm/amdgpu: refine uvd pg code in kv_dpm.c
  drm/amdgpu: refine uvd4.2 init/stop code.
  drm/amdgpu: fix uvd can't initialized when dpm disabled on Ci.
  drm/amdgpu: refine uvd5.0/6.0 code.
  drm/amdgpu: when dpm disabled, also need to stop/start vce.
  drm/amdgpu: refine code for VCE2.0 and related dpm code.
  drm/amdgpu: enable vce pg feature on Kv.
  drm/amdgpu: move subfunctions to the front of vce_v2_0.c.
  drm/amdgpu: refine vce3.0 code and related powerplay pg code.
  drm/amd/powerplay: set fan speed to max in profile peak mode only.
  drm/amd/powerplay: refine code to avoid potential bug that the memory not 
cleared.

Samuel Pitoiset (2):
  drm/amdgpu: fix a potential deadlock in amdgpu_bo_create_restricted()
  drm/amdgpu: report the number of bytes moved at buffer creation

 drivers/gpu/drm/amd/amdgpu/amdgpu.h|   1 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c|  33 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c |   3 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c|  54 +--
 drivers/gpu/drm/amd/amdgpu/amdgpu_object.c |  13 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c |  12 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c|   9 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c|   9 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c   |   1 -
 drivers/gpu/drm/amd/amdgpu/ci_dpm.c|  29 +-
 drivers/gpu/drm/amd/amdgpu/cik.c   |   4 +-
 drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c  | 216 --
 drivers/gpu/drm/amd/amdgpu/kv_dpm.c|  68 +---
 drivers/gpu/drm/amd/amdgpu/si.c|  90 +++-
 drivers/gpu/drm/amd/amdgpu/si_enums.h  |   4 +-
 drivers/gpu/drm/amd/amdgpu/uvd_v4_2.c  | 128 --
 drivers/gpu/drm/amd/amdgpu/uvd_v5_0.c  |  24 +-
 drivers/gpu/drm/amd/amdgpu/uvd_v6_0.c  |  21 +-
 drivers/gpu/drm/amd/amdgpu/vce_v2_0.c  | 451 +++--
 drivers/gpu/drm/amd/amdgpu/vce_v3_0.c  |  17 +-
 .../gpu/drm/amd/include/asic_reg/smu/smu_7_0_1_d.h |   1 +
 .../drm/amd/powerplay/hwmgr/cz_clockpowergating.c  |  74 ++--
 .../amd/powerplay/hwmgr/smu7_clockpowergating.c|  23 +-
 drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c   |  22 +-
 drivers/gpu/drm/amd/powerplay/smumgr/smumgr.c  |   2 +
 drivers/gpu/drm/radeon/radeon_bios.c   |   4 +-
 drivers/gpu/drm/radeon/vce_v1_0.c  |   2 +-
 27 files changed, 682 insertions(+), 633 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/6] drm: Introduce consistent reference counting APIs

[Daniel Vetter]

On Thu, Feb 09, 2017 at 07:39:33PM +0200, Jani Nikula wrote:
> On Thu, 09 Feb 2017, Daniel Vetter  wrote:
> > On Thu, Feb 09, 2017 at 04:10:12PM +0200, Jani Nikula wrote:
> >> On Wed, 08 Feb 2017, Thierry Reding  wrote:
> >> > This series introduces DRM reference counting APIs that are consistent
> >> > with other reference counting APIs in the kernel. They are also much
> >> > shorter. Compatibility aliases are added to keep existing code working
> >> > and will stay in place until all users of the old APIs are gone.
> >> 
> >> I like it.
> >> 
> >> But it makes drm_connector_list_iter_{get,put} stick out like a sore
> >> thumb. Something for the TODO list I guess.
> >
> > Hm, why is that one the sore thumb now? Just because it's really long? It
> > does acquire/drop references behind the scenes, that's why I went with the
> > _get/put postfixes ...
> 
> I think the assumption is that get/put work on an object, and you can
> get/put as many times as you like, as long as you keep them at
> balance. AFAICT this doesn't hold for iter.

Hm right. What else should we use instead? start/stop are confusing in the
context of list walking, create/destroy maybe?

I don't have a good name I guess ...
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 2/2] drm/fb_helper: implement ioctl FBIO_WAITFORVSYNC

[Daniel Vetter]

On Thu, Feb 09, 2017 at 05:38:26PM +, Daniel Stone wrote:
> Hi,
> 
> On 9 February 2017 at 17:01, Daniel Vetter  wrote:
> > On Thu, Feb 02, 2017 at 11:31:57AM +0100, Maxime Ripard wrote:
> >> +int drm_fb_helper_ioctl(struct fb_info *info, unsigned int cmd, unsigned 
> >> long arg)
> >> +{
> >> + struct drm_fb_helper *fb_helper = info->par;
> >> + struct drm_device *dev = fb_helper->dev;
> >> + unsigned int i;
> >> + int ret = 0;
> >> +
> >> + drm_modeset_lock_all(dev);
> >> + if (!drm_fb_helper_is_bound(fb_helper)) {
> >> + drm_modeset_unlock_all(dev);
> >> + return -EBUSY;
> >> + }
> >> +
> >> + switch (cmd) {
> >> + case FBIO_WAITFORVSYNC:
> >> + for (i = 0; i < fb_helper->crtc_count; i++) {
> >> + struct drm_mode_set *mode_set;
> >> + struct drm_crtc *crtc;
> >> +
> >> + mode_set = _helper->crtc_info[i].mode_set;
> >> + crtc = mode_set->crtc;
> >> +
> >> + /*
> >> +  * Only call drm_crtc_wait_one_vblank for crtcs that
> >> +  * are currently enabled.
> >> +  */
> >> + if (!crtc->enabled)
> >> + continue;
> >
> > This needs locking
> 
> More locking than the drm_modeset_lock_all() above the switch? Ouch. :)

Oh, I didn't spot that one. Well, that one should be removed imo, we dont
want any vblank wait path to hold these locks, it looks bad. Otoh we still
need to grab the dev->mode_config.mutex, because that's also the fbdev
lock. There's a plan somewhere to give the fbdev helpers their own lock,
so switching to just mode_config.mutex + the changes I suggestd would be
good.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/vc4: Fix OOPSes from trying to cache a partially constructed BO.

[Eric Anholt]

If a CMA allocation failed, the partially constructed BO would be
unreferenced through the normal path, and we might choose to put it in
the BO cache.  If we then reused it before it expired from the cache,
the kernel would OOPS.

Signed-off-by: Eric Anholt 
Fixes: c826a6e10644 ("drm/vc4: Add a BO cache.")
---
 drivers/gpu/drm/vc4/vc4_bo.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/vc4/vc4_bo.c b/drivers/gpu/drm/vc4/vc4_bo.c
index 5ec14f25625d..fd83a2807656 100644
--- a/drivers/gpu/drm/vc4/vc4_bo.c
+++ b/drivers/gpu/drm/vc4/vc4_bo.c
@@ -314,6 +314,14 @@ void vc4_free_object(struct drm_gem_object *gem_bo)
goto out;
}
 
+   /* If this object was partially constructed but CMA allocation
+* had failed, just free it.
+*/
+   if (!bo->base.vaddr) {
+   vc4_bo_destroy(bo);
+   goto out;
+   }
+
cache_list = vc4_get_cache_list_for_size(dev, gem_bo->size);
if (!cache_list) {
vc4_bo_destroy(bo);
-- 
2.11.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/6] drm: Introduce consistent reference counting APIs

[Jani Nikula]

On Thu, 09 Feb 2017, Daniel Vetter  wrote:
> On Thu, Feb 09, 2017 at 04:10:12PM +0200, Jani Nikula wrote:
>> On Wed, 08 Feb 2017, Thierry Reding  wrote:
>> > This series introduces DRM reference counting APIs that are consistent
>> > with other reference counting APIs in the kernel. They are also much
>> > shorter. Compatibility aliases are added to keep existing code working
>> > and will stay in place until all users of the old APIs are gone.
>> 
>> I like it.
>> 
>> But it makes drm_connector_list_iter_{get,put} stick out like a sore
>> thumb. Something for the TODO list I guess.
>
> Hm, why is that one the sore thumb now? Just because it's really long? It
> does acquire/drop references behind the scenes, that's why I went with the
> _get/put postfixes ...

I think the assumption is that get/put work on an object, and you can
get/put as many times as you like, as long as you keep them at
balance. AFAICT this doesn't hold for iter.

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: Add helper macro for duplicating custom drm_*_state

[Daniel Vetter]

On Thu, Feb 09, 2017 at 03:41:42PM +, Mihail Atanassov wrote:
> Assuming a derived struct of the form:
> 
> struct foo_bar_state
> {
>   struct drm_bar_state bar_state;
>   struct foo_private priv;
>   struct foo_private2 *priv2;
> };
> 
> memcpy priv and priv2 to the new instance of foo_bar_state. The
> intention is to use this macro in ->atomic_duplicate_state in conjunction with
> __drm_atomic_helper_*_duplicate_state, which already copies the relevant
> drm_*_state struct.
> 
> There's an equality check for new_state and old_state to ensure that
> they are distinct instances of the same type, and a BUILD_BUG if the
> base struct (bar_state in the above example) is not first in the derived
> struct, to avoid missing any data before it and corrupting the base's data.
> 
> Signed-off-by: Mihail Atanassov 
> ---
>  include/drm/drm_atomic_helper.h | 33 +
>  1 file changed, 33 insertions(+)
> 
> diff --git a/include/drm/drm_atomic_helper.h b/include/drm/drm_atomic_helper.h
> index d066e94..ecc6a82 100644
> --- a/include/drm/drm_atomic_helper.h
> +++ b/include/drm/drm_atomic_helper.h
> @@ -171,6 +171,39 @@ int drm_atomic_helper_legacy_gamma_set(struct drm_crtc 
> *crtc,
>  uint32_t size);
>  
>  /**
> + * drm_atomic_duplicate_custom_state - helper macro for duplicating
> + * driver-private additions to drm_*_state.
> + * @new_state: pointer to destination state struct
> + * @old_state: pointer to source state struct
> + * @basename: name of the drm_*_state member of the new_state/old_state 
> struct
> + *
> + * Copies the data after the base struct until the end of the custom struct,
> + * e.g. given a structure
> + *
> + * struct foo_bar_state {
> + *   struct drm_bar_state base;
> + *   struct foo_private priv;
> + *   struct foo_private2 *priv2;
> + * };

Forgot the kernel-doc bikeshed: Please reformat this that it's a proper
rst quoted block for prettier output. See

http://blog.ffwll.ch/2016/12/howto-docs.html

> + *
> + * this copies priv and priv2. NB: the base struct *must* be the first 
> element

Iirc rst has a different opinion how bold higlighting works, pls double
check this is the right one.

> + * of the derived struct, and new_state and old_state have to be two distinct

@new_state and @old_state

> + * instances.

btw for even more fanciness you could do an example of what a driver's
foo_bar_duplicate_state() function would look like, using this. That would
be even better I think. And maybe s/foo/drv/ for clarity ...

Just ideas, feel free to prettify as you see fit.

Cheers, Daniel

> + */
> +#define drm_atomic_helper_duplicate_custom_state(new_state, old_state, 
> basename) \
> + do { \
> + size_t base_size = sizeof(new_state->basename); \
> + size_t base_offset = offsetof(typeof(*new_state), basename); \
> + \
> + BUILD_BUG_ON(base_offset != 0); \
> + if (new_state == old_state) /* Type-check */ \
> + break; \
> + memcpy((char *)new_state + base_size, \
> +(char *)old_state + base_size, \
> +sizeof(*new_state) - base_size); \
> + } while(0)
> +
> +/**
>   * drm_atomic_crtc_for_each_plane - iterate over planes currently attached 
> to CRTC
>   * @plane: the loop cursor
>   * @crtc:  the crtc whose planes are iterated
> -- 
> 1.9.1
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 2/2] drm/fb_helper: implement ioctl FBIO_WAITFORVSYNC

[Daniel Stone]

Hi,

On 9 February 2017 at 17:01, Daniel Vetter  wrote:
> On Thu, Feb 02, 2017 at 11:31:57AM +0100, Maxime Ripard wrote:
>> +int drm_fb_helper_ioctl(struct fb_info *info, unsigned int cmd, unsigned 
>> long arg)
>> +{
>> + struct drm_fb_helper *fb_helper = info->par;
>> + struct drm_device *dev = fb_helper->dev;
>> + unsigned int i;
>> + int ret = 0;
>> +
>> + drm_modeset_lock_all(dev);
>> + if (!drm_fb_helper_is_bound(fb_helper)) {
>> + drm_modeset_unlock_all(dev);
>> + return -EBUSY;
>> + }
>> +
>> + switch (cmd) {
>> + case FBIO_WAITFORVSYNC:
>> + for (i = 0; i < fb_helper->crtc_count; i++) {
>> + struct drm_mode_set *mode_set;
>> + struct drm_crtc *crtc;
>> +
>> + mode_set = _helper->crtc_info[i].mode_set;
>> + crtc = mode_set->crtc;
>> +
>> + /*
>> +  * Only call drm_crtc_wait_one_vblank for crtcs that
>> +  * are currently enabled.
>> +  */
>> + if (!crtc->enabled)
>> + continue;
>
> This needs locking

More locking than the drm_modeset_lock_all() above the switch? Ouch. :)

Cheers,
Daniel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: Add helper macro for duplicating custom drm_*_state

[Daniel Vetter]

On Thu, Feb 09, 2017 at 03:41:42PM +, Mihail Atanassov wrote:
> Assuming a derived struct of the form:
> 
> struct foo_bar_state
> {
>   struct drm_bar_state bar_state;
>   struct foo_private priv;
>   struct foo_private2 *priv2;
> };
> 
> memcpy priv and priv2 to the new instance of foo_bar_state. The
> intention is to use this macro in ->atomic_duplicate_state in conjunction with
> __drm_atomic_helper_*_duplicate_state, which already copies the relevant
> drm_*_state struct.
> 
> There's an equality check for new_state and old_state to ensure that
> they are distinct instances of the same type, and a BUILD_BUG if the
> base struct (bar_state in the above example) is not first in the derived
> struct, to avoid missing any data before it and corrupting the base's data.
> 
> Signed-off-by: Mihail Atanassov 

Seems reasonable, but I don't have any strong opinions about it's
usefulness. Converting a few drivers (to really establish it as a
pattern), or at least a few acks from maintainers, to prove that it's a
good idea, and I'll merge this.
-Daniel

> ---
>  include/drm/drm_atomic_helper.h | 33 +
>  1 file changed, 33 insertions(+)
> 
> diff --git a/include/drm/drm_atomic_helper.h b/include/drm/drm_atomic_helper.h
> index d066e94..ecc6a82 100644
> --- a/include/drm/drm_atomic_helper.h
> +++ b/include/drm/drm_atomic_helper.h
> @@ -171,6 +171,39 @@ int drm_atomic_helper_legacy_gamma_set(struct drm_crtc 
> *crtc,
>  uint32_t size);
>  
>  /**
> + * drm_atomic_duplicate_custom_state - helper macro for duplicating
> + * driver-private additions to drm_*_state.
> + * @new_state: pointer to destination state struct
> + * @old_state: pointer to source state struct
> + * @basename: name of the drm_*_state member of the new_state/old_state 
> struct
> + *
> + * Copies the data after the base struct until the end of the custom struct,
> + * e.g. given a structure
> + *
> + * struct foo_bar_state {
> + *   struct drm_bar_state base;
> + *   struct foo_private priv;
> + *   struct foo_private2 *priv2;
> + * };
> + *
> + * this copies priv and priv2. NB: the base struct *must* be the first 
> element
> + * of the derived struct, and new_state and old_state have to be two distinct
> + * instances.
> + */
> +#define drm_atomic_helper_duplicate_custom_state(new_state, old_state, 
> basename) \
> + do { \
> + size_t base_size = sizeof(new_state->basename); \
> + size_t base_offset = offsetof(typeof(*new_state), basename); \
> + \
> + BUILD_BUG_ON(base_offset != 0); \
> + if (new_state == old_state) /* Type-check */ \
> + break; \
> + memcpy((char *)new_state + base_size, \
> +(char *)old_state + base_size, \
> +sizeof(*new_state) - base_size); \
> + } while(0)
> +
> +/**
>   * drm_atomic_crtc_for_each_plane - iterate over planes currently attached 
> to CRTC
>   * @plane: the loop cursor
>   * @crtc:  the crtc whose planes are iterated
> -- 
> 1.9.1
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/2] drm: refernce count event->completion

[Daniel Vetter]

On Thu, Feb 09, 2017 at 04:39:29PM +0200, Jani Nikula wrote:
> On Wed, 04 Jan 2017, Daniel Vetter  wrote:
> > On Wed, Dec 21, 2016 at 12:08:45PM +0100, Maarten Lankhorst wrote:
> >> Op 21-12-16 om 11:36 schreef Chris Wilson:
> >> > On Wed, Dec 21, 2016 at 11:23:30AM +0100, Daniel Vetter wrote:
> >> >> When writing the generic nonblocking commit code I assumed that
> >> >> through clever lifetime management I can assure that the completion
> >> >> (stored in drm_crtc_commit) only gets freed after it is completed. And
> >> >> that worked.
> >> >>
> >> >> I also wanted to make nonblocking helpers resilient against driver
> >> >> bugs, by having timeouts everywhere. And that worked too.
> >> >>
> >> >> Unfortunately taking boths things together results in oopses :( Well,
> >> >> at least sometimes: What seems to happen is that the drm event hangs
> >> >> around forever stuck in limbo land. The nonblocking helpers eventually
> >> >> time out, move on and release it. Now the bug I tested all this
> >> >> against is drivers that just entirely fail to deliver the vblank
> >> >> events like they should, and in those cases the event is simply
> >> >> leaked. But what seems to happen, at least sometimes, on i915 is that
> >> >> the event is set up correctly, but somohow the vblank fails to fire in
> >> >> time. Which means the event isn't leaked, it's still there waiting for
> >> >> evevntually a vblank to fire. That tends to happen when re-enabling the
> >> >> pipe, and then the trap springs and the kernel oopses.
> >> >>
> >> >> The correct fix here is simply to refcount the crtc commit to make
> >> >> sure that the event sticks around even for drivers which only
> >> >> sometimes fail to deliver vblanks for some arbitrary reasons. Since
> >> >> crtc commits are already refcounted that's easy to do.
> >> > Or make the event a part of the atomic state?
> >> > -Chris
> >> >
> >> afaict crtc commit is already taken to wait for completion, so this patch 
> >> makes sense.
> >> 
> >> There's just a minor typo in the subject. :)
> >> Not sure that release_commit should be a function pointer, regardless..
> >> 
> >> Reviewed-by: Maarten Lankhorst 
> >
> > It didn't help the bug reporters against oopses (but the reporters are
> > supremely confusing, I have no idea what's really being tested, the
> > bugzilla is a mess), but I still think the patch is useful for more
> > robuestness, I dropped the cc: stable and applied it to drm-misc.
> 
> Agreed on the bug [1] being a mess. However, the bug has a reliable
> bisect result, the revert was posted by some of the reporters on the
> lists and in the bug, and now something that will not help anyone in
> v4.9 or v4.10 was pushed. :(

Latest report just says that the revert isn't helping either. I suspect
the report is a giantic conflagration of everything ever that kills
various reporters boxes. I still believe that the patch here fixes the
original bug, but there might be a lot more hiding.

It's at least seen quite a pile of testing, so I think it's sounds, and we
could cherry-pick it to dinf with cc: stable for 4.9+. Worst case it's not
going to help for the other problems.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC] drm: Helper macro for drm state duplication

[Liviu Dudau]

On Thu, Feb 09, 2017 at 05:57:04PM +0100, Daniel Vetter wrote:
> On Thu, Feb 09, 2017 at 03:41:41PM +, Mihail Atanassov wrote:
> > Hi,
> > 
> > I was working on a few patches adding fields to struct malidp_crtc_state and
> > found myself writing memcpy multiple times in the ->atomic_duplicate_state
> > hook because I wanted to avoid copying the drm_crtc_state twice
> > (__drm_atomic_helper_crtc_duplicate_state copies it already). I figured this
> > also applies to the other drm_*_state derivatives, so I concocted a macro
> > helper to do the copy in one chunk (two if you count the 
> > __drm_atomic_helper*
> > one). I'd appreciate some comments on whether anyone else might find this
> > macro useful. Thanks!
> > 
> > Mihail Atanassov (1):
> >   drm: Add helper macro for duplicating custom drm_*_state
> 
> I don't have your patch here, did something go wrong with the submission?
> Only the cover letter seems to have made it through ...

There is another patch that should come through, I can see it in my home 
account.

Liviu

> -Daniel
> 
> > 
> >  include/drm/drm_atomic_helper.h | 33 +
> >  1 file changed, 33 insertions(+)
> > 
> > -- 
> > Mihail Atanassov
> > 
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch

-- 

| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---
¯\_(ツ)_/¯
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm: Add helper macro for duplicating custom drm_*_state

[Mihail Atanassov]

Assuming a derived struct of the form:

struct foo_bar_state
{
struct drm_bar_state bar_state;
struct foo_private priv;
struct foo_private2 *priv2;
};

memcpy priv and priv2 to the new instance of foo_bar_state. The
intention is to use this macro in ->atomic_duplicate_state in conjunction with
__drm_atomic_helper_*_duplicate_state, which already copies the relevant
drm_*_state struct.

There's an equality check for new_state and old_state to ensure that
they are distinct instances of the same type, and a BUILD_BUG if the
base struct (bar_state in the above example) is not first in the derived
struct, to avoid missing any data before it and corrupting the base's data.

Signed-off-by: Mihail Atanassov 
---
 include/drm/drm_atomic_helper.h | 33 +
 1 file changed, 33 insertions(+)

diff --git a/include/drm/drm_atomic_helper.h b/include/drm/drm_atomic_helper.h
index d066e94..ecc6a82 100644
--- a/include/drm/drm_atomic_helper.h
+++ b/include/drm/drm_atomic_helper.h
@@ -171,6 +171,39 @@ int drm_atomic_helper_legacy_gamma_set(struct drm_crtc 
*crtc,
   uint32_t size);
 
 /**
+ * drm_atomic_duplicate_custom_state - helper macro for duplicating
+ * driver-private additions to drm_*_state.
+ * @new_state: pointer to destination state struct
+ * @old_state: pointer to source state struct
+ * @basename: name of the drm_*_state member of the new_state/old_state struct
+ *
+ * Copies the data after the base struct until the end of the custom struct,
+ * e.g. given a structure
+ *
+ * struct foo_bar_state {
+ * struct drm_bar_state base;
+ * struct foo_private priv;
+ * struct foo_private2 *priv2;
+ * };
+ *
+ * this copies priv and priv2. NB: the base struct *must* be the first element
+ * of the derived struct, and new_state and old_state have to be two distinct
+ * instances.
+ */
+#define drm_atomic_helper_duplicate_custom_state(new_state, old_state, 
basename) \
+   do { \
+   size_t base_size = sizeof(new_state->basename); \
+   size_t base_offset = offsetof(typeof(*new_state), basename); \
+   \
+   BUILD_BUG_ON(base_offset != 0); \
+   if (new_state == old_state) /* Type-check */ \
+   break; \
+   memcpy((char *)new_state + base_size, \
+  (char *)old_state + base_size, \
+  sizeof(*new_state) - base_size); \
+   } while(0)
+
+/**
  * drm_atomic_crtc_for_each_plane - iterate over planes currently attached to 
CRTC
  * @plane: the loop cursor
  * @crtc:  the crtc whose planes are iterated
-- 
1.9.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/vc4: Drop debug print at boot with DPI enabled.

[Daniel Vetter]

On Wed, Feb 08, 2017 at 12:47:01PM -0800, Eric Anholt wrote:
> Unlike the other encoders in the driver, I've also dropped the debug
> dump function.  There's only really one register to this device, and
> we have the debugfs reg entry still.
> 
> Signed-off-by: Eric Anholt 

Yeah, dmesg spew by default isn't cool. Btw if you ever want to have fancy
debug printers, there's drm_printer, which allows you to spam both dmesg
and debugfs with the same code. Rob did that, I recently converted drm_mm,
it's pretty cool.

Acked-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/vc4/vc4_dpi.c | 13 -
>  1 file changed, 13 deletions(-)
> 
> diff --git a/drivers/gpu/drm/vc4/vc4_dpi.c b/drivers/gpu/drm/vc4/vc4_dpi.c
> index 1e1f6b8184d0..3f360cf6cf5a 100644
> --- a/drivers/gpu/drm/vc4/vc4_dpi.c
> +++ b/drivers/gpu/drm/vc4/vc4_dpi.c
> @@ -144,17 +144,6 @@ static const struct {
>   DPI_REG(DPI_ID),
>  };
>  
> -static void vc4_dpi_dump_regs(struct vc4_dpi *dpi)
> -{
> - int i;
> -
> - for (i = 0; i < ARRAY_SIZE(dpi_regs); i++) {
> - DRM_INFO("0x%04x (%s): 0x%08x\n",
> -  dpi_regs[i].reg, dpi_regs[i].name,
> -  DPI_READ(dpi_regs[i].reg));
> - }
> -}
> -
>  #ifdef CONFIG_DEBUG_FS
>  int vc4_dpi_debugfs_regs(struct seq_file *m, void *unused)
>  {
> @@ -416,8 +405,6 @@ static int vc4_dpi_bind(struct device *dev, struct device 
> *master, void *data)
>   if (IS_ERR(dpi->regs))
>   return PTR_ERR(dpi->regs);
>  
> - vc4_dpi_dump_regs(dpi);
> -
>   if (DPI_READ(DPI_ID) != DPI_ID_VALUE) {
>   dev_err(dev, "Port returned 0x%08x for ID instead of 0x%08x\n",
>   DPI_READ(DPI_ID), DPI_ID_VALUE);
> -- 
> 2.11.0
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 99476] Forcing perf level to high doesn't change memory clock

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=99476

--- Comment #1 from Alex Deucher  ---
Does the firmware here help?
https://people.freedesktop.org/~agd5f/radeon_ucode/polaris/

-- 
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 0/6] drm: Introduce consistent reference counting APIs

[Daniel Vetter]

On Thu, Feb 09, 2017 at 04:10:12PM +0200, Jani Nikula wrote:
> On Wed, 08 Feb 2017, Thierry Reding  wrote:
> > This series introduces DRM reference counting APIs that are consistent
> > with other reference counting APIs in the kernel. They are also much
> > shorter. Compatibility aliases are added to keep existing code working
> > and will stay in place until all users of the old APIs are gone.
> 
> I like it.
> 
> But it makes drm_connector_list_iter_{get,put} stick out like a sore
> thumb. Something for the TODO list I guess.

Hm, why is that one the sore thumb now? Just because it's really long? It
does acquire/drop references behind the scenes, that's why I went with the
_get/put postfixes ...
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/6] drm: Introduce drm_mode_object_{get,put}()

[Daniel Vetter]

On Wed, Feb 08, 2017 at 02:28:14PM -0500, Sean Paul wrote:
> On Wed, Feb 08, 2017 at 07:24:04PM +0100, Thierry Reding wrote:
> > From: Thierry Reding 
> > 
> > For consistency with other reference counting APIs in the kernel, add
> > drm_mode_object_get() and drm_mode_object_put() to reference count DRM
> > mode objects.
> > 
> > Compatibility aliases are added to keep existing code working. To help
> > speed up the transition, all the instances of the old functions in the
> > DRM core are already replaced in this commit.
> > 
> 
> drm code looks good and is 
> 
> Reviewed-by: Sean Paul 
> 
> > A semantic patch is provided that can be used to convert all drivers to
> > the new helpers.
> 
> I'm not convinced we need to commit the cocci patch. I think including it in
> your cover letter and then following up with a follow on series to actually 
> make
> the change is sufficient (See: ickle's s/fence/dma_fence/ series).

Yeah, if you do a large-scale refactor anyway, I think it's best to just
store the cocci in the commit message. I think storing the cocci is ok if
you have thousands of hits among lots of subsystems, and it's clear it's
going to take at least a few release cycles or maybe even years to clean
it all up. drm is luckily not yet that big :-)

I'll drop this while applying if no one minds ...
-Daniel

> 
> Sean
> 
> > 
> > Signed-off-by: Thierry Reding 
> > ---
> >  drivers/gpu/drm/drm_atomic.c | 14 +--
> >  drivers/gpu/drm/drm_mode_object.c| 26 ++--
> >  drivers/gpu/drm/drm_property.c   |  6 ++---
> >  include/drm/drm_mode_object.h| 36 ++-
> >  scripts/coccinelle/api/drm-get-put.cocci | 42 
> > 
> >  5 files changed, 95 insertions(+), 29 deletions(-)
> >  create mode 100644 scripts/coccinelle/api/drm-get-put.cocci
> > 
> > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > index a5673107db26..2bb0a759e8ec 100644
> > --- a/drivers/gpu/drm/drm_atomic.c
> > +++ b/drivers/gpu/drm/drm_atomic.c
> > @@ -2122,13 +2122,13 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
> > }
> >  
> > if (!obj->properties) {
> > -   drm_mode_object_unreference(obj);
> > +   drm_mode_object_put(obj);
> > ret = -ENOENT;
> > goto out;
> > }
> >  
> > if (get_user(count_props, count_props_ptr + copied_objs)) {
> > -   drm_mode_object_unreference(obj);
> > +   drm_mode_object_put(obj);
> > ret = -EFAULT;
> > goto out;
> > }
> > @@ -2141,14 +2141,14 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
> > struct drm_property *prop;
> >  
> > if (get_user(prop_id, props_ptr + copied_props)) {
> > -   drm_mode_object_unreference(obj);
> > +   drm_mode_object_put(obj);
> > ret = -EFAULT;
> > goto out;
> > }
> >  
> > prop = drm_mode_obj_find_prop_id(obj, prop_id);
> > if (!prop) {
> > -   drm_mode_object_unreference(obj);
> > +   drm_mode_object_put(obj);
> > ret = -ENOENT;
> > goto out;
> > }
> > @@ -2156,14 +2156,14 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
> > if (copy_from_user(_value,
> >prop_values_ptr + copied_props,
> >sizeof(prop_value))) {
> > -   drm_mode_object_unreference(obj);
> > +   drm_mode_object_put(obj);
> > ret = -EFAULT;
> > goto out;
> > }
> >  
> > ret = atomic_set_prop(state, obj, prop, prop_value);
> > if (ret) {
> > -   drm_mode_object_unreference(obj);
> > +   drm_mode_object_put(obj);
> > goto out;
> > }
> >  
> > @@ -2176,7 +2176,7 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
> > plane_mask |= (1 << drm_plane_index(plane));
> > plane->old_fb = plane->fb;
> > }
> > -   drm_mode_object_unreference(obj);
> > +   drm_mode_object_put(obj);
> > }
> >  
> > ret = prepare_crtc_signaling(dev, state, arg, file_priv, _state,
> > diff --git a/drivers/gpu/drm/drm_mode_object.c 
> > b/drivers/gpu/drm/drm_mode_object.c
> > index 3b405dbf1b8d..da9a9adbcc98 100644
> > --- a/drivers/gpu/drm/drm_mode_object.c
> > +++ 

Re: [PATCH v2 1/2] drm/cma-helper: Add multi buffer support for cma fbdev

[Daniel Vetter]

On Thu, Feb 02, 2017 at 11:31:56AM +0100, Maxime Ripard wrote:
> From: Xinliang Liu 
> 
> This patch add a config to support to create multi buffer for cma fbdev.
> Such as double buffer and triple buffer.
> 
> Cma fbdev is convient to add a legency fbdev. And still many Android
> devices use fbdev now and at least double buffer is needed for these
> Android devices, so that a buffer flip can be operated. It will need
> some time for Android device vendors to abondon legency fbdev. So multi
> buffer for fbdev is needed.
> 
> Signed-off-by: Xinliang Liu 
> [s.chr...@phytec.de: Picking patch from
>  https://lkml.org/lkml/2015/9/14/188]
> Signed-off-by: Stefan Christ 
> Signed-off-by: Maxime Ripard 
> ---
>  drivers/gpu/drm/Kconfig | 8 
>  drivers/gpu/drm/drm_fb_cma_helper.c | 8 +++-
>  2 files changed, 15 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index ebfe8404c25f..2ca9bb26a4e4 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -121,6 +121,14 @@ config DRM_KMS_CMA_HELPER
>   help
> Choose this if you need the KMS CMA helper functions
>  
> +config DRM_CMA_FBDEV_BUFFER_NUM
> + int "Cma Fbdev Buffer Number"
> + depends on DRM_KMS_CMA_HELPER
> + default 1
> + help
> +   Defines the buffer number of cma fbdev.  Default is one buffer.
> +   For double buffer please set to 2 and 3 for triple buffer.
> +
>  source "drivers/gpu/drm/i2c/Kconfig"
>  
>  source "drivers/gpu/drm/arm/Kconfig"
> diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c 
> b/drivers/gpu/drm/drm_fb_cma_helper.c
> index 81b3558302b5..e3f8b9e720a0 100644
> --- a/drivers/gpu/drm/drm_fb_cma_helper.c
> +++ b/drivers/gpu/drm/drm_fb_cma_helper.c
> @@ -411,6 +411,12 @@ static void drm_fbdev_cma_defio_fini(struct fb_info *fbi)
>   kfree(fbi->fbops);
>  }
>  
> +static int fbdev_num_buffers = CONFIG_DRM_CMA_FBDEV_BUFFER_NUM;
> +module_param(fbdev_num_buffers, int, 0444);
> +MODULE_PARM_DESC(fbdev_num_buffers,
> +  "Number of frame buffers to allocate [default="
> +  __MODULE_STRING(CONFIG_DRM_CMA_FBDEV_BUFFER_NUM) "]");

Pure bikshed: Should this be an overallocation %? 200 for
double-buffering, 100 as the default?

Slightly less bikesheddy: Can't we do this in the core helpers somehow?
I'd be nice if this is not cma specific. If it's not possible, I'd at
least move the symbol to drm_fb_helper.c, and add some kernel-doc around
it. That allows any other non-cma driver to at least implement support for
this. That also has the benefit of featuring it more prominently, in our
docs.

Besides these bikesheds/question, looks all reasonable to me. If you can
get some more acks would be great, but will merge anyway.
-Daniel

> +
>  /*
>   * For use in a (struct drm_fb_helper_funcs *)->fb_probe callback function 
> that
>   * needs custom struct drm_framebuffer_funcs, like dirty() for deferred_io 
> use.
> @@ -437,7 +443,7 @@ int drm_fbdev_cma_create_with_funcs(struct drm_fb_helper 
> *helper,
>   bytes_per_pixel = DIV_ROUND_UP(sizes->surface_bpp, 8);
>  
>   mode_cmd.width = sizes->surface_width;
> - mode_cmd.height = sizes->surface_height;
> + mode_cmd.height = sizes->surface_height * fbdev_num_buffers;
>   mode_cmd.pitches[0] = sizes->surface_width * bytes_per_pixel;
>   mode_cmd.pixel_format = drm_mode_legacy_fb_format(sizes->surface_bpp,
>   sizes->surface_depth);
> -- 
> git-series 0.8.11
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 2/2] drm/fb_helper: implement ioctl FBIO_WAITFORVSYNC

[Daniel Vetter]

On Thu, Feb 02, 2017 at 11:31:57AM +0100, Maxime Ripard wrote:
> From: Stefan Christ 
> 
> Implement legacy framebuffer ioctl FBIO_WAITFORVSYNC in the generic
> framebuffer emulation driver. Legacy framebuffer users like non kms/drm
> based OpenGL(ES)/EGL implementations may require the ioctl to
> synchronize drawing or buffer flip for double buffering. It is tested on
> the i.MX6.
> 
> Code is based on
> 
> https://github.com/Xilinx/linux-xlnx/blob/master/drivers/gpu/drm/xilinx/xilinx_drm_fb.c#L196
> 
> Signed-off-by: Stefan Christ 
> Signed-off-by: Maxime Ripard 
> ---
>  drivers/gpu/drm/drm_fb_helper.c | 55 ++-
>  include/drm/drm_fb_helper.h |  5 ++-
>  2 files changed, 59 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index e934b541feea..39a3532e311c 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -1234,6 +1234,61 @@ int drm_fb_helper_setcmap(struct fb_cmap *cmap, struct 
> fb_info *info)
>  EXPORT_SYMBOL(drm_fb_helper_setcmap);
>  
>  /**
> + * drm_fb_helper_ioctl - legacy ioctl implementation
> + * @info: fbdev registered by the helper
> + * @cmd: ioctl command
> + * @arg: ioctl argument
> + *
> + * A helper to implement the standard fbdev ioctl. Only
> + * FBIO_WAITFORVSYNC is implemented for now.
> + */
> +int drm_fb_helper_ioctl(struct fb_info *info, unsigned int cmd, unsigned 
> long arg)
> +{
> + struct drm_fb_helper *fb_helper = info->par;
> + struct drm_device *dev = fb_helper->dev;
> + unsigned int i;
> + int ret = 0;
> +
> + drm_modeset_lock_all(dev);
> + if (!drm_fb_helper_is_bound(fb_helper)) {
> + drm_modeset_unlock_all(dev);
> + return -EBUSY;
> + }
> +
> + switch (cmd) {
> + case FBIO_WAITFORVSYNC:
> + for (i = 0; i < fb_helper->crtc_count; i++) {
> + struct drm_mode_set *mode_set;
> + struct drm_crtc *crtc;
> +
> + mode_set = _helper->crtc_info[i].mode_set;
> + crtc = mode_set->crtc;
> +
> + /*
> +  * Only call drm_crtc_wait_one_vblank for crtcs that
> +  * are currently enabled.
> +  */
> + if (!crtc->enabled)
> + continue;

This needs locking, and the interface spec for vblank_get says you'll get
an -EINVAL if the pipe is off. I'd say drop this, and instead eat the
-EINVAL from vblank_get and explain in a comment why you do that.

The trouble is that ->enabled is legacy state, atomic drivers don't need
to update it (helpers do it by default, but only for transition reasons),
and it's not synchronized to the real state changes at all. vblank_get
otoh is.

Otherwise lgtm.
-Daniel

> +
> + ret = drm_crtc_vblank_get(crtc);
> + if (!ret) {
> + drm_crtc_wait_one_vblank(crtc);
> + drm_crtc_vblank_put(crtc);
> + }
> + }
> + goto unlock;
> + default:
> + ret = -ENOTTY;
> + }
> +
> +unlock:
> + drm_modeset_unlock_all(dev);
> + return ret;
> +}
> +EXPORT_SYMBOL(drm_fb_helper_ioctl);
> +
> +/**
>   * drm_fb_helper_check_var - implementation for ->fb_check_var
>   * @var: screeninfo to check
>   * @info: fbdev registered by the helper
> diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
> index 975deedd593e..460be9d9fa98 100644
> --- a/include/drm/drm_fb_helper.h
> +++ b/include/drm/drm_fb_helper.h
> @@ -230,7 +230,8 @@ struct drm_fb_helper {
>   .fb_blank   = drm_fb_helper_blank, \
>   .fb_pan_display = drm_fb_helper_pan_display, \
>   .fb_debug_enter = drm_fb_helper_debug_enter, \
> - .fb_debug_leave = drm_fb_helper_debug_leave
> + .fb_debug_leave = drm_fb_helper_debug_leave, \
> + .fb_ioctl   = drm_fb_helper_ioctl
>  
>  #ifdef CONFIG_DRM_FBDEV_EMULATION
>  void drm_fb_helper_prepare(struct drm_device *dev, struct drm_fb_helper 
> *helper,
> @@ -286,6 +287,8 @@ void drm_fb_helper_set_suspend_unlocked(struct 
> drm_fb_helper *fb_helper,
>  
>  int drm_fb_helper_setcmap(struct fb_cmap *cmap, struct fb_info *info);
>  
> +int drm_fb_helper_ioctl(struct fb_info *info, unsigned int cmd, unsigned 
> long arg);
> +
>  int drm_fb_helper_hotplug_event(struct drm_fb_helper *fb_helper);
>  int drm_fb_helper_initial_config(struct drm_fb_helper *fb_helper, int 
> bpp_sel);
>  int drm_fb_helper_single_add_all_connectors(struct drm_fb_helper *fb_helper);
> -- 
> git-series 0.8.11
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel 

Re: [RFC] drm: Helper macro for drm state duplication

[Daniel Vetter]

On Thu, Feb 09, 2017 at 03:41:41PM +, Mihail Atanassov wrote:
> Hi,
> 
> I was working on a few patches adding fields to struct malidp_crtc_state and
> found myself writing memcpy multiple times in the ->atomic_duplicate_state
> hook because I wanted to avoid copying the drm_crtc_state twice
> (__drm_atomic_helper_crtc_duplicate_state copies it already). I figured this
> also applies to the other drm_*_state derivatives, so I concocted a macro
> helper to do the copy in one chunk (two if you count the __drm_atomic_helper*
> one). I'd appreciate some comments on whether anyone else might find this
> macro useful. Thanks!
> 
> Mihail Atanassov (1):
>   drm: Add helper macro for duplicating custom drm_*_state

I don't have your patch here, did something go wrong with the submission?
Only the cover letter seems to have made it through ...
-Daniel

> 
>  include/drm/drm_atomic_helper.h | 33 +
>  1 file changed, 33 insertions(+)
> 
> -- 
> Mihail Atanassov
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 6/8] dt-bindings: gpu: mali: Add optional OPPs

[Maxime Ripard]

The operating-points-v2 binding gives a way to provide the OPP of the GPU.
Let's use it.

Signed-off-by: Maxime Ripard 
---
 Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt | 4 
 1 file changed, 4 insertions(+), 0 deletions(-)

diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt 
b/Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt
index 88df4a276607..2b6243e730f6 100644
--- a/Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt
+++ b/Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt
@@ -39,6 +39,10 @@ Optional properties:
 Memory region to allocate from, as defined in
 Documentation/devicetree/bindi/reserved-memory/reserved-memory.txt
 
+  - operating-points-v2:
+Operating Points for the GPU, as defined in
+Documentation/devicetree/bindings/opp/opp.txt
+
 Vendor-specific bindings
 
 
-- 
git-series 0.8.11
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 4/8] drm/sun4i: Grab reserved memory region

[Maxime Ripard]

Allow to provide an optional memory region to allocate from for our DRM
driver.

Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/sun4i/sun4i_drv.c | 19 ++-
 1 file changed, 14 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c 
b/drivers/gpu/drm/sun4i/sun4i_drv.c
index 4ce665349f6b..7ed7a159c9c1 100644
--- a/drivers/gpu/drm/sun4i/sun4i_drv.c
+++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
@@ -12,6 +12,7 @@
 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -133,10 +134,16 @@ static int sun4i_drv_bind(struct device *dev)
drm_vblank_init(drm, 1);
drm_mode_config_init(drm);
 
+   ret = of_reserved_mem_device_init(dev);
+   if (ret && ret != -ENODEV) {
+   dev_err(drm->dev, "Couldn't claim our memory region\n");
+   goto free_drm;
+   }
+
ret = component_bind_all(drm->dev, drm);
if (ret) {
dev_err(drm->dev, "Couldn't bind all pipelines components\n");
-   goto free_drm;
+   goto free_mem_region;
}
 
/* Create our layers */
@@ -144,7 +151,7 @@ static int sun4i_drv_bind(struct device *dev)
if (IS_ERR(drv->layers)) {
dev_err(drm->dev, "Couldn't create the planes\n");
ret = PTR_ERR(drv->layers);
-   goto free_drm;
+   goto free_mem_region;
}
 
/* Create our CRTC */
@@ -152,7 +159,7 @@ static int sun4i_drv_bind(struct device *dev)
if (!drv->crtc) {
dev_err(drm->dev, "Couldn't create the CRTC\n");
ret = -EINVAL;
-   goto free_drm;
+   goto free_mem_region;
}
drm->irq_enabled = true;
 
@@ -164,7 +171,7 @@ static int sun4i_drv_bind(struct device *dev)
if (IS_ERR(drv->fbdev)) {
dev_err(drm->dev, "Couldn't create our framebuffer\n");
ret = PTR_ERR(drv->fbdev);
-   goto free_drm;
+   goto free_mem_region;
}
 
/* Enable connectors polling */
@@ -172,10 +179,12 @@ static int sun4i_drv_bind(struct device *dev)
 
ret = drm_dev_register(drm, 0);
if (ret)
-   goto free_drm;
+   goto free_mem_region;
 
return 0;
 
+free_mem_region:
+   of_reserved_mem_device_release(dev);
 free_drm:
drm_dev_unref(drm);
return ret;
-- 
git-series 0.8.11
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 3/8] mm: cma: Export a few symbols

[Maxime Ripard]

Modules might want to check their CMA pool size and address for debugging
and / or have additional checks.

The obvious way to do this would be through dev_get_cma_area and
cma_get_base and cma_get_size, that are currently not exported, which
results in a build failure.

Export them to prevent such a failure.

Signed-off-by: Maxime Ripard 
---
 drivers/base/dma-contiguous.c | 1 +
 mm/cma.c  | 2 ++
 2 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/drivers/base/dma-contiguous.c b/drivers/base/dma-contiguous.c
index e167a1e1bccb..60f5c2591ccd 100644
--- a/drivers/base/dma-contiguous.c
+++ b/drivers/base/dma-contiguous.c
@@ -35,6 +35,7 @@
 #endif
 
 struct cma *dma_contiguous_default_area;
+EXPORT_SYMBOL(dma_contiguous_default_area);
 
 /*
  * Default global CMA area size can be defined in kernel's .config.
diff --git a/mm/cma.c b/mm/cma.c
index c960459eda7e..b50245282a18 100644
--- a/mm/cma.c
+++ b/mm/cma.c
@@ -47,11 +47,13 @@ phys_addr_t cma_get_base(const struct cma *cma)
 {
return PFN_PHYS(cma->base_pfn);
 }
+EXPORT_SYMBOL(cma_get_base);
 
 unsigned long cma_get_size(const struct cma *cma)
 {
return cma->count << PAGE_SHIFT;
 }
+EXPORT_SYMBOL(cma_get_size);
 
 static unsigned long cma_bitmap_aligned_mask(const struct cma *cma,
 int align_order)
-- 
git-series 0.8.11
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 8/8] ARM: sun8i: a33: Add the Mali OPPs

[Maxime Ripard]

The Mali GPU in the A33 has various operating frequencies used in the
Allwinner BSP.

Add them to our DT.

Signed-off-by: Maxime Ripard 
---
 arch/arm/boot/dts/sun8i-a33.dtsi | 17 +
 1 file changed, 17 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/sun8i-a33.dtsi b/arch/arm/boot/dts/sun8i-a33.dtsi
index 043b1b017276..e1b0abfee42f 100644
--- a/arch/arm/boot/dts/sun8i-a33.dtsi
+++ b/arch/arm/boot/dts/sun8i-a33.dtsi
@@ -101,6 +101,22 @@
status = "disabled";
};
 
+   mali_opp_table: opp_table1 {
+   compatible = "operating-points-v2";
+
+   opp@14400 {
+   opp-hz = /bits/ 64 <14400>;
+   };
+
+   opp@24000 {
+   opp-hz = /bits/ 64 <24000>;
+   };
+
+   opp@38400 {
+   opp-hz = /bits/ 64 <38400>;
+   };
+   };
+
memory {
reg = <0x4000 0x8000>;
};
@@ -282,6 +298,7 @@
 
  {
memory-region = <_pool>;
+   operating-points-v2 = <_opp_table>;
 };
 
  {
-- 
git-series 0.8.11
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel