Re: Embedded Linux Conference
Hi Tony, I think I can join you. And also Kyungmin Park I guess. See you then. Nate 2009. 03. 18, 오전 1:45, Tony Lindgren 작성: * Kevin Hilman khil...@deeprootsystems.com [090317 07:50]: Hans Verkuil wrote: On Tuesday 17 March 2009 01:14:28 Steve Sakoman wrote: On Mon, Mar 16, 2009 at 3:56 PM, Tony Lindgren t...@atomide.com wrote: * Kevin Hilman khil...@deeprootsystems.com [090316 15:52]: Hans Verkuil hverk...@xs4all.nl writes: Just FYI: I'll be attending the Embedded Linux Conference in San Francisco, April 6th-8th (http://www.embeddedlinuxconference.com/elc_2009). This might be a good opportunity to discuss omap and davinci V4L2 issues face-to-face. Let me know if you are interested. I will be there as well, and while not directly involved with V4L2, I'm involved in various parts of getting OMAP and DaVinci devices supported in mainline kernels. Yeah I'll be in town too and will be dropping by at the conf here and there. Maybe let's arrange something to get some beers one night during the conf? I'll be there too. How about Wednesday evening for beers? Steve On Wednesday evening there is the 'social event', which means free food and beer :-). So I'd say that evening is covered. However, I'd welcome dinner on Sunday evening. Having arrived that day from Europe I won't be a sparkling conversationalist but it beats having dinner by your own and gives us a chance to meet one another. I won't be arriving until late Sunday night, and I imagine others may be arrving Monday morning. How about Monday night after the Dinner (ends at 7pm [1]) we meet for beers. I'll let someone local (Tony) pick the venue. OK, let's plan for Monday night then. I'll find some place with drinks easily available, and within walking distance from the conference. I've added a placeholder for the event where I'll post the details later on: http://www.muru.com/linux/omap/events/ To get a rough idea how many people we'll have, please reply to this thread, or send me an email if you're planning to attend. Cheers, Tony [1] http://www.embeddedlinuxconference.com/elc_2009/program.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] How to pass camera Orientation to userspace
Hello Hans. I went too far. Just forgot what we can do through porting job. You are right. That should be board specific item. Cheers, Nate 2009. 02. 18, 오후 11:36, Hans de Goede 작성: DongSoo(Nathaniel) Kim wrote: Hello Adam, I've been thinking exactly the same issue not usb but SoC based camera. I have no idea about how usb cameras work but I am quite curious about is it really possible to make proper orientation with only querying camera driver. Because in case of SoC based camera device, many of camera ISPs are supporting VFLIP, HFLIP register on their own, and we can read current orientation by reading those registers. But the problem is ISP's registers are set as not flipped at all but it physically mounted upside down, because the H/W vendor has packed the camera module upside down. (it sounds ridiculous but happens sometimes) That happens a lot with webcams too. Given that these SoC systems will come with some board specific config anyways, all that is needed is to pass some boardconfig in to the camera driver (through platform data for example) which tells the camera driver that on this board the sensor is mounted upside down. So in that case when we query orientation of camera, it returns not flipped vertically or horizontally at all but actually it turns out to be upside down. Actually we are setting camera device to be flipped for default in that case. Ack, but the right thing to do is not to set the vflip and hflip video4linux2 controls on by default, but to invert their meaning, so when the sensor is upside down, the hflip and vflip controls as seen by the application through the v4l2 API will report not flipping, but the hwcontrols will actually be set to flipping, and when an app enables flipping at the v4l2 API level it will actually gets disables at the HW level, this way the upside downness is 100% hidden from userspace. So your problem does not need any of the new API we are working on. The new API is for when the hardware cannot flip and we need to tell userspace to correct for this in software. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [REVIEW PATCH 11/14] OMAP34XXCAM: Add driver
Thank you for your comment.
BTW, what should I do if I would rather use external ISP device than
OMAP3 internal ISP feature?
You said that you just have raw sensors by now, so you mean this patch
is not verified working with some ISP modules?
I'm testing your patch on my own omap3 target board with NEC ISP...but
unfortunately not working yet ;(
I should try more harder. more research is needed :)
Cheers,
On Thu, Feb 12, 2009 at 4:09 PM, Sakari Ailus
sakari.ai...@maxwell.research.nokia.com wrote:
DongSoo Kim wrote:
Hello.
Hi, and thanks for the comments!
+static int omap34xxcam_open(struct inode *inode, struct file *file)
+{
snip
+ if (atomic_inc_return(vdev-users) == 1) {
+ isp_get();
+ if (omap34xxcam_slave_power_set(vdev, V4L2_POWER_ON,
+
OMAP34XXCAM_SLAVE_POWER_ALL))
+ goto out_slave_power_set_standby;
+ omap34xxcam_slave_power_set(
+ vdev, V4L2_POWER_STANDBY,
+ OMAP34XXCAM_SLAVE_POWER_SENSOR);
+ omap34xxcam_slave_power_suggest(
+ vdev, V4L2_POWER_STANDBY,
+ OMAP34XXCAM_SLAVE_POWER_LENS);
+ }
I'm wondering whether this V4L2_POWER_STANDBY operation for sensor
device is really necessary.
Because if that makes sensor device in standby mode, we do S_FMT and
bunch of V4L2 APIs while the camera module is in standby mode.
In most cases of sensor + ISP SOC camera modules, I2C command is not
working while the camera module is in standby mode.
I guess that applies to most sensors.
Following the camera interface source code, sensor goes down to
standby mode until VIDIOC_STREAMON is called.
If this power up timing depends on sensor device, then I think we need
a conditional power on sequence.
You're right, there's something wrong with the slave power handling. :)
We were thinking that the sensor (or any slave) power management (current
on, off and standby) could be replaced by four commands: open, close,
streamon and streamoff. The slave could decide by itself what its real power
state is. IMO direct power management doesn't belong to the camera driver
which doesn't drive any hardware anyway.
As you defined slave devices as SENSOR, LENS, FLASH, then how about
making a new slave category like ISP for sensor+ISP SOC modules?
I currently have just raw sensors. It'd be nice to keep the interface for
smart sensors the same, though. You still need for a receiver for the image
data, sometimes called the camera controller. That would be the same than
the ISP but without fancy features.
Cheers,
--
Sakari Ailus
sakari.ai...@maxwell.research.nokia.com
--
Dong Soo, Kim
Engineer
Mobile S/W Platform Lab. S/W centre
Telecommunication RD Centre
Samsung Electronics CO., LTD.
e-mail : dongsoo@gmail.com
dongsoo45@samsung.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [REVIEW PATCH 11/14] OMAP34XXCAM: Add driver
Hello.
+static int omap34xxcam_open(struct inode *inode, struct file *file)
+{
snip
+ if (atomic_inc_return(vdev-users) == 1) {
+ isp_get();
+ if (omap34xxcam_slave_power_set(vdev, V4L2_POWER_ON,
+ OMAP34XXCAM_SLAVE_POWER_ALL))
+ goto out_slave_power_set_standby;
+ omap34xxcam_slave_power_set(
+ vdev, V4L2_POWER_STANDBY,
+ OMAP34XXCAM_SLAVE_POWER_SENSOR);
+ omap34xxcam_slave_power_suggest(
+ vdev, V4L2_POWER_STANDBY,
+ OMAP34XXCAM_SLAVE_POWER_LENS);
+ }
I'm wondering whether this V4L2_POWER_STANDBY operation for sensor
device is really necessary.
Because if that makes sensor device in standby mode, we do S_FMT and
bunch of V4L2 APIs while the camera module is in standby mode.
In most cases of sensor + ISP SOC camera modules, I2C command is not
working while the camera module is in standby mode.
Following the camera interface source code, sensor goes down to
standby mode until VIDIOC_STREAMON is called.
If this power up timing depends on sensor device, then I think we need
a conditional power on sequence.
As you defined slave devices as SENSOR, LENS, FLASH, then how about
making a new slave category like ISP for sensor+ISP SOC modules?
Then we could make slave devices with conditional cases.
Cheers.
Regards,
Nate
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [REVIEW PATCH 11/14] OMAP34XXCAM: Add driver
Hello.
This could be something trivial.
On Tue, Jan 13, 2009 at 11:03 AM, Aguirre Rodriguez, Sergio Alberto
saagui...@ti.com wrote:
+/**
+ * struct omap34xxcam_hw_config - struct for vidioc_int_g_priv ioctl
+ * @xclk: OMAP34XXCAM_XCLK_A or OMAP34XXCAM_XCLK_B
+ * @sensor_isp: Is sensor smart/SOC or raw
+ * @s_pix_sparm: Access function to set pix and sparm.
+ * Pix will override sparm
+ */
+struct omap34xxcam_hw_config {
+ int dev_index; /* Index in omap34xxcam_sensors */
I found omap34xxcam_sensors in your comment, but it couldn't found anywhere.
Let me guess that it means omap34xxcam_videodev. Am I right?
Cheers.
Regards,
Nate
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
OMAP3430 camear ISP strobe control
Hello. Since I was working on OMAP3 camera driver with camera interface driver in OMAPZOOM repository, I could not figure it out how to control strobe device. I found that strobe control depends on CSI1 (MIPI)..but how could I control that? In my opinion, in case of OMAP3 ISP has to be made in v4l2 int device way. (of course new v4l2 int device commands should be made either) And also new V4L2 API should be made I guess...;( Anyone has any idea? -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
