Re: [PATCH] iommu/vt-d: Fix PCI bus rescan device hot add

2022-01-13 Thread Lu Baolu 

On 1/14/22 11:11 AM, Jacob Pan wrote:

On Fri, 14 Jan 2022 08:58:53 +0800, Lu Baolu
wrote:


Hi Jacob,

On 1/13/22 9:23 PM, Jacob Pan wrote:

During PCI bus rescan, adding new devices involve two notifiers.
1. dmar_pci_bus_notifier()
2. iommu_bus_notifier()
The current code sets #1 as low priority (INT_MIN) which resulted in #2
being invoked first. The result is that struct device pointer cannot be
found in DRHD search for the new device's DMAR/IOMMU. Subsequently, the
device is put under the "catch-all" IOMMU instead of the correct one.

This could cause system hang when device TLB invalidation is sent to the
wrong IOMMU. Invalidation timeout error or hard lockup can be observed.

This patch fixes the issue by setting a higher priority for
dmar_pci_bus_notifier. DRHD search for a new device will find the
correct IOMMU.

Fixes: 59ce0515cdaf ("iommu/vt-d: Update DRHD/RMRR/ATSR device scope")
Reported-by: Zhang, Bernice
Signed-off-by: Jacob Pan
---
   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 915bff76fe96..5d07e5b89c2e 100644
