From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752778AbbKBHcA (ORCPT ); Mon, 2 Nov 2015 02:32:00 -0500 Received: from mailout2.w1.samsung.com ([210.118.77.12]:58709 "EHLO mailout2.w1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752273AbbKBHb5 (ORCPT ); Mon, 2 Nov 2015 02:31:57 -0500 X-AuditID: cbfec7f5-f794b6d000001495-84-5637116a1b11 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: k.kozlowski.k@gmail.com, "'Mark Rutland'" , "'Pawel Moll'" , "'Ian Campbell'" , "'Rob Herring'" , "'Kukjin Kim'" , "'Kumar Gala'" References: <56330E6E.50003@samsung.com> <00d401d112ff$c426e9a0$4c74bce0$@samsung.com> <5635D1EE.5010604@samsung.com> In-reply-to: <5635D1EE.5010604@samsung.com> Subject: RE: [PATCH v4 1/4] Documentation: dt-bindings: Describe SROMc configuration Date: Mon, 02 Nov 2015 10:31:52 +0300 Message-id: <012101d11540$8c280be0$a47823a0$@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+spkOVIgDiU4jMHmu53IoLAgIrGUotAS0y68MBUsEi/AKfjc28noWkeQA= Content-language: ru X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrBIsWRmVeSWpSXmKPExsVy+t/xK7pZguZhBpPfq1jMP3KO1aL/zUJW i3OvVjJaPP/3g93i9QtDi/7Hr5ktNj2+xmpxedccNosZ5/cxWSy9fpHJYsL0tSwWrXuPsDvw eKyZt4bR43JfL5PHzll32T1WLv/C5rFpVSebx+Yl9R59W1YxenzeJBfAEcVlk5Kak1mWWqRv l8CV8fvBXLaCyaIV528qNjCuFOhi5OSQEDCR6Fg3jQnCFpO4cG89WxcjF4eQwFJGidaNDxgh nO+MEkcPrGQBqWITUJc4/fUDC0hCRGAXo8SvLd1gDrNAO5PE4Wt32CFavjBKLF76lBWkhVNA W6Lh5Cp2EFtYIEzidM93sDiLgKrE5P4bbCA2r4ClxLwXPUwQtqDEj8n3wNYxC2hJrN95nAnC lpfYvOYtM8SxChI7zr5mBLFFBPwk1lxdwg5RIyIx7d895gmMQrOQjJqFZNQsJKNmIWlZwMiy ilE0tTS5oDgpPddIrzgxt7g0L10vOT93EyMk/r7uYFx6zOoQowAHoxIP7wFPszAh1sSy4src Q4wSHMxKIrxeN4BCvCmJlVWpRfnxRaU5qcWHGKU5WJTEeWfueh8iJJCeWJKanZpakFoEk2Xi 4JRqYAyOLD59XMh1WvT083vkxSeoM/J2sbtEPFgc/0/7wDaxPivFuEsqSw4tNdrn93FO1scY hV3d67JvFTke1Hux5E9pwdoJ81zDDFqi58yR09xT5urXe0Q5UaNZ4o7B//CY986Vzy99+7d8 TfFcvbmzmpWlxdrUXl3UWa9Z8Nyjyy+xmW1eRub+ZiWW4oxEQy3mouJEAA65uOm7AgAA Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello! > > --- 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>; > > Do you have to use 2 cells for address? Cannot it be: > ranges = <0 0x04000000 0x20000 > 1 0x05000000 0x20000 > 2 0x06000000 0x20000 > 3 0x07000000 0x20000>; I tried this first, but it didn't work, and ranges translation gave me something really weird (like addr = 0x80 and size = 0x04000004). I decided not to dig deeply into "ranges" processing, but just followed GPMC approach. They say that first number is range ID and second number is offset within the range. And it just worked. > > 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. > > For timings - OK. PMC is separate. This is not a timing. But it's srom-config, and not srom-timing anymore. So do you want two properties like srom-timing + srom-page-mode (with vendor prefix of course)? > You need to document them. We are not gonna put some data looking like a > vendor blob into the binding. I understand that document has > confidential mark... all of Samsung datasheets I've seen had it. I don't > find it as problem but of course I am not the one to judge here. If you > do not feel comfortable publishing such data, get an approval from your > manager. You can also try to search for this in vendor code > (opensource.samsung.com). If it is published there, then this won't be a > disclosure. I've seen the actual SROMc settings in some old Android kernels, like 3.0.4. But they are not documented there, no comments, just #define's. Ok, i'll try to take a look how to minimize the actual information. :) > BTW, your email client is weird. You are sending non-wrapped emails > without format=flowed in Content-Type. Please stick to mailing list > convention of wrapping at 72-char. I know, sorry, this is MS Outlook (not Express), and it's impossible to configure it this way (if i just set up word wrap, it starts to corrupt patches). I am now trying to wrap the text by hands, i hope it's better. And i cannot use anything else because... You know why. :) Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia From mboxrd@z Thu Jan 1 00:00:00 1970 From: p.fedin@samsung.com (Pavel Fedin) Date: Mon, 02 Nov 2015 10:31:52 +0300 Subject: [PATCH v4 1/4] Documentation: dt-bindings: Describe SROMc configuration In-Reply-To: <5635D1EE.5010604@samsung.com> References: <56330E6E.50003@samsung.com> <00d401d112ff$c426e9a0$4c74bce0$@samsung.com> <5635D1EE.5010604@samsung.com> Message-ID: <012101d11540$8c280be0$a47823a0$@samsung.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Hello! > > --- cut exynos5410.dtsi --- > > sromc: sromc at 12250000 { > > #address-cells = <2>; > > #size-cells = <1>; > > ranges = <0 0 0x04000000 0x20000 > > 1 0 0x05000000 0x20000 > > 2 0 0x06000000 0x20000 > > 3 0 0x07000000 0x20000>; > > Do you have to use 2 cells for address? Cannot it be: > ranges = <0 0x04000000 0x20000 > 1 0x05000000 0x20000 > 2 0x06000000 0x20000 > 3 0x07000000 0x20000>; I tried this first, but it didn't work, and ranges translation gave me something really weird (like addr = 0x80 and size = 0x04000004). I decided not to dig deeply into "ranges" processing, but just followed GPMC approach. They say that first number is range ID and second number is offset within the range. And it just worked. > > 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. > > For timings - OK. PMC is separate. This is not a timing. But it's srom-config, and not srom-timing anymore. So do you want two properties like srom-timing + srom-page-mode (with vendor prefix of course)? > You need to document them. We are not gonna put some data looking like a > vendor blob into the binding. I understand that document has > confidential mark... all of Samsung datasheets I've seen had it. I don't > find it as problem but of course I am not the one to judge here. If you > do not feel comfortable publishing such data, get an approval from your > manager. You can also try to search for this in vendor code > (opensource.samsung.com). If it is published there, then this won't be a > disclosure. I've seen the actual SROMc settings in some old Android kernels, like 3.0.4. But they are not documented there, no comments, just #define's. Ok, i'll try to take a look how to minimize the actual information. :) > BTW, your email client is weird. You are sending non-wrapped emails > without format=flowed in Content-Type. Please stick to mailing list > convention of wrapping at 72-char. I know, sorry, this is MS Outlook (not Express), and it's impossible to configure it this way (if i just set up word wrap, it starts to corrupt patches). I am now trying to wrap the text by hands, i hope it's better. And i cannot use anything else because... You know why. :) Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia