omap_vout: rotation issue on the first start
Hi Laurent,
Sorry to insist on this, but for you it's probably peanuts to see a possible
error.
Any hints/workarounds are welcome...
>From the mail with subject
AW: AW: mt9p031 shows purple coloured capture
Florian Neuhaus wrote on 2013-06-24:
>> Have you tested the unmodified omap3-is-live ?
> I did today and indeed, with the unmodified app there is no green taint on
> the first start. I have now tracked down the issue to my implemented
> rotation on the video-out:
>
diff --git a/videoout.c b/videoout.c
index 51bed8b..6fd8a16 100644
--- a/videoout.c
+++ b/videoout.c
@@ -60,6 +60,7 @@ struct videoout *vo_init(const char *devname,
struct v4l2_format fmt;
struct videoout *vo;
int ret;
+ int rotation = 90; /* rotate for testing purposes */
/* Allocate the video output object. */
vo = malloc(sizeof *vo);
@@ -76,6 +77,14 @@ struct videoout *vo_init(const char *devname,
goto error;
}
+ /* setup the rotation here, we have to do it BEFORE
+* setting the format. */
+ ret = v4l2_set_control(vo->dev, V4L2_CID_ROTATE, &rotation);
+ if (ret < 0){
+ perror("Failed to setup rotation\n");
+ goto error;
+ }
+
pixfmt.pixelformat = format->pixelformat;
pixfmt.width = format->width;
pixfmt.height = format->height;
It would be very nice if you could test the above patch with one of
your omap-devices.
> I do a rotation by 90 or 270 degrees. So there seems to be an issue with the
> vrfb-rotation in omap_vout?
> I am already rotating the omapfb - is this a problem?
> omapfb.rotate=1 omapfb.vrfb=y
> Another possibility to rotate the captured stream?
I noticed, that it happens only with 90 or 270 degree rotation
and not with 0 and 180 degree. Also only on the first start of
the stream. All following streamings are correct.
I have a 480x800 Portrait display. I try to rotate the output to
800x480 landscape.
Regards,
Florian
--
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
AW: AW: mt9p031 shows purple coloured capture
Hi Laurent,
Laurent Pinchart wrote on 2013-06-22:
If I use omap3isp-live to capture a stream on my beagleboard, the
first time I start the app, the picture has always a green taint.
The second time I start the app, the picture is good. As the camera
is reset by a gpio upon device open, probably the CCDC or previewer
is not initialized correctly? @Laurent: As I am unable to test it
with another cam, does this also happen with your hardware or is it
a problem specific to the mt9p031?
>>>
>>> Last time I've tested my MT9P031 sensor with the Beagleboard-xM
>>> there was no such issue.
>>
>> If I test it with yavta, it works also from the very first start. So
>> there must be an issue in my (adapted) omap3-isp-live.
>
> Have you tested the unmodified omap3-is-live ?
I did today and indeed, with the unmodified app there is no
green taint on the first start. I have now tracked down the issue
to my implemented rotation on the video-out:
diff --git a/videoout.c b/videoout.c
index 51bed8b..627363a 100644
--- a/videoout.c
+++ b/videoout.c
@@ -76,6 +76,14 @@ struct videoout *vo_init(const char *devname,
goto error;
}
+ /* setup the rotation here, we have to do it BEFORE
+* setting the format. */
+ ret = v4l2_set_control(vo->dev, V4L2_CID_ROTATE, &rotation);
+ if (ret < 0){
+ perror("Failed to setup rotation\n");
+ goto error;
+ }
+
pixfmt.pixelformat = format->pixelformat;
pixfmt.width = format->width;
pixfmt.height = format->height;
I do a rotation by 90 or 270 degrees. So there seems to be an issue with
the vrfb-rotation in omap_vout?
I am already rotating the omapfb - is this a problem?
omapfb.rotate=1 omapfb.vrfb=y
Another possibility to rotate the captured stream?
>> The color problem goes away nearly completely, if I do a power-off and
>> on in the mt9p031_s_stream function. It then happens only 1 out of 10
>> times. At least an improvement ;) I have the feeling, that the CCDC
>> doesn't get all data on a stream restart and that causes a buffer
>> corruption. Probably the sensor doesn't start outputting from the
>> beginning (even with a frame restart).
>> Any ideas on this?
Probably this issue is in relation with omap_vout as well.
I will do more tests.
Regards,
Florian
--
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
media: i2c: mt9p031: HFLIP/VFLIP changes format
Hi Laurent In the mt9p031 driver, the picture can be flipped either horizontally or vertically by using the according V4L2 controls. This can be done at runtime. I have noticed, that flipping the picture will change the bayer-pattern. So if I flip horizontally and vertically to get a 180 degree rotation the bayer pattern changes from V4L2_MBUS_FMT_SGRBG12_1X12 to V4L2_MBUS_FMT_SGBRG12_1X12 I'm not sure how the patch should look like... The format code could be adapted accordingly to the flipping, but how does the userspace notices this change? The user could issue another get_format. But what about the omap3isp-pipe? Concrete: What should I do to configure a streaming pipe with a flipped image? Flip the image on the v4l-subdev and then build the pipe? Is there a chance to propagate the format change through the pipe during streaming? Thanks for your clarification! Regards, Florian -- 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
AW: mt9p031 shows purple coloured capture
Hi Laurent, Laurent Pinchart wrote on 2013-06-18: >> If I use omap3isp-live to capture a stream on my beagleboard, the first >> time I start the app, the picture has always a green taint. The second >> time I start the app, the picture is good. As the camera is reset by a >> gpio upon device open, probably the CCDC or previewer is not >> initialized correctly? @Laurent: As I am unable to test it with another >> cam, does this also happen with your hardware or is it a problem >> specific to the mt9p031? > > Last time I've tested my MT9P031 sensor with the Beagleboard-xM there > was no such issue. If I test it with yavta, it works also from the very first start. So there must be an issue in my (adapted) omap3-isp-live. > >> The second problem is similiar to your problem: >> omap3isp-live has (thanks to Laurent) a built in snapshot-mode. So I >> am doing the following: >> 1. Streaming video, picture looks good on the second start 2. Taking a >> snapshot: The video stream will turn off, the isp-pipe reconfigured. >> Then the stream will be turned back on and the captured image will be >> written to memory. >> 3. The captured image will now be displayed, but the image is corrupted: >> Wrong colors and cut in half: >> https://www.dropbox.com/s/ijk1nq8nrhlobfd/bad-snapshot.jpg >> 4. It doesn't help to skip a few buffers, also the 3rd buffer looks bad. >> 5. Additional problem: The CCDC can't be stopped properly (omap3isp >> omap3isp: Unable to stop OMAP3 ISP CCDC) and sometimes the isp locks >> up completely. >> >>> So I used the register 0x0B (Restart), bit 0 (abandon the current >>> frame and restart from the first row) set to 1 each time the >>> function s_stream is called. >> >> The finding so far: If I do a frame-restart (the register 0x0b on >> mt9p031) upon stream-on, the CCDC can be stopped properly and the >> snapshot looks pretty good. BUT the colors are still messed up. If I >> then switch to streaming again, the colors sometimes turn to good but >> sometimes the picture is purple tainted. @Andrei: What have you done to >> get good colors? The color problem goes away nearly completely, if I do a power-off and on in the mt9p031_s_stream function. It then happens only 1 out of 10 times. At least an improvement ;) I have the feeling, that the CCDC doesn't get all data on a stream restart and that causes a buffer corruption. Probably the sensor doesn't start outputting from the beginning (even with a frame restart). Any ideas on this? Regards, Florian -- 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: mt9p031 shows purple coloured capture
Hi Andrei, Your post helped me a lot! My environment: beagleboard-xm mt9p031 @96Mhz (adapted power-supply) linux-omap 3.7.10 omap3isp-live I have two similiar issues with the mt9p031, that has probably the same cause: If I use omap3isp-live to capture a stream on my beagleboard, the first time I start the app, the picture has always a green taint. The second time I start the app, the picture is good. As the camera is reset by a gpio upon device open, probably the CCDC or previewer is not initialized correctly? @Laurent: As I am unable to test it with another cam, does this also happen with your hardware or is it a problem specific to the mt9p031? The second problem is similiar to your problem: omap3isp-live has (thanks to Laurent) a built in snapshot-mode. So I am doing the following: 1. Streaming video, picture looks good on the second start 2. Taking a snapshot: The video stream will turn off, the isp-pipe reconfigured. Then the stream will be turned back on and the captured image will be written to memory. 3. The captured image will now be displayed, but the image is corrupted: Wrong colors and cut in half: https://www.dropbox.com/s/ijk1nq8nrhlobfd/bad-snapshot.jpg 4. It doesn't help to skip a few buffers, also the 3rd buffer looks bad. 5. Additional problem: The CCDC can't be stopped properly (omap3isp omap3isp: Unable to stop OMAP3 ISP CCDC) and sometimes the isp locks up completely. > So I used the register 0x0B (Restart), bit 0 (abandon the current frame and > restart from the first row) set to 1 each time the function s_stream is > called. The finding so far: If I do a frame-restart (the register 0x0b on mt9p031) upon stream-on, the CCDC can be stopped properly and the snapshot looks pretty good. BUT the colors are still messed up. If I then switch to streaming again, the colors sometimes turn to good but sometimes the picture is purple tainted. @Andrei: What have you done to get good colors? >> Wrong clock or *sync polarity selection? Which leads to random >> start-of-frame misplacement? >> > Do you mean pixel clock polarity? If so, I checked it - with it being > inverted - > the image capture goes well (purple color also appears from time to time), > but in the case it is not inverted I see a noise on the screen. Inverted the pixel-clock on the mt9p031 side (register 0x0a, bit 15)? I inverted the clock, but then the streaming had a purple taint. Regards, Florian -- 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
omap3isp, omap3-isp-live, mt9p031: snapshot-mode causing picture corruption
Hi Laurent I'm still modifying your omap3-isp-live application to fit our needs. Now I have severe problems with the snapshot-mode. When I let the "live"-app running, the picture is fine. Then I capture a snapshot by clicking the right mouse-button. The snapshot is taken (1-2 seconds) and displayed on the LCD. Now the picture is corrupted. Only the lower part of the picture looks good (altough it has a green cast): https://www.dropbox.com/s/ijk1nq8nrhlobfd/bad-snapshot.jpg When I now resume the viewfinder, then a moving picture is shown, but also partially corrupted (not a lot - just about the last 50 lines). If I do the switching (viewfinder<->snapshot) several times, the hardware locks completely up. My hardware is as usual ;) beagleboard-xm kernel 3.7 mt9p031 running at 96Mhz (instead of 48Mhz, problem?) lcd 800x480 vrfb with rotate 3 Further testing: It also happens with vrfb disabled. If I manually load a picture from disk into the resizer-input (in the function snapshot_process) while in snapshot-mode, the picture is displayed correctly. It seems that the picture taken from the snapshot-pipeline is "dirty". The buffer-sizes are correct though. Furthermore the snapshot-pipeline looks nearly the same as the viewfinder-pipeline... streaming-pipeline: http://pastebin.com/7qXtqXNz during-snapshot-pipeline: http://pastebin.com/L5XE0h30 display-snapshot-pipeline: http://pastebin.com/dZ0zzHyC I really have to get this working... any workarounds, dirty hacks or ideas (or even fixes ;)) are very welcome! Regards, Florian -- 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
AW: omapdss/omap3isp/omapfb: Picture from omap3isp can't recover after a blank/unblank (or overlay disables after resuming)
Hi Tomi, Tomi Valkeinen wrote on 2013-02-07: > FIFO underflow means that the DSS hardware wasn't able to fetch enough > pixel data in time to output them to the panel. Sometimes this happens > because of plain misconfiguration, but usually it happens because of > the hardware just can't do things fast enough with the configuration > the user has set. > > In this case I see that you are using VRFB rotation on fb0, and the > rotation is > 270 degrees. Rotating the fb is heavy, especially 90 and 270 degrees. > It may be that when the DSS is resumed, there's a peak in the mem > usage as DSS suddenly needs to fetch lots of data. > > Another issue that could be involved is power management. After the > DSS is suspended, parts of OMAP may be put to sleep. When the DSS is > resumed, these parts need to be woken up, and it may be that there's a > higher mem latency for a short period of time right after resume. > Which could again cause DSS not getting enough pixel data. > > You say the issue doesn't happen if you disable fb0. What happens if > you disable fb0, blank the screen, then unblank the screen, and after > that enable fb0 again? By "disable fb0" do you mean disconnect fb0 from ovl0 or disable ovl0? I have done both: http://pastebin.com/Bxm1Z2RY This works as expected. Further tests I have done: Enable fb1/ovl1 and hit some keys on the keyboard to let fb0/ovl0 update in the background causes a fifo underflow too: http://pastebin.com/f3JnMLsV This happens only, if I enable the vrfb (rotate=3). So the whole thing seems to be a rotation issue. Do you have some hints to trace down the problem? > How about if you disable VRFB rotation, either totally, or set the > rotation to 0 or 180 degrees? Disable rotation is not an option for me, as we have a "wrong" oriented portrait display with 480x800 which we must use in landscape mode... > And you can also tune the PM so that deeper sleep states are prevented. > I don't remember right away how this is done, though. > > Tomi Regards, Florian P.S. @Laurent: Do you use your streamer on a headless device? What is your DSS-config? Do you have a framebuffer-console on fb0? -- 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
AW: omapdss/omap3isp/omapfb: Picture from omap3isp can't recover after a blank/unblank (or overlay disables after resuming)
Hi Laurent, Thank you for your help, see my notes below: Laurent Pinchart wrote on 2013-01-30: >> Will result in the following and the following (screen flickers and >> goes black again): [ 5293.617095] omapdss DISPC error: FIFO UNDERFLOW >> on gfx, disabling the overlay [ 5293.678283] omapdss DISPC error: FIFO >> UNDERFLOW on vid2, disabling the overlay >> >> Output of mediactl -p while streaming: >> http://pastebin.com/d9zDfKXu >> >> OMAPDSS-config: >> http://pastebin.com/JjF0CcCS >> >> Now my questions: >> Is this behaviour expected? > > I don't think so. I'm not an expert on the OMAP DSS, but I wouldn't consider > the above messages as normal. Just as a note: This does not happen, if I disable the fb0 upon start of the streamer. My DSS config before the streamer start: fb0 --- gfx --- lcd --- LCD fb1 --- vid1 -/ vid2 / Description: I am using fb0 for the framebuffer-console. The fb1 is connected with the overlay vid1 and used as the colorkey in your streamer application. vid2 is directly used from within the streamer app for the ISP-output (at least I think so ;)). Everything is connected to the lcd-manager and outputted to a physical attached LCD. My DSS config when streamer is running: fb0 gfx --- lcd --- LCD fb1 --- vid1 -/ vid2 / With this workaround the streamer will continue streaming after a blank/unblank. > As buffers > will stop flowing until the screen is unblanked, the live application > will exit after a short select() timeout. This is an application issue. If the AF/AEWB unit is enabled, the timeout doesn't happen as the H3A-unit delivers still OMAP3_ISP_EVENT_EXCEPTION events. > It doesn't explain the omapdss error, Tomi might be able to provide more > information about that (but he is currently away until beginning of > February if I'm not mistaken). That would be very nice! Regards, Florian -- 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] ad5820: Voice coil motor controller driver
Hi Laurent,
Laurent Pinchart wrote on 2012-11-15:
> This is the ad5820 driver I've told you about. The code is compile-tested only
> as I haven't had time to try it on an N900 (the only device I own that
> includes an ad5820).
>
> It should be quite easy to adapt the driver to support both the ad5820
> and the ad5821. Would you have time to give it a try ?
I finally adapted the patch to work with ad5821 and ad5398. I tested it on a
3.5 kernel
on the beagleboard-xm and only with the ad5821! I neither found a datasheet for
the
ad5820 on the web...
The patch though can be applied against your current omap3isp/next branch.
I made it work without a separate regulator (mentioned as "VANA"), since we
control
the power by just setting the x-shutdown-flag in the register.
I guess there was a bug by calling the ad5820_detect-function too early, so I
rewrote
it to use the v4l2_subdev_internal_ops for detection.
As this is my first patch I ever wrote for the community: Is it gross to add me
as a
co-author?
Signed-off-by: Florian Neuhaus
---
drivers/media/i2c/Kconfig |9 +
drivers/media/i2c/Makefile |1 +
drivers/media/i2c/ad5820.c | 561
include/media/ad5820.h | 39 +++
4 files changed, 610 insertions(+)
create mode 100644 drivers/media/i2c/ad5820.c
create mode 100644 include/media/ad5820.h
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index 24d78e2..fad22e6 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -534,6 +534,15 @@ config VIDEO_AS3645A
This is a driver for the AS3645A and LM3555 flash controllers. It has
build in control for flash, torch and indicator LEDs.
+comment "Lens controllers"
+
+config VIDEO_AD5820
+ tristate "AD5820/AD5821/AD5398 lens voice coil support"
+ depends on I2C && VIDEO_V4L2 && MEDIA_CONTROLLER
+ ---help---
+ This is a driver for the AD5820/AD5821/AD5398 camera lens voice coil.
+ It is used for example in Nokia RX51.
+
comment "Video improvement chips"
config VIDEO_UPD64031A
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index b1d62df..975cfb8 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -58,6 +58,7 @@ obj-$(CONFIG_VIDEO_SR030PC30) += sr030pc30.o
obj-$(CONFIG_VIDEO_NOON010PC30)+= noon010pc30.o
obj-$(CONFIG_VIDEO_S5K6AA) += s5k6aa.o
obj-$(CONFIG_VIDEO_S5K4ECGX) += s5k4ecgx.o
+obj-$(CONFIG_VIDEO_AD5820) += ad5820.o
obj-$(CONFIG_VIDEO_ADP1653)+= adp1653.o
obj-$(CONFIG_VIDEO_AS3645A)+= as3645a.o
obj-$(CONFIG_VIDEO_SMIAPP_PLL) += smiapp-pll.o
diff --git a/drivers/media/i2c/ad5820.c b/drivers/media/i2c/ad5820.c
new file mode 100644
index 000..e91d0f3
--- /dev/null
+++ b/drivers/media/i2c/ad5820.c
@@ -0,0 +1,561 @@
+/*
+ * AD5820/AD5821/AD5398 DAC driver for camera voice coil focus.
+ *
+ * Copyright (C) 2008 Nokia Corporation
+ * Copyright (C) 2007 Texas Instruments
+ *
+ * Contact: Laurent Pinchart
+ * Sakari Ailus
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * 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
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+/* Register definitions */
+#define AD5820_POWER_DOWN (1 << 15)
+#define AD5820_DAC_SHIFT 4
+#define AD5820_RAMP_MODE_LINEAR(0 << 3)
+#define AD5820_RAMP_MODE_64_16 (1 << 3)
+
+#define CODE_TO_RAMP_US(s) ((s) == 0 ? 0 : (1 << ((s) - 1)) * 50)
+#define RAMP_US_TO_CODE(c) fls(((c) + ((c)>>1)) / 50)
+
+struct ad5820_current_data_format {
+ int id;
+ int current_bits;
+ int current_offset;
+ int min_uA;
+ int max_uA;
+};
+
+struct ad5820_device {
+ struct v4l2_subdev subdev;
+
+ struct regulator *vana;
+ int xshutdown;
+
+ struct v4l2_ctrl_handler ctrls;
+ u32 focus_absolute;
+ u32 focus_ramp_time;
+ u32 focus_ramp_mode;
+
+ struct mutex power_lock;
+ int power_count;
+
+ int standby:1;
+
+ struct ad5820_current_data_format *data_format;
+};
+
+#define to_ad5820_device(sd) container_of(sd, struct ad5820_device, subdev)
+
+/**
+ * @brief I2C write using i2c_transfer().
+ * @param coil - the driver data structure
+ * @param data - register value to be written
+ * @returns nonnegative on success, negative if failed
+ */
+static
AW: [omap3-isp-live] Autofocus buffer interpretation of H3A engine
Hi Laurent, Laurent Pinchart wrote on 2012-11-04: > The AD5821 is similar to the AD5820, for which I have a driver that I need to > clean up and post. Would you be interested in that ? Yes, you can send me the driver. Just as a note: I (probably) found an error in the current ad5398 and ad5821 driver http://lxr.free-electrons.com/source/drivers/regulator/ad5398.c It seems that the enable and disable functions are switched (at least for the ad5821). Also it's not possible to set the maximum current. I've done a patch but didn't have the time to submit it. Is this the right place for it? > Even though that buffer structure is pretty simple, I'm afraid I can't provide > that information as it's covered by an NDA. I have written the TI-support and here's the answer: START QUOTE " After checking it seems that we unfortunately do not make the DM37x H3A documention available. Implementing Autofocus is quite complexe and the documentation is likely not going to provide enough help. A lot of experience is required to handle the mecanics and control loop aspect for the Autofocus. We have partners that do have experience with the H3A module and that might be able to help. For example MMS that mentionned is the below document: http://www.ti.com/lit/ml/swpt052/swpt052.pdf Also Leopard Imaging has experience on the H3A: https://www.leopardimaging.com/Services.html END QUOTE It's sad that they can't provide any further information, because we are not that far to get this stuff working... > could try to figure it out ourselves. Looking at the FCam project, I've > found > > http://vcs.maemo.org/svn/fcam/fcam- > dev/tags/1.1.0/src/N900/V4L2Sensor.cpp > > Does that help figuring out what the buffer contains ? That helps a lot! Thank you. I found also a little info here: http://www.mail-archive.com/davinci-linux-open-source@linux.davincidsp.com/msg18438.html > I haven't started, and it's currently not on my to-do list I'm afraid. That's too bad, as your help is always appreciated. Have you already seen my patch for the rotation in your omap3-isp-live program? I have seen also another little issue, if you are interested (snapshot_init should be after aewb as the output format changes during snapshot-init). I am now off for 3 weeks (annual refresher course in the Swiss armed forces). Regards, Florian -- 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
[omap3-isp-live] Autofocus buffer interpretation of H3A engine
Hi Laurent I am adapting your current omap3-isp-live application to fit our needs (http://git.ideasonboard.org/omap3-isp-live.git/commit/619164a994c8d878249d6c1b8b16c27074a04209). For this I need to implement an autofocus algorithm to control an attached actuator. Let me summarize what components I use: - beagleboard-xm - mt9p031 on leopardimaging li-5m03 - own developed voice-coil-motor (vcm) driven by current regulator ad5821 - kernel 3.5 out of the linux-omap tree To generate a control signal for my vcm, I need to interpret the values generated by the AF engine of the omap3isp, h3a module. I see, that you have already implemented a working auto-exposure functionality with the AEWB module - so I have done the same with the AF module. But now I have problems to interpret the generated values in omap3_isp_af_process. Do you know how the paxel-buffer is structured? I see that the received buffer has the size of buf_size = af->paxel.h_cnt * af->paxel.v_cnt * OMAP3ISP_AF_PAXEL_SIZE; where OMAP3ISP_AF_PAXEL_SIZE is 48 bytes, but what is in the 48 bytes? Have you made some progress in implementing an autofocus algorithm? Thank you for your help and greetings, Florian -- 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] Rotate the videout via V4L2_CID_ROTATE based on fb_var_screeninfo.rotate
Hi Laurent
You are very fast on implementing new features in omap3-isp-live. I appreciate
much the new panning-feature - thank you!
On my beagleboard I use omap-vout with vrfb-rotation. As I already configured
omapfb to rotate the screen upon start (kernel-argument omapfb.rotate), I
thought it might be useful to rotate omap-vout accordingly in your application.
This is what the following patch does.
The patch is a diff against your latest commit
619164a994c8d878249d6c1b8b16c27074a04209.
I hope it is useful.
Greetings,
Florian
diff -rupN '--exclude=.git' omap3-isp-live/live.c omap3-isp-live-voisee/live.c
--- omap3-isp-live/live.c 2012-10-24 18:14:58.830555741 +0200
+++ omap3-isp-live-voisee/live.c2012-10-24 22:28:49.278056954 +0200
@@ -661,7 +674,36 @@ struct color_rgb24 {
unsigned int value:24;
} __attribute__((__packed__));
-static int fb_init(struct v4l2_rect *rect)
+/*
+ * Convert DSS rotation to V4L2 rotation
+ * V4L2 understand 0, 90, 180, 270 degrees.
+ */
+static int dss_rot_to_v4l2_rot(int dss_rotation,
+int *v4l2_rotation)
+{
+int ret = 0;
+
+switch (dss_rotation) {
+case 1:
+*v4l2_rotation = 90;
+break;
+case 2:
+*v4l2_rotation = 180;
+break;
+case 3:
+*v4l2_rotation = 270;
+break;
+case 0:
+*v4l2_rotation = 0;
+break;
+default:
+ret = -EINVAL;
+break;
+}
+return ret;
+}
+
+static int fb_init(struct v4l2_rect *rect, int *rotation)
{
struct color_24bpp ;
@@ -745,6 +787,8 @@ static int fb_init(struct v4l2_rect *rec
rect->width = var.xres;
rect->height = var.yres;
+ /* Return the rotation (if any) in degrees */
+ dss_rot_to_v4l2_rot(var.rotate, rotation);
done:
if (mem != NULL)
munmap(mem, fix.smem_len);
@@ -812,6 +858,7 @@ int main(int argc __attribute__((__unuse
unsigned int colorkey;
bool enable_aewb = true;
float fps;
+ int rotation;
int ret;
int c;
@@ -851,10 +898,10 @@ int main(int argc __attribute__((__unuse
}
events_init(&events);
input_init(&input);
memset(&rect, 0, sizeof rect);
- ret = fb_init(&rect);
+ ret = fb_init(&rect, &rotation);
if (ret < 0) {
printf("error: unable to initialize frame buffer\n");
goto cleanup;
@@ -879,7 +929,7 @@ int main(int argc __attribute__((__unuse
format.pixelformat = V4L2_PIX_FMT_YUYV;
format.width = rect.width;
format.height = rect.height;
- vo = vo_init(vo_devname, &vo_ops, buffers, &format);
+ vo = vo_init(vo_devname, &vo_ops, buffers, &format, rotation);
if (vo == NULL) {
printf("error: unable to initialize video output\n");
goto cleanup;
diff -rupN '--exclude=.git' omap3-isp-live/snapshot.c
omap3-isp-live-voisee/snapshot.c
--- omap3-isp-live/snapshot.c 2012-10-24 18:14:58.830555741 +0200
+++ omap3-isp-live-voisee/snapshot.c2012-10-24 22:28:49.274057063 +0200
@@ -45,6 +45,7 @@
#if USE_LIBJPEG
#include
#include
+#include "jpeg.h"
#endif
#include "isp/list.h"
@@ -55,7 +56,6 @@
#include "events.h"
#include "iq.h"
-#include "jpeg.h"
#define MEDIA_DEVICE "/dev/media0"
diff -rupN '--exclude=.git' omap3-isp-live/videoout.c
omap3-isp-live-voisee/videoout.c
--- omap3-isp-live/videoout.c 2012-09-28 14:43:53.978198906 +0200
+++ omap3-isp-live-voisee/videoout.c2012-10-24 22:28:49.278056954 +0200
@@ -54,7 +54,8 @@ struct videoout
struct videoout *vo_init(const char *devname,
const struct video_out_operations *ops,
unsigned int buffers,
-struct v4l2_pix_format *format)
+struct v4l2_pix_format *format,
+int rotation)
{
struct v4l2_pix_format pixfmt;
struct v4l2_format fmt;
@@ -76,6 +77,14 @@ struct videoout *vo_init(const char *dev
goto error;
}
+ /* setup the rotation here, we have to do it BEFORE
+* setting the format. */
+ ret = v4l2_set_control(vo->dev, V4L2_CID_ROTATE, &rotation);
+ if (ret < 0){
+ perror("Failed to setup rotation\n");
+ goto error;
+ }
+
pixfmt.pixelformat = format->pixelformat;
pixfmt.width = format->width;
pixfmt.height = format->height;
diff -rupN '--exclude=.git' omap3-isp-live/videoout.h
omap3-isp-live-voisee/videoout.h
--- omap3-isp-live/videoout.h 2012-09-28 14:43:53.978198906 +0200
+++ omap3-isp-live-voisee/videoout.h2012-10-24 22:28:49.274057063 +0200
@@ -34,10 +34,13 @@ struct video_out_operations {
void (*unwatch_fd)(int fd);
};
+int vo_set_rotation(struct videoout *vo,
AW: omap3-isp-live does not allocate big enough buffers?
Hi Laurent, Thank you for your fast answer. Laurent Pinchart wrote on 2012-10-08: > The OMAP3 ISP resizer can't scale down 1944 pixels (the native sensor > height) to exactly 480 pixels as that would exceed the resizer limits. > You will thus have to crop the sensor image slightly. Cropping is > supported by libomap3isp and by the snapshot application but not by the live > application. > Ideally the live application or the libomap3isp library should realize > that the ISP limits are exceeded and configure cropping on the sensor > accordingly. As an interim solution you could add manual crop support > to the live application using the snapshot application crop support code as > an example. I have seen, that the resizer "only" supports downscaling by 0.25, so with all the cropping, 1944 lines will come down to 482 which is too big for my framebuffer. If I apply some cropping in the omap3_isp_viewfinder_setup function, the output will work as expected. Now I'm going to crop on the sensor (or better on the first entity that supports cropping, as in your code) if the ratio "sensor input -> viewfinder output" exceeds 0.25. Are you interested in a patch for this? Regards, Florian -- 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
omap3-isp-live does not allocate big enough buffers?
Hi Laurent I am working on a demo-application for displaying a videostream on a beagleboard. Now I have seen that you have done something similar, but if I run your "live" application out of the omap3-isp-live repo, then I get the following error: root@beagleboard:~# modprobe omap_vout video1_numbuffers=3 video2_numbuffers=3 video1_bufsize=771200 video2_bufsize=771200 vid1_static_vrfb_alloc=n vid2_static_vrfb_alloc=n root@beagleboard:~# ./live fb size is 800x480 Device /dev/video6 opened: OMAP3 ISP resizer output (media). viewfinder configured for 2011 800x482 AEWB: #win 10x7 start 16x74 size 256x256 inc 30x30 trying to allocate 800x480 Device /dev/video7 opened: omap_vout (). 3 buffers requested. Buffer 0 mapped at address 0xb6d68000. Buffer 1 mapped at address 0xb6cac000. Buffer 2 mapped at address 0xb6bf. 3 buffers requested. Buffer 0 too small (771200 bytes required, 770048 bytes available). error: unable to allocate buffers for viewfinder. error: unable to set buffers pool This seems to happen in the v4l2_alloc_buffers function of v4l2.c when memtype is V4L2_MEMORY_USERPTR. Has it been broken in the newer kernel versions? Do you have hint where I should start fixing? I am using the following config: beagleboard-xm linux-omap branch, tag v3.5 leopard imaging li-5m03 with mt9p031 Greetings, Florian -- 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
AW: omap3isp: cropping bug in previewer?
Hi Laurent, Laurent Pinchart wrote on 2012-07-06: >> This patch resolves the issue for me. I get a good picture at both the >> previewer and the resizer output. Thanks for your help! > > You're welcome. Can I include your > > Tested-by: Florian Neuhaus > > in the patch ? Yes, of course! I tested it with the following commands: For the previewer out: # media-ctl -v -r -l '"mt9p031 2-0048":0->"OMAP3 ISP CCDC":0[1], "OMAP3 ISP CCDC":2->"OMAP3 ISP preview":0[1], "OMAP3 ISP preview":1->"OMAP3 ISP preview output":0[1]' # media-ctl -v -f '"mt9p031 2-0048":0 [SGRBG12 800x600], "OMAP3 ISP CCDC":2 [SGRBG10 800x600], "OMAP3 ISP preview":1 [UYVY 800x600]' # yavta -c1000 -p --stdout --skip 3 -f UYVY -s 782x592 /dev/video4 | mplayer - -demuxer rawvideo -rawvideo w=784:h=592:format=uyvy -vo fbdev -fs (Note the 784 width in the mplayer command) For the resizer out: # media-ctl -v -r -l '"mt9p031 2-0048":0->"OMAP3 ISP CCDC":0[1], "OMAP3 ISP CCDC":2->"OMAP3 ISP preview":0[1], "OMAP3 ISP preview":1->"OMAP3 ISP resizer":0[1], "OMAP3 ISP resizer":1->"OMAP3 ISP resizer output": 0[1]' # media-ctl -v -f '"mt9p031 2-0048":0 [SGRBG12 800x600], "OMAP3 ISP CCDC":2 [SGRBG10 800x600], "OMAP3 ISP preview":1 [UYVY 800x600], "OMAP3 ISP resizer":1 [UYVY 800x600]' # yavta -f UYVY -s 800x600 -n 8 --skip 3 --capture=1000 --stdout /dev/video6 | mplayer - -demuxer rawvideo -rawvideo w=800:h=600:format=uyvy -vo fbdev -- Best regards, Florian Neuhaus -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: omap3isp: cropping bug in previewer?
Hi Laurent,
Laurent Pinchart wrote on 2012-07-05:
> There's really an issue, which was introduced in v3.5-rc1. Could you please
> try
> the following patch instead of yours ?
>
> diff --git a/drivers/media/video/omap3isp/isppreview.c
> b/drivers/media/video/omap3isp/isppreview.c index 9c6dd44..614752a
> 100644 --- a/drivers/media/video/omap3isp/isppreview.c +++
> b/drivers/media/video/omap3isp/isppreview.c @@ -1116,7 +1116,7 @@ static
> void preview_config_input_size(struct isp_prev_device *prev, u32 active)
> unsigned int elv = prev->crop.top + prev->crop.height - 1;
> u32 features;
> - if (format->code == V4L2_MBUS_FMT_Y10_1X10) {
> + if (format->code != V4L2_MBUS_FMT_Y10_1X10) {
> sph -= 2;
> eph += 2;
> slv -= 2;
This patch resolves the issue for me. I get a good picture at both the
previewer and the resizer output. Thanks for your help!
--
Best regards,
Florian Neuhaus
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: omap3isp: cropping bug in previewer?
Hi Laurent,
Laurent Pinchart wrote on 2012-07-05:
>> When I now capture a frame with yavta (see [3] for details), I must use
>> 846x639 as frame size (as this size is reported by the driver). But it
>> seems that the outputted image is 2px wider (that means 848x639). This
>> results in a "scrambled"/unusable image on screen when streaming (see
>> [6] bad-frame-846x639_on_display.bmp for an example how it looks like
>> on screen). Also the file size too big for a 846x639 image: The frame
>> size is 1083744 bytes, which is exactly 848*639*2 (NOT 846*639*2)!
>
> The OMAP3 ISP pads lines to multiples of 32 or 64 bytes when reading
> from/writing to memory. 846 pixels * 2 bytes per pixel is not a multiple of 32
> bytes, so the line length gets padded to the next multiple, 848 pixels in this
> case. The information is reported by the bytesperline field of the
> v4l2_pix_format structure returned by VIDIOC_G_FMT and VIDIOC_S_FMT
> on the
> preview engine output video node. You need to take the padding into
> account in
> your application, that should solve your issue. raw2rgbpnm tries to detect
> padding at the end of lines, and skips it automatically.
Thanks for your fast answer and the explanation!
So you're saying that yavta doesn't check that the image is coming from the
previewer-output and has maybe a padding? So yavta needs a patch to extend the
line width when not aligned on 32 bytes or strip out the padding?
>> If you look in the isp-datasheet [7] in table 6-40 (page
>> 1201) you see, that the CFA interpolation block for bayer-mode crops 4
>> px per line and 4 lines. So shouldn't we respect this in the
>> preview_config_input_size function? My RFC is:
>>
>> Index: git/drivers/media/video/omap3isp/isppreview.c
>>
>> =
>> --- git.orig/drivers/media/video/omap3isp/isppreview.c 2012-07-05
>> 10:59:33.675358396 +0200 +++
>> git/drivers/media/video/omap3isp/isppreview.c2012-07-05
>> 12:14:33.723223514 +0200 @@ -1140,6 +1140,12 @@
>> } if (features & (OMAP3ISP_PREV_CHROMA_SUPP |
>> OMAP3ISP_PREV_LUMAENH)) sph -= 2;
>> +if (features & OMAP3ISP_PREV_CFA) {
>> +sph -= 2;
>> +eph += 2;
>> +slv -= 2;
>> +elv += 2;
>> +}
>>
>> isp_reg_writel(isp, (sph << ISPPRV_HORZ_INFO_SPH_SHIFT) | eph,
>> OMAP3_ISP_IOMEM_PREV, ISPPRV_HORZ_INFO);
>> =
>> NOTE: This still gives an unusable picture at the previewer output BUT if I
>> extend the pipeline to the resizer output, the picture is good. So I must
>> be missing something...
After reading your explanation about the padding, I understand why the image is
broken on the previewer out. But if I configure the pipeline to output on the
resizer-out, the image is still broken (without my patch). I used a resolution
of 800x600 for the resizer-out, so the alignment should be fine:
# media-ctl -v -r -l '"mt9p031 2-0048":0->"OMAP3 ISP CCDC":0[1], "OMAP3 ISP
CCDC":2->"OMAP3 ISP preview":0[1], "OMAP3 ISP preview":1->"OMAP3 ISP
resizer":0[1], "OMAP3 ISP resizer":1->"OMAP3 ISP resizer output": 0[1]'
# media-ctl -v -f '"mt9p031 2-0048":0 [SGRBG12 800x600], "OMAP3 ISP CCDC":2
[SGRBG10 800x600], "OMAP3 ISP preview":1 [UYVY 800x600], "OMAP3 ISP resizer":1
[UYVY 800x600]'
# yavta -f UYVY -s 800x600 -n 8 --skip 3 --capture=1000 --stdout /dev/video6 |
mplayer - -demuxer rawvideo -rawvideo w=800:h=600:format=uyvy -vo fbdev
Does my patch just output a good picture by chance, or is there really an issue?
--
Best regards,
Florian Neuhaus
--
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
omap3isp: cropping bug in previewer?
Dear all,
I am trying to get a mt9p031 sensor running on a beagleboard-xm with the
following configuration:
Hardware:
- beagleboard-xm, rev c1
- Leopard Imaging cam module LI-5M03 with a mt9p031 5MP sensor
Software:
- Angstrom-distro built with bitbake using the setup-scripts from [4] (commit
da56a56b690bcc07a50716f1071e90e2b3a4fb47).
- own bitbake recipe to build a linux-omap kernel 3.5-rc1 from the tmdlind
branch (this source: [5], tag omap-fixes-for-v3.5-rc1)
- some patches to update the 3.5-rc1 omap3-isp module (not the whole kernel) to
the latest omap3isp-sensors-next branch from Laurent Pinchart [1]
- yavta with an extension to output data to stdout
- mediactl to configure the omap3isp pipeline
Problem:
I configure a pipe with mediactl from OMAP3 ISP CCDC input to the previewer
output (see [3] for a detailed log) with an example resolution of 800x600. This
resolution is adapted by the omap3isp driver to 846x639 at the previewer
output. In my understanding the adjustment of the resolution (from 800x600 to
846x639) is a result of the following process:
1) The closest possible windowing of the mt9p031 sensor is 864x648.
2) The ccdc-source pad crops the height by one line (see function
ccdc_try_format in ispccdc.c) - we are now on 864x647
3) The previewer (isppreview.c) crops a left margin of 8px and a right margin
of 6px (see the PREV_MARGIN_* defines) plus 4px if the input is from ccdc (see
preview_try_crop) - we are now on 846x639.
As there are no filters activated, the input size will not be modified by the
preview_config_input_size function.
When I now capture a frame with yavta (see [3] for details), I must use 846x639
as frame size (as this size is reported by the driver). But it seems that the
outputted image is 2px wider (that means 848x639). This results in a
"scrambled"/unusable image on screen when streaming (see [6]
bad-frame-846x639_on_display.bmp for an example how it looks like on screen).
Also the file size too big for a 846x639 image:
The frame size is 1083744 bytes, which is exactly 848*639*2 (NOT 846*639*2)!
Then I transformed the "bad" yuv-picture with raw2rgbpnm which gives me a good
picture with both frame-sizes (see bad-frame-846x639.pnm and
bad-frame-848x639_on_display.bmp in [6]).
So the picture-information seems to be good, but I guess that the input-size is
configured badly by the driver.
If you look in the isp-datasheet [7] in table 6-40 (page 1201) you see, that
the CFA interpolation block for bayer-mode crops 4 px per line and 4 lines.
So shouldn't we respect this in the preview_config_input_size function?
My RFC is:
Index: git/drivers/media/video/omap3isp/isppreview.c
===
--- git.orig/drivers/media/video/omap3isp/isppreview.c 2012-07-05
10:59:33.675358396 +0200
+++ git/drivers/media/video/omap3isp/isppreview.c 2012-07-05
12:14:33.723223514 +0200
@@ -1140,6 +1140,12 @@
}
if (features & (OMAP3ISP_PREV_CHROMA_SUPP | OMAP3ISP_PREV_LUMAENH))
sph -= 2;
+ if (features & OMAP3ISP_PREV_CFA) {
+ sph -= 2;
+ eph += 2;
+ slv -= 2;
+ elv += 2;
+ }
isp_reg_writel(isp, (sph << ISPPRV_HORZ_INFO_SPH_SHIFT) | eph,
OMAP3_ISP_IOMEM_PREV, ISPPRV_HORZ_INFO);
===
NOTE: This still gives an unusable picture at the previewer output BUT if I
extend the pipeline to the resizer output, the picture is good. So I must be
missing something...
It would be nice, if someone could tell me, if my assumptions are right and
point me the right direction.
Further information:
- Bootup dmesg: [2]
- Configuration of the pipe with mediactl, capturing of an image with yavta and
analyze of the image with raw2rgbpnm: [3]
[1]
http://git.linuxtv.org/pinchartl/media.git/commit/019214973ee4f03c8f2d582468b914fcf3385089
[2] http://pastebin.com/7PQnzcmx
[3] http://pastebin.com/ChEaYHMy
[4] https://github.com/Angstrom-distribution/setup-scripts
[5] git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git
[6] https://www.dropbox.com/sh/p2fy5u4i71c3vy8/Fyya25YqK-
[7] http://www.ti.com/lit/ug/sprugn4q/sprugn4q.pdf
Greetings,
Florian Neuhaus
--
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
