Re: Linux Plumbers Conference 2009: V4L2 API discussions
On Tue, Aug 4, 2009 at 4:12 PM, Hans Verkuil wrote: > Hi all, > > During this years Plumbers Conference I will be organizing a session (or > possibly more than one) on what sort of new V4L2 APIs are needed to > support the new SoC devices. These new APIs should also solve the problem > of how to find all the related alsa/fb/ir/dvb devices that a typical video > device might create. > > A proposal was made about a year ago (note that this is a bit outdated > by now, but the basics are still valid): > > http://www.archivum.info/video4linux-list%40redhat.com/2008-07/msg00371.html > > In the past year the v4l2 core has evolved enough so that we can finally > start thinking about this for real. > > I would like to know who will be attending this conference. I also urge > anyone who is working in this area and who wants to have a say in this to > attend the conference. The goal is to prepare a new RFC with a detailed > proposal on the new APIs that are needed to fully support all the new > SoCs. So the more input we get, the better the end-result will be. > > Early-bird registration is still possible up to August 5th (that's > tomorrow :-) ). > > Regards, > > Hans > > -- > Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom > I've been hardly trying to attend the conference but I'm afraid not gonna make it. But going to try to arrange the characteristics of the H/W I'm working on in a brief document and also expected new V4P2 APIs. I'll let you know when I finish my documentation. I know this is a good chance to discuss about where the video4linux for SoC platforms to go and I'm desperately looking forward to participate. but my business trip depends on the approval of my boss. Thus I'm very disappointed that I can't make it. Cheers, Nate -- = DongSoo, Nathaniel Kim Engineer Mobile S/W Platform Lab. Digital Media & Communications R&D 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: v4l2_int_device vs v4l2_subdev?
Hello, On Fri, Jun 26, 2009 at 7:43 AM, Gary Thomas wrote: > Still trying to wrap my head around the OMAP/34xx camera support. > I need to use the TVP5150 sensor/controller, but the existing > driver uses v4l_subdev. The "working" examples I've found > (from Sergio's tree) use sensors like ov3640 with uses v4l2_int_device > > Are these two totally separate beasts? > If I have an infrastructure (I assume) based on v4l2_int_device, > how do I use a v4l2_subdev device driver? or need I move one to > the other? > I've been through the same case (now I'm trying to use subdev framework and writing a new device driver based on that) As far as I understand, every v4l2 drivers are moving on subdev framework. But in user space there is nothing changed having access to device and control them. As you know, subdev and int-device is all about how to bind interface(or host?) and device and make them communicated each other. But using subdev device driver with int-device supporting interface (or host) device driver? it won't make any communication. So if you are running out of time with your project, you'd better use old driver of TVP. Like TVP driver in kernel 2.6.28 I suppose. But if you have enough time and wanna be challenging, try to convert in-device based omap3 camera interface driver to subdev supporting one. Cheers, Nate > ... dizzy from traveling down too many twisty little passages :-( > > -- > > Gary Thomas | Consulting for the > MLB Associates | Embedded world > > -- > 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 > -- = DongSoo, Nathaniel Kim Engineer Mobile S/W Platform Lab. Digital Media & Communications R&D 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: [PATCH 3/3] OMAP2/3 V4L2 Display Driver
Hi Hardik,
According to earlier mail from Sergio, I could be noticed that it is
totally ok to restrict number of buffers by driver. As matter of fact,
I was always considering about the H/W restriction and could find the
answer from his mail.
By the way, thank you for your answer.
Cheers,
Nate
On Tue, May 19, 2009 at 2:28 PM, Shah, Hardik wrote:
> Hi Nate,
>
>
>> -Original Message-
>> From: Aguirre Rodriguez, Sergio Alberto
>> Sent: Tuesday, May 19, 2009 10:52 AM
>> To: Dongsoo, Nathaniel Kim; Shah, Hardik
>> Cc: linux-me...@vger.kernel.org; linux-omap@vger.kernel.org; Jadav, Brijesh
>> R;
>> Hiremath, Vaibhav
>> Subject: RE: [PATCH 3/3] OMAP2/3 V4L2 Display Driver
>>
>> Hi Nate,
>>
>> I have 1 input regarding your question:
>>
>> >From: linux-media-ow...@vger.kernel.org [linux-media-ow...@vger.kernel.org]
>> On Behalf Of Dongsoo, Nathaniel Kim [dongsoo@gmail.com]
>> >Sent: Tuesday, May 19, 2009 7:53 AM
>> >To: Shah, Hardik
>> >Cc: linux-me...@vger.kernel.org; linux-omap@vger.kernel.org; Jadav, Brijesh
>> R; Hiremath, Vaibhav
>> >Subject: Re: [PATCH 3/3] OMAP2/3 V4L2 Display Driver
>> >
>> >Hello Hardik,
>> >
>> >Reviewing your driver, I found something made me curious.
>> >
>> >
>> >On Wed, Apr 22, 2009 at 3:25 PM, Hardik Shah wrote:
>>
>>
>>
>> >> +/* Buffer setup function is called by videobuf layer when REQBUF ioctl is
>> >> + * called. This is used to setup buffers and return size and count of
>> >> + * buffers allocated. After the call to this buffer, videobuf layer will
>> >> + * setup buffer queue depending on the size and count of buffers
>> >> + */
>> >> +static int omap_vout_buffer_setup(struct videobuf_queue *q, unsigned int
>> *count,
>> >> + unsigned int *size)
>> >> +{
>> >> + struct omap_vout_device *vout = q->priv_data;
>> >> + int startindex = 0, i, j;
>> >> + u32 phy_addr = 0, virt_addr = 0;
>> >> +
>> >> + if (!vout)
>> >> + return -EINVAL;
>> >> +
>> >> + if (V4L2_BUF_TYPE_VIDEO_OUTPUT != q->type)
>> >> + return -EINVAL;
>> >> +
>> >> + startindex = (vout->vid == OMAP_VIDEO1) ?
>> >> + video1_numbuffers : video2_numbuffers;
>> >> + if (V4L2_MEMORY_MMAP == vout->memory && *count < startindex)
>> >> + *count = startindex;
>> >> +
>> >> + if ((rotation_enabled(vout->rotation)) && *count > 4)
>> >> + *count = 4;
>> >> +
>> >
>> >
>> >
>> >This seems to be weird to me. If user requests multiple buffers more
>> >than 4, user cannot recognize that the number of buffers requested is
>> >forced to change into 4. I'm not sure whether this could be serious or
>> >not, but it is obvious that user can have doubt about why if user have
>> >no information about the OMAP H/W.
>> >Is it really necessary to be configured to 4?
> [Shah, Hardik] Rotation requires the VRFB contexts and limited number of
> contexts are available. So maximum number of buffers is fixed to 4 when
> rotation is enabled.
>
> Thanks,
> Hardik
>> >
>> >
>> >Cheers,
>> >
>> >Nate
>> >
>>
>> We did a very similar thing on omap3 camera driver, not exactly by the number
>> of buffers requested, but more about checking if the bytesize of the total
>> requested buffers was superior to the MMU fixed sized page table size
>> capabilities to map that size, then we were limiting the number of buffers
>> accordingly (for keeping the page table size fixed).
>>
>> According to the v4l2 spec, changing the count value should be valid, and it
>> is the userspace app responsability to check the value again, to confirm how
>> many of the requested buffers are actually available.
>>
>> Regards,
>> Sergio
>
--
=
DongSoo, Nathaniel Kim
Engineer
Mobile S/W Platform Lab.
Digital Media & Communications R&D 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: [PATCH 3/3] OMAP2/3 V4L2 Display Driver
Hi Sergio,
Thank you for your explanation . I learned much from that.
Cheers,
Nate
On Tue, May 19, 2009 at 2:22 PM, Aguirre Rodriguez, Sergio Alberto
wrote:
> Hi Nate,
>
> I have 1 input regarding your question:
>
>>From: linux-media-ow...@vger.kernel.org [linux-media-ow...@vger.kernel.org]
>>On Behalf Of Dongsoo, Nathaniel Kim [dongsoo@gmail.com]
>>Sent: Tuesday, May 19, 2009 7:53 AM
>>To: Shah, Hardik
>>Cc: linux-me...@vger.kernel.org; linux-omap@vger.kernel.org; Jadav, Brijesh
>>R; Hiremath, Vaibhav
>>Subject: Re: [PATCH 3/3] OMAP2/3 V4L2 Display Driver
>>
>>Hello Hardik,
>>
>>Reviewing your driver, I found something made me curious.
>>
>>
>>On Wed, Apr 22, 2009 at 3:25 PM, Hardik Shah wrote:
>
>
>
>>> +/* Buffer setup function is called by videobuf layer when REQBUF ioctl is
>>> + * called. This is used to setup buffers and return size and count of
>>> + * buffers allocated. After the call to this buffer, videobuf layer will
>>> + * setup buffer queue depending on the size and count of buffers
>>> + */
>>> +static int omap_vout_buffer_setup(struct videobuf_queue *q, unsigned int
>>> *count,
>>> + unsigned int *size)
>>> +{
>>> + struct omap_vout_device *vout = q->priv_data;
>>> + int startindex = 0, i, j;
>>> + u32 phy_addr = 0, virt_addr = 0;
>>> +
>>> + if (!vout)
>>> + return -EINVAL;
>>> +
>>> + if (V4L2_BUF_TYPE_VIDEO_OUTPUT != q->type)
>>> + return -EINVAL;
>>> +
>>> + startindex = (vout->vid == OMAP_VIDEO1) ?
>>> + video1_numbuffers : video2_numbuffers;
>>> + if (V4L2_MEMORY_MMAP == vout->memory && *count < startindex)
>>> + *count = startindex;
>>> +
>>> + if ((rotation_enabled(vout->rotation)) && *count > 4)
>>> + *count = 4;
>>> +
>>
>>
>>
>>This seems to be weird to me. If user requests multiple buffers more
>>than 4, user cannot recognize that the number of buffers requested is
>>forced to change into 4. I'm not sure whether this could be serious or
>>not, but it is obvious that user can have doubt about why if user have
>>no information about the OMAP H/W.
>>Is it really necessary to be configured to 4?
>>
>>
>>Cheers,
>>
>>Nate
>>
>
> We did a very similar thing on omap3 camera driver, not exactly by the number
> of buffers requested, but more about checking if the bytesize of the total
> requested buffers was superior to the MMU fixed sized page table size
> capabilities to map that size, then we were limiting the number of buffers
> accordingly (for keeping the page table size fixed).
>
> According to the v4l2 spec, changing the count value should be valid, and it
> is the userspace app responsability to check the value again, to confirm how
> many of the requested buffers are actually available.
>
> Regards,
> Sergio
--
=
DongSoo, Nathaniel Kim
Engineer
Mobile S/W Platform Lab.
Digital Media & Communications R&D 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: [RFC] Stand-alone Resizer/Previewer Driver support under V4L2 framework
Hello Vaibhav, On Tue, Apr 21, 2009 at 9:08 PM, Hiremath, Vaibhav wrote: >> -Original Message- >> From: Dongsoo, Nathaniel Kim [mailto:dongsoo@gmail.com] >> Sent: Tuesday, April 21, 2009 3:44 PM >> To: Hiremath, Vaibhav >> Cc: Hans Verkuil; linux-me...@vger.kernel.org; Aguirre Rodriguez, >> Sergio Alberto; Toivonen Tuukka.O (Nokia-D/Oulu); linux- >> o...@vger.kernel.org; Nagalla, Hari; Sakari Ailus; Jadav, Brijesh R; >> R, Sivaraj; Hadli, Manjunath; Shah, Hardik; Kumar, Purushotam >> Subject: Re: [RFC] Stand-alone Resizer/Previewer Driver support >> under V4L2 framework >> >> Hello, Vaibhav, >> >> >> On Tue, Apr 21, 2009 at 7:01 PM, Hiremath, Vaibhav >> wrote: >> > >> >> -----Original Message- >> >> From: Hiremath, Vaibhav >> >> Sent: Tuesday, April 21, 2009 3:16 PM >> >> To: 'Dongsoo, Nathaniel Kim' >> >> Cc: Hans Verkuil; linux-me...@vger.kernel.org; Aguirre Rodriguez, >> >> Sergio Alberto; Toivonen Tuukka.O (Nokia-D/Oulu); linux- >> >> o...@vger.kernel.org; Nagalla, Hari; Sakari Ailus; Jadav, Brijesh >> R; >> >> R, Sivaraj; Hadli, Manjunath; Shah, Hardik; Kumar, Purushotam >> >> Subject: RE: [RFC] Stand-alone Resizer/Previewer Driver support >> >> under V4L2 framework >> >> >> >> > -Original Message- >> >> > From: Dongsoo, Nathaniel Kim [mailto:dongsoo@gmail.com] >> >> > Sent: Monday, April 20, 2009 4:15 PM >> >> > To: Hiremath, Vaibhav >> >> > Cc: Hans Verkuil; linux-me...@vger.kernel.org; Aguirre >> Rodriguez, >> >> > Sergio Alberto; Toivonen Tuukka.O (Nokia-D/Oulu); linux- >> >> > o...@vger.kernel.org; Nagalla, Hari; Sakari Ailus; Jadav, >> Brijesh >> >> R; >> >> > R, Sivaraj; Hadli, Manjunath; Shah, Hardik; Kumar, Purushotam >> >> > Subject: Re: [RFC] Stand-alone Resizer/Previewer Driver support >> >> > under V4L2 framework >> >> > >> >> > Hello Vaibhav, >> >> > >> >> > This is user manual of S3C6400 (not much different from >> S3C6410) >> >> > >> >> >> http://www.ebv.com/fileadmin/products/Products/Samsung/S3C6400/S3C64 >> >> > 00X_UserManual_rev1-0_2008-02_661558um.pdf >> >> > >> >> > That SoC is from my company but not from the same division of >> >> mine. >> >> > Actually I'm doing this driver job without any request from >> chip >> >> > delivering division. I'm doing this because this is so >> challenging >> >> > and >> >> > want better generic driver :-) >> >> > >> >> > Take a look at the user manual and please let me know your >> >> opinion. >> >> > In my understanding scaler and some camera interface feature in >> >> > S3C64XX are very similar to the features in Omap3. >> >> > >> >> [Hiremath, Vaibhav] Hi Kim, >> >> >> >> I went through the document and below are some observations and >> >> questions I have - >> >> >> >> - If I compare it with OMAP then there is nothing >> application >> >> needs to configure specific to hardware. All the parameters >> >> supported through "v4l2_format" one with TYPE_VIDEO_OUTPUT and >> >> another with TYPE_VIDEO_CAPTURE except the parameter "offset" (If >> >> driver is supporting it) >> >> >> >> I'm not sure whether I'm following your question, but S3C64XX camera >> interface is obviously simpler than OMAP. So there is no wonder that >> user doesn't need to configure H/W specific things. And I don't get >> the question about "offset" parameter. Can you explain me more >> specifically? >> > [Hiremath, Vaibhav] Please refer to the section 16.5.1 (Page no 532 (16-11)) > 16.7.11 and 16.7.16. > > You can specify offset from the input image to start, so that you can have > part of image for scaling. Oh! sorry I made you get confused. What I'm working on is not the TV scaler of S3C64XX but scaler and rotator in camera interface. Please take a look at "20-1 camera interface" This scaler/rotator feature can be used in general purpose. > >> >> >> - I wanted to understand how are you configuring offset >> >> register? How are you exporting it to user application? >> >
Re: [RFC] Stand-alone Resizer/Previewer Driver support under V4L2 framework
Hello, Vaibhav, On Tue, Apr 21, 2009 at 7:01 PM, Hiremath, Vaibhav wrote: > >> -Original Message- >> From: Hiremath, Vaibhav >> Sent: Tuesday, April 21, 2009 3:16 PM >> To: 'Dongsoo, Nathaniel Kim' >> Cc: Hans Verkuil; linux-me...@vger.kernel.org; Aguirre Rodriguez, >> Sergio Alberto; Toivonen Tuukka.O (Nokia-D/Oulu); linux- >> o...@vger.kernel.org; Nagalla, Hari; Sakari Ailus; Jadav, Brijesh R; >> R, Sivaraj; Hadli, Manjunath; Shah, Hardik; Kumar, Purushotam >> Subject: RE: [RFC] Stand-alone Resizer/Previewer Driver support >> under V4L2 framework >> >> > -Original Message- >> > From: Dongsoo, Nathaniel Kim [mailto:dongsoo@gmail.com] >> > Sent: Monday, April 20, 2009 4:15 PM >> > To: Hiremath, Vaibhav >> > Cc: Hans Verkuil; linux-me...@vger.kernel.org; Aguirre Rodriguez, >> > Sergio Alberto; Toivonen Tuukka.O (Nokia-D/Oulu); linux- >> > o...@vger.kernel.org; Nagalla, Hari; Sakari Ailus; Jadav, Brijesh >> R; >> > R, Sivaraj; Hadli, Manjunath; Shah, Hardik; Kumar, Purushotam >> > Subject: Re: [RFC] Stand-alone Resizer/Previewer Driver support >> > under V4L2 framework >> > >> > Hello Vaibhav, >> > >> > This is user manual of S3C6400 (not much different from S3C6410) >> > >> http://www.ebv.com/fileadmin/products/Products/Samsung/S3C6400/S3C64 >> > 00X_UserManual_rev1-0_2008-02_661558um.pdf >> > >> > That SoC is from my company but not from the same division of >> mine. >> > Actually I'm doing this driver job without any request from chip >> > delivering division. I'm doing this because this is so challenging >> > and >> > want better generic driver :-) >> > >> > Take a look at the user manual and please let me know your >> opinion. >> > In my understanding scaler and some camera interface feature in >> > S3C64XX are very similar to the features in Omap3. >> > >> [Hiremath, Vaibhav] Hi Kim, >> >> I went through the document and below are some observations and >> questions I have - >> >> - If I compare it with OMAP then there is nothing application >> needs to configure specific to hardware. All the parameters >> supported through "v4l2_format" one with TYPE_VIDEO_OUTPUT and >> another with TYPE_VIDEO_CAPTURE except the parameter "offset" (If >> driver is supporting it) >> I'm not sure whether I'm following your question, but S3C64XX camera interface is obviously simpler than OMAP. So there is no wonder that user doesn't need to configure H/W specific things. And I don't get the question about "offset" parameter. Can you explain me more specifically? >> - I wanted to understand how are you configuring offset >> register? How are you exporting it to user application? >> Again, I don't get the point. Sorry. >> Rest everything we can handle in driver once input source and output >> destination format receives from application. >> > [Hiremath, Vaibhav] Missed one point in last draft, about buffer handling. > How are you handling buffers? Are you supporting both USER_POINTER and MMAP > buffers? > What is the size of buffers, is that different for input and output? > If yes, then how are you managing it? > > If no, don't you see requirement for it? Sorry, my driver work is not that stage yet. It's just still in designing level, because of some special H/W features (like MSDMA, scaler and so) I'm totally stuck and can't go further. But your buffer theory seems to make sense and I suppose that is necessary if we have that kind of device. > > Thanks, > Vaibhav > >> From OMAP Point of view - >> --- >> >> The extra configuration is coefficients, which if we don't export to >> user application then I think we are very close to your IP. >> >> Extra configuration required other than coeff. >> >> RSZ_YENH - which takes 4 params >> >> - Algo >> - Gain >> - Slope >> - Core >> >> All are part of one register so we can make use of "priv" field for >> this configuration. >> I get it. But S3C64XX is not that much configurable. As you see in user manual, it's a quite simple device. For now I'm still designing my driver, so I'll let you know if I face those issues in my driver. Cheers, Nate >> >> Thanks, >> Vaibhav Hiremath >> >> > Cheers, >> > >> > Nate >> > >> > On Mon, Apr 20, 2009
Re: [RFC] Stand-alone Resizer/Previewer Driver support under V4L2 framework
size (the size of the resized image), then just >> send >> >>> the >> >>> frames to the device (== resizer) and get them back on the >> capture >> >>> side. >> >> >> >> [Hiremath, Vaibhav] Yes, it is possible to do that. >> >> >> >> Hans, >> >> >> >> I went through the link referred by Sergio and I think we should >> >> inherit >> >> some implementation for CODECs here for such devices. >> >> >> >> V4L2_BUF_TYPE_CODECIN - To access the input format. >> >> V4L2_BUF_TYPE_CODECOUT - To access the output format. >> >> >> >> It makes sense, since such memory-to-memory devices will mostly >> being >> >> used from codecs context. And this would be more clear from user >> >> application. >> > >> > To be honest, I don't see the need for this. I think >> > TYPE_VIDEO_CAPTURE and >> > TYPE_VIDEO_OUTPUT are perfectly fine. >> > >> >> And as acknowledged by you, we can use VIDIOC_S_FMT for setting >> >> parameters. >> >> >> >> One thing I am not able to convince myself is that, using "priv" >> >> field >> >> for custom configuration. >> > >> > I agree. Especially since you cannot use it as a pointer to >> addition >> > information. >> > >> >> I would prefer and recommend capability based >> >> interface, where application will query the capability of the >> >> device for >> >> luma enhancement, filter coefficients (number of coeff and >> depth), >> >> interpolation type, etc... >> >> >> >> This way we can make sure that, any such future devices can be >> >> adapted by >> >> this framework. >> > >> > The big question is how many of these capabilities are 'generic' >> and >> > how >> > many are very much hardware specific. I am leaning towards using >> the >> > extended control API for this. It's a bit awkward to implement in >> > drivers >> > at the moment, but that should improve in the future when a lot of >> the >> > control handling code will move into the new core framework. >> > >> > I really need to know more about the sort of features that omap/ >> > davinci >> > offer (and preferably also for similar devices by other >> > manufacturers). >> > >> >> >> >> >> >> Hans, >> >> Have you get a chance to look at Video-Buf layer issues I >> mentioned >> >> in >> >> original draft? >> > >> > I've asked Magnus Damm to take a look at this. I know he did some >> > work in >> > this area and he may have fixed some of these issues already. Very >> > useful, >> > that Embedded Linux conference... >> > >> > Regards, >> > >> > Hans >> > >> > -- >> > Hans Verkuil - video4linux developer - sponsored by TANDBERG >> >> = >> DongSoo, Nathaniel Kim >> Engineer >> Mobile S/W Platform Lab. >> Digital Media & Communications R&D Centre >> Samsung Electronics CO., LTD. >> e-mail : dongsoo@gmail.com >>dongsoo45@samsung.com >> >> >> >> -- >> To unsubscribe from this list: send the line "unsubscribe linux- >> media" in >> the body of a message to majord...@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html > > -- DongSoo, Nathaniel Kim Engineer Mobile S/W Platform Lab. Digital Media & Communications R&D 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: Embedded Linux Conference
Oh! I can see my laptop! It was nice to meet you everyone. Sorry for not be talking with you much. I had to review my work with Hans before today's presentation. I appreciate for the beer. Cheers. Nate On Wed, Apr 8, 2009 at 12:53 AM, Tony Lindgren wrote: > * Tony Lindgren [090406 18:45]: >> On Mon, Apr 06, 2009 at 11:45:39PM +, Tony Lindgren wrote: >> > On Tue, Apr 07, 2009 at 01:18:05AM +0200, Hans Verkuil wrote: >> > > >> > > > * Dongsoo Kim [090317 10:36]: >> > > > >> > > > >> > > > >> > > >>>> 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/ >> > > > >> > > > OK, let's meet at Harry's bar 7pm at 2020 Fillmore St >> > > > between Pine and California St. They're closed until 4pm, >> > > > so there's no reservation. But as it's Monday night, I'd >> > > > assume there's plenty of space. In case of last minute >> > > > changes, please check the page above. >> > > >> > > Not sure whether it will be as quiet as you hope: >> > > >> > > http://www.harrysbarsf.com/ >> > > >> > > There's apparently some championship game going on today. >> > >> > Just spoke withem on the phone, they'll just have some >> > basketball on tv. So let's meet there and if it's too loud >> > we can go somewhere else. >> >> Oops, Harry's bar is completely packed, let's meet at the >> bar next door to Haary's, it's called The Grove. > > So six people showed up last night for beers, we took few > photos of this historic event :) > > http://www.muru.com/linux/omap/events/ > > Cheers, > > Tony > > -- DongSoo, Nathaniel Kim Engineer Mobile S/W Platform Lab. Digital Media & Communications R&D 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: Embedded Linux Conference
Hello, I'm attending as a speaker for one session which title is "Digital camera framework in Linux" I'm also looking forward to see many v4l2 engineers and discuss about latest issues. BTW, see you there Hans :) Nate On Fri, Mar 6, 2009 at 1:49 AM, Hans Verkuil wrote: > 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. > > Regards, > > Hans > > -- > Hans Verkuil - video4linux developer - sponsored by TANDBERG > -- ======== DongSoo(Nathaniel), Kim Engineer Mobile S/W Platform Lab. S/W Team. DMC 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: [PATCH 4/5] OMAP3430SDP: Add support for Camera Kit v3
Hi Alexey, On Fri, Mar 6, 2009 at 7:05 AM, Alexey Klimov wrote: > Hello, all > > On Thu, Mar 5, 2009 at 7:42 PM, Curran, Dominic wrote: >> >> Hi Kim >> >>> -Original Message- >>> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- >>> ow...@vger.kernel.org] On Behalf Of DongSoo(Nathaniel) Kim >>> Sent: Wednesday, March 04, 2009 8:58 PM >>> To: Aguirre Rodriguez, Sergio Alberto >>> Cc: linux-me...@vger.kernel.org; linux-omap@vger.kernel.org; Sakari Ailus; >>> Tuukka.O Toivonen; Hiroshi DOYU; MiaoStanley; Nagalla, Hari; Hiremath, >>> Vaibhav; Lakhani, Amish; Menon, Nishanth >>> Subject: Re: [PATCH 4/5] OMAP3430SDP: Add support for Camera Kit v3 >>> >>> Hi Sergio, >>> >>> >>> >>> On Wed, Mar 4, 2009 at 5:44 AM, Aguirre Rodriguez, Sergio Alberto >>> wrote: >>> > + /* turn on analog power */ >>> > + twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER, >>> > + VAUX_2_8_V, TWL4030_VAUX2_DEDICATED); >>> > + twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER, >>> > + VAUX_DEV_GRP_P1, TWL4030_VAUX2_DEV_GRP); >>> > + >>> > + /* out of standby */ >>> > + gpio_set_value(MT9P012_STANDBY_GPIO, 0); >>> > + udelay(1000); >>> >>> It seems better using msleep rather than udelay for 1000us much. Just >>> to be safe :) >>> How about you? >>> >> >> Why is msleep safer than udelay ? > > I have small guess that he is wondering why you are using big delays > with help of udelay(). (It's may be obvious but as we know udelay uses > cpu loops to make delay and msleep calls to scheduler) So, msleep is > more flexible and "softer" but if you need precise time or you can't > sleep in code you need udelay. Sometimes using udelay is reasonably > required. I totally agree with you. But besides the "udelay and mdelay accuracy" issue, Sergio's power up timing for MT9P012 seems to delay too much. (not for lens controller.) I also have experience using MT9P012 sensor with other ISP, but in case of mine it took 600 to 800 ms for whole power up sequence. But if that delay depends on SDP board and Sergio had no options without making delay for that much, then it explains everything. So I'm saying if there was no other option than making long delay to bring up MT9P012 sensor properly, if I were Sergio I should rather use mdelay than udelay. But if that delay is necessary to bring up MT9P012 with SDP board, I have no idea what to say. In that case, Sergio should be right. Cheers, Nate > > -- > Best regards, Klimov Alexey > -- DongSoo(Nathaniel), Kim Engineer Mobile S/W Platform Lab. S/W Team. DMC 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: [RFC 0/9] OMAP3 ISP and camera drivers
Hi Sakari, Reviewing your driver, I couldn't find JPEG sync mode or where to make programme ISP_CTRL with ISPCTRL_JPEG_FLUSH. Is JPEG sync mode is not the coverage of this version? or I'm missing something. If JPEG sync mode is not considered yet please let me know. Cheers, Nate On Tue, Mar 3, 2009 at 7:06 PM, Sakari Ailus wrote: > Hi, > > So here's the patchset for OMAP 3 ISP and camera drivers plus the > associated V4L changes. Sergio Aguirre has been posting a related > patchset earlier, containing also sensor and lens driver used on SDP. This > patchset is agains the linux-omap tree: > > http://www.muru.com/linux/omap/README_OMAP_GIT> > > So I and Sergio have synchronised our versions of the ISP and camera > drivers and this is the end result. There is still a lot of work to do, > though. You can find some comments in individual patch descriptions. If the > todo list for a patch is empty it doesn't mean there wouldn't be anything > left to do. ;) > > There's at least one major change to Sergio Aguirre's earlier patches which > is that the ISP driver now uses the IOMMU from Hiroshi Doyu. Hiroshi is away > for some time now so there are just some hacks on top of Hiroshi's older > iommu patches to use with current linux-omap. > > This patchset does not contain the resizer or preview wrappers from TI but > they have been left intentionally out. A proper interface (V4L) should be > used for those and the camera driver should be somehow involved --- the > wrappers are just duplicating much of the camera driver's functionality. > > I don't have any sensor or lens drivers to publish at this time. > > This patchset should work with the SDP and OMAPZoom boards although you > need the associated sensor drivers + the board code from Sergio Aguirre to > use it. You'll also need the IOMMU patchset from Hiroshi Doyu. Everything > except the sensor / board stuff is available here: > > http://www.gitorious.org/projects/omap3camera> > > In short, on linux-omap: > > $ git pull http://git.gitorious.org/omap3camera/mainline.git v4l \ > iommu omap3camera base > > Hiroshi's original iommu tree is here (branch iommu): > > http://git.gitorious.org/lk/mainline.git> > > Some of the camera and ISP driver development history is available, too. See > the first link. > > Any feedback is appreciated. > > Sincerely, > > -- > Sakari Ailus > sakari.ai...@maxwell.research.nokia.com > > -- DongSoo(Nathaniel), Kim Engineer Mobile S/W Platform Lab. S/W Team. DMC 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: [RFC 0/9] OMAP3 ISP and camera drivers
Hi,
You are right. I checked with my JTAG debugger.
It crashes just exactly there because of the reason you issued.
Cheers,
Nate
On Thu, Mar 5, 2009 at 12:53 PM, Hiremath, Vaibhav wrote:
>
>
> Thanks,
> Vaibhav Hiremath
>
>> -Original Message-----
>> From: DongSoo(Nathaniel) Kim [mailto:dongsoo@gmail.com]
>> Sent: Thursday, March 05, 2009 5:41 AM
>> To: Sakari Ailus
>> Cc: Hiremath, Vaibhav; linux-me...@vger.kernel.org; linux-
>> o...@vger.kernel.org; Aguirre Rodriguez, Sergio Alberto; Toivonen
>> Tuukka Olli Artturi; Hiroshi DOYU
>> Subject: Re: [RFC 0/9] OMAP3 ISP and camera drivers
>>
>> Hi Sakari,
>>
>> I'm also facing same issue with Hiremath.
>>
>> Here you are my kernel stack dump.
>>
> [Hiremath, Vaibhav] I was getting same kernel crash, The reason is -
>
> Since isp_probe doesn't get called, leaving omap3isp = NULL. So isp_get will
> return -EBUSY from the very beginning of function. And the function
> "omap34xxcam_device_register" which calls isp_get tries to access
> vdev->vfd->dev where it crashes. Which is completely wrong, since the vfd
> gets initialize later part of function
>
>
> if (hwc.dev_type == OMAP34XXCAM_SLAVE_SENSOR) {
> rval = isp_get();
> if (rval < 0) {
> dev_err(&vdev->vfd->dev, "can't get ISP, sensor init
> failed\n");
> [Vaibhav] - Here it crashes.
> goto err;
> }
> }
>
> There are some instances where vdev->vfd is being accessed before
> initializing.
>
>> Cheers,
>>
>> Nate
>>
>> [ 6.465606] [] (dev_driver_string+0x0/0x44) from
>> [] (omap34xxcam_device_register+0x110/0x2f8)
>> [ 6.475952] [] (omap34xxcam_device_register+0x0/0x2f8)
>> from [] (__v4l2_int_device_try_attach_all+0xb0/0x108)
>> [ 6.487609] r7: r6:c03e4fcc r5:cfbbf834 r4:c03e4f94
>> [ 6.493347] []
>> (__v4l2_int_device_try_attach_all+0x0/0x108) from []
>> (v4l2_int_device_register+0x60/0x7c)
>> [ 6.504638] r7:c03e4eec r6:cf9e5020 r5:c03e4f94 r4:c03e03f8
>> [ 6.510375] [] (v4l2_int_device_register+0x0/0x7c) from
>> [] (ce131f_probe+0x88/0xa8)
>> [ 6.519836] r5: r4:cf9e5000
>> [ 6.523437] [] (ce131f_probe+0x0/0xa8) from
>> []
>> (i2c_device_probe+0x78/0x90)
>> [ 6.532226] r5:cf9e5000 r4:c001825c
>> [ 6.535827] [] (i2c_device_probe+0x0/0x90) from
>> [] (driver_probe_device+0xd4/0x180)
>> [ 6.545318] r7:c03e4eec r6:c03e4eec r5:cf9e50a8 r4:cf9e5020
>> [ 6.551025] [] (driver_probe_device+0x0/0x180) from
>> [] (__driver_attach+0x68/0x8c)
>> [ 6.560394] r7:c03e4eec r6:c03e4eec r5:cf9e50a8 r4:cf9e5020
>> [ 6.566131] [] (__driver_attach+0x0/0x8c) from
>> [] (bus_for_each_dev+0x4c/0x84)
>> [ 6.575164] r7:c03e4eec r6:c01a16e0 r5:cf821cc8 r4:
>> [ 6.580871] [] (bus_for_each_dev+0x0/0x84) from
>> [] (driver_attach+0x20/0x28)
>> [ 6.589721] r7:cfb121a0 r6:c0018224 r5:c03e4eec r4:
>> [ 6.595458] [] (driver_attach+0x0/0x28) from
>> []
>> (bus_add_driver+0xa8/0x214)
>> [ 6.604217] [] (bus_add_driver+0x0/0x214) from
>> [] (driver_register+0x98/0x120)
>> [ 6.613250] r8: r7:c03ef760 r6:c0018224 r5:c03e4eec
>> r4:c03e4ec0
>> [ 6.620025] [] (driver_register+0x0/0x120) from
>> [] (i2c_register_driver+0x98/0xfc)
>> [ 6.629425] [] (i2c_register_driver+0x0/0xfc) from
>> [] (ce131f_isp_init+0x18/0x38)
>> [ 6.638702] r7:c03ef760 r6:c0018224 r5:c0022d78 r4:c0023128
>> [ 6.644439] [] (ce131f_isp_init+0x0/0x38) from
>> [] (do_one_initcall+0x78/0x1d8)
>> [ 6.653472] r5:c0022d78 r4:c0023128
>> [ 6.657073] [] (do_one_initcall+0x0/0x1d8) from
>> [] (kernel_init+0x74/0xe0)
>> [ 6.665740] r8: r7: r6: r5:c0022d78
>> r4:c0023128
>> [ 6.672515] [] (kernel_init+0x0/0xe0) from []
>> (do_exit+0x0/0x684)
>> [ 6.680419] r5: r4:
>> [ 6.684020] Code: c036e993 e1a0c00d e92dd800 e24cb004 (e5903098)
>> [ 6.690246] ---[ end trace cc13b15a4191e849 ]---
>> [ 6.694915] Kernel panic - not syncing: Attempted to kill init!
>>
>> On Thu, Mar 5, 2009 at 12:38 AM, Sakari Ailus
>> wrote:
>> > Hiremath, Vaibhav wrote:
>> >>
>> >> [Hiremath, Vaibhav] Sakari, Let me ask you basic question, have
>> you
>> >> tested/verified these patch-sets?
>> >
>> > For the ISP and camera drivers, yes. That's actually the only
>> thing that's
>> > contain
Re: [PATCH 4/5] OMAP3430SDP: Add support for Camera Kit v3
2_DEV_GRP);
> +#endif
> + enable_fpga_vio_1v8(0);
> + iounmap(fpga_map_addr);
> + break;
> + case V4L2_POWER_STANDBY:
> + break;
> + }
> + previous_power = power;
> + return 0;
> +}
> +
> +static u32 ov3640_sensor_set_xclk(u32 xclkfreq)
> +{
> + return isp_set_xclk(xclkfreq, CAMKITV3_USE_XCLKB);
> +}
> +
> +struct ov3640_platform_data sdp3430_ov3640_platform_data = {
> + .power_set = ov3640_sensor_power_set,
> + .priv_data_set = ov3640_sensor_set_prv_data,
> + .set_xclk= ov3640_sensor_set_xclk,
> +};
> +
> +#endif
> +
> +void __init sdp3430_cam_init(void)
> +{
> + cam_inited = 0;
> + /* Request and configure gpio pins */
> + if (gpio_request(CAMKITV3_RESET_GPIO, "camkitv3_reset_gpio") != 0) {
> + printk(KERN_ERR "Could not request GPIO %d",
> + CAMKITV3_RESET_GPIO);
> + return;
> + }
> +
> + if (gpio_request(OV3640_STANDBY_GPIO, "ov3640_standby_gpio") != 0) {
> + printk(KERN_ERR "Could not request GPIO %d",
> + OV3640_STANDBY_GPIO);
> + return;
> + }
> +
> + if (gpio_request(MT9P012_STANDBY_GPIO, "mt9p012_standby_gpio")) {
> + printk(KERN_ERR "Could not request GPIO %d for MT9P012\n",
> + MT9P012_STANDBY_GPIO);
> + return;
> + }
> +
> + /* set to output mode */
> + gpio_direction_output(CAMKITV3_RESET_GPIO, true);
> + gpio_direction_output(OV3640_STANDBY_GPIO, true);
> + gpio_direction_output(MT9P012_STANDBY_GPIO, true);
> +
> + cam_inited = 1;
> +}
> +#else
> +void __init sdp3430_cam_init(void)
> +{
> +}
> +#endif
> diff --git a/arch/arm/mach-omap2/board-3430sdp.c
> b/arch/arm/mach-omap2/board-3430sdp.c
> index 867f5f6..986f087 100644
> --- a/arch/arm/mach-omap2/board-3430sdp.c
> +++ b/arch/arm/mach-omap2/board-3430sdp.c
> @@ -40,6 +40,23 @@
> #include
> #include
>
> +#include
> +
> +#if defined(CONFIG_VIDEO_MT9P012) || defined(CONFIG_VIDEO_MT9P012_MODULE)
> +#include
> +extern struct mt9p012_platform_data sdp3430_mt9p012_platform_data;
> +#endif
> +
> +#if defined(CONFIG_VIDEO_OV3640) || defined(CONFIG_VIDEO_OV3640_MODULE)
> +#include
> +extern struct ov3640_platform_data sdp3430_ov3640_platform_data;
> +#endif
> +
> +#ifdef CONFIG_VIDEO_DW9710
> +#include
> +extern struct dw9710_platform_data sdp3430_dw9710_platform_data;
> +#endif
> +
> #include
>
> #include "sdram-qimonda-hyb18m512160af-6.h"
> @@ -610,13 +627,35 @@ static struct i2c_board_info __initdata
> sdp3430_i2c_boardinfo[] = {
>},
> };
>
> +static struct i2c_board_info __initdata sdp3430_i2c_boardinfo_2[] = {
> +#if defined(CONFIG_VIDEO_MT9P012) || defined(CONFIG_VIDEO_MT9P012_MODULE)
> + {
> + I2C_BOARD_INFO("mt9p012", MT9P012_I2C_ADDR),
> + .platform_data = &sdp3430_mt9p012_platform_data,
> + },
> +#ifdef CONFIG_VIDEO_DW9710
> + {
> + I2C_BOARD_INFO("dw9710", DW9710_AF_I2C_ADDR),
> + .platform_data = &sdp3430_dw9710_platform_data,
> + },
> +#endif
> +#endif
> +#if defined(CONFIG_VIDEO_OV3640) || defined(CONFIG_VIDEO_OV3640_MODULE)
> + {
> + I2C_BOARD_INFO("ov3640", OV3640_I2C_ADDR),
> + .platform_data = &sdp3430_ov3640_platform_data,
> + },
> +#endif
> +};
> +
> static int __init omap3430_i2c_init(void)
> {
>/* i2c1 for PMIC only */
>omap_register_i2c_bus(1, 2600, sdp3430_i2c_boardinfo,
>ARRAY_SIZE(sdp3430_i2c_boardinfo));
>/* i2c2 on camera connector (for sensor control) and optional isp1301
> */
> - omap_register_i2c_bus(2, 400, NULL, 0);
> + omap_register_i2c_bus(2, 400, sdp3430_i2c_boardinfo_2,
> + ARRAY_SIZE(sdp3430_i2c_boardinfo_2));
>/* i2c3 on display connector (for DVI, tfp410) */
>omap_register_i2c_bus(3, 400, NULL, 0);
>return 0;
> @@ -641,6 +680,7 @@ static void __init omap_3430sdp_init(void)
>omap_serial_init();
>usb_musb_init();
>usb_ehci_init();
> + sdp3430_cam_init();
> }
>
> static void __init omap_3430sdp_map_io(void)
> diff --git a/arch/arm/plat-omap/include/mach/board-3430sdp.h
> b/arch/arm/plat-omap/include/mach/board-3430sdp.h
> index 67d3f78..2ddb3e5 100644
> --- a/arch/arm/plat-omap/include/mach/board-3430sdp.h
> +++ b/arch/arm/plat-omap/include/mach/board-3430sdp.h
> @@ -32,6 +32,7 @@
> extern void sdp3430_usb_init(void);
> extern void sdp3430_flash_init(void);
> extern void twl4030_bci_battery_init(void);
> +extern void sdp3430_cam_init(void);
>
> #define DEBUG_BASE 0x0800 /* debug board */
>
> --
> 1.5.6.5
>
>
--
DongSoo(Nathaniel), Kim
Engineer
Mobile S/W Platform Team.
DMC
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: [RFC 0/9] OMAP3 ISP and camera drivers
Hi Sakari, I'm also facing same issue with Hiremath. Here you are my kernel stack dump. Cheers, Nate [6.465606] [] (dev_driver_string+0x0/0x44) from [] (omap34xxcam_device_register+0x110/0x2f8) [6.475952] [] (omap34xxcam_device_register+0x0/0x2f8) from [] (__v4l2_int_device_try_attach_all+0xb0/0x108) [6.487609] r7: r6:c03e4fcc r5:cfbbf834 r4:c03e4f94 [6.493347] [] (__v4l2_int_device_try_attach_all+0x0/0x108) from [] (v4l2_int_device_register+0x60/0x7c) [6.504638] r7:c03e4eec r6:cf9e5020 r5:c03e4f94 r4:c03e03f8 [6.510375] [] (v4l2_int_device_register+0x0/0x7c) from [] (ce131f_probe+0x88/0xa8) [6.519836] r5: r4:cf9e5000 [6.523437] [] (ce131f_probe+0x0/0xa8) from [] (i2c_device_probe+0x78/0x90) [6.532226] r5:cf9e5000 r4:c001825c [6.535827] [] (i2c_device_probe+0x0/0x90) from [] (driver_probe_device+0xd4/0x180) [6.545318] r7:c03e4eec r6:c03e4eec r5:cf9e50a8 r4:cf9e5020 [6.551025] [] (driver_probe_device+0x0/0x180) from [] (__driver_attach+0x68/0x8c) [6.560394] r7:c03e4eec r6:c03e4eec r5:cf9e50a8 r4:cf9e5020 [6.566131] [] (__driver_attach+0x0/0x8c) from [] (bus_for_each_dev+0x4c/0x84) [6.575164] r7:c03e4eec r6:c01a16e0 r5:cf821cc8 r4: [6.580871] [] (bus_for_each_dev+0x0/0x84) from [] (driver_attach+0x20/0x28) [6.589721] r7:cfb121a0 r6:c0018224 r5:c03e4eec r4: [6.595458] [] (driver_attach+0x0/0x28) from [] (bus_add_driver+0xa8/0x214) [6.604217] [] (bus_add_driver+0x0/0x214) from [] (driver_register+0x98/0x120) [6.613250] r8: r7:c03ef760 r6:c0018224 r5:c03e4eec r4:c03e4ec0 [6.620025] [] (driver_register+0x0/0x120) from [] (i2c_register_driver+0x98/0xfc) [6.629425] [] (i2c_register_driver+0x0/0xfc) from [] (ce131f_isp_init+0x18/0x38) [6.638702] r7:c03ef760 r6:c0018224 r5:c0022d78 r4:c0023128 [6.644439] [] (ce131f_isp_init+0x0/0x38) from [] (do_one_initcall+0x78/0x1d8) [6.653472] r5:c0022d78 r4:c0023128 [6.657073] [] (do_one_initcall+0x0/0x1d8) from [] (kernel_init+0x74/0xe0) [6.665740] r8: r7: r6: r5:c0022d78 r4:c0023128 [6.672515] [] (kernel_init+0x0/0xe0) from [] (do_exit+0x0/0x684) [6.680419] r5: r4: [6.684020] Code: c036e993 e1a0c00d e92dd800 e24cb004 (e5903098) [6.690246] ---[ end trace cc13b15a4191e849 ]--- [6.694915] Kernel panic - not syncing: Attempted to kill init! On Thu, Mar 5, 2009 at 12:38 AM, Sakari Ailus wrote: > Hiremath, Vaibhav wrote: >> >> [Hiremath, Vaibhav] Sakari, Let me ask you basic question, have you >> tested/verified these patch-sets? > > For the ISP and camera drivers, yes. That's actually the only thing that's > contained in the patchset. > >> The reason I am asking this question is, for me it was not working. I >> had to debug this and found that - >> >> - Changes missing in devices.c file, so isp_probe function will not >> be called at all, keeping omap3isp = NULL. You will end up into >> kernel crash in omap34xxcam_device_register. > > Anyway a crash shouldn't happen here. Could I see the kernel oops if there > was such? > >> - The patches from Hiroshi DOYU doesn't build as is, you need to add >> one include line #include in iovmmu.c (I am using >> the patches submitted on 16th Jan 2009) > > Just pull the iommu branch, the Hiroshi's original patches are missing some > hacks that you need to use them now. I'd expect Hiroshi to update the > patchset when he comes back. > >> I have attached "git diff" output here with this mail for reference. > > Please pull also the "base" branch. > > -- > Sakari Ailus > sakari.ai...@maxwell.research.nokia.com > -- DongSoo(Nathaniel), Kim Engineer Mobile S/W Platform Lab. S/W centre Telecommunication R&D 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
Thank you for your kind explanation Hans. Problem is omap3 camera subsystem is making device node for every int device attached to it. Before I have been using v4l2 int device, I implemented S_INPUT/G_INPUT/ENUMINPUT by my own for other CPUs like S3C64XX (just for demo..not opened on public domain yet) In that case, I considered camera interface as a capture device, and every camera devices as input devices for capture device. So using enuminput I could query how many devices do I have for input, and even camera device's name could be get. I made only one device node for camera interface because it was exactly camera interface that I open, not camera module attached on it. Furthermore, CPU's camera video processing H/W cannot process data from multiple cameras at the same time. So no need to make device node for every single camera module attached on it. For these kinds of reason, I think also omap3 camera subsystem should make only one device node for the same category of int device(or subdev for now?). I mean single device node for sensors, single device node for lens controllers, single device node for strobes. I hope I made myself clear. Honestly it is quite hard to explain (even in my language) Cheers, Nate On Tue, Mar 3, 2009 at 4:36 PM, Hans Verkuil wrote: > On Tuesday 03 March 2009 06:13:11 DongSoo(Nathaniel) Kim wrote: >> Thank you for your reply. >> >> This is quite confusing because in case of mine, I wanna make >> switchable between different cameras attached to omap camera >> interface. >> Which idea do I have to follow? Comparing with multiple video input >> devices and multiple cameras attached to single camera interface is >> giving me no answer. >> >> Perhaps multiple cameras with single camera interface couldn't make >> sense at the first place because single camera interface can go with >> only one camera module at one time. >> But we are using like that. I mean dual cameras with single camera >> interface. There is no choice except that when we are using dual >> camera without stereo camera controller. > > If you have multiple inputs (cameras in this case) that the user can choose > from, then you need to implement S_INPUT/G_INPUT/ENUMINPUTS. That's what > they are there for. Any decent V4L2 app should support these ioctls. > >> By the way, I cannot find any API documents about >> VIDIOC_INT_S_VIDEO_ROUTING but it seems to be all about "how to route >> between input device with output device". > > The description of this internal ioctl is in v4l2-common.h. It is used to > tell the i2c module how it is hooked up to the rest of the system. I.e. > what pin(s) is used for the input signal and what pin(s) is used for the > output signal. > > Typically the main v4l2 driver will map a user-level input (as set with > VIDIOC_S_INPUT) to the low-level routing information and pass that on to > the i2c device using VIDIOC_INT_S_VIDEO_ROUTING. > > Regards, > > Hans > >> What exactly I need is "how to make switchable with multiple camera as >> an input for camera interface", which means just about an input >> device. In my opinion, those are different issues each other..(Am I >> right?) >> Cheers, >> >> Nate >> >> On Tue, Mar 3, 2009 at 12:53 PM, Hiremath, Vaibhav > wrote: >> > Thanks, >> > Vaibhav Hiremath >> > >> >> -Original Message- >> >> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- >> >> ow...@vger.kernel.org] On Behalf Of DongSoo(Nathaniel) Kim >> >> Sent: Tuesday, March 03, 2009 8:18 AM >> >> To: Tuukka.O Toivonen >> >> Cc: Aguirre Rodriguez, Sergio Alberto; linux-omap@vger.kernel.org; >> >> Ailus Sakari (Nokia-D/Helsinki); Nagalla, Hari >> >> Subject: Re: [REVIEW PATCH 11/14] OMAP34XXCAM: Add driver >> >> >> >> Hi Tuukka, >> >> >> >> I understand that it is a huge thing to support VIDIOC_S_INPUT. >> >> But without that, we don't have any proper "V4L2" api to get >> >> information about how many devices are attached to camera interface, >> >> and names of input devices...and so on. Because VIDIOC_ENUMINPUT and >> >> VIDIOC_G_INPUT needs VIDIOC_S_INPUT for prior. Of course we can >> >> refer >> >> to sysfs, but using only single set of APIs like V4L2 looks more >> >> decent. >> >> >> >> What do you think about this? >> >> If you think that it is a big burden, can I make a patch for this? >> >> Cheers, >> > >> > [Hiremath, Vaibhav] You may want to refer to the thre
Re: [REVIEW PATCH 11/14] OMAP34XXCAM: Add driver
Hello Sakari, Let me explain what I want to do. First of all, I need to make it clear that I'm not using bare sensors with omap3, but I'm using ISP included camera modules. To be more clear I can take a 3G handset for instance, which has dual cameras on it. Each camera has their own ISP on them, and they share omap3 camera data pins and clock/sync pins also. So, I need a API to switch between two of them because OMAP3 can't handle every data from each camera at once. To be honest, I definitely thought that VIDIOC_S_INPUT is the proper API for that ;( But now I'm quite confused. Regards, Nate On Tue, Mar 3, 2009 at 4:25 PM, Sakari Ailus wrote: > DongSoo(Nathaniel) Kim wrote: >> >> Hi Tuukka, >> >> I understand that it is a huge thing to support VIDIOC_S_INPUT. > > It might not be that much, in case it's supported by just one slave. > >> But without that, we don't have any proper "V4L2" api to get >> information about how many devices are attached to camera interface, >> and names of input devices...and so on. Because VIDIOC_ENUMINPUT and >> VIDIOC_G_INPUT needs VIDIOC_S_INPUT for prior. Of course we can refer >> to sysfs, but using only single set of APIs like V4L2 looks more >> decent. >> >> What do you think about this? >> If you think that it is a big burden, can I make a patch for this? > > I'm just wondering the purpose --- as Tuukka explained, the ISP block > doesn't make a camera, but a sensor essentially does. So for every sensor > there's a video device, even if they are implemented by using just one ISP. > How does this sound like? > > But for video decoders at least it's definitely meaningful to support > VIDIOC_S_INPUT. > > -- > Sakari Ailus > sakari.ai...@maxwell.research.nokia.com > -- DongSoo(Nathaniel), Kim Engineer Mobile S/W Platform Lab. S/W centre Telecommunication R&D 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
Thank you for your reply. This is quite confusing because in case of mine, I wanna make switchable between different cameras attached to omap camera interface. Which idea do I have to follow? Comparing with multiple video input devices and multiple cameras attached to single camera interface is giving me no answer. Perhaps multiple cameras with single camera interface couldn't make sense at the first place because single camera interface can go with only one camera module at one time. But we are using like that. I mean dual cameras with single camera interface. There is no choice except that when we are using dual camera without stereo camera controller. By the way, I cannot find any API documents about VIDIOC_INT_S_VIDEO_ROUTING but it seems to be all about "how to route between input device with output device". What exactly I need is "how to make switchable with multiple camera as an input for camera interface", which means just about an input device. In my opinion, those are different issues each other..(Am I right?) Cheers, Nate On Tue, Mar 3, 2009 at 12:53 PM, Hiremath, Vaibhav wrote: > > > Thanks, > Vaibhav Hiremath > >> -Original Message- >> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- >> ow...@vger.kernel.org] On Behalf Of DongSoo(Nathaniel) Kim >> Sent: Tuesday, March 03, 2009 8:18 AM >> To: Tuukka.O Toivonen >> Cc: Aguirre Rodriguez, Sergio Alberto; linux-omap@vger.kernel.org; >> Ailus Sakari (Nokia-D/Helsinki); Nagalla, Hari >> Subject: Re: [REVIEW PATCH 11/14] OMAP34XXCAM: Add driver >> >> Hi Tuukka, >> >> I understand that it is a huge thing to support VIDIOC_S_INPUT. >> But without that, we don't have any proper "V4L2" api to get >> information about how many devices are attached to camera interface, >> and names of input devices...and so on. Because VIDIOC_ENUMINPUT and >> VIDIOC_G_INPUT needs VIDIOC_S_INPUT for prior. Of course we can >> refer >> to sysfs, but using only single set of APIs like V4L2 looks more >> decent. >> >> What do you think about this? >> If you think that it is a big burden, can I make a patch for this? >> Cheers, >> > [Hiremath, Vaibhav] You may want to refer to the thread on this subject. > > http://marc.info/?l=linux-omap&m=122772175002777&w=2 > http://marc.info/?l=linux-omap&m=122823846806440&w=2 > >> Nate >> >> On Mon, Feb 23, 2009 at 5:50 PM, Tuukka.O Toivonen >> wrote: >> > On Monday 23 February 2009 10:08:54 ext DongSoo(Nathaniel) Kim >> wrote: >> >> So, logically it does not make sense with making device nodes of >> every >> >> single slave attached with OMAP3camera interface. Because they >> can't >> >> be opened at the same time,even if it is possible it should not >> work >> >> properly. >> >> >> >> So.. how about making only single device node like /dev/video0 >> for >> >> OMAP3 camera interface and make it switchable through V4L2 API. >> Like >> >> VIDIOC_S_INPUT? >> > >> > You are right that if the OMAP3 has several camera sensors >> attached >> > to its camera interface, generally just one can be used at once. >> > >> > However, from user's perspective those are still distinct >> > cameras. Many v4l2 applications don't support VIDIOC_S_INPUT >> > or at least it will be more difficult to use than just pointing >> > an app to the correct video device. Logically they are two >> > independent cameras, which can't be used simultaneously >> > due to HW restrictions. >> > >> > - Tuukka >> > >> >> >> >> -- >> ======== >> DongSoo(Nathaniel), Kim >> Engineer >> Mobile S/W Platform Lab. S/W centre >> Telecommunication R&D 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 > > -- DongSoo(Nathaniel), Kim Engineer Mobile S/W Platform Lab. S/W centre Telecommunication R&D 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
Hi Tuukka, I understand that it is a huge thing to support VIDIOC_S_INPUT. But without that, we don't have any proper "V4L2" api to get information about how many devices are attached to camera interface, and names of input devices...and so on. Because VIDIOC_ENUMINPUT and VIDIOC_G_INPUT needs VIDIOC_S_INPUT for prior. Of course we can refer to sysfs, but using only single set of APIs like V4L2 looks more decent. What do you think about this? If you think that it is a big burden, can I make a patch for this? Cheers, Nate On Mon, Feb 23, 2009 at 5:50 PM, Tuukka.O Toivonen wrote: > On Monday 23 February 2009 10:08:54 ext DongSoo(Nathaniel) Kim wrote: >> So, logically it does not make sense with making device nodes of every >> single slave attached with OMAP3camera interface. Because they can't >> be opened at the same time,even if it is possible it should not work >> properly. >> >> So.. how about making only single device node like /dev/video0 for >> OMAP3 camera interface and make it switchable through V4L2 API. Like >> VIDIOC_S_INPUT? > > You are right that if the OMAP3 has several camera sensors attached > to its camera interface, generally just one can be used at once. > > However, from user's perspective those are still distinct > cameras. Many v4l2 applications don't support VIDIOC_S_INPUT > or at least it will be more difficult to use than just pointing > an app to the correct video device. Logically they are two > independent cameras, which can't be used simultaneously > due to HW restrictions. > > - Tuukka > -- DongSoo(Nathaniel), Kim Engineer Mobile S/W Platform Lab. S/W centre Telecommunication R&D 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 09/14] OMAP: CAM: Add ISP Core
Hi.
Thank you for your reply.
I'm looking forward to see Sakari's new patch :)
Cheers,
Nate
On Tue, Mar 3, 2009 at 4:37 AM, Aguirre Rodriguez, Sergio Alberto
wrote:
> Hi Nate,
>
>> -Original Message-
>> From: DongSoo(Nathaniel) Kim [mailto:dongsoo@gmail.com]
>> Sent: Monday, March 02, 2009 2:10 AM
>> To: Aguirre Rodriguez, Sergio Alberto
>> Cc: linux-omap@vger.kernel.org; video4linux-l...@redhat.com; Nagalla,
>> Hari; Sakari Ailus; Tuukka.O Toivonen; linux-me...@vger.kernel.org
>> Subject: Re: [REVIEW PATCH 09/14] OMAP: CAM: Add ISP Core
>>
>> Hello,
>>
>> reviewing ISP driver, I found that we've got no querymenu support in
>> ISP and also omap3 camera interface driver.
>
> Sakari is about to repost our latest progress on this driver, and exactly one
> of the changes we did is added this support for querymenu on both camera and
> ISP drivers.
>
>>
>> +/**
>> + * struct vcontrol - Video control structure.
>> + * @qc: V4L2 Query control structure.
>> + * @current_value: Current value of the control.
>> + */
>> +static struct vcontrol {
>> + struct v4l2_queryctrl qc;
>> + int current_value;
>> +} video_control[] = {
>>
>>
>>
>> + {
>> + {
>> + .id = V4L2_CID_PRIVATE_ISP_COLOR_FX,
>> + .type = V4L2_CTRL_TYPE_INTEGER,
>> + .name = "Color Effects",
>> + .minimum = PREV_DEFAULT_COLOR,
>> + .maximum = PREV_BW_COLOR,
>> + .step = 1,
>> + .default_value = PREV_DEFAULT_COLOR,
>> + },
>> + .current_value = PREV_DEFAULT_COLOR,
>> + }
>> +};
>>
>> I think we should make it menu type for this color FX control.
>> If that kind of control has no menu information, user has no way to
>> figure out what kind of FX supported by device.
>> BTW if we make querymenu support in omap3 camera subsystem, we should
>> make querymenu support for v4l2 int device also.
>> I think I've seen before a patch which intent to use querymenu in v4l2
>> int device, but no patch for omap3 ISP and camera interface.
>> Can I make a patch and post on linux-omap, linux-media list? of course
>> if you don't mind.
>> Or...am I digging wrong way? I mean.. querymenu for omap3 camera subsystem.
>> Please let me know :)
>
> Please hold a bit, as we expect to repost the driver again this week.
>
> This control is now substituted by V4L2_CID_COLORFX, with seems to be already
> accepted for merging into v4l:
>
> http://osdir.com/ml/linux-media/2009-02/msg00593.html
>
> Anyways, thanks for your intended help on this. Expect new patches very soon.
>>
>> Cheers,
>>
>> Nate
>>
>> --
>>
>> DongSoo(Nathaniel), Kim
>> Engineer
>> Mobile S/W Platform Lab.
>> Telecommunication R&D Centre
>> Samsung Electronics CO., LTD.
>> e-mail : dongsoo@gmail.com
>> dongsoo45@samsung.com
>>
>
>
--
DongSoo(Nathaniel), Kim
Engineer
Mobile S/W Platform Lab. S/W centre
Telecommunication R&D 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 09/14] OMAP: CAM: Add ISP Core
Hello,
reviewing ISP driver, I found that we've got no querymenu support in
ISP and also omap3 camera interface driver.
+/**
+ * struct vcontrol - Video control structure.
+ * @qc: V4L2 Query control structure.
+ * @current_value: Current value of the control.
+ */
+static struct vcontrol {
+ struct v4l2_queryctrl qc;
+ int current_value;
+} video_control[] = {
+ {
+ {
+ .id = V4L2_CID_PRIVATE_ISP_COLOR_FX,
+ .type = V4L2_CTRL_TYPE_INTEGER,
+ .name = "Color Effects",
+ .minimum = PREV_DEFAULT_COLOR,
+ .maximum = PREV_BW_COLOR,
+ .step = 1,
+ .default_value = PREV_DEFAULT_COLOR,
+ },
+ .current_value = PREV_DEFAULT_COLOR,
+ }
+};
I think we should make it menu type for this color FX control.
If that kind of control has no menu information, user has no way to
figure out what kind of FX supported by device.
BTW if we make querymenu support in omap3 camera subsystem, we should
make querymenu support for v4l2 int device also.
I think I've seen before a patch which intent to use querymenu in v4l2
int device, but no patch for omap3 ISP and camera interface.
Can I make a patch and post on linux-omap, linux-media list? of course
if you don't mind.
Or...am I digging wrong way? I mean.. querymenu for omap3 camera subsystem.
Please let me know :)
Cheers,
Nate
--
============
DongSoo(Nathaniel), Kim
Engineer
Mobile S/W Platform Lab.
Telecommunication R&D 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
[OMAPZOOM][PATCH] CAM: Make PACK8 mode on CCDC work only with CCIR-656
Hello,
Besides the patch I've posted couple of hours ago, there is one more
thing in omap3 ispccdc.c.
According to omap3 datasheet, PACK8 could be enabled only when
CCDC_SYN_MODE is with CCIR-656 mode.
If you try to use external camera module with ITU-R.601 mode without
this patch, you could face weird data from your camera interface.
Please find following patch, and any comments will be welcomed.
Cheers,
Nate
>From 23425c97233c93f9b572351d8a93a13ae3cb3188 Mon Sep 17 00:00:00 2001
From: Dongsoo Kim
Date: Mon, 2 Mar 2009 11:01:14 +0900
Subject: [PATCH 2/2] CAM: Make PACK8 mode on CCDC work only with CCIR-656
Signed-off-by: Dongsoo Kim
---
drivers/media/video/isp/ispccdc.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/isp/ispccdc.c
b/drivers/media/video/isp/ispccdc.c
index 8f7e896..2945c6f 100644
--- a/drivers/media/video/isp/ispccdc.c
+++ b/drivers/media/video/isp/ispccdc.c
@@ -762,7 +762,8 @@ void ispccdc_config_sync_if(struct ispccdc_syncif syncif)
switch (syncif.datsz) {
case DAT8:
syn_mode |= ISPCCDC_SYN_MODE_DATSIZ_8;
- syn_mode |= ISPCCDC_SYN_MODE_PACK8; /* Added by MMS */
+ if (syncif.bt_r656_en)
+ syn_mode |= ISPCCDC_SYN_MODE_PACK8; /* Added by MMS */
break;
case DAT10:
syn_mode |= ISPCCDC_SYN_MODE_DATSIZ_10;
--
1.5.4.3
--
====
DongSoo(Nathaniel), Kim
Engineer
Mobile S/W Platform Lab. S/W centre
Telecommunication R&D 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
[OMAPZOOM][PATCH] CAM: Make omap3 camera interface driver more generic for external camera devices.
hwc->dev_type = OMAP34XXCAM_SLAVE_SENSOR;
diff --git a/drivers/media/video/omap34xxcam.c
b/drivers/media/video/omap34xxcam.c
index 43eeb1c..0cde1c6
--- a/drivers/media/video/omap34xxcam.c
+++ b/drivers/media/video/omap34xxcam.c
@@ -392,8 +392,9 @@ static int try_pix_parm(struct omap34xxcam_videodev *vdev,
best_ival->denominator = 0;
best_pix_in->width = 0;
- /* FIXME: this isn't good... */
- best_pix_in->pixelformat = V4L2_PIX_FMT_SGRBG10;
+
+ /* first try with default pixel format designated at sensor config */
+ best_pix_in->pixelformat = vdev->vdev_sensor_config.pixelformat;
best_pix_out.height = INT_MAX >> 1;
best_pix_out.width = best_pix_out.height;
diff --git a/drivers/media/video/omap34xxcam.h
b/drivers/media/video/omap34xxcam.h
index 86631b7..83d43a1
--- a/drivers/media/video/omap34xxcam.h
+++ b/drivers/media/video/omap34xxcam.h
@@ -71,6 +71,7 @@ struct omap34xxcam_hw_csi2 {
struct omap34xxcam_sensor_config {
int xclk;
int sensor_isp;
+ u32 pixelformat;
u32 capture_mem;
};
--
DongSoo(Nathaniel), Kim
Engineer
Mobile S/W Platform Lab. S/W centre
Telecommunication R&D 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: [RFC] How to pass camera Orientation to userspace
ort it. > > 5) Use some reserved bits from the v4l2_input structure (or possibly the > status word but that is normally only valid for current input) > Pros: Less overhead than controls. Could support multiple sensors in one > camera if such a beast exists. > Cons: Would require polling to support the case of a camera being turned > toward / away from the user while streaming. Can't easily identify drivers > that don't support it. > > The interest in detecting if a driver provides this informnation is to allow > libv4l to know when it should use the driver provided information and when it > should use its internal table (which needs to be retained for backward > compatibility). With no detection capability the driver provided info should > be ignored for USB IDs in the built in table. > > Thoughts please > > Adam Baker > -- > 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 > -- DongSoo(Nathaniel), Kim Engineer Mobile S/W Platform Lab. S/W centre Telecommunication R&D 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
Hi! Sakari. On Fri, Feb 13, 2009 at 7:02 PM, Sakari Ailus wrote: > DongSoo Kim wrote: >> >> 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 haven't verified it myself. Others might be using it. Some people using external ISP have informed me. Thank you. > >> I'm testing your patch on my own omap3 target board with NEC ISP...but >> unfortunately not working yet ;( > > NEC ISP? A sensor with NEC ISP integrated? Yep. CE131 exactly. > >> I should try more harder. more research is needed :) > > Thanks for the interest. :-) Thank you too :) I wish I could send you my work as a patch ASAP. Cheers, Nate > > -- > Sakari Ailus > sakari.ai...@maxwell.research.nokia.com > -- DongSoo(Nathaniel), Kim Engineer Mobile S/W Platform Lab. S/W centre Telecommunication R&D 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
Hi Arun.
I appreciate your helpful words!
For the meantime, I need a concrete driver for my camera module first
and I'm still working on it.
I wish I could post my work as a patch ASAP :)
Wish me luck!
Cheers,
Nate
On Fri, Feb 13, 2009 at 6:31 PM, Arun KS wrote:
> On Thu, Feb 12, 2009 at 1:22 PM, DongSoo Kim wrote:
>> 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?
>
> Hi DongSoo,
>
> The driver is tested and working with sensors which have
> inbuilt ISP modules.
>
> Thanks,
> Arun
>
>>
>> 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
>> wrote:
>>> DongSoo Kim wrote:
>>>>
>>>> Hello.
>>>
>>> Hi, and thanks for the comments!
>>>
>>>> +static int omap34xxcam_open(struct inode *inode, struct file *file)
>>>> +{
>>>>
>>>>
>>>>
>>>> + 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 R&D Centre
>> Samsung Electronics CO., LTD.
>> e-mail : dongsoo@gmail.com
>> dongsoo45@samsung.com
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-media" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
--
DongSoo(Nathaniel), Kim
Engineer
Mobile S/W Platform Lab. S/W centre
Telecommunication R&D 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
