[RFC]: s3c2410fb conversion

[RFC]: s3c2410fb conversion

[Krzysztof Helt]

Hello,

The s3c2410fb driver needs register values set for every
platform. A way of conversion is to move as many values to
particular fields (e.g. resolution, bit depth, etc.) and
calculate the register values from them.

I want to ask how far one should move in conversion of the
driver. Should enumerated values also be moved to separate fields
or they can be set with "or" operator (I) into existing register
fields? I mean values (usually bits) like display type (STN/TFT
bit), etc.

E.g., the pxafb driver works with the latter approach. Most of
values are calculated but some of them are set as or-ed values
into register-like fields (the bits from fields are directly
copied to register's bits and completed by bits from calculated
values).

The s3c2410fb driver does not work currently because some
conversion started and was not finished (no platform code support
it). I need to know how to fix it - either modify platform or fb
code depending on the approach.

Regards,
Krzysztof

----------------------------------------------------
Odkryj drug± stronê ciemnego portalu - "World of War Craft" premiera:
http://klik.wp.pl/?adr=http%3A%2F%2Fadv.reklama.wp.pl%2Fas%2Fd59.html&sid=1000



-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: [RFC]: s3c2410fb conversion

[Ben Dooks]

On Fri, Jan 26, 2007 at 09:06:44AM +0100, Krzysztof Helt wrote:
> Hello,
> 
> The s3c2410fb driver needs register values set for every
> platform. A way of conversion is to move as many values to
> particular fields (e.g. resolution, bit depth, etc.) and
> calculate the register values from them.

I definetly think we should be passing a number of items as
more generic info, such as the pixel clock range, and anything
that can be set from a mode info structure.

This should possibly be the first stage of development, and then
we can see what else can be done.

> I want to ask how far one should move in conversion of the
> driver. Should enumerated values also be moved to separate fields
> or they can be set with "or" operator (I) into existing register
> fields? I mean values (usually bits) like display type (STN/TFT
> bit), etc.
> 
> E.g., the pxafb driver works with the latter approach. Most of
> values are calculated but some of them are set as or-ed values
> into register-like fields (the bits from fields are directly
> copied to register's bits and completed by bits from calculated
> values).

It might be easier to pass lcdcon1 through, and calculate the
rest from a mode info structure.

-- 
Ben (ben@fluff.org, http://www.fluff.org/)

  'a smiley only costs 4 bytes'

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642