From mboxrd@z Thu Jan 1 00:00:00 1970 From: zourongrong@huawei.com (Rongrong Zou) Date: Tue, 12 Jan 2016 17:25:56 +0800 Subject: [PATCH v1 3/3] ARM64 LPC: update binding doc In-Reply-To: <20160112090722.GN13633@e106497-lin.cambridge.arm.com> References: <1451396032-23708-1-git-send-email-zourongrong@gmail.com> <568912EE.9030009@huawei.com> <15026471.7nGZ0rWlIf@wuerfel> <20160111161415.GM13633@e106497-lin.cambridge.arm.com> <56946768.7090805@gmail.com> <20160112090722.GN13633@e106497-lin.cambridge.arm.com> Message-ID: <5694C6A4.8060308@huawei.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org ? 2016/1/12 17:07, liviu.dudau at arm.com ??: > On Tue, Jan 12, 2016 at 10:39:36AM +0800, Rongrong Zou wrote: >> On 2016/1/12 0:14, liviu.dudau at arm.com wrote: >>> On Mon, Jan 04, 2016 at 12:13:05PM +0100, Arnd Bergmann wrote: >>>> On Sunday 03 January 2016 20:24:14 Rongrong Zou wrote: >>>>> ? 2015/12/31 23:00, Rongrong Zou ??: >>>>>> 2015-12-31 22:40 GMT+08:00 Arnd Bergmann >: >>>>>> > On Thursday 31 December 2015 22:12:19 Rongrong Zou wrote: >>>>>> > > ? 2015/12/30 17:06, Arnd Bergmann ??: >>>>>> > > > On Tuesday 29 December 2015 21:33:52 Rongrong Zou wrote: >>>>>> > >>>>>> > The DT sample above looks good in principle. I believe what you are missing >>>>>> > here is code in your driver to scan the child nodes to create the platform >>>>>> > devices. of_bus_isa_translate() should work with your definition here >>>>>> > and create the correct IORESOURCE_IO resources. You don't have any MMIO >>>>>> > resources, so the absence of a ranges property is ok. Maybe all you >>>>>> > are missing is a call to of_platform_populate() or of_platform_bus_probe()? >>>>>> > >>>>>> >>>>>> You are right. thanks, i'll try on test board . if i get the correct result , the new patch >>>>>> will be sent later. By the way, it's my another email account use when i at home. >>>>> >>>>> I tried, and there need some additional changes. >>>>> >>>>> isa at a01b0000 { >>>>> >>>>> /*the node name should start with "isa", because of below definition >>>>> * static int of_bus_isa_match(struct device_node *np) >>>>> * { >>>>> * return !strcmp(np->name, "isa"); >>>>> * } >>>> >>>> Looks good. It would be nicer to match on device_type than on name, >>>> but this is ancient code and it's probably best not to touch it >>>> so we don't accidentally break some old SPARC or PPC system. >>>> >>>>> */ >>>>> compatible = "low-pin-count"; >>>>> device_type = "isa"; >>>>> #address-cells = <2>; >>>>> #size-cells = <1>; >>>>> reg = <0x0 0xa01b0000 0x0 0x10000>; >>>>> ranges = <0x1 0x0 0x0 0x0 0x1000>; >>>>> /* >>>>> * ranges is required, then i can get the IORESOURCE_IO <0xe4,4> from "reg = <0x1, 0x000000e4, 4>". >>>>> * >>>>> */ >>>>> ipmi_0:ipmi at 000000e4{ >>>>> device_type = "ipmi"; >>>>> compatible = "ipmi-bt"; >>>>> reg = <0x1 0x000000e4 0x4>; >>>>> }; >>>>> >>>> >>>> This looks wrong: the property above says that the I/O port range is >>>> translated to MMIO address 0x00000000 to 0x00010000, which is not >>>> true on your hardware. I think this needs to be changed in the code >>>> so the ranges property is not required for I/O ports. >>>> >>>>> drivers\of\address.c >>>>> static int __of_address_to_resource(struct device_node *dev, >>>>> const __be32 *addrp, u64 size, unsigned int flags, >>>>> const char *name, struct resource *r) >>>>> { >>>>> u64 taddr; >>>>> >>>>> if ((flags & (IORESOURCE_IO | IORESOURCE_MEM)) == 0) >>>>> return -EINVAL; >>>>> taddr = of_translate_address(dev, addrp); >>>>> if (taddr == OF_BAD_ADDR) >>>>> return -EINVAL; >>>>> memset(r, 0, sizeof(struct resource)); >>>>> if (flags & IORESOURCE_IO) { >>>>> unsigned long port; >>>>> >>>>> /*****************************************************************/ >>>>> /*legacy port(< 0x1000) is reserved, and need no translation here*/ >>>>> /*****************************************************************/ >>>>> if(taddr + size < PCIBIOS_MIN_IO){ >>>>> r->start = taddr; >>>>> r->end = taddr + size - 1; >>>>> } >>>> >>>> I don't like having a special case based on the address here, >>>> the same kind of hack might be needed for PCI I/O spaces in >>>> hardware that uses an indirect method like your LPC bus >>>> does, and the code above will not work on any LPC implementation >>>> that correctly multiplexes its I/O ports with the first PCI domain. >>>> >>>> I think it would be better to avoid translating the port into >>>> a physical address to start with just to translate it back into >>>> a port number, what we need instead is the offset between the >>>> bus specific port number and the linux port number. I've added >>>> Liviu to Cc, he wrote this code originally and may have some idea >>>> of how we could do that. >>> >>> Hi, >> >> Hi Liviu, >> >> Thanks for reviewing this. >> >>> >>> Getting back to work after a longer holiday, my brain might not be running >>> at full speed here, so I'm trying to clarify things a bit here. >>> >>> It looks to me like Rongrong is trying to trap the inb()/outb() calls that he >>> added to arm64 by patch 1/3 and redirect those operations to the memory >>> mapped LPC driver. I think the whole redirection and registration of inb/outb >>> ops can be made cleaner, so that the general concept resembles the DMA ops >>> registration? (I have this mental picture that what Rongrong is trying to do >>> is similar to what a DMA engine does, except this is slowing down things to >>> byte level). If that is done properly in the parent node, then we should not >>> care what the PCIBIOS_MIN_IO value is as the inb()/outb() calls will always >>> go through the redirection for the children. >>> >>> As for the ranges property: does he wants the ipmi-bt driver to see in the >>> reg property the legacy ISA I/O ports values or the CPU addresses? If the former, >>> then I agree that the range property should not be required, but also the >>> reg values need to be changed (drop the top bit). If the later, then the >>> ranges property is required to do the proper translation. >> >> The former, thanks. >> >>> >>> Rongrong, removing the ranges property and with a reg = <0xe4 0x4> property >>> in the ipmi-bt node, what IO_RESOURCE type resources do you get back from >>> the of_address_to_resource() translation? >> >> I want to get IORESOURCE_IO type resource, but if the parent node drop the >> "rangs" property, the of_address_to_resource() translation will return with -EINVAL. > > Have you tracked what part of the code is sensitive to the presence of "ranges" > property? Does of_get_address() call returns the IO_RESOURCE flag set without "ranges"? > Yes, IO_RESOURCE flag can be get without "ranges". I tracked the code, it is at of_translate_one(), Below is the calling infomation. of_address_to_resource-> __of_address_to_resource ->of_translate_address-> __of_translate_address(dev, in_addr, "ranges")->of_translate_one() static int of_translate_one(struct device_node *parent, struct of_bus *bus, struct of_bus *pbus, __be32 *addr, int na, int ns, int pna, const char *rprop) { const __be32 *ranges; unsigned int rlen; int rone; u64 offset = OF_BAD_ADDR; ranges = of_get_property(parent, rprop, &rlen); if (ranges == NULL && !of_empty_ranges_quirk(parent)) { pr_debug("OF: no ranges; cannot translate\n"); return 1; } ... } > Best regards, > Liviu > >> >>> >>> Best regards, >>> Liviu >>> >>> >>>> >>>> Arnd >>>> >>> >> Regards, >> Rongrong >> > -- Regards, Rongrong From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rongrong Zou Subject: Re: [PATCH v1 3/3] ARM64 LPC: update binding doc Date: Tue, 12 Jan 2016 17:25:56 +0800 Message-ID: <5694C6A4.8060308@huawei.com> References: <1451396032-23708-1-git-send-email-zourongrong@gmail.com> <568912EE.9030009@huawei.com> <15026471.7nGZ0rWlIf@wuerfel> <20160111161415.GM13633@e106497-lin.cambridge.arm.com> <56946768.7090805@gmail.com> <20160112090722.GN13633@e106497-lin.cambridge.arm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8"; Format="flowed" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: <20160112090722.GN13633@e106497-lin.cambridge.arm.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=m.gmane.org@lists.infradead.org To: liviu.dudau@arm.com, Rongrong Zou Cc: devicetree@vger.kernel.org, Catalin Marinas , Arnd Bergmann , Corey Minyard , gregkh@linuxfoundation.org, Will Deacon , linux-kernel@vger.kernel.org, linuxarm@huawei.com, benh@kernel.crashing.org, linux-arm-kernel@lists.infradead.org List-Id: devicetree@vger.kernel.org 5ZyoIDIwMTYvMS8xMiAxNzowNywgbGl2aXUuZHVkYXVAYXJtLmNvbSDlhpnpgZM6Cj4gT24gVHVl LCBKYW4gMTIsIDIwMTYgYXQgMTA6Mzk6MzZBTSArMDgwMCwgUm9uZ3JvbmcgWm91IHdyb3RlOgo+ PiBPbiAyMDE2LzEvMTIgMDoxNCwgbGl2aXUuZHVkYXVAYXJtLmNvbSB3cm90ZToKPj4+IE9uIE1v biwgSmFuIDA0LCAyMDE2IGF0IDEyOjEzOjA1UE0gKzAxMDAsIEFybmQgQmVyZ21hbm4gd3JvdGU6 Cj4+Pj4gT24gU3VuZGF5IDAzIEphbnVhcnkgMjAxNiAyMDoyNDoxNCBSb25ncm9uZyBab3Ugd3Jv dGU6Cj4+Pj4+IOWcqCAyMDE1LzEyLzMxIDIzOjAwLCBSb25ncm9uZyBab3Ug5YaZ6YGTOgo+Pj4+ Pj4gMjAxNS0xMi0zMSAyMjo0MCBHTVQrMDg6MDAgQXJuZCBCZXJnbWFubiA8YXJuZEBhcm5kYi5k ZSA8bWFpbHRvOmFybmRAYXJuZGIuZGU+PjoKPj4+Pj4+ICAgPiBPbiBUaHVyc2RheSAzMSBEZWNl bWJlciAyMDE1IDIyOjEyOjE5IFJvbmdyb25nIFpvdSB3cm90ZToKPj4+Pj4+ICAgPiA+IOWcqCAy MDE1LzEyLzMwIDE3OjA2LCBBcm5kIEJlcmdtYW5uIOWGmemBkzoKPj4+Pj4+ICAgPiA+ID4gT24g VHVlc2RheSAyOSBEZWNlbWJlciAyMDE1IDIxOjMzOjUyIFJvbmdyb25nIFpvdSB3cm90ZToKPj4+ Pj4+ICAgPgo+Pj4+Pj4gICA+IFRoZSBEVCBzYW1wbGUgYWJvdmUgbG9va3MgZ29vZCBpbiBwcmlu Y2lwbGUuIEkgYmVsaWV2ZSB3aGF0IHlvdSBhcmUgbWlzc2luZwo+Pj4+Pj4gICA+IGhlcmUgaXMg Y29kZSBpbiB5b3VyIGRyaXZlciB0byBzY2FuIHRoZSBjaGlsZCBub2RlcyB0byBjcmVhdGUgdGhl IHBsYXRmb3JtCj4+Pj4+PiAgID4gZGV2aWNlcy4gb2ZfYnVzX2lzYV90cmFuc2xhdGUoKSBzaG91 bGQgd29yayB3aXRoIHlvdXIgZGVmaW5pdGlvbiBoZXJlCj4+Pj4+PiAgID4gYW5kIGNyZWF0ZSB0 aGUgY29ycmVjdCBJT1JFU09VUkNFX0lPIHJlc291cmNlcy4gWW91IGRvbid0IGhhdmUgYW55IE1N SU8KPj4+Pj4+ICAgPiByZXNvdXJjZXMsIHNvIHRoZSBhYnNlbmNlIG9mIGEgcmFuZ2VzIHByb3Bl cnR5IGlzIG9rLiBNYXliZSBhbGwgeW91Cj4+Pj4+PiAgID4gYXJlIG1pc3NpbmcgaXMgYSBjYWxs IHRvIG9mX3BsYXRmb3JtX3BvcHVsYXRlKCkgb3Igb2ZfcGxhdGZvcm1fYnVzX3Byb2JlKCk/Cj4+ Pj4+PiAgID4KPj4+Pj4+Cj4+Pj4+PiBZb3UgYXJlIHJpZ2h0LiB0aGFua3MsIGknbGwgdHJ5IG9u IHRlc3QgYm9hcmQgLiAgaWYgaSBnZXQgdGhlIGNvcnJlY3QgcmVzdWx0ICwgdGhlIG5ldyBwYXRj aAo+Pj4+Pj4gd2lsbCBiZSBzZW50IGxhdGVyLiBCeSB0aGUgd2F5LCBpdCdzIG15IGFub3RoZXIg ZW1haWwgYWNjb3VudCB1c2Ugd2hlbiBpIGF0IGhvbWUuCj4+Pj4+Cj4+Pj4+IEkgdHJpZWQsIGFu ZCB0aGVyZSBuZWVkIHNvbWUgYWRkaXRpb25hbCBjaGFuZ2VzLgo+Pj4+Pgo+Pj4+PiBpc2FAYTAx YjAwMDAgewo+Pj4+Pgo+Pj4+PiAvKnRoZSBub2RlIG5hbWUgc2hvdWxkIHN0YXJ0IHdpdGggImlz YSIsIGJlY2F1c2Ugb2YgYmVsb3cgZGVmaW5pdGlvbgo+Pj4+PiAqIHN0YXRpYyBpbnQgb2ZfYnVz X2lzYV9tYXRjaChzdHJ1Y3QgZGV2aWNlX25vZGUgKm5wKQo+Pj4+PiAqIHsKPj4+Pj4gKglyZXR1 cm4gIXN0cmNtcChucC0+bmFtZSwgImlzYSIpOwo+Pj4+PiAqIH0KPj4+Pgo+Pj4+IExvb2tzIGdv b2QuIEl0IHdvdWxkIGJlIG5pY2VyIHRvIG1hdGNoIG9uIGRldmljZV90eXBlIHRoYW4gb24gbmFt ZSwKPj4+PiBidXQgdGhpcyBpcyBhbmNpZW50IGNvZGUgYW5kIGl0J3MgcHJvYmFibHkgYmVzdCBu b3QgdG8gdG91Y2ggaXQKPj4+PiBzbyB3ZSBkb24ndCBhY2NpZGVudGFsbHkgYnJlYWsgc29tZSBv bGQgU1BBUkMgb3IgUFBDIHN5c3RlbS4KPj4+Pgo+Pj4+PiAqLwo+Pj4+PiAJY29tcGF0aWJsZSA9 ICJsb3ctcGluLWNvdW50IjsKPj4+Pj4gCWRldmljZV90eXBlID0gImlzYSI7Cj4+Pj4+IAkjYWRk cmVzcy1jZWxscyA9IDwyPjsKPj4+Pj4gCSNzaXplLWNlbGxzID0gPDE+Owo+Pj4+PiAJcmVnID0g PDB4MCAweGEwMWIwMDAwIDB4MCAweDEwMDAwPjsKPj4+Pj4gCXJhbmdlcyA9IDwweDEgMHgwIDB4 MCAweDAgMHgxMDAwPjsKPj4+Pj4gLyoKPj4+Pj4gKiAgcmFuZ2VzIGlzIHJlcXVpcmVkLCB0aGVu IGkgY2FuIGdldCB0aGUgSU9SRVNPVVJDRV9JTyA8MHhlNCw0PiBmcm9tICJyZWcgPSA8MHgxLCAw eDAwMDAwMGU0LCA0PiIuCj4+Pj4+ICoKPj4+Pj4gKi8KPj4+Pj4gCWlwbWlfMDppcG1pQDAwMDAw MGU0ewo+Pj4+PiAJCWRldmljZV90eXBlID0gImlwbWkiOwo+Pj4+PiAJCWNvbXBhdGlibGUgPSAi aXBtaS1idCI7Cj4+Pj4+IAkJcmVnID0gPDB4MSAweDAwMDAwMGU0IDB4ND47Cj4+Pj4+IH07Cj4+ Pj4+Cj4+Pj4KPj4+PiBUaGlzIGxvb2tzIHdyb25nOiB0aGUgcHJvcGVydHkgYWJvdmUgc2F5cyB0 aGF0IHRoZSBJL08gcG9ydCByYW5nZSBpcwo+Pj4+IHRyYW5zbGF0ZWQgdG8gTU1JTyBhZGRyZXNz IDB4MDAwMDAwMDAgdG8gMHgwMDAxMDAwMCwgd2hpY2ggaXMgbm90Cj4+Pj4gdHJ1ZSBvbiB5b3Vy IGhhcmR3YXJlLiBJIHRoaW5rIHRoaXMgbmVlZHMgdG8gYmUgY2hhbmdlZCBpbiB0aGUgY29kZQo+ Pj4+IHNvIHRoZSByYW5nZXMgcHJvcGVydHkgaXMgbm90IHJlcXVpcmVkIGZvciBJL08gcG9ydHMu Cj4+Pj4KPj4+Pj4gZHJpdmVyc1xvZlxhZGRyZXNzLmMKPj4+Pj4gc3RhdGljIGludCBfX29mX2Fk ZHJlc3NfdG9fcmVzb3VyY2Uoc3RydWN0IGRldmljZV9ub2RlICpkZXYsCj4+Pj4+ICAgICAgICAg ICAgICAgICAgIGNvbnN0IF9fYmUzMiAqYWRkcnAsIHU2NCBzaXplLCB1bnNpZ25lZCBpbnQgZmxh Z3MsCj4+Pj4+ICAgICAgICAgICAgICAgICAgIGNvbnN0IGNoYXIgKm5hbWUsIHN0cnVjdCByZXNv dXJjZSAqcikKPj4+Pj4gewo+Pj4+PiAgICAgICAgICAgdTY0IHRhZGRyOwo+Pj4+Pgo+Pj4+PiAg ICAgICAgICAgaWYgKChmbGFncyAmIChJT1JFU09VUkNFX0lPIHwgSU9SRVNPVVJDRV9NRU0pKSA9 PSAwKQo+Pj4+PiAgICAgICAgICAgICAgICAgICByZXR1cm4gLUVJTlZBTDsKPj4+Pj4gICAgICAg ICAgIHRhZGRyID0gb2ZfdHJhbnNsYXRlX2FkZHJlc3MoZGV2LCBhZGRycCk7Cj4+Pj4+ICAgICAg ICAgICBpZiAodGFkZHIgPT0gT0ZfQkFEX0FERFIpCj4+Pj4+ICAgICAgICAgICAgICAgICAgIHJl dHVybiAtRUlOVkFMOwo+Pj4+PiAgICAgICAgICAgbWVtc2V0KHIsIDAsIHNpemVvZihzdHJ1Y3Qg cmVzb3VyY2UpKTsKPj4+Pj4gICAgICAgICAgIGlmIChmbGFncyAmIElPUkVTT1VSQ0VfSU8pIHsK Pj4+Pj4gICAgICAgICAgICAgICAgICAgdW5zaWduZWQgbG9uZyBwb3J0Owo+Pj4+Pgo+Pj4+PiAv KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKiovCj4+Pj4+IC8qbGVnYWN5IHBvcnQoPCAweDEwMDApIGlzIHJlc2VydmVkLCBhbmQg bmVlZCBubyB0cmFuc2xhdGlvbiBoZXJlKi8KPj4+Pj4gLyoqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqLwo+Pj4+PiAgICAgICAg ICAgICAgICAgICBpZih0YWRkciArIHNpemUgPCBQQ0lCSU9TX01JTl9JTyl7Cj4+Pj4+ICAgICAg ICAgICAgICAgICAgICAgICAgICAgci0+c3RhcnQgPSB0YWRkcjsKPj4+Pj4gICAgICAgICAgICAg ICAgICAgICAgICAgICByLT5lbmQgPSB0YWRkciArIHNpemUgLSAxOwo+Pj4+PiAgICAgICAgICAg ICAgICAgICB9Cj4+Pj4KPj4+PiBJIGRvbid0IGxpa2UgaGF2aW5nIGEgc3BlY2lhbCBjYXNlIGJh c2VkIG9uIHRoZSBhZGRyZXNzIGhlcmUsCj4+Pj4gdGhlIHNhbWUga2luZCBvZiBoYWNrIG1pZ2h0 IGJlIG5lZWRlZCBmb3IgUENJIEkvTyBzcGFjZXMgaW4KPj4+PiBoYXJkd2FyZSB0aGF0IHVzZXMg YW4gaW5kaXJlY3QgbWV0aG9kIGxpa2UgeW91ciBMUEMgYnVzCj4+Pj4gZG9lcywgYW5kIHRoZSBj b2RlIGFib3ZlIHdpbGwgbm90IHdvcmsgb24gYW55IExQQyBpbXBsZW1lbnRhdGlvbgo+Pj4+IHRo YXQgY29ycmVjdGx5IG11bHRpcGxleGVzIGl0cyBJL08gcG9ydHMgd2l0aCB0aGUgZmlyc3QgUENJ IGRvbWFpbi4KPj4+Pgo+Pj4+IEkgdGhpbmsgaXQgd291bGQgYmUgYmV0dGVyIHRvIGF2b2lkIHRy YW5zbGF0aW5nIHRoZSBwb3J0IGludG8KPj4+PiBhIHBoeXNpY2FsIGFkZHJlc3MgdG8gc3RhcnQg d2l0aCBqdXN0IHRvIHRyYW5zbGF0ZSBpdCBiYWNrIGludG8KPj4+PiBhIHBvcnQgbnVtYmVyLCB3 aGF0IHdlIG5lZWQgaW5zdGVhZCBpcyB0aGUgb2Zmc2V0IGJldHdlZW4gdGhlCj4+Pj4gYnVzIHNw ZWNpZmljIHBvcnQgbnVtYmVyIGFuZCB0aGUgbGludXggcG9ydCBudW1iZXIuIEkndmUgYWRkZWQK Pj4+PiBMaXZpdSB0byBDYywgaGUgd3JvdGUgdGhpcyBjb2RlIG9yaWdpbmFsbHkgYW5kIG1heSBo YXZlIHNvbWUgaWRlYQo+Pj4+IG9mIGhvdyB3ZSBjb3VsZCBkbyB0aGF0Lgo+Pj4KPj4+IEhpLAo+ Pgo+PiBIaSBMaXZpdSwKPj4KPj4gVGhhbmtzIGZvciByZXZpZXdpbmcgdGhpcy4KPj4KPj4+Cj4+ PiBHZXR0aW5nIGJhY2sgdG8gd29yayBhZnRlciBhIGxvbmdlciBob2xpZGF5LCBteSBicmFpbiBt aWdodCBub3QgYmUgcnVubmluZwo+Pj4gYXQgZnVsbCBzcGVlZCBoZXJlLCBzbyBJJ20gdHJ5aW5n IHRvIGNsYXJpZnkgdGhpbmdzIGEgYml0IGhlcmUuCj4+Pgo+Pj4gSXQgbG9va3MgdG8gbWUgbGlr ZSBSb25ncm9uZyBpcyB0cnlpbmcgdG8gdHJhcCB0aGUgaW5iKCkvb3V0YigpIGNhbGxzIHRoYXQg aGUKPj4+IGFkZGVkIHRvIGFybTY0IGJ5IHBhdGNoIDEvMyBhbmQgcmVkaXJlY3QgdGhvc2Ugb3Bl cmF0aW9ucyB0byB0aGUgbWVtb3J5Cj4+PiBtYXBwZWQgTFBDIGRyaXZlci4gSSB0aGluayB0aGUg d2hvbGUgcmVkaXJlY3Rpb24gYW5kIHJlZ2lzdHJhdGlvbiBvZiBpbmIvb3V0Ygo+Pj4gb3BzIGNh biBiZSBtYWRlIGNsZWFuZXIsIHNvIHRoYXQgdGhlIGdlbmVyYWwgY29uY2VwdCByZXNlbWJsZXMg dGhlIERNQSBvcHMKPj4+IHJlZ2lzdHJhdGlvbj8gKEkgaGF2ZSB0aGlzIG1lbnRhbCBwaWN0dXJl IHRoYXQgd2hhdCBSb25ncm9uZyBpcyB0cnlpbmcgdG8gZG8KPj4+IGlzIHNpbWlsYXIgdG8gd2hh dCBhIERNQSBlbmdpbmUgZG9lcywgZXhjZXB0IHRoaXMgaXMgc2xvd2luZyBkb3duIHRoaW5ncyB0 bwo+Pj4gYnl0ZSBsZXZlbCkuIElmIHRoYXQgaXMgZG9uZSBwcm9wZXJseSBpbiB0aGUgcGFyZW50 IG5vZGUsIHRoZW4gd2Ugc2hvdWxkIG5vdAo+Pj4gY2FyZSB3aGF0IHRoZSBQQ0lCSU9TX01JTl9J TyB2YWx1ZSBpcyBhcyB0aGUgaW5iKCkvb3V0YigpIGNhbGxzIHdpbGwgYWx3YXlzCj4+PiBnbyB0 aHJvdWdoIHRoZSByZWRpcmVjdGlvbiBmb3IgdGhlIGNoaWxkcmVuLgo+Pj4KPj4+IEFzIGZvciB0 aGUgcmFuZ2VzIHByb3BlcnR5OiBkb2VzIGhlIHdhbnRzIHRoZSBpcG1pLWJ0IGRyaXZlciB0byBz ZWUgaW4gdGhlCj4+PiByZWcgcHJvcGVydHkgdGhlIGxlZ2FjeSBJU0EgSS9PIHBvcnRzIHZhbHVl cyBvciB0aGUgQ1BVIGFkZHJlc3Nlcz8gSWYgdGhlIGZvcm1lciwKPj4+IHRoZW4gSSBhZ3JlZSB0 aGF0IHRoZSByYW5nZSBwcm9wZXJ0eSBzaG91bGQgbm90IGJlIHJlcXVpcmVkLCBidXQgYWxzbyB0 aGUKPj4+IHJlZyB2YWx1ZXMgbmVlZCB0byBiZSBjaGFuZ2VkIChkcm9wIHRoZSB0b3AgYml0KS4g SWYgdGhlIGxhdGVyLCB0aGVuIHRoZQo+Pj4gcmFuZ2VzIHByb3BlcnR5IGlzIHJlcXVpcmVkIHRv IGRvIHRoZSBwcm9wZXIgdHJhbnNsYXRpb24uCj4+Cj4+IFRoZSBmb3JtZXIsIHRoYW5rcy4KPj4K Pj4+Cj4+PiBSb25ncm9uZywgcmVtb3ZpbmcgdGhlIHJhbmdlcyBwcm9wZXJ0eSBhbmQgd2l0aCBh IHJlZyA9IDwweGU0IDB4ND4gcHJvcGVydHkKPj4+IGluIHRoZSBpcG1pLWJ0IG5vZGUsIHdoYXQg SU9fUkVTT1VSQ0UgdHlwZSByZXNvdXJjZXMgZG8geW91IGdldCBiYWNrIGZyb20KPj4+IHRoZSBv Zl9hZGRyZXNzX3RvX3Jlc291cmNlKCkgdHJhbnNsYXRpb24/Cj4+Cj4+IEkgd2FudCB0byBnZXQg SU9SRVNPVVJDRV9JTyB0eXBlIHJlc291cmNlLCBidXQgaWYgdGhlIHBhcmVudCBub2RlIGRyb3Ag dGhlCj4+ICJyYW5ncyIgcHJvcGVydHksIHRoZSBvZl9hZGRyZXNzX3RvX3Jlc291cmNlKCkgdHJh bnNsYXRpb24gd2lsbCByZXR1cm4gd2l0aCAtRUlOVkFMLgo+Cj4gSGF2ZSB5b3UgdHJhY2tlZCB3 aGF0IHBhcnQgb2YgdGhlIGNvZGUgaXMgc2Vuc2l0aXZlIHRvIHRoZSBwcmVzZW5jZSBvZiAicmFu Z2VzIgo+IHByb3BlcnR5PyBEb2VzIG9mX2dldF9hZGRyZXNzKCkgY2FsbCByZXR1cm5zIHRoZSBJ T19SRVNPVVJDRSBmbGFnIHNldCB3aXRob3V0ICJyYW5nZXMiPwo+CgoKWWVzLCBJT19SRVNPVVJD RSBmbGFnIGNhbiBiZSBnZXQgd2l0aG91dCAicmFuZ2VzIi4KSSB0cmFja2VkIHRoZSBjb2RlLCBp dCBpcyBhdCBvZl90cmFuc2xhdGVfb25lKCksIEJlbG93IGlzIHRoZSBjYWxsaW5nIGluZm9tYXRp b24uCgpvZl9hZGRyZXNzX3RvX3Jlc291cmNlLT4gX19vZl9hZGRyZXNzX3RvX3Jlc291cmNlIC0+ b2ZfdHJhbnNsYXRlX2FkZHJlc3MtPgpfX29mX3RyYW5zbGF0ZV9hZGRyZXNzKGRldiwgaW5fYWRk ciwgInJhbmdlcyIpLT5vZl90cmFuc2xhdGVfb25lKCkKCgpzdGF0aWMgaW50IG9mX3RyYW5zbGF0 ZV9vbmUoc3RydWN0IGRldmljZV9ub2RlICpwYXJlbnQsIHN0cnVjdCBvZl9idXMgKmJ1cywKCQkJ ICAgIHN0cnVjdCBvZl9idXMgKnBidXMsIF9fYmUzMiAqYWRkciwKCQkJICAgIGludCBuYSwgaW50 IG5zLCBpbnQgcG5hLCBjb25zdCBjaGFyICpycHJvcCkKewoJY29uc3QgX19iZTMyICpyYW5nZXM7 Cgl1bnNpZ25lZCBpbnQgcmxlbjsKCWludCByb25lOwoJdTY0IG9mZnNldCA9IE9GX0JBRF9BRERS OwoKCXJhbmdlcyA9IG9mX2dldF9wcm9wZXJ0eShwYXJlbnQsIHJwcm9wLCAmcmxlbik7CglpZiAo cmFuZ2VzID09IE5VTEwgJiYgIW9mX2VtcHR5X3Jhbmdlc19xdWlyayhwYXJlbnQpKSB7CgkJcHJf ZGVidWcoIk9GOiBubyByYW5nZXM7IGNhbm5vdCB0cmFuc2xhdGVcbiIpOwoJCXJldHVybiAxOwoJ fQoJLi4uCn0KCj4gQmVzdCByZWdhcmRzLAo+IExpdml1Cj4KPj4KPj4+Cj4+PiBCZXN0IHJlZ2Fy ZHMsCj4+PiBMaXZpdQo+Pj4KPj4+Cj4+Pj4KPj4+PiAJQXJuZAo+Pj4+Cj4+Pgo+PiBSZWdhcmRz LAo+PiBSb25ncm9uZwo+Pgo+Ci0tIApSZWdhcmRzLApSb25ncm9uZwoKX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbGludXgtYXJtLWtlcm5lbCBtYWlsaW5n IGxpc3QKbGludXgtYXJtLWtlcm5lbEBsaXN0cy5pbmZyYWRlYWQub3JnCmh0dHA6Ly9saXN0cy5p bmZyYWRlYWQub3JnL21haWxtYW4vbGlzdGluZm8vbGludXgtYXJtLWtlcm5lbAo= From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934671AbcALJ1s (ORCPT ); Tue, 12 Jan 2016 04:27:48 -0500 Received: from szxga03-in.huawei.com ([119.145.14.66]:26649 "EHLO szxga03-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932750AbcALJ1J (ORCPT ); Tue, 12 Jan 2016 04:27:09 -0500 Subject: Re: [PATCH v1 3/3] ARM64 LPC: update binding doc To: , Rongrong Zou References: <1451396032-23708-1-git-send-email-zourongrong@gmail.com> <568912EE.9030009@huawei.com> <15026471.7nGZ0rWlIf@wuerfel> <20160111161415.GM13633@e106497-lin.cambridge.arm.com> <56946768.7090805@gmail.com> <20160112090722.GN13633@e106497-lin.cambridge.arm.com> CC: Arnd Bergmann , , , , Corey Minyard , , Will Deacon , , , Catalin Marinas From: Rongrong Zou Message-ID: <5694C6A4.8060308@huawei.com> Date: Tue, 12 Jan 2016 17:25:56 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20160112090722.GN13633@e106497-lin.cambridge.arm.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.177.30.66] X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.5694C6B6.0001,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0, ip=0.0.0.0, so=2013-05-26 15:14:31, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: c8e66213a399bda3cc683539489bdf65 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 在 2016/1/12 17:07, liviu.dudau@arm.com 写道: > On Tue, Jan 12, 2016 at 10:39:36AM +0800, Rongrong Zou wrote: >> On 2016/1/12 0:14, liviu.dudau@arm.com wrote: >>> On Mon, Jan 04, 2016 at 12:13:05PM +0100, Arnd Bergmann wrote: >>>> On Sunday 03 January 2016 20:24:14 Rongrong Zou wrote: >>>>> 在 2015/12/31 23:00, Rongrong Zou 写道: >>>>>> 2015-12-31 22:40 GMT+08:00 Arnd Bergmann >: >>>>>> > On Thursday 31 December 2015 22:12:19 Rongrong Zou wrote: >>>>>> > > 在 2015/12/30 17:06, Arnd Bergmann 写道: >>>>>> > > > On Tuesday 29 December 2015 21:33:52 Rongrong Zou wrote: >>>>>> > >>>>>> > The DT sample above looks good in principle. I believe what you are missing >>>>>> > here is code in your driver to scan the child nodes to create the platform >>>>>> > devices. of_bus_isa_translate() should work with your definition here >>>>>> > and create the correct IORESOURCE_IO resources. You don't have any MMIO >>>>>> > resources, so the absence of a ranges property is ok. Maybe all you >>>>>> > are missing is a call to of_platform_populate() or of_platform_bus_probe()? >>>>>> > >>>>>> >>>>>> You are right. thanks, i'll try on test board . if i get the correct result , the new patch >>>>>> will be sent later. By the way, it's my another email account use when i at home. >>>>> >>>>> I tried, and there need some additional changes. >>>>> >>>>> isa@a01b0000 { >>>>> >>>>> /*the node name should start with "isa", because of below definition >>>>> * static int of_bus_isa_match(struct device_node *np) >>>>> * { >>>>> * return !strcmp(np->name, "isa"); >>>>> * } >>>> >>>> Looks good. It would be nicer to match on device_type than on name, >>>> but this is ancient code and it's probably best not to touch it >>>> so we don't accidentally break some old SPARC or PPC system. >>>> >>>>> */ >>>>> compatible = "low-pin-count"; >>>>> device_type = "isa"; >>>>> #address-cells = <2>; >>>>> #size-cells = <1>; >>>>> reg = <0x0 0xa01b0000 0x0 0x10000>; >>>>> ranges = <0x1 0x0 0x0 0x0 0x1000>; >>>>> /* >>>>> * ranges is required, then i can get the IORESOURCE_IO <0xe4,4> from "reg = <0x1, 0x000000e4, 4>". >>>>> * >>>>> */ >>>>> ipmi_0:ipmi@000000e4{ >>>>> device_type = "ipmi"; >>>>> compatible = "ipmi-bt"; >>>>> reg = <0x1 0x000000e4 0x4>; >>>>> }; >>>>> >>>> >>>> This looks wrong: the property above says that the I/O port range is >>>> translated to MMIO address 0x00000000 to 0x00010000, which is not >>>> true on your hardware. I think this needs to be changed in the code >>>> so the ranges property is not required for I/O ports. >>>> >>>>> drivers\of\address.c >>>>> static int __of_address_to_resource(struct device_node *dev, >>>>> const __be32 *addrp, u64 size, unsigned int flags, >>>>> const char *name, struct resource *r) >>>>> { >>>>> u64 taddr; >>>>> >>>>> if ((flags & (IORESOURCE_IO | IORESOURCE_MEM)) == 0) >>>>> return -EINVAL; >>>>> taddr = of_translate_address(dev, addrp); >>>>> if (taddr == OF_BAD_ADDR) >>>>> return -EINVAL; >>>>> memset(r, 0, sizeof(struct resource)); >>>>> if (flags & IORESOURCE_IO) { >>>>> unsigned long port; >>>>> >>>>> /*****************************************************************/ >>>>> /*legacy port(< 0x1000) is reserved, and need no translation here*/ >>>>> /*****************************************************************/ >>>>> if(taddr + size < PCIBIOS_MIN_IO){ >>>>> r->start = taddr; >>>>> r->end = taddr + size - 1; >>>>> } >>>> >>>> I don't like having a special case based on the address here, >>>> the same kind of hack might be needed for PCI I/O spaces in >>>> hardware that uses an indirect method like your LPC bus >>>> does, and the code above will not work on any LPC implementation >>>> that correctly multiplexes its I/O ports with the first PCI domain. >>>> >>>> I think it would be better to avoid translating the port into >>>> a physical address to start with just to translate it back into >>>> a port number, what we need instead is the offset between the >>>> bus specific port number and the linux port number. I've added >>>> Liviu to Cc, he wrote this code originally and may have some idea >>>> of how we could do that. >>> >>> Hi, >> >> Hi Liviu, >> >> Thanks for reviewing this. >> >>> >>> Getting back to work after a longer holiday, my brain might not be running >>> at full speed here, so I'm trying to clarify things a bit here. >>> >>> It looks to me like Rongrong is trying to trap the inb()/outb() calls that he >>> added to arm64 by patch 1/3 and redirect those operations to the memory >>> mapped LPC driver. I think the whole redirection and registration of inb/outb >>> ops can be made cleaner, so that the general concept resembles the DMA ops >>> registration? (I have this mental picture that what Rongrong is trying to do >>> is similar to what a DMA engine does, except this is slowing down things to >>> byte level). If that is done properly in the parent node, then we should not >>> care what the PCIBIOS_MIN_IO value is as the inb()/outb() calls will always >>> go through the redirection for the children. >>> >>> As for the ranges property: does he wants the ipmi-bt driver to see in the >>> reg property the legacy ISA I/O ports values or the CPU addresses? If the former, >>> then I agree that the range property should not be required, but also the >>> reg values need to be changed (drop the top bit). If the later, then the >>> ranges property is required to do the proper translation. >> >> The former, thanks. >> >>> >>> Rongrong, removing the ranges property and with a reg = <0xe4 0x4> property >>> in the ipmi-bt node, what IO_RESOURCE type resources do you get back from >>> the of_address_to_resource() translation? >> >> I want to get IORESOURCE_IO type resource, but if the parent node drop the >> "rangs" property, the of_address_to_resource() translation will return with -EINVAL. > > Have you tracked what part of the code is sensitive to the presence of "ranges" > property? Does of_get_address() call returns the IO_RESOURCE flag set without "ranges"? > Yes, IO_RESOURCE flag can be get without "ranges". I tracked the code, it is at of_translate_one(), Below is the calling infomation. of_address_to_resource-> __of_address_to_resource ->of_translate_address-> __of_translate_address(dev, in_addr, "ranges")->of_translate_one() static int of_translate_one(struct device_node *parent, struct of_bus *bus, struct of_bus *pbus, __be32 *addr, int na, int ns, int pna, const char *rprop) { const __be32 *ranges; unsigned int rlen; int rone; u64 offset = OF_BAD_ADDR; ranges = of_get_property(parent, rprop, &rlen); if (ranges == NULL && !of_empty_ranges_quirk(parent)) { pr_debug("OF: no ranges; cannot translate\n"); return 1; } ... } > Best regards, > Liviu > >> >>> >>> Best regards, >>> Liviu >>> >>> >>>> >>>> Arnd >>>> >>> >> Regards, >> Rongrong >> > -- Regards, Rongrong