subject:"RE\: Are media drivers abusing of GFP_DMA\? \- was\: Re\: \[LSF\/MM TOPIC NOTES\] x86 ZONE

Re: Are media drivers abusing of GFP_DMA? - was: Re: [LSF/MM TOPIC NOTES] x86 ZONE_DMA love

2018-05-15 Thread Luis R. Rodriguez

On Mon, May 14, 2018 at 07:35:03AM -0300, Mauro Carvalho Chehab wrote:
> Hi Fabien,
> 
> Em Mon, 14 May 2018 08:00:37 +
> Fabien DESSENNE  escreveu:
> 
> > On 07/05/18 17:19, Mauro Carvalho Chehab wrote:
> > > Em Mon, 07 May 2018 16:26:08 +0300
> > > Laurent Pinchart  escreveu:
> > >  
> > >> Hi Mauro,
> > >>
> > >> On Saturday, 5 May 2018 19:08:15 EEST Mauro Carvalho Chehab wrote:  
> > >>> There was a recent discussion about the use/abuse of GFP_DMA flag when
> > >>> allocating memories at LSF/MM 2018 (see Luis notes enclosed).
> > >>>
> > >>> The idea seems to be to remove it, using CMA instead. Before doing that,
> > >>> better to check if what we have on media is are valid use cases for it, 
> > >>> or
> > >>> if it is there just due to some misunderstanding (or because it was
> > >>> copied from some other code).
> > >>>
> > >>> Hans de Goede sent us today a patch stopping abuse at gspca, and I'm
> > >>> also posting today two other patches meant to stop abuse of it on USB
> > >>> drivers. Still, there are 4 platform drivers using it:
> > >>>
> > >>> $ git grep -l -E "GFP_DMA\\b" drivers/media/
> > >>> drivers/media/platform/omap3isp/ispstat.c
> > >>> drivers/media/platform/sti/bdisp/bdisp-hw.c
> > >>> drivers/media/platform/sti/hva/hva-mem.c  
> > 
> > Hi Mauro,
> > 
> > The two STI drivers (bdisp-hw.c and hva-mem.c) are only expected to run 
> > on ARM platforms, not on x86.
> > Since this thread deals with x86 & DMA trouble, I am not sure that we 
> > actually have a problem for the sti drivers.
> > 
> > There are some other sti drivers that make use of this GFP_DMA flag 
> > (drivers/gpu/drm/sti/sti_*.c) and it does not seem to be a problem.
> > 
> > Nevertheless I can see that the media sti drivers depend on COMPILE_TEST 
> > (which is not the case for the DRM ones).
> > Would it be an acceptable solution to remove the COMPILE_TEST dependency?
> 
> This has nothing to do with either x86 

Actually it does.

> or COMPILE_TEST. The thing is
> that there's a plan for removing GFP_DMA from the Kernel[1], 

That would not be possible given architectures use GFP_DMA for other
things and there are plenty of legacy x86 drivers which still need to be
around. So the focus from mm folks shifted to letting x86 folks map
GFP_DMA onto the CMA pool. Long term, this is nothing that driver developers
need to care for, but just knowing internally behind the scenes there is some
cleaning up being done in terms of architecture.

> as it was
> originally meant to be used only by old PCs, where the DMA controllers
> used only  on the bottom 16 MB memory address (24 bits).

This is actually the part that is x86 specific.

Each other architecture may use it for some other definition and it seems
some architectures use GFP_DMA all over the place. So the topic really should
be about x86.

> IMHO, it is 
> very unlikely that any ARM SoC have such limitation.

Right, how the flag is used on other architectures varies, so in fact the
focus for cleaning up for now should be an x86 effort. Whether or not
other architectures do something silly with GFP_DMA is beyond the scope
of what was discussed.

  Luis

Re: Are media drivers abusing of GFP_DMA? - was: Re: [LSF/MM TOPIC NOTES] x86 ZONE_DMA love

2018-05-15 Thread Mauro Carvalho Chehab

Hi Laurent,

Em Tue, 15 May 2018 11:27:44 +0300
Laurent Pinchart  escreveu:

