Hi Oliver,
I love your patch! Yet something to improve:
[auto build test ERROR on linuxtv-media/master]
[also build test ERROR on v5.1-rc7 next-20190502]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux
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 May 3 05:00:10 CEST 2019
media-tree git hash:7afa8db323e37b9174cf78a1c9ab0ae7a9f5e7dd
media_build gi
On Thu, Mar 14, 2019 at 10:18:33PM +0800, Louis Kuo wrote:
> This patch adds Mediatek's sensor interface driver. Sensor interface driver
> is a MIPI-CSI2 host driver, namely, a HW camera interface controller.
> It support a widely adopted, simple, high-speed protocol primarily intended
> for point-
While working on a SoC with CODA980 (currently not supported by the
driver), I came across some low-hanging fruit that looked worth
addressing.
Patch 1 is just a cosmetic change to print a different "more standard"
device registered message, if such thing exists.
Patches 2 and 3 address unneeded
This is just a cosmetic change to print a more descriptive
message, to distinguish decoder from encoder:
So, instead of printing
coda 204.vpu: codec registered as /dev/video[4-5]
With this change, the driver now prints
coda 204.vpu: encoder registered as /dev/video4
coda 204.v
The mutex unlock in the threaded interrupt handler is not paired
with any mutex lock. Remove it.
This bug has been here for a really long time, so it applies
to any stable repo.
Reviewed-by: Philipp Zabel
Signed-off-by: Ezequiel Garcia
---
drivers/media/platform/coda/coda-bit.c | 1 -
1 file c
HI Sakari,
On Fri, May 03, 2019 at 12:32:02AM +0300, Sakari Ailus wrote:
> Hi Jacopo,
>
> On Sat, Apr 27, 2019 at 01:00:42AM +0200, Jacopo Mondi wrote:
> > HI Sakari,
> >
> > On Tue, Apr 23, 2019 at 04:28:40PM +0300, Sakari Ailus wrote:
> > > Hi Jacopo,
> > >
> > > On Tue, Apr 23, 2019 at 12:19:32
This commit clears the interrupt reason (INT_REASON) register
on the interrupt handler. Without this clearing, the CODA hardware
has been observed to get completely stalled on CODA980 variants,
requiring a pretty deep hardware reset.
The datasheet specifies that the INT_REASON register is set
by t
The current interrupt handler is doing very little, and not doing
any non-atomic operations. Pretty much all it does is accessing
a couple registers, taking a couple spinlocks and then signalling
a completion.
There is no reason this should be a threaded interrupt handler,
so move the handler to r
Hi Jacopo,
On Sat, Apr 27, 2019 at 01:00:42AM +0200, Jacopo Mondi wrote:
> HI Sakari,
>
> On Tue, Apr 23, 2019 at 04:28:40PM +0300, Sakari Ailus wrote:
> > Hi Jacopo,
> >
> > On Tue, Apr 23, 2019 at 12:19:32PM +0200, Jacopo Mondi wrote:
> > > Hi Sakari,
> > >
> > > On Wed, Apr 17, 2019 at 01:41:4
On 5/2/19 2:13 PM, Jae Hyun Yoo wrote:
There are cases that interrupt bits are cleared by a 500ms delayed
work which causes unnecessary irq calls. Also, the current
interrupt handler returns IRQ_HANDLED always but it should return
IRQ_NONE if there is any unhandled interrupt. So this commit
ref
Differently fron other Aspeed drivers, this driver calls clock
control APIs in interrupt context. Since ECLK is coupled with a
reset bit in clk-aspeed module, aspeed_clk_enable will make 10ms of
busy waiting delay for triggering the reset and it will eventually
disturb other drivers' interrupt hand
VE_INTERRUPT_CAPTURE_COMPLETE and VE_INTERRUPT_COMP_COMPLETE are
not set at the same time but the current interrupt handling
mechanism of this driver doesn't clear the interrupt flag until
both two are set, and this behavior causes unnecessary interrupt
handler calls. In fact, this driver provides
Currently, this driver prints out too much log messages when a
mode change happens, video turned off by screen saver and etc.
Actually, all cases are reported to user space properly. Also,
these are not critical errors but recoverable things, so this
commit changes the log level of some noisy print
There are cases that interrupt bits are cleared by a 500ms delayed
work which causes unnecessary irq calls. Also, the current
interrupt handler returns IRQ_HANDLED always but it should return
IRQ_NONE if there is any unhandled interrupt. So this commit
refines the interrupt handling logic to fix th
Video Engine has a dedicated interrupt line so this driver doesn't
need to use IRQF_SHARED flag so remove it. Also, it'd be good for
following what Thomas recommended in the IRQF_ONESHOT support
patch like below:
"Note that for now IRQF_ONESHOT cannot be used with IRQF_SHARED to
avoid complex acco
This patch series improves stability of Aspeed video engine driver by fixing
clock control and irq handling logic in the driver.
This series should be applied on top of:
https://www.spinics.net/lists/linux-media/msg150193.html
Jae Hyun Yoo (7):
media: aspeed: fix a kernel warning on clk control
Currently, this driver calls clk_prepare and clk_unprepare from
interrupt context too but these should be called from sleepable
context only. To fix this issue, this commit splits out
clk_enable/disable and clk_prepare/unprepare, and it places
clk_prepare/unprepare calls into the module probe/remov
Video engine clock control functions in the Aspeed video engine
driver are being called from multiple context without any
protection so video clocks can be double disabled and eventually
it causes a kernel warning with stack dump printing out like below:
[ 515.540498] [ cut here ]
It is really weird that the media controller sources are all top-level
in drivers/media. It is a bit of a left-over from long ago when most
media sources were all at the top-level. At some point we reorganized
the directory structure, but the media-*.c sources where never moved
to their own directo
It is really weird that the media controller sources are all top-level
in drivers/media. It is a bit of a left-over from long ago when most
media sources were all at the top-level. At some point we reorganized
the directory structure, but the media-*.c sources where never moved
to their own directo
On 5/2/19 3:39 PM, Mauro Carvalho Chehab wrote:
> Em Thu, 2 May 2019 15:35:17 +0200
> Hans Verkuil escreveu:
>
>> It is really weird that the media controller sources are all top-level
>> in drivers/media. It is a bit of a left-over from long ago when most
>> media sources were all at the top-lev
Em Thu, 2 May 2019 15:35:17 +0200
Hans Verkuil escreveu:
> It is really weird that the media controller sources are all top-level
> in drivers/media. It is a bit of a left-over from long ago when most
> media sources were all at the top-level. At some point we reorganized
> the directory structur
Hello Hans,
Would be great if you could at least get this into 5.2 :
media: atmel: atmel-isc: make try_fmt error less verbose
I noticed several sensor drivers act in a way that makes this message
appear a lot, when the sensors actually work fine. They just return
errors in try_fmt if the forma
This previous PR https://patchwork.linuxtv.org/patch/55818/ is now split
in two, one with patches for 5.2 and one with stuff that can go into 5.3.
This PR contains the patches with new features for 5.3.
Regards,
Hans
The following changes since commit 7afa8db323e37b9174cf78a1c9ab0ae7a9f
This previous PR https://patchwork.linuxtv.org/patch/55818/ is now split
in two, one with patches for 5.2 and one with stuff that can go into 5.3.
This PR contains the fixes for 5.2.
Regards,
Hans
The other patches of that previous PR will be added to a PR for
The following changes sin
Hi Oliver,
Thank you for the patch.
On Tue, Apr 30, 2019 at 02:28:14PM +0200, Oliver Neukum wrote:
> We need to check whether this work we are canceling actually is
> initialized.
I think we should add
Fixes: e5225c820c05 ("media: uvcvideo: Send a control event when a Control
Change interrupt
Hello,
I am beginner in C and interested in getting into learning C and about
cameras. Can I help in any capacity to improve V4L2 and gain a lot of knowledge?
Thanks,
Horrible
28 matches
Mail list logo
