Re: [PATCH v4 03/13] memory: mtk-smi: Use clk_bulk clock ops

2021-10-15 Thread Krzysztof Kozlowski
On 15/10/2021 15:38, AngeloGioacchino Del Regno wrote:
>> Use clk_bulk interface instead of the orginal one to simplify the code.
>>
>> For SMI larbs: Require apb/smi clocks while gals is optional.
>> For SMI common: Require apb/smi/gals0/gal1 in has_gals case. Otherwise,
>>  also only require apb/smi, No optional clk here.
>>
>> About the "has_gals" flag, for smi larbs, the gals clock also may be
>> optional even this platform support it. thus it always use
>> *_bulk_get_optional, then the flag has_gals is unnecessary. Remove it.
>> The smi_common's has_gals still keep it.
>>
>> Also remove clk fail logs since bulk interface already output fail log.
>>
>> Signed-off-by: Yong Wu 
> 
> Hello Yong,
> thanks for the patch! However, I have an improvement to point out:
> 
>> ---
>>   drivers/memory/mtk-smi.c | 143 +++
>>   1 file changed, 55 insertions(+), 88 deletions(-)
>>
>> diff --git a/drivers/memory/mtk-smi.c b/drivers/memory/mtk-smi.c
>> index c5fb51f73b34..f91eaf5c3ab0 100644
>> --- a/drivers/memory/mtk-smi.c
>> +++ b/drivers/memory/mtk-smi.c
>> @@ -60,6 +60,20 @@ enum mtk_smi_gen {
>>  MTK_SMI_GEN2
>>   };
>>   
>> +#define MTK_SMI_CLK_NR_MAX  4
> 
> This refers to mtk_smi_common_clks[] and should be probably moved after that.
> In any case, I don't think that there's any need to manually define this as 4,
> as you can simply use the macro ARRAY_SIZE(mtk_smi_common_clks).
> Using that will make you able to not update this definition everytime an 
> update
> occurs to the mtk_smi_common_clks array.
> 
>> +
>> +/* larbs: Require apb/smi clocks while gals is optional. */
>> +static const char * const mtk_smi_larb_clks[] = {"apb", "smi", "gals"};
>> +#define MTK_SMI_LARB_REQ_CLK_NR 2
>> +#define MTK_SMI_LARB_OPT_CLK_NR 1
>> +
>> +/*
>> + * common: Require these four clocks in has_gals case. Otherwise, only 
>> apb/smi are required.
>> + */
>> +static const char * const mtk_smi_common_clks[] = {"apb", "smi", "gals0", 
>> "gals1"};
>> +#define MTK_SMI_COM_REQ_CLK_NR  2
>> +#define MTK_SMI_COM_GALS_REQ_CLK_NR MTK_SMI_CLK_NR_MAX
>> +
> 
> Apart from that,
> Acked-By: AngeloGioacchino Del Regno 

The patchset was merged around a month ago:
https://lore.kernel.org/lkml/163229303729.7874.4095337797772755570.b4...@canonical.com/


Best regards,
Krzysztof
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v4 00/13] MT8195 SMI support

2021-09-22 Thread Krzysztof Kozlowski
On Tue, 14 Sep 2021 19:36:50 +0800, Yong Wu wrote:
> This patchset mainly adds SMI support for mt8195.
> 
> Comparing with the previous version, add two new functions:
> a) add smi sub common
> b) add initial setting for smi-common and smi-larb.
> 
> Change note:
> v4:1) base on v5.15-rc1
>2) In the dt-binding:
>   a. add "else mediatek,smi: false." in the yaml.
>   b. Remove mediatek,smi_sub_common. since we have only 2 level currently,
>   It should be smi-sub-common if that node has "mediatek,smi". otherwise,
>   it is smi-common.
> 
> [...]

Applied, thanks!

[01/13] dt-bindings: memory: mediatek: Add mt8195 smi binding
commit: b01065eee432b3ae91a2c0aaab66c2cae2e9812d
[02/13] dt-bindings: memory: mediatek: Add mt8195 smi sub common
commit: 599e681a31a2dfa7359b8e420a1157ed015f840b
[03/13] memory: mtk-smi: Use clk_bulk clock ops
commit: 0e14917c57f9d8b9b7d4f41813849a29659447b3
[04/13] memory: mtk-smi: Rename smi_gen to smi_type
commit: a5c18986f404206fdbc27f208620dc13bffb5657
[05/13] memory: mtk-smi: Adjust some code position
commit: 534e0ad2ed4f9296a8c7ccb1a393bc4d5000dbad
[06/13] memory: mtk-smi: Add error handle for smi_probe
commit: 30b869e77a1c626190bbbe6b4e5f5382b0102ac3
[07/13] memory: mtk-smi: Add device link for smi-sub-common
commit: 47404757702ec8aa5c8310cdf58a267081f0ce6c
[08/13] memory: mtk-smi: Add clocks for smi-sub-common
commit: 3e4f74e0ea5a6a6d6d825fd7afd8a10afbd1152c
[09/13] memory: mtk-smi: Use devm_platform_ioremap_resource
commit: 912fea8bf8d854aef967c82a279ffd20be0326d7
[10/13] memory: mtk-smi: mt8195: Add smi support
commit: cc4f9dcd9c1543394d6ee0d635551a2bd96bcacb
[11/13] memory: mtk-smi: mt8195: Add initial setting for smi-common
commit: 431e9cab7097b5d5eb3cf2b04d4b12d272df85e0
[12/13] memory: mtk-smi: mt8195: Add initial setting for smi-larb
commit: fe6dd2a4017d3dfbf4a530d95270a1d498a16a4c
[13/13] MAINTAINERS: Add entry for MediaTek SMI
commit: 93403ede5aa4edeec2c63541b185d9c4fc9ae1e4

Best regards,
-- 
Krzysztof Kozlowski 
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v3 00/13] MT8195 SMI support

2021-08-18 Thread Krzysztof Kozlowski
On 10/08/2021 10:08, Yong Wu wrote:
> This patchset mainly adds SMI support for mt8195.
> 
> Comparing with the previous version, add two new functions:
> a) add smi sub common
> b) add initial setting for smi-common and smi-larb.
> 
> Change note:
> v3:1) In the dt-binding:
>a. Change mediatek,smi type from phandle-array to phandle from Rob.
>b. Add a new bool property (mediatek,smi_sub_common)
>   to indicate if this is smi-sub-common.
>2) Change the clock using bulk parting.
>   keep the smi-common's has_gals flag. more strict.
>3) More comment about larb initial setting.
>4) Add a maintain patch

The patchset looks good to me but I saw now comments from Rob, so I
expect a resend. Therefore there is also time for additional review -
maybe continued by Ikjoon Jang?

If you sent a v4 with fixes rather soon and get ack from Rob, I could
still try to get it into next merge window. After this weekend I won't
be taking patches for this cycle and it will wait for the merge window
to finish.


Best regards,
Krzysztof
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH] dt-bindings: arm-smmu: Fix json-schema syntax

2021-07-20 Thread Krzysztof Kozlowski
On Tue, 13 Jul 2021 at 10:27, Krzysztof Kozlowski
 wrote:
>
> On Mon, 12 Jul 2021 at 16:14, Rob Herring  wrote:
> >
> > On Tue, Jun 22, 2021 at 11:56 PM Krzysztof Kozlowski
> >  wrote:
> > >
> > > On Mon, 21 Jun 2021 16:00:36 +0200, Thierry Reding wrote:
> > > > Commit 4287861dca9d ("dt-bindings: arm-smmu: Add Tegra186 compatible
> > > > string") introduced a jsonschema syntax error as a result of a rebase
> > > > gone wrong. Fix it.
> > >
> > > Applied, thanks!
> > >
> > > [1/1] dt-bindings: arm-smmu: Fix json-schema syntax
> > >   commit: bf3ec9deaa33889630722c47f7bb86ba58872ea7
> >
> > Applied where? Now Linus's master is broken.
>
> To memory controller drivers tree. Pushed to soc folks some time ago:
> https://lore.kernel.org/lkml/20210625073604.13562-1-krzysztof.kozlow...@canonical.com/

Hi Rob,

The patch landed in the Linus' tree in v5.14-rc2.

Best regards,
Krzysztof
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH] dt-bindings: arm-smmu: Fix json-schema syntax

2021-07-13 Thread Krzysztof Kozlowski
On Mon, 12 Jul 2021 at 16:14, Rob Herring  wrote:
>
> On Tue, Jun 22, 2021 at 11:56 PM Krzysztof Kozlowski
>  wrote:
> >
> > On Mon, 21 Jun 2021 16:00:36 +0200, Thierry Reding wrote:
> > > Commit 4287861dca9d ("dt-bindings: arm-smmu: Add Tegra186 compatible
> > > string") introduced a jsonschema syntax error as a result of a rebase
> > > gone wrong. Fix it.
> >
> > Applied, thanks!
> >
> > [1/1] dt-bindings: arm-smmu: Fix json-schema syntax
> >   commit: bf3ec9deaa33889630722c47f7bb86ba58872ea7
>
> Applied where? Now Linus's master is broken.

To memory controller drivers tree. Pushed to soc folks some time ago:
https://lore.kernel.org/lkml/20210625073604.13562-1-krzysztof.kozlow...@canonical.com/

Cc: Arnd and Olof,
Any comments on merging these fixes? They should go to current RC.

Best regards,
Krzysztof
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH 3/9] memory: mtk-smi: Use clk_bulk instead of the clk ops

2021-07-12 Thread Krzysztof Kozlowski
On 11/07/2021 10:29, Yong Wu wrote:
> On Thu, 2021-07-08 at 11:32 +0200, Krzysztof Kozlowski wrote:
>> On 16/06/2021 13:43, Yong Wu wrote:
>>> smi have many clocks: apb/smi/gals.
>>> This patch use clk_bulk interface instead of the orginal one to simply
>>> the code.
>>>
>>> gals is optional clk(some larbs may don't have gals). use clk_bulk_optional
>>> instead. and then remove the has_gals flag.
>>>
>>> Also remove clk fail logs since bulk interface already output fail log.
>>>
>>> Signed-off-by: Yong Wu 
>>> ---
>>>  drivers/memory/mtk-smi.c | 124 +++
>>>  1 file changed, 34 insertions(+), 90 deletions(-)
>>>
>>> diff --git a/drivers/memory/mtk-smi.c b/drivers/memory/mtk-smi.c
>>> index c5fb51f73b34..bcd2bf130655 100644
>>> --- a/drivers/memory/mtk-smi.c
>>> +++ b/drivers/memory/mtk-smi.c
>>> @@ -60,9 +60,18 @@ enum mtk_smi_gen {
>>> MTK_SMI_GEN2
>>>  };
>>>  
>>> +#define MTK_SMI_CLK_NR_MAX 4
>>> +
>>> +static const char * const mtk_smi_common_clocks[] = {
>>> +   "apb", "smi", "gals0", "gals1", /* glas is optional */
>>
>> Typo here - glas.
> 
> Will Fix. Thanks.
> 
>>
>>> +};
>>> +
> 
> [snip]
> 
>>> @@ -493,7 +449,7 @@ static int mtk_smi_common_probe(struct platform_device 
>>> *pdev)
>>> struct device *dev = >dev;
>>> struct mtk_smi *common;
>>> struct resource *res;
>>> -   int ret;
>>> +   int i, ret;
>>>  
>>> common = devm_kzalloc(dev, sizeof(*common), GFP_KERNEL);
>>> if (!common)
>>> @@ -501,23 +457,13 @@ static int mtk_smi_common_probe(struct 
>>> platform_device *pdev)
>>> common->dev = dev;
>>> common->plat = of_device_get_match_data(dev);
>>>  
>>> -   common->clk_apb = devm_clk_get(dev, "apb");
>>> -   if (IS_ERR(common->clk_apb))
>>> -   return PTR_ERR(common->clk_apb);
>>> -
>>> -   common->clk_smi = devm_clk_get(dev, "smi");
>>> -   if (IS_ERR(common->clk_smi))
>>> -   return PTR_ERR(common->clk_smi);
>>> +   common->clk_num = ARRAY_SIZE(mtk_smi_common_clocks);
>>> +   for (i = 0; i < common->clk_num; i++)
>>> +   common->clks[i].id = mtk_smi_common_clocks[i];
>>>  
>>> -   if (common->plat->has_gals) {
>>> -   common->clk_gals0 = devm_clk_get(dev, "gals0");
>>> -   if (IS_ERR(common->clk_gals0))
>>> -   return PTR_ERR(common->clk_gals0);
>>> -
>>> -   common->clk_gals1 = devm_clk_get(dev, "gals1");
>>> -   if (IS_ERR(common->clk_gals1))
>>> -   return PTR_ERR(common->clk_gals1);
>>> -   }
>>> +   ret = devm_clk_bulk_get_optional(dev, common->clk_num, common->clks);
>>> +   if (ret)
>>> +   return ret;
>>
>> How do you handle now missing required clocks?
> 
> It looks this is a common issue for this function which supports all the
> clocks could be optional. Is there common suggestion for this?
> 
> For our case, the apb/smi clocks are required while "gals" are optional.
> 
> thus, we should use devm_clk_bulk_get for the necessary clocks and
> devm_clk_bulk_get_optional for the optional ones. right?

Yes, I think that's the solution. Otherwise you might not have proper
clocks leading to accesses to disabled/gated hardware.

Best regards,
Krzysztof
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH 6/9] memory: mtk-smi: Add smi sub common support

2021-07-08 Thread Krzysztof Kozlowski
On 16/06/2021 13:43, Yong Wu wrote:
> This patch adds smi-sub-common support. some larbs may connect with the
> smi-sub-common, then connect with smi-common.

Please start sentences with capital letter. This (similarly to "This
patch") appears in multiple patches.

> 
> Before we create device link between smi-larb with smi-common, If we have
> sub-common, we should use device link the smi-larb and smi-sub-common,
> then use device link between the smi-sub-common with smi-common. This is
> for enabling clock/power automatically.
> Move the device link code to a new interface for reusing.
> 
> there is no SW extra setting for smi-sub-common.
> 
> Signed-off-by: Yong Wu 
> ---
>  drivers/memory/mtk-smi.c | 78 ++--
>  1 file changed, 52 insertions(+), 26 deletions(-)
> 


Best regards,
Krzysztof
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH 4/9] memory: mtk-smi: Rename smi_gen to smi_type

2021-07-08 Thread Krzysztof Kozlowski
On 16/06/2021 13:43, Yong Wu wrote:
> This is a preparing patch for adding smi sub common.

Don't write "This patch". Use simple imperative:
"Prepare for adding smi sub common."

https://elixir.bootlin.com/linux/v5.13/source/Documentation/process/submitting-patches.rst#L89
 
> About the previou smi_gen, we have gen1/gen2 that stand for the generation
> number for HW. I plan to add a new type(sub_common), then the "gen" is not
> prober. this patch only change it to "type", No functional change.

Same.

> 
> Signed-off-by: Yong Wu 
> ---
>  drivers/memory/mtk-smi.c | 24 
>  1 file changed, 12 insertions(+), 12 deletions(-)
> 

Best regards,
Krzysztof
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH 3/9] memory: mtk-smi: Use clk_bulk instead of the clk ops

