Re: [PATCH v2 1/2] drm: bridge: sil902x

[Archit Taneja]

On 01/06/2016 05:55 PM, Boris Brezillon wrote:

Add basic support for the sil902x RGB -> HDMI bridge.
This driver does not support audio output yet.

Signed-off-by: Boris Brezillon 
---
Hello,

This patch is only adding basic support for the sil9022 chip.
As stated in the commit log, there's no audio support, but the
driver also hardcodes a lot of things (like the RGB input format to
use).
There are two reasons for this:
1/ the DRM framework does not allow for advanced link description
between an encoder and a bridge (that's for the RGB format
limitation). Any idea how this should be described?


The adv7511 driver uses a DT param "input_colorspace" to chose between
RGB or YUV. I don't think DT is the best idea, but I don't know of a
better way either.

The connector's display_info.color_formats field gives us some info
about the color formats supported by the monitor, but I guess that
isn't sufficient data to know what format the encoder is pushing out.

We get around this problem in case the case of DSI encoders by using
the mipi_dsi_device api, where a DSI based bridge or panel can pass
color format/lane info to the DSI host (i.e, encoder) by using
mipi_dsi_attach().




2/ I don't have the datasheet of this HDMI encoder, and all logic
has been extracted from those two drivers [1][2], which means
I may miss some important things in my encoder setup.

Another thing I find weird in the drm_bridge interface is the fact
that we have a ->attach() method, but no ->detach(), which can be
a problem if we allow drm bridges and KMS drivers to be compiled as
modules. Any reason for that?


I guess the drm_bridge_add/remove ops make can ensure that the bridge
driver itself can be compiled as a module. However, you're right that
we would need a bridge detach op that the kms driver should call
before it is removed (to unregister the connector we created).

Someone would still need to make sure about the order in which the
modules are removed. If the bridge driver is removed first, then
it would really mess up the kms driver using the bridge.


Would the kms driver using this chip really have an encoder?
Since the chip takes in RGB input, I'm assuming that the encoder in
the kms driver would more or less be nop funcs, giving their way to
bridge ops.

In such cases, I think the bridge still doesn't fit in so well. The
best fit here is how the current tda998x driver is modeled. It adds
itself as a component that creates both an encoder and connector,
which the kms driver can use directly. This approach, of course,
prevents us using tda998x in kms drivers that don't accept any
encoders that it didn't create itself.

Thanks,
Archit



That's all for the questions part :-).

Best Regards,

Boris

Changes in v2:
- fix errors reported by kbuild test robot

---
  drivers/gpu/drm/bridge/Kconfig   |   8 +
  drivers/gpu/drm/bridge/Makefile  |   1 +
  drivers/gpu/drm/bridge/sil902x.c | 491 +++
  3 files changed, 500 insertions(+)
  create mode 100644 drivers/gpu/drm/bridge/sil902x.c

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 27e2022..9701fd2 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -40,4 +40,12 @@ config DRM_PARADE_PS8622
---help---
  Parade eDP-LVDS bridge chip driver.

+config DRM_SIL902X
+   tristate "Silicon Image sil902x RGB/HDMI bridge"
+   depends on OF
+   select DRM_KMS_HELPER
+   select REGMAP_I2C
+   ---help---
+ Silicon Image sil902x bridge chip driver.
+
  endmenu
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index f13c33d..a689aad 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -4,3 +4,4 @@ obj-$(CONFIG_DRM_DW_HDMI) += dw-hdmi.o
  obj-$(CONFIG_DRM_DW_HDMI_AHB_AUDIO) += dw-hdmi-ahb-audio.o
  obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
  obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
+obj-$(CONFIG_DRM_SIL902X) += sil902x.o
diff --git a/drivers/gpu/drm/bridge/sil902x.c b/drivers/gpu/drm/bridge/sil902x.c
new file mode 100644
index 000..2657031
--- /dev/null
+++ b/drivers/gpu/drm/bridge/sil902x.c
@@ -0,0 +1,491 @@
+/*
+ * Copyright (C) 2014 Atmel
+ *   Bo Shen 
+ *
+ * Authors:  Bo Shen 
+ *   Boris Brezillon 
+ *   Wu, Songjun 
+ *
+ *
+ * Copyright (C) 2010-2011 Freescale Semiconductor, Inc. All Rights Reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for m

[PATCH v5 3/3] dt/bindings: qcom_nandc: Add DT bindings

[Archit Taneja]

Add DT bindings document for the Qualcomm NAND controller driver.

Cc: devicetree@vger.kernel.org
Cc: Rob Herring 
Signed-off-by: Archit Taneja 
---
v5:
- Make changes to incorporate chip select sub nodes (brcmnand taken as
  reference)

v3:
- Don't use '0x' when specifying nand controller address space
- Add optional property for on-flash bbt usage

 .../devicetree/bindings/mtd/qcom_nandc.txt | 84 ++
 1 file changed, 84 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mtd/qcom_nandc.txt

diff --git a/Documentation/devicetree/bindings/mtd/qcom_nandc.txt 
b/Documentation/devicetree/bindings/mtd/qcom_nandc.txt
new file mode 100644
index 000..b2cf2d9
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/qcom_nandc.txt
@@ -0,0 +1,84 @@
+* Qualcomm NAND controller
+
+Required properties:
+- compatible:  should be "qcom,ebi2-nand" for IPQ806x
+- reg: MMIO address range
+- clocks:  must contain core clock and always on clock
+- clock-names: must contain "core" for the core clock and "aon" for the
+   always on clock
+- dmas:DMA specifier, consisting of a phandle to the 
ADM DMA
+   controller node and the channel number to be used for
+   NAND. Refer to dma.txt and qcom_adm.txt for more details
+- dma-names:   must be "rxtx"
+- qcom,cmd-crci:   must contain the ADM command type CRCI block instance
+   number specified for the NAND controller on the given
+   platform
+- qcom,data-crci:  must contain the ADM data type CRCI block instance
+   number specified for the NAND controller on the given
+   platform
+- #address-cells:  <1> - subnodes give the chip-select number
+- #size-cells: <0>
+
+* NAND chip-select
+
+Each controller may contain one or more subnodes to represent enabled
+chip-selects which (may) contain NAND flash chips. Their properties are as
+follows.
+
+Required properties:
+- compatible:  should contain "qcom,nandcs"
+- reg: a single integer representing the chip-select
+   number (e.g., 0, 1, 2, etc.)
+- #address-cells:  see partition.txt
+- #size-cells: see partition.txt
+- nand-ecc-strength:   number of bits to correct per ECC step. Must be 4 or 8
+   bits.
+- nand-ecc-step-size:  bytes of data per ECC step. Must be 512.
+
+Optional properties:
+- nand-bus-width:  bus width. Must be 8 or 16. If not present, 8 is chosen
+   as default
+
+Each nandcs device node may optionally contain sub-nodes describing the flash
+partition mapping. See partition.txt for more detail.
+
+Example:
+
+nand@1ac0 {
+   compatible = "qcom,ebi2-nandc";
+   reg = <0x1ac0 0x800>;
+
+   clocks = <&gcc EBI2_CLK>,
+<&gcc EBI2_AON_CLK>;
+   clock-names = "core", "aon";
+
+   dmas = <&adm_dma 3>;
+   dma-names = "rxtx";
+   qcom,cmd-crci = <15>;
+   qcom,data-crci = <3>;
+
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   nandcs@0 {
+   compatible = "qcom,nandcs";
+   reg = <0>;
+
+   nand-ecc-strength = <4>;
+   nand-ecc-step-size = <512>;
+   nand-bus-width = <8>;
+
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   partition@0 {
+   label = "boot-nand";
+   reg = <0 0x58a>;
+   };
+
+   partition@58a {
+   label = "fs-nand";
+   reg = <0x58a 0x400>;
+   };
+   };
+};
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 3/5] dt/bindings: qcom_nandc: Add DT bindings

[Archit Taneja]

Hi Boris,

On 12/16/2015 12:03 PM, Boris Brezillon wrote:

Hi Archit,

Sorry for the late review, but there are a few things I think should be
addressed.

On Wed, 19 Aug 2015 10:19:04 +0530
Archit Taneja  wrote:


Add DT bindings document for the Qualcomm NAND controller driver.

Cc: devicetree@vger.kernel.org

v4:
- No changes

v3:
- Don't use '0x' when specifying nand controller address space
- Add optional property for on-flash bbt usage

Acked-by: Andy Gross 
Signed-off-by: Archit Taneja 
---
  .../devicetree/bindings/mtd/qcom_nandc.txt | 49 ++
  1 file changed, 49 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/mtd/qcom_nandc.txt

diff --git a/Documentation/devicetree/bindings/mtd/qcom_nandc.txt 
b/Documentation/devicetree/bindings/mtd/qcom_nandc.txt
new file mode 100644
index 000..1de4643
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/qcom_nandc.txt
@@ -0,0 +1,49 @@
+* Qualcomm NAND controller
+
+Required properties:
+- compatible:  should be "qcom,ebi2-nand" for IPQ806x
+- reg: MMIO address range
+- clocks:  must contain core clock and always on clock
+- clock-names: must contain "core" for the core clock and "aon" for the
+   always on clock
+- dmas:DMA specifier, consisting of a phandle to the 
ADM DMA
+   controller node and the channel number to be used for
+   NAND. Refer to dma.txt and qcom_adm.txt for more details
+- dma-names:   must be "rxtx"
+- qcom,cmd-crci:   must contain the ADM command type CRCI block instance
+   number specified for the NAND controller on the given
+   platform
+- qcom,data-crci:  must contain the ADM data type CRCI block instance
+   number specified for the NAND controller on the given
+   platform
+
+Optional properties:
+- nand-bus-width:  bus width. Must be 8 or 16. If not present, 8 is chosen
+   as default
+
+- nand-ecc-strength:   number of bits to correct per ECC step. Must be 4 or 8
+   bits. If not present, 4 is chosen as default
+- nand-on-flash-bbt:   Create/use on-flash bad block table
+
+The device tree may optionally contain sub-nodes describing partitions of the
+address space. See partition.txt for more detail.
+
+Example:
+
+nand@1ac0 {
+   compatible = "qcom,ebi2-nandc";
+   reg = <0x1ac0 0x800>;
+
+   clocks = <&gcc EBI2_CLK>,
+<&gcc EBI2_AON_CLK>;
+   clock-names = "core", "aon";
+
+   dmas = <&adm_dma 3>;
+   dma-names = "rxtx";
+   qcom,cmd-crci = <15>;
+   qcom,data-crci = <3>;
+
+   partition@0 {
+   ...
+   };
+};



According to the registers layout defined in your driver, your NAND
controller can address multiple chips (NAND_DEV_SEL register). Since DT
bindings are supposed to be as stable as possible, I would recommend
separating the NAND controller and NAND chip declaration (as done here
[1] and here [2]).


Yes, the controller does support multiple chips, but the driver only
supports one chip for now.

I'll make changes such that the driver works in accordance to the DT
bindings format you shared.

Thanks for the review.

Archit




Best Regards,

Boris

[1]http://lxr.free-electrons.com/source/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt
[2]http://lxr.free-electrons.com/source/Documentation/devicetree/bindings/mtd/sunxi-nand.txt




--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora 
Forum, hosted by The Linux Foundation

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v6 2/2] drm/bridge: Add I2C based driver for ps8640 bridge

[Archit Taneja]

Hi,

On 12/15/2015 09:00 AM, Jitao Shi wrote:

This patch adds drm_bridge driver for parade DSI to eDP bridge chip.

Signed-off-by: Jitao Shi 
---
Changes since v5
-fix compile errors when CONFIG_GPIOLIB=n
---
  drivers/gpu/drm/bridge/Kconfig |   10 +
  drivers/gpu/drm/bridge/Makefile|1 +
  drivers/gpu/drm/bridge/parade-ps8640.c |  472 
  3 files changed, 483 insertions(+)
  create mode 100644 drivers/gpu/drm/bridge/parade-ps8640.c

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 639..dcfdbc9 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -41,4 +41,14 @@ config DRM_PARADE_PS8622
---help---
  Parade eDP-LVDS bridge chip driver.

+config DRM_PARADE_PS8640
+   tristate "Parade PS8640 MIPI DSI to eDP Converter"
+   depends on OF
+   select DRM_KMS_HELPER
+   select DRM_PANEL
+   ---help---
+ Choose this option if you have PS8640 for display
+ The PS8640 is a high-performance and low-power
+ MIPI DSI to eDP converter
+
  endmenu
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index d4e28be..272e3c01 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -4,3 +4,4 @@ obj-$(CONFIG_DRM_DW_HDMI) += dw_hdmi.o
  obj-$(CONFIG_DRM_DW_HDMI_AHB_AUDIO) += dw_hdmi-ahb-audio.o
  obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
  obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
+obj-$(CONFIG_DRM_PARADE_PS8640) += parade-ps8640.o
diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c 
b/drivers/gpu/drm/bridge/parade-ps8640.c
new file mode 100644
index 000..bf0c3c37
--- /dev/null
+++ b/drivers/gpu/drm/bridge/parade-ps8640.c
@@ -0,0 +1,472 @@
+/*
+ * Copyright (c) 2014 MediaTek Inc.
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include 
+#include 
+#include 
+#include 


This doesn't seem to be used at the moment.




+
+static int ps8640_probe(struct i2c_client *client,
+   const struct i2c_device_id *id)
+{
+   struct device *dev = &client->dev;
+   struct ps8640 *ps_bridge;
+   struct device_node *np = dev->of_node;
+   struct device_node *port, *out_ep;
+   struct device_node *panel_node = NULL;
+   int i, ret;
+
+   ps_bridge = devm_kzalloc(dev, sizeof(*ps_bridge), GFP_KERNEL);
+   if (!ps_bridge)
+   return -ENOMEM;
+
+   /* port@1 is ps8640 output port */
+   port = of_graph_get_port_by_id(np, 1);
+   if (port) {
+   out_ep = of_get_child_by_name(port, "endpoint");
+   of_node_put(port);
+   if (out_ep) {
+   panel_node = of_graph_get_remote_port_parent(out_ep);
+   of_node_put(out_ep);
+   }
+   }
+   if (panel_node) {
+   ps_bridge->panel = of_drm_find_panel(panel_node);
+   of_node_put(panel_node);
+   if (!ps_bridge->panel)
+   return -EPROBE_DEFER;
+   }


The driver retrieves the panel from the output port via DT, but doesn't
retrieve the DSI host from the input port?

Wouldn't this driver need to call a "mipi_dsi_attach" at some point to
link with the DSI host (and pass parameters like number of lanes, color
format etc)?

I've been working on a patchset[1] which lets i2c drivers create mipi
dsi devices. I think this would be needed for the ps8640 driver too.

[1] https://lkml.org/lkml/2015/12/10/283

Archit


+
+   ps_bridge->page[0] = client;
+   for (i = 1; i < 6; i++)
+   ps_bridge->page[i] = i2c_new_dummy(client->adapter,
+  client->addr + i);
+
+   ps_bridge->pwr_3v3_supply = devm_regulator_get(dev, "vdd33");
+   if (IS_ERR(ps_bridge->pwr_3v3_supply)) {
+   ret = PTR_ERR(ps_bridge->pwr_3v3_supply);
+   dev_err(dev, "cannot get vdd33 supply: %d\n", ret);
+   return ret;
+   }
+
+   ps_bridge->pwr_1v2_supply = devm_regulator_get(dev, "vdd12");
+   if (IS_ERR(ps_bridge->pwr_1v2_supply)) {
+   ret = PTR_ERR(ps_bridge->pwr_1v2_supply);
+   dev_err(dev, "cannot get vdd12 supply: %d\n", ret);
+   return ret;
+   }
+
+   ps_bridge->gpio_mode_sel_n = devm_gpiod_get(&client->dev, "mode-sel",
+   GPIOD_OUT_H

Re: [PATCH v2 10/10] dt-bindings: Add DSIv2 documentation

[Archit Taneja]

On 12/02/2015 02:04 PM, Stephen Boyd wrote:

On 12/02, Stephen Boyd wrote:


My only thought there would be to make of_clk_set_defaults() wait
until both clocks are registered before it does any parent
setting. But only in the case where the assigned parents contains
a clock that is provided by the node being processed. I suppose
the simplest thing to do would be to skip it during the device
driver probe and handle it when the clk provider is registered.



Actually it looks like we already have the code for that.

if (clkspec.np == node && !clk_supplier)
return 0;

So assigned parents should "just work"?


I tried using assigned-parents and it works fine.

The issue you mentioned above doesn't apply in our case, because
we have two different devices for "dsi" and "dsi_phy". dsi_phy is the
clock provider here and dsi is the one that wants to assign clocks.

If there was only one dsi device representing both DSI and PHY, then
we'd hit the condition you mentioned.

Thanks,
Archit

--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora 
Forum, hosted by The Linux Foundation

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 10/10] dt-bindings: Add DSIv2 documentation

[Archit Taneja]

On 12/03/2015 12:46 PM, Stephen Boyd wrote:

On 12/02, Archit Taneja wrote:

On 12/02/2015 01:50 PM, Stephen Boyd wrote:


My only thought there would be to make of_clk_set_defaults() wait
until both clocks are registered before it does any parent
setting. But only in the case where the assigned parents contains
a clock that is provided by the node being processed. I suppose
the simplest thing to do would be to skip it during the device
driver probe and handle it when the clk provider is registered.



The assigned-clock-parents stuff you mentioned is needed to set a
default link between the one of the DSI PLLs and the RCG, right? I
just wanted to make clear if we were still discussing the same
issue.


Yes.



 From what I understand, we don't need the assigned-clock-parents stuff
to establish a link between byte_clk_src(RCG clock) and
byte_clk(branch clock). That's a fixed link set up by the clock
structs provided in the gcc driver and doesn't need to be specially
assigned, and just a
clk_get_parent in the driver does the job there.


There's only one parent of the byte_clk and that's byte_clk_src.
So yes, there's no need to describe that in DT and
clk_get_parent() works fine.



About assigning a parent to the RCG, wouldn't that be xo by default, and
changed by the drm/msm driver to one of the PLLs when the need arrives?
I didn't get why we need to establish that beforehand in DT?



Yes, it would be XO out of reset, but we have no idea what the
bootloader is doing. I thought the problem was that byte_clk_src
is not actually an input to the DSI device. The proposal was to
have DT specify byte_clk_src and byte_clk in the clocks array so
that byte_clk_src could be reparented to the PLL and the byte_clk
could be enabled/disabled. If we use DT to do the parent
configuring then the DSI node doesn't have the byte_clk_src in
its clocks array and thus DT is reflecting reality.


Okay, I understand your point now.



If we want to dynamically switch the parent of byte_clk_src to be
different PLLs at runtime, then yes we'll need to get the parent
of the byte_clk (which is byte_clk_src) and set the PLL as the
parent. Or we'll need to make clk_set_parent() on the byte_clk
transparently set the grand-parent to be the PLL. In that case we
may need to introduce some sort of flag like
CLK_SET_PARENT_GRANDPARENT to add this type of behavior.

I don't have a huge problem with

clk_set_parent(clk_get_parent(byte_clk), PLL)

except that this fails the abstraction test. It leaks information
about the clock tree into a driver that shouldn't need to know
that on this particular SoC there's a clock in between the PLL
and the byte_clk. Future designs may not have the intermediate
clock and then we'll need to update the driver to handle the
difference, when we could have added the flag and things would
work the same.



I will have to check if we really require dynamic PLL configuration
or not. At the moment, the driver reads another DT param (that
identifies if we are in dual dsi mode) and then sets the appropriate
PLL as parent. So, in a sense, it is relying on DT already for setting
the parent.

I guess we can do the following:

- use assigned-clock-parents in DT to set the default PLL
parent (provided it works out of the box)

- Within the driver, still do the
'clk_set_parent(clk_get_parent(byte_clk), PLL)' thing and
remove it later if dynamic switching isn't needed at all
if the parent PLL is known beforehand in all use cases.

Archit





--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora 
Forum, hosted by The Linux Foundation

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 10/10] dt-bindings: Add DSIv2 documentation

[Archit Taneja]

On 12/02/2015 01:50 PM, Stephen Boyd wrote:

On 11/23, Archit Taneja wrote:



On 11/21/2015 1:29 AM, Rob Herring wrote:

+Stephen

On Wed, Nov 18, 2015 at 9:24 AM, Archit Taneja  wrote:

Hi Rob,

On 11/18/2015 6:48 PM, Rob Herring wrote:


+dt list

On Wed, Nov 18, 2015 at 4:55 AM, Archit Taneja 
wrote:


Add additional property info needed for DSIv2 DT.



Please use get_maintainers.pl.



Sorry about that, missed out doing that posting this time.




Signed-off-by: Archit Taneja 
---
   Documentation/devicetree/bindings/display/msm/dsi.txt | 10 +-
   1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/display/msm/dsi.txt
b/Documentation/devicetree/bindings/display/msm/dsi.txt
index f344b9e..ca65a34 100644
--- a/Documentation/devicetree/bindings/display/msm/dsi.txt
+++ b/Documentation/devicetree/bindings/display/msm/dsi.txt
@@ -13,18 +13,25 @@ Required properties:
   - power-domains: Should be <&mmcc MDSS_GDSC>.
   - clocks: device clocks
 See Documentation/devicetree/bindings/clocks/clock-bindings.txt for
details.
-- clock-names: the following clocks are required:
+- clock-names: these vary based on the DSI version. For DSI6G:
 * "bus_clk"
 * "byte_clk"
+  * "byte_clk_src



This sounds like the parent of byte_clk. Is that really a clock within
the block?



byte_clk_src isn't in the block, but byte_clk_src's parent is one of
the PLLs in this block. We take this clock so that we can re-parent
it to an appropriate PLL. The decision of what PLL to choose needs to
be done by the DSI block's driver.


Seems like abuse to me. The list of clocks should match what are
inputs to the block, not what the driver happens to need. Without a
full understanding of the clock tree here, I don't have a suggestion.
Maybe Stephen does.


We don't need specify byte_clk_src (and other xyz_clk_src clocks) via
DT. There is a static link set up between byte_clk and byte_clk_src by
our clock driver that never changes. We can retrieve it in the driver
itself using clk_get_parent(byte_clk). This way we stick to only
input clocks.

Stephen, does that sound okay?



I guess so. From the DT perspective it's "correct" so sure.

It would be nice if we could use assigned-clock-parents though.
As far as I can recall that's hard because the clock tree looks
like a cyclic graph when we take a clock provider level view. The
display block consumes the byte_clk and provides the source of it
too. So if we used assigned parents we would need to wait for
both clocks to be registered with the framework before we can
reconfigure the parent of byte_clk_src to be the PLL that the
display clock outputs. Unfortunately, of_clk_set_defaults() is
called during device driver probe, which in the display driver
case would be before the PLL is registered.

My only thought there would be to make of_clk_set_defaults() wait
until both clocks are registered before it does any parent
setting. But only in the case where the assigned parents contains
a clock that is provided by the node being processed. I suppose
the simplest thing to do would be to skip it during the device
driver probe and handle it when the clk provider is registered.



The assigned-clock-parents stuff you mentioned is needed to set a 
default link between the one of the DSI PLLs and the RCG, right? I just 
wanted to make clear if we were still discussing the same issue.


From what I understand, we don't need the assigned-clock-parents stuff
to establish a link between byte_clk_src(RCG clock) and byte_clk(branch 
clock). That's a fixed link set up by the clock structs provided in the 
gcc driver and doesn't need to be specially assigned, and just a

clk_get_parent in the driver does the job there.

About assigning a parent to the RCG, wouldn't that be xo by default, and
changed by the drm/msm driver to one of the PLLs when the need arrives?
I didn't get why we need to establish that beforehand in DT?

Archit

--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora 
Forum, hosted by The Linux Foundation

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 10/10] drm/hisilicon: Add support for external bridge

[Archit Taneja]

On 12/01/2015 08:20 PM, Xinliang Liu wrote:

On 1 December 2015 at 17:04, Archit Taneja  wrote:



On 11/28/2015 04:09 PM, Xinliang Liu wrote:


Add support for external HDMI bridge.

Signed-off-by: Xinliang Liu 
Signed-off-by: Xinwei Kong 
Signed-off-by: Andy Green 
---
   drivers/gpu/drm/hisilicon/hisi_drm_dsi.c | 51

   1 file changed, 51 insertions(+)

diff --git a/drivers/gpu/drm/hisilicon/hisi_drm_dsi.c
b/drivers/gpu/drm/hisilicon/hisi_drm_dsi.c
index 066e08d..9e056db 100644
--- a/drivers/gpu/drm/hisilicon/hisi_drm_dsi.c
+++ b/drivers/gpu/drm/hisilicon/hisi_drm_dsi.c
@@ -78,6 +78,7 @@ struct dsi_hw_ctx {

   struct hisi_dsi {
 struct drm_encoder encoder;
+   struct drm_bridge *bridge;
 struct mipi_dsi_host host;
 struct drm_display_mode cur_mode;
 struct dsi_hw_ctx *ctx;
@@ -671,6 +672,25 @@ static int dsi_host_init(struct device *dev, struct
hisi_dsi *dsi)
 return 0;
   }

+static int dsi_bridge_init(struct drm_device *dev, struct hisi_dsi *dsi)
+{
+   struct drm_encoder *encoder = &dsi->encoder;
+   struct drm_bridge *bridge = dsi->bridge;
+   int ret;
+
+   /* associate the bridge to dsi encoder */
+   encoder->bridge = bridge;
+   bridge->encoder = encoder;
+
+   ret = drm_bridge_attach(dev, bridge);
+   if (ret) {
+   DRM_ERROR("failed to attach exteranl bridge\n");



s/exteranl/external



will be fixed in v3.




+   return ret;
+   }
+
+   return 0;
+}
+
   static int dsi_bind(struct device *dev, struct device *master, void
*data)
   {
 struct dsi_data *ddata = dev_get_drvdata(dev);
@@ -686,6 +706,10 @@ static int dsi_bind(struct device *dev, struct device
*master, void *data)
 if (ret)
 return ret;

+   ret = dsi_bridge_init(drm_dev, dsi);
+   if (ret)
+   return ret;
+
 return 0;
   }

@@ -702,8 +726,35 @@ static const struct component_ops dsi_ops = {
   static int dsi_parse_dt(struct platform_device *pdev, struct hisi_dsi
*dsi)
   {
 struct dsi_hw_ctx *ctx = dsi->ctx;
+   struct device_node *np = pdev->dev.of_node;
+   struct device_node *endpoint, *bridge_node;
+   struct drm_bridge *bridge;
 struct resource *res;

+   /*
+* Get the endpoint node. In our case, dsi has one output port
+* to which the external HDMI bridge is connected.
+*/
+   endpoint = of_graph_get_next_endpoint(np, NULL);
+   if (!endpoint) {
+   DRM_ERROR("no valid endpoint node\n");
+   return -ENODEV;
+   }
+   of_node_put(endpoint);
+
+   bridge_node = of_graph_get_remote_port_parent(endpoint);
+   if (!bridge_node) {
+   DRM_ERROR("no valid bridge node\n");
+   return -ENODEV;
+   }
+   of_node_put(bridge_node);
+
+   bridge = of_drm_find_bridge(bridge_node);
+   if (!bridge) {
+   DRM_INFO("wait for external HDMI bridge driver.\n");
+   return -EPROBE_DEFER;
+   }
+   dsi->bridge = bridge;



This could be left for later, but it would be better if the dsi driver
registers even if the bridge driver module isn't inserted yet, or
happens much later in boot.

We could achieve this by trying to attach the bridge (done in
dsi_bridge_init) in the dsi_host_attach callback instead of having it
in dsi_bind.


Do you mean that it is the right time or place to attach the bridge in
dsi_host_attach callback.
Why? Because at this time bridge driver must be register?


The bridge/panel drivers generally call drm_bridge_add/drm_panel_add and 
mipi_dsi_attach() during probe.


If the driver calls drm_bridge_add() before mipi_dsi_attach() in probe,
then 'of_drm_find_bridge()' should succeed in the callback. This, 
however, is prone to all sorts of race conditions and hence not the

best solution.

In the case of panels, a dsi host can always create a dummy connector,
and search for a panel (of_drm_find_panel) in its 'detect' helper.
Unfortunately, we don't have a free connector in the case of bridges.
The connector are, in most cases, created by the bridge driver itself,
and the dsi host driver has no say over the connector ops.

I don't have a better solution yet, hence I said it could be left for
later :)

Archit



Thanks,
-xinliang



Thanks,
Archit



 ctx->dsi_cfg_clk = devm_clk_get(&pdev->dev, "pclk_dsi");
 if (IS_ERR(ctx->dsi_cfg_clk)) {



--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation


--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora 
Forum, hosted by The Linux Foundation

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 12/12] dt-bindings: msm/dsi: Add DSIv2 documentation

[Archit Taneja]

Add additional property info needed for DSIv2 DT.

Cc: devicetree@vger.kernel.org
Cc: Rob Herring 

Signed-off-by: Archit Taneja 
---
 Documentation/devicetree/bindings/display/msm/dsi.txt | 4 
 1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/msm/dsi.txt 
b/Documentation/devicetree/bindings/display/msm/dsi.txt
index e097955..e7423be 100644
--- a/Documentation/devicetree/bindings/display/msm/dsi.txt
+++ b/Documentation/devicetree/bindings/display/msm/dsi.txt
@@ -21,10 +21,13 @@ Required properties:
   * "byte_clk"
   * "pixel_clk"
   * "core_clk"
+  For DSIv2, we need an additional clock:
+   * "src_clk"
 - vdd-supply: phandle to vdd regulator device node
 - vddio-supply: phandle to vdd-io regulator device node
 - vdda-supply: phandle to vdda regulator device node
 - qcom,dsi-phy: phandle to DSI PHY device node
+- syscon-sfpb: A phandle to mmss_sfpb syscon node (only for DSIv2)
 
 Optional properties:
 - panel@0: Node of panel connected to this DSI controller.
@@ -51,6 +54,7 @@ Required properties:
   * "qcom,dsi-phy-28nm-hpm"
   * "qcom,dsi-phy-28nm-lp"
   * "qcom,dsi-phy-20nm"
+  * "qcom,dsi-phy-28nm-8960"
 - reg: Physical base address and length of the registers of PLL, PHY and PHY
   regulator
 - reg-names: The names of register regions. The following regions are required:
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 11/12] dt-bindings: msm/dsi: Fix the order in which clocks are listed

[Archit Taneja]

List the clocks in the order that's used in DT. We don't have mdp/dsi
DT nodes for any SoC in upstream yet, but we align with the order
we intend to use.

Cc: devicetree@vger.kernel.org
Cc: Rob Herring 

Signed-off-by: Archit Taneja 
---
 Documentation/devicetree/bindings/display/msm/dsi.txt | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/Documentation/devicetree/bindings/display/msm/dsi.txt 
b/Documentation/devicetree/bindings/display/msm/dsi.txt
index f344b9e..e097955 100644
--- a/Documentation/devicetree/bindings/display/msm/dsi.txt
+++ b/Documentation/devicetree/bindings/display/msm/dsi.txt
@@ -14,13 +14,13 @@ Required properties:
 - clocks: device clocks
   See Documentation/devicetree/bindings/clocks/clock-bindings.txt for details.
 - clock-names: the following clocks are required:
+  * "mdp_core_clk"
+  * "iface_clk"
   * "bus_clk"
-  * "byte_clk"
-  * "core_clk"
   * "core_mmss_clk"
-  * "iface_clk"
-  * "mdp_core_clk"
+  * "byte_clk"
   * "pixel_clk"
+  * "core_clk"
 - vdd-supply: phandle to vdd regulator device node
 - vddio-supply: phandle to vdd-io regulator device node
 - vdda-supply: phandle to vdda regulator device node
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 10/10] drm/hisilicon: Add support for external bridge

[Archit Taneja]

On 11/28/2015 04:09 PM, Xinliang Liu wrote:

Add support for external HDMI bridge.

Signed-off-by: Xinliang Liu 
Signed-off-by: Xinwei Kong 
Signed-off-by: Andy Green 
---
  drivers/gpu/drm/hisilicon/hisi_drm_dsi.c | 51 
  1 file changed, 51 insertions(+)

diff --git a/drivers/gpu/drm/hisilicon/hisi_drm_dsi.c 
b/drivers/gpu/drm/hisilicon/hisi_drm_dsi.c
index 066e08d..9e056db 100644
--- a/drivers/gpu/drm/hisilicon/hisi_drm_dsi.c
+++ b/drivers/gpu/drm/hisilicon/hisi_drm_dsi.c
@@ -78,6 +78,7 @@ struct dsi_hw_ctx {

  struct hisi_dsi {
struct drm_encoder encoder;
+   struct drm_bridge *bridge;
struct mipi_dsi_host host;
struct drm_display_mode cur_mode;
struct dsi_hw_ctx *ctx;
@@ -671,6 +672,25 @@ static int dsi_host_init(struct device *dev, struct 
hisi_dsi *dsi)
return 0;
  }

+static int dsi_bridge_init(struct drm_device *dev, struct hisi_dsi *dsi)
+{
+   struct drm_encoder *encoder = &dsi->encoder;
+   struct drm_bridge *bridge = dsi->bridge;
+   int ret;
+
+   /* associate the bridge to dsi encoder */
+   encoder->bridge = bridge;
+   bridge->encoder = encoder;
+
+   ret = drm_bridge_attach(dev, bridge);
+   if (ret) {
+   DRM_ERROR("failed to attach exteranl bridge\n");


s/exteranl/external


+   return ret;
+   }
+
+   return 0;
+}
+
  static int dsi_bind(struct device *dev, struct device *master, void *data)
  {
struct dsi_data *ddata = dev_get_drvdata(dev);
@@ -686,6 +706,10 @@ static int dsi_bind(struct device *dev, struct device 
*master, void *data)
if (ret)
return ret;

+   ret = dsi_bridge_init(drm_dev, dsi);
+   if (ret)
+   return ret;
+
return 0;
  }

@@ -702,8 +726,35 @@ static const struct component_ops dsi_ops = {
  static int dsi_parse_dt(struct platform_device *pdev, struct hisi_dsi *dsi)
  {
struct dsi_hw_ctx *ctx = dsi->ctx;
+   struct device_node *np = pdev->dev.of_node;
+   struct device_node *endpoint, *bridge_node;
+   struct drm_bridge *bridge;
struct resource *res;

+   /*
+* Get the endpoint node. In our case, dsi has one output port
+* to which the external HDMI bridge is connected.
+*/
+   endpoint = of_graph_get_next_endpoint(np, NULL);
+   if (!endpoint) {
+   DRM_ERROR("no valid endpoint node\n");
+   return -ENODEV;
+   }
+   of_node_put(endpoint);
+
+   bridge_node = of_graph_get_remote_port_parent(endpoint);
+   if (!bridge_node) {
+   DRM_ERROR("no valid bridge node\n");
+   return -ENODEV;
+   }
+   of_node_put(bridge_node);
+
+   bridge = of_drm_find_bridge(bridge_node);
+   if (!bridge) {
+   DRM_INFO("wait for external HDMI bridge driver.\n");
+   return -EPROBE_DEFER;
+   }
+   dsi->bridge = bridge;


This could be left for later, but it would be better if the dsi driver
registers even if the bridge driver module isn't inserted yet, or
happens much later in boot.

We could achieve this by trying to attach the bridge (done in 
dsi_bridge_init) in the dsi_host_attach callback instead of having it

in dsi_bind.

Thanks,
Archit



ctx->dsi_cfg_clk = devm_clk_get(&pdev->dev, "pclk_dsi");
if (IS_ERR(ctx->dsi_cfg_clk)) {



--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora 
Forum, hosted by The Linux Foundation

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 08/10] drm/hisilicon: Add dsi encoder driver

[Archit Taneja]

On 11/28/2015 04:09 PM, Xinliang Liu wrote:

Add dsi encoder driver for hi6220 SoC.

Signed-off-by: Xinliang Liu 
Signed-off-by: Xinwei Kong 
Signed-off-by: Andy Green 
---
  drivers/gpu/drm/hisilicon/Kconfig|   1 +
  drivers/gpu/drm/hisilicon/Makefile   |   3 +-
  drivers/gpu/drm/hisilicon/hisi_drm_dsi.c | 728 +++
  drivers/gpu/drm/hisilicon/hisi_dsi_reg.h |  89 
  4 files changed, 820 insertions(+), 1 deletion(-)
  create mode 100644 drivers/gpu/drm/hisilicon/hisi_drm_dsi.c
  create mode 100644 drivers/gpu/drm/hisilicon/hisi_dsi_reg.h

diff --git a/drivers/gpu/drm/hisilicon/Kconfig 
b/drivers/gpu/drm/hisilicon/Kconfig
index 70aa8d1..f1c33c2 100644
--- a/drivers/gpu/drm/hisilicon/Kconfig
+++ b/drivers/gpu/drm/hisilicon/Kconfig
@@ -4,6 +4,7 @@ config DRM_HISI
select DRM_KMS_HELPER
select DRM_GEM_CMA_HELPER
select DRM_KMS_CMA_HELPER
+   select DRM_MIPI_DSI
help
  Choose this option if you have a hisilicon chipsets(hi6220).
  If M is selected the module will be called hisi-drm.
diff --git a/drivers/gpu/drm/hisilicon/Makefile 
b/drivers/gpu/drm/hisilicon/Makefile
index 3433c8b..5083c1f 100644
--- a/drivers/gpu/drm/hisilicon/Makefile
+++ b/drivers/gpu/drm/hisilicon/Makefile
@@ -1,4 +1,5 @@
  hisi-drm-y := hisi_drm_drv.o \
- hisi_drm_ade.o
+ hisi_drm_ade.o \
+ hisi_drm_dsi.o

  obj-$(CONFIG_DRM_HISI)+= hisi-drm.o
diff --git a/drivers/gpu/drm/hisilicon/hisi_drm_dsi.c 
b/drivers/gpu/drm/hisilicon/hisi_drm_dsi.c
new file mode 100644
index 000..7a6cf66
--- /dev/null
+++ b/drivers/gpu/drm/hisilicon/hisi_drm_dsi.c
@@ -0,0 +1,728 @@
+/*
+ * Hisilicon hi6220 SoC dsi driver
+ *
+ * Copyright (c) 2014-2015 Hisilicon Limited.
+ * Author:
+ * Xinliang Liu 
+ * Xinliang Liu 
+ * Xinwei Kong 
+ *
+ * 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 
+#include 
+
+#include "hisi_dsi_reg.h"
+
+#define MAX_TX_ESC_CLK(10)
+#define ROUND(x, y) ((x) / (y) + ((x) % (y) * 10 / (y) >= 5 ? 1 : 0))
+#define DEFAULT_MIPI_CLK_RATE   1920
+#define DEFAULT_MIPI_CLK_PERIOD_PS (10 / (DEFAULT_MIPI_CLK_RATE / 
1000))
+#define R(x) ((u32)u64)(x) * (u64)1000 * (u64)mode->clock) / \
+ phy->lane_byte_clk_kHz)))
+
+#define encoder_to_dsi(encoder) \
+   container_of(encoder, struct hisi_dsi, encoder)
+#define host_to_dsi(host) \
+   container_of(host, struct hisi_dsi, host)
+
+struct mipi_phy_register {
+   u32 clk_t_lpx;
+   u32 clk_t_hs_prepare;
+   u32 clk_t_hs_zero;
+   u32 clk_t_hs_trial;
+   u32 clk_t_wakeup;
+   u32 data_t_lpx;
+   u32 data_t_hs_prepare;
+   u32 data_t_hs_zero;
+   u32 data_t_hs_trial;
+   u32 data_t_ta_go;
+   u32 data_t_ta_get;
+   u32 data_t_wakeup;
+   u32 hstx_ckg_sel;
+   u32 pll_fbd_div5f;
+   u32 pll_fbd_div1f;
+   u32 pll_fbd_2p;
+   u32 pll_enbwt;
+   u32 pll_fbd_p;
+   u32 pll_fbd_s;
+   u32 pll_pre_div1p;
+   u32 pll_pre_p;
+   u32 pll_vco_750M;
+   u32 pll_lpf_rs;
+   u32 pll_lpf_cs;
+   u32 clklp2hs_time;
+   u32 clkhs2lp_time;
+   u32 lp2hs_time;
+   u32 hs2lp_time;
+   u32 clk_to_data_delay;
+   u32 data_to_clk_delay;
+   u32 lane_byte_clk_kHz;
+   u32 clk_division;
+};
+
+struct dsi_hw_ctx {
+   void __iomem *base;
+   struct clk *dsi_cfg_clk;
+};
+
+struct hisi_dsi {
+   struct drm_encoder encoder;
+   struct drm_display_mode cur_mode;
+   struct dsi_hw_ctx *ctx;
+   struct mipi_phy_register phy;
+
+   u32 lanes;
+   enum mipi_dsi_pixel_format format;
+   unsigned long mode_flags;
+   bool enable;
+};
+
+struct dsi_data {
+   struct hisi_dsi dsi;
+   struct dsi_hw_ctx ctx;
+};
+
+struct dsi_phy_seq_info {
+   u32 min_range_kHz;
+   u32 max_range_kHz;
+   u32 pll_vco_750M;
+   u32 hstx_ckg_sel;
+};
+
+static const struct dsi_phy_seq_info dphy_seq_info[] = {
+   {   46000,62000,   1,7 },
+   {   62000,93000,   0,7 },
+   {   93000,   125000,   1,6 },
+   {  125000,   187000,   0,6 },
+   {  187000,   25,   1,5 },
+   {  25,   375000,   0,5 },
+   {  375000,   50,   1,4 },
+   {  50,   75,   0,4 },
+   {  75,  100,   1,0 },
+   { 100,  150,   0,0 }
+};
+
+static void set_dsi_phy_rate_equal_or_faster(u32 phy_freq_kHz,
+struct mipi_phy_register *phy)
+{
+   u32 ui = 0;
+   u32 cfg_clk_ps = DEFAULT_MIPI_CLK_PERIOD_PS;
+   u32 i = 0;
+   u32 q_pll = 1;
+   u32 m_pll = 0;
+   u32 n_pll = 0;
+   u32 r_pll = 1;
+   u32 

Re: [PATCH v2 10/10] dt-bindings: Add DSIv2 documentation

[Archit Taneja]

On 11/21/2015 1:29 AM, Rob Herring wrote:

+Stephen

On Wed, Nov 18, 2015 at 9:24 AM, Archit Taneja  wrote:

Hi Rob,

On 11/18/2015 6:48 PM, Rob Herring wrote:


+dt list

On Wed, Nov 18, 2015 at 4:55 AM, Archit Taneja 
wrote:


Add additional property info needed for DSIv2 DT.



Please use get_maintainers.pl.



Sorry about that, missed out doing that posting this time.




Signed-off-by: Archit Taneja 
---
   Documentation/devicetree/bindings/display/msm/dsi.txt | 10 +-
   1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/display/msm/dsi.txt
b/Documentation/devicetree/bindings/display/msm/dsi.txt
index f344b9e..ca65a34 100644
--- a/Documentation/devicetree/bindings/display/msm/dsi.txt
+++ b/Documentation/devicetree/bindings/display/msm/dsi.txt
@@ -13,18 +13,25 @@ Required properties:
   - power-domains: Should be <&mmcc MDSS_GDSC>.
   - clocks: device clocks
 See Documentation/devicetree/bindings/clocks/clock-bindings.txt for
details.
-- clock-names: the following clocks are required:
+- clock-names: these vary based on the DSI version. For DSI6G:
 * "bus_clk"
 * "byte_clk"
+  * "byte_clk_src



This sounds like the parent of byte_clk. Is that really a clock within
the block?



byte_clk_src isn't in the block, but byte_clk_src's parent is one of
the PLLs in this block. We take this clock so that we can re-parent
it to an appropriate PLL. The decision of what PLL to choose needs to
be done by the DSI block's driver.


Seems like abuse to me. The list of clocks should match what are
inputs to the block, not what the driver happens to need. Without a
full understanding of the clock tree here, I don't have a suggestion.
Maybe Stephen does.


We don't need specify byte_clk_src (and other xyz_clk_src clocks) via
DT. There is a static link set up between byte_clk and byte_clk_src by
our clock driver that never changes. We can retrieve it in the driver
itself using clk_get_parent(byte_clk). This way we stick to only
input clocks.

Stephen, does that sound okay?




 * "core_clk"
 * "core_mmss_clk"
 * "iface_clk"
 * "mdp_core_clk"
 * "pixel_clk"
+  * "pixel_clk_src"
+  For DSIv2, we need a few more:



What is the overall order of clocks? As listed?



Order in which the driver does clk_get? It uses the clock
name to get each one individually, so the order doesn't matter
as such.


The order in DT. You may use the names, but the order should still be specified.


Okay. I'll cross check and make sure the order is as in our DT files.

Archit



Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html



--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 10/10] dt-bindings: Add DSIv2 documentation

[Archit Taneja]

Hi Rob,

On 11/18/2015 6:48 PM, Rob Herring wrote:

+dt list

On Wed, Nov 18, 2015 at 4:55 AM, Archit Taneja  wrote:

Add additional property info needed for DSIv2 DT.


Please use get_maintainers.pl.


Sorry about that, missed out doing that posting this time.




Signed-off-by: Archit Taneja 
---
  Documentation/devicetree/bindings/display/msm/dsi.txt | 10 +-
  1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/display/msm/dsi.txt 
b/Documentation/devicetree/bindings/display/msm/dsi.txt
index f344b9e..ca65a34 100644
--- a/Documentation/devicetree/bindings/display/msm/dsi.txt
+++ b/Documentation/devicetree/bindings/display/msm/dsi.txt
@@ -13,18 +13,25 @@ Required properties:
  - power-domains: Should be <&mmcc MDSS_GDSC>.
  - clocks: device clocks
See Documentation/devicetree/bindings/clocks/clock-bindings.txt for details.
-- clock-names: the following clocks are required:
+- clock-names: these vary based on the DSI version. For DSI6G:
* "bus_clk"
* "byte_clk"
+  * "byte_clk_src


This sounds like the parent of byte_clk. Is that really a clock within
the block?


byte_clk_src isn't in the block, but byte_clk_src's parent is one of
the PLLs in this block. We take this clock so that we can re-parent
it to an appropriate PLL. The decision of what PLL to choose needs to
be done by the DSI block's driver.




* "core_clk"
* "core_mmss_clk"
* "iface_clk"
* "mdp_core_clk"
* "pixel_clk"
+  * "pixel_clk_src"
+  For DSIv2, we need a few more:


What is the overall order of clocks? As listed?


Order in which the driver does clk_get? It uses the clock
name to get each one individually, so the order doesn't matter
as such.

I don't think it the order of clk_get in the driver is the same
as what's been listed here. I can fix it if that's the norm.

Thanks,
Archit




+   * "dsi_clk_src"
+   * "esc_clk_src"
+   * "src_clk"
  - vdd-supply: phandle to vdd regulator device node
  - vddio-supply: phandle to vdd-io regulator device node
  - vdda-supply: phandle to vdda regulator device node
  - qcom,dsi-phy: phandle to DSI PHY device node
+- syscon-sfpb: A phandle to mmss_sfpb syscon node (only for DSIv2)

  Optional properties:
  - panel@0: Node of panel connected to this DSI controller.
@@ -51,6 +58,7 @@ Required properties:
* "qcom,dsi-phy-28nm-hpm"
* "qcom,dsi-phy-28nm-lp"
* "qcom,dsi-phy-20nm"
+  * "qcom,dsi-phy-28nm-8960"
  - reg: Physical base address and length of the registers of PLL, PHY and PHY
regulator
  - reg-names: The names of register regions. The following regions are 
required:
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

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


--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] dt-bindings: drm/msm: Update bindings for MDP5

[Archit Taneja]

On 10/20/2015 11:47 PM, Rob Clark wrote:

On Mon, Oct 19, 2015 at 1:49 AM, Archit Taneja  wrote:


On 10/18/2015 08:49 AM, Bjorn Andersson wrote:


On Fri, Oct 16, 2015 at 5:06 AM, Archit Taneja 
wrote:


MDP5 has a different compatible string (which causes checkpatch warnings
when we try to add MDP5 device nodes). It also has different list of
clocks.

Update the bindings for MDP5.

Signed-off-by: Archit Taneja 
---
   Documentation/devicetree/bindings/drm/msm/mdp.txt | 23
---
   1 file changed, 16 insertions(+), 7 deletions(-)

diff --git a/Documentation/devicetree/bindings/drm/msm/mdp.txt
b/Documentation/devicetree/bindings/drm/msm/mdp.txt
index 1a0598e..e926daa 100644
--- a/Documentation/devicetree/bindings/drm/msm/mdp.txt
+++ b/Documentation/devicetree/bindings/drm/msm/mdp.txt
@@ -3,18 +3,27 @@ Qualcomm adreno/snapdragon display controller
   Required properties:
   - compatible:
 * "qcom,mdp" - mdp4
+  * "qcom,mdss_mdp" - mdp5



Wouldn't it be better to name these "qcom,mdp4" and "qcom,mdp5" so
that we don't have to rely on some magic detection mechanism to
support future versions?



My guess is that compatibility string "mdss_mdp" came from the
downstream kernels. Chips having MDP4 were supported on downstream
kernels that preceded DT.

Since we don't have any MDP DT upstream, I think we could go with the
string names you suggested. It might break things for people who might
try to use an old downstream dts file with a new kernel. But that
doesn't sound like the worst thing.


it would break things for downstream 3.10/mdp5 dt files..  but what
I'd suggest is to make the code look for both qcom,mdp5 and
qcom,mdss_mdp but only document the former


That's a good idea. I'll update the patches to do that.

Archit



BR,
-R


Archit



Regards,
Bjorn



--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation


--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] dt-bindings: drm/msm: Update bindings for MDP5

[Archit Taneja]

On 10/18/2015 08:49 AM, Bjorn Andersson wrote:

On Fri, Oct 16, 2015 at 5:06 AM, Archit Taneja  wrote:

MDP5 has a different compatible string (which causes checkpatch warnings
when we try to add MDP5 device nodes). It also has different list of
clocks.

Update the bindings for MDP5.

Signed-off-by: Archit Taneja 
---
  Documentation/devicetree/bindings/drm/msm/mdp.txt | 23 ---
  1 file changed, 16 insertions(+), 7 deletions(-)

diff --git a/Documentation/devicetree/bindings/drm/msm/mdp.txt 
b/Documentation/devicetree/bindings/drm/msm/mdp.txt
index 1a0598e..e926daa 100644
--- a/Documentation/devicetree/bindings/drm/msm/mdp.txt
+++ b/Documentation/devicetree/bindings/drm/msm/mdp.txt
@@ -3,18 +3,27 @@ Qualcomm adreno/snapdragon display controller
  Required properties:
  - compatible:
* "qcom,mdp" - mdp4
+  * "qcom,mdss_mdp" - mdp5


Wouldn't it be better to name these "qcom,mdp4" and "qcom,mdp5" so
that we don't have to rely on some magic detection mechanism to
support future versions?


My guess is that compatibility string "mdss_mdp" came from the
downstream kernels. Chips having MDP4 were supported on downstream
kernels that preceded DT.

Since we don't have any MDP DT upstream, I think we could go with the
string names you suggested. It might break things for people who might
try to use an old downstream dts file with a new kernel. But that
doesn't sound like the worst thing.

Archit



Regards,
Bjorn



--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora 
Forum, hosted by The Linux Foundation

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/2] dt-bindings: drm/msm: Update bindings for MDP5

[Archit Taneja]

MDP5 has a different compatible string (which causes checkpatch warnings
when we try to add MDP5 device nodes). It also has different list of
clocks.

Update the bindings for MDP5.

Signed-off-by: Archit Taneja 
---
 Documentation/devicetree/bindings/drm/msm/mdp.txt | 23 ---
 1 file changed, 16 insertions(+), 7 deletions(-)

diff --git a/Documentation/devicetree/bindings/drm/msm/mdp.txt 
b/Documentation/devicetree/bindings/drm/msm/mdp.txt
index 1a0598e..e926daa 100644
--- a/Documentation/devicetree/bindings/drm/msm/mdp.txt
+++ b/Documentation/devicetree/bindings/drm/msm/mdp.txt
@@ -3,18 +3,27 @@ Qualcomm adreno/snapdragon display controller
 Required properties:
 - compatible:
   * "qcom,mdp" - mdp4
+  * "qcom,mdss_mdp" - mdp5
 - reg: Physical base address and length of the controller's registers.
 - interrupts: The interrupt signal from the display controller.
 - connectors: array of phandles for output device(s)
 - clocks: device clocks
   See ../clocks/clock-bindings.txt for details.
-- clock-names: the following clocks are required:
-  * "core_clk"
-  * "iface_clk"
-  * "lut_clk"
-  * "src_clk"
-  * "hdmi_clk"
-  * "mpd_clk"
+- clock-names: the following clocks are required.
+  For MDP4:
+   * "core_clk"
+   * "iface_clk"
+   * "lut_clk"
+   * "src_clk"
+   * "hdmi_clk"
+   * "mdp_clk"
+  For MDP5:
+   * "bus_clk"
+   * "iface_clk"
+   * "core_clk_src"
+   * "core_clk"
+   * "lut_clk" (some MDP5 versions may not need this)
+   * "vsync_clk"
 
 Optional properties:
 - gpus: phandle for gpu device
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/2] arm64: dtsi: Add device nodes for GPU and MDSS on MSM8916

[Archit Taneja]

Add device nodes for gpu, mdp and dsi blocks.

The gpu and dsi nodes are missing the 'power-domains' property needed
for configuring GDSC. This needs to be added when its available.

Signed-off-by: Archit Taneja 
---
 arch/arm64/boot/dts/qcom/msm8916.dtsi | 105 ++
 1 file changed, 105 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi 
b/arch/arm64/boot/dts/qcom/msm8916.dtsi
index ac006e8..7807d77 100644
--- a/arch/arm64/boot/dts/qcom/msm8916.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8916.dtsi
@@ -391,6 +391,111 @@
interrupt-controller;
#interrupt-cells = <4>;
};
+
+   gpu: qcom,adreno-3xx@01c0 {
+   compatible = "qcom,adreno-3xx";
+   #stream-id-cells = <16>;
+   reg = <0x01c0 0x2>;
+   reg-names = "kgsl_3d0_reg_memory";
+   interrupts = ;
+   interrupt-names = "kgsl_3d0_irq";
+   clocks =
+   <&gcc GCC_OXILI_GFX3D_CLK>,
+   <&gcc GCC_OXILI_AHB_CLK>,
+   <&gcc GCC_OXILI_GMEM_CLK>,
+   <&gcc GCC_BIMC_GFX_CLK>,
+   <&gcc GCC_BIMC_GPU_CLK>,
+   <&gcc GFX3D_CLK_SRC>;
+   clock-names =
+   "core_clk",
+   "iface_clk",
+   "mem_clk",
+   "mem_iface_clk",
+   "alt_mem_iface_clk",
+   "gfx3d_clk_src";
+
+   qcom,chipid = <0x03000600>;
+   qcom,gpu-pwrlevels {
+   compatible = "qcom,gpu-pwrlevels";
+   qcom,gpu-pwrlevel@0 {
+   qcom,gpu-freq = <4>;
+   };
+   qcom,gpu-pwrlevel@1 {
+   qcom,gpu-freq = <1920>;
+   };
+   };
+   };
+
+   mdss_mdp: qcom,mdss_mdp@1a0 {
+   compatible = "qcom,mdss_mdp";
+   reg = <0x1a0 0x9>,
+ <0x1ac8000 0x3000>;
+   reg-names = "mdp_phys",
+   "vbif_phys";
+   interrupts = ;
+
+   interrupt-controller;
+   #interrupt-cells = <1>;
+
+   connectors = <&mdss_dsi0>;
+   gpus = <&gpu>;
+
+   clocks = <&gcc GCC_MDSS_AHB_CLK>,
+<&gcc GCC_MDSS_AXI_CLK>,
+<&gcc MDP_CLK_SRC>,
+<&gcc GCC_MDSS_MDP_CLK>,
+<&gcc GCC_MDSS_VSYNC_CLK>;
+   clock-names = "iface_clk",
+ "bus_clk",
+ "core_clk_src",
+ "core_clk",
+ "vsync_clk";
+   };
+
+   mdss_dsi0: qcom,mdss_dsi@1a98000 {
+   compatible = "qcom,mdss-dsi-ctrl";
+   qcom,dsi-host-index = <0>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0x1a98000 0x25c>;
+   reg-names = "dsi_ctrl";
+   interrupt-parent = <&mdss_mdp>;
+   interrupts = <4 IRQ_TYPE_NONE>;
+
+   clocks = <&gcc GCC_MDSS_MDP_CLK>,
+<&gcc GCC_MDSS_AHB_CLK>,
+<&gcc GCC_MDSS_AXI_CLK>,
+<&gcc GCC_MDSS_BYTE0_CLK>,
+<&gcc GCC_MDSS_PCLK0_CLK>,
+<&gcc GCC_MDSS_ESC0_CLK>,
+<&gcc BYTE0_CLK_SRC>,
+<&gcc PCLK0_CLK_SRC>;
+   clock-names = "mdp_core_clk",
+ "iface_clk",
+ "bus_clk",
+ "byte_clk&q

Re: [PATCH RFC 5/8] drm: hisilicon: fill interface function of encoder\connector part

[Archit Taneja]

On 9/15/2015 3:07 PM, Xinwei Kong wrote:

This patch enables the adv7533 module which is connecting hisilicon SOC
by dsi module. while using DSI module and adv7533 module to implement the
encoder/connector interface of DRM\KMS.

Signed-off-by: Xinliang Liu 
Signed-off-by: Xinwei Kong 
Signed-off-by: Andy Green 
Signed-off-by: Jiwen Qi 
Signed-off-by: Yu Gong 
---
  drivers/gpu/drm/hisilicon/Kconfig  |  10 +
  drivers/gpu/drm/hisilicon/hisi_drm_connector.c |  34 ++
  drivers/gpu/drm/hisilicon/hisi_drm_connector.h |   8 +
  drivers/gpu/drm/hisilicon/hisi_drm_dsi.c   | 670 +
  drivers/gpu/drm/hisilicon/hisi_drm_encoder.c   |  52 ++
  drivers/gpu/drm/hisilicon/hisi_drm_encoder.h   |  19 +
  drivers/gpu/drm/hisilicon/hisi_dsi_reg.h   |  91 
  7 files changed, 884 insertions(+)
  create mode 100644 drivers/gpu/drm/hisilicon/hisi_dsi_reg.h






+struct hisi_connector_funcs hisi_dsi_connector_ops = {
+   .get_modes = dsi_connector_get_modes,
+};
+
+struct hisi_encoder_funcs hisi_dsi_encoder_ops = {
+   .mode_set = dsi_encoder_mode_set,
+   .enable = dsi_encoder_enable,
+   .disable = dsi_encoder_disable,
+};
+
  static int hisi_dsi_bind(struct device *dev, struct device *master,
 void *data)
  {
@@ -52,8 +682,23 @@ static int hisi_dsi_bind(struct device *dev, struct device 
*master,

hisi_drm_encoder_init(ctx->dev, &ctx->dsi.hisi_encoder.base.base);

+#ifdef CONFIG_DRM_HISI_HAS_SLAVE_ENCODER
+   ret = ctx->drm_i2c_driver->encoder_init(ctx->client, ctx->dev,
+   &ctx->dsi.hisi_encoder.base);
+   if (ret) {
+   DRM_ERROR("fail to init drm i2c encoder\n");
+   return ret;
+   }
+
+   if (!ctx->dsi.hisi_encoder.base.slave_funcs) {
+   DRM_ERROR("failed check encoder function\n");
+   return -ENODEV;
+   }
+#endif


A slave encoder isn't supposed to be used this way. A slave encoder is
supposed to register itself to drm as an encoder object. A slave
encoder connects directly to a crtc, and operate like a normal encoder.
In other words, a slave encoder isn't something that attaches to a
'master' encoder as the driver does here. 'Slave encoder' here means
that the encoder is a part of a different bus (like i2c etc).

Currently, the driver is directly calling slave encoder ops in 
hisi_drm_encoder.c.




+
hisi_drm_connector_init(ctx->dev, &ctx->dsi.hisi_encoder.base.base,
&ctx->dsi.hisi_connector.connector);
+
return ret;
  }

@@ -102,6 +747,27 @@ static int hisi_dsi_probe(struct platform_device *pdev)
return -EINVAL;
}

+#ifdef CONFIG_DRM_HISI_HAS_SLAVE_ENCODER
+   ctx->client = of_find_i2c_device_by_node(slave_node);
+   of_node_put(slave_node);
+   if (!ctx->client) {
+   DRM_ERROR("failed to find slave encoder i2c client\n");
+   return -EPROBE_DEFER;
+   }
+
+   if (!ctx->client->dev.driver) {
+   DRM_ERROR("%s: NULL client driver\n", __func__);
+   return -EPROBE_DEFER;
+   }
+
+   ctx->drm_i2c_driver = to_drm_i2c_encoder_driver(
+   to_i2c_driver(ctx->client->dev.driver));
+   if (IS_ERR(ctx->drm_i2c_driver)) {
+   DRM_ERROR("failed to initialize encoder driver");
+   return -EPROBE_DEFER;
+   }
+#endif
+
dsi = &ctx->dsi;
dsi->ctx = ctx;
dsi->lanes = 3;
@@ -110,6 +776,10 @@ static int hisi_dsi_probe(struct platform_device *pdev)
dsi->format = MIPI_DSI_FMT_RGB888;
dsi->mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_SYNC_PULSE;

+   dsi->hisi_encoder.ops = &hisi_dsi_encoder_ops;
+   dsi->hisi_connector.encoder = &dsi->hisi_encoder.base.base;
+   dsi->hisi_connector.ops = &hisi_dsi_connector_ops;
+
return component_add(&pdev->dev, &hisi_dsi_ops);
  }

diff --git a/drivers/gpu/drm/hisilicon/hisi_drm_encoder.c 
b/drivers/gpu/drm/hisilicon/hisi_drm_encoder.c
index 89fc73d..acd73d8 100644
--- a/drivers/gpu/drm/hisilicon/hisi_drm_encoder.c
+++ b/drivers/gpu/drm/hisilicon/hisi_drm_encoder.c
@@ -15,18 +15,49 @@

  #include "hisi_drm_encoder.h"

+#define to_hisi_encoder(encoder) \
+   container_of(encoder, struct hisi_encoder, base.base)
+
  void hisi_drm_encoder_disable(struct drm_encoder *encoder)
  {
+   struct hisi_encoder *hencoder = to_hisi_encoder(encoder);
+   struct hisi_encoder_funcs *ops = hencoder->ops;
+   struct drm_encoder_slave_funcs *sfuncs = get_slave_funcs(encoder);
+
+   if (ops->enable)
+   ops->disable(encoder);
+
+   if (sfuncs && sfuncs->dpms)
+   sfuncs->dpms(encoder, DRM_MODE_DPMS_OFF);
  }



The encoder should represent only the DSI encoder hardware here. It
shouldn't be calling slave encoder ops.

What you want is to have the encoder connect to a bridge. Something
like:

crtc(ade)->enco

Re: [PATCH RFC 2/8] drm: hisilicon: Add new DRM driver for hisilicon Soc

[Archit Taneja]

Hi,

On 9/15/2015 3:07 PM, Xinwei Kong wrote:

This patch creates this driver itself and register all the sub-components
which is from DTS inode, this driver uses components framework mechanism
to bind all the sub-components.

This patch also introduces a memory manager for hisilison drm. As cma
framebuffer helpers can no more be used.

Signed-off-by: Xinliang Liu 
Signed-off-by: Xinwei Kong 
Signed-off-by: Andy Green 
Signed-off-by: Jiwen Qi 
Signed-off-by: Yu Gong 
---
  arch/arm64/configs/defconfig |   5 +
  drivers/gpu/drm/Kconfig  |   2 +
  drivers/gpu/drm/Makefile |   1 +
  drivers/gpu/drm/hisilicon/Kconfig|   9 ++
  drivers/gpu/drm/hisilicon/Makefile   |   7 ++
  drivers/gpu/drm/hisilicon/hisi_ade.c | 166 +
  drivers/gpu/drm/hisilicon/hisi_drm_drv.c | 206 +++
  drivers/gpu/drm/hisilicon/hisi_drm_dsi.c | 131 
  drivers/gpu/drm/hisilicon/hisi_drm_fb.c  | 156 +++
  drivers/gpu/drm/hisilicon/hisi_drm_fb.h  |  26 
  10 files changed, 709 insertions(+)
  create mode 100644 drivers/gpu/drm/hisilicon/Kconfig
  create mode 100644 drivers/gpu/drm/hisilicon/Makefile
  create mode 100644 drivers/gpu/drm/hisilicon/hisi_ade.c
  create mode 100644 drivers/gpu/drm/hisilicon/hisi_drm_drv.c
  create mode 100644 drivers/gpu/drm/hisilicon/hisi_drm_dsi.c
  create mode 100644 drivers/gpu/drm/hisilicon/hisi_drm_fb.c
  create mode 100644 drivers/gpu/drm/hisilicon/hisi_drm_fb.h






diff --git a/drivers/gpu/drm/hisilicon/hisi_drm_dsi.c 
b/drivers/gpu/drm/hisilicon/hisi_drm_dsi.c
new file mode 100644
index 000..a8dbaad
--- /dev/null
+++ b/drivers/gpu/drm/hisilicon/hisi_drm_dsi.c
@@ -0,0 +1,131 @@
+/*
+ * Hisilicon Terminal SoCs drm driver
+ *
+ * Copyright (c) 2014-2015 Hisilicon Limited.
+ * Author: Xinwei Kong  for hisilicon
+ *
+ * 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 
+
+#define DSI_24BITS_1   (5)
+
+struct hisi_dsi {
+   u32 lanes;
+   u32 format;
+   u32 date_enable_pol;
+   u32 mode_flags;
+   u8 color_mode;
+   void *ctx;
+};
+
+struct hisi_dsi_context {
+   struct hisi_dsi dsi;
+   struct clk *dsi_cfg_clk;
+   struct drm_device *dev;
+
+   void __iomem *base;
+   int nominal_pixel_clk_kHz;
+};
+
+static int hisi_dsi_bind(struct device *dev, struct device *master,
+void *data)
+{
+   int ret = 0;
+
+   return ret;
+}
+
+static void hisi_dsi_unbind(struct device *dev, struct device *master,
+   void *data)
+{
+   /* do nothing */
+}
+
+static const struct component_ops hisi_dsi_ops = {
+   .bind   = hisi_dsi_bind,
+   .unbind = hisi_dsi_unbind,
+};
+
+static int hisi_dsi_probe(struct platform_device *pdev)
+{
+   struct hisi_dsi_context *ctx;
+   struct hisi_dsi *dsi;
+   struct resource *res;
+   struct device_node *slave_node;
+   struct device_node *np = pdev->dev.of_node;
+   int ret;
+
+   ctx = devm_kzalloc(&pdev->dev, sizeof(*ctx), GFP_KERNEL);
+   if (!ctx) {
+   DRM_ERROR("failed to allocate hisi dsi context.\n");
+   ret = -ENOMEM;
+   }
+
+   ctx->dsi_cfg_clk = devm_clk_get(&pdev->dev, "pclk_dsi");
+   if (IS_ERR(ctx->dsi_cfg_clk)) {
+   DRM_ERROR("failed to parse the dsi config clock\n");
+   ret = PTR_ERR(ctx->dsi_cfg_clk);
+   }
+
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+   ctx->base = devm_ioremap_resource(&pdev->dev, res);
+   if (IS_ERR(ctx->base)) {
+   DRM_ERROR("failed to remap dsi io region\n");
+   ret = PTR_ERR(ctx->base);
+   }
+
+   slave_node = of_parse_phandle(np, "encoder-slave", 0);
+   if (!slave_node) {
+   DRM_ERROR("failed to parse the slave encoder node\n");
+   return -EINVAL;
+   }
+
+   dsi = &ctx->dsi;
+   dsi->ctx = ctx;
+   dsi->lanes = 3;
+   dsi->date_enable_pol = 0;
+   dsi->color_mode = DSI_24BITS_1;
+   dsi->format = MIPI_DSI_FMT_RGB888;
+   dsi->mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_SYNC_PULSE;
+
+   return component_add(&pdev->dev, &hisi_dsi_ops);
+}
+


The DSI driver should register the dsi host via 
mipi_dsi_host_register(). That's the standard way of establishing a

connection between a host and dsi peripherals.

The dsi_context approach isn't something that will work very well.
With this approach, you're forced to set DSI parameters like number of
lanes, format, mode flags etc in the host driver, rather than receiving
them from the connected device.

Archit

--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Colla

Re: [RFC 0/2] drm/dsi: DSI for devices with different control bus

[Archit Taneja]

On 9/15/2015 9:13 PM, Rob Herring wrote:

On 09/15/2015 05:32 AM, Archit Taneja wrote:

Hi Rob, Mark,

We've been trying to figure out the right way to represent a class
of display encoder devices in DT.


I've been meaning to reply on this.


These devices have registers that are generally configured via i2c. Once
the device is configured, it takes in video data from the mipi
dsi bus.

Until now, all the devices we've supported devices that can be are
configured by the dsi bus itself, and hence, we've been able to
represent them in DT as children under the dsi host.

For the above class of devices (using both i2c and dsi), we aren't
able to conclude upon what's the better approach among the two:

1. Represent the device via 2 different nodes in DT. One would be
a child under an i2c adapter, the other a child of a dsi host. We
would have two device drivers, one i2c client, and the other a
mipi dsi device.

2. Represent the device as an i2c client in DT. Provide an api
to create "dummy" dsi devices. The i2c client driver would use
this api to register a dsi device, and link itself with the dsi
host.

What do you think would be the way to go here? I guess you
might have faced something similar in other subsystems.


The closest thing I can think of are WiFi/BT combo chips that use
SDIO+UART. In that case, 2 nodes makes sense as these chips are
essentially 2 independent functions in a single chip and both interfaces
are control interfaces (as well as data). This case is a bit different
with both interfaces being tied to the same function.

So in this case, I think option 2 is the right way for the reasons
already outlined in this thread. I think there needs to be more
consistency in how the of-graph connections are defined with the core
doing more of the graph traversing. So having an i2c device plus
of-graph seems more consistent with other non-DSI cases.

The main open issue seemed to be setting the VC. At least for the
ADV7533, it can be whatever you want it to be. The host and device just
need to agree. I see no need for that to be in DT at least in this case.
But then I'm not sure what are typical constraints for VC assignment.
I'd guess that constraints are on the device side and hosts can support
whatever the device wants. If so, then it can purely be up to the driver
to set.


2 DSI devices connected to the same host shouldn't have the same VC.
When representing the DSI nodes via DT, we use the 'reg' property to
assign the VC.

Although, in practice, we don't generally have multiple devices
on the same bus. The trend is to have multiple DSI hosts on the
platform to support more devices.

If we have checks that ensures the DT way and the new manual way
of creation of DSI devices doesn't result in having conflicting VCs
for devices, we should be okay.



Implementation-wise, I don't think that I'd call this a dummy device.
There are multiple ways for devices to get created in the driver model.
DT is just one way. You are just creating the device in a different way
outside of DT which is fine.



Thanks for the feedback.

Archit

--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH RFC 1/8] dt-bindings: Document the hi6220 bindings for DRM driver

[Archit Taneja]

Hi,

On 09/16/2015 02:04 PM, Xinwei Kong wrote:

hi architt

On 2015/9/16 2:11, Rob Herring wrote:

On 09/15/2015 04:37 AM, Xinwei Kong wrote:

This adds documentation of device tree bindings for the
Graphics Processing Unit of hi6220 SOC.

Signed-off-by: Xinliang Liu 
Signed-off-by: Xinwei Kong 
Signed-off-by: Andy Green 
Signed-off-by: Jiwen Qi 
Signed-off-by: Yu Gong 
---
  .../devicetree/bindings/gpu/hisilicon,hi6220.txt   | 69 ++
  1 file changed, 69 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/gpu/hisilicon,hi6220.txt

diff --git a/Documentation/devicetree/bindings/gpu/hisilicon,hi6220.txt 
b/Documentation/devicetree/bindings/gpu/hisilicon,hi6220.txt
new file mode 100644
index 000..173ac63
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpu/hisilicon,hi6220.txt
@@ -0,0 +1,69 @@
+ * Hisilicon hi6220 Graphics Processing Unit for HiKey board
+
+ ** display-subsystem: Master device for binding DRM sub-components


DRM is a Linuxism that doesn't belong in the binding.


+This master device is parent node and it will be responsible to bind all
+sub-components devices node.


Are these nodes a single block in the h/w? If not, you should describe
the connection of sub-nodes with of-graph instead.


+- Required properties :
+  - compatible: "hisilicon,display-subsystem".
+  - #address-cells, #size-cells: Must be present if the device has 
sub-nodes.
+  - ranges: to allow probing of subdevices.
+  - dma-coherent: Present if dma operations are coherent.
+
+ ** ade: Graphic overlay, Graphic post-processing, display timing control.
+This device is child node of display-subsystem
+- Required properties :
+  - compatible: "hisilicon,hi6220-ade".
+  - reg: physical base address of the ADE register and length of memory
+   region.
+  - reg-names: Should contain the reg names "ade_base" and "media_base".
+  - interrupt: The interrupt number to the cpu. Defines the interrupt
+by ADE.
+  - clocks: The clocks needed by the ADE module.
+  - clock-names: the name of the clocks.
+
+ ** dsi: support mipi dsi interface
+This device is child node of display-subsystem
+- Required properties :
+  - compatible: "hisilicon,hi6220-dsi".
+  - reg: physical base address of the DSI register and length of memory
+   region.
+  - clocks: The clocks needed by the DSI module.
+  - clock-names: the name of the clocks.
+  -encoder-slave: phandles to a 'encoder-slave' subnode which DSI 
connect
+ADV7533 in order to support hdmi display.


What the ADV7533 binding looks like is still being discussed.
"encoder-slave" is certainly DRM specific and not how it should be done.
Most likely, this needs to use the of-graph ports.


I dont how to implement the encoder bridge stuff in upstream,
you think that I will how to handle this part?


You can use of-graph ports to link the dsi output with the adv7533
bridge.

An example of the binding looks like:

Documentation/devicetree/bindings/drm/msm/dsi.txt

The implementation of this on the dsi host side of drm/msm
can be found in dsi_host_parse_dt, in:

drivers/gpu/drm/msm/dsi/dsi_host.c

You can get to know more about of-graph parsing here:

Documentation/devicetree/bindings/graph.txt

I'd started going through the drm/hisil patches. I'll
share more comments there.

Thanks,
Archit



Thank you
xinwei


Also, the ADV7533 connection is specific to HiKey. This binding should
just generically describe how any bridge or panel is connected.

Rob

.



--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html



--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 0/2] drm/dsi: DSI for devices with different control bus

[Archit Taneja]

Hi Rob, Mark,

We've been trying to figure out the right way to represent a class
of display encoder devices in DT.

These devices have registers that are generally configured via i2c. Once 
the device is configured, it takes in video data from the mipi

dsi bus.

Until now, all the devices we've supported devices that can be are
configured by the dsi bus itself, and hence, we've been able to
represent them in DT as children under the dsi host.

For the above class of devices (using both i2c and dsi), we aren't
able to conclude upon what's the better approach among the two:

1. Represent the device via 2 different nodes in DT. One would be
a child under an i2c adapter, the other a child of a dsi host. We
would have two device drivers, one i2c client, and the other a
mipi dsi device.

2. Represent the device as an i2c client in DT. Provide an api
to create "dummy" dsi devices. The i2c client driver would use
this api to register a dsi device, and link itself with the dsi
host.

What do you think would be the way to go here? I guess you
might have faced something similar in other subsystems.

I've given a relatively brief description of the problem. There
were some more nitty gritties discussed in this thread before.

Thierry, Andrzej, Lucas,

Please feel free to add your comments if I have missed out on
something.

Thanks,
Archit

On 09/10/2015 01:02 PM, Thierry Reding wrote:

On Thu, Sep 10, 2015 at 11:45:35AM +0530, Archit Taneja wrote:



On 09/08/2015 03:57 PM, Andrzej Hajda wrote:

On 09/07/2015 01:46 PM, Archit Taneja wrote:

Thierry,

On 08/21/2015 11:39 AM, Archit Taneja wrote:



On 08/20/2015 05:18 PM, Thierry Reding wrote:

On Thu, Aug 20, 2015 at 09:46:14AM +0530, Archit Taneja wrote:

Hi Thierry, Lucas,


On 08/19/2015 08:32 PM, Thierry Reding wrote:

On Wed, Aug 19, 2015 at 04:52:24PM +0200, Lucas Stach wrote:

Am Mittwoch, den 19.08.2015, 16:34 +0200 schrieb Thierry Reding:

On Wed, Aug 19, 2015 at 04:17:08PM +0200, Lucas Stach wrote:

Hi Thierry, Archit,


[...]

Perhaps a better way would be to invert this relationship.
According to
your proposal we'd have to have DT like this:

 i2c@... {
 ...

 dsi-device@... {
 ...
 dsi-bus = <&dsi>;
 ...
 };

 ...
 };

 dsi@... {
 ...
 };

Inversing the relationship would become something like this:

 i2c@... {
 ...
 };

 dsi@... {
 ...

 peripheral@... {
 ...
 i2c-bus = <&i2c>;
 ...
 };

 ...
 };

Both of those aren't fundamentally different, and they both have
the
disavantage of lacking ways to transport configuration data that
the
other bus needs to instantiate the dummy device (such as the reg
property for example, denoting the I2C slave address or the DSI
VC).

So how about we create two devices in the device tree and fuse
them at
the driver level:

 i2c@... {
 ...

 i2cdsi: dsi-device@... {
 ...
 };

 ...
 };

 dsi@... {
 ...

 peripheral@... {
 ...
 control = <&i2cdsi>;
 ...
 };

 ...
 };

This way we'll get both an I2C device and a DSI device that we
can fully
describe using the standard device tree bindings. At driver time
we can
get the I2C device from the phandle in the control property of
the DSI
device and use it to execute I2C transactions.


I don't really like to see that you are inventing yet-another-way to
handle devices connected to multiple buses.

Devicetree is structured along the control buses, even if the
devices
are connected to multiple buses, in the DT they are always
children of
the bus that is used to control their registers from the CPUs
perspective. So a DSI encoder that is controlled through i2c is
clearly
a child of the i2c master controller and only of that one.


I think that's a flawed interpretation of what's going on here. The
device in fact has two interfaces: one is I2C, the other is DSI.
In my
opinion that's reason enough to represent it as two logical devices.


Does it really have 2 control interfaces that are used at the same
time?
Or is the DSI connection a passive data bus if the register control
happens through i2c?


The interfaces may not be used at the same time, and the DSI interface
may even be crippled, but the device is still addressable from the DSI
host controller, if for nothing else than for routing the video stream.


If you need to model connections between devices that are not
reflected
through the control bus hierarchy you should really consider
using the
standardized of-graph bindings.
(Documentation/devicetree/bindings/graph.txt)


The problem is that the original proposal would instantiate a dummy
device, so it wouldn't be represented in DT at all. So unless you
do add
two

Re: [RFC 0/2] drm/dsi: DSI for devices with different control bus

[Archit Taneja]

Hi Rob, Mark,

We've been trying to figure out the right way to represent a class
of display encoder devices in DT.

These devices have registers that are generally configured via i2c. Once 
the device is configured, it takes in video data from the mipi

dsi bus.

Until now, all the devices we've supported devices that can be are
configured by the dsi bus itself, and hence, we've been able to
represent them in DT as children under the dsi host.

For the above class of devices (using both i2c and dsi), we aren't
able to conclude upon what's the better approach among the two:

1. Represent the device via 2 different nodes in DT. One would be
a child under an i2c adapter, the other a child of a dsi host. We
would have two device drivers, one i2c client, and the other a
mipi dsi device.

2. Represent the device as an i2c client in DT. Provide an api
to create "dummy" dsi devices. The i2c client driver would use
this api to register a dsi device, and link itself with the dsi
host.

What do you think would be the way to go here? I guess you
might have faced something similar in other subsystems.

I've given a relatively brief description of the problem. There
were some more nitty gritties discussed in this thread before.

Thierry, Andrzej, Lucas,

Please feel free to add your comments if I have missed out on
something.

Thanks,
Archit

On 09/10/2015 01:02 PM, Thierry Reding wrote:

On Thu, Sep 10, 2015 at 11:45:35AM +0530, Archit Taneja wrote:



On 09/08/2015 03:57 PM, Andrzej Hajda wrote:

On 09/07/2015 01:46 PM, Archit Taneja wrote:

Thierry,

On 08/21/2015 11:39 AM, Archit Taneja wrote:



On 08/20/2015 05:18 PM, Thierry Reding wrote:

On Thu, Aug 20, 2015 at 09:46:14AM +0530, Archit Taneja wrote:

Hi Thierry, Lucas,


On 08/19/2015 08:32 PM, Thierry Reding wrote:

On Wed, Aug 19, 2015 at 04:52:24PM +0200, Lucas Stach wrote:

Am Mittwoch, den 19.08.2015, 16:34 +0200 schrieb Thierry Reding:

On Wed, Aug 19, 2015 at 04:17:08PM +0200, Lucas Stach wrote:

Hi Thierry, Archit,


[...]

Perhaps a better way would be to invert this relationship.
According to
your proposal we'd have to have DT like this:

 i2c@... {
 ...

 dsi-device@... {
 ...
 dsi-bus = <&dsi>;
 ...
 };

 ...
 };

 dsi@... {
 ...
 };

Inversing the relationship would become something like this:

 i2c@... {
 ...
 };

 dsi@... {
 ...

 peripheral@... {
 ...
 i2c-bus = <&i2c>;
 ...
 };

 ...
 };

Both of those aren't fundamentally different, and they both have
the
disavantage of lacking ways to transport configuration data that
the
other bus needs to instantiate the dummy device (such as the reg
property for example, denoting the I2C slave address or the DSI
VC).

So how about we create two devices in the device tree and fuse
them at
the driver level:

 i2c@... {
 ...

 i2cdsi: dsi-device@... {
 ...
 };

 ...
 };

 dsi@... {
 ...

 peripheral@... {
 ...
 control = <&i2cdsi>;
 ...
 };

 ...
 };

This way we'll get both an I2C device and a DSI device that we
can fully
describe using the standard device tree bindings. At driver time
we can
get the I2C device from the phandle in the control property of
the DSI
device and use it to execute I2C transactions.


I don't really like to see that you are inventing yet-another-way to
handle devices connected to multiple buses.

Devicetree is structured along the control buses, even if the
devices
are connected to multiple buses, in the DT they are always
children of
the bus that is used to control their registers from the CPUs
perspective. So a DSI encoder that is controlled through i2c is
clearly
a child of the i2c master controller and only of that one.


I think that's a flawed interpretation of what's going on here. The
device in fact has two interfaces: one is I2C, the other is DSI.
In my
opinion that's reason enough to represent it as two logical devices.


Does it really have 2 control interfaces that are used at the same
time?
Or is the DSI connection a passive data bus if the register control
happens through i2c?


The interfaces may not be used at the same time, and the DSI interface
may even be crippled, but the device is still addressable from the DSI
host controller, if for nothing else than for routing the video stream.


If you need to model connections between devices that are not
reflected
through the control bus hierarchy you should really consider
using the
standardized of-graph bindings.
(Documentation/devicetree/bindings/graph.txt)


The problem is that the original proposal would instantiate a dummy
device, so it wouldn't be represented in DT at all. So unless you
do add
two

Re: [RFC 0/2] drm/dsi: DSI for devices with different control bus

[Archit Taneja]

On 09/08/2015 03:57 PM, Andrzej Hajda wrote:

On 09/07/2015 01:46 PM, Archit Taneja wrote:

Thierry,

On 08/21/2015 11:39 AM, Archit Taneja wrote:



On 08/20/2015 05:18 PM, Thierry Reding wrote:

On Thu, Aug 20, 2015 at 09:46:14AM +0530, Archit Taneja wrote:

Hi Thierry, Lucas,


On 08/19/2015 08:32 PM, Thierry Reding wrote:

On Wed, Aug 19, 2015 at 04:52:24PM +0200, Lucas Stach wrote:

Am Mittwoch, den 19.08.2015, 16:34 +0200 schrieb Thierry Reding:

On Wed, Aug 19, 2015 at 04:17:08PM +0200, Lucas Stach wrote:

Hi Thierry, Archit,


[...]

Perhaps a better way would be to invert this relationship.
According to
your proposal we'd have to have DT like this:

 i2c@... {
 ...

 dsi-device@... {
 ...
 dsi-bus = <&dsi>;
 ...
 };

 ...
 };

 dsi@... {
 ...
 };

Inversing the relationship would become something like this:

 i2c@... {
 ...
 };

 dsi@... {
 ...

 peripheral@... {
 ...
 i2c-bus = <&i2c>;
 ...
 };

 ...
 };

Both of those aren't fundamentally different, and they both have
the
disavantage of lacking ways to transport configuration data that
the
other bus needs to instantiate the dummy device (such as the reg
property for example, denoting the I2C slave address or the DSI
VC).

So how about we create two devices in the device tree and fuse
them at
the driver level:

 i2c@... {
 ...

 i2cdsi: dsi-device@... {
 ...
 };

 ...
 };

 dsi@... {
 ...

 peripheral@... {
 ...
 control = <&i2cdsi>;
 ...
 };

 ...
 };

This way we'll get both an I2C device and a DSI device that we
can fully
describe using the standard device tree bindings. At driver time
we can
get the I2C device from the phandle in the control property of
the DSI
device and use it to execute I2C transactions.


I don't really like to see that you are inventing yet-another-way to
handle devices connected to multiple buses.

Devicetree is structured along the control buses, even if the
devices
are connected to multiple buses, in the DT they are always
children of
the bus that is used to control their registers from the CPUs
perspective. So a DSI encoder that is controlled through i2c is
clearly
a child of the i2c master controller and only of that one.


I think that's a flawed interpretation of what's going on here. The
device in fact has two interfaces: one is I2C, the other is DSI.
In my
opinion that's reason enough to represent it as two logical devices.


Does it really have 2 control interfaces that are used at the same
time?
Or is the DSI connection a passive data bus if the register control
happens through i2c?


The interfaces may not be used at the same time, and the DSI interface
may even be crippled, but the device is still addressable from the DSI
host controller, if for nothing else than for routing the video stream.


If you need to model connections between devices that are not
reflected
through the control bus hierarchy you should really consider
using the
standardized of-graph bindings.
(Documentation/devicetree/bindings/graph.txt)


The problem is that the original proposal would instantiate a dummy
device, so it wouldn't be represented in DT at all. So unless you
do add
two logical devices to DT (one for each bus interface), you don't
have
anything to glue together with an OF graph.


I see that the having dummy device is the least desirable solution.
But
if there is only one control bus to the device I think it should be
one
device sitting beneath the control bus.

You can then use of-graph to model the data path between the DSI
encoder
and device.


But you will be needing a device below the DSI host controller to
represent that endpoint of the connection. The DSI host controller
itself is in no way connected to the I2C adapter. You would have to
add some sort of quirk to the DSI controller binding to allow it to


Thanks for the review.

I implemented this to support ADV7533 DSI to HDMI encoder chip, which
has a DSI video bus and an i2c control bus.

There weren't any quirks as such in the device tree when I tried to
implement this. The DT seems to manage fine without a node
corresponding to a mipi_dsi_device:

i2c_adap@.. {
 adv7533@.. {

 port {
 adv_in: endpoint {
 remote-endpoint = <&dsi_out>;
 };
 };
 };
};

dsi_host@.. {
 ...
 ...

 port {
 dsi_out: endpoint {
 remote-endpoint = <&adv_in>;
 }
 };
};

It's the i2c driver's job to parse the graph and retrieve the
phandle to the dsi host. Using this, it can proceed with
registering itself to this host using the new dsi funcs. This
patch does the s

Re: [RFC 0/2] drm/dsi: DSI for devices with different control bus

[Archit Taneja]

Thierry,

On 08/21/2015 11:39 AM, Archit Taneja wrote:



On 08/20/2015 05:18 PM, Thierry Reding wrote:

On Thu, Aug 20, 2015 at 09:46:14AM +0530, Archit Taneja wrote:

Hi Thierry, Lucas,


On 08/19/2015 08:32 PM, Thierry Reding wrote:

On Wed, Aug 19, 2015 at 04:52:24PM +0200, Lucas Stach wrote:

Am Mittwoch, den 19.08.2015, 16:34 +0200 schrieb Thierry Reding:

On Wed, Aug 19, 2015 at 04:17:08PM +0200, Lucas Stach wrote:

Hi Thierry, Archit,


[...]

Perhaps a better way would be to invert this relationship.
According to
your proposal we'd have to have DT like this:

i2c@... {
...

dsi-device@... {
...
dsi-bus = <&dsi>;
...
};

...
};

dsi@... {
...
};

Inversing the relationship would become something like this:

i2c@... {
...
};

dsi@... {
...

peripheral@... {
...
i2c-bus = <&i2c>;
...
};

...
};

Both of those aren't fundamentally different, and they both have
the
disavantage of lacking ways to transport configuration data that
the
other bus needs to instantiate the dummy device (such as the reg
property for example, denoting the I2C slave address or the DSI
VC).

So how about we create two devices in the device tree and fuse
them at
the driver level:

i2c@... {
...

i2cdsi: dsi-device@... {
...
};

...
};

dsi@... {
...

peripheral@... {
...
control = <&i2cdsi>;
...
};

...
};

This way we'll get both an I2C device and a DSI device that we
can fully
describe using the standard device tree bindings. At driver time
we can
get the I2C device from the phandle in the control property of
the DSI
device and use it to execute I2C transactions.


I don't really like to see that you are inventing yet-another-way to
handle devices connected to multiple buses.

Devicetree is structured along the control buses, even if the
devices
are connected to multiple buses, in the DT they are always
children of
the bus that is used to control their registers from the CPUs
perspective. So a DSI encoder that is controlled through i2c is
clearly
a child of the i2c master controller and only of that one.


I think that's a flawed interpretation of what's going on here. The
device in fact has two interfaces: one is I2C, the other is DSI.
In my
opinion that's reason enough to represent it as two logical devices.


Does it really have 2 control interfaces that are used at the same
time?
Or is the DSI connection a passive data bus if the register control
happens through i2c?


The interfaces may not be used at the same time, and the DSI interface
may even be crippled, but the device is still addressable from the DSI
host controller, if for nothing else than for routing the video stream.


If you need to model connections between devices that are not
reflected
through the control bus hierarchy you should really consider
using the
standardized of-graph bindings.
(Documentation/devicetree/bindings/graph.txt)


The problem is that the original proposal would instantiate a dummy
device, so it wouldn't be represented in DT at all. So unless you
do add
two logical devices to DT (one for each bus interface), you don't
have
anything to glue together with an OF graph.


I see that the having dummy device is the least desirable solution.
But
if there is only one control bus to the device I think it should be
one
device sitting beneath the control bus.

You can then use of-graph to model the data path between the DSI
encoder
and device.


But you will be needing a device below the DSI host controller to
represent that endpoint of the connection. The DSI host controller
itself is in no way connected to the I2C adapter. You would have to
add some sort of quirk to the DSI controller binding to allow it to


Thanks for the review.

I implemented this to support ADV7533 DSI to HDMI encoder chip, which
has a DSI video bus and an i2c control bus.

There weren't any quirks as such in the device tree when I tried to
implement this. The DT seems to manage fine without a node
corresponding to a mipi_dsi_device:

i2c_adap@.. {
adv7533@.. {

port {
adv_in: endpoint {
remote-endpoint = <&dsi_out>;
};
};
};
};

dsi_host@.. {
...
...

port {
dsi_out: endpoint {
remote-endpoint = <&adv_in>;
}
};
};

It's the i2c driver's job to parse the graph and retrieve the
phandle to the dsi host. Using this, it can proceed with
registering itself to this host using the new dsi funcs. This
patch does the same for the adv7533 i2c driver:

http://www.spinics.net/lists/dri-devel/msg86840.html


hook up with a control endpoint. And then you'll need m

Re: [RFC 0/2] drm/dsi: DSI for devices with different control bus

[Archit Taneja]

On 08/20/2015 05:18 PM, Thierry Reding wrote:

On Thu, Aug 20, 2015 at 09:46:14AM +0530, Archit Taneja wrote:

Hi Thierry, Lucas,


On 08/19/2015 08:32 PM, Thierry Reding wrote:

On Wed, Aug 19, 2015 at 04:52:24PM +0200, Lucas Stach wrote:

Am Mittwoch, den 19.08.2015, 16:34 +0200 schrieb Thierry Reding:

On Wed, Aug 19, 2015 at 04:17:08PM +0200, Lucas Stach wrote:

Hi Thierry, Archit,


[...]

Perhaps a better way would be to invert this relationship. According to
your proposal we'd have to have DT like this:

i2c@... {
...

dsi-device@... {
...
dsi-bus = <&dsi>;
...
};

...
};

dsi@... {
...
};

Inversing the relationship would become something like this:

i2c@... {
...
};

dsi@... {
...

peripheral@... {
...
i2c-bus = <&i2c>;
...
};

...
};

Both of those aren't fundamentally different, and they both have the
disavantage of lacking ways to transport configuration data that the
other bus needs to instantiate the dummy device (such as the reg
property for example, denoting the I2C slave address or the DSI VC).

So how about we create two devices in the device tree and fuse them at
the driver level:

i2c@... {
...

i2cdsi: dsi-device@... {
...
};

...
};

dsi@... {
...

peripheral@... {
...
control = <&i2cdsi>;
...
};

...
};

This way we'll get both an I2C device and a DSI device that we can fully
describe using the standard device tree bindings. At driver time we can
get the I2C device from the phandle in the control property of the DSI
device and use it to execute I2C transactions.


I don't really like to see that you are inventing yet-another-way to
handle devices connected to multiple buses.

Devicetree is structured along the control buses, even if the devices
are connected to multiple buses, in the DT they are always children of
the bus that is used to control their registers from the CPUs
perspective. So a DSI encoder that is controlled through i2c is clearly
a child of the i2c master controller and only of that one.


I think that's a flawed interpretation of what's going on here. The
device in fact has two interfaces: one is I2C, the other is DSI. In my
opinion that's reason enough to represent it as two logical devices.


Does it really have 2 control interfaces that are used at the same time?
Or is the DSI connection a passive data bus if the register control
happens through i2c?


The interfaces may not be used at the same time, and the DSI interface
may even be crippled, but the device is still addressable from the DSI
host controller, if for nothing else than for routing the video stream.


If you need to model connections between devices that are not reflected
through the control bus hierarchy you should really consider using the
standardized of-graph bindings.
(Documentation/devicetree/bindings/graph.txt)


The problem is that the original proposal would instantiate a dummy
device, so it wouldn't be represented in DT at all. So unless you do add
two logical devices to DT (one for each bus interface), you don't have
anything to glue together with an OF graph.


I see that the having dummy device is the least desirable solution. But
if there is only one control bus to the device I think it should be one
device sitting beneath the control bus.

You can then use of-graph to model the data path between the DSI encoder
and device.


But you will be needing a device below the DSI host controller to
represent that endpoint of the connection. The DSI host controller
itself is in no way connected to the I2C adapter. You would have to
add some sort of quirk to the DSI controller binding to allow it to


Thanks for the review.

I implemented this to support ADV7533 DSI to HDMI encoder chip, which
has a DSI video bus and an i2c control bus.

There weren't any quirks as such in the device tree when I tried to
implement this. The DT seems to manage fine without a node
corresponding to a mipi_dsi_device:

i2c_adap@.. {
adv7533@.. {

port {
adv_in: endpoint {
remote-endpoint = <&dsi_out>;
};
};
};
};

dsi_host@.. {
...
...

port {
dsi_out: endpoint {
remote-endpoint = <&adv_in>;
}

Re: [PATCH v3 0/14] Add Analogix Core Display Port Driver

[Archit Taneja]

Hi,

On 08/19/2015 08:18 PM, Yakir Yang wrote:


Hi all,
The Samsung Exynos eDP controller and Rockchip RK3288 eDP controller
share the same IP, so a lot of parts can be re-used. I split the common
code into bridge directory, then rk3288 and exynos only need to keep
some platform code. Cause I can't find the exact IP name of exynos dp
controller, so I decide to name dp core driver with "analogix" which I
find in rk3288 eDP TRM ;)

Beyond that, there are three light registers setting differents bewteen
exynos and rk3288.
1. RK3288 have five special pll resigters which not indicata in exynos
dp controller.
2. The address of DP_PHY_PD(dp phy power manager register) are different
between rk3288 and exynos.
3. Rk3288 and exynos have different setting with AUX_HW_RETRY_CTL(dp debug
register).

I have verified this series on two kinds of rockchip platform board, one
is rk3288 sdk board which connect with a 2K display port monitor, the other
is google jerry chromebook which connect with a eDP screen "cnm,n116bgeea2",
both of them works rightlly.

I haven't verified the dp function on samsung platform, cause I haven't got
exynos boards. I can only ensure that there are no build error on samsung
platform, wish some samsung guys help to test. ;)

Thanks,
- Yakir

Changes in v3:
- Take Thierry Reding suggest, move exynos's video_timing code
   to analogix_dp-exynos platform driver, add get_modes method
   to struct analogix_dp_plat_data.
- Take Heiko suggest, rename some "samsung*" dts propery to "analogix*".
- Take Thierry Reding suggest, dynamic parse video timing info from
   struct drm_display_mode and struct drm_display_info.
- Take Thierry Reding suggest, link_rate and lane_count shouldn't config to
   the DT property value directly, but we can take those as hardware limite.
   For example, RK3288 only support 4 physical lanes of 2.7/1.62 Gbps/lane,
   so DT property would like "link-rate = 0x0a" "lane-count = 4".
- Take Heiko suggest, add devicetree binding documents.
- Take Thierry Reding suggest, remove sync pol & colorimetry properies
   from the new analogix dp driver devicetree binding.
- Update the exist exynos dtsi file with the latest DP DT properies.
- Take Thierry Reding and Heiko suggest, leave "sclk_edp_24m" to rockchip
   dp phy driver which name to "24m", and leave "sclk_edp" to analogix dp
   core driver which name to "dp", and leave "pclk_edp" to rockchip dp platform
   driver which name to "pclk".
- Take Heiko suggest, add devicetree binding document.
- Take Heiko suggest, remove "rockchip,panel" DT property, take use of remote
   point to get panel node.
- Add the new function point analogix_dp_platdata.get_modes init.
- Take Heiko suggest, add rockchip dp phy driver,
   collect the phy clocks and power control.
- Add "analogix,need-force-hpd" to indicate whether driver need foce
   hpd when hpd detect failed.
- move dp hpd detect to connector detect function.
- Add edid modes parse support

Changes in v2:
- Take Joe Preches advise, improved commit message more readable, and
   avoid using some uncommon style like bellow:
   -  retval = exynos_dp_read_bytes_from_i2c(...
...)
   +  retval =
   +  exynos_dp_read_bytes_from_i2c(..);
- Take Jingoo Han suggest, just remove my name from author list.
- Take Jingoo Han suggest, remove new copyright
- Fix compiled failed dut to analogix_dp_device misspell
- Take Heiko suggest, get panel node with remote-endpoint method,
   and create devicetree binding for driver.
- Remove the clock enable/disbale with "sclk_edp" & "sclk_edp_24m",
   leave those clock to rockchip dp phy driver.
- Add GNU license v2 declared and samsung copyright
- Fix compile failed dut to phy_pd_addr variable misspell error

Yakir Yang (14):
   drm: exynos/dp: fix code style
   drm: exynos/dp: convert to drm bridge mode
   drm: bridge: analogix_dp: split exynos dp driver to bridge dir
   drm: bridge/analogix_dp: dynamic parse sync_pol & interlace &
 colorimetry
   drm: bridge/analogix_dp: fix link_rate & lane_count bug
   Documentation: drm/bridge: add document for analogix_dp
   drm: rockchip/dp: add rockchip platform dp driver
   phy: Add driver for rockchip Display Port PHY
   drm: bridge/analogix_dp: add platform device type support
   drm: bridge: analogix_dp: add some rk3288 special registers setting
   drm: bridge: analogix_dp: try force hpd after plug in lookup failed
   drm: bridge/analogix_dp: expand the delay time for hpd detect
   drm: bridge/analogix_dp: move hpd detect to connector detect function
   drm: bridge/analogix_dp: add edid modes parse in get_modes method

  .../devicetree/bindings/drm/bridge/analogix_dp.txt |   73 +
  .../devicetree/bindings/phy/rockchip-dp-phy.txt|   26 +
  .../bindings/video/analogix_dp-rockchip.txt|   83 ++
  .../devicetree/bindings/video/exynos_dp.txt|   51 +-
  arch/arm/boot/dts/exynos5250-arndale.dts   |   10 +-
  arch/arm/boot/dts/exynos5250-smdk5250.dt

[PATCH v4 5/5] arm: qcom: dts: Enable NAND node on IPQ8064 AP148 platform

[Archit Taneja]

Enable the NAND controller node on the AP148 platform. Provide pinmux
information.

v4:
- Move bias-disable out of mux and create a separate group for it.
- Place the dma node inside soc node and give the full path with address.

v3, v2, v1:
- No changes

Cc: devicetree@vger.kernel.org

Signed-off-by: Archit Taneja 
---
 arch/arm/boot/dts/qcom-ipq8064-ap148.dts | 40 
 1 file changed, 40 insertions(+)

diff --git a/arch/arm/boot/dts/qcom-ipq8064-ap148.dts 
b/arch/arm/boot/dts/qcom-ipq8064-ap148.dts
index 7f9ea50..648994c 100644
--- a/arch/arm/boot/dts/qcom-ipq8064-ap148.dts
+++ b/arch/arm/boot/dts/qcom-ipq8064-ap148.dts
@@ -30,6 +30,32 @@
bias-none;
};
};
+   nand_pins: nand_pins {
+   mux {
+   pins = "gpio34", "gpio35", "gpio36",
+  "gpio37", "gpio38", "gpio39",
+  "gpio40", "gpio41", "gpio42",
+  "gpio43", "gpio44", "gpio45",
+  "gpio46", "gpio47";
+   function = "nand";
+   drive-strength = <10>;
+   };
+   disable {
+   pins = "gpio34", "gpio35", "gpio36",
+  "gpio37", "gpio38";
+   bias-disable;
+   };
+   pullups {
+   pins = "gpio39";
+   bias-pull-up;
+   };
+   hold {
+   pins = "gpio40", "gpio41", "gpio42",
+  "gpio43", "gpio44", "gpio45",
+  "gpio46", "gpio47";
+   bias-bus-hold;
+   };
+   };
};
 
gsbi@1630 {
@@ -93,5 +119,19 @@
sata@2900 {
status = "ok";
};
+
+   dma@1830 {
+   status = "ok";
+   };
+
+   nand@1ac0 {
+   status = "ok";
+
+   pinctrl-0 = <&nand_pins>;
+   pinctrl-names = "default";
+
+   nand-ecc-strength = <4>;
+   nand-bus-width = <8>;
+   };
};
 };
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4 3/5] dt/bindings: qcom_nandc: Add DT bindings

[Archit Taneja]

Add DT bindings document for the Qualcomm NAND controller driver.

Cc: devicetree@vger.kernel.org

v4:
- No changes

v3:
- Don't use '0x' when specifying nand controller address space
- Add optional property for on-flash bbt usage

Acked-by: Andy Gross 
Signed-off-by: Archit Taneja 
---
 .../devicetree/bindings/mtd/qcom_nandc.txt | 49 ++
 1 file changed, 49 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mtd/qcom_nandc.txt

diff --git a/Documentation/devicetree/bindings/mtd/qcom_nandc.txt 
b/Documentation/devicetree/bindings/mtd/qcom_nandc.txt
new file mode 100644
index 000..1de4643
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/qcom_nandc.txt
@@ -0,0 +1,49 @@
+* Qualcomm NAND controller
+
+Required properties:
+- compatible:  should be "qcom,ebi2-nand" for IPQ806x
+- reg: MMIO address range
+- clocks:  must contain core clock and always on clock
+- clock-names: must contain "core" for the core clock and "aon" for the
+   always on clock
+- dmas:DMA specifier, consisting of a phandle to the 
ADM DMA
+   controller node and the channel number to be used for
+   NAND. Refer to dma.txt and qcom_adm.txt for more details
+- dma-names:   must be "rxtx"
+- qcom,cmd-crci:   must contain the ADM command type CRCI block instance
+   number specified for the NAND controller on the given
+   platform
+- qcom,data-crci:  must contain the ADM data type CRCI block instance
+   number specified for the NAND controller on the given
+   platform
+
+Optional properties:
+- nand-bus-width:  bus width. Must be 8 or 16. If not present, 8 is chosen
+   as default
+
+- nand-ecc-strength:   number of bits to correct per ECC step. Must be 4 or 8
+   bits. If not present, 4 is chosen as default
+- nand-on-flash-bbt:   Create/use on-flash bad block table
+
+The device tree may optionally contain sub-nodes describing partitions of the
+address space. See partition.txt for more detail.
+
+Example:
+
+nand@1ac0 {
+   compatible = "qcom,ebi2-nandc";
+   reg = <0x1ac0 0x800>;
+
+   clocks = <&gcc EBI2_CLK>,
+<&gcc EBI2_AON_CLK>;
+   clock-names = "core", "aon";
+
+   dmas = <&adm_dma 3>;
+   dma-names = "rxtx";
+   qcom,cmd-crci = <15>;
+   qcom,data-crci = <3>;
+
+   partition@0 {
+   ...
+   };
+};
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4 4/5] arm: qcom: dts: Add NAND controller node for ipq806x

[Archit Taneja]

The nand controller in IPQ806x is of the 'EBI2 type'. Use the corresponding
compatible string.

Cc: devicetree@vger.kernel.org

Reviewed-by: Andy Gross 
Signed-off-by: Archit Taneja 
---
 arch/arm/boot/dts/qcom-ipq8064.dtsi | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/arch/arm/boot/dts/qcom-ipq8064.dtsi 
b/arch/arm/boot/dts/qcom-ipq8064.dtsi
index 1e1b3f0..a7f0ee5 100644
--- a/arch/arm/boot/dts/qcom-ipq8064.dtsi
+++ b/arch/arm/boot/dts/qcom-ipq8064.dtsi
@@ -350,5 +350,20 @@
status = "disabled";
};
 
+   nand@1ac0 {
+   compatible = "qcom,ebi2-nandc";
+   reg = <0x1ac0 0x800>;
+
+   clocks = <&gcc EBI2_CLK>,
+<&gcc EBI2_AON_CLK>;
+   clock-names = "core", "aon";
+
+   dmas = <&adm_dma 3>;
+   dma-names = "rxtx";
+   qcom,cmd-crci = <15>;
+   qcom,data-crci = <3>;
+
+   status = "disabled";
+   };
};
 };
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 5/5] arm: qcom: dts: Enable NAND node on IPQ8064 AP148 platform

[Archit Taneja]

On 8/4/2015 1:05 AM, Andy Gross wrote:

On Mon, Aug 03, 2015 at 10:38:18AM +0530, Archit Taneja wrote:

Enable the NAND controller node on the AP148 platform. Provide pinmux
information.

Cc: devicetree@vger.kernel.org

Signed-off-by: Archit Taneja 
---
  arch/arm/boot/dts/qcom-ipq8064-ap148.dts | 36 
  1 file changed, 36 insertions(+)

diff --git a/arch/arm/boot/dts/qcom-ipq8064-ap148.dts 
b/arch/arm/boot/dts/qcom-ipq8064-ap148.dts
index 7f9ea50..2e88eff 100644
--- a/arch/arm/boot/dts/qcom-ipq8064-ap148.dts
+++ b/arch/arm/boot/dts/qcom-ipq8064-ap148.dts
@@ -30,6 +30,28 @@
bias-none;
};
};
+   nand_pins: nand_pins {
+   mux {
+   pins = "gpio34", "gpio35", "gpio36",
+  "gpio37", "gpio38", "gpio39",
+  "gpio40", "gpio41", "gpio42",
+  "gpio43", "gpio44", "gpio45",
+  "gpio46", "gpio47";
+   function = "nand";
+   drive-strength = <10>;
+   bias-disable;
+   };
+   pullups {
+   pins = "gpio39";
+   bias-pull-up;
+   };
+   hold {
+   pins = "gpio40", "gpio41", "gpio42",
+  "gpio43", "gpio44", "gpio45",
+  "gpio46", "gpio47";
+   bias-bus-hold;


Maybe split out the bias-disable into a separate set and remove that property
from the mux.


I'll fix this.

Thanks,
Archit

--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 5/5] arm: qcom: dts: Enable NAND node on IPQ8064 AP148 platform

[Archit Taneja]

On 8/4/2015 2:28 AM, Stephen Boyd wrote:

On 08/03, Archit Taneja wrote:

@@ -93,5 +115,19 @@
sata@2900 {
status = "ok";
};
+
+   nand@1ac0 {
+   status = "ok";
+
+   pinctrl-0 = <&nand_pins>;
+   pinctrl-names = "default";
+
+   nand-ecc-strength = <4>;
+   nand-bus-width = <8>;
+   };
};
  };
+
+&adm_dma {
+   status = "ok";
+};


I think the preference is to put the full path to the device in
the dts file and then have status = "ok". So please move this
into the soc node and give the correct offset, etc. like we've
done for other nodes.


I'll do that.

Archit

--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 3/5] dt/bindings: qcom_nandc: Add DT bindings

[Archit Taneja]

Add DT bindings document for the Qualcomm NAND controller driver.

Cc: devicetree@vger.kernel.org

v3:
- Don't use '0x' when specifying nand controller address space
- Add optional property for on-flash bbt usage

Acked-by: Andy Gross 
Signed-off-by: Archit Taneja 
---
 .../devicetree/bindings/mtd/qcom_nandc.txt | 49 ++
 1 file changed, 49 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mtd/qcom_nandc.txt

diff --git a/Documentation/devicetree/bindings/mtd/qcom_nandc.txt 
b/Documentation/devicetree/bindings/mtd/qcom_nandc.txt
new file mode 100644
index 000..1de4643
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/qcom_nandc.txt
@@ -0,0 +1,49 @@
+* Qualcomm NAND controller
+
+Required properties:
+- compatible:  should be "qcom,ebi2-nand" for IPQ806x
+- reg: MMIO address range
+- clocks:  must contain core clock and always on clock
+- clock-names: must contain "core" for the core clock and "aon" for the
+   always on clock
+- dmas:DMA specifier, consisting of a phandle to the 
ADM DMA
+   controller node and the channel number to be used for
+   NAND. Refer to dma.txt and qcom_adm.txt for more details
+- dma-names:   must be "rxtx"
+- qcom,cmd-crci:   must contain the ADM command type CRCI block instance
+   number specified for the NAND controller on the given
+   platform
+- qcom,data-crci:  must contain the ADM data type CRCI block instance
+   number specified for the NAND controller on the given
+   platform
+
+Optional properties:
+- nand-bus-width:  bus width. Must be 8 or 16. If not present, 8 is chosen
+   as default
+
+- nand-ecc-strength:   number of bits to correct per ECC step. Must be 4 or 8
+   bits. If not present, 4 is chosen as default
+- nand-on-flash-bbt:   Create/use on-flash bad block table
+
+The device tree may optionally contain sub-nodes describing partitions of the
+address space. See partition.txt for more detail.
+
+Example:
+
+nand@1ac0 {
+   compatible = "qcom,ebi2-nandc";
+   reg = <0x1ac0 0x800>;
+
+   clocks = <&gcc EBI2_CLK>,
+<&gcc EBI2_AON_CLK>;
+   clock-names = "core", "aon";
+
+   dmas = <&adm_dma 3>;
+   dma-names = "rxtx";
+   qcom,cmd-crci = <15>;
+   qcom,data-crci = <3>;
+
+   partition@0 {
+   ...
+   };
+};
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 4/5] arm: qcom: dts: Add NAND controller node for ipq806x

[Archit Taneja]

The nand controller in IPQ806x is of the 'EBI2 type'. Use the corresponding
compatible string.

Cc: devicetree@vger.kernel.org

Reviewed-by: Andy Gross 
Signed-off-by: Archit Taneja 
---
 arch/arm/boot/dts/qcom-ipq8064.dtsi | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/arch/arm/boot/dts/qcom-ipq8064.dtsi 
b/arch/arm/boot/dts/qcom-ipq8064.dtsi
index 1e1b3f0..a7f0ee5 100644
--- a/arch/arm/boot/dts/qcom-ipq8064.dtsi
+++ b/arch/arm/boot/dts/qcom-ipq8064.dtsi
@@ -350,5 +350,20 @@
status = "disabled";
};
 
+   nand@1ac0 {
+   compatible = "qcom,ebi2-nandc";
+   reg = <0x1ac0 0x800>;
+
+   clocks = <&gcc EBI2_CLK>,
+<&gcc EBI2_AON_CLK>;
+   clock-names = "core", "aon";
+
+   dmas = <&adm_dma 3>;
+   dma-names = "rxtx";
+   qcom,cmd-crci = <15>;
+   qcom,data-crci = <3>;
+
+   status = "disabled";
+   };
};
 };
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 5/5] arm: qcom: dts: Enable NAND node on IPQ8064 AP148 platform

[Archit Taneja]

Enable the NAND controller node on the AP148 platform. Provide pinmux
information.

Cc: devicetree@vger.kernel.org

Signed-off-by: Archit Taneja 
---
 arch/arm/boot/dts/qcom-ipq8064-ap148.dts | 36 
 1 file changed, 36 insertions(+)

diff --git a/arch/arm/boot/dts/qcom-ipq8064-ap148.dts 
b/arch/arm/boot/dts/qcom-ipq8064-ap148.dts
index 7f9ea50..2e88eff 100644
--- a/arch/arm/boot/dts/qcom-ipq8064-ap148.dts
+++ b/arch/arm/boot/dts/qcom-ipq8064-ap148.dts
@@ -30,6 +30,28 @@
bias-none;
};
};
+   nand_pins: nand_pins {
+   mux {
+   pins = "gpio34", "gpio35", "gpio36",
+  "gpio37", "gpio38", "gpio39",
+  "gpio40", "gpio41", "gpio42",
+  "gpio43", "gpio44", "gpio45",
+  "gpio46", "gpio47";
+   function = "nand";
+   drive-strength = <10>;
+   bias-disable;
+   };
+   pullups {
+   pins = "gpio39";
+   bias-pull-up;
+   };
+   hold {
+   pins = "gpio40", "gpio41", "gpio42",
+  "gpio43", "gpio44", "gpio45",
+  "gpio46", "gpio47";
+   bias-bus-hold;
+   };
+   };
};
 
gsbi@1630 {
@@ -93,5 +115,19 @@
sata@2900 {
status = "ok";
};
+
+   nand@1ac0 {
+   status = "ok";
+
+   pinctrl-0 = <&nand_pins>;
+   pinctrl-names = "default";
+
+   nand-ecc-strength = <4>;
+   nand-bus-width = <8>;
+   };
};
 };
+
+&adm_dma {
+   status = "ok";
+};
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v1 7/7] ARM: dts: ifc6410: add inforce LVDS panel support

[Archit Taneja]

Hi Srini,

On 07/28/2015 06:24 PM, Srinivas Kandagatla wrote:

This patch adds LVDS panel for IFC6410.

Signed-off-by: Rob Clark 
[Rob Clark: WIP patch]
Signed-off-by: Srinivas Kandagatla 
---
  arch/arm/boot/dts/qcom-apq8064-ifc6410.dts | 66 ++
  1 file changed, 66 insertions(+)

diff --git a/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts 
b/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
index 1ab71f1..3bdac02 100644
--- a/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
+++ b/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
@@ -63,6 +63,12 @@
qcom,switch-mode-frequency = <320>;
};

+   pm8921_l2: l2 {
+   regulator-min-microvolt = <120>;
+   regulator-max-microvolt = <120>;
+   bias-pull-down;
+   };
+
pm8921_l3: l3 {
regulator-min-microvolt = <305>;
regulator-max-microvolt = <330>;
@@ -96,6 +102,10 @@
pm8921_lvs1: lvs1 {
bias-pull-down;
};
+
+   pm8921_lvs7: lvs7 {
+   bias-pull-down;
+   };
};
};

@@ -119,6 +129,41 @@

mdp: qcom,mdp@510 {
status = "okay";
+   qcom,lvds-panel = <&panel>;


We're trying to switch to the of_graph way of representing connected
panels. With that, the above phandle will go away. This needs to be 
replaced with:


port {
lvds_out: endpoint {
remote_endpoint = <&auo_in>;
};
};


+   lvds-vccs-3p3v-supply = <&ext_3p3v>;
+   lvds-pll-vdda-supply = <&pm8921_l2>;
+   lvds-vdda-supply = <&pm8921_lvs7>;
+   };
+
+   panel_3p3v: panel_3p3v {
+   compatible = "regulator-fixed";
+   pinctrl-0 = <&disp_en_gpios>;
+   pinctrl-names = "default";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   regulator-name = "panel_en_3p3v";
+   regulator-type = "voltage";
+   startup-delay-us = <0>;
+   gpio = <&pm8921_gpio 36 GPIO_ACTIVE_HIGH>;
+   enable-active-high;
+   regulator-boot-on;
+   };
+
+   backlight: backlight{
+   pinctrl-0 = <&pwm_bl_gpios>;
+   pinctrl-names = "default";
+   compatible = "gpio-backlight";
+   gpios = <&pm8921_gpio 26 GPIO_ACTIVE_HIGH>;
+   default-on;
+   };
+
+   panel: auo,b101xtn01 {
+   status = "okay";
+   compatible = "auo,b101xtn01";
+
+   ddc-i2c-bus = <&i2c3>;
+   backlight = <&backlight>;
+   power-supply = <&panel_3p3v>;


and for the panel:

port {
auo_in: endpoint {
remote-endpoint = <&lvds_out>;
};
};

Thanks,
Archit


};

gsbi3: gsbi@1620 {
@@ -235,6 +280,27 @@
pm8921_gpio: gpio@150 {
pinctrl-names = "default";
pinctrl-0 = <&wlan_default_gpios>;
+
+   pwm_bl_gpios: pwm-bl-gpios {
+   pios {
+   pins = "gpio26";
+   bias-disable;
+   function = "normal";
+   qcom,drive-strength = 
;
+   power-source = 
;
+   };
+   };
+
+   disp_en_gpios: disp-en-gpios {
+   pios {
+   pins = "gpio36";
+   bias-disable;
+   function = "normal"

[PATCH v2 3/5] dt/bindings: qcom_nandc: Add DT bindings

[Archit Taneja]

Add DT bindings document for the Qualcomm NAND controller driver.

Cc: devicetree@vger.kernel.org

Signed-off-by: Archit Taneja 
---
 .../devicetree/bindings/mtd/qcom_nandc.txt | 48 ++
 1 file changed, 48 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mtd/qcom_nandc.txt

diff --git a/Documentation/devicetree/bindings/mtd/qcom_nandc.txt 
b/Documentation/devicetree/bindings/mtd/qcom_nandc.txt
new file mode 100644
index 000..e24c77a
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/qcom_nandc.txt
@@ -0,0 +1,48 @@
+* Qualcomm NAND controller
+
+Required properties:
+- compatible:  should be "qcom,ebi2-nand" for IPQ806x
+- reg: MMIO address range
+- clocks:  must contain core clock and always on clock
+- clock-names: must contain "core" for the core clock and "aon" for the
+   always on clock
+- dmas:DMA specifier, consisting of a phandle to the 
ADM DMA
+   controller node and the channel number to be used for
+   NAND. Refer to dma.txt and qcom_adm.txt for more details
+- dma-names:   must be "rxtx"
+- qcom,cmd-crci:   must contain the ADM command type CRCI block instance
+   number specified for the NAND controller on the given
+   platform
+- qcom,data-crci:  must contain the ADM data type CRCI block instance
+   number specified for the NAND controller on the given
+   platform
+
+Optional properties:
+- nand-bus-width:  bus width. Must be 8 or 16. If not present, 8 is chosen
+   as default
+
+- nand-ecc-strength:   number of bits to correct per ECC step. Must be 4 or 8
+   bits. If not present, 4 is chosen as default
+
+The device tree may optionally contain sub-nodes describing partitions of the
+address space. See partition.txt for more detail.
+
+Example:
+
+nand@0x1ac0 {
+   compatible = "qcom,ebi2-nandc";
+   reg = <0x1ac0 0x800>;
+
+   clocks = <&gcc EBI2_CLK>,
+<&gcc EBI2_AON_CLK>;
+   clock-names = "core", "aon";
+
+   dmas = <&adm_dma 3>;
+   dma-names = "rxtx";
+   qcom,cmd-crci = <15>;
+   qcom,data-crci = <3>;
+
+   partition@0 {
+   ...
+   };
+};
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 4/5] arm: qcom: dts: Add NAND controller node for ipq806x

[Archit Taneja]

The nand controller in IPQ806x is of the 'EBI2 type'. Use the corresponding
compatible string.

Cc: devicetree@vger.kernel.org
Signed-off-by: Archit Taneja 
---
 arch/arm/boot/dts/qcom-ipq8064.dtsi | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/arch/arm/boot/dts/qcom-ipq8064.dtsi 
b/arch/arm/boot/dts/qcom-ipq8064.dtsi
index 1e1b3f0..08dc2ef 100644
--- a/arch/arm/boot/dts/qcom-ipq8064.dtsi
+++ b/arch/arm/boot/dts/qcom-ipq8064.dtsi
@@ -350,5 +350,20 @@
status = "disabled";
};
 
+   nand@0x1ac0 {
+   compatible = "qcom,ebi2-nandc";
+   reg = <0x1ac0 0x800>;
+
+   clocks = <&gcc EBI2_CLK>,
+<&gcc EBI2_AON_CLK>;
+   clock-names = "core", "aon";
+
+   dmas = <&adm_dma 3>;
+   dma-names = "rxtx";
+   qcom,cmd-crci = <15>;
+   qcom,data-crci = <3>;
+
+   status = "disabled";
+   };
};
 };
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 5/5] arm: qcom: dts: Enale NAND node on IPQ8064 AP148 platform

[Archit Taneja]

Enable the NAND controller node on the AP148 platform. Provide pinmux
information.

Cc: devicetree@vger.kernel.org
Signed-off-by: Archit Taneja 
---
 arch/arm/boot/dts/qcom-ipq8064-ap148.dts | 36 
 1 file changed, 36 insertions(+)

diff --git a/arch/arm/boot/dts/qcom-ipq8064-ap148.dts 
b/arch/arm/boot/dts/qcom-ipq8064-ap148.dts
index 7f9ea50..03fd6b7 100644
--- a/arch/arm/boot/dts/qcom-ipq8064-ap148.dts
+++ b/arch/arm/boot/dts/qcom-ipq8064-ap148.dts
@@ -30,6 +30,28 @@
bias-none;
};
};
+   nand_pins: nand_pins {
+   mux {
+   pins = "gpio34", "gpio35", "gpio36",
+  "gpio37", "gpio38", "gpio39",
+  "gpio40", "gpio41", "gpio42",
+  "gpio43", "gpio44", "gpio45",
+  "gpio46", "gpio47";
+   function = "nand";
+   drive-strength = <10>;
+   bias-disable;
+   };
+   pullups {
+   pins = "gpio39";
+   bias-pull-up;
+   };
+   hold {
+   pins = "gpio40", "gpio41", "gpio42",
+  "gpio43", "gpio44", "gpio45",
+  "gpio46", "gpio47";
+   bias-bus-hold;
+   };
+   };
};
 
gsbi@1630 {
@@ -93,5 +115,19 @@
sata@2900 {
status = "ok";
};
+
+   nand@0x1ac0 {
+   status = "ok";
+
+   pinctrl-0 = <&nand_pins>;
+   pinctrl-names = "default";
+
+   nand-ecc-strength = <4>;
+   nand-bus-width = <8>;
+   };
};
 };
+
+&adm_dma {
+   status = "ok";
+};
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Patch v6 2/2] dmaengine: Add ADM driver

[Archit Taneja]

Hi,

On 03/17/2015 11:16 AM, Andy Gross wrote:

Add the DMA engine driver for the QCOM Application Data Mover (ADM) DMA
controller found in the MSM8x60 and IPQ/APQ8064 platforms.

The ADM supports both memory to memory transactions and memory
to/from peripheral device transactions.  The controller also provides flow
control capabilities for transactions to/from peripheral devices.

The initial release of this driver supports slave transfers to/from peripherals
and also incorporates CRCI (client rate control interface) flow control.

Signed-off-by: Andy Gross 
---
  drivers/dma/Kconfig|   10 +
  drivers/dma/Makefile   |1 +
  drivers/dma/qcom_adm.c |  900 
  3 files changed, 911 insertions(+)
  create mode 100644 drivers/dma/qcom_adm.c

diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index a874b6e..6919013 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -473,4 +473,14 @@ config QCOM_BAM_DMA
  Enable support for the QCOM BAM DMA controller.  This controller
  provides DMA capabilities for a variety of on-chip devices.

+config QCOM_ADM
+   tristate "Qualcomm ADM support"
+   depends on ARCH_QCOM || (COMPILE_TEST && OF && ARM)
+   select DMA_ENGINE
+   select DMA_VIRTUAL_CHANNELS
+   ---help---
+ Enable support for the Qualcomm ADM DMA controller.  This controller
+ provides DMA capabilities for both general purpose and on-chip
+ peripheral devices.
+
  endif
diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
index f915f61..7f0fbe6 100644
--- a/drivers/dma/Makefile
+++ b/drivers/dma/Makefile
@@ -51,3 +51,4 @@ obj-$(CONFIG_INTEL_MIC_X100_DMA) += mic_x100_dma.o
  obj-$(CONFIG_NBPFAXI_DMA) += nbpfaxi.o
  obj-$(CONFIG_DMA_SUN6I) += sun6i-dma.o
  obj-$(CONFIG_IMG_MDC_DMA) += img-mdc-dma.o
+obj-$(CONFIG_QCOM_ADM) += qcom_adm.o
diff --git a/drivers/dma/qcom_adm.c b/drivers/dma/qcom_adm.c
new file mode 100644
index 000..7f8c119
--- /dev/null
+++ b/drivers/dma/qcom_adm.c
@@ -0,0 +1,900 @@
+/*
+ * Copyright (c) 2013-2015, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "dmaengine.h"
+#include "virt-dma.h"
+
+/* ADM registers - calculated from channel number and security domain */
+#define ADM_CHAN_MULTI 0x4
+#define ADM_CI_MULTI   0x4
+#define ADM_CRCI_MULTI 0x4
+#define ADM_EE_MULTI   0x800
+#define ADM_CHAN_OFFS(chan)(ADM_CHAN_MULTI * chan)
+#define ADM_EE_OFFS(ee)(ADM_EE_MULTI * ee)
+#define ADM_CHAN_EE_OFFS(chan, ee) (ADM_CHAN_OFFS(chan) + ADM_EE_OFFS(ee))
+#define ADM_CHAN_OFFS(chan)(ADM_CHAN_MULTI * chan)
+#define ADM_CI_OFFS(ci)(ADM_CHAN_OFF(ci))
+#define ADM_CH_CMD_PTR(chan, ee)   (ADM_CHAN_EE_OFFS(chan, ee))
+#define ADM_CH_RSLT(chan, ee)  (0x40 + ADM_CHAN_EE_OFFS(chan, ee))
+#define ADM_CH_FLUSH_STATE0(chan, ee)  (0x80 + ADM_CHAN_EE_OFFS(chan, ee))
+#define ADM_CH_STATUS_SD(chan, ee) (0x200 + ADM_CHAN_EE_OFFS(chan, ee))
+#define ADM_CH_CONF(chan)  (0x240 + ADM_CHAN_OFFS(chan))
+#define ADM_CH_RSLT_CONF(chan, ee) (0x300 + ADM_CHAN_EE_OFFS(chan, ee))
+#define ADM_SEC_DOMAIN_IRQ_STATUS(ee)  (0x380 + ADM_EE_OFFS(ee))
+#define ADM_CI_CONF(ci)(0x390 + ci * ADM_CI_MULTI)
+#define ADM_GP_CTL 0x3d8
+#define ADM_CRCI_CTL(crci, ee) (0x400 + crci * ADM_CRCI_MULTI + \
+   ADM_EE_OFFS(ee))
+
+/* channel status */
+#define ADM_CH_STATUS_VALIDBIT(1)
+
+/* channel result */
+#define ADM_CH_RSLT_VALID  BIT(31)
+#define ADM_CH_RSLT_ERRBIT(3)
+#define ADM_CH_RSLT_FLUSH  BIT(2)
+#define ADM_CH_RSLT_TPDBIT(1)
+
+/* channel conf */
+#define ADM_CH_CONF_SHADOW_EN  BIT(12)
+#define ADM_CH_CONF_MPU_DISABLEBIT(11)
+#define ADM_CH_CONF_PERM_MPU_CONF  BIT(9)
+#define ADM_CH_CONF_FORCE_RSLT_EN  BIT(7)
+#define ADM_CH_CONF_SEC_DOMAIN(ee) (((ee & 0x3) << 4) | ((ee & 0x4) << 11))
+
+/* channel result conf */
+#define ADM_CH_RSLT_CONF_FLUSH_EN  BIT(1)
+#define ADM_CH_RSLT_CONF_IRQ_ENBIT(0)
+
+/* CRCI CTL */
+#define ADM_CRCI_CTL_MUX_SEL   BIT(18)
+#define ADM_CRCI_CTL_RST   

Re: [PATCH RFC v9 11/20] drm/bridge: Add Synopsys DesignWare MIPI DSI host controller driver

[Archit Taneja]

On 04/09/2015 02:13 PM, Thierry Reding wrote:

On Thu, Feb 12, 2015 at 02:01:34PM +0800, Liu Ying wrote:
[...]

diff --git a/drivers/gpu/drm/bridge/dw_mipi_dsi.c 
b/drivers/gpu/drm/bridge/dw_mipi_dsi.c

[...]

+struct dw_mipi_dsi {
+   struct mipi_dsi_host dsi_host;
+   struct drm_connector connector;
+   struct drm_encoder *encoder;
+   struct drm_bridge *bridge;
+   struct drm_panel *panel;
+   struct device *dev;
+
+   void __iomem *base;
+
+   struct clk *pllref_clk;
+   struct clk *cfg_clk;
+   struct clk *pclk;
+
+   unsigned int lane_mbps; /* per lane */
+   u32 channel;
+   u32 lanes;
+   u32 format;
+   struct drm_display_mode *mode;
+
+   const struct dw_mipi_dsi_plat_data *pdata;
+
+   bool enabled;
+};


While reviewing this I kept thinking whether this is really the right
architectural design. This driver is a MIPI DSI host, a connector and
a bridge, all in one. But it seems to me like it should really be an
encoder/connector and a MIPI DSI host. Why the need for a bridge? The
bridge abstraction targets blocks outside of the SoC, but it is my
understanding that these DesignWare IP blocks are designed into SoCs.



The msm driver uses bridges for blocks within the SoC too. We have too 
many sub blocks in the display controller that use up crtcs and encoder 
entities. A bridge is the only option one has if an encoder in the 
display chain is already taken.


In the above designware configuration, if some one created a board that 
used an external chip to further convert DSI to some other output 
format, then we would be completely exhausted of all entities.


I posted a patch that allows us to create a chain of bridges for such 
cases. It seems to work well as an interim solution. Ideally, it would 
be better if we could make bridge a special case of an encoder, and let 
one encoder connect to another encoder.


Such a thing would also help us unify i2c slave encoders and bridge 
drivers too. A chip designed as an i2c slave encoder would work well 
with a drm driver that doesn't have an encoder, but won't work for SoCs 
SoCs that already have an encoder and were expecting a bridge entity 
instead.


Archit

--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 4/5] arm: qcom: dts: Add NAND controller node for ipq806x

[Archit Taneja]

The nand controller in IPQ806x is of the 'EBI2 type'. Use the corresponding
compatible string.

Cc: devicetree@vger.kernel.org
Signed-off-by: Archit Taneja 
---
 arch/arm/boot/dts/qcom-ipq8064.dtsi | 19 ++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/qcom-ipq8064.dtsi 
b/arch/arm/boot/dts/qcom-ipq8064.dtsi
index 733b0f3..6ed0150 100644
--- a/arch/arm/boot/dts/qcom-ipq8064.dtsi
+++ b/arch/arm/boot/dts/qcom-ipq8064.dtsi
@@ -281,7 +281,7 @@
#reset-cells = <1>;
};
 
-   dma@1830 {
+   adm_dma: dma@1830 {
compatible = "qcom,adm";
reg = <0x1830 0x10>;
interrupts = <0 170 0>;
@@ -300,5 +300,22 @@
 
status = "disabled";
};
+
+   nand@0x1ac0 {
+   compatible = "qcom,ebi2-nandc";
+   reg = <0x1ac0 0x800>;
+
+   clocks = <&gcc EBI2_CLK>,
+<&gcc EBI2_AON_CLK>;
+   clock-names = "core", "aon";
+
+   dmas = <&adm_dma 3>;
+   dma-names = "rxtx";
+   qcom,cmd-crci = <15>;
+   qcom,data-crci = <3>;
+
+   status = "disabled";
+   };
+
};
 };
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 5/5] arm: qcom: dts: Enale NAND node on IPQ8064 AP148 pplatform

[Archit Taneja]

Enable the NAND controller node on the AP148 platform. Provide pinmux
information.

Cc: devicetree@vger.kernel.org
Signed-off-by: Archit Taneja 
---
 arch/arm/boot/dts/qcom-ipq8064-ap148.dts | 32 
 1 file changed, 32 insertions(+)

diff --git a/arch/arm/boot/dts/qcom-ipq8064-ap148.dts 
b/arch/arm/boot/dts/qcom-ipq8064-ap148.dts
index 1e1d0d8..82878bb 100644
--- a/arch/arm/boot/dts/qcom-ipq8064-ap148.dts
+++ b/arch/arm/boot/dts/qcom-ipq8064-ap148.dts
@@ -30,6 +30,28 @@
bias-none;
};
};
+   nand_pins: nand_pins {
+   mux {
+   pins = "gpio34", "gpio35", "gpio36",
+  "gpio37", "gpio38", "gpio39",
+  "gpio40", "gpio41", "gpio42",
+  "gpio43", "gpio44", "gpio45",
+  "gpio46", "gpio47";
+   function = "nand";
+   drive-strength = <10>;
+   bias-disable;
+   };
+   pullups {
+   pins = "gpio39";
+   bias-pull-up;
+   };
+   hold {
+   pins = "gpio40", "gpio41", "gpio42",
+  "gpio43", "gpio44", "gpio45",
+  "gpio46", "gpio47";
+   bias-bus-hold;
+   };
+   };
};
 
gsbi@1630 {
@@ -93,5 +115,15 @@
dma@1830 {
status = "ok";
};
+
+   nand@0x1ac0 {
+   status = "ok";
+
+   pinctrl-0 = <&nand_pins>;
+   pinctrl-names = "default";
+
+   nand-ecc-strength = <4>;
+   nand-bus-width = <8>;
+   };
};
 };
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3/5] Documentaion: dt: add DT bindings for Qualcomm NAND controller

[Archit Taneja]

Cc: devicetree@vger.kernel.org
Signed-off-by: Archit Taneja 
---
 .../devicetree/bindings/mtd/qcom_nandc.txt | 48 ++
 1 file changed, 48 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mtd/qcom_nandc.txt

diff --git a/Documentation/devicetree/bindings/mtd/qcom_nandc.txt 
b/Documentation/devicetree/bindings/mtd/qcom_nandc.txt
new file mode 100644
index 000..e24c77a
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/qcom_nandc.txt
@@ -0,0 +1,48 @@
+* Qualcomm NAND controller
+
+Required properties:
+- compatible:  should be "qcom,ebi2-nand" for IPQ806x
+- reg: MMIO address range
+- clocks:  must contain core clock and always on clock
+- clock-names: must contain "core" for the core clock and "aon" for the
+   always on clock
+- dmas:DMA specifier, consisting of a phandle to the 
ADM DMA
+   controller node and the channel number to be used for
+   NAND. Refer to dma.txt and qcom_adm.txt for more details
+- dma-names:   must be "rxtx"
+- qcom,cmd-crci:   must contain the ADM command type CRCI block instance
+   number specified for the NAND controller on the given
+   platform
+- qcom,data-crci:  must contain the ADM data type CRCI block instance
+   number specified for the NAND controller on the given
+   platform
+
+Optional properties:
+- nand-bus-width:  bus width. Must be 8 or 16. If not present, 8 is chosen
+   as default
+
+- nand-ecc-strength:   number of bits to correct per ECC step. Must be 4 or 8
+   bits. If not present, 4 is chosen as default
+
+The device tree may optionally contain sub-nodes describing partitions of the
+address space. See partition.txt for more detail.
+
+Example:
+
+nand@0x1ac0 {
+   compatible = "qcom,ebi2-nandc";
+   reg = <0x1ac0 0x800>;
+
+   clocks = <&gcc EBI2_CLK>,
+<&gcc EBI2_AON_CLK>;
+   clock-names = "core", "aon";
+
+   dmas = <&adm_dma 3>;
+   dma-names = "rxtx";
+   qcom,cmd-crci = <15>;
+   qcom,data-crci = <3>;
+
+   partition@0 {
+   ...
+   };
+};
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 2/3] dmaengine: qcom_bam_dma: Add BAM v1.3.0 support

[Archit Taneja]

We currently have register offset information only for BAM IPs with revision
1.4.0. We add register offset table entries for the legacy (v1.3.0) version
of BAM IPs found on SoCs like APQ8064 and MSM8960.

The register offset table pointers are stored in DT data corresponding to the
BAM IP version specified in the compatible string.

Reviewed-by: Kumar Gala 
Reviewed-by: Andy Gross 
Signed-off-by: Archit Taneja 
---
 drivers/dma/qcom_bam_dma.c | 58 +++---
 1 file changed, 50 insertions(+), 8 deletions(-)

diff --git a/drivers/dma/qcom_bam_dma.c b/drivers/dma/qcom_bam_dma.c
index b5a1662..777afd2 100644
--- a/drivers/dma/qcom_bam_dma.c
+++ b/drivers/dma/qcom_bam_dma.c
@@ -113,7 +113,36 @@ struct reg_offset_data {
unsigned int pipe_mult, evnt_mult, ee_mult;
 };
 
