date:20120105

On Thu, Jan 5, 2012 at 6:16 PM, Dmitriy Fitisov  wrote:
> Hello everyone,
> I know, Devin Heitmueller was about to add support  for em2874 bulk endpoint.
>
> Is that still in plans?

The project that I was slated to do this work for got cancelled, and
the only device I know of that requires bulk support is an obscure
K-world product.  It just didn't make any sense to waste the time for
one unpopular stick.

Regards,

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.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 0/5] Fix dvb-core set_delivery_system and port drxk to one frontend

On 05-01-2012 16:38, Lars Hanisch wrote:
> Hi,
> 
>  First: I'm no driver but an application developer.
> 
> Am 05.01.2012 17:40, schrieb Devin Heitmueller:
>> On Thu, Jan 5, 2012 at 10:37 AM, Mauro Carvalho Chehab
>>   wrote:
>>> With all these series applied, it is now possible to use frontend 0
>>> for all delivery systems. As the current tools don't support changing
>>> the delivery system, the dvb-fe-tool (on my experimental tree[1]) can now
>>> be used to change between them:
>>
>> Hi Mauro,
>>
>> While from a functional standpoint I think this is a good change (and
>> we probably should have done it this way all along), is there not
>> concern that this could be interpreted by regular users as a
>> regression?  Right now they get two frontends, and they can use all
>> their existing tools.  We're moving to a model where if users upgraded
>> their kernel they would now require some new userland tool to do
>> something that the kernel was allowing them to do previously.
>>
>> Sure, it's not "ABI breakage" in the classic sense but the net effect
>> is the same - stuff that used to work stops working and now they need
>> new tools or to recompile their existing tools to include new
>> functionality (which as you mentioned, none of those tools have
>> today).
> 
> Since now there isn't any consistent behaviour of hybrid multifrontend 
> devices.
> Some create multiple frontends but only one demux/dvr (like drx-k), others 
> create 
> all devices for every delivery system (HVR 4000). But they all could only be 
> opened 
> mutually exclusive. In case of vdr (my favourite app) you have to trick with 
> udev,
> symlinks, "remove unwanted frontends" etc. to get the devices in a shape so 
> the 
> application can use it. I don't know how mythtv is handling such devices, but 
> I 
> think there will be something like driver-dependend code in the one or other 
> way.
> 
> The spec isn't really meaningful for hybrid devices. Maybe we should start 
> there and claim something the driver developer can follow.

We had some discussions about that at the KS workshop. All people there
agreed that the better is to use one frontend by physical device.

So, in the end of the day, all drivers should behave like what those DRX-K
patches are doing.

>> Perhaps you would consider some sort of module option that would let
>> users fall back to the old behavior?
> 
>  That would be fine but better would be a module option that will 
>  initialize frontend0 to the "connected" delivery system. In case of DVB-C/-T
>  you don't switch frequently from one to the other. You would need extra 
> hardware 
>  like a splitter which switches inputs if there are e.g. 5V for an active 
> antenna
>  (which means: switch to the dvb-t-input). Is there any DVB-T card which can 
> supply
>  such voltage? And is it controllable via an ioctl (like LNB power supply in 
> DVB-S)?

This is called LNA. A proper LNA support is missing. I think we should 
add a DVBv5 property to control it, on the devices that supports this feature.

The DRX-K chips described at the drxk_hard.c don't support such feature, but
there are other devices that supports it.

Btw, there are some DRX-K devices with two separate demods and two separate
frontends. A driver option won't work on such devices, as one frontend may
be connected to DVB-C, and the other one to DVB-T.

Also, the user may have more than one device of the same type (I have 3 sticks 
here
with em28xx/drx-k) that could be used simultaneously. Again, a modprobe
parameter won't fit, if the user wants to use some devices for one type, and
the other ones for the second type.

> 
>  Anyway, I think, if there's finally a solution so all drivers behave the 
> same,
>  the tools and applications will handle this new model in the near future.

Yes, that's what we expect ;)

The DTV_ENUM_DELSYS and DTV_DELIVERY_SYSTEM properties are enough to
properly support such devices.
> 
>  Please do something... :-)
> 
> Regards,
> Lars.
> 
>>
>> Devin
>>
> -- 
> 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

em2874 bulk endpoint support

2012-01-05 Thread Dmitriy Fitisov

Hello everyone,
I know, Devin Heitmueller was about to add support  for em2874 bulk endpoint.

Is that still in plans?

Thank you.
Dmitriy 

Copying old thread:
> On Oct 29, 2010, at 2:37 PM, Devin Heitmueller wrote:
>
> > On Fri, Oct 29, 2010 at 2:04 PM, Jarod Wilson  wrote:
> >> On Oct 15, 2010, at 6:07 PM, Jarod Wilson wrote:...
> >> So a spot of bad news here... I've been poking at one of Gavin's sticks 
> >> inside a VM he set up for me, simultaneous with talking to one of the 
> >> upstream em28xx driver authors. We now have a very good understanding of 
> >> why the stick isn't working.
> >> 
> >> All known prior em28xx-based tuner sticks have had at least one 
> >> isochronous usb endpoint, with a max packet size of 940 bytes, typically. 
> >> This stick only has bulk usb endpoints and a max packet size of 512. 
> >> Supporting this stick is actually going to require a fair bit of work in 
> >> the em28xx driver core to support using bulk transfer instead of 
> >> isochronous transfer.
> >> 
> >> Short version: don't buy this stick right now, its going to be a little 
> >> while before its actually supported.
> > 
> > Jarod,
> > 
> > Just an FYI:  bulk support for em2874/em2884 is on my todo list for
> > the near future.
>
>
 Ah, very cool. I'm inclined to wait and let you do that part, since you know 
em28xx much better than I do, and I'll just focus on the device-specific 
implementation details (gpio settings, wiring up tuner and demod, etc). I'm 
assuming you have some other manufacturer's em2874/em2884 based devices to work 
on this for... :)


--
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: Support for RC-6 in em28xx driver?

On Thu, Jan 5, 2012 at 11:51 PM, Devin Heitmueller
 wrote:
> On Thu, Jan 5, 2012 at 5:48 PM, Devin Heitmueller
>  wrote:
>> Yes, it can.  Like almost every IR receiver provided by the linux
>> media subsystem, the 290e is configured with the keymap of the
>> pinnacle remote *by default*.  There are userland tools (e.g.
>> ir-keytable) which allow you to load keymaps in for other remotes.
>
> I should clarify my previous statement by saying that the support for
> other remotes is constrained by what the hardware supports.  If the IR
> receiver hardware only supports RC5 and NEC, then you can't use an RC6
> remote with it.
>
> But to your point, I actually used my Hauppauge remote when I
> originally wrote the em2874 IR support (and only at the end
> reconfigured it to use the PCTV remote).
>
> Devin
>

Chris,

If the driver supported RC6 out of the box, the I should be able to
use the hp remote on my mythbuntu machine:

sudo ir-keytable -p rc-6 -c -w /lib/udev/rc_keymaps/rc6_mce

/etc/rc_maps.cfg could be updated to make the choice permanent

Br,
/Simon
--
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: Support for RC-6 in em28xx driver?

2012/1/5 Devin Heitmueller :
> 2012/1/5 Simon Søndergaard :
>> 2012/1/5 Devin Heitmueller :
>>> 2012/1/5 Simon Søndergaard :
 Hi,

 I recently purchased a PCTV 290e USB Stick (em28174) it comes with a
 remote almost as small as the stick itself... I've been able to get
 both stick and remote to work. I also own an MCE media center remote
 from HP (this make
 http://www.ebay.com/itm/Original-Win7-PC-MCE-Media-Center-HP-Remote-Controller-/170594956920)
 that sends RC-6 codes. While it do have a windows logo I still think
 it is vastly superior to the one that shipped with the stick :-)

 If I understand it correctly em28174 is a derivative of em2874?

 In em28xx-input.c it is stated that: "em2874 supports more protocols.
 For now, let's just announce the two protocols that were already
 tested"

 I've been searching high and low for a datasheet for em28(1)74, but
 have been unable to find it online. Do anyone know if one of the
 protocols supported is RC-6? and if so how do I get a copy of the
 datasheet?
>>>
>>> The 2874 supports NEC, RC-5, and RC-6/6A.  I did the original support
>>> (based on the docs provided under NDA) but ironically enough I didn't
>>> have an RC6 remote kicking around so I didn't do the support for it.
>>>
>>> IR receivers for MCE devices are dirt cheap (< $20), and if you're
>>> doing a media center then it's likely the PCTV 290e probably isn't in
>>> line-of-site for a remote anyway.
>>
>> The 290e will be in line of sight.
>>
>> Perhaps the info is already there, not sure why I overlooked it in the
>> first place:
>>
>> EM2874_IR_RC6_MODE_0    0x08
>> EM2874_IR_RC6_MODE_6A 0x0b
>
> Ah, so I guess I did put at least some of the info into the driver.
> Also, for RC6 make sure bits 0-1 are 00 and for RC6A they need to be
> set based on the number of bytes expected to be received (2 bytes=00,
> 3bytes=01, 4bytes=10).  The received data gets stored in 0x52-0x55 (I
> don't remember if the driver actually looks are 0x54/55 currently
> since they aren't used for NEC or RC5)..
>

The driver already reads up to 0x55.

Do you mean bits 0-1 of EM2874_R50_IR_CONFIG? The Driver code and the
defines above is in LSB 0 syntax, so bit 0-1 would overlap with the
0x0b value... Regardless I tried using 0x8b, 0x4b, 0x0b, 0x0a and 0x09
as the value for EM2874_R50_IR_CONFIG, but I never observed any
changes to EM2874_R51_IR :-(

I'm assuming that read count should still be read from EM2874_R51_IR
regardless of the mode

Br,
/Simon
--
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: Support for RC-6 in em28xx driver?

2012-01-05 Thread Chris Rankin


Hi,

As someone who also owns a PCTV 290e device, I must agree that the remote 
control that it ships with is useless for VDR. Its biggest flaw is a lack of 
red, green, yellow and blue buttons, unlike the very nice remote control that 
ships with the Hauppauge NOVA-T2.


Are you suggesting that the 290e could (potentially) use *any* NEC, RC-5 or 
RC-6/6A remote control, please? Because I would find that "useful"... ;-).


Cheers,
Chris
--
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: Support for RC-6 in em28xx driver?

On Thu, Jan 5, 2012 at 5:48 PM, Devin Heitmueller
 wrote:
> Yes, it can.  Like almost every IR receiver provided by the linux
> media subsystem, the 290e is configured with the keymap of the
> pinnacle remote *by default*.  There are userland tools (e.g.
> ir-keytable) which allow you to load keymaps in for other remotes.

I should clarify my previous statement by saying that the support for
other remotes is constrained by what the hardware supports.  If the IR
receiver hardware only supports RC5 and NEC, then you can't use an RC6
remote with it.

But to your point, I actually used my Hauppauge remote when I
originally wrote the em2874 IR support (and only at the end
reconfigured it to use the PCTV remote).

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.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: Support for RC-6 in em28xx driver?

On Thu, Jan 5, 2012 at 5:44 PM, Chris Rankin  wrote:
> Hi,
>
> As someone who also owns a PCTV 290e device, I must agree that the remote
> control that it ships with is useless for VDR. Its biggest flaw is a lack of
> red, green, yellow and blue buttons, unlike the very nice remote control
> that ships with the Hauppauge NOVA-T2.
>
> Are you suggesting that the 290e could (potentially) use *any* NEC, RC-5 or
> RC-6/6A remote control, please? Because I would find that "useful"... ;-).

Hi Chris,

Yes, it can.  Like almost every IR receiver provided by the linux
media subsystem, the 290e is configured with the keymap of the
pinnacle remote *by default*.  There are userland tools (e.g.
ir-keytable) which allow you to load keymaps in for other remotes.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.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: Support for RC-6 in em28xx driver?

2012/1/5 Simon Søndergaard :
> 2012/1/5 Devin Heitmueller :
>> 2012/1/5 Simon Søndergaard :
>>> Hi,
>>>
>>> I recently purchased a PCTV 290e USB Stick (em28174) it comes with a
>>> remote almost as small as the stick itself... I've been able to get
>>> both stick and remote to work. I also own an MCE media center remote
>>> from HP (this make
>>> http://www.ebay.com/itm/Original-Win7-PC-MCE-Media-Center-HP-Remote-Controller-/170594956920)
>>> that sends RC-6 codes. While it do have a windows logo I still think
>>> it is vastly superior to the one that shipped with the stick :-)
>>>
>>> If I understand it correctly em28174 is a derivative of em2874?
>>>
>>> In em28xx-input.c it is stated that: "em2874 supports more protocols.
>>> For now, let's just announce the two protocols that were already
>>> tested"
>>>
>>> I've been searching high and low for a datasheet for em28(1)74, but
>>> have been unable to find it online. Do anyone know if one of the
>>> protocols supported is RC-6? and if so how do I get a copy of the
>>> datasheet?
>>
>> The 2874 supports NEC, RC-5, and RC-6/6A.  I did the original support
>> (based on the docs provided under NDA) but ironically enough I didn't
>> have an RC6 remote kicking around so I didn't do the support for it.
>>
>> IR receivers for MCE devices are dirt cheap (< $20), and if you're
>> doing a media center then it's likely the PCTV 290e probably isn't in
>> line-of-site for a remote anyway.
>
> The 290e will be in line of sight.
>
> Perhaps the info is already there, not sure why I overlooked it in the
> first place:
>
> EM2874_IR_RC6_MODE_0    0x08
> EM2874_IR_RC6_MODE_6A 0x0b

Ah, so I guess I did put at least some of the info into the driver.
Also, for RC6 make sure bits 0-1 are 00 and for RC6A they need to be
set based on the number of bytes expected to be received (2 bytes=00,
3bytes=01, 4bytes=10).  The received data gets stored in 0x52-0x55 (I
don't remember if the driver actually looks are 0x54/55 currently
since they aren't used for NEC or RC5)..

> RC5 and RC6 use same carrier frequency? so do I need another value for
> EM28XX_R0F_XCLK?

You shouldn't need to touch the XCLK register.

Good luck!

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.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: Support for RC-6 in em28xx driver?

2012/1/5 Devin Heitmueller :
> 2012/1/5 Simon Søndergaard :
>> Hi,
>>
>> I recently purchased a PCTV 290e USB Stick (em28174) it comes with a
>> remote almost as small as the stick itself... I've been able to get
>> both stick and remote to work. I also own an MCE media center remote
>> from HP (this make
>> http://www.ebay.com/itm/Original-Win7-PC-MCE-Media-Center-HP-Remote-Controller-/170594956920)
>> that sends RC-6 codes. While it do have a windows logo I still think
>> it is vastly superior to the one that shipped with the stick :-)
>>
>> If I understand it correctly em28174 is a derivative of em2874?
>>
>> In em28xx-input.c it is stated that: "em2874 supports more protocols.
>> For now, let's just announce the two protocols that were already
>> tested"
>>
>> I've been searching high and low for a datasheet for em28(1)74, but
>> have been unable to find it online. Do anyone know if one of the
>> protocols supported is RC-6? and if so how do I get a copy of the
>> datasheet?
>
> The 2874 supports NEC, RC-5, and RC-6/6A.  I did the original support
> (based on the docs provided under NDA) but ironically enough I didn't
> have an RC6 remote kicking around so I didn't do the support for it.
>
> IR receivers for MCE devices are dirt cheap (< $20), and if you're
> doing a media center then it's likely the PCTV 290e probably isn't in
> line-of-site for a remote anyway.

The 290e will be in line of sight.

Perhaps the info is already there, not sure why I overlooked it in the
first place:

EM2874_IR_RC6_MODE_00x08
EM2874_IR_RC6_MODE_6A 0x0b

RC5 and RC6 use same carrier frequency? so do I need another value for
EM28XX_R0F_XCLK?

Br,
/Simon

 That said, if you still really want
> to see it supported I can probably find a couple of hours to do it (or
> walk Mauro through the register differences if he cares to).
>
> Devin
>
> --
> Devin J. Heitmueller - Kernel Labs
> http://www.kernellabs.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 2/3] drxk: correction frontend attatching

On 18-12-2011 04:05, Stefan Ringel wrote:
> Am 18.12.2011 00:47, schrieb Oliver Endriss:
>> On Sunday 18 December 2011 00:39:49 Oliver Endriss wrote:
>>> On Saturday 17 December 2011 21:57:16 linu...@stefanringel.de wrote:
 From: Stefan Ringel

 all drxk have dvb-t, but not dvb-c.

 Signed-off-by: Stefan Ringel
 ---
   drivers/media/dvb/frontends/drxk_hard.c |6 --
   1 files changed, 4 insertions(+), 2 deletions(-)

 diff --git a/drivers/media/dvb/frontends/drxk_hard.c 
 b/drivers/media/dvb/frontends/drxk_hard.c
 index 038e470..8a59801 100644
 --- a/drivers/media/dvb/frontends/drxk_hard.c
 +++ b/drivers/media/dvb/frontends/drxk_hard.c
 @@ -6460,9 +6460,11 @@ struct dvb_frontend *drxk_attach(const struct 
 drxk_config *config,
   init_state(state);
   if (init_drxk(state)<  0)
   goto error;
 -*fe_t =&state->t_frontend;
>>>  ^^^

 -return&state->c_frontend;
>>>  ^^
 +if (state->m_hasDVBC)
 +*fe_t =&state->c_frontend;
>>>  ^^^
 +
 +return&state->t_frontend;
>>> ^^^

   error:
   printk(KERN_ERR "drxk: not found\n");
>>> NAK, this changes the behaviour for existing drivers.
>>>
>>> What is the point to swap DVB-T and DVB-C frontends?
>>> If you really need this, please add an option to the config struct
>>> with default that does not change anything for existing drivers.
>> Correction:
>> Better do something like this (untested):
>>
>> if (state->m_hasDVBC) {
>> *fe_t =&state->t_frontend;
>> return state->c_frontend;
>> } else
>> return&state->t_frontend;
>>
>> CU
>> Oliver
>>
> What shall be that, explain? For me not practicable.

The right thing to do here is to create just one frontend per DRX-K.
This were already discussed in the past. Now that we have enough
dvb-core infrastructure to support it, I've made the patches for it:

http://news.gmane.org/gmane.linux.drivers.video-input-infrastructure

I took the m_hasDVBC and m_hasDVBT states into account, so DRX-K
drivers that implement just one of the types should now be properly
reported.

It also made the attachment logic simpler.

Regards,
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 4/9] [media] dvb_frontend: Don't use ops->info.type anymore

On 05-01-2012 14:19, e9hack wrote:
> Am 01.01.2012 21:11, schrieb Mauro Carvalho Chehab:
>> Get rid of using ops->info.type defined on DVB drivers,
>> as it doesn't apply anymore.
> 
>>
>> Signed-off-by: Mauro Carvalho Chehab 
>> ---
>>  drivers/media/dvb/dvb-core/dvb_frontend.c |  541 
>> ++---
>>  1 files changed, 266 insertions(+), 275 deletions(-)
> 
>> diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.c 
>> b/drivers/media/dvb/dvb-core/dvb_frontend.c
>> index eefcb7f..7f6ce06 100644
>> @@ -1902,6 +1850,37 @@ static int dvb_frontend_ioctl_legacy(struct file 
>> *file,
>>  memcpy(info, &fe->ops.info, sizeof(struct dvb_frontend_info));
>>  dvb_frontend_get_frequency_limits(fe, &info->frequency_min, 
>> &info->frequency_max);
>>  
>> +/*
>> + * Associate the 4 delivery systems supported by DVBv3
>> + * API with their DVBv5 counterpart. For the other standards,
>> + * use the closest type, assuming that it would hopefully
>> + * work with a DVBv3 application.
>> + * It should be noticed that, on multi-frontend devices with
>> + * different types (terrestrial and cable, for example),
>> + * a pure DVBv3 application won't be able to use all delivery
>> + * systems. Yet, changing the DVBv5 cache to the other delivery
>> + * system should be enough for making it work.
>> + */
>> +switch (dvbv3_type(c->delivery_system)) {
>> +case DVBV3_QPSK:
>> +fe->ops.info.type = FE_QPSK;
>> +break;
>> +case DVBV3_ATSC:
>> +fe->ops.info.type = FE_ATSC;
>> +break;
>> +case DVBV3_QAM:
>> +fe->ops.info.type = FE_QAM;
>> +break;
>> +case DVBV3_OFDM:
>> +fe->ops.info.type = FE_OFDM;
>> +break;
>> +default:
>> +printk(KERN_ERR
>> +   "%s: doesn't know how to handle a DVBv3 call to 
>> delivery system %i\n",
>> +   __func__, c->delivery_system);
>> +fe->ops.info.type = FE_OFDM;
>> +}
>> +
> 
> Hi,
> 
> I think this is partly wrong. The old delivery system values must be set in 
> the given data
> structure from caller:
> 
> fe->ops.info.type = FE_QAM;
> 
> must be replace by
> 
> info->type = FE_QAM;

Yeah, I noticed it today, when testing it with DRX-K. Patches fixing it
were sent to the ML earlier, but it ends that your solution is better
than mine ;) I've re-sent the patch to the ML, and added it upstream.

Thanks for noticing it!
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: Support for RC-6 in em28xx driver?

2012/1/5 Simon Søndergaard :
> Hi,
>
> I recently purchased a PCTV 290e USB Stick (em28174) it comes with a
> remote almost as small as the stick itself... I've been able to get
> both stick and remote to work. I also own an MCE media center remote
> from HP (this make
> http://www.ebay.com/itm/Original-Win7-PC-MCE-Media-Center-HP-Remote-Controller-/170594956920)
> that sends RC-6 codes. While it do have a windows logo I still think
> it is vastly superior to the one that shipped with the stick :-)
>
> If I understand it correctly em28174 is a derivative of em2874?
>
> In em28xx-input.c it is stated that: "em2874 supports more protocols.
> For now, let's just announce the two protocols that were already
> tested"
>
> I've been searching high and low for a datasheet for em28(1)74, but
> have been unable to find it online. Do anyone know if one of the
> protocols supported is RC-6? and if so how do I get a copy of the
> datasheet?

The 2874 supports NEC, RC-5, and RC-6/6A.  I did the original support
(based on the docs provided under NDA) but ironically enough I didn't
have an RC6 remote kicking around so I didn't do the support for it.

IR receivers for MCE devices are dirt cheap (< $20), and if you're
doing a media center then it's likely the PCTV 290e probably isn't in
line-of-site for a remote anyway.  That said, if you still really want
to see it supported I can probably find a couple of hours to do it (or
walk Mauro through the register differences if he cares to).

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.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

Support for RC-6 in em28xx driver?

Hi,

I recently purchased a PCTV 290e USB Stick (em28174) it comes with a
remote almost as small as the stick itself... I've been able to get
both stick and remote to work. I also own an MCE media center remote
from HP (this make
http://www.ebay.com/itm/Original-Win7-PC-MCE-Media-Center-HP-Remote-Controller-/170594956920)
that sends RC-6 codes. While it do have a windows logo I still think
it is vastly superior to the one that shipped with the stick :-)

If I understand it correctly em28174 is a derivative of em2874?

In em28xx-input.c it is stated that: "em2874 supports more protocols.
For now, let's just announce the two protocols that were already
tested"

I've been searching high and low for a datasheet for em28(1)74, but
have been unable to find it online. Do anyone know if one of the
protocols supported is RC-6? and if so how do I get a copy of the
datasheet?

Br,
/Simon
--
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 01/11] mm: page_alloc: set_migratetype_isolate: drain PCP prior to isolating

2012-01-05 Thread Marek Szyprowski

Hello,

On Thursday, January 05, 2012 4:40 PM Michał Nazarewicz wrote:

> On Thu, 29 Dec 2011 13:39:02 +0100, Marek Szyprowski 
>  wrote:
> > From: Michal Nazarewicz 
> >
> > When set_migratetype_isolate() sets pageblock's migrate type, it does
> > not change each page_private data.  This makes sense, as the function
> > has no way of knowing what kind of information page_private stores.
> >
> > Unfortunately, if a page is on PCP list, it's page_private indicates
> > its migrate type.  This means, that if a page on PCP list gets
> > isolated, a call to free_pcppages_bulk() will assume it has the old
> > migrate type rather than MIGRATE_ISOLATE.  This means, that a page
> > which should be isolated, will end up on a free list of it's old
> > migrate type.
> >
> > Coincidentally, at the very end, set_migratetype_isolate() calls
> > drain_all_pages() which leads to calling free_pcppages_bulk(), which
> > does the wrong thing.
> >
> > To avoid this situation, this commit moves the draining prior to
> > setting pageblock's migratetype and moving pages from old free list to
> > MIGRATETYPE_ISOLATE's free list.
> >
> > Because of spin locks this is a non-trivial change however as both
> > set_migratetype_isolate() and free_pcppages_bulk() grab zone->lock.
> > To solve this problem, this commit renames free_pcppages_bulk() to
> > __free_pcppages_bulk() and changes it so that it no longer grabs
> > zone->lock instead requiring caller to hold it.  This commit later
> > adds a __zone_drain_all_pages() function which works just like
> > drain_all_pages() expects that it drains only pages from a single zone
> > and assumes that caller holds zone->lock.
> 
> As it turns out, with some more testing on SMP systems, this whole patch
> turned out to be incorrect.
> 
> We have been thinking about other approach and, if we were to use something
> else then the first patch from CMAv17[1], the best thing we could came up
> with was to unconditionally call drain_all_pages() at the beginning of
> set_migratetype_isolate() before the call to spin_lock_irqsave().  It has
> a possible race condition but a nightly stress test did have not shown any
> problems.
> 
> Nonetheless, the cleanest, in my opinion, solution is to use the first patch
>  from CMAv17 which can be found at [1].
> 
> So, to sum up: if you intend to test CMAv18, instead of applying this first
> patch either use first patch from CMAv17[1] or put an unconditional call to
> drain_all_pages() at the beginning of set_migrate_isolate() function.
> 
> Sorry for the troubles.
> 
> [1] http://www.spinics.net/lists/arm-kernel/msg148494.html

I've updated our public git repository to include this workaround. You can
pull the patches from the following addresses:

git://git.infradead.org/users/kmpark/linux-samsung 3.2-rc7-cma-v18

http://git.infradead.org/users/kmpark/linux-samsung/shortlog/refs/heads/3.2-rc7-cma-v18

Best regards
-- 
Marek Szyprowski
Samsung Poland R&D Center


--
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: Broken ioctl error returns (was Re: [PATCH 2/3] block: fail SCSI passthrough ioctls on partition devices)

On 05-01-2012 15:47, Linus Torvalds wrote:
> On Thu, Jan 5, 2012 at 9:37 AM, Mauro Carvalho Chehab
>  wrote:
>>
>> For the media drivers, we've already fixed it, at the V4L side:
>> -EINVAL doesn't mean that an ioctl is not supported anymore.
>> I think that such fix went into Kernel 3.1.
> 
> Ok, I'm happy to hear that the thing should be fixed. My grepping
> still found a fair amount of EINVAL returns both in code and in the
> Documentation subdirectory for media ioctls, but it really was just
> grepping with a few lines of context, so I didn't look closer at the
> semantics. I was just looking for certain patterns (ie grepping for
> "EINVAL" near ioctl or ENOIOCTLCMD etc) that I thought might indicate
> problem spots, and the media subdirectory had a lot of them.

Yeah, there are lots of EINVAL there, as the API is fairly complex
(about 80 ioctl's for V4L, plus a similar set for DVB),  but there's
an ioctl dispatcher inside the V4L core that handles the ENOTTY case,
at drivers/media/video/v4l2-ioctl.c.

You'll see some -EINVAL things there, but they're due to errors
on parameters (the semantics there is somewhat complex, to avoid
returning -ENOTTY where a -EINVAL should be returned, instead).

In summary, the code there is:

static long __video_do_ioctl(struct file *file,
unsigned int cmd, void *arg)
{
...
long ret = -ENOTTY;
...
switch (cmd) {
/*
 * several ioctl callbacks here. if they're not
 * implemented, break (e. g. -ENOTTY will be returned).
 */
...
}
...
return ret;

The context there is too big for noticing it with a few lines of
context, and too complex as well, as some ioctl's may be implemented 
by more than one callback, depending on what's needed, and some 
others have a default implementation there. This is somewhat similar 
to file ops callbacks.

> Can you test the patch with some media capture apps (preferably with
> the obvious fix for the problem that Paulo already pointed out -
> although that won't actually matter until some block driver starts
> using ENOIOCTLCMD there, so even the unfixed patch should mostly work
> for testing)?

Sure. I'm currently traveling, so I have just my "first aids kit" of devices
but they should be enough for testing it. I'll return you as soon as I finish
compiling the kernel on this slow 4 years-old notebook and run some
tests with the usual applications.

Regards,
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 0/5] Fix dvb-core set_delivery_system and port drxk to one frontend

2012-01-05 Thread Lars Hanisch

Hi,

First: I'm no driver but an application developer.

Am 05.01.2012 17:40, schrieb Devin Heitmueller:

On Thu, Jan 5, 2012 at 10:37 AM, Mauro Carvalho Chehab
wrote:

With all these series applied, it is now possible to use frontend 0
for all delivery systems. As the current tools don't support changing
the delivery system, the dvb-fe-tool (on my experimental tree[1]) can now
be used to change between them:

Hi Mauro,

While from a functional standpoint I think this is a good change (and
we probably should have done it this way all along), is there not
concern that this could be interpreted by regular users as a
regression? Right now they get two frontends, and they can use all
their existing tools. We're moving to a model where if users upgraded
their kernel they would now require some new userland tool to do
something that the kernel was allowing them to do previously.

Sure, it's not "ABI breakage" in the classic sense but the net effect
is the same - stuff that used to work stops working and now they need
new tools or to recompile their existing tools to include new
functionality (which as you mentioned, none of those tools have
today).

Since now there isn't any consistent behaviour of hybrid multifrontend devices. Some create multiple frontends but
only one demux/dvr (like drx-k), others create all devices for every delivery system (HVR 4000). But they all could only
be opened mutually exclusive. In case of vdr (my favourite app) you have to trick with udev, symlinks, "remove unwanted
frontends" etc. to get the devices in a shape so the application can use it. I don't know how mythtv is handling such
devices, but I think there will be something like driver-dependend code in the one or other way.

The spec isn't really meaningful for hybrid devices. Maybe we should start there and claim something the driver
developer can follow.

Perhaps you would consider some sort of module option that would let
users fall back to the old behavior?

That would be fine but better would be a module option that will initialize frontend0 to the "connected" delivery
system. In case of DVB-C/-T you don't switch frequently from one to the other. You would need extra hardware like a
splitter which switches inputs if there are e.g. 5V for an active antenna (which means: switch to the dvb-t-input). Is
there any DVB-T card which can supply such voltage? And is it controllable via an ioctl (like LNB power supply in DVB-S)?

Anyway, I think, if there's finally a solution so all drivers behave the same, the tools and applications will handle
this new model in the near future.

Please do something... :-)

Regards,
Lars.

Devin

--
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: media_tree daily build: ERRORS

2012-01-05 Thread Hans Verkuil

This message is generated daily by a cron job that builds media_tree for
the kernels and architectures in the list below.

Results of the daily build of media_tree:

date:Thu Jan  5 19:00:25 CET 2012
git hash:534e04810304a9c6715220b392aa387197d5fa15
gcc version:  i686-linux-gcc (GCC) 4.6.1
host hardware:x86_64
host os:  3.1-2.slh.1-amd64

linux-git-arm-eabi-enoxys: ERRORS
linux-git-arm-eabi-omap: ERRORS
linux-git-armv5-ixp: WARNINGS
linux-git-i686: WARNINGS
linux-git-m32r: OK
linux-git-mips: WARNINGS
linux-git-powerpc64: OK
linux-git-x86_64: WARNINGS
linux-2.6.31.12-i686: ERRORS
linux-2.6.32.6-i686: WARNINGS
linux-2.6.33-i686: WARNINGS
linux-2.6.34-i686: WARNINGS
linux-2.6.35.3-i686: WARNINGS
linux-2.6.36-i686: WARNINGS
linux-2.6.37-i686: WARNINGS
linux-2.6.38.2-i686: WARNINGS
linux-2.6.39.1-i686: WARNINGS
linux-3.0-i686: WARNINGS
linux-3.1-i686: WARNINGS
linux-3.2-rc1-i686: WARNINGS
linux-2.6.31.12-x86_64: ERRORS
linux-2.6.32.6-x86_64: WARNINGS
linux-2.6.33-x86_64: WARNINGS
linux-2.6.34-x86_64: WARNINGS
linux-2.6.35.3-x86_64: WARNINGS
linux-2.6.36-x86_64: WARNINGS
linux-2.6.37-x86_64: WARNINGS
linux-2.6.38.2-x86_64: WARNINGS
linux-2.6.39.1-x86_64: WARNINGS
linux-3.0-x86_64: WARNINGS
linux-3.1-x86_64: WARNINGS
linux-3.2-rc1-x86_64: WARNINGS
spec-git: WARNINGS
sparse: ERRORS

Detailed results are available here:

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

Full logs are available here:

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

The V4L-DVB specification from this daily build is here:

http://www.xs4all.nl/~hverkuil/spec/media.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

[PATCH] [media] dvb_frontend: improve documentation on set_delivery_system()

While this patch change some things, the updated fields there are
used just on printk, so it shouldn't cause any functional changes.

Yet, this routine is a little complex, so explain a little more
how it works.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/dvb/dvb-core/dvb_frontend.c |   27 ++-
 1 files changed, 18 insertions(+), 9 deletions(-)

diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.c 
b/drivers/media/dvb/dvb-core/dvb_frontend.c
index 128f677..0e079a1 100644
--- a/drivers/media/dvb/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb/dvb-core/dvb_frontend.c
@@ -1440,9 +1440,13 @@ static int set_delivery_system(struct dvb_frontend *fe, 
u32 desired_system)
if (desired_system == SYS_UNDEFINED) {
/*
 * A DVBv3 call doesn't know what's the desired system.
-* So, don't change the current delivery system. Instead,
-* find the closest DVBv3 system that matches the delivery
-* system.
+* Also, DVBv3 applications don't know that ops.info->type
+* could be changed, and they simply dies when it doesn't
+* match.
+* So, don't change the current delivery system, as it
+* may be trying to do the wrong thing, like setting an
+* ISDB-T frontend as DVB-T. Instead, find the closest
+* DVBv3 system that matches the delivery system.
 */
if (is_dvbv3_delsys(c->delivery_system)) {
dprintk("%s() Using delivery system to %d\n",
@@ -1452,27 +1456,29 @@ static int set_delivery_system(struct dvb_frontend *fe, 
u32 desired_system)
type = dvbv3_type(c->delivery_system);
switch (type) {
case DVBV3_QPSK:
-   desired_system = FE_QPSK;
+   desired_system = SYS_DVBS;
break;
case DVBV3_QAM:
-   desired_system = FE_QAM;
+   desired_system = SYS_DVBC_ANNEX_A;
break;
case DVBV3_ATSC:
-   desired_system = FE_ATSC;
+   desired_system = SYS_ATSC;
break;
case DVBV3_OFDM:
-   desired_system = FE_OFDM;
+   desired_system = SYS_DVBT;
break;
default:
dprintk("%s(): This frontend doesn't support DVBv3 
calls\n",
__func__);
return -EINVAL;
}
-   delsys = c->delivery_system;
} else {
/*
-* Check if the desired delivery system is supported
+* This is a DVBv5 call. So, it likely knows the supported
+* delivery systems.
 */
+
+   /* Check if the desired delivery system is supported */
ncaps = 0;
while (fe->ops.delsys[ncaps] && ncaps < MAX_DELSYS) {
if (fe->ops.delsys[ncaps] == desired_system) {
@@ -1518,6 +1524,9 @@ static int set_delivery_system(struct dvb_frontend *fe, 
u32 desired_system)
}
 
/*
+* The DVBv3 or DVBv5 call is requesting a different system. So,
+* emulation is needed.
+*
 * Emulate newer delivery systems like ISDBT, DVBT and DMBTH
 * for older DVBv5 applications. The emulation will try to use
 * the auto mode for most things, and will assume that the desired
-- 
1.7.7.5

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

[PATCH v2] [media] dvb_frontend: Update the dynamic info->type

Instead of changing the ops.info.type struct, updates only
the data that will be returned to userspace.

Also add some debug messages to help tracking such issues.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/dvb/dvb-core/dvb_frontend.c |   13 +
 1 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.c 
b/drivers/media/dvb/dvb-core/dvb_frontend.c
index cd3c0f6..128f677 100644
--- a/drivers/media/dvb/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb/dvb-core/dvb_frontend.c
@@ -1551,6 +1551,8 @@ static int set_delivery_system(struct dvb_frontend *fe, 
u32 desired_system)
}
}
}
+   dprintk("change delivery system on cache to %d\n", c->delivery_system);
+
return 0;
 }
 
@@ -1965,6 +1967,7 @@ static int dvb_frontend_ioctl_legacy(struct file *file,
switch (cmd) {
case FE_GET_INFO: {
struct dvb_frontend_info* info = parg;
+
memcpy(info, &fe->ops.info, sizeof(struct dvb_frontend_info));
dvb_frontend_get_frequency_limits(fe, &info->frequency_min, 
&info->frequency_max);
 
@@ -1981,16 +1984,16 @@ static int dvb_frontend_ioctl_legacy(struct file *file,
 */
switch (dvbv3_type(c->delivery_system)) {
case DVBV3_QPSK:
-   fe->ops.info.type = FE_QPSK;
+   info->type = FE_QPSK;
break;
case DVBV3_ATSC:
-   fe->ops.info.type = FE_ATSC;
+   info->type = FE_ATSC;
break;
case DVBV3_QAM:
-   fe->ops.info.type = FE_QAM;
+   info->type = FE_QAM;
break;
case DVBV3_OFDM:
-   fe->ops.info.type = FE_OFDM;
+   info->type = FE_OFDM;
break;
default:
printk(KERN_ERR
@@ -1998,6 +2001,8 @@ static int dvb_frontend_ioctl_legacy(struct file *file,
   __func__, c->delivery_system);
fe->ops.info.type = FE_OFDM;
}
+   dprintk("current delivery system on cache: %d, V3 type: %d\n",
+   c->delivery_system, fe->ops.info.type);
 
/* Force the CAN_INVERSION_AUTO bit on. If the frontend doesn't
 * do it, it is done for it. */
-- 
1.7.7.5

--
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 0/5] Fix dvb-core set_delivery_system and port drxk to one frontend

On 05-01-2012 14:40, Devin Heitmueller wrote:
> On Thu, Jan 5, 2012 at 10:37 AM, Mauro Carvalho Chehab
>  wrote:
>> With all these series applied, it is now possible to use frontend 0
>> for all delivery systems. As the current tools don't support changing
>> the delivery system, the dvb-fe-tool (on my experimental tree[1]) can now
>> be used to change between them:
> 
> Hi Mauro,
> 
> While from a functional standpoint I think this is a good change (and
> we probably should have done it this way all along), is there not
> concern that this could be interpreted by regular users as a
> regression?  Right now they get two frontends, and they can use all
> their existing tools.  We're moving to a model where if users upgraded
> their kernel they would now require some new userland tool to do
> something that the kernel was allowing them to do previously.
> 
> Sure, it's not "ABI breakage" in the classic sense but the net effect
> is the same - stuff that used to work stops working and now they need
> new tools or to recompile their existing tools to include new
> functionality (which as you mentioned, none of those tools have
> today).
> 
> Perhaps you would consider some sort of module option that would let
> users fall back to the old behavior?

I see your point, but I can't see a simple way for fixing it. Thankfully,
there aren't many drivers yet that support multiple delivery systems
with different ops.info.type.

So, the better is to fix it earlier than later.

The issue with a fall-back option is that the end result will be the same:
it won't work as-is by default. The user will need to seek at the ML's
in order to discover about that. After discovering what is needed to fix
their environments, a simple tool that allows changing the delivery 
system at runtime  works better than a modprobe option to select it at
module load time, as it gives more flexibility to the user.

The real fix is to add support at the userspace applications for
using either the full DVBv5 API or, at least, to implement DTV_ENUM_DELSYS
and use a DVBv5 call to change the cache, on multi-frontend devices.

Btw, I just patched both my dvbv5-zap and dvbv5-scan applications to
work on that way.

Other GPL'd tools can just use my implementation as a reference if they
want, or write a simple code that will just add this on their code,
before checking if the delivery system matches their needs:

int set_delivery_system(uint32_t delivery_system)
{
struct dtv_properties props;
struct dtv_property dvb_prop[1];

dvb_prop[0].cmd = DTV_DELIVERY_SYSTEM;
dvb_prop[0].u.data = delivery_system;
props.num = 1;
props.props = dvb_prop;
if (ioctl(fd, FE_SET_PROPERTY, &props) >= 0
return 0;
return errno;
}

Regards,
Mauro

PS.: As a reference, the enclosed patch adds support for changing the
delivery system at the dvb-apps scan.c. Similar changes are needed at
the other dvb-apps tools.

--
scan: allow it to work with multiple delivery-systems frontends

Add support for changing the delivery system to the one specified
at the channels/transponders file.

Signed-off-by: Mauro Carvalho Chehab 

diff -r bec11f78be51 util/scan/scan.c
--- a/util/scan/scan.c  Wed Dec 07 15:26:50 2011 +0100
+++ b/util/scan/scan.c  Thu Jan 05 15:28:14 2012 -0500
@@ -1934,14 +1934,54 @@
return -1;
 }
 
+static set_delivery_system(int fd, unsigned type)
+{
+   struct dtv_properties props;
+   struct dtv_property dvb_prop[1];
+   unsigned delsys;
+
+   switch (type) {
+   case FE_QPSK:
+   delsys = SYS_DVBS;
+   break;
+   case FE_QAM:
+   delsys = SYS_DVBC_ANNEX_AC;
+   break;
+   case FE_OFDM:
+   delsys = SYS_DVBT;
+   break;
+   case FE_ATSC:
+   delsys = SYS_ATSC;
+   break;
+   default:
+   return -1;
+   }
+
+   dvb_prop[0].cmd = DTV_DELIVERY_SYSTEM;
+   dvb_prop[0].u.data = delsys;
+   props.num = 1;
+   props.props = dvb_prop;
+   if (ioctl(fd, FE_SET_PROPERTY, &props) >= 0)
+   return 0;
+   return errno;
+}
+
 static int tune_to_transponder (int frontend_fd, struct transponder *t)
 {
+   int rc;
+
/* move TP from "new" to "scanned" list */
list_del_init(&t->list);
list_add_tail(&t->list, &scanned_transponders);
t->scan_done = 1;
 
if (t->type != fe_info.type) {
+   rc = set_delivery_system(frontend_fd, t->type);
+   if (!rc)
+   fe_info.type = t->type;
+   }
+
+   if (t->type != fe_info.type) {
warning("frontend type (%s) is not compatible with requested 
tuning type (%s)\n",
fe_type2str(fe_info.type),fe_type2str(t->type));
/* ignore cab

Re: [patch -longterm v2] V4L/DVB: v4l2-ioctl: integer overflow in video_usercopy()

2012-01-05 Thread Dan Carpenter

On Thu, Jan 05, 2012 at 08:43:58AM -0800, Greg KH wrote:
> On Thu, Jan 05, 2012 at 09:28:22AM +0300, Dan Carpenter wrote:
> > If p->count is too high the multiplication could overflow and
> > array_size would be lower than expected.  Mauro and Hans Verkuil
> > suggested that we cap it at 1024.  That comes from the maximum
> > number of controls with lots of room for expantion.
> > 
> > $ grep V4L2_CID include/linux/videodev2.h | wc -l
> > 211
> > 
> > Signed-off-by: Dan Carpenter 
> 
> So this patch is only for 2.6.32?  But the original needs to get into
> Linus's tree first (which is what I'm guessing the other patch you sent
> is, right?)

Yep.

regards,
dan carpenter



signature.asc
Description: Digital signature

Re: Broken ioctl error returns (was Re: [PATCH 2/3] block: fail SCSI passthrough ioctls on partition devices)

On Thu, Jan 5, 2012 at 9:37 AM, Mauro Carvalho Chehab
 wrote:
>
> For the media drivers, we've already fixed it, at the V4L side:
> -EINVAL doesn't mean that an ioctl is not supported anymore.
> I think that such fix went into Kernel 3.1.

Ok, I'm happy to hear that the thing should be fixed. My grepping
still found a fair amount of EINVAL returns both in code and in the
Documentation subdirectory for media ioctls, but it really was just
grepping with a few lines of context, so I didn't look closer at the
semantics. I was just looking for certain patterns (ie grepping for
"EINVAL" near ioctl or ENOIOCTLCMD etc) that I thought might indicate
problem spots, and the media subdirectory had a lot of them.

Can you test the patch with some media capture apps (preferably with
the obvious fix for the problem that Paulo already pointed out -
although that won't actually matter until some block driver starts
using ENOIOCTLCMD there, so even the unfixed patch should mostly work
for testing)?

  Linus
--
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: Broken ioctl error returns (was Re: [PATCH 2/3] block: fail SCSI passthrough ioctls on partition devices)

On Thu, Jan 5, 2012 at 9:26 AM, Paolo Bonzini  wrote:
> On 01/05/2012 06:02 PM, Linus Torvalds wrote:
>>
>> +       return  ret == -EINVAL ||
>> +               ret == -ENOTTY ||
>> +               ret == ENOIOCTLCMD;
>
>
> Missing minus before ENOIOCTLCMD.

Oops, thanks, fixed.

Also, I do realize that the patch results in a warning about
"compat_ioctl_error()" no longer being used. I've removed it in my
tree, but I do wonder if we could perhaps have some kind of better
check, so maybe it is useful if somebody can come up with a saner way
to do it. Or at least a way that doesn't cause the kind of crazy code
that net/socket.c had.

And I notice that not only net/socket.c had workarounds for the bogus
warning, but fs/compat_ioctl.c itself does too: it's why we have those
IGNORE_IOCTL() entries.

So *maybe* we can reinstate that compat_ioctl_error() check, and just
remove the net/socket.c stuff, and make sure that all the ioctls that
net/socket.c had hacks for are mentioned as IGNORE_IOCTL's. Dunno.

Anybody have strong opinions either way? Has that printout helped
compat ioctl debugging a lot lately and we really want to maintain it?
Otherwise I'm inclined to remove it (we can always reinstate it later,
it's not like removal is necessarily final).

Linus
--
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: Broken ioctl error returns (was Re: [PATCH 2/3] block: fail SCSI passthrough ioctls on partition devices)

On 05-01-2012 15:02, Linus Torvalds wrote:
> On Thu, Jan 5, 2012 at 8:16 AM, Linus Torvalds
>  wrote:
>>
>> Just fix the *obvious* breakage in BLKROSET. It's clearly what the
>> code *intends* to do, it just didn't check for ENOIOCTLCMD.
> 
> So it seems from quick grepping that the block layer isn't actually
> all that confused apart from that one BLK[SG]ETRO issue, although I'm
> sure there are crazy drivers that think that EINVAL is the right error
> return.
> 
> The *really* confused layer seems to be the damn media drivers. The
> confusion there seems to go very deep indeed, where for some crazy
> reason the media people seem to have made it part of the semantics
> that "if a driver doesn't support a particular ioctl, it returns
> EINVAL".
> 
> Added, linux-media and Mauro to the Cc, because I'm about to commit
> something like the attached patch to see if anything breaks. We may
> have to revert it if things get too nasty, but we should have done
> this years and years ago, so let's hope not.

For the media drivers, we've already fixed it, at the V4L side:
-EINVAL doesn't mean that an ioctl is not supported anymore.
I think that such fix went into Kernel 3.1.

There are still two different behaviors there:
at the V4L API: the return code is -ENOTTY;
at the DVB API: the return code is currrently -EOPNOTSUPP.

Yeah, I know that DVB is returning the wrong code. Fixing it is on
my todo list, although with low priority, as the behavior inside the
DVB part is consistent.

On both DVB and V4L, -EINVAL now means only invalid parameters.

Regards,
Mauro

> Basic rules: ENOTTY means "I don't recognize this ioctl". Yes, the
> name is odd, and yes, it's for historical Unix reasons. ioctl's were
> originally a way to control mainly terminal settings - think termios -
> so when you did an ioctl on a file, you'd get "I'm not a tty, dummy".
> File flags were controlled with fcntl().
> 
> In contrast, EINVAL means "there is something wrong with the
> arguments", which very much implies "I do recognize the ioctl".
> 
> And finally, ENOIOCTLCMD is a way to say ENOTTY in a sane manner, and
> will now be turned into ENOTTY for the user space return (not EINVAL -
> I have no idea where that idiocy came from, but it's clearly confused,
> although it's also clearly very old).
> 
> This fixes the core files I noticed. It removes the *insane*
> complaints from the compat_ioctl() (which would complain if you
> returned ENOIOCTLCMD after an ioctl translation - the reason that is
> totally insane is that somebody might use an ioctl on the wrong kind
> of file descriptor, so even if it was translated perfectly fine,
> ENOIOCTLCMD is a perfectly fine error return and shouldn't cause
> warnings - and that allows us to remove stupid crap from the socket
> ioctl code).
> 
> Does this break things and need to be reverted? Maybe. There could be
> user code that tests *explicitly* for EINVAL and considers that the
> "wrong ioctl number", even though it's the wrong error return.
> 
> And we may have those kinds of mistakes inside the kernel too. We did
> in the block layer BLKSETRO code, for example, as pointed out by
> Paulo. That one is fixed here, but there may be others.
> 
> I didn't change any media layers, since there it's clearly an endemic
> problem, and there it seems to be used as a "we pass media ioctls down
> and drivers should by definition recognize them, so if they don't, we
> assume the driver is limited and doesn't support those particular
> settings and return EINVAL".
> 
> But in general, any code like this is WRONG:
> 
>switch (cmd) {
>case MYIOCTL:
>   .. do something ..
>default:
>   return -EINVAL;
>}
> 
> while something like this is CORRECT:
> 
>switch (cmd) {
>case MYIOCT:
>   if (arg)
>  return -EINVAL;
>   ...
> 
>case OTHERIOCT:
>   /* I recognize this one, but I don't support it */
>   return -EINVAL;
> 
>default:
>   return -ENOIOCTLCMD; // Or -ENOTTY - see below about the difference
>}
> 
> where right now we do have some magic differences between ENOIOCTLCMD
> and ENOTTY (the compat layer will try to do a translated ioctl *only*
> if it gets ENOIOCTLCMD, iirc, so ENOTTY basically means "this is my
> final answer").
> 
> I'll try it out on my own setup here to see what problems I can
> trigger, but I thought I'd send it out first just as (a) a heads-up
> and (b) to let others try it out and see.. See the block/ioctl.c code
> for an example of the kinds of things we may need even just inside the
> kernel (and the kinds of things that could cause problems for
> user-space that makes a difference between EINVAL and ENOTTY).
> 
>  Linus

--
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: Broken ioctl error returns (was Re: [PATCH 2/3] block: fail SCSI passthrough ioctls on partition devices)

On Thu, Jan 5, 2012 at 9:02 AM, Linus Torvalds
 wrote:
>
> Added, linux-media and Mauro to the Cc, because I'm about to commit
> something like the attached patch to see if anything breaks. We may
> have to revert it if things get too nasty, but we should have done
> this years and years ago, so let's hope not.

Ok, so "It works for me". I'll delay committing it in case somebody
has some quick obvious fixes or comments (like noticing other cases
like the blk_ioctl.c one), but on the whole I think I'll commit it
later today, just so that it will be as early as possible in the merge
window in case there is ENOTTY/EINVAL confusion.

The good news is that no user space can *ever* care about
ENOTTY/EINVAL in the "generic case", since different drivers have
returned different error returns for years. So user space that doesn't
know exactly what it is dealing with will pretty much by definition
not be affected. Except perhaps in a good way - if it uses "perror()"
or "strerror()" or similar, it will now give a much better error
string of "Inappropriate ioctl for device".

However, some applications don't work with "generic devices", but
instead work with a very specific device or perhaps a very specific
subset.

So the exception would be user space apps that know exactly which
driver they are talking about, and that particular driver used to
always return EINVAL before, and now the ENOIOCTLCMD -> ENOTTY fix
means that it returns the proper ENOTTY - and the application has
never seen it, and never tested against it, and breaks.

I don't *think* this happens outside of the media drivers, but we'll
see. It may be that we will have to make certain drivers return EINVAL
explicitly rather than ENOIOCTLCMD and add a comment about why. Sad,
if so, so we'll have little choice. Let's see what the breakage (if
any - cross your fingers) looks like.

   Linus
--
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: Broken ioctl error returns (was Re: [PATCH 2/3] block: fail SCSI passthrough ioctls on partition devices)

2012-01-05 Thread Paolo Bonzini


On 01/05/2012 06:02 PM, Linus Torvalds wrote:

+   return  ret == -EINVAL ||
+   ret == -ENOTTY ||
+   ret == ENOIOCTLCMD;


Missing minus before ENOIOCTLCMD.

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

Broken ioctl error returns (was Re: [PATCH 2/3] block: fail SCSI passthrough ioctls on partition devices)

On Thu, Jan 5, 2012 at 8:16 AM, Linus Torvalds
 wrote:
>
> Just fix the *obvious* breakage in BLKROSET. It's clearly what the
> code *intends* to do, it just didn't check for ENOIOCTLCMD.

So it seems from quick grepping that the block layer isn't actually
all that confused apart from that one BLK[SG]ETRO issue, although I'm
sure there are crazy drivers that think that EINVAL is the right error
return.

The *really* confused layer seems to be the damn media drivers. The
confusion there seems to go very deep indeed, where for some crazy
reason the media people seem to have made it part of the semantics
that "if a driver doesn't support a particular ioctl, it returns
EINVAL".

Added, linux-media and Mauro to the Cc, because I'm about to commit
something like the attached patch to see if anything breaks. We may
have to revert it if things get too nasty, but we should have done
this years and years ago, so let's hope not.

Basic rules: ENOTTY means "I don't recognize this ioctl". Yes, the
name is odd, and yes, it's for historical Unix reasons. ioctl's were
originally a way to control mainly terminal settings - think termios -
so when you did an ioctl on a file, you'd get "I'm not a tty, dummy".
File flags were controlled with fcntl().

In contrast, EINVAL means "there is something wrong with the
arguments", which very much implies "I do recognize the ioctl".

And finally, ENOIOCTLCMD is a way to say ENOTTY in a sane manner, and
will now be turned into ENOTTY for the user space return (not EINVAL -
I have no idea where that idiocy came from, but it's clearly confused,
although it's also clearly very old).

This fixes the core files I noticed. It removes the *insane*
complaints from the compat_ioctl() (which would complain if you
returned ENOIOCTLCMD after an ioctl translation - the reason that is
totally insane is that somebody might use an ioctl on the wrong kind
of file descriptor, so even if it was translated perfectly fine,
ENOIOCTLCMD is a perfectly fine error return and shouldn't cause
warnings - and that allows us to remove stupid crap from the socket
ioctl code).

Does this break things and need to be reverted? Maybe. There could be
user code that tests *explicitly* for EINVAL and considers that the
"wrong ioctl number", even though it's the wrong error return.

And we may have those kinds of mistakes inside the kernel too. We did
in the block layer BLKSETRO code, for example, as pointed out by
Paulo. That one is fixed here, but there may be others.

I didn't change any media layers, since there it's clearly an endemic
problem, and there it seems to be used as a "we pass media ioctls down
and drivers should by definition recognize them, so if they don't, we
assume the driver is limited and doesn't support those particular
settings and return EINVAL".

But in general, any code like this is WRONG:

   switch (cmd) {
   case MYIOCTL:
  .. do something ..
   default:
  return -EINVAL;
   }

while something like this is CORRECT:

   switch (cmd) {
   case MYIOCT:
  if (arg)
 return -EINVAL;
  ...

   case OTHERIOCT:
  /* I recognize this one, but I don't support it */
  return -EINVAL;

   default:
  return -ENOIOCTLCMD; // Or -ENOTTY - see below about the difference
   }

where right now we do have some magic differences between ENOIOCTLCMD
and ENOTTY (the compat layer will try to do a translated ioctl *only*
if it gets ENOIOCTLCMD, iirc, so ENOTTY basically means "this is my
final answer").

I'll try it out on my own setup here to see what problems I can
trigger, but I thought I'd send it out first just as (a) a heads-up
and (b) to let others try it out and see.. See the block/ioctl.c code
for an example of the kinds of things we may need even just inside the
kernel (and the kinds of things that could cause problems for
user-space that makes a difference between EINVAL and ENOTTY).

 Linus
 block/ioctl.c |   26 ++
 fs/compat_ioctl.c |9 ++---
 fs/ioctl.c|2 +-
 net/socket.c  |   16 +---
 4 files changed, 26 insertions(+), 27 deletions(-)

diff --git a/block/ioctl.c b/block/ioctl.c
index ca939fc1030f..af8363e775a8 100644
--- a/block/ioctl.c
+++ b/block/ioctl.c
@@ -180,6 +180,26 @@ int __blkdev_driver_ioctl(struct block_device *bdev, fmode_t mode,
 EXPORT_SYMBOL_GPL(__blkdev_driver_ioctl);

 /*
+ * Is it an unrecognized ioctl? The correct returns are either
+ * ENOTTY (final) or ENOIOCTLCMD ("I don't know this one, try a
+ * fallback"). ENOIOCTLCMD gets turned into ENOTTY by the ioctl
+ * code before returning.
+ *
+ * Confused drivers sometimes return EINVAL, which is wrong. It
+ * means "I understood the ioctl command, but the parameters to
+ * it were wrong".
+ *
+ * We should aim to just fix the broken drivers, the EINVAL case
+ * should go away.
+ */
+static inline int is_unrecognized_ioctl(int ret)
+{
+	return	ret == -EINVAL ||
+		ret == -ENOTTY ||
+		ret == ENOIOCTLCMD;
+}
+
+

Re: [patch -longterm v2] V4L/DVB: v4l2-ioctl: integer overflow in video_usercopy()

2012-01-05 Thread Greg KH

On Thu, Jan 05, 2012 at 09:28:22AM +0300, Dan Carpenter wrote:
> If p->count is too high the multiplication could overflow and
> array_size would be lower than expected.  Mauro and Hans Verkuil
> suggested that we cap it at 1024.  That comes from the maximum
> number of controls with lots of room for expantion.
> 
> $ grep V4L2_CID include/linux/videodev2.h | wc -l
> 211
> 
> Signed-off-by: Dan Carpenter 

So this patch is only for 2.6.32?  But the original needs to get into
Linus's tree first (which is what I'm guessing the other patch you sent
is, right?)

thanks,

greg k-h
--
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 0/5] Fix dvb-core set_delivery_system and port drxk to one frontend

On Thu, Jan 5, 2012 at 10:37 AM, Mauro Carvalho Chehab
 wrote:
> With all these series applied, it is now possible to use frontend 0
> for all delivery systems. As the current tools don't support changing
> the delivery system, the dvb-fe-tool (on my experimental tree[1]) can now
> be used to change between them:

Hi Mauro,

While from a functional standpoint I think this is a good change (and
we probably should have done it this way all along), is there not
concern that this could be interpreted by regular users as a
regression?  Right now they get two frontends, and they can use all
their existing tools.  We're moving to a model where if users upgraded
their kernel they would now require some new userland tool to do
something that the kernel was allowing them to do previously.

Sure, it's not "ABI breakage" in the classic sense but the net effect
is the same - stuff that used to work stops working and now they need
new tools or to recompile their existing tools to include new
functionality (which as you mentioned, none of those tools have
today).

Perhaps you would consider some sort of module option that would let
users fall back to the old behavior?

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.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

DVB: Question on TS_DECODER

2012-01-05 Thread Hamad Kadmany

Hi,

dvb_dmxdev_start_feed sets TS_DECODER to ts_type regardless of whether
pes-output was set to DMX_OUT_DECODER or not, but depending on the pes-type
only. 

This might cause confusion, there's a hidden assumption that if user is not
interested to send data to decoder, the pes type must always be
DMX_PES_OTHER, which makes the API a bit un-clear to user-space.

If user-space is only interested in recording video packets for example, and
by mistake sets DMX_PES_VIDEO (because it just says the pes type which is
independent from the pes output type) then packets will make their way to
the decoder eventhough this was not the intention.

Is there any special reason to have this? 

Thanks,
Hamad

--
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 08/17] v4l: Image source control class

Hi Sakari,

Thanks for the patch.

On Tuesday 20 December 2011 21:28:00 Sakari Ailus wrote:
> From: Sakari Ailus 
> 
> Add image source control class. This control class is intended to contain
> low level controls which deal with control of the image capture process ---
> the A/D converter in image sensors, for example.
> 
> Signed-off-by: Sakari Ailus 
> ---
>  Documentation/DocBook/media/v4l/controls.xml   |  101 +
>  .../DocBook/media/v4l/vidioc-g-ext-ctrls.xml   |6 +
>  drivers/media/video/v4l2-ctrls.c   |   10 ++
>  include/linux/videodev2.h  |   10 ++
>  4 files changed, 127 insertions(+), 0 deletions(-)
> 
> diff --git a/Documentation/DocBook/media/v4l/controls.xml
> b/Documentation/DocBook/media/v4l/controls.xml index 3bc5ee8..69ede83
> 100644
> --- a/Documentation/DocBook/media/v4l/controls.xml
> +++ b/Documentation/DocBook/media/v4l/controls.xml
> @@ -3356,6 +3356,107 @@ interface and may change in the future.
>
> 
>  
> +
> +
> +  Image Source Control Reference
> +
> +  
> + Experimental
> +
> + This is an  + linkend="experimental">experimental interface and may
> + change in the future.
> +  
> +
> +  
> + The Image Source control class is intended for low-level
> + control of image source devices such as image sensors. The
> + devices feature an analogue to digital converter and a bus

Is the V4L2 documentation written in US or UK English ? US uses analog, UK 
uses analogue. Analog would be shorter in control names.

> + transmitter to transmit the image data out of the device.
> +  
> +
> +  
> +  Image Source Control IDs
> +
> +  
> + 
> + 
> + 
> + 
> + 
> + 
> + 
> +   
> + ID
> + Type
> +align="left">Description +  
> + 
> + 
> +   
> +   
> +  spanname="id">V4L2_CID_IMAGE_SOURCE_CLASS +  
>  
>   class
> +   
> +   
> + The IMAGE_SOURCE class descriptor.
> +   
> +   
> +  spanname="id">V4L2_CID_IMAGE_SOURCE_VBLANK + 
>integer
> +   
> +   
> + Vertical blanking. The idle
> + preriod after every frame during which no image data is

s/preriod/period/

> + produced. The unit of vertical blanking is a line. Every
> + line has length of the image width plus horizontal
> + blanking at the pixel clock specified by struct
> + v4l2_mbus_framefmt  + />.
> +   
> +   
> +  spanname="id">V4L2_CID_IMAGE_SOURCE_HBLANK + 
>integer
> +   
> +   
> + Horizontal blanking. The idle
> + preriod after every line of image data during which no

s/preriod/period/

> + image data is produced. The unit of horizontal blanking is
> + pixels.
> +   
> +   
> +  spanname="id">V4L2_CID_IMAGE_SOURCE_LINK_FREQ
> + integer menu
> +   
> +   
> + Image source's data bus frequency.

What's the frequency unit ? Sample/second ?

> + Together with the media bus pixel code, bus type (clock
> + cycles per sample), the data bus frequency defines the
> + pixel clock.  The
> + frame rate can be calculated from the pixel clock, image
> + width and height and horizontal and vertical blanking. The
> + frame rate control is performed by selecting the desired
> + horizontal and vertical blanking.
> + 
> +   
> +   
> +  spanname="id">V4L2_CID_IMAGE_SOURCE_ANALOGUE_GAIN try> +integer
> +   
> +   
> + Analogue gain is gain affecting
> + all colour components in the pixel matrix. The gain
> + operation is performed in the analogue domain before A/D
> + conversion.

Should we define one gain per color component ?

> + 
> +   
> +   
> + 
> +  
> +  
> +
> +
> +
>  
> 
>

Re: [PATCH 4/9] [media] dvb_frontend: Don't use ops->info.type anymore

2012-01-05 Thread e9hack

Am 01.01.2012 21:11, schrieb Mauro Carvalho Chehab:
> Get rid of using ops->info.type defined on DVB drivers,
> as it doesn't apply anymore.

> 
> Signed-off-by: Mauro Carvalho Chehab 
> ---
>  drivers/media/dvb/dvb-core/dvb_frontend.c |  541 
> ++---
>  1 files changed, 266 insertions(+), 275 deletions(-)

> diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.c 
> b/drivers/media/dvb/dvb-core/dvb_frontend.c
> index eefcb7f..7f6ce06 100644
> @@ -1902,6 +1850,37 @@ static int dvb_frontend_ioctl_legacy(struct file *file,
>   memcpy(info, &fe->ops.info, sizeof(struct dvb_frontend_info));
>   dvb_frontend_get_frequency_limits(fe, &info->frequency_min, 
> &info->frequency_max);
>  
> + /*
> +  * Associate the 4 delivery systems supported by DVBv3
> +  * API with their DVBv5 counterpart. For the other standards,
> +  * use the closest type, assuming that it would hopefully
> +  * work with a DVBv3 application.
> +  * It should be noticed that, on multi-frontend devices with
> +  * different types (terrestrial and cable, for example),
> +  * a pure DVBv3 application won't be able to use all delivery
> +  * systems. Yet, changing the DVBv5 cache to the other delivery
> +  * system should be enough for making it work.
> +  */
> + switch (dvbv3_type(c->delivery_system)) {
> + case DVBV3_QPSK:
> + fe->ops.info.type = FE_QPSK;
> + break;
> + case DVBV3_ATSC:
> + fe->ops.info.type = FE_ATSC;
> + break;
> + case DVBV3_QAM:
> + fe->ops.info.type = FE_QAM;
> + break;
> + case DVBV3_OFDM:
> + fe->ops.info.type = FE_OFDM;
> + break;
> + default:
> + printk(KERN_ERR
> +"%s: doesn't know how to handle a DVBv3 call to 
> delivery system %i\n",
> +__func__, c->delivery_system);
> + fe->ops.info.type = FE_OFDM;
> + }
> +

Hi,

I think this is partly wrong. The old delivery system values must be set in the 
given data
structure from caller:

fe->ops.info.type = FE_QAM;

must be replace by

info->type = FE_QAM;

Regards,
Hartmut
--
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 05/17] v4l: Support s_crop and g_crop through s/g_selection

Hi Sakari,

Thanks for the patch.

On Tuesday 20 December 2011 21:27:57 Sakari Ailus wrote:
> From: Sakari Ailus 
> 
> Revert to s_selection if s_crop isn't implemented by a driver. Same for
> g_selection / g_crop.

Shouldn't this say "Fall back" instead of "Revert" ?

> Signed-off-by: Sakari Ailus 
> ---
>  drivers/media/video/v4l2-subdev.c |   37
> +++-- 1 files changed, 35 insertions(+), 2
> deletions(-)
> 
> diff --git a/drivers/media/video/v4l2-subdev.c
> b/drivers/media/video/v4l2-subdev.c index e8ae098..f8de551 100644
> --- a/drivers/media/video/v4l2-subdev.c
> +++ b/drivers/media/video/v4l2-subdev.c
> @@ -226,6 +226,8 @@ static long subdev_do_ioctl(struct file *file, unsigned
> int cmd, void *arg)
> 
>   case VIDIOC_SUBDEV_G_CROP: {
>   struct v4l2_subdev_crop *crop = arg;
> + struct v4l2_subdev_selection sel;
> + int rval;
> 
>   if (crop->which != V4L2_SUBDEV_FORMAT_TRY &&
>   crop->which != V4L2_SUBDEV_FORMAT_ACTIVE)
> @@ -234,11 +236,27 @@ static long subdev_do_ioctl(struct file *file,
> unsigned int cmd, void *arg) if (crop->pad >= sd->entity.num_pads)
>   return -EINVAL;
> 
> - return v4l2_subdev_call(sd, pad, get_crop, subdev_fh, crop);
> + rval = v4l2_subdev_call(sd, pad, get_crop, subdev_fh, crop);
> + if (rval != -ENOIOCTLCMD)
> + return rval;
> +
> + memset(&sel, 0, sizeof(sel));
> + sel.which = V4L2_SUBDEV_FORMAT_ACTIVE;

Shouldn't sel.which be set to crop->which ?

> + sel.pad = crop->pad;
> + sel.target = V4L2_SUBDEV_SEL_TGT_CROP_ACTIVE;
> +
> + rval = v4l2_subdev_call(
> + sd, pad, get_selection, subdev_fh, &sel);
> +
> + crop->rect = sel.r;
> +
> + return rval;
>   }
> 
>   case VIDIOC_SUBDEV_S_CROP: {
>   struct v4l2_subdev_crop *crop = arg;
> + struct v4l2_subdev_selection sel;
> + int rval;
> 
>   if (crop->which != V4L2_SUBDEV_FORMAT_TRY &&
>   crop->which != V4L2_SUBDEV_FORMAT_ACTIVE)
> @@ -247,7 +265,22 @@ static long subdev_do_ioctl(struct file *file,
> unsigned int cmd, void *arg) if (crop->pad >= sd->entity.num_pads)
>   return -EINVAL;
> 
> - return v4l2_subdev_call(sd, pad, set_crop, subdev_fh, crop);
> + rval = v4l2_subdev_call(sd, pad, set_crop, subdev_fh, crop);
> + if (rval != -ENOIOCTLCMD)
> + return rval;
> +
> + memset(&sel, 0, sizeof(sel));
> + sel.which = V4L2_SUBDEV_FORMAT_ACTIVE;

Same here.

> + sel.pad = crop->pad;
> + sel.target = V4L2_SUBDEV_SEL_TGT_CROP_ACTIVE;
> + sel.r = crop->rect;
> +
> + rval = v4l2_subdev_call(
> + sd, pad, set_selection, subdev_fh, &sel);
> +
> + crop->rect = sel.r;
> +
> + return rval;
>   }
> 
>   case VIDIOC_SUBDEV_ENUM_MBUS_CODE: {

-- 
Regards,

Laurent Pinchart
--
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 04/17] v4l: VIDIOC_SUBDEV_S_SELECTION and VIDIOC_SUBDEV_G_SELECTION IOCTLs

Hi Sakari,

Thanks for the patch.

On Tuesday 20 December 2011 21:27:56 Sakari Ailus wrote:
> From: Sakari Ailus 
> 
> Add support for VIDIOC_SUBDEV_S_SELECTION and VIDIOC_SUBDEV_G_SELECTION
> IOCTLs. They replace functionality provided by VIDIOC_SUBDEV_S_CROP and
> VIDIOC_SUBDEV_G_CROP IOCTLs and also add new functionality (composing).
> 
> VIDIOC_SUBDEV_G_CROP and VIDIOC_SUBDEV_S_CROP continue to be supported.

As those ioctls are experimental, should we deprecate them ?

> Signed-off-by: Sakari Ailus 
> ---
>  drivers/media/video/v4l2-subdev.c |   26 -
>  include/linux/v4l2-subdev.h   |   45 ++
>  include/media/v4l2-subdev.h   |5 
>  3 files changed, 75 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/media/video/v4l2-subdev.c
> b/drivers/media/video/v4l2-subdev.c index 65ade5f..e8ae098 100644
> --- a/drivers/media/video/v4l2-subdev.c
> +++ b/drivers/media/video/v4l2-subdev.c
> @@ -36,13 +36,17 @@ static int subdev_fh_init(struct v4l2_subdev_fh *fh,
> struct v4l2_subdev *sd) {
>  #if defined(CONFIG_VIDEO_V4L2_SUBDEV_API)
>   /* Allocate try format and crop in the same memory block */
> - fh->try_fmt = kzalloc((sizeof(*fh->try_fmt) + sizeof(*fh->try_crop))
> + fh->try_fmt = kzalloc((sizeof(*fh->try_fmt) + sizeof(*fh->try_crop)
> ++ sizeof(*fh->try_compose))
> * sd->entity.num_pads, GFP_KERNEL);

Could you check how the 3 structures are aligned on 64-bit platforms ? I'm a 
bit worried about the compiler expecting a 64-bit alignment for one of them, 
and getting only a 32-bit alignment in the end.

What about using kcalloc ?

>   if (fh->try_fmt == NULL)
>   return -ENOMEM;
> 
>   fh->try_crop = (struct v4l2_rect *)
>   (fh->try_fmt + sd->entity.num_pads);
> +
> + fh->try_compose = (struct v4l2_rect *)
> + (fh->try_crop + sd->entity.num_pads);
>  #endif
>   return 0;
>  }
> @@ -281,6 +285,26 @@ static long subdev_do_ioctl(struct file *file,
> unsigned int cmd, void *arg) return v4l2_subdev_call(sd, pad,
> enum_frame_interval, subdev_fh, fie);
>   }
> +
> + case VIDIOC_SUBDEV_G_SELECTION: {
> + struct v4l2_subdev_selection *sel = arg;

Shouldn't you check sel->which ?

> + if (sel->pad >= sd->entity.num_pads)
> + return -EINVAL;
> +
> + return v4l2_subdev_call(
> + sd, pad, get_selection, subdev_fh, sel);
> + }
> +
> + case VIDIOC_SUBDEV_S_SELECTION: {
> + struct v4l2_subdev_selection *sel = arg;

And here too ?

> + if (sel->pad >= sd->entity.num_pads)
> + return -EINVAL;
> +
> + return v4l2_subdev_call(
> + sd, pad, set_selection, subdev_fh, sel);
> + }
>  #endif
>   default:
>   return v4l2_subdev_call(sd, core, ioctl, cmd, arg);
> diff --git a/include/linux/v4l2-subdev.h b/include/linux/v4l2-subdev.h
> index ed29cbb..d53d775 100644
> --- a/include/linux/v4l2-subdev.h
> +++ b/include/linux/v4l2-subdev.h
> @@ -123,6 +123,47 @@ struct v4l2_subdev_frame_interval_enum {
>   __u32 reserved[9];
>  };
> 
> +#define V4L2_SUBDEV_SEL_FLAG_SIZE_GE (1 << 0)
> +#define V4L2_SUBDEV_SEL_FLAG_SIZE_LE (1 << 1)
> +#define V4L2_SUBDEV_SEL_FLAG_KEEP_CONFIG (1 << 2)
> +
> +/* active cropping area */
> +#define V4L2_SUBDEV_SEL_TGT_CROP_ACTIVE  0
> +/* default cropping area */
> +#define V4L2_SUBDEV_SEL_TGT_CROP_DEFAULT 1
> +/* cropping bounds */
> +#define V4L2_SUBDEV_SEL_TGT_CROP_BOUNDS  2
> +/* current composing area */
> +#define V4L2_SUBDEV_SEL_TGT_COMPOSE_ACTIVE   256
> +/* default composing area */
> +#define V4L2_SUBDEV_SEL_TGT_COMPOSE_DEFAULT  257
> +/* composing bounds */
> +#define V4L2_SUBDEV_SEL_TGT_COMPOSE_BOUNDS   258
> +
> +
> +/**
> + * struct v4l2_subdev_selection - selection info
> + *
> + * @which: either V4L2_SUBDEV_FORMAT_ACTIVE or V4L2_SUBDEV_FORMAT_TRY
> + * @pad: pad number, as reported by the media API
> + * @target: selection target, used to choose one of possible rectangles
> + * @flags: constraints flags
> + * @r: coordinates of selection window
> + * @reserved: for future use, rounds structure size to 64 bytes, set to
> zero + *
> + * Hardware may use multiple helper window to process a video stream.
> + * The structure is used to exchange this selection areas between
> + * an application and a driver.
> + */
> +struct v4l2_subdev_selection {
> + __u32 which;
> + __u32 pad;
> + __u32 target;
> + __u32 flags;
> + struct v4l2_rect r;
> + __u32 reserved[8];
> +};
> +
>  #define VIDIOC_SUBDEV_G_FMT  _IOWR('V',  4, struct v4l2_subdev_format)
>  #define VIDIOC_SUBDEV_S_FMT  _IOWR('V',  5, struct v4l2_subdev_format)
>  #define VIDIOC_SUBDEV_G_FRAME_INTERVAL \
> @@ -137,5 +178,9 @@ st

Re: [yavta PATCH 1/1] Support integer menus.

Hi Sakari,

Thanks for the patch.

On Wednesday 28 December 2011 10:47:01 Sakari Ailus wrote:
> Signed-off-by: Sakari Ailus 
> ---
>  yavta.c |   12 +---
>  1 files changed, 9 insertions(+), 3 deletions(-)
> 
> diff --git a/yavta.c b/yavta.c
> index c0e9acb..9b8a80e 100644
> --- a/yavta.c
> +++ b/yavta.c
> @@ -551,6 +551,7 @@ static int video_enable(struct device *dev, int enable)
>  }
> 
>  static void video_query_menu(struct device *dev, unsigned int id,
> +  unsigned int type,
>unsigned int min, unsigned int max)
>  {
>   struct v4l2_querymenu menu;
> @@ -562,7 +563,10 @@ static void video_query_menu(struct device *dev,
> unsigned int id, if (ret < 0)
>   continue;
> 
> - printf("  %u: %.32s\n", menu.index, menu.name);
> + if (type == V4L2_CTRL_TYPE_MENU)
> + printf("  %u: %.32s\n", menu.index, menu.name);
> + else
> + printf("  %u: %lld\n", menu.index, menu.value);
>   };
>  }
> 
> @@ -607,8 +611,10 @@ static void video_list_controls(struct device *dev)
>   query.id, query.name, query.minimum, query.maximum,
>   query.step, query.default_value, value);
> 
> - if (query.type == V4L2_CTRL_TYPE_MENU)
> - video_query_menu(dev, query.id, query.minimum, 
> query.maximum);
> + if (query.type == V4L2_CTRL_TYPE_MENU ||
> + query.type == V4L2_CTRL_TYPE_INTEGER_MENU)
> + video_query_menu(dev, query.id, query.type,
> +  query.minimum, query.maximum);

What about passing &query to the function instead ?

> 
>   nctrls++;
>   }

-- 
Regards,

Laurent Pinchart
--
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 03/17] vivi: Add an integer menu test control

Hi Sakari,

Thanks for the patch.

On Tuesday 20 December 2011 21:27:55 Sakari Ailus wrote:
> From: Sakari Ailus 
> 
> Add an integer menu test control for the vivi driver.
> 
> Signed-off-by: Sakari Ailus 
> ---
>  drivers/media/video/vivi.c |   21 +
>  1 files changed, 21 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/media/video/vivi.c b/drivers/media/video/vivi.c
> index 7d754fb..763ec23 100644
> --- a/drivers/media/video/vivi.c
> +++ b/drivers/media/video/vivi.c
> @@ -177,6 +177,7 @@ struct vivi_dev {
>   struct v4l2_ctrl   *menu;
>   struct v4l2_ctrl   *string;
>   struct v4l2_ctrl   *bitmask;
> + struct v4l2_ctrl   *int_menu;
> 
>   spinlock_t slock;
>   struct mutex   mutex;
> @@ -503,6 +504,10 @@ static void vivi_fillbuff(struct vivi_dev *dev, struct
> vivi_buffer *buf) dev->boolean->cur.val,
>   dev->menu->qmenu[dev->menu->cur.val],
>   dev->string->cur.string);
> + snprintf(str, sizeof(str), " integer_menu %s, value %lld ",
> + dev->int_menu->qmenu[dev->int_menu->cur.val],

Shouldn't you print the content of qmenu_int as a 64-bit integer instead ?

> + dev->int64->cur.val64);

Shouldn't this be dev->int_menu->cur.val ?

> + gen_text(dev, vbuf, line++ * 16, 16, str);
>   mutex_unlock(&dev->ctrl_handler.lock);
>   gen_text(dev, vbuf, line++ * 16, 16, str);
>   if (dev->button_pressed) {
> @@ -1183,6 +1188,22 @@ static const struct v4l2_ctrl_config
> vivi_ctrl_bitmask = { .step = 0,
>  };
> 
> +static const s64 * const vivi_ctrl_int_menu_values[] = {
> + 1, 1, 2, 3, 5, 8, 13, 21, 42,
> +};
> +
> +static const struct v4l2_ctrl_config vivi_ctrl_string = {
> + .ops = &vivi_ctrl_ops,
> + .id = VIDI_CID_CUSTOM_BASE + 7
> + .name = "Integer menu",
> + .type = V4L2_CTRL_TYPE_INTEGER_MENU,
> + .min = 1,
> + .max = 8,

There are 9 values in your vivi_ctrl_int_menu_values array. Is 8 on purpose 
here ?

> + .def = 4,
> + .menu_skip_mask = 0x02,
> + .qmenu_int = &vivi_ctrl_int_menu_values,
> +};
> +
>  static const struct v4l2_file_operations vivi_fops = {
>   .owner  = THIS_MODULE,
>   .open   = v4l2_fh_open,

-- 
Regards,

Laurent Pinchart
--
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 02/17] v4l: Document integer menu controls

Hi Sakari,

Thanks for the patch.

On Tuesday 20 December 2011 21:27:54 Sakari Ailus wrote:
> From: Sakari Ailus 
> 
> Signed-off-by: Sakari Ailus 
> ---
>  Documentation/DocBook/media/v4l/compat.xml |   10 +
>  Documentation/DocBook/media/v4l/v4l2.xml   |7 
>  .../DocBook/media/v4l/vidioc-queryctrl.xml |   39
> +++- 3 files changed, 54 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/DocBook/media/v4l/compat.xml
> b/Documentation/DocBook/media/v4l/compat.xml index b68698f..569efd1 100644
> --- a/Documentation/DocBook/media/v4l/compat.xml
> +++ b/Documentation/DocBook/media/v4l/compat.xml
> @@ -2379,6 +2379,16 @@ that used it. It was originally scheduled for
> removal in 2.6.35. 
>  
> 
> +
> +  V4L2 in Linux 3.3

Seems it will be for 3.4 :-) Same for Documentation/DocBook/media/v4l/v4l2.xml

> +  
> +
> +   Added integer menus, the new type will be
> +   V4L2_CTRL_TYPE_INTEGER_MENU.
> +
> +  
> +
> +
>  
>Relation of V4L2 to other Linux multimedia APIs
> 

-- 
Regards,

Laurent Pinchart
--
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 01/17] v4l: Introduce integer menu controls

Hi Sakari,

Thanks for the patch.

On Tuesday 20 December 2011 21:27:53 Sakari Ailus wrote:
> From: Sakari Ailus 
> 
> Create a new control type called V4L2_CTRL_TYPE_INTEGER_MENU. Integer menu
> controls are just like menu controls but the menu items are 64-bit integers
> rather than strings.

[snip]

> diff --git a/drivers/media/video/v4l2-ctrls.c
> b/drivers/media/video/v4l2-ctrls.c index 0f415da..083bb79 100644
> --- a/drivers/media/video/v4l2-ctrls.c
> +++ b/drivers/media/video/v4l2-ctrls.c

> @@ -1775,16 +1797,22 @@ int v4l2_querymenu(struct v4l2_ctrl_handler *hdl,
> struct v4l2_querymenu *qm)
> 
>   qm->reserved = 0;
>   /* Sanity checks */

You should return -EINVAL here if the control is not of a menu type. It was 
done implictly before by the ctrl->qmenu == NULL check, but that's now 
conditioned to the control type being V4L2_CTRL_TYPE_MENU.

> - if (ctrl->qmenu == NULL ||
> + if ((ctrl->type == V4L2_CTRL_TYPE_MENU && ctrl->qmenu == NULL) ||
> + (ctrl->type == V4L2_CTRL_TYPE_INTEGER_MENU
> +  && ctrl->qmenu_int == NULL) ||
>   i < ctrl->minimum || i > ctrl->maximum)
>   return -EINVAL;
>   /* Use mask to see if this menu item should be skipped */
>   if (ctrl->menu_skip_mask & (1 << i))
>   return -EINVAL;
>   /* Empty menu items should also be skipped */
> - if (ctrl->qmenu[i] == NULL || ctrl->qmenu[i][0] == '\0')
> - return -EINVAL;
> - strlcpy(qm->name, ctrl->qmenu[i], sizeof(qm->name));
> + if (ctrl->type == V4L2_CTRL_TYPE_MENU) {
> + if (ctrl->qmenu[i] == NULL || ctrl->qmenu[i][0] == '\0')
> + return -EINVAL;
> + strlcpy(qm->name, ctrl->qmenu[i], sizeof(qm->name));
> + } else if (ctrl->type == V4L2_CTRL_TYPE_INTEGER_MENU) {

And you can then replace the else if by an else.

> + qm->value = ctrl->qmenu_int[i];
> + }
>   return 0;
>  }
>  EXPORT_SYMBOL(v4l2_querymenu);

-- 
Regards,

Laurent Pinchart
--
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: Add support for two new types of Leadtek Winfast TV 2000XP tuner

2012-01-05 Thread Miroslav Slugeň

Resending signed-off version
Signed-off-by: Miroslav Slugen 
From: Miroslav Slugen 
Date: Mon, 12 Dec 2011 00:20:24 +0100
Subject: [PATCH] Add support for two new types of Leadtek Winfast TV 2000XP tuner, author of
 this patch is Istvan Varga. Only resending current reformated version against
 actual git.

---
 drivers/media/video/cx88/cx88-cards.c |   91 +
 drivers/media/video/cx88/cx88-input.c |4 ++
 drivers/media/video/cx88/cx88.h   |2 +
 3 files changed, 97 insertions(+), 0 deletions(-)

diff --git a/drivers/media/video/cx88/cx88-cards.c b/drivers/media/video/cx88/cx88-cards.c
index 3929d93..dca369d 100644
--- a/drivers/media/video/cx88/cx88-cards.c
+++ b/drivers/media/video/cx88/cx88-cards.c
@@ -1643,6 +1643,78 @@ static const struct cx88_board cx88_boards[] = {
 			.gpio3  = 0x,
 		},
 	},
