From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933369AbcKHLqG (ORCPT ); Tue, 8 Nov 2016 06:46:06 -0500 Received: from mout.kundenserver.de ([212.227.126.130]:62620 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932319AbcKHLqC (ORCPT ); Tue, 8 Nov 2016 06:46:02 -0500 From: Arnd Bergmann To: John Garry Cc: linux-arm-kernel@lists.infradead.org, Anurup M , anurup.m@huawei.com, linux-kernel@vger.kernel.org, mark.rutland@arm.com, shyju.pv@huawei.com, gabriele.paoloni@huawei.com, will.deacon@arm.com, linuxarm@huawei.com, xuwei5@hisilicon.com, zhangshaokun@hisilicon.com, sanil.kumar@hisilicon.com, tanxiaojun@huawei.com, shiju.jose@huawei.com Subject: Re: [PATCH v1 03/11] drivers: soc: hisi: Add support for Hisilicon Djtag driver Date: Tue, 08 Nov 2016 12:45:20 +0100 Message-ID: <2030692.HPgjBCTYG6@wuerfel> User-Agent: KMail/5.1.3 (Linux/4.4.0-34-generic; KDE/5.18.0; x86_64; ; ) In-Reply-To: References: <1478101374-18778-1-git-send-email-anurup.m@huawei.com> <2467231.EbVekJun1R@wuerfel> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:n/jFalUVGGzHslzpbPP7WxWmTooD5mjvzoQJmwY6TWmVC9/ijNv CSYFoRPeN+mqsdgbL38hSriBuSTLhPRIWgYNE6bsUrqDMrgZ62Dpw5uR2oKA8tnbqMBMvt4 kC0F+oi8L8sktT5N86ut1N34e4zEuClnp5dmGr06guI6c3p5e/jeRW0524sEbYJDOFgTEb1 kYdKNVS3ABfmhPI2MLjcw== X-UI-Out-Filterresults: notjunk:1;V01:K0:mSfLOFCM9lU=:n2JStkgbbZdH63lX0eYu/Q VQrz/AazRJRjx9SxGGnkJI3FN+HbqV0yDiVB6Yeu1hm8DmIVczkvBx9UBjRLgUzr9429P7ARk PxvnBXV7Tq5AkKgPD2+cIqA6OrS5AFC5UG/ZAXp4SXGKLo0u5aDTfb6xAKuWr2ir6Ugi5/6t2 ToH/IfEVPCaPCSWlO9EQhSz1n/PyfRs67J3mk16+irQxNkhkmR+esNK0+i8EBzexvxNeInGRP dgoJzVLcLkUH2Ci2CcUcmomFjV3zY+AAThKYWltADqwHFyhJw+WX+Mpa7EWxFvo6pzylth+zd hpyLGOtVzt2H6g9Q9ddtdi8QZxEeJxAeUs56vhxAKNNLqG+Vgc4pcF5Ln/Ig5bYP6+ysQBRIC GlFmsw4RGeSjwgIUKeI2jZzVBuIM0EIFnIFFQz5WikBzUC3HVVa8P3J25NjeVDZQTbj95yRZn WBTs1J+i5Xqleq5SfOzzV0X0+djJxRv52959JzMEBU7wnZUaxCcRkeMV/s1IbpEWT4Q+pHOfR r8/G7a8ISq3MB2lcZ8q6K6LQYp9AFA7qvcFQgQjplVztKkGb9VBmQD0xwlmW4Sw298CeD5RcU YqSripZ2s0epvA4M1hcFG+jTTrYTPrpCRGb4psVl2nYQEqouEHpcXkHUpRqSSWcIOAVQl0s7b 59tqDGECT0vae3EPgBY8CS6OJJPIs7AtJ3L+J6zLi3IXcNUZriGAKeFYppSVovcrTu0fDskCH 3ZEoMPtJxpkhvlHn Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tuesday, November 8, 2016 11:23:35 AM CET John Garry wrote: > On 07/11/2016 20:08, Arnd Bergmann wrote: > > On Monday, November 7, 2016 2:15:10 PM CET John Garry wrote: > >> > >> Hi Arnd, > >> > >> The new bus type tries to model the djtag in a similar way to I2C/USB > >> driver arch, where we have a host bus adapter and child devices attached > >> to the bus. The child devices are bus driver devices and have bus > >> addresses. We think of the djtag as a separate bus, so we are modelling > >> it as such. > >> > >> The bus driver offers a simple host interface for clients to read/write > >> to the djtag bus: bus accesses are hidden from the client, the host > >> drives the bus. > > > > Ok, in that case we should probably start out by having a bus specific > > DT binding, and separating the description from that of the bus master > > device. > > OK > > > > > I'd suggest requiring #address-cells=<1> and #size-cells=<0> in the master > > node, and listing the children by reg property. If the address is not > > easily expressed as a single integer, use a larger #address-cells value. > > We already have something equivalent to reg in "module-id" (see patch > 02/11), which is the slave device bus address; here's a sample: > + /* For L3 cache PMU */ > + pmul3c0 { > + compatible = "hisilicon,hisi-pmu-l3c-v1"; > + scl-id = <0x02>; > + num-events = <0x16>; > + num-counters = <0x08>; > + module-id = <0x04>; > + num-banks = <0x04>; > + cfgen-map = <0x02 0x04 0x01 0x08>; > + counter-reg = <0x170>; > + evctrl-reg = <0x04>; > + event-en = <0x1000000>; > + evtype-reg = <0x140>; > + }; > > FYI, "module-id" is our own internal hw nomenclature. Yes, that was my interpretation as well. Please use the standard "reg" property for this then. > > Another option that we have previously used was to actually pretend that > > a vendor specific bus is an i2c bus and use the i2c probing infrastructure, > > but that only makes sense if the software side closely resembles i2c > > (this was the case for Allwinner I think, but I have not looked at > > your driver in enough detail to know if it is true here as well). > > > > OK, let me check this. By chance do you remember the specific AllWinner > driver/hw? drivers/i2c/busses/i2c-sun6i-p2wi.c Arnd