[{"id":1773300,"web_url":"http://patchwork.ozlabs.org/comment/1773300/","msgid":"<1814950930.414004.1506062733728@email.1und1.de>","list_archive_url":null,"date":"2017-09-22T06:45:33","subject":"Re: [PATCH v3 2/4] [media] dt-bindings: Document BCM283x CSI2/CCP2\n\treceiver","submitter":{"id":61266,"url":"http://patchwork.ozlabs.org/api/people/61266/","name":"Stefan Wahren","email":"stefan.wahren@i2se.com"},"content":"Hi Dave,\n\n> Dave Stevenson hat am 20. September 2017 um 18:07 geschrieben:\n> \n> \n> Document the DT bindings for the CSI2/CCP2 receiver peripheral\n> (known as Unicam) on BCM283x SoCs.\n> \n> Signed-off-by: Dave Stevenson \n> ---\n> \n> Changes since v2\n> - Removed all references to Linux drivers.\n> - Reworded section about disabling the firmware driver.\n> - Renamed clock from \"lp_clock\" to \"lp\" in description and example.\n> - Referred to video-interfaces.txt and stated requirements on remote-endpoint\n> and data-lanes.\n> - Corrected typo in example from csi to csi1.\n> - Removed unnecessary #address-cells and #size-cells in example.\n> - Removed setting of status from the example.\n> \n> .../devicetree/bindings/media/bcm2835-unicam.txt | 85 ++++++++++++++++++++++\n> 1 file changed, 85 insertions(+)\n> create mode 100644 Documentation/devicetree/bindings/media/bcm2835-unicam.txt\n> \n> diff --git a/Documentation/devicetree/bindings/media/bcm2835-unicam.txt b/Documentation/devicetree/bindings/media/bcm2835-unicam.txt\n> new file mode 100644\n> index 0000000..7714fb3\n> --- /dev/null\n> +++ b/Documentation/devicetree/bindings/media/bcm2835-unicam.txt\n> @@ -0,0 +1,85 @@\n> +Broadcom BCM283x Camera Interface (Unicam)\n> +------------------------------------------\n> +\n> +The Unicam block on BCM283x SoCs is the receiver for either\n> +CSI-2 or CCP2 data from image sensors or similar devices.\n> +\n> +The main platform using this SoC is the Raspberry Pi family of boards.\n> +On the Pi the VideoCore firmware can also control this hardware block,\n> +and driving it from two different processors will cause issues.\n> +To avoid this, the firmware checks the device tree configuration\n> +during boot. If it finds device tree nodes called csi0 or csi1 then\n> +it will stop the firmware accessing the block, and it can then\n> +safely be used via the device tree binding.\n> +\n> +Required properties:\n> +===================\n> +- compatible\t: must be \"brcm,bcm2835-unicam\".\n> +- reg\t\t: physical base address and length of the register sets for the\n> +\t\t device.\n> +- interrupts\t: should contain the IRQ line for this Unicam instance.\n> +- clocks\t: list of clock specifiers, corresponding to entries in\n> +\t\t clock-names property.\n> +- clock-names\t: must contain an \"lp\" entry, matching entries in the\n> +\t\t clocks property.\n> +\n> +Unicam supports a single port node. It should contain one 'port' child node\n> +with child 'endpoint' node. Please refer to the bindings defined in\n> +Documentation/devicetree/bindings/media/video-interfaces.txt.\n> +\n> +Within the endpoint node the \"remote-endpoint\" and \"data-lanes\" properties\n> +are mandatory.\n> +Data lane reordering is not supported so the data lanes must be in order,\n> +starting at 1. The number of data lanes should represent the number of\n> +usable lanes for the hardware block. That may be limited by either the SoC or\n> +how the platform presents the interface, and the lower value must be used.\n> +\n> +Lane reordering is not supported on the clock lane either, so the optional\n> +property \"clock-lane\" will implicitly be <0>.\n> +Similarly lane inversion is not supported, therefore \"lane-polarities\" will\n> +implicitly be <0 0 0 0 0>.\n> +Neither of these values will be checked.\n> +\n> +Example:\n> +\tcsi1: csi1@7e801000 {\n> +\t\tcompatible = \"brcm,bcm2835-unicam\";\n> +\t\treg = <0x7e801000 0x800>,\n> +\t\t <0x7e802004 0x4>;\n\nsorry, i didn't noticed this before. I'm afraid this is using a small range of the CMI. Are there possible other users of this range? Does it make sense to handle this by a separate clock driver?\n\nRegards\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 3xz3sv4w0lz9sP1\n\tfor ;\n\tFri, 22 Sep 2017 16:46:27 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751821AbdIVGq0 (ORCPT\n\t);\n\tFri, 22 Sep 2017 02:46:26 -0400","from mout.kundenserver.de ([212.227.126.133]:59374 \"EHLO\n\tmout.kundenserver.de\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1751637AbdIVGqZ (ORCPT\n\t); Fri, 22 Sep 2017 02:46:25 -0400","from oxbsltgw58.schlund.de ([172.19.249.148]) by\n\tmrelayeu.kundenserver.de (mreue005 [212.227.15.167]) with ESMTPSA\n\t(Nemesis)\n\tid 0MURN9-1dnLWG3ADj-00RLBk; Fri, 22 Sep 2017 08:45:35 +0200"],"Date":"Fri, 22 Sep 2017 08:45:33 +0200 (CEST)","From":"Stefan Wahren ","To":"Mauro Carvalho Chehab ,\n\tEric Anholt , linux-media@vger.kernel.org,\n\tRob Herring ,\n\tDave Stevenson ,\n\tSakari Ailus ,\n\tHans Verkuil , \n\tlinux-rpi-kernel@lists.infradead.org, devicetree@vger.kernel.org","Message-ID":"<1814950930.414004.1506062733728@email.1und1.de>","In-Reply-To":"","References":"\n\t","Subject":"Re: [PATCH v3 2/4] [media] dt-bindings: Document BCM283x CSI2/CCP2\n\treceiver","MIME-Version":"1.0","Content-Type":"text/plain; charset=UTF-8","Content-Transfer-Encoding":"7bit","X-Priority":"3","Importance":"Medium","X-Mailer":"Open-Xchange Mailer v7.8.3-Rev30","X-Originating-Client":"open-xchange-appsuite","X-Provags-ID":"V03:K0:CipPneh7N37ormUgZghBVhej3AFkKv3noPaxNx1WR3nc3Ps9Uwc\n\tqOAxMwBNg4PPMEUBl1k00KedoQf0Mddg9pAfqBcWIDyW5FDIpCEi9TZUaSbkuXlj8PjWYgc\n\tMcpgjfQ6XTf6hFzVWIqf0nER8uraFuzktyQ4sUF9iw1UIX8XQt/Tjn4Jywmfb7Sv8ZcIPjw\n\tN5rHbiF9DehwwhO94g6Cg==","X-UI-Out-Filterresults":"notjunk:1; V01:K0:xHWYHdD5/KU=:3iMaRR88brviknf/mGGVC3\n\tXKcaPUvn6GozTqT9EZAoIJs7VGBqSlb7tBNyOau99Ct0XqdLXDHjOf+3i2Pq5NA36myFzGWRE\n\tj2w35i5JVLd4/3SogxwR6qyY6rU93PolebRrmHPjwkEZmkCauAzLHoJi63RbLLCxv3PdfNACC\n\t31MvZP98/mYn4AIHJtUuJh5/2qZoAh4+/zA0aq5MgMRCDb5J7kCZI9m/0mPPFztOvTn/RX4nY\n\tv5OOuz7oZN2uElb/yrH581hXEanRnfUfAA5biWmB9ugjY1dy7JL4h0YS7luqr3m9D7djT1Tud\n\ty6JiKTTmVgB5Plc6yIgyJAtxcKEvOOF89BJGlIpdgrXisKQcfaV7Hjv79k5F4WwCiGUsdr+jj\n\tfyA6LaeUxd2D5MTuBVO4x6s97bjklvszpY/6Tr0u0noQN3bVg12OriU5A/ALuttSHyqxvx5VA\n\tONsJh5UtSyfAkgZGU9bmo3P0kzHaRcz5/k6c8FmGd/2+j1AAuBxatLgHqXpD0+3WdbacXjQce\n\tE+yxTC3bdxOaQxsunKATWVVp9XPTEAyptPGp8lZZNqQRytN62oWTtF0D1XQXt4vTbeu2eIsfO\n\tO1Q3CR+7sI+UpeYQT0PlGMABNIyTp+HK9QexTsnzNqyEXzgbflYC2Fu0su9Og1MPuGTaNecey\n\tkL9GcsXoOYwWupDFjf8uA7yHYRNBFjMjkdbvYDA0ib98Vpve43EutqIADAqUvWjQaGowVwVx/\n\tbOzAAn9ugYsGDWfjKUNIR1hvO+G0xmiR3r1yxdwLHRORh7nACTWYFo81wj8=","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1773717,"web_url":"http://patchwork.ozlabs.org/comment/1773717/","msgid":"","list_archive_url":null,"date":"2017-09-22T16:07:22","subject":"Re: [PATCH v3 2/4] [media] dt-bindings: Document BCM283x CSI2/CCP2\n\treceiver","submitter":{"id":72357,"url":"http://patchwork.ozlabs.org/api/people/72357/","name":"Dave Stevenson","email":"dave.stevenson@raspberrypi.org"},"content":"Hi Stefan\n\nOn 22 September 2017 at 07:45, Stefan Wahren wrote:\n> Hi Dave,\n>\n>> Dave Stevenson hat am 20. September 2017 um 18:07 geschrieben:\n>>\n>>\n>> Document the DT bindings for the CSI2/CCP2 receiver peripheral\n>> (known as Unicam) on BCM283x SoCs.\n>>\n>> Signed-off-by: Dave Stevenson \n>> ---\n>>\n>> Changes since v2\n>> - Removed all references to Linux drivers.\n>> - Reworded section about disabling the firmware driver.\n>> - Renamed clock from \"lp_clock\" to \"lp\" in description and example.\n>> - Referred to video-interfaces.txt and stated requirements on remote-endpoint\n>> and data-lanes.\n>> - Corrected typo in example from csi to csi1.\n>> - Removed unnecessary #address-cells and #size-cells in example.\n>> - Removed setting of status from the example.\n>>\n>> .../devicetree/bindings/media/bcm2835-unicam.txt | 85 ++++++++++++++++++++++\n>> 1 file changed, 85 insertions(+)\n>> create mode 100644 Documentation/devicetree/bindings/media/bcm2835-unicam.txt\n>>\n>> diff --git a/Documentation/devicetree/bindings/media/bcm2835-unicam.txt b/Documentation/devicetree/bindings/media/bcm2835-unicam.txt\n>> new file mode 100644\n>> index 0000000..7714fb3\n>> --- /dev/null\n>> +++ b/Documentation/devicetree/bindings/media/bcm2835-unicam.txt\n>> @@ -0,0 +1,85 @@\n>> +Broadcom BCM283x Camera Interface (Unicam)\n>> +------------------------------------------\n>> +\n>> +The Unicam block on BCM283x SoCs is the receiver for either\n>> +CSI-2 or CCP2 data from image sensors or similar devices.\n>> +\n>> +The main platform using this SoC is the Raspberry Pi family of boards.\n>> +On the Pi the VideoCore firmware can also control this hardware block,\n>> +and driving it from two different processors will cause issues.\n>> +To avoid this, the firmware checks the device tree configuration\n>> +during boot. If it finds device tree nodes called csi0 or csi1 then\n>> +it will stop the firmware accessing the block, and it can then\n>> +safely be used via the device tree binding.\n>> +\n>> +Required properties:\n>> +===================\n>> +- compatible : must be \"brcm,bcm2835-unicam\".\n>> +- reg : physical base address and length of the register sets for the\n>> + device.\n>> +- interrupts : should contain the IRQ line for this Unicam instance.\n>> +- clocks : list of clock specifiers, corresponding to entries in\n>> + clock-names property.\n>> +- clock-names : must contain an \"lp\" entry, matching entries in the\n>> + clocks property.\n>> +\n>> +Unicam supports a single port node. It should contain one 'port' child node\n>> +with child 'endpoint' node. Please refer to the bindings defined in\n>> +Documentation/devicetree/bindings/media/video-interfaces.txt.\n>> +\n>> +Within the endpoint node the \"remote-endpoint\" and \"data-lanes\" properties\n>> +are mandatory.\n>> +Data lane reordering is not supported so the data lanes must be in order,\n>> +starting at 1. The number of data lanes should represent the number of\n>> +usable lanes for the hardware block. That may be limited by either the SoC or\n>> +how the platform presents the interface, and the lower value must be used.\n>> +\n>> +Lane reordering is not supported on the clock lane either, so the optional\n>> +property \"clock-lane\" will implicitly be <0>.\n>> +Similarly lane inversion is not supported, therefore \"lane-polarities\" will\n>> +implicitly be <0 0 0 0 0>.\n>> +Neither of these values will be checked.\n>> +\n>> +Example:\n>> + csi1: csi1@7e801000 {\n>> + compatible = \"brcm,bcm2835-unicam\";\n>> + reg = <0x7e801000 0x800>,\n>> + <0x7e802004 0x4>;\n>\n> sorry, i didn't noticed this before. I'm afraid this is using a small range of the CMI. Are there possible other users of this range? Does it make sense to handle this by a separate clock driver?\n\nCMI (Clock Manager Image) consists of a total of 4 registers.\n0x7e802000 is CMI_CAM0, with only bits 0-5 used for gating and\ninversion of the clock and data lanes (2 data lanes available on\nCAM0).\n0x7e802004 is CMI_CAM1, with only bits 0-9 used for gating and\ninversion of the clock and data lanes (4 data lanes available on\nCAM1).\n0x7e802008 is CMI_CAMTEST which I have no documentation or drivers for.\n0x7e802010 is CMI_USBCTL. Only bit 6 is documented and is a reset. The\ndefault value is the required value. Nothing touches it that I can\nfind.\n\nThe range listed only covers the one register associated with that\nUnicam instance, so no other users. The other two aren't touched.\nDo 16 active register bits solely for camera clock gating really\nwarrant a full clock driver?\n\n Dave\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=)","ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tsecure) header.d=raspberrypi.org header.i=@raspberrypi.org\n\theader.b=\"GVQjXDAu\"; \n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=raspberrypi-org.20150623.gappssmtp.com\n\theader.i=@raspberrypi-org.20150623.gappssmtp.com header.b=\"Cu43Agcn\"; \n\tdkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xzJKF5cspz9t3h\n\tfor ;\n\tSat, 23 Sep 2017 02:07:29 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1752168AbdIVQH2 (ORCPT\n\t);\n\tFri, 22 Sep 2017 12:07:28 -0400","from mx08-00252a01.pphosted.com ([91.207.212.211]:37890 \"EHLO\n\tmx08-00252a01.pphosted.com\" rhost-flags-OK-OK-OK-OK)\n\tby vger.kernel.org with ESMTP id S1751877AbdIVQH0 (ORCPT\n\t); Fri, 22 Sep 2017 12:07:26 -0400","from pps.filterd (m0102629.ppops.net [127.0.0.1])\n\tby mx08-00252a01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id\n\tv8MG5uoa011704\n\tfor ; Fri, 22 Sep 2017 17:07:25 +0100","from mail-pf0-f197.google.com (mail-pf0-f197.google.com\n\t[209.85.192.197])\n\tby mx08-00252a01.pphosted.com with ESMTP id 2d0reg34qs-1\n\t(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128\n\tverify=OK)\n\tfor ; Fri, 22 Sep 2017 17:07:25 +0100","by mail-pf0-f197.google.com with SMTP id x78so2577763pff.7\n\tfor ;\n\tFri, 22 Sep 2017 09:07:24 -0700 (PDT)","by 10.100.185.135 with HTTP; Fri, 22 Sep 2017 09:07:22 -0700 (PDT)"],"DKIM-Signature":["v=1; a=rsa-sha256; c=relaxed/relaxed; d=raspberrypi.org;\n\th=mime-version :\n\tin-reply-to : references : from : date : message-id : subject : to :\n\tcc :\n\tcontent-type; s=pp; bh=jYlWOkdLI72GvIhRoRvKqWqaJpAHsyQ655hjRZs+g7c=; \n\tb=GVQjXDAu5MM6U72GMOXt4lHO+v789semCwXIotekt3syPSC8929kNFnqU7mI1qQif43r\n\tFrRNh9rUqmlS9mYNW/Xics9CyNgacvivGECgjPP+BDOi6aRVVzzLSMTEuvkj/Eyf6t4K\n\tSMMr8TvUR8QFFpZcCV5znEjR/jXGl9uIlFiaA/EsOo/lF4uYP9AVBgzLi/8i/kN9umO5\n\twT87TkEfm2TaULt+QIXSpBeSWib+qgV9/R69YiogysFQTgaZWk5abo18Bqr3P9dTyOWG\n\tnXc+OU8pJ7X4AGcerCsZntrYtBxLmd5ZA2cEx69d3QEoNbUeAtHGv/IWeEEUY9D/2Gue\n\txg== ","v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=raspberrypi-org.20150623.gappssmtp.com; s=20150623;\n\th=mime-version:in-reply-to:references:from:date:message-id:subject:to\n\t:cc; bh=jYlWOkdLI72GvIhRoRvKqWqaJpAHsyQ655hjRZs+g7c=;\n\tb=Cu43AgcnPoIXXVU4L45L0VDdqW5PpjgpddUHPim2eXAOkC7WXoUBXifkl3OSTb88VT\n\tCL3TLFPb/rUvSYAZNCJcxGW8lz+kksadryM6RU6EA7fW9x4DNAHkcX1DtK6tw1QdncAI\n\tQM3WDcv5dYV3jtMmsme+BarrUr0DVJslRzg+7rKz0jW0RwcXt2vZz54nVVC6GXmN2g0N\n\tLyaFsLqgi765KpHLc/06iaMQe6xZ97pEHMhI77eIe4ZHiUohgt/GnYgl2JZsyL3dwhPq\n\tBNVVQ2Ip3SLL1aK6xMHiSULdUs6qb4CnkppeNmAsDbUglF8DhvBmvfs/aHtQ6JfHxy2Y\n\tnl+w=="],"X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:mime-version:in-reply-to:references:from:date\n\t:message-id:subject:to:cc;\n\tbh=jYlWOkdLI72GvIhRoRvKqWqaJpAHsyQ655hjRZs+g7c=;\n\tb=K1jQEQc7xeftzNimEhHcH9OBNiLTQEigbpv4he7e2euDHv8iNPAZlzn+ZtE4FDQwEi\n\tRPM3pa08D6TUl3619EJBS4zyQVsRJbwb0pFRJdMYSp7ROUIlI3y+bu9L8FuJ1ISA1uai\n\t5N1CDT+H9bVkiulVmRLuRWIKDDTto4bTKB9tiewEylm7BLuK8zBEgd+MLDrXN/tRbnnK\n\t9J5oC9EF4pNmQ3+hnlnU3q2XNKKHwtv69mOR2696rb0GIc6xldda+iHlqHBbd4D//Z25\n\trfbXAbUgHZXcMIZ2ZgrZmm5mxlB8t9sKzcESsrxW2bsXatNmRhXiH8TmkUeiRnSheUj0\n\tTeUQ==","X-Gm-Message-State":"AHPjjUillz+RPM9owPzJtAzBOcV7dp8qdfLCZtnohNbRa2ytB1A6kqpa\n\tnD30MI31HMk5QHfOKOgpafHFk5rXJHHmyHUt6HJJDJ0ch0h6UNeFFG1Wf+oBRbUJpXh1SRsuFDq\n\t1YmG+ty/iVaZYwzyuH5k9S3oQP7pTCm8hf/A6","X-Received":["by 10.159.218.69 with SMTP id x5mr9385885plv.4.1506096443230;\n\tFri, 22 Sep 2017 09:07:23 -0700 (PDT)","by 10.159.218.69 with SMTP id x5mr9385867plv.4.1506096442848;\n\tFri, 22 Sep 2017 09:07:22 -0700 (PDT)"],"X-Google-Smtp-Source":"AOwi7QDEoc/nSK9PswDceJNRbSwe1Vlz45LxQtECKxYut/ozww+czqxoZsq5nml3APTti5Evq6w2k3wgCcVpLAGBmks=","MIME-Version":"1.0","In-Reply-To":"<1814950930.414004.1506062733728@email.1und1.de>","References":"\n\t\n\t<1814950930.414004.1506062733728@email.1und1.de>","From":"Dave Stevenson ","Date":"Fri, 22 Sep 2017 17:07:22 +0100","Message-ID":"","Subject":"Re: [PATCH v3 2/4] [media] dt-bindings: Document BCM283x CSI2/CCP2\n\treceiver","To":"Stefan Wahren ","Cc":"Mauro Carvalho Chehab ,\n\tEric Anholt , linux-media@vger.kernel.org,\n\tRob Herring , Sakari Ailus , \n\tHans Verkuil ,\n\tlinux-rpi-kernel@lists.infradead.org, devicetree@vger.kernel.org","Content-Type":"text/plain; charset=\"UTF-8\"","X-Proofpoint-Virus-Version":"vendor=fsecure engine=2.50.10432:, ,\n\tdefinitions=2017-09-22_06:, , signatures=0","X-Proofpoint-Spam-Details":"rule=outbound_spam_notspam policy=outbound_spam\n\tscore=0 priorityscore=1501\n\tmalwarescore=0 suspectscore=1 phishscore=0 bulkscore=0 spamscore=0\n\tclxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0\n\tclassifier=spam adjust=0 reason=mlx scancount=1\n\tengine=8.0.1-1707230000\n\tdefinitions=main-1709220227","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1773790,"web_url":"http://patchwork.ozlabs.org/comment/1773790/","msgid":"<73619863.196918.1506101985740@email.1und1.de>","list_archive_url":null,"date":"2017-09-22T17:39:45","subject":"Re: [PATCH v3 2/4] [media] dt-bindings: Document BCM283x CSI2/CCP2\n\treceiver","submitter":{"id":61266,"url":"http://patchwork.ozlabs.org/api/people/61266/","name":"Stefan Wahren","email":"stefan.wahren@i2se.com"},"content":"Hi Dave,\n\n> Dave Stevenson hat am 22. September 2017 um 18:07 geschrieben:\n> \n> \n> Hi Stefan\n> \n> On 22 September 2017 at 07:45, Stefan Wahren wrote:\n> > Hi Dave,\n> >\n> >> Dave Stevenson hat am 20. September 2017 um 18:07 geschrieben:\n> >>\n> >>\n> >> Document the DT bindings for the CSI2/CCP2 receiver peripheral\n> >> (known as Unicam) on BCM283x SoCs.\n> >>\n> >> Signed-off-by: Dave Stevenson \n> >> ---\n> >>\n> >> Changes since v2\n> >> - Removed all references to Linux drivers.\n> >> - Reworded section about disabling the firmware driver.\n> >> - Renamed clock from \"lp_clock\" to \"lp\" in description and example.\n> >> - Referred to video-interfaces.txt and stated requirements on remote-endpoint\n> >> and data-lanes.\n> >> - Corrected typo in example from csi to csi1.\n> >> - Removed unnecessary #address-cells and #size-cells in example.\n> >> - Removed setting of status from the example.\n> >>\n> >> .../devicetree/bindings/media/bcm2835-unicam.txt | 85 ++++++++++++++++++++++\n> >> 1 file changed, 85 insertions(+)\n> >> create mode 100644 Documentation/devicetree/bindings/media/bcm2835-unicam.txt\n> >>\n> >> diff --git a/Documentation/devicetree/bindings/media/bcm2835-unicam.txt b/Documentation/devicetree/bindings/media/bcm2835-unicam.txt\n> >> new file mode 100644\n> >> index 0000000..7714fb3\n> >> --- /dev/null\n> >> +++ b/Documentation/devicetree/bindings/media/bcm2835-unicam.txt\n> >> @@ -0,0 +1,85 @@\n> >> +Broadcom BCM283x Camera Interface (Unicam)\n> >> +------------------------------------------\n> >> +\n> >> +The Unicam block on BCM283x SoCs is the receiver for either\n> >> +CSI-2 or CCP2 data from image sensors or similar devices.\n> >> +\n> >> +The main platform using this SoC is the Raspberry Pi family of boards.\n> >> +On the Pi the VideoCore firmware can also control this hardware block,\n> >> +and driving it from two different processors will cause issues.\n> >> +To avoid this, the firmware checks the device tree configuration\n> >> +during boot. If it finds device tree nodes called csi0 or csi1 then\n> >> +it will stop the firmware accessing the block, and it can then\n> >> +safely be used via the device tree binding.\n> >> +\n> >> +Required properties:\n> >> +===================\n> >> +- compatible : must be \"brcm,bcm2835-unicam\".\n> >> +- reg : physical base address and length of the register sets for the\n> >> + device.\n> >> +- interrupts : should contain the IRQ line for this Unicam instance.\n> >> +- clocks : list of clock specifiers, corresponding to entries in\n> >> + clock-names property.\n> >> +- clock-names : must contain an \"lp\" entry, matching entries in the\n> >> + clocks property.\n> >> +\n> >> +Unicam supports a single port node. It should contain one 'port' child node\n> >> +with child 'endpoint' node. Please refer to the bindings defined in\n> >> +Documentation/devicetree/bindings/media/video-interfaces.txt.\n> >> +\n> >> +Within the endpoint node the \"remote-endpoint\" and \"data-lanes\" properties\n> >> +are mandatory.\n> >> +Data lane reordering is not supported so the data lanes must be in order,\n> >> +starting at 1. The number of data lanes should represent the number of\n> >> +usable lanes for the hardware block. That may be limited by either the SoC or\n> >> +how the platform presents the interface, and the lower value must be used.\n> >> +\n> >> +Lane reordering is not supported on the clock lane either, so the optional\n> >> +property \"clock-lane\" will implicitly be <0>.\n> >> +Similarly lane inversion is not supported, therefore \"lane-polarities\" will\n> >> +implicitly be <0 0 0 0 0>.\n> >> +Neither of these values will be checked.\n> >> +\n> >> +Example:\n> >> + csi1: csi1@7e801000 {\n> >> + compatible = \"brcm,bcm2835-unicam\";\n> >> + reg = <0x7e801000 0x800>,\n> >> + <0x7e802004 0x4>;\n> >\n> > sorry, i didn't noticed this before. I'm afraid this is using a small range of the CMI. Are there possible other users of this range? Does it make sense to handle this by a separate clock driver?\n> \n> CMI (Clock Manager Image) consists of a total of 4 registers.\n> 0x7e802000 is CMI_CAM0, with only bits 0-5 used for gating and\n> inversion of the clock and data lanes (2 data lanes available on\n> CAM0).\n> 0x7e802004 is CMI_CAM1, with only bits 0-9 used for gating and\n> inversion of the clock and data lanes (4 data lanes available on\n> CAM1).\n> 0x7e802008 is CMI_CAMTEST which I have no documentation or drivers for.\n> 0x7e802010 is CMI_USBCTL. Only bit 6 is documented and is a reset. The\n> default value is the required value. Nothing touches it that I can\n> find.\n\nthanks for providing these information.\n\n> \n> The range listed only covers the one register associated with that\n> Unicam instance, so no other users. The other two aren't touched.\n> Do 16 active register bits solely for camera clock gating really\n> warrant a full clock driver?\n\nAs long as there no new driver in the future, which also needs to touch these gates i'm fine.\n\nStefan\n\n> \n> Dave\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 3xzLNh0Hf0z9t3Z\n\tfor ;\n\tSat, 23 Sep 2017 03:40:36 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1752259AbdIVRke (ORCPT\n\t);\n\tFri, 22 Sep 2017 13:40:34 -0400","from mout.kundenserver.de ([212.227.17.24]:52453 \"EHLO\n\tmout.kundenserver.de\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1752218AbdIVRkd (ORCPT\n\t); Fri, 22 Sep 2017 13:40:33 -0400","from oxbsltgw05.schlund.de ([172.19.249.22]) by\n\tmrelayeu.kundenserver.de (mreue103 [212.227.15.183]) with ESMTPSA\n\t(Nemesis)\n\tid 0MQLgi-1dni8W0fuu-00TihA; Fri, 22 Sep 2017 19:39:48 +0200"],"Date":"Fri, 22 Sep 2017 19:39:45 +0200 (CEST)","From":"Stefan Wahren ","To":"Dave Stevenson ","Cc":"Mauro Carvalho Chehab ,\n\tEric Anholt , linux-media@vger.kernel.org,\n\tRob Herring , Sakari Ailus , \n\tHans Verkuil ,\n\tlinux-rpi-kernel@lists.infradead.org, devicetree@vger.kernel.org","Message-ID":"<73619863.196918.1506101985740@email.1und1.de>","In-Reply-To":"","References":"\n\t\n\t<1814950930.414004.1506062733728@email.1und1.de>\n\t","Subject":"Re: [PATCH v3 2/4] [media] dt-bindings: Document BCM283x CSI2/CCP2\n\treceiver","MIME-Version":"1.0","Content-Type":"text/plain; charset=UTF-8","Content-Transfer-Encoding":"7bit","X-Priority":"3","Importance":"Medium","X-Mailer":"Open-Xchange Mailer v7.8.3-Rev33","X-Originating-Client":"open-xchange-appsuite","X-Provags-ID":"V03:K0:PA+y3MQIoYfNkn4K5PfIwPcmxd2N6Znwup/xnEbs2M7FR2X+7Sh\n\tBJ26mflwXYQGuSJnu0HqgCdZo0NoLZiBAYtnkG1jjut4++Tmg1Eo9coy3hY6zSOdu603DPW\n\t0vVjSLrrEnvTZPoNTU6bbC14/oFYVjuMrYppcArChGX0U/a41Neo+E7LzPhhGL2KRw/+X97\n\tlZJV0VfH8ugARSx9NoW6w==","X-UI-Out-Filterresults":"notjunk:1; V01:K0:vuw8FO/Rdy4=:H7VVszIfRkk6JPDvcTauJr\n\tyw9odRzcJFXSNkWpGR/X/00V7IbINNHxF4wEbNZnOFfX87BXmHDzI/Pv0MwdHkadhA68hSYVi\n\tYS+qfuQm3nemp3WREYkNIxNkuLLkmE5BFJikcsS0nHlkHjpBbh5eVHXHejQqUELSWBdzF3f8p\n\tf4ra9o60wXUWdKQ8JJbox7CdRenouJcLL1Zd/rZEP9I9FbavZqNjL69K2yNNdhTk/RrxzuNha\n\tanKHJv6GH+zPWqygsVSC110NbfMA+G59K/hU7Jzt3VJfFkDg4SkQvYCU8d4WVS5ZGFhADJVPN\n\tzDq7SqML/e5ldlXrUUu/Sy9vI8XBxVYT5SuoqcMmez6xIQITjA+JFGsFIEaTuEMqn0yFxFAFS\n\tn14huOS84FyraXhZ8P2Efj9TOKMHLDdZAPy4N59rL2DVgc4Wg0G4JpVE4ESjq86z2MLOH7sdP\n\t1TmY/F8jWr96CxvI7cg0rld5C8wT2cPdPZc8dC1BoXgi8YRQhfzt3lHb0vx/TCyDJ8eX4RMHf\n\trfBtKEMHCty97ufvgmKI4xgkYC8xpxS8qzehL2Twb2gGfaJIowubI41VI6hnLHtUUKctHiP5S\n\t31A72k53JCQGEageTWg6ruaKmoTylgAcWGB84YbN8SHh7QAU67FoR5hMEOVwZQ1qnDjMqWi1F\n\t/6Wp0i6g2giQTlti+UJAbZQ35+tmdp1Dzx6El+kk/la/2ZRSeNGDS7sCiSAZ4VYUK4sarkiL8\n\ta6Me+YoTH54ByS/tkppwCer7EVjYQCdL4p0WlpLy5i89Q+m1Eimli0sKIbk=","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1773805,"web_url":"http://patchwork.ozlabs.org/comment/1773805/","msgid":"<877ewqd2yp.fsf@anholt.net>","list_archive_url":null,"date":"2017-09-22T18:04:46","subject":"Re: [PATCH v3 2/4] [media] dt-bindings: Document BCM283x CSI2/CCP2\n\treceiver","submitter":{"id":608,"url":"http://patchwork.ozlabs.org/api/people/608/","name":"Eric Anholt","email":"eric@anholt.net"},"content":"Dave Stevenson writes:\n\n> Hi Stefan\n>\n> On 22 September 2017 at 07:45, Stefan Wahren wrote:\n>> Hi Dave,\n>>\n>>> Dave Stevenson hat am 20. September 2017 um 18:07 geschrieben:\n>>>\n>>>\n>>> Document the DT bindings for the CSI2/CCP2 receiver peripheral\n>>> (known as Unicam) on BCM283x SoCs.\n>>>\n>>> Signed-off-by: Dave Stevenson \n>>> ---\n>>>\n>>> Changes since v2\n>>> - Removed all references to Linux drivers.\n>>> - Reworded section about disabling the firmware driver.\n>>> - Renamed clock from \"lp_clock\" to \"lp\" in description and example.\n>>> - Referred to video-interfaces.txt and stated requirements on remote-endpoint\n>>> and data-lanes.\n>>> - Corrected typo in example from csi to csi1.\n>>> - Removed unnecessary #address-cells and #size-cells in example.\n>>> - Removed setting of status from the example.\n>>>\n>>> .../devicetree/bindings/media/bcm2835-unicam.txt | 85 ++++++++++++++++++++++\n>>> 1 file changed, 85 insertions(+)\n>>> create mode 100644 Documentation/devicetree/bindings/media/bcm2835-unicam.txt\n>>>\n>>> diff --git a/Documentation/devicetree/bindings/media/bcm2835-unicam.txt b/Documentation/devicetree/bindings/media/bcm2835-unicam.txt\n>>> new file mode 100644\n>>> index 0000000..7714fb3\n>>> --- /dev/null\n>>> +++ b/Documentation/devicetree/bindings/media/bcm2835-unicam.txt\n>>> @@ -0,0 +1,85 @@\n>>> +Broadcom BCM283x Camera Interface (Unicam)\n>>> +------------------------------------------\n>>> +\n>>> +The Unicam block on BCM283x SoCs is the receiver for either\n>>> +CSI-2 or CCP2 data from image sensors or similar devices.\n>>> +\n>>> +The main platform using this SoC is the Raspberry Pi family of boards.\n>>> +On the Pi the VideoCore firmware can also control this hardware block,\n>>> +and driving it from two different processors will cause issues.\n>>> +To avoid this, the firmware checks the device tree configuration\n>>> +during boot. If it finds device tree nodes called csi0 or csi1 then\n>>> +it will stop the firmware accessing the block, and it can then\n>>> +safely be used via the device tree binding.\n>>> +\n>>> +Required properties:\n>>> +===================\n>>> +- compatible : must be \"brcm,bcm2835-unicam\".\n>>> +- reg : physical base address and length of the register sets for the\n>>> + device.\n>>> +- interrupts : should contain the IRQ line for this Unicam instance.\n>>> +- clocks : list of clock specifiers, corresponding to entries in\n>>> + clock-names property.\n>>> +- clock-names : must contain an \"lp\" entry, matching entries in the\n>>> + clocks property.\n>>> +\n>>> +Unicam supports a single port node. It should contain one 'port' child node\n>>> +with child 'endpoint' node. Please refer to the bindings defined in\n>>> +Documentation/devicetree/bindings/media/video-interfaces.txt.\n>>> +\n>>> +Within the endpoint node the \"remote-endpoint\" and \"data-lanes\" properties\n>>> +are mandatory.\n>>> +Data lane reordering is not supported so the data lanes must be in order,\n>>> +starting at 1. The number of data lanes should represent the number of\n>>> +usable lanes for the hardware block. That may be limited by either the SoC or\n>>> +how the platform presents the interface, and the lower value must be used.\n>>> +\n>>> +Lane reordering is not supported on the clock lane either, so the optional\n>>> +property \"clock-lane\" will implicitly be <0>.\n>>> +Similarly lane inversion is not supported, therefore \"lane-polarities\" will\n>>> +implicitly be <0 0 0 0 0>.\n>>> +Neither of these values will be checked.\n>>> +\n>>> +Example:\n>>> + csi1: csi1@7e801000 {\n>>> + compatible = \"brcm,bcm2835-unicam\";\n>>> + reg = <0x7e801000 0x800>,\n>>> + <0x7e802004 0x4>;\n>>\n>> sorry, i didn't noticed this before. I'm afraid this is using a small range of the CMI. Are there possible other users of this range? Does it make sense to handle this by a separate clock driver?\n>\n> CMI (Clock Manager Image) consists of a total of 4 registers.\n> 0x7e802000 is CMI_CAM0, with only bits 0-5 used for gating and\n> inversion of the clock and data lanes (2 data lanes available on\n> CAM0).\n> 0x7e802004 is CMI_CAM1, with only bits 0-9 used for gating and\n> inversion of the clock and data lanes (4 data lanes available on\n> CAM1).\n> 0x7e802008 is CMI_CAMTEST which I have no documentation or drivers for.\n> 0x7e802010 is CMI_USBCTL. Only bit 6 is documented and is a reset. The\n> default value is the required value. Nothing touches it that I can\n> find.\n\nYeah, my conclusion previously was that it's appropriate to consider\nthis register as part of the unicam instance. No other HW block could\nwant to talk to it.","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 3xzLwh499cz9t3h\n\tfor ;\n\tSat, 23 Sep 2017 04:04:52 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1752506AbdIVSEv (ORCPT\n\t);\n\tFri, 22 Sep 2017 14:04:51 -0400","from anholt.net ([50.246.234.109]:51150 \"EHLO anholt.net\"\n\trhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S1752504AbdIVSEu (ORCPT );\n\tFri, 22 Sep 2017 14:04:50 -0400","from localhost (localhost [127.0.0.1])\n\tby anholt.net (Postfix) with ESMTP id B707F10A1475;\n\tFri, 22 Sep 2017 11:04:49 -0700 (PDT)","from anholt.net ([127.0.0.1])\n\tby localhost (kingsolver.anholt.net [127.0.0.1]) (amavisd-new,\n\tport 10024)\n\twith LMTP id mzRG9ti9T9j0; Fri, 22 Sep 2017 11:04:48 -0700 (PDT)","from eliezer.anholt.net (localhost [127.0.0.1])\n\tby anholt.net (Postfix) with ESMTP id EAA5310A043B;\n\tFri, 22 Sep 2017 11:04:47 -0700 (PDT)","by eliezer.anholt.net (Postfix, from userid 1000)\n\tid 381002FE21E2; Fri, 22 Sep 2017 11:04:47 -0700 (PDT)"],"X-Virus-Scanned":"Debian amavisd-new at anholt.net","From":"Eric Anholt ","To":"Dave Stevenson ,\n\tStefan Wahren ","Cc":"Mauro Carvalho Chehab ,\n\tlinux-media@vger.kernel.org, Rob Herring ,\n\tSakari Ailus ,\n\tHans Verkuil , \n\tlinux-rpi-kernel@lists.infradead.org, devicetree@vger.kernel.org","Subject":"Re: [PATCH v3 2/4] [media] dt-bindings: Document BCM283x CSI2/CCP2\n\treceiver","In-Reply-To":"","References":"\n\t\n\t<1814950930.414004.1506062733728@email.1und1.de>\n\t","User-Agent":"Notmuch/0.22.2+1~gb0bcfaa (http://notmuchmail.org) Emacs/25.2.2\n\t(x86_64-pc-linux-gnu)","Date":"Fri, 22 Sep 2017 11:04:46 -0700","Message-ID":"<877ewqd2yp.fsf@anholt.net>","MIME-Version":"1.0","Content-Type":"multipart/signed; boundary=\"=-=-=\";\n\tmicalg=pgp-sha512; protocol=\"application/pgp-signature\"","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1776643,"web_url":"http://patchwork.ozlabs.org/comment/1776643/","msgid":"<20170927215124.6k3j54qf2qscnzc2@rob-hp-laptop>","list_archive_url":null,"date":"2017-09-27T21:51:24","subject":"Re: [PATCH v3 2/4] [media] dt-bindings: Document BCM283x CSI2/CCP2\n\treceiver","submitter":{"id":62529,"url":"http://patchwork.ozlabs.org/api/people/62529/","name":"Rob Herring (Arm)","email":"robh@kernel.org"},"content":"On Fri, Sep 22, 2017 at 05:07:22PM +0100, Dave Stevenson wrote:\n> Hi Stefan\n> \n> On 22 September 2017 at 07:45, Stefan Wahren wrote:\n> > Hi Dave,\n> >\n> >> Dave Stevenson hat am 20. September 2017 um 18:07 geschrieben:\n> >>\n> >>\n> >> Document the DT bindings for the CSI2/CCP2 receiver peripheral\n> >> (known as Unicam) on BCM283x SoCs.\n> >>\n> >> Signed-off-by: Dave Stevenson \n> >> ---\n> >>\n> >> Changes since v2\n> >> - Removed all references to Linux drivers.\n> >> - Reworded section about disabling the firmware driver.\n> >> - Renamed clock from \"lp_clock\" to \"lp\" in description and example.\n> >> - Referred to video-interfaces.txt and stated requirements on remote-endpoint\n> >> and data-lanes.\n> >> - Corrected typo in example from csi to csi1.\n> >> - Removed unnecessary #address-cells and #size-cells in example.\n> >> - Removed setting of status from the example.\n> >>\n> >> .../devicetree/bindings/media/bcm2835-unicam.txt | 85 ++++++++++++++++++++++\n> >> 1 file changed, 85 insertions(+)\n> >> create mode 100644 Documentation/devicetree/bindings/media/bcm2835-unicam.txt\n> >>\n> >> diff --git a/Documentation/devicetree/bindings/media/bcm2835-unicam.txt b/Documentation/devicetree/bindings/media/bcm2835-unicam.txt\n> >> new file mode 100644\n> >> index 0000000..7714fb3\n> >> --- /dev/null\n> >> +++ b/Documentation/devicetree/bindings/media/bcm2835-unicam.txt\n> >> @@ -0,0 +1,85 @@\n> >> +Broadcom BCM283x Camera Interface (Unicam)\n> >> +------------------------------------------\n> >> +\n> >> +The Unicam block on BCM283x SoCs is the receiver for either\n> >> +CSI-2 or CCP2 data from image sensors or similar devices.\n> >> +\n> >> +The main platform using this SoC is the Raspberry Pi family of boards.\n> >> +On the Pi the VideoCore firmware can also control this hardware block,\n> >> +and driving it from two different processors will cause issues.\n> >> +To avoid this, the firmware checks the device tree configuration\n> >> +during boot. If it finds device tree nodes called csi0 or csi1 then\n> >> +it will stop the firmware accessing the block, and it can then\n> >> +safely be used via the device tree binding.\n> >> +\n> >> +Required properties:\n> >> +===================\n> >> +- compatible : must be \"brcm,bcm2835-unicam\".\n> >> +- reg : physical base address and length of the register sets for the\n> >> + device.\n> >> +- interrupts : should contain the IRQ line for this Unicam instance.\n> >> +- clocks : list of clock specifiers, corresponding to entries in\n> >> + clock-names property.\n> >> +- clock-names : must contain an \"lp\" entry, matching entries in the\n> >> + clocks property.\n> >> +\n> >> +Unicam supports a single port node. It should contain one 'port' child node\n> >> +with child 'endpoint' node. Please refer to the bindings defined in\n> >> +Documentation/devicetree/bindings/media/video-interfaces.txt.\n> >> +\n> >> +Within the endpoint node the \"remote-endpoint\" and \"data-lanes\" properties\n> >> +are mandatory.\n> >> +Data lane reordering is not supported so the data lanes must be in order,\n> >> +starting at 1. The number of data lanes should represent the number of\n> >> +usable lanes for the hardware block. That may be limited by either the SoC or\n> >> +how the platform presents the interface, and the lower value must be used.\n> >> +\n> >> +Lane reordering is not supported on the clock lane either, so the optional\n> >> +property \"clock-lane\" will implicitly be <0>.\n> >> +Similarly lane inversion is not supported, therefore \"lane-polarities\" will\n> >> +implicitly be <0 0 0 0 0>.\n> >> +Neither of these values will be checked.\n> >> +\n> >> +Example:\n> >> + csi1: csi1@7e801000 {\n> >> + compatible = \"brcm,bcm2835-unicam\";\n> >> + reg = <0x7e801000 0x800>,\n> >> + <0x7e802004 0x4>;\n> >\n> > sorry, i didn't noticed this before. I'm afraid this is using a small range of the CMI. Are there possible other users of this range? Does it make sense to handle this by a separate clock driver?\n> \n> CMI (Clock Manager Image) consists of a total of 4 registers.\n> 0x7e802000 is CMI_CAM0, with only bits 0-5 used for gating and\n> inversion of the clock and data lanes (2 data lanes available on\n> CAM0).\n> 0x7e802004 is CMI_CAM1, with only bits 0-9 used for gating and\n> inversion of the clock and data lanes (4 data lanes available on\n> CAM1).\n> 0x7e802008 is CMI_CAMTEST which I have no documentation or drivers for.\n> 0x7e802010 is CMI_USBCTL. Only bit 6 is documented and is a reset. The\n> default value is the required value. Nothing touches it that I can\n> find.\n> \n> The range listed only covers the one register associated with that\n> Unicam instance, so no other users. The other two aren't touched.\n> Do 16 active register bits solely for camera clock gating really\n> warrant a full clock driver?\n\nYou should describe all the registers in DT, not just what the driver \n(currently) uses.\n\nRob\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 3y2Wjs6pw0z9t67\n\tfor ;\n\tThu, 28 Sep 2017 07:51:29 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1752011AbdI0Vv2 (ORCPT\n\t);\n\tWed, 27 Sep 2017 17:51:28 -0400","from mail-pg0-f67.google.com ([74.125.83.67]:34998 \"EHLO\n\tmail-pg0-f67.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1751905AbdI0Vv1 (ORCPT\n\t); Wed, 27 Sep 2017 17:51:27 -0400","by mail-pg0-f67.google.com with SMTP id j16so10466647pga.2;\n\tWed, 27 Sep 2017 14:51:27 -0700 (PDT)","from localhost ([70.35.39.2]) by smtp.gmail.com with ESMTPSA id\n\tk25sm19685958pgf.13.2017.09.27.14.51.25\n\t(version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256);\n\tWed, 27 Sep 2017 14:51:25 -0700 (PDT)"],"X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:date:from:to:cc:subject:message-id:references\n\t:mime-version:content-disposition:in-reply-to:user-agent;\n\tbh=3KF1SwpQiDBqUQzZUUBxLzmNrXa9HMHIp7bo/D/ltd4=;\n\tb=fuszca9rfNodh7if1PljCpFVgXdABapvUopnsr3DwUpqAuf3nSV1YPHIcIOm9JenJQ\n\t9v3foLloF22IKw0OJBa9fJWkmYsJpC21AqrgiS6ps/AeDIGj87G0KE7qvnWhAFhj3Lfu\n\tshmUrSclccLDggRs7wx1jfl4z7w6KKi5ZctQZAlT4f+8YM+ejCNm0qaJmo2ueDal4wru\n\tV/L+rCK1iuQ57V/EXnS8r7HRCfogVV1unne9lQlw4T8/YFt4cUpieUp+IMxb+vAkCYx8\n\t6Z7qDZuGwD4R8Yf9F5StFMy+8T1GOSXKFZtHC72W3ZYjQJalyq9D3ynJYyInyxJlDuhV\n\tDrAw==","X-Gm-Message-State":"AHPjjUhw5X3AdBU0J7hfACObo4iUM6+OFgtWyFnFmLrioe+VjxBQQ0X4\n\tOPKwHHQVRcRqkzYSjUufIqGzQXU=","X-Google-Smtp-Source":"AOwi7QBn8yCQ/nm2d+ohJs7cglmJGq0pjm2VSynuPJAjTUUw7tQKBL2M9hJjIWgMg7yeYnc1azJekw==","X-Received":"by 10.99.126.84 with SMTP id o20mr2449540pgn.137.1506549086612; \n\tWed, 27 Sep 2017 14:51:26 -0700 (PDT)","Date":"Wed, 27 Sep 2017 16:51:24 -0500","From":"Rob Herring ","To":"Dave Stevenson ","Cc":"Stefan Wahren ,\n\tMauro Carvalho Chehab ,\n\tEric Anholt , linux-media@vger.kernel.org,\n\tSakari Ailus ,\n\tHans Verkuil , \n\tlinux-rpi-kernel@lists.infradead.org, devicetree@vger.kernel.org","Subject":"Re: [PATCH v3 2/4] [media] dt-bindings: Document BCM283x CSI2/CCP2\n\treceiver","Message-ID":"<20170927215124.6k3j54qf2qscnzc2@rob-hp-laptop>","References":"\n\t\n\t<1814950930.414004.1506062733728@email.1und1.de>\n\t","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"","User-Agent":"NeoMutt/20170113 (1.7.2)","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1778245,"web_url":"http://patchwork.ozlabs.org/comment/1778245/","msgid":"","list_archive_url":null,"date":"2017-10-02T10:36:03","subject":"Re: [PATCH v3 2/4] [media] dt-bindings: Document BCM283x CSI2/CCP2\n\treceiver","submitter":{"id":72357,"url":"http://patchwork.ozlabs.org/api/people/72357/","name":"Dave Stevenson","email":"dave.stevenson@raspberrypi.org"},"content":"Hi Rob\n\nOn 27 September 2017 at 22:51, Rob Herring wrote:\n> On Fri, Sep 22, 2017 at 05:07:22PM +0100, Dave Stevenson wrote:\n>> Hi Stefan\n>>\n>> On 22 September 2017 at 07:45, Stefan Wahren wrote:\n>> > Hi Dave,\n>> >\n>> >> Dave Stevenson hat am 20. September 2017 um 18:07 geschrieben:\n>> >>\n>> >>\n>> >> Document the DT bindings for the CSI2/CCP2 receiver peripheral\n>> >> (known as Unicam) on BCM283x SoCs.\n>> >>\n>> >> Signed-off-by: Dave Stevenson \n>> >> ---\n>> >>\n>> >> Changes since v2\n>> >> - Removed all references to Linux drivers.\n>> >> - Reworded section about disabling the firmware driver.\n>> >> - Renamed clock from \"lp_clock\" to \"lp\" in description and example.\n>> >> - Referred to video-interfaces.txt and stated requirements on remote-endpoint\n>> >> and data-lanes.\n>> >> - Corrected typo in example from csi to csi1.\n>> >> - Removed unnecessary #address-cells and #size-cells in example.\n>> >> - Removed setting of status from the example.\n>> >>\n>> >> .../devicetree/bindings/media/bcm2835-unicam.txt | 85 ++++++++++++++++++++++\n>> >> 1 file changed, 85 insertions(+)\n>> >> create mode 100644 Documentation/devicetree/bindings/media/bcm2835-unicam.txt\n>> >>\n>> >> diff --git a/Documentation/devicetree/bindings/media/bcm2835-unicam.txt b/Documentation/devicetree/bindings/media/bcm2835-unicam.txt\n>> >> new file mode 100644\n>> >> index 0000000..7714fb3\n>> >> --- /dev/null\n>> >> +++ b/Documentation/devicetree/bindings/media/bcm2835-unicam.txt\n>> >> @@ -0,0 +1,85 @@\n>> >> +Broadcom BCM283x Camera Interface (Unicam)\n>> >> +------------------------------------------\n>> >> +\n>> >> +The Unicam block on BCM283x SoCs is the receiver for either\n>> >> +CSI-2 or CCP2 data from image sensors or similar devices.\n>> >> +\n>> >> +The main platform using this SoC is the Raspberry Pi family of boards.\n>> >> +On the Pi the VideoCore firmware can also control this hardware block,\n>> >> +and driving it from two different processors will cause issues.\n>> >> +To avoid this, the firmware checks the device tree configuration\n>> >> +during boot. If it finds device tree nodes called csi0 or csi1 then\n>> >> +it will stop the firmware accessing the block, and it can then\n>> >> +safely be used via the device tree binding.\n>> >> +\n>> >> +Required properties:\n>> >> +===================\n>> >> +- compatible : must be \"brcm,bcm2835-unicam\".\n>> >> +- reg : physical base address and length of the register sets for the\n>> >> + device.\n>> >> +- interrupts : should contain the IRQ line for this Unicam instance.\n>> >> +- clocks : list of clock specifiers, corresponding to entries in\n>> >> + clock-names property.\n>> >> +- clock-names : must contain an \"lp\" entry, matching entries in the\n>> >> + clocks property.\n>> >> +\n>> >> +Unicam supports a single port node. It should contain one 'port' child node\n>> >> +with child 'endpoint' node. Please refer to the bindings defined in\n>> >> +Documentation/devicetree/bindings/media/video-interfaces.txt.\n>> >> +\n>> >> +Within the endpoint node the \"remote-endpoint\" and \"data-lanes\" properties\n>> >> +are mandatory.\n>> >> +Data lane reordering is not supported so the data lanes must be in order,\n>> >> +starting at 1. The number of data lanes should represent the number of\n>> >> +usable lanes for the hardware block. That may be limited by either the SoC or\n>> >> +how the platform presents the interface, and the lower value must be used.\n>> >> +\n>> >> +Lane reordering is not supported on the clock lane either, so the optional\n>> >> +property \"clock-lane\" will implicitly be <0>.\n>> >> +Similarly lane inversion is not supported, therefore \"lane-polarities\" will\n>> >> +implicitly be <0 0 0 0 0>.\n>> >> +Neither of these values will be checked.\n>> >> +\n>> >> +Example:\n>> >> + csi1: csi1@7e801000 {\n>> >> + compatible = \"brcm,bcm2835-unicam\";\n>> >> + reg = <0x7e801000 0x800>,\n>> >> + <0x7e802004 0x4>;\n>> >\n>> > sorry, i didn't noticed this before. I'm afraid this is using a small range of the CMI. Are there possible other users of this range? Does it make sense to handle this by a separate clock driver?\n>>\n>> CMI (Clock Manager Image) consists of a total of 4 registers.\n>> 0x7e802000 is CMI_CAM0, with only bits 0-5 used for gating and\n>> inversion of the clock and data lanes (2 data lanes available on\n>> CAM0).\n>> 0x7e802004 is CMI_CAM1, with only bits 0-9 used for gating and\n>> inversion of the clock and data lanes (4 data lanes available on\n>> CAM1).\n>> 0x7e802008 is CMI_CAMTEST which I have no documentation or drivers for.\n>> 0x7e802010 is CMI_USBCTL. Only bit 6 is documented and is a reset. The\n>> default value is the required value. Nothing touches it that I can\n>> find.\n>>\n>> The range listed only covers the one register associated with that\n>> Unicam instance, so no other users. The other two aren't touched.\n>> Do 16 active register bits solely for camera clock gating really\n>> warrant a full clock driver?\n>\n> You should describe all the registers in DT, not just what the driver\n> (currently) uses.\n\nI'm not clear what you're asking for here.\n\nThis binding is for the Unicam block, not for CMI (Clock Manager\nImaging). In order for a Unicam instance to work, it needs to enable\nthe relevant clock gating via 1 CMI register, and it will only ever be\none register.\n\nEric and Stefan as the platform maintainers have already both\nacknowledged that a full clock driver for the CMI block is not\nwarranted - the only user would be this driver, and the other\nregisters in the CMI block are not useful.\n\nDo you want a random text description of a different block within this\nbinding? Or are you requesting a full clock driver for the CMI block?\nOr that all Unicam instances should be mapping the whole 4 register\nrange of CMI, and then somehow working out which register within that\nblock they should be mapping?\n\nRegards,\n Dave\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=)","ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tsecure) header.d=raspberrypi.org header.i=@raspberrypi.org\n\theader.b=\"xG3n4FkL\"; \n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=raspberrypi-org.20150623.gappssmtp.com\n\theader.i=@raspberrypi-org.20150623.gappssmtp.com header.b=\"iyuWLK7m\"; \n\tdkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3y5JVM4F5Tz9t4Z\n\tfor ;\n\tMon, 2 Oct 2017 21:36:11 +1100 (AEDT)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751019AbdJBKgJ (ORCPT\n\t);\n\tMon, 2 Oct 2017 06:36:09 -0400","from mx08-00252a01.pphosted.com ([91.207.212.211]:33512 \"EHLO\n\tmx08-00252a01.pphosted.com\" rhost-flags-OK-OK-OK-OK)\n\tby vger.kernel.org with ESMTP id S1750981AbdJBKgH (ORCPT\n\t); Mon, 2 Oct 2017 06:36:07 -0400","from pps.filterd (m0102629.ppops.net [127.0.0.1])\n\tby mx08-00252a01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id\n\tv92AYqpG020223\n\tfor ; Mon, 2 Oct 2017 11:36:06 +0100","from mail-pf0-f200.google.com (mail-pf0-f200.google.com\n\t[209.85.192.200])\n\tby mx08-00252a01.pphosted.com with ESMTP id 2d9yrf13a1-1\n\t(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128\n\tverify=OK)\n\tfor ; Mon, 02 Oct 2017 11:36:06 +0100","by mail-pf0-f200.google.com with SMTP id a7so11348988pfj.3\n\tfor ;\n\tMon, 02 Oct 2017 03:36:05 -0700 (PDT)","by 10.100.178.204 with HTTP; Mon, 2 Oct 2017 03:36:03 -0700 (PDT)"],"DKIM-Signature":["v=1; a=rsa-sha256; c=relaxed/relaxed; d=raspberrypi.org;\n\th=mime-version :\n\tin-reply-to : references : from : date : message-id : subject : to :\n\tcc :\n\tcontent-type; s=pp; bh=m8OF+G94WN/WY5sUxe6tMRBzlaMJAbfEAEt2DiwYMtA=; \n\tb=xG3n4FkLXV54EfCf7cTix9/JSp4QD8qXYA8jXC8b9i8qCD3Ly0ebYNNG4ZMtIT4yp2fT\n\tWbxSb+y1hj0n0yD26e/qFQ2f1W985JcwAczlfgLfeEgOV/Rs/EaDnTznwxdMjWA/abqV\n\ti2BTdvyYR6pilvDH2pGdcwWcEGponASLe3d2RSeZ9Y8808ashrQjDp/imcGk4oIn2JmK\n\tqhTSTOVukwpNYEaZr5sAzVNbfqHw8mCixCt+yXKlBACz5joSsliSFfgyTvw8sW6blXeV\n\tSe0HcmRBDiVtLyB93pCKJpH5p5vsfEZBGyK9cwFfROZzvR1KxamxuIPmEzCpnyAP7cug\n\tRQ== ","v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=raspberrypi-org.20150623.gappssmtp.com; s=20150623;\n\th=mime-version:in-reply-to:references:from:date:message-id:subject:to\n\t:cc; bh=m8OF+G94WN/WY5sUxe6tMRBzlaMJAbfEAEt2DiwYMtA=;\n\tb=iyuWLK7mUVLNxCgeOGm2iw2eBmbbMrW9uV+3f3GUT6ze+P+w+jfb9yWGxWPaKmrkAD\n\tQZwk/UiM5sSAepAxRgI844ulGd4W6JIBIzLvC50zUPiOm7X7j4S7N+5KO6HT+eTOd9hx\n\tm5C+nA8lTz0ns+omU63QtjO08DFiQ9HBNNBHgN4hDW+iRri4jeRr10162HuJMylbmCZp\n\tqTTD2GKyzQo/KinDGViOSMRl05a/+CcHwmG0rnPwg1wnlqAiOOWaZUxdOXIXtodQNKAA\n\t9pHqKNv/g+Oumwv8W/62zyOBC+chV7FGWtkrLI1XyQOq/YVMxSp0tUT2qn43tHxCB3tj\n\tzX5w=="],"X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:mime-version:in-reply-to:references:from:date\n\t:message-id:subject:to:cc;\n\tbh=m8OF+G94WN/WY5sUxe6tMRBzlaMJAbfEAEt2DiwYMtA=;\n\tb=JWeNNyGVEQiaKhLEDHFgGkDGROEDFW6n+Gfb1hnTyL+JxFVsEP0PzNDoiFAyrg0YrN\n\tCzQfZDPKo6YtX85Rw+wrHUgYE8n3Cj3LbE3Xh5XVhR2Oeqa/rQ+QnWNWafhGPOhJEAme\n\t3Zv0Uo1JgJB4Rq7X1/5dqzG95tLn9+3/CmS2OvOI4GEfsaeIJoIDqfKTz2/ebdrn7wjV\n\t/kdgtkFEuC7Y2QLVvMN2xFiq3w2BV2cZl/XQYFYU1yFG29P8RsxPHKBzebviygnF+d85\n\tPX8Pfoqv7+AstF+0FHAGqTCGfcQ4hyTVhUZgfUf7PCAVLhGM7XnaSWAKincMfCwfsOW1\n\tNAHg==","X-Gm-Message-State":"AHPjjUgkBUXZ9Bmk2KDWbkpN4M1nhFaArZOEGPD+x4+2S+pPvlm+DCE1\n\tfJCH66DzyF4JpNH/yaGoyTEqne9d+5xSmKFXqe70Sw7yqLiZroaMus7kp73bVVT34ZAv+l4qUDR\n\tXF1HUJ4ZQkOJ3/uXmho/cLPH1kjL+f6WY7e8I","X-Received":["by 10.159.229.136 with SMTP id az8mr13810999plb.79.1506940564104;\n\tMon, 02 Oct 2017 03:36:04 -0700 (PDT)","by 10.159.229.136 with SMTP id az8mr13810983plb.79.1506940563585;\n\tMon, 02 Oct 2017 03:36:03 -0700 (PDT)"],"X-Google-Smtp-Source":"AOwi7QAM2krUBgKF8A0AhWiMy2gmr1vvyMZQRFoD/Wf09/XMiCnbmCiQFDnoTBaz5ETnkzx/Yd/NCms5DSUQHgq1Bn8=","MIME-Version":"1.0","In-Reply-To":"<20170927215124.6k3j54qf2qscnzc2@rob-hp-laptop>","References":"\n\t\n\t<1814950930.414004.1506062733728@email.1und1.de>\n\t\n\t<20170927215124.6k3j54qf2qscnzc2@rob-hp-laptop>","From":"Dave Stevenson ","Date":"Mon, 2 Oct 2017 11:36:03 +0100","Message-ID":"","Subject":"Re: [PATCH v3 2/4] [media] dt-bindings: Document BCM283x CSI2/CCP2\n\treceiver","To":"Rob Herring ","Cc":"Stefan Wahren ,\n\tMauro Carvalho Chehab ,\n\tEric Anholt , linux-media@vger.kernel.org,\n\tSakari Ailus ,\n\tHans Verkuil , \n\tlinux-rpi-kernel@lists.infradead.org, devicetree@vger.kernel.org","Content-Type":"text/plain; charset=\"UTF-8\"","X-Proofpoint-Virus-Version":"vendor=fsecure engine=2.50.10432:, ,\n\tdefinitions=2017-10-02_03:, , signatures=0","X-Proofpoint-Spam-Details":"rule=outbound_spam_notspam policy=outbound_spam\n\tscore=0 priorityscore=1501\n\tmalwarescore=0 suspectscore=1 phishscore=0 bulkscore=0 spamscore=0\n\tclxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0\n\tclassifier=spam adjust=0 reason=mlx scancount=1\n\tengine=8.0.1-1707230000\n\tdefinitions=main-1710020153","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1808343,"web_url":"http://patchwork.ozlabs.org/comment/1808343/","msgid":"<877euje8mc.fsf@anholt.net>","list_archive_url":null,"date":"2017-11-21T19:26:19","subject":"Re: [PATCH v3 2/4] [media] dt-bindings: Document BCM283x CSI2/CCP2\n\treceiver","submitter":{"id":608,"url":"http://patchwork.ozlabs.org/api/people/608/","name":"Eric Anholt","email":"eric@anholt.net"},"content":"Dave Stevenson writes:\n\n> Hi Rob\n>\n> On 27 September 2017 at 22:51, Rob Herring wrote:\n>> On Fri, Sep 22, 2017 at 05:07:22PM +0100, Dave Stevenson wrote:\n>>> Hi Stefan\n>>>\n>>> On 22 September 2017 at 07:45, Stefan Wahren wrote:\n>>> > Hi Dave,\n>>> >\n>>> >> Dave Stevenson hat am 20. September 2017 um 18:07 geschrieben:\n>>> >>\n>>> >>\n>>> >> Document the DT bindings for the CSI2/CCP2 receiver peripheral\n>>> >> (known as Unicam) on BCM283x SoCs.\n>>> >>\n>>> >> Signed-off-by: Dave Stevenson \n>>> >> ---\n>>> >>\n>>> >> Changes since v2\n>>> >> - Removed all references to Linux drivers.\n>>> >> - Reworded section about disabling the firmware driver.\n>>> >> - Renamed clock from \"lp_clock\" to \"lp\" in description and example.\n>>> >> - Referred to video-interfaces.txt and stated requirements on remote-endpoint\n>>> >> and data-lanes.\n>>> >> - Corrected typo in example from csi to csi1.\n>>> >> - Removed unnecessary #address-cells and #size-cells in example.\n>>> >> - Removed setting of status from the example.\n>>> >>\n>>> >> .../devicetree/bindings/media/bcm2835-unicam.txt | 85 ++++++++++++++++++++++\n>>> >> 1 file changed, 85 insertions(+)\n>>> >> create mode 100644 Documentation/devicetree/bindings/media/bcm2835-unicam.txt\n>>> >>\n>>> >> diff --git a/Documentation/devicetree/bindings/media/bcm2835-unicam.txt b/Documentation/devicetree/bindings/media/bcm2835-unicam.txt\n>>> >> new file mode 100644\n>>> >> index 0000000..7714fb3\n>>> >> --- /dev/null\n>>> >> +++ b/Documentation/devicetree/bindings/media/bcm2835-unicam.txt\n>>> >> @@ -0,0 +1,85 @@\n>>> >> +Broadcom BCM283x Camera Interface (Unicam)\n>>> >> +------------------------------------------\n>>> >> +\n>>> >> +The Unicam block on BCM283x SoCs is the receiver for either\n>>> >> +CSI-2 or CCP2 data from image sensors or similar devices.\n>>> >> +\n>>> >> +The main platform using this SoC is the Raspberry Pi family of boards.\n>>> >> +On the Pi the VideoCore firmware can also control this hardware block,\n>>> >> +and driving it from two different processors will cause issues.\n>>> >> +To avoid this, the firmware checks the device tree configuration\n>>> >> +during boot. If it finds device tree nodes called csi0 or csi1 then\n>>> >> +it will stop the firmware accessing the block, and it can then\n>>> >> +safely be used via the device tree binding.\n>>> >> +\n>>> >> +Required properties:\n>>> >> +===================\n>>> >> +- compatible : must be \"brcm,bcm2835-unicam\".\n>>> >> +- reg : physical base address and length of the register sets for the\n>>> >> + device.\n>>> >> +- interrupts : should contain the IRQ line for this Unicam instance.\n>>> >> +- clocks : list of clock specifiers, corresponding to entries in\n>>> >> + clock-names property.\n>>> >> +- clock-names : must contain an \"lp\" entry, matching entries in the\n>>> >> + clocks property.\n>>> >> +\n>>> >> +Unicam supports a single port node. It should contain one 'port' child node\n>>> >> +with child 'endpoint' node. Please refer to the bindings defined in\n>>> >> +Documentation/devicetree/bindings/media/video-interfaces.txt.\n>>> >> +\n>>> >> +Within the endpoint node the \"remote-endpoint\" and \"data-lanes\" properties\n>>> >> +are mandatory.\n>>> >> +Data lane reordering is not supported so the data lanes must be in order,\n>>> >> +starting at 1. The number of data lanes should represent the number of\n>>> >> +usable lanes for the hardware block. That may be limited by either the SoC or\n>>> >> +how the platform presents the interface, and the lower value must be used.\n>>> >> +\n>>> >> +Lane reordering is not supported on the clock lane either, so the optional\n>>> >> +property \"clock-lane\" will implicitly be <0>.\n>>> >> +Similarly lane inversion is not supported, therefore \"lane-polarities\" will\n>>> >> +implicitly be <0 0 0 0 0>.\n>>> >> +Neither of these values will be checked.\n>>> >> +\n>>> >> +Example:\n>>> >> + csi1: csi1@7e801000 {\n>>> >> + compatible = \"brcm,bcm2835-unicam\";\n>>> >> + reg = <0x7e801000 0x800>,\n>>> >> + <0x7e802004 0x4>;\n>>> >\n>>> > sorry, i didn't noticed this before. I'm afraid this is using a small range of the CMI. Are there possible other users of this range? Does it make sense to handle this by a separate clock driver?\n>>>\n>>> CMI (Clock Manager Image) consists of a total of 4 registers.\n>>> 0x7e802000 is CMI_CAM0, with only bits 0-5 used for gating and\n>>> inversion of the clock and data lanes (2 data lanes available on\n>>> CAM0).\n>>> 0x7e802004 is CMI_CAM1, with only bits 0-9 used for gating and\n>>> inversion of the clock and data lanes (4 data lanes available on\n>>> CAM1).\n>>> 0x7e802008 is CMI_CAMTEST which I have no documentation or drivers for.\n>>> 0x7e802010 is CMI_USBCTL. Only bit 6 is documented and is a reset. The\n>>> default value is the required value. Nothing touches it that I can\n>>> find.\n>>>\n>>> The range listed only covers the one register associated with that\n>>> Unicam instance, so no other users. The other two aren't touched.\n>>> Do 16 active register bits solely for camera clock gating really\n>>> warrant a full clock driver?\n>>\n>> You should describe all the registers in DT, not just what the driver\n>> (currently) uses.\n>\n> I'm not clear what you're asking for here.\n>\n> This binding is for the Unicam block, not for CMI (Clock Manager\n> Imaging). In order for a Unicam instance to work, it needs to enable\n> the relevant clock gating via 1 CMI register, and it will only ever be\n> one register.\n\nRob, the CMI just a small bit of glue required by the crossing of a\npower domain in a unicam instance, and the two unicam instances in this\nHW have their CMI regs next to each other. It's not really a separate\nblock, and I think describing the unicam's CMI reg in the unicam binding\nis appropriate.\n\nWhat would you need from Dave to ack this binding?","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 3yhFv603X2z9sRm\n\tfor ;\n\tWed, 22 Nov 2017 06:26:26 +1100 (AEDT)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751317AbdKUT0Y (ORCPT\n\t);\n\tTue, 21 Nov 2017 14:26:24 -0500","from anholt.net ([50.246.234.109]:45890 \"EHLO anholt.net\"\n\trhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S1751154AbdKUT0X (ORCPT );\n\tTue, 21 Nov 2017 14:26:23 -0500","from localhost (localhost [127.0.0.1])\n\tby anholt.net (Postfix) with ESMTP id 947F910A13BD;\n\tTue, 21 Nov 2017 11:26:22 -0800 (PST)","from anholt.net ([127.0.0.1])\n\tby localhost (kingsolver.anholt.net [127.0.0.1]) (amavisd-new,\n\tport 10024)\n\twith LMTP id V0nIN2xuy4X1; Tue, 21 Nov 2017 11:26:20 -0800 (PST)","from eliezer.anholt.net (localhost [127.0.0.1])\n\tby anholt.net (Postfix) with ESMTP id AD16F10A0077;\n\tTue, 21 Nov 2017 11:26:20 -0800 (PST)","by eliezer.anholt.net (Postfix, from userid 1000)\n\tid F0C622FE5C64; Tue, 21 Nov 2017 11:26:19 -0800 (PST)"],"X-Virus-Scanned":"Debian amavisd-new at anholt.net","From":"Eric Anholt ","To":"Dave Stevenson ,\n\tRob Herring ","Cc":"Stefan Wahren ,\n\tMauro Carvalho Chehab ,\n\tlinux-media@vger.kernel.org, Sakari Ailus ,\n\tHans Verkuil ,\n\tlinux-rpi-kernel@lists.infradead.org, devicetree@vger.kernel.org","Subject":"Re: [PATCH v3 2/4] [media] dt-bindings: Document BCM283x CSI2/CCP2\n\treceiver","In-Reply-To":"","References":"\n\t\n\t<1814950930.414004.1506062733728@email.1und1.de>\n\t\n\t<20170927215124.6k3j54qf2qscnzc2@rob-hp-laptop>\n\t","User-Agent":"Notmuch/0.22.2+1~gb0bcfaa (http://notmuchmail.org) Emacs/25.2.2\n\t(x86_64-pc-linux-gnu)","Date":"Tue, 21 Nov 2017 11:26:19 -0800","Message-ID":"<877euje8mc.fsf@anholt.net>","MIME-Version":"1.0","Content-Type":"multipart/signed; boundary=\"=-=-=\";\n\tmicalg=pgp-sha512; protocol=\"application/pgp-signature\"","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1808355,"web_url":"http://patchwork.ozlabs.org/comment/1808355/","msgid":"","list_archive_url":null,"date":"2017-11-21T19:58:27","subject":"Re: [PATCH v3 2/4] [media] dt-bindings: Document BCM283x CSI2/CCP2\n\treceiver","submitter":{"id":62529,"url":"http://patchwork.ozlabs.org/api/people/62529/","name":"Rob Herring (Arm)","email":"robh@kernel.org"},"content":"On Tue, Nov 21, 2017 at 1:26 PM, Eric Anholt wrote:\n> Dave Stevenson writes:\n>\n>> Hi Rob\n>>\n>> On 27 September 2017 at 22:51, Rob Herring wrote:\n>>> On Fri, Sep 22, 2017 at 05:07:22PM +0100, Dave Stevenson wrote:\n>>>> Hi Stefan\n>>>>\n>>>> On 22 September 2017 at 07:45, Stefan Wahren wrote:\n>>>> > Hi Dave,\n>>>> >\n>>>> >> Dave Stevenson hat am 20. September 2017 um 18:07 geschrieben:\n>>>> >>\n>>>> >>\n>>>> >> Document the DT bindings for the CSI2/CCP2 receiver peripheral\n>>>> >> (known as Unicam) on BCM283x SoCs.\n>>>> >>\n>>>> >> Signed-off-by: Dave Stevenson \n>>>> >> ---\n>>>> >>\n>>>> >> Changes since v2\n>>>> >> - Removed all references to Linux drivers.\n>>>> >> - Reworded section about disabling the firmware driver.\n>>>> >> - Renamed clock from \"lp_clock\" to \"lp\" in description and example.\n>>>> >> - Referred to video-interfaces.txt and stated requirements on remote-endpoint\n>>>> >> and data-lanes.\n>>>> >> - Corrected typo in example from csi to csi1.\n>>>> >> - Removed unnecessary #address-cells and #size-cells in example.\n>>>> >> - Removed setting of status from the example.\n>>>> >>\n>>>> >> .../devicetree/bindings/media/bcm2835-unicam.txt | 85 ++++++++++++++++++++++\n>>>> >> 1 file changed, 85 insertions(+)\n>>>> >> create mode 100644 Documentation/devicetree/bindings/media/bcm2835-unicam.txt\n>>>> >>\n>>>> >> diff --git a/Documentation/devicetree/bindings/media/bcm2835-unicam.txt b/Documentation/devicetree/bindings/media/bcm2835-unicam.txt\n>>>> >> new file mode 100644\n>>>> >> index 0000000..7714fb3\n>>>> >> --- /dev/null\n>>>> >> +++ b/Documentation/devicetree/bindings/media/bcm2835-unicam.txt\n>>>> >> @@ -0,0 +1,85 @@\n>>>> >> +Broadcom BCM283x Camera Interface (Unicam)\n>>>> >> +------------------------------------------\n>>>> >> +\n>>>> >> +The Unicam block on BCM283x SoCs is the receiver for either\n>>>> >> +CSI-2 or CCP2 data from image sensors or similar devices.\n>>>> >> +\n>>>> >> +The main platform using this SoC is the Raspberry Pi family of boards.\n>>>> >> +On the Pi the VideoCore firmware can also control this hardware block,\n>>>> >> +and driving it from two different processors will cause issues.\n>>>> >> +To avoid this, the firmware checks the device tree configuration\n>>>> >> +during boot. If it finds device tree nodes called csi0 or csi1 then\n>>>> >> +it will stop the firmware accessing the block, and it can then\n>>>> >> +safely be used via the device tree binding.\n>>>> >> +\n>>>> >> +Required properties:\n>>>> >> +===================\n>>>> >> +- compatible : must be \"brcm,bcm2835-unicam\".\n>>>> >> +- reg : physical base address and length of the register sets for the\n>>>> >> + device.\n>>>> >> +- interrupts : should contain the IRQ line for this Unicam instance.\n>>>> >> +- clocks : list of clock specifiers, corresponding to entries in\n>>>> >> + clock-names property.\n>>>> >> +- clock-names : must contain an \"lp\" entry, matching entries in the\n>>>> >> + clocks property.\n>>>> >> +\n>>>> >> +Unicam supports a single port node. It should contain one 'port' child node\n>>>> >> +with child 'endpoint' node. Please refer to the bindings defined in\n>>>> >> +Documentation/devicetree/bindings/media/video-interfaces.txt.\n>>>> >> +\n>>>> >> +Within the endpoint node the \"remote-endpoint\" and \"data-lanes\" properties\n>>>> >> +are mandatory.\n>>>> >> +Data lane reordering is not supported so the data lanes must be in order,\n>>>> >> +starting at 1. The number of data lanes should represent the number of\n>>>> >> +usable lanes for the hardware block. That may be limited by either the SoC or\n>>>> >> +how the platform presents the interface, and the lower value must be used.\n>>>> >> +\n>>>> >> +Lane reordering is not supported on the clock lane either, so the optional\n>>>> >> +property \"clock-lane\" will implicitly be <0>.\n>>>> >> +Similarly lane inversion is not supported, therefore \"lane-polarities\" will\n>>>> >> +implicitly be <0 0 0 0 0>.\n>>>> >> +Neither of these values will be checked.\n>>>> >> +\n>>>> >> +Example:\n>>>> >> + csi1: csi1@7e801000 {\n>>>> >> + compatible = \"brcm,bcm2835-unicam\";\n>>>> >> + reg = <0x7e801000 0x800>,\n>>>> >> + <0x7e802004 0x4>;\n>>>> >\n>>>> > sorry, i didn't noticed this before. I'm afraid this is using a small range of the CMI. Are there possible other users of this range? Does it make sense to handle this by a separate clock driver?\n>>>>\n>>>> CMI (Clock Manager Image) consists of a total of 4 registers.\n>>>> 0x7e802000 is CMI_CAM0, with only bits 0-5 used for gating and\n>>>> inversion of the clock and data lanes (2 data lanes available on\n>>>> CAM0).\n>>>> 0x7e802004 is CMI_CAM1, with only bits 0-9 used for gating and\n>>>> inversion of the clock and data lanes (4 data lanes available on\n>>>> CAM1).\n>>>> 0x7e802008 is CMI_CAMTEST which I have no documentation or drivers for.\n>>>> 0x7e802010 is CMI_USBCTL. Only bit 6 is documented and is a reset. The\n>>>> default value is the required value. Nothing touches it that I can\n>>>> find.\n>>>>\n>>>> The range listed only covers the one register associated with that\n>>>> Unicam instance, so no other users. The other two aren't touched.\n>>>> Do 16 active register bits solely for camera clock gating really\n>>>> warrant a full clock driver?\n>>>\n>>> You should describe all the registers in DT, not just what the driver\n>>> (currently) uses.\n>>\n>> I'm not clear what you're asking for here.\n>>\n>> This binding is for the Unicam block, not for CMI (Clock Manager\n>> Imaging). In order for a Unicam instance to work, it needs to enable\n>> the relevant clock gating via 1 CMI register, and it will only ever be\n>> one register.\n>\n> Rob, the CMI just a small bit of glue required by the crossing of a\n> power domain in a unicam instance, and the two unicam instances in this\n> HW have their CMI regs next to each other. It's not really a separate\n> block, and I think describing the unicam's CMI reg in the unicam binding\n> is appropriate.\n>\n> What would you need from Dave to ack this binding?\n\nSorry, had started to reply on this and got distracted.\n\nI guess since there seems to be only 1 other bit that could possibly\nbe used (CMI_USBCTL) it is fine like this. However, my concern would\nbe if the CMI registers are integrated in a different way in some\nfuture chip that has the same unicam instances. Or just if the\nregister bits are rearranged. Those are not an uncommon occurrence.\nYou would have to provide access to those registers in some other way.\nIt can be dealt with, but then you have to support both cases in the\ndriver. If you all are fine with that, then:\n\nAcked-by: Rob Herring \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=)","mail.kernel.org;\n\tdmarc=none (p=none dis=none) header.from=kernel.org","mail.kernel.org;\n\tspf=none smtp.mailfrom=robh@kernel.org"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3yhGcZ0n53z9sRn\n\tfor ;\n\tWed, 22 Nov 2017 06:58:54 +1100 (AEDT)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751337AbdKUT6v (ORCPT\n\t);\n\tTue, 21 Nov 2017 14:58:51 -0500","from mail.kernel.org ([198.145.29.99]:42238 \"EHLO mail.kernel.org\"\n\trhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S1751067AbdKUT6t (ORCPT );\n\tTue, 21 Nov 2017 14:58:49 -0500","from mail-qt0-f170.google.com (mail-qt0-f170.google.com\n\t[209.85.216.170])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128\n\tbits)) (No client certificate requested)\n\tby mail.kernel.org (Postfix) with ESMTPSA id 1362721986;\n\tTue, 21 Nov 2017 19:58:49 +0000 (UTC)","by mail-qt0-f170.google.com with SMTP id w10so8870374qtb.10;\n\tTue, 21 Nov 2017 11:58:49 -0800 (PST)","by 10.12.194.73 with HTTP; Tue, 21 Nov 2017 11:58:27 -0800 (PST)"],"DMARC-Filter":"OpenDMARC Filter v1.3.2 mail.kernel.org 1362721986","X-Gm-Message-State":"AJaThX6GVKFvxlhU6s0JN5HDQV2auOk0QxuPq18FQyMpS6FLc9LKy8Y7\n\tZdosiOoWJJ6r0lxqGH6SxVKf5Z7LTm5HDlqZKA==","X-Google-Smtp-Source":"AGs4zMZ5D+hXUPwFwneibUxUhIotuXUoPr/F6UGAyPib7y0CIILNrOdRMVosPrUBBzyR6uV3jZqXiuqCn2T++0p3Uk0=","X-Received":"by 10.237.42.22 with SMTP id c22mr27737528qtd.162.1511294328216; \n\tTue, 21 Nov 2017 11:58:48 -0800 (PST)","MIME-Version":"1.0","In-Reply-To":"<877euje8mc.fsf@anholt.net>","References":"\n\t\n\t<1814950930.414004.1506062733728@email.1und1.de>\n\t\n\t<20170927215124.6k3j54qf2qscnzc2@rob-hp-laptop>\n\t\n\t<877euje8mc.fsf@anholt.net>","From":"Rob Herring ","Date":"Tue, 21 Nov 2017 13:58:27 -0600","X-Gmail-Original-Message-ID":"","Message-ID":"","Subject":"Re: [PATCH v3 2/4] [media] dt-bindings: Document BCM283x CSI2/CCP2\n\treceiver","To":"Eric Anholt ","Cc":"Dave Stevenson ,\n\tStefan Wahren ,\n\tMauro Carvalho Chehab ,\n\t\"linux-media@vger.kernel.org\" ,\n\tSakari Ailus ,\n\tHans Verkuil , \n\t\"moderated list:BROADCOM BCM2835 ARM ARCHITECTURE\" \n\t,\n\t\"devicetree@vger.kernel.org\" ","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":1808381,"web_url":"http://patchwork.ozlabs.org/comment/1808381/","msgid":"<87bmjvcpyv.fsf@anholt.net>","list_archive_url":null,"date":"2017-11-21T20:54:32","subject":"Re: [PATCH v3 2/4] [media] dt-bindings: Document BCM283x CSI2/CCP2\n\treceiver","submitter":{"id":608,"url":"http://patchwork.ozlabs.org/api/people/608/","name":"Eric Anholt","email":"eric@anholt.net"},"content":"Rob Herring writes:\n\n> On Tue, Nov 21, 2017 at 1:26 PM, Eric Anholt wrote:\n>> Dave Stevenson writes:\n>>\n>>> Hi Rob\n>>>\n>>> On 27 September 2017 at 22:51, Rob Herring wrote:\n>>>> On Fri, Sep 22, 2017 at 05:07:22PM +0100, Dave Stevenson wrote:\n>>>>> Hi Stefan\n>>>>>\n>>>>> On 22 September 2017 at 07:45, Stefan Wahren wrote:\n>>>>> > Hi Dave,\n>>>>> >\n>>>>> >> Dave Stevenson hat am 20. September 2017 um 18:07 geschrieben:\n>>>>> >>\n>>>>> >>\n>>>>> >> Document the DT bindings for the CSI2/CCP2 receiver peripheral\n>>>>> >> (known as Unicam) on BCM283x SoCs.\n>>>>> >>\n>>>>> >> Signed-off-by: Dave Stevenson \n>>>>> >> ---\n>>>>> >>\n>>>>> >> Changes since v2\n>>>>> >> - Removed all references to Linux drivers.\n>>>>> >> - Reworded section about disabling the firmware driver.\n>>>>> >> - Renamed clock from \"lp_clock\" to \"lp\" in description and example.\n>>>>> >> - Referred to video-interfaces.txt and stated requirements on remote-endpoint\n>>>>> >> and data-lanes.\n>>>>> >> - Corrected typo in example from csi to csi1.\n>>>>> >> - Removed unnecessary #address-cells and #size-cells in example.\n>>>>> >> - Removed setting of status from the example.\n>>>>> >>\n>>>>> >> .../devicetree/bindings/media/bcm2835-unicam.txt | 85 ++++++++++++++++++++++\n>>>>> >> 1 file changed, 85 insertions(+)\n>>>>> >> create mode 100644 Documentation/devicetree/bindings/media/bcm2835-unicam.txt\n>>>>> >>\n>>>>> >> diff --git a/Documentation/devicetree/bindings/media/bcm2835-unicam.txt b/Documentation/devicetree/bindings/media/bcm2835-unicam.txt\n>>>>> >> new file mode 100644\n>>>>> >> index 0000000..7714fb3\n>>>>> >> --- /dev/null\n>>>>> >> +++ b/Documentation/devicetree/bindings/media/bcm2835-unicam.txt\n>>>>> >> @@ -0,0 +1,85 @@\n>>>>> >> +Broadcom BCM283x Camera Interface (Unicam)\n>>>>> >> +------------------------------------------\n>>>>> >> +\n>>>>> >> +The Unicam block on BCM283x SoCs is the receiver for either\n>>>>> >> +CSI-2 or CCP2 data from image sensors or similar devices.\n>>>>> >> +\n>>>>> >> +The main platform using this SoC is the Raspberry Pi family of boards.\n>>>>> >> +On the Pi the VideoCore firmware can also control this hardware block,\n>>>>> >> +and driving it from two different processors will cause issues.\n>>>>> >> +To avoid this, the firmware checks the device tree configuration\n>>>>> >> +during boot. If it finds device tree nodes called csi0 or csi1 then\n>>>>> >> +it will stop the firmware accessing the block, and it can then\n>>>>> >> +safely be used via the device tree binding.\n>>>>> >> +\n>>>>> >> +Required properties:\n>>>>> >> +===================\n>>>>> >> +- compatible : must be \"brcm,bcm2835-unicam\".\n>>>>> >> +- reg : physical base address and length of the register sets for the\n>>>>> >> + device.\n>>>>> >> +- interrupts : should contain the IRQ line for this Unicam instance.\n>>>>> >> +- clocks : list of clock specifiers, corresponding to entries in\n>>>>> >> + clock-names property.\n>>>>> >> +- clock-names : must contain an \"lp\" entry, matching entries in the\n>>>>> >> + clocks property.\n>>>>> >> +\n>>>>> >> +Unicam supports a single port node. It should contain one 'port' child node\n>>>>> >> +with child 'endpoint' node. Please refer to the bindings defined in\n>>>>> >> +Documentation/devicetree/bindings/media/video-interfaces.txt.\n>>>>> >> +\n>>>>> >> +Within the endpoint node the \"remote-endpoint\" and \"data-lanes\" properties\n>>>>> >> +are mandatory.\n>>>>> >> +Data lane reordering is not supported so the data lanes must be in order,\n>>>>> >> +starting at 1. The number of data lanes should represent the number of\n>>>>> >> +usable lanes for the hardware block. That may be limited by either the SoC or\n>>>>> >> +how the platform presents the interface, and the lower value must be used.\n>>>>> >> +\n>>>>> >> +Lane reordering is not supported on the clock lane either, so the optional\n>>>>> >> +property \"clock-lane\" will implicitly be <0>.\n>>>>> >> +Similarly lane inversion is not supported, therefore \"lane-polarities\" will\n>>>>> >> +implicitly be <0 0 0 0 0>.\n>>>>> >> +Neither of these values will be checked.\n>>>>> >> +\n>>>>> >> +Example:\n>>>>> >> + csi1: csi1@7e801000 {\n>>>>> >> + compatible = \"brcm,bcm2835-unicam\";\n>>>>> >> + reg = <0x7e801000 0x800>,\n>>>>> >> + <0x7e802004 0x4>;\n>>>>> >\n>>>>> > sorry, i didn't noticed this before. I'm afraid this is using a small range of the CMI. Are there possible other users of this range? Does it make sense to handle this by a separate clock driver?\n>>>>>\n>>>>> CMI (Clock Manager Image) consists of a total of 4 registers.\n>>>>> 0x7e802000 is CMI_CAM0, with only bits 0-5 used for gating and\n>>>>> inversion of the clock and data lanes (2 data lanes available on\n>>>>> CAM0).\n>>>>> 0x7e802004 is CMI_CAM1, with only bits 0-9 used for gating and\n>>>>> inversion of the clock and data lanes (4 data lanes available on\n>>>>> CAM1).\n>>>>> 0x7e802008 is CMI_CAMTEST which I have no documentation or drivers for.\n>>>>> 0x7e802010 is CMI_USBCTL. Only bit 6 is documented and is a reset. The\n>>>>> default value is the required value. Nothing touches it that I can\n>>>>> find.\n>>>>>\n>>>>> The range listed only covers the one register associated with that\n>>>>> Unicam instance, so no other users. The other two aren't touched.\n>>>>> Do 16 active register bits solely for camera clock gating really\n>>>>> warrant a full clock driver?\n>>>>\n>>>> You should describe all the registers in DT, not just what the driver\n>>>> (currently) uses.\n>>>\n>>> I'm not clear what you're asking for here.\n>>>\n>>> This binding is for the Unicam block, not for CMI (Clock Manager\n>>> Imaging). In order for a Unicam instance to work, it needs to enable\n>>> the relevant clock gating via 1 CMI register, and it will only ever be\n>>> one register.\n>>\n>> Rob, the CMI just a small bit of glue required by the crossing of a\n>> power domain in a unicam instance, and the two unicam instances in this\n>> HW have their CMI regs next to each other. It's not really a separate\n>> block, and I think describing the unicam's CMI reg in the unicam binding\n>> is appropriate.\n>>\n>> What would you need from Dave to ack this binding?\n>\n> Sorry, had started to reply on this and got distracted.\n>\n> I guess since there seems to be only 1 other bit that could possibly\n> be used (CMI_USBCTL) it is fine like this. However, my concern would\n> be if the CMI registers are integrated in a different way in some\n> future chip that has the same unicam instances. Or just if the\n> register bits are rearranged. Those are not an uncommon occurrence.\n> You would have to provide access to those registers in some other way.\n> It can be dealt with, but then you have to support both cases in the\n> driver. If you all are fine with that, then:\n\nThe bigisland chips match bcm2835. For capri the lane enables are\nshifted down by two and the clock is up at bit 20. That would be\ntrivial to handle based on the compatible string, except that we can't\ntalk to capri's hardware from ARM anyway :(","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 3yhHrw0FcMz9t2f\n\tfor ;\n\tWed, 22 Nov 2017 07:54:40 +1100 (AEDT)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751263AbdKUUyi (ORCPT\n\t);\n\tTue, 21 Nov 2017 15:54:38 -0500","from anholt.net ([50.246.234.109]:46618 \"EHLO anholt.net\"\n\trhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S1751067AbdKUUyh (ORCPT );\n\tTue, 21 Nov 2017 15:54:37 -0500","from localhost (localhost [127.0.0.1])\n\tby anholt.net (Postfix) with ESMTP id E725610A135F;\n\tTue, 21 Nov 2017 12:54:36 -0800 (PST)","from anholt.net ([127.0.0.1])\n\tby localhost (kingsolver.anholt.net [127.0.0.1]) (amavisd-new,\n\tport 10024)\n\twith LMTP id yC88BiNa83If; Tue, 21 Nov 2017 12:54:35 -0800 (PST)","from eliezer.anholt.net (localhost [127.0.0.1])\n\tby anholt.net (Postfix) with ESMTP id D5B4A10A0077;\n\tTue, 21 Nov 2017 12:54:34 -0800 (PST)","by eliezer.anholt.net (Postfix, from userid 1000)\n\tid CF1522FE5C65; Tue, 21 Nov 2017 12:54:32 -0800 (PST)"],"X-Virus-Scanned":"Debian amavisd-new at anholt.net","From":"Eric Anholt ","To":"Rob Herring ","Cc":"Dave Stevenson ,\n\tStefan Wahren ,\n\tMauro Carvalho Chehab ,\n\t\"linux-media\\@vger.kernel.org\" ,\n\tSakari Ailus ,\n\tHans Verkuil , \n\t\"moderated list\\:BROADCOM BCM2835 ARM ARCHITECTURE\" \n\t,\n\t\"devicetree\\@vger.kernel.org\" ","Subject":"Re: [PATCH v3 2/4] [media] dt-bindings: Document BCM283x CSI2/CCP2\n\treceiver","In-Reply-To":"","References":"\n\t\n\t<1814950930.414004.1506062733728@email.1und1.de>\n\t\n\t<20170927215124.6k3j54qf2qscnzc2@rob-hp-laptop>\n\t\n\t<877euje8mc.fsf@anholt.net>\n\t","User-Agent":"Notmuch/0.22.2+1~gb0bcfaa (http://notmuchmail.org) Emacs/25.2.2\n\t(x86_64-pc-linux-gnu)","Date":"Tue, 21 Nov 2017 12:54:32 -0800","Message-ID":"<87bmjvcpyv.fsf@anholt.net>","MIME-Version":"1.0","Content-Type":"multipart/signed; boundary=\"=-=-=\";\n\tmicalg=pgp-sha512; protocol=\"application/pgp-signature\"","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}},{"id":1808823,"web_url":"http://patchwork.ozlabs.org/comment/1808823/","msgid":"","list_archive_url":null,"date":"2017-11-22T16:39:21","subject":"Re: [PATCH v3 2/4] [media] dt-bindings: Document BCM283x CSI2/CCP2\n\treceiver","submitter":{"id":72357,"url":"http://patchwork.ozlabs.org/api/people/72357/","name":"Dave Stevenson","email":"dave.stevenson@raspberrypi.org"},"content":"On 21 November 2017 at 20:54, Eric Anholt wrote:\n> Rob Herring writes:\n>\n>> On Tue, Nov 21, 2017 at 1:26 PM, Eric Anholt wrote:\n>>> Dave Stevenson writes:\n>>>\n>>>> Hi Rob\n>>>>\n>>>> On 27 September 2017 at 22:51, Rob Herring wrote:\n>>>>> On Fri, Sep 22, 2017 at 05:07:22PM +0100, Dave Stevenson wrote:\n>>>>>> Hi Stefan\n>>>>>>\n>>>>>> On 22 September 2017 at 07:45, Stefan Wahren wrote:\n>>>>>> > Hi Dave,\n>>>>>> >\n>>>>>> >> Dave Stevenson hat am 20. September 2017 um 18:07 geschrieben:\n>>>>>> >>\n>>>>>> >>\n>>>>>> >> Document the DT bindings for the CSI2/CCP2 receiver peripheral\n>>>>>> >> (known as Unicam) on BCM283x SoCs.\n>>>>>> >>\n>>>>>> >> Signed-off-by: Dave Stevenson \n>>>>>> >> ---\n>>>>>> >>\n>>>>>> >> Changes since v2\n>>>>>> >> - Removed all references to Linux drivers.\n>>>>>> >> - Reworded section about disabling the firmware driver.\n>>>>>> >> - Renamed clock from \"lp_clock\" to \"lp\" in description and example.\n>>>>>> >> - Referred to video-interfaces.txt and stated requirements on remote-endpoint\n>>>>>> >> and data-lanes.\n>>>>>> >> - Corrected typo in example from csi to csi1.\n>>>>>> >> - Removed unnecessary #address-cells and #size-cells in example.\n>>>>>> >> - Removed setting of status from the example.\n>>>>>> >>\n>>>>>> >> .../devicetree/bindings/media/bcm2835-unicam.txt | 85 ++++++++++++++++++++++\n>>>>>> >> 1 file changed, 85 insertions(+)\n>>>>>> >> create mode 100644 Documentation/devicetree/bindings/media/bcm2835-unicam.txt\n>>>>>> >>\n>>>>>> >> diff --git a/Documentation/devicetree/bindings/media/bcm2835-unicam.txt b/Documentation/devicetree/bindings/media/bcm2835-unicam.txt\n>>>>>> >> new file mode 100644\n>>>>>> >> index 0000000..7714fb3\n>>>>>> >> --- /dev/null\n>>>>>> >> +++ b/Documentation/devicetree/bindings/media/bcm2835-unicam.txt\n>>>>>> >> @@ -0,0 +1,85 @@\n>>>>>> >> +Broadcom BCM283x Camera Interface (Unicam)\n>>>>>> >> +------------------------------------------\n>>>>>> >> +\n>>>>>> >> +The Unicam block on BCM283x SoCs is the receiver for either\n>>>>>> >> +CSI-2 or CCP2 data from image sensors or similar devices.\n>>>>>> >> +\n>>>>>> >> +The main platform using this SoC is the Raspberry Pi family of boards.\n>>>>>> >> +On the Pi the VideoCore firmware can also control this hardware block,\n>>>>>> >> +and driving it from two different processors will cause issues.\n>>>>>> >> +To avoid this, the firmware checks the device tree configuration\n>>>>>> >> +during boot. If it finds device tree nodes called csi0 or csi1 then\n>>>>>> >> +it will stop the firmware accessing the block, and it can then\n>>>>>> >> +safely be used via the device tree binding.\n>>>>>> >> +\n>>>>>> >> +Required properties:\n>>>>>> >> +===================\n>>>>>> >> +- compatible : must be \"brcm,bcm2835-unicam\".\n>>>>>> >> +- reg : physical base address and length of the register sets for the\n>>>>>> >> + device.\n>>>>>> >> +- interrupts : should contain the IRQ line for this Unicam instance.\n>>>>>> >> +- clocks : list of clock specifiers, corresponding to entries in\n>>>>>> >> + clock-names property.\n>>>>>> >> +- clock-names : must contain an \"lp\" entry, matching entries in the\n>>>>>> >> + clocks property.\n>>>>>> >> +\n>>>>>> >> +Unicam supports a single port node. It should contain one 'port' child node\n>>>>>> >> +with child 'endpoint' node. Please refer to the bindings defined in\n>>>>>> >> +Documentation/devicetree/bindings/media/video-interfaces.txt.\n>>>>>> >> +\n>>>>>> >> +Within the endpoint node the \"remote-endpoint\" and \"data-lanes\" properties\n>>>>>> >> +are mandatory.\n>>>>>> >> +Data lane reordering is not supported so the data lanes must be in order,\n>>>>>> >> +starting at 1. The number of data lanes should represent the number of\n>>>>>> >> +usable lanes for the hardware block. That may be limited by either the SoC or\n>>>>>> >> +how the platform presents the interface, and the lower value must be used.\n>>>>>> >> +\n>>>>>> >> +Lane reordering is not supported on the clock lane either, so the optional\n>>>>>> >> +property \"clock-lane\" will implicitly be <0>.\n>>>>>> >> +Similarly lane inversion is not supported, therefore \"lane-polarities\" will\n>>>>>> >> +implicitly be <0 0 0 0 0>.\n>>>>>> >> +Neither of these values will be checked.\n>>>>>> >> +\n>>>>>> >> +Example:\n>>>>>> >> + csi1: csi1@7e801000 {\n>>>>>> >> + compatible = \"brcm,bcm2835-unicam\";\n>>>>>> >> + reg = <0x7e801000 0x800>,\n>>>>>> >> + <0x7e802004 0x4>;\n>>>>>> >\n>>>>>> > sorry, i didn't noticed this before. I'm afraid this is using a small range of the CMI. Are there possible other users of this range? Does it make sense to handle this by a separate clock driver?\n>>>>>>\n>>>>>> CMI (Clock Manager Image) consists of a total of 4 registers.\n>>>>>> 0x7e802000 is CMI_CAM0, with only bits 0-5 used for gating and\n>>>>>> inversion of the clock and data lanes (2 data lanes available on\n>>>>>> CAM0).\n>>>>>> 0x7e802004 is CMI_CAM1, with only bits 0-9 used for gating and\n>>>>>> inversion of the clock and data lanes (4 data lanes available on\n>>>>>> CAM1).\n>>>>>> 0x7e802008 is CMI_CAMTEST which I have no documentation or drivers for.\n>>>>>> 0x7e802010 is CMI_USBCTL. Only bit 6 is documented and is a reset. The\n>>>>>> default value is the required value. Nothing touches it that I can\n>>>>>> find.\n>>>>>>\n>>>>>> The range listed only covers the one register associated with that\n>>>>>> Unicam instance, so no other users. The other two aren't touched.\n>>>>>> Do 16 active register bits solely for camera clock gating really\n>>>>>> warrant a full clock driver?\n>>>>>\n>>>>> You should describe all the registers in DT, not just what the driver\n>>>>> (currently) uses.\n>>>>\n>>>> I'm not clear what you're asking for here.\n>>>>\n>>>> This binding is for the Unicam block, not for CMI (Clock Manager\n>>>> Imaging). In order for a Unicam instance to work, it needs to enable\n>>>> the relevant clock gating via 1 CMI register, and it will only ever be\n>>>> one register.\n>>>\n>>> Rob, the CMI just a small bit of glue required by the crossing of a\n>>> power domain in a unicam instance, and the two unicam instances in this\n>>> HW have their CMI regs next to each other. It's not really a separate\n>>> block, and I think describing the unicam's CMI reg in the unicam binding\n>>> is appropriate.\n>>>\n>>> What would you need from Dave to ack this binding?\n>>\n>> Sorry, had started to reply on this and got distracted.\n>>\n>> I guess since there seems to be only 1 other bit that could possibly\n>> be used (CMI_USBCTL) it is fine like this. However, my concern would\n>> be if the CMI registers are integrated in a different way in some\n>> future chip that has the same unicam instances. Or just if the\n>> register bits are rearranged. Those are not an uncommon occurrence.\n>> You would have to provide access to those registers in some other way.\n>> It can be dealt with, but then you have to support both cases in the\n>> driver. If you all are fine with that, then:\n>\n> The bigisland chips match bcm2835. For capri the lane enables are\n> shifted down by two and the clock is up at bit 20. That would be\n> trivial to handle based on the compatible string, except that we can't\n> talk to capri's hardware from ARM anyway :(\n\nThank you both.\n\nThe Java and Hawaii chips also have the same Unicam block, but appear\nto be missing CMI totally based on the BCM Android kernel source.\nThey aren't chips I have any interest in, but as Eric says it can be\nsupported easily via the compatible string, or by making the resource\noptional. The latter is easy to do, so I'll add that to v4 of the\npatch set.\n\nCheers,\n Dave\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=)","ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tsecure) header.d=raspberrypi.org header.i=@raspberrypi.org\n\theader.b=\"Ju1yEc4s\"; \n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=raspberrypi-org.20150623.gappssmtp.com\n\theader.i=@raspberrypi-org.20150623.gappssmtp.com header.b=\"TbphYa47\"; \n\tdkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3yhpp11vPVz9s03\n\tfor ;\n\tThu, 23 Nov 2017 04:08:57 +1100 (AEDT)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751472AbdKVRI4 (ORCPT\n\t);\n\tWed, 22 Nov 2017 12:08:56 -0500","from mx08-00252a01.pphosted.com ([91.207.212.211]:40818 \"EHLO\n\tmx08-00252a01.pphosted.com\" rhost-flags-OK-OK-OK-OK)\n\tby vger.kernel.org with ESMTP id S1751458AbdKVRIz (ORCPT\n\t); Wed, 22 Nov 2017 12:08:55 -0500","from pps.filterd (m0102629.ppops.net [127.0.0.1])\n\tby mx08-00252a01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id\n\tvAMGZ73t009623\n\tfor ; Wed, 22 Nov 2017 16:39:24 GMT","from mail-pg0-f71.google.com (mail-pg0-f71.google.com\n\t[74.125.83.71])\n\tby mx08-00252a01.pphosted.com with ESMTP id 2ecvxmgddn-1\n\t(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128\n\tverify=OK)\n\tfor ; Wed, 22 Nov 2017 16:39:24 +0000","by mail-pg0-f71.google.com with SMTP id 199so10635563pgg.20\n\tfor ;\n\tWed, 22 Nov 2017 08:39:24 -0800 (PST)","by 10.100.182.44 with HTTP; Wed, 22 Nov 2017 08:39:21 -0800 (PST)"],"X-Greylist":"delayed 1769 seconds by postgrey-1.27 at vger.kernel.org;\n\tWed, 22 Nov 2017 12:08:54 EST","DKIM-Signature":["v=1; a=rsa-sha256; c=relaxed/relaxed; d=raspberrypi.org;\n\th=mime-version :\n\tin-reply-to : references : from : date : message-id : subject : to :\n\tcc :\n\tcontent-type; s=pp; bh=wYaXtPRmb7XNyLONTDCnIHcHDW+v3S7LVaCSRPWAFm8=; \n\tb=Ju1yEc4sy4GmStRqKGNgFHcpXx5h6/5AoFjLm+Yhn09ok8MRzb3sASiKoK30msBEo0Nr\n\tPwlC9PZRUysX6Dp5YrTZZi/IavbMbHbGxKMAsuayHpxvV8KdhPZZ/46mTZ0s81EDPBkU\n\tUZE+gGNoriyoHDFvSq7YX9PTH2Is6wB4His/QmYJnJO+c8o7Mmn0YUs9u1VvmS6NHAT9\n\ttQdiKRU58YcGxcrs0PibaI2uacHkHQtqzL1I+rGjfpEZQJg3D3WFtIymNdAHV56J9jGT\n\tJhDzm6aW77eB0aUBQA9k60lEHW8M+8Iz9yPQ/b/K8yfaokGgmolV22Otl4mOunIwHplp\n\tcQ== ","v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=raspberrypi-org.20150623.gappssmtp.com; s=20150623;\n\th=mime-version:in-reply-to:references:from:date:message-id:subject:to\n\t:cc; bh=wYaXtPRmb7XNyLONTDCnIHcHDW+v3S7LVaCSRPWAFm8=;\n\tb=TbphYa47Zps3LxLMDWNC6Lm49mXLFZ//cRgZ+F+lzPuyJfxDvrm8akExPIR+OMXm13\n\tpbytKtoNnIaOrN8vRCIG/lTitd8tJvBxDDsTkTI2aetiwBg7FTOV9DEtZqF9G9QR0LG2\n\tB1Y6mCjHC3r3Xi+LTMqrNwvh1G9wGWJl5e+VcYPIEPvnHT5sDwRfvDAqJeToXzdIifxp\n\tw7wMRJOm25iRpA5eo7qBQ2ZGqx3eEVSBy2mI/U8+HAbuHivL5hk1EzRTlxJTU4lJNBNP\n\tLi8IGzWf429sV2fSU+YhbIwRCpCTNw9J7x/+nkAZAMpM7TS5KpVae+6pWmA8rvSh9+QF\n\tENfA=="],"X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:mime-version:in-reply-to:references:from:date\n\t:message-id:subject:to:cc;\n\tbh=wYaXtPRmb7XNyLONTDCnIHcHDW+v3S7LVaCSRPWAFm8=;\n\tb=b4ZF7KF8j22fVu/8rHj7RRMM2oiLdHhZF2i22szzBcHeD+5aw4Dzb2EzX6QQWY6UqC\n\tEHCVBueTGFO7d44SIr9skKlgQtGOEHitU0Zy25MXW7uNi2oZiVpvHcEezcJjyE5CBd41\n\tQpsTbj43e8QDzPVyRuTk9sWK/91UMJA/WXhMGnYMC6r3J9YZD4jGPy1R8KpG6F4BozFT\n\tD7ZfKSabDetRkb1SO4BzqoPD/sXMC6QS8ALThuG4ftjAp3thE6DARTFEWlqfz64O5INF\n\tOKpqQx8qj3qSBTaBpjwLQNw2ST0Ih2wAjdNeUkI+s68yQOtjGRAqZ1ZAM/oL7JXMlIun\n\t74rQ==","X-Gm-Message-State":"AJaThX4yGEhzdCkYW+583krOAA/kwcE1d9pHOQzjUwpjytIOvdrbds3M\n\twdi7cDu0Hk5vojiv777De7g1NBEBr8wqyYHO0kFzNOzlwMC6uPUkCZ8M6rp5uWSMdUX06SW6zqO\n\tXslvpZk4uwUxjwtyNuRlbILhBJlKn27YFXgki","X-Received":["by 10.84.198.35 with SMTP id o32mr21940023pld.214.1511368762174; \n\tWed, 22 Nov 2017 08:39:22 -0800 (PST)","by 10.84.198.35 with SMTP id o32mr21939993pld.214.1511368761810; \n\tWed, 22 Nov 2017 08:39:21 -0800 (PST)"],"X-Google-Smtp-Source":"AGs4zMbRSjmUJtBeIKq4KJ1lvWXS5V6gNYr8FK8V+rlrWV6aG1M0SpLl6wCGJHsOYEC5uLcPioF+l8kIbP+3Usi4THc=","MIME-Version":"1.0","In-Reply-To":"<87bmjvcpyv.fsf@anholt.net>","References":"\n\t\n\t<1814950930.414004.1506062733728@email.1und1.de>\n\t\n\t<20170927215124.6k3j54qf2qscnzc2@rob-hp-laptop>\n\t\n\t<877euje8mc.fsf@anholt.net>\n\t\n\t<87bmjvcpyv.fsf@anholt.net>","From":"Dave Stevenson ","Date":"Wed, 22 Nov 2017 16:39:21 +0000","Message-ID":"","Subject":"Re: [PATCH v3 2/4] [media] dt-bindings: Document BCM283x CSI2/CCP2\n\treceiver","To":"Eric Anholt ","Cc":"Rob Herring , Stefan Wahren ,\n\tMauro Carvalho Chehab ,\n\t\"linux-media@vger.kernel.org\" ,\n\tSakari Ailus ,\n\tHans Verkuil , \n\t\"moderated list:BROADCOM BCM2835 ARM ARCHITECTURE\" \n\t,\n\t\"devicetree@vger.kernel.org\" ","Content-Type":"text/plain; charset=\"UTF-8\"","X-Proofpoint-Virus-Version":"vendor=fsecure engine=2.50.10432:, ,\n\tdefinitions=2017-11-22_05:, , signatures=0","X-Proofpoint-Spam-Details":"rule=outbound_spam_notspam policy=outbound_spam\n\tscore=0 priorityscore=1501\n\tmalwarescore=0 suspectscore=1 phishscore=0 bulkscore=0 spamscore=0\n\tclxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0\n\tclassifier=spam adjust=0 reason=mlx scancount=1\n\tengine=8.0.1-1709140000\n\tdefinitions=main-1711220220","Sender":"devicetree-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"devicetree@vger.kernel.org"}}]