Re: [PATCHv7 0/9] FM Transmitter (si4713) and another changes

2009-06-17 Thread Hans Verkuil
On Tuesday 16 June 2009 13:07:55 Eduardo Valentin wrote:
> On Tue, Jun 16, 2009 at 01:01:51PM +0200, ext Hans Verkuil wrote:
> > On Tuesday 16 June 2009 12:47:14 Eduardo Valentin wrote:
> > > Hi Hans,
> > >
> > > On Sun, Jun 14, 2009 at 01:37:20PM +0200, ext Hans Verkuil wrote:
> >
> > 
> >
> > > > I think the refactoring should be done first. I don't believe it is
> > > > that much work and experience shows that it is better to do this
> > > > right away while you are still motivated :-)
> > >
> > > hehehe.. Yes, that's what I was expecting :-). No problem. I've
> > > started it. I will resend the series once I've completed the
> > > re-factoring and I 've made some testing after that. I hope tomorrow
> > > or so.
> > >
> > > > The string control support should not go into 2.6.31. I would like
> > > > to do that only in the v4l-dvb tree (so it will appear in 2.6.32)
> > > > since I want to give that a bit more time to mature. I implemented
> > > > it very quickly and I do not feel comfortable queueing this for
> > > > 2.6.31.
> > >
> > > Right. Yes, better to test the stuff a bit more.
> > >
> > > > In addition it is still unclear if Mauro will merge my
> > > > v4l-dvb-subdev2 tree for 2.6.31. I hope so, since otherwise it will
> > > > hamper the development of this and other embedded platforms.
> > >
> > > Ok.
> > >
> > > > I also need to add a new V4L2_CAP_MODULATOR (which needs a review
> > > > as well).
> > > >
> > > > And finally I realized that we need to add some v4l2_modulator
> > > > capabilities for the RDS encoder similar to the upcoming v4l2_tuner
> > > > RDS capabilities as is described in this RFC:
> > > >
> > > > http://www.mail-archive.com/linux-media%40vger.kernel.org/msg02498.
> > > >html
> > > >
> > > > I haven't had time to implement this RFC and I know that is not
> > > > going to make 2.6.31. It's now almost at the top of my TODO list,
> > > > so it should go in soon (pending unforeseen circumstances).
> > >
> > > Ok. I'll take a look at it.
> >
> > I've worked on this yesterday. You can take a look at my v4l-dvb-rds
> > tree. Both the API and the documentation of it in the v4l2-spec is in
> > there. I started work on updating the few RDS decoders that we have,
> > but that is not yet in that tree.
> >
> > > > As a result of rereading this RFC I also started to wonder about
> > > > whether the si4713 supports the MMBS functionality. Do you know
> > > > anything about that?
> > >
> > > No. Not that I know. Can you point some link?
> >
> > http://www.rds.org.uk/rdsfrdsrbds.html
> >
> > But I've just read here:
> >
> > http://www.rds.org.uk/rds98/pdf/rdsForum_standards_090414_8.pdf
> >
> > that MMBS is discontinued. I'll need to investigate this further, but
> > if this is indeed true then this can be removed completely from our RDS
> > decoder and encoder APIs.
>
> Yes, better to double check. At least with si4713, I haven't heard
> anything about this.

MMBS does definitely not apply to this FM transmitter. In order to transmit 
MMBS you would need to have a license to do so since it seems to be a 
proprietary format.

I have not been able to confirm that it is indeed discontinued, but since it 
is a proprietary predecessor format of RDS it is very very likely indeed 
that this is true. I'm going to remove the MMBS support from my RDS API and 
I'll just add a note to the spec that if anyone needs this, then they 
should contact the list.

I am glad I found this in time before the final RDS decoding API is in the 
kernel.

Regards,

Hans

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom
--
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: [DaVinci] patches for linux-media

2009-06-17 Thread Hans Verkuil
On Wednesday 17 June 2009 23:01:21 Karicheri, Muralidharan wrote:
> Hi Hans & Mauro,
>
> The v3 version of the DaVici VPFE Capture driver and TVP514x driver has
> been sent to the list for review. I expect this to sail through with out
> any comments as I have addressed few minor comments from last review. I
> think Hans will send you the pull request for these patches. Once again,
> it will be great if this can be merged to 2.6.31.

I'll prepare a pull request for this tomorrow.

Regards,

Hans

>
> Murali Karicheri
> m-kariche...@ti.com
>
> >I have proposed this before, but I'll do it again: I'm more than happy
> > to be
> >the official person who collects and organizes the omap and davinci
> > patches for you and who does the initial reviews. This is effectively
> > already the case since I've been reviewing both omap and davinci
> > patches pretty much from the beginning.
> >
> >Both the omap2/3 display driver and the davinci drivers are now very
> > close to be ready for inclusion in the kernel as my last reviews only
> > found some minor things.
> >
> >Part of the reason for the delays for both omap and davinci was that
> > they had to be modified for v4l2_subdev, which was an absolute
> > necessity, and because they simply needed quite a bit of work to make
> > them suitable for inclusion in the kernel.
> >
> >Regards,
> >
> > Hans
> >
> >--
> >Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom



-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [Patch] New utility program atsc_epg added to dvb-apps utility suite.

2009-06-17 Thread hermann pitton

Am Mittwoch, den 17.06.2009, 20:12 -0500 schrieb Yufei Yuan:
> Okay, you win. Apology to others in the list who have to endure the
> garbage talk.
> 
> Regards,
> Yufei Yuan

Sorry for abusing you for a ride out on mail footers.

Best,
Hermann

> 
> On Wed, Jun 17, 2009 at 8:05 PM, hermann pitton 
> wrote:
> > Am Mittwoch, den 17.06.2009, 19:46 -0500 schrieb Yufei Yuan:
> >> Age would cure neither naivety nor stupidity. I would imagine only a
> >> self-important white supremacist would utter such comments in public
> >> against a total stranger. If you can read the Chinese above, I
> >> *seriously* doubt that, it's what Confucious said around 500BC, to
> >> encourage learning and repentance.
> >
> > That was of course totally clear and exactly that is the annoyance !
> >
> >>
> >> I may not do a good job in translation, sorry about that. But blindly
> >> interpret other's intention based on one's own narrow personal
> >> experience, or cultural context, is the origin of the trouble between
> >> groups and nations, in this case, two individuals.
> >
> > OK, let's keep the footers uncensored ;)
> >
> >> Regards,
> >>
> >> On Wed, Jun 17, 2009 at 7:30 PM, hermann pitton 
> >> wrote:
> >> >
> >> > Am Mittwoch, den 17.06.2009, 19:20 -0500 schrieb Yufei Yuan:
> >> >> If you take such an intolerant attitude against what others opinion
> >> >> might be, your words might just be deemed worthless, or should I say
> >> >> *bullshit*, by others. It is really sad that this world is never in
> >> >> shortage of people like you.
> >> >>
> >> >> What a shame of humanity.
> >> >>
> >> >> Regards,
> >> >
> >> > I'm a German born in 1957.
> >> >
> >> > If that could help you any further in the future not to claim to have
> >> > the three golden rules ...
> >> >
> >> > Cheers,
> >> > Hermann
> >> >
> >> >>
> >> >> On Wed, Jun 17, 2009 at 7:14 PM, hermann 
> >> >> pitton wrote:
> >> >> > Hi,
> >> >> >
> >> >> > Am Mittwoch, den 17.06.2009, 19:06 -0500 schrieb Yufei Yuan:
> >> >> >> Sorry I guess this is about the way the patch was generated? Or about
> >> >> >> the utility itself?
> >> >> >>
> >> >> >> Regards,
> >> >> >
> >> >> > most likely.
> >> >> >
> >> >> > And that is what I exactly do mean.
> >> >> >
> >> >> > Obviously you don't have any control about the footers others provide
> >> >> > for you, if you go shopping ;)
> >> >> >
> >> >> > --
> >> >> > 好学近乎智,力行近乎仁,知耻近乎勇。
> >> >> > Eagerness in learning is close to intelligence.
> >> >> > Commitment in doing is close to nobleness.
> >> >> > Realization of shamefulness is close to courageousness.
> >> >> >
> >> >> > :)
> >> >> >
> >> >> > what a bullshit.
> >> >> >
> >> >> > Cheers,
> >> >> > Hermann
> >> >> >
> >> >> >>
> >> >> >> On Wed, Jun 17, 2009 at 6:51 PM, hermann 
> >> >> >> pitton wrote:
> >> >> >> >
> >> >> >> > Am Mittwoch, den 17.06.2009, 18:18 -0500 schrieb Yufei Yuan:
> >> >> >> >> Hi,
> >> >> >> >>
> >> >> >> >> I am not sure if this is the correct mailing list to send this 
> >> >> >> >> patch.
> >> >> >> >> >From the LinuxTV website, it seems that currently dvb-apps 
> >> >> >> >> >project
> >> >> >> >> has
> >> >> >> >> no owner.
> >> >> >> >>
> >> >> >> >> A new utility atsc_epg is added into the dvb-apps utility suite. 
> >> >> >> >> It
> >> >> >> >> parses PSIP information carried in OTA ATSC channels, and 
> >> >> >> >> constructs a
> >> >> >> >> basic EPG in a terminal window. Changes were also made to files to
> >> >> >> >> please GCC4.4.
> >> >> >> >>
> >> >> >> >> The patch is against latest revision 1278 from the dvb-apps
> >> >> >> >> repository.
> >> >> >> >>
> >> >> >> >> Regards,
> >> >> >> >> Yufei Yuan
> >> >> >> >>
> >> >> >> >> --
> >> >> >> >> 好学近乎智,力行近乎仁,知耻近乎勇。
> >> >> >> >> Eagerness in learning is close to intelligence.
> >> >> >> >> Commitment in doing is close to nobleness.
> >> >> >> >> Realization of shamefulness is close to courageousness.
> >> >> >> >
> >> >> >> > Getting engaged into footers ...
> >> >> >> >
> >> >> >> > The above blindly assumes that there is a balance within that 
> >> >> >> > reduction
> >> >> >> > to three cases ... (we know two are enough)
> >> >> >> >
> >> >> >> > You miss at least several hundred years of history on the other 
> >> >> >> > side of
> >> >> >> > the planet.
> >> >> >> >
> >> >> >> > I totally disagree with that kind of stuff.
> >> >> >> >
> >> >> >> > Most explicitly with the third variant.
> >> >> >> >
> >> >> >> > That way you can still press any slave into any army ...
> >> >> >> >
> >> >
> >> >
> >> >
> >>
> >>
> >>
> >
> >
> 
> 
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [Patch] New utility program atsc_epg added to dvb-apps utility suite.

2009-06-17 Thread Yufei Yuan
Okay, you win. Apology to others in the list who have to endure the
garbage talk.

Regards,
Yufei Yuan

On Wed, Jun 17, 2009 at 8:05 PM, hermann pitton wrote:
> Am Mittwoch, den 17.06.2009, 19:46 -0500 schrieb Yufei Yuan:
>> Age would cure neither naivety nor stupidity. I would imagine only a
>> self-important white supremacist would utter such comments in public
>> against a total stranger. If you can read the Chinese above, I
>> *seriously* doubt that, it's what Confucious said around 500BC, to
>> encourage learning and repentance.
>
> That was of course totally clear and exactly that is the annoyance !
>
>>
>> I may not do a good job in translation, sorry about that. But blindly
>> interpret other's intention based on one's own narrow personal
>> experience, or cultural context, is the origin of the trouble between
>> groups and nations, in this case, two individuals.
>
> OK, let's keep the footers uncensored ;)
>
>> Regards,
>>
>> On Wed, Jun 17, 2009 at 7:30 PM, hermann pitton 
>> wrote:
>> >
>> > Am Mittwoch, den 17.06.2009, 19:20 -0500 schrieb Yufei Yuan:
>> >> If you take such an intolerant attitude against what others opinion
>> >> might be, your words might just be deemed worthless, or should I say
>> >> *bullshit*, by others. It is really sad that this world is never in
>> >> shortage of people like you.
>> >>
>> >> What a shame of humanity.
>> >>
>> >> Regards,
>> >
>> > I'm a German born in 1957.
>> >
>> > If that could help you any further in the future not to claim to have
>> > the three golden rules ...
>> >
>> > Cheers,
>> > Hermann
>> >
>> >>
>> >> On Wed, Jun 17, 2009 at 7:14 PM, hermann pitton 
>> >> wrote:
>> >> > Hi,
>> >> >
>> >> > Am Mittwoch, den 17.06.2009, 19:06 -0500 schrieb Yufei Yuan:
>> >> >> Sorry I guess this is about the way the patch was generated? Or about
>> >> >> the utility itself?
>> >> >>
>> >> >> Regards,
>> >> >
>> >> > most likely.
>> >> >
>> >> > And that is what I exactly do mean.
>> >> >
>> >> > Obviously you don't have any control about the footers others provide
>> >> > for you, if you go shopping ;)
>> >> >
>> >> > --
>> >> > 好学近乎智,力行近乎仁,知耻近乎勇。
>> >> > Eagerness in learning is close to intelligence.
>> >> > Commitment in doing is close to nobleness.
>> >> > Realization of shamefulness is close to courageousness.
>> >> >
>> >> > :)
>> >> >
>> >> > what a bullshit.
>> >> >
>> >> > Cheers,
>> >> > Hermann
>> >> >
>> >> >>
>> >> >> On Wed, Jun 17, 2009 at 6:51 PM, hermann 
>> >> >> pitton wrote:
>> >> >> >
>> >> >> > Am Mittwoch, den 17.06.2009, 18:18 -0500 schrieb Yufei Yuan:
>> >> >> >> Hi,
>> >> >> >>
>> >> >> >> I am not sure if this is the correct mailing list to send this 
>> >> >> >> patch.
>> >> >> >> >From the LinuxTV website, it seems that currently dvb-apps project
>> >> >> >> has
>> >> >> >> no owner.
>> >> >> >>
>> >> >> >> A new utility atsc_epg is added into the dvb-apps utility suite. It
>> >> >> >> parses PSIP information carried in OTA ATSC channels, and 
>> >> >> >> constructs a
>> >> >> >> basic EPG in a terminal window. Changes were also made to files to
>> >> >> >> please GCC4.4.
>> >> >> >>
>> >> >> >> The patch is against latest revision 1278 from the dvb-apps
>> >> >> >> repository.
>> >> >> >>
>> >> >> >> Regards,
>> >> >> >> Yufei Yuan
>> >> >> >>
>> >> >> >> --
>> >> >> >> 好学近乎智,力行近乎仁,知耻近乎勇。
>> >> >> >> Eagerness in learning is close to intelligence.
>> >> >> >> Commitment in doing is close to nobleness.
>> >> >> >> Realization of shamefulness is close to courageousness.
>> >> >> >
>> >> >> > Getting engaged into footers ...
>> >> >> >
>> >> >> > The above blindly assumes that there is a balance within that 
>> >> >> > reduction
>> >> >> > to three cases ... (we know two are enough)
>> >> >> >
>> >> >> > You miss at least several hundred years of history on the other side 
>> >> >> > of
>> >> >> > the planet.
>> >> >> >
>> >> >> > I totally disagree with that kind of stuff.
>> >> >> >
>> >> >> > Most explicitly with the third variant.
>> >> >> >
>> >> >> > That way you can still press any slave into any army ...
>> >> >> >
>> >
>> >
>> >
>>
>>
>>
>
>



-- 
好学近乎智,力行近乎仁,知耻近乎勇。
Eagerness in learning is close to intelligence.
Commitment in doing is close to nobleness.
Realization of shamefulness is close to courageousness.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [Patch] New utility program atsc_epg added to dvb-apps utility suite.

2009-06-17 Thread hermann pitton
Am Mittwoch, den 17.06.2009, 19:46 -0500 schrieb Yufei Yuan:
> Age would cure neither naivety nor stupidity. I would imagine only a
> self-important white supremacist would utter such comments in public
> against a total stranger. If you can read the Chinese above, I
> *seriously* doubt that, it's what Confucious said around 500BC, to
> encourage learning and repentance.

That was of course totally clear and exactly that is the annoyance !

> 
> I may not do a good job in translation, sorry about that. But blindly
> interpret other's intention based on one's own narrow personal
> experience, or cultural context, is the origin of the trouble between
> groups and nations, in this case, two individuals.

OK, let's keep the footers uncensored ;)

> Regards,
> 
> On Wed, Jun 17, 2009 at 7:30 PM, hermann pitton 
> wrote:
> >
> > Am Mittwoch, den 17.06.2009, 19:20 -0500 schrieb Yufei Yuan:
> >> If you take such an intolerant attitude against what others opinion
> >> might be, your words might just be deemed worthless, or should I say
> >> *bullshit*, by others. It is really sad that this world is never in
> >> shortage of people like you.
> >>
> >> What a shame of humanity.
> >>
> >> Regards,
> >
> > I'm a German born in 1957.
> >
> > If that could help you any further in the future not to claim to have
> > the three golden rules ...
> >
> > Cheers,
> > Hermann
> >
> >>
> >> On Wed, Jun 17, 2009 at 7:14 PM, hermann pitton 
> >> wrote:
> >> > Hi,
> >> >
> >> > Am Mittwoch, den 17.06.2009, 19:06 -0500 schrieb Yufei Yuan:
> >> >> Sorry I guess this is about the way the patch was generated? Or about
> >> >> the utility itself?
> >> >>
> >> >> Regards,
> >> >
> >> > most likely.
> >> >
> >> > And that is what I exactly do mean.
> >> >
> >> > Obviously you don't have any control about the footers others provide
> >> > for you, if you go shopping ;)
> >> >
> >> > --
> >> > 好学近乎智,力行近乎仁,知耻近乎勇。
> >> > Eagerness in learning is close to intelligence.
> >> > Commitment in doing is close to nobleness.
> >> > Realization of shamefulness is close to courageousness.
> >> >
> >> > :)
> >> >
> >> > what a bullshit.
> >> >
> >> > Cheers,
> >> > Hermann
> >> >
> >> >>
> >> >> On Wed, Jun 17, 2009 at 6:51 PM, hermann 
> >> >> pitton wrote:
> >> >> >
> >> >> > Am Mittwoch, den 17.06.2009, 18:18 -0500 schrieb Yufei Yuan:
> >> >> >> Hi,
> >> >> >>
> >> >> >> I am not sure if this is the correct mailing list to send this patch.
> >> >> >> >From the LinuxTV website, it seems that currently dvb-apps project
> >> >> >> has
> >> >> >> no owner.
> >> >> >>
> >> >> >> A new utility atsc_epg is added into the dvb-apps utility suite. It
> >> >> >> parses PSIP information carried in OTA ATSC channels, and constructs 
> >> >> >> a
> >> >> >> basic EPG in a terminal window. Changes were also made to files to
> >> >> >> please GCC4.4.
> >> >> >>
> >> >> >> The patch is against latest revision 1278 from the dvb-apps
> >> >> >> repository.
> >> >> >>
> >> >> >> Regards,
> >> >> >> Yufei Yuan
> >> >> >>
> >> >> >> --
> >> >> >> 好学近乎智,力行近乎仁,知耻近乎勇。
> >> >> >> Eagerness in learning is close to intelligence.
> >> >> >> Commitment in doing is close to nobleness.
> >> >> >> Realization of shamefulness is close to courageousness.
> >> >> >
> >> >> > Getting engaged into footers ...
> >> >> >
> >> >> > The above blindly assumes that there is a balance within that 
> >> >> > reduction
> >> >> > to three cases ... (we know two are enough)
> >> >> >
> >> >> > You miss at least several hundred years of history on the other side 
> >> >> > of
> >> >> > the planet.
> >> >> >
> >> >> > I totally disagree with that kind of stuff.
> >> >> >
> >> >> > Most explicitly with the third variant.
> >> >> >
> >> >> > That way you can still press any slave into any army ...
> >> >> >
> >
> >
> >
> 
> 
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [Patch] New utility program atsc_epg added to dvb-apps utility suite.

2009-06-17 Thread hermann pitton
Hi,

Am Mittwoch, den 17.06.2009, 19:20 -0500 schrieb Yufei Yuan:
> If you take such an intolerant attitude against what others opinion
> might be, your words might just be deemed worthless, or should I say
> *bullshit*, by others. It is really sad that this world is never in
> shortage of people like you.
> 
> What a shame of humanity.
> 
> Regards,

yes, feel free to speak up.

I do the same and do hate medieval age footers ;)

Why that stuff is not filtered here ???

Cheers,
Hermann

> 
> On Wed, Jun 17, 2009 at 7:14 PM, hermann pitton 
> wrote:
> > Hi,
> >
> > Am Mittwoch, den 17.06.2009, 19:06 -0500 schrieb Yufei Yuan:
> >> Sorry I guess this is about the way the patch was generated? Or about
> >> the utility itself?
> >>
> >> Regards,
> >
> > most likely.
> >
> > And that is what I exactly do mean.
> >
> > Obviously you don't have any control about the footers others provide
> > for you, if you go shopping ;)
> >
> > --
> > 好学近乎智,力行近乎仁,知耻近乎勇。
> > Eagerness in learning is close to intelligence.
> > Commitment in doing is close to nobleness.
> > Realization of shamefulness is close to courageousness.
> >
> > :)
> >
> > what a bullshit.
> >
> > Cheers,
> > Hermann
> >
> >>
> >> On Wed, Jun 17, 2009 at 6:51 PM, hermann pitton 
> >> wrote:
> >> >
> >> > Am Mittwoch, den 17.06.2009, 18:18 -0500 schrieb Yufei Yuan:
> >> >> Hi,
> >> >>
> >> >> I am not sure if this is the correct mailing list to send this patch.
> >> >> >From the LinuxTV website, it seems that currently dvb-apps project
> >> >> has
> >> >> no owner.
> >> >>
> >> >> A new utility atsc_epg is added into the dvb-apps utility suite. It
> >> >> parses PSIP information carried in OTA ATSC channels, and constructs a
> >> >> basic EPG in a terminal window. Changes were also made to files to
> >> >> please GCC4.4.
> >> >>
> >> >> The patch is against latest revision 1278 from the dvb-apps
> >> >> repository.
> >> >>
> >> >> Regards,
> >> >> Yufei Yuan
> >> >>
> >> >> --
> >> >> 好学近乎智,力行近乎仁,知耻近乎勇。
> >> >> Eagerness in learning is close to intelligence.
> >> >> Commitment in doing is close to nobleness.
> >> >> Realization of shamefulness is close to courageousness.
> >> >
> >> > Getting engaged into footers ...
> >> >
> >> > The above blindly assumes that there is a balance within that reduction
> >> > to three cases ... (we know two are enough)
> >> >
> >> > You miss at least several hundred years of history on the other side of
> >> > the planet.
> >> >
> >> > I totally disagree with that kind of stuff.
> >> >
> >> > Most explicitly with the third variant.
> >> >
> >> > That way you can still press any slave into any army ...
> >> >


--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [Patch] New utility program atsc_epg added to dvb-apps utility suite.

2009-06-17 Thread hermann pitton

Am Mittwoch, den 17.06.2009, 18:18 -0500 schrieb Yufei Yuan:
> Hi,
> 
> I am not sure if this is the correct mailing list to send this patch.
> >From the LinuxTV website, it seems that currently dvb-apps project
> has
> no owner.
> 
> A new utility atsc_epg is added into the dvb-apps utility suite. It
> parses PSIP information carried in OTA ATSC channels, and constructs a
> basic EPG in a terminal window. Changes were also made to files to
> please GCC4.4.
> 
> The patch is against latest revision 1278 from the dvb-apps
> repository.
> 
> Regards,
> Yufei Yuan
> 
> -- 
> 好学近乎智,力行近乎仁,知耻近乎勇。
> Eagerness in learning is close to intelligence.
> Commitment in doing is close to nobleness.
> Realization of shamefulness is close to courageousness.

Getting engaged into footers ...

The above blindly assumes that there is a balance within that reduction
to three cases ... (we know two are enough)

You miss at least several hundred years of history on the other side of
the planet.

I totally disagree with that kind of stuff.

Most explicitly with the third variant.

That way you can still press any slave into any army ...







--
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: typo: v4l2_bound_align_image name mismatch.

2009-06-17 Thread Mauro Carvalho Chehab
Em Wed, 17 Jun 2009 09:17:21 -0700 (PDT)
Trent Piepho  escreveu:

> On Wed, 17 Jun 2009, Mauro Carvalho Chehab wrote:
> > It seems that there's a typo error at pxa-camera. One more fix for the 
> > align stuff.
> 
> Sorry about that.  I did the pxa patch first, then changed the name of
> function before finding other drivers to patch and didn't go back and fix
> the pxa patch.
> 
> 01/02: v4l2: Fix flaw in alignment code
> http://linuxtv.org/hg/~tap/fix?cmd=changeset;node=4ef7fb102b6c
> 
> 02/02: pxa-camera: fix typo
> http://linuxtv.org/hg/~tap/fix?cmd=changeset;node=1ca713eae3b4

Applied, thanks.

I'll fold both patches on your original ones at -git. It is important to fold
the second one to avoid bisect breakages.

> 
> > Forwarded message:
> >
> > Date: Wed, 17 Jun 2009 13:47:57 +
> > From: Jonathan Cameron 
> > To: Linux Media Mailing List ,  Mauro Carvalho 
> > Chehab 
> > Subject: typo: v4l2_bound_align_image name mismatch.
> >
> >
> > Just came across a build error with pxa_camera with Mauro's linux-next tree.
> >
> > pxa-camera calls v4l2_bound_align_image whereas the function is called
> > v4l_bound_align_image.
> >
> > Cheers,
> >
> > ---
> > Jonathan Cameron
> >
> >
> >
> >
> > Cheers,
> > Mauro
> >




Cheers,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


RE: OMAP34XXCAM: Micron mt9d111 sensor support?

2009-06-17 Thread Aguirre Rodriguez, Sergio Alberto


> -Original Message-
> From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
> ow...@vger.kernel.org] On Behalf Of Zach LeRoy
> Sent: Wednesday, June 17, 2009 5:06 PM
> To: linux-omap; linux-media@vger.kernel.org
> Subject: OMAP34XXCAM: Micron mt9d111 sensor support?
> 
> I am working on adding support for a micron 2 MP sensor: mt9d111 on a
> gumsitx overo.  This is a i2c-controlled sensor.  Ideally, I would like to
> use the omap34xxcam driver to interface with this sensor.  I am wondering
> if there are currently any distributions which already include support for
> this sensor through the omap34xxcam driver, or if anyone else is
> interested in this topic.

Hi Zach,

I'm working along with Sakari Ailus and others in this omap34xxcam driver 
you're talking about, and we are in the process to provide a newer patchset to 
work on the latest l-o tree.

Sakari is sharing the camera core here:

http://gitorious.org/omap3camera

And I have also this repository which contains a snapshot of Sakari's tree + 
support from some sensors I have available for the 3430SDP and LDP (the name 
could confuse with the above, but I'll change the name/location soon):

http://gitorious.org/omap3-linux-camera-driver

Testing the driver with as much sensors as we can is very interesting (at least 
for me), because that help us spot possible bugs that aren't seen with our 
current HW. So, I'll be looking forward if you add this sensor driver to the 
supported list :)

Regards,
Sergio
> 
> Cheers,
> 
> Zach LeRoy
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


OMAP34XXCAM: Micron mt9d111 sensor support?

2009-06-17 Thread Zach LeRoy
I am working on adding support for a micron 2 MP sensor: mt9d111 on a gumsitx 
overo.  This is a i2c-controlled sensor.  Ideally, I would like to use the 
omap34xxcam driver to interface with this sensor.  I am wondering if there are 
currently any distributions which already include support for this sensor 
through the omap34xxcam driver, or if anyone else is interested in this topic.

Cheers,

Zach LeRoy
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 4/11 - v3] dm644x ccdc module for vpfe capture driver

2009-06-17 Thread Alexey Klimov
On Thu, Jun 18, 2009 at 12:11 AM,  wrote:
> From: Muralidharan Karicheri 
>
> DM644x CCDC hw module
>
> This is the hw module for DM644x CCDC. This registers with the
> vpfe capture driver and provides a set of hw_ops to configure
> CCDC for a specific decoder device connected to the VPFE
>
> Module description, GPL and owner information MACROs added at the top



