[{"id":1765355,"web_url":"http://patchwork.ozlabs.org/comment/1765355/","msgid":"<20170908132932.rfz4hxab4tgntioo@flea.lan>","list_archive_url":null,"date":"2017-09-08T13:29:32","subject":"Re: [PATCH 1/8] ARM: dts: sun6i: Fix endpoint IDs in second display\n\tpipeline","submitter":{"id":12916,"url":"http://patchwork.ozlabs.org/api/people/12916/","name":"Maxime Ripard","email":"maxime.ripard@free-electrons.com"},"content":"Hi,\n\nOn Fri, Sep 08, 2017 at 03:50:09PM +0800, Chen-Yu Tsai wrote:\n> When the second display pipeline device nodes for the A31/A31s were\n> added, it was not known that the TCONs could (through either DRCs)\n> select either backend as their input. Thus in the endpoints connecting\n> these components together, the endpoint IDs were set to 0, while in\n> fact they should have been set to 1.\n> \n> Fixes: 9a26882a7378 (\"ARM: dts: sun6i: Add second display pipeline device\n> \t\t nodes\")\n> Signed-off-by: Chen-Yu Tsai \n\nShould we CC stable on this one?\n\nThanks!\nMaxime","headers":{"Return-Path":"","X-Original-To":"incoming-dt@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-dt@bilbo.ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=devicetree-owner@vger.kernel.org; receiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xpdTY0w6hz9s4s\n\tfor ;\n\tFri, 8 Sep 2017 23:29:37 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1756327AbdIHN3f (ORCPT\n\t);\n\tFri, 8 Sep 2017 09:29:35 -0400","from mail.free-electrons.com ([62.4.15.54]:49467 \"EHLO\n\tmail.free-electrons.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1756380AbdIHN3d (ORCPT\n\t); Fri, 8 Sep 2017 09:29:33 -0400","by mail.free-electrons.com (Postfix, from userid 110)\n\tid 7CEE620968; Fri, 8 Sep 2017 15:29:31 +0200 (CEST)","from localhost (LStLambert-657-1-97-87.w90-63.abo.wanadoo.fr\n\t[90.63.216.87])\n\tby mail.free-electrons.com (Postfix) with ESMTPSA id 4DFE820947;\n\tFri, 8 Sep 2017 15:29:31 +0200 (CEST)"],"X-Spam-Checker-Version":"SpamAssassin 3.4.0 (2014-02-07) on\n\tmail.free-electrons.com","X-Spam-Level":"","X-Spam-Status":"No, score=-1.0 required=5.0 tests=ALL_TRUSTED,SHORTCIRCUIT,\n\tURIBL_BLOCKED shortcircuit=ham autolearn=disabled version=3.4.0","Date":"Fri, 8 Sep 2017 15:29:32 +0200","From":"Maxime Ripard ","To":"Chen-Yu Tsai ","Cc":"David Airlie , dri-devel@lists.freedesktop.org,\n\tlinux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org","Subject":"Re: [PATCH 1/8] ARM: dts: sun6i: Fix endpoint IDs in second display\n\tpipeline","Message-ID":"<20170908132932.rfz4hxab4tgntioo@flea.lan>","References":"<20170908075016.18657-1-wens@csie.org>\n\t<20170908075016.18657-2-wens@csie.org>","MIME-Version":"1.0","Content-Type":"multipart/signed; micalg=pgp-sha1;\n\tprotocol=\"application/pgp-signature\"; boundary=\"boiord233u4nq2qs\"","Content-Disposition":"inline","In-Reply-To":"<20170908075016.18657-2-wens@csie.org>","User-Agent":"NeoMutt/20170714 (1.8.3)","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1765367,"web_url":"http://patchwork.ozlabs.org/comment/1765367/","msgid":"","list_archive_url":null,"date":"2017-09-08T13:38:23","subject":"Re: [PATCH 1/8] ARM: dts: sun6i: Fix endpoint IDs in second display\n\tpipeline","submitter":{"id":47154,"url":"http://patchwork.ozlabs.org/api/people/47154/","name":"Chen-Yu Tsai","email":"wens@csie.org"},"content":"On Fri, Sep 8, 2017 at 9:29 PM, Maxime Ripard\n wrote:\n> Hi,\n>\n> On Fri, Sep 08, 2017 at 03:50:09PM +0800, Chen-Yu Tsai wrote:\n>> When the second display pipeline device nodes for the A31/A31s were\n>> added, it was not known that the TCONs could (through either DRCs)\n>> select either backend as their input. Thus in the endpoints connecting\n>> these components together, the endpoint IDs were set to 0, while in\n>> fact they should have been set to 1.\n>>\n>> Fixes: 9a26882a7378 (\"ARM: dts: sun6i: Add second display pipeline device\n>> nodes\")\n>> Signed-off-by: Chen-Yu Tsai \n>\n> Should we CC stable on this one?\n\nIt wouldn't matter for old kernels, but I suppose we should get it right\neverywhere, so we should probably CC stable. Also I forgot to mention\nthat this patch should go in -fixes, while the rest can go in -next.\n\nThanks\nChenYu\n--\nTo unsubscribe from this list: send the line \"unsubscribe devicetree\" in\nthe body of a message to majordomo@vger.kernel.org\nMore majordomo info at http://vger.kernel.org/majordomo-info.html","headers":{"Return-Path":"","X-Original-To":"incoming-dt@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-dt@bilbo.ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=devicetree-owner@vger.kernel.org; receiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xpdhV3Tl7z9s7p\n\tfor ;\n\tFri, 8 Sep 2017 23:39:06 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1756525AbdIHNjE (ORCPT\n\t);\n\tFri, 8 Sep 2017 09:39:04 -0400","from smtp.csie.ntu.edu.tw ([140.112.30.61]:59220 \"EHLO\n\tsmtp.csie.ntu.edu.tw\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1755770AbdIHNit (ORCPT\n\t); Fri, 8 Sep 2017 09:38:49 -0400","from mail-wm0-f48.google.com (mail-wm0-f48.google.com\n\t[74.125.82.48])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits))\n\t(No client certificate requested) (Authenticated sender: b93043)\n\tby smtp.csie.ntu.edu.tw (Postfix) with ESMTPSA id 2F5B220347\n\tfor ;\n\tFri, 8 Sep 2017 21:38:47 +0800 (CST)","by mail-wm0-f48.google.com with SMTP id i189so5104829wmf.1\n\tfor ;\n\tFri, 08 Sep 2017 06:38:47 -0700 (PDT)","by 10.223.196.226 with HTTP; Fri, 8 Sep 2017 06:38:23 -0700 (PDT)"],"X-Gm-Message-State":"AHPjjUjaaYt7JQVs3nNMNq4tfjoVGnM9Dgz2KIHS86LMqg4SFCIDT16h\n\tbdlC+yyb7zRM102U3jGvf/8Du+Z/b/exT9RElog=","X-Google-Smtp-Source":"AOwi7QCX5T/tTLj7+VhiMTz09/7az2zPHKhSSruhxY5ww4KkFhRlZXPpYA0fZmeEkWGjWWcwlFwR/6uqddMxLzgXDqQ=","X-Received":"by 10.28.59.215 with SMTP id i206mr1707495wma.116.1504877923840; \n\tFri, 08 Sep 2017 06:38:43 -0700 (PDT)","MIME-Version":"1.0","In-Reply-To":"<20170908132932.rfz4hxab4tgntioo@flea.lan>","References":"<20170908075016.18657-1-wens@csie.org>\n\t<20170908075016.18657-2-wens@csie.org>\n\t<20170908132932.rfz4hxab4tgntioo@flea.lan>","From":"Chen-Yu Tsai ","Date":"Fri, 8 Sep 2017 21:38:23 +0800","X-Gmail-Original-Message-ID":"","Message-ID":"","Subject":"Re: [PATCH 1/8] ARM: dts: sun6i: Fix endpoint IDs in second display\n\tpipeline","To":"Maxime Ripard ","Cc":"Chen-Yu Tsai , David Airlie ,\n\tdri-devel ,\n\tlinux-arm-kernel ,\n\tdevicetree ","Content-Type":"text/plain; charset=\"UTF-8\"","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1765812,"web_url":"http://patchwork.ozlabs.org/comment/1765812/","msgid":"<20170909154140.wmuh46kxamumyspz@flea.lan>","list_archive_url":null,"date":"2017-09-09T15:41:40","subject":"Re: [PATCH 0/8] drm/sun4i: Make both display pipeline work together","submitter":{"id":12916,"url":"http://patchwork.ozlabs.org/api/people/12916/","name":"Maxime Ripard","email":"maxime.ripard@free-electrons.com"},"content":"Hi,\n\nOn Fri, Sep 08, 2017 at 03:50:08PM +0800, Chen-Yu Tsai wrote:\n> Hi everyone,\n> \n> Previously I added support for two display pipelines for the sun4i-drm\n> driver. At the time we did not have support for downstream encoders to\n> actually test the second pipeline, nor having both pipelines active at\n> the same time.\n> \n> With HDMI encoder support now merged and support for it on sun6i in\n> progress, we are now able to test both pipelines being active at the\n> same time, with LCD output from one and HDMI from the other. Testing\n> has revealed some more issues, such as component probing order. Also,\n> we found out that muxing between the display backend and TCON was\n> possible, and required for the second pipeline to work as intended.\n> Last, the number of CRTCs provided to drm_vblank_init needs to be\n> increased for vblanks to work properly.\n> \n> This patch series does a few things:\n> \n> - Fix endpoint IDs so they conform to what the DT binding stipulates.\n> \n> - Change the order the individual components are queued up.\n> \n> - Fix how the TCON gets its ID when the backend-TCON mux is present.\n> \n> - Support the input mux in the TCON (which selects which backend to\n> use on the A31/A31s).\n> \n> - Fix the drm_vblank_init call and pass the correct number of crtcs.\n> \n> - Add the cross pipeline connections between the DRCs and TCONs on\n> the A31, conforming to the DT binding and what the hardware is\n> capable of.\n> \n> More details are available in each individual commit. Please have a look.\n\nI've applied all the commits, with:\npatch 1 in our arm-soc fixes branch\npatch 2-7 in drm-misc-next\npatch 8 in sunxi/dt-for-4.15.\n\nI have a minor comment on one patch that can be fixed in a followup\npatch, so please have a look at my other mail.\n\nThanks for this great work,\nMaxime","headers":{"Return-Path":"","X-Original-To":"incoming-dt@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-dt@bilbo.ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=devicetree-owner@vger.kernel.org; receiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xqJMW3Ynsz9t16\n\tfor ;\n\tSun, 10 Sep 2017 01:41:43 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1753630AbdIIPlm (ORCPT\n\t);\n\tSat, 9 Sep 2017 11:41:42 -0400","from mail.free-electrons.com ([62.4.15.54]:33956 \"EHLO\n\tmail.free-electrons.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1753519AbdIIPll (ORCPT\n\t); Sat, 9 Sep 2017 11:41:41 -0400","by mail.free-electrons.com (Postfix, from userid 110)\n\tid 966CB20A1C; Sat, 9 Sep 2017 17:41:40 +0200 (CEST)","from localhost (LFbn-TOU-1-209-191.w86-201.abo.wanadoo.fr\n\t[86.201.56.191])\n\tby mail.free-electrons.com (Postfix) with ESMTPSA id 6F3BD20910;\n\tSat, 9 Sep 2017 17:41:40 +0200 (CEST)"],"X-Spam-Checker-Version":"SpamAssassin 3.4.0 (2014-02-07) on\n\tmail.free-electrons.com","X-Spam-Level":"","X-Spam-Status":"No, score=-1.0 required=5.0 tests=ALL_TRUSTED,SHORTCIRCUIT\n\tshortcircuit=ham autolearn=disabled version=3.4.0","Date":"Sat, 9 Sep 2017 17:41:40 +0200","From":"Maxime Ripard ","To":"Chen-Yu Tsai ","Cc":"David Airlie , dri-devel@lists.freedesktop.org,\n\tlinux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org","Subject":"Re: [PATCH 0/8] drm/sun4i: Make both display pipeline work together","Message-ID":"<20170909154140.wmuh46kxamumyspz@flea.lan>","References":"<20170908075016.18657-1-wens@csie.org>","MIME-Version":"1.0","Content-Type":"multipart/signed; micalg=pgp-sha1;\n\tprotocol=\"application/pgp-signature\"; boundary=\"kfqkuj2vp7zlwfpe\"","Content-Disposition":"inline","In-Reply-To":"<20170908075016.18657-1-wens@csie.org>","User-Agent":"NeoMutt/20170714 (1.8.3)","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1765814,"web_url":"http://patchwork.ozlabs.org/comment/1765814/","msgid":"<20170909154257.wgwybldpmpr6snsc@flea.lan>","list_archive_url":null,"date":"2017-09-09T15:42:57","subject":"Re: [PATCH 4/8] drm/sun4i: tcon: get TCON ID and matching engine\n\twith remote endpoint ID","submitter":{"id":12916,"url":"http://patchwork.ozlabs.org/api/people/12916/","name":"Maxime Ripard","email":"maxime.ripard@free-electrons.com"},"content":"Hi,\n\nOn Fri, Sep 08, 2017 at 03:50:12PM +0800, Chen-Yu Tsai wrote:\n> The device tree binding for sun4i-drm says:\n> \n> For all connections between components up to the TCONs in the display\n> pipeline, when there are multiple components of the same type at the\n> same depth, the local endpoint ID must be the same as the remote\n> component's index. For example, if the remote endpoint is Frontend 1,\n> then the local endpoint ID must be 1.\n> \n> We should be able to get the TCON's ID directly from any of the remote\n> endpoints from its input port. With the ID, we can then go through the\n> list of registered engines and find a matching one by ID.\n> \n> However the A31 device tree is incorrect. We assumed that there were no\n> cross pipeline connections between the backends and TCONs. As a result,\n> in all the endpoints between the backends and TCONs of the second\n> display pipeline, the endpoint IDs were incorrectly set to 0, when in\n> fact they should've been set to 1.\n> \n> To maintain compatibility with this incorrect device tree, we first\n> check if the TCON's input port has 1 or many endpoints. If there are\n> more than 1, then it is likely a fixed version, and we can proceed\n> with the new method. If there is only 1 endpoint, then it is possibly\n> an incorrect version, or it could be the SoC only has one pipeline.\n> In either case we fall back to using the old method of traversing\n> the input connections to find a matching engine, and then get its\n> ID.\n> \n> Signed-off-by: Chen-Yu Tsai \n> ---\n> drivers/gpu/drm/sun4i/sun4i_tcon.c | 121 ++++++++++++++++++++++++++++++++++++-\n> 1 file changed, 118 insertions(+), 3 deletions(-)\n> \n> diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c b/drivers/gpu/drm/sun4i/sun4i_tcon.c\n> index 065654dbfb2c..33c20d2f9fb1 100644\n> --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c\n> +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c\n> @@ -463,8 +463,9 @@ static int sun4i_tcon_init_regmap(struct device *dev,\n> * function in fact searches the corresponding engine, and the ID is\n> * requested via the get_id function of the engine.\n> */\n> -static struct sunxi_engine *sun4i_tcon_find_engine(struct sun4i_drv *drv,\n> -\t\t\t\t\t\t struct device_node *node)\n> +static struct sunxi_engine *\n> +sun4i_tcon_find_engine_traverse(struct sun4i_drv *drv,\n> +\t\t\t\tstruct device_node *node)\n> {\n> \tstruct device_node *port, *ep, *remote;\n> \tstruct sunxi_engine *engine;\n> @@ -502,7 +503,7 @@ static struct sunxi_engine *sun4i_tcon_find_engine(struct sun4i_drv *drv,\n> \t\t}\n> \n> \t\t/* keep looking through upstream ports */\n> -\t\tengine = sun4i_tcon_find_engine(drv, remote);\n> +\t\tengine = sun4i_tcon_find_engine_traverse(drv, remote);\n> \t\tif (!IS_ERR(engine)) {\n> \t\t\tof_node_put(remote);\n> \t\t\tof_node_put(port);\n> @@ -513,6 +514,120 @@ static struct sunxi_engine *sun4i_tcon_find_engine(struct sun4i_drv *drv,\n> \treturn ERR_PTR(-EINVAL);\n> }\n> \n> +/*\n> + * The device tree binding says that the remote endpoint ID of any\n> + * connection between components, up to and including the TCON, of\n> + * the display pipeline should be equal to the actual ID of the local\n> + * component. Thus we can look at any one of the input connections of\n> + * the TCONs, and use that connection's remote endpoint ID as our own.\n> + *\n> + * Since the user of this function already finds the input port,\n> + * the port is passed in directly without further checks.\n> + */\n> +static int sun4i_tcon_of_get_id_from_port(struct device_node *port)\n> +{\n> +\tstruct device_node *ep;\n> +\tint ret = -EINVAL;\n> +\n> +\t/* try finding an upstream endpoint */\n> +\tfor_each_available_child_of_node(port, ep) {\n> +\t\tstruct device_node *remote;\n> +\t\tu32 reg;\n> +\n> +\t\tremote = of_graph_get_remote_endpoint(ep);\n> +\t\tif (!remote)\n> +\t\t\tcontinue;\n> +\n> +\t\tret = of_property_read_u32(remote, \"reg\", ®);\n> +\t\tif (ret)\n> +\t\t\tcontinue;\n> +\n> +\t\tret = reg;\n> +\t}\n> +\n> +\treturn ret;\n> +}\n> +\n> +/*\n> + * Once we know the TCON's id, we can look through the list of\n> + * engines to find a matching one. We assume all engines have\n> + * been probed and added to the list.\n> + */\n> +static struct sunxi_engine *sun4i_tcon_get_engine_by_id(struct sun4i_drv *drv,\n> +\t\t\t\t\t\t\tint id)\n> +{\n> +\tstruct sunxi_engine *engine;\n> +\n> +\tlist_for_each_entry(engine, &drv->engine_list, list)\n> +\t\tif (engine->id == id)\n> +\t\t\treturn engine;\n> +\n> +\treturn ERR_PTR(-EINVAL);\n> +}\n> +\n> +/*\n> + * On SoCs with the old display pipeline design (Display Engine 1.0),\n> + * we assumed the TCON was always tied to just one backend. However\n> + * this proved not to be the case. On the A31, the TCON can select\n> + * either backend as its source. On the A20 (and likely on the A10),\n> + * the backend can choose which TCON to output to.\n> + *\n> + * The device tree binding says that the remote endpoint ID of any\n> + * connection between components, up to and including the TCON, of\n> + * the display pipeline should be equal to the actual ID of the local\n> + * component. Thus we should be able to look at any one of the input\n> + * connections of the TCONs, and use that connection's remote endpoint\n> + * ID as our own.\n> + *\n> + * However the connections between the backend and TCON were assumed\n> + * to be always singular, and their endpoit IDs were all incorrectly\n> + * set to 0. This means for these old device trees, we cannot just look\n> + * up the remote endpoint ID of a TCON input endpoint. TCON1 would be\n> + * incorrectly identified as TCON0.\n> + *\n> + * This function first checks if the TCON node has 2 input endpoints.\n> + * If so, then the device tree is a corrected version, and it will use\n> + * sun4i_tcon_of_get_id() and sun4i_tcon_get_engine_by_id() from above\n> + * to fetch the ID and engine directly. If not, then it is likely an\n> + * old device trees, where the endpoint IDs were incorrect, but did not\n> + * have endpoint connections between the backend and TCON across\n> + * different display pipelines. It will fall back to the old method of\n> + * traversing the of_graph to try and find a matching engine by device\n> + * node.\n> + *\n> + * In the case of single display pipeline device trees, either method\n> + * works.\n> + */\n> +static struct sunxi_engine *sun4i_tcon_find_engine(struct sun4i_drv *drv,\n> +\t\t\t\t\t\t struct device_node *node)\n> +{\n> +\tstruct device_node *port;\n> +\tstruct sunxi_engine *engine;\n> +\n> +\tport = of_graph_get_port_by_id(node, 0);\n> +\tif (!port)\n> +\t\treturn ERR_PTR(-EINVAL);\n> +\n> +\t/*\n> +\t * Is this a corrected device tree with cross pipeline\n> +\t * connections between the backend and TCON?\n> +\t */\n> +\tif (of_get_child_count(port) > 1) {\n> +\t\t/* Get our ID directly from an upstream endpoint */\n> +\t\tint id = sun4i_tcon_of_get_id_from_port(port);\n> +\n> +\t\t/* Get our engine by matching our ID */\n> +\t\tengine = sun4i_tcon_get_engine_by_id(drv, id);\n> +\n> +\t\tof_node_put(port);\n> +\t\treturn engine;\n> +\t}\n> +\n> +\t/* Fallback to old method by traversing input endpoints */\n> +\tof_node_put(port);\n> +\treturn sun4i_tcon_find_engine_traverse(drv, node);\n\nIn the old DT case, I'd like to have a warning displayed in the log\nsaying that the DT is too old and we won't be able to support the\ndual-pipeline properly, so that the users can at least know that they\nshould update.\n\nCan you add it in a follow-up?\n\nThanks!","headers":{"Return-Path":"","X-Original-To":"incoming-dt@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-dt@bilbo.ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=devicetree-owner@vger.kernel.org; receiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xqJP01ZP2z9sRY\n\tfor ;\n\tSun, 10 Sep 2017 01:43:00 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1753630AbdIIPm7 (ORCPT\n\t);\n\tSat, 9 Sep 2017 11:42:59 -0400","from mail.free-electrons.com ([62.4.15.54]:34039 \"EHLO\n\tmail.free-electrons.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1753519AbdIIPm6 (ORCPT\n\t); Sat, 9 Sep 2017 11:42:58 -0400","by mail.free-electrons.com (Postfix, from userid 110)\n\tid D1EB420A1C; Sat, 9 Sep 2017 17:42:57 +0200 (CEST)","from localhost (LFbn-TOU-1-209-191.w86-201.abo.wanadoo.fr\n\t[86.201.56.191])\n\tby mail.free-electrons.com (Postfix) with ESMTPSA id A3AFE20910;\n\tSat, 9 Sep 2017 17:42:57 +0200 (CEST)"],"X-Spam-Checker-Version":"SpamAssassin 3.4.0 (2014-02-07) on\n\tmail.free-electrons.com","X-Spam-Level":"","X-Spam-Status":"No, score=-1.0 required=5.0 tests=ALL_TRUSTED,SHORTCIRCUIT,\n\tURIBL_BLOCKED shortcircuit=ham autolearn=disabled version=3.4.0","Date":"Sat, 9 Sep 2017 17:42:57 +0200","From":"Maxime Ripard ","To":"Chen-Yu Tsai ","Cc":"David Airlie , dri-devel@lists.freedesktop.org,\n\tlinux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org","Subject":"Re: [PATCH 4/8] drm/sun4i: tcon: get TCON ID and matching engine\n\twith remote endpoint ID","Message-ID":"<20170909154257.wgwybldpmpr6snsc@flea.lan>","References":"<20170908075016.18657-1-wens@csie.org>\n\t<20170908075016.18657-5-wens@csie.org>","MIME-Version":"1.0","Content-Type":"multipart/signed; micalg=pgp-sha1;\n\tprotocol=\"application/pgp-signature\"; boundary=\"ri7gvs7xpplwpxxr\"","Content-Disposition":"inline","In-Reply-To":"<20170908075016.18657-5-wens@csie.org>","User-Agent":"NeoMutt/20170714 (1.8.3)","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}}]