+	[CX88_BOARD_WINFAST_TV2000_XP_GLOBAL_6F36] = {
+		.name   = "Leadtek TV2000 XP Global (SC4100)",
+		.tuner_type = TUNER_XC4000,
+		.tuner_addr = 0x61,
+		.radio_type = UNSET,
+		.radio_addr = ADDR_UNSET,
+		.input  = { {
+			.type   = CX88_VMUX_TELEVISION,
+			.vmux   = 0,
+			.gpio0  = 0x0400,   /* pin 2 = 0 */
+			.gpio1  = 0x,
+			.gpio2  = 0x0C04,   /* pin 18 = 1, pin 19 = 0 */
+			.gpio3  = 0x,
+		}, {
+			.type   = CX88_VMUX_COMPOSITE1,
+			.vmux   = 1,
+			.gpio0  = 0x0400,   /* pin 2 = 0 */
+			.gpio1  = 0x,
+			.gpio2  = 0x0C0C,   /* pin 18 = 1, pin 19 = 1 */
+			.gpio3  = 0x,
+		}, {
+			.type   = CX88_VMUX_SVIDEO,
+			.vmux   = 2,
+			.gpio0  = 0x0400,   /* pin 2 = 0 */
+			.gpio1  = 0x,
+			.gpio2  = 0x0C0C,   /* pin 18 = 1, pin 19 = 1 */
+			.gpio3  = 0x,
+		} },
+		.radio = {
+			.type   = CX88_RADIO,
+			.gpio0  = 0x0400,/* pin 2 = 0 */
+			.gpio1  = 0x,
+			.gpio2  = 0x0C00,   /* pin 18 = 0, pin 19 = 0 */
+			.gpio3  = 0x,
+		},
+	},
+	[CX88_BOARD_WINFAST_TV2000_XP_GLOBAL_6F43] = {
+		.name   = "Leadtek TV2000 XP Global (XC4100)",
+		.tuner_type = TUNER_XC4000,
+		.tuner_addr = 0x61,
+		.radio_type = UNSET,
+		.radio_addr = ADDR_UNSET,
+		.input  = { {
+			.type   = CX88_VMUX_TELEVISION,
+			.vmux   = 0,
+			.gpio0  = 0x0400,   /* pin 2 = 0 */
+			.gpio1  = 0x6040,   /* pin 14 = 1, pin 13 = 0 */
+			.gpio2  = 0x,
+			.gpio3  = 0x,
+		}, {
+			.type   = CX88_VMUX_COMPOSITE1,
+			.vmux   = 1,
+			.gpio0  = 0x0400,   /* pin 2 = 0 */
+			.gpio1  = 0x6060,   /* pin 14 = 1, pin 13 = 1 */
+			.gpio2  = 0x,
+			.gpio3  = 0x,
+		}, {
+			.type   = CX88_VMUX_SVIDEO,
+			.vmux   = 2,
+			.gpio0  = 0x0400,   /* pin 2 = 0 */
+			.gpio1  = 0x6060,   /* pin 14 = 1, pin 13 = 1 */
+			.gpio2  = 0x,
+			.gpio3  = 0x,
+		} },
+		.radio = {
+			.type   = CX88_RADIO,
+			.gpio0  = 0x0400,/* pin 2 = 0 */
+			.gpio1  = 0x6000,/* pin 14 = 1, pin 13 = 0 */
+			.gpio2  = 0x,
+			.gpio3  = 0x,
+		},
+	},
 	[CX88_BOARD_POWERCOLOR_REAL_ANGEL] = {
 		.name   = "PowerColor RA330",	/* Long names may confuse LIRC. */
 		.tuner_type = TUNER_XC2028,
@@ -2719,6 +2791,21 @@ static const struct cx88_subid cx88_subids[] = {
 		.subdevice = 0x6618,
 		.card  = CX88_BOARD_WINFAST_TV2000_XP_GLOBAL,
 	}, {
+		/* TV2000 XP Global [107d:6618] */
+		.subvendor = 0x107d,
+		.subdevice = 0x6619,
+		.card  = CX88_BOARD_WINFAST_TV2000_XP_GLOBAL,
+	}, {
+		/* WinFast TV2000 XP Global with XC4000 tuner */
+		.subvendor = 0x107d,
+		.subdevice = 0x6f36,
+		.card  = CX88_BOARD_WINFAST_TV2000_XP_GLOBAL_6F36,
+	}, {
+		/* WinFast TV2000 XP Global with XC4000 tuner and different GPIOs */
+		.subvendor = 0x107d,
+		.subdevice = 0x6f43,
+		.card  = CX88_BOARD_WINFAST_TV2000_XP_GLOBAL_6F43,
+	}, {
 		.subvendor = 0xb034,
 		.subdevice = 0x3034,
 		.card  = CX88_BOARD_PROF_7301,
@@ -3075,6 +3162,8 @@ static int cx88_xc4000_tuner_callback(struct cx88_core *core,
 	switch (core->boardnr) {
 	case CX88_BOARD_WINFAST_DTV1800H_XC4000:
 	case CX88_BOARD_WINFAST_DTV2000H_PLUS:
+	case CX88_BOARD_WINFAST_TV2000_XP_GLOBAL_6F36:
+	case CX88_BOARD_WINFAST_TV2000_XP_GLOBAL_6F43:
 		return cx88_xc4000_winfast2000h_plus_callback(core,
 			  command, arg);
 	}
@@ -3250,6 +3339,8 @@ static void cx88_card_setup_pre_i2c(struct cx88_core *core)
 
 	case CX88_BOARD_WINFAST_DTV1800H_XC4000:
 	case CX88_BOARD_WINFAST_DTV2000H_PLUS:
+	case CX88_BOARD_WINFAST_TV2000_XP_GLOBAL_6F36:
+	case CX88_BOARD_WINFAST_TV2000_XP_GLOBAL_6F43:
 		cx88_xc4000_winfast2000h_plus_callback(core,
 		   XC4000_TUNER_RESET, 0);
 		break;
diff --git a/drivers/media/video/cx88/cx88-input.c b/drivers/media/video/cx88/cx88-input.c
index e614201..ebf448c 100644
--- a/drivers/media/video/cx88/cx88-input.c
+++ b/drivers/media/video/cx88/cx88-input.c
@@ -103,6 +103,8 @@ static void cx88_ir_handle_key(struct cx88_IR *ir)
 	case CX88_BOARD_WINFAST_DTV1800H_XC4000:
 	case CX88_BOARD_WINFAST_DTV2000H_PLUS:
 	case CX88_BO

Re: [PATCH 01/11] mm: page_alloc: set_migratetype_isolate: drain PCP prior to isolating

2012-01-05 Thread Michal Nazarewicz


On Thu, 29 Dec 2011 13:39:02 +0100, Marek Szyprowski  
wrote:

From: Michal Nazarewicz 

When set_migratetype_isolate() sets pageblock's migrate type, it does
not change each page_private data.  This makes sense, as the function
has no way of knowing what kind of information page_private stores.

Unfortunately, if a page is on PCP list, it's page_private indicates
its migrate type.  This means, that if a page on PCP list gets
isolated, a call to free_pcppages_bulk() will assume it has the old
migrate type rather than MIGRATE_ISOLATE.  This means, that a page
which should be isolated, will end up on a free list of it's old
migrate type.

Coincidentally, at the very end, set_migratetype_isolate() calls
drain_all_pages() which leads to calling free_pcppages_bulk(), which
does the wrong thing.

To avoid this situation, this commit moves the draining prior to
setting pageblock's migratetype and moving pages from old free list to
MIGRATETYPE_ISOLATE's free list.

Because of spin locks this is a non-trivial change however as both
set_migratetype_isolate() and free_pcppages_bulk() grab zone->lock.
To solve this problem, this commit renames free_pcppages_bulk() to
__free_pcppages_bulk() and changes it so that it no longer grabs
zone->lock instead requiring caller to hold it.  This commit later
adds a __zone_drain_all_pages() function which works just like
drain_all_pages() expects that it drains only pages from a single zone
and assumes that caller holds zone->lock.


As it turns out, with some more testing on SMP systems, this whole patch
turned out to be incorrect.

We have been thinking about other approach and, if we were to use something
else then the first patch from CMAv17[1], the best thing we could came up
with was to unconditionally call drain_all_pages() at the beginning of
set_migratetype_isolate() before the call to spin_lock_irqsave().  It has
a possible race condition but a nightly stress test did have not shown any
problems.

Nonetheless, the cleanest, in my opinion, solution is to use the first patch
from CMAv17 which can be found at [1].

So, to sum up: if you intend to test CMAv18, instead of applying this first
patch either use first patch from CMAv17[1] or put an unconditional call to
drain_all_pages() at the beginning of set_migrate_isolate() function.

Sorry for the troubles.

[1] http://www.spinics.net/lists/arm-kernel/msg148494.html

--
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of  o' \,=./ `o
..o | Computer Science,  Michał “mina86” Nazarewicz(o o)
ooo +--ooO--(_)--Ooo--
--
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 5/5] [media] dvb_frontend: Update ops.info.type earlier

ops.info.type should be updated before copying it into the
memory buffer that will be returned to userspace.

Also add some debug messages to help tracking such issues.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/dvb/dvb-core/dvb_frontend.c |   10 +++---
 1 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.c 
b/drivers/media/dvb/dvb-core/dvb_frontend.c
index cd3c0f6..1e1265e 100644
--- a/drivers/media/dvb/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb/dvb-core/dvb_frontend.c
@@ -1551,6 +1551,8 @@ static int set_delivery_system(struct dvb_frontend *fe, 
u32 desired_system)
}
}
}
+   dprintk("change delivery system on cache to %d\n", c->delivery_system);
+
return 0;
 }
 
