Send Davinci-linux-open-source mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-
source
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Davinci-linux-open-source digest..."
Today's Topics:
1. Re: omap-L1xxx (Kevin Hilman)
2. RE: omap-L1xxx (He, Zhengting)
3. RE: omap-L1xxx (He, Zhengting)
4. Re: DM6446 MUSB (Sergei Shtylyov)
5. Re: DM6446 MUSB (David Chan)
----------------------------------------------------------------------
Message: 1
Date: Thu, 22 Jan 2009 14:04:55 -0800
From: Kevin Hilman <[email protected]>
Subject: Re: omap-L1xxx
To: "He, Zhengting" <[email protected]>
Cc: "[email protected]"
<[email protected]>, "Wells, Kimberly"
<[email protected]>, "McGoldrick, Bobby" <[email protected]>, "Venkat,
Subbu"
<[email protected]>, "Friedland, David" <[email protected]>
Message-ID: <[email protected]>
Content-Type: text/plain; charset=shift_jis
"He, Zhengting" <[email protected]> writes:
Hi, All,
After some discussion internally in TI, I think we (as TI
catalog) would like to change the proposal a little bit.
1. The macros and source code will have da830 only. (no change)
2. The menuconfig prompts will have "DA830/OMAP-L137" in them. (no
change)
3. The defconfig would be called da830_omapl137_defconfig (no
change).
So far, so good.
4. The file and directory names should also have omapl137. (CHANGE)
I have listed the following directory and file names which are
required to be changed. (There are not many). With the
file/directory name change, OMAPL137 users can tell which code is
specifically applicable to OMAPL137 at a first glance. Does everyone
agree this change?
Personally, I think this is a bit cumbersome. I'm perfectly fine with
the user-visible names and strings having both, but enforcing this
type of naming into the kernel structure itself is overkill IMHO.
Do you expect most users to be digging into the kernel at that level?
If so, I would rather see this addressed in Documentation that comes
with the product rather than having filenames carry the burden.
My $0.02.
Kevin
/
**************************************************************************/
/* Directory names to be
changed */
/
**************************************************************************/
include/config/mach/da8xx
include/config/snd/da8xx
arch/arm/mach-da8xx
drivers/char/da8xx_lcd
drivers/video/da8xx
/
**************************************************************************/
/* File names to be
changed */
/
**************************************************************************/
arch/arm/mach-da8xx/da8xx.h
include/config/rtc/drv/da8xx.h
drivers/usb/musb/da8xx.c
drivers/video/da8xx/da8xx_fb.c
drivers/video/da8xx/da8xx_fb.h
drivers/video/da8xx/da8xx_lcdc.h
Zhengting He (Ph.D)
Application Engineer
DSP Catalog
email: [email protected]
voice: 281-274-4355
fax: 281-274-2279
-----Original Message-----
From: [email protected] [mailto:[email protected]
] On Behalf Of Mark A. Greer
Sent: 2009N122ú 11:54
To: Longley, Lester
Cc: [email protected]; Wells,
Kimberly; McGoldrick, Bobby
Subject: Re: omap-L1xxx
On Thu, Jan 22, 2009 at 09:53:43AM -0600, Longley, Lester wrote:
Hi Mark,
From: Mark A. Greer [mailto:[email protected]]
On Wed, Jan 21, 2009 at 11:35:07AM -0800, Kevin Hilman wrote:
"Longley, Lester" <[email protected]> writes:
[ ... ]
From: Sergei Shtylyov [mailto:[email protected]]
[ ... ]
So, how should we reference to OMAP-L1x in kernel (in order
to avoid the
confusion with real OMAP)?
It's the strong preference from my group, Performance Media, that
"da830" be *included* in the name.
Lester, thanks for sharing the views of your group.
Do you mean included along with the omapl1x name? Or would your
team
be OK with only the da830 naming (which would be my preference)?
For in-kernel code, I think it would be *really* clumsy to have
both.
In other words, I would much rather have
#define DA830_MY_VAR
void da830_my_func(void);
OR
#define OMAPL1X_MY_VAR
void omapl1x_my_func(void);
instead of:
#define DA830_OMAPL1X_MY_VAR
void da830_omapl1x_my_func(void);
Which I think would be more confusing than informative.
Maybe one could consider that a side benefit of such naming is
easier distinction versus "real OMAP" (or maybe "original OMAP").
Yes, I think that using the d830 naming only would avoid this
confusion.
Moreover, many users of the chip will utilize the DSP-side audio
code available for DA830, and so helping them readily identify
the
appropriate kernel is important to them & to us. This need can
hopefully be addressed by inclusion of "da830_" prefix in the
kernel
name.
Will these users have much visibility into the in-kernel
naming? Or
are you primarily concerned with the naming of how the kernel as
it is
packaged and visible to non kernel-developers.
To try to get closure, here is a proposal:
File names/macros/config options will have da830 only but the
menuconfig
prompts will have "DA830/OMAP-L137" in them. The defconfig would
be
called da8xx_omapl137_defconfig.
Everyone agree?
Did you mean "da830_omapl137_defconfig", rather than
"da8xx_omapl137_defconfig"?
Oops, yes, that's what I meant. Sorry...
Mark
--
_______________________________________________
Davinci-linux-open-source mailing list
[email protected]
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-
source
_______________________________________________
Davinci-linux-open-source mailing list
[email protected]
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-
source
------------------------------
Message: 2
Date: Thu, 22 Jan 2009 16:17:22 -0600
From: "He, Zhengting" <[email protected]>
Subject: RE: omap-L1xxx
To: Kevin Hilman <[email protected]>
Cc: "[email protected]"
<[email protected]>, "Wells, Kimberly"
<[email protected]>, "McGoldrick, Bobby" <[email protected]>, "Venkat,
Subbu"
<[email protected]>, "Friedland, David" <[email protected]>
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="iso-2022-jp"
Kevin,
Thanks a lot for your quick response.
I think serious customers will need to go into that level and
modify the drivers for their customized boards, special requirement
etc. Without the directory/file name changes being made, it is easy
for them to find out where the things are that they need to change.
It also brings them little confusion.
Addressing it in documentation is also a solution but personally
I don't feel that's a solution enough. Given the fact that there are
already so many documentations floating around for a complicated
device, a user may stay away from the documentation and step into
the source directly.
Zhengting He (Ph.D)
Application Engineer
DSP Catalog
email: [email protected]
voice: 281-274-4355
fax: 281-274-2279
-----Original Message-----
From: Kevin Hilman [mailto:[email protected]]
Sent: 2009$BG/(B1$B7n(B22$BF|(B 16:05
To: He, Zhengting
Cc: Mark A. Greer; Longley, Lester; Wells, Kimberly; McGoldrick,
Bobby; Venkat, Subbu; Friedland, David; Nori, Sekhar; [email protected]
Subject: Re: omap-L1xxx
"He, Zhengting" <[email protected]> writes:
Hi, All,
After some discussion internally in TI, I think we (as TI
catalog) would like to change the proposal a little bit.
1. The macros and source code will have da830 only. (no change)
2. The menuconfig prompts will have "DA830/OMAP-L137" in them. (no
change)
3. The defconfig would be called da830_omapl137_defconfig (no
change).
So far, so good.
4. The file and directory names should also have omapl137. (CHANGE)
I have listed the following directory and file names which are
required to be changed. (There are not many). With the
file/directory name change, OMAPL137 users can tell which code is
specifically applicable to OMAPL137 at a first glance. Does everyone
agree this change?
Personally, I think this is a bit cumbersome. I'm perfectly fine with
the user-visible names and strings having both, but enforcing this
type of naming into the kernel structure itself is overkill IMHO.
Do you expect most users to be digging into the kernel at that level?
If so, I would rather see this addressed in Documentation that comes
with the product rather than having filenames carry the burden.
My $0.02.
Kevin
/
**************************************************************************/
/* Directory names to be
changed */
/
**************************************************************************/
include/config/mach/da8xx
include/config/snd/da8xx
arch/arm/mach-da8xx
drivers/char/da8xx_lcd
drivers/video/da8xx
/
**************************************************************************/
/* File names to be
changed */
/
**************************************************************************/
arch/arm/mach-da8xx/da8xx.h
include/config/rtc/drv/da8xx.h
drivers/usb/musb/da8xx.c
drivers/video/da8xx/da8xx_fb.c
drivers/video/da8xx/da8xx_fb.h
drivers/video/da8xx/da8xx_lcdc.h
Zhengting He (Ph.D)
Application Engineer
DSP Catalog
email: [email protected]
voice: 281-274-4355
fax: 281-274-2279
------------------------------
Message: 3
Date: Thu, 22 Jan 2009 16:20:05 -0600
From: "He, Zhengting" <[email protected]>
Subject: RE: omap-L1xxx
To: "He, Zhengting" <[email protected]>, Kevin Hilman
<[email protected]>
Cc: "[email protected]"
<[email protected]>, "Wells, Kimberly"
<[email protected]>, "McGoldrick, Bobby" <[email protected]>, "Venkat,
Subbu"
<[email protected]>, "Friedland, David" <[email protected]>
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="iso-2022-jp"
Sorry, a typo. It should be "With the directory/file name changes
being made ..."
Zhengting He (Ph.D)
Application Engineer
DSP Catalog
email: [email protected]
voice: 281-274-4355
fax: 281-274-2279
-----Original Message-----
From: [email protected] [mailto:[email protected]
] On Behalf Of He, Zhengting
Sent: 2009$BG/(B1$B7n(B22$BF|(B 16:17
To: Kevin Hilman
Cc: [email protected]; Wells, Kimberly;
McGoldrick, Bobby; Venkat, Subbu; Friedland, David
Subject: RE: omap-L1xxx
Kevin,
Thanks a lot for your quick response.
I think serious customers will need to go into that level and
modify the drivers for their customized boards, special requirement
etc. WITH the directory/file name changes being made, it is easy for
them to find out where the things are that they need to change. It
also brings them little confusion.
Addressing it in documentation is also a solution but personally
I don't feel that's a solution enough. Given the fact that there are
already so many documentations floating around for a complicated
device, a user may stay away from the documentation and step into
the source directly.
Zhengting He (Ph.D)
Application Engineer
DSP Catalog
email: [email protected]
voice: 281-274-4355
fax: 281-274-2279
-----Original Message-----
From: Kevin Hilman [mailto:[email protected]]
Sent: 2009$BG/(B1$B7n(B22$BF|(B 16:05
To: He, Zhengting
Cc: Mark A. Greer; Longley, Lester; Wells, Kimberly; McGoldrick,
Bobby; Venkat, Subbu; Friedland, David; Nori, Sekhar; [email protected]
Subject: Re: omap-L1xxx
"He, Zhengting" <[email protected]> writes:
Hi, All,
After some discussion internally in TI, I think we (as TI
catalog) would like to change the proposal a little bit.
1. The macros and source code will have da830 only. (no change)
2. The menuconfig prompts will have "DA830/OMAP-L137" in them. (no
change)
3. The defconfig would be called da830_omapl137_defconfig (no
change).
So far, so good.
4. The file and directory names should also have omapl137. (CHANGE)
I have listed the following directory and file names which are
required to be changed. (There are not many). With the
file/directory name change, OMAPL137 users can tell which code is
specifically applicable to OMAPL137 at a first glance. Does everyone
agree this change?
Personally, I think this is a bit cumbersome. I'm perfectly fine with
the user-visible names and strings having both, but enforcing this
type of naming into the kernel structure itself is overkill IMHO.
Do you expect most users to be digging into the kernel at that level?
If so, I would rather see this addressed in Documentation that comes
with the product rather than having filenames carry the burden.
My $0.02.
Kevin
/
**************************************************************************/
/* Directory names to be
changed */
/
**************************************************************************/
include/config/mach/da8xx
include/config/snd/da8xx
arch/arm/mach-da8xx
drivers/char/da8xx_lcd
drivers/video/da8xx
/
**************************************************************************/
/* File names to be
changed */
/
**************************************************************************/
arch/arm/mach-da8xx/da8xx.h
include/config/rtc/drv/da8xx.h
drivers/usb/musb/da8xx.c
drivers/video/da8xx/da8xx_fb.c
drivers/video/da8xx/da8xx_fb.h
drivers/video/da8xx/da8xx_lcdc.h
Zhengting He (Ph.D)
Application Engineer
DSP Catalog
email: [email protected]
voice: 281-274-4355
fax: 281-274-2279
_______________________________________________
Davinci-linux-open-source mailing list
[email protected]
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
------------------------------
Message: 4
Date: Fri, 23 Jan 2009 01:23:12 +0300
From: Sergei Shtylyov <[email protected]>
Subject: Re: DM6446 MUSB
To: Brian Rhodes <[email protected]>
Cc: "[email protected]"
<[email protected]>
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Hello.
Brian Rhodes wrote:
Is PIO ONLY the only working USB mode in the current GIT kernel? By
working, I mean without periodic reset. PIO is suitable for my
application, but I just merged the latest GIT code into our kernel
tree and without CONFIG_MUSB_PIO_ONLY=y USB does not work very well,
so I was curious if I had possibly overlooked something. Does the
CPPI DMA mode work well on DM6446 in the current GIT code?
I don't think so. In particular, sending data via DMA should cause
issues (perhaps indeed ending in reset).
Thanks.
WBR, Sergei
------------------------------
Message: 5
Date: Fri, 23 Jan 2009 08:58:37 +0800
From: David Chan <[email protected]>
Subject: Re: DM6446 MUSB
To: [email protected]
Cc: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Hi, Brian
The DMA is supported by current git for dm6446 usb.
I've used for quite a long period.
David
On Jan 23, 2009, at 4:34 AM,
[email protected]
wrote:
DM6446 MUSB
------------------------------
_______________________________________________
Davinci-linux-open-source mailing list
[email protected]
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
End of Davinci-linux-open-source Digest, Vol 37, Issue 103
**********************************************************