2021-07-08 Thread Krzysztof Kozlowski
On 16/06/2021 13:43, Yong Wu wrote:
> smi have many clocks: apb/smi/gals.
> This patch use clk_bulk interface instead of the orginal one to simply
> the code.
> 
> gals is optional clk(some larbs may don't have gals). use clk_bulk_optional
> instead. and then remove the has_gals flag.
> 
> Also remove clk fail logs since bulk interface already output fail log.
> 
> Signed-off-by: Yong Wu 
> ---
>  drivers/memory/mtk-smi.c | 124 +++
>  1 file changed, 34 insertions(+), 90 deletions(-)
> 
> diff --git a/drivers/memory/mtk-smi.c b/drivers/memory/mtk-smi.c
> index c5fb51f73b34..bcd2bf130655 100644
> --- a/drivers/memory/mtk-smi.c
> +++ b/drivers/memory/mtk-smi.c
> @@ -60,9 +60,18 @@ enum mtk_smi_gen {
>   MTK_SMI_GEN2
>  };
>  
> +#define MTK_SMI_CLK_NR_MAX   4
> +
> +static const char * const mtk_smi_common_clocks[] = {
> + "apb", "smi", "gals0", "gals1", /* glas is optional */

Typo here - glas.

> +};
> +
> +static const char * const mtk_smi_larb_clocks[] = {
> + "apb",  "smi", "gals"
> +};
> +
>  struct mtk_smi_common_plat {
>   enum mtk_smi_gen gen;
> - bool has_gals;
>   u32  bus_sel; /* Balance some larbs to enter mmu0 or mmu1 */
>  };
>  
> @@ -70,13 +79,12 @@ struct mtk_smi_larb_gen {
>   int port_in_larb[MTK_LARB_NR_MAX + 1];
>   void (*config_port)(struct device *dev);
>   unsigned intlarb_direct_to_common_mask;
> - boolhas_gals;
>  };
>  
>  struct mtk_smi {
>   struct device   *dev;
> - struct clk  *clk_apb, *clk_smi;
> - struct clk  *clk_gals0, *clk_gals1;
> + unsigned intclk_num;
> + struct clk_bulk_dataclks[MTK_SMI_CLK_NR_MAX];
>   struct clk  *clk_async; /*only needed by mt2701*/
>   union {
>   void __iomem*smi_ao_base; /* only for gen1 */
> @@ -95,45 +103,6 @@ struct mtk_smi_larb { /* larb: local arbiter */
>   unsigned char   *bank;
>  };
>  
> -static int mtk_smi_clk_enable(const struct mtk_smi *smi)
> -{
> - int ret;
> -
> - ret = clk_prepare_enable(smi->clk_apb);
> - if (ret)
> - return ret;
> -
> - ret = clk_prepare_enable(smi->clk_smi);
> - if (ret)
> - goto err_disable_apb;
> -
> - ret = clk_prepare_enable(smi->clk_gals0);
> - if (ret)
> - goto err_disable_smi;
> -
> - ret = clk_prepare_enable(smi->clk_gals1);
> - if (ret)
> - goto err_disable_gals0;
> -
> - return 0;
> -
> -err_disable_gals0:
> - clk_disable_unprepare(smi->clk_gals0);
> -err_disable_smi:
> - clk_disable_unprepare(smi->clk_smi);
> -err_disable_apb:
> - clk_disable_unprepare(smi->clk_apb);
> - return ret;
> -}
> -
> -static void mtk_smi_clk_disable(const struct mtk_smi *smi)
> -{
> - clk_disable_unprepare(smi->clk_gals1);
> - clk_disable_unprepare(smi->clk_gals0);
> - clk_disable_unprepare(smi->clk_smi);
> - clk_disable_unprepare(smi->clk_apb);
> -}
> -
>  int mtk_smi_larb_get(struct device *larbdev)
>  {
>   int ret = pm_runtime_resume_and_get(larbdev);
> @@ -270,7 +239,6 @@ static const struct mtk_smi_larb_gen mtk_smi_larb_mt6779 
> = {
>  };
>  
>  static const struct mtk_smi_larb_gen mtk_smi_larb_mt8183 = {
> - .has_gals   = true,
>   .config_port= mtk_smi_larb_config_port_gen2_general,
>   .larb_direct_to_common_mask = BIT(2) | BIT(3) | BIT(7),
> /* IPU0 | IPU1 | CCU */
> @@ -320,6 +288,7 @@ static int mtk_smi_larb_probe(struct platform_device 
> *pdev)
>   struct device_node *smi_node;
>   struct platform_device *smi_pdev;
>   struct device_link *link;
> + int i, ret;
>  
>   larb = devm_kzalloc(dev, sizeof(*larb), GFP_KERNEL);
>   if (!larb)
> @@ -331,22 +300,14 @@ static int mtk_smi_larb_probe(struct platform_device 
> *pdev)
>   if (IS_ERR(larb->base))
>   return PTR_ERR(larb->base);
>  
> - larb->smi.clk_apb = devm_clk_get(dev, "apb");
> - if (IS_ERR(larb->smi.clk_apb))
> - return PTR_ERR(larb->smi.clk_apb);
> -
> - larb->smi.clk_smi = devm_clk_get(dev, "smi");
> - if (IS_ERR(larb->smi.clk_smi))
> - return PTR_ERR(larb->smi.clk_smi);
> -
> - if (larb->larb_gen->has_gals) {
> - /* The larbs may still haven't gals even if the SoC support.*/
> - larb->smi.clk_gals0 = devm_clk_get(dev, "gals");
> - if (PTR_ERR(larb->smi.clk_gals0) == -ENOENT)
> - larb->smi.clk_gals0 = NULL;
> - else if (IS_ERR(larb->smi.clk_gals0))
> - return PTR_ERR(larb->smi.clk_gals0);
> - }
> + larb->smi.clk_num = ARRAY_SIZE(mtk_smi_larb_clocks);
> + for (i = 0; i < larb->smi.clk_num; i++)
> + 

Re: [PATCH 1/9] dt-bindings: memory: mediatek: Add mt8195 smi binding

2021-07-08 Thread Krzysztof Kozlowski
On 16/06/2021 13:43, Yong Wu wrote:
> This patch adds mt8195 smi supporting in the bindings.
> 
> In mt8195, there are two smi-common HW, one is for vdo(video output),
> the other is for vpp(video processing pipe). They connects with different
> smi-larbs, then some setting(bus_sel) is different. Differentiate them
> with the compatible string.
> 
> Something like this:
> 
> IOMMU(VDO)  IOMMU(VPP)
>|   |
>   SMI_COMMON_VDO  SMI_COMMON_VPP
>   --- 
>   |  |   ...  |  | ...
> larb0 larb2  ...larb1 larb3...
> 
> Signed-off-by: Yong Wu 
> ---
>  .../bindings/memory-controllers/mediatek,smi-common.yaml| 6 +-
>  .../bindings/memory-controllers/mediatek,smi-larb.yaml  | 3 +++
>  2 files changed, 8 insertions(+), 1 deletion(-)
> 

I cannot find it on devicetree list, it seems you did not Cc it. Please
use scripts/get_maintainer.pl.


Best regards,
Krzysztof
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH 02/24] dt-bindings: mediatek: mt8195: Add binding for infra IOMMU

2021-06-30 Thread Krzysztof Kozlowski
On 30/06/2021 04:34, Yong Wu wrote:
> In mt8195, we have a new IOMMU that is for INFRA IOMMU. its masters
> mainly are PCIe and USB. Different with MM IOMMU, all these masters
> connect with IOMMU directly, there is no mediatek,larbs property for
> infra IOMMU.
> 
> Another thing is about PCIe ports. currently the function
> "of_iommu_configure_dev_id" only support the id number is 1, But our
> PCIe have two ports, one is for reading and the other is for writing.
> see more about the PCIe patch in this patchset. Thus, I only list
> the reading id here and add the other id in our driver.
> 
> Signed-off-by: Yong Wu 
> ---
>  .../bindings/iommu/mediatek,iommu.yaml | 14 +-
>  .../dt-bindings/memory/mt8195-memory-port.h| 18 ++
>  include/dt-bindings/memory/mtk-memory-port.h   |  2 ++
>  3 files changed, 33 insertions(+), 1 deletion(-)
> 


Acked-by: Krzysztof Kozlowski 


Best regards,
Krzysztof
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH 01/24] dt-bindings: mediatek: mt8195: Add binding for MM IOMMU

2021-06-30 Thread Krzysztof Kozlowski
On 30/06/2021 04:34, Yong Wu wrote:
> This patch adds descriptions for mt8195 IOMMU which also use ARM
> Short-Descriptor translation table format.
> 
> In mt8195, there are two smi-common HW and IOMMU, one is for vdo(video
> output), the other is for vpp(video processing pipe). They connects
> with different smi-larbs, then some setting(larbid_remap) is different.
> Differentiate them with the compatible string.
> 
> Something like this:
> 
> IOMMU(VDO)  IOMMU(VPP)
>|   |
>   SMI_COMMON_VDO  SMI_COMMON_VPP
>   --- 
>   |  |   ...  |  | ...
> larb0 larb2  ...larb1 larb3...
> 
> Another change is that we have a new IOMMU that is for infra master like
> PCIe and USB. The infra master don't have the larb and ports, thus we
> rename the port header file to mt8195-memory-port.h rather than
> mt8195-larb-port.h.
> 
> Also, the IOMMU is not only for MM, thus, we don't call it "m4u" which
> means "MultiMedia Memory Management UNIT". thus, use the "iommu" as the
> compatiable string.
> 
> Signed-off-by: Yong Wu 
> ---
>  .../bindings/iommu/mediatek,iommu.yaml|   7 +
>  .../dt-bindings/memory/mt8195-memory-port.h   | 390 ++
>  2 files changed, 397 insertions(+)
>  create mode 100644 include/dt-bindings/memory/mt8195-memory-port.h
> 

I understand this will go through IOMMU tree. Do you know about any
further patches for memory controllers which will need the header?

Acked-by: Krzysztof Kozlowski 


Best regards,
Krzysztof
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH] dt-bindings: arm-smmu: Fix json-schema syntax

2021-06-22 Thread Krzysztof Kozlowski
On Mon, 21 Jun 2021 16:00:36 +0200, Thierry Reding wrote:
> Commit 4287861dca9d ("dt-bindings: arm-smmu: Add Tegra186 compatible
> string") introduced a jsonschema syntax error as a result of a rebase
> gone wrong. Fix it.

Applied, thanks!

[1/1] dt-bindings: arm-smmu: Fix json-schema syntax
  commit: bf3ec9deaa33889630722c47f7bb86ba58872ea7

Best regards,
-- 
Krzysztof Kozlowski 
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v3 2/9] dt-bindings: arm-smmu: Add Tegra186 compatible string

2021-06-21 Thread Krzysztof Kozlowski
On 18/06/2021 21:47, Rob Herring wrote:
> On Thu, Jun 3, 2021 at 10:49 AM Thierry Reding  
> wrote:
>>
>> From: Thierry Reding 
>>
>> The ARM SMMU instantiations found on Tegra186 and later need inter-
>> operation with the memory controller in order to correctly program
>> stream ID overrides.
>>
>> Furthermore, on Tegra194 multiple instances of the SMMU can gang up
>> to achieve higher throughput. In order to do this, they have to be
>> programmed identically so that the memory controller can interleave
>> memory accesses between them.
>>
>> Add the Tegra186 compatible string to make sure the interoperation
>> with the memory controller can be enabled on that SoC generation.
>>
>> Signed-off-by: Thierry Reding 
>> ---
>>  Documentation/devicetree/bindings/iommu/arm,smmu.yaml | 11 +--
>>  1 file changed, 9 insertions(+), 2 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml 
>> b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
>> index 9d27aa5111d4..1181b590db71 100644
>> --- a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
>> +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
>> @@ -54,8 +54,14 @@ properties:
>>- const: arm,mmu-500
>>- description: NVIDIA SoCs that program two ARM MMU-500s identically
>>  items:
>> +  - description: NVIDIA SoCs that require memory controller interaction
> 
> This is not valid jsonschema:
> 
> /builds/robherring/linux-dt/Documentation/devicetree/bindings/iommu/arm,smmu.yaml:
> properties:compatible:oneOf:4:items: 'anyOf' conditional failed, one
> must be fixed:
> None is not of type 'object', 'boolean'
> None is not of type 'array'
> from schema $id: http://json-schema.org/draft-07/schema#
> /builds/robherring/linux-dt/Documentation/devicetree/bindings/iommu/arm,smmu.yaml:
> properties:compatible:oneOf:4:items: 'oneOf' conditional failed, one
> must be fixed:
> None is not of type 'object'
> None is not of type 'array'
> from schema $id: http://devicetree.org/meta-schemas/keywords.yaml#
> /builds/robherring/linux-dt/Documentation/devicetree/bindings/iommu/arm,smmu.yaml:
> properties:compatible:oneOf:4:items: 'oneOf' conditional failed, one
> must be fixed:
> None is not of type 'object'
> None is not of type 'array'
> from schema $id: http://devicetree.org/meta-schemas/string-array.yaml#
> /builds/robherring/linux-dt/Documentation/devicetree/bindings/iommu/arm,smmu.yaml:
> properties:compatible:oneOf:5:items: 'oneOf' conditional failed, one
> must be fixed:
> [{'enum': [{'const': 'nvidia,tegra194-smmu'}, {'const':
> 'nvidia,tegra186-smmu'}]}, {'const': 'nvidia,smmu-500'}] is not of
> type 'object'
> {'const': 'nvidia,tegra194-smmu'} is not of type 'string'
> {'const': 'nvidia,tegra186-smmu'} is not of type 'string'
> from schema $id: http://devicetree.org/meta-schemas/string-array.yaml#
> 
> 
> This was not reviewed nor tested since the DT list was not Cc'ed.

Ugh, I see now weird empty item on a list... and not only DT list was
skipped - Thierry did not Cc you either.

My bad, I did not check that patch thoroughly before applying.

Thierry, please Cc folks mentioned by get_maintainer.pl. Either sent a
fix or a revert, if fix needs more time.

Additionally, why the patch changes reg to "minItems: 1" for
nvidia,tegra194-smmu?

Best regards,
Krzysztof
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v3 0/9] arm64: tegra: Prevent early SMMU faults

2021-06-11 Thread Krzysztof Kozlowski
On Thu, 3 Jun 2021 18:46:23 +0200, Thierry Reding wrote:
> this is a set of patches that is the result of earlier discussions
> regarding early identity mappings that are needed to avoid SMMU faults
> during early boot.
> 
> The goal here is to avoid early identity mappings altogether and instead
> postpone the need for the identity mappings to when devices are attached
> to the SMMU. This works by making the SMMU driver coordinate with the
> memory controller driver on when to start enforcing SMMU translations.
> This makes Tegra behave in a more standard way and pushes the code to
> deal with the Tegra-specific programming into the NVIDIA SMMU
> implementation.
> 
> [...]

Applied, thanks!

[1/9] memory: tegra: Implement SID override programming
  (no commit info)
[2/9] dt-bindings: arm-smmu: Add Tegra186 compatible string
  commit: 4287861dca9d77490ee50de42aa3ada92da86c9d

[3/9] - skipped

[4/9] iommu/arm-smmu: tegra: Detect number of instances at runtime
  commit: 7ecbf253f8d64c08de28d16a66e3abbe873f6c9f
[5/9] iommu/arm-smmu: tegra: Implement SID override programming
  commit: 8eb68595475ac5fcaaa3718a173283df48cb4ef1
[6/9] iommu/arm-smmu: Use Tegra implementation on Tegra186
  commit: 2c1bc371268862a991a6498e1dddc8971b9076b8

Best regards,
-- 
Krzysztof Kozlowski 
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [GIT PULL] memory: Tegra memory controller for v5.14

2021-06-11 Thread Krzysztof Kozlowski
On 10/06/2021 19:29, Will Deacon wrote:
> On Thu, Jun 10, 2021 at 05:05:27PM +0200, Thierry Reding wrote:
>> On Thu, Jun 10, 2021 at 04:23:56PM +0200, Krzysztof Kozlowski wrote:
>>> On 10/06/2021 11:19, Thierry Reding wrote:
>>>> On Tue, Jun 08, 2021 at 05:48:51PM +0100, Will Deacon wrote:
>>>>> I can queue as much or as little of 2-6 as you like, but I would like to
>>>>> avoid pulling in the memory controller queue into the arm smmu tree. But
>>>>> yes, whichever of those I take, I can put them on a separate branch so
>>>>> that you're not blocked for the later patches.
>>>>>
>>>>> You have a better handle on the dependencies, so please tell me what works
>>>>> for you. I just want to make sure that at least patch 3 lands in my tree,
>>>>> so we don't get late conflicts with other driver changes.
>>>>
>>>> Yes, if you could pick up patch 3 and send out a link with the stable
>>>> branch, I think Krzysztof or I could pull in that branch and pick up the
>>>> remaining patches. It'd be good if you could also ack the remaining SMMU
>>>> patches so that ARM SoC knows that they've been sanctioned.
>>>>
>>>> Krzysztof: would you be okay with picking up patches 2 and 4-6 on top of
>>>> your memory branch for v5.14?
>>>
>>> You mean the iommu patches? Yes, I can take them and later explain to
>>> Arnd/Olof why they come through me.
>>
>> Okay, great.
>>
>> Will, can you provide that stable branch? Or would you prefer if I
>> prepared it and sent you a pull request? We're kind of running out of
>> time, since for ARM SoC the cut-off point for new material is usually
>> -rc6 and that's coming up pretty fast.
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git/log/?h=for-thierry/arm-smmu

Merged, thanks.

I'll take ARM/SMMU patches from Thierry's patchset: 2, 4-6.


Best regards,
Krzysztof
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [GIT PULL] memory: Tegra memory controller for v5.14

2021-06-10 Thread Krzysztof Kozlowski
On 10/06/2021 11:19, Thierry Reding wrote:
> On Tue, Jun 08, 2021 at 05:48:51PM +0100, Will Deacon wrote:
>> On Tue, Jun 08, 2021 at 04:38:48PM +0200, Thierry Reding wrote:
>>> On Tue, Jun 08, 2021 at 01:01:29PM +0100, Will Deacon wrote:
>>>> On Mon, Jun 07, 2021 at 10:49:10AM +0200, Krzysztof Kozlowski wrote:
>>>>> This is the pull for you to base further SMMU aptches (prevent early SMMU
>>>>> faults).
>>>>
>>>> This is a tonne of code for me to pull into the SMMU tree given that I only
>>>> want one patch!
>>>>
>>>> Thierry, if I just stick:
>>>>
>>>> https://lore.kernel.org/r/20210603164632.1000458-4-thierry.red...@gmail.com
>>>>
>>>> on its own branch, can you stitch together whatever you need?
>>>
>>> I'm not sure I understand what you're proposing. For reference, here's
>>> the set of patches that I sent out:
>>>
>>>   1. memory: tegra: Implement SID override programming
>>>   2. dt-bindings: arm-smmu: Add Tegra186 compatible string
>>>   3. iommu/arm-smmu: Implement ->probe_finalize()
>>>   4. iommu/arm-smmu: tegra: Detect number of instances at runtime
>>>   5. iommu/arm-smmu: tegra: Implement SID override programming
>>>   6. iommu/arm-smmu: Use Tegra implementation on Tegra186
>>>   7. arm64: tegra: Use correct compatible string for Tegra186 SMMU
>>>   8. arm64: tegra: Hook up memory controller to SMMU on Tegra186
>>>   9. arm64: tegra: Enable SMMU support on Tegra194
>>>
>>> Krzysztof already picked up patch 1 and I was assuming that you'd pick
>>> up 2-6 because they are to the ARM SMMU driver. However, if you're
>>> primarily interested in just patch 3, which is more "core" ARM SMMU than
>>> the rest, which are Tegra-specific, then I suppose what we could do is
>>> for you to give an Acked-by on the rest (2, 4-6) and then Krzysztof or I
>>> can pick them up and take them via ARM SoC, based on the stable branch
>>> from your tree that only has patch 3.
>>
>> I think you previously said that patch 5 depends on patch 1, so I can't
>> take 2-6 without also pulling in the memory controller queue.
>>
>>> Patch 6 touches arm-smmu-impl.c, though it's a two-line change that
>>> touches only the Tegra-specific matching bit in arm_smmu_impl_init(), so
>>> the likelihood of that conflicting with anything else is fairly small.
>>>
>>> Is that what you were proposing?
>>
>> I can queue as much or as little of 2-6 as you like, but I would like to
>> avoid pulling in the memory controller queue into the arm smmu tree. But
>> yes, whichever of those I take, I can put them on a separate branch so
>> that you're not blocked for the later patches.
>>
>> You have a better handle on the dependencies, so please tell me what works
>> for you. I just want to make sure that at least patch 3 lands in my tree,
>> so we don't get late conflicts with other driver changes.
> 
> Yes, if you could pick up patch 3 and send out a link with the stable
> branch, I think Krzysztof or I could pull in that branch and pick up the
> remaining patches. It'd be good if you could also ack the remaining SMMU
> patches so that ARM SoC knows that they've been sanctioned.
> 
> Krzysztof: would you be okay with picking up patches 2 and 4-6 on top of
> your memory branch for v5.14?

You mean the iommu patches? Yes, I can take them and later explain to
Arnd/Olof why they come through me.


Best regards,
Krzysztof
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [GIT PULL] memory: Tegra memory controller for v5.14

2021-06-09 Thread Krzysztof Kozlowski
On 07/06/2021 10:49, Krzysztof Kozlowski wrote:
> Hi Olof and Arnd,
> 
> Tegra memory controller driver changes with necessary dependency from Thierry
> (which you will also get from him):
> 1. Dmitry's power domain work on Tegra MC drivers,
> 2. Necessary clock and regulator dependencies for Dmitry's work.
> 

Hi Olof and Arnd,

Just FYI, the stable tag from Thierry which I pulled here (and you will
get from him as well) might cause COMPILE_TEST failures on specific
configurations. Regular defconfigs and allyes/allmod should not be affected.

I am giving heads up in case this lands in Linus later...

There will be two fixes for this, sent already by Thierry:
https://lore.kernel.org/lkml/20210609112806.3565057-1-thierry.red...@gmail.com/

1. reset controller stubs: going via reset tree,
2. reserved memory section: probably going via my tree later.


Best regards,
Krzysztof
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


[GIT PULL] memory: Tegra memory controller for v5.14

2021-06-07 Thread Krzysztof Kozlowski
Hi Olof and Arnd,

Tegra memory controller driver changes with necessary dependency from Thierry
(which you will also get from him):
1. Dmitry's power domain work on Tegra MC drivers,
2. Necessary clock and regulator dependencies for Dmitry's work.


Hi Thierry and Will,

This is the pull for you to base further SMMU aptches (prevent early SMMU
faults).

Best regards,
Krzysztof


The following changes since commit 6efb943b8616ec53a5e444193dccf1af9ad627b5:

  Linux 5.13-rc1 (2021-05-09 14:17:44 -0700)

are available in the Git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux-mem-ctrl.git 
tags/memory-controller-drv-tegra-5.14

for you to fetch changes up to 393d66fd2cacba3e6aa95d7bb38790bfb7b1cc3a:

  memory: tegra: Implement SID override programming (2021-06-03 21:50:43 +0200)


Memory controller drivers for v5.14 - Tegra SoC

1. Enable compile testing of Tegra memory controller drivers.
2. Unify Tegra memory controller drivers. From Thierry Reding:
   "This set of patches converges the feature sets of the pre-Tegra186
   and the post-Tegra186 memory controller drivers such that newer chips
   can take advantage of some features that were previously only
   implemented on earlier chips."
3. Implement SID override programming as part of work to prevent early
   SMMU faults.
4. Some simplifications, e.g. use devm-helpers.

This pulls dedicated tag from Thierry Reding with necessary changes to
Tegra memory controller drivers, as a pre-requisite to series applied
here.  The changes from Thierry's tree also include their own
dependencies: regulator and clock driver changes.


Dmitry Osipenko (18):
  clk: tegra30: Use 300MHz for video decoder by default
  clk: tegra: Fix refcounting of gate clocks
  clk: tegra: Ensure that PLLU configuration is applied properly
  clk: tegra: Halve SCLK rate on Tegra20
  clk: tegra: Don't allow zero clock rate for PLLs
  clk: tegra: cclk: Handle thermal DIV2 CPU frequency throttling
  clk: tegra: Mark external clocks as not having reset control
  clk: tegra: Don't deassert reset on enabling clocks
  regulator: core: Add regulator_sync_voltage_rdev()
  soc/tegra: regulators: Bump voltages on system reboot
  soc/tegra: Add stub for soc_is_tegra()
  soc/tegra: Add devm_tegra_core_dev_init_opp_table()
  soc/tegra: fuse: Add stubs needed for compile-testing
  clk: tegra: Add stubs needed for compile-testing
  memory: tegra: Fix compilation warnings on 64bit platforms
  memory: tegra: Enable compile testing for all drivers
  memory: tegra20-emc: Use devm_tegra_core_dev_init_opp_table()
  memory: tegra30-emc: Use devm_tegra_core_dev_init_opp_table()

Krzysztof Kozlowski (1):
  Merge tag 'tegra-for-5.14-memory' of 
https://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux into 
for-v5.14/tegra-mc

Thierry Reding (16):
  Merge branch 'for-5.14/regulator' into for-5.14/soc
  Merge branch 'for-5.14/clk' into for-5.14/memory
  Merge branch 'for-5.14/soc' into for-5.14/memory
  memory: tegra: Consolidate register fields
  memory: tegra: Unify struct tegra_mc across SoC generations
  memory: tegra: Introduce struct tegra_mc_ops
  memory: tegra: Push suspend/resume into SoC drivers
  memory: tegra: Make per-SoC setup more generic
  memory: tegra: Extract setup code into callback
  memory: tegra: Parameterize interrupt handler
  memory: tegra: Make IRQ support opitonal
  memory: tegra: Only initialize reset controller if available
  memory: tegra: Unify drivers
  memory: tegra: Add memory client IDs to tables
  memory: tegra: Split Tegra194 data into separate file
  memory: tegra: Implement SID override programming

 drivers/clk/tegra/clk-periph-gate.c  |   80 +-
 drivers/clk/tegra/clk-periph.c   |   11 +
 drivers/clk/tegra/clk-pll.c  |   12 +-
 drivers/clk/tegra/clk-tegra-periph.c |6 +-
 drivers/clk/tegra/clk-tegra-super-cclk.c |   16 +-
 drivers/clk/tegra/clk-tegra20.c  |6 +-
 drivers/clk/tegra/clk-tegra30.c  |6 +-
 drivers/clk/tegra/clk.h  |4 -
 drivers/iommu/tegra-smmu.c   |   16 +-
 drivers/memory/tegra/Kconfig |   18 +-
 drivers/memory/tegra/Makefile|6 +-
 drivers/memory/tegra/mc.c|  321 +++---
 drivers/memory/tegra/mc.h|   25 +
 drivers/memory/tegra/tegra114.c  | 1245 --
 drivers/memory/tegra/tegra124-emc.c  |4 +-
 drivers/memory/tegra/tegra124.c  | 1306 ---
 drivers/memory/tegra/tegra186.c  | 1679 +-
 drivers/memory/tegra/tegra194.c  | 1351 
 drivers/memory/tegra/tegra20-emc.c   |   48 +-
 drivers/me

Re: (subset) [PATCH v3 0/9] arm64: tegra: Prevent early SMMU faults

2021-06-03 Thread Krzysztof Kozlowski
On Thu, 3 Jun 2021 18:46:23 +0200, Thierry Reding wrote:
> this is a set of patches that is the result of earlier discussions
> regarding early identity mappings that are needed to avoid SMMU faults
> during early boot.
> 
> The goal here is to avoid early identity mappings altogether and instead
> postpone the need for the identity mappings to when devices are attached
> to the SMMU. This works by making the SMMU driver coordinate with the
> memory controller driver on when to start enforcing SMMU translations.
> This makes Tegra behave in a more standard way and pushes the code to
> deal with the Tegra-specific programming into the NVIDIA SMMU
> implementation.
> 
> [...]

Applied, thanks!

[1/9] memory: tegra: Implement SID override programming
  commit: 393d66fd2cacba3e6aa95d7bb38790bfb7b1cc3a

Best regards,
-- 
Krzysztof Kozlowski 
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v2 00/10] arm64: tegra: Prevent early SMMU faults

2021-06-02 Thread Krzysztof Kozlowski
On 02/06/2021 16:58, Thierry Reding wrote:
> On Wed, Jun 02, 2021 at 12:40:49PM +0100, Will Deacon wrote:
>> On Wed, Jun 02, 2021 at 12:44:58PM +0200, Krzysztof Kozlowski wrote:
>>> On 02/06/2021 10:52, Thierry Reding wrote:
>>>> On Wed, Jun 02, 2021 at 09:35:13AM +0200, Krzysztof Kozlowski wrote:
>>>>> On 02/06/2021 09:33, Krzysztof Kozlowski wrote:
>>>>>> On 01/06/2021 20:08, Thierry Reding wrote:
>>>>>>> On Tue, Jun 01, 2021 at 01:26:46PM +0100, Will Deacon wrote:
>>>>>>>> On Fri, May 28, 2021 at 07:05:28PM +0200, Thierry Reding wrote:
>>>>>>>>> On Tue, Apr 20, 2021 at 07:26:09PM +0200, Thierry Reding wrote:
>>>>>>>>>> From: Thierry Reding 
>>>>>>>>>>
>>>>>>>> Probably best if I queue 3-6 on a separate branch once you send a v3,
>>>>>>>> then Krzysztof can pull that in if he needs it.
>>>>>>>
>>>>>>> Patch 5 has a build-time dependency on patch 1, so they need to go in
>>>>>>> together. The reason why I suggested Krzysztof pick these up is because
>>>>>>> there is a restructuring series that this depends on, which will go into
>>>>>>> Krzysztof's tree. So in order to pull in 3-6, you'd get a bunch of other
>>>>>>> and mostly unrelated stuff as well.
>>>>>>
>>>>>> I missed that part... what other series are needed for this one? Except
>>>>>> Dmitry's power management set I do not have anything in my sight for
>>>>>> Tegras memory controllers.
>>>>>>
>>>>>> Anyway, I can take the memory bits and provide a stable tag with these.
>>>>>> Recently there was quite a lot work around Tegra memory controllers, so
>>>>>> this makes especially sense if new patches appear.
>>>>>
>>>>> OK, I think I have now the patchset you talked about - "memory: tegra:
>>>>> Driver unification" v2, right?
>>>>
>>>> Yes, that's the one. That series is fairly self-contained, but Dmitry's
>>>> power management set has dependencies that pull in the regulator, clock
>>>> and ARM SoC trees.
>>>>
>>>> I did a test merge of the driver unification series with a branch that
>>>> has Dmitry's patches and all the dependencies and there are no conflicts
>>>> so that, fortunately, doesn't further complicates things.
>>>>
>>>> Do you want me to send you a pull request with Dmitry's memory
>>>> controller changes? You could then apply the unification series on top,
>>>> which should allow this SMMU series to apply cleanly on top of that.
>>>
>>> Makes sense and it looks quite bulletproof for future changes. Let's do
>>> like this. I will apply your patch 1/10 from this v2 on top of it and
>>> driver unification later.
>>
>> Okey doke. Thierry -- please let me know which patches I can queue. Having
>> the SMMU driver changes in the IOMMU tree really helps in case of conflicts
>> with other SMMU changes. As I say, I can put stuff on a separate branch for
>> you if it helps.
> 
> Given that the SMMU patches have a build-time dependency on the first
> patch in the series, and the series depends on the unification series, I
> think Krzysztof would have to pull the memory controller branch that I
> have with Dmitry's work, apply the unification series on top and then
> take patch 1 of this series on top of that. That's the state that you'd
> have to pull into the SMMU tree to get the right dependencies.
> 
> The SMMU pieces are the leaf of the dependency tree, so technically no
> separate branch is needed, because I don't think anybody would have to
> pull from it. However, a separate branch might make it easier to back
> any of this work out if we have to.
> 
> Krzysztof, I do plan on sending out a v3 of the unification series to
> address the two cleanups that Dmitry and you have pointed out. After
> that I can send out v3 of this series to fix the ordering issue that
> Krishna had mentioned. After all of those are applied, would you be able
> to provide a stable branch for Will's SMMU tree?

Yes, I will provide a stable branch/tag.

Best regards,
Krzysztof
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v2 00/10] arm64: tegra: Prevent early SMMU faults

2021-06-02 Thread Krzysztof Kozlowski
On 02/06/2021 16:53, Thierry Reding wrote:
> On Wed, Jun 02, 2021 at 12:44:58PM +0200, Krzysztof Kozlowski wrote:
>> On 02/06/2021 10:52, Thierry Reding wrote:
>>> On Wed, Jun 02, 2021 at 09:35:13AM +0200, Krzysztof Kozlowski wrote:
>>>> On 02/06/2021 09:33, Krzysztof Kozlowski wrote:
>>>>> On 01/06/2021 20:08, Thierry Reding wrote:
>>>>>> On Tue, Jun 01, 2021 at 01:26:46PM +0100, Will Deacon wrote:
>>>>>>> On Fri, May 28, 2021 at 07:05:28PM +0200, Thierry Reding wrote:
>>>>>>>> On Tue, Apr 20, 2021 at 07:26:09PM +0200, Thierry Reding wrote:
>>>>>>>>> From: Thierry Reding 
>>>>>>>>>
>>>>>>> Probably best if I queue 3-6 on a separate branch once you send a v3,
>>>>>>> then Krzysztof can pull that in if he needs it.
>>>>>>
>>>>>> Patch 5 has a build-time dependency on patch 1, so they need to go in
>>>>>> together. The reason why I suggested Krzysztof pick these up is because
>>>>>> there is a restructuring series that this depends on, which will go into
>>>>>> Krzysztof's tree. So in order to pull in 3-6, you'd get a bunch of other
>>>>>> and mostly unrelated stuff as well.
>>>>>
>>>>> I missed that part... what other series are needed for this one? Except
>>>>> Dmitry's power management set I do not have anything in my sight for
>>>>> Tegras memory controllers.
>>>>>
>>>>> Anyway, I can take the memory bits and provide a stable tag with these.
>>>>> Recently there was quite a lot work around Tegra memory controllers, so
>>>>> this makes especially sense if new patches appear.
>>>>
>>>> OK, I think I have now the patchset you talked about - "memory: tegra:
>>>> Driver unification" v2, right?
>>>
>>> Yes, that's the one. That series is fairly self-contained, but Dmitry's
>>> power management set has dependencies that pull in the regulator, clock
>>> and ARM SoC trees.
>>>
>>> I did a test merge of the driver unification series with a branch that
>>> has Dmitry's patches and all the dependencies and there are no conflicts
>>> so that, fortunately, doesn't further complicates things.
>>>
>>> Do you want me to send you a pull request with Dmitry's memory
>>> controller changes? You could then apply the unification series on top,
>>> which should allow this SMMU series to apply cleanly on top of that.
>>
>> Makes sense and it looks quite bulletproof for future changes. Let's do
>> like this. I will apply your patch 1/10 from this v2 on top of it and
>> driver unification later.
> 
> The SMMU series here depends on the unification series, so the
> unification series needs to go first. It'd be a fair bit of work to
> reverse that because the ->probe_device() callback implemented by the
> first patch of this SMMU series is part of the tegra_mc_ops structure
> that's introduced in the unification series.

Right, you already wrote it in the first email in this thread, I just
reversed words in my head... Then as you wrote - take Dmitry's changes
and share them via pull to me. I'll put on top the unification series,
then #1 from this SMMU series and finally I'll provide a pull request
for Will so his SMMU can go on.

Best regards,
Krzysztof
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v2 00/10] arm64: tegra: Prevent early SMMU faults

2021-06-02 Thread Krzysztof Kozlowski
On 02/06/2021 10:52, Thierry Reding wrote:
> On Wed, Jun 02, 2021 at 09:35:13AM +0200, Krzysztof Kozlowski wrote:
>> On 02/06/2021 09:33, Krzysztof Kozlowski wrote:
>>> On 01/06/2021 20:08, Thierry Reding wrote:
>>>> On Tue, Jun 01, 2021 at 01:26:46PM +0100, Will Deacon wrote:
>>>>> On Fri, May 28, 2021 at 07:05:28PM +0200, Thierry Reding wrote:
>>>>>> On Tue, Apr 20, 2021 at 07:26:09PM +0200, Thierry Reding wrote:
>>>>>>> From: Thierry Reding 
>>>>>>>
>>>>> Probably best if I queue 3-6 on a separate branch once you send a v3,
>>>>> then Krzysztof can pull that in if he needs it.
>>>>
>>>> Patch 5 has a build-time dependency on patch 1, so they need to go in
>>>> together. The reason why I suggested Krzysztof pick these up is because
>>>> there is a restructuring series that this depends on, which will go into
>>>> Krzysztof's tree. So in order to pull in 3-6, you'd get a bunch of other
>>>> and mostly unrelated stuff as well.
>>>
>>> I missed that part... what other series are needed for this one? Except
>>> Dmitry's power management set I do not have anything in my sight for
>>> Tegras memory controllers.
>>>
>>> Anyway, I can take the memory bits and provide a stable tag with these.
>>> Recently there was quite a lot work around Tegra memory controllers, so
>>> this makes especially sense if new patches appear.
>>
>> OK, I think I have now the patchset you talked about - "memory: tegra:
>> Driver unification" v2, right?
> 
> Yes, that's the one. That series is fairly self-contained, but Dmitry's
> power management set has dependencies that pull in the regulator, clock
> and ARM SoC trees.
> 
> I did a test merge of the driver unification series with a branch that
> has Dmitry's patches and all the dependencies and there are no conflicts
> so that, fortunately, doesn't further complicates things.
> 
> Do you want me to send you a pull request with Dmitry's memory
> controller changes? You could then apply the unification series on top,
> which should allow this SMMU series to apply cleanly on top of that.

Makes sense and it looks quite bulletproof for future changes. Let's do
like this. I will apply your patch 1/10 from this v2 on top of it and
driver unification later.

> I can also carry all these changes in the Tegra tree and send a PR in a
> few days once this has seen a bit more testing in linux-next, which also
> makes sure it's got a bit more testing in our internal test farm.
> 


Best regards,
Krzysztof
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v2 00/10] arm64: tegra: Prevent early SMMU faults

2021-06-02 Thread Krzysztof Kozlowski
On 02/06/2021 09:33, Krzysztof Kozlowski wrote:
> On 01/06/2021 20:08, Thierry Reding wrote:
>> On Tue, Jun 01, 2021 at 01:26:46PM +0100, Will Deacon wrote:
>>> On Fri, May 28, 2021 at 07:05:28PM +0200, Thierry Reding wrote:
>>>> On Tue, Apr 20, 2021 at 07:26:09PM +0200, Thierry Reding wrote:
>>>>> From: Thierry Reding 
>>>>>
>>> Probably best if I queue 3-6 on a separate branch once you send a v3,
>>> then Krzysztof can pull that in if he needs it.
>>
>> Patch 5 has a build-time dependency on patch 1, so they need to go in
>> together. The reason why I suggested Krzysztof pick these up is because
>> there is a restructuring series that this depends on, which will go into
>> Krzysztof's tree. So in order to pull in 3-6, you'd get a bunch of other
>> and mostly unrelated stuff as well.
> 
> I missed that part... what other series are needed for this one? Except
> Dmitry's power management set I do not have anything in my sight for
> Tegras memory controllers.
> 
> Anyway, I can take the memory bits and provide a stable tag with these.
> Recently there was quite a lot work around Tegra memory controllers, so
> this makes especially sense if new patches appear.

OK, I think I have now the patchset you talked about - "memory: tegra:
Driver unification" v2, right?


Best regards,
Krzysztof
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v2 00/10] arm64: tegra: Prevent early SMMU faults

