All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nishanth Menon <menon.nishanth@gmail.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [beagleboard] TI:OMAP: [PATCH 4/4] Minimal Display driver for OMAP3
Date: Sun, 10 Jan 2010 09:41:51 -0600	[thread overview]
Message-ID: <4B49F53F.2080305@gmail.com> (raw)
In-Reply-To: <a8ca84ad1001091916t3f447b92rbad74ac324fc19c2@mail.gmail.com>

Khasim Syed Mohammed said the following on 01/09/2010 09:16 PM:
> On Sat, Jan 9, 2010 at 8:18 PM, Nishanth Menon <menon.nishanth@gmail.com> wrote:
>> Khasim Syed Mohammed said the following on 01/08/2010 09:00 PM:
>>> On Sat, Jan 9, 2010 at 1:31 AM, Nishanth Menon <menon.nishanth@gmail.com>
>>> wrote:
>>>
>>>> On Fri, Jan 8, 2010 at 9:40 AM, Khasim Syed Mohammed
>>>> <khasim@beagleboard.org> wrote:
>>>>
>>>>> From 239c47a4180fb4d5b5217f892955524d476916cf Mon Sep 17 00:00:00 2001
>>>>> From: Syed Mohammed Khasim <khasim@ti.com>
[...]

>> The recomendation here is to move from #defines to struct based register
>> usage. I am ok with the rest(except for need to split).
> Split is done, posted yesterday.
> 
> Struct based register needs more comments, not that I am lazy to
> implement that. I need to know the reason for doing the same when no
> multiple instances are used.
> 
>>> You can add a new panel or a new tv standard with these structures
>>> easily. Structures are not used for register accesses.
>>>
>>>
>>>> here is what I think:
>>>> venc_config {
>>>> }
>>>>
>>>> if it is organized as the register definitions,
>>>>
>>>> configure_venc(struct venc_config *values)
>>>> struct venc_config * d = BASE_ADDRESS_OF_OMAP3_VENC;
>>>> writel(values->regx, &d->regx);
>>>>
>>>> refer: drivers/mtd/nand/omap_gpmc.c
>>>>
>>>>
>>> GPIO, GPMC and other controllers have multiple instances in OMAP, it
>>> makes sense to organize such register set in structure mode. I did
>>> start with that but found no use for DSS as it is just one instance.
>>> Structures don't give any value here.
>>>
>> there were other reasons mentioned when nand got split -> one of them had to
>> do with the compiler or something. Dirk might remember - unfortunately, this
>> was more than a year back.. if I recollect right..
> Will try doing a google. May be some one can point me to that
> decision. It would help developing drivers which have single instance
> of controller being used.
the reference I got:
http://old.nabble.com/-U-Boot---PATCH-08-13-v4--ARM%3A-OMAP3%3A-Add-NAND-support-tp20039673p20039673.html

V5 became:
http://old.nabble.com/-U-Boot---PATCH-07-13-v5--ARM%3A-OMAP3%3A-Add-NAND-support-tp20292477p20292477.html

similar changes happend for GPMC etc..

Quote:
 > >Is GPMC_BASE an integer or a pointer?
 >
 > Nothing. A macro:
 >
 > #define OMAP34XX_GPMC_BASE                (0x6E000000)
 > #define GPMC_BASE (OMAP34XX_GPMC_BASE)

So it's an integer.

 > It's then casted to volatile pointer by ARM's readx/writex.

The cast should be done by the driver, or you'll get warnings if
readx/writex ever become inline functions (as they are on other arches).

might help explain..

> 
>>> More over I am introducing minimal DSS driver with minimal register
>>> set. It doesn't help any to give structure based register access for
>>> single instance drivers.
>>>
>> moving to struct based is easy and done once and improves your chance of
>> your driver getting upstreamed :).
> DSS in OMAP3 has following register domains.
> 
> DSI Protocol Engine           0x4804 FC00            512 bytes
> DSI_PHY                           0x4804 FE00             64 bytes
> DSI PLL Controller              0x4804 FF00             32 bytes
> Display Subsystem            0x4805 0000            512 bytes
> Display Controller               0x4805 0400             1K byte
> Display Controller VID1       0x4805 0400             1K byte
> Display Controller VID2       0x4805 0400             1K byte
> RFBI                                 0x4805 0800            256 bytes
> Video Encode                    0x4805 0C00           256 bytes
> 
> I am not sure why one would ask me to give struct definitions for
> these 500 (approx) registers when only 50 of these are required to
> implement background and color bar. As I am saying all the way, DSS is
> not multiple instance module like GPMC (NAND) and GPIO it is just one
> module.

Aren't you extrapolating this a bit out of scope? DSI,RFBI etc.. is not relevant to your patch.
you may need DSS, controller and VID1(and VID2 is the same). I think your complaint is about having
  to define the reg structs when multiple instances dont exist - how about OMAP4? wont these structs
get reused there(once we get around to it)?


Regards,
Nishanth Menon

  reply	other threads:[~2010-01-10 15:41 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-08 15:40 [U-Boot] TI:OMAP: [PATCH 4/4] Minimal Display driver for OMAP3 Khasim Syed Mohammed
2010-01-08 20:01 ` [U-Boot] [beagleboard] " Nishanth Menon
2010-01-09  3:00   ` Khasim Syed Mohammed
2010-01-09 14:48     ` Nishanth Menon
2010-01-10  3:16       ` Khasim Syed Mohammed
2010-01-10 15:41         ` Nishanth Menon [this message]
2010-01-10 17:46           ` Khasim Syed Mohammed
2010-01-11 13:09             ` Grazvydas Ignotas
2010-01-11 13:48               ` Khasim Syed Mohammed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4B49F53F.2080305@gmail.com \
    --to=menon.nishanth@gmail.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.