From: Sinan Kaya <okaya@codeaurora.org>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
linux-pci@vger.kernel.org, Zhou Wang <wangzhou1@hisilicon.com>,
Phil Edworthy <phil.edworthy@renesas.com>,
Bjorn Helgaas <bhelgaas@google.com>
Subject: Re: [RFC] ARM/ARM64 PCI_PROBE_ONLY platforms
Date: Fri, 29 Jan 2016 19:14:29 -0500 [thread overview]
Message-ID: <56AC0065.5030909@codeaurora.org> (raw)
In-Reply-To: <20160129230645.GG12965@localhost>
On 1/29/2016 6:06 PM, Bjorn Helgaas wrote:
> On Wed, Jan 20, 2016 at 11:13:04AM -0500, Sinan Kaya wrote:
>> On 1/20/2016 11:04 AM, Lorenzo Pieralisi wrote:
>>>
>>> We want to get rid of PCI_PROBE_ONLY on ARM/ARM64:
>>
>> For platforms that does not have UEFI BIOS, it makes sense to remove the probe only
>> option as the firmware is not doing anything.
>
> I don't understand this statement. It sounds like you mean "non-UEFI
> BIOS firmware doesn't assign PCI BARs", but that's not true, so you
> must mean something else.
It depends on the firmware flavor. I know u-boot does some PCI assignment but it does minimum
to use PCI itself not for OS consumption. It may not deal with with switches/bridges etc. or
will only assign mem32 resources and not touch prefetchable.
Most non-UEFI firmwares I have seen on ARM rely on device specific driver
like synopsys etc. to do the device initialization and ask kernel to do the enumeration.
ACPI systems on the other hand handle the resource assignment before the OS starts.
>
>> For server like arm64 platforms, the behavior should be identical to
>> x86 world.
>
>> The UEFI BIOS sets up the resources, kernel uses the resources.
>
> Is there actually a requirement that a UEFI BIOS assign resources to
> PCI BARs? I know that historically, x86 BIOS has set up most or all
> PCI BARs. But I thought there was something in UEFI that relaxed
> that, so it would only have to program BARs for the boot and console
> devices it actually needed. But I can't find a spec reference either
> way.
I don't have a spec reference. This statement was purely out of x86 experience not based on some
spec. We are trying to follow the PC model.
>
> Bjorn
> --
> 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
>
--
Sinan Kaya
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
next prev parent reply other threads:[~2016-01-30 0:14 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-20 16:04 [RFC] ARM/ARM64 PCI_PROBE_ONLY platforms Lorenzo Pieralisi
2016-01-20 16:13 ` Sinan Kaya
2016-01-20 18:10 ` Lorenzo Pieralisi
2016-01-20 18:15 ` Sinan Kaya
2016-01-29 23:26 ` Bjorn Helgaas
2016-01-22 16:28 ` Phil Edworthy
2016-01-25 17:51 ` Lorenzo Pieralisi
2016-01-28 17:27 ` Lorenzo Pieralisi
2016-01-29 12:02 ` Gabriele Paoloni
2016-01-29 6:32 ` Pratyush Anand
2016-01-29 23:25 ` Bjorn Helgaas
2016-02-01 16:28 ` Lorenzo Pieralisi
2016-02-01 21:19 ` Bjorn Helgaas
2016-01-29 23:06 ` Bjorn Helgaas
2016-01-30 0:14 ` Sinan Kaya [this message]
2016-01-30 13:30 ` Bjorn Helgaas
2016-01-30 17:51 ` Okaya
2016-02-01 15:25 ` Lorenzo Pieralisi
2016-02-01 21:12 ` Bjorn Helgaas
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=56AC0065.5030909@codeaurora.org \
--to=okaya@codeaurora.org \
--cc=bhelgaas@google.com \
--cc=helgaas@kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lorenzo.pieralisi@arm.com \
--cc=phil.edworthy@renesas.com \
--cc=wangzhou1@hisilicon.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: link
Be 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).