[PATCH 6/7] soc_camera/sh_mobile_ceu_camera: Fix warning related to spacing
Fixes the following checkpatch warning:
WARNING: please, no space before tabs
Signed-off-by: Sachin Kamat
---
.../platform/soc_camera/sh_mobile_ceu_camera.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/platform/soc_camera/sh_mobile_ceu_camera.c
b/drivers/media/platform/soc_camera/sh_mobile_ceu_camera.c
index d7294ef..143d29fe 100644
--- a/drivers/media/platform/soc_camera/sh_mobile_ceu_camera.c
+++ b/drivers/media/platform/soc_camera/sh_mobile_ceu_camera.c
@@ -2288,7 +2288,7 @@ static const struct dev_pm_ops sh_mobile_ceu_dev_pm_ops =
{
};
static struct platform_driver sh_mobile_ceu_driver = {
- .driver = {
+ .driver = {
.name = "sh_mobile_ceu",
.pm = &sh_mobile_ceu_dev_pm_ops,
},
--
1.7.9.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 7/7] soc_camera/soc_camera_platform: Fix warning related to spacing
Fixes the following checkpatch warning:
WARNING: please, no space before tabs
Signed-off-by: Sachin Kamat
---
.../platform/soc_camera/soc_camera_platform.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/platform/soc_camera/soc_camera_platform.c
b/drivers/media/platform/soc_camera/soc_camera_platform.c
index ce3b1d6..1b7a88c 100644
--- a/drivers/media/platform/soc_camera/soc_camera_platform.c
+++ b/drivers/media/platform/soc_camera/soc_camera_platform.c
@@ -188,7 +188,7 @@ static int soc_camera_platform_remove(struct
platform_device *pdev)
}
static struct platform_driver soc_camera_platform_driver = {
- .driver = {
+ .driver = {
.name = "soc_camera_platform",
.owner = THIS_MODULE,
},
--
1.7.9.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 4/7] soc_camera/pxa_camera: Fix warning related to spacing
Fixes the following checkpatch warning:
WARNING: please, no space before tabs
Signed-off-by: Sachin Kamat
---
drivers/media/platform/soc_camera/pxa_camera.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/platform/soc_camera/pxa_camera.c
b/drivers/media/platform/soc_camera/pxa_camera.c
index 42abbce..b0e6f3b 100644
--- a/drivers/media/platform/soc_camera/pxa_camera.c
+++ b/drivers/media/platform/soc_camera/pxa_camera.c
@@ -1802,7 +1802,7 @@ static struct dev_pm_ops pxa_camera_pm = {
};
static struct platform_driver pxa_camera_driver = {
- .driver = {
+ .driver = {
.name = PXA_CAM_DRV_NAME,
.pm = &pxa_camera_pm,
},
--
1.7.9.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 5/7] soc_camera/pxa_camera: Constify struct dev_pm_ops
struct dev_pm_ops should be const.
Signed-off-by: Sachin Kamat
---
drivers/media/platform/soc_camera/pxa_camera.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/platform/soc_camera/pxa_camera.c
b/drivers/media/platform/soc_camera/pxa_camera.c
index b0e6f3b..d665242 100644
--- a/drivers/media/platform/soc_camera/pxa_camera.c
+++ b/drivers/media/platform/soc_camera/pxa_camera.c
@@ -1796,7 +1796,7 @@ static int pxa_camera_remove(struct platform_device *pdev)
return 0;
}
-static struct dev_pm_ops pxa_camera_pm = {
+static const struct dev_pm_ops pxa_camera_pm = {
.suspend= pxa_camera_suspend,
.resume = pxa_camera_resume,
};
--
1.7.9.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/7] soc_camera/mx2_camera: Fix warnings related to spacing
Fixes the following checkpatch warnings:
WARNING: unnecessary whitespace before a quoted newline
WARNING: please, no space before tabs
Signed-off-by: Sachin Kamat
---
drivers/media/platform/soc_camera/mx2_camera.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/soc_camera/mx2_camera.c
b/drivers/media/platform/soc_camera/mx2_camera.c
index 048c26a..3a0ffbb 100644
--- a/drivers/media/platform/soc_camera/mx2_camera.c
+++ b/drivers/media/platform/soc_camera/mx2_camera.c
@@ -1454,7 +1454,7 @@ static int mx27_camera_emma_init(struct platform_device
*pdev)
err = devm_request_irq(pcdev->dev, irq_emma, mx27_camera_emma_irq, 0,
MX2_CAM_DRV_NAME, pcdev);
if (err) {
- dev_err(pcdev->dev, "Camera EMMA interrupt register failed \n");
+ dev_err(pcdev->dev, "Camera EMMA interrupt register failed\n");
goto out;
}
@@ -1615,7 +1615,7 @@ static int mx2_camera_remove(struct platform_device *pdev)
}
static struct platform_driver mx2_camera_driver = {
- .driver = {
+ .driver = {
.name = MX2_CAM_DRV_NAME,
},
.id_table = mx2_camera_devtype,
--
1.7.9.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 3/7] soc_camera/mx3_camera: Fix warning related to spacing
Silences the following checkpatch warning:
WARNING: please, no space before tabs
Signed-off-by: Sachin Kamat
---
drivers/media/platform/soc_camera/mx3_camera.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/platform/soc_camera/mx3_camera.c
b/drivers/media/platform/soc_camera/mx3_camera.c
index 2c3bd69..5da3377 100644
--- a/drivers/media/platform/soc_camera/mx3_camera.c
+++ b/drivers/media/platform/soc_camera/mx3_camera.c
@@ -1276,7 +1276,7 @@ static int mx3_camera_remove(struct platform_device *pdev)
}
static struct platform_driver mx3_camera_driver = {
- .driver = {
+ .driver = {
.name = MX3_CAM_DRV_NAME,
},
.probe = mx3_camera_probe,
--
1.7.9.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 1/7] soc_camera/mx1_camera: Fix warnings related to spacing
Fixes the following checkpatch warnings:
WARNING: unnecessary whitespace before a quoted newline
WARNING: please, no space before tabs
Signed-off-by: Sachin Kamat
---
drivers/media/platform/soc_camera/mx1_camera.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/soc_camera/mx1_camera.c
b/drivers/media/platform/soc_camera/mx1_camera.c
index 4389f43..a3fd8d6 100644
--- a/drivers/media/platform/soc_camera/mx1_camera.c
+++ b/drivers/media/platform/soc_camera/mx1_camera.c
@@ -776,7 +776,7 @@ static int __init mx1_camera_probe(struct platform_device
*pdev)
/* request irq */
err = claim_fiq(&fh);
if (err) {
- dev_err(&pdev->dev, "Camera interrupt register failed \n");
+ dev_err(&pdev->dev, "Camera interrupt register failed\n");
goto exit_free_dma;
}
@@ -853,7 +853,7 @@ static int __exit mx1_camera_remove(struct platform_device
*pdev)
}
static struct platform_driver mx1_camera_driver = {
- .driver = {
+ .driver = {
.name = DRIVER_NAME,
},
.remove = __exit_p(mx1_camera_remove),
--
1.7.9.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
Re: [PATCH] cxd2820r_t2: Multistream support (MultiPLP)
Now confirmed in Russia - work ok. Used my mods scan-s2 + tzap-t2 + vdr 1.7.27 https://bitbucket.org/CrazyCat/szap-s2 https://bitbucket.org/CrazyCat/scan-s2 24.03.2013, 20:19, "Antti Palosaari" : > Is there anyone who could test that patch? > > I have no multi PLP signal here. > > Also there is minor issue on that patch. As stream ID validy is already > checked there is no reason for bit AND 0xff. -- 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 0/3] em28xx: add support for two buses on em2874 and upper
Em Tue, 02 Apr 2013 21:02:33 +0200
Frank Schäfer escreveu:
> > We don't have enough documentation to write a driver for avf4910b. Some
> > developers at the ML are trying to implement support for it for HVR-930C:
> >
> > http://www.mail-archive.com/linux-media@vger.kernel.org/msg59296.html
> >
> > There is a code pointed there for avf4910a:
> >
> > https://github.com/wurststulle/ngene_2400i/blob/2377b1fd99d91ff355a5e46881ef27ccc87cb376/avf4910a.c
> >
> > Also, maybe to access the avf4910b some different GPIO setting may be
> > needed,
> > as it might be powered off by the GPIO settings initialized at device i
> >
>
> Yeah, I remember that.
> Anyway, I don't have time for this at the moment.
> I also think this is really Hauppauges job. These devices are still
> expensive (65-100€) but half working only.
> That's why I'm going to do it with all my Hauppauge devices: wait 5
> years and then buy them used for max. 10€.
> Maybe I'll get back to this if it is still not working then and I find
> some free time, but no guarantee... ;)
It's up to you. Even if Hauppauge would be interested on doing it, I
suspect they won't do anything anytime soon, as it may be hard to find
someone at Trident to ack with a source code release, as Trident bankrupted.
I probably won't have any spare time anytime soon for doing that, although
it could be fun. So, perhaps one day I might try to write a driver for
avf4910b, at least to make it work with PAL/M.
> Removing the temporary switches to bus A makes no difference (as
> expected).
>
> > There are some things there on the init sequence that can be
> > cleaned/removed. Those sequences generally comes from observing
> > what the original driver does. While it produces a working driver,
> > in general, it is not optimized and part of the init sequence can
> > be removed.
> Do you want me to send patches to remove these writes ?
> Which i2c speed settings do you suggest for the HVR-930C and the
> HTC-Stick (board settings:
> EM28XX_I2C_FREQ_400_KHZ, code overwrites it with
> EM28XX_I2C_FREQ_100_KHZ) ?
> >>> Sure. The better would be to even remove the hauppauge_hvr930c_init()
> >>> function, as this is just a hack, and use the setup via the em28xx-cards
> >>> commented entries:
> >>>
> >>> .tuner_type = TUNER_XC5000,
> >>> .tuner_addr = 0x41,
> >>> .dvb_gpio = hauppauge_930c_digital,
> >>> .tuner_gpio = hauppauge_930c_gpio,
> >> Hmm... tuner address is 0x61 for the device I tested !
> >> The register sequences in em28xx-cards.c also seem to be different to
> >> the ones used in hauppauge_hvr930c_init() in em28xx-dvb.c...
> > I'm not telling that the entries there are right. They aren't. If they
> > where working, that data there weren't commented. This device entry
> > started with a clone from Terratec H5, which was the first em28xx
> > device with DRX-K.
> >
> > On Terratec H5, the tuner is different (based on tda8290/tda8275).
> > The current device initialization started as a clone of the code
> > under terratec_h5_init().
> >
> > As it worked like that, the patch author that added support for HVR-930
> > likely didn't touch on it.
>
> :-/
> So the whole code for these devices is basically a quick and dirty hack.
Yes.
> I also checked the init sequences in em28xx-dvb.c and the GPIO sequences
> and board parameters which are currently commented out...
>
> No, thank you, I'm not going to touch this under the current circumstances !
Again, it is up to you to do whatever you want with your time ;)
The hack works, so there's no real need to fix it, although doing it
might save some power if the analog demod is turned on while in
digital mode.
> What I'm still going to do is to remove at least these writes to reg
> 0x06 in em28xx-dvb.c.
Ok.
> >
> > The tuner for HVR930C is clearly at 0x61 address, as it can be seen at
> > em28xx-dvb:
> >
> > /* Attach xc5000 */
> > memset(&cfg, 0, sizeof(cfg));
> > cfg.i2c_address = 0x61;
> > cfg.if_khz = 4000;
> >
> > if (dvb->fe[0]->ops.i2c_gate_ctrl)
> > dvb->fe[0]->ops.i2c_gate_ctrl(dvb->fe[0], 1);
> > if (!dvb_attach(xc5000_attach, dvb->fe[0],
> > &dev->i2c_adap[dev->def_i2c_bus],
> > &cfg)) {
> > result = -EINVAL;
> > goto out_free;
> > }
> >
> >> Are you sure this will work for _all_ variants of the HVR-930C ?
> > Well, the current code will only work with a HVR-930C with a xc5000 tuner,
> > a drx-k demod and an em28xx (and an avf4910b analog TV demod).
> >
> > Any other model with a different layout, if are there any, won't work
> > anyway.
> >
> > While we can't discard that a different model might have a different GPIO
> > setting, Hauppauge tends to keep the GPIO settings equal for t
Re: [PATCH 0/3] em28xx: add support for two buses on em2874 and upper
Am 02.04.2013 02:48, schrieb Devin Heitmueller: > On Mon, Apr 1, 2013 at 6:14 PM, Mauro Carvalho Chehab > wrote: >> In time, I meant to say: >> "So, it seems very unlikely that any change here will keep it >> working for >> model 16009 while breaking it for other HVR-930 devices." > As far as I know, there's only ever been one em28xx/drxk variant of > the 930c. And since it was obsoleted a while ago I don't see any > reason you will see any minor revisions of this board design in the > future (the current design uses the cx231xx). Are the em28xx devices model 16xxx and the newer cx231xx devices model 111xxx ? Frank > > Devin > -- 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 0/3] em28xx: add support for two buses on em2874 and upper
Am 02.04.2013 00:12, schrieb Mauro Carvalho Chehab: > Em Mon, 01 Apr 2013 22:39:28 +0200 > Frank Schäfer escreveu: > >> Am 01.04.2013 21:22, schrieb Mauro Carvalho Chehab: >>> Em Mon, 01 Apr 2013 19:14:03 +0200 >>> Frank Schäfer escreveu: >>> Am 18.03.2013 22:22, schrieb Mauro Carvalho Chehab: > Em Wed, 06 Mar 2013 18:44:07 +0100 > Frank Schäfer escreveu: > >> Am 05.03.2013 16:43, schrieb Devin Heitmueller: >>> 2013/3/5 Mauro Carvalho Chehab : The em2874 chips and upper have 2 buses. On all known devices, bus 0 is currently used only by eeprom, and bus 1 for the rest. Add support to register both buses. >>> Did you add a mutex to ensure that both buses cannot be used at the >>> same time? Because using the bus requires you to toggle a register >>> (thus you cannot be using both busses at the same time), you cannot >>> rely on the existing i2c adapter lock anymore. >>> >>> You don't want a situation where something is actively talking on bus >>> 0, and then something else tries to talk on bus 1, flips the register >>> bit and then the thread talking on bus 0 starts failing. >>> >>> Devin >> Hmm... there are several writes to EM28XX_R06_I2C_CLK in em28xx-dvb... >> See hauppauge_hvr930c_init(), terratec_h5_init() and >> terratec_htc_stick_init(). >> These functions are called from em28xx_dvb_init() at module init. >> Module init is async, so yes, this is (or could at least become) a >> problem... >> >> I wonder if we can't simply remove all those writes to >> EM28XX_R06_I2C_CLK from em28xx-dvb. >> This is what the functions are doing: >> >> hauppauge_hvr930c_init() >> ... >> em28xx_write_reg(dev, EM28XX_R06_I2C_CLK, 0x40); >> msleep(10); >> em28xx_write_reg(dev, EM28XX_R06_I2C_CLK, 0x44); >> msleep(10); >> ... [init sequence for slave at address 0x82] >> em28xx_write_reg(dev, EM28XX_R06_I2C_CLK, 0x44); >> msleep(30); >> em28xx_write_reg(dev, EM28XX_R06_I2C_CLK, 0x45); >> msleep(10); >> >> terratec_h5_init(): >> ... >> em28xx_write_reg(dev, EM28XX_R06_I2C_CLK, 0x40); >> msleep(10); >> em28xx_write_reg(dev, EM28XX_R06_I2C_CLK, 0x45); >> msleep(10); >> ... >> >> terratec_htc_stick_init() >> ... >> em28xx_write_reg(dev, EM28XX_R06_I2C_CLK, 0x40); >> msleep(10); >> em28xx_write_reg(dev, EM28XX_R06_I2C_CLK, 0x44); >> msleep(10); >> ... >> >> All three boards are using the following settings: >> .i2c_speed= EM2874_I2C_SECONDARY_BUS_SELECT | >> EM28XX_I2C_CLK_WAIT_ENABLE | EM28XX_I2C_FREQ_400_KHZ = 0x45 >> >> So what these functions are doing is >> - switch to bus A and do nothing fo 10ms >> - overwrite board settings for reg 0x06 with a local value (clears >> EM28XX_I2C_FREQ_400_KHZ permanently for the HTC-Stick !). >> >> I can test the HVR-930C next week. Ok, I finally had the chance to test with a HVR-930C, but it seems my device () is different. >> I forgot to insert the device/model of the device I tested: it's 16009, B1F0 > It has the same model as the one I have here. Ok. > It has no slave device at i2c address 0x82, so I can't test this part. Btw, which slave device is this ? > AFAIKT, at address 0x41, there is the analog demod (avf4910b). It is not > used by Digital TV (although I'm not sure if, for this device, it needs > to be initialized or not). > > We don't have enough documentation to write a driver for avf4910b. Some > developers at the ML are trying to implement support for it for HVR-930C: > > http://www.mail-archive.com/linux-media@vger.kernel.org/msg59296.html > > There is a code pointed there for avf4910a: > > https://github.com/wurststulle/ngene_2400i/blob/2377b1fd99d91ff355a5e46881ef27ccc87cb376/avf4910a.c > > Also, maybe to access the avf4910b some different GPIO setting may be needed, > as it might be powered off by the GPIO settings initialized at device i > Yeah, I remember that. Anyway, I don't have time for this at the moment. I also think this is really Hauppauges job. These devices are still expensive (65-100€) but half working only. That's why I'm going to do it with all my Hauppauge devices: wait 5 years and then buy them used for max. 10€. Maybe I'll get back to this if it is still not working then and I find some free time, but no guarantee... ;) > Removing the temporary switches to bus A makes no difference (as expected). > There are some things there on the init sequence that can be > cleaned/removed. Those sequences generally comes from observing > what the original driver does. While it produces a working driver, > in general, it is not optimized and part of the init sequence can > be removed. Do you want me to send patches
cron job: media_tree daily build: ERRORS
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: Tue Apr 2 19:00:23 CEST 2013 git branch: test git hash: f9f11dfe4831adb1531e1face9dcd9fc57665d2e gcc version:i686-linux-gcc (GCC) 4.7.2 host hardware: x86_64 host os:3.8-3.slh.2-amd64 linux-git-arm-davinci: ERRORS linux-git-arm-exynos: ERRORS linux-git-arm-omap: ERRORS linux-git-blackfin: WARNINGS linux-git-i686: OK linux-git-m32r: OK linux-git-mips: ERRORS linux-git-powerpc64: OK linux-git-sh: ERRORS linux-git-x86_64: OK linux-2.6.31.14-i686: WARNINGS linux-2.6.32.27-i686: WARNINGS linux-2.6.33.7-i686: WARNINGS linux-2.6.34.7-i686: WARNINGS linux-2.6.35.9-i686: WARNINGS linux-2.6.36.4-i686: WARNINGS linux-2.6.37.6-i686: WARNINGS linux-2.6.38.8-i686: WARNINGS linux-2.6.39.4-i686: WARNINGS linux-3.0.60-i686: WARNINGS linux-3.1.10-i686: WARNINGS linux-3.2.37-i686: WARNINGS linux-3.3.8-i686: WARNINGS linux-3.4.27-i686: WARNINGS linux-3.5.7-i686: WARNINGS linux-3.6.11-i686: WARNINGS linux-3.7.4-i686: WARNINGS linux-3.8-i686: OK linux-3.9-rc1-i686: OK linux-2.6.31.14-x86_64: WARNINGS linux-2.6.32.27-x86_64: WARNINGS linux-2.6.33.7-x86_64: WARNINGS linux-2.6.34.7-x86_64: WARNINGS linux-2.6.35.9-x86_64: WARNINGS linux-2.6.36.4-x86_64: WARNINGS linux-2.6.37.6-x86_64: WARNINGS linux-2.6.38.8-x86_64: WARNINGS linux-2.6.39.4-x86_64: WARNINGS linux-3.0.60-x86_64: WARNINGS linux-3.1.10-x86_64: WARNINGS linux-3.2.37-x86_64: WARNINGS linux-3.3.8-x86_64: WARNINGS linux-3.4.27-x86_64: WARNINGS linux-3.5.7-x86_64: WARNINGS linux-3.6.11-x86_64: WARNINGS linux-3.7.4-x86_64: WARNINGS linux-3.8-x86_64: WARNINGS linux-3.9-rc1-x86_64: WARNINGS apps: WARNINGS spec-git: OK sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.tar.bz2 The Media Infrastructure API 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 v2 2/3] mutex: add support for reservation style locks, v2
On Tue, Apr 2, 2013 at 6:59 PM, Peter Zijlstra wrote: >> > Also, is there anything in CS literature that comes close to this? I'd >> > think the DBMS people would have something similar with their >> > transactional systems. What do they call it? > >> I didn't study cs, but judging from your phrasing I guess you mean you >> want me to call it transaction_mutexes instead? > > Nah, me neither, I just hate reinventing names for something that's > already got a perfectly fine name under which a bunch of people know > it. > > See the email from Daniel, apparently its known as wound-wait deadlock > avoidance -- its actually described in the "deadlock" wikipedia > article. > > So how about we call the thing something like: > > struct ww_mutex; /* wound/wait */ > > int mutex_wound_lock(struct ww_mutex *); /* returns -EDEADLK */ > int mutex_wait_lock(struct ww_mutex *); /* does not fail */ I'm not sold on this prefix, since wound-wait is just the implementation detail of how it detects/handles deadlocks. For users a really dumb strategy of just doing a mutex trylock and always returning -EAGAIN if that fails (together with a msleep(rand) in the slowpath) would have the same interface. Almost at least, we could ditch the ticket - but the ticket is used as a virtual lock for the lockdep annotation, so ditching it would also reduce lockdep usefulness (due to all those trylocks). So in case we ever switch the deadlock/backoff algo ww_ would be a bit misleading. Otoh reservation_ is just what it's used for in graphics-land, so not that much better. I don't really have a good idea for what this is besides mutexes_with_magic_deadlock_detection_and_backoff. Which is a bit long. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- 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: [GIT PULL FOR 3.10] Media DT bindings and V4L2 OF parsing library
On 03/29/2013 09:22 PM, Rob Herring wrote: > On 03/29/2013 12:39 PM, Sylwester Nawrocki wrote: >> > Mauro, >> > >> > This includes two patches adding device tree support at the V4L2 API. >> > I added Rob and Grant at Cc in case they still wanted to comment on >> > those patches. Not sure what the exact policy is but I guess we need >> > an explicit DT maintainer's Ack on stuff like this. > > Bindings regularly go in without Grant's or my ack simply because there > are too many to keep up with and it really requires knowledge of the > particular h/w being described. OK, I suspected the high volume of patches might be of an issue. Anyway, I find the devicetree mailing list one of the most interesting, since the discussions there are fairly diverse, touching various subsystems. > I've skimmed thru this one on several versions and nothing concerning > jumps out. So I think it is good to go in. Thanks, it's now queued in the media tree for 3.10. -- 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 v2 2/3] mutex: add support for reservation style locks, v2
On Tue, Apr 2, 2013 at 6:59 PM, Peter Zijlstra wrote: >> > Head hurts, needs more time to ponder. It would be good if someone else >> > (this would probably be you maarten) would also consider this explore >> > this 'interesting' problem space :-) > >> My head too, evil priority stuff! >> >> Hacky but pragmatical workaround for now: use a real mutex around all >> the reserve_mutex_lock* calls instead of a virtual lock. It can be >> unlocked as soon as all locks have been taken, before any actual work >> is done. >> >> It only slightly kills the point of having a reservation in the first >> place, but at least it won't break completely -rt completely for now. > > Yeah, global lock, yay :-( We've discussed this quite a bit on irc and came up with a bunch of other ideas. The global lock is completely transparent to users, since the lockdep annotations already rely on ticket_init/fini being a virtual lock. So we can always fall back to that option. For more fancy approaches we need to consider the aim first - do we just want to prevent deadlocks through PI or do we aim for bounded per-reservation_mutex wait block-to-acquire times for the thread with highest rt-prio. If it's just the former I think we can get by by piggy-packing on top of the existing PI mutex code. Only downside is that threads can lock arbitrary many reservation locks and so we're looking at boosting an entire tree of processes. Otoh common operations done while holding such a lock are swapping buffer objects in or waiting for gpu rendering. And since we can easily queue up a few ms of rendering rt guarantees are out the window ;-) If that's not good enough and the global lock not scalable enough we could try to limit the fan-out by setting a PI-boost flag in the reservation ticket (in additional to the normal PI boosting for the reservation mutex). Threads which are boosted in that fashion will get a -EAGAIN on the next mutex_reserv_lock call, ensuring that the blocking doesn't spread to further threads. But that requires that we pass around pointers to tickets instead of values, so lifetime fun (atm the ticket is on the stack) and probably tons of races in updating the ticket boost state. I'd like to avoid that until we've demonstrated a need for it ... In any way I think that all three approaches should fit into the proposed interfaces, so we should be able to do something sane here. But since I have pretty much zero clue about rt I have no idea which of the first two approaches would be preferable. Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- 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
soc-camera: last call for 3.10
Hi These are the patches that I've got in my 3.10 soc-camera queue. Please, ping me if any are missing. I'll be pushing these some time later this week. Fabio Porcedda (2): drivers: media: use module_platform_driver_probe() mx2_camera: use module_platform_driver_probe() Guennadi Liakhovetski (1): soc-camera: protect against racing open(2) and rmmod Phil Edworthy (1): soc_camera: Add RGB666 & RGB888 formats Tushar Behera (1): atmel-isi: Update error check for unsigned variables 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: [PATCH v2 2/3] mutex: add support for reservation style locks, v2
On Tue, 2013-04-02 at 16:57 +0200, Maarten Lankhorst wrote:
> Hey,
>
> Thanks for reviewing.
Only partway through so far :-)
> Op 02-04-13 13:00, Peter Zijlstra schreef:
> > On Thu, 2013-02-28 at 11:25 +0100, Maarten Lankhorst wrote:
> >> +Reservation type mutexes
> >> +struct ticket_mutex {
> >> +extern int __must_check _mutex_reserve_lock(struct ticket_mutex *lock,
> > That's two different names and two different forms of one (for a total
> > of 3 variants) for the same scheme.
> >
> > FAIL...
> It's been hard since I haven't seen anything similar in the kernel, I
> originally went with tickets since that's what ttm originally called
> it, and tried to kill as many references as I could when I noticed
> ticket mutexes already being taken.
Ticket mutexes as such don't exist, but we have ticket based spinlock
implementations. It seems a situation ripe for confusion to have two
locking primitives (mutex, spinlock) with similar names (ticket) but
vastly different semantics.
> I'll fix up the ticket_mutex -> reservation_mutex, and mutex_reserve_*
> -> reserve_mutex_*
Do a google for "lock reservation" and observe the results.. its some
scheme where they pre-assign lock ownership to the most likely thread.
> > On Thu, 2013-02-28 at 11:25 +0100, Maarten Lankhorst wrote:
> >> +mutex_reserve_lock_slow and mutex_reserve_lock_intr_slow:
> >> + Similar to mutex_reserve_lock, except it won't backoff with
> >> -EAGAIN.
> >> + This is useful when mutex_reserve_lock failed with -EAGAIN, and you
> >> + unreserved all reservation_locks so no deadlock can occur.
> >> +
> > I don't particularly like these function names, with lock
> > implementations the _slow post-fix is typically used for slow path
> > implementations, not API type interfaces.
> I didn't intend for drivers to use the new calls directly, but rather
> through a wrapper, for example by ttm_eu_reserve_buffers in
> drivers/gpu/drm/ttm/ttm_execbuf_util.c
You're providing a generic interface to the core kernel, other people
will end up using it. Providing a proper API is helpful.
> > Also, is there anything in CS literature that comes close to this? I'd
> > think the DBMS people would have something similar with their
> > transactional systems. What do they call it?
> I didn't study cs, but judging from your phrasing I guess you mean you
> want me to call it transaction_mutexes instead?
Nah, me neither, I just hate reinventing names for something that's
already got a perfectly fine name under which a bunch of people know
it.
See the email from Daniel, apparently its known as wound-wait deadlock
avoidance -- its actually described in the "deadlock" wikipedia
article.
So how about we call the thing something like:
struct ww_mutex; /* wound/wait */
int mutex_wound_lock(struct ww_mutex *); /* returns -EDEADLK */
int mutex_wait_lock(struct ww_mutex *); /* does not fail */
Hmm.. thinking about that,.. you only need that second variant because
you don't have a clear lock to wait for the 'older' process to
complete; but having the unconditional wait makes the entire thing
prone to accidents and deadlocks when the 'user' (read your fellow
programmers) make a mistake.
Ideally we'd only have the one primitive that returns -EDEADLK and use
a 'proper' mutex to wait on or somesuch.. let me ponder this a bit more.
> > Head hurts, needs more time to ponder. It would be good if someone else
> > (this would probably be you maarten) would also consider this explore
> > this 'interesting' problem space :-)
> My head too, evil priority stuff!
>
> Hacky but pragmatical workaround for now: use a real mutex around all
> the reserve_mutex_lock* calls instead of a virtual lock. It can be
> unlocked as soon as all locks have been taken, before any actual work
> is done.
>
> It only slightly kills the point of having a reservation in the first
> place, but at least it won't break completely -rt completely for now.
Yeah, global lock, yay :-(
--
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] DT: export of_get_next_parent() for use by modules: fix modular V4L2
On Tue, 2 Apr 2013, Arnd Bergmann wrote: > On Tuesday 02 April 2013, Guennadi Liakhovetski wrote: > > Currently modular V4L2 build with enabled OF is broken dur to the > > of_get_next_parent() function being unavailable to modules. Export it to > > fix the build. > > > > Cc: Sylwester Nawrocki > > Signed-off-by: Guennadi Liakhovetski > > Looks good to me, but shouldn't this be EXPORT_SYMBOL_GPL? "grep EXPORT_SYMBOL drivers/of/base.c" doesn't give a certain answer, but it seems to fit other of_get_* functions pretty well: EXPORT_SYMBOL(of_get_parent); +EXPORT_SYMBOL(of_get_next_parent); EXPORT_SYMBOL(of_get_next_child); EXPORT_SYMBOL(of_get_next_available_child); EXPORT_SYMBOL(of_get_child_by_name); 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: Terratec Grabby hwrev 2
Am 02.04.2013 07:43, schrieb Timo Teras: > On Mon, 01 Apr 2013 19:26:53 +0200 > Frank Schäfer wrote: > >> Am 30.03.2013 10:54, schrieb Timo Teras: >>> On Thu, 28 Mar 2013 12:22:52 -0300 >>> Mauro Carvalho Chehab wrote: >>> > On the W7 driver, I don't get any of the above mentioned problems. > > I looked at the saa7113 register init sequence, and copied that > over to linux saa7113 init, but that did not remove the problems. > There were only few changes. So, maybe it does a different crop setup at em28xx. >>> I did an analysis of the register setups of em28xx and found the >>> following differences: >>> >>> 1. Different crop settings >>> >>> EM28XX_R1D_VSTART, EM28XX_R1F_CHEIGHT and EM28XX_R2B_YMAX set by W7 >>> driver were divided by two compared to the linux driver. Seems that >>> linux driver did just this before commit c2a6b54. I also found the >>> patch https://patchwork.kernel.org/patch/1272051/ to restore the >>> original behaviour, but somehow it was disregarded and commit >>> 0bc9c89 was done instead. The mentioned patch though does not fix >>> R1D setting though. >> Can you post the settings the Windows driver uses for these >> registers ? Don't worry about registers 0x28-0x2B, different values >> shouldn' matter. See >> http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/57039. > Yes, it would seem registers 0x28-0x2B do not have great significance > in the video we get out of it. > > The full sequence the W7 driver does for PAL video is: > > EM28XX_R20_YGAIN0x00 > EM28XX_R22_UVGAIN 0x00 > EM28XX_R06_I2C_CLK 0x40 > EM28XX_R15_RGAIN0x20 > EM28XX_R16_GGAIN0x20 > EM28XX_R17_BGAIN0x20 > EM28XX_R18_ROFFSET 0x00 > EM28XX_R19_GOFFSET 0x00 > EM28XX_R1A_BOFFSET 0x00 > EM28XX_R23_UOFFSET 0x00 > EM28XX_R24_VOFFSET 0x00 > EM28XX_R26_COMPR0x00 > EM28XX_R13_??? 0x08 (Note: we do not set this at all) I've seen this write to reg 0x13 with my webcams, too. Unfortunately, we don't know what it means. But according to my tests, it is not needed. > EM28XX_R27_OUTFMT 0x34 > EM28XX_R10_VINMODE 0x00 We set vinmode to 0x10 (see em28xx_init_dev() in em28xx-cards.c). No idea what the values mean. Might be worth testing with 0x00. > EM28XX_R28_XMIN 0x01 > EM28XX_R29_XMAX 0xB3 > EM28XX_R2A_YMIN 0x01 > EM28XX_R2B_YMAX 0x47 (We set 0x8e, i think) Yes, we set to EM28XX_R2B_YMAX to 0x8f, the other values are the same as used by the driver. 0x47 is 0x8f / 2, so what the Windows driver seems to do here is to use the field height instead of the image height (interlaced mode) which is the same what we did in the past in our driver. Anyway, some other device like the MSI DigiVox ATSC (PAL or NTSC ?, interlaced), Silvercrest webcam 1.3MPix (640x480, progressive) use the following values: 0x01, 0xFF, 0x01, 0xFF. And the Speedlink VAD Laplace webcam for example uses the following values: 0x1B, 0x83, 0x13, 0x63(320x240, 640x480, progressive) 0x6B, 0xD3, 0x57, 0xA7(1280x1024, progressive) 0x93, 0xFB, 0x6D, 0xBD(1600x1200, progressive) So which formula should we use ? Suggestions ? ;) As said before, we didn't notice any difference in the device behavior when changing the values so far. So let's stay with the current formula. > EM28XX_R1C_HSTART 0x00 > EM28XX_R1D_VSTART 0x01 (We set 0x02) In VBI mode, yes, without VBI we use 0x00. I don't know if a 1 Pixel offset makes a big difference. But looking at the comment in em28xx_resolution_set(), an offset of 2 pixels seems to make a bigger difference for VBI devices, which makes my alert bells ringing... > EM28XX_R1E_CWIDTH 0xB4 > EM28XX_R1F_CHEIGHT 0x48 (We set 0x8f, or 0x90) Are you sure that 0x48 is used for PAL ? Which resolution does the Windows driver claim too use ? All USB-logs from the various devices I've seen so far match what we do in the driver (0x90). > EM28XX_R1B_OFLOW0x00 > > (Tuner and AC97 config takes place here) > > EM28XX_R0E_AUDIOSRC 0x8f > EM28XX_R21_YOFFSET 0x08 (We set 0x10) This is the "brightness" value... > EM28XX_R20_YGAIN0x10 > EM28XX_R22_UVGAIN 0x10 > EM28XX_R14_GAMMA0x32 (We set 0x20) > EM28XX_R25_SHARPNESS0x02 (We set 0x00) ... and these are the "Gamma" and "Sharpness" values. The Windows driver uses different image quality settings for different devices, while our em28xx driver uses a single (common) set of values. > EM28XX_R26_COMPR0x00 > EM28XX_R27_OUTFMT 0x34 > EM28XX_R11_VINCTRL 0x11 > EM28XX_R1B_OFLOW0x00 > EM28XX_R12_VINENABLE0x67 > EM28XX_R22_UVGAIN 0x10 > EM28XX_R20_YGAIN0x10 > EM28XX_R0E_AUDIOSRC 0x8f > > >>> 2. Different outfmt used >>> >>> It seems that ffmpeg defaults to v4l default, which somehow >>> apparently resulted in EM28XX_OUTFMT_RGB_8_RGRG set. When forcing >>> ffmpeg to set yuyv422 or EM28XX_OUTFMT_YUV422_Y0U
Re: [PATCH] DT: export of_get_next_parent() for use by modules: fix modular V4L2
On Tuesday 02 April 2013, Guennadi Liakhovetski wrote: > Currently modular V4L2 build with enabled OF is broken dur to the > of_get_next_parent() function being unavailable to modules. Export it to > fix the build. > > Cc: Sylwester Nawrocki > Signed-off-by: Guennadi Liakhovetski Looks good to me, but shouldn't this be EXPORT_SYMBOL_GPL? Arnd -- 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] DT: export of_get_next_parent() for use by modules: fix modular V4L2
Currently modular V4L2 build with enabled OF is broken dur to the of_get_next_parent() function being unavailable to modules. Export it to fix the build. Cc: Sylwester Nawrocki Signed-off-by: Guennadi Liakhovetski --- This is for 3.10 drivers/of/base.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/of/base.c b/drivers/of/base.c index 321d3ef..1733081 100644 --- a/drivers/of/base.c +++ b/drivers/of/base.c @@ -382,6 +382,7 @@ struct device_node *of_get_next_parent(struct device_node *node) raw_spin_unlock_irqrestore(&devtree_lock, flags); return parent; } +EXPORT_SYMBOL(of_get_next_parent); /** * of_get_next_child - Iterate a node childs -- 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 v4 7/7] exynos4-is: Create media links for the FIMC-IS entities
Create disabled links from the FIMC-LITE subdevs to the FIMC-IS-ISP
subdev and from FIMC-IS-ISP to all FIMC subdevs.
Signed-off-by: Sylwester Nawrocki
Signed-off-by: Kyungmin Park
---
drivers/media/platform/exynos4-is/media-dev.c | 79 +++--
1 file changed, 60 insertions(+), 19 deletions(-)
diff --git a/drivers/media/platform/exynos4-is/media-dev.c
b/drivers/media/platform/exynos4-is/media-dev.c
index 597648e..44d6c1d 100644
--- a/drivers/media/platform/exynos4-is/media-dev.c
+++ b/drivers/media/platform/exynos4-is/media-dev.c
@@ -838,12 +838,19 @@ static int __fimc_md_create_fimc_sink_links(struct
fimc_md *fmd,
struct v4l2_subdev *sensor,
int pad, int link_mask)
{
- struct fimc_sensor_info *s_info = NULL;
+ struct fimc_sensor_info *si = NULL;
struct media_entity *sink;
unsigned int flags = 0;
- int ret, i;
+ int i, ret = 0;
- for (i = 0; i < FIMC_MAX_DEVS; i++) {
+ if (sensor) {
+ si = v4l2_get_subdev_hostdata(sensor);
+ /* Skip direct FIMC links in the logical FIMC-IS sensor path */
+ if (si && si->pdata.fimc_bus_type ==
FIMC_BUS_TYPE_ISP_WRITEBACK)
+ ret = 1;
+ }
+
+ for (i = 0; !ret && i < FIMC_MAX_DEVS; i++) {
if (!fmd->fimc[i])
continue;
/*
@@ -872,11 +879,11 @@ static int __fimc_md_create_fimc_sink_links(struct
fimc_md *fmd,
if (flags == 0 || sensor == NULL)
continue;
- s_info = v4l2_get_subdev_hostdata(sensor);
- if (!WARN_ON(s_info == NULL)) {
+
+ if (!WARN_ON(si == NULL)) {
unsigned long irq_flags;
spin_lock_irqsave(&fmd->slock, irq_flags);
- s_info->host = fmd->fimc[i];
+ si->host = fmd->fimc[i];
spin_unlock_irqrestore(&fmd->slock, irq_flags);
}
}
@@ -885,25 +892,20 @@ static int __fimc_md_create_fimc_sink_links(struct
fimc_md *fmd,
if (!fmd->fimc_lite[i])
continue;
- if (link_mask & (1 << (i + FIMC_MAX_DEVS)))
- flags = MEDIA_LNK_FL_ENABLED;
- else
- flags = 0;
-
sink = &fmd->fimc_lite[i]->subdev.entity;
ret = media_entity_create_link(source, pad, sink,
- FLITE_SD_PAD_SINK, flags);
+ FLITE_SD_PAD_SINK, 0);
if (ret)
return ret;
/* Notify FIMC-LITE subdev entity */
ret = media_entity_call(sink, link_setup, &sink->pads[0],
- &source->pads[pad], flags);
+ &source->pads[pad], 0);
if (ret)
break;
- v4l2_info(&fmd->v4l2_dev, "created link [%s] %c> [%s]\n",
- source->name, flags ? '=' : '-', sink->name);
+ v4l2_info(&fmd->v4l2_dev, "created link [%s] -> [%s]\n",
+ source->name, sink->name);
}
return 0;
}
@@ -912,21 +914,50 @@ static int __fimc_md_create_fimc_sink_links(struct
fimc_md *fmd,
static int __fimc_md_create_flite_source_links(struct fimc_md *fmd)
{
struct media_entity *source, *sink;
- unsigned int flags = MEDIA_LNK_FL_ENABLED;
int i, ret = 0;
for (i = 0; i < FIMC_LITE_MAX_DEVS; i++) {
struct fimc_lite *fimc = fmd->fimc_lite[i];
+
if (fimc == NULL)
continue;
+
source = &fimc->subdev.entity;
sink = &fimc->vfd.entity;
/* FIMC-LITE's subdev and video node */
ret = media_entity_create_link(source, FLITE_SD_PAD_SOURCE_DMA,
- sink, 0, flags);
+ sink, 0, 0);
+ if (ret)
+ break;
+ /* Link from FIMC-LITE to IS-ISP subdev */
+ sink = &fmd->fimc_is->isp.subdev.entity;
+ ret = media_entity_create_link(source, FLITE_SD_PAD_SOURCE_ISP,
+ sink, 0, 0);
if (ret)
break;
- /* TODO: create links to other entities */
+ }
+
+ return ret;
+}
+
+/* Create FIMC-IS links */
+static int __fimc_md_create_fimc_is_links(struct fimc_md *fmd)
+{
+ struct media_entity *source, *sink;
+ int i, ret;
+
+ source = &fmd->fimc_is->isp.subdev.entity;
+
+ for (i = 0; i < FIMC_MAX_DEVS; i++) {
+ if (fmd->fimc[i] == NULL)
+
[PATCH v4 6/7] exynos4-is: Add fimc-is subdevs registration
This patch allows to register FIMC-IS device represented by FIMC-IS-ISP
subdev to the top level media device driver. The use_isp platform data
structure field allows to select whether the fimc-is ISP subdev should
be tried to be registered or not.
Signed-off-by: Sylwester Nawrocki
Signed-off-by: Andrzej Hajda
Signed-off-by: Kyungmin Park
---
drivers/media/platform/exynos4-is/media-dev.c | 37 +++--
drivers/media/platform/exynos4-is/media-dev.h | 13 +
2 files changed, 47 insertions(+), 3 deletions(-)
diff --git a/drivers/media/platform/exynos4-is/media-dev.c
b/drivers/media/platform/exynos4-is/media-dev.c
index a0fd8cc..597648e 100644
--- a/drivers/media/platform/exynos4-is/media-dev.c
+++ b/drivers/media/platform/exynos4-is/media-dev.c
@@ -32,6 +32,7 @@
#include "media-dev.h"
#include "fimc-core.h"
+#include "fimc-is.h"
#include "fimc-lite.h"
#include "mipi-csis.h"
@@ -85,9 +86,11 @@ static void fimc_pipeline_prepare(struct fimc_pipeline *p,
case GRP_ID_FIMC:
/* No need to control FIMC subdev through subdev ops */
break;
+ case GRP_ID_FIMC_IS:
+ p->subdevs[IDX_IS_ISP] = sd;
+ break;
default:
- pr_warn("%s: Unknown subdev grp_id: %#x\n",
- __func__, sd->grp_id);
+ break;
}
me = &sd->entity;
if (me->num_pads == 1)
@@ -322,6 +325,7 @@ static void fimc_md_unregister_sensor(struct v4l2_subdev
*sd)
if (!client)
return;
+
v4l2_device_unregister_subdev(sd);
if (!client->dev.of_node) {
@@ -372,7 +376,11 @@ static int fimc_md_of_add_sensor(struct fimc_md *fmd,
goto mod_put;
v4l2_set_subdev_hostdata(sd, si);
- sd->grp_id = GRP_ID_SENSOR;
+ if (si->pdata.fimc_bus_type == FIMC_BUS_TYPE_ISP_WRITEBACK)
+ sd->grp_id = GRP_ID_FIMC_IS_SENSOR;
+ else
+ sd->grp_id = GRP_ID_SENSOR;
+
si->subdev = sd;
v4l2_info(&fmd->v4l2_dev, "Registered sensor subdevice: %s (%d)\n",
sd->name, fmd->num_sensors);
@@ -652,6 +660,22 @@ static int register_csis_entity(struct fimc_md *fmd,
return ret;
}
+static int register_fimc_is_entity(struct fimc_md *fmd, struct fimc_is *is)
+{
+ struct v4l2_subdev *sd = &is->isp.subdev;
+ int ret;
+
+ ret = v4l2_device_register_subdev(&fmd->v4l2_dev, sd);
+ if (ret) {
+ v4l2_err(&fmd->v4l2_dev,
+"Failed to register FIMC-ISP (%d)\n", ret);
+ return ret;
+ }
+
+ fmd->fimc_is = is;
+ return 0;
+}
+
static int fimc_md_register_platform_entity(struct fimc_md *fmd,
struct platform_device *pdev,
int plat_entity)
@@ -679,6 +703,9 @@ static int fimc_md_register_platform_entity(struct fimc_md
*fmd,
case IDX_CSIS:
ret = register_csis_entity(fmd, pdev, drvdata);
break;
+ case IDX_IS_ISP:
+ ret = register_fimc_is_entity(fmd, drvdata);
+ break;
default:
ret = -ENODEV;
}
@@ -742,6 +769,8 @@ static int fimc_md_register_of_platform_entities(struct
fimc_md *fmd,
/* If driver of any entity isn't ready try all again later. */
if (!strcmp(node->name, CSIS_OF_NODE_NAME))
plat_entity = IDX_CSIS;
+ else if (!strcmp(node->name, FIMC_IS_OF_NODE_NAME))
+ plat_entity = IDX_IS_ISP;
else if (!strcmp(node->name, FIMC_LITE_OF_NODE_NAME))
plat_entity = IDX_FLITE;
else if (!strcmp(node->name, FIMC_OF_NODE_NAME) &&
@@ -1308,6 +1337,8 @@ static int fimc_md_probe(struct platform_device *pdev)
v4l2_dev->notify = fimc_sensor_notify;
strlcpy(v4l2_dev->name, "s5p-fimc-md", sizeof(v4l2_dev->name));
+ fmd->use_isp = fimc_md_is_isp_available(dev->of_node);
+
ret = v4l2_device_register(dev, &fmd->v4l2_dev);
if (ret < 0) {
v4l2_err(v4l2_dev, "Failed to register v4l2_device: %d\n", ret);
diff --git a/drivers/media/platform/exynos4-is/media-dev.h
b/drivers/media/platform/exynos4-is/media-dev.h
index 1d5cea5..0b14cd5 100644
--- a/drivers/media/platform/exynos4-is/media-dev.h
+++ b/drivers/media/platform/exynos4-is/media-dev.h
@@ -12,6 +12,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -80,6 +81,7 @@ struct fimc_sensor_info {
* @num_sensors: actual number of registered sensors
* @camclk: external sensor clock information
* @fimc: array of registered fimc devices
+ * @fimc_is: fimc-is data structure
[PATCH v4 5/7] exynos4-is: Add Exynos4x12 FIMC-IS device tree binding documentation
This patch adds DT binding documentaton for the Imaging Subsystem (camera ISP) found on Samsung Exynos4x12 SoCs. Signed-off-by: Sylwester Nawrocki Signed-off-by: Kyungmin Park --- Changes since v3: - specified order of the interrupts, - added a note about image sensor device nodes. Changes since v2: - added missing clocks at the binding documentation; - added clocks/clock-names properties to isp-i2c node. --- .../devicetree/bindings/media/exynos4-fimc-is.txt | 49 1 file changed, 49 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/exynos4-fimc-is.txt diff --git a/Documentation/devicetree/bindings/media/exynos4-fimc-is.txt b/Documentation/devicetree/bindings/media/exynos4-fimc-is.txt new file mode 100644 index 000..55c9ad6 --- /dev/null +++ b/Documentation/devicetree/bindings/media/exynos4-fimc-is.txt @@ -0,1 +1,49 @@ +Exynos4x12 SoC series Imaging Subsystem (FIMC-IS) + +The FIMC-IS is a subsystem for processing image signal from an image sensor. +The Exynos4x12 SoC series FIMC-IS V1.5 comprises of a dedicated ARM Cortex-A5 +processor, ISP, DRC and FD IP blocks and peripheral devices such as UART, I2C +and SPI bus controllers, PWM and ADC. + +fimc-is node + + +Required properties: +- compatible : should be "samsung,exynos4212-fimc-is" for Exynos4212 and + Exynos4412 SoCs; +- reg : physical base address and length of the registers set; +- interrupts : must contain two FIMC-IS interrupts, in order: ISP0, ISP1; +- clocks : list of clock specifiers, corresponding to entries in + clock-names property; +- clock-names : must contain "ppmuispx", "ppmuispx", "lite0", "lite1" + "mpll", "sysreg", "isp", "drc", "fd", "mcuisp", "uart", + "ispdiv0", "ispdiv1", "mcuispdiv0", "mcuispdiv1", "aclk200", + "div_aclk200", "aclk400mcuisp", "div_aclk400mcuisp" entries, + matching entries in the clocks property. +pmu subnode +--- + +Required properties: + - reg : must contain PMU physical base address and size of the register set. + +The following are the FIMC-IS peripheral device nodes and can be specified +either standalone or as the fimc-is node child nodes. + +i2c-isp (ISP I2C bus controller) nodes +-- + +Required properties: + +- compatible : should be "samsung,exynos4212-i2c-isp" for Exynos4212 and + Exynos4412 SoCs; +- reg : physical base address and length of the registers set; +- clocks : must contain gate clock specifier for this controller; +- clock-names : must contain "i2c_isp" entry. + +For the above nodes it is required to specify a pinctrl state named "default", +according to the pinctrl bindings defined in ../pinctrl/pinctrl-bindings.txt. + +Device tree nodes of the image sensors controlled directly by the FIMC-IS +firmware must be child nodes of their corresponding ISP I2C bus controller node. +The data link of these image sensors must be specified using the common video +interfaces bindings, defined in video-interfaces.txt. -- 1.7.9.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 v4 4/7] exynos4-is: Add common FIMC-IS image sensor driver
This patch adds a common image sensor driver and Makefile/Kconfig
to enable cpmpilation of the whole IS drives.
The sensor subdev driver currently only handles an image sensor's
power supplies and reset signal. There is no an I2C communication
as it is handled by the ISP's firmware.
Signed-off-by: Sylwester Nawrocki
Signed-off-by: Kyungmin Park
---
Changes since v3:
- dropped unused headers.
---
drivers/media/platform/exynos4-is/Kconfig | 11 +
drivers/media/platform/exynos4-is/Makefile |3 +
drivers/media/platform/exynos4-is/fimc-is-sensor.c | 322
drivers/media/platform/exynos4-is/fimc-is-sensor.h | 83 +
4 files changed, 419 insertions(+)
create mode 100644 drivers/media/platform/exynos4-is/fimc-is-sensor.c
create mode 100644 drivers/media/platform/exynos4-is/fimc-is-sensor.h
diff --git a/drivers/media/platform/exynos4-is/Kconfig
b/drivers/media/platform/exynos4-is/Kconfig
index 0ffb6a4..57e9c7e 100644
--- a/drivers/media/platform/exynos4-is/Kconfig
+++ b/drivers/media/platform/exynos4-is/Kconfig
@@ -51,4 +51,15 @@ config VIDEO_EXYNOS_FIMC_LITE
module will be called exynos-fimc-lite.
endif
+config VIDEO_EXYNOS4_FIMC_IS
+ tristate "EXYNOS4x12 FIMC-IS (Imaging Subsystem) driver"
+ select VIDEOBUF2_DMA_CONTIG
+ depends on OF
+ help
+ This is a V4L2 driver for Samsung EXYNOS4x12 SoC series
+ FIMC-IS (Imaging Subsystem).
+
+ To compile this driver as a module, choose M here: the
+ module will be called exynos4-fimc-is.
+
endif # VIDEO_SAMSUNG_S5P_FIMC
diff --git a/drivers/media/platform/exynos4-is/Makefile
b/drivers/media/platform/exynos4-is/Makefile
index 8c67441..f25f463 100644
--- a/drivers/media/platform/exynos4-is/Makefile
+++ b/drivers/media/platform/exynos4-is/Makefile
@@ -1,7 +1,10 @@
s5p-fimc-objs := fimc-core.o fimc-reg.o fimc-m2m.o fimc-capture.o media-dev.o
exynos-fimc-lite-objs += fimc-lite-reg.o fimc-lite.o
+exynos-fimc-is-objs := fimc-is.o fimc-isp.o fimc-is-sensor.o fimc-is-regs.o
+exynos-fimc-is-objs += fimc-is-param.o fimc-is-errno.o fimc-is-i2c.o
s5p-csis-objs := mipi-csis.o
obj-$(CONFIG_VIDEO_S5P_MIPI_CSIS) += s5p-csis.o
obj-$(CONFIG_VIDEO_EXYNOS_FIMC_LITE) += exynos-fimc-lite.o
+obj-$(CONFIG_VIDEO_EXYNOS4_FIMC_IS)+= exynos-fimc-is.o
obj-$(CONFIG_VIDEO_S5P_FIMC) += s5p-fimc.o
diff --git a/drivers/media/platform/exynos4-is/fimc-is-sensor.c
b/drivers/media/platform/exynos4-is/fimc-is-sensor.c
new file mode 100644
index 000..02b2719
--- /dev/null
+++ b/drivers/media/platform/exynos4-is/fimc-is-sensor.c
@@ -0,0 +1,322 @@
+/*
+ * Samsung EXYNOS4x12 FIMC-IS (Imaging Subsystem) driver
+ *
+ * Copyright (C) 2013 Samsung Electronics Co., Ltd.
+ *
+ * Author: Sylwester Nawrocki
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "fimc-is.h"
+#include "fimc-is-sensor.h"
+
+#define DRIVER_NAME "FIMC-IS-SENSOR"
+
+static const char * const sensor_supply_names[] = {
+ "svdda",
+ "svddio",
+};
+
+static const struct v4l2_mbus_framefmt fimc_is_sensor_formats[] = {
+ {
+ .code = V4L2_MBUS_FMT_SGRBG10_1X10,
+ .colorspace = V4L2_COLORSPACE_SRGB,
+ .field = V4L2_FIELD_NONE,
+ }
+};
+
+static struct fimc_is_sensor *sd_to_fimc_is_sensor(struct v4l2_subdev *sd)
+{
+ return container_of(sd, struct fimc_is_sensor, subdev);
+}
+
+static const struct v4l2_mbus_framefmt *find_sensor_format(
+ struct v4l2_mbus_framefmt *mf)
+{
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(fimc_is_sensor_formats); i++)
+ if (mf->code == fimc_is_sensor_formats[i].code)
+ return &fimc_is_sensor_formats[i];
+
+ return &fimc_is_sensor_formats[0];
+}
+
+static int fimc_is_sensor_enum_mbus_code(struct v4l2_subdev *sd,
+ struct v4l2_subdev_fh *fh,
+ struct v4l2_subdev_mbus_code_enum *code)
+{
+ if (code->index >= ARRAY_SIZE(fimc_is_sensor_formats))
+ return -EINVAL;
+
+ code->code = fimc_is_sensor_formats[code->index].code;
+ return 0;
+}
+
+static void fimc_is_sensor_try_format(struct fimc_is_sensor *sensor,
+ struct v4l2_mbus_framefmt *mf)
+{
+ const struct sensor_drv_data *dd = sensor->drvdata;
+ const struct v4l2_mbus_framefmt *fmt;
+
+ fmt = find_sensor_format(mf);
+ mf->code = fmt->code;
+ v4l_bound_align_image(&mf->width, 16 + 8, dd->width, 0,
+ &mf->height, 12 + 8, dd->height, 0, 0);
+}
+
+static struct v4l2_mbus_framefmt *__fimc_is_sensor_get_format(
+ struct
[PATCH v4 3/7] exynos4-is: Add FIMC-IS parameter region definitions
This patch adds ISP processing parameters interface files.
Signed-off-by: Younghwan Joo
Signed-off-by: Sylwester Nawrocki
Signed-off-by: Kyungmin Park
---
Changes since v3:
- dropped unused headers,
- removed get_is_cfg() macro which was temporary only.
---
drivers/media/platform/exynos4-is/fimc-is-param.c | 955 +++
drivers/media/platform/exynos4-is/fimc-is-param.h | 1022 +
2 files changed, 1977 insertions(+)
create mode 100644 drivers/media/platform/exynos4-is/fimc-is-param.c
create mode 100644 drivers/media/platform/exynos4-is/fimc-is-param.h
diff --git a/drivers/media/platform/exynos4-is/fimc-is-param.c
b/drivers/media/platform/exynos4-is/fimc-is-param.c
new file mode 100644
index 000..37fd5fe
--- /dev/null
+++ b/drivers/media/platform/exynos4-is/fimc-is-param.c
@@ -0,0 +1,955 @@
+/*
+ * Samsung EXYNOS4x12 FIMC-IS (Imaging Subsystem) driver
+ *
+ * Copyright (C) 2013 Samsung Electronics Co., Ltd.
+ *
+ * Authors: Younghwan Joo
+ * Sylwester Nawrocki
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#define pr_fmt(fmt) "%s:%d " fmt, __func__, __LINE__
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+#include "fimc-is.h"
+#include "fimc-is-command.h"
+#include "fimc-is-errno.h"
+#include "fimc-is-param.h"
+#include "fimc-is-regs.h"
+#include "fimc-is-sensor.h"
+
+static void __hw_param_copy(void *dst, void *src)
+{
+ memcpy(dst, src, FIMC_IS_PARAM_MAX_SIZE);
+}
+
+void __fimc_is_hw_update_param_global_shotmode(struct fimc_is *is)
+{
+ struct param_global_shotmode *dst, *src;
+
+ dst = &is->is_p_region->parameter.global.shotmode;
+ src = &is->cfg_param[is->scenario_id].global.shotmode;
+ __hw_param_copy(dst, src);
+}
+
+void __fimc_is_hw_update_param_sensor_framerate(struct fimc_is *is)
+{
+ struct param_sensor_framerate *dst, *src;
+
+ dst = &is->is_p_region->parameter.sensor.frame_rate;
+ src = &is->cfg_param[is->scenario_id].sensor.frame_rate;
+ __hw_param_copy(dst, src);
+}
+
+int __fimc_is_hw_update_param(struct fimc_is *is, u32 offset)
+{
+ struct is_param_region *par = &is->is_p_region->parameter;
+ struct is_config_param *cfg = &is->cfg_param[is->scenario_id];
+
+ switch (offset) {
+ case PARAM_ISP_CONTROL:
+ __hw_param_copy(&par->isp.control, &cfg->isp.control);
+ break;
+
+ case PARAM_ISP_OTF_INPUT:
+ __hw_param_copy(&par->isp.otf_input, &cfg->isp.otf_input);
+ break;
+
+ case PARAM_ISP_DMA1_INPUT:
+ __hw_param_copy(&par->isp.dma1_input, &cfg->isp.dma1_input);
+ break;
+
+ case PARAM_ISP_DMA2_INPUT:
+ __hw_param_copy(&par->isp.dma2_input, &cfg->isp.dma2_input);
+ break;
+
+ case PARAM_ISP_AA:
+ __hw_param_copy(&par->isp.aa, &cfg->isp.aa);
+ break;
+
+ case PARAM_ISP_FLASH:
+ __hw_param_copy(&par->isp.flash, &cfg->isp.flash);
+ break;
+
+ case PARAM_ISP_AWB:
+ __hw_param_copy(&par->isp.awb, &cfg->isp.awb);
+ break;
+
+ case PARAM_ISP_IMAGE_EFFECT:
+ __hw_param_copy(&par->isp.effect, &cfg->isp.effect);
+ break;
+
+ case PARAM_ISP_ISO:
+ __hw_param_copy(&par->isp.iso, &cfg->isp.iso);
+ break;
+
+ case PARAM_ISP_ADJUST:
+ __hw_param_copy(&par->isp.adjust, &cfg->isp.adjust);
+ break;
+
+ case PARAM_ISP_METERING:
+ __hw_param_copy(&par->isp.metering, &cfg->isp.metering);
+ break;
+
+ case PARAM_ISP_AFC:
+ __hw_param_copy(&par->isp.afc, &cfg->isp.afc);
+ break;
+
+ case PARAM_ISP_OTF_OUTPUT:
+ __hw_param_copy(&par->isp.otf_output, &cfg->isp.otf_output);
+ break;
+
+ case PARAM_ISP_DMA1_OUTPUT:
+ __hw_param_copy(&par->isp.dma1_output, &cfg->isp.dma1_output);
+ break;
+
+ case PARAM_ISP_DMA2_OUTPUT:
+ __hw_param_copy(&par->isp.dma2_output, &cfg->isp.dma2_output);
+ break;
+
+ case PARAM_DRC_CONTROL:
+ __hw_param_copy(&par->drc.control, &cfg->drc.control);
+ break;
+
+ case PARAM_DRC_OTF_INPUT:
+ __hw_param_copy(&par->drc.otf_input, &cfg->drc.otf_input);
+ break;
+
+ case PARAM_DRC_DMA_INPUT:
+ __hw_param_copy(&par->drc.dma_input, &cfg->drc.dma_input);
+ break;
+
+ case PARAM_DRC_OTF_OUTPUT:
+ __hw_param_copy(&par->drc.otf_output, &cfg->drc.otf_output);
+ break;
+
+ case PARAM_FD_CONTROL:
+ __
[PATCH v4 2/7] exynos4-is: Add FIMC-IS ISP I2C bus driver
This patch adds the ISP I2C bus controller driver files.
Creating a standard I2C bus adapter, even if the driver doesn't
actually communicates with the hardware and it is instead used
by the ISP firmware running on the Cortex-A5, allows to use
standard hardware description in the device tree. As the sensor
would have actually had a standard V4L2 sub-device driver run
on the host CPU.
This approach allows to adapt the driver with a relatively small
effort should the Imaging Subsystem architecture change so that
the I2C bus is controlled by the host CPU, rather than the
internal FIMC-IS ARM CPU. The image sensor drivers can be
standard I2C client driver, as in case of most existing image
sensor driver.
Signed-off-by: Sylwester Nawrocki
Signed-off-by: Kyungmin Park
---
Changes since v3:
- corrected I2C bus driver remove() function,
- added missing EXPORT_SYMBOL() for the driver
register/unregister API.
---
drivers/media/platform/exynos4-is/fimc-is-i2c.c | 129 +++
drivers/media/platform/exynos4-is/fimc-is-i2c.h | 15 +++
2 files changed, 144 insertions(+)
create mode 100644 drivers/media/platform/exynos4-is/fimc-is-i2c.c
create mode 100644 drivers/media/platform/exynos4-is/fimc-is-i2c.h
diff --git a/drivers/media/platform/exynos4-is/fimc-is-i2c.c
b/drivers/media/platform/exynos4-is/fimc-is-i2c.c
new file mode 100644
index 000..1ec6b3c
--- /dev/null
+++ b/drivers/media/platform/exynos4-is/fimc-is-i2c.c
@@ -0,0 +1,129 @@
+/*
+ * Samsung EXYNOS4x12 FIMC-IS (Imaging Subsystem) driver
+ *
+ * Copyright (C) 2013 Samsung Electronics Co., Ltd.
+ *
+ * Author: Sylwester Nawrocki
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include "fimc-is-i2c.h"
+
+struct fimc_is_i2c {
+ struct i2c_adapter adapter;
+ struct clk *clock;
+};
+
+/*
+ * An empty algorithm is used as the actual I2C bus controller driver
+ * is implemented in the FIMC-IS subsystem firmware and the host CPU
+ * doesn't access the I2C bus controller.
+ */
+static const struct i2c_algorithm fimc_is_i2c_algorithm;
+
+static int fimc_is_i2c_probe(struct platform_device *pdev)
+{
+ struct device_node *node = pdev->dev.of_node;
+ struct fimc_is_i2c *isp_i2c;
+ struct i2c_adapter *i2c_adap;
+ int ret;
+
+ isp_i2c = devm_kzalloc(&pdev->dev, sizeof(*isp_i2c), GFP_KERNEL);
+ if (!isp_i2c)
+ return -ENOMEM;
+
+ isp_i2c->clock = devm_clk_get(&pdev->dev, "i2c_isp");
+ if (IS_ERR(isp_i2c->clock)) {
+ dev_err(&pdev->dev, "failed to get the clock\n");
+ return PTR_ERR(isp_i2c->clock);
+ }
+
+ i2c_adap = &isp_i2c->adapter;
+ i2c_adap->dev.of_node = node;
+ i2c_adap->dev.parent = &pdev->dev;
+ strlcpy(i2c_adap->name, "exynos4x12-isp-i2c", sizeof(i2c_adap->name));
+ i2c_adap->owner = THIS_MODULE;
+ i2c_adap->algo = &fimc_is_i2c_algorithm;
+ i2c_adap->class = I2C_CLASS_SPD;
+
+ ret = i2c_add_adapter(i2c_adap);
+ if (ret < 0) {
+ dev_err(&pdev->dev, "failed to add I2C bus %s\n",
+ node->full_name);
+ return ret;
+ }
+
+ platform_set_drvdata(pdev, isp_i2c);
+
+ pm_runtime_enable(&pdev->dev);
+ pm_runtime_enable(&i2c_adap->dev);
+
+ of_i2c_register_devices(i2c_adap);
+
+ return 0;
+}
+
+static int fimc_is_i2c_remove(struct platform_device *pdev)
+{
+ struct fimc_is_i2c *isp_i2c = platform_get_drvdata(pdev);
+
+ pm_runtime_disable(&isp_i2c->adapter.dev);
+ pm_runtime_disable(&pdev->dev);
+ i2c_del_adapter(&isp_i2c->adapter);
+
+ return 0;
+}
+
+static int fimc_is_i2c_suspend(struct device *dev)
+{
+ struct fimc_is_i2c *isp_i2c = dev_get_drvdata(dev);
+ clk_disable_unprepare(isp_i2c->clock);
+ return 0;
+}
+
+static int fimc_is_i2c_resume(struct device *dev)
+{
+ struct fimc_is_i2c *isp_i2c = dev_get_drvdata(dev);
+ return clk_prepare_enable(isp_i2c->clock);
+}
+
+UNIVERSAL_DEV_PM_OPS(fimc_is_i2c_pm_ops, fimc_is_i2c_suspend,
+fimc_is_i2c_resume, NULL);
+
+static const struct of_device_id fimc_is_i2c_of_match[] = {
+ { .compatible = FIMC_IS_I2C_COMPATIBLE },
+ { },
+};
+MODULE_DEVICE_TABLE(of, fimc_is_i2c_of_match);
+
+static struct platform_driver fimc_is_i2c_driver = {
+ .probe = fimc_is_i2c_probe,
+ .remove = fimc_is_i2c_remove,
+ .driver = {
+ .of_match_table = fimc_is_i2c_of_match,
+ .name = "fimc-isp-i2c",
+ .owner = THIS_MODULE,
+ .pm = &fimc_is_i2c_pm_ops,
+ }
+};
+
+int fimc_is_register_i2c_driver(void)
+{
+ return platfor
[PATCH v4 0/7] V4L2 driver for Exynos4x12 Imaging Subsystem
This iteration includes mostly headers inclusion and comments cleanup, minor DT binding documentation update and added missing cleanup steps at the I2C bus driver. Detailed changes are listed at individual patches. Below is a full cover letter of v3. If there is no more comments I would send a pull request this week, so further development can be continued already in tree. - This patch series includes mostly changes in the clocks handling, fix of coding style issues found with checkpatch.pl and an improvement of the DT binding documentation. There is an issue that the ISP clocks (MCU_ISP block clocks) are in the ISP power domain and the clock registers should not be touched when this power domain is inactive. At least this applies to part of the CMU_ISP clocks, as our investigation shows. That is mainly the reason why all ISP clocks have CLK_IGNORE_UNUSED flag set in patch [1]. That's most likely not the right solution to this problem. But I'm not sure what could be other options, probably it would help to make the CMU_ISP clocks provider aware of the ISP domain. But I can't tell state of which clock registers is persistent over the ISP power domain on/off cycles. Without the CLK_IGNORE_UNUSED flags set the system hangs when the clock core disables unused clocks. Changes since v2: - Improved clocks handling, all required clocks should now be explicitly enabled/disabled by the driver as needed. In addition a frequency of selected clocks is now being set to ensure the FIMC-IS ISP chain an the MCU core clocks frequency is valid, before starting the ISP firmware. - Added ISP I2C bus clock handling in the dummy I2C bus controller driver. - Clock properties added at the DT binding description. This patch series with all dependencies can be found at: git://linuxtv.org/snawrocki/samsung.git exynos4-fimc-is-v3 [1] http://www.spinics.net/lists/arm-kernel/msg233534.html Below is a cover letter of the initial version of this patch series. --- This patch series is an initial version of a driver for the camera ISP subsystem (FIMC-IS) found in Samsung Exynos4x12 SoCs. The FIMC-IS subsystem is build around a ARM Cortex-A5 CPU that controls its dedicated peripherals, like I2C, SPI, UART, PWM, ADC,... and the ISP chain. There are 3 hardware image processing blocks: ISP, DRC (dynamic range compression) and FD (face detection) that are normally controlled by the Cortex-A5 firmware. The driver currently exposes two additional sub-devices to user space: the image sensor and FIMC-IS-ISP sub-device. Another one might be added in future for the FD features. The FIMC-IS has various data inputs, it can capture data from memory or from other SoC IP blocks (FIMC-LITE). It is currently plugged between FIMC-LITE and FIMC (post-processor) IP blocks, so there is a processing chain like: sensor -> MIPI-CSIS -> FIMC-LITE -> FIMC-IS-ISP -> FIMC -> memory A raw Bayer image data can be captured from the ISP block which has it's own DMA engines. Support for this is not really included in this series, only a video capture node driver stubs are added. This is a bit complicated code, nevertheless I would really appreciate any review comments you might have. And this is just a basic set of futures this patch series addresses. Others include input/output DMA support for the DRC and FD blocks, support for more ISP controls, etc. Full git tree with all dependencies can be found at: http://git.linuxtv.org/snawrocki/samsung.git/exynos4-fimc-is-v2 -- Sylwester Nawrocki (7): exynos4-is: Add Exynos4x12 FIMC-IS driver exynos4-is: Add FIMC-IS ISP I2C bus driver exynos4-is: Add FIMC-IS parameter region definitions exynos4-is: Add common FIMC-IS image sensor driver exynos4-is: Add Exynos4x12 FIMC-IS device tree binding documentation exynos4-is: Add fimc-is subdevs registration exynos4-is: Create media links for the FIMC-IS entities .../devicetree/bindings/media/exynos4-fimc-is.txt | 49 + drivers/media/platform/exynos4-is/Kconfig | 11 + drivers/media/platform/exynos4-is/Makefile |3 + .../media/platform/exynos4-is/fimc-is-command.h| 147 +++ drivers/media/platform/exynos4-is/fimc-is-errno.c | 272 ++ drivers/media/platform/exynos4-is/fimc-is-errno.h | 248 + drivers/media/platform/exynos4-is/fimc-is-i2c.c| 129 +++ drivers/media/platform/exynos4-is/fimc-is-i2c.h| 15 + drivers/media/platform/exynos4-is/fimc-is-param.c | 955 ++ drivers/media/platform/exynos4-is/fimc-is-param.h | 1022 drivers/media/platform/exynos4-is/fimc-is-regs.c | 242 + drivers/media/platform/exynos4-is/fimc-is-regs.h | 164 drivers/media/platform/exynos4-is/fimc-is-sensor.c | 322 ++ drivers/media/platform/exynos4-is/fimc-is-sensor.h | 83 ++ drivers/media/platform/exynos4-is/fimc-is.c| 1009 +++ drivers/media/pl
Re: [PATCH v2 2/3] mutex: add support for reservation style locks, v2
On Tue, Apr 2, 2013 at 1:00 PM, Peter Zijlstra wrote: > Also, is there anything in CS literature that comes close to this? I'd > think the DBMS people would have something similar with their > transactional systems. What do they call it? I've looked around a bit and in dbms row-locking land this seems to be called the wound-wait deadlock avoidance algorithm. It's the same approach where if you encounter an older ticket (there called transaction timestamp) you drop all locked rows and retry (or abort) the transaction. If you encounter a newer ticket when trying to grab a lock simply do a blocking wait. So ticket/reservation in Maartens patches is the analog of timestamp/transaction. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- 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
saa7134 irq status bits
Hi,
Forwarding to linux-media mailing list, hoping that someone there can
help out. I havn't worked in the code for years now, can't remember
what the AR irq bit is and can't find my copy of the saa7134 data sheet
too ...
cheers,
Gerd
Original Message
Subject: hello kraxel
Date: Tue, 02 Apr 2013 15:48:42 +0800
From: zhaokai
To: kra...@bytesex.org
Dear Kraxel:
My name is zhaokai, I am a soft developer working in beijing.
This is my first mail to The Kernel Developer, I am very excited.
Now I have a question about your code for saa7134 driver in linux kernel
2.6.21.
We use Loongson CPU,I compile kernel and run the image,when I run my
test app for saa7134 camera
this message will print:
saa7130[0]/irq: looping -- clearing all enable bits
I study the saa7134 driver code,find the message come from the follow code:
if (10 == loop) {
print_irqstatus(dev,loop,report,status);
if (report & SAA7134_IRQ_REPORT_PE) {
/* disable all parity error */
printk(KERN_WARNING "%s/irq: looping -- "
"clearing PE (parity error!) enable bit\n",dev->name);
saa_clearl(SAA7134_IRQ2,SAA7134_IRQ2_INTE_PE);
} else if (report & SAA7134_IRQ_REPORT_GPIO16) {
/* disable gpio16 IRQ */
printk(KERN_WARNING "%s/irq: looping -- "
"clearing GPIO16 enable bit\n",dev->name);
saa_clearl(SAA7134_IRQ2, SAA7134_IRQ2_INTE_GPIO16);
} else if (report & SAA7134_IRQ_REPORT_GPIO18) {
/* disable gpio18 IRQs */
printk(KERN_WARNING "%s/irq: looping -- "
"clearing GPIO18 enable bit\n",dev->name);
saa_clearl(SAA7134_IRQ2, SAA7134_IRQ2_INTE_GPIO18);
} else {
/* disable all irqs */
printk(KERN_WARNING "%s/irq: looping -- "
"clearing all enable bits\n",dev->name);
saa_writel(SAA7134_IRQ1,0);
saa_writel(SAA7134_IRQ2,0);
}
}
this is in the interrupt handle function,I add some print and find the
value of SAA7134_IRQ_REPORT register is 0x11 or 0x10, normally it would
be 0x1 or 0x0,
0x1x means SAA7134_IRQ_REPORT_AR, So what is the meaning of
SAA7134_IRQ_REPORT_AR ?
Best regards,
ZhaoKai
--
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: Remove incorrect EXPORT_SYMBOL() usage at v4l2-of.c
On Tue, 2 Apr 2013, Sylwester Nawrocki wrote: > Hi Guennadi, > > On 04/02/2013 04:54 PM, Guennadi Liakhovetski wrote: > > On Tue, 2 Apr 2013, Sylwester Nawrocki wrote: > > > >> > v4l2_of_parse_parallel_bus() function is now static and > >> > EXPORT_SYMBOL() doesn't apply to it any more. Drop this > >> > meaningless statement, which was supposed to be done in > >> > the original merged patch. > >> > > >> > While at it, edit the copyright notice so it is sorted in > >> > both the v4l2-of.c and v4l2-of.h file in newest entries > >> > on top order, and state clearly I'm just the author of > >> > parts of the code, not the copyright owner. > >> > > >> > Signed-off-by: Sylwester Nawrocki > >> > Signed-off-by: Kyungmin Park > > > > This is not concerning the contents of this patch, but rather the form > > confuses me a bit - the two above Sob's: you are the author, and you're > > sending the patch to the list, but Kyungmin Park's Sob is the last in the > > list, which to me means that your patch went via his tree, but it's you > > who's sending it?... I think I saw this pattern in some other your patches > > too. What exactly does this mean? > > This means just that Kyungmin approves the patch submission as our manager > and the internal tree maintainer. He is not necessarily directly involved > in the development of a patch. As you probably noticed his Signed-off is > on patches from all our team members. I agree it is not immediately obvious > what's going on here. This has been discussed in the past few times. For > instance please refer to this thread: > > http://www.spinics.net/lists/linux-usb/msg74981.html Ok, thanks, I wasn't aware of this use of Sob. 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: [PATCH] V4L: Remove incorrect EXPORT_SYMBOL() usage at v4l2-of.c
Hi Guennadi, On 04/02/2013 04:54 PM, Guennadi Liakhovetski wrote: > On Tue, 2 Apr 2013, Sylwester Nawrocki wrote: > >> > v4l2_of_parse_parallel_bus() function is now static and >> > EXPORT_SYMBOL() doesn't apply to it any more. Drop this >> > meaningless statement, which was supposed to be done in >> > the original merged patch. >> > >> > While at it, edit the copyright notice so it is sorted in >> > both the v4l2-of.c and v4l2-of.h file in newest entries >> > on top order, and state clearly I'm just the author of >> > parts of the code, not the copyright owner. >> > >> > Signed-off-by: Sylwester Nawrocki >> > Signed-off-by: Kyungmin Park > > This is not concerning the contents of this patch, but rather the form > confuses me a bit - the two above Sob's: you are the author, and you're > sending the patch to the list, but Kyungmin Park's Sob is the last in the > list, which to me means that your patch went via his tree, but it's you > who's sending it?... I think I saw this pattern in some other your patches > too. What exactly does this mean? This means just that Kyungmin approves the patch submission as our manager and the internal tree maintainer. He is not necessarily directly involved in the development of a patch. As you probably noticed his Signed-off is on patches from all our team members. I agree it is not immediately obvious what's going on here. This has been discussed in the past few times. For instance please refer to this thread: http://www.spinics.net/lists/linux-usb/msg74981.html -- 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 v2 2/3] mutex: add support for reservation style locks, v2
Hey,
Thanks for reviewing.
Op 02-04-13 13:00, Peter Zijlstra schreef:
> On Thu, 2013-02-28 at 11:25 +0100, Maarten Lankhorst wrote:
>> +Reservation type mutexes
>> +struct ticket_mutex {
>> +extern int __must_check _mutex_reserve_lock(struct ticket_mutex *lock,
> That's two different names and two different forms of one (for a total
> of 3 variants) for the same scheme.
>
> FAIL...
It's been hard since I haven't seen anything similar in the kernel, I
originally went with tickets
since that's what ttm originally called it, and tried to kill as many
references as I could
when I noticed ticket mutexes already being taken.
I'll fix up the ticket_mutex -> reservation_mutex, and mutex_reserve_* ->
reserve_mutex_*
> On Thu, 2013-02-28 at 11:25 +0100, Maarten Lankhorst wrote:
>> +mutex_reserve_lock_slow and mutex_reserve_lock_intr_slow:
>> + Similar to mutex_reserve_lock, except it won't backoff with
>> -EAGAIN.
>> + This is useful when mutex_reserve_lock failed with -EAGAIN, and you
>> + unreserved all reservation_locks so no deadlock can occur.
>> +
> I don't particularly like these function names, with lock
> implementations the _slow post-fix is typically used for slow path
> implementations, not API type interfaces.
I didn't intend for drivers to use the new calls directly, but rather through
a wrapper,
for example by ttm_eu_reserve_buffers in drivers/gpu/drm/ttm/ttm_execbuf_util.c
> Also, is there anything in CS literature that comes close to this? I'd
> think the DBMS people would have something similar with their
> transactional systems. What do they call it?
I didn't study cs, but judging from your phrasing I guess you mean you want me
to call it transaction_mutexes instead?
> Head hurts, needs more time to ponder. It would be good if someone else
> (this would probably be you maarten) would also consider this and
> explore
> this 'interesting' problem space :-)
My head too, evil priority stuff!
Hacky but pragmatical workaround for now: use a real mutex around all the
reserve_mutex_lock* calls instead of a virtual lock.
It can be unlocked as soon as all locks have been taken, before any actual work
is done.
It only slightly kills the point of having a reservation in the first place,
but at least it won't break completely -rt completely for now.
~Maarten
--
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: Remove incorrect EXPORT_SYMBOL() usage at v4l2-of.c
Hi Sylwester On Tue, 2 Apr 2013, Sylwester Nawrocki wrote: > v4l2_of_parse_parallel_bus() function is now static and > EXPORT_SYMBOL() doesn't apply to it any more. Drop this > meaningless statement, which was supposed to be done in > the original merged patch. > > While at it, edit the copyright notice so it is sorted in > both the v4l2-of.c and v4l2-of.h file in newest entries > on top order, and state clearly I'm just the author of > parts of the code, not the copyright owner. > > Signed-off-by: Sylwester Nawrocki > Signed-off-by: Kyungmin Park This is not concerning the contents of this patch, but rather the form confuses me a bit - the two above Sob's: you are the author, and you're sending the patch to the list, but Kyungmin Park's Sob is the last in the list, which to me means that your patch went via his tree, but it's you who's sending it?... I think I saw this pattern in some other your patches too. What exactly does this mean? Thanks Guennadi > --- > drivers/media/v4l2-core/v4l2-of.c |3 +-- > include/media/v4l2-of.h |6 +++--- > 2 files changed, 4 insertions(+), 5 deletions(-) > > diff --git a/drivers/media/v4l2-core/v4l2-of.c > b/drivers/media/v4l2-core/v4l2-of.c > index e38e210..aa59639 100644 > --- a/drivers/media/v4l2-core/v4l2-of.c > +++ b/drivers/media/v4l2-core/v4l2-of.c > @@ -2,7 +2,7 @@ > * V4L2 OF binding parsing library > * > * Copyright (C) 2012 - 2013 Samsung Electronics Co., Ltd. > - * Sylwester Nawrocki > + * Author: Sylwester Nawrocki > * > * Copyright (C) 2012 Renesas Electronics Corp. > * Author: Guennadi Liakhovetski > @@ -103,7 +103,6 @@ static void v4l2_of_parse_parallel_bus(const struct > device_node *node, > bus->flags = flags; > > } > -EXPORT_SYMBOL(v4l2_of_parse_parallel_bus); > > /** > * v4l2_of_parse_endpoint() - parse all endpoint node properties > diff --git a/include/media/v4l2-of.h b/include/media/v4l2-of.h > index 00f9147..3a8a841 100644 > --- a/include/media/v4l2-of.h > +++ b/include/media/v4l2-of.h > @@ -1,12 +1,12 @@ > /* > * V4L2 OF binding parsing library > * > + * Copyright (C) 2012 - 2013 Samsung Electronics Co., Ltd. > + * Author: Sylwester Nawrocki > + * > * Copyright (C) 2012 Renesas Electronics Corp. > * Author: Guennadi Liakhovetski > * > - * Copyright (C) 2012 - 2013 Samsung Electronics Co., Ltd. > - * Sylwester Nawrocki > - * > * This program is free software; you can redistribute it and/or modify > * it under the terms of version 2 of the GNU General Public License as > * published by the Free Software Foundation. > -- > 1.7.9.5 > --- 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
[PATCH] V4L: Remove incorrect EXPORT_SYMBOL() usage at v4l2-of.c
v4l2_of_parse_parallel_bus() function is now static and EXPORT_SYMBOL() doesn't apply to it any more. Drop this meaningless statement, which was supposed to be done in the original merged patch. While at it, edit the copyright notice so it is sorted in both the v4l2-of.c and v4l2-of.h file in newest entries on top order, and state clearly I'm just the author of parts of the code, not the copyright owner. Signed-off-by: Sylwester Nawrocki Signed-off-by: Kyungmin Park --- drivers/media/v4l2-core/v4l2-of.c |3 +-- include/media/v4l2-of.h |6 +++--- 2 files changed, 4 insertions(+), 5 deletions(-) diff --git a/drivers/media/v4l2-core/v4l2-of.c b/drivers/media/v4l2-core/v4l2-of.c index e38e210..aa59639 100644 --- a/drivers/media/v4l2-core/v4l2-of.c +++ b/drivers/media/v4l2-core/v4l2-of.c @@ -2,7 +2,7 @@ * V4L2 OF binding parsing library * * Copyright (C) 2012 - 2013 Samsung Electronics Co., Ltd. - * Sylwester Nawrocki + * Author: Sylwester Nawrocki * * Copyright (C) 2012 Renesas Electronics Corp. * Author: Guennadi Liakhovetski @@ -103,7 +103,6 @@ static void v4l2_of_parse_parallel_bus(const struct device_node *node, bus->flags = flags; } -EXPORT_SYMBOL(v4l2_of_parse_parallel_bus); /** * v4l2_of_parse_endpoint() - parse all endpoint node properties diff --git a/include/media/v4l2-of.h b/include/media/v4l2-of.h index 00f9147..3a8a841 100644 --- a/include/media/v4l2-of.h +++ b/include/media/v4l2-of.h @@ -1,12 +1,12 @@ /* * V4L2 OF binding parsing library * + * Copyright (C) 2012 - 2013 Samsung Electronics Co., Ltd. + * Author: Sylwester Nawrocki + * * Copyright (C) 2012 Renesas Electronics Corp. * Author: Guennadi Liakhovetski * - * Copyright (C) 2012 - 2013 Samsung Electronics Co., Ltd. - * Sylwester Nawrocki - * * This program is free software; you can redistribute it and/or modify * it under the terms of version 2 of the GNU General Public License as * published by the Free Software Foundation. -- 1.7.9.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
Announce: xawtv-3.103
Hi All, I'm happy to announce the latest xawtv release Changes: 3.103 = * Improve alsa stream handling * Add support for alsa audio loopback to the radio app * Add support for multiple-band (AM+FM) tuners to radio app * Tons of other bugfixes + improvements for the radio app * Fix xawtv window flashing to black when changing channel or taking a snapshot * Fix crackle crackle sound on mp34xx cards when changing channel * Various other bugfixes Grab it here: http://linuxtv.org/downloads/xawtv/xawtv-3.103.tar.bz2 Regards, Hans -- 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] soc-camera: protect against racing open(2) and rmmod
To protect against open() racing with rmmod, hold the list_lock also while
obtaining a reference to the camera host driver and check that the video
device hasn't been unregistered yet.
Signed-off-by: Guennadi Liakhovetski
---
drivers/media/platform/soc_camera/soc_camera.c | 42
1 files changed, 28 insertions(+), 14 deletions(-)
diff --git a/drivers/media/platform/soc_camera/soc_camera.c
b/drivers/media/platform/soc_camera/soc_camera.c
index 8ec9805..9cc3898 100644
--- a/drivers/media/platform/soc_camera/soc_camera.c
+++ b/drivers/media/platform/soc_camera/soc_camera.c
@@ -508,36 +508,49 @@ static int soc_camera_set_fmt(struct soc_camera_device
*icd,
static int soc_camera_open(struct file *file)
{
struct video_device *vdev = video_devdata(file);
- struct soc_camera_device *icd = dev_get_drvdata(vdev->parent);
- struct soc_camera_desc *sdesc = to_soc_camera_desc(icd);
+ struct soc_camera_device *icd;
struct soc_camera_host *ici;
int ret;
- if (!to_soc_camera_control(icd))
- /* No device driver attached */
- return -ENODEV;
-
/*
* Don't mess with the host during probe: wait until the loop in
-* scan_add_host() completes
+* scan_add_host() completes. Also protect against a race with
+* soc_camera_host_unregister().
*/
if (mutex_lock_interruptible(&list_lock))
return -ERESTARTSYS;
+
+ if (!vdev || !video_is_registered(vdev)) {
+ mutex_unlock(&list_lock);
+ return -ENODEV;
+ }
+
+ icd = dev_get_drvdata(vdev->parent);
ici = to_soc_camera_host(icd->parent);
+
+ ret = try_module_get(ici->ops->owner) ? 0 : -ENODEV;
mutex_unlock(&list_lock);
- if (mutex_lock_interruptible(&ici->host_lock))
- return -ERESTARTSYS;
- if (!try_module_get(ici->ops->owner)) {
+ if (ret < 0) {
dev_err(icd->pdev, "Couldn't lock capture bus driver.\n");
- ret = -EINVAL;
- goto emodule;
+ return ret;
+ }
+
+ if (!to_soc_camera_control(icd)) {
+ /* No device driver attached */
+ ret = -ENODEV;
+ goto econtrol;
}
+ if (mutex_lock_interruptible(&ici->host_lock)) {
+ ret = -ERESTARTSYS;
+ goto elockhost;
+ }
icd->use_count++;
/* Now we really have to activate the camera */
if (icd->use_count == 1) {
+ struct soc_camera_desc *sdesc = to_soc_camera_desc(icd);
/* Restore parameters before the last close() per V4L2 API */
struct v4l2_format f = {
.type = V4L2_BUF_TYPE_VIDEO_CAPTURE,
@@ -609,9 +622,10 @@ epower:
ici->ops->remove(icd);
eiciadd:
icd->use_count--;
- module_put(ici->ops->owner);
-emodule:
mutex_unlock(&ici->host_lock);
+elockhost:
+econtrol:
+ module_put(ici->ops->owner);
return ret;
}
--
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
Re: [PATCH v3] davinci: vpif: add pm_runtime support
On Tue 2 April 2013 15:41:30 Prabhakar lad wrote:
> From: Lad, Prabhakar
>
> Add pm_runtime support to the TI Davinci VPIF driver.
>
> Signed-off-by: Lad, Prabhakar
> Cc: Mauro Carvalho Chehab
> Cc: Hans Verkuil
Acked-by: Hans Verkuil
Regards,
Hans
> Cc: Laurent Pinchart
> Cc: Sakari Ailus
> Cc: Sekhar Nori
> ---
> Changes for v3:
> 1: Removed pm_runtime_resume() from probe as pm_runtime_get()
> calls it as pointed by Hans.
>
> Changes for v2:
> 1: Removed use of clk API as pointed by Laurent and Sekhar.
>
> drivers/media/platform/davinci/vpif.c | 24 ++--
> 1 files changed, 6 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/media/platform/davinci/vpif.c
> b/drivers/media/platform/davinci/vpif.c
> index 3bc4db8..ea82a8b 100644
> --- a/drivers/media/platform/davinci/vpif.c
> +++ b/drivers/media/platform/davinci/vpif.c
> @@ -23,8 +23,8 @@
> #include
> #include
> #include
> -#include
> #include
> +#include
> #include
>
> #include
> @@ -46,8 +46,6 @@ spinlock_t vpif_lock;
> void __iomem *vpif_base;
> EXPORT_SYMBOL_GPL(vpif_base);
>
> -struct clk *vpif_clk;
> -
> /**
> * vpif_ch_params: video standard configuration parameters for vpif
> * The table must include all presets from supported subdevices.
> @@ -443,19 +441,13 @@ static int vpif_probe(struct platform_device *pdev)
> goto fail;
> }
>
> - vpif_clk = clk_get(&pdev->dev, "vpif");
> - if (IS_ERR(vpif_clk)) {
> - status = PTR_ERR(vpif_clk);
> - goto clk_fail;
> - }
> - clk_prepare_enable(vpif_clk);
> + pm_runtime_enable(&pdev->dev);
> + pm_runtime_get(&pdev->dev);
>
> spin_lock_init(&vpif_lock);
> dev_info(&pdev->dev, "vpif probe success\n");
> return 0;
>
> -clk_fail:
> - iounmap(vpif_base);
> fail:
> release_mem_region(res->start, res_len);
> return status;
> @@ -463,11 +455,7 @@ fail:
>
> static int vpif_remove(struct platform_device *pdev)
> {
> - if (vpif_clk) {
> - clk_disable_unprepare(vpif_clk);
> - clk_put(vpif_clk);
> - }
> -
> + pm_runtime_disable(&pdev->dev);
> iounmap(vpif_base);
> release_mem_region(res->start, res_len);
> return 0;
> @@ -476,13 +464,13 @@ static int vpif_remove(struct platform_device *pdev)
> #ifdef CONFIG_PM
> static int vpif_suspend(struct device *dev)
> {
> - clk_disable_unprepare(vpif_clk);
> + pm_runtime_put(dev);
> return 0;
> }
>
> static int vpif_resume(struct device *dev)
> {
> - clk_prepare_enable(vpif_clk);
> + pm_runtime_get(dev);
> return 0;
> }
>
>
--
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 v3] davinci: vpif: add pm_runtime support
From: Lad, Prabhakar
Add pm_runtime support to the TI Davinci VPIF driver.
Signed-off-by: Lad, Prabhakar
Cc: Mauro Carvalho Chehab
Cc: Hans Verkuil
Cc: Laurent Pinchart
Cc: Sakari Ailus
Cc: Sekhar Nori
---
Changes for v3:
1: Removed pm_runtime_resume() from probe as pm_runtime_get()
calls it as pointed by Hans.
Changes for v2:
1: Removed use of clk API as pointed by Laurent and Sekhar.
drivers/media/platform/davinci/vpif.c | 24 ++--
1 files changed, 6 insertions(+), 18 deletions(-)
diff --git a/drivers/media/platform/davinci/vpif.c
b/drivers/media/platform/davinci/vpif.c
index 3bc4db8..ea82a8b 100644
--- a/drivers/media/platform/davinci/vpif.c
+++ b/drivers/media/platform/davinci/vpif.c
@@ -23,8 +23,8 @@
#include
#include
#include
-#include
#include
+#include
#include
#include
@@ -46,8 +46,6 @@ spinlock_t vpif_lock;
void __iomem *vpif_base;
EXPORT_SYMBOL_GPL(vpif_base);
-struct clk *vpif_clk;
-
/**
* vpif_ch_params: video standard configuration parameters for vpif
* The table must include all presets from supported subdevices.
@@ -443,19 +441,13 @@ static int vpif_probe(struct platform_device *pdev)
goto fail;
}
- vpif_clk = clk_get(&pdev->dev, "vpif");
- if (IS_ERR(vpif_clk)) {
- status = PTR_ERR(vpif_clk);
- goto clk_fail;
- }
- clk_prepare_enable(vpif_clk);
+ pm_runtime_enable(&pdev->dev);
+ pm_runtime_get(&pdev->dev);
spin_lock_init(&vpif_lock);
dev_info(&pdev->dev, "vpif probe success\n");
return 0;
-clk_fail:
- iounmap(vpif_base);
fail:
release_mem_region(res->start, res_len);
return status;
@@ -463,11 +455,7 @@ fail:
static int vpif_remove(struct platform_device *pdev)
{
- if (vpif_clk) {
- clk_disable_unprepare(vpif_clk);
- clk_put(vpif_clk);
- }
-
+ pm_runtime_disable(&pdev->dev);
iounmap(vpif_base);
release_mem_region(res->start, res_len);
return 0;
@@ -476,13 +464,13 @@ static int vpif_remove(struct platform_device *pdev)
#ifdef CONFIG_PM
static int vpif_suspend(struct device *dev)
{
- clk_disable_unprepare(vpif_clk);
+ pm_runtime_put(dev);
return 0;
}
static int vpif_resume(struct device *dev)
{
- clk_prepare_enable(vpif_clk);
+ pm_runtime_get(dev);
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] m5mols: Improved power on routine
From: Andrzej Hajda
The regulator bulk API doesn't guarantee an order in which regulators
are enabled or disabled. Make sure the regulators are enabled
sequentially, as specified in the sensor's datasheet.
Additionally a 1ms delay is added after the reset GPIO (de)assertion.
Signed-off-by: Andrzej Hajda
Signed-off-by: Sylwester Nawrocki
Signed-off-by: Kyungmin Park
---
drivers/media/i2c/m5mols/m5mols_core.c | 23 ++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/drivers/media/i2c/m5mols/m5mols_core.c
b/drivers/media/i2c/m5mols/m5mols_core.c
index 0b899cb..a364781 100644
--- a/drivers/media/i2c/m5mols/m5mols_core.c
+++ b/drivers/media/i2c/m5mols/m5mols_core.c
@@ -740,6 +740,24 @@ static const struct v4l2_subdev_video_ops m5mols_video_ops
= {
.s_stream = m5mols_s_stream,
};
+static int regulator_bulk_enable_sync(int num_consumers,
+ struct regulator_bulk_data *consumers)
+{
+ int ret = 0;
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(supplies); ++i) {
+ ret = regulator_enable(supplies[i].consumer);
+ if (ret < 0) {
+ for (; i >= 0; --i)
+ regulator_disable(supplies[i].consumer);
+ return ret;
+ }
+ }
+
+ return 0;
+}
+
static int m5mols_sensor_power(struct m5mols_info *info, bool enable)
{
struct v4l2_subdev *sd = &info->sd;
@@ -757,13 +775,15 @@ static int m5mols_sensor_power(struct m5mols_info *info,
bool enable)
return ret;
}
- ret = regulator_bulk_enable(ARRAY_SIZE(supplies), supplies);
+ ret = regulator_bulk_enable_sync(ARRAY_SIZE(supplies),
+ supplies);
if (ret) {
info->set_power(&client->dev, 0);
return ret;
}
gpio_set_value(pdata->gpio_reset, !pdata->reset_polarity);
+ usleep_range(1000, 1000);
info->power = 1;
return ret;
@@ -777,6 +797,7 @@ static int m5mols_sensor_power(struct m5mols_info *info,
bool enable)
info->set_power(&client->dev, 0);
gpio_set_value(pdata->gpio_reset, pdata->reset_polarity);
+ usleep_range(1000, 1000);
info->isp_ready = 0;
info->power = 0;
--
1.7.9.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] exynos4-is: Correct clock properties description at the DT binding documentation
The 'camera' DT node needs to have sclk_cam0/1 and pxl_async0/1 clocks specified, while 'fimc' nodes should have only "fimc" and "sclk_fimc". "mux" and "parent" are leftovers from early versions of patches adding DT support, when the IP bus clock parent clock was being set by the driver. A better solution is needed to have e.g. clocks driver setting all required parent clocks, before clock consumers start using the clocks. Currently this binding doesn't describe the parent clocks setup, it needs to be specified and handled somewhere else. Signed-off-by: Sylwester Nawrocki Signed-off-by: Kyungmin Park --- .../devicetree/bindings/media/samsung-fimc.txt | 10 -- 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/Documentation/devicetree/bindings/media/samsung-fimc.txt b/Documentation/devicetree/bindings/media/samsung-fimc.txt index 2a63ddd..51c776b 100644 --- a/Documentation/devicetree/bindings/media/samsung-fimc.txt +++ b/Documentation/devicetree/bindings/media/samsung-fimc.txt @@ -17,9 +17,9 @@ Required properties: - compatible : must be "samsung,fimc", "simple-bus" - clocks : list of clock specifiers, corresponding to entries in - clock-names property; -- clock-names : must contain "fimc", "sclk_fimc" entries, matching entries - in the clocks property. + the clock-names property; +- clock-names : must contain "sclk_cam0", "sclk_cam1", "pxl_async0", + "pxl_async1" entries, matching entries in the clocks property. The pinctrl bindings defined in ../pinctrl/pinctrl-bindings.txt must be used to define a required pinctrl state named "default" and optional pinctrl states: @@ -32,7 +32,6 @@ way around. The 'camera' node must include at least one 'fimc' child node. - 'fimc' device nodes --- @@ -44,8 +43,7 @@ Required properties: - interrupts: should contain FIMC interrupt; - clocks: list of clock specifiers, must contain an entry for each required entry in clock-names; -- clock-names: must include "fimc", "sclk_fimc", "mux" entries and optionally - "parent" entry. +- clock-names: must contain "fimc", "sclk_fimc" entries. - samsung,pix-limits: an array of maximum supported image sizes in pixels, for details refer to Table 2-1 in the S5PV210 SoC User Manual; The meaning of each cell is as follows: -- 1.7.9.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] exynos4-is: Remove dependency on SYSCON for non-dt platforms
Currently the whole driver depends on MFD_SYSCON, which in turn
depends on OF. To allow to use the driver on non-dt platforms
(S5PV210) the SYSREG support is made conditional (it is needed
only for dt enabled platforms) and MFD_SYSCON is selected if
OF is enabled, instead of depending on OF.
Signed-off-by: Sylwester Nawrocki
Signed-off-by: Kyungmin Park
---
drivers/media/platform/exynos4-is/Kconfig |7 ++-
drivers/media/platform/exynos4-is/fimc-core.c |3 +--
drivers/media/platform/exynos4-is/fimc-core.h | 10 ++
drivers/media/platform/exynos4-is/fimc-reg.c |3 +++
4 files changed, 20 insertions(+), 3 deletions(-)
diff --git a/drivers/media/platform/exynos4-is/Kconfig
b/drivers/media/platform/exynos4-is/Kconfig
index 6954f05..c56f714 100644
--- a/drivers/media/platform/exynos4-is/Kconfig
+++ b/drivers/media/platform/exynos4-is/Kconfig
@@ -3,13 +3,18 @@ config VIDEO_SAMSUNG_EXYNOS4_IS
bool "Samsung S5P/EXYNOS4 SoC series Camera Subsystem driver"
depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API && PLAT_S5P && PM_RUNTIME
depends on EXPERIMENTAL
- depends on MFD_SYSCON
help
Say Y here to enable camera host interface devices for
Samsung S5P and EXYNOS SoC series.
if VIDEO_SAMSUNG_EXYNOS4_IS
+config FIMC_SYSREG
+ bool
+ depends on OF
+ select MFD_SYSCON
+ default y
+
config VIDEO_S5P_FIMC
tristate "S5P/EXYNOS4 FIMC/CAMIF camera interface driver"
depends on I2C
diff --git a/drivers/media/platform/exynos4-is/fimc-core.c
b/drivers/media/platform/exynos4-is/fimc-core.c
index f6efa47..c7a8bc1 100644
--- a/drivers/media/platform/exynos4-is/fimc-core.c
+++ b/drivers/media/platform/exynos4-is/fimc-core.c
@@ -964,8 +964,7 @@ static int fimc_probe(struct platform_device *pdev)
spin_lock_init(&fimc->slock);
mutex_init(&fimc->lock);
- fimc->sysreg = syscon_regmap_lookup_by_phandle(dev->of_node,
- "samsung,sysreg");
+ fimc->sysreg = fimc_get_sysreg_regmap(dev->of_node);
if (IS_ERR(fimc->sysreg))
return PTR_ERR(fimc->sysreg);
diff --git a/drivers/media/platform/exynos4-is/fimc-core.h
b/drivers/media/platform/exynos4-is/fimc-core.h
index de2b57e..dfd7476 100644
--- a/drivers/media/platform/exynos4-is/fimc-core.h
+++ b/drivers/media/platform/exynos4-is/fimc-core.h
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -646,6 +647,15 @@ void fimc_unregister_m2m_device(struct fimc_dev *fimc);
int fimc_register_driver(void);
void fimc_unregister_driver(void);
+#ifdef CONFIG_FIMC_SYSREG
+static inline struct regmap * fimc_get_sysreg_regmap(struct device_node *node)
+{
+ return syscon_regmap_lookup_by_phandle(node, "samsung,sysreg");
+}
+#else
+#define fimc_get_sysreg_regmap(node) (NULL)
+#endif
+
/* -*/
/* fimc-m2m.c */
void fimc_m2m_job_finish(struct fimc_ctx *ctx, int vb_state);
diff --git a/drivers/media/platform/exynos4-is/fimc-reg.c
b/drivers/media/platform/exynos4-is/fimc-reg.c
index fd144a1..f079f36 100644
--- a/drivers/media/platform/exynos4-is/fimc-reg.c
+++ b/drivers/media/platform/exynos4-is/fimc-reg.c
@@ -806,6 +806,9 @@ int fimc_hw_camblk_cfg_writeback(struct fimc_dev *fimc)
unsigned int mask, val, camblk_cfg;
int ret;
+ if (map == NULL)
+ return 0;
+
ret = regmap_read(map, SYSREG_CAMBLK, &camblk_cfg);
if (ret < 0 || ((camblk_cfg & 0x0070) >> 20 != 0x3))
return ret;
--
1.7.9.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
Re: [PATCH 10/23] [media] exynos: remove unnecessary header inclusions
On 04/02/2013 03:08 PM, Sylwester Nawrocki wrote: > On 03/05/2013 06:42 PM, Arnd Bergmann wrote: >> In multiplatform configurations, we cannot include headers >> provided by only the exynos platform. Fortunately a number >> of drivers that include those headers do not actually need >> them, so we can just remove the inclusions. >> >> Signed-off-by: Arnd Bergmann >> --- >> drivers/media/platform/exynos-gsc/gsc-regs.c | 1 - >> drivers/media/platform/s5p-tv/sii9234_drv.c | 3 --- > > Cc: linux-media@vger.kernel.org Uhh, now really added it to Cc. > Thanks Arnd. I have applied this patch to my tree for 3.10. > >> 2 files changed, 4 deletions(-) >> >> diff --git a/drivers/media/platform/exynos-gsc/gsc-regs.c >> b/drivers/media/platform/exynos-gsc/gsc-regs.c >> index 6f5b5a4..e22d147 100644 >> --- a/drivers/media/platform/exynos-gsc/gsc-regs.c >> +++ b/drivers/media/platform/exynos-gsc/gsc-regs.c >> @@ -12,7 +12,6 @@ >> >> #include >> #include >> -#include >> >> #include "gsc-core.h" >> >> diff --git a/drivers/media/platform/s5p-tv/sii9234_drv.c >> b/drivers/media/platform/s5p-tv/sii9234_drv.c >> index d90d228..39b77d2 100644 >> --- a/drivers/media/platform/s5p-tv/sii9234_drv.c >> +++ b/drivers/media/platform/s5p-tv/sii9234_drv.c >> @@ -23,9 +23,6 @@ >> #include >> #include >> >> -#include >> -#include >> - >> #include >> #include > > -- > > 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
[PATCH v2 3/3] davinic: vpss: trivial cleanup
From: Lad, Prabhakar
this patch removes unnecessary header file inclusions and
fixes the typo's.
Signed-off-by: Lad, Prabhakar
---
drivers/media/platform/davinci/vpss.c | 11 +++
1 files changed, 3 insertions(+), 8 deletions(-)
diff --git a/drivers/media/platform/davinci/vpss.c
b/drivers/media/platform/davinci/vpss.c
index d36429d..8a2f01e 100644
--- a/drivers/media/platform/davinci/vpss.c
+++ b/drivers/media/platform/davinci/vpss.c
@@ -17,13 +17,8 @@
*
* common vpss system module platform driver for all video drivers.
*/
-#include
-#include
-#include
#include
#include
-#include
-#include
#include
#include
@@ -101,7 +96,7 @@ enum vpss_platform_type {
/*
* vpss operations. Depends on platform. Not all functions are available
- * on all platforms. The api, first check if a functio is available before
+ * on all platforms. The api, first check if a function is available before
* invoking it. In the probe, the function ptrs are initialized based on
* vpss name. vpss name can be "dm355_vpss", "dm644x_vpss" etc.
*/
@@ -116,7 +111,7 @@ struct vpss_hw_ops {
void (*set_sync_pol)(struct vpss_sync_pol);
/* set the PG_FRAME_SIZE register*/
void (*set_pg_frame_size)(struct vpss_pg_frame_size);
- /* check and clear interrupt if occured */
+ /* check and clear interrupt if occurred */
int (*dma_complete_interrupt)(void);
};
@@ -235,7 +230,7 @@ EXPORT_SYMBOL(vpss_clear_wbl_overflow);
/*
* dm355_enable_clock - Enable VPSS Clock
- * @clock_sel: CLock to be enabled/disabled
+ * @clock_sel: Clock to be enabled/disabled
* @en: enable/disable flag
*
* This is called to enable or disable a vpss clock
--
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 v2 0/3] davinci: vpss: clock cleanup
From: Lad, Prabhakar This patch series cleanup's the VPSS clock enabling. The first patch removes vpss clock enabling from the capture drivers and moves it to the VPSS driver itself. The second patch moves the venc_enable_vpss_clock() to the driver which was being done in platform code. Changes for v2: 1: Used PM runtime API for clock handling and nit's pointed by Sekhar. Lad, Prabhakar (3): media: davinci: vpss: enable vpss clocks media: davinci: vpbe: venc: move the enabling of vpss clocks to driver davinic: vpss: trivial cleanup arch/arm/mach-davinci/dm355.c|7 +--- arch/arm/mach-davinci/dm365.c| 11 +-- arch/arm/mach-davinci/dm644x.c |9 + arch/arm/mach-davinci/pm_domain.c|2 +- drivers/media/platform/davinci/dm355_ccdc.c | 39 +-- drivers/media/platform/davinci/dm644x_ccdc.c | 44 -- drivers/media/platform/davinci/isif.c| 28 ++-- drivers/media/platform/davinci/vpbe_venc.c | 25 ++ drivers/media/platform/davinci/vpss.c| 36 - 9 files changed, 71 insertions(+), 130 deletions(-) -- 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 v2 1/3] media: davinci: vpss: enable vpss clocks
From: Lad, Prabhakar
By default the VPSS clocks were enabled in capture driver
for davinci family which creates duplicates for dm355/dm365/dm644x.
This patch adds support to enable the VPSS clocks in VPSS driver,
which avoids duplication of code and also adding clock aliases.
This patch uses PM runtime API to enable/disable instead common clock
framework. con_ids for master and slave clocks of vpss is added in pm_domain
for pm runtime to clock handling.
This patch cleanups the VPSS clock enabling in the capture driver,
and also removes the clock alias in machine file. Along side adds
a vpss slave clock for DM365 as mentioned by Sekhar
(https://patchwork.kernel.org/patch/1221261/).
The Suspend/Resume in dm644x_ccdc.c which enabled/disabled the VPSS clock
is now implemented as part of the VPSS driver.
Signed-off-by: Lad, Prabhakar
---
arch/arm/mach-davinci/dm355.c|7 +---
arch/arm/mach-davinci/dm365.c| 11 +--
arch/arm/mach-davinci/dm644x.c |9 +
arch/arm/mach-davinci/pm_domain.c|2 +-
drivers/media/platform/davinci/dm355_ccdc.c | 39 +--
drivers/media/platform/davinci/dm644x_ccdc.c | 44 --
drivers/media/platform/davinci/isif.c| 28 ++--
drivers/media/platform/davinci/vpss.c| 25 ++
8 files changed, 43 insertions(+), 122 deletions(-)
diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c
index b49c3b7..8e98bb0 100644
--- a/arch/arm/mach-davinci/dm355.c
+++ b/arch/arm/mach-davinci/dm355.c
@@ -345,8 +345,8 @@ static struct clk_lookup dm355_clks[] = {
CLK(NULL, "pll1_aux", &pll1_aux_clk),
CLK(NULL, "pll1_sysclkbp", &pll1_sysclkbp),
CLK(NULL, "vpss_dac", &vpss_dac_clk),
- CLK(NULL, "vpss_master", &vpss_master_clk),
- CLK(NULL, "vpss_slave", &vpss_slave_clk),
+ CLK("vpss", "master", &vpss_master_clk),
+ CLK("vpss", "slave", &vpss_slave_clk),
CLK(NULL, "clkout1", &clkout1_clk),
CLK(NULL, "clkout2", &clkout2_clk),
CLK(NULL, "pll2", &pll2_clk),
@@ -873,9 +873,6 @@ static int __init dm355_init_devices(void)
if (!cpu_is_davinci_dm355())
return 0;
- /* Add ccdc clock aliases */
- clk_add_alias("master", dm355_ccdc_dev.name, "vpss_master", NULL);
- clk_add_alias("slave", dm355_ccdc_dev.name, "vpss_master", NULL);
davinci_cfg_reg(DM355_INT_EDMA_CC);
platform_device_register(&dm355_edma_device);
platform_device_register(&dm355_vpss_device);
diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
index 6c39805..c61dd94 100644
--- a/arch/arm/mach-davinci/dm365.c
+++ b/arch/arm/mach-davinci/dm365.c
@@ -257,6 +257,12 @@ static struct clk vpss_master_clk = {
.flags = CLK_PSC,
};
+static struct clk vpss_slave_clk = {
+ .name = "vpss_slave",
+ .parent = &pll1_sysclk5,
+ .lpsc = DAVINCI_LPSC_VPSSSLV,
+};
+
static struct clk arm_clk = {
.name = "arm_clk",
.parent = &pll2_sysclk2,
@@ -449,7 +455,8 @@ static struct clk_lookup dm365_clks[] = {
CLK(NULL, "pll2_sysclk8", &pll2_sysclk8),
CLK(NULL, "pll2_sysclk9", &pll2_sysclk9),
CLK(NULL, "vpss_dac", &vpss_dac_clk),
- CLK(NULL, "vpss_master", &vpss_master_clk),
+ CLK("vpss", "master", &vpss_master_clk),
+ CLK("vpss", "slave", &vpss_slave_clk),
CLK(NULL, "arm", &arm_clk),
CLK(NULL, "uart0", &uart0_clk),
CLK(NULL, "uart1", &uart1_clk),
@@ -1239,8 +1246,6 @@ static int __init dm365_init_devices(void)
clk_add_alias(NULL, dev_name(&dm365_mdio_device.dev),
NULL, &dm365_emac_device.dev);
- /* Add isif clock alias */
- clk_add_alias("master", dm365_isif_dev.name, "vpss_master", NULL);
platform_device_register(&dm365_vpss_device);
platform_device_register(&dm365_isif_dev);
platform_device_register(&vpfe_capture_dev);
diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
index ee0e994..c2a9273 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -300,8 +300,8 @@ static struct clk_lookup dm644x_clks[] = {
CLK(NULL, "dsp", &dsp_clk),
CLK(NULL, "arm", &arm_clk),
CLK(NULL, "vicp", &vicp_clk),
- CLK(NULL, "vpss_master", &vpss_master_clk),
- CLK(NULL, "vpss_slave", &vpss_slave_clk),
+ CLK("vpss", "master", &vpss_master_clk),
+ CLK("vpss", "slave", &vpss_slave_clk),
CLK(NULL, "arm", &arm_clk),
CLK(NULL, "uart0", &uart0_clk),
CLK(NULL, "uart1", &uart1_clk),
@@ -901,11 +901,6 @@ int __init dm644x_init_video(struct vpfe_config *vpfe_cfg,
dm644x_vpfe_dev.dev.platform_data = vpfe_cfg;
platform_device_register(&dm644x_ccdc_dev);
platform_device_register
[PATCH v2 2/3] media: davinci: vpbe: venc: move the enabling of vpss clocks to driver
From: Lad, Prabhakar
The vpss clocks were enabled by calling a exported function from a driver
in a machine code. calling driver code from platform code is incorrect way.
This patch fixes this issue and calls the function from driver code itself.
Signed-off-by: Lad, Prabhakar
---
drivers/media/platform/davinci/vpbe_venc.c | 25 +
1 files changed, 25 insertions(+), 0 deletions(-)
diff --git a/drivers/media/platform/davinci/vpbe_venc.c
b/drivers/media/platform/davinci/vpbe_venc.c
index f15f211..91d0272 100644
--- a/drivers/media/platform/davinci/vpbe_venc.c
+++ b/drivers/media/platform/davinci/vpbe_venc.c
@@ -202,6 +202,25 @@ static void venc_enabledigitaloutput(struct v4l2_subdev
*sd, int benable)
}
}
+static void
+venc_enable_vpss_clock(int venc_type,
+ enum vpbe_enc_timings_type type,
+ unsigned int pclock)
+{
+ if (venc_type == VPBE_VERSION_1)
+ return;
+
+ if (venc_type == VPBE_VERSION_2 && (type == VPBE_ENC_STD ||
+ (type == VPBE_ENC_DV_TIMINGS && pclock <= 2700))) {
+ vpss_enable_clock(VPSS_VENC_CLOCK_SEL, 1);
+ vpss_enable_clock(VPSS_VPBE_CLOCK, 1);
+ return;
+ }
+
+ if (venc_type == VPBE_VERSION_3 && type == VPBE_ENC_STD)
+ vpss_enable_clock(VPSS_VENC_CLOCK_SEL, 0);
+}
+
#define VDAC_CONFIG_SD_V3 0x0E21A6B6
#define VDAC_CONFIG_SD_V2 0x081141CF
/*
@@ -220,6 +239,7 @@ static int venc_set_ntsc(struct v4l2_subdev *sd)
if (pdata->setup_clock(VPBE_ENC_STD, V4L2_STD_525_60) < 0)
return -EINVAL;
+ venc_enable_vpss_clock(venc->venc_type, VPBE_ENC_STD, V4L2_STD_525_60);
venc_enabledigitaloutput(sd, 0);
if (venc->venc_type == VPBE_VERSION_3) {
@@ -265,6 +285,7 @@ static int venc_set_pal(struct v4l2_subdev *sd)
if (venc->pdata->setup_clock(VPBE_ENC_STD, V4L2_STD_625_50) < 0)
return -EINVAL;
+ venc_enable_vpss_clock(venc->venc_type, VPBE_ENC_STD, V4L2_STD_625_50);
venc_enabledigitaloutput(sd, 0);
if (venc->venc_type == VPBE_VERSION_3) {
@@ -319,6 +340,7 @@ static int venc_set_480p59_94(struct v4l2_subdev *sd)
if (pdata->setup_clock(VPBE_ENC_DV_TIMINGS, 2700) < 0)
return -EINVAL;
+ venc_enable_vpss_clock(venc->venc_type, VPBE_ENC_DV_TIMINGS, 2700);
venc_enabledigitaloutput(sd, 0);
if (venc->venc_type == VPBE_VERSION_2)
@@ -366,6 +388,7 @@ static int venc_set_576p50(struct v4l2_subdev *sd)
if (pdata->setup_clock(VPBE_ENC_DV_TIMINGS, 2700) < 0)
return -EINVAL;
+ venc_enable_vpss_clock(venc->venc_type, VPBE_ENC_DV_TIMINGS, 2700);
venc_enabledigitaloutput(sd, 0);
if (venc->venc_type == VPBE_VERSION_2)
@@ -406,6 +429,7 @@ static int venc_set_720p60_internal(struct v4l2_subdev *sd)
if (pdata->setup_clock(VPBE_ENC_DV_TIMINGS, 7425) < 0)
return -EINVAL;
+ venc_enable_vpss_clock(venc->venc_type, VPBE_ENC_DV_TIMINGS, 7425);
venc_enabledigitaloutput(sd, 0);
venc_write(sd, VENC_OSDCLK0, 0);
@@ -434,6 +458,7 @@ static int venc_set_1080i30_internal(struct v4l2_subdev *sd)
if (pdata->setup_clock(VPBE_ENC_DV_TIMINGS, 7425) < 0)
return -EINVAL;
+ venc_enable_vpss_clock(venc->venc_type, VPBE_ENC_DV_TIMINGS, 7425);
venc_enabledigitaloutput(sd, 0);
venc_write(sd, VENC_OSDCLK0, 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
Re: [PATCH v2 2/3] mutex: add support for reservation style locks, v2
On Thu, 2013-02-28 at 11:25 +0100, Maarten Lankhorst wrote: > +The algorithm that TTM came up with for dealing with this problem is > +quite simple. For each group of buffers (execbuf) that need to be > +locked, the caller would be assigned a unique reservation_id, from a > +global counter. In case of deadlock while locking all the buffers > +associated with a execbuf, the one with the lowest reservation_id > +wins, and the one with the higher reservation_id unlocks all of the > +buffers that it has already locked, and then tries again. So the thing that made me cringe inside when I read this was making it all work on -rt, where we also need to take PI into account and ensure the entire thing is deterministic. It _might_ be 'easy' and we could fall back to PI mutex behaviour in the case the reservation IDs match; however the entire for-all-bufs retry loops do worry me still. Head hurts, needs more time to ponder. It would be good if someone else (this would probably be you maarten) would also consider this and explore this 'interesting' problem space :-) -- 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 v2 2/3] mutex: add support for reservation style locks, v2
On Thu, 2013-02-28 at 11:25 +0100, Maarten Lankhorst wrote:
> +Reservation type mutexes
> +struct ticket_mutex {
> +extern int __must_check _mutex_reserve_lock(struct ticket_mutex *lock,
That's two different names and two different forms of one (for a total
of 3 variants) for the same scheme.
FAIL...
Also, is there anything in CS literature that comes close to this? I'd
think the DBMS people would have something similar with their
transactional systems. What do they call it?
--
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 v2] davinci: vpif: add pm_runtime support
Hi Hans,
On Tue, Apr 2, 2013 at 2:17 PM, Hans Verkuil wrote:
> On Mon 1 April 2013 08:36:50 Prabhakar lad wrote:
>> From: Lad, Prabhakar
>>
>> Add pm_runtime support to the TI Davinci VPIF driver.
>>
>> Signed-off-by: Lad, Prabhakar
>> Cc: Mauro Carvalho Chehab
>> Cc: Hans Verkuil
>> Cc: Laurent Pinchart
>> Cc: Sakari Ailus
>> Cc: Sekhar Nori
>> ---
>> Changes for v2:
>> 1: Removed use of clk API as pointed by Laurent and Sekhar.
>>
>> drivers/media/platform/davinci/vpif.c | 24 +++-
>> 1 files changed, 7 insertions(+), 17 deletions(-)
>>
>> diff --git a/drivers/media/platform/davinci/vpif.c
>> b/drivers/media/platform/davinci/vpif.c
>> index 28638a8..599cabb 100644
>> --- a/drivers/media/platform/davinci/vpif.c
>> +++ b/drivers/media/platform/davinci/vpif.c
>> @@ -23,8 +23,8 @@
>> #include
>> #include
>> #include
>> -#include
>> #include
>> +#include
>> #include
>>
>> #include
>> @@ -44,7 +44,6 @@ static struct resource *res;
>> spinlock_t vpif_lock;
>>
>> void __iomem *vpif_base;
>> -struct clk *vpif_clk;
>>
>> /**
>> * ch_params: video standard configuration parameters for vpif
>> @@ -439,19 +438,15 @@ static int vpif_probe(struct platform_device *pdev)
>> goto fail;
>> }
>>
>> - vpif_clk = clk_get(&pdev->dev, "vpif");
>> - if (IS_ERR(vpif_clk)) {
>> - status = PTR_ERR(vpif_clk);
>> - goto clk_fail;
>> - }
>> - clk_prepare_enable(vpif_clk);
>> + pm_runtime_enable(&pdev->dev);
>> + pm_runtime_resume(&pdev->dev);
>> +
>> + pm_runtime_get(&pdev->dev);
>
> pm_runtime_get() calls pm_runtime_resume() if needed, so is the call to
> resume()
> really necessary?
>
Agreed I'll drop the call to pm_runtime_resume() and post a v3.
Regards,
--Prabhakar
> Regards,
>
> Hans
>
>>
>> spin_lock_init(&vpif_lock);
>> dev_info(&pdev->dev, "vpif probe success\n");
>> return 0;
>>
>> -clk_fail:
>> - iounmap(vpif_base);
>> fail:
>> release_mem_region(res->start, res_len);
>> return status;
>> @@ -459,11 +454,6 @@ fail:
>>
>> static int vpif_remove(struct platform_device *pdev)
>> {
>> - if (vpif_clk) {
>> - clk_disable_unprepare(vpif_clk);
>> - clk_put(vpif_clk);
>> - }
>> -
>> iounmap(vpif_base);
>> release_mem_region(res->start, res_len);
>> return 0;
>> @@ -472,13 +462,13 @@ static int vpif_remove(struct platform_device *pdev)
>> #ifdef CONFIG_PM
>> static int vpif_suspend(struct device *dev)
>> {
>> - clk_disable_unprepare(vpif_clk);
>> + pm_runtime_put(dev);
>> return 0;
>> }
>>
>> static int vpif_resume(struct device *dev)
>> {
>> - clk_prepare_enable(vpif_clk);
>> + pm_runtime_get(dev);
>> return 0;
>> }
>>
>>
--
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 v2 2/3] mutex: add support for reservation style locks, v2
On Thu, 2013-02-28 at 11:25 +0100, Maarten Lankhorst wrote:
> +struct ticket_mutex {
> + struct mutex base;
> + atomic_long_t reservation_id;
> +};
I'm not sure this is a good name, esp. due to the potential confusion
vs the ticket spinlocks we have.
--
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 v2 2/3] mutex: add support for reservation style locks, v2
On Thu, 2013-02-28 at 11:25 +0100, Maarten Lankhorst wrote: > +mutex_reserve_lock_slow and mutex_reserve_lock_intr_slow: > + Similar to mutex_reserve_lock, except it won't backoff with > -EAGAIN. > + This is useful when mutex_reserve_lock failed with -EAGAIN, and you > + unreserved all reservation_locks so no deadlock can occur. > + I don't particularly like these function names, with lock implementations the _slow post-fix is typically used for slow path implementations, not API type interfaces. -- 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] xawtv: release buffer if it can't be displayed
Hi, On 04/01/2013 04:39 PM, Hans Verkuil wrote: On Mon April 1 2013 16:23:51 Hans de Goede wrote: Hi, On 04/01/2013 12:19 PM, Hans Verkuil wrote: Hi Hans, On Sun March 31 2013 14:48:01 Hans de Goede wrote: Hi, On 03/30/2013 10:47 AM, Hans Verkuil wrote: This patch for xawtv3 releases the buffer if it can't be displayed because the resolution of the current format is larger than the size of the window. This will happen if the hardware cannot scale down to the initially quite small xawtv window. For example the au0828 driver has a fixed size of 720x480, so it will not display anything until the window is large enough for that resolution. The problem is that xawtv never releases (== calls QBUF) the buffer in that case, and it will of course run out of buffers and stall. The only way to kill it is to issue a 'kill -9' since ctrl-C won't work either. By releasing the buffer xawtv at least remains responsive and a picture will appear after resizing the window. Ideally of course xawtv should resize itself to the minimum supported resolution, but that's left as an exercise for the reader... Hans, the xawtv issues I reported off-list are all caused by this bug and by by the scaling bug introduced recently in em28xx. They had nothing to do with the alsa streaming, that was a red herring. Thanks for the debugging and for the patch. I've pushed the patch to xawtv3.git. I've a 2 patch follow up set which should fix the issue with being able to resize the window to a too small size. I'll send this patch set right after this mail, can you test it with the au0828 please? I've tested it and it is not yet working. I've tracked it down to video_gd_configure where it calls ng_ratio_fixup() which changes the cur_tv_width of 736 to 640. The height remains the same at 480. Thanks for testing and for figuring out where the problem lies. I've attached a second version of the second patch, can you give that a try please? This is now working for au0828, but now vivi is broken... That worked fine with your previous patch. I'm getting: $ xawtv This is xawtv-3.102, running on Linux/x86_64 (3.9.0-rc1-tschai) ioctl: VIDIOC_QUERYMENU(id=134217731;index=2;name="Menu Item 1";reserved=0): Invalid argument vid-open-auto: using grabber/webcam device /dev/video0 libv4l2: error setting pixformat: Device or resource busy ioctl: VIDIOC_S_FMT(type=VIDEO_CAPTURE;fmt.pix.width=384;fmt.pix.height=288;fmt.pix.pixelformat=0x34524742 [BGR4];fmt.pix.field=INTERLACED;fmt.pix.bytesperline=1536;fmt.pix.sizeimage=442368;fmt.pix.colorspace=SRGB;fmt.pix.priv=0): Device or resource busy Note that the QUERYMENU error is harmless, although it would be nice if xawtv would understand menu controls with 'holes' in the menu list. The 'Device or resource busy' errors are new and I didn't have them in your previous version. After much debugging I feel it is safe to say, that these errors are not new, and not caused by my patch. But still a good catch. They are caused by a pre-existing timing dependent bug. I can trigger the problem both with / without my patch by simply starting xawtv with the vivi driver a number of times, and 1 in every 2-5 times it triggers. I've also debugged and fixed this, see the commit message for details: http://git.linuxtv.org/xawtv3.git/commit/f0d84401dfa392ad86d11a76dda1f722269f3eaa I'm going to work on fixing the snapshot function with videobuf2 based drivers next, and when that is fixed I'll do a new xawtv3 release, unless someone yells NOOO before that time. Regards, Hans -- 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: Status of the patches under review at LMML (32 patches)
On Tue, 2 Apr 2013, Laurent Pinchart wrote: > Hi Guennadi, > > On Friday 29 March 2013 16:13:41 Guennadi Liakhovetski wrote: > > Hi Mauro > > > > On Sun, 24 Mar 2013, Mauro Carvalho Chehab wrote: > > > == Guennadi Liakhovetski == > > > > > > I suspect that some of the above may be obsoleted: > > > > > > Nov,13 2012: sh_vou: Move from videobuf to videobuf2 > > > http://patchwork.linuxtv.org/patch/15433 Laurent Pinchart > > > > > dropped for now > > As Renesas doesn't seem to be interested in maintaining the sh-vou driver, > should it be marked as 'Odd Fixes' in the MAINTAINERS file ? I wouldn't nak such a patch ;-) 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: [PATCH v2] davinci: vpif: add pm_runtime support
On Mon 1 April 2013 08:36:50 Prabhakar lad wrote:
> From: Lad, Prabhakar
>
> Add pm_runtime support to the TI Davinci VPIF driver.
>
> Signed-off-by: Lad, Prabhakar
> Cc: Mauro Carvalho Chehab
> Cc: Hans Verkuil
> Cc: Laurent Pinchart
> Cc: Sakari Ailus
> Cc: Sekhar Nori
> ---
> Changes for v2:
> 1: Removed use of clk API as pointed by Laurent and Sekhar.
>
> drivers/media/platform/davinci/vpif.c | 24 +++-
> 1 files changed, 7 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/media/platform/davinci/vpif.c
> b/drivers/media/platform/davinci/vpif.c
> index 28638a8..599cabb 100644
> --- a/drivers/media/platform/davinci/vpif.c
> +++ b/drivers/media/platform/davinci/vpif.c
> @@ -23,8 +23,8 @@
> #include
> #include
> #include
> -#include
> #include
> +#include
> #include
>
> #include
> @@ -44,7 +44,6 @@ static struct resource *res;
> spinlock_t vpif_lock;
>
> void __iomem *vpif_base;
> -struct clk *vpif_clk;
>
> /**
> * ch_params: video standard configuration parameters for vpif
> @@ -439,19 +438,15 @@ static int vpif_probe(struct platform_device *pdev)
> goto fail;
> }
>
> - vpif_clk = clk_get(&pdev->dev, "vpif");
> - if (IS_ERR(vpif_clk)) {
> - status = PTR_ERR(vpif_clk);
> - goto clk_fail;
> - }
> - clk_prepare_enable(vpif_clk);
> + pm_runtime_enable(&pdev->dev);
> + pm_runtime_resume(&pdev->dev);
> +
> + pm_runtime_get(&pdev->dev);
pm_runtime_get() calls pm_runtime_resume() if needed, so is the call to resume()
really necessary?
Regards,
Hans
>
> spin_lock_init(&vpif_lock);
> dev_info(&pdev->dev, "vpif probe success\n");
> return 0;
>
> -clk_fail:
> - iounmap(vpif_base);
> fail:
> release_mem_region(res->start, res_len);
> return status;
> @@ -459,11 +454,6 @@ fail:
>
> static int vpif_remove(struct platform_device *pdev)
> {
> - if (vpif_clk) {
> - clk_disable_unprepare(vpif_clk);
> - clk_put(vpif_clk);
> - }
> -
> iounmap(vpif_base);
> release_mem_region(res->start, res_len);
> return 0;
> @@ -472,13 +462,13 @@ static int vpif_remove(struct platform_device *pdev)
> #ifdef CONFIG_PM
> static int vpif_suspend(struct device *dev)
> {
> - clk_disable_unprepare(vpif_clk);
> + pm_runtime_put(dev);
> return 0;
> }
>
> static int vpif_resume(struct device *dev)
> {
> - clk_prepare_enable(vpif_clk);
> + pm_runtime_get(dev);
> return 0;
> }
>
>
--
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
[RFC] [media] dvb-core: check ->msg_len for diseqc_send_master_cmd()
I'd like to send this patch except that it "breaks"
cx24116_send_diseqc_msg(). The cx24116 driver accepts ->msg_len values
up to 24 but it looks like it's just copying 16 bytes past the end of
the ->msg[] array so it's already broken.
cmd->msg_len is an unsigned char. The comment next to the struct
declaration says that valid values are are 3-6. Some of the drivers
check that this is true, but most don't and it could cause memory
corruption.
Some examples of functions which don't check are:
ttusbdecfe_dvbs_diseqc_send_master_cmd()
cx24123_send_diseqc_msg()
ds3000_send_diseqc_msg()
etc.
Signed-off-by: Dan Carpenter
diff --git a/drivers/media/dvb-core/dvb_frontend.c
b/drivers/media/dvb-core/dvb_frontend.c
index 57601c0..3d1eee6 100644
--- a/drivers/media/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb-core/dvb_frontend.c
@@ -2265,7 +2265,13 @@ static int dvb_frontend_ioctl_legacy(struct file *file,
case FE_DISEQC_SEND_MASTER_CMD:
if (fe->ops.diseqc_send_master_cmd) {
- err = fe->ops.diseqc_send_master_cmd(fe, (struct
dvb_diseqc_master_cmd*) parg);
+ struct dvb_diseqc_master_cmd *cmd = parg;
+
+ if (cmd->msg_len >= 3 && cmd->msg_len <= 6)
+ err = fe->ops.diseqc_send_master_cmd(fe, cmd);
+ else
+ err = -EINVAL;
+
fepriv->state = FESTATE_DISEQC;
fepriv->status = 0;
}
--
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