> +static int dm644x_ccdc_init(void)
> +{
> +       printk(KERN_NOTICE "dm644x_ccdc_init\n");
> +       if (vpfe_register_ccdc_device(&ccdc_hw_dev) < 0)
> +               return -1;

The same small idea like in "[PATCH 3/11 - v3] dm355 ccdc module for
vpfe capture driver" about this function. What do you think about
introducing ret variable and returning good error code?

> +       printk(KERN_NOTICE "%s is registered with vpfe.\n",
> +               ccdc_hw_dev.name);
> +       return 0;
> +}
> +
> +static void dm644x_ccdc_exit(void)
> +{
> +       vpfe_unregister_ccdc_device(&ccdc_hw_dev);
> +}


-- 
Best regards, Klimov Alexey
--
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


PULL request - http://linuxtv.org/hg/~hgoede/gspca

2009-06-17 Thread Hans de Goede

Hi Mauro,

Can you please pull from:
http://linuxtv.org/hg/~hgoede/gspca

I know you haven't even had the chance to do my previous
pull request :)

New this time:
* mark the ov511 driver as deprecated, note:
we should really also keep track of this
in Documentation/feature-removal-schedule.txt, but that is not
part of the v4l-dvb tree.

* Support for the st6422 bridge + sensor !
Give it a try, I know now you have a cam which uses this bridge :)
When you try it be sure to use the latest (just updated my
libv4l tree) libv4l, this enables (software) automatic control of
the gain and exposure, for a decent image in most lighting
conditions.

BTW, the latest libv4l also does this (auto expo / gain) for the
spca561 based logitech cam I borrowed to you at plumbers last year,
works really nice :)

Regards,

Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 3/11 - v3] dm355 ccdc module for vpfe capture driver

2009-06-17 Thread Alexey Klimov
Hello,
one more small comment

On Thu, Jun 18, 2009 at 12:11 AM,  wrote:
> From: Muralidharan Karicheri 
>
> DM355 CCDC hw module
>
> Adds ccdc hw module for DM355 CCDC. This registers with the bridge
> driver a set of hw_ops for configuring the CCDC for a specific
> decoder device connected to vpfe.
>
> The module description and owner information added





> +static int dm355_ccdc_init(void)
> +{
> +       printk(KERN_NOTICE "dm355_ccdc_init\n");
> +       if (vpfe_register_ccdc_device(&ccdc_hw_dev) < 0)
> +               return -1;

Don't you want to rewrite this to return good error code?
int ret;
printk();
ret = vpfe_register_ccdc_device();
if (ret < 0)
return ret;

I know you have tight/fast track/hard schedule, so you can do this
improvement later, after merging this patch.

> +       printk(KERN_NOTICE "%s is registered with vpfe.\n",
> +               ccdc_hw_dev.name);
> +       return 0;
> +}
> +
> +static void dm355_ccdc_exit(void)
> +{
> +       vpfe_unregister_ccdc_device(&ccdc_hw_dev);
> +}


-- 
Best regards, Klimov Alexey
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 1/11 - v3] vpfe capture bridge driver for DM355 and DM6446

2009-06-17 Thread Alexey Klimov
Hello,

very small comments, see below please

On Thu, Jun 18, 2009 at 12:11 AM,  wrote:
> From: Muralidharan Karicheri 



> +static int vpfe_enable_clock(struct vpfe_device *vpfe_dev)
> +{
> +       struct vpfe_config *vpfe_cfg = vpfe_dev->cfg;
> +       int ret = -ENOENT;
> +
> +       vpfe_cfg->vpssclk = clk_get(vpfe_dev->pdev, "vpss_master");
> +       if (NULL == vpfe_cfg->vpssclk) {
> +               v4l2_err(vpfe_dev->pdev->driver, "No clock defined for"
> +                        "vpss_master\n");
> +               return ret;
> +       }
> +
> +       if (clk_enable(vpfe_cfg->vpssclk)) {
> +               v4l2_err(vpfe_dev->pdev->driver,
> +                       "vpfe vpss master clock not enabled");
> +               goto out;
> +       }
> +       v4l2_info(vpfe_dev->pdev->driver,
> +                "vpfe vpss master clock enabled\n");
> +
> +       vpfe_cfg->slaveclk = clk_get(vpfe_dev->pdev, "vpss_slave");
> +       if (NULL == vpfe_cfg->slaveclk) {
> +               v4l2_err(vpfe_dev->pdev->driver,
> +                       "No clock defined for vpss slave\n");
> +               goto out;
> +       }
> +
> +       if (clk_enable(vpfe_cfg->slaveclk)) {
> +               v4l2_err(vpfe_dev->pdev->driver,
> +                        "vpfe vpss slave clock not enabled");
> +               goto out;
> +       }
> +       v4l2_info(vpfe_dev->pdev->driver,
> +                "vpfe vpss slave clock enabled\n");
> +       return 0;
> +out:
> +       if (vpfe_cfg->vpssclk)
> +               clk_put(vpfe_cfg->vpssclk);
> +       if (vpfe_cfg->slaveclk)
> +               clk_put(vpfe_cfg->slaveclk);
> +
> +       return -1;
> +}
> +
> +/*
> + * vpfe_probe : This function creates device entries by register
> + * itself to the V4L2 driver and initializes fields of each
> + * device objects
> + */
> +static __init int vpfe_probe(struct platform_device *pdev)
> +{
> +       struct vpfe_config *vpfe_cfg;
> +       struct resource *res1;
> +       struct vpfe_device *vpfe_dev;
> +       struct i2c_adapter *i2c_adap;
> +       struct i2c_client *client;
> +       struct video_device *vfd;
> +       int ret = -ENOMEM, i, j;
> +       int num_subdevs = 0;
> +
> +       /* Get the pointer to the device object */
> +       vpfe_dev = vpfe_initialize();
> +
> +       if (!vpfe_dev) {
> +               v4l2_err(pdev->dev.driver,
> +                       "Failed to allocate memory for vpfe_dev\n");
> +               return ret;
> +       }
> +
> +       vpfe_dev->pdev = &pdev->dev;
> +
> +       if (NULL == pdev->dev.platform_data) {
> +               v4l2_err(pdev->dev.driver, "Unable to get vpfe config\n");
> +               ret = -ENOENT;
> +               goto probe_free_dev_mem;
> +       }
> +
> +       vpfe_cfg = pdev->dev.platform_data;
> +       vpfe_dev->cfg = vpfe_cfg;
> +       if (NULL == vpfe_cfg->ccdc ||
> +           NULL == vpfe_cfg->card_name ||
> +           NULL == vpfe_cfg->sub_devs) {
> +               v4l2_err(pdev->dev.driver, "null ptr in vpfe_cfg\n");
> +               ret = -ENOENT;
> +               goto probe_free_dev_mem;
> +       }
> +
> +       /* enable vpss clocks */
> +       ret = vpfe_enable_clock(vpfe_dev);
> +       if (ret)
> +               goto probe_free_dev_mem;
> +
> +       mutex_lock(&ccdc_lock);
> +       /* Allocate memory for ccdc configuration */
> +       ccdc_cfg = kmalloc(sizeof(struct ccdc_config), GFP_KERNEL);
> +       if (NULL == ccdc_cfg) {
> +               v4l2_err(pdev->dev.driver, "Memory allocation failed for"
> +                       "ccdc_cfg");
> +               goto probe_disable_clock;
> +       }
> +
> +       strncpy(ccdc_cfg->name, vpfe_cfg->ccdc, 32);
> +       /* Get VINT0 irq resource */
> +       res1 = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
> +       if (!res1) {
> +               v4l2_err(pdev->dev.driver, "Unable to get interrupt for 
> VINT0");

Do you want to add "\n" to the end of this message? If i'm now wrong
it's better to check other messages in this patch for "\n". Please,
check.

> +               ret = -ENOENT;
> +               goto probe_disable_clock;
> +       }
> +       vpfe_dev->ccdc_irq0 = res1->start;
> +
> +       /* Get VINT1 irq resource */
> +       res1 = platform_get_resource(pdev,
> +                               IORESOURCE_IRQ, 1);
> +       if (!res1) {
> +               v4l2_err(pdev->dev.driver, "Unable to get interrupt for 
> VINT1");

"\n" ?

> +               ret = -ENOENT;
> +               goto probe_disable_clock;
> +       }
> +       vpfe_dev->ccdc_irq1 = res1->start;
> +
> +       /* Get address base of CCDC */
> +       res1 = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +       if (!res1) {
> +               v4l2_err(pdev->dev.driver,
> +                       "Unable to get register address map\n");
> +               ret = -ENOENT;
> +               goto probe_disable_clock;
> +       }
> +
> +       ccdc_cfg->ccdc_addr_size = res1->end - res1->start + 1;
> +       if (!request_mem

[PATCH] adding support for setting bus parameters in sub device

2009-06-17 Thread m-karicheri2
From: Muralidharan Karicheri 

This patch adds support for setting bus parameters such as bus type
(Raw Bayer or Raw YUV image data bus), bus width (example 10 bit raw
image data bus, 10 bit BT.656 etc.), and polarities (vsync, hsync, field
etc) in sub device. This allows bridge driver to configure the sub device
bus for a specific set of bus parameters through s_bus() function call.
This also can be used to define platform specific bus parameters for
host and sub-devices.

Reviewed by: Hans Verkuil 
Signed-off-by: Murali Karicheri 
---
Applies to v4l-dvb repository

 include/media/v4l2-subdev.h |   40 
 1 files changed, 40 insertions(+), 0 deletions(-)

diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
index 1785608..8532b91 100644
--- a/include/media/v4l2-subdev.h
+++ b/include/media/v4l2-subdev.h
@@ -37,6 +37,43 @@ struct v4l2_decode_vbi_line {
u32 type;   /* VBI service type (V4L2_SLICED_*). 0 if no 
service found */
 };
 
+/*
+ * Some sub-devices are connected to the host/bridge device through a bus that
+ * carries the clock, vsync, hsync and data. Some interfaces such as BT.656
+ * carries the sync embedded in the data where as others have separate line
+ * carrying the sync signals. The structure below is used to define bus
+ * configuration parameters for host as well as sub-device
+ */
+enum v4l2_bus_type {
+   /* Raw YUV image data bus */
+   V4L2_BUS_RAW_YUV,
+   /* Raw Bayer image data bus */
+   V4L2_BUS_RAW_BAYER
+};
+
+struct v4l2_bus_settings {
+   /* yuv or bayer image data bus */
+   enum v4l2_bus_type type;
+   /* subdev bus width */
+   u8 subdev_width;
+   /* host bus width */
+   u8 host_width;
+   /* embedded sync, set this when sync is embedded in the data stream */
+   unsigned embedded_sync:1;
+   /* master or slave */
+   unsigned host_is_master:1;
+   /* 0 - active low, 1 - active high */
+   unsigned pol_vsync:1;
+   /* 0 - active low, 1 - active high */
+   unsigned pol_hsync:1;
+   /* 0 - low to high , 1 - high to low */
+   unsigned pol_field:1;
+   /* 0 - active low , 1 - active high */
+   unsigned pol_data:1;
+   /* 0 - sample at falling edge , 1 - sample at rising edge */
+   unsigned edge_pclock:1;
+};
+
 /* Sub-devices are devices that are connected somehow to the main bridge
device. These devices are usually audio/video muxers/encoders/decoders or
sensors and webcam controllers.
@@ -199,6 +236,8 @@ struct v4l2_subdev_audio_ops {
 
s_routing: see s_routing in audio_ops, except this version is for video
devices.
+
+   s_bus: set bus parameters in sub device to configure the bus
  */
 struct v4l2_subdev_video_ops {
int (*s_routing)(struct v4l2_subdev *sd, u32 input, u32 output, u32 
config);
@@ -219,6 +258,7 @@ struct v4l2_subdev_video_ops {
int (*s_parm)(struct v4l2_subdev *sd, struct v4l2_streamparm *param);
int (*enum_framesizes)(struct v4l2_subdev *sd, struct v4l2_frmsizeenum 
*fsize);
int (*enum_frameintervals)(struct v4l2_subdev *sd, struct 
v4l2_frmivalenum *fival);
+   int (*s_bus)(struct v4l2_subdev *sd, const struct v4l2_bus_settings 
*bus);
 };
 
 struct v4l2_subdev_ops {
-- 
1.6.0.4

--
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: [DaVinci] patches for linux-media

2009-06-17 Thread Karicheri, Muralidharan
Hi Hans & Mauro,

The v3 version of the DaVici VPFE Capture driver and TVP514x driver has been 
sent to the list for review. I expect this to sail through with out any 
comments as I have addressed few minor comments from last review. I think Hans 
will send you the pull request for these patches. Once again, it will be great 
if this can be merged to 2.6.31.

Murali Karicheri
m-kariche...@ti.com

>I have proposed this before, but I'll do it again: I'm more than happy to
>be
>the official person who collects and organizes the omap and davinci patches
>for you and who does the initial reviews. This is effectively already the
>case since I've been reviewing both omap and davinci patches pretty much
>from the beginning.
>
>Both the omap2/3 display driver and the davinci drivers are now very close
>to be ready for inclusion in the kernel as my last reviews only found some
>minor things.
>
>Part of the reason for the delays for both omap and davinci was that they
>had to be modified for v4l2_subdev, which was an absolute necessity, and
>because they simply needed quite a bit of work to make them suitable for
>inclusion in the kernel.
>
>Regards,
>
>   Hans
>
>--
>Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom

--
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 - V3] TVP514x: Migration to sub-device framework

2009-06-17 Thread m-karicheri2
From: Muralidharan Karicheri 

This patch converts TVP514x driver to sub-device framework
from V4L2-int framework. 

NOTE: Please note that this patch was tested on DM355 and DM6446
and not tested on OMAP platform

Changes from v2 based on review comments (Taken over this work from
Vaibhav)

- removed __exit for tvp514x_remove
- removed v4l2_i2c_driver_data and use new model similar to ths7303
- changed state to streaming

TODO:
- Add support for some basic video/core functionality like,
  .g_chip_ident
  .reset
  .g_input_status
- Migration of OMAP master driver to validate this driver
- validate on OMAP boards

Reviewed by :Hans Verkuil 

Signed-off-by: Brijesh Jadav 
Signed-off-by: Hardik Shah 
Signed-off-by: Vaibhav Hiremath 
Signed-off-by: Murali Karicheri 
---
Applies to v4l-dvb repository
 
 drivers/media/video/tvp514x.c  |  875 ++--
 drivers/media/video/tvp514x_regs.h |   10 -
 include/media/tvp514x.h|4 -
 3 files changed, 349 insertions(+), 540 deletions(-)

diff --git a/drivers/media/video/tvp514x.c b/drivers/media/video/tvp514x.c
index 3750f7f..6063b57 100644
--- a/drivers/media/video/tvp514x.c
+++ b/drivers/media/video/tvp514x.c
@@ -31,7 +31,10 @@
 #include 
 #include 
 #include 
-#include 
+
+#include 
+#include 
+#include 
 #include 
 
 #include "tvp514x_regs.h"
@@ -49,13 +52,11 @@ static int debug;
 module_param(debug, bool, 0644);
 MODULE_PARM_DESC(debug, "Debug level (0-1)");
 
-#define dump_reg(client, reg, val) \
-   do {\
-   val = tvp514x_read_reg(client, reg);\
-   v4l_info(client, "Reg(0x%.2X): 0x%.2X\n", reg, val); \
-   } while (0)
+MODULE_AUTHOR("Texas Instruments");
+MODULE_DESCRIPTION("TVP514X linux decoder driver");
+MODULE_LICENSE("GPL");
 
-/**
+/*
  * enum tvp514x_std - enum for supported standards
  */
 enum tvp514x_std {
@@ -64,15 +65,7 @@ enum tvp514x_std {
STD_INVALID
 };
 
-/**
- * enum tvp514x_state - enum for different decoder states
- */
-enum tvp514x_state {
-   STATE_NOT_DETECTED,
-   STATE_DETECTED
-};
-
-/**
+/*
  * struct tvp514x_std_info - Structure to store standard informations
  * @width: Line width in pixels
  * @height:Number of active lines
@@ -87,35 +80,29 @@ struct tvp514x_std_info {
 };
 
 static struct tvp514x_reg tvp514x_reg_list_default[0x40];
-/**
+/*
  * struct tvp514x_decoder - TVP5146/47 decoder object
- * @v4l2_int_device: Slave handle
- * @tvp514x_slave: Slave pointer which is used by @v4l2_int_device
+ * @sd: Subdevice Slave handle
  * @tvp514x_regs: copy of hw's regs with preset values.
  * @pdata: Board specific
- * @client: I2C client data
- * @id: Entry from I2C table
  * @ver: Chip version
- * @state: TVP5146/47 decoder state - detected or not-detected
+ * @streaming: TVP5146/47 decoder streaming - enabled or disabled.
  * @pix: Current pixel format
  * @num_fmts: Number of formats
  * @fmt_list: Format list
  * @current_std: Current standard
  * @num_stds: Number of standards
  * @std_list: Standards list
- * @route: input and output routing at chip level
+ * @input: Input routing at chip level
+ * @output: Output routing at chip level
  */
 struct tvp514x_decoder {
-   struct v4l2_int_device v4l2_int_device;
-   struct v4l2_int_slave tvp514x_slave;
+   struct v4l2_subdev sd;
struct tvp514x_reg tvp514x_regs[ARRAY_SIZE(tvp514x_reg_list_default)];
const struct tvp514x_platform_data *pdata;
-   struct i2c_client *client;
-
-   struct i2c_device_id *id;
 
int ver;
-   enum tvp514x_state state;
+   int streaming;
 
struct v4l2_pix_format pix;
int num_fmts;
@@ -124,8 +111,11 @@ struct tvp514x_decoder {
enum tvp514x_std current_std;
int num_stds;
struct tvp514x_std_info *std_list;
-
-   struct v4l2_routing route;
+   /*
+* Input and Output Routing parameters
+*/
+   u32 input;
+   u32 output;
 };
 
 /* TVP514x default register values */
@@ -191,7 +181,8 @@ static struct tvp514x_reg tvp514x_reg_list_default[] = {
{TOK_TERM, 0, 0},
 };
 
-/* List of image formats supported by TVP5146/47 decoder
+/*
+ * List of image formats supported by TVP5146/47 decoder
  * Currently we are using 8 bit mode only, but can be
  * extended to 10/20 bit mode.
  */
@@ -240,35 +231,29 @@ static struct tvp514x_std_info tvp514x_std_list[] = {
},
/* Standard: need to add for additional standard */
 };
-/*
- * Control structure for Auto Gain
- * This is temporary data, will get replaced once
- * v4l2_ctrl_query_fill supports it.
- */
-static const struct v4l2_queryctrl tvp514x_autogain_ctrl = {
-   .id = V4L2_CID_AUTOGAIN,
-   .name = "Gain, Automatic",
-   .type = V4L2_CTRL_TYPE_BOOLEAN,
-   .minimum = 0,
-   .maximum = 1,
-   .step 

Re: bttv problem loading takes about several minutes

2009-06-17 Thread Halim Sahin
Hi,
On Mi, Jun 17, 2009 at 10:06:26 +0200, Hans Verkuil wrote:
> The log is from bttv version 0.9.17. The new code is only present in version 
> 0.9.18. So this is definitely not related to any of my changes.
> 

Yes it's from a debian lenny kernel 2.6.26.
But I have tested latest v4l-dvb with the same result
under 2.6.28 (ubuntu 9.04).



> The code in bttv_probe (bttv-driver.c) does this:
> 
> if (bttv_verbose)
> bttv_gpio_tracking(btv,"init");
> 
> /* needs to be done before i2c is registered */
> bttv_init_card1(btv);
> 
> /* register i2c + gpio */
> init_bttv_i2c(btv);
> 
> /* some card-specific stuff (needs working i2c) */
> bttv_init_card2(btv);
> 
> So it looks like it can be either bttv_init_card1 or init_bttv_i2c that is 
> causing the delay.
> 
> Halim, can you try to put some printk() statements in between the calls 
> above to see which call is taking so long? Actually, it would be nice if 
> you are able to 'drill-down' as well in whatever function is causing the 
> delay, since I truly don't see what might be delaying things for you.

Yes I will test  this tomorrow.

Thanks a lot!
Halim

--
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 0/11 - v3] ARM: DaVinci: Video: DM355/DM6446 VPFE Capture driver

2009-06-17 Thread m-karicheri2
From: Muralidharan Karicheri 

Big Thanks to all reviewers who have contributed to this driver
by reviewing and offering valuable comments.

VPFE Capture driver for DaVinci Media SOCs :- DM355 and DM6446

This is the version v3 of the patch series. This is the reworked
version of the driver based on comments received against the last
version (v2) of the patch and is expected to be final version
candidate for merge to upstream kernel

+++
These patches add support for VPFE (Video Processing Front End) based
video capture on DM355 and DM6446 EVMs. For more details on the hardware
configuration and capabilities, please refer the vpfe_capture.c header.
This patch set consists of following:- 

Patch 1: VPFE Capture bridge driver
Patch 2: CCDC hw device header file
Patch 3: DM355 CCDC hw module
Patch 4: DM644x CCDC hw module
Patch 5: ccdc types used across CCDC modules
Patch 6: Makefile and config files for the driver
Patch 7: DM355 platform and board setup
Patch 8: DM644x platform and board setup
Patch 9: common vpss hw module for video drivers
Patch 10: Remove outdated driver files from davinci git tree
Patch 11: Makefile and config files for the davinci git tree (New
from v2)

NOTE:

1. Patches 10-11 are only for DaVinci GIT tree. Others applies to
DaVinci GIT and v4l-dvb

2. Dependent on the TVP514x decoder driver patch for migrating the
driver to sub device model from Vaibhav Hiremath. I am sending the
reworked version of this patch instead of Vaibhav.

Following tests are performed.
1) Capture and display video (PAL & NTSC) from tvp5146 decoder.
   Displayed using fbdev device driver available on davinci git tree
2) Tested with driver built statically and dynamically

Muralidhara Karicheri

Reviewed by: Hans Verkuil 
Reviewed by: Laurent Pinchart 
Reviewed by: Alexey Klimov 
Reviewed by: Kevin Hilman 
Reviewed by: David Brownell 

Signed-off-by: Muralidharan Karicheri 
--
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 8/11 - v3] DM6446 platform changes for vpfe capture driver

2009-06-17 Thread m-karicheri2
From: Muralidharan Karicheri 

DM644x platform and board setup

This adds plarform and board setup changes required to support
vpfe capture driver on DM644x

summary of changes:-
1) replaced v4l2_routing structure with vpfe structure
2) input names changed to Composite and S-Video
3) bus parameters defined for ccdc

Reviewed by: Hans Verkuil 
Reviewed by: Laurent Pinchart 
Reviewed by: Kevin Hilman 
Reviewed by: David Brownell 

Signed-off-by: Muralidharan Karicheri 
---
Applies to Davinci GIT Tree

 arch/arm/mach-davinci/board-dm644x-evm.c|   72 ++-
 arch/arm/mach-davinci/dm644x.c  |   56 +
 arch/arm/mach-davinci/include/mach/dm644x.h |2 +
 3 files changed, 128 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c 
b/arch/arm/mach-davinci/board-dm644x-evm.c
index d9d4045..54f084b 100644
--- a/arch/arm/mach-davinci/board-dm644x-evm.c
+++ b/arch/arm/mach-davinci/board-dm644x-evm.c
@@ -28,7 +28,8 @@
 #include 
 #include 
 #include 
-
+#include 
+#include 
 #include 
 #include 
 
@@ -195,6 +196,62 @@ static struct platform_device davinci_fb_device = {
.num_resources = 0,
 };
 
+#define TVP514X_STD_ALL(V4L2_STD_NTSC | V4L2_STD_PAL)
+/* Inputs available at the TVP5146 */
+static struct v4l2_input tvp5146_inputs[] = {
+   {
+   .index = 0,
+   .name = "Composite",
+   .type = V4L2_INPUT_TYPE_CAMERA,
+   .std = TVP514X_STD_ALL,
+   },
+   {
+   .index = 1,
+   .name = "S-Video",
+   .type = V4L2_INPUT_TYPE_CAMERA,
+   .std = TVP514X_STD_ALL,
+   },
+};
+
+/*
+ * this is the route info for connecting each input to decoder
+ * ouput that goes to vpfe. There is a one to one correspondence
+ * with tvp5146_inputs
+ */
+static struct vpfe_route tvp5146_routes[] = {
+   {
+   .input = INPUT_CVBS_VI2B,
+   .output = OUTPUT_10BIT_422_EMBEDDED_SYNC,
+   },
+   {
+   .input = INPUT_SVIDEO_VI2C_VI1C,
+   .output = OUTPUT_10BIT_422_EMBEDDED_SYNC,
+   },
+};
+
+static struct vpfe_subdev_info vpfe_sub_devs[] = {
+   {
+   .name = "tvp5146",
+   .grp_id = 0,
+   .num_inputs = ARRAY_SIZE(tvp5146_inputs),
+   .inputs = tvp5146_inputs,
+   .routes = tvp5146_routes,
+   .can_route = 1,
+   .ccdc_if_params = {
+   .if_type = VPFE_BT656,
+   .hdpol = VPFE_PINPOL_POSITIVE,
+   .vdpol = VPFE_PINPOL_POSITIVE,
+   },
+   },
+};
+
+static struct vpfe_config vpfe_cfg = {
+   .num_subdevs = ARRAY_SIZE(vpfe_sub_devs),
+   .sub_devs = vpfe_sub_devs,
+   .card_name = "DM6446 EVM",
+   .ccdc = "DM6446 CCDC",
+};
+
 static struct platform_device rtc_dev = {
.name   = "rtc_davinci_evm",
.id = -1,
@@ -447,6 +504,12 @@ static struct at24_platform_data eeprom_info = {
.context= (void *)0x7f00,
 };
 
+static struct tvp514x_platform_data tvp5146_pdata = {
+   .clk_polarity = 0,
+   .hs_polarity = 1,
+   .vs_polarity = 1
+};
+
 /*
  * MSP430 supports RTC, card detection, input from IR remote, and
  * a bit more.  It triggers interrupts on GPIO(7) from pressing
@@ -558,9 +621,12 @@ static struct i2c_board_info __initdata i2c_info[] =  {
I2C_BOARD_INFO("24c256", 0x50),
.platform_data  = &eeprom_info,
},
+   {
+   I2C_BOARD_INFO("tvp5146", 0x5d),
+   .platform_data = &tvp5146_pdata,
+   },
/* ALSO:
 * - tvl320aic33 audio codec (0x1b)
-* - tvp5146 video decoder (0x5d)
 */
 };
 