> Hello,
> 
> On Tuesday, 15 May 2018 10:30:28 EEST Fabien DESSENNE wrote:
> > On 14/05/18 12:39, Mauro Carvalho Chehab wrote:  
> > > Em Mon, 14 May 2018 07:35:03 -0300 Mauro Carvalho Chehab escreveu:  
> > >> Em Mon, 14 May 2018 08:00:37 + Fabien DESSENNE escreveu:  
> > >>> On 07/05/18 17:19, Mauro Carvalho Chehab wrote:  
> >  Em Mon, 07 May 2018 16:26:08 +0300 Laurent Pinchart escreveu:  
> > > On Saturday, 5 May 2018 19:08:15 EEST Mauro Carvalho Chehab wrote:
> > >   
> > >> There was a recent discussion about the use/abuse of GFP_DMA flag
> > >> when allocating memories at LSF/MM 2018 (see Luis notes enclosed).
> > >>
> > >> The idea seems to be to remove it, using CMA instead. Before doing
> > >> that, better to check if what we have on media is are valid use cases
> > >> for it, or if it is there just due to some misunderstanding (or
> > >> because it was copied from some other code).
> > >>
> > >> Hans de Goede sent us today a patch stopping abuse at gspca, and I'm
> > >> also posting today two other patches meant to stop abuse of it on
> > >> USB drivers. Still, there are 4 platform drivers using it:
> > >>
> > >>  $ git grep -l -E "GFP_DMA\\b" drivers/media/
> > >>  drivers/media/platform/omap3isp/ispstat.c
> > >>  drivers/media/platform/sti/bdisp/bdisp-hw.c
> > >>  drivers/media/platform/sti/hva/hva-mem.c  
> > >>>
> > >>> The two STI drivers (bdisp-hw.c and hva-mem.c) are only expected to run
> > >>> on ARM platforms, not on x86. Since this thread deals with x86 & DMA
> > >>> trouble, I am not sure that we actually have a problem for the sti
> > >>> drivers.
> > >>>
> > >>> There are some other sti drivers that make use of this GFP_DMA flag
> > >>> (drivers/gpu/drm/sti/sti_*.c) and it does not seem to be a problem.
> > >>>
> > >>> Nevertheless I can see that the media sti drivers depend on COMPILE_TEST
> > >>> (which is not the case for the DRM ones).
> > >>> Would it be an acceptable solution to remove the COMPILE_TEST
> > >>> dependency?  
> > >> 
> > >> This has nothing to do with either x86 or COMPILE_TEST. The thing is
> > >> that there's a plan for removing GFP_DMA from the Kernel[1], as it was
> > >> originally meant to be used only by old PCs, where the DMA controllers
> > >> used only  on the bottom 16 MB memory address (24 bits). IMHO, it is
> > >> very unlikely that any ARM SoC have such limitation.
> > >>
> > >> [1] https://lwn.net/Articles/753273/ (article will be freely available
> > >> on May, 17)  
> > > 
> > > Btw, you can also read about that at:
> > > 
> > >   https://lwn.net/Articles/753274/
> > >  
> > >> Anyway, before the removal of GFP_DMA happens, I'd like to better
> > >> understand why we're using it at media, and if we can, instead,
> > >> set the DMA bit mask, just like almost all other media drivers
> > >> that require to confine DMA into a certain range do. In the case
> > >> of ARM, this is what we currently have:
> > >>
> > >> drivers/media/platform/exynos-gsc/gsc-core.c:  
> > >> vb2_dma_contig_set_max_seg_size(dev, DMA_BIT_MASK(32));
> > >> drivers/media/platform/exynos4-is/fimc-core.c: 
> > >> vb2_dma_contig_set_max_seg_size(dev, DMA_BIT_MASK(32));
> > >> drivers/media/platform/exynos4-is/fimc-is.c:   
> > >> vb2_dma_contig_set_max_seg_size(dev, DMA_BIT_MASK(32));
> > >> drivers/media/platform/exynos4-is/fimc-lite.c: 
> > >> vb2_dma_contig_set_max_seg_size(dev, DMA_BIT_MASK(32));
> > >> drivers/media/platform/mtk-mdp/mtk_mdp_core.c: 
> > >> vb2_dma_contig_set_max_seg_size(>dev, DMA_BIT_MASK(32));
> > >> drivers/media/platform/omap3isp/isp.c:  ret =
> > >> dma_coerce_mask_and_coherent(isp->dev, DMA_BIT_MASK(32));
> > >> drivers/media/platform/s5p-g2d/g2d.c:  
> > >> vb2_dma_contig_set_max_seg_size(>dev, DMA_BIT_MASK(32));
> > >> drivers/media/platform/s5p-jpeg/jpeg-core.c:   
> > >> vb2_dma_contig_set_max_seg_size(>dev, DMA_BIT_MASK(32));
> > >> drivers/media/platform/s5p-mfc/s5p_mfc.c:   
> > >>DMA_BIT_MASK(32));
> > >> drivers/media/platform/s5p-mfc/s5p_mfc.c: 
> > >>  DMA_BIT_MASK(32));
> > >> drivers/media/platform/s5p-mfc/s5p_mfc.c:  
> > >> vb2_dma_contig_set_max_seg_size(dev, DMA_BIT_MASK(32));  
> > 
> > That's clearer now, thank you for the clarification
> > I am about to send patches for the sti drivers (set the DMA bit mask)  
> 
> Some drivers call vb2_dma_contig_set_max_seg_size() and some call 
> dma_coerce_mask_and_coherent(). Both are likely needed, the former telling 
> the 
> DMA mapping API about the maximum size of a scatter-gather chunk that the 
> device supports (when using vb2-dma-contig that size should really be the 
> full 
> address space supported by the device as we want DMA-contiguous buffers), and 
> the latter telling the DMA mapping API about

Re: Are media drivers abusing of GFP_DMA? - was: Re: [LSF/MM TOPIC NOTES] x86 ZONE_DMA love

2018-05-15 Thread Laurent Pinchart

Hello,

