From: Yijing Wang <wangyijing@huawei.com> To: Liviu Dudau <Liviu.Dudau@arm.com> Cc: Catalin Marinas <Catalin.Marinas@arm.com>, linux-pci <linux-pci@vger.kernel.org>, Linus Walleij <linus.walleij@linaro.org>, Will Deacon <Will.Deacon@arm.com>, Grant Likely <grant.likely@secretlab.ca>, Tanmay Inamdar <tinamdar@apm.com>, linux-arch <linux-arch@vger.kernel.org>, Kukjin Kim <kgene.kim@samsung.com>, Russell King <linux@arm.linux.org.uk>, Jingoo Han <jg1.han@samsung.com>, Jason Gunthorpe <jgunthorpe@obsidianresearch.com>, Benjamin Herrenschmidt <benh@kernel.crashing.org>, "grant.likely@linaro.org" <grant.likely@linaro.org>, Device Tree ML <devicetree@vger.kernel.org>, Arnd Bergmann <arnd@arndb.de>, Rob Herring <robh+dt@kernel.org>, Bjorn Helgaas <bhelgaas@google.com>, LAKML <linux-arm-kernel@lists.infradead.org>, Sinan Kaya <okaya@codeaurora.org>, LKML <linux-kernel@vger.kernel.org>, Suravee Suthikulanit <suravee.suthikulpanit@amd.com> Subject: Re: [PATCH v10 07/10] OF: Introduce helper function for getting PCI domain_nr Date: Wed, 10 Sep 2014 09:44:51 +0800 [thread overview] Message-ID: <540FAD13.9030502@huawei.com> (raw) In-Reply-To: <20140909141122.GY27864@e106497-lin.cambridge.arm.com> >> OK. Sorry, I have one last question, because domain will be used to calculate the address used to >> access PCI hardware config registers. So if DTS file doesn't report the domain, how do we know >> we would access the right registers when we use the auto increment domain vaule ? > > That's a good question and sides with Arnd's suggestion to try to mandate the presence of the PCI > domain in the DTS. However, by grepping through the source code, it looks like the architectures > that use the domain number for reading config registers (x86-based) are non-DT architectures, > while DT-aware arches seem to ignore the domain number except when printing out messages. Is that > another confirmation that most DT-aware architectures have only run with domain_nr = 0? > Arnd's suggestion is make sense to me, thanks for Bjorn's detailed explanation, now I know domain_nr is purely internal to kernel in DT-aware platform, it's not needed when access PCI config space. Thanks! Yijing. > >> Has there a mechanism to make sure system can access the correct registers by the domain ? > > Not as such if you look with x86 glasses. With the exception of powerpc all other architecures > seem to happily assume domain_nr = 0 and ignore it in the computation of configuration registers > offsets. > > Best regards, > Liviu > >> >> Thanks! >> Yijing. >> >>> >>> Best regards, >>> Liviu >>> >>>> >>>> PCI get domain by ACPI "_SEG" in IA64(drivers/acpi/pci_root.c) >>>> ...... >>>> status = acpi_evaluate_integer(handle, METHOD_NAME__SEG, NULL, >>>> &segment); >>>> if (ACPI_FAILURE(status) && status != AE_NOT_FOUND) { >>>> dev_err(&device->dev, "can't evaluate _SEG\n"); >>>> result = -ENODEV; >>>> goto end; >>>> } >>>> ....... >>>> >>>> Thanks! >>>> Yijing. >>>> >>>>> >>>>>> This function >>>>>> is just a weird mixture of data retrieval and allocation. I think you >>>>>> need to separate it into 2 functions. >>>>> >>>>> It is meant to do allocation with the retrieval being a short-cut (or fine >>>>> control if you want). >>>>> >>>>> I need to think a bit more for a better solution. >>>>> >>>>> Best regards, >>>>> Liviu >>>>> >>>>>> >>>>>> Rob >>>>>> >>>>> >>>> >>>> >>>> -- >>>> Thanks! >>>> Yijing >>>> >>>> >>> >> >> >> -- >> Thanks! >> Yijing >> >> -- >> 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 >> > -- Thanks! Yijing
WARNING: multiple messages have this Message-ID (diff)
From: Yijing Wang <wangyijing@huawei.com> To: Liviu Dudau <Liviu.Dudau@arm.com> Cc: Rob Herring <robherring2@gmail.com>, Bjorn Helgaas <bhelgaas@google.com>, Arnd Bergmann <arnd@arndb.de>, Rob Herring <robh+dt@kernel.org>, Jason Gunthorpe <jgunthorpe@obsidianresearch.com>, Benjamin Herrenschmidt <benh@kernel.crashing.org>, Catalin Marinas <Catalin.Marinas@arm.com>, Will Deacon <Will.Deacon@arm.com>, Russell King <linux@arm.linux.org.uk>, linux-pci <linux-pci@vger.kernel.org>, Linus Walleij <linus.walleij@linaro.org>, Tanmay Inamdar <tinamdar@apm.com>, Grant Likely <grant.likely@secretlab.ca>, Sinan Kaya <okaya@codeaurora.org>, Jingoo Han <jg1.han@samsung.com>, Kukjin Kim <kgene.kim@samsung.com>, Suravee Suthikulanit <suravee.suthikulpanit@amd.com>, linux-arch <linux-arch@vger.kernel.org>, LKML <linux-kernel@vger.kernel.org>, Device Tree ML <devicetree@vger.kernel.org>, LAKML <linux-arm-kernel@lists.infradead.org>, "grant.likely@linaro.org" <grant.likely@linaro.org> Subject: Re: [PATCH v10 07/10] OF: Introduce helper function for getting PCI domain_nr Date: Wed, 10 Sep 2014 09:44:51 +0800 [thread overview] Message-ID: <540FAD13.9030502@huawei.com> (raw) Message-ID: <20140910014451.FKRjjbBpI7h7D0AD-1lh68pG-ESuFaPVvRqlkUeKT9w@z> (raw) In-Reply-To: <20140909141122.GY27864@e106497-lin.cambridge.arm.com> >> OK. Sorry, I have one last question, because domain will be used to calculate the address used to >> access PCI hardware config registers. So if DTS file doesn't report the domain, how do we know >> we would access the right registers when we use the auto increment domain vaule ? > > That's a good question and sides with Arnd's suggestion to try to mandate the presence of the PCI > domain in the DTS. However, by grepping through the source code, it looks like the architectures > that use the domain number for reading config registers (x86-based) are non-DT architectures, > while DT-aware arches seem to ignore the domain number except when printing out messages. Is that > another confirmation that most DT-aware architectures have only run with domain_nr = 0? > Arnd's suggestion is make sense to me, thanks for Bjorn's detailed explanation, now I know domain_nr is purely internal to kernel in DT-aware platform, it's not needed when access PCI config space. Thanks! Yijing. > >> Has there a mechanism to make sure system can access the correct registers by the domain ? > > Not as such if you look with x86 glasses. With the exception of powerpc all other architecures > seem to happily assume domain_nr = 0 and ignore it in the computation of configuration registers > offsets. > > Best regards, > Liviu > >> >> Thanks! >> Yijing. >> >>> >>> Best regards, >>> Liviu >>> >>>> >>>> PCI get domain by ACPI "_SEG" in IA64(drivers/acpi/pci_root.c) >>>> ...... >>>> status = acpi_evaluate_integer(handle, METHOD_NAME__SEG, NULL, >>>> &segment); >>>> if (ACPI_FAILURE(status) && status != AE_NOT_FOUND) { >>>> dev_err(&device->dev, "can't evaluate _SEG\n"); >>>> result = -ENODEV; >>>> goto end; >>>> } >>>> ....... >>>> >>>> Thanks! >>>> Yijing. >>>> >>>>> >>>>>> This function >>>>>> is just a weird mixture of data retrieval and allocation. I think you >>>>>> need to separate it into 2 functions. >>>>> >>>>> It is meant to do allocation with the retrieval being a short-cut (or fine >>>>> control if you want). >>>>> >>>>> I need to think a bit more for a better solution. >>>>> >>>>> Best regards, >>>>> Liviu >>>>> >>>>>> >>>>>> Rob >>>>>> >>>>> >>>> >>>> >>>> -- >>>> Thanks! >>>> Yijing >>>> >>>> >>> >> >> >> -- >> Thanks! >> Yijing >> >> -- >> 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 >> > -- Thanks! Yijing
next prev parent reply other threads:[~2014-09-10 1:44 UTC|newest] Thread overview: 90+ messages / expand[flat|nested] mbox.gz Atom feed top 2014-09-08 13:54 [PATCH v10 00/10] Support for creating generic PCI host bridges from DT Liviu Dudau 2014-09-08 13:54 ` Liviu Dudau 2014-09-08 13:54 ` [PATCH v10 01/10] Fix ioport_map() for !CONFIG_GENERIC_IOMAP cases Liviu Dudau 2014-09-08 13:54 ` Liviu Dudau 2014-09-08 13:54 ` [PATCH v10 02/10] PCI: Introduce helper functions to deal with PCI I/O ranges Liviu Dudau 2014-09-08 13:54 ` Liviu Dudau 2014-09-08 13:54 ` [PATCH v10 03/10] ARM: Define PCI_IOBASE as the base of virtual PCI IO space Liviu Dudau 2014-09-08 13:54 ` Liviu Dudau 2014-09-08 13:54 ` [PATCH v10 04/10] PCI: OF: Fix the conversion of IO ranges into IO resources Liviu Dudau 2014-09-08 13:54 ` Liviu Dudau 2014-09-08 13:54 ` [PATCH v10 05/10] PCI: Create pci_host_bridge before its associated bus in pci_create_root_bus Liviu Dudau 2014-09-08 13:54 ` Liviu Dudau 2014-09-08 13:54 ` [PATCH v10 06/10] PCI: Introduce generic domain handling for PCI busses Liviu Dudau 2014-09-08 13:54 ` Liviu Dudau 2014-09-08 14:03 ` Catalin Marinas 2014-09-08 14:03 ` Catalin Marinas 2014-09-08 14:05 ` Liviu Dudau 2014-09-08 14:05 ` Liviu Dudau 2014-09-08 13:54 ` [PATCH v10 07/10] OF: Introduce helper function for getting PCI domain_nr Liviu Dudau 2014-09-08 13:54 ` Liviu Dudau 2014-09-08 14:27 ` Rob Herring 2014-09-08 14:27 ` Rob Herring 2014-09-08 14:54 ` Liviu Dudau 2014-09-08 15:27 ` Rob Herring 2014-09-08 15:59 ` Liviu Dudau 2014-09-08 16:39 ` Jason Gunthorpe 2014-09-09 5:54 ` Yijing Wang 2014-09-09 8:46 ` Liviu Dudau 2014-09-09 8:46 ` Liviu Dudau [not found] ` <20140909084621.GS27864-2JSQmVVBSi7ZROr8t4l/smS4ubULX0JqMm0uRHvK7Nw@public.gmane.org> 2014-09-09 9:16 ` Arnd Bergmann 2014-09-09 9:16 ` Arnd Bergmann 2014-09-09 11:20 ` Catalin Marinas 2014-09-09 11:20 ` Catalin Marinas 2014-09-10 18:19 ` Arnd Bergmann 2014-09-10 18:19 ` Arnd Bergmann 2014-09-11 14:11 ` Phil Edworthy 2014-09-11 14:11 ` Phil Edworthy 2014-09-11 14:49 ` Arnd Bergmann 2014-09-11 14:49 ` Arnd Bergmann 2014-09-09 14:17 ` Bjorn Helgaas 2014-09-09 14:17 ` Bjorn Helgaas 2014-09-09 9:30 ` Yijing Wang 2014-09-09 9:30 ` Yijing Wang 2014-09-09 14:11 ` Liviu Dudau 2014-09-09 14:11 ` Liviu Dudau 2014-09-10 1:44 ` Yijing Wang [this message] 2014-09-10 1:44 ` Yijing Wang 2014-09-09 14:26 ` Bjorn Helgaas 2014-09-09 14:26 ` Bjorn Helgaas 2014-09-09 15:41 ` Jason Gunthorpe 2014-09-09 15:41 ` Jason Gunthorpe 2014-09-10 2:44 ` Rob Herring 2014-09-10 2:44 ` Rob Herring 2014-09-10 16:32 ` Jason Gunthorpe 2014-09-10 16:32 ` Jason Gunthorpe 2014-09-10 1:55 ` Yijing Wang 2014-09-10 1:55 ` Yijing Wang 2014-09-10 13:04 ` Liviu Dudau 2014-09-10 13:04 ` Liviu Dudau 2014-09-08 13:54 ` [PATCH v10 08/10] OF: PCI: Add support for parsing PCI host bridge resources from DT Liviu Dudau 2014-09-08 13:54 ` Liviu Dudau 2014-09-09 13:35 ` Lorenzo Pieralisi 2014-09-09 13:35 ` Lorenzo Pieralisi 2014-09-10 14:22 ` Liviu Dudau 2014-09-10 14:22 ` Liviu Dudau 2014-09-10 15:10 ` Lorenzo Pieralisi 2014-09-10 15:10 ` Lorenzo Pieralisi 2014-09-10 15:32 ` Liviu Dudau 2014-09-10 15:32 ` Liviu Dudau 2014-09-10 16:37 ` Lorenzo Pieralisi 2014-09-10 16:37 ` Lorenzo Pieralisi [not found] ` <20140910163746.GB19662-7AyDDHkRsp3ZROr8t4l/smS4ubULX0JqMm0uRHvK7Nw@public.gmane.org> 2014-09-10 16:53 ` Liviu Dudau 2014-09-10 16:53 ` Liviu Dudau 2014-09-10 17:06 ` Lorenzo Pieralisi 2014-09-10 17:06 ` Lorenzo Pieralisi 2014-09-08 13:54 ` [PATCH v10 09/10] PCI: Assign unassigned bus resources in pci_scan_root_bus() Liviu Dudau 2014-09-08 13:54 ` Liviu Dudau 2014-09-12 10:13 ` Suravee Suthikulpanit 2014-09-12 10:13 ` Suravee Suthikulpanit 2014-09-12 10:34 ` Liviu Dudau 2014-09-08 13:54 ` [PATCH v10 10/10] PCI: Introduce pci_remap_iospace() for remapping PCI I/O bus resources into CPU space Liviu Dudau 2014-09-08 13:54 ` Liviu Dudau [not found] ` <1410184472-17630-1-git-send-email-Liviu.Dudau-5wv7dgnIgG8@public.gmane.org> 2014-09-08 16:07 ` [PATCH v10 00/10] Support for creating generic PCI host bridges from DT Liviu Dudau 2014-09-08 16:07 ` Liviu Dudau 2014-09-12 8:25 ` Suravee Suthikulpanit 2014-09-12 8:25 ` Suravee Suthikulpanit 2014-09-12 9:30 ` Liviu Dudau 2014-09-12 9:30 ` Liviu Dudau 2014-09-12 10:00 ` Suravee Suthikulpanit 2014-09-12 10:00 ` Suravee Suthikulpanit
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=540FAD13.9030502@huawei.com \ --to=wangyijing@huawei.com \ --cc=Catalin.Marinas@arm.com \ --cc=Liviu.Dudau@arm.com \ --cc=Will.Deacon@arm.com \ --cc=arnd@arndb.de \ --cc=benh@kernel.crashing.org \ --cc=bhelgaas@google.com \ --cc=devicetree@vger.kernel.org \ --cc=grant.likely@linaro.org \ --cc=grant.likely@secretlab.ca \ --cc=jg1.han@samsung.com \ --cc=jgunthorpe@obsidianresearch.com \ --cc=kgene.kim@samsung.com \ --cc=linus.walleij@linaro.org \ --cc=linux-arch@vger.kernel.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-pci@vger.kernel.org \ --cc=linux@arm.linux.org.uk \ --cc=okaya@codeaurora.org \ --cc=robh+dt@kernel.org \ --cc=suravee.suthikulpanit@amd.com \ --cc=tinamdar@apm.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).