-static const struct reg_offset_data reg_info[] = {
+static const struct reg_offset_data bam_v1_3_reg_info[] = {
+   [BAM_CTRL]  = { 0x0F80, 0x00, 0x00, 0x00 },
+   [BAM_REVISION]  = { 0x0F84, 0x00, 0x00, 0x00 },
+   [BAM_NUM_PIPES] = { 0x0FBC, 0x00, 0x00, 0x00 },
+   [BAM_DESC_CNT_TRSHLD]   = { 0x0F88, 0x00, 0x00, 0x00 },
+   [BAM_IRQ_SRCS]  = { 0x0F8C, 0x00, 0x00, 0x00 },
+   [BAM_IRQ_SRCS_MSK]  = { 0x0F90, 0x00, 0x00, 0x00 },
+   [BAM_IRQ_SRCS_UNMASKED] = { 0x0FB0, 0x00, 0x00, 0x00 },
+   [BAM_IRQ_STTS]  = { 0x0F94, 0x00, 0x00, 0x00 },
+   [BAM_IRQ_CLR]   = { 0x0F98, 0x00, 0x00, 0x00 },
+   [BAM_IRQ_EN]= { 0x0F9C, 0x00, 0x00, 0x00 },
+   [BAM_CNFG_BITS] = { 0x0FFC, 0x00, 0x00, 0x00 },
+   [BAM_IRQ_SRCS_EE]   = { 0x1800, 0x00, 0x00, 0x80 },
+   [BAM_IRQ_SRCS_MSK_EE]   = { 0x1804, 0x00, 0x00, 0x80 },
+   [BAM_P_CTRL]= { 0x, 0x80, 0x00, 0x00 },
+   [BAM_P_RST] = { 0x0004, 0x80, 0x00, 0x00 },
+   [BAM_P_HALT]= { 0x0008, 0x80, 0x00, 0x00 },
+   [BAM_P_IRQ_STTS]= { 0x0010, 0x80, 0x00, 0x00 },
+   [BAM_P_IRQ_CLR] = { 0x0014, 0x80, 0x00, 0x00 },
+   [BAM_P_IRQ_EN]  = { 0x0018, 0x80, 0x00, 0x00 },
+   [BAM_P_EVNT_DEST_ADDR]  = { 0x102C, 0x00, 0x40, 0x00 },
+   [BAM_P_EVNT_REG]= { 0x1018, 0x00, 0x40, 0x00 },
+   [BAM_P_SW_OFSTS]= { 0x1000, 0x00, 0x40, 0x00 },
+   [BAM_P_DATA_FIFO_ADDR]  = { 0x1024, 0x00, 0x40, 0x00 },
+   [BAM_P_DESC_FIFO_ADDR]  = { 0x101C, 0x00, 0x40, 0x00 },
+   [BAM_P_EVNT_GEN_TRSHLD] = { 0x1028, 0x00, 0x40, 0x00 },
+   [BAM_P_FIFO_SIZES]  = { 0x1020, 0x00, 0x40, 0x00 },
+};
+
+static const struct reg_offset_data bam_v1_4_reg_info[] = {
[BAM_CTRL]  = { 0x, 0x00, 0x00, 0x00 },
[BAM_REVISION]  = { 0x0004, 0x00, 0x00, 0x00 },
[BAM_NUM_PIPES] = { 0x003C, 0x00, 0x00, 0x00 },
@@ -330,6 +359,8 @@ struct bam_device {
/* execution environment ID, from DT */
u32 ee;
 
+   const struct reg_offset_data *layout;
+
struct clk *bamclk;
int irq;
 
@@ -346,7 +377,7 @@ struct bam_device {
 static inline void __iomem *bam_addr(struct bam_device *bdev, u32 pipe,
enum bam_reg reg)
 {
-   const struct reg_offset_data r = reg_info[reg];
+   const struct reg_offset_data r = bdev->layout[reg];
 
return bdev->regs + r.base_offset +
r.pipe_mult * pipe +
@@ -1019,9 +1050,18 @@ static void bam_channel_init(struct bam_device *bdev, 
struct bam_chan *bchan,
bchan->vc.desc_free = bam_dma_free_desc;
 }
 
+static const struct of_device_id bam_of_match[] = {
+   { .compatible = "qcom,bam-v1.3.0", .data = &bam_v1_3_reg_info },
+   { .compatible = "qcom,bam-v1.4.0", .data = &bam_v1_4_reg_info },
+   {}
+};
+
+MODULE_DEVICE_TABLE(of, bam_of_match);
+
 static int bam_dma_probe(struct platform_device *pdev)
 {
struct bam_device *bdev;
+   const struct of_device_id *match;
struct resource *iores;
int ret, i;
 
@@ -1031,6 +1071,14 @@ static int bam_dma_probe(struct platform_device *pdev)
 
bdev->dev = &pdev->dev;
 
+   match = of_match_node(bam_of_match, pdev->dev.of_node);
+   if (!match) {
+   dev_err(&pdev->dev, "Unsupported BAM module\n");
+   return -ENODEV;
+   }
+
+   bdev->layout = match->data;
+
iores = platform_get_resource(pdev, IORESOURCE_MEM, 0);
bdev->regs = devm_ioremap_resource(&pdev->dev, iores);
if (IS_ERR(bdev->regs))
@@ -1154,12 +1202,6 @@ static int bam_dma_remove(struct platform_device *pdev)
return 0;
 }
 
-static const struct of_device_id bam_of_match[] = {
-   { .compatible = "qcom,bam-v1.4.0", },
-   {}
-};
-MODULE_DEVICE_TABLE(of, bam_of_match);
-
 static struct platform_driver bam_dma_driver = {
.probe = bam_dma_probe,
.remove = bam_dma_remove,
-- 
The Qualc

[PATCH v2 3/3] dt/bindings: dmaengine: qcom_bam_dma: Add compatible string for BAM v1.3.0

[Archit Taneja]

Add compatible string for BAM v1.3.0 in the DT bindings documentation. Mentioned
a few more SoCs which have BAM v1.4.0 in them.

Reviewed-by: Kumar Gala 
Reviewed-by: Andy Gross 
Signed-off-by: Archit Taneja 
---
Update in v2: Added IPQ8064 to the v1.3.0 list

 Documentation/devicetree/bindings/dma/qcom_bam_dma.txt | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/dma/qcom_bam_dma.txt 
b/Documentation/devicetree/bindings/dma/qcom_bam_dma.txt
index d75a9d7..f8c3311 100644
--- a/Documentation/devicetree/bindings/dma/qcom_bam_dma.txt
+++ b/Documentation/devicetree/bindings/dma/qcom_bam_dma.txt
@@ -1,7 +1,9 @@
 QCOM BAM DMA controller
 
 Required properties:
-- compatible: must contain "qcom,bam-v1.4.0" for MSM8974
+- compatible: must be one of the following:
+ * "qcom,bam-v1.4.0" for MSM8974, APQ8074 and APQ8084
+ * "qcom,bam-v1.3.0" for APQ8064, IPQ8064 and MSM8960
 - reg: Address range for DMA registers
 - interrupts: Should contain the one interrupt shared by all channels
 - #dma-cells: must be <1>, the cell in the dmas property of the client device
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 1/3] dmaengine: qcom_bam_dma: Generalize BAM register offset calculations

[Archit Taneja]

The BAM DMA IP comes in different versions. The register offset layout varies
among these versions. The layouts depend on which generation/family of SoCs they
belong to.

The current SoCs(like 8084, 8074) have a layout where the Top level registers
come in the beginning of the address range, followed by pipe and event
registers. The BAM revision numbers fall above 1.4.0.

The older SoCs (like 8064, 8960) have a layout where the pipe registers come
first, and the top level come later. These have BAM revision numbers lesser than
1.4.0.

It isn't suitable to have macros provide the register offsets with the layouts
changed. Future BAM revisions may have different register layouts too. The
register addresses are now calculated by referring a table which contains a base
offset and multipliers for pipe/evnt/ee registers.

We have a common function bam_addr() which computes addresses for all the
registers. When computing address of top level/ee registers, we pass 0 to the
pipe argument in addr() since they don't have any multiple instances.

Some of the unused register definitions are removed. We can add new registers as
we need them.

Reviewed-by: Kumar Gala 
Reviewed-by: Andy Gross 
Signed-off-by: Archit Taneja 
---
 drivers/dma/qcom_bam_dma.c | 176 +
 1 file changed, 113 insertions(+), 63 deletions(-)

diff --git a/drivers/dma/qcom_bam_dma.c b/drivers/dma/qcom_bam_dma.c
index 7a4bbb0..b5a1662 100644
--- a/drivers/dma/qcom_bam_dma.c
+++ b/drivers/dma/qcom_bam_dma.c
@@ -79,35 +79,68 @@ struct bam_async_desc {
struct bam_desc_hw desc[0];
 };
 
-#define BAM_CTRL   0x
-#define BAM_REVISION   0x0004
-#define BAM_SW_REVISION0x0080
-#define BAM_NUM_PIPES  0x003C
-#define BAM_TIMER  0x0040
-#define BAM_TIMER_CTRL 0x0044
-#define BAM_DESC_CNT_TRSHLD0x0008
-#define BAM_IRQ_SRCS   0x000C
-#define BAM_IRQ_SRCS_MSK   0x0010
-#define BAM_IRQ_SRCS_UNMASKED  0x0030
-#define BAM_IRQ_STTS   0x0014
-#define BAM_IRQ_CLR0x0018
-#define BAM_IRQ_EN 0x001C
-#define BAM_CNFG_BITS  0x007C
-#define BAM_IRQ_SRCS_EE(ee)(0x0800 + ((ee) * 0x80))
-#define BAM_IRQ_SRCS_MSK_EE(ee)(0x0804 + ((ee) * 0x80))
-#define BAM_P_CTRL(pipe)   (0x1000 + ((pipe) * 0x1000))
-#define BAM_P_RST(pipe)(0x1004 + ((pipe) * 0x1000))
-#define BAM_P_HALT(pipe)   (0x1008 + ((pipe) * 0x1000))
-#define BAM_P_IRQ_STTS(pipe)   (0x1010 + ((pipe) * 0x1000))
-#define BAM_P_IRQ_CLR(pipe)(0x1014 + ((pipe) * 0x1000))
-#define BAM_P_IRQ_EN(pipe) (0x1018 + ((pipe) * 0x1000))
-#define BAM_P_EVNT_DEST_ADDR(pipe) (0x182C + ((pipe) * 0x1000))
-#define BAM_P_EVNT_REG(pipe)   (0x1818 + ((pipe) * 0x1000))
-#define BAM_P_SW_OFSTS(pipe)   (0x1800 + ((pipe) * 0x1000))
-#define BAM_P_DATA_FIFO_ADDR(pipe) (0x1824 + ((pipe) * 0x1000))
-#define BAM_P_DESC_FIFO_ADDR(pipe) (0x181C + ((pipe) * 0x1000))
-#define BAM_P_EVNT_TRSHLD(pipe)(0x1828 + ((pipe) * 0x1000))
-#define BAM_P_FIFO_SIZES(pipe) (0x1820 + ((pipe) * 0x1000))
+enum bam_reg {
+   BAM_CTRL,
+   BAM_REVISION,
+   BAM_NUM_PIPES,
+   BAM_DESC_CNT_TRSHLD,
+   BAM_IRQ_SRCS,
+   BAM_IRQ_SRCS_MSK,
+   BAM_IRQ_SRCS_UNMASKED,
+   BAM_IRQ_STTS,
+   BAM_IRQ_CLR,
+   BAM_IRQ_EN,
+   BAM_CNFG_BITS,
+   BAM_IRQ_SRCS_EE,
+   BAM_IRQ_SRCS_MSK_EE,
+   BAM_P_CTRL,
+   BAM_P_RST,
+   BAM_P_HALT,
+   BAM_P_IRQ_STTS,
+   BAM_P_IRQ_CLR,
+   BAM_P_IRQ_EN,
+   BAM_P_EVNT_DEST_ADDR,
+   BAM_P_EVNT_REG,
+   BAM_P_SW_OFSTS,
+   BAM_P_DATA_FIFO_ADDR,
+   BAM_P_DESC_FIFO_ADDR,
+   BAM_P_EVNT_GEN_TRSHLD,
+   BAM_P_FIFO_SIZES,
+};
+
+struct reg_offset_data {
+   u32 base_offset;
+   unsigned int pipe_mult, evnt_mult, ee_mult;
+};
+
+static const struct reg_offset_data reg_info[] = {
+   [BAM_CTRL]  = { 0x, 0x00, 0x00, 0x00 },
+   [BAM_REVISION]  = { 0x0004, 0x00, 0x00, 0x00 },
+   [BAM_NUM_PIPES] = { 0x003C, 0x00, 0x00, 0x00 },
+   [BAM_DESC_CNT_TRSHLD]   = { 0x0008, 0x00, 0x00, 0x00 },
+   [BAM_IRQ_SRCS]  = { 0x000C, 0x00, 0x00, 0x00 },
+   [BAM_IRQ_SRCS_MSK]  = { 0x0010, 0x00, 0x00, 0x00 },
+   [BAM_IRQ_SRCS_UNMASKED] = { 0x0030, 0x00, 0x00, 0x00 },
+   [BAM_IRQ_STTS]  = { 0x0014, 0x00, 0x00, 0x00 },
+   [BAM_IRQ_CLR]   = { 0x0018, 0x00, 0x00, 0x00 },
+   [BAM_IRQ_EN]= { 0x001C, 0x00, 0x00, 0x00 },
+   [BAM_CNFG_BITS] = { 0x007C, 0x00, 0x00, 0x00 },
+   [BAM_IRQ_SRCS_EE]   = { 0x0800, 0x00, 0x00, 0x80 },
+   [BAM_IRQ_SRCS_MSK_EE]   = { 0x0804, 0x00, 

[PATCH 3/3] dt/bindings: dmaengine: qcom_bam_dma: Add compatible string for BAM v1.3.0

[Archit Taneja]

Add compatible string for BAM v1.3.0 in the DT bindings documentation. Mentioned
a few more SoCs which have BAM v1.4.0 in them.

Cc: devicetree@vger.kernel.org
Signed-off-by: Archit Taneja 
---
 Documentation/devicetree/bindings/dma/qcom_bam_dma.txt | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/dma/qcom_bam_dma.txt 
b/Documentation/devicetree/bindings/dma/qcom_bam_dma.txt
index d75a9d7..83c8e57 100644
--- a/Documentation/devicetree/bindings/dma/qcom_bam_dma.txt
+++ b/Documentation/devicetree/bindings/dma/qcom_bam_dma.txt
@@ -1,7 +1,9 @@
 QCOM BAM DMA controller
 
 Required properties:
-- compatible: must contain "qcom,bam-v1.4.0" for MSM8974
+- compatible: must be one of the following:
+ * "qcom,bam-v1.4.0" for MSM8974, APQ8074 and APQ8084
+ * "qcom,bam-v1.3.0" for APQ8064 and MSM8960
 - reg: Address range for DMA registers
 - interrupts: Should contain the one interrupt shared by all channels
 - #dma-cells: must be <1>, the cell in the dmas property of the client device
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 5/5] Doc/DT: hdmi-connector: add HPD GPIO documentation

[Archit Taneja]

Hi,

On Friday 09 May 2014 06:02 PM, Tomi Valkeinen wrote:

Add binding documentation for HDMI connector's HPD GPIO.

Signed-off-by: Tomi Valkeinen 
Cc: devicetree@vger.kernel.org
---
  Documentation/devicetree/bindings/video/hdmi-connector.txt | 1 +
  1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/video/hdmi-connector.txt 
b/Documentation/devicetree/bindings/video/hdmi-connector.txt
index c19e2573..acd5668b1ce1 100644
--- a/Documentation/devicetree/bindings/video/hdmi-connector.txt
+++ b/Documentation/devicetree/bindings/video/hdmi-connector.txt
@@ -7,6 +7,7 @@ Required properties:

  Optional properties:
  - label: a symbolic name for the connector
+- hpd-gpios: HPD GPIO number


Would there ever be more than one HPD gpio?

Archit

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V5 0/3] arm: dts: dra7: Updates for adding crossbar device

[Archit Taneja]

On Wednesday 07 May 2014 03:15 AM, Darren Etheridge wrote:

Sricharan R  wrote on Tue [2014-May-06 19:26:16 +0530]:

Some socs have a large number of interrupts requests to service
the needs of its many peripherals and subsystems. All of the interrupt
requests lines from the subsystems are not needed at the same
time, so they have to be muxed to the controllers appropriately.
In such places a interrupt controllers are preceded by an
IRQ CROSSBAR that provides flexibility in muxing the device interrupt
requests to the controller inputs.

The dts file update to support the crossbar device and convert
peripheral irq numbers to crossbar number are added here.

This is a rebase of V4 series on top of 3.15-rc4

This series depends on crossbar-driver-fixes sent below
http://marc.info/?l=linux-omap&m=139929963420299&w=2

Sricharan R (3):
   arm: dts: dra7: Add crossbar device binding
   arm: dts: dra7: Replace peripheral interrupt numbers with crossbar
 inputs
   arm: dts: dra7: Add routable-irqs property for gic node



OK, assuming the bisectability issues discussed earlier on this thread
are addressed.  I have tested the earlier crossbar patch series in
conjunction with this dts series with VIP capture and DSS display
running together on DRA7.  Looks good with this combination of
devices. VIP is one of the modules that must have a crossbar mapping as
there is no default interrupt mapping for it, therefore VIP makes a good
test case.

So please feel free to add:

Tested-by: Darren Etheridge 


DMM doesn't get used by default since it's hwmod is missing in DRA7x's 
hwmod data. I added the hwmod and tried using dmm with omapdrm, it works 
fine.


So, for DSS and DMM:

Tested-by: Archit Taneja 





  arch/arm/boot/dts/dra7.dtsi |  109 +--
  1 file changed, 63 insertions(+), 46 deletions(-)

--
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html



--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 1/2] arm: dts: omap4+: Add DMM bindings

[Archit Taneja]

On Tuesday 11 March 2014 12:45 PM, Tomi Valkeinen wrote:

Hi,

On 15/10/13 10:04, Archit Taneja wrote:

Add Dynamic Memory Manager (DMM) bindings for OMAP4 and OMAP5 devices. DMM
only requires address and irq information.

Add documentation for the DMM bindings.

Originally worked on by Andy Gross 

Cc: Andy Gross 
Signed-off-by: Archit Taneja 
---
  Documentation/devicetree/bindings/arm/omap/dmm.txt | 22 ++
  arch/arm/boot/dts/omap4.dtsi   |  7 +++
  arch/arm/boot/dts/omap5.dtsi   |  7 +++
  3 files changed, 36 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/arm/omap/dmm.txt


Has this been queued for 3.15?


Yes, It has got queued.

Archit

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/9] OMAP DSS DT bindings documentation

[Archit Taneja]

Hi,

On Thursday 13 February 2014 06:02 PM, Tomi Valkeinen wrote:

Hi,

Here is DT binding documentation for OMAP Display Subsystem. I've sent these
earlier as part of the whole DSS DT series, but I'm now sending them separately
to get comments for them.

These patches are essentially the same as what I already sent earlier. The only
difference is that I added clock information for omap3 and omap4 platforms.


Reviewed-by: Archit Taneja 

Archit

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/9] Doc/DT: Add OMAP DSS DT Bindings

[Archit Taneja]

Hi,

On Thursday 13 February 2014 06:02 PM, Tomi Valkeinen wrote:

Add device tree bindings for OMAP Display Subsystem for the following
SoCs: OMAP2, OMAP3, OMAP4.





Signed-off-by: Tomi Valkeinen 
---





+A shortened example of the board description for OMAP4 Panda board, defined in
+omap4-panda.dts.
+
+The Panda board has a DVI and a HDMI connector, and the board contains a TFP410
+chip (MIPI DPI to DVI encoder) and a TPD12S015 chip (HDMI ESD protection & 
level
+shifter). The video pipelines for the connectors are formed as follows:
+
+DSS Core --(MIPI DPI)--> TFP410 --(DVI)--> DVI Connector
+OMAP HDMI --(HDMI)--> TPD12S015 --(HDMI)--> HDMI COnnector


Nitpick - 'CO' -> 'Co'

Archit

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 0/2] DMM DT adaptation

[Archit Taneja]

Hi Mark,

On Friday 03 January 2014 06:04 PM, Archit Taneja wrote:

Hullo,

On Tuesday 17 December 2013 03:32 PM, Archit Taneja wrote:

The DMM/Tiler block can used by omapdrm to allocate frame buffers.
With the
removal of address and irq data from the omap4 hwmods, the probe of
DMM driver
fails and omapdrm isn't able to utilize the DMM hardware.

Add DMM bindings for OMAP4 and OMAP5 and DRA7x.


Can this be pulled for 3.14? I've incorporated comments from Mark and
other folks.


Can you please ack the first patch in the series?

The second one is going via a pull request to the drm maintainer:

https://git.kernel.org/cgit/linux/kernel/git/tomba/linux.git/commit/?id=3d232346c5656b300028b6c920ddc10b229b5264

Thanks,
Archit



Thanks,
Archit



Changes in v5:
- Use of_match_ptr() in the dmm driver.
- Add DT node for DRA7x as dra7.dtsi is now in mainline.

Changes in v4:
- Clean up documentation further.

Changes in v3:
- Fix mistakes in documentation and remove aliases for dmm nodes.

Changes in v2:
- No changes, split out into a separate series containing only DT
related parts.


Archit Taneja (2):
   arm: dts: omap4+: Add DMM bindings
   drm: omap: Enable DT support for DMM

  Documentation/devicetree/bindings/arm/omap/dmm.txt | 22
++
  arch/arm/boot/dts/dra7.dtsi|  7 +++
  arch/arm/boot/dts/omap4.dtsi   |  7 +++
  arch/arm/boot/dts/omap5.dtsi   |  7 +++
  drivers/gpu/drm/omapdrm/omap_dmm_tiler.c   |  7 +++
  5 files changed, 50 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/arm/omap/dmm.txt



--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html




--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 0/2] DMM DT adaptation

[Archit Taneja]

Hullo,

On Tuesday 17 December 2013 03:32 PM, Archit Taneja wrote:

The DMM/Tiler block can used by omapdrm to allocate frame buffers. With the
removal of address and irq data from the omap4 hwmods, the probe of DMM driver
fails and omapdrm isn't able to utilize the DMM hardware.

Add DMM bindings for OMAP4 and OMAP5 and DRA7x.


Can this be pulled for 3.14? I've incorporated comments from Mark and 
other folks.


Thanks,
Archit



Changes in v5:
- Use of_match_ptr() in the dmm driver.
- Add DT node for DRA7x as dra7.dtsi is now in mainline.

Changes in v4:
- Clean up documentation further.

Changes in v3:
- Fix mistakes in documentation and remove aliases for dmm nodes.

Changes in v2:
- No changes, split out into a separate series containing only DT related parts.


Archit Taneja (2):
   arm: dts: omap4+: Add DMM bindings
   drm: omap: Enable DT support for DMM

  Documentation/devicetree/bindings/arm/omap/dmm.txt | 22 ++
  arch/arm/boot/dts/dra7.dtsi|  7 +++
  arch/arm/boot/dts/omap4.dtsi   |  7 +++
  arch/arm/boot/dts/omap5.dtsi   |  7 +++
  drivers/gpu/drm/omapdrm/omap_dmm_tiler.c   |  7 +++
  5 files changed, 50 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/arm/omap/dmm.txt



--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 0/2] DMM DT adaptation

[Archit Taneja]

The DMM/Tiler block can used by omapdrm to allocate frame buffers. With the
removal of address and irq data from the omap4 hwmods, the probe of DMM driver
fails and omapdrm isn't able to utilize the DMM hardware.

Add DMM bindings for OMAP4 and OMAP5 and DRA7x.

Changes in v5:
- Use of_match_ptr() in the dmm driver.
- Add DT node for DRA7x as dra7.dtsi is now in mainline.

Changes in v4:
- Clean up documentation further.

Changes in v3:
- Fix mistakes in documentation and remove aliases for dmm nodes.

Changes in v2:
- No changes, split out into a separate series containing only DT related parts.


Archit Taneja (2):
  arm: dts: omap4+: Add DMM bindings
  drm: omap: Enable DT support for DMM

 Documentation/devicetree/bindings/arm/omap/dmm.txt | 22 ++
 arch/arm/boot/dts/dra7.dtsi|  7 +++
 arch/arm/boot/dts/omap4.dtsi   |  7 +++
 arch/arm/boot/dts/omap5.dtsi   |  7 +++
 drivers/gpu/drm/omapdrm/omap_dmm_tiler.c   |  7 +++
 5 files changed, 50 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/omap/dmm.txt

-- 
1.8.3.2

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 2/2] drm: omap: Enable DT support for DMM

[Archit Taneja]

Enable use of DT for DMM/Tiler.

Originally worked on by Andy Gross 

Cc: Andy Gross 
Cc: DRI Development 
Signed-off-by: Archit Taneja 
---
 drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c 
b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
index 701c4c1..1b782aa 100644
--- a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
+++ b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
@@ -969,12 +969,19 @@ static const struct dev_pm_ops omap_dmm_pm_ops = {
 };
 #endif
 
+static const struct of_device_id dmm_of_match[] = {
+   { .compatible = "ti,omap4-dmm", },
+   { .compatible = "ti,omap5-dmm", },
+   {},
+};
+
 struct platform_driver omap_dmm_driver = {
.probe = omap_dmm_probe,
.remove = omap_dmm_remove,
.driver = {
.owner = THIS_MODULE,
.name = DMM_DRIVER_NAME,
+   .of_match_table = of_match_ptr(dmm_of_match),
 #ifdef CONFIG_PM
.pm = &omap_dmm_pm_ops,
 #endif
-- 
1.8.3.2

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 1/2] arm: dts: omap4+: Add DMM bindings

[Archit Taneja]

Add Dynamic Memory Manager (DMM) bindings for OMAP4 and OMAP5 and DRA7x devices.
DMM only requires address and irq information.

Add documentation for the DMM bindings.

Originally worked on by Andy Gross 

Cc: Andy Gross 
Signed-off-by: Archit Taneja 
---
 Documentation/devicetree/bindings/arm/omap/dmm.txt | 22 ++
 arch/arm/boot/dts/dra7.dtsi|  7 +++
 arch/arm/boot/dts/omap4.dtsi   |  7 +++
 arch/arm/boot/dts/omap5.dtsi   |  7 +++
 4 files changed, 43 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/omap/dmm.txt

diff --git a/Documentation/devicetree/bindings/arm/omap/dmm.txt 
b/Documentation/devicetree/bindings/arm/omap/dmm.txt
new file mode 100644
index 000..8bd6d0a
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/omap/dmm.txt
@@ -0,0 +1,22 @@
+OMAP Dynamic Memory Manager (DMM) bindings
+
+The dynamic memory manager (DMM) is a module located immediately in front of 
the
+SDRAM controllers (called EMIFs on OMAP). DMM manages various aspects of memory
+accesses such as priority generation amongst initiators, configuration of SDRAM
+interleaving, optimizing transfer of 2D block objects, and provide MMU-like 
page
+translation for initiators which need contiguous dma bus addresses.
+
+Required properties:
+- compatible:  Should contain "ti,omap4-dmm" for OMAP4 family
+   Should contain "ti,omap5-dmm" for OMAP5 and DRA7x family
+- reg: Contains DMM register address range (base address and length)
+- interrupts:  Should contain an interrupt-specifier for DMM_IRQ.
+- ti,hwmods:   Name of the hwmod associated to DMM, which is typically "dmm"
+
+Example:
+
+dmm@4e00 {
+   compatible = "ti,omap4-dmm";
+   reg = <0x4e00 0x800>;
+   ti,hwmods = "dmm";
+};
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index d0df4c4..c9bb006 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -425,6 +425,13 @@
ti,hwmods = "wd_timer2";
};
 