On Tuesday, 15 May 2018 10:30:28 EEST Fabien DESSENNE wrote:
> On 14/05/18 12:39, Mauro Carvalho Chehab wrote:
> > Em Mon, 14 May 2018 07:35:03 -0300 Mauro Carvalho Chehab escreveu:
> >> Em Mon, 14 May 2018 08:00:37 + Fabien DESSENNE escreveu:
> >>> On 07/05/18 17:19, Mauro Carvalho Chehab wrote:
>  Em Mon, 07 May 2018 16:26:08 +0300 Laurent Pinchart escreveu:
> > On Saturday, 5 May 2018 19:08:15 EEST Mauro Carvalho Chehab wrote:
> > 
> >> There was a recent discussion about the use/abuse of GFP_DMA flag
> >> when allocating memories at LSF/MM 2018 (see Luis notes enclosed).
> >>
> >> The idea seems to be to remove it, using CMA instead. Before doing
> >> that, better to check if what we have on media is are valid use cases
> >> for it, or if it is there just due to some misunderstanding (or
> >> because it was copied from some other code).
> >>
> >> Hans de Goede sent us today a patch stopping abuse at gspca, and I'm
> >> also posting today two other patches meant to stop abuse of it on
> >> USB drivers. Still, there are 4 platform drivers using it:
> >>
> >>$ git grep -l -E "GFP_DMA\\b" drivers/media/
> >>drivers/media/platform/omap3isp/ispstat.c
> >>drivers/media/platform/sti/bdisp/bdisp-hw.c
> >>drivers/media/platform/sti/hva/hva-mem.c
> >>>
> >>> The two STI drivers (bdisp-hw.c and hva-mem.c) are only expected to run
> >>> on ARM platforms, not on x86. Since this thread deals with x86 & DMA
> >>> trouble, I am not sure that we actually have a problem for the sti
> >>> drivers.
> >>>
> >>> There are some other sti drivers that make use of this GFP_DMA flag
> >>> (drivers/gpu/drm/sti/sti_*.c) and it does not seem to be a problem.
> >>>
> >>> Nevertheless I can see that the media sti drivers depend on COMPILE_TEST
> >>> (which is not the case for the DRM ones).
> >>> Would it be an acceptable solution to remove the COMPILE_TEST
> >>> dependency?
> >> 
> >> This has nothing to do with either x86 or COMPILE_TEST. The thing is
> >> that there's a plan for removing GFP_DMA from the Kernel[1], as it was
> >> originally meant to be used only by old PCs, where the DMA controllers
> >> used only  on the bottom 16 MB memory address (24 bits). IMHO, it is
> >> very unlikely that any ARM SoC have such limitation.
> >>
> >> [1] https://lwn.net/Articles/753273/ (article will be freely available
> >> on May, 17)
> > 
> > Btw, you can also read about that at:
> > 
> > https://lwn.net/Articles/753274/
> >
> >> Anyway, before the removal of GFP_DMA happens, I'd like to better
> >> understand why we're using it at media, and if we can, instead,
> >> set the DMA bit mask, just like almost all other media drivers
> >> that require to confine DMA into a certain range do. In the case
> >> of ARM, this is what we currently have:
> >>
> >> drivers/media/platform/exynos-gsc/gsc-core.c:  
> >> vb2_dma_contig_set_max_seg_size(dev, DMA_BIT_MASK(32));
> >> drivers/media/platform/exynos4-is/fimc-core.c: 
> >> vb2_dma_contig_set_max_seg_size(dev, DMA_BIT_MASK(32));
> >> drivers/media/platform/exynos4-is/fimc-is.c:   
> >> vb2_dma_contig_set_max_seg_size(dev, DMA_BIT_MASK(32));
> >> drivers/media/platform/exynos4-is/fimc-lite.c: 
> >> vb2_dma_contig_set_max_seg_size(dev, DMA_BIT_MASK(32));
> >> drivers/media/platform/mtk-mdp/mtk_mdp_core.c: 
> >> vb2_dma_contig_set_max_seg_size(>dev, DMA_BIT_MASK(32));
> >> drivers/media/platform/omap3isp/isp.c:  ret =
> >> dma_coerce_mask_and_coherent(isp->dev, DMA_BIT_MASK(32));
> >> drivers/media/platform/s5p-g2d/g2d.c:  
> >> vb2_dma_contig_set_max_seg_size(>dev, DMA_BIT_MASK(32));
> >> drivers/media/platform/s5p-jpeg/jpeg-core.c:   
> >> vb2_dma_contig_set_max_seg_size(>dev, DMA_BIT_MASK(32));
> >> drivers/media/platform/s5p-mfc/s5p_mfc.c:   
> >>DMA_BIT_MASK(32));
> >> drivers/media/platform/s5p-mfc/s5p_mfc.c: 
> >>  DMA_BIT_MASK(32));
> >> drivers/media/platform/s5p-mfc/s5p_mfc.c:  
> >> vb2_dma_contig_set_max_seg_size(dev, DMA_BIT_MASK(32));
> 
> That's clearer now, thank you for the clarification
> I am about to send patches for the sti drivers (set the DMA bit mask)

Some drivers call vb2_dma_contig_set_max_seg_size() and some call 
dma_coerce_mask_and_coherent(). Both are likely needed, the former telling the 
DMA mapping API about the maximum size of a scatter-gather chunk that the 
device supports (when using vb2-dma-contig that size should really be the full 
address space supported by the device as we want DMA-contiguous buffers), and 
the latter telling the DMA mapping API about the address space that is 
accessible through DMA (and thus in which address range buffers must be 
placed).

I wonder why the omap3isp driver works without a 
vb2_dma_contig_set_max_seg_size() call. Sakari, any insight ?

> >>drivers/media/spi/cxd2880-spi.c
> >>
> >> Could you please check if

Re: Are media drivers abusing of GFP_DMA? - was: Re: [LSF/MM TOPIC NOTES] x86 ZONE_DMA love

2018-05-15 Thread Fabien DESSENNE



On 14/05/18 12:39, Mauro Carvalho Chehab wrote:
> Em Mon, 14 May 2018 07:35:03 -0300
> Mauro Carvalho Chehab  escreveu:
>
>> Hi Fabien,
>>
>> Em Mon, 14 May 2018 08:00:37 +
>> Fabien DESSENNE  escreveu:
>>
>>> On 07/05/18 17:19, Mauro Carvalho Chehab wrote:
 Em Mon, 07 May 2018 16:26:08 +0300
 Laurent Pinchart  escreveu:
   
> Hi Mauro,
>
> On Saturday, 5 May 2018 19:08:15 EEST Mauro Carvalho Chehab wrote:
>> There was a recent discussion about the use/abuse of GFP_DMA flag when
>> allocating memories at LSF/MM 2018 (see Luis notes enclosed).
>>
>> The idea seems to be to remove it, using CMA instead. Before doing that,
>> better to check if what we have on media is are valid use cases for it, 
>> or
>> if it is there just due to some misunderstanding (or because it was
>> copied from some other code).
>>
>> Hans de Goede sent us today a patch stopping abuse at gspca, and I'm
>> also posting today two other patches meant to stop abuse of it on USB
>> drivers. Still, there are 4 platform drivers using it:
>>
>>  $ git grep -l -E "GFP_DMA\\b" drivers/media/
>>  drivers/media/platform/omap3isp/ispstat.c
>>  drivers/media/platform/sti/bdisp/bdisp-hw.c
>>  drivers/media/platform/sti/hva/hva-mem.c
>>> Hi Mauro,
>>>
>>> The two STI drivers (bdisp-hw.c and hva-mem.c) are only expected to run
>>> on ARM platforms, not on x86.
>>> Since this thread deals with x86 & DMA trouble, I am not sure that we
>>> actually have a problem for the sti drivers.
>>>
>>> There are some other sti drivers that make use of this GFP_DMA flag
>>> (drivers/gpu/drm/sti/sti_*.c) and it does not seem to be a problem.
>>>
>>> Nevertheless I can see that the media sti drivers depend on COMPILE_TEST
>>> (which is not the case for the DRM ones).
>>> Would it be an acceptable solution to remove the COMPILE_TEST dependency?
>> This has nothing to do with either x86 or COMPILE_TEST. The thing is
>> that there's a plan for removing GFP_DMA from the Kernel[1], as it was
>> originally meant to be used only by old PCs, where the DMA controllers
>> used only  on the bottom 16 MB memory address (24 bits). IMHO, it is
>> very unlikely that any ARM SoC have such limitation.
>>
>> [1] https://lwn.net/Articles/753273/ (article will be freely available
>> on May, 17)
> Btw, you can also read about that at:
>   https://lwn.net/Articles/753274/
>
>> Anyway, before the removal of GFP_DMA happens, I'd like to better
>> understand why we're using it at media, and if we can, instead,
>> set the DMA bit mask, just like almost all other media drivers
>> that require to confine DMA into a certain range do. In the case
>> of ARM, this is what we currently have:
>>
>> drivers/media/platform/exynos-gsc/gsc-core.c:   
>> vb2_dma_contig_set_max_seg_size(dev, DMA_BIT_MASK(32));
>> drivers/media/platform/exynos4-is/fimc-core.c:  
>> vb2_dma_contig_set_max_seg_size(dev, DMA_BIT_MASK(32));
>> drivers/media/platform/exynos4-is/fimc-is.c:
>> vb2_dma_contig_set_max_seg_size(dev, DMA_BIT_MASK(32));
>> drivers/media/platform/exynos4-is/fimc-lite.c:  
>> vb2_dma_contig_set_max_seg_size(dev, DMA_BIT_MASK(32));
>> drivers/media/platform/mtk-mdp/mtk_mdp_core.c:  
>> vb2_dma_contig_set_max_seg_size(>dev, DMA_BIT_MASK(32));
>> drivers/media/platform/omap3isp/isp.c:  ret = 
>> dma_coerce_mask_and_coherent(isp->dev, DMA_BIT_MASK(32));
>> drivers/media/platform/s5p-g2d/g2d.c:   
>> vb2_dma_contig_set_max_seg_size(>dev, DMA_BIT_MASK(32));
>> drivers/media/platform/s5p-jpeg/jpeg-core.c:
>> vb2_dma_contig_set_max_seg_size(>dev, DMA_BIT_MASK(32));
>> drivers/media/platform/s5p-mfc/s5p_mfc.c:
>>DMA_BIT_MASK(32));
>> drivers/media/platform/s5p-mfc/s5p_mfc.c:
>>DMA_BIT_MASK(32));
>> drivers/media/platform/s5p-mfc/s5p_mfc.c:   
>> vb2_dma_contig_set_max_seg_size(dev, DMA_BIT_MASK(32));
>>

That's clearer now, thank you for the clarification
I am about to send patches for the sti drivers (set the DMA bit mask)

BR,
Fabien

>>> BR
>>>
>>> Fabien
>>>
>>  drivers/media/spi/cxd2880-spi.c
>>
>> Could you please check if GFP_DMA is really needed there, or if it is
>> just because of some cut-and-paste from some other place?
> I started looking at that for the omap3isp driver but Sakari beat me at
> submitting a patch. GFP_DMA isn't needed for omap3isp.
>   
 Thank you both for looking into it.

 Regards,
 Mauro



 Thanks,
 Mauro
>>
>>
>> Thanks,
>> Mauro
>
>
> Thanks,
> Mauro

Re: Are media drivers abusing of GFP_DMA? - was: Re: [LSF/MM TOPIC NOTES] x86 ZONE_DMA love

2018-05-14 Thread Mauro Carvalho Chehab

Em Mon, 14 May 2018 07:35:03 -0300
Mauro Carvalho Chehab  escreveu:

> Hi Fabien,
> 
> Em Mon, 14 May 2018 08:00:37 +
> Fabien DESSENNE  escreveu:
> 
> > On 07/05/18 17:19, Mauro Carvalho Chehab wrote:
> > > Em Mon, 07 May 2018 16:26:08 +0300
> > > Laurent Pinchart  escreveu:
> > >  
> > >> Hi Mauro,
> > >>
> > >> On Saturday, 5 May 2018 19:08:15 EEST Mauro Carvalho Chehab wrote:  
> > >>> There was a recent discussion about the use/abuse of GFP_DMA flag when
> > >>> allocating memories at LSF/MM 2018 (see Luis notes enclosed).
> > >>>
> > >>> The idea seems to be to remove it, using CMA instead. Before doing that,
> > >>> better to check if what we have on media is are valid use cases for it, 
> > >>> or
> > >>> if it is there just due to some misunderstanding (or because it was
> > >>> copied from some other code).
> > >>>
> > >>> Hans de Goede sent us today a patch stopping abuse at gspca, and I'm
> > >>> also posting today two other patches meant to stop abuse of it on USB
> > >>> drivers. Still, there are 4 platform drivers using it:
> > >>>
> > >>> $ git grep -l -E "GFP_DMA\\b" drivers/media/
> > >>> drivers/media/platform/omap3isp/ispstat.c
> > >>> drivers/media/platform/sti/bdisp/bdisp-hw.c
> > >>> drivers/media/platform/sti/hva/hva-mem.c  
> > 
> > Hi Mauro,
> > 
> > The two STI drivers (bdisp-hw.c and hva-mem.c) are only expected to run 
> > on ARM platforms, not on x86.
> > Since this thread deals with x86 & DMA trouble, I am not sure that we 
> > actually have a problem for the sti drivers.
> > 
> > There are some other sti drivers that make use of this GFP_DMA flag 
> > (drivers/gpu/drm/sti/sti_*.c) and it does not seem to be a problem.
> > 
> > Nevertheless I can see that the media sti drivers depend on COMPILE_TEST 
> > (which is not the case for the DRM ones).
> > Would it be an acceptable solution to remove the COMPILE_TEST dependency?
> 
> This has nothing to do with either x86 or COMPILE_TEST. The thing is
> that there's a plan for removing GFP_DMA from the Kernel[1], as it was
> originally meant to be used only by old PCs, where the DMA controllers
> used only  on the bottom 16 MB memory address (24 bits). IMHO, it is 
> very unlikely that any ARM SoC have such limitation.
> 
> [1] https://lwn.net/Articles/753273/ (article will be freely available
> on May, 17)

Btw, you can also read about that at:
https://lwn.net/Articles/753274/

> 
> Anyway, before the removal of GFP_DMA happens, I'd like to better 
> understand why we're using it at media, and if we can, instead,
> set the DMA bit mask, just like almost all other media drivers
> that require to confine DMA into a certain range do. In the case
> of ARM, this is what we currently have:
> 
> drivers/media/platform/exynos-gsc/gsc-core.c:   
> vb2_dma_contig_set_max_seg_size(dev, DMA_BIT_MASK(32));
> drivers/media/platform/exynos4-is/fimc-core.c:  
> vb2_dma_contig_set_max_seg_size(dev, DMA_BIT_MASK(32));
> drivers/media/platform/exynos4-is/fimc-is.c:
> vb2_dma_contig_set_max_seg_size(dev, DMA_BIT_MASK(32));
> drivers/media/platform/exynos4-is/fimc-lite.c:  
> vb2_dma_contig_set_max_seg_size(dev, DMA_BIT_MASK(32));
> drivers/media/platform/mtk-mdp/mtk_mdp_core.c:  
> vb2_dma_contig_set_max_seg_size(>dev, DMA_BIT_MASK(32));
> drivers/media/platform/omap3isp/isp.c:  ret = 
> dma_coerce_mask_and_coherent(isp->dev, DMA_BIT_MASK(32));
> drivers/media/platform/s5p-g2d/g2d.c:   
> vb2_dma_contig_set_max_seg_size(>dev, DMA_BIT_MASK(32));
> drivers/media/platform/s5p-jpeg/jpeg-core.c:
> vb2_dma_contig_set_max_seg_size(>dev, DMA_BIT_MASK(32));
> drivers/media/platform/s5p-mfc/s5p_mfc.c: 
>   DMA_BIT_MASK(32));
> drivers/media/platform/s5p-mfc/s5p_mfc.c: 
>   DMA_BIT_MASK(32));
> drivers/media/platform/s5p-mfc/s5p_mfc.c:   
> vb2_dma_contig_set_max_seg_size(dev, DMA_BIT_MASK(32));
> 
> > 
> > BR
> > 
> > Fabien
> > 
> > >>> drivers/media/spi/cxd2880-spi.c
> > >>>
> > >>> Could you please check if GFP_DMA is really needed there, or if it is
> > >>> just because of some cut-and-paste from some other place?  
> > >> I started looking at that for the omap3isp driver but Sakari beat me at
> > >> submitting a patch. GFP_DMA isn't needed for omap3isp.
> > >>  
> > > Thank you both for looking into it.
> > >
> > > Regards,
> > > Mauro
> > >
> > >
> > >
> > > Thanks,
> > > Mauro  
> 
> 
> 
> Thanks,
> Mauro



Thanks,
Mauro

Re: Are media drivers abusing of GFP_DMA? - was: Re: [LSF/MM TOPIC NOTES] x86 ZONE_DMA love

2018-05-14 Thread Mauro Carvalho Chehab

Hi Fabien,

Em Mon, 14 May 2018 08:00:37 +
Fabien DESSENNE  escreveu:

> On 07/05/18 17:19, Mauro Carvalho Chehab wrote:
> > Em Mon, 07 May 2018 16:26:08 +0300
> > Laurent Pinchart  escreveu:
> >  
> >> Hi Mauro,
> >>
> >> On Saturday, 5 May 2018 19:08:15 EEST Mauro Carvalho Chehab wrote:  
> >>> There was a recent discussion about the use/abuse of GFP_DMA flag when
> >>> allocating memories at LSF/MM 2018 (see Luis notes enclosed).
> >>>
> >>> The idea seems to be to remove it, using CMA instead. Before doing that,
> >>> better to check if what we have on media is are valid use cases for it, or
> >>> if it is there just due to some misunderstanding (or because it was
> >>> copied from some other code).
> >>>
> >>> Hans de Goede sent us today a patch stopping abuse at gspca, and I'm
> >>> also posting today two other patches meant to stop abuse of it on USB
> >>> drivers. Still, there are 4 platform drivers using it:
> >>>
> >>>   $ git grep -l -E "GFP_DMA\\b" drivers/media/
> >>>   drivers/media/platform/omap3isp/ispstat.c
> >>>   drivers/media/platform/sti/bdisp/bdisp-hw.c
> >>>   drivers/media/platform/sti/hva/hva-mem.c  
> 
> Hi Mauro,
> 
> The two STI drivers (bdisp-hw.c and hva-mem.c) are only expected to run 
> on ARM platforms, not on x86.
> Since this thread deals with x86 & DMA trouble, I am not sure that we 
> actually have a problem for the sti drivers.
> 
> There are some other sti drivers that make use of this GFP_DMA flag 
> (drivers/gpu/drm/sti/sti_*.c) and it does not seem to be a problem.
> 
> Nevertheless I can see that the media sti drivers depend on COMPILE_TEST 
> (which is not the case for the DRM ones).
> Would it be an acceptable solution to remove the COMPILE_TEST dependency?

This has nothing to do with either x86 or COMPILE_TEST. The thing is
that there's a plan for removing GFP_DMA from the Kernel[1], as it was
originally meant to be used only by old PCs, where the DMA controllers
used only  on the bottom 16 MB memory address (24 bits). IMHO, it is 
very unlikely that any ARM SoC have such limitation.

[1] https://lwn.net/Articles/753273/ (article will be freely available
on May, 17)

Anyway, before the removal of GFP_DMA happens, I'd like to better 
understand why we're using it at media, and if we can, instead,
set the DMA bit mask, just like almost all other media drivers
that require to confine DMA into a certain range do. In the case
of ARM, this is what we currently have:

drivers/media/platform/exynos-gsc/gsc-core.c:   
vb2_dma_contig_set_max_seg_size(dev, DMA_BIT_MASK(32));
drivers/media/platform/exynos4-is/fimc-core.c:  
vb2_dma_contig_set_max_seg_size(dev, DMA_BIT_MASK(32));
drivers/media/platform/exynos4-is/fimc-is.c:
vb2_dma_contig_set_max_seg_size(dev, DMA_BIT_MASK(32));
drivers/media/platform/exynos4-is/fimc-lite.c:  
vb2_dma_contig_set_max_seg_size(dev, DMA_BIT_MASK(32));
drivers/media/platform/mtk-mdp/mtk_mdp_core.c:  
vb2_dma_contig_set_max_seg_size(>dev, DMA_BIT_MASK(32));
drivers/media/platform/omap3isp/isp.c:  ret = 
dma_coerce_mask_and_coherent(isp->dev, DMA_BIT_MASK(32));
drivers/media/platform/s5p-g2d/g2d.c:   
vb2_dma_contig_set_max_seg_size(>dev, DMA_BIT_MASK(32));
drivers/media/platform/s5p-jpeg/jpeg-core.c:
vb2_dma_contig_set_max_seg_size(>dev, DMA_BIT_MASK(32));
drivers/media/platform/s5p-mfc/s5p_mfc.c:   
DMA_BIT_MASK(32));
drivers/media/platform/s5p-mfc/s5p_mfc.c:   
DMA_BIT_MASK(32));
drivers/media/platform/s5p-mfc/s5p_mfc.c:   
vb2_dma_contig_set_max_seg_size(dev, DMA_BIT_MASK(32));

> 
> BR
> 
> Fabien
> 
> >>>   drivers/media/spi/cxd2880-spi.c
> >>>
> >>> Could you please check if GFP_DMA is really needed there, or if it is
> >>> just because of some cut-and-paste from some other place?  
> >> I started looking at that for the omap3isp driver but Sakari beat me at
> >> submitting a patch. GFP_DMA isn't needed for omap3isp.
> >>  
> > Thank you both for looking into it.
> >
> > Regards,
> > Mauro
> >
> >
> >
> > Thanks,
> > Mauro  



Thanks,
Mauro

Re: Are media drivers abusing of GFP_DMA? - was: Re: [LSF/MM TOPIC NOTES] x86 ZONE_DMA love

2018-05-14 Thread Fabien DESSENNE



On 07/05/18 17:19, Mauro Carvalho Chehab wrote:
> Em Mon, 07 May 2018 16:26:08 +0300
> Laurent Pinchart  escreveu:
>
>> Hi Mauro,
>>
>> On Saturday, 5 May 2018 19:08:15 EEST Mauro Carvalho Chehab wrote:
>>> There was a recent discussion about the use/abuse of GFP_DMA flag when
>>> allocating memories at LSF/MM 2018 (see Luis notes enclosed).
>>>
>>> The idea seems to be to remove it, using CMA instead. Before doing that,
>>> better to check if what we have on media is are valid use cases for it, or
>>> if it is there just due to some misunderstanding (or because it was
>>> copied from some other code).
>>>
>>> Hans de Goede sent us today a patch stopping abuse at gspca, and I'm
>>> also posting today two other patches meant to stop abuse of it on USB
>>> drivers. Still, there are 4 platform drivers using it:
>>>
>>> $ git grep -l -E "GFP_DMA\\b" drivers/media/
>>> drivers/media/platform/omap3isp/ispstat.c
>>> drivers/media/platform/sti/bdisp/bdisp-hw.c
>>> drivers/media/platform/sti/hva/hva-mem.c

Hi Mauro,

The two STI drivers (bdisp-hw.c and hva-mem.c) are only expected to run 
on ARM platforms, not on x86.
Since this thread deals with x86 & DMA trouble, I am not sure that we 
actually have a problem for the sti drivers.

There are some other sti drivers that make use of this GFP_DMA flag 
(drivers/gpu/drm/sti/sti_*.c) and it does not seem to be a problem.

Nevertheless I can see that the media sti drivers depend on COMPILE_TEST 
(which is not the case for the DRM ones).
Would it be an acceptable solution to remove the COMPILE_TEST dependency?

BR

Fabien

>>> drivers/media/spi/cxd2880-spi.c
>>>
>>> Could you please check if GFP_DMA is really needed there, or if it is
>>> just because of some cut-and-paste from some other place?
>> I started looking at that for the omap3isp driver but Sakari beat me at
>> submitting a patch. GFP_DMA isn't needed for omap3isp.
>>
> Thank you both for looking into it.
>
> Regards,
> Mauro
>
>
>
> Thanks,
> Mauro

RE: Are media drivers abusing of GFP_DMA? - was: Re: [LSF/MM TOPIC NOTES] x86 ZONE_DMA love

2018-05-09 Thread Yasunari.Takiguchi

Dear Mauro

> -Original Message-
> 
> There was a recent discussion about the use/abuse of GFP_DMA flag when
> allocating memories at LSF/MM 2018 (see Luis notes enclosed).
> 
> The idea seems to be to remove it, using CMA instead. Before doing that,
> better to check if what we have on media is are valid use cases for it,
> or
> if it is there just due to some misunderstanding (or because it was
> copied from some other code).
> 
> Hans de Goede sent us today a patch stopping abuse at gspca, and I'm
> also posting today two other patches meant to stop abuse of it on USB
> drivers. Still, there are 4 platform drivers using it:
> 
>   $ git grep -l -E "GFP_DMA\\b" drivers/media/
>   drivers/media/platform/omap3isp/ispstat.c
>   drivers/media/platform/sti/bdisp/bdisp-hw.c
>   drivers/media/platform/sti/hva/hva-mem.c
>   drivers/media/spi/cxd2880-spi.c
> 
> Could you please check if GFP_DMA is really needed there, or if it is
> just because of some cut-and-paste from some other place?
About drivers/media/spi/cxd2880-spi.c,
we referred to kmalloc of driver/spi/spi.c spi_write_then_read() function and 
made this code. 

