[PATCHv5 0/2] Speed Cap fixes for ppc64
This v5 of the patch series is based on v4 sent by Lucas Kannebley Tavares with a few changes: 1. Fix a compilation warning on the code from the first patch, where it was missing a declaration of struct pci_host_bridge, used on the definition of the function pointer pcibios_root_bridge_prepare() in arch/powerpc/include/asm/machdep.h. 2. Incorporate some changes proposed by Tony Breeds in pseries_root_bridge_prepare(). The following description of the changes was extrated from v4: This patch series does: 1. max_bus_speed is used to set the device to gen2 speeds 2. on power there's no longer a conflict between the pseries call and other architectures, because the overwrite is done via a ppc_md hook 3. radeon is using bus->max_bus_speed instead of drm_pcie_get_speed_cap_mask for gen2 capability detection The first patch consists of some architecture changes, such as adding a hook on powerpc for pci_root_bridge_prepare, so that pseries will initialize it to a function, while all other architectures get a NULL pointer. So that whenever pci_create_root_bus is called, we'll get max_bus_speed properly setup from OpenFirmware. The second patch consists of simple radeon changes not to call drm_get_pcie_speed_cap_mask anymore. I assume that on x86 machines, the max_bus_speed property will be properly set already. Kleber Sacilotto de Souza (2): ppc64: perform proper max_bus_speed detection radeon: use max_bus_speed to activate gen2 speeds arch/powerpc/include/asm/machdep.h |3 ++ arch/powerpc/kernel/pci-common.c |8 arch/powerpc/platforms/pseries/pci.c | 53 ++ arch/powerpc/platforms/pseries/pseries.h |4 ++ arch/powerpc/platforms/pseries/setup.c |2 + drivers/gpu/drm/radeon/evergreen.c | 10 ++ drivers/gpu/drm/radeon/r600.c|9 + drivers/gpu/drm/radeon/rv770.c |9 + 8 files changed, 77 insertions(+), 21 deletions(-) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCHv5 0/2] Speed Cap fixes for ppc64
On Fri, 2013-05-03 at 19:43 -0300, Kleber Sacilotto de Souza wrote: > This patch series does: > 1. max_bus_speed is used to set the device to gen2 speeds > 2. on power there's no longer a conflict between the pseries call and other > architectures, because the overwrite is done via a ppc_md hook > 3. radeon is using bus->max_bus_speed instead of drm_pcie_get_speed_cap_mask > for gen2 capability detection > > The first patch consists of some architecture changes, such as adding a hook > on > powerpc for pci_root_bridge_prepare, so that pseries will initialize it to a > function, while all other architectures get a NULL pointer. So that whenever > pci_create_root_bus is called, we'll get max_bus_speed properly setup from > OpenFirmware. > > The second patch consists of simple radeon changes not to call > drm_get_pcie_speed_cap_mask anymore. I assume that on x86 machines, > the max_bus_speed property will be properly set already. So I'm ok with the approach now and I might even put the powerpc patch in for 3.10 since arguably we are fixing a nasty bug (uninitialized max_bus_speed). David, what's your feeling about the radeon change ? It would be nice if that could go in soon for various distro targets :-) On the other hand I'm not going to be pushy if you are not comfortable with it. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCHv5 0/2] Speed Cap fixes for ppc64
On Fri, May 3, 2013 at 7:01 PM, Benjamin Herrenschmidt wrote: > On Fri, 2013-05-03 at 19:43 -0300, Kleber Sacilotto de Souza wrote: > >> This patch series does: >> 1. max_bus_speed is used to set the device to gen2 speeds >> 2. on power there's no longer a conflict between the pseries call and other >> architectures, because the overwrite is done via a ppc_md hook >> 3. radeon is using bus->max_bus_speed instead of >> drm_pcie_get_speed_cap_mask >> for gen2 capability detection >> >> The first patch consists of some architecture changes, such as adding a hook >> on >> powerpc for pci_root_bridge_prepare, so that pseries will initialize it to a >> function, while all other architectures get a NULL pointer. So that whenever >> pci_create_root_bus is called, we'll get max_bus_speed properly setup from >> OpenFirmware. >> >> The second patch consists of simple radeon changes not to call >> drm_get_pcie_speed_cap_mask anymore. I assume that on x86 machines, >> the max_bus_speed property will be properly set already. > > So I'm ok with the approach now and I might even put the powerpc patch > in for 3.10 since arguably we are fixing a nasty bug (uninitialized > max_bus_speed). > > David, what's your feeling about the radeon change ? It would be nice if > that could go in soon for various distro targets :-) On the other hand > I'm not going to be pushy if you are not comfortable with it. FWIW, the radeon change looks fine to me. Alex ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCHv5 0/2] Speed Cap fixes for ppc64
n Mon, May 6, 2013 at 10:32 AM, Alex Deucher wrote: > On Fri, May 3, 2013 at 7:01 PM, Benjamin Herrenschmidt > wrote: >> On Fri, 2013-05-03 at 19:43 -0300, Kleber Sacilotto de Souza wrote: >> >>> This patch series does: >>> 1. max_bus_speed is used to set the device to gen2 speeds >>> 2. on power there's no longer a conflict between the pseries call and >>> other >>> architectures, because the overwrite is done via a ppc_md hook >>> 3. radeon is using bus->max_bus_speed instead of >>> drm_pcie_get_speed_cap_mask >>> for gen2 capability detection >>> >>> The first patch consists of some architecture changes, such as adding a >>> hook on >>> powerpc for pci_root_bridge_prepare, so that pseries will initialize it to a >>> function, while all other architectures get a NULL pointer. So that whenever >>> pci_create_root_bus is called, we'll get max_bus_speed properly setup from >>> OpenFirmware. >>> >>> The second patch consists of simple radeon changes not to call >>> drm_get_pcie_speed_cap_mask anymore. I assume that on x86 machines, >>> the max_bus_speed property will be properly set already. >> >> So I'm ok with the approach now and I might even put the powerpc patch >> in for 3.10 since arguably we are fixing a nasty bug (uninitialized >> max_bus_speed). >> >> David, what's your feeling about the radeon change ? It would be nice if >> that could go in soon for various distro targets :-) On the other hand >> I'm not going to be pushy if you are not comfortable with it. > > FWIW, the radeon change looks fine to me. > > Alex As said previously, looks fine to me too. Cheers, Jerome ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCHv5 0/2] Speed Cap fixes for ppc64
On 05/06/2013 11:32 AM, Alex Deucher wrote: On Fri, May 3, 2013 at 7:01 PM, Benjamin Herrenschmidt wrote: On Fri, 2013-05-03 at 19:43 -0300, Kleber Sacilotto de Souza wrote: This patch series does: 1. max_bus_speed is used to set the device to gen2 speeds 2. on power there's no longer a conflict between the pseries call and other architectures, because the overwrite is done via a ppc_md hook 3. radeon is using bus->max_bus_speed instead of drm_pcie_get_speed_cap_mask for gen2 capability detection The first patch consists of some architecture changes, such as adding a hook on powerpc for pci_root_bridge_prepare, so that pseries will initialize it to a function, while all other architectures get a NULL pointer. So that whenever pci_create_root_bus is called, we'll get max_bus_speed properly setup from OpenFirmware. The second patch consists of simple radeon changes not to call drm_get_pcie_speed_cap_mask anymore. I assume that on x86 machines, the max_bus_speed property will be properly set already. So I'm ok with the approach now and I might even put the powerpc patch in for 3.10 since arguably we are fixing a nasty bug (uninitialized max_bus_speed). David, what's your feeling about the radeon change ? It would be nice if that could go in soon for various distro targets :-) On the other hand I'm not going to be pushy if you are not comfortable with it. FWIW, the radeon change looks fine to me. Alex Hi David, Are you planning to accept the radeon patch? If yes, can we still expect it to make it for 3.10? As Ben mentioned, we have some distro targets to make and it would be nice to have an outlook of the upstream acceptance to start the conversations with those distros. Thanks! -- Kleber Sacilotto de Souza IBM Linux Technology Center ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCHv5 0/2] Speed Cap fixes for ppc64
On Wed, May 15, 2013 at 8:35 AM, Kleber Sacilotto de Souza wrote: > On 05/06/2013 11:32 AM, Alex Deucher wrote: >> >> On Fri, May 3, 2013 at 7:01 PM, Benjamin Herrenschmidt >> wrote: >>> >>> On Fri, 2013-05-03 at 19:43 -0300, Kleber Sacilotto de Souza wrote: >>> This patch series does: 1. max_bus_speed is used to set the device to gen2 speeds 2. on power there's no longer a conflict between the pseries call and other architectures, because the overwrite is done via a ppc_md hook 3. radeon is using bus->max_bus_speed instead of drm_pcie_get_speed_cap_mask for gen2 capability detection The first patch consists of some architecture changes, such as adding a hook on powerpc for pci_root_bridge_prepare, so that pseries will initialize it to a function, while all other architectures get a NULL pointer. So that whenever pci_create_root_bus is called, we'll get max_bus_speed properly setup from OpenFirmware. The second patch consists of simple radeon changes not to call drm_get_pcie_speed_cap_mask anymore. I assume that on x86 machines, the max_bus_speed property will be properly set already. >>> >>> >>> So I'm ok with the approach now and I might even put the powerpc patch >>> in for 3.10 since arguably we are fixing a nasty bug (uninitialized >>> max_bus_speed). >>> >>> David, what's your feeling about the radeon change ? It would be nice if >>> that could go in soon for various distro targets :-) On the other hand >>> I'm not going to be pushy if you are not comfortable with it. >> >> >> FWIW, the radeon change looks fine to me. >> >> Alex >> > > Hi David, > > Are you planning to accept the radeon patch? If yes, can we still expect it > to make it for 3.10? > > As Ben mentioned, we have some distro targets to make and it would be nice > to have an outlook of the upstream acceptance to start the conversations > with those distros. Is the rest of this series already upstream? I don't see a problem pulling it in if the rest of the patches are in Dave's tree. Dave, do you want to grab this, or do you wan me to pull it in through my tree? Alex ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCHv5 0/2] Speed Cap fixes for ppc64
On 05/15/2013 09:58 AM, Alex Deucher wrote: On Wed, May 15, 2013 at 8:35 AM, Kleber Sacilotto de Souza wrote: On 05/06/2013 11:32 AM, Alex Deucher wrote: On Fri, May 3, 2013 at 7:01 PM, Benjamin Herrenschmidt wrote: On Fri, 2013-05-03 at 19:43 -0300, Kleber Sacilotto de Souza wrote: This patch series does: 1. max_bus_speed is used to set the device to gen2 speeds 2. on power there's no longer a conflict between the pseries call and other architectures, because the overwrite is done via a ppc_md hook 3. radeon is using bus->max_bus_speed instead of drm_pcie_get_speed_cap_mask for gen2 capability detection The first patch consists of some architecture changes, such as adding a hook on powerpc for pci_root_bridge_prepare, so that pseries will initialize it to a function, while all other architectures get a NULL pointer. So that whenever pci_create_root_bus is called, we'll get max_bus_speed properly setup from OpenFirmware. The second patch consists of simple radeon changes not to call drm_get_pcie_speed_cap_mask anymore. I assume that on x86 machines, the max_bus_speed property will be properly set already. So I'm ok with the approach now and I might even put the powerpc patch in for 3.10 since arguably we are fixing a nasty bug (uninitialized max_bus_speed). David, what's your feeling about the radeon change ? It would be nice if that could go in soon for various distro targets :-) On the other hand I'm not going to be pushy if you are not comfortable with it. FWIW, the radeon change looks fine to me. Alex Hi David, Are you planning to accept the radeon patch? If yes, can we still expect it to make it for 3.10? As Ben mentioned, we have some distro targets to make and it would be nice to have an outlook of the upstream acceptance to start the conversations with those distros. Is the rest of this series already upstream? I don't see a problem pulling it in if the rest of the patches are in Dave's tree. Dave, do you want to grab this, or do you wan me to pull it in through my tree? Alex The powerpc patch was applied by Ben and is already upstream. Thanks, -- Kleber Sacilotto de Souza IBM Linux Technology Center ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