2021-06-02 Thread Krzysztof Kozlowski
On 01/06/2021 20:08, Thierry Reding wrote:
> On Tue, Jun 01, 2021 at 01:26:46PM +0100, Will Deacon wrote:
>> On Fri, May 28, 2021 at 07:05:28PM +0200, Thierry Reding wrote:
>>> On Tue, Apr 20, 2021 at 07:26:09PM +0200, Thierry Reding wrote:
 From: Thierry Reding 

 Hi,

 this is a set of patches that is the result of earlier discussions
 regarding early identity mappings that are needed to avoid SMMU faults
 during early boot.

 The goal here is to avoid early identity mappings altogether and instead
 postpone the need for the identity mappings to when devices are attached
 to the SMMU. This works by making the SMMU driver coordinate with the
 memory controller driver on when to start enforcing SMMU translations.
 This makes Tegra behave in a more standard way and pushes the code to
 deal with the Tegra-specific programming into the NVIDIA SMMU
 implementation.

 Compared to the original version of these patches, I've split the
 preparatory work into a separate patch series because it became very
 large and will be mostly uninteresting for this audience.

 Patch 1 provides a mechanism to program SID overrides at runtime. Patch
 2 updates the ARM SMMU device tree bindings to include the Tegra186
 compatible string as suggested by Robin during review.

 Patches 3 and 4 create the fundamentals in the SMMU driver to support
 this and also make this functionality available on Tegra186. Patch 5
 hooks the ARM SMMU up to the memory controller so that the memory client
 stream ID overrides can be programmed at the right time.

 Patch 6 extends this mechanism to Tegra186 and patches 7-9 enable all of
 this through device tree updates. Patch 10 is included here to show how
 SMMU will be enabled for display controllers. However, it cannot be
 applied yet because the code to create identity mappings for potentially
 live framebuffers hasn't been merged yet.

 The end result is that various peripherals will have SMMU enabled, while
 the display controllers will keep using passthrough, as initially set up
 by firmware. Once the device tree bindings have been accepted and the
 SMMU driver has been updated to create identity mappings for the display
 controllers, they can be hooked up to the SMMU and the code in this
 series will automatically program the SID overrides to enable SMMU
 translations at the right time.

 Note that the series creates a compile time dependency between the
 memory controller and IOMMU trees. If it helps I can provide a branch
 for each tree, modelling the dependency, once the series has been
 reviewed.

 Changes in v2:
 - split off the preparatory work into a separate series (that needs to
   be applied first)
 - address review comments by Robin

 Thierry

 Thierry Reding (10):
   memory: tegra: Implement SID override programming
   dt-bindings: arm-smmu: Add Tegra186 compatible string
   iommu/arm-smmu: Implement ->probe_finalize()
   iommu/arm-smmu: tegra: Detect number of instances at runtime
   iommu/arm-smmu: tegra: Implement SID override programming
   iommu/arm-smmu: Use Tegra implementation on Tegra186
   arm64: tegra: Use correct compatible string for Tegra186 SMMU
   arm64: tegra: Hook up memory controller to SMMU on Tegra186
   arm64: tegra: Enable SMMU support on Tegra194
   arm64: tegra: Enable SMMU support for display on Tegra194

  .../devicetree/bindings/iommu/arm,smmu.yaml   |  11 +-
  arch/arm64/boot/dts/nvidia/tegra186.dtsi  |   4 +-
  arch/arm64/boot/dts/nvidia/tegra194.dtsi  | 166 ++
  drivers/iommu/arm/arm-smmu/arm-smmu-impl.c|   3 +-
  drivers/iommu/arm/arm-smmu/arm-smmu-nvidia.c  |  90 --
  drivers/iommu/arm/arm-smmu/arm-smmu.c |  13 ++
  drivers/iommu/arm/arm-smmu/arm-smmu.h |   1 +
  drivers/memory/tegra/mc.c |   9 +
  drivers/memory/tegra/tegra186.c   |  72 
  include/soc/tegra/mc.h|   3 +
  10 files changed, 349 insertions(+), 23 deletions(-)
>>>
>>> Will, Robin,
>>>
>>> do you have any more comments on the ARM SMMU bits of this series? If
>>> not, can you guys provide an Acked-by so that Krzysztof can pick this
>>> (modulo the DT patches) up into the memory-controller tree for v5.14?
>>>
>>> I'll send out a v3 with the bisectibilitiy fix that Krishna pointed
>>> out.
>>
>> Probably best if I queue 3-6 on a separate branch once you send a v3,
>> then Krzysztof can pull that in if he needs it.
> 
> Patch 5 has a build-time dependency on patch 1, so they need to go in
> together. The reason why I suggested Krzysztof pick these up is because
> there is a restructuring series that this depends on, which will go into
> Krzysztof's tree. So in order to 

Re: [PATCH v2 01/10] memory: tegra: Implement SID override programming

2021-04-26 Thread Krzysztof Kozlowski
On 26/04/2021 14:13, Thierry Reding wrote:
> On Mon, Apr 26, 2021 at 10:28:43AM +0200, Krzysztof Kozlowski wrote:

(...)

>>> +
>>> +   value = readl(mc->regs + client->regs.sid.override);
>>> +   old = value & MC_SID_STREAMID_OVERRIDE_MASK;
>>> +
>>> +   if (old != sid) {
>>> +   dev_dbg(mc->dev, "overriding SID %x for %s with %x\n", old,
>>> +   client->name, sid);
>>> +   writel(sid, mc->regs + client->regs.sid.override);
>>> +   }
>>> +}
>>> +
>>> +static int tegra186_mc_probe_device(struct tegra_mc *mc, struct device 
>>> *dev)
>>> +{
>>> +#if IS_ENABLED(CONFIG_IOMMU_API)
>>
>> Is this part really build-time dependent? I don't see here any uses of
>> IOMMU specific fields, so maybe this should be runtime choice based on
>> enabled interconnect devices?
> 
> Unfortunately it is. struct iommu_fwspec is an empty structure for
> !CONFIG_IOMMU_API, so the code below that tries to access fwspec->ids
> fails for !CONFIG_IOMMU_API configurations if we don't protect this with
> the preprocessor guard.

OK, thanks.

> 
>>
>>> +   struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
>>> +   struct of_phandle_args args;
>>> +   unsigned int i, index = 0;
>>> +
>>> +   while (!of_parse_phandle_with_args(dev->of_node, "interconnects", 
>>> "#interconnect-cells",
>>> +  index, )) {
>>> +   if (args.np == mc->dev->of_node && args.args_count != 0) {
>>> +   for (i = 0; i < mc->soc->num_clients; i++) {
>>> +   const struct tegra_mc_client *client = 
>>> >soc->clients[i];
>>> +
>>> +   if (client->id == args.args[0]) {
>>> +   u32 sid = fwspec->ids[0] & 
>>> MC_SID_STREAMID_OVERRIDE_MASK;
>>> +
>>> +   tegra186_mc_client_sid_override(mc, 
>>> client, sid);
>>> +   }
>>> +   }
>>> +   }
>>> +
>>> +   index++;
>>> +   }
>>> +#endif
>>> +
>>> +   return 0;
>>> +}
>>> +
>>>  const struct tegra_mc_ops tegra186_mc_ops = {
>>> .probe = tegra186_mc_probe,
>>> .remove = tegra186_mc_remove,
>>> .resume = tegra186_mc_resume,
>>> +   .probe_device = tegra186_mc_probe_device,
>>>  };
>>>  
>>>  #if defined(CONFIG_ARCH_TEGRA_186_SOC)
>>> diff --git a/include/soc/tegra/mc.h b/include/soc/tegra/mc.h
>>> index 1387747d574b..bbad6330008b 100644
>>> --- a/include/soc/tegra/mc.h
>>> +++ b/include/soc/tegra/mc.h
>>> @@ -176,6 +176,7 @@ struct tegra_mc_ops {
>>> int (*suspend)(struct tegra_mc *mc);
>>> int (*resume)(struct tegra_mc *mc);
>>> irqreturn_t (*handle_irq)(int irq, void *data);
>>> +   int (*probe_device)(struct tegra_mc *mc, struct device *dev);
>>>  };
>>>  
>>>  struct tegra_mc_soc {
>>> @@ -240,4 +241,6 @@ devm_tegra_memory_controller_get(struct device *dev)
>>>  }
>>>  #endif
>>>  
>>> +int tegra_mc_probe_device(struct tegra_mc *mc, struct device *dev);
>>> +
>>
>> What about !CONFIG_TEGRA_MC? I think arm-smmmu will fail.
> 
> I think it doesn't fail because for !CONFIG_TEGRA_MC it basically throws
> away most of nvidia_smmu_impl_init() already because ERR_PTR(-ENODEV) is
> returned by devm_tegra_memory_controller_get() and so it unconditionally
> fails early on already.
> 
> I say I /think/ that happens because I can't reproduce a build failure
> even if I manually tweak the .config such that ARM_SMMU is enabled and
> TEGRA_MC is disabled. But I can't say I fully understand why it's
> working, because, yes, the symbol definitely doesn't exist. But again,
> if the compiler is clever enough to figure out that that function can't
> be called anyway and doesn't even want it, why bother making it more
> complicated than it has to be?

Since you tested that case, it's fine.


Best regards,
Krzysztof
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v2 01/10] memory: tegra: Implement SID override programming

2021-04-26 Thread Krzysztof Kozlowski
On 20/04/2021 19:26, Thierry Reding wrote:
> From: Thierry Reding 
> 
> Instead of programming all SID overrides during early boot, perform the
> operation on-demand after the SMMU translations have been set up for a
> device. This reuses data from device tree to match memory clients for a
> device and programs the SID specified in device tree, which corresponds
> to the SID used for the SMMU context banks for the device.
> 
> Signed-off-by: Thierry Reding 
> ---
>  drivers/memory/tegra/mc.c   |  9 +
>  drivers/memory/tegra/tegra186.c | 72 +
>  include/soc/tegra/mc.h  |  3 ++
>  3 files changed, 84 insertions(+)
> 
> diff --git a/drivers/memory/tegra/mc.c b/drivers/memory/tegra/mc.c
> index c854639cf30c..bace5ecfe770 100644
> --- a/drivers/memory/tegra/mc.c
> +++ b/drivers/memory/tegra/mc.c
> @@ -97,6 +97,15 @@ struct tegra_mc *devm_tegra_memory_controller_get(struct 
> device *dev)
>  }
>  EXPORT_SYMBOL_GPL(devm_tegra_memory_controller_get);
>  
> +int tegra_mc_probe_device(struct tegra_mc *mc, struct device *dev)
> +{
> + if (mc->soc->ops && mc->soc->ops->probe_device)
> + return mc->soc->ops->probe_device(mc, dev);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(tegra_mc_probe_device);
> +
>  static int tegra_mc_block_dma_common(struct tegra_mc *mc,
>const struct tegra_mc_reset *rst)
>  {
> diff --git a/drivers/memory/tegra/tegra186.c b/drivers/memory/tegra/tegra186.c
> index 1f87915ccd62..e65eac5764d4 100644
> --- a/drivers/memory/tegra/tegra186.c
> +++ b/drivers/memory/tegra/tegra186.c
> @@ -4,6 +4,7 @@
>   */
>  
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -15,6 +16,10 @@
>  #include 
>  #endif
>  
> +#define MC_SID_STREAMID_OVERRIDE_MASK GENMASK(7, 0)
> +#define MC_SID_STREAMID_SECURITY_WRITE_ACCESS_DISABLED BIT(16)
> +#define MC_SID_STREAMID_SECURITY_OVERRIDE BIT(8)
> +
>  static void tegra186_mc_program_sid(struct tegra_mc *mc)
>  {
>   unsigned int i;
> @@ -66,10 +71,77 @@ static int tegra186_mc_resume(struct tegra_mc *mc)
>   return 0;
>  }
>  
> +static void tegra186_mc_client_sid_override(struct tegra_mc *mc,
> + const struct tegra_mc_client 
> *client,
> + unsigned int sid)
> +{
> + u32 value, old;
> +
> + value = readl(mc->regs + client->regs.sid.security);
> + if ((value & MC_SID_STREAMID_SECURITY_OVERRIDE) == 0) {
> + /*
> +  * If the secure firmware has locked this down the override
> +  * for this memory client, there's nothing we can do here.
> +  */
> + if (value & MC_SID_STREAMID_SECURITY_WRITE_ACCESS_DISABLED)
> + return;
> +
> + /*
> +  * Otherwise, try to set the override itself. Typically the
> +  * secure firmware will never have set this configuration.
> +  * Instead, it will either have disabled write access to
> +  * this field, or it will already have set an explicit
> +  * override itself.
> +  */
> + WARN_ON((value & MC_SID_STREAMID_SECURITY_OVERRIDE) == 0);
> +
> + value |= MC_SID_STREAMID_SECURITY_OVERRIDE;
> + writel(value, mc->regs + client->regs.sid.security);
> + }
> +
> + value = readl(mc->regs + client->regs.sid.override);
> + old = value & MC_SID_STREAMID_OVERRIDE_MASK;
> +
> + if (old != sid) {
> + dev_dbg(mc->dev, "overriding SID %x for %s with %x\n", old,
> + client->name, sid);
> + writel(sid, mc->regs + client->regs.sid.override);
> + }
> +}
> +
> +static int tegra186_mc_probe_device(struct tegra_mc *mc, struct device *dev)
> +{
> +#if IS_ENABLED(CONFIG_IOMMU_API)

Is this part really build-time dependent? I don't see here any uses of
IOMMU specific fields, so maybe this should be runtime choice based on
enabled interconnect devices?

> + struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
> + struct of_phandle_args args;
> + unsigned int i, index = 0;
> +
> + while (!of_parse_phandle_with_args(dev->of_node, "interconnects", 
> "#interconnect-cells",
> +index, )) {
> + if (args.np == mc->dev->of_node && args.args_count != 0) {
> + for (i = 0; i < mc->soc->num_clients; i++) {
> + const struct tegra_mc_client *client = 
> >soc->clients[i];
> +
> + if (client->id == args.args[0]) {
> + u32 sid = fwspec->ids[0] & 
> MC_SID_STREAMID_OVERRIDE_MASK;
> +
> + tegra186_mc_client_sid_override(mc, 
> client, sid);
> + }
> + }
> + }
> +
> + index++;
> + }
> +#endif
> +
> + return 0;
> +}
> +
>  

Re: (subset) [PATCH v5 00/16] Clean up "mediatek,larb"

2021-04-13 Thread Krzysztof Kozlowski
On Sat, 10 Apr 2021 17:11:12 +0800, Yong Wu wrote:
> MediaTek IOMMU block diagram always like below:
> 
> M4U
>  |
> smi-common
>  |
>   -
>   | |  ...
>   | |
> larb1 larb2
>   | |
> vdec   venc
> 
> [...]

Applied, thanks!

[04/16] memory: mtk-smi: Add device-link between smi-larb and smi-common
commit: 6ce2c05b21189eb17b3aa26720cc5841acf9dce8

Best regards,
-- 
Krzysztof Kozlowski 
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v5 04/16] memory: mtk-smi: Add device-link between smi-larb and smi-common

2021-04-13 Thread Krzysztof Kozlowski
On 13/04/2021 08:04, Yong Wu wrote:
> On Sat, 2021-04-10 at 14:40 +0200, Krzysztof Kozlowski wrote:
>> On 10/04/2021 11:11, Yong Wu wrote:
>>> Normally, If the smi-larb HW need work, we should enable the smi-common
>>> HW power and clock firstly.
>>> This patch adds device-link between the smi-larb dev and the smi-common
>>> dev. then If pm_runtime_get_sync(smi-larb-dev), the pm_runtime_get_sync
>>> (smi-common-dev) will be called automatically.
>>>
>>> Also, Add DL_FLAG_STATELESS to avoid the smi-common clocks be gated when
>>> probe.
>>>
>>> CC: Matthias Brugger 
>>> Suggested-by: Tomasz Figa 
>>> Signed-off-by: Yong Wu 
>>> ---
>>>  drivers/memory/mtk-smi.c | 19 ++-
>>>  1 file changed, 10 insertions(+), 9 deletions(-)
>>
>> I understood this is a dependency for other patches, so:
>> Acked-by: Krzysztof Kozlowski 
>>
>> If I am wrong and I can take it via memory tree, let me know.
> 
> Hi Krzysztof,
> 
> Thanks very much for your quickly review.
> 
> I think it is ok if it go through memory tree. In the original patch, we
> pm_runtime_get(smi-common-dev) in the smi-larb's pm resume callback.
> This patch only use device-link do this. thus, this patch have no
> function change. it only adjusts the SMI internal code flow.

Hm, okay, I took it then for v5.13.

> 
> In addition, [14/16] expects your Acked-by. and that one should be
> merged with the others.

Thanks for reminder.

Best regards,
Krzysztof
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v5 14/16] memory: mtk-smi: Get rid of mtk_smi_larb_get/put

2021-04-13 Thread Krzysztof Kozlowski
On 10/04/2021 11:11, Yong Wu wrote:
> After adding device_link between the iommu consumer and smi-larb,
> the pm_runtime_get(_sync) of smi-larb and smi-common will be called
> automatically. we can get rid of mtk_smi_larb_get/put.
> 
> CC: Matthias Brugger 
> Signed-off-by: Yong Wu 
> Reviewed-by: Evan Green 
> ---
>  drivers/memory/mtk-smi.c   | 14 --
>  include/soc/mediatek/smi.h | 20 
>  2 files changed, 34 deletions(-)
> 


Acked-by: Krzysztof Kozlowski 


Best regards,
Krzysztof
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v5 04/16] memory: mtk-smi: Add device-link between smi-larb and smi-common

2021-04-10 Thread Krzysztof Kozlowski
On 10/04/2021 11:11, Yong Wu wrote:
> Normally, If the smi-larb HW need work, we should enable the smi-common
> HW power and clock firstly.
> This patch adds device-link between the smi-larb dev and the smi-common
> dev. then If pm_runtime_get_sync(smi-larb-dev), the pm_runtime_get_sync
> (smi-common-dev) will be called automatically.
> 
> Also, Add DL_FLAG_STATELESS to avoid the smi-common clocks be gated when
> probe.
> 
> CC: Matthias Brugger 
> Suggested-by: Tomasz Figa 
> Signed-off-by: Yong Wu 
> ---
>  drivers/memory/mtk-smi.c | 19 ++-
>  1 file changed, 10 insertions(+), 9 deletions(-)

I understood this is a dependency for other patches, so:
Acked-by: Krzysztof Kozlowski 

If I am wrong and I can take it via memory tree, let me know.

Best regards,
Krzysztof
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


[PATCH] iommu: exynos: remove unneeded local variable initialization

2021-04-08 Thread Krzysztof Kozlowski
The initialization of 'fault_addr' local variable is not needed as it is
shortly after overwritten.

Addresses-Coverity: Unused value
Signed-off-by: Krzysztof Kozlowski 
---
 drivers/iommu/exynos-iommu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
index de324b4eedfe..8fa9a591fb96 100644
--- a/drivers/iommu/exynos-iommu.c
+++ b/drivers/iommu/exynos-iommu.c
@@ -407,7 +407,7 @@ static irqreturn_t exynos_sysmmu_irq(int irq, void *dev_id)
struct sysmmu_drvdata *data = dev_id;
const struct sysmmu_fault_info *finfo;
unsigned int i, n, itype;
-   sysmmu_iova_t fault_addr = -1;
+   sysmmu_iova_t fault_addr;
unsigned short reg_status, reg_clear;
int ret = -ENOSYS;
 
-- 
2.25.1

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v2] memory: mtk-smi: Support SMI modular

2021-01-26 Thread Krzysztof Kozlowski
On Tue, Jan 26, 2021 at 02:00:55PM +0800, Yong Wu wrote:
> This patch mainly support SMI modular. Switch MTK_SMI to tristate,
> and add module_exit/module_license.
> 
> Signed-off-by: Yong Wu 
> ---
> This patch rebase on the clean v5.11-rc1.
> and this one: memory: mtk-smi: Use platform_register_drivers
> https://lore.kernel.org/linux-arm-kernel/20210121062429.26504-2-yong...@mediatek.com/
> 
> change note:
> a) squash the last two of v1 into one patch.
> b) Remove module_alias
> ---
>  drivers/memory/Kconfig | 2 +-
>  drivers/memory/mtk-smi.c   | 9 +
>  include/soc/mediatek/smi.h | 2 +-
>  3 files changed, 11 insertions(+), 2 deletions(-)

Thanks, applied with slightly adjusted commit msg and subject.

Best regards,
Krzysztof

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH 2/3] memory: mtk-smi: Add module_exit and module_license

2021-01-25 Thread Krzysztof Kozlowski
On Mon, Jan 25, 2021 at 05:28:05PM +0800, Yong Wu wrote:
> On Mon, 2021-01-25 at 09:40 +0100, Krzysztof Kozlowski wrote:
> > On Mon, Jan 25, 2021 at 02:49:41PM +0800, Yong Wu wrote:
> > > On Fri, 2021-01-22 at 22:34 +0100, Krzysztof Kozlowski wrote:
> > > > On Thu, Jan 21, 2021 at 02:24:28PM +0800, Yong Wu wrote:
> > > > > The config MTK_SMI always depends on MTK_IOMMU which is built-in
> > > > > currently. Thus we don't have module_exit before. This patch adds
> > > > > module_exit and module_license. It is a preparing patch for supporting
> > > > > MTK_SMI could been built as a module.
> > > > > 
> > > > > Signed-off-by: Yong Wu 
> > > > > ---
> > > > >  drivers/memory/mtk-smi.c | 10 ++
> > > > >  1 file changed, 10 insertions(+)
> > > > > 
> > > > > diff --git a/drivers/memory/mtk-smi.c b/drivers/memory/mtk-smi.c
> > > > > index e2aebd2bfa8e..aa2a25abf04f 100644
> > > > > --- a/drivers/memory/mtk-smi.c
> > > > > +++ b/drivers/memory/mtk-smi.c
> > > > > @@ -597,3 +597,13 @@ static int __init mtk_smi_init(void)
> > > > >   return platform_register_drivers(smidrivers, 
> > > > > ARRAY_SIZE(smidrivers));
> > > > >  }
> > > > >  module_init(mtk_smi_init);
> > > > > +
> > > > > +static void __exit mtk_smi_exit(void)
> > > > > +{
> > > > > + platform_unregister_drivers(smidrivers, ARRAY_SIZE(smidrivers));
> > > > > +}
> > > > > +module_exit(mtk_smi_exit);
> > > > > +
> > > > > +MODULE_DESCRIPTION("MediaTek SMI driver");
> > > > > +MODULE_ALIAS("platform:MediaTek-SMI");
> > > > 
> > > > Drivers do not use capital letters, so I have doubts whether this alias
> > > > is correct.
> > > 
> > > I didn't care the upper/lower-case. I will change to lower case in next
> > > time.
> > 
> > Then why do you need the alias? The name does not match driver name, so
> > what's the purpose of this alias/
> 
> I think it is not so necessary for us. I will delete this line in next
> version.
> 
> Only curious what's alias is fit in our case? normally it should be the
> file name: mtk-smi?

If autoloading of your module works, then remove it. The alias is
necessary for some cases when a device table is missing (e.g. platform
driver is matched via devicetree but not having the platform_device_id
table) or matching is done via different method (e.g. driver is matched
from MFD via devicetree compatible even though there is a
platform_device_id table).

Best regards,
Krzysztof
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH 3/3] memory: mtk-smi: Switch MTK_SMI to tristate

2021-01-25 Thread Krzysztof Kozlowski
On Mon, Jan 25, 2021 at 02:49:44PM +0800, Yong Wu wrote:
> On Fri, 2021-01-22 at 22:35 +0100, Krzysztof Kozlowski wrote:
> > On Thu, Jan 21, 2021 at 02:24:29PM +0800, Yong Wu wrote:
> > > This patch switches MTK_SMI to tristate. Support it could be 'm'.
> > > 
> > > Meanwhile, Fix a build issue while MTK_SMI is built as module.
> > 
> > s/Fix/fix.
> > 
> > What error is being fixed here? How can I reproduce it? Aren't you just
> > adjusting it to being buildable by module?
> 
> Sorry, I didn't copy the fail log here. This is the build log:
> 
> In file included from .../drivers/iommu/mtk_iommu.c:34:0:
> .../drivers/iommu/mtk_iommu.h:84:28: error: array type has incomplete
> element type 'struct mtk_smi_larb_iommu'
>   struct mtk_smi_larb_iommu larb_imu[MTK_LARB_NR_MAX];
> 
> Our iommu driver will use this structure. but it was contained by
> "#ifdef CONFIG_MTK_SMI". thus I change it to "#if
> IS_ENABLED(CONFIG_MTK_SMI)"
> 
> If reproducing it, we should change mtk-iommu to module_init[1]. and
> switch kconfig MTK_IOMMU to tristate, then change the CONFIG_MTK_IOMMU
> to m. we could get the fail log.
> 
> In this case, Should I squash this change into this patch? I though this
> is a preparing patch and the fail is caused by MTK_SMI. thus I squash
> that into this patch. or change it as a independent patch and send when
> I change MTK_IOMMU to tristate?

If I understand correctly, there is no error before this patch. In such
case just don't mention the error to fix, because it is simply part of
making things modular.

Best regards,
Krzysztof

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH 2/3] memory: mtk-smi: Add module_exit and module_license

2021-01-25 Thread Krzysztof Kozlowski
On Mon, Jan 25, 2021 at 02:49:41PM +0800, Yong Wu wrote:
> On Fri, 2021-01-22 at 22:34 +0100, Krzysztof Kozlowski wrote:
> > On Thu, Jan 21, 2021 at 02:24:28PM +0800, Yong Wu wrote:
> > > The config MTK_SMI always depends on MTK_IOMMU which is built-in
> > > currently. Thus we don't have module_exit before. This patch adds
> > > module_exit and module_license. It is a preparing patch for supporting
> > > MTK_SMI could been built as a module.
> > > 
> > > Signed-off-by: Yong Wu 
> > > ---
> > >  drivers/memory/mtk-smi.c | 10 ++
> > >  1 file changed, 10 insertions(+)
> > > 
> > > diff --git a/drivers/memory/mtk-smi.c b/drivers/memory/mtk-smi.c
> > > index e2aebd2bfa8e..aa2a25abf04f 100644
> > > --- a/drivers/memory/mtk-smi.c
> > > +++ b/drivers/memory/mtk-smi.c
> > > @@ -597,3 +597,13 @@ static int __init mtk_smi_init(void)
> > >   return platform_register_drivers(smidrivers, ARRAY_SIZE(smidrivers));
> > >  }
> > >  module_init(mtk_smi_init);
> > > +
> > > +static void __exit mtk_smi_exit(void)
> > > +{
> > > + platform_unregister_drivers(smidrivers, ARRAY_SIZE(smidrivers));
> > > +}
> > > +module_exit(mtk_smi_exit);
> > > +
> > > +MODULE_DESCRIPTION("MediaTek SMI driver");
> > > +MODULE_ALIAS("platform:MediaTek-SMI");
> > 
> > Drivers do not use capital letters, so I have doubts whether this alias
> > is correct.
> 
> I didn't care the upper/lower-case. I will change to lower case in next
> time.

Then why do you need the alias? The name does not match driver name, so
what's the purpose of this alias/

> 
> MODULE_ALIAS("platform:MediaTek-smi")
> 
> > 
> > Adding all these should be squashed with changing Kconfig into tristate.
> > It does not have sense on its own.
> 
> Thanks  very much for review.
> 
> Only confirm: Squash whole this patch or only squash the MODULE_x into
> the next patch?

This entire patch 2/3 should be with 3/3.

Best regards,
Krzysztof
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH 3/3] memory: mtk-smi: Switch MTK_SMI to tristate

2021-01-22 Thread Krzysztof Kozlowski
On Thu, Jan 21, 2021 at 02:24:29PM +0800, Yong Wu wrote:
> This patch switches MTK_SMI to tristate. Support it could be 'm'.
> 
> Meanwhile, Fix a build issue while MTK_SMI is built as module.

s/Fix/fix.

What error is being fixed here? How can I reproduce it? Aren't you just
adjusting it to being buildable by module?

Best regards,
Krzysztof


> 
> Signed-off-by: Yong Wu 
> ---
> This patch has a little conflict with the mt8192 iommu patch which
> delete the MTK_LARB_NR_MAX in smi.h(It's still reviewing).
> This patch rebase on the clean v5.11-rc1.
> ---
>  drivers/memory/Kconfig | 2 +-
>  include/soc/mediatek/smi.h | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/memory/Kconfig b/drivers/memory/Kconfig
> index 3ea6913df176..d5f0f4680880 100644
> --- a/drivers/memory/Kconfig
> +++ b/drivers/memory/Kconfig
> @@ -173,7 +173,7 @@ config JZ4780_NEMC
> memory devices such as NAND and SRAM.
>  
>  config MTK_SMI
> - bool "Mediatek SoC Memory Controller driver" if COMPILE_TEST
> + tristate "Mediatek SoC Memory Controller driver" if COMPILE_TEST
>   depends on ARCH_MEDIATEK || COMPILE_TEST
>   help
> This driver is for the Memory Controller module in MediaTek SoCs,
> diff --git a/include/soc/mediatek/smi.h b/include/soc/mediatek/smi.h
> index 5a34b87d89e3..29e2fb8f33d6 100644
> --- a/include/soc/mediatek/smi.h
> +++ b/include/soc/mediatek/smi.h
> @@ -9,7 +9,7 @@
>  #include 
>  #include 
>  
> -#ifdef CONFIG_MTK_SMI
> +#if IS_ENABLED(CONFIG_MTK_SMI)
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH 2/3] memory: mtk-smi: Add module_exit and module_license

