With the previous patch applied pcibios_setup_device() will always be run
when pcibios_bus_add_device() is called. There are several code paths where
pcibios_setup_bus_device() is still called (the PowerPC specific PCI
hotplug support is one) so with just the previous patch applied the setup
can be
From: Shawn Anastasio
Move PCI device setup from pcibios_add_device() and pcibios_fixup_bus() to
pcibios_bus_add_device(). This ensures that platform-specific DMA and IOMMU
setup occurs after the device has been registered in sysfs, which is a
requirement for IOMMU group assignment to work
This
On PowerNV we use the pcibios_sriov_enable() hook to do two things:
1. Create a pci_dn structure for each of the VFs, and
2. Configure the PHB's internal BARs that map MMIO ranges to PEs
so that each VF has it's own PE. Note that the PE also determines
the IOMMU table the HW uses for the dev
A couple of extra patches on top of Shawn's existing re-ordering patch.
This seems to fix the problem Alexey noted with Shawn's change causing
VFs to lose their IOMMU group. I've tried pretty hard to make this a
minimal fix it's still a bit large.
If mpe is happy to take this as a fix for 5.4 then
Hi all,
After merging the powerpc tree, today's linux-next build (powerpc64
allnoconfig) failed like this:
arch/powerpc/mm/book3s64/pgtable.c: In function 'flush_partition':
arch/powerpc/mm/book3s64/pgtable.c:216:3: error: implicit declaration of
function 'radix__flush_all_lpid_guest'; did you m
On 9/29/19 3:40 PM, John Hubbard wrote:
On 9/27/19 4:39 PM, Leonardo Bras wrote:
...
+config LOCKLESS_PAGE_TABLE_WALK_TRACKING
+ bool "Tracking (and optimization) of lockless page table walkers"
+ default n
+
+ help
+ Maintain a reference count of active lockless page table
+
On 9/27/19 4:39 PM, Leonardo Bras wrote:
It's necessary to monitor lockless pagetable walks, in order to avoid doing
THP splitting/collapsing during them.
Some methods rely on local_irq_{save,restore}, but that can be slow on
cases with a lot of cpus are used for the process.
In order to speedu
From: Xiaowei Bao
[ Upstream commit fd5d16531a39322c3d7433d9f8a36203c9aaeddc ]
The layerscape PCIe controller have 4 BARs.
BAR0 and BAR1 are 32bit, BAR2 and BAR4 are 64bit and that's a
fixed hardware configuration.
Set the bar_fixed_64bit variable accordingly.
Signed-off-by: Xiaowei Bao
[lo
From: Xiaowei Bao
[ Upstream commit fd5d16531a39322c3d7433d9f8a36203c9aaeddc ]
The layerscape PCIe controller have 4 BARs.
BAR0 and BAR1 are 32bit, BAR2 and BAR4 are 64bit and that's a
fixed hardware configuration.
Set the bar_fixed_64bit variable accordingly.
Signed-off-by: Xiaowei Bao
[lo
I am attaching two logs. I now the mailing lists will be unhappy, but
don't want to try and spam a bunch of log through the mailing liast.
The two logs show the differences between the working and non-working
imx6q 3D accelerator when trying to run a simple glmark2-es2-drm demo.
The only change
On Sat, Sep 28, 2019 at 3:41 AM Greg Kroah-Hartman
wrote:
>
> On Fri, Sep 27, 2019 at 03:48:49PM -0400, Dan Streetman wrote:
> > On Fri, Sep 27, 2019 at 2:19 PM Greg Kroah-Hartman
> > wrote:
> > >
> > > On Fri, Sep 27, 2019 at 09:04:02AM -0400, Dan Streetman wrote:
> > > > The dummy vio_bus_devic
On Fri, Sep 27, 2019 at 2:19 PM Greg Kroah-Hartman
wrote:
>
> On Fri, Sep 27, 2019 at 09:04:02AM -0400, Dan Streetman wrote:
> > The dummy vio_bus_device creates the /sys/devices/vio directory, which
> > contains real vio devices under it; since it represents itself as having
> > a bus = &vio_bus_
The dummy vio_bus_device creates the /sys/devices/vio directory, which
contains real vio devices under it; since it represents itself as having
a bus = &vio_bus_type, its /sys/devices/vio/uevent does call the bus's
.uevent function, vio_hotplug(), and as that function won't find a real
device for t
13 matches
Mail list logo
