[PATCH] DVB-APPS: azap gets -p argument
Hey there, I've written a patch against the latest version of azap in the hg repository during the work of my Archos Gen8 DVB-T / ATSC project. Details of patch: - add -p argument from tzap to azap - thus ts streaming to dvr0 includes the pat/pmt Best regards, Chris azap_patpmt.patch Description: Binary data
Re: [patch] Fix AF9015 Dual tuner i2c write failures
On 5 March 2011 01:43, adq wrote: > On 4 March 2011 23:11, Andrew de Quincey wrote: >> On 4 March 2011 22:59, Antti Palosaari wrote: >>> On 03/05/2011 12:44 AM, Andrew de Quincey wrote: >> >> Adding a "bus lock" to af9015_i2c_xfer() will not work as demod/tuner >> accesses will take multiple i2c transactions. >> >> Therefore, the following patch overrides the dvb_frontend_ops >> functions to add a per-device lock around them: only one frontend can >> now use the i2c bus at a time. Testing with the scripts above shows >> this has eliminated the errors. > > This have annoyed me too, but since it does not broken functionality much > I > haven't put much effort for fixing it. I like that fix since it is in > AF9015 > driver where it logically belongs to. But it looks still rather complex. > I > see you have also considered "bus lock" to af9015_i2c_xfer() which could > be > much smaller in code size (that's I have tried to implement long time > back). > > I would like to ask if it possible to check I2C gate open / close inside > af9015_i2c_xfer() and lock according that? Something like: Hmm, I did think about that, but I felt overriding the functions was just cleaner: I felt it was more obvious what it was doing. Doing exactly this sort of tweaking was one of the main reasons we added that function overriding feature. I don't like the idea of returning "error locked by FE" since that'll mean the tuning will randomly fail sometimes in a way visible to userspace (unless we change the core dvb_frontend code), which was one of the things I was trying to avoid. Unless, of course, I've misunderstood your proposal. >>> >>> Not returning error, but waiting in lock like that: >>> if (mutex_lock_interruptible(&d->i2c_mutex) < 0) >>> return -EAGAIN; >> >> Ah k, sorry >> However, looking at the code again, I realise it is possible to simplify it. Since its only the demod gates that cause a problem, we only /actually/ need to lock the get_frontend() and set_frontend() calls. >>> >>> I don't understand why .get_frontend() causes problem, since it does not >>> access tuner at all. It only reads demod registers. The main problem is >>> (like schema in af9015.c shows) that there is two tuners on same I2C bus >>> using same address. And demod gate is only way to open access for desired >>> tuner only. >> >> AFAIR /some/ tuner code accesses the tuner hardware to read the exact >> tuned frequency back on a get_frontend(); was just being extra >> paranoid :) >> >>> You should block traffic based of tuner not demod. And I think those >>> callbacks which are needed for override are tuner driver callbacks. Consider >>> situation device goes it v4l-core calls same time both tuner .sleep() == >>> problem. >> >> Hmm, yeah, you're right, let me have another look tomorrow. >> > > Hi, must admit I misunderstood your diagram originally, I thought it > was the demods AND the tuners that had the same i2c addresses. > > As you say though. its just the tuners, so adding the locking into the > gate ctrl as you suggested makes perfect sense. Attached is v3 > implementing this; it seems to be working fine here. > Unfortunately even with this fix, I'm still seeing the problem I was trying to fix to begin with. Although I no longer get any i2c errors (or *any* reported errors), after a bit, one of the frontends just.. stops working. All attempts to tune it fail. I can even unload and reload the driver module, and its stuck in the same state, indicating its a problem with the hardware. :( -- 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] Fix AF9015 Dual tuner i2c write failures
On 4 March 2011 23:11, Andrew de Quincey wrote:
> On 4 March 2011 22:59, Antti Palosaari wrote:
>> On 03/05/2011 12:44 AM, Andrew de Quincey wrote:
>
> Adding a "bus lock" to af9015_i2c_xfer() will not work as demod/tuner
> accesses will take multiple i2c transactions.
>
> Therefore, the following patch overrides the dvb_frontend_ops
> functions to add a per-device lock around them: only one frontend can
> now use the i2c bus at a time. Testing with the scripts above shows
> this has eliminated the errors.
This have annoyed me too, but since it does not broken functionality much
I
haven't put much effort for fixing it. I like that fix since it is in
AF9015
driver where it logically belongs to. But it looks still rather complex.
I
see you have also considered "bus lock" to af9015_i2c_xfer() which could
be
much smaller in code size (that's I have tried to implement long time
back).
I would like to ask if it possible to check I2C gate open / close inside
af9015_i2c_xfer() and lock according that? Something like:
>>>
>>> Hmm, I did think about that, but I felt overriding the functions was
>>> just cleaner: I felt it was more obvious what it was doing. Doing
>>> exactly this sort of tweaking was one of the main reasons we added
>>> that function overriding feature.
>>>
>>> I don't like the idea of returning "error locked by FE" since that'll
>>> mean the tuning will randomly fail sometimes in a way visible to
>>> userspace (unless we change the core dvb_frontend code), which was one
>>> of the things I was trying to avoid. Unless, of course, I've
>>> misunderstood your proposal.
>>
>> Not returning error, but waiting in lock like that:
>> if (mutex_lock_interruptible(&d->i2c_mutex) < 0)
>> return -EAGAIN;
>
> Ah k, sorry
>
>>> However, looking at the code again, I realise it is possible to
>>> simplify it. Since its only the demod gates that cause a problem, we
>>> only /actually/ need to lock the get_frontend() and set_frontend()
>>> calls.
>>
>> I don't understand why .get_frontend() causes problem, since it does not
>> access tuner at all. It only reads demod registers. The main problem is
>> (like schema in af9015.c shows) that there is two tuners on same I2C bus
>> using same address. And demod gate is only way to open access for desired
>> tuner only.
>
> AFAIR /some/ tuner code accesses the tuner hardware to read the exact
> tuned frequency back on a get_frontend(); was just being extra
> paranoid :)
>
>> You should block traffic based of tuner not demod. And I think those
>> callbacks which are needed for override are tuner driver callbacks. Consider
>> situation device goes it v4l-core calls same time both tuner .sleep() ==
>> problem.
>
> Hmm, yeah, you're right, let me have another look tomorrow.
>
Hi, must admit I misunderstood your diagram originally, I thought it
was the demods AND the tuners that had the same i2c addresses.
As you say though. its just the tuners, so adding the locking into the
gate ctrl as you suggested makes perfect sense. Attached is v3
implementing this; it seems to be working fine here.
diff --git a/drivers/media/dvb/dvb-usb/af9015.c b/drivers/media/dvb/dvb-usb/af9015.c
index 31c0a0e..d9f32fe 100644
--- a/drivers/media/dvb/dvb-usb/af9015.c
+++ b/drivers/media/dvb/dvb-usb/af9015.c
@@ -1083,6 +1083,24 @@ static int af9015_i2c_init(struct dvb_usb_device *d)
return ret;
}
+static int af9015_lock_i2c_gate_ctrl(struct dvb_frontend *fe, int enable)
+{
+ int result;
+ struct dvb_usb_adapter *adap = fe->dvb->priv;
+ struct af9015_state *state = adap->dev->priv;
+
+ if (enable)
+ if (mutex_lock_interruptible(&adap->dev->usb_mutex))
+ return -EAGAIN;
+
+ result = state->i2c_gate_ctrl[adap->id](fe, enable);
+
+ if (!enable)
+ mutex_unlock(&adap->dev->usb_mutex);
+
+ return result;
+}
+
static int af9015_af9013_frontend_attach(struct dvb_usb_adapter *adap)
{
int ret;
@@ -1116,6 +1134,11 @@ static int af9015_af9013_frontend_attach(struct dvb_usb_adapter *adap)
/* attach demodulator */
adap->fe = dvb_attach(af9013_attach, &af9015_af9013_config[adap->id],
i2c_adap);
+
+ if (adap->fe && adap->fe->ops.i2c_gate_ctrl) {
+ state->i2c_gate_ctrl[adap->id] = adap->fe->ops.i2c_gate_ctrl;
+ adap->fe->ops.i2c_gate_ctrl = af9015_lock_i2c_gate_ctrl;
+ }
return adap->fe == NULL ? -ENODEV : 0;
}
diff --git a/drivers/media/dvb/dvb-usb/af9015.h b/drivers/media/dvb/dvb-usb/af9015.h
index f20cfa6..094b1e3 100644
--- a/drivers/media/dvb/dvb-usb/af9015.h
+++ b/drivers/media/dvb/dvb-usb/af9015.h
@@ -102,6 +102,7 @@ struct af9015_state {
struct i2c_adapter i2c_adap; /* I2C adapter for 2nd FE */
u8 rc_repeat;
u32 rc_keycode;
+ int (*i2c_gate_ctrl[2])(struct dvb_frontend *fe, int enable);
};
struct af9015_config {
Re: [GIT PULL FOR 2.6.39] Media controller and OMAP3 ISP driver
On Sat, Mar 5, 2011 at 1:49 AM, Mauro Carvalho Chehab wrote: > Em 04-03-2011 19:49, David Cohen escreveu: >> On Sat, Mar 5, 2011 at 12:43 AM, Mauro Carvalho Chehab >> wrote: >>> Em 04-03-2011 19:33, David Cohen escreveu: Hi Mauro, On Sat, Mar 5, 2011 at 12:16 AM, Mauro Carvalho Chehab wrote: > Hi Laurent, > > Em 17-02-2011 13:06, Laurent Pinchart escreveu: >> Hi Mauro, >> >> The following changes since commit >> 85e2efbb1db9a18d218006706d6e4fbeb0216213: >> >> Linux 2.6.38-rc5 (2011-02-15 19:23:45 -0800) >> >> are available in the git repository at: >> git://linuxtv.org/pinchartl/media.git media-0005-omap3isp > > I've added the patches that looked ok on my eyes at: > > http://git.linuxtv.org/mchehab/experimental.git?a=shortlog;h=refs/heads/media_controller > > There are just a few small adjustments on a few of them, as I've > commented. > I prefer if you do them on separate patches, to save my work of not > needing > to review the entire series again. > > The ones still pending on my quilt tree are: > > 0030-v4l-subdev-Generic-ioctl-support.patch > 0040-omap3isp-OMAP3-ISP-core.patch > 0041-omap3isp-Video-devices-and-buffers-queue.patch > 0042-omap3isp-CCP2-CSI2-receivers.patch > 0043-omap3isp-CCDC-preview-engine-and-resizer.patch > 0044-omap3isp-Statistics.patch > 0045-omap3isp-Kconfig-and-Makefile.patch > 0046-omap3isp-Add-set-performance-callback-in-isp-platfor.patch > > with the following diffstat: > > Documentation/video4linux/v4l2-framework.txt | 5 + > MAINTAINERS | 6 + > drivers/media/video/Kconfig | 13 + > drivers/media/video/Makefile | 2 + > drivers/media/video/omap3-isp/Makefile | 13 + > drivers/media/video/omap3-isp/cfa_coef_table.h | 61 + > drivers/media/video/omap3-isp/gamma_table.h | 90 + > drivers/media/video/omap3-isp/isp.c | 2220 > +++ > drivers/media/video/omap3-isp/isp.h | 428 > drivers/media/video/omap3-isp/ispccdc.c | 2268 > > drivers/media/video/omap3-isp/ispccdc.h | 219 ++ > drivers/media/video/omap3-isp/ispccp2.c | 1173 ++ > drivers/media/video/omap3-isp/ispccp2.h | 98 + > drivers/media/video/omap3-isp/ispcsi2.c | 1317 > drivers/media/video/omap3-isp/ispcsi2.h | 166 ++ > drivers/media/video/omap3-isp/ispcsiphy.c | 247 +++ > drivers/media/video/omap3-isp/ispcsiphy.h | 74 + > drivers/media/video/omap3-isp/isph3a.h | 117 + > drivers/media/video/omap3-isp/isph3a_aewb.c | 374 > drivers/media/video/omap3-isp/isph3a_af.c | 429 > drivers/media/video/omap3-isp/isphist.c | 520 + > drivers/media/video/omap3-isp/isphist.h | 40 + > drivers/media/video/omap3-isp/isppreview.c | 2113 > ++ > drivers/media/video/omap3-isp/isppreview.h | 214 ++ > drivers/media/video/omap3-isp/ispqueue.c | 1153 ++ > drivers/media/video/omap3-isp/ispqueue.h | 187 ++ > drivers/media/video/omap3-isp/ispreg.h | 1589 ++ > drivers/media/video/omap3-isp/ispresizer.c | 1693 +++ > drivers/media/video/omap3-isp/ispresizer.h | 147 ++ > drivers/media/video/omap3-isp/ispstat.c | 1092 ++ > drivers/media/video/omap3-isp/ispstat.h | 169 ++ > drivers/media/video/omap3-isp/ispvideo.c | 1255 +++ > drivers/media/video/omap3-isp/ispvideo.h | 202 ++ > drivers/media/video/omap3-isp/luma_enhance_table.h | 42 + > drivers/media/video/omap3-isp/noise_filter_table.h | 30 + > drivers/media/video/v4l2-subdev.c | 2 +- > drivers/media/video/videobuf-dma-contig.c | 2 +- > include/linux/Kbuild | 1 + > 38 files changed, 19769 insertions(+), 2 deletions(-) > > I used quilt for all patches, except for the one patch with some gifs, > where I did a > git cherry-pick. So, the imported patches should be ok. Of course, it > doesn't hurt > do double check. > > The main issue with the omap3isp is due to the presence of private > ioctl's that > I don't have a clear idea about what they are really doing. > > I couldn't see any documentation about them on a very quick look. While I > suspect > that they are used only for 3A, I have no means of being sure about that. > > Also, as I've said several times, whi
Re: [GIT PULL FOR 2.6.39] Media controller and OMAP3 ISP driver
Em 04-03-2011 19:49, David Cohen escreveu: > On Sat, Mar 5, 2011 at 12:43 AM, Mauro Carvalho Chehab > wrote: >> Em 04-03-2011 19:33, David Cohen escreveu: >>> Hi Mauro, >>> >>> On Sat, Mar 5, 2011 at 12:16 AM, Mauro Carvalho Chehab >>> wrote: Hi Laurent, Em 17-02-2011 13:06, Laurent Pinchart escreveu: > Hi Mauro, > > The following changes since commit > 85e2efbb1db9a18d218006706d6e4fbeb0216213: > > Linux 2.6.38-rc5 (2011-02-15 19:23:45 -0800) > > are available in the git repository at: > git://linuxtv.org/pinchartl/media.git media-0005-omap3isp I've added the patches that looked ok on my eyes at: http://git.linuxtv.org/mchehab/experimental.git?a=shortlog;h=refs/heads/media_controller There are just a few small adjustments on a few of them, as I've commented. I prefer if you do them on separate patches, to save my work of not needing to review the entire series again. The ones still pending on my quilt tree are: 0030-v4l-subdev-Generic-ioctl-support.patch 0040-omap3isp-OMAP3-ISP-core.patch 0041-omap3isp-Video-devices-and-buffers-queue.patch 0042-omap3isp-CCP2-CSI2-receivers.patch 0043-omap3isp-CCDC-preview-engine-and-resizer.patch 0044-omap3isp-Statistics.patch 0045-omap3isp-Kconfig-and-Makefile.patch 0046-omap3isp-Add-set-performance-callback-in-isp-platfor.patch with the following diffstat: Documentation/video4linux/v4l2-framework.txt |5 + MAINTAINERS|6 + drivers/media/video/Kconfig| 13 + drivers/media/video/Makefile |2 + drivers/media/video/omap3-isp/Makefile | 13 + drivers/media/video/omap3-isp/cfa_coef_table.h | 61 + drivers/media/video/omap3-isp/gamma_table.h| 90 + drivers/media/video/omap3-isp/isp.c| 2220 +++ drivers/media/video/omap3-isp/isp.h| 428 drivers/media/video/omap3-isp/ispccdc.c| 2268 drivers/media/video/omap3-isp/ispccdc.h| 219 ++ drivers/media/video/omap3-isp/ispccp2.c| 1173 ++ drivers/media/video/omap3-isp/ispccp2.h| 98 + drivers/media/video/omap3-isp/ispcsi2.c| 1317 drivers/media/video/omap3-isp/ispcsi2.h| 166 ++ drivers/media/video/omap3-isp/ispcsiphy.c | 247 +++ drivers/media/video/omap3-isp/ispcsiphy.h | 74 + drivers/media/video/omap3-isp/isph3a.h | 117 + drivers/media/video/omap3-isp/isph3a_aewb.c| 374 drivers/media/video/omap3-isp/isph3a_af.c | 429 drivers/media/video/omap3-isp/isphist.c| 520 + drivers/media/video/omap3-isp/isphist.h| 40 + drivers/media/video/omap3-isp/isppreview.c | 2113 ++ drivers/media/video/omap3-isp/isppreview.h | 214 ++ drivers/media/video/omap3-isp/ispqueue.c | 1153 ++ drivers/media/video/omap3-isp/ispqueue.h | 187 ++ drivers/media/video/omap3-isp/ispreg.h | 1589 ++ drivers/media/video/omap3-isp/ispresizer.c | 1693 +++ drivers/media/video/omap3-isp/ispresizer.h | 147 ++ drivers/media/video/omap3-isp/ispstat.c| 1092 ++ drivers/media/video/omap3-isp/ispstat.h| 169 ++ drivers/media/video/omap3-isp/ispvideo.c | 1255 +++ drivers/media/video/omap3-isp/ispvideo.h | 202 ++ drivers/media/video/omap3-isp/luma_enhance_table.h | 42 + drivers/media/video/omap3-isp/noise_filter_table.h | 30 + drivers/media/video/v4l2-subdev.c |2 +- drivers/media/video/videobuf-dma-contig.c |2 +- include/linux/Kbuild |1 + 38 files changed, 19769 insertions(+), 2 deletions(-) I used quilt for all patches, except for the one patch with some gifs, where I did a git cherry-pick. So, the imported patches should be ok. Of course, it doesn't hurt do double check. The main issue with the omap3isp is due to the presence of private ioctl's that I don't have a clear idea about what they are really doing. I couldn't see any documentation about them on a very quick look. While I suspect that they are used only for 3A, I have no means of being sure about that. Also, as I've said several times, while I don't like, I have nothing against having some ioctls that would be used by a vendor to implement their own 3A software algorithms that he may need to
Re: [patch] Fix AF9015 Dual tuner i2c write failures
On 4 March 2011 22:59, Antti Palosaari wrote: > On 03/05/2011 12:44 AM, Andrew de Quincey wrote: Adding a "bus lock" to af9015_i2c_xfer() will not work as demod/tuner accesses will take multiple i2c transactions. Therefore, the following patch overrides the dvb_frontend_ops functions to add a per-device lock around them: only one frontend can now use the i2c bus at a time. Testing with the scripts above shows this has eliminated the errors. >>> >>> This have annoyed me too, but since it does not broken functionality much >>> I >>> haven't put much effort for fixing it. I like that fix since it is in >>> AF9015 >>> driver where it logically belongs to. But it looks still rather complex. >>> I >>> see you have also considered "bus lock" to af9015_i2c_xfer() which could >>> be >>> much smaller in code size (that's I have tried to implement long time >>> back). >>> >>> I would like to ask if it possible to check I2C gate open / close inside >>> af9015_i2c_xfer() and lock according that? Something like: >> >> Hmm, I did think about that, but I felt overriding the functions was >> just cleaner: I felt it was more obvious what it was doing. Doing >> exactly this sort of tweaking was one of the main reasons we added >> that function overriding feature. >> >> I don't like the idea of returning "error locked by FE" since that'll >> mean the tuning will randomly fail sometimes in a way visible to >> userspace (unless we change the core dvb_frontend code), which was one >> of the things I was trying to avoid. Unless, of course, I've >> misunderstood your proposal. > > Not returning error, but waiting in lock like that: > if (mutex_lock_interruptible(&d->i2c_mutex) < 0) > return -EAGAIN; Ah k, sorry >> However, looking at the code again, I realise it is possible to >> simplify it. Since its only the demod gates that cause a problem, we >> only /actually/ need to lock the get_frontend() and set_frontend() >> calls. > > I don't understand why .get_frontend() causes problem, since it does not > access tuner at all. It only reads demod registers. The main problem is > (like schema in af9015.c shows) that there is two tuners on same I2C bus > using same address. And demod gate is only way to open access for desired > tuner only. AFAIR /some/ tuner code accesses the tuner hardware to read the exact tuned frequency back on a get_frontend(); was just being extra paranoid :) > You should block traffic based of tuner not demod. And I think those > callbacks which are needed for override are tuner driver callbacks. Consider > situation device goes it v4l-core calls same time both tuner .sleep() == > problem. Hmm, yeah, you're right, let me have another look tomorrow. -- 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] Fix AF9015 Dual tuner i2c write failures
On 03/05/2011 12:44 AM, Andrew de Quincey wrote: Adding a "bus lock" to af9015_i2c_xfer() will not work as demod/tuner accesses will take multiple i2c transactions. Therefore, the following patch overrides the dvb_frontend_ops functions to add a per-device lock around them: only one frontend can now use the i2c bus at a time. Testing with the scripts above shows this has eliminated the errors. This have annoyed me too, but since it does not broken functionality much I haven't put much effort for fixing it. I like that fix since it is in AF9015 driver where it logically belongs to. But it looks still rather complex. I see you have also considered "bus lock" to af9015_i2c_xfer() which could be much smaller in code size (that's I have tried to implement long time back). I would like to ask if it possible to check I2C gate open / close inside af9015_i2c_xfer() and lock according that? Something like: Hmm, I did think about that, but I felt overriding the functions was just cleaner: I felt it was more obvious what it was doing. Doing exactly this sort of tweaking was one of the main reasons we added that function overriding feature. I don't like the idea of returning "error locked by FE" since that'll mean the tuning will randomly fail sometimes in a way visible to userspace (unless we change the core dvb_frontend code), which was one of the things I was trying to avoid. Unless, of course, I've misunderstood your proposal. Not returning error, but waiting in lock like that: if (mutex_lock_interruptible(&d->i2c_mutex) < 0) return -EAGAIN; However, looking at the code again, I realise it is possible to simplify it. Since its only the demod gates that cause a problem, we only /actually/ need to lock the get_frontend() and set_frontend() calls. I don't understand why .get_frontend() causes problem, since it does not access tuner at all. It only reads demod registers. The main problem is (like schema in af9015.c shows) that there is two tuners on same I2C bus using same address. And demod gate is only way to open access for desired tuner only. You should block traffic based of tuner not demod. And I think those callbacks which are needed for override are tuner driver callbacks. Consider situation device goes it v4l-core calls same time both tuner .sleep() == problem. Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL FOR 2.6.39] Media controller and OMAP3 ISP driver
On Sat, Mar 5, 2011 at 12:43 AM, Mauro Carvalho Chehab wrote: > Em 04-03-2011 19:33, David Cohen escreveu: >> Hi Mauro, >> >> On Sat, Mar 5, 2011 at 12:16 AM, Mauro Carvalho Chehab >> wrote: >>> Hi Laurent, >>> >>> Em 17-02-2011 13:06, Laurent Pinchart escreveu: Hi Mauro, The following changes since commit 85e2efbb1db9a18d218006706d6e4fbeb0216213: Linux 2.6.38-rc5 (2011-02-15 19:23:45 -0800) are available in the git repository at: git://linuxtv.org/pinchartl/media.git media-0005-omap3isp >>> >>> I've added the patches that looked ok on my eyes at: >>> >>> http://git.linuxtv.org/mchehab/experimental.git?a=shortlog;h=refs/heads/media_controller >>> >>> There are just a few small adjustments on a few of them, as I've commented. >>> I prefer if you do them on separate patches, to save my work of not needing >>> to review the entire series again. >>> >>> The ones still pending on my quilt tree are: >>> >>> 0030-v4l-subdev-Generic-ioctl-support.patch >>> 0040-omap3isp-OMAP3-ISP-core.patch >>> 0041-omap3isp-Video-devices-and-buffers-queue.patch >>> 0042-omap3isp-CCP2-CSI2-receivers.patch >>> 0043-omap3isp-CCDC-preview-engine-and-resizer.patch >>> 0044-omap3isp-Statistics.patch >>> 0045-omap3isp-Kconfig-and-Makefile.patch >>> 0046-omap3isp-Add-set-performance-callback-in-isp-platfor.patch >>> >>> with the following diffstat: >>> >>> Documentation/video4linux/v4l2-framework.txt | 5 + >>> MAINTAINERS | 6 + >>> drivers/media/video/Kconfig | 13 + >>> drivers/media/video/Makefile | 2 + >>> drivers/media/video/omap3-isp/Makefile | 13 + >>> drivers/media/video/omap3-isp/cfa_coef_table.h | 61 + >>> drivers/media/video/omap3-isp/gamma_table.h | 90 + >>> drivers/media/video/omap3-isp/isp.c | 2220 >>> +++ >>> drivers/media/video/omap3-isp/isp.h | 428 >>> drivers/media/video/omap3-isp/ispccdc.c | 2268 >>> >>> drivers/media/video/omap3-isp/ispccdc.h | 219 ++ >>> drivers/media/video/omap3-isp/ispccp2.c | 1173 ++ >>> drivers/media/video/omap3-isp/ispccp2.h | 98 + >>> drivers/media/video/omap3-isp/ispcsi2.c | 1317 >>> drivers/media/video/omap3-isp/ispcsi2.h | 166 ++ >>> drivers/media/video/omap3-isp/ispcsiphy.c | 247 +++ >>> drivers/media/video/omap3-isp/ispcsiphy.h | 74 + >>> drivers/media/video/omap3-isp/isph3a.h | 117 + >>> drivers/media/video/omap3-isp/isph3a_aewb.c | 374 >>> drivers/media/video/omap3-isp/isph3a_af.c | 429 >>> drivers/media/video/omap3-isp/isphist.c | 520 + >>> drivers/media/video/omap3-isp/isphist.h | 40 + >>> drivers/media/video/omap3-isp/isppreview.c | 2113 >>> ++ >>> drivers/media/video/omap3-isp/isppreview.h | 214 ++ >>> drivers/media/video/omap3-isp/ispqueue.c | 1153 ++ >>> drivers/media/video/omap3-isp/ispqueue.h | 187 ++ >>> drivers/media/video/omap3-isp/ispreg.h | 1589 ++ >>> drivers/media/video/omap3-isp/ispresizer.c | 1693 +++ >>> drivers/media/video/omap3-isp/ispresizer.h | 147 ++ >>> drivers/media/video/omap3-isp/ispstat.c | 1092 ++ >>> drivers/media/video/omap3-isp/ispstat.h | 169 ++ >>> drivers/media/video/omap3-isp/ispvideo.c | 1255 +++ >>> drivers/media/video/omap3-isp/ispvideo.h | 202 ++ >>> drivers/media/video/omap3-isp/luma_enhance_table.h | 42 + >>> drivers/media/video/omap3-isp/noise_filter_table.h | 30 + >>> drivers/media/video/v4l2-subdev.c | 2 +- >>> drivers/media/video/videobuf-dma-contig.c | 2 +- >>> include/linux/Kbuild | 1 + >>> 38 files changed, 19769 insertions(+), 2 deletions(-) >>> >>> I used quilt for all patches, except for the one patch with some gifs, >>> where I did a >>> git cherry-pick. So, the imported patches should be ok. Of course, it >>> doesn't hurt >>> do double check. >>> >>> The main issue with the omap3isp is due to the presence of private ioctl's >>> that >>> I don't have a clear idea about what they are really doing. >>> >>> I couldn't see any documentation about them on a very quick look. While I >>> suspect >>> that they are used only for 3A, I have no means of being sure about that. >>> >>> Also, as I've said several times, while I don't like, I have nothing against >>> having some ioctls that would be used by a vendor to implement their own 3A >>> software >>> algorithms that he may need to hide for some reason or have any patents >>> applied to >>> the algorithm, but only if: >>> 1) such algorithms are implemented on userspace; >>
Re: [patch] Fix AF9015 Dual tuner i2c write failures
>> Adding a "bus lock" to af9015_i2c_xfer() will not work as demod/tuner
>> accesses will take multiple i2c transactions.
>>
>> Therefore, the following patch overrides the dvb_frontend_ops
>> functions to add a per-device lock around them: only one frontend can
>> now use the i2c bus at a time. Testing with the scripts above shows
>> this has eliminated the errors.
>
> This have annoyed me too, but since it does not broken functionality much I
> haven't put much effort for fixing it. I like that fix since it is in AF9015
> driver where it logically belongs to. But it looks still rather complex. I
> see you have also considered "bus lock" to af9015_i2c_xfer() which could be
> much smaller in code size (that's I have tried to implement long time back).
>
> I would like to ask if it possible to check I2C gate open / close inside
> af9015_i2c_xfer() and lock according that? Something like:
Hmm, I did think about that, but I felt overriding the functions was
just cleaner: I felt it was more obvious what it was doing. Doing
exactly this sort of tweaking was one of the main reasons we added
that function overriding feature.
I don't like the idea of returning "error locked by FE" since that'll
mean the tuning will randomly fail sometimes in a way visible to
userspace (unless we change the core dvb_frontend code), which was one
of the things I was trying to avoid. Unless, of course, I've
misunderstood your proposal.
However, looking at the code again, I realise it is possible to
simplify it. Since its only the demod gates that cause a problem, we
only /actually/ need to lock the get_frontend() and set_frontend()
calls.
Signed-off-by: Andrew de Quincey
diff --git a/drivers/media/dvb/dvb-usb/af9015.c b/drivers/media/dvb/dvb-usb/af9015.c
index 31c0a0e..52ac6ef 100644
--- a/drivers/media/dvb/dvb-usb/af9015.c
+++ b/drivers/media/dvb/dvb-usb/af9015.c
@@ -1083,6 +1083,34 @@ static int af9015_i2c_init(struct dvb_usb_device *d)
return ret;
}
+static int af9015_lock_set_frontend(struct dvb_frontend* fe, struct dvb_frontend_parameters* params)
+{
+ int result;
+ struct dvb_usb_adapter *adap = fe->dvb->priv;
+ struct af9015_state *state = adap->dev->priv;
+
+ if (mutex_lock_interruptible(&adap->dev->usb_mutex))
+ return -EAGAIN;
+
+ result = state->fe_ops[adap->id].set_frontend(fe, params);
+ mutex_unlock(&adap->dev->usb_mutex);
+ return result;
+}
+
+static int af9015_lock_get_frontend(struct dvb_frontend* fe, struct dvb_frontend_parameters* params)
+{
+ int result;
+ struct dvb_usb_adapter *adap = fe->dvb->priv;
+ struct af9015_state *state = adap->dev->priv;
+
+ if (mutex_lock_interruptible(&adap->dev->usb_mutex))
+ return -EAGAIN;
+
+ result = state->fe_ops[adap->id].get_frontend(fe, params);
+ mutex_unlock(&adap->dev->usb_mutex);
+ return result;
+}
+
static int af9015_af9013_frontend_attach(struct dvb_usb_adapter *adap)
{
int ret;
@@ -1116,6 +1144,12 @@ static int af9015_af9013_frontend_attach(struct dvb_usb_adapter *adap)
/* attach demodulator */
adap->fe = dvb_attach(af9013_attach, &af9015_af9013_config[adap->id],
i2c_adap);
+
+ memcpy(&state->fe_ops[adap->id], &adap->fe->ops, sizeof(struct dvb_frontend_ops));
+ if (adap->fe->ops.set_frontend)
+ adap->fe->ops.set_frontend = af9015_lock_set_frontend;
+ if (adap->fe->ops.get_frontend)
+ adap->fe->ops.get_frontend = af9015_lock_get_frontend;
return adap->fe == NULL ? -ENODEV : 0;
}
diff --git a/drivers/media/dvb/dvb-usb/af9015.h b/drivers/media/dvb/dvb-usb/af9015.h
index f20cfa6..759bb3f 100644
--- a/drivers/media/dvb/dvb-usb/af9015.h
+++ b/drivers/media/dvb/dvb-usb/af9015.h
@@ -102,6 +102,7 @@ struct af9015_state {
struct i2c_adapter i2c_adap; /* I2C adapter for 2nd FE */
u8 rc_repeat;
u32 rc_keycode;
+ struct dvb_frontend_ops fe_ops[2];
};
struct af9015_config {
Re: [GIT PULL FOR 2.6.39] Media controller and OMAP3 ISP driver
Em 04-03-2011 19:33, David Cohen escreveu: > Hi Mauro, > > On Sat, Mar 5, 2011 at 12:16 AM, Mauro Carvalho Chehab > wrote: >> Hi Laurent, >> >> Em 17-02-2011 13:06, Laurent Pinchart escreveu: >>> Hi Mauro, >>> >>> The following changes since commit 85e2efbb1db9a18d218006706d6e4fbeb0216213: >>> >>> Linux 2.6.38-rc5 (2011-02-15 19:23:45 -0800) >>> >>> are available in the git repository at: >>> git://linuxtv.org/pinchartl/media.git media-0005-omap3isp >> >> I've added the patches that looked ok on my eyes at: >> >> http://git.linuxtv.org/mchehab/experimental.git?a=shortlog;h=refs/heads/media_controller >> >> There are just a few small adjustments on a few of them, as I've commented. >> I prefer if you do them on separate patches, to save my work of not needing >> to review the entire series again. >> >> The ones still pending on my quilt tree are: >> >> 0030-v4l-subdev-Generic-ioctl-support.patch >> 0040-omap3isp-OMAP3-ISP-core.patch >> 0041-omap3isp-Video-devices-and-buffers-queue.patch >> 0042-omap3isp-CCP2-CSI2-receivers.patch >> 0043-omap3isp-CCDC-preview-engine-and-resizer.patch >> 0044-omap3isp-Statistics.patch >> 0045-omap3isp-Kconfig-and-Makefile.patch >> 0046-omap3isp-Add-set-performance-callback-in-isp-platfor.patch >> >> with the following diffstat: >> >> Documentation/video4linux/v4l2-framework.txt |5 + >> MAINTAINERS|6 + >> drivers/media/video/Kconfig| 13 + >> drivers/media/video/Makefile |2 + >> drivers/media/video/omap3-isp/Makefile | 13 + >> drivers/media/video/omap3-isp/cfa_coef_table.h | 61 + >> drivers/media/video/omap3-isp/gamma_table.h| 90 + >> drivers/media/video/omap3-isp/isp.c| 2220 >> +++ >> drivers/media/video/omap3-isp/isp.h| 428 >> drivers/media/video/omap3-isp/ispccdc.c| 2268 >> >> drivers/media/video/omap3-isp/ispccdc.h| 219 ++ >> drivers/media/video/omap3-isp/ispccp2.c| 1173 ++ >> drivers/media/video/omap3-isp/ispccp2.h| 98 + >> drivers/media/video/omap3-isp/ispcsi2.c| 1317 >> drivers/media/video/omap3-isp/ispcsi2.h| 166 ++ >> drivers/media/video/omap3-isp/ispcsiphy.c | 247 +++ >> drivers/media/video/omap3-isp/ispcsiphy.h | 74 + >> drivers/media/video/omap3-isp/isph3a.h | 117 + >> drivers/media/video/omap3-isp/isph3a_aewb.c| 374 >> drivers/media/video/omap3-isp/isph3a_af.c | 429 >> drivers/media/video/omap3-isp/isphist.c| 520 + >> drivers/media/video/omap3-isp/isphist.h| 40 + >> drivers/media/video/omap3-isp/isppreview.c | 2113 ++ >> drivers/media/video/omap3-isp/isppreview.h | 214 ++ >> drivers/media/video/omap3-isp/ispqueue.c | 1153 ++ >> drivers/media/video/omap3-isp/ispqueue.h | 187 ++ >> drivers/media/video/omap3-isp/ispreg.h | 1589 ++ >> drivers/media/video/omap3-isp/ispresizer.c | 1693 +++ >> drivers/media/video/omap3-isp/ispresizer.h | 147 ++ >> drivers/media/video/omap3-isp/ispstat.c| 1092 ++ >> drivers/media/video/omap3-isp/ispstat.h| 169 ++ >> drivers/media/video/omap3-isp/ispvideo.c | 1255 +++ >> drivers/media/video/omap3-isp/ispvideo.h | 202 ++ >> drivers/media/video/omap3-isp/luma_enhance_table.h | 42 + >> drivers/media/video/omap3-isp/noise_filter_table.h | 30 + >> drivers/media/video/v4l2-subdev.c |2 +- >> drivers/media/video/videobuf-dma-contig.c |2 +- >> include/linux/Kbuild |1 + >> 38 files changed, 19769 insertions(+), 2 deletions(-) >> >> I used quilt for all patches, except for the one patch with some gifs, where >> I did a >> git cherry-pick. So, the imported patches should be ok. Of course, it >> doesn't hurt >> do double check. >> >> The main issue with the omap3isp is due to the presence of private ioctl's >> that >> I don't have a clear idea about what they are really doing. >> >> I couldn't see any documentation about them on a very quick look. While I >> suspect >> that they are used only for 3A, I have no means of being sure about that. >> >> Also, as I've said several times, while I don't like, I have nothing against >> having some ioctls that would be used by a vendor to implement their own 3A >> software >> algorithms that he may need to hide for some reason or have any patents >> applied to >> the algorithm, but only if: >>1) such algorithms are implemented on userspace; > > Yes. > >>2) the userspace API used by them is fully documented, in order >> to allow that someone else with enough motivation and spare time may >> want to implemen
Re: [GIT PULL FOR 2.6.39] Media controller and OMAP3 ISP driver
Hi Mauro, On Sat, Mar 5, 2011 at 12:16 AM, Mauro Carvalho Chehab wrote: > Hi Laurent, > > Em 17-02-2011 13:06, Laurent Pinchart escreveu: >> Hi Mauro, >> >> The following changes since commit 85e2efbb1db9a18d218006706d6e4fbeb0216213: >> >> Linux 2.6.38-rc5 (2011-02-15 19:23:45 -0800) >> >> are available in the git repository at: >> git://linuxtv.org/pinchartl/media.git media-0005-omap3isp > > I've added the patches that looked ok on my eyes at: > > http://git.linuxtv.org/mchehab/experimental.git?a=shortlog;h=refs/heads/media_controller > > There are just a few small adjustments on a few of them, as I've commented. > I prefer if you do them on separate patches, to save my work of not needing > to review the entire series again. > > The ones still pending on my quilt tree are: > > 0030-v4l-subdev-Generic-ioctl-support.patch > 0040-omap3isp-OMAP3-ISP-core.patch > 0041-omap3isp-Video-devices-and-buffers-queue.patch > 0042-omap3isp-CCP2-CSI2-receivers.patch > 0043-omap3isp-CCDC-preview-engine-and-resizer.patch > 0044-omap3isp-Statistics.patch > 0045-omap3isp-Kconfig-and-Makefile.patch > 0046-omap3isp-Add-set-performance-callback-in-isp-platfor.patch > > with the following diffstat: > > Documentation/video4linux/v4l2-framework.txt | 5 + > MAINTAINERS | 6 + > drivers/media/video/Kconfig | 13 + > drivers/media/video/Makefile | 2 + > drivers/media/video/omap3-isp/Makefile | 13 + > drivers/media/video/omap3-isp/cfa_coef_table.h | 61 + > drivers/media/video/omap3-isp/gamma_table.h | 90 + > drivers/media/video/omap3-isp/isp.c | 2220 +++ > drivers/media/video/omap3-isp/isp.h | 428 > drivers/media/video/omap3-isp/ispccdc.c | 2268 > > drivers/media/video/omap3-isp/ispccdc.h | 219 ++ > drivers/media/video/omap3-isp/ispccp2.c | 1173 ++ > drivers/media/video/omap3-isp/ispccp2.h | 98 + > drivers/media/video/omap3-isp/ispcsi2.c | 1317 > drivers/media/video/omap3-isp/ispcsi2.h | 166 ++ > drivers/media/video/omap3-isp/ispcsiphy.c | 247 +++ > drivers/media/video/omap3-isp/ispcsiphy.h | 74 + > drivers/media/video/omap3-isp/isph3a.h | 117 + > drivers/media/video/omap3-isp/isph3a_aewb.c | 374 > drivers/media/video/omap3-isp/isph3a_af.c | 429 > drivers/media/video/omap3-isp/isphist.c | 520 + > drivers/media/video/omap3-isp/isphist.h | 40 + > drivers/media/video/omap3-isp/isppreview.c | 2113 ++ > drivers/media/video/omap3-isp/isppreview.h | 214 ++ > drivers/media/video/omap3-isp/ispqueue.c | 1153 ++ > drivers/media/video/omap3-isp/ispqueue.h | 187 ++ > drivers/media/video/omap3-isp/ispreg.h | 1589 ++ > drivers/media/video/omap3-isp/ispresizer.c | 1693 +++ > drivers/media/video/omap3-isp/ispresizer.h | 147 ++ > drivers/media/video/omap3-isp/ispstat.c | 1092 ++ > drivers/media/video/omap3-isp/ispstat.h | 169 ++ > drivers/media/video/omap3-isp/ispvideo.c | 1255 +++ > drivers/media/video/omap3-isp/ispvideo.h | 202 ++ > drivers/media/video/omap3-isp/luma_enhance_table.h | 42 + > drivers/media/video/omap3-isp/noise_filter_table.h | 30 + > drivers/media/video/v4l2-subdev.c | 2 +- > drivers/media/video/videobuf-dma-contig.c | 2 +- > include/linux/Kbuild | 1 + > 38 files changed, 19769 insertions(+), 2 deletions(-) > > I used quilt for all patches, except for the one patch with some gifs, where > I did a > git cherry-pick. So, the imported patches should be ok. Of course, it doesn't > hurt > do double check. > > The main issue with the omap3isp is due to the presence of private ioctl's > that > I don't have a clear idea about what they are really doing. > > I couldn't see any documentation about them on a very quick look. While I > suspect > that they are used only for 3A, I have no means of being sure about that. > > Also, as I've said several times, while I don't like, I have nothing against > having some ioctls that would be used by a vendor to implement their own 3A > software > algorithms that he may need to hide for some reason or have any patents > applied to > the algorithm, but only if: > 1) such algorithms are implemented on userspace; Yes. > 2) the userspace API used by them is fully documented, in order > to allow that someone else with enough motivation and spare time may > want to implement his own algorithm (including an open-source one); The API is pretty close to what is found on public OMAP3 TRM. I'd say it's almost to fill registers throug
Re: [GIT PULL FOR 2.6.39] Media controller and OMAP3 ISP driver
Hi Laurent, Em 17-02-2011 13:06, Laurent Pinchart escreveu: > Hi Mauro, > > The following changes since commit 85e2efbb1db9a18d218006706d6e4fbeb0216213: > > Linux 2.6.38-rc5 (2011-02-15 19:23:45 -0800) > > are available in the git repository at: > git://linuxtv.org/pinchartl/media.git media-0005-omap3isp I've added the patches that looked ok on my eyes at: http://git.linuxtv.org/mchehab/experimental.git?a=shortlog;h=refs/heads/media_controller There are just a few small adjustments on a few of them, as I've commented. I prefer if you do them on separate patches, to save my work of not needing to review the entire series again. The ones still pending on my quilt tree are: 0030-v4l-subdev-Generic-ioctl-support.patch 0040-omap3isp-OMAP3-ISP-core.patch 0041-omap3isp-Video-devices-and-buffers-queue.patch 0042-omap3isp-CCP2-CSI2-receivers.patch 0043-omap3isp-CCDC-preview-engine-and-resizer.patch 0044-omap3isp-Statistics.patch 0045-omap3isp-Kconfig-and-Makefile.patch 0046-omap3isp-Add-set-performance-callback-in-isp-platfor.patch with the following diffstat: Documentation/video4linux/v4l2-framework.txt |5 + MAINTAINERS|6 + drivers/media/video/Kconfig| 13 + drivers/media/video/Makefile |2 + drivers/media/video/omap3-isp/Makefile | 13 + drivers/media/video/omap3-isp/cfa_coef_table.h | 61 + drivers/media/video/omap3-isp/gamma_table.h| 90 + drivers/media/video/omap3-isp/isp.c| 2220 +++ drivers/media/video/omap3-isp/isp.h| 428 drivers/media/video/omap3-isp/ispccdc.c| 2268 drivers/media/video/omap3-isp/ispccdc.h| 219 ++ drivers/media/video/omap3-isp/ispccp2.c| 1173 ++ drivers/media/video/omap3-isp/ispccp2.h| 98 + drivers/media/video/omap3-isp/ispcsi2.c| 1317 drivers/media/video/omap3-isp/ispcsi2.h| 166 ++ drivers/media/video/omap3-isp/ispcsiphy.c | 247 +++ drivers/media/video/omap3-isp/ispcsiphy.h | 74 + drivers/media/video/omap3-isp/isph3a.h | 117 + drivers/media/video/omap3-isp/isph3a_aewb.c| 374 drivers/media/video/omap3-isp/isph3a_af.c | 429 drivers/media/video/omap3-isp/isphist.c| 520 + drivers/media/video/omap3-isp/isphist.h| 40 + drivers/media/video/omap3-isp/isppreview.c | 2113 ++ drivers/media/video/omap3-isp/isppreview.h | 214 ++ drivers/media/video/omap3-isp/ispqueue.c | 1153 ++ drivers/media/video/omap3-isp/ispqueue.h | 187 ++ drivers/media/video/omap3-isp/ispreg.h | 1589 ++ drivers/media/video/omap3-isp/ispresizer.c | 1693 +++ drivers/media/video/omap3-isp/ispresizer.h | 147 ++ drivers/media/video/omap3-isp/ispstat.c| 1092 ++ drivers/media/video/omap3-isp/ispstat.h| 169 ++ drivers/media/video/omap3-isp/ispvideo.c | 1255 +++ drivers/media/video/omap3-isp/ispvideo.h | 202 ++ drivers/media/video/omap3-isp/luma_enhance_table.h | 42 + drivers/media/video/omap3-isp/noise_filter_table.h | 30 + drivers/media/video/v4l2-subdev.c |2 +- drivers/media/video/videobuf-dma-contig.c |2 +- include/linux/Kbuild |1 + 38 files changed, 19769 insertions(+), 2 deletions(-) I used quilt for all patches, except for the one patch with some gifs, where I did a git cherry-pick. So, the imported patches should be ok. Of course, it doesn't hurt do double check. The main issue with the omap3isp is due to the presence of private ioctl's that I don't have a clear idea about what they are really doing. I couldn't see any documentation about them on a very quick look. While I suspect that they are used only for 3A, I have no means of being sure about that. Also, as I've said several times, while I don't like, I have nothing against having some ioctls that would be used by a vendor to implement their own 3A software algorithms that he may need to hide for some reason or have any patents applied to the algorithm, but only if: 1) such algorithms are implemented on userspace; 2) the userspace API used by them is fully documented, in order to allow that someone else with enough motivation and spare time may want to implement his own algorithm (including an open-source one); 3) there are no patents denying or charging for the usage and/or distribution/redistribution of the Kernel with the provided kernel driver; 4) if the device works with a reasonable quality without them (by reasonable I mean like a cheap webcam, where libv4l could use his set of 3A algorithms to provide a good quality). Assuming that all t
Re: [patch] Fix AF9015 Dual tuner i2c write failures
Wow, thanks! On 03/04/2011 11:37 PM, Andrew de Quincey wrote: Hi, this has been annoying me for some time, so this evening I fixed it. If you use one of the above dual tuner devices (e.g. KWorld 399U), you get random tuning failures and i2c errors reported in dmesg such as: [...] Adding a "bus lock" to af9015_i2c_xfer() will not work as demod/tuner accesses will take multiple i2c transactions. Therefore, the following patch overrides the dvb_frontend_ops functions to add a per-device lock around them: only one frontend can now use the i2c bus at a time. Testing with the scripts above shows this has eliminated the errors. This have annoyed me too, but since it does not broken functionality much I haven't put much effort for fixing it. I like that fix since it is in AF9015 driver where it logically belongs to. But it looks still rather complex. I see you have also considered "bus lock" to af9015_i2c_xfer() which could be much smaller in code size (that's I have tried to implement long time back). I would like to ask if it possible to check I2C gate open / close inside af9015_i2c_xfer() and lock according that? Something like: typical command sequence: >> FE0 open gate >> FE0 write reg >> FE0 close gate >> FE1 open gate >> FE1 read reg >> FE1 close gate if (locked == YES) if (locked_by != caller FE) return error locked by other FE else (locked_by == caller FE) allow reg access if (gate close req) locked = NO locked_by = NONE else (locked == NO) locked = YES locked_by = caller FE allow reg access Do you see it possible? thanks Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch] Fix AF9015 Dual tuner i2c write failures
Hi, this has been annoying me for some time, so this evening I fixed
it. If you use one of the above dual tuner devices (e.g. KWorld 399U),
you get random tuning failures and i2c errors reported in dmesg such
as:
af9013: I2C read failed reg:d607
af9015: command failed:1
mxl5005s I2C write failed
af9015: command failed:1
mxl5005s I2C write failed
af9015: command failed:2
af9013: I2C read failed reg:d607
af9015: command failed:2
af9013: I2C read failed reg:d607
Looking at the large comment in dvb-usb/af9015.c/af9015_i2c_xfer() it
seems the dual demods/tuners have the same i2c addresses and are
switched by an i2c gate. Since the two show up as separate DVB
devices, and there is no synchronisation of i2c accesses, its fairly
obvious the problem is because both tuners are being written to at the
same time, which is mucking up the i2c gate. I tested this with two
scripts on my development machine:
while [ 1 ];
do
scan -a 0 /usr/share/dvb/dvb-t/uk-Craigkelly
done
AND
while [ 1 ];
do
scan -a 1 /usr/share/dvb/dvb-t/uk-Craigkelly
done
If I run only one at a time, it works perfectly. Run two, and I start
to see errors.
Adding a "bus lock" to af9015_i2c_xfer() will not work as demod/tuner
accesses will take multiple i2c transactions.
Therefore, the following patch overrides the dvb_frontend_ops
functions to add a per-device lock around them: only one frontend can
now use the i2c bus at a time. Testing with the scripts above shows
this has eliminated the errors.
Signed-off-by: Andrew de Quincey
diff --git a/drivers/media/dvb/dvb-usb/af9015.c b/drivers/media/dvb/dvb-usb/af9015.c
index 31c0a0e..740d969 100644
--- a/drivers/media/dvb/dvb-usb/af9015.c
+++ b/drivers/media/dvb/dvb-usb/af9015.c
@@ -1083,6 +1083,104 @@ static int af9015_i2c_init(struct dvb_usb_device *d)
return ret;
}
+static int af9015_lock_set_frontend(struct dvb_frontend* fe, struct dvb_frontend_parameters* params)
+{
+ int result;
+ struct dvb_usb_adapter *adap = fe->dvb->priv;
+ struct af9015_state *state = adap->dev->priv;
+
+ if (mutex_lock_interruptible(&adap->dev->usb_mutex))
+ return -EAGAIN;
+
+ result = state->fe_ops[adap->id].set_frontend(fe, params);
+ mutex_unlock(&adap->dev->usb_mutex);
+ return result;
+}
+
+static int af9015_lock_get_frontend(struct dvb_frontend* fe, struct dvb_frontend_parameters* params)
+{
+ int result;
+ struct dvb_usb_adapter *adap = fe->dvb->priv;
+ struct af9015_state *state = adap->dev->priv;
+
+ if (mutex_lock_interruptible(&adap->dev->usb_mutex))
+ return -EAGAIN;
+
+ result = state->fe_ops[adap->id].get_frontend(fe, params);
+ mutex_unlock(&adap->dev->usb_mutex);
+ return result;
+}
+
+static int af9015_lock_read_status(struct dvb_frontend* fe, fe_status_t* status)
+{
+ int result;
+ struct dvb_usb_adapter *adap = fe->dvb->priv;
+ struct af9015_state *state = adap->dev->priv;
+
+ if (mutex_lock_interruptible(&adap->dev->usb_mutex))
+ return -EAGAIN;
+
+ result = state->fe_ops[adap->id].read_status(fe, status);
+ mutex_unlock(&adap->dev->usb_mutex);
+ return result;
+}
+
+static int af9015_lock_read_ber(struct dvb_frontend* fe, u32* ber)
+{
+ int result;
+ struct dvb_usb_adapter *adap = fe->dvb->priv;
+ struct af9015_state *state = adap->dev->priv;
+
+ if (mutex_lock_interruptible(&adap->dev->usb_mutex))
+ return -EAGAIN;
+
+ result = state->fe_ops[adap->id].read_ber(fe, ber);
+ mutex_unlock(&adap->dev->usb_mutex);
+ return result;
+}
+
+static int af9015_lock_read_signal_strength(struct dvb_frontend* fe, u16* strength)
+{
+ int result;
+ struct dvb_usb_adapter *adap = fe->dvb->priv;
+ struct af9015_state *state = adap->dev->priv;
+
+ if (mutex_lock_interruptible(&adap->dev->usb_mutex))
+ return -EAGAIN;
+
+ result = state->fe_ops[adap->id].read_signal_strength(fe, strength);
+ mutex_unlock(&adap->dev->usb_mutex);
+ return result;
+}
+
+static int af9015_lock_read_snr(struct dvb_frontend* fe, u16* snr)
+{
+ int result;
+ struct dvb_usb_adapter *adap = fe->dvb->priv;
+ struct af9015_state *state = adap->dev->priv;
+
+ if (mutex_lock_interruptible(&adap->dev->usb_mutex))
+ return -EAGAIN;
+
+ result = state->fe_ops[adap->id].read_snr(fe, snr);
+ mutex_unlock(&adap->dev->usb_mutex);
+ return result;
+}
+
+static int af9015_lock_read_ucblocks(struct dvb_frontend* fe, u32* ucblocks)
+{
+ int result;
+ struct dvb_usb_adapter *adap = fe->dvb->priv;
+ struct af9015_state *state = adap->dev->priv;
+
+ if (mutex_lock_interruptible(&adap->dev->usb_mutex))
+ return -EAGAIN;
+
+ result = state->fe_ops[adap->id].read_ucblocks(fe, ucblocks);
+ mutex_unlock(&adap->dev->usb_mutex);
+ return result;
+}
+
static int af9015_af9013_frontend_attach(struct dvb_usb_adapter *adap)
{
int ret;
@@ -1116,6 +1214,22 @@ static int af9015_af9013_frontend_attach(struct dvb_usb_adapter *adap)
/* attach demodulator */
adap->fe = dvb_attach(af9013_attach, &af9015_af9013_config[adap->id],
i2c_adap);
+
+ memcpy(&state->fe_ops[adap->id], &adap->fe->ops, sizeof(str
Re: [GIT PULL FOR 2.6.39] Media controller and OMAP3 ISP driver
Em 04-03-2011 17:49, Mauro Carvalho Chehab escreveu: > Em 03-03-2011 07:25, Laurent Pinchart escreveu: >> > Hi Mauro, >> > >> > The following changes since commit >> > 88a763df226facb74fdb254563e30e9efb64275c: >> > >> > [media] dw2102: prof 1100 corrected (2011-03-02 16:56:54 -0300) >> > >> > are available in the git repository at: >> > git://linuxtv.org/pinchartl/media.git media-2.6.39-0005-omap3isp > ... >> > Laurent Pinchart (36): > ... >> > v4l: subdev: Generic ioctl supportFrom >> > 57b36ef1b9733124f3e04e6e2c06cf358051e209 Mon Sep 17 00:00:00 2001 > From: Laurent Pinchart > Date: Fri, 26 Feb 2010 16:23:10 +0100 > Subject: v4l: subdev: Generic ioctl support > Cc: Linux Media Mailing List > > Instead of returning an error when receiving an ioctl call with an > unsupported command, forward the call to the subdev core::ioctl handler. > > Signed-off-by: Laurent Pinchart > Acked-by: Hans Verkuil > Signed-off-by: Mauro Carvalho Chehab > --- > Documentation/video4linux/v4l2-framework.txt |5 + > drivers/media/video/v4l2-subdev.c|2 +- > 2 files changed, 6 insertions(+), 1 deletions(-) > > diff --git a/Documentation/video4linux/v4l2-framework.txt > b/Documentation/video4linux/v4l2-framework.txt > index 77d96f4..f2df31b 100644 > --- a/Documentation/video4linux/v4l2-framework.txt > +++ b/Documentation/video4linux/v4l2-framework.txt > @@ -405,6 +405,11 @@ VIDIOC_UNSUBSCRIBE_EVENT > To properly support events, the poll() file operation is also > implemented. > > +Private ioctls > + > + All ioctls not in the above list are passed directly to the sub-device > + driver through the core::ioctl operation. > + > > I2C sub-device drivers > -- > diff --git a/drivers/media/video/v4l2-subdev.c > b/drivers/media/video/v4l2-subdev.c > index 6e76f73..0b80644 100644 > --- a/drivers/media/video/v4l2-subdev.c > +++ b/drivers/media/video/v4l2-subdev.c > @@ -276,7 +276,7 @@ static long subdev_do_ioctl(struct file *file, unsigned > int cmd, void *arg) > } > #endif > default: > - return -ENOIOCTLCMD; > + return v4l2_subdev_call(sd, core, ioctl, cmd, arg); > } > > return 0; > I don't like to apply a patch like that without a very good explanation > about why it is needed and where it is used. Private ioctls are generally > a very bad idea, as they lack proper documentation. > > Also, we may quickly loose the control about what ioctl's are valid for > subdevs, as the same code could also be used to accept a video (or audio) > ioctl directly into a subdev. > > So, IMO, the better is to manually add ioctl's there as they're > needed inside subdevs. I'll not apply this patch on my tree for now. > > Is it currently needed for omap3isp? If so, what are the used ioctls > inside omap3isp? Ok, I got my answer at the omap3isp patches: # + * Private IOCTLs # + * # + * VIDIOC_OMAP3ISP_CCDC_CFG: Set CCDC configuration # + * VIDIOC_OMAP3ISP_PRV_CFG: Set preview engine configuration # + * VIDIOC_OMAP3ISP_AEWB_CFG: Set AEWB module configuration # + * VIDIOC_OMAP3ISP_HIST_CFG: Set histogram module configuration # + * VIDIOC_OMAP3ISP_AF_CFG: Set auto-focus module configuration # + * VIDIOC_OMAP3ISP_STAT_REQ: Read statistics (AEWB/AF/histogram) data # + * VIDIOC_OMAP3ISP_STAT_EN: Enable/disable a statistics module What are those ioctl's meant to do? In special, they seem to be needed to make the device work. As I don't have any device here to test, it is hard to be sure about that, so I'm tempted to nack this patch as-is. Also, where are those private ioctl's documented? Cheers, Mauro. -- 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 2.6.39] Media controller and OMAP3 ISP driver
Em 03-03-2011 07:25, Laurent Pinchart escreveu: > Hi Mauro, > > The following changes since commit 88a763df226facb74fdb254563e30e9efb64275c: > > [media] dw2102: prof 1100 corrected (2011-03-02 16:56:54 -0300) > > are available in the git repository at: > git://linuxtv.org/pinchartl/media.git media-2.6.39-0005-omap3isp ... > Laurent Pinchart (36): ... > v4l: subdev: Generic ioctl supportFrom > 57b36ef1b9733124f3e04e6e2c06cf358051e209 Mon Sep 17 00:00:00 2001 From: Laurent Pinchart Date: Fri, 26 Feb 2010 16:23:10 +0100 Subject: v4l: subdev: Generic ioctl support Cc: Linux Media Mailing List Instead of returning an error when receiving an ioctl call with an unsupported command, forward the call to the subdev core::ioctl handler. Signed-off-by: Laurent Pinchart Acked-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- Documentation/video4linux/v4l2-framework.txt |5 + drivers/media/video/v4l2-subdev.c|2 +- 2 files changed, 6 insertions(+), 1 deletions(-) diff --git a/Documentation/video4linux/v4l2-framework.txt b/Documentation/video4linux/v4l2-framework.txt index 77d96f4..f2df31b 100644 --- a/Documentation/video4linux/v4l2-framework.txt +++ b/Documentation/video4linux/v4l2-framework.txt @@ -405,6 +405,11 @@ VIDIOC_UNSUBSCRIBE_EVENT To properly support events, the poll() file operation is also implemented. +Private ioctls + + All ioctls not in the above list are passed directly to the sub-device + driver through the core::ioctl operation. + I2C sub-device drivers -- diff --git a/drivers/media/video/v4l2-subdev.c b/drivers/media/video/v4l2-subdev.c index 6e76f73..0b80644 100644 --- a/drivers/media/video/v4l2-subdev.c +++ b/drivers/media/video/v4l2-subdev.c @@ -276,7 +276,7 @@ static long subdev_do_ioctl(struct file *file, unsigned int cmd, void *arg) } #endif default: - return -ENOIOCTLCMD; + return v4l2_subdev_call(sd, core, ioctl, cmd, arg); } return 0; -- 1.7.1 I don't like to apply a patch like that without a very good explanation about why it is needed and where it is used. Private ioctls are generally a very bad idea, as they lack proper documentation. Also, we may quickly loose the control about what ioctl's are valid for subdevs, as the same code could also be used to accept a video (or audio) ioctl directly into a subdev. So, IMO, the better is to manually add ioctl's there as they're needed inside subdevs. I'll not apply this patch on my tree for now. Is it currently needed for omap3isp? If so, what are the used ioctls inside omap3isp? > v4l: Add subdev sensor g_skip_frames operation > v4l: Add 8-bit YUYV on 16-bit bus and SGRBG10 media bus pixel codes > v4l: Add remaining RAW10 patterns w DPCM pixel code variants > v4l: Add missing 12 bits bayer media bus formats > v4l: Add 12 bits bayer pixel formats Had you document all those newly-added formats at the API? Is there a way to double check if something is missed there? With the V4L2 API, as we add videodev2.h header, and we create dynamic links between the .h file and the specs, DocBook warns if some FOURCC is missed. From our experience, it is common that people add stuff at the header files, but forget to add the corresponding documentation for it. We need something similar for MBUS formats, as I suspect that we'll also have lots of additions there. Ok, I finished the review of the 36 media controller patches. I'll now start to dig into omap3isp patches. Cheers, Mauro -- 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 2.6.39] Media controller and OMAP3 ISP driver
Hi Mauro, On Fri, Mar 4, 2011 at 10:10 PM, Mauro Carvalho Chehab wrote: > Em 03-03-2011 07:25, Laurent Pinchart escreveu: >> Hi Mauro, >> >> The following changes since commit 88a763df226facb74fdb254563e30e9efb64275c: >> >> [media] dw2102: prof 1100 corrected (2011-03-02 16:56:54 -0300) >> >> are available in the git repository at: >> git://linuxtv.org/pinchartl/media.git media-2.6.39-0005-omap3isp >> >> The branch has been rebased on top of the latest for_v2.6.39 branch, with the >> v4l2-ioctl.c conflict resolved. >> >> Antti Koskipaa (1): >> v4l: v4l2_subdev userspace crop API >> >> David Cohen (1): >> omap3isp: Statistics >> >> Laurent Pinchart (36): >> v4l: Share code between video_usercopy and video_ioctl2 >> v4l: subdev: Don't require core operations >> v4l: subdev: Add device node support >> v4l: subdev: Uninline the v4l2_subdev_init function >> v4l: subdev: Control ioctls support >> media: Media device node support >> media: Media device >> media: Entities, pads and links >> media: Entity use count >> media: Media device information query >> media: Entities, pads and links enumeration >> media: Links setup >> media: Pipelines and media streams >> v4l: Add a media_device pointer to the v4l2_device structure >> v4l: Make video_device inherit from media_entity >> v4l: Make v4l2_subdev inherit from media_entity >> v4l: Move the media/v4l2-mediabus.h header to include/linux >> v4l: Replace enums with fixed-sized fields in public structure >> v4l: Rename V4L2_MBUS_FMT_GREY8_1X8 to V4L2_MBUS_FMT_Y8_1X8 >> v4l: Group media bus pixel codes by types and sort them alphabetically > > The presence of those mediabus names against the traditional fourcc codes > at the API adds some mess to the media controller. Not sure how to solve, > but maybe the best way is to add a table at the V4L2 API associating each > media bus format to the corresponding V4L2 fourcc codes. That would be good. OMAP2 camera driver also needs such table. Br, David > > Cheers, > Mauro > -- > 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 > -- 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 2.6.39] Media controller and OMAP3 ISP driver
Em 03-03-2011 07:25, Laurent Pinchart escreveu: > Hi Mauro, > > The following changes since commit 88a763df226facb74fdb254563e30e9efb64275c: > > [media] dw2102: prof 1100 corrected (2011-03-02 16:56:54 -0300) > > are available in the git repository at: > git://linuxtv.org/pinchartl/media.git media-2.6.39-0005-omap3isp > > The branch has been rebased on top of the latest for_v2.6.39 branch, with the > v4l2-ioctl.c conflict resolved. > > Antti Koskipaa (1): > v4l: v4l2_subdev userspace crop API > > David Cohen (1): > omap3isp: Statistics > > Laurent Pinchart (36): > v4l: Share code between video_usercopy and video_ioctl2 > v4l: subdev: Don't require core operations > v4l: subdev: Add device node support > v4l: subdev: Uninline the v4l2_subdev_init function > v4l: subdev: Control ioctls support > media: Media device node support > media: Media device > media: Entities, pads and links > media: Entity use count > media: Media device information query > media: Entities, pads and links enumeration > media: Links setup > media: Pipelines and media streams > v4l: Add a media_device pointer to the v4l2_device structure > v4l: Make video_device inherit from media_entity > v4l: Make v4l2_subdev inherit from media_entity > v4l: Move the media/v4l2-mediabus.h header to include/linux > v4l: Replace enums with fixed-sized fields in public structure > v4l: Rename V4L2_MBUS_FMT_GREY8_1X8 to V4L2_MBUS_FMT_Y8_1X8 > v4l: Group media bus pixel codes by types and sort them alphabetically The presence of those mediabus names against the traditional fourcc codes at the API adds some mess to the media controller. Not sure how to solve, but maybe the best way is to add a table at the V4L2 API associating each media bus format to the corresponding V4L2 fourcc codes. Cheers, Mauro -- 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 2.6.39] Media controller and OMAP3 ISP driver
Em 03-03-2011 07:25, Laurent Pinchart escreveu: > Hi Mauro, > > The following changes since commit 88a763df226facb74fdb254563e30e9efb64275c: > > [media] dw2102: prof 1100 corrected (2011-03-02 16:56:54 -0300) > > are available in the git repository at: > git://linuxtv.org/pinchartl/media.git media-2.6.39-0005-omap3isp > > The branch has been rebased on top of the latest for_v2.6.39 branch, with the > v4l2-ioctl.c conflict resolved. > > Antti Koskipaa (1): > v4l: v4l2_subdev userspace crop API > > David Cohen (1): > omap3isp: Statistics > > Laurent Pinchart (36): > v4l: Share code between video_usercopy and video_ioctl2 > v4l: subdev: Don't require core operations > v4l: subdev: Add device node support > v4l: subdev: Uninline the v4l2_subdev_init function > v4l: subdev: Control ioctls support > media: Media device node support > media: Media device > media: Entities, pads and links > media: Entity use count > media: Media device information query Hi Laurent, You're using 'M' for the media control ioctl's, but I'm not seeing any patch adding that range to the ioctl-number: Documentation/ioctl/ioctl-number.txt In particular, according with the text, 'M' is used by several other drivers, including audio, with doesn't sounds like a good idea to me. So, please send me a patch, at the end of the series, reserving an unused range for the media controller and replacing the ioctl numbers that you've already added to the new ioctl group. Thanks! Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[cron job] v4l-dvb daily build: ERRORS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Fri Mar 4 19:00:23 CET 2011 git hash:88a763df226facb74fdb254563e30e9efb64275c gcc version: i686-linux-gcc (GCC) 4.5.1 host hardware:x86_64 host os: 2.6.32.5 linux-git-armv5: WARNINGS linux-git-armv5-davinci: WARNINGS linux-git-armv5-ixp: WARNINGS linux-git-armv5-omap2: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: WARNINGS linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS linux-2.6.31.12-i686: ERRORS linux-2.6.32.6-i686: ERRORS linux-2.6.33-i686: ERRORS linux-2.6.34-i686: ERRORS linux-2.6.35.3-i686: ERRORS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: ERRORS linux-2.6.31.12-x86_64: ERRORS linux-2.6.32.6-x86_64: ERRORS linux-2.6.33-x86_64: ERRORS linux-2.6.34-x86_64: ERRORS linux-2.6.35.3-x86_64: ERRORS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: ERRORS spec-git: ERRORS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.tar.bz2 The V4L-DVB specification failed to build, but the last compiled spec 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: [RFC/PATCH v7 1/5] Changes in include/linux/videodev2.h for MFC 5.1
Hi,
> -Original Message-
> From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com]
> Sent: 04 March 2011 17:39
> To: Kamil Debski
> Cc: linux-media@vger.kernel.org; linux-samsung-...@vger.kernel.org;
> m.szyprow...@samsung.com; kyungmin.p...@samsung.com;
> jaeryul...@samsung.com; kgene@samsung.com
> Subject: Re: [RFC/PATCH v7 1/5] Changes in include/linux/videodev2.h
> for MFC 5.1
>
> On Friday 04 March 2011 12:26:18 Kamil Debski wrote:
> > This patch adds fourcc values for compressed video stream formats and
> > V4L2_CTRL_CLASS_CODEC. Also adds controls used by MFC 5.1 driver.
> >
> > Signed-off-by: Kamil Debski
> > Signed-off-by: Kyungmin Park
> > ---
> > include/linux/videodev2.h | 39
> +++
> > 1 files changed, 39 insertions(+), 0 deletions(-)
> >
> > diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
> > index a94c4d5..a48a42e 100644
> > --- a/include/linux/videodev2.h
> > +++ b/include/linux/videodev2.h
> > @@ -369,6 +369,19 @@ struct v4l2_pix_format {
> > #define V4L2_PIX_FMT_DV v4l2_fourcc('d', 'v', 's', 'd') /*
> 1394 */
> > #define V4L2_PIX_FMT_MPEG v4l2_fourcc('M', 'P', 'E', 'G') /*
> MPEG-1/2/4 */
> >
> > +#define V4L2_PIX_FMT_H264 v4l2_fourcc('H', '2', '6', '4') /*
> H264 */
> > +#define V4L2_PIX_FMT_H263 v4l2_fourcc('H', '2', '6', '3') /*
> H263 */
> > +#define V4L2_PIX_FMT_MPEG12 v4l2_fourcc('M', 'P', '1', '2') /*
> MPEG-1/2 */
> > +#define V4L2_PIX_FMT_MPEG4v4l2_fourcc('M', 'P', 'G', '4') /*
> MPEG-4 */
> > +#define V4L2_PIX_FMT_DIVX v4l2_fourcc('D', 'I', 'V', 'X') /*
> DivX */
> > +#define V4L2_PIX_FMT_DIVX3v4l2_fourcc('D', 'I', 'V', '3') /*
> DivX 3.11 */
> > +#define V4L2_PIX_FMT_DIVX4v4l2_fourcc('D', 'I', 'V', '4') /*
> DivX 4.12 */
> > +#define V4L2_PIX_FMT_DIVX500 v4l2_fourcc('D', 'X', '5', '2') /*
> DivX 5.00 - 5.02 */
> > +#define V4L2_PIX_FMT_DIVX503 v4l2_fourcc('D', 'X', '5', '3') /*
> DivX 5.03 - x */
> > +#define V4L2_PIX_FMT_XVID v4l2_fourcc('X', 'V', 'I', 'D') /*
> Xvid */
> > +#define V4L2_PIX_FMT_VC1 v4l2_fourcc('V', 'C', '1', 'A') /* VC-
> 1 */
> > +#define V4L2_PIX_FMT_VC1_RCV v4l2_fourcc('V', 'C', '1', 'R') /* VC-
> 1 RCV */
> > +
>
> Hans, you mentioned some time ago that you were against ading H.264 or
> MPEG4
> fourccs, and that drivers should use the MPEG controls instead. Could
> you
> clarify your current position on this ?
If I remember correct there was no clear conclusion on this. I hope we can
discuss this
during the upcoming meeting.
Have you got an alternative suggestion to using fourccs?
The existing MPEG controls won't cover all the functions and parameters that
are
used by video codecs. The controls that are in this patch are the ones
related to
decoding, there is even more for encoding.
Yesterday I have been talking with Hans on the IRC channel about the control
for
quantization parameters and he has suggested to use different for MPEG4,
H263 and H264.
Personally I'd like to have a common one, as the QP meaning is the same in
those 3
cases, the difference is the range of the value.
So I think that this still is a subject that could use more discussion as
there are
a few ideas.
Best regards,
--
Kamil Debski
Linux Platform Group
Samsung Poland R&D Center
--
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: [cron job] v4l-dvb daily build: ERRORS
On Thu, 3 Mar 2011 10:11:35 +0100 Hans Verkuil wrote: > On Thursday, March 03, 2011 09:44:17 Steffen Barszus wrote: > > home/hans/work/build/media_build/v4l/cx23885-cards.c:28:28: fatal > > error: staging/altera.h: No such file or directory > > > > This is true :) Any commit waiting, or any commit missing ? > > I hope I can work on this this weekend. Thx ! Its working now if i put #if LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 36) #define usleep_range(_min, _max)msleep((_max) / 1000) #endif in compat.h - not sure how it gets there - but you might know :) > > @Hans: one idea to improve your mail would be to show the git hash > > of the media tree instead of media build (i assume this is what is > > in your mails) > > Oops, that's a bug in my script. I made some changes some time ago > and my script tried to get the hash of a no longer existing branch. > Fixed. Thanks ! -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: BUG at mm/mmap.c:2309 when cx18.ko and cx18-alsa.ko loaded
On Fri, 2011-03-04 at 10:50 -0500, Devin Heitmueller wrote: > On Thu, Mar 3, 2011 at 9:06 PM, Andy Walls wrote: > > Hi, > > > > I got a BUG when loading the cx18.ko module (which in turn requests the > > cx18-alsa.ko module) on a kernel built from this repository > > > >http://git.linuxtv.org/media_tree.git staging/for_v2.6.39 > > > > which I beleive is based on 2.6.38-rc2. > > > > The BUG is mmap related and I'm almost certain it has to do with > > userspace accessing cx18-alsa.ko ALSA device nodes, since cx18.ko > > doesn't provide any mmap() related file ops. > > > > So here is my transcription of a fuzzy digital photo of the screen: > > > I'm not very familiar with mmap() nor ALSA and I did not author the > > cx18-alsa part of the cx18 driver, so any hints at where to look for the > > problem are appreciated. > > Hi Andy, > > I'm traveling on business for about two weeks, so I won't be able to > look into this right now. > > Any idea whether this is some new regression? I do not know. I normally don't let cx18-alsa.ko load, due to PulseAudio's persistence at keeping the device nodes open (which makes unloading the cx18.ko module for development a hassle.) > I'm just trying to > understand whether this is something that has always been there since > I originally added the ALSA support to cx18 or whether it's something > that is new, in which case it might make sense to drag the ALSA people > into the conversation since there haven't been any changes in the cx18 > driver lately. I can add some information about what is going on in userspace. This was on a Fedora 10 machine. When devices nodes show up, the HAL daemon and PulseAudio start using the device nodes right away. That activity triggers cx18.ko to do a firmware load which gets udevd running to satisfy firmware requests, and then the cx18 driver issues some simple commands to the CX23418 firmware, which will have acknowledgment interrupts coming back from the CX23418. I resolved the firmware race in cx18*.ko a while ago, so I'm confident its not an issue. The BUG looks like some sort of mmap() race or memory management problem outside of the cx18*.ko modules, given that mmput(), which appears to be an mm specific reference counting function, is involved. It could also be in ALSA I guess. I'm not sure how in the cx18-alsa.ko things can be screwed up so badly that it messes up the kernel's reference counting of mm structures. I'll take a harder look at it myself this weekend, but the kernel mm system is a little out of my current realm of experience. Looks like I get to learn, because I'm not going to bisect a BUG() that halts the machine and risks disk corruption every time. Regards, Andy -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: omap3isp cache error when unloading
[snip]
>> From 2712f2fd087ca782e964c912c7f1973e7d84f2b7 Mon Sep 17 00:00:00 2001
>> From: Michael Jones
>> Date: Fri, 4 Mar 2011 15:09:48 +0100
>> Subject: [PATCH] omap: iovmm: disallow mapping NULL address
>>
>> commit c7f4ab26e3bcdaeb3e19ec658e3ad9092f1a6ceb allowed mapping
>> the NULL address if da_start==0, which would then not get unmapped.
>> Disallow this again. And spell variable 'alignment' correctly.
>>
>> Signed-off-by: Michael Jones
>> ---
>> arch/arm/plat-omap/iovmm.c | 16 ++--
>> 1 files changed, 10 insertions(+), 6 deletions(-)
>>
>> diff --git a/arch/arm/plat-omap/iovmm.c b/arch/arm/plat-omap/iovmm.c
>> index 6dc1296..11c9b76 100644
>> --- a/arch/arm/plat-omap/iovmm.c
>> +++ b/arch/arm/plat-omap/iovmm.c
>> @@ -271,20 +271,24 @@ static struct iovm_struct *alloc_iovm_area(struct
>> iommu *obj, u32 da,
>> size_t bytes, u32 flags)
>> {
>> struct iovm_struct *new, *tmp;
>> - u32 start, prev_end, alignement;
>> + u32 start, prev_end, alignment;
>>
>> if (!obj || !bytes)
>> return ERR_PTR(-EINVAL);
>>
>> start = da;
>> - alignement = PAGE_SIZE;
>> + alignment = PAGE_SIZE;
>>
>> if (flags & IOVMF_DA_ANON) {
>> - start = obj->da_start;
>> + /* Don't map address 0 */
>> + if (obj->da_start)
>> + start = obj->da_start;
>> + else
>> + start = obj->da_start + alignment;
>
> It seems to be fine for me now. Let's see what Hiroshi says.
Sorry, I'm afraid I changed my mind after take a look into the driver. :)
Try to correct obj->da_start in the functions iommu_set_da_range() and
omap_iommu_probe(). That should be the correct way. Your patch doesn't
fix this situation when IOVMF_DA_ANON isn't set.
After obj->da_start is correctly set, your current patch is non longer required.
Regards,
David
>
> Regards,
>
> David
>
>>
>> if (flags & IOVMF_LINEAR)
>> - alignement = iopgsz_max(bytes);
>> - start = roundup(start, alignement);
>> + alignment = iopgsz_max(bytes);
>> + start = roundup(start, alignment);
>> } else if (start < obj->da_start || start > obj->da_end ||
>> obj->da_end - start < bytes) {
>> return ERR_PTR(-EINVAL);
>> @@ -304,7 +308,7 @@ static struct iovm_struct *alloc_iovm_area(struct iommu
>> *obj, u32 da,
>> goto found;
>>
>> if (tmp->da_end >= start && flags & IOVMF_DA_ANON)
>> - start = roundup(tmp->da_end + 1, alignement);
>> + start = roundup(tmp->da_end + 1, alignment);
>>
>> prev_end = tmp->da_end;
>> }
>> --
>> 1.7.4.1
>>
>>
>>
>> MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
>> Registergericht: Amtsgericht Stuttgart, HRB 271090
>> Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
>>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH v7 1/5] Changes in include/linux/videodev2.h for MFC 5.1
On Friday 04 March 2011 12:26:18 Kamil Debski wrote:
> This patch adds fourcc values for compressed video stream formats and
> V4L2_CTRL_CLASS_CODEC. Also adds controls used by MFC 5.1 driver.
>
> Signed-off-by: Kamil Debski
> Signed-off-by: Kyungmin Park
> ---
> include/linux/videodev2.h | 39 +++
> 1 files changed, 39 insertions(+), 0 deletions(-)
>
> diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
> index a94c4d5..a48a42e 100644
> --- a/include/linux/videodev2.h
> +++ b/include/linux/videodev2.h
> @@ -369,6 +369,19 @@ struct v4l2_pix_format {
> #define V4L2_PIX_FMT_DV v4l2_fourcc('d', 'v', 's', 'd') /* 1394 */
> #define V4L2_PIX_FMT_MPEG v4l2_fourcc('M', 'P', 'E', 'G') /* MPEG-1/2/4
> */
>
> +#define V4L2_PIX_FMT_H264 v4l2_fourcc('H', '2', '6', '4') /* H264 */
> +#define V4L2_PIX_FMT_H263 v4l2_fourcc('H', '2', '6', '3') /* H263 */
> +#define V4L2_PIX_FMT_MPEG12 v4l2_fourcc('M', 'P', '1', '2') /* MPEG-1/2 */
> +#define V4L2_PIX_FMT_MPEG4v4l2_fourcc('M', 'P', 'G', '4') /* MPEG-4 */
> +#define V4L2_PIX_FMT_DIVX v4l2_fourcc('D', 'I', 'V', 'X') /* DivX */
> +#define V4L2_PIX_FMT_DIVX3v4l2_fourcc('D', 'I', 'V', '3') /* DivX 3.11 */
> +#define V4L2_PIX_FMT_DIVX4v4l2_fourcc('D', 'I', 'V', '4') /* DivX 4.12 */
> +#define V4L2_PIX_FMT_DIVX500 v4l2_fourcc('D', 'X', '5', '2') /* DivX 5.00 -
> 5.02 */
> +#define V4L2_PIX_FMT_DIVX503 v4l2_fourcc('D', 'X', '5', '3') /* DivX 5.03 -
> x */
> +#define V4L2_PIX_FMT_XVID v4l2_fourcc('X', 'V', 'I', 'D') /* Xvid */
> +#define V4L2_PIX_FMT_VC1 v4l2_fourcc('V', 'C', '1', 'A') /* VC-1 */
> +#define V4L2_PIX_FMT_VC1_RCV v4l2_fourcc('V', 'C', '1', 'R') /* VC-1 RCV */
> +
Hans, you mentioned some time ago that you were against ading H.264 or MPEG4
fourccs, and that drivers should use the MPEG controls instead. Could you
clarify your current position on this ?
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] omap3isp: lane shifter support
Hi sMichal,
Thanks for the patch.
On Friday 04 March 2011 09:58:04 Michael Jones wrote:
> Signed-off-by: Michael Jones
> ---
> drivers/media/video/omap3-isp/isp.c | 82
> +- drivers/media/video/omap3-isp/isp.h |
> 4 +-
> drivers/media/video/omap3-isp/ispccdc.c |2 +-
> drivers/media/video/omap3-isp/ispvideo.c | 65 +---
> drivers/media/video/omap3-isp/ispvideo.h |3 +
> 5 files changed, 134 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/media/video/omap3-isp/isp.c
> b/drivers/media/video/omap3-isp/isp.c index 08d90fe..20e6daa 100644
> --- a/drivers/media/video/omap3-isp/isp.c
> +++ b/drivers/media/video/omap3-isp/isp.c
> @@ -273,6 +273,44 @@ static void isp_power_settings(struct isp_device *isp,
> int idle) }
>
> /*
> + * Decide whether desired output pixel code can be obtained with
> + * the lane shifter by shifting the input pixel code.
> + * return 1 if the combination is possible
> + * return 0 otherwise
> + */
> +int omap3isp_is_shiftable(enum v4l2_mbus_pixelcode in,
> + enum v4l2_mbus_pixelcode out)
As you only use this function in ispvideo.c, I would move it there. You could
also make the function return a bool.
> +{
> + const struct isp_format_info *in_info, *out_info;
> + int shiftable = 0;
> + if ((in == 0) || (out == 0))
> + return 0;
Can this happen ?
> +
> + if (in == out)
> + return 1;
> +
> + in_info = omap3isp_video_format_info(in);
> + out_info = omap3isp_video_format_info(out);
> + if ((!in_info) || (!out_info))
> + return 0;
Can this happen ?
> +
> + if (in_info->flavor != out_info->flavor)
> + return 0;
> +
> + switch (in_info->bpp - out_info->bpp) {
> + case 2:
> + case 4:
> + case 6:
> + shiftable = 1;
> + break;
> + default:
> + shiftable = 0;
> + }
What about
return in_info->bpp - out_info->bpp <= 6;
> +
> + return shiftable;
> +}
> +
> +/*
> * Configure the bridge and lane shifter. Valid inputs are
> *
> * CCDC_INPUT_PARALLEL: Parallel interface
> @@ -288,6 +326,10 @@ void omap3isp_configure_bridge(struct isp_device *isp,
> const struct isp_parallel_platform_data *pdata)
> {
> u32 ispctrl_val;
> + u32 depth_in = 0, depth_out = 0;
> + u32 shift;
> + const struct isp_format_info *fmt_info;
> + struct media_pad *srcpad;
>
> ispctrl_val = isp_reg_readl(isp, OMAP3_ISP_IOMEM_MAIN, ISP_CTRL);
> ispctrl_val &= ~ISPCTRL_SHIFT_MASK;
> @@ -298,7 +340,6 @@ void omap3isp_configure_bridge(struct isp_device *isp,
> switch (input) {
> case CCDC_INPUT_PARALLEL:
> ispctrl_val |= ISPCTRL_PAR_SER_CLK_SEL_PARALLEL;
> - ispctrl_val |= pdata->data_lane_shift << ISPCTRL_SHIFT_SHIFT;
> ispctrl_val |= pdata->clk_pol << ISPCTRL_PAR_CLK_POL_SHIFT;
> ispctrl_val |= pdata->bridge << ISPCTRL_PAR_BRIDGE_SHIFT;
> break;
> @@ -319,6 +360,45 @@ void omap3isp_configure_bridge(struct isp_device *isp,
> return;
> }
>
> + /* find output format from the remote end of the link connected to
> + * CCDC sink pad
> + */
> + srcpad = media_entity_remote_source(&isp->isp_ccdc.pads[CCDC_PAD_SINK]);
> + if (srcpad == NULL)
> + dev_err(isp->dev, "No active input to CCDC.\n");
There's no need to test for NULL, as this function will only be called on
streamon, so the pipeline will be valid.
> + if (media_entity_type(srcpad->entity) == MEDIA_ENT_T_V4L2_SUBDEV) {
The CCDC has no memory input, so this condition will always be true.
> + struct v4l2_subdev *subdev =
> +media_entity_to_v4l2_subdev(srcpad->entity);
> + struct v4l2_subdev_format fmt_src;
> + fmt_src.pad = srcpad->index;
> + fmt_src.which = V4L2_SUBDEV_FORMAT_ACTIVE;
> + if (!v4l2_subdev_call(subdev, pad, get_fmt, NULL, &fmt_src)) {
> + fmt_info =
> +omap3isp_video_format_info(fmt_src.format.code);
> + depth_in = fmt_info ? fmt_info->bpp : 0;
> + }
> + }
> +
> + /* find CCDC input format */
> + fmt_info = omap3isp_video_format_info
> + (isp->isp_ccdc.formats[CCDC_PAD_SINK].code);
> + depth_out = fmt_info ? fmt_info->bpp : 0;
> +
> + isp->isp_ccdc.syncif.datsz = depth_out;
> +
> + /* determine necessary shifting */
> + if (depth_in == depth_out + 6)
> + shift = 3;
> + else if (depth_in == depth_out + 4)
> + shift = 2;
> + else if (depth_in == depth_out + 2)
> + shift = 1;
> + else
> + shift = 0;
Maybe shift = (depth_out - depth_in) / 2; ?
> +
> + ispctrl_val |= shift << ISPCTRL_SHIFT_SHIFT;
> +
> ispctrl_val &= ~ISPCTRL_SYNC_DETECT_MASK;
> ispctrl_
[PATCH 3/7] ARM: Samsung: update/rewrite Samsung SYSMMU (IOMMU) driver
From: Andrzej Pietrasiewicz
This patch performs a complete rewrite of sysmmu driver for Samsung platform:
- the new version introduces an api to construct device private page
tables and enables to use device private address space mode
- simplified the resource management: no more single platform
device with 32 resources is needed, better fits into linux driver model,
each sysmmu instance has it's own resource definition
- added support for sysmmu clocks
- some other minor API chages required by upcoming videobuf2 allocator
Signed-off-by: Andrzej Pietrasiewicz
Signed-off-by: Kyungmin Park
Signed-off-by: Marek Szyprowski
---
Hello,
I'm really sorry for breaking this patch in the previous mail. The
semi-colon is missing in the "EXPORT_SYMBOL_GPL(s5p_sysmmu_unmap_area)"
line. This is the fixed version.
Best regards
--
Marek Szyprowski
Samsung Poland R&D Center
---
arch/arm/mach-s5pv310/clock.c| 91 ++
arch/arm/mach-s5pv310/dev-sysmmu.c | 582 +
arch/arm/mach-s5pv310/include/mach/irqs.h| 36 +-
arch/arm/mach-s5pv310/include/mach/regs-clock.h |3 +
arch/arm/mach-s5pv310/include/mach/regs-sysmmu.h | 23 +-
arch/arm/mach-s5pv310/include/mach/sysmmu.h | 122 ---
arch/arm/plat-s5p/Kconfig| 17 +-
arch/arm/plat-s5p/include/plat/sysmmu.h | 127 +++
arch/arm/plat-s5p/sysmmu.c | 988 +++---
arch/arm/plat-samsung/include/plat/devs.h|2 +-
10 files changed, 1323 insertions(+), 668 deletions(-)
rewrite arch/arm/mach-s5pv310/dev-sysmmu.c (86%)
delete mode 100644 arch/arm/mach-s5pv310/include/mach/sysmmu.h
create mode 100644 arch/arm/plat-s5p/include/plat/sysmmu.h
rewrite arch/arm/plat-s5p/sysmmu.c (85%)
diff --git a/arch/arm/mach-s5pv310/clock.c b/arch/arm/mach-s5pv310/clock.c
index fc7c2f8..f142b8c 100644
--- a/arch/arm/mach-s5pv310/clock.c
+++ b/arch/arm/mach-s5pv310/clock.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include
#include
@@ -116,6 +117,21 @@ static int s5pv310_clk_ip_perir_ctrl(struct clk *clk, int
enable)
return s5p_gatectrl(S5P_CLKGATE_IP_PERIR, clk, enable);
}
+static int s5pv310_clk_ip_dmc_ctrl(struct clk *clk, int enable)
+{
+ return s5p_gatectrl(S5P_CLKGATE_IP_DMC, clk, enable);
+}
+
+static int s5pv310_clk_ip_mfc_ctrl(struct clk *clk, int enable)
+{
+ return s5p_gatectrl(S5P_CLKGATE_IP_MFC, clk, enable);
+}
+
+static int s5pv310_clk_ip_tv_ctrl(struct clk *clk, int enable)
+{
+ return s5p_gatectrl(S5P_CLKGATE_IP_TV, clk, enable);
+}
+
/* Core list of CMU_CPU side */
static struct clksrc_clk clk_mout_apll = {
@@ -422,6 +438,81 @@ static struct clk init_clocks_off[] = {
.enable = s5pv310_clk_ip_cam_ctrl,
.ctrlbit= (1 << 3),
}, {
+ .name = "sysmmu",
+ .id = S5P_SYSMMU_MFC_L,
+ .enable = s5pv310_clk_ip_mfc_ctrl,
+ .ctrlbit= ((15 << 1) | 1),
+ }, {
+ .name = "sysmmu",
+ .id = S5P_SYSMMU_MFC_R,
+ .enable = s5pv310_clk_ip_mfc_ctrl,
+ .ctrlbit= ((15 << 1) | 1),
+ }, {
+ .name = "sysmmu",
+ .id = S5P_SYSMMU_FIMC0,
+ .enable = s5pv310_clk_ip_cam_ctrl,
+ .ctrlbit= (1 << 7),
+ }, {
+ .name = "sysmmu",
+ .id = S5P_SYSMMU_FIMC1,
+ .enable = s5pv310_clk_ip_cam_ctrl,
+ .ctrlbit= (1 << 8),
+ } , {
+ .name = "sysmmu",
+ .id = S5P_SYSMMU_FIMC2,
+ .enable = s5pv310_clk_ip_cam_ctrl,
+ .ctrlbit= (1 << 9),
+ } , {
+ .name = "sysmmu",
+ .id = S5P_SYSMMU_FIMC3,
+ .enable = s5pv310_clk_ip_cam_ctrl,
+ .ctrlbit= (1 << 10),
+ } , {
+ .name = "sysmmu",
+ .id = S5P_SYSMMU_JPEG,
+ .enable = s5pv310_clk_ip_cam_ctrl,
+ .ctrlbit= (1 << 11),
+ } , {
+ .name = "sysmmu",
+ .id = S5P_SYSMMU_TV,
+ .enable = s5pv310_clk_ip_tv_ctrl,
+ .ctrlbit= (1 << 4),
+ } , {
+ .name = "sysmmu",
+ .id = S5P_SYSMMU_G2D,
+ .enable = s5pv310_clk_ip_image_ctrl,
+ .ctrlbit= (1 << 3),
+ } , {
+ .name = "sysmmu",
+ .id = S5P_SYSMMU_ROTATOR,
+ .enable = s5pv310_clk_ip_image_ctrl,
+ .ctrlbit= (1 << 4)
Re: BUG at mm/mmap.c:2309 when cx18.ko and cx18-alsa.ko loaded
On Thu, Mar 3, 2011 at 9:06 PM, Andy Walls wrote: > Hi, > > I got a BUG when loading the cx18.ko module (which in turn requests the > cx18-alsa.ko module) on a kernel built from this repository > > http://git.linuxtv.org/media_tree.git staging/for_v2.6.39 > > which I beleive is based on 2.6.38-rc2. > > The BUG is mmap related and I'm almost certain it has to do with > userspace accessing cx18-alsa.ko ALSA device nodes, since cx18.ko > doesn't provide any mmap() related file ops. > > So here is my transcription of a fuzzy digital photo of the screen: > I'm not very familiar with mmap() nor ALSA and I did not author the > cx18-alsa part of the cx18 driver, so any hints at where to look for the > problem are appreciated. Hi Andy, I'm traveling on business for about two weeks, so I won't be able to look into this right now. Any idea whether this is some new regression? I'm just trying to understand whether this is something that has always been there since I originally added the ALSA support to cx18 or whether it's something that is new, in which case it might make sense to drag the ALSA people into the conversation since there haven't been any changes in the cx18 driver lately. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] omap3isp: ccdc: support Y10, Y12, SGRBG8, SBGGR8
Hi Michael,
Thanks for the patch.
On Friday 04 March 2011 09:58:03 Michael Jones wrote:
> Signed-off-by: Michael Jones
> ---
> drivers/media/video/omap3-isp/ispccdc.c |4
> drivers/media/video/omap3-isp/ispvideo.c |8
> 2 files changed, 12 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/media/video/omap3-isp/ispccdc.c
> b/drivers/media/video/omap3-isp/ispccdc.c index e4d04ce..166115d 100644
> --- a/drivers/media/video/omap3-isp/ispccdc.c
> +++ b/drivers/media/video/omap3-isp/ispccdc.c
> @@ -43,6 +43,10 @@ __ccdc_get_format(struct isp_ccdc_device *ccdc, struct
> v4l2_subdev_fh *fh,
>
> static const unsigned int ccdc_fmts[] = {
> V4L2_MBUS_FMT_Y8_1X8,
> + V4L2_MBUS_FMT_Y10_1X10,
> + V4L2_MBUS_FMT_Y12_1X12,
> + V4L2_MBUS_FMT_SGRBG8_1X8,
> + V4L2_MBUS_FMT_SBGGR8_1X8,
While you're at it, what about SGBRG8_1X8 and SRGGB8_1X8 (here and in
ispvideo.c) ?
> V4L2_MBUS_FMT_SGRBG10_1X10,
> V4L2_MBUS_FMT_SRGGB10_1X10,
> V4L2_MBUS_FMT_SBGGR10_1X10,
> diff --git a/drivers/media/video/omap3-isp/ispvideo.c
> b/drivers/media/video/omap3-isp/ispvideo.c index f16d787..c406043 100644
> --- a/drivers/media/video/omap3-isp/ispvideo.c
> +++ b/drivers/media/video/omap3-isp/ispvideo.c
> @@ -48,6 +48,14 @@
> static struct isp_format_info formats[] = {
> { V4L2_MBUS_FMT_Y8_1X8, V4L2_MBUS_FMT_Y8_1X8,
> V4L2_MBUS_FMT_Y8_1X8, V4L2_PIX_FMT_GREY, 8, },
> + { V4L2_MBUS_FMT_Y10_1X10, V4L2_MBUS_FMT_Y10_1X10,
> + V4L2_MBUS_FMT_Y10_1X10, V4L2_PIX_FMT_Y10, 10, },
> + { V4L2_MBUS_FMT_Y12_1X12, V4L2_MBUS_FMT_Y10_1X10,
> + V4L2_MBUS_FMT_Y12_1X12, V4L2_PIX_FMT_Y12, 12, },
> + { V4L2_MBUS_FMT_SBGGR8_1X8, V4L2_MBUS_FMT_SBGGR8_1X8,
> + V4L2_MBUS_FMT_SBGGR8_1X8, V4L2_PIX_FMT_SBGGR8, 8, },
> + { V4L2_MBUS_FMT_SGRBG8_1X8, V4L2_MBUS_FMT_SGRBG8_1X8,
> + V4L2_MBUS_FMT_SGRBG8_1X8, V4L2_PIX_FMT_SGRBG8, 8, },
> { V4L2_MBUS_FMT_SGRBG10_DPCM8_1X8, V4L2_MBUS_FMT_SGRBG10_DPCM8_1X8,
> V4L2_MBUS_FMT_SGRBG10_1X10, V4L2_PIX_FMT_SGRBG10DPCM8, 8, },
> { V4L2_MBUS_FMT_SBGGR10_1X10, V4L2_MBUS_FMT_SBGGR10_1X10,
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: omap3isp cache error when unloading
On Fri, Mar 4, 2011 at 4:39 PM, Michael Jones
wrote:
> Hi David,
Hi Michael,
>
> On 03/04/2011 02:12 PM, David Cohen wrote:
>> Hi,
>>
>> [snip]
>>
>>> Sorry, I should've mentioned: I'm using your media-0005-omap3isp branch
>>> based on 2.6.38-rc5. I didn't have the problem with 2.6.37, either.
>>> It's actually not related to mis-configuring the ISP pipeline like I
>>> thought at first- it also happens after I have successfully captured images.
>>>
>>> I've since tracked down the problem, although I don't understand the
>>> cache management well enough to be sure it's a proper fix, so hopefully
>>> some new recipients on this can make suggestions/comments.
>>>
>>> The patch below solves the problem, which modifies a commit by Fernando
>>> Guzman Lugo from December.
>>>
>>> -Michael
>>>
>>> From db35fb8edca2a4f8fd37197d77fd58676cb1dcac Mon Sep 17 00:00:00 2001
>>> From: Michael Jones
>>> Date: Thu, 3 Mar 2011 16:50:39 +0100
>>> Subject: [PATCH] fix iovmm slab cache error on module unload
>>>
>>> modify "OMAP: iommu: create new api to set valid da range"
>>>
>>> This modifies commit c7f4ab26e3bcdaeb3e19ec658e3ad9092f1a6ceb.
>>> ---
>>> arch/arm/plat-omap/iovmm.c | 5 -
>>> 1 files changed, 4 insertions(+), 1 deletions(-)
>>>
>>> diff --git a/arch/arm/plat-omap/iovmm.c b/arch/arm/plat-omap/iovmm.c
>>> index 6dc1296..2fba6f1 100644
>>> --- a/arch/arm/plat-omap/iovmm.c
>>> +++ b/arch/arm/plat-omap/iovmm.c
>>> @@ -280,7 +280,10 @@ static struct iovm_struct *alloc_iovm_area(struct
>>> iommu *obj, u32 da,
>>> alignement = PAGE_SIZE;
>>>
>>> if (flags & IOVMF_DA_ANON) {
>>> - start = obj->da_start;
>>> + /*
>>> + * Reserve the first page for NULL
>>> + */
>>> + start = obj->da_start + PAGE_SIZE;
>>
>> IMO if obj->da_start != 0, no need to add PAGE_SIZE. Otherwise, it
>> does make sense to correct wrong obj->da_start == 0. Another thing is
>> this piece of code is using alignement (alignment) variable instead of
>> PAGE_SIZE (which is the same value).
>>
>> Br,
>>
>> David
>
> I believe the following patch addresses your comments. I couldn't
> resist also fixing the misspelling of alignment when I was using the
> variable in my patch.
>
> -Michael
>
> From 2712f2fd087ca782e964c912c7f1973e7d84f2b7 Mon Sep 17 00:00:00 2001
> From: Michael Jones
> Date: Fri, 4 Mar 2011 15:09:48 +0100
> Subject: [PATCH] omap: iovmm: disallow mapping NULL address
>
> commit c7f4ab26e3bcdaeb3e19ec658e3ad9092f1a6ceb allowed mapping
> the NULL address if da_start==0, which would then not get unmapped.
> Disallow this again. And spell variable 'alignment' correctly.
>
> Signed-off-by: Michael Jones
> ---
> arch/arm/plat-omap/iovmm.c | 16 ++--
> 1 files changed, 10 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm/plat-omap/iovmm.c b/arch/arm/plat-omap/iovmm.c
> index 6dc1296..11c9b76 100644
> --- a/arch/arm/plat-omap/iovmm.c
> +++ b/arch/arm/plat-omap/iovmm.c
> @@ -271,20 +271,24 @@ static struct iovm_struct *alloc_iovm_area(struct iommu
> *obj, u32 da,
> size_t bytes, u32 flags)
> {
> struct iovm_struct *new, *tmp;
> - u32 start, prev_end, alignement;
> + u32 start, prev_end, alignment;
>
> if (!obj || !bytes)
> return ERR_PTR(-EINVAL);
>
> start = da;
> - alignement = PAGE_SIZE;
> + alignment = PAGE_SIZE;
>
> if (flags & IOVMF_DA_ANON) {
> - start = obj->da_start;
> + /* Don't map address 0 */
> + if (obj->da_start)
> + start = obj->da_start;
> + else
> + start = obj->da_start + alignment;
It seems to be fine for me now. Let's see what Hiroshi says.
Regards,
David
>
> if (flags & IOVMF_LINEAR)
> - alignement = iopgsz_max(bytes);
> - start = roundup(start, alignement);
> + alignment = iopgsz_max(bytes);
> + start = roundup(start, alignment);
> } else if (start < obj->da_start || start > obj->da_end ||
> obj->da_end - start < bytes) {
> return ERR_PTR(-EINVAL);
> @@ -304,7 +308,7 @@ static struct iovm_struct *alloc_iovm_area(struct iommu
> *obj, u32 da,
> goto found;
>
> if (tmp->da_end >= start && flags & IOVMF_DA_ANON)
> - start = roundup(tmp->da_end + 1, alignement);
> + start = roundup(tmp->da_end + 1, alignment);
>
> prev_end = tmp->da_end;
> }
> --
> 1.7.4.1
>
>
>
> MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
> Registergericht: Amtsgericht Stuttgart, HRB 271090
> Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
>
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@
Re: [PATCH 2/4] media: add 8-bit bayer formats and Y12
Hi Michael,
Thanks for the patch.
On Friday 04 March 2011 09:58:02 Michael Jones wrote:
> Signed-off-by: Michael Jones
Acked-by: Laurent Pinchart
> ---
> include/linux/v4l2-mediabus.h |7 +--
> 1 files changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/v4l2-mediabus.h b/include/linux/v4l2-mediabus.h
> index 7054a7a..46caecd 100644
> --- a/include/linux/v4l2-mediabus.h
> +++ b/include/linux/v4l2-mediabus.h
> @@ -47,8 +47,9 @@ enum v4l2_mbus_pixelcode {
> V4L2_MBUS_FMT_RGB565_2X8_BE = 0x1007,
> V4L2_MBUS_FMT_RGB565_2X8_LE = 0x1008,
>
> - /* YUV (including grey) - next is 0x2013 */
> + /* YUV (including grey) - next is 0x2014 */
> V4L2_MBUS_FMT_Y8_1X8 = 0x2001,
> + V4L2_MBUS_FMT_Y12_1X12 = 0x2013,
> V4L2_MBUS_FMT_UYVY8_1_5X8 = 0x2002,
> V4L2_MBUS_FMT_VYUY8_1_5X8 = 0x2003,
> V4L2_MBUS_FMT_YUYV8_1_5X8 = 0x2004,
> @@ -67,9 +68,11 @@ enum v4l2_mbus_pixelcode {
> V4L2_MBUS_FMT_YUYV10_1X20 = 0x200d,
> V4L2_MBUS_FMT_YVYU10_1X20 = 0x200e,
>
> - /* Bayer - next is 0x3013 */
> + /* Bayer - next is 0x3015 */
> V4L2_MBUS_FMT_SBGGR8_1X8 = 0x3001,
> + V4L2_MBUS_FMT_SGBRG8_1X8 = 0x3013,
> V4L2_MBUS_FMT_SGRBG8_1X8 = 0x3002,
> + V4L2_MBUS_FMT_SRGGB8_1X8 = 0x3014,
> V4L2_MBUS_FMT_SBGGR10_DPCM8_1X8 = 0x300b,
> V4L2_MBUS_FMT_SGBRG10_DPCM8_1X8 = 0x300c,
> V4L2_MBUS_FMT_SGRBG10_DPCM8_1X8 = 0x3009,
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/6] s5pv310: add s5p-tv to platform devices
Signed-off-by: Tomasz Stanislawski
Signed-off-by: Kyungmin Park
Reviewed-by: Marek Szyprowski
s5pv310: fix and clean code for TV power
s5pv310: tv: fix clock setup
s5pv310: tv: integrate with Power Domain driver
s5pv310: tv: register fix
s5pv310: tv: add port HDMI_EN1 gpio to regulator api
s5pv310: tv: use hdmiphy as clock
s5pv310: tv: moved TV setup to separete function
s5pv310: hdmi: removed control for clocks and regulators
s5pv310: mixer: removed control for clocks and regulators
---
arch/arm/mach-s5pv310/Kconfig |5 +
arch/arm/mach-s5pv310/Makefile |1 +
arch/arm/mach-s5pv310/clock.c | 132 ++-
arch/arm/mach-s5pv310/dev-tv.c | 103 ++
arch/arm/mach-s5pv310/include/mach/irqs.h |4 +
arch/arm/mach-s5pv310/include/mach/map.h| 26 +
arch/arm/mach-s5pv310/include/mach/regs-clock.h |3 +
arch/arm/mach-s5pv310/include/mach/regs-pmu.h |2 +
arch/arm/plat-samsung/include/plat/devs.h |2 +
9 files changed, 277 insertions(+), 1 deletions(-)
create mode 100644 arch/arm/mach-s5pv310/dev-tv.c
diff --git a/arch/arm/mach-s5pv310/Kconfig b/arch/arm/mach-s5pv310/Kconfig
index 6f83817..4c863850 100644
--- a/arch/arm/mach-s5pv310/Kconfig
+++ b/arch/arm/mach-s5pv310/Kconfig
@@ -20,6 +20,11 @@ config S5PV310_DEV_PD
help
Compile in platform device definitions for Power Domain
+config S5PV310_DEV_TV
+ bool
+ help
+ Compile in platform device definition for TV interface
+
config S5PV310_SETUP_I2C1
bool
help
diff --git a/arch/arm/mach-s5pv310/Makefile b/arch/arm/mach-s5pv310/Makefile
index 036fb38..a234b80 100644
--- a/arch/arm/mach-s5pv310/Makefile
+++ b/arch/arm/mach-s5pv310/Makefile
@@ -32,6 +32,7 @@ obj-y += dev-audio.o
obj-$(CONFIG_S5PV310_DEV_PD) += dev-pd.o
obj-$(CONFIG_S5PV310_DEV_SYSMMU) += dev-sysmmu.o
+obj-$(CONFIG_S5PV310_DEV_TV) += dev-tv.o
obj-$(CONFIG_S5PV310_SETUP_I2C1) += setup-i2c1.o
obj-$(CONFIG_S5PV310_SETUP_I2C2) += setup-i2c2.o
obj-$(CONFIG_S5PV310_SETUP_I2C3) += setup-i2c3.o
diff --git a/arch/arm/mach-s5pv310/clock.c b/arch/arm/mach-s5pv310/clock.c
index 465beb9..f037be6 100644
--- a/arch/arm/mach-s5pv310/clock.c
+++ b/arch/arm/mach-s5pv310/clock.c
@@ -24,6 +24,7 @@
#include
#include
+#include
static struct clk clk_sclk_hdmi27m = {
.name = "sclk_hdmi27m",
@@ -82,6 +83,11 @@ static int s5pv310_clksrc_mask_peril1_ctrl(struct clk *clk,
int enable)
return s5p_gatectrl(S5P_CLKSRC_MASK_PERIL1, clk, enable);
}
+static int s5pv310_clksrc_mask_tv_ctrl(struct clk *clk, int enable)
+{
+ return s5p_gatectrl(S5P_CLKSRC_MASK_TV, clk, enable);
+}
+
static int s5pv310_clk_ip_cam_ctrl(struct clk *clk, int enable)
{
return s5p_gatectrl(S5P_CLKGATE_IP_CAM, clk, enable);
@@ -132,6 +138,11 @@ static int s5pv310_clk_ip_tv_ctrl(struct clk *clk, int
enable)
return s5p_gatectrl(S5P_CLKGATE_IP_TV, clk, enable);
}
+static int s5pv310_clk_hdmiphy_ctrl(struct clk *clk, int enable)
+{
+ return s5p_gatectrl(S5P_HDMI_PHY_CONTROL, clk, enable);
+}
+
/* Core list of CMU_CPU side */
static struct clksrc_clk clk_mout_apll = {
@@ -528,6 +539,31 @@ static struct clk init_clocks_off[] = {
.enable = s5pv310_clk_ip_mfc_ctrl,
.ctrlbit= (1 << 0),
}, {
+ .name = "dac",
+ .id = -1,
+ .enable = s5pv310_clk_ip_tv_ctrl,
+ .ctrlbit= (1 << 2),
+ }, {
+ .name = "mixer",
+ .id = -1,
+ .enable = s5pv310_clk_ip_tv_ctrl,
+ .ctrlbit= (1 << 1),
+ }, {
+ .name = "vp",
+ .id = -1,
+ .enable = s5pv310_clk_ip_tv_ctrl,
+ .ctrlbit= (1 << 0),
+ }, {
+ .name = "hdmi",
+ .id = -1,
+ .enable = s5pv310_clk_ip_tv_ctrl,
+ .ctrlbit= (1 << 3),
+ }, {
+ .name = "hdmiphy",
+ .id = -1,
+ .enable = s5pv310_clk_hdmiphy_ctrl,
+ .ctrlbit= (1 << 0),
+ }, {
.name = "hsmmc",
.id = 0,
.parent = &clk_aclk_133.clk,
@@ -805,6 +841,93 @@ static struct clksrc_sources clkset_mout_g2d = {
.nr_sources = ARRAY_SIZE(clkset_mout_g2d_list),
};
+/* --
+ * TV subsystem CLOCKS
+ * --
+ */
+
+static struct clk *clkset_sclk_dac_list[] = {
+ [0] = &clk_sclk_vpll.clk,
+ [1] = &clk_sclk_hdmiphy,
+};
+
[PATCH 3/6] v4l: add macro for 1080p59_54 preset
The 1080p59_94 is supported in latest Samusng SoC.
Signed-off-by: Tomasz Stanislawski
Signed-off-by: Kyungmin Park
---
drivers/media/video/v4l2-common.c |1 +
include/linux/videodev2.h |1 +
2 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/v4l2-common.c
b/drivers/media/video/v4l2-common.c
index 940b5db..ef684f6 100644
--- a/drivers/media/video/v4l2-common.c
+++ b/drivers/media/video/v4l2-common.c
@@ -645,6 +645,7 @@ int v4l_fill_dv_preset_info(u32 preset, struct
v4l2_dv_enum_preset *info)
{ 1920, 1080, "1080p@30" }, /* V4L2_DV_1080P30 */
{ 1920, 1080, "1080p@50" }, /* V4L2_DV_1080P50 */
{ 1920, 1080, "1080p@60" }, /* V4L2_DV_1080P60 */
+ { 1920, 1080, "1080p@59.94" }, /* V4L2_DV_1080P59_94 */
};
if (info == NULL || preset >= ARRAY_SIZE(dv_presets))
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index a48a42e..4a44b45 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -875,6 +875,7 @@ struct v4l2_dv_enum_preset {
#defineV4L2_DV_1080P30 16 /* SMPTE 296M */
#defineV4L2_DV_1080P50 17 /* BT.1120 */
#defineV4L2_DV_1080P60 18 /* BT.1120 */
+#defineV4L2_DV_1080P59_94 19
/*
* D V B T T I M I N G S
--
1.7.1.569.g6f426
--
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 6/6] s5pv310: add s5p-tv to Universal C210 board
Signed-off-by: Tomasz Stanislawski
Signed-off-by: Kyungmin Park
---
arch/arm/mach-s5pv310/Kconfig |2 +
arch/arm/mach-s5pv310/mach-universal_c210.c | 54 +++
2 files changed, 56 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-s5pv310/Kconfig b/arch/arm/mach-s5pv310/Kconfig
index 4c863850..9acf9c0 100644
--- a/arch/arm/mach-s5pv310/Kconfig
+++ b/arch/arm/mach-s5pv310/Kconfig
@@ -112,10 +112,12 @@ config MACH_UNIVERSAL_C210
select S5PV310_SETUP_SDHCI
select S3C_DEV_I2C1
select S3C_DEV_I2C5
+ select S3C_DEV_I2C8
select S5P_DEV_MFC
select S5PV310_DEV_PD
select S5PV310_DEV_SYSMMU
select S5PV310_SETUP_I2C1
+ select S5PV310_DEV_TV
select S5PV310_SETUP_I2C5
help
Machine support for Samsung Mobile Universal S5PC210 Reference
diff --git a/arch/arm/mach-s5pv310/mach-universal_c210.c
b/arch/arm/mach-s5pv310/mach-universal_c210.c
index ce88262..206c539 100644
--- a/arch/arm/mach-s5pv310/mach-universal_c210.c
+++ b/arch/arm/mach-s5pv310/mach-universal_c210.c
@@ -27,6 +27,7 @@
#include
#include
#include
+#include
#include
#include
@@ -812,6 +813,35 @@ static struct i2c_board_info i2c1_devs[] __initdata = {
/* Gyro, To be updated */
};
+static struct regulator_consumer_supply hdmi_supplies[] = {
+ REGULATOR_SUPPLY("hdmi-en", "s5p-hdmi"),
+};
+
+static struct regulator_init_data hdmi_fixed_voltage_init_data = {
+ .constraints= {
+ .name = "HDMI_5V",
+ .valid_ops_mask = REGULATOR_CHANGE_STATUS,
+ },
+ .num_consumer_supplies = ARRAY_SIZE(mmc0_supplies),
+ .consumer_supplies = hdmi_supplies,
+};
+
+static struct fixed_voltage_config hdmi_fixed_voltage_config = {
+ .supply_name= "HDMI_EN1",
+ .microvolts = 500,
+ .gpio = S5PV310_GPE0(1),
+ .enable_high= true,
+ .init_data = &hdmi_fixed_voltage_init_data,
+};
+
+static struct platform_device hdmi_fixed_voltage = {
+ .name = "reg-fixed-voltage",
+ .id = 6,
+ .dev= {
+ .platform_data = &hdmi_fixed_voltage_config,
+ },
+};
+
static struct platform_device *universal_devices[] __initdata = {
/* Samsung Platform Devices */
&mmc0_fixed_voltage,
@@ -831,8 +861,14 @@ static struct platform_device *universal_devices[]
__initdata = {
&s5pv310_device_pd[PD_MFC],
&s5pv310_device_sysmmu[S5P_SYSMMU_MFC_L],
&s5pv310_device_sysmmu[S5P_SYSMMU_MFC_R],
+ &s3c_device_i2c8,
+ &s5p_device_hdmi,
+ &s5p_device_mixer,
+ &s5pv310_device_pd[PD_TV],
+ &s5pv310_device_sysmmu[S5P_SYSMMU_TV],
/* Universal Devices */
+ &hdmi_fixed_voltage,
&universal_gpio_keys,
&s3c_device_i2c5,
&s5p_device_onenand,
@@ -845,6 +881,21 @@ static void __init universal_map_io(void)
s3c24xx_init_uarts(universal_uartcfgs, ARRAY_SIZE(universal_uartcfgs));
}
+void s5p_tv_setup(void)
+{
+ /* direct HPD to HDMI chip */
+ gpio_request(S5PV310_GPX3(7), "hpd-plug");
+
+ gpio_direction_input(S5PV310_GPX3(7));
+ s3c_gpio_cfgpin(S5PV310_GPX3(7), S3C_GPIO_SFN(0x3));
+ s3c_gpio_setpull(S5PV310_GPX3(7), S3C_GPIO_PULL_NONE);
+
+ /* setup dependencies between TV devices */
+ s5p_device_hdmi.dev.parent = &s5pv310_device_pd[PD_TV].dev;
+ s5p_device_mixer.dev.parent = &s5pv310_device_pd[PD_TV].dev;
+ s5pv310_device_sysmmu[S5P_SYSMMU_TV].dev.parent =
&s5pv310_device_pd[PD_TV].dev;
+}
+
static void __init universal_machine_init(void)
{
universal_sdhci_init();
@@ -853,6 +904,7 @@ static void __init universal_machine_init(void)
i2c_register_board_info(1, i2c1_devs, ARRAY_SIZE(i2c1_devs));
s3c_i2c5_set_platdata(NULL);
+ s3c_i2c8_set_platdata(NULL);
i2c_register_board_info(5, i2c_devs5, ARRAY_SIZE(i2c_devs5));
/* Last */
@@ -870,6 +922,8 @@ static void __init universal_machine_init(void)
s5p_device_mfc.dev.parent = &s5pv310_device_pd[PD_MFC].dev;
s5pv310_device_sysmmu[S5P_SYSMMU_MFC_L].dev.parent =
&s5pv310_device_pd[PD_MFC].dev;
s5pv310_device_sysmmu[S5P_SYSMMU_MFC_R].dev.parent =
&s5pv310_device_pd[PD_MFC].dev;
+
+ s5p_tv_setup();
}
MACHINE_START(UNIVERSAL_C210, "UNIVERSAL_C210")
--
1.7.1.569.g6f426
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] v4l: add V4L2_PIX_FMT_Y12 format
Hi Michael,
Thanks for the patch.
On Friday 04 March 2011 09:58:01 Michael Jones wrote:
> Signed-off-by: Michael Jones
Acked-by: Laurent Pinchart
> ---
> include/linux/videodev2.h |1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
> index 02da9e7..6fac463 100644
> --- a/include/linux/videodev2.h
> +++ b/include/linux/videodev2.h
> @@ -288,6 +288,7 @@ struct v4l2_pix_format {
> #define V4L2_PIX_FMT_Y4 v4l2_fourcc('Y', '0', '4', ' ') /* 4
> Greyscale */ #define V4L2_PIX_FMT_Y6 v4l2_fourcc('Y', '0', '6', '
> ') /* 6 Greyscale */ #define V4L2_PIX_FMT_Y10 v4l2_fourcc('Y',
> '1', '0', ' ') /* 10 Greyscale */ +#define V4L2_PIX_FMT_Y12
> v4l2_fourcc('Y', '1', '2', ' ') /* 12 Greyscale */ #define
> V4L2_PIX_FMT_Y16 v4l2_fourcc('Y', '1', '6', ' ') /* 16 Greyscale
> */
>
> /* Palette formats */
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/6] universal: i2c: add I2C controller 8 (HDMIPHY)
Signed-off-by: Tomasz Stanislawski
Signed-off-by: Kyungmin Park
---
arch/arm/mach-s5pv310/clock.c |6 +++
arch/arm/mach-s5pv310/include/mach/irqs.h |4 ++
arch/arm/mach-s5pv310/include/mach/map.h |1 +
arch/arm/plat-samsung/Kconfig |5 ++
arch/arm/plat-samsung/Makefile|1 +
arch/arm/plat-samsung/dev-i2c8.c | 68 +
arch/arm/plat-samsung/include/plat/devs.h |1 +
arch/arm/plat-samsung/include/plat/iic.h |1 +
8 files changed, 87 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/plat-samsung/dev-i2c8.c
diff --git a/arch/arm/mach-s5pv310/clock.c b/arch/arm/mach-s5pv310/clock.c
index d28fa6f..465beb9 100644
--- a/arch/arm/mach-s5pv310/clock.c
+++ b/arch/arm/mach-s5pv310/clock.c
@@ -685,6 +685,12 @@ static struct clk init_clocks_off[] = {
.parent = &clk_aclk_100.clk,
.enable = s5pv310_clk_ip_peril_ctrl,
.ctrlbit= (1 << 13),
+ }, {
+ .name = "i2c",
+ .id = 8,
+ .parent = &clk_aclk_100.clk,
+ .enable = s5pv310_clk_ip_peril_ctrl,
+ .ctrlbit= (1 << 14),
},
};
diff --git a/arch/arm/mach-s5pv310/include/mach/irqs.h
b/arch/arm/mach-s5pv310/include/mach/irqs.h
index f6b99c6..f7ddc98 100644
--- a/arch/arm/mach-s5pv310/include/mach/irqs.h
+++ b/arch/arm/mach-s5pv310/include/mach/irqs.h
@@ -77,6 +77,9 @@
#define IRQ_PDMA0 COMBINER_IRQ(21, 0)
#define IRQ_PDMA1 COMBINER_IRQ(21, 1)
+#define IRQ_HDMI COMBINER_IRQ(16, 0)
+#define IRQ_HDMI_I2C COMBINER_IRQ(16, 1)
+
#define IRQ_TIMER0_VIC COMBINER_IRQ(22, 0)
#define IRQ_TIMER1_VIC COMBINER_IRQ(22, 1)
#define IRQ_TIMER2_VIC COMBINER_IRQ(22, 2)
@@ -100,6 +103,7 @@
#define IRQ_IIC5 COMBINER_IRQ(27, 5)
#define IRQ_IIC6 COMBINER_IRQ(27, 6)
#define IRQ_IIC7 COMBINER_IRQ(27, 7)
+#define IRQ_IIC8 IRQ_HDMI_I2C
#define IRQ_HSMMC0 COMBINER_IRQ(29, 0)
#define IRQ_HSMMC1 COMBINER_IRQ(29, 1)
diff --git a/arch/arm/mach-s5pv310/include/mach/map.h
b/arch/arm/mach-s5pv310/include/mach/map.h
index 576ba55..0aa0171 100644
--- a/arch/arm/mach-s5pv310/include/mach/map.h
+++ b/arch/arm/mach-s5pv310/include/mach/map.h
@@ -120,6 +120,7 @@
#define S3C_PA_IIC5S5PV310_PA_IIC(5)
#define S3C_PA_IIC6S5PV310_PA_IIC(6)
#define S3C_PA_IIC7S5PV310_PA_IIC(7)
+#define S3C_PA_IIC8S5PV310_PA_IIC(8)
#define S3C_PA_RTC S5PV310_PA_RTC
#define S3C_PA_WDT S5PV310_PA_WATCHDOG
diff --git a/arch/arm/plat-samsung/Kconfig b/arch/arm/plat-samsung/Kconfig
index 32be05c..dd1fd15 100644
--- a/arch/arm/plat-samsung/Kconfig
+++ b/arch/arm/plat-samsung/Kconfig
@@ -211,6 +211,11 @@ config S3C_DEV_I2C7
help
Compile in platform device definition for I2C controller 7
+config S3C_DEV_I2C8
+ bool
+ help
+ Compile in platform device definitions for I2C channel 8 (HDMIPHY)
+
config S3C_DEV_FB
bool
help
diff --git a/arch/arm/plat-samsung/Makefile b/arch/arm/plat-samsung/Makefile
index 7e92457..826ae4f 100644
--- a/arch/arm/plat-samsung/Makefile
+++ b/arch/arm/plat-samsung/Makefile
@@ -46,6 +46,7 @@ obj-$(CONFIG_S3C_DEV_I2C4)+= dev-i2c4.o
obj-$(CONFIG_S3C_DEV_I2C5) += dev-i2c5.o
obj-$(CONFIG_S3C_DEV_I2C6) += dev-i2c6.o
obj-$(CONFIG_S3C_DEV_I2C7) += dev-i2c7.o
+obj-$(CONFIG_S3C_DEV_I2C8) += dev-i2c8.o
obj-$(CONFIG_S3C_DEV_FB) += dev-fb.o
obj-y += dev-uart.o
obj-$(CONFIG_S3C_DEV_USB_HOST) += dev-usb.o
diff --git a/arch/arm/plat-samsung/dev-i2c8.c b/arch/arm/plat-samsung/dev-i2c8.c
new file mode 100644
index 000..8edba7f
--- /dev/null
+++ b/arch/arm/plat-samsung/dev-i2c8.c
@@ -0,0 +1,68 @@
+/* linux/arch/arm/plat-samsung/dev-i2c7.c
+ *
+ * Copyright (c) 2010 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com/
+ *
+ * S3C series device definition for i2c device 8
+ *
+ * Based on plat-samsung/dev-i2c8.c
+ *
+ * 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
+
+static struct resource s3c_i2c_resource[] = {
+ [0] = {
+ .start = S3C_PA_IIC8,
+ .end = S3C_PA_IIC8 + SZ_4K - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ [1] = {
+ .start = IRQ_IIC8,
+ .end = IRQ_IIC8,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+struct platform_device s3c_device_i2c8 = {
+ .n
[PATCH 1/6] i2c-s3c2410: fix I2C dedicated for hdmiphy
The I2C HDMIPHY dedicated controller has different timeout
handling and reset conditions.
Signed-off-by: Tomasz Stanislawski
Signed-off-by: Kyungmin Park
CC: ben-li...@fluff.org
---
drivers/i2c/busses/i2c-s3c2410.c | 36 +++-
1 files changed, 35 insertions(+), 1 deletions(-)
diff --git a/drivers/i2c/busses/i2c-s3c2410.c b/drivers/i2c/busses/i2c-s3c2410.c
index 6c00c10..99cfe2f 100644
--- a/drivers/i2c/busses/i2c-s3c2410.c
+++ b/drivers/i2c/busses/i2c-s3c2410.c
@@ -54,6 +54,7 @@ enum s3c24xx_i2c_state {
enum s3c24xx_i2c_type {
TYPE_S3C2410,
TYPE_S3C2440,
+ TYPE_S3C2440_HDMIPHY,
};
struct s3c24xx_i2c {
@@ -96,7 +97,21 @@ static inline int s3c24xx_i2c_is2440(struct s3c24xx_i2c *i2c)
enum s3c24xx_i2c_type type;
type = platform_get_device_id(pdev)->driver_data;
- return type == TYPE_S3C2440;
+ return type == TYPE_S3C2440 || type == TYPE_S3C2440_HDMIPHY;
+}
+
+/* s3c24xx_i2c_is2440_hdmiphy()
+ *
+ * return true is this is an s3c2440 dedicated for HDMIPHY interface
+*/
+
+static inline int s3c24xx_i2c_is2440_hdmiphy(struct s3c24xx_i2c *i2c)
+{
+ struct platform_device *pdev = to_platform_device(i2c->dev);
+ enum s3c24xx_i2c_type type;
+
+ type = platform_get_device_id(pdev)->driver_data;
+ return type == TYPE_S3C2440_HDMIPHY;
}
/* s3c24xx_i2c_master_complete
@@ -461,6 +476,13 @@ static int s3c24xx_i2c_set_master(struct s3c24xx_i2c *i2c)
unsigned long iicstat;
int timeout = 400;
+ /* if hang-up of HDMIPHY occured reduce timeout
+* The controller will work after reset, so waiting
+* 400 ms will cause unneccessary system hangup
+*/
+ if (s3c24xx_i2c_is2440_hdmiphy(i2c))
+ timeout = 10;
+
while (timeout-- > 0) {
iicstat = readl(i2c->regs + S3C2410_IICSTAT);
@@ -470,6 +492,15 @@ static int s3c24xx_i2c_set_master(struct s3c24xx_i2c *i2c)
msleep(1);
}
+ /* hang-up of bus dedicated for HDMIPHY occured, resetting */
+ if (s3c24xx_i2c_is2440_hdmiphy(i2c)) {
+ writel(0, i2c->regs + S3C2410_IICCON);
+ writel(0, i2c->regs + S3C2410_IICSTAT);
+ writel(0, i2c->regs + S3C2410_IICDS);
+
+ return 0;
+ }
+
return -ETIMEDOUT;
}
@@ -1009,6 +1040,9 @@ static struct platform_device_id s3c24xx_driver_ids[] = {
}, {
.name = "s3c2440-i2c",
.driver_data= TYPE_S3C2440,
+ }, {
+ .name = "s3c2440-hdmiphy-i2c",
+ .driver_data= TYPE_S3C2440_HDMIPHY,
}, { },
};
MODULE_DEVICE_TABLE(platform, s3c24xx_driver_ids);
--
1.7.1.569.g6f426
--
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/6] HDMI driver for Samsung S5PV310 platform
From: Marek Szyprowski Hello, I would like to present the second version of HDMI driver for S5PC210 platform. The driver is under a heavy development. The most recent changes are: 1. Minor bugs and fixes: - pink line on left side of display - premature start of VP's streaming - usage of free memory - usage of non-initialized variables - fixed sequence of power setup - dependencies in Kconfig 2. Integration with Runtime Power Managment and Power Domain driver. 3. The CMA was substituted by the SYSMMU driver. 4. Applying existing frameworks: - activation of HDMIPHY using clock API - control of power on HDMI-5V pin using regulator API 5. Moving all clocks and regulator management from platform to the drivers' code. 6. Redesigned the control of mixer's debugging. 7. Added a watchdog to deal with HW failures. Original HDMI driver RFC: == Introduction == The purpose of this RFC is to discuss the driver for a TV output interface available in upcoming Samsung SoC. The HW is able to generate digital and analog signals. Current version of the driver supports only digital output. Internally the driver uses videobuf2 framework, and CMA memory allocator. Not all of them are merged by now, but I decided to post the sources to start discussion driver's design. == Hardware description == The SoC contains a few HW sub-blocks: 1. Video Processor (VP). It is used for processing of NV12 data. An image stored in RAM is accessed by DMA. Pixels are cropped, scaled. Additionally, post processing operations like brightness, sharpness and contrast adjustments could be performed. The output in YCbCr444 format is send to Mixer. 2. Mixer (MXR). The piece of hardware responsible for mixing and blending multiple data inputs before passing it to an output device. The MXR is capable of handling up to three image layers. One is the output of VP. Other two are images in RGB format (multiple variants are supported). The layers are scaled, cropped and blended with background color. The blending factor, and layers' priority are controlled by MXR's registers. The output is passed either to HDMI or TVOUT. 3. HDMI. The piece of HW responsible for generation of HDMI packets. It takes pixel data from mixer and transforms it into data frames. The output is send to HDMIPHY interface. 4. HDMIPHY. Physical interface for HDMI. Its duties are sending HDMI packets to HDMI connector. Basically, it contains a PLL that produces source clock for Mixer, VP and HDMI during streaming. 5. TVOUT. Generation of TV analog signal. (driver not implemented) 6. VideoDAC. Modulator for TVOUT signal. (driver not implemented) The diagram below depicts connection between all HW pieces. +---+ NV12 data ---dma--->| Video | | Processor | +---+ | V +---+ RGB data ---dma--->| | | Mixer | RGB data ---dma--->| | +---+ | * dmux / +-* *--+ || VV +---++---+ |HDMI || TVOUT | +---++---+ || VV +---++---+ | HDMIPHY || VideoDAC | +---++---+ || VV HDMI Composite connector connector == Driver interface == The posted driver implements three V4L2 nodes. Every video node implements V4L2 output buffer. One of nodes corresponds to input of Video Processor. The other two nodes correspond to RGB inputs of Mixer. All nodes share the same output. It is one of the Mixer's outputs: TVOUT or HDMI. Changing output in one layer using S_OUTPUT would change outputs of all other video nodes. The same thing happens if one try to reconfigure output i.e. by calling S_DV_PRESET. However it not possible to change or reconfigure the output while streaming. To sum up, all features in posted version of driver goes as follows: 1. QUERYCAP 2. S_FMT, G_FMT - single and multiplanar API a) node named video0 supports formats NV12, NV12, NV12T (tiled version of NV12), NV12MT (multiplane version of NV12T). b) nodes named graph0 and graph1 support formats RGB565, ARGB1555, ARGB, ARGB. 3. Buffer with USERPTR and MMAP memory. 4. Streaming and buffer control. (STREAMON, STREAMOFF, REQBUF, QBUF, DQBUF) 5. OUTPUT enumeration. 6. DV preset control (SET, GET, ENUM). Currently modes 480P59_94, 720P59_94, 1080P30, 1080P59_94 and 1080P60 work
Re: [PATCH] v4l2-ctrls: Add transaction support
On Friday, March 04, 2011 14:36:40 Laurent Pinchart wrote:
> Hi Hans,
>
> On Friday 04 March 2011 10:47:11 Hans Verkuil wrote:
> > Hi Laurent,
> >
> > I'm afraid this approach won't work. See below for the details.
> >
> > On Thursday, March 03, 2011 16:13:33 Laurent Pinchart wrote:
> > > Some hardware supports controls transactions. For instance, the MT9T001
> > > sensor can optionally shadow registers that influence the output image,
> > > allowing the host to explicitly control the shadow process.
> > >
> > > To support such hardware, drivers need to be notified when a control
> > > transation is about to start and when it has finished. Add begin() and
> > > commit() callback functions to the v4l2_ctrl_handler structure to
> > > support such notifications.
> > >
> > > Signed-off-by: Laurent Pinchart
> > > ---
> > >
> > > drivers/media/video/v4l2-ctrls.c | 42
> > > +++-- include/media/v4l2-ctrls.h
> > > |8 +++
> > > 2 files changed, 47 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/media/video/v4l2-ctrls.c
> > > b/drivers/media/video/v4l2-ctrls.c index 2412f08..d0e6265 100644
> > > --- a/drivers/media/video/v4l2-ctrls.c
> > > +++ b/drivers/media/video/v4l2-ctrls.c
> > > @@ -1264,13 +1264,22 @@ EXPORT_SYMBOL(v4l2_ctrl_handler_log_status);
> > >
> > > int v4l2_ctrl_handler_setup(struct v4l2_ctrl_handler *hdl)
> > > {
> > >
> > > struct v4l2_ctrl *ctrl;
> > >
> > > + unsigned int count = 0;
> > >
> > > int ret = 0;
> > >
> > > if (hdl == NULL)
> > >
> > > return 0;
> > >
> > > mutex_lock(&hdl->lock);
> > >
> > > - list_for_each_entry(ctrl, &hdl->ctrls, node)
> > > + list_for_each_entry(ctrl, &hdl->ctrls, node) {
> > >
> > > ctrl->done = false;
> > >
> > > + count++;
> > > + }
> > > +
> > > + if (hdl->begin) {
> > > + ret = hdl->begin(hdl, count == 1);
> >
> > Note that count can be 0! In any case, rather then adding a counter you can
> > use list_empty() and list_is_singular().
>
> OK.
>
> > > + if (ret)
> > > + goto done;
> > > + }
> > >
> > > list_for_each_entry(ctrl, &hdl->ctrls, node) {
> > >
> > > struct v4l2_ctrl *master = ctrl->cluster[0];
> > >
> > > @@ -1298,6 +1307,11 @@ int v4l2_ctrl_handler_setup(struct
> > > v4l2_ctrl_handler *hdl)
> > >
> > > if (master->cluster[i])
> > >
> > > master->cluster[i]->done = true;
> > >
> > > }
> > >
> > > +
> > > + if (hdl->commit)
> > > + hdl->commit(hdl, ret != 0);
> > > +
> >
> > > +done:
> > I understand that you assume that all controls registered to a handler can
> > be used in a transaction. But isn't it possible that only a subset of the
> > controls is shadowed? And so only certain controls can be in a
> > transaction?
> >
> > > mutex_unlock(&hdl->lock);
> > > return ret;
> > >
> > > }
> > >
> > > @@ -1717,6 +1731,12 @@ static int try_or_set_ext_ctrls(struct
> > > v4l2_ctrl_handler *hdl,
> > >
> > > return -EBUSY;
> > >
> > > }
> > >
> > > + if (set && hdl->begin) {
> > > + ret = hdl->begin(hdl, cs->count == 1);
> > > + if (ret)
> > > + return ret;
> > > + }
> > > +
> >
> > You are assuming that all controls here are owned by the given control
> > handler. That's not necessarily the case though as a control handler can
> > inherit controls from another handler. So the cs array is an array of
> > controls where each control can be owned by a different handler.
>
> Right. That will indeed be an issue.
>
> > > for (i = 0; !ret && i < cs->count; i++) {
> > >
> > > struct v4l2_ctrl *ctrl = helpers[i].ctrl;
> > > struct v4l2_ctrl *master = ctrl->cluster[0];
> > >
> > > @@ -1747,6 +1767,10 @@ static int try_or_set_ext_ctrls(struct
> > > v4l2_ctrl_handler *hdl,
> > >
> > > v4l2_ctrl_unlock(ctrl);
> > > cluster_done(i, cs, helpers);
> > >
> > > }
> > >
> > > +
> > > + if (set && hdl->commit)
> > > + hdl->commit(hdl, ret == 0);
> > > +
> >
> > If you rollback a transaction, then you also have a problem: if some of the
> > controls of the transaction succeeded then try_or_set_control_cluster()
> > will have set the current control value to the new value (since the 'set'
> > succeeded).
> >
> > But if you rollback the transaction, then that means that the old value
> > isn't restored for such controls.
> >
> > I don't see an easy solution for that offhand.
> >
> > I really wonder whether you are not reinventing the control cluster here.
> >
> > If you put all shadowed controls in a cluster, then it will behave exactly
> > the same as a transaction.
> >
> > Yes, that might mean that all controls of a subdev are in a single cluster.
> > But so what? That's the way to atomically handle controls that in some
> > manner are related.
>
> More and more sensors start to support cont
Re: omap3isp cache error when unloading
Hi David,
On 03/04/2011 02:12 PM, David Cohen wrote:
> Hi,
>
> [snip]
>
>> Sorry, I should've mentioned: I'm using your media-0005-omap3isp branch
>> based on 2.6.38-rc5. I didn't have the problem with 2.6.37, either.
>> It's actually not related to mis-configuring the ISP pipeline like I
>> thought at first- it also happens after I have successfully captured images.
>>
>> I've since tracked down the problem, although I don't understand the
>> cache management well enough to be sure it's a proper fix, so hopefully
>> some new recipients on this can make suggestions/comments.
>>
>> The patch below solves the problem, which modifies a commit by Fernando
>> Guzman Lugo from December.
>>
>> -Michael
>>
>> From db35fb8edca2a4f8fd37197d77fd58676cb1dcac Mon Sep 17 00:00:00 2001
>> From: Michael Jones
>> Date: Thu, 3 Mar 2011 16:50:39 +0100
>> Subject: [PATCH] fix iovmm slab cache error on module unload
>>
>> modify "OMAP: iommu: create new api to set valid da range"
>>
>> This modifies commit c7f4ab26e3bcdaeb3e19ec658e3ad9092f1a6ceb.
>> ---
>> arch/arm/plat-omap/iovmm.c |5 -
>> 1 files changed, 4 insertions(+), 1 deletions(-)
>>
>> diff --git a/arch/arm/plat-omap/iovmm.c b/arch/arm/plat-omap/iovmm.c
>> index 6dc1296..2fba6f1 100644
>> --- a/arch/arm/plat-omap/iovmm.c
>> +++ b/arch/arm/plat-omap/iovmm.c
>> @@ -280,7 +280,10 @@ static struct iovm_struct *alloc_iovm_area(struct iommu
>> *obj, u32 da,
>>alignement = PAGE_SIZE;
>>
>>if (flags & IOVMF_DA_ANON) {
>> - start = obj->da_start;
>> + /*
>> +* Reserve the first page for NULL
>> +*/
>> + start = obj->da_start + PAGE_SIZE;
>
> IMO if obj->da_start != 0, no need to add PAGE_SIZE. Otherwise, it
> does make sense to correct wrong obj->da_start == 0. Another thing is
> this piece of code is using alignement (alignment) variable instead of
> PAGE_SIZE (which is the same value).
>
> Br,
>
> David
I believe the following patch addresses your comments. I couldn't
resist also fixing the misspelling of alignment when I was using the
variable in my patch.
-Michael
>From 2712f2fd087ca782e964c912c7f1973e7d84f2b7 Mon Sep 17 00:00:00 2001
From: Michael Jones
Date: Fri, 4 Mar 2011 15:09:48 +0100
Subject: [PATCH] omap: iovmm: disallow mapping NULL address
commit c7f4ab26e3bcdaeb3e19ec658e3ad9092f1a6ceb allowed mapping
the NULL address if da_start==0, which would then not get unmapped.
Disallow this again. And spell variable 'alignment' correctly.
Signed-off-by: Michael Jones
---
arch/arm/plat-omap/iovmm.c | 16 ++--
1 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/arch/arm/plat-omap/iovmm.c b/arch/arm/plat-omap/iovmm.c
index 6dc1296..11c9b76 100644
--- a/arch/arm/plat-omap/iovmm.c
+++ b/arch/arm/plat-omap/iovmm.c
@@ -271,20 +271,24 @@ static struct iovm_struct *alloc_iovm_area(struct iommu
*obj, u32 da,
size_t bytes, u32 flags)
{
struct iovm_struct *new, *tmp;
- u32 start, prev_end, alignement;
+ u32 start, prev_end, alignment;
if (!obj || !bytes)
return ERR_PTR(-EINVAL);
start = da;
- alignement = PAGE_SIZE;
+ alignment = PAGE_SIZE;
if (flags & IOVMF_DA_ANON) {
- start = obj->da_start;
+ /* Don't map address 0 */
+ if (obj->da_start)
+ start = obj->da_start;
+ else
+ start = obj->da_start + alignment;
if (flags & IOVMF_LINEAR)
- alignement = iopgsz_max(bytes);
- start = roundup(start, alignement);
+ alignment = iopgsz_max(bytes);
+ start = roundup(start, alignment);
} else if (start < obj->da_start || start > obj->da_end ||
obj->da_end - start < bytes) {
return ERR_PTR(-EINVAL);
@@ -304,7 +308,7 @@ static struct iovm_struct *alloc_iovm_area(struct iommu
*obj, u32 da,
goto found;
if (tmp->da_end >= start && flags & IOVMF_DA_ANON)
- start = roundup(tmp->da_end + 1, alignement);
+ start = roundup(tmp->da_end + 1, alignment);
prev_end = tmp->da_end;
}
--
1.7.4.1
MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
--
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] v4l2-ctrls: Add transaction support
Hi Hans,
On Friday 04 March 2011 10:47:11 Hans Verkuil wrote:
> Hi Laurent,
>
> I'm afraid this approach won't work. See below for the details.
>
> On Thursday, March 03, 2011 16:13:33 Laurent Pinchart wrote:
> > Some hardware supports controls transactions. For instance, the MT9T001
> > sensor can optionally shadow registers that influence the output image,
> > allowing the host to explicitly control the shadow process.
> >
> > To support such hardware, drivers need to be notified when a control
> > transation is about to start and when it has finished. Add begin() and
> > commit() callback functions to the v4l2_ctrl_handler structure to
> > support such notifications.
> >
> > Signed-off-by: Laurent Pinchart
> > ---
> >
> > drivers/media/video/v4l2-ctrls.c | 42
> > +++-- include/media/v4l2-ctrls.h
> > |8 +++
> > 2 files changed, 47 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/media/video/v4l2-ctrls.c
> > b/drivers/media/video/v4l2-ctrls.c index 2412f08..d0e6265 100644
> > --- a/drivers/media/video/v4l2-ctrls.c
> > +++ b/drivers/media/video/v4l2-ctrls.c
> > @@ -1264,13 +1264,22 @@ EXPORT_SYMBOL(v4l2_ctrl_handler_log_status);
> >
> > int v4l2_ctrl_handler_setup(struct v4l2_ctrl_handler *hdl)
> > {
> >
> > struct v4l2_ctrl *ctrl;
> >
> > + unsigned int count = 0;
> >
> > int ret = 0;
> >
> > if (hdl == NULL)
> >
> > return 0;
> >
> > mutex_lock(&hdl->lock);
> >
> > - list_for_each_entry(ctrl, &hdl->ctrls, node)
> > + list_for_each_entry(ctrl, &hdl->ctrls, node) {
> >
> > ctrl->done = false;
> >
> > + count++;
> > + }
> > +
> > + if (hdl->begin) {
> > + ret = hdl->begin(hdl, count == 1);
>
> Note that count can be 0! In any case, rather then adding a counter you can
> use list_empty() and list_is_singular().
OK.
> > + if (ret)
> > + goto done;
> > + }
> >
> > list_for_each_entry(ctrl, &hdl->ctrls, node) {
> >
> > struct v4l2_ctrl *master = ctrl->cluster[0];
> >
> > @@ -1298,6 +1307,11 @@ int v4l2_ctrl_handler_setup(struct
> > v4l2_ctrl_handler *hdl)
> >
> > if (master->cluster[i])
> >
> > master->cluster[i]->done = true;
> >
> > }
> >
> > +
> > + if (hdl->commit)
> > + hdl->commit(hdl, ret != 0);
> > +
>
> > +done:
> I understand that you assume that all controls registered to a handler can
> be used in a transaction. But isn't it possible that only a subset of the
> controls is shadowed? And so only certain controls can be in a
> transaction?
>
> > mutex_unlock(&hdl->lock);
> > return ret;
> >
> > }
> >
> > @@ -1717,6 +1731,12 @@ static int try_or_set_ext_ctrls(struct
> > v4l2_ctrl_handler *hdl,
> >
> > return -EBUSY;
> >
> > }
> >
> > + if (set && hdl->begin) {
> > + ret = hdl->begin(hdl, cs->count == 1);
> > + if (ret)
> > + return ret;
> > + }
> > +
>
> You are assuming that all controls here are owned by the given control
> handler. That's not necessarily the case though as a control handler can
> inherit controls from another handler. So the cs array is an array of
> controls where each control can be owned by a different handler.
Right. That will indeed be an issue.
> > for (i = 0; !ret && i < cs->count; i++) {
> >
> > struct v4l2_ctrl *ctrl = helpers[i].ctrl;
> > struct v4l2_ctrl *master = ctrl->cluster[0];
> >
> > @@ -1747,6 +1767,10 @@ static int try_or_set_ext_ctrls(struct
> > v4l2_ctrl_handler *hdl,
> >
> > v4l2_ctrl_unlock(ctrl);
> > cluster_done(i, cs, helpers);
> >
> > }
> >
> > +
> > + if (set && hdl->commit)
> > + hdl->commit(hdl, ret == 0);
> > +
>
> If you rollback a transaction, then you also have a problem: if some of the
> controls of the transaction succeeded then try_or_set_control_cluster()
> will have set the current control value to the new value (since the 'set'
> succeeded).
>
> But if you rollback the transaction, then that means that the old value
> isn't restored for such controls.
>
> I don't see an easy solution for that offhand.
>
> I really wonder whether you are not reinventing the control cluster here.
>
> If you put all shadowed controls in a cluster, then it will behave exactly
> the same as a transaction.
>
> Yes, that might mean that all controls of a subdev are in a single cluster.
> But so what? That's the way to atomically handle controls that in some
> manner are related.
More and more sensors start to support control transactions. The MT9V034 even
supports two sets of control-related registers, with a single command to
switch between them. We need a way to support that in the control framework.
Putting all controls into a cluster seems like a dirty hack to workaround the
pr
Re: omap3isp cache error when unloading
Hi,
[snip]
> Sorry, I should've mentioned: I'm using your media-0005-omap3isp branch
> based on 2.6.38-rc5. I didn't have the problem with 2.6.37, either.
> It's actually not related to mis-configuring the ISP pipeline like I
> thought at first- it also happens after I have successfully captured images.
>
> I've since tracked down the problem, although I don't understand the
> cache management well enough to be sure it's a proper fix, so hopefully
> some new recipients on this can make suggestions/comments.
>
> The patch below solves the problem, which modifies a commit by Fernando
> Guzman Lugo from December.
>
> -Michael
>
> From db35fb8edca2a4f8fd37197d77fd58676cb1dcac Mon Sep 17 00:00:00 2001
> From: Michael Jones
> Date: Thu, 3 Mar 2011 16:50:39 +0100
> Subject: [PATCH] fix iovmm slab cache error on module unload
>
> modify "OMAP: iommu: create new api to set valid da range"
>
> This modifies commit c7f4ab26e3bcdaeb3e19ec658e3ad9092f1a6ceb.
> ---
> arch/arm/plat-omap/iovmm.c | 5 -
> 1 files changed, 4 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/plat-omap/iovmm.c b/arch/arm/plat-omap/iovmm.c
> index 6dc1296..2fba6f1 100644
> --- a/arch/arm/plat-omap/iovmm.c
> +++ b/arch/arm/plat-omap/iovmm.c
> @@ -280,7 +280,10 @@ static struct iovm_struct *alloc_iovm_area(struct iommu
> *obj, u32 da,
> alignement = PAGE_SIZE;
>
> if (flags & IOVMF_DA_ANON) {
> - start = obj->da_start;
> + /*
> + * Reserve the first page for NULL
> + */
> + start = obj->da_start + PAGE_SIZE;
IMO if obj->da_start != 0, no need to add PAGE_SIZE. Otherwise, it
does make sense to correct wrong obj->da_start == 0. Another thing is
this piece of code is using alignement (alignment) variable instead of
PAGE_SIZE (which is the same value).
Br,
David
--
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/PATCH v7 1/5] Changes in include/linux/videodev2.h for MFC 5.1
This patch adds fourcc values for compressed video stream formats and
V4L2_CTRL_CLASS_CODEC. Also adds controls used by MFC 5.1 driver.
Signed-off-by: Kamil Debski
Signed-off-by: Kyungmin Park
---
include/linux/videodev2.h | 39 +++
1 files changed, 39 insertions(+), 0 deletions(-)
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index a94c4d5..a48a42e 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -369,6 +369,19 @@ struct v4l2_pix_format {
#define V4L2_PIX_FMT_DV v4l2_fourcc('d', 'v', 's', 'd') /* 1394
*/
#define V4L2_PIX_FMT_MPEG v4l2_fourcc('M', 'P', 'E', 'G') /* MPEG-1/2/4
*/
+#define V4L2_PIX_FMT_H264 v4l2_fourcc('H', '2', '6', '4') /* H264*/
+#define V4L2_PIX_FMT_H263 v4l2_fourcc('H', '2', '6', '3') /* H263*/
+#define V4L2_PIX_FMT_MPEG12 v4l2_fourcc('M', 'P', '1', '2') /* MPEG-1/2 */
+#define V4L2_PIX_FMT_MPEG4v4l2_fourcc('M', 'P', 'G', '4') /* MPEG-4 */
+#define V4L2_PIX_FMT_DIVX v4l2_fourcc('D', 'I', 'V', 'X') /* DivX */
+#define V4L2_PIX_FMT_DIVX3v4l2_fourcc('D', 'I', 'V', '3') /* DivX 3.11 */
+#define V4L2_PIX_FMT_DIVX4v4l2_fourcc('D', 'I', 'V', '4') /* DivX 4.12 */
+#define V4L2_PIX_FMT_DIVX500v4l2_fourcc('D', 'X', '5', '2') /* DivX 5.00 -
5.02 */
+#define V4L2_PIX_FMT_DIVX503v4l2_fourcc('D', 'X', '5', '3') /* DivX 5.03 -
x */
+#define V4L2_PIX_FMT_XVID v4l2_fourcc('X', 'V', 'I', 'D') /* Xvid */
+#define V4L2_PIX_FMT_VC1 v4l2_fourcc('V', 'C', '1', 'A') /* VC-1 */
+#define V4L2_PIX_FMT_VC1_RCV v4l2_fourcc('V', 'C', '1', 'R') /* VC-1 RCV
*/
+
/* Vendor-specific formats */
#define V4L2_PIX_FMT_CPIA1v4l2_fourcc('C', 'P', 'I', 'A') /* cpia1 YUV */
#define V4L2_PIX_FMT_WNVA v4l2_fourcc('W', 'N', 'V', 'A') /* Winnov hw
compress */
@@ -1016,6 +1029,7 @@ struct v4l2_ext_controls {
#define V4L2_CTRL_CLASS_MPEG 0x0099/* MPEG-compression controls */
#define V4L2_CTRL_CLASS_CAMERA 0x009a /* Camera class controls */
#define V4L2_CTRL_CLASS_FM_TX 0x009b /* FM Modulator control class */
+#define V4L2_CTRL_CLASS_CODEC 0x009c /* Codec control class */
#define V4L2_CTRL_ID_MASK(0x0fff)
#define V4L2_CTRL_ID2CLASS(id)((id) & 0x0fffUL)
@@ -1349,6 +1363,31 @@ enum v4l2_mpeg_cx2341x_video_median_filter_type {
#define V4L2_CID_MPEG_CX2341X_VIDEO_CHROMA_MEDIAN_FILTER_TOP
(V4L2_CID_MPEG_CX2341X_BASE+10)
#define V4L2_CID_MPEG_CX2341X_STREAM_INSERT_NAV_PACKETS
(V4L2_CID_MPEG_CX2341X_BASE+11)
+/* For codecs */
+
+#define V4L2_CID_CODEC_BASE(V4L2_CTRL_CLASS_CODEC | 0x900)
+#define V4L2_CID_CODEC_CLASS (V4L2_CTRL_CLASS_CODEC | 1)
+
+/* For both decoding and encoding */
+
+/* For encoding */
+#define V4L2_CID_CODEC_LOOP_FILTER_H264(V4L2_CID_CODEC_BASE +
1)
+enum v4l2_cid_codec_loop_filter_h264 {
+ V4L2_CID_CODEC_LOOP_FILTER_H264_ENABLE = 0,
+ V4L2_CID_CODEC_LOOP_FILTER_H264_DISABLE = 1,
+ V4L2_CID_CODEC_LOOP_FILTER_H264_DISABLE_AT_BOUNDARY = 2,
+};
+
+/* For decoding */
+
+#define V4L2_CID_CODEC_LOOP_FILTER_MPEG4_ENABLE(V4L2_CID_CODEC_BASE +
2)
+#define V4L2_CID_CODEC_DISPLAY_DELAY (V4L2_CID_CODEC_BASE + 3)
+#define V4L2_CID_CODEC_DISPLAY_DELAY_ENABLE(V4L2_CID_CODEC_BASE + 4)
+#define V4L2_CID_CODEC_MIN_REQ_BUFS_OUT(V4L2_CID_CODEC_BASE +
5)
+#define V4L2_CID_CODEC_MIN_REQ_BUFS_CAP(V4L2_CID_CODEC_BASE +
6)
+#define V4L2_CID_CODEC_SLICE_INTERFACE (V4L2_CID_CODEC_BASE + 7)
+#define V4L2_CID_CODEC_PACKED_PB (V4L2_CID_CODEC_BASE + 8)
+
/* Camera class control IDs */
#define V4L2_CID_CAMERA_CLASS_BASE (V4L2_CTRL_CLASS_CAMERA | 0x900)
#define V4L2_CID_CAMERA_CLASS (V4L2_CTRL_CLASS_CAMERA | 1)
--
1.6.3.3
--
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/PATCH v7 2/5] MFC: Add MFC 5.1 driver to plat-s5p
This patch adds platform support for Multi Format Codec 5.1.
MFC 5.1 is capable of handling a range of video codecs and this driver
provides V4L2 interface for video decoding.
Signed-off-by: Kamil Debski
Signed-off-by: Kyungmin Park
---
arch/arm/mach-s5pv310/clock.c | 28 -
arch/arm/mach-s5pv310/include/mach/map.h|2 +
arch/arm/mach-s5pv310/include/mach/regs-clock.h |3 +
arch/arm/plat-s5p/Kconfig |5 ++
arch/arm/plat-s5p/Makefile |2 +-
arch/arm/plat-s5p/dev-mfc.c | 49 +++
arch/arm/plat-samsung/include/plat/devs.h |1 +
7 files changed, 88 insertions(+), 2 deletions(-)
create mode 100644 arch/arm/plat-s5p/dev-mfc.c
diff --git a/arch/arm/mach-s5pv310/clock.c b/arch/arm/mach-s5pv310/clock.c
index f142b8c..d28fa6f 100644
--- a/arch/arm/mach-s5pv310/clock.c
+++ b/arch/arm/mach-s5pv310/clock.c
@@ -523,6 +523,11 @@ static struct clk init_clocks_off[] = {
.enable = s5pv310_clk_ip_lcd1_ctrl,
.ctrlbit= (1 << 0),
}, {
+ .name = "mfc",
+ .id = -1,
+ .enable = s5pv310_clk_ip_mfc_ctrl,
+ .ctrlbit= (1 << 0),
+ }, {
.name = "hsmmc",
.id = 0,
.parent = &clk_aclk_133.clk,
@@ -734,6 +739,18 @@ static struct clksrc_sources clkset_group = {
.nr_sources = ARRAY_SIZE(clkset_group_list),
};
+static struct clk *clkset_group1_list[] = {
+ [0] = &clk_mout_mpll.clk,
+ [1] = &clk_sclk_apll.clk,
+ [2] = &clk_mout_epll.clk,
+ [3] = &clk_sclk_vpll.clk,
+};
+
+static struct clksrc_sources clkset_group1 = {
+ .sources= clkset_group1_list,
+ .nr_sources = ARRAY_SIZE(clkset_group1_list),
+};
+
static struct clk *clkset_mout_g2d0_list[] = {
[0] = &clk_mout_mpll.clk,
[1] = &clk_sclk_apll.clk,
@@ -1076,7 +1093,16 @@ static struct clksrc_clk clksrcs[] = {
.ctrlbit= (1 << 16),
},
.reg_div = { .reg = S5P_CLKDIV_FSYS3, .shift = 8, .size = 8 },
- }
+ }, {
+ .clk= {
+ .name = "sclk_mfc",
+ .id = -1,
+ },
+ .sources = &clkset_group1,
+ .reg_src = { .reg = S5P_CLKSRC_MFC, .shift = 8, .size = 1 },
+ .reg_div = { .reg = S5P_CLKDIV_MFC, .shift = 0, .size = 4 },
+ },
+
};
/* Clock initialization code */
diff --git a/arch/arm/mach-s5pv310/include/mach/map.h
b/arch/arm/mach-s5pv310/include/mach/map.h
index 0db3a47..576ba55 100644
--- a/arch/arm/mach-s5pv310/include/mach/map.h
+++ b/arch/arm/mach-s5pv310/include/mach/map.h
@@ -29,6 +29,7 @@
#define S5PV310_PA_FIMC1 0x1181
#define S5PV310_PA_FIMC2 0x1182
#define S5PV310_PA_FIMC3 0x1183
+#define S5PV310_PA_MFC 0x1340
#define S5PV310_PA_I2S00x0383
#define S5PV310_PA_I2S10xE310
#define S5PV310_PA_I2S20xE2A0
@@ -129,6 +130,7 @@
#define S5P_PA_FIMC1 S5PV310_PA_FIMC1
#define S5P_PA_FIMC2 S5PV310_PA_FIMC2
#define S5P_PA_FIMC3 S5PV310_PA_FIMC3
+#define S5P_PA_MFC S5PV310_PA_MFC
#define S5P_PA_ONENAND S5PC210_PA_ONENAND
#define S5P_PA_ONENAND_DMA S5PC210_PA_ONENAND_DMA
#define S5P_PA_SDRAM S5PV310_PA_SDRAM
diff --git a/arch/arm/mach-s5pv310/include/mach/regs-clock.h
b/arch/arm/mach-s5pv310/include/mach/regs-clock.h
index 9ef5f0c..f6b8181 100644
--- a/arch/arm/mach-s5pv310/include/mach/regs-clock.h
+++ b/arch/arm/mach-s5pv310/include/mach/regs-clock.h
@@ -176,4 +176,7 @@
#define S5P_EPLL_CON S5P_EPLL_CON0
+/* MFC related */
+#define S5P_CLKSRC_MFC S5P_CLKREG(0x0C228)
+#define S5P_CLKDIV_MFC S5P_CLKREG(0x0C528)
#endif /* __ASM_ARCH_REGS_CLOCK_H */
diff --git a/arch/arm/plat-s5p/Kconfig b/arch/arm/plat-s5p/Kconfig
index 4166964..ea9032e 100644
--- a/arch/arm/plat-s5p/Kconfig
+++ b/arch/arm/plat-s5p/Kconfig
@@ -5,6 +5,11 @@
#
# Licensed under GPLv2
+config S5P_DEV_MFC
+ bool
+ help
+ Compile in platform device definitions for MFC
+
config PLAT_S5P
bool
depends on (ARCH_S5P64X0 || ARCH_S5P6442 || ARCH_S5PC100 ||
ARCH_S5PV210 || ARCH_S5PV310)
diff --git a/arch/arm/plat-s5p/Makefile b/arch/arm/plat-s5p/Makefile
index cfcd1db..54e330d 100644
--- a/arch/arm/plat-s5p/Makefile
+++ b/arch/arm/plat-s5p/Makefile
@@ -24,7 +24,7 @@ obj-$(CONFIG_SUSPEND) += pm.o
obj-$(CONFIG_SUSPEND) += irq-pm.o
# devices
-
+obj-$(CONFIG_S5P_DEV
[PATCH/RFC v7 5/5] v4l: Documentation for the codec interface
This patch adds documentation for the codec interface of V4L2. Signed-off-by: Kamil Debski Signed-off-by: Kyungmin Park --- Documentation/DocBook/v4l/dev-codec.xml | 169 --- 1 files changed, 155 insertions(+), 14 deletions(-) diff --git a/Documentation/DocBook/v4l/dev-codec.xml b/Documentation/DocBook/v4l/dev-codec.xml index 6e156dc..73ecee8 100644 --- a/Documentation/DocBook/v4l/dev-codec.xml +++ b/Documentation/DocBook/v4l/dev-codec.xml @@ -1,21 +1,162 @@ - Codec Interface + Codec Interface - -Suspended + +A V4L2 codec can compress, decompress, transform, or otherwise convert +video data from one format into another format, in memory. Applications +can send and receive the data in two ways. First method utilizes +&func-write; and &func-read; calls to exchange the data. The second +uses streaming I/O to interact with the driver. + -This interface has been be suspended from the V4L2 API -implemented in Linux 2.6 until we have more experience with codec -device interfaces. - + +Codec devices belong to the group of memory-to-memory devices – memory +buffer containing a frame in one format is converted and stored in another +buffer in the memory. The format of capture and output buffers is +determined by the pixel formats passed in the &VIDIOC-S-FMT; call. + - A V4L2 codec can compress, decompress, transform, or otherwise -convert video data from one format into another format, in memory. -Applications send data to be converted to the driver through a -&func-write; call, and receive the converted data through a -&func-read; call. For efficiency a driver may also support streaming -I/O. + +Many advanced video codecs – such as H264 and MPEG4 require that decoded buffers +are kept as reference for other frames. This requirement may result in a use +case where a few output buffers have to be processed before the first capture +buffer is returned. In addition the buffers may be dequeued in an arbitrary +order. + - [to do] + +The codec hardware may enable to tweak decoding parameters and will require the +application to set encoding parameters. Hence the +V4L2_CTRL_CLASS_CODEC control class has been introduced. + + + +The standard V4L2 naming of buffers is kept – output means input of the device, +capture on the other hand means the device’s output. + + + + Querying Capabilities + + +Devices that support the codec interface set the +V4L2_CAP_VIDEO_M2M flag of the capabilities field of the +v4l2_capability struct returned by the &VIDIOC-QUERYCAP; ioctl. At least one of +the read/write or streaming I/O methods must be supported. + + + + + Multiple Instance Capabilities + + +Codecs as memory to memory devices can support multiple instances. +Drivers for devices with such capabilities should store configuration context +for every open file descriptor. This means that configuration is kept only until +the descriptor is closed and it is not possible to configure the device with one +application and perform streaming with another. If the device is capable of +handling only one stream at a time it can use a single context. + + + + + Image Format Negotiation + + +In case of decoding a video stream, the header may need to be parsed before the +stream decoding can take place. Usually only after the header is processed the +dimensions of the decoded image and the minimum number of buffers is known. This +requires that the output part of the interface has to be able to process the +header before allocating the buffers for capture. &VIDIOC-G-FMT; can be used by +the application to get the parameters of the capture buffers. If necessary the +&VIDIOC-S-FMT; call can be used to change those parameters, but it is up to the +driver to validate and correct those values. In addition it is necessary to +negotiate the number of capture buffers. In many cases the application may need +to allocate N more buffers than the minimum required by the codec. It can be +useful in case the device has a minimum number of buffers that have to be queued +in hardware to operate and if the application needs to keep N buffers dequeued +for processing. This cannot be easily done with &VIDIOC-REQBUFS; alone. To +address this issue the V4L2_CID_CODEC_MIN_REQ_ BUFS_CAP control has been +introduced and can be read to determine the minimum buffer count for the +capture queue. The application can use this number to calculate the number of +buffers passed to the REQBUFS call. The V4L2_CID_CODEC_MIN_REQ_ BUFS_OUT +control can also be used if the minimum number of buffers is determined for the +output queue, for example in case of encoding. + + + +When encoding &VIDIOC-S-FMT; has to be done on both capture and output. +&VIDIOC-S-FMT; on capture will determine the video codec to be used and encoding +parameters should be configured by setting appropriate contr
[RFC/PATCH v7 4/5] s5pv310: Enable MFC on universal_c210 board
This patch enables MFC 5.1 on the universal_c210 board. Multi Format
Codec 5.1 is capable of handling a range of video codecs.
Signed-off-by: Kamil Debski
Signed-off-by: Kyungmin Park
---
arch/arm/mach-s5pv310/Kconfig |1 +
arch/arm/mach-s5pv310/mach-universal_c210.c |8
2 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-s5pv310/Kconfig b/arch/arm/mach-s5pv310/Kconfig
index c850086..6f83817 100644
--- a/arch/arm/mach-s5pv310/Kconfig
+++ b/arch/arm/mach-s5pv310/Kconfig
@@ -107,6 +107,7 @@ config MACH_UNIVERSAL_C210
select S5PV310_SETUP_SDHCI
select S3C_DEV_I2C1
select S3C_DEV_I2C5
+ select S5P_DEV_MFC
select S5PV310_DEV_PD
select S5PV310_DEV_SYSMMU
select S5PV310_SETUP_I2C1
diff --git a/arch/arm/mach-s5pv310/mach-universal_c210.c
b/arch/arm/mach-s5pv310/mach-universal_c210.c
index f153895..ce88262 100644
--- a/arch/arm/mach-s5pv310/mach-universal_c210.c
+++ b/arch/arm/mach-s5pv310/mach-universal_c210.c
@@ -827,6 +827,10 @@ static struct platform_device *universal_devices[]
__initdata = {
&s5pv310_device_sysmmu[S5P_SYSMMU_FIMC1],
&s5pv310_device_sysmmu[S5P_SYSMMU_FIMC2],
&s5pv310_device_sysmmu[S5P_SYSMMU_FIMC3],
+ &s5p_device_mfc,
+ &s5pv310_device_pd[PD_MFC],
+ &s5pv310_device_sysmmu[S5P_SYSMMU_MFC_L],
+ &s5pv310_device_sysmmu[S5P_SYSMMU_MFC_R],
/* Universal Devices */
&universal_gpio_keys,
@@ -862,6 +866,10 @@ static void __init universal_machine_init(void)
s5pv310_device_sysmmu[S5P_SYSMMU_FIMC1].dev.parent =
&s5pv310_device_pd[PD_CAM].dev;
s5pv310_device_sysmmu[S5P_SYSMMU_FIMC2].dev.parent =
&s5pv310_device_pd[PD_CAM].dev;
s5pv310_device_sysmmu[S5P_SYSMMU_FIMC3].dev.parent =
&s5pv310_device_pd[PD_CAM].dev;
+
+ s5p_device_mfc.dev.parent = &s5pv310_device_pd[PD_MFC].dev;
+ s5pv310_device_sysmmu[S5P_SYSMMU_MFC_L].dev.parent =
&s5pv310_device_pd[PD_MFC].dev;
+ s5pv310_device_sysmmu[S5P_SYSMMU_MFC_R].dev.parent =
&s5pv310_device_pd[PD_MFC].dev;
}
MACHINE_START(UNIVERSAL_C210, "UNIVERSAL_C210")
--
1.6.3.3
--
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/PATCH v7 0/5] Multi Format Codec 5.1 driver for s5pv310 SoC
Hi, This is the seventh version of the MFC 5.1 driver. It is still a work in progress. This version currently supports decoding only, but encoding is heavily developed. For nearly two months new features were added and fixes and suggestions were implemented. The main purpose for posting this patch is to show an example driver that uses the new IOMMU vb2 allocator. In addition this is the first try to create a V4L2 codec driver that I know of. I hope to discuss issues related to this type of hardware on the upcoming brainstorming session in Warsaw. Major new features include: - proper handling for stream seeking (stream off + stream on and resume from another point of the stream). - support for resolution change in the stream - power domain handling - clock gating - support for IOMMU allocator - setting buffer flags according to decoded frame type: V4L2_BUF_FLAG_(KEY|P|B)FRAME - proper display delay handling for H264 Things that still need to be done: - move to the control framework - rebase onto Exynos4 platform name change * Stream seeking scenario is as follows: 1. Stream off on OUTPUT 2. Stream off on CAPTURE 3. Queue at least one new src buffer on OUTPUT (after stream off they all have been dequeued and at least one buffer has to be queued to successfully do a stream on) 4. Queue dst buffers on CAPTURE (after stream off they all have been dequeued) 5. Stream on on CAPTURE queue 6. Stream on on OUTPUT queue * Resolution change scenario: 1. Stream off on CAPTURE 2. Unmap the destination buffers Note: To successfully unmap the buffer they cannot be used by any other hardware, such as FIMC. Thus it necessary to shutdown FIMC - either close, or streamoff and reqbufs(0). 3. Call Reqbufs (0) on CAPTURE 4. Same as after parsing header a) Run G_FMT on CAPTURE b) Run G_CROP on CAPTURE c) Get the minimum number of buffers (by reading the V4L2_CID_CODEC_REQ_NUM_BUFS control) 5. Init CAPTURE stream a) Run Reqbufs with appropriate number of buffers (minimum + extra) b) Run Querybuf and Mmap on each buffer c) Run Q_BUF on the new buffers 6. Stream on on CAPTURE 7. Initialize FIMC Note: application is notified about resolution change in the same way as the notification that all decoded buffers have been read. The value of bytesused in the capture buffer is set to 0. If the application has sent last encoded stream frame then it is waiting for last decoded frame. If the application receives a frame with bytesused set to 0 with no error set in the middle of a stream then it should treat is as the notification of resolution change. Best regards, Kamil * Changelog: == Changes since v6 == 1) Stream seeking handling - done by running stream off and then stream on from another point of the stream 2) Support for streams during which the resolution is changed - done by calling stream off, reallocating the buffers and stream on again to resume 3) Power domain handling 4) Clock gating hw related operations - This has introduced a large reduction in power use 5) Support for IOMMU allocator - Using IOMMU as the memory allocator removes the cache problem and the need for reserving continuous memory at system boot 6) Flags of v4l2_buffer are set accrodingly to the returned buffer frame type V4L2_BUF_FLAG_(KEY|P|B)FRAME 7) Fixed display delay handling of H264. Now dealy of 0 frames is possible, although it may cause that the frames are returned out of order. 8) Minor changes - global s5p_mfc_dev variable has been removed - improved Packed PB handling - fixed error handling - separate for decoding and display frames - some cosmetic changes to simplify the code and make it more readable == Changes since v5 == 1) Changes suggested by Hans Verkuil: - small change in videodev2.h - corrected control offsets - made the code more readable by simplifying if statements and using temporary pointers - mfc_mutex is now included in s5p_mfc_dev structure - after discussion with Peter Oh modification of fourcc defintions (replaced DX52 and DX53 with DX50) 2) Changes suggested by JongHun Han: - comsmetic changed of defines in regs-mfc5.h - in buffers that have no width adn height, such as the buffer for compressed stream, those values are set to 0 instead of 1 - remove redundant pointer to MFC registers - change name of the union in s5p_mfc_buf from paddr to cookie - removed global variable (struct s5p_mfc_dev *dev) and moved to use video_drvdata 3) Other changes: - added check for values returned after parsing header - in rare circumstances MFC hw returned 0x0 as image size and this could cause problems == Changes since v4 == 1) Changes suggested by Kukjin Kim from: - removed comment arch/arm/mach-s5pv210/include/mach/map.h - changed device name to s5p-mfc (removed "5", MFC version number
[partially solved] Re: Big ptoblem with small webcam
Użytkownik W.P. napisał: > Użytkownik Laurent Pinchart napisał: > >> Hi, >> >> On Wednesday 02 March 2011 16:57:05 W.P. wrote: >> >> >>> Hi there, >>> I just got an Creative VGA (640x480) USB Live Webcam, VF0520. >>> >>> lsusb (partial): >>> >>> Bus 003 Device 007: ID 041e:406c Creative Technology, Ltd >>> Device Descriptor: >>> bLength18 >>> bDescriptorType 1 >>> bcdUSB 2.00 >>> bDeviceClass 239 Miscellaneous Device >>> bDeviceSubClass 2 ? >>> bDeviceProtocol 1 Interface Association >>> bMaxPacketSize064 >>> idVendor 0x041e Creative Technology, Ltd >>> idProduct 0x406c >>> bcdDevice 10.19 >>> iManufacturer 1 Creative Labs >>> iProduct3 VF0520 Live! Cam Sync >>> iSerial 0 >>> bNumConfigurations 1 >>> >>> lsmod | grep vid: >>> uvcvideo 50184 0 >>> compat_ioctl32 5120 1 uvcvideo >>> videodev 32000 1 uvcvideo >>> v4l1_compat15876 2 uvcvideo,videodev >>> >>> uname -a (kernel from Fedora 10): >>> [root@laurent-home ~]# uname -a >>> Linux laurent-home 2.6.27.5-117.fc10.i686 #1 SMP Tue Nov 18 12:19:59 EST >>> 2008 i686 athlon i386 GNU/Linux >>> >>> Problem: device nodes are created, but NO video in gmplayer, tvtime >>> complains: can't open /dev/video0. >>> >>> Only trace in syslog is: >>> >>> Mar 2 16:26:56 laurent-home kernel: uvcvideo: Failed to submit URB 0 >>> (-28). >>> >>> >> This means the webcam requires more USB bandwidth than available. Another >> device probably uses USB bandwidth (it could be another webcam, an audio >> device, ...). >> >> >> > It is the only USB 2.0 device connected (rest are keyboard, mouse, 2x > PL2303 converters, BT, and WiFi (unused). But what is strange: it seems > device runs in 1.1 mode: > > Mar 3 15:54:46 laurent-home kernel: usb 3-1.4: new full speed USB > device using > uhci_hcd and address 24 > Mar 3 15:54:47 laurent-home kernel: usb 3-1.4: *not running at top > speed*; conne > ct to a high speed hub > Mar 3 15:54:47 laurent-home kernel: usb 3-1.4: configuration #1 chosen > from 1 > choice > Mar 3 15:54:47 laurent-home kernel: uvcvideo: Found UVC 1.00 device > VF0520 Liv > e! Cam Sync (041e:406c) > Mar 3 15:54:47 laurent-home kernel: uvcvideo: Found a valid video chain > (1 -> > 2). > Mar 3 15:54:47 laurent-home kernel: input: VF0520 Live! Cam Sync as > /devices/p > ci:00/:00:0b.1/usb3/3-1/3-1.4/3-1.4:1.0/input/input19 > Mar 3 15:54:47 laurent-home kernel: usb 3-1.4: New USB device found, > idVendor= > 041e, idProduct=406c > Mar 3 15:54:47 laurent-home kernel: usb 3-1.4: New USB device strings: > Mfr=1, > Product=3, SerialNumber=0 > Mar 3 15:54:47 laurent-home kernel: usb 3-1.4: Product: VF0520 Live! > Cam Sync > Mar 3 15:54:47 laurent-home kernel: usb 3-1.4: Manufacturer: Creative Labs > > But I have tested it with 2 hubs on different controller ports, same. > >>> Webcam is connected to VIA USB 2.0 controller through a USB 2.0 hub. >>> >>> What is strange, two days ago I tried apparently the same (model VF) >>> with SUCCESS. >>> Device seems working in Windoze (Ekiga). >>> >>> What should I check/ do? >>> >>> > Only switching OS (for test) and it works. WTF? > > Connecting to controller directly -> detected as high speed and works. Again, question is WTF? > W.P. > -- 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
[GIT PULL FOR 2.6.39] s5p-fimc driver and videobuf2 fixes
Hi Mauro, please pull the following change set, it's a couple of s5p-fimc driver fixes and updates after conversion to videobuf2. There are also two small corrections for the videobuf2 and documentation for NV12MT format. The following changes since commit 548b491f5a3221e26c0b08dece18fdc62930fe5e: [media] media/radio/wl1273: fix build errors (2011-02-27 21:36:52 -0300) are available in the git repository at: git://git.infradead.org/users/kmpark/linux-2.6-samsung s5p_fimc_for_mauro Andrzej Pietrasiewicz (1): v4l2: vb2-dma-sg: fix memory leak Kamil Debski (1): v4l: Documentation for the NV12MT format Marek Szyprowski (1): v4l2: vb2: fix queue reallocation and REQBUFS(0) case Sungchun Kang (1): s5p-fimc: fix ISR and buffer handling for fimc-capture Sylwester Nawrocki (6): s5p-fimc: Prevent oops when i2c adapter is not available s5p-fimc: Prevent hanging on device close and fix the locking s5p-fimc: Allow defining number of sensors at runtime s5p-fimc: Add a platform data entry for MIPI-CSI data alignment s5p-fimc: Use dynamic debug s5p-fimc: Fix G_FMT ioctl handler Documentation/DocBook/media-entities.tmpl|1 + Documentation/DocBook/v4l/nv12mt.gif | Bin 0 -> 2108 bytes Documentation/DocBook/v4l/nv12mt_example.gif | Bin 0 -> 6858 bytes Documentation/DocBook/v4l/pixfmt-nv12mt.xml | 74 +++ Documentation/DocBook/v4l/pixfmt.xml |1 + drivers/media/video/s5p-fimc/fimc-capture.c | 99 -- drivers/media/video/s5p-fimc/fimc-core.c | 266 ++ drivers/media/video/s5p-fimc/fimc-core.h | 50 -- drivers/media/video/s5p-fimc/fimc-reg.c |6 +- drivers/media/video/videobuf2-core.c |9 +- drivers/media/video/videobuf2-dma-sg.c |2 + include/media/s5p_fimc.h |9 +- 12 files changed, 307 insertions(+), 210 deletions(-) create mode 100644 Documentation/DocBook/v4l/nv12mt.gif create mode 100644 Documentation/DocBook/v4l/nv12mt_example.gif create mode 100644 Documentation/DocBook/v4l/pixfmt-nv12mt.xml Regards, Sylwester -- Sylwester Nawrocki Samsung Poland R&D Center -- 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: omap3isp cache error when unloading
From: Sakari Ailus Subject: Re: omap3isp cache error when unloading Date: Fri, 4 Mar 2011 09:38:22 +0200 > Hi Michael, > > Michael Jones wrote: >> On 03/02/2011 08:18 PM, Laurent Pinchart wrote: >>> Hi Michael, >>> >>> On Tuesday 01 March 2011 17:41:01 Michael Jones wrote: Hi all, I get a warning about a cache error with the following steps: 0. load omap3-isp 1. set up media broken media pipeline. (e.g. set different formats on opposite ends of a link, as will be the case for using the lane shifter) 2. try to capture images. isp_video_streamon() returns -EPIPE from the failed isp_video_validate_pipeline() call. 3. unload omap3-isp module then I get the following from kmem_cache_destroy(): slab error in kmem_cache_destroy(): cache `iovm_area_cache': Can't free all objects [] (unwind_backtrace+0x0/0xec) from [] (kmem_cache_destroy+0x88/0xf4) [] (kmem_cache_destroy+0x88/0xf4) from [] (sys_delete_module+0x1c4/0x230) [] (sys_delete_module+0x1c4/0x230) from [] (ret_fast_syscall+0x0/0x30) Then, when reloading the module: SLAB: cache with size 32 has lost its name Can somebody else confirm that they also observe this behavior? >>> >>> I can't reproduce that (tried both 2.6.32 and 2.6.37). Could you give me >>> some >>> more details about your exact test procedure (such as how you configure the >>> pipeline) ? >>> >> >> Sorry, I should've mentioned: I'm using your media-0005-omap3isp branch >> based on 2.6.38-rc5. I didn't have the problem with 2.6.37, either. >> It's actually not related to mis-configuring the ISP pipeline like I >> thought at first- it also happens after I have successfully captured images. >> >> I've since tracked down the problem, although I don't understand the >> cache management well enough to be sure it's a proper fix, so hopefully >> some new recipients on this can make suggestions/comments. >> >> The patch below solves the problem, which modifies a commit by Fernando >> Guzman Lugo from December. > > Thanks for the patch. > > It looks like this patch from Fernando, perhaps unintentionally, also > makes the first page mappable so the NULL address is also valid. The > NULL address isn't considered valid by the ISP driver which thus does > not iommu_vunmap() the NULL address. > > Hiroshi, David, what do you think? I think the patch is correct so it > could be applied with description changed to mention it disallows > mapping the first page again. > > Or is there a reason to allow mapping the first page automatically? I > personally don't see any. I think that was done "unintentionally". The invalid first page may be quite reasonable generally. -- 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: V4L2 'brainstorming' meeting in Warsaw, March 2011
Hi, Marek Jonghun Han & I will participate in that meeting. We are preparing for some topic that we want to talk with participants. I'll let you know about the agenda soon. > -Original Message- > From: linux-media-ow...@vger.kernel.org [mailto:linux-media- > ow...@vger.kernel.org] On Behalf Of Marek Szyprowski > Sent: Wednesday, March 02, 2011 12:27 AM > To: Marek Szyprowski; linux-media@vger.kernel.org > Subject: RE: V4L2 'brainstorming' meeting in Warsaw, March 2011 > > Hello once more, > > After some discussion on #v4l irc channel, I would like to inform that the > meeting > date has been fixed to my initial proposition: 3 days from 16 to 18 March > 2011. > > Best regards > -- > Marek Szyprowski > Samsung Poland R&D Center > > > -- > 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 -- 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] v4l2-ctrls: Add transaction support
Hi Laurent,
I'm afraid this approach won't work. See below for the details.
On Thursday, March 03, 2011 16:13:33 Laurent Pinchart wrote:
> Some hardware supports controls transactions. For instance, the MT9T001
> sensor can optionally shadow registers that influence the output image,
> allowing the host to explicitly control the shadow process.
>
> To support such hardware, drivers need to be notified when a control
> transation is about to start and when it has finished. Add begin() and
> commit() callback functions to the v4l2_ctrl_handler structure to
> support such notifications.
>
> Signed-off-by: Laurent Pinchart
> ---
> drivers/media/video/v4l2-ctrls.c | 42 +++--
> include/media/v4l2-ctrls.h |8 +++
> 2 files changed, 47 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/media/video/v4l2-ctrls.c
> b/drivers/media/video/v4l2-ctrls.c
> index 2412f08..d0e6265 100644
> --- a/drivers/media/video/v4l2-ctrls.c
> +++ b/drivers/media/video/v4l2-ctrls.c
> @@ -1264,13 +1264,22 @@ EXPORT_SYMBOL(v4l2_ctrl_handler_log_status);
> int v4l2_ctrl_handler_setup(struct v4l2_ctrl_handler *hdl)
> {
> struct v4l2_ctrl *ctrl;
> + unsigned int count = 0;
> int ret = 0;
>
> if (hdl == NULL)
> return 0;
> mutex_lock(&hdl->lock);
> - list_for_each_entry(ctrl, &hdl->ctrls, node)
> + list_for_each_entry(ctrl, &hdl->ctrls, node) {
> ctrl->done = false;
> + count++;
> + }
> +
> + if (hdl->begin) {
> + ret = hdl->begin(hdl, count == 1);
Note that count can be 0! In any case, rather then adding a counter you can
use list_empty() and list_is_singular().
> + if (ret)
> + goto done;
> + }
>
> list_for_each_entry(ctrl, &hdl->ctrls, node) {
> struct v4l2_ctrl *master = ctrl->cluster[0];
> @@ -1298,6 +1307,11 @@ int v4l2_ctrl_handler_setup(struct v4l2_ctrl_handler
> *hdl)
> if (master->cluster[i])
> master->cluster[i]->done = true;
> }
> +
> + if (hdl->commit)
> + hdl->commit(hdl, ret != 0);
> +
> +done:
I understand that you assume that all controls registered to a handler can
be used in a transaction. But isn't it possible that only a subset of the
controls
is shadowed? And so only certain controls can be in a transaction?
> mutex_unlock(&hdl->lock);
> return ret;
> }
> @@ -1717,6 +1731,12 @@ static int try_or_set_ext_ctrls(struct
> v4l2_ctrl_handler *hdl,
> return -EBUSY;
> }
>
> + if (set && hdl->begin) {
> + ret = hdl->begin(hdl, cs->count == 1);
> + if (ret)
> + return ret;
> + }
> +
You are assuming that all controls here are owned by the given control handler.
That's not necessarily the case though as a control handler can inherit controls
from another handler. So the cs array is an array of controls where each control
can be owned by a different handler.
> for (i = 0; !ret && i < cs->count; i++) {
> struct v4l2_ctrl *ctrl = helpers[i].ctrl;
> struct v4l2_ctrl *master = ctrl->cluster[0];
> @@ -1747,6 +1767,10 @@ static int try_or_set_ext_ctrls(struct
> v4l2_ctrl_handler *hdl,
> v4l2_ctrl_unlock(ctrl);
> cluster_done(i, cs, helpers);
> }
> +
> + if (set && hdl->commit)
> + hdl->commit(hdl, ret == 0);
> +
If you rollback a transaction, then you also have a problem: if some of the
controls of the transaction succeeded then try_or_set_control_cluster() will
have set the current control value to the new value (since the 'set' succeeded).
But if you rollback the transaction, then that means that the old value isn't
restored for such controls.
I don't see an easy solution for that offhand.
I really wonder whether you are not reinventing the control cluster here.
If you put all shadowed controls in a cluster, then it will behave exactly the
same as a transaction.
Yes, that might mean that all controls of a subdev are in a single cluster.
But so what? That's the way to atomically handle controls that in some manner
are related.
Regards,
Hans
> return ret;
> }
>
> @@ -1842,8 +1866,20 @@ static int set_ctrl(struct v4l2_ctrl *ctrl, s32 *val)
> ctrl->val = *val;
> ctrl->is_new = 1;
> ret = try_or_set_control_cluster(master, false);
> - if (!ret)
> - ret = try_or_set_control_cluster(master, true);
> + if (ret)
> + goto done;
> +
> + if (master->handler->begin) {
> + ret = master->handler->begin(master->handler, true);
> + if (ret)
> + goto done;
> + }
> +
> + ret = try_or_set_control_cluster(master, true);
> + if (master->handler->commit)
> + master->handler->commit(master->handler, ret != 0);
> +
> +done:
> *val = ctrl-
Re: V4L2 'brainstorming' meeting in Warsaw, March 2011
Hi, I would gladly join this meeting but unfortunately I cannot attend. On the other hand I am glad to present that Willy Poisson from ST-Ericsson can join. Willy will mainly focus on Camera/imaging parts in which we believe V4L2 may fit very well. Some comments: Regarding OGL/ES in V4L2 I do not quite get the connection. As long as there is a common system memory handle...like hwmem any buffer dequeued from a camera or video decoder automatically slips into GLES...right. Of course the GL hw driver must also be aware of hwmem and accept the bufferformat used. Regarding HDMI API: We have some thoughts here as well...I'll get back to you. Regarding Buffer Pool: As you already know hwmem is one proposal but we are moving more towards GEM(since it's there already) with hwmem style though with CMA at the bottomI'll get back to you on this matter as well. Have a nice meeting in Warsaw! BR /Robert Fekete (robert.fek...@stericsson.com) > On 1 March 2011 16:26, Marek Szyprowski wrote: >> >> Hello once more, >> >> After some discussion on #v4l irc channel, I would like to inform that the >> meeting >> date has been fixed to my initial proposition: 3 days from 16 to 18 March >> 2011. >> >> Best regards >> -- >> Marek Szyprowski >> Samsung Poland R&D Center >> >> >> -- >> 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 > > -- 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] ARM: Samsung: update/rewrite Samsung SYSMMU (IOMMU) driver
From: Andrzej Pietrasiewicz
This patch performs a complete rewrite of sysmmu driver for Samsung platform:
- the new version introduces an api to construct device private page
tables and enables to use device private address space mode
- simplified the resource management: no more single platform
device with 32 resources is needed, better fits into linux driver model,
each sysmmu instance has it's own resource definition
- added support for sysmmu clocks
- some other minor API chages required by upcoming videobuf2 allocator
Signed-off-by: Andrzej Pietrasiewicz
Signed-off-by: Kyungmin Park
Signed-off-by: Marek Szyprowski
---
arch/arm/mach-s5pv310/clock.c| 91 ++
arch/arm/mach-s5pv310/dev-sysmmu.c | 582 +
arch/arm/mach-s5pv310/include/mach/irqs.h| 36 +-
arch/arm/mach-s5pv310/include/mach/regs-clock.h |3 +
arch/arm/mach-s5pv310/include/mach/regs-sysmmu.h | 23 +-
arch/arm/mach-s5pv310/include/mach/sysmmu.h | 122 ---
arch/arm/plat-s5p/Kconfig| 17 +-
arch/arm/plat-s5p/include/plat/sysmmu.h | 127 +++
arch/arm/plat-s5p/sysmmu.c | 988 +++---
arch/arm/plat-samsung/include/plat/devs.h|2 +-
10 files changed, 1323 insertions(+), 668 deletions(-)
rewrite arch/arm/mach-s5pv310/dev-sysmmu.c (86%)
delete mode 100644 arch/arm/mach-s5pv310/include/mach/sysmmu.h
create mode 100644 arch/arm/plat-s5p/include/plat/sysmmu.h
rewrite arch/arm/plat-s5p/sysmmu.c (85%)
diff --git a/arch/arm/mach-s5pv310/clock.c b/arch/arm/mach-s5pv310/clock.c
index fc7c2f8..f142b8c 100644
--- a/arch/arm/mach-s5pv310/clock.c
+++ b/arch/arm/mach-s5pv310/clock.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include
#include
@@ -116,6 +117,21 @@ static int s5pv310_clk_ip_perir_ctrl(struct clk *clk, int
enable)
return s5p_gatectrl(S5P_CLKGATE_IP_PERIR, clk, enable);
}
+static int s5pv310_clk_ip_dmc_ctrl(struct clk *clk, int enable)
+{
+ return s5p_gatectrl(S5P_CLKGATE_IP_DMC, clk, enable);
+}
+
+static int s5pv310_clk_ip_mfc_ctrl(struct clk *clk, int enable)
+{
+ return s5p_gatectrl(S5P_CLKGATE_IP_MFC, clk, enable);
+}
+
+static int s5pv310_clk_ip_tv_ctrl(struct clk *clk, int enable)
+{
+ return s5p_gatectrl(S5P_CLKGATE_IP_TV, clk, enable);
+}
+
/* Core list of CMU_CPU side */
static struct clksrc_clk clk_mout_apll = {
@@ -422,6 +438,81 @@ static struct clk init_clocks_off[] = {
.enable = s5pv310_clk_ip_cam_ctrl,
.ctrlbit= (1 << 3),
}, {
+ .name = "sysmmu",
+ .id = S5P_SYSMMU_MFC_L,
+ .enable = s5pv310_clk_ip_mfc_ctrl,
+ .ctrlbit= ((15 << 1) | 1),
+ }, {
+ .name = "sysmmu",
+ .id = S5P_SYSMMU_MFC_R,
+ .enable = s5pv310_clk_ip_mfc_ctrl,
+ .ctrlbit= ((15 << 1) | 1),
+ }, {
+ .name = "sysmmu",
+ .id = S5P_SYSMMU_FIMC0,
+ .enable = s5pv310_clk_ip_cam_ctrl,
+ .ctrlbit= (1 << 7),
+ }, {
+ .name = "sysmmu",
+ .id = S5P_SYSMMU_FIMC1,
+ .enable = s5pv310_clk_ip_cam_ctrl,
+ .ctrlbit= (1 << 8),
+ } , {
+ .name = "sysmmu",
+ .id = S5P_SYSMMU_FIMC2,
+ .enable = s5pv310_clk_ip_cam_ctrl,
+ .ctrlbit= (1 << 9),
+ } , {
+ .name = "sysmmu",
+ .id = S5P_SYSMMU_FIMC3,
+ .enable = s5pv310_clk_ip_cam_ctrl,
+ .ctrlbit= (1 << 10),
+ } , {
+ .name = "sysmmu",
+ .id = S5P_SYSMMU_JPEG,
+ .enable = s5pv310_clk_ip_cam_ctrl,
+ .ctrlbit= (1 << 11),
+ } , {
+ .name = "sysmmu",
+ .id = S5P_SYSMMU_TV,
+ .enable = s5pv310_clk_ip_tv_ctrl,
+ .ctrlbit= (1 << 4),
+ } , {
+ .name = "sysmmu",
+ .id = S5P_SYSMMU_G2D,
+ .enable = s5pv310_clk_ip_image_ctrl,
+ .ctrlbit= (1 << 3),
+ } , {
+ .name = "sysmmu",
+ .id = S5P_SYSMMU_ROTATOR,
+ .enable = s5pv310_clk_ip_image_ctrl,
+ .ctrlbit= (1 << 4),
+ } , {
+ .name = "sysmmu",
+ .id = S5P_SYSMMU_MDMA,
+ .enable = s5pv310_clk_ip_image_ctrl,
+ .ctrlbit= (1 << 5),
+ } , {
+
[PATCH 4/7] v4l: videobuf2: add Samsung SYSMMU (IOMMU) based allocator
From: Andrzej Pietrasiewicz
This patch adds new videobuf2 memory allocator dedicated to Samsung SoC
series with IOMMU module. It requires s5p-sysmmu low level driver for
controlling iommu. This allocator aquires memory with standard
alloc_page() call and doesn't suffer from memory fragmentation issues.
Curretnly it supports only iommu module on Sasmung S5PV310 SoC series.
Signed-off-by: Andrzej Pietrasiewicz
Signed-off-by: Kyungmin Park
Signed-off-by: Marek Szyprowski
---
drivers/media/video/Kconfig |8 +-
drivers/media/video/Makefile |1 +
drivers/media/video/videobuf2-s5p-iommu.c | 444 +
include/media/videobuf2-s5p-iommu.h | 50
4 files changed, 502 insertions(+), 1 deletions(-)
create mode 100644 drivers/media/video/videobuf2-s5p-iommu.c
create mode 100644 include/media/videobuf2-s5p-iommu.h
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index e2f5a69..9806505 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -60,12 +60,18 @@ config VIDEOBUF2_VMALLOC
select VIDEOBUF2_MEMOPS
tristate
-
config VIDEOBUF2_DMA_SG
#depends on HAS_DMA
select VIDEOBUF2_CORE
select VIDEOBUF2_MEMOPS
tristate
+
+config VIDEOBUF2_S5P_IOMMU
+ select GENERIC_ALLOCATOR
+ select VIDEOBUF2_CORE
+ select VIDEOBUF2_MEMOPS
+ tristate
+
#
# Multimedia Video device configuration
#
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index ac54652..fd9488d 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -118,6 +118,7 @@ obj-$(CONFIG_VIDEOBUF2_MEMOPS) +=
videobuf2-memops.o
obj-$(CONFIG_VIDEOBUF2_VMALLOC)+= videobuf2-vmalloc.o
obj-$(CONFIG_VIDEOBUF2_DMA_CONTIG) += videobuf2-dma-contig.o
obj-$(CONFIG_VIDEOBUF2_DMA_SG) += videobuf2-dma-sg.o
+obj-$(CONFIG_VIDEOBUF2_S5P_IOMMU) += videobuf2-s5p-iommu.o
obj-$(CONFIG_V4L2_MEM2MEM_DEV) += v4l2-mem2mem.o
diff --git a/drivers/media/video/videobuf2-s5p-iommu.c
b/drivers/media/video/videobuf2-s5p-iommu.c
new file mode 100644
index 000..5826fe0
--- /dev/null
+++ b/drivers/media/video/videobuf2-s5p-iommu.c
@@ -0,0 +1,444 @@
+/*
+ * videobuf2-s5p-iommu.c - SYSMMU (IOMMU) based memory allocator for videobuf2
+ *
+ * Copyright (C) 2011 Samsung Electronics
+ *
+ * Author: Andrzej Pietrasiewicz
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+/*
+ * 17: single piece of memory (one bitmap entry) equals 128k,
+ * so by default the genalloc's bitmap occupies 4kB (one page
+ * for a number of architectures)
+ */
+#define VB2_S5P_IOMMU_PIECE_ORDER 17
+
+/* -1: use default node id to allocate gen_pool/gen_pool_chunk structure from
*/
+#define VB2_S5P_IOMMU_NODE_ID -1
+
+/*
+ * starting address of the virtual address space of the client device
+ * must not be zero
+ */
+#define VB2_S5P_IOMMU_MEM_BASE 0x3000
+
+/* size of the virtual address space of the client device */
+#define VB2_S5P_IOMMU_MEM_SIZE 0x4000
+
+struct vb2_s5p_iommu_alloc_ctx {
+ /* not interpreted here; only passed to the sysmmu driver */
+ void *sysmmu;
+
+ struct gen_pool *pool;
+};
+
+struct vb2_s5p_iommu_desc {
+ unsigned long size;
+ unsigned intnum_pages;
+ struct page **pages;
+};
+
+struct vb2_s5p_iommu_buf {
+ unsigned long drv_addr;
+ unsigned long vaddr;
+
+ struct vb2_s5p_iommu_desc info;
+ int offset;
+ atomic_trefcount;
+ int write;
+ struct vm_area_struct *vma;
+
+ struct vb2_vmarea_handler handler;
+
+ struct vb2_s5p_iommu_alloc_ctx *ctx;
+};
+
+static void vb2_s5p_iommu_put(void *buf_priv);
+
+static void *vb2_s5p_iommu_alloc(void *alloc_ctx, unsigned long size)
+{
+ struct vb2_s5p_iommu_alloc_ctx *ctx = alloc_ctx;
+ struct vb2_s5p_iommu_buf *buf;
+ int i, ret;
+
+ BUG_ON(NULL == alloc_ctx);
+
+ buf = kzalloc(sizeof *buf, GFP_KERNEL);
+ if (!buf)
+ return NULL;
+
+ buf->drv_addr = gen_pool_alloc(ctx->pool, size);
+ if (0 == buf->drv_addr)
+ goto gen_pool_alloc_fail;
+
+ buf->info.size = size;
+ buf->info.num_pages = (size + PAGE_SIZE - 1) >> PAGE_SHIFT;
+ buf->ctx = ctx;
+ buf->info.pages = kzalloc(
+ buf->info.num_pages * sizeof(struct page *), GFP_KERNEL);
+ if (!buf->info.pages)
+ goto fail_pages_
[PATCH 2/7] ARM: S5PV310: power domains: fixes and code cleanup
From: Tomasz Stanislawski
This patch extends power domain driver with support for enabling and
disabling modules in S5P_CLKGATE_BLOCK register. It also performs a
little code cleanup to avoid confusion between s5pv310_device_pd array
index and power domain id.
Signed-off-by: Tomasz Stanislawski
Signed-off-by: Kyungmin Park
Signed-off-by: Marek Szyprowski
---
arch/arm/mach-s5pv310/dev-pd.c | 93 +--
arch/arm/mach-s5pv310/include/mach/regs-clock.h |9 ++
arch/arm/plat-samsung/include/plat/pd.h |1 +
3 files changed, 81 insertions(+), 22 deletions(-)
diff --git a/arch/arm/mach-s5pv310/dev-pd.c b/arch/arm/mach-s5pv310/dev-pd.c
index 58a50c2..e051998 100644
--- a/arch/arm/mach-s5pv310/dev-pd.c
+++ b/arch/arm/mach-s5pv310/dev-pd.c
@@ -16,13 +16,17 @@
#include
#include
+#include
#include
+static spinlock_t gate_block_slock = SPIN_LOCK_UNLOCKED;
+
static int s5pv310_pd_enable(struct device *dev)
{
struct samsung_pd_info *pdata = dev->platform_data;
u32 timeout;
+ int ret = 0;
__raw_writel(S5P_INT_LOCAL_PWR_EN, pdata->base);
@@ -31,21 +35,39 @@ static int s5pv310_pd_enable(struct device *dev)
while ((__raw_readl(pdata->base + 0x4) & S5P_INT_LOCAL_PWR_EN)
!= S5P_INT_LOCAL_PWR_EN) {
if (timeout == 0) {
- printk(KERN_ERR "Power domain %s enable failed.\n",
- dev_name(dev));
- return -ETIMEDOUT;
+ dev_err(dev, "enable failed\n");
+ ret = -ETIMEDOUT;
+ goto done;
}
timeout--;
udelay(100);
}
- return 0;
+ /* configure clk gate mask if it is present */
+ if (pdata->gate_mask) {
+ unsigned long flags;
+ unsigned long value;
+
+ spin_lock_irqsave(&gate_block_slock, flags);
+
+ value = __raw_readl(S5P_CLKGATE_BLOCK);
+ value |= pdata->gate_mask;
+ __raw_writel(value, S5P_CLKGATE_BLOCK);
+
+ spin_unlock_irqrestore(&gate_block_slock, flags);
+ }
+
+done:
+ dev_info(dev, "enable finished\n");
+
+ return ret;
}
static int s5pv310_pd_disable(struct device *dev)
{
struct samsung_pd_info *pdata = dev->platform_data;
u32 timeout;
+ int ret = 0;
__raw_writel(0, pdata->base);
@@ -53,81 +75,108 @@ static int s5pv310_pd_disable(struct device *dev)
timeout = 10;
while (__raw_readl(pdata->base + 0x4) & S5P_INT_LOCAL_PWR_EN) {
if (timeout == 0) {
- printk(KERN_ERR "Power domain %s disable failed.\n",
- dev_name(dev));
- return -ETIMEDOUT;
+ dev_err(dev, "disable failed\n");
+ ret = -ETIMEDOUT;
+ goto done;
}
timeout--;
udelay(100);
}
- return 0;
+ if (pdata->gate_mask) {
+ unsigned long flags;
+ unsigned long value;
+
+ spin_lock_irqsave(&gate_block_slock, flags);
+
+ value = __raw_readl(S5P_CLKGATE_BLOCK);
+ value &= ~pdata->gate_mask;
+ __raw_writel(value, S5P_CLKGATE_BLOCK);
+
+ spin_unlock_irqrestore(&gate_block_slock, flags);
+ }
+done:
+ dev_info(dev, "disable finished\n");
+
+ return ret;
}
struct platform_device s5pv310_device_pd[] = {
- {
+ [PD_MFC] = {
.name = "samsung-pd",
- .id = 0,
+ .id = PD_MFC,
.dev = {
.platform_data = &(struct samsung_pd_info) {
.enable = s5pv310_pd_enable,
.disable= s5pv310_pd_disable,
.base = S5P_PMU_MFC_CONF,
+ .gate_mask = S5P_CLKGATE_BLOCK_MFC,
},
},
- }, {
+ },
+ [PD_G3D] = {
.name = "samsung-pd",
- .id = 1,
+ .id = PD_G3D,
.dev = {
.platform_data = &(struct samsung_pd_info) {
.enable = s5pv310_pd_enable,
.disable= s5pv310_pd_disable,
.base = S5P_PMU_G3D_CONF,
+ .gate_mask = S5P_CLKGATE_BLOCK_G3D,
},
},
- }, {
+ },
+ [PD_LCD0] = {
.name = "samsung-pd",
- .id = 2,
+ .id = PD_LCD0,
[PATCH 7/7] ARM: S5PC210: enable FIMC on Universal_C210
This patch adds definitions to enable support for s5p-fimc driver
together with required power domains and sysmmu controller on Universal
C210 board.
Signed-off-by: Marek Szyprowski
Signed-off-by: Kyungmin Park
---
arch/arm/mach-s5pv310/Kconfig |6 ++
arch/arm/mach-s5pv310/mach-universal_c210.c | 20
2 files changed, 26 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-s5pv310/Kconfig b/arch/arm/mach-s5pv310/Kconfig
index a8b0425..c850086 100644
--- a/arch/arm/mach-s5pv310/Kconfig
+++ b/arch/arm/mach-s5pv310/Kconfig
@@ -97,12 +97,18 @@ config MACH_UNIVERSAL_C210
bool "Mobile UNIVERSAL_C210 Board"
select CPU_S5PV310
select S5P_DEV_ONENAND
+ select S5P_DEV_FIMC0
+ select S5P_DEV_FIMC1
+ select S5P_DEV_FIMC2
+ select S5P_DEV_FIMC3
select S3C_DEV_HSMMC
select S3C_DEV_HSMMC2
select S3C_DEV_HSMMC3
select S5PV310_SETUP_SDHCI
select S3C_DEV_I2C1
select S3C_DEV_I2C5
+ select S5PV310_DEV_PD
+ select S5PV310_DEV_SYSMMU
select S5PV310_SETUP_I2C1
select S5PV310_SETUP_I2C5
help
diff --git a/arch/arm/mach-s5pv310/mach-universal_c210.c
b/arch/arm/mach-s5pv310/mach-universal_c210.c
index eece381..f153895 100644
--- a/arch/arm/mach-s5pv310/mach-universal_c210.c
+++ b/arch/arm/mach-s5pv310/mach-universal_c210.c
@@ -24,7 +24,9 @@
#include
#include
#include
+#include
#include
+#include
#include
#include
@@ -816,6 +818,15 @@ static struct platform_device *universal_devices[]
__initdata = {
&s3c_device_hsmmc0,
&s3c_device_hsmmc2,
&s3c_device_hsmmc3,
+ &s5p_device_fimc0,
+ &s5p_device_fimc1,
+ &s5p_device_fimc2,
+ &s5p_device_fimc3,
+ &s5pv310_device_pd[PD_CAM],
+ &s5pv310_device_sysmmu[S5P_SYSMMU_FIMC0],
+ &s5pv310_device_sysmmu[S5P_SYSMMU_FIMC1],
+ &s5pv310_device_sysmmu[S5P_SYSMMU_FIMC2],
+ &s5pv310_device_sysmmu[S5P_SYSMMU_FIMC3],
/* Universal Devices */
&universal_gpio_keys,
@@ -842,6 +853,15 @@ static void __init universal_machine_init(void)
/* Last */
platform_add_devices(universal_devices, ARRAY_SIZE(universal_devices));
+
+ s5p_device_fimc0.dev.parent = &s5pv310_device_pd[PD_CAM].dev;
+ s5p_device_fimc1.dev.parent = &s5pv310_device_pd[PD_CAM].dev;
+ s5p_device_fimc2.dev.parent = &s5pv310_device_pd[PD_CAM].dev;
+ s5p_device_fimc3.dev.parent = &s5pv310_device_pd[PD_CAM].dev;
+ s5pv310_device_sysmmu[S5P_SYSMMU_FIMC0].dev.parent =
&s5pv310_device_pd[PD_CAM].dev;
+ s5pv310_device_sysmmu[S5P_SYSMMU_FIMC1].dev.parent =
&s5pv310_device_pd[PD_CAM].dev;
+ s5pv310_device_sysmmu[S5P_SYSMMU_FIMC2].dev.parent =
&s5pv310_device_pd[PD_CAM].dev;
+ s5pv310_device_sysmmu[S5P_SYSMMU_FIMC3].dev.parent =
&s5pv310_device_pd[PD_CAM].dev;
}
MACHINE_START(UNIVERSAL_C210, "UNIVERSAL_C210")
--
1.7.1.569.g6f426
--
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 6/7] s5p-fimc: Add support for vb2-s5p-iommu allocator
This patch adds support for videobuf2-s5p-iommu allocator to s5p-fimc
driver. This allocator is selected only on systems that contains support
for S5P SYSMMU module. Otherwise the standard videobuf2-dma-contig is
used.
Signed-off-by: Marek Szyprowski
Signed-off-by: Kyungmin Park
---
drivers/media/video/Kconfig |3 +-
drivers/media/video/s5p-fimc/fimc-capture.c |4 +-
drivers/media/video/s5p-fimc/fimc-core.c| 22 ---
drivers/media/video/s5p-fimc/fimc-mem.h | 87 +++
4 files changed, 104 insertions(+), 12 deletions(-)
create mode 100644 drivers/media/video/s5p-fimc/fimc-mem.h
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index 9806505..12fb325 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -1018,7 +1018,8 @@ config VIDEO_MEM2MEM_TESTDEV
config VIDEO_SAMSUNG_S5P_FIMC
tristate "Samsung S5P FIMC (video postprocessor) driver"
depends on VIDEO_DEV && VIDEO_V4L2 && PLAT_S5P
- select VIDEOBUF2_DMA_CONTIG
+ select VIDEOBUF2_S5P_IOMMU if S5P_SYSTEM_MMU
+ select VIDEOBUF2_DMA_CONTIG if !S5P_SYSTEM_MMU
select V4L2_MEM2MEM_DEV
help
This is a v4l2 driver for the S5P camera interface
diff --git a/drivers/media/video/s5p-fimc/fimc-capture.c
b/drivers/media/video/s5p-fimc/fimc-capture.c
index f8d7de5..6819908 100644
--- a/drivers/media/video/s5p-fimc/fimc-capture.c
+++ b/drivers/media/video/s5p-fimc/fimc-capture.c
@@ -29,8 +29,8 @@
#include
#include
#include
-#include
+#include "fimc-mem.h"
#include "fimc-core.h"
static struct v4l2_subdev *fimc_subdev_register(struct fimc_dev *fimc,
@@ -881,7 +881,7 @@ int fimc_register_capture_device(struct fimc_dev *fimc)
q->io_modes = VB2_MMAP | VB2_USERPTR;
q->drv_priv = fimc->vid_cap.ctx;
q->ops = &fimc_capture_qops;
- q->mem_ops = &vb2_dma_contig_memops;
+ q->mem_ops = &fimc_vb2_allocator_memops;
q->buf_struct_size = sizeof(struct fimc_vid_buffer);
vb2_queue_init(q);
diff --git a/drivers/media/video/s5p-fimc/fimc-core.c
b/drivers/media/video/s5p-fimc/fimc-core.c
index c92dbdb..f06aaea 100644
--- a/drivers/media/video/s5p-fimc/fimc-core.c
+++ b/drivers/media/video/s5p-fimc/fimc-core.c
@@ -27,8 +27,8 @@
#include
#include
#include
-#include
+#include "fimc-mem.h"
#include "fimc-core.h"
static char *fimc_clocks[MAX_FIMC_CLOCKS] = {
@@ -458,7 +458,7 @@ int fimc_prepare_addr(struct fimc_ctx *ctx, struct
vb2_buffer *vb,
dbg("memplanes= %d, colplanes= %d, pix_size= %d",
frame->fmt->memplanes, frame->fmt->colplanes, pix_size);
- paddr->y = vb2_dma_contig_plane_paddr(vb, 0);
+ paddr->y = fimc_vb2_plane_addr(vb, 0);
if (frame->fmt->memplanes == 1) {
switch (frame->fmt->colplanes) {
@@ -486,10 +486,10 @@ int fimc_prepare_addr(struct fimc_ctx *ctx, struct
vb2_buffer *vb,
}
} else {
if (frame->fmt->memplanes >= 2)
- paddr->cb = vb2_dma_contig_plane_paddr(vb, 1);
+ paddr->cb = fimc_vb2_plane_addr(vb, 1);
if (frame->fmt->memplanes == 3)
- paddr->cr = vb2_dma_contig_plane_paddr(vb, 2);
+ paddr->cr = fimc_vb2_plane_addr(vb, 2);
}
dbg("PHYS_ADDR: y= 0x%X cb= 0x%X cr= 0x%X ret= %d",
@@ -1375,7 +1375,7 @@ static int queue_init(void *priv, struct vb2_queue
*src_vq,
src_vq->io_modes = VB2_MMAP | VB2_USERPTR;
src_vq->drv_priv = ctx;
src_vq->ops = &fimc_qops;
- src_vq->mem_ops = &vb2_dma_contig_memops;
+ src_vq->mem_ops = &fimc_vb2_allocator_memops;
src_vq->buf_struct_size = sizeof(struct v4l2_m2m_buffer);
ret = vb2_queue_init(src_vq);
@@ -1387,7 +1387,7 @@ static int queue_init(void *priv, struct vb2_queue
*src_vq,
dst_vq->io_modes = VB2_MMAP | VB2_USERPTR;
dst_vq->drv_priv = ctx;
dst_vq->ops = &fimc_qops;
- dst_vq->mem_ops = &vb2_dma_contig_memops;
+ dst_vq->mem_ops = &fimc_vb2_allocator_memops;
dst_vq->buf_struct_size = sizeof(struct v4l2_m2m_buffer);
return vb2_queue_init(dst_vq);
@@ -1685,12 +1685,15 @@ static int fimc_probe(struct platform_device *pdev)
goto err_clk;
}
- /* Initialize contiguous memory allocator */
- fimc->alloc_ctx = vb2_dma_contig_init_ctx(&fimc->pdev->dev);
+ /* Initialize memory allocator */
+ fimc->alloc_ctx = fimc_vb2_allocator_init(pdev);
if (IS_ERR(fimc->alloc_ctx)) {
ret = PTR_ERR(fimc->alloc_ctx);
goto err_irq;
}
+ ret = fimc_vb2_allocator_enable(fimc->alloc_ctx);
+ if (ret)
+ goto err_irq;
ret = fimc_register_m2m_device(fimc);
if (ret)
@@ -1747,7 +1750,8 @@ static int __devexit fimc_remove(struct platform_device
*pdev)
fimc_cl
[PATCH/RFC 0/7] Samsung IOMMU videobuf2 allocator and s5p-fimc update
Hello, This patch series introduces new type of videbuf2 memory allocator - vb2-s5p-iommu. This allocator can be used only on Samsung SoCs that have IOMMU module. Currently only Samsung EXYNOS4 (former S5PV310) platform has SYSMMU modules. The allocator is then used by s5p-fimc driver. To make it possible some additional changes are required. Mainly platform support for s5p-fimc for EXYNOS4 machines need to be defined. The proposed solution has been tested on Universal C210 board (Samsung S5PC210/EXYNOS4 based). We decided to use driver private address space mode of the iommu driver. This way each vb2-s5p-iommu client gets it's own address space for memory buffers. This reduces kernel virtual memory fragmentation as well as solves some non-trivial page table updates issues. The drawback is the fact that the interface for s5p-sysmmu has been changed. This IOMMU allocator has no dependences on other subsystems besides Samsung platfrom core. We also ported s5p-mfc and s5p-tv drivers to this allocator, they will be posted in separate patch series. This will enable to get them working on EXYNOS4 (S5PV310) platform. Support for S5PV210/S5PC110 platform still depends on CMA allocator that needs more discussion on memory management mailing list and development. The patches with updated s5p-mfc and s5p-tv drivers will follow. To get FIMC module working on EXYNOS4/UniversalC210 board we also added support for power domains and power gating. This patch series contains a collection of patches for various platform subsystems. Here is a detailed list: [PATCH 1/7] ARM: S5PV310: Add platform definitions for FIMC - adds basic platform resources for FIMC modules (for s5p-fimc driver) [PATCH 2/7] ARM: S5PV310: power domains: fixes and code cleanup - adds support for block gating in Samsung power domain driver and performs some cleanup [PATCH 3/7] ARM: Samsung: update/rewrite Samsung SYSMMU (IOMMU) driver - a complete rewrite of sysmmu driver for Samsung platform: - the new version introduces device private page tables (address space) mode - simplified the resource management (no more horrible single platform device with 32 resources is needed) - some other API chages required by upcoming videobuf2 allocator [PATCH 4/7] v4l: videobuf2: add Samsung SYSMMU (IOMMU) based allocator - introduces new memory allocator for videobuf2, it uses s5p-sysmmu iommu driver, memory for video buffers is acuired by alloc_page() kernel function [PATCH 5/7] s5p-fimc: add pm_runtime support - adds support for pm_runtime in s5p-fimc driver [PATCH 6/7] s5p-fimc: Add support for vb2-s5p-iommu allocator - adds support for the newly introduces videbuf2-s5p-iommu allocator on EXYNOS4 platform [PATCH 7/7] ARM: S5PC210: enable FIMC on Universal_C210 - adds all required machine definitions to get FIMC modules working on Universal C210 boards The patch series is based on git://linuxtv.org/media_tree.git tree, staging/for_v2.6.39 branch with the following Samsung platform patches: 1. [PATCH] ARM: Samsung: change suspend/resume code to depend on CONFIG_SUSPEND http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg04025.html 2. [PATCH v2] ARM: S5PC210: add support for i2c PMICs on Universal_C210 board http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg04029.html This series has not been rebased onto the latest changes (S5PV310 renamed to EXYNOS4) in git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git, for-next branch. We will rebase them soon, but first we want to get feedback and comments on the s5p-iommu videobuf2 allocator idea. Best regards -- Marek Szyprowski Samsung Poland R&D Center Complete patch summary: Andrzej Pietrasiewicz (2): ARM: Samsung: update/rewrite Samsung SYSMMU (IOMMU) driver v4l: videobuf2: add Samsung SYSMMU (IOMMU) based allocator Marek Szyprowski (3): s5p-fimc: add pm_runtime support s5p-fimc: Add support for vb2-s5p-iommu allocator ARM: S5PC210: enable FIMC on Universal_C210 Sylwester Nawrocki (1): ARM: S5PV310: Add platform definitions for FIMC Tomasz Stanislawski (1): ARM: S5PV310: power domains: fixes and code cleanup arch/arm/mach-s5pv310/Kconfig|6 + arch/arm/mach-s5pv310/clock.c| 91 ++ arch/arm/mach-s5pv310/cpu.c |7 + arch/arm/mach-s5pv310/dev-pd.c | 93 ++- arch/arm/mach-s5pv310/dev-sysmmu.c | 582 + arch/arm/mach-s5pv310/include/mach/irqs.h| 40 +- arch/arm/mach-s5pv310/include/mach/map.h |8 + arch/arm/mach-s5pv310/include/mach/regs-clock.h | 12 + arch/arm/mach-s5pv310/include/mach/regs-sysmmu.h | 23 +- arch/arm/mach-s5pv310/include/mach/sysmmu.h | 122 --- arch/arm/mach-s5pv310/mach-universal_c210.c | 20 + arch/arm/plat-s5p/Kconfig| 22 +- arch/arm/plat-s5p/Makefile |1 + arch/arm/plat-s5p/dev-fimc3.c
[PATCH 1/7] ARM: S5PV310: Add platform definitions for FIMC
From: Sylwester Nawrocki Add support for fourth FIMC platform device definition and define resources for FIMC modules on S5PV310 machines. Signed-off-by: Sylwester Nawrocki Signed-off-by: Kyungmin Park Signed-off-by: Marek Szyprowski --- arch/arm/mach-s5pv310/cpu.c|7 arch/arm/mach-s5pv310/include/mach/irqs.h |4 ++ arch/arm/mach-s5pv310/include/mach/map.h |8 arch/arm/plat-s5p/Kconfig |5 +++ arch/arm/plat-s5p/Makefile |1 + arch/arm/plat-s5p/dev-fimc3.c | 43 arch/arm/plat-samsung/include/plat/devs.h |1 + arch/arm/plat-samsung/include/plat/fimc-core.h |5 +++ 8 files changed, 74 insertions(+), 0 deletions(-) create mode 100644 arch/arm/plat-s5p/dev-fimc3.c diff --git a/arch/arm/mach-s5pv310/cpu.c b/arch/arm/mach-s5pv310/cpu.c index 0db0fb6..0bdb0b0 100644 --- a/arch/arm/mach-s5pv310/cpu.c +++ b/arch/arm/mach-s5pv310/cpu.c @@ -21,6 +21,8 @@ #include #include #include +#include +#include #include @@ -114,6 +116,11 @@ void __init s5pv310_map_io(void) s5pv310_default_sdhci1(); s5pv310_default_sdhci2(); s5pv310_default_sdhci3(); + + s3c_fimc_setname(0, "s5pv310-fimc"); + s3c_fimc_setname(1, "s5pv310-fimc"); + s3c_fimc_setname(2, "s5pv310-fimc"); + s3c_fimc_setname(3, "s5pv310-fimc"); } void __init s5pv310_init_clocks(int xtal) diff --git a/arch/arm/mach-s5pv310/include/mach/irqs.h b/arch/arm/mach-s5pv310/include/mach/irqs.h index 536b0b5..0e99968 100644 --- a/arch/arm/mach-s5pv310/include/mach/irqs.h +++ b/arch/arm/mach-s5pv310/include/mach/irqs.h @@ -107,6 +107,10 @@ #define IRQ_MIPI_CSIS0 COMBINER_IRQ(30, 0) #define IRQ_MIPI_CSIS1 COMBINER_IRQ(30, 1) +#define IRQ_FIMC0 COMBINER_IRQ(32, 0) +#define IRQ_FIMC1 COMBINER_IRQ(32, 1) +#define IRQ_FIMC2 COMBINER_IRQ(33, 0) +#define IRQ_FIMC3 COMBINER_IRQ(33, 1) #define IRQ_ONENAND_AUDI COMBINER_IRQ(34, 0) diff --git a/arch/arm/mach-s5pv310/include/mach/map.h b/arch/arm/mach-s5pv310/include/mach/map.h index 901657f..0db3a47 100644 --- a/arch/arm/mach-s5pv310/include/mach/map.h +++ b/arch/arm/mach-s5pv310/include/mach/map.h @@ -25,6 +25,10 @@ #define S5PV310_PA_SYSRAM 0x02025000 +#define S5PV310_PA_FIMC0 0x1180 +#define S5PV310_PA_FIMC1 0x1181 +#define S5PV310_PA_FIMC2 0x1182 +#define S5PV310_PA_FIMC3 0x1183 #define S5PV310_PA_I2S00x0383 #define S5PV310_PA_I2S10xE310 #define S5PV310_PA_I2S20xE2A0 @@ -121,6 +125,10 @@ #define S5P_PA_CHIPID S5PV310_PA_CHIPID #define S5P_PA_MIPI_CSIS0 S5PV310_PA_MIPI_CSIS0 #define S5P_PA_MIPI_CSIS1 S5PV310_PA_MIPI_CSIS1 +#define S5P_PA_FIMC0 S5PV310_PA_FIMC0 +#define S5P_PA_FIMC1 S5PV310_PA_FIMC1 +#define S5P_PA_FIMC2 S5PV310_PA_FIMC2 +#define S5P_PA_FIMC3 S5PV310_PA_FIMC3 #define S5P_PA_ONENAND S5PC210_PA_ONENAND #define S5P_PA_ONENAND_DMA S5PC210_PA_ONENAND_DMA #define S5P_PA_SDRAM S5PV310_PA_SDRAM diff --git a/arch/arm/plat-s5p/Kconfig b/arch/arm/plat-s5p/Kconfig index 557f8c5..0db2a7a 100644 --- a/arch/arm/plat-s5p/Kconfig +++ b/arch/arm/plat-s5p/Kconfig @@ -60,6 +60,11 @@ config S5P_DEV_FIMC2 help Compile in platform device definitions for FIMC controller 2 +config S5P_DEV_FIMC3 + bool + help + Compile in platform device definitions for FIMC controller 3 + config S5P_DEV_ONENAND bool help diff --git a/arch/arm/plat-s5p/Makefile b/arch/arm/plat-s5p/Makefile index ce5a0a7..cfcd1db 100644 --- a/arch/arm/plat-s5p/Makefile +++ b/arch/arm/plat-s5p/Makefile @@ -28,6 +28,7 @@ obj-$(CONFIG_SUSPEND) += irq-pm.o obj-$(CONFIG_S5P_DEV_FIMC0)+= dev-fimc0.o obj-$(CONFIG_S5P_DEV_FIMC1)+= dev-fimc1.o obj-$(CONFIG_S5P_DEV_FIMC2)+= dev-fimc2.o +obj-$(CONFIG_S5P_DEV_FIMC3)+= dev-fimc3.o obj-$(CONFIG_S5P_DEV_ONENAND) += dev-onenand.o obj-$(CONFIG_S5P_DEV_CSIS0)+= dev-csis0.o obj-$(CONFIG_S5P_DEV_CSIS1)+= dev-csis1.o diff --git a/arch/arm/plat-s5p/dev-fimc3.c b/arch/arm/plat-s5p/dev-fimc3.c new file mode 100644 index 000..ef31bec --- /dev/null +++ b/arch/arm/plat-s5p/dev-fimc3.c @@ -0,0 +1,43 @@ +/* linux/arch/arm/plat-s5p/dev-fimc3.c + * + * Copyright (c) 2010 Samsung Electronics + * + * Base S5P FIMC3 resource and device definitions + * + * 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
[PATCH 5/7] s5p-fimc: add pm_runtime support
This patch adds basic support for pm_runtime to s5p-fimc driver. PM
runtime support is required to enable the driver on S5PV310 series with
power domain driver enabled.
Signed-off-by: Marek Szyprowski
Signed-off-by: Kyungmin Park
---
drivers/media/video/s5p-fimc/fimc-capture.c |5 +
drivers/media/video/s5p-fimc/fimc-core.c| 14 ++
2 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/s5p-fimc/fimc-capture.c
b/drivers/media/video/s5p-fimc/fimc-capture.c
index 59123a6..f8d7de5 100644
--- a/drivers/media/video/s5p-fimc/fimc-capture.c
+++ b/drivers/media/video/s5p-fimc/fimc-capture.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -395,6 +396,8 @@ static int fimc_capture_open(struct file *file)
if (fimc_m2m_active(fimc))
return -EBUSY;
+ pm_runtime_get_sync(&fimc->pdev->dev);
+
if (++fimc->vid_cap.refcnt == 1) {
ret = fimc_isp_subdev_init(fimc, 0);
if (ret) {
@@ -425,6 +428,8 @@ static int fimc_capture_close(struct file *file)
fimc_subdev_unregister(fimc);
}
+ pm_runtime_put_sync(&fimc->pdev->dev);
+
return 0;
}
diff --git a/drivers/media/video/s5p-fimc/fimc-core.c
b/drivers/media/video/s5p-fimc/fimc-core.c
index db3e730..c92dbdb 100644
--- a/drivers/media/video/s5p-fimc/fimc-core.c
+++ b/drivers/media/video/s5p-fimc/fimc-core.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -1407,6 +1408,8 @@ static int fimc_m2m_open(struct file *file)
if (fimc->vid_cap.refcnt > 0)
return -EBUSY;
+ pm_runtime_get_sync(&fimc->pdev->dev);
+
fimc->m2m.refcnt++;
set_bit(ST_OUTDMA_RUN, &fimc->state);
@@ -1449,6 +1452,8 @@ static int fimc_m2m_release(struct file *file)
if (--fimc->m2m.refcnt <= 0)
clear_bit(ST_OUTDMA_RUN, &fimc->state);
+ pm_runtime_put_sync(&fimc->pdev->dev);
+
return 0;
}
@@ -1646,6 +1651,11 @@ static int fimc_probe(struct platform_device *pdev)
goto err_req_region;
}
+ pm_runtime_set_active(&pdev->dev);
+ pm_runtime_enable(&pdev->dev);
+
+ pm_runtime_get_sync(&pdev->dev);
+
fimc->num_clocks = MAX_FIMC_CLOCKS - 1;
/* Check if a video capture node needs to be registered. */
@@ -1703,6 +1713,8 @@ static int fimc_probe(struct platform_device *pdev)
dev_dbg(&pdev->dev, "%s(): fimc-%d registered successfully\n",
__func__, fimc->id);
+ pm_runtime_put_sync(&pdev->dev);
+
return 0;
err_m2m:
@@ -1737,6 +1749,8 @@ static int __devexit fimc_remove(struct platform_device
*pdev)
vb2_dma_contig_cleanup_ctx(fimc->alloc_ctx);
+ pm_runtime_disable(&pdev->dev);
+
iounmap(fimc->regs);
release_resource(fimc->regs_res);
kfree(fimc->regs_res);
--
1.7.1.569.g6f426
--
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/4] omap3isp: lane shifter support
Signed-off-by: Michael Jones
---
drivers/media/video/omap3-isp/isp.c | 82 +-
drivers/media/video/omap3-isp/isp.h |4 +-
drivers/media/video/omap3-isp/ispccdc.c |2 +-
drivers/media/video/omap3-isp/ispvideo.c | 65 +---
drivers/media/video/omap3-isp/ispvideo.h |3 +
5 files changed, 134 insertions(+), 22 deletions(-)
diff --git a/drivers/media/video/omap3-isp/isp.c
b/drivers/media/video/omap3-isp/isp.c
index 08d90fe..20e6daa 100644
--- a/drivers/media/video/omap3-isp/isp.c
+++ b/drivers/media/video/omap3-isp/isp.c
@@ -273,6 +273,44 @@ static void isp_power_settings(struct isp_device *isp, int
idle)
}
/*
+ * Decide whether desired output pixel code can be obtained with
+ * the lane shifter by shifting the input pixel code.
+ * return 1 if the combination is possible
+ * return 0 otherwise
+ */
+int omap3isp_is_shiftable(enum v4l2_mbus_pixelcode in,
+ enum v4l2_mbus_pixelcode out)
+{
+ const struct isp_format_info *in_info, *out_info;
+ int shiftable = 0;
+ if ((in == 0) || (out == 0))
+ return 0;
+
+ if (in == out)
+ return 1;
+
+ in_info = omap3isp_video_format_info(in);
+ out_info = omap3isp_video_format_info(out);
+ if ((!in_info) || (!out_info))
+ return 0;
+
+ if (in_info->flavor != out_info->flavor)
+ return 0;
+
+ switch (in_info->bpp - out_info->bpp) {
+ case 2:
+ case 4:
+ case 6:
+ shiftable = 1;
+ break;
+ default:
+ shiftable = 0;
+ }
+
+ return shiftable;
+}
+
+/*
* Configure the bridge and lane shifter. Valid inputs are
*
* CCDC_INPUT_PARALLEL: Parallel interface
@@ -288,6 +326,10 @@ void omap3isp_configure_bridge(struct isp_device *isp,
const struct isp_parallel_platform_data *pdata)
{
u32 ispctrl_val;
+ u32 depth_in = 0, depth_out = 0;
+ u32 shift;
+ const struct isp_format_info *fmt_info;
+ struct media_pad *srcpad;
ispctrl_val = isp_reg_readl(isp, OMAP3_ISP_IOMEM_MAIN, ISP_CTRL);
ispctrl_val &= ~ISPCTRL_SHIFT_MASK;
@@ -298,7 +340,6 @@ void omap3isp_configure_bridge(struct isp_device *isp,
switch (input) {
case CCDC_INPUT_PARALLEL:
ispctrl_val |= ISPCTRL_PAR_SER_CLK_SEL_PARALLEL;
- ispctrl_val |= pdata->data_lane_shift << ISPCTRL_SHIFT_SHIFT;
ispctrl_val |= pdata->clk_pol << ISPCTRL_PAR_CLK_POL_SHIFT;
ispctrl_val |= pdata->bridge << ISPCTRL_PAR_BRIDGE_SHIFT;
break;
@@ -319,6 +360,45 @@ void omap3isp_configure_bridge(struct isp_device *isp,
return;
}
+ /* find output format from the remote end of the link connected to
+* CCDC sink pad
+*/
+ srcpad = media_entity_remote_source(&isp->isp_ccdc.pads[CCDC_PAD_SINK]);
+ if (srcpad == NULL)
+ dev_err(isp->dev, "No active input to CCDC.\n");
+
+ if (media_entity_type(srcpad->entity) == MEDIA_ENT_T_V4L2_SUBDEV) {
+ struct v4l2_subdev *subdev =
+ media_entity_to_v4l2_subdev(srcpad->entity);
+ struct v4l2_subdev_format fmt_src;
+ fmt_src.pad = srcpad->index;
+ fmt_src.which = V4L2_SUBDEV_FORMAT_ACTIVE;
+ if (!v4l2_subdev_call(subdev, pad, get_fmt, NULL, &fmt_src)) {
+ fmt_info =
+ omap3isp_video_format_info(fmt_src.format.code);
+ depth_in = fmt_info ? fmt_info->bpp : 0;
+ }
+ }
+
+ /* find CCDC input format */
+ fmt_info = omap3isp_video_format_info
+ (isp->isp_ccdc.formats[CCDC_PAD_SINK].code);
+ depth_out = fmt_info ? fmt_info->bpp : 0;
+
+ isp->isp_ccdc.syncif.datsz = depth_out;
+
+ /* determine necessary shifting */
+ if (depth_in == depth_out + 6)
+ shift = 3;
+ else if (depth_in == depth_out + 4)
+ shift = 2;
+ else if (depth_in == depth_out + 2)
+ shift = 1;
+ else
+ shift = 0;
+
+ ispctrl_val |= shift << ISPCTRL_SHIFT_SHIFT;
+
ispctrl_val &= ~ISPCTRL_SYNC_DETECT_MASK;
ispctrl_val |= ISPCTRL_SYNC_DETECT_VSRISE;
diff --git a/drivers/media/video/omap3-isp/isp.h
b/drivers/media/video/omap3-isp/isp.h
index 21fa88b..c84d349 100644
--- a/drivers/media/video/omap3-isp/isp.h
+++ b/drivers/media/video/omap3-isp/isp.h
@@ -144,8 +144,6 @@ struct isp_reg {
* ISPCTRL_PAR_BRIDGE_BENDIAN - Big endian
*/
struct isp_parallel_platform_data {
- unsigned int width;
- unsigned int data_lane_shift:2;
unsigned int clk_pol:1;
unsigned int bridge:4;
};
@@ -320,6 +318,8 @@ int omap3isp_module_sync_is_stopping(wait_queue_head_t
*wait,
int omap3isp_pipeline_set_str
[PATCH 3/4] omap3isp: ccdc: support Y10, Y12, SGRBG8, SBGGR8
Signed-off-by: Michael Jones
---
drivers/media/video/omap3-isp/ispccdc.c |4
drivers/media/video/omap3-isp/ispvideo.c |8
2 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/omap3-isp/ispccdc.c
b/drivers/media/video/omap3-isp/ispccdc.c
index e4d04ce..166115d 100644
--- a/drivers/media/video/omap3-isp/ispccdc.c
+++ b/drivers/media/video/omap3-isp/ispccdc.c
@@ -43,6 +43,10 @@ __ccdc_get_format(struct isp_ccdc_device *ccdc, struct
v4l2_subdev_fh *fh,
static const unsigned int ccdc_fmts[] = {
V4L2_MBUS_FMT_Y8_1X8,
+ V4L2_MBUS_FMT_Y10_1X10,
+ V4L2_MBUS_FMT_Y12_1X12,
+ V4L2_MBUS_FMT_SGRBG8_1X8,
+ V4L2_MBUS_FMT_SBGGR8_1X8,
V4L2_MBUS_FMT_SGRBG10_1X10,
V4L2_MBUS_FMT_SRGGB10_1X10,
V4L2_MBUS_FMT_SBGGR10_1X10,
diff --git a/drivers/media/video/omap3-isp/ispvideo.c
b/drivers/media/video/omap3-isp/ispvideo.c
index f16d787..c406043 100644
--- a/drivers/media/video/omap3-isp/ispvideo.c
+++ b/drivers/media/video/omap3-isp/ispvideo.c
@@ -48,6 +48,14 @@
static struct isp_format_info formats[] = {
{ V4L2_MBUS_FMT_Y8_1X8, V4L2_MBUS_FMT_Y8_1X8,
V4L2_MBUS_FMT_Y8_1X8, V4L2_PIX_FMT_GREY, 8, },
+ { V4L2_MBUS_FMT_Y10_1X10, V4L2_MBUS_FMT_Y10_1X10,
+ V4L2_MBUS_FMT_Y10_1X10, V4L2_PIX_FMT_Y10, 10, },
+ { V4L2_MBUS_FMT_Y12_1X12, V4L2_MBUS_FMT_Y10_1X10,
+ V4L2_MBUS_FMT_Y12_1X12, V4L2_PIX_FMT_Y12, 12, },
+ { V4L2_MBUS_FMT_SBGGR8_1X8, V4L2_MBUS_FMT_SBGGR8_1X8,
+ V4L2_MBUS_FMT_SBGGR8_1X8, V4L2_PIX_FMT_SBGGR8, 8, },
+ { V4L2_MBUS_FMT_SGRBG8_1X8, V4L2_MBUS_FMT_SGRBG8_1X8,
+ V4L2_MBUS_FMT_SGRBG8_1X8, V4L2_PIX_FMT_SGRBG8, 8, },
{ V4L2_MBUS_FMT_SGRBG10_DPCM8_1X8, V4L2_MBUS_FMT_SGRBG10_DPCM8_1X8,
V4L2_MBUS_FMT_SGRBG10_1X10, V4L2_PIX_FMT_SGRBG10DPCM8, 8, },
{ V4L2_MBUS_FMT_SBGGR10_1X10, V4L2_MBUS_FMT_SBGGR10_1X10,
--
1.7.4.1
MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
--
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/4] media: add 8-bit bayer formats and Y12
Signed-off-by: Michael Jones
---
include/linux/v4l2-mediabus.h |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/include/linux/v4l2-mediabus.h b/include/linux/v4l2-mediabus.h
index 7054a7a..46caecd 100644
--- a/include/linux/v4l2-mediabus.h
+++ b/include/linux/v4l2-mediabus.h
@@ -47,8 +47,9 @@ enum v4l2_mbus_pixelcode {
V4L2_MBUS_FMT_RGB565_2X8_BE = 0x1007,
V4L2_MBUS_FMT_RGB565_2X8_LE = 0x1008,
- /* YUV (including grey) - next is 0x2013 */
+ /* YUV (including grey) - next is 0x2014 */
V4L2_MBUS_FMT_Y8_1X8 = 0x2001,
+ V4L2_MBUS_FMT_Y12_1X12 = 0x2013,
V4L2_MBUS_FMT_UYVY8_1_5X8 = 0x2002,
V4L2_MBUS_FMT_VYUY8_1_5X8 = 0x2003,
V4L2_MBUS_FMT_YUYV8_1_5X8 = 0x2004,
@@ -67,9 +68,11 @@ enum v4l2_mbus_pixelcode {
V4L2_MBUS_FMT_YUYV10_1X20 = 0x200d,
V4L2_MBUS_FMT_YVYU10_1X20 = 0x200e,
- /* Bayer - next is 0x3013 */
+ /* Bayer - next is 0x3015 */
V4L2_MBUS_FMT_SBGGR8_1X8 = 0x3001,
+ V4L2_MBUS_FMT_SGBRG8_1X8 = 0x3013,
V4L2_MBUS_FMT_SGRBG8_1X8 = 0x3002,
+ V4L2_MBUS_FMT_SRGGB8_1X8 = 0x3014,
V4L2_MBUS_FMT_SBGGR10_DPCM8_1X8 = 0x300b,
V4L2_MBUS_FMT_SGBRG10_DPCM8_1X8 = 0x300c,
V4L2_MBUS_FMT_SGRBG10_DPCM8_1X8 = 0x3009,
--
1.7.4.1
MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
--
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/4] v4l: add V4L2_PIX_FMT_Y12 format
Signed-off-by: Michael Jones
---
include/linux/videodev2.h |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 02da9e7..6fac463 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -288,6 +288,7 @@ struct v4l2_pix_format {
#define V4L2_PIX_FMT_Y4 v4l2_fourcc('Y', '0', '4', ' ') /* 4 Greyscale
*/
#define V4L2_PIX_FMT_Y6 v4l2_fourcc('Y', '0', '6', ' ') /* 6 Greyscale
*/
#define V4L2_PIX_FMT_Y10 v4l2_fourcc('Y', '1', '0', ' ') /* 10 Greyscale
*/
+#define V4L2_PIX_FMT_Y12 v4l2_fourcc('Y', '1', '2', ' ') /* 12 Greyscale
*/
#define V4L2_PIX_FMT_Y16 v4l2_fourcc('Y', '1', '6', ' ') /* 16 Greyscale
*/
/* Palette formats */
--
1.7.4.1
MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/4] OMAP3-ISP lane shifter support
Add support for the ISP's lane shifter. To use the shifter, set different pixel formats at each end of the link at the CCDC input. This has only been tested shifting Y12 and SBGGR12 from a parallel sensor to Y8 and SBGGR12 (respectively) at the CCDC input. Support has also been added for other formats and other shifting values, but is untested. Shifting data coming from one of the serial sensor interfaces (CSI2a, etc) is also untested. As before, ccdc_try_format() does not check that the format at its input is compatible with the format coming from the sensor interface. This consistency check is first done when activating the pipeline. These patches apply to Laurent's media-0005-omap3isp branch, based on 2.6.38-rc5 Michael Jones (4): v4l: add V4L2_PIX_FMT_Y12 format media: add 8-bit bayer formats and Y12 omap3isp: ccdc: support Y10, Y12, SGRBG8, SBGGR8 omap3isp: lane shifter support drivers/media/video/omap3-isp/isp.c | 82 +- drivers/media/video/omap3-isp/isp.h |4 +- drivers/media/video/omap3-isp/ispccdc.c |6 ++- drivers/media/video/omap3-isp/ispvideo.c | 65 ++- drivers/media/video/omap3-isp/ispvideo.h |3 + include/linux/v4l2-mediabus.h|7 ++- include/linux/videodev2.h|1 + 7 files changed, 148 insertions(+), 20 deletions(-) -- 1.7.4.1 MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner -- 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
