On 04.03.2020 11:51, Russell King - ARM Linux admin wrote:
> On Wed, Mar 04, 2020 at 11:42:16AM +0200, Laurentiu Tudor wrote:
>> On 04.03.2020 11:33, Russell King - ARM Linux admin wrote:
>>> On Wed, Mar 04, 2020 at 10:56:06AM +0200, Laurentiu Tudor wrote:
>>>>
>>>> On 04.03.2020 00:17, Russell King - ARM Linux admin wrote:
>>>>> On Tue, Mar 03, 2020 at 05:55:05PM +0200, Laurentiu Tudor wrote:
>>>>>>    From c98dc05cdd45ae923654f2427985bd28bcde4bb2 Mon Sep 17 00:00:00 2001
>>>>>> From: Laurentiu Tudor <laurentiu.tudor@nxp.com>
>>>>>> Date: Thu, 13 Feb 2020 11:59:12 +0200
>>>>>> Subject: [PATCH 1/4] bus: fsl-mc: add custom .dma_configure implementation
>>>>>> Content-Type: text/plain; charset="us-ascii"
>>>>>>
>>>>>> The devices on this bus are not discovered by way of device tree
>>>>>> but by queries to the firmware. It makes little sense to trick the
>>>>>> generic of layer into thinking that these devices are of related so
>>>>>> that we can get our dma configuration. Instead of doing that, add
>>>>>> our custom dma configuration implementation.
>>>>>
>>>>> Firstly, applying this to v5.5 results in a build failure, due to a
>>>>> missing linux/iommu.h include.
>>>>>
>>>>> Secondly, this on its own appears to make the DPAA2 network interfaces
>>>>> completely disappear.  Looking in /sys/bus/fsl-mc/drivers/*, none of
>>>>> the DPAA2 drivers are bound to anything, and looking in
>>>>> /sys/bus/fsl-mc/devices/, there is:
>>>>>
>>>>> lrwxrwxrwx 1 root root 0 Mar  3 22:06 dprc.1 -> ../../../devices/platform/soc/80c000000.fsl-mc/dprc.1
>>>>>
>>>>> This is booting with u-boot, so using DT rather than ACPI.
>>>>>
>>>>>> Signed-off-by: Laurentiu Tudor <laurentiu.tudor@nxp.com>
>>>>>> ---
>>>>>>     drivers/bus/fsl-mc/fsl-mc-bus.c | 42 ++++++++++++++++++++++++++++++++-
>>>>>>     1 file changed, 41 insertions(+), 1 deletion(-)
>>>>>>
>>>>>> diff --git a/drivers/bus/fsl-mc/fsl-mc-bus.c b/drivers/bus/fsl-mc/fsl-mc-bus.c
>>>>>> index 36eb25f82c8e..3df015eedae4 100644
>>>>>> --- a/drivers/bus/fsl-mc/fsl-mc-bus.c
>>>>>> +++ b/drivers/bus/fsl-mc/fsl-mc-bus.c
>>>>>> @@ -132,11 +132,51 @@ static int fsl_mc_bus_uevent(struct device *dev, struct kobj_uevent_env *env)
>>>>>>     static int fsl_mc_dma_configure(struct device *dev)
>>>>>>     {
>>>>>>     	struct device *dma_dev = dev;
>>>>>> +	struct iommu_fwspec *fwspec;
>>>>>> +	const struct iommu_ops *iommu_ops;
>>>>>> +	struct fsl_mc_device *mc_dev = to_fsl_mc_device(dev);
>>>>>> +	int ret;
>>>>>> +	u32 icid;
>>>>>> +
>>>>>> +	/* Skip DMA setup for devices that are not DMA masters */
>>>>>> +	if (dev->type == &fsl_mc_bus_dpmcp_type ||
>>>>>> +	    dev->type == &fsl_mc_bus_dpbp_type ||
>>>>>> +	    dev->type == &fsl_mc_bus_dpcon_type ||
>>>>>> +	    dev->type == &fsl_mc_bus_dpio_type)
>>>>>> +		return 0;
>>>>>>     	while (dev_is_fsl_mc(dma_dev))
>>>>>>     		dma_dev = dma_dev->parent;
>>>>>> -	return of_dma_configure(dev, dma_dev->of_node, 0);
>>>>>> +	fwspec = dev_iommu_fwspec_get(dma_dev);
>>>>>> +	if (!fwspec)
>>>>>> +		return -ENODEV;
>>>>>
>>>>> The problem appears to be here - fwspec is NULL for dprc.1.
>>>>
>>>> Ok, that's because the iommu config is missing from the DT node that's
>>>> exposing the MC firmware. I've attached a fresh set of patches that include
>>>> on top the missing config and a workaround that makes MC work over SMMU.
>>>> Also added the missing #include, thanks for pointing out.
>>>> Let me know how it goes.
>>>
>>> Shouldn't patch 6 should be first in the series, so that patch 1 does
>>> not cause a regression and bisectability damage?
>>>
>>
>> Correct, width one comment: both 5 and 6 should go first. Once iommu-map is
>> added in the device tree the workaround for MC with the
>> arm-smmu.disable_bypass boot arg will no longer work.
> 
> So, wouldn't it be reasonable to arrange the patch series like that?
> 

Sure, please see attached.

---
Best Regards, Laurentiu