2021-01-22 Thread Krzysztof Kozlowski
On Thu, Jan 21, 2021 at 02:24:28PM +0800, Yong Wu wrote:
> The config MTK_SMI always depends on MTK_IOMMU which is built-in
> currently. Thus we don't have module_exit before. This patch adds
> module_exit and module_license. It is a preparing patch for supporting
> MTK_SMI could been built as a module.
> 
> Signed-off-by: Yong Wu 
> ---
>  drivers/memory/mtk-smi.c | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/drivers/memory/mtk-smi.c b/drivers/memory/mtk-smi.c
> index e2aebd2bfa8e..aa2a25abf04f 100644
> --- a/drivers/memory/mtk-smi.c
> +++ b/drivers/memory/mtk-smi.c
> @@ -597,3 +597,13 @@ static int __init mtk_smi_init(void)
>   return platform_register_drivers(smidrivers, ARRAY_SIZE(smidrivers));
>  }
>  module_init(mtk_smi_init);
> +
> +static void __exit mtk_smi_exit(void)
> +{
> + platform_unregister_drivers(smidrivers, ARRAY_SIZE(smidrivers));
> +}
> +module_exit(mtk_smi_exit);
> +
> +MODULE_DESCRIPTION("MediaTek SMI driver");
> +MODULE_ALIAS("platform:MediaTek-SMI");

Drivers do not use capital letters, so I have doubts whether this alias
is correct.

Adding all these should be squashed with changing Kconfig into tristate.
It does not have sense on its own.

Best regards,
Krzysztof
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH 1/3] memory: mtk-smi: Use platform_register_drivers

2021-01-22 Thread Krzysztof Kozlowski
On Thu, Jan 21, 2021 at 02:24:27PM +0800, Yong Wu wrote:
> In this file, we have 2 drivers, smi-common and smi-larb.
> Use platform_register_drivers.
> 
> Signed-off-by: Yong Wu 
> ---
>  drivers/memory/mtk-smi.c | 25 ++---
>  1 file changed, 6 insertions(+), 19 deletions(-)

Thanks, applied.

Best regards,
Krzysztof

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v5 06/27] dt-bindings: mediatek: Add binding for mt8192 IOMMU

2020-12-09 Thread Krzysztof Kozlowski
On Wed, Dec 09, 2020 at 04:00:41PM +0800, Yong Wu wrote:
> This patch adds decriptions for mt8192 IOMMU and SMI.
> 
> mt8192 also is MTK IOMMU gen2 which uses ARM Short-Descriptor translation
> table format. The M4U-SMI HW diagram is as below:
> 
>   EMI
>|
>   M4U
>|
>   
>SMI Common
>   
>|
>   +---+--+--+--+---+
>   |   |  |  |   .. |   |
>   |   |  |  |  |   |
> larb0   larb1  larb2  larb4 ..  larb19   larb20
> disp0   disp1   mdpvdec   IPE  IPE
> 
> All the connections are HW fixed, SW can NOT adjust it.
> 
> mt8192 M4U support 0~16GB iova range. we preassign different engines
> into different iova ranges:
> 
> domain-id  module iova-range  larbs
>0   disp0 ~ 4G  larb0/1
>1   vcodec  4G ~ 8G larb4/5/7
>2   cam/mdp 8G ~ 12G larb2/9/11/13/14/16/17/18/19/20
>3   CCU00x4000_ ~ 0x43ff_ larb13: port 9/10
>4   CCU10x4400_ ~ 0x47ff_ larb14: port 4/5
> 
> The iova range for CCU0/1(camera control unit) is HW requirement.
> 
> Signed-off-by: Yong Wu 
> Reviewed-by: Rob Herring 
> ---
>  .../bindings/iommu/mediatek,iommu.yaml|  18 +-
>  include/dt-bindings/memory/mt8192-larb-port.h | 240 ++
>  2 files changed, 257 insertions(+), 1 deletion(-)
>  create mode 100644 include/dt-bindings/memory/mt8192-larb-port.h
> 

Acked-by: Krzysztof Kozlowski 

Best regards,
Krzysztof
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v5 05/27] dt-bindings: memory: mediatek: Rename header guard for SMI header file

2020-12-09 Thread Krzysztof Kozlowski
On Wed, Dec 09, 2020 at 04:00:40PM +0800, Yong Wu wrote:
> Only rename the header guard for all the SoC larb port header file.
> No funtional change.
> 
> Suggested-by: Krzysztof Kozlowski 
> Signed-off-by: Yong Wu 
> ---

Acked-by: Krzysztof Kozlowski 

Best regards,
Krzysztof
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v4 18/24] iommu/mediatek: Support master use iova over 32bit

2020-11-11 Thread Krzysztof Kozlowski
On Wed, Nov 11, 2020 at 08:38:32PM +0800, Yong Wu wrote:
> After extending v7s, our pagetable already support iova reach
> 16GB(34bit). the master got the iova via dma_alloc_attrs may reach
> 34bits, but its HW register still is 32bit. then how to set the
> bit32/bit33 iova? this depend on a SMI larb setting(bank_sel).
> 
> we separate whole 16GB iova to four banks:
> bank: 0: 0~4G; 1: 4~8G; 2: 8-12G; 3: 12-16G;
> The bank number is (iova >> 32).
> 
> We will preassign which bank the larbs belong to. currently we don't
> have a interface for master to adjust its bank number.
> 
> Each a bank is a iova_region which is a independent iommu-domain.
> the iova range for each iommu-domain can't cross 4G.
> 
> Signed-off-by: Yong Wu 
> Acked-by: Krzysztof Kozlowski  # memory part
> ---
>  drivers/iommu/mtk_iommu.c  | 12 +---
>  drivers/memory/mtk-smi.c   |  7 +++
>  include/soc/mediatek/smi.h |  1 +
>  3 files changed, 17 insertions(+), 3 deletions(-)
> 

Acked-by: Krzysztof Kozlowski 

Best regards,
Krzysztof
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v4 06/24] iommu/mediatek: Use the common mtk-smi-larb-port.h

2020-11-11 Thread Krzysztof Kozlowski
On Wed, Nov 11, 2020 at 08:38:20PM +0800, Yong Wu wrote:
> Use the common larb-port header in the source code.
> 
> Signed-off-by: Yong Wu 
> ---
>  drivers/iommu/mtk_iommu.c  | 7 ---
>  drivers/iommu/mtk_iommu.h  | 1 +
>  drivers/memory/mtk-smi.c   | 1 +
>  include/soc/mediatek/smi.h | 2 --
>  4 files changed, 2 insertions(+), 9 deletions(-)
> 

Acked-by: Krzysztof Kozlowski 

Best regards,
Krzysztof
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v4 05/24] dt-bindings: mediatek: Add binding for mt8192 IOMMU

2020-11-11 Thread Krzysztof Kozlowski
On Wed, Nov 11, 2020 at 08:38:19PM +0800, Yong Wu wrote:
> This patch adds decriptions for mt8192 IOMMU and SMI.
> 
> mt8192 also is MTK IOMMU gen2 which uses ARM Short-Descriptor translation
> table format. The M4U-SMI HW diagram is as below:
> 
>   EMI
>|
>   M4U
>|
>   
>SMI Common
>   
>|
>   +---+--+--+--+---+
>   |   |  |  |   .. |   |
>   |   |  |  |  |   |
> larb0   larb1  larb2  larb4 ..  larb19   larb20
> disp0   disp1   mdpvdec   IPE  IPE
> 
> All the connections are HW fixed, SW can NOT adjust it.
> 
> mt8192 M4U support 0~16GB iova range. we preassign different engines
> into different iova ranges:
> 
> domain-id  module iova-range  larbs
>0   disp0 ~ 4G  larb0/1
>1   vcodec  4G ~ 8G larb4/5/7
>2   cam/mdp 8G ~ 12G larb2/9/11/13/14/16/17/18/19/20
>3   CCU00x4000_ ~ 0x43ff_ larb13: port 9/10
>4   CCU10x4400_ ~ 0x47ff_ larb14: port 4/5
> 
> The iova range for CCU0/1(camera control unit) is HW requirement.
> 
> Signed-off-by: Yong Wu 
> Reviewed-by: Rob Herring 
> ---
>  .../bindings/iommu/mediatek,iommu.yaml|  18 +-
>  include/dt-bindings/memory/mt8192-larb-port.h | 240 ++
>  2 files changed, 257 insertions(+), 1 deletion(-)
>  create mode 100644 include/dt-bindings/memory/mt8192-larb-port.h
> 
> diff --git a/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml 
> b/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml
> index ba6626347381..0f26fe14c8e2 100644
> --- a/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml
> +++ b/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml
> @@ -76,6 +76,7 @@ properties:
>- mediatek,mt8167-m4u  # generation two
>- mediatek,mt8173-m4u  # generation two
>- mediatek,mt8183-m4u  # generation two
> +  - mediatek,mt8192-m4u  # generation two
>  
>- description: mt7623 generation one
>  items:
> @@ -115,7 +116,11 @@ properties:
>dt-binding/memory/mt6779-larb-port.h for mt6779,
>dt-binding/memory/mt8167-larb-port.h for mt8167,
>dt-binding/memory/mt8173-larb-port.h for mt8173,
> -  dt-binding/memory/mt8183-larb-port.h for mt8183.
> +  dt-binding/memory/mt8183-larb-port.h for mt8183,
> +  dt-binding/memory/mt8192-larb-port.h for mt8192.
> +
> +  power-domains:
> +maxItems: 1
>  
>  required:
>- compatible
> @@ -133,11 +138,22 @@ allOf:
>- mediatek,mt2701-m4u
>- mediatek,mt2712-m4u
>- mediatek,mt8173-m4u
> +  - mediatek,mt8192-m4u
>  
>  then:
>required:
>  - clocks
>  
> +  - if:
> +  properties:
> +compatible:
> +  enum:
> +- mediatek,mt8192-m4u
> +
> +then:
> +  required:
> +- power-domains
> +
>  additionalProperties: false
>  
>  examples:
> diff --git a/include/dt-bindings/memory/mt8192-larb-port.h 
> b/include/dt-bindings/memory/mt8192-larb-port.h
> new file mode 100644
> index ..7437fa62654e
> --- /dev/null
> +++ b/include/dt-bindings/memory/mt8192-larb-port.h
> @@ -0,0 +1,240 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * Copyright (c) 2020 MediaTek Inc.
> + *
> + * Author: Chao Hao 
> + * Author: Yong Wu 
> + */
> +#ifndef _DTS_IOMMU_PORT_MT8192_H_
> +#define _DTS_IOMMU_PORT_MT8192_H_

Not accurate header guard. Shoud be:
_DT_BINDINGS_MEMORY_MT8192_LARB_PORT_H_

Probably you copied it from some other Mediatek headers - all of them
have header guard pointing to different directory.

Best regards,
Krzysztof
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v4 04/24] dt-bindings: memory: mediatek: Add domain definition

2020-11-11 Thread Krzysztof Kozlowski
On Wed, Nov 11, 2020 at 08:38:18PM +0800, Yong Wu wrote:
> In the latest SoC, there are several HW IP require a sepecial iova
> range, mainly CCU and VPU has this requirement. Take CCU as a example,
> CCU require its iova locate in the range(0x4000_ ~ 0x43ff_).
> 
> In this patch we add a domain definition for the special port. In the
> example of CCU, If we preassign CCU port in domain1, then iommu driver
> will prepare a independent iommu domain of the special iova range for it,
> then the iova got from dma_alloc_attrs(ccu-dev) will locate in its special
> range.
> 
> This is a preparing patch for multi-domain support.
> 
> Signed-off-by: Yong Wu 
> ---
>  include/dt-bindings/memory/mtk-smi-larb-port.h | 9 -
>  1 file changed, 8 insertions(+), 1 deletion(-)
> 

Acked-by: Krzysztof Kozlowski 

Best regards,
Krzysztof
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v4 03/24] dt-bindings: memory: mediatek: Extend LARB_NR_MAX to 32

2020-11-11 Thread Krzysztof Kozlowski
On Wed, Nov 11, 2020 at 08:38:17PM +0800, Yong Wu wrote:
> Extend the max larb number definition as mt8192 has larb_nr over 16.
> 
> Signed-off-by: Yong Wu 
> Acked-by: Rob Herring 
> ---
>  Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml | 2 +-
>  include/dt-bindings/memory/mtk-smi-larb-port.h  | 4 ++--
>  2 files changed, 3 insertions(+), 3 deletions(-)
> 

Acked-by: Krzysztof Kozlowski 

Best regards,
Krzysztof
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v4 02/24] dt-bindings: memory: mediatek: Add a common larb-port header file

2020-11-11 Thread Krzysztof Kozlowski
On Wed, Nov 11, 2020 at 08:38:16PM +0800, Yong Wu wrote:
> Put all the macros about smi larb/port togethers, this is a preparing
> patch for extending LARB_NR and adding new dom-id support.
> 
> Signed-off-by: Yong Wu 
> Acked-by: Rob Herring 
> ---
>  include/dt-bindings/memory/mt2712-larb-port.h  |  2 +-
>  include/dt-bindings/memory/mt6779-larb-port.h  |  2 +-
>  include/dt-bindings/memory/mt8167-larb-port.h  |  2 +-
>  include/dt-bindings/memory/mt8173-larb-port.h  |  2 +-
>  include/dt-bindings/memory/mt8183-larb-port.h  |  2 +-
>  include/dt-bindings/memory/mtk-smi-larb-port.h | 15 +++
>  6 files changed, 20 insertions(+), 5 deletions(-)
>  create mode 100644 include/dt-bindings/memory/mtk-smi-larb-port.h
> 
> diff --git a/include/dt-bindings/memory/mt2712-larb-port.h 
> b/include/dt-bindings/memory/mt2712-larb-port.h

Acked-by: Krzysztof Kozlowski 

Best regards,
Krzysztof
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v5 3/3] memory: mtk-smi: Add mt8192 support

2020-11-05 Thread Krzysztof Kozlowski
On Tue, Nov 03, 2020 at 01:42:00PM +0800, Yong Wu wrote:
> Add mt8192 smi support.
> 
> Signed-off-by: Yong Wu 
> ---
>  drivers/memory/mtk-smi.c | 19 +++

Thanks, applied.

Best regards,
Krzysztof

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v5 1/3] dt-bindings: memory: mediatek: Convert SMI to DT schema

2020-11-05 Thread Krzysztof Kozlowski
On Tue, Nov 03, 2020 at 01:41:58PM +0800, Yong Wu wrote:
> Convert MediaTek SMI to DT schema.
> 
> Signed-off-by: Yong Wu 
> ---
>  .../mediatek,smi-common.txt   |  50 ---
>  .../mediatek,smi-common.yaml  | 140 ++
>  .../memory-controllers/mediatek,smi-larb.txt  |  50 ---
>  .../memory-controllers/mediatek,smi-larb.yaml | 130 
>  4 files changed, 270 insertions(+), 100 deletions(-)
>  delete mode 100644 
> Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.txt
>  create mode 100644 
> Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml
>  delete mode 100644 
> Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt
>  create mode 100644 
> Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml

Thanks, applied with Rob's tag.

Best regards,
Krzysztof

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v5 2/3] dt-bindings: memory: mediatek: Add mt8192 support

2020-11-05 Thread Krzysztof Kozlowski
On Tue, Nov 03, 2020 at 01:41:59PM +0800, Yong Wu wrote:
> Add mt8192 smi support in the bindings.
> 
> Signed-off-by: Yong Wu 
> Reviewed-by: Rob Herring 
> ---
>  .../bindings/memory-controllers/mediatek,smi-common.yaml  | 4 +++-
>  .../bindings/memory-controllers/mediatek,smi-larb.yaml| 2 ++

Thanks, applied.

Best regards,
Krzysztof

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v4 1/3] dt-bindings: memory: mediatek: Convert SMI to DT

2020-11-01 Thread Krzysztof Kozlowski
On Mon, 2 Nov 2020 at 06:31, Yong Wu  wrote:
>
> On Sat, 2020-10-31 at 12:36 +0100, Krzysztof Kozlowski wrote:
> > On Fri, Oct 30, 2020 at 05:12:52PM +0800, Yong Wu wrote:
> > > Convert MediaTek SMI to DT schema.
> > >
> > > CC: Fabien Parent 
> > > CC: Ming-Fan Chen 
> > > CC: Matthias Brugger 
> > > Signed-off-by: Yong Wu 
> > > ---
> > >  .../mediatek,smi-common.txt   |  50 ---
> > >  .../mediatek,smi-common.yaml  | 140 ++
> > >  .../memory-controllers/mediatek,smi-larb.txt  |  50 ---
> > >  .../memory-controllers/mediatek,smi-larb.yaml | 129 
> > >  4 files changed, 269 insertions(+), 100 deletions(-)
> > >  delete mode 100644 
> > > Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.txt
> >
> > +Cc Honghui Zhang,
>
> As comment [1], Honghui's address is not valid now. I will act for him.
>
> >
> > Your Ack is needed as you contributed descriptions to the bindings and
> > work is being relicensed to GPL-2.0-only OR BSD-2-Clause.
>
> "GPL-2.0-only OR BSD-2-Clause" is required when we run check-patch.
>
> If I still use "GPL-2.0-only", then the contributors' Ack/SoB is not
> needed, right?

That would be one solution but I was thinking to proceed with only
your agreement. You were the main contributor to these files. Honghui
added a few descriptions. Other developers added only compatibles.
Since we cannot reach Honghui, I would assume that your agreement
(Sign-off) is enough.

Best regards,
Krzysztof
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v4 1/3] dt-bindings: memory: mediatek: Convert SMI to DT schema

2020-10-31 Thread Krzysztof Kozlowski
On Fri, Oct 30, 2020 at 05:12:52PM +0800, Yong Wu wrote:
> Convert MediaTek SMI to DT schema.
> 
> CC: Fabien Parent 
> CC: Ming-Fan Chen 
> CC: Matthias Brugger 
> Signed-off-by: Yong Wu 
> ---
>  .../mediatek,smi-common.txt   |  50 ---
>  .../mediatek,smi-common.yaml  | 140 ++
>  .../memory-controllers/mediatek,smi-larb.txt  |  50 ---
>  .../memory-controllers/mediatek,smi-larb.yaml | 129 
>  4 files changed, 269 insertions(+), 100 deletions(-)
>  delete mode 100644 
> Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.txt

+Cc Honghui Zhang,

Your Ack is needed as you contributed descriptions to the bindings and
work is being relicensed to GPL-2.0-only OR BSD-2-Clause.


Best regards,
Krzysztof




>  create mode 100644 
> Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml
>  delete mode 100644 
> Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt
>  create mode 100644 
> Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml
> 
> diff --git 
> a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.txt
>  
> b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.txt
> deleted file mode 100644
> index dbafffe3f41e..
> --- 
> a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.txt
> +++ /dev/null
> @@ -1,50 +0,0 @@
> -SMI (Smart Multimedia Interface) Common
> -
> -The hardware block diagram please check bindings/iommu/mediatek,iommu.txt
> -
> -Mediatek SMI have two generations of HW architecture, here is the list
> -which generation the SoCs use:
> -generation 1: mt2701 and mt7623.
> -generation 2: mt2712, mt6779, mt8167, mt8173 and mt8183.
> -
> -There's slight differences between the two SMI, for generation 2, the
> -register which control the iommu port is at each larb's register base. But
> -for generation 1, the register is at smi ao base(smi always on register
> -base). Besides that, the smi async clock should be prepared and enabled for
> -SMI generation 1 to transform the smi clock into emi clock domain, but that 
> is
> -not needed for SMI generation 2.
> -
> -Required properties:
> -- compatible : must be one of :
> - "mediatek,mt2701-smi-common"
> - "mediatek,mt2712-smi-common"
> - "mediatek,mt6779-smi-common"
> - "mediatek,mt7623-smi-common", "mediatek,mt2701-smi-common"
> - "mediatek,mt8167-smi-common"
> - "mediatek,mt8173-smi-common"
> - "mediatek,mt8183-smi-common"
> -- reg : the register and size of the SMI block.
> -- power-domains : a phandle to the power domain of this local arbiter.
> -- clocks : Must contain an entry for each entry in clock-names.
> -- clock-names : must contain 3 entries for generation 1 smi HW and 2 entries
> -  for generation 2 smi HW as follows:
> -  - "apb" : Advanced Peripheral Bus clock, It's the clock for setting
> - the register.
> -  - "smi" : It's the clock for transfer data and command.
> - They may be the same if both source clocks are the same.
> -  - "async" : asynchronous clock, it help transform the smi clock into the 
> emi
> -   clock domain, this clock is only needed by generation 1 smi HW.
> -  and these 2 option clocks for generation 2 smi HW:
> -  - "gals0": the path0 clock of GALS(Global Async Local Sync).
> -  - "gals1": the path1 clock of GALS(Global Async Local Sync).
> -  Here is the list which has this GALS: mt6779 and mt8183.
> -
> -Example:
> - smi_common: smi@14022000 {
> - compatible = "mediatek,mt8173-smi-common";
> - reg = <0 0x14022000 0 0x1000>;
> - power-domains = < MT8173_POWER_DOMAIN_MM>;
> - clocks = < CLK_MM_SMI_COMMON>,
> -  < CLK_MM_SMI_COMMON>;
> - clock-names = "apb", "smi";
> - };
> diff --git 
> a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml
>  
> b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml
> new file mode 100644
> index ..e050a0c2aed6
> --- /dev/null
> +++ 
> b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml
> @@ -0,0 +1,140 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +# Copyright (c) 2020 MediaTek Inc.
> +%YAML 1.2
> +---
> +$id: 
> http://devicetree.org/schemas/memory-controllers/mediatek,smi-common.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: SMI (Smart Multimedia Interface) Common
> +
> +maintainers:
> +  - Yong Wu 
> +
> +description: |+
> +  The hardware block diagram please check bindings/iommu/mediatek,iommu.yaml
> +
> +  MediaTek SMI have two generations of HW architecture, here is the list
> +  which generation the SoCs use:
> +  generation 1: mt2701 and mt7623.
> +  generation 2: mt2712, mt6779, mt8167, mt8173 and mt8183.
> +
> +  There's slight differences between the 

Re: [PATCH v3 00/24] MT8192 IOMMU support

2020-10-26 Thread Krzysztof Kozlowski
On Wed, Sep 30, 2020 at 03:06:23PM +0800, Yong Wu wrote:
> This patch mainly adds support for mt8192 IOMMU and SMI.
> 
> mt8192 also is MTK IOMMU gen2 which uses ARM Short-Descriptor translation
> table format. The M4U-SMI HW diagram is as below:
> 
>   EMI
>|
>   M4U
>|
>   
>SMI Common
>   
>|
>   +---+--+--+--+---+
>   |   |  |  |   .. |   |
>   |   |  |  |  |   |
> larb0   larb1  larb2  larb4 ..  larb19   larb20
> disp0   disp1   mdpvdec   IPE  IPE
> 
> All the connections are HW fixed, SW can NOT adjust it.
> 
> Comparing with the preview SoC, this patchset mainly adds two new functions:
> a) add iova 34 bits support.
> b) add multi domains support since several HW has the special iova
> region requirement.
> 
> this patchset depend on v5.9-rc1.

Hi,

I think there will be v4 of this, right? If yes, please also describe
the dependencies between the patches. If the entire patchset is strictly
ordered, then mention this as well.

Best regards,
Krzysztof

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v3 01/24] dt-bindings: iommu: mediatek: Convert IOMMU to DT schema

2020-10-12 Thread Krzysztof Kozlowski
On Tue, 6 Oct 2020 at 06:27, Yong Wu  wrote:
>
> On Fri, 2020-10-02 at 13:07 +0200, Krzysztof Kozlowski wrote:
> > On Wed, Sep 30, 2020 at 03:06:24PM +0800, Yong Wu wrote:
> > > Convert MediaTek IOMMU to DT schema.
> > >
> > > Signed-off-by: Yong Wu 
> > > ---
> > >  .../bindings/iommu/mediatek,iommu.txt | 103 
> > >  .../bindings/iommu/mediatek,iommu.yaml| 154 ++
> > >  2 files changed, 154 insertions(+), 103 deletions(-)
> > >  delete mode 100644 
> > > Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
> > >  create mode 100644 
> > > Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml
> > >
>
> [...]
>
> > > +properties:
> > > +  compatible:
> > > +oneOf:
> > > +  - enum:
> > > +  - mediatek,mt2701-m4u # mt2701 generation one HW
> > > +  - mediatek,mt2712-m4u # mt2712 generation two HW
> > > +  - mediatek,mt6779-m4u # mt6779 generation two HW
> > > +  - mediatek,mt8173-m4u # mt8173 generation two HW
> > > +  - mediatek,mt8183-m4u # mt8183 generation two HW
> > > +
> > > +  - description: mt7623 generation one HW
> > > +items:
> > > +  - const: mediatek,mt7623-m4u
> > > +  - const: mediatek,mt2701-m4u
> > > +
> > > +  reg:
> > > +maxItems: 1
> > > +
> > > +  interrupts:
> > > +maxItems: 1
> > > +
> > > +  clocks:
> > > +description: |
> > > +  bclk is optional. here is the list which require this bclk:
> > > +  mt2701, mt2712, mt7623 and mt8173.
> >
> > Similarly to my comment in other patch, this should be part of schema
> > within 'if-then'.
>
> Thanks for the review.
>
> I will change like this:
>
> =
>   clocks:
> items:
>   - description: bclk is the block clock.
>
>   clock-names:
> items:
>   - const: bclk
>
> required:
>   - compatible
>   - reg
>   - interrupts
>   - mediatek,larbs
>   - '#iommu-cells'
> if:
>   properties:
> compatible:
>   contains:
> enum:
>   - mediatek,mt2701-m4u
>   - mediatek,mt2712-m4u
>   - mediatek,mt8173-m4u
>
> then:
>  required:
>- clocks
> ==
>
> If this is not right, please tell me.
> (dt_binding_check is ok.)

Looks fine, except "if" should be part of some "allOf" block.

Best regards,
Krzysztof
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v3 02/24] dt-bindings: memory: mediatek: Convert SMI to DT schema

2020-10-12 Thread Krzysztof Kozlowski
On Mon, 12 Oct 2020 at 14:02, Yong Wu  wrote:
>
> On Mon, 2020-10-12 at 09:18 +0200, Krzysztof Kozlowski wrote:
> > On Sat, Oct 10, 2020 at 02:18:11PM +0800, Yong Wu wrote:
> > > On Tue, 2020-10-06 at 09:15 +0200, Krzysztof Kozlowski wrote:
> > > > On Tue, 6 Oct 2020 at 06:27, Yong Wu  wrote:
> > > > >
> > > > > On Fri, 2020-10-02 at 13:08 +0200, Krzysztof Kozlowski wrote:
> > > > > > On Wed, Sep 30, 2020 at 03:06:25PM +0800, Yong Wu wrote:
> > > > > > > Convert MediaTek SMI to DT schema.
> > > > > > >
> > > > > > > Signed-off-by: Yong Wu 
> > > > > > > ---
> > > > > > >  .../mediatek,smi-common.txt   |  49 -
> > > > > > >  .../mediatek,smi-common.yaml  | 100 
> > > > > > > ++
> > > > > > >  .../memory-controllers/mediatek,smi-larb.txt  |  49 -
> > > > > > >  .../memory-controllers/mediatek,smi-larb.yaml |  91 
> > > > > > > 
> > > > > > >  4 files changed, 191 insertions(+), 98 deletions(-)
> > > > > > >  delete mode 100644 
> > > > > > > Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.txt
> > > > > > >  create mode 100644 
> > > > > > > Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml
> > > > > > >  delete mode 100644 
> > > > > > > Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt
> > > > > > >  create mode 100644 
> > > > > > > Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml
> > > > > ...
> > > > > > > +properties:
> > > > > > > +  compatible:
> > > > > > > +oneOf:
> > > > > > > +  - enum:
> > > > > > > +  - mediatek,mt2701-smi-common
> > > > > > > +  - mediatek,mt2712-smi-common
> > > > > > > +  - mediatek,mt6779-smi-common
> > > > > > > +  - mediatek,mt8173-smi-common
> > > > > > > +  - mediatek,mt8183-smi-common
> > > > > > > +
> > > > > > > +  - description: for mt7623
> > > > > > > +items:
> > > > > > > +  - const: mediatek,mt7623-smi-common
> > > > > > > +  - const: mediatek,mt2701-smi-common
> > > > > > > +
> > > > > > > +  reg:
> > > > > > > +maxItems: 1
> > > > > > > +
> > > > > > > +  clocks:
> > > > > > > +description: |
> > > > > > > +  apb and smi are mandatory. the async is only for 
> > > > > > > generation 1 smi HW.
> > > > > > > +  gals(global async local sync) also is optional, here is 
> > > > > > > the list which
> > > > > > > +  require gals: mt6779 and mt8183.
> > > > > > > +minItems: 2
> > > > > > > +maxItems: 4
> > > > > > > +items:
> > > > > > > +  - description: apb is Advanced Peripheral Bus clock, It's 
> > > > > > > the clock for
> > > > > > > +  setting the register.
> > > > > > > +  - description: smi is the clock for transfer data and 
> > > > > > > command.
> > > > > > > +  - description: async is asynchronous clock, it help 
> > > > > > > transform the smi clock
> > > > > > > +  into the emi clock domain.
> > > > > > > +  - description: gals0 is the path0 clock of gals.
> > > > > > > +  - description: gals1 is the path1 clock of gals.
> > > > > > > +
> > > > > > > +  clock-names:
> > > > > > > +oneOf:
> > > > > > > +  - items:
> > > > > > > +  - const: apb
> > > > > > > +  - const: smi
> > > > > > > +  - items:
> > > > > > > +  - const: apb
> > > > > > > +  - const: smi
> > > > > > > +  - const: async
> > > > > > > +  - items:
> > > > > > > +  - const: apb
> > > > > > > +  - const: smi
> > > > > > > +  - const: gals0
> > > > > > > +  - const: gals1
> > > > > >
> > > > > > Similarly to my comment to other properties, this requirement per
> > > > > > compatible should be part of the schema within 'if-then'.
> > > > >
> > > > > I'm not so familiar with this format. Do this has "if-then-'else
> > > > > if'-then-else"?
> > > >
> > > > These are mutually exclusive conditions, so you can skip else:
> > > >  - if-then
> > > >  - if-then
> > > >  - if-then
> > > > It will be more readable then stacking 'if' under 'else'
> > >
> > > Thanks. I will use something like this:
> > >
> > >  anyOf:
> >
> > Then it should be oneOf as only one condition can be valid.
>
> I did do this at the beginning. But I get a warning log when
> dt_binding_check.