Regards,
Takiguchi

Re: Are media drivers abusing of GFP_DMA? - was: Re: [LSF/MM TOPIC NOTES] x86 ZONE_DMA love

2018-05-07 Thread Mauro Carvalho Chehab

Em Mon, 07 May 2018 16:26:08 +0300
Laurent Pinchart  escreveu:

> Hi Mauro,
> 
> On Saturday, 5 May 2018 19:08:15 EEST Mauro Carvalho Chehab wrote:
> > There was a recent discussion about the use/abuse of GFP_DMA flag when
> > allocating memories at LSF/MM 2018 (see Luis notes enclosed).
> > 
> > The idea seems to be to remove it, using CMA instead. Before doing that,
> > better to check if what we have on media is are valid use cases for it, or
> > if it is there just due to some misunderstanding (or because it was
> > copied from some other code).
> > 
> > Hans de Goede sent us today a patch stopping abuse at gspca, and I'm
> > also posting today two other patches meant to stop abuse of it on USB
> > drivers. Still, there are 4 platform drivers using it:
> > 
> > $ git grep -l -E "GFP_DMA\\b" drivers/media/
> > drivers/media/platform/omap3isp/ispstat.c
> > drivers/media/platform/sti/bdisp/bdisp-hw.c
> > drivers/media/platform/sti/hva/hva-mem.c
> > drivers/media/spi/cxd2880-spi.c
> > 
> > Could you please check if GFP_DMA is really needed there, or if it is
> > just because of some cut-and-paste from some other place?  
> 
> I started looking at that for the omap3isp driver but Sakari beat me at 
> submitting a patch. GFP_DMA isn't needed for omap3isp.
> 
Thank you both for looking into it.

Regards,
Mauro



Thanks,
Mauro

Re: Are media drivers abusing of GFP_DMA? - was: Re: [LSF/MM TOPIC NOTES] x86 ZONE_DMA love

2018-05-07 Thread Laurent Pinchart

Hi Mauro,

On Saturday, 5 May 2018 19:08:15 EEST Mauro Carvalho Chehab wrote:
> There was a recent discussion about the use/abuse of GFP_DMA flag when
> allocating memories at LSF/MM 2018 (see Luis notes enclosed).
> 
> The idea seems to be to remove it, using CMA instead. Before doing that,
> better to check if what we have on media is are valid use cases for it, or
> if it is there just due to some misunderstanding (or because it was
> copied from some other code).
> 
> Hans de Goede sent us today a patch stopping abuse at gspca, and I'm
> also posting today two other patches meant to stop abuse of it on USB
> drivers. Still, there are 4 platform drivers using it:
> 
>   $ git grep -l -E "GFP_DMA\\b" drivers/media/
>   drivers/media/platform/omap3isp/ispstat.c
>   drivers/media/platform/sti/bdisp/bdisp-hw.c
>   drivers/media/platform/sti/hva/hva-mem.c
>   drivers/media/spi/cxd2880-spi.c
> 
> Could you please check if GFP_DMA is really needed there, or if it is
> just because of some cut-and-paste from some other place?

I started looking at that for the omap3isp driver but Sakari beat me at 
submitting a patch. GFP_DMA isn't needed for omap3isp.

-- 
Regards,

Laurent Pinchart

Re: Are media drivers abusing of GFP_DMA? - was: Re: [LSF/MM TOPIC NOTES] x86 ZONE_DMA love

Re: Are media drivers abusing of GFP_DMA? - was: Re: [LSF/MM TOPIC NOTES] x86 ZONE_DMA love

Re: Are media drivers abusing of GFP_DMA? - was: Re: [LSF/MM TOPIC NOTES] x86 ZONE_DMA love

Re: Are media drivers abusing of GFP_DMA? - was: Re: [LSF/MM TOPIC NOTES] x86 ZONE_DMA love

Re: Are media drivers abusing of GFP_DMA? - was: Re: [LSF/MM TOPIC NOTES] x86 ZONE_DMA love

Re: Are media drivers abusing of GFP_DMA? - was: Re: [LSF/MM TOPIC NOTES] x86 ZONE_DMA love

Re: Are media drivers abusing of GFP_DMA? - was: Re: [LSF/MM TOPIC NOTES] x86 ZONE_DMA love

RE: Are media drivers abusing of GFP_DMA? - was: Re: [LSF/MM TOPIC NOTES] x86 ZONE_DMA love

Re: Are media drivers abusing of GFP_DMA? - was: Re: [LSF/MM TOPIC NOTES] x86 ZONE_DMA love

Re: Are media drivers abusing of GFP_DMA? - was: Re: [LSF/MM TOPIC NOTES] x86 ZONE_DMA love

10 matches

Site Navigation

Mail list logo

Footer information