@@ -591,6 +657,8 @@ static struct davinci_uart_config uart_config __initdata = {
 static void __init
 davinci_evm_map_io(void)
 {
+   /* setup input configuration for VPFE input devices */
+   dm644x_set_vpfe_config(&vpfe_cfg);
dm644x_init();
 }
 
diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
index dd58f08..09993cc 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -549,6 +549,59 @@ static struct platform_device dm644x_edma_device = {
.resource   = edma_resources,
 };
 
+static struct resource dm644x_vpss_resources[] = {
+   {
+   /* VPSS Base address */
+   .name   = "vpss",
+   .start  = 0x01c73400,
+   .end= 0x01c73400 + 0xff,
+   .flags  = IORESOURCE_MEM,
+   },
+};
+
+static struct platform_device dm644x_vpss_device = {
+   .name   = "vpss",
+   .id = -1,
+   .dev.platform_data  = "dm644x_vpss",
+   .num_resources  = ARRAY_SIZE(dm644x_vpss_resources),
+   .resource

[PATCH 11/11 - v3] Makefile and config file changes for davinci git tree

2009-06-17 Thread m-karicheri2
From: Muralidharan Karicheri 

Makefile and config files for vpfe capture driver that applies
to DaVinci GIT tree only. This is added to help in applying this
patch to DaVinci GIT tree since the tree has some obsolete davinci
drivers that is being removed by this patch. These files are not
available in upstream kernel. Please use this patch instead of 
Patch #6 of this series for DaVinci GIT tree.

Reviewed by: Hans Verkuil 
Reviewed by: Laurent Pinchart 
Reviewed by: Kevin Hilman 

Signed-off-by: Muralidharan Karicheri 
---
Applies to DaVinci GIT tree

 drivers/media/video/Kconfig  |   57 +
 drivers/media/video/Makefile |6 +---
 drivers/media/video/davinci/Makefile |9 +
 3 files changed, 53 insertions(+), 19 deletions(-)
 create mode 100644 drivers/media/video/davinci/Makefile

diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index e037e3f..ee6806c 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -479,25 +479,54 @@ config VIDEO_VIVI
  Say Y here if you want to test video apps or debug V4L devices.
  In doubt, say N.
 
-config VIDEO_TVP5146
-   tristate "TVP5146 video decoder"
-   depends on I2C && ARCH_DAVINCI
+config VIDEO_VPSS_SYSTEM
+   tristate "VPSS System module driver"
+   depends on ARCH_DAVINCI
help
- Support for I2C bus based TVP5146 configuration.
-
- To compile this driver as a module, choose M here: the
- module will be called tvp5146.
+ Support for vpss system module for video driver
+   default y
 
-config VIDEO_DAVINCI
-   tristate "Davinci Video Capture"
-   depends on VIDEO_DEV && VIDEO_TVP5146 && ARCH_DAVINCI
-   select VIDEOBUF_GEN
-   select VIDEOBUF_DMA_SG
+config VIDEO_VPFE_CAPTURE
+   tristate "VPFE Video Capture Driver"
+   depends on VIDEO_V4L2 && ARCH_DAVINCI
+   select VIDEOBUF_DMA_CONTIG
help
- Support for Davinci based frame grabber through CCDC.
+ Support for DM VPFE based frame grabber. This is the
+ common V4L2 module for following DMXXX SoCs from Texas
+ Instruments:- DM6446 & DM355.
 
  To compile this driver as a module, choose M here: the
- module will be called vpfe.
+ module will be called vpfe-capture.
+
+config VIDEO_DM6446_CCDC
+   tristate "DM6446 CCDC HW module"
+   depends on ARCH_DAVINCI_DM644x && VIDEO_VPFE_CAPTURE
+   select VIDEO_VPSS_SYSTEM
+   default y
+   help
+  Enables DaVinci CCD hw module. DaVinci CCDC hw interfaces
+  with decoder modules such as TVP5146 over BT656 or
+  sensor module such as MT9T001 over a raw interface. This
+  module configures the interface and CCDC/ISIF to do
+  video frame capture from slave decoders.
+
+  To compile this driver as a module, choose M here: the
+  module will be called vpfe.
+
+config VIDEO_DM355_CCDC
+   tristate "DM355 CCDC HW module"
+   depends on ARCH_DAVINCI_DM355 && VIDEO_VPFE_CAPTURE
+   select VIDEO_VPSS_SYSTEM
+   default y
+   help
+  Enables DM355 CCD hw module. DM355 CCDC hw interfaces
+  with decoder modules such as TVP5146 over BT656 or
+  sensor module such as MT9T001 over a raw interface. This
+  module configures the interface and CCDC/ISIF to do
+  video frame capture from a slave decoders
+
+  To compile this driver as a module, choose M here: the
+  module will be called vpfe.
 
 source "drivers/media/video/bt8xx/Kconfig"
 
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index 12ddb9a..76db635 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -10,8 +10,6 @@ stkwebcam-objs:=  stk-webcam.o stk-sensor.o
 
 omap2cam-objs  :=  omap24xxcam.o omap24xxcam-dma.o
 
-davinci-vpfe-objs   :=  ccdc_davinci.o davinci_vpfe.o
-
 videodev-objs  :=  v4l2-dev.o v4l2-ioctl.o v4l2-device.o
 
 obj-$(CONFIG_VIDEO_DEV) += videodev.o v4l2-int-device.o
@@ -133,9 +131,6 @@ obj-$(CONFIG_USB_S2255) += s2255drv.o
 obj-$(CONFIG_VIDEO_IVTV) += ivtv/
 obj-$(CONFIG_VIDEO_CX18) += cx18/
 
-obj-$(CONFIG_VIDEO_DAVINCI) += davinci-vpfe.o
-obj-$(CONFIG_VIDEO_TVP5146) += tvp5146.o
-
 obj-$(CONFIG_VIDEO_VIVI) += vivi.o
 obj-$(CONFIG_VIDEO_CX23885) += cx23885/
 
@@ -152,6 +147,7 @@ obj-$(CONFIG_SOC_CAMERA_MT9V022)+= mt9v022.o
 obj-$(CONFIG_SOC_CAMERA_OV772X)+= ov772x.o
 obj-$(CONFIG_SOC_CAMERA_PLATFORM)  += soc_camera_platform.o
 obj-$(CONFIG_SOC_CAMERA_TW9910)+= tw9910.o
+obj-$(CONFIG_ARCH_DAVINCI) += davinci/
 
 obj-$(CONFIG_VIDEO_AU0828) += au0828/
 
diff --git a/drivers/media/video/davinci/Makefile 
b/drivers/media/video/davinci/Makefile
new file mode 100644
index 000..b84a405
--- /dev/null
+++ b/drivers/media/video/davinci/Makefile
@@ -0,0 +1,9 @@
+#
+

[PATCH 6/11 - v3] Makefile and config files for vpfe capture driver

2009-06-17 Thread m-karicheri2
From: Muralidharan Karicheri 

Makefile and config files for the driver

This adds Makefile and Kconfig changes to build vpfe capture driver.

No change in this version

Reviewed by: Hans Verkuil 
Reviewed by: Laurent Pinchart 

Signed-off-by: Muralidharan Karicheri 
---
Applies to v4l-dvb repository

 drivers/media/video/Kconfig  |   49 ++
 drivers/media/video/Makefile |2 +
 drivers/media/video/davinci/Makefile |9 ++
 3 files changed, 60 insertions(+), 0 deletions(-)
 create mode 100644 drivers/media/video/davinci/Makefile

diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index 94f4405..8a1bd1c 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -497,6 +497,55 @@ config VIDEO_VIVI
  Say Y here if you want to test video apps or debug V4L devices.
  In doubt, say N.
 
+config VIDEO_VPSS_SYSTEM
+   tristate "VPSS System module driver"
+   depends on ARCH_DAVINCI
+   help
+ Support for vpss system module for video driver
+   default y
+
+config VIDEO_VPFE_CAPTURE
+   tristate "VPFE Video Capture Driver"
+   depends on VIDEO_V4L2 && ARCH_DAVINCI
+   select VIDEOBUF_DMA_CONTIG
+   help
+ Support for DM VPFE based frame grabber. This is the
+ common V4L2 module for following DMXXX SoCs from Texas
+ Instruments:- DM6446 & DM355.
+
+ To compile this driver as a module, choose M here: the
+ module will be called vpfe-capture.
+
+config VIDEO_DM6446_CCDC
+   tristate "DM6446 CCDC HW module"
+   depends on ARCH_DAVINCI_DM644x && VIDEO_VPFE_CAPTURE
+   select VIDEO_VPSS_SYSTEM
+   default y
+   help
+  Enables DaVinci CCD hw module. DaVinci CCDC hw interfaces
+  with decoder modules such as TVP5146 over BT656 or
+  sensor module such as MT9T001 over a raw interface. This
+  module configures the interface and CCDC/ISIF to do
+  video frame capture from slave decoders.
+
+  To compile this driver as a module, choose M here: the
+  module will be called vpfe.
+
+config VIDEO_DM355_CCDC
+   tristate "DM355 CCDC HW module"
+   depends on ARCH_DAVINCI_DM355 && VIDEO_VPFE_CAPTURE
+   select VIDEO_VPSS_SYSTEM
+   default y
+   help
+  Enables DM355 CCD hw module. DM355 CCDC hw interfaces
+  with decoder modules such as TVP5146 over BT656 or
+  sensor module such as MT9T001 over a raw interface. This
+  module configures the interface and CCDC/ISIF to do
+  video frame capture from a slave decoders
+
+  To compile this driver as a module, choose M here: the
+  module will be called vpfe.
+
 source "drivers/media/video/bt8xx/Kconfig"
 
 config VIDEO_PMS
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index 7fb3add..1f28495 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -153,6 +153,8 @@ obj-$(CONFIG_VIDEO_MX3) += mx3_camera.o
 obj-$(CONFIG_VIDEO_PXA27x) += pxa_camera.o
 obj-$(CONFIG_VIDEO_SH_MOBILE_CEU)  += sh_mobile_ceu_camera.o
 
+obj-$(CONFIG_ARCH_DAVINCI) += davinci/
+
 obj-$(CONFIG_VIDEO_AU0828) += au0828/
 
 obj-$(CONFIG_USB_VIDEO_CLASS)  += uvc/
diff --git a/drivers/media/video/davinci/Makefile 
b/drivers/media/video/davinci/Makefile
new file mode 100644
index 000..b84a405
--- /dev/null
+++ b/drivers/media/video/davinci/Makefile
@@ -0,0 +1,9 @@
+#
+# Makefile for the davinci video device drivers.
+#
+
+# Capture: DM6446 and DM355
+obj-$(CONFIG_VIDEO_VPSS_SYSTEM) += vpss.o
+obj-$(CONFIG_VIDEO_VPFE_CAPTURE) += vpfe_capture.o
+obj-$(CONFIG_VIDEO_DM6446_CCDC) += dm644x_ccdc.o
+obj-$(CONFIG_VIDEO_DM355_CCDC) += dm355_ccdc.o
-- 
1.6.0.4

--
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 4/11 - v3] dm644x ccdc module for vpfe capture driver

2009-06-17 Thread m-karicheri2
From: Muralidharan Karicheri 

DM644x CCDC hw module

This is the hw module for DM644x CCDC. This registers with the
vpfe capture driver and provides a set of hw_ops to configure
CCDC for a specific decoder device connected to the VPFE

Module description, GPL and owner information MACROs added at the top

Reviewed by: Hans Verkuil 
Reviewed by: Laurent Pinchart 

Signed-off-by: Muralidharan Karicheri 
---
Applies to v4l-dvb repository

 drivers/media/video/davinci/dm644x_ccdc.c  |  878 
 drivers/media/video/davinci/dm644x_ccdc_regs.h |  145 
 include/media/davinci/dm644x_ccdc.h|  184 +
 3 files changed, 1207 insertions(+), 0 deletions(-)
 create mode 100644 drivers/media/video/davinci/dm644x_ccdc.c
 create mode 100644 drivers/media/video/davinci/dm644x_ccdc_regs.h
 create mode 100644 include/media/davinci/dm644x_ccdc.h

diff --git a/drivers/media/video/davinci/dm644x_ccdc.c 
b/drivers/media/video/davinci/dm644x_ccdc.c
new file mode 100644
index 000..2f19a91
--- /dev/null
+++ b/drivers/media/video/davinci/dm644x_ccdc.c
@@ -0,0 +1,878 @@
+/*
+ * Copyright (C) 2006-2009 Texas Instruments Inc
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ *
+ * CCDC hardware module for DM6446
+ * --
+ *
+ * This module is for configuring CCD controller of DM6446 VPFE to capture
+ * Raw yuv or Bayer RGB data from a decoder. CCDC has several modules
+ * such as Defect Pixel Correction, Color Space Conversion etc to
+ * pre-process the Raw Bayer RGB data, before writing it to SDRAM. This
+ * module also allows application to configure individual
+ * module parameters through VPFE_CMD_S_CCDC_RAW_PARAMS IOCTL.
+ * To do so, application includes dm644x_ccdc.h and vpfe_capture.h header
+ * files.  The setparams() API is called by vpfe_capture driver
+ * to configure module parameters. This file is named DM644x so that other
+ * variants such DM6443 may be supported using the same module.
+ *
+ * TODO: Test Raw bayer parameter settings and bayer capture
+ *  Split module parameter structure to module specific ioctl structs
+ *  investigate if enum used for user space type definition
+ *  to be replaced by #defines or integer
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "dm644x_ccdc_regs.h"
+#include "ccdc_hw_device.h"
+
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("CCDC Driver for DM6446");
+MODULE_AUTHOR("Texas Instruments");
+
+static struct device *dev;
+
+/* Object for CCDC raw mode */
+static struct ccdc_params_raw ccdc_hw_params_raw = {
+   .pix_fmt = CCDC_PIXFMT_RAW,
+   .frm_fmt = CCDC_FRMFMT_PROGRESSIVE,
+   .win = CCDC_WIN_VGA,
+   .fid_pol = VPFE_PINPOL_POSITIVE,
+   .vd_pol = VPFE_PINPOL_POSITIVE,
+   .hd_pol = VPFE_PINPOL_POSITIVE,
+   .config_params = {
+   .data_sz = CCDC_DATA_10BITS,
+   },
+};
+
+/* Object for CCDC ycbcr mode */
+static struct ccdc_params_ycbcr ccdc_hw_params_ycbcr = {
+   .pix_fmt = CCDC_PIXFMT_YCBCR_8BIT,
+   .frm_fmt = CCDC_FRMFMT_INTERLACED,
+   .win = CCDC_WIN_PAL,
+   .fid_pol = VPFE_PINPOL_POSITIVE,
+   .vd_pol = VPFE_PINPOL_POSITIVE,
+   .hd_pol = VPFE_PINPOL_POSITIVE,
+   .bt656_enable = 1,
+   .pix_order = CCDC_PIXORDER_CBYCRY,
+   .buf_type = CCDC_BUFTYPE_FLD_INTERLEAVED
+};
+
+#define CCDC_MAX_RAW_YUV_FORMATS   2
+
+/* Raw Bayer formats */
+static u32 ccdc_raw_bayer_pix_formats[] =
+   {V4L2_PIX_FMT_SBGGR8, V4L2_PIX_FMT_SBGGR16};
+
+/* Raw YUV formats */
+static u32 ccdc_raw_yuv_pix_formats[] =
+   {V4L2_PIX_FMT_UYVY, V4L2_PIX_FMT_YUYV};
+
+static void *__iomem ccdc_base_addr;
+static int ccdc_addr_size;
+static enum vpfe_hw_if_type ccdc_if_type;
+
+/* register access routines */
+static inline u32 regr(u32 offset)
+{
+   return __raw_readl(ccdc_base_addr + offset);
+}
+
+static inline void regw(u32 val, u32 offset)
+{
+   __raw_writel(val, ccdc_base_addr + offset);
+}
+
+static void ccdc_set_ccdc_base(void *addr, int size)
+{
+   ccdc_base_addr = addr;
+   ccdc_addr_size = size;
+}
+
+static void ccdc_enable(int flag)
+{
+   regw(flag, CCDC_PCR);
+}
+
+static void ccdc_enable_vport(int flag)
+{
+   if (flag)
+   /* enable video port */
+   regw(CCDC_ENABLE_VIDEO_PO

[PATCH 9/11 - v3] common vpss module for video drivers

2009-06-17 Thread m-karicheri2
From: Muralidharan Karicheri 

common voss module for video drivers

This is a new module added for vpss library functions that are
used for configuring vpss system module. All video drivers will
include vpss.h header file and call functions defined in this
module to configure vpss system module.

Following are the updates:-
1) added module owner, description and GPL macros
2) some error conditions addressed in the probe

Reviewed by: Hans Verkuil 
Reviewed by: Laurent Pinchart 
Reviewed by: Alexey Klimov 

Signed-off-by: Muralidharan Karicheri 
---
Applies to v4l-dvb repository

 drivers/media/video/davinci/vpss.c |  301 
 include/media/davinci/vpss.h   |   69 
 2 files changed, 370 insertions(+), 0 deletions(-)
 create mode 100644 drivers/media/video/davinci/vpss.c
 create mode 100644 include/media/davinci/vpss.h

diff --git a/drivers/media/video/davinci/vpss.c 
b/drivers/media/video/davinci/vpss.c
new file mode 100644
index 000..6d709ca
--- /dev/null
+++ b/drivers/media/video/davinci/vpss.c
@@ -0,0 +1,301 @@
+/*
+ * Copyright (C) 2009 Texas Instruments.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ *
+ * common vpss driver for all video drivers.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("VPSS Driver");
+MODULE_AUTHOR("Texas Instruments");
+
+/* DM644x defines */
+#define DM644X_SBL_PCR_VPSS(4)
+
+/* vpss BL register offsets */
+#define DM355_VPSSBL_CCDCMUX   0x1c
+/* vpss CLK register offsets */
+#define DM355_VPSSCLK_CLKCTRL  0x04
+/* masks and shifts */
+#define VPSS_HSSISEL_SHIFT 4
+
+/*
+ * vpss operations. Depends on platform. Not all functions are available
+ * on all platforms. The api, first check if a functio is available before
+ * invoking it. In the probe, the function ptrs are intialized based on
+ * vpss name. vpss name can be "dm355_vpss", "dm644x_vpss" etc.
+ */
+struct vpss_hw_ops {
+   /* enable clock */
+   int (*enable_clock)(enum vpss_clock_sel clock_sel, int en);
+   /* select input to ccdc */
+   void (*select_ccdc_source)(enum vpss_ccdc_source_sel src_sel);
+   /* clear wbl overlflow bit */
+   int (*clear_wbl_overflow)(enum vpss_wbl_sel wbl_sel);
+};
+
+/* vpss configuration */
+struct vpss_oper_config {
+   __iomem void *vpss_bl_regs_base;
+   __iomem void *vpss_regs_base;
+   struct resource *r1;
+   resource_size_t len1;
+   struct resource *r2;
+   resource_size_t len2;
+   char vpss_name[32];
+   spinlock_t vpss_lock;
+   struct vpss_hw_ops hw_ops;
+};
+
+static struct vpss_oper_config oper_cfg;
+
+/* register access routines */
+static inline u32 bl_regr(u32 offset)
+{
+   return __raw_readl(oper_cfg.vpss_bl_regs_base + offset);
+}
+
+static inline void bl_regw(u32 val, u32 offset)
+{
+   __raw_writel(val, oper_cfg.vpss_bl_regs_base + offset);
+}
+
+static inline u32 vpss_regr(u32 offset)
+{
+   return __raw_readl(oper_cfg.vpss_regs_base + offset);
+}
+
+static inline void vpss_regw(u32 val, u32 offset)
+{
+   __raw_writel(val, oper_cfg.vpss_regs_base + offset);
+}
+
+static void dm355_select_ccdc_source(enum vpss_ccdc_source_sel src_sel)
+{
+   bl_regw(src_sel << VPSS_HSSISEL_SHIFT, DM355_VPSSBL_CCDCMUX);
+}
+
+int vpss_select_ccdc_source(enum vpss_ccdc_source_sel src_sel)
+{
+   if (!oper_cfg.hw_ops.select_ccdc_source)
+   return -1;
+
+   dm355_select_ccdc_source(src_sel);
+   return 0;
+}
+EXPORT_SYMBOL(vpss_select_ccdc_source);
+
+static int dm644x_clear_wbl_overflow(enum vpss_wbl_sel wbl_sel)
+{
+   u32 mask = 1, val;
+
+   if (wbl_sel < VPSS_PCR_AEW_WBL_0 ||
+   wbl_sel > VPSS_PCR_CCDC_WBL_O)
+   return -1;
+
+   /* writing a 0 clear the overflow */
+   mask = ~(mask << wbl_sel);
+   val = bl_regr(DM644X_SBL_PCR_VPSS) & mask;
+   bl_regw(val, DM644X_SBL_PCR_VPSS);
+   return 0;
+}
+
+int vpss_clear_wbl_overflow(enum vpss_wbl_sel wbl_sel)
+{
+   if (!oper_cfg.hw_ops.clear_wbl_overflow)
+   return -1;
+
+   return oper_cfg.hw_ops.clear_wbl_overflow(wbl_sel);
+}
+EXPORT_SYMBOL(vpss

[PATCH 7/11 - v3] DM355 platform changes for vpfe capture driver

2009-06-17 Thread m-karicheri2
From: Muralidharan Karicheri 

DM355 platform and board setup

This has platform and board setup changes to support vpfe capture
driver for DM355 EVMs.

summary of changes
1) replaced v4l2_routing structure with vpfe structure for route
2) ccdc bus parameter settings added
3) input name string changed to Composite and S-Video
 
Reviewed by: Hans Verkuil 
Reviewed by: Laurent Pinchart 
Reviewed by: Kevin Hilman 
Reviewed by: David Brownell 

Signed-off-by: Muralidharan Karicheri 
---
Applies to Davinci GIT Tree

 arch/arm/mach-davinci/board-dm355-evm.c|   76 -
 arch/arm/mach-davinci/dm355.c  |   83 
 arch/arm/mach-davinci/include/mach/dm355.h |2 +
 arch/arm/mach-davinci/include/mach/mux.h   |9 +++
 4 files changed, 167 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-davinci/board-dm355-evm.c 
b/arch/arm/mach-davinci/board-dm355-evm.c
index 5ac2f56..513be53 100644
--- a/arch/arm/mach-davinci/board-dm355-evm.c
+++ b/arch/arm/mach-davinci/board-dm355-evm.c
@@ -20,6 +20,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 
@@ -134,12 +136,22 @@ static void dm355evm_mmcsd_gpios(unsigned gpio)
dm355evm_mmc_gpios = gpio;
 }
 
+static struct tvp514x_platform_data tvp5146_pdata = {
+   .clk_polarity = 0,
+   .hs_polarity = 1,
+   .vs_polarity = 1
+};
+
 static struct i2c_board_info dm355evm_i2c_info[] = {
-   { I2C_BOARD_INFO("dm355evm_msp", 0x25),
+   {   I2C_BOARD_INFO("dm355evm_msp", 0x25),
.platform_data = dm355evm_mmcsd_gpios,
-   /* plus irq */ },
+   },
+   {
+   I2C_BOARD_INFO("tvp5146", 0x5d),
+   .platform_data = &tvp5146_pdata,
+   },
+   /* { plus irq  }, */
/* { I2C_BOARD_INFO("tlv320aic3x", 0x1b), }, */
-   /* { I2C_BOARD_INFO("tvp5146", 0x5d), }, */
 };
 
 static void __init evm_init_i2c(void)
@@ -178,6 +190,62 @@ static struct platform_device dm355evm_dm9000 = {
.num_resources  = ARRAY_SIZE(dm355evm_dm9000_rsrc),
 };
 
