public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Marc Zyngier <marc.zyngier@arm.com>
To: "J. German Rivera" <German.Rivera@freescale.com>,
	gregkh@linuxfoundation.org, arnd@arndb.de,
	devel@driverdev.osuosl.org, linux-kernel@vger.kernel.org
Cc: stuart.yoder@freescale.com, itai.katz@freescale.com,
	lijun.pan@freescale.com, leoli@freescale.com,
	scottwood@freescale.com, agraf@suse.de, bhamciu1@freescale.com,
	R89243@freescale.com, bhupesh.sharma@freescale.com,
	nir.erez@freescale.com, richard.schmitt@freescale.com,
	dan.carpenter@oracle.com, jiang.liu@linux.intel.com
Subject: Re: [PATCH v2 03/11] staging: fsl-mc: Added generic MSI support for FSL-MC devices
Date: Fri, 06 Nov 2015 17:50:51 +0000	[thread overview]
Message-ID: <563CE87B.9040107@arm.com> (raw)
In-Reply-To: <1446234217-25512-4-git-send-email-German.Rivera@freescale.com>

On 30/10/15 19:43, J. German Rivera wrote:
> Created an MSI domain for the fsl-mc bus-- including functions
> to create a domain, find a domain, alloc/free domain irqs, and
> bus specific overrides for domain and irq_chip ops.
> 
> Signed-off-by: J. German Rivera <German.Rivera@freescale.com>
> ---
> Changes in v2: none
> 
>  drivers/staging/fsl-mc/bus/Kconfig          |   1 +
>  drivers/staging/fsl-mc/bus/Makefile         |   1 +
>  drivers/staging/fsl-mc/bus/mc-msi.c         | 276 ++++++++++++++++++++++++++++
>  drivers/staging/fsl-mc/include/mc-private.h |  17 ++
>  drivers/staging/fsl-mc/include/mc.h         |  17 ++
>  5 files changed, 312 insertions(+)
>  create mode 100644 drivers/staging/fsl-mc/bus/mc-msi.c
> 
> diff --git a/drivers/staging/fsl-mc/bus/Kconfig b/drivers/staging/fsl-mc/bus/Kconfig
> index 0d779d9..c498ac6 100644
> --- a/drivers/staging/fsl-mc/bus/Kconfig
> +++ b/drivers/staging/fsl-mc/bus/Kconfig
> @@ -9,6 +9,7 @@
>  config FSL_MC_BUS
>  	tristate "Freescale Management Complex (MC) bus driver"
>  	depends on OF && ARM64
> +	select GENERIC_MSI_IRQ_DOMAIN
>  	help
>  	  Driver to enable the bus infrastructure for the Freescale
>            QorIQ Management Complex (fsl-mc). The fsl-mc is a hardware
> diff --git a/drivers/staging/fsl-mc/bus/Makefile b/drivers/staging/fsl-mc/bus/Makefile
> index 25433a9..a5f2ba4 100644
> --- a/drivers/staging/fsl-mc/bus/Makefile
> +++ b/drivers/staging/fsl-mc/bus/Makefile
> @@ -13,5 +13,6 @@ mc-bus-driver-objs := mc-bus.o \
>  		      dpmng.o \
>  		      dprc-driver.o \
>  		      mc-allocator.o \
> +		      mc-msi.o \
>  		      dpmcp.o \
>  		      dpbp.o
> diff --git a/drivers/staging/fsl-mc/bus/mc-msi.c b/drivers/staging/fsl-mc/bus/mc-msi.c
> new file mode 100644
> index 0000000..81b53e3
> --- /dev/null
> +++ b/drivers/staging/fsl-mc/bus/mc-msi.c
> @@ -0,0 +1,276 @@
> +/*
> + * Freescale Management Complex (MC) bus driver MSI support
> + *
> + * Copyright (C) 2015 Freescale Semiconductor, Inc.
> + * Author: German Rivera <German.Rivera@freescale.com>
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2. This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +
> +#include "../include/mc-private.h"
> +#include <linux/of_device.h>
> +#include <linux/of_address.h>
> +#include <linux/irqchip/arm-gic-v3.h>
> +#include <linux/irq.h>
> +#include <linux/irqdomain.h>
> +#include <linux/msi.h>
> +#include "../include/mc-sys.h"
> +#include "dprc-cmd.h"
> +
> +static void fsl_mc_msi_set_desc(msi_alloc_info_t *arg,
> +				struct msi_desc *desc)
> +{
> +	arg->desc = desc;
> +	arg->hwirq = (irq_hw_number_t)desc->fsl_mc.msi_index;
> +}
> +
> +static void fsl_mc_msi_update_dom_ops(struct msi_domain_info *info)
> +{
> +	struct msi_domain_ops *ops = info->ops;
> +
> +	if (WARN_ON(!ops))
> +		return;
> +
> +	if (!ops->set_desc)
> +		ops->set_desc = fsl_mc_msi_set_desc;

When would that be overridden by the MSI controller?

> +}
> +
> +static void __fsl_mc_msi_write_msg(struct fsl_mc_device *mc_bus_dev,
> +				   struct fsl_mc_device_irq *mc_dev_irq)
> +{
> +	int error;
> +	struct fsl_mc_device *owner_mc_dev = mc_dev_irq->mc_dev;
> +	struct msi_desc *msi_desc = mc_dev_irq->msi_desc;
> +	struct dprc_irq_cfg irq_cfg;
> +
> +	/*
> +	 * msi_desc->msg.address is 0x0 when this function is invoked in
> +	 * the free_irq() code path. In this case, for the MC, we don't
> +	 * really need to "unprogram" the MSI, so we just return.
> +	 */
> +	if (msi_desc->msg.address_lo == 0x0 && msi_desc->msg.address_hi == 0x0)
> +		return;
> +
> +	if (WARN_ON(!owner_mc_dev))
> +		return;
> +
> +	irq_cfg.paddr = ((u64)msi_desc->msg.address_hi << 32) |
> +			msi_desc->msg.address_lo;

