0) While working my way through the stack of apparently unused headers I
also looked at arch/blackfin/include/asm/ipipe_base.h, as nothing seems
to include that header. The last include of that file got removed in
commit 1353d050facf5efd8dc05ba6c4d7852fcb423b15 ("Blackfin/ipipe:
restore pipeline bits in irqflags"). So that header is unused since
v2.6.39.
1) Before submitting the (possibly trivial) patch to remove that header
I did some further research, because I wanted to be sure that removing
this header was a reasonable thing to do.
2) I learned that arch/blackfin/include/asm/ipipe_base.h got added to
the tree in commit 6a01f230339321292cf065551f8cf55361052461 ("Blackfin
arch: merge adeos blackfin part to arch/blackfin/"). That commit also
introduced the macro CONFIG_IPIPE. But it did not introduce the Kconfig
symbol IPIPE. (Neither did it add code that defines a macro
CONFIG_IPIPE.) So to me it looks like the I-pipe code got added to
v2.6.29 without proper Kbuild support.
3) And this is currently still the case. There seem to be no Kconfig
symbols IPIPE, IPIPE_DEBUG, IPIPE_DEBUG_CONTEXT, or IPIPE_TRACE_IRQSOFF.
(Neither seems there to be code that defines the macros CONFIG_IPIPE,
CONFIG_IPIPE_DEBUG, CONFIG_IPIPE_DEBUG_CONTEXT, or
CONFIG_IPIPE_TRACE_IRQSOFF.)
4) Whether or not arch/blackfin/include/asm/ipipe_base.h should be
removed isn't very interesting. What is more interesting is how the
blackfin I-pipe code is supposed to be built. How can this code be built
from what currently is in mainline?
Paul Bolle
Hi Paul,
The IPIPE patch is part of the ADEOS real time kernel patch. The common part of this patch hasn't been merged into mainline by the maintainer Philippe Gerum, although the Blackfin architecture part was. The relative Kbuild support and Kconfig symbols are defined in the ADOES common patch.
Regards,
Sonic
>-----Original Message-----
>From: [email protected] [mailto:uclinux-dist-devel-
>[email protected]] On Behalf Of Paul Bolle
>Sent: Monday, June 11, 2012 5:51 AM
>To: Mike Frysinger
>Cc: [email protected]; [email protected]
>Subject: [uclinux-dist-devel] blackfin: how is the I-pipe code supposed to be built?
>
>0) While working my way through the stack of apparently unused headers I
>also looked at arch/blackfin/include/asm/ipipe_base.h, as nothing seems
>to include that header. The last include of that file got removed in
>commit 1353d050facf5efd8dc05ba6c4d7852fcb423b15 ("Blackfin/ipipe:
>restore pipeline bits in irqflags"). So that header is unused since
>v2.6.39.
>
>1) Before submitting the (possibly trivial) patch to remove that header
>I did some further research, because I wanted to be sure that removing
>this header was a reasonable thing to do.
>
>2) I learned that arch/blackfin/include/asm/ipipe_base.h got added to
>the tree in commit 6a01f230339321292cf065551f8cf55361052461 ("Blackfin
>arch: merge adeos blackfin part to arch/blackfin/"). That commit also
>introduced the macro CONFIG_IPIPE. But it did not introduce the Kconfig
>symbol IPIPE. (Neither did it add code that defines a macro
>CONFIG_IPIPE.) So to me it looks like the I-pipe code got added to
>v2.6.29 without proper Kbuild support.
>
>3) And this is currently still the case. There seem to be no Kconfig
>symbols IPIPE, IPIPE_DEBUG, IPIPE_DEBUG_CONTEXT, or
>IPIPE_TRACE_IRQSOFF.
>(Neither seems there to be code that defines the macros CONFIG_IPIPE,
>CONFIG_IPIPE_DEBUG, CONFIG_IPIPE_DEBUG_CONTEXT, or
>CONFIG_IPIPE_TRACE_IRQSOFF.)
>
>4) Whether or not arch/blackfin/include/asm/ipipe_base.h should be
>removed isn't very interesting. What is more interesting is how the
>blackfin I-pipe code is supposed to be built. How can this code be built
>from what currently is in mainline?
>
>
>Paul Bolle
>
>_______________________________________________
>Uclinux-dist-devel mailing list
>[email protected]
>https://blackfin.uclinux.org/mailman/listinfo/uclinux-dist-devel
Sonic,
On Sun, 2012-06-10 at 23:05 -0400, Zhang, Sonic wrote:
> The IPIPE patch is part of the ADEOS real time kernel patch. The
> common part of this patch hasn't been merged into mainline by the
> maintainer Philippe Gerum, although the Blackfin architecture part
> was. The relative Kbuild support and Kconfig symbols are defined in
> the ADOES common patch.
What's the point of having code in the mainline tree, for over three
years, without any Kbuild or Kconfig support?
Paul Bolle
On Monday 11 June 2012 15:44:50 Paul Bolle wrote:
> On Sun, 2012-06-10 at 23:05 -0400, Zhang, Sonic wrote:
> > The IPIPE patch is part of the ADEOS real time kernel patch. The
> > common part of this patch hasn't been merged into mainline by the
> > maintainer Philippe Gerum, although the Blackfin architecture part
> > was. The relative Kbuild support and Kconfig symbols are defined in
> > the ADOES common patch.
>
> What's the point of having code in the mainline tree, for over three
> years, without any Kbuild or Kconfig support?
because the Blackfin team cares about keeping ADEOS active throughout the
rewrites/updates of core code. it isn't hurting keeping the code in the
arch/blackfin/ tree, and we're ok with any overhead it implies for the team.
-mike