+#define TVP514X_STD_ALL(V4L2_STD_NTSC | V4L2_STD_PAL)
+/* Inputs available at the TVP5146 */
+static struct v4l2_input tvp5146_inputs[] = {
+   {
+   .index = 0,
+   .name = "Composite",
+   .type = V4L2_INPUT_TYPE_CAMERA,
+   .std = TVP514X_STD_ALL,
+   },
+   {
+   .index = 1,
+   .name = "S-Video",
+   .type = V4L2_INPUT_TYPE_CAMERA,
+   .std = TVP514X_STD_ALL,
+   },
+};
+
+/*
+ * this is the route info for connecting each input to decoder
+ * ouput that goes to vpfe. There is a one to one correspondence
+ * with tvp5146_inputs
+ */
+static struct vpfe_route tvp5146_routes[] = {
+   {
+   .input = INPUT_CVBS_VI2B,
+   .output = OUTPUT_10BIT_422_EMBEDDED_SYNC,
+   },
+   {
+   .input = INPUT_SVIDEO_VI2C_VI1C,
+   .output = OUTPUT_10BIT_422_EMBEDDED_SYNC,
+   },
+};
+
+static struct vpfe_subdev_info vpfe_sub_devs[] = {
+   {
+   .name = "tvp5146",
+   .grp_id = 0,
+   .num_inputs = ARRAY_SIZE(tvp5146_inputs),
+   .inputs = tvp5146_inputs,
+   .routes = tvp5146_routes,
+   .can_route = 1,
+   .ccdc_if_params = {
+   .if_type = VPFE_BT656,
+   .hdpol = VPFE_PINPOL_POSITIVE,
+   .vdpol = VPFE_PINPOL_POSITIVE,
+   },
+   }
+};
+
+static struct vpfe_config vpfe_cfg = {
+   .num_subdevs = ARRAY_SIZE(vpfe_sub_devs),
+   .sub_devs = vpfe_sub_devs,
+   .card_name = "DM355 EVM",
+   .ccdc = "DM355 CCDC",
+};
+
 static struct platform_device *davinci_evm_devices[] __initdata = {
&dm355evm_dm9000,
&davinci_nand_device,
@@ -189,6 +257,8 @@ static struct davinci_uart_config uart_config __initdata = {
 
 static void __init dm355_evm_map_io(void)
 {
+   /* setup input configuration for VPFE input devices */
+   dm355_set_vpfe_config(&vpfe_cfg);
dm355_init();
 }
 
diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c
index f0b10b4..7a7b020 100644
--- a/arch/arm/mach-davinci/dm355.c
+++ b/arch/arm/mach-davinci/dm355.c
@@ -481,6 +481,14 @@ INT_CFG(DM355,  INT_EDMA_TC1_ERR, 4,1,1, 
false)
 EVT_CFG(DM355,  EVT8_ASP1_TX,0,1,0, false)
 EVT_CFG(DM355,  EVT9_ASP1_RX,1,1,0, false)
 EVT_CFG(DM355,  EVT26_MMC0_RX,   2,1,0, false)
+
+MUX_CFG(DM355, VIN_PCLK,   0,   14,1,1, false)
+MUX_CFG(DM355, VIN_CAM_WEN,0,   13,1,1, false)
+MUX_CFG(DM355, VIN_CAM_VD, 0,   12,1,1, false)
+MUX_CFG(DM355, VIN_CAM_HD, 0,   11,1,1, false)
+MUX_CFG(DM355, VIN_YIN_EN, 0,   10,1,1, false)
+MUX_CFG(DM355, VIN_CINL_EN,  

[PATCH 3/11 - v3] dm355 ccdc module for vpfe capture driver

2009-06-17 Thread m-karicheri2
From: Muralidharan Karicheri 

DM355 CCDC hw module

Adds ccdc hw module for DM355 CCDC. This registers with the bridge
driver a set of hw_ops for configuring the CCDC for a specific
decoder device connected to vpfe.

The module description and owner information added

Reviewed by: Hans Verkuil 
Reviewed by: Laurent Pinchart 

Signed-off-by: Muralidharan Karicheri 
---
Applies to v4l-dvb repository

 drivers/media/video/davinci/dm355_ccdc.c  | 1163 +
 drivers/media/video/davinci/dm355_ccdc_regs.h |  310 +++
 include/media/davinci/dm355_ccdc.h|  336 +++
 3 files changed, 1809 insertions(+), 0 deletions(-)
 create mode 100644 drivers/media/video/davinci/dm355_ccdc.c
 create mode 100644 drivers/media/video/davinci/dm355_ccdc_regs.h
 create mode 100644 include/media/davinci/dm355_ccdc.h

diff --git a/drivers/media/video/davinci/dm355_ccdc.c 
b/drivers/media/video/davinci/dm355_ccdc.c
new file mode 100644
index 000..69e38d0
--- /dev/null
+++ b/drivers/media/video/davinci/dm355_ccdc.c
@@ -0,0 +1,1163 @@
+/*
+ * Copyright (C) 2005-2009 Texas Instruments Inc
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ *
+ * CCDC hardware module for DM355
+ * --
+ *
+ * This module is for configuring DM355 CCD controller of VPFE to capture
+ * Raw yuv or Bayer RGB data from a decoder. CCDC has several modules
+ * such as Defect Pixel Correction, Color Space Conversion etc to
+ * pre-process the Bayer RGB data, before writing it to SDRAM. This
+ * module also allows application to configure individual
+ * module parameters through VPFE_CMD_S_CCDC_RAW_PARAMS IOCTL.
+ * To do so, application include dm355_ccdc.h and vpfe_capture.h header
+ * files. The setparams() API is called by vpfe_capture driver
+ * to configure module parameters
+ *
+ * TODO: 1) Raw bayer parameter settings and bayer capture
+ *  2) Split module parameter structure to module specific ioctl structs
+ *  3) add support for lense shading correction
+ *  4) investigate if enum used for user space type definition
+ * to be replaced by #defines or integer
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "dm355_ccdc_regs.h"
+#include "ccdc_hw_device.h"
+
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("CCDC Driver for DM355");
+MODULE_AUTHOR("Texas Instruments");
+
+static struct device *dev;
+
+/* Object for CCDC raw mode */
+static struct ccdc_params_raw ccdc_hw_params_raw = {
+   .pix_fmt = CCDC_PIXFMT_RAW,
+   .frm_fmt = CCDC_FRMFMT_PROGRESSIVE,
+   .win = CCDC_WIN_VGA,
+   .fid_pol = VPFE_PINPOL_POSITIVE,
+   .vd_pol = VPFE_PINPOL_POSITIVE,
+   .hd_pol = VPFE_PINPOL_POSITIVE,
+   .gain = {
+   .r_ye = 256,
+   .gb_g = 256,
+   .gr_cy = 256,
+   .b_mg = 256
+   },
+   .config_params = {
+   .datasft = 2,
+   .data_sz = CCDC_DATA_10BITS,
+   .mfilt1 = CCDC_NO_MEDIAN_FILTER1,
+   .mfilt2 = CCDC_NO_MEDIAN_FILTER2,
+   .alaw = {
+   .gama_wd = 2,
+   },
+   .blk_clamp = {
+   .sample_pixel = 1,
+   .dc_sub = 25
+   },
+   .col_pat_field0 = {
+   .olop = CCDC_GREEN_BLUE,
+   .olep = CCDC_BLUE,
+   .elop = CCDC_RED,
+   .elep = CCDC_GREEN_RED
+   },
+   .col_pat_field1 = {
+   .olop = CCDC_GREEN_BLUE,
+   .olep = CCDC_BLUE,
+   .elop = CCDC_RED,
+   .elep = CCDC_GREEN_RED
+   },
+   },
+};
+
+
+/* Object for CCDC ycbcr mode */
+static struct ccdc_params_ycbcr ccdc_hw_params_ycbcr = {
+   .win = CCDC_WIN_PAL,
+   .pix_fmt = CCDC_PIXFMT_YCBCR_8BIT,
+   .frm_fmt = CCDC_FRMFMT_INTERLACED,
+   .fid_pol = VPFE_PINPOL_POSITIVE,
+   .vd_pol = VPFE_PINPOL_POSITIVE,
+   .hd_pol = VPFE_PINPOL_POSITIVE,
+   .bt656_enable = 1,
+   .pix_order = CCDC_PIXORDER_CBYCRY,
+   .buf_type = CCDC_BUFTYPE_FLD_INTERLEAVED
+};
+
+static struct v4l2_queryctrl ccdc_control_info[] = {
+   {
+   .id = CCDC_CID_R_GAIN,

[PATCH 5/11 - v3] ccdc types used across ccdc modules for vpfe capture driver

2009-06-17 Thread m-karicheri2
From: Muralidharan Karicheri 

common types used across CCDC modules

No change from last version

Reviewed by: Hans Verkuil 
Reviewed by: Laurent Pinchart 

Signed-off-by: Muralidharan Karicheri 
---
Applies to v4l-dvb repository

 include/media/davinci/ccdc_types.h |   43 
 1 files changed, 43 insertions(+), 0 deletions(-)
 create mode 100644 include/media/davinci/ccdc_types.h

diff --git a/include/media/davinci/ccdc_types.h 
b/include/media/davinci/ccdc_types.h
new file mode 100644
index 000..5773874
--- /dev/null
+++ b/include/media/davinci/ccdc_types.h
@@ -0,0 +1,43 @@
+/*
+ * Copyright (C) 2008-2009 Texas Instruments Inc
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307 USA
+ *
+ **/
+#ifndef _CCDC_TYPES_H
+#define _CCDC_TYPES_H
+enum ccdc_pixfmt {
+   CCDC_PIXFMT_RAW,
+   CCDC_PIXFMT_YCBCR_16BIT,
+   CCDC_PIXFMT_YCBCR_8BIT
+};
+
+enum ccdc_frmfmt {
+   CCDC_FRMFMT_PROGRESSIVE,
+   CCDC_FRMFMT_INTERLACED
+};
+
+/* PIXEL ORDER IN MEMORY from LSB to MSB */
+/* only applicable for 8-bit input mode  */
+enum ccdc_pixorder {
+   CCDC_PIXORDER_YCBYCR,
+   CCDC_PIXORDER_CBYCRY,
+};
+
+enum ccdc_buftype {
+   CCDC_BUFTYPE_FLD_INTERLEAVED,
+   CCDC_BUFTYPE_FLD_SEPARATED
+};
+#endif
-- 
1.6.0.4

--
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 2/11 - v3] ccdc hw device header file for vpfe capture

2009-06-17 Thread m-karicheri2
From: Muralidharan Karicheri 

CCDC hw device header file

Adds ccdc hw device header for vpfe capture driver

No change from last version

Reviewed by: Hans Verkuil 
Reviewed by: Laurent Pinchart 

Signed-off-by: Muralidharan Karicheri 
---
Applies to v4l-dvb repository

 drivers/media/video/davinci/ccdc_hw_device.h |  110 ++
 1 files changed, 110 insertions(+), 0 deletions(-)
 create mode 100644 drivers/media/video/davinci/ccdc_hw_device.h

diff --git a/drivers/media/video/davinci/ccdc_hw_device.h 
b/drivers/media/video/davinci/ccdc_hw_device.h
new file mode 100644
index 000..86b9b35
--- /dev/null
+++ b/drivers/media/video/davinci/ccdc_hw_device.h
@@ -0,0 +1,110 @@
+/*
+ * Copyright (C) 2008-2009 Texas Instruments Inc
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ *
+ * ccdc device API
+ */
+#ifndef _CCDC_HW_DEVICE_H
+#define _CCDC_HW_DEVICE_H
+
+#ifdef __KERNEL__
+#include 
+#include 
+#include 
+#include 
+
+/*
+ * ccdc hw operations
+ */
+struct ccdc_hw_ops {
+   /* Pointer to initialize function to initialize ccdc device */
+   int (*open) (struct device *dev);
+   /* Pointer to deinitialize function */
+   int (*close) (struct device *dev);
+   /* set ccdc base address */
+   void (*set_ccdc_base)(void *base, int size);
+   /* Pointer to function to enable or disable ccdc */
+   void (*enable) (int en);
+   /* reset sbl. only for 6446 */
+   void (*reset) (void);
+   /* enable output to sdram */
+   void (*enable_out_to_sdram) (int en);
+   /* Pointer to function to set hw parameters */
+   int (*set_hw_if_params) (struct vpfe_hw_if_param *param);
+   /* get interface parameters */
+   int (*get_hw_if_params) (struct vpfe_hw_if_param *param);
+   /*
+* Pointer to function to set parameters. Used
+* for implementing VPFE_S_CCDC_PARAMS
+*/
+   int (*set_params) (void *params);
+   /*
+* Pointer to function to get parameter. Used
+* for implementing VPFE_G_CCDC_PARAMS
+*/
+   int (*get_params) (void *params);
+   /* Pointer to function to configure ccdc */
+   int (*configure) (void);
+
+   /* Pointer to function to set buffer type */
+   int (*set_buftype) (enum ccdc_buftype buf_type);
+   /* Pointer to function to get buffer type */
+   enum ccdc_buftype (*get_buftype) (void);
+   /* Pointer to function to set frame format */
+   int (*set_frame_format) (enum ccdc_frmfmt frm_fmt);
+   /* Pointer to function to get frame format */
+   enum ccdc_frmfmt (*get_frame_format) (void);
+   /* enumerate hw pix formats */
+   int (*enum_pix)(u32 *hw_pix, int i);
+   /* Pointer to function to set buffer type */
+   u32 (*get_pixel_format) (void);
+   /* Pointer to function to get pixel format. */
+   int (*set_pixel_format) (u32 pixfmt);
+   /* Pointer to function to set image window */
+   int (*set_image_window) (struct v4l2_rect *win);
+   /* Pointer to function to set image window */
+   void (*get_image_window) (struct v4l2_rect *win);
+   /* Pointer to function to get line length */
+   unsigned int (*get_line_length) (void);
+
+   /* Query CCDC control IDs */
+   int (*queryctrl)(struct v4l2_queryctrl *qctrl);
+   /* Set CCDC control */
+   int (*set_control)(struct v4l2_control *ctrl);
+   /* Get CCDC control */
+   int (*get_control)(struct v4l2_control *ctrl);
+
+   /* Pointer to function to set frame buffer address */
+   void (*setfbaddr) (unsigned long addr);
+   /* Pointer to function to get field id */
+   int (*getfid) (void);
+};
+
+struct ccdc_hw_device {
+   /* ccdc device name */
+   char name[32];
+   /* module owner */
+   struct module *owner;
+   /* hw ops */
+   struct ccdc_hw_ops hw_ops;
+};
+
+/* Used by CCDC module to register & unregister with vpfe capture driver */
+int vpfe_register_ccdc_device(struct ccdc_hw_device *dev);
+void vpfe_unregister_ccdc_device(struct ccdc_hw_device *dev);
+
+#endif
+#endif
-- 
1.6.0.4

--
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: bttv problem loading takes about several minutes

2009-06-17 Thread Hans Verkuil
On Wednesday 17 June 2009 19:11:23 Trent Piepho wrote:
> On Wed, 17 Jun 2009, Halim Sahin wrote:
> > Hi,
> > In the past I could use this card by typing
> > modprobe bttv card=34 tuner=24 gbuffers=16
>
> What card do you actually have?  What is the PCI subsystem vendor/device
> and what tuner does it actually have?
>
> Hans, the problem might be with bttv audio probing.  This card has
> needs_tvaudio set to 0, which used to mean that tvaudio would not be
> probed or loaded.  But with your changes to bttv audio probing this
> behavior has changed.  Now tvaudio is always loaded and probed if another
> audio chip hasn't been detected.  The needs_tvaudio field is totally
> ignored.

The log is from bttv version 0.9.17. The new code is only present in version 
0.9.18. So this is definitely not related to any of my changes.

The text "bttv0: gpio: en=, out= in=003ff502 [init]" comes 
from the call to bttv_gpio_tracking in bttv_probe, then the next 
text "bttv0: tuner type=24" comes from early in bttv_init_card2, before any 
i2c modules have been loaded.

The code in bttv_probe (bttv-driver.c) does this:

if (bttv_verbose)
bttv_gpio_tracking(btv,"init");

/* needs to be done before i2c is registered */
bttv_init_card1(btv);

/* register i2c + gpio */
init_bttv_i2c(btv);

/* some card-specific stuff (needs working i2c) */
bttv_init_card2(btv);

So it looks like it can be either bttv_init_card1 or init_bttv_i2c that is 
causing the delay.

Halim, can you try to put some printk() statements in between the calls 
above to see which call is taking so long? Actually, it would be nice if 
you are able to 'drill-down' as well in whatever function is causing the 
delay, since I truly don't see what might be delaying things for you.

Regards,

Hans

>
> > Giving this command with current drivers has some problems:
> > 1. it takes several minutes to load bttv module.
> > 2. capturing doesn't work any more (dropped frames etc).
> > Tested with current v4l-dvb from hg, ubuntu 9.04,
> > debian lenny.
> >
> > I have a bt878  based card from leadtek.
> >
> > Here is my output after loading the driver:
> > [ 3013.735459] bttv: driver version 0.9.17 loaded
> > [ 3013.735470] bttv: using 32 buffers with 16k (4 pages) each for
> > capture [ 3013.735542] bttv: Bt8xx card found (0).
> > [ 3013.735562] bttv0: Bt878 (rev 17) at :00:0b.0, irq: 19, latency:
> > 32, mmio
> >
> > : 0xf780
> >
> > [ 3013.737762] bttv0: using: Leadtek WinFast 2000/ WinFast 2000 XP
> > [card=34,insm od option]
> > [ 3013.737825] bttv0: gpio: en=, out= in=003ff502
> > [init] [ 3148.136017] bttv0: tuner type=24
> > [ 3148.136029] bttv0: i2c: checking for MSP34xx @ 0x80... not found
> > [ 3154.536019] bttv0: i2c: checking for TDA9875 @ 0xb0... not found
> > [ 3160.936018] bttv0: i2c: checking for TDA7432 @ 0x8a... not found
> > [ 3167.351398] bttv0: registered device video0
> > [ 3167.351434] bttv0: registered device vbi0
> > [ 3167.351463] bttv0: registered device radio0
> > [ 3167.351485] bttv0: PLL: 28636363 => 35468950 . ok
> > [ 3167.364182] input: bttv IR (card=34) as /class/input/input6
> >
> > Please help!
> > Regards
> > Halim
> >
> >
> > --
> > Halim Sahin
> > E-Mail:
> > halim.sahin (at) t-online.de
> > --
> > 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



-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom
--
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: bttv problem loading takes about several minutes

2009-06-17 Thread Halim Sahin
Hi,
The card is a
winfast tv 2000 xp rm edition
lspci -vvv says:

00:0b.0 Multimedia video controller: Brooktree Corporation Bt878 Video Capture 
(rev 11)
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- 
Capabilities: [4c] Power Management version 2
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA 
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Kernel driver in use: bttv
Kernel modules: bttv

00:0b.1 Multimedia controller: Brooktree Corporation Bt878 Audio Capture (rev 
11)
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- 
Capabilities: [4c] Power Management version 2
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA 
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-


HTH.
Halim

-- 
Halim Sahin
E-Mail: 
halim.sahin (at) t-online.de
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [RFC PATCH] adding support for setting bus parameters in sub device

2009-06-17 Thread Hans Verkuil
On Wednesday 17 June 2009 17:43:42 m-kariche...@ti.com wrote:
> From: Muralidharan Karicheri 
>
> This patch adds support for setting bus parameters such as bus type
> (Raw Bayer or Raw YUV image data bus), bus width (example 10 bit raw
> image data bus, 10 bit BT.656 etc.), and polarities (vsync, hsync, field
> etc) in sub device. This allows bridge driver to configure the sub device
> bus for a specific set of bus parameters through s_bus() function call.
> This also can be used to define platform specific bus parameters for
> host and sub-devices.
>
> Reviewed by: Hans Verkuil 
> Signed-off-by: Murali Karicheri 
> ---
> Applies to v4l-dvb repository
>
>  include/media/v4l2-subdev.h |   40
>  1 files changed, 40
> insertions(+), 0 deletions(-)
>
> diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
> index 1785608..2f5ec98 100644
> --- a/include/media/v4l2-subdev.h
> +++ b/include/media/v4l2-subdev.h
> @@ -37,6 +37,43 @@ struct v4l2_decode_vbi_line {
>   u32 type;   /* VBI service type (V4L2_SLICED_*). 0 if no 
> service found
> */ };
>
> +/*
> + * Some sub-devices are connected to the host/bridge device through a
> bus that + * carries the clock, vsync, hsync and data. Some interfaces
> such as BT.656 + * carries the sync embedded in the data where as others
> have separate line + * carrying the sync signals. The structure below is
> used to define bus + * configuration parameters for host as well as
> sub-device
> + */
> +enum v4l2_subdev_bus_type {
> + /* Raw YUV image data bus */
> + V4L2_SUBDEV_BUS_RAW_YUV,
> + /* Raw Bayer image data bus */
> + V4L2_SUBDEV_BUS_RAW_BAYER
> +};

Remove the _subdev prefix from the enum above.

> +
> +struct v4l2_bus_settings {
> + /* yuv or bayer image data bus */
> + enum v4l2_subdev_bus_type type;
> + /* subdev bus width */
> + u8 subdev_width;
> + /* host bus width */
> + u8 host_width;
> + /* embedded sync, set this when sync is embedded in the data stream */
> + unsigned embedded_sync:1;
> + /* master or slave */
> + unsigned host_is_master:1;
> + /* 0 - active low, 1 - active high */
> + unsigned pol_vsync:1;
> + /* 0 - active low, 1 - active high */
> + unsigned pol_hsync:1;
> + /* 0 - low to high , 1 - high to low */
> + unsigned pol_field:1;
> + /* 0 - sample at falling edge , 1 - sample at rising edge */
> + unsigned pol_pclock:1;

I'm not sure whether the pol_ prefix is correct here. Perhaps edge_pclock is 
a more appropriate name.

Regards,

Hans

> + /* 0 - active low , 1 - active high */
> + unsigned pol_data:1;
> +};
> +
>  /* Sub-devices are devices that are connected somehow to the main bridge
> device. These devices are usually audio/video
> muxers/encoders/decoders or sensors and webcam controllers.
> @@ -199,6 +236,8 @@ struct v4l2_subdev_audio_ops {
>
> s_routing: see s_routing in audio_ops, except this version is for
> video devices.
> +
> +   s_bus: set bus parameters in sub device to configure the bus
>   */
>  struct v4l2_subdev_video_ops {
>   int (*s_routing)(struct v4l2_subdev *sd, u32 input, u32 output, u32
> config); @@ -219,6 +258,7 @@ struct v4l2_subdev_video_ops {
>   int (*s_parm)(struct v4l2_subdev *sd, struct v4l2_streamparm *param);
>   int (*enum_framesizes)(struct v4l2_subdev *sd, struct v4l2_frmsizeenum
> *fsize); int (*enum_frameintervals)(struct v4l2_subdev *sd, struct
> v4l2_frmivalenum *fival); +   int (*s_bus)(struct v4l2_subdev *sd, const
> struct v4l2_bus_settings *bus); };
>
>  struct v4l2_subdev_ops {



-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 1/10 - v2] vpfe capture bridge driver for DM355 and DM6446

2009-06-17 Thread Hans Verkuil
On Wednesday 17 June 2009 17:02:01 Karicheri, Muralidharan wrote:
> >> 
> >
> >Can you post your latest proposal for the s_bus op?
> >
> >I propose a few changes: the name of the struct should be something like
> >v4l2_bus_settings, the master/slave bit should be renamed to something
> >like 'host_is_master', and we should have two widths: subdev_width and
> >host_width.
> >
> >That way the same structure can be used for both host and subdev, unless
> >some of the polarities are inverted. In that case you need to make two
> >structs, one for host and one for the subdev.
> >
> >It is possible to add info on inverters to the struct, but unless
> > inverters are used a lot more frequently than I expect I am inclined
> > not to do that at this time.
>
> [MK]Today I am planning to send my v3 version of the vpfe capture patch
> and also tvp514x patch since Vaibhav is pre-occupied with some other
> activities. I have discussed the changes with Vaibhav for this driver.
>
> For s_bus, I will try if I can send a patch today. BTW, do you expect me
> to add one bool for active high, one for active low etc as done in SoC
> camera ?

Since I remain opposed to autonegotiation, there is IMO no need for this.

Regards,

Hans

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom
--
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: OV7670: getting it working with soc-camera.

2009-06-17 Thread Guennadi Liakhovetski
On Wed, 17 Jun 2009, Jonathan Cameron wrote:

> This is purely for info of anyone else wanting to use the ov7670
> with Guennadi's recent work on converted soc-camera to v4l2-subdevs.
> 
> It may not be completely minimal, but it's letting me take pictures ;)

Cool, I like it! Not the pictures, but the fact that the required patch 
turned out to be so small. Of course, you understand this is not what 
we'll eventually commit, but, I think, this is a good start. In principle, 
if a device has all parameters fixed, there's no merit in trying to set 
them.

> Couple of minor queries:
> 
> Currently it is assumed that there is a means of telling the chip to
> use particular bus params.  In the case of this one it doesn't support
> anything other than 8 bit. Stuff may get added down the line, but
> in meantime does anyone mind if we make icd->ops->set_bus_param
> optional in soc-camera?

struct soc_camera_ops will disappear completely anyway, and we don't know 
yet what the v4l2-subdev counterpart will look like.

> Is there any reason (or advantage) in not specifying the i2c address
> in the driver?

Some i2c devices can be configured to respond to one of several i2c 
addresses.

> Or for that matter why the address is right shifted by
> 1 in:
> 
> v4l_info(client, "chip found @ 0x%02x (%s)\n",
>client->addr << 1, client->adapter->name);
> 
> Admittedly the data sheet uses an 'unusual' convention for the
> address (separate write and read address which correspond to
> a single address of 0x21 with the relevant write bit set as
> appropriate).

That's exactly the reason, I think. Many (or most?) datasheets specify i2c 
addresses which are a double of Linux i2c address. IIRC this is just a 
Linux convention to use the shifted address.

> As ever any comments welcome. Thanks to Guennadi Liakhovetski
> for his soc-camera work and Hans Verkuil for conversion of the
> ov7670 to soc-dev.
> 
> Tested against a merge of todays v4l-next tree and Linus' current
> with the minor pxa-camera bug I posted earlier fixed and Guennadi's
> extensive patch set applied (this requires a few hand merges, but
> nothing too nasty).

Good to know.

A couple of comments:

> diff --git a/include/media/ov7670_soc.h b/include/media/ov7670_soc.h
> new file mode 100644
> index 000..2f264b2
> --- /dev/null
> +++ b/include/media/ov7670_soc.h
> @@ -0,0 +1,21 @@
> +/* ov7670_soc Camera
> + *
> + * Copyright (C) 2009 Jonathan Cameron 
> + *
> + * 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.
> + */
> +
> +#ifndef __OV7670_SOC_H__
> +#define __OV7670_SOC_H__
> +
> +#include 
> +
> +struct ov7670_soc_camera_info {
> + int gpio_pwr;
> + int gpio_reset;

You should not need these GPIOs...

> + struct soc_camera_link link;
> +};
> +
> +#endif
> diff --git a/drivers/media/video/ov7670.c b/drivers/media/video/ov7670.c
> index 0e2184e..51d432e 100644
> --- a/drivers/media/video/ov7670.c
> +++ b/drivers/media/video/ov7670.c
> @@ -19,7 +19,14 @@
>  #include 
>  #include 
>  
> +#define OV7670_SOC
>  
> +
> +#ifdef OV7670_SOC
> +#include 
> +#include 
> +#include 

...this header...

> +#endif /* OV7670_SOC */
>  MODULE_AUTHOR("Jonathan Corbet ");
>  MODULE_DESCRIPTION("A low-level driver for OmniVision ov7670 sensors");
>  MODULE_LICENSE("GPL");
> @@ -1239,19 +1246,94 @@ static const struct v4l2_subdev_ops ov7670_ops = {
>  };
>  
>  /* --- */
> +#ifdef OV7670_SOC
> +
> +static unsigned long ov7670_soc_query_bus_param(struct soc_camera_device 
> *icd)
> +{
> + struct soc_camera_link *icl = to_soc_camera_link(icd);
> +
> + unsigned long flags = SOCAM_PCLK_SAMPLE_RISING | SOCAM_MASTER |
> + SOCAM_VSYNC_ACTIVE_HIGH | SOCAM_HSYNC_ACTIVE_HIGH |
> + SOCAM_DATAWIDTH_8 | SOCAM_DATA_ACTIVE_HIGH;
> +
> + return soc_camera_apply_sensor_flags(icl, flags);
> +}
> +/* This device only supports one bus option */
> +static int ov7670_soc_set_bus_param(struct soc_camera_device *icd,
> + unsigned long flags)
> +{
> + return 0;
> +}
> +
> +static struct soc_camera_ops ov7670_soc_ops = {
> + .set_bus_param = ov7670_soc_set_bus_param,
> + .query_bus_param = ov7670_soc_query_bus_param,
> +};
> +
> +#define SETFOURCC(type) .name = (#type), .fourcc = (V4L2_PIX_FMT_ ## type)
> +static const struct soc_camera_data_format ov7670_soc_fmt_lists[] = {
> + {
> + SETFOURCC(YUYV),
> + .depth = 16,
> + .colorspace = V4L2_COLORSPACE_JPEG,
> + }, {
> + SETFOURCC(RGB565),
> + .depth = 16,
> + .colorspace = V4L2_COLORSPACE_SRGB,
> + },
> +};
>  
> +#endif
>  static int ov7670_probe(struct i2c_client *client,
>   const struct i2c_device_id *id)
>  {
> +#ifdef OV7670_SOC
> + stru

Re: Convert cpia driver to v4l2, drop parallel port version support?

2009-06-17 Thread Hans de Goede



On 06/17/2009 08:11 PM, Brian Johnson wrote:

Hans de Goede wrote:

sn9c102
Supports a large number of cams also supported by gspca's sonixb / sonixj 
driver, we're using
#ifdef  macros to detect if both are being build at the same time to 
include usb-id's only
in one of the 2.

Btw, it would be interesting to work with the out-of-tree microdia driver,
since there are some models that are supported only by the alternative driver.

Ack, only one small problem, which is another reason why Luca's drivers should 
slowly be phased
out, Luca has gone closed source with his sn9cxxx driver.

There is an out of tree driver for the new sn9c2xx models you talk about 
though, with active
developers, I've pushing them to get it into the mainline, I'll give it another 
try soonish.



Hello I'm one of the developers for the current out of tree sn9c20x driver.  
What needs to be done in order
to get the sn9c20x code into the mainline? Am i right in assuming it would be 
preferred to move the code into
a sn9c20x gspca subdriver rather then include the complete out of tree driver?


Yes that would be very much prefered. Not that I believe that gspca is the
best thing ever invented or anything like that. But usb webcam drivers all have 
a lot in
common and gspca handles that good enough, and if we ever want to make 
improvements like
moving usb webcams to use videobuf, having them all as gspca sub drivers means 
we only
need to do it once, as for example all buffer management is done by gspca.

Also after looking at the pwc driver oops at unplug, and being reminded at the 
ref counting
with hotplug devices going away and locking nightmare stuff we discussed some 
time ago,
I'm also really glad to only have all that tricky code only once.

This will also make reviewing a lot easier as there will be no tricky buffer 
management
and locking, etc. to review.

> If this is the case I can work
> on a set of patches to implement our code as a gspca subdriver.
>

As explained above very much: "Yes please"


Also i have a few questions regarding submitting the patches.

1) In addition to sending them to linux-media should I CC them to anyone in 
particular?


I have such a cam and I'm one of the people actively working on gspca, so if 
you could CC
me then I'm sure to notice it and review it, and it can get merged through my 
mercurial
(git alike vcs) tree.


2) The entire patch would likely be about 70k. Should I just send one patch or 
split the
thing up into several?


I would hope gspca would shrink the size somewhat :) As for one patch versus 
incremental
patches, as this is a whole new driver one patch will do I guess, I see little 
use in having
non working increments in between.

Thanks & Regards,

Hans
--
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


[cron job] v4l-dvb daily build 2.6.22 and up: WARNINGS, 2.6.16-2.6.21: ERRORS

2009-06-17 Thread Hans Verkuil
This message is generated daily by a cron job that builds v4l-dvb for
the kernels and architectures in the list below.

Results of the daily build of v4l-dvb:

date:Wed Jun 17 19:00:05 CEST 2009
path:http://www.linuxtv.org/hg/v4l-dvb
changeset:   12010:b385a43af222
gcc version: gcc (GCC) 4.3.1
hardware:x86_64
host os: 2.6.26

linux-2.6.22.19-armv5: OK
linux-2.6.23.12-armv5: OK
linux-2.6.24.7-armv5: OK
linux-2.6.25.11-armv5: OK
linux-2.6.26-armv5: OK
linux-2.6.27-armv5: WARNINGS
linux-2.6.28-armv5: WARNINGS
linux-2.6.29.1-armv5: OK
linux-2.6.30-armv5: OK
linux-2.6.27-armv5-ixp: WARNINGS
linux-2.6.28-armv5-ixp: WARNINGS
linux-2.6.29.1-armv5-ixp: WARNINGS
linux-2.6.30-armv5-ixp: WARNINGS
linux-2.6.28-armv5-omap2: WARNINGS
linux-2.6.29.1-armv5-omap2: WARNINGS
linux-2.6.30-armv5-omap2: WARNINGS
linux-2.6.22.19-i686: OK
linux-2.6.23.12-i686: WARNINGS
linux-2.6.24.7-i686: WARNINGS
linux-2.6.25.11-i686: WARNINGS
linux-2.6.26-i686: WARNINGS
linux-2.6.27-i686: WARNINGS
linux-2.6.28-i686: WARNINGS
linux-2.6.29.1-i686: WARNINGS
linux-2.6.30-i686: WARNINGS
linux-2.6.23.12-m32r: OK
linux-2.6.24.7-m32r: OK
linux-2.6.25.11-m32r: OK
linux-2.6.26-m32r: OK
linux-2.6.27-m32r: OK
linux-2.6.28-m32r: OK
linux-2.6.29.1-m32r: OK
linux-2.6.30-m32r: OK
linux-2.6.30-mips: WARNINGS
linux-2.6.27-powerpc64: WARNINGS
linux-2.6.28-powerpc64: WARNINGS
linux-2.6.29.1-powerpc64: WARNINGS
linux-2.6.30-powerpc64: WARNINGS
linux-2.6.22.19-x86_64: OK
linux-2.6.23.12-x86_64: OK
linux-2.6.24.7-x86_64: OK
linux-2.6.25.11-x86_64: OK
linux-2.6.26-x86_64: OK
linux-2.6.27-x86_64: OK
linux-2.6.28-x86_64: OK
linux-2.6.29.1-x86_64: OK
linux-2.6.30-x86_64: WARNINGS
sparse (linux-2.6.30): OK
linux-2.6.16.61-i686: ERRORS
linux-2.6.17.14-i686: ERRORS
linux-2.6.18.8-i686: ERRORS
linux-2.6.19.5-i686: OK
linux-2.6.20.21-i686: OK
linux-2.6.21.7-i686: OK
linux-2.6.16.61-x86_64: ERRORS
linux-2.6.17.14-x86_64: ERRORS
linux-2.6.18.8-x86_64: ERRORS
linux-2.6.19.5-x86_64: OK
linux-2.6.20.21-x86_64: OK
linux-2.6.21.7-x86_64: OK

Detailed results are available here:

http://www.xs4all.nl/~hverkuil/logs/Wednesday.log

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Wednesday.tar.bz2

The V4L2 specification failed to build, but the last compiled spec is here:

http://www.xs4all.nl/~hverkuil/spec/v4l2.html

The DVB API specification from this daily build is here:

http://www.xs4all.nl/~hverkuil/spec/dvbapi.pdf

--
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: Convert cpia driver to v4l2, drop parallel port version support?

2009-06-17 Thread Brian Johnson
Hans de Goede wrote:
>>> sn9c102
>>> Supports a large number of cams also supported by gspca's sonixb / sonixj 
>>> driver, we're using
>>> #ifdef  macros to detect if both are being build at the same time to 
>>> include usb-id's only
>>> in one of the 2.
>> Btw, it would be interesting to work with the out-of-tree microdia driver,
>> since there are some models that are supported only by the alternative 
>> driver.
> 
> Ack, only one small problem, which is another reason why Luca's drivers 
> should slowly be phased
> out, Luca has gone closed source with his sn9cxxx driver.
> 
> There is an out of tree driver for the new sn9c2xx models you talk about 
> though, with active
> developers, I've pushing them to get it into the mainline, I'll give it 
> another try soonish.
> 

Hello I'm one of the developers for the current out of tree sn9c20x driver.  
What needs to be done in order
to get the sn9c20x code into the mainline? Am i right in assuming it would be 
preferred to move the code into 
a sn9c20x gspca subdriver rather then include the complete out of tree driver? 
If this is the case I can work
on a set of patches to implement our code as a gspca subdriver.

Also i have a few questions regarding submitting the patches.

1) In addition to sending them to linux-media should I CC them to anyone in 
particular?
2) The entire patch would likely be about 70k. Should I just send one patch or 
split the
thing up into several?

Thanks,
Brian

> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


OV7670: getting it working with soc-camera.

2009-06-17 Thread Jonathan Cameron
This is purely for info of anyone else wanting to use the ov7670
with Guennadi's recent work on converted soc-camera to v4l2-subdevs.

It may not be completely minimal, but it's letting me take pictures ;)

Couple of minor queries:

Currently it is assumed that there is a means of telling the chip to
use particular bus params.  In the case of this one it doesn't support
anything other than 8 bit. Stuff may get added down the line, but
in meantime does anyone mind if we make icd->ops->set_bus_param
optional in soc-camera?

Is there any reason (or advantage) in not specifying the i2c address
in the driver? Or for that matter why the address is right shifted by
1 in:

v4l_info(client, "chip found @ 0x%02x (%s)\n",
 client->addr << 1, client->adapter->name);

Admittedly the data sheet uses an 'unusual' convention for the
address (separate write and read address which correspond to
a single address of 0x21 with the relevant write bit set as
appropriate).

As ever any comments welcome. Thanks to Guennadi Liakhovetski
for his soc-camera work and Hans Verkuil for conversion of the
ov7670 to soc-dev.

Tested against a merge of todays v4l-next tree and Linus' current
with the minor pxa-camera bug I posted earlier fixed and Guennadi's
extensive patch set applied (this requires a few hand merges, but
nothing too nasty).

---

diff --git a/include/media/ov7670_soc.h b/include/media/ov7670_soc.h
new file mode 100644
index 000..2f264b2
--- /dev/null
+++ b/include/media/ov7670_soc.h
@@ -0,0 +1,21 @@
+/* ov7670_soc Camera
+ *
+ * Copyright (C) 2009 Jonathan Cameron 
+ *
+ * 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.
+ */
+
+#ifndef __OV7670_SOC_H__
+#define __OV7670_SOC_H__
+
+#include 
+
+struct ov7670_soc_camera_info {
+   int gpio_pwr;
+   int gpio_reset;
+   struct soc_camera_link link;
+};
+
+#endif
diff --git a/drivers/media/video/ov7670.c b/drivers/media/video/ov7670.c
index 0e2184e..51d432e 100644
--- a/drivers/media/video/ov7670.c
+++ b/drivers/media/video/ov7670.c
@@ -19,7 +19,14 @@
 #include 
 #include 
 
+#define OV7670_SOC
 
+
+#ifdef OV7670_SOC
+#include 
+#include 
+#include 
+#endif /* OV7670_SOC */
 MODULE_AUTHOR("Jonathan Corbet ");
 MODULE_DESCRIPTION("A low-level driver for OmniVision ov7670 sensors");
 MODULE_LICENSE("GPL");
@@ -1239,19 +1246,94 @@ static const struct v4l2_subdev_ops ov7670_ops = {
 };
 
 /* --- */
+#ifdef OV7670_SOC
+
+static unsigned long ov7670_soc_query_bus_param(struct soc_camera_device *icd)
+{
+   struct soc_camera_link *icl = to_soc_camera_link(icd);
+
+   unsigned long flags = SOCAM_PCLK_SAMPLE_RISING | SOCAM_MASTER |
+   SOCAM_VSYNC_ACTIVE_HIGH | SOCAM_HSYNC_ACTIVE_HIGH |
+   SOCAM_DATAWIDTH_8 | SOCAM_DATA_ACTIVE_HIGH;
+
+   return soc_camera_apply_sensor_flags(icl, flags);
+}
+/* This device only supports one bus option */
+static int ov7670_soc_set_bus_param(struct soc_camera_device *icd,
+   unsigned long flags)
+{
+   return 0;
+}
+
+static struct soc_camera_ops ov7670_soc_ops = {
+   .set_bus_param = ov7670_soc_set_bus_param,
+   .query_bus_param = ov7670_soc_query_bus_param,
+};
+
+#define SETFOURCC(type) .name = (#type), .fourcc = (V4L2_PIX_FMT_ ## type)
+static const struct soc_camera_data_format ov7670_soc_fmt_lists[] = {
+   {
+   SETFOURCC(YUYV),
+   .depth = 16,
+   .colorspace = V4L2_COLORSPACE_JPEG,
+   }, {
+   SETFOURCC(RGB565),
+   .depth = 16,
+   .colorspace = V4L2_COLORSPACE_SRGB,
+   },
+};
 
+#endif
 static int ov7670_probe(struct i2c_client *client,
const struct i2c_device_id *id)
 {
+#ifdef OV7670_SOC
+   struct soc_camera_device *icd = client->dev.platform_data;
+   struct soc_camera_link *icl;
+   struct ov7670_soc_camera_info *board_info;
+#endif
struct v4l2_subdev *sd;
struct ov7670_info *info;
+
int ret;
 
+#ifdef OV7670_SOC
+   icl = to_soc_camera_link(icd);
+   if (!icl)
+   return -EINVAL;
+   board_info = container_of(icl, struct ov7670_soc_camera_info, link);
+
+   gpio_request(board_info->gpio_reset, "ov7670 soc reset");
+   gpio_request(board_info->gpio_pwr, "ov7670 soc power");
+
+   /* reset high for normal mode */
+   gpio_direction_output(board_info->gpio_reset, 1);
+   /* power down normal mode. */
+   gpio_direction_output(board_info->gpio_pwr, 0);
+   /* perform a hard reset as per tinyos code */
+   gpio_set_value(board_info->gpio_pwr, 1);
+   gpio_set_value(board_info->gpio_reset, 1);
+   mdelay(2);
+   gpio_set_value(board_info->gpio_pwr, 0);
+   gpio_set_value(board_info->gpio_reset, 0);
+   mdelay(2);
+ 

Re: OMAP patches for linux-media

2009-06-17 Thread Sakari Ailus

Mauro Carvalho Chehab wrote:

Hi Sakari and others,


Hi, Mauro!


I'm seeing lots of patches and discussions for OMAP and DaVinci being handled
at the linux-media Mailing List, as part of the development process of the open
source drivers.

However, it is hard to track all those discussions and be sure what patches are
ready for merging and what patches are just RFC.

On the development model we use here, we have driver maintainers that are
responsible to discuss about improvements on their drivers. They are generally
the driver authors or the one that first started submitting the patches for
that driver(s). 


One of the roles of the driver maintainers is to collect the patches for the
drivers they maintain, merge on their trees, and periodically ask the patch
merge. 


One fundamental concept on Kernel development is the concept of "Commit earlier
and commit often", meaning that the better is to send small, incremental, and
periodic patches, than wait until having everything done, then submit a big
patch. Every time I receive a big patch I need to postpone its analysis and
open a big window on my schedule to analyze it. Of course, this means to
postpone it, and generally results on lots of comments going back to developer,
that, in turn, will need to do lots of changes and return me back with another
big patch for me to analyze again, resulting on a long period of time for
merging it.

As you, Sakari, was the first one that started merging the OMAP drivers, I was
expecting that you would be the one that will handle the figure of the driver
maintainer for OMAP. I even created you an account at linuxtv for you to create
your trees there and ask me to merge from it.

Unfortunately, you haven't sent me any pull requests yet along this year. This
is concerning me a lot, since, at the end, I'll need to review big piles of
patches and/or drivers when you decide to submit the final version.

So, I decided to send you this email, c/c a random list of people that I
believe are involved on the submit and/or review process of those patches, in
the hope to better understand and to discuss what's happening and how can we
speedup the merge process of those patches.


There are a few reasons for apparent stalling of the development 
process. I should have sent a status update earlier.


The code quality of the ISP driver was originally quite low and from 
that part it wouldn't have made much sense to repeatedly post that for 
reviewing. It's been improving since many of the subdrivers have been 
refactored or rewritten since I last posted the patchset. The end result 
should be (more?) easily understood by human beings...


Another reason for no upstream patches is that we are still depending on 
the obsolete v4l2-int-device in the camera / sensor / lens / flash 
driver interface. Hans' opinion was that we must switch to v4l2_subdev 
instead with which I fully agree. However, due to our internal reasons 
we have not been able to even start that transition process yet.


There is no definite deadline for the v4l2_subdev transition (or even 
its start) at the moment. I'm planning to update the patchset in 
Gitorious, however.


Best regards,

--
Sakari Ailus
sakari.ai...@maxwell.research.nokia.com
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] [09061_01] Siano: Update KConfig and Makefile

2009-06-17 Thread Mauro Carvalho Chehab
Em Wed, 17 Jun 2009 17:36:21 +0300
Udi Atar  escreveu:

> # HG changeset patch
> # User Udi Atar 
> # Date 1245248482 -10800
> # Node ID 46081b3e60046b900c9c8110513224911df8e106
> # Parent  b385a43af222b6c8d2d93937644eb936f63d81e3
> Update Siano KConfig file
> 
> From: Udi Atar 
> 
> Priority: normal
> 
> Signed-off-by: Udi Atar 
> 
> diff -r b385a43af222 -r 46081b3e6004 linux/drivers/media/dvb/siano/Kconfig
> --- a/linux/drivers/media/dvb/siano/Kconfig   Tue Jun 16 23:55:44 2009 -0300
> +++ b/linux/drivers/media/dvb/siano/Kconfig   Wed Jun 17 17:21:22 2009 +0300
> @@ -2,25 +2,32 @@
>  # Siano Mobile Silicon Digital TV device configuration
>  #
> 
> -config DVB_SIANO_SMS1XXX
> - tristate "Siano SMS1XXX USB dongle support"
> - depends on DVB_CORE && USB
> +config SMS_SIANO_MDTV

All DVB devices should start with DVB_.

> + tristate "Siano SMS1xxx based MDTV receiver"
> + default m

Don't use "default". You shouldn't assume that most of the kernel users are 
interested
on this module.

>   ---help---
> -   Choose Y here if you have a USB dongle with a SMS1XXX chipset.
> + Choose Y or M here if you have MDTV receiver with a Siano chipset.
> 
> -   To compile this driver as a module, choose M here: the
> -   module will be called sms1xxx.
> + To compile this driver as a module, choose M here
> + (The modules will be called smsmdtv).
> 
> -config DVB_SIANO_SMS1XXX_SMS_IDS
> - bool "Enable support for Siano Mobile Silicon default USB IDs"
> - depends on DVB_SIANO_SMS1XXX
> - default y
> + Note: All dependents, if selected, will be part of this module.

As already discussed, the driver should be kept modular. So, the note above
doesn't apply.

> +
> + Further documentation on this driver can be found on the WWW
> + at http://www.siano-ms.com/
> +
> +if SMS_SIANO_MDTV
> +menu "Siano module components"
> +
> +# Hardware interfaces support
> +
> +config SMS_USB_DRV
> + tristate "USB interface support"
> + depends on USB
> + default m if USB
>   ---help---
> -   Choose Y here if you have a USB dongle with a SMS1XXX chipset
> -   that uses Siano Mobile Silicon's default usb vid:pid.
> + Choose if you would like to have Siano's support for USB interface
> 
> -   Choose N here if you would prefer to use Siano's external driver.
> 
> -   Further documentation on this driver can be found on the WWW at
> -   .
> -
> +endmenu
> +endif # SMS_SIANO_MDTV

What kind of support the driver will provide without USB ?

I suspect that you are wanting to have several bus options like for example USB
and MMC. Since, without a bus, the core module makes no sense to be compiled,
you should, instead, use a different Kbuild struct. Something something like:


comment "Siano devices"

config DVB_SIANO_MDTV
tristate
default n

config DVB_SIANO_USB
tristate "USB bus support for Siano devices"
depends on DVB_CORE && USB
select DVB_SIANO_MDTV
---help---
  Choose if you would like to have Siano's support for USB interface

config DVB_SIANO_MMC
tristate "MMC bus support for Siano devices"
depends on DVB_CORE && USB
select DVB_SIANO_MDTV
---help---
  Choose if you would like to have Siano's support for MMC interface



With the above syntax, the core module will be built only if at least one of the
supported bus is selected.



Cheers,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PULL] generic image bounds setting and alignment function

