From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1030463AbbJ3KnP (ORCPT ); Fri, 30 Oct 2015 06:43:15 -0400 Received: from mailout1.w1.samsung.com ([210.118.77.11]:61836 "EHLO mailout1.w1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1030375AbbJ3KnM (ORCPT ); Fri, 30 Oct 2015 06:43:12 -0400 X-AuditID: cbfec7f4-f79c56d0000012ee-58-563349bcbdc2 From: Pavel Fedin To: "'Krzysztof Kozlowski'" , devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-samsung-soc@vger.kernel.org, linux-kernel@vger.kernel.org Cc: "'Rob Herring'" , "'Pawel Moll'" , "'Mark Rutland'" , "'Ian Campbell'" , "'Kumar Gala'" , "'Kukjin Kim'" References: <56330E6E.50003@samsung.com> In-reply-to: <56330E6E.50003@samsung.com> Subject: RE: [PATCH v4 1/4] Documentation: dt-bindings: Describe SROMc configuration Date: Fri, 30 Oct 2015 13:43:07 +0300 Message-id: <00d401d112ff$c426e9a0$4c74bce0$@samsung.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-index: AQG1Qj+spkOVIgDiU4jMHmu53IoLAgIrGUotAS0y68OeoKWgoA== Content-language: ru X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprPIsWRmVeSWpSXmKPExsVy+t/xa7p7PI3DDJZfMbOYf+Qcq0X/m4Ws FuderWS0eP3C0KL/8Wtmi02Pr7FaXN41h81ixvl9TBZLr19kspgwfS2LReveI+wO3B5r5q1h 9Ljc18vksXL5FzaPTas62Tw2L6n36NuyitHj8ya5APYoLpuU1JzMstQifbsEroyH054xFswW qzj1/TpjA+MuwS5GTg4JAROJx+sPMkLYYhIX7q1n62Lk4hASWMoocefWV1YI5zujRM+zHrAq NgF1idNfP7CAJEQEdjFK/NrSDeYwC7xhlDi17DEzXP/FVQeZQFo4BTQlzs1bxA5iCwuESZzu +c4KYrMIqEpMvjUJzOYVsJRoXnKECcIWlPgx+R4LiM0soCWxfudxJghbXmLzmrfMEMcqSOw4 +xrsJBEBJ4lLxw5D1YhITPt3j3kCo9AsJKNmIRk1C8moWUhaFjCyrGIUTS1NLihOSs811CtO zC0uzUvXS87P3cQIibYvOxgXH7M6xCjAwajEw/sjwShMiDWxrLgy9xCjBAezkghvj5NxmBBv SmJlVWpRfnxRaU5q8SFGaQ4WJXHeubvehwgJpCeWpGanphakFsFkmTg4pRoYmwxUGlmK1QvV eNiWnLd34l/6OWYjy/uCNRdmhD3ufaayX/Mm11+WNbqtB8N1gjrOrFe7/iY9oFB95taT3fJe jNL3L+3zdT5atvTJBP4p4ncS+S2mXFSN1LhqvyxGuTQwrcTs1/e4O0LF3nMcVDcecpkY0Pnp ivOj4KI0n+eKW5K2P7d7/1JfiaU4I9FQi7moOBEAVHbIALICAAA= Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello! > Please, carefully look at: > Documentation/devicetree/bindings/net/gpmc-eth.txt > Documentation/devicetree/bindings/bus/ti-gpmc.txt > > 1. Try to re-use existing bindings. Although I see existing bank-width > and gpmc,device-width but yours samsung,srom-data-width seems better. > Maybe there are other to re-use? I've done this and this is what i currently came up with. I'd like to discuss this before respin because nobody needs this back-and-forth bouncing. --- cut exynos5410.dtsi --- sromc: sromc@12250000 { #address-cells = <2>; #size-cells = <1>; ranges = <0 0 0x04000000 0x20000 1 0 0x05000000 0x20000 2 0 0x06000000 0x20000 3 0 0x07000000 0x20000>; compatible = "samsung,exynos-srom"; reg = <0x12250000 0x14>; }; --- cut exynos5410.dtsi --- --- cut exynos5410-smdk5410.dts --- &sromc { pinctrl-names = "default"; pinctrl-0 = <&srom_ctl>, <&srom_ebi>; ethernet@3 { compatible = "smsc,lan9115"; reg = <3 0 0x10000>; phy-mode = "mii"; interrupt-parent = <&gpx0>; interrupts = <5 8>; reg-io-width = <2>; smsc,irq-push-pull; smsc,force-internal-phy; samsung,srom-config = <1 9 12 1 9 1 1>; }; }; --- cut exynos5410-smdk5410.dts --- 1. After writing proper ranges i was able to get rid of dedicated bank number property, because now it is the first value in device's "reg". 2. I noticed that smsc binding already uses reg-io-width property. I searched for it, and it appears to be reused by many devices. So, i decided to use it to specify bank width, since it's already there. ti-gpmc uses bank-width because it supports configurations like reg-io-width = 4 && bank-width = 2. I don't know if it's possible to do the same with SROMc, Exynos doc doesn't tell anything about 32-bit accesses. But, if you want to support it too, i would suggest the following algorithm: if (have bank-width) width = bank-width else if (have reg-io-width) width = reg-io-width else width = 1 /* default */ 3. About samsung,srom-config array. I have the following reasons to keep if this way: - listing every property under own name is just too much typing - these values really do not make sense without each other, or partialy. I would say that in array form they are even better readable, because it is the same order in which they go into the register. However, it is still a nice idea do document them, but... my PDF has "confidential" watermark on it, and this would mean that i essentially copy some information from it into Linux doc. Is it okay to do this? If you still dislike the array, i'll redo is a set of properties like samsung,srom-tacs, samsung,srom-tcos, etc. Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia