This message is generated daily by a cron job that builds media_tree for
the kernels and architectures in the list below.
Results of the daily build of media_tree:
date: Fri Mar 1 05:00:11 CET 2019
media-tree git hash:9fabe1d108ca4755a880de43f751f1c054f8894d
media_build git
On Mon, Feb 11, 2019 at 7:42 AM Souptick Joarder wrote:
>
> On Mon, Feb 4, 2019 at 8:27 PM Souptick Joarder wrote:
> >
> > There is no point to continuing assignment after memory allocation
> > failed, rather throw error immediately.
> >
> > Signed-off-by: Souptick Joarder
>
> Any comment on thi
Hi Daniel,
On Thu, 2019-02-28 at 02:01:46 -0800, Daniel Vetter wrote:
> On Wed, Feb 27, 2019 at 04:36:06PM -0800, Hyun Kwon wrote:
> > Hi Daniel,
> >
> > On Wed, 2019-02-27 at 06:13:45 -0800, Daniel Vetter wrote:
> > > On Tue, Feb 26, 2019 at 11:20 PM Hyun Kwon wrote:
> > > >
> > > > Hi Daniel,
Function `sh_veu_find_fmt` returns an address that is an addition of a
base pointer `sh_veu_fmt` and an offset. The base pointer refers to a
global variable of which address cannot be NULL. Therefore, this commit
removes the NULL pointer checks on the return values of function
`sh_veu_find_fmt`.
S
Hi Amila,
I believe this topic might get more attention on the linux-media mailing
list (which I've added to Cc), but I have some comments below too:
On 27/02/2019 16:41, Amila Manoj wrote:
> Hello,
>
>
> I'm trying to get this camera working with Ubuntu 18 (4.15.0-20-generic
> x86_64 GNU/Linu
The vim2m driver doesn't enforce that the capture and output
buffers would have the same size. Do the right thing if the
buffers are different, zeroing the buffer before writing,
ensuring that lines will be aligned and it won't write past
the buffer area.
This is a temporary fix.
A proper fix is
Em Thu, 28 Feb 2019 14:59:21 -0300
Mauro Carvalho Chehab escreveu:
> The vim2m driver doesn't enforce that the capture and output
> buffers would have the same size. Do the right thing if the
> buffers are different, zeroing the buffer before writing,
> ensuring that lines will be aligned and it
The vim2m driver doesn't enforce that the capture and output
buffers would have the same size. Do the right thing if the
buffers are different, zeroing the buffer before writing,
ensuring that lines will be aligned and it won't write past
the buffer area.
This is a temporary fix.
A proper fix is
Em Thu, 28 Feb 2019 16:42:28 +0100
Hans Verkuil escreveu:
> On 2/28/19 4:21 PM, Mauro Carvalho Chehab wrote:
> > Em Thu, 28 Feb 2019 15:35:07 +0100
> > Hans Verkuil escreveu:
> >
> >> On 2/28/19 3:09 PM, Mauro Carvalho Chehab wrote:
> >>> Em Thu, 28 Feb 2019 13:30:49 +0100
> >>> Hans Verkui
Avoid call of dmaengine_terminate_all() between
dmaengine_prep_slave_single() and dmaengine_submit() by locking
the whole DMA submission sequence.
Signed-off-by: Hugues Fruchet
---
drivers/media/platform/stm32/stm32-dcmi.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/dr
Start streaming was sometimes failing because of pm_runtime_get_sync()
non-0 return value. In fact return value was not an error but a
positive value (1), indicating that PM was already enabled.
Fix this by going to error path only with negative return value.
Signed-off-by: Hugues Fruchet
---
dr
Le jeudi 28 février 2019 à 09:12 +0800, Ayaka a écrit :
> > On Feb 28, 2019, at 5:07 AM, Nicolas Dufresne wrote:
> >
> > Hi Ayaka,
> >
> > > Le mercredi 27 février 2019 à 23:13 +0800, Ayaka a écrit :
> > > Last time in FOSDEM, kwiboo and I talk some problems of the request
> > > API and stateles
On 2/28/19 4:21 PM, Mauro Carvalho Chehab wrote:
> Em Thu, 28 Feb 2019 15:35:07 +0100
> Hans Verkuil escreveu:
>
>> On 2/28/19 3:09 PM, Mauro Carvalho Chehab wrote:
>>> Em Thu, 28 Feb 2019 13:30:49 +0100
>>> Hans Verkuil escreveu:
>>>
On 2/26/19 6:36 PM, Mauro Carvalho Chehab wrote:
>>
sd_desc->stop0 and sd_desc->stopN hooks are meant to access
the device hardware, stopping the transfer. Thus, hardware
presence should be checked before calling them.
This means that sd_desc.start is not allowed to allocate resources,
since sd_desc.stop0 and sd_desc.stopN won't be releasing when
t
In order to prevent ISOC URBs from being infinitely resubmitted,
the driver's USB disconnect handler must kill all the in-flight URBs.
While here, change the URB packet status message to a debug level,
to avoid spamming the console too much.
This commit fixes a lockup caused by an interrupt storm
Em Thu, 28 Feb 2019 15:35:07 +0100
Hans Verkuil escreveu:
> On 2/28/19 3:09 PM, Mauro Carvalho Chehab wrote:
> > Em Thu, 28 Feb 2019 13:30:49 +0100
> > Hans Verkuil escreveu:
> >
> >> On 2/26/19 6:36 PM, Mauro Carvalho Chehab wrote:
> >>> The vim2m driver doesn't enforce that the capture an
Hello!
On 02/28/2019 02:06 PM, Geert Uytterhoeven wrote:
> devm_ioremap_resource() already prints an error message on failure, so
> there is no need to repeat that.
>
> Signed-off-by: Geert Uytterhoeven
> ---
> drivers/media/platform/rcar_drif.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff
On 2/28/19 3:09 PM, Mauro Carvalho Chehab wrote:
> Em Thu, 28 Feb 2019 13:30:49 +0100
> Hans Verkuil escreveu:
>
>> On 2/26/19 6:36 PM, Mauro Carvalho Chehab wrote:
>>> The vim2m driver doesn't enforce that the capture and output
>>> buffers would have the same size. Do the right thing if the
>>>
Em Thu, 28 Feb 2019 13:30:49 +0100
Hans Verkuil escreveu:
> On 2/26/19 6:36 PM, Mauro Carvalho Chehab wrote:
> > The vim2m driver doesn't enforce that the capture and output
> > buffers would have the same size. Do the right thing if the
> > buffers are different, zeroing the buffer before writin
The following changes since commit 9fabe1d108ca4755a880de43f751f1c054f8894d:
media: ipu3-mmu: fix some kernel-doc macros (2019-02-19 09:00:42 -0500)
are available in the Git repository at:
git://linuxtv.org/hverkuil/media_tree.git tags/br-v5.1s
for you to fetch changes up to d3d18960c43d
The cobalt driver is the only driver that uses VB2_BUF_STATE_REQUEUEING.
Replace it by VB2_BUF_STATE_ERROR so we can drop support for the
REQUEUEING state.
The requeueing state was used in the cobalt driver to optimize
buffer handling while waiting for a valid signal: by requeueing
buffers interna
The last user of this state has been converted, so we can now drop
this. Requeueing causes the queue to become unordered, which causes
problems with requests and (in the future) fences.
Since it is no longer needed, just get rid of this.
Signed-off-by: Hans Verkuil
---
.../media/common/videobuf
The VB2_BUF_STATE_REQUEUEING leads to unordered behavior in vb2.
The only driver that used it was the cobalt driver, and replacing
VB2_BUF_STATE_REQUEUEING by VB2_BUF_STATE_ERROR is sufficient.
In addition, VB2_BUF_STATE_REQUEUEING can't be used with the Request
API, so removing support for this s
On 2/26/19 6:36 PM, Mauro Carvalho Chehab wrote:
> The vim2m driver doesn't enforce that the capture and output
> buffers would have the same size. Do the right thing if the
> buffers are different, zeroing the buffer before writing,
> ensuring that lines will be aligned and it won't write past
> t
devm_ioremap_resource() already prints an error message on failure, so
there is no need to repeat that.
Signed-off-by: Geert Uytterhoeven
---
drivers/media/platform/rcar_drif.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/media/platform/rcar_drif.c
b/drivers/media/platform/rcar_dr
On 2/26/19 4:33 AM, Alexandre Courbot wrote:
> Hi, sorry for the delayed reply!
>
> On Wed, Feb 13, 2019 at 8:04 PM Paul Kocialkowski
> wrote:
>>
>> Hi,
>>
>> On Wed, 2019-02-13 at 10:57 +0100, Hans Verkuil wrote:
>>> On 2/13/19 10:20 AM, Paul Kocialkowski wrote:
Hi,
On Wed, 2019-0
On Wed, Feb 27, 2019 at 04:36:06PM -0800, Hyun Kwon wrote:
> Hi Daniel,
>
> On Wed, 2019-02-27 at 06:13:45 -0800, Daniel Vetter wrote:
> > On Tue, Feb 26, 2019 at 11:20 PM Hyun Kwon wrote:
> > >
> > > Hi Daniel,
> > >
> > > Thanks for the comment.
> > >
> > > On Tue, 2019-02-26 at 04:06:13 -0800,
27 matches
Mail list logo