+   dmm@4e00 {
+   compatible = "ti,omap5-dmm";
+   reg = <0x4e00 0x800>;
+   interrupts = <0 113 0x4>;
+   ti,hwmods = "dmm";
+   };
+
i2c1: i2c@4807 {
compatible = "ti,omap4-i2c";
reg = <0x4807 0x100>;
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index a1e0585..3c67b2f 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -502,6 +502,13 @@
ti,hwmods = "kbd";
};
 
+   dmm@4e00 {
+   compatible = "ti,omap4-dmm";
+   reg = <0x4e00 0x800>;
+   interrupts = <0 113 0x4>;
+   ti,hwmods = "dmm";
+   };
+
emif1: emif@4c00 {
compatible = "ti,emif-4d";
reg = <0x4c00 0x100>;
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index fc3fad5..878f635 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -621,6 +621,13 @@
ti,hwmods = "wd_timer2";
};
 
+   dmm@4e00 {
+   compatible = "ti,omap5-dmm";
+   reg = <0x4e00 0x800>;
+   interrupts = <0 113 0x4>;
+   ti,hwmods = "dmm";
+   };
+
emif1: emif@4c00 {
compatible  = "ti,emif-4d5";
ti,hwmods   = "emif1";
-- 
1.8.3.2

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv2 08/27] OMAPDSS: add of helpers

[Archit Taneja]

Hi,

On Monday 16 December 2013 08:26 PM, Tomi Valkeinen wrote:

Add helpers to get ports and endpoints from DT data.

Signed-off-by: Tomi Valkeinen 
---
  drivers/video/omap2/dss/Makefile |   2 +-
  drivers/video/omap2/dss/dss-of.c | 162 +++
  include/video/omapdss.h  |  14 
  3 files changed, 177 insertions(+), 1 deletion(-)
  create mode 100644 drivers/video/omap2/dss/dss-of.c

diff --git a/drivers/video/omap2/dss/Makefile b/drivers/video/omap2/dss/Makefile
index d3aa91bdd6a8..8aec8bda27cc 100644
--- a/drivers/video/omap2/dss/Makefile
+++ b/drivers/video/omap2/dss/Makefile
@@ -1,7 +1,7 @@
  obj-$(CONFIG_OMAP2_DSS) += omapdss.o
  # Core DSS files
  omapdss-y := core.o dss.o dss_features.o dispc.o dispc_coefs.o display.o \
-   output.o
+   output.o dss-of.o
  # DSS compat layer files
  omapdss-y += manager.o manager-sysfs.o overlay.o overlay-sysfs.o apply.o \
dispc-compat.o display-sysfs.o
diff --git a/drivers/video/omap2/dss/dss-of.c b/drivers/video/omap2/dss/dss-of.c
new file mode 100644
index ..59213cf2ffa2
--- /dev/null
+++ b/drivers/video/omap2/dss/dss-of.c
@@ -0,0 +1,162 @@
+/*
+ * Copyright (C) 2013 Texas Instruments
+ * Author: Tomi Valkeinen 
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include "dss.h"
+#include "dss_features.h"


Minor nitpick. The above 2 headers aren't needed.

Archit

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 16/26] ARM: omap4-sdp.dts: add display information

[Archit Taneja]

On Friday 13 December 2013 03:09 PM, Tomi Valkeinen wrote:

On 2013-12-13 11:27, Archit Taneja wrote:

On Wednesday 04 December 2013 05:58 PM, Tomi Valkeinen wrote:

Signed-off-by: Tomi Valkeinen 
---
   arch/arm/boot/dts/omap4-sdp.dts | 91
+
   1 file changed, 91 insertions(+)

diff --git a/arch/arm/boot/dts/omap4-sdp.dts
b/arch/arm/boot/dts/omap4-sdp.dts
index 5fc3f43c5a81..e3048f849612 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -550,3 +550,94 @@
   mode = <3>;
   power = <50>;
   };
+
+&dsi1 {
+vdds_dsi-supply = <&vcxio>;
+
+dsi1_out_ep: endpoint {
+remote-endpoint = <&lcd0_in>;
+lanes = <0 1 2 3 4 5>;


In the previous revision omapdss DT patchset, the lanes node was a
member of the panel DT node, and not the dsi DT node. Any reason to
change this? Does it make more sense this way?


Well, the lane configuration is programmed into the DSI HW. So DSI needs
to know them. Thus the lanes can be considered a property of the DSI.

In some cases, the external encoder or panel also needs to know about
the lanes. In that case, both DSI and the encoder/panel would contain
the same data.

My reasoning where a property belongs to:

If a property is clearly internal to a device, it belongs there. For
example, in this case vdds_dsi-supply is clearly a property of the DSI.

If a property is about the link between two devices, like "lanes" here,
it belongs to both devices. If a device does not need that data for
anything, it can be omitted.


I suppose it's more suitable for dsi to hold the property if 2 panels
are connected on the same bus. Say, one with 4 data lanes, and other
with 2. It would be tricky for the dsi driver to get lane params from 2
different places and merge them somehow.


It doesn't matter, both would work fine. If the lanes property is in the
DSI node, then the DSI driver finds out the lane config by finding out
which endpoint is used for the panel that's being enabled.

If the lanes property would be in the panel, the panel would pass the
lane config to the DSI when it's enabled.

But I think passing the lane config from panel to DSI (like we do
currently) is not so nice.


Okay, that makes sense.




+};
+
+lcd0: display@0 {
+compatible = "tpo,taal", "panel-dsi-cm";
+
+gpios = <&gpio4 6 0>;/* 102, reset */
+
+lcd0_in: endpoint {
+remote-endpoint = <&dsi1_out_ep>;
+};
+};


Is there a reason why lcd0 and lcd1 are children nodes of dsi1 and dsi2
respectively? I don't see this for panels on other boards.


Yes. The panels are _controlled_ with DSI. We model the child-parent
relationships in DT data based on the control. So an i2c peripheral is
controlled via i2c master, and is thus a child of the i2c master. Same
here. The ports/endpoints are used to define the data path, which is
separate thing from the control path.

DPI panels which don't have any way to control them (except basic things
like gpios) are platform devices without any parent.

If the DPI panel would be controlled with i2c, it'd be a child of an i2c
master.


Ah, I thought the port/endpoint stuff had something to do with this. I 
forgot about the parent-child relationship for the control path.


In that case, for the sake of accuracy, the dsi-cm panel could get the 
"in" parameter via the parent node wherever it's used for control, like 
setting a DCS command for sleep out. And via 
omapdss_of_find_source_for_first_ep() when it's used to start data 
transfer, even though both the "in's" are finally the same dsi device?


Archit

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 16/26] ARM: omap4-sdp.dts: add display information

[Archit Taneja]

On Wednesday 04 December 2013 05:58 PM, Tomi Valkeinen wrote:

Signed-off-by: Tomi Valkeinen 
---
  arch/arm/boot/dts/omap4-sdp.dts | 91 +
  1 file changed, 91 insertions(+)

diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index 5fc3f43c5a81..e3048f849612 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -550,3 +550,94 @@
mode = <3>;
power = <50>;
  };
+
+&dsi1 {
+   vdds_dsi-supply = <&vcxio>;
+
+   dsi1_out_ep: endpoint {
+   remote-endpoint = <&lcd0_in>;
+   lanes = <0 1 2 3 4 5>;


In the previous revision omapdss DT patchset, the lanes node was a 
member of the panel DT node, and not the dsi DT node. Any reason to 
change this? Does it make more sense this way?


I suppose it's more suitable for dsi to hold the property if 2 panels 
are connected on the same bus. Say, one with 4 data lanes, and other 
with 2. It would be tricky for the dsi driver to get lane params from 2 
different places and merge them somehow.



+   };
+
+   lcd0: display@0 {
+   compatible = "tpo,taal", "panel-dsi-cm";
+
+   gpios = <&gpio4 6 0>; /* 102, reset */
+
+   lcd0_in: endpoint {
+   remote-endpoint = <&dsi1_out_ep>;
+   };
+   };


Is there a reason why lcd0 and lcd1 are children nodes of dsi1 and dsi2 
respectively? I don't see this for panels on other boards.


Archit

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 05/26] ARM: OMAP2+: add omapdss_init_of()

[Archit Taneja]

On Thursday 12 December 2013 01:00 PM, Tomi Valkeinen wrote:

On 2013-12-12 01:10, Laurent Pinchart wrote:

Hi Tomi,

On Wednesday 04 December 2013 14:28:32 Tomi Valkeinen wrote:

omapdss driver uses a omapdss platform device to pass platform specific
function pointers and DSS hardware version from the arch code to the
driver. This device is needed also when booting with DT.

This patch adds omapdss_init_of() function, called from board-generic at
init time, which creates the omapdss device.


Is this a temporary solution that you plan to later replace with DT-only
device instantiation ?


It's a long term task to remove the "virtual" omapdss device. Removing
the platform data that we pass has been very difficult.


Even if we remove the platform data, what would be the right place to 
register the drm, fb and vout devices? We need to make sure their 
drivers are probed only after omapdss is initialised.




For example, we need to get the OMAP revision to know which OMAP DSS
hardware we have. We can't get that information from the DSS hardware
(thank you, HW designers! ;).




Another is DSI pin muxing. I think we need a new pinmuxing driver for
that, or maybe change pinmux-single quite a bit. The DSI pinmuxing is
very simple, but the register fields are varying lengths and at varying
positions, so pinmux-single doesn't work for it.


I have seen other OMAP drivers passing control module register info to 
their DT node. Instead of having a pinmux driver for a single register, 
we might want to consider just passing the control module register, and 
take care of the reg fields and masks in the OMAP DSI driver itself.


The parsing of the DSI pins from DT, however, can be kept generic.

Archit

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 2/2] drm: omap: Enable DT support for DMM

[Archit Taneja]

On Friday 01 November 2013 06:10 AM, Mark Rutland wrote:

On Tue, Oct 15, 2013 at 08:04:20AM +0100, Archit Taneja wrote:

Enable use of DT for DMM/Tiler.

Originally worked on by Andy Gross 

Cc: Andy Gross 
Cc: DRI Development 
Signed-off-by: Archit Taneja 
---
  drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 11 +++
  1 file changed, 11 insertions(+)

diff --git a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c 
b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
index acf6678..59f17de 100644
--- a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
+++ b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
@@ -968,12 +968,23 @@ static const struct dev_pm_ops omap_dmm_pm_ops = {
  };
  #endif

+#if defined(CONFIG_OF)
+static const struct of_device_id dmm_of_match[] = {
+   { .compatible = "ti,omap4-dmm", },
+   { .compatible = "ti,omap5-dmm", },
+   {},
+};
+#else
+#define dmm_of_match NULL
+#endif
+
  struct platform_driver omap_dmm_driver = {
.probe = omap_dmm_probe,
.remove = omap_dmm_remove,
.driver = {
.owner = THIS_MODULE,
.name = DMM_DRIVER_NAME,
+   .of_match_table = dmm_of_match,


If you use of_match_ptr(dmm_of_match) here you don't need the #else case above.


Thanks for the tip. I'll make this update.

Archit

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4 0/2] DMM DT adaptation

[Archit Taneja]

The DMM/Tiler block can used by omapdrm to allocate frame buffers. With the
removal of address and irq data from the omap4 hwmods, the probe of DMM driver
fails and omapdrm isn't able to utilize the DMM hardware.

Add DMM bindings for omap4 and omap5.

Changes in v4:
- Clean up documentation further.

Changes in v3:
- Fix mistakes in documentation and remove aliases for dmm nodes.

Changes in v2:
- No changes, split out into a separate series containing only DT related parts.

Archit Taneja (2):
  arm: dts: omap4+: Add DMM bindings
  drm: omap: Enable DT support for DMM

 Documentation/devicetree/bindings/arm/omap/dmm.txt | 22 ++
 arch/arm/boot/dts/omap4.dtsi   |  7 +++
 arch/arm/boot/dts/omap5.dtsi   |  7 +++
 drivers/gpu/drm/omapdrm/omap_dmm_tiler.c   | 11 +++
 4 files changed, 47 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/omap/dmm.txt

-- 
1.8.1.2

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4 1/2] arm: dts: omap4+: Add DMM bindings

[Archit Taneja]

Add Dynamic Memory Manager (DMM) bindings for OMAP4 and OMAP5 devices. DMM
only requires address and irq information.

Add documentation for the DMM bindings.

Originally worked on by Andy Gross 

Cc: Andy Gross 
Signed-off-by: Archit Taneja 
---
 Documentation/devicetree/bindings/arm/omap/dmm.txt | 22 ++
 arch/arm/boot/dts/omap4.dtsi   |  7 +++
 arch/arm/boot/dts/omap5.dtsi   |  7 +++
 3 files changed, 36 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/omap/dmm.txt

diff --git a/Documentation/devicetree/bindings/arm/omap/dmm.txt 
b/Documentation/devicetree/bindings/arm/omap/dmm.txt
new file mode 100644
index 000..8bd6d0a
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/omap/dmm.txt
@@ -0,0 +1,22 @@
+OMAP Dynamic Memory Manager (DMM) bindings
+
+The dynamic memory manager (DMM) is a module located immediately in front of 
the
+SDRAM controllers (called EMIFs on OMAP). DMM manages various aspects of memory
+accesses such as priority generation amongst initiators, configuration of SDRAM
+interleaving, optimizing transfer of 2D block objects, and provide MMU-like 
page
+translation for initiators which need contiguous dma bus addresses.
+
+Required properties:
+- compatible:  Should contain "ti,omap4-dmm" for OMAP4 family
+   Should contain "ti,omap5-dmm" for OMAP5 and DRA7x family
+- reg: Contains DMM register address range (base address and length)
+- interrupts:  Should contain an interrupt-specifier for DMM_IRQ.
+- ti,hwmods:   Name of the hwmod associated to DMM, which is typically "dmm"
+
+Example:
+
+dmm@4e00 {
+   compatible = "ti,omap4-dmm";
+   reg = <0x4e00 0x800>;
+   ti,hwmods = "dmm";
+};
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 22d9f2b..b6bf288 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -487,6 +487,13 @@
ti,hwmods = "kbd";
};
 
+   dmm@4e00 {
+   compatible = "ti,omap4-dmm";
+   reg = <0x4e00 0x800>;
+   interrupts = <0 113 0x4>;
+   ti,hwmods = "dmm";
+   };
+
emif1: emif@4c00 {
compatible = "ti,emif-4d";
reg = <0x4c00 0x100>;
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 7cdea1b..e405458 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -604,6 +604,13 @@
ti,hwmods = "wd_timer2";
};
 
+   dmm@4e00 {
+   compatible = "ti,omap5-dmm";
+   reg = <0x4e00 0x800>;
+   interrupts = <0 113 0x4>;
+   ti,hwmods = "dmm";
+   };
+
emif1: emif@0x4c00 {
compatible  = "ti,emif-4d5";
ti,hwmods   = "emif1";
-- 
1.8.1.2

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4 2/2] drm: omap: Enable DT support for DMM

[Archit Taneja]

Enable use of DT for DMM/Tiler.

Originally worked on by Andy Gross 

Cc: Andy Gross 
Cc: DRI Development 
Signed-off-by: Archit Taneja 
---
 drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c 
b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
index acf6678..59f17de 100644
--- a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
+++ b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
@@ -968,12 +968,23 @@ static const struct dev_pm_ops omap_dmm_pm_ops = {
 };
 #endif
 
+#if defined(CONFIG_OF)
+static const struct of_device_id dmm_of_match[] = {
+   { .compatible = "ti,omap4-dmm", },
+   { .compatible = "ti,omap5-dmm", },
+   {},
+};
+#else
+#define dmm_of_match NULL
+#endif
+
 struct platform_driver omap_dmm_driver = {
.probe = omap_dmm_probe,
.remove = omap_dmm_remove,
.driver = {
.owner = THIS_MODULE,
.name = DMM_DRIVER_NAME,
+   .of_match_table = dmm_of_match,
 #ifdef CONFIG_PM
.pm = &omap_dmm_pm_ops,
 #endif
-- 
1.8.1.2

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 1/2] arm: dts: omap4+: Add DMM bindings

[Archit Taneja]

Hi,

On Thursday 10 October 2013 03:38 PM, Mark Rutland wrote:

On Thu, Oct 10, 2013 at 07:36:33AM +0100, Archit Taneja wrote:

Add Dynamic Memory Manager (DMM) bindings for OMAP4 and OMAP5 devices. DMM
only requires address and irq information.

Add documentation for the DMM bindings.

Originally worked on by Andy Gross 

Cc: Andy Gross 
Signed-off-by: Archit Taneja 
---
  Documentation/devicetree/bindings/arm/omap/dmm.txt | 16 
  arch/arm/boot/dts/omap4.dtsi   |  7 +++
  arch/arm/boot/dts/omap5.dtsi   |  7 +++
  3 files changed, 30 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/arm/omap/dmm.txt

diff --git a/Documentation/devicetree/bindings/arm/omap/dmm.txt 
b/Documentation/devicetree/bindings/arm/omap/dmm.txt
new file mode 100644
index 000..6fc3d79
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/omap/dmm.txt
@@ -0,0 +1,16 @@
+OMAP Dynamic Memory Manager (DMM) bindings


Is there any documentation? A brief description of what this is would be
nice.


I'll do that.




+
+Required properties:
+- compatible:  Must be "ti,omap4-dmm" for OMAP4 family
+   Must be "ti,omap5-dmm" for OMAP5 and DRA7x family


s/must be/should contain/


+- reg: Contains timer register address range (base address and length)


Huh? What's a timer got to do with the DMM?


Err, my mistake!




+- interrupts:  Contains interrupt information (source, etc) for the DMM IRQ


Is there a single interrupt? If so:

- interrupts: Should contain an interrupt-specifier for the DMM IRQ.


Okay.



Assuming the "DMM IRQ" is well defined. If there's a name for it in
documentation, using that's preferable. If a future revision may have
multiple interrupts, please use interrupt-names now to save us endless
pain in future.


The IRQ is called DMM_IRQ in the documentation. I don't think there 
would be more than one interrupt line from this IP. I'll still cross check.


Thanks,
Archit

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 0/2] DMM DT adaptation

[Archit Taneja]

The DMM/Tiler block can used by omapdrm to allocate frame buffers. With the
removal of address and irq data from the omap4 hwmods, the probe of DMM driver
fails and omapdrm isn't able to utilize the DMM hardware.

Add DMM bindings for omap4 and omap5.

Changes in v3:
- Fix mistakes in documentation and remove aliases for dmm nodes.

Changes in v2:
- No changes, split out into a separate series containing only DT related parts.

Archit Taneja (2):
  arm: dts: omap4+: Add DMM bindings
  drm: omap: Enable DT support for DMM

 Documentation/devicetree/bindings/arm/omap/dmm.txt | 16 
 arch/arm/boot/dts/omap4.dtsi   |  7 +++
 arch/arm/boot/dts/omap5.dtsi   |  7 +++
 drivers/gpu/drm/omapdrm/omap_dmm_tiler.c   | 11 +++
 4 files changed, 41 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/omap/dmm.txt

-- 
1.8.1.2

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 1/2] arm: dts: omap4+: Add DMM bindings

[Archit Taneja]

Add Dynamic Memory Manager (DMM) bindings for OMAP4 and OMAP5 devices. DMM
only requires address and irq information.

Add documentation for the DMM bindings.

Originally worked on by Andy Gross 

Cc: Andy Gross 
Signed-off-by: Archit Taneja 
---
 Documentation/devicetree/bindings/arm/omap/dmm.txt | 16 
 arch/arm/boot/dts/omap4.dtsi   |  7 +++
 arch/arm/boot/dts/omap5.dtsi   |  7 +++
 3 files changed, 30 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/omap/dmm.txt

diff --git a/Documentation/devicetree/bindings/arm/omap/dmm.txt 
b/Documentation/devicetree/bindings/arm/omap/dmm.txt
new file mode 100644
index 000..6fc3d79
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/omap/dmm.txt
@@ -0,0 +1,16 @@
+OMAP Dynamic Memory Manager (DMM) bindings
+
+Required properties:
+- compatible:  Must be "ti,omap4-dmm" for OMAP4 family
+   Must be "ti,omap5-dmm" for OMAP5 and DRA7x family
+- reg: Contains timer register address range (base address and length)
+- interrupts:  Contains interrupt information (source, etc) for the DMM IRQ
+- ti,hwmods:   Name of the hwmod associated to DMM, which is typically "dmm"
+
+Example:
+
+dmm@4e00 {
+   compatible = "ti,omap4-dmm";
+   reg = <0x4e00 0x800>;
+   ti,hwmods = "dmm";
+};
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 22d9f2b..b6bf288 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -487,6 +487,13 @@
ti,hwmods = "kbd";
};
 
+   dmm@4e00 {
+   compatible = "ti,omap4-dmm";
+   reg = <0x4e00 0x800>;
+   interrupts = <0 113 0x4>;
+   ti,hwmods = "dmm";
+   };
+
emif1: emif@4c00 {
compatible = "ti,emif-4d";
reg = <0x4c00 0x100>;
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 7cdea1b..e405458 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -604,6 +604,13 @@
ti,hwmods = "wd_timer2";
};
 
+   dmm@4e00 {
+   compatible = "ti,omap5-dmm";
+   reg = <0x4e00 0x800>;
+   interrupts = <0 113 0x4>;
+   ti,hwmods = "dmm";
+   };
+
emif1: emif@0x4c00 {
compatible  = "ti,emif-4d5";
ti,hwmods   = "emif1";
-- 
1.8.1.2

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 2/2] drm: omap: Enable DT support for DMM

[Archit Taneja]

Enable use of DT for DMM/Tiler.

Originally worked on by Andy Gross 

Cc: Andy Gross 
Cc: DRI Development 
Signed-off-by: Archit Taneja 
---
 drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c 
b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
index acf6678..59f17de 100644
--- a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
+++ b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
@@ -968,12 +968,23 @@ static const struct dev_pm_ops omap_dmm_pm_ops = {
 };
 #endif
 
+#if defined(CONFIG_OF)
+static const struct of_device_id dmm_of_match[] = {
+   { .compatible = "ti,omap4-dmm", },
+   { .compatible = "ti,omap5-dmm", },
+   {},
+};
+#else
+#define dmm_of_match NULL
+#endif
+
 struct platform_driver omap_dmm_driver = {
.probe = omap_dmm_probe,
.remove = omap_dmm_remove,
.driver = {
.owner = THIS_MODULE,
.name = DMM_DRIVER_NAME,
+   .of_match_table = dmm_of_match,
 #ifdef CONFIG_PM
.pm = &omap_dmm_pm_ops,
 #endif
-- 
1.8.1.2

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html