RE: [PATCH 5/7 v5] bus: fsl-mc: support dma configure for devices on fsl-mc bus

[Nipun Gupta]

> -----Original Message-----
> From: Robin Murphy [mailto:robin.murphy@xxxxxxx]
> Sent: Tuesday, July 3, 2018 9:44 PM
> To: Nipun Gupta <nipun.gupta@xxxxxxx>; will.deacon@xxxxxxx;
> robh+dt@xxxxxxxxxx; robh@xxxxxxxxxx; mark.rutland@xxxxxxx;
> catalin.marinas@xxxxxxx; gregkh@xxxxxxxxxxxxxxxxxxx; Laurentiu Tudor
> <laurentiu.tudor@xxxxxxx>; bhelgaas@xxxxxxxxxx
> Cc: hch@xxxxxx; joro@xxxxxxxxxx; m.szyprowski@xxxxxxxxxxx;
> shawnguo@xxxxxxxxxx; frowand.list@xxxxxxxxx; iommu@xxxxxxxxxxxx
> foundation.org; linux-kernel@xxxxxxxxxxxxxxx; devicetree@xxxxxxxxxxxxxxx;
> linux-arm-kernel@xxxxxxxxxxxxxxxxxxx; linuxppc-dev@xxxxxxxxxxxxxxxx; linux-
> pci@xxxxxxxxxxxxxxx; Bharat Bhushan <bharat.bhushan@xxxxxxx>;
> stuyoder@xxxxxxxxx; Leo Li <leoyang.li@xxxxxxx>
> Subject: Re: [PATCH 5/7 v5] bus: fsl-mc: support dma configure for devices
> on fsl-mc bus
> 
> On 20/05/18 14:49, Nipun Gupta wrote:
> > This patch adds support of dma configuration for devices on fsl-mc
> > bus using 'dma_configure' callback for busses. Also, directly calling
> > arch_setup_dma_ops is removed from the fsl-mc bus.
> 
> Looks like this is the final arch_setup_dma_ops offender, yay!
> 
> > Signed-off-by: Nipun Gupta <nipun.gupta@xxxxxxx>
> > Reviewed-by: Laurentiu Tudor <laurentiu.tudor@xxxxxxx>
> > ---
> >   drivers/bus/fsl-mc/fsl-mc-bus.c | 15 +++++++++++----
> >   1 file changed, 11 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/bus/fsl-mc/fsl-mc-bus.c b/drivers/bus/fsl-mc/fsl-mc-
> bus.c
> > index 5d8266c..fa43c7d 100644
> > --- a/drivers/bus/fsl-mc/fsl-mc-bus.c
> > +++ b/drivers/bus/fsl-mc/fsl-mc-bus.c
> > @@ -127,6 +127,16 @@ static int fsl_mc_bus_uevent(struct device *dev,
> struct kobj_uevent_env *env)
> >   	return 0;
> >   }
> >
> > +static int fsl_mc_dma_configure(struct device *dev)
> > +{
> > +	struct device *dma_dev = dev;
> > +
> > +	while (dev_is_fsl_mc(dma_dev))
> > +		dma_dev = dma_dev->parent;
> > +
> > +	return of_dma_configure(dev, dma_dev->of_node, 0);
> > +}
> > +
> >   static ssize_t modalias_show(struct device *dev, struct device_attribute
> *attr,
> >   			     char *buf)
> >   {
> > @@ -148,6 +158,7 @@ struct bus_type fsl_mc_bus_type = {
> >   	.name = "fsl-mc",
> >   	.match = fsl_mc_bus_match,
> >   	.uevent = fsl_mc_bus_uevent,
> > +	.dma_configure  = fsl_mc_dma_configure,
> >   	.dev_groups = fsl_mc_dev_groups,
> >   };
> >   EXPORT_SYMBOL_GPL(fsl_mc_bus_type);
> > @@ -633,10 +644,6 @@ int fsl_mc_device_add(struct fsl_mc_obj_desc
> *obj_desc,
> >   			goto error_cleanup_dev;
> >   	}
> >
> > -	/* Objects are coherent, unless 'no shareability' flag set. */
> > -	if (!(obj_desc->flags &
> FSL_MC_OBJ_FLAG_NO_MEM_SHAREABILITY))
> 
> Although it seems we do end up without any handling of this
> "non-coherent object behind coherent MC" case, and I'm not sure how
> easily that could be accommodated by generic code... :/ How important is
> the quirk?

We have all the devices as coherent in our SoC's now :) So this is fine.
We have internally discussed it.

Regards,
Nipun

> 
> Robin.
> 
> > -		arch_setup_dma_ops(&mc_dev->dev, 0, 0, NULL, true);
> > -
> >   	/*
> >   	 * The device-specific probe callback will get invoked by device_add()
> >   	 */
> >