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 Jan 20 05:00:21 CET 2017
media-tree git hash:40eca140c404505c09773d1c6685d818cb55ab1a
media_build git
good morning linux
http:// circostruzioni.it/adimage.php?rule=y23df1x1razv8tn
Patrick Cairns
--
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
Commit a006c04e6218 ("[media] exynos-gsc: Fixup clock management at
->remove()") changed the driver's .remove function logic to fist do
a pm_runtime_get_sync() to make sure the device is powered before
attempting to gate the gsc clock.
But the commit also removed a pm_runtime_disable() call that l
Commit 15f90ab57acc ("[media] exynos-gsc: Make driver functional when
CONFIG_PM is unset") removed the implicit dependency that the driver
had with CONFIG_PM, since it relied on the config option to be enabled.
In order to work with !CONFIG_PM, the GSC reset logic that happens in
the runtime resum
Hi Pavel,
On Wed, Jan 11, 2017 at 11:53:35PM +0100, Pavel Machek wrote:
> From: Sakari Ailus
>
> In the vast majority of cases the bus type is known to the driver(s)
> since a receiver or transmitter can only support a single one. There
> are cases however where different options are possible.
>
Hi Baruch,
On Thu, Jan 12, 2017 at 02:06:03PM +0200, Baruch Siach wrote:
> Hi Pavel,
>
> On Wed, Jan 11, 2017 at 11:53:35PM +0100, Pavel Machek wrote:
> > From: Sakari Ailus
> >
> > In the vast majority of cases the bus type is known to the driver(s)
> > since a receiver or transmitter can only
Hi Gregor,
On Mon, Jan 16, 2017 at 09:00:40PM +0100, Gregor Jasny wrote:
> On 16/01/2017 11:06, Sean Young wrote:
> > On Mon, Jan 16, 2017 at 09:10:36AM +0100, Gregor Jasny wrote:
> >> Hello,
> >>
> >> I'd like to do a new v4l-utils release before the Debian freeze. Is master
> >> in a releasable
Hello Marek,
On 01/19/2017 11:56 AM, Javier Martinez Canillas wrote:
> On 01/19/2017 11:17 AM, Marek Szyprowski wrote:
[snip]
>
> Also when removing the exynos_gsc driver, I get the same error:
>
> # rmmod s5p_mfc
> [ 106.405972] s5p-mfc 1100.codec: Removing 1100.codec
> # rmmod exyno
Hello Hans,
Do you have any further feedback on this?
Thanks, Chris
> From: Ramesh Shanmugasundaram
> Sent: 10 January 2017 09:31
> Hi Laurent,
>
> > > >>> On Wednesday 21 Dec 2016 08:10:37 Ramesh Shanmugasundaram
> wrote:
> > > Add binding documentation for Renesas R-Car Digital Radio
>
Hi Michael,
[auto build test ERROR on pci/next]
[also build test ERROR on v4.10-rc4]
[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/commits/Michael-S-Tsirkin/pci-drop-link_reset/20170119-34
base
Hello Marek,
Thanks a lot for your feedback.
On 01/19/2017 11:17 AM, Marek Szyprowski wrote:
> Hi Javier,
>
> On 2017-01-18 01:30, Javier Martinez Canillas wrote:
>> Commit 15f90ab57acc ("[media] exynos-gsc: Make driver functional when
>> CONFIG_PM is unset") removed the implicit dependency that
Hello Marek,
On 01/19/2017 11:12 AM, Marek Szyprowski wrote:
> Hi Javier,
>
> On 2017-01-18 01:30, Javier Martinez Canillas wrote:
>> Commit a006c04e6218 ("[media] exynos-gsc: Fixup clock management at
>> ->remove()") changed the driver's .remove function logic to fist do
>> a pm_runtime_get_sync
Hi Javier,
On 2017-01-18 01:30, Javier Martinez Canillas wrote:
Commit 15f90ab57acc ("[media] exynos-gsc: Make driver functional when
CONFIG_PM is unset") removed the implicit dependency that the driver
had with CONFIG_PM, since it relied on the config option to be enabled.
In order to work wit
Hi Javier,
On 2017-01-18 01:30, Javier Martinez Canillas wrote:
Commit a006c04e6218 ("[media] exynos-gsc: Fixup clock management at
->remove()") changed the driver's .remove function logic to fist do
a pm_runtime_get_sync() to make sure the device is powered before
attempting to gate the gsc clo
Hi Philipp,
(Adding firmware loader maintainers to Cc).
On Thu, Jan 19, 2017 at 10:44:54AM +0100, Philipp Zabel wrote:
> On Wed, 2017-01-18 at 21:33 +0200, Baruch Siach wrote:
> > > - if (dev->firmware == 1) {
> > > + if (dev->firmware > 0) {
> >
> > Why would vpu/vpu_fw_*.bin and v4l-coda960-*.
Hi Laurent,
Thank you for the detailed review.
On 12/05/2016 05:22 PM, Laurent Pinchart wrote:
> Hi Todor,
>
> Thank you for the patch.
>
> On Friday 25 Nov 2016 16:57:20 Todor Tomov wrote:
>> These files handle the video device nodes of the camss driver.
>
> camss is a quite generic, I'm a bi
Hi Baruch,
On Wed, 2017-01-18 at 21:33 +0200, Baruch Siach wrote:
[...]
> > To increase the number of firmware paths, coda_fw_callback has to be
> > modified, too. Otherwise it will just ignore firmware[2]:
>
> Thanks for catching that. But shouldn't we make the firmware files list a
> NULL
> t
17 matches
Mail list logo
