RE: [PATCH v3 09/12] s3c-fb: Correct window osd size and alpha register handling

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



>Ben Dooks <ben@xxxxxxxxxxxx> wrote:
>On 28/06/10 09:08, Pawel Osciak wrote:
>> S3C64xx and S5P OSD registers for OSD size and alpha are as follows:
>> VIDOSDC: win 0 - size, win 1-4: alpha
>> VIDOSDD: win 1-2 - size; not present for windows 0, 3 and 4
>>
>> Signed-off-by: Pawel Osciak <p.osciak@xxxxxxxxxxx>
>> Signed-off-by: Kyungmin Park <kyungmin.park@xxxxxxxxxxx>
>> ---
>>  drivers/video/s3c-fb.c |   58 ++++++++++++++++++++++++++++++++++++++++++--
>---
>>  1 files changed, 51 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/video/s3c-fb.c b/drivers/video/s3c-fb.c
>> index 94423c5..3b2c7fe 100644
>> --- a/drivers/video/s3c-fb.c
>> +++ b/drivers/video/s3c-fb.c
>> @@ -64,6 +64,9 @@ struct s3c_fb;
>>  #define VIDOSD_B(win, variant) (OSD_BASE(win, variant) + 0x04)
>>  #define VIDOSD_C(win, variant) (OSD_BASE(win, variant) + 0x08)
>>  #define VIDOSD_D(win, variant) (OSD_BASE(win, variant) + 0x0C)
>> +#define VIDOSD_SIZE(win, variant, win_variant) \
>> +	(OSD_BASE(win, variant) + (win_variant).osd_size_off)
>> +#define VIDOSD_ALPHA(win, variant, win_variant) VIDOSD_C(win, variant)
>
>hmm, this is becoming a bit complicated. if we have a function to
>set it then maybe we should just calculate it there.
>

>> @@ -1445,12 +1478,17 @@ static int s3c_fb_resume(struct platform_device
>*pdev)
>>  static struct s3c_fb_win_variant s3c_fb_data_64xx_wins[] __devinitdata = {
>>  	[0] = {
>>  		.has_osd_c	= 1,
>> +		.has_osd_size	= 1,
>> +		.osd_size_off	= 0x8,
>>  		.palette_sz	= 256,
>>  		.valid_bpp	= VALID_BPP1248 | VALID_BPP(16) | VALID_BPP(24),
>>  	},
>>  	[1] = {
>>  		.has_osd_c	= 1,
>>  		.has_osd_d	= 1,
>> +		.has_osd_size	= 1,
>> +		.osd_size_off	= 0x12,
>> +		.has_osd_alpha	= 1,
>
>how about osd_size_off !=0 => has_osd_size ?
>

Could be done that way, yes... I'm not aware of any SoC with osd_size_off == 0
till now.

>do we need to change the osd c and d definitions?

I'd prefer not using "OSD_C" and "OSD_D" names at all. How they are changing
their usage across hw versions and windows is confusing enough. Maybe we should
only be using osd_sizeand osd_alpha instead? Would you agree?


Best regards
--
Pawel Osciak
Linux Platform Group
Samsung Poland R&D Center





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


[Index of Archives]     [Video for Linux]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Tourism]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux