Re: [PATCH v5 06/27] dt-bindings: mediatek: Add binding for mt8192 IOMMU
On Mon, Feb 1, 2021 at 7:44 PM Robin Murphy wrote: > > On 2021-01-29 11:45, Tomasz Figa wrote: > > On Mon, Jan 25, 2021 at 4:34 PM Yong Wu wrote: > >> > >> On Mon, 2021-01-25 at 13:18 +0900, Tomasz Figa wrote: > >>> On Wed, Jan 20, 2021 at 4:08 PM Yong Wu wrote: > > On Wed, 2021-01-20 at 13:15 +0900, Tomasz Figa wrote: > > On Wed, Jan 13, 2021 at 3:45 PM Yong Wu wrote: > >> > >> On Wed, 2021-01-13 at 14:30 +0900, Tomasz Figa wrote: > >>> On Thu, Dec 24, 2020 at 8:35 PM Yong Wu wrote: > > On Wed, 2020-12-23 at 17:18 +0900, Tomasz Figa wrote: > > 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 > > > > Why do we preassign these addresses in DT? Shouldn't it be a user's > > or > > integrator's decision to split the 16 GB address range into > > sub-ranges > > and define which larbs those sub-ranges are shared with? > > The problem is that we can't split the 16GB range with the larb as > unit. > The example is the below ccu0(larb13 port9/10) is a independent > range(domain), the others ports in larb13 is in another domain. > > disp/vcodec/cam/mdp don't have special iova requirement, they could > access any range. vcodec also can locate 8G~12G. it don't care about > where its iova locate. here I preassign like this following with our > internal project setting. > >>> > >>> Let me try to understand this a bit more. Given the split you're > >>> proposing, is there actually any isolation enforced between particular > >>> domains? For example, if I program vcodec to with a DMA address from > >>> the 0-4G range, would the IOMMU actually generate a fault, even if > >>> disp had some memory mapped at that address? > >> > >> In this case. we will get fault in current SW setting. > >> > > > > Okay, thanks. > > > >>> > > Why set this in DT?, this is only for simplifying the code. Assume we > put it in the platform data. We have up to 32 larbs, each larb has > up to > 32 ports, each port may be in different iommu domains. we should > have a > big array for this..however we only use a macro to get the domain in > the > DT method. > > When replying this mail, I happen to see there is a > "dev->dev_range_map" > which has "dma-range" information, I think I could use this value to > get > which domain the device belong to. then no need put domid in DT. I > will > test this. > >>> > >>> My feeling is that the only part that needs to be enforced statically > >>> is the reserved IOVA range for CCUs. The other ranges should be > >>> determined dynamically, although I think I need to understand better > >>> how the hardware and your proposed design work to tell what would be > >>> likely the best choice here. > >> > >> I have removed the domid patch in v6. and get the domain id in [27/33] > >> in v6.. > >> > >> About the other ranges should be dynamical, the commit message [30/33] > >> of v6 should be helpful. the problem is that we have a bank_sel setting > >> for the iova[32:33]. currently we preassign this value. thus, all the > >> ranges are fixed. If
Re: [PATCH v5 06/27] dt-bindings: mediatek: Add binding for mt8192 IOMMU
On 2021-01-29 11:45, Tomasz Figa wrote: On Mon, Jan 25, 2021 at 4:34 PM Yong Wu wrote: On Mon, 2021-01-25 at 13:18 +0900, Tomasz Figa wrote: On Wed, Jan 20, 2021 at 4:08 PM Yong Wu wrote: On Wed, 2021-01-20 at 13:15 +0900, Tomasz Figa wrote: On Wed, Jan 13, 2021 at 3:45 PM Yong Wu wrote: On Wed, 2021-01-13 at 14:30 +0900, Tomasz Figa wrote: On Thu, Dec 24, 2020 at 8:35 PM Yong Wu wrote: On Wed, 2020-12-23 at 17:18 +0900, Tomasz Figa wrote: 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 Why do we preassign these addresses in DT? Shouldn't it be a user's or integrator's decision to split the 16 GB address range into sub-ranges and define which larbs those sub-ranges are shared with? The problem is that we can't split the 16GB range with the larb as unit. The example is the below ccu0(larb13 port9/10) is a independent range(domain), the others ports in larb13 is in another domain. disp/vcodec/cam/mdp don't have special iova requirement, they could access any range. vcodec also can locate 8G~12G. it don't care about where its iova locate. here I preassign like this following with our internal project setting. Let me try to understand this a bit more. Given the split you're proposing, is there actually any isolation enforced between particular domains? For example, if I program vcodec to with a DMA address from the 0-4G range, would the IOMMU actually generate a fault, even if disp had some memory mapped at that address? In this case. we will get fault in current SW setting. Okay, thanks. Why set this in DT?, this is only for simplifying the code. Assume we put it in the platform data. We have up to 32 larbs, each larb has up to 32 ports, each port may be in different iommu domains. we should have a big array for this..however we only use a macro to get the domain in the DT method. When replying this mail, I happen to see there is a "dev->dev_range_map" which has "dma-range" information, I think I could use this value to get which domain the device belong to. then no need put domid in DT. I will test this. My feeling is that the only part that needs to be enforced statically is the reserved IOVA range for CCUs. The other ranges should be determined dynamically, although I think I need to understand better how the hardware and your proposed design work to tell what would be likely the best choice here. I have removed the domid patch in v6. and get the domain id in [27/33] in v6.. About the other ranges should be dynamical, the commit message [30/33] of v6 should be helpful. the problem is that we have a bank_sel setting for the iova[32:33]. currently we preassign this value. thus, all the ranges are fixed. If you adjust this setting, you can let vcodec access 0~4G. Okay, so it sounds like we effectively have four 4G address spaces and we can assign the master devices to them. I guess each of these address spaces makes for an IOMMU group. Yes. Each a address spaces is an IOMMU group. It's fine to pre-assign the devices to those groups for now, but it definitely shouldn't be hardcoded in DT, because it depends on the use case of the device. I'll take a look at v6, but it sounds like it should be fine if it doesn't take the address space assignment from DT anymore. Thanks very much for your review. Hmm, I had a look at v6 and it still has the address spaces hardcoded in the DTS. sorry. I didn't get here. where do you mean. or help reply in v6. I only added the preassign list as comment in the file (dt-binding/memory/mt8192-larb-port.h). I thought our iommu consumer may need it when they use these ports. they need add dma-ranges property if its iova is over 4GB. That's exactly the problem. v6 simply replaced one way to describe the policy (domain ID) with another (dma-ranges). However, DT is not the right place to describe poli
Re: [PATCH v5 06/27] dt-bindings: mediatek: Add binding for mt8192 IOMMU
On Fri, 2021-01-29 at 20:45 +0900, Tomasz Figa wrote: > On Mon, Jan 25, 2021 at 4:34 PM Yong Wu wrote: > > > > On Mon, 2021-01-25 at 13:18 +0900, Tomasz Figa wrote: > > > On Wed, Jan 20, 2021 at 4:08 PM Yong Wu wrote: > > > > > > > > On Wed, 2021-01-20 at 13:15 +0900, Tomasz Figa wrote: > > > > > On Wed, Jan 13, 2021 at 3:45 PM Yong Wu wrote: > > > > > > > > > > > > On Wed, 2021-01-13 at 14:30 +0900, Tomasz Figa wrote: > > > > > > > On Thu, Dec 24, 2020 at 8:35 PM Yong Wu > > > > > > > wrote: > > > > > > > > > > > > > > > > On Wed, 2020-12-23 at 17:18 +0900, Tomasz Figa wrote: > > > > > > > > > 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 > > > > > > > > > > > > > > > > > > Why do we preassign these addresses in DT? Shouldn't it be a > > > > > > > > > user's or > > > > > > > > > integrator's decision to split the 16 GB address range into > > > > > > > > > sub-ranges > > > > > > > > > and define which larbs those sub-ranges are shared with? > > > > > > > > > > > > > > > > The problem is that we can't split the 16GB range with the larb > > > > > > > > as unit. > > > > > > > > The example is the below ccu0(larb13 port9/10) is a independent > > > > > > > > range(domain), the others ports in larb13 is in another domain. > > > > > > > > > > > > > > > > disp/vcodec/cam/mdp don't have special iova requirement, they > > > > > > > > could > > > > > > > > access any range. vcodec also can locate 8G~12G. it don't care > > > > > > > > about > > > > > > > > where its iova locate. here I preassign like this following > > > > > > > > with our > > > > > > > > internal project setting. > > > > > > > > > > > > > > Let me try to understand this a bit more. Given the split you're > > > > > > > proposing, is there actually any isolation enforced between > > > > > > > particular > > > > > > > domains? For example, if I program vcodec to with a DMA address > > > > > > > from > > > > > > > the 0-4G range, would the IOMMU actually generate a fault, even if > > > > > > > disp had some memory mapped at that address? > > > > > > > > > > > > In this case. we will get fault in current SW setting. > > > > > > > > > > > > > > > > Okay, thanks. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Why set this in DT?, this is only for simplifying the code. > > > > > > > > Assume we > > > > > > > > put it in the platform data. We have up to 32 larbs, each larb > > > > > > > > has up to > > > > > > > > 32 ports, each port may be in different iommu domains. we > > > > > > > > should have a > > > > > > > > big array for this..however we only use a macro to get the > > > > > > > > domain in the > > > > > > > > DT method. > > > > > > > > > > > > > > > > When replying this mail, I happen to see there is a > > > > > > > > "dev->dev_range_map" > > > > > > > > which has "dma-range" information, I think I could use this > > > > > > > > value to get > > > > > > > > which domain the device belong to. then no need put domid in > > > > > > > > DT. I will > > > > > > > > test this. > > > > > > > > > > > > > > My feeling is that the only part that needs to be enforced > > > > > > > statically > > > > > > > is the reserved IOVA range for CCUs. The other ranges should be > > > > > > > determined dynamically, al
Re: [PATCH v5 06/27] dt-bindings: mediatek: Add binding for mt8192 IOMMU
On Mon, 2021-01-25 at 13:18 +0900, Tomasz Figa wrote: > On Wed, Jan 20, 2021 at 4:08 PM Yong Wu wrote: > > > > On Wed, 2021-01-20 at 13:15 +0900, Tomasz Figa wrote: > > > On Wed, Jan 13, 2021 at 3:45 PM Yong Wu wrote: > > > > > > > > On Wed, 2021-01-13 at 14:30 +0900, Tomasz Figa wrote: > > > > > On Thu, Dec 24, 2020 at 8:35 PM Yong Wu wrote: > > > > > > > > > > > > On Wed, 2020-12-23 at 17:18 +0900, Tomasz Figa wrote: > > > > > > > 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 > > > > > > > > > > > > > > Why do we preassign these addresses in DT? Shouldn't it be a > > > > > > > user's or > > > > > > > integrator's decision to split the 16 GB address range into > > > > > > > sub-ranges > > > > > > > and define which larbs those sub-ranges are shared with? > > > > > > > > > > > > The problem is that we can't split the 16GB range with the larb as > > > > > > unit. > > > > > > The example is the below ccu0(larb13 port9/10) is a independent > > > > > > range(domain), the others ports in larb13 is in another domain. > > > > > > > > > > > > disp/vcodec/cam/mdp don't have special iova requirement, they could > > > > > > access any range. vcodec also can locate 8G~12G. it don't care about > > > > > > where its iova locate. here I preassign like this following with our > > > > > > internal project setting. > > > > > > > > > > Let me try to understand this a bit more. Given the split you're > > > > > proposing, is there actually any isolation enforced between particular > > > > > domains? For example, if I program vcodec to with a DMA address from > > > > > the 0-4G range, would the IOMMU actually generate a fault, even if > > > > > disp had some memory mapped at that address? > > > > > > > > In this case. we will get fault in current SW setting. > > > > > > > > > > Okay, thanks. > > > > > > > > > > > > > > > > > > > > Why set this in DT?, this is only for simplifying the code. Assume > > > > > > we > > > > > > put it in the platform data. We have up to 32 larbs, each larb has > > > > > > up to > > > > > > 32 ports, each port may be in different iommu domains. we should > > > > > > have a > > > > > > big array for this..however we only use a macro to get the domain > > > > > > in the > > > > > > DT method. > > > > > > > > > > > > When replying this mail, I happen to see there is a > > > > > > "dev->dev_range_map" > > > > > > which has "dma-range" information, I think I could use this value > > > > > > to get > > > > > > which domain the device belong to. then no need put domid in DT. I > > > > > > will > > > > > > test this. > > > > > > > > > > My feeling is that the only part that needs to be enforced statically > > > > > is the reserved IOVA range for CCUs. The other ranges should be > > > > > determined dynamically, although I think I need to understand better > > > > > how the hardware and your proposed design work to tell what would be > > > > > likely the best choice here. > > > > > > > > I have removed the domid patch in v6. and get the domain id in [27/33] > > > > in v6.. > > > > > > > > About the other ranges should be dynamical, the commit message [30/33] > > > > of v6 should be helpful. the problem is that we have a bank_sel setting > > > > for the iova[32:33]. currently we preassign this value. thus, all the > > > > ranges are fixed. If you adjust this setting, you can let vcodec access >
Re: [PATCH v5 06/27] dt-bindings: mediatek: Add binding for mt8192 IOMMU
On Wed, Jan 20, 2021 at 4:08 PM Yong Wu wrote: > > On Wed, 2021-01-20 at 13:15 +0900, Tomasz Figa wrote: > > On Wed, Jan 13, 2021 at 3:45 PM Yong Wu wrote: > > > > > > On Wed, 2021-01-13 at 14:30 +0900, Tomasz Figa wrote: > > > > On Thu, Dec 24, 2020 at 8:35 PM Yong Wu wrote: > > > > > > > > > > On Wed, 2020-12-23 at 17:18 +0900, Tomasz Figa wrote: > > > > > > 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 > > > > > > > > > > > > Why do we preassign these addresses in DT? Shouldn't it be a user's > > > > > > or > > > > > > integrator's decision to split the 16 GB address range into > > > > > > sub-ranges > > > > > > and define which larbs those sub-ranges are shared with? > > > > > > > > > > The problem is that we can't split the 16GB range with the larb as > > > > > unit. > > > > > The example is the below ccu0(larb13 port9/10) is a independent > > > > > range(domain), the others ports in larb13 is in another domain. > > > > > > > > > > disp/vcodec/cam/mdp don't have special iova requirement, they could > > > > > access any range. vcodec also can locate 8G~12G. it don't care about > > > > > where its iova locate. here I preassign like this following with our > > > > > internal project setting. > > > > > > > > Let me try to understand this a bit more. Given the split you're > > > > proposing, is there actually any isolation enforced between particular > > > > domains? For example, if I program vcodec to with a DMA address from > > > > the 0-4G range, would the IOMMU actually generate a fault, even if > > > > disp had some memory mapped at that address? > > > > > > In this case. we will get fault in current SW setting. > > > > > > > Okay, thanks. > > > > > > > > > > > > > > > > Why set this in DT?, this is only for simplifying the code. Assume we > > > > > put it in the platform data. We have up to 32 larbs, each larb has up > > > > > to > > > > > 32 ports, each port may be in different iommu domains. we should have > > > > > a > > > > > big array for this..however we only use a macro to get the domain in > > > > > the > > > > > DT method. > > > > > > > > > > When replying this mail, I happen to see there is a > > > > > "dev->dev_range_map" > > > > > which has "dma-range" information, I think I could use this value to > > > > > get > > > > > which domain the device belong to. then no need put domid in DT. I > > > > > will > > > > > test this. > > > > > > > > My feeling is that the only part that needs to be enforced statically > > > > is the reserved IOVA range for CCUs. The other ranges should be > > > > determined dynamically, although I think I need to understand better > > > > how the hardware and your proposed design work to tell what would be > > > > likely the best choice here. > > > > > > I have removed the domid patch in v6. and get the domain id in [27/33] > > > in v6.. > > > > > > About the other ranges should be dynamical, the commit message [30/33] > > > of v6 should be helpful. the problem is that we have a bank_sel setting > > > for the iova[32:33]. currently we preassign this value. thus, all the > > > ranges are fixed. If you adjust this setting, you can let vcodec access > > > 0~4G. > > > > Okay, so it sounds like we effectively have four 4G address spaces and > > we can assign the master devices to them. I guess each of these > > address spaces makes for an IOMMU group. > > Yes. Each a address spaces is an IOMMU group. > > > > > It's fi
Re: [PATCH v5 06/27] dt-bindings: mediatek: Add binding for mt8192 IOMMU
On Wed, 2021-01-20 at 13:15 +0900, Tomasz Figa wrote: > On Wed, Jan 13, 2021 at 3:45 PM Yong Wu wrote: > > > > On Wed, 2021-01-13 at 14:30 +0900, Tomasz Figa wrote: > > > On Thu, Dec 24, 2020 at 8:35 PM Yong Wu wrote: > > > > > > > > On Wed, 2020-12-23 at 17:18 +0900, Tomasz Figa wrote: > > > > > 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 > > > > > > > > > > Why do we preassign these addresses in DT? Shouldn't it be a user's or > > > > > integrator's decision to split the 16 GB address range into sub-ranges > > > > > and define which larbs those sub-ranges are shared with? > > > > > > > > The problem is that we can't split the 16GB range with the larb as unit. > > > > The example is the below ccu0(larb13 port9/10) is a independent > > > > range(domain), the others ports in larb13 is in another domain. > > > > > > > > disp/vcodec/cam/mdp don't have special iova requirement, they could > > > > access any range. vcodec also can locate 8G~12G. it don't care about > > > > where its iova locate. here I preassign like this following with our > > > > internal project setting. > > > > > > Let me try to understand this a bit more. Given the split you're > > > proposing, is there actually any isolation enforced between particular > > > domains? For example, if I program vcodec to with a DMA address from > > > the 0-4G range, would the IOMMU actually generate a fault, even if > > > disp had some memory mapped at that address? > > > > In this case. we will get fault in current SW setting. > > > > Okay, thanks. > > > > > > > > > > > > Why set this in DT?, this is only for simplifying the code. Assume we > > > > put it in the platform data. We have up to 32 larbs, each larb has up to > > > > 32 ports, each port may be in different iommu domains. we should have a > > > > big array for this..however we only use a macro to get the domain in the > > > > DT method. > > > > > > > > When replying this mail, I happen to see there is a "dev->dev_range_map" > > > > which has "dma-range" information, I think I could use this value to get > > > > which domain the device belong to. then no need put domid in DT. I will > > > > test this. > > > > > > My feeling is that the only part that needs to be enforced statically > > > is the reserved IOVA range for CCUs. The other ranges should be > > > determined dynamically, although I think I need to understand better > > > how the hardware and your proposed design work to tell what would be > > > likely the best choice here. > > > > I have removed the domid patch in v6. and get the domain id in [27/33] > > in v6.. > > > > About the other ranges should be dynamical, the commit message [30/33] > > of v6 should be helpful. the problem is that we have a bank_sel setting > > for the iova[32:33]. currently we preassign this value. thus, all the > > ranges are fixed. If you adjust this setting, you can let vcodec access > > 0~4G. > > Okay, so it sounds like we effectively have four 4G address spaces and > we can assign the master devices to them. I guess each of these > address spaces makes for an IOMMU group. Yes. Each a address spaces is an IOMMU group. > > It's fine to pre-assign the devices to those groups for now, but it > definitely shouldn't be hardcoded in DT, because it depends on the use > case of the device. I'll take a look at v6, but it sounds like it > should be fine if it doesn't take the address space assignment from DT > anymore. Thanks very much for your review. > > > > > Currently we have no interf
Re: [PATCH v5 06/27] dt-bindings: mediatek: Add binding for mt8192 IOMMU
On Wed, Jan 13, 2021 at 3:45 PM Yong Wu wrote: > > On Wed, 2021-01-13 at 14:30 +0900, Tomasz Figa wrote: > > On Thu, Dec 24, 2020 at 8:35 PM Yong Wu wrote: > > > > > > On Wed, 2020-12-23 at 17:18 +0900, Tomasz Figa wrote: > > > > 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 > > > > > > > > Why do we preassign these addresses in DT? Shouldn't it be a user's or > > > > integrator's decision to split the 16 GB address range into sub-ranges > > > > and define which larbs those sub-ranges are shared with? > > > > > > The problem is that we can't split the 16GB range with the larb as unit. > > > The example is the below ccu0(larb13 port9/10) is a independent > > > range(domain), the others ports in larb13 is in another domain. > > > > > > disp/vcodec/cam/mdp don't have special iova requirement, they could > > > access any range. vcodec also can locate 8G~12G. it don't care about > > > where its iova locate. here I preassign like this following with our > > > internal project setting. > > > > Let me try to understand this a bit more. Given the split you're > > proposing, is there actually any isolation enforced between particular > > domains? For example, if I program vcodec to with a DMA address from > > the 0-4G range, would the IOMMU actually generate a fault, even if > > disp had some memory mapped at that address? > > In this case. we will get fault in current SW setting. > Okay, thanks. > > > > > > > > Why set this in DT?, this is only for simplifying the code. Assume we > > > put it in the platform data. We have up to 32 larbs, each larb has up to > > > 32 ports, each port may be in different iommu domains. we should have a > > > big array for this..however we only use a macro to get the domain in the > > > DT method. > > > > > > When replying this mail, I happen to see there is a "dev->dev_range_map" > > > which has "dma-range" information, I think I could use this value to get > > > which domain the device belong to. then no need put domid in DT. I will > > > test this. > > > > My feeling is that the only part that needs to be enforced statically > > is the reserved IOVA range for CCUs. The other ranges should be > > determined dynamically, although I think I need to understand better > > how the hardware and your proposed design work to tell what would be > > likely the best choice here. > > I have removed the domid patch in v6. and get the domain id in [27/33] > in v6.. > > About the other ranges should be dynamical, the commit message [30/33] > of v6 should be helpful. the problem is that we have a bank_sel setting > for the iova[32:33]. currently we preassign this value. thus, all the > ranges are fixed. If you adjust this setting, you can let vcodec access > 0~4G. Okay, so it sounds like we effectively have four 4G address spaces and we can assign the master devices to them. I guess each of these address spaces makes for an IOMMU group. It's fine to pre-assign the devices to those groups for now, but it definitely shouldn't be hardcoded in DT, because it depends on the use case of the device. I'll take a look at v6, but it sounds like it should be fine if it doesn't take the address space assignment from DT anymore. > > Currently we have no interface to adjust this setting. Suppose we add a > new interface for this. It would be something like: > >int mtk_smi_larb_config_banksel(struct device *larb, int banksel) > >Then, all the MM drivers should call it before the HW works every > time, and its implement will be a bit complex since we aren't sure if > the larb has power at t
Re: [PATCH v5 06/27] dt-bindings: mediatek: Add binding for mt8192 IOMMU
On Wed, 2021-01-13 at 14:30 +0900, Tomasz Figa wrote: > On Thu, Dec 24, 2020 at 8:35 PM Yong Wu wrote: > > > > On Wed, 2020-12-23 at 17:18 +0900, Tomasz Figa wrote: > > > 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 > > > > > > Why do we preassign these addresses in DT? Shouldn't it be a user's or > > > integrator's decision to split the 16 GB address range into sub-ranges > > > and define which larbs those sub-ranges are shared with? > > > > The problem is that we can't split the 16GB range with the larb as unit. > > The example is the below ccu0(larb13 port9/10) is a independent > > range(domain), the others ports in larb13 is in another domain. > > > > disp/vcodec/cam/mdp don't have special iova requirement, they could > > access any range. vcodec also can locate 8G~12G. it don't care about > > where its iova locate. here I preassign like this following with our > > internal project setting. > > Let me try to understand this a bit more. Given the split you're > proposing, is there actually any isolation enforced between particular > domains? For example, if I program vcodec to with a DMA address from > the 0-4G range, would the IOMMU actually generate a fault, even if > disp had some memory mapped at that address? In this case. we will get fault in current SW setting. > > > > > Why set this in DT?, this is only for simplifying the code. Assume we > > put it in the platform data. We have up to 32 larbs, each larb has up to > > 32 ports, each port may be in different iommu domains. we should have a > > big array for this..however we only use a macro to get the domain in the > > DT method. > > > > When replying this mail, I happen to see there is a "dev->dev_range_map" > > which has "dma-range" information, I think I could use this value to get > > which domain the device belong to. then no need put domid in DT. I will > > test this. > > My feeling is that the only part that needs to be enforced statically > is the reserved IOVA range for CCUs. The other ranges should be > determined dynamically, although I think I need to understand better > how the hardware and your proposed design work to tell what would be > likely the best choice here. I have removed the domid patch in v6. and get the domain id in [27/33] in v6.. About the other ranges should be dynamical, the commit message [30/33] of v6 should be helpful. the problem is that we have a bank_sel setting for the iova[32:33]. currently we preassign this value. thus, all the ranges are fixed. If you adjust this setting, you can let vcodec access 0~4G. Currently we have no interface to adjust this setting. Suppose we add a new interface for this. It would be something like: int mtk_smi_larb_config_banksel(struct device *larb, int banksel) Then, all the MM drivers should call it before the HW works every time, and its implement will be a bit complex since we aren't sure if the larb has power at that time. the important thing is that the MM devices have already not known which larb it connects with as we plan to delete "mediatek,larb" in their dtsi nodes. In current design, the MM device don't need care about it and 4GB range is enough for them. > > Best regards, > Tomasz > > > > > Thanks. > > > > > > Best regards, > > > Tomasz > > > > > > >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
Re: [PATCH v5 06/27] dt-bindings: mediatek: Add binding for mt8192 IOMMU
On Thu, Dec 24, 2020 at 8:35 PM Yong Wu wrote: > > On Wed, 2020-12-23 at 17:18 +0900, Tomasz Figa wrote: > > 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 > > > > Why do we preassign these addresses in DT? Shouldn't it be a user's or > > integrator's decision to split the 16 GB address range into sub-ranges > > and define which larbs those sub-ranges are shared with? > > The problem is that we can't split the 16GB range with the larb as unit. > The example is the below ccu0(larb13 port9/10) is a independent > range(domain), the others ports in larb13 is in another domain. > > disp/vcodec/cam/mdp don't have special iova requirement, they could > access any range. vcodec also can locate 8G~12G. it don't care about > where its iova locate. here I preassign like this following with our > internal project setting. Let me try to understand this a bit more. Given the split you're proposing, is there actually any isolation enforced between particular domains? For example, if I program vcodec to with a DMA address from the 0-4G range, would the IOMMU actually generate a fault, even if disp had some memory mapped at that address? > > Why set this in DT?, this is only for simplifying the code. Assume we > put it in the platform data. We have up to 32 larbs, each larb has up to > 32 ports, each port may be in different iommu domains. we should have a > big array for this..however we only use a macro to get the domain in the > DT method. > > When replying this mail, I happen to see there is a "dev->dev_range_map" > which has "dma-range" information, I think I could use this value to get > which domain the device belong to. then no need put domid in DT. I will > test this. My feeling is that the only part that needs to be enforced statically is the reserved IOVA range for CCUs. The other ranges should be determined dynamically, although I think I need to understand better how the hardware and your proposed design work to tell what would be likely the best choice here. Best regards, Tomasz > > Thanks. > > > > Best regards, > > Tomasz > > > > >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 > > > > [snip]
Re: [PATCH v5 06/27] dt-bindings: mediatek: Add binding for mt8192 IOMMU
On Wed, 2020-12-23 at 17:18 +0900, Tomasz Figa wrote: > 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 > > Why do we preassign these addresses in DT? Shouldn't it be a user's or > integrator's decision to split the 16 GB address range into sub-ranges > and define which larbs those sub-ranges are shared with? The problem is that we can't split the 16GB range with the larb as unit. The example is the below ccu0(larb13 port9/10) is a independent range(domain), the others ports in larb13 is in another domain. disp/vcodec/cam/mdp don't have special iova requirement, they could access any range. vcodec also can locate 8G~12G. it don't care about where its iova locate. here I preassign like this following with our internal project setting. Why set this in DT?, this is only for simplifying the code. Assume we put it in the platform data. We have up to 32 larbs, each larb has up to 32 ports, each port may be in different iommu domains. we should have a big array for this..however we only use a macro to get the domain in the DT method. When replying this mail, I happen to see there is a "dev->dev_range_map" which has "dma-range" information, I think I could use this value to get which domain the device belong to. then no need put domid in DT. I will test this. Thanks. > > Best regards, > Tomasz > > >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 > > [snip]
Re: [PATCH v5 06/27] dt-bindings: mediatek: Add binding for mt8192 IOMMU
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 Why do we preassign these addresses in DT? Shouldn't it be a user's or integrator's decision to split the 16 GB address range into sub-ranges and define which larbs those sub-ranges are shared with? Best regards, Tomasz >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 ..ec1ac2ba7094 > --- /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 _DT_BINDINGS_MEMORY_MT8192_LARB_PORT_H_ > +#define _DT_BINDINGS_MEMORY_MT8192_LARB_PORT_H_ > + > +#include > + > +/* > + * MM IOMMU: > + * domain 0: display: larb0, larb1. > + * domain 1: vcodec: larb4, larb5, larb7. > + * domain 2: CAM/MDP: larb2, larb9, larb11, larb13, larb14, larb16, > + * larb17, larb18, larb19, larb20, > + * domain 3: CCU0: larb13 - port9/10. > + * domain 4: CCU1: larb14 - port4/5. > + * > + * larb3/6/8/10/12/15 is null. > + */ > + > +/* larb0 */ > +#define M4U_PORT_L0_DISP_POSTMASK0 MTK_M4U_DOM_ID(0, 0, 0) > +#define M4U_PORT_L0_OVL_RDMA0_HDRMTK_M4U_DOM_ID(0, 0, 1) > +#define M4U_PORT_L0_OVL_RDMA0MTK_M4U_DOM_ID(0, 0, 2) > +#define M4U_PORT_L0_DISP_RDMA0 MTK_M4U_DOM_ID(0, 0, 3) > +#define M4U_PORT_L0_DISP_WDMA0 MTK_M4U_DOM_ID(0, 0, 4) > +#define M4U_PORT_L0_DISP_FAKE0 MTK_M4U_DOM_ID(0, 0, 5) > + > +/* larb1 */ > +#define M4U_PORT_L1_OVL_2L_RDMA0_HDR MTK_M
Re: [PATCH v5 06/27] dt-bindings: mediatek: Add binding for mt8192 IOMMU
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
[PATCH v5 06/27] dt-bindings: mediatek: Add binding for mt8192 IOMMU
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 ..ec1ac2ba7094 --- /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 _DT_BINDINGS_MEMORY_MT8192_LARB_PORT_H_ +#define _DT_BINDINGS_MEMORY_MT8192_LARB_PORT_H_ + +#include + +/* + * MM IOMMU: + * domain 0: display: larb0, larb1. + * domain 1: vcodec: larb4, larb5, larb7. + * domain 2: CAM/MDP: larb2, larb9, larb11, larb13, larb14, larb16, + * larb17, larb18, larb19, larb20, + * domain 3: CCU0: larb13 - port9/10. + * domain 4: CCU1: larb14 - port4/5. + * + * larb3/6/8/10/12/15 is null. + */ + +/* larb0 */ +#define M4U_PORT_L0_DISP_POSTMASK0 MTK_M4U_DOM_ID(0, 0, 0) +#define M4U_PORT_L0_OVL_RDMA0_HDR MTK_M4U_DOM_ID(0, 0, 1) +#define M4U_PORT_L0_OVL_RDMA0 MTK_M4U_DOM_ID(0, 0, 2) +#define M4U_PORT_L0_DISP_RDMA0 MTK_M4U_DOM_ID(0, 0, 3) +#define M4U_PORT_L0_DISP_WDMA0 MTK_M4U_DOM_ID(0, 0, 4) +#define M4U_PORT_L0_DISP_FAKE0 MTK_M4U_DOM_ID(0, 0, 5) + +/* larb1 */ +#define M4U_PORT_L1_OVL_2L_RDMA0_HDR MTK_M4U_DOM_ID(0, 1, 0) +#define M4U_PORT_L1_OVL_2L_RDMA2_HDR MTK_M4U_DOM_ID(0, 1, 1) +#define M4U_PORT_L1_OVL_2L_RDMA0 MTK_M4U_DOM_ID(0, 1, 2) +#define M4U_PORT_L1_OVL_2L_RDMA2 MTK_M4U_DOM_ID(0, 1, 3) +#define M4U_PORT_L1_DISP_MDP_RDMA4 MTK_M4U_DOM_ID(0, 1, 4) +#define M4U_PORT_L1_DISP_RDMA4 MTK_M4U_DOM_ID(0, 1, 5) +#define M4U_PORT_L1_DISP_UFBC_WDMA0MTK_M4U_DOM_ID(0, 1, 6) +#define M4U_PORT_L1_DISP_FAKE1 MTK_M4U_DOM_ID(0, 1, 7) + +/* larb2 */ +#define M4U_PORT_L2_M