2009-06-17 Thread Trent Piepho
On Wed, 17 Jun 2009, Guennadi Liakhovetski wrote:
> On Tue, 16 Jun 2009, Trent Piepho wrote:
> > On Tue, 16 Jun 2009, Guennadi Liakhovetski wrote:
> > > > 01/14: compat: handle __fls
> > > > http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=c4b55ce6c273
> > > >
> > > > 02/14: v4l2: Create helper function for bounding and aligning images
> > > > http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=b4d3ec8d363d
> > >
> > > I am sorry, I will not bother with saving, reformatting, pasting... Just
> > > wanted to ask about this place:
> >
> > I guess you do not use Mercurial like all other v4l-dvb developers?
>
> I do use hg, though not for development, but for interacting with "all
> other v4l-dvb developers"
>
> > Because you are making a big deal about a simple operation than can be done
> > with a few keystrokes.  If I wanted this patch quoted in my editor, I can
> > simply type:  !!cd ~/v4l-dvb ; hg export b4d3ec8d363d | sed 's/^/> /'
>
> No, typing this is not a big deal, as you say. But I do not understand
> _wny_ everyone, wishing to review / comment on your patches has to do
> that. And another problem of your approach you confirm yourself in this
> post:

Using pull requests is something all v4l developers, besides you, do as
well.  No one, besides you, seems to find it a problem.  It's been this way
for years.  I'm not the one who came up with this system.  Sometimes one
needs to go the mountain instead of expecting the mountain to come to
oneself.

> See? Now hg will have two patches, which Mauro will then have to merge
> into one when exporting to git, and which then will be very difficult to

Oh well.  It's happened plenty of times before.  I try not to make a habit
of it.

One can find many many patches in the linux git tree that have bugs in
them.  Often there are patches that fix these bugs included in the same
upstream merge.  IOW, the bug was found and fixed before the patch was
merged upstream but the fix wasn't folded into the original patch, because
the original patch was already in git and someone didn't want to do a
git-rebase.  One advantage of the hg tree is we get an extra opportunity to
fix these things before sending them to git.

> everyone gets to see and review your patches only when they are already in
> your external repository ready to be pulled by the maintainer.

s/in your/posted in the/; s/repository/mailing list/; s/pulled/applied/;

everyone gets to see and review your patches only when they are already
posted in the external mailing list ready to be applied by the maintainer.

Is that really any different?
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH / resubmit] USB interrupt support for radio-si470x FM radio driver

2009-06-17 Thread Edouard Lafargue
All,

   Following up on your comments, here is the patch against the
current mercurial tree, still works fine, and indeed, the stereo/mono
and strength indicators work better on this newer version. RDS
reception remains better with my patch :-) Now I just need to bundle
this with icecast to get mp3 streaming with embedded RDS info, but
that's outside of the scope of this list.

   Thanks for all your help, now on to Tobias, I guess!

Best regards,

Signed-off-by: Edouard Lafargue 

diff -r b385a43af222 linux/drivers/media/radio/radio-si470x.c
--- a/linux/drivers/media/radio/radio-si470x.c  Tue Jun 16 23:55:44 2009 -0300
+++ b/linux/drivers/media/radio/radio-si470x.c  Wed Jun 17 19:04:25 2009 +0200
@@ -106,20 +106,24 @@
  * Tobias Lorenz 
  * - add LED status output
  * - get HW/SW version from scratchpad
+ * 2009-06-16   Edouard Lafargue 
+ * Version 1.0.10
+ * - add support for interrupt mode for RDS endpoint,
+ *instead of polling.
+ *Improves RDS reception significantly
  *
  * ToDo:
  * - add firmware download/update support
- * - RDS support: interrupt mode, instead of polling
  */


 /* driver definitions */
 #define DRIVER_AUTHOR "Tobias Lorenz "
 #define DRIVER_NAME "radio-si470x"
-#define DRIVER_KERNEL_VERSION KERNEL_VERSION(1, 0, 9)
+#define DRIVER_KERNEL_VERSION KERNEL_VERSION(1, 0, 10)
 #define DRIVER_CARD "Silicon Labs Si470x FM Radio Receiver"
 #define DRIVER_DESC "USB radio driver for Si470x FM Radio Receivers"
-#define DRIVER_VERSION "1.0.9"
+#define DRIVER_VERSION "1.0.10"


 /* kernel includes */
@@ -218,16 +222,6 @@
 module_param(max_rds_errors, ushort, 0644);
 MODULE_PARM_DESC(max_rds_errors, "RDS maximum block errors: *1*");

-/* RDS poll frequency */
-static unsigned int rds_poll_time = 40;
-/* 40 is used by the original USBRadio.exe */
-/* 50 is used by radio-cadet */
-/* 75 should be okay */
-/* 80 is the usual RDS receive interval */
-module_param(rds_poll_time, uint, 0644);
-MODULE_PARM_DESC(rds_poll_time, "RDS poll time (ms): *40*");
-
-

 /**
  * Register Definitions
@@ -450,6 +444,12 @@
struct usb_interface *intf;
struct video_device *videodev;

+   /* Interrupt endpoint handling */
+   char *int_in_buffer;
+   struct usb_endpoint_descriptor *int_in_endpoint;
+   struct urb *int_in_urb;
+   int int_in_running;
+
/* driver management */
unsigned int users;
unsigned char disconnected;
@@ -459,7 +459,6 @@
unsigned short registers[RADIO_REGISTER_NUM];

/* RDS receive buffer */
-   struct delayed_work work;
wait_queue_head_t read_queue;
struct mutex lock;  /* buffer locking */
unsigned char *buffer;  /* size is always multiple of three */
@@ -865,43 +864,6 @@


 /**
- * General Driver Functions - RDS_REPORT
- **/
-
-/*
- * si470x_get_rds_registers - read rds registers
- */
-static int si470x_get_rds_registers(struct si470x_device *radio)
-{
-   unsigned char buf[RDS_REPORT_SIZE];
-   int retval;
-   int size;
-   unsigned char regnr;
-
-   buf[0] = RDS_REPORT;
-
-   retval = usb_interrupt_msg(radio->usbdev,
-   usb_rcvintpipe(radio->usbdev, 1),
-   (void *) &buf, sizeof(buf), &size, usb_timeout);
-   if (size != sizeof(buf))
-   printk(KERN_WARNING DRIVER_NAME ": si470x_get_rds_registers: "
-   "return size differs: %d != %zu\n", size, sizeof(buf));
-   if (retval < 0)
-   printk(KERN_WARNING DRIVER_NAME ": si470x_get_rds_registers: "
-   "usb_interrupt_msg returned %d\n", retval);
-
-   if (retval >= 0)
-   for (regnr = 0; regnr < RDS_REGISTER_NUM; regnr++)
-   radio->registers[STATUSRSSI + regnr] =
-   get_unaligned_be16(
-   &buf[regnr * RADIO_REGISTER_SIZE + 1]);
-
-   return (retval < 0) ? -EINVAL : 0;
-}
-
-
-
-/**
  * General Driver Functions - LED_REPORT
  **/

@@ -959,102 +921,118 @@
  **/

 /*
- * si470x_rds - rds processing function
+ * si470x_int_in_callback - rds callback and processing function
+ *
+ * TODO: do we need to use mutex locks in some sections?
  */
-static void si470x_rds(struct si470x_device *radio)
+static void si470x_int_in_callback(struct urb *urb)
 {
+   struct si470x_device *radio = urb->context;
+   unsigned char buf[RDS_REPORT_SIZE];
+   int retval;
+   unsigned char regnr;
uns

Re: Convert cpia driver to v4l2, drop parallel port version support?

2009-06-17 Thread Hans de Goede

Hi,

On 06/17/2009 05:23 PM, Mauro Carvalho Chehab wrote:

Em Wed, 17 Jun 2009 16:41:23 +0200
Hans de Goede  escreveu:


Hi all,

On 06/17/2009 04:28 PM, Mauro Carvalho Chehab wrote:

Em Wed, 17 Jun 2009 12:59:59 +0200
Hans de Goede   escreveu:





As for usbvideo that supports (amongst others) the st6422 (from the out of tree
qc-usb-messenger driver), but only one usb-id ??. I'm currently finishing up 
adding
st6422 support to gspca (with all known usb-id's), I have 2 different cams to 
test this with.

I have here one Logitech quickcam. There are several variants, and the in-tree
and out-tree drivers support different models. I can test it here and give you
a feedback. However, I don't have the original driver for it.


Ok, what is its usb id (they tend to be unique for Logitech cams) ?


The one I have is this one:

Bus 005 Device 003: ID 046d:08f6 Logitech, Inc. QuickCam Messenger Plus

This is supported by one quickcam driver.



Ah, that is one of the 2 models I have access to, so I can promise you that one 
will work fine
with the new st6422 support I'm doing.


zc0301
only supports one usb-id which has not yet been tested with gspca, used to 
claim a lot more
usb-id's but didn't actually work with those as it only supported the bridge, 
not the sensor
->   remove it now ?

I have one zc0301 cam that works with this driver. The last time I checked, it
didn't work with gspca. I'll double check.


Ok, let me know how it goes.


The zc0301 camera is this one:

Bus 005 Device 002: ID 046d:08ae Logitech, Inc. QuickCam for Notebooks

zc0301 driver says this:

[98174.672464] zc0301: V4L2 driver for ZC0301[P] Image Processor and Control 
Chip v1:1.10
[98174.672517] usb 5-2: ZC0301[P] Image Processor and Control Chip detected 
(vid/pid 0x046D:0x08AE)
[98174.713717] usb 5-2: PAS202BCB image sensor detected

The cam works as expected.



Hmm, bummer I don't have any zc3xx test cams with a pas202b sensor, guess I 
need to find one :)



I probably won't go to LPC this year, since I'm programming to be at Japan Linux
Symposium in October, and it seems too much jet leg for me to be in Portland in
Sept and in Japan in Oct ;)



Ah too bad, but understandable.

Regards,

Hans
--
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: bttv problem loading takes about several minutes

2009-06-17 Thread Trent Piepho
On Wed, 17 Jun 2009, Halim Sahin wrote:
> Hi,
> In the past I could use this card by typing
> modprobe bttv card=34 tuner=24 gbuffers=16

What card do you actually have?  What is the PCI subsystem vendor/device
and what tuner does it actually have?

Hans, the problem might be with bttv audio probing.  This card has
needs_tvaudio set to 0, which used to mean that tvaudio would not be probed
or loaded.  But with your changes to bttv audio probing this behavior has
changed.  Now tvaudio is always loaded and probed if another audio chip
hasn't been detected.  The needs_tvaudio field is totally ignored.

> Giving this command with current drivers has some problems:
> 1. it takes several minutes to load bttv module.
> 2. capturing doesn't work any more (dropped frames etc).
> Tested with current v4l-dvb from hg, ubuntu 9.04,
> debian lenny.
>
> I have a bt878  based card from leadtek.
>
> Here is my output after loading the driver:
> [ 3013.735459] bttv: driver version 0.9.17 loaded
> [ 3013.735470] bttv: using 32 buffers with 16k (4 pages) each for capture
> [ 3013.735542] bttv: Bt8xx card found (0).
> [ 3013.735562] bttv0: Bt878 (rev 17) at :00:0b.0, irq: 19, latency: 32, 
> mmio
> : 0xf780
> [ 3013.737762] bttv0: using: Leadtek WinFast 2000/ WinFast 2000 XP 
> [card=34,insm
> od option]
> [ 3013.737825] bttv0: gpio: en=, out= in=003ff502 [init]
> [ 3148.136017] bttv0: tuner type=24
> [ 3148.136029] bttv0: i2c: checking for MSP34xx @ 0x80... not found
> [ 3154.536019] bttv0: i2c: checking for TDA9875 @ 0xb0... not found
> [ 3160.936018] bttv0: i2c: checking for TDA7432 @ 0x8a... not found
> [ 3167.351398] bttv0: registered device video0
> [ 3167.351434] bttv0: registered device vbi0
> [ 3167.351463] bttv0: registered device radio0
> [ 3167.351485] bttv0: PLL: 28636363 => 35468950 . ok
> [ 3167.364182] input: bttv IR (card=34) as /class/input/input6
>
> Please help!
> Regards
> Halim
>
>
> --
> Halim Sahin
> E-Mail:
> halim.sahin (at) t-online.de
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PULL] generic image bounds setting and alignment function