This should really be a phys_addr_t.

> +	irq_cfg.val = msi_desc->msg.data;
> +	irq_cfg.user_irq_id = msi_desc->irq;
> +
> +	/*
> +	 * DPRCs and other objects use different commands to set up IRQs,
> +	 * so we have to differentiate them here.
> +	 */
> +	if (owner_mc_dev == mc_bus_dev) {
> +		/*
> +		 * IRQ is for the mc_bus_dev's DPRC itself
> +		 */
> +		error = dprc_set_irq(mc_bus_dev->mc_io,
> +				     MC_CMD_FLAG_INTR_DIS | MC_CMD_FLAG_PRI,
> +				     mc_bus_dev->mc_handle,
> +				     mc_dev_irq->dev_irq_index,
> +				     &irq_cfg);
> +		if (error < 0) {
> +			dev_err(&owner_mc_dev->dev,
> +				"dprc_set_irq() failed: %d\n", error);
> +		}
> +	} else {
> +		error = dprc_set_obj_irq(mc_bus_dev->mc_io,
> +					 MC_CMD_FLAG_INTR_DIS | MC_CMD_FLAG_PRI,
> +					 mc_bus_dev->mc_handle,
> +					 owner_mc_dev->obj_desc.type,
> +					 owner_mc_dev->obj_desc.id,
> +					 mc_dev_irq->dev_irq_index,
> +					 &irq_cfg);
> +		if (error < 0) {
> +			dev_err(&owner_mc_dev->dev,
> +				"dprc_obj_set_irq() failed: %d\n", error);
> +		}
> +	}