Mhmm, right, since "if-else" matches in either of arms, then oneOf
will complain as it expects only one of items to match.  Then just go
with allOf. anyOf might match zero of items, so it would not catch
actual errors, I think.

Best regards,
Krzysztof
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v3 02/24] dt-bindings: memory: mediatek: Convert SMI to DT schema

2020-10-12 Thread Krzysztof Kozlowski
On Sat, Oct 10, 2020 at 02:18:11PM +0800, Yong Wu wrote:
> On Tue, 2020-10-06 at 09:15 +0200, Krzysztof Kozlowski wrote:
> > On Tue, 6 Oct 2020 at 06:27, Yong Wu  wrote:
> > >
> > > On Fri, 2020-10-02 at 13:08 +0200, Krzysztof Kozlowski wrote:
> > > > On Wed, Sep 30, 2020 at 03:06:25PM +0800, Yong Wu wrote:
> > > > > Convert MediaTek SMI to DT schema.
> > > > >
> > > > > Signed-off-by: Yong Wu 
> > > > > ---
> > > > >  .../mediatek,smi-common.txt   |  49 -
> > > > >  .../mediatek,smi-common.yaml  | 100 
> > > > > ++
> > > > >  .../memory-controllers/mediatek,smi-larb.txt  |  49 -
> > > > >  .../memory-controllers/mediatek,smi-larb.yaml |  91 
> > > > >  4 files changed, 191 insertions(+), 98 deletions(-)
> > > > >  delete mode 100644 
> > > > > Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.txt
> > > > >  create mode 100644 
> > > > > Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml
> > > > >  delete mode 100644 
> > > > > Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt
> > > > >  create mode 100644 
> > > > > Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml
> > > ...
> > > > > +properties:
> > > > > +  compatible:
> > > > > +oneOf:
> > > > > +  - enum:
> > > > > +  - mediatek,mt2701-smi-common
> > > > > +  - mediatek,mt2712-smi-common
> > > > > +  - mediatek,mt6779-smi-common
> > > > > +  - mediatek,mt8173-smi-common
> > > > > +  - mediatek,mt8183-smi-common
> > > > > +
> > > > > +  - description: for mt7623
> > > > > +items:
> > > > > +  - const: mediatek,mt7623-smi-common
> > > > > +  - const: mediatek,mt2701-smi-common
> > > > > +
> > > > > +  reg:
> > > > > +maxItems: 1
> > > > > +
> > > > > +  clocks:
> > > > > +description: |
> > > > > +  apb and smi are mandatory. the async is only for generation 1 
> > > > > smi HW.
> > > > > +  gals(global async local sync) also is optional, here is the 
> > > > > list which
> > > > > +  require gals: mt6779 and mt8183.
> > > > > +minItems: 2
> > > > > +maxItems: 4
> > > > > +items:
> > > > > +  - description: apb is Advanced Peripheral Bus clock, It's the 
> > > > > clock for
> > > > > +  setting the register.
> > > > > +  - description: smi is the clock for transfer data and command.
> > > > > +  - description: async is asynchronous clock, it help transform 
> > > > > the smi clock
> > > > > +  into the emi clock domain.
> > > > > +  - description: gals0 is the path0 clock of gals.
> > > > > +  - description: gals1 is the path1 clock of gals.
> > > > > +
> > > > > +  clock-names:
> > > > > +oneOf:
> > > > > +  - items:
> > > > > +  - const: apb
> > > > > +  - const: smi
> > > > > +  - items:
> > > > > +  - const: apb
> > > > > +  - const: smi
> > > > > +  - const: async
> > > > > +  - items:
> > > > > +  - const: apb
> > > > > +  - const: smi
> > > > > +  - const: gals0
> > > > > +  - const: gals1
> > > >
> > > > Similarly to my comment to other properties, this requirement per
> > > > compatible should be part of the schema within 'if-then'.
> > >
> > > I'm not so familiar with this format. Do this has "if-then-'else
> > > if'-then-else"?
> > 
> > These are mutually exclusive conditions, so you can skip else:
> >  - if-then
> >  - if-then
> >  - if-then
> > It will be more readable then stacking 'if' under 'else'
> 
> Thanks. I will use something like this:
> 
>  anyOf:

Then it should be oneOf as only one condition can be valid.

Best regards,
Krzysztof

>- if: #gen1 hw
>  then:
>use apb/smi/async clocks
> 
>- if: #gen2 hw that has gals.
>  then:
>use apb/smi/gals0/gals1 clocks
>  else: # gen2 hw that doesn't have gals.
>use apb/smi clocks.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v3 06/24] dt-bindings: mediatek: Add binding for mt8192 IOMMU

2020-10-06 Thread Krzysztof Kozlowski
On Tue, Oct 06, 2020 at 12:26:45PM +0800, Yong Wu wrote:
> Hi Krzysztof,
> 
> On Fri, 2020-10-02 at 13:10 +0200, Krzysztof Kozlowski wrote:
> > On Wed, Sep 30, 2020 at 03:06:29PM +0800, Yong Wu wrote:
> > > This patch adds decriptions for mt8192 IOMMU and SMI.
> > > 
> > > mt8192 also is MTK IOMMU gen2 which uses ARM Short-Descriptor translation
> > > table format. The M4U-SMI HW diagram is as below:
> > > 
> > >   EMI
> > >|
> > >   M4U
> > >|
> > >   
> > >SMI Common
> > >   
> > >|
> > >   +---+--+--+--+---+
> > >   |   |  |  |   .. |   |
> > >   |   |  |  |  |   |
> > > larb0   larb1  larb2  larb4 ..  larb19   larb20
> > > disp0   disp1   mdpvdec   IPE  IPE
> > > 
> > > All the connections are HW fixed, SW can NOT adjust it.
> > > 
> > > mt8192 M4U support 0~16GB iova range. we preassign different engines
> > > into different iova ranges:
> > > 
> > > domain-id  module iova-range  larbs
> > >0   disp0 ~ 4G  larb0/1
> > >1   vcodec  4G ~ 8G larb4/5/7
> > >2   cam/mdp 8G ~ 12G 
> > > larb2/9/11/13/14/16/17/18/19/20
> > >3   CCU00x4000_ ~ 0x43ff_ larb13: port 9/10
> > >4   CCU10x4400_ ~ 0x47ff_ larb14: port 4/5
> > > 
> > > The iova range for CCU0/1(camera control unit) is HW requirement.
> > > 
> > > Signed-off-by: Yong Wu 
> > > Reviewed-by: Rob Herring 
> > > ---
> > >  .../bindings/iommu/mediatek,iommu.yaml|   9 +-
> > >  .../mediatek,smi-common.yaml  |   5 +-
> > >  .../memory-controllers/mediatek,smi-larb.yaml |   3 +-
> > >  include/dt-bindings/memory/mt8192-larb-port.h | 239 ++
> > >  4 files changed, 251 insertions(+), 5 deletions(-)
> > >  create mode 100644 include/dt-bindings/memory/mt8192-larb-port.h
> > 
> > I see it depends on previous patches but does it have to be within one
> > commit? Is it not bisectable? The memory changes/bindings could go via
> > memory tree if this is split.
> 
> Thanks for the view.
> 
> I can split this into two patchset in next version, one is for iommu and
> the other is for smi.
> 
> Only the patch [18/24] change both the code(iommu and smi). I don't plan
> to split it, and the smi patch[24/24] don't depend on it(won't
> conflict).

It got too late in the cycle, so I am not going to take the 24/24 now.

> 
> since 18/24 also touch the smi code, I expect it could get Acked-by from
> you or Matthias, then Joerg could take it.

Sure. I acked it.

Best regards,
Krzysztof
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v3 18/24] iommu/mediatek: Support master use iova over 32bit

2020-10-06 Thread Krzysztof Kozlowski
On Wed, Sep 30, 2020 at 03:06:41PM +0800, Yong Wu wrote:
> After extending v7s, our pagetable already support iova reach
> 16GB(34bit). the master got the iova via dma_alloc_attrs may reach
> 34bits, but its HW register still is 32bit. then how to set the
> bit32/bit33 iova? this depend on a SMI larb setting(bank_sel).
> 
> we separate whole 16GB iova to four banks:
> bank: 0: 0~4G; 1: 4~8G; 2: 8-12G; 3: 12-16G;
> The bank number is (iova >> 32).
> 
> We will preassign which bank the larbs belong to. currently we don't
> have a interface for master to adjust its bank number.
> 
> Each a bank is a iova_region which is a independent iommu-domain.
> the iova range for each iommu-domain can't cross 4G.
> 
> Signed-off-by: Yong Wu 
> ---
>  drivers/iommu/mtk_iommu.c  | 12 +---
>  drivers/memory/mtk-smi.c   |  7 +++
>  include/soc/mediatek/smi.h |  1 +
>  3 files changed, 17 insertions(+), 3 deletions(-)


For the memory part:
Acked-by: Krzysztof Kozlowski 

Best regards,
Krzysztof
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v3 02/24] dt-bindings: memory: mediatek: Convert SMI to DT schema

2020-10-06 Thread Krzysztof Kozlowski
On Tue, 6 Oct 2020 at 06:27, Yong Wu  wrote:
>
> On Fri, 2020-10-02 at 13:08 +0200, Krzysztof Kozlowski wrote:
> > On Wed, Sep 30, 2020 at 03:06:25PM +0800, Yong Wu wrote:
> > > Convert MediaTek SMI to DT schema.
> > >
> > > Signed-off-by: Yong Wu 
> > > ---
> > >  .../mediatek,smi-common.txt   |  49 -
> > >  .../mediatek,smi-common.yaml  | 100 ++
> > >  .../memory-controllers/mediatek,smi-larb.txt  |  49 -
> > >  .../memory-controllers/mediatek,smi-larb.yaml |  91 
> > >  4 files changed, 191 insertions(+), 98 deletions(-)
> > >  delete mode 100644 
> > > Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.txt
> > >  create mode 100644 
> > > Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml
> > >  delete mode 100644 
> > > Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt
> > >  create mode 100644 
> > > Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml
> ...
> > > +properties:
> > > +  compatible:
> > > +oneOf:
> > > +  - enum:
> > > +  - mediatek,mt2701-smi-common
> > > +  - mediatek,mt2712-smi-common
> > > +  - mediatek,mt6779-smi-common
> > > +  - mediatek,mt8173-smi-common
> > > +  - mediatek,mt8183-smi-common
> > > +
> > > +  - description: for mt7623
> > > +items:
> > > +  - const: mediatek,mt7623-smi-common
> > > +  - const: mediatek,mt2701-smi-common
> > > +
> > > +  reg:
> > > +maxItems: 1
> > > +
> > > +  clocks:
> > > +description: |
> > > +  apb and smi are mandatory. the async is only for generation 1 smi 
> > > HW.
> > > +  gals(global async local sync) also is optional, here is the list 
> > > which
> > > +  require gals: mt6779 and mt8183.
> > > +minItems: 2
> > > +maxItems: 4
> > > +items:
> > > +  - description: apb is Advanced Peripheral Bus clock, It's the 
> > > clock for
> > > +  setting the register.
> > > +  - description: smi is the clock for transfer data and command.
> > > +  - description: async is asynchronous clock, it help transform the 
> > > smi clock
> > > +  into the emi clock domain.
> > > +  - description: gals0 is the path0 clock of gals.
> > > +  - description: gals1 is the path1 clock of gals.
> > > +
> > > +  clock-names:
> > > +oneOf:
> > > +  - items:
> > > +  - const: apb
> > > +  - const: smi
> > > +  - items:
> > > +  - const: apb
> > > +  - const: smi
> > > +  - const: async
> > > +  - items:
> > > +  - const: apb
> > > +  - const: smi
> > > +  - const: gals0
> > > +  - const: gals1
> >
> > Similarly to my comment to other properties, this requirement per
> > compatible should be part of the schema within 'if-then'.
>
> I'm not so familiar with this format. Do this has "if-then-'else
> if'-then-else"?

These are mutually exclusive conditions, so you can skip else:
 - if-then
 - if-then
 - if-then
It will be more readable then stacking 'if' under 'else'

>
> I tried below instead of the clocks segment above:
>
> ===
> if:
>   properties:
> compatible:

Missing contains. Just take an example from some existing schema.

>   enum:
> - mediatek,mt6779-smi-common
> - mediatek,mt8183-smi-common
>
> then:
>   properties:
> clock:
>   items:
> - description: apb is the clock for setting the register..
> - description: smi is the clock for transfer data and command.
> - description: gals0 is the path0 clock of gals(global async
> local sync).
> - description: gals1 is the path1 clock of gals.
> clock-names:
>   items:
> - const: apb
> - const: smi
> - const: gals0
> - const: gals1
> else:
>   if:
> properties:
>   compatible:
> contains:
>   enum:
> - mediatek,mt2701-smi-common
>
>   then:
> properties:
>   clocks:
> items:
>   - description: apb is the clock for setting the register.

Re: [PATCH v3 24/24] memory: mtk-smi: Add mt8192 support

2020-10-02 Thread Krzysztof Kozlowski
On Wed, Sep 30, 2020 at 03:06:47PM +0800, Yong Wu wrote:
> Add mt8192 smi support.
> 
> Signed-off-by: Yong Wu 
> ---
>  drivers/memory/mtk-smi.c | 19 +++
>  1 file changed, 19 insertions(+)

Does it depend on any of the previous patches (so can it be applied
independently)?

Best regards,
Krzysztof
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v3 06/24] dt-bindings: mediatek: Add binding for mt8192 IOMMU

2020-10-02 Thread Krzysztof Kozlowski
On Wed, Sep 30, 2020 at 03:06:29PM +0800, Yong Wu wrote:
> This patch adds decriptions for mt8192 IOMMU and SMI.
> 
> mt8192 also is MTK IOMMU gen2 which uses ARM Short-Descriptor translation
> table format. The M4U-SMI HW diagram is as below:
> 
>   EMI
>|
>   M4U
>|
>   
>SMI Common
>   
>|
>   +---+--+--+--+---+
>   |   |  |  |   .. |   |
>   |   |  |  |  |   |
> larb0   larb1  larb2  larb4 ..  larb19   larb20
> disp0   disp1   mdpvdec   IPE  IPE
> 
> All the connections are HW fixed, SW can NOT adjust it.
> 
> mt8192 M4U support 0~16GB iova range. we preassign different engines
> into different iova ranges:
> 
> domain-id  module iova-range  larbs
>0   disp0 ~ 4G  larb0/1
>1   vcodec  4G ~ 8G larb4/5/7
>2   cam/mdp 8G ~ 12G larb2/9/11/13/14/16/17/18/19/20
>3   CCU00x4000_ ~ 0x43ff_ larb13: port 9/10
>4   CCU10x4400_ ~ 0x47ff_ larb14: port 4/5
> 
> The iova range for CCU0/1(camera control unit) is HW requirement.
> 
> Signed-off-by: Yong Wu 
> Reviewed-by: Rob Herring 
> ---
>  .../bindings/iommu/mediatek,iommu.yaml|   9 +-
>  .../mediatek,smi-common.yaml  |   5 +-
>  .../memory-controllers/mediatek,smi-larb.yaml |   3 +-
>  include/dt-bindings/memory/mt8192-larb-port.h | 239 ++
>  4 files changed, 251 insertions(+), 5 deletions(-)
>  create mode 100644 include/dt-bindings/memory/mt8192-larb-port.h

I see it depends on previous patches but does it have to be within one
commit? Is it not bisectable? The memory changes/bindings could go via
memory tree if this is split.

Best regards,
Krzysztof
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v3 02/24] dt-bindings: memory: mediatek: Convert SMI to DT schema

2020-10-02 Thread Krzysztof Kozlowski
On Wed, Sep 30, 2020 at 03:06:25PM +0800, Yong Wu wrote:
> Convert MediaTek SMI to DT schema.
> 
> Signed-off-by: Yong Wu 
> ---
>  .../mediatek,smi-common.txt   |  49 -
>  .../mediatek,smi-common.yaml  | 100 ++
>  .../memory-controllers/mediatek,smi-larb.txt  |  49 -
>  .../memory-controllers/mediatek,smi-larb.yaml |  91 
>  4 files changed, 191 insertions(+), 98 deletions(-)
>  delete mode 100644 
> Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.txt
>  create mode 100644 
> Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml
>  delete mode 100644 
> Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt
>  create mode 100644 
> Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml
> 
> diff --git 
> a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.txt
>  
> b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.txt
> deleted file mode 100644
> index b64573680b42..
> --- 
> a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.txt
> +++ /dev/null
> @@ -1,49 +0,0 @@
> -SMI (Smart Multimedia Interface) Common
> -
> -The hardware block diagram please check bindings/iommu/mediatek,iommu.txt
> -
> -Mediatek SMI have two generations of HW architecture, here is the list
> -which generation the SoCs use:
> -generation 1: mt2701 and mt7623.
> -generation 2: mt2712, mt6779, mt8173 and mt8183.
> -
> -There's slight differences between the two SMI, for generation 2, the
> -register which control the iommu port is at each larb's register base. But
> -for generation 1, the register is at smi ao base(smi always on register
> -base). Besides that, the smi async clock should be prepared and enabled for
> -SMI generation 1 to transform the smi clock into emi clock domain, but that 
> is
> -not needed for SMI generation 2.
> -
> -Required properties:
> -- compatible : must be one of :
> - "mediatek,mt2701-smi-common"
> - "mediatek,mt2712-smi-common"
> - "mediatek,mt6779-smi-common"
> - "mediatek,mt7623-smi-common", "mediatek,mt2701-smi-common"
> - "mediatek,mt8173-smi-common"
> - "mediatek,mt8183-smi-common"
> -- reg : the register and size of the SMI block.
> -- power-domains : a phandle to the power domain of this local arbiter.
> -- clocks : Must contain an entry for each entry in clock-names.
> -- clock-names : must contain 3 entries for generation 1 smi HW and 2 entries
> -  for generation 2 smi HW as follows:
> -  - "apb" : Advanced Peripheral Bus clock, It's the clock for setting
> - the register.
> -  - "smi" : It's the clock for transfer data and command.
> - They may be the same if both source clocks are the same.
> -  - "async" : asynchronous clock, it help transform the smi clock into the 
> emi
> -   clock domain, this clock is only needed by generation 1 smi HW.
> -  and these 2 option clocks for generation 2 smi HW:
> -  - "gals0": the path0 clock of GALS(Global Async Local Sync).
> -  - "gals1": the path1 clock of GALS(Global Async Local Sync).
> -  Here is the list which has this GALS: mt6779 and mt8183.
> -
> -Example:
> - smi_common: smi@14022000 {
> - compatible = "mediatek,mt8173-smi-common";
> - reg = <0 0x14022000 0 0x1000>;
> - power-domains = < MT8173_POWER_DOMAIN_MM>;
> - clocks = < CLK_MM_SMI_COMMON>,
> -  < CLK_MM_SMI_COMMON>;
> - clock-names = "apb", "smi";
> - };
> diff --git 
> a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml
>  
> b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml
> new file mode 100644
> index ..76ecc7205438
> --- /dev/null
> +++ 
> b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml
> @@ -0,0 +1,100 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: 
> http://devicetree.org/schemas/memory-controllers/mediatek,smi-common.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: SMI (Smart Multimedia Interface) Common
> +
> +maintainers:
> +  - Yong Wu 
> +
> +description: |+
> +  The hardware block diagram please check bindings/iommu/mediatek,iommu.yaml
> +
> +  MediaTek SMI have two generations of HW architecture, here is the list
> +  which generation the SoCs use:
> +  generation 1: mt2701 and mt7623.
> +  generation 2: mt2712, mt6779, mt8173 and mt8183.
> +
> +  There's slight differences between the two SMI, for generation 2, the
> +  register which control the iommu port is at each larb's register base. But
> +  for generation 1, the register is at smi ao base(smi always on register
> +  base). Besides that, the smi async clock should be prepared and enabled for
> +  SMI generation 1 to transform the smi clock into emi clock 

Re: [PATCH v3 01/24] dt-bindings: iommu: mediatek: Convert IOMMU to DT schema

2020-10-02 Thread Krzysztof Kozlowski
On Wed, Sep 30, 2020 at 03:06:24PM +0800, Yong Wu wrote:
> Convert MediaTek IOMMU to DT schema.
> 
> Signed-off-by: Yong Wu 
> ---
>  .../bindings/iommu/mediatek,iommu.txt | 103 
>  .../bindings/iommu/mediatek,iommu.yaml| 154 ++
>  2 files changed, 154 insertions(+), 103 deletions(-)
>  delete mode 100644 Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
>  create mode 100644 
> Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml
> 
> diff --git a/Documentation/devicetree/bindings/iommu/mediatek,iommu.txt 
> b/Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
> deleted file mode 100644
> index c1ccd8582eb2..
> --- a/Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
> +++ /dev/null
> @@ -1,103 +0,0 @@
> -* Mediatek IOMMU Architecture Implementation
> -
> -  Some Mediatek SOCs contain a Multimedia Memory Management Unit (M4U), and
> -this M4U have two generations of HW architecture. Generation one uses flat
> -pagetable, and only supports 4K size page mapping. Generation two uses the
> -ARM Short-Descriptor translation table format for address translation.
> -
> -  About the M4U Hardware Block Diagram, please check below:
> -
> -  EMI (External Memory Interface)
> -   |
> -  m4u (Multimedia Memory Management Unit)
> -   |
> -  ++
> -  ||
> -  gals0-rx   gals1-rx(Global Async Local Sync rx)
> -  ||
> -  ||
> -  gals0-tx   gals1-tx(Global Async Local Sync tx)
> -  ||  Some SoCs may have GALS.
> -  ++
> -   |
> -   SMI Common(Smart Multimedia Interface Common)
> -   |
> -   ++---
> -   ||
> -   | gals-rxThere may be GALS in some larbs.
> -   ||
> -   ||
> -   | gals-tx
> -   ||
> -   SMI larb0SMI larb1   ... SoCs have several SMI local 
> arbiter(larb).
> -   (display) (vdec)
> -   ||
> -   ||
> - +-+-+ +++
> - | | | |||
> - | | |...  |||  ... There are different ports in each larb.
> - | | | |||
> -OVL0 RDMA0 WDMA0  MC   PP   VLD
> -
> -  As above, The Multimedia HW will go through SMI and M4U while it
> -access EMI. SMI is a bridge between m4u and the Multimedia HW. It contain
> -smi local arbiter and smi common. It will control whether the Multimedia
> -HW should go though the m4u for translation or bypass it and talk
> -directly with EMI. And also SMI help control the power domain and clocks for
> -each local arbiter.
> -  Normally we specify a local arbiter(larb) for each multimedia HW
> -like display, video decode, and camera. And there are different ports
> -in each larb. Take a example, There are many ports like MC, PP, VLD in the
> -video decode local arbiter, all these ports are according to the video HW.
> -  In some SoCs, there may be a GALS(Global Async Local Sync) module between
> -smi-common and m4u, and additional GALS module between smi-larb and
> -smi-common. GALS can been seen as a "asynchronous fifo" which could help
> -synchronize for the modules in different clock frequency.
> -
> -Required properties:
> -- compatible : must be one of the following string:
> - "mediatek,mt2701-m4u" for mt2701 which uses generation one m4u HW.
> - "mediatek,mt2712-m4u" for mt2712 which uses generation two m4u HW.
> - "mediatek,mt6779-m4u" for mt6779 which uses generation two m4u HW.
> - "mediatek,mt7623-m4u", "mediatek,mt2701-m4u" for mt7623 which uses
> -  generation one m4u HW.
> - "mediatek,mt8173-m4u" for mt8173 which uses generation two m4u HW.
> - "mediatek,mt8183-m4u" for mt8183 which uses generation two m4u HW.
> -- reg : m4u register base and size.
> -- interrupts : the interrupt of m4u.
> -- clocks : must contain one entry for each clock-names.
> -- clock-names : Only 1 optional clock:
> -  - "bclk": the block clock of m4u.
> -  Here is the list which require this "bclk":
> -  - mt2701, mt2712, mt7623 and mt8173.
> -  Note that m4u use the EMI clock which always has been enabled before kernel
> -  if there is no this "bclk".
> -- mediatek,larbs : List of phandle to the local arbiters in the current Socs.
> - Refer to bindings/memory-controllers/mediatek,smi-larb.txt. It must sort
> - according to the local arbiter index, like larb0, larb1, larb2...
> -- iommu-cells : must be 1. This is the mtk_m4u_id according to the HW.
> - Specifies the mtk_m4u_id as defined in
> - dt-binding/memory/mt2701-larb-port.h for mt2701, mt7623
> - dt-binding/memory/mt2712-larb-port.h for mt2712,
> - dt-binding/memory/mt6779-larb-port.h for mt6779,
> - 

Re: [PATCH v3 02/24] dt-bindings: memory: mediatek: Convert SMI to DT schema