2009-06-17 Thread Trent Piepho
On Wed, 17 Jun 2009, Guennadi Liakhovetski wrote:
> On Tue, 16 Jun 2009, Trent Piepho wrote:
>
>   /* up the smaller alignment until we have enough */
>   do {
> - if (walign <= halign && walign < wmaxa) {
> + if (halign >= hmaxa ||
> + (walign <= halign && walign < wmaxa)) {
>
> Do I understand it right now, that as soon as your halign now reaches
> hmaxa, you'll stop incrementing halign and then keep incrementing walign
> even beyond wmaxa?...

Yes.

It's clearly documented that the function isn't designed to handle
impossible constraints.  If both walign and halign are at max and there
still needs to be more alignment then there is no possible resolution, no
matter what width & height started at.

This is just one of many ways the constraints could be impossible.  Max
width being less than min width is another obvious example.  I decided it
wasn't worth complicating the code to check for all of these things.  And
if the function did return failure the callers would need to check that.
None of the code v4l_bound_align_image() replaces has a failure path for
impossible image size constraints, because the constraints aren't
impossible.
--
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


bttv problem loading takes about several minutes

2009-06-17 Thread Halim Sahin
Hi,
In the past I could use this card by typing
modprobe bttv card=34 tuner=24 gbuffers=16
Giving this command with current drivers has some problems:
1. it takes several minutes to load bttv module.
2. capturing doesn't work any more (dropped frames etc).
Tested with current v4l-dvb from hg, ubuntu 9.04, 
debian lenny.

I have a bt878  based card from leadtek.

Here is my output after loading the driver:
[ 3013.735459] bttv: driver version 0.9.17 loaded
[ 3013.735470] bttv: using 32 buffers with 16k (4 pages) each for capture
[ 3013.735542] bttv: Bt8xx card found (0).
[ 3013.735562] bttv0: Bt878 (rev 17) at :00:0b.0, irq: 19, latency: 32, mmio
: 0xf780
[ 3013.737762] bttv0: using: Leadtek WinFast 2000/ WinFast 2000 XP [card=34,insm
od option]
[ 3013.737825] bttv0: gpio: en=, out= in=003ff502 [init]
[ 3148.136017] bttv0: tuner type=24
[ 3148.136029] bttv0: i2c: checking for MSP34xx @ 0x80... not found
[ 3154.536019] bttv0: i2c: checking for TDA9875 @ 0xb0... not found
[ 3160.936018] bttv0: i2c: checking for TDA7432 @ 0x8a... not found
[ 3167.351398] bttv0: registered device video0
[ 3167.351434] bttv0: registered device vbi0
[ 3167.351463] bttv0: registered device radio0
[ 3167.351485] bttv0: PLL: 28636363 => 35468950 . ok
[ 3167.364182] input: bttv IR (card=34) as /class/input/input6

Please help!
Regards
Halim


-- 
Halim Sahin
E-Mail: 
halim.sahin (at) t-online.de
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


RE: [RFC PATCH] adding support for setting bus parameters in sub device

2009-06-17 Thread Karicheri, Muralidharan
Hans,

Let me know if this has all changes that you are expecting. This is just for 
review. I will send the final one against the latest v4l-dvb kernel tree.

Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
email: m-kariche...@ti.com

>-Original Message-
>From: Karicheri, Muralidharan
>Sent: Wednesday, June 17, 2009 11:44 AM
>To: linux-media@vger.kernel.org
>Cc: davinci-linux-open-sou...@linux.davincidsp.com; Muralidharan Karicheri;
>Karicheri, Muralidharan
>Subject: [RFC PATCH] adding support for setting bus parameters in sub
>device
>
>From: Muralidharan Karicheri 
>
>This patch adds support for setting bus parameters such as bus type
>(Raw Bayer or Raw YUV image data bus), bus width (example 10 bit raw
>image data bus, 10 bit BT.656 etc.), and polarities (vsync, hsync, field
>etc) in sub device. This allows bridge driver to configure the sub device
>bus for a specific set of bus parameters through s_bus() function call.
>This also can be used to define platform specific bus parameters for
>host and sub-devices.
>
>Reviewed by: Hans Verkuil 
>Signed-off-by: Murali Karicheri 
>---
>Applies to v4l-dvb repository
>
> include/media/v4l2-subdev.h |   40
>
> 1 files changed, 40 insertions(+), 0 deletions(-)
>
>diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
>index 1785608..2f5ec98 100644
>--- a/include/media/v4l2-subdev.h
>+++ b/include/media/v4l2-subdev.h
>@@ -37,6 +37,43 @@ struct v4l2_decode_vbi_line {
>   u32 type;   /* VBI service type (V4L2_SLICED_*). 0 if no
>service found */
> };
>
>+/*
>+ * Some sub-devices are connected to the host/bridge device through a bus
>that
>+ * carries the clock, vsync, hsync and data. Some interfaces such as
>BT.656
>+ * carries the sync embedded in the data where as others have separate
>line
>+ * carrying the sync signals. The structure below is used to define bus
>+ * configuration parameters for host as well as sub-device
>+ */
>+enum v4l2_subdev_bus_type {
>+  /* Raw YUV image data bus */
>+  V4L2_SUBDEV_BUS_RAW_YUV,
>+  /* Raw Bayer image data bus */
>+  V4L2_SUBDEV_BUS_RAW_BAYER
>+};
>+
>+struct v4l2_bus_settings {
>+  /* yuv or bayer image data bus */
>+  enum v4l2_subdev_bus_type type;
>+  /* subdev bus width */
>+  u8 subdev_width;
>+  /* host bus width */
>+  u8 host_width;
>+  /* embedded sync, set this when sync is embedded in the data stream
>*/
>+  unsigned embedded_sync:1;
>+  /* master or slave */
>+  unsigned host_is_master:1;
>+  /* 0 - active low, 1 - active high */
>+  unsigned pol_vsync:1;
>+  /* 0 - active low, 1 - active high */
>+  unsigned pol_hsync:1;
>+  /* 0 - low to high , 1 - high to low */
>+  unsigned pol_field:1;
>+  /* 0 - sample at falling edge , 1 - sample at rising edge */
>+  unsigned pol_pclock:1;
>+  /* 0 - active low , 1 - active high */
>+  unsigned pol_data:1;
>+};
>+
> /* Sub-devices are devices that are connected somehow to the main bridge
>device. These devices are usually audio/video muxers/encoders/decoders
>or
>sensors and webcam controllers.
>@@ -199,6 +236,8 @@ struct v4l2_subdev_audio_ops {
>
>s_routing: see s_routing in audio_ops, except this version is for video
>   devices.
>+
>+   s_bus: set bus parameters in sub device to configure the bus
>  */
> struct v4l2_subdev_video_ops {
>   int (*s_routing)(struct v4l2_subdev *sd, u32 input, u32 output, u32
>config);
>@@ -219,6 +258,7 @@ struct v4l2_subdev_video_ops {
>   int (*s_parm)(struct v4l2_subdev *sd, struct v4l2_streamparm *param);
>   int (*enum_framesizes)(struct v4l2_subdev *sd, struct
>v4l2_frmsizeenum *fsize);
>   int (*enum_frameintervals)(struct v4l2_subdev *sd, struct
>v4l2_frmivalenum *fival);
>+  int (*s_bus)(struct v4l2_subdev *sd, const struct v4l2_bus_settings
>*bus);
> };
>
> struct v4l2_subdev_ops {
>--
>1.6.0.4

--
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


[RFC PATCH] adding support for setting bus parameters in sub device

2009-06-17 Thread m-karicheri2
From: Muralidharan Karicheri 

This patch adds support for setting bus parameters such as bus type
(Raw Bayer or Raw YUV image data bus), bus width (example 10 bit raw
image data bus, 10 bit BT.656 etc.), and polarities (vsync, hsync, field
etc) in sub device. This allows bridge driver to configure the sub device
bus for a specific set of bus parameters through s_bus() function call.
This also can be used to define platform specific bus parameters for
host and sub-devices.

Reviewed by: Hans Verkuil 
Signed-off-by: Murali Karicheri 
---
Applies to v4l-dvb repository

 include/media/v4l2-subdev.h |   40 
 1 files changed, 40 insertions(+), 0 deletions(-)

diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
index 1785608..2f5ec98 100644
--- a/include/media/v4l2-subdev.h
+++ b/include/media/v4l2-subdev.h
@@ -37,6 +37,43 @@ struct v4l2_decode_vbi_line {
u32 type;   /* VBI service type (V4L2_SLICED_*). 0 if no 
service found */
 };
 
+/*
+ * Some sub-devices are connected to the host/bridge device through a bus that
+ * carries the clock, vsync, hsync and data. Some interfaces such as BT.656
+ * carries the sync embedded in the data where as others have separate line
+ * carrying the sync signals. The structure below is used to define bus 
+ * configuration parameters for host as well as sub-device
+ */
+enum v4l2_subdev_bus_type {
+   /* Raw YUV image data bus */
+   V4L2_SUBDEV_BUS_RAW_YUV,
+   /* Raw Bayer image data bus */
+   V4L2_SUBDEV_BUS_RAW_BAYER
+};
+
+struct v4l2_bus_settings {
+   /* yuv or bayer image data bus */
+   enum v4l2_subdev_bus_type type;
+   /* subdev bus width */
+   u8 subdev_width;
+   /* host bus width */
+   u8 host_width;
+   /* embedded sync, set this when sync is embedded in the data stream */
+   unsigned embedded_sync:1;
+   /* master or slave */
+   unsigned host_is_master:1;
+   /* 0 - active low, 1 - active high */
+   unsigned pol_vsync:1;
+   /* 0 - active low, 1 - active high */
+   unsigned pol_hsync:1;
+   /* 0 - low to high , 1 - high to low */
+   unsigned pol_field:1;
+   /* 0 - sample at falling edge , 1 - sample at rising edge */
+   unsigned pol_pclock:1;
+   /* 0 - active low , 1 - active high */
+   unsigned pol_data:1;
+};
+
 /* Sub-devices are devices that are connected somehow to the main bridge
device. These devices are usually audio/video muxers/encoders/decoders or
sensors and webcam controllers.
@@ -199,6 +236,8 @@ struct v4l2_subdev_audio_ops {
 
s_routing: see s_routing in audio_ops, except this version is for video
devices.
+
+   s_bus: set bus parameters in sub device to configure the bus 
  */
 struct v4l2_subdev_video_ops {
int (*s_routing)(struct v4l2_subdev *sd, u32 input, u32 output, u32 
config);
@@ -219,6 +258,7 @@ struct v4l2_subdev_video_ops {
int (*s_parm)(struct v4l2_subdev *sd, struct v4l2_streamparm *param);
int (*enum_framesizes)(struct v4l2_subdev *sd, struct v4l2_frmsizeenum 
*fsize);
int (*enum_frameintervals)(struct v4l2_subdev *sd, struct 
v4l2_frmivalenum *fival);
+   int (*s_bus)(struct v4l2_subdev *sd, const struct v4l2_bus_settings 
*bus);
 };
 
 struct v4l2_subdev_ops {
-- 
1.6.0.4

--
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: Convert cpia driver to v4l2, drop parallel port version support?

2009-06-17 Thread Mauro Carvalho Chehab
Em Wed, 17 Jun 2009 16:41:23 +0200
Hans de Goede  escreveu:

> Hi all,
> 
> On 06/17/2009 04:28 PM, Mauro Carvalho Chehab wrote:
> > Em Wed, 17 Jun 2009 12:59:59 +0200
> > Hans de Goede  escreveu:
> >
> 
> 
> 
> >>
> >> As for usbvideo that supports (amongst others) the st6422 (from the out of 
> >> tree
> >> qc-usb-messenger driver), but only one usb-id ??. I'm currently finishing 
> >> up adding
> >> st6422 support to gspca (with all known usb-id's), I have 2 different cams 
> >> to test this with.
> >
> > I have here one Logitech quickcam. There are several variants, and the 
> > in-tree
> > and out-tree drivers support different models. I can test it here and give 
> > you
> > a feedback. However, I don't have the original driver for it.
> >
> 
> Ok, what is its usb id (they tend to be unique for Logitech cams) ?

The one I have is this one:

Bus 005 Device 003: ID 046d:08f6 Logitech, Inc. QuickCam Messenger Plus

This is supported by one quickcam driver.

> >> zc0301
> >> only supports one usb-id which has not yet been tested with gspca, used to 
> >> claim a lot more
> >> usb-id's but didn't actually work with those as it only supported the 
> >> bridge, not the sensor
> >> ->  remove it now ?
> >
> > I have one zc0301 cam that works with this driver. The last time I checked, 
> > it
> > didn't work with gspca. I'll double check.
> >
> 
> Ok, let me know how it goes. 

The zc0301 camera is this one:

Bus 005 Device 002: ID 046d:08ae Logitech, Inc. QuickCam for Notebooks

zc0301 driver says this:

[98174.672464] zc0301: V4L2 driver for ZC0301[P] Image Processor and Control 
Chip v1:1.10
[98174.672517] usb 5-2: ZC0301[P] Image Processor and Control Chip detected 
(vid/pid 0x046D:0x08AE)
[98174.713717] usb 5-2: PAS202BCB image sensor detected

The cam works as expected.

> If it does not work, guess what I want you to bring along
> to plumbers ? (you are coming to plumbers, or .. ? )

I probably won't go to LPC this year, since I'm programming to be at Japan Linux
Symposium in October, and it seems too much jet leg for me to be in Portland in
Sept and in Japan in Oct ;)



Cheers,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


RE: [PATCH 1/10 - v2] vpfe capture bridge driver for DM355 and DM6446

2009-06-17 Thread Karicheri, Muralidharan
>>
>> 
>
>Can you post your latest proposal for the s_bus op?
>
>I propose a few changes: the name of the struct should be something like
>v4l2_bus_settings, the master/slave bit should be renamed to something
>like 'host_is_master', and we should have two widths: subdev_width and
>host_width.
>
>That way the same structure can be used for both host and subdev, unless
>some of the polarities are inverted. In that case you need to make two
>structs, one for host and one for the subdev.
>
>It is possible to add info on inverters to the struct, but unless inverters
>are used a lot more frequently than I expect I am inclined not to do that
>at this time.
>
[MK]Today I am planning to send my v3 version of the vpfe capture patch and 
also tvp514x patch since Vaibhav is pre-occupied with some other activities. I 
have discussed the changes with Vaibhav for this driver.

For s_bus, I will try if I can send a patch today. BTW, do you expect me to add 
one bool for active high, one for active low etc as done in SoC camera ?

Murali 
--
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: Convert cpia driver to v4l2, drop parallel port version support?

2009-06-17 Thread Hans de Goede

Hi all,

On 06/17/2009 04:28 PM, Mauro Carvalho Chehab wrote:

Em Wed, 17 Jun 2009 12:59:59 +0200
Hans de Goede  escreveu:







As for usbvideo that supports (amongst others) the st6422 (from the out of tree
qc-usb-messenger driver), but only one usb-id ??. I'm currently finishing up 
adding
st6422 support to gspca (with all known usb-id's), I have 2 different cams to 
test this with.


I have here one Logitech quickcam. There are several variants, and the in-tree
and out-tree drivers support different models. I can test it here and give you
a feedback. However, I don't have the original driver for it.



Ok, what is its usb id (they tend to be unique for Logitech cams) ?


zc0301
only supports one usb-id which has not yet been tested with gspca, used to 
claim a lot more
usb-id's but didn't actually work with those as it only supported the bridge, 
not the sensor
->  remove it now ?


I have one zc0301 cam that works with this driver. The last time I checked, it
didn't work with gspca. I'll double check.



Ok, let me know how it goes. If it does not work, guess what I want you to 
bring along
to plumbers ? (you are coming to plumbers, or .. ? )


sn9c102
Supports a large number of cams also supported by gspca's sonixb / sonixj 
driver, we're using
#ifdef  macros to detect if both are being build at the same time to 
include usb-id's only
in one of the 2.


Btw, it would be interesting to work with the out-of-tree microdia driver,
since there are some models that are supported only by the alternative driver.


Ack, only one small problem, which is another reason why Luca's drivers should 
slowly be phased
out, Luca has gone closed source with his sn9cxxx driver.

There is an out of tree driver for the new sn9c2xx models you talk about 
though, with active
developers, I've pushing them to get it into the mainline, I'll give it another 
try soonish.

Regards,

Hans
--
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] [09061_01] Siano: Update KConfig and Makefile

2009-06-17 Thread Udi Atar
# HG changeset patch
# User Udi Atar 
# Date 1245248482 -10800
# Node ID 46081b3e60046b900c9c8110513224911df8e106
# Parent  b385a43af222b6c8d2d93937644eb936f63d81e3
Update Siano KConfig file

From: Udi Atar 

Priority: normal

Signed-off-by: Udi Atar 

diff -r b385a43af222 -r 46081b3e6004 linux/drivers/media/dvb/siano/Kconfig
--- a/linux/drivers/media/dvb/siano/Kconfig Tue Jun 16 23:55:44 2009 -0300
+++ b/linux/drivers/media/dvb/siano/Kconfig Wed Jun 17 17:21:22 2009 +0300
@@ -2,25 +2,32 @@
 # Siano Mobile Silicon Digital TV device configuration
 #

-config DVB_SIANO_SMS1XXX
-   tristate "Siano SMS1XXX USB dongle support"
-   depends on DVB_CORE && USB
+config SMS_SIANO_MDTV
+   tristate "Siano SMS1xxx based MDTV receiver"
+   default m
---help---
- Choose Y here if you have a USB dongle with a SMS1XXX chipset.
+   Choose Y or M here if you have MDTV receiver with a Siano chipset.

- To compile this driver as a module, choose M here: the
- module will be called sms1xxx.
+   To compile this driver as a module, choose M here
+   (The modules will be called smsmdtv).

-config DVB_SIANO_SMS1XXX_SMS_IDS
-   bool "Enable support for Siano Mobile Silicon default USB IDs"
-   depends on DVB_SIANO_SMS1XXX
-   default y
+   Note: All dependents, if selected, will be part of this module.
+
+   Further documentation on this driver can be found on the WWW
+   at http://www.siano-ms.com/
+
+if SMS_SIANO_MDTV
+menu "Siano module components"
+
+# Hardware interfaces support
+
+config SMS_USB_DRV
+   tristate "USB interface support"
+   depends on USB
+   default m if USB
---help---
- Choose Y here if you have a USB dongle with a SMS1XXX chipset
- that uses Siano Mobile Silicon's default usb vid:pid.
+   Choose if you would like to have Siano's support for USB interface

- Choose N here if you would prefer to use Siano's external driver.

- Further documentation on this driver can be found on the WWW at
- .
-
+endmenu
+endif # SMS_SIANO_MDTV
diff -r b385a43af222 -r 46081b3e6004 linux/drivers/media/dvb/siano/Makefile
--- a/linux/drivers/media/dvb/siano/MakefileTue Jun 16 23:55:44 2009 -0300
+++ b/linux/drivers/media/dvb/siano/MakefileWed Jun 17 17:21:22 2009 +0300
@@ -1,8 +1,8 @@
-sms1xxx-objs := smscoreapi.o sms-cards.o smsendian.o smsir.o

-obj-$(CONFIG_DVB_SIANO_SMS1XXX) += sms1xxx.o
-obj-$(CONFIG_DVB_SIANO_SMS1XXX) += smsusb.o
-obj-$(CONFIG_DVB_SIANO_SMS1XXX) += smsdvb.o
+smsmdtv-objs := smscoreapi.o sms-cards.o smsendian.o smsir.o
+
+obj-$(CONFIG_SMS_SIANO_MDTV) += smsmdtv.o smsdvb.o
+obj-$(CONFIG_SMS_USB_DRV) += smsusb.o

 EXTRA_CFLAGS += -Idrivers/media/dvb/dvb-core
--
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: Convert cpia driver to v4l2, drop parallel port version support?

2009-06-17 Thread Mauro Carvalho Chehab
Em Wed, 17 Jun 2009 12:59:59 +0200
Hans de Goede  escreveu:

> 
> 
> On 06/17/2009 11:56 AM, Mauro Carvalho Chehab wrote:
> > Em Wed, 17 Jun 2009 09:43:50 +0200 (CEST)
> > "Hans Verkuil"  escreveu:
> >
> >>> I recently have been bying second hand usb webcams left and right
> >>> one of them (a creative unknown model) uses the cpia1 chipset, and
> >>> works with the v4l1 driver currently in the kernel.
> >>>
> >>> One of these days I would like to convert it to a v4l2 driver using
> >>> gspca as basis, this however will cause us to use parallel port support
> >>> (that or we need to keep the old code around for the parallel port
> >>> version).
> >>>
> >>> I personally think that loosing support for the parallel port
> >>> version is ok given that the parallel port itslef is rapidly
> >>> disappearing, what do you think ?
> >> I agree wholeheartedly. If we remove pp support, then we can also remove
> >> the bw-qcam and c-qcam drivers since they too use the parallel port.
> >
> > Maybe I'm too nostalgic, but those are the first V4L drivers. It would be 
> > fun
> > to keep supporting them with V4L2 API ;)
> >
> > That's said, while it is probably not that hard to develop a gspca-pp 
> > driver,
> > I'm not against removing parallel port support or even removing those 
> > drivers
> > due to technical reasons, like the end of V4L1 drivers.
> >
> > By looking at the remaining V4L1 drivers, we have:
> >
> > ov511 - already implemented with V4L2 on gspca. Can be easily removed;
> >
> 
> Yip, this one is a done deal :)
> 
> > se401, stv680, usbvideo, vicam - USB V4L1 drivers. IMO, it is valuable
> > to convert them to gspca;
> >
> 
> I've recently bought a (second hand) stv680 cam, haven't seriously tested it 
> yet,
> so I dunno if it works with the v4l1 driver. I agree it would be good to 
> convert these,
> and I can work on this as time permits, but I won't be converting code I 
> don't have
> HW to test for.
> 
> As for usbvideo that supports (amongst others) the st6422 (from the out of 
> tree
> qc-usb-messenger driver), but only one usb-id ??. I'm currently finishing up 
> adding
> st6422 support to gspca (with all known usb-id's), I have 2 different cams to 
> test this with.

I have here one Logitech quickcam. There are several variants, and the in-tree
and out-tree drivers support different models. I can test it here and give you
a feedback. However, I don't have the original driver for it.

> zc0301
> only supports one usb-id which has not yet been tested with gspca, used to 
> claim a lot more
> usb-id's but didn't actually work with those as it only supported the bridge, 
> not the sensor
> -> remove it now ?

I have one zc0301 cam that works with this driver. The last time I checked, it
didn't work with gspca. I'll double check.

> et61x251
> Only supports using this bridge in combination with one type of sensor where 
> as gspca
> supports 2 type of sensors. gspca support is untested AFAIK.
> -> ?
> 
> sn9c102
> Supports a large number of cams also supported by gspca's sonixb / sonixj 
> driver, we're using
> #ifdef  macros to detect if both are being build at the same time to 
> include usb-id's only
> in one of the 2.

Btw, it would be interesting to work with the out-of-tree microdia driver,
since there are some models that are supported only by the alternative driver. 
> 
> As seems normal for drivers from this author the driver used to claim a lot 
> of usb-id's it
> couldn't actually work with as it only supported the bridge, not the sensor. 
> We've removed all
> those and are now slowly moving over the remaining usb-ids to gspca as things 
> get tested
> with gspca.
> -> Keep on moving over usb-id's then when only a few are left, drop it

It makes no sense to have two drivers for the same cams. Once having support
for all USB ID's, we can mark the alternative driver as deprecated and remove
it at the next kernel version.



Cheers,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


typo: v4l2_bound_align_image name mismatch.

2009-06-17 Thread Jonathan Cameron
Just came across a build error with pxa_camera with Mauro's linux-next tree.

pxa-camera calls v4l2_bound_align_image whereas the function is called
v4l_bound_align_image.  

Cheers,

---
Jonathan Cameron
--
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


Elgato EyeTV Diversity Support in dib0700

2009-06-17 Thread Andreas Huesgen

Hi everybody,

I few days ago I bought an Elgato EyeTV Diversity. After some googling, 
I found patches for it at 
http://www.linuxtv.org/pipermail/linux-dvb/2008-September/028813.html. 
Applying the patches succeeded (I only hat to adjust the index into 
dib0700_usb_id_table) and after rebooting the card worked without 
problems. Even the remote control worked properly with the Xorg evdev 
driver after setting dvb_usb_dib0700_ir_proto to NEC.


So I wondered if there is a reason why the patches have not been merged, 
yet. I searched the hg drivers as well as the developer repositories at 
http://linuxtv.org/hg/ and the mailing list archives but found little to 
no references referring to the EyeTV Diversity.


I just wanted to mention it in case that the patches have been forgotten 
or something similar.


Best Regards,

Andreas Huesgen
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] adding support for setting bus parameters in sub device

2009-06-17 Thread Trent Piepho
On Wed, 17 Jun 2009, Guennadi Liakhovetski wrote:
> On Wed, 17 Jun 2009, Hans Verkuil wrote:
> > It is my strong opinion that while autonegotiation is easy to use, it is
> > not a wise choice to make. Filling in a single struct with the bus
> > settings to use for each board-subdev combination (usually there is only
> > one) is simple, straight-forward and unambiguous. And I really don't see
> > why that should take much time at all. And I consider it a very good point
> > that the programmer is forced to think about this for a bit.
>
> Ok, my opinion is, that we should keep autonegotiation, but if you like,
> we can print a BIG-FAT-WARNING if both polarities are supported and no
> platform preference is set.
>
> I think, we've heard all opinions, unless someone would like to add
> something? Would it be fair to ask Mauro to make a decision? Or we can
> just count votes (which I would obviously prefer), but I'll accept Mauro's
> decision too.

There is a similar situation in the networking code, where there is a
driver for a PHY and another driver for a MAC, much like a sensor and
bridge.  phylib will find the common subset of the supported modes between
the MAC and the detected PHY and use that to configure aneg advertisement
settings.
--
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: Convert cpia driver to v4l2, drop parallel port version support?

2009-06-17 Thread Mauro Carvalho Chehab
Em Wed, 17 Jun 2009 13:26:58 +0200 (CEST)
"Hans Verkuil"  escreveu:

> 
> > On Wed, 2009-06-17 at 09:43 +0200, Hans Verkuil wrote:
> >
> >> > I personally think that loosing support for the parallel port
> >> > version is ok given that the parallel port itslef is rapidly
> >> > disappearing, what do you think ?
> >>
> >> I agree wholeheartedly. If we remove pp support, then we can also remove
> >> the bw-qcam and c-qcam drivers since they too use the parallel port.
> >
> > Maybe I just like keeping old hardware up and running, but...
> >
> > I think it may be better to remove camera drivers when a majority of the
> > actual camera hardware is likely to reach EOL, as existing parallel
> > ports will likely outlive the cameras.

Parallel port will still be there for some time. However, Parallel port webcams
are less common.

> For sure. But these are really old webcams with correspondingly very poor
> resolutions. I haven't been able to track one down on ebay and as far as I
> know nobody has one of these beasts to test with. I can't see anyone using
> parallel port webcams. I actually wonder whether these drivers still work.
> And converting to v4l2 without having the hardware is very hard indeed.

Maybe Alan Cox might still have some of those cams. Some of those old cameras
were used on specialized hardware, like microscopes. Maybe it still could make
sense to support them, but somebody with the hardware should convert to V4L2
and test with the real hardware. Otherwise, I agree that the better is just to
remove the parallel port camera drivers from newer kernels.



Cheers,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] zl10353 and qt1010: fix stack corruption bug

2009-06-17 Thread Mauro Carvalho Chehab
Em Wed, 17 Jun 2009 14:26:28 +0200
Matthias Schwarzott  escreveu:

> On Mittwoch, 17. Juni 2009, Jan Nikitenko wrote:
> >
> > Or we could use sizeof, like this:
> > char buf[sizeof("00: ") - 1 + 16 * (sizeof("00 ") - 1) + 1]
> > or
> > char buf[sizeof("00: 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
> > ")] but it is not very readable in my opinion either.
> >
> > Maybe the best way would be to avoid the need for temporal buffer
> > completely by directly using printk in a loop, that is only the first
> > printk with KERN_DEBUG, followed by sequence of printk with registers dump
> > and final printk with end of line (but isn't a printk without KERN_
> > facility coding style problem as well?).
> >
> 
> Exactly for this case, line continuation, there is KERN_CONT defined.

There are some functions meant for printing hex dumps at kernel.h:

extern void hex_dump_to_buffer(const void *buf, size_t len,
int rowsize, int groupsize,
char *linebuf, size_t linebuflen, bool ascii);
extern void print_hex_dump(const char *level, const char *prefix_str,
int prefix_type, int rowsize, int groupsize,
const void *buf, size_t len, bool ascii);
extern void print_hex_dump_bytes(const char *prefix_str, int prefix_type,
const void *buf, size_t len);

Also, it is possible to use kasprintf() to dynamically allocate a temporary
buffer. If you use it, you'll need to do a kfree after its usage.



Cheers,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: soc-camera: status, roadmap

2009-06-17 Thread Guennadi Liakhovetski
On Wed, 10 Jun 2009, Guennadi Liakhovetski wrote:

> 2. The above means, I'll have to maintain and update my patches for a 
> whole 2.6.31 development cycle. In this time I'll try to update and upload 
> them as a quilt patch series and announce it on the list a couple of 
> times.

As promised, I just uploaded my current tree snapshot at 
http://download.open-technology.de/soc-camera/20090617/
This is nothing remarkable, just my current patch-stack for those working 
with the soc-camera framework. It is still based on a linux-next snapshot 
of 07.05.2009 "history" branch. The exact commit on which the stack is 
based is, as usual, in -base. This is still based off 2.6.30-rc4, and 
I expect to upgrade next time after 2.6.31-rc1.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] zl10353 and qt1010: fix stack corruption bug

2009-06-17 Thread Matthias Schwarzott
On Mittwoch, 17. Juni 2009, Jan Nikitenko wrote:
>
> Or we could use sizeof, like this:
> char buf[sizeof("00: ") - 1 + 16 * (sizeof("00 ") - 1) + 1]
> or
> char buf[sizeof("00: 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
> ")] but it is not very readable in my opinion either.
>
> Maybe the best way would be to avoid the need for temporal buffer
> completely by directly using printk in a loop, that is only the first
> printk with KERN_DEBUG, followed by sequence of printk with registers dump
> and final printk with end of line (but isn't a printk without KERN_
> facility coding style problem as well?).
>

Exactly for this case, line continuation, there is KERN_CONT defined.

Regards
Matthias
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] zl10353 and qt1010: fix stack corruption bug

2009-06-17 Thread Jan Nikitenko

Mauro Carvalho Chehab wrote:

Em Wed, 10 Jun 2009 08:21:20 +0200
Jan Nikitenko  escreveu:

This patch fixes stack corruption bug present in dump_regs function of zl10353 
and qt1010 drivers:

the buffer buf is one byte smaller than required - there is 4 chars
for address prefix, 16*3 chars for dump of 16 eeprom bytes per line
and 1 byte for zero ending the string required, i.e. 53 bytes, but
only 52 were provided.
The one byte missing in stack based buffer buf can cause stack corruption 
possibly leading to kernel oops, as discovered originally with af9015 driver.


Signed-off-by: Jan Nikitenko 

---

Antti Palosaari wrote:
 > On 06/10/2009 01:39 AM, Jan Nikitenko wrote:
 >> Solved with "[PATCH] af9015: fix stack corruption bug".
 >
 > This error leads to the zl10353.c and there it was copied to qt1010.c
 > and af9015.c.
 >
Antti, thanks for pointing out that the same problem was also in zl10353.c and 
qt1010.c. Include your Sign-off-by, please.


Best regards,
Jan

  linux/drivers/media/common/tuners/qt1010.c  |2 +-
  linux/drivers/media/dvb/frontends/zl10353.c |2 +-
  2 files changed, 2 insertions(+), 2 deletions(-)

diff -r cff06234b725 linux/drivers/media/common/tuners/qt1010.c
--- a/linux/drivers/media/common/tuners/qt1010.cSun May 31 23:07:01 
2009 +0300
+++ b/linux/drivers/media/common/tuners/qt1010.cWed Jun 10 07:37:51 
2009 +0200
@@ -65,7 +65,7 @@
  /* dump all registers */
  static void qt1010_dump_regs(struct qt1010_priv *priv)
  {
-   char buf[52], buf2[4];
+   char buf[4+3*16+1], buf2[4];


CodingStyle is incorrect. It should be buf[4 + 3 * 16 + 1].


right.





u8 reg, val;

for (reg = 0; ; reg++) {
diff -r cff06234b725 linux/drivers/media/dvb/frontends/zl10353.c
--- a/linux/drivers/media/dvb/frontends/zl10353.c   Sun May 31 23:07:01 
2009 +0300
+++ b/linux/drivers/media/dvb/frontends/zl10353.c   Wed Jun 10 07:37:51 
2009 +0200
@@ -102,7 +102,7 @@
  static void zl10353_dump_regs(struct dvb_frontend *fe)
  {
struct zl10353_state *state = fe->demodulator_priv;
-   char buf[52], buf2[4];
+   char buf[4+3*16+1], buf2[4];


Same CodingStyle issue here.


agreed.




int ret;
u8 reg;



Without having actually looking at the source code, would it be possible to
change the logic in order to use something else instead of a magic number for
buf size - e. g. using sizeof(something) ?


I am not sure if that's possible - the buffer is used for sprintf in a loop to 
store text representation of registers dump, before printk-ing it.


We could put there a comment, suggesting that 4 bytes are required for address 
prefix of form "00: ", then 16 strings of form "00 " (3 bytes each) and one byte 
for zero to terminate the string.


Or we could use sizeof, like this:
   char buf[sizeof("00: ") - 1 + 16 * (sizeof("00 ") - 1) + 1]
or
   char buf[sizeof("00: 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f ")]
but it is not very readable in my opinion either.

Maybe the best way would be to avoid the need for temporal buffer completely by 
directly using printk in a loop, that is only the first printk with KERN_DEBUG, 
followed by sequence of printk with registers dump and final printk with end of 
line (but isn't a printk without KERN_ facility coding style problem as well?).


I am not sure, what approach is the best - I just wanted to fix a bug, which did 
not allow to use my af9015 based tuner on mips platform. After that, Antti 
pointed out, that the same code with the same bug is also in other two sources, 
so I send the same fix for them as well...


Best regards,
Jan
--
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: Convert cpia driver to v4l2, drop parallel port version support?

2009-06-17 Thread Hans Verkuil

> On Wed, 2009-06-17 at 09:43 +0200, Hans Verkuil wrote:
>
>> > I personally think that loosing support for the parallel port
>> > version is ok given that the parallel port itslef is rapidly
>> > disappearing, what do you think ?
>>
>> I agree wholeheartedly. If we remove pp support, then we can also remove
>> the bw-qcam and c-qcam drivers since they too use the parallel port.
>
> Maybe I just like keeping old hardware up and running, but...
>
> I think it may be better to remove camera drivers when a majority of the
> actual camera hardware is likely to reach EOL, as existing parallel
> ports will likely outlive the cameras.

For sure. But these are really old webcams with correspondingly very poor
resolutions. I haven't been able to track one down on ebay and as far as I
know nobody has one of these beasts to test with. I can't see anyone using
parallel port webcams. I actually wonder whether these drivers still work.
And converting to v4l2 without having the hardware is very hard indeed.

Regards,

 Hans

>
> My PC I got in Dec 2005 has a parellel port, as does the motherboard I
> purchased 2008.
>
> I have a 802.11g router (ASUS WL-500g) with a parallel port.  It works
> nicely as a remote print server.  From my perspective, that parallel
> port isn't going away anytime soon.
>
>
> 
> At least the custom firmware for the WL-500g
> ( http://oleg.wl500g.info/ ) has the ability to use webcams for snapping
> pictures and emailing away a notification.  I'm pretty sure PP webcams
> are not actually supported though.
>
> The wireless router surveillance case is probably not relevant though,
> as routers are usually using (very) old kernels.
> 
>
> -Andy
>
>


-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] adding support for setting bus parameters in sub device

2009-06-17 Thread Hans Verkuil

> On Wed, 17 Jun 2009, Hans Verkuil wrote:
>
>> It is my strong opinion that while autonegotiation is easy to use, it is
>> not a wise choice to make. Filling in a single struct with the bus
>> settings to use for each board-subdev combination (usually there is only
>> one) is simple, straight-forward and unambiguous. And I really don't see
>> why that should take much time at all. And I consider it a very good
>> point
>> that the programmer is forced to think about this for a bit.
>
> Ok, my opinion is, that we should keep autonegotiation, but if you like,
> we can print a BIG-FAT-WARNING if both polarities are supported and no
> platform preference is set.

I'd rather see a message stating which bus settings were chosen. That way
if something fails in the future you can compare which bus settings were
chosen in the past with the new bus settings and see if something changed
there.

> I think, we've heard all opinions, unless someone would like to add
> something? Would it be fair to ask Mauro to make a decision? Or we can
> just count votes (which I would obviously prefer),

Obviously :-) Since the only non-soc driver that needs this right now is
tvp514x I'm pretty sure you'll get the most votes :-)

But this is something that should be decided on technical merits, and not
on what is easier for converting soc-camera. I'm not saying that is your
only or main reason for wanting to keep autonegotiation, but it no doubt
plays a role (perfectly understandable, BTW).

Just note that it is exactly my experiences with dm646x and with closely
working with the hardware team that made me realize the dangers of
autonegotiation. A year ago I would have agreed with you, but now I feel
very strongly that it is the wrong approach. Usually I would accept this
code, even if I thought it was not the optimal solution, in the interest
of finishing the conversion quickly. But I fear that if this goes in, then
it will be next to impossible to change in the future.

It simply boils down to this for me: I want to see unambiguous and
explicit bus settings in the code so the reader can safely assume that the
hardware was verified and/or certified for those settings. Even if you
just picked some settings because you didn't have access to the preferred
bus settings that the hardware manufacturer did his verification or
certification with, then that will still show which settings you used to
do your own testing. That's very important information to have in the
code.

Assuming that any autonegotiation code will always return the same result
is in my opinion wishful thinking. Look at the problems we have in
removing autoprobing from i2c: I'm pretty sure someone at the time also
thought that autoprobing would never cause a problem.

> but I'll accept Mauro's
> decision too.

That's fine by me as well.

Regards,

Hans

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG

--
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: Convert cpia driver to v4l2, drop parallel port version support?

2009-06-17 Thread Hans de Goede



On 06/17/2009 11:56 AM, Mauro Carvalho Chehab wrote:

Em Wed, 17 Jun 2009 09:43:50 +0200 (CEST)
"Hans Verkuil"  escreveu:


I recently have been bying second hand usb webcams left and right
one of them (a creative unknown model) uses the cpia1 chipset, and
works with the v4l1 driver currently in the kernel.

One of these days I would like to convert it to a v4l2 driver using
gspca as basis, this however will cause us to use parallel port support
(that or we need to keep the old code around for the parallel port
version).

I personally think that loosing support for the parallel port
version is ok given that the parallel port itslef is rapidly
disappearing, what do you think ?

I agree wholeheartedly. If we remove pp support, then we can also remove
the bw-qcam and c-qcam drivers since they too use the parallel port.


Maybe I'm too nostalgic, but those are the first V4L drivers. It would be fun
to keep supporting them with V4L2 API ;)

That's said, while it is probably not that hard to develop a gspca-pp driver,
I'm not against removing parallel port support or even removing those drivers
due to technical reasons, like the end of V4L1 drivers.

By looking at the remaining V4L1 drivers, we have:

ov511 - already implemented with V4L2 on gspca. Can be easily removed;



Yip, this one is a done deal :)


se401, stv680, usbvideo, vicam - USB V4L1 drivers. IMO, it is valuable
to convert them to gspca;



I've recently bought a (second hand) stv680 cam, haven't seriously tested it 
yet,
so I dunno if it works with the v4l1 driver. I agree it would be good to 
convert these,
and I can work on this as time permits, but I won't be converting code I don't 
have
HW to test for.

As for usbvideo that supports (amongst others) the st6422 (from the out of tree
qc-usb-messenger driver), but only one usb-id ??. I'm currently finishing up 
adding
st6422 support to gspca (with all known usb-id's), I have 2 different cams to 
test this with.

And indeed as mentioned in another mail we should also convert the w9968cf.


cpia2, pwc - supports both V4L1 and V4L2 API. It shouldn't be hard to 
convert them
to vidio_ioctl2 and remove V4L1 API.



I have a pwc cam , so I can test changes for pwc. btw current pwc oopses rather 
badly (GPF)
when unplugging the cam, I'll dig into this.


stradis - a saa7146 V4L1 only driver - I never understood this one 
well, since there is
already another saa7146 driver running V4L2, used by mxb, 
hexium_gemini and
hexium_orion. To make things worse, stradis, mxb and 
hexium_orion are registering for
the same PCI device (the generic saa7146 PCI ID). If nobody 
volunteers to convert
and test with V4L2, then maybe we can just remove it. The 
better conversion would
probably be to use the V4L2 support at the saa7146 driver.

arv - seems to be a VGA output driver - Only implements 3 ioctls:
VIDIOCGCAP and VIDIOCGWIN/VIDIOCSWIN. It shouldn't be hard to 
convert it to V4L2.
I'm not sure if this is still used in practice.

bw-qcam, pms, c-qcam, cpia, w9966 - very old drivers that use direct io 
and/or parport;

IMO, after having all USB ID's for se401, stv680, usbvideo and vicam devices 
supported
by a V4L2 driver, we can just remove V4L1 ioctls from cpia2 and pwc, and the 
drivers that
will still remain using only the legacy API can be dropped. Anything more 
converted will be a bonus



Big +1, having digged through many of these old drivers to convert them, they 
all seem rather crufty
and ugly and having them gone would be good.

While cleaning cruft, I would also like to see the following v4l2 drivers go 
away in time, they are all
from the same author (who mostly borrowed the reverse engineering work from the 
original out of tree
gspca) and he does not maintain them, and they all support cams also supported 
by the new gspca:

zc0301
only supports one usb-id which has not yet been tested with gspca, used to 
claim a lot more
usb-id's but didn't actually work with those as it only supported the bridge, 
not the sensor
-> remove it now ?

et61x251
Only supports using this bridge in combination with one type of sensor where as 
gspca
supports 2 type of sensors. gspca support is untested AFAIK.
-> ?

sn9c102
Supports a large number of cams also supported by gspca's sonixb / sonixj 
driver, we're using
#ifdef  macros to detect if both are being build at the same time to 
include usb-id's only
in one of the 2.

As seems normal for drivers from this author the driver used to claim a lot of 
usb-id's it
couldn't actually work with as it only supported the bridge, not the sensor. 
We've removed all
those and are now slowly moving over the remaining usb-ids to gspca as things 
get tested
with gspca.
-> Keep on moving over usb-id's then when only a few are left, drop it

Regards,

Hans
--
To unsubscribe from this l

Re: Convert cpia driver to v4l2, drop parallel port version support?

2009-06-17 Thread Andy Walls
On Wed, 2009-06-17 at 09:43 +0200, Hans Verkuil wrote:

> > I personally think that loosing support for the parallel port
> > version is ok given that the parallel port itslef is rapidly
> > disappearing, what do you think ?
> 
> I agree wholeheartedly. If we remove pp support, then we can also remove
> the bw-qcam and c-qcam drivers since they too use the parallel port.

Maybe I just like keeping old hardware up and running, but...

I think it may be better to remove camera drivers when a majority of the
actual camera hardware is likely to reach EOL, as existing parallel
ports will likely outlive the cameras.

My PC I got in Dec 2005 has a parellel port, as does the motherboard I
purchased 2008.

I have a 802.11g router (ASUS WL-500g) with a parallel port.  It works
nicely as a remote print server.  From my perspective, that parallel
port isn't going away anytime soon.



At least the custom firmware for the WL-500g
( http://oleg.wl500g.info/ ) has the ability to use webcams for snapping
pictures and emailing away a notification.  I'm pretty sure PP webcams
are not actually supported though.

The wireless router surveillance case is probably not relevant though,
as routers are usually using (very) old kernels.


-Andy

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] v4l: add cropping prototypes to struct v4l2_subdev_video_ops

2009-06-17 Thread Hans Verkuil

> Add g_crop, s_crop and cropcap methods to video v4l2-subdev operations.
>
> Signed-off-by: Guennadi Liakhovetski 
> ---
>
> Hans, is this all that's needed?

Reviewed-by: Hans Verkuil 

Regards,

   Hans

>
>  include/media/v4l2-subdev.h |3 +++
>  1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
> index 1785608..673a4e1 100644
> --- a/include/media/v4l2-subdev.h
> +++ b/include/media/v4l2-subdev.h
> @@ -215,6 +215,9 @@ struct v4l2_subdev_video_ops {
>   int (*g_fmt)(struct v4l2_subdev *sd, struct v4l2_format *fmt);
>   int (*try_fmt)(struct v4l2_subdev *sd, struct v4l2_format *fmt);
>   int (*s_fmt)(struct v4l2_subdev *sd, struct v4l2_format *fmt);
> + int (*cropcap)(struct v4l2_subdev *sd, struct v4l2_cropcap *cc);
> + int (*g_crop)(struct v4l2_subdev *sd, struct v4l2_crop *crop);
> + int (*s_crop)(struct v4l2_subdev *sd, struct v4l2_crop *crop);
>   int (*g_parm)(struct v4l2_subdev *sd, struct v4l2_streamparm *param);
>   int (*s_parm)(struct v4l2_subdev *sd, struct v4l2_streamparm *param);
>   int (*enum_framesizes)(struct v4l2_subdev *sd, struct v4l2_frmsizeenum
> *fsize);
> --
> 1.6.2.4
>
>


-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] v4l: add cropping prototypes to struct v4l2_subdev_video_ops

2009-06-17 Thread Hans Verkuil

> Add g_crop, s_crop and cropcap methods to video v4l2-subdev operations.
>
> Signed-off-by: Guennadi Liakhovetski 
> ---
>
> Hans, is this all that's needed?

Reviewed-by: Hans Verkuil 

Regards,

   Hans

>
>  include/media/v4l2-subdev.h |3 +++
>  1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
> index 1785608..673a4e1 100644
> --- a/include/media/v4l2-subdev.h
> +++ b/include/media/v4l2-subdev.h
> @@ -215,6 +215,9 @@ struct v4l2_subdev_video_ops {
>   int (*g_fmt)(struct v4l2_subdev *sd, struct v4l2_format *fmt);
>   int (*try_fmt)(struct v4l2_subdev *sd, struct v4l2_format *fmt);
>   int (*s_fmt)(struct v4l2_subdev *sd, struct v4l2_format *fmt);
> + int (*cropcap)(struct v4l2_subdev *sd, struct v4l2_cropcap *cc);
> + int (*g_crop)(struct v4l2_subdev *sd, struct v4l2_crop *crop);
> + int (*s_crop)(struct v4l2_subdev *sd, struct v4l2_crop *crop);
>   int (*g_parm)(struct v4l2_subdev *sd, struct v4l2_streamparm *param);
>   int (*s_parm)(struct v4l2_subdev *sd, struct v4l2_streamparm *param);
>   int (*enum_framesizes)(struct v4l2_subdev *sd, struct v4l2_frmsizeenum
> *fsize);
> --
> 1.6.2.4
>
>


-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG

--
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: Convert cpia driver to v4l2, drop parallel port version support?

2009-06-17 Thread Hans Verkuil

> Em Wed, 17 Jun 2009 09:43:50 +0200 (CEST)
> "Hans Verkuil"  escreveu:
>
>> > I recently have been bying second hand usb webcams left and right
>> > one of them (a creative unknown model) uses the cpia1 chipset, and
>> > works with the v4l1 driver currently in the kernel.
>> >
>> > One of these days I would like to convert it to a v4l2 driver using
>> > gspca as basis, this however will cause us to use parallel port
>> support
>> > (that or we need to keep the old code around for the parallel port
>> > version).
>> >
>> > I personally think that loosing support for the parallel port
>> > version is ok given that the parallel port itslef is rapidly
>> > disappearing, what do you think ?
>>
>> I agree wholeheartedly. If we remove pp support, then we can also remove
>> the bw-qcam and c-qcam drivers since they too use the parallel port.
>
> Maybe I'm too nostalgic, but those are the first V4L drivers. It would be
> fun
> to keep supporting them with V4L2 API ;)

I have a pms ISA card and it is still on my list to convert that one to
V4L2. Shouldn't be difficult. It is my understanding that that is the very
first v4l driver, so that should satisfy any nostalgic feelings :-)

> That's said, while it is probably not that hard to develop a gspca-pp
> driver,
> I'm not against removing parallel port support or even removing those
> drivers
> due to technical reasons, like the end of V4L1 drivers.
>
> By looking at the remaining V4L1 drivers, we have:
>
>   ov511 - already implemented with V4L2 on gspca. Can be easily removed;
>
>   se401, stv680, usbvideo, vicam - USB V4L1 drivers. IMO, it is valuable
>   to convert them to gspca;
>
>   cpia2, pwc - supports both V4L1 and V4L2 API. It shouldn't be hard to
> convert them
>   to vidio_ioctl2 and remove V4L1 API.
>
>   stradis - a saa7146 V4L1 only driver - I never understood this one well,
> since there is
>   already another saa7146 driver running V4L2, used by mxb, 
> hexium_gemini
> and
>   hexium_orion. To make things worse, stradis, mxb and 
> hexium_orion are
> registering for
>   the same PCI device (the generic saa7146 PCI ID). If nobody 
> volunteers
> to convert
>   and test with V4L2, then maybe we can just remove it. The better
> conversion would
>   probably be to use the V4L2 support at the saa7146 driver.
>
>   arv - seems to be a VGA output driver - Only implements 3 ioctls:
>   VIDIOCGCAP and VIDIOCGWIN/VIDIOCSWIN. It shouldn't be hard to 
> convert it
> to V4L2.
>   I'm not sure if this is still used in practice.
>
>   bw-qcam, pms, c-qcam, cpia, w9966 - very old drivers that use direct io
> and/or parport;
>
> IMO, after having all USB ID's for se401, stv680, usbvideo and vicam
> devices supported
> by a V4L2 driver, we can just remove V4L1 ioctls from cpia2 and pwc, and
> the drivers that
> will still remain using only the legacy API can be dropped. Anything more
> converted will be a bonus

I have a cpia2 device as well that I can use to test.

Regards,

Hans

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG

--
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: S_FMT vs. S_CROP

2009-06-17 Thread Guennadi Liakhovetski
On Wed, 10 Jun 2009, Hans Verkuil wrote:

> On Wednesday 10 June 2009 18:02:39 Guennadi Liakhovetski wrote:
> >
> > {G,S,TRY}_FMT configure output geometry in user pixels
> > [GS]_CROP, CROPCAP configure input window in sensor pixels
> 
> Agreed.

Now one more related question: if the driver (stack) can only scale down, 
and the user has requested either a crop smaller than current fmt, or fmt 
larger than current crop. What should the driver do? I can think of at 
least two reasonably logical behaviours:

1. adjust the last invalid request - either enlarge crop or reduce fmt
2. give fmt preference and adjust the source rectangle if needed

Which one is prererred?

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
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: Convert cpia driver to v4l2, drop parallel port version support?

2009-06-17 Thread Mauro Carvalho Chehab
Em Wed, 17 Jun 2009 06:56:21 -0300
Mauro Carvalho Chehab  escreveu:

> Em Wed, 17 Jun 2009 09:43:50 +0200 (CEST)
> "Hans Verkuil"  escreveu:
> 
> > > I recently have been bying second hand usb webcams left and right
> > > one of them (a creative unknown model) uses the cpia1 chipset, and
> > > works with the v4l1 driver currently in the kernel.
> > >
> > > One of these days I would like to convert it to a v4l2 driver using
> > > gspca as basis, this however will cause us to use parallel port support
> > > (that or we need to keep the old code around for the parallel port
> > > version).
> > >
> > > I personally think that loosing support for the parallel port
> > > version is ok given that the parallel port itslef is rapidly
> > > disappearing, what do you think ?
> > 
> > I agree wholeheartedly. If we remove pp support, then we can also remove
> > the bw-qcam and c-qcam drivers since they too use the parallel port.
> 
> Maybe I'm too nostalgic, but those are the first V4L drivers. It would be fun
> to keep supporting them with V4L2 API ;)
> 
> That's said, while it is probably not that hard to develop a gspca-pp driver,
> I'm not against removing parallel port support or even removing those drivers
> due to technical reasons, like the end of V4L1 drivers.
> 
> By looking at the remaining V4L1 drivers, we have:
> 
>   ov511 - already implemented with V4L2 on gspca. Can be easily removed;
> 
>   se401, stv680, usbvideo, vicam - USB V4L1 drivers. IMO, it is valuable
>   to convert them to gspca;

In time: w9968cf
> 
>   cpia2, pwc - supports both V4L1 and V4L2 API. It shouldn't be hard to 
> convert them
>   to vidio_ioctl2 and remove V4L1 API.
> 
>   stradis - a saa7146 V4L1 only driver - I never understood this one 
> well, since there is
>   already another saa7146 driver running V4L2, used by mxb, 
> hexium_gemini and
>   hexium_orion. To make things worse, stradis, mxb and 
> hexium_orion are registering for
>   the same PCI device (the generic saa7146 PCI ID). If nobody 
> volunteers to convert
>   and test with V4L2, then maybe we can just remove it. The 
> better conversion would
>   probably be to use the V4L2 support at the saa7146 driver.
> 
>   arv - seems to be a VGA output driver - Only implements 3 ioctls:
>   VIDIOCGCAP and VIDIOCGWIN/VIDIOCSWIN. It shouldn't be hard to 
> convert it to V4L2.
>   I'm not sure if this is still used in practice.
> 
>   bw-qcam, pms, c-qcam, cpia, w9966 - very old drivers that use direct io 
> and/or parport;
> 
> IMO, after having all USB ID's for se401, stv680, usbvideo and vicam devices 
> supported
> by a V4L2 driver, we can just remove V4L1 ioctls from cpia2 and pwc, and the 
> drivers that
> will still remain using only the legacy API can be dropped. Anything more 
> converted will be a bonus

So, the must do list seems to be:

se401, stv680, usbvideo, vicam and w9968cf.



Cheers,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Convert cpia driver to v4l2, drop parallel port version support?

2009-06-17 Thread Mauro Carvalho Chehab
Em Wed, 17 Jun 2009 09:43:50 +0200 (CEST)
"Hans Verkuil"  escreveu:

> > I recently have been bying second hand usb webcams left and right
> > one of them (a creative unknown model) uses the cpia1 chipset, and
> > works with the v4l1 driver currently in the kernel.
> >
> > One of these days I would like to convert it to a v4l2 driver using
> > gspca as basis, this however will cause us to use parallel port support
> > (that or we need to keep the old code around for the parallel port
> > version).
> >
> > I personally think that loosing support for the parallel port
> > version is ok given that the parallel port itslef is rapidly
> > disappearing, what do you think ?
> 
> I agree wholeheartedly. If we remove pp support, then we can also remove
> the bw-qcam and c-qcam drivers since they too use the parallel port.

Maybe I'm too nostalgic, but those are the first V4L drivers. It would be fun
to keep supporting them with V4L2 API ;)

That's said, while it is probably not that hard to develop a gspca-pp driver,
I'm not against removing parallel port support or even removing those drivers
due to technical reasons, like the end of V4L1 drivers.

By looking at the remaining V4L1 drivers, we have:

ov511 - already implemented with V4L2 on gspca. Can be easily removed;

se401, stv680, usbvideo, vicam - USB V4L1 drivers. IMO, it is valuable
to convert them to gspca;

cpia2, pwc - supports both V4L1 and V4L2 API. It shouldn't be hard to 
convert them
to vidio_ioctl2 and remove V4L1 API.

stradis - a saa7146 V4L1 only driver - I never understood this one 
well, since there is
already another saa7146 driver running V4L2, used by mxb, 
hexium_gemini and
hexium_orion. To make things worse, stradis, mxb and 
hexium_orion are registering for
the same PCI device (the generic saa7146 PCI ID). If nobody 
volunteers to convert
and test with V4L2, then maybe we can just remove it. The 
better conversion would
probably be to use the V4L2 support at the saa7146 driver.

arv - seems to be a VGA output driver - Only implements 3 ioctls:
VIDIOCGCAP and VIDIOCGWIN/VIDIOCSWIN. It shouldn't be hard to 
convert it to V4L2.
I'm not sure if this is still used in practice.

bw-qcam, pms, c-qcam, cpia, w9966 - very old drivers that use direct io 
and/or parport;

IMO, after having all USB ID's for se401, stv680, usbvideo and vicam devices 
supported
by a V4L2 driver, we can just remove V4L1 ioctls from cpia2 and pwc, and the 
drivers that
will still remain using only the legacy API can be dropped. Anything more 
converted will be a bonus



Cheers,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Convert cpia driver to v4l2, drop parallel port version support?

2009-06-17 Thread Hans de Goede



On 06/17/2009 09:43 AM, Hans Verkuil wrote:

Hi,

I recently have been bying second hand usb webcams left and right
one of them (a creative unknown model) uses the cpia1 chipset, and
works with the v4l1 driver currently in the kernel.

One of these days I would like to convert it to a v4l2 driver using
gspca as basis, this however will cause us to loose parallel port support
(that or we need to keep the old code around for the parallel port
version).

I personally think that loosing support for the parallel port
version is ok given that the parallel port itself is rapidly
disappearing, what do you think ?


I agree wholeheartedly. If we remove pp support, then we can also remove
the bw-qcam and c-qcam drivers since they too use the parallel port.



Ok :)


BTW, I also have a cpia1 camera available for testing. I can also test
ov511 (I saw that you added support for that to gspca). Ditto for the
stv680 and w9968cf.

Note that I can mail these devices to you if you want to work on
integrating them into gspca. I'm pretty sure I won't have time for that
myself.



Yes I want to work on integrating them into gspca (as time permits).
If you could mail them to me that would be great! Esp the w9968cf one,
once that is moved to gspca, we can get rid of the entire ovcamchip stuff
(eventually it would be good to move to a model where the sensor drivers
 are seperated again, but I'm waiting to see what comes out of the
 soc / ov7660 discussion for this).

I'll send my postal address in a private mail.

Regards,

Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] soc-camera: ov7670 merged multiple drivers and moved over to v4l2-subdev

2009-06-17 Thread Jonathan Cameron
Hans Verkuil wrote:
> On Tuesday 16 June 2009 16:45:04 Jonathan Cameron wrote:
>> Guennadi Liakhovetski wrote:
>>> On Mon, 15 Jun 2009, Jonathan Cameron wrote:
 From: Jonathan Cameron 

 OV7670 soc-camera driver. Merge of drivers from Jonathan Corbet,
 Darius Augulis and Jonathan Cameron
>>> Could you please, describe in more detail how you merged them?
>> Mostly by combining the various register sets and then adding pretty much
>> all the functionality in each of them, testing pretty much everything.
>>
>> Note that a lot of what was in those drivers (usually labeled as
>> untested) simply doesn't work and is based on 'magic' register sets
>> provided by omnivision.
>>
>>> However, I am not sure this is the best way to go. I think, a better
>>> approach would be to take a driver currently in the mainline, perhaps,
>>> the most feature-complete one if there are several of them there,
>> That is more or less what I've done (it's based on Jonathan Corbet's
>> driver). Darius' driver and mine have never been in mainline. Darius' was
>> a complete rewrite based on doc's he has under NDA.  Mine was based on
>> Jonathan Corbet's one with a few bits leveraged from a working tinyos
>> driver for the platform I'm using (principally because Omnivision are
>> ignoring both myself and the board supplier).
>>
>>> convert
>>> it and its user(s) to v4l2-subdev, extend it with any features missing
>>> in it and present in other drivers, then switch users of all other
>>> ov7670 drivers over to this one,
>> That's the problem. The only mainlined driver is specifically for an OLPC
>> machine.  The driver is tied to specific i2c device and doesn't use
>> anything anywhere near soc-camera or v4l2-subdev.
> 
> Yes, it does. ov7670.c was converted to v4l2-subdev in 2.6.30.
Ah! thanks for the heads up on that.
Some how I missed that entirely.
> 
>> While it would be nice to get a single driver working
>> for this hardware as well as more conventional soc-camera devices, it
>> isn't going to happen without a lot of input from someone with an olpc. 
>> The chip is interfaced through a Marvell 88alp101 'cafe' chip which does
>> a whole host of random things alongside being video processor and taking
>> a quick look at that would be written in a completely different fashion
>> if it were done now (mfd with subdevices etc, v4l2-sudev)
>>
>> So basically in the ideal world it would happen exactly as you've
>> suggested, but I doubt it'll happen any time soon and in the meantime
>> there is no in kernel support for those of us using the chip on other
>> platforms.
>>
>> *looks hopefully in the direction of Jonathan Corbet and other olpc
>> owners*
> 
> I have an olpc, but I still haven't had the time to setup a proper test 
> environment on it. However, I managed to clear my backlog of reviews in the 
> past few days so hopefully I can find some time this weekend to set it up.
Cool.
> 
>>> and finally make it work with soc-camera. This
>>> way you get a series of smaller and reviewable patches, instead of a
>>> completely new driver, that reproduces a lot of existing code but has
>>> to be reviewed anew. How does this sound?
>> Would be fine if the original driver (or anything terribly close to it)
>> were useable on a platform I actually have without more or less being
>> rewritten.
>>
>> I can back track the driver to be as close to that as possible and still
>> functional, but I'm not entirely sure it will make the code any easier to
>> review and you'll loose a lot the functionality lifted from Darius' as
>> my original drivers.
>>
>> The original posting I made was as close as you can reasonably get to
>> Jonathan's original driver.
>>
>> http://patchwork.kernel.org/patch/12192/
>>
>> At the time it wasn't really reviewed (beyond a few comments)
>> as you were just commencing the soc-camera conversion and it made
>> sense to wait for after that.
>>
>> I'm not really sure how we should proceed with this. I'm particularly
>> loath to touch the olpc driver unless we have a reasonable number of
>> people willing to test.
> 
> The current ov7670.c driver in the 2.6.30 tree (and the v4l-dvb repository) 
> is already v4l2_subdev based and should be reusable in other platforms, 
> including soc-camera once that has also been converted to use v4l2_subdev.
Excellent, I'll look at moving the functionality patches based on this driver
and Darius' on to that then.  Sorry for repeating some of your work, I somehow
completely forgot your original email saying this was on it's way!

