Adaptec VideOh! DVD Media Center

Adaptec VideOh! DVD Media Center

[Paulo Assis]

Hi,
I'm currently porting the GPL linux-avc2210k driver (
http://www.freelists.org/archive/linux-avc2210k/ ) to V4L2.
The current version has it's own API that makes it incompatible with
any software except for specific user space apps (avcctrl, avctune)
bundled with the driver.
Since development seems to have halted for some time now, I had no
other choice than get my hands dirty :(
For the most part this task seems quite straight forward it's mostly a
matter of changing ioctls to V4L2 and add some missing support, there
are however a few points that I need some advice on:
For the box to function it needs a firmware upload. Currently this is
managed by a udev script that in turn calls an application (multiload)
that provides for the upload.
What I would like to know is, if this the best way to handle it?
The problem with this process is that it will always require
installing and configuring additional software (multiload and udev
script), besides the firmware.
Is there any simpler/standard way of handling these firmware uploads ?

Regards,
Paulo

Re: Adaptec VideOh! DVD Media Center

[Simon Farnsworth]

Paulo Assis wrote:
> For the box to function it needs a firmware upload. Currently this is
> managed by a udev script that in turn calls an application (multiload)
> that provides for the upload.
> What I would like to know is, if this the best way to handle it?
> The problem with this process is that it will always require
> installing and configuring additional software (multiload and udev
> script), besides the firmware.
> Is there any simpler/standard way of handling these firmware uploads ?
> 
Look at Documentation/firmware_class/README. There's a mechanism called
request_firmware() that does what you want; it's used in several V4L
drivers if you need an example usage.
-- 
Simon Farnsworth

Re: Adaptec VideOh! DVD Media Center

[Devin Heitmueller]

On Fri, Dec 18, 2009 at 9:05 AM, Paulo Assis <pj.assis@gmail.com> wrote:
> Hi,
> I'm currently porting the GPL linux-avc2210k driver (
> http://www.freelists.org/archive/linux-avc2210k/ ) to V4L2.
> The current version has it's own API that makes it incompatible with
> any software except for specific user space apps (avcctrl, avctune)
> bundled with the driver.
> Since development seems to have halted for some time now, I had no
> other choice than get my hands dirty :(
> For the most part this task seems quite straight forward it's mostly a
> matter of changing ioctls to V4L2 and add some missing support, there
> are however a few points that I need some advice on:
> For the box to function it needs a firmware upload. Currently this is
> managed by a udev script that in turn calls an application (multiload)
> that provides for the upload.
> What I would like to know is, if this the best way to handle it?
> The problem with this process is that it will always require
> installing and configuring additional software (multiload and udev
> script), besides the firmware.
> Is there any simpler/standard way of handling these firmware uploads ?
>
> Regards,
> Paulo

Hi Paulo,

I would start by looking at the request_firmware() function, which is
used by a variety of other v4l cards.

Cheers,

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com

Re: Adaptec VideOh! DVD Media Center

[Mauro Carvalho Chehab]

Devin Heitmueller wrote:
> On Fri, Dec 18, 2009 at 9:05 AM, Paulo Assis <pj.assis@gmail.com> wrote:
>> Hi,

>> Is there any simpler/standard way of handling these firmware uploads ?
>>
>> Regards,
>> Paulo
> 
> Hi Paulo,
> 
> I would start by looking at the request_firmware() function, which is
> used by a variety of other v4l cards.

Yes. Basically, you store all firmwares you need on /lib/firmware and 
request_firmware loads them when the driver is loaded. 

You don't need to add any extra udev magic for it to work, since there are
already some userspace programs that handle firmware requests when using
request_firmware().

Cheers,
Mauro.

Re: Adaptec VideOh! DVD Media Center

[Paulo Assis]

Hi,
I'm having a real bad time with this, I've just noticed the strangest thing:
The product id on the box changes when loading the firmware:
from the initial vid:pid of 03f3:008b to 03f3:008c I guess the same
also happens for 03f3:0087 to 03f3:0088
This is way the original firmware loader uses the inital pid in the
configuration and the driver module sets the later in the device tab:
udev loads the firmware, the pid changes and the driver module gets
loaded.
So if If I want the driver to request the firmware I have to set both
pids and end up with two device entries, the first of which will never
get removed since the inital pid is no more :D

Is there any solution/ideas on how to handle this behaviour?
Also I exctrated the firmware into a ihex file, I see that existing
modules use several diferent types of firmware binary files (fw, bin)
obtained from the ihex file, some even use ihex directly
(request_ihex_firmware), is there a optimal format for this?

Regards,
Paulo

2009/12/18 Mauro Carvalho Chehab <maurochehab@gmail.com>:
> Devin Heitmueller wrote:
>> On Fri, Dec 18, 2009 at 9:05 AM, Paulo Assis <pj.assis@gmail.com> wrote:
>>> Hi,
>
>>> Is there any simpler/standard way of handling these firmware uploads ?
>>>
>>> Regards,
>>> Paulo
>>
>> Hi Paulo,
>>
>> I would start by looking at the request_firmware() function, which is
>> used by a variety of other v4l cards.
>
> Yes. Basically, you store all firmwares you need on /lib/firmware and
> request_firmware loads them when the driver is loaded.
>
> You don't need to add any extra udev magic for it to work, since there are
> already some userspace programs that handle firmware requests when using
> request_firmware().
>
> Cheers,
> Mauro.
>