Re: [PATCH 6/8] PCI: host: brcmstb: add MSI capability

[Jim Quinlan]

On Wed, Oct 25, 2017 at 4:16 PM, Bjorn Helgaas  wrote:
> On Wed, Oct 25, 2017 at 11:40:47AM -0700, Scott Branden wrote:
>> Hi Bjorn,
>>
>>
>> On 17-10-25 10:23 AM, Bjorn Helgaas wrote:
>> >[+cc Ray, Scott, Jon]
>> >
>> >On Wed, Oct 25, 2017 at 11:28:07AM -0400, Jim Quinlan wrote:
>> >>On Tue, Oct 24, 2017 at 2:57 PM, Florian Fainelli  
>> >>wrote:
>> >>>Hi Jim,
>> >>>
>> >>>On 10/24/2017 11:15 AM, Jim Quinlan wrote:
>> This commit adds MSI to the Broadcom STB PCIe host controller. It does
>> not add MSIX since that functionality is not in the HW.  The MSI
>> controller is physically located within the PCIe block, however, there
>> is no reason why the MSI controller could not be moved elsewhere in
>> the future.
>> 
>> Since the internal Brcmstb MSI controller is intertwined with the PCIe
>> controller, it is not its own platform device but rather part of the
>> PCIe platform device.
>> 
>> Signed-off-by: Jim Quinlan 
>> ---
>>   drivers/pci/host/Kconfig   |  12 ++
>>   drivers/pci/host/Makefile  |   1 +
>>   drivers/pci/host/pci-brcmstb-msi.c | 318 
>>  +
>>   drivers/pci/host/pci-brcmstb.c |  72 +++--
>>   drivers/pci/host/pci-brcmstb.h |  26 +++
>>   5 files changed, 419 insertions(+), 10 deletions(-)
>>   create mode 100644 drivers/pci/host/pci-brcmstb-msi.c
>> 
>> diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
>> index b9b4f11..54aa5d2 100644
>> --- a/drivers/pci/host/Kconfig
>> +++ b/drivers/pci/host/Kconfig
>> @@ -228,4 +228,16 @@ config PCI_BRCMSTB
>>    default ARCH_BRCMSTB || BMIPS_GENERIC
>>    help
>>  Adds support for Broadcom Settop Box PCIe host controller.
>> +   To compile this driver as a module, choose m here.
>> +
>> +config PCI_BRCMSTB_MSI
>> + bool "Broadcom Brcmstb PCIe MSI support"
>> + depends on ARCH_BRCMSTB || BMIPS_GENERIC
>> >>>This could probably be depends on PCI_BRCMSTB, which would imply these
>> >>>two conditions. PCI_BRCMSTB_MSI on its own is probably not very useful
>> >>>without the parent RC driver.
>> >>>
>> + depends on OF
>> + depends on PCI_MSI
>> + default PCI_BRCMSTB
>> + help
>> +   Say Y here if you want to enable MSI support for Broadcom's iProc
>> +   PCIe controller
>> +
>>   endmenu
>> diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
>> index c283321..1026d6f 100644
>> --- a/drivers/pci/host/Makefile
>> +++ b/drivers/pci/host/Makefile
>> @@ -23,6 +23,7 @@ obj-$(CONFIG_PCIE_TANGO_SMP8759) += pcie-tango.o
>>   obj-$(CONFIG_VMD) += vmd.o
>>   obj-$(CONFIG_PCI_BRCMSTB) += brcmstb-pci.o
>>   brcmstb-pci-objs := pci-brcmstb.o pci-brcmstb-dma.o
>> +obj-$(CONFIG_PCI_BRCMSTB_MSI) += pci-brcmstb-msi.o
>> >>>Should we combine this file with the brcmstb-pci.o? There is probably no
>> >>>functional difference, except that pci-brcmstb-msi.ko needs to be loaded
>> >>>first, right?
>> >>>--
>> >>>Florian
>> >>If you look at the pci/host/Kconfig you will see that other drivers
>> >>also have a separate MSI config (eg iproc, altera, xgene) so there is
>> >>precedent.  The reason that pci-brcmstb-msi.c is its own file is
>> >>because it depends on an irq function that is not exported.  That is
>> >>why CONFIG_PCI_BRCMSTB_MSI is bool, and CONFIG_PCI_BRCMSTB is
>> >>tristate.  -- Jim
>> >There is precedent, but that doesn't mean I like it :)
>> >I would strongly prefer one file per driver when possible.
>> >
>> >Take iproc for example.  iproc-msi.c is enabled by a Kconfig bool.  It
>> >contains a bunch of code with the only external entry points being
>> >iproc_msi_init() and iproc_msi_exit().  These are only called via
>> >iproc_pcie_bcma_probe() or iproc_pcie_pltfm_probe(), both of which are
>> >tristate.  So iproc-msi.c is only compiled if CONFIG_IPROC_BCMA or
>> >CONFIG_IPROC_PLATFORM are enabled, but all that text is loaded even if
>> >neither module is loaded, which seems suboptimal.
>> >
>> >I don't care if you have several config options to enable the BCMA
>> >probe and the platform probe (although these could probably be
>> >replaced in the code by a simple "#ifdef CONFIG_BCMA" and "#ifdef
>> >CONFIG_OF"), and making CONFIG_PCIE_IPROC tristate so it can be a
>> >module makes sense.  But I think it would be better to put all the
>> >code in one file instead of five, and probably remove
>> >CONFIG_PCIE_IPROC_MSI.  Maybe this requires exporting some IRQ
>> >function that currently isn't exported.  But that seems like a simpler
>> >solution than what we currently have.
>> Placing pcie-iproc-bcma.c in its own file is useful in being able to
>> read the code that is actually used.  BCMA is really unnecessary if
>> a few platforms stopped using BCMA and declared 

Re: [PATCH 6/8] PCI: host: brcmstb: add MSI capability

[Jim Quinlan]

On Wed, Oct 25, 2017 at 4:16 PM, Bjorn Helgaas  wrote:
> On Wed, Oct 25, 2017 at 11:40:47AM -0700, Scott Branden wrote:
>> Hi Bjorn,
>>
>>
>> On 17-10-25 10:23 AM, Bjorn Helgaas wrote:
>> >[+cc Ray, Scott, Jon]
>> >
>> >On Wed, Oct 25, 2017 at 11:28:07AM -0400, Jim Quinlan wrote:
>> >>On Tue, Oct 24, 2017 at 2:57 PM, Florian Fainelli  
>> >>wrote:
>> >>>Hi Jim,
>> >>>
>> >>>On 10/24/2017 11:15 AM, Jim Quinlan wrote:
>> This commit adds MSI to the Broadcom STB PCIe host controller. It does
>> not add MSIX since that functionality is not in the HW.  The MSI
>> controller is physically located within the PCIe block, however, there
>> is no reason why the MSI controller could not be moved elsewhere in
>> the future.
>> 
>> Since the internal Brcmstb MSI controller is intertwined with the PCIe
>> controller, it is not its own platform device but rather part of the
>> PCIe platform device.
>> 
>> Signed-off-by: Jim Quinlan 
>> ---
>>   drivers/pci/host/Kconfig   |  12 ++
>>   drivers/pci/host/Makefile  |   1 +
>>   drivers/pci/host/pci-brcmstb-msi.c | 318 
>>  +
>>   drivers/pci/host/pci-brcmstb.c |  72 +++--
>>   drivers/pci/host/pci-brcmstb.h |  26 +++
>>   5 files changed, 419 insertions(+), 10 deletions(-)
>>   create mode 100644 drivers/pci/host/pci-brcmstb-msi.c
>> 
>> diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
>> index b9b4f11..54aa5d2 100644
>> --- a/drivers/pci/host/Kconfig
>> +++ b/drivers/pci/host/Kconfig
>> @@ -228,4 +228,16 @@ config PCI_BRCMSTB
>>    default ARCH_BRCMSTB || BMIPS_GENERIC
>>    help
>>  Adds support for Broadcom Settop Box PCIe host controller.
>> +   To compile this driver as a module, choose m here.
>> +
>> +config PCI_BRCMSTB_MSI
>> + bool "Broadcom Brcmstb PCIe MSI support"
>> + depends on ARCH_BRCMSTB || BMIPS_GENERIC
>> >>>This could probably be depends on PCI_BRCMSTB, which would imply these
>> >>>two conditions. PCI_BRCMSTB_MSI on its own is probably not very useful
>> >>>without the parent RC driver.
>> >>>
>> + depends on OF
>> + depends on PCI_MSI
>> + default PCI_BRCMSTB
>> + help
>> +   Say Y here if you want to enable MSI support for Broadcom's iProc
>> +   PCIe controller
>> +
>>   endmenu
>> diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
>> index c283321..1026d6f 100644
>> --- a/drivers/pci/host/Makefile
>> +++ b/drivers/pci/host/Makefile
>> @@ -23,6 +23,7 @@ obj-$(CONFIG_PCIE_TANGO_SMP8759) += pcie-tango.o
>>   obj-$(CONFIG_VMD) += vmd.o
>>   obj-$(CONFIG_PCI_BRCMSTB) += brcmstb-pci.o
>>   brcmstb-pci-objs := pci-brcmstb.o pci-brcmstb-dma.o
>> +obj-$(CONFIG_PCI_BRCMSTB_MSI) += pci-brcmstb-msi.o
>> >>>Should we combine this file with the brcmstb-pci.o? There is probably no
>> >>>functional difference, except that pci-brcmstb-msi.ko needs to be loaded
>> >>>first, right?
>> >>>--
>> >>>Florian
>> >>If you look at the pci/host/Kconfig you will see that other drivers
>> >>also have a separate MSI config (eg iproc, altera, xgene) so there is
>> >>precedent.  The reason that pci-brcmstb-msi.c is its own file is
>> >>because it depends on an irq function that is not exported.  That is
>> >>why CONFIG_PCI_BRCMSTB_MSI is bool, and CONFIG_PCI_BRCMSTB is
>> >>tristate.  -- Jim
>> >There is precedent, but that doesn't mean I like it :)
>> >I would strongly prefer one file per driver when possible.
>> >
>> >Take iproc for example.  iproc-msi.c is enabled by a Kconfig bool.  It
>> >contains a bunch of code with the only external entry points being
>> >iproc_msi_init() and iproc_msi_exit().  These are only called via
>> >iproc_pcie_bcma_probe() or iproc_pcie_pltfm_probe(), both of which are
>> >tristate.  So iproc-msi.c is only compiled if CONFIG_IPROC_BCMA or
>> >CONFIG_IPROC_PLATFORM are enabled, but all that text is loaded even if
>> >neither module is loaded, which seems suboptimal.
>> >
>> >I don't care if you have several config options to enable the BCMA
>> >probe and the platform probe (although these could probably be
>> >replaced in the code by a simple "#ifdef CONFIG_BCMA" and "#ifdef
>> >CONFIG_OF"), and making CONFIG_PCIE_IPROC tristate so it can be a
>> >module makes sense.  But I think it would be better to put all the
>> >code in one file instead of five, and probably remove
>> >CONFIG_PCIE_IPROC_MSI.  Maybe this requires exporting some IRQ
>> >function that currently isn't exported.  But that seems like a simpler
>> >solution than what we currently have.
>> Placing pcie-iproc-bcma.c in its own file is useful in being able to
>> read the code that is actually used.  BCMA is really unnecessary if
>> a few platforms stopped using BCMA and declared everything via
>> devicetree or ACPI.  Same with 

Re: [PATCH 6/8] PCI: host: brcmstb: add MSI capability

[Bjorn Helgaas]

On Wed, Oct 25, 2017 at 11:40:47AM -0700, Scott Branden wrote:
> Hi Bjorn,
> 
> 
> On 17-10-25 10:23 AM, Bjorn Helgaas wrote:
> >[+cc Ray, Scott, Jon]
> >
> >On Wed, Oct 25, 2017 at 11:28:07AM -0400, Jim Quinlan wrote:
> >>On Tue, Oct 24, 2017 at 2:57 PM, Florian Fainelli  
> >>wrote:
> >>>Hi Jim,
> >>>
> >>>On 10/24/2017 11:15 AM, Jim Quinlan wrote:
> This commit adds MSI to the Broadcom STB PCIe host controller. It does
> not add MSIX since that functionality is not in the HW.  The MSI
> controller is physically located within the PCIe block, however, there
> is no reason why the MSI controller could not be moved elsewhere in
> the future.
> 
> Since the internal Brcmstb MSI controller is intertwined with the PCIe
> controller, it is not its own platform device but rather part of the
> PCIe platform device.
> 
> Signed-off-by: Jim Quinlan 
> ---
>   drivers/pci/host/Kconfig   |  12 ++
>   drivers/pci/host/Makefile  |   1 +
>   drivers/pci/host/pci-brcmstb-msi.c | 318 
>  +
>   drivers/pci/host/pci-brcmstb.c |  72 +++--
>   drivers/pci/host/pci-brcmstb.h |  26 +++
>   5 files changed, 419 insertions(+), 10 deletions(-)
>   create mode 100644 drivers/pci/host/pci-brcmstb-msi.c
> 
> diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
> index b9b4f11..54aa5d2 100644
> --- a/drivers/pci/host/Kconfig
> +++ b/drivers/pci/host/Kconfig
> @@ -228,4 +228,16 @@ config PCI_BRCMSTB
>    default ARCH_BRCMSTB || BMIPS_GENERIC
>    help
>  Adds support for Broadcom Settop Box PCIe host controller.
> +   To compile this driver as a module, choose m here.
> +
> +config PCI_BRCMSTB_MSI
> + bool "Broadcom Brcmstb PCIe MSI support"
> + depends on ARCH_BRCMSTB || BMIPS_GENERIC
> >>>This could probably be depends on PCI_BRCMSTB, which would imply these
> >>>two conditions. PCI_BRCMSTB_MSI on its own is probably not very useful
> >>>without the parent RC driver.
> >>>
> + depends on OF
> + depends on PCI_MSI
> + default PCI_BRCMSTB
> + help
> +   Say Y here if you want to enable MSI support for Broadcom's iProc
> +   PCIe controller
> +
>   endmenu
> diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
> index c283321..1026d6f 100644
> --- a/drivers/pci/host/Makefile
> +++ b/drivers/pci/host/Makefile
> @@ -23,6 +23,7 @@ obj-$(CONFIG_PCIE_TANGO_SMP8759) += pcie-tango.o
>   obj-$(CONFIG_VMD) += vmd.o
>   obj-$(CONFIG_PCI_BRCMSTB) += brcmstb-pci.o
>   brcmstb-pci-objs := pci-brcmstb.o pci-brcmstb-dma.o
> +obj-$(CONFIG_PCI_BRCMSTB_MSI) += pci-brcmstb-msi.o
> >>>Should we combine this file with the brcmstb-pci.o? There is probably no
> >>>functional difference, except that pci-brcmstb-msi.ko needs to be loaded
> >>>first, right?
> >>>--
> >>>Florian
> >>If you look at the pci/host/Kconfig you will see that other drivers
> >>also have a separate MSI config (eg iproc, altera, xgene) so there is
> >>precedent.  The reason that pci-brcmstb-msi.c is its own file is
> >>because it depends on an irq function that is not exported.  That is
> >>why CONFIG_PCI_BRCMSTB_MSI is bool, and CONFIG_PCI_BRCMSTB is
> >>tristate.  -- Jim
> >There is precedent, but that doesn't mean I like it :)
> >I would strongly prefer one file per driver when possible.
> >
> >Take iproc for example.  iproc-msi.c is enabled by a Kconfig bool.  It
> >contains a bunch of code with the only external entry points being
> >iproc_msi_init() and iproc_msi_exit().  These are only called via
> >iproc_pcie_bcma_probe() or iproc_pcie_pltfm_probe(), both of which are
> >tristate.  So iproc-msi.c is only compiled if CONFIG_IPROC_BCMA or
> >CONFIG_IPROC_PLATFORM are enabled, but all that text is loaded even if
> >neither module is loaded, which seems suboptimal.
> >
> >I don't care if you have several config options to enable the BCMA
> >probe and the platform probe (although these could probably be
> >replaced in the code by a simple "#ifdef CONFIG_BCMA" and "#ifdef
> >CONFIG_OF"), and making CONFIG_PCIE_IPROC tristate so it can be a
> >module makes sense.  But I think it would be better to put all the
> >code in one file instead of five, and probably remove
> >CONFIG_PCIE_IPROC_MSI.  Maybe this requires exporting some IRQ
> >function that currently isn't exported.  But that seems like a simpler
> >solution than what we currently have.
> Placing pcie-iproc-bcma.c in its own file is useful in being able to
> read the code that is actually used.  BCMA is really unnecessary if
> a few platforms stopped using BCMA and declared everything via
> devicetree or ACPI.  Same with pcie-iproc-platform.c.  Both keep the
> mess out of pcie-iproc.c.

Maybe.  Both pcie-iproc-bcma.c and pcie-iproc-platform.c are 

Re: [PATCH 6/8] PCI: host: brcmstb: add MSI capability

[Bjorn Helgaas]

On Wed, Oct 25, 2017 at 11:40:47AM -0700, Scott Branden wrote:
> Hi Bjorn,
> 
> 
> On 17-10-25 10:23 AM, Bjorn Helgaas wrote:
> >[+cc Ray, Scott, Jon]
> >
> >On Wed, Oct 25, 2017 at 11:28:07AM -0400, Jim Quinlan wrote:
> >>On Tue, Oct 24, 2017 at 2:57 PM, Florian Fainelli  
> >>wrote:
> >>>Hi Jim,
> >>>
> >>>On 10/24/2017 11:15 AM, Jim Quinlan wrote:
> This commit adds MSI to the Broadcom STB PCIe host controller. It does
> not add MSIX since that functionality is not in the HW.  The MSI
> controller is physically located within the PCIe block, however, there
> is no reason why the MSI controller could not be moved elsewhere in
> the future.
> 
> Since the internal Brcmstb MSI controller is intertwined with the PCIe
> controller, it is not its own platform device but rather part of the
> PCIe platform device.
> 
> Signed-off-by: Jim Quinlan 
> ---
>   drivers/pci/host/Kconfig   |  12 ++
>   drivers/pci/host/Makefile  |   1 +
>   drivers/pci/host/pci-brcmstb-msi.c | 318 
>  +
>   drivers/pci/host/pci-brcmstb.c |  72 +++--
>   drivers/pci/host/pci-brcmstb.h |  26 +++
>   5 files changed, 419 insertions(+), 10 deletions(-)
>   create mode 100644 drivers/pci/host/pci-brcmstb-msi.c
> 
> diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
> index b9b4f11..54aa5d2 100644
> --- a/drivers/pci/host/Kconfig
> +++ b/drivers/pci/host/Kconfig
> @@ -228,4 +228,16 @@ config PCI_BRCMSTB
>    default ARCH_BRCMSTB || BMIPS_GENERIC
>    help
>  Adds support for Broadcom Settop Box PCIe host controller.
> +   To compile this driver as a module, choose m here.
> +
> +config PCI_BRCMSTB_MSI
> + bool "Broadcom Brcmstb PCIe MSI support"
> + depends on ARCH_BRCMSTB || BMIPS_GENERIC
> >>>This could probably be depends on PCI_BRCMSTB, which would imply these
> >>>two conditions. PCI_BRCMSTB_MSI on its own is probably not very useful
> >>>without the parent RC driver.
> >>>
> + depends on OF
> + depends on PCI_MSI
> + default PCI_BRCMSTB
> + help
> +   Say Y here if you want to enable MSI support for Broadcom's iProc
> +   PCIe controller
> +
>   endmenu
> diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
> index c283321..1026d6f 100644
> --- a/drivers/pci/host/Makefile
> +++ b/drivers/pci/host/Makefile
> @@ -23,6 +23,7 @@ obj-$(CONFIG_PCIE_TANGO_SMP8759) += pcie-tango.o
>   obj-$(CONFIG_VMD) += vmd.o
>   obj-$(CONFIG_PCI_BRCMSTB) += brcmstb-pci.o
>   brcmstb-pci-objs := pci-brcmstb.o pci-brcmstb-dma.o
> +obj-$(CONFIG_PCI_BRCMSTB_MSI) += pci-brcmstb-msi.o
> >>>Should we combine this file with the brcmstb-pci.o? There is probably no
> >>>functional difference, except that pci-brcmstb-msi.ko needs to be loaded
> >>>first, right?
> >>>--
> >>>Florian
> >>If you look at the pci/host/Kconfig you will see that other drivers
> >>also have a separate MSI config (eg iproc, altera, xgene) so there is
> >>precedent.  The reason that pci-brcmstb-msi.c is its own file is
> >>because it depends on an irq function that is not exported.  That is
> >>why CONFIG_PCI_BRCMSTB_MSI is bool, and CONFIG_PCI_BRCMSTB is
> >>tristate.  -- Jim
> >There is precedent, but that doesn't mean I like it :)
> >I would strongly prefer one file per driver when possible.
> >
> >Take iproc for example.  iproc-msi.c is enabled by a Kconfig bool.  It
> >contains a bunch of code with the only external entry points being
> >iproc_msi_init() and iproc_msi_exit().  These are only called via
> >iproc_pcie_bcma_probe() or iproc_pcie_pltfm_probe(), both of which are
> >tristate.  So iproc-msi.c is only compiled if CONFIG_IPROC_BCMA or
> >CONFIG_IPROC_PLATFORM are enabled, but all that text is loaded even if
> >neither module is loaded, which seems suboptimal.
> >
> >I don't care if you have several config options to enable the BCMA
> >probe and the platform probe (although these could probably be
> >replaced in the code by a simple "#ifdef CONFIG_BCMA" and "#ifdef
> >CONFIG_OF"), and making CONFIG_PCIE_IPROC tristate so it can be a
> >module makes sense.  But I think it would be better to put all the
> >code in one file instead of five, and probably remove
> >CONFIG_PCIE_IPROC_MSI.  Maybe this requires exporting some IRQ
> >function that currently isn't exported.  But that seems like a simpler
> >solution than what we currently have.
> Placing pcie-iproc-bcma.c in its own file is useful in being able to
> read the code that is actually used.  BCMA is really unnecessary if
> a few platforms stopped using BCMA and declared everything via
> devicetree or ACPI.  Same with pcie-iproc-platform.c.  Both keep the
> mess out of pcie-iproc.c.

Maybe.  Both pcie-iproc-bcma.c and pcie-iproc-platform.c are small
(280 lines combined) relative to 

Re: [PATCH 6/8] PCI: host: brcmstb: add MSI capability

[Scott Branden]

Hi Bjorn,


On 17-10-25 10:23 AM, Bjorn Helgaas wrote:

[+cc Ray, Scott, Jon]

On Wed, Oct 25, 2017 at 11:28:07AM -0400, Jim Quinlan wrote:

On Tue, Oct 24, 2017 at 2:57 PM, Florian Fainelli  wrote:

Hi Jim,

On 10/24/2017 11:15 AM, Jim Quinlan wrote:

This commit adds MSI to the Broadcom STB PCIe host controller. It does
not add MSIX since that functionality is not in the HW.  The MSI
controller is physically located within the PCIe block, however, there
is no reason why the MSI controller could not be moved elsewhere in
the future.

Since the internal Brcmstb MSI controller is intertwined with the PCIe
controller, it is not its own platform device but rather part of the
PCIe platform device.

Signed-off-by: Jim Quinlan 
---
  drivers/pci/host/Kconfig   |  12 ++
  drivers/pci/host/Makefile  |   1 +
  drivers/pci/host/pci-brcmstb-msi.c | 318 +
  drivers/pci/host/pci-brcmstb.c |  72 +++--
  drivers/pci/host/pci-brcmstb.h |  26 +++
  5 files changed, 419 insertions(+), 10 deletions(-)
  create mode 100644 drivers/pci/host/pci-brcmstb-msi.c

diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
index b9b4f11..54aa5d2 100644
--- a/drivers/pci/host/Kconfig
+++ b/drivers/pci/host/Kconfig
@@ -228,4 +228,16 @@ config PCI_BRCMSTB
   default ARCH_BRCMSTB || BMIPS_GENERIC
   help
 Adds support for Broadcom Settop Box PCIe host controller.
+   To compile this driver as a module, choose m here.
+
+config PCI_BRCMSTB_MSI
+ bool "Broadcom Brcmstb PCIe MSI support"
+ depends on ARCH_BRCMSTB || BMIPS_GENERIC

This could probably be depends on PCI_BRCMSTB, which would imply these
two conditions. PCI_BRCMSTB_MSI on its own is probably not very useful
without the parent RC driver.


+ depends on OF
+ depends on PCI_MSI
+ default PCI_BRCMSTB
+ help
+   Say Y here if you want to enable MSI support for Broadcom's iProc
+   PCIe controller
+
  endmenu
diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
index c283321..1026d6f 100644
--- a/drivers/pci/host/Makefile
+++ b/drivers/pci/host/Makefile
@@ -23,6 +23,7 @@ obj-$(CONFIG_PCIE_TANGO_SMP8759) += pcie-tango.o
  obj-$(CONFIG_VMD) += vmd.o
  obj-$(CONFIG_PCI_BRCMSTB) += brcmstb-pci.o
  brcmstb-pci-objs := pci-brcmstb.o pci-brcmstb-dma.o
+obj-$(CONFIG_PCI_BRCMSTB_MSI) += pci-brcmstb-msi.o

Should we combine this file with the brcmstb-pci.o? There is probably no
functional difference, except that pci-brcmstb-msi.ko needs to be loaded
first, right?
--
Florian

If you look at the pci/host/Kconfig you will see that other drivers
also have a separate MSI config (eg iproc, altera, xgene) so there is
precedent.  The reason that pci-brcmstb-msi.c is its own file is
because it depends on an irq function that is not exported.  That is
why CONFIG_PCI_BRCMSTB_MSI is bool, and CONFIG_PCI_BRCMSTB is
tristate.  -- Jim

There is precedent, but that doesn't mean I like it :)
I would strongly prefer one file per driver when possible.

Take iproc for example.  iproc-msi.c is enabled by a Kconfig bool.  It
contains a bunch of code with the only external entry points being
iproc_msi_init() and iproc_msi_exit().  These are only called via
iproc_pcie_bcma_probe() or iproc_pcie_pltfm_probe(), both of which are
tristate.  So iproc-msi.c is only compiled if CONFIG_IPROC_BCMA or
CONFIG_IPROC_PLATFORM are enabled, but all that text is loaded even if
neither module is loaded, which seems suboptimal.

I don't care if you have several config options to enable the BCMA
probe and the platform probe (although these could probably be
replaced in the code by a simple "#ifdef CONFIG_BCMA" and "#ifdef
CONFIG_OF"), and making CONFIG_PCIE_IPROC tristate so it can be a
module makes sense.  But I think it would be better to put all the
code in one file instead of five, and probably remove
CONFIG_PCIE_IPROC_MSI.  Maybe this requires exporting some IRQ
function that currently isn't exported.  But that seems like a simpler
solution than what we currently have.
Placing pcie-iproc-bcma.c in its own file is useful in being able to 
read the code that is actually used.  BCMA is really unnecessary if a 
few platforms stopped using BCMA and declared everything via devicetree 
or ACPI.  Same with pcie-iproc-platform.c.  Both keep the mess out of 
pcie-iproc.c.


It looks like pcie-iproc-msi.c followed existing pci drivers in place.  
So if msi was cleaned up through the entire pci drivers then yes it 
would make sense to remove CONFIG_PCIE_IPROC_MSI and combine code in 
pcie-iproc.c.  But I think leaving the bcma and platform code in their 
own files makes it easier for us to work with the code rather than 
placing unused code in ifdefs in the same file.


Bjorn

Regards,
Scott

Re: [PATCH 6/8] PCI: host: brcmstb: add MSI capability

[Scott Branden]

Hi Bjorn,


On 17-10-25 10:23 AM, Bjorn Helgaas wrote:

[+cc Ray, Scott, Jon]

On Wed, Oct 25, 2017 at 11:28:07AM -0400, Jim Quinlan wrote:

On Tue, Oct 24, 2017 at 2:57 PM, Florian Fainelli  wrote:

Hi Jim,

On 10/24/2017 11:15 AM, Jim Quinlan wrote:

This commit adds MSI to the Broadcom STB PCIe host controller. It does
not add MSIX since that functionality is not in the HW.  The MSI
controller is physically located within the PCIe block, however, there
is no reason why the MSI controller could not be moved elsewhere in
the future.

Since the internal Brcmstb MSI controller is intertwined with the PCIe
controller, it is not its own platform device but rather part of the
PCIe platform device.

Signed-off-by: Jim Quinlan 
---
  drivers/pci/host/Kconfig   |  12 ++
  drivers/pci/host/Makefile  |   1 +
  drivers/pci/host/pci-brcmstb-msi.c | 318 +
  drivers/pci/host/pci-brcmstb.c |  72 +++--
  drivers/pci/host/pci-brcmstb.h |  26 +++
  5 files changed, 419 insertions(+), 10 deletions(-)
  create mode 100644 drivers/pci/host/pci-brcmstb-msi.c

diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
index b9b4f11..54aa5d2 100644
--- a/drivers/pci/host/Kconfig
+++ b/drivers/pci/host/Kconfig
@@ -228,4 +228,16 @@ config PCI_BRCMSTB
   default ARCH_BRCMSTB || BMIPS_GENERIC
   help
 Adds support for Broadcom Settop Box PCIe host controller.
+   To compile this driver as a module, choose m here.
+
+config PCI_BRCMSTB_MSI
+ bool "Broadcom Brcmstb PCIe MSI support"
+ depends on ARCH_BRCMSTB || BMIPS_GENERIC

This could probably be depends on PCI_BRCMSTB, which would imply these
two conditions. PCI_BRCMSTB_MSI on its own is probably not very useful
without the parent RC driver.


+ depends on OF
+ depends on PCI_MSI
+ default PCI_BRCMSTB
+ help
+   Say Y here if you want to enable MSI support for Broadcom's iProc
+   PCIe controller
+
  endmenu
diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
index c283321..1026d6f 100644
--- a/drivers/pci/host/Makefile
+++ b/drivers/pci/host/Makefile
@@ -23,6 +23,7 @@ obj-$(CONFIG_PCIE_TANGO_SMP8759) += pcie-tango.o
  obj-$(CONFIG_VMD) += vmd.o
  obj-$(CONFIG_PCI_BRCMSTB) += brcmstb-pci.o
  brcmstb-pci-objs := pci-brcmstb.o pci-brcmstb-dma.o
+obj-$(CONFIG_PCI_BRCMSTB_MSI) += pci-brcmstb-msi.o

Should we combine this file with the brcmstb-pci.o? There is probably no
functional difference, except that pci-brcmstb-msi.ko needs to be loaded
first, right?
--
Florian

If you look at the pci/host/Kconfig you will see that other drivers
also have a separate MSI config (eg iproc, altera, xgene) so there is
precedent.  The reason that pci-brcmstb-msi.c is its own file is
because it depends on an irq function that is not exported.  That is
why CONFIG_PCI_BRCMSTB_MSI is bool, and CONFIG_PCI_BRCMSTB is
tristate.  -- Jim

There is precedent, but that doesn't mean I like it :)
I would strongly prefer one file per driver when possible.

Take iproc for example.  iproc-msi.c is enabled by a Kconfig bool.  It
contains a bunch of code with the only external entry points being
iproc_msi_init() and iproc_msi_exit().  These are only called via
iproc_pcie_bcma_probe() or iproc_pcie_pltfm_probe(), both of which are
tristate.  So iproc-msi.c is only compiled if CONFIG_IPROC_BCMA or
CONFIG_IPROC_PLATFORM are enabled, but all that text is loaded even if
neither module is loaded, which seems suboptimal.

I don't care if you have several config options to enable the BCMA
probe and the platform probe (although these could probably be
replaced in the code by a simple "#ifdef CONFIG_BCMA" and "#ifdef
CONFIG_OF"), and making CONFIG_PCIE_IPROC tristate so it can be a
module makes sense.  But I think it would be better to put all the
code in one file instead of five, and probably remove
CONFIG_PCIE_IPROC_MSI.  Maybe this requires exporting some IRQ
function that currently isn't exported.  But that seems like a simpler
solution than what we currently have.
Placing pcie-iproc-bcma.c in its own file is useful in being able to 
read the code that is actually used.  BCMA is really unnecessary if a 
few platforms stopped using BCMA and declared everything via devicetree 
or ACPI.  Same with pcie-iproc-platform.c.  Both keep the mess out of 
pcie-iproc.c.


It looks like pcie-iproc-msi.c followed existing pci drivers in place.  
So if msi was cleaned up through the entire pci drivers then yes it 
would make sense to remove CONFIG_PCIE_IPROC_MSI and combine code in 
pcie-iproc.c.  But I think leaving the bcma and platform code in their 
own files makes it easier for us to work with the code rather than 
placing unused code in ifdefs in the same file.


Bjorn

Regards,
Scott

Re: [PATCH 6/8] PCI: host: brcmstb: add MSI capability

[Bjorn Helgaas]

[+cc Ray, Scott, Jon]

On Wed, Oct 25, 2017 at 11:28:07AM -0400, Jim Quinlan wrote:
> On Tue, Oct 24, 2017 at 2:57 PM, Florian Fainelli  
> wrote:
> > Hi Jim,
> >
> > On 10/24/2017 11:15 AM, Jim Quinlan wrote:
> >> This commit adds MSI to the Broadcom STB PCIe host controller. It does
> >> not add MSIX since that functionality is not in the HW.  The MSI
> >> controller is physically located within the PCIe block, however, there
> >> is no reason why the MSI controller could not be moved elsewhere in
> >> the future.
> >>
> >> Since the internal Brcmstb MSI controller is intertwined with the PCIe
> >> controller, it is not its own platform device but rather part of the
> >> PCIe platform device.
> >>
> >> Signed-off-by: Jim Quinlan 
> >> ---
> >>  drivers/pci/host/Kconfig   |  12 ++
> >>  drivers/pci/host/Makefile  |   1 +
> >>  drivers/pci/host/pci-brcmstb-msi.c | 318 
> >> +
> >>  drivers/pci/host/pci-brcmstb.c |  72 +++--
> >>  drivers/pci/host/pci-brcmstb.h |  26 +++
> >>  5 files changed, 419 insertions(+), 10 deletions(-)
> >>  create mode 100644 drivers/pci/host/pci-brcmstb-msi.c
> >>
> >> diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
> >> index b9b4f11..54aa5d2 100644
> >> --- a/drivers/pci/host/Kconfig
> >> +++ b/drivers/pci/host/Kconfig
> >> @@ -228,4 +228,16 @@ config PCI_BRCMSTB
> >>   default ARCH_BRCMSTB || BMIPS_GENERIC
> >>   help
> >> Adds support for Broadcom Settop Box PCIe host controller.
> >> +   To compile this driver as a module, choose m here.
> >> +
> >> +config PCI_BRCMSTB_MSI
> >> + bool "Broadcom Brcmstb PCIe MSI support"
> >> + depends on ARCH_BRCMSTB || BMIPS_GENERIC
> >
> > This could probably be depends on PCI_BRCMSTB, which would imply these
> > two conditions. PCI_BRCMSTB_MSI on its own is probably not very useful
> > without the parent RC driver.
> >
> >> + depends on OF
> >> + depends on PCI_MSI
> >> + default PCI_BRCMSTB
> >> + help
> >> +   Say Y here if you want to enable MSI support for Broadcom's iProc
> >> +   PCIe controller
> >> +
> >>  endmenu
> >> diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
> >> index c283321..1026d6f 100644
> >> --- a/drivers/pci/host/Makefile
> >> +++ b/drivers/pci/host/Makefile
> >> @@ -23,6 +23,7 @@ obj-$(CONFIG_PCIE_TANGO_SMP8759) += pcie-tango.o
> >>  obj-$(CONFIG_VMD) += vmd.o
> >>  obj-$(CONFIG_PCI_BRCMSTB) += brcmstb-pci.o
> >>  brcmstb-pci-objs := pci-brcmstb.o pci-brcmstb-dma.o
> >> +obj-$(CONFIG_PCI_BRCMSTB_MSI) += pci-brcmstb-msi.o
> >
> > Should we combine this file with the brcmstb-pci.o? There is probably no
> > functional difference, except that pci-brcmstb-msi.ko needs to be loaded
> > first, right?
> > --
> > Florian
> 
> If you look at the pci/host/Kconfig you will see that other drivers
> also have a separate MSI config (eg iproc, altera, xgene) so there is
> precedent.  The reason that pci-brcmstb-msi.c is its own file is
> because it depends on an irq function that is not exported.  That is
> why CONFIG_PCI_BRCMSTB_MSI is bool, and CONFIG_PCI_BRCMSTB is
> tristate.  -- Jim

There is precedent, but that doesn't mean I like it :)
I would strongly prefer one file per driver when possible.

Take iproc for example.  iproc-msi.c is enabled by a Kconfig bool.  It
contains a bunch of code with the only external entry points being
iproc_msi_init() and iproc_msi_exit().  These are only called via
iproc_pcie_bcma_probe() or iproc_pcie_pltfm_probe(), both of which are
tristate.  So iproc-msi.c is only compiled if CONFIG_IPROC_BCMA or
CONFIG_IPROC_PLATFORM are enabled, but all that text is loaded even if
neither module is loaded, which seems suboptimal.

I don't care if you have several config options to enable the BCMA
probe and the platform probe (although these could probably be
replaced in the code by a simple "#ifdef CONFIG_BCMA" and "#ifdef
CONFIG_OF"), and making CONFIG_PCIE_IPROC tristate so it can be a
module makes sense.  But I think it would be better to put all the
code in one file instead of five, and probably remove
CONFIG_PCIE_IPROC_MSI.  Maybe this requires exporting some IRQ
function that currently isn't exported.  But that seems like a simpler
solution than what we currently have.

Bjorn

Re: [PATCH 6/8] PCI: host: brcmstb: add MSI capability

[Bjorn Helgaas]

[+cc Ray, Scott, Jon]

On Wed, Oct 25, 2017 at 11:28:07AM -0400, Jim Quinlan wrote:
> On Tue, Oct 24, 2017 at 2:57 PM, Florian Fainelli  
> wrote:
> > Hi Jim,
> >
> > On 10/24/2017 11:15 AM, Jim Quinlan wrote:
> >> This commit adds MSI to the Broadcom STB PCIe host controller. It does
> >> not add MSIX since that functionality is not in the HW.  The MSI
> >> controller is physically located within the PCIe block, however, there
> >> is no reason why the MSI controller could not be moved elsewhere in
> >> the future.
> >>
> >> Since the internal Brcmstb MSI controller is intertwined with the PCIe
> >> controller, it is not its own platform device but rather part of the
> >> PCIe platform device.
> >>
> >> Signed-off-by: Jim Quinlan 
> >> ---
> >>  drivers/pci/host/Kconfig   |  12 ++
> >>  drivers/pci/host/Makefile  |   1 +
> >>  drivers/pci/host/pci-brcmstb-msi.c | 318 
> >> +
> >>  drivers/pci/host/pci-brcmstb.c |  72 +++--
> >>  drivers/pci/host/pci-brcmstb.h |  26 +++
> >>  5 files changed, 419 insertions(+), 10 deletions(-)
> >>  create mode 100644 drivers/pci/host/pci-brcmstb-msi.c
> >>
> >> diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
> >> index b9b4f11..54aa5d2 100644
> >> --- a/drivers/pci/host/Kconfig
> >> +++ b/drivers/pci/host/Kconfig
> >> @@ -228,4 +228,16 @@ config PCI_BRCMSTB
> >>   default ARCH_BRCMSTB || BMIPS_GENERIC
> >>   help
> >> Adds support for Broadcom Settop Box PCIe host controller.
> >> +   To compile this driver as a module, choose m here.
> >> +
> >> +config PCI_BRCMSTB_MSI
> >> + bool "Broadcom Brcmstb PCIe MSI support"
> >> + depends on ARCH_BRCMSTB || BMIPS_GENERIC
> >
> > This could probably be depends on PCI_BRCMSTB, which would imply these
> > two conditions. PCI_BRCMSTB_MSI on its own is probably not very useful
> > without the parent RC driver.
> >
> >> + depends on OF
> >> + depends on PCI_MSI
> >> + default PCI_BRCMSTB
> >> + help
> >> +   Say Y here if you want to enable MSI support for Broadcom's iProc
> >> +   PCIe controller
> >> +
> >>  endmenu
> >> diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
> >> index c283321..1026d6f 100644
> >> --- a/drivers/pci/host/Makefile
> >> +++ b/drivers/pci/host/Makefile
> >> @@ -23,6 +23,7 @@ obj-$(CONFIG_PCIE_TANGO_SMP8759) += pcie-tango.o
> >>  obj-$(CONFIG_VMD) += vmd.o
> >>  obj-$(CONFIG_PCI_BRCMSTB) += brcmstb-pci.o
> >>  brcmstb-pci-objs := pci-brcmstb.o pci-brcmstb-dma.o
> >> +obj-$(CONFIG_PCI_BRCMSTB_MSI) += pci-brcmstb-msi.o
> >
> > Should we combine this file with the brcmstb-pci.o? There is probably no
> > functional difference, except that pci-brcmstb-msi.ko needs to be loaded
> > first, right?
> > --
> > Florian
> 
> If you look at the pci/host/Kconfig you will see that other drivers
> also have a separate MSI config (eg iproc, altera, xgene) so there is
> precedent.  The reason that pci-brcmstb-msi.c is its own file is
> because it depends on an irq function that is not exported.  That is
> why CONFIG_PCI_BRCMSTB_MSI is bool, and CONFIG_PCI_BRCMSTB is
> tristate.  -- Jim

There is precedent, but that doesn't mean I like it :)
I would strongly prefer one file per driver when possible.

Take iproc for example.  iproc-msi.c is enabled by a Kconfig bool.  It
contains a bunch of code with the only external entry points being
iproc_msi_init() and iproc_msi_exit().  These are only called via
iproc_pcie_bcma_probe() or iproc_pcie_pltfm_probe(), both of which are
tristate.  So iproc-msi.c is only compiled if CONFIG_IPROC_BCMA or
CONFIG_IPROC_PLATFORM are enabled, but all that text is loaded even if
neither module is loaded, which seems suboptimal.

I don't care if you have several config options to enable the BCMA
probe and the platform probe (although these could probably be
replaced in the code by a simple "#ifdef CONFIG_BCMA" and "#ifdef
CONFIG_OF"), and making CONFIG_PCIE_IPROC tristate so it can be a
module makes sense.  But I think it would be better to put all the
code in one file instead of five, and probably remove
CONFIG_PCIE_IPROC_MSI.  Maybe this requires exporting some IRQ
function that currently isn't exported.  But that seems like a simpler
solution than what we currently have.

Bjorn

Re: [PATCH 6/8] PCI: host: brcmstb: add MSI capability

[Jim Quinlan]

On Wed, Oct 25, 2017 at 9:22 AM, Bjorn Helgaas  wrote:
> On Tue, Oct 24, 2017 at 02:15:47PM -0400, Jim Quinlan wrote:
>> This commit adds MSI to the Broadcom STB PCIe host controller. It does
>> not add MSIX since that functiostbsrvnality is not in the HW.  The MSI
>> controller is physically located within the PCIe block, however, there
>> is no reason why the MSI controller could not be moved elsewhere in
>> the future.
>>
>> Since the internal Brcmstb MSI controller is intertwined with the PCIe
>> controller, it is not its own platform device but rather part of the
>> PCIe platform device.
>>
>> Signed-off-by: Jim Quinlan 
>> ---
>>  drivers/pci/host/Kconfig   |  12 ++
>>  drivers/pci/host/Makefile  |   1 +
>>  drivers/pci/host/pci-brcmstb-msi.c | 318 
>> +
>>  drivers/pci/host/pci-brcmstb.c |  72 +++--
>>  drivers/pci/host/pci-brcmstb.h |  26 +++
>>  5 files changed, 419 insertions(+), 10 deletions(-)
>>  create mode 100644 drivers/pci/host/pci-brcmstb-msi.c
>>
>> diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
>> index b9b4f11..54aa5d2 100644
>> --- a/drivers/pci/host/Kconfig
>> +++ b/drivers/pci/host/Kconfig
>> @@ -228,4 +228,16 @@ config PCI_BRCMSTB
>>   default ARCH_BRCMSTB || BMIPS_GENERIC
>>   help
>> Adds support for Broadcom Settop Box PCIe host controller.
>> +   To compile this driver as a module, choose m here.
>> +
>> +config PCI_BRCMSTB_MSI
>> + bool "Broadcom Brcmstb PCIe MSI support"
>> + depends on ARCH_BRCMSTB || BMIPS_GENERIC
>> + depends on OF
>> + depends on PCI_MSI
>> + default PCI_BRCMSTB
>> + help
>> +   Say Y here if you want to enable MSI support for Broadcom's iProc
>> +   PCIe controller
>
> Is there any reason *not* to enable MSI?  Most drivers just include
> MSI support in the base driver, in the same file and under the same
> config symbol.
>
CONFIG_PCI_BRCMSTB_MSI is bool, CONFIG_PCI_BRCMSTB is tri-state.  The
reason for this -- and also for the separate msi file -- is that there
is an irq call  that is not exported (I can dig it up if you'd like).
We have had requests that the PCIe RC driver doesn't run at boot, so
we consider the idea of it being a module valuable.  You can see the
same thing going on with PCIE_IPROC_MSI.

>> +
>>  endmenu
>> diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
>> index c283321..1026d6f 100644
>> --- a/drivers/pci/host/Makefile
>> +++ b/drivers/pci/host/Makefile
>> @@ -23,6 +23,7 @@ obj-$(CONFIG_PCIE_TANGO_SMP8759) += pcie-tango.o
>>  obj-$(CONFIG_VMD) += vmd.o
>>  obj-$(CONFIG_PCI_BRCMSTB) += brcmstb-pci.o
>>  brcmstb-pci-objs := pci-brcmstb.o pci-brcmstb-dma.o
>> +obj-$(CONFIG_PCI_BRCMSTB_MSI) += pci-brcmstb-msi.o
>>
>>  # The following drivers are for devices that use the generic ACPI
>>  # pci_root.c driver but don't support standard ECAM config access.
>> diff --git a/drivers/pci/host/pci-brcmstb-msi.c 
>> b/drivers/pci/host/pci-brcmstb-msi.c
>> new file mode 100644
>> index 000..c805e2f
>> --- /dev/null
>> +++ b/drivers/pci/host/pci-brcmstb-msi.c
>> @@ -0,0 +1,318 @@
>> +/*
>> + * Copyright (C) 2015-2017 Broadcom
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> + * GNU General Public License for more details.
>> + *
>> + */
>
> Remove last blank line of comment and add a blank line between comment
> and #includes.
Will fix.

>
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include "pci-brcmstb.h"
>> +
>> +#define PCIE_MISC_MSI_DATA_CONFIG0x404c
>> +#define PCIE_MSI_INTR2_BASE  0x4500
>> +#define PCIE_MISC_MSI_BAR_CONFIG_LO  0x4044
>> +#define PCIE_MISC_MSI_BAR_CONFIG_HI  0x4048
>> +
>> +/* Offsets from PCIE_INTR2_CPU_BASE and PCIE_MSI_INTR2_BASE */
>> +#define STATUS   0x0
>> +#define SET  0x4
>> +#define CLR  0x8
>> +#define MASK_STATUS  0xc
>> +#define MASK_SET 0x10
>> +#define MASK_CLR 0x14
>> +
>> +struct brcm_msi {
>> + struct irq_domain *msi_domain;
>> + struct irq_domain *inner_domain;
>> + struct mutex lock; /* guards the alloc/free operations */
>> + u64 target_addr;
>> + int irq;
>> + /* intr_base is the base pointer for interrupt status/set/clr regs */
>> + 

Re: [PATCH 6/8] PCI: host: brcmstb: add MSI capability

[Jim Quinlan]

On Wed, Oct 25, 2017 at 9:22 AM, Bjorn Helgaas  wrote:
> On Tue, Oct 24, 2017 at 02:15:47PM -0400, Jim Quinlan wrote:
>> This commit adds MSI to the Broadcom STB PCIe host controller. It does
>> not add MSIX since that functiostbsrvnality is not in the HW.  The MSI
>> controller is physically located within the PCIe block, however, there
>> is no reason why the MSI controller could not be moved elsewhere in
>> the future.
>>
>> Since the internal Brcmstb MSI controller is intertwined with the PCIe
>> controller, it is not its own platform device but rather part of the
>> PCIe platform device.
>>
>> Signed-off-by: Jim Quinlan 
>> ---
>>  drivers/pci/host/Kconfig   |  12 ++
>>  drivers/pci/host/Makefile  |   1 +
>>  drivers/pci/host/pci-brcmstb-msi.c | 318 
>> +
>>  drivers/pci/host/pci-brcmstb.c |  72 +++--
>>  drivers/pci/host/pci-brcmstb.h |  26 +++
>>  5 files changed, 419 insertions(+), 10 deletions(-)
>>  create mode 100644 drivers/pci/host/pci-brcmstb-msi.c
>>
>> diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
>> index b9b4f11..54aa5d2 100644
>> --- a/drivers/pci/host/Kconfig
>> +++ b/drivers/pci/host/Kconfig
>> @@ -228,4 +228,16 @@ config PCI_BRCMSTB
>>   default ARCH_BRCMSTB || BMIPS_GENERIC
>>   help
>> Adds support for Broadcom Settop Box PCIe host controller.
>> +   To compile this driver as a module, choose m here.
>> +
>> +config PCI_BRCMSTB_MSI
>> + bool "Broadcom Brcmstb PCIe MSI support"
>> + depends on ARCH_BRCMSTB || BMIPS_GENERIC
>> + depends on OF
>> + depends on PCI_MSI
>> + default PCI_BRCMSTB
>> + help
>> +   Say Y here if you want to enable MSI support for Broadcom's iProc
>> +   PCIe controller
>
> Is there any reason *not* to enable MSI?  Most drivers just include
> MSI support in the base driver, in the same file and under the same
> config symbol.
>
CONFIG_PCI_BRCMSTB_MSI is bool, CONFIG_PCI_BRCMSTB is tri-state.  The
reason for this -- and also for the separate msi file -- is that there
is an irq call  that is not exported (I can dig it up if you'd like).
We have had requests that the PCIe RC driver doesn't run at boot, so
we consider the idea of it being a module valuable.  You can see the
same thing going on with PCIE_IPROC_MSI.

>> +
>>  endmenu
>> diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
>> index c283321..1026d6f 100644
>> --- a/drivers/pci/host/Makefile
>> +++ b/drivers/pci/host/Makefile
>> @@ -23,6 +23,7 @@ obj-$(CONFIG_PCIE_TANGO_SMP8759) += pcie-tango.o
>>  obj-$(CONFIG_VMD) += vmd.o
>>  obj-$(CONFIG_PCI_BRCMSTB) += brcmstb-pci.o
>>  brcmstb-pci-objs := pci-brcmstb.o pci-brcmstb-dma.o
>> +obj-$(CONFIG_PCI_BRCMSTB_MSI) += pci-brcmstb-msi.o
>>
>>  # The following drivers are for devices that use the generic ACPI
>>  # pci_root.c driver but don't support standard ECAM config access.
>> diff --git a/drivers/pci/host/pci-brcmstb-msi.c 
>> b/drivers/pci/host/pci-brcmstb-msi.c
>> new file mode 100644
>> index 000..c805e2f
>> --- /dev/null
>> +++ b/drivers/pci/host/pci-brcmstb-msi.c
>> @@ -0,0 +1,318 @@
>> +/*
>> + * Copyright (C) 2015-2017 Broadcom
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> + * GNU General Public License for more details.
>> + *
>> + */
>
> Remove last blank line of comment and add a blank line between comment
> and #includes.
Will fix.

>
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include "pci-brcmstb.h"
>> +
>> +#define PCIE_MISC_MSI_DATA_CONFIG0x404c
>> +#define PCIE_MSI_INTR2_BASE  0x4500
>> +#define PCIE_MISC_MSI_BAR_CONFIG_LO  0x4044
>> +#define PCIE_MISC_MSI_BAR_CONFIG_HI  0x4048
>> +
>> +/* Offsets from PCIE_INTR2_CPU_BASE and PCIE_MSI_INTR2_BASE */
>> +#define STATUS   0x0
>> +#define SET  0x4
>> +#define CLR  0x8
>> +#define MASK_STATUS  0xc
>> +#define MASK_SET 0x10
>> +#define MASK_CLR 0x14
>> +
>> +struct brcm_msi {
>> + struct irq_domain *msi_domain;
>> + struct irq_domain *inner_domain;
>> + struct mutex lock; /* guards the alloc/free operations */
>> + u64 target_addr;
>> + int irq;
>> + /* intr_base is the base pointer for interrupt status/set/clr regs */
>> + void __iomem *intr_base;
>> + /* 

Re: [PATCH 6/8] PCI: host: brcmstb: add MSI capability

[Jim Quinlan]

On Tue, Oct 24, 2017 at 2:57 PM, Florian Fainelli  wrote:
> Hi Jim,
>
> On 10/24/2017 11:15 AM, Jim Quinlan wrote:
>> This commit adds MSI to the Broadcom STB PCIe host controller. It does
>> not add MSIX since that functionality is not in the HW.  The MSI
>> controller is physically located within the PCIe block, however, there
>> is no reason why the MSI controller could not be moved elsewhere in
>> the future.
>>
>> Since the internal Brcmstb MSI controller is intertwined with the PCIe
>> controller, it is not its own platform device but rather part of the
>> PCIe platform device.
>>
>> Signed-off-by: Jim Quinlan 
>> ---
>>  drivers/pci/host/Kconfig   |  12 ++
>>  drivers/pci/host/Makefile  |   1 +
>>  drivers/pci/host/pci-brcmstb-msi.c | 318 
>> +
>>  drivers/pci/host/pci-brcmstb.c |  72 +++--
>>  drivers/pci/host/pci-brcmstb.h |  26 +++
>>  5 files changed, 419 insertions(+), 10 deletions(-)
>>  create mode 100644 drivers/pci/host/pci-brcmstb-msi.c
>>
>> diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
>> index b9b4f11..54aa5d2 100644
>> --- a/drivers/pci/host/Kconfig
>> +++ b/drivers/pci/host/Kconfig
>> @@ -228,4 +228,16 @@ config PCI_BRCMSTB
>>   default ARCH_BRCMSTB || BMIPS_GENERIC
>>   help
>> Adds support for Broadcom Settop Box PCIe host controller.
>> +   To compile this driver as a module, choose m here.
>> +
>> +config PCI_BRCMSTB_MSI
>> + bool "Broadcom Brcmstb PCIe MSI support"
>> + depends on ARCH_BRCMSTB || BMIPS_GENERIC
>
> This could probably be depends on PCI_BRCMSTB, which would imply these
> two conditions. PCI_BRCMSTB_MSI on its own is probably not very useful
> without the parent RC driver.
>
>> + depends on OF
>> + depends on PCI_MSI
>> + default PCI_BRCMSTB
>> + help
>> +   Say Y here if you want to enable MSI support for Broadcom's iProc
>> +   PCIe controller
>> +
>>  endmenu
>> diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
>> index c283321..1026d6f 100644
>> --- a/drivers/pci/host/Makefile
>> +++ b/drivers/pci/host/Makefile
>> @@ -23,6 +23,7 @@ obj-$(CONFIG_PCIE_TANGO_SMP8759) += pcie-tango.o
>>  obj-$(CONFIG_VMD) += vmd.o
>>  obj-$(CONFIG_PCI_BRCMSTB) += brcmstb-pci.o
>>  brcmstb-pci-objs := pci-brcmstb.o pci-brcmstb-dma.o
>> +obj-$(CONFIG_PCI_BRCMSTB_MSI) += pci-brcmstb-msi.o
>
> Should we combine this file with the brcmstb-pci.o? There is probably no
> functional difference, except that pci-brcmstb-msi.ko needs to be loaded
> first, right?
> --
> Florian

If you look at the pci/host/Kconfig you will see that other drivers
also have a separate MSI config (eg iproc, altera, xgene) so there is
precedent.  The reason that pci-brcmstb-msi.c is its own file is
because it depends on an irq function that is not exported.  That is
why CONFIG_PCI_BRCMSTB_MSI is bool, and CONFIG_PCI_BRCMSTB is
tristate.  -- Jim

Re: [PATCH 6/8] PCI: host: brcmstb: add MSI capability

[Jim Quinlan]

On Tue, Oct 24, 2017 at 2:57 PM, Florian Fainelli  wrote:
> Hi Jim,
>
> On 10/24/2017 11:15 AM, Jim Quinlan wrote:
>> This commit adds MSI to the Broadcom STB PCIe host controller. It does
>> not add MSIX since that functionality is not in the HW.  The MSI
>> controller is physically located within the PCIe block, however, there
>> is no reason why the MSI controller could not be moved elsewhere in
>> the future.
>>
>> Since the internal Brcmstb MSI controller is intertwined with the PCIe
>> controller, it is not its own platform device but rather part of the
>> PCIe platform device.
>>
>> Signed-off-by: Jim Quinlan 
>> ---
>>  drivers/pci/host/Kconfig   |  12 ++
>>  drivers/pci/host/Makefile  |   1 +
>>  drivers/pci/host/pci-brcmstb-msi.c | 318 
>> +
>>  drivers/pci/host/pci-brcmstb.c |  72 +++--
>>  drivers/pci/host/pci-brcmstb.h |  26 +++
>>  5 files changed, 419 insertions(+), 10 deletions(-)
>>  create mode 100644 drivers/pci/host/pci-brcmstb-msi.c
>>
>> diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
>> index b9b4f11..54aa5d2 100644
>> --- a/drivers/pci/host/Kconfig
>> +++ b/drivers/pci/host/Kconfig
>> @@ -228,4 +228,16 @@ config PCI_BRCMSTB
>>   default ARCH_BRCMSTB || BMIPS_GENERIC
>>   help
>> Adds support for Broadcom Settop Box PCIe host controller.
>> +   To compile this driver as a module, choose m here.
>> +
>> +config PCI_BRCMSTB_MSI
>> + bool "Broadcom Brcmstb PCIe MSI support"
>> + depends on ARCH_BRCMSTB || BMIPS_GENERIC
>
> This could probably be depends on PCI_BRCMSTB, which would imply these
> two conditions. PCI_BRCMSTB_MSI on its own is probably not very useful
> without the parent RC driver.
>
>> + depends on OF
>> + depends on PCI_MSI
>> + default PCI_BRCMSTB
>> + help
>> +   Say Y here if you want to enable MSI support for Broadcom's iProc
>> +   PCIe controller
>> +
>>  endmenu
>> diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
>> index c283321..1026d6f 100644
>> --- a/drivers/pci/host/Makefile
>> +++ b/drivers/pci/host/Makefile
>> @@ -23,6 +23,7 @@ obj-$(CONFIG_PCIE_TANGO_SMP8759) += pcie-tango.o
>>  obj-$(CONFIG_VMD) += vmd.o
>>  obj-$(CONFIG_PCI_BRCMSTB) += brcmstb-pci.o
>>  brcmstb-pci-objs := pci-brcmstb.o pci-brcmstb-dma.o
>> +obj-$(CONFIG_PCI_BRCMSTB_MSI) += pci-brcmstb-msi.o
>
> Should we combine this file with the brcmstb-pci.o? There is probably no
> functional difference, except that pci-brcmstb-msi.ko needs to be loaded
> first, right?
> --
> Florian

If you look at the pci/host/Kconfig you will see that other drivers
also have a separate MSI config (eg iproc, altera, xgene) so there is
precedent.  The reason that pci-brcmstb-msi.c is its own file is
because it depends on an irq function that is not exported.  That is
why CONFIG_PCI_BRCMSTB_MSI is bool, and CONFIG_PCI_BRCMSTB is
tristate.  -- Jim

Re: [PATCH 6/8] PCI: host: brcmstb: add MSI capability

[Bjorn Helgaas]

On Tue, Oct 24, 2017 at 02:15:47PM -0400, Jim Quinlan wrote:
> This commit adds MSI to the Broadcom STB PCIe host controller. It does
> not add MSIX since that functionality is not in the HW.  The MSI
> controller is physically located within the PCIe block, however, there
> is no reason why the MSI controller could not be moved elsewhere in
> the future.
> 
> Since the internal Brcmstb MSI controller is intertwined with the PCIe
> controller, it is not its own platform device but rather part of the
> PCIe platform device.
> 
> Signed-off-by: Jim Quinlan 
> ---
>  drivers/pci/host/Kconfig   |  12 ++
>  drivers/pci/host/Makefile  |   1 +
>  drivers/pci/host/pci-brcmstb-msi.c | 318 
> +
>  drivers/pci/host/pci-brcmstb.c |  72 +++--
>  drivers/pci/host/pci-brcmstb.h |  26 +++
>  5 files changed, 419 insertions(+), 10 deletions(-)
>  create mode 100644 drivers/pci/host/pci-brcmstb-msi.c
> 
> diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
> index b9b4f11..54aa5d2 100644
> --- a/drivers/pci/host/Kconfig
> +++ b/drivers/pci/host/Kconfig
> @@ -228,4 +228,16 @@ config PCI_BRCMSTB
>   default ARCH_BRCMSTB || BMIPS_GENERIC
>   help
> Adds support for Broadcom Settop Box PCIe host controller.
> +   To compile this driver as a module, choose m here.
> +
> +config PCI_BRCMSTB_MSI
> + bool "Broadcom Brcmstb PCIe MSI support"
> + depends on ARCH_BRCMSTB || BMIPS_GENERIC
> + depends on OF
> + depends on PCI_MSI
> + default PCI_BRCMSTB
> + help
> +   Say Y here if you want to enable MSI support for Broadcom's iProc
> +   PCIe controller

Is there any reason *not* to enable MSI?  Most drivers just include
MSI support in the base driver, in the same file and under the same
config symbol.

> +
>  endmenu
> diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
> index c283321..1026d6f 100644
> --- a/drivers/pci/host/Makefile
> +++ b/drivers/pci/host/Makefile
> @@ -23,6 +23,7 @@ obj-$(CONFIG_PCIE_TANGO_SMP8759) += pcie-tango.o
>  obj-$(CONFIG_VMD) += vmd.o
>  obj-$(CONFIG_PCI_BRCMSTB) += brcmstb-pci.o
>  brcmstb-pci-objs := pci-brcmstb.o pci-brcmstb-dma.o
> +obj-$(CONFIG_PCI_BRCMSTB_MSI) += pci-brcmstb-msi.o
>  
>  # The following drivers are for devices that use the generic ACPI
>  # pci_root.c driver but don't support standard ECAM config access.
> diff --git a/drivers/pci/host/pci-brcmstb-msi.c 
> b/drivers/pci/host/pci-brcmstb-msi.c
> new file mode 100644
> index 000..c805e2f
> --- /dev/null
> +++ b/drivers/pci/host/pci-brcmstb-msi.c
> @@ -0,0 +1,318 @@
> +/*
> + * Copyright (C) 2015-2017 Broadcom
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + */

Remove last blank line of comment and add a blank line between comment
and #includes.

> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "pci-brcmstb.h"
> +
> +#define PCIE_MISC_MSI_DATA_CONFIG0x404c
> +#define PCIE_MSI_INTR2_BASE  0x4500
> +#define PCIE_MISC_MSI_BAR_CONFIG_LO  0x4044
> +#define PCIE_MISC_MSI_BAR_CONFIG_HI  0x4048
> +
> +/* Offsets from PCIE_INTR2_CPU_BASE and PCIE_MSI_INTR2_BASE */
> +#define STATUS   0x0
> +#define SET  0x4
> +#define CLR  0x8
> +#define MASK_STATUS  0xc
> +#define MASK_SET 0x10
> +#define MASK_CLR 0x14
> +
> +struct brcm_msi {
> + struct irq_domain *msi_domain;
> + struct irq_domain *inner_domain;
> + struct mutex lock; /* guards the alloc/free operations */
> + u64 target_addr;
> + int irq;
> + /* intr_base is the base pointer for interrupt status/set/clr regs */
> + void __iomem *intr_base;
> + /* intr_legacy_mask indicates how many bits are MSI interrupts */
> + u32 intr_legacy_mask;
> + /* intr_legacy_offset indicates bit position of MSI_01. It is
> +  * to map the register bit position to a hwirq that starts at 0.
> +  */
> + u32 intr_legacy_offset;
> + /* used indicates which MSI interrupts have been alloc'd */
> + unsigned long used;
> +
> + void __iomem *base;
> + struct device *dev;
> + struct device_node *dn;
> + unsigned int rev;
> +};
> +
> +static struct irq_chip brcm_msi_irq_chip = {
> + .name = 

Re: [PATCH 6/8] PCI: host: brcmstb: add MSI capability

[Bjorn Helgaas]

On Tue, Oct 24, 2017 at 02:15:47PM -0400, Jim Quinlan wrote:
> This commit adds MSI to the Broadcom STB PCIe host controller. It does
> not add MSIX since that functionality is not in the HW.  The MSI
> controller is physically located within the PCIe block, however, there
> is no reason why the MSI controller could not be moved elsewhere in
> the future.
> 
> Since the internal Brcmstb MSI controller is intertwined with the PCIe
> controller, it is not its own platform device but rather part of the
> PCIe platform device.
> 
> Signed-off-by: Jim Quinlan 
> ---
>  drivers/pci/host/Kconfig   |  12 ++
>  drivers/pci/host/Makefile  |   1 +
>  drivers/pci/host/pci-brcmstb-msi.c | 318 
> +
>  drivers/pci/host/pci-brcmstb.c |  72 +++--
>  drivers/pci/host/pci-brcmstb.h |  26 +++
>  5 files changed, 419 insertions(+), 10 deletions(-)
>  create mode 100644 drivers/pci/host/pci-brcmstb-msi.c
> 
> diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
> index b9b4f11..54aa5d2 100644
> --- a/drivers/pci/host/Kconfig
> +++ b/drivers/pci/host/Kconfig
> @@ -228,4 +228,16 @@ config PCI_BRCMSTB
>   default ARCH_BRCMSTB || BMIPS_GENERIC
>   help
> Adds support for Broadcom Settop Box PCIe host controller.
> +   To compile this driver as a module, choose m here.
> +
> +config PCI_BRCMSTB_MSI
> + bool "Broadcom Brcmstb PCIe MSI support"
> + depends on ARCH_BRCMSTB || BMIPS_GENERIC
> + depends on OF
> + depends on PCI_MSI
> + default PCI_BRCMSTB
> + help
> +   Say Y here if you want to enable MSI support for Broadcom's iProc
> +   PCIe controller

Is there any reason *not* to enable MSI?  Most drivers just include
MSI support in the base driver, in the same file and under the same
config symbol.

> +
>  endmenu
> diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
> index c283321..1026d6f 100644
> --- a/drivers/pci/host/Makefile
> +++ b/drivers/pci/host/Makefile
> @@ -23,6 +23,7 @@ obj-$(CONFIG_PCIE_TANGO_SMP8759) += pcie-tango.o
>  obj-$(CONFIG_VMD) += vmd.o
>  obj-$(CONFIG_PCI_BRCMSTB) += brcmstb-pci.o
>  brcmstb-pci-objs := pci-brcmstb.o pci-brcmstb-dma.o
> +obj-$(CONFIG_PCI_BRCMSTB_MSI) += pci-brcmstb-msi.o
>  
>  # The following drivers are for devices that use the generic ACPI
>  # pci_root.c driver but don't support standard ECAM config access.
> diff --git a/drivers/pci/host/pci-brcmstb-msi.c 
> b/drivers/pci/host/pci-brcmstb-msi.c
> new file mode 100644
> index 000..c805e2f
> --- /dev/null
> +++ b/drivers/pci/host/pci-brcmstb-msi.c
> @@ -0,0 +1,318 @@
> +/*
> + * Copyright (C) 2015-2017 Broadcom
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + */

Remove last blank line of comment and add a blank line between comment
and #includes.

> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "pci-brcmstb.h"
> +
> +#define PCIE_MISC_MSI_DATA_CONFIG0x404c
> +#define PCIE_MSI_INTR2_BASE  0x4500
> +#define PCIE_MISC_MSI_BAR_CONFIG_LO  0x4044
> +#define PCIE_MISC_MSI_BAR_CONFIG_HI  0x4048
> +
> +/* Offsets from PCIE_INTR2_CPU_BASE and PCIE_MSI_INTR2_BASE */
> +#define STATUS   0x0
> +#define SET  0x4
> +#define CLR  0x8
> +#define MASK_STATUS  0xc
> +#define MASK_SET 0x10
> +#define MASK_CLR 0x14
> +
> +struct brcm_msi {
> + struct irq_domain *msi_domain;
> + struct irq_domain *inner_domain;
> + struct mutex lock; /* guards the alloc/free operations */
> + u64 target_addr;
> + int irq;
> + /* intr_base is the base pointer for interrupt status/set/clr regs */
> + void __iomem *intr_base;
> + /* intr_legacy_mask indicates how many bits are MSI interrupts */
> + u32 intr_legacy_mask;
> + /* intr_legacy_offset indicates bit position of MSI_01. It is
> +  * to map the register bit position to a hwirq that starts at 0.
> +  */
> + u32 intr_legacy_offset;
> + /* used indicates which MSI interrupts have been alloc'd */
> + unsigned long used;
> +
> + void __iomem *base;
> + struct device *dev;
> + struct device_node *dn;
> + unsigned int rev;
> +};
> +
> +static struct irq_chip brcm_msi_irq_chip = {
> + .name = "Brcm_MSI",
> + 

Re: [PATCH 6/8] PCI: host: brcmstb: add MSI capability

[Florian Fainelli]

Hi Jim,

On 10/24/2017 11:15 AM, Jim Quinlan wrote:
> This commit adds MSI to the Broadcom STB PCIe host controller. It does
> not add MSIX since that functionality is not in the HW.  The MSI
> controller is physically located within the PCIe block, however, there
> is no reason why the MSI controller could not be moved elsewhere in
> the future.
> 
> Since the internal Brcmstb MSI controller is intertwined with the PCIe
> controller, it is not its own platform device but rather part of the
> PCIe platform device.
> 
> Signed-off-by: Jim Quinlan 
> ---
>  drivers/pci/host/Kconfig   |  12 ++
>  drivers/pci/host/Makefile  |   1 +
>  drivers/pci/host/pci-brcmstb-msi.c | 318 
> +
>  drivers/pci/host/pci-brcmstb.c |  72 +++--
>  drivers/pci/host/pci-brcmstb.h |  26 +++
>  5 files changed, 419 insertions(+), 10 deletions(-)
>  create mode 100644 drivers/pci/host/pci-brcmstb-msi.c
> 
> diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
> index b9b4f11..54aa5d2 100644
> --- a/drivers/pci/host/Kconfig
> +++ b/drivers/pci/host/Kconfig
> @@ -228,4 +228,16 @@ config PCI_BRCMSTB
>   default ARCH_BRCMSTB || BMIPS_GENERIC
>   help
> Adds support for Broadcom Settop Box PCIe host controller.
> +   To compile this driver as a module, choose m here.
> +
> +config PCI_BRCMSTB_MSI
> + bool "Broadcom Brcmstb PCIe MSI support"
> + depends on ARCH_BRCMSTB || BMIPS_GENERIC

This could probably be depends on PCI_BRCMSTB, which would imply these
two conditions. PCI_BRCMSTB_MSI on its own is probably not very useful
without the parent RC driver.

> + depends on OF
> + depends on PCI_MSI
> + default PCI_BRCMSTB
> + help
> +   Say Y here if you want to enable MSI support for Broadcom's iProc
> +   PCIe controller
> +
>  endmenu
> diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
> index c283321..1026d6f 100644
> --- a/drivers/pci/host/Makefile
> +++ b/drivers/pci/host/Makefile
> @@ -23,6 +23,7 @@ obj-$(CONFIG_PCIE_TANGO_SMP8759) += pcie-tango.o
>  obj-$(CONFIG_VMD) += vmd.o
>  obj-$(CONFIG_PCI_BRCMSTB) += brcmstb-pci.o
>  brcmstb-pci-objs := pci-brcmstb.o pci-brcmstb-dma.o
> +obj-$(CONFIG_PCI_BRCMSTB_MSI) += pci-brcmstb-msi.o

Should we combine this file with the brcmstb-pci.o? There is probably no
functional difference, except that pci-brcmstb-msi.ko needs to be loaded
first, right?
-- 
Florian

Re: [PATCH 6/8] PCI: host: brcmstb: add MSI capability

[Florian Fainelli]

Hi Jim,

On 10/24/2017 11:15 AM, Jim Quinlan wrote:
> This commit adds MSI to the Broadcom STB PCIe host controller. It does
> not add MSIX since that functionality is not in the HW.  The MSI
> controller is physically located within the PCIe block, however, there
> is no reason why the MSI controller could not be moved elsewhere in
> the future.
> 
> Since the internal Brcmstb MSI controller is intertwined with the PCIe
> controller, it is not its own platform device but rather part of the
> PCIe platform device.
> 
> Signed-off-by: Jim Quinlan 
> ---
>  drivers/pci/host/Kconfig   |  12 ++
>  drivers/pci/host/Makefile  |   1 +
>  drivers/pci/host/pci-brcmstb-msi.c | 318 
> +
>  drivers/pci/host/pci-brcmstb.c |  72 +++--
>  drivers/pci/host/pci-brcmstb.h |  26 +++
>  5 files changed, 419 insertions(+), 10 deletions(-)
>  create mode 100644 drivers/pci/host/pci-brcmstb-msi.c
> 
> diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
> index b9b4f11..54aa5d2 100644
> --- a/drivers/pci/host/Kconfig
> +++ b/drivers/pci/host/Kconfig
> @@ -228,4 +228,16 @@ config PCI_BRCMSTB
>   default ARCH_BRCMSTB || BMIPS_GENERIC
>   help
> Adds support for Broadcom Settop Box PCIe host controller.
> +   To compile this driver as a module, choose m here.
> +
> +config PCI_BRCMSTB_MSI
> + bool "Broadcom Brcmstb PCIe MSI support"
> + depends on ARCH_BRCMSTB || BMIPS_GENERIC

This could probably be depends on PCI_BRCMSTB, which would imply these
two conditions. PCI_BRCMSTB_MSI on its own is probably not very useful
without the parent RC driver.

> + depends on OF
> + depends on PCI_MSI
> + default PCI_BRCMSTB
> + help
> +   Say Y here if you want to enable MSI support for Broadcom's iProc
> +   PCIe controller
> +
>  endmenu
> diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
> index c283321..1026d6f 100644
> --- a/drivers/pci/host/Makefile
> +++ b/drivers/pci/host/Makefile
> @@ -23,6 +23,7 @@ obj-$(CONFIG_PCIE_TANGO_SMP8759) += pcie-tango.o
>  obj-$(CONFIG_VMD) += vmd.o
>  obj-$(CONFIG_PCI_BRCMSTB) += brcmstb-pci.o
>  brcmstb-pci-objs := pci-brcmstb.o pci-brcmstb-dma.o
> +obj-$(CONFIG_PCI_BRCMSTB_MSI) += pci-brcmstb-msi.o

Should we combine this file with the brcmstb-pci.o? There is probably no
functional difference, except that pci-brcmstb-msi.ko needs to be loaded
first, right?
-- 
Florian