[PATCH] testsuite: Add libdl/dl05 weak symbol test.
Requires rtems-tools to be updated.
---
testsuites/libtests/Makefile.am | 2 +-
testsuites/libtests/configure.ac | 1 +
testsuites/libtests/dl05/Makefile.am | 49 +
testsuites/libtests/dl05/dl-load.c | 49 +
testsuites/libtests/dl05/dl-load.h | 14 ++
testsuites/libtests/dl05/dl-o5.c | 17
testsuites/libtests/dl05/dl05.doc| 25 +++
testsuites/libtests/dl05/dl05.scn| 9
testsuites/libtests/dl05/init.c | 82
9 files changed, 247 insertions(+), 1 deletion(-)
create mode 100644 testsuites/libtests/dl05/Makefile.am
create mode 100644 testsuites/libtests/dl05/dl-load.c
create mode 100644 testsuites/libtests/dl05/dl-load.h
create mode 100644 testsuites/libtests/dl05/dl-o5.c
create mode 100644 testsuites/libtests/dl05/dl05.doc
create mode 100644 testsuites/libtests/dl05/dl05.scn
create mode 100644 testsuites/libtests/dl05/init.c
diff --git a/testsuites/libtests/Makefile.am b/testsuites/libtests/Makefile.am
index effed07..4925775 100644
--- a/testsuites/libtests/Makefile.am
+++ b/testsuites/libtests/Makefile.am
@@ -46,7 +46,7 @@ _SUBDIRS += syscall01
endif
if DLTESTS
-_SUBDIRS += dl01 dl02 dl03
+_SUBDIRS += dl01 dl02 dl03 dl05
if HAS_CXX
_SUBDIRS += dl04
endif
diff --git a/testsuites/libtests/configure.ac b/testsuites/libtests/configure.ac
index 31afcae..9093cba 100644
--- a/testsuites/libtests/configure.ac
+++ b/testsuites/libtests/configure.ac
@@ -128,6 +128,7 @@ dl01/Makefile
dl02/Makefile
dl03/Makefile
dl04/Makefile
+dl05/Makefile
dumpbuf01/Makefile
ftp01/Makefile
gxx01/Makefile
diff --git a/testsuites/libtests/dl05/Makefile.am
b/testsuites/libtests/dl05/Makefile.am
new file mode 100644
index 000..4aeea8a
--- /dev/null
+++ b/testsuites/libtests/dl05/Makefile.am
@@ -0,0 +1,49 @@
+rtems_tests_PROGRAMS = dl05
+dl05_SOURCES = init.c dl-load.c dl-tar.c dl-tar.h
+
+BUILT_SOURCES = dl-tar.c dl-tar.h
+
+dist_rtems_tests_DATA = dl05.scn dl05.doc
+
+include $(RTEMS_ROOT)/make/custom/@RTEMS_BSP@.cfg
+include $(top_srcdir)/../automake/compile.am
+include $(top_srcdir)/../automake/leaf.am
+
+AM_CPPFLAGS += -I$(top_srcdir)/../support/include
+
+LINK_OBJS = $(dl05_OBJECTS)
+LINK_LIBS = $(dl05_LDLIBS)
+
+dl-o1.o: dl-o5.c
+
+dl.tar: dl-o5.o
+ @rm -f $@
+ $(PAX) -w -f $@ $<
+CLEANFILES += dl.tar
+
+dl-tar.c: dl.tar
+ $(BIN2C) -C $< $@
+CLEANFILES += dl-tar.c
+
+dl-tar.h: dl.tar
+ $(BIN2C) -H $< $@
+CLEANFILES += dl-tar.h
+
+dl05.pre$(EXEEXT): $(dl05_OBJECTS) $(dl05_DEPENDENCIES)
+ @rm -f dl05.pre$(EXEEXT)
+ $(make-exe)
+ rm -f dl05.pre.ralf
+
+dl05.pre: dl05.pre$(EXEEXT)
+ mv $< $@
+CLEANFILES += dl05.pre
+
+dl-sym.o: dl05.pre
+ rtems-syms -e -c "$(CFLAGS)" -o $@ $<
+
+dl05$(EXEEXT): $(dl05_OBJECTS) $(dl05_DEPENDENCIES) dl-sym.o
+ @rm -f dl05$(EXEEXT)
+ $(LINK.c) $(CPU_CFLAGS) $(AM_CFLAGS) $(AM_LDFLAGS) \
+ -o $(basename $@)$(EXEEXT) $(LINK_OBJS) dl-sym.o
$(LINK_LIBS)
+
+include $(top_srcdir)/../automake/local.am
diff --git a/testsuites/libtests/dl05/dl-load.c
b/testsuites/libtests/dl05/dl-load.c
new file mode 100644
index 000..3036a3a
--- /dev/null
+++ b/testsuites/libtests/dl05/dl-load.c
@@ -0,0 +1,49 @@
+/*
+ * Copyright (c) 2014 Chris Johns . All rights reserved.
+ *
+ * The license and distribution terms for this file may be
+ * found in the file LICENSE in this distribution or at
+ * http://www.rtems.org/license/LICENSE.
+ */
+
+#include "tmacros.h"
+
+#include
+
+#include
+
+#include "dl-load.h"
+
+typedef int (*dl_call)(void);
+
+__attribute__((__weak__)) void base_func(const char *c);
+
+__attribute__((__weak__)) void base_func(const char *c)
+{
+ printf("base_func: %s", c);
+}
+
+int dl_load_test(void)
+{
+ void* handle;
+ dl_call call;
+ int call_ret;
+ int unresolved;
+ char* message = "loaded";
+
+ printf("load: /dl-o5.o\n");
+ rtems_test_assert((handle = dlopen ("/dl-o5.o", RTLD_NOW | RTLD_GLOBAL)) !=
NULL);
+ if (dlinfo (handle, RTLD_DI_UNRESOLVED, &unresolved) < 0)
+message = "dlinfo error checking unresolved status";
+ else if (unresolved)
+message = "has unresolved externals";
+ printf ("handle: %p %s\n", handle, message);
+ rtems_test_assert(unresolved == 0);
+ base_func("Called from " __FILE__ ": working?\n");
+ rtems_test_assert((call = dlsym (handle, "lib_func")) != NULL);
+ rtems_test_assert((call_ret = call ()) == 0);
+ rtems_test_assert(dlclose (handle) == 0);
+ printf ("handle: %p closed\n", handle);
+
+ return 0;
+}
diff --git a/testsuites/libtests/dl05/dl-load.h
b/testsuites/libtests/dl05/dl-load.h
new file mode 100644
index 000..3f3910a
--- /dev/null
+++ b/testsuites/libtests/dl05/dl-load.h
@@ -0,0 +1,14 @@
+/*
+ * Copyright (c) 2014 Chris Johns . All rights reserved.
+ *
+ * The license and distribution terms for this file may be
+ * found in the file LICENSE in this distribution or at
+ * http://www.rt
Re: [PATCH v2 2/2] libbsp/arm: Fix the local interrupt mask disable/enable calls.
Hello Chris and others, I would like to remind Chris's patches (top-post to highlight important the first) [PATCH v2 1/2] arm/cortex-a: Fix cache flush/invalidate after u-boot. [PATCH v2 2/2] libbsp/arm: Fix the local interrupt mask disable/enable calls. I consider fix of Zynq (all arm-a9mpcore-start) boot through U-boot as important. But discussion has vanished. >From my point of view, changes should/could be committed as they are. I consider locking in this place as unimportant in actual state (see my previous analysis in the thread) so the second patch can even replace rtems_interrupt_disable by comment - rtems_interrupt_disable(level); + /* FIXME: if concurrent update of same area is considered locking hat to be added */ or even remove lines alltogether. The real need for locking has been eliminated by my previous patch bsps/arm: do not disable MMU during translation table management operations. because set_translation_table_entries() manipulated with global core state before. It disabled cache and after update re-enabled it. Interleaving parallel execution of this sequence would lead to errors for sure. As I have analyzed, that sequence has been probably broken for SMP at all because invalidation complete cache (only realizable by set and way on ARMv7) can be implemented without broadcast to snoop subsystem on some cores so only reliable way is to ask all CPUs by IPI to stop, then run complete cache flush on each core one by one. But that is not case for now, so locking is not required except for case of contention for given region and this has to be solved somewhere else. So at the end, I suggest to remove locking alltogether there. There has been left my question unanswered Is there some defined function/way to check if RTEMS executive reached switch to multitasking mode? This has impact to think about correct locking in functions which are required to be used during startup when there is no concurrent execution but mutexes support and memory initialization is not finished yet but the same functions can be used later when scheduler is running for further update of system state. More complete analysis and context in previous communication. Best wishes, Pavel On Tuesday 16 of August 2016 15:28:42 Pavel Pisa wrote: > Hello Chris and Sebastian, > > On Tuesday 16 of August 2016 07:55:57 Sebastian Huber wrote: > > On 16/08/16 07:45, Chris Johns wrote: > > > --- > > > c/src/lib/libbsp/arm/shared/arm-cp15-set-ttb-entries.c | 4 ++-- > > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > > > diff --git a/c/src/lib/libbsp/arm/shared/arm-cp15-set-ttb-entries.c > > > b/c/src/lib/libbsp/arm/shared/arm-cp15-set-ttb-entries.c index > > > f650009..cfad45f 100644 > > > --- a/c/src/lib/libbsp/arm/shared/arm-cp15-set-ttb-entries.c > > > +++ b/c/src/lib/libbsp/arm/shared/arm-cp15-set-ttb-entries.c > > > @@ -88,10 +88,10 @@ uint32_t arm_cp15_set_translation_table_entries( > > > rtems_interrupt_level level; > > > uint32_t section_flags_of_first_entry; > > > > > > - rtems_interrupt_disable(level); > > > + rtems_interrupt_local_disable(level); > > > section_flags_of_first_entry = > > > set_translation_table_entries(begin, end, section_flags); > > > - rtems_interrupt_enable(level); > > > + rtems_interrupt_local_enable(level); > > > > > > return section_flags_of_first_entry; > > > } > > > > We should only change this if this is known to work on SMP. > > My analysis for this concrete case, > > 1) RTEMS uses same MMU table for all CPUs. > 2) inner set_translation_table_entries() ensures that change >is visible to all CPUs > 3) when arm_cp15_set_translation_table_entries() is called for range >which is not (yet) accessed by other CPU(s) then the function should >not cause any breakage > 4) when change is requested for same range in parallel/twice from multiple >threads or even CPUs then it is indication of some more serious problem >in upper layers > 5) if the update of mapping is requested for some range from cached to >uncached for example then it is not enough to protect >arm_cp15_set_translation_table_entries() alone. Protection >of necessary cache flush and invalidation is required in addition. > > > So generally, there is almost no difference between case when there is > no protection or weak protection by rtems_interrupt_local_disable(). > May it be that there can be some difference if operation > ttb [i] = addr | section_flags; > is translated by multiple memory accesses by C compiler (highly > improbable). > > If the dynamic MMU operations/virtual space allocations are needed > like in multiprocess OS then MMU table changes needs to be protected > by spinlock or better semaphore (to not cause block of other tasks). > > So I agree that simple change of rtems_interrupt_disable(level) > to rtems_interrupt_local_disable(level) is not perfect but on the other > hand real situation is not changed. I
Re: [PATCH v2 2/2] libbsp/arm: Fix the local interrupt mask disable/enable calls.
Hello Gedare, On Thursday 25 of August 2016 17:32:09 Gedare Bloom wrote: > On Thu, Aug 25, 2016 at 6:56 AM, Pavel Pisa wrote: > > Is there some defined function/way to check if RTEMS executive > > reached switch to multitasking mode? > > _System_state_Is_before_multitasking() Thanks, great that is what I have been looking for. > > This has impact to think about correct locking in functions > > which are required to be used during startup when there is > > no concurrent execution but mutexes support and memory initialization > > is not finished yet but the same functions can be used later > > when scheduler is running for further update of system state. > > > > More complete analysis and context in previous communication. > > I read prior discussion and had no problems, but Sebastian's concern > should be addressed whether other ARM targets are correct or not. His (correct) concern has been about SMP. But I think that need of locking has been eliminated by my previous commit. There is another reason against locking by IRQ disable or spinlock. If we consider update of pagetables at runtime where some real time tasks run then if scheduler is blocked but change in large part of address space then we can consider this as almost unbound latency source. So I vote for no locking at this level at all and mutex based locking (skipped if part of initialization and _System_state_Is_before_multitasking) at higher level when concurrent use need arises - for example allocation of virtual address space for mmap or something similar. Best wishes, Pavel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH v2 2/2] libbsp/arm: Fix the local interrupt mask disable/enable calls.
On Thu, Aug 25, 2016 at 1:47 PM, Pavel Pisa wrote: > Hello Gedare, > > On Thursday 25 of August 2016 17:32:09 Gedare Bloom wrote: >> On Thu, Aug 25, 2016 at 6:56 AM, Pavel Pisa wrote: >> > Is there some defined function/way to check if RTEMS executive >> > reached switch to multitasking mode? >> >> _System_state_Is_before_multitasking() > > Thanks, great that is what I have been looking for. > >> > This has impact to think about correct locking in functions >> > which are required to be used during startup when there is >> > no concurrent execution but mutexes support and memory initialization >> > is not finished yet but the same functions can be used later >> > when scheduler is running for further update of system state. >> > >> > More complete analysis and context in previous communication. >> >> I read prior discussion and had no problems, but Sebastian's concern >> should be addressed whether other ARM targets are correct or not. > > His (correct) concern has been about SMP. > But I think that need of locking has been eliminated by my previous commit. > There is another reason against locking by IRQ disable or spinlock. > If we consider update of pagetables at runtime where some real time tasks > run then if scheduler is blocked but change in large part of address space > then we can consider this as almost unbound latency source. > > So I vote for no locking at this level at all and mutex based locking > (skipped if part of initialization and _System_state_Is_before_multitasking) > at higher level when concurrent use need arises - for example allocation > of virtual address space for mmap or something similar. > This seems reasonable to me. I expect to eventually add some (limited) capabilities in this direction but I have not finished any (mental) design. > Best wishes, > > Pavel > > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
FYI - RSB tools and binutils 2.27
Hi Just a note that I am testing updating the binutils version to this now. Is there a gcc bump needed also? --joel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: FYI - RSB tools and binutils 2.27
Sebastian has more than once suggested we bump to gcc6 snapshot On Thu, Aug 25, 2016 at 3:27 PM, Joel Sherrill wrote: > Hi > > Just a note that I am testing updating the binutils version to this now. > > Is there a gcc bump needed also? > > --joel > > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: FYI - RSB tools and binutils 2.27
P.S. you may like to see if there is a recent newlib snapshot available or request one. On Thu, Aug 25, 2016 at 3:29 PM, Gedare Bloom wrote: > Sebastian has more than once suggested we bump to gcc6 snapshot > > On Thu, Aug 25, 2016 at 3:27 PM, Joel Sherrill wrote: >> Hi >> >> Just a note that I am testing updating the binutils version to this now. >> >> Is there a gcc bump needed also? >> >> --joel >> >> ___ >> devel mailing list >> devel@rtems.org >> http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH v2 2/2] libbsp/arm: Fix the local interrupt mask disable/enable calls.
On Thu, Aug 25, 2016 at 6:56 AM, Pavel Pisa wrote: > Hello Chris and others, > > I would like to remind Chris's patches (top-post to highlight important the > first) > > [PATCH v2 1/2] arm/cortex-a: Fix cache flush/invalidate after u-boot. > [PATCH v2 2/2] libbsp/arm: Fix the local interrupt mask disable/enable > calls. > > I consider fix of Zynq (all arm-a9mpcore-start) boot > through U-boot as important. But discussion has vanished. > > From my point of view, changes should/could be committed > as they are. I consider locking in this place as unimportant > in actual state (see my previous analysis in the thread) so > the second patch can even replace rtems_interrupt_disable by comment > > - rtems_interrupt_disable(level); > + /* FIXME: if concurrent update of same area is considered locking hat to > be added */ > > or even remove lines alltogether. The real need for locking > has been eliminated by my previous patch > > bsps/arm: do not disable MMU during translation table management operations. > > because set_translation_table_entries() manipulated with global core state > before. > It disabled cache and after update re-enabled it. Interleaving parallel > execution > of this sequence would lead to errors for sure. As I have analyzed, that > sequence has > been probably broken for SMP at all because invalidation complete cache > (only realizable by set and way on ARMv7) can be implemented without > broadcast to snoop > subsystem on some cores so only reliable way is to ask all CPUs by IPI to > stop, > then run complete cache flush on each core one by one. But that is not case > for now, > so locking is not required except for case of contention for given region and > this > has to be solved somewhere else. > > So at the end, I suggest to remove locking alltogether there. > > There has been left my question unanswered > > Is there some defined function/way to check if RTEMS executive > reached switch to multitasking mode? > _System_state_Is_before_multitasking() > This has impact to think about correct locking in functions > which are required to be used during startup when there is > no concurrent execution but mutexes support and memory initialization > is not finished yet but the same functions can be used later > when scheduler is running for further update of system state. > > More complete analysis and context in previous communication. > I read prior discussion and had no problems, but Sebastian's concern should be addressed whether other ARM targets are correct or not. > Best wishes, > > Pavel > > > On Tuesday 16 of August 2016 15:28:42 Pavel Pisa wrote: >> Hello Chris and Sebastian, >> >> On Tuesday 16 of August 2016 07:55:57 Sebastian Huber wrote: >> > On 16/08/16 07:45, Chris Johns wrote: >> > > --- >> > > c/src/lib/libbsp/arm/shared/arm-cp15-set-ttb-entries.c | 4 ++-- >> > > 1 file changed, 2 insertions(+), 2 deletions(-) >> > > >> > > diff --git a/c/src/lib/libbsp/arm/shared/arm-cp15-set-ttb-entries.c >> > > b/c/src/lib/libbsp/arm/shared/arm-cp15-set-ttb-entries.c index >> > > f650009..cfad45f 100644 >> > > --- a/c/src/lib/libbsp/arm/shared/arm-cp15-set-ttb-entries.c >> > > +++ b/c/src/lib/libbsp/arm/shared/arm-cp15-set-ttb-entries.c >> > > @@ -88,10 +88,10 @@ uint32_t arm_cp15_set_translation_table_entries( >> > > rtems_interrupt_level level; >> > > uint32_t section_flags_of_first_entry; >> > > >> > > - rtems_interrupt_disable(level); >> > > + rtems_interrupt_local_disable(level); >> > > section_flags_of_first_entry = >> > > set_translation_table_entries(begin, end, section_flags); >> > > - rtems_interrupt_enable(level); >> > > + rtems_interrupt_local_enable(level); >> > > >> > > return section_flags_of_first_entry; >> > > } >> > >> > We should only change this if this is known to work on SMP. >> >> My analysis for this concrete case, >> >> 1) RTEMS uses same MMU table for all CPUs. >> 2) inner set_translation_table_entries() ensures that change >>is visible to all CPUs >> 3) when arm_cp15_set_translation_table_entries() is called for range >>which is not (yet) accessed by other CPU(s) then the function should >>not cause any breakage >> 4) when change is requested for same range in parallel/twice from multiple >>threads or even CPUs then it is indication of some more serious problem >>in upper layers >> 5) if the update of mapping is requested for some range from cached to >>uncached for example then it is not enough to protect >>arm_cp15_set_translation_table_entries() alone. Protection >>of necessary cache flush and invalidation is required in addition. >> >> >> So generally, there is almost no difference between case when there is >> no protection or weak protection by rtems_interrupt_local_disable(). >> May it be that there can be some difference if operation >> ttb [i] = addr | section_flags; >> is translated by multiple memory accesses by C compiler (highly >> improbable). >>
Re: [PATCH v2 2/2] libbsp/arm: Fix the local interrupt mask disable/enable calls.
Hi Pavel, I am sorry about the delay. I have been on other things and then I was out with a pesky flue virus for the past week. On 26/08/2016 03:47, Pavel Pisa wrote: Hello Gedare, On Thursday 25 of August 2016 17:32:09 Gedare Bloom wrote: On Thu, Aug 25, 2016 at 6:56 AM, Pavel Pisa wrote: Is there some defined function/way to check if RTEMS executive reached switch to multitasking mode? _System_state_Is_before_multitasking() Thanks, great that is what I have been looking for. This has impact to think about correct locking in functions which are required to be used during startup when there is no concurrent execution but mutexes support and memory initialization is not finished yet but the same functions can be used later when scheduler is running for further update of system state. More complete analysis and context in previous communication. I read prior discussion and had no problems, but Sebastian's concern should be addressed whether other ARM targets are correct or not. His (correct) concern has been about SMP. But I think that need of locking has been eliminated by my previous commit. There is another reason against locking by IRQ disable or spinlock. If we consider update of pagetables at runtime where some real time tasks run then if scheduler is blocked but change in large part of address space then we can consider this as almost unbound latency source. So I vote for no locking at this level at all and mutex based locking (skipped if part of initialization and _System_state_Is_before_multitasking) at higher level when concurrent use need arises - for example allocation of virtual address space for mmap or something similar. Great. I was hoping you would provide a clear decision. I agree. I will remove the interrupt mask and push the change. Thanks for posts and the detail. It is really valuable. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] DMA : Added DMA API for Raspberrypi
Hello Mudit Jain, I have tried to test the DMA API code I have setup temporary branch on my RTEMS tests repo https://github.com/ppisa/rtems/tree/rtems-rpi-devel-dma-test I have applied patches extracted from your GitHub repository Re: [PATCH] Mailbox : Extending functionality https://github.com/ppisa/rtems/commit/640071d0e16f0a29019e09c0308a364373b4b0e1 with changes in alignment and padding which I have described in review [PATCH] DMA : Added DMA API for Raspberrypi https://github.com/ppisa/rtems/commit/d1f1ed30f918789b3ed91771ab743c7a1e6bf649 I have added missing defines to c/src/lib/libbsp/arm/raspberrypi/include/irq.h which has been probably lost during your rebasing to master. Without these code cannot compile. My patches arm/raspberrypi: DMA API: correct obvious errors https://github.com/ppisa/rtems/commit/ec34b48b9b87462276f93ab07f7522b84c1819bd Correct your code to at least initialization call suceed arm/raspberrypi: DMA API: ensure that channel is enabled when it is configured. https://github.com/ppisa/rtems/commit/ec34b48b9b87462276f93ab07f7522b84c1819bd Because even after above correction I have not observed channel activity, I have added code to ensure that channel is enabled in a global enable register arm/raspberrypi: DMA API: add simple memory to memory transfer test https://github.com/ppisa/rtems/commit/6c7d9463c83ee2d084a88235dbdaabd32b60b1a0 Quite dirty test integrated into RTEMS samples ticker application to check if DMA API works. System does not crash/stuck during testing, operations returns success status but even after more ticks there data do not appear in destination position albeit DMA request 0 should be permanently assigned according to the manual so data should be copied. rpi_dma_init ... rpi_dma_init 0 rpi_dma_allocate ... rpi_dma_allocate 0 rpi_dma_setup_src ... rpi_dma_setup_src 0 rpi_dma_setup_dst ... rpi_dma_setup_dst 0 rpi_dma_setup_intr ... rpi_dma_setup_intr 0 rpi_dma_start ... rpi_dma_start 0 dma test result 11>00 22>00 33>00 44>00 55>00 66>00 77>00 88>00 simple mem2mem DMA test has FAILED It is important that at least some functional tests run to prove that code development heads in the right direction. Please, check if I use API intended way and try to help us to make code more acceptable for mainline. We need to declare the state for project evaluation forms. See see remarks inlined in the following DMA patch On Saturday 20 of August 2016 17:33:18 Mudit Jain wrote: > Brief API Description > > rpi_dma_init -> Initializes the channel structure > and its members for that particular channel, gets > the physical address of the control block structure > and installs the interrupt handler. > > rpi_dma_allocate -> Allocates the channel if it is > not busy > > rpi_dma_setup_dst & rpi_dma_setup_src -> These setup > src and dst parameters like dreq, width. Basically they > configure the info section of the control block structure > of that particular channel. > > rpi_dma_setup_intr -> These will assign the handler > function for channel interrupt. This basically again > updates the channel structure with that function. > Note : rpi_dma_intr is the callback function for the > interrupt controller and calls this function internally. > > rpi_dma_start -> Here you provide the virtual address, > the channel to be used and the width. Internally, it > converts the address to physical address and configures > the control block for that channel. > It flushes and invalidates the cache and writes the physical > address of the control block to a particular register > corresponding to the channel. > > rpi_dma_free -> Frees the channel > --- > c/src/lib/libbsp/arm/raspberrypi/Makefile.am | 4 + > c/src/lib/libbsp/arm/raspberrypi/include/dma.h | 200 > c/src/lib/libbsp/arm/raspberrypi/misc/dma.c| 618 > + 3 files changed, 822 insertions(+) > create mode 100644 c/src/lib/libbsp/arm/raspberrypi/include/dma.h > create mode 100644 c/src/lib/libbsp/arm/raspberrypi/misc/dma.c > > diff --git a/c/src/lib/libbsp/arm/raspberrypi/Makefile.am > b/c/src/lib/libbsp/arm/raspberrypi/Makefile.am index 4b111ad..5b0e92e > 100644 > --- a/c/src/lib/libbsp/arm/raspberrypi/Makefile.am > +++ b/c/src/lib/libbsp/arm/raspberrypi/Makefile.am > @@ -51,6 +51,7 @@ include_bsp_HEADERS += include/rpi-gpio.h > include_bsp_HEADERS += include/i2c.h > include_bsp_HEADERS += include/spi.h > include_bsp_HEADERS += include/mailbox.h > +include_bsp_HEADERS += include/dma.h > include_bsp_HEADERS += include/vc.h > include_bsp_HEADERS += include/rpi-fb.h > include_bsp_HEADERS += console/fbcons.h > @@ -124,6 +125,9 @@ libbsp_a_SOURCES += console/fb.c > libbsp_a_SOURCES += console/fbcons.c > libbsp_a_SOURCES += console/outch.c > > +# DMA > +libbsp_a_SOURCES += misc/dma.c > + > # Mailbox > libbsp_a_SOURCES += misc/mailbox.c > > diff --git a/c/src/lib/libbsp/a