Jonathan
--
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] v4l: add cropping prototypes to struct v4l2_subdev_video_ops

2009-06-17 Thread Guennadi Liakhovetski
Add g_crop, s_crop and cropcap methods to video v4l2-subdev operations.

Signed-off-by: Guennadi Liakhovetski 
---

Hans, is this all that's needed?

 include/media/v4l2-subdev.h |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
index 1785608..673a4e1 100644
--- a/include/media/v4l2-subdev.h
+++ b/include/media/v4l2-subdev.h
@@ -215,6 +215,9 @@ struct v4l2_subdev_video_ops {
int (*g_fmt)(struct v4l2_subdev *sd, struct v4l2_format *fmt);
int (*try_fmt)(struct v4l2_subdev *sd, struct v4l2_format *fmt);
int (*s_fmt)(struct v4l2_subdev *sd, struct v4l2_format *fmt);
+   int (*cropcap)(struct v4l2_subdev *sd, struct v4l2_cropcap *cc);
+   int (*g_crop)(struct v4l2_subdev *sd, struct v4l2_crop *crop);
+   int (*s_crop)(struct v4l2_subdev *sd, struct v4l2_crop *crop);
int (*g_parm)(struct v4l2_subdev *sd, struct v4l2_streamparm *param);
int (*s_parm)(struct v4l2_subdev *sd, struct v4l2_streamparm *param);
int (*enum_framesizes)(struct v4l2_subdev *sd, struct v4l2_frmsizeenum 
*fsize);
-- 
1.6.2.4

--
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: OMAP patches for linux-media

2009-06-17 Thread Mauro Carvalho Chehab
Em Wed, 17 Jun 2009 08:30:13 +0200
Hans Verkuil  escreveu:

> On Tuesday 16 June 2009 15:40:18 Mauro Carvalho Chehab wrote:
> > Hi Sakari and others,
> >
> > I'm seeing lots of patches and discussions for OMAP and DaVinci being
> > handled at the linux-media Mailing List, as part of the development
> > process of the open source drivers.
> >
> > However, it is hard to track all those discussions and be sure what
> > patches are ready for merging and what patches are just RFC.
> >
> > On the development model we use here, we have driver maintainers that are
> > responsible to discuss about improvements on their drivers. They are
> > generally the driver authors or the one that first started submitting the
> > patches for that driver(s).
> >
> > One of the roles of the driver maintainers is to collect the patches for
> > the drivers they maintain, merge on their trees, and periodically ask the
> > patch merge.
> >
> > One fundamental concept on Kernel development is the concept of "Commit
> > earlier and commit often", meaning that the better is to send small,
> > incremental, and periodic patches, than wait until having everything
> > done, then submit a big patch. Every time I receive a big patch I need to
> > postpone its analysis and open a big window on my schedule to analyze it.
> > Of course, this means to postpone it, and generally results on lots of
> > comments going back to developer, that, in turn, will need to do lots of
> > changes and return me back with another big patch for me to analyze
> > again, resulting on a long period of time for merging it.
> >
> > As you, Sakari, was the first one that started merging the OMAP drivers,
> > I was expecting that you would be the one that will handle the figure of
> > the driver maintainer for OMAP. I even created you an account at linuxtv
> > for you to create your trees there and ask me to merge from it.
> >
> > Unfortunately, you haven't sent me any pull requests yet along this year.
> > This is concerning me a lot, since, at the end, I'll need to review big
> > piles of patches and/or drivers when you decide to submit the final
> > version.
> >
> > So, I decided to send you this email, c/c a random list of people that I
> > believe are involved on the submit and/or review process of those
> > patches, in the hope to better understand and to discuss what's happening
> > and how can we speedup the merge process of those patches.
> 
> I have proposed this before, but I'll do it again: I'm more than happy to be 
> the official person who collects and organizes the omap and davinci patches 
> for you and who does the initial reviews. This is effectively already the 
> case since I've been reviewing both omap and davinci patches pretty much 
> from the beginning.

As I said before, in general the maintainer is the driver author or the first
submitter. Submitting patches for me is part of maintainer's hole. It is also a
maintainers responsibility to receive bug fixes and patches from other
developers and deal with them.

In the case where the chipset manufacturer is providing official support, it is
preferred if they are also handling this task. Of course they can delegate this
task to someone else.

While we are still bound to mercurial, the maintainer(s) should use it for
sending me pull requests, especially for a high traffic of patches like
what we're having. I hope we can migrate the development model to -git, but
this may still take some time.

>From my side, I'm ok if they prefer to delegate maintainer's task to you.
I'm also ok if they want to do by themselves. 

As there are multiple driver sets involved (OMAP, OMAP2, OMAP3, OMAP4, DaVinci),
eventually the task can be split on different maintainers, provided that I know
exactly who is maintaining what drivers.

Just let me know what fits better.

> Both the omap2/3 display driver and the davinci drivers are now very close 
> to be ready for inclusion in the kernel as my last reviews only found some 
> minor things.
>
> Part of the reason for the delays for both omap and davinci was that they 
> had to be modified for v4l2_subdev, which was an absolute necessity, and 
> because they simply needed quite a bit of work to make them suitable for 
> inclusion in the kernel.

Ok.



Cheers,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] adding support for setting bus parameters in sub device