@@ -1965,9 +1967,6 @@ static int dvb_frontend_ioctl_legacy(struct file *file,
switch (cmd) {
case FE_GET_INFO: {
struct dvb_frontend_info* info = parg;
-   memcpy(info, &fe->ops.info, sizeof(struct dvb_frontend_info));
-   dvb_frontend_get_frequency_limits(fe, &info->frequency_min, 
&info->frequency_max);
-
/*
 * Associate the 4 delivery systems supported by DVBv3
 * API with their DVBv5 counterpart. For the other standards,
@@ -1998,6 +1997,11 @@ static int dvb_frontend_ioctl_legacy(struct file *file,
   __func__, c->delivery_system);
fe->ops.info.type = FE_OFDM;
}
+   dprintk("current delivery system on cache: %d, V3 type: %d\n",
+   c->delivery_system, fe->ops.info.type);
+
+   memcpy(info, &fe->ops.info, sizeof(struct dvb_frontend_info));
+   dvb_frontend_get_frequency_limits(fe, &info->frequency_min, 
&info->frequency_max);
 
/* Force the CAN_INVERSION_AUTO bit on. If the frontend doesn't
 * do it, it is done for it. */
-- 
1.7.7.5

--
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/5] Fix dvb-core set_delivery_system and port drxk to one frontend

This patch series contain one feature and two bug fixes:

1) it ports the DRX-K driver to use just one frontend for all three
   delivery systems (DVB-C Annex A, DVB-C Annex C and DVB-T).
   As not all DRX-K supports all three, it also adds a logic there to
   show and accept only the delivery systems that are valid to the
   detected DRX-K version;

2) fixes a bug at dvb_frontend that causes it to wait forever, while
   changing to the second or upper delivery system (a var were not
   incremented inside it);

