Re: [PATCH v3 00/27] kill devm_ioremap_nocache
Hi Christophe ，
On 2018/1/4 16:05, Christophe LEROY wrote:
>
>
> Le 25/12/2017 à 02:34, Yisheng Xie a écrit :
>>
>>
>> On 2017/12/24 17:05, christophe leroy wrote:
>>>
>>>
>>> Le 23/12/2017 à 14:48, Greg KH a écrit :
>>>> On Sat, Dec 23, 2017 at 06:55:25PM +0800, Yisheng Xie wrote:
>>>>> Hi all,
>>>>>
>>>>> When I tried to use devm_ioremap function and review related code, I found
>>>>> devm_ioremap and devm_ioremap_nocache is almost the same with each other,
>>>>> except one use ioremap while the other use ioremap_nocache.
>>>>
>>>> For all arches? Really? Look at MIPS, and x86, they have different
>>>> functions.
>>>>
>>>>> While ioremap's
>>>>> default function is ioremap_nocache, so devm_ioremap_nocache also have the
>>>>> same function with devm_ioremap, which can just be killed to reduce the
>>>>> size
>>>>> of devres.o(from 20304 bytes to 18992 bytes in my compile environment).
>>>>>
>>>>> I have posted two versions, which use macro instead of function for
>>>>> devm_ioremap_nocache[1] or devm_ioremap[2]. And Greg suggest me to kill
>>>>> devm_ioremap_nocache for no need to keep a macro around for the duplicate
>>>>> thing. So here comes v3 and please help to review.
>>>>
>>>> I don't think this can be done, what am I missing? These functions are
>>>> not identical, sorry for missing that before.
>>>
>>> devm_ioremap() and devm_ioremap_nocache() are quite similar, both use
>>> devm_ioremap_release() for the release, why not just defining:
>>>
>>> static void __iomem *__devm_ioremap(struct device *dev, resource_size_t
>>> offset,
>>> resource_size_t size, bool nocache)
>>> {
>>> [...]
>>> if (nocache)
>>> addr = ioremap_nocache(offset, size);
>>> else
>>> addr = ioremap(offset, size);
>>> [...]
>>> }
>>>
>>> then in include/linux/io.h
>>>
>>> static inline void __iomem *devm_ioremap(struct device *dev,
>>> resource_size_t offset,
>>> resource_size_t size)
>>> {return __devm_ioremap(dev, offset, size, false);}
>>>
>>> static inline void __iomem *devm_ioremap_nocache(struct device *dev,
>>> resource_size_t offset,
>>> resource_size_t size);
>>> {return __devm_ioremap(dev, offset, size, true);}
>>
>> Yeah, this seems good to me, right now we have devm_ioremap,
>> devm_ioremap_wc, devm_ioremap_nocache
>> May be we can use an enum like:
>> typedef enum {
>> DEVM_IOREMAP = 0,
>> DEVM_IOREMAP_NOCACHE,
>> DEVM_IOREMAP_WC,
>> } devm_ioremap_type;
>>
>> static inline void __iomem *devm_ioremap(struct device *dev, resource_size_t
>> offset,
>> resource_size_t size)
>> {return __devm_ioremap(dev, offset, size, DEVM_IOREMAP);}
>>
>> static inline void __iomem *devm_ioremap_nocache(struct device *dev,
>> resource_size_t offset,
>> resource_size_t size);
>> {return __devm_ioremap(dev, offset, size, DEVM_IOREMAP_NOCACHE);}
>>
>> static inline void __iomem *devm_ioremap_wc(struct device *dev,
>> resource_size_t offset,
>> resource_size_t size);
>> {return __devm_ioremap(dev, offset, size, DEVM_IOREMAP_WC);}
>>
>> static void __iomem *__devm_ioremap(struct device *dev, resource_size_t
>> offset,
>> resource_size_t size, devm_ioremap_type type)
>> {
>> void __iomem **ptr, *addr = NULL;
>> [...]
>> switch (type){
>> case DEVM_IOREMAP:
>> addr = ioremap(offset, size);
>> break;
>> case DEVM_IOREMAP_NOCACHE:
>> addr = ioremap_nocache(offset, size);
>> break;
>> case DEVM_IOREMAP_WC:
>> addr = ioremap_wc(offset, size);
>> break;
>> }
>> [...]
>> }
>
>
> That looks good to me, will you submit a v4 ?
Sorry for late response. And I will submit the v4 as your suggestion.
Thanks
Yisheng
>
> Christophe
>
>>
Re: [PATCH v3 00/27] kill devm_ioremap_nocache
+ cris/ia64/mn10300/openrisc maintainers On 2017/12/25 9:09, Yisheng Xie wrote: > hi Christophe and Greg, > > On 2017/12/24 16:55, christophe leroy wrote: >> >> >> Le 23/12/2017 à 16:57, Guenter Roeck a écrit : >>> On 12/23/2017 05:48 AM, Greg KH wrote: >>>> On Sat, Dec 23, 2017 at 06:55:25PM +0800, Yisheng Xie wrote: >>>>> Hi all, >>>>> >>>>> When I tried to use devm_ioremap function and review related code, I found >>>>> devm_ioremap and devm_ioremap_nocache is almost the same with each other, >>>>> except one use ioremap while the other use ioremap_nocache. >>>> >>>> For all arches? Really? Look at MIPS, and x86, they have different >>>> functions. >>>> >>> >>> Both mips and x86 end up mapping the same function, but other arches don't. >>> mn10300 is one where ioremap and ioremap_nocache are definitely different. >> >> alpha: identical >> arc: identical >> arm: identical >> arm64: identical >> cris: different<== >> frv: identical >> hexagone: identical >> ia64: different<== >> m32r: identical >> m68k: identical >> metag: identical >> microblaze: identical >> mips: identical >> mn10300: different <== >> nios: identical >> openrisc: different<== >> parisc: identical >> riscv: identical >> s390: identical >> sh: identical >> sparc: identical >> tile: identical >> um: rely on asm/generic >> unicore32: identical >> x86: identical >> asm/generic (no mmu): identical > > Wow, that's correct, sorry for I have just checked the main archs, I means > x86,arm, arm64, mips. > > However, I stall have no idea about why these 4 archs want different ioremap > function with others. Drivers seems cannot aware this? If driver call ioremap > want he really want for there 4 archs, cache or nocache? Could you please help about this? it is out of my knowledge. Thanks Yisheng > >> >> So 4 among all arches seems to have ioremap() and ioremap_nocache() being >> different. >> >> Could we have a define set by the 4 arches on which ioremap() and >> ioremap_nocache() are different, something like >> HAVE_DIFFERENT_IOREMAP_NOCACHE ? > > Then, what the HAVE_DIFFERENT_IOREMAP_NOCACHE is uesed for ? > > Thanks > Yisheng >> >> Christophe >> >>> >>> Guenter >>> >>>>> While ioremap's >>>>> default function is ioremap_nocache, so devm_ioremap_nocache also have the >>>>> same function with devm_ioremap, which can just be killed to reduce the >>>>> size >>>>> of devres.o(from 20304 bytes to 18992 bytes in my compile environment). >>>>> >>>>> I have posted two versions, which use macro instead of function for >>>>> devm_ioremap_nocache[1] or devm_ioremap[2]. And Greg suggest me to kill >>>>> devm_ioremap_nocache for no need to keep a macro around for the duplicate >>>>> thing. So here comes v3 and please help to review. >>>> >>>> I don't think this can be done, what am I missing? These functions are >>>> not identical, sorry for missing that before. > > Never mind, I should checked all the arches, sorry about that. > >>>> >>>> thanks, >>>> >>>> greg k-h >>>> >>> >>> -- >>> To unsubscribe from this list: send the line "unsubscribe linux-watchdog" in >>> the body of a message to majord...@vger.kernel.org >>> More majordomo info at http://vger.kernel.org/majordomo-info.html >> >> --- >> L'absence de virus dans ce courrier électronique a été vérifiée par le >> logiciel antivirus Avast. >> https://www.avast.com/antivirus >> >> >> . >> > > > . >
Re: [PATCH v3 27/27] devres: kill devm_ioremap_nocache
On 2017/12/23 21:45, Greg KH wrote:
> On Sat, Dec 23, 2017 at 07:02:59PM +0800, Yisheng Xie wrote:
>> --- a/lib/devres.c
>> +++ b/lib/devres.c
>> @@ -44,35 +44,6 @@ void __iomem *devm_ioremap(struct device *dev,
>> resource_size_t offset,
>> EXPORT_SYMBOL(devm_ioremap);
>>
>> /**
>> - * devm_ioremap_nocache - Managed ioremap_nocache()
>> - * @dev: Generic device to remap IO address for
>> - * @offset: Resource address to map
>> - * @size: Size of map
>> - *
>> - * Managed ioremap_nocache(). Map is automatically unmapped on driver
>> - * detach.
>> - */
>> -void __iomem *devm_ioremap_nocache(struct device *dev, resource_size_t
>> offset,
>> - resource_size_t size)
>> -{
>> -void __iomem **ptr, *addr;
>> -
>> -ptr = devres_alloc(devm_ioremap_release, sizeof(*ptr), GFP_KERNEL);
>> -if (!ptr)
>> -return NULL;
>> -
>> -addr = ioremap_nocache(offset, size);
>
> Wait, devm_ioremap() calls ioremap(), not ioremap_nocache(), are you
> _SURE_ that these are all identical? For all arches? If so, then
> ioremap_nocache() can also be removed, right?
Yeah, As Christophe pointed out, that 4 archs do not have the same function.
But I do not why they do not want do the same thing. Driver may no know about
this? right?
>
> In my quick glance, I don't think you can do this series at all :(
Yes, maybe should take Christophe suggestion and use a bool or enum to
distinguish them?
Thanks
Yisheng
>
> greg k-h
>
> .
>
Re: [PATCH v3 00/27] kill devm_ioremap_nocache
On 2017/12/24 17:05, christophe leroy wrote:
>
>
> Le 23/12/2017 à 14:48, Greg KH a écrit :
>> On Sat, Dec 23, 2017 at 06:55:25PM +0800, Yisheng Xie wrote:
>>> Hi all,
>>>
>>> When I tried to use devm_ioremap function and review related code, I found
>>> devm_ioremap and devm_ioremap_nocache is almost the same with each other,
>>> except one use ioremap while the other use ioremap_nocache.
>>
>> For all arches? Really? Look at MIPS, and x86, they have different
>> functions.
>>
>>> While ioremap's
>>> default function is ioremap_nocache, so devm_ioremap_nocache also have the
>>> same function with devm_ioremap, which can just be killed to reduce the size
>>> of devres.o(from 20304 bytes to 18992 bytes in my compile environment).
>>>
>>> I have posted two versions, which use macro instead of function for
>>> devm_ioremap_nocache[1] or devm_ioremap[2]. And Greg suggest me to kill
>>> devm_ioremap_nocache for no need to keep a macro around for the duplicate
>>> thing. So here comes v3 and please help to review.
>>
>> I don't think this can be done, what am I missing? These functions are
>> not identical, sorry for missing that before.
>
> devm_ioremap() and devm_ioremap_nocache() are quite similar, both use
> devm_ioremap_release() for the release, why not just defining:
>
> static void __iomem *__devm_ioremap(struct device *dev, resource_size_t
> offset,
>resource_size_t size, bool nocache)
> {
> [...]
> if (nocache)
> addr = ioremap_nocache(offset, size);
> else
> addr = ioremap(offset, size);
> [...]
> }
>
> then in include/linux/io.h
>
> static inline void __iomem *devm_ioremap(struct device *dev, resource_size_t
> offset,
>resource_size_t size)
> {return __devm_ioremap(dev, offset, size, false);}
>
> static inline void __iomem *devm_ioremap_nocache(struct device *dev,
> resource_size_t offset,
>resource_size_t size);
> {return __devm_ioremap(dev, offset, size, true);}
Yeah, this seems good to me, right now we have devm_ioremap, devm_ioremap_wc,
devm_ioremap_nocache
May be we can use an enum like:
typedef enum {
DEVM_IOREMAP = 0,
DEVM_IOREMAP_NOCACHE,
DEVM_IOREMAP_WC,
} devm_ioremap_type;
static inline void __iomem *devm_ioremap(struct device *dev, resource_size_t
offset,
resource_size_t size)
{return __devm_ioremap(dev, offset, size, DEVM_IOREMAP);}
static inline void __iomem *devm_ioremap_nocache(struct device *dev,
resource_size_t offset,
resource_size_t size);
{return __devm_ioremap(dev, offset, size, DEVM_IOREMAP_NOCACHE);}
static inline void __iomem *devm_ioremap_wc(struct device *dev,
resource_size_t offset,
resource_size_t size);
{return __devm_ioremap(dev, offset, size, DEVM_IOREMAP_WC);}
static void __iomem *__devm_ioremap(struct device *dev, resource_size_t offset,
resource_size_t size, devm_ioremap_type type)
{
void __iomem **ptr, *addr = NULL;
[...]
switch (type){
case DEVM_IOREMAP:
addr = ioremap(offset, size);
break;
case DEVM_IOREMAP_NOCACHE:
addr = ioremap_nocache(offset, size);
break;
case DEVM_IOREMAP_WC:
addr = ioremap_wc(offset, size);
break;
}
[...]
}
Thanks
Yisheng
>
> Christophe
>
>>
>> thanks,
>>
>> greg k-h
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-watchdog" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
> ---
> L'absence de virus dans ce courrier électronique a été vérifiée par le
> logiciel antivirus Avast.
> https://www.avast.com/antivirus
>
>
> .
>
Re: [PATCH v3 00/27] kill devm_ioremap_nocache
hi Christophe and Greg, On 2017/12/24 16:55, christophe leroy wrote: > > > Le 23/12/2017 à 16:57, Guenter Roeck a écrit : >> On 12/23/2017 05:48 AM, Greg KH wrote: >>> On Sat, Dec 23, 2017 at 06:55:25PM +0800, Yisheng Xie wrote: >>>> Hi all, >>>> >>>> When I tried to use devm_ioremap function and review related code, I found >>>> devm_ioremap and devm_ioremap_nocache is almost the same with each other, >>>> except one use ioremap while the other use ioremap_nocache. >>> >>> For all arches? Really? Look at MIPS, and x86, they have different >>> functions. >>> >> >> Both mips and x86 end up mapping the same function, but other arches don't. >> mn10300 is one where ioremap and ioremap_nocache are definitely different. > > alpha: identical > arc: identical > arm: identical > arm64: identical > cris: different<== > frv: identical > hexagone: identical > ia64: different<== > m32r: identical > m68k: identical > metag: identical > microblaze: identical > mips: identical > mn10300: different <== > nios: identical > openrisc: different<== > parisc: identical > riscv: identical > s390: identical > sh: identical > sparc: identical > tile: identical > um: rely on asm/generic > unicore32: identical > x86: identical > asm/generic (no mmu): identical Wow, that's correct, sorry for I have just checked the main archs, I means x86,arm, arm64, mips. However, I stall have no idea about why these 4 archs want different ioremap function with others. Drivers seems cannot aware this? If driver call ioremap want he really want for there 4 archs, cache or nocache? > > So 4 among all arches seems to have ioremap() and ioremap_nocache() being > different. > > Could we have a define set by the 4 arches on which ioremap() and > ioremap_nocache() are different, something like > HAVE_DIFFERENT_IOREMAP_NOCACHE ? Then, what the HAVE_DIFFERENT_IOREMAP_NOCACHE is uesed for ? Thanks Yisheng > > Christophe > >> >> Guenter >> >>>> While ioremap's >>>> default function is ioremap_nocache, so devm_ioremap_nocache also have the >>>> same function with devm_ioremap, which can just be killed to reduce the >>>> size >>>> of devres.o(from 20304 bytes to 18992 bytes in my compile environment). >>>> >>>> I have posted two versions, which use macro instead of function for >>>> devm_ioremap_nocache[1] or devm_ioremap[2]. And Greg suggest me to kill >>>> devm_ioremap_nocache for no need to keep a macro around for the duplicate >>>> thing. So here comes v3 and please help to review. >>> >>> I don't think this can be done, what am I missing? These functions are >>> not identical, sorry for missing that before. Never mind, I should checked all the arches, sorry about that. >>> >>> thanks, >>> >>> greg k-h >>> >> >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-watchdog" in >> the body of a message to majord...@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html > > --- > L'absence de virus dans ce courrier électronique a été vérifiée par le > logiciel antivirus Avast. > https://www.avast.com/antivirus > > > . >
[PATCH v3 27/27] devres: kill devm_ioremap_nocache
Now, nobody use devm_ioremap_nocache anymore, can it can just be
removed. After this patch the size of devres.o will be reduced from
20304 bytes to 18992 bytes.
Suggested-by: Greg KH
Signed-off-by: Yisheng Xie
---
Documentation/driver-model/devres.txt | 1 -
include/linux/io.h | 2 --
lib/devres.c| 29 -
scripts/coccinelle/free/devm_free.cocci | 2 --
4 files changed, 34 deletions(-)
diff --git a/Documentation/driver-model/devres.txt
b/Documentation/driver-model/devres.txt
index c180045..c3fddb5 100644
--- a/Documentation/driver-model/devres.txt
+++ b/Documentation/driver-model/devres.txt
@@ -292,7 +292,6 @@ IOMAP
devm_ioport_map()
devm_ioport_unmap()
devm_ioremap()
- devm_ioremap_nocache()
devm_ioremap_wc()
devm_ioremap_resource() : checks resource, requests memory region, ioremaps
devm_iounmap()
diff --git a/include/linux/io.h b/include/linux/io.h
index 32e30e8..a9c7270 100644
--- a/include/linux/io.h
+++ b/include/linux/io.h
@@ -75,8 +75,6 @@ static inline void devm_ioport_unmap(struct device *dev, void
__iomem *addr)
void __iomem *devm_ioremap(struct device *dev, resource_size_t offset,
resource_size_t size);
-void __iomem *devm_ioremap_nocache(struct device *dev, resource_size_t offset,
- resource_size_t size);
void __iomem *devm_ioremap_wc(struct device *dev, resource_size_t offset,
resource_size_t size);
void devm_iounmap(struct device *dev, void __iomem *addr);
diff --git a/lib/devres.c b/lib/devres.c
index 5f2aedd..f818fcf 100644
--- a/lib/devres.c
+++ b/lib/devres.c
@@ -44,35 +44,6 @@ void __iomem *devm_ioremap(struct device *dev,
resource_size_t offset,
EXPORT_SYMBOL(devm_ioremap);
/**
- * devm_ioremap_nocache - Managed ioremap_nocache()
- * @dev: Generic device to remap IO address for
- * @offset: Resource address to map
- * @size: Size of map
- *
- * Managed ioremap_nocache(). Map is automatically unmapped on driver
- * detach.
- */
-void __iomem *devm_ioremap_nocache(struct device *dev, resource_size_t offset,
- resource_size_t size)
-{
- void __iomem **ptr, *addr;
-
- ptr = devres_alloc(devm_ioremap_release, sizeof(*ptr), GFP_KERNEL);
- if (!ptr)
- return NULL;
-
- addr = ioremap_nocache(offset, size);
- if (addr) {
- *ptr = addr;
- devres_add(dev, ptr);
- } else
- devres_free(ptr);
-
- return addr;
-}
-EXPORT_SYMBOL(devm_ioremap_nocache);
-
-/**
* devm_ioremap_wc - Managed ioremap_wc()
* @dev: Generic device to remap IO address for
* @offset: Resource address to map
diff --git a/scripts/coccinelle/free/devm_free.cocci
b/scripts/coccinelle/free/devm_free.cocci
index c990d2c..36b8752 100644
--- a/scripts/coccinelle/free/devm_free.cocci
+++ b/scripts/coccinelle/free/devm_free.cocci
@@ -51,8 +51,6 @@ expression x;
|
x = devm_ioremap(...)
|
- x = devm_ioremap_nocache(...)
-|
x = devm_ioport_map(...)
)
--
1.8.3.1
[PATCH v3 05/27] media: replace devm_ioremap_nocache with devm_ioremap
Default ioremap is ioremap_nocache, so devm_ioremap has the same
function with devm_ioremap_nocache, which can just be killed to
save the size of devres.o
This patch is to use use devm_ioremap instead of devm_ioremap_nocache,
which should not have any function change but prepare for killing
devm_ioremap_nocache.
Cc: Mauro Carvalho Chehab
Cc: linux-media@vger.kernel.org
Signed-off-by: Yisheng Xie
---
drivers/media/platform/tegra-cec/tegra_cec.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/tegra-cec/tegra_cec.c
b/drivers/media/platform/tegra-cec/tegra_cec.c
index 807c94c..425728a 100644
--- a/drivers/media/platform/tegra-cec/tegra_cec.c
+++ b/drivers/media/platform/tegra-cec/tegra_cec.c
@@ -371,8 +371,8 @@ static int tegra_cec_probe(struct platform_device *pdev)
if (cec->tegra_cec_irq <= 0)
return -EBUSY;
- cec->cec_base = devm_ioremap_nocache(&pdev->dev, res->start,
-resource_size(res));
+ cec->cec_base = devm_ioremap(&pdev->dev, res->start,
+resource_size(res));
if (!cec->cec_base) {
dev_err(&pdev->dev, "Unable to grab IOs for device\n");
--
1.8.3.1
[PATCH v3 00/27] kill devm_ioremap_nocache
Hi all, When I tried to use devm_ioremap function and review related code, I found devm_ioremap and devm_ioremap_nocache is almost the same with each other, except one use ioremap while the other use ioremap_nocache. While ioremap's default function is ioremap_nocache, so devm_ioremap_nocache also have the same function with devm_ioremap, which can just be killed to reduce the size of devres.o(from 20304 bytes to 18992 bytes in my compile environment). I have posted two versions, which use macro instead of function for devm_ioremap_nocache[1] or devm_ioremap[2]. And Greg suggest me to kill devm_ioremap_nocache for no need to keep a macro around for the duplicate thing. So here comes v3 and please help to review. Thanks so much! Yisheng Xie [1] https://lkml.org/lkml/2017/11/20/135 [2] https://lkml.org/lkml/2017/11/25/21 Yisheng Xie (27): ASOC: replace devm_ioremap_nocache with devm_ioremap spi: replace devm_ioremap_nocache with devm_ioremap staging: replace devm_ioremap_nocache with devm_ioremap ipack: replace devm_ioremap_nocache with devm_ioremap media: replace devm_ioremap_nocache with devm_ioremap gpio: replace devm_ioremap_nocache with devm_ioremap mmc: replace devm_ioremap_nocache with devm_ioremap PCI: replace devm_ioremap_nocache with devm_ioremap platform/x86: replace devm_ioremap_nocache with devm_ioremap tty: replace devm_ioremap_nocache with devm_ioremap video: replace devm_ioremap_nocache with devm_ioremap rtc: replace devm_ioremap_nocache with devm_ioremap char: replace devm_ioremap_nocache with devm_ioremap mtd: nand: replace devm_ioremap_nocache with devm_ioremap dmaengine: replace devm_ioremap_nocache with devm_ioremap ata: replace devm_ioremap_nocache with devm_ioremap irqchip: replace devm_ioremap_nocache with devm_ioremap pinctrl: replace devm_ioremap_nocache with devm_ioremap drm: replace devm_ioremap_nocache with devm_ioremap regulator: replace devm_ioremap_nocache with devm_ioremap watchdog: replace devm_ioremap_nocache with devm_ioremap tools/testing/nvdimm: replace devm_ioremap_nocache with devm_ioremap MIPS: pci: replace devm_ioremap_nocache with devm_ioremap can: replace devm_ioremap_nocache with devm_ioremap wireless: replace devm_ioremap_nocache with devm_ioremap ethernet: replace devm_ioremap_nocache with devm_ioremap devres: kill devm_ioremap_nocache Documentation/driver-model/devres.txt | 1 - arch/mips/pci/pci-ar2315.c | 3 +-- drivers/ata/pata_arasan_cf.c| 3 +-- drivers/ata/pata_octeon_cf.c| 9 drivers/ata/pata_rb532_cf.c | 2 +- drivers/char/hw_random/bcm63xx-rng.c| 3 +-- drivers/char/hw_random/octeon-rng.c | 10 - drivers/dma/altera-msgdma.c | 3 +-- drivers/dma/sprd-dma.c | 4 ++-- drivers/gpio/gpio-ath79.c | 3 +-- drivers/gpio/gpio-em.c | 6 ++--- drivers/gpio/gpio-htc-egpio.c | 4 ++-- drivers/gpio/gpio-xgene.c | 3 +-- drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 2 +- drivers/gpu/drm/msm/msm_drv.c | 2 +- drivers/gpu/drm/sti/sti_dvo.c | 3 +-- drivers/gpu/drm/sti/sti_hda.c | 4 ++-- drivers/gpu/drm/sti/sti_hdmi.c | 2 +- drivers/gpu/drm/sti/sti_tvout.c | 2 +- drivers/gpu/drm/sti/sti_vtg.c | 2 +- drivers/ipack/devices/ipoctal.c | 13 +-- drivers/irqchip/irq-renesas-intc-irqpin.c | 4 ++-- drivers/media/platform/tegra-cec/tegra_cec.c| 4 ++-- drivers/mmc/host/sdhci-acpi.c | 3 +-- drivers/mtd/nand/fsl_upm.c | 4 ++-- drivers/net/can/sja1000/sja1000_platform.c | 4 ++-- drivers/net/ethernet/altera/altera_tse_main.c | 3 +-- drivers/net/ethernet/ethoc.c| 8 +++ drivers/net/ethernet/lantiq_etop.c | 4 ++-- drivers/net/ethernet/ti/netcp_core.c| 2 +- drivers/net/wireless/ath/ath9k/ahb.c| 2 +- drivers/pci/dwc/pci-dra7xx.c| 2 +- drivers/pinctrl/bcm/pinctrl-ns2-mux.c | 2 +- drivers/pinctrl/bcm/pinctrl-nsp-mux.c | 4 ++-- drivers/pinctrl/freescale/pinctrl-imx1-core.c | 2 +- drivers/pinctrl/pinctrl-amd.c | 4 ++-- drivers/platform/x86/intel_pmc_core.c | 5 ++--- drivers/regulator/ti-abb-regulator.c| 6 ++--- drivers/rtc/rtc-sh.c| 4 ++-- drivers/spi/spi-jcore.c | 3 +-- drivers/staging/fsl-mc/bus/mc-io.c | 8 +++ drivers/tty/mips_ejtag_fdc.c| 4 ++-- drivers/tty/serial/8250/8250_omap.c | 3 +-- drivers/tty/serial/lantiq.c | 3 +-- drivers/tty/serial/meson_u
[PATCH v1] [media] uvcvideo: mark buffer error where overflow
Some cameras post inaccurate frame where next frame data overlap
it. this results in screen flicker, and it need to be prevented.
So this patch marks the buffer error to discard the frame where
buffer overflow.
Signed-off-by: Baoyou Xie
---
drivers/media/usb/uvc/uvc_video.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/media/usb/uvc/uvc_video.c
b/drivers/media/usb/uvc/uvc_video.c
index fb86d6a..81a3530 100644
--- a/drivers/media/usb/uvc/uvc_video.c
+++ b/drivers/media/usb/uvc/uvc_video.c
@@ -1077,6 +1077,7 @@ static void uvc_video_decode_data(struct uvc_streaming
*stream,
/* Complete the current frame if the buffer size was exceeded. */
if (len > maxlen) {
uvc_trace(UVC_TRACE_FRAME, "Frame complete (overflow).\n");
+ buf->error = 1;
buf->state = UVC_BUF_STATE_READY;
}
}
--
2.7.4
[PATCH v1] [media] uvcvideo: mark buffer error where overflow
Some cameras post inaccurate frame where next frame data overlap
it. this results in screen flicker, and it need to be prevented.
So this patch marks the buffer error to discard the frame where
buffer overflow.
Signed-off-by: Baoyou Xie
---
drivers/media/usb/uvc/uvc_video.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/media/usb/uvc/uvc_video.c
b/drivers/media/usb/uvc/uvc_video.c
index fb86d6a..81a3530 100644
--- a/drivers/media/usb/uvc/uvc_video.c
+++ b/drivers/media/usb/uvc/uvc_video.c
@@ -1077,6 +1077,7 @@ static void uvc_video_decode_data(struct uvc_streaming
*stream,
/* Complete the current frame if the buffer size was exceeded. */
if (len > maxlen) {
uvc_trace(UVC_TRACE_FRAME, "Frame complete (overflow).\n");
+ buf->error = 1;
buf->state = UVC_BUF_STATE_READY;
}
}
--
2.7.4
[PATCH] [media] coda: add missing header dependencies
We get 1 warning when building kernel with W=1:
drivers/media/platform/coda/coda-h264.c:21:5: warning: no previous prototype
for 'coda_h264_padding' [-Wmissing-prototypes]
In fact, this function is declared in drivers/media/platform/coda/coda.h,
so this patch adds missing header dependencies.
Signed-off-by: Baoyou Xie
---
drivers/media/platform/coda/coda-h264.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/media/platform/coda/coda-h264.c
b/drivers/media/platform/coda/coda-h264.c
index 456773a..6d6f555 100644
--- a/drivers/media/platform/coda/coda-h264.c
+++ b/drivers/media/platform/coda/coda-h264.c
@@ -13,6 +13,7 @@
#include
#include
+#include "coda.h"
static const u8 coda_filler_nal[14] = { 0x00, 0x00, 0x00, 0x01, 0x0c, 0xff,
0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x80 };
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] dma-buf/sw_sync: mark sync_timeline_create() static
We get 1 warning when building kernel with W=1:
drivers/dma-buf/sw_sync.c:87:23: warning: no previous prototype for
'sync_timeline_create' [-Wmissing-prototypes]
In fact, this function is only used in the file in which it is
declared and don't need a declaration, but can be made static.
So this patch marks it 'static'.
Signed-off-by: Baoyou Xie
---
drivers/dma-buf/sw_sync.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/dma-buf/sw_sync.c b/drivers/dma-buf/sw_sync.c
index 62e8e6d..6f16c85 100644
--- a/drivers/dma-buf/sw_sync.c
+++ b/drivers/dma-buf/sw_sync.c
@@ -84,7 +84,7 @@ static inline struct sync_pt *fence_to_sync_pt(struct fence
*fence)
* Creates a new sync_timeline. Returns the sync_timeline object or NULL in
* case of error.
*/
-struct sync_timeline *sync_timeline_create(const char *name)
+static struct sync_timeline *sync_timeline_create(const char *name)
{
struct sync_timeline *obj;
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] dma-buf/sw_sync: mark sync_timeline_create() static
We get 1 warning when building kernel with W=1:
drivers/dma-buf/sw_sync.c:87:23: warning: no previous prototype for
'sync_timeline_create' [-Wmissing-prototypes]
In fact, this function is only used in the file in which it is
declared and don't need a declaration, but can be made static.
So this patch marks it 'static'.
Signed-off-by: Baoyou Xie
---
drivers/dma-buf/sw_sync.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/dma-buf/sw_sync.c b/drivers/dma-buf/sw_sync.c
index 62e8e6d..6f16c85 100644
--- a/drivers/dma-buf/sw_sync.c
+++ b/drivers/dma-buf/sw_sync.c
@@ -84,7 +84,7 @@ static inline struct sync_pt *fence_to_sync_pt(struct fence
*fence)
* Creates a new sync_timeline. Returns the sync_timeline object or NULL in
* case of error.
*/
-struct sync_timeline *sync_timeline_create(const char *name)
+static struct sync_timeline *sync_timeline_create(const char *name)
{
struct sync_timeline *obj;
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [media] coda: add missing header dependencies
We get 1 warning when building kernel with W=1:
drivers/media/platform/coda/coda-h264.c:22:5: warning: no previous prototype
for 'coda_h264_padding' [-Wmissing-prototypes]
In fact, this function is declared in coda.h, so this patch
add missing header dependencies.
Signed-off-by: Baoyou Xie
---
drivers/media/platform/coda/coda-h264.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/media/platform/coda/coda-h264.c
b/drivers/media/platform/coda/coda-h264.c
index 456773a..09dfcca 100644
--- a/drivers/media/platform/coda/coda-h264.c
+++ b/drivers/media/platform/coda/coda-h264.c
@@ -13,6 +13,7 @@
#include
#include
+#include
static const u8 coda_filler_nal[14] = { 0x00, 0x00, 0x00, 0x01, 0x0c, 0xff,
0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x80 };
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] staging: media: omap4iss: mark omap4iss_flush() static
We get 1 warning when building kernel with W=1:
drivers/staging/media/omap4iss/iss.c:64:6: warning: no previous prototype for
'omap4iss_flush' [-Wmissing-prototypes]
In fact, this function is only used in the file in which it is
declared and don't need a declaration, but can be made static.
so this patch marks this function with 'static'.
Signed-off-by: Baoyou Xie
---
drivers/staging/media/omap4iss/iss.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/media/omap4iss/iss.c
b/drivers/staging/media/omap4iss/iss.c
index 6ceb4eb..e27c7a9 100644
--- a/drivers/staging/media/omap4iss/iss.c
+++ b/drivers/staging/media/omap4iss/iss.c
@@ -61,7 +61,7 @@ static void iss_print_status(struct iss_device *iss)
* See this link for reference:
* http://www.mail-archive.com/linux-omap@vger.kernel.org/msg08149.html
*/
-void omap4iss_flush(struct iss_device *iss)
+static void omap4iss_flush(struct iss_device *iss)
{
iss_reg_write(iss, OMAP4_ISS_MEM_TOP, ISS_HL_REVISION, 0);
iss_reg_read(iss, OMAP4_ISS_MEM_TOP, ISS_HL_REVISION);
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
I wish you good luck everyday
Dear Dongsoo, Nathaniel ~~ Thanks very much for your help ~~ I am very Sorry to have taken up so much of your time and you always be so patient. You must be an angel ~~ I am making progress with the help of yours ~ I wish you good luck everyday with all my heart ~~ 在 2009-06-11四的 19:21 +0900，Dongsoo, Nathaniel Kim写道： > Sorry, I have no idea about that. > I have never been that far. > > The only thing I ever heard about v4l2 output, is on ELC 2009 > presentation list. You can find at following URL: > http://tree.celinuxforum.org/CelfPubWiki/ELC2009Presentations > Just look for Matthew Porter's presentation. > > Or maintainer who is responsible for v4l2 output can help you I > guess.(but not me) > Cheers, > > Nate > > > On Thu, Jun 11, 2009 at 7:06 PM, xie wrote: > > Dear Dongsoo Nathaniel ~~ > > > > Does the capture interface get the image and the output interface > > display the image ~ ? > > > > Best regards ~ > > > > > > > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
About v4l2 output interface
Dear Dongsoo Nathaniel ~~ Does the capture interface get the image and the output interface display the image ~ ? Best regards ~ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
About v4l2 output interface
Dear Dongsoo Nathaniel ~~ In the spec , I have readed this sentence : Video output devices encode stills or image sequences as analog video signal. Can you give me a function-example about output interface in real life ~~ ? Thanks ~ Best regards ~!~ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
About V4l2 overlay sequence
Dear all ~~ With your help I have implemented the preview with capture interface ~~ Now i want to implement the preview with ovelay , and my camera support s ovelay ~ Who can tell me where I can find the document about ovelay sequcence ~ ? Or does there have a standard example source code ~ ? Thanks a lot ~ Best regards -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: About the VIDIOC_DQBUF
hi ~~ I have found the problem ~~ The 3'rd partner didn't give us the right v4l2 driver. Thanks for your help ~~ Best wishes 在 2009-06-09二的 16:41 +0900，Dongsoo, Nathaniel Kim写道： > Hi, > > Sorry I still don't get what the full frame means, but I might > consider that is the maximum resolution-ed image data coming from > external camera module. And whatever it is, you might have no problem > getting data through memcpy with buf.byteused size. > Cheers, > > Nate > > On Tue, Jun 9, 2009 at 11:22 AM, xie wrote: > > hi ~~ Dongsoo, Nathaniel ~ > > > > I am sorry for disturbing you, and not descripe the question clear ~ > > Thanks very much for your help ~~ > > > > I know that I must stop preview with streamoff and re-configure with > > s_fmt ~~ I have asked to you before ~!~ > > > > The "full frame" means a complete frame ~Because I just need to get the > > frame data and post it to multimedia framework, so I want to consult to > > you that if I can get a complete frame with memcpy ~~ > > > > I want to know that can I get a complete frame from buf.start to the > > end , and the memory-lenth is buf.byteused ~ > > > >buf.byteused > >|-| > > buf.startend > > > > > > > > > > > > > > > > 在 2009-06-08一的 20:40 +0900，Dongsoo, Nathaniel Kim写道： > >> Hi, > >> > >> Sorry I'm not an expert, you can expect expertise from maintainers not > >> from me. > >> But before answering your question about capturing, I'm not sure about > >> what the "full frame" means. I just assume that you meant to say the > >> biggest resolution of image frame, right? > >> > >> So, when you are to capture a full resolution data while preview is > >> working, you need to stop preview with streamoff, re-configure > >> resolution with s_fmt to external camera module and start capturing > >> issuing streamon with re-configured resolution. I think you are > >> well-aware with this, aren't you? And in my opinion, memcpy may be > >> cool for that. What else are you expecting to use? and for what? > >> Anyway, I wish you luck. > >> Cheers, > >> > >> Nate > >> > >> > >> On Mon, Jun 8, 2009 at 5:02 PM, xie wrote: > >> > Hi Dongsoo, Nathaniel ~ > >> > You must be expert on V4l2 ~ Thanks very much for your help and advice > >> > ~!~ > >> > I used the MXC camera interface driver from Fressscale ,I readed the > >> > driver interface just now ,and have fouded that the driver not modified > >> > the buf.lenth but buf.byteused . You are very right , I will use the > >> > buf.byteused instead of buf.length ~ > >> > > >> > There is also a problem I want to consult to you ~ Can i get a full > >> > frame with the below method if the driver have no problem ? > >> > > >> > memcpy((mCameraProwave->getPreviewHeap())->base(), > >> > v4l2Buffer[buf.index].start, buf.byteused) ; > >> > > >> > Because I just need to implement a hal for getting the frame data and > >> > post it to top layer , so I used the memcpy simply . Am I right ~ ? Or > >> > what about your advice ? > >> > > >> > Thanks a lot ~~ > >> > > >> > > >> > > >> > 在 2009-06-08一的 15:56 +0900，Dongsoo, Nathaniel Kim写道： > >> >> Hello Xie, > >> >> > >> >> I'm not sure which camera interface driver you are using, but it seems > >> >> to be camera interface driver's problem. Let me guess, are you using > >> >> pxa camera interface driver from Marvell?(proprietary but not in up > >> >> stream kernel) > >> >> It just looks like that camera interface driver is not returning > >> >> proper data in dqbuf. > >> >> > >> >> And one more thing. I prefer to use byteused rather than length in > >> >> buf. because as far as I know the size of preview data from camera is > >> >> in byte unit which we need to copy to memory. But it should be > >> >> possible to use length, I guess.. > >> >> Cheers, > >> >> > >> >> Nate > >> >> > >> >> On Mon, Jun 8, 2009 at 11:05 AM, xie wrote: > >> >> > Dear all ~~ > >> >> > > >&
Re: About the VIDIOC_DQBUF
hi ~~ Dongsoo, Nathaniel ~
I am sorry for disturbing you, and not descripe the question clear ~
Thanks very much for your help ~~
I know that I must stop preview with streamoff and re-configure with
s_fmt ~~ I have asked to you before ~!~
The "full frame" means a complete frame ~Because I just need to get the
frame data and post it to multimedia framework, so I want to consult to
you that if I can get a complete frame with memcpy ~~
I want to know that can I get a complete frame from buf.start to the
end , and the memory-lenth is buf.byteused ~
buf.byteused
|-|
buf.startend
在 2009-06-08一的 20:40 +0900，Dongsoo, Nathaniel Kim写道：
> Hi,
>
> Sorry I'm not an expert, you can expect expertise from maintainers not from
> me.
> But before answering your question about capturing, I'm not sure about
> what the "full frame" means. I just assume that you meant to say the
> biggest resolution of image frame, right?
>
> So, when you are to capture a full resolution data while preview is
> working, you need to stop preview with streamoff, re-configure
> resolution with s_fmt to external camera module and start capturing
> issuing streamon with re-configured resolution. I think you are
> well-aware with this, aren't you? And in my opinion, memcpy may be
> cool for that. What else are you expecting to use? and for what?
> Anyway, I wish you luck.
> Cheers,
>
> Nate
>
>
> On Mon, Jun 8, 2009 at 5:02 PM, xie wrote:
> > Hi Dongsoo, Nathaniel ~
> > You must be expert on V4l2 ~ Thanks very much for your help and advice
> > ~!~
> > I used the MXC camera interface driver from Fressscale ,I readed the
> > driver interface just now ,and have fouded that the driver not modified
> > the buf.lenth but buf.byteused . You are very right , I will use the
> > buf.byteused instead of buf.length ~
> >
> > There is also a problem I want to consult to you ~ Can i get a full
> > frame with the below method if the driver have no problem ?
> >
> > memcpy((mCameraProwave->getPreviewHeap())->base(),
> > v4l2Buffer[buf.index].start, buf.byteused) ;
> >
> > Because I just need to implement a hal for getting the frame data and
> > post it to top layer , so I used the memcpy simply . Am I right ~ ? Or
> > what about your advice ?
> >
> > Thanks a lot ~~
> >
> >
> >
> > 在 2009-06-08一的 15:56 +0900，Dongsoo, Nathaniel Kim写道：
> >> Hello Xie,
> >>
> >> I'm not sure which camera interface driver you are using, but it seems
> >> to be camera interface driver's problem. Let me guess, are you using
> >> pxa camera interface driver from Marvell?(proprietary but not in up
> >> stream kernel)
> >> It just looks like that camera interface driver is not returning
> >> proper data in dqbuf.
> >>
> >> And one more thing. I prefer to use byteused rather than length in
> >> buf. because as far as I know the size of preview data from camera is
> >> in byte unit which we need to copy to memory. But it should be
> >> possible to use length, I guess..
> >> Cheers,
> >>
> >> Nate
> >>
> >> On Mon, Jun 8, 2009 at 11:05 AM, xie wrote:
> >> > Dear all ~~
> >> >
> >> > I have met a issue when I used the mmap method for previewing . I just
> >> > used the standard code as spec to get the image data :
> >> > status_t CameraHardwareProwave::V4l2Camera::v4l2CaptureMainloop()
> >> > {
> >> >LOG_FUNCTION_NAME
> >> >int rt ;
> >> >unsigned int i ;
> >> >fd_set fds ;
> >> >struct timeval tv ;
> >> >struct v4l2_buffer buf ;
> >> >
> >> >for(;;){
> >> >FD_ZERO(&fds) ;
> >> >FD_SET(v4l2Fd, &fds) ;
> >> >//now the time is long ,just for debug
> >> >tv.tv_sec = 2 ;
> >> >tv.tv_usec = 0 ;
> >> >
> >> >rt = select(v4l2Fd + 1, &fds, NULL, NULL, &tv) ;
> >> >LOGD("The value of select return : %d\n", rt) ;
> >> >
> >> >/** for debug
> >> >if(V4L2_NOERROR != v4l2ReadFrame()){
> >> >LOGE("READ ERROR") ;
> >> >}
> >> >***/
> >> &
Re: About the VIDIOC_DQBUF
Hi Dongsoo, Nathaniel ~
You must be expert on V4l2 ~ Thanks very much for your help and advice
~!~
I used the MXC camera interface driver from Fressscale ,I readed the
driver interface just now ,and have fouded that the driver not modified
the buf.lenth but buf.byteused . You are very right , I will use the
buf.byteused instead of buf.length ~
There is also a problem I want to consult to you ~ Can i get a full
frame with the below method if the driver have no problem ?
memcpy((mCameraProwave->getPreviewHeap())->base(),
v4l2Buffer[buf.index].start, buf.byteused) ;
Because I just need to implement a hal for getting the frame data and
post it to top layer , so I used the memcpy simply . Am I right ~ ? Or
what about your advice ?
Thanks a lot ~~
在 2009-06-08一的 15:56 +0900，Dongsoo, Nathaniel Kim写道：
> Hello Xie,
>
> I'm not sure which camera interface driver you are using, but it seems
> to be camera interface driver's problem. Let me guess, are you using
> pxa camera interface driver from Marvell?(proprietary but not in up
> stream kernel)
> It just looks like that camera interface driver is not returning
> proper data in dqbuf.
>
> And one more thing. I prefer to use byteused rather than length in
> buf. because as far as I know the size of preview data from camera is
> in byte unit which we need to copy to memory. But it should be
> possible to use length, I guess..
> Cheers,
>
> Nate
>
> On Mon, Jun 8, 2009 at 11:05 AM, xie wrote:
> > Dear all ~~
> >
> > I have met a issue when I used the mmap method for previewing . I just
> > used the standard code as spec to get the image data :
> > status_t CameraHardwareProwave::V4l2Camera::v4l2CaptureMainloop()
> > {
> >LOG_FUNCTION_NAME
> >int rt ;
> >unsigned int i ;
> >fd_set fds ;
> >struct timeval tv ;
> >struct v4l2_buffer buf ;
> >
> >for(;;){
> >FD_ZERO(&fds) ;
> >FD_SET(v4l2Fd, &fds) ;
> >//now the time is long ,just for debug
> >tv.tv_sec = 2 ;
> >tv.tv_usec = 0 ;
> >
> >rt = select(v4l2Fd + 1, &fds, NULL, NULL, &tv) ;
> >LOGD("The value of select return : %d\n", rt) ;
> >
> >/** for debug
> >if(V4L2_NOERROR != v4l2ReadFrame()){
> >LOGE("READ ERROR") ;
> >}
> >***/
> >
> >if(-1 == rt){
> >LOGE("there is something wrong in select
> > function(select)") ;
> >//no defined error manage
> >return V4L2_IOCTL_ERROR ;
> >}
> >if(0 == rt){
> >LOGE("wait for data timeout in select") ;
> >return V4L2_TIMEOUT ;
> >}
> >
> >memset(&buf, 0, sizeof(buf)) ;
> >buf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE ;
> >buf.memory = V4L2_MEMORY_MMAP ;
> >if(-1 == ioctl(v4l2Fd, VIDIOC_DQBUF, &buf)){
> >LOGE("there is something wrong in dequeue
> > buffer(VIDIOC_DQBUF)") ;
> >return V4L2_IOCTL_ERROR ;
> >}
> >
> >assert(i < n_buf) ;
> >LOGE("buf.index 0buf.length = %d %d \n", buf.index ,
> > buf.length) ;
> >memcpy((mCameraProwave->getPreviewHeap())->base(),
> > v4l2Buffer[buf.index].start, buf.length) ;
> >if(-1 == ioctl(v4l2Fd, VIDIOC_QBUF, &buf)){
> >LOGE("there is something wrong in enqueue
> > buffer(VIDIOC_QBUF)") ;
> >return V4L2_IOCTL_ERROR ;
> >}
> >//break ; //i don't know whether the break is needed ;
> >
> >}
> >return V4L2_NOERROR ;
> > }
> >
> > when executed the VIDIOC_DQBUF IOCTL,the return value was right, but the
> > value of buf.length would always be zero. Then I used the read()
> > function to read raw data in the file handle for debug, and I can get
> > the raw data. Anybody have met this issue before ? Who can give me some
> > advices or tell me what is wrong , thanks a lot ~
> >
> >
>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
About the VIDIOC_DQBUF
Dear all ~~
I have met a issue when I used the mmap method for previewing . I just
used the standard code as spec to get the image data :
status_t CameraHardwareProwave::V4l2Camera::v4l2CaptureMainloop()
{
LOG_FUNCTION_NAME
int rt ;
unsigned int i ;
fd_set fds ;
struct timeval tv ;
struct v4l2_buffer buf ;
for(;;){
FD_ZERO(&fds) ;
FD_SET(v4l2Fd, &fds) ;
//now the time is long ,just for debug
tv.tv_sec = 2 ;
tv.tv_usec = 0 ;
rt = select(v4l2Fd + 1, &fds, NULL, NULL, &tv) ;
LOGD("The value of select return : %d\n", rt) ;
/** for debug
if(V4L2_NOERROR != v4l2ReadFrame()){
LOGE("READ ERROR") ;
}
***/
if(-1 == rt){
LOGE("there is something wrong in select
function(select)") ;
//no defined error manage
return V4L2_IOCTL_ERROR ;
}
if(0 == rt){
LOGE("wait for data timeout in select") ;
return V4L2_TIMEOUT ;
}
memset(&buf, 0, sizeof(buf)) ;
buf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE ;
buf.memory = V4L2_MEMORY_MMAP ;
if(-1 == ioctl(v4l2Fd, VIDIOC_DQBUF, &buf)){
LOGE("there is something wrong in dequeue
buffer(VIDIOC_DQBUF)") ;
return V4L2_IOCTL_ERROR ;
}
assert(i < n_buf) ;
LOGE("buf.index 0buf.length = %d %d \n", buf.index ,
buf.length) ;
memcpy((mCameraProwave->getPreviewHeap())->base(),
v4l2Buffer[buf.index].start, buf.length) ;
if(-1 == ioctl(v4l2Fd, VIDIOC_QBUF, &buf)){
LOGE("there is something wrong in enqueue
buffer(VIDIOC_QBUF)") ;
return V4L2_IOCTL_ERROR ;
}
//break ; //i don't know whether the break is needed ;
}
return V4L2_NOERROR ;
}
when executed the VIDIOC_DQBUF IOCTL,the return value was right, but the
value of buf.length would always be zero. Then I used the read()
function to read raw data in the file handle for debug, and I can get
the raw data. Anybody have met this issue before ? Who can give me some
advices or tell me what is wrong , thanks a lot ~
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
