Re: Re: Re: A reliable kernel panic (3.6.2) and system crash when visiting a particular website
On Sat, 20 Oct 2012, Artem S. Tashkinov wrote: > You don't get me - I have *no* VirtualBox (or any proprietary) modules running > - but I can reproduce this problem using *the same system running under* > VirtualBox > in Windows 7 64. > > It's almost definitely either a USB driver bug or video4linux driver bug: Does the same thing happen with earlier kernel versions? What about if you unload snd-usb-audio or ehci-hcd? Alan Stern -- 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
Re: Re: Re: Re: A reliable kernel panic (3.6.2) and system crash when visiting a particular website
> On Oct 21, 2012, Borislav Petkov wrote: > > On Sat, Oct 20, 2012 at 11:15:17PM +, Artem S. Tashkinov wrote: > > You don't get me - I have *no* VirtualBox (or any proprietary) modules > > running > > Ok, good. We got that out of the way - I wanted to make sure after you > replied with two other possibilities of the system freezing. > > > - but I can reproduce this problem using *the same system running > > under* VirtualBox in Windows 7 64. > > That's windoze as host and linux as a guest, correct? Exactly. > If so, that's virtualbox's problem, I'd say. I can reproduce it on my host *alone* as I said in the very first message - never before I tried to run my Linux in a virtual machine. Please, just forget about VirtualBox - it has nothing to do with this problem. > > It's almost definitely either a USB driver bug or video4linux driver > > bug: > > And you're assuming that because the freeze happens when using your usb > webcam, correct? And not otherwise? Yes, like I said earlier - only when I try to access its settings using Adobe Flash the system crashes/freezes. > Maybe you can describe in more detail what exactly you're doing so that > people could try to reproduce your issue. I don't think many people have the same webcam so it's going to be a problem. It can be reproduced easily - just open Flash "Settings" in Google Chrome 22. The crash will occur immediately. > > I'm CC'ing linux-media and linux-usb mailing lists, the problem is > > described here: > > https://lkml.org/lkml/2012/10/20/35 > > https://lkml.org/lkml/2012/10/20/148 > > Yes, good idea. Maybe the folks there have some more ideas how to debug > this. > > I'm leaving in the rest for reference. > > What should be pointed out, though, is that you don't have any more > random corruptions causing oopses now that virtualbox is gone. The > freeze below is a whole another issue. The freeze happens on my *host* Linux PC. For an experiment I decided to check if I could reproduce the freeze under a virtual machine - it turns out the Linux kernel running under it also freezes. Artem -- 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
Re: Re: Re: A reliable kernel panic (3.6.2) and system crash when visiting a particular website
On Sat, Oct 20, 2012 at 11:15:17PM +, Artem S. Tashkinov wrote: > You don't get me - I have *no* VirtualBox (or any proprietary) modules > running Ok, good. We got that out of the way - I wanted to make sure after you replied with two other possibilities of the system freezing. > - but I can reproduce this problem using *the same system running > under* VirtualBox in Windows 7 64. That's windoze as host and linux as a guest, correct? If so, that's virtualbox's problem, I'd say. > It's almost definitely either a USB driver bug or video4linux driver > bug: And you're assuming that because the freeze happens when using your usb webcam, correct? And not otherwise? Maybe you can describe in more detail what exactly you're doing so that people could try to reproduce your issue. > I'm CC'ing linux-media and linux-usb mailing lists, the problem is described > here: > https://lkml.org/lkml/2012/10/20/35 > https://lkml.org/lkml/2012/10/20/148 Yes, good idea. Maybe the folks there have some more ideas how to debug this. I'm leaving in the rest for reference. What should be pointed out, though, is that you don't have any more random corruptions causing oopses now that virtualbox is gone. The freeze below is a whole another issue. Thanks. > Here are the last lines from my dmesg (with usbmon loaded): > > [ 292.164833] hub 1-0:1.0: state 7 ports 8 chg evt 0002 > [ 292.168091] ehci_hcd :00:1f.5: GetStatus port:1 status 00100a 0 ACK > POWER sig=se0 PEC CSC > [ 292.172063] hub 1-0:1.0: port 1, status 0100, change 0003, 12 Mb/s > [ 292.174883] usb 1-1: USB disconnect, device number 2 > [ 292.178045] usb 1-1: unregistering device > [ 292.183539] usb 1-1: unregistering interface 1-1:1.0 > [ 292.197034] usb 1-1: unregistering interface 1-1:1.1 > [ 292.204317] usb 1-1: unregistering interface 1-1:1.2 > [ 292.234519] usb 1-1: unregistering interface 1-1:1.3 > [ 292.236175] usb 1-1: usb_disable_device nuking all URBs > [ 292.364429] hub 1-0:1.0: debounce: port 1: total 100ms stable 100ms status > 0x100 > [ 294.364279] hub 1-0:1.0: hub_suspend > [ 294.366045] usb usb1: bus auto-suspend, wakeup 1 > [ 294.367375] ehci_hcd :00:1f.5: suspend root hub > [ 296.501084] usb usb1: usb wakeup-resume > [ 296.508311] usb usb1: usb auto-resume > [ 296.509833] ehci_hcd :00:1f.5: resume root hub > [ 296.560149] hub 1-0:1.0: hub_resume > [ 296.562240] ehci_hcd :00:1f.5: GetStatus port:1 status 001003 0 ACK > POWER sig=se0 CSC CONNECT > [ 296.566141] hub 1-0:1.0: port 1: status 0501 change 0001 > [ 296.670413] hub 1-0:1.0: state 7 ports 8 chg 0002 evt > [ 296.673222] hub 1-0:1.0: port 1, status 0501, change , 480 Mb/s > [ 297.311720] usb 1-1: new high-speed USB device number 3 using ehci_hcd > [ 300.547237] usb 1-1: skipped 1 descriptor after configuration > [ 300.549443] usb 1-1: skipped 4 descriptors after interface > [ 300.552273] usb 1-1: skipped 2 descriptors after interface > [ 300.556499] usb 1-1: skipped 1 descriptor after endpoint > [ 300.559392] usb 1-1: skipped 2 descriptors after interface > [ 300.560960] usb 1-1: skipped 1 descriptor after endpoint > [ 300.562169] usb 1-1: skipped 2 descriptors after interface > [ 300.563440] usb 1-1: skipped 1 descriptor after endpoint > [ 300.564639] usb 1-1: skipped 2 descriptors after interface > [ 300.565828] usb 1-1: skipped 2 descriptors after endpoint > [ 300.567084] usb 1-1: skipped 9 descriptors after interface > [ 300.569205] usb 1-1: skipped 1 descriptor after endpoint > [ 300.570484] usb 1-1: skipped 53 descriptors after interface > [ 300.595843] usb 1-1: default language 0x0409 > [ 300.602503] usb 1-1: USB interface quirks for this device: 2 > [ 300.605700] usb 1-1: udev 3, busnum 1, minor = 2 > [ 300.606959] usb 1-1: New USB device found, idVendor=046d, idProduct=081d > [ 300.610298] usb 1-1: New USB device strings: Mfr=0, Product=0, > SerialNumber=1 > [ 300.613742] usb 1-1: SerialNumber: 48C5D2B0 > [ 300.617703] usb 1-1: usb_probe_device > [ 300.620594] usb 1-1: configuration #1 chosen from 1 choice > [ 300.639218] usb 1-1: adding 1-1:1.0 (config #1, interface 0) > [ 300.640736] snd-usb-audio 1-1:1.0: usb_probe_interface > [ 300.642307] snd-usb-audio 1-1:1.0: usb_probe_interface - got id > [ 301.050296] usb 1-1: adding 1-1:1.1 (config #1, interface 1) > [ 301.054897] usb 1-1: adding 1-1:1.2 (config #1, interface 2) > [ 301.056934] uvcvideo 1-1:1.2: usb_probe_interface > [ 301.058072] uvcvideo 1-1:1.2: usb_probe_interface - got id > [ 301.059395] uvcvideo: Found UVC 1.00 device (046d:081d) > [ 301.090173] input: UVC Camera (046d:081d) as > /devices/pci:00/:00:1f.5/usb1/1-1/1-1:1.2/input/input7 > [ 301.111289] usb 1-1: adding 1-1:1.3 (config #1, interface 3) > [ 301.131207] usb 1-1: link qh16-0001/f48d64c0 start 2 [1/0 us] > [ 301.137066] usb 1-1: unlink qh16-0001/f48d64c0 start 2 [1/0 us] > [ 301.156451] ehci_hcd :00:1f.5: reused qh f48d64c0 schedule > [ 301.158
Re: Re: Re: A reliable kernel panic (3.6.2) and system crash when visiting a particular website
You don't get me - I have *no* VirtualBox (or any proprietary) modules running - but I can reproduce this problem using *the same system running under* VirtualBox in Windows 7 64. It's almost definitely either a USB driver bug or video4linux driver bug: I'm CC'ing linux-media and linux-usb mailing lists, the problem is described here: https://lkml.org/lkml/2012/10/20/35 https://lkml.org/lkml/2012/10/20/148 Here are the last lines from my dmesg (with usbmon loaded): [ 292.164833] hub 1-0:1.0: state 7 ports 8 chg evt 0002 [ 292.168091] ehci_hcd :00:1f.5: GetStatus port:1 status 00100a 0 ACK POWER sig=se0 PEC CSC [ 292.172063] hub 1-0:1.0: port 1, status 0100, change 0003, 12 Mb/s [ 292.174883] usb 1-1: USB disconnect, device number 2 [ 292.178045] usb 1-1: unregistering device [ 292.183539] usb 1-1: unregistering interface 1-1:1.0 [ 292.197034] usb 1-1: unregistering interface 1-1:1.1 [ 292.204317] usb 1-1: unregistering interface 1-1:1.2 [ 292.234519] usb 1-1: unregistering interface 1-1:1.3 [ 292.236175] usb 1-1: usb_disable_device nuking all URBs [ 292.364429] hub 1-0:1.0: debounce: port 1: total 100ms stable 100ms status 0x100 [ 294.364279] hub 1-0:1.0: hub_suspend [ 294.366045] usb usb1: bus auto-suspend, wakeup 1 [ 294.367375] ehci_hcd :00:1f.5: suspend root hub [ 296.501084] usb usb1: usb wakeup-resume [ 296.508311] usb usb1: usb auto-resume [ 296.509833] ehci_hcd :00:1f.5: resume root hub [ 296.560149] hub 1-0:1.0: hub_resume [ 296.562240] ehci_hcd :00:1f.5: GetStatus port:1 status 001003 0 ACK POWER sig=se0 CSC CONNECT [ 296.566141] hub 1-0:1.0: port 1: status 0501 change 0001 [ 296.670413] hub 1-0:1.0: state 7 ports 8 chg 0002 evt [ 296.673222] hub 1-0:1.0: port 1, status 0501, change , 480 Mb/s [ 297.311720] usb 1-1: new high-speed USB device number 3 using ehci_hcd [ 300.547237] usb 1-1: skipped 1 descriptor after configuration [ 300.549443] usb 1-1: skipped 4 descriptors after interface [ 300.552273] usb 1-1: skipped 2 descriptors after interface [ 300.556499] usb 1-1: skipped 1 descriptor after endpoint [ 300.559392] usb 1-1: skipped 2 descriptors after interface [ 300.560960] usb 1-1: skipped 1 descriptor after endpoint [ 300.562169] usb 1-1: skipped 2 descriptors after interface [ 300.563440] usb 1-1: skipped 1 descriptor after endpoint [ 300.564639] usb 1-1: skipped 2 descriptors after interface [ 300.565828] usb 1-1: skipped 2 descriptors after endpoint [ 300.567084] usb 1-1: skipped 9 descriptors after interface [ 300.569205] usb 1-1: skipped 1 descriptor after endpoint [ 300.570484] usb 1-1: skipped 53 descriptors after interface [ 300.595843] usb 1-1: default language 0x0409 [ 300.602503] usb 1-1: USB interface quirks for this device: 2 [ 300.605700] usb 1-1: udev 3, busnum 1, minor = 2 [ 300.606959] usb 1-1: New USB device found, idVendor=046d, idProduct=081d [ 300.610298] usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=1 [ 300.613742] usb 1-1: SerialNumber: 48C5D2B0 [ 300.617703] usb 1-1: usb_probe_device [ 300.620594] usb 1-1: configuration #1 chosen from 1 choice [ 300.639218] usb 1-1: adding 1-1:1.0 (config #1, interface 0) [ 300.640736] snd-usb-audio 1-1:1.0: usb_probe_interface [ 300.642307] snd-usb-audio 1-1:1.0: usb_probe_interface - got id [ 301.050296] usb 1-1: adding 1-1:1.1 (config #1, interface 1) [ 301.054897] usb 1-1: adding 1-1:1.2 (config #1, interface 2) [ 301.056934] uvcvideo 1-1:1.2: usb_probe_interface [ 301.058072] uvcvideo 1-1:1.2: usb_probe_interface - got id [ 301.059395] uvcvideo: Found UVC 1.00 device (046d:081d) [ 301.090173] input: UVC Camera (046d:081d) as /devices/pci:00/:00:1f.5/usb1/1-1/1-1:1.2/input/input7 [ 301.111289] usb 1-1: adding 1-1:1.3 (config #1, interface 3) [ 301.131207] usb 1-1: link qh16-0001/f48d64c0 start 2 [1/0 us] [ 301.137066] usb 1-1: unlink qh16-0001/f48d64c0 start 2 [1/0 us] [ 301.156451] ehci_hcd :00:1f.5: reused qh f48d64c0 schedule [ 301.158310] usb 1-1: link qh16-0001/f48d64c0 start 2 [1/0 us] [ 301.160238] usb 1-1: unlink qh16-0001/f48d64c0 start 2 [1/0 us] [ 301.196606] set resolution quirk: cval->res = 384 [ 371.309569] e1000: eth1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX [ 390.729568] ehci_hcd :00:1f.5: reused qh f48d64c0 schedule f5ade900 2296555[ 390.730023] usb 1-1: link qh16-0001/f48d64c0 start 2 [1/0 us] 437 S Ii:1:003:7[ 390.736394] usb 1-1: unlink qh16-0001/f48d64c0 start 2 [1/0 us] -115:128 16 < f5ade900 2296566256 C Ii:1:003:7 -2:128 0 [ 391.100896] ehci_hcd :00:1f.5: reused qh f48d64c0 schedule [ 391.103188] usb 1-1: link qh16-0001/f48d64c0 start 2 [1/0 us] f5ade900 2296926929 S Ii:1:003:7[ 391.104889] usb 1-1: unlink qh16-0001/f48d64c0 start 2 [1/0 us] -115:128 16 < f5ade900 2296937889 C Ii:1:003:7 -2:128 0 f5272300 2310382508 S Co:1:003:0 s 01 0b 0004 0001 0 f5272300 2310407888 C Co:1:003:0 0 0 f5272300 2310408051 S Co:1:003:0 s 22 01 0100 0086
[PATCH 1/2] omap3isp: Add resizer data rate configuration to resizer_link_validate
The configuration of many other blocks depend on resizer maximum data rate.
Get the value from resizer at link validation time.
Signed-off-by: Sakari Ailus
Acked-by: Laurent Pinchart
---
drivers/media/platform/omap3isp/ispresizer.c | 15 +++
drivers/media/platform/omap3isp/ispvideo.c | 54 --
2 files changed, 15 insertions(+), 54 deletions(-)
diff --git a/drivers/media/platform/omap3isp/ispresizer.c
b/drivers/media/platform/omap3isp/ispresizer.c
index d11fb26..bb5fb4a 100644
--- a/drivers/media/platform/omap3isp/ispresizer.c
+++ b/drivers/media/platform/omap3isp/ispresizer.c
@@ -1532,6 +1532,20 @@ static int resizer_set_format(struct v4l2_subdev *sd,
struct v4l2_subdev_fh *fh,
return 0;
}
+static int resizer_link_validate(struct v4l2_subdev *sd,
+struct media_link *link,
+struct v4l2_subdev_format *source_fmt,
+struct v4l2_subdev_format *sink_fmt)
+{
+ struct isp_res_device *res = v4l2_get_subdevdata(sd);
+ struct isp_pipeline *pipe = to_isp_pipeline(&sd->entity);
+
+ omap3isp_resizer_max_rate(res, &pipe->max_rate);
+
+ return v4l2_subdev_link_validate_default(sd, link,
+source_fmt, sink_fmt);
+}
+
/*
* resizer_init_formats - Initialize formats on all pads
* @sd: ISP resizer V4L2 subdevice
@@ -1570,6 +1584,7 @@ static const struct v4l2_subdev_pad_ops
resizer_v4l2_pad_ops = {
.set_fmt = resizer_set_format,
.get_selection = resizer_get_selection,
.set_selection = resizer_set_selection,
+ .link_validate = resizer_link_validate,
};
/* subdev operations */
diff --git a/drivers/media/platform/omap3isp/ispvideo.c
b/drivers/media/platform/omap3isp/ispvideo.c
index a0b737fe..aae70f7 100644
--- a/drivers/media/platform/omap3isp/ispvideo.c
+++ b/drivers/media/platform/omap3isp/ispvideo.c
@@ -280,55 +280,6 @@ static int isp_video_get_graph_data(struct isp_video
*video,
return 0;
}
-/*
- * Validate a pipeline by checking both ends of all links for format
- * discrepancies.
- *
- * Compute the minimum time per frame value as the maximum of time per frame
- * limits reported by every block in the pipeline.
- *
- * Return 0 if all formats match, or -EPIPE if at least one link is found with
- * different formats on its two ends or if the pipeline doesn't start with a
- * video source (either a subdev with no input pad, or a non-subdev entity).
- */
-static int isp_video_validate_pipeline(struct isp_pipeline *pipe)
-{
- struct isp_device *isp = pipe->output->isp;
- struct media_pad *pad;
- struct v4l2_subdev *subdev;
-
- subdev = isp_video_remote_subdev(pipe->output, NULL);
- if (subdev == NULL)
- return -EPIPE;
-
- while (1) {
- /* Retrieve the sink format */
- pad = &subdev->entity.pads[0];
- if (!(pad->flags & MEDIA_PAD_FL_SINK))
- break;
-
- /* Update the maximum frame rate */
- if (subdev == &isp->isp_res.subdev)
- omap3isp_resizer_max_rate(&isp->isp_res,
- &pipe->max_rate);
-
- /* Retrieve the source format. Return an error if no source
-* entity can be found, and stop checking the pipeline if the
-* source entity isn't a subdev.
-*/
- pad = media_entity_remote_source(pad);
- if (pad == NULL)
- return -EPIPE;
-
- if (media_entity_type(pad->entity) != MEDIA_ENT_T_V4L2_SUBDEV)
- break;
-
- subdev = media_entity_to_v4l2_subdev(pad->entity);
- }
-
- return 0;
-}
-
static int
__isp_video_get_format(struct isp_video *video, struct v4l2_format *format)
{
@@ -1056,11 +1007,6 @@ isp_video_streamon(struct file *file, void *fh, enum
v4l2_buf_type type)
if (ret < 0)
goto err_check_format;
- /* Validate the pipeline and update its state. */
- ret = isp_video_validate_pipeline(pipe);
- if (ret < 0)
- goto err_check_format;
-
pipe->error = false;
spin_lock_irqsave(&pipe->lock, flags);
--
1.7.2.5
--
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
[PATCH 2/2] omap3isp: Find source pad from external entity
No longer assume pad number 0 is the source pad of the external entity. Find
the source pad from the external entity and use it instead.
Signed-off-by: Sakari Ailus
Acked-by: Laurent Pinchart
---
drivers/media/platform/omap3isp/isp.c | 14 +-
1 files changed, 13 insertions(+), 1 deletions(-)
diff --git a/drivers/media/platform/omap3isp/isp.c
b/drivers/media/platform/omap3isp/isp.c
index 5ea5520..5f75798 100644
--- a/drivers/media/platform/omap3isp/isp.c
+++ b/drivers/media/platform/omap3isp/isp.c
@@ -1767,6 +1767,7 @@ static int isp_register_entities(struct isp_device *isp)
struct media_entity *input;
unsigned int flags;
unsigned int pad;
+ unsigned int i;
sensor = isp_register_subdev_group(isp, subdevs->subdevs);
if (sensor == NULL)
@@ -1814,7 +1815,18 @@ static int isp_register_entities(struct isp_device *isp)
goto done;
}
- ret = media_entity_create_link(&sensor->entity, 0, input, pad,
+ for (i = 0; i < sensor->entity.num_pads; i++) {
+ if (sensor->entity.pads[i].flags & MEDIA_PAD_FL_SOURCE)
+ break;
+ }
+ if (i == sensor->entity.num_pads) {
+ dev_err(isp->dev,
+ "no source pads in external entities\n");
+ ret = -EINVAL;
+ goto done;
+ }
+
+ ret = media_entity_create_link(&sensor->entity, i, input, pad,
flags);
if (ret < 0)
goto done;
--
1.7.2.5
--
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
[PATCH 0/2] Old omap3isp improvements
Hi Laurent, These are the final omap3isp improvements I were left over from my earlier largish patchset around half a year ago. You seem to have acked these previously, but they depended on other patches that were contested at the time --- and which now are in your tree. How about putting them in now? Kind regards, -- Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- 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
Re: [PATCH] v4l: Don't warn during link validation when encountering a V4L2 devnode
On Sat, Oct 20, 2012 at 11:04:33PM +0200, Laurent Pinchart wrote: > v4l2_subdev_link_validate_get_format() retrieves the remote pad format > depending on the entity type and prints a warning if the entity type is > not supported. The type check doesn't take the subtype into account, and > thus always prints a warning for device node types, even when supported. > Fix it. > > Signed-off-by: Laurent Pinchart Thanks! Acked-by: Sakari Ailus -- Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- 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
[PATCH] v4l: Don't warn during link validation when encountering a V4L2 devnode
v4l2_subdev_link_validate_get_format() retrieves the remote pad format
depending on the entity type and prints a warning if the entity type is
not supported. The type check doesn't take the subtype into account, and
thus always prints a warning for device node types, even when supported.
Fix it.
Signed-off-by: Laurent Pinchart
---
drivers/media/video/v4l2-subdev.c | 22 +++---
1 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/media/video/v4l2-subdev.c
b/drivers/media/video/v4l2-subdev.c
index 9182f81..5f74d96 100644
--- a/drivers/media/video/v4l2-subdev.c
+++ b/drivers/media/video/v4l2-subdev.c
@@ -406,20 +406,20 @@ static int
v4l2_subdev_link_validate_get_format(struct media_pad *pad,
struct v4l2_subdev_format *fmt)
{
- switch (media_entity_type(pad->entity)) {
- case MEDIA_ENT_T_V4L2_SUBDEV:
+ if (media_entity_type(pad->entity) == MEDIA_ENT_T_V4L2_SUBDEV) {
+ struct v4l2_subdev *sd =
+ media_entity_to_v4l2_subdev(pad->entity);
+
fmt->which = V4L2_SUBDEV_FORMAT_ACTIVE;
fmt->pad = pad->index;
- return v4l2_subdev_call(media_entity_to_v4l2_subdev(
- pad->entity),
- pad, get_fmt, NULL, fmt);
- default:
- WARN(1, "Driver bug! Wrong media entity type %d, entity %s\n",
-media_entity_type(pad->entity), pad->entity->name);
- /* Fall through */
- case MEDIA_ENT_T_DEVNODE_V4L:
- return -EINVAL;
+ return v4l2_subdev_call(sd, pad, get_fmt, NULL, fmt);
}
+
+ WARN(pad->entity->type != MEDIA_ENT_T_DEVNODE_V4L,
+"Driver bug! Wrong media entity type 0x%08x, entity %s\n",
+pad->entity->type, pad->entity->name);
+
+ return -EINVAL;
}
int v4l2_subdev_link_validate(struct media_link *link)
--
Regards,
Laurent Pinchart
--
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
[PATCH] it913x [BUG] Enable endpoint 3 on devices with HID interface.
On some USB controllers when endpoint 3 (used by HID) is not enabled
this causes a USB reset.
Signed-off-by: Malcolm Priestley
---
drivers/media/usb/dvb-usb-v2/it913x.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/media/usb/dvb-usb-v2/it913x.c
b/drivers/media/usb/dvb-usb-v2/it913x.c
index 695f910..4498f60 100644
--- a/drivers/media/usb/dvb-usb-v2/it913x.c
+++ b/drivers/media/usb/dvb-usb-v2/it913x.c
@@ -659,13 +659,19 @@ static int it913x_frontend_attach(struct dvb_usb_adapter
*adap)
it913x_wr_reg(d, DEV_0_DMOD, MP2IF2_SW_RST, 0x1);
it913x_wr_reg(d, DEV_0, EP0_TX_EN, 0x0f);
it913x_wr_reg(d, DEV_0, EP0_TX_NAK, 0x1b);
- it913x_wr_reg(d, DEV_0, EP0_TX_EN, 0x2f);
+ if (st->proprietary_ir == false) /* Enable endpoint 3 */
+ it913x_wr_reg(d, DEV_0, EP0_TX_EN, 0x3f);
+ else
+ it913x_wr_reg(d, DEV_0, EP0_TX_EN, 0x2f);
it913x_wr_reg(d, DEV_0, EP4_TX_LEN_LSB,
ep_size & 0xff);
it913x_wr_reg(d, DEV_0, EP4_TX_LEN_MSB, ep_size >> 8);
ret = it913x_wr_reg(d, DEV_0, EP4_MAX_PKT, pkt_size);
} else if (adap->id == 1 && adap->fe[0]) {
- it913x_wr_reg(d, DEV_0, EP0_TX_EN, 0x6f);
+ if (st->proprietary_ir == false)
+ it913x_wr_reg(d, DEV_0, EP0_TX_EN, 0x7f);
+ else
+ it913x_wr_reg(d, DEV_0, EP0_TX_EN, 0x6f);
it913x_wr_reg(d, DEV_0, EP5_TX_LEN_LSB,
ep_size & 0xff);
it913x_wr_reg(d, DEV_0, EP5_TX_LEN_MSB, ep_size >> 8);
--
1.7.10.4
--
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
cron job: media_tree daily build: WARNINGS
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:Sat Oct 20 19:00:24 CEST 2012 git hash:74df06daf632ce2d321d01cb046004768352efc4 gcc version: i686-linux-gcc (GCC) 4.7.1 host hardware:x86_64 host os: 3.4.07-marune linux-git-arm-eabi-davinci: WARNINGS linux-git-arm-eabi-exynos: WARNINGS linux-git-arm-eabi-omap: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: WARNINGS linux-git-mips: WARNINGS linux-git-powerpc64: OK linux-git-sh: WARNINGS linux-git-x86_64: WARNINGS linux-2.6.31.12-i686: WARNINGS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.39.1-i686: WARNINGS linux-3.0-i686: WARNINGS linux-3.1-i686: WARNINGS linux-3.2.1-i686: WARNINGS linux-3.3-i686: WARNINGS linux-3.4-i686: WARNINGS linux-3.5-i686: WARNINGS linux-3.6-i686: WARNINGS linux-3.7-rc1-i686: WARNINGS linux-2.6.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS linux-2.6.39.1-x86_64: WARNINGS linux-3.0-x86_64: WARNINGS linux-3.1-x86_64: WARNINGS linux-3.2.1-x86_64: WARNINGS linux-3.3-x86_64: WARNINGS linux-3.4-x86_64: WARNINGS linux-3.5-x86_64: WARNINGS linux-3.6-x86_64: WARNINGS linux-3.7-rc1-x86_64: WARNINGS apps: WARNINGS spec-git: WARNINGS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- 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
Re: [PATCH 1/2 v6] of: add helper to parse display timings
On Thu, Oct 04, 2012 at 07:59:19PM +0200, Steffen Trumtrar wrote:
[...]
> diff --git a/include/linux/of_display_timings.h
> b/include/linux/of_display_timings.h
[...]
> +struct display_timings {
> + unsigned int num_timings;
> + unsigned int default_timing;
> +
> + struct signal_timing **timings;
> +};
> +
> +struct timing_entry {
> + u32 min;
> + u32 typ;
> + u32 max;
> +};
> +
> +struct signal_timing {
I'm slightly confused by the naming here. signal_timing seems overly
generic in this context. Is there any reason why this isn't called
display_timing or even display_mode?
pgp4IEEZTAHtO.pgp
Description: PGP signature
Re: [PATCH v5.1 1/3] omap3isp: Add CSI configuration registers from control block to ISP resources
Hi Sakari,
On Saturday 20 October 2012 17:11:17 Sakari Ailus wrote:
> Add the registers used to configure the CSI-2 receiver PHY on OMAP3430 and
> 3630 and map them in the ISP driver. The register is part of the control
> block but it only is needed by the ISP driver.
>
> Signed-off-by: Sakari Ailus
> Acked-by: Tony Lindgren
> ---
> Hi Laurent,
>
> Could you replace the patch I sent you with this one? I think there's a tiny
> conflict there since the interrupt number definition suddenly changed.
I had already resolved the conflict when applying to my tree
(http://git.linuxtv.org/pinchartl/media.git/shortlog/refs/heads/omap3isp-
omap3isp-next).
> arch/arm/mach-omap2/devices.c | 10 ++
> drivers/media/platform/omap3isp/isp.c |6 --
> drivers/media/platform/omap3isp/isp.h |2 ++
> 3 files changed, 16 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
> index c8c2117..5f1ee96 100644
> --- a/arch/arm/mach-omap2/devices.c
> +++ b/arch/arm/mach-omap2/devices.c
> @@ -200,6 +200,16 @@ static struct resource omap3isp_resources[] = {
> .flags = IORESOURCE_MEM,
> },
> {
> + .start = OMAP343X_CTRL_BASE + OMAP343X_CONTROL_CSIRXFE,
> + .end= OMAP343X_CTRL_BASE + OMAP343X_CONTROL_CSIRXFE
> + 3,
> + .flags = IORESOURCE_MEM,
> + },
> + {
> + .start = OMAP343X_CTRL_BASE +
> OMAP3630_CONTROL_CAMERA_PHY_CTRL,
> + .end= OMAP343X_CTRL_BASE +
> OMAP3630_CONTROL_CAMERA_PHY_CTRL + 3,
> + .flags = IORESOURCE_MEM,
> + },
> + {
> .start = 24 + OMAP_INTC_START,
> .flags = IORESOURCE_IRQ,
> }
> diff --git a/drivers/media/platform/omap3isp/isp.c
> b/drivers/media/platform/omap3isp/isp.c index 99640d8..5ea5520 100644
> --- a/drivers/media/platform/omap3isp/isp.c
> +++ b/drivers/media/platform/omap3isp/isp.c
> @@ -102,7 +102,8 @@ static const struct isp_res_mapping isp_res_maps[] = {
> 1 << OMAP3_ISP_IOMEM_RESZ |
> 1 << OMAP3_ISP_IOMEM_SBL |
> 1 << OMAP3_ISP_IOMEM_CSI2A_REGS1 |
> -1 << OMAP3_ISP_IOMEM_CSIPHY2,
> +1 << OMAP3_ISP_IOMEM_CSIPHY2 |
> +1 << OMAP3_ISP_IOMEM_343X_CONTROL_CSIRXFE,
> },
> {
> .isp_rev = ISP_REVISION_15_0,
> @@ -119,7 +120,8 @@ static const struct isp_res_mapping isp_res_maps[] = {
> 1 << OMAP3_ISP_IOMEM_CSI2A_REGS2 |
> 1 << OMAP3_ISP_IOMEM_CSI2C_REGS1 |
> 1 << OMAP3_ISP_IOMEM_CSIPHY1 |
> -1 << OMAP3_ISP_IOMEM_CSI2C_REGS2,
> +1 << OMAP3_ISP_IOMEM_CSI2C_REGS2 |
> +1 << OMAP3_ISP_IOMEM_3630_CONTROL_CAMERA_PHY_CTRL,
> },
> };
>
> diff --git a/drivers/media/platform/omap3isp/isp.h
> b/drivers/media/platform/omap3isp/isp.h index 8be7487..6fed222 100644
> --- a/drivers/media/platform/omap3isp/isp.h
> +++ b/drivers/media/platform/omap3isp/isp.h
> @@ -72,6 +72,8 @@ enum isp_mem_resources {
> OMAP3_ISP_IOMEM_CSI2C_REGS1,
> OMAP3_ISP_IOMEM_CSIPHY1,
> OMAP3_ISP_IOMEM_CSI2C_REGS2,
> + OMAP3_ISP_IOMEM_343X_CONTROL_CSIRXFE,
> + OMAP3_ISP_IOMEM_3630_CONTROL_CAMERA_PHY_CTRL,
> OMAP3_ISP_IOMEM_LAST
> };
--
Regards,
Laurent Pinchart
--
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
Re: [RFC 0/5] Generic panel framework
correct some typo. Sorry for this. 2012/10/20 Inki Dae : > Hi Laurent. sorry for being late. > > 2012/8/17 Laurent Pinchart : >> Hi everybody, >> >> While working on DT bindings for the Renesas Mobile SoC display controller >> (a.k.a. LCDC) I quickly realized that display panel implementation based on >> board code callbacks would need to be replaced by a driver-based panel >> framework. >> >> Several driver-based panel support solution already exist in the kernel. >> >> - The LCD device class is implemented in drivers/video/backlight/lcd.c and >> exposes a kernel API in include/linux/lcd.h. That API is tied to the FBDEV >> API for historical reason, uses board code callback for reset and power >> management, and doesn't include support for standard features available in >> today's "smart panels". >> >> - OMAP2+ based systems use custom panel drivers available in >> drivers/video/omap2/displays. Those drivers are based on OMAP DSS (display >> controller) specific APIs. >> >> - Similarly, Exynos based systems use custom panel drivers available in >> drivers/video/exynos. Only a single driver (s6e8ax0) is currently >> available. >> That driver is based on Exynos display controller specific APIs and on the >> LCD device class API. >> >> I've brought up the issue with Tomi Valkeinen (OMAP DSS maintainer) and >> Marcus >> Lorentzon (working on panel support for ST/Linaro), and we agreed that a >> generic panel framework for display devices is needed. These patches >> implement >> a first proof of concept. >> >> One of the main reasons for creating a new panel framework instead of adding >> missing features to the LCD framework is to avoid being tied to the FBDEV >> framework. Panels will be used by DRM drivers as well, and their API should >> thus be subsystem-agnostic. Note that the panel framework used the >> fb_videomode structure in its API, this will be replaced by a common video >> mode structure shared across subsystems (there's only so many hours per day). >> >> Panels, as used in these patches, are defined as physical devices combining a >> matrix of pixels and a controller capable of driving that matrix. >> >> Panel physical devices are registered as children of the control bus the >> panel >> controller is connected to (depending on the panel type, we can find platform >> devices for dummy panels with no control bus, or I2C, SPI, DBI, DSI, ... >> devices). The generic panel framework matches registered panel devices with >> panel drivers and call the panel drivers probe method, as done by other >> device >> classes in the kernel. The driver probe() method is responsible for >> instantiating a struct panel instance and registering it with the generic >> panel framework. >> >> Display drivers are panel consumers. They register a panel notifier with the >> framework, which then calls the notifier when a matching panel is registered. >> The reason for this asynchronous mode of operation, compared to how drivers >> acquire regulator or clock resources, is that the panel can use resources >> provided by the display driver. For instance a panel can be a child of the >> DBI >> or DSI bus controlled by the display device, or use a clock provided by that >> device. We can't defer the display device probe until the panel is registered >> and also defer the panel device probe until the display is registered. As >> most display drivers need to handle output devices hotplug (HDMI monitors for >> instance), handling panel through a notification system seemed to be the >> easiest solution. >> >> Note that this brings a different issue after registration, as display and >> panel drivers would take a reference to each other. Those circular references >> would make driver unloading impossible. I haven't found a good solution for >> that problem yet (hence the RFC state of those patches), and I would >> appreciate your input here. This might also be a hint that the framework >> design is wrong to start with. I guess I can't get everything right on the >> first try ;-) >> >> Getting hold of the panel is the most complex part. Once done, display >> drivers >> can call abstract operations provided by panel drivers to control the panel >> operation. These patches implement three of those operations (enable, start >> transfer and get modes). More operations will be needed, and those three >> operations will likely get modified during review. Most of the panels on >> devices I own are dumb panels with no control bus, and are thus not the best >> candidates to design a framework that needs to take complex panels' needs >> into >> account. >> >> In addition to the generic panel core, I've implemented MIPI DBI (Display Bus >> Interface, a parallel bus for panels that supports read/write transfers of >> commands and data) bus support, as well as three panel drivers (dummy panels >> with no control bus, and Renesas R61505- and R61517-based panels, both using >> DBI as their control bus). Only the dummy p
Re: [RFC 0/5] Generic panel framework
Hi Tomi, 2012/8/17 Tomi Valkeinen : > Hi, > > On Fri, 2012-08-17 at 02:49 +0200, Laurent Pinchart wrote: > >> I will appreciate all reviews, comments, criticisms, ideas, remarks, ... If > > Oookay, where to start... ;) > > A few cosmetic/general comments first. > > I find the file naming a bit strange. You have panel.c, which is the > core framework, panel-dbi.c, which is the DBI bus, panel-r61517.c, which > is driver for r61517 panel... > > Perhaps something in this direction (in order): panel-core.c, > mipi-dbi-bus.c, panel-r61517.c? And we probably end up with quite a lot > of panel drivers, perhaps we should already divide these into separate > directories, and then we wouldn't need to prefix each panel with > "panel-" at all. > > --- > > Should we aim for DT only solution from the start? DT is the direction > we are going, and I feel the older platform data stuff would be > deprecated soon. > > --- > > Something missing from the intro is how this whole thing should be used. > It doesn't help if we know how to turn on the panel, we also need to > display something on it =). So I think some kind of diagram/example of > how, say, drm would use this thing, and also how the SoC specific DBI > bus driver would be done, would clarify things. > > --- > > We have discussed face to face about the different hardware setups and > scenarios that we should support, but I'll list some of them here for > others: > > 1) We need to support chains of external display chips and panels. A > simple example is a chip that takes DSI in, and outputs DPI. In that > case we'd have a chain of SoC -> DSI2DPI -> DPI panel. > > In final products I think two external devices is the maximum (at least > I've never seen three devices in a row), but in theory and in > development environments the chain can be arbitrarily long. Also the > connections are not necessarily 1-to-1, but a device can take one input > while it has two outputs, or a device can take two inputs. > > Now, I think two external devices is a must requirement. I'm not sure if > supporting more is an important requirement. However, if we support two > devices, it could be that it's trivial to change the framework to > support n devices. > > 2) Panels and display chips are all but standard. They very often have > their own sequences how to do things, have bugs, or implement some > feature in slightly different way than some other panel. This is why the > panel driver should be able to control or define the way things happen. > > As an example, Sharp LQ043T1DG01 panel > (www.sharpsme.com/download/LQ043T1DG01-SP-072106pdf). It is enabled with > the following sequence: > > - Enable VCC and AVDD regulators > - Wait min 50ms > - Enable full video stream (pck, syncs, pixels) from SoC > - Wait min 0.5ms > - Set DISP GPIO, which turns on the display panel > > Here we could split the enabling of panel to two parts, prepare (in this > case starts regulators and waits 50ms) and finish (wait 0.5ms and set > DISP GPIO), and the upper layer would start the video stream in between. > > I realize this could be done with the PANEL_ENABLE_* levels in your RFC, > but I don't think the concepts quite match: > > - PANEL_ENABLE_BLANK level is needed for "smart panels", as we need to > configure them and send the initial frame at that operating level. With The smart panel means command mode way(same as cpu mode)? This panel includes framebuffer internally and needs triggering from Display controller to update a new frame on that internal framebuffer. I think we also need this trigger interface. Thanks, Inki Dae > dummy panels there's really no such level, there's just one enable > sequence that is always done right away. > > - I find waiting at the beginning of a function very ugly (what are we > waiting for?) and we'd need that when changing the panel to > PANEL_ENABLE_ON level. > > - It's still limited if the panel is a stranger one (see following > example). > > Consider the following theoretical panel enable example, taken to absurd > level just to show the general problem: > > - Enable regulators > - Enable video stream > - Wait 50ms > - Disable video stream > - Set enable GPIO > - Enable video stream > > This one would be rather impossible with the upper layer handling the > enabling of the video stream. Thus I see that the panel driver needs to > control the sequences, and the Sharp panel driver's enable would look > something like: > > regulator_enable(...); > sleep(); > dpi_enable_video(); > sleep(); > gpip_set(..); > > Note that even with this model we still need the PANEL_ENABLE levels you > have. > > --- > > I'm not sure I understand the panel unload problem you mentioned. Nobody > should have direct references to the panel functions, so there shouldn't > be any automatic references that would prevent module unloading. So when > the user does rmmod panel-mypanel, the panel driver's remove will be > called. It'll unregister itself from the panel framework, which causes > notifi
[PATCH v5.1 1/3] omap3isp: Add CSI configuration registers from control block to ISP resources
Add the registers used to configure the CSI-2 receiver PHY on OMAP3430 and
3630 and map them in the ISP driver. The register is part of the control
block but it only is needed by the ISP driver.
Signed-off-by: Sakari Ailus
Acked-by: Tony Lindgren
---
Hi Laurent,
Could you replace the patch I sent you with this one? I think there's a tiny
conflict there since the interrupt number definition suddenly changed.
arch/arm/mach-omap2/devices.c | 10 ++
drivers/media/platform/omap3isp/isp.c |6 --
drivers/media/platform/omap3isp/isp.h |2 ++
3 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index c8c2117..5f1ee96 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -200,6 +200,16 @@ static struct resource omap3isp_resources[] = {
.flags = IORESOURCE_MEM,
},
{
+ .start = OMAP343X_CTRL_BASE + OMAP343X_CONTROL_CSIRXFE,
+ .end= OMAP343X_CTRL_BASE + OMAP343X_CONTROL_CSIRXFE
+ 3,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = OMAP343X_CTRL_BASE +
OMAP3630_CONTROL_CAMERA_PHY_CTRL,
+ .end= OMAP343X_CTRL_BASE +
OMAP3630_CONTROL_CAMERA_PHY_CTRL + 3,
+ .flags = IORESOURCE_MEM,
+ },
+ {
.start = 24 + OMAP_INTC_START,
.flags = IORESOURCE_IRQ,
}
diff --git a/drivers/media/platform/omap3isp/isp.c
b/drivers/media/platform/omap3isp/isp.c
index 99640d8..5ea5520 100644
--- a/drivers/media/platform/omap3isp/isp.c
+++ b/drivers/media/platform/omap3isp/isp.c
@@ -102,7 +102,8 @@ static const struct isp_res_mapping isp_res_maps[] = {
1 << OMAP3_ISP_IOMEM_RESZ |
1 << OMAP3_ISP_IOMEM_SBL |
1 << OMAP3_ISP_IOMEM_CSI2A_REGS1 |
- 1 << OMAP3_ISP_IOMEM_CSIPHY2,
+ 1 << OMAP3_ISP_IOMEM_CSIPHY2 |
+ 1 << OMAP3_ISP_IOMEM_343X_CONTROL_CSIRXFE,
},
{
.isp_rev = ISP_REVISION_15_0,
@@ -119,7 +120,8 @@ static const struct isp_res_mapping isp_res_maps[] = {
1 << OMAP3_ISP_IOMEM_CSI2A_REGS2 |
1 << OMAP3_ISP_IOMEM_CSI2C_REGS1 |
1 << OMAP3_ISP_IOMEM_CSIPHY1 |
- 1 << OMAP3_ISP_IOMEM_CSI2C_REGS2,
+ 1 << OMAP3_ISP_IOMEM_CSI2C_REGS2 |
+ 1 << OMAP3_ISP_IOMEM_3630_CONTROL_CAMERA_PHY_CTRL,
},
};
diff --git a/drivers/media/platform/omap3isp/isp.h
b/drivers/media/platform/omap3isp/isp.h
index 8be7487..6fed222 100644
--- a/drivers/media/platform/omap3isp/isp.h
+++ b/drivers/media/platform/omap3isp/isp.h
@@ -72,6 +72,8 @@ enum isp_mem_resources {
OMAP3_ISP_IOMEM_CSI2C_REGS1,
OMAP3_ISP_IOMEM_CSIPHY1,
OMAP3_ISP_IOMEM_CSI2C_REGS2,
+ OMAP3_ISP_IOMEM_343X_CONTROL_CSIRXFE,
+ OMAP3_ISP_IOMEM_3630_CONTROL_CAMERA_PHY_CTRL,
OMAP3_ISP_IOMEM_LAST
};
--
1.7.2.5
--
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
[PATCH] ARM: dm365: replace V4L2_OUT_CAP_CUSTOM_TIMINGS with V4L2_OUT_CAP_DV_TIMINGS
From: Lad, Prabhakar
This patch replaces V4L2_OUT_CAP_CUSTOM_TIMINGS macro with
V4L2_OUT_CAP_DV_TIMINGS. As V4L2_OUT_CAP_CUSTOM_TIMINGS is being phased
out.
Signed-off-by: Lad, Prabhakar
Signed-off-by: Manjunath Hadli
Cc: Sekhar Nori
---
This patch is based on the following patch series,
ARM: davinci: dm365 EVM: add support for VPBE display
(https://patchwork.kernel.org/patch/1295071/)
arch/arm/mach-davinci/board-dm365-evm.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-davinci/board-dm365-evm.c
b/arch/arm/mach-davinci/board-dm365-evm.c
index 2924d61..771abb5 100644
--- a/arch/arm/mach-davinci/board-dm365-evm.c
+++ b/arch/arm/mach-davinci/board-dm365-evm.c
@@ -514,7 +514,7 @@ static struct vpbe_output dm365evm_vpbe_outputs[] = {
.index = 1,
.name = "Component",
.type = V4L2_OUTPUT_TYPE_ANALOG,
- .capabilities = V4L2_OUT_CAP_CUSTOM_TIMINGS,
+ .capabilities = V4L2_OUT_CAP_DV_TIMINGS,
},
.subdev_name= VPBE_VENC_SUBDEV_NAME,
.default_mode = "480p59_94",
--
1.7.4.1
--
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
[PATCH 2/2] media: davinci: vpbe: set device capabilities
From: Lad, Prabhakar set device_caps and also change the driver and bus_info to proper values as per standard. Signed-off-by: Lad, Prabhakar Signed-off-by: Manjunath Hadli --- drivers/media/platform/davinci/vpbe_display.c |9 ++--- 1 files changed, 6 insertions(+), 3 deletions(-) diff --git a/drivers/media/platform/davinci/vpbe_display.c b/drivers/media/platform/davinci/vpbe_display.c index 974957f..2bfde79 100644 --- a/drivers/media/platform/davinci/vpbe_display.c +++ b/drivers/media/platform/davinci/vpbe_display.c @@ -702,9 +702,12 @@ static int vpbe_display_querycap(struct file *file, void *priv, struct vpbe_device *vpbe_dev = fh->disp_dev->vpbe_dev; cap->version = VPBE_DISPLAY_VERSION_CODE; - cap->capabilities = V4L2_CAP_VIDEO_OUTPUT | V4L2_CAP_STREAMING; - strlcpy(cap->driver, VPBE_DISPLAY_DRIVER, sizeof(cap->driver)); - strlcpy(cap->bus_info, "platform", sizeof(cap->bus_info)); + cap->device_caps = V4L2_CAP_VIDEO_OUTPUT | V4L2_CAP_STREAMING; + cap->capabilities = cap->device_caps | V4L2_CAP_DEVICE_CAPS; + snprintf(cap->driver, sizeof(cap->driver), "%s", + dev_name(vpbe_dev->pdev)); + snprintf(cap->bus_info, sizeof(cap->bus_info), "platform:%s", +dev_name(vpbe_dev->pdev)); strlcpy(cap->card, vpbe_dev->cfg->module_name, sizeof(cap->card)); return 0; -- 1.7.4.1 -- 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
[PATCH 1/2] media: davinci: vpbe: migrate driver to videobuf2
From: Lad, Prabhakar
This patch migrates VPBE display driver to videobuf2 framework.
Signed-off-by: Lad, Prabhakar
Signed-off-by: Manjunath Hadli
---
drivers/media/platform/davinci/Kconfig|2 +-
drivers/media/platform/davinci/vpbe_display.c | 296 +++--
include/media/davinci/vpbe_display.h | 15 +-
3 files changed, 188 insertions(+), 125 deletions(-)
diff --git a/drivers/media/platform/davinci/Kconfig
b/drivers/media/platform/davinci/Kconfig
index 78e26d2..3c56037 100644
--- a/drivers/media/platform/davinci/Kconfig
+++ b/drivers/media/platform/davinci/Kconfig
@@ -101,7 +101,7 @@ config VIDEO_DM644X_VPBE
tristate "DM644X VPBE HW module"
depends on ARCH_DAVINCI_DM644x
select VIDEO_VPSS_SYSTEM
- select VIDEOBUF_DMA_CONTIG
+ select VIDEOBUF2_DMA_CONTIG
help
Enables VPBE modules used for display on a DM644x
SoC.
diff --git a/drivers/media/platform/davinci/vpbe_display.c
b/drivers/media/platform/davinci/vpbe_display.c
index 161c776..974957f 100644
--- a/drivers/media/platform/davinci/vpbe_display.c
+++ b/drivers/media/platform/davinci/vpbe_display.c
@@ -47,6 +47,9 @@ static int debug;
module_param(debug, int, 0644);
+static int vpbe_set_osd_display_params(struct vpbe_display *disp_dev,
+ struct vpbe_layer *layer);
+
static int venc_is_second_field(struct vpbe_display *disp_dev)
{
struct vpbe_device *vpbe_dev = disp_dev->vpbe_dev;
@@ -73,10 +76,11 @@ static void vpbe_isr_even_field(struct vpbe_display
*disp_obj,
if (layer->cur_frm == layer->next_frm)
return;
ktime_get_ts(&timevalue);
- layer->cur_frm->ts.tv_sec = timevalue.tv_sec;
- layer->cur_frm->ts.tv_usec = timevalue.tv_nsec / NSEC_PER_USEC;
- layer->cur_frm->state = VIDEOBUF_DONE;
- wake_up_interruptible(&layer->cur_frm->done);
+ layer->cur_frm->vb.v4l2_buf.timestamp.tv_sec =
+ timevalue.tv_sec;
+ layer->cur_frm->vb.v4l2_buf.timestamp.tv_usec =
+ timevalue.tv_nsec / NSEC_PER_USEC;
+ vb2_buffer_done(&layer->cur_frm->vb, VB2_BUF_STATE_DONE);
/* Make cur_frm pointing to next_frm */
layer->cur_frm = layer->next_frm;
}
@@ -99,16 +103,14 @@ static void vpbe_isr_odd_field(struct vpbe_display
*disp_obj,
* otherwise hold on current frame
* Get next from the buffer queue
*/
- layer->next_frm = list_entry(
- layer->dma_queue.next,
- struct videobuf_buffer,
- queue);
+ layer->next_frm = list_entry(layer->dma_queue.next,
+ struct vpbe_disp_buffer, list);
/* Remove that from the buffer queue */
- list_del(&layer->next_frm->queue);
+ list_del(&layer->next_frm->list);
spin_unlock(&disp_obj->dma_queue_lock);
/* Mark state of the frame to active */
- layer->next_frm->state = VIDEOBUF_ACTIVE;
- addr = videobuf_to_dma_contig(layer->next_frm);
+ layer->next_frm->vb.state = VB2_BUF_STATE_ACTIVE;
+ addr = vb2_dma_contig_plane_dma_addr(&layer->next_frm->vb, 0);
osd_device->ops.start_layer(osd_device,
layer->layer_info.id,
addr,
@@ -199,39 +201,29 @@ static irqreturn_t venc_isr(int irq, void *arg)
/*
* vpbe_buffer_prepare()
- * This is the callback function called from videobuf_qbuf() function
+ * This is the callback function called from vb2_qbuf() function
* the buffer is prepared and user space virtual address is converted into
* physical address
*/
-static int vpbe_buffer_prepare(struct videobuf_queue *q,
- struct videobuf_buffer *vb,
- enum v4l2_field field)
+static int vpbe_buffer_prepare(struct vb2_buffer *vb)
{
- struct vpbe_fh *fh = q->priv_data;
+ struct vpbe_fh *fh = vb2_get_drv_priv(vb->vb2_queue);
+ struct vb2_queue *q = vb->vb2_queue;
struct vpbe_layer *layer = fh->layer;
struct vpbe_device *vpbe_dev = fh->disp_dev->vpbe_dev;
unsigned long addr;
- int ret;
v4l2_dbg(1, debug, &vpbe_dev->v4l2_dev,
"vpbe_buffer_prepare\n");
- /* If buffer is not initialized, initialize it */
- if (VIDEOBUF_NEEDS_INIT == vb->state) {
- vb->width = layer->pix_fmt.width;
- vb->height = layer->pix_fmt.height;
- vb->size = layer->pix_fmt.sizeimage;
- vb->field = field;
-
- ret = videobuf_iolock(q, vb, NULL);
- if (ret < 0) {
- v4l2_err(&vpbe_dev->v4l2_dev, "Failed to map \
- user address\n");
+ if (vb->state != VB2_BUF_STATE_ACTIVE &&
+ vb->state != VB2_BUF_STATE_PREPARED) {
+ vb2_set_plane_payload(vb, 0, layer
Re: [RFC 0/5] Generic panel framework
Hi Laurent. sorry for being late. 2012/8/17 Laurent Pinchart : > Hi everybody, > > While working on DT bindings for the Renesas Mobile SoC display controller > (a.k.a. LCDC) I quickly realized that display panel implementation based on > board code callbacks would need to be replaced by a driver-based panel > framework. > > Several driver-based panel support solution already exist in the kernel. > > - The LCD device class is implemented in drivers/video/backlight/lcd.c and > exposes a kernel API in include/linux/lcd.h. That API is tied to the FBDEV > API for historical reason, uses board code callback for reset and power > management, and doesn't include support for standard features available in > today's "smart panels". > > - OMAP2+ based systems use custom panel drivers available in > drivers/video/omap2/displays. Those drivers are based on OMAP DSS (display > controller) specific APIs. > > - Similarly, Exynos based systems use custom panel drivers available in > drivers/video/exynos. Only a single driver (s6e8ax0) is currently available. > That driver is based on Exynos display controller specific APIs and on the > LCD device class API. > > I've brought up the issue with Tomi Valkeinen (OMAP DSS maintainer) and Marcus > Lorentzon (working on panel support for ST/Linaro), and we agreed that a > generic panel framework for display devices is needed. These patches implement > a first proof of concept. > > One of the main reasons for creating a new panel framework instead of adding > missing features to the LCD framework is to avoid being tied to the FBDEV > framework. Panels will be used by DRM drivers as well, and their API should > thus be subsystem-agnostic. Note that the panel framework used the > fb_videomode structure in its API, this will be replaced by a common video > mode structure shared across subsystems (there's only so many hours per day). > > Panels, as used in these patches, are defined as physical devices combining a > matrix of pixels and a controller capable of driving that matrix. > > Panel physical devices are registered as children of the control bus the panel > controller is connected to (depending on the panel type, we can find platform > devices for dummy panels with no control bus, or I2C, SPI, DBI, DSI, ... > devices). The generic panel framework matches registered panel devices with > panel drivers and call the panel drivers probe method, as done by other device > classes in the kernel. The driver probe() method is responsible for > instantiating a struct panel instance and registering it with the generic > panel framework. > > Display drivers are panel consumers. They register a panel notifier with the > framework, which then calls the notifier when a matching panel is registered. > The reason for this asynchronous mode of operation, compared to how drivers > acquire regulator or clock resources, is that the panel can use resources > provided by the display driver. For instance a panel can be a child of the DBI > or DSI bus controlled by the display device, or use a clock provided by that > device. We can't defer the display device probe until the panel is registered > and also defer the panel device probe until the display is registered. As > most display drivers need to handle output devices hotplug (HDMI monitors for > instance), handling panel through a notification system seemed to be the > easiest solution. > > Note that this brings a different issue after registration, as display and > panel drivers would take a reference to each other. Those circular references > would make driver unloading impossible. I haven't found a good solution for > that problem yet (hence the RFC state of those patches), and I would > appreciate your input here. This might also be a hint that the framework > design is wrong to start with. I guess I can't get everything right on the > first try ;-) > > Getting hold of the panel is the most complex part. Once done, display drivers > can call abstract operations provided by panel drivers to control the panel > operation. These patches implement three of those operations (enable, start > transfer and get modes). More operations will be needed, and those three > operations will likely get modified during review. Most of the panels on > devices I own are dumb panels with no control bus, and are thus not the best > candidates to design a framework that needs to take complex panels' needs into > account. > > In addition to the generic panel core, I've implemented MIPI DBI (Display Bus > Interface, a parallel bus for panels that supports read/write transfers of > commands and data) bus support, as well as three panel drivers (dummy panels > with no control bus, and Renesas R61505- and R61517-based panels, both using > DBI as their control bus). Only the dummy panel driver has been tested as I > lack hardware for the two other drivers. > > I will appreciate all reviews, comments, criticisms, ideas, remarks, ... If > you can find a clev
Re: [Intel-gfx] GPU RC6 breaks PCIe to PCI bridge connected to CPU PCIe slot on SandyBridge systems
On Fri, 2012-10-19 at 18:06 +0100, Simon Farnsworth wrote: > On Friday 19 October 2012 17:10:17 Simon Farnsworth wrote: > > Mauro, Linux-Media > > > > I have an issue where an SAA7134-based TV capture card connected via a PCIe > > to > > PCI bridge chip works when the GPU is kept out of RC6 state, but sometimes > > "skips" updating lines of the capture when the GPU is in RC6. We've > > confirmed > > that a CX23418 based chip doesn't have the problem, so the question is > > whether > > the SAA7134 and the saa7134 driver are at fault, or whether it's the PCIe > > bus. My money's on the saa7134 driver's irq_handler or the driver's locking scheme to protect data accessed by both irq handler and userspace file operations (aka videobuf's locking) in the driver. It could also be a system level problem with another driver's irq handler being stupid. > > This manifests as a regression, as I had no problems with kernel 3.3 (which > > never enabled RC6 on the Intel GPU), but I do have problems with 3.5 and > > with > > current Linus git master. I'm happy to try anything, Profile the saa7134 driver in operation: http://www.spinics.net/lists/linux-media/msg15762.html That will give you and driver writers a clue as to where any big delays are hapeening in the saa7134 driver. Odds are the processor slowing down to a lower power/lower speed state is exposing inefficiencies in the irq handling of the saa7134 driver. > > I've attached lspci -vvx output (suitable for feeding to lspci -F) for > > when the corruption is present (lspci.faulty) and when it's not > > (lspci.working). Doing a diff between the two files and checking what devices have changed registers I noted that only 3 devices' PCI config space registers changed: 00:01.0 and 00:1c.1 (both PCIe ports/bridges) and 00:1a.0. $ lspci -F lspci.working -tv -[:00]-+-00.0 Intel Corporation 2nd Generation Core Processor Family DRAM Controller +-01.0-[01-02]00.0-[02]08.0 Philips Semiconductors SAA7131/SAA7133/SAA7135 Video Broadcast Decoder +-02.0 Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller +-16.0 Intel Corporation 6 Series/C200 Series Chipset Family MEI Controller #1 +-19.0 Intel Corporation 82579V Gigabit Network Connection +-1a.0 Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #2 +-1b.0 Intel Corporation 6 Series/C200 Series Chipset Family High Definition Audio Controller +-1c.0-[03]-- +-1c.1-[04]00.0 NEC Corporation uPD720200 USB 3.0 Host Controller +-1d.0 Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #1 +-1f.0 Intel Corporation H67 Express Chipset Family LPC Controller +-1f.2 Intel Corporation 6 Series/C200 Series Chipset Family 6 port SATA AHCI Controller \-1f.3 Intel Corporation 6 Series/C200 Series Chipset Family SMBus Controller Obviously the changes to the bridge at 00:01.0 might matter, but I would need to dig up the data sheet for the "00:01.0 PCI bridge [0604]: Intel Corporation Xeon E3-1200/2nd Generation Core Processor Family PCI Express Root Port [8086:0101] (rev 09) (prog-if 00 [Normal decode])" to see if it really mattered. > The speculation is that the SAA7134 is somehow more > > sensitive to the changes in timings that RC6 introduces than the CX23418, > > and > > that someone who understands the saa7134 driver might be able to make it > > less > > sensitive. I heavily optimized the cx18 driver for the high throughput use case (mutliple cards running multiple data streams), which meant squeezing every little bit of useless junk out of the irq handler and adding highly granular buffer queue locking between the irq handling and the userspace file operations calls. Also the CX23418 firmware has a "best effort" buffer notification handshake and the cx18 driver does some extra recovery processing to handle when it is late on handling buffer notifications. All that optimzation and robustness coding took me a few months to get right. I don't see that sort of optimization of the saa7134 driver coming anytime soon. Regards, Andy > And timings are definitely the problem; I have a userspace provided pm_qos > request asking for 0 exit latency, but I can see CPU cores entering C6. I'll > take this problem to an appropriate list. > > There is still be a bug in the SAA7134 driver, as the card clearly wants a > pm_qos request when streaming to stop the DMA latency becoming too high; this > doesn't directly affect me, as my userspace always requests minimal DMA > latency anyway, so consider this message as just closing down the thread for > now, and as a marker for the future (if people see such corruption, the > saa7134 driver needs a pm_qos request when streaming that isn't currently > present). -- To unsubscribe from this list: send the line "unsubscr
Re: [PATCH 0/2 v6] of: add display helper
On Mon, Oct 15, 2012 at 04:17:51PM +0200, Steffen Trumtrar wrote: > Hi Leela, > > On Mon, Oct 15, 2012 at 04:24:43PM +0530, Leela Krishna Amudala wrote: > > Hello Steffen, > > > > To which version of the kernel we can expect this patch set to be merged > > into? > > Because I'm waiting for this from long time to add DT support for my > > display controller :) > > > > I have no idea, sorry. It seems like we have almost settled with the binding > (clock-name needs to be changed), but I'm not responsible for any > merging/inclusions > in the kernel. I want to use this in the Tegra DRM driver which I hope to get into 3.8. If you need any help with this, please let me know. Thierry pgpwGLsCwp58x.pgp Description: PGP signature
Re: [PATCH 2/2 v6] of: add generic videomode description
On Thu, Oct 04, 2012 at 07:59:20PM +0200, Steffen Trumtrar wrote:
[...]
> diff --git a/drivers/of/of_videomode.c b/drivers/of/of_videomode.c
[...]
> +#if defined(CONFIG_DRM)
This should be:
#if IS_ENABLED(CONFIG_DRM)
or the code below won't be included if DRM is built as a module. But see
my other replies as to how we can probably handle this better by moving
this into the DRM subsystem.
> +int videomode_to_display_mode(struct videomode *vm, struct drm_display_mode
> *dmode)
> +{
> + memset(dmode, 0, sizeof(*dmode));
It appears the usual method to obtain a drm_display_mode to allocate it
using drm_mode_create(), which will allocate it and associate it with
the struct drm_device.
Now, if you do a memset() on the structure you'll overwrite a number of
fields that have previously been initialized and are actually required
to get everything cleaned up properly later on.
So I think we should remove the call to memset().
> +int of_get_fb_videomode(struct device_node *np, struct fb_videomode *fb,
> + int index)
> +{
[...]
> +}
> +EXPORT_SYMBOL_GPL(of_get_drm_display_mode);
This should be:
EXPORT_SYMBOL_GPL(of_get_fb_videomode);
Thierry
pgpXoG5cskkMX.pgp
Description: PGP signature
Re: [PATCH 1/2 v6] of: add helper to parse display timings
On Thu, Oct 04, 2012 at 07:59:19PM +0200, Steffen Trumtrar wrote: [...] > diff --git a/include/linux/of_display_timings.h > b/include/linux/of_display_timings.h > new file mode 100644 > index 000..1ad719e > --- /dev/null > +++ b/include/linux/of_display_timings.h > @@ -0,0 +1,85 @@ > +/* > + * Copyright 2012 Steffen Trumtrar > + * > + * description of display timings > + * > + * This file is released under the GPLv2 > + */ > + > +#ifndef __LINUX_OF_DISPLAY_TIMINGS_H > +#define __LINUX_OF_DISPLAY_TIMINGS_H This file needs to include linux/slab.h because it uses kfree() in the inline functions. Alternatively I think I'd rather see the inline functions moved out of the header, with the exception of the signal_timing_get_value() function perhaps. Moreover there should be a forward declaration of struct display_node to avoid the need to include linux/of.h. Thierry pgpgdeqMpeoZ4.pgp Description: PGP signature
Re: [PATCH 2/2 v6] of: add generic videomode description
On Tue, Oct 09, 2012 at 09:26:08AM +0200, Steffen Trumtrar wrote: > Hi Laurent, > > On Mon, Oct 08, 2012 at 10:52:04PM +0200, Laurent Pinchart wrote: > > Hi Steffen, > > > > On Monday 08 October 2012 14:48:01 Steffen Trumtrar wrote: > > > On Mon, Oct 08, 2012 at 02:13:50PM +0200, Laurent Pinchart wrote: > > > > On Thursday 04 October 2012 19:59:20 Steffen Trumtrar wrote: [...] > > > > > +int of_get_videomode(struct device_node *np, struct videomode *vm, > > > > > int > > > > > index) > > > > > > > > I wonder how to avoid abuse of this functions. It's a useful helper for > > > > drivers that need to get a video mode once only, but would result in > > > > lower > > > > performances if a driver calls it for every mode. Drivers must call > > > > of_get_display_timing_list instead in that case and case the display > > > > timings. I'm wondering whether we should really expose of_get_videomode. > > > > > > The intent was to let the driver decide. That way all the other overhead > > > may > > > be skipped. > > > > My point is that driver writers might just call of_get_videomode() in a > > loop, > > not knowing that it's expensive. I want to avoid that. We need to at least > > add > > kerneldoc to the function stating that this shouldn't be done. > > > > You're right. That should be made clear in the code. In that case we should export videomode_from_timing(). For Tegra DRM I wrote a small utility function that takes a struct display_timings and converts every timing to a struct videomode which is then converted to a struct drm_display_mode and added to the DRM connector. The code is really generic and could be part of the DRM core. Thierry pgpP1yScppums.pgp Description: PGP signature
Re: [PATCH 2/2 v6] of: add generic videomode description
On Sun, Oct 07, 2012 at 03:38:33PM +0200, Laurent Pinchart wrote:
> Hi Steffen,
>
> On Friday 05 October 2012 17:51:21 Steffen Trumtrar wrote:
> > On Thu, Oct 04, 2012 at 12:51:00PM -0600, Stephen Warren wrote:
> > > On 10/04/2012 11:59 AM, Steffen Trumtrar wrote:
> > > > Get videomode from devicetree in a format appropriate for the
> > > > backend. drm_display_mode and fb_videomode are supported atm.
> > > > Uses the display signal timings from of_display_timings
> > > >
> > > > +++ b/drivers/of/of_videomode.c
> > > >
> > > > +int videomode_from_timing(struct display_timings *disp, struct
> > > > videomode *vm,
> > > >
> > > > + st = display_timings_get(disp, index);
> > > > +
> > > > + if (!st) {
> > >
> > > It's a little odd to leave a blank line between those two lines.
> >
> > Hm, well okay. That can be remedied
> >
> > > Only half of the code in this file seems OF-related; the routines to
> > > convert a timing to a videomode or drm display mode seem like they'd be
> > > useful outside device tree, so I wonder if putting them into
> > > of_videomode.c is the correct thing to do. Still, it's probably not a
> > > big deal.
> >
> > I am not sure, what the appropriate way to do this is. I can split it up
> > (again).
>
> I think it would make sense to move them to their respective subsystems.
I agree. While looking at integrating this for Tegra DRM, I came across
the issue that if I build DRM as a module, linking with this code will
fail. The reason for that was that it was that the code, itself builtin,
uses drm_mode_set_name(), which would be exported by the drm module. So
I had to modifiy the Kconfig entries to be "def_tristate DRM". That
obviously isn't very nice since the code can also be used without DRM.
Moving the subsystem specific conversion routines to the respective
subsystems should solve any of these issues.
Thierry
pgplYOJeXMIaP.pgp
Description: PGP signature
Re: [PATCH] [media] s5p-tv: remove unused including
Hi, On 10/08/2012 02:32 PM, Wei Yongjun wrote: From: Wei Yongjun Remove including that don't need it. dpatch engine is used to auto generate this patch. (https://github.com/weiyj/dpatch) Sorry, I have already applied similar patch: http://patchwork.linuxtv.org/patch/15057 Thanks, Sylwester Signed-off-by: Wei Yongjun --- drivers/media/platform/s5p-tv/mixer_video.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/media/platform/s5p-tv/mixer_video.c b/drivers/media/platform/s5p-tv/mixer_video.c index 0c1cd89..9b52f3a 100644 --- a/drivers/media/platform/s5p-tv/mixer_video.c +++ b/drivers/media/platform/s5p-tv/mixer_video.c @@ -19,7 +19,6 @@ #include #include #include -#include #include #include -- 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
Re: [PATCH 1/1] [media] s5p-fimc: Fix potential NULL pointer dereference
Hi Sachin,
On 10/13/2012 01:41 PM, Sachin Kamat wrote:
'fimc' was being dereferenced before the NULL check.
Moved it to after the check.
Signed-off-by: Sachin Kamat
---
drivers/media/platform/s5p-fimc/fimc-mdevice.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/s5p-fimc/fimc-mdevice.c
b/drivers/media/platform/s5p-fimc/fimc-mdevice.c
index 80ada58..61fab00 100644
--- a/drivers/media/platform/s5p-fimc/fimc-mdevice.c
+++ b/drivers/media/platform/s5p-fimc/fimc-mdevice.c
@@ -343,7 +343,7 @@ static int fimc_md_register_sensor_entities(struct fimc_md
*fmd)
static int fimc_register_callback(struct device *dev, void *p)
{
struct fimc_dev *fimc = dev_get_drvdata(dev);
- struct v4l2_subdev *sd =&fimc->vid_cap.subdev;
+ struct v4l2_subdev *sd;
struct fimc_md *fmd = p;
int ret = 0;
@@ -353,6 +353,7 @@ static int fimc_register_callback(struct device *dev, void
*p)
if (fimc->pdev->id< 0 || fimc->pdev->id>= FIMC_MAX_DEVS)
return 0;
+ sd =&fimc->vid_cap.subdev;
fimc->pipeline_ops =&fimc_pipeline_ops;
fmd->fimc[fimc->pdev->id] = fimc;
sd->grp_id = FIMC_GROUP_ID;
@@ -369,7 +370,7 @@ static int fimc_register_callback(struct device *dev, void
*p)
static int fimc_lite_register_callback(struct device *dev, void *p)
{
struct fimc_lite *fimc = dev_get_drvdata(dev);
- struct v4l2_subdev *sd =&fimc->subdev;
+ struct v4l2_subdev *sd;
Thank you for the patch. May I ask you to remove sd instead and to
replace sd with fimc->subdev ? There are just two references of
sd below.
struct fimc_md *fmd = p;
int ret;
@@ -379,6 +380,7 @@ static int fimc_lite_register_callback(struct device *dev,
void *p)
if (fimc->index>= FIMC_LITE_MAX_DEVS)
return 0;
+ sd =&fimc->subdev;
fimc->pipeline_ops =&fimc_pipeline_ops;
fmd->fimc_lite[fimc->index] = fimc;
sd->grp_id = FLITE_GROUP_ID;
Thanks,
Sylwester
--
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
Re: [PATCH 1/1] [media] s5p-mfc: Fix compilation warning
On 10/13/2012 01:18 PM, Sachin Kamat wrote: Added missing const qualifier. Without this patch compiler gives the following warning: drivers/media/platform/s5p-mfc/s5p_mfc_enc.c:1576:2: warning: initialization from incompatible pointer type [enabled by default] drivers/media/platform/s5p-mfc/s5p_mfc_enc.c:1576:2: warning: (near initialization for ‘s5p_mfc_enc_ioctl_ops.vidioc_subscribe_event’) [enabled by default] Applied to my tree. Thank you. -- 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
Re: [PATCH] [media] exynos-gsc: change driver compatible string
Hi Shaik, On 10/16/2012 04:43 PM, Shaik Ameer Basha wrote: As G-Scaler is going to stay unchanged across all exynos5 series SoCs, changing the driver compatible string name to "samsung,exynos5-gsc" from "samsung,exynos5250-gsc". This change is as per the discussion in the devicetree forum. http://www.mail-archive.com/devicetree-discuss@lists.ozlabs.org/msg16448.html I have added this patch to my tree, together with: [PATCH] [media] exynos-gsc: fix variable type in gsc_m2m_device_run() [PATCH] [media] s5p-fimc: fix variable type in fimc_device_run() Thank you. -- Regards, Sylwester -- 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
Re: [PATCH] [media] s5p-tv: don't include linux/version.h in mixer_video.c
On 10/18/2012 09:28 PM, Jesper Juhl wrote: The header is not needed, so remove it. I have applied it to my tree, thanks! -- 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
Re: [PATCH 8/8] [media] s5p-fimc: Make 'fimc_pipeline_s_stream' function static
On 10/17/2012 01:11 PM, Sachin Kamat wrote: Fixes the following sparse warning: drivers/media/platform/s5p-fimc/fimc-mdevice.c:216:5: warning: symbol 'fimc_pipeline_s_stream' was not declared. Should it be static? Thanks Sachin, I've add it to my tree. -- 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
Re: [PATCH 7/8] [media] s5p-mfc: Make 'clk_ref' static in s5p_mfc_pm.c
On 10/17/2012 01:11 PM, Sachin Kamat wrote: Fixes the following sparse warning: drivers/media/platform/s5p-mfc/s5p_mfc_pm.c:31:10: warning: symbol 'clk_ref' was not declared. Should it be static? Applied, thanks. -- 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
Re: [PATCH 6/8] [media] exynos-gsc: Fix compilation warning
On 10/17/2012 01:11 PM, Sachin Kamat wrote: Used type casting to avoid the following compilation warning: drivers/media/platform/exynos-gsc/gsc-core.c:983:37: warning: incorrect type in assignment (different modifiers) drivers/media/platform/exynos-gsc/gsc-core.c:983:37: expected struct gsc_driverdata *driver_data drivers/media/platform/exynos-gsc/gsc-core.c:983:37: got void const *data Applied to my tree, thanks. -- 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
Re: [PATCH 5/8] [media] exynos-gsc: Use clk_prepare_enable and clk_disable_unprepare
On 10/17/2012 01:11 PM, Sachin Kamat wrote:
> Replace clk_enable/clk_disable with clk_prepare_enable/clk_disable_unprepare
> as required by the common clock framework.
>
> Signed-off-by: Sachin Kamat
> ---
> drivers/media/platform/exynos-gsc/gsc-core.c |4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c
> b/drivers/media/platform/exynos-gsc/gsc-core.c
> index bfec9e6..d11668b 100644
> --- a/drivers/media/platform/exynos-gsc/gsc-core.c
> +++ b/drivers/media/platform/exynos-gsc/gsc-core.c
> @@ -1009,7 +1009,7 @@ static int gsc_clk_get(struct gsc_dev *gsc)
> if (IS_ERR(gsc->clock))
> goto err_print;
>
> - ret = clk_prepare(gsc->clock);
> + ret = clk_prepare_enable(gsc->clock);
This is not right, gsc->clock is being enabled somewhere else.
And as you can see this driver has already taken care of preparing/
unpreparing the clock.
> if (ret< 0) {
> clk_put(gsc->clock);
> gsc->clock = NULL;
> @@ -1186,7 +1186,7 @@ static int gsc_runtime_suspend(struct device *dev)
>
> ret = gsc_m2m_suspend(gsc);
> if (!ret)
> - clk_disable(gsc->clock);
> + clk_disable_unprepare(gsc->clock);
No, that will result in unbalanced clk_prepare/unprepare. Please
don't do that.
>
> pr_debug("gsc%d: state: 0x%lx", gsc->id, gsc->state);
> return ret;
This driver should already inter-work fine with the common clock
framework, just look how it handles the clock:
# git grep -n -7 clk_ -- exynos-gsc
exynos-gsc/gsc-core.c:993:static void gsc_clk_put(struct gsc_dev *gsc)
exynos-gsc/gsc-core.c-994-{
exynos-gsc/gsc-core.c-995- if (IS_ERR_OR_NULL(gsc->clock))
exynos-gsc/gsc-core.c-996- return;
exynos-gsc/gsc-core.c-997-
exynos-gsc/gsc-core.c:998: clk_unprepare(gsc->clock);
exynos-gsc/gsc-core.c:999: clk_put(gsc->clock);
exynos-gsc/gsc-core.c-1000- gsc->clock = NULL;
exynos-gsc/gsc-core.c-1001-}
exynos-gsc/gsc-core.c-1002-
exynos-gsc/gsc-core.c:1003:static int gsc_clk_get(struct gsc_dev *gsc)
exynos-gsc/gsc-core.c-1004-{
exynos-gsc/gsc-core.c-1005- int ret;
exynos-gsc/gsc-core.c-1006-
exynos-gsc/gsc-core.c:1007: dev_dbg(&gsc->pdev->dev, "gsc_clk_get
Called\n");
exynos-gsc/gsc-core.c-1008-
exynos-gsc/gsc-core.c:1009: gsc->clock = clk_get(&gsc->pdev->dev,
GSC_CLOCK_GATE_NAME);
exynos-gsc/gsc-core.c-1010- if (IS_ERR(gsc->clock))
exynos-gsc/gsc-core.c-1011- goto err_print;
exynos-gsc/gsc-core.c-1012-
exynos-gsc/gsc-core.c:1013: ret = clk_prepare(gsc->clock);
exynos-gsc/gsc-core.c-1014- if (ret < 0) {
exynos-gsc/gsc-core.c:1015: clk_put(gsc->clock);
exynos-gsc/gsc-core.c-1016- gsc->clock = NULL;
exynos-gsc/gsc-core.c-1017- goto err;
exynos-gsc/gsc-core.c-1018- }
exynos-gsc/gsc-core.c-1019-
exynos-gsc/gsc-core.c-1020- return 0;
exynos-gsc/gsc-core.c-1021-
exynos-gsc/gsc-core.c-1022-err:
exynos-gsc/gsc-core.c-1023- dev_err(&gsc->pdev->dev, "clock prepare failed
for clock: %s\n",
exynos-gsc/gsc-core.c-1024-
GSC_CLOCK_GATE_NAME);
exynos-gsc/gsc-core.c:1025: gsc_clk_put(gsc);
exynos-gsc/gsc-core.c-1026-err_print:
exynos-gsc/gsc-core.c-1027- dev_err(&gsc->pdev->dev, "failed to get
clock~~~: %s\n",
exynos-gsc/gsc-core.c-1028-
GSC_CLOCK_GATE_NAME);
exynos-gsc/gsc-core.c-1029- return -ENXIO;
exynos-gsc/gsc-core.c-1030-}
--
exynos-gsc/gsc-core.c-1105-
exynos-gsc/gsc-core.c-1106- res = platform_get_resource(pdev,
IORESOURCE_IRQ, 0);
exynos-gsc/gsc-core.c-1107- if (!res) {
exynos-gsc/gsc-core.c-1108- dev_err(dev, "failed to get IRQ
resource\n");
exynos-gsc/gsc-core.c-1109- return -ENXIO;
exynos-gsc/gsc-core.c-1110- }
exynos-gsc/gsc-core.c--
exynos-gsc/gsc-core.c:1112: ret = gsc_clk_get(gsc);
exynos-gsc/gsc-core.c-1113- if (ret)
exynos-gsc/gsc-core.c-1114- return ret;
--
exynos-gsc/gsc-core.c-1142- pm_runtime_put(dev);
exynos-gsc/gsc-core.c-1143- return 0;
exynos-gsc/gsc-core.c-1144-err_pm:
exynos-gsc/gsc-core.c-1145- pm_runtime_put(dev);
exynos-gsc/gsc-core.c-1146-err_m2m:
exynos-gsc/gsc-core.c-1147- gsc_unregister_m2m_device(gsc);
exynos-gsc/gsc-core.c-1148-err_clk:
exynos-gsc/gsc-core.c:1149: gsc_clk_put(gsc);
exynos-gsc/gsc-core.c-1150- return ret;
exynos-gsc/gsc-core.c-1151-}
--
exynos-gsc/gsc-core.c-1166-static int gsc_runtime_resume(struct device *dev)
exynos-gsc/gsc-core.c-1167-{
exynos-gsc/gsc-core.c-1168- struct gsc_dev *gsc = dev_get_drvdata(dev);
exynos-gsc/gsc-core.c-1169- int ret = 0;
exynos-gsc/gsc-core.c-1170-
exynos-gsc/gsc-core.c-1171- pr_debug("gsc%d: state: 0x%lx", gsc->id,
gsc->state);
exynos-gsc/gsc-core.c-1172-
exynos-gsc/gsc-core.c:1173: ret = clk_enable(gsc->clock);
exynos-gsc/gsc-core.c-1174- if (ret)
exynos-gsc/gsc-core.c-1175-
Re: [PATCH 4/8] [media] s5p-tv: Use clk_prepare_enable and clk_disable_unprepare
On 10/17/2012 01:11 PM, Sachin Kamat wrote: > Replace clk_enable/clk_disable with clk_prepare_enable/clk_disable_unprepare > as required by the common clock framework. > > Signed-off-by: Sachin Kamat > Cc: Tomasz Stanislawski Could you add clocks (un)prepare calls at the functions where the clocks are acquired/released instead ? I think it results in slightly less overhead this way. -- Thanks, Sylwester -- 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
Re: [PATCH 3/8] [media] s5p-mfc: Use clk_prepare_enable and clk_disable_unprepare
On 10/17/2012 01:11 PM, Sachin Kamat wrote: > Replace clk_enable/clk_disable with clk_prepare_enable/clk_disable_unprepare > as required by the common clock framework. Similarly as in case of s5p-g2d driver, there is no need for this change. -- 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
Re: [PATCH 3/8] [media] s5p-mfc: Use clk_prepare_enable and clk_disable_unprepare
On 10/17/2012 01:11 PM, Sachin Kamat wrote: > Replace clk_enable/clk_disable with clk_prepare_enable/clk_disable_unprepare > as required by the common clock framework. Similarly as in case of s5p-g2d driver, there is no need for this change. -- 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
Re: [PATCH 2/8] [media] s5p-g2d: Use clk_prepare_enable and clk_disable_unprepare
Hi Sachin, On 10/17/2012 01:11 PM, Sachin Kamat wrote: > Replace clk_enable/clk_disable with clk_prepare_enable/clk_disable_unprepare > as required by the common clock framework. > > Signed-off-by: Sachin Kamat > Cc: Kamil Debski As we discussed previously, this patch is not needed. clk_prepare/unprepare are done in this driver's probe() and remove() callbacks. Thanks, Sylwester -- 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
[PATCH] media: davinci: vpbe: fix build warning
From: Lad, Prabhakar
Warnings were generated because of the following commit changed data type for
address pointer
195bbca ARM: 7500/1: io: avoid writeback addressing modes for __raw_ accessors
add __iomem annotation to fix following warnings
drivers/media/platform/davinci/vpbe_osd.c: In function ‘osd_read’:
drivers/media/platform/davinci/vpbe_osd.c:49:2: warning: passing
argument 1 of ‘__raw_readl’ makes pointer from integer without a cast [enabled
by default]
arch/arm/include/asm/io.h:104:19: note: expected ‘const volatile
void *’ but argument is of type ‘long unsigned int’
Signed-off-by: Lad, Prabhakar
Signed-off-by: Manjunath Hadli
---
drivers/media/platform/davinci/vpbe_osd.c | 16
1 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/media/platform/davinci/vpbe_osd.c
b/drivers/media/platform/davinci/vpbe_osd.c
index bba299d..9ab9280 100644
--- a/drivers/media/platform/davinci/vpbe_osd.c
+++ b/drivers/media/platform/davinci/vpbe_osd.c
@@ -46,14 +46,14 @@ static inline u32 osd_read(struct osd_state *sd, u32 offset)
{
struct osd_state *osd = sd;
- return readl(osd->osd_base + offset);
+ return readl(IOMEM(osd->osd_base + offset));
}
static inline u32 osd_write(struct osd_state *sd, u32 val, u32 offset)
{
struct osd_state *osd = sd;
- writel(val, osd->osd_base + offset);
+ writel(val, IOMEM(osd->osd_base + offset));
return val;
}
@@ -63,9 +63,9 @@ static inline u32 osd_set(struct osd_state *sd, u32 mask, u32
offset)
struct osd_state *osd = sd;
u32 addr = osd->osd_base + offset;
- u32 val = readl(addr) | mask;
+ u32 val = readl(IOMEM(addr)) | mask;
- writel(val, addr);
+ writel(val, IOMEM(addr));
return val;
}
@@ -75,9 +75,9 @@ static inline u32 osd_clear(struct osd_state *sd, u32 mask,
u32 offset)
struct osd_state *osd = sd;
u32 addr = osd->osd_base + offset;
- u32 val = readl(addr) & ~mask;
+ u32 val = readl(IOMEM(addr)) & ~mask;
- writel(val, addr);
+ writel(val, IOMEM(addr));
return val;
}
@@ -88,9 +88,9 @@ static inline u32 osd_modify(struct osd_state *sd, u32 mask,
u32 val,
struct osd_state *osd = sd;
u32 addr = osd->osd_base + offset;
- u32 new_val = (readl(addr) & ~mask) | (val & mask);
+ u32 new_val = (readl(IOMEM(addr)) & ~mask) | (val & mask);
- writel(new_val, addr);
+ writel(new_val, IOMEM(addr));
return new_val;
}
--
1.7.4.1
--
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