3) fixes a bug that a delivery system change would appear only on the
   second call, for a DVBv3 application.

With all these series applied, it is now possible to use frontend 0
for all delivery systems. As the current tools don't support changing
the delivery system, the dvb-fe-tool (on my experimental tree[1]) can now
be used to change between them:

For example, to use DVB-T with the standard scan:

$ ./dvb-fe-tool -d DVBT && scan /usr/share/dvb/dvb-t/au-Adelaide

[1] 
http://git.linuxtv.org/mchehab/experimental-v4l-utils.git/shortlog/refs/heads/dvb-utils


Mauro Carvalho Chehab (5):
  [media] drxk: remove ops.info.frequency_stepsize from DVB-C
  [media] drxk: create only one frontend for both DVB-C and DVB-T
  [media] drxk_hard: fix locking issues when changing the delsys
  [media] dvb_frontend: regression fix: add a missing inc inside the
loop
  [media] dvb_frontend: Update ops.info.type earlier

 drivers/media/dvb/ddbridge/ddbridge-core.c |2 +-
 drivers/media/dvb/dvb-core/dvb_frontend.c  |   11 +-
 drivers/media/dvb/frontends/drxk.h |6 +-
 drivers/media/dvb/frontends/drxk_hard.c|  206 
 drivers/media/dvb/frontends/drxk_hard.h|4 +-
 drivers/media/dvb/ngene/ngene-cards.c  |2 +-
 drivers/media/video/em28xx/em28xx-dvb.c|   28 +
 7 files changed, 104 insertions(+), 155 deletions(-)

-- 
1.7.7.5

--
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/5] [media] drxk: create only one frontend for both DVB-C and DVB-T

Instead of creating two DVB frontend entries for the same device,
create just one entry, and fill the delivery_system according with
the supported standards.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/dvb/ddbridge/ddbridge-core.c |2 +-
 drivers/media/dvb/frontends/drxk.h |6 +-
 drivers/media/dvb/frontends/drxk_hard.c|  192 
 drivers/media/dvb/frontends/drxk_hard.h|3 +-
 drivers/media/dvb/ngene/ngene-cards.c  |2 +-
 drivers/media/video/em28xx/em28xx-dvb.c|   28 +
 6 files changed, 88 insertions(+), 145 deletions(-)

diff --git a/drivers/media/dvb/ddbridge/ddbridge-core.c 
b/drivers/media/dvb/ddbridge/ddbridge-core.c
index ba9a643..2f31648 100644
--- a/drivers/media/dvb/ddbridge/ddbridge-core.c
+++ b/drivers/media/dvb/ddbridge/ddbridge-core.c
@@ -580,7 +580,7 @@ static int demod_attach_drxk(struct ddb_input *input)
memset(&config, 0, sizeof(config));
config.adr = 0x29 + (input->nr & 1);
 
-   fe = input->fe = dvb_attach(drxk_attach, &config, i2c, &input->fe2);
+   fe = input->fe = dvb_attach(drxk_attach, &config, i2c);
if (!input->fe) {
printk(KERN_ERR "No DRXK found!\n");
return -ENODEV;
diff --git a/drivers/media/dvb/frontends/drxk.h 
b/drivers/media/dvb/frontends/drxk.h
index 870432f..0209818 100644
--- a/drivers/media/dvb/frontends/drxk.h
+++ b/drivers/media/dvb/frontends/drxk.h
@@ -37,12 +37,10 @@ struct drxk_config {
 #if defined(CONFIG_DVB_DRXK) || (defined(CONFIG_DVB_DRXK_MODULE) \
 && defined(MODULE))
 extern struct dvb_frontend *drxk_attach(const struct drxk_config *config,
-   struct i2c_adapter *i2c,
-   struct dvb_frontend **fe_t);
+   struct i2c_adapter *i2c);
 #else
 static inline struct dvb_frontend *drxk_attach(const struct drxk_config 
*config,
-   struct i2c_adapter *i2c,
-   struct dvb_frontend **fe_t)
+   struct i2c_adapter *i2c)
 {
 printk(KERN_WARNING "%s: driver disabled by Kconfig\n", __func__);
 return NULL;
diff --git a/drivers/media/dvb/frontends/drxk_hard.c 
b/drivers/media/dvb/frontends/drxk_hard.c
index 77e78f4..a95fb44 100644
--- a/drivers/media/dvb/frontends/drxk_hard.c
+++ b/drivers/media/dvb/frontends/drxk_hard.c
@@ -6174,7 +6174,7 @@ error:
return status;
 }
 
-static void drxk_c_release(struct dvb_frontend *fe)
+static void drxk_release(struct dvb_frontend *fe)
 {
struct drxk_state *state = fe->demodulator_priv;
 
@@ -6182,21 +6182,7 @@ static void drxk_c_release(struct dvb_frontend *fe)
kfree(state);
 }
 
-static int drxk_c_init(struct dvb_frontend *fe)
-{
-   struct drxk_state *state = fe->demodulator_priv;
-
-   dprintk(1, "\n");
-   if (mutex_trylock(&state->ctlock) == 0)
-   return -EBUSY;
-   if (state->m_itut_annex_c)
-   SetOperationMode(state, OM_QAM_ITU_C);
-   else
-   SetOperationMode(state, OM_QAM_ITU_A);
-   return 0;
-}
-
-static int drxk_c_sleep(struct dvb_frontend *fe)
+static int drxk_sleep(struct dvb_frontend *fe)
 {
struct drxk_state *state = fe->demodulator_priv;
 
@@ -6229,24 +6215,36 @@ static int drxk_set_parameters(struct dvb_frontend *fe)
return -EINVAL;
}
 
+   if (fe->ops.i2c_gate_ctrl)
+   fe->ops.i2c_gate_ctrl(fe, 1);
+   if (fe->ops.tuner_ops.set_params)
+   fe->ops.tuner_ops.set_params(fe);
+   if (fe->ops.i2c_gate_ctrl)
+   fe->ops.i2c_gate_ctrl(fe, 0);
+   state->props = *p;
+
switch (delsys) {
case SYS_DVBC_ANNEX_A:
-   state->m_itut_annex_c = false;
-   break;
case SYS_DVBC_ANNEX_C:
+   if (!state->m_hasDVBC)
+   return -EINVAL;
+   state->m_itut_annex_c = (delsys == SYS_DVBC_ANNEX_C) ? true : 
false;
+   if (state->m_itut_annex_c)
+   SetOperationMode(state, OM_QAM_ITU_C);
+   else
+   SetOperationMode(state, OM_QAM_ITU_A);
+   break;
state->m_itut_annex_c = true;
break;
+   case SYS_DVBT:
+   if (!state->m_hasDVBT)
+   return -EINVAL;
+   SetOperationMode(state, OM_DVBT);
+   break;
default:
return -EINVAL;
}
 
-   if (fe->ops.i2c_gate_ctrl)
-   fe->ops.i2c_gate_ctrl(fe, 1);
-   if (fe->ops.tuner_ops.set_params)
-   fe->ops.tuner_ops.set_params(fe);
-   if (fe->ops.i2c_gate_ctrl)
-   fe->ops.i2c_gate_ctrl(fe, 0);
-   state->props = *p;
fe->ops.tuner_ops.get_if_frequency(fe, &IF);
Start(state, 0, IF);
 
@@ -6314,91 +6312,54 @@

[PATCH 4/5] [media] dvb_frontend: regression fix: add a missing inc inside the loop

without it, the loop will run forever!

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/dvb/dvb-core/dvb_frontend.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.c 
b/drivers/media/dvb/dvb-core/dvb_frontend.c
index 678e329..cd3c0f6 100644
--- a/drivers/media/dvb/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb/dvb-core/dvb_frontend.c
@@ -1481,6 +1481,7 @@ static int set_delivery_system(struct dvb_frontend *fe, 
u32 desired_system)
__func__, desired_system);
return 0;
}
+   ncaps++;
}
type = dvbv3_type(desired_system);
 
-- 
1.7.7.5

--
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 1/5] [media] drxk: remove ops.info.frequency_stepsize from DVB-C

ops.info.frequency_stepsize is used only for DVB-T & friends. For
DVB-C, the step size is calculated using the symbol rate.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/dvb/frontends/drxk_hard.c |1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/drivers/media/dvb/frontends/drxk_hard.c 
b/drivers/media/dvb/frontends/drxk_hard.c
index c8213f6..77e78f4 100644
--- a/drivers/media/dvb/frontends/drxk_hard.c
+++ b/drivers/media/dvb/frontends/drxk_hard.c
@@ -6356,7 +6356,6 @@ static struct dvb_frontend_ops drxk_c_ops = {
.delsys = { SYS_DVBC_ANNEX_A, SYS_DVBC_ANNEX_C },
.info = {
 .name = "DRXK DVB-C",
-.frequency_stepsize = 62500,
 .frequency_min = 4700,
 .frequency_max = 86200,
 .symbol_rate_min = 87,
-- 
1.7.7.5

--
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 3/5] [media] drxk_hard: fix locking issues when changing the delsys

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/dvb/frontends/drxk_hard.c |   45 --
 drivers/media/dvb/frontends/drxk_hard.h |1 -
 2 files changed, 24 insertions(+), 22 deletions(-)

diff --git a/drivers/media/dvb/frontends/drxk_hard.c 
b/drivers/media/dvb/frontends/drxk_hard.c
index a95fb44..97670db 100644
--- a/drivers/media/dvb/frontends/drxk_hard.c
+++ b/drivers/media/dvb/frontends/drxk_hard.c
@@ -6188,7 +6188,6 @@ static int drxk_sleep(struct dvb_frontend *fe)
 
dprintk(1, "\n");
ShutDown(state);
-   mutex_unlock(&state->ctlock);
return 0;
 }
 
@@ -6203,7 +6202,7 @@ static int drxk_gate_ctrl(struct dvb_frontend *fe, int 
enable)
 static int drxk_set_parameters(struct dvb_frontend *fe)
 {
struct dtv_frontend_properties *p = &fe->dtv_property_cache;
-   u32 delsys  = p->delivery_system;
+   u32 delsys  = p->delivery_system, old_delsys;
struct drxk_state *state = fe->demodulator_priv;
u32 IF;
 
@@ -6221,28 +6220,33 @@ static int drxk_set_parameters(struct dvb_frontend *fe)
fe->ops.tuner_ops.set_params(fe);
if (fe->ops.i2c_gate_ctrl)
fe->ops.i2c_gate_ctrl(fe, 0);
+
+   old_delsys = state->props.delivery_system;
state->props = *p;
 
-   switch (delsys) {
-   case SYS_DVBC_ANNEX_A:
-   case SYS_DVBC_ANNEX_C:
-   if (!state->m_hasDVBC)
-   return -EINVAL;
-   state->m_itut_annex_c = (delsys == SYS_DVBC_ANNEX_C) ? true : 
false;
-   if (state->m_itut_annex_c)
-   SetOperationMode(state, OM_QAM_ITU_C);
-   else
-   SetOperationMode(state, OM_QAM_ITU_A);
+   if (old_delsys != delsys) {
+   ShutDown(state);
+   switch (delsys) {
+   case SYS_DVBC_ANNEX_A:
+   case SYS_DVBC_ANNEX_C:
+   if (!state->m_hasDVBC)
+   return -EINVAL;
+   state->m_itut_annex_c = (delsys == SYS_DVBC_ANNEX_C) ? 
true : false;
+   if (state->m_itut_annex_c)
+   SetOperationMode(state, OM_QAM_ITU_C);
+   else
+   SetOperationMode(state, OM_QAM_ITU_A);
+   break;
+   state->m_itut_annex_c = true;
break;
-   state->m_itut_annex_c = true;
-   break;
-   case SYS_DVBT:
-   if (!state->m_hasDVBT)
+   case SYS_DVBT:
+   if (!state->m_hasDVBT)
+   return -EINVAL;
+   SetOperationMode(state, OM_DVBT);
+   break;
+   default:
return -EINVAL;
-   SetOperationMode(state, OM_DVBT);
-   break;
-   default:
-   return -EINVAL;
+   }
}
 
fe->ops.tuner_ops.get_if_frequency(fe, &IF);
@@ -6405,7 +6409,6 @@ struct dvb_frontend *drxk_attach(const struct drxk_config 
*config,
state->m_GPIO &= ~state->antenna_gpio;
 
mutex_init(&state->mutex);
-   mutex_init(&state->ctlock);
 
memcpy(&state->frontend.ops, &drxk_ops, sizeof(drxk_ops));
state->frontend.demodulator_priv = state;
diff --git a/drivers/media/dvb/frontends/drxk_hard.h 
b/drivers/media/dvb/frontends/drxk_hard.h
index 7e3e4cf..3a58b73 100644
--- a/drivers/media/dvb/frontends/drxk_hard.h
+++ b/drivers/media/dvb/frontends/drxk_hard.h
@@ -204,7 +204,6 @@ struct drxk_state {
void  *priv;
 
struct mutex mutex;
-   struct mutex ctlock;
 
u32m_Instance;   /**< Channel 1,2,3 or 4 */
 
-- 
1.7.7.5

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

[PATCH v2] media: tvp5150: Add mbus_fmt callbacks.

2012-01-05 Thread Javier Martin

These callbacks allow a host video driver
to poll video formats supported by tvp5150.

---
Changes since v1:
 Fix standard handling in tvp5150_mbus_fmt()
---
 drivers/media/video/tvp5150.c |   67 +
 1 files changed, 67 insertions(+), 0 deletions(-)

diff --git a/drivers/media/video/tvp5150.c b/drivers/media/video/tvp5150.c
index 26cc75b..c58c8d5 100644
--- a/drivers/media/video/tvp5150.c
+++ b/drivers/media/video/tvp5150.c
@@ -778,6 +778,70 @@ static int tvp5150_s_ctrl(struct v4l2_ctrl *ctrl)
return -EINVAL;
 }
 
+static v4l2_std_id tvp5150_read_std(struct v4l2_subdev *sd)
+{
+   int val = tvp5150_read(sd, TVP5150_STATUS_REG_5);
+
+   switch (val & 0x0F) {
+   case 0x01:
+   return V4L2_STD_NTSC;
+   case 0x03:
+   return V4L2_STD_PAL;
+   case 0x05:
+   return V4L2_STD_PAL_M;
+   case 0x07:
+   return V4L2_STD_PAL_N | V4L2_STD_PAL_Nc;
+   case 0x09:
+   return V4L2_STD_NTSC_443;
+   case 0xb:
+   return V4L2_STD_SECAM;
+   default:
+   return V4L2_STD_UNKNOWN;
+   }
+}
+
+static int tvp5150_enum_mbus_fmt(struct v4l2_subdev *sd, unsigned index,
+   enum v4l2_mbus_pixelcode *code)
+{
+   if (index)
+   return -EINVAL;
+
+   *code = V4L2_MBUS_FMT_YUYV8_2X8;
+   return 0;
+}
+
+static int tvp5150_mbus_fmt(struct v4l2_subdev *sd,
+   struct v4l2_mbus_framefmt *f)
+{
+   struct tvp5150 *decoder = to_tvp5150(sd);
+   v4l2_std_id std;
+
+   if (f == NULL)
+   return -EINVAL;
+
+   tvp5150_reset(sd, 0);
+
+   /* Calculate height and width based on current standard */
+   if (decoder->norm == V4L2_STD_ALL)
+   std = tvp5150_read_std(sd);
+   else
+   std = decoder->norm;
+
+   f->width = 720;
+   if (std & V4L2_STD_525_60)
+   f->height = 480;
+   else
+   f->height = 576;
+
+   f->code = V4L2_MBUS_FMT_YUYV8_2X8;
+   f->field = V4L2_FIELD_SEQ_TB;
+   f->colorspace = V4L2_COLORSPACE_SMPTE170M;
+
+   v4l2_dbg(1, debug, sd, "width = %d, height = %d\n", f->width,
+   f->height);
+   return 0;
+}
+
 /
I2C Command
  /
@@ -930,6 +994,9 @@ static const struct v4l2_subdev_tuner_ops tvp5150_tuner_ops 
= {
 
 static const struct v4l2_subdev_video_ops tvp5150_video_ops = {
.s_routing = tvp5150_s_routing,
+   .enum_mbus_fmt = tvp5150_enum_mbus_fmt,
+   .s_mbus_fmt = tvp5150_mbus_fmt,
+   .try_mbus_fmt = tvp5150_mbus_fmt,
 };
 
 static const struct v4l2_subdev_vbi_ops tvp5150_vbi_ops = {
-- 
1.7.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: subdev support for querying struct v4l2_input *

2012-01-05 Thread Steven Toth

>> In the cx23885 driver as part of vidioc_enum_input call, I have a need
>> to return V4L2_IN_ST_NO_SIGNAL in the status
>> field as part of struct v4l2_input. Thus, when no signal is detected
>> by the video decoder it can be signalled to the calling application.
>>
> v4l2_subdev_video_ops->g_input_status

I'm blind.

That will work, thanks Scott.

-- 
Steven Toth - Kernel Labs
http://www.kernellabs.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

Fix Leadtek DTV2000H radio tuner

2012-01-05 Thread Miroslav Slugeň

Resending signed-off version for kernel 3.2
Signed-off-by: Miroslav Slugen 
From dadfa45664f765297e03e73a907ac04bd55e9b25 Mon Sep 17 00:00:00 2001
From: Miroslav Slugen 
Date: Tue, 13 Dec 2011 19:36:15 +0100
Subject: [PATCH] Leadtek DTV2000H J has Philips FMD1216MEX tuner, this patch fixed not working
 radio part, but some stations are still not visible.

---
diff -Naurp a/drivers/media/video/cx88/cx88-cards.c b/drivers/media/video/cx88/cx88-cards.c
--- a/drivers/media/video/cx88/cx88-cards.c	2012-01-05 00:55:44.0 +0100
+++ b/drivers/media/video/cx88/cx88-cards.c	2012-01-05 12:38:27.177910802 +0100
@@ -1306,7 +1306,7 @@ static const struct cx88_board cx88_boar
 	},
 	[CX88_BOARD_WINFAST_DTV2000H_J] = {
 		.name   = "WinFast DTV2000 H rev. J",
-		.tuner_type = TUNER_PHILIPS_FMD1216ME_MK3,
+		.tuner_type = TUNER_PHILIPS_FMD1216MEX_MK3,
 		.radio_type = UNSET,
 		.tuner_addr = ADDR_UNSET,
 		.radio_addr = ADDR_UNSET,
@@ -3232,6 +3232,7 @@ static void cx88_card_setup_pre_i2c(stru
 		cx_set(MO_GP0_IO, 0x1010);
 		break;
 
+	case CX88_BOARD_WINFAST_DTV2000H_J:
 	case CX88_BOARD_HAUPPAUGE_HVR3000:
 	case CX88_BOARD_HAUPPAUGE_HVR4000:
 		/* Init GPIO */
diff -Naurp a/drivers/media/video/cx88/cx88-dvb.c b/drivers/media/video/cx88/cx88-dvb.c
--- a/drivers/media/video/cx88/cx88-dvb.c	2012-01-05 00:55:44.0 +0100
+++ b/drivers/media/video/cx88/cx88-dvb.c	2012-01-05 12:38:27.177910802 +0100
@@ -999,7 +999,6 @@ static int dvb_register(struct cx8802_de
 		}
 		break;
 	case CX88_BOARD_WINFAST_DTV2000H:
-	case CX88_BOARD_WINFAST_DTV2000H_J:
 	case CX88_BOARD_HAUPPAUGE_HVR1100:
 	case CX88_BOARD_HAUPPAUGE_HVR1100LP:
 	case CX88_BOARD_HAUPPAUGE_HVR1300:
@@ -1013,6 +1012,17 @@ static int dvb_register(struct cx8802_de
 goto frontend_detach;
 		}
 		break;
+	case CX88_BOARD_WINFAST_DTV2000H_J:
+		fe0->dvb.frontend = dvb_attach(cx22702_attach,
+	   &hauppauge_hvr_config,
+	   &core->i2c_adap);
+		if (fe0->dvb.frontend != NULL) {
+			if (!dvb_attach(simple_tuner_attach, fe0->dvb.frontend,
+   &core->i2c_adap, 0x61,
+   TUNER_PHILIPS_FMD1216MEX_MK3))
+goto frontend_detach;
+		}
+		break;
 	case CX88_BOARD_HAUPPAUGE_HVR3000:
 		/* MFE frontend 1 */
 		mfe_shared = 1;
diff -Naurp a/drivers/media/video/tuner-core.c b/drivers/media/video/tuner-core.c
--- a/drivers/media/video/tuner-core.c	2012-01-05 00:55:44.0 +0100
+++ b/drivers/media/video/tuner-core.c	2012-01-05 12:38:27.177910802 +0100
@@ -326,6 +326,7 @@ static void set_type(struct i2c_client *
 		t->mode_mask = T_RADIO;
 		break;
 	case TUNER_PHILIPS_FMD1216ME_MK3:
+	case TUNER_PHILIPS_FMD1216MEX_MK3:
 		buffer[0] = 0x0b;
 		buffer[1] = 0xdc;
 		buffer[2] = 0x9c;

[GIT PULL] davinci vpbe pull request

2012-01-05 Thread Hadli, Manjunath

Hi Mauro,
 Can you please pull these vpbe patches which add the support for
 DM365 and DM355 display?

 The 3 vpbe patches were sent to you as a pull request earlier. Please  see 
this mail:
 
http://linux.omap.com/pipermail/davinci-linux-open-source/2011-November/023496.html

 I have now rebased these to 3.2 since my earlier pull request was  not based 
on commits on Linus's tree.
 As a result they look like recent commits, but have actually been  around for 
a long time.

 Thx,
 -Manju

The following changes since commit 805a6af8dba5dfdd35ec35dc52ec0122400b2610:
  Linus Torvalds (1):
Linux 3.2

are available in the git repository at:

  git://linuxtv.org/mhadli/v4l-dvb-davinci_devices.git for-mauro-v3.3

Manjunath Hadli (3):
  davinci vpbe: add dm365 VPBE display driver changes
  davinci vpbe: add dm365 and dm355 specific OSD changes
  davinci vpbe: add VENC block changes to enable dm365 and dm355

 drivers/media/video/davinci/vpbe.c  |   48 +++-
 drivers/media/video/davinci/vpbe_osd.c  |  473 --- 
 drivers/media/video/davinci/vpbe_venc.c |  205 --
 include/media/davinci/vpbe.h|   16 +
 include/media/davinci/vpbe_venc.h   |4 +
 5 files changed, 678 insertions(+), 68 deletions(-)
--
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/1] omap3isp: Check media bus code on links

2012-01-05 Thread Sakari Ailus

Hi Laurent,

On Thu, Jan 05, 2012 at 11:12:14AM +0100, Laurent Pinchart wrote:
> Hi Sakari,
> 
> On Thursday 05 January 2012 10:10:19 Sakari Ailus wrote:
> > Check media bus code on links. The user could configure different formats
> > at different ends of the link, say, 8 bits-per-pixel in the source and 10
> > bits-per-pixel in the sink. This leads to interesting and typically
> > undesired results image-wise.
> > 
> > Signed-off-by: Sakari Ailus 
> > ---
> >  drivers/media/video/omap3isp/ispvideo.c |3 ++-
> >  1 files changed, 2 insertions(+), 1 deletions(-)
> > 
> > diff --git a/drivers/media/video/omap3isp/ispvideo.c
> > b/drivers/media/video/omap3isp/ispvideo.c index 615dae5..dbdd5b4 100644
> > --- a/drivers/media/video/omap3isp/ispvideo.c
> > +++ b/drivers/media/video/omap3isp/ispvideo.c
> > @@ -352,7 +352,8 @@ static int isp_video_validate_pipeline(struct
> > isp_pipeline *pipe)
> > 
> > /* Check if the two ends match */
> > if (fmt_source.format.width != fmt_sink.format.width ||
> > -   fmt_source.format.height != fmt_sink.format.height)
> > +   fmt_source.format.height != fmt_sink.format.height ||
> > +   fmt_source.format.code != fmt_sink.format.code)
> 
> If you scroll down a bit, the check is already present in the second branch 
> of 
> the if statement. The reason why the driver doesn't enforce the same format 
> unconditionally is that the lane shifter on the CCDC sink link can shift 
> data, 
> so a special check is needed there.

Ooops. My mistake --- I had made an error in implementing
validate_pipeline() op. Somehow my assumption was the resulted issue would
be present in the original code.

You may thus ignore this patch completely.

-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: sai...@retiisi.org.uk
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFCv1 4/4] v4l:vb2: Add dma-contig allocator as dma_buf user

This patch makes changes for adding dma-contig as a dma_buf user. It provides
function implementations for the {attach, detach, map, unmap}_dmabuf()
mem_ops of DMABUF memory type.

Signed-off-by: Sumit Semwal 
Signed-off-by: Sumit Semwal 
---
 drivers/media/video/videobuf2-dma-contig.c |  125 
 1 files changed, 125 insertions(+), 0 deletions(-)

diff --git a/drivers/media/video/videobuf2-dma-contig.c 
b/drivers/media/video/videobuf2-dma-contig.c
index f17ad98..e671371 100644
--- a/drivers/media/video/videobuf2-dma-contig.c
+++ b/drivers/media/video/videobuf2-dma-contig.c
@@ -13,6 +13,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #include 
 #include 
@@ -27,6 +29,7 @@ struct vb2_dc_buf {
dma_addr_t  dma_addr;
unsigned long   size;
struct vm_area_struct   *vma;
+   struct dma_buf_attachment   *db_attach;
atomic_trefcount;
struct vb2_vmarea_handler   handler;
 };
@@ -37,6 +40,7 @@ static void *vb2_dma_contig_alloc(void *alloc_ctx, unsigned 
long size)
 {
struct vb2_dc_conf *conf = alloc_ctx;
struct vb2_dc_buf *buf;
+   /* TODO: add db_attach processing while adding DMABUF as exporter */
 
buf = kzalloc(sizeof *buf, GFP_KERNEL);
if (!buf)
@@ -106,6 +110,8 @@ static int vb2_dma_contig_mmap(void *buf_priv, struct 
vm_area_struct *vma)
return -EINVAL;
}
 
+   WARN_ON(buf->db_attach);
+
return vb2_mmap_pfn_range(vma, buf->dma_addr, buf->size,
  &vb2_common_vm_ops, &buf->handler);
 }
@@ -148,6 +154,121 @@ static void vb2_dma_contig_put_userptr(void *mem_priv)
kfree(buf);
 }
 
+static int vb2_dma_contig_map_dmabuf(void *mem_priv,
+   enum dma_data_direction direction)
+{
+   struct vb2_dc_buf *buf = mem_priv;
+   struct dma_buf *dmabuf;
+   struct sg_table *sg;
+
+   if (!buf || !buf->db_attach) {
+   printk(KERN_ERR "No dma buffer to pin\n");
+   return -EINVAL;
+   }
+
+   WARN_ON(buf->dma_addr);
+
+   if (direction == DMA_NONE) {
+   printk(KERN_ERR "Incorrect DMA direction\n");
+   return -EINVAL;
+   }
+
+   dmabuf = buf->db_attach->dmabuf;
+
+   /* get the associated scatterlist for this buffer */
+   sg = dma_buf_map_attachment(buf->db_attach, direction);
+
+   if (!sg) {
+   printk(KERN_ERR "Error getting dmabuf scatterlist\n");
+   return -EINVAL;
+   }
+
+   /*
+*  convert sglist to paddr:
+*  Assumption: for dma-contig, dmabuf would map to single entry
+*  Will return an error if it has more than one.
+*/
+   if (sg->nents > 1) {
+   printk(KERN_ERR
+   "dmabuf scatterlist has more than 1 entry\n");
+   return -EINVAL;
+   }
+
+   buf->dma_addr = sg_dma_address(sg->sgl);
+   /* TODO: check the buffer size as per S_FMT */
+   buf->size = sg_dma_len(sg->sgl);
+
+   /* save this scatterlist in dmabuf for put_scatterlist */
+   dmabuf->priv = sg;
+
+   return 0;
+}
+
+static void vb2_dma_contig_unmap_dmabuf(void *mem_priv)
+{
+   struct vb2_dc_buf *buf = mem_priv;
+   struct dma_buf *dmabuf;
+   struct sg_table *sg;
+
+   if (!buf || !buf->db_attach)
+   return;
+
+   WARN_ON(!buf->dma_addr);
+
+   dmabuf = buf->db_attach->dmabuf;
+   sg = dmabuf->priv;
+
+   /* Put the sg for this buffer */
+   dma_buf_unmap_attachment(buf->db_attach, sg);
+
+   buf->dma_addr = 0;
+   buf->size = 0;
+}
+
+static void *vb2_dma_contig_attach_dmabuf(void *alloc_ctx, struct dma_buf 
*dbuf)
+{
+   struct vb2_dc_conf *conf = alloc_ctx;
+   struct vb2_dc_buf *buf;
+   struct dma_buf_attachment *dba;
+
+   buf = kzalloc(sizeof *buf, GFP_KERNEL);
+   if (!buf)
+   return ERR_PTR(-ENOMEM);
+
+   /* create attachment for the dmabuf with the user device */
+   dba = dma_buf_attach(dbuf, conf->dev);
+   if (IS_ERR(dba)) {
+   printk(KERN_ERR "failed to attach dmabuf\n");
+   kfree(buf);
+   return dba;
+   }
+
+   buf->conf = conf;
+   buf->size = dba->dmabuf->size;
+   buf->db_attach = dba;
+   buf->dma_addr = 0; /* dma_addr is available only after map */
+
+   return buf;
+}
+
+static void vb2_dma_contig_detach_dmabuf(void *mem_priv)
+{
+   struct vb2_dc_buf *buf = mem_priv;
+
+   if (!buf)
+   return;
+
+   if (buf->dma_addr) {
+   vb2_dma_contig_unmap_dmabuf(buf);
+   }
+
+   /* detach this attachment */
+   dma_buf_detach(buf->db_attach->dmabuf, buf->db_attach);
+   buf->db_attach = NULL;
+
+   kfree(buf);
+}
+
 const struct vb2_mem_ops vb2_dma_contig_memops = {
.alloc

[RFCv1 3/4] v4l:vb: remove warnings about MEMORY_DMABUF

Adding DMABUF memory type causes videobuf to complain about not using it
in some switch cases. This patch removes these warnings.

Signed-off-by: Sumit Semwal 
---
 drivers/media/video/videobuf-core.c |4 
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/drivers/media/video/videobuf-core.c 
b/drivers/media/video/videobuf-core.c
index de4fa4e..b457c8b 100644
--- a/drivers/media/video/videobuf-core.c
+++ b/drivers/media/video/videobuf-core.c
@@ -335,6 +335,9 @@ static void videobuf_status(struct videobuf_queue *q, 
struct v4l2_buffer *b,
case V4L2_MEMORY_OVERLAY:
b->m.offset  = vb->boff;
break;
+   case V4L2_MEMORY_DMABUF:
+   /* DMABUF is not handled in videobuf framework */
+   break;
}
 
b->flags= 0;
@@ -411,6 +414,7 @@ int __videobuf_mmap_setup(struct videobuf_queue *q,
break;
case V4L2_MEMORY_USERPTR:
case V4L2_MEMORY_OVERLAY:
+   case V4L2_MEMORY_DMABUF:
/* nothing */
break;
}
-- 
1.7.5.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

[RFCv1 2/4] v4l:vb2: add support for shared buffer (dma_buf)

This patch adds support for DMABUF memory type in videobuf2. It calls relevant
APIs of dma_buf for v4l reqbuf / qbuf / dqbuf operations.

For this version, the support is for videobuf2 as a user of the shared buffer;
so the allocation of the buffer is done outside of V4L2. [A sample allocator of
dma-buf shared buffer is given at [1]]

[1]: Rob Clark's DRM:
   https://github.com/robclark/kernel-omap4/commits/drmplane-dmabuf

Signed-off-by: Tomasz Stanislawski 
   [original work in the PoC for buffer sharing]
Signed-off-by: Sumit Semwal 
Signed-off-by: Sumit Semwal 
---
 drivers/media/video/videobuf2-core.c |  186 +-
 include/media/videobuf2-core.h   |   30 ++
 2 files changed, 215 insertions(+), 1 deletions(-)

diff --git a/drivers/media/video/videobuf2-core.c 
b/drivers/media/video/videobuf2-core.c
index 95a3f5e..6cd2f97 100644
--- a/drivers/media/video/videobuf2-core.c
+++ b/drivers/media/video/videobuf2-core.c
@@ -107,6 +107,27 @@ static void __vb2_buf_userptr_put(struct vb2_buffer *vb)
 }
 
 /**
+ * __vb2_buf_dmabuf_put() - release memory associated with
+ * a DMABUF shared buffer
+ */
+static void __vb2_buf_dmabuf_put(struct vb2_buffer *vb)
+{
+   struct vb2_queue *q = vb->vb2_queue;
+   unsigned int plane;
+
+   for (plane = 0; plane < vb->num_planes; ++plane) {
+   void *mem_priv = vb->planes[plane].mem_priv;
+
+   if (mem_priv) {
+   call_memop(q, plane, detach_dmabuf, mem_priv);
+   dma_buf_put(vb->planes[plane].dbuf);
+   vb->planes[plane].dbuf = NULL;
+   vb->planes[plane].mem_priv = NULL;
+   }
+   }
+}
+
+/**
  * __setup_offsets() - setup unique offsets ("cookies") for every plane in
  * every buffer on the queue
  */
@@ -228,6 +249,8 @@ static void __vb2_free_mem(struct vb2_queue *q, unsigned 
int buffers)
/* Free MMAP buffers or release USERPTR buffers */
if (q->memory == V4L2_MEMORY_MMAP)
__vb2_buf_mem_free(vb);
+   if (q->memory == V4L2_MEMORY_DMABUF)
+   __vb2_buf_dmabuf_put(vb);
else
__vb2_buf_userptr_put(vb);
}
@@ -350,6 +373,13 @@ static int __fill_v4l2_buffer(struct vb2_buffer *vb, 
struct v4l2_buffer *b)
 */
memcpy(b->m.planes, vb->v4l2_planes,
b->length * sizeof(struct v4l2_plane));
+
+   if (q->memory == V4L2_MEMORY_DMABUF) {
+   unsigned int plane;
+   for (plane = 0; plane < vb->num_planes; ++plane) {
+   b->m.planes[plane].m.fd = 0;
+   }
+   }
} else {
/*
 * We use length and offset in v4l2_planes array even for
@@ -361,6 +391,8 @@ static int __fill_v4l2_buffer(struct vb2_buffer *vb, struct 
v4l2_buffer *b)
b->m.offset = vb->v4l2_planes[0].m.mem_offset;
else if (q->memory == V4L2_MEMORY_USERPTR)
b->m.userptr = vb->v4l2_planes[0].m.userptr;
+   else if (q->memory == V4L2_MEMORY_DMABUF)
+   b->m.fd = 0;
}
 
/*
@@ -452,6 +484,21 @@ static int __verify_mmap_ops(struct vb2_queue *q)
 }
 
 /**
+ * __verify_dmabuf_ops() - verify that all memory operations required for
+ * DMABUF queue type have been provided
+ */
+static int __verify_dmabuf_ops(struct vb2_queue *q)
+{
+   if (!(q->io_modes & VB2_DMABUF) || !q->mem_ops->attach_dmabuf
+   || !q->mem_ops->detach_dmabuf
+   || !q->mem_ops->map_dmabuf
+   || !q->mem_ops->unmap_dmabuf)
+   return -EINVAL;
+
+   return 0;
+}
+
+/**
  * vb2_reqbufs() - Initiate streaming
  * @q: videobuf2 queue
  * @req:   struct passed from userspace to vidioc_reqbufs handler in driver
@@ -485,6 +532,7 @@ int vb2_reqbufs(struct vb2_queue *q, struct 
v4l2_requestbuffers *req)
}
 
if (req->memory != V4L2_MEMORY_MMAP
+   && req->memory != V4L2_MEMORY_DMABUF
&& req->memory != V4L2_MEMORY_USERPTR) {
dprintk(1, "reqbufs: unsupported memory type\n");
return -EINVAL;
@@ -514,6 +562,11 @@ int vb2_reqbufs(struct vb2_queue *q, struct 
v4l2_requestbuffers *req)
return -EINVAL;
}
 
+   if (req->memory == V4L2_MEMORY_DMABUF && __verify_dmabuf_ops(q)) {
+   dprintk(1, "reqbufs: DMABUF for current setup unsupported\n");
+   return -EINVAL;
+   }
+
if (req->count == 0 || q->num_buffers != 0 || q->memory != req->memory) 
{
/*
 * We already have buffers allocated, so first check if they
@@ -621,7 +674,8 @@ int vb2_create_bufs(struct vb2_queue *q, struct 
v4l2_create_buffers *create)

[RFCv1 1/4] v4l: Add DMABUF as a memory type

Adds DMABUF memory type to v4l framework. Also adds the related file
descriptor in v4l2_plane and v4l2_buffer.

Signed-off-by: Tomasz Stanislawski 
   [original work in the PoC for buffer sharing]
Signed-off-by: Sumit Semwal 
Signed-off-by: Sumit Semwal 
---
 include/linux/videodev2.h |8 
 1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 4b752d5..3c0ade1 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -185,6 +185,7 @@ enum v4l2_memory {
V4L2_MEMORY_MMAP = 1,
V4L2_MEMORY_USERPTR  = 2,
V4L2_MEMORY_OVERLAY  = 3,
+   V4L2_MEMORY_DMABUF   = 4,
 };
 
 /* see also http://vektor.theorem.ca/graphics/ycbcr/ */
@@ -574,6 +575,8 @@ struct v4l2_requestbuffers {
  * should be passed to mmap() called on the video node)
  * @userptr:   when memory is V4L2_MEMORY_USERPTR, a userspace pointer
  * pointing to this plane
+ * @fd:when memory is V4L2_MEMORY_DMABUF, a userspace 
file
+ * descriptor associated with this plane
  * @data_offset:   offset in the plane to the start of data; usually 0,
  * unless there is a header in front of the data
  *
@@ -588,6 +591,7 @@ struct v4l2_plane {
union {
__u32   mem_offset;
unsigned long   userptr;
+   int fd;
} m;
__u32   data_offset;
__u32   reserved[11];
@@ -610,6 +614,9 @@ struct v4l2_plane {
  * (or a "cookie" that should be passed to mmap() as offset)
  * @userptr:   for non-multiplanar buffers with memory == V4L2_MEMORY_USERPTR;
  * a userspace pointer pointing to this buffer
+ * @fd:for non-multiplanar buffers with
+ * memory == V4L2_MEMORY_DMABUF; a userspace file descriptor
+ * associated with this buffer
  * @planes:for multiplanar buffers; userspace pointer to the array of plane
  * info structs for this buffer
  * @length:size in bytes of the buffer (NOT its payload) for single-plane
@@ -636,6 +643,7 @@ struct v4l2_buffer {
__u32   offset;
unsigned long   userptr;
struct v4l2_plane *planes;
+   int fd;
} m;
__u32   length;
__u32   input;
-- 
1.7.5.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

[RFCv1 0/4] v4l: DMA buffer sharing support as a user

Hello Everyone,

A very happy new year 2012! :)

This patchset is an RFC for the way videobuf2 can be adapted to add support for
DMA buffer sharing framework[1].

The original patch-set for the idea, and PoC of buffer sharing was by 
Tomasz Stanislawski , who demonstrated buffer sharing
between two v4l2 devices[2]. This RFC is needed to adapt these patches to the
changes that have happened in the DMA buffer sharing framework over past few
months.

To begin with, I have tried to adapt only the dma-contig allocator, and only as
a user of dma-buf buffer. I am currently working on the v4l2-as-an-exporter
changes, and will share as soon as I get it in some shape.

As with the PoC [2], the handle for sharing buffers is a file-descriptor (fd).
The usage documentation is also a part of [1].

So, the current RFC has the following limitations:
- Only buffer sharing as a buffer user,
- doesn't handle cases where even for a contiguous buffer, the sg_table can have
   more than one scatterlist entry.


Thanks and best regards,
~Sumit.

[1]: dma-buf patchset at: https://lkml.org/lkml/2011/12/26/29
[2]: http://lwn.net/Articles/454389

Sumit Semwal (4):
  v4l: Add DMABUF as a memory type
  v4l:vb2: add support for shared buffer (dma_buf)
  v4l:vb: remove warnings about MEMORY_DMABUF
  v4l:vb2: Add dma-contig allocator as dma_buf user

 drivers/media/video/videobuf-core.c|4 +
 drivers/media/video/videobuf2-core.c   |  186 +++-
 drivers/media/video/videobuf2-dma-contig.c |  125 +++
 include/linux/videodev2.h  |8 ++
 include/media/videobuf2-core.h |   30 +
 5 files changed, 352 insertions(+), 1 deletions(-)

-- 
1.7.5.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: [PATCH] V4L: soc-camera: provide support for S_INPUT.

2012-01-05 Thread Guennadi Liakhovetski

On Wed, 4 Jan 2012, Guennadi Liakhovetski wrote:

> On Wed, 4 Jan 2012, Laurent Pinchart wrote:
> 
> > On Wednesday 04 January 2012 18:13:58 Guennadi Liakhovetski wrote:
> > > On Wed, 4 Jan 2012, Laurent Pinchart wrote:
> > > > On Wednesday 04 January 2012 17:35:27 Guennadi Liakhovetski wrote:
> > > > > On Wed, 4 Jan 2012, javier Martin wrote:
> > > > > 
> > > > > [snip]
> > > > > 
> > > > > > For ov7725 it is a natural thing to do since it was originally
> > > > > > developed for soc-camera and it can easily do the following to 
> > > > > > access
> > > > > > platform data:
> > > > > > 
> > > > > > struct soc_camera_link  *icl = soc_camera_i2c_to_link(client);
> > > > > > pdata = icl->priv;
> > > > > > 
> > > > > > However, tvp5150 is not aware about soc_camera. I should be able to
> > > > > > tell whether it's being used with soc-camera or not. If soc camera
> > > > > > was used I would do the previous method to retrieve platform data.
> > > > > > But if soc-camera was not used I would do the classic method:
> > > > > > 
> > > > > > struct tvp5150_platform_data *pdata = client->dev.platform_data;
> > > > > > 
> > > > > > The problem is how to distinguish in tvp5150 whether I am using
> > > > > > soc_camera or not.
> > > > > 
> > > > > Right, that _is_ the problem now. And we've known about it since the
> > > > > very first time we started to think about re-using the subdev drivers.
> > > > > The only solution I see so far is to introduce a standard platform
> > > > > data struct for all subdevices, similar to soc_camera_link. We could
> > > > > use it as a basis, of course, use a generic name, maybe reconsider
> > > > > fields - rename / remove / add, but the principle would be the same: a
> > > > > standard platform data struct with an optional private field.
> > > > 
> > > > Why is that needed ? Why can't a tvp5150-specific platform data 
> > > > structure
> > > > do ?
> > > 
> > > Javier has actually explained this already.
> > 
> > Sorry for not having followed.
> > 
> > > Ok, again: he wants to use tvp5150 with an soc-camera host driver, i.e.,
> > > with the soc-camera subsystem. And the soc-camera core sets board_info->
> > > platform_data itself to a pointer to the struct soc_camera_link instance.
> > 
> > That looks to me like it's the part to be changed...
> 
> Well, we could do this, but this would require changing a few soc-camera 
> subdev drivers and respective platforms and (slightly) the core itself.
> 
> The soc-camera core needs access to the struct soc_camera_link instance, 
> supplied by the platform. It is passed in .platform_data of the soc-camera 
> client platform device, there's no need to change that. struct 
> soc_camera_link::board_info points to struct i2c_board_info, this is also 
> ok. Basically, that's all the soc-camera core needs - access to these two 
> structs. Next, subdevice drivers also need access to struct 
> soc_camera_link and to their private data. If we let platforms pass 
> subdevice driver private data in i2c_board_info::platform_data, then each 
> driver will need to invent its own way how to also get to struct 
> soc_camera_link. They would either have to point at it from their private 
> data or embed it therein.
> 
> So, yes, it is doable. AFAICS currently these subdevice drivers
> 
> soc_camera_platform
> rj54n1cb0c
> tw9910
> mt9t112
> ov772x
> 
> and these platforms
> 
> sh/ecovec24
> sh/kfr2r09
> sh/migor
> sh/ap325rxa
> 
> arm/mackerel
> 
> are affected and have to be modified. After which the core can be fixed 
> too. I could do that, but not sure when I find the time. Javier, if you 
> like, feel free to give it a try.

Thinking a bit more about this, looks like the drivers don't have to be 
modified in fact. We just would have to make the reference from 
soc_camera_link::board_info to the specific struct i2c_board_info in 
platform data on the above platforms and remove it from soc_camera.c. This 
would look ugly in platform data, because structs i2c_board_info and 
soc_camera_link would then hold pointers to each other, but it would work.

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 1/1] omap3isp: Check media bus code on links