Re: [PATCH 1/2] [media] drxd: allow functional gate control after, attach
On 12/16/2012 01:11 AM, Patrice Chotard wrote: Previously, gate control didn't work until drxd_init() execution. Migrate necessary set of commands in drxd_attach to allow gate control to be used by tuner which are accessible through i2c gate. Reported-by: frederic.mantega...@gbiloba.org Signed-off-by: Patrice Chotard patricechot...@free.fr --- drivers/media/dvb-frontends/drxd_hard.c |4 1 file changed, 4 insertions(+) diff --git a/drivers/media/dvb-frontends/drxd_hard.c b/drivers/media/dvb-frontends/drxd_hard.c index 6d98537..b2ab1e8 100644 --- a/drivers/media/dvb-frontends/drxd_hard.c +++ b/drivers/media/dvb-frontends/drxd_hard.c @@ -2978,6 +2978,10 @@ struct dvb_frontend *drxd_attach(const struct drxd_config *config, sizeof(struct dvb_frontend_ops)); state-frontend.demodulator_priv = state; ConfigureMPEGOutput(state, 0); + /* add few initialization to allow gate control */ + CDRXD(state, state-config.IF ? state-config.IF : 3600); + InitHI(state); + return state-frontend; error: Reviewed-by: Antti Palosaari cr...@iki.fi I looked it quite carefully. Comments could be nice, but as far as I understood: ConfigureMPEGOutput(state, 0); * that puts device sleeping, mostly configures MPEG TS IF (set pins to some state eg. Hi-Z to prevent current leakage, I can guess). CDRXD(state, state-config.IF ? state-config.IF : 3600); * that just initializes state - no I/O InitHI(state); * there is comment: port/bridge/power down ctrl * HI == host interface ? * that is normally done during init(), * only one command = not much I/O Looks fine, thank you! regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] [media] ngene: separate demodulator and tuner attach
On 12/16/2012 01:11 AM, Patrice Chotard wrote:
Previously, demodulator and tuner attach was done in the
demod_attach callback. Migrate the tuner part in the
tuner_attach callback in ngene_info to do thing in right place.
Signed-off-by: Patrice Chotard patricechot...@free.fr
---
drivers/media/pci/ngene/ngene-cards.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/media/pci/ngene/ngene-cards.c
b/drivers/media/pci/ngene/ngene-cards.c
index 96a13ed..8db3fa1 100644
--- a/drivers/media/pci/ngene/ngene-cards.c
+++ b/drivers/media/pci/ngene/ngene-cards.c
@@ -328,6 +328,15 @@ static int demod_attach_drxd(struct ngene_channel
*chan)
return -ENODEV;
}
+ return 0;
+}
+
+static int tuner_attach_dtt7520x(struct ngene_channel *chan)
+{
+ struct drxd_config *feconf;
+
+ feconf = chan-dev-card_info-fe_config[chan-number];
+
if (!dvb_attach(dvb_pll_attach, chan-fe, feconf-pll_address,
chan-i2c_adapter,
feconf-pll_type)) {
@@ -722,6 +731,7 @@ static struct ngene_info ngene_info_terratec = {
.name = Terratec Integra/Cinergy2400i Dual DVB-T,
.io_type= {NGENE_IO_TSIN, NGENE_IO_TSIN},
.demod_attach = {demod_attach_drxd, demod_attach_drxd},
+ .tuner_attach = {tuner_attach_dtt7520x, tuner_attach_dtt7520x},
.fe_config = {fe_terratec_dvbt_0, fe_terratec_dvbt_1},
.i2c_access = 1,
};
Reviewed-by: Antti Palosaari cr...@iki.fi
Looks very correct, but I am not familiar with n-gene.
regards
Antti
--
http://palosaari.fi/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC 1/2] V4L: Add auto focus selection targets
Hi Andzej, On Wed, Dec 12, 2012 at 02:59:32PM +0100, Andrzej Hajda wrote: On 11.12.2012 22:04, Sakari Ailus wrote: Hi Andrzej, Many thanks for the patch! On Mon, Dec 10, 2012 at 02:43:38PM +0100, Andrzej Hajda wrote: From: Sylwester Nawrocki s.nawro...@samsung.com The camera automatic focus algorithms may require setting up a spot or rectangle coordinates. The automatic focus selection targets are introduced in order to allow applications to query and set such coordinates. Those selections are intended to be used together with the automatic focus controls available in the camera control class. Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com Signed-off-by: Andrzej Hajda a.ha...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com --- Documentation/DocBook/media/v4l/selection-api.xml | 32 - .../DocBook/media/v4l/selections-common.xml| 37 .../media/v4l/vidioc-subdev-g-selection.xml|4 +-- include/uapi/linux/v4l2-common.h |5 +++ 4 files changed, 75 insertions(+), 3 deletions(-) diff --git a/Documentation/DocBook/media/v4l/selection-api.xml b/Documentation/DocBook/media/v4l/selection-api.xml index 4c238ce..8caf67b 100644 --- a/Documentation/DocBook/media/v4l/selection-api.xml +++ b/Documentation/DocBook/media/v4l/selection-api.xml @@ -1,6 +1,6 @@ section id=selection-api - titleExperimental API for cropping, composing and scaling/title + titleExperimental selections API/title Hmm. I wonder if it'd be enough to call this just Selection API. There's a note just below telling it's experimental. note titleExperimental/title @@ -9,6 +9,10 @@ interface and may change in the future./para /note + section + + titleImage cropping, composing and scaling/title + section titleIntroduction/title @@ -321,5 +325,31 @@ V4L2_BUF_TYPE_VIDEO_OUTPUT /constant for other devices/para /example /section + /section + + section + titleAutomatic focus regions of interest/title + +paraThe camera automatic focus algorithms may require configuration of +regions of interest in form of rectangle or spot coordinates. The automatic +focus selection targets allow applications to query and set such coordinates. +Those selections are intended to be used together with the +constantV4L2_CID_AUTO_FOCUS_AREA/constant link linkend=camera-controls +camera class/link control. The constantV4L2_SEL_TGT_AUTO_FOCUS/constant +target is used for querying or setting actual spot or rectangle coordinates, +while constantV4L2_SEL_TGT_AUTO_FOCUS_BOUNDS/constant target determines +bounds for a single spot or rectangle. +These selections are only effective when the constantV4L2_CID_AUTO_FOCUS_AREA +/constantcontrol is set to +constantV4L2_AUTO_FOCUS_AREA_RECTANGLE/constant. The new coordinates shall +be accepted and applied to hardware when the focus area control value is +changed and also during a VIDIOC-S-SELECTION; ioctl call, only when the focus +area control is already set to required value./para + +paraWhen the structfieldwidth/structfield and +structfieldheight/structfield of the selection rectangle are set to 0 the +selection determines spot coordinates, rather than a rectangle./para + + /section /section diff --git a/Documentation/DocBook/media/v4l/selections-common.xml b/Documentation/DocBook/media/v4l/selections-common.xml index 7502f78..9f0c477 100644 --- a/Documentation/DocBook/media/v4l/selections-common.xml +++ b/Documentation/DocBook/media/v4l/selections-common.xml @@ -93,6 +93,22 @@ entryYes/entry entryNo/entry /row + row + entryconstantV4L2_SEL_TGT_AUTO_FOCUS/constant/entry + entry0x1001/entry + entryActual automatic focus rectangle./entry + entryYes/entry + entryYes/entry + /row + row + entryconstantV4L2_SEL_TGT_AUTO_FOCUS_BOUNDS/constant/entry + entry0x1002/entry + entryBounds of the automatic focus region of interest. All valid + automatic focus rectangles fit inside the automatic focus bounds + rectangle./entry + entryYes/entry + entryYes/entry + /row /tbody /tgroup /table @@ -158,7 +174,28 @@ /tbody /tgroup /table + /section + + section + titleAutomatic focus regions of interest/title + + paraThe camera automatic focus algorithms may require configuration + of a region or multiple regions of interest in form of rectangle or spot + coordinates./para + + paraA single rectangle of interest is represented in v4l2-rect; + by the coordinates of the top left corner and the rectangle size. Both + the coordinates and sizes are expressed in pixels. When the structfield + width/structfield and structfieldheight/structfield fields of +
cannot make this Asus my cinema-u3100miniplusv2 work under linux
any news on this ? Asus my cinema-u3100miniplusv2 Bus 001 Device 015: ID 1b80:d3a8 Afatech [ 6956.333440] usb 1-6.3.6: new high-speed USB device number 16 using ehci_hcd [ 6956.453943] usb 1-6.3.6: New USB device found, idVendor=1b80, idProduct=d3a8 [ 6956.453950] usb 1-6.3.6: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 6956.453955] usb 1-6.3.6: Product: Rtl2832UDVB [ 6956.453959] usb 1-6.3.6: Manufacturer: Realtek -- 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: cannot make this Asus my cinema-u3100miniplusv2 work under linux
On 12/16/2012 04:23 PM, Renato Gallo wrote: any news on this ? Asus my cinema-u3100miniplusv2 Bus 001 Device 015: ID 1b80:d3a8 Afatech [ 6956.333440] usb 1-6.3.6: new high-speed USB device number 16 using ehci_hcd [ 6956.453943] usb 1-6.3.6: New USB device found, idVendor=1b80, idProduct=d3a8 [ 6956.453950] usb 1-6.3.6: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 6956.453955] usb 1-6.3.6: Product: Rtl2832UDVB [ 6956.453959] usb 1-6.3.6: Manufacturer: Realtek Seems to be Realtek RTL2832U. Add that USB ID to the driver and test. It is very high probability it starts working. Here is the patch: http://git.linuxtv.org/anttip/media_tree.git/shortlog/refs/heads/rtl28xxu-usb-ids Please test and report. regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC 2/2] V4L: Add V4L2_CID_AUTO_FOCUS_AREA control
Hi Andrzej, On Wed, Dec 12, 2012 at 04:14:22PM +0100, Andrzej Hajda wrote: On 11.12.2012 22:34, Sakari Ailus wrote: Hi Andrzej and Sylwester, Thanks for the patch! On Mon, Dec 10, 2012 at 02:43:39PM +0100, Andrzej Hajda wrote: From: Sylwester Nawrocki s.nawro...@samsung.com Add control for automatic focus area selection. This control determines the area of the frame that the camera uses for automatic focus. Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com Signed-off-by: Andrzej Hajda a.ha...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com --- Documentation/DocBook/media/v4l/compat.xml |9 +++-- Documentation/DocBook/media/v4l/controls.xml | 47 +- Documentation/DocBook/media/v4l/v4l2.xml |7 drivers/media/v4l2-core/v4l2-ctrls.c | 10 ++ include/uapi/linux/v4l2-controls.h |6 5 files changed, 76 insertions(+), 3 deletions(-) diff --git a/Documentation/DocBook/media/v4l/compat.xml b/Documentation/DocBook/media/v4l/compat.xml index 4fdf6b5..e8b53da 100644 --- a/Documentation/DocBook/media/v4l/compat.xml +++ b/Documentation/DocBook/media/v4l/compat.xml @@ -2452,8 +2452,9 @@ that used it. It was originally scheduled for removal in 2.6.35. constantV4L2_CID_3A_LOCK/constant, constantV4L2_CID_AUTO_FOCUS_START/constant, constantV4L2_CID_AUTO_FOCUS_STOP/constant, - constantV4L2_CID_AUTO_FOCUS_STATUS/constant and - constantV4L2_CID_AUTO_FOCUS_RANGE/constant. + constantV4L2_CID_AUTO_FOCUS_STATUS/constant, + constantV4L2_CID_AUTO_FOCUS_RANGE/constant and + constantV4L2_CID_AUTO_FOCUS_AREA/constant. /para /listitem /orderedlist @@ -2586,6 +2587,10 @@ ioctls./para paraVendor and device specific media bus pixel formats. xref linkend=v4l2-mbus-vendor-spec-fmts /./para /listitem +listitem + paralink linkend=v4l2-auto-focus-areaconstant + V4L2_CID_AUTO_FOCUS_AREA/constant/link control./para +/listitem /itemizedlist /section diff --git a/Documentation/DocBook/media/v4l/controls.xml b/Documentation/DocBook/media/v4l/controls.xml index 7fe5be1..9d4af8a 100644 --- a/Documentation/DocBook/media/v4l/controls.xml +++ b/Documentation/DocBook/media/v4l/controls.xml @@ -3347,6 +3347,51 @@ use its minimum possible distance for auto focus./entry /row rowentry/entry/row + row id=v4l2-auto-focus-area + entry spanname=id + constantV4L2_CID_AUTO_FOCUS_AREA/constantnbsp;/entry + entryenumnbsp;v4l2_auto_focus_area/entry + /row + rowentry spanname=descrDetermines the area of the frame that +the camera uses for automatic focus. The corresponding coordinates of the +focusing spot or rectangle can be specified and queried using the selection API. +To change the auto focus region of interest applications first select required +mode of this control and then set the rectangle or spot coordinates by means +of the VIDIOC-SUBDEV-S-SELECTION; or VIDIOC-S-SELECTION; ioctl. In order to +trigger again a one shot auto focus with same coordinates applications should +use the constantV4L2_CID_AUTO_FOCUS_START /constant control. Or alternatively Extra space above.^ +invoke a VIDIOC-SUBDEV-S-SELECTION; or a VIDIOC-S-SELECTION; ioctl again. How about requiring explicit V4L2_CID_AUTO_FOCUS_START? If you need to specify several AF selection windows, then on which one do you start the algorithm? A bitmask control explicitly telling which ones are active would also be needed --- but that's for the future. I think now we just need to ascertain we don't make that difficult. :-) Do you mean only V4L2_CID_AUTO_FOCUS_START should start AF? What about continuous auto-focus (CAF)? In case of the sensor I am working on, face detection can work in both AF and CAF. Continuous AF needs to be an exception to that. It's controlled by V4L2_CID_FOCUS_AUTO, which interestingly doesn't even mention continuous AF. Should CAF be restarted (ie stopped and started again), to use face detection? I wonder if V4L2_CID_AUTO_FOCUS_START should be defined to restart CAF when V4L2_CID_FOCUS_AUTO is enabled. I don't think we currently have a way to do that; the current definition says that using V4L2_CID_AUTO_FOCUS_START is undefined then. What do you think? +In the latter case the new pixel coordinates are applied to hardware only when +the focus area control was set to +constantV4L2_AUTO_FOCUS_AREA_RECTANGLE/constant./entry + /row + row + entrytbl spanname=descr cols=2 + tbody valign=top + row + entryconstantV4L2_AUTO_FOCUS_AREA_ALL/constantnbsp;/entry + entryNormal auto focus, the focusing area extends over the +entire frame./entry Does this need to be explicitly specified? Shouldn't the user just choose
Re: [PATCH V3 01/15] [media] marvell-ccic: use internal variable replace global frame stats variable
On Sat, 15 Dec 2012 17:57:50 +0800 Albert Wang twan...@marvell.com wrote: This patch replaces the global frame stats variables by using internal variables in mcam_camera structure. This one seems fine. Someday it might be nice to have proper stats rather than my debugging hack, complete with a nice sysfs interface and all that. Acked-by: Jonathan Corbet cor...@lwn.net jon -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 02/15] [media] marvell-ccic: add MIPI support for marvell-ccic driver
On Sat, 15 Dec 2012 17:57:51 +0800
Albert Wang twan...@marvell.com wrote:
From: Libin Yang lby...@marvell.com
This patch adds the MIPI support for marvell-ccic.
Board driver should determine whether using MIPI or not.
There are limits to how deeply I can review this, since I know little about
the MIPI mode and don't have any hardware that uses it. So I'm assuming
that it all works :) My comments are on a different level.
+static int mcam_config_mipi(struct mcam_camera *mcam, int enable)
+{
+ if (mcam-bus_type == V4L2_MBUS_CSI2 enable) {
+ /* Using MIPI mode and enable MIPI */
+ cam_dbg(mcam, camera: DPHY3=0x%x, DPHY5=0x%x, DPHY6=0x%x\n,
+ mcam-dphy[0], mcam-dphy[1], mcam-dphy[2]);
+ mcam_reg_write(mcam, REG_CSI2_DPHY3, mcam-dphy[0]);
+ mcam_reg_write(mcam, REG_CSI2_DPHY6, mcam-dphy[2]);
+ mcam_reg_write(mcam, REG_CSI2_DPHY5, mcam-dphy[1]);
Is there a reason you're writing them in something other than direct
increasing order? If so, a comment saying why might help somebody in ghe
future.
+ if (mcam-mipi_enabled == 0) {
+ /*
+ * 0x41 actives 1 lane
+ * 0x43 actives 2 lanes
+ * 0x47 actives 4 lanes
+ * There is no 3 lanes case
+ */
+ switch (mcam-lane) {
+ case 1:
+ mcam_reg_write(mcam, REG_CSI2_CTRL0, 0x41);
+ break;
+ case 2:
+ mcam_reg_write(mcam, REG_CSI2_CTRL0, 0x43);
+ break;
+ case 4:
+ mcam_reg_write(mcam, REG_CSI2_CTRL0, 0x47);
+ break;
Can we have defined symbols rather than magic constants here?
@@ -656,6 +701,15 @@ static void mcam_ctlr_image(struct mcam_camera *cam)
*/
mcam_reg_write_mask(cam, REG_CTRL0, C0_SIF_HVSYNC,
C0_SIFM_MASK);
+
+ /*
+ * This field controls the generation of EOF(DVP only)
+ */
+ if (cam-bus_type != V4L2_MBUS_CSI2) {
+ mcam_reg_set_bit(cam, REG_CTRL0,
+ C0_EOF_VSYNC | C0_VEDGE_CTRL);
+ mcam_reg_write(cam, REG_CTRL3, 0x4);
Again, how about a symbol, or at least an explanation of what 0x4 means?
+ }
}
[...]
@@ -1551,6 +1615,11 @@ static int mcam_v4l_open(struct file *filp)
mcam_set_config_needed(cam, 1);
}
(cam-users)++;
+ cam-pll1 = devm_clk_get(cam-dev, pll1);
+ if (IS_ERR(cam-pll1)) {
+ cam_err(cam, Could not get pll1 clock\n);
+ ret = PTR_ERR(cam-pll1);
+ }
This looks like it gets the clock in all cases? Is that right?
#define REG_IMGPITCH 0x24/* Image pitch register */
@@ -292,7 +311,9 @@ int mccic_resume(struct mcam_camera *cam);
#defineC0_DOWNSCALE0x0800/* Enable downscaler */
#defineC0_SIFM_MASK0xc000/* SIF mode bits */
#defineC0_SIF_HVSYNC 0x/* Use H/VSYNC */
-#defineCO_SOF_NOSYNC 0x4000/* Use inband active signaling
*/
+#defineC0_SOF_NOSYNC 0x4000/* Use inband active signaling
*/
+#defineC0_EOF_VSYNC0x0040/* Generate EOF by VSYNC */
+#defineC0_VEDGE_CTRL 0x0080/* Detect falling edge of VSYNC
*/
Being the retentive sort of guy I am, I try to keep definitions like these
in numerical order. Any chance you could humor me and maintain that?
/* Bits below C1_444ALPHA are not present in Cafe */
#define REG_CTRL10x40/* Control 1 */
@@ -308,6 +329,7 @@ int mccic_resume(struct mcam_camera *cam);
#defineC1_TWOBUFS 0x0800/* Use only two DMA buffers */
#defineC1_PWRDWN 0x1000/* Power down */
+#define REG_CTRL30x1ec /* CCIC parallel mode */
#define REG_CLKCTRL 0x88/* Clock control */
#defineCLK_DIV_MASK0x/* Upper bits RW reserved */
Here, too, I'd rather keep them in order if possible.
+/*
+ * calc the dphy register values
+ * There are three dphy registers being used.
+ * dphy[0] can be set with a default value
+ * or be calculated dynamically
+ */
+void mmpcam_calc_dphy(struct mcam_camera *mcam)
+{
+ struct mmp_camera *cam = mcam_to_cam(mcam);
+ struct mmp_camera_platform_data *pdata = cam-pdev-dev.platform_data;
+ struct device *dev = cam-pdev-dev;
+ unsigned long tx_clk_esc;
+
+ /*
+ * If dphy[0] is calculated dynamically,
+ * pdata-lane_clk should be already set
+ * either in the board driver statically
+ * or in the sensor driver dynamically.
+ */
+ switch (pdata-dphy3_algo) {
+ case 1:
+ /*
+ * dphy3_algo == 1
Re: [PATCH V3 03/15] [media] marvell-ccic: add clock tree support for marvell-ccic driver
On Sat, 15 Dec 2012 17:57:52 +0800
Albert Wang twan...@marvell.com wrote:
From: Libin Yang lby...@marvell.com
This patch adds the clock tree support for marvell-ccic.
Each board may require different clk enabling sequence.
Developer need add the clk_name in correct sequence in board driver
to use this feature.
+static void mcam_clk_set(struct mcam_camera *mcam, int on)
+{
+ unsigned int i;
+
+ if (on) {
+ for (i = 0; i mcam-clk_num; i++) {
+ if (mcam-clk[i])
+ clk_enable(mcam-clk[i]);
+ }
+ } else {
+ for (i = mcam-clk_num; i 0; i--) {
+ if (mcam-clk[i - 1])
+ clk_disable(mcam-clk[i - 1]);
+ }
+ }
+}
A couple of minor comments:
- This function is always called with a constant value for on. It would
be easier to read (and less prone to unfortunate brace errors) if it
were just two functions: mcam_clk_enable() and mcam_clk_disable().
- I'd write the second for loop as:
for (i = mcal-clk_num - 1; i = 0; i==) {
just to match the values used in the other direction and avoid the
subscript arithmetic.
+static void mcam_init_clk(struct mcam_camera *mcam,
+ struct mmp_camera_platform_data *pdata, int init)
So why does an init function have an init parameter? Again, I think
this would be far better split into two functions. Among other things,
that would help to reduce the deep nesting below.
+{
+ unsigned int i;
+
+ if (NR_MCAM_CLK pdata-clk_num) {
+ dev_err(mcam-dev, Too many mcam clocks defined\n);
+ mcam-clk_num = 0;
+ return;
+ }
+
+ if (init) {
+ for (i = 0; i pdata-clk_num; i++) {
+ if (pdata-clk_name[i] != NULL) {
+ mcam-clk[i] = devm_clk_get(mcam-dev,
+ pdata-clk_name[i]);
+ if (IS_ERR(mcam-clk[i])) {
+ dev_err(mcam-dev,
+ Could not get clk: %s\n,
+ pdata-clk_name[i]);
+ mcam-clk_num = 0;
+ return;
+ }
+ }
+ }
+ mcam-clk_num = pdata-clk_num;
+ } else
+ mcam-clk_num = 0;
+}
Again, minor comments, but I do think the code would be improved by
splitting those functions. Meanwhile:
Acked-by: Jonathan Corbet cor...@lwn.net
jon
--
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
dma_mmap_coherent / ARCH_HAS_DMA_MMAP_COHERENT
drivers/media/v4l2-core/videobuf2-dma-contig.c: In function ‘vb2_dc_mmap’:
drivers/media/v4l2-core/videobuf2-dma-contig.c:204: error: implicit
declaration of function ‘dma_mmap_coherent’
drivers/media/v4l2-core/videobuf2-dma-contig.c: In function
‘vb2_dc_get_base_sgt’:
drivers/media/v4l2-core/videobuf2-dma-contig.c:387: error: implicit
declaration of function ‘dma_get_sgtable’
make[6]: *** [drivers/media/v4l2-core/videobuf2-dma-contig.o] Error 1
make[6]: Target `__build' not remade because of errors.
make[5]: *** [drivers/media/v4l2-core] Error 2
Both dma_mmap_coherent() and dma_get_sgtable() are defined in
include/asm-generic/dma-mapping-common.h only, which is included by
asm/dma-mapping.h on alpha, arm, arm64, hexagon, ia64, microblaze, mips,
openrisc, powerpc, s390, sh, sparc, tile, unicore32, x86.
Should the remaining architectures include this, too?
Should it be moved to linux/dma-mapping.h?
Furthermore, there's ARCH_HAS_DMA_MMAP_COHERENT, which is defined
by powerpc only:
arch/powerpc/include/asm/dma-mapping.h:#define ARCH_HAS_DMA_MMAP_COHERENT
and handled in some fishy way in sound/core/pcm_native.c:
#ifndef ARCH_HAS_DMA_MMAP_COHERENT
/* This should be defined / handled globally! */
#ifdef CONFIG_ARM
#define ARCH_HAS_DMA_MMAP_COHERENT
#endif
#endif
/*
* mmap the DMA buffer on RAM
*/
int snd_pcm_lib_default_mmap(struct snd_pcm_substream *substream,
struct vm_area_struct *area)
{
area-vm_flags |= VM_DONTEXPAND | VM_DONTDUMP;
#ifdef ARCH_HAS_DMA_MMAP_COHERENT
if (!substream-ops-page
substream-dma_buffer.dev.type == SNDRV_DMA_TYPE_DEV)
return dma_mmap_coherent(substream-dma_buffer.dev.dev,
area,
substream-runtime-dma_area,
substream-runtime-dma_addr,
area-vm_end - area-vm_start);
#elif defined(CONFIG_MIPS) defined(CONFIG_DMA_NONCOHERENT)
if (substream-dma_buffer.dev.type == SNDRV_DMA_TYPE_DEV
!plat_device_is_coherent(substream-dma_buffer.dev.dev))
area-vm_page_prot = pgprot_noncached(area-vm_page_prot);
#endif /* ARCH_HAS_DMA_MMAP_COHERENT */
/* mmap with fault handler */
area-vm_ops = snd_pcm_vm_ops_data_fault;
return 0;
}
EXPORT_SYMBOL_GPL(snd_pcm_lib_default_mmap);
What's up here?
Thx!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 04/15] [media] marvell-ccic: reset ccic phy when stop streaming for stability
On Sat, 15 Dec 2012 17:57:53 +0800 Albert Wang twan...@marvell.com wrote: From: Libin Yang lby...@marvell.com This patch adds the reset ccic phy operation when stop streaming. Without reset ccic phy, the next start streaming may be unstable. Also need add CCIC2 definition when PXA688/PXA2128 support dual ccics. As with all of these, I've not been able to test it, but it looks OK to me. Acked-by: Jonathan Corbet cor...@lwn.net jon -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 05/15] [media] marvell-ccic: refine mcam_set_contig_buffer function
On Sat, 15 Dec 2012 17:57:54 +0800 Albert Wang twan...@marvell.com wrote: From: Libin Yang lby...@marvell.com This patch refines mcam_set_contig_buffer() in mcam core It might be nice if the changelog said *why* this was being done - don't worry about insulting my ugly code :) But no biggie... Acked-by: Jonathan Corbet cor...@lwn.net jon -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 06/15] [media] marvell-ccic: add new formats support for marvell-ccic driver
On Sat, 15 Dec 2012 17:57:55 +0800
Albert Wang twan...@marvell.com wrote:
From: Libin Yang lby...@marvell.com
This patch adds the new formats support for marvell-ccic.
Once again, just one second-order comment:
+static bool mcam_fmt_is_planar(__u32 pfmt)
+{
+ switch (pfmt) {
+ case V4L2_PIX_FMT_YUV422P:
+ case V4L2_PIX_FMT_YUV420:
+ case V4L2_PIX_FMT_YVU420:
+ return true;
+ }
+ return false;
+}
This seems like the kind of thing that would be useful in a number of
places; I'd be tempted to push it up a level and make it available to all
V4L2 drivers. Of course, that means making it work for *all* formats,
which would be a pain.
But, then, I can see some potential future pain if somebody adds a new
format and forgets to tweak this function here. Rather than adding a new
switch, could you put a planar flag into struct mcam_format_struct
instead? That would help to keep all this information together.
jon
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 07/15] [media] marvell-ccic: add SOF / EOF pair check for marvell-ccic driver
On Sat, 15 Dec 2012 17:57:56 +0800 Albert Wang twan...@marvell.com wrote: From: Libin Yang lby...@marvell.com This patch adds the SOFx/EOFx pair check for marvell-ccic. When switching format, the last EOF may not arrive when stop streamning. And the EOF will be detected in the next start streaming. Must ensure clear the obsolete frame flags before every really start streaming. obsolete doesn't quite read right; it suggests that the flags only apply to older hardware. I'd suggest left over or some such (in the code comment too). Otherwise seems fine. Acked-by: Jonathan Corbet cor...@lwn.net jon -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 08/15] [media] marvell-ccic: switch to resource managed allocation and request
On Sat, 15 Dec 2012 17:57:57 +0800 Albert Wang twan...@marvell.com wrote: From: Libin Yang lby...@marvell.com This patch switchs to resource managed allocation and request in mmp-driver. It can remove free resource operations. But that takes away half the challenge of getting all this stuff right! :) Acked-by: Jonathan Corbet cor...@lwn.net jon -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 09/15] [media] marvell-ccic: add get_mcam function for marvell-ccic driver
On Sat, 15 Dec 2012 17:57:58 +0800
Albert Wang twan...@marvell.com wrote:
This patch adds get_mcam() inline function which is prepared for
adding soc_camera support in marvell-ccic driver
Time for a bikeshed moment: get generally is understood to mean
incrementing a reference count in kernel code. Can it have a name like
vbq_to_mcam() instead?
Also:
@@ -1073,14 +1073,17 @@ static int mcam_vb_queue_setup(struct vb2_queue *vq,
static void mcam_vb_buf_queue(struct vb2_buffer *vb)
{
struct mcam_vb_buffer *mvb = vb_to_mvb(vb);
- struct mcam_camera *cam = vb2_get_drv_priv(vb-vb2_queue);
+ struct mcam_camera *cam = get_mcam(vb-vb2_queue);
struct v4l2_pix_format *fmt = cam-pix_format;
unsigned long flags;
int start;
dma_addr_t dma_handle;
+ unsigned long size;
u32 pixel_count = fmt-width * fmt-height;
spin_lock_irqsave(cam-dev_lock, flags);
+ size = vb2_plane_size(vb, 0);
+ vb2_set_plane_payload(vb, 0, size);
dma_handle = vb2_dma_contig_plane_dma_addr(vb, 0);
BUG_ON(!dma_handle);
start = (cam-state == S_BUFWAIT) !list_empty(cam-buffers);
There is an unrelated change here that belongs in a separate patch.
@@ -1138,9 +1141,12 @@ static void mcam_vb_wait_finish(struct vb2_queue *vq)
*/
static int mcam_vb_start_streaming(struct vb2_queue *vq, unsigned int count)
{
- struct mcam_camera *cam = vb2_get_drv_priv(vq);
+ struct mcam_camera *cam = get_mcam(vq);
unsigned int frame;
+ if (count 2)
+ return -EINVAL;
+
Here too - unrelated change.
if (cam-state != S_IDLE) {
INIT_LIST_HEAD(cam-buffers);
return -EINVAL;
@@ -1170,7 +1176,7 @@ static int mcam_vb_start_streaming(struct vb2_queue
*vq, unsigned int count)
static int mcam_vb_stop_streaming(struct vb2_queue *vq)
{
- struct mcam_camera *cam = vb2_get_drv_priv(vq);
+ struct mcam_camera *cam = get_mcam(vq);
unsigned long flags;
if (cam-state == S_BUFWAIT) {
@@ -1181,6 +1187,7 @@ static int mcam_vb_stop_streaming(struct vb2_queue *vq)
if (cam-state != S_STREAMING)
return -EINVAL;
mcam_ctlr_stop_dma(cam);
+ cam-state = S_IDLE;
...and also here ...
jon
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 10/15] [media] marvell-ccic: split mcam-core into 2 parts for soc_camera support
On Sat, 15 Dec 2012 17:57:59 +0800 Albert Wang twan...@marvell.com wrote: This patch splits mcam-core into 2 parts to prepare for soc_camera support. The first part remains in mcam-core.c. This part includes the HW operations and vb2 callback functions. The second part is moved to mcam-core-standard.c. This part is relevant with the implementation of using V4L2. OK, I'll confess I'm still not 100% sold on this part. Can I repeat the questions I raised before? - Is the soc_camera mode necessary? Is there something you're trying to do that can't be done without it? Or, at least, does it add sufficient benefit to be worth this work? It would be nice if the reasoning behind this change were put into the changelog. - If the soc_camera change is deemed to be worthwhile, is there anything preventing you from doing it 100% so it's the only mode used? The split as you've done it here is an improvement over what came before, but it still results in a lot of duplicated code; it also adds a *lot* of symbols to the global namespace. If this is really the only way then we'll find a way to make it work, but I'd like to be sure that we can't do something better. Thanks, jon -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 12/15] [media] marvell-ccic: add soc_camera support in mmp driver
On Sat, 15 Dec 2012 17:58:01 +0800
Albert Wang twan...@marvell.com wrote:
This patch adds the soc_camera support in the platform driver: mmp-driver.c.
Specified board driver also should be modified to support soc_camera by
passing
some platform datas to platform driver.
Currently the soc_camera mode in mmp driver only supports B_DMA_contig mode.
You do intend to add the other modes (or SG, at least) in the future?
--- a/drivers/media/platform/marvell-ccic/Kconfig
+++ b/drivers/media/platform/marvell-ccic/Kconfig
@@ -1,23 +1,45 @@
+config VIDEO_MARVELL_CCIC
+ tristate
+config VIDEO_MRVL_SOC_CAMERA
+ bool
If Linus sees this you'll get an unpleasant reminder that vowels are not
actually in short supply; I'd suggest spelling out MARVELL.
diff --git a/drivers/media/platform/marvell-ccic/mmp-driver.c
b/drivers/media/platform/marvell-ccic/mmp-driver.c
index 40c243e..cd850f4 100755
--- a/drivers/media/platform/marvell-ccic/mmp-driver.c
+++ b/drivers/media/platform/marvell-ccic/mmp-driver.c
@@ -28,6 +28,10 @@
#include linux/list.h
#include linux/pm.h
#include linux/clk.h
+#include linux/regulator/consumer.h
+#include media/videobuf2-dma-contig.h
+#include media/soc_camera.h
+#include media/soc_mediabus.h
#include mcam-core.h
@@ -40,6 +44,8 @@ struct mmp_camera {
struct platform_device *pdev;
struct mcam_camera mcam;
struct list_head devlist;
+ /* will change here */
+ struct clk *clk[3]; /* CCIC_GATE, CCIC_RST, CCIC_DBG clocks */
What does that comment mean?
int irq;
};
@@ -144,15 +150,17 @@ static void mmpcam_power_up(struct mcam_camera *mcam)
* Provide power to the sensor.
*/
mcam_reg_write(mcam, REG_CLKCTRL, 0x6002);
- pdata = cam-pdev-dev.platform_data;
- gpio_set_value(pdata-sensor_power_gpio, 1);
- mdelay(5);
+ if (mcam-chip_id == V4L2_IDENT_ARMADA610) {
I'm seeing a lot of these tests being added to the code. I can imagine
more in the future as new chipsets are supported in the driver. Maybe it's
time to add a structure to hide chipset-specific low-level operations? It
would make the code a lot cleaner.
Actually, things like mmpcam_power_up() were meant to be exactly that. Can
we just define a different version of this function for different chipsets?
+ pdata = cam-pdev-dev.platform_data;
+ gpio_set_value(pdata-sensor_power_gpio, 1);
+ mdelay(5);
+ /* reset is active low */
+ gpio_set_value(pdata-sensor_reset_gpio, 0);
+ mdelay(5);
+ gpio_set_value(pdata-sensor_reset_gpio, 1);
+ mdelay(5);
+ }
mcam_reg_clear_bit(mcam, REG_CTRL1, 0x1000);
- gpio_set_value(pdata-sensor_reset_gpio, 0); /* reset is active low */
- mdelay(5);
- gpio_set_value(pdata-sensor_reset_gpio, 1); /* reset is active low */
- mdelay(5);
-
mcam_clk_set(mcam, 1);
}
@@ -165,13 +173,14 @@ static void mmpcam_power_down(struct mcam_camera *mcam)
*/
iowrite32(0, cam-power_regs + REG_CCIC_DCGCR);
iowrite32(0, cam-power_regs + REG_CCIC_CRCR);
-/*
- * Shut down the sensor.
- */
- pdata = cam-pdev-dev.platform_data;
- gpio_set_value(pdata-sensor_power_gpio, 0);
- gpio_set_value(pdata-sensor_reset_gpio, 0);
-
+ if (mcam-chip_id == V4L2_IDENT_ARMADA610) {
Same comment applies here.
+ /*
+ * Shut down the sensor.
+ */
+ pdata = cam-pdev-dev.platform_data;
+ gpio_set_value(pdata-sensor_power_gpio, 0);
+ gpio_set_value(pdata-sensor_reset_gpio, 0);
+ }
mcam_clk_set(mcam, 0);
jon
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 13/15] [media] marvell-ccic: add dma burst mode support in marvell-ccic driver
On Sat, 15 Dec 2012 17:58:02 +0800
Albert Wang twan...@marvell.com wrote:
This patch adds the dma burst size config support for marvell-ccic.
Developer can set the dma burst size in specified board driver.
diff --git a/drivers/media/platform/marvell-ccic/mcam-core.h
b/drivers/media/platform/marvell-ccic/mcam-core.h
index 57442e0..e1025f2 100755
--- a/drivers/media/platform/marvell-ccic/mcam-core.h
+++ b/drivers/media/platform/marvell-ccic/mcam-core.h
@@ -126,6 +126,7 @@ struct mcam_camera {
short int use_smbus;/* SMBUS or straight I2c? */
enum mcam_buffer_mode buffer_mode;
+ int burst;
That's a register flag value, seems it should be unsigned (says the guy who
is admittedly sloppy about such things).
int mclk_min;
int mclk_src;
int mclk_div;
@@ -411,9 +412,9 @@ int mcam_soc_camera_host_register(struct mcam_camera
*mcam);
#define C1_DESC_3WORD 0x0200 /* Three-word descriptors used */
#defineC1_444ALPHA 0x00f0/* Alpha field in RGB444 */
#defineC1_ALPHA_SHFT 20
-#defineC1_DMAB32 0x/* 32-byte DMA burst */
-#defineC1_DMAB16 0x0200/* 16-byte DMA burst */
-#defineC1_DMAB64 0x0400/* 64-byte DMA burst */
+#defineC1_DMAB64 0x/* 64-byte DMA burst */
+#defineC1_DMAB128 0x0200/* 128-byte DMA burst */
+#defineC1_DMAB256 0x0400/* 256-byte DMA burst */
Interesting, did I just get those wrong somehow? Or might they have been
different in the Cafe days?
Acked-by: Jonathan Corbet cor...@lwn.net
jon
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 14/15] [media] marvell-ccic: use unsigned int type replace int type
On Sat, 15 Dec 2012 17:58:03 +0800 Albert Wang twan...@marvell.com wrote: This patch use unsigned int type replace int type in marvell-ccic. These variables: frame number, buf number, irq... should be unsigned. Acked-by: Jonathan Corbet cor...@lwn.net jon -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 15/15] [media] marvell-ccic: add 3 frame buffers support in DMA_CONTIG mode
On Sat, 15 Dec 2012 17:58:04 +0800
Albert Wang twan...@marvell.com wrote:
This patch adds support of 3 frame buffers in DMA-contiguous mode.
In current DMA_CONTIG mode, only 2 frame buffers can be supported.
Actually, Marvell CCIC can support at most 3 frame buffers.
Currently 2 frame buffers mode will be used by default.
To use 3 frame buffers mode, can do:
define MAX_FRAME_BUFS 3
in mcam-core.h
Now that the code supports three buffers properly, is there any reason not
to use that mode by default?
Did you test that it works properly if allocation of the third buffer fails?
Otherwise looks OK except for one thing:
diff --git a/drivers/media/platform/marvell-ccic/mcam-core.h
b/drivers/media/platform/marvell-ccic/mcam-core.h
index 765d47c..9bf31c8 100755
--- a/drivers/media/platform/marvell-ccic/mcam-core.h
+++ b/drivers/media/platform/marvell-ccic/mcam-core.h
@@ -62,6 +62,13 @@ enum mcam_state {
#define MAX_DMA_BUFS 3
/*
+ * CCIC can support at most 3 frame buffers in DMA_CONTIG buffer mode
+ * 2 - Use Two Buffers mode
+ * 3 - Use Three Buffers mode
+ */
+#define MAX_FRAME_BUFS 2 /* Current marvell-ccic used Two Buffers mode */
+
+/*
* Different platforms work best with different buffer modes, so we
* let the platform pick.
*/
@@ -99,6 +106,10 @@ struct mcam_frame_state {
unsigned int frames;
unsigned int singles;
unsigned int delivered;
+ /*
+ * Only usebufs == 2 can enter single buffer mode
+ */
+ unsigned int usebufs;
};
What is the purpose of the usebufs field? The code maintains it in
various places, but I don't see anywhere that actually uses that value for
anything.
Thanks,
jon
--
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: [Linaro-mm-sig] [PATCH] dma-buf: Add debugfs support
Hi,
On 12/14/2012 10:36 AM, sumit.sem...@ti.com wrote:
From: Sumit Semwal sumit.sem...@linaro.org
Add debugfs support to make it easier to print debug information
about the dma-buf buffers.
Signed-off-by: Sumit Semwal sumit.sem...@ti.com
---
drivers/base/dma-buf.c | 149
+++
include/linux/dma-buf.h |6 +-
2 files changed, 154 insertions(+), 1 deletion(-)
[...]
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index bd2e52c..160453f 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -112,6 +112,7 @@ struct dma_buf_ops {
* @file: file pointer used for sharing buffers across, and for refcounting.
* @attachments: list of dma_buf_attachment that denotes all devices
attached.
* @ops: dma_buf_ops associated with this buffer object.
+ * @list_node: node for dma_buf accounting and debugging.
* @priv: exporter specific private data for this buffer object.
*/
struct dma_buf {
@@ -121,6 +122,8 @@ struct dma_buf {
const struct dma_buf_ops *ops;
/* mutex to serialize list manipulation and attach/detach */
struct mutex lock;
+
+ struct list_head list_node;
void *priv;
};
@@ -183,5 +186,6 @@ int dma_buf_mmap(struct dma_buf *, struct vm_area_struct
*,
unsigned long);
void *dma_buf_vmap(struct dma_buf *);
void dma_buf_vunmap(struct dma_buf *, void *vaddr);
-
+int dma_buf_debugfs_create_file(const char *name,
+ int (*write)(struct seq_file *));
Why is this function declared in the public header file?
--
Francesco
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 00/15] [media] marvell-ccic: add soc camera support on marvell-ccic
On Sat, 15 Dec 2012 17:57:49 +0800 Albert Wang twan...@marvell.com wrote: The following patches series will add soc_camera support on marvell-ccic Overall, this patch set has come a long way - great work! As I commented on the specific patches, I still have some concerns about the soc_camera part of it. There's various quibbles with the rest, but mostly not much that's serious. I think this work is getting close to being ready. Thanks, jon Jonathan Corbet / LWN.net / cor...@lwn.net -- 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: cannot make this Asus my cinema-u3100miniplusv2 work under linux
now the modules loads and kaffeine recognizes the device but i cannot find any channels. can it be a tuner bug ? kaffeine(5978) DvbDevice::frontendEvent: tuning failed kaffeine(5978) DvbScanFilter::timerEvent: timeout while reading section; type = 0 pid = 0 kaffeine(5978) DvbScanFilter::timerEvent: timeout while reading section; type = 2 pid = 17 kaffeine(5978) DvbScanFilter::timerEvent: timeout while reading section; type = 4 pid = 16 kaffeine(5978) DvbDevice::frontendEvent: tuning failed kaffeine(5978) DvbScanFilter::timerEvent: timeout while reading section; type = 0 pid = 0 kaffeine(5978) DvbScanFilter::timerEvent: timeout while reading section; type = 2 pid = 17 kaffeine(5978) DvbScanFilter::timerEvent: timeout while reading section; type = 4 pid = 16 kaffeine(5978) DvbDevice::frontendEvent: tuning failed Il 16/12/2012 15:50 Antti Palosaari ha scritto: On 12/16/2012 04:23 PM, Renato Gallo wrote: any news on this ? Asus my cinema-u3100miniplusv2 Bus 001 Device 015: ID 1b80:d3a8 Afatech [ 6956.333440] usb 1-6.3.6: new high-speed USB device number 16 using ehci_hcd [ 6956.453943] usb 1-6.3.6: New USB device found, idVendor=1b80, idProduct=d3a8 [ 6956.453950] usb 1-6.3.6: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 6956.453955] usb 1-6.3.6: Product: Rtl2832UDVB [ 6956.453959] usb 1-6.3.6: Manufacturer: Realtek Seems to be Realtek RTL2832U. Add that USB ID to the driver and test. It is very high probability it starts working. Here is the patch: http://git.linuxtv.org/anttip/media_tree.git/shortlog/refs/heads/rtl28xxu-usb-ids Please test and report. regards Antti -- 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: cannot make this Asus my cinema-u3100miniplusv2 work under linux
On 12/16/2012 07:15 PM, Renato Gallo wrote: now the modules loads and kaffeine recognizes the device but i cannot find any channels. can it be a tuner bug ? I think it is bad antenna / weak signal. Try w_scan, scan, tzap. Could you say which RF-tuner it finds from your device? use dmesg to dump output. It could be for example e4000, FC0012, FC0013, FC2580, TUA9001 etc. Antti kaffeine(5978) DvbDevice::frontendEvent: tuning failed kaffeine(5978) DvbScanFilter::timerEvent: timeout while reading section; type = 0 pid = 0 kaffeine(5978) DvbScanFilter::timerEvent: timeout while reading section; type = 2 pid = 17 kaffeine(5978) DvbScanFilter::timerEvent: timeout while reading section; type = 4 pid = 16 kaffeine(5978) DvbDevice::frontendEvent: tuning failed kaffeine(5978) DvbScanFilter::timerEvent: timeout while reading section; type = 0 pid = 0 kaffeine(5978) DvbScanFilter::timerEvent: timeout while reading section; type = 2 pid = 17 kaffeine(5978) DvbScanFilter::timerEvent: timeout while reading section; type = 4 pid = 16 kaffeine(5978) DvbDevice::frontendEvent: tuning failed Il 16/12/2012 15:50 Antti Palosaari ha scritto: On 12/16/2012 04:23 PM, Renato Gallo wrote: any news on this ? Asus my cinema-u3100miniplusv2 Bus 001 Device 015: ID 1b80:d3a8 Afatech [ 6956.333440] usb 1-6.3.6: new high-speed USB device number 16 using ehci_hcd [ 6956.453943] usb 1-6.3.6: New USB device found, idVendor=1b80, idProduct=d3a8 [ 6956.453950] usb 1-6.3.6: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 6956.453955] usb 1-6.3.6: Product: Rtl2832UDVB [ 6956.453959] usb 1-6.3.6: Manufacturer: Realtek Seems to be Realtek RTL2832U. Add that USB ID to the driver and test. It is very high probability it starts working. Here is the patch: http://git.linuxtv.org/anttip/media_tree.git/shortlog/refs/heads/rtl28xxu-usb-ids Please test and report. regards Antti -- 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 -- 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: em28xx: msi Digivox ATSC board id [0db0:8810]
Am 15.12.2012 17:51, schrieb Antti Palosaari:
On 12/15/2012 06:21 PM, Frank Schäfer wrote:
Am 15.12.2012 14:38, schrieb Antti Palosaari:
On 12/15/2012 03:11 PM, Frank Schäfer wrote:
Am 15.12.2012 02:54, schrieb Mauro Carvalho Chehab:
Em Sat, 15 Dec 2012 02:56:25 +0200
Antti Palosaari cr...@iki.fi escreveu:
On 12/15/2012 02:26 AM, Mauro Carvalho Chehab wrote:
Em Fri, 14 Dec 2012 17:39:50 -0200
Mauro Carvalho Chehab mche...@redhat.com escreveu:
Am 10.12.2012 17:00, schrieb Matthew Gyurgyik:
Here is the dmesg output:
[root@tux ~]# dmesg -t | sort | uniq | grep 'em28xx IR' | grep
handle
em28xx IR (em28xx #0)/ir: 6em28xx_ir_handle_key: toggle: 0,
count: 1,
key 0x61d6
em28xx IR (em28xx #0)/ir: 6em28xx_ir_handle_key: toggle: 0,
count: 2,
key 0x61d6
em28xx IR (em28xx #0)/ir: 6em28xx_ir_handle_key: toggle: 1,
count: 1,
key 0x61d6
em28xx IR (em28xx #0)/ir: em28xx_ir_handle_key: toggle: 0,
count: 1,
key 0x61d6
em28xx IR (em28xx #0)/ir: em28xx_ir_handle_key: toggle: 0,
count: 2,
key 0x61d6
em28xx IR (em28xx #0)/ir: em28xx_ir_handle_key: toggle: 1,
count: 1,
key 0x61d6
em28xx IR (em28xx #0)/ir: em28xx_ir_handle_key: toggle: 1,
count: 2,
key 0x61d6
I pressed all the buttons on the remote (40 buttons).
Did you cut the dmesg output ? Or do you really get these
messages for
key 0x61d6 only ?
Correct, I only got the messages for key 0x61d6 regardless of which
physical button I press.
So if Matthew didn't make any mistakes, the problem seems to be the
read
count handling...
That is what happened and it is correct behavior as Matthews remote is
24 bit NEC (and driver does not know how to handle it). If you look
again those raw dumps which I send previous mail you could see the
issue. 61d6 seen here is remote controller address, two first bits. It
outputs that because debug does not output rest 2 remaining bytes
where is actual key code. If you set em28xx to 32bit NEC mode then key
code for that remote set 61d6 by driver mistakenly as it does not know
there is 2 bytes more to handle.
Antti, the problem with Matthews RC isn't the number of bytes printed to
the log.
The problems is, that NO messages appear in the log (with one
exception).
What is that exception?
In that case there should be around 40 similar debug lines - as
address byte is same for all buttons and debug prints only address
byte, toggle and count.
That's what I mean. He said he didn't cut dmesg.
As toggle and count still outputs some numbers we will see that many
line. Without toggle and count there is likely only one debug line
seen as output is piped through uniq which drops similar lines.
I copy pasted here relevant lines from the em28xx driver. Maybe you
could now see why code is wrong - why the extended address byte is set
as to scancode mistakenly. Look especially care following variables:
msg[1], msg[2], poll_result-rc_address and poll_result.rc_data[0]
static int em2874_polling_getkey()
{
rc = dev-em28xx_read_reg_req_len(dev, 0, EM2874_R51_IR, msg,
sizeof(msg));
/* Remote Control Address (Reg 0x52) */
poll_result-rc_address = msg[1];
/* Remote Control Data (Reg 0x53-55) */
poll_result-rc_data[0] = msg[2];
poll_result-rc_data[1] = msg[3];
poll_result-rc_data[2] = msg[4];
}
You missed the relevant part of the code:
static int em2874_polling_getkey()
{
...
/* Infrared read count (Reg 0x51[6:0] */
poll_result-read_count = (msg[0] 0x7f);
...
}
static void em28xx_ir_handle_key()
{
dprintk(%s: toggle: %d, count: %d, key 0x%02x%02x\n, __func__,
poll_result.toggle_bit, poll_result.read_count,
poll_result.rc_address, poll_result.rc_data[0]);
}
Same here, you missed the if () statement:
static void em28xx_ir_handle_key(struct em28xx_IR *ir)
{
...
if (unlikely(poll_result.read_count != ir-last_readcount)) {
dprintk(%s: toggle: %d, count: %d, key 0x%02x%02x\n,
__func__,
poll_result.toggle_bit, poll_result.read_count,
poll_result.rc_address, poll_result.rc_data[0]);
...
}
It doesn't matter which format the scancode (4 bytes) has, a message
should be printed in any case.
But according to Matthew, that doesn't happen. Hence, the
poll_result.read_count != ir-last_readcount must be the problem.
I don't see which messages are missing.
I think read_count is not incremented in case NEC 16bit checksum fails
- hw just discards whole code = read_count not increase = no debug.
For my tests there was always 81/01 when key was pressed and 00 when
no key pressed (as seen also logs I posted yesterday).
I don't know, I don't have the data sheet, I don't have the hardware and
I didn't make the test myself.
If you are sure you can declare it working, fine.
Care to fix the tuner issues ?
Regards,
Frank
I am about 99% sure Mauro's patch works correctly for Matthews device.
If Matthew didn't make any mistakes, I can't see how these patches can
make it work. Which doesn't mean
Re: [PATCH 5/5] em28xx: fix+improve+unify i2c error handling, debug messages and code comments
Am 15.12.2012 18:16, schrieb Antti Palosaari:
On 12/15/2012 06:25 PM, Frank Schäfer wrote:
Am 15.12.2012 14:46, schrieb Antti Palosaari:
On 12/15/2012 03:01 PM, Frank Schäfer wrote:
Am 14.12.2012 18:03, schrieb Antti Palosaari:
On 12/14/2012 06:28 PM, Frank Schäfer wrote:
- check i2c slave address range (only 7 bit addresses supported)
- do not pass USB specific error codes to userspace/i2c-subsystem
- unify the returned error codes and make them compliant with
the i2c subsystem spec
- check number of actually transferred bytes (via USB) everywehere
- fix/improve debug messages
- improve code comments
Signed-off-by: Frank Schäfer fschaefer@googlemail.com
@@ -244,16 +294,20 @@ static int em28xx_i2c_xfer(struct i2c_adapter
*i2c_adap,
dprintk2(2, %s %s addr=%x len=%d:,
(msgs[i].flags I2C_M_RD) ? read : write,
i == num - 1 ? stop : nonstop, addr,
msgs[i].len);
+if (addr 0xff) {
+dprintk2(2, ERROR: 10 bit addresses not
supported\n);
+return -EOPNOTSUPP;
+}
There is own flag for 10bit I2C address. Use it (and likely not
compare at all addr validly like that). This kind of address
validation check is quite unnecessary - and after all if it is wanted
then correct place is somewhere in I2C routines.
Well, to be 100% sure and strict, we should check both, the flag
and the
actual address.
We support 7 bit addresses only, no matter which i2c algo is used. So
doing the address check in each i2c routine seems to be unnecessary
code
duplication to me ?
I will repeat me, I see it overkill to check address correctness. And
as I said, that one is general validly could be done easily in I2C
core - so why the hell you wish make it just only for em28xx ?
I am quite sure if that kind of address validness are saw important
they are already implemented by I2C core.
Make patch for I2C which does that address validation against client
10BIT flag and sent it to the mailing list for discussion.
The I2C core doesn't know about the capabilities of the adapter.
Hence it doesn't know if ten bit addresses will work (the same as with
the message size constraints).
All it does ist to check the client for I2C_CLIENT_TEN addr 0x7f
once, when it is instanciated with a call to i2c_new_device().
But we don't use this function in em28xx and the same applies to many
other drivers as well.
Apart from that, the client address and flags can change anytime later
(e.g. when probing devices).
yes, it does not need to know if adapter supports 10 bit or not, or
how many bytes adapter could send at once. It is up to adapter to
check those.
master_xfer() fcn _is_ the adpater.
You are confusing i2c adapter and client driver code here.
But it could check if client tries to send using invalid address
(client says it is 7BIT, but address is 10BIT), just situation you are
adding to em28xx adapter.
If you are worried flags and address could change during operation,
I2C core could check it too.
Feel free to send patches.
Every driver I have seen are using I2C routines to send messages, and
if there is check lets say eg. inside i2c_transfer() then it benefits
all the others than em28xx.
I agree.
That is NOT em28xx *only* issue, it is common for all of our drivers.
Sure.
As it is common, adding check for each driver sounds wrong. General
check should be done in general level, and hw specific issues are for
driver.
Although I wouldn't call it wrong, I agree.
Jean might shed some light on this.
Regards,
Frank
--
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/5] em28xx: i2c bug fixes and cleanups
This patch series contains some I2C bug fixes / cleanups / unifications and improvements for the em28xx driver, which I've made while working on adding support for the em25xx/em276x i2c bus B support and playing with the Terratec Cinergy 200 USB which I've got recently. Patches 1 and 5 are cleanup/unification patches, patches 2, 3, 4 fix some bugs. Patch 3 actually fixes 2 bugs, but separate commits didn't make sense, because more or less the whole function had to be rewritten. Changelog v2: - removed i2c address type/range check from patch 5 as requested by Antti Palosaari Frank Schäfer (5): em28xx: clean up the data type mess of the i2c transfer function parameters em28xx: respect the message size constraints for i2c transfers em28xx: fix two severe bugs in function em2800_i2c_recv_bytes() em28xx: fix the i2c adapter functionality flags em28xx: fix+improve+unify i2c error handling, debug messages and code comments drivers/media/usb/em28xx/em28xx-core.c |5 +- drivers/media/usb/em28xx/em28xx-i2c.c | 276 +++- drivers/media/usb/em28xx/em28xx.h |2 +- 3 Dateien geändert, 168 Zeilen hinzugefügt(+), 115 Zeilen entfernt(-) -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/5] em28xx: clean up the data type mess of the i2c transfer function parameters
Signed-off-by: Frank Schäfer fschaefer@googlemail.com
---
drivers/media/usb/em28xx/em28xx-i2c.c | 28 +++-
1 Datei geändert, 11 Zeilen hinzugefügt(+), 17 Zeilen entfernt(-)
diff --git a/drivers/media/usb/em28xx/em28xx-i2c.c
b/drivers/media/usb/em28xx/em28xx-i2c.c
index 1683bd9..44533e4 100644
--- a/drivers/media/usb/em28xx/em28xx-i2c.c
+++ b/drivers/media/usb/em28xx/em28xx-i2c.c
@@ -53,12 +53,11 @@ do {
\
* em2800_i2c_send_max4()
* send up to 4 bytes to the i2c device
*/
-static int em2800_i2c_send_max4(struct em28xx *dev, unsigned char addr,
- char *buf, int len)
+static int em2800_i2c_send_max4(struct em28xx *dev, u8 addr, u8 *buf, u16 len)
{
int ret;
int write_timeout;
- unsigned char b2[6];
+ u8 b2[6];
BUG_ON(len 1 || len 4);
b2[5] = 0x80 + len - 1;
b2[4] = addr;
@@ -89,15 +88,13 @@ static int em2800_i2c_send_max4(struct em28xx *dev,
unsigned char addr,
/*
* em2800_i2c_send_bytes()
*/
-static int em2800_i2c_send_bytes(void *data, unsigned char addr, char *buf,
-short len)
+static int em2800_i2c_send_bytes(struct em28xx *dev, u8 addr, u8 *buf, u16 len)
{
- char *bufPtr = buf;
+ u8 *bufPtr = buf;
int ret;
int wrcount = 0;
int count;
int maxLen = 4;
- struct em28xx *dev = (struct em28xx *)data;
while (len 0) {
count = (len maxLen) ? maxLen : len;
ret = em2800_i2c_send_max4(dev, addr, bufPtr, count);
@@ -115,9 +112,9 @@ static int em2800_i2c_send_bytes(void *data, unsigned char
addr, char *buf,
* em2800_i2c_check_for_device()
* check if there is a i2c_device at the supplied address
*/
-static int em2800_i2c_check_for_device(struct em28xx *dev, unsigned char addr)
+static int em2800_i2c_check_for_device(struct em28xx *dev, u8 addr)
{
- char msg;
+ u8 msg;
int ret;
int write_timeout;
msg = addr;
@@ -150,8 +147,7 @@ static int em2800_i2c_check_for_device(struct em28xx *dev,
unsigned char addr)
* em2800_i2c_recv_bytes()
* read from the i2c device
*/
-static int em2800_i2c_recv_bytes(struct em28xx *dev, unsigned char addr,
-char *buf, int len)
+static int em2800_i2c_recv_bytes(struct em28xx *dev, u8 addr, u8 *buf, u16 len)
{
int ret;
/* check for the device and set i2c read address */
@@ -174,11 +170,10 @@ static int em2800_i2c_recv_bytes(struct em28xx *dev,
unsigned char addr,
/*
* em28xx_i2c_send_bytes()
*/
-static int em28xx_i2c_send_bytes(void *data, unsigned char addr, char *buf,
-short len, int stop)
+static int em28xx_i2c_send_bytes(struct em28xx *dev, u16 addr, u8 *buf,
+u16 len, int stop)
{
int wrcount = 0;
- struct em28xx *dev = (struct em28xx *)data;
int write_timeout, ret;
wrcount = dev-em28xx_write_regs_req(dev, stop ? 2 : 3, addr, buf, len);
@@ -199,8 +194,7 @@ static int em28xx_i2c_send_bytes(void *data, unsigned char
addr, char *buf,
* em28xx_i2c_recv_bytes()
* read a byte from the i2c device
*/
-static int em28xx_i2c_recv_bytes(struct em28xx *dev, unsigned char addr,
-char *buf, int len)
+static int em28xx_i2c_recv_bytes(struct em28xx *dev, u16 addr, u8 *buf, u16
len)
{
int ret;
ret = dev-em28xx_read_reg_req_len(dev, 2, addr, buf, len);
@@ -217,7 +211,7 @@ static int em28xx_i2c_recv_bytes(struct em28xx *dev,
unsigned char addr,
* em28xx_i2c_check_for_device()
* check if there is a i2c_device at the supplied address
*/
-static int em28xx_i2c_check_for_device(struct em28xx *dev, unsigned char addr)
+static int em28xx_i2c_check_for_device(struct em28xx *dev, u16 addr)
{
int ret;
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/5] em28xx: respect the message size constraints for i2c transfers
The em2800 can transfer up to 4 bytes per i2c message.
All other em25xx/em27xx/28xx chips can transfer at least 64 bytes per message.
I2C adapters should never split messages transferred via the I2C subsystem
into multiple message transfers, because the result will almost always NOT be
the same as when the whole data is transferred to the I2C client in a single
message.
If the message size exceeds the capabilities of the I2C adapter, -EOPNOTSUPP
should be returned.
Signed-off-by: Frank Schäfer fschaefer@googlemail.com
---
drivers/media/usb/em28xx/em28xx-i2c.c | 44 ++---
1 Datei geändert, 18 Zeilen hinzugefügt(+), 26 Zeilen entfernt(-)
diff --git a/drivers/media/usb/em28xx/em28xx-i2c.c
b/drivers/media/usb/em28xx/em28xx-i2c.c
index 44533e4..c508c12 100644
--- a/drivers/media/usb/em28xx/em28xx-i2c.c
+++ b/drivers/media/usb/em28xx/em28xx-i2c.c
@@ -50,14 +50,18 @@ do {
\
} while (0)
/*
- * em2800_i2c_send_max4()
- * send up to 4 bytes to the i2c device
+ * em2800_i2c_send_bytes()
+ * send up to 4 bytes to the em2800 i2c device
*/
-static int em2800_i2c_send_max4(struct em28xx *dev, u8 addr, u8 *buf, u16 len)
+static int em2800_i2c_send_bytes(struct em28xx *dev, u8 addr, u8 *buf, u16 len)
{
int ret;
int write_timeout;
u8 b2[6];
+
+ if (len 1 || len 4)
+ return -EOPNOTSUPP;
+
BUG_ON(len 1 || len 4);
b2[5] = 0x80 + len - 1;
b2[4] = addr;
@@ -86,29 +90,6 @@ static int em2800_i2c_send_max4(struct em28xx *dev, u8 addr,
u8 *buf, u16 len)
}
/*
- * em2800_i2c_send_bytes()
- */
-static int em2800_i2c_send_bytes(struct em28xx *dev, u8 addr, u8 *buf, u16 len)
-{
- u8 *bufPtr = buf;
- int ret;
- int wrcount = 0;
- int count;
- int maxLen = 4;
- while (len 0) {
- count = (len maxLen) ? maxLen : len;
- ret = em2800_i2c_send_max4(dev, addr, bufPtr, count);
- if (ret 0) {
- len -= count;
- bufPtr += count;
- wrcount += count;
- } else
- return (ret 0) ? ret : -EFAULT;
- }
- return wrcount;
-}
-
-/*
* em2800_i2c_check_for_device()
* check if there is a i2c_device at the supplied address
*/
@@ -150,6 +131,10 @@ static int em2800_i2c_check_for_device(struct em28xx *dev,
u8 addr)
static int em2800_i2c_recv_bytes(struct em28xx *dev, u8 addr, u8 *buf, u16 len)
{
int ret;
+
+ if (len 1 || len 4)
+ return -EOPNOTSUPP;
+
/* check for the device and set i2c read address */
ret = em2800_i2c_check_for_device(dev, addr);
if (ret) {
@@ -176,6 +161,9 @@ static int em28xx_i2c_send_bytes(struct em28xx *dev, u16
addr, u8 *buf,
int wrcount = 0;
int write_timeout, ret;
+ if (len 1 || len 64)
+ return -EOPNOTSUPP;
+
wrcount = dev-em28xx_write_regs_req(dev, stop ? 2 : 3, addr, buf, len);
/* Seems to be required after a write */
@@ -197,6 +185,10 @@ static int em28xx_i2c_send_bytes(struct em28xx *dev, u16
addr, u8 *buf,
static int em28xx_i2c_recv_bytes(struct em28xx *dev, u16 addr, u8 *buf, u16
len)
{
int ret;
+
+ if (len 1 || len 64)
+ return -EOPNOTSUPP;
+
ret = dev-em28xx_read_reg_req_len(dev, 2, addr, buf, len);
if (ret 0) {
em28xx_warn(reading i2c device failed (error=%i)\n, ret);
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 3/5] em28xx: fix two severe bugs in function em2800_i2c_recv_bytes()
Function em2800_i2c_recv_bytes() has 2 severe bugs:
1) It does not wait for the i2c read to complete before reading the received
message content from the bridge registers.
2) Reading more than 1 byte doesn't work
The former can result in data corruption, the latter always does.
The rewritten code also superseds the content of function
em2800_i2c_check_for_device().
Tested with device Terratec Cinergy 200 USB.
Signed-off-by: Frank Schäfer fschaefer@googlemail.com
---
drivers/media/usb/em28xx/em28xx-i2c.c | 104 ++---
drivers/media/usb/em28xx/em28xx.h |2 +-
2 Dateien geändert, 58 Zeilen hinzugefügt(+), 48 Zeilen entfernt(-)
diff --git a/drivers/media/usb/em28xx/em28xx-i2c.c
b/drivers/media/usb/em28xx/em28xx-i2c.c
index c508c12..940ff4d 100644
--- a/drivers/media/usb/em28xx/em28xx-i2c.c
+++ b/drivers/media/usb/em28xx/em28xx-i2c.c
@@ -73,12 +73,14 @@ static int em2800_i2c_send_bytes(struct em28xx *dev, u8
addr, u8 *buf, u16 len)
if (len 3)
b2[0] = buf[3];
+ /* trigger write */
ret = dev-em28xx_write_regs(dev, 4 - len, b2[4 - len], 2 + len);
if (ret != 2 + len) {
em28xx_warn(writing to i2c device failed (error=%i)\n, ret);
return -EIO;
}
- for (write_timeout = EM2800_I2C_WRITE_TIMEOUT; write_timeout 0;
+ /* wait for completion */
+ for (write_timeout = EM2800_I2C_XFER_TIMEOUT; write_timeout 0;
write_timeout -= 5) {
ret = dev-em28xx_read_reg(dev, 0x05);
if (ret == 0x80 + len - 1)
@@ -90,66 +92,74 @@ static int em2800_i2c_send_bytes(struct em28xx *dev, u8
addr, u8 *buf, u16 len)
}
/*
- * em2800_i2c_check_for_device()
- * check if there is a i2c_device at the supplied address
+ * em2800_i2c_recv_bytes()
+ * read up to 4 bytes from the em2800 i2c device
*/
-static int em2800_i2c_check_for_device(struct em28xx *dev, u8 addr)
+static int em2800_i2c_recv_bytes(struct em28xx *dev, u8 addr, u8 *buf, u16 len)
{
- u8 msg;
+ u8 buf2[4];
int ret;
- int write_timeout;
- msg = addr;
- ret = dev-em28xx_write_regs(dev, 0x04, msg, 1);
- if (ret 0) {
- em28xx_warn(setting i2c device address failed (error=%i)\n,
- ret);
- return ret;
- }
- msg = 0x84;
- ret = dev-em28xx_write_regs(dev, 0x05, msg, 1);
- if (ret 0) {
- em28xx_warn(preparing i2c read failed (error=%i)\n, ret);
- return ret;
+ int read_timeout;
+ int i;
+
+ if (len 1 || len 4)
+ return -EOPNOTSUPP;
+
+ /* trigger read */
+ buf2[1] = 0x84 + len - 1;
+ buf2[0] = addr;
+ ret = dev-em28xx_write_regs(dev, 0x04, buf2, 2);
+ if (ret != 2) {
+ em28xx_warn(failed to trigger read from i2c address 0x%x
+ (error=%i)\n, addr, ret);
+ return (ret 0) ? ret : -EIO;
}
- for (write_timeout = EM2800_I2C_WRITE_TIMEOUT; write_timeout 0;
-write_timeout -= 5) {
- unsigned reg = dev-em28xx_read_reg(dev, 0x5);
- if (reg == 0x94)
+ /* wait for completion */
+ for (read_timeout = EM2800_I2C_XFER_TIMEOUT; read_timeout 0;
+read_timeout -= 5) {
+ ret = dev-em28xx_read_reg(dev, 0x05);
+ if (ret == 0x84 + len - 1) {
+ break;
+ } else if (ret == 0x94 + len - 1) {
return -ENODEV;
- else if (reg == 0x84)
- return 0;
+ } else if (ret 0) {
+ em28xx_warn(failed to get i2c transfer status from
+ bridge register (error=%i)\n, ret);
+ return ret;
+ }
msleep(5);
}
- return -ENODEV;
+ if (ret != 0x84 + len - 1)
+ em28xx_warn(read from i2c device at 0x%x timed out\n, addr);
+
+ /* get the received message */
+ ret = dev-em28xx_read_reg_req_len(dev, 0x00, 4-len, buf2, len);
+ if (ret != len) {
+ em28xx_warn(reading from i2c device at 0x%x failed:
+ couldn't get the received message from the bridge
+ (error=%i)\n, addr, ret);
+ return (ret 0) ? ret : -EIO;
+ }
+ for (i=0; ilen; i++)
+ buf[i] = buf2[len-1-i];
+
+ return ret;
}
/*
- * em2800_i2c_recv_bytes()
- * read from the i2c device
+ * em2800_i2c_check_for_device()
+ * check if there is an i2c device at the supplied address
*/
-static int em2800_i2c_recv_bytes(struct em28xx *dev, u8 addr, u8 *buf, u16 len)
+static int em2800_i2c_check_for_device(struct em28xx *dev, u8 addr)
{
+ u8 buf;
int ret;
- if (len 1 || len 4)
- return -EOPNOTSUPP;
-
- /*
[PATCH v2 4/5] em28xx: fix the i2c adapter functionality flags
I2C_FUNC_SMBUS_EMUL includes flag I2C_FUNC_SMBUS_WRITE_BLOCK_DATA which signals
that up to 31 data bytes can be written to the ic2 client.
But the EM2800 supports only i2c messages with max. 4 data bytes.
I2C_FUNC_IC2 should be set if a master_xfer fucntion pointer is provided in
struct i2c_algorithm.
Signed-off-by: Frank Schäfer fschaefer@googlemail.com
---
drivers/media/usb/em28xx/em28xx-i2c.c |6 +-
1 Datei geändert, 5 Zeilen hinzugefügt(+), 1 Zeile entfernt(-)
diff --git a/drivers/media/usb/em28xx/em28xx-i2c.c
b/drivers/media/usb/em28xx/em28xx-i2c.c
index 940ff4d..7118535 100644
--- a/drivers/media/usb/em28xx/em28xx-i2c.c
+++ b/drivers/media/usb/em28xx/em28xx-i2c.c
@@ -445,7 +445,11 @@ static int em28xx_i2c_eeprom(struct em28xx *dev, unsigned
char *eedata, int len)
*/
static u32 functionality(struct i2c_adapter *adap)
{
- return I2C_FUNC_SMBUS_EMUL;
+ struct em28xx *dev = adap-algo_data;
+ u32 func_flags = I2C_FUNC_I2C | I2C_FUNC_SMBUS_EMUL;
+ if (dev-board.is_em2800)
+ func_flags = ~I2C_FUNC_SMBUS_WRITE_BLOCK_DATA;
+ return func_flags;
}
static struct i2c_algorithm em28xx_algo = {
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 5/5] em28xx: fix+improve+unify i2c error handling, debug messages and code comments
- do not pass USB specific error codes to userspace/i2c-subsystem
- unify the returned error codes and make them compliant with
the i2c subsystem spec
- check number of actually transferred bytes (via USB) everywehere
- fix/improve debug messages
- improve code comments
Changelog v2:
- removed i2c address type/range check as requested by Antti Palosaari
Signed-off-by: Frank Schäfer fschaefer@googlemail.com
---
drivers/media/usb/em28xx/em28xx-core.c |5 +-
drivers/media/usb/em28xx/em28xx-i2c.c | 112 +++-
2 Dateien geändert, 85 Zeilen hinzugefügt(+), 32 Zeilen entfernt(-)
diff --git a/drivers/media/usb/em28xx/em28xx-core.c
b/drivers/media/usb/em28xx/em28xx-core.c
index c78d38b..cd808bf 100644
--- a/drivers/media/usb/em28xx/em28xx-core.c
+++ b/drivers/media/usb/em28xx/em28xx-core.c
@@ -101,7 +101,7 @@ int em28xx_read_reg_req_len(struct em28xx *dev, u8 req, u16
reg,
if (reg_debug)
printk( failed!\n);
mutex_unlock(dev-ctrl_urb_lock);
- return ret;
+ return usb_translate_errors(ret);
}
if (len)
@@ -182,6 +182,9 @@ int em28xx_write_regs_req(struct em28xx *dev, u8 req, u16
reg, char *buf,
0x, reg, dev-urb_buf, len, HZ);
mutex_unlock(dev-ctrl_urb_lock);
+ if (ret 0)
+ return usb_translate_errors(ret);
+
if (dev-wait_after_write)
msleep(dev-wait_after_write);
diff --git a/drivers/media/usb/em28xx/em28xx-i2c.c
b/drivers/media/usb/em28xx/em28xx-i2c.c
index 7118535..c57db43 100644
--- a/drivers/media/usb/em28xx/em28xx-i2c.c
+++ b/drivers/media/usb/em28xx/em28xx-i2c.c
@@ -76,18 +76,26 @@ static int em2800_i2c_send_bytes(struct em28xx *dev, u8
addr, u8 *buf, u16 len)
/* trigger write */
ret = dev-em28xx_write_regs(dev, 4 - len, b2[4 - len], 2 + len);
if (ret != 2 + len) {
- em28xx_warn(writing to i2c device failed (error=%i)\n, ret);
- return -EIO;
+ em28xx_warn(failed to trigger write to i2c address 0x%x
+ (error=%i)\n, addr, ret);
+ return (ret 0) ? ret : -EIO;
}
/* wait for completion */
for (write_timeout = EM2800_I2C_XFER_TIMEOUT; write_timeout 0;
write_timeout -= 5) {
ret = dev-em28xx_read_reg(dev, 0x05);
- if (ret == 0x80 + len - 1)
+ if (ret == 0x80 + len - 1) {
return len;
+ } else if (ret == 0x94 + len - 1) {
+ return -ENODEV;
+ } else if (ret 0) {
+ em28xx_warn(failed to get i2c transfer status from
+ bridge register (error=%i)\n, ret);
+ return ret;
+ }
msleep(5);
}
- em28xx_warn(i2c write timed out\n);
+ em28xx_warn(write to i2c device at 0x%x timed out\n, addr);
return -EIO;
}
@@ -168,24 +176,46 @@ static int em2800_i2c_check_for_device(struct em28xx
*dev, u8 addr)
static int em28xx_i2c_send_bytes(struct em28xx *dev, u16 addr, u8 *buf,
u16 len, int stop)
{
- int wrcount = 0;
int write_timeout, ret;
if (len 1 || len 64)
return -EOPNOTSUPP;
- wrcount = dev-em28xx_write_regs_req(dev, stop ? 2 : 3, addr, buf, len);
+ /* Write to i2c device */
+ ret = dev-em28xx_write_regs_req(dev, stop ? 2 : 3, addr, buf, len);
+ if (ret != len) {
+ if (ret 0) {
+ em28xx_warn(writing to i2c device at 0x%x failed
+ (error=%i)\n, addr, ret);
+ return ret;
+ } else {
+ em28xx_warn(%i bytes write to i2c device at 0x%x
+ requested, but %i bytes written\n,
+ len, addr, ret);
+ return -EIO;
+ }
+ }
- /* Seems to be required after a write */
+ /* Check success of the i2c operation */
for (write_timeout = EM2800_I2C_XFER_TIMEOUT; write_timeout 0;
write_timeout -= 5) {
ret = dev-em28xx_read_reg(dev, 0x05);
- if (!ret)
- break;
+ if (ret == 0) { /* success */
+ return len;
+ } else if (ret == 0x10) {
+ return -ENODEV;
+ } else if (ret 0) {
+ em28xx_warn(failed to read i2c transfer status from
+ bridge (error=%i)\n, ret);
+ return ret;
+ }
msleep(5);
+ /* NOTE: do we really have to wait for success ?
+ Never seen anything else than 0x00 or 0x10
+
Re: [PATCH] omap_vout: find_vma() needs -mmap_sem held
On Sun, Dec 16, 2012 at 09:01:10PM +0100, Paul Bolle wrote:
+ vma = find_vma(mm, virtp);
} else if (vma (vma-vm_flags VM_IO) vma-vm_pgoff) {
Shouldn't that line become
if (vma (vma-vm_flags VM_IO) vma-vm_pgoff) {
so that this actually compiles?
*Do'h*
Yes, it should. Mea culpa...
Signed-off-by: Al Viro v...@zeniv.linux.org.uk
---
diff --git a/drivers/media/platform/omap/omap_vout.c
b/drivers/media/platform/omap/omap_vout.c
index 9935040..cb564d0 100644
--- a/drivers/media/platform/omap/omap_vout.c
+++ b/drivers/media/platform/omap/omap_vout.c
@@ -207,19 +207,21 @@ static u32 omap_vout_uservirt_to_phys(u32 virtp)
struct vm_area_struct *vma;
struct mm_struct *mm = current-mm;
- vma = find_vma(mm, virtp);
/* For kernel direct-mapped memory, take the easy way */
- if (virtp = PAGE_OFFSET) {
- physp = virt_to_phys((void *) virtp);
- } else if (vma (vma-vm_flags VM_IO) vma-vm_pgoff) {
+ if (virtp = PAGE_OFFSET)
+ return virt_to_phys((void *) virtp);
+
+ down_read(current-mm-mmap_sem);
+ vma = find_vma(mm, virtp);
+ if (vma (vma-vm_flags VM_IO) vma-vm_pgoff) {
/* this will catch, kernel-allocated, mmaped-to-usermode
addresses */
physp = (vma-vm_pgoff PAGE_SHIFT) + (virtp - vma-vm_start);
+ up_read(current-mm-mmap_sem);
} else {
/* otherwise, use get_user_pages() for general userland pages */
int res, nr_pages = 1;
struct page *pages;
- down_read(current-mm-mmap_sem);
res = get_user_pages(current, current-mm, virtp, nr_pages, 1,
0, pages, NULL);
--
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: cannot make this Asus my cinema-u3100miniplusv2 work under linux
i found it is a problem with kaffeine, with other programs i can lock a signal but reception is very very sketchy (like in unviewable). GlovX xine-lib # dmesg |grep e4000 GlovX xine-lib # dmesg |grep FC0012 GlovX xine-lib # dmesg |grep FC0013 [ 28.281685] fc0013: Fitipower FC0013 successfully attached. GlovX xine-lib # dmesg |grep FC2580 GlovX xine-lib # dmesg |grep TUA GlovX xine-lib # Il 16/12/2012 18:55 Antti Palosaari ha scritto: On 12/16/2012 07:15 PM, Renato Gallo wrote: now the modules loads and kaffeine recognizes the device but i cannot find any channels. can it be a tuner bug ? I think it is bad antenna / weak signal. Try w_scan, scan, tzap. Could you say which RF-tuner it finds from your device? use dmesg to dump output. It could be for example e4000, FC0012, FC0013, FC2580, TUA9001 etc. Antti kaffeine(5978) DvbDevice::frontendEvent: tuning failed kaffeine(5978) DvbScanFilter::timerEvent: timeout while reading section; type = 0 pid = 0 kaffeine(5978) DvbScanFilter::timerEvent: timeout while reading section; type = 2 pid = 17 kaffeine(5978) DvbScanFilter::timerEvent: timeout while reading section; type = 4 pid = 16 kaffeine(5978) DvbDevice::frontendEvent: tuning failed kaffeine(5978) DvbScanFilter::timerEvent: timeout while reading section; type = 0 pid = 0 kaffeine(5978) DvbScanFilter::timerEvent: timeout while reading section; type = 2 pid = 17 kaffeine(5978) DvbScanFilter::timerEvent: timeout while reading section; type = 4 pid = 16 kaffeine(5978) DvbDevice::frontendEvent: tuning failed Il 16/12/2012 15:50 Antti Palosaari ha scritto: On 12/16/2012 04:23 PM, Renato Gallo wrote: any news on this ? Asus my cinema-u3100miniplusv2 Bus 001 Device 015: ID 1b80:d3a8 Afatech [ 6956.333440] usb 1-6.3.6: new high-speed USB device number 16 using ehci_hcd [ 6956.453943] usb 1-6.3.6: New USB device found, idVendor=1b80, idProduct=d3a8 [ 6956.453950] usb 1-6.3.6: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 6956.453955] usb 1-6.3.6: Product: Rtl2832UDVB [ 6956.453959] usb 1-6.3.6: Manufacturer: Realtek Seems to be Realtek RTL2832U. Add that USB ID to the driver and test. It is very high probability it starts working. Here is the patch: http://git.linuxtv.org/anttip/media_tree.git/shortlog/refs/heads/rtl28xxu-usb-ids Please test and report. regards Antti -- 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: cannot make this Asus my cinema-u3100miniplusv2 work under linux
It is very likely weak signal issue as I said. What kind of antenna you are using? Antti On 12/16/2012 10:13 PM, Renato Gallo wrote: i found it is a problem with kaffeine, with other programs i can lock a signal but reception is very very sketchy (like in unviewable). GlovX xine-lib # dmesg |grep e4000 GlovX xine-lib # dmesg |grep FC0012 GlovX xine-lib # dmesg |grep FC0013 [ 28.281685] fc0013: Fitipower FC0013 successfully attached. GlovX xine-lib # dmesg |grep FC2580 GlovX xine-lib # dmesg |grep TUA GlovX xine-lib # Il 16/12/2012 18:55 Antti Palosaari ha scritto: On 12/16/2012 07:15 PM, Renato Gallo wrote: now the modules loads and kaffeine recognizes the device but i cannot find any channels. can it be a tuner bug ? I think it is bad antenna / weak signal. Try w_scan, scan, tzap. Could you say which RF-tuner it finds from your device? use dmesg to dump output. It could be for example e4000, FC0012, FC0013, FC2580, TUA9001 etc. Antti kaffeine(5978) DvbDevice::frontendEvent: tuning failed kaffeine(5978) DvbScanFilter::timerEvent: timeout while reading section; type = 0 pid = 0 kaffeine(5978) DvbScanFilter::timerEvent: timeout while reading section; type = 2 pid = 17 kaffeine(5978) DvbScanFilter::timerEvent: timeout while reading section; type = 4 pid = 16 kaffeine(5978) DvbDevice::frontendEvent: tuning failed kaffeine(5978) DvbScanFilter::timerEvent: timeout while reading section; type = 0 pid = 0 kaffeine(5978) DvbScanFilter::timerEvent: timeout while reading section; type = 2 pid = 17 kaffeine(5978) DvbScanFilter::timerEvent: timeout while reading section; type = 4 pid = 16 kaffeine(5978) DvbDevice::frontendEvent: tuning failed Il 16/12/2012 15:50 Antti Palosaari ha scritto: On 12/16/2012 04:23 PM, Renato Gallo wrote: any news on this ? Asus my cinema-u3100miniplusv2 Bus 001 Device 015: ID 1b80:d3a8 Afatech [ 6956.333440] usb 1-6.3.6: new high-speed USB device number 16 using ehci_hcd [ 6956.453943] usb 1-6.3.6: New USB device found, idVendor=1b80, idProduct=d3a8 [ 6956.453950] usb 1-6.3.6: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 6956.453955] usb 1-6.3.6: Product: Rtl2832UDVB [ 6956.453959] usb 1-6.3.6: Manufacturer: Realtek Seems to be Realtek RTL2832U. Add that USB ID to the driver and test. It is very high probability it starts working. Here is the patch: http://git.linuxtv.org/anttip/media_tree.git/shortlog/refs/heads/rtl28xxu-usb-ids Please test and report. regards Antti -- 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 -- 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
cron job: media_tree daily build: ERRORS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date:Sun Dec 16 19:00:27 CET 2012 git hash:49cc629df16f2a15917800a8579bd9c25c41b634 gcc version: i686-linux-gcc (GCC) 4.7.1 host hardware:x86_64 host os: 3.4.07-marune linux-git-arm-eabi-davinci: WARNINGS linux-git-arm-eabi-exynos: OK linux-git-arm-eabi-omap: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: WARNINGS linux-2.6.31.12-i686: WARNINGS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.39.1-i686: WARNINGS linux-3.0-i686: WARNINGS linux-3.1-i686: WARNINGS linux-3.2.1-i686: WARNINGS linux-3.3-i686: WARNINGS linux-3.4-i686: WARNINGS linux-3.5-i686: WARNINGS linux-3.6-i686: WARNINGS linux-3.7-i686: ERRORS linux-2.6.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS linux-2.6.39.1-x86_64: WARNINGS linux-3.0-x86_64: WARNINGS linux-3.1-x86_64: WARNINGS linux-3.2.1-x86_64: WARNINGS linux-3.3-x86_64: WARNINGS linux-3.4-x86_64: WARNINGS linux-3.5-x86_64: WARNINGS linux-3.6-x86_64: WARNINGS linux-3.7-x86_64: ERRORS apps: WARNINGS spec-git: WARNINGS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cannot make this Asus my cinema-u3100miniplusv2 work under linux
stock one that came with the device http://unixproducts.com/antenna.jpg Il 16/12/2012 21:34 Antti Palosaari ha scritto: It is very likely weak signal issue as I said. What kind of antenna you are using? Antti On 12/16/2012 10:13 PM, Renato Gallo wrote: i found it is a problem with kaffeine, with other programs i can lock a signal but reception is very very sketchy (like in unviewable). GlovX xine-lib # dmesg |grep e4000 GlovX xine-lib # dmesg |grep FC0012 GlovX xine-lib # dmesg |grep FC0013 [ 28.281685] fc0013: Fitipower FC0013 successfully attached. GlovX xine-lib # dmesg |grep FC2580 GlovX xine-lib # dmesg |grep TUA GlovX xine-lib # Il 16/12/2012 18:55 Antti Palosaari ha scritto: On 12/16/2012 07:15 PM, Renato Gallo wrote: now the modules loads and kaffeine recognizes the device but i cannot find any channels. can it be a tuner bug ? I think it is bad antenna / weak signal. Try w_scan, scan, tzap. Could you say which RF-tuner it finds from your device? use dmesg to dump output. It could be for example e4000, FC0012, FC0013, FC2580, TUA9001 etc. Antti kaffeine(5978) DvbDevice::frontendEvent: tuning failed kaffeine(5978) DvbScanFilter::timerEvent: timeout while reading section; type = 0 pid = 0 kaffeine(5978) DvbScanFilter::timerEvent: timeout while reading section; type = 2 pid = 17 kaffeine(5978) DvbScanFilter::timerEvent: timeout while reading section; type = 4 pid = 16 kaffeine(5978) DvbDevice::frontendEvent: tuning failed kaffeine(5978) DvbScanFilter::timerEvent: timeout while reading section; type = 0 pid = 0 kaffeine(5978) DvbScanFilter::timerEvent: timeout while reading section; type = 2 pid = 17 kaffeine(5978) DvbScanFilter::timerEvent: timeout while reading section; type = 4 pid = 16 kaffeine(5978) DvbDevice::frontendEvent: tuning failed Il 16/12/2012 15:50 Antti Palosaari ha scritto: On 12/16/2012 04:23 PM, Renato Gallo wrote: any news on this ? Asus my cinema-u3100miniplusv2 Bus 001 Device 015: ID 1b80:d3a8 Afatech [ 6956.333440] usb 1-6.3.6: new high-speed USB device number 16 using ehci_hcd [ 6956.453943] usb 1-6.3.6: New USB device found, idVendor=1b80, idProduct=d3a8 [ 6956.453950] usb 1-6.3.6: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 6956.453955] usb 1-6.3.6: Product: Rtl2832UDVB [ 6956.453959] usb 1-6.3.6: Manufacturer: Realtek Seems to be Realtek RTL2832U. Add that USB ID to the driver and test. It is very high probability it starts working. Here is the patch: http://git.linuxtv.org/anttip/media_tree.git/shortlog/refs/heads/rtl28xxu-usb-ids Please test and report. regards Antti -- 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 -- 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: cannot make this Asus my cinema-u3100miniplusv2 work under linux
That antenna is your problem. I will send that patch to the Kernel 3.8, but as I think it is maybe too late for 3.8 it will eventually go to the 3.9 which is out sometime near beginning of next summer. If you wish I add your name as reporter then reply. Otherwise case closed. Feedback from the better antenna could be nice too. Antti On 12/16/2012 11:16 PM, Renato Gallo wrote: stock one that came with the device http://unixproducts.com/antenna.jpg Il 16/12/2012 21:34 Antti Palosaari ha scritto: It is very likely weak signal issue as I said. What kind of antenna you are using? Antti On 12/16/2012 10:13 PM, Renato Gallo wrote: i found it is a problem with kaffeine, with other programs i can lock a signal but reception is very very sketchy (like in unviewable). GlovX xine-lib # dmesg |grep e4000 GlovX xine-lib # dmesg |grep FC0012 GlovX xine-lib # dmesg |grep FC0013 [ 28.281685] fc0013: Fitipower FC0013 successfully attached. GlovX xine-lib # dmesg |grep FC2580 GlovX xine-lib # dmesg |grep TUA GlovX xine-lib # Il 16/12/2012 18:55 Antti Palosaari ha scritto: On 12/16/2012 07:15 PM, Renato Gallo wrote: now the modules loads and kaffeine recognizes the device but i cannot find any channels. can it be a tuner bug ? I think it is bad antenna / weak signal. Try w_scan, scan, tzap. Could you say which RF-tuner it finds from your device? use dmesg to dump output. It could be for example e4000, FC0012, FC0013, FC2580, TUA9001 etc. Antti kaffeine(5978) DvbDevice::frontendEvent: tuning failed kaffeine(5978) DvbScanFilter::timerEvent: timeout while reading section; type = 0 pid = 0 kaffeine(5978) DvbScanFilter::timerEvent: timeout while reading section; type = 2 pid = 17 kaffeine(5978) DvbScanFilter::timerEvent: timeout while reading section; type = 4 pid = 16 kaffeine(5978) DvbDevice::frontendEvent: tuning failed kaffeine(5978) DvbScanFilter::timerEvent: timeout while reading section; type = 0 pid = 0 kaffeine(5978) DvbScanFilter::timerEvent: timeout while reading section; type = 2 pid = 17 kaffeine(5978) DvbScanFilter::timerEvent: timeout while reading section; type = 4 pid = 16 kaffeine(5978) DvbDevice::frontendEvent: tuning failed Il 16/12/2012 15:50 Antti Palosaari ha scritto: On 12/16/2012 04:23 PM, Renato Gallo wrote: any news on this ? Asus my cinema-u3100miniplusv2 Bus 001 Device 015: ID 1b80:d3a8 Afatech [ 6956.333440] usb 1-6.3.6: new high-speed USB device number 16 using ehci_hcd [ 6956.453943] usb 1-6.3.6: New USB device found, idVendor=1b80, idProduct=d3a8 [ 6956.453950] usb 1-6.3.6: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 6956.453955] usb 1-6.3.6: Product: Rtl2832UDVB [ 6956.453959] usb 1-6.3.6: Manufacturer: Realtek Seems to be Realtek RTL2832U. Add that USB ID to the driver and test. It is very high probability it starts working. Here is the patch: http://git.linuxtv.org/anttip/media_tree.git/shortlog/refs/heads/rtl28xxu-usb-ids Please test and report. regards Antti -- 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 -- 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 -- 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: cannot make this Asus my cinema-u3100miniplusv2 work under linux
I will be honored if my name will be added as reporter, thanks for your kind and fast advice. I have ordered another portable (30 db) antenna and will talk about that in a future reply to this thread :) Il 16/12/2012 22:22 Antti Palosaari ha scritto: That antenna is your problem. I will send that patch to the Kernel 3.8, but as I think it is maybe too late for 3.8 it will eventually go to the 3.9 which is out sometime near beginning of next summer. If you wish I add your name as reporter then reply. Otherwise case closed. Feedback from the better antenna could be nice too. Antti On 12/16/2012 11:16 PM, Renato Gallo wrote: stock one that came with the device http://unixproducts.com/antenna.jpg Il 16/12/2012 21:34 Antti Palosaari ha scritto: It is very likely weak signal issue as I said. What kind of antenna you are using? Antti On 12/16/2012 10:13 PM, Renato Gallo wrote: i found it is a problem with kaffeine, with other programs i can lock a signal but reception is very very sketchy (like in unviewable). GlovX xine-lib # dmesg |grep e4000 GlovX xine-lib # dmesg |grep FC0012 GlovX xine-lib # dmesg |grep FC0013 [ 28.281685] fc0013: Fitipower FC0013 successfully attached. GlovX xine-lib # dmesg |grep FC2580 GlovX xine-lib # dmesg |grep TUA GlovX xine-lib # Il 16/12/2012 18:55 Antti Palosaari ha scritto: On 12/16/2012 07:15 PM, Renato Gallo wrote: now the modules loads and kaffeine recognizes the device but i cannot find any channels. can it be a tuner bug ? I think it is bad antenna / weak signal. Try w_scan, scan, tzap. Could you say which RF-tuner it finds from your device? use dmesg to dump output. It could be for example e4000, FC0012, FC0013, FC2580, TUA9001 etc. Antti kaffeine(5978) DvbDevice::frontendEvent: tuning failed kaffeine(5978) DvbScanFilter::timerEvent: timeout while reading section; type = 0 pid = 0 kaffeine(5978) DvbScanFilter::timerEvent: timeout while reading section; type = 2 pid = 17 kaffeine(5978) DvbScanFilter::timerEvent: timeout while reading section; type = 4 pid = 16 kaffeine(5978) DvbDevice::frontendEvent: tuning failed kaffeine(5978) DvbScanFilter::timerEvent: timeout while reading section; type = 0 pid = 0 kaffeine(5978) DvbScanFilter::timerEvent: timeout while reading section; type = 2 pid = 17 kaffeine(5978) DvbScanFilter::timerEvent: timeout while reading section; type = 4 pid = 16 kaffeine(5978) DvbDevice::frontendEvent: tuning failed Il 16/12/2012 15:50 Antti Palosaari ha scritto: On 12/16/2012 04:23 PM, Renato Gallo wrote: any news on this ? Asus my cinema-u3100miniplusv2 Bus 001 Device 015: ID 1b80:d3a8 Afatech [ 6956.333440] usb 1-6.3.6: new high-speed USB device number 16 using ehci_hcd [ 6956.453943] usb 1-6.3.6: New USB device found, idVendor=1b80, idProduct=d3a8 [ 6956.453950] usb 1-6.3.6: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 6956.453955] usb 1-6.3.6: Product: Rtl2832UDVB [ 6956.453959] usb 1-6.3.6: Manufacturer: Realtek Seems to be Realtek RTL2832U. Add that USB ID to the driver and test. It is very high probability it starts working. Here is the patch: http://git.linuxtv.org/anttip/media_tree.git/shortlog/refs/heads/rtl28xxu-usb-ids Please test and report. regards Antti -- 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 -- 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
Anyone want a crash-backtrace (Atom/Ion) ?
Don't know if anyone will want to try getting any info out of the log messages below here, my system is tainted in every way possible. I'm running squeeze with a kernel from backports and nvidia vdpau display-drivers (ii nvidia-kernel-dkms 295.59-1~bpo60+2 ) . Also running mythtv-0.26-fixes with some homegrown patches. Anyway, if anyone wants it, here it is. At the time this happens the system becomes totally unresponsive. Logging is via udp to another host on my network. If anyone has patches to test, I'm up for it. I'm running an atom 330 cpu and an nVidia ION gpu. TechnoTrend AG TT-connect CT-3650 CI capturecard Kernel: root@sookie:/apub:0:# uname -a Linux sookie 3.2.0-0.bpo.4-rt-686-pae #1 SMP PREEMPT RT Debian 3.2.32-1~bpo60+1 i686 GNU/Linux --- Modules loaded are --- root@sookie:/apub:0:# lsmod Module Size Used by joydev 16906 0 hidp 17543 0 parport_pc 21895 0 ppdev 12621 0 lp 12858 0 parport27018 3 parport_pc,ppdev,lp bridge 59191 0 stp12368 1 bridge mperf 12387 0 bnep 17147 2 cpufreq_conservative12987 0 rfcomm 31983 8 cpufreq_stats 12711 0 autofs422715 1 cpufreq_powersave 12422 0 cpufreq_userspace 12520 0 snd_hrtimer12540 1 nfsd 176690 13 nfs 271813 7 lockd 60955 2 nfsd,nfs fscache31488 1 nfs auth_rpcgss31970 2 nfsd,nfs nfs_acl12463 2 nfsd,nfs sunrpc150575 30 nfsd,nfs,lockd,auth_rpcgss,nfs_acl binfmt_misc12778 1 fuse 55737 1 loop 22119 0 nvidia 10933469 40 snd_hda_codec_hdmi 30242 1 snd_hda_codec_realtek 141983 1 rc_tt_1500 12372 0 ir_lirc_codec 12651 0 lirc_dev 12797 1 ir_lirc_codec snd_hda_intel 21660 1 ir_mce_kbd_decoder 12518 0 tda10048 16982 1 ir_sony_decoder12403 0 tda827x12954 2 tda10023 12839 1 ir_jvc_decoder 12401 0 snd_hda_codec 63120 3 snd_hda_codec_hdmi,snd_hda_codec_realtek,snd_hda_intel dvb_usb_ttusb2 17404 22 dvb_usb17913 1 dvb_usb_ttusb2 dvb_core 67624 2 dvb_usb_ttusb2,dvb_usb ir_rc6_decoder 12401 0 snd_hwdep 12906 1 snd_hda_codec snd_pcm_oss35906 0 snd_mixer_oss 17649 1 snd_pcm_oss ir_rc5_decoder 12401 0 snd_pcm52946 4 snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec,snd_pcm_oss ir_nec_decoder 12401 0 btusb 17209 2 snd_seq_midi 12744 0 bluetooth 111085 24 hidp,bnep,rfcomm,btusb rc_core17813 11 rc_tt_1500,ir_lirc_codec,ir_mce_kbd_decoder,ir_sony_decoder,ir_jvc_decoder,dvb_usb_ttusb2,dvb_usb,ir_rc6_decoder,ir_rc5_decoder,ir_nec_decoder snd_rawmidi22310 1 snd_seq_midi rfkill 18474 3 bluetooth snd_seq_midi_event 13124 1 snd_seq_midi snd_seq39208 3 snd_seq_midi,snd_seq_midi_event crc16 12327 1 bluetooth psmouse54719 0 snd_timer 22209 3 snd_hrtimer,snd_pcm,snd_seq snd_seq_device 12995 3 snd_seq_midi,snd_rawmidi,snd_seq evdev 17209 14 shpchp 26653 0 tpm_tis13027 0 tpm17545 1 tpm_tis tpm_bios 12799 1 tpm wmi13051 0 coretemp 12793 0 processor 27159 0 serio_raw 12820 0 i2c_nforce212520 0 snd42459 15 snd_hda_codec_hdmi,snd_hda_codec_realtek,snd_hda_intel,snd_hda_codec,snd_hwdep,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_rawmidi,snd_seq,snd_timer,snd_seq_device soundcore 12878 1 snd snd_page_alloc 12841 2 snd_hda_intel,snd_pcm pcspkr 12515 0 i2c_core 19022 6 nvidia,tda10048,tda827x,tda10023,dvb_usb,i2c_nforce2 button 12783 0 thermal_sys17712 1 processor usbhid 35206 0 hid63962 2 hidp,usbhid ext3 141637 2 jbd50667 1 ext3 mbcache12810 1 ext3 sg 21385 0 sd_mod 35060 4 sr_mod 17418 0 cdrom 30535 1 sr_mod crc_t10dif 12332 1 sd_mod ata_generic12439 0 ohci_hcd 21855 0 ahci 20821 4 libahci22282 1 ahci libata124147 3 ata_generic,ahci,libahci ehci_hcd 34968 0 usbcore 107736 7 dvb_usb_ttusb2,dvb_usb,btusb,usbhid,ohci_hcd,ehci_hcd
RE: [PATCH V3 02/15] [media] marvell-ccic: add MIPI support for marvell-ccic driver
Hi, Jonathan
-Original Message-
From: Jonathan Corbet [mailto:cor...@lwn.net]
Sent: Sunday, 16 December, 2012 23:55
To: Albert Wang
Cc: g.liakhovet...@gmx.de; linux-media@vger.kernel.org; Libin Yang
Subject: Re: [PATCH V3 02/15] [media] marvell-ccic: add MIPI support for
marvell-ccic
driver
On Sat, 15 Dec 2012 17:57:51 +0800
Albert Wang twan...@marvell.com wrote:
From: Libin Yang lby...@marvell.com
This patch adds the MIPI support for marvell-ccic.
Board driver should determine whether using MIPI or not.
There are limits to how deeply I can review this, since I know little about
the MIPI mode and don't have any hardware that uses it. So I'm assuming
that it all works :) My comments are on a different level.
+static int mcam_config_mipi(struct mcam_camera *mcam, int enable)
+{
+if (mcam-bus_type == V4L2_MBUS_CSI2 enable) {
+/* Using MIPI mode and enable MIPI */
+cam_dbg(mcam, camera: DPHY3=0x%x, DPHY5=0x%x,
DPHY6=0x%x\n,
+mcam-dphy[0], mcam-dphy[1], mcam-dphy[2]);
+mcam_reg_write(mcam, REG_CSI2_DPHY3, mcam-dphy[0]);
+mcam_reg_write(mcam, REG_CSI2_DPHY6, mcam-dphy[2]);
+mcam_reg_write(mcam, REG_CSI2_DPHY5, mcam-dphy[1]);
Is there a reason you're writing them in something other than direct
increasing order? If so, a comment saying why might help somebody in ghe
future.
[Albert Wang] Oh, actually there is no strict sequence to write these MIPI
registers.
We can change it with direct increasing order, also we can add some comments
for describing the definition. :)
+if (mcam-mipi_enabled == 0) {
+/*
+ * 0x41 actives 1 lane
+ * 0x43 actives 2 lanes
+ * 0x47 actives 4 lanes
+ * There is no 3 lanes case
+ */
+switch (mcam-lane) {
+case 1:
+mcam_reg_write(mcam, REG_CSI2_CTRL0, 0x41);
+break;
+case 2:
+mcam_reg_write(mcam, REG_CSI2_CTRL0, 0x43);
+break;
+case 4:
+mcam_reg_write(mcam, REG_CSI2_CTRL0, 0x47);
+break;
Can we have defined symbols rather than magic constants here?
[Albert Wang] Sure, we can do it in the next version.
@@ -656,6 +701,15 @@ static void mcam_ctlr_image(struct mcam_camera *cam)
*/
mcam_reg_write_mask(cam, REG_CTRL0, C0_SIF_HVSYNC,
C0_SIFM_MASK);
+
+/*
+ * This field controls the generation of EOF(DVP only)
+ */
+if (cam-bus_type != V4L2_MBUS_CSI2) {
+mcam_reg_set_bit(cam, REG_CTRL0,
+C0_EOF_VSYNC | C0_VEDGE_CTRL);
+mcam_reg_write(cam, REG_CTRL3, 0x4);
Again, how about a symbol, or at least an explanation of what 0x4 means?
[Albert Wang] OK, will do it.
+}
}
[...]
@@ -1551,6 +1615,11 @@ static int mcam_v4l_open(struct file *filp)
mcam_set_config_needed(cam, 1);
}
(cam-users)++;
+cam-pll1 = devm_clk_get(cam-dev, pll1);
+if (IS_ERR(cam-pll1)) {
+cam_err(cam, Could not get pll1 clock\n);
+ret = PTR_ERR(cam-pll1);
+}
This looks like it gets the clock in all cases? Is that right?
[Albert Wang] Em, we need it in MIPI mode, it looks we should limit the usage
in the MIPI mode.
We will update it.
#define REG_IMGPITCH0x24/* Image pitch register */
@@ -292,7 +311,9 @@ int mccic_resume(struct mcam_camera *cam);
#define C0_DOWNSCALE0x0800/* Enable downscaler */
#define C0_SIFM_MASK0xc000/* SIF mode bits */
#define C0_SIF_HVSYNC 0x/* Use H/VSYNC */
-#define CO_SOF_NOSYNC 0x4000/* Use inband active signaling
*/
+#define C0_SOF_NOSYNC 0x4000/* Use inband active signaling
*/
+#define C0_EOF_VSYNC0x0040/* Generate EOF by VSYNC */
+#define C0_VEDGE_CTRL 0x0080/* Detect falling edge of
VSYNC */
Being the retentive sort of guy I am, I try to keep definitions like these
in numerical order. Any chance you could humor me and maintain that?
[Albert Wang] OK, we will update it and keep it with numerical order.
BTW, there is a typo in CO_SOF_NOSYNC
/* Bits below C1_444ALPHA are not present in Cafe */
#define REG_CTRL1 0x40/* Control 1 */
@@ -308,6 +329,7 @@ int mccic_resume(struct mcam_camera *cam);
#define C1_TWOBUFS 0x0800/* Use only two DMA buffers */
#define C1_PWRDWN 0x1000/* Power down */
+#define REG_CTRL3 0x1ec /* CCIC parallel mode */
#define REG_CLKCTRL 0x88/* Clock control */
#define CLK_DIV_MASK0x/* Upper bits RW reserved */
Here, too, I'd rather keep them in
RE: [PATCH V3 03/15] [media] marvell-ccic: add clock tree support for marvell-ccic driver
Hi, Jonathan
-Original Message-
From: Jonathan Corbet [mailto:cor...@lwn.net]
Sent: Monday, 17 December, 2012 00:03
To: Albert Wang
Cc: g.liakhovet...@gmx.de; linux-media@vger.kernel.org; Libin Yang
Subject: Re: [PATCH V3 03/15] [media] marvell-ccic: add clock tree support for
marvell-
ccic driver
On Sat, 15 Dec 2012 17:57:52 +0800
Albert Wang twan...@marvell.com wrote:
From: Libin Yang lby...@marvell.com
This patch adds the clock tree support for marvell-ccic.
Each board may require different clk enabling sequence.
Developer need add the clk_name in correct sequence in board driver
to use this feature.
+static void mcam_clk_set(struct mcam_camera *mcam, int on)
+{
+unsigned int i;
+
+if (on) {
+for (i = 0; i mcam-clk_num; i++) {
+if (mcam-clk[i])
+clk_enable(mcam-clk[i]);
+}
+} else {
+for (i = mcam-clk_num; i 0; i--) {
+if (mcam-clk[i - 1])
+clk_disable(mcam-clk[i - 1]);
+}
+}
+}
A couple of minor comments:
- This function is always called with a constant value for on. It would
be easier to read (and less prone to unfortunate brace errors) if it
were just two functions: mcam_clk_enable() and mcam_clk_disable().
[Albert Wang] OK, that's fine to split it to 2 functions. :)
- I'd write the second for loop as:
for (i = mcal-clk_num - 1; i = 0; i==) {
just to match the values used in the other direction and avoid the
subscript arithmetic.
[Albert Wang] Yes, we can improve it. :)
+static void mcam_init_clk(struct mcam_camera *mcam,
+struct mmp_camera_platform_data *pdata, int init)
So why does an init function have an init parameter? Again, I think
this would be far better split into two functions. Among other things,
that would help to reduce the deep nesting below.
[Albert Wang] Yes, the parameter name is confused.
And we will split this function too. :)
+{
+unsigned int i;
+
+if (NR_MCAM_CLK pdata-clk_num) {
+dev_err(mcam-dev, Too many mcam clocks defined\n);
+mcam-clk_num = 0;
+return;
+}
+
+if (init) {
+for (i = 0; i pdata-clk_num; i++) {
+if (pdata-clk_name[i] != NULL) {
+mcam-clk[i] = devm_clk_get(mcam-dev,
+pdata-clk_name[i]);
+if (IS_ERR(mcam-clk[i])) {
+dev_err(mcam-dev,
+Could not get clk: %s\n,
+pdata-clk_name[i]);
+mcam-clk_num = 0;
+return;
+}
+}
+}
+mcam-clk_num = pdata-clk_num;
+} else
+mcam-clk_num = 0;
+}
Again, minor comments, but I do think the code would be improved by
splitting those functions. Meanwhile:
Acked-by: Jonathan Corbet cor...@lwn.net
jon
Thanks
Albert Wang
86-21-61092656
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH V3 05/15] [media] marvell-ccic: refine mcam_set_contig_buffer function
Hi, Jonathan -Original Message- From: Jonathan Corbet [mailto:cor...@lwn.net] Sent: Monday, 17 December, 2012 00:07 To: Albert Wang Cc: g.liakhovet...@gmx.de; linux-media@vger.kernel.org; Libin Yang Subject: Re: [PATCH V3 05/15] [media] marvell-ccic: refine mcam_set_contig_buffer function On Sat, 15 Dec 2012 17:57:54 +0800 Albert Wang twan...@marvell.com wrote: From: Libin Yang lby...@marvell.com This patch refines mcam_set_contig_buffer() in mcam core It might be nice if the changelog said *why* this was being done - [Albert Wang] We just want to reduce some redundancy code. :) don't worry about insulting my ugly code :) But no biggie... Acked-by: Jonathan Corbet cor...@lwn.net jon Thanks Albert Wang 86-21-61092656 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH V3 06/15] [media] marvell-ccic: add new formats support for marvell-ccic driver
Hi, Jonathan
-Original Message-
From: Jonathan Corbet [mailto:cor...@lwn.net]
Sent: Monday, 17 December, 2012 00:17
To: Albert Wang
Cc: g.liakhovet...@gmx.de; linux-media@vger.kernel.org; Libin Yang
Subject: Re: [PATCH V3 06/15] [media] marvell-ccic: add new formats support for
marvell-ccic driver
On Sat, 15 Dec 2012 17:57:55 +0800
Albert Wang twan...@marvell.com wrote:
From: Libin Yang lby...@marvell.com
This patch adds the new formats support for marvell-ccic.
Once again, just one second-order comment:
+static bool mcam_fmt_is_planar(__u32 pfmt)
+{
+switch (pfmt) {
+case V4L2_PIX_FMT_YUV422P:
+case V4L2_PIX_FMT_YUV420:
+case V4L2_PIX_FMT_YVU420:
+return true;
+}
+return false;
+}
This seems like the kind of thing that would be useful in a number of
places; I'd be tempted to push it up a level and make it available to all
V4L2 drivers. Of course, that means making it work for *all* formats,
which would be a pain.
But, then, I can see some potential future pain if somebody adds a new
format and forgets to tweak this function here. Rather than adding a new
switch, could you put a planar flag into struct mcam_format_struct
instead? That would help to keep all this information together.
[Albert Wang] Yes, it looks make sense, we will think about it in next version.
jon
Thanks
Albert Wang
86-21-61092656
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH V3 07/15] [media] marvell-ccic: add SOF / EOF pair check for marvell-ccic driver
Hi, Jonathan -Original Message- From: Jonathan Corbet [mailto:cor...@lwn.net] Sent: Monday, 17 December, 2012 00:19 To: Albert Wang Cc: g.liakhovet...@gmx.de; linux-media@vger.kernel.org; Libin Yang Subject: Re: [PATCH V3 07/15] [media] marvell-ccic: add SOF / EOF pair check for marvell-ccic driver On Sat, 15 Dec 2012 17:57:56 +0800 Albert Wang twan...@marvell.com wrote: From: Libin Yang lby...@marvell.com This patch adds the SOFx/EOFx pair check for marvell-ccic. When switching format, the last EOF may not arrive when stop streamning. And the EOF will be detected in the next start streaming. Must ensure clear the obsolete frame flags before every really start streaming. obsolete doesn't quite read right; it suggests that the flags only apply to older hardware. I'd suggest left over or some such (in the code comment too). Otherwise seems fine. [Albert Wang] OK, we will change the bad word. :) Acked-by: Jonathan Corbet cor...@lwn.net jon Thanks Albert Wang 86-21-61092656 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH V3 09/15] [media] marvell-ccic: add get_mcam function for marvell-ccic driver
Hi, Jonathan
-Original Message-
From: Jonathan Corbet [mailto:cor...@lwn.net]
Sent: Monday, 17 December, 2012 00:25
To: Albert Wang
Cc: g.liakhovet...@gmx.de; linux-media@vger.kernel.org; Libin Yang
Subject: Re: [PATCH V3 09/15] [media] marvell-ccic: add get_mcam function for
marvell-
ccic driver
On Sat, 15 Dec 2012 17:57:58 +0800
Albert Wang twan...@marvell.com wrote:
This patch adds get_mcam() inline function which is prepared for
adding soc_camera support in marvell-ccic driver
Time for a bikeshed moment: get generally is understood to mean
incrementing a reference count in kernel code. Can it have a name like
vbq_to_mcam() instead?
[Albert Wang] Sure. It looks your name is more professional. :)
Also:
@@ -1073,14 +1073,17 @@ static int mcam_vb_queue_setup(struct vb2_queue *vq,
static void mcam_vb_buf_queue(struct vb2_buffer *vb)
{
struct mcam_vb_buffer *mvb = vb_to_mvb(vb);
-struct mcam_camera *cam = vb2_get_drv_priv(vb-vb2_queue);
+struct mcam_camera *cam = get_mcam(vb-vb2_queue);
struct v4l2_pix_format *fmt = cam-pix_format;
unsigned long flags;
int start;
dma_addr_t dma_handle;
+unsigned long size;
u32 pixel_count = fmt-width * fmt-height;
spin_lock_irqsave(cam-dev_lock, flags);
+size = vb2_plane_size(vb, 0);
+vb2_set_plane_payload(vb, 0, size);
dma_handle = vb2_dma_contig_plane_dma_addr(vb, 0);
BUG_ON(!dma_handle);
start = (cam-state == S_BUFWAIT) !list_empty(cam-buffers);
There is an unrelated change here that belongs in a separate patch.
[Albert Wang] OK
@@ -1138,9 +1141,12 @@ static void mcam_vb_wait_finish(struct vb2_queue *vq)
*/
static int mcam_vb_start_streaming(struct vb2_queue *vq, unsigned int count)
{
-struct mcam_camera *cam = vb2_get_drv_priv(vq);
+struct mcam_camera *cam = get_mcam(vq);
unsigned int frame;
+if (count 2)
+return -EINVAL;
+
Here too - unrelated change.
[Albert Wang] Em, it looks we should add a new patch to contain these changes.
:)
if (cam-state != S_IDLE) {
INIT_LIST_HEAD(cam-buffers);
return -EINVAL;
@@ -1170,7 +1176,7 @@ static int mcam_vb_start_streaming(struct vb2_queue
*vq,
unsigned int count)
static int mcam_vb_stop_streaming(struct vb2_queue *vq)
{
-struct mcam_camera *cam = vb2_get_drv_priv(vq);
+struct mcam_camera *cam = get_mcam(vq);
unsigned long flags;
if (cam-state == S_BUFWAIT) {
@@ -1181,6 +1187,7 @@ static int mcam_vb_stop_streaming(struct vb2_queue *vq)
if (cam-state != S_STREAMING)
return -EINVAL;
mcam_ctlr_stop_dma(cam);
+cam-state = S_IDLE;
...and also here ...
jon
Thanks
Albert Wang
86-21-61092656
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH V3 10/15] [media] marvell-ccic: split mcam-core into 2 parts for soc_camera support
Hi, Jonathan -Original Message- From: Jonathan Corbet [mailto:cor...@lwn.net] Sent: Monday, 17 December, 2012 00:37 To: Albert Wang Cc: g.liakhovet...@gmx.de; linux-media@vger.kernel.org; Libin Yang Subject: Re: [PATCH V3 10/15] [media] marvell-ccic: split mcam-core into 2 parts for soc_camera support On Sat, 15 Dec 2012 17:57:59 +0800 Albert Wang twan...@marvell.com wrote: This patch splits mcam-core into 2 parts to prepare for soc_camera support. The first part remains in mcam-core.c. This part includes the HW operations and vb2 callback functions. The second part is moved to mcam-core-standard.c. This part is relevant with the implementation of using V4L2. OK, I'll confess I'm still not 100% sold on this part. Can I repeat the questions I raised before? - Is the soc_camera mode necessary? Is there something you're trying to do that can't be done without it? Or, at least, does it add sufficient benefit to be worth this work? It would be nice if the reasoning behind this change were put into the changelog. [Albert Wang] We just want to add one more option for user. :) And we split it to 2 parts because we want to keep the original mode. - If the soc_camera change is deemed to be worthwhile, is there anything preventing you from doing it 100% so it's the only mode used? [Albert Wang] No, but current all Marvell platform have used the soc_camera in camera driver. :) So we just hope the marvell-ccic can have this option. :) The split as you've done it here is an improvement over what came before, but it still results in a lot of duplicated code; it also adds a *lot* of symbols to the global namespace. If this is really the only way then we'll find a way to make it work, but I'd like to be sure that we can't do something better. Thanks, jon Thanks Albert Wang 86-21-61092656 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH V3 12/15] [media] marvell-ccic: add soc_camera support in mmp driver
Hi, Jonathan
-Original Message-
From: Jonathan Corbet [mailto:cor...@lwn.net]
Sent: Monday, 17 December, 2012 00:46
To: Albert Wang
Cc: g.liakhovet...@gmx.de; linux-media@vger.kernel.org; Libin Yang
Subject: Re: [PATCH V3 12/15] [media] marvell-ccic: add soc_camera support in
mmp
driver
On Sat, 15 Dec 2012 17:58:01 +0800
Albert Wang twan...@marvell.com wrote:
This patch adds the soc_camera support in the platform driver: mmp-driver.c.
Specified board driver also should be modified to support soc_camera by
passing
some platform datas to platform driver.
Currently the soc_camera mode in mmp driver only supports B_DMA_contig mode.
You do intend to add the other modes (or SG, at least) in the future?
[Albert Wang] Yes, if need we can add the other modes in the future.
--- a/drivers/media/platform/marvell-ccic/Kconfig
+++ b/drivers/media/platform/marvell-ccic/Kconfig
@@ -1,23 +1,45 @@
+config VIDEO_MARVELL_CCIC
+ tristate
+config VIDEO_MRVL_SOC_CAMERA
+ bool
If Linus sees this you'll get an unpleasant reminder that vowels are not
actually in short supply; I'd suggest spelling out MARVELL.
[Albert Wang] Sorry, we will change it.
diff --git a/drivers/media/platform/marvell-ccic/mmp-driver.c
b/drivers/media/platform/marvell-ccic/mmp-driver.c
index 40c243e..cd850f4 100755
--- a/drivers/media/platform/marvell-ccic/mmp-driver.c
+++ b/drivers/media/platform/marvell-ccic/mmp-driver.c
@@ -28,6 +28,10 @@
#include linux/list.h
#include linux/pm.h
#include linux/clk.h
+#include linux/regulator/consumer.h
+#include media/videobuf2-dma-contig.h
+#include media/soc_camera.h
+#include media/soc_mediabus.h
#include mcam-core.h
@@ -40,6 +44,8 @@ struct mmp_camera {
struct platform_device *pdev;
struct mcam_camera mcam;
struct list_head devlist;
+/* will change here */
+struct clk *clk[3]; /* CCIC_GATE, CCIC_RST, CCIC_DBG clocks */
What does that comment mean?
[Albert Wang] It means there are 3 clk setting, gate_clk, rst_clk, dbg_clk.
Forgive me, the name of CCIC_DBG register is not good, but it's our actual
register name. :(
int irq;
};
@@ -144,15 +150,17 @@ static void mmpcam_power_up(struct mcam_camera
*mcam)
* Provide power to the sensor.
*/
mcam_reg_write(mcam, REG_CLKCTRL, 0x6002);
-pdata = cam-pdev-dev.platform_data;
-gpio_set_value(pdata-sensor_power_gpio, 1);
-mdelay(5);
+if (mcam-chip_id == V4L2_IDENT_ARMADA610) {
I'm seeing a lot of these tests being added to the code. I can imagine
more in the future as new chipsets are supported in the driver. Maybe it's
time to add a structure to hide chipset-specific low-level operations? It
would make the code a lot cleaner.
[Albert Wang] OK, we will do it.
Actually, things like mmpcam_power_up() were meant to be exactly that. Can
we just define a different version of this function for different chipsets?
[Albert Wang] Sure.
+pdata = cam-pdev-dev.platform_data;
+gpio_set_value(pdata-sensor_power_gpio, 1);
+mdelay(5);
+/* reset is active low */
+gpio_set_value(pdata-sensor_reset_gpio, 0);
+mdelay(5);
+gpio_set_value(pdata-sensor_reset_gpio, 1);
+mdelay(5);
+}
mcam_reg_clear_bit(mcam, REG_CTRL1, 0x1000);
-gpio_set_value(pdata-sensor_reset_gpio, 0); /* reset is active low */
-mdelay(5);
-gpio_set_value(pdata-sensor_reset_gpio, 1); /* reset is active low */
-mdelay(5);
-
mcam_clk_set(mcam, 1);
}
@@ -165,13 +173,14 @@ static void mmpcam_power_down(struct mcam_camera
*mcam)
*/
iowrite32(0, cam-power_regs + REG_CCIC_DCGCR);
iowrite32(0, cam-power_regs + REG_CCIC_CRCR);
-/*
- * Shut down the sensor.
- */
-pdata = cam-pdev-dev.platform_data;
-gpio_set_value(pdata-sensor_power_gpio, 0);
-gpio_set_value(pdata-sensor_reset_gpio, 0);
-
+if (mcam-chip_id == V4L2_IDENT_ARMADA610) {
Same comment applies here.
+/*
+ * Shut down the sensor.
+ */
+pdata = cam-pdev-dev.platform_data;
+gpio_set_value(pdata-sensor_power_gpio, 0);
+gpio_set_value(pdata-sensor_reset_gpio, 0);
+}
mcam_clk_set(mcam, 0);
jon
Thanks
Albert Wang
86-21-61092656
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH V3 13/15] [media] marvell-ccic: add dma burst mode support in marvell-ccic driver
Hi, Jonathan
-Original Message-
From: Jonathan Corbet [mailto:cor...@lwn.net]
Sent: Monday, 17 December, 2012 00:49
To: Albert Wang
Cc: g.liakhovet...@gmx.de; linux-media@vger.kernel.org; Libin Yang
Subject: Re: [PATCH V3 13/15] [media] marvell-ccic: add dma burst mode support
in
marvell-ccic driver
On Sat, 15 Dec 2012 17:58:02 +0800
Albert Wang twan...@marvell.com wrote:
This patch adds the dma burst size config support for marvell-ccic.
Developer can set the dma burst size in specified board driver.
diff --git a/drivers/media/platform/marvell-ccic/mcam-core.h
b/drivers/media/platform/marvell-ccic/mcam-core.h
index 57442e0..e1025f2 100755
--- a/drivers/media/platform/marvell-ccic/mcam-core.h
+++ b/drivers/media/platform/marvell-ccic/mcam-core.h
@@ -126,6 +126,7 @@ struct mcam_camera {
short int use_smbus;/* SMBUS or straight I2c? */
enum mcam_buffer_mode buffer_mode;
+int burst;
That's a register flag value, seems it should be unsigned (says the guy who
is admittedly sloppy about such things).
[Albert Wang] Yes, you are right.
int mclk_min;
int mclk_src;
int mclk_div;
@@ -411,9 +412,9 @@ int mcam_soc_camera_host_register(struct mcam_camera
*mcam);
#define C1_DESC_3WORD 0x0200/* Three-word descriptors used
*/
#define C1_444ALPHA 0x00f0/* Alpha field in RGB444 */
#define C1_ALPHA_SHFT 20
-#define C1_DMAB32 0x/* 32-byte DMA burst */
-#define C1_DMAB16 0x0200/* 16-byte DMA burst */
-#define C1_DMAB64 0x0400/* 64-byte DMA burst */
+#define C1_DMAB64 0x/* 64-byte DMA burst */
+#define C1_DMAB128 0x0200/* 128-byte DMA burst */
+#define C1_DMAB256 0x0400/* 256-byte DMA burst */
Interesting, did I just get those wrong somehow? Or might they have been
different in the Cafe days?
[Albert Wang] Yes, it looks the original definitions are wrong. We can't find
them in all Marvell documents. :)
Just correct them.
Acked-by: Jonathan Corbet cor...@lwn.net
jon
Thanks
Albert Wang
86-21-61092656
--
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: cannot make this Asus my cinema-u3100miniplusv2 work under linux
On Sun, 16 Dec 2012 22:16:31 +0100 Renato Gallo renatoga...@unixproducts.com wrote: stock one that came with the device http://unixproducts.com/antenna.jpg If this is an antenna with a magnetic base you can try putting it on top of one of those tin boxes for candies like this one: http://img.alibaba.com/wsphoto/v0/456087010/Free-shipping-50pcs-lot-fashion-style-wedding-box-candy-tin-box-jewellery-tin-box-06.jpg I verified that reception does improve a little bit, don't expect miracles tho :) Regards, Antonio -- Antonio Ospite http://ao2.it A: Because it messes up the order in which people normally read text. See http://en.wikipedia.org/wiki/Posting_style Q: Why is top-posting such a bad thing? -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH V3 15/15] [media] marvell-ccic: add 3 frame buffers support in DMA_CONTIG mode
Hi, Jonathan
-Original Message-
From: Jonathan Corbet [mailto:cor...@lwn.net]
Sent: Monday, 17 December, 2012 00:56
To: Albert Wang
Cc: g.liakhovet...@gmx.de; linux-media@vger.kernel.org; Libin Yang
Subject: Re: [PATCH V3 15/15] [media] marvell-ccic: add 3 frame buffers
support in
DMA_CONTIG mode
On Sat, 15 Dec 2012 17:58:04 +0800
Albert Wang twan...@marvell.com wrote:
This patch adds support of 3 frame buffers in DMA-contiguous mode.
In current DMA_CONTIG mode, only 2 frame buffers can be supported.
Actually, Marvell CCIC can support at most 3 frame buffers.
Currently 2 frame buffers mode will be used by default.
To use 3 frame buffers mode, can do:
define MAX_FRAME_BUFS 3
in mcam-core.h
Now that the code supports three buffers properly, is there any reason not
to use that mode by default?
[Albert Wang] Because the original code use the two buffers mode, so we keep
it. :)
Did you test that it works properly if allocation of the third buffer fails?
[Albert Wang] Yes, we test it in our Marvell platforms.
Otherwise looks OK except for one thing:
diff --git a/drivers/media/platform/marvell-ccic/mcam-core.h
b/drivers/media/platform/marvell-ccic/mcam-core.h
index 765d47c..9bf31c8 100755
--- a/drivers/media/platform/marvell-ccic/mcam-core.h
+++ b/drivers/media/platform/marvell-ccic/mcam-core.h
@@ -62,6 +62,13 @@ enum mcam_state {
#define MAX_DMA_BUFS 3
/*
+ * CCIC can support at most 3 frame buffers in DMA_CONTIG buffer mode
+ * 2 - Use Two Buffers mode
+ * 3 - Use Three Buffers mode
+ */
+#define MAX_FRAME_BUFS 2 /* Current marvell-ccic used Two Buffers mode */
+
+/*
* Different platforms work best with different buffer modes, so we
* let the platform pick.
*/
@@ -99,6 +106,10 @@ struct mcam_frame_state {
unsigned int frames;
unsigned int singles;
unsigned int delivered;
+/*
+ * Only usebufs == 2 can enter single buffer mode
+ */
+unsigned int usebufs;
};
What is the purpose of the usebufs field? The code maintains it in
various places, but I don't see anywhere that actually uses that value for
anything.
[Albert Wang] Two buffers mode doesn't need it.
But Three buffers mode need it indicates which conditions we need set the
single buffer flag.
I used tribufs as the name in the previous version, but it looks it's a
confused name when we merged
Two buffers mode and Three buffers mode with same code by removing #ifdef based
on your comments months ago. :)
So we just changed the name with usebufs.
Thanks,
jon
Thanks
Albert Wang
86-21-61092656
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH V3 00/15] [media] marvell-ccic: add soc camera support on marvell-ccic
Hi, Jonathan Thank you very much for taking your weekend time to review our patches! :) Thanks Albert Wang 86-21-61092656 -Original Message- From: Jonathan Corbet [mailto:cor...@lwn.net] Sent: Monday, 17 December, 2012 00:58 To: Albert Wang Cc: g.liakhovet...@gmx.de; linux-media@vger.kernel.org Subject: Re: [PATCH V3 00/15] [media] marvell-ccic: add soc camera support on marvell- ccic On Sat, 15 Dec 2012 17:57:49 +0800 Albert Wang twan...@marvell.com wrote: The following patches series will add soc_camera support on marvell-ccic Overall, this patch set has come a long way - great work! As I commented on the specific patches, I still have some concerns about the soc_camera part of it. There's various quibbles with the rest, but mostly not much that's serious. I think this work is getting close to being ready. Thanks, jon Jonathan Corbet / LWN.net / cor...@lwn.net -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 15/15] [media] marvell-ccic: add 3 frame buffers support in DMA_CONTIG mode
On Sun, 16 Dec 2012 14:34:31 -0800 Albert Wang twan...@marvell.com wrote: What is the purpose of the usebufs field? The code maintains it in various places, but I don't see anywhere that actually uses that value for anything. [Albert Wang] Two buffers mode doesn't need it. But Three buffers mode need it indicates which conditions we need set the single buffer flag. I used tribufs as the name in the previous version, but it looks it's a confused name when we merged Two buffers mode and Three buffers mode with same code by removing #ifdef based on your comments months ago. :) So we just changed the name with usebufs. OK, I misread the code a bit, sorry. I do find the variable confusing still, but it clearly does play a role. I think that using three buffers by default would make sense. I don't think that increased overruns are an unbreakable ABI feature :) Feel free to add my ack to this one. Thanks, jon -- 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 RFC 2/2] V4L: Add V4L2_CID_AUTO_FOCUS_AREA control
Hi Sakari, On 12/16/2012 04:00 PM, Sakari Ailus wrote: diff --git a/Documentation/DocBook/media/v4l/controls.xml b/Documentation/DocBook/media/v4l/controls.xml index 7fe5be1..9d4af8a 100644 --- a/Documentation/DocBook/media/v4l/controls.xml +++ b/Documentation/DocBook/media/v4l/controls.xml @@ -3347,6 +3347,51 @@ use its minimum possible distance for auto focus./entry /row rowentry/entry/row + row id=v4l2-auto-focus-area + entry spanname=id + constantV4L2_CID_AUTO_FOCUS_AREA/constantnbsp;/entry + entryenumnbsp;v4l2_auto_focus_area/entry + /row + rowentry spanname=descrDetermines the area of the frame that +the camera uses for automatic focus. The corresponding coordinates of the +focusing spot or rectangle can be specified and queried using the selection API. +To change the auto focus region of interest applications first select required +mode of this control and then set the rectangle or spot coordinates by means +of theVIDIOC-SUBDEV-S-SELECTION; orVIDIOC-S-SELECTION; ioctl. In order to +trigger again a one shot auto focus with same coordinates applications should +use theconstantV4L2_CID_AUTO_FOCUS_START/constant control. Or alternatively Extra space above.^ +invoke aVIDIOC-SUBDEV-S-SELECTION; or aVIDIOC-S-SELECTION; ioctl again. How about requiring explicit V4L2_CID_AUTO_FOCUS_START? If you need to specify several AF selection windows, then on which one do you start the algorithm? A bitmask control explicitly telling which ones are active would also be needed --- but that's for the future. I think now we just need to ascertain we don't make that difficult. :-) Do you mean only V4L2_CID_AUTO_FOCUS_START should start AF? What about continuous auto-focus (CAF)? In case of the sensor I am working on, face detection can work in both AF and CAF. Continuous AF needs to be an exception to that. It's controlled by V4L2_CID_FOCUS_AUTO, which interestingly doesn't even mention continuous AF. I think it does, maybe not exactly in these words, but continuous automatic focus adjustments doesn't sound like a difference thing to me. Should CAF be restarted (ie stopped and started again), to use face detection? I wonder if V4L2_CID_AUTO_FOCUS_START should be defined to restart CAF when V4L2_CID_FOCUS_AUTO is enabled. I don't think we currently have a way to do that; the current definition says that using V4L2_CID_AUTO_FOCUS_START is undefined then. What do you think? Yes, it might be worth to reconsider this. However, I would like to see real use cases first where V4L2_CID_AUTO_FOCUS_START control is needed in continuous AF mode. All in all, we have V4L2_AUTO_FOCUS_STATUS_FAILED AF status control value and I can't see anything preventing it to be applicable to CAF. So it might make sense to define in the API what needs to be done to bring CAF out of this state. +In the latter case the new pixel coordinates are applied to hardware only when +the focus area control was set to +constantV4L2_AUTO_FOCUS_AREA_RECTANGLE/constant./entry + /row + row + entrytbl spanname=descr cols=2 + tbody valign=top + row + entryconstantV4L2_AUTO_FOCUS_AREA_ALL/constantnbsp;/entry + entryNormal auto focus, the focusing area extends over the +entire frame./entry Does this need to be explicitly specified? Shouldn't the user just choose the largest possible AF window instead? I'd even expect that the AF window might span the whole frame by default (up to driver, hardware etc.). Yes it could be removed. There are two reasons I have left it: 1. If hardware support only AF on spots, V4L2_AUTO_FOCUS_AREA_ALL seems to be more natural than focusing on the whole image. If the hardware only supports spots, then wouldn't V4L2_AUTO_FOCUS_AREA_ALL give false information to the user, suggesting the focus area is actually the whole image? I think Andrzej meant to say that there can be hardware that supports: a. AF where region of interest is whole frame, b. AF where region of interest is some rectangle of size that may be not known exactly, and position (center) of that rectangle only is defined through AF selections. So you would be really switching AF algorithms by manipulating AF selection rectangle only. That said I really think V4L2_AUTO_FOCUS_AREA_ALL is a bad name here. I originally started with single AF mode control and then after discussions we came up with V4L2_AUTO_FOCUS_RANGE and V4L2_AUTO_FOCUS_AREA controls. My motivation behind V4L2_AUTO_FOCUS_AREA_ALL was to provide a menu item that would allow to select normal AF, with supposedly whole frame being the AF region of interest. Normal AF might mean really any area of the frame, so I propose to just replace V4L2_AUTO_FOCUS_AREA_ALL with V4L2_AUTO_FOCUS_AREA_AUTO. This entry would naturally mean that AF area is automatically selected by an ISP and it might not be known exactly to user. Like in case of
[PATCH 1/2] tda10071: add tuner_i2c_addr to struct tda10071_config
The default i2c address for the tuner is 0x14,
allow this to be overridden with a configuration parameter
Signed-off-by: Michael Krufky mkru...@linuxtv.org
Reviewed-by: Antti Palosaari cr...@iki.fi
---
drivers/media/dvb-frontends/tda10071.c |2 +-
drivers/media/dvb-frontends/tda10071.h |6 ++
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/media/dvb-frontends/tda10071.c
b/drivers/media/dvb-frontends/tda10071.c
index 16a4bc5..7103629 100644
--- a/drivers/media/dvb-frontends/tda10071.c
+++ b/drivers/media/dvb-frontends/tda10071.c
@@ -1064,7 +1064,7 @@ static int tda10071_init(struct dvb_frontend *fe)
cmd.args[2] = 0x00;
cmd.args[3] = 0x00;
cmd.args[4] = 0x00;
- cmd.args[5] = 0x14;
+ cmd.args[5] = (priv-cfg.tuner_i2c_addr) ?
priv-cfg.tuner_i2c_addr : 0x14;
cmd.args[6] = 0x00;
cmd.args[7] = 0x03;
cmd.args[8] = 0x02;
diff --git a/drivers/media/dvb-frontends/tda10071.h
b/drivers/media/dvb-frontends/tda10071.h
index 21163c4..a20d5c4 100644
--- a/drivers/media/dvb-frontends/tda10071.h
+++ b/drivers/media/dvb-frontends/tda10071.h
@@ -30,6 +30,12 @@ struct tda10071_config {
*/
u8 i2c_address;
+ /* Tuner I2C address.
+* Default: 0x14
+* Values: 0x14, 0x54, ...
+*/
+ u8 tuner_i2c_addr;
+
/* Max bytes I2C provider can write at once.
* Note: Buffer is taken from the stack currently!
* Default: none, must set
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] cx23885: add basic DVB-S2 support for Hauppauge HVR-4400
Add basic DVB-S2 support for the Hauppauge HVR-4400 PCIe board.
Thanks to Antti Palosaari and Devin Heitmueller for their
suggestions and testing.
Signed-off-by: Michael Krufky mkru...@linuxtv.org
Reviewed-by: Devin Heitmueller dheitmuel...@kernellabs.com
Reviewed-by: Antti Palosaari cr...@iki.fi
---
drivers/media/pci/cx23885/Kconfig |2 ++
drivers/media/pci/cx23885/cx23885-cards.c | 38 -
drivers/media/pci/cx23885/cx23885-dvb.c | 27
drivers/media/pci/cx23885/cx23885.h |1 +
4 files changed, 67 insertions(+), 1 deletion(-)
diff --git a/drivers/media/pci/cx23885/Kconfig
b/drivers/media/pci/cx23885/Kconfig
index eafa114..733d6c8 100644
--- a/drivers/media/pci/cx23885/Kconfig
+++ b/drivers/media/pci/cx23885/Kconfig
@@ -26,6 +26,8 @@ config VIDEO_CX23885
select DVB_STV0900 if MEDIA_SUBDRV_AUTOSELECT
select DVB_DS3000 if MEDIA_SUBDRV_AUTOSELECT
select DVB_STV0367 if MEDIA_SUBDRV_AUTOSELECT
+ select DVB_TDA10071 if MEDIA_SUBDRV_AUTOSELECT
+ select DVB_A8293 if MEDIA_SUBDRV_AUTOSELECT
select MEDIA_TUNER_MT2063 if MEDIA_SUBDRV_AUTOSELECT
select MEDIA_TUNER_MT2131 if MEDIA_SUBDRV_AUTOSELECT
select MEDIA_TUNER_XC2028 if MEDIA_SUBDRV_AUTOSELECT
diff --git a/drivers/media/pci/cx23885/cx23885-cards.c
b/drivers/media/pci/cx23885/cx23885-cards.c
index 6277e145..7a79a17 100644
--- a/drivers/media/pci/cx23885/cx23885-cards.c
+++ b/drivers/media/pci/cx23885/cx23885-cards.c
@@ -572,7 +572,11 @@ struct cx23885_board cx23885_boards[] = {
[CX23885_BOARD_PROF_8000] = {
.name = Prof Revolution DVB-S2 8000,
.portb = CX23885_MPEG_DVB,
- }
+ },
+ [CX23885_BOARD_HAUPPAUGE_HVR4400] = {
+ .name = Hauppauge WinTV-HVR4400,
+ .portb = CX23885_MPEG_DVB,
+ },
};
const unsigned int cx23885_bcount = ARRAY_SIZE(cx23885_boards);
@@ -788,6 +792,22 @@ struct cx23885_subid cx23885_subids[] = {
.subvendor = 0x8000,
.subdevice = 0x3034,
.card = CX23885_BOARD_PROF_8000,
+ }, {
+ .subvendor = 0x0070,
+ .subdevice = 0xc108,
+ .card = CX23885_BOARD_HAUPPAUGE_HVR4400,
+ }, {
+ .subvendor = 0x0070,
+ .subdevice = 0xc138,
+ .card = CX23885_BOARD_HAUPPAUGE_HVR4400,
+ }, {
+ .subvendor = 0x0070,
+ .subdevice = 0xc12a,
+ .card = CX23885_BOARD_HAUPPAUGE_HVR4400,
+ }, {
+ .subvendor = 0x0070,
+ .subdevice = 0xc1f8,
+ .card = CX23885_BOARD_HAUPPAUGE_HVR4400,
},
};
const unsigned int cx23885_idcount = ARRAY_SIZE(cx23885_subids);
@@ -1301,6 +1321,16 @@ void cx23885_gpio_setup(struct cx23885_dev *dev)
/* enable irq */
cx_write(GPIO_ISM, 0x);/* INTERRUPTS active low*/
break;
+ case CX23885_BOARD_HAUPPAUGE_HVR4400:
+ /* GPIO-8 tda10071 demod reset */
+
+ /* Put the parts into reset and back */
+ cx23885_gpio_enable(dev, GPIO_8, 1);
+ cx23885_gpio_clear(dev, GPIO_8);
+ mdelay(100);
+ cx23885_gpio_set(dev, GPIO_8);
+ mdelay(100);
+ break;
}
}
@@ -1509,6 +1539,7 @@ void cx23885_card_setup(struct cx23885_dev *dev)
case CX23885_BOARD_HAUPPAUGE_HVR1210:
case CX23885_BOARD_HAUPPAUGE_HVR1850:
case CX23885_BOARD_HAUPPAUGE_HVR1290:
+ case CX23885_BOARD_HAUPPAUGE_HVR4400:
if (dev-i2c_bus[0].i2c_rc == 0)
hauppauge_eeprom(dev, eeprom+0xc0);
break;
@@ -1581,6 +1612,11 @@ void cx23885_card_setup(struct cx23885_dev *dev)
ts2-ts_clk_en_val = 0x1; /* Enable TS_CLK */
ts2-src_sel_val = CX23885_SRC_SEL_PARALLEL_MPEG_VIDEO;
break;
+ case CX23885_BOARD_HAUPPAUGE_HVR4400:
+ ts1-gen_ctrl_val = 0xc; /* Serial bus + punctured clock */
+ ts1-ts_clk_en_val = 0x1; /* Enable TS_CLK */
+ ts1-src_sel_val = CX23885_SRC_SEL_PARALLEL_MPEG_VIDEO;
+ break;
case CX23885_BOARD_HAUPPAUGE_HVR1250:
case CX23885_BOARD_HAUPPAUGE_HVR1500:
case CX23885_BOARD_HAUPPAUGE_HVR1500Q:
diff --git a/drivers/media/pci/cx23885/cx23885-dvb.c
b/drivers/media/pci/cx23885/cx23885-dvb.c
index 2f5b902..cf84c53 100644
--- a/drivers/media/pci/cx23885/cx23885-dvb.c
+++ b/drivers/media/pci/cx23885/cx23885-dvb.c
@@ -66,6 +66,8 @@
#include stv090x.h
#include stb6100.h
#include stb6100_cfg.h
+#include tda10071.h
+#include a8293.h
static unsigned int debug;
@@ -659,6 +661,20 @@ static struct mt2063_config terratec_mt2063_config[] = {
},
};
+static const struct
[PULL] add basic DVB-S2 support for Hauppauge HVR-4400
Mauro, Please merge: git request-pull 49cc629df16f2a15917800a8579bd9c25c41b634 git://linuxtv.org/mkrufky/hauppauge hvr4400 The following changes since commit 49cc629df16f2a15917800a8579bd9c25c41b634: [media] MAINTAINERS: add si470x-usb+common and si470x-i2c entries (2012-12-11 18:16:13 -0200) are available in the git repository at: git://linuxtv.org/mkrufky/hauppauge hvr4400 for you to fetch changes up to 4c8e64232d4a71e68d68b9093506966c0244a526: cx23885: add basic DVB-S2 support for Hauppauge HVR-4400 (2012-12-16 12:27:25 -0500) Michael Krufky (2): tda10071: add tuner_i2c_addr to struct tda10071_config cx23885: add basic DVB-S2 support for Hauppauge HVR-4400 drivers/media/dvb-frontends/tda10071.c|2 +- drivers/media/dvb-frontends/tda10071.h|6 ++ drivers/media/pci/cx23885/Kconfig |2 ++ drivers/media/pci/cx23885/cx23885-cards.c | 38 +- drivers/media/pci/cx23885/cx23885-dvb.c | 27 +++ drivers/media/pci/cx23885/cx23885.h |1 + 6 files changed, 74 insertions(+), 2 deletions(-) Cheers, Mike -- 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: em28xx: msi Digivox ATSC board id [0db0:8810]
On 12/15/2012 06:21 PM, Frank Schäfer wrote: Matthew, could you please validate your test results and try Mauros patches ? If it doesn't work, please create another USB-log. Sorry it took me so long to test the patch, but the results look promising, I actually got various keycodes! dmesg: http://pyther.net/a/digivox_atsc/dec16/dmesg_remote.txt evtest was also generating output Event: time 1355705906.950551, type 4 (EV_MSC), code 4 (MSC_SCAN), value 61d618e7 Event: time 1355705906.950551, -- SYN_REPORT This is the current patch I'm using: http://pyther.net/a/digivox_atsc/dec16/dmesg_remote.txt What needs to be done to generate a keymap file? Is there anything I can collect or try to do, to get channel scanning working? Just let me know what you need me to do. I really appreciate all the help! Thanks, Matthew -- 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] tda10071: make sure both tuner and demod i2c addresses are specified
display an error message if either tuner_i2c_addr or demod_i2c_addr
are not specified in the tda10071_config structure
Signed-off-by: Michael Krufky mkru...@linuxtv.org
---
drivers/media/dvb-frontends/tda10071.c | 18 +++---
drivers/media/dvb-frontends/tda10071.h |4 ++--
drivers/media/pci/cx23885/cx23885-dvb.c |2 +-
drivers/media/usb/em28xx/em28xx-dvb.c |3 ++-
4 files changed, 20 insertions(+), 7 deletions(-)
diff --git a/drivers/media/dvb-frontends/tda10071.c
b/drivers/media/dvb-frontends/tda10071.c
index 7103629..02f9234 100644
--- a/drivers/media/dvb-frontends/tda10071.c
+++ b/drivers/media/dvb-frontends/tda10071.c
@@ -30,7 +30,7 @@ static int tda10071_wr_regs(struct tda10071_priv *priv, u8
reg, u8 *val,
u8 buf[len+1];
struct i2c_msg msg[1] = {
{
- .addr = priv-cfg.i2c_address,
+ .addr = priv-cfg.demod_i2c_addr,
.flags = 0,
.len = sizeof(buf),
.buf = buf,
@@ -59,12 +59,12 @@ static int tda10071_rd_regs(struct tda10071_priv *priv, u8
reg, u8 *val,
u8 buf[len];
struct i2c_msg msg[2] = {
{
- .addr = priv-cfg.i2c_address,
+ .addr = priv-cfg.demod_i2c_addr,
.flags = 0,
.len = 1,
.buf = reg,
}, {
- .addr = priv-cfg.i2c_address,
+ .addr = priv-cfg.demod_i2c_addr,
.flags = I2C_M_RD,
.len = sizeof(buf),
.buf = buf,
@@ -1202,6 +1202,18 @@ struct dvb_frontend *tda10071_attach(const struct
tda10071_config *config,
goto error;
}
+ /* make sure demod i2c address is specified */
+ if (!config-demod_i2c_addr) {
+ dev_dbg(i2c-dev, %s: invalid demod i2c address!\n,
__func__);
+ goto error;
+ }
+
+ /* make sure tuner i2c address is specified */
+ if (!config-tuner_i2c_addr) {
+ dev_dbg(i2c-dev, %s: invalid tuner i2c address!\n,
__func__);
+ goto error;
+ }
+
/* setup the priv */
priv-i2c = i2c;
memcpy(priv-cfg, config, sizeof(struct tda10071_config));
diff --git a/drivers/media/dvb-frontends/tda10071.h
b/drivers/media/dvb-frontends/tda10071.h
index a20d5c4..bff1c38 100644
--- a/drivers/media/dvb-frontends/tda10071.h
+++ b/drivers/media/dvb-frontends/tda10071.h
@@ -28,10 +28,10 @@ struct tda10071_config {
* Default: none, must set
* Values: 0x55,
*/
- u8 i2c_address;
+ u8 demod_i2c_addr;
/* Tuner I2C address.
-* Default: 0x14
+* Default: none, must set
* Values: 0x14, 0x54, ...
*/
u8 tuner_i2c_addr;
diff --git a/drivers/media/pci/cx23885/cx23885-dvb.c
b/drivers/media/pci/cx23885/cx23885-dvb.c
index cf84c53..a1aae56 100644
--- a/drivers/media/pci/cx23885/cx23885-dvb.c
+++ b/drivers/media/pci/cx23885/cx23885-dvb.c
@@ -662,7 +662,7 @@ static struct mt2063_config terratec_mt2063_config[] = {
};
static const struct tda10071_config hauppauge_tda10071_config = {
- .i2c_address = 0x05,
+ .demod_i2c_addr = 0x05,
.tuner_i2c_addr = 0x54,
.i2c_wr_max = 64,
.ts_mode = TDA10071_TS_SERIAL,
diff --git a/drivers/media/usb/em28xx/em28xx-dvb.c
b/drivers/media/usb/em28xx/em28xx-dvb.c
index 63f2e70..e800881 100644
--- a/drivers/media/usb/em28xx/em28xx-dvb.c
+++ b/drivers/media/usb/em28xx/em28xx-dvb.c
@@ -714,7 +714,8 @@ static struct tda18271_config
em28xx_cxd2820r_tda18271_config = {
};
static const struct tda10071_config em28xx_tda10071_config = {
- .i2c_address = 0x55, /* (0xaa 1) */
+ .demod_i2c_addr = 0x55, /* (0xaa 1) */
+ .tuner_i2c_addr = 0x14,
.i2c_wr_max = 64,
.ts_mode = TDA10071_TS_SERIAL,
.spec_inv = 0,
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] tda18271: add missing entries for qam_7 to tda18271_update_std_map() and tda18271_dump_std_map()
From: Frank Sch�fer fschaefer@googlemail.com Signed-off-by: Frank Sch�fer fschaefer@googlemail.com Signed-off-by: Michael Krufky mkru...@linuxtv.org --- drivers/media/tuners/tda18271-fe.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/media/tuners/tda18271-fe.c b/drivers/media/tuners/tda18271-fe.c index 72c26fd..e778686 100644 --- a/drivers/media/tuners/tda18271-fe.c +++ b/drivers/media/tuners/tda18271-fe.c @@ -1122,6 +1122,7 @@ static int tda18271_dump_std_map(struct dvb_frontend *fe) tda18271_dump_std_item(dvbt_7, dvbt 7); tda18271_dump_std_item(dvbt_8, dvbt 8); tda18271_dump_std_item(qam_6, qam 6 ); + tda18271_dump_std_item(qam_7, qam 7 ); tda18271_dump_std_item(qam_8, qam 8 ); return 0; @@ -1149,6 +1150,7 @@ static int tda18271_update_std_map(struct dvb_frontend *fe, tda18271_update_std(dvbt_7, dvbt 7); tda18271_update_std(dvbt_8, dvbt 8); tda18271_update_std(qam_6, qam 6); + tda18271_update_std(qam_7, qam 7); tda18271_update_std(qam_8, qam 8); return 0; -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] tda18271: add missing entries for qam_7 to tda18271_update_std_map() and tda18271_dump_std_map()
Mauro, Please merge: git request-pull c6c22955f80f2db9614b01fe5a3d1cfcd8b3d848 git://linuxtv.org/mkrufky/tuners tda18271-qam7 The following changes since commit c6c22955f80f2db9614b01fe5a3d1cfcd8b3d848: [media] dma-mapping: fix dma_common_get_sgtable() conditional compilation (2012-11-27 09:42:31 -0200) are available in the git repository at: git://linuxtv.org/mkrufky/tuners tda18271-qam7 for you to fetch changes up to 6554906af8c145b4fa8d4ea1b9c98c20322dd132: tda18271: add missing entries for qam_7 to tda18271_update_std_map() and tda18271_dump_std_map() (2012-12-04 14:14:26 -0500) Frank Sch�fer (1): tda18271: add missing entries for qam_7 to tda18271_update_std_map() and tda18271_dump_std_map() drivers/media/tuners/tda18271-fe.c |2 ++ 1 file changed, 2 insertions(+) Regards, Mike On Sun, Dec 16, 2012 at 8:17 PM, Michael Krufky mkru...@linuxtv.org wrote: From: Frank Schäfer fschaefer@googlemail.com Signed-off-by: Frank Schäfer fschaefer@googlemail.com Signed-off-by: Michael Krufky mkru...@linuxtv.org --- drivers/media/tuners/tda18271-fe.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/media/tuners/tda18271-fe.c b/drivers/media/tuners/tda18271-fe.c index 72c26fd..e778686 100644 --- a/drivers/media/tuners/tda18271-fe.c +++ b/drivers/media/tuners/tda18271-fe.c @@ -1122,6 +1122,7 @@ static int tda18271_dump_std_map(struct dvb_frontend *fe) tda18271_dump_std_item(dvbt_7, dvbt 7); tda18271_dump_std_item(dvbt_8, dvbt 8); tda18271_dump_std_item(qam_6, qam 6 ); + tda18271_dump_std_item(qam_7, qam 7 ); tda18271_dump_std_item(qam_8, qam 8 ); return 0; @@ -1149,6 +1150,7 @@ static int tda18271_update_std_map(struct dvb_frontend *fe, tda18271_update_std(dvbt_7, dvbt 7); tda18271_update_std(dvbt_8, dvbt 8); tda18271_update_std(qam_6, qam 6); + tda18271_update_std(qam_7, qam 7); tda18271_update_std(qam_8, qam 8); return 0; -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PULL] tda18271: add missing entries for qam_7 to tda18271_update_std_map() and tda18271_dump_std_map()
Please pardon the previous email... Mauro, Please merge: The following changes since commit c6c22955f80f2db9614b01fe5a3d1cfcd8b3d848: [media] dma-mapping: fix dma_common_get_sgtable() conditional compilation (2012-11-27 09:42:31 -0200) are available in the git repository at: git://linuxtv.org/mkrufky/tuners tda18271-qam7 for you to fetch changes up to 6554906af8c145b4fa8d4ea1b9c98c20322dd132: tda18271: add missing entries for qam_7 to tda18271_update_std_map() and tda18271_dump_std_map() (2012-12-04 14:14:26 -0500) Frank Sch�fer (1): tda18271: add missing entries for qam_7 to tda18271_update_std_map() and tda18271_dump_std_map() drivers/media/tuners/tda18271-fe.c |2 ++ 1 file changed, 2 insertions(+) Cheers, Mike -- 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: em28xx: msi Digivox ATSC board id [0db0:8810]
On 12/17/2012 03:09 AM, Matthew Gyurgyik wrote: On 12/15/2012 06:21 PM, Frank Schäfer wrote: Matthew, could you please validate your test results and try Mauros patches ? If it doesn't work, please create another USB-log. Sorry it took me so long to test the patch, but the results look promising, I actually got various keycodes! dmesg: http://pyther.net/a/digivox_atsc/dec16/dmesg_remote.txt evtest was also generating output Event: time 1355705906.950551, type 4 (EV_MSC), code 4 (MSC_SCAN), value 61d618e7 Event: time 1355705906.950551, -- SYN_REPORT This is the current patch I'm using: http://pyther.net/a/digivox_atsc/dec16/dmesg_remote.txt What needs to be done to generate a keymap file? Is there anything I can collect or try to do, to get channel scanning working? Just let me know what you need me to do. I really appreciate all the help! You don't need to do nothing as that remote is already there. Just ensure buttons are same and we are happy. http://lxr.free-electrons.com/source/drivers/media/IR/keymaps/rc-msi-digivox-iii.c?v=2.6.37 RC_MAP_MSI_DIGIVOX_III should be added to your device profile in order to load correct keytable by default. You could test it easily, just add following definition .ir_codes = RC_MAP_MSI_DIGIVOX_III, to em28xx-cards.c board config and it is all. regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: em28xx: msi Digivox ATSC board id [0db0:8810]
On 12/16/2012 08:26 PM, Antti Palosaari wrote: On 12/17/2012 03:09 AM, Matthew Gyurgyik wrote: On 12/15/2012 06:21 PM, Frank Schäfer wrote: Matthew, could you please validate your test results and try Mauros patches ? If it doesn't work, please create another USB-log. Sorry it took me so long to test the patch, but the results look promising, I actually got various keycodes! dmesg: http://pyther.net/a/digivox_atsc/dec16/dmesg_remote.txt evtest was also generating output Event: time 1355705906.950551, type 4 (EV_MSC), code 4 (MSC_SCAN), value 61d618e7 Event: time 1355705906.950551, -- SYN_REPORT This is the current patch I'm using: http://pyther.net/a/digivox_atsc/dec16/dmesg_remote.txt What needs to be done to generate a keymap file? Is there anything I can collect or try to do, to get channel scanning working? Just let me know what you need me to do. I really appreciate all the help! You don't need to do nothing as that remote is already there. Just ensure buttons are same and we are happy. http://lxr.free-electrons.com/source/drivers/media/IR/keymaps/rc-msi-digivox-iii.c?v=2.6.37 RC_MAP_MSI_DIGIVOX_III should be added to your device profile in order to load correct keytable by default. You could test it easily, just add following definition .ir_codes = RC_MAP_MSI_DIGIVOX_III, to em28xx-cards.c board config and it is all. regards Antti Maybe I'm missing something but these are different key codes and lengths. tux:~ $ echo 0x61d643bc | wc -c # my dmesg dump 11 tux:~ $ echo 0x61d601 | wc -c # DIGIVOX mini III 9 As I understand it, this was the whole reason for the patches that Mauros wrote. Regards, Matthew -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH V3 15/15] [media] marvell-ccic: add 3 frame buffers support in DMA_CONTIG mode
Hi, Jonathan -Original Message- From: Jonathan Corbet [mailto:cor...@lwn.net] Sent: Monday, 17 December, 2012 06:55 To: Albert Wang Cc: g.liakhovet...@gmx.de; linux-media@vger.kernel.org; Libin Yang Subject: Re: [PATCH V3 15/15] [media] marvell-ccic: add 3 frame buffers support in DMA_CONTIG mode On Sun, 16 Dec 2012 14:34:31 -0800 Albert Wang twan...@marvell.com wrote: What is the purpose of the usebufs field? The code maintains it in various places, but I don't see anywhere that actually uses that value for anything. [Albert Wang] Two buffers mode doesn't need it. But Three buffers mode need it indicates which conditions we need set the single buffer flag. I used tribufs as the name in the previous version, but it looks it's a confused name when we merged Two buffers mode and Three buffers mode with same code by removing #ifdef based on your comments months ago. :) So we just changed the name with usebufs. OK, I misread the code a bit, sorry. I do find the variable confusing still, but it clearly does play a role. I think that using three buffers by default would make sense. I don't think that increased overruns are an unbreakable ABI feature :) [Albert Wang] OK, we can change the default to three buffers mode. Feel free to add my ack to this one. Thanks, jon Thanks Albert Wang 86-21-61092656 -- 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
