On Sun, Dec 6, 2009 at 2:51 PM, Øyvind Harboe oyvind.har...@zylin.com wrote:
1. Move the $(srcdir) from defining _DIR vars to their use. i.e.
set just the directory component.
I'm not quite sure what you mean by this. I have a makefile rule
that is only used with the minidriver,
On Mon, 2009-12-07 at 12:26 +0100, Øyvind Harboe wrote:
On Sun, Dec 6, 2009 at 2:51 PM, Øyvind Harboe oyvind.har...@zylin.com wrote:
1. Move the $(srcdir) from defining _DIR vars to their use. i.e.
set just the directory component.
I'm not quite sure what you mean by this. I
1. Move the $(srcdir) from defining _DIR vars to their use. i.e.
set just the directory component.
I'm not quite sure what you mean by this. I have a makefile rule
that is only used with the minidriver, would you like that to be
defined always? I'm not even sure that would work when
On Sat, 2009-12-05 at 08:25 +0100, Øyvind Harboe wrote:
This worked pretty well, but there are lots of (to me) inexplicable
-I's on the command line still and none of them point to the right
place in the build tree. I'm testing minidummy build != src dir.
oharboe/fixminidriver2
On Sat, Dec 5, 2009 at 8:45 AM, Zach Welch z...@superlucidity.net wrote:
On Sat, 2009-12-05 at 08:35 +0100, Øyvind Harboe wrote:
The approach seems to work fine, but requires that some other
issues are sorted out first with include dirs.
From error message above, there are two strange -I
On Sat, 2009-12-05 at 11:14 +0100, Øyvind Harboe wrote:
On Sat, Dec 5, 2009 at 8:45 AM, Zach Welch z...@superlucidity.net wrote:
On Sat, 2009-12-05 at 08:35 +0100, Øyvind Harboe wrote:
The approach seems to work fine, but requires that some other
issues are sorted out first with include
It's getting there, see oharboe/fixminidriver.
I had to mess with lots of Makefile.am to pollute the include path. If I
can get that out of the way, then I should be able to clean up the
rest too.
--
Øyvind Harboe
US toll free 1-866-980-3434 / International +47 51 63 25 00
On Fri, 2009-12-04 at 16:03 +0100, Øyvind Harboe wrote:
It's getting there, see oharboe/fixminidriver.
I had to mess with lots of Makefile.am to pollute the include path. If I
can get that out of the way, then I should be able to clean up the
rest too
Yeah, those changes should not go into
On Fri, Dec 4, 2009 at 10:36 PM, Zach Welch z...@superlucidity.net wrote:
On Fri, 2009-12-04 at 16:03 +0100, Øyvind Harboe wrote:
It's getting there, see oharboe/fixminidriver.
I had to mess with lots of Makefile.am to pollute the include path. If I
can get that out of the way, then I should
On Fri, 2009-12-04 at 22:51 +0100, Øyvind Harboe wrote:
On Fri, Dec 4, 2009 at 10:36 PM, Zach Welch z...@superlucidity.net wrote:
On Fri, 2009-12-04 at 16:03 +0100, Øyvind Harboe wrote:
It's getting there, see oharboe/fixminidriver.
I had to mess with lots of Makefile.am to pollute the
This worked pretty well, but there are lots of (to me) inexplicable
-I's on the command line still and none of them point to the right
place in the build tree. I'm testing minidummy build != src dir.
oharboe/fixminidriver2
../openocd/configure --enable-minidriver-dummy --enable-maintainer-mode
On Sat, 2009-12-05 at 08:35 +0100, Øyvind Harboe wrote:
The approach seems to work fine, but requires that some other
issues are sorted out first with include dirs.
From error message above, there are two strange -I additions:
NB! build != src dir
-I. = current build directory
-I../.. =
So the minidriver (including classic API) must have control over whether or
not the following fn's gets inlined or not. These fn's really are in the inner
loops and boil away to *nothing* on a low performance low latency
system.
Note that I'm not keen on the idea of an ABI for OpenOCD, we need
On Thu, 2009-12-03 at 09:20 +0100, Øyvind Harboe wrote:
The public API _must_ be a non-inline version of the API that calls the
inline version. Period.
You don't explain why this is necessary and I don't agree. I believe
you assume that it is impossible to allow the minidriver to inline
On Thu, 2009-12-03 at 09:53 +0100, Øyvind Harboe wrote:
So the minidriver (including classic API) must have control over whether or
not the following fn's gets inlined or not. These fn's really are in the inner
loops and boil away to *nothing* on a low performance low latency
system.
And they
On Thu, 2009-12-03 at 10:22 +0100, Øyvind Harboe wrote:
(Ref. discussion I think we've settled that the minidriver can either
implement an ABI or use inlining for performance.)
On Thu, Dec 3, 2009 at 10:11 AM, Zach Welch z...@superlucidity.net wrote:
On Thu, 2009-12-03 at 09:53 +0100,
On Thu, Dec 3, 2009 at 10:36 AM, Zach Welch z...@superlucidity.net wrote:
On Thu, 2009-12-03 at 10:22 +0100, Øyvind Harboe wrote:
(Ref. discussion I think we've settled that the minidriver can either
implement an ABI or use inlining for performance.)
On Thu, Dec 3, 2009 at 10:11 AM, Zach
(Ref. discussion I think we've settled that the minidriver can either
implement an ABI or use inlining for performance.)
On Thu, Dec 3, 2009 at 10:11 AM, Zach Welch z...@superlucidity.net wrote:
On Thu, 2009-12-03 at 09:53 +0100, Øyvind Harboe wrote:
So the minidriver (including classic API)
On Thu, 2009-12-03 at 10:51 +0100, Øyvind Harboe wrote:
On Thu, Dec 3, 2009 at 10:36 AM, Zach Welch z...@superlucidity.net wrote:
On Thu, 2009-12-03 at 10:22 +0100, Øyvind Harboe wrote:
(Ref. discussion I think we've settled that the minidriver can either
implement an ABI or use inlining
Fix 'regression' where jtag_add_dr_out() is no longer inlined
after refactoring.
The minidrivers strip away all the overhead and allow inner loops
to communicate directly with a hardware FIFO.
Signed-off-by: Øyvind Harboe oyvind.har...@zylin.com
---
src/jtag/Makefile.am |2 -
Do not apply this until you fix the problem noted below.
Thanks,
Zach
On Wed, 2009-12-02 at 14:38 +0100, Øyvind Harboe wrote:
Fix 'regression' where jtag_add_dr_out() is no longer inlined
after refactoring.
The minidrivers strip away all the overhead and allow inner loops
to communicate
+
+/* The minidriver contains inline versions of JTAG fn's */
+#include minidriver.h
+
This is bad, as you are creating a new layering violation that will need
to be removed. You should move this #include to somewhere other than
what should be our public API, probably inside the C files
I just noticed that there may be other problems with this; I question
the need for both -I and #include dirname/ Seems like one or the
other is enough, so there appears to be a new redundancy here.
On Wed, 2009-12-02 at 13:39 -0800, Zach Welch wrote:
Do not apply this until you fix the
On Wed, Dec 2, 2009 at 10:55 PM, Zach Welch z...@superlucidity.net wrote:
I just noticed that there may be other problems with this; I question
the need for both -I and #include dirname/ Seems like one or the
other is enough, so there appears to be a new redundancy here.
I removed the -I
On Wed, 2009-12-02 at 23:00 +0100, Øyvind Harboe wrote:
On Wed, Dec 2, 2009 at 10:55 PM, Zach Welch z...@superlucidity.net wrote:
I just noticed that there may be other problems with this; I question
the need for both -I and #include dirname/ Seems like one or the
other is enough, so
On Wed, 2009-12-02 at 22:54 +0100, Øyvind Harboe wrote:
+
+/* The minidriver contains inline versions of JTAG fn's */
+#include minidriver.h
+
This is bad, as you are creating a new layering violation that will need
to be removed. You should move this #include to somewhere other
On Wed, 2009-12-02 at 14:32 -0800, Zach Welch wrote:
On Wed, 2009-12-02 at 22:54 +0100, Øyvind Harboe wrote:
+
+/* The minidriver contains inline versions of JTAG fn's */
+#include minidriver.h
+
This is bad, as you are creating a new layering violation that will need
to be
I was thinking about splitting this patch into at least a few:
The first would be to get rid of some -I's.
The second would clarify that the classic JTAG driver
is just another minidriver.
The third would then allow a minidriver to grab the
JTAG stack from jtag_xxx() and down to the metal.
The
On Wed, 2009-12-02 at 14:44 -0800, Zach Welch wrote:
On Wed, 2009-12-02 at 14:32 -0800, Zach Welch wrote:
On Wed, 2009-12-02 at 22:54 +0100, Øyvind Harboe wrote:
+
+/* The minidriver contains inline versions of JTAG fn's */
+#include minidriver.h
+
This is bad, as you
I am probably wrong about some details (e.g. renaming), but the goal of
this is to eliminate the #if logic from the header files too. That is
not acceptable for installed libraries either, so we should not be
adding more of that to headers The tricks above are similar to
those that I
Okay. The solution that I have tried to propose will get this back,
without exposing anything during a normal non-minidriver installation.
The point I'm trying to make is that there is no normal non-minidriver.
The normal/classic stack is *also* a minidriver.
The *first* step would be to
31 matches
Mail list logo