It feels a bit odd that you have all of this under a single MSI
umbrella, and yet have to differentiate between them. Do they have a
different programming interface? Or is that because these dprc_set_*_irq
functions do some other stuff behind the scene (I'm too lazy to check...)?

> +}
> +
> +/*
> + * NOTE: This function is invoked with interrupts disabled
> + */
> +static void fsl_mc_msi_write_msg(struct irq_data *irq_data,
> +				 struct msi_msg *msg)
> +{
> +	struct msi_desc *msi_desc = irq_data_get_msi_desc(irq_data);
> +	struct fsl_mc_device *mc_bus_dev = to_fsl_mc_device(msi_desc->dev);
> +	struct fsl_mc_bus *mc_bus = to_fsl_mc_bus(mc_bus_dev);
> +	struct fsl_mc_device_irq *mc_dev_irq =
> +		&mc_bus->irq_resources[msi_desc->fsl_mc.msi_index];
> +
> +	WARN_ON(mc_dev_irq->msi_desc != msi_desc);
> +	msi_desc->msg = *msg;

I wonder why we don't do that in core code...

> +
> +	/*
> +	 * Program the MSI (paddr, value) pair in the device:
> +	 */
> +	__fsl_mc_msi_write_msg(mc_bus_dev, mc_dev_irq);
> +}
> +
> +static void fsl_mc_msi_update_chip_ops(struct msi_domain_info *info)
> +{
> +	struct irq_chip *chip = info->chip;
> +
> +	if (WARN_ON((!chip)))
> +		return;
> +
> +	if (!chip->irq_write_msi_msg)
> +		chip->irq_write_msi_msg = fsl_mc_msi_write_msg;

Same as above. Do you foresee any circumstances where you you wouldn't
use this function? My hunch is that you should warn if
chip->irq_write_msi_msg is provided by the caller.

> +}

[...]

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...

  reply	other threads:[~2015-11-06 17:50 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-30 19:43 [PATCH v2 00/11] staging: fsl-mc: MC bus MSI support J. German Rivera
2015-10-30 19:43 ` [PATCH v2 01/11] irqdomain: Added domain bus token DOMAIN_BUS_FSL_MC_MSI J. German Rivera
2015-11-06  1:56   ` Jiang Liu
2015-10-30 19:43 ` [PATCH v2 02/11] fsl-mc: msi: Added FSL-MC-specific member to the msi_desc's union J. German Rivera
2015-11-06  1:59   ` Jiang Liu
2015-10-30 19:43 ` [PATCH v2 03/11] staging: fsl-mc: Added generic MSI support for FSL-MC devices J. German Rivera
2015-11-06 17:50   ` Marc Zyngier [this message]
2015-11-06 23:20     ` Jose Rivera
2015-11-09 10:45       ` Marc Zyngier
2015-11-09 21:18         ` Jose Rivera
2015-10-30 19:43 ` [PATCH v2 04/11] staging: fsl-mc: Added GICv3-ITS support for FSL-MC MSIs J. German Rivera
2015-10-30 19:43 ` [PATCH v2 05/11] staging: fsl-mc: Extended MC bus allocator to include IRQs J. German Rivera
2015-10-30 19:43 ` [PATCH v2 06/11] staging: fsl-mc: Changed DPRC built-in portal's mc_io to be atomic J. German Rivera
2015-10-30 19:43 ` [PATCH v2 07/11] staging: fsl-mc: Populate the IRQ pool for an MC bus instance J. German Rivera
2015-10-30 19:43 ` [PATCH v2 08/11] staging: fsl-mc: set MSI domain for DPRC objects J. German Rivera
2015-10-30 19:43 ` [PATCH v2 09/11] staging: fsl-mc: Fixed bug in dprc_probe() error path J. German Rivera
2015-10-30 19:43 ` [PATCH v2 10/11] staging: fsl-mc: Added DPRC interrupt handler J. German Rivera
2015-10-30 19:43 ` [PATCH v2 11/11] staging: fsl-mc: Added MSI support to the MC bus driver J. German Rivera

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=563CE87B.9040107@arm.com \
    --to=marc.zyngier@arm.com \
    --cc=German.Rivera@freescale.com \
    --cc=R89243@freescale.com \
    --cc=agraf@suse.de \
    --cc=arnd@arndb.de \
    --cc=bhamciu1@freescale.com \
    --cc=bhupesh.sharma@freescale.com \
    --cc=dan.carpenter@oracle.com \
    --cc=devel@driverdev.osuosl.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=itai.katz@freescale.com \
    --cc=jiang.liu@linux.intel.com \
    --cc=leoli@freescale.com \
    --cc=lijun.pan@freescale.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nir.erez@freescale.com \
    --cc=richard.schmitt@freescale.com \
    --cc=scottwood@freescale.com \
    --cc=stuart.yoder@freescale.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