RE: [PATCH 8/9] dspbridge: add map support for big buffers
>From: FUJITA Tomonori [fujita.tomon...@lab.ntt.co.jp] >Sent: Thursday, August 26, 2010 9:03 AM >To: Guzman Lugo, Fernando >Cc: fujita.tomon...@lab.ntt.co.jp; linux-omap@vger.kernel.org; >linux-ker...@vger.kernel.org; o...@wizery.com; hiroshi.d...@nokia.com; >ameya.pala...@nokia.com; >felipe.contre...@nokia.com >Subject: RE: [PATCH 8/9] dspbridge: add map support for big buffers > >On Thu, 26 Aug 2010 08:16:24 -0500 >"Guzman Lugo, Fernando" wrote: > >> >From a quick look, arch/arm/plat-omap/iovmm.c does nothing wrong about >> >scatter gather chaining. arm/arm/mm/dma-mapping.c looks fine too about >> >it. Maybe just defining ARCH_HAS_SG_CHAIN works? >> >> I can try, but it looks tricky for me. Maybe someone else can tell us why >> SG chain is not supported for ARM or if there is a problem just defining >> ARCH_HAS_SG_CHAIN. > >I suppose that nobody in ARM has been interested in the feature. It >was invented to improve I/O performance with large I/O requests. No >wonder embeded people aren't interested in it. > >fuj...@rose:~/git/linux-2.6$ find arch -name 'scatterlist.h'|xargs grep HAS_SG >arch/x86/include/asm/scatterlist.h:#define ARCH_HAS_SG_CHAIN >arch/ia64/include/asm/scatterlist.h:#define ARCH_HAS_SG_CHAIN >arch/sparc/include/asm/scatterlist.h:#define ARCH_HAS_SG_CHAIN >arch/powerpc/include/asm/scatterlist.h:#define ARCH_HAS_SG_CHAIN Ok, so let me try SG chain, that should be the correct fix. Thanks a lot, Fernando. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 8/9] dspbridge: add map support for big buffers
On Thu, 26 Aug 2010 08:16:24 -0500 "Guzman Lugo, Fernando" wrote: > >From a quick look, arch/arm/plat-omap/iovmm.c does nothing wrong about > >scatter gather chaining. arm/arm/mm/dma-mapping.c looks fine too about > >it. Maybe just defining ARCH_HAS_SG_CHAIN works? > > I can try, but it looks tricky for me. Maybe someone else can tell us why > SG chain is not supported for ARM or if there is a problem just defining > ARCH_HAS_SG_CHAIN. I suppose that nobody in ARM has been interested in the feature. It was invented to improve I/O performance with large I/O requests. No wonder embeded people aren't interested in it. fuj...@rose:~/git/linux-2.6$ find arch -name 'scatterlist.h'|xargs grep HAS_SG arch/x86/include/asm/scatterlist.h:#define ARCH_HAS_SG_CHAIN arch/ia64/include/asm/scatterlist.h:#define ARCH_HAS_SG_CHAIN arch/sparc/include/asm/scatterlist.h:#define ARCH_HAS_SG_CHAIN arch/powerpc/include/asm/scatterlist.h:#define ARCH_HAS_SG_CHAIN -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 8/9] dspbridge: add map support for big buffers
> >From: FUJITA Tomonori [fujita.tomon...@lab.ntt.co.jp] >Sent: Thursday, August 26, 2010 7:56 AM >To: Guzman Lugo, Fernando >Cc: fujita.tomon...@lab.ntt.co.jp; linux-omap@vger.kernel.org; >linux-ker...@vger.kernel.org; o...@wizery.com; hiroshi.d...@nokia.com; >ameya.pala...@nokia.com; >felipe.contre...@nokia.com >Subject: RE: [PATCH 8/9] dspbridge: add map support for big buffers > >On Thu, 26 Aug 2010 07:38:26 -0500 >"Guzman Lugo, Fernando" wrote: > >> >> due to a restriction in scatter gather lists, it can >> >> not be created a list for a buffer bigger than 1MB. >> >> This patch is spliting big mappings into 1MB mappings. >> > >> >I don't read the whole thread but the above description is incorrect. >> > >> >Why can't you use scatter gather chaining? You can create a scatter >> >list for a buffer larger than 1MB. >> >> The thing is that ARM architecture does not support SG chaining. This patch >> should be >> seen like a workaround until it is fixed in iovmm module. > >Fix iovmm module is easier than the workaround? I have not thought about possible fixes inside iovmm, but now I am reviewing the patches I will figure out how to fix this inside iovmm. Since he workaround still can fail to allocate big buffers even though there is space to allocate it. > >From a quick look, arch/arm/plat-omap/iovmm.c does nothing wrong about >scatter gather chaining. arm/arm/mm/dma-mapping.c looks fine too about >it. Maybe just defining ARCH_HAS_SG_CHAIN works? I can try, but it looks tricky for me. Maybe someone else can tell us why SG chain is not supported for ARM or if there is a problem just defining ARCH_HAS_SG_CHAIN. Regards, Fernando. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 8/9] dspbridge: add map support for big buffers
> >From: Felipe Contreras [felipe.contre...@gmail.com] >Sent: Thursday, August 26, 2010 5:04 AM >To: Guzman Lugo, Fernando >Cc: Kanigeri, Hari; linux-omap@vger.kernel.org; linux-ker...@vger.kernel.org; >o...@wizery.com; hiroshi.d...@nokia.com; ameya.pala...@nokia.com; >>felipe.contre...@nokia.com >Subject: Re: [PATCH 8/9] dspbridge: add map support for big buffers > >On Wed, Aug 25, 2010 at 10:42 PM, Guzman Lugo, Fernando > wrote: >>> On Wed, Aug 25, 2010 at 7:00 PM, Guzman Lugo, Fernando >>> wrote: >>> >> Or the whole iovmm.c can be copied and just remove the mapping. >>> > >>> > That is the migration patches do, remove custom bridge >>> mapping and use >>> > iovmm module instead. >>> >>> You didn't get me; copy the iovmm.c code into dmm.c, and >>> remove the mapping. >> >> It sounds like double work, changing the dmm.c which will disappear. > >But in the meantime the bug is still there, and there's no timeline >when it will disappear. I think you are talking about the issue when there are a lot of reservations and unreservations of big buffer and the memory is getting fragmented and it is not possible to allocate more big buffers. if so, I don't think it is a bug. The thing is because of the algorithm used for reserve memory is optimized to satisfy the memory requested as soon as possible, so this algorithm is good where there are too much reservation of memory and for small buffers, because the algorithm get rid of big free chucks of memory soon. so that issue, can be fixed just chaning the algorithm without changing the array implementation in dmm.c. > >> Also I think what you want is only the change from array to >> Linked list. > >That's what I said. > >> Otherwise copying iovmm.c into dmm.c and adapting >> To how dspbridge is at this momment it will need too much changes, > >Yeah, I just said that it was possible. > >> It is better to think like: take memory reservation (linked list) >> Implementation from iovmm and map it to dmm.c. > >I think so too. > >> But I don't see the point of doing that, if dmm.c is about to >> Dissapear. > >When exactly? with iommu migration patches, hopefully next week. Regards, Fernando. > >-- >Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 8/9] dspbridge: add map support for big buffers
On Thu, 26 Aug 2010 07:38:26 -0500 "Guzman Lugo, Fernando" wrote: > >> due to a restriction in scatter gather lists, it can > >> not be created a list for a buffer bigger than 1MB. > >> This patch is spliting big mappings into 1MB mappings. > > > >I don't read the whole thread but the above description is incorrect. > > > >Why can't you use scatter gather chaining? You can create a scatter > >list for a buffer larger than 1MB. > > The thing is that ARM architecture does not support SG chaining. This patch > should be > seen like a workaround until it is fixed in iovmm module. Fix iovmm module is easier than the workaround? >From a quick look, arch/arm/plat-omap/iovmm.c does nothing wrong about scatter gather chaining. arm/arm/mm/dma-mapping.c looks fine too about it. Maybe just defining ARCH_HAS_SG_CHAIN works? -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 8/9] dspbridge: add map support for big buffers
Hi Fujita, >From: FUJITA Tomonori [fujita.tomon...@lab.ntt.co.jp] >Sent: Thursday, August 26, 2010 1:55 AM >To: Guzman Lugo, Fernando >Cc: linux-omap@vger.kernel.org; linux-ker...@vger.kernel.org; o...@wizery.com; >hiroshi.d...@nokia.com; ameya.pala...@nokia.com; felipe.contre...@nokia.com >Subject: Re: [PATCH 8/9] dspbridge: add map support for big buffers > >On Wed, 30 Jun 2010 19:20:59 -0500 >Fernando Guzman Lugo wrote: > >> due to a restriction in scatter gather lists, it can >> not be created a list for a buffer bigger than 1MB. >> This patch is spliting big mappings into 1MB mappings. > >I don't read the whole thread but the above description is incorrect. > >Why can't you use scatter gather chaining? You can create a scatter >list for a buffer larger than 1MB. The thing is that ARM architecture does not support SG chaining. This patch should be seen like a workaround until it is fixed in iovmm module. Thanks and regards, Fernando. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 8/9] dspbridge: add map support for big buffers
On Wed, Aug 25, 2010 at 10:42 PM, Guzman Lugo, Fernando wrote: >> On Wed, Aug 25, 2010 at 7:00 PM, Guzman Lugo, Fernando >> wrote: >> >> Or the whole iovmm.c can be copied and just remove the mapping. >> > >> > That is the migration patches do, remove custom bridge >> mapping and use >> > iovmm module instead. >> >> You didn't get me; copy the iovmm.c code into dmm.c, and >> remove the mapping. > > It sounds like double work, changing the dmm.c which will disappear. But in the meantime the bug is still there, and there's no timeline when it will disappear. > Also I think what you want is only the change from array to > Linked list. That's what I said. > Otherwise copying iovmm.c into dmm.c and adapting > To how dspbridge is at this momment it will need too much changes, Yeah, I just said that it was possible. > It is better to think like: take memory reservation (linked list) > Implementation from iovmm and map it to dmm.c. I think so too. > But I don't see the point of doing that, if dmm.c is about to > Dissapear. When exactly? -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 8/9] dspbridge: add map support for big buffers
On Wed, 30 Jun 2010 19:20:59 -0500 Fernando Guzman Lugo wrote: > due to a restriction in scatter gather lists, it can > not be created a list for a buffer bigger than 1MB. > This patch is spliting big mappings into 1MB mappings. I don't read the whole thread but the above description is incorrect. Why can't you use scatter gather chaining? You can create a scatter list for a buffer larger than 1MB. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 8/9] dspbridge: add map support for big buffers
> -Original Message- > From: Felipe Contreras [mailto:felipe.contre...@gmail.com] > Sent: Wednesday, August 25, 2010 2:18 PM > To: Guzman Lugo, Fernando > Cc: Kanigeri, Hari; linux-omap@vger.kernel.org; > linux-ker...@vger.kernel.org; o...@wizery.com; > hiroshi.d...@nokia.com; ameya.pala...@nokia.com; > felipe.contre...@nokia.com > Subject: Re: [PATCH 8/9] dspbridge: add map support for big buffers > > On Wed, Aug 25, 2010 at 7:00 PM, Guzman Lugo, Fernando > wrote: > >> Or the whole iovmm.c can be copied and just remove the mapping. > > > > That is the migration patches do, remove custom bridge > mapping and use > > iovmm module instead. > > You didn't get me; copy the iovmm.c code into dmm.c, and > remove the mapping. It sounds like double work, changing the dmm.c which will disappear. Also I think what you want is only the change from array to Linked list. Otherwise copying iovmm.c into dmm.c and adapting To how dspbridge is at this momment it will need too much changes, It is better to think like: take memory reservation (linked list) Implementation from iovmm and map it to dmm.c. But I don't see the point of doing that, if dmm.c is about to Dissapear. Regards, Fernando. > > -- > Felipe Contreras > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 8/9] dspbridge: add map support for big buffers
On Wed, Aug 25, 2010 at 7:00 PM, Guzman Lugo, Fernando wrote: >> Or the whole iovmm.c can be copied and just remove the mapping. > > That is the migration patches do, remove custom bridge mapping and > use iovmm module instead. You didn't get me; copy the iovmm.c code into dmm.c, and remove the mapping. -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 8/9] dspbridge: add map support for big buffers
> -Original Message- > From: Felipe Contreras [mailto:felipe.contre...@gmail.com] > Sent: Wednesday, August 25, 2010 1:06 AM > To: Guzman Lugo, Fernando > Cc: Kanigeri, Hari; linux-omap@vger.kernel.org; > linux-ker...@vger.kernel.org; o...@wizery.com; > hiroshi.d...@nokia.com; ameya.pala...@nokia.com; > felipe.contre...@nokia.com > Subject: Re: [PATCH 8/9] dspbridge: add map support for big buffers > > On Wed, Aug 25, 2010 at 12:55 AM, Guzman Lugo, Fernando > wrote: > >> However, from what I can see iovmm can be used instead of > dmm even if > >> the switch to iommu is not yet there. > > > > Iovmm have a list of memory used (reserved, that is what dmm module > > does) and also maps the buffer, So we can not use iovmm without > > removing The mapping which is done inside dspbridge because it will > > conflic with The mapping doing inside iovmm module. So that > means for > > using iovmm, the Mapping in dspbridge had to be removed in > order to work properly. > > Or the whole iovmm.c can be copied and just remove the mapping. That is the migration patches do, remove custom bridge mapping and use iovmm module instead. Regards, Fernando. > > -- > Felipe Contreras > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 8/9] dspbridge: add map support for big buffers
On Wed, Aug 25, 2010 at 12:55 AM, Guzman Lugo, Fernando wrote: >> However, from what I can see iovmm can be used instead of dmm >> even if the switch to iommu is not yet there. > > Iovmm have a list of memory used (reserved, that is what dmm module > does) and also maps the buffer, So we can not use iovmm without removing > The mapping which is done inside dspbridge because it will conflic with > The mapping doing inside iovmm module. So that means for using iovmm, the > Mapping in dspbridge had to be removed in order to work properly. Or the whole iovmm.c can be copied and just remove the mapping. -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 8/9] dspbridge: add map support for big buffers
> -Original Message- > From: Felipe Contreras [mailto:felipe.contre...@gmail.com] > Sent: Tuesday, August 24, 2010 4:18 PM > To: Guzman Lugo, Fernando > Cc: Kanigeri, Hari; linux-omap@vger.kernel.org; > linux-ker...@vger.kernel.org; o...@wizery.com; > hiroshi.d...@nokia.com; ameya.pala...@nokia.com; > felipe.contre...@nokia.com > Subject: Re: [PATCH 8/9] dspbridge: add map support for big buffers > > On Tue, Aug 24, 2010 at 10:30 PM, Guzman Lugo, Fernando > wrote: > >> Oh, I actually meant the DMM pool. > >> > >> a) 1. Migrate to iommu, 2. Remove DMM completely > >> b) 1. Remove DMM pool, 2. Migrate to iommu 3. Remove DMM completely > > > > Ok, what is the issue with DMM pool? > > From what I've heard; fragmentation. > > > The issue I see removing DMM pool in this moment and making all the > > DMM Available (from 0x1100 to 0x omap3 case) that is: > > > > The DMM module allocates a list of "struct map_page" > elements base on > > DMM_POOL_SIZE to keep track of memory reserved and mapped. > > > > Memory allocated = DMM_POOL_SIZE / PAGE_SIZE * sizeof(struct > > map_page); > > > > So making all memory avalible it will increase the memory > used for DMM > > Module and it could be quite significant. > > > > Iovmm.c module, the list is increased dynamically when it > is needed so > > It does no have that problem. Then when the migration is done and > > Iovmm.c module is used the DMM_POOL_SIZE can be removed > without issues. > > It seems that this "memory allocated" you are taking about is > an array, but what we would like is a list, like apparently > iovmm is using. I think I can give that a try if needed. Yes, that is an array in dmm and a liked list in iovmm. > > However, from what I can see iovmm can be used instead of dmm > even if the switch to iommu is not yet there. Iovmm have a list of memory used (reserved, that is what dmm module does) and also maps the buffer, So we can not use iovmm without removing The mapping which is done inside dspbridge because it will conflic with The mapping doing inside iovmm module. So that means for using iovmm, the Mapping in dspbridge had to be removed in order to work properly. Regards, Fernando. > > -- > Felipe Contreras > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 8/9] dspbridge: add map support for big buffers
On Tue, Aug 24, 2010 at 10:30 PM, Guzman Lugo, Fernando wrote: >> Oh, I actually meant the DMM pool. >> >> a) 1. Migrate to iommu, 2. Remove DMM completely >> b) 1. Remove DMM pool, 2. Migrate to iommu 3. Remove DMM completely > > Ok, what is the issue with DMM pool? >From what I've heard; fragmentation. > The issue I see removing DMM pool in this moment and making all the DMM > Available (from 0x1100 to 0x omap3 case) that is: > > The DMM module allocates a list of "struct map_page" elements base on > DMM_POOL_SIZE to keep track of memory reserved and mapped. > > Memory allocated = DMM_POOL_SIZE / PAGE_SIZE * sizeof(struct map_page); > > So making all memory avalible it will increase the memory used for DMM > Module and it could be quite significant. > > Iovmm.c module, the list is increased dynamically when it is needed so > It does no have that problem. Then when the migration is done and > Iovmm.c module is used the DMM_POOL_SIZE can be removed without issues. It seems that this "memory allocated" you are taking about is an array, but what we would like is a list, like apparently iovmm is using. I think I can give that a try if needed. However, from what I can see iovmm can be used instead of dmm even if the switch to iommu is not yet there. -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 8/9] dspbridge: add map support for big buffers
> -Original Message- > From: Felipe Contreras [mailto:felipe.contre...@gmail.com] > Sent: Tuesday, August 24, 2010 2:14 PM > To: Guzman Lugo, Fernando > Cc: Kanigeri, Hari; linux-omap@vger.kernel.org; > linux-ker...@vger.kernel.org; o...@wizery.com; > hiroshi.d...@nokia.com; ameya.pala...@nokia.com; > felipe.contre...@nokia.com > Subject: Re: [PATCH 8/9] dspbridge: add map support for big buffers > > On Tue, Aug 24, 2010 at 10:05 PM, Guzman Lugo, Fernando > wrote: > >> I've heard there are some problems regarding DMM, and > since you say > >> you have already done the changes, and since iommu > migration is not > >> yet ready AFAIK, it might make sense to go for option b). > >> > >> Anyway, thanks for the clarification :) > > > > But DMM is used in this momment, it is after the IOMMU > migration When > > DMM is not needed anymore. So we need to go for option a). > > Oh, I actually meant the DMM pool. > > a) 1. Migrate to iommu, 2. Remove DMM completely > b) 1. Remove DMM pool, 2. Migrate to iommu 3. Remove DMM completely Ok, what is the issue with DMM pool? The issue I see removing DMM pool in this moment and making all the DMM Available (from 0x1100 to 0x omap3 case) that is: The DMM module allocates a list of "struct map_page" elements base on DMM_POOL_SIZE to keep track of memory reserved and mapped. Memory allocated = DMM_POOL_SIZE / PAGE_SIZE * sizeof(struct map_page); So making all memory avalible it will increase the memory used for DMM Module and it could be quite significant. Iovmm.c module, the list is increased dynamically when it is needed so It does no have that problem. Then when the migration is done and Iovmm.c module is used the DMM_POOL_SIZE can be removed without issues. Regards, Fernando. > > -- > Felipe Contreras > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 8/9] dspbridge: add map support for big buffers
On Tue, Aug 24, 2010 at 10:05 PM, Guzman Lugo, Fernando wrote: >> I've heard there are some problems regarding DMM, and since >> you say you have already done the changes, and since iommu >> migration is not yet ready AFAIK, it might make sense to go >> for option b). >> >> Anyway, thanks for the clarification :) > > But DMM is used in this momment, it is after the IOMMU migration > When DMM is not needed anymore. So we need to go for option a). Oh, I actually meant the DMM pool. a) 1. Migrate to iommu, 2. Remove DMM completely b) 1. Remove DMM pool, 2. Migrate to iommu 3. Remove DMM completely -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 8/9] dspbridge: add map support for big buffers
> -Original Message- > From: Felipe Contreras [mailto:felipe.contre...@gmail.com] > Sent: Tuesday, August 24, 2010 1:55 PM > To: Guzman Lugo, Fernando > Cc: Kanigeri, Hari; linux-omap@vger.kernel.org; > linux-ker...@vger.kernel.org; o...@wizery.com; > hiroshi.d...@nokia.com; ameya.pala...@nokia.com; > felipe.contre...@nokia.com > Subject: Re: [PATCH 8/9] dspbridge: add map support for big buffers > > On Tue, Aug 24, 2010 at 9:44 PM, Guzman Lugo, Fernando > wrote: > >> However, I still have the question about the dependency on iommu; > >> AFAICS the DMM removal doesn't depend on the migration to iommu, > >> which AFAIK has been stalled for some time. > > > > Yeah, DMM removal does not depend on iommu migration. > However, After > > the changes for iommu migration the DMM module is not > Needed anymore, > > so it is better to remove it too. > > Yes, but there are two options: > > a) 1. Migrate to iommu, 2. Remove DMM > > or: > > b) 1. Remove DMM, 2. Migrate to iommu > > I've heard there are some problems regarding DMM, and since > you say you have already done the changes, and since iommu > migration is not yet ready AFAIK, it might make sense to go > for option b). > > Anyway, thanks for the clarification :) But DMM is used in this momment, it is after the IOMMU migration When DMM is not needed anymore. So we need to go for option a). Regards, Fernando. > > -- > Felipe Contreras > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 8/9] dspbridge: add map support for big buffers
On Tue, Aug 24, 2010 at 9:44 PM, Guzman Lugo, Fernando wrote: >> However, I still have the question about the dependency on >> iommu; AFAICS the DMM removal doesn't depend on the migration >> to iommu, which AFAIK has been stalled for some time. > > Yeah, DMM removal does not depend on iommu migration. However, > After the changes for iommu migration the DMM module is not > Needed anymore, so it is better to remove it too. Yes, but there are two options: a) 1. Migrate to iommu, 2. Remove DMM or: b) 1. Remove DMM, 2. Migrate to iommu I've heard there are some problems regarding DMM, and since you say you have already done the changes, and since iommu migration is not yet ready AFAIK, it might make sense to go for option b). Anyway, thanks for the clarification :) -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 8/9] dspbridge: add map support for big buffers
> -Original Message- > From: Felipe Contreras [mailto:felipe.contre...@gmail.com] > Sent: Tuesday, August 24, 2010 12:46 PM > To: Guzman Lugo, Fernando > Cc: Kanigeri, Hari; linux-omap@vger.kernel.org; > linux-ker...@vger.kernel.org; o...@wizery.com; > hiroshi.d...@nokia.com; ameya.pala...@nokia.com; > felipe.contre...@nokia.com > Subject: Re: [PATCH 8/9] dspbridge: add map support for big buffers > > On Tue, Aug 24, 2010 at 7:31 PM, Guzman Lugo, Fernando > wrote: > > > > > >> -Original Message- > >> From: Felipe Contreras [mailto:felipe.contre...@gmail.com] > >> Sent: Tuesday, August 24, 2010 5:09 AM > >> To: Guzman Lugo, Fernando > >> Cc: Kanigeri, Hari; linux-omap@vger.kernel.org; > >> linux-ker...@vger.kernel.org; o...@wizery.com; > >> hiroshi.d...@nokia.com; ameya.pala...@nokia.com; > >> felipe.contre...@nokia.com > >> Subject: Re: [PATCH 8/9] dspbridge: add map support for big buffers > >> > >> On Fri, Jul 2, 2010 at 9:39 PM, Guzman Lugo, Fernando > >> wrote: > >> > I think, it would be good if we get rid of DMMPOOL size, if > >> the liked list grow up as it is needed, there is no memory > penalty of > >> have all the possible iommu addresses valid (1100 - ). > >> The reservation will only fail when there is no memory. If > a software > >> restriction is needed we could define a start and end > addresses for > >> iommu module (maybe as a parameter when the iommu handle > for iva2 is > >> got) and that boundaries can be taking in account at the moment of > >> reserve the memory. > >> > >> What happened to this? > >> > >> IIUC what you are proposing is to remove the DMM pool completely, > >> that makes sense to me. However, is it really needed to finish the > >> iommu migration to do this? > >> > >> > I think the reserve/unreserved dspbridge api can disappear > >> and just return the da address in the map function. > >> > >> This is something I've proposed before, so I agree :) > > > > Yeah, that is how it will be. I have been busy with other > stuffs, but > > now I have finish a version with all dmm module removed and > > reserve/unreserve Api removed as well. But because a the big # of > > patches merge in dspbrdge I have to rebase them to the > latest, I hope > > finish this week and send Them again next week. > > Awesome :) > > However, I still have the question about the dependency on > iommu; AFAICS the DMM removal doesn't depend on the migration > to iommu, which AFAIK has been stalled for some time. Yeah, DMM removal does not depend on iommu migration. However, After the changes for iommu migration the DMM module is not Needed anymore, so it is better to remove it too. Regards, Fernando. > > -- > Felipe Contreras > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 8/9] dspbridge: add map support for big buffers
On Tue, Aug 24, 2010 at 7:31 PM, Guzman Lugo, Fernando wrote: > > >> -Original Message- >> From: Felipe Contreras [mailto:felipe.contre...@gmail.com] >> Sent: Tuesday, August 24, 2010 5:09 AM >> To: Guzman Lugo, Fernando >> Cc: Kanigeri, Hari; linux-omap@vger.kernel.org; >> linux-ker...@vger.kernel.org; o...@wizery.com; >> hiroshi.d...@nokia.com; ameya.pala...@nokia.com; >> felipe.contre...@nokia.com >> Subject: Re: [PATCH 8/9] dspbridge: add map support for big buffers >> >> On Fri, Jul 2, 2010 at 9:39 PM, Guzman Lugo, Fernando >> wrote: >> > I think, it would be good if we get rid of DMMPOOL size, if >> the liked list grow up as it is needed, there is no memory >> penalty of have all the possible iommu addresses valid >> (1100 - ). The reservation will only fail when >> there is no memory. If a software restriction is needed we >> could define a start and end addresses for iommu module >> (maybe as a parameter when the iommu handle for iva2 is got) >> and that boundaries can be taking in account at the moment of >> reserve the memory. >> >> What happened to this? >> >> IIUC what you are proposing is to remove the DMM pool >> completely, that makes sense to me. However, is it really >> needed to finish the iommu migration to do this? >> >> > I think the reserve/unreserved dspbridge api can disappear >> and just return the da address in the map function. >> >> This is something I've proposed before, so I agree :) > > Yeah, that is how it will be. I have been busy with other stuffs, but now > I have finish a version with all dmm module removed and reserve/unreserve > Api removed as well. But because a the big # of patches merge in dspbrdge > I have to rebase them to the latest, I hope finish this week and send > Them again next week. Awesome :) However, I still have the question about the dependency on iommu; AFAICS the DMM removal doesn't depend on the migration to iommu, which AFAIK has been stalled for some time. -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 8/9] dspbridge: add map support for big buffers
> -Original Message- > From: Felipe Contreras [mailto:felipe.contre...@gmail.com] > Sent: Tuesday, August 24, 2010 5:09 AM > To: Guzman Lugo, Fernando > Cc: Kanigeri, Hari; linux-omap@vger.kernel.org; > linux-ker...@vger.kernel.org; o...@wizery.com; > hiroshi.d...@nokia.com; ameya.pala...@nokia.com; > felipe.contre...@nokia.com > Subject: Re: [PATCH 8/9] dspbridge: add map support for big buffers > > On Fri, Jul 2, 2010 at 9:39 PM, Guzman Lugo, Fernando > wrote: > > I think, it would be good if we get rid of DMMPOOL size, if > the liked list grow up as it is needed, there is no memory > penalty of have all the possible iommu addresses valid > (1100 - ). The reservation will only fail when > there is no memory. If a software restriction is needed we > could define a start and end addresses for iommu module > (maybe as a parameter when the iommu handle for iva2 is got) > and that boundaries can be taking in account at the moment of > reserve the memory. > > What happened to this? > > IIUC what you are proposing is to remove the DMM pool > completely, that makes sense to me. However, is it really > needed to finish the iommu migration to do this? > > > I think the reserve/unreserved dspbridge api can disappear > and just return the da address in the map function. > > This is something I've proposed before, so I agree :) Yeah, that is how it will be. I have been busy with other stuffs, but now I have finish a version with all dmm module removed and reserve/unreserve Api removed as well. But because a the big # of patches merge in dspbrdge I have to rebase them to the latest, I hope finish this week and send Them again next week. Regards, Fernando. > > -- > Felipe Contreras > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 8/9] dspbridge: add map support for big buffers
On Fri, Jul 2, 2010 at 9:39 PM, Guzman Lugo, Fernando wrote: > I think, it would be good if we get rid of DMMPOOL size, if the liked list > grow up as it is needed, there is no memory penalty of have all the possible > iommu addresses valid (1100 - ). The reservation will only fail > when there is no memory. If a software restriction is needed we could define > a start and end addresses for iommu module (maybe as a parameter when the > iommu handle for iva2 is got) and that boundaries can be taking in account at > the moment of reserve the memory. What happened to this? IIUC what you are proposing is to remove the DMM pool completely, that makes sense to me. However, is it really needed to finish the iommu migration to do this? > I think the reserve/unreserved dspbridge api can disappear and just return > the da address in the map function. This is something I've proposed before, so I agree :) -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 8/9] dspbridge: add map support for big buffers
Hi Hari, > -Original Message- > From: Kanigeri, Hari > Sent: Friday, July 02, 2010 12:03 PM > To: Guzman Lugo, Fernando; linux-omap@vger.kernel.org; linux- > ker...@vger.kernel.org > Cc: o...@wizery.com; hiroshi.d...@nokia.com; ameya.pala...@nokia.com; > felipe.contre...@nokia.com > Subject: RE: [PATCH 8/9] dspbridge: add map support for big buffers > > Fernando, > > > -Original Message- > > From: Guzman Lugo, Fernando > > Sent: Friday, July 02, 2010 11:27 AM > > To: Kanigeri, Hari; linux-omap@vger.kernel.org; linux- > > ker...@vger.kernel.org > > Cc: o...@wizery.com; hiroshi.d...@nokia.com; ameya.pala...@nokia.com; > > felipe.contre...@nokia.com > > Subject: RE: [PATCH 8/9] dspbridge: add map support for big buffers > > > > > > > > Hi Hari, > > > > > -Original Message- > > > From: Kanigeri, Hari > > > Sent: Thursday, July 01, 2010 6:36 PM > > > To: Guzman Lugo, Fernando; linux-omap@vger.kernel.org; linux- > > > ker...@vger.kernel.org > > > Cc: o...@wizery.com; hiroshi.d...@nokia.com; ameya.pala...@nokia.com; > > > felipe.contre...@nokia.com; Guzman Lugo, Fernando > > > Subject: RE: [PATCH 8/9] dspbridge: add map support for big buffers > > > > > > Fernando, > > > > > > > - for_each_sg(sgt->sgl, sg, sgt->nents, i) > > > > - sg_set_page(sg, usr_pgs[i], PAGE_SIZE, 0); > > > > + da = iommu_vmap(mmu, da, sgt, IOVMF_ENDIAN_LITTLE | > > > > + IOVMF_ELSZ_32); > > > > > > -- iommu_vmap does the Kernel mapping to the buffers you are mapping > to > > > DSP MMU. Why do you need Kernel mappings ? > > > > > > If there is no benefit in maintaining Kernel mapping I would rather > call > > > iopgtable_store_entry directly to map the entries. > > > > Where inside iommu_vmap is the mapping done? > > -- The mapping is done to track down the Device mappings. But since you > already have it in dmm.c this is kind of redundant right now, and we might > see performance impact due to this. > > I think it might be good to transition to iovmm when we phase out dmm.c. it could be a good time now, I think. > Few things to take into account transitioning to iovmm approach: > - DSPBridge used to have linked list approach to track down the > mapped entries and profiling showed it took considerable amount of > traversing through the list. Jeff Taylor's algorithm in dmm.c helped to > reduce this impact. That can be implemented in the iovmmu without too many changes, right? > - How would you manage the Device virtual pool moving to iovmm ? And > how about the reservation ? I think, it would be good if we get rid of DMMPOOL size, if the liked list grow up as it is needed, there is no memory penalty of have all the possible iommu addresses valid (1100 - ). The reservation will only fail when there is no memory. If a software restriction is needed we could define a start and end addresses for iommu module (maybe as a parameter when the iommu handle for iva2 is got) and that boundaries can be taking in account at the moment of reserve the memory. I think the reserve/unreserved dspbridge api can disappear and just return the da address in the map function. Please let me know what you think. Thanks for the comments, Fernando. > > Thank you, > Best regards, > Hari -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 8/9] dspbridge: add map support for big buffers
Fernando, > -Original Message- > From: Guzman Lugo, Fernando > Sent: Friday, July 02, 2010 11:27 AM > To: Kanigeri, Hari; linux-omap@vger.kernel.org; linux- > ker...@vger.kernel.org > Cc: o...@wizery.com; hiroshi.d...@nokia.com; ameya.pala...@nokia.com; > felipe.contre...@nokia.com > Subject: RE: [PATCH 8/9] dspbridge: add map support for big buffers > > > > Hi Hari, > > > -Original Message- > > From: Kanigeri, Hari > > Sent: Thursday, July 01, 2010 6:36 PM > > To: Guzman Lugo, Fernando; linux-omap@vger.kernel.org; linux- > > ker...@vger.kernel.org > > Cc: o...@wizery.com; hiroshi.d...@nokia.com; ameya.pala...@nokia.com; > > felipe.contre...@nokia.com; Guzman Lugo, Fernando > > Subject: RE: [PATCH 8/9] dspbridge: add map support for big buffers > > > > Fernando, > > > > > - for_each_sg(sgt->sgl, sg, sgt->nents, i) > > > - sg_set_page(sg, usr_pgs[i], PAGE_SIZE, 0); > > > + da = iommu_vmap(mmu, da, sgt, IOVMF_ENDIAN_LITTLE | > > > + IOVMF_ELSZ_32); > > > > -- iommu_vmap does the Kernel mapping to the buffers you are mapping to > > DSP MMU. Why do you need Kernel mappings ? > > > > If there is no benefit in maintaining Kernel mapping I would rather call > > iopgtable_store_entry directly to map the entries. > > Where inside iommu_vmap is the mapping done? -- The mapping is done to track down the Device mappings. But since you already have it in dmm.c this is kind of redundant right now, and we might see performance impact due to this. I think it might be good to transition to iovmm when we phase out dmm.c. Few things to take into account transitioning to iovmm approach: - DSPBridge used to have linked list approach to track down the mapped entries and profiling showed it took considerable amount of traversing through the list. Jeff Taylor's algorithm in dmm.c helped to reduce this impact. - How would you manage the Device virtual pool moving to iovmm ? And how about the reservation ? Thank you, Best regards, Hari -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 8/9] dspbridge: add map support for big buffers
Hi Hari, > -Original Message- > From: Kanigeri, Hari > Sent: Thursday, July 01, 2010 6:36 PM > To: Guzman Lugo, Fernando; linux-omap@vger.kernel.org; linux- > ker...@vger.kernel.org > Cc: o...@wizery.com; hiroshi.d...@nokia.com; ameya.pala...@nokia.com; > felipe.contre...@nokia.com; Guzman Lugo, Fernando > Subject: RE: [PATCH 8/9] dspbridge: add map support for big buffers > > Fernando, > > > - for_each_sg(sgt->sgl, sg, sgt->nents, i) > > - sg_set_page(sg, usr_pgs[i], PAGE_SIZE, 0); > > + da = iommu_vmap(mmu, da, sgt, IOVMF_ENDIAN_LITTLE | > > + IOVMF_ELSZ_32); > > -- iommu_vmap does the Kernel mapping to the buffers you are mapping to > DSP MMU. Why do you need Kernel mappings ? > > If there is no benefit in maintaining Kernel mapping I would rather call > iopgtable_store_entry directly to map the entries. Where inside iommu_vmap is the mapping done? I thought the kernel can access to that buffer after get_user_pages() where the user pages are pin and we can get a kernel address. The intention using iommu_vmap was to use api's proved by the iovmmu module. iommu_vmap() it is also tracking the mapped areas, so maybe the next step could be: remove dmm.c/h files and also proc_reserve/unreserved functions. If you think the function is unneeded steps and could affect the performance I can do the change to use only iopgtable_store_entry(). I think a kernel mapping is needed for flush/invalidate api's, please correct me if I am wrong. Regards, Fernando. > > Thank you, > Best regards, Hari -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 8/9] dspbridge: add map support for big buffers
Fernando, > - for_each_sg(sgt->sgl, sg, sgt->nents, i) > - sg_set_page(sg, usr_pgs[i], PAGE_SIZE, 0); > + da = iommu_vmap(mmu, da, sgt, IOVMF_ENDIAN_LITTLE | > + IOVMF_ELSZ_32); -- iommu_vmap does the Kernel mapping to the buffers you are mapping to DSP MMU. Why do you need Kernel mappings ? If there is no benefit in maintaining Kernel mapping I would rather call iopgtable_store_entry directly to map the entries. Thank you, Best regards, Hari -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 8/9] dspbridge: add map support for big buffers
due to a restriction in scatter gather lists, it can
not be created a list for a buffer bigger than 1MB.
This patch is spliting big mappings into 1MB mappings.
Signed-off-by: Fernando Guzman Lugo
---
arch/arm/plat-omap/include/dspbridge/dsp-mmu.h |2 +-
drivers/dsp/bridge/core/dsp-mmu.c | 55 ++-
drivers/dsp/bridge/rmgr/proc.c |3 +-
3 files changed, 36 insertions(+), 24 deletions(-)
diff --git a/arch/arm/plat-omap/include/dspbridge/dsp-mmu.h
b/arch/arm/plat-omap/include/dspbridge/dsp-mmu.h
index 266f38b..2e4bf6a 100644
--- a/arch/arm/plat-omap/include/dspbridge/dsp-mmu.h
+++ b/arch/arm/plat-omap/include/dspbridge/dsp-mmu.h
@@ -85,6 +85,6 @@ int user_to_dsp_map(struct iommu *mmu, u32 uva, u32 da, u32
size,
* This function unmaps a user space buffer into DSP virtual address.
*
*/
-int user_to_dsp_unmap(struct iommu *mmu, u32 da);
+int user_to_dsp_unmap(struct iommu *mmu, u32 da, unsigned size);
#endif
diff --git a/drivers/dsp/bridge/core/dsp-mmu.c
b/drivers/dsp/bridge/core/dsp-mmu.c
index e8da327..9a46206 100644
--- a/drivers/dsp/bridge/core/dsp-mmu.c
+++ b/drivers/dsp/bridge/core/dsp-mmu.c
@@ -133,7 +133,7 @@ int user_to_dsp_map(struct iommu *mmu, u32 uva, u32 da, u32
size,
struct page **usr_pgs)
{
int res, w;
- unsigned pages, i;
+ unsigned pages, i, j = 0;
struct vm_area_struct *vma;
struct mm_struct *mm = current->mm;
struct sg_table *sgt;
@@ -162,24 +162,31 @@ int user_to_dsp_map(struct iommu *mmu, u32 uva, u32 da,
u32 size,
if (res < 0)
return res;
- sgt = kzalloc(sizeof(*sgt), GFP_KERNEL);
+ while (pages) {
+ sgt = kzalloc(sizeof(*sgt), GFP_KERNEL);
- if (!sgt)
- return -ENOMEM;
+ if (!sgt)
+ return -ENOMEM;
- res = sg_alloc_table(sgt, pages, GFP_KERNEL);
+ res = sg_alloc_table(sgt,
+ min((unsigned)SG_MAX_SINGLE_ALLOC, pages), GFP_KERNEL);
+ pages -= min((unsigned)SG_MAX_SINGLE_ALLOC, pages);
- if (res < 0)
- goto err_sg;
+ if (res < 0)
+ goto err_sg;
+
+ for_each_sg(sgt->sgl, sg, sgt->nents, i)
+ sg_set_page(sg, usr_pgs[j++], PAGE_SIZE, 0);
- for_each_sg(sgt->sgl, sg, sgt->nents, i)
- sg_set_page(sg, usr_pgs[i], PAGE_SIZE, 0);
+ da = iommu_vmap(mmu, da, sgt, IOVMF_ENDIAN_LITTLE |
+ IOVMF_ELSZ_32);
- da = iommu_vmap(mmu, da, sgt, IOVMF_ENDIAN_LITTLE | IOVMF_ELSZ_32);
+ if (IS_ERR_VALUE(da)) {
+ res = (int)da;
+ goto err_map;
+ }
- if (IS_ERR_VALUE(da)) {
- res = (int)da;
- goto err_map;
+ da += SG_MAX_SINGLE_ALLOC * PAGE_SIZE;
}
return 0;
@@ -198,21 +205,25 @@ err_sg:
* This function unmaps a user space buffer into DSP virtual address.
*
*/
-int user_to_dsp_unmap(struct iommu *mmu, u32 da)
+int user_to_dsp_unmap(struct iommu *mmu, u32 da, unsigned size)
{
unsigned i;
struct sg_table *sgt;
struct scatterlist *sg;
+ const unsigned max_sz = SG_MAX_SINGLE_ALLOC * PAGE_SIZE;
- sgt = iommu_vunmap(mmu, da);
- if (!sgt)
- return -EFAULT;
-
- for_each_sg(sgt->sgl, sg, sgt->nents, i)
- put_page(sg_page(sg));
+ while (size) {
+ size -= min(max_sz, size);
+ sgt = iommu_vunmap(mmu, da);
+ if (!sgt)
+ return -EFAULT;
- sg_free_table(sgt);
- kfree(sgt);
+ for_each_sg(sgt->sgl, sg, sgt->nents, i)
+ put_page(sg_page(sg));
+ sg_free_table(sgt);
+ kfree(sgt);
+ da += max_sz;
+ }
return 0;
}
diff --git a/drivers/dsp/bridge/rmgr/proc.c b/drivers/dsp/bridge/rmgr/proc.c
index 4f10a41..997918e 100644
--- a/drivers/dsp/bridge/rmgr/proc.c
+++ b/drivers/dsp/bridge/rmgr/proc.c
@@ -1713,7 +1713,8 @@ int proc_un_map(void *hprocessor, void *map_addr,
/* Remove mapping from the page tables. */
if (DSP_SUCCEEDED(status)) {
status = user_to_dsp_unmap(
- p_proc_object->hbridge_context->dsp_mmu, va_align);
+ p_proc_object->hbridge_context->dsp_mmu,
+ va_align, size_align);
}
mutex_unlock(&proc_lock);
--
1.6.3.3
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
