linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Scott Wood <scottwood@freescale.com>
To: Jia Hongtao-B38951 <B38951@freescale.com>
Cc: Wood Scott-B07421 <B07421@freescale.com>,
	"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
	Li Yang-R58472 <r58472@freescale.com>
Subject: Re: [PATCH V2] powerpc/85xx: workaround for chips with MSI hardware errata
Date: Tue, 19 Mar 2013 11:31:33 -0500	[thread overview]
Message-ID: <1363710693.16671.7@snotra> (raw)
In-Reply-To: <412C8208B4A0464FA894C5F0C278CD5D01C1AB0B@039-SN1MPN1-003.039d.mgd.msft.net> (from B38951@freescale.com on Tue Mar 19 03:03:13 2013)

;On 03/19/2013 03:03:13 AM, Jia Hongtao-B38951 wrote:
>=20
>=20
> > -----Original Message-----
> > From: Kumar Gala [mailto:galak@kernel.crashing.org]
> > Sent: Friday, March 15, 2013 11:53 PM
> > To: Jia Hongtao-B38951
> > Cc: linuxppc-dev@lists.ozlabs.org; Wood Scott-B07421;
> > michael@ellerman.id.au; Li Yang-R58472
> > Subject: Re: [PATCH V2] powerpc/85xx: workaround for chips with MSI
> > hardware errata
> >
> >
> > On Mar 14, 2013, at 9:00 PM, Jia Hongtao-B38951 wrote:
> >
> > >
> > >
> > >> -----Original Message-----
> > >> From: Kumar Gala [mailto:galak@kernel.crashing.org]
> > >> Sent: Friday, March 15, 2013 4:05 AM
> > >> To: Jia Hongtao-B38951
> > >> Cc: linuxppc-dev@lists.ozlabs.org; Wood Scott-B07421;
> > >> michael@ellerman.id.au; Li Yang-R58472; Jia Hongtao-B38951
> > >> Subject: Re: [PATCH V2] powerpc/85xx: workaround for chips with =20
> MSI
> > >> hardware errata
> > >>
> > >>
> > >> On Mar 14, 2013, at 5:35 AM, Jia Hongtao wrote:
> > >>
> > >>> The MPIC version 2.0 has a MSI errata (errata PIC1 of mpc8544), =20
> It
> > >>> causes that neither MSI nor MSI-X can work fine. This is a
> > >>> workaround to allow MSI-X to function properly.
> > >>>
> > >>> Signed-off-by: Liu Shuo <soniccat.liu@gmail.com>
> > >>> Signed-off-by: Li Yang <leoli@freescale.com>
> > >>> Signed-off-by: Jia Hongtao <hongtao.jia@freescale.com>
> > >>> ---
> > >>> Changes for V2:
> > >>> - Address almost all the comments from Michael Ellerman for V1.
> > >>> Here is the link:
> > >>> http://patchwork.ozlabs.org/patch/226833/
> > >>>
> > >>> arch/powerpc/sysdev/fsl_msi.c | 65
> > >>> +++++++++++++++++++++++++++++++++++++++++--
> > >>> arch/powerpc/sysdev/fsl_msi.h |  2 ++
> > >>> 2 files changed, 64 insertions(+), 3 deletions(-)
> > >>>
> > >>> diff --git a/arch/powerpc/sysdev/fsl_msi.c
> > >>> b/arch/powerpc/sysdev/fsl_msi.c index 178c994..54cb83e 100644
> > >>> --- a/arch/powerpc/sysdev/fsl_msi.c
> > >>> +++ b/arch/powerpc/sysdev/fsl_msi.c
> > >>> @@ -98,8 +98,18 @@ static int fsl_msi_init_allocator(struct =20
> fsl_msi
> > >>> *msi_data)
> > >>>
> > >>> static int fsl_msi_check_device(struct pci_dev *pdev, int nvec, =20
> int
> > >>> type) {
> > >>> -	if (type =3D=3D PCI_CAP_ID_MSIX)
> > >>> -		pr_debug("fslmsi: MSI-X untested, trying =20
> anyway.\n");
> > >>> +	struct fsl_msi *msi;
> > >>> +
> > >>> +	if (type =3D=3D PCI_CAP_ID_MSI) {
> > >>> +		/*
> > >>> +		 * MPIC version 2.0 has erratum PIC1. For now =20
> MSI
> > >>> +		 * could not work. So check to prevent MSI from
> > >>> +		 * being used on the board with this erratum.
> > >>> +		 */
> > >>> +		list_for_each_entry(msi, &msi_head, list)
> > >>> +			if (msi->feature & MSI_HW_ERRATA_ENDIAN)
> > >>> +				return -EINVAL;
> > >>> +	}
> > >>>
> > >>> 	return 0;
> > >>> }
> > >>> @@ -142,7 +152,17 @@ static void fsl_compose_msi_msg(struct =20
> pci_dev
> > >> *pdev, int hwirq,
> > >>> 	msg->address_lo =3D lower_32_bits(address);
> > >>> 	msg->address_hi =3D upper_32_bits(address);
> > >>>
> > >>> -	msg->data =3D hwirq;
> > >>> +	/*
> > >>> +	 * MPIC version 2.0 has erratum PIC1. It causes
> > >>> +	 * that neither MSI nor MSI-X can work fine.
> > >>> +	 * This is a workaround to allow MSI-X to function
> > >>> +	 * properly. It only works for MSI-X, we prevent
> > >>> +	 * MSI on buggy chips in fsl_msi_check_device().
> > >>> +	 */
> > >>> +	if (msi_data->feature & MSI_HW_ERRATA_ENDIAN)
> > >>> +		msg->data =3D __swab32(hwirq);
> > >>> +	else
> > >>> +		msg->data =3D hwirq;
> > >>>
> > >>> 	pr_debug("%s: allocated srs: %d, ibs: %d\n",
> > >>> 		__func__, hwirq / IRQS_PER_MSI_REG, hwirq % =20
> IRQS_PER_MSI_REG);
> > >> @@
> > >>> -361,6 +381,35 @@ static int fsl_msi_setup_hwirq(struct fsl_msi
> > >>> *msi,
> > >> struct platform_device *dev,
> > >>> 	return 0;
> > >>> }
> > >>>
> > >>> +/* MPIC version 2.0 has erratum PIC1 */ static int
> > >>> +mpic_has_errata(struct platform_device *dev) {
> > >>> +	struct device_node *mpic_node;
> > >>> +
> > >>> +	mpic_node =3D of_irq_find_parent(dev->dev.of_node);
> > >>> +	if (mpic_node) {
> > >>> +		u32 *reg_base, brr1 =3D 0;
> > >>> +		/* Get the PIC reg base */
> > >>> +		reg_base =3D of_iomap(mpic_node, 0);
> > >>> +		of_node_put(mpic_node);
> > >>> +		if (!reg_base) {
> > >>> +			dev_err(&dev->dev, "ioremap problem =20
> failed.\n");
> > >>> +			return -EIO;
> > >>> +		}
> > >>> +
> > >>> +		/* Get the mpic version from block revision =20
> register 1 */
> > >>> +		brr1 =3D in_be32(reg_base + MPIC_FSL_BRR1);
> > >>> +		iounmap(reg_base);
> > >>> +		if ((brr1 & MPIC_FSL_BRR1_VER) =3D=3D 0x0200)
> > >>> +			return 1;
> > >>> +	} else {
> > >>> +		dev_err(&dev->dev, "MSI can't find his parent =20
> mpic node.\n");
> > >>> +		return -ENODEV;
> > >>> +	}
> > >>> +
> > >>> +	return 0;
> > >>> +}
> > >>> +
> > >>> static const struct of_device_id fsl_of_msi_ids[]; static int
> > >>> fsl_of_msi_probe(struct platform_device *dev) { @@ -423,6 =20
> +472,16 @@
> > >>> static int fsl_of_msi_probe(struct platform_device *dev)
> > >>>
> > >>> 	msi->feature =3D features->fsl_pic_ip;
> > >>>
> > >>> +	if ((features->fsl_pic_ip & FSL_PIC_IP_MASK) =3D=3D =20
> FSL_PIC_IP_MPIC) {
> > >>> +		rc =3D mpic_has_errata(dev);
> > >>> +		if (rc > 0) {
> > >>> +			msi->feature |=3D MSI_HW_ERRATA_ENDIAN;
> > >>> +		} else if (rc < 0) {
> > >>> +			err =3D rc;
> > >>> +			goto error_out;
> > >>> +		}
> > >>> +	}
> > >>> +
> > >>> 	/*
> > >>> 	 * Remember the phandle, so that we can match with any =20
> PCI nodes
> > >>> 	 * that have an "fsl,msi" property.
> > >>> diff --git a/arch/powerpc/sysdev/fsl_msi.h
> > >>> b/arch/powerpc/sysdev/fsl_msi.h index 8225f86..7389e8e 100644
> > >>> --- a/arch/powerpc/sysdev/fsl_msi.h
> > >>> +++ b/arch/powerpc/sysdev/fsl_msi.h
> > >>> @@ -25,6 +25,8 @@
> > >>> #define FSL_PIC_IP_IPIC   0x00000002
> > >>> #define FSL_PIC_IP_VMPIC  0x00000003
> > >>>
> > >>> +#define MSI_HW_ERRATA_ENDIAN 0x00000010
> > >>> +
> > >>
> > >> Is there any reason to put this in fsl_msi.h rather than just in
> > >> fsl_msi.c itself?
> > >>
> > >> - k
> > >
> > > Actually no. This micro is only used by fsl_msi.c.
> > > Will move it to fsl_msi.c.
> > >
> > > Thanks.
> > > -Hongtao.
> >
> > Also, wondering if we can do the mpic version detection in mpic.c =20
> and not
> > here.  I'm not sure what means we'd have to get back to the mpic =20
> struct
> > so we could possible use mpic->flags.
> >
>=20
> Use the MPIC version result in mpic.c was my plan.
> But as you point out there seems no obvious way to get the mpic =20
> struct.
> mpic struct is defined as an automatic variable in platform files.
> Also MSI driver is not so close to mpic driver under current =20
> architecture.
>=20
> If you get some elegant way to do this please feel free to tell me.

Declare a non-static function to retrieve the MPIC version.

-Scott=

  reply	other threads:[~2013-03-19 16:31 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-14 10:35 [PATCH V2] powerpc/85xx: workaround for chips with MSI hardware errata Jia Hongtao
2013-03-14 20:04 ` Kumar Gala
2013-03-15  2:00   ` Jia Hongtao-B38951
2013-03-15 15:52     ` Kumar Gala
2013-03-19  8:03       ` Jia Hongtao-B38951
2013-03-19 16:31         ` Scott Wood [this message]
2013-03-21 10:22           ` Jia Hongtao-B38951

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=1363710693.16671.7@snotra \
    --to=scottwood@freescale.com \
    --cc=B07421@freescale.com \
    --cc=B38951@freescale.com \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=r58472@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;
as well as URLs for NNTP newsgroup(s).