Re: [PATCH v3 2/2] media: platform: Add Aspeed Video Engine driver

[Eddie James <eajames@linux.vnet.ibm.com>]

On 10/04/2018 08:12 AM, Hans Verkuil wrote:
> On 10/03/18 22:43, Eddie James wrote:
>>
>> On 09/28/2018 06:30 AM, Hans Verkuil wrote:
>>> On 09/25/2018 09:27 PM, Eddie James wrote:
>>>> The Video Engine (VE) embedded in the Aspeed AST2400 and AST2500 SOCs
>>>> can capture and compress video data from digital or analog sources. With
>>>> the Aspeed chip acting a service processor, the Video Engine can capture
>>>> the host processor graphics output.
>>>>
>>>> Add a V4L2 driver to capture video data and compress it to JPEG images.
>>>> Make the video frames available through the V4L2 streaming interface.
>>>>
>>>> Signed-off-by: Eddie James <eajames@linux.ibm.com>
>>>> +	}
>>>> +
>>>> +	video->height = (bottom - top) + 1;
>>>> +	video->width = (right - left) + 1;
>>>> +	size = video->height * video->width;
>>> It looks like you can actually determine the blanking width/height and
>>> possibly even more detailed information that would be very useful to
>>> show with the DV_TIMINGS ioctls.
>> Hmm. This information is related to the video signal captured from the
>> host. That information has nothing to do with the buffer that is
>> compressed and grabbed by the driver and ultimately provided to
>> userspace. Isn't the timing information meaningless for JPEG frames?
> It helps in debugging. Basically you are implementing a receiver for a
> video signal. So if for some reason you cannot support the video timings
> that the host sends, then it is very useful to have QUERY_DV_TIMINGS report
> as much information about the signal as possible.
>
> BTW, out of curiosity, how are the host video signals connected to the
> aspeed? Is it still a VGA video signal?
>
> Looking at product briefs it appears that it is VGA. So I guess the aspeed
> 'sniffs' the VGA signals from the host and can capture the video that way.
> Is that correct?

I believe it is a VGA signal from the host, but the Aspeed Video Engine 
somewhat abstracts that away; not all the signal information that the 
engine is receiving is available to the BMC interface. I did add the 
timing information I could access to the latest patch set. As you say, 
it could be useful for debugging if weird things are happening.

Thanks!
Eddie

>
> If so, then this driver is a VGA receiver and should act like that.
> The host can configure its VGA transmitter to invalid timings, or weird
> values, and you need to be able to handle that in your driver.
>
>> Forgot to include this question in my previous reply, sorry for the
>> additional mail.
> No problem! Happy to help.
>
> Regards,
>
> 	Hans
>