Em Thu, 20 Aug 2015 02:33:15 +0300
Laurent Pinchart escreveu:
> Hi Mauro,
>
> On Tuesday 18 August 2015 07:06:36 Mauro Carvalho Chehab wrote:
> > Em Tue, 18 Aug 2015 09:35:14 +0300 Laurent Pinchart escreveu:
> > > On Friday 14 August 2015 12:54:44 Hans Verkuil wrote:
>
> [snip]
>
> > > I think
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: Thu Aug 20 04:00:18 CEST 2015
git branch: test
git hash: 3a6b0605c73d1d695f6d4e49289deaa3fa3e73ee
gcc versi
Hi Mauro,
On Tuesday 18 August 2015 07:06:36 Mauro Carvalho Chehab wrote:
> Em Tue, 18 Aug 2015 09:35:14 +0300 Laurent Pinchart escreveu:
> > On Friday 14 August 2015 12:54:44 Hans Verkuil wrote:
[snip]
> > I think this is becoming too complex. How about considering "deploy" as a
> > commit inst
Hi Michael,
On Thursday 20 August 2015 01:40:26 Laurent Pinchart wrote:
> Hi Michael,
>
> Thank you for the patch.
I forgot to mention that your patch got corrupted by your mailer (tabs
replaced by spaces for instance). Could you please fix that for the next
version ?
--
Regards,
Laurent Pi
Hi Michael,
Thank you for the patch.
On Monday 10 August 2015 17:16:30 Michael Allwright wrote:
> Hi All,
>
> The following PRELIMINARY patch adds DT support to the OMAP4 ISS. It
> also fixes some problems a have found along the way. It is tightly
> modelled after the omap3-isp media platform dr
Hi Michael,
On Tuesday 11 August 2015 19:13:08 Michael Allwright wrote:
> On 11 August 2015 at 13:16, Tony Lindgren wrote:
> > * Michael Allwright [150810 08:19]:
> >> +
> >> +/*
> >> +We need a better solution for this
> >> +*/
> >> +#include <../arch/arm/mach-omap2/omap-pm.h>
> >
> > Please l
Hi Tony,
On Tuesday 11 August 2015 04:16:04 Tony Lindgren wrote:
> * Michael Allwright [150810 08:19]:
> > +
> > +/*
> > +We need a better solution for this
> > +*/
> > +#include <../arch/arm/mach-omap2/omap-pm.h>
>
> Please let's not do things like this, I end up having to deal with
> all these
Hi Hans,
I like your proposal, and especially how it would integrate with the requests
API. Should we give the requests API a try to make sure your proposal works
fine with it ?
As a side note, I'll need to requests API for Renesas. The current schedule is
to have a first RFC implementation by
rcar_vin_set_fmt() defaults to PAL when the subdevice's querystd() method call
fails (e.g. due to I2C error). This doesn't work very well when a camera being
used outputs NTSC which has different order of fields and resolution. Let us
stop pretending and return the actual error (which would p
Good day,hoping you read this email and respond to me in good time.I do not
intend to solicit for funds but your time and energy in using my own resources
to assist the less privileged.I am medically confined at the moment hence I
request your indulgence.
I will give you a comprehensive brief o
Good day,hoping you read this email and respond to me in good time.I do not
intend to solicit for funds but your time and energy in using my own resources
to assist the less privileged.I am medically confined at the moment hence I
request your indulgence.
I will give you a comprehensive brief o
Signed-off-by: Ravinder Atla
---
drivers/staging/media/davinci_vpfe/dm365_resizer.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/media/davinci_vpfe/dm365_resizer.c
b/drivers/staging/media/davinci_vpfe/dm365_resizer.c
index 6218230..273aea3 100644
--
Now that the struct media_entity .parent field is unused, it can be
safely removed. Since all the previous users were converted to use
the .mdev field from the embedded struct media_gobj instead.
Suggested-by: Mauro Carvalho Chehab
Signed-off-by: Javier Martinez Canillas
---
include/media/med
The struct media_entity has a .parent field that stores a pointer
to the parent struct media_device. But recently a media_gobj was
embedded into the entities and since struct media_gojb already has
a pointer to a struct media_device in the .mdev field, the .parent
field becomes redundant and can be
Hello,
This series contains a couple of build fixes and cleanups for the
Media Controller framework. The goal of the series is to get rid of
the struct media_entity .parent member since now that a media_gobj is
embedded into entities, the media_gobj .mdev member can be used to
store a pointer to t
The struct media_entity does not have an .id field anymore since
now the entity ID is stored in the embedded struct media_gobj.
This caused the omap3isp driver fail to build. Fix by using the
media_entity_id() macro to obtain the entity ID.
Signed-off-by: Javier Martinez Canillas
---
drivers/m
The struct media_entity does not have an .id field anymore since
now the entity ID is stored in the embedded struct media_gobj.
This caused the omap4iss driver fail to build. Fix by using the
media_entity_id() macro to obtain the entity ID.
Signed-off-by: Javier Martinez Canillas
---
drivers/s
ping?
On Mon, Aug 10, 2015 at 2:04 PM, Ricardo Ribalda Delgado
wrote:
> Hello Hans, Sakari and Laurent:
>
> I am back from holidays :). Shall I prepare a new patchset with the
> suggestion from Hans?
>
> Thanks!
>
> On Mon, Jul 20, 2015 at 4:31 PM, Hans Verkuil wrote:
>> On 07/20/2015 03:52 PM,
On 08/19/15 13:01, Mauro Carvalho Chehab wrote:
> It helps to check if the media controller is doing the
> right thing with the object creation and removal.
>
> No extra code/data will be produced if DEBUG or
> CONFIG_DYNAMIC_DEBUG is not enabled.
>
> Signed-off-by: Mauro Carvalho Chehab
Acked-
On 08/19/15 13:01, Mauro Carvalho Chehab wrote:
> Due to the MC API proposed changes, we'll need to have an unique
> object ID for all graph objects, and have some shared fields
> that will be common on all media graph objects.
>
> Right now, the only common object is the object ID, but other
> fi
On 08/19/15 13:01, Mauro Carvalho Chehab wrote:
> We can only free the media device after being sure that no
> graph object is used.
>
> In order to help tracking it, let's add debug messages
> that will print when the media controller gets registered
> or unregistered.
>
> Signed-off-by: Mauro C
On 08/19/15 13:01, Mauro Carvalho Chehab wrote:
> Just like entities and pads, links also need to have unique
> Object IDs along a given media controller.
>
> So, let's add a media_gobj inside it and initialize
> the object then a new link is created.
>
> Signed-off-by: Mauro Carvalho Chehab
Hm
It helps to check if the media controller is doing the
right thing with the object creation and removal.
No extra code/data will be produced if DEBUG or
CONFIG_DYNAMIC_DEBUG is not enabled.
Signed-off-by: Mauro Carvalho Chehab
diff --git a/drivers/media/media-entity.c b/drivers/media/media-enti
As entities are graph elements, let's embed media_gobj
on it. That ensures an unique ID for entities that can be
global along the entire media controller.
For now, we'll keep the already existing entity ID. Such
field need to be dropped at some point, but for now, let's
not do this, to avoid needi
On 08/19/15 11:50, Mauro Carvalho Chehab wrote:
> Em Wed, 19 Aug 2015 10:36:51 +0200
> Hans Verkuil escreveu:
>
>> On 08/18/2015 10:04 PM, Mauro Carvalho Chehab wrote:
>>> It helps to check if the media controller is doing the
>>> right thing with the object creation and removal.
>>>
>>> No extra
PADs also need unique object IDs that won't conflict with
the entity object IDs.
The pad objects are currently created via media_entity_init()
and, once created, never change.
While this will likely change in the future in order to
support dynamic changes, for now we'll keep PADs as arrays
and in
Instead of accessing directly entity.id, let's create a macro,
as this field will be moved into a common struct later on.
Signed-off-by: Mauro Carvalho Chehab
Acked-by: Hans Verkuil
Signed-off-by: Mauro Carvalho Chehab
diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c
in
Now that a link can be either between two different graph
objects, we'll need to add more functions to create links.
So, rename the existing one that create links only between
two pads as media_create_pad_link().
No functional changes.
This patch was created via this shell script:
for i i
Due to the MC API proposed changes, we'll need to have an unique
object ID for all graph objects, and have some shared fields
that will be common on all media graph objects.
Right now, the only common object is the object ID, but other
fields will be added later on.
Signed-off-by: Mauro Carvalho
Just like entities and pads, links also need to have unique
Object IDs along a given media controller.
So, let's add a media_gobj inside it and initialize
the object then a new link is created.
Signed-off-by: Mauro Carvalho Chehab
diff --git a/drivers/media/media-device.c b/drivers/media/media-
Those are the same patches as sent at PATCH RFCv5, addressing most of
the stuff pointed by Hans.
The only thing I didn't do yet is the removal of entity->parent, in
favor of using, instead, entity->graph_obj.mdev. Such patch will
be done latter on.
As the previous series:
The first 5 patches on
We can only free the media device after being sure that no
graph object is used.
In order to help tracking it, let's add debug messages
that will print when the media controller gets registered
or unregistered.
Signed-off-by: Mauro Carvalho Chehab
diff --git a/drivers/media/media-device.c b/dri
Em Wed, 19 Aug 2015 10:36:51 +0200
Hans Verkuil escreveu:
> On 08/18/2015 10:04 PM, Mauro Carvalho Chehab wrote:
> > It helps to check if the media controller is doing the
> > right thing with the object creation and removal.
> >
> > No extra code/data will be produced if DEBUG or
> > CONFIG_DYN
Em Wed, 19 Aug 2015 10:17:46 +0200
Hans Verkuil escreveu:
> On 08/18/2015 10:04 PM, Mauro Carvalho Chehab wrote:
> > Due to the MC API proposed changes, we'll need to have an unique
> > object ID for all graph objects, and have some shared fields
> > that will be common on all media graph objects
On 08/18/2015 10:04 PM, Mauro Carvalho Chehab wrote:
> Now that a link can be either between two different graph
> objects, we'll need to add more functions to create links.
> So, rename the existing one that create links only between
> two pads as media_create_pad_link().
>
> No functional change
On 08/18/2015 10:04 PM, Mauro Carvalho Chehab wrote:
> It helps to check if the media controller is doing the
> right thing with the object creation and removal.
>
> No extra code/data will be produced if DEBUG or
> CONFIG_DYNAMIC_DEBUG is not enabled.
>
> Signed-off-by: Mauro Carvalho Chehab
>
Hi Everyone,
I'm thinking of using systemtap to create watchpoints on all memory
regions of the ISS and associated PRCM registers to generate two log
files with all memory accesses at any given point of time, one for
3.17 and one for 4.1.4.
Does this sound like reasonable approach, or is this ove
Am Dienstag, den 18.08.2015, 10:31 +0200 schrieb Uwe Kleine-König:
> Commit 256148246852 ("[media] tc358743: support probe from device tree")
> specified in the device tree binding documentation that the reset gpio
> is optional. Make the implementation match accordingly.
>
> Signed-off-by: Uwe Kl
Am Dienstag, den 18.08.2015, 10:31 +0200 schrieb Uwe Kleine-König:
> Commit 256148246852 ("[media] tc358743: support probe from device tree")
> failed to explicitly set the direction of the reset gpio. Use the
> optional flag of devm_gpiod_get to make up leeway.
>
> This is also necessary because
On 08/18/2015 10:04 PM, Mauro Carvalho Chehab wrote:
> Just like entities and pads, links also need to have unique
> Object IDs along a given media controller.
>
> So, let's add a media_gobj inside it and initialize
> the object then a new link is created.
>
> Signed-off-by: Mauro Carvalho Chehab
On 08/18/2015 10:04 PM, Mauro Carvalho Chehab wrote:
> Due to the MC API proposed changes, we'll need to have an unique
> object ID for all graph objects, and have some shared fields
> that will be common on all media graph objects.
>
> Right now, the only common object is the object ID, but other
Hello Kozlov Sergey,
The patch 52b1eaf4c59a: "[media] netup_unidvb: NetUP Universal
DVB-S/S2/T/T2/C PCI-E card driver" from Jul 28, 2015, leads to the
following static checker warning:
drivers/media/pci/netup_unidvb/netup_unidvb_spi.c:84
netup_spi_interrupt()
error: we previously
42 matches
Mail list logo