2009-06-17 Thread Guennadi Liakhovetski
On Wed, 17 Jun 2009, Hans Verkuil wrote:

> It is my strong opinion that while autonegotiation is easy to use, it is
> not a wise choice to make. Filling in a single struct with the bus
> settings to use for each board-subdev combination (usually there is only
> one) is simple, straight-forward and unambiguous. And I really don't see
> why that should take much time at all. And I consider it a very good point
> that the programmer is forced to think about this for a bit.

Ok, my opinion is, that we should keep autonegotiation, but if you like, 
we can print a BIG-FAT-WARNING if both polarities are supported and no 
platform preference is set.

I think, we've heard all opinions, unless someone would like to add 
something? Would it be fair to ask Mauro to make a decision? Or we can 
just count votes (which I would obviously prefer), but I'll accept Mauro's 
decision too.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
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: How to handle v4l1 -> v4l2 driver transition

2009-06-17 Thread Mauro Carvalho Chehab
Em Wed, 17 Jun 2009 08:54:20 +0200
Hans de Goede  escreveu:

> Hi all,
> 
> I've recently been working on adding support for cams with the
> ov511(+) and ov518(+) to the gspca ov519 driver. I'm happy to
> announce that work is finished, see:
> http://linuxtv.org/hg/~hgoede/gspca
> 
> And the pull request I just send. This does lead to the question
> what to do with the existing  in kernel v4l1 ov511 driver, which
> claims to support these 2 bridges too (but since the decompression
> code has been removed actually only works with the 511 in uncompressed
> mode).
> 
> It is clear that the ov518 usb-id's should be removed from the ov511
> driver. But that still leaves the ov511 support, we could just completely
> remove the ov511 driver, as the code in gspca should cover all supported
> devices (and his been tested with a few).
> 
> However the downside of removing it is that people who used to have
> a working ov511 setup now will need to have a (very recent) libv4l
> to keep their setup working.
> 
> So I guess that the best way forward is to mark the driver as deprecated
> now and remove it in say 2 releases?

It seems a good strategy to me, provided that all USB ID's found at the
original ov511 are also present on gspca.

If so, please send the deprecate patch as well. I'll add it on my -git tree.

> 
> Regards,
> 
> Hans
> --
> 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




Cheers,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] adding support for setting bus parameters in sub device

2009-06-17 Thread Hans Verkuil

> On Mon, Jun 15, 2009 at 12:33 AM, Guennadi
> Liakhovetski wrote:
>> On Fri, 12 Jun 2009, Hans Verkuil wrote:
>>
>>> On Friday 12 June 2009 14:59:03 Guennadi Liakhovetski wrote:
>>> > On Fri, 12 Jun 2009, Hans Verkuil wrote:
>>> >
>>> > > > 1. it is very unusual that the board designer has to mandate what
>>> signal
>>> > > > polarity has to be used - only when there's additional logic
>>> between the
>>> > > > capture device and the host. So, we shouldn't overload all boards
>>> with
>>> > > > this information. Board-code authors will be grateful to us!
>>> > >
>>> > > I talked to my colleague who actually designs boards like that
>>> about what
>>> > > he would prefer. His opinion is that he wants to set this himself,
>>> rather
>>> > > than leave it as the result of a software negotiation. It
>>> simplifies
>>> > > verification and debugging the hardware, and in addition there may
>>> be
>>> > > cases where subtle timing differences between e.g. sampling on a
>>> falling
>>> > > edge vs rising edge can actually become an important factor,
>>> particularly
>>> > > on high frequencies.
>
> Let me guess, your coworker is a hardware designer? Letting hardware
> people do hardware design is usually a good idea, but I'm yet to see
> good software written by hardware people. =)

I agree. That's why I'm doing the software part :-)

>>> > I'd say this is different. You're talking about cases where you
>>> _want_ to
>>> > be able to configure it explicitly, I am saying you do not have to
>>> _force_
>>> > all to do this. Now, this selection only makes sense if both are
>>> > configurable, right? In this case, e.g., pxa270 driver does support
>>> > platform-specified preference. So, if both the host and the client
>>> can
>>> > configure either polarity in the software you _can_ still specify the
>>> > preferred one in platform data and it will be used.
>>> >
>>> > I think, the ability to specify inverters and the preferred polarity
>>> > should cover all possible cases.
>>>
>>> In my opinion you should always want to set this explicitly. This is
>>> not
>>> something you want to leave to chance. Say you autoconfigure this. Now
>>> someone either changes the autoconf algorithm, or a previously
>>> undocumented
>>> register was discovered for the i2c device and it can suddenly
>>> configure the
>>> polarity of some signal that was previously thought to be fixed, or
>>> something
>>> else happens causing a different polarity to be negotiated.
>>
>> TBH, the argumentation like "someone changes the autoconf algorithm" or
>> "previously undocumented register is discovered" doesn't convince me. In
>> any case, I am adding authors, maintainers and major contributors to
>> various soc-camera host drivers to CC and asking them to express their
>> opinion on this matter. I will not add anything else here to avoid any
>> "unfair competition":-) they will have to go a couple emails back in
>> this
>> thread to better understand what is being discussed here.
>
> I think automatic negotiation is a good thing if it is implemented
> correctly.
>
> Actually, i think modelling software after hardware is a good thing
> and from that perspective the soc_camera was (and still is) a very
> good fit for our on-chip SoC. Apart from host/sensor separation, the
> main benefits in my mind are autonegotiation and separate
> configuration for camera sensor, capture interface and board.
>
> I don't mind doing the same outside soc_camera, and I agree with Hans
> that in some cases it's nice to hard code and skip the "magic"
> negotiation. I'm however pretty sure the soc_camera allows hard coding
> though, so in that case you get the best of two worlds.

It is my strong opinion that while autonegotiation is easy to use, it is
not a wise choice to make. Filling in a single struct with the bus
settings to use for each board-subdev combination (usually there is only
one) is simple, straight-forward and unambiguous. And I really don't see
why that should take much time at all. And I consider it a very good point
that the programmer is forced to think about this for a bit.

Regards,

Hans

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] [09051_49] Siano: smscore - upgrade firmware loading engine

2009-06-17 Thread Udi Atar
On Tue, Jun 16, 2009 at 7:44 PM, Mauro Carvalho
Chehab wrote:
> Em Tue, 16 Jun 2009 15:39:01 +0300
> "Udi Atar"  escreveu:
>
>> The README.patches file in v4l-dvb clearly states that it is OK to use 
>> version checking to allow backporting.
>>
>> 
>> k) Sometimes it is necessary to introduce some testing code inside a
>>    module or remove parts that are not yet finished. Also, compatibility
>>    tests may be required to provide backporting.
>>
>>    To allow compatibility tests, linux/version.h is automatically
>>    included by the building system. This allows adding tests like:
>>
>>       #if LINUX_VERSION_CODE >= KERNEL_VERSION(2, 6, 16)
>>       #include 
>>       #else
>>       #include 
>>       #endif
>> 
>>
>> The patch allows older version of the kernel, and embedded platforms, that 
>> choose not to include the "request firmware" mechanism to continue working 
>> with the Siano driver.
>
> I don't see a big issue with this, provided that this won't affect the 
> upstream driver.
>
>> As for the SMS_HOSTLIB_SUBSYS, the Siano driver supports standards which are 
>> not currently implemented in V4L (i.e. CMMB). I see no reason why we should 
>> create a duplicate driver for DVB-T and CMMB, if the codebase is exactly the 
>> same.
>
> The proper way is to add support for those standards at DVB API, instead of
> using a proprietary API.
>
> In order to keep the merging process of the pending patches, I suggest you to
> remove the the SMS_HOSTLIB_SUBSYS part from this patch and re-submit the
> pending ones up to the point where the only pending issue to sync your 
> codebase
> with kernel being the API for those non-supported standards. After that, we 
> can
> discuss the API improvement needs to support the missing standards.
>>
>> Best regards,
>> Udi Atar
>>
>>
>> -Original Message-
>> From: linux-media-ow...@vger.kernel.org 
>> [mailto:linux-media-ow...@vger.kernel.org] On Behalf Of Michael Krufky
>> Sent: Tuesday, May 19, 2009 7:24 PM
>> To: Uri Shkolnik
>> Cc: LinuxML; Mauro Carvalho Chehab
>> Subject: Re: [PATCH] [09051_49] Siano: smscore - upgrade firmware loading 
>> engine
>>
>> On Tue, May 19, 2009 at 11:43 AM, Uri Shkolnik  wrote:
>> >
>> > # HG changeset patch
>> > # User Uri Shkolnik 
>> > # Date 1242748115 -10800
>> > # Node ID 4d75f9d1c4f96d65a8ad312c21e488a212ee58a3
>> > # Parent  cfb4106f3ceaee9fe8f7e3acc9d4adec1baffe5e
>> > [09051_49] Siano: smscore - upgrade firmware loading engine
>> >
>> > From: Uri Shkolnik 
>> >
>> > Upgrade the firmware loading (download and switching) engine.
>> >
>> > Priority: normal
>> >
>> > Signed-off-by: Uri Shkolnik 
>> >
>> > diff -r cfb4106f3cea -r 4d75f9d1c4f9 
>> > linux/drivers/media/dvb/siano/smscoreapi.c
>> > --- a/linux/drivers/media/dvb/siano/smscoreapi.c        Tue May 19 
>> > 18:38:07 2009 +0300
>> > +++ b/linux/drivers/media/dvb/siano/smscoreapi.c        Tue May 19 
>> > 18:48:35 2009 +0300
>> > @@ -28,7 +28,7 @@
>> >  #include 
>> >  #include 
>> >  #include 
>> > -
>> > +#include 
>> >  #include 
>> >  #include 
>> >  #include 
>> > @@ -36,7 +36,13 @@
>> >  #include "smscoreapi.h"
>> >  #include "sms-cards.h"
>> >  #include "smsir.h"
>> > -#include "smsendian.h"
>> > +#define MAX_GPIO_PIN_NUMBER    31
>> > +
>> > +#if LINUX_VERSION_CODE >= KERNEL_VERSION(2, 6, 10)
>> > +#define REQUEST_FIRMWARE_SUPPORTED
>> > +#else
>> > +#define DEFAULT_FW_FILE_PATH "/lib/firmware"
>> > +#endif
>> >
>> >  static int sms_dbg;
>> >  module_param_named(debug, sms_dbg, int, 0644);
>> > @@ -459,8 +465,6 @@ static int smscore_init_ir(struct smscor
>> >                                msg->msgData[0] = coredev->ir.controller;
>> >                                msg->msgData[1] = coredev->ir.timeout;
>> >
>> > -                               smsendian_handle_tx_message(
>> > -                                       (struct SmsMsgHdr_ST2 *)msg);
>> >                                rc = smscore_sendrequest_and_wait(coredev, 
>> > msg,
>> >                                                msg->xMsgHeader. msgLength,
>> >                                                &coredev->ir_init_done);
>> > @@ -486,12 +490,16 @@ static int smscore_init_ir(struct smscor
>> >  */
>> >  int smscore_start_device(struct smscore_device_t *coredev)
>> >  {
>> > -       int rc = smscore_set_device_mode(
>> > -                       coredev, 
>> > smscore_registry_getmode(coredev->devpath));
>> > +       int rc;
>> > +
>> > +#ifdef REQUEST_FIRMWARE_SUPPORTED
>> > +       rc = smscore_set_device_mode(coredev, smscore_registry_getmode(
>> > +                       coredev->devpath));
>> >        if (rc < 0) {
>> > -               sms_info("set device mode faile , rc %d", rc);
>> > +               sms_info("set device mode failed , rc %d", rc);
>> >                return rc;
>> >        }
>> > +#endif
>> >
>> >        kmutex_lock(&g_smsc

Re: [PATCH RFC] adding support for setting bus parameters in sub device

2009-06-17 Thread Magnus Damm
On Tue, Jun 16, 2009 at 11:33 PM, Karicheri,
Muralidharan wrote:
>
> 
>>>
>>> [MK]In that case can't the driver just ignore the field polarity? I
>>assume that drivers implement the parameter that has support in hardware.
>>So it is not an issue.
>>
>>No, because the same driver runs on hardware that also has the field
>>signal. So we need to be able to give information about which signals
>>that the board actually implement. We already do this with the
>>soc_camera framework and it is working just fine.
>
>
> Hardware with field signal used (driver use polarity from platform data and 
> set it in the hardware)
> Hardware with field signal not used (In this case, even though the driver 
> sets it in the hardware, it is not really used in the hardware design and 
> hence is a don't care. right?
>
> So I don't see why it matters.

Maybe I'm misunderstanding what you are trying to do. But how can the
camera sensor driver check if the field signal is present or not? The
camera sensor driver may need information if a pin is present or not
for some decision? Perhaps for hardware configuration?

A good example IMO is the tw9910 driver and the mpout signal. Right
now the mpout configuration is part of the platform data, but maybe it
would make more sense to allow the driver to check if field is used on
the platform and if so configure the pin accordingly.

/ magnus
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] adding support for setting bus parameters in sub device

2009-06-17 Thread Magnus Damm
On Mon, Jun 15, 2009 at 12:33 AM, Guennadi
Liakhovetski wrote:
> On Fri, 12 Jun 2009, Hans Verkuil wrote:
>
>> On Friday 12 June 2009 14:59:03 Guennadi Liakhovetski wrote:
>> > On Fri, 12 Jun 2009, Hans Verkuil wrote:
>> >
>> > > > 1. it is very unusual that the board designer has to mandate what 
>> > > > signal
>> > > > polarity has to be used - only when there's additional logic between 
>> > > > the
>> > > > capture device and the host. So, we shouldn't overload all boards with
>> > > > this information. Board-code authors will be grateful to us!
>> > >
>> > > I talked to my colleague who actually designs boards like that about what
>> > > he would prefer. His opinion is that he wants to set this himself, rather
>> > > than leave it as the result of a software negotiation. It simplifies
>> > > verification and debugging the hardware, and in addition there may be
>> > > cases where subtle timing differences between e.g. sampling on a falling
>> > > edge vs rising edge can actually become an important factor, particularly
>> > > on high frequencies.

Let me guess, your coworker is a hardware designer? Letting hardware
people do hardware design is usually a good idea, but I'm yet to see
good software written by hardware people. =)

>> > I'd say this is different. You're talking about cases where you _want_ to
>> > be able to configure it explicitly, I am saying you do not have to _force_
>> > all to do this. Now, this selection only makes sense if both are
>> > configurable, right? In this case, e.g., pxa270 driver does support
>> > platform-specified preference. So, if both the host and the client can
>> > configure either polarity in the software you _can_ still specify the
>> > preferred one in platform data and it will be used.
>> >
>> > I think, the ability to specify inverters and the preferred polarity
>> > should cover all possible cases.
>>
>> In my opinion you should always want to set this explicitly. This is not
>> something you want to leave to chance. Say you autoconfigure this. Now
>> someone either changes the autoconf algorithm, or a previously undocumented
>> register was discovered for the i2c device and it can suddenly configure the
>> polarity of some signal that was previously thought to be fixed, or something
>> else happens causing a different polarity to be negotiated.
>
> TBH, the argumentation like "someone changes the autoconf algorithm" or
> "previously undocumented register is discovered" doesn't convince me. In
> any case, I am adding authors, maintainers and major contributors to
> various soc-camera host drivers to CC and asking them to express their
> opinion on this matter. I will not add anything else here to avoid any
> "unfair competition":-) they will have to go a couple emails back in this
> thread to better understand what is being discussed here.

I think automatic negotiation is a good thing if it is implemented correctly.

Actually, i think modelling software after hardware is a good thing
and from that perspective the soc_camera was (and still is) a very
good fit for our on-chip SoC. Apart from host/sensor separation, the
main benefits in my mind are autonegotiation and separate
configuration for camera sensor, capture interface and board.

I don't mind doing the same outside soc_camera, and I agree with Hans
that in some cases it's nice to hard code and skip the "magic"
negotiation. I'm however pretty sure the soc_camera allows hard coding
though, so in that case you get the best of two worlds.

Cheers,

/ magnus
--
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: Convert cpia driver to v4l2, drop parallel port version support?

2009-06-17 Thread Hans Verkuil

> Hi,
>
> I recently have been bying second hand usb webcams left and right
> one of them (a creative unknown model) uses the cpia1 chipset, and
> works with the v4l1 driver currently in the kernel.
>
> One of these days I would like to convert it to a v4l2 driver using
> gspca as basis, this however will cause us to use parallel port support
> (that or we need to keep the old code around for the parallel port
> version).
>
> I personally think that loosing support for the parallel port
> version is ok given that the parallel port itslef is rapidly
> disappearing, what do you think ?

I agree wholeheartedly. If we remove pp support, then we can also remove
the bw-qcam and c-qcam drivers since they too use the parallel port.

BTW, I also have a cpia1 camera available for testing. I can also test
ov511 (I saw that you added support for that to gspca). Ditto for the
stv680 and w9968cf.

Note that I can mail these devices to you if you want to work on
integrating them into gspca. I'm pretty sure I won't have time for that
myself.

Regards,

   Hans

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG

--
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: [PULL] generic image bounds setting and alignment function

2009-06-17 Thread Guennadi Liakhovetski
On Tue, 16 Jun 2009, Trent Piepho wrote:

> On Tue, 16 Jun 2009, Mauro Carvalho Chehab wrote:
> > Em Tue, 16 Jun 2009 17:57:20 +0200 (CEST)
> > Guennadi Liakhovetski  escreveu:
> > > On Sat, 30 May 2009, Trent Piepho wrote:
> > > + if (walign + halign < salign) {
> > > + /* Max walign where there is still a valid width */
> > > + unsigned int wmaxa = __fls(wmax ^ (wmin - 1));
> > >
> > > I cannot follow correctness of the above, sorry. Take a simple example:
> > > wmax=0x7f, wmin=7, wmaxa = __fls(0x7f ^ 6) = __fls(0x79) = 0. And the
> > > comment says it's the "maximum walign where there is still a valid width."
> > > What am I missing?
> > >
> > > +
> > > + /* up the smaller alignment until we have enough */
> > > + do {
> > > + if (walign <= halign && walign < wmaxa) {
> > >
> >
> > As I'm still cooking the patches, I prefer to postpone the align ones until 
> > we
> > are comfortable with them.
> >
> > Trent,
> >
> > Could you please take a look on the above comments
> 
> There is no bug with the wmaxa code, but there is a different bug
> elsewhere.
> 
> Please pull from http://linuxtv.org/hg/~tap/fix
> 
> for the following changeset:
> 
> 01/01: v4l2: Fix flaw in alignment code
> http://linuxtv.org/hg/~tap/fix?cmd=changeset;node=4ef7fb102b6c

/* up the smaller alignment until we have enough */
do {
-   if (walign <= halign && walign < wmaxa) {
+   if (halign >= hmaxa ||
+   (walign <= halign && walign < wmaxa)) {

Do I understand it right now, that as soon as your halign now reaches 
hmaxa, you'll stop incrementing halign and then keep incrementing walign 
even beyond wmaxa?...

*w = clamp_align(*w, wmin, wmax, walign + 1);
walign = __ffs(*w);
} else {

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
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