--- a/drivers/iommu/intel/dmar.c
+++ b/drivers/iommu/intel/dmar.c
@@ -385,7 +385,7 @@ static int dmar_pci_bus_notifier(struct
notifier_block *nb,
   static struct notifier_block dmar_pci_bus_nb = {
.notifier_call = dmar_pci_bus_notifier,
-   .priority = INT_MIN,
+   .priority = INT_MAX,
   };
   
   static struct dmar_drhd_unit *
   

Nice catch! dmar_pci_bus_add_dev() should take place*before*
iommu_probe_device(). This change enforces this with a higher notifier
priority for dmar callback.

Comparably, dmar_pci_bus_del_dev() should take place*after*
iommu_release_device(). Perhaps we can use two notifiers, one for
ADD_DEVICE (with .priority=INT_MAX) and the other for REMOVE_DEVICE
(with .priority=INT_MIN)?


Since device_to_iommu() lookup in intel_iommu_release_device() only
checks if device is under "an" IOMMU, not "the" IOMMU. Then the remove path
order is not needed, right?

I know this is not robust, but having so many notifiers with implicit
priority is not clean either.

Perhaps, we should have explicit priority defined around iommu_bus
notifier? i.e.

@@ -1841,6 +1841,7 @@ static int iommu_bus_init(struct bus_type *bus, const
struct iommu_ops *ops) return -ENOMEM;
 nb->notifier_call = iommu_bus_notifier;

+   nb->priority = IOMMU_BUS_NOTIFY_PRIORITY;



  static struct notifier_block dmar_pci_bus_add_nb = {
 .notifier_call = dmar_pci_bus_notifier,
-   .priority = INT_MIN,
+   .priority = IOMMU_BUS_NOTIFY_PRIORITY + 1,
  };

  static struct notifier_block dmar_pci_bus_remove_nb = {
 .notifier_call = dmar_pci_bus_notifier,
-   .priority = INT_MIN,
+   .priority = IOMMU_BUS_NOTIFY_PRIORITY - 1,
  };


IOMMU_BUS_NOTIFY_PRIORITY by default is 0. So you can simply use 1 and
-1? Adding a comment around it will be helpful.

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

Re: [PATCH] iommu/vt-d: Fix PCI bus rescan device hot add

2022-01-13 Thread Jacob Pan 
Hi BaoLu,

On Fri, 14 Jan 2022 08:58:53 +0800, Lu Baolu 
wrote:

> Hi Jacob,
> 
> On 1/13/22 9:23 PM, Jacob Pan wrote:
> > During PCI bus rescan, adding new devices involve two notifiers.
> > 1. dmar_pci_bus_notifier()
> > 2. iommu_bus_notifier()
> > The current code sets #1 as low priority (INT_MIN) which resulted in #2
> > being invoked first. The result is that struct device pointer cannot be
> > found in DRHD search for the new device's DMAR/IOMMU. Subsequently, the
> > device is put under the "catch-all" IOMMU instead of the correct one.
> > 
> > This could cause system hang when device TLB invalidation is sent to the
> > wrong IOMMU. Invalidation timeout error or hard lockup can be observed.
> > 
> > This patch fixes the issue by setting a higher priority for
> > dmar_pci_bus_notifier. DRHD search for a new device will find the
> > correct IOMMU.
> > 
> > Fixes: 59ce0515cdaf ("iommu/vt-d: Update DRHD/RMRR/ATSR device scope")
> > Reported-by: Zhang, Bernice 
> > Signed-off-by: Jacob Pan 
> > ---
> >   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 915bff76fe96..5d07e5b89c2e 100644
> > --- a/drivers/iommu/intel/dmar.c
> > +++ b/drivers/iommu/intel/dmar.c
> > @@ -385,7 +385,7 @@ static int dmar_pci_bus_notifier(struct
> > notifier_block *nb, 
> >   static struct notifier_block dmar_pci_bus_nb = {
> > .notifier_call = dmar_pci_bus_notifier,
> > -   .priority = INT_MIN,
> > +   .priority = INT_MAX,
> >   };
> >   
> >   static struct dmar_drhd_unit *
> >   
> 
> Nice catch! dmar_pci_bus_add_dev() should take place *before*
> iommu_probe_device(). This change enforces this with a higher notifier
> priority for dmar callback.
> 
> Comparably, dmar_pci_bus_del_dev() should take place *after*
> iommu_release_device(). Perhaps we can use two notifiers, one for
> ADD_DEVICE (with .priority=INT_MAX) and the other for REMOVE_DEVICE
> (with .priority=INT_MIN)?
> 

Since device_to_iommu() lookup in intel_iommu_release_device() only
checks if device is under "an" IOMMU, not "the" IOMMU. Then the remove path
order is not needed, right?

I know this is not robust, but having so many notifiers with implicit
priority is not clean either.

Perhaps, we should have explicit priority defined around iommu_bus
notifier? i.e.

@@ -1841,6 +1841,7 @@ static int iommu_bus_init(struct bus_type *bus, const
struct iommu_ops *ops) return -ENOMEM; 
nb->notifier_call = iommu_bus_notifier;
   
+   nb->priority = IOMMU_BUS_NOTIFY_PRIORITY;
   

 static struct notifier_block dmar_pci_bus_add_nb = {  
.notifier_call = dmar_pci_bus_notifier,
-   .priority = INT_MIN,   
+   .priority = IOMMU_BUS_NOTIFY_PRIORITY + 1,   
 };

 static struct notifier_block dmar_pci_bus_remove_nb = {  
.notifier_call = dmar_pci_bus_notifier,
-   .priority = INT_MIN,   
+   .priority = IOMMU_BUS_NOTIFY_PRIORITY - 1,   
 };   
   

> Best regards,
> baolu


Thanks,

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

Re: [PATCH] iommu/vt-d: Fix PCI bus rescan device hot add

2022-01-13 Thread Lu Baolu 

Hi Jacob,

On 1/13/22 9:23 PM, Jacob Pan wrote:

During PCI bus rescan, adding new devices involve two notifiers.
1. dmar_pci_bus_notifier()
2. iommu_bus_notifier()
The current code sets #1 as low priority (INT_MIN) which resulted in #2
being invoked first. The result is that struct device pointer cannot be
found in DRHD search for the new device's DMAR/IOMMU. Subsequently, the
device is put under the "catch-all" IOMMU instead of the correct one.

This could cause system hang when device TLB invalidation is sent to the
wrong IOMMU. Invalidation timeout error or hard lockup can be observed.

This patch fixes the issue by setting a higher priority for
dmar_pci_bus_notifier. DRHD search for a new device will find the
correct IOMMU.

Fixes: 59ce0515cdaf ("iommu/vt-d: Update DRHD/RMRR/ATSR device scope")
Reported-by: Zhang, Bernice 
Signed-off-by: Jacob Pan 
---
  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 915bff76fe96..5d07e5b89c2e 100644
--- a/drivers/iommu/intel/dmar.c
+++ b/drivers/iommu/intel/dmar.c
@@ -385,7 +385,7 @@ static int dmar_pci_bus_notifier(struct notifier_block *nb,
  
  static struct notifier_block dmar_pci_bus_nb = {

.notifier_call = dmar_pci_bus_notifier,
-   .priority = INT_MIN,
+   .priority = INT_MAX,
  };
  
  static struct dmar_drhd_unit *




Nice catch! dmar_pci_bus_add_dev() should take place *before*
iommu_probe_device(). This change enforces this with a higher notifier
priority for dmar callback.

Comparably, dmar_pci_bus_del_dev() should take place *after*
iommu_release_device(). Perhaps we can use two notifiers, one for
ADD_DEVICE (with .priority=INT_MAX) and the other for REMOVE_DEVICE
(with .priority=INT_MIN)?

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

[PATCH] iommu/vt-d: Fix PCI bus rescan device hot add

2022-01-13 Thread Jacob Pan 
During PCI bus rescan, adding new devices involve two notifiers.
1. dmar_pci_bus_notifier()
2. iommu_bus_notifier()
The current code sets #1 as low priority (INT_MIN) which resulted in #2
being invoked first. The result is that struct device pointer cannot be
found in DRHD search for the new device's DMAR/IOMMU. Subsequently, the
device is put under the "catch-all" IOMMU instead of the correct one.

This could cause system hang when device TLB invalidation is sent to the
wrong IOMMU. Invalidation timeout error or hard lockup can be observed.

This patch fixes the issue by setting a higher priority for
dmar_pci_bus_notifier. DRHD search for a new device will find the
correct IOMMU.

Fixes: 59ce0515cdaf ("iommu/vt-d: Update DRHD/RMRR/ATSR device scope")
Reported-by: Zhang, Bernice 
Signed-off-by: Jacob Pan 
---
 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 915bff76fe96..5d07e5b89c2e 100644
--- a/drivers/iommu/intel/dmar.c
+++ b/drivers/iommu/intel/dmar.c
@@ -385,7 +385,7 @@ static int dmar_pci_bus_notifier(struct notifier_block *nb,
 
 static struct notifier_block dmar_pci_bus_nb = {
.notifier_call = dmar_pci_bus_notifier,
-   .priority = INT_MIN,
+   .priority = INT_MAX,
 };
 
 static struct dmar_drhd_unit *
-- 
2.25.1

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

Re: [RFC PATCH v3 2/8] mm: compaction: handle non-lru compound pages properly in isolate_migratepages_block().

2022-01-13 Thread Zi Yan via iommu 
On 13 Jan 2022, at 9:57, Zi Yan wrote:

> On 12 Jan 2022, at 6:01, David Hildenbrand wrote:
>
>> On 05.01.22 22:47, Zi Yan wrote:
>>> From: Zi Yan 
>>>
>>> In isolate_migratepages_block(), a !PageLRU tail page can be encountered
>>> when the page is larger than a pageblock. Use compound head page for the
>>> checks inside and skip the entire compound page when isolation succeeds.
>>>
>>
>> This will currently never happen, due to the way we always isolate
>> MAX_ORDER -1 ranges, correct?
>
> You are right.
>
>>
>> Better note that in the patch description, because currently it reads
>> like it's an actual fix "can be encountered".
>>
>
> Will do. This is a preparation patch for the upcoming commits.

I will drop this one too. Like you mentioned in [1], there are no
non-lru migratable compound pages. This is only used by my local
test code.

[1] 
https://lore.kernel.org/linux-mm/970ca2a4-416d-7e8f-37c7-510c5b050...@redhat.com/


>
>>> Signed-off-by: Zi Yan 
>>> ---
>>>  mm/compaction.c | 10 +++---
>>>  1 file changed, 7 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/mm/compaction.c b/mm/compaction.c
>>> index b4e94cda3019..ad9053fbbe06 100644
>>> --- a/mm/compaction.c
>>> +++ b/mm/compaction.c
>>> @@ -979,19 +979,23 @@ isolate_migratepages_block(struct compact_control 
>>> *cc, unsigned long low_pfn,
>>>  * Skip any other type of page
>>>  */
>>> if (!PageLRU(page)) {
>>> +   struct page *head = compound_head(page);
>>> /*
>>>  * __PageMovable can return false positive so we need
>>>  * to verify it under page_lock.
>>>  */
>>> -   if (unlikely(__PageMovable(page)) &&
>>> -   !PageIsolated(page)) {
>>> +   if (unlikely(__PageMovable(head)) &&
>>> +   !PageIsolated(head)) {
>>> if (locked) {
>>> unlock_page_lruvec_irqrestore(locked, 
>>> flags);
>>> locked = NULL;
>>> }
>>>
>>> -   if (!isolate_movable_page(page, isolate_mode))
>>> +   if (!isolate_movable_page(head, isolate_mode)) {
>>> +   low_pfn += (1 << compound_order(head)) 
>>> - 1 - (page - head);
>>> +   page = head;
>>> goto isolate_success;
>>> +   }
>>> }
>>>
>>> goto isolate_fail;
>>
>>
>> -- 
>> Thanks,
>>
>> David / dhildenb
>
>
> --
> Best Regards,
> Yan, Zi


--
Best Regards,
Yan, Zi


signature.asc
Description: OpenPGP digital signature
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH v9 12/15] media: mtk-vcodec: enc: Remove mtk_vcodec_release_enc_pm

2022-01-13 Thread Matthias Brugger 

Hi Hans,

On 13/01/2022 11:15, Hans Verkuil wrote:

On 13/01/2022 11:11, AngeloGioacchino Del Regno wrote:

Il 11/01/22 11:57, AngeloGioacchino Del Regno ha scritto:

Il 12/11/21 11:55, Yong Wu ha scritto:

After this patchset, mtk_vcodec_release_enc_pm has only one line.
then remove that function, use pm_runtime_disable instead.

meanwhile, mtk_vcodec_init_enc_pm only operate for the clocks,
rename it from the _pm to _clk.

No functional change.

CC: Tiffany Lin 
CC: Irui Wang 
Signed-off-by: Yong Wu 


Reviewed-by: AngeloGioacchino Del Regno 




Hello Yong,
the mtk-vcodec patches were merged in Yunfei's vcodec patch series and Hans has
scheduled that for v5.18.

Can you please send a v10 and drop patches 10/15, 11/15, 12/15 (all of the
media: mtk-vcodec: *) from this series?

For the records, I think that after sending v10 this series is ready to be 
merged,
as it was well reviewed and also tested on many MTK platforms.


Good to know. When I have the v10 I'll try to prioritize reviewing it and 
running
my usual tests.

Yong, please make sure you run 'checkpatch.pl --strict' over the v10 patches 
and fix
any issues (using common sense).



Can you please take me in the look when you take the patches. I'll take the DTS 
related as soon as you queue up the others.


Thanks!
Matthias


Regards,

Hans



Thank you,
- Angelo



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

Re: [RFC PATCH v3 3/8] mm: migrate: allocate the right size of non hugetlb or THP compound pages.

2022-01-13 Thread David Hildenbrand 
On 13.01.22 16:46, Zi Yan wrote:
> On 12 Jan 2022, at 6:04, David Hildenbrand wrote:
> 
>> On 05.01.22 22:47, Zi Yan wrote:
>>> From: Zi Yan 
>>>
>>> alloc_migration_target() is used by alloc_contig_range() and non-LRU
>>> movable compound pages can be migrated. Current code does not allocate the
>>> right page size for such pages. Check THP precisely using
>>> is_transparent_huge() and add allocation support for non-LRU compound
>>> pages.
>>
>> IIRC, we don't have any non-lru migratable pages that are coumpound
>> pages. Read: not used and not supported :)
> 
> OK, but nothing prevents one writing a driver that allocates compound
> pages and provides address_space->migratepage() and 
> address_space->isolate_page().
> 
> Actually, to test this series, I write a kernel module that allocates
> an order-10 page, gives it a fake address_space with migratepage() and
> isolate_page(), __SetPageMovable() on it, then call alloc_contig_range()
> on the page range. Apparently, my kernel module is not supported by
> the kernel, thus, I added this patch.
> 
> Do you have an alternative test to my kernel module, so that I do not
> even need this patch myself?
> 
>> Why is this required in the context of this series?
> 
> It might not be required. I will drop it.

That's why I think it would be best dropping it. If you need it in
different context, better submit it in different context.

Makes this series easier to digest :)


-- 
Thanks,

David / dhildenb

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

Re: [RFC PATCH v3 3/8] mm: migrate: allocate the right size of non hugetlb or THP compound pages.

2022-01-13 Thread Zi Yan via iommu 
On 12 Jan 2022, at 6:04, David Hildenbrand wrote:

> On 05.01.22 22:47, Zi Yan wrote:
>> From: Zi Yan 
>>
>> alloc_migration_target() is used by alloc_contig_range() and non-LRU
>> movable compound pages can be migrated. Current code does not allocate the
>> right page size for such pages. Check THP precisely using
>> is_transparent_huge() and add allocation support for non-LRU compound
>> pages.
>
> IIRC, we don't have any non-lru migratable pages that are coumpound
> pages. Read: not used and not supported :)

OK, but nothing prevents one writing a driver that allocates compound
pages and provides address_space->migratepage() and 
address_space->isolate_page().

Actually, to test this series, I write a kernel module that allocates
an order-10 page, gives it a fake address_space with migratepage() and
isolate_page(), __SetPageMovable() on it, then call alloc_contig_range()
on the page range. Apparently, my kernel module is not supported by
the kernel, thus, I added this patch.

Do you have an alternative test to my kernel module, so that I do not
even need this patch myself?

> Why is this required in the context of this series?

It might not be required. I will drop it.

--
Best Regards,
Yan, Zi


signature.asc
Description: OpenPGP digital signature
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH v3 2/7] dt-bindings: memory: mtk-smi: No need mediatek,larb-id for mt8167

2022-01-13 Thread AngeloGioacchino Del Regno 

Il 13/01/22 12:10, Yong Wu ha scritto:

Mute the warning from "make dtbs_check":

larb@14016000: 'mediatek,larb-id' is a required property
arch/arm64/boot/dts/mediatek/mt8167-pumpkin.dt.yaml
larb@15001000: 'mediatek,larb-id' is a required property
arch/arm64/boot/dts/mediatek/mt8167-pumpkin.dt.yaml
larb@1601: 'mediatek,larb-id' is a required property
arch/arm64/boot/dts/mediatek/mt8167-pumpkin.dt.yaml

As the description of mediatek,larb-id, the property is only
required when the larbid is not consecutive from its IOMMU point of view.

Also, from the description of mediatek,larbs in
Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml, all the larbs
must sort by the larb index.

In mt8167, there is only one IOMMU HW and three larbs. The drivers already
know its larb index from the mediatek,larbs property of IOMMU, thus no
need this property.

Fixes: 27bb0e42855a ("dt-bindings: memory: mediatek: Convert SMI to DT schema")
Signed-off-by: Yong Wu 


Acked-by: AngeloGioacchino Del Regno 



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

Re: [PATCH v3 3/7] dt-bindings: memory: mtk-smi: Correct minItems to 2 for the gals clocks

2022-01-13 Thread AngeloGioacchino Del Regno 

Il 13/01/22 12:10, Yong Wu ha scritto:

Mute the warning from "make dtbs_check":

larb@14017000: clock-names: ['apb', 'smi'] is too short
arch/arm64/boot/dts/mediatek/mt8183-evb.dt.yaml
arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-burnet.dt.yaml
...

larb@1601: clock-names: ['apb', 'smi'] is too short
arch/arm64/boot/dts/mediatek/mt8183-evb.dt.yaml
arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-burnet.dt.yaml

larb@1701: clock-names: ['apb', 'smi'] is too short
arch/arm64/boot/dts/mediatek/mt8183-evb.dt.yaml
arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-burnet.dt.yaml

If a platform's larb supports gals, there will be some larbs have one
more "gals" clock while the others still only need "apb"/"smi" clocks,
then the minItems for clocks and clock-names are 2.

Fixes: 27bb0e42855a ("dt-bindings: memory: mediatek: Convert SMI to DT schema")
Signed-off-by: Yong Wu 


Reviewed-by: AngeloGioacchino Del Regno 


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

Re: [PATCH v3 4/7] dt-bindings: memory: mediatek: Add mt8186 support

2022-01-13 Thread AngeloGioacchino Del Regno 

Il 13/01/22 12:10, Yong Wu ha scritto:

Add mt8186 smi support in the bindings.

Signed-off-by: Yong Wu 
Acked-by: Rob Herring 


Reviewed-by: AngeloGioacchino Del Regno 


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

Re: [PATCH v3 1/7] dt-bindings: memory: mtk-smi: Rename clock to clocks

2022-01-13 Thread AngeloGioacchino Del Regno 

Il 13/01/22 12:10, Yong Wu ha scritto:

The property "clock" should be rename to "clocks", and delete the "items",
the minItems/maxItems should not be put under "items".

Fixes: 27bb0e42855a ("dt-bindings: memory: mediatek: Convert SMI to DT schema")
Signed-off-by: Yong Wu 


Acked-by: AngeloGioacchino Del Regno 

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

Re: [RFC PATCH v3 2/8] mm: compaction: handle non-lru compound pages properly in isolate_migratepages_block().

2022-01-13 Thread Zi Yan via iommu 
On 12 Jan 2022, at 6:01, David Hildenbrand wrote:

> On 05.01.22 22:47, Zi Yan wrote:
>> From: Zi Yan 
>>
>> In isolate_migratepages_block(), a !PageLRU tail page can be encountered
>> when the page is larger than a pageblock. Use compound head page for the
>> checks inside and skip the entire compound page when isolation succeeds.
>>
>
> This will currently never happen, due to the way we always isolate
> MAX_ORDER -1 ranges, correct?

You are right.

>
> Better note that in the patch description, because currently it reads
> like it's an actual fix "can be encountered".
>

Will do. This is a preparation patch for the upcoming commits.


>> Signed-off-by: Zi Yan 
>> ---
>>  mm/compaction.c | 10 +++---
>>  1 file changed, 7 insertions(+), 3 deletions(-)
>>
>> diff --git a/mm/compaction.c b/mm/compaction.c
>> index b4e94cda3019..ad9053fbbe06 100644
>> --- a/mm/compaction.c
>> +++ b/mm/compaction.c
>> @@ -979,19 +979,23 @@ isolate_migratepages_block(struct compact_control *cc, 
>> unsigned long low_pfn,
>>   * Skip any other type of page
>>   */
>>  if (!PageLRU(page)) {
>> +struct page *head = compound_head(page);
>>  /*
>>   * __PageMovable can return false positive so we need
>>   * to verify it under page_lock.
>>   */
>> -if (unlikely(__PageMovable(page)) &&
>> -!PageIsolated(page)) {
>> +if (unlikely(__PageMovable(head)) &&
>> +!PageIsolated(head)) {
>>  if (locked) {
>>  unlock_page_lruvec_irqrestore(locked, 
>> flags);
>>  locked = NULL;
>>  }
>>
>> -if (!isolate_movable_page(page, isolate_mode))
>> +if (!isolate_movable_page(head, isolate_mode)) {
>> +low_pfn += (1 << compound_order(head)) 
>> - 1 - (page - head);
>> +page = head;
>>  goto isolate_success;
>> +}
>>  }
>>
>>  goto isolate_fail;
>
>
> -- 
> Thanks,
>
> David / dhildenb


--
Best Regards,
Yan, Zi


signature.asc
Description: OpenPGP digital signature
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [RFC PATCH v3 1/8] mm: page_alloc: avoid merging non-fallbackable pageblocks with others.

2022-01-13 Thread Zi Yan via iommu 
On 13 Jan 2022, at 7:28, David Hildenbrand wrote:

> On 13.01.22 12:36, Mike Rapoport wrote:
>> On Wed, Jan 12, 2022 at 11:54:49AM +0100, David Hildenbrand wrote:
>>> On 05.01.22 22:47, Zi Yan wrote:
 From: Zi Yan 

 This is done in addition to MIGRATE_ISOLATE pageblock merge avoidance.
 It prepares for the upcoming removal of the MAX_ORDER-1 alignment
 requirement for CMA and alloc_contig_range().

 MIGRARTE_HIGHATOMIC should not merge with other migratetypes like
 MIGRATE_ISOLATE and MIGRARTE_CMA[1], so this commit prevents that too.
 Also add MIGRARTE_HIGHATOMIC to fallbacks array for completeness.

 [1] 
 https://lore.kernel.org/linux-mm/20211130100853.gp3...@techsingularity.net/

 Signed-off-by: Zi Yan 
 ---
  include/linux/mmzone.h |  6 ++
  mm/page_alloc.c| 28 ++--
  2 files changed, 24 insertions(+), 10 deletions(-)

>>
>> ...
>>
 @@ -3545,8 +3553,8 @@ int __isolate_free_page(struct page *page, unsigned 
 int order)
struct page *endpage = page + (1 << order) - 1;
for (; page < endpage; page += pageblock_nr_pages) {
int mt = get_pageblock_migratetype(page);
 -  if (!is_migrate_isolate(mt) && !is_migrate_cma(mt)
 -  && !is_migrate_highatomic(mt))
 +  /* Only change normal pageblock */
 +  if (migratetype_has_fallback(mt))
set_pageblock_migratetype(page,
  MIGRATE_MOVABLE);
}
>>>
>>> That part is a nice cleanup IMHO. Although the "has fallback" part is a
>>> bit imprecise. "migratetype_is_mergable()" might be a bit clearer.
>>> ideally "migratetype_is_mergable_with_other_types()". Can we come up
>>> with a nice name for that?
>>
>> migratetype_is_mergable() kinda implies "_with_other_types", no?
>>
>> I like migratetype_is_mergable() more than _has_fallback().
>>
>> My $0.02 to bikeshedding :)
>
> :)
>
> Yeah, for me migratetype_is_mergable() would also be good enough. I
> think I was at first thinking one could mistake it with a dedicated
> migratetype. But such functions are historically called
>
> is_migrate_cma/is_migrate_cma/
>
> -- 
> Thanks,
>
> David / dhildenb

OK. Will use migratetype_is_mergable() instead.


--
Best Regards,
Yan, Zi


signature.asc
Description: OpenPGP digital signature
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [RFC PATCH v3 1/8] mm: page_alloc: avoid merging non-fallbackable pageblocks with others.

2022-01-13 Thread Zi Yan via iommu 
On 12 Jan 2022, at 5:54, David Hildenbrand wrote:

> On 05.01.22 22:47, Zi Yan wrote:
>> From: Zi Yan 
>>
>> This is done in addition to MIGRATE_ISOLATE pageblock merge avoidance.
>> It prepares for the upcoming removal of the MAX_ORDER-1 alignment
>> requirement for CMA and alloc_contig_range().
>>
>> MIGRARTE_HIGHATOMIC should not merge with other migratetypes like
>> MIGRATE_ISOLATE and MIGRARTE_CMA[1], so this commit prevents that too.
>> Also add MIGRARTE_HIGHATOMIC to fallbacks array for completeness.
>>
>> [1] 
>> https://lore.kernel.org/linux-mm/20211130100853.gp3...@techsingularity.net/
>>
>> Signed-off-by: Zi Yan 
>> ---
>>  include/linux/mmzone.h |  6 ++
>>  mm/page_alloc.c| 28 ++--
>>  2 files changed, 24 insertions(+), 10 deletions(-)
>>
>> diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
>> index aed44e9b5d89..0aa549653e4e 100644
>> --- a/include/linux/mmzone.h
>> +++ b/include/linux/mmzone.h
>> @@ -83,6 +83,12 @@ static inline bool is_migrate_movable(int mt)
>>  return is_migrate_cma(mt) || mt == MIGRATE_MOVABLE;
>>  }
>>
>> +/* See fallbacks[MIGRATE_TYPES][3] in page_alloc.c */
>> +static inline bool migratetype_has_fallback(int mt)
>> +{
>> +return mt < MIGRATE_PCPTYPES;
>> +}
>> +
>>  #define for_each_migratetype_order(order, type) \
>>  for (order = 0; order < MAX_ORDER; order++) \
>>  for (type = 0; type < MIGRATE_TYPES; type++)
>> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
>> index 8dd6399bafb5..5193c953dbf8 100644
>> --- a/mm/page_alloc.c
>> +++ b/mm/page_alloc.c
>> @@ -1042,6 +1042,12 @@ buddy_merge_likely(unsigned long pfn, unsigned long 
>> buddy_pfn,
>>  return page_is_buddy(higher_page, higher_buddy, order + 1);
>>  }
>>
>> +static inline bool has_non_fallback_pageblock(struct zone *zone)
>> +{
>> +return has_isolate_pageblock(zone) || zone_cma_pages(zone) != 0 ||
>> +zone->nr_reserved_highatomic != 0;
>> +}
>
> Due to zone_cma_pages(), the unlikely() below will be very wrong on many
> setups. Previously, isolation really was a corner case. CMA and
> highatomic are less of a corner case ...

Got it.

>
> I'm not even sure if this check is worth having around anymore at all,
> or if it would be easier and cheaper to just always check the both
> migration types unconditionally. Would certainly simplify the code.

I will remove the if check below, since, like you said, the check is
no longer a corner case with added highatomic and CMA check.

>
> Side node: we actually care about has_free_non_fallback_pageblock(), we
> can only merge with free pageblocks. But that might not necessarily be
> cheaper to test/track/check.
>

I agree that what we are actually looking for is free pageblocks of these
migratetypes. But tracking them is nontrivial.

>> +
>>  /*
>>   * Freeing function for a buddy system allocator.
>>   *
>> @@ -1117,14 +1123,15 @@ static inline void __free_one_page(struct page *page,
>>  }
>>  if (order < MAX_ORDER - 1) {
>>  /* If we are here, it means order is >= pageblock_order.
>> - * We want to prevent merge between freepages on isolate
>> - * pageblock and normal pageblock. Without this, pageblock
>> - * isolation could cause incorrect freepage or CMA accounting.
>> + * We want to prevent merge between freepages on pageblock
>> + * without fallbacks and normal pageblock. Without this,
>> + * pageblock isolation could cause incorrect freepage or CMA
>> + * accounting or HIGHATOMIC accounting.
>>   *
>>   * We don't want to hit this code for the more frequent
>>   * low-order merging.
>>   */
>> -if (unlikely(has_isolate_pageblock(zone))) {
>> +if (unlikely(has_non_fallback_pageblock(zone))) {
>>  int buddy_mt;
>>
>>  buddy_pfn = __find_buddy_pfn(pfn, order);
>> @@ -1132,8 +1139,8 @@ static inline void __free_one_page(struct page *page,
>>  buddy_mt = get_pageblock_migratetype(buddy);
>>
>>  if (migratetype != buddy_mt
>> -&& (is_migrate_isolate(migratetype) ||
>> -is_migrate_isolate(buddy_mt)))
>> +&& 
>> (!migratetype_has_fallback(migratetype) ||
>> +
>> !migratetype_has_fallback(buddy_mt)))
>>  goto done_merging;
>>  }
>>  max_order = order + 1;
>> @@ -2484,6 +2491,7 @@ static int fallbacks[MIGRATE_TYPES][3] = {
>>  [MIGRATE_UNMOVABLE]   = { MIGRATE_RECLAIMABLE, MIGRATE_MOVABLE,   
>> MIGRATE_TYPES },
>>  [MIGRATE_MOVABLE] = { MIGRATE_RECLAIMABLE, MIGRATE_UNMOVABLE, 
>> MIGRATE_TYPES },
>>  [MIGRATE_RECLAIMABLE] = { MIGRATE_UNMOVABLE,   MIGRATE_MOVABLE,   
>> MIGRATE_TYPES },
>> +

Re: [RFC PATCH v3 1/8] mm: page_alloc: avoid merging non-fallbackable pageblocks with others.

2022-01-13 Thread David Hildenbrand 
On 13.01.22 12:36, Mike Rapoport wrote:
> On Wed, Jan 12, 2022 at 11:54:49AM +0100, David Hildenbrand wrote:
>> On 05.01.22 22:47, Zi Yan wrote:
>>> From: Zi Yan 
>>>
>>> This is done in addition to MIGRATE_ISOLATE pageblock merge avoidance.
>>> It prepares for the upcoming removal of the MAX_ORDER-1 alignment
>>> requirement for CMA and alloc_contig_range().
>>>
>>> MIGRARTE_HIGHATOMIC should not merge with other migratetypes like
>>> MIGRATE_ISOLATE and MIGRARTE_CMA[1], so this commit prevents that too.
>>> Also add MIGRARTE_HIGHATOMIC to fallbacks array for completeness.
>>>
>>> [1] 
>>> https://lore.kernel.org/linux-mm/20211130100853.gp3...@techsingularity.net/
>>>
>>> Signed-off-by: Zi Yan 
>>> ---
>>>  include/linux/mmzone.h |  6 ++
>>>  mm/page_alloc.c| 28 ++--
>>>  2 files changed, 24 insertions(+), 10 deletions(-)
>>>
> 
> ...
> 
>>> @@ -3545,8 +3553,8 @@ int __isolate_free_page(struct page *page, unsigned 
>>> int order)
>>> struct page *endpage = page + (1 << order) - 1;
>>> for (; page < endpage; page += pageblock_nr_pages) {
>>> int mt = get_pageblock_migratetype(page);
>>> -   if (!is_migrate_isolate(mt) && !is_migrate_cma(mt)
>>> -   && !is_migrate_highatomic(mt))
>>> +   /* Only change normal pageblock */
>>> +   if (migratetype_has_fallback(mt))
>>> set_pageblock_migratetype(page,
>>>   MIGRATE_MOVABLE);
>>> }
>>
>> That part is a nice cleanup IMHO. Although the "has fallback" part is a
>> bit imprecise. "migratetype_is_mergable()" might be a bit clearer.
>> ideally "migratetype_is_mergable_with_other_types()". Can we come up
>> with a nice name for that?
> 
> migratetype_is_mergable() kinda implies "_with_other_types", no?
> 
> I like migratetype_is_mergable() more than _has_fallback().
> 
> My $0.02 to bikeshedding :)

:)

Yeah, for me migratetype_is_mergable() would also be good enough. I
think I was at first thinking one could mistake it with a dedicated
migratetype. But such functions are historically called

is_migrate_cma/is_migrate_cma/

-- 
Thanks,

David / dhildenb

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

Re: [RFC PATCH v3 1/8] mm: page_alloc: avoid merging non-fallbackable pageblocks with others.

2022-01-13 Thread Mike Rapoport 
On Wed, Jan 12, 2022 at 11:54:49AM +0100, David Hildenbrand wrote:
> On 05.01.22 22:47, Zi Yan wrote:
> > From: Zi Yan 
> > 
> > This is done in addition to MIGRATE_ISOLATE pageblock merge avoidance.
> > It prepares for the upcoming removal of the MAX_ORDER-1 alignment
> > requirement for CMA and alloc_contig_range().
> > 
> > MIGRARTE_HIGHATOMIC should not merge with other migratetypes like
> > MIGRATE_ISOLATE and MIGRARTE_CMA[1], so this commit prevents that too.
> > Also add MIGRARTE_HIGHATOMIC to fallbacks array for completeness.
> > 
> > [1] 
> > https://lore.kernel.org/linux-mm/20211130100853.gp3...@techsingularity.net/
> > 
> > Signed-off-by: Zi Yan 
> > ---
> >  include/linux/mmzone.h |  6 ++
> >  mm/page_alloc.c| 28 ++--
> >  2 files changed, 24 insertions(+), 10 deletions(-)
> > 

...

> > @@ -3545,8 +3553,8 @@ int __isolate_free_page(struct page *page, unsigned 
> > int order)
> > struct page *endpage = page + (1 << order) - 1;
> > for (; page < endpage; page += pageblock_nr_pages) {
> > int mt = get_pageblock_migratetype(page);
> > -   if (!is_migrate_isolate(mt) && !is_migrate_cma(mt)
> > -   && !is_migrate_highatomic(mt))
> > +   /* Only change normal pageblock */
> > +   if (migratetype_has_fallback(mt))
> > set_pageblock_migratetype(page,
> >   MIGRATE_MOVABLE);
> > }
> 
> That part is a nice cleanup IMHO. Although the "has fallback" part is a
> bit imprecise. "migratetype_is_mergable()" might be a bit clearer.
> ideally "migratetype_is_mergable_with_other_types()". Can we come up
> with a nice name for that?

migratetype_is_mergable() kinda implies "_with_other_types", no?

I like migratetype_is_mergable() more than _has_fallback().

My $0.02 to bikeshedding :)
 
> -- 
> Thanks,
> 
> David / dhildenb
> 
> 

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

[PATCH v3 6/7] memory: mtk-smi: Add sleep ctrl function

2022-01-13 Thread Yong Wu 
Sleep control means that when the larb goes to sleep, we should wait a bit
until all the current commands are finished. Thus, when the larb runtime
suspends, we need to enable this function to wait until all the existed
commands are finished. When the larb resumes, just disable this function.
This function only improves the safety of bus. Add a new flag for this
function. Prepare for mt8186.

Signed-off-by: Anan Sun 
Signed-off-by: Yong Wu 
Reviewed-by: AngeloGioacchino Del Regno 

---
 drivers/memory/mtk-smi.c | 36 
 1 file changed, 36 insertions(+)

diff --git a/drivers/memory/mtk-smi.c b/drivers/memory/mtk-smi.c
index e7b1a22b12ea..12d15fcc65e2 100644
--- a/drivers/memory/mtk-smi.c
+++ b/drivers/memory/mtk-smi.c
@@ -8,6 +8,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -32,6 +33,10 @@
 #define SMI_DUMMY  0x444
 
 /* SMI LARB */
+#define SMI_LARB_SLP_CON0xc
+#define SLP_PROT_EN BIT(0)
+#define SLP_PROT_RDYBIT(16)
+
 #define SMI_LARB_CMD_THRT_CON  0x24
 #define SMI_LARB_THRT_RD_NU_LMT_MSKGENMASK(7, 4)
 #define SMI_LARB_THRT_RD_NU_LMT(5 << 4)
@@ -81,6 +86,7 @@
 
 #define MTK_SMI_FLAG_THRT_UPDATE   BIT(0)
 #define MTK_SMI_FLAG_SW_FLAG   BIT(1)
+#define MTK_SMI_FLAG_SLEEP_CTL BIT(2)
 #define MTK_SMI_CAPS(flags, _x)(!!((flags) & (_x)))
 
 struct mtk_smi_reg_pair {
@@ -371,6 +377,26 @@ static const struct of_device_id mtk_smi_larb_of_ids[] = {
{}
 };
 
+static int mtk_smi_larb_sleep_ctrl_enable(struct mtk_smi_larb *larb)
+{
+   int ret;
+   u32 tmp;
+
+   writel_relaxed(SLP_PROT_EN, larb->base + SMI_LARB_SLP_CON);
+   ret = readl_poll_timeout_atomic(larb->base + SMI_LARB_SLP_CON,
+   tmp, !!(tmp & SLP_PROT_RDY), 10, 1000);
+   if (ret) {
+   /* TODO: Reset this larb if it fails here. */
+   dev_err(larb->smi.dev, "sleep ctrl is not ready(0x%x).\n", tmp);
+   }
+   return ret;
+}
+
+static void mtk_smi_larb_sleep_ctrl_disable(struct mtk_smi_larb *larb)
+{
+   writel_relaxed(0, larb->base + SMI_LARB_SLP_CON);
+}
+
 static int mtk_smi_device_link_common(struct device *dev, struct device 
**com_dev)
 {
struct platform_device *smi_com_pdev;
@@ -483,6 +509,9 @@ static int __maybe_unused mtk_smi_larb_resume(struct device 
*dev)
if (ret)
return ret;
 
+   if (MTK_SMI_CAPS(larb->larb_gen->flags_general, MTK_SMI_FLAG_SLEEP_CTL))
+   mtk_smi_larb_sleep_ctrl_disable(larb);
+
/* Configure the basic setting for this larb */
larb_gen->config_port(dev);
 
@@ -492,6 +521,13 @@ static int __maybe_unused mtk_smi_larb_resume(struct 
device *dev)
 static int __maybe_unused mtk_smi_larb_suspend(struct device *dev)
 {
struct mtk_smi_larb *larb = dev_get_drvdata(dev);
+   int ret;
+
+   if (MTK_SMI_CAPS(larb->larb_gen->flags_general, 
MTK_SMI_FLAG_SLEEP_CTL)) {
+   ret = mtk_smi_larb_sleep_ctrl_enable(larb);
+   if (ret)
+   return ret;
+   }
 
clk_bulk_disable_unprepare(larb->smi.clk_num, larb->smi.clks);
return 0;
-- 
2.18.0

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

[PATCH v3 7/7] memory: mtk-smi: mt8186: Add smi support

2022-01-13 Thread Yong Wu 
Add mt8186 SMI support.

Signed-off-by: Yong Wu 
Acked-by: AngeloGioacchino Del Regno 
---
 drivers/memory/mtk-smi.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/drivers/memory/mtk-smi.c b/drivers/memory/mtk-smi.c
index 12d15fcc65e2..378affd43fc4 100644
--- a/drivers/memory/mtk-smi.c
+++ b/drivers/memory/mtk-smi.c
@@ -355,6 +355,11 @@ static const struct mtk_smi_larb_gen mtk_smi_larb_mt8183 = 
{
  /* IPU0 | IPU1 | CCU */
 };
 
+static const struct mtk_smi_larb_gen mtk_smi_larb_mt8186 = {
+   .config_port= mtk_smi_larb_config_port_gen2_general,
+   .flags_general  = MTK_SMI_FLAG_SLEEP_CTL,
+};
+
 static const struct mtk_smi_larb_gen mtk_smi_larb_mt8192 = {
.config_port= mtk_smi_larb_config_port_gen2_general,
 };
@@ -372,6 +377,7 @@ static const struct of_device_id mtk_smi_larb_of_ids[] = {
{.compatible = "mediatek,mt8167-smi-larb", .data = 
_smi_larb_mt8167},
{.compatible = "mediatek,mt8173-smi-larb", .data = 
_smi_larb_mt8173},
{.compatible = "mediatek,mt8183-smi-larb", .data = 
_smi_larb_mt8183},
+   {.compatible = "mediatek,mt8186-smi-larb", .data = 
_smi_larb_mt8186},
{.compatible = "mediatek,mt8192-smi-larb", .data = 
_smi_larb_mt8192},
{.compatible = "mediatek,mt8195-smi-larb", .data = 
_smi_larb_mt8195},
{}
@@ -580,6 +586,12 @@ static const struct mtk_smi_common_plat 
mtk_smi_common_mt8183 = {
F_MMU1_LARB(7),
 };
 
+static const struct mtk_smi_common_plat mtk_smi_common_mt8186 = {
+   .type = MTK_SMI_GEN2,
+   .has_gals = true,
+   .bus_sel  = F_MMU1_LARB(1) | F_MMU1_LARB(4) | F_MMU1_LARB(7),
+};
+
 static const struct mtk_smi_common_plat mtk_smi_common_mt8192 = {
.type = MTK_SMI_GEN2,
.has_gals = true,
@@ -614,6 +626,7 @@ static const struct of_device_id mtk_smi_common_of_ids[] = {
{.compatible = "mediatek,mt8167-smi-common", .data = 
_smi_common_gen2},
{.compatible = "mediatek,mt8173-smi-common", .data = 
_smi_common_gen2},
{.compatible = "mediatek,mt8183-smi-common", .data = 
_smi_common_mt8183},
+   {.compatible = "mediatek,mt8186-smi-common", .data = 
_smi_common_mt8186},
{.compatible = "mediatek,mt8192-smi-common", .data = 
_smi_common_mt8192},
{.compatible = "mediatek,mt8195-smi-common-vdo", .data = 
_smi_common_mt8195_vdo},
{.compatible = "mediatek,mt8195-smi-common-vpp", .data = 
_smi_common_mt8195_vpp},
-- 
2.18.0

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

[PATCH v3 5/7] memory: mtk-smi: Fix the return value for clk_bulk_prepare_enable

2022-01-13 Thread Yong Wu 
Function clk_bulk_prepare_enable() returns 0 for success or a negative
number for error. Fix this code style issue.

Signed-off-by: Yong Wu 
Reviewed-by: AngeloGioacchino Del Regno 

---
 drivers/memory/mtk-smi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/memory/mtk-smi.c b/drivers/memory/mtk-smi.c
index b883dcc0bbfa..e7b1a22b12ea 100644
--- a/drivers/memory/mtk-smi.c
+++ b/drivers/memory/mtk-smi.c
@@ -480,7 +480,7 @@ static int __maybe_unused mtk_smi_larb_resume(struct device 
*dev)
int ret;
 
ret = clk_bulk_prepare_enable(larb->smi.clk_num, larb->smi.clks);
-   if (ret < 0)
+   if (ret)
return ret;
 
/* Configure the basic setting for this larb */
-- 
2.18.0

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

[PATCH v3 4/7] dt-bindings: memory: mediatek: Add mt8186 support

2022-01-13 Thread Yong Wu 
Add mt8186 smi support in the bindings.

Signed-off-by: Yong Wu 
Acked-by: Rob Herring 
---
 .../bindings/memory-controllers/mediatek,smi-common.yaml  | 4 +++-
 .../bindings/memory-controllers/mediatek,smi-larb.yaml| 3 +++
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git 
a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml 
b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml
index 4fca71f34310..a98b359bf909 100644
--- 
a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml
+++ 
b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml
@@ -16,7 +16,7 @@ description: |
   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, mt8183, mt8192 and mt8195.
+  generation 2: mt2712, mt6779, mt8167, mt8173, mt8183, mt8186, mt8192 and 
mt8195.
 
   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
@@ -35,6 +35,7 @@ properties:
   - mediatek,mt8167-smi-common
   - mediatek,mt8173-smi-common
   - mediatek,mt8183-smi-common
+  - mediatek,mt8186-smi-common
   - mediatek,mt8192-smi-common
   - mediatek,mt8195-smi-common-vdo
   - mediatek,mt8195-smi-common-vpp
@@ -125,6 +126,7 @@ allOf:
   enum:
 - mediatek,mt6779-smi-common
 - mediatek,mt8183-smi-common
+- mediatek,mt8186-smi-common
 - mediatek,mt8192-smi-common
 - mediatek,mt8195-smi-common-vdo
 - mediatek,mt8195-smi-common-vpp
diff --git 
a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml 
b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml
index c5c32c910045..4db8690829cd 100644
--- 
a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml
+++ 
b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml
@@ -23,6 +23,7 @@ properties:
   - mediatek,mt8167-smi-larb
   - mediatek,mt8173-smi-larb
   - mediatek,mt8183-smi-larb
+  - mediatek,mt8186-smi-larb
   - mediatek,mt8192-smi-larb
   - mediatek,mt8195-smi-larb
 
@@ -75,6 +76,7 @@ allOf:
 compatible:
   enum:
 - mediatek,mt8183-smi-larb
+- mediatek,mt8186-smi-larb
 - mediatek,mt8195-smi-larb
 
 then:
@@ -107,6 +109,7 @@ allOf:
   - mediatek,mt2701-smi-larb
   - mediatek,mt2712-smi-larb
   - mediatek,mt6779-smi-larb
+  - mediatek,mt8186-smi-larb
   - mediatek,mt8192-smi-larb
   - mediatek,mt8195-smi-larb
 
-- 
2.18.0

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

[PATCH v3 3/7] dt-bindings: memory: mtk-smi: Correct minItems to 2 for the gals clocks

2022-01-13 Thread Yong Wu 
Mute the warning from "make dtbs_check":

larb@14017000: clock-names: ['apb', 'smi'] is too short
arch/arm64/boot/dts/mediatek/mt8183-evb.dt.yaml
arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-burnet.dt.yaml
...

larb@1601: clock-names: ['apb', 'smi'] is too short
arch/arm64/boot/dts/mediatek/mt8183-evb.dt.yaml
arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-burnet.dt.yaml

larb@1701: clock-names: ['apb', 'smi'] is too short
arch/arm64/boot/dts/mediatek/mt8183-evb.dt.yaml
arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-burnet.dt.yaml

If a platform's larb supports gals, there will be some larbs have one
more "gals" clock while the others still only need "apb"/"smi" clocks,
then the minItems for clocks and clock-names are 2.

Fixes: 27bb0e42855a ("dt-bindings: memory: mediatek: Convert SMI to DT schema")
Signed-off-by: Yong Wu 
---
 .../bindings/memory-controllers/mediatek,smi-larb.yaml | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git 
a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml 
b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml
index 6d61c51893d2..c5c32c910045 100644
--- 
a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml
+++ 
b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml
@@ -80,9 +80,10 @@ allOf:
 then:
   properties:
 clocks:
-  minItems: 3
+  minItems: 2
   maxItems: 3
 clock-names:
+  minItems: 2
   items:
 - const: apb
 - const: smi
-- 
2.18.0

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

[PATCH v3 2/7] dt-bindings: memory: mtk-smi: No need mediatek, larb-id for mt8167

2022-01-13 Thread Yong Wu 
Mute the warning from "make dtbs_check":

larb@14016000: 'mediatek,larb-id' is a required property
arch/arm64/boot/dts/mediatek/mt8167-pumpkin.dt.yaml
larb@15001000: 'mediatek,larb-id' is a required property
arch/arm64/boot/dts/mediatek/mt8167-pumpkin.dt.yaml
larb@1601: 'mediatek,larb-id' is a required property
arch/arm64/boot/dts/mediatek/mt8167-pumpkin.dt.yaml

As the description of mediatek,larb-id, the property is only
required when the larbid is not consecutive from its IOMMU point of view.

Also, from the description of mediatek,larbs in
Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml, all the larbs
must sort by the larb index.

In mt8167, there is only one IOMMU HW and three larbs. The drivers already
know its larb index from the mediatek,larbs property of IOMMU, thus no
need this property.

Fixes: 27bb0e42855a ("dt-bindings: memory: mediatek: Convert SMI to DT schema")
Signed-off-by: Yong Wu 
---
 .../bindings/memory-controllers/mediatek,smi-larb.yaml   | 1 -
 1 file changed, 1 deletion(-)

diff --git 
a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml 
b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml
index bd7aa8257949..6d61c51893d2 100644
--- 
a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml
+++ 
b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml
@@ -106,7 +106,6 @@ allOf:
   - mediatek,mt2701-smi-larb
   - mediatek,mt2712-smi-larb
   - mediatek,mt6779-smi-larb
-  - mediatek,mt8167-smi-larb
   - mediatek,mt8192-smi-larb
   - mediatek,mt8195-smi-larb
 
-- 
2.18.0

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

[PATCH v3 1/7] dt-bindings: memory: mtk-smi: Rename clock to clocks

2022-01-13 Thread Yong Wu 
The property "clock" should be rename to "clocks", and delete the "items",
the minItems/maxItems should not be put under "items".

Fixes: 27bb0e42855a ("dt-bindings: memory: mediatek: Convert SMI to DT schema")
Signed-off-by: Yong Wu 
---
 .../mediatek,smi-common.yaml  | 28 ---
 .../memory-controllers/mediatek,smi-larb.yaml | 14 --
 2 files changed, 18 insertions(+), 24 deletions(-)

diff --git 
a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml 
b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml
index 3a82b0b27fa0..4fca71f34310 100644
--- 
a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml
+++ 
b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml
@@ -88,10 +88,9 @@ allOf:
   - mediatek,mt2701-smi-common
 then:
   properties:
-clock:
-  items:
-minItems: 3
-maxItems: 3
+clocks:
+  minItems: 3
+  maxItems: 3
 clock-names:
   items:
 - const: apb
@@ -108,10 +107,9 @@ allOf:
   required:
 - mediatek,smi
   properties:
-clock:
-  items:
-minItems: 3
-maxItems: 3
+clocks:
+  minItems: 3
+  maxItems: 3
 clock-names:
   items:
 - const: apb
@@ -133,10 +131,9 @@ allOf:
 
 then:
   properties:
-clock:
-  items:
-minItems: 4
-maxItems: 4
+clocks:
+  minItems: 4
+  maxItems: 4
 clock-names:
   items:
 - const: apb
@@ -146,10 +143,9 @@ allOf:
 
 else:  # for gen2 HW that don't have gals
   properties:
-clock:
-  items:
-minItems: 2
-maxItems: 2
+clocks:
+  minItems: 2
+  maxItems: 2
 clock-names:
   items:
 - const: apb
diff --git 
a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml 
b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml
index eaeff1ada7f8..bd7aa8257949 100644
--- 
a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml
+++ 
b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml
@@ -79,10 +79,9 @@ allOf:
 
 then:
   properties:
-clock:
-  items:
-minItems: 3
-maxItems: 3
+clocks:
+  minItems: 3
+  maxItems: 3
 clock-names:
   items:
 - const: apb
@@ -91,10 +90,9 @@ allOf:
 
 else:
   properties:
-clock:
-  items:
-minItems: 2
-maxItems: 2
+clocks:
+  minItems: 2
+  maxItems: 2
 clock-names:
   items:
 - const: apb
-- 
2.18.0

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

[PATCH v3 0/7] MT8186 SMI SUPPORT

2022-01-13 Thread Yong Wu 
This patchset adds mt8186 smi support.
mainly adds a sleep control function.

Change note:
v3: a) Add a new binding patch for renaming "clock" to "clocks".
b) Reword the title for the binding patches, more detailed.
c) Add the sleep control error path: if err, return directly.
   also change the log from dev_warn to dev_err.

v2: 
https://lore.kernel.org/linux-devicetree/20220111063904.7583-1-yong...@mediatek.com/
a) Add two patches for the "make dtbs_check" warning.
b) Seperate the "sleep control" into two functions.
   And add a "TODO" comment while sleep control fails.

v1: 
https://lore.kernel.org/linux-mediatek/20211203064027.14993-1-yong...@mediatek.com/
Base on v5.16-rc1.

Yong Wu (7):
  dt-bindings: memory: mtk-smi: Rename clock to clocks
  dt-bindings: memory: mtk-smi: No need mediatek,larb-id for mt8167
  dt-bindings: memory: mtk-smi: Correct minItems to 2 for the gals
clocks
  dt-bindings: memory: mediatek: Add mt8186 support
  memory: mtk-smi: Fix the return value for clk_bulk_prepare_enable
  memory: mtk-smi: Add sleep ctrl function
  memory: mtk-smi: mt8186: Add smi support

 .../mediatek,smi-common.yaml  | 32 ++--
 .../memory-controllers/mediatek,smi-larb.yaml | 19 +++
 drivers/memory/mtk-smi.c  | 51 ++-
 3 files changed, 75 insertions(+), 27 deletions(-)

-- 
2.18.0


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

Re: [PATCH v9 12/15] media: mtk-vcodec: enc: Remove mtk_vcodec_release_enc_pm

2022-01-13 Thread Hans Verkuil 
On 13/01/2022 11:11, AngeloGioacchino Del Regno wrote:
> Il 11/01/22 11:57, AngeloGioacchino Del Regno ha scritto:
>> Il 12/11/21 11:55, Yong Wu ha scritto:
>>> After this patchset, mtk_vcodec_release_enc_pm has only one line.
>>> then remove that function, use pm_runtime_disable instead.
>>>
>>> meanwhile, mtk_vcodec_init_enc_pm only operate for the clocks,
>>> rename it from the _pm to _clk.
>>>
>>> No functional change.
>>>
>>> CC: Tiffany Lin 
>>> CC: Irui Wang 
>>> Signed-off-by: Yong Wu 
>>
>> Reviewed-by: AngeloGioacchino Del Regno 
>> 
>>
> 
> Hello Yong,
> the mtk-vcodec patches were merged in Yunfei's vcodec patch series and Hans 
> has
> scheduled that for v5.18.
> 
> Can you please send a v10 and drop patches 10/15, 11/15, 12/15 (all of the
> media: mtk-vcodec: *) from this series?
> 
> For the records, I think that after sending v10 this series is ready to be 
> merged,
> as it was well reviewed and also tested on many MTK platforms.

Good to know. When I have the v10 I'll try to prioritize reviewing it and 
running
my usual tests.

Yong, please make sure you run 'checkpatch.pl --strict' over the v10 patches 
and fix
any issues (using common sense).

Regards,

Hans

> 
> Thank you,
> - Angelo

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

Re: [PATCH v9 12/15] media: mtk-vcodec: enc: Remove mtk_vcodec_release_enc_pm

2022-01-13 Thread AngeloGioacchino Del Regno 

Il 13/01/22 11:15, Hans Verkuil ha scritto:

On 13/01/2022 11:11, AngeloGioacchino Del Regno wrote:

Il 11/01/22 11:57, AngeloGioacchino Del Regno ha scritto:

Il 12/11/21 11:55, Yong Wu ha scritto:

After this patchset, mtk_vcodec_release_enc_pm has only one line.
then remove that function, use pm_runtime_disable instead.

meanwhile, mtk_vcodec_init_enc_pm only operate for the clocks,
rename it from the _pm to _clk.

No functional change.

CC: Tiffany Lin 
CC: Irui Wang 
Signed-off-by: Yong Wu 


Reviewed-by: AngeloGioacchino Del Regno 




Hello Yong,
the mtk-vcodec patches were merged in Yunfei's vcodec patch series and Hans has
scheduled that for v5.18.

Can you please send a v10 and drop patches 10/15, 11/15, 12/15 (all of the
media: mtk-vcodec: *) from this series?

For the records, I think that after sending v10 this series is ready to be 
merged,
as it was well reviewed and also tested on many MTK platforms.


Good to know. When I have the v10 I'll try to prioritize reviewing it and 
running
my usual tests.


Thank you Hans, that's very much appreciated!



Yong, please make sure you run 'checkpatch.pl --strict' over the v10 patches 
and fix
any issues (using common sense).

Regards,

Hans



Thank you,
- Angelo





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

Re: [PATCH v9 12/15] media: mtk-vcodec: enc: Remove mtk_vcodec_release_enc_pm

2022-01-13 Thread AngeloGioacchino Del Regno 

Il 11/01/22 11:57, AngeloGioacchino Del Regno ha scritto:

Il 12/11/21 11:55, Yong Wu ha scritto:

After this patchset, mtk_vcodec_release_enc_pm has only one line.
then remove that function, use pm_runtime_disable instead.

meanwhile, mtk_vcodec_init_enc_pm only operate for the clocks,
rename it from the _pm to _clk.

No functional change.

CC: Tiffany Lin 
CC: Irui Wang 
Signed-off-by: Yong Wu 


Reviewed-by: AngeloGioacchino Del Regno 




Hello Yong,
the mtk-vcodec patches were merged in Yunfei's vcodec patch series and Hans has
scheduled that for v5.18.

Can you please send a v10 and drop patches 10/15, 11/15, 12/15 (all of the
media: mtk-vcodec: *) from this series?

For the records, I think that after sending v10 this series is ready to be 
merged,
as it was well reviewed and also tested on many MTK platforms.

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