> Thanks for you reply.
>
> The SOC is still under development stage, it's not a product yet. And
> a small mistake I've made, the tuner will not integrated into the SOC.
> The demod might be.
>
> Some more questions:
> As far as I know, relationship between demod and decoder is the buffer
> used as demod output(also the input for a/v decoder), and maybe a
> shared interrupt used to catch some misc event from tuner/demo/av
> decoder(a interrupt status register will be used to determine who
> cause it). Do you think this will be a problem if I write individual
> drivers?
I would probably start by writing it as one driver, and check later how
much work it is to split it up. Writing it as one driver will certainly
work, splitting it up may or may not be a problem.
> And would you please tell me that is the "memory-to-memory decoding" for?
That's when you give the hardware a JPEG image (for example) and you get
the decoded raw image back from the hardware. As opposed to sending a JPEG
image to the hardware which is then sent on to e.g. HDMI out.
Regards,
Hans
>
> Best regards
> Michael Qiu
>
> 2010/1/14 Hans Verkuil <hverkuil@xxxxxxxxx>:
>> Hi Michael,
>>
>>> Hi guys,
>>> I'm going to write drivers for a new soc which designed for dvb-s set
>>> top box.
>>> It will support these features:
>>> 1. Multi-layer display with alpha blending feature, including
>>> video(YUV), OSDs(2 same RGB layers), background(with fixed YUV color)
>>> and still picture(YUV color for still image)
>>> 2. DVB-S tuner and demod
>>> 3. HW MPEG2/4 decoder
>>> 4. HW accelerated JPEG decoder engine.
>>
>> Interesting device. Which SoC is this?
>>
>>>
>>> My targets are:
>>> 1. Fit all the drivers in proper framework so they can be easily used
>>> by applications in open source community.
>>> 2. As flexible as I can to add new software features in the future.
>>>
>>> My questions are:
>>> How many drivers should I implement, and how should I divide all the
>>> features?
>>> As far as I know:
>>> A) a frame buffer driver for 2 OSDs, maybe also the control point for
>>> whole display module?
>>> B) video output device for video layer, which will output video
>>> program.
>>> C) drivers for tuner and demo (or just a driver which will export 2
>>> devices files for each?)
>>> D) driver for jpeg accelerate interface, or should it be a part of
>>> MPEG2/4 decoder driver?
>>> E) driver for MPEG2/4 decoder which will control the behave of H/W
>>> decoder.
>>>
>>> Actually I think all the display functions are relative, some
>>> functions i listed upper are operating one HW module, for instance:
>>> OSD and video layer are implemented by display module in H/W level.
>>> What's the right way to implement these functions in driver level,
>>> united or separated?
>>> And, I've read some documents for V4L2, but I still cannot figure out
>>> where should I implement my driver in the framework.
>>>
>>> In a word, I'm totally confused. Can you guys show me the right way or
>>> just kick me to a existing example with similar features?
>>
>> The driver that comes closest to this in terms of functionality is the
>> ivtv driver. That driver supports MPEG2 encoding and decoding, an OSD
>> and
>> raw YUV input and output.
>>
>> There are several ways you can design devices like this, but the way
>> ivtv
>> is designed is that there is one master driver (ivtv) that handles all
>> the
>> encoding and decoding, and the framebuffer driver that you need for the
>> OSD is just an 'add-on' module that provides the FB API but internally
>> talks to the master driver.
>>
>> The tuner/demod part is usually integrated in the master driver. See the
>> cx18 driver for example. But it is probably also possible to implement
>> it
>> as a separate driver in a similar manner as a framebuffer driver.
>>
>> Generally the key criteria on how to design drivers like this is the
>> hardware design: for example, if the tuner/demod part is completely
>> independent from the decoder part, then it is possible to write
>> completely
>> independent drivers as well, but if they share hardware components (e.g.
>> the interrupt handling hardware), then you usually have to combine
>> functions in one driver.
>>
>> Note that some features that you probably need (such as memory-to-memory
>> decoding) are not yet implemented in V4L2 (although work is in progress
>> on
>> this).
>>
>> Regards,
>>
>> Hans
>>
>>>
>>>
>>> Best regards
>>> Michael Qiu
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-media"
>>> in
>>> the body of a message to majordomo@xxxxxxxxxxxxxxx
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>
>>
>>
>> --
>> Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom
>>
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
