mobile apps for you
Do you need mobile apps development? We can do it for you. We are an India base company. Here are the details about us: Years in business: 8 Staffs: 125 App developed: 350 We work on Android, iOS, Ionic, and PhoneGap platforms, we have clients across different kind of industries. Such like retail, media and entertainment, BFSI, hospitality, social media, eCommerce, food and beverages, etc. We do below: Mobile Apps Mobile App UI/UX designing App Maintenance and Support Website or ecommerce portal development Please reply back if you are interested in what we do. We will share our portfolios to you. Regards, Jack
mobile apps design
Do you need mobile apps development? We can do it for you. We are an India base company. Here are the details about us: Years in business: 8 Staffs: 125 App developed: 350 We work on Android, iOS, Ionic, and PhoneGap platforms, we have clients across different kind of industries. Such like retail, media and entertainment, BFSI, hospitality, social media, eCommerce, food and beverages, etc. We do below: Mobile Apps Mobile App UI/UX designing App Maintenance and Support Website or ecommerce portal development Please reply back if you are interested in what we do. We will share our portfolios to you. Regards, Jack
we do mobile apps
Do you need mobile apps development? We can do it for you. We are an India base company. Here are the details about us: Years in business: 8 Staffs: 125 App developed: 350 We work on Android, iOS, Ionic, and PhoneGap platforms, we have clients across different kind of industries. Such like retail, media and entertainment, BFSI, hospitality, social media, eCommerce, food and beverages, etc. We do below: Mobile Apps Mobile App UI/UX designing App Maintenance and Support Website or ecommerce portal development Please reply back if you are interested in what we do. We will share our portfolios to you. Regards, Jack
Hello gorgeous
Good day dear, i hope this letter meets you well? my name is Jack, I know this may seem inappropriate so i ask for your forgiveness, i wish to get to know you better, if I may be so bold. I consider myself an easy-going man, adventurous, honest and fun loving person but I am currently looking for a relationship in which I will feel loved. I promise to answer any question that you may want to ask me...all i need is just your attention and the chance to know you more. Please tell me more about yourself, if you do not mind. Hope to hear back from you soon and i hope this letter will be the beginning of a lasting communication between us. Jack.
Hello Beautiful
Hi Dear, my name is Jack and i am seeking for a relationship in which i will feel loved after a series of failed relationships. I am hoping that you would be interested and we could possibly get to know each other more if you do not mind. I am open to answering questions from you as i think my approach is a little inappropriate. Hope to hear back from you. Jack.
Hello Beautiful
Hi Dear, my name is Jack and i am seeking for a relationship in which i will feel loved after a series of failed relationships. I am hoping that you would be interested and we could possibly get to know each other more if you do not mind. I am open to answering questions from you as i think my approach is a little inappropriate. Hope to hear back from you. Jack.
Hi Pretty,
Hi Dear, my name is Jack and i am seeking for a relationship in which i will feel loved after a series of failed relationships. I am hoping that you would be interested and we could possibly get to know each other more if you do not mind. I am open to answering questions from you as i think my approach is a little inappropriate. Hope to hear back from you. Jack.
NICE TO MEET YOU,
Hi Dear, my name is Jack and i am seeking for a relationship in which i will feel loved after a series of failed relationships. I am hoping that you would be interested and we could possibly get to know each other more if you do not mind. I am open to answering questions from you as i think my approach is a little inappropriate. Hope to hear back from you. Jack.
Hello Beautiful
Good day dear, i hope this mail meets you well? my name is Jack, from the U.S. I know this may seem inappropriate so i ask for your forgiveness but i wish to get to know you better, if I may be so bold. I consider myself an easy-going man, adventurous, honest and fun loving person but I am currently looking for a relationship in which I will feel loved. I promise to answer any question that you may want to ask me...all i need is just your attention and the chance to know you more. Please tell me more about yourself, if you do not mind. Hope to hear back from you soon. Jack.
Hello Beautiful
Good day dear, i hope this mail meets you well? my name is Jack, from the U.S. I know this may seem inappropriate so i ask for your forgiveness but i wish to get to know you better, if I may be so bold. I consider myself an easy-going man, adventurous, honest and fun loving person but I am currently looking for a relationship in which I will feel loved. I promise to answer any question that you may want to ask me...all i need is just your attention and the chance to know you more. Please tell me more about yourself, if you do not mind. Hope to hear back from you soon. Jack.
Hello Beautiful
Good day dear, i hope this mail meets you well? my name is Jack, from the U.S. I know this may seem inappropriate so i ask for your forgiveness but i wish to get to know you better, if I may be so bold. I consider myself an easy-going man, adventurous, honest and fun loving person but I am currently looking for a relationship in which I will feel loved. I promise to answer any question that you may want to ask me...all i need is just your attention and the chance to know you more. Please tell me more about yourself, if you do not mind. Hope to hear back from you soon. Jack.
Re: [PATCH v2 08/21] [media] imx: Add i.MX IPUv3 capture driver
Hi Marek,
On 19/10/16 20:25, Marek Vasut wrote:
On 10/19/2016 06:22 PM, Jack Mitchell wrote:
Hi Philipp,
On 17/10/16 13:12, Philipp Zabel wrote:
Hi Jack,
Am Montag, den 17.10.2016, 12:32 +0100 schrieb Jack Mitchell:
Hi Philipp,
I'm looking at how I would enable a parallel greyscale camera using this
set of drivers and am a little bit confused. Do you have an example
somewhere of a devicetree with an input node.
In your board device tree it should look somewhat like this:
{
sensor@48 {
compatible = "aptina,mt9v032m";
/* ... */
port {
cam_out: endpoint {
remote-endpoint = <_in>;
}
};
};
};
/*
* This is the input port node corresponding to the 'CSI0' pad group,
* not necessarily the CSI0 port of IPU1 or IPU2. On i.MX6Q it's port@1
* of the mipi_ipu1_mux, on i.MX6DL it's port@4 of the ipu_csi0_mux,
* the csi0 label is added in patch 13/21.
*/
{
#address-cells = <1>;
#size-cells = <0>;
csi_in: endpoint@0 {
bus-width = <8>;
data-shift = <12>;
hsync-active = <1>;
vsync-active = <1>;
pclk-sample = <1>;
remote-endpoint = <_out>;
};
};
I also have a further note below:
[...]
+if (raw && priv->smfc) {
Thank you, I think I have something which is kind of right.
(Apologies in advance for the formatting)
diff --git a/arch/arm/boot/dts/imx6q-sabrelite.dts
b/arch/arm/boot/dts/imx6q-sabrelite.dts
index 66d10d8..90e6b92 100644
--- a/arch/arm/boot/dts/imx6q-sabrelite.dts
+++ b/arch/arm/boot/dts/imx6q-sabrelite.dts
@@ -52,3 +52,62 @@
{
status = "okay";
};
+
+ {
+sensor@10 {
+compatible = "onsemi,ar0135";
+reg = <0x10>;
+
+pinctrl-names = "default";
+pinctrl-0 = <_ar0135>;
+
+reset-gpio = < 6 GPIO_ACTIVE_HIGH>;
+
+clocks = < IMX6QDL_CLK_CKO2>;
+clock-names = "xclk";
+
+xclk = <2400>;
+
+port {
+parallel_camera_output: endpoint {
+remote-endpoint = <_in_from_parallel_camera>;
+};
+};
+};
+};
+
+ {
+csi_in_from_parallel_camera: endpoint@0 {
+bus-width = <8>;
+data-shift = <12>;
+hsync-active = <1>;
+vsync-active = <1>;
+pclk-sample = <1>;
+remote-endpoint = <_camera_output>;
+};
+};
+
+ {
+
+imx6q-sabrelite {
+
+pinctrl_ar0135: ar0135grp {
+fsl,pins = <
+MX6QDL_PAD_GPIO_6__GPIO1_IO06 0x8000
+MX6QDL_PAD_CSI0_DAT12__IPU1_CSI0_DATA120x8000
+MX6QDL_PAD_CSI0_DAT13__IPU1_CSI0_DATA130x8000
+MX6QDL_PAD_CSI0_DAT14__IPU1_CSI0_DATA140x8000
+MX6QDL_PAD_CSI0_DAT15__IPU1_CSI0_DATA150x8000
+MX6QDL_PAD_CSI0_DAT16__IPU1_CSI0_DATA160x8000
+MX6QDL_PAD_CSI0_DAT17__IPU1_CSI0_DATA170x8000
+MX6QDL_PAD_CSI0_DAT18__IPU1_CSI0_DATA180x8000
+MX6QDL_PAD_CSI0_DAT19__IPU1_CSI0_DATA190x8000
+MX6QDL_PAD_CSI0_PIXCLK__IPU1_CSI0_PIXCLK 0x8000
+MX6QDL_PAD_CSI0_MCLK__IPU1_CSI0_HSYNC 0x8000
+MX6QDL_PAD_CSI0_VSYNC__IPU1_CSI0_VSYNC 0x8000
+MX6QDL_PAD_CSI0_DATA_EN__IPU1_CSI0_DATA_EN 0x8000
+>;
+};
+};
+};
However, I can't seem to link the entities together properly, am I
missing something obvious?
root@vicon:~# media-ctl -p
Media controller API version 0.1.0
Media device information
driver imx-media
model i.MX IPUv3
serial
bus info
hw revision 0x0
driver version 0.0.0
Device topology
- entity 1: IPU0 CSI0 (2 pads, 1 link)
type V4L2 subdev subtype Unknown flags 0
pad0: Sink
pad1: Source
-> "imx-ipuv3-capture.0":0 [ENABLED]
- entity 4: imx-ipuv3-capture.0 (1 pad, 1 link)
type Node subtype V4L flags 0
device node name /dev/video0
pad0: Sink
<- "IPU0 CSI0":1 [ENABLED]
- entity 10: IPU0 CSI1 (2 pads, 1 link)
type V4L2 subdev subtype Unknown flags 0
pad0: Sink
pad1: Source
-> "imx-ipuv3-capture.1":0 [ENABLED]
- entity 13: imx-ipuv3-capture.1 (1 pad, 1 link)
type Node subtype V4L flags 0
device node name /dev/video1
pad0: Sink
<- "IPU0 CSI1":1 [ENABLED]
- entity 19: IPU1 CSI0 (2 pads, 1 link)
type V4L2 subdev subtype Unknown flags 0
pad0: Sink
pad1: Source
-> "imx-ipuv3-capture.0":0 [ENABLED]
- entity 22: imx-ipuv3-capture.0 (1 pad, 1 link)
type Node subtype V4L flags 0
Re: [PATCH v2 08/21] [media] imx: Add i.MX IPUv3 capture driver
Hi Philipp,
On 17/10/16 13:12, Philipp Zabel wrote:
Hi Jack,
Am Montag, den 17.10.2016, 12:32 +0100 schrieb Jack Mitchell:
Hi Philipp,
I'm looking at how I would enable a parallel greyscale camera using this
set of drivers and am a little bit confused. Do you have an example
somewhere of a devicetree with an input node.
In your board device tree it should look somewhat like this:
{
sensor@48 {
compatible = "aptina,mt9v032m";
/* ... */
port {
cam_out: endpoint {
remote-endpoint = <_in>;
}
};
};
};
/*
* This is the input port node corresponding to the 'CSI0' pad group,
* not necessarily the CSI0 port of IPU1 or IPU2. On i.MX6Q it's port@1
* of the mipi_ipu1_mux, on i.MX6DL it's port@4 of the ipu_csi0_mux,
* the csi0 label is added in patch 13/21.
*/
{
#address-cells = <1>;
#size-cells = <0>;
csi_in: endpoint@0 {
bus-width = <8>;
data-shift = <12>;
hsync-active = <1>;
vsync-active = <1>;
pclk-sample = <1>;
remote-endpoint = <_out>;
};
};
I also have a further note below:
[...]
+ if (raw && priv->smfc) {
Thank you, I think I have something which is kind of right.
(Apologies in advance for the formatting)
diff --git a/arch/arm/boot/dts/imx6q-sabrelite.dts
b/arch/arm/boot/dts/imx6q-sabrelite.dts
index 66d10d8..90e6b92 100644
--- a/arch/arm/boot/dts/imx6q-sabrelite.dts
+++ b/arch/arm/boot/dts/imx6q-sabrelite.dts
@@ -52,3 +52,62 @@
{
status = "okay";
};
+
+ {
+ sensor@10 {
+ compatible = "onsemi,ar0135";
+ reg = <0x10>;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <_ar0135>;
+
+ reset-gpio = < 6 GPIO_ACTIVE_HIGH>;
+
+ clocks = < IMX6QDL_CLK_CKO2>;
+ clock-names = "xclk";
+
+ xclk = <2400>;
+
+ port {
+ parallel_camera_output: endpoint {
+ remote-endpoint =
<_in_from_parallel_camera>;
+ };
+ };
+ };
+};
+
+ {
+ csi_in_from_parallel_camera: endpoint@0 {
+ bus-width = <8>;
+ data-shift = <12>;
+ hsync-active = <1>;
+ vsync-active = <1>;
+ pclk-sample = <1>;
+ remote-endpoint = <_camera_output>;
+ };
+};
+
+ {
+
+imx6q-sabrelite {
+
+ pinctrl_ar0135: ar0135grp {
+ fsl,pins = <
+ MX6QDL_PAD_GPIO_6__GPIO1_IO06 0x8000
+ MX6QDL_PAD_CSI0_DAT12__IPU1_CSI0_DATA12
0x8000
+ MX6QDL_PAD_CSI0_DAT13__IPU1_CSI0_DATA13
0x8000
+ MX6QDL_PAD_CSI0_DAT14__IPU1_CSI0_DATA14
0x8000
+ MX6QDL_PAD_CSI0_DAT15__IPU1_CSI0_DATA15
0x8000
+ MX6QDL_PAD_CSI0_DAT16__IPU1_CSI0_DATA16
0x8000
+ MX6QDL_PAD_CSI0_DAT17__IPU1_CSI0_DATA17
0x8000
+ MX6QDL_PAD_CSI0_DAT18__IPU1_CSI0_DATA18
0x8000
+ MX6QDL_PAD_CSI0_DAT19__IPU1_CSI0_DATA19
0x8000
+ MX6QDL_PAD_CSI0_PIXCLK__IPU1_CSI0_PIXCLK
0x8000
+ MX6QDL_PAD_CSI0_MCLK__IPU1_CSI0_HSYNC
0x8000
+ MX6QDL_PAD_CSI0_VSYNC__IPU1_CSI0_VSYNC
0x8000
+ MX6QDL_PAD_CSI0_DATA_EN__IPU1_CSI0_DATA_EN
0x8000
+ >;
+ };
+ };
+};
However, I can't seem to link the entities together properly, am I
missing something obvious?
root@vicon:~# media-ctl -p
Media controller API version 0.1.0
Media device information
driver imx-media
model i.MX IPUv3
serial
bus info
hw revision 0x0
driver version 0.0.0
Device topology
- entity 1: IPU0 CSI0 (2 pads, 1 link)
type V4L2 subdev subtype Unknown flags 0
pad0: Sink
pad1: Source
-> "imx-ipuv3-capture.0":0 [ENABLED]
- entity 4: imx-ipuv3-capture.0 (1 pad, 1 link)
type Node subtype V4L flags 0
device node name /dev/video0
pad0: Sink
<- "IPU0 CSI0":1 [ENABLED]
- entity 10: IPU0 CSI1 (2 pads, 1 link)
type V4L2 subdev subtype Unknown flags 0
pad0: Sink
pad1: Source
-> "i
Re: [PATCH v2 08/21] [media] imx: Add i.MX IPUv3 capture driver
On 17/10/16 12:35, Marek Vasut wrote: On 10/17/2016 01:32 PM, Jack Mitchell wrote: Hi Philipp, Hi, I'm looking at how I would enable a parallel greyscale camera using this set of drivers and am a little bit confused. Do you have an example somewhere of a devicetree with an input node. I also have a further note below: Which sensor do you use ? [...] One which has a driver yet to be written :) Initial prototype board has an onsemi ar0135 on the parallel interface. -- 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 08/21] [media] imx: Add i.MX IPUv3 capture driver
Hi Philipp,
I'm looking at how I would enable a parallel greyscale camera using this
set of drivers and am a little bit confused. Do you have an example
somewhere of a devicetree with an input node. I also have a further note
below:
+
+static int ipu_capture_start_streaming(struct vb2_queue *vq, unsigned int
count)
+{
+ struct ipu_capture *priv = vb2_get_drv_priv(vq);
+ struct v4l2_subdev *csi_sd = priv->csi_sd;
+ u32 width = priv->format.fmt.pix.width;
+ u32 height = priv->format.fmt.pix.height;
+ struct device *dev = priv->dev;
+ int burstsize;
+ struct ipu_capture_buffer *buf;
+ int nfack_irq;
+ int ret;
+ const char *irq_name[2] = { "CSI0", "CSI1" };
+ bool raw;
+
+ ret = ipu_capture_get_resources(priv);
+ if (ret < 0) {
+ dev_err(dev, "Failed to get resources: %d\n", ret);
+ goto err_dequeue;
+ }
+
+ ipu_cpmem_zero(priv->ipuch);
+
+ nfack_irq = ipu_idmac_channel_irq(priv->ipu, priv->ipuch,
+ IPU_IRQ_NFACK);
+ ret = request_threaded_irq(nfack_irq, NULL,
+ ipu_capture_new_frame_handler, IRQF_ONESHOT,
+ irq_name[priv->id], priv);
+ if (ret) {
+ dev_err(dev, "Failed to request NFACK interrupt: %d\n",
nfack_irq);
+ goto put_resources;
+ }
+
+ dev_dbg(dev, "width: %d height: %d, %.4s\n",
+ width, height, (char *)>format.fmt.pix.pixelformat);
+
+ ipu_cpmem_set_resolution(priv->ipuch, width, height);
+
+ raw = false;
+
+ if (raw && priv->smfc) {
How does this ever get used? If I were to set 1X8 greyscale it wouldn't
ever take this path, correct?
+ /*
+* raw formats. We can only pass them through to memory
+*/
+ u32 fourcc = priv->format.fmt.pix.pixelformat;
+ int bytes;
+
+ switch (fourcc) {
+ case V4L2_PIX_FMT_GREY:
+ bytes = 1;
+ break;
+ case V4L2_PIX_FMT_Y10:
+ case V4L2_PIX_FMT_Y16:
+ case V4L2_PIX_FMT_UYVY:
+ case V4L2_PIX_FMT_YUYV:
+ bytes = 2;
+ break;
+ }
+
+ ipu_cpmem_set_stride(priv->ipuch, width * bytes);
+ ipu_cpmem_set_format_passthrough(priv->ipuch, bytes * 8);
+ /*
+* According to table 37-727 (SMFC Burst Size), burstsize should
+* be set to NBP[6:4] for PFS == 6. Unfortunately, with a 16-bit
+* bus any value below 4 doesn't produce proper images.
+*/
+ burstsize = (64 / bytes) >> 3;
+ } else {
+ /*
+* formats we understand, we can write it in any format not
requiring
+* colorspace conversion.
+*/
+ u32 fourcc = priv->format.fmt.pix.pixelformat;
+
+ switch (fourcc) {
+ case V4L2_PIX_FMT_RGB32:
+ ipu_cpmem_set_stride(priv->ipuch, width * 4);
+ ipu_cpmem_set_fmt(priv->ipuch, fourcc);
+ break;
+ case V4L2_PIX_FMT_UYVY:
+ case V4L2_PIX_FMT_YUYV:
+ ipu_cpmem_set_stride(priv->ipuch, width * 2);
+ ipu_cpmem_set_yuv_interleaved(priv->ipuch, fourcc);
+ break;
+ case V4L2_PIX_FMT_YUV420:
+ case V4L2_PIX_FMT_YVU420:
+ case V4L2_PIX_FMT_NV12:
+ case V4L2_PIX_FMT_YUV422P:
+ ipu_cpmem_set_stride(priv->ipuch, width);
+ ipu_cpmem_set_fmt(priv->ipuch, fourcc);
+ ipu_cpmem_set_yuv_planar(priv->ipuch, fourcc,
+width, height);
+ burstsize = 16;
+ break;
+ default:
+ dev_err(dev, "invalid color format: %4.4s\n",
+ (char *));
+ ret = -EINVAL;
+ goto free_irq;
+ }
+ }
+
--
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 v4 0/8] adv7180 subdev fixes, v4
On 03/08/16 19:03, Steve Longerbeam wrote: Steve Longerbeam (8): media: adv7180: fix field type media: adv7180: define more registers media: adv7180: add support for NEWAVMODE media: adv7180: add power pin control media: adv7180: implement g_parm media: adv7180: change mbus format to UYVY v4l: Add signal lock status to source change events media: adv7180: enable lock/unlock interrupts .../devicetree/bindings/media/i2c/adv7180.txt | 8 + Documentation/media/uapi/v4l/vidioc-dqevent.rst| 9 + Documentation/media/videodev2.h.rst.exceptions | 1 + drivers/media/i2c/Kconfig | 2 +- drivers/media/i2c/adv7180.c| 200 + include/uapi/linux/videodev2.h | 1 + 6 files changed, 183 insertions(+), 38 deletions(-) Did anything come of this patchset, I see a few select patches from the original (full imx6) series have been merged in but only seems partial? Cheers, Jack. -- 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: [19/38] ARM: dts: imx6-sabrelite: add video capture ports and connections
On 20/06/16 11:16, Gary Bisson wrote: Jack, All, On Mon, Jun 20, 2016 at 10:44:44AM +0100, Jack Mitchell wrote: I've tried that patch have a some comments: - When applied, no capture shows up any more, instead I have two m2m v4l2 devices [1]. - OV5640 Mipi is assigned the same address as OV5642, therefore both Yes, I only have one device attached in my scenario. Thanks for confirming. can't work at the same time right now. There's a register in the camera that allows to modify its I2C address, see this patch [2]. - How is the mclk working in this patch? It should be using the PWM3 As mentioned I have an eCon sensor board [1] which generates it's own clock on the board and as such I don't need the PWM signal, just the two GPIOs. Oh ok, thanks I didn't this sensor board was different than ours [1]. But in your patch, you specifically disable pwm3, what's the reason for it? Yes, it uses the GPIO on the PWM3 pin (beats me why...) so I had to specifically disable it to stop the pin muxing clash. output to generate a ~22MHz clock. I would expect the use of a pwm-clock node [3]. Also another remark on both OV5642 and OV5640 patches, is it recommended to use 0x8000 pin muxing value? This leaves it to the bootloader to I also wondered about this, but didn't know if the pinmux driver did this based on the define name? I tried it both ways and it worked so I just left it as it was. Actually my phrasing is wrong, the muxing is ok. Yes depending on the name a pin will be muxed to one function or another. The problem is the pad configuration (pull-up, pull-down etc..). I am not surprised that it works, because the bootloader should properly set those. But it would be safer IMO not to rely on it. Ah ok, makes sense. Regards, Gary [1] https://boundarydevices.com/product/nit6x_5mp_mipi/ -- 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: [19/38] ARM: dts: imx6-sabrelite: add video capture ports and connections
On 20/06/16 10:33, Gary Bisson wrote: Steve, Jack, All, On Fri, Jun 17, 2016 at 12:01:41PM -0700, Steve Longerbeam wrote: On 06/17/2016 08:18 AM, Gary Bisson wrote: Steve, All, On Thu, Jun 16, 2016 at 10:32:31AM +0200, Gary Bisson wrote: Steve, All, On Tue, Jun 14, 2016 at 03:49:15PM -0700, Steve Longerbeam wrote: Defines the host video capture device node and an OV5642 camera sensor node on i2c2. The host capture device connects to the OV5642 via the parallel-bus mux input on the ipu1_csi0_mux. Note there is a pin conflict with GPIO6. This pin functions as a power input pin to the OV5642, but ENET requires it to wake-up the ARM cores on normal RX and TX packet done events (see 6261c4c8). So by default, capture is disabled, enable by uncommenting __OV5642_CAPTURE__ macro. Ethernet will still work just not quite as well. Actually the following patch fixes this issue and has already been applied on Shawn's tree: https://patchwork.kernel.org/patch/9153523/ Also, this follow-up patch declared the HW workaround for SabreLite: https://patchwork.kernel.org/patch/9153525/ So ideally, once those two patches land on your base tree, you could get rid of the #define and remove the HW workaround declaration. Finally, I'll test the series on Sabre-Lite this week. I've applied this series on top of Shawn tree (for-next branch) in order not to worry about the GPIO6 workaround. Although the camera seems to get enumerated properly, I can't seem to get anything from it. See log: http://pastebin.com/xnw1ujUq Hi Gary, the driver does not implement vidioc_cropcap, it has switched to the new selection APIs and v4l2src should be using vidioc_g_selection instead of vidioc_cropcap. I confirm this was the issue, your patch fixes it. In your cover letter, you said that you have not run through v4l2-compliance. How have you tested the capture? I use v4l2-ctl, and have used v4l2src in the past, but that was before switching to the selection APIs. Try the attached hack that adds vidioc_cropcap back in, and see how far you get on SabreLite with v4l2src. I tried the following on SabreAuto: gst-launch-1.0 v4l2src io_mode=4 ! "video/x-raw,format=RGB16,width=640,height=480" ! fbdevsink I confirm that works with OV5642 on SabreLite: Tested-by: Gary Bisson <gary.bis...@boundarydevices.com> Also, why isn't the OV5640 MIPI camera declared on the SabreLite device tree? See Jack Mitchell's patch at http://ix.io/TTg. Thanks Jack! I will work on incorporating it. Hi Gary, I've tried that patch have a some comments: - When applied, no capture shows up any more, instead I have two m2m v4l2 devices [1]. - OV5640 Mipi is assigned the same address as OV5642, therefore both Yes, I only have one device attached in my scenario. can't work at the same time right now. There's a register in the camera that allows to modify its I2C address, see this patch [2]. - How is the mclk working in this patch? It should be using the PWM3 As mentioned I have an eCon sensor board [1] which generates it's own clock on the board and as such I don't need the PWM signal, just the two GPIOs. output to generate a ~22MHz clock. I would expect the use of a pwm-clock node [3]. Also another remark on both OV5642 and OV5640 patches, is it recommended to use 0x8000 pin muxing value? This leaves it to the bootloader to I also wondered about this, but didn't know if the pinmux driver did this based on the define name? I tried it both ways and it worked so I just left it as it was. Cheers, Jack. [1] https://www.e-consystems.com/iMX6-MIPI-Camera-Board.asp properly setup the I/O. It sounds safer to properly set them up in the device tree in my opinion in order not to be dependent on the bootloader. All the above remarks said, thanks for this work on i.MX camera support, that feature will be highly appreciated. Regards, Gary [1] http://pastebin.com/i5MrhB1h [2] https://github.com/boundarydevices/linux-imx6/commit/f915806d [3] http://lxr.free-electrons.com/source/Documentation/devicetree/bindings/clock/pwm-clock.txt -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [19/38] ARM: dts: imx6-sabrelite: add video capture ports and connections
On 17/06/16 16:18, Gary Bisson wrote: Steve, All, On Thu, Jun 16, 2016 at 10:32:31AM +0200, Gary Bisson wrote: Steve, All, On Tue, Jun 14, 2016 at 03:49:15PM -0700, Steve Longerbeam wrote: Defines the host video capture device node and an OV5642 camera sensor node on i2c2. The host capture device connects to the OV5642 via the parallel-bus mux input on the ipu1_csi0_mux. Note there is a pin conflict with GPIO6. This pin functions as a power input pin to the OV5642, but ENET requires it to wake-up the ARM cores on normal RX and TX packet done events (see 6261c4c8). So by default, capture is disabled, enable by uncommenting __OV5642_CAPTURE__ macro. Ethernet will still work just not quite as well. Actually the following patch fixes this issue and has already been applied on Shawn's tree: https://patchwork.kernel.org/patch/9153523/ Also, this follow-up patch declared the HW workaround for SabreLite: https://patchwork.kernel.org/patch/9153525/ So ideally, once those two patches land on your base tree, you could get rid of the #define and remove the HW workaround declaration. Finally, I'll test the series on Sabre-Lite this week. I've applied this series on top of Shawn tree (for-next branch) in order not to worry about the GPIO6 workaround. Although the camera seems to get enumerated properly, I can't seem to get anything from it. See log: http://pastebin.com/xnw1ujUq In your cover letter, you said that you have not run through v4l2-compliance. How have you tested the capture? Also, why isn't the OV5640 MIPI camera declared on the SabreLite device tree? Let me know if I can help testing/updating things on the SabreLite. Hi Gary, I have been testing the ov5640 MIPI on the Sabrelite. Patch is at [1]. Careful of the GPIO numbers as I am using an eCon sensor which has slightly different pin routing to the boundarydevices sensor. Let me know how you get on, I've managed to get images out of the device so it's working to a degree. Cheers, Jack. Tuxable Ltd, London, UK [1] http://ix.io/TTg Regards, Gary -- -- 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 00/38] i.MX5/6 Video Capture
On 16/06/16 02:37, Steve Longerbeam wrote: Hi Jack, On 06/15/2016 03:43 AM, Jack Mitchell wrote: Trying to use a user pointer rather than mmap also fails and causes a kernel splat. Hmm, I've tested userptr with the mem2mem driver, but maybe never with video capture. I tried "v4l2-ctl -d/dev/video0 --stream-user=8" but that returns "VIDIOC_QBUF: failed: Invalid argument", haven't tracked down why (could be a bug in v4l2-ctl). Can you share the splat? On re-checking the splat was the same v4l_cropcap that was mentioned before so I don't think it's related. The error I get back is: VIDIOC_QBUF error 22, Invalid argument I'm using the example program the the v4l2 docs [1]. Cheers, Jack [1] https://linuxtv.org/downloads/v4l-dvb-apis/capture-example.html Apart from that and a few v4l2-compliance tests failing which you already mentioned, it seems to work OK. I'll try and do some more testing and see if I can come back with some more feedback. Thanks! 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: [PATCH 00/38] i.MX5/6 Video Capture
On 14/06/16 23:48, Steve Longerbeam wrote: Tested on imx6q SabreAuto with ADV7180, and imx6q SabreSD with mipi-csi2 OV5640. There is device-tree support also for imx6qdl SabreLite, but that is not tested. Also, this driver should theoretically work on i.MX5 targets, but that is also untested. I tested this on a sabrelite with ov5640 MIPI camera. I managed to capture multiple images of a few different resolutions without issue. I did get a kernel splat at one point though: [ 905.469680] WARNING: CPU: 3 PID: 349 at drivers/media/v4l2-core/v4l2-ioctl.c:2174 v4l_cropcap+0x15c/0x190 [ 905.482308] Modules linked in: dw_hdmi_ahb_audio evbug [ 905.489079] CPU: 3 PID: 349 Comm: capture-example Tainted: GW 4.7.0-rc1-00095-g921736c0-dirty #7 [ 905.502069] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree) [ 905.510116] Backtrace: [ 905.514066] [] (dump_backtrace) from [] (show_stack+0x18/0x1c) [ 905.523161] r7: r6:600f0013 r5: r4:c0e21bbc [ 905.530442] [] (show_stack) from [] (dump_stack+0xb4/0xe8) [ 905.539210] [] (dump_stack) from [] (__warn+0xd8/0x104) [ 905.547680] r9:c06219b0 r8:087e r7:0009 r6:c0c51b10 r5: r4: [ 905.557086] [] (__warn) from [] (warn_slowpath_null+0x28/0x30) [ 905.566172] r9:c5e09680 r8: r7:c63c0e00 r6:c5e09680 r5:c0a7b2fc r4:c6223e18 [ 905.575577] [] (warn_slowpath_null) from [] (v4l_cropcap+0x15c/0x190) [ 905.585296] [] (v4l_cropcap) from [] (__video_do_ioctl+0x280/0x300) [ 905.594824] r8: r7:c6248000 r6:c02c563a r5:0003 r4:c0621854 [ 905.603176] [] (__video_do_ioctl) from [] (video_usercopy+0x208/0x520) [ 905.612994] r10:c6223e18 r9:c5e09680 r8:bef3fb60 r7: r6: r5:002c [ 905.622542] r4:c02c563a [ 905.626692] [] (video_usercopy) from [] (video_ioctl2+0x14/0x1c) [ 905.636129] r10: r9:c6222000 r8:c62e0088 r7:bef3fb60 r6:c02c563a r5:c5e09680 [ 905.645837] r4:c6248000 [ 905.650146] [] (video_ioctl2) from [] (v4l2_ioctl+0xac/0xe8) [ 905.659402] [] (v4l2_ioctl) from [] (do_vfs_ioctl+0x9c/0xa28) [ 905.668768] r9:c6222000 r8:0003 r7:c022cc90 r6:c5e09680 r5:c61fcc68 r4:bef3fb60 [ 905.678598] [] (do_vfs_ioctl) from [] (SyS_ioctl+0x3c/0x64) [ 905.687898] r10: r9:c6222000 r8:bef3fb60 r7:c02c563a r6:c5e09680 r5:0003 [ 905.697911] r4:c5e09680 [ 905.702505] [] (SyS_ioctl) from [] (ret_fast_syscall+0x0/0x1c) [ 905.712135] r9:c6222000 r8:c0107dc4 r7:0036 r6:000107cc r5: r4:00012170 [ 905.722143] ---[ end trace 772a5fdfa424cbd1 ]--- Trying to use a user pointer rather than mmap also fails and causes a kernel splat. Apart from that and a few v4l2-compliance tests failing which you already mentioned, it seems to work OK. I'll try and do some more testing and see if I can come back with some more feedback. Tested-by: Jack Mitchell <j...@tuxable.co.uk> Cheers, Jack. Not run through v4l2-compliance yet, but that is in my queue. Philipp Zabel (2): ARM: dts: imx6qdl: Add mipi_ipu1/2 video muxes, mipi_csi, and their connections media: imx: Add video switch Steve Longerbeam (35): gpu: ipu-v3: Add Video Deinterlacer unit gpu: ipu-cpmem: Add ipu_cpmem_set_uv_offset() gpu: ipu-cpmem: Add ipu_cpmem_get_burstsize() gpu: ipu-v3: Add ipu_get_num() gpu: ipu-v3: Add IDMA channel linking support gpu: ipu-v3: Add ipu_set_vdi_src_mux() gpu: ipu-v3: Add VDI input IDMAC channels gpu: ipu-v3: Add ipu_csi_set_src() gpu: ipu-v3: Add ipu_ic_set_src() gpu: ipu-v3: set correct full sensor frame for PAL/NTSC gpu: ipu-v3: Fix CSI data format for 16-bit media bus formats gpu: ipu-v3: Fix IRT usage gpu: ipu-ic: Add complete image conversion support with tiling gpu: ipu-ic: allow multiple handles to ic gpu: ipu-v3: rename CSI client device ARM: dts: imx6qdl: Flesh out MIPI CSI2 receiver node ARM: dts: imx6-sabrelite: add video capture ports and connections ARM: dts: imx6-sabresd: add video capture ports and connections ARM: dts: imx6-sabreauto: create i2cmux for i2c3 ARM: dts: imx6-sabreauto: add reset-gpios property for max7310 ARM: dts: imx6-sabreauto: add pinctrl for gpt input capture ARM: dts: imx6-sabreauto: add video capture ports and connections ARM: dts: imx6qdl: add mem2mem device for sabre* boards gpio: pca953x: Add reset-gpios property clocksource/drivers/imx: add input capture support v4l: Add signal lock status to source change events media: Add camera interface driver for i.MX5/6 media: imx: Add MIPI CSI-2 Receiver driver media: imx: Add support for MIPI CSI-2 OV5640 media: imx: Add support for Parallel OV5642 media: imx: Add support for ADV7180 Video Decoder media: adv7180: add power pin control media: adv7180: implement g_parm media: Add i.MX5/6 mem2mem driver ARM: imx_v6_v7_defconfig: Enable staging video4linux drivers Suresh Dhandapani (1): gpu: ipu-v3: Fix CSI0 blur in NTSC format Documentation/DocBook/med
Re: i.mx6 camera interface (CSI) and mainline kernel
Hi all, I need a few more days. I would like to bring in the video-switch subdev from Pengutronix, which will replace the platform data set_video_mux method. Also re-org the device-tree to better define all the possible hardware connections, and split out mx6-encode.c into mx6-smfc and mx6-ic subdevs. Once this is done we should have a better base for adding media control later. I should have this done by end of this week. Steve Hi Steve, Just a heads up that I've also tested and confirmed partially working support on a sabrelite + mipi ov5640. The two gotchas I came across were dma_allocations fail in the higher resolutions (4x1080p buffers), a limit may need to be upped somewhere, the code says it should be able to handle up to 64MB? Secondly I can't get the 5MP resolution by default as in ov5640_find_nearest_mode, the array ov5640_mode_info_data is hard coded to 0. I gave your v2 branch a quick whirl also but it fails to compile. Thanks for the awesome work so far. Cheers, Jack. --- Jack Mitchell Tuxable Ltd London, UK -- 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] dib0700: get rid of on-stack dma buffers
On 06/03/2011 11:16, Florian Mickler wrote:
This should fix warnings seen by some:
WARNING: at lib/dma-debug.c:866 check_for_stack
Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=15977.
Reported-by: Zdenek Kabelac zdenek.kabe...@gmail.com
Signed-off-by: Florian Mickler flor...@mickler.org
CC: Mauro Carvalho Chehab mche...@infradead.org
CC: linux-media@vger.kernel.org
CC: linux-ker...@vger.kernel.org
CC: Greg Kroah-Hartman g...@kroah.com
CC: Rafael J. Wysocki r...@sisk.pl
CC: Maciej Rutecki maciej.rute...@gmail.com
---
@@ -101,8 +109,19 @@ int dib0700_ctrl_rd(struct dvb_usb_device *d, u8 *tx, u8
txlen, u8 *rx, u8 rxlen
int dib0700_set_gpio(struct dvb_usb_device *d, enum dib07x0_gpios gpio, u8
gpio_dir, u8 gpio_val)
{
- u8 buf[3] = { REQUEST_SET_GPIO, gpio, ((gpio_dir 0x01) 7) |
((gpio_val 0x01) 6) };
- return dib0700_ctrl_wr(d, buf, sizeof(buf));
+ s16 ret;
+ u8 *buf = kmalloc(3, GFP_KERNEL);
+ if (!buf)
+ return -ENOMEM;
+
+ buf[0] = REQUEST_SET_GPIO;
+ buf[1] = gpio;
+ buf[2] = ((gpio_dir 0x01) 7) | ((gpio_val 0x01) 6);
+
+ ret = dib0700_ctrl_wr(d, buf, sizeof(buf));
Shouldn't this sizeof be changed as well?
Thanks,
Jack
--
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
Hauppauge WinTV-HVR1800 dual tuner help needed
I bought a Hauppauge WinTV-HVR-1800 HDTV Tuner Capture Card PCI-e off of ebay for $30 and need some help getting the 2nd tuner activated ( if it's even possible ) The card pictured in the auction looks exactly like the one I received, but it doesn't look anything like the one listed on: http://www.linuxtv.org/wiki/index.php/Hauppauge_WinTV-HVR-1800 The card I have has 2 antenna connectors ( no other connectors at all )... a very basic looking card. I want to get both tuners tuning dvb ( digital ) qcam signals off of my FIOS TV Cable cable. I have have gotten the qcam stuff working on a DViCO FusionHDTV 5 Lite and a Hauppauge WinTV-HVR1200 pcie board so I know that that part is ok. I can get a single tuner working on the WinTV-HVR-1800 card... dmesg, lscpi, etc for the card are below... ( I'm only trying to get the major networks ( abc, cbs, fox, etc ) that are not encrypted... ) I'm running fedora 13, but I have compiled / installed the latest ( as of a few days ago ) v4l-dvv drivers from the v4l-dvb site dmesg reports: Linux video capture interface: v2.00 cx23885 driver version 0.0.2 loaded cx23885 :08:00.0: PCI INT A - GSI 19 (level, low) - IRQ 19 CORE cx23885[0]: subsystem: 0070:7809, board: Hauppauge WinTV-HVR1800 [card=2,autodetected] tveeprom 1-0050: Hauppauge model 78631, rev C1E9, serial# 2876620 tveeprom 1-0050: MAC address is 00:0d:fe:2b:e4:cc tveeprom 1-0050: tuner model is Philips 18271_8295 (idx 149, type 54) tveeprom 1-0050: TV standards NTSC(M) ATSC/DVB Digital (eeprom 0x88) tveeprom 1-0050: audio processor is CX23887 (idx 42) tveeprom 1-0050: decoder processor is CX23887 (idx 37) tveeprom 1-0050: has no radio cx23885[0]: hauppauge eeprom: model=78631 cx25840 3-0044: cx23887 A/V decoder found @ 0x88 (cx23885[0]) cx25840 3-0044: firmware: requesting v4l-cx23885-avcore-01.fw cx25840 3-0044: loaded v4l-cx23885-avcore-01.fw firmware (16382 bytes) tuner 2-0042: chip found @ 0x84 (cx23885[0]) tda829x 2-0042: could not clearly identify tuner address, defaulting to 60 tda18271 2-0060: creating new instance TDA18271HD/C1 detected @ 2-0060 tda829x 2-0042: type set to tda8295+18271 cx23885[0]/0: registered device video0 [v4l2] cx23885[0]: registered device video1 [mpeg] cx23885_dvb_register() allocating 1 frontend(s) cx23885[0]: cx23885 based dvb card MT2131: successfully identified at address 0x61 DVB: registering new adapter (cx23885[0]) DVB: registering adapter 0 frontend 0 (Samsung S5H1409 QAM/8VSB Frontend)... cx23885_dev_checkrevision() Hardware revision = 0xb1 cx23885[0]/0: found at :08:00.0, rev: 15, irq: 19, latency: 0, mmio: 0xf2e0 cx23885 :08:00.0: setting latency timer to 64 IRQ 19/cx23885[0]: IRQF_DISABLED is not guaranteed on shared IRQs lspci reports: 08:00.0 Multimedia video controller: Conexant Systems, Inc. Hauppauge Inc. HDPVR-1250 model 1196 (rev 0f) find on /dev/dvb reports: /dev/dvb /dev/dvb/adapter0 /dev/dvb/adapter0/net0 /dev/dvb/adapter0/dvr0 /dev/dvb/adapter0/demux0 /dev/dvb/adapter0/frontend0 I also have /dev/video0 and /dev/video1 devices listed lsmod | egrep tuner|cx23885|dvb|vl4 cx23885 102191 0 tuner 15518 1 cx2341x 9306 1 cx23885 v4l2_common13545 4 cx23885,tuner,cx25840,cx2341x videodev 34211 4 cx23885,tuner,cx25840,v4l2_common videobuf_dma_sg 7217 1 cx23885 videobuf_dvb4174 1 cx23885 dvb_core 71187 2 cx23885,videobuf_dvb videobuf_core 13426 3 cx23885,videobuf_dma_sg,videobuf_dvb ir_common 4056 1 cx23885 ir_core11377 8 cx23885,rc_hauppauge_new,ir_sony_decoder,ir_jvc_decoder,ir_rc6_decoder,ir_rc5_decoder,ir_nec_decoder,ir_common btcx_risc 2978 1 cx23885 tveeprom9994 1 cx23885 i2c_core 19651 13 cx23885,s5h1411,mt2131,s5h1409,tda18271,tda8290,tuner,cx25840,nvidia,v4l2_common,videodev,i2c_i801,tveeprom I can use 1 input on the card with mythtv using /dev/dvb/adapter0/frontend0 but I can't figure out how to use the 2nd tuner I'm not sure if the 2nd tuner is getting detected correctly... or if the 2nd tuner is just an analog tuner and not a digital tuner or what exactly... There is something in mythtv that says how many things an input can tune at once, but setting it to 2 does not let me record two things using this WinTV-HVR-1800 card. mythtv treats it as one tuner... I think that I need to see /dev/dvb/adapter0/frontend0 and /dev/dvb/adapter0/frontend1 to get to the 2nd tuner... Is there a modprobe cx23885 option that enables a 2nd tuner? Is one of the dmesg messages telling me that the 2nd tuner is analog only? The can on the card doesn't look like any of the cans on my other analog cards that I've had in the past Thanks - jack -- 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
