From: James Bottomley
Date: Thu, 13 Aug 2015 20:59:20 -0700
> On Thu, 2015-08-13 at 20:30 -0700, Dan Williams wrote:
>> On Thu, Aug 13, 2015 at 7:31 AM, Christoph Hellwig wrote:
>> > On Wed, Aug 12, 2015 at 09:01:02AM -0700, Linus Torvalds wrote:
>> >> I'm assuming that anybody who wants to use
On Thu, 2015-08-13 at 20:30 -0700, Dan Williams wrote:
> On Thu, Aug 13, 2015 at 7:31 AM, Christoph Hellwig wrote:
> > On Wed, Aug 12, 2015 at 09:01:02AM -0700, Linus Torvalds wrote:
> >> I'm assuming that anybody who wants to use the page-less
> >> scatter-gather lists always does so on memory th
On Thu, Aug 13, 2015 at 7:31 AM, Christoph Hellwig wrote:
> On Wed, Aug 12, 2015 at 09:01:02AM -0700, Linus Torvalds wrote:
>> I'm assuming that anybody who wants to use the page-less
>> scatter-gather lists always does so on memory that isn't actually
>> virtually mapped at all, or only does so o
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 Aug 14 04:00:19 CEST 2015
git branch: test
git hash: 2696f495bdc046d84da6c909a1e7f535138a2a62
gcc versi
Hi Helen,
Thank you for the patch.
I would have moved this patch before 5/7 and 6/7 as it would ease review by
making 7/7 smaller and by making the debayer and scaler implementation fully
contained in 5/7 and 6/7.
On Thursday 06 August 2015 17:26:14 Helen Fornazier wrote:
> Implement set forma
Hi Helen,
Thank you for the patch.
On Thursday 06 August 2015 17:26:13 Helen Fornazier wrote:
> Implement scaler and integrated with the core
>
> Signed-off-by: Helen Fornazier
> ---
> drivers/media/platform/vimc/Makefile | 3 +-
> drivers/media/platform/vimc/vimc-core.c | 6 +-
> d
Hi Helen,
Thank you for the patch.
On Thursday 06 August 2015 17:26:12 Helen Fornazier wrote:
> Implement the debayer filter and integrate it with the core
>
> Signed-off-by: Helen Fornazier
> ---
> drivers/media/platform/vimc/Makefile | 2 +-
> drivers/media/platform/vimc/vimc-core.c
Hi Christoph,
On Fri, Aug 14, 2015 at 12:35 AM, Christoph Hellwig wrote:
> On Thu, Aug 13, 2015 at 09:37:37AM +1000, Julian Calaby wrote:
>> I.e. ~90% of this patch set seems to be just mechanically dropping
>> BUG_ON()s and converting open coded stuff to use accessor functions
>> (which should b
Hi Helen,
Thank you for the patch.
On Thursday 06 August 2015 17:26:11 Helen Fornazier wrote:
> Move the vimc_cap_pipeline_s_stream from the vimc-cap.c to vimc-core.c
> as this core will be reused by other subdevices to activate the stream
> in their directly connected nodes
>
> Signed-off-by: H
Hi Helen,
Thank you for the patch.
On Thursday 06 August 2015 17:26:10 Helen Fornazier wrote:
> As all the subdevices in the topology will be initialized in the same
> way, to avoid code repetition the vimc_ent_sd_init/cleanup helper functions
> were created
>
> Signed-off-by: Helen Fornazier
>
Oops, my mistake.
Thanks for the patch, I've applied it.
Regards,
Hans
On 08/13/2015 09:47 PM, Robert 'Bobby' Zenz wrote:
> Signed-off-by: Robert Zenz
> ---
> backports/v4.1_pat_enabled.patch | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/backports/v4.1_p
Hi Helen,
Thank you for the patch.
On Thursday 06 August 2015 17:26:09 Helen Fornazier wrote:
> Initialize the test pattern generator on the sensor
> Generate a colored bar image instead of a grey one
>
> Signed-off-by: Helen Fornazier
> ---
> drivers/media/platform/vimc/Kconfig | 1 +
>
Signed-off-by: Robert Zenz
---
backports/v4.1_pat_enabled.patch | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/backports/v4.1_pat_enabled.patch b/backports/v4.1_pat_enabled.patch
index b266d9d..66a8671 100644
--- a/backports/v4.1_pat_enabled.patch
+++ b/backports/v4.1_pat_e
Hi Helen,
Thank you for the patch. I just have a couple of small comments.
On Thursday 06 August 2015 17:26:08 Helen Fornazier wrote:
> The test pattern generator will be used by other drivers as the virtual
> media controller (vimc)
>
> Signed-off-by: Helen Fornazier
> ---
> drivers/media/pla
When using multiple capture cards, it migth be necessary to identify a specific
device with an ALSA one. If not, the order of the ALSA devices might have no
relation to the id of the radio or video device.
Signed-off-by: Nicolas Sugino
---
drivers/media/pci/ivtv/ivtv-alsa-main.c | 10 +
Hello,
On Tuesday 11 August 2015 17:07:04 Helen Fornazier wrote:
> On Tue, Aug 11, 2015 at 6:36 AM, Mauro Carvalho Chehab wrote:
> > Hans Verkuil escreveu:
> >> On 08/10/15 19:21, Helen Fornazier wrote:
> >>> On Mon, Aug 10, 2015 at 10:11 AM, Hans Verkuil wrote:
> On 08/08/2015 03:55 AM, Hel
Hello,
On Tuesday 11 August 2015 12:34:46 Hans Verkuil wrote:
> On 08/11/15 11:36, Mauro Carvalho Chehab wrote:
> > Em Tue, 11 Aug 2015 11:28:25 +0200 Hans Verkuil escreveu:
> >> On 08/10/15 19:21, Helen Fornazier wrote:
> >>> On Mon, Aug 10, 2015 at 10:11 AM, Hans Verkuil wrote:
> On 08/08/2
On 08/13/2015 05:40 PM, Christoph Hellwig wrote:
> On Wed, Aug 12, 2015 at 03:42:47PM +0300, Boaz Harrosh wrote:
>> The support I have suggested and submitted for zone-less sections.
>> (In my add_persistent_memory() patchset)
>>
>> Would work perfectly well and transparent for all such multimedia
On 08/13/2015 03:49 PM, Marek Szyprowski wrote:
> Hello,
>
> On 2015-08-13 14:40, Lars-Peter Clausen wrote:
>> On 08/12/2015 11:58 AM, Marek Szyprowski wrote:
>>> If device has no DMA max_seg_size set, we assume that there is no limit
>>> and it is safe to force it to use DMA_BIT_MASK(32) as max_s
On Wed, Aug 12, 2015 at 03:42:47PM +0300, Boaz Harrosh wrote:
> The support I have suggested and submitted for zone-less sections.
> (In my add_persistent_memory() patchset)
>
> Would work perfectly well and transparent for all such multimedia cases.
> (All hacks removed). In fact I have loaded pme
On Thu, Aug 13, 2015 at 09:37:37AM +1000, Julian Calaby wrote:
> I.e. ~90% of this patch set seems to be just mechanically dropping
> BUG_ON()s and converting open coded stuff to use accessor functions
> (which should be macros or get inlined, right?) - and the remaining
> bit is not flushing if we
On Wed, Aug 12, 2015 at 09:05:15AM -0700, Linus Torvalds wrote:
> [ Again, I'm responding to one random patch - this pattern was in
> other patches too. ]
>
> A question: do we actually expect to mix page-less and pageful SG
> entries in the same SG list?
>
> How does that happen?
Both for DAX
On Wed, Aug 12, 2015 at 09:01:02AM -0700, Linus Torvalds wrote:
> I'm assuming that anybody who wants to use the page-less
> scatter-gather lists always does so on memory that isn't actually
> virtually mapped at all, or only does so on sane architectures that
> are cache coherent at a physical lev
On Thu, Aug 13, 2015 at 7:49 AM, Marek Szyprowski
wrote:
> Hello,
>
>
> On 2015-08-13 14:40, Lars-Peter Clausen wrote:
>>
>> On 08/12/2015 11:58 AM, Marek Szyprowski wrote:
>>>
>>> If device has no DMA max_seg_size set, we assume that there is no limit
>>> and it is safe to force it to use DMA_BIT
Hi Sakari,
On Thursday 13 August 2015 15:23:26 Sakari Ailus wrote:
> On Mon, Aug 10, 2015 at 04:07:30PM +0200, Hans Verkuil wrote:
> > On 07/14/2015 04:32 PM, Laurent Pinchart wrote:
> >> On Tuesday 14 July 2015 16:19:50 Hans Verkuil wrote:
> >>> On 07/13/15 10:03, Sakari Ailus wrote:
> Helen
Hello,
On 2015-08-13 14:40, Lars-Peter Clausen wrote:
On 08/12/2015 11:58 AM, Marek Szyprowski wrote:
If device has no DMA max_seg_size set, we assume that there is no limit
and it is safe to force it to use DMA_BIT_MASK(32) as max_seg_size to
let DMA-mapping API always create contiguous mappin
On 08/12/2015 11:58 AM, Marek Szyprowski wrote:
> If device has no DMA max_seg_size set, we assume that there is no limit
> and it is safe to force it to use DMA_BIT_MASK(32) as max_seg_size to
> let DMA-mapping API always create contiguous mappings in DMA address
> space. This is essential for all
Hi Hans,
On Mon, Aug 10, 2015 at 04:07:30PM +0200, Hans Verkuil wrote:
> On 07/14/2015 04:32 PM, Laurent Pinchart wrote:
> > Hi Hans,
> >
> > On Tuesday 14 July 2015 16:19:50 Hans Verkuil wrote:
> >> On 07/13/15 10:03, Sakari Ailus wrote:
> >>> Helen Fornazier wrote:
> On Tue, Jun 30, 2015 a
Add logic such that the "default-input" property becomes unnecessary
for chips that only have one suitable input (ADV7611 by design, and
ADV7612 due to commit 7111cddd "[media] media: adv7604: reduce support
to first (digital) input").
Additionally, Ian's documentation in commit bf9c8227 ("[media]
Add DT entries for vin0, vin0_pins, and adv7612.
Signed-off-by: William Towle
Signed-off-by: Rob Taylor
---
arch/arm/boot/dts/r8a7790-lager.dts | 37 ++-
1 file changed, 36 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/r8a7790-lager.dts
b/arch/a
From: Ian Molton
Set the 'default-input' property for ADV7612, enabling image and video
capture without the need to have userspace specifying routing.
(This version places the property in the adv7612 node, in line with
Ian's documentation)
Signed-off-by: Ian Molton
Signed-off-by: William Towle
Version 2 ... removes some redundant configuration from device nodes,
and provides some supplementary logic for automatic initialisation of
state->pdata.default_input based on the hardware present.
(Obsoletes corresponding parts of "HDMI and Composite capture on
Lager...", published previously
On 08/12/15 22:14, Mauro Carvalho Chehab wrote:
> Change the internal namespace for links between two pads to
> have the "pad" there.
>
> We're also numbering it, as a common constructor is to do
> things like:
>
> if (link->port1.type != MEDIA_GRAPH_PAD)
> continue;
> i
No message body: min...@vill.hakuba.lg.jp
Original message follows.
--
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
34 matches
Mail list logo
