From patchwork Sat Sep 24 08:00:37 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: zhichang X-Patchwork-Id: 9349123 X-Patchwork-Delegate: bhelgaas@google.com Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 613D8601C2 for ; Sat, 24 Sep 2016 08:00:17 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 46B2129FB5 for ; Sat, 24 Sep 2016 08:00:17 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 37B9229FC4; Sat, 24 Sep 2016 08:00:17 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=2.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED,FREEMAIL_FROM,RCVD_IN_DNSWL_HI,T_DKIM_INVALID autolearn=unavailable version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 8B61329FB5 for ; Sat, 24 Sep 2016 08:00:16 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757734AbcIXH7x (ORCPT ); Sat, 24 Sep 2016 03:59:53 -0400 Received: from mail-pa0-f68.google.com ([209.85.220.68]:35654 "EHLO mail-pa0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752017AbcIXH7v (ORCPT ); Sat, 24 Sep 2016 03:59:51 -0400 Received: by mail-pa0-f68.google.com with SMTP id gg10so621531pac.2; Sat, 24 Sep 2016 00:59:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=7S+Lc6MWdChsrZzEmoAK63TUK36954fjZQIlCutNRT4=; b=hmaS6uv+b4CI6gDVka6bCR1WPPKK/ro0vFQA3R5w4imbrFa0GLorkwPtMJEhP+pin3 rPuMi/8pGiUKNtKSsFV7xntpTwZGy/sVIsViddEvBRv/1C9ev+kZo5rWyb7dJS4xzhi0 7x2kc5eDK9y3JUeDJfWg8Lnreol/zTsdnp6Cnz51yhWlJ+c9sq8qd24PRtFkZtlTAeYH pRyd0lqRDiGBIV4bXDjcXMDMuvCLovVTZEaq1FSIX2X6t/9IGUTu9ZkGWLjQz+mXALI9 3MOW6MyhRymgkIfLnmF4ATlIPe5QY1Le2W5F6tRMm4j8W6x9PhGSWLdhR27AndmFYOV+ ZvKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=7S+Lc6MWdChsrZzEmoAK63TUK36954fjZQIlCutNRT4=; b=i0PgeMxB/2q7rylh13DD2P4p0pL+uJ2n7PHxGK2UZnQAG8n3UVJH4JWc9Owc2MSb// KBUZdvMidYCzrp4VKsn1XSOO7RYUB3BK/kSF8hkEqpsDpIMMcrsB0P8zQBD3NtKOkcjw KOjG8ZIdBrmNTMp12jagmp1i6qYZ8hKThDR/brSY3pk+78+FNJv+9O6o21525NfjMlND Tpk3/UzsimpRMcnLuiH3B3C9wTawUVLqGMfgoGMRUJjYCtoMwLwsmIVHoCoz55gNoD09 4HWYTDsIvo+g129hfFATlHgIQMKU9JOqAE3jMvP5U4384muNmGAow6dDcdfKNepr/0WH y0sw== X-Gm-Message-State: AE9vXwPP2nCuNsdJ8nycepMX/I1Ua19sllSLUWzSMPpU8BaGja0FY/aBqxKSfm56PBOUhA== X-Received: by 10.66.249.200 with SMTP id yw8mr19814198pac.13.1474703990963; Sat, 24 Sep 2016 00:59:50 -0700 (PDT) Received: from [192.168.201.126] ([58.251.159.252]) by smtp.gmail.com with ESMTPSA id f7sm16313504pfk.79.2016.09.24.00.59.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 24 Sep 2016 00:59:50 -0700 (PDT) Subject: Re: [PATCH V3 2/4] ARM64 LPC: LPC driver implementation on Hip06 To: Arnd Bergmann , "will.deacon@arm.com" , "liviu.dudau@arm.com" , bhelgaas@google.com References: <1473855354-150093-1-git-send-email-yuanzhichang@hisilicon.com> <9178320.n4yHmfyPA3@wuerfel> <57E40665.8080005@gmail.com> <1760643.vMTR5o5E9g@wuerfel> Cc: Gabriele Paoloni , "linux-arm-kernel@lists.infradead.org" , "devicetree@vger.kernel.org" , "lorenzo.pieralisi@arm.com" , "minyard@acm.org" , "linux-pci@vger.kernel.org" , "gregkh@linuxfoundation.org" , John Garry , "linux-kernel@vger.kernel.org" , Yuanzhichang , Linuxarm , "xuwei (O)" , "linux-serial@vger.kernel.org" , "benh@kernel.crashing.org" , "zourongrong@gmail.com" , "kantyzc@163.com" From: zhichang X-Enigmail-Draft-Status: N1110 Message-ID: <378cda2d-e8fb-af10-01ff-c555def3d639@gmail.com> Date: Sat, 24 Sep 2016 16:00:37 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <1760643.vMTR5o5E9g@wuerfel> Sender: linux-pci-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Hi, Arnd, On 2016年09月23日 17:51, Arnd Bergmann wrote: > On Friday, September 23, 2016 12:27:17 AM CEST zhichang.yuan wrote: >> For this patch sketch, I have a question. >> Do we call pci_address_to_pio in arch_of_address_to_pio to get the >> corresponding logical IO port >> for LPC?? > > > No, of course not, that would be silly: > > The argument to pci_address_to_pio() is a phys_addr_t, and we we don't > have one because there is no address associated with your PIO, that > is the entire point of your driver! > ok. I think I know you points. The physical addresses of LPC are only the LPC domain addresses, not the really CPU physical addresses. That is just why you don't support the ranges property usage in patch V3. Consequently, It is not so reasonable to call pci_address_to_pio() with LPC address because that function is only suitable for cpu physical address. But just as you said in the next email reply to Gabriele, "Any IORESOURCE_IO address always refers to the logical I/O port range in Linux, not the physical address that is used on a bus.", Any devices which support IO accesses should have their own unique logical IO range to drive the corresponding hardware. It means that the drivers should know the mapping between physical port/memory address and logical IO depend on the device specific I/O mode. At this moment, only PCI host bridge setup a logical IO range allocation mechanism to manipulate this logical IO range, and this way applies cpu physical address(memory) as the input. Now, our LPC also need subrange from this common logical IO range, but with legacy I/O port rather than CPU memory address. Ok, it break the precondition of pci_register_io_range/pci_pio_to_address, we should not use them directly for LPC although the calling of pci_pio_to_address is simple and less change on the relevant code. We had done like that in V3... So, the key issue is how to get a logical IO subrange which is not conflicted with others, such as pci host bridges?? I list several ideas for discussion: 1. reserve a specific logical IO subrange for LPC I describe this in "Note 1" below. Please check it. This way seems simple without much changes, but it is not generic. 2. setup a separate logical IO subrange allocation mechanism specific for LPC/ISA Just as your suggestion before, add the arch_of_address_to_pio() for the devices which operate I/O with legacy I/O port address rather than memory address in MMIO mode. That arch_of_address_to_pio() will return non-conflict logical IO with PCI host bridge at last. But the logical IO range is global, those functions for LPC/ISA specific logical IO subrange allocation must be synchronized with pci_register_io_range/pci_pio_to_address to know what logical ranges had been populated. It is not good for the implement dispersion on same issue. 3. setup a new underlying method to control the logical IO range management Based on the existing resource management, add a simplified logical IO range management support which only request the logical IO ranges according the IO range size ( similar to IORESOURCE_SIZEALIGN mode ), no matter what type the physical address is. Then revise the current pci_register_io_range to adopt this new method. Of-course, LPC/ISA request the logical IO with this new method too. This is just a proposition. It is more workload compared with other solutions. What do you think about these? Any more ideas? > Also, we already know the mapping because this is what the inb/outb > workaround is looking at, so there is absolutely no reason to call it > either. > >> If we don't, it seems the LPC specific IO address will conflict with PCI >> host bridges' logical IO. >> >> Supposed our LPC populated the IO range from 0x100 to 0x3FF( this is >> normal for ISA similar >> devices), after arch_of_address_to_pio(), the r->start will be set as >> 0x100, r->end will be set as >> 0x3FF. And if there is one PCI host bridge who request a IO window size >> over 0x400 at the same >> time, the corresponding r->start and r->end will be set as 0x0, 0x3FF >> after of_address_to_resource >> for this host bridge. Then the IO conflict happens. > > You would still need to reserve some space in the io_range_list > to avoid possible conflicts, which is a bit ugly with the current > definition of pci_register_io_range, but I'm sure can be done. > Note 1) Do you remember patch V2? There, I modified the pci.c like that to reserve 0 - PCIBIOS_MIN_IO (it is 0x1000) : Based on this, a exclusive logical IO subrange is for LPC now. Then we certainly can add some special handling in __of_address_to_resource or __of_translate_address --> of_translate_one to return the untranslated LPC/ISA IO address. But to be honest, I think we don't need this special handling in address.c anymore. We had known the LPC/ISA IO is 1:1 to logical IO, just think any logical IO port among 0 - 0x1000 should call the LPC registered I/O hooks in the new in/out(). Furthermore, we can make the reservation is not fixed as PCIBIOS_MIN_IO. If the LPC/ISA probing is run before PCI host bridge probing, we can reserve a non-fixed logcial IO subrange what LPC/ISA ask for. This solution is based on an assumption that no any other devices have to request the specific logical IO subrange for LPC/ISA. Probably this assumption is ok on arm64, you known, there is no real IO space as X86. But anyway, this reservation is not so generic, depended on some special handling. Does this idea match your comments?? > One way I can think of would be to change pci_register_io_range() > to just return the logical port number directly (it already > knows it!), and pass an invalid physical address (e.g. > #define ISA_WORKAROUND_IO_PORT_WINDOW -0x10000) into it for > invalid translations. > I am not so clear know your idea here. Do you want to select an unpopulated CPU address as the parent address in range property?? or anything else??? > Another alternative that just occurred to me would be to move > the pci_address_to_pio() call from __of_address_to_resource() > into of_bus_pci_translate() and then do the special handling > for the ISA/LPC bus in of_bus_isa_translate(). As for this idea, do you mean that of_translate_address will directly return the final logical IO start address?? It seems to extend the definition of of_translate_address. Thanks, Zhichang > > Arnd > --- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c index aab9d51..ac2e569 100644 --- a/drivers/pci/pci.c +++ b/drivers/pci/pci.c @@ -3221,7 +3221,7 @@ int __weak pci_register_io_range(phys_addr_t addr, resourc #ifdef PCI_IOBASE struct io_range *range; - resource_size_t allocated_size = 0; + resource_size_t allocated_size = PCIBIOS_MIN_IO; /* check if the range hasn't been previously recorded */ spin_lock(&io_range_lock); @@ -3270,7 +3270,7 @@ phys_addr_t pci_pio_to_address(unsigned long pio) #ifdef PCI_IOBASE struct io_range *range; - resource_size_t allocated_size = 0; + resource_size_t allocated_size = PCIBIOS_MIN_IO; if (pio > IO_SPACE_LIMIT) return address; @@ -3293,7 +3293,7 @@ unsigned long __weak pci_address_to_pio(phys_addr_t addres { #ifdef PCI_IOBASE struct io_range *res; - resource_size_t offset = 0; + resource_size_t offset = PCIBIOS_MIN_IO; unsigned long addr = -1; spin_lock(&io_range_lock);