Re: [PATCH v2 6/6] devicetree: bindings: Document Renesas JPEG Processing Unit.
On Wednesday 27 August 2014 14:15:01 Simon Horman wrote: On Tue, Aug 26, 2014 at 11:27:43AM +0200, Geert Uytterhoeven wrote: On Tue, Aug 26, 2014 at 11:01 AM, Simon Horman ho...@verge.net.au wrote: On Tue, Aug 26, 2014 at 10:03:34AM +0200, Geert Uytterhoeven wrote: On Tue, Aug 26, 2014 at 1:57 AM, Simon Horman wrote: On Mon, Aug 25, 2014 at 02:59:46PM +0200, Geert Uytterhoeven wrote: On Mon, Aug 25, 2014 at 2:35 PM, Mikhail Ulyanov wrote: + - compatible: should containg one of the following: + - renesas,jpu-r8a7790 for R-Car H2 + - renesas,jpu-r8a7791 for R-Car M2 + - renesas,jpu-gen2 for R-Car second generation Isn't renesas,jpu-gen2 meant as a fallback? I.e. the DTS should have one of '7790 and '7791, AND the gen2 fallback, so we can make the driver match against '7790 and '7791 is we find out about an incompatibility. Is there a document that clearly states that there is such a thing as jpu-gen2 in hardware? If not I would prefer not to add a binding for it. We do have a document that describes the JPEG Processing Unit (JPU), as found in the following members of the Second Generation R-Car Series Products: R-Car H2, R-Car M2-W, R-Car M2-N, and R-Car V2H. Oh, that is nice :) From my point of view that ticks a lot of boxes. But I wonder if we can come up with a better name than jpu,-gen2. jpu-rcar-gen2? I guess that is a slight improvement. But suppose some gen2 SoC exists or comes to exists that has different IP. Suppose there is more than one that same the same IP that is different to the SoCs covered by the existing compat string? That's exactly the information we need to request from the hardware team :-) -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 6/6] devicetree: bindings: Document Renesas JPEG Processing Unit.
On Wed, Aug 27, 2014 at 08:06:10AM +0200, Laurent Pinchart wrote: On Wednesday 27 August 2014 14:15:01 Simon Horman wrote: On Tue, Aug 26, 2014 at 11:27:43AM +0200, Geert Uytterhoeven wrote: On Tue, Aug 26, 2014 at 11:01 AM, Simon Horman ho...@verge.net.au wrote: On Tue, Aug 26, 2014 at 10:03:34AM +0200, Geert Uytterhoeven wrote: On Tue, Aug 26, 2014 at 1:57 AM, Simon Horman wrote: On Mon, Aug 25, 2014 at 02:59:46PM +0200, Geert Uytterhoeven wrote: On Mon, Aug 25, 2014 at 2:35 PM, Mikhail Ulyanov wrote: + - compatible: should containg one of the following: + - renesas,jpu-r8a7790 for R-Car H2 + - renesas,jpu-r8a7791 for R-Car M2 + - renesas,jpu-gen2 for R-Car second generation Isn't renesas,jpu-gen2 meant as a fallback? I.e. the DTS should have one of '7790 and '7791, AND the gen2 fallback, so we can make the driver match against '7790 and '7791 is we find out about an incompatibility. Is there a document that clearly states that there is such a thing as jpu-gen2 in hardware? If not I would prefer not to add a binding for it. We do have a document that describes the JPEG Processing Unit (JPU), as found in the following members of the Second Generation R-Car Series Products: R-Car H2, R-Car M2-W, R-Car M2-N, and R-Car V2H. Oh, that is nice :) From my point of view that ticks a lot of boxes. But I wonder if we can come up with a better name than jpu,-gen2. jpu-rcar-gen2? I guess that is a slight improvement. But suppose some gen2 SoC exists or comes to exists that has different IP. Suppose there is more than one that same the same IP that is different to the SoCs covered by the existing compat string? That's exactly the information we need to request from the hardware team :-) Agreed. -- 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] [media] v4l2-pci-skeleton: Only build if PCI is available
On Tue, Aug 26, 2014 at 01:08:39PM -0700, Randy Dunlap wrote: On 08/26/14 12:59, Randy Dunlap wrote: On 08/26/14 12:26, Mark Brown wrote: No, it's not - if it's going to depend on COMPILE_TEST at all it need to be a hard dependency. How about just drop COMPILE_TEST? This code only builds if someone enabled BUILD_DOCSRC. That should be enough (along with PCI and some VIDEO kconfig symbols) to qualify it. I'll add BUILD_DOCSRC to the depends list in the Kconfig file... OK, that symbol probably does the job - I wasn't aware of it previously. signature.asc Description: Digital signature
Re: i.MX6 status for IPU/VPU/GPU
Hi Phillip, 2014-08-04 13:54 GMT+02:00 Philipp Zabel p.za...@pengutronix.de: We should take this step by step. First I'd like to get Steve's ipu-v3 series in, those don't have any major issues and are a prerequisite for the media patches anyway. The capture patches had a few more issues than just missing media device support. But this is indeed the biggest one, especially where it involves a userspace interface that we don't want to have to support in the future. My RFC series wasn't without problems either. I'll work on the IPU this week and then post another RFC. Any news about this ? I saw your patchset from june 12th. What is the current status of this RFC and is there a way to help integrating/testing it ? Do you have a public git repository I can fetch and merge in order to test ? Thanks, JM -- 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
Hello
Good Day, Pardon my manner invading your privacy without getting to know you well before now, I summoned courage to write you as am aware you from my home town. I had to write you as a result of my health seeking a matured and God Minded person to handle Humanitarian Project in my name in Hungary since am unable in my Health condition. My name is franca 69 years, I was diagnoses of Breast Cancer years ago which has finally deteriorated to stage 4. My Surgeon confirmed less hope for survival in my upcoming surgery even medical report shows less hope of survival. prior to my email, it has become a matter of important and necessity to make this decision of reaching out to less privileged with my earns. At this point, It's imperative to open up with someone am willing to trust and believe with my heart to fulfill my version for less privilege hence my contact to you since you close around. I need to know you better and see if you can handle a humanitarian project in my name (FRANCA MCNEIL HOME OF THE NEEDY) I am willing to give my life endeavor to the poor through a Godly minded person since my hope of surviving upcoming surgery is 50/50 chance.If not done, I have just 2 weeks left as stated on my medical report. PLEASE CAN YOU HANDLE HUMANITARIAN PROJECT IN MY NAME ? MY SURGERY DATE WILL BE ANNOUNCE NEXT WEEK, I will need your word to bond my courage considering you for this great assignment from God. My contact with you is beyond comprehension was only surfing through directories then came across a link with your ads before considering to write you as a remarkable person. This must be divine hand of God in answer to my prayers.. God will never mislead me.Please confirm your competency to handle this project.You can call or send text anytime +19172319881.Wait to read from you soon Warm regards Mrs. franca McNeil -- -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/3] [media] rc: remove change_protocol in rc-ir-raw.c
On 08/21/2014 07:50 PM, Mauro Carvalho Chehab wrote: Em Thu, 21 Aug 2014 17:24:45 +0800 Zhangfei Gao zhangfei@linaro.org escreveu: With commit 4924a311a62f ([media] rc-core: rename ir-raw.c), empty change_protocol was introduced. No. This was introduced on this changeset: commit da6e162d6a4607362f8478c715c797d84d449f8b Author: David Härdeman da...@hardeman.nu Date: Thu Apr 3 20:32:16 2014 -0300 [media] rc-core: simplify sysfs code As a result, rc_register_device will set dev-enabled_protocols addording to rc_map-rc_type, which prevent using all protocols. I strongly suspect that this patch will break some things, as the new code seems to expect that this is always be set. See the code at store_protocols(): if this callback is not set, then it won't allow to disable a protocol. Also, this doesn't prevent using all protocols. You can still use ir-keytable -p all to enable all protocols (the all protocol type were introduced recently at the userspace tool). From the way I see, setting the protocol when a table is loaded is not a bad thing, as: - if RC tables are loaded, the needed protocol to decode it is already known; - by running just one IR decoder, the IR handling routine will be faster and will consume less power; - on a real case scenario, it is a way more likely that just one decoder will ever be needed by the end user. So, I think that this is just annoying for developers when are checking if all decoders are working, by sending keycodes from different IR types at the same time. Thanks Mauro for the kind explanation. ir-keytable seems also enalbe specific protocol -p, --protocol=PROTOCOL Currently we use lirc user space decoder/keymap and only need pulse-length information from kernel. Thanks for the info. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/3] rc: Introduce hix5hd2 IR transmitter driver
On 08/21/2014 06:07 PM, Sean Young wrote: On Thu, Aug 21, 2014 at 05:24:44PM +0800, Zhangfei Gao wrote: From: Guoxiong Yan yanguoxi...@huawei.com + rdev-driver_type = RC_DRIVER_IR_RAW; + rdev-allowed_protocols = RC_BIT_ALL; + rdev-priv = priv; + rdev-open = hix5hd2_ir_open; + rdev-close = hix5hd2_ir_close; + rdev-driver_name = IR_HIX5HD2_NAME; + rdev-map_name = RC_MAP_LIRC; I'm not sure RC_MAP_LIRC is appropriate. If the hardware has no implicit remote, can this be stored in device tree like the sunxi-cir.c driver does? OK， got it. Will set optional property linux,rc-map-name for the map_name. We usually use user space lirc decoder, so this optional property may not need to be set in dts. + rdev-input_name = Hisilicon hix5hd2 Remote Control Receiver; It would be useful is rdev-input_phys, rdev-input_id, rdev-timeout, rdev-rx_resolution are set correctly. OK, will set rdev-timeout, rdev-rx_resolution Not sure the usage of rdev-input_id, why is it required? Thanks for the suggestion. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] [media] v4l2: add V4L2 pixel format array and helper functions
Hi Guennadi, Am Dienstag, den 26.08.2014, 22:18 +0200 schrieb Guennadi Liakhovetski: Hi Philipp, On Mon, 25 Aug 2014, Philipp Zabel wrote: This patch adds an array of V4L2 pixel formats and descriptions that can be used by drivers so that each driver doesn't have to provide its own slightly different format descriptions for VIDIOC_ENUM_FMT. In case you missed it, soc-camera is doing something rather similar along the lines of: drivers/media/platform/soc_camera/soc_mediabus.c include/media/soc_mediabus.h Feel free to re-use. thank you for the pointer. It is unfortunate that there is a bit of overlap in the names, but not much in the rest of the information. I don't see how the data could be reused in a meaningful way, but maybe I should try to match the patterns. I like the idea of soc_mbus_find_fmtdesc being called with a driver specific lookup array. Although that currently causes drivers to again duplicate all the names, it side-steps the issue of a linear lookup in a large global array. Maybe a helper to fill this driver specific array from the global array would be a good idea for consistency? What is the reason for the separation between struct soc_mbus_lookup and struct soc_mbus pixelformat (as opposed to including enum v4l2_mbus_pixelcode in struct soc_mbus_pixelformat directly)? regards Philipp -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v2] [media] v4l2: add V4L2 pixel format array and helper functions
Hi Laurent,
thank you for the comments.
Am Dienstag, den 26.08.2014, 12:01 +0200 schrieb Laurent Pinchart:
[...]
+};
+
+const struct v4l2_pixfmt *v4l2_pixfmt_by_fourcc(u32 fourcc)
+{
+ int i;
The loop counter is always positive, it can be an unsigned int.
I'll change that.
+ for (i = 0; i ARRAY_SIZE(v4l2_pixfmts); i++) {
+ if (v4l2_pixfmts[i].pixelformat == fourcc)
+ return v4l2_pixfmts + i;
+ }
We currently have 123 pixel formats defined, and that number will keep
increasing. I wonder if something more efficient than an O(n) array lookup
would be worth it.
How about a function similar to soc_mbus_find_fmtdesc that uses an array
provided by the driver:
const struct v4l2_pixfmt_info *v4l2_find_pixfmt(u32 pixelformat,
const struct v4l2_pixfmt_info *array, unsigned int len)
{
unsigned int i;
for (i = 0; i len; i++) {
if (pixelformat == array[i].pixelformat)
return array + i;
}
return NULL;
}
And a function to fill this driver specific array from the global array
once:
void v4l2_init_pixfmt_array(struct v4l2_pixfmt_info *array, int len)
{
unsigned int i;
for (i = 0; i len; i++)
array[i] = *v4l2_pixfmt_by_fourcc(array[i].pixelformat);
}
A driver could then do the following:
static struct v4l2_pixfmt_info driver_formats[] = {
{ .pixelformat = V4L2_PIX_FMT_YUYV },
{ .pixelformat = V4L2_PIX_FMT_YUV420 },
};
int driver_probe(...)
{
...
v4l2_init_pixfmt_array(driver_formats,
ARRAY_SIZE(driver_formats));
...
}
[...]
+unsigned int v4l2_sizeimage(const struct v4l2_pixfmt *fmt, unsigned int
width,
+ unsigned int height)
+{
A small comment would be useful here to explain why we don't round up in the
second case.
Agreed, I think the YUV410 case is a good example for this.
[...]
+/**
+ * struct v4l2_pixfmt - internal V4L2 pixel format description
Maybe struct v4l2_pixfmt_info ?
That's fine with me.
regards
Philipp
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/3] rc: Introduce hix5hd2 IR transmitter driver
On Wed, Aug 27, 2014 at 04:49:59PM +0800, zhangfei wrote: On 08/21/2014 06:07 PM, Sean Young wrote: On Thu, Aug 21, 2014 at 05:24:44PM +0800, Zhangfei Gao wrote: It would be useful is rdev-input_phys, rdev-input_id, rdev-timeout, rdev-rx_resolution are set correctly. OK, will set rdev-timeout, rdev-rx_resolution Not sure the usage of rdev-input_id, why is it required? This is for the EVIOCGID ioctl on the input device which will be created for the rc device. This is used for delivering input events from decoded IR. There is be no reason to run lircd if you use this method. Sean -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/3] rc: Introduce hix5hd2 IR transmitter driver
Hi, Sean On 08/27/2014 05:51 PM, Sean Young wrote: On Wed, Aug 27, 2014 at 04:49:59PM +0800, zhangfei wrote: On 08/21/2014 06:07 PM, Sean Young wrote: On Thu, Aug 21, 2014 at 05:24:44PM +0800, Zhangfei Gao wrote: It would be useful is rdev-input_phys, rdev-input_id, rdev-timeout, rdev-rx_resolution are set correctly. OK, will set rdev-timeout, rdev-rx_resolution Not sure the usage of rdev-input_id, why is it required? This is for the EVIOCGID ioctl on the input device which will be created for the rc device. This is used for delivering input events from decoded Find EVIOCGID in drivers/input/evdev.c Will use same value as sunxi-cir.c gpio-ir-recv.c, if these value has no special requirement. rcdev-input_id.bustype = BUS_HOST; rcdev-input_id.vendor = 0x0001; rcdev-input_id.product = 0x0001; rcdev-input_id.version = 0x0100; IR. There is be no reason to run lircd if you use this method. Do you mean kernel decoder is enough to cover? We use user space lircd to cosider more flexibility, even some non-standard protocol. Anyway both method can be supported, depending on whether setting the optional property linux,rc-map-name or not. Thanks -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problems with the omap3isp
Hi Laurent, Am 04.08.2014 um 17:25 schrieb Laurent Pinchart: On Monday 04 August 2014 11:24:13 Stefan Herbrechtsmeier wrote: Hi Laurent, thank you very much for your help. The problem is cross talk on the camera flex cable of the Gumstix Overo. The XCLKA signal is beside PCLK and VS. Right, I should have mentioned that. It's a know issue, and there's not much that can be done about it without a hardware redesign. A ground (or power supply) signal should really have been inserted on each side of the XCLKA and PCLK signals. Exists a list about knowing issues with the Gumstix Overo? Because I have some problems with the MMC3 too. Additionally the OV5647 camera tristate all outputs by default. This leads to HS_VS_IRQ interrupts. This should be taken care of by pull-up or pull-down resistors on the camera signals. I've disabled them with the Caspa camera given the low drive strength of the buffer on the camera board, but you could enable them on your system. I have manually rework my camera adapter and change the camera clock from XCLKA to XCLKB. Additionally I have enable the pull-ups in my device tree. Now the camera sensor from the Raspberry Pi camera module works together with the Gumstix Overo. Thank you for your help, Stefan -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/3] [media] rc: remove change_protocol in rc-ir-raw.c
Em Wed, 27 Aug 2014 16:42:34 +0800 zhangfei zhangfei@linaro.org escreveu: On 08/21/2014 07:50 PM, Mauro Carvalho Chehab wrote: Em Thu, 21 Aug 2014 17:24:45 +0800 Zhangfei Gao zhangfei@linaro.org escreveu: With commit 4924a311a62f ([media] rc-core: rename ir-raw.c), empty change_protocol was introduced. No. This was introduced on this changeset: commit da6e162d6a4607362f8478c715c797d84d449f8b Author: David Härdeman da...@hardeman.nu Date: Thu Apr 3 20:32:16 2014 -0300 [media] rc-core: simplify sysfs code As a result, rc_register_device will set dev-enabled_protocols addording to rc_map-rc_type, which prevent using all protocols. I strongly suspect that this patch will break some things, as the new code seems to expect that this is always be set. See the code at store_protocols(): if this callback is not set, then it won't allow to disable a protocol. Also, this doesn't prevent using all protocols. You can still use ir-keytable -p all to enable all protocols (the all protocol type were introduced recently at the userspace tool). From the way I see, setting the protocol when a table is loaded is not a bad thing, as: - if RC tables are loaded, the needed protocol to decode it is already known; - by running just one IR decoder, the IR handling routine will be faster and will consume less power; - on a real case scenario, it is a way more likely that just one decoder will ever be needed by the end user. So, I think that this is just annoying for developers when are checking if all decoders are working, by sending keycodes from different IR types at the same time. Thanks Mauro for the kind explanation. ir-keytable seems also enalbe specific protocol -p, --protocol=PROTOCOL Currently we use lirc user space decoder/keymap and only need pulse-length information from kernel. Well, you can use ir-keytable to disable everything but lirc, not compile the other hardware decoders or directly write lirc to /sys/class/rc/rc0/protocols (see Documentation/ABI/testing/sysfs-class-rc). Anyway, I suggest you to use the hardware decoder instead of lirc, as the in-kernel decoders should be lighter than lirc and works pretty well, but this is, of course, your decision. Btw, it would make sense, IMHO, to have a way to setup LIRC daemon to enable LIRC output on a given remote controller, and, optionally, disabling the hardware decoders that are needlessly enabled. Regards, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] media: s5p-mfc: rename special clock to sclk_mfc
Commit d19f405a5a8d2ed942b40f8cf7929a5a50d0cc59 ([media] s5p-mfc: Fix selective sclk_mfc init) added support for special clock handling (named sclk-mfc). However this clock is not defined yet on any platform, so before adding it to all Exynos platform, better rename it to sclk_mfc to match the scheme used for all other special clocks on Exynos platform. Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com --- drivers/media/platform/s5p-mfc/s5p_mfc_pm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_pm.c b/drivers/media/platform/s5p-mfc/s5p_mfc_pm.c index b6a8be97a96c..826c48945bf5 100644 --- a/drivers/media/platform/s5p-mfc/s5p_mfc_pm.c +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_pm.c @@ -21,7 +21,7 @@ #include s5p_mfc_pm.h #define MFC_GATE_CLK_NAME mfc -#define MFC_SCLK_NAME sclk-mfc +#define MFC_SCLK_NAME sclk_mfc #define MFC_SCLK_RATE (200 * 100) #define CLK_DEBUG -- 1.9.2 -- 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] Add support for definition of register maps in DT in ADV7604
From: Jean-Michel Hautbois jean-michel.hautb...@vodalys.com This patch adds support for DT parsing of register maps adresses. This allows multiple adv76xx devices on the same bus. Signed-off-by: Jean-Michel Hautbois jean-michel.hautb...@vodalys.com --- .../devicetree/bindings/media/i2c/adv7604.txt | 12 drivers/media/i2c/adv7604.c| 71 ++ 2 files changed, 71 insertions(+), 12 deletions(-) diff --git a/Documentation/devicetree/bindings/media/i2c/adv7604.txt b/Documentation/devicetree/bindings/media/i2c/adv7604.txt index c27cede..33881fb 100644 --- a/Documentation/devicetree/bindings/media/i2c/adv7604.txt +++ b/Documentation/devicetree/bindings/media/i2c/adv7604.txt @@ -32,6 +32,18 @@ The digital output port node must contain at least one endpoint. Optional Properties: - reset-gpios: Reference to the GPIO connected to the device's reset pin. + - adv7604-page-avlink: Programmed address for avlink register map + - adv7604-page-cec: Programmed address for cec register map + - adv7604-page-infoframe: Programmed address for infoframe register map + - adv7604-page-esdp: Programmed address for esdp register map + - adv7604-page-dpp: Programmed address for dpp register map + - adv7604-page-afe: Programmed address for afe register map + - adv7604-page-rep: Programmed address for rep register map + - adv7604-page-edid: Programmed address for edid register map + - adv7604-page-hdmi: Programmed address for hdmi register map + - adv7604-page-test: Programmed address for test register map + - adv7604-page-cp: Programmed address for cp register map + - adv7604-page-vdp: Programmed address for vdp register map Optional Endpoint Properties: diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c index d4fa213..89a7034 100644 --- a/drivers/media/i2c/adv7604.c +++ b/drivers/media/i2c/adv7604.c @@ -2718,18 +2718,65 @@ static int adv7604_parse_dt(struct adv7604_state *state) state-pdata.int1_config = ADV7604_INT1_CONFIG_DISABLED; /* Use the default I2C addresses. */ - state-pdata.i2c_addresses[ADV7604_PAGE_AVLINK] = 0x42; - state-pdata.i2c_addresses[ADV7604_PAGE_CEC] = 0x40; - state-pdata.i2c_addresses[ADV7604_PAGE_INFOFRAME] = 0x3e; - state-pdata.i2c_addresses[ADV7604_PAGE_ESDP] = 0x38; - state-pdata.i2c_addresses[ADV7604_PAGE_DPP] = 0x3c; - state-pdata.i2c_addresses[ADV7604_PAGE_AFE] = 0x26; - state-pdata.i2c_addresses[ADV7604_PAGE_REP] = 0x32; - state-pdata.i2c_addresses[ADV7604_PAGE_EDID] = 0x36; - state-pdata.i2c_addresses[ADV7604_PAGE_HDMI] = 0x34; - state-pdata.i2c_addresses[ADV7604_PAGE_TEST] = 0x30; - state-pdata.i2c_addresses[ADV7604_PAGE_CP] = 0x22; - state-pdata.i2c_addresses[ADV7604_PAGE_VDP] = 0x24; + of_property_read_u32(np, adv7604-page-avlink, + state-pdata.i2c_addresses[ADV7604_PAGE_AVLINK]); + if (!state-pdata.i2c_addresses[ADV7604_PAGE_AVLINK]) + state-pdata.i2c_addresses[ADV7604_PAGE_AVLINK] = 0x42; + + of_property_read_u32(np, adv7604-page-cec, + state-pdata.i2c_addresses[ADV7604_PAGE_CEC]); + if (!state-pdata.i2c_addresses[ADV7604_PAGE_CEC]) + state-pdata.i2c_addresses[ADV7604_PAGE_CEC] = 0x40; + + of_property_read_u32(np, adv7604-page-infoframe, + state-pdata.i2c_addresses[ADV7604_PAGE_INFOFRAME]); + if (!state-pdata.i2c_addresses[ADV7604_PAGE_INFOFRAME]) + state-pdata.i2c_addresses[ADV7604_PAGE_INFOFRAME] = 0x3e; + + of_property_read_u32(np, adv7604-page-esdp, + state-pdata.i2c_addresses[ADV7604_PAGE_ESDP]); + if (!state-pdata.i2c_addresses[ADV7604_PAGE_ESDP]) + state-pdata.i2c_addresses[ADV7604_PAGE_ESDP] = 0x38; + + of_property_read_u32(np, adv7604-page-dpp, + state-pdata.i2c_addresses[ADV7604_PAGE_DPP]); + if (!state-pdata.i2c_addresses[ADV7604_PAGE_DPP]) + state-pdata.i2c_addresses[ADV7604_PAGE_DPP] = 0x3c; + + of_property_read_u32(np, adv7604-page-afe, + state-pdata.i2c_addresses[ADV7604_PAGE_AFE]); + if (!state-pdata.i2c_addresses[ADV7604_PAGE_AFE]) + state-pdata.i2c_addresses[ADV7604_PAGE_AFE] = 0x26; + + of_property_read_u32(np, adv7604-page-rep, + state-pdata.i2c_addresses[ADV7604_PAGE_REP]); + if (!state-pdata.i2c_addresses[ADV7604_PAGE_REP]) + state-pdata.i2c_addresses[ADV7604_PAGE_REP] = 0x32; + + of_property_read_u32(np, adv7604-page-edid, + state-pdata.i2c_addresses[ADV7604_PAGE_EDID]); + if (!state-pdata.i2c_addresses[ADV7604_PAGE_EDID]) + state-pdata.i2c_addresses[ADV7604_PAGE_EDID] = 0x36; + + of_property_read_u32(np, adv7604-page-hdmi, + state-pdata.i2c_addresses[ADV7604_PAGE_HDMI]); + if
Re: [PATCH] media: s5p-mfc: rename special clock to sclk_mfc
On 27/08/14 14:36, Marek Szyprowski wrote: Commit d19f405a5a8d2ed942b40f8cf7929a5a50d0cc59 ([media] s5p-mfc: Fix selective sclk_mfc init) added support for special clock handling (named sclk-mfc). However this clock is not defined yet on any platform, so before adding it to all Exynos platform, better rename it to sclk_mfc to match the scheme used for all other special clocks on Exynos platform. Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com Acked-by: Sylwester Nawrocki s.nawro...@samsung.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Add support for definition of register maps in DT in ADV7604
On 08/27/14 14:53, jean-michel.hautb...@vodalys.com wrote: From: Jean-Michel Hautbois jean-michel.hautb...@vodalys.com This patch adds support for DT parsing of register maps adresses. This allows multiple adv76xx devices on the same bus. Signed-off-by: Jean-Michel Hautbois jean-michel.hautb...@vodalys.com --- .../devicetree/bindings/media/i2c/adv7604.txt | 12 drivers/media/i2c/adv7604.c| 71 ++ 2 files changed, 71 insertions(+), 12 deletions(-) diff --git a/Documentation/devicetree/bindings/media/i2c/adv7604.txt b/Documentation/devicetree/bindings/media/i2c/adv7604.txt index c27cede..33881fb 100644 --- a/Documentation/devicetree/bindings/media/i2c/adv7604.txt +++ b/Documentation/devicetree/bindings/media/i2c/adv7604.txt @@ -32,6 +32,18 @@ The digital output port node must contain at least one endpoint. Optional Properties: - reset-gpios: Reference to the GPIO connected to the device's reset pin. + - adv7604-page-avlink: Programmed address for avlink register map + - adv7604-page-cec: Programmed address for cec register map + - adv7604-page-infoframe: Programmed address for infoframe register map + - adv7604-page-esdp: Programmed address for esdp register map + - adv7604-page-dpp: Programmed address for dpp register map + - adv7604-page-afe: Programmed address for afe register map + - adv7604-page-rep: Programmed address for rep register map + - adv7604-page-edid: Programmed address for edid register map + - adv7604-page-hdmi: Programmed address for hdmi register map + - adv7604-page-test: Programmed address for test register map + - adv7604-page-cp: Programmed address for cp register map + - adv7604-page-vdp: Programmed address for vdp register map Might adv7604-addr-avlink be a better name? Other than that it looks good to me. Hans Optional Endpoint Properties: diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c index d4fa213..89a7034 100644 --- a/drivers/media/i2c/adv7604.c +++ b/drivers/media/i2c/adv7604.c @@ -2718,18 +2718,65 @@ static int adv7604_parse_dt(struct adv7604_state *state) state-pdata.int1_config = ADV7604_INT1_CONFIG_DISABLED; /* Use the default I2C addresses. */ - state-pdata.i2c_addresses[ADV7604_PAGE_AVLINK] = 0x42; - state-pdata.i2c_addresses[ADV7604_PAGE_CEC] = 0x40; - state-pdata.i2c_addresses[ADV7604_PAGE_INFOFRAME] = 0x3e; - state-pdata.i2c_addresses[ADV7604_PAGE_ESDP] = 0x38; - state-pdata.i2c_addresses[ADV7604_PAGE_DPP] = 0x3c; - state-pdata.i2c_addresses[ADV7604_PAGE_AFE] = 0x26; - state-pdata.i2c_addresses[ADV7604_PAGE_REP] = 0x32; - state-pdata.i2c_addresses[ADV7604_PAGE_EDID] = 0x36; - state-pdata.i2c_addresses[ADV7604_PAGE_HDMI] = 0x34; - state-pdata.i2c_addresses[ADV7604_PAGE_TEST] = 0x30; - state-pdata.i2c_addresses[ADV7604_PAGE_CP] = 0x22; - state-pdata.i2c_addresses[ADV7604_PAGE_VDP] = 0x24; + of_property_read_u32(np, adv7604-page-avlink, + state-pdata.i2c_addresses[ADV7604_PAGE_AVLINK]); + if (!state-pdata.i2c_addresses[ADV7604_PAGE_AVLINK]) + state-pdata.i2c_addresses[ADV7604_PAGE_AVLINK] = 0x42; + + of_property_read_u32(np, adv7604-page-cec, + state-pdata.i2c_addresses[ADV7604_PAGE_CEC]); + if (!state-pdata.i2c_addresses[ADV7604_PAGE_CEC]) + state-pdata.i2c_addresses[ADV7604_PAGE_CEC] = 0x40; + + of_property_read_u32(np, adv7604-page-infoframe, + state-pdata.i2c_addresses[ADV7604_PAGE_INFOFRAME]); + if (!state-pdata.i2c_addresses[ADV7604_PAGE_INFOFRAME]) + state-pdata.i2c_addresses[ADV7604_PAGE_INFOFRAME] = 0x3e; + + of_property_read_u32(np, adv7604-page-esdp, + state-pdata.i2c_addresses[ADV7604_PAGE_ESDP]); + if (!state-pdata.i2c_addresses[ADV7604_PAGE_ESDP]) + state-pdata.i2c_addresses[ADV7604_PAGE_ESDP] = 0x38; + + of_property_read_u32(np, adv7604-page-dpp, + state-pdata.i2c_addresses[ADV7604_PAGE_DPP]); + if (!state-pdata.i2c_addresses[ADV7604_PAGE_DPP]) + state-pdata.i2c_addresses[ADV7604_PAGE_DPP] = 0x3c; + + of_property_read_u32(np, adv7604-page-afe, + state-pdata.i2c_addresses[ADV7604_PAGE_AFE]); + if (!state-pdata.i2c_addresses[ADV7604_PAGE_AFE]) + state-pdata.i2c_addresses[ADV7604_PAGE_AFE] = 0x26; + + of_property_read_u32(np, adv7604-page-rep, + state-pdata.i2c_addresses[ADV7604_PAGE_REP]); + if (!state-pdata.i2c_addresses[ADV7604_PAGE_REP]) + state-pdata.i2c_addresses[ADV7604_PAGE_REP] = 0x32; + + of_property_read_u32(np, adv7604-page-edid, + state-pdata.i2c_addresses[ADV7604_PAGE_EDID]); + if (!state-pdata.i2c_addresses[ADV7604_PAGE_EDID]) +
Re: [PATCH] Add support for definition of register maps in DT in ADV7604
2014-08-27 15:03 GMT+02:00 Hans Verkuil hverk...@xs4all.nl: On 08/27/14 14:53, jean-michel.hautb...@vodalys.com wrote: From: Jean-Michel Hautbois jean-michel.hautb...@vodalys.com This patch adds support for DT parsing of register maps adresses. This allows multiple adv76xx devices on the same bus. Signed-off-by: Jean-Michel Hautbois jean-michel.hautb...@vodalys.com --- .../devicetree/bindings/media/i2c/adv7604.txt | 12 drivers/media/i2c/adv7604.c| 71 ++ 2 files changed, 71 insertions(+), 12 deletions(-) diff --git a/Documentation/devicetree/bindings/media/i2c/adv7604.txt b/Documentation/devicetree/bindings/media/i2c/adv7604.txt index c27cede..33881fb 100644 --- a/Documentation/devicetree/bindings/media/i2c/adv7604.txt +++ b/Documentation/devicetree/bindings/media/i2c/adv7604.txt @@ -32,6 +32,18 @@ The digital output port node must contain at least one endpoint. Optional Properties: - reset-gpios: Reference to the GPIO connected to the device's reset pin. + - adv7604-page-avlink: Programmed address for avlink register map + - adv7604-page-cec: Programmed address for cec register map + - adv7604-page-infoframe: Programmed address for infoframe register map + - adv7604-page-esdp: Programmed address for esdp register map + - adv7604-page-dpp: Programmed address for dpp register map + - adv7604-page-afe: Programmed address for afe register map + - adv7604-page-rep: Programmed address for rep register map + - adv7604-page-edid: Programmed address for edid register map + - adv7604-page-hdmi: Programmed address for hdmi register map + - adv7604-page-test: Programmed address for test register map + - adv7604-page-cp: Programmed address for cp register map + - adv7604-page-vdp: Programmed address for vdp register map Might adv7604-addr-avlink be a better name? Other than that it looks good to me. Hans I can replace all -page- by -addr- if it seems better... I used page as this is also the name defined in the source code but you are probably right, it is an address, not a page... :) JM -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/3] rc: Introduce hix5hd2 IR transmitter driver
On Wed, Aug 27, 2014 at 06:10:28PM +0800, zhangfei wrote: On 08/27/2014 05:51 PM, Sean Young wrote: On Wed, Aug 27, 2014 at 04:49:59PM +0800, zhangfei wrote: On 08/21/2014 06:07 PM, Sean Young wrote: IR. There is be no reason to run lircd if you use this method. Do you mean kernel decoder is enough to cover? We use user space lircd to cosider more flexibility, even some non-standard protocol. Just out of interest, what flexibility does lircd offer which the kernel decoders do not? Anyway both method can be supported, depending on whether setting the optional property linux,rc-map-name or not. Great, thanks. Sean -- 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] Add support for definition of register maps in DT in ADV7604
This patch adds support for DT parsing of register maps adresses. This allows multiple adv76xx devices on the same bus. Signed-off-by: Jean-Michel Hautbois jean-michel.hautb...@vodalys.com --- .../devicetree/bindings/media/i2c/adv7604.txt | 12 drivers/media/i2c/adv7604.c| 71 ++ 2 files changed, 71 insertions(+), 12 deletions(-) diff --git a/Documentation/devicetree/bindings/media/i2c/adv7604.txt b/Documentation/devicetree/bindings/media/i2c/adv7604.txt index c27cede..21146cb 100644 --- a/Documentation/devicetree/bindings/media/i2c/adv7604.txt +++ b/Documentation/devicetree/bindings/media/i2c/adv7604.txt @@ -32,6 +32,18 @@ The digital output port node must contain at least one endpoint. Optional Properties: - reset-gpios: Reference to the GPIO connected to the device's reset pin. + - adv7604-addr-avlink: Programmed address for avlink register map + - adv7604-addr-cec: Programmed address for cec register map + - adv7604-addr-infoframe: Programmed address for infoframe register map + - adv7604-addr-esdp: Programmed address for esdp register map + - adv7604-addr-dpp: Programmed address for dpp register map + - adv7604-addr-afe: Programmed address for afe register map + - adv7604-addr-rep: Programmed address for rep register map + - adv7604-addr-edid: Programmed address for edid register map + - adv7604-addr-hdmi: Programmed address for hdmi register map + - adv7604-addr-test: Programmed address for test register map + - adv7604-addr-cp: Programmed address for cp register map + - adv7604-addr-vdp: Programmed address for vdp register map Optional Endpoint Properties: diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c index d4fa213..d15a05f 100644 --- a/drivers/media/i2c/adv7604.c +++ b/drivers/media/i2c/adv7604.c @@ -2718,18 +2718,65 @@ static int adv7604_parse_dt(struct adv7604_state *state) state-pdata.int1_config = ADV7604_INT1_CONFIG_DISABLED; /* Use the default I2C addresses. */ - state-pdata.i2c_addresses[ADV7604_PAGE_AVLINK] = 0x42; - state-pdata.i2c_addresses[ADV7604_PAGE_CEC] = 0x40; - state-pdata.i2c_addresses[ADV7604_PAGE_INFOFRAME] = 0x3e; - state-pdata.i2c_addresses[ADV7604_PAGE_ESDP] = 0x38; - state-pdata.i2c_addresses[ADV7604_PAGE_DPP] = 0x3c; - state-pdata.i2c_addresses[ADV7604_PAGE_AFE] = 0x26; - state-pdata.i2c_addresses[ADV7604_PAGE_REP] = 0x32; - state-pdata.i2c_addresses[ADV7604_PAGE_EDID] = 0x36; - state-pdata.i2c_addresses[ADV7604_PAGE_HDMI] = 0x34; - state-pdata.i2c_addresses[ADV7604_PAGE_TEST] = 0x30; - state-pdata.i2c_addresses[ADV7604_PAGE_CP] = 0x22; - state-pdata.i2c_addresses[ADV7604_PAGE_VDP] = 0x24; + of_property_read_u32(np, adv7604-addr-avlink, + state-pdata.i2c_addresses[ADV7604_PAGE_AVLINK]); + if (!state-pdata.i2c_addresses[ADV7604_PAGE_AVLINK]) + state-pdata.i2c_addresses[ADV7604_PAGE_AVLINK] = 0x42; + + of_property_read_u32(np, adv7604-addr-cec, + state-pdata.i2c_addresses[ADV7604_PAGE_CEC]); + if (!state-pdata.i2c_addresses[ADV7604_PAGE_CEC]) + state-pdata.i2c_addresses[ADV7604_PAGE_CEC] = 0x40; + + of_property_read_u32(np, adv7604-addr-infoframe, + state-pdata.i2c_addresses[ADV7604_PAGE_INFOFRAME]); + if (!state-pdata.i2c_addresses[ADV7604_PAGE_INFOFRAME]) + state-pdata.i2c_addresses[ADV7604_PAGE_INFOFRAME] = 0x3e; + + of_property_read_u32(np, adv7604-addr-esdp, + state-pdata.i2c_addresses[ADV7604_PAGE_ESDP]); + if (!state-pdata.i2c_addresses[ADV7604_PAGE_ESDP]) + state-pdata.i2c_addresses[ADV7604_PAGE_ESDP] = 0x38; + + of_property_read_u32(np, adv7604-addr-dpp, + state-pdata.i2c_addresses[ADV7604_PAGE_DPP]); + if (!state-pdata.i2c_addresses[ADV7604_PAGE_DPP]) + state-pdata.i2c_addresses[ADV7604_PAGE_DPP] = 0x3c; + + of_property_read_u32(np, adv7604-addr-afe, + state-pdata.i2c_addresses[ADV7604_PAGE_AFE]); + if (!state-pdata.i2c_addresses[ADV7604_PAGE_AFE]) + state-pdata.i2c_addresses[ADV7604_PAGE_AFE] = 0x26; + + of_property_read_u32(np, adv7604-addr-rep, + state-pdata.i2c_addresses[ADV7604_PAGE_REP]); + if (!state-pdata.i2c_addresses[ADV7604_PAGE_REP]) + state-pdata.i2c_addresses[ADV7604_PAGE_REP] = 0x32; + + of_property_read_u32(np, adv7604-addr-edid, + state-pdata.i2c_addresses[ADV7604_PAGE_EDID]); + if (!state-pdata.i2c_addresses[ADV7604_PAGE_EDID]) + state-pdata.i2c_addresses[ADV7604_PAGE_EDID] = 0x36; + + of_property_read_u32(np, adv7604-addr-hdmi, + state-pdata.i2c_addresses[ADV7604_PAGE_HDMI]); + if (!state-pdata.i2c_addresses[ADV7604_PAGE_HDMI]) +
Re: linux-firmware: add firmware v3.25.0.0 for ITEtech IT9135 DVB-T USB driver
On Tue, Aug 19, 2014 at 03:37:47PM +0800, Bimow Chen wrote: Add two firmware files for ITEtech IT9135 Ax and Bx chip versions. From c05fac0989dff376729609cd6baac2367929d990 Mon Sep 17 00:00:00 2001 From: Bimow Chen bimow.c...@ite.com.tw Date: Tue, 19 Aug 2014 15:19:56 +0800 Subject: [PATCH] Add firmware v3.25.0.0 for ITEtech IT9135 DVB-T USB driver Signed-off-by: Bimow Chen bimow.c...@ite.com.tw --- LICENCE.it913x | 17 + WHENCE |9 + dvb-usb-it9135-01.fw | Bin 0 - 8128 bytes dvb-usb-it9135-02.fw | Bin 0 - 5834 bytes 4 files changed, 26 insertions(+), 0 deletions(-) create mode 100644 LICENCE.it913x create mode 100644 dvb-usb-it9135-01.fw create mode 100644 dvb-usb-it9135-02.fw Looks better, thanks, I've applied this. regards, Kyle diff --git a/LICENCE.it913x b/LICENCE.it913x new file mode 100644 index 000..3706c18 --- /dev/null +++ b/LICENCE.it913x @@ -0,0 +1,17 @@ +Copyright (c) 2014, ITE Tech. Inc. + +The firmware files dvb-usb-it9135-01.fw and dvb-usb-it9135-02.fw +are for ITEtech it9135 Ax and Bx chip versions. + +Permission to use, copy, modify, and/or distribute this software for +any purpose with or without fee is hereby granted, provided that the +above copyright notice and this permission notice appear in all copies. + +THE SOFTWARE IS PROVIDED AS IS AND THE AUTHOR DISCLAIMS ALL WARRANTIES +WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF +MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE +FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY +DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, +WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, +ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS +SOFTWARE. diff --git a/WHENCE b/WHENCE index bd65d8c..3d46b76 100644 --- a/WHENCE +++ b/WHENCE @@ -2503,3 +2503,12 @@ File: intel/fw_sst_0f28.bin-48kHz_i2s_master License: Redistributable. See LICENCE.fw_sst_0f28 for details -- + +Driver: it9135 -- ITEtech IT913x DVB-T USB driver + +File: dvb-usb-it9135-01.fw +File: dvb-usb-it9135-02.fw + +Licence: Redistributable. See LICENCE.it913x for details + +-- -- 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] Add support for definition of register maps in DT in ADV7604
On 08/27/2014 03:03 PM, Hans Verkuil wrote: On 08/27/14 14:53, jean-michel.hautb...@vodalys.com wrote: From: Jean-Michel Hautbois jean-michel.hautb...@vodalys.com This patch adds support for DT parsing of register maps adresses. This allows multiple adv76xx devices on the same bus. Signed-off-by: Jean-Michel Hautbois jean-michel.hautb...@vodalys.com --- .../devicetree/bindings/media/i2c/adv7604.txt | 12 drivers/media/i2c/adv7604.c| 71 ++ 2 files changed, 71 insertions(+), 12 deletions(-) diff --git a/Documentation/devicetree/bindings/media/i2c/adv7604.txt b/Documentation/devicetree/bindings/media/i2c/adv7604.txt index c27cede..33881fb 100644 --- a/Documentation/devicetree/bindings/media/i2c/adv7604.txt +++ b/Documentation/devicetree/bindings/media/i2c/adv7604.txt @@ -32,6 +32,18 @@ The digital output port node must contain at least one endpoint. Optional Properties: - reset-gpios: Reference to the GPIO connected to the device's reset pin. + - adv7604-page-avlink: Programmed address for avlink register map + - adv7604-page-cec: Programmed address for cec register map + - adv7604-page-infoframe: Programmed address for infoframe register map + - adv7604-page-esdp: Programmed address for esdp register map + - adv7604-page-dpp: Programmed address for dpp register map + - adv7604-page-afe: Programmed address for afe register map + - adv7604-page-rep: Programmed address for rep register map + - adv7604-page-edid: Programmed address for edid register map + - adv7604-page-hdmi: Programmed address for hdmi register map + - adv7604-page-test: Programmed address for test register map + - adv7604-page-cp: Programmed address for cp register map + - adv7604-page-vdp: Programmed address for vdp register map Might adv7604-addr-avlink be a better name? Other than that it looks good to me. Those properties need at least a vendor prefix. But to be honest I'd rather see generic support for multiple addresses in the I2C core. This is not a feature that is specific to this particular device. And for example similar things work already fine for other buses like for example MMIO devices. E.g. something like reg = 0x12 0x34 0x56 0x78 ... reg-names = main, avlink, cec, infoframe, ... Ideally accessing those other addresses will be hidden in the I2C core by a helper function that allows you to create a dummy device for a particular sub-address. - Lars -- 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: i.MX6 status for IPU/VPU/GPU
On 08/27/2014 12:13 AM, Jean-Michel Hautbois wrote: Hi Phillip, 2014-08-04 13:54 GMT+02:00 Philipp Zabel p.za...@pengutronix.de: We should take this step by step. First I'd like to get Steve's ipu-v3 series in, those don't have any major issues and are a prerequisite for the media patches anyway. The capture patches had a few more issues than just missing media device support. But this is indeed the biggest one, especially where it involves a userspace interface that we don't want to have to support in the future. My RFC series wasn't without problems either. I'll work on the IPU this week and then post another RFC. Any news about this ? I saw your patchset from june 12th. What is the current status of this RFC and is there a way to help integrating/testing it ? Do you have a public git repository I can fetch and merge in order to test ? Hi Jean-Michel, Phillip, I've done some work on Philipp's June 12 patchset, converting the CSI driver to a CSI subdev entity, and fixing some issues here and there. This June 12 patchset doesn't appear to be a fully working driver, Phillip correct me if I am wrong. I can post this work as it exists, it is incomplete but compiles. I've also worked out what I think is a workable video pipeline graph for i.MX, suitable for defining the entities, pads, and links. Unfortunately I haven't been able to spend as much time as I'd like on it. The complete driver I posted to the list does have some minor issues mostly suggested by Hans Verkuil (switch to new selection API instead of cropping API for example). It is a full featured driver but it does not implement the media device framework, i.e. user does not have direct control of the video pipeline, rather the driver chooses the pipeline based on the traditional inputs from user (video format and controls). If there is interest I can submit another version of the traditional driver to resolve the issues. But media device is a major rework, so I don't know whether it would make sense to start from the traditional driver and then implement media device on top later, since media device is almost a complete rewrite. Steve -- 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: randconfig build error with next-20140826, in Documentation/video4linux
On 08/27/14 03:58, Sudip Mukherjee wrote: On Tue, Aug 26, 2014 at 09:50:43AM -0700, Jim Davis wrote: Building with the attached random configuration file, ERROR: vb2_ops_wait_finish [Documentation/video4linux/v4l2-pci-skeleton.ko] undefined! ERROR: vb2_ops_wait_prepare [Documentation/video4linux/v4l2-pci-skeleton.ko] undefined! ERROR: v4l2_event_unsubscribe [Documentation/video4linux/v4l2-pci-skeleton.ko] undefined! ERROR: v4l2_ctrl_subscribe_event [Documentation/video4linux/v4l2-pci-skeleton.ko] undefined! ERROR: v4l2_ctrl_log_status [Documentation/video4linux/v4l2-pci-skeleton.ko] undefined! ERROR: vb2_ioctl_streamoff [Documentation/video4linux/v4l2-pci-skeleton.ko] undefined! ERROR: vb2_ioctl_streamon [Documentation/video4linux/v4l2-pci-skeleton.ko] undefined! ERROR: vb2_ioctl_create_bufs [Documentation/video4linux/v4l2-pci-skeleton.ko] undefined! ERROR: vb2_ioctl_dqbuf [Documentation/video4linux/v4l2-pci-skeleton.ko] undefined! ERROR: vb2_ioctl_expbuf [Documentation/video4linux/v4l2-pci-skeleton.ko] undefined! ERROR: vb2_ioctl_qbuf [Documentation/video4linux/v4l2-pci-skeleton.ko] undefined! ERROR: vb2_ioctl_querybuf [Documentation/video4linux/v4l2-pci-skeleton.ko] undefined! ERROR: vb2_ioctl_reqbufs [Documentation/video4linux/v4l2-pci-skeleton.ko] undefined! ERROR: vb2_fop_release [Documentation/video4linux/v4l2-pci-skeleton.ko] undefined! ERROR: v4l2_fh_open [Documentation/video4linux/v4l2-pci-skeleton.ko] undefined! ERROR: vb2_fop_mmap [Documentation/video4linux/v4l2-pci-skeleton.ko] undefined! ERROR: video_ioctl2 [Documentation/video4linux/v4l2-pci-skeleton.ko] undefined! ERROR: vb2_fop_poll [Documentation/video4linux/v4l2-pci-skeleton.ko] undefined! ERROR: vb2_fop_read [Documentation/video4linux/v4l2-pci-skeleton.ko] undefined! ERROR: vb2_buffer_done [Documentation/video4linux/v4l2-pci-skeleton.ko] undefined! ERROR: __video_register_device [Documentation/video4linux/v4l2-pci-skeleton.ko] undefined! ERROR: video_device_release_empty [Documentation/video4linux/v4l2-pci-skeleton.ko] undefined! ERROR: vb2_dma_contig_init_ctx [Documentation/video4linux/v4l2-pci-skeleton.ko] undefined! ERROR: vb2_queue_init [Documentation/video4linux/v4l2-pci-skeleton.ko] undefined! ERROR: vb2_dma_contig_memops [Documentation/video4linux/v4l2-pci-skeleton.ko] undefined! ERROR: v4l2_ctrl_new_std [Documentation/video4linux/v4l2-pci-skeleton.ko] undefined! ERROR: v4l2_ctrl_handler_init_class [Documentation/video4linux/v4l2-pci-skeleton.ko] undefined! ERROR: v4l2_device_register [Documentation/video4linux/v4l2-pci-skeleton.ko] undefined! ERROR: v4l2_match_dv_timings [Documentation/video4linux/v4l2-pci-skeleton.ko] undefined! ERROR: v4l2_find_dv_timings_cap [Documentation/video4linux/v4l2-pci-skeleton.ko] undefined! ERROR: v4l2_valid_dv_timings [Documentation/video4linux/v4l2-pci-skeleton.ko] undefined! ERROR: v4l2_enum_dv_timings_cap [Documentation/video4linux/v4l2-pci-skeleton.ko] undefined! ERROR: video_devdata [Documentation/video4linux/v4l2-pci-skeleton.ko] undefined! ERROR: v4l2_device_unregister [Documentation/video4linux/v4l2-pci-skeleton.ko] undefined! ERROR: vb2_dma_contig_cleanup_ctx [Documentation/video4linux/v4l2-pci-skeleton.ko] undefined! ERROR: v4l2_ctrl_handler_free [Documentation/video4linux/v4l2-pci-skeleton.ko] undefined! ERROR: video_unregister_device [Documentation/video4linux/v4l2-pci-skeleton.ko] undefined! make[1]: *** [__modpost] Error 1 make: *** [modules] Error 2 Similar to a build error from January 7th: https://lists.01.org/pipermail/kbuild-all/2014-January/002566.html Hi, I tried to build next-20140826 with your given config file . But for me everything was fine. And I was just wondering why the skeleton code in the Documentation is building ? It builds if the Kconfig symbol BUILD_DOCSRC is enabled. Building of this module was just added to linux-next. -- ~Randy -- 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] usb: gadget: f_uvc fix transition to video_ioctl2
UVC video node is a TX device from the point of view of the gadget, so we cannot rely on the video struct being filled with zeros, because VFL_DIR_TX is actually 1. Suggested-by: Sylwester Nawrocki s.nawro...@samsung.com Signed-off-by: Andrzej Pietrasiewicz andrze...@samsung.com --- drivers/usb/gadget/function/f_uvc.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/usb/gadget/function/f_uvc.c b/drivers/usb/gadget/function/f_uvc.c index 5209105..95dc1c6 100644 --- a/drivers/usb/gadget/function/f_uvc.c +++ b/drivers/usb/gadget/function/f_uvc.c @@ -411,6 +411,7 @@ uvc_register_video(struct uvc_device *uvc) video-fops = uvc_v4l2_fops; video-ioctl_ops = uvc_v4l2_ioctl_ops; video-release = video_device_release; + video-vfl_dir = VFL_DIR_TX; strlcpy(video-name, cdev-gadget-name, sizeof(video-name)); uvc-vdev = video; -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/5] dvb-core: add a new tuner ops to dvb_frontend for APIv5
From: Akihiro Tsukada tsk...@gmail.com
fe-ops.tuner_ops.get_rf_strength() reports its result in u16,
while in DVB APIv5 it should be reported in s64 and by 0.001dBm.
Signed-off-by: Akihiro Tsukada tsk...@gmail.com
---
drivers/media/dvb-core/dvb_frontend.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/media/dvb-core/dvb_frontend.h
b/drivers/media/dvb-core/dvb_frontend.h
index 816269e..f6222b5 100644
--- a/drivers/media/dvb-core/dvb_frontend.h
+++ b/drivers/media/dvb-core/dvb_frontend.h
@@ -222,6 +222,8 @@ struct dvb_tuner_ops {
#define TUNER_STATUS_STEREO 2
int (*get_status)(struct dvb_frontend *fe, u32 *status);
int (*get_rf_strength)(struct dvb_frontend *fe, u16 *strength);
+ /** get signal strengh in 0.001dBm, in accordance with APIv5 */
+ int (*get_rf_strength_dbm)(struct dvb_frontend *fe, s64 *strength);
int (*get_afc)(struct dvb_frontend *fe, s32 *afc);
/** These are provided separately from set_params in order to
facilitate silicon
--
2.1.0
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 3/5] qm1d1c0042: add driver for Sharp QM1D1C0042 ISDB-S tuner
From: Akihiro Tsukada tsk...@gmail.com
This patch adds driver for qm1d1c0042 tuner chips.
It is used as an ISDB-S tuner in earthsoft pt3 cards.
Signed-off-by: Akihiro Tsukada tsk...@gmail.com
---
Changes in v2:
- moved a static const table out of function scope
- removed an unused config parameter
- improvement in _init() to support suspend/resume
drivers/media/tuners/Kconfig | 7 +
drivers/media/tuners/Makefile | 1 +
drivers/media/tuners/qm1d1c0042.c | 422 ++
drivers/media/tuners/qm1d1c0042.h | 50 +
4 files changed, 480 insertions(+)
diff --git a/drivers/media/tuners/Kconfig b/drivers/media/tuners/Kconfig
index cd3f8ee..8125d1d 100644
--- a/drivers/media/tuners/Kconfig
+++ b/drivers/media/tuners/Kconfig
@@ -264,4 +264,11 @@ config MEDIA_TUNER_MXL301RF
default m if !MEDIA_SUBDRV_AUTOSELECT
help
MaxLinear MxL301RF OFDM tuner driver.
+
+config MEDIA_TUNER_QM1D1C0042
+ tristate Sharp QM1D1C0042 tuner
+ depends on MEDIA_SUPPORT I2C
+ default m if !MEDIA_SUBDRV_AUTOSELECT
+ help
+ Sharp QM1D1C0042 trellis coded 8PSK tuner driver.
endmenu
diff --git a/drivers/media/tuners/Makefile b/drivers/media/tuners/Makefile
index 6d5bf48..04d5efc 100644
--- a/drivers/media/tuners/Makefile
+++ b/drivers/media/tuners/Makefile
@@ -40,6 +40,7 @@ obj-$(CONFIG_MEDIA_TUNER_FC0013) += fc0013.o
obj-$(CONFIG_MEDIA_TUNER_IT913X) += tuner_it913x.o
obj-$(CONFIG_MEDIA_TUNER_R820T) += r820t.o
obj-$(CONFIG_MEDIA_TUNER_MXL301RF) += mxl301rf.o
+obj-$(CONFIG_MEDIA_TUNER_QM1D1C0042) += qm1d1c0042.o
ccflags-y += -I$(srctree)/drivers/media/dvb-core
ccflags-y += -I$(srctree)/drivers/media/dvb-frontends
diff --git a/drivers/media/tuners/qm1d1c0042.c
b/drivers/media/tuners/qm1d1c0042.c
new file mode 100644
index 000..ea6c245
--- /dev/null
+++ b/drivers/media/tuners/qm1d1c0042.c
@@ -0,0 +1,422 @@
+/*
+ * Sharp QM1D1C0042 8PSK tuner driver
+ *
+ * Copyright (C) 2014 Akihiro Tsukada tsk...@gmail.com
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include qm1d1c0042.h
+
+#define QM1D1C0042_NUM_REGS 0x20
+
+static const u8 reg_initval[QM1D1C0042_NUM_REGS] = {
+ 0x48, 0x1c, 0xa0, 0x10, 0xbc, 0xc5, 0x20, 0x33,
+ 0x06, 0x00, 0x00, 0x00, 0x03, 0x00, 0x00, 0x00,
+ 0x00, 0xff, 0xf3, 0x00, 0x2a, 0x64, 0xa6, 0x86,
+ 0x8c, 0xcf, 0xb8, 0xf1, 0xa8, 0xf2, 0x89, 0x00
+};
+
+static const struct qm1d1c0042_config default_cfg = {
+ .init_freq = 0,
+ .xtal_freq = 16000,
+ .lpf = 1,
+ .fast_srch = 0,
+ .lpf_wait = 20,
+ .fast_srch_wait = 4,
+ .normal_srch_wait = 15,
+};
+
+struct qm1d1c0042_state {
+ struct qm1d1c0042_config cfg;
+ struct i2c_adapter *i2c;
+ struct dvb_frontend *fe;
+ u8 regs[QM1D1C0042_NUM_REGS];
+};
+
+static int reg_write(struct qm1d1c0042_state *state, u8 reg, u8 val)
+{
+ u8 wbuf[2] = { reg, val };
+ struct i2c_msg msg = {
+ .addr = state-cfg.addr,
+ .flags = 0,
+ .buf = wbuf,
+ .len = 2,
+ };
+ return i2c_transfer(state-i2c, msg, 1);
+}
+
+
+static int reg_read(struct qm1d1c0042_state *state, u8 reg, u8 *val)
+{
+ struct i2c_msg msgs[2] = {
+ {
+ .addr = state-cfg.addr,
+ .flags = 0,
+ .buf = reg,
+ .len = 1,
+ },
+ {
+ .addr = state-cfg.addr,
+ .flags = I2C_M_RD,
+ .buf = val,
+ .len = 1,
+ },
+ };
+
+ return i2c_transfer(state-i2c, msgs, ARRAY_SIZE(msgs));
+}
+
+static int qm1d1c0042_set_srch_mode(struct qm1d1c0042_state *state, bool fast)
+{
+ if (fast)
+ state-regs[0x03] |= 0x01; /* set fast search mode */
+ else
+ state-regs[0x03] = ~0x01 0xff;
+
+ return reg_write(state, 0x03, state-regs[0x03]);
+}
+
+static int qm1d1c0042_wakeup(struct qm1d1c0042_state *state)
+{
+ int ret;
+
+ state-regs[0x01] |= 1 3; /* BB_Reg_enable */
+ state-regs[0x01] = (~(1 0)) 0xff; /* NORMAL (wake-up) */
+ state-regs[0x05] = (~(1 3)) 0xff; /* pfd_rst NORMAL */
+ ret = reg_write(state, 0x01, state-regs[0x01]);
+ if (ret == 0)
+ ret = reg_write(state, 0x05, state-regs[0x05]);
+
+ if (ret 0)
+ dev_warn(state-i2c-dev, (%s) failed. [adap%d-fe%d]\n,
+ __func__,
[PATCH v2 5/5] pt3: add support for Earthsoft PT3 ISDB-S/T receiver card
From: Akihiro Tsukada tsk...@gmail.com This patch adds support for PT3 PCIe cards. PT3 has an FPGA PCIe bridge chip, a TC90522 demod chip and a VA4M6JC2103 tuner module which contains two QM1D1C0042 chips for ISDB-S and two MxL301RF's for ISDB-T. It can receive and deliver 4 (2x ISDB-S, 2x ISDB-T) streams simultaneously, and a kthread is used per stream to poll incoming data, because PT3 does not have interrupts. As an antenna input for each delivery system is split in the tuner module and shared between the corresponding two tuner chips, LNB/LNA controls that the FPGA chip provides are (naturally) shared as well. The tuner chips also share the power line in the tuner module, which is controlled on/off by a GPIO pin of the demod chip. As with the demod chip and the ISDB-T tuner chip, the init sequences/register settings for those chips are not disclosed and stored in a private memory of the FPGA, PT3 driver executes the init of those chips on behalf of their drivers. Signed-off-by: Akihiro Tsukada tsk...@gmail.com --- Changes in v2: - improved handling of kthread, including support of suspend/resume - added support of suspend/resume - improved init sequence to support live (streaming) suspend/resume - moved static const tables out of function scop drivers/media/pci/Kconfig | 1 + drivers/media/pci/Makefile | 1 + drivers/media/pci/pt3/Kconfig | 10 + drivers/media/pci/pt3/Makefile | 8 + drivers/media/pci/pt3/pt3.c | 817 drivers/media/pci/pt3/pt3.h | 179 + drivers/media/pci/pt3/pt3_dma.c | 225 +++ drivers/media/pci/pt3/pt3_i2c.c | 239 8 files changed, 1480 insertions(+) diff --git a/drivers/media/pci/Kconfig b/drivers/media/pci/Kconfig index 5c16c9c..89bd2a5 100644 --- a/drivers/media/pci/Kconfig +++ b/drivers/media/pci/Kconfig @@ -41,6 +41,7 @@ source drivers/media/pci/b2c2/Kconfig source drivers/media/pci/pluto2/Kconfig source drivers/media/pci/dm1105/Kconfig source drivers/media/pci/pt1/Kconfig +source drivers/media/pci/pt3/Kconfig source drivers/media/pci/mantis/Kconfig source drivers/media/pci/ngene/Kconfig source drivers/media/pci/ddbridge/Kconfig diff --git a/drivers/media/pci/Makefile b/drivers/media/pci/Makefile index dc2ebbe..9db6775 100644 --- a/drivers/media/pci/Makefile +++ b/drivers/media/pci/Makefile @@ -7,6 +7,7 @@ obj-y+= ttpci/ \ pluto2/ \ dm1105/ \ pt1/\ + pt3/\ mantis/ \ ngene/ \ ddbridge/ \ diff --git a/drivers/media/pci/pt3/Kconfig b/drivers/media/pci/pt3/Kconfig new file mode 100644 index 000..16c208a --- /dev/null +++ b/drivers/media/pci/pt3/Kconfig @@ -0,0 +1,10 @@ +config DVB_PT3 + tristate Earthsoft PT3 cards + depends on DVB_CORE PCI I2C + select DVB_TC90522 if MEDIA_SUBDRV_AUTOSELECT + select MEDIA_TUNER_QM1D1C0042 if MEDIA_SUBDRV_AUTOSELECT + select MEDIA_TUNER_MXL301RF if MEDIA_SUBDRV_AUTOSELECT + help + Support for Earthsoft PT3 PCIe cards. + + Say Y or M if you own such a device and want to use it. diff --git a/drivers/media/pci/pt3/Makefile b/drivers/media/pci/pt3/Makefile new file mode 100644 index 000..396f146 --- /dev/null +++ b/drivers/media/pci/pt3/Makefile @@ -0,0 +1,8 @@ + +earth-pt3-objs += pt3.o pt3_i2c.o pt3_dma.o + +obj-$(CONFIG_DVB_PT3) += earth-pt3.o + +ccflags-y += -Idrivers/media/dvb-core +ccflags-y += -Idrivers/media/dvb-frontends +ccflags-y += -Idrivers/media/tuners diff --git a/drivers/media/pci/pt3/pt3.c b/drivers/media/pci/pt3/pt3.c new file mode 100644 index 000..902eca5 --- /dev/null +++ b/drivers/media/pci/pt3/pt3.c @@ -0,0 +1,817 @@ +/* + * Earthsoft PT3 driver + * + * Copyright (C) 2014 Akihiro Tsukada tsk...@gmail.com + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation version 2. + * + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ + +#include linux/freezer.h +#include linux/kernel.h +#include linux/kthread.h +#include linux/mutex.h +#include linux/module.h +#include linux/pci.h +#include linux/string.h + +#include dmxdev.h +#include dvbdev.h +#include dvb_demux.h +#include dvb_frontend.h + +#include pt3.h + +DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr); + +static bool one_adapter; +module_param(one_adapter, bool, 0444); +MODULE_PARM_DESC(one_adapter, Place FE's together under one adapter.); + +static int num_bufs = 4; +module_param(num_bufs, int, 0444); +MODULE_PARM_DESC(num_bufs, Number of DMA buffer (188KiB) per FE.); + + +static const struct
[PATCH v2 2/5] mxl301rf: add driver for MaxLinear MxL301RF OFDM tuner
From: Akihiro Tsukada tsk...@gmail.com
This patch adds driver for mxl301rf OFDM tuner chips.
It is used as an ISDB-T tuner in earthsoft pt3 cards.
Note that this driver does not initilize the chip,
because the initilization sequence / register setting is not disclosed.
Thus, the driver assumes that the chips are initilized externally
by its parent board driver before tuner_ops-init() are called,
like in PT3 driver where the bridge chip contains the init sequence
in its private memory and provides a command to trigger the sequence.
Signed-off-by: Akihiro Tsukada tsk...@gmail.com
---
Changes in v2:
- use new tuner ops for get_signal_strengh() for DVBv5 API
- removed automatic frequency adjustment
- moved static const tables out of function scope
- extend max acceptable frequency to accept ISDB-Tb
drivers/media/tuners/Kconfig| 7 +
drivers/media/tuners/Makefile | 1 +
drivers/media/tuners/mxl301rf.c | 334
drivers/media/tuners/mxl301rf.h | 40 +
4 files changed, 382 insertions(+)
diff --git a/drivers/media/tuners/Kconfig b/drivers/media/tuners/Kconfig
index d79fd1c..cd3f8ee 100644
--- a/drivers/media/tuners/Kconfig
+++ b/drivers/media/tuners/Kconfig
@@ -257,4 +257,11 @@ config MEDIA_TUNER_R820T
default m if !MEDIA_SUBDRV_AUTOSELECT
help
Rafael Micro R820T silicon tuner driver.
+
+config MEDIA_TUNER_MXL301RF
+ tristate MaxLinear MxL301RF tuner
+ depends on MEDIA_SUPPORT I2C
+ default m if !MEDIA_SUBDRV_AUTOSELECT
+ help
+ MaxLinear MxL301RF OFDM tuner driver.
endmenu
diff --git a/drivers/media/tuners/Makefile b/drivers/media/tuners/Makefile
index 5591699..6d5bf48 100644
--- a/drivers/media/tuners/Makefile
+++ b/drivers/media/tuners/Makefile
@@ -39,6 +39,7 @@ obj-$(CONFIG_MEDIA_TUNER_FC0012) += fc0012.o
obj-$(CONFIG_MEDIA_TUNER_FC0013) += fc0013.o
obj-$(CONFIG_MEDIA_TUNER_IT913X) += tuner_it913x.o
obj-$(CONFIG_MEDIA_TUNER_R820T) += r820t.o
+obj-$(CONFIG_MEDIA_TUNER_MXL301RF) += mxl301rf.o
ccflags-y += -I$(srctree)/drivers/media/dvb-core
ccflags-y += -I$(srctree)/drivers/media/dvb-frontends
diff --git a/drivers/media/tuners/mxl301rf.c b/drivers/media/tuners/mxl301rf.c
new file mode 100644
index 000..11ac7b8
--- /dev/null
+++ b/drivers/media/tuners/mxl301rf.c
@@ -0,0 +1,334 @@
+/*
+ * MaxLinear MxL301RF OFDM tuner driver
+ *
+ * Copyright (C) 2014 Akihiro Tsukada tsk...@gmail.com
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include mxl301rf.h
+
+struct mxl301rf_state {
+ struct mxl301rf_config cfg;
+ struct i2c_adapter *i2c;
+};
+
+static int data_write(struct mxl301rf_state *state, const u8 *buf, int len)
+{
+ struct i2c_msg msg = {
+ .addr = state-cfg.addr,
+ .flags = 0,
+ .buf = (u8 *)buf,
+ .len = len,
+ };
+
+ return i2c_transfer(state-i2c, msg, 1);
+}
+
+static int reg_write(struct mxl301rf_state *state, u8 reg, u8 val)
+{
+ u8 buf[2] = { reg, val };
+
+ return data_write(state, buf, 2);
+}
+
+static int reg_read(struct mxl301rf_state *state, u8 reg, u8 *val)
+{
+ u8 wbuf[2] = { 0xfb, reg };
+ struct i2c_msg msgs[2] = {
+ {
+ .addr = state-cfg.addr,
+ .flags = 0,
+ .buf = wbuf,
+ .len = 2,
+ },
+ {
+ .addr = state-cfg.addr,
+ .flags = I2C_M_RD,
+ .buf = val,
+ .len = 1,
+ }
+ };
+
+ return i2c_transfer(state-i2c, msgs, ARRAY_SIZE(msgs));
+}
+
+/* tuner_ops */
+
+static int mxl301rf_get_status(struct dvb_frontend *fe, u32 *status)
+{
+ struct mxl301rf_state *state;
+ int ret;
+ u8 val;
+
+ *status = 0;
+ state = fe-tuner_priv;
+ ret = reg_read(state, 0x16, val); /* check RF Synthesizer lock */
+ if (ret 0 || (val 0x0c) != 0x0c)
+ return ret;
+ ret = reg_read(state, 0x16, val); /* check REF Synthesizer lock */
+ if (ret 0 || (val 0x03) != 0x03)
+ return ret;
+ *status = TUNER_STATUS_LOCKED;
+ return 0;
+}
+
+/* *strength : [0.001dBm] */
+static int mxl301rf_get_rf_strength(struct dvb_frontend *fe, s64 *strength)
+{
+ struct mxl301rf_state *state;
+ int ret;
+ u8 rf_in1, rf_in2, rf_off1, rf_off2;
+ u16 rf_in, rf_off;
+
+ *strength = 0;
+ state = fe-tuner_priv;
+ ret = reg_write(state,
[RFI] OMAP4 ISS: l3_interrupt_handler Errors due to wrong initialized iss_fck?
Hi,
I am trying to get both CSI2 interfaces up and running through the ISS
on the v3.16 kernel for the TI OMAP4 Blaze platform (omap4430 ES 2.3
revision).
Trough a omap_device_build() call (using the iss omap_hwmod) I call the
iss_probe function. It devm_clk_get's both the iss_ctrlclk and the iss_fck.
Since I am building the kernel with the omap4-sdp-es23plus device tree
appended, I figured I need to define the iss_fck in the omap44xx-clocks.dtsi
file, right after the iss_ctrlclk, as following:
iss_fck: iss_fck {
#clock-cells = 0;
compatible = ti,gate-clock;
clocks = ducati_clk_mux_ck;
ti,bit-shift = 1;
reg = 0x1020;
};
For that, I used the information in [1], the TI clock tree tool and the
Linux documentation.
Now the omap4iss_get() call throws L3 Standard Errors, right after the first
time the interrupts, set in iss_enable_interrupts, occur. I am pretty sure the
cause for that is a wrong initialization of the iss_fck (since I haven't
changed much more), even though the kernel runs through and the
cat clk_summary ¦ grep iss command in /sys/kernel/debug/clk/ writes:
iss_ctrlclk 019600 0
iss_fck 01 4 0
Could there be an error in the device tree entry stated above? Or might I be
missing something else? Has anyone ever enabled iss_fck through device tree?
BTW I've also added iss_fck as an opt_clk in omap_hwmod_44xx_data and added
the clock to the ti_dt_clk struct.
Thanks,
Martin
[1] http://www.ti.com/pdfs/wtbu/OMAP4430_ES2.x_PUBLIC_TRM_vAJ.zip
--
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 4/5] tc90522: add driver for Toshiba TC90522 quad demodulator
From: Akihiro Tsukada tsk...@gmail.com
This patch adds driver for tc90522 demodulator chips.
The chip contains 4 demod modules that run in parallel and are independently
controllable via separate I2C addresses.
Two of the modules are for ISDB-T and the rest for ISDB-S.
It is used in earthsoft pt3 cards.
Note that this driver does not init the chip,
because the initilization sequence / register setting is not disclosed.
Thus, the driver assumes that the chips are initilized externally
by its parent board driver before fe-ops-init() are called.
Earthsoft PT3 PCIe card, for example, contains the init sequence
in its private memory and provides a command to trigger the sequence.
Signed-off-by: Akihiro Tsukada tsk...@gmail.com
---
Changes in v2:
- renamed badly named variables
- moved static const tables out of function scope
- calculate symbol rate per output TS
- improve in _init() to support suspend/resume
drivers/media/dvb-frontends/Kconfig | 8 +
drivers/media/dvb-frontends/Makefile | 1 +
drivers/media/dvb-frontends/tc90522.c | 857 ++
drivers/media/dvb-frontends/tc90522.h | 63 +++
4 files changed, 929 insertions(+)
diff --git a/drivers/media/dvb-frontends/Kconfig
b/drivers/media/dvb-frontends/Kconfig
index aa5ae22..123adb2 100644
--- a/drivers/media/dvb-frontends/Kconfig
+++ b/drivers/media/dvb-frontends/Kconfig
@@ -648,6 +648,14 @@ config DVB_MB86A20S
A driver for Fujitsu mb86a20s ISDB-T/ISDB-Tsb demodulator.
Say Y when you want to support this frontend.
+config DVB_TC90522
+ tristate Toshiba TC90522
+ depends on DVB_CORE I2C
+ default m if !MEDIA_SUBDRV_AUTOSELECT
+ help
+ A Toshiba TC90522 2xISDB-T + 2xISDB-S demodulator.
+ Say Y when you want to support this frontend.
+
comment Digital terrestrial only tuners/PLL
depends on DVB_CORE
diff --git a/drivers/media/dvb-frontends/Makefile
b/drivers/media/dvb-frontends/Makefile
index fc4e689..00cc299 100644
--- a/drivers/media/dvb-frontends/Makefile
+++ b/drivers/media/dvb-frontends/Makefile
@@ -114,3 +114,4 @@ obj-$(CONFIG_DVB_RTL2832_SDR) += rtl2832_sdr.o
obj-$(CONFIG_DVB_M88RS2000) += m88rs2000.o
obj-$(CONFIG_DVB_AF9033) += af9033.o
obj-$(CONFIG_DVB_AS102_FE) += as102_fe.o
+obj-$(CONFIG_DVB_TC90522) += tc90522.o
diff --git a/drivers/media/dvb-frontends/tc90522.c
b/drivers/media/dvb-frontends/tc90522.c
new file mode 100644
index 000..1f0f6f7
--- /dev/null
+++ b/drivers/media/dvb-frontends/tc90522.c
@@ -0,0 +1,857 @@
+/*
+ * Toshiba TC90522 Demodulator
+ *
+ * Copyright (C) 2014 Akihiro Tsukada tsk...@gmail.com
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/kernel.h
+#include linux/dvb/frontend.h
+#include dvb_math.h
+#include tc90522.h
+
+#define TC90522_I2C_THRU_REG 0xfe
+
+#define TC90522_MODULE_IDX(addr) (((u8)(addr) 0x02U) 1)
+
+enum tc90522_tuning_status {
+ STATUS_IDLE,
+ STATUS_SET_FREQ,
+ STATUS_CHECK_TUNER,
+ STATUS_CHECK_DEMOD,
+ STATUS_TRACK,
+};
+
+struct tc90522_state {
+ struct dvb_frontend dvb_fe;
+
+ struct tc90522_config cfg;
+ struct i2c_adapter *i2c;
+ struct i2c_adapter tuner_i2c;
+ enum tc90522_tuning_status tuning_status;
+ int retry_count;
+
+ bool lna;
+};
+
+struct reg_val {
+ u8 reg;
+ u8 val;
+};
+
+
+static int
+reg_write(struct tc90522_state *state, const struct reg_val *regs, int num)
+{
+ int i, ret;
+ struct i2c_msg msg;
+
+ ret = 0;
+ msg.addr = state-cfg.addr;
+ msg.flags = 0;
+ msg.len = 2;
+ for (i = 0; i num; i++) {
+ msg.buf = (u8 *)regs[i];
+ ret = i2c_transfer(state-i2c, msg, 1);
+ if (ret 0)
+ break;
+ }
+ return ret;
+}
+
+static int reg_read(struct tc90522_state *state, u8 reg, u8 *val, u8 len)
+{
+ struct i2c_msg msgs[2] = {
+ {
+ .addr = state-cfg.addr,
+ .flags = 0,
+ .buf = reg,
+ .len = 1,
+ },
+ {
+ .addr = state-cfg.addr,
+ .flags = I2C_M_RD,
+ .buf = val,
+ .len = len,
+ },
+ };
+
+ return i2c_transfer(state-i2c, msgs, ARRAY_SIZE(msgs));
+}
+
+static int enable_lna(struct dvb_frontend *fe, bool on)
+{
+ struct tc90522_state *state;
+
+ state = fe-demodulator_priv;
+ /* delegate to the parent
[PATCH v2 0/5] dvb: Add support for PT3 ISDB-S/T card
From: Akihiro Tsukada tsk...@gmail.com This patch series adds support for PT3 ISDB-S/T receiver cards. It contains a PCI bridge driver, a dvb-frontend driver and two tuner drivers. I know Bud R had already posted ones to this mailing list, (as in 1400629035-32487-1-git-send-email-knightri...@are.ma ), but it seems that he stopped updating his patch and does not agree on splitting the single large patch into smaller, separate ones. This series is another version written independently by me. Changes in v2: - added a new tuner ops (get_signal_strength_dbm()) for DVBv5 - improved kthread handling on remove,suspend,resume - added support for suspend/resume - moved static const tables out of function scope - renamed badly named variables - changed symbol_rate calculation - other small fixes pointed out in the last review by mauro Akihiro Tsukada (5): dvb-core: add a new tuner ops to dvb_frontend for APIv5 mxl301rf: add driver for MaxLinear MxL301RF OFDM tuner qm1d1c0042: add driver for Sharp QM1D1C0042 ISDB-S tuner tc90522: add driver for Toshiba TC90522 quad demodulator pt3: add support for Earthsoft PT3 ISDB-S/T receiver card drivers/media/dvb-core/dvb_frontend.h | 2 + drivers/media/dvb-frontends/Kconfig | 8 + drivers/media/dvb-frontends/Makefile | 1 + drivers/media/dvb-frontends/tc90522.c | 857 ++ drivers/media/dvb-frontends/tc90522.h | 63 +++ drivers/media/pci/Kconfig | 1 + drivers/media/pci/Makefile| 1 + drivers/media/pci/pt3/Kconfig | 10 + drivers/media/pci/pt3/Makefile| 8 + drivers/media/pci/pt3/pt3.c | 817 drivers/media/pci/pt3/pt3.h | 179 +++ drivers/media/pci/pt3/pt3_dma.c | 225 + drivers/media/pci/pt3/pt3_i2c.c | 239 ++ drivers/media/tuners/Kconfig | 14 + drivers/media/tuners/Makefile | 2 + drivers/media/tuners/mxl301rf.c | 334 + drivers/media/tuners/mxl301rf.h | 40 ++ drivers/media/tuners/qm1d1c0042.c | 422 + drivers/media/tuners/qm1d1c0042.h | 50 ++ 19 files changed, 3273 insertions(+) create mode 100644 drivers/media/dvb-frontends/tc90522.c create mode 100644 drivers/media/dvb-frontends/tc90522.h create mode 100644 drivers/media/pci/pt3/Kconfig create mode 100644 drivers/media/pci/pt3/Makefile create mode 100644 drivers/media/pci/pt3/pt3.c create mode 100644 drivers/media/pci/pt3/pt3.h create mode 100644 drivers/media/pci/pt3/pt3_dma.c create mode 100644 drivers/media/pci/pt3/pt3_i2c.c create mode 100644 drivers/media/tuners/mxl301rf.c create mode 100644 drivers/media/tuners/mxl301rf.h create mode 100644 drivers/media/tuners/qm1d1c0042.c create mode 100644 drivers/media/tuners/qm1d1c0042.h -- 2.1.0 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Status of g_webcam uvc-gadget
Hello Is somebody using/supporting g_webcam? The only reference userland server is uvc-gadget from http://git.ideasonboard.org/?p=uvc-gadget.git;a=summary ? I have an industrial fpga camera that speaks v4l2, my plan is to export it as an uvc camera via usb3380 as a debug interface. Thanks! -- Ricardo Ribalda -- 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: [linuxtv-media:devel 497/499] drivers/media/platform/s5p-mfc/s5p_mfc.c:454:2-5: WARNING: Use BUG_ON
The bug_on one doesn't look like a good idea, but the returnvar one would
make the code a little simpler.
julia
On Thu, 28 Aug 2014, kbuild test robot wrote:
TO: Mauro Carvalho Chehab m.che...@samsung.com
CC: linux-media@vger.kernel.org
Hi Mauro,
First bad commit (maybe != root cause):
tree: git://linuxtv.org/media_tree.git devel
head: 38a0731165250a0a77eff7b90ea3156d44cc7d66
commit: 7155043c2d027c9c848c3d09badb5af2894ed652 [497/499] [media] enable
COMPILE_TEST for media drivers
:: branch date: 19 hours ago
:: commit date: 19 hours ago
drivers/media/platform/s5p-mfc/s5p_mfc.c:454:2-5: WARNING: Use BUG_ON
drivers/media/platform/s5p-mfc/s5p_mfc.c:333:3-6: WARNING: Use BUG_ON
drivers/media/platform/s5p-mfc/s5p_mfc.c:406:2-5: WARNING: Use BUG_ON
drivers/media/platform/s5p-mfc/s5p_mfc.c:548:3-6: WARNING: Use BUG_ON
drivers/media/platform/s5p-mfc/s5p_mfc.c:556:3-6: WARNING: Use BUG_ON
drivers/media/platform/s5p-mfc/s5p_mfc.c:509:2-5: WARNING: Use BUG_ON
drivers/media/platform/s5p-mfc/s5p_mfc.c:634:4-7: WARNING: Use BUG_ON
--
drivers/media/platform/davinci/vpfe_capture.c:946:5-8: Unneeded variable:
ret. Return 0 on line 951
Please consider folding the attached diff :-)
---
0-DAY kernel build testing backend Open Source Technology Center
http://lists.01.org/mailman/listinfo/kbuild Intel Corporation
From: Fengguang Wu fengguang...@intel.com
Subject: [PATCH] fix coccinelle warnings
TO: Mauro Carvalho Chehab m.che...@samsung.com
CC: Mauro Carvalho Chehab m.che...@samsung.com
CC: linux-arm-ker...@lists.infradead.org
CC: linux-media@vger.kernel.org
CC: linux-ker...@vger.kernel.org
CC: devicet...@vger.kernel.org
drivers/media/platform/s5p-mfc/s5p_mfc.c:454:2-5: WARNING: Use BUG_ON
drivers/media/platform/s5p-mfc/s5p_mfc.c:333:3-6: WARNING: Use BUG_ON
drivers/media/platform/s5p-mfc/s5p_mfc.c:406:2-5: WARNING: Use BUG_ON
drivers/media/platform/s5p-mfc/s5p_mfc.c:548:3-6: WARNING: Use BUG_ON
drivers/media/platform/s5p-mfc/s5p_mfc.c:556:3-6: WARNING: Use BUG_ON
drivers/media/platform/s5p-mfc/s5p_mfc.c:509:2-5: WARNING: Use BUG_ON
drivers/media/platform/s5p-mfc/s5p_mfc.c:634:4-7: WARNING: Use BUG_ON
Use BUG_ON instead of a if condition followed by BUG.
Semantic patch information:
This makes an effort to find cases where BUG() follows an if
condition on an expression and replaces the if condition and BUG()
with a BUG_ON having the conditional expression of the if statement
as argument.
Generated by: scripts/coccinelle/misc/bugon.cocci
CC: Mauro Carvalho Chehab m.che...@samsung.com
Signed-off-by: Fengguang Wu fengguang...@intel.com
---
Please take the patch only if it's a positive warning. Thanks!
s5p_mfc.c | 21 +++--
1 file changed, 7 insertions(+), 14 deletions(-)
--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -329,8 +329,7 @@ static void s5p_mfc_handle_frame(struct
ctx-state = MFCINST_RES_CHANGE_INIT;
s5p_mfc_hw_call(dev-mfc_ops, clear_int_flags, dev);
wake_up_ctx(ctx, reason, err);
- if (test_and_clear_bit(0, dev-hw_lock) == 0)
- BUG();
+ BUG_ON(test_and_clear_bit(0, dev-hw_lock) == 0);
s5p_mfc_clock_off();
s5p_mfc_hw_call(dev-mfc_ops, try_run, dev);
return;
@@ -402,8 +401,7 @@ leave_handle_frame:
clear_work_bit(ctx);
s5p_mfc_hw_call(dev-mfc_ops, clear_int_flags, dev);
wake_up_ctx(ctx, reason, err);
- if (test_and_clear_bit(0, dev-hw_lock) == 0)
- BUG();
+ BUG_ON(test_and_clear_bit(0, dev-hw_lock) == 0);
s5p_mfc_clock_off();
/* if suspending, wake up device and do not try_run again*/
if (test_bit(0, dev-enter_suspend))
@@ -450,8 +448,7 @@ static void s5p_mfc_handle_error(struct
break;
}
}
- if (test_and_clear_bit(0, dev-hw_lock) == 0)
- BUG();
+ BUG_ON(test_and_clear_bit(0, dev-hw_lock) == 0);
s5p_mfc_hw_call(dev-mfc_ops, clear_int_flags, dev);
s5p_mfc_clock_off();
wake_up_dev(dev, reason, err);
@@ -505,8 +502,7 @@ static void s5p_mfc_handle_seq_done(stru
}
s5p_mfc_hw_call(dev-mfc_ops, clear_int_flags, dev);
clear_work_bit(ctx);
- if (test_and_clear_bit(0, dev-hw_lock) == 0)
- BUG();
+ BUG_ON(test_and_clear_bit(0, dev-hw_lock) == 0);
s5p_mfc_clock_off();
s5p_mfc_hw_call(dev-mfc_ops, try_run, dev);
wake_up_ctx(ctx, reason, err);
@@ -544,16 +540,14 @@ static void s5p_mfc_handle_init_buffers(
} else {
ctx-dpb_flush_flag = 0;
}
- if (test_and_clear_bit(0, dev-hw_lock) == 0)
- BUG();
+ BUG_ON(test_and_clear_bit(0, dev-hw_lock) == 0);
s5p_mfc_clock_off();
wake_up(ctx-queue);
s5p_mfc_hw_call(dev-mfc_ops, try_run, dev);
} else {
- if (test_and_clear_bit(0, dev-hw_lock) == 0)
- BUG();
+ BUG_ON(test_and_clear_bit(0, dev-hw_lock) == 0);
s5p_mfc_clock_off();
@@ -630,8 +624,7 @@ static irqreturn_t s5p_mfc_irq(int irq,
mfc_err(post_frame_start() failed\n);
s5p_mfc_hw_call(dev-mfc_ops, clear_int_flags, dev);
wake_up_ctx(ctx, reason, err);
- if
Re: randconfig build error with next-20140826, in Documentation/video4linux
Em Wed, 27 Aug 2014 07:36:05 -0700 Randy Dunlap rdun...@infradead.org escreveu: On 08/27/14 03:58, Sudip Mukherjee wrote: On Tue, Aug 26, 2014 at 09:50:43AM -0700, Jim Davis wrote: Building with the attached random configuration file, ERROR: vb2_ops_wait_finish [Documentation/video4linux/v4l2-pci-skeleton.ko] undefined! ERROR: vb2_ops_wait_prepare [Documentation/video4linux/v4l2-pci-skeleton.ko] undefined! ERROR: v4l2_event_unsubscribe [Documentation/video4linux/v4l2-pci-skeleton.ko] undefined! ERROR: v4l2_ctrl_subscribe_event [Documentation/video4linux/v4l2-pci-skeleton.ko] undefined! ERROR: v4l2_ctrl_log_status [Documentation/video4linux/v4l2-pci-skeleton.ko] undefined! ERROR: vb2_ioctl_streamoff [Documentation/video4linux/v4l2-pci-skeleton.ko] undefined! ERROR: vb2_ioctl_streamon [Documentation/video4linux/v4l2-pci-skeleton.ko] undefined! ERROR: vb2_ioctl_create_bufs [Documentation/video4linux/v4l2-pci-skeleton.ko] undefined! ERROR: vb2_ioctl_dqbuf [Documentation/video4linux/v4l2-pci-skeleton.ko] undefined! ERROR: vb2_ioctl_expbuf [Documentation/video4linux/v4l2-pci-skeleton.ko] undefined! ERROR: vb2_ioctl_qbuf [Documentation/video4linux/v4l2-pci-skeleton.ko] undefined! ERROR: vb2_ioctl_querybuf [Documentation/video4linux/v4l2-pci-skeleton.ko] undefined! ERROR: vb2_ioctl_reqbufs [Documentation/video4linux/v4l2-pci-skeleton.ko] undefined! ERROR: vb2_fop_release [Documentation/video4linux/v4l2-pci-skeleton.ko] undefined! ERROR: v4l2_fh_open [Documentation/video4linux/v4l2-pci-skeleton.ko] undefined! ERROR: vb2_fop_mmap [Documentation/video4linux/v4l2-pci-skeleton.ko] undefined! ERROR: video_ioctl2 [Documentation/video4linux/v4l2-pci-skeleton.ko] undefined! ERROR: vb2_fop_poll [Documentation/video4linux/v4l2-pci-skeleton.ko] undefined! ERROR: vb2_fop_read [Documentation/video4linux/v4l2-pci-skeleton.ko] undefined! ERROR: vb2_buffer_done [Documentation/video4linux/v4l2-pci-skeleton.ko] undefined! ERROR: __video_register_device [Documentation/video4linux/v4l2-pci-skeleton.ko] undefined! ERROR: video_device_release_empty [Documentation/video4linux/v4l2-pci-skeleton.ko] undefined! ERROR: vb2_dma_contig_init_ctx [Documentation/video4linux/v4l2-pci-skeleton.ko] undefined! ERROR: vb2_queue_init [Documentation/video4linux/v4l2-pci-skeleton.ko] undefined! ERROR: vb2_dma_contig_memops [Documentation/video4linux/v4l2-pci-skeleton.ko] undefined! ERROR: v4l2_ctrl_new_std [Documentation/video4linux/v4l2-pci-skeleton.ko] undefined! ERROR: v4l2_ctrl_handler_init_class [Documentation/video4linux/v4l2-pci-skeleton.ko] undefined! ERROR: v4l2_device_register [Documentation/video4linux/v4l2-pci-skeleton.ko] undefined! ERROR: v4l2_match_dv_timings [Documentation/video4linux/v4l2-pci-skeleton.ko] undefined! ERROR: v4l2_find_dv_timings_cap [Documentation/video4linux/v4l2-pci-skeleton.ko] undefined! ERROR: v4l2_valid_dv_timings [Documentation/video4linux/v4l2-pci-skeleton.ko] undefined! ERROR: v4l2_enum_dv_timings_cap [Documentation/video4linux/v4l2-pci-skeleton.ko] undefined! ERROR: video_devdata [Documentation/video4linux/v4l2-pci-skeleton.ko] undefined! ERROR: v4l2_device_unregister [Documentation/video4linux/v4l2-pci-skeleton.ko] undefined! ERROR: vb2_dma_contig_cleanup_ctx [Documentation/video4linux/v4l2-pci-skeleton.ko] undefined! ERROR: v4l2_ctrl_handler_free [Documentation/video4linux/v4l2-pci-skeleton.ko] undefined! ERROR: video_unregister_device [Documentation/video4linux/v4l2-pci-skeleton.ko] undefined! make[1]: *** [__modpost] Error 1 make: *** [modules] Error 2 Similar to a build error from January 7th: https://lists.01.org/pipermail/kbuild-all/2014-January/002566.html Hi, I tried to build next-20140826 with your given config file . But for me everything was fine. And I was just wondering why the skeleton code in the Documentation is building ? It builds if the Kconfig symbol BUILD_DOCSRC is enabled. Building of this module was just added to linux-next. It makes sense to add a depends on BUILD_DOCSRC, PCI and MEDIA_V4L2 inside the docs Makefile, instead of moving the Kconfig to drivers/media, IMHO. Regards, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: randconfig build error with next-20140826, in Documentation/video4linux
On 08/27/14 10:17, Mauro Carvalho Chehab wrote: Em Wed, 27 Aug 2014 07:36:05 -0700 Randy Dunlap rdun...@infradead.org escreveu: On 08/27/14 03:58, Sudip Mukherjee wrote: On Tue, Aug 26, 2014 at 09:50:43AM -0700, Jim Davis wrote: Building with the attached random configuration file, ERROR: vb2_ops_wait_finish [Documentation/video4linux/v4l2-pci-skeleton.ko] undefined! ERROR: vb2_ops_wait_prepare [Documentation/video4linux/v4l2-pci-skeleton.ko] undefined! ERROR: v4l2_event_unsubscribe [Documentation/video4linux/v4l2-pci-skeleton.ko] undefined! ERROR: v4l2_ctrl_subscribe_event [Documentation/video4linux/v4l2-pci-skeleton.ko] undefined! ERROR: v4l2_ctrl_log_status [Documentation/video4linux/v4l2-pci-skeleton.ko] undefined! ERROR: vb2_ioctl_streamoff [Documentation/video4linux/v4l2-pci-skeleton.ko] undefined! ERROR: vb2_ioctl_streamon [Documentation/video4linux/v4l2-pci-skeleton.ko] undefined! ERROR: vb2_ioctl_create_bufs [Documentation/video4linux/v4l2-pci-skeleton.ko] undefined! ERROR: vb2_ioctl_dqbuf [Documentation/video4linux/v4l2-pci-skeleton.ko] undefined! ERROR: vb2_ioctl_expbuf [Documentation/video4linux/v4l2-pci-skeleton.ko] undefined! ERROR: vb2_ioctl_qbuf [Documentation/video4linux/v4l2-pci-skeleton.ko] undefined! ERROR: vb2_ioctl_querybuf [Documentation/video4linux/v4l2-pci-skeleton.ko] undefined! ERROR: vb2_ioctl_reqbufs [Documentation/video4linux/v4l2-pci-skeleton.ko] undefined! ERROR: vb2_fop_release [Documentation/video4linux/v4l2-pci-skeleton.ko] undefined! ERROR: v4l2_fh_open [Documentation/video4linux/v4l2-pci-skeleton.ko] undefined! ERROR: vb2_fop_mmap [Documentation/video4linux/v4l2-pci-skeleton.ko] undefined! ERROR: video_ioctl2 [Documentation/video4linux/v4l2-pci-skeleton.ko] undefined! ERROR: vb2_fop_poll [Documentation/video4linux/v4l2-pci-skeleton.ko] undefined! ERROR: vb2_fop_read [Documentation/video4linux/v4l2-pci-skeleton.ko] undefined! ERROR: vb2_buffer_done [Documentation/video4linux/v4l2-pci-skeleton.ko] undefined! ERROR: __video_register_device [Documentation/video4linux/v4l2-pci-skeleton.ko] undefined! ERROR: video_device_release_empty [Documentation/video4linux/v4l2-pci-skeleton.ko] undefined! ERROR: vb2_dma_contig_init_ctx [Documentation/video4linux/v4l2-pci-skeleton.ko] undefined! ERROR: vb2_queue_init [Documentation/video4linux/v4l2-pci-skeleton.ko] undefined! ERROR: vb2_dma_contig_memops [Documentation/video4linux/v4l2-pci-skeleton.ko] undefined! ERROR: v4l2_ctrl_new_std [Documentation/video4linux/v4l2-pci-skeleton.ko] undefined! ERROR: v4l2_ctrl_handler_init_class [Documentation/video4linux/v4l2-pci-skeleton.ko] undefined! ERROR: v4l2_device_register [Documentation/video4linux/v4l2-pci-skeleton.ko] undefined! ERROR: v4l2_match_dv_timings [Documentation/video4linux/v4l2-pci-skeleton.ko] undefined! ERROR: v4l2_find_dv_timings_cap [Documentation/video4linux/v4l2-pci-skeleton.ko] undefined! ERROR: v4l2_valid_dv_timings [Documentation/video4linux/v4l2-pci-skeleton.ko] undefined! ERROR: v4l2_enum_dv_timings_cap [Documentation/video4linux/v4l2-pci-skeleton.ko] undefined! ERROR: video_devdata [Documentation/video4linux/v4l2-pci-skeleton.ko] undefined! ERROR: v4l2_device_unregister [Documentation/video4linux/v4l2-pci-skeleton.ko] undefined! ERROR: vb2_dma_contig_cleanup_ctx [Documentation/video4linux/v4l2-pci-skeleton.ko] undefined! ERROR: v4l2_ctrl_handler_free [Documentation/video4linux/v4l2-pci-skeleton.ko] undefined! ERROR: video_unregister_device [Documentation/video4linux/v4l2-pci-skeleton.ko] undefined! make[1]: *** [__modpost] Error 1 make: *** [modules] Error 2 Similar to a build error from January 7th: https://lists.01.org/pipermail/kbuild-all/2014-January/002566.html Hi, I tried to build next-20140826 with your given config file . But for me everything was fine. And I was just wondering why the skeleton code in the Documentation is building ? It builds if the Kconfig symbol BUILD_DOCSRC is enabled. Building of this module was just added to linux-next. It makes sense to add a depends on BUILD_DOCSRC, PCI and MEDIA_V4L2 inside the docs Makefile, instead of moving the Kconfig to drivers/media, IMHO. No, the dependencies should be in a Kconfig file, not in a Makefile. If you insist, I'll look into moving the Kconfig contents into Documentation/. -- ~Randy -- 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: randconfig build error with next-20140826, in Documentation/video4linux
On Wed, Aug 27, 2014 at 3:58 AM, Sudip Mukherjee sudipm.mukher...@gmail.com wrote: Hi, I tried to build next-20140826 with your given config file . But for me everything was fine. Well, you should be able to reproduce it. Do these steps work for you? jim@krebstar:~/linux2$ git checkout next-20140826 HEAD is now at 1c9e4561f3b2... Add linux-next specific files for 20140826 jim@krebstar:~/linux2$ git clean -fdx jim@krebstar:~/linux2$ cp ~/randconfig-1409069188.txt .config jim@krebstar:~/linux2$ make oldconfig HOSTCC scripts/basic/fixdep HOSTCC scripts/kconfig/conf.o SHIPPED scripts/kconfig/zconf.tab.c SHIPPED scripts/kconfig/zconf.lex.c SHIPPED scripts/kconfig/zconf.hash.c HOSTCC scripts/kconfig/zconf.tab.o HOSTLD scripts/kconfig/conf scripts/kconfig/conf --oldconfig Kconfig # # configuration written to .config # jim@krebstar:~/linux2$ make -j4 buildlog.txt 21 jim@krebstar:~/linux2$ grep ERROR buildlog.txt ERROR: vb2_ops_wait_finish [Documentation/video4linux/v4l2-pci-skeleton.ko] undefined! (followed by many more similar lines). -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/5] dvb-core: add a new tuner ops to dvb_frontend for APIv5
Moikka
I have feeling DVBv5 API is aimed to transfer data via property cached.
I haven't done much driver for DVBv5 statistics, but recently I
implemented CNR (DVBv5 stats) to Si2168 driver and it just writes all
the values directly to property cache. I expect RF strength (RSSI) is
just similar.
Antti
On 08/27/2014 06:29 PM, tsk...@gmail.com wrote:
From: Akihiro Tsukada tsk...@gmail.com
fe-ops.tuner_ops.get_rf_strength() reports its result in u16,
while in DVB APIv5 it should be reported in s64 and by 0.001dBm.
Signed-off-by: Akihiro Tsukada tsk...@gmail.com
---
drivers/media/dvb-core/dvb_frontend.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/media/dvb-core/dvb_frontend.h
b/drivers/media/dvb-core/dvb_frontend.h
index 816269e..f6222b5 100644
--- a/drivers/media/dvb-core/dvb_frontend.h
+++ b/drivers/media/dvb-core/dvb_frontend.h
@@ -222,6 +222,8 @@ struct dvb_tuner_ops {
#define TUNER_STATUS_STEREO 2
int (*get_status)(struct dvb_frontend *fe, u32 *status);
int (*get_rf_strength)(struct dvb_frontend *fe, u16 *strength);
+ /** get signal strengh in 0.001dBm, in accordance with APIv5 */
+ int (*get_rf_strength_dbm)(struct dvb_frontend *fe, s64 *strength);
int (*get_afc)(struct dvb_frontend *fe, s32 *afc);
/** These are provided separately from set_params in order to
facilitate silicon
--
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
[linuxtv-media:devel 497/499] drivers/media/platform/s5p-mfc/s5p_mfc_enc.c:1775:3: warning: format '%zx' expects argument of type 'size_t', but argument 6 has type 'dma_addr_t'
tree: git://linuxtv.org/media_tree.git devel head: 38a0731165250a0a77eff7b90ea3156d44cc7d66 commit: 7155043c2d027c9c848c3d09badb5af2894ed652 [497/499] [media] enable COMPILE_TEST for media drivers config: make ARCH=x86_64 allmodconfig All warnings: drivers/media/platform/s5p-mfc/s5p_mfc_enc.c:803:17: sparse: incompatible types in conditional expression (different base types) drivers/media/platform/s5p-mfc/s5p_mfc_enc.c:828:9: sparse: incompatible types in conditional expression (different base types) drivers/media/platform/s5p-mfc/s5p_mfc_enc.c:861:17: sparse: incompatible types in conditional expression (different base types) drivers/media/platform/s5p-mfc/s5p_mfc_enc.c:1127:17: sparse: incompatible types in conditional expression (different base types) drivers/media/platform/s5p-mfc/s5p_mfc_enc.c:1704:25: sparse: incompatible types in conditional expression (different base types) drivers/media/platform/s5p-mfc/s5p_mfc_enc.c:1948:9: sparse: incompatible types in conditional expression (different base types) drivers/media/platform/s5p-mfc/s5p_mfc_enc.c:1969:17: sparse: incompatible types in conditional expression (different base types) drivers/media/platform/s5p-mfc/s5p_mfc_enc.c:1976:17: sparse: incompatible types in conditional expression (different base types) drivers/media/platform/s5p-mfc/s5p_mfc_enc.c:2017:9: sparse: incompatible types in conditional expression (different base types) drivers/media/platform/s5p-mfc/s5p_mfc_enc.c: In function 'check_vb_with_fmt': drivers/media/platform/s5p-mfc/s5p_mfc_enc.c:1775:3: warning: format '%zx' expects argument of type 'size_t', but argument 6 has type 'dma_addr_t' [-Wformat=] mfc_debug(2, index: %d, plane[%d] cookie: 0x%08zx\n, ^ drivers/media/platform/s5p-mfc/s5p_mfc_enc.c: In function 's5p_mfc_buf_prepare': drivers/media/platform/s5p-mfc/s5p_mfc_enc.c:1897:3: warning: format '%d' expects argument of type 'int', but argument 5 has type 'size_t' [-Wformat=] mfc_debug(2, plane size: %ld, dst size: %d\n, ^ sparse warnings: (new ones prefixed by ) drivers/media/rc/st_rc.c:107:38: sparse: incorrect type in argument 1 (different address spaces) drivers/media/rc/st_rc.c:107:38:expected void const volatile [noderef] asn:2*addr drivers/media/rc/st_rc.c:107:38:got void * drivers/media/rc/st_rc.c:110:53: sparse: incorrect type in argument 1 (different address spaces) drivers/media/rc/st_rc.c:110:53:expected void const volatile [noderef] asn:2*addr drivers/media/rc/st_rc.c:110:53:got void * drivers/media/rc/st_rc.c:116:54: sparse: incorrect type in argument 2 (different address spaces) drivers/media/rc/st_rc.c:116:54:expected void volatile [noderef] asn:2*addr drivers/media/rc/st_rc.c:116:54:got void * drivers/media/rc/st_rc.c:120:45: sparse: incorrect type in argument 1 (different address spaces) drivers/media/rc/st_rc.c:120:45:expected void const volatile [noderef] asn:2*addr drivers/media/rc/st_rc.c:120:45:got void * drivers/media/rc/st_rc.c:121:43: sparse: incorrect type in argument 1 (different address spaces) drivers/media/rc/st_rc.c:121:43:expected void const volatile [noderef] asn:2*addr drivers/media/rc/st_rc.c:121:43:got void * drivers/media/rc/st_rc.c:150:46: sparse: incorrect type in argument 1 (different address spaces) drivers/media/rc/st_rc.c:150:46:expected void const volatile [noderef] asn:2*addr drivers/media/rc/st_rc.c:150:46:got void * drivers/media/rc/st_rc.c:153:42: sparse: incorrect type in argument 2 (different address spaces) drivers/media/rc/st_rc.c:153:42:expected void volatile [noderef] asn:2*addr drivers/media/rc/st_rc.c:153:42:got void * drivers/media/rc/st_rc.c:174:32: sparse: incorrect type in argument 2 (different address spaces) drivers/media/rc/st_rc.c:174:32:expected void volatile [noderef] asn:2*addr drivers/media/rc/st_rc.c:174:32:got void * drivers/media/rc/st_rc.c:177:48: sparse: incorrect type in argument 2 (different address spaces) drivers/media/rc/st_rc.c:177:48:expected void volatile [noderef] asn:2*addr drivers/media/rc/st_rc.c:177:48:got void * drivers/media/rc/st_rc.c:187:48: sparse: incorrect type in argument 2 (different address spaces) drivers/media/rc/st_rc.c:187:48:expected void volatile [noderef] asn:2*addr drivers/media/rc/st_rc.c:187:48:got void * drivers/media/rc/st_rc.c:204:42: sparse: incorrect type in argument 2 (different address spaces) drivers/media/rc/st_rc.c:204:42:expected void volatile [noderef] asn:2*addr drivers/media/rc/st_rc.c:204:42:got void * drivers/media/rc/st_rc.c:205:35: sparse: incorrect type in argument 2 (different address spaces) drivers/media/rc/st_rc.c:205:35:expected void volatile [noderef] asn:2*addr drivers/media/rc/st_rc.c:205:35:got void * drivers/media/rc/st_rc.c:215:35: sparse:
cron job: media_tree daily build: WARNINGS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Thu Aug 28 04:00:19 CEST 2014 git branch: test git hash: b250392f7b5062cf026b1423e27265e278fd6b30 gcc version:i686-linux-gcc (GCC) 4.9.1 sparse version: v0.5.0-20-g7abd8a7 host hardware: x86_64 host os:3.16-1.slh.1-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux-git-blackfin: OK 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.32.27-i686: OK linux-2.6.33.7-i686: OK linux-2.6.34.7-i686: OK linux-2.6.35.9-i686: OK linux-2.6.36.4-i686: OK linux-2.6.37.6-i686: OK linux-2.6.38.8-i686: OK linux-2.6.39.4-i686: OK linux-3.0.60-i686: OK linux-3.1.10-i686: OK linux-3.2.37-i686: OK linux-3.3.8-i686: OK linux-3.4.27-i686: OK linux-3.5.7-i686: OK linux-3.6.11-i686: OK linux-3.7.4-i686: OK linux-3.8-i686: OK linux-3.9.2-i686: OK linux-3.10.1-i686: OK linux-3.11.1-i686: OK linux-3.12.23-i686: OK linux-3.13.11-i686: OK linux-3.14.9-i686: OK linux-3.15.2-i686: OK linux-3.16-i686: OK linux-3.17-rc1-i686: OK linux-2.6.32.27-x86_64: OK linux-2.6.33.7-x86_64: OK linux-2.6.34.7-x86_64: OK linux-2.6.35.9-x86_64: OK linux-2.6.36.4-x86_64: OK linux-2.6.37.6-x86_64: OK linux-2.6.38.8-x86_64: OK linux-2.6.39.4-x86_64: OK linux-3.0.60-x86_64: OK linux-3.1.10-x86_64: OK linux-3.2.37-x86_64: OK linux-3.3.8-x86_64: OK linux-3.4.27-x86_64: OK linux-3.5.7-x86_64: OK linux-3.6.11-x86_64: OK linux-3.7.4-x86_64: OK linux-3.8-x86_64: OK linux-3.9.2-x86_64: OK linux-3.10.1-x86_64: OK linux-3.11.1-x86_64: OK linux-3.12.23-x86_64: OK linux-3.13.11-x86_64: OK linux-3.14.9-x86_64: OK linux-3.15.2-x86_64: OK linux-3.16-x86_64: OK linux-3.17-rc1-x86_64: OK apps: WARNINGS spec-git: OK sparse: WARNINGS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.tar.bz2 The 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: Advice on DVB-S/S2 card and CAM support
On 07/28/2014 01:44 AM, Kaya Saman wrote: Hi, I'm wondering what the best solution for getting satellite working on Linux is? Currently I have a satellite box with CAM module branded by the Satellite TV provider we are with. As I am now migrating everything including TV through my HTPC environment I would also like to link the satellite box up to the HTPC too to take advantage of the PVR and streaming capabilities. I run XBMC as my frontend so I was looking into TV Headend to take care of PVR side of things. My greatest issue though is what is the best solution for getting the satellite system into the HTPC? After some research my first idea was to use a satellite tuner card; models are available for Hauppauge and other vendors so really it was about which was going to offer best compatibility with Linux? (distro is Arch Linux with 3.15 kernel) The model of card I was looking was from DVB-Sky: http://www.dvbsky.net/Products_S950C.html something like that, which has CAM module slot and is DVB-S/S2 compatible and claims to have drivers supported by the Linuxtv project. Or alternately going for something like this: http://www.dvbsky.net/Products_T9580.html as it has a combined DVB-T tuner, then using a USB card reader for the CAM smart card. Has anyone used the cards above, what are the opinions relating to them? Also would they work with motorized dishes? Since I'm not sure if all CAM's are supported as apparently our satellite tv provider wanted to lock out other receivers so they force people to use their own product; my second idea was to perhaps use a capture card with RCA inputs. Something like this: http://www.c21video.com/viewcast/osprey-210.html perhaps or a Hauppauge HD-PVR mk I edition: which according to the wiki is supported. Looking forward to hearing advice. Thanks. Kaya -- 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 Hi Kaya, RCA inputs is probably the last thing you want. Less quality, more of a pain to set up. You may or may not be able to use that CAM - but even if it's supported, a CAM has downsides. It generally only supports one channel at a time - and surely not multiple channels from different frequencies (if you have more tuners). And it's more expensive, both the tuner (that needs a CI slot) and the CAM you need. Also, I'm not sure if tvheadend nowadays supports a CAM - it used not to, but support may have been added. The main downside of a phoenix-mode cardreader is that it's harder to set up, but if you can find a guide for your provider it's generally doable. It's cheaper, more flexible and allows for faster channel switching. As for a tuner, I personally suggest going for a USB-tuner. You never know if you want to connect you tuner to a notebook or NAS or anything in the future, with USB you're more flexible. If you do go for PCI-e, Tevii appears to have some supported products that are also available. If you go for USB, support is somewhat problematic (problematic because many supported tuners are no longer available in stores), you'll have to see what's locally available. (perhaps also check second-hand) Be careful, some devices have various revisions. Always check http://linuxtv.org/wiki/index.php/Hardware_Device_Information Very recently, Antti reviewed a patch from nibble.max to support the DVBsky S960. (and presumably it's direct clones from Mystique) This is a pretty cheap tuner that can still be found in shops. It would appear that as soon as this patch gets merged, this device will be supported if you compile v4l-dvb yourself, and in time support will make it into the kernel. In any case, you want something with in-kernel support - something that's only supported by s2-liplianin or vendor drivers (like many dvbsky and TBS products) will only break in the long term. Only exception to this is Sundtek, but I personally have mixed feelings about closed source userspace drivers. I wouldn't recommend them personally. Good luck, P. van Gaans -- 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
