[PATCH 18/60] media: remove the second argument of k[un]map_atomic()
Acked-by: Andy Walls Signed-off-by: Cong Wang --- drivers/media/video/ivtv/ivtv-udma.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/media/video/ivtv/ivtv-udma.c b/drivers/media/video/ivtv/ivtv-udma.c index 69cc816..7338cb2 100644 --- a/drivers/media/video/ivtv/ivtv-udma.c +++ b/drivers/media/video/ivtv/ivtv-udma.c @@ -57,9 +57,9 @@ int ivtv_udma_fill_sg_list (struct ivtv_user_dma *dma, struct ivtv_dma_page_info if (dma->bouncemap[map_offset] == NULL) return -1; local_irq_save(flags); - src = kmap_atomic(dma->map[map_offset], KM_BOUNCE_READ) + offset; + src = kmap_atomic(dma->map[map_offset]) + offset; memcpy(page_address(dma->bouncemap[map_offset]) + offset, src, len); - kunmap_atomic(src, KM_BOUNCE_READ); + kunmap_atomic(src); local_irq_restore(flags); sg_set_page(&dma->SGlist[map_offset], dma->bouncemap[map_offset], len, offset); } -- 1.7.7.6 -- 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: [Q] Interleaved formats on the media bus
Hi Sylwester, On Wednesday 08 February 2012 23:48:27 Sylwester Nawrocki wrote: > On 02/05/2012 02:30 PM, Laurent Pinchart wrote: > > On Saturday 04 February 2012 18:00:10 Sylwester Nawrocki wrote: > >> On 02/04/2012 12:34 PM, Laurent Pinchart wrote: > >>> On Thursday 02 February 2012 12:14:08 Sylwester Nawrocki wrote: > On 02/02/2012 10:55 AM, Laurent Pinchart wrote: > > Do all those sensors interleave the data in the same way ? This sounds > > quite > > No, each one uses it's own interleaving method. > > > hackish and vendor-specific to me, I'm not sure if we should try to > > generalize that. Maybe vendor-specific media bus format codes would be > > the way to go. I don't expect ISPs to understand the format, they will > > likely be configured in pass-through mode. Instead of adding explicit > > support for all those weird formats to all ISP drivers, it might make > > sense to add a "binary blob" media bus code to be used by the ISP. > > This could work, except that there is no way to match a fourcc with > media > bus code. Different fourcc would map to same media bus code, making it > impossible for the brigde to handle multiple sensors or one sensor > supporting multiple interleaved formats. Moreover there is a need to > map > media bus code to the MIPI-CSI data ID. What if one sensor sends > "binary" > blob with MIPI-CSI "User Define Data 1" and the other with "User Define > Data 2" ? > >>> > >>> My gut feeling is that the information should be retrieved from the > >>> sensor > >>> driver. This is all pretty vendor-specific, and adding explicit support > >>> for such sensors to each bridge driver wouldn't be very clean. Could the > >>> bridge > >> > >> We have many standard pixel codes in include/linux/v4l2-mediabus.h, yet > >> each bridge driver supports only a subset of them. I wouldn't expect a > >> sudden need for all existing bridge drivers to support some strange > >> interleaved image formats. > > > > Those media bus codes are standard, so implementing explicit support for > > them in bridge drivers is fine with me. What I want to avoid is adding > > explicit support for sensor-specific formats to bridges. There should be > > no dependency between the bridge and the sensor. > > OK, I see your point. Naturally I agree here, even though sometimes the > hardware engineers make this process of getting rid of the dependencies > more painful that it really could be. Obviously if an ISP has been designed to use specific features of a given sensor from the same manufacturer, implementing explicit support for those sensor-specific features in the ISP driver is fine. > >>> query the sensor using a subdev operation ? > >> > >> There is also a MIPI-CSI2 receiver in between that needs to be > >> configured. > >> I.e. it must know that it processes the User Defined Data 1, which > >> implies > >> certain pixel alignment, etc. So far a media bus pixel codes have been > >> a base information to handle such things. > > > > For CSI user-defined data types, I still think that the information > > required to configure the CSI receiver should come from the sensor. Only > > the sensor knows what user-defined data type it will generate. > > I agree. Should we have separate callback at the sensor ops for this or > should it belong to a bigger data structure (like the "frame description" > structure mentioned before) ? The latter might be more reasonable. I'd vote for a data structure, as one operation per value will result in too many operations. Maybe somewhere in the mbus config structure ? > Maybe we could create e.g. V4L2_MBUS_FMT_USER?, for each MIPI-CSI User > Defined data identifier, but as I remember it was decided not to map > MIPI-CSI data codes directly onto media bus pixel codes. > >>> > >>> Would setting the format directly on the sensor subdev be an option ? > >> > >> Do you mean setting a MIPI-CSI2 format ? > > > > No, I mean setting the media bus code on the sensor output pad to a > > vendor-specific value. > > I'm afraid we need a vendor/sensor specific format identifier since the > sensor produces truly vendor specific format. In fact this format is made > to overcome hardware limitations of the video bridge. We can of course > standardize things like: embedded (non-image) data presence and size at > beginning and an end of frame, MIPI-CSIS2 data type, interleaving method > (different data type and/or virtual channel), etc. But still there will be > some crap that is relevant to only one hardware type and it would need to > be distinguished in some way. Sure. We can have a sensor-specific media bus code. What I'd like to avoid is to propagate that code through the whole pipeline and adding explicit support for it to all bridge drivers. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of
Re: omap3isp: sequence number in v4l2 buffer not incremented
Hi Kruno,
On Wednesday 25 January 2012 16:34:26 Kruno Mrak wrote:
> Hello,
>
> we have an omap based intelligent camera and image sensor is connected to
> camera parallel interface. Image capturing via "CCDC output" works fine.
> When streaming is on and reading "sequence" variable, it shows always -1.
> Looking at kernel-source ispvideo.c, i found following if-else statement:
>
> /* Do frame number propagation only if this is the output video node.
> * Frame number either comes from the CSI receivers or it gets
> * incremented here if H3A is not active.
> * Note: There is no guarantee that the output buffer will finish
> * first, so the input number might lag behind by 1 in some cases.
> */
> if (video == pipe->output && !pipe->do_propagation)
> buf->vbuf.sequence = atomic_inc_return(&pipe->frame_number);
> else
> buf->vbuf.sequence = atomic_read(&pipe->frame_number);
>
> When i change to
> if (video == pipe->output && pipe->do_propagation)
> ...
> the sequence variable is incremented.
>
> So my question:
> Could it be that "pipe->do_propagation" should be tested on true and not on
> false?
No, the code is correct here. When do_propagation is true, the pipeline's
frame number is incremented in the frame start interrupt handler. This allows
synchronization of buffer sequence numbers with the statistics engine frame
counts.
> If this change is wrong, how can i achieve that the sequence number is
> incremented?
The driver increments the frame number in the CCP2 and CSI2 receivers
interrupt handlers. The frame number will thus not be incremented when using
the CCDC parallel input, which is wrong.
Does the following patch fix your problem ? I haven't been able to test it
yet with the CCP2 and CSI2 receivers, I might ask you to test a second
version. Sakari, could you test the patch on the N900 with the CCP2 receiver ?
I'm currently travelling and haven't brought mine with me.
>From c0d23bfa38fc91f33f39bab9328eda3a4481f152 Mon Sep 17 00:00:00 2001
From: Laurent Pinchart
Date: Thu, 9 Feb 2012 17:00:45 +0100
Subject: [PATCH] omap3isp: Fix frame number propagation
When propagating the frame number through the pipeline, the frame number
must be incremented at frame start by the appropriate IRQ handler. This
was properly handled for the CSI2 and CCP2 receivers, but not when the
CCDC parallel interface is used.
ADD frame number incrementation to the HS/VS interrupt handler. As the
HS/VS interrupt is also generated for frames received by the CSI2 and
CCP2 receivers, remove explicit propagation handling from the serial
receivers.
Reported-by: Kruno Mrak
Signed-off-by: Laurent Pinchart
---
drivers/media/video/omap3isp/isp.c |8
drivers/media/video/omap3isp/ispccdc.c |3 +++
drivers/media/video/omap3isp/ispccp2.c | 22 --
drivers/media/video/omap3isp/ispcsi2.c | 19 +++
drivers/media/video/omap3isp/ispcsi2.h |1 -
5 files changed, 6 insertions(+), 47 deletions(-)
diff --git a/drivers/media/video/omap3isp/isp.c
b/drivers/media/video/omap3isp/isp.c
index 06afbc1..df6416c 100644
--- a/drivers/media/video/omap3isp/isp.c
+++ b/drivers/media/video/omap3isp/isp.c
@@ -785,14 +785,6 @@ static int isp_pipeline_enable(struct isp_pipeline *pipe,
}
}
- /* Frame number propagation. In continuous streaming mode the number
-* is incremented in the frame start ISR. In mem-to-mem mode
-* singleshot is used and frame start IRQs are not available.
-* Thus we have to increment the number here.
-*/
- if (pipe->do_propagation && mode == ISP_PIPELINE_STREAM_SINGLESHOT)
- atomic_inc(&pipe->frame_number);
-
return 0;
}
diff --git a/drivers/media/video/omap3isp/ispccdc.c
b/drivers/media/video/omap3isp/ispccdc.c
index eaabc27..8d8d6f3 100644
--- a/drivers/media/video/omap3isp/ispccdc.c
+++ b/drivers/media/video/omap3isp/ispccdc.c
@@ -1410,6 +1410,9 @@ static void ccdc_hs_vs_isr(struct isp_ccdc_device *ccdc)
struct video_device *vdev = ccdc->subdev.devnode;
struct v4l2_event event;
+ /* Frame number propagation */
+ atomic_inc(&pipe->frame_number);
+
memset(&event, 0, sizeof(event));
event.type = V4L2_EVENT_FRAME_SYNC;
event.u.frame_sync.frame_sequence = atomic_read(&pipe->frame_number);
diff --git a/drivers/media/video/omap3isp/ispccp2.c
b/drivers/media/video/omap3isp/ispccp2.c
index 70ddbf3..84014b9 100644
--- a/drivers/media/video/omap3isp/ispccp2.c
+++ b/drivers/media/video/omap3isp/ispccp2.c
@@ -178,19 +178,6 @@ static void ccp2_if_enable(struct isp_ccp2_device *ccp2,
u8 enable)
ISPCCP2_CTRL_MODE | ISPCCP2_CTRL_IF_EN,
enable ? (ISPCCP2_CTRL_MODE | ISPCCP2_CTRL_IF_EN) : 0);
- /* For frame count propagation */
- if (pipe->do_propagation) {
- /* We may want the Frame Start IRQ from LC0 */
- if (enable)
-
Re: [PATCH v2 27/31] omap3isp: Configure CSI-2 phy based on platform data
Hi Sakari,
On Thu, Feb 2, 2012 at 5:54 PM, Sakari Ailus wrote:
> Configure CSI-2 phy based on platform data in the ISP driver. For that, the
> new V4L2_CID_IMAGE_SOURCE_PIXEL_RATE control is used. Previously the same
> was configured from the board code.
>
> Signed-off-by: Sakari Ailus
> ---
> drivers/media/video/omap3isp/ispcsi2.c | 10 +++-
> drivers/media/video/omap3isp/ispcsiphy.c | 78
> ++
> drivers/media/video/omap3isp/ispcsiphy.h | 2 +
> 3 files changed, 78 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/media/video/omap3isp/ispcsi2.c
> b/drivers/media/video/omap3isp/ispcsi2.c
> index 9313f7c..e2e3d63 100644
> --- a/drivers/media/video/omap3isp/ispcsi2.c
> +++ b/drivers/media/video/omap3isp/ispcsi2.c
> @@ -1068,7 +1068,13 @@ static int csi2_set_stream(struct v4l2_subdev *sd, int
> enable)
> struct isp_video *video_out = &csi2->video_out;
>
> switch (enable) {
> - case ISP_PIPELINE_STREAM_CONTINUOUS:
> + case ISP_PIPELINE_STREAM_CONTINUOUS: {
> + int ret;
> +
> + ret = omap3isp_csiphy_config(isp, sd);
> + if (ret < 0)
> + return ret;
> +
> if (omap3isp_csiphy_acquire(csi2->phy) < 0)
> return -ENODEV;
> csi2->use_fs_irq = pipe->do_propagation;
> @@ -1092,7 +1098,7 @@ static int csi2_set_stream(struct v4l2_subdev *sd, int
> enable)
> csi2_if_enable(isp, csi2, 1);
> isp_video_dmaqueue_flags_clr(video_out);
> break;
> -
> + }
> case ISP_PIPELINE_STREAM_STOPPED:
> if (csi2->state == ISP_PIPELINE_STREAM_STOPPED)
> return 0;
> diff --git a/drivers/media/video/omap3isp/ispcsiphy.c
> b/drivers/media/video/omap3isp/ispcsiphy.c
> index 5be37ce..5d7a6ab 100644
> --- a/drivers/media/video/omap3isp/ispcsiphy.c
> +++ b/drivers/media/video/omap3isp/ispcsiphy.c
> @@ -28,6 +28,8 @@
> #include
> #include
>
> +#include "../../../../arch/arm/mach-omap2/control.h"
> +
> #include "isp.h"
> #include "ispreg.h"
> #include "ispcsiphy.h"
> @@ -138,15 +140,73 @@ static void csiphy_dphy_config(struct isp_csiphy *phy)
> isp_reg_writel(phy->isp, reg, phy->phy_regs, ISPCSIPHY_REG1);
> }
>
> -static int csiphy_config(struct isp_csiphy *phy,
> - struct isp_csiphy_dphy_cfg *dphy,
> - struct isp_csiphy_lanes_cfg *lanes)
> +/*
> + * TCLK values are OK at their reset values
> + */
> +#define TCLK_TERM 0
> +#define TCLK_MISS 1
> +#define TCLK_SETTLE 14
> +
> +int omap3isp_csiphy_config(struct isp_device *isp,
> + struct v4l2_subdev *csi2_subdev)
> {
> + struct isp_csi2_device *csi2 = v4l2_get_subdevdata(csi2_subdev);
> + struct isp_pipeline *pipe = to_isp_pipeline(&csi2_subdev->entity);
> + struct isp_v4l2_subdevs_group *subdevs = pipe->external->host_priv;
> + struct isp_csiphy_dphy_cfg csi2phy;
> + int csi2_ddrclk_khz;
> + struct isp_csiphy_lanes_cfg *lanes;
> unsigned int used_lanes = 0;
> unsigned int i;
>
> + if (subdevs->interface == ISP_INTERFACE_CCP2B_PHY1
> + || subdevs->interface == ISP_INTERFACE_CCP2B_PHY2)
> + lanes = &subdevs->bus.ccp2.lanecfg;
> + else
> + lanes = &subdevs->bus.csi2.lanecfg;
> +
> + /* FIXME: Do 34xx / 35xx require something here? */
> + if (cpu_is_omap3630()) {
> + u32 cam_phy_ctrl = omap_readl(
> + OMAP343X_CTRL_BASE +
> OMAP3630_CONTROL_CAMERA_PHY_CTRL);
How about:
u32 cam_phy_ctrl =
omap_ctrl_readl(OMAP3630_CONTROL_CAMERA_PHY_CTRL);
?
> +
> + /*
> + * SCM.CONTROL_CAMERA_PHY_CTRL
> + * - bit[4] : CSIPHY1 data sent to CSIB
> + * - bit [3:2] : CSIPHY1 config: 00 d-phy, 01/10 ccp2
> + * - bit [1:0] : CSIPHY2 config: 00 d-phy, 01/10 ccp2
> + */
> + if (subdevs->interface == ISP_INTERFACE_CCP2B_PHY1)
> + cam_phy_ctrl |= 1 << 2;
> + else if (subdevs->interface == ISP_INTERFACE_CSI2C_PHY1)
> + cam_phy_ctrl &= 1 << 2;
Shouldn't this be:
cam_phy_ctrl &= ~(1 << 2);
?
> +
> + if (subdevs->interface == ISP_INTERFACE_CCP2B_PHY2)
> + cam_phy_ctrl |= 1;
> + else if (subdevs->interface == ISP_INTERFACE_CSI2A_PHY2)
> + cam_phy_ctrl &= 1;
... and:
cam_phy_ctrl &= ~1;
> +
> + omap_writel(cam_phy_ctrl,
> + OMAP343X_CTRL_BASE
> + + OMAP3630_CONTROL_CAMERA_PHY_CTRL);
Again:
omap_ctrl_writel(cam_phy_ctrl,
OMAP3630_CONTROL_CAMERA_PHY_CTRL);
> + }
> +
> + csi2_ddrclk_khz = pipe->external_rate / 1000
>
Re: [PATCH] tm6000: Don't use pointer after freeing it in tm6000_ir_fini()
On Mon, 6 Feb 2012, Thierry Reding wrote: > * Jesper Juhl wrote: > > In tm6000_ir_fini() there seems to be a problem. > > rc_unregister_device(ir->rc); calls rc_free_device() on the pointer it is > > given, which frees it. > > > > Subsequently the function does: > > > > if (!ir->polling) > > __tm6000_ir_int_stop(ir->rc); > > > > and __tm6000_ir_int_stop() dereferences the pointer it is given, which > > has already been freed. > > > > and it also does: > > > > tm6000_ir_stop(ir->rc); > > > > which also dereferences the (already freed) pointer. > > > > So, it seems that the call to rc_unregister_device() should be move > > below the calls to __tm6000_ir_int_stop() and tm6000_ir_stop(), so > > those don't operate on a already freed pointer. > > > > But, I must admit that I don't know this code *at all*, so someone who > > knows the code should take a careful look before applying this > > patch. It is based purely on inspection of facts of what is beeing > > freed where and not at all on understanding what the code does or why. > > I don't even have a means to test it, so beyond testing that the > > change compiles it has seen no testing what-so-ever. > > > > Anyway, here's a proposed patch. > > > > Signed-off-by: Jesper Juhl > > --- > > drivers/media/video/tm6000/tm6000-input.c |3 +-- > > 1 files changed, 1 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/media/video/tm6000/tm6000-input.c > > b/drivers/media/video/tm6000/tm6000-input.c > > index 7844607..859eb90 100644 > > --- a/drivers/media/video/tm6000/tm6000-input.c > > +++ b/drivers/media/video/tm6000/tm6000-input.c > > @@ -481,8 +481,6 @@ int tm6000_ir_fini(struct tm6000_core *dev) > > > > dprintk(2, "%s\n",__func__); > > > > - rc_unregister_device(ir->rc); > > - > > if (!ir->polling) > > __tm6000_ir_int_stop(ir->rc); > > > > @@ -492,6 +490,7 @@ int tm6000_ir_fini(struct tm6000_core *dev) > > tm6000_flash_led(dev, 0); > > ir->pwled = 0; > > > > + rc_unregister_device(ir->rc); > > > > kfree(ir); > > dev->ir = NULL; > > -- > > 1.7.8.4 > > Reviewed-by: Thierry Reding > Thanks :-) -- Jesper Juhlhttp://www.chaosbits.net/ Don't top-post http://www.catb.org/jargon/html/T/top-post.html Plain text mails only, please. -- 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: [alsa-devel] tea575x-tuner improvements & use in maxiradio
On Wednesday 08 February 2012 08:29:25 Hans Verkuil wrote:
> On Tuesday, February 07, 2012 23:20:19 Ondrej Zary wrote:
> > On Sunday 05 February 2012 14:17:05 Hans Verkuil wrote:
> > > These patches improve the tea575x-tuner module to make it up to date
> > > with the latest V4L2 frameworks.
> > >
> > > The maxiradio driver has also been converted to use the tea575x-tuner
> > > and I've used that card to test it.
> > >
> > > Unfortunately, this card can't read the data pin, so the new hardware
> > > seek functionality has been tested only partially (yes, it seeks, but
> > > when it finds a channel I can't read back the frequency).
> > >
> > > Ondrej, are you able to test these patches for the sound cards that use
> > > this tea575x tuner?
> > >
> > > Note that these two patches rely on other work that I did and that
> > > hasn't been merged yet. So it is best to pull from my git tree:
> > >
> > > http://git.linuxtv.org/hverkuil/media_tree.git/shortlog/refs/heads/radi
> > >o-pc i2
> > >
> > > You can use the v4l-utils repository
> > > (http://git.linuxtv.org/v4l-utils.git) to test the drivers: the
> > > v4l2-compliance test should succeed and with v4l2-ctl you can test the
> > > hardware seek:
> > >
> > > To seek down:
> > >
> > > v4l2-ctl -d /dev/radio0 --freq-seek=dir=0
> > >
> > > To seek up:
> > >
> > > v4l2-ctl -d /dev/radio0 --freq-seek=dir=1
> > >
> > > To do the compliance test:
> > >
> > > v4l2-compliance -r /dev/radio0
> >
> > It seems to work (tested with SF64-PCR - snd_fm801) but the seek is
> > severely broken. Reading the frequency immediately after seek does not
> > work, it always returns the old value (haven't found a delay that works).
> > Reading it later (copied back snd_tea575x_get_freq function) works. The
> > chip seeks randomly up or down, ignoring UP/DOWN flag and often stops at
> > wrong place (only noise) or even outside the FM range.
> >
> > So I strongly suggest not to enable this (mis-)feature. The HW seems to
> > be completely broken (unless there's some weird bug in the code).
>
> Well, it seemed like a good idea at the time :-) I'll remove this
> 'feature', it's really not worth our time to try and make this work for
> these old cards.
I fixed it somehow. Now it works most of the time.
The important things:
- a delay must be present after search start and before first register read
or the seek does weird things
- when the search stops, the new frequency is not available immediately, we
must wait until it appears in the register (fortunately, we can clear the
frequency bits when starting the search as it starts at the frequency
currently set, not from the value written)
- sometimes, seek remains on the current frequency (or moves only a little),
so repeat it until it moves by at least 50 kHz
--- a/sound/i2c/other/tea575x-tuner.c
+++ b/sound/i2c/other/tea575x-tuner.c
@@ -89,7 +89,7 @@ static void snd_tea575x_write(struct snd_tea575x *tea,
unsigned int val)
tea->ops->set_pins(tea, 0);
}
-static unsigned int snd_tea575x_read(struct snd_tea575x *tea)
+static u32 snd_tea575x_read(struct snd_tea575x *tea)
{
u16 l, rdata;
u32 data = 0;
@@ -120,6 +120,27 @@ static unsigned int snd_tea575x_read(struct snd_tea575x
*tea)
return data;
}
+static void snd_tea575x_get_freq(struct snd_tea575x *tea)
+{
+ u32 freq = snd_tea575x_read(tea) & TEA575X_BIT_FREQ_MASK;
+
+ if (freq == 0) {
+ tea->freq = 0;
+ return;
+ }
+
+ /* freq *= 12.5 */
+ freq *= 125;
+ freq /= 10;
+ /* crystal fixup */
+ if (tea->tea5759)
+ freq += TEA575X_FMIF;
+ else
+ freq -= TEA575X_FMIF;
+
+ tea->freq = clamp(freq * 16, FREQ_LO, FREQ_HI); /* from kHz */
+}
+
static void snd_tea575x_set_freq(struct snd_tea575x *tea)
{
u32 freq = tea->freq;
@@ -203,6 +224,8 @@ static int vidioc_g_frequency(struct file *file, void *priv,
if (f->tuner != 0)
return -EINVAL;
f->type = V4L2_TUNER_RADIO;
+ if (!tea->cannot_read_data)
+ snd_tea575x_get_freq(tea);
f->frequency = tea->freq;
return 0;
}
@@ -225,36 +248,50 @@ static int vidioc_s_hw_freq_seek(struct file *file, void
*fh,
struct v4l2_hw_freq_seek *a)
{
struct snd_tea575x *tea = video_drvdata(file);
+ int i, old_freq;
+ unsigned long timeout;
if (tea->cannot_read_data)
return -ENOTTY;
+
+ snd_tea575x_get_freq(tea);
+ old_freq = tea->freq;
+ /* clear the frequency, HW will fill it in */
+ tea->val &= ~TEA575X_BIT_FREQ_MASK;
tea->val |= TEA575X_BIT_SEARCH;
- tea->val &= ~TEA575X_BIT_UPDOWN;
if (a->seek_upward)
tea->val |= TEA575X_BIT_UPDOWN;
+ else
+ tea->val &= ~TEA575X_BIT_UPDOWN;
snd_tea575x_write(tea, tea->val);
+ timeout = jiffies + msecs_to_jif
Re: [PATCH v4 3/4] media i.MX27 camera: improve discard buffer handling.
Hi Javier
On Thu, 9 Feb 2012, javier Martin wrote:
> Hi Guennadi,
> I understand you are probably quite busy right now but it would be
> great if you could ack this patch. The sooner you merge it the sooner
> I will start working on the cleanup series. I've got some time on my
> hands now.
Yes, I can take this version, at the same time, I have a couple of
comments, that you might find useful to address in a clean-up patch;-) Or
just leave them as they are...
[anip]
> > @@ -1274,6 +1298,15 @@ static irqreturn_t mx27_camera_emma_irq(int
> > irq_emma, void *data)
> > struct mx2_camera_dev *pcdev = data;
> > unsigned int status = readl(pcdev->base_emma + PRP_INTRSTATUS);
> > struct mx2_buffer *buf;
> > + unsigned long flags;
> > +
> > + spin_lock_irqsave(&pcdev->lock, flags);
It wasn't an accident, that I wrote "spin_lock()" - without the "_irqsave"
part. You are in an ISR here, and this is the only IRQ, that your driver
has to protect against, so, here, I think, you don't have to block other
IRQs.
> > +
> > + if (list_empty(&pcdev->active_bufs)) {
> > + dev_warn(pcdev->dev, "%s: called while active list is
> > empty\n",
> > + __func__);
> > + goto irq_ok;
This means, you return IRQ_HANDLED here without even checking whether any
of your status bits are actually set. So, if you get an interrupt here
with an empty list, it might indeed be the case of a shared IRQ, in which
case you'd have to return IRQ_NONE.
> > + }
> >
> > if (status & (1 << 7)) { /* overflow */
> > u32 cntl;
As I said - we can keep this version, but maybe you'll like to improve at
least the latter of the above two snippets.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
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: SDR FM demodulation
Antti Palosaari wrote: >On 09.02.2012 17:11, Patrick Boettcher wrote: >> On Thursday 09 February 2012 16:01:12 Antti Palosaari wrote: >>> I have taken radio sniffs from FM capable Realtek DVB-T device. >Looks >>> like demodulator ADC samples IF frequency and pass all the sampled >>> data to the application. Application is then responsible for >>> decoding that. Device supports DVB-T, FM and DAB. I can guess both >>> FM and DAB are demodulated by software. >>> >>> Here is 17 second, 83 MB, FM radio sniff: >>> http://palosaari.fi/linux/v4l-dvb/rtl2832u_fm/ >>> Decode it and listen some Finnish speak ;) >>> >>> Could someone help to decode it? I tried GNU Radio, but I failed >>> likely because I didn't have enough knowledge... GNU Radio and >>> Octave or Matlab are way to go. >> >> For someone to decode it, you would need to give more information >about >> the format of the stream. Like the sampling frequency, the >sample-format >> and then the IF-frequency. > >You can see sampling format easily looking hexdump or open file in >Audacity. It is 8bit unsigned samples, 2 channels (I & Q). > >No knowledge about IF... For good guess is to try some general used >IFs. > >Sampling freq can be calculated using sample info and the fact it is >about 17 sec. sample size = 86919168 Bytes, time 17 sec. 2 channels, 1 >byte sample => 2556446,11765 sample/sec (~2.5 MHz!) > >> I never did something like myself, but from what I saw in gnuradio >there >> should be everything to make a FM-demod based on the data. > >Yes there was a lot of block and those were rather easy to connect >using >graphical interface (gnuradio-companion). But I don't know exactly what > >block are needed and what are parameters. I used file-sink => >fm-modulator => audio-sink. Likely not enough :i > >Without any earlier experience it is rather challenging. But if there >is >someone who have done that earlier using USRP SDR he could likely do it > >easier :) > >regards >Antti >-- >http://palosaari.fi/ >-- >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 Implement a phased locked loop (phase comparator, low pass filter, and VCO) that is centered reasonably close to the IF. The output of the LPF of the PLL should be the demodulated signal, IIRC. Maybe this matlab (octave) file will help you: http://www.mathworks.com/matlabcentral/fileexchange/24167-simple-pll-demostration Regards, Andy -- 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: TechnoTrend CT-3650 Viaccess CAM never initializes correctly
2012/1/31 Kenni Lund :
> Hi list
>
> I'm unable to get the CI working on a TT CT-3650 with a Viaccess CAM.
> Every time the CAM is inserted, I get a "dvb_ca adapter 0: Invalid PC
> card inserted :(" error message.
>
> I've tested with both an Arch Linux 3.2.1 kernel (CI-support included)
> and with a Ubuntu 2.6.32 kernel with latest media_build git compiled
> against it - both results in the same error.
>
> To rule out any hardware issues, I've tested the tuner with the
> Viaccess CAM under Windows, and it works without any issues here.
>
> From my very limited understanding of the code, it appears that the
> CAM never returns any initialization string to the driver - or times
> out too early - and therefore never is initialized ("TUPLE type:0x0
> length:0").
For the sake of the archives, I finally got it working. Jose Alberto
Reguero was kind enough to tell me, that the above error message is
simply caused by the CAM being in sleep-mode. When an application
needs it, the CAM *should* wake up and initialize successfully. In my
case it didn't on multiple test setups, but it works now on my test
system with the following software:
- A daily build of Ubuntu 12.04 (~alpha2) which includes a 3.2 kernel.
- A daily build of MythTV pre0.25.
- A quick workaround with hard links added to /etc/rc.local to make up
for the non-existing /dev/dvb/adapter0/*1 devices on the combined
DVB-C/T tuner:
ln -s /dev/dvb/adapter0/ca0 /dev/dvb/adapter0/ca1
ln -s /dev/dvb/adapter0/demux0 /dev/dvb/adapter0/demux1
ln -s /dev/dvb/adapter0/dvr0 /dev/dvb/adapter0/dvr1
ln -s /dev/dvb/adapter0/net0 /dev/dvb/adapter0/net1
With this setup, the CAM initializes correctly once the MythTV backend
is started on bootup.
Best regards
Kenni
--
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 00/35] Add a driver for Terratec H7
Update: On Thu, Feb 9, 2012 at 12:04 AM, Torfinn Ingolfsen wrote: > Never mind. after adding this patch: > http://patchwork.linuxtv.org/patch/9691/ > > and rebuilding the media drivers, the device is now detected: > tingo@kg-f4:~$ dmesg | grep -i terratec > [ 19.755806] dvb-usb: found a 'TerraTec DTV StarBox DVB-T/C USB2.0 > (az6007)' in warm state. > [ 20.949045] DVB: registering new adapter (TerraTec DTV StarBox > DVB-T/C USB2.0 (az6007)) > [ 23.732039] Registered IR keymap rc-nec-terratec-cinergy-xs > [ 23.732442] dvb-usb: TerraTec DTV StarBox DVB-T/C USB2.0 (az6007) > successfully initialized and connected. I have now tested the TerraTec H7, both with w_scan and with Kaffeine. Neither of then is able to find any channels from the H7. (The device is connected to an external power supply). However, if I connect another device (a PCTV nanoStick T2 290e) to the same cable, both w_scan and Kaffeine find all the channels for my provider, and I can watch the clear (unencrypted) ones in Kaffeine. How can I debug the H7 further? -- Regards, Torfinn Ingolfsen -- 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:Thu Feb 9 19:00:17 CET 2012 git hash:59b30294e14fa6a370fdd2bc2921cca1f977ef16 gcc version: i686-linux-gcc (GCC) 4.6.2 host hardware:x86_64 host os: 3.1-2.slh.1-amd64 linux-git-arm-eabi-enoxys: WARNINGS linux-git-arm-eabi-omap: WARNINGS linux-git-armv5-ixp: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: WARNINGS linux-git-mips: WARNINGS linux-git-powerpc64: 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-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-rc1-x86_64: WARNINGS apps: WARNINGS spec-git: WARNINGS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.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] drivers/media/video/s5p-tv/*_drv.c: use devm_ functions
Acked-by: Kyungmin Park
To Marek,
Please include this patch at next git pull request.
On Thu, Feb 9, 2012 at 7:45 PM, Julia Lawall wrote:
> From: Julia Lawall
>
> The various devm_ functions allocate memory that is released when a driver
> detaches. This patch uses these functions for data that is allocated in
> the probe function of a platform device and is only freed in the remove
> function.
>
> Signed-off-by: Julia Lawall
>
> ---
> drivers/media/video/s5p-tv/hdmi_drv.c | 30 ++
> drivers/media/video/s5p-tv/sdo_drv.c | 26 +-
> 2 files changed, 19 insertions(+), 37 deletions(-)
>
> diff --git a/drivers/media/video/s5p-tv/hdmi_drv.c
> b/drivers/media/video/s5p-tv/hdmi_drv.c
> index 3e0dd09..6c21dc6 100644
> --- a/drivers/media/video/s5p-tv/hdmi_drv.c
> +++ b/drivers/media/video/s5p-tv/hdmi_drv.c
> @@ -875,7 +875,7 @@ static int __devinit hdmi_probe(struct platform_device
> *pdev)
>
> dev_dbg(dev, "probe start\n");
>
> - hdmi_dev = kzalloc(sizeof(*hdmi_dev), GFP_KERNEL);
> + hdmi_dev = devm_kzalloc(&pdev->dev, sizeof(*hdmi_dev), GFP_KERNEL);
> if (!hdmi_dev) {
> dev_err(dev, "out of memory\n");
> ret = -ENOMEM;
> @@ -886,7 +886,7 @@ static int __devinit hdmi_probe(struct platform_device
> *pdev)
>
> ret = hdmi_resources_init(hdmi_dev);
> if (ret)
> - goto fail_hdev;
> + goto fail;
>
> /* mapping HDMI registers */
> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> @@ -896,24 +896,26 @@ static int __devinit hdmi_probe(struct platform_device
> *pdev)
> goto fail_init;
> }
>
> - hdmi_dev->regs = ioremap(res->start, resource_size(res));
> + hdmi_dev->regs = devm_ioremap(&pdev->dev, res->start,
> + resource_size(res));
> if (hdmi_dev->regs == NULL) {
> dev_err(dev, "register mapping failed.\n");
> ret = -ENXIO;
> - goto fail_hdev;
> + goto fail;
> }
>
> res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
> if (res == NULL) {
> dev_err(dev, "get interrupt resource failed.\n");
> ret = -ENXIO;
> - goto fail_regs;
> + goto fail_init;
> }
>
> - ret = request_irq(res->start, hdmi_irq_handler, 0, "hdmi", hdmi_dev);
> + ret = devm_request_irq(&pdev->dev, res->start, hdmi_irq_handler, 0,
> + "hdmi", hdmi_dev);
> if (ret) {
> dev_err(dev, "request interrupt failed.\n");
> - goto fail_regs;
> + goto fail_init;
> }
> hdmi_dev->irq = res->start;
>
> @@ -924,7 +926,7 @@ static int __devinit hdmi_probe(struct platform_device
> *pdev)
> ret = v4l2_device_register(NULL, &hdmi_dev->v4l2_dev);
> if (ret) {
> dev_err(dev, "could not register v4l2 device.\n");
> - goto fail_irq;
> + goto fail_init;
> }
>
> drv_data = (struct hdmi_driver_data *)
> @@ -969,18 +971,9 @@ static int __devinit hdmi_probe(struct platform_device
> *pdev)
> fail_vdev:
> v4l2_device_unregister(&hdmi_dev->v4l2_dev);
>
> -fail_irq:
> - free_irq(hdmi_dev->irq, hdmi_dev);
> -
> -fail_regs:
> - iounmap(hdmi_dev->regs);
> -
> fail_init:
> hdmi_resources_cleanup(hdmi_dev);
>
> -fail_hdev:
> - kfree(hdmi_dev);
> -
> fail:
> dev_err(dev, "probe failed\n");
> return ret;
> @@ -996,10 +989,7 @@ static int __devexit hdmi_remove(struct platform_device
> *pdev)
> clk_disable(hdmi_dev->res.hdmi);
> v4l2_device_unregister(&hdmi_dev->v4l2_dev);
> disable_irq(hdmi_dev->irq);
> - free_irq(hdmi_dev->irq, hdmi_dev);
> - iounmap(hdmi_dev->regs);
> hdmi_resources_cleanup(hdmi_dev);
> - kfree(hdmi_dev);
> dev_info(dev, "remove successful\n");
>
> return 0;
> diff --git a/drivers/media/video/s5p-tv/sdo_drv.c
> b/drivers/media/video/s5p-tv/sdo_drv.c
> index 059e774..f6bca2c 100644
> --- a/drivers/media/video/s5p-tv/sdo_drv.c
> +++ b/drivers/media/video/s5p-tv/sdo_drv.c
> @@ -301,7 +301,7 @@ static int __devinit sdo_probe(struct platform_device
> *pdev)
> struct clk *sclk_vpll;
>
> dev_info(dev, "probe start\n");
> - sdev = kzalloc(sizeof *sdev, GFP_KERNEL);
> + sdev = devm_kzalloc(&pdev->dev, sizeof *sdev, GFP_KERNEL);
> if (!sdev) {
> dev_err(dev, "not enough memory.\n");
> ret = -ENOMEM;
> @@ -314,14 +314,14 @@ static int __devinit sdo_probe(struct platform_device
> *pdev)
> if (res == NULL) {
> dev_err(dev, "get memory resource failed.\n");
> ret = -ENXIO;
> - goto fail_sdev;
> + goto fail;
> }
>
> - sdev->regs = ioremap(res->start, resource_size(res));
Re: AverTV Volar HD PRO
Il 07/02/2012 06:10, Andrej Podzimek ha scritto: > An attempt to scan channels in Kaffeine always fails before the progress > bar reaches 20% and lots of messages like this appear in dmesg: > > af9035: recv bulk message failed:-110 > af9033: I2C read failed reg:0047 > af9035: recv bulk message failed:-110 > af9033: I2C read failed reg:0047 > af9035: recv bulk message failed:-110 > af9033: I2C read failed reg:0045 > af9035: recv bulk message failed:-110 > af9033: I2C read failed reg:0048 > af9035: recv bulk message failed:-110 > af9033: I2C read failed reg:0047 > af9035: recv bulk message failed:-110 > af9033: I2C read failed reg:002c > af9035: recv bulk message failed:-110 > af9033: I2C read failed reg:0047 > af9035: recv bulk message failed:-110 > af9033: I2C read failed reg:0048 Hi Andrej, I contacted the original creator of the patch that you used previously (Xgaz on Ubuntu.it forums). He passed this suggestion to me (coming from a Spanish user): For people having the kernel message "af9035: recv bulk message failed:-110", it's due a problem with the power save mode. To solve it, create the file "/etc/modprobe.d/options.conf" with this content: options dvb-core dvb_powerdown_on_sleep=0 So basically you may need to disable the power saving functionalities to make the device working again. Since the only functional difference between the old and the new patch version is in the remote code (which I removed), probably this code was preventing your device to go into sleep mode, so it was hotter but worked fine. Please report if this helps. Regards, Gianluca -- 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: SDR FM demodulation
On 09.02.2012 17:11, Patrick Boettcher wrote: On Thursday 09 February 2012 16:01:12 Antti Palosaari wrote: I have taken radio sniffs from FM capable Realtek DVB-T device. Looks like demodulator ADC samples IF frequency and pass all the sampled data to the application. Application is then responsible for decoding that. Device supports DVB-T, FM and DAB. I can guess both FM and DAB are demodulated by software. Here is 17 second, 83 MB, FM radio sniff: http://palosaari.fi/linux/v4l-dvb/rtl2832u_fm/ Decode it and listen some Finnish speak ;) Could someone help to decode it? I tried GNU Radio, but I failed likely because I didn't have enough knowledge... GNU Radio and Octave or Matlab are way to go. For someone to decode it, you would need to give more information about the format of the stream. Like the sampling frequency, the sample-format and then the IF-frequency. You can see sampling format easily looking hexdump or open file in Audacity. It is 8bit unsigned samples, 2 channels (I & Q). No knowledge about IF... For good guess is to try some general used IFs. Sampling freq can be calculated using sample info and the fact it is about 17 sec. sample size = 86919168 Bytes, time 17 sec. 2 channels, 1 byte sample => 2556446,11765 sample/sec (~2.5 MHz!) I never did something like myself, but from what I saw in gnuradio there should be everything to make a FM-demod based on the data. Yes there was a lot of block and those were rather easy to connect using graphical interface (gnuradio-companion). But I don't know exactly what block are needed and what are parameters. I used file-sink => fm-modulator => audio-sink. Likely not enough :i Without any earlier experience it is rather challenging. But if there is someone who have done that earlier using USRP SDR he could likely do it easier :) regards Antti -- http://palosaari.fi/ -- 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: SDR FM demodulation
On Thursday 09 February 2012 16:01:12 Antti Palosaari wrote: > I have taken radio sniffs from FM capable Realtek DVB-T device. Looks > like demodulator ADC samples IF frequency and pass all the sampled > data to the application. Application is then responsible for > decoding that. Device supports DVB-T, FM and DAB. I can guess both > FM and DAB are demodulated by software. > > Here is 17 second, 83 MB, FM radio sniff: > http://palosaari.fi/linux/v4l-dvb/rtl2832u_fm/ > Decode it and listen some Finnish speak ;) > > Could someone help to decode it? I tried GNU Radio, but I failed > likely because I didn't have enough knowledge... GNU Radio and > Octave or Matlab are way to go. For someone to decode it, you would need to give more information about the format of the stream. Like the sampling frequency, the sample-format and then the IF-frequency. I never did something like myself, but from what I saw in gnuradio there should be everything to make a FM-demod based on the data. regards, -- Patrick Boettcher Kernel Labs Inc. http://www.kernellabs.com/ -- 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
SDR FM demodulation
I have taken radio sniffs from FM capable Realtek DVB-T device. Looks like demodulator ADC samples IF frequency and pass all the sampled data to the application. Application is then responsible for decoding that. Device supports DVB-T, FM and DAB. I can guess both FM and DAB are demodulated by software. Here is 17 second, 83 MB, FM radio sniff: http://palosaari.fi/linux/v4l-dvb/rtl2832u_fm/ Decode it and listen some Finnish speak ;) Could someone help to decode it? I tried GNU Radio, but I failed likely because I didn't have enough knowledge... GNU Radio and Octave or Matlab are way to go. I smell very cheap poor man's software radio here :) regards Antti -- http://palosaari.fi/ -- 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 v4 3/4] media i.MX27 camera: improve discard buffer handling.
Hi Guennadi,
I understand you are probably quite busy right now but it would be
great if you could ack this patch. The sooner you merge it the sooner
I will start working on the cleanup series. I've got some time on my
hands now.
Thank you.
On 7 February 2012 11:14, Javier Martin wrote:
> The way discard buffer was previously handled lead
> to possible races that made a buffer that was not
> yet ready to be overwritten by new video data. This
> is easily detected at 25fps just adding "#define DEBUG"
> to enable the "memset" check and seeing how the image
> is corrupted.
>
> A new "discard" queue and two discard buffers have
> been added to make them flow trough the pipeline
> of queues and thus provide suitable event ordering.
>
> Signed-off-by: Javier Martin
> ---
> - Add proper locking to avoid races between IRQ and stop callbacks.
> - If a list is unexpectedly empty want the user and bail out.
>
> ---
> drivers/media/video/mx2_camera.c | 287
> +-
> 1 files changed, 161 insertions(+), 126 deletions(-)
>
> diff --git a/drivers/media/video/mx2_camera.c
> b/drivers/media/video/mx2_camera.c
> index 35ab971..3880d24 100644
> --- a/drivers/media/video/mx2_camera.c
> +++ b/drivers/media/video/mx2_camera.c
> @@ -237,7 +237,8 @@ struct mx2_buffer {
> struct list_head queue;
> enum mx2_buffer_state state;
>
> - int bufnum;
> + int bufnum;
> + bool discard;
> };
>
> struct mx2_camera_dev {
> @@ -256,6 +257,7 @@ struct mx2_camera_dev {
>
> struct list_head capture;
> struct list_head active_bufs;
> + struct list_head discard;
>
> spinlock_t lock;
>
> @@ -268,6 +270,7 @@ struct mx2_camera_dev {
>
> u32 csicr1;
>
> + struct mx2_buffer buf_discard[2];
> void *discard_buffer;
> dma_addr_t discard_buffer_dma;
> size_t discard_size;
> @@ -329,6 +332,29 @@ static struct mx2_fmt_cfg *mx27_emma_prp_get_format(
> return &mx27_emma_prp_table[0];
> };
>
> +static void mx27_update_emma_buf(struct mx2_camera_dev *pcdev,
> + unsigned long phys, int bufnum)
> +{
> + struct mx2_fmt_cfg *prp = pcdev->emma_prp;
> +
> + if (prp->cfg.channel == 1) {
> + writel(phys, pcdev->base_emma +
> + PRP_DEST_RGB1_PTR + 4 * bufnum);
> + } else {
> + writel(phys, pcdev->base_emma +
> + PRP_DEST_Y_PTR - 0x14 * bufnum);
> + if (prp->out_fmt == V4L2_PIX_FMT_YUV420) {
> + u32 imgsize = pcdev->icd->user_height *
> + pcdev->icd->user_width;
> +
> + writel(phys + imgsize, pcdev->base_emma +
> + PRP_DEST_CB_PTR - 0x14 * bufnum);
> + writel(phys + ((5 * imgsize) / 4), pcdev->base_emma +
> + PRP_DEST_CR_PTR - 0x14 * bufnum);
> + }
> + }
> +}
> +
> static void mx2_camera_deactivate(struct mx2_camera_dev *pcdev)
> {
> unsigned long flags;
> @@ -377,7 +403,7 @@ static int mx2_camera_add_device(struct soc_camera_device
> *icd)
> writel(pcdev->csicr1, pcdev->base_csi + CSICR1);
>
> pcdev->icd = icd;
> - pcdev->frame_count = -1;
> + pcdev->frame_count = 0;
>
> dev_info(icd->parent, "Camera driver attached to camera %d\n",
> icd->devnum);
> @@ -397,13 +423,6 @@ static void mx2_camera_remove_device(struct
> soc_camera_device *icd)
>
> mx2_camera_deactivate(pcdev);
>
> - if (pcdev->discard_buffer) {
> - dma_free_coherent(ici->v4l2_dev.dev, pcdev->discard_size,
> - pcdev->discard_buffer,
> - pcdev->discard_buffer_dma);
> - pcdev->discard_buffer = NULL;
> - }
> -
> pcdev->icd = NULL;
> }
>
> @@ -640,7 +659,6 @@ static void mx2_videobuf_release(struct vb2_buffer *vb)
> */
>
> spin_lock_irqsave(&pcdev->lock, flags);
> - list_del_init(&buf->queue);
> if (cpu_is_mx25() && buf->state == MX2_STATE_ACTIVE) {
> if (pcdev->fb1_active == buf) {
> pcdev->csicr1 &= ~CSICR1_FB1_DMA_INTEN;
> @@ -656,6 +674,34 @@ static void mx2_videobuf_release(struct vb2_buffer *vb)
> spin_unlock_irqrestore(&pcdev->lock, flags);
> }
>
> +static void mx27_camera_emma_buf_init(struct soc_camera_device *icd,
> + int bytesperline)
> +{
> + struct soc_camera_host *ici =
> + to_soc_camera_host(icd->parent);
> + struct mx2_camera_dev *pcdev = ici->priv;
> + struct mx2_fmt_cfg *prp = pcdev->emma_prp;
> +
> + writel((icd->user_width << 16) | icd->user_height,
[PATCH] use devm_ functions
The semantic patch (http://coccinelle.lip6.fr/) used in generating this
patch is as follows. Some manual cleanup was required. This improves on
the previous version in that allocated values are allowed to be renamed
before they are freed.
virtual after_start
virtual returned
virtual arg
virtual get
// -
// find functions
@plat depends on !after_start@
identifier i,pfn,rfn;
position p;
@@
struct platform_driver i@p = {
.probe = pfn,
.remove = (<+...rfn...+>),
};
// -
// set up iteration
@initialize:ocaml@
type ret = UseReturned | UseReturned2 of string | UseArg | UseGet
let add pfn rfn alloc free devm_alloc file rule =
let it = new iteration() in
it#set_files [file];
it#add_virtual_rule After_start;
(match rule with
UseReturned -> it#add_virtual_rule Returned
| UseReturned2(free) -> it#add_virtual_rule Returned;
it#add_virtual_identifier Second_free free
| UseArg -> it#add_virtual_rule Arg
| UseGet -> it#add_virtual_rule Get);
if not (pfn="") then it#add_virtual_identifier Pfn pfn;
if not (rfn="") then it#add_virtual_identifier Rfn rfn;
if not (alloc="") then it#add_virtual_identifier Alloc alloc;
if not (free="") then it#add_virtual_identifier Free free;
if not (devm_alloc="") then it#add_virtual_identifier Devm_alloc devm_alloc;
it#register()
@script:ocaml@
pfn << plat.pfn;
rfn << plat.rfn;
p << plat.p;
@@
let file = (List.hd p).file in
add pfn rfn "kmalloc" "kfree" "devm_kzalloc" file UseReturned;
add pfn rfn "kzalloc" "kfree" "devm_kzalloc" file UseReturned;
add pfn rfn "ioremap" "iounmap" "devm_ioremap" file UseReturned;
add pfn rfn "ioremap_nocache" "iounmap" "devm_ioremap_nocache" file
UseReturned;
add pfn rfn "request_irq" "free_irq" "devm_request_irq" file UseArg;
add pfn rfn "request_threaded_irq" "free_irq" "devm_request_threaded_irq" file
UseArg;
add pfn rfn "dma_alloc_coherent" "dma_free_coherent" "dmam_alloc_coherent"
file UseArg;
add pfn rfn "dma_alloc_noncoherent" "dma_free_noncoherent"
"dmam_alloc_noncoherent" file UseArg;
(* several possibilities... *)
add pfn rfn "request_region" "release_region" "devm_request_region" file
UseGet;
add pfn rfn "request_mem_region" "release_mem_region"
"devm_request_mem_region" file UseGet;
add pfn rfn "request_region" "release_region" "devm_request_region" file
UseArg;
add pfn rfn "request_mem_region" "release_mem_region"
"devm_request_mem_region" file UseArg;
(* fix a bug at the same time *)
add pfn rfn "request_region" "release_resource" "devm_request_region" file
(UseReturned2("kfree"));
add pfn rfn "request_mem_region" "release_resource"
"devm_request_mem_region" file (UseReturned2("kfree"));
add pfn rfn "ioport_map" "ioport_unmap" "devm_ioport_map" file UseReturned
// -
// process the initial definition of the probe function
@preprobe@
identifier virtual.pfn;
position p;
@@
pfn@p(...) { ... }
@probe@
identifier pfn;
position preprobe.p;
@@
pfn@p(...) { ... }
@labelled_return@
identifier probe.pfn,l;
expression e;
@@
pfn(...) { <+... l: return e; ...+> }
// -
// transform functions where free uses the result
@prb depends on returned exists@
identifier probe.pfn,pdev,virtual.alloc,virtual.free,virtual.second_free;
expression x,y,e;
expression list args;
position p1,p2,p3;
type T1,T2,T3;
@@
pfn(struct platform_device *pdev) { ... when any
x = (T1)alloc@p1(args)
<... when strict
when any
when forall
(
y = x;
... when != y = e
when != &y
free@p2((T2)y,...);
... when != x
when != y
second_free@p3((T3)y,...);
|
y = x;
... when != y = e
when != &y
free@p2((T2)y,...);
|
free@p2((T2)x,...);
... when != x
second_free@p3((T3)x,...);
|
free@p2((T2)x,...);
)
...>
}
@reme exists@
identifier virtual.rfn,virtual.free;
expression prb.x,prb.y;
type T;
@@
rfn(...) { ... free((T)\(x\|y\),...); ... }
@rem depends on reme@
identifier virtual.rfn,virtual.free,virtual.second_free;
expression prb.x,prb.y;
position p4,p5;
type T,T1;
@@
rfn(...) {
<... when strict
(
free@p4((T)\(x\|y\),...);
... when != x
second_free@p5((T1)\(x\|y\),...);
|
free@p4((T)\(x\|y\),...);
)
...>
}
@bad@
identifier virtual.free;
expression prb.x,prb.y;
position p != {prb.p2,rem.p4};
type T;
@@
free@p((T)\(x\|y\),...)
@modif depends on rem && !bad@
expression x;
identifier prb.pdev,virtual.alloc,virtual.free,virtual.devm_alloc;
identifier virtual.second_free;
expression list args;
position prb.p1,prb.p2,prb.p3,rem.p4,rem.p5;
type T;
@@
(
- free@p2(...);
|
- second_free@p3(...);
|
- free@p4(...);
|
- second_free@p5(...);
|
x =
- alloc@p1(
+ devm_alloc(&pdev->dev,
args)
|
x =
- (T)alloc@p1(
+ (T)devm_alloc(&pdev->dev,
args)
)
// --
[PATCH] drivers/media/video/s5p-tv/*_drv.c: use devm_ functions
From: Julia Lawall
The various devm_ functions allocate memory that is released when a driver
detaches. This patch uses these functions for data that is allocated in
the probe function of a platform device and is only freed in the remove
function.
Signed-off-by: Julia Lawall
---
drivers/media/video/s5p-tv/hdmi_drv.c | 30 ++
drivers/media/video/s5p-tv/sdo_drv.c | 26 +-
2 files changed, 19 insertions(+), 37 deletions(-)
diff --git a/drivers/media/video/s5p-tv/hdmi_drv.c
b/drivers/media/video/s5p-tv/hdmi_drv.c
index 3e0dd09..6c21dc6 100644
--- a/drivers/media/video/s5p-tv/hdmi_drv.c
+++ b/drivers/media/video/s5p-tv/hdmi_drv.c
@@ -875,7 +875,7 @@ static int __devinit hdmi_probe(struct platform_device
*pdev)
dev_dbg(dev, "probe start\n");
- hdmi_dev = kzalloc(sizeof(*hdmi_dev), GFP_KERNEL);
+ hdmi_dev = devm_kzalloc(&pdev->dev, sizeof(*hdmi_dev), GFP_KERNEL);
if (!hdmi_dev) {
dev_err(dev, "out of memory\n");
ret = -ENOMEM;
@@ -886,7 +886,7 @@ static int __devinit hdmi_probe(struct platform_device
*pdev)
ret = hdmi_resources_init(hdmi_dev);
if (ret)
- goto fail_hdev;
+ goto fail;
/* mapping HDMI registers */
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
@@ -896,24 +896,26 @@ static int __devinit hdmi_probe(struct platform_device
*pdev)
goto fail_init;
}
- hdmi_dev->regs = ioremap(res->start, resource_size(res));
+ hdmi_dev->regs = devm_ioremap(&pdev->dev, res->start,
+ resource_size(res));
if (hdmi_dev->regs == NULL) {
dev_err(dev, "register mapping failed.\n");
ret = -ENXIO;
- goto fail_hdev;
+ goto fail;
}
res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
if (res == NULL) {
dev_err(dev, "get interrupt resource failed.\n");
ret = -ENXIO;
- goto fail_regs;
+ goto fail_init;
}
- ret = request_irq(res->start, hdmi_irq_handler, 0, "hdmi", hdmi_dev);
+ ret = devm_request_irq(&pdev->dev, res->start, hdmi_irq_handler, 0,
+ "hdmi", hdmi_dev);
if (ret) {
dev_err(dev, "request interrupt failed.\n");
- goto fail_regs;
+ goto fail_init;
}
hdmi_dev->irq = res->start;
@@ -924,7 +926,7 @@ static int __devinit hdmi_probe(struct platform_device
*pdev)
ret = v4l2_device_register(NULL, &hdmi_dev->v4l2_dev);
if (ret) {
dev_err(dev, "could not register v4l2 device.\n");
- goto fail_irq;
+ goto fail_init;
}
drv_data = (struct hdmi_driver_data *)
@@ -969,18 +971,9 @@ static int __devinit hdmi_probe(struct platform_device
*pdev)
fail_vdev:
v4l2_device_unregister(&hdmi_dev->v4l2_dev);
-fail_irq:
- free_irq(hdmi_dev->irq, hdmi_dev);
-
-fail_regs:
- iounmap(hdmi_dev->regs);
-
fail_init:
hdmi_resources_cleanup(hdmi_dev);
-fail_hdev:
- kfree(hdmi_dev);
-
fail:
dev_err(dev, "probe failed\n");
return ret;
@@ -996,10 +989,7 @@ static int __devexit hdmi_remove(struct platform_device
*pdev)
clk_disable(hdmi_dev->res.hdmi);
v4l2_device_unregister(&hdmi_dev->v4l2_dev);
disable_irq(hdmi_dev->irq);
- free_irq(hdmi_dev->irq, hdmi_dev);
- iounmap(hdmi_dev->regs);
hdmi_resources_cleanup(hdmi_dev);
- kfree(hdmi_dev);
dev_info(dev, "remove successful\n");
return 0;
diff --git a/drivers/media/video/s5p-tv/sdo_drv.c
b/drivers/media/video/s5p-tv/sdo_drv.c
index 059e774..f6bca2c 100644
--- a/drivers/media/video/s5p-tv/sdo_drv.c
+++ b/drivers/media/video/s5p-tv/sdo_drv.c
@@ -301,7 +301,7 @@ static int __devinit sdo_probe(struct platform_device *pdev)
struct clk *sclk_vpll;
dev_info(dev, "probe start\n");
- sdev = kzalloc(sizeof *sdev, GFP_KERNEL);
+ sdev = devm_kzalloc(&pdev->dev, sizeof *sdev, GFP_KERNEL);
if (!sdev) {
dev_err(dev, "not enough memory.\n");
ret = -ENOMEM;
@@ -314,14 +314,14 @@ static int __devinit sdo_probe(struct platform_device
*pdev)
if (res == NULL) {
dev_err(dev, "get memory resource failed.\n");
ret = -ENXIO;
- goto fail_sdev;
+ goto fail;
}
- sdev->regs = ioremap(res->start, resource_size(res));
+ sdev->regs = devm_ioremap(&pdev->dev, res->start, resource_size(res));
if (sdev->regs == NULL) {
dev_err(dev, "register mapping failed.\n");
ret = -ENXIO;
- goto fail_sdev;
+ goto fail;
}
/* acquiring interrupt */
@@ -329,12 +329,13 @@ static int
