From: Haicheng Li <haicheng.li@linux.intel.com>
To: Bjorn Helgaas <bhelgaas@google.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Haicheng Li <haicheng.lee@gmail.com>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>
Subject: Re: [PATCH 1/3] PCI: Add hide_device support to pci subsystem.
Date: Thu, 4 Jul 2013 12:53:16 +0800 [thread overview]
Message-ID: <20130704045316.GC3244@hli22-desktop> (raw)
In-Reply-To: <CAErSpo5dR_2tUDFoFO49N3Ut569+6Cfosx8Q=91U_w-8mvFVkg@mail.gmail.com>
On Wed, Jul 03, 2013 at 10:09:32AM -0600, Bjorn Helgaas wrote:
> On Wed, Jul 3, 2013 at 9:16 AM, Haicheng Li <haicheng.li@linux.intel.com> wrote:
> > With more and more SOCs having pci device integrated into chip (e.g. Intel
> > Atom series), it's useful to add an interface to cleanly hide pci devices from
> > pci device scanning, which is because:
> >
> > 1. phone or tablet OEMs may choose disabling some pci device in the SOC,
> > such as camera ISP in Intel Atom Z2580 chip, and etc.
> > 2. if such disabled devices are not cleanly removed from pci device tree,
> > then pci-core will still try to operate on the relative device control
> > registers while S3 suspend and resume.
> > 3. so hiding such devices from early begining will not only reduce the kernel
> > boot time, but also optimize the latency of system suspend and resume.
>
> Normally the chip provides a way to disable devices by writing a
> configuration register. Then the device doesn't respond when Linux
> enumerates devices, so nothing special is required in the kernel.
Agreed, this is true.
> What's different about the Z2580? I'd be surprised if Intel forgot to
> include such a register.
A pci shim faked by firmware was introduced to help easily port Linux onto Z2XXX
SOC chips, which enumerates both real and fake PCI devices inside the SOC (The camera ISP
I mentioned above is a real PCI device in this case)
A detailed tech talk about this technology by Jacob Pan in elc2010 can be found online
here: http://elinux.org/images/e/ee/Jacob-Pan-x86MID-elc2010.pdf
> Maybe the firmware just isn't smart enough
> to disable the device? If so, it would be better to fix the firmware
> than to add kludges in the kernel.
On PC or server, end-user/OEM can disable/hide a pci device easily thru BIOS setting or
by hacking BIOS code directly when they find some device is broken or useless.
However on phone or tablet equipment, there is no BIOS-setting alike UI exposed to end-user/developer
to disable broken device easily (and physically removing the device is not doable on Phone or tablet)
OTOH, this i/f is really *helpful* for kernel developer to power-on a new platform, debug system
problem, or to do performance tuning of suspend/resume. At least it makes my daily job easier:).
So if people are strongly against this, I would still suggest accept this i/f as a debug i/f
at least:).
> > To hide pci devices, just pass such parameters to kernel at boot stage:
> > pci=hide=[<domain>:]<bus>:<slot>.<func>[; ...]
next prev parent reply other threads:[~2013-07-04 4:53 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-03 15:16 [PATCH 1/3] PCI: Add hide_device support to pci subsystem Haicheng Li
2013-07-03 15:16 ` [PATCH 2/3] doc: add the description for pci=hide kernel parameter Haicheng Li
2013-07-03 16:00 ` Bjorn Helgaas
2013-07-04 2:22 ` Haicheng Li
2013-07-03 15:16 ` [PATCH 3/3] acpi: remove unused LIST_HEAD(acpi_device_list) Haicheng Li
2013-07-03 21:24 ` Rafael J. Wysocki
2013-07-04 2:27 ` Haicheng Li
2013-07-04 4:07 ` [PATCH] " Haicheng Li
2013-07-04 12:50 ` Rafael J. Wysocki
2013-07-03 16:09 ` [PATCH 1/3] PCI: Add hide_device support to pci subsystem Bjorn Helgaas
2013-07-03 16:41 ` Jiang Liu
2013-07-04 4:53 ` Haicheng Li [this message]
2013-07-05 17:28 ` Bjorn Helgaas
2013-07-09 14:22 ` Haicheng Li
2013-07-07 2:43 ` Jiang Liu
2013-07-09 14:21 ` Haicheng Li
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=20130704045316.GC3244@hli22-desktop \
--to=haicheng.li@linux.intel.com \
--cc=bhelgaas@google.com \
--cc=haicheng.lee@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
/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