2020-10-02 Thread Krzysztof Kozlowski
On Wed, Sep 30, 2020 at 03:06:25PM +0800, Yong Wu wrote:
> Convert MediaTek SMI to DT schema.
> 
> Signed-off-by: Yong Wu 
> ---
>  .../mediatek,smi-common.txt   |  49 -
>  .../mediatek,smi-common.yaml  | 100 ++
>  .../memory-controllers/mediatek,smi-larb.txt  |  49 -
>  .../memory-controllers/mediatek,smi-larb.yaml |  91 
>  4 files changed, 191 insertions(+), 98 deletions(-)
>  delete mode 100644 
> Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.txt
>  create mode 100644 
> Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml
>  delete mode 100644 
> Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt
>  create mode 100644 
> Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml
> 
> diff --git 
> a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.txt
>  
> b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.txt
> deleted file mode 100644
> index b64573680b42..
> --- 
> a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.txt
> +++ /dev/null
> @@ -1,49 +0,0 @@
> -SMI (Smart Multimedia Interface) Common
> -
> -The hardware block diagram please check bindings/iommu/mediatek,iommu.txt
> -
> -Mediatek SMI have two generations of HW architecture, here is the list
> -which generation the SoCs use:
> -generation 1: mt2701 and mt7623.
> -generation 2: mt2712, mt6779, mt8173 and mt8183.
> -
> -There's slight differences between the two SMI, for generation 2, the
> -register which control the iommu port is at each larb's register base. But
> -for generation 1, the register is at smi ao base(smi always on register
> -base). Besides that, the smi async clock should be prepared and enabled for
> -SMI generation 1 to transform the smi clock into emi clock domain, but that 
> is
> -not needed for SMI generation 2.
> -
> -Required properties:
> -- compatible : must be one of :
> - "mediatek,mt2701-smi-common"
> - "mediatek,mt2712-smi-common"
> - "mediatek,mt6779-smi-common"
> - "mediatek,mt7623-smi-common", "mediatek,mt2701-smi-common"
> - "mediatek,mt8173-smi-common"
> - "mediatek,mt8183-smi-common"
> -- reg : the register and size of the SMI block.
> -- power-domains : a phandle to the power domain of this local arbiter.
> -- clocks : Must contain an entry for each entry in clock-names.
> -- clock-names : must contain 3 entries for generation 1 smi HW and 2 entries
> -  for generation 2 smi HW as follows:
> -  - "apb" : Advanced Peripheral Bus clock, It's the clock for setting
> - the register.
> -  - "smi" : It's the clock for transfer data and command.
> - They may be the same if both source clocks are the same.
> -  - "async" : asynchronous clock, it help transform the smi clock into the 
> emi
> -   clock domain, this clock is only needed by generation 1 smi HW.
> -  and these 2 option clocks for generation 2 smi HW:
> -  - "gals0": the path0 clock of GALS(Global Async Local Sync).
> -  - "gals1": the path1 clock of GALS(Global Async Local Sync).
> -  Here is the list which has this GALS: mt6779 and mt8183.
> -
> -Example:
> - smi_common: smi@14022000 {
> - compatible = "mediatek,mt8173-smi-common";
> - reg = <0 0x14022000 0 0x1000>;
> - power-domains = < MT8173_POWER_DOMAIN_MM>;
> - clocks = < CLK_MM_SMI_COMMON>,
> -  < CLK_MM_SMI_COMMON>;
> - clock-names = "apb", "smi";
> - };
> diff --git 
> a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml
>  
> b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml
> new file mode 100644
> index ..76ecc7205438
> --- /dev/null
> +++ 
> b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml
> @@ -0,0 +1,100 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)

You relicense existing GPLv2 work. Please CC all contributors and
collect their acks/SoB.

> +%YAML 1.2
> +---
> +$id: 
> http://devicetree.org/schemas/memory-controllers/mediatek,smi-common.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: SMI (Smart Multimedia Interface) Common
> +
> +maintainers:
> +  - Yong Wu 
> +
> +description: |+
> +  The hardware block diagram please check bindings/iommu/mediatek,iommu.yaml
> +
> +  MediaTek SMI have two generations of HW architecture, here is the list
> +  which generation the SoCs use:
> +  generation 1: mt2701 and mt7623.
> +  generation 2: mt2712, mt6779, mt8173 and mt8183.
> +
> +  There's slight differences between the two SMI, for generation 2, the
> +  register which control the iommu port is at each larb's register base. But
> +  for generation 1, the register is at smi ao base(smi always on register
> +  base). Besides that, the smi async clock should be 

Re: [PATCH v3 01/24] dt-bindings: iommu: mediatek: Convert IOMMU to DT schema

2020-10-02 Thread Krzysztof Kozlowski
On Wed, Sep 30, 2020 at 03:06:24PM +0800, Yong Wu wrote:
> Convert MediaTek IOMMU to DT schema.
> 
> Signed-off-by: Yong Wu 
> ---
>  .../bindings/iommu/mediatek,iommu.txt | 103 
>  .../bindings/iommu/mediatek,iommu.yaml| 154 ++
>  2 files changed, 154 insertions(+), 103 deletions(-)
>  delete mode 100644 Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
>  create mode 100644 
> Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml
> 
> diff --git a/Documentation/devicetree/bindings/iommu/mediatek,iommu.txt 
> b/Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
> deleted file mode 100644
> index c1ccd8582eb2..
> --- a/Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
> +++ /dev/null
> @@ -1,103 +0,0 @@
> -* Mediatek IOMMU Architecture Implementation
> -
> -  Some Mediatek SOCs contain a Multimedia Memory Management Unit (M4U), and
> -this M4U have two generations of HW architecture. Generation one uses flat
> -pagetable, and only supports 4K size page mapping. Generation two uses the
> -ARM Short-Descriptor translation table format for address translation.
> -
> -  About the M4U Hardware Block Diagram, please check below:
> -
> -  EMI (External Memory Interface)
> -   |
> -  m4u (Multimedia Memory Management Unit)
> -   |
> -  ++
> -  ||
> -  gals0-rx   gals1-rx(Global Async Local Sync rx)
> -  ||
> -  ||
> -  gals0-tx   gals1-tx(Global Async Local Sync tx)
> -  ||  Some SoCs may have GALS.
> -  ++
> -   |
> -   SMI Common(Smart Multimedia Interface Common)
> -   |
> -   ++---
> -   ||
> -   | gals-rxThere may be GALS in some larbs.
> -   ||
> -   ||
> -   | gals-tx
> -   ||
> -   SMI larb0SMI larb1   ... SoCs have several SMI local 
> arbiter(larb).
> -   (display) (vdec)
> -   ||
> -   ||
> - +-+-+ +++
> - | | | |||
> - | | |...  |||  ... There are different ports in each larb.
> - | | | |||
> -OVL0 RDMA0 WDMA0  MC   PP   VLD
> -
> -  As above, The Multimedia HW will go through SMI and M4U while it
> -access EMI. SMI is a bridge between m4u and the Multimedia HW. It contain
> -smi local arbiter and smi common. It will control whether the Multimedia
> -HW should go though the m4u for translation or bypass it and talk
> -directly with EMI. And also SMI help control the power domain and clocks for
> -each local arbiter.
> -  Normally we specify a local arbiter(larb) for each multimedia HW
> -like display, video decode, and camera. And there are different ports
> -in each larb. Take a example, There are many ports like MC, PP, VLD in the
> -video decode local arbiter, all these ports are according to the video HW.
> -  In some SoCs, there may be a GALS(Global Async Local Sync) module between
> -smi-common and m4u, and additional GALS module between smi-larb and
> -smi-common. GALS can been seen as a "asynchronous fifo" which could help
> -synchronize for the modules in different clock frequency.
> -
> -Required properties:
> -- compatible : must be one of the following string:
> - "mediatek,mt2701-m4u" for mt2701 which uses generation one m4u HW.
> - "mediatek,mt2712-m4u" for mt2712 which uses generation two m4u HW.
> - "mediatek,mt6779-m4u" for mt6779 which uses generation two m4u HW.
> - "mediatek,mt7623-m4u", "mediatek,mt2701-m4u" for mt7623 which uses
> -  generation one m4u HW.
> - "mediatek,mt8173-m4u" for mt8173 which uses generation two m4u HW.
> - "mediatek,mt8183-m4u" for mt8183 which uses generation two m4u HW.
> -- reg : m4u register base and size.
> -- interrupts : the interrupt of m4u.
> -- clocks : must contain one entry for each clock-names.
> -- clock-names : Only 1 optional clock:
> -  - "bclk": the block clock of m4u.
> -  Here is the list which require this "bclk":
> -  - mt2701, mt2712, mt7623 and mt8173.
> -  Note that m4u use the EMI clock which always has been enabled before kernel
> -  if there is no this "bclk".
> -- mediatek,larbs : List of phandle to the local arbiters in the current Socs.
> - Refer to bindings/memory-controllers/mediatek,smi-larb.txt. It must sort
> - according to the local arbiter index, like larb0, larb1, larb2...
> -- iommu-cells : must be 1. This is the mtk_m4u_id according to the HW.
> - Specifies the mtk_m4u_id as defined in
> - dt-binding/memory/mt2701-larb-port.h for mt2701, mt7623
> - dt-binding/memory/mt2712-larb-port.h for mt2712,
> - dt-binding/memory/mt6779-larb-port.h for mt6779,
> - 

Re: [PATCH v3 1/3] memory: tegra: Add devm_tegra_get_memory_controller()

2020-09-30 Thread Krzysztof Kozlowski
On Wed, 30 Sep 2020 at 16:41, Dmitry Osipenko  wrote:
>
> ...
> > +struct tegra_mc *devm_tegra_get_memory_controller(struct device *dev)
> > +{
> > + struct platform_device *pdev;
> > + struct device_node *np;
> > + struct tegra_mc *mc;
> > + int err;
> > +
> > + np = of_find_matching_node_and_match(NULL, tegra_mc_of_match, NULL);
> > + if (!np)
> > + return ERR_PTR(-ENOENT);
> > +
> > + pdev = of_find_device_by_node(np);
> > + of_node_put(np);
> > + if (!pdev)
> > + return ERR_PTR(-ENODEV);
> > +
> > + mc = platform_get_drvdata(pdev);
> > + if (!mc) {
> > + put_device(mc->dev);
>
> This should be put_device(>dev). Please always be careful while
> copying someones else code :)

Good catch. I guess devm_add_action_or_reset() would also work... or
running Smatch on new code. Smatch should point it out.

Best regards,
Krzysztof
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v3 1/3] memory: tegra: Add devm_tegra_get_memory_controller()

2020-09-30 Thread Krzysztof Kozlowski
On Wed, Sep 30, 2020 at 02:41:45AM -0700, Nicolin Chen wrote:
> On Wed, Sep 30, 2020 at 11:07:32AM +0200, Krzysztof Kozlowski wrote:
> > "On Wed, 30 Sep 2020 at 10:48, Nicolin Chen  wrote:
> > >
> > > From: Dmitry Osipenko 
> > >
> > > Multiple Tegra drivers need to retrieve Memory Controller and hence there
> > > is quite some duplication of the retrieval code among the drivers. Let's
> > > add a new common helper for the retrieval of the MC.
> > >
> > > Signed-off-by: Dmitry Osipenko 
> > > Signed-off-by: Nicolin Chen 
> > > ---
> > >
> > > Changelog
> > > v2->v3:
> > >  * Replaced with Dimtry's devm_tegra_get_memory_controller()
> > > v1->v2:
> > >  * N/A
> > >
> > >  drivers/memory/tegra/mc.c | 39 +++
> > >  include/soc/tegra/mc.h| 17 +
> > >  2 files changed, 56 insertions(+)
> > >
> > > diff --git a/drivers/memory/tegra/mc.c b/drivers/memory/tegra/mc.c
> > > index ec8403557ed4..dd691dc3738e 100644
> > > --- a/drivers/memory/tegra/mc.c
> > > +++ b/drivers/memory/tegra/mc.c
> > > @@ -42,6 +42,45 @@ static const struct of_device_id tegra_mc_of_match[] = 
> > > {
> > >  };
> > >  MODULE_DEVICE_TABLE(of, tegra_mc_of_match);
> > >
> > > +static void tegra_mc_devm_action_put_device(void *data)
> > 
> > devm_tegra_memory_controller_put()

My bad here, this is not a "put" helper so the previous name was
actually good. No need to change.

> > 
> > > +{
> > > +   struct tegra_mc *mc = data;
> > > +
> > > +   put_device(mc->dev);
> > > +}
> > > +
> > > +struct tegra_mc *devm_tegra_get_memory_controller(struct device *dev)
> > 
> > Usually 'get' is a suffix (e.g. clk, gpiod, iio, led), so:
> > devm_tegra_memory_controller_get()
> > 
> > > +{
> > > +   struct platform_device *pdev;
> > > +   struct device_node *np;
> > > +   struct tegra_mc *mc;
> > > +   int err;
> > > +
> > > +   np = of_find_matching_node_and_match(NULL, tegra_mc_of_match, 
> > > NULL);
> > > +   if (!np)
> > > +   return ERR_PTR(-ENOENT);
> > > +
> > > +   pdev = of_find_device_by_node(np);
> > > +   of_node_put(np);
> > > +   if (!pdev)
> > > +   return ERR_PTR(-ENODEV);
> > > +
> > > +   mc = platform_get_drvdata(pdev);
> > > +   if (!mc) {
> > > +   put_device(mc->dev);
> > > +   return ERR_PTR(-EPROBE_DEFER);
> > > +   }
> > > +
> > > +   err = devm_add_action(dev, tegra_mc_devm_action_put_device, mc);

This can be simpler with devm_add_action_or_reset.

Best regards,
Krzysztof
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v3 2/3] iommu/tegra-smmu: Rework .probe_device and .attach_dev

2020-09-30 Thread Krzysztof Kozlowski
On Wed, Sep 30, 2020 at 02:40:32AM -0700, Nicolin Chen wrote:
> On Wed, Sep 30, 2020 at 11:21:14AM +0200, Krzysztof Kozlowski wrote:
> > On Wed, 30 Sep 2020 at 10:48, Nicolin Chen  wrote:
> > >
> > > Previously the driver relies on bus_set_iommu() in .probe() to call
> > > in .probe_device() function so each client can poll iommus property
> > > in DTB to configure fwspec via tegra_smmu_configure(). According to
> > > the comments in .probe(), this is a bit of a hack. And this doesn't
> > > work for a client that doesn't exist in DTB, PCI device for example.
> > >
> > > Actually when a device/client gets probed, the of_iommu_configure()
> > > will call in .probe_device() function again, with a prepared fwspec
> > > from of_iommu_configure() that reads the SWGROUP id in DTB as we do
> > > in tegra-smmu driver.
> > >
> > > Additionally, as a new helper devm_tegra_get_memory_controller() is
> > > introduced, there's no need to poll the iommus property in order to
> > > get mc->smmu pointers or SWGROUP id.
> > >
> > > This patch reworks .probe_device() and .attach_dev() by doing:
> > > 1) Using fwspec to get swgroup id in .attach_dev/.dettach_dev()
> > > 2) Removing DT polling code, tegra_smmu_find/tegra_smmu_configure()
> > > 3) Calling devm_tegra_get_memory_controller() in .probe_device()
> > > 4) Also dropping the hack in .probe() that's no longer needed.
> > >
> > > Signed-off-by: Nicolin Chen 
> > > ---
> > >
> > > Changelog
> > > v2->v3
> > >  * Used devm_tegra_get_memory_controller() to get mc pointer
> > >  * Replaced IS_ERR_OR_NULL with IS_ERR in .probe_device()
> > > v1->v2
> > >  * Replaced in .probe_device() tegra_smmu_find/tegra_smmu_configure()
> > >with tegra_get_memory_controller call.
> > >  * Dropped the hack in tegra_smmu_probe().
> > >
> > >  drivers/iommu/tegra-smmu.c | 144 ++---
> > >  1 file changed, 36 insertions(+), 108 deletions(-)
> > >
> > > diff --git a/drivers/iommu/tegra-smmu.c b/drivers/iommu/tegra-smmu.c
> > > index 6a3ecc334481..636dc3b89545 100644
> > > --- a/drivers/iommu/tegra-smmu.c
> > > +++ b/drivers/iommu/tegra-smmu.c
> > > @@ -61,6 +61,8 @@ struct tegra_smmu_as {
> > > u32 attr;
> > >  };
> > >
> > > +static const struct iommu_ops tegra_smmu_ops;
> > 
> > I cannot find in this patch where this is assigned.
> 
> Because it's already set in probe():
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/iommu/tegra-smmu.c#n1162
> 
> And my PATCH-3 sets it for PCI bus also.

OK, good point. Thanks for explanation.

Best regards,
Krzysztof
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v3 2/3] iommu/tegra-smmu: Rework .probe_device and .attach_dev

2020-09-30 Thread Krzysztof Kozlowski
On Wed, 30 Sep 2020 at 10:48, Nicolin Chen  wrote:
>
> Previously the driver relies on bus_set_iommu() in .probe() to call
> in .probe_device() function so each client can poll iommus property
> in DTB to configure fwspec via tegra_smmu_configure(). According to
> the comments in .probe(), this is a bit of a hack. And this doesn't
> work for a client that doesn't exist in DTB, PCI device for example.
>
> Actually when a device/client gets probed, the of_iommu_configure()
> will call in .probe_device() function again, with a prepared fwspec
> from of_iommu_configure() that reads the SWGROUP id in DTB as we do
> in tegra-smmu driver.
>
> Additionally, as a new helper devm_tegra_get_memory_controller() is
> introduced, there's no need to poll the iommus property in order to
> get mc->smmu pointers or SWGROUP id.
>
> This patch reworks .probe_device() and .attach_dev() by doing:
> 1) Using fwspec to get swgroup id in .attach_dev/.dettach_dev()
> 2) Removing DT polling code, tegra_smmu_find/tegra_smmu_configure()
> 3) Calling devm_tegra_get_memory_controller() in .probe_device()
> 4) Also dropping the hack in .probe() that's no longer needed.
>
> Signed-off-by: Nicolin Chen 
> ---
>
> Changelog
> v2->v3
>  * Used devm_tegra_get_memory_controller() to get mc pointer
>  * Replaced IS_ERR_OR_NULL with IS_ERR in .probe_device()
> v1->v2
>  * Replaced in .probe_device() tegra_smmu_find/tegra_smmu_configure()
>with tegra_get_memory_controller call.
>  * Dropped the hack in tegra_smmu_probe().
>
>  drivers/iommu/tegra-smmu.c | 144 ++---
>  1 file changed, 36 insertions(+), 108 deletions(-)
>
> diff --git a/drivers/iommu/tegra-smmu.c b/drivers/iommu/tegra-smmu.c
> index 6a3ecc334481..636dc3b89545 100644
> --- a/drivers/iommu/tegra-smmu.c
> +++ b/drivers/iommu/tegra-smmu.c
> @@ -61,6 +61,8 @@ struct tegra_smmu_as {
> u32 attr;
>  };
>
> +static const struct iommu_ops tegra_smmu_ops;

I cannot find in this patch where this is assigned.

Best regards,
Krzysztof
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v3 1/3] memory: tegra: Add devm_tegra_get_memory_controller()

2020-09-30 Thread Krzysztof Kozlowski
"On Wed, 30 Sep 2020 at 10:48, Nicolin Chen  wrote:
>
> From: Dmitry Osipenko 
>
> Multiple Tegra drivers need to retrieve Memory Controller and hence there
> is quite some duplication of the retrieval code among the drivers. Let's
> add a new common helper for the retrieval of the MC.
>
> Signed-off-by: Dmitry Osipenko 
> Signed-off-by: Nicolin Chen 
> ---
>
> Changelog
> v2->v3:
>  * Replaced with Dimtry's devm_tegra_get_memory_controller()
> v1->v2:
>  * N/A
>
>  drivers/memory/tegra/mc.c | 39 +++
>  include/soc/tegra/mc.h| 17 +
>  2 files changed, 56 insertions(+)
>
> diff --git a/drivers/memory/tegra/mc.c b/drivers/memory/tegra/mc.c
> index ec8403557ed4..dd691dc3738e 100644
> --- a/drivers/memory/tegra/mc.c
> +++ b/drivers/memory/tegra/mc.c
> @@ -42,6 +42,45 @@ static const struct of_device_id tegra_mc_of_match[] = {
>  };
>  MODULE_DEVICE_TABLE(of, tegra_mc_of_match);
>
> +static void tegra_mc_devm_action_put_device(void *data)

devm_tegra_memory_controller_put()

> +{
> +   struct tegra_mc *mc = data;
> +
> +   put_device(mc->dev);
> +}
> +
> +struct tegra_mc *devm_tegra_get_memory_controller(struct device *dev)

Usually 'get' is a suffix (e.g. clk, gpiod, iio, led), so:
devm_tegra_memory_controller_get()

> +{
> +   struct platform_device *pdev;
> +   struct device_node *np;
> +   struct tegra_mc *mc;
> +   int err;
> +
> +   np = of_find_matching_node_and_match(NULL, tegra_mc_of_match, NULL);
> +   if (!np)
> +   return ERR_PTR(-ENOENT);
> +
> +   pdev = of_find_device_by_node(np);
> +   of_node_put(np);
> +   if (!pdev)
> +   return ERR_PTR(-ENODEV);
> +
> +   mc = platform_get_drvdata(pdev);
> +   if (!mc) {
> +   put_device(mc->dev);
> +   return ERR_PTR(-EPROBE_DEFER);
> +   }
> +
> +   err = devm_add_action(dev, tegra_mc_devm_action_put_device, mc);
> +   if (err) {
> +   put_device(mc->dev);
> +   return ERR_PTR(err);
> +   }
> +
> +   return mc;
> +}
> +EXPORT_SYMBOL_GPL(devm_tegra_get_memory_controller);
> +
>  static int tegra_mc_block_dma_common(struct tegra_mc *mc,
>  const struct tegra_mc_reset *rst)
>  {
> diff --git a/include/soc/tegra/mc.h b/include/soc/tegra/mc.h
> index 1238e35653d1..c05142e3e244 100644
> --- a/include/soc/tegra/mc.h
> +++ b/include/soc/tegra/mc.h
> @@ -184,4 +184,21 @@ struct tegra_mc {
>  int tegra_mc_write_emem_configuration(struct tegra_mc *mc, unsigned long 
> rate);
>  unsigned int tegra_mc_get_emem_device_count(struct tegra_mc *mc);
>
> +#ifdef CONFIG_TEGRA_MC
> +/**
> + * devm_tegra_get_memory_controller() - Get the tegra_mc pointer.
> + * @dev: Device that will be interacted with

This is not precise enough and there is no interaction with 'dev' in
devm_tegra_get_memory_controller(). Something like: "Device that owns
the pointer to tegra memory controller"

> + *
> + * Return: ERR_PTR() on error or a valid pointer to a struct tegra_mc.
> + *
> + * The mc->dev counter will be automatically put by the device management 
> code.

1. s/mc/tegra_mc/ (it's the first occurence of word mc here)
2. "kerneldoc goes to the C file". Not to the header.

Best regards,
Krzysztof
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v2 1/3] memory: tegra: Add helper function tegra_get_memory_controller

2020-09-30 Thread Krzysztof Kozlowski
On Wed, 30 Sep 2020 at 09:31, Nicolin Chen  wrote:
>
> Hi Krzysztof,
>
> On Wed, Sep 30, 2020 at 09:21:39AM +0200, Krzysztof Kozlowski wrote:
> > On Wed, 30 Sep 2020 at 02:35, Nicolin Chen  wrote:
> > >
> > > This can be used by both tegra-smmu and tegra20-devfreq drivers.
> > >
> > > Suggested-by: Dmitry Osipenko 
> > > Signed-off-by: Nicolin Chen 
> > > ---
> > >
> > > Changelog
> > > v1->v2
> > >  * N/A
> > >
> > >  drivers/memory/tegra/mc.c | 23 +++
> > >  include/soc/tegra/mc.h|  1 +
> > >  2 files changed, 24 insertions(+)
> > >
> > > diff --git a/drivers/memory/tegra/mc.c b/drivers/memory/tegra/mc.c
> > > index ec8403557ed4..09352ad66dcc 100644
> > > --- a/drivers/memory/tegra/mc.c
> > > +++ b/drivers/memory/tegra/mc.c
> > > @@ -42,6 +42,29 @@ static const struct of_device_id tegra_mc_of_match[] = 
> > > {
> > >  };
> > >  MODULE_DEVICE_TABLE(of, tegra_mc_of_match);
> >
> > > +struct tegra_mc *tegra_get_memory_controller(void)
> > > +{
> >
> > Add kerneldoc and mention dropping of reference to the device after use.
>
> I am abort to use Dmitry's devm_ one in my next version:
> https://github.com/grate-driver/linux/commit/2105e7664063772d72fefe9696bdab0b688b9de2
>
> Could I just skip the kerneldoc part? Otherwise, would you please
> tell me which kerneldoc file I should update?

His version is almost the same as yours so it does not matter - you
declare an exported function, so you need to document it. kerneldoc
goes to the C file.
https://elixir.bootlin.com/linux/latest/source/Documentation/doc-guide/kernel-doc.rst

Best regards,
Krzysztof
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v2 1/3] memory: tegra: Add helper function tegra_get_memory_controller

2020-09-30 Thread Krzysztof Kozlowski
On Wed, 30 Sep 2020 at 02:35, Nicolin Chen  wrote:
>
> This can be used by both tegra-smmu and tegra20-devfreq drivers.
>
> Suggested-by: Dmitry Osipenko 
> Signed-off-by: Nicolin Chen 
> ---
>
> Changelog
> v1->v2
>  * N/A
>
>  drivers/memory/tegra/mc.c | 23 +++
>  include/soc/tegra/mc.h|  1 +
>  2 files changed, 24 insertions(+)
>
> diff --git a/drivers/memory/tegra/mc.c b/drivers/memory/tegra/mc.c
> index ec8403557ed4..09352ad66dcc 100644
> --- a/drivers/memory/tegra/mc.c
> +++ b/drivers/memory/tegra/mc.c
> @@ -42,6 +42,29 @@ static const struct of_device_id tegra_mc_of_match[] = {
>  };
>  MODULE_DEVICE_TABLE(of, tegra_mc_of_match);

> +struct tegra_mc *tegra_get_memory_controller(void)
> +{

Add kerneldoc and mention dropping of reference to the device after use.

Best regards,
Krzysztof

> +   struct platform_device *pdev;
> +   struct device_node *np;
> +   struct tegra_mc *mc;
> +
> +   np = of_find_matching_node_and_match(NULL, tegra_mc_of_match, NULL);
> +   if (!np)
> +   return ERR_PTR(-ENOENT);
> +
> +   pdev = of_find_device_by_node(np);
> +   of_node_put(np);
> +   if (!pdev)
> +   return ERR_PTR(-ENODEV);
> +
> +   mc = platform_get_drvdata(pdev);
> +   if (!mc)
> +   return ERR_PTR(-EPROBE_DEFER);
> +
> +   return mc;
> +}
> +EXPORT_SYMBOL_GPL(tegra_get_memory_controller);
> +
>  static int tegra_mc_block_dma_common(struct tegra_mc *mc,
>  const struct tegra_mc_reset *rst)
>  {
> diff --git a/include/soc/tegra/mc.h b/include/soc/tegra/mc.h
> index 1238e35653d1..c72718fd589f 100644
> --- a/include/soc/tegra/mc.h
> +++ b/include/soc/tegra/mc.h
> @@ -183,5 +183,6 @@ struct tegra_mc {
>
>  int tegra_mc_write_emem_configuration(struct tegra_mc *mc, unsigned long 
> rate);
>  unsigned int tegra_mc_get_emem_device_count(struct tegra_mc *mc);
> +struct tegra_mc *tegra_get_memory_controller(void);
>
>  #endif /* __SOC_TEGRA_MC_H__ */
> --
> 2.17.1
>
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


[RESEND PATCH 5/5] iommu: qcom: Drop of_match_ptr to fix -Wunused-const-variable

2020-08-19 Thread Krzysztof Kozlowski
The of_device_id is included unconditionally by of.h header and used
in the driver as well.  Remove of_match_ptr to fix W=1 compile test
warning with !CONFIG_OF:

drivers/iommu/qcom_iommu.c:910:34: warning: 'qcom_iommu_of_match' defined 
but not used [-Wunused-const-variable=]
  910 | static const struct of_device_id qcom_iommu_of_match[] = {

Signed-off-by: Krzysztof Kozlowski 
---
 drivers/iommu/arm/arm-smmu/qcom_iommu.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/iommu/arm/arm-smmu/qcom_iommu.c 
b/drivers/iommu/arm/arm-smmu/qcom_iommu.c
index af6bec3ace00..9535a6af7553 100644
--- a/drivers/iommu/arm/arm-smmu/qcom_iommu.c
+++ b/drivers/iommu/arm/arm-smmu/qcom_iommu.c
@@ -752,7 +752,7 @@ static const struct of_device_id ctx_of_match[] = {
 static struct platform_driver qcom_iommu_ctx_driver = {
.driver = {
.name   = "qcom-iommu-ctx",
-   .of_match_table = of_match_ptr(ctx_of_match),
+   .of_match_table = ctx_of_match,
},
.probe  = qcom_iommu_ctx_probe,
.remove = qcom_iommu_ctx_remove,
@@ -915,7 +915,7 @@ static const struct of_device_id qcom_iommu_of_match[] = {
 static struct platform_driver qcom_iommu_driver = {
.driver = {
.name   = "qcom-iommu",
-   .of_match_table = of_match_ptr(qcom_iommu_of_match),
+   .of_match_table = qcom_iommu_of_match,
.pm = _iommu_pm_ops,
},
.probe  = qcom_iommu_device_probe,
-- 
2.17.1

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


[RESEND PATCH 4/5] iommu: intel: Drop kerneldoc marker from regular comment

2020-08-19 Thread Krzysztof Kozlowski
Fix W=1 compile warnings (invalid kerneldoc):

drivers/iommu/intel/dmar.c:389: warning: Function parameter or member 
'header' not described in 'dmar_parse_one_drhd'

Signed-off-by: Krzysztof Kozlowski 
---
 drivers/iommu/intel/dmar.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iommu/intel/dmar.c b/drivers/iommu/intel/dmar.c
index 93e6345f3414..ba47edf03941 100644
--- a/drivers/iommu/intel/dmar.c
+++ b/drivers/iommu/intel/dmar.c
@@ -380,7 +380,7 @@ dmar_find_dmaru(struct acpi_dmar_hardware_unit *drhd)
return NULL;
 }
 
-/**
+/*
  * dmar_parse_one_drhd - parses exactly one DMA remapping hardware definition
  * structure which uniquely represent one DMA remapping hardware unit
  * present in the platform
-- 
2.17.1

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


[RESEND PATCH 1/5] iommu: mtk: Drop of_match_ptr to fix -Wunused-const-variable

2020-08-19 Thread Krzysztof Kozlowski
The of_device_id is included unconditionally by of.h header and used
in the driver as well.  Remove of_match_ptr to fix W=1 compile test
warning with !CONFIG_OF:

drivers/iommu/mtk_iommu.c:833:34: warning: 'mtk_iommu_of_ids' defined but 
not used [-Wunused-const-variable=]
  833 | static const struct of_device_id mtk_iommu_of_ids[] = {

Reported-by: kernel test robot 
Signed-off-by: Krzysztof Kozlowski 
---
 drivers/iommu/mtk_iommu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 785b228d39a6..b99c2b4b48ca 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -843,7 +843,7 @@ static struct platform_driver mtk_iommu_driver = {
.remove = mtk_iommu_remove,
.driver = {
.name = "mtk-iommu",
-   .of_match_table = of_match_ptr(mtk_iommu_of_ids),
+   .of_match_table = mtk_iommu_of_ids,
.pm = _iommu_pm_ops,
}
 };
-- 
2.17.1

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


[RESEND PATCH 2/5] iommu: amd: Add missing function prototypes to fix -Wmissing-prototypes

2020-08-19 Thread Krzysztof Kozlowski
Few exported functions from AMD IOMMU driver are missing prototypes.
They have declaration in arch/x86/events/amd/iommu.h but this file
cannot be included in the driver.  Add prototypes to fix W=1 warnings
like:

drivers/iommu/amd/init.c:3066:19: warning:
no previous prototype for 'get_amd_iommu' [-Wmissing-prototypes]
 3066 | struct amd_iommu *get_amd_iommu(unsigned int idx)

Signed-off-by: Krzysztof Kozlowski 
---
 drivers/iommu/amd/amd_iommu.h | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/iommu/amd/amd_iommu.h b/drivers/iommu/amd/amd_iommu.h
index 57309716fd18..0781b7112467 100644
--- a/drivers/iommu/amd/amd_iommu.h
+++ b/drivers/iommu/amd/amd_iommu.h
@@ -41,6 +41,15 @@ extern int amd_iommu_guest_ir;
 struct iommu_domain;
 
 extern bool amd_iommu_v2_supported(void);
+extern struct amd_iommu *get_amd_iommu(unsigned int idx);
+extern u8 amd_iommu_pc_get_max_banks(unsigned int idx);
+extern bool amd_iommu_pc_supported(void);
+extern u8 amd_iommu_pc_get_max_counters(unsigned int idx);
+extern int amd_iommu_pc_get_reg(struct amd_iommu *iommu, u8 bank, u8 cntr,
+   u8 fxn, u64 *value);
+extern int amd_iommu_pc_set_reg(struct amd_iommu *iommu, u8 bank, u8 cntr,
+   u8 fxn, u64 *value);
+
 extern int amd_iommu_register_ppr_notifier(struct notifier_block *nb);
 extern int amd_iommu_unregister_ppr_notifier(struct notifier_block *nb);
 extern void amd_iommu_domain_direct_map(struct iommu_domain *dom);
-- 
2.17.1

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


[RESEND PATCH 3/5] iommu: amd: Fix kerneldoc

2020-08-19 Thread Krzysztof Kozlowski
Fix W=1 compile warnings (invalid kerneldoc):

drivers/iommu/amd/init.c:1586: warning: Function parameter or member 'ivrs' 
not described in 'get_highest_supported_ivhd_type'
drivers/iommu/amd/init.c:1938: warning: Function parameter or member 
'iommu' not described in 'iommu_update_intcapxt'

Signed-off-by: Krzysztof Kozlowski 
---
 drivers/iommu/amd/init.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/iommu/amd/init.c b/drivers/iommu/amd/init.c
index c652f16eb702..908d8e89764c 100644
--- a/drivers/iommu/amd/init.c
+++ b/drivers/iommu/amd/init.c
@@ -1578,7 +1578,7 @@ static int __init init_iommu_one(struct amd_iommu *iommu, 
struct ivhd_header *h)
 
 /**
  * get_highest_supported_ivhd_type - Look up the appropriate IVHD type
- * @ivrs  Pointer to the IVRS header
+ * @ivrs: Pointer to the IVRS header
  *
  * This function search through all IVDB of the maximum supported IVHD
  */
@@ -1929,7 +1929,7 @@ static int iommu_setup_msi(struct amd_iommu *iommu)
 #define XT_INT_VEC(x)  (((x) & 0xFFULL) << 32)
 #define XT_INT_DEST_HI(x)  x) >> 24) & 0xFFULL) << 56)
 
-/**
+/*
  * Setup the IntCapXT registers with interrupt routing information
  * based on the PCI MSI capability block registers, accessed via
  * MMIO MSI address low/hi and MSI data registers.
-- 
2.17.1

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


[PATCH 2/3] iommu: intel: Drop kerneldoc marker from regular comment

2020-07-28 Thread Krzysztof Kozlowski
Fix W=1 compile warnings (invalid kerneldoc):

drivers/iommu/intel/dmar.c:389: warning: Function parameter or member 
'header' not described in 'dmar_parse_one_drhd'

Signed-off-by: Krzysztof Kozlowski 
---
 drivers/iommu/intel/dmar.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iommu/intel/dmar.c b/drivers/iommu/intel/dmar.c
index 93e6345f3414..ba47edf03941 100644
--- a/drivers/iommu/intel/dmar.c
+++ b/drivers/iommu/intel/dmar.c
@@ -380,7 +380,7 @@ dmar_find_dmaru(struct acpi_dmar_hardware_unit *drhd)
return NULL;
 }
 
-/**
+/*
  * dmar_parse_one_drhd - parses exactly one DMA remapping hardware definition
  * structure which uniquely represent one DMA remapping hardware unit
  * present in the platform
-- 
2.17.1

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


[PATCH 3/3] iommu: qcom: Drop of_match_ptr to fix -Wunused-const-variable

2020-07-28 Thread Krzysztof Kozlowski
The of_device_id is included unconditionally by of.h header and used
in the driver as well.  Remove of_match_ptr to fix W=1 compile test
warning with !CONFIG_OF:

drivers/iommu/qcom_iommu.c:910:34: warning: 'qcom_iommu_of_match' defined 
but not used [-Wunused-const-variable=]
  910 | static const struct of_device_id qcom_iommu_of_match[] = {

Signed-off-by: Krzysztof Kozlowski 
---
 drivers/iommu/qcom_iommu.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/iommu/qcom_iommu.c b/drivers/iommu/qcom_iommu.c
index af6bec3ace00..9535a6af7553 100644
--- a/drivers/iommu/qcom_iommu.c
+++ b/drivers/iommu/qcom_iommu.c
@@ -752,7 +752,7 @@ static const struct of_device_id ctx_of_match[] = {
 static struct platform_driver qcom_iommu_ctx_driver = {
.driver = {
.name   = "qcom-iommu-ctx",
-   .of_match_table = of_match_ptr(ctx_of_match),
+   .of_match_table = ctx_of_match,
},
.probe  = qcom_iommu_ctx_probe,
.remove = qcom_iommu_ctx_remove,
@@ -915,7 +915,7 @@ static const struct of_device_id qcom_iommu_of_match[] = {
 static struct platform_driver qcom_iommu_driver = {
.driver = {
.name   = "qcom-iommu",
-   .of_match_table = of_match_ptr(qcom_iommu_of_match),
+   .of_match_table = qcom_iommu_of_match,
.pm = _iommu_pm_ops,
},
.probe  = qcom_iommu_device_probe,
-- 
2.17.1

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


[PATCH 1/3] iommu: amd: Fix kerneldoc

2020-07-28 Thread Krzysztof Kozlowski
Fix W=1 compile warnings (invalid kerneldoc):

drivers/iommu/amd/init.c:1586: warning: Function parameter or member 'ivrs' 
not described in 'get_highest_supported_ivhd_type'
drivers/iommu/amd/init.c:1938: warning: Function parameter or member 
'iommu' not described in 'iommu_update_intcapxt'

Signed-off-by: Krzysztof Kozlowski 
---
 drivers/iommu/amd/init.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/iommu/amd/init.c b/drivers/iommu/amd/init.c
index 958050c213f9..4a37169b1b1b 100644
--- a/drivers/iommu/amd/init.c
+++ b/drivers/iommu/amd/init.c
@@ -1578,7 +1578,7 @@ static int __init init_iommu_one(struct amd_iommu *iommu, 
struct ivhd_header *h)
 
 /**
  * get_highest_supported_ivhd_type - Look up the appropriate IVHD type
- * @ivrs  Pointer to the IVRS header
+ * @ivrs: Pointer to the IVRS header
  *
  * This function search through all IVDB of the maximum supported IVHD
  */
@@ -1929,7 +1929,7 @@ static int iommu_setup_msi(struct amd_iommu *iommu)
 #define XT_INT_VEC(x)  (((x) & 0xFFULL) << 32)
 #define XT_INT_DEST_HI(x)  x) >> 24) & 0xFFULL) << 56)
 
-/**
+/*
  * Setup the IntCapXT registers with interrupt routing information
  * based on the PCI MSI capability block registers, accessed via
  * MMIO MSI address low/hi and MSI data registers.
-- 
2.17.1

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


[PATCH] iommu: amd: Add missing function prototypes to fix -Wmissing-prototypes

2020-07-27 Thread Krzysztof Kozlowski
Few exported functions from AMD IOMMU driver are missing prototypes.
They have declaration in arch/x86/events/amd/iommu.h but this file
cannot be included in the driver.  Add prototypes to fix W=1 warnings
like:

drivers/iommu/amd/init.c:3066:19: warning:
no previous prototype for 'get_amd_iommu' [-Wmissing-prototypes]
 3066 | struct amd_iommu *get_amd_iommu(unsigned int idx)

Signed-off-by: Krzysztof Kozlowski 
---
 drivers/iommu/amd/amd_iommu.h | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/iommu/amd/amd_iommu.h b/drivers/iommu/amd/amd_iommu.h
index 57309716fd18..0781b7112467 100644
--- a/drivers/iommu/amd/amd_iommu.h
+++ b/drivers/iommu/amd/amd_iommu.h
@@ -41,6 +41,15 @@ extern int amd_iommu_guest_ir;
 struct iommu_domain;
 
 extern bool amd_iommu_v2_supported(void);
+extern struct amd_iommu *get_amd_iommu(unsigned int idx);
+extern u8 amd_iommu_pc_get_max_banks(unsigned int idx);
+extern bool amd_iommu_pc_supported(void);
+extern u8 amd_iommu_pc_get_max_counters(unsigned int idx);
+extern int amd_iommu_pc_get_reg(struct amd_iommu *iommu, u8 bank, u8 cntr,
+   u8 fxn, u64 *value);
+extern int amd_iommu_pc_set_reg(struct amd_iommu *iommu, u8 bank, u8 cntr,
+   u8 fxn, u64 *value);
+
 extern int amd_iommu_register_ppr_notifier(struct notifier_block *nb);
 extern int amd_iommu_unregister_ppr_notifier(struct notifier_block *nb);
 extern void amd_iommu_domain_direct_map(struct iommu_domain *dom);
-- 
2.17.1

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


[PATCH] iommu: mtk: Drop of_match_ptr to fix -Wunused-const-variable

2020-07-27 Thread Krzysztof Kozlowski
The of_device_id is included unconditionally by of.h header and used
in the driver as well.  Remove of_match_ptr to fix W=1 compile test
warning with !CONFIG_OF:

drivers/iommu/mtk_iommu.c:833:34: warning: 'mtk_iommu_of_ids' defined but 
not used [-Wunused-const-variable=]
  833 | static const struct of_device_id mtk_iommu_of_ids[] = {

Reported-by: kernel test robot 
Signed-off-by: Krzysztof Kozlowski 
---
 drivers/iommu/mtk_iommu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 59e5a62a34db..cdfd9f8be190 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -843,7 +843,7 @@ static struct platform_driver mtk_iommu_driver = {
.remove = mtk_iommu_remove,
.driver = {
.name = "mtk-iommu",
-   .of_match_table = of_match_ptr(mtk_iommu_of_ids),
+   .of_match_table = mtk_iommu_of_ids,
.pm = _iommu_pm_ops,
}
 };
-- 
2.17.1

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


[PATCH 2/2] x86: Hide the archdata.iommu field behind generic IOMMU_API

2020-05-18 Thread Krzysztof Kozlowski
There is a generic, kernel wide configuration symbol for enabling the
IOMMU specific bits: CONFIG_IOMMU_API.  Implementations (including
INTEL_IOMMU and AMD_IOMMU driver) select it so use it here as well.

This makes the conditional archdata.iommu field consistent with other
platforms and also fixes any compile test builds of other IOMMU drivers,
when INTEL_IOMMU or AMD_IOMMU are not selected).

For the case when INTEL_IOMMU/AMD_IOMMU and COMPILE_TEST are not
selected, this should create functionally equivalent code/choice.  With
COMPILE_TEST this field could appear if other IOMMU drivers are chosen
but neither INTEL_IOMMU nor AMD_IOMMU are not.

Reported-by: kbuild test robot 
Signed-off-by: Krzysztof Kozlowski 
---
 arch/x86/include/asm/device.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/device.h b/arch/x86/include/asm/device.h
index 7e31f7f1bb06..49bd6cf3eec9 100644
--- a/arch/x86/include/asm/device.h
+++ b/arch/x86/include/asm/device.h
@@ -3,7 +3,7 @@
 #define _ASM_X86_DEVICE_H
 
 struct dev_archdata {
-#if defined(CONFIG_INTEL_IOMMU) || defined(CONFIG_AMD_IOMMU)
+#ifdef CONFIG_IOMMU_API
void *iommu; /* hook for IOMMU specific extension */
 #endif
 };
-- 
2.17.1

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


[PATCH 1/2] ia64: Hide the archdata.iommu field behind generic IOMMU_API

2020-05-18 Thread Krzysztof Kozlowski
There is a generic, kernel wide configuration symbol for enabling the
IOMMU specific bits: CONFIG_IOMMU_API.  Implementations (including
INTEL_IOMMU driver) select it so use it here as well.

This makes the conditional archdata.iommu field consistent with other
platforms and also fixes any compile test builds of other IOMMU drivers,
when INTEL_IOMMU is not selected).

For the case when INTEL_IOMMU and COMPILE_TEST are not selected, this
should create functionally equivalent code/choice.  With COMPILE_TEST
this field could appear if other IOMMU drivers are chosen but
INTEL_IOMMU not.

Reported-by: kbuild test robot 
Signed-off-by: Krzysztof Kozlowski 

---

See:
https://lore.kernel.org/lkml/202005181412.frc4jufy%25...@intel.com/
---
 arch/ia64/include/asm/device.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/ia64/include/asm/device.h b/arch/ia64/include/asm/device.h
index 410a769ece95..3eb397415381 100644
--- a/arch/ia64/include/asm/device.h
+++ b/arch/ia64/include/asm/device.h
@@ -6,7 +6,7 @@
 #define _ASM_IA64_DEVICE_H
 
 struct dev_archdata {
-#ifdef CONFIG_INTEL_IOMMU
+#ifdef CONFIG_IOMMU_API
void *iommu; /* hook for IOMMU specific extension */
 #endif
 };
-- 
2.17.1

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


[PATCH] iommu: spapr_tce: Disable compile testing to fix build on book3s_32 config

2020-04-14 Thread Krzysztof Kozlowski
Although SPAPR_TCE_IOMMU itself can be compile tested on certain PowerPC
configurations, its presence makes arch/powerpc/kvm/Makefile to select
modules which do not build in such configuration.

The arch/powerpc/kvm/ modules use kvm_arch.spapr_tce_tables which exists
only with CONFIG_PPC_BOOK3S_64.  However these modules are selected when
COMPILE_TEST and SPAPR_TCE_IOMMU are chosen leading to build failures:

In file included from arch/powerpc/include/asm/book3s/64/mmu-hash.h:20:0,
 from arch/powerpc/kvm/book3s_64_vio_hv.c:22:
arch/powerpc/include/asm/book3s/64/pgtable.h:17:0: error: "_PAGE_EXEC" 
redefined [-Werror]
 #define _PAGE_EXEC  0x1 /* execute permission */

In file included from arch/powerpc/include/asm/book3s/32/pgtable.h:8:0,
 from arch/powerpc/include/asm/book3s/pgtable.h:8,
 from arch/powerpc/include/asm/pgtable.h:18,
 from include/linux/mm.h:95,
 from arch/powerpc/include/asm/io.h:29,
 from include/linux/io.h:13,
 from include/linux/irq.h:20,
 from arch/powerpc/include/asm/hardirq.h:6,
 from include/linux/hardirq.h:9,
 from include/linux/kvm_host.h:7,
 from arch/powerpc/kvm/book3s_64_vio_hv.c:12:
arch/powerpc/include/asm/book3s/32/hash.h:29:0: note: this is the location 
of the previous definition
 #define _PAGE_EXEC 0x200 /* software: exec allowed */

Reported-by: Geert Uytterhoeven 
Fixes: e93a1695d7fb ("iommu: Enable compile testing for some of drivers")
Signed-off-by: Krzysztof Kozlowski 
---
 drivers/iommu/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index 58b4a4dbfc78..3532b1ead19d 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -362,7 +362,7 @@ config IPMMU_VMSA
 
 config SPAPR_TCE_IOMMU
bool "sPAPR TCE IOMMU Support"
-   depends on PPC_POWERNV || PPC_PSERIES || (PPC && COMPILE_TEST)
+   depends on PPC_POWERNV || PPC_PSERIES
select IOMMU_API
help
  Enables bits of IOMMU API required by VFIO. The iommu_ops
-- 
2.17.1

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [iommu:arm/omap 4/4] drivers/gpu/drm/rockchip/rockchip_drm_gem.c:134:20: error: implicit declaration of function 'vmap'; did you mean 'bmap'?

2020-03-05 Thread Krzysztof Kozlowski
On Thu, 5 Mar 2020 at 02:00, kbuild test robot  wrote:
>
> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git 
> arm/omap
> head:   e93a1695d7fb551376b1c1220a267d032b6ad159
> commit: e93a1695d7fb551376b1c1220a267d032b6ad159 [4/4] iommu: Enable compile 
> testing for some of drivers
> config: sparc-allyesconfig (attached as .config)
> compiler: sparc64-linux-gcc (GCC) 7.5.0
> reproduce:
> wget 
> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
> ~/bin/make.cross
> chmod +x ~/bin/make.cross
> git checkout e93a1695d7fb551376b1c1220a267d032b6ad159
> # save the attached .config to linux build tree
> GCC_VERSION=7.5.0 make.cross ARCH=sparc
>
> If you fix the issue, kindly add following tag
> Reported-by: kbuild test robot 
>
> All errors (new ones prefixed by >>):
>
>drivers/gpu/drm/rockchip/rockchip_drm_gem.c: In function 
> 'rockchip_gem_alloc_iommu':
> >> drivers/gpu/drm/rockchip/rockchip_drm_gem.c:134:20: error: implicit 
> >> declaration of function 'vmap'; did you mean 'bmap'? 
> >> [-Werror=implicit-function-declaration]
>   rk_obj->kvaddr = vmap(rk_obj->pages, rk_obj->num_pages, VM_MAP,
>^~~~
>bmap
> >> drivers/gpu/drm/rockchip/rockchip_drm_gem.c:134:59: error: 'VM_MAP' 
> >> undeclared (first use in this function); did you mean 'VM_MPX'?
>   rk_obj->kvaddr = vmap(rk_obj->pages, rk_obj->num_pages, VM_MAP,
>   ^~
>   VM_MPX
>drivers/gpu/drm/rockchip/rockchip_drm_gem.c:134:59: note: each undeclared 
> identifier is reported only once for each function it appears in
>drivers/gpu/drm/rockchip/rockchip_drm_gem.c: In function 
> 'rockchip_gem_free_iommu':
> >> drivers/gpu/drm/rockchip/rockchip_drm_gem.c:190:2: error: implicit 
> >> declaration of function 'vunmap'; did you mean 'iounmap'? 
> >> [-Werror=implicit-function-declaration]
>  vunmap(rk_obj->kvaddr);
>  ^~
>  iounmap
>drivers/gpu/drm/rockchip/rockchip_drm_gem.c: In function 
> 'rockchip_gem_prime_vmap':
>drivers/gpu/drm/rockchip/rockchip_drm_gem.c:547:49: error: 'VM_MAP' 
> undeclared (first use in this function); did you mean 'VM_MPX'?
>   return vmap(rk_obj->pages, rk_obj->num_pages, VM_MAP,
> ^~
> VM_MPX
>cc1: some warnings being treated as errors
>
> vim +134 drivers/gpu/drm/rockchip/rockchip_drm_gem.c

Hi,

+Cc Heiko,

This is already fixed in drm-misc here:
https://patchwork.freedesktop.org/patch/347106/

Best regards,
Krzysztof
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


[RESEND PATCH 2/4] iommu/omap: Fix printing format for size_t on 64-bit

2020-03-03 Thread Krzysztof Kozlowski
Print size_t as %zu or %zx to fix -Wformat warnings when compiling on
64-bit platform (e.g. with COMPILE_TEST):

drivers/iommu/omap-iommu.c: In function ‘flush_iotlb_page’:
drivers/iommu/omap-iommu.c:437:47: warning:
format ‘%x’ expects argument of type ‘unsigned int’,
but argument 7 has type ‘size_t {aka long unsigned int}’ [-Wformat=]

Acked-by: Suman Anna 
Signed-off-by: Krzysztof Kozlowski 

---

Not tested on hardware.
---
 drivers/iommu/omap-iommu.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index 50e8acf88ec4..887fefcb03b4 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -434,7 +434,7 @@ static void flush_iotlb_page(struct omap_iommu *obj, u32 da)
bytes = iopgsz_to_bytes(cr.cam & 3);
 
if ((start <= da) && (da < start + bytes)) {
-   dev_dbg(obj->dev, "%s: %08x<=%08x(%x)\n",
+   dev_dbg(obj->dev, "%s: %08x<=%08x(%zx)\n",
__func__, start, da, bytes);
iotlb_load_cr(obj, );
iommu_write_reg(obj, 1, MMU_FLUSH_ENTRY);
@@ -1352,11 +1352,11 @@ static int omap_iommu_map(struct iommu_domain *domain, 
unsigned long da,
 
omap_pgsz = bytes_to_iopgsz(bytes);
if (omap_pgsz < 0) {
-   dev_err(dev, "invalid size to map: %d\n", bytes);
+   dev_err(dev, "invalid size to map: %zu\n", bytes);
return -EINVAL;
}
 
-   dev_dbg(dev, "mapping da 0x%lx to pa %pa size 0x%x\n", da, , bytes);
+   dev_dbg(dev, "mapping da 0x%lx to pa %pa size 0x%zx\n", da, , bytes);
 
iotlb_init_entry(, da, pa, omap_pgsz);
 
@@ -1393,7 +1393,7 @@ static size_t omap_iommu_unmap(struct iommu_domain 
*domain, unsigned long da,
size_t bytes = 0;
int i;
 
-   dev_dbg(dev, "unmapping da 0x%lx size %u\n", da, size);
+   dev_dbg(dev, "unmapping da 0x%lx size %zu\n", da, size);
 
iommu = omap_domain->iommus;
for (i = 0; i < omap_domain->num_iommus; i++, iommu++) {
-- 
2.17.1

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

[RESEND PATCH 1/4] iommu/omap: Fix pointer cast -Wpointer-to-int-cast warnings on 64 bit

2020-03-03 Thread Krzysztof Kozlowski
pointers should be casted to unsigned long to avoid
-Wpointer-to-int-cast warnings when compiling on 64-bit platform (e.g.
with COMPILE_TEST):

drivers/iommu/omap-iommu.c: In function ‘omap2_iommu_enable’:
drivers/iommu/omap-iommu.c:170:25: warning:
cast from pointer to integer of different size [-Wpointer-to-int-cast]
  if (!obj->iopgd || !IS_ALIGNED((u32)obj->iopgd,  SZ_16K))
 ^

Signed-off-by: Krzysztof Kozlowski 

---

Not tested on hardware.
---
 drivers/iommu/omap-iommu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index be551cc34be4..50e8acf88ec4 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -167,7 +167,7 @@ static int omap2_iommu_enable(struct omap_iommu *obj)
 {
u32 l, pa;
 
-   if (!obj->iopgd || !IS_ALIGNED((u32)obj->iopgd,  SZ_16K))
+   if (!obj->iopgd || !IS_ALIGNED((unsigned long)obj->iopgd,  SZ_16K))
return -EINVAL;
 
pa = virt_to_phys(obj->iopgd);
-- 
2.17.1

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

[RESEND PATCH 4/4] iommu: Enable compile testing for some of drivers

2020-03-03 Thread Krzysztof Kozlowski
Some of the IOMMU drivers can be compile tested to increase build
coverage.  The OMAP, Rockchip and Exynos drivers use
device.dev_archdata.iommu field which does not exist on all platforms.
The sPAPR TCE and ARM SMMU have also restrictions where they can be
built.

Signed-off-by: Krzysztof Kozlowski 
---
 drivers/iommu/Kconfig | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index c5df570ef84a..9eb9e16eb620 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -273,7 +273,7 @@ config IRQ_REMAP
 # OMAP IOMMU support
 config OMAP_IOMMU
bool "OMAP IOMMU Support"
-   depends on ARM && MMU
+   depends on ARM && MMU || (COMPILE_TEST && (ARM || ARM64 || IA64 || 
SPARC))
depends on ARCH_OMAP2PLUS || COMPILE_TEST
select IOMMU_API
---help---
@@ -291,7 +291,7 @@ config OMAP_IOMMU_DEBUG
 
 config ROCKCHIP_IOMMU
bool "Rockchip IOMMU Support"
-   depends on ARM || ARM64
+   depends on ARM || ARM64 || (COMPILE_TEST && (ARM64 || IA64 || SPARC))
depends on ARCH_ROCKCHIP || COMPILE_TEST
select IOMMU_API
select ARM_DMA_USE_IOMMU
@@ -325,7 +325,7 @@ config TEGRA_IOMMU_SMMU
 
 config EXYNOS_IOMMU
bool "Exynos IOMMU Support"
-   depends on ARCH_EXYNOS && MMU
+   depends on ARCH_EXYNOS && MMU || (COMPILE_TEST && (ARM || ARM64 || IA64 
|| SPARC))
depends on !CPU_BIG_ENDIAN # revisit driver if we can enable big-endian 
ptes
select IOMMU_API
select ARM_DMA_USE_IOMMU
@@ -361,7 +361,7 @@ config IPMMU_VMSA
 
 config SPAPR_TCE_IOMMU
bool "sPAPR TCE IOMMU Support"
-   depends on PPC_POWERNV || PPC_PSERIES
+   depends on PPC_POWERNV || PPC_PSERIES || (PPC && COMPILE_TEST)
select IOMMU_API
help
  Enables bits of IOMMU API required by VFIO. The iommu_ops
@@ -370,7 +370,7 @@ config SPAPR_TCE_IOMMU
 # ARM IOMMU support
 config ARM_SMMU
tristate "ARM Ltd. System MMU (SMMU) Support"
-   depends on (ARM64 || ARM) && MMU
+   depends on (ARM64 || ARM || (COMPILE_TEST && !GENERIC_ATOMIC64)) && MMU
select IOMMU_API
select IOMMU_IO_PGTABLE_LPAE
select ARM_DMA_USE_IOMMU if ARM
@@ -440,7 +440,7 @@ config S390_IOMMU
 
 config S390_CCW_IOMMU
bool "S390 CCW IOMMU Support"
-   depends on S390 && CCW
+   depends on S390 && CCW || COMPILE_TEST
select IOMMU_API
help
  Enables bits of IOMMU API required by VFIO. The iommu_ops
@@ -448,7 +448,7 @@ config S390_CCW_IOMMU
 
 config S390_AP_IOMMU
bool "S390 AP IOMMU Support"
-   depends on S390 && ZCRYPT
+   depends on S390 && ZCRYPT || COMPILE_TEST
select IOMMU_API
help
  Enables bits of IOMMU API required by VFIO. The iommu_ops
@@ -456,7 +456,7 @@ config S390_AP_IOMMU
 
 config MTK_IOMMU
bool "MTK IOMMU Support"
-   depends on ARM || ARM64
+   depends on ARM || ARM64 || COMPILE_TEST
depends on ARCH_MEDIATEK || COMPILE_TEST
select ARM_DMA_USE_IOMMU
select IOMMU_API
-- 
2.17.1

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


[RESEND PATCH 3/4] iommu/omap: Fix -Woverflow warnings when compiling on 64-bit architectures

2020-03-03 Thread Krzysztof Kozlowski
Although the OMAP IOMMU driver supports only ARMv7 (32-bit) platforms,
it can be compile tested for other architectures, including 64-bit ones.
In such case the warning appears:

   In file included from drivers/iommu/omap-iommu.c:33:0:
   drivers/iommu/omap-iommu.c: In function 'omap_iommu_iova_to_phys':
>> drivers/iommu/omap-iopgtable.h:44:21: warning: large integer implicitly 
truncated to unsigned type [-Woverflow]
#define IOPTE_MASK  (~(IOPTE_SIZE - 1))
^
>> drivers/iommu/omap-iommu.c:1641:41: note: in expansion of macro 
'IOPTE_MASK'
   ret = omap_iommu_translate(*pte, da, IOPTE_MASK);
^~

Fix this by using architecture-depending types in omap_iommu_translate():
1. Pointer should be cast to unsigned long,
2. Virtual addresses should be cast to dma_addr_t.

On 32-bit this will be the same as original code (using u32).  On 64-bit
it should produce meaningful result, although it does not really matter.

Reported-by: kbuild test robot 
Signed-off-by: Krzysztof Kozlowski 

---

Not tested on hardware.
---
 drivers/iommu/omap-iopgtable.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/iommu/omap-iopgtable.h b/drivers/iommu/omap-iopgtable.h
index 1a4adb59a859..51d74002cc30 100644
--- a/drivers/iommu/omap-iopgtable.h
+++ b/drivers/iommu/omap-iopgtable.h
@@ -63,7 +63,8 @@
  *
  * va to pa translation
  */
-static inline phys_addr_t omap_iommu_translate(u32 d, u32 va, u32 mask)
+static inline phys_addr_t omap_iommu_translate(unsigned long d, dma_addr_t va,
+  dma_addr_t mask)
 {
return (d & mask) | (va & (~mask));
 }
-- 
2.17.1

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH 3/3] iommu: Enable compile testing for some of drivers

2020-01-03 Thread Krzysztof Kozlowski
On Thu, Jan 02, 2020 at 04:40:16PM -0600, Suman Anna wrote:
> Hi Krzysztof,
> 
> On 12/31/19 2:07 AM, Krzysztof Kozlowski wrote:
> > On Tue, Dec 31, 2019 at 03:43:39PM +0800, kbuild test robot wrote:
> >> Hi Krzysztof,
> >>
> >> I love your patch! Perhaps something to improve:
> >>
> >> [auto build test WARNING on iommu/next]
> >> [also build test WARNING on v5.5-rc4]
> >> [if your patch is applied to the wrong git tree, please drop us a note to 
> >> help
> >> improve the system. BTW, we also suggest to use '--base' option to specify 
> >> the
> >> base tree in git format-patch, please see 
> >> https://stackoverflow.com/a/37406982]
> >>
> >> url:
> >> https://github.com/0day-ci/linux/commits/Krzysztof-Kozlowski/iommu-omap-Fix-pointer-cast-Wpointer-to-int-cast-warnings-on-64-bit/20191231-022212
> >> base:   https://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git next
> >> config: ia64-allmodconfig (attached as .config)
> >> compiler: ia64-linux-gcc (GCC) 7.5.0
> >> reproduce:
> >> wget 
> >> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross 
> >> -O ~/bin/make.cross
> >> chmod +x ~/bin/make.cross
> >> # save the attached .config to linux build tree
> >> GCC_VERSION=7.5.0 make.cross ARCH=ia64 
> >>
> >> If you fix the issue, kindly add following tag
> >> Reported-by: kbuild test robot 
> > 
> > I saw it already while compile testing my patch. I must admit that I
> > could not find easy/fast fix for it.  Probably the
> > omap_iommu_translate() helper should be made 64-bit friendly but this
> > obfuscates the code. 
> 
> >The driver and hardware supports only 32-bit addresses.
> 
> Yeah, is there a reason why you are trying to enable the build for the
> OMAP IOMMU driver on 64-bit platforms or other architectures - the IP
> and driver is only ever used on ARMv7 platforms, and it should already
> be available for COMPILE_TEST on those.

It's the same reason we enable compile testing on all other drivers
which will never be used outside original platforms. There are many
of such examples because we want to increase the build coverage to as
many different configurations as possible. There could be also another
benefit - easier code reusability - although it is purely theoretical in
this case, I think.

Best regards,
Krzysztof
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


[RFT] iommu: omap: Fix -Woverflow warnings when compiling on 64-bit architectures

2019-12-31 Thread Krzysztof Kozlowski
Although the OMAP IOMMU driver supports only ARMv7 (32-bit) platforms,
it can be compile tested for other architectures, including 64-bit ones.
In such case the warning appears:

   In file included from drivers/iommu/omap-iommu.c:33:0:
   drivers/iommu/omap-iommu.c: In function 'omap_iommu_iova_to_phys':
>> drivers/iommu/omap-iopgtable.h:44:21: warning: large integer implicitly 
truncated to unsigned type [-Woverflow]
#define IOPTE_MASK  (~(IOPTE_SIZE - 1))
^
>> drivers/iommu/omap-iommu.c:1641:41: note: in expansion of macro 
'IOPTE_MASK'
   ret = omap_iommu_translate(*pte, da, IOPTE_MASK);
^~

Fix this by using architecture-depending types in omap_iommu_translate():
1. Pointer should be cast to unsigned long,
2. Virtual addresses should be cast to dma_addr_t.

On 32-bit this will be the same as original code (using u32).  On 64-bit
it should produce meaningful result, although it does not really matter.

Reported-by: kbuild test robot 
Signed-off-by: Krzysztof Kozlowski 

---

Not tested on hardware.
---
 drivers/iommu/omap-iopgtable.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/iommu/omap-iopgtable.h b/drivers/iommu/omap-iopgtable.h
index 1a4adb59a859..51d74002cc30 100644
--- a/drivers/iommu/omap-iopgtable.h
+++ b/drivers/iommu/omap-iopgtable.h
@@ -63,7 +63,8 @@
  *
  * va to pa translation
  */
-static inline phys_addr_t omap_iommu_translate(u32 d, u32 va, u32 mask)
+static inline phys_addr_t omap_iommu_translate(unsigned long d, dma_addr_t va,
+  dma_addr_t mask)
 {
return (d & mask) | (va & (~mask));
 }
-- 
2.7.4

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH 3/3] iommu: Enable compile testing for some of drivers

2019-12-31 Thread Krzysztof Kozlowski
On Tue, Dec 31, 2019 at 09:08:38AM +0800, kbuild test robot wrote:
> Hi Krzysztof,
> 
> I love your patch! Yet something to improve:
> 
> [auto build test ERROR on iommu/next]
> [also build test ERROR on v5.5-rc4 next-20191219]
> [if your patch is applied to the wrong git tree, please drop us a note to help
> improve the system. BTW, we also suggest to use '--base' option to specify the
> base tree in git format-patch, please see 
> https://stackoverflow.com/a/37406982]
> 
> url:
> https://github.com/0day-ci/linux/commits/Krzysztof-Kozlowski/iommu-omap-Fix-pointer-cast-Wpointer-to-int-cast-warnings-on-64-bit/20191231-022212
> base:   https://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git next
> config: sparc64-allmodconfig (attached as .config)
> compiler: sparc64-linux-gcc (GCC) 7.5.0
> reproduce:
> wget 
> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
> ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # save the attached .config to linux build tree
> GCC_VERSION=7.5.0 make.cross ARCH=sparc64 
> 
> If you fix the issue, kindly add following tag
> Reported-by: kbuild test robot 

Thanks, kbuild!

I sent a fix:
https://lore.kernel.org/linux-arm-kernel/159956-7612-1-git-send-email-k...@kernel.org/

Best regards,
Krzysztof

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


[PATCH] drm/rockchip: Add missing vmalloc header

2019-12-31 Thread Krzysztof Kozlowski
The Rockship DRM GEM code uses vmap()/vunmap() so vmalloc header must be
included to avoid warnings like (on IA64, compile tested):

drivers/gpu/drm/rockchip/rockchip_drm_gem.c: In function 
‘rockchip_gem_alloc_iommu’:
drivers/gpu/drm/rockchip/rockchip_drm_gem.c:134:20: error:
implicit declaration of function ‘vmap’ 
[-Werror=implicit-function-declaration]

Reported-by: kbuild test robot 
Signed-off-by: Krzysztof Kozlowski 
---
 drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
index 7582d0e6a60a..0d1884684dcb 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
@@ -6,6 +6,7 @@
 
 #include 
 #include 
+#include 
 
 #include 
 #include 
-- 
2.7.4

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH 3/3] iommu: Enable compile testing for some of drivers

2019-12-31 Thread Krzysztof Kozlowski
On Tue, Dec 31, 2019 at 03:43:39PM +0800, kbuild test robot wrote:
> Hi Krzysztof,
> 
> I love your patch! Perhaps something to improve:
> 
> [auto build test WARNING on iommu/next]
> [also build test WARNING on v5.5-rc4]
> [if your patch is applied to the wrong git tree, please drop us a note to help
> improve the system. BTW, we also suggest to use '--base' option to specify the
> base tree in git format-patch, please see 
> https://stackoverflow.com/a/37406982]
> 
> url:
> https://github.com/0day-ci/linux/commits/Krzysztof-Kozlowski/iommu-omap-Fix-pointer-cast-Wpointer-to-int-cast-warnings-on-64-bit/20191231-022212
> base:   https://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git next
> config: ia64-allmodconfig (attached as .config)
> compiler: ia64-linux-gcc (GCC) 7.5.0
> reproduce:
> wget 
> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
> ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # save the attached .config to linux build tree
> GCC_VERSION=7.5.0 make.cross ARCH=ia64 
> 
> If you fix the issue, kindly add following tag
> Reported-by: kbuild test robot 

I saw it already while compile testing my patch. I must admit that I
could not find easy/fast fix for it.  Probably the
omap_iommu_translate() helper should be made 64-bit friendly but this
obfuscates the code. The driver and hardware supports only 32-bit addresses.

Best regards,
Krzysztof


> 
> All warnings (new ones prefixed by >>):
> 
>In file included from drivers/iommu/omap-iommu.c:33:0:
>drivers/iommu/omap-iommu.c: In function 'omap_iommu_iova_to_phys':
> >> drivers/iommu/omap-iopgtable.h:44:21: warning: large integer implicitly 
> >> truncated to unsigned type [-Woverflow]
> #define IOPTE_MASK  (~(IOPTE_SIZE - 1))
> ^
> >> drivers/iommu/omap-iommu.c:1641:41: note: in expansion of macro 
> >> 'IOPTE_MASK'
>ret = omap_iommu_translate(*pte, da, IOPTE_MASK);
> ^~
>drivers/iommu/omap-iopgtable.h:51:23: warning: large integer implicitly 
> truncated to unsigned type [-Woverflow]
> #define IOLARGE_MASK  (~(IOLARGE_SIZE - 1))
>   ^
> >> drivers/iommu/omap-iommu.c:1643:41: note: in expansion of macro 
> >> 'IOLARGE_MASK'
>ret = omap_iommu_translate(*pte, da, IOLARGE_MASK);
> ^~~~
>drivers/iommu/omap-iopgtable.h:27:25: warning: large integer implicitly 
> truncated to unsigned type [-Woverflow]
> #define IOSECTION_MASK  (~(IOSECTION_SIZE - 1))
> ^
> >> drivers/iommu/omap-iommu.c:1649:41: note: in expansion of macro 
> >> 'IOSECTION_MASK'
>ret = omap_iommu_translate(*pgd, da, IOSECTION_MASK);
> ^~
>drivers/iommu/omap-iopgtable.h:34:23: warning: large integer implicitly 
> truncated to unsigned type [-Woverflow]
> #define IOSUPER_MASK  (~(IOSUPER_SIZE - 1))
>   ^
> >> drivers/iommu/omap-iommu.c:1651:41: note: in expansion of macro 
> >> 'IOSUPER_MASK'
>ret = omap_iommu_translate(*pgd, da, IOSUPER_MASK);
> ^~~~
> 
> vim +44 drivers/iommu/omap-iopgtable.h
> 
> 97ec7d585b33bb arch/arm/plat-omap/iopgtable.h Hiroshi DOYU 2010-02-15  38  
> 97ec7d585b33bb arch/arm/plat-omap/iopgtable.h Hiroshi DOYU 2010-02-15  39  /*
> 97ec7d585b33bb arch/arm/plat-omap/iopgtable.h Hiroshi DOYU 2010-02-15  40   * 
> "small page" address mask and size definitions.
> 97ec7d585b33bb arch/arm/plat-omap/iopgtable.h Hiroshi DOYU 2010-02-15  41   */
> a9dcad5e375800 arch/arm/plat-omap/iopgtable.h Hiroshi DOYU 2009-01-26  42  
> #define IOPTE_SHIFT12
> 5ff98fa68c88d7 drivers/iommu/omap-iopgtable.h Suman Anna   2015-07-20  43  
> #define IOPTE_SIZE BIT(IOPTE_SHIFT)
> a9dcad5e375800 arch/arm/plat-omap/iopgtable.h Hiroshi DOYU 2009-01-26 @44  
> #define IOPTE_MASK (~(IOPTE_SIZE - 1))
> a9dcad5e375800 arch/arm/plat-omap/iopgtable.h Hiroshi DOYU 2009-01-26  45  
> 
> :: The code at line 44 was first introduced by commit
> :: a9dcad5e375800fcb07f7617dba23b3aade8f09d omap iommu: tlb and pagetable 
> primitives
> 
> :: TO: Hiroshi DOYU 
> :: CC: Hiroshi DOYU 
> 
> ---
> 0-DAY kernel test infrastructure Open Source Technology Center
> https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org Intel Corporation


___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


[PATCH 1/3] iommu: omap: Fix pointer cast -Wpointer-to-int-cast warnings on 64 bit

2019-12-30 Thread Krzysztof Kozlowski
pointers should be casted to unsigned long to avoid
-Wpointer-to-int-cast warnings when compiling on 64-bit platform (e.g.
with COMPILE_TEST):

drivers/iommu/omap-iommu.c: In function ‘omap2_iommu_enable’:
drivers/iommu/omap-iommu.c:170:25: warning:
cast from pointer to integer of different size [-Wpointer-to-int-cast]
  if (!obj->iopgd || !IS_ALIGNED((u32)obj->iopgd,  SZ_16K))
 ^

Signed-off-by: Krzysztof Kozlowski 
---
 drivers/iommu/omap-iommu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index be551cc34be4..50e8acf88ec4 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -167,7 +167,7 @@ static int omap2_iommu_enable(struct omap_iommu *obj)
 {
u32 l, pa;
 
-   if (!obj->iopgd || !IS_ALIGNED((u32)obj->iopgd,  SZ_16K))
+   if (!obj->iopgd || !IS_ALIGNED((unsigned long)obj->iopgd,  SZ_16K))
return -EINVAL;
 
pa = virt_to_phys(obj->iopgd);
-- 
2.17.1

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

[PATCH 2/3] iommu: omap: Fix printing format for size_t on 64-bit

2019-12-30 Thread Krzysztof Kozlowski
Print size_t as %zu or %zx to fix -Wformat warnings when compiling on
64-bit platform (e.g. with COMPILE_TEST):

drivers/iommu/omap-iommu.c: In function ‘flush_iotlb_page’:
drivers/iommu/omap-iommu.c:437:47: warning:
format ‘%x’ expects argument of type ‘unsigned int’,
but argument 7 has type ‘size_t {aka long unsigned int}’ [-Wformat=]

Signed-off-by: Krzysztof Kozlowski 
---
 drivers/iommu/omap-iommu.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index 50e8acf88ec4..887fefcb03b4 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -434,7 +434,7 @@ static void flush_iotlb_page(struct omap_iommu *obj, u32 da)
bytes = iopgsz_to_bytes(cr.cam & 3);
 
if ((start <= da) && (da < start + bytes)) {
-   dev_dbg(obj->dev, "%s: %08x<=%08x(%x)\n",
+   dev_dbg(obj->dev, "%s: %08x<=%08x(%zx)\n",
__func__, start, da, bytes);
iotlb_load_cr(obj, );
iommu_write_reg(obj, 1, MMU_FLUSH_ENTRY);
@@ -1352,11 +1352,11 @@ static int omap_iommu_map(struct iommu_domain *domain, 
unsigned long da,
 
omap_pgsz = bytes_to_iopgsz(bytes);
if (omap_pgsz < 0) {
-   dev_err(dev, "invalid size to map: %d\n", bytes);
+   dev_err(dev, "invalid size to map: %zu\n", bytes);
return -EINVAL;
}
 
-   dev_dbg(dev, "mapping da 0x%lx to pa %pa size 0x%x\n", da, , bytes);
+   dev_dbg(dev, "mapping da 0x%lx to pa %pa size 0x%zx\n", da, , bytes);
 
iotlb_init_entry(, da, pa, omap_pgsz);
 
@@ -1393,7 +1393,7 @@ static size_t omap_iommu_unmap(struct iommu_domain 
*domain, unsigned long da,
size_t bytes = 0;
int i;
 
-   dev_dbg(dev, "unmapping da 0x%lx size %u\n", da, size);
+   dev_dbg(dev, "unmapping da 0x%lx size %zu\n", da, size);
 
iommu = omap_domain->iommus;
for (i = 0; i < omap_domain->num_iommus; i++, iommu++) {
-- 
2.17.1

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

[PATCH 3/3] iommu: Enable compile testing for some of drivers

2019-12-30 Thread Krzysztof Kozlowski
Some of the IOMMU drivers can be compile tested to increase build
coverage.  The OMAP, Rockchip and Exynos drivers use
device.dev_archdata.iommu field which does not exist on all platforms.
The sPAPR TCE and ARM SMMU have also restrictions where they can be
built.

Signed-off-by: Krzysztof Kozlowski 
---
 drivers/iommu/Kconfig | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index 0b9d78a0f3ac..fa27192ad166 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -260,7 +260,7 @@ config IRQ_REMAP
 # OMAP IOMMU support
 config OMAP_IOMMU
bool "OMAP IOMMU Support"
-   depends on ARM && MMU
+   depends on ARM && MMU || (COMPILE_TEST && (ARM || ARM64 || IA64 || 
SPARC))
depends on ARCH_OMAP2PLUS || COMPILE_TEST
select IOMMU_API
---help---
@@ -278,7 +278,7 @@ config OMAP_IOMMU_DEBUG
 
 config ROCKCHIP_IOMMU
bool "Rockchip IOMMU Support"
-   depends on ARM || ARM64
+   depends on ARM || ARM64 || (COMPILE_TEST && (ARM64 || IA64 || SPARC))
depends on ARCH_ROCKCHIP || COMPILE_TEST
select IOMMU_API
select ARM_DMA_USE_IOMMU
@@ -312,7 +312,7 @@ config TEGRA_IOMMU_SMMU
 
 config EXYNOS_IOMMU
bool "Exynos IOMMU Support"
-   depends on ARCH_EXYNOS && MMU
+   depends on ARCH_EXYNOS && MMU || (COMPILE_TEST && (ARM || ARM64 || IA64 
|| SPARC))
depends on !CPU_BIG_ENDIAN # revisit driver if we can enable big-endian 
ptes
select IOMMU_API
select ARM_DMA_USE_IOMMU
@@ -348,7 +348,7 @@ config IPMMU_VMSA
 
 config SPAPR_TCE_IOMMU
bool "sPAPR TCE IOMMU Support"
-   depends on PPC_POWERNV || PPC_PSERIES
+   depends on PPC_POWERNV || PPC_PSERIES || (PPC && COMPILE_TEST)
select IOMMU_API
help
  Enables bits of IOMMU API required by VFIO. The iommu_ops
@@ -357,7 +357,7 @@ config SPAPR_TCE_IOMMU
 # ARM IOMMU support
 config ARM_SMMU
bool "ARM Ltd. System MMU (SMMU) Support"
-   depends on (ARM64 || ARM) && MMU
+   depends on (ARM64 || ARM || (COMPILE_TEST && !GENERIC_ATOMIC64)) && MMU
select IOMMU_API
select IOMMU_IO_PGTABLE_LPAE
select ARM_DMA_USE_IOMMU if ARM
@@ -415,7 +415,7 @@ config S390_IOMMU
 
 config S390_CCW_IOMMU
bool "S390 CCW IOMMU Support"
-   depends on S390 && CCW
+   depends on S390 && CCW || COMPILE_TEST
select IOMMU_API
help
  Enables bits of IOMMU API required by VFIO. The iommu_ops
@@ -423,7 +423,7 @@ config S390_CCW_IOMMU
 
 config S390_AP_IOMMU
bool "S390 AP IOMMU Support"
-   depends on S390 && ZCRYPT
+   depends on S390 && ZCRYPT || COMPILE_TEST
select IOMMU_API
help
  Enables bits of IOMMU API required by VFIO. The iommu_ops
@@ -431,7 +431,7 @@ config S390_AP_IOMMU
 
 config MTK_IOMMU
bool "MTK IOMMU Support"
-   depends on ARM || ARM64
+   depends on ARM || ARM64 || COMPILE_TEST
depends on ARCH_MEDIATEK || COMPILE_TEST
select ARM_DMA_USE_IOMMU
select IOMMU_API
-- 
2.17.1

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


[PATCH v2] iommu: Fix Kconfig indentation

2019-11-20 Thread Krzysztof Kozlowski
Adjust indentation from spaces to tab (+optional two spaces) as in
coding style with command like:
$ sed -e 's/^/\t/' -i */Kconfig

Signed-off-by: Krzysztof Kozlowski 

---

Changes since v1:
1. Fix also 7-space and tab+1 space indentation issues.
---
 drivers/iommu/Kconfig | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index 0b9d78a0f3ac..c4486db105af 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -82,7 +82,7 @@ config IOMMU_DEBUGFS
 config IOMMU_DEFAULT_PASSTHROUGH
bool "IOMMU passthrough by default"
depends on IOMMU_API
-help
+   help
  Enable passthrough by default, removing the need to pass in
  iommu.passthrough=on or iommu=pt through command line. If this
  is enabled, you can still disable with iommu.passthrough=off
@@ -91,8 +91,8 @@ config IOMMU_DEFAULT_PASSTHROUGH
  If unsure, say N here.
 
 config OF_IOMMU
-   def_bool y
-   depends on OF && IOMMU_API
+   def_bool y
+   depends on OF && IOMMU_API
 
 # IOMMU-agnostic DMA-mapping layer
 config IOMMU_DMA
-- 
2.7.4

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


[RESEND TRIVIAL 2/3] treewide: Fix Kconfig indentation

2019-10-04 Thread Krzysztof Kozlowski
Adjust indentation from spaces to tab (+optional two spaces) as in
coding style with command like:
$ sed -e 's/^/\t/' -i */Kconfig

Signed-off-by: Krzysztof Kozlowski 
---
 certs/Kconfig  | 14 ++---
 init/Kconfig   | 28 +-
 kernel/trace/Kconfig   |  8 
 lib/Kconfig|  2 +-
 lib/Kconfig.debug  | 36 +-
 lib/Kconfig.kgdb   |  8 
 mm/Kconfig | 28 +-
 samples/Kconfig|  2 +-
 security/apparmor/Kconfig  |  2 +-
 security/integrity/Kconfig | 24 +++
 security/integrity/ima/Kconfig | 12 ++--
 security/safesetid/Kconfig | 24 +++
 12 files changed, 94 insertions(+), 94 deletions(-)

diff --git a/certs/Kconfig b/certs/Kconfig
index c94e93d8bccf..0358c66d3d7c 100644
--- a/certs/Kconfig
+++ b/certs/Kconfig
@@ -6,14 +6,14 @@ config MODULE_SIG_KEY
default "certs/signing_key.pem"
depends on MODULE_SIG
help
- Provide the file name of a private key/certificate in PEM format,
- or a PKCS#11 URI according to RFC7512. The file should contain, or
- the URI should identify, both the certificate and its corresponding
- private key.
+Provide the file name of a private key/certificate in PEM format,
+or a PKCS#11 URI according to RFC7512. The file should contain, or
+the URI should identify, both the certificate and its corresponding
+private key.
 
- If this option is unchanged from its default "certs/signing_key.pem",
- then the kernel will automatically generate the private key and
- certificate as described in 
Documentation/admin-guide/module-signing.rst
+If this option is unchanged from its default "certs/signing_key.pem",
+then the kernel will automatically generate the private key and
+certificate as described in 
Documentation/admin-guide/module-signing.rst
 
 config SYSTEM_TRUSTED_KEYRING
bool "Provide system-wide ring of trusted keys"
diff --git a/init/Kconfig b/init/Kconfig
index b4daad2bac23..e1a6f31da281 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -169,10 +169,10 @@ config BUILD_SALT
string "Build ID Salt"
default ""
help
-  The build ID is used to link binaries and their debug info. Setting
-  this option will use the value in the calculation of the build id.
-  This is mostly useful for distributions which want to ensure the
-  build is unique between builds. It's safe to leave the default.
+ The build ID is used to link binaries and their debug info. Setting
+ this option will use the value in the calculation of the build id.
+ This is mostly useful for distributions which want to ensure the
+ build is unique between builds. It's safe to leave the default.
 
 config HAVE_KERNEL_GZIP
bool
@@ -1327,9 +1327,9 @@ menuconfig EXPERT
select DEBUG_KERNEL
help
  This option allows certain base kernel options and settings
-  to be disabled or tweaked. This is for specialized
-  environments which can tolerate a "non-standard" kernel.
-  Only use this if you really know what you are doing.
+ to be disabled or tweaked. This is for specialized
+ environments which can tolerate a "non-standard" kernel.
+ Only use this if you really know what you are doing.
 
 config UID16
bool "Enable 16-bit UID system calls" if EXPERT
@@ -1439,11 +1439,11 @@ config BUG
bool "BUG() support" if EXPERT
default y
help
-  Disabling this option eliminates support for BUG and WARN, reducing
-  the size of your kernel image and potentially quietly ignoring
-  numerous fatal conditions. You should only consider disabling this
-  option for embedded systems with no facilities for reporting errors.
-  Just say Y.
+ Disabling this option eliminates support for BUG and WARN, reducing
+ the size of your kernel image and potentially quietly ignoring
+ numerous fatal conditions. You should only consider disabling this
+ option for embedded systems with no facilities for reporting errors.
+ Just say Y.
 
 config ELF_CORE
depends on COREDUMP
@@ -1459,8 +1459,8 @@ config PCSPKR_PLATFORM
select I8253_LOCK
default y
help
-  This option allows to disable the internal PC-Speaker
-  support, saving some memory.
+ This option allows to disable the internal PC-Speaker
+ support, saving some memory.
 
 config BASE_FULL
default y
diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig
index e0

  1   2   >