Re: [PATCH V2 1/3] saa7115: move the autodetection code out of the probe function
On Fri, May 03, 2013 at 09:08:16AM -0300, Mauro Carvalho Chehab wrote: Em 03-05-2013 08:20, Ezequiel Garcia escreveu: Hi Jon, On Fri, May 03, 2013 at 08:58:46AM +0200, Jon Arne Jørgensen wrote: [...] You can read more about this in Documentation/SubmittingPatches. I just re-read SubmittingPatches. I couldn't see that there is anything wrong with multiple sign-off's. Indeed there isn't anything wrong with multiple SOBs tags, but they're used a bit differently than this. Quote: The Signed-off-by: tag indicates that the signer was involved in the development of the patch, or that he/she was in the patch's delivery path. Ah, I see your point. @Mauro, perhaps you can explain this better then me? The SOB is used mainly to describe the patch flow. Each one that touched on a patch attests that: Developer's Certificate of Origin 1.1 By making a contribution to this project, I certify that: (a) The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file; or (b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same open source license (unless I am permitted to submit under a different license), as indicated in the file; or (c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it. (d) I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the open source license(s) involved. In other words, it tracks the custody chain, with is typically one of the alternatives below[1]: Author - maintainer's tree - upstream Author - sub-maintainer's tree - maintainer's tree - upstream Author - driver's maintainer - maintainer's tree - upstream Author - driver's maintainer - sub-maintainer's tree - maintainer's tree - upstream\ In this specific case, as patches 1 and 2 are identical to the ones I submitted, the right way would be for you both to just reply to my original e-mail with your tested-by or reviewed-by. That patches will then be applied (either directly or via Hverkuil's tree, as he is the sub-maintainer for those I2C drivers). The patch you submitted lacked all register setup so there wasn't that much to test without the stuff I added in the third patch in this series. Is there any way to accnowledge this when I reply to your patch with tested-by? Should I maybe add the third patch in this series into that reply? Also, when I post the next RFC for my smi2021 driver that depends on this patch. Are there any correct way to mention that dependency in the smi2021 patch? Best, Jon Arne I hope that helps to clarify it. Regards, Mauro [1] when the driver is developed/patched internally on some company's trees, it is possible to have there also the SOBs for that company's internal maintainers. There are also some other corner cases, like patches that are sent in non-public mailing lists or in private, where everybody in the custody chain sign it. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-media] Re: [linux-media] stb0899: no lock on dvb-s2 transponders in SCR environment
Hi, Am 27.04.2013 16:51, schrieb Klaus Schmidinger: On 27.04.2013 14:14, Reinhard Nissl wrote: Hi, my stb0899 card works properly on dvb-s and dvb-s2 transponders when using a direct port on my sat multiswitch. When using a SCR port on that multiswitch and changing VDR's config files accordingly, it only locks on dvb-s transponders. A SCR converts the selected transponder's frequency after the LNB (IF1) to a fixed frequency (for example 1076 MHz) by mixing the signal with a local oscialator frequency above IF1 so that the lower sideband of the mixing product appears at 1076 MHz. The lower sideband's spectrum is mirrored compared to the upper sideband, which is identical to the original spectrum on the original IF1. Could that be the reason why the stb0899 cannot lock on dvb-s2 transponders in an SCR environment? Any ideas on how to get a lock on dvb-s2 transponders? Just wanted to let you know that I can confirm the problem with the stb0899. On my TT S2-6400 I can receive DVB-S and DVB-S2 just fine with SCR. During development of SCR support for VDR I guess I did all tests with the 6400, so I didn't come across this problem. However, as a reaction to your posting I explicitly tested it with my budget cards, and there I indeed can only tune to DVB-S transponders. No idea how to solve this, though... Well, as mentioned above, it really has to do with the lower side band, which is mirrored compared to the original spectrum. The phase of the Q component of the signal is usually 90 ° behind the I component. Due to the mirroring, the phase changes its sign which means, the Q component is now 90 ° ahead of the I component with the result that the decoded symbols do not match the expected code points. To fix the phase relationship between I and Q component, I and Q inputs need to be swapped. This can done by enabling inversion. I first thought that VDR's channel parameter inversion could do the trick, but it looks to me like it is either not supported by the driver or does/means something different (have to learn alot more about mixing and signal processing regarding DVB). Anyway, digging through the code I found that the driver supports inversion and that this behaviour is a compiled in configuration option for the TT-3200 board. The driver even supports automatic inversion, so that's the way I got it finally working for now (see attached patch). Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:rni...@gmx.de --- pci/ttpci/budget-ci.c.orig 2013-05-05 13:18:16.203930908 +0200 +++ pci/ttpci/budget-ci.c 2013-05-05 13:18:26.576914170 +0200 @@ -1280,7 +1280,7 @@ static struct stb0899_config tt3200_conf .demod_address = 0x68, .xtal_freq = 2700, - .inversion = IQ_SWAP_ON, /* 1 */ + .inversion = IQ_SWAP_AUTO, /* 2 */ .lo_clk = 7650, .hi_clk = 9900,
Re: [PATCH V2 1/3] saa7115: move the autodetection code out of the probe function
Em Sun, 5 May 2013 10:20:08 +0200 Jon Arne Jørgensen jona...@jonarne.no escreveu: On Fri, May 03, 2013 at 09:08:16AM -0300, Mauro Carvalho Chehab wrote: Em 03-05-2013 08:20, Ezequiel Garcia escreveu: Hi Jon, On Fri, May 03, 2013 at 08:58:46AM +0200, Jon Arne Jørgensen wrote: [...] You can read more about this in Documentation/SubmittingPatches. I just re-read SubmittingPatches. I couldn't see that there is anything wrong with multiple sign-off's. Indeed there isn't anything wrong with multiple SOBs tags, but they're used a bit differently than this. Quote: The Signed-off-by: tag indicates that the signer was involved in the development of the patch, or that he/she was in the patch's delivery path. Ah, I see your point. @Mauro, perhaps you can explain this better then me? The SOB is used mainly to describe the patch flow. Each one that touched on a patch attests that: Developer's Certificate of Origin 1.1 By making a contribution to this project, I certify that: (a) The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file; or (b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same open source license (unless I am permitted to submit under a different license), as indicated in the file; or (c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it. (d) I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the open source license(s) involved. In other words, it tracks the custody chain, with is typically one of the alternatives below[1]: Author - maintainer's tree - upstream Author - sub-maintainer's tree - maintainer's tree - upstream Author - driver's maintainer - maintainer's tree - upstream Author - driver's maintainer - sub-maintainer's tree - maintainer's tree - upstream\ In this specific case, as patches 1 and 2 are identical to the ones I submitted, the right way would be for you both to just reply to my original e-mail with your tested-by or reviewed-by. That patches will then be applied (either directly or via Hverkuil's tree, as he is the sub-maintainer for those I2C drivers). The patch you submitted lacked all register setup so there wasn't that much to test without the stuff I added in the third patch in this series. That's by purpose. I didn't want to touch on the things you authored/tested: the gm7113c special setup. I also didn't want to merge a pure cosmetic change that re-group the logic with the new table setup for gm7113c, as we do prefer to have one logical change by patch. In any case, the patches can be tested as a hole or in separate. The first one is a cosmetic patch, moving things into a separate function. A tested-by there means that it didn't break anything. The second one detects the saa7113 clone. Again, a tested by means that it does what it proposes: detect this new variant. Of course, your third patch is needed in order to make gm7113c to work. That's basically why I didn't merge them on my tree yet. Is there any way to accnowledge this when I reply to your patch with tested-by? Feel free to add your notes when replying to the email. We generally don't add such notes at git history to avoid polluting it, but they are stored at patchwork, and at the list archives. For example: https://patchwork.linuxtv.org/patch/15524/ In this case, one patch touched on several different drivers. Some drivers' maintainers replied with their ack, but noted that their ack are limited to just their own stuff[1]. [1] they did it by cutting-off the diffstat lines for the drivers they don't maintain. So, Prabhakar acked for DaVinci; Guennadi acked for sh_vou/soc_camera changes. Should I maybe add the third patch in this series into that reply? Yeah, you can do that. If you're using git send-email, it allows you to put the message ID of a message on your reply. This way, you can bind your patch to an existing patch thread. You may also add a note on your patch for the maintainer, after your SOB, like: ... Signed-off-by: my name my@email --- Note: please apply this one together
Re: [PATCH v2 1/2] saa7115: move the autodetection code out of the probe function
On Fri, Apr 26, 2013 at 11:22:47AM -0300, Mauro Carvalho Chehab wrote:
As we're now seeing other variants from chinese clones, like
gm1113c, we'll need to add more bits at the detection code.
So, move it into a separate function.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
Tested-by: Jon Arne Jørgensen jona...@jonarne.no
---
drivers/media/i2c/saa7115.c | 133
+++-
1 file changed, 83 insertions(+), 50 deletions(-)
diff --git a/drivers/media/i2c/saa7115.c b/drivers/media/i2c/saa7115.c
index 52c717d..9340e0c 100644
--- a/drivers/media/i2c/saa7115.c
+++ b/drivers/media/i2c/saa7115.c
@@ -1573,46 +1573,103 @@ static const struct v4l2_subdev_ops saa711x_ops = {
/* --- */
+/**
+ * saa711x_detect_chip - Detects the saa711x (or clone) variant
+ * @client: I2C client structure.
+ * @id: I2C device ID structure.
+ * @name:Name of the device to be filled.
+ * @size:Size of the name var.
+ *
+ * Detects the Philips/NXP saa711x chip, or some clone of it.
+ * if 'id' is NULL or id-driver_data is equal to 1, it auto-probes
+ * the analog demod.
+ * If the tuner is not found, it returns -ENODEV.
+ * If auto-detection is disabled and the tuner doesn't match what it was
+ * requred, it returns -EINVAL and fills 'name'.
+ * If the chip is found, it returns the chip ID and fills 'name'.
+ */
+static int saa711x_detect_chip(struct i2c_client *client,
+const struct i2c_device_id *id,
+char *name, unsigned size)
+{
+ char chip_ver[size - 1];
+ char chip_id;
+ int i;
+ int autodetect;
+
+ autodetect = !id || id-driver_data == 1;
+
+ /* Read the chip version register */
+ for (i = 0; i size - 1; i++) {
+ i2c_smbus_write_byte_data(client, 0, i);
+ chip_ver[i] = i2c_smbus_read_byte_data(client, 0);
+ name[i] = (chip_ver[i] 0x0f) + '0';
+ if (name[i] '9')
+ name[i] += 'a' - '9' - 1;
+ }
+ name[i] = '\0';
+
+ /* Check if it is a Philips/NXP chip */
+ if (!memcmp(name + 1, f711, 4)) {
+ chip_id = name[5];
+ snprintf(name, size, saa711%c, chip_id);
+
+ if (!autodetect strcmp(name, id-name))
+ return -EINVAL;
+
+ switch (chip_id) {
+ case '1':
+ if (chip_ver[0] 0xf0) {
+ snprintf(name, size, saa711%ca, chip_id);
+ v4l_info(client, saa7111a variant found\n);
+ return V4L2_IDENT_SAA7111A;
+ }
+ return V4L2_IDENT_SAA7111;
+ case '3':
+ return V4L2_IDENT_SAA7113;
+ case '4':
+ return V4L2_IDENT_SAA7114;
+ case '5':
+ return V4L2_IDENT_SAA7115;
+ case '8':
+ return V4L2_IDENT_SAA7118;
+ default:
+ v4l2_info(client,
+ WARNING: Philips/NXP chip unknown - Falling
back to saa7111\n);
+ return V4L2_IDENT_SAA7111;
+ }
+ }
+
+ /* Chip was not discovered. Return its ID and don't bind */
+ v4l_dbg(1, debug, client, chip %*ph @ 0x%x is unknown.\n,
+ 16, chip_ver, client-addr 1);
+ return -ENODEV;
+}
+
static int saa711x_probe(struct i2c_client *client,
const struct i2c_device_id *id)
{
struct saa711x_state *state;
struct v4l2_subdev *sd;
struct v4l2_ctrl_handler *hdl;
- int i;
+ int ident;
char name[17];
- char chip_id;
- int autodetect = !id || id-driver_data == 1;
/* Check if the adapter supports the needed features */
if (!i2c_check_functionality(client-adapter, I2C_FUNC_SMBUS_BYTE_DATA))
return -EIO;
- for (i = 0; i 0x0f; i++) {
- i2c_smbus_write_byte_data(client, 0, i);
- name[i] = (i2c_smbus_read_byte_data(client, 0) 0x0f) + '0';
- if (name[i] '9')
- name[i] += 'a' - '9' - 1;
- }
- name[i] = '\0';
-
- chip_id = name[5];
-
- /* Check whether this chip is part of the saa711x series */
- if (memcmp(name + 1, f711, 4)) {
- v4l_dbg(1, debug, client, chip found @ 0x%x (ID %s) does not
match a known saa711x chip.\n,
- client-addr 1, name);
+ ident = saa711x_detect_chip(client, id, name, sizeof(name));
+ if (ident == -EINVAL) {
+ /* Chip exists, but doesn't match */
+ v4l_warn(client, found %s while %s was expected\n,
+ name, id-name);
Re: [PATCH v2 2/2] saa7115: add detection code for gm7113c
On Fri, Apr 26, 2013 at 11:22:48AM -0300, Mauro Carvalho Chehab wrote:
Adds a code that (auto)detects gm7113c clones. The auto-detection
here is not perfect, as, on contrary to what it would be expected
by looking into its datasheets some devices would return, instead:
saa7115 0-0025: chip 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 @
0x4a is unknown
(found on a device labeled as GM7113C 1145 by Ezequiel Garcia)
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
Tested-by: Jon Arne Jørgensen jona...@jonarne.no
---
drivers/media/i2c/saa7115.c | 36
include/media/v4l2-chip-ident.h | 2 ++
2 files changed, 38 insertions(+)
diff --git a/drivers/media/i2c/saa7115.c b/drivers/media/i2c/saa7115.c
index 9340e0c..950a536 100644
--- a/drivers/media/i2c/saa7115.c
+++ b/drivers/media/i2c/saa7115.c
@@ -1640,6 +1640,36 @@ static int saa711x_detect_chip(struct i2c_client
*client,
}
}
+ /* Check if it is a gm7113c */
+ if (!memcmp(name, , 4)) {
+ chip_id = 0;
+ for (i = 0; i 4; i++) {
+ chip_id = chip_id 1;
+ chip_id |= (chip_ver[i] 0x80) ? 1 : 0;
+ }
+
+ /*
+ * Note: From the datasheet, only versions 1 and 2
+ * exists. However, tests on a device labeled as:
+ * GM7113C 1145 returned 10 on all 16 chip
+ * version (reg 0x00) reads. So, we need to also
+ * accept at least verion 0. For now, let's just
+ * assume that a device that returns for
+ * the lower nibble is a gm7113c.
+ */
+
+ strlcpy(name, gm7113c, size);
+
+ if (!autodetect strcmp(name, id-name))
+ return -EINVAL;
+
+ v4l_dbg(1, debug, client,
+ It seems to be a %s chip (%*ph) @ 0x%x.\n,
+ name, 16, chip_ver, client-addr 1);
+
+ return V4L2_IDENT_GM7113C;
+ }
+
/* Chip was not discovered. Return its ID and don't bind */
v4l_dbg(1, debug, client, chip %*ph @ 0x%x is unknown.\n,
16, chip_ver, client-addr 1);
@@ -1669,6 +1699,11 @@ static int saa711x_probe(struct i2c_client *client,
if (ident 0)
return ident;
+ if (ident == V4L2_IDENT_GM7113C) {
+ v4l_warn(client, %s not yet supported\n, name);
+ return -ENODEV;
+ }
+
strlcpy(client-name, name, sizeof(client-name));
state = kzalloc(sizeof(struct saa711x_state), GFP_KERNEL);
@@ -1756,6 +1791,7 @@ static const struct i2c_device_id saa711x_id[] = {
{ saa7114, 0 },
{ saa7115, 0 },
{ saa7118, 0 },
+ { gm7113c, 0 },
{ }
};
MODULE_DEVICE_TABLE(i2c, saa711x_id);
diff --git a/include/media/v4l2-chip-ident.h b/include/media/v4l2-chip-ident.h
index c259b36..543f89c 100644
--- a/include/media/v4l2-chip-ident.h
+++ b/include/media/v4l2-chip-ident.h
@@ -52,6 +52,8 @@ enum {
V4L2_IDENT_SAA7115 = 105,
V4L2_IDENT_SAA7118 = 108,
+ V4L2_IDENT_GM7113C = 140,
+
/* module saa7127: reserved range 150-199 */
V4L2_IDENT_SAA7127 = 157,
V4L2_IDENT_SAA7129 = 159,
--
1.8.1.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
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
cron job: media_tree daily build: WARNINGS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Sun May 5 19:00:23 CEST 2013 git branch: test git hash: 02615ed5e1b2283db2495af3cf8f4ee172c77d80 gcc version:i686-linux-gcc (GCC) 4.7.2 host hardware: x86_64 host os:3.8-3.slh.2-amd64 linux-git-arm-davinci: OK linux-git-arm-exynos: WARNINGS linux-git-arm-omap: WARNINGS linux-git-blackfin: WARNINGS linux-git-i686: OK linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.31.14-i686: WARNINGS linux-2.6.32.27-i686: WARNINGS linux-2.6.33.7-i686: WARNINGS linux-2.6.34.7-i686: WARNINGS linux-2.6.35.9-i686: WARNINGS linux-2.6.36.4-i686: WARNINGS linux-2.6.37.6-i686: WARNINGS linux-2.6.38.8-i686: WARNINGS linux-2.6.39.4-i686: WARNINGS linux-3.0.60-i686: WARNINGS linux-3.1.10-i686: WARNINGS linux-3.2.37-i686: WARNINGS linux-3.3.8-i686: WARNINGS linux-3.4.27-i686: WARNINGS linux-3.5.7-i686: WARNINGS linux-3.6.11-i686: WARNINGS linux-3.7.4-i686: WARNINGS linux-3.8-i686: OK linux-3.9-rc1-i686: OK linux-2.6.31.14-x86_64: WARNINGS linux-2.6.32.27-x86_64: WARNINGS linux-2.6.33.7-x86_64: WARNINGS linux-2.6.34.7-x86_64: WARNINGS linux-2.6.35.9-x86_64: WARNINGS linux-2.6.36.4-x86_64: WARNINGS linux-2.6.37.6-x86_64: WARNINGS linux-2.6.38.8-x86_64: WARNINGS linux-2.6.39.4-x86_64: WARNINGS linux-3.0.60-x86_64: WARNINGS linux-3.1.10-x86_64: WARNINGS linux-3.2.37-x86_64: WARNINGS linux-3.3.8-x86_64: WARNINGS linux-3.4.27-x86_64: WARNINGS linux-3.5.7-x86_64: WARNINGS linux-3.6.11-x86_64: WARNINGS linux-3.7.4-x86_64: WARNINGS linux-3.8-x86_64: OK linux-3.9-rc1-x86_64: OK apps: WARNINGS spec-git: OK 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 Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] drm/udl: avoid swiotlb for imported vmap buffers.
However if we don't set a dma mask on the usb device, the mapping ends up using swiotlb on machines that have it enabled, which is less than desireable. Signed-off-by: Dave Airlie airl...@redhat.com Fyi for everyone else who was not on irc when DaveI discussed this: This really shouldn't be required and I think the real issue is that udl creates a dma_buf attachement (which is needed for device dma only), but only really wants to do cpu access through vmap/kmap. So not attached the device should be good enough. Cc'ing a few more lists for better fyi ;-) Though I've looked at this a bit more, and since I want to be able to expose shared objects as proper GEM objects from the import side I really need that list of pages. So it looks like this won't really fly. Dave. -- 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
MSI DigiVox Trio support?
Hi, I bought some MSI DigiVox trio. I made a page for it on the wiki: http://linuxtv.org/wiki/index.php/MSI_DigiVox_Trio So what I know is.. It shares several (if not all? maybe a clone?) components with the PCTV Quatrostick 520e. There was once some support (at least DVB-C) in em28xx-new. Is there anything I can do now? I can't really code, but can copypast. I could probably make a machine with this stick plugged in available through SSH. Any hope? Best regards, Pim -- 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
