I can think of 2 ways to handle different interrupt handler in
entry-macro.S
1. cp_intc has an ID register. We can read it and handle interrupts
accordingly.
2. Use a variable (similar to how Lennert used phys_offset in the
run-time phys_offset patch) to determine which code to execute. Of
On Thu, Feb 05, 2009 at 06:34:06AM -0600, Steve Chen wrote:
On Wed, 2009-02-04 at 20:57 -0700, Mark A. Greer wrote:
On Fri, Jan 23, 2009 at 11:45:42PM +0300, Sergei Shtylyov wrote:
Mark A. Greer wrote:
With the static data being turning into dynamic, what's the win of
converting
Mark A. Greer mgr...@mvista.com writes:
On Thu, Feb 05, 2009 at 06:34:06AM -0600, Steve Chen wrote:
On Wed, 2009-02-04 at 20:57 -0700, Mark A. Greer wrote:
On Fri, Jan 23, 2009 at 11:45:42PM +0300, Sergei Shtylyov wrote:
Mark A. Greer wrote:
With the static data being turning into
Mark A. Greer mgr...@mvista.com writes:
On Thu, Feb 05, 2009 at 06:34:06AM -0600, Steve Chen wrote:
On Wed, 2009-02-04 at 20:57 -0700, Mark A. Greer wrote:
On Fri, Jan 23, 2009 at 11:45:42PM +0300, Sergei Shtylyov wrote:
Mark A. Greer wrote:
With the static data being turning into
On Fri, Jan 23, 2009 at 11:45:42PM +0300, Sergei Shtylyov wrote:
Mark A. Greer wrote:
With the static data being turning into dynamic, what's the win of
converting to __initdata?
The thing that really worries me about cp_intc is entry-macro.S.
Me too unless we do some GOT
Hello.
Kevin Hilman wrote:
MUSB driver will need the different DMA driver and different glue
layer but that's outside the scope of arch/arm/ (DMA driver needs to
be backed by CPPI 4.1 support though). There's also .
There are some additional devices like OHCI, RTC (seems tobe
OMAP-alike
On Thu, Jan 22, 2009 at 10:20:08AM -0800, Kevin Hilman wrote:
Mark A. Greer mgr...@mvista.com writes:
On Tue, Jan 20, 2009 at 05:26:38PM -0800, Kevin Hilman wrote:
Mark A. Greer mgr...@mvista.com writes:
On Tuesday 20 January 2009, David Brownell wrote:
snip
I think we're in
-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: 2009年1月22日 16:05
To: He, Zhengting
Cc: Mark A. Greer; Longley, Lester; Wells, Kimberly; McGoldrick, Bobby;
Venkat, Subbu; Friedland, David; Nori, Sekhar;
davinci-linux-open-source@linux.davincidsp.com
Subject: Re: omap-L1xxx
He
Hello.
Mark A. Greer wrote:
On the cost side of the equation, things are going to be messier in
mach-davinci because there will now be parallel files (e.g.,
a davinci devices.c file and a da8xx devices.c file, a davinci irq.c
file and a da8xx irq.c file).
There won't be DA8xx irq.c file
[mailto:sshtyl...@ru.mvista.com]
Sent: 2009年1月23日 13:44
To: He, Zhengting
Cc: Kevin Hilman; davinci-linux-open-source@linux.davincidsp.com; Wells,
Kimberly; McGoldrick, Bobby; Venkat, Subbu; Friedland, David
Subject: Re: omap-L1xxx
Hello.
He, Zhengting wrote:
I think serious customers
On Fri, Jan 23, 2009 at 11:05:38PM +0300, Sergei Shtylyov wrote:
Hello.
Mark A. Greer wrote:
On the cost side of the equation, things are going to be messier in
mach-davinci because there will now be parallel files (e.g., a davinci
devices.c file and a da8xx devices.c file, a davinci irq.c
He, Zhengting wrote:
Why do you think modifying the drivers for customized boards is a wrong
idea?
Because the drivers shouldn't contain anything board specific, at least not
directly. Some TI's code like the MMC driver has been plagued by that.
MV or open source cannot support every
On Fri, 2009-01-23 at 23:45 +0300, Sergei Shtylyov wrote:
Mark A. Greer wrote:
A somewhat related point, use of cpu_is_*. I think it would be smarter
to factor out the use of those calls as much as you can. If you had one
overall board.c file that did the cpu_is_*'s and hooked up the
Hello.
Kevin Hilman wrote:
Personally, if TI is OK with it, for kernel-internal names, I would
lean towards the da8xx prefix rather thant the omap prefix since it
would result in less confusion with the omap names.
Unless something changes, the .config options and macros will still be
DA8XX
Message-
From: Sergei Shtylyov [mailto:sshtyl...@ru.mvista.com]
Sent: 2009年1月23日 13:44
To: He, Zhengting
Cc: Kevin Hilman; davinci-linux-open-source@linux.davincidsp.com; Wells,
Kimberly; McGoldrick, Bobby; Venkat, Subbu; Friedland, David
Subject: Re: omap-L1xxx
Hello.
He
On Friday 23 January 2009, Sergei Shtylyov wrote:
That's trifles -- 'struct mux_config' which will take
up really much space with DA830's 400+ controllable signals.
Not really. It might be *nice* to have all of the pinmux
options pre-defined, but it's not *necessary* to do that.
Consider how
Steve Chen sc...@mvista.com writes:
On Fri, 2009-01-23 at 23:45 +0300, Sergei Shtylyov wrote:
Mark A. Greer wrote:
A somewhat related point, use of cpu_is_*. I think it would be smarter
to factor out the use of those calls as much as you can. If you had one
overall board.c file that did
On Fri, Jan 23, 2009 at 11:54:06PM +0300, Sergei Shtylyov wrote:
Double names would look quite stupid, to be honest.
I agree.
And I'm not sure they
will be upstream acceptable.
Almost certainly unacceptable. I've seen people try this before and get
scolded.
The issue isn't effort, its
Hello.
Steve Chen wrote:
A somewhat related point, use of cpu_is_*. I think it would be smarter
to factor out the use of those calls as much as you can. If you had one
overall board.c file that did the cpu_is_*'s and hooked up the correct
device data, platform_data, etc. (or called a routine
Hello.
David Brownell wrote:
That's trifles -- 'struct mux_config' which will take
up really much space with DA830's 400+ controllable signals.
Not really.
It also is optional kernel feature, luckily. Although with the
current OMAP-L137 EVM bootloaders you'll want that option
On Friday 23 January 2009, Sergei Shtylyov wrote:
But not all those options are pre-defined ... they get
added as needed to support various boards.
We have them all entered already. Sorry. :-)
That's OK too.
___
Davinci-linux-open-source
Hello.
David Brownell wrote:
We didn't want to cause two separate packages
(DA830 OMAP-L137) to be created, but yet we
want both to have some top-level visibility.
To clarify: DA830 Aureus (new brand) and
Note that there's also DA828 coming RSN:
Hello.
Kevin Hilman wrote:
From: Sergei Shtylyov [mailto:sshtyl...@ru.mvista.com]
[ ... ]
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
On Wed, Jan 21, 2009 at 11:35:07AM -0800, Kevin Hilman wrote:
Longley, Lester les...@ti.com writes:
[ ... ]
From: Sergei Shtylyov [mailto:sshtyl...@ru.mvista.com]
[ ... ]
So, how should we reference to OMAP-L1x in kernel (in order to avoid
the
confusion with real OMAP)?
Hi Mark,
From: Mark A. Greer [mailto:mgr...@mvista.com]
On Wed, Jan 21, 2009 at 11:35:07AM -0800, Kevin Hilman wrote:
Longley, Lester les...@ti.com writes:
[ ... ]
From: Sergei Shtylyov [mailto:sshtyl...@ru.mvista.com]
[ ... ]
So, how should we reference to OMAP-L1x in
Hello.
Yusuf Caglar AKYUZ wrote:
Absolutely.
Here's an example of enforcing your private opinion...
Yes, this is my private opinion, but I am not enforcing anything. I
am attempting to share the technical arguments behind my private
opinion so folks know where I'm coming from.
As
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Sergei Shtylyov wrote:
Hello.
Hello,
Besides, how are you using DaVinci? Asking because OMAP-L1xx/ and
DA8xx both seem to be targeted to the different market niches than
DaVinci -- at least the former completely lack the video support that
On Thu, Jan 22, 2009 at 09:53:43AM -0600, Longley, Lester wrote:
Hi Mark,
From: Mark A. Greer [mailto:mgr...@mvista.com]
On Wed, Jan 21, 2009 at 11:35:07AM -0800, Kevin Hilman wrote:
Longley, Lester les...@ti.com writes:
[ ... ]
From: Sergei Shtylyov
Mark A. Greer mgr...@mvista.com writes:
On Tue, Jan 20, 2009 at 05:26:38PM -0800, Kevin Hilman wrote:
Mark A. Greer mgr...@mvista.com writes:
On Tuesday 20 January 2009, David Brownell wrote:
Hi David Kevin.
[My apologies for being out of the loop on this. I just subscribed a
: davinci-linux-open-source@linux.davincidsp.com; 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:mgr...@mvista.com]
On Wed, Jan 21, 2009 at 11:35:07AM -0800, Kevin Hilman wrote
, 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:mgr...@mvista.com]
On Wed, Jan 21, 2009 at 11:35:07AM -0800, Kevin Hilman wrote:
Longley, Lester les...@ti.com writes:
[ ... ]
From: Sergei
Cc: Mark A. Greer; Longley, Lester; Wells, Kimberly; McGoldrick, Bobby; Venkat,
Subbu; Friedland, David; Nori, Sekhar;
davinci-linux-open-source@linux.davincidsp.com
Subject: Re: omap-L1xxx
He, Zhengting z-...@ti.com writes:
Hi, All,
After some discussion internally in TI, I think we (as TI
[mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of
He, Zhengting
Sent: 2009年1月22日 16:17
To: Kevin Hilman
Cc: davinci-linux-open-source@linux.davincidsp.com; Wells, Kimberly;
McGoldrick, Bobby; Venkat, Subbu; Friedland, David
Subject: RE: omap-L1xxx
Kevin,
Thanks a lot for your
Hello.
Mark A. Greer wrote:
Hi David Kevin.
[My apologies for being out of the loop on this. I just subscribed a
few mins ago and still catching up on the emails.]
Kind of my fault too -- I kept forgetting to CC Mark in the heat of
the argument...
On Tuesday 20 January 2009,
Hello.
David Brownell wrote:
- Entirely different dma controller.
Well, different address and fewer hardware events (32 vs 64),
but otherwise they both looked like EDMA. What's different
enough to may you say entirely different?
Hm, TCs are indeed mapped differently (CC mapped
Hello,
From: Sergei Shtylyov
Sent: Wednesday, January 21, 2009 5:42 PM
Hello.
Mark A. Greer wrote:
Hi David Kevin.
[My apologies for being out of the loop on this. I just subscribed a
few mins ago and still catching up on the emails.]
Kind of my fault too -- I kept
Hello.
Kevin Hilman wrote:
Either way, the lack of a complete proposal (not necessarily
in the form of patches) makes it hard to get anywhere with
such OMAP-L1xx discussions...
I think I've expressed it clear enough: common shared code is
to be moved to plat-davinci/ and OMAP-L1x
Hello.
Kevin Hilman wrote:
Either way, the lack of a complete proposal (not necessarily
in the form of patches) makes it hard to get anywhere with
such OMAP-L1xx discussions...
I think I've expressed it clear enough: common shared code is
to be moved to plat-davinci/
On Wed, 2009-01-21 at 15:12 +0300, Sergei Shtylyov wrote:
- We (or at least *I*) had no desire to have the same kernel binary
run on both a da8xx and a davinci. So, cutting out the davinci
runtime code data that was wasting memory was A Good Thing (tm).
Kevin seems the
Hello.
Nori, Sekhar wrote:
Either way, the lack of a complete proposal (not necessarily
in the form of patches) makes it hard to get anywhere with
such OMAP-L1xx discussions...
think I've expressed it clear enough: common shared code is
to be moved to plat-davinci/ and OMAP-L1x support is to
Hello,
From: Sergei Shtylyov [mailto:sshtyl...@ru.mvista.com]
Sent: Wednesday, January 21, 2009 6:36 PM
Hello.
Nori, Sekhar wrote:
Either way, the lack of a complete proposal (not necessarily
in the form of patches) makes it hard to get anywhere with
such OMAP-L1xx discussions...
Hello.
Steve Chen wrote:
- We (or at least *I*) had no desire to have the same kernel binary
run on both a da8xx and a davinci. So, cutting out the davinci
runtime code data that was wasting memory was A Good Thing (tm).
Kevin seems the only person interested in ahving the
Hello.
Nori, Sekhar wrote:
Either way, the lack of a complete proposal (not necessarily
in the form of patches) makes it hard to get anywhere with
such OMAP-L1xx discussions...
think I've expressed it clear enough: common shared code is
to be moved to plat-davinci/ and OMAP-L1x support is
Hi Sergei, Sekhar,
From: davinci-linux-open-source-bounces+lester=ti@linux.davincidsp.com
[mailto:davinci-linux-open-source-
Nori, Sekhar wrote:
Either way, the lack of a complete proposal (not necessarily
in the form of patches) makes it hard to get anywhere with
such OMAP-L1xx
Hello.
Longley, Lester wrote:
Either way, the lack of a complete proposal (not necessarily
in the form of patches) makes it hard to get anywhere with
such OMAP-L1xx discussions...
think I've expressed it clear enough: common shared code is
to be moved to plat-davinci/ and OMAP-L1x support
Hello, I wrote:
Either way, the lack of a complete proposal (not necessarily
in the form of patches) makes it hard to get anywhere with
such OMAP-L1xx discussions...
I think I've expressed it clear enough: common shared code is
to be moved to plat-davinci/ and OMAP-L1x support is to be
added
Sergei Shtylyov sshtyl...@ru.mvista.com writes:
Hello.
Kevin Hilman wrote:
Either way, the lack of a complete proposal (not necessarily
in the form of patches) makes it hard to get anywhere with
such OMAP-L1xx discussions...
I think I've expressed it clear enough: common
On Wed, 2009-01-21 at 10:01 -0800, Kevin Hilman wrote:
Steve Chen sc...@mvista.com writes:
On Wed, 2009-01-21 at 15:12 +0300, Sergei Shtylyov wrote:
- We (or at least *I*) had no desire to have the same kernel binary
run on both a da8xx and a davinci. So, cutting out the davinci
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Kevin Hilman wrote:
Sergei Shtylyov sshtyl...@ru.mvista.com writes:
Absolutely.
Here's an example of enforcing your private opinion...
Yes, this is my private opinion, but I am not enforcing anything. I
am attempting to share the
Hi Sergei,
From: Sergei Shtylyov [mailto:sshtyl...@ru.mvista.com]
Longley, Lester wrote:
Either way, the lack of a complete proposal (not necessarily
in the form of patches) makes it hard to get anywhere with
such OMAP-L1xx discussions...
think I've expressed it clear enough: common
Steve Chen sc...@mvista.com writes:
On Wed, 2009-01-21 at 10:01 -0800, Kevin Hilman wrote:
Steve Chen sc...@mvista.com writes:
On Wed, 2009-01-21 at 15:12 +0300, Sergei Shtylyov wrote:
- We (or at least *I*) had no desire to have the same kernel binary
run on both a da8xx and a
Longley, Lester les...@ti.com writes:
[ ... ]
From: Sergei Shtylyov [mailto:sshtyl...@ru.mvista.com]
[ ... ]
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
Hello.
Yusuf Caglar AKYUZ wrote:
Absolutely.
Here's an example of enforcing your private opinion...
Yes, this is my private opinion, but I am not enforcing anything. I
am attempting to share the technical arguments behind my private
opinion so folks know where I'm coming from.
As
Hi Kevin,
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Longley, Lester les...@ti.com writes:
[ ... ]
From: Sergei Shtylyov [mailto:sshtyl...@ru.mvista.com]
[ ... ]
So, how should we reference to OMAP-L1x in kernel (in order to avoid
the
confusion with real
On Wednesday 21 January 2009, Longley, Lester wrote:
We didn't want to cause two separate packages
(DA830 OMAP-L137) to be created, but yet we
want both to have some top-level visibility.
To clarify: DA830 Aureus (new brand) and
OMAP-L137 (established brand) are closely
related silicon,
Hi Dave,
From: David Brownell [mailto:davi...@pacbell.net]
On Wednesday 21 January 2009, Longley, Lester wrote:
We didn't want to cause two separate packages
(DA830 OMAP-L137) to be created, but yet we
want both to have some top-level visibility.
To clarify: DA830 Aureus (new brand)
On Tue, Jan 20, 2009 at 04:23:53PM -0800, David Brownell wrote:
On Tuesday 20 January 2009, Mark A. Greer wrote:
- Entirely different dma controller.
Well, different address and fewer hardware events (32 vs 64),
but otherwise they both looked like EDMA. What's different
enough to may you
If so, my initial reaction is to thnk that
using da830_* symbols would be the least
confusing option ... instead of omap_*.
Text in Kconfig would be able to include both
Aureus and OMAP (L1xx) descriptions.
That's beginning to sound like a consensus (I hope).
This same situation has
On Tue, Jan 20, 2009 at 05:26:38PM -0800, Kevin Hilman wrote:
Mark A. Greer mgr...@mvista.com writes:
On Tuesday 20 January 2009, David Brownell wrote:
Hi David Kevin.
[My apologies for being out of the loop on this. I just subscribed a
few mins ago and still catching up on the
On Wed, Jan 21, 2009 at 12:55:24PM -0800, David Brownell wrote:
On Wednesday 21 January 2009, Longley, Lester wrote:
We didn't want to cause two separate packages
(DA830 OMAP-L137) to be created, but yet we
want both to have some top-level visibility.
To clarify: DA830 Aureus (new
It would be much better to have $SUBJECT change when
the topic changes ...
On Tuesday 20 January 2009, Sergei Shtylyov wrote:
The way I currently see things is a single mach-davinci with support
for dm644x, dm355, dm646x, omapl1x7, etc.
MV too have clinged to the idea of parasitising on
Hello.
David Brownell wrote:
It would be much better to have $SUBJECT change when
the topic changes ...
Sure.
The way I currently see things is a single mach-davinci with support
for dm644x, dm355, dm646x, omapl1x7, etc.
MV too have clinged to the idea of parasitising on the DaVinci
On Tuesday 20 January 2009, Sergei Shtylyov wrote:
Either way, the lack of a complete proposal (not necessarily
in the form of patches) makes it hard to get anywhere with
such OMAP-L1xx discussions...
I think I've expressed it clear enough: common shared code is
to be moved to
David Brownell wrote:
Either way, the lack of a complete proposal (not necessarily
in the form of patches) makes it hard to get anywhere with
such OMAP-L1xx discussions...
I think I've expressed it clear enough: common shared code is
to be moved to plat-davinci/ and OMAP-L1x support is to be
I suspect that until patches appear, discussion can get no
further. Plus, if it's going to be mach-omap-L1 it'd
be good to have enough detail that the OMAP team (and RMK)
can see why it should pair with plat-davinci instead of
the more obvious plat-omap.
Although it has OMAP in the
Sergei Shtylyov sshtyl...@ru.mvista.com writes:
David Brownell wrote:
Either way, the lack of a complete proposal (not necessarily
in the form of patches) makes it hard to get anywhere with
such OMAP-L1xx discussions...
I think I've expressed it clear enough: common shared code is
to be moved
Hello.
Kevin Hilman wrote:
Either way, the lack of a complete proposal (not necessarily
in the form of patches) makes it hard to get anywhere with
such OMAP-L1xx discussions...
I think I've expressed it clear enough: common shared code is
to be moved to plat-davinci/ and OMAP-L1x
Hello, I wrote:
Either way, the lack of a complete proposal (not necessarily
in the form of patches) makes it hard to get anywhere with
such OMAP-L1xx discussions...
I think I've expressed it clear enough: common shared code is
to be moved to plat-davinci/ and OMAP-L1x support is to
-Original Message-
From: David Brownell [mailto:davi...@pacbell.net]
Sent: Tuesday, January 20, 2009 3:50 PM
To: Griffis, Brad
Cc: Sergei Shtylyov; DaVinci
Subject: Re: omap-L1xxx (WAS: [patch 0/6] EDMA interface updates)
On Tuesday 20 January 2009, Griffis, Brad wrote:
I
Hello.
David Brownell wrote:
The vast majority of the HW IP is shared with the
rest of the DaVinci family. I'm not aware of any HW IP shared with
OMAP (other than MUSB.)
MUSB runs on Blackfin too ... and the MUSB on OMAP-L1xx is
like the DaVinci flavor, given its use of CPPI for DMA.
Sergei Shtylyov sshtyl...@ru.mvista.com writes:
Hello.
Kevin Hilman wrote:
Either way, the lack of a complete proposal (not necessarily
in the form of patches) makes it hard to get anywhere with
such OMAP-L1xx discussions...
I think I've expressed it clear enough: common
On Tuesday 20 January 2009, David Brownell wrote:
Hi David Kevin.
[My apologies for being out of the loop on this. I just subscribed a
few mins ago and still catching up on the emails.]
On Tuesday 20 January 2009, Sergei Shtylyov wrote:
Either way, the lack of a complete proposal (not
On Tuesday 20 January 2009, Mark A. Greer wrote:
- Entirely different dma controller.
Well, different address and fewer hardware events (32 vs 64),
but otherwise they both looked like EDMA. What's different
enough to may you say entirely different?
Mark A. Greer mgr...@mvista.com writes:
On Tuesday 20 January 2009, David Brownell wrote:
Hi David Kevin.
[My apologies for being out of the loop on this. I just subscribed a
few mins ago and still catching up on the emails.]
Hi Mark,
I was hoping you would be joining this thread... :)
74 matches
Mail list logo
