Re: SPI with DMA on SAME70

[Simon Filgis]

Dear all,

I started to follow up this topic.

Found that one in sam_hsmci.c:

/* There is some unresolved issue with the SAMV7 DMA.  TX DMA is currently
 * disabled.
 */


#undef  HSCMI_NORXDMA  /* Define to disable RX DMA */
*#define HSCMI_NOTXDMA1 /* Define to disable TX DMA */*


That fits my (and Michael Lenc's) experience that DMA peripheral to memory
works. Memory to the peripheral seems broken though.

I will therefore debug *sam_xdmax.c*. Even if I find some odd comments on
DMA timeouts in sam_spi.c.

If anybody has a better idea, or remembers details ;), please give feedback.

BR,

Simon

--
Hard- and Softwaredevelopment Consultant
Ingenieurbüro-Filgis
USt-IdNr.: DE305343278


On Tue, Feb 8, 2022 at 11:52 AM Simon Filgis 
wrote:

> Dear all,
>
> I'm using ST7789.c in combination with lvgl-lib.
>
> The bottleneck to the display is the SPI communication. But even if I
> increase the SPI frequency to 24MHz, it does not get faster. This is
> because of constant delay between the bytes.
>
> I guessed that this can be improved using DMA. But that does not seem to
> work out of the box. In the SPI TX callback the result of the DMA transfer
> is -4. The transfer is not executed.
>
> Can anybody give me a hint on what to do?
>
> Best regards,
>
> Simon
>
> --
> Hard- and Softwaredevelopment Consultant
> Ingenieurbüro-Filgis
> USt-IdNr.: DE305343278
>

Re: Graduation?

[Nathan Hartman]

On Sat, Feb 12, 2022 at 2:32 AM 张铎(Duo Zhang)  wrote:
>
> It depends. We need to start a discuss thread on the incubator-general
> mailing list to see if IPMC members have any concerns.

Hi all,

I suggest we go ahead and start that thread. Does anyone need more time first?

Cheers,
Nathan

Re: Graduation?

[Brennan Ashton]

I really think we need to address the existing feedback from the last two
releases before we go asking for more.

We also need to go through the process of a release without the WIP
disclaimer which should also solicit some of the remaining feedback.

--Brennan

On Mon, Feb 14, 2022, 9:00 AM Nathan Hartman 
wrote:

> On Sat, Feb 12, 2022 at 2:32 AM 张铎(Duo Zhang) 
> wrote:
> >
> > It depends. We need to start a discuss thread on the incubator-general
> > mailing list to see if IPMC members have any concerns.
>
> Hi all,
>
> I suggest we go ahead and start that thread. Does anyone need more time
> first?
>
> Cheers,
> Nathan
>

[DISCUSS]: Self merge and Single company/organization merge gating

[David Sidrane]

I am opening this discussion to widen the audience for feedback on the
rules for merging. The original interexchange was in [1]



1 ) Given the geographical and time differences should we consider that
once a review with approval* has been done the PR’s author can merge it?



2) Should we consider requiring more than one organization/company to
approve a PR before it is merged.



Background:



If only one company does a review, that can lead to undo influence as noted
as the "The Enemies"
 of
the INVIOLABLES [2]:

“Focus on the values of the organization, not the values of the Open Source
project. Need to support both.”

*The change would define PR approval as requiring a review/approval from
more than the members of one company or organization.





I am in favor of both these changes.



David



[1]
https://github.com/apache/incubator-nuttx/pull/5320#issuecomment-1020379240

[2] https://github.com/apache/incubator-nuttx/blob/master/INVIOLABLES.md

Re: Graduation?

[Alin Jerpelea]

my last commits will arrive this week then if there are no other concerns I
would suggest that someone runs FOSSID and verifies independently that I
did not miss anything.

If we all agree that the feedback was addressed I can start a new release
process without the WIP disclaimer

Best regards
Alin


On Mon, 14 Feb 2022, 18:05 Brennan Ashton, 
wrote:

> I really think we need to address the existing feedback from the last two
> releases before we go asking for more.
>
> We also need to go through the process of a release without the WIP
> disclaimer which should also solicit some of the remaining feedback.
>
> --Brennan
>
> On Mon, Feb 14, 2022, 9:00 AM Nathan Hartman 
> wrote:
>
> > On Sat, Feb 12, 2022 at 2:32 AM 张铎(Duo Zhang) 
> > wrote:
> > >
> > > It depends. We need to start a discuss thread on the incubator-general
> > > mailing list to see if IPMC members have any concerns.
> >
> > Hi all,
> >
> > I suggest we go ahead and start that thread. Does anyone need more time
> > first?
> >
> > Cheers,
> > Nathan
> >
>

[DISCUSS] Default state of NDEBUG

[David Sidrane]

PR 5399 adds an Kconfig option for NDEBUG. The salient discussion begins at
[2] there are mixed positions and reasoning. xiaoxiang781216 asked me to
raise a discussion on this.



The reasoning for the Default state of to be NDEBUG (n) hence undefined so
that assert() enabled is the following:



1)  It follows the standard understanding of NDEBUG



  The standard for standard library from [3]



 The definition of the macro assert depends on another macro,
NDEBUG, *which is not defined* by the standard library.





  2) We have DEBUGASSERT for use in the OS. I believe this was an
intentional separation on Greg’s part. We have asked for is input.



In a NuttX "Release" build DEGUASSERT is off (all debug is off to show off
the build size).

I should still be able to build the app code with assert() and not have to
use a Kconfig to enable it.

How would you prefer it to be defined?



   1. Defaulted ON – assert() is a No OP
   2. Defaulted OFF assert() is enabled.
   3. Left to a command line setting from build system



David



[1] https://github.com/apache/incubator-nuttx/pull/5399



[2]
https://github.com/apache/incubator-nuttx/pull/5399#issuecomment-1029387606

[3]
https://en.cppreference.com/w/c/error/assert#:~:text=If%20NDEBUG%20is%20defined%20as,the%20source%20code%20where%20%3Cassert.&text=If%20NDEBUG%20is%20not%20defined,output%20and%20calls%20abort()
.

Re: [DISCUSS]: Self merge and Single company/organization merge gating

[Brennan Ashton]

On Mon, Feb 14, 2022, 9:28 AM David Sidrane  wrote:

> I am opening this discussion to widen the audience for feedback on the
> rules for merging. The original interexchange was in [1]
>
>
>
> 1 ) Given the geographical and time differences should we consider that
> once a review with approval* has been done the PR’s author can merge it?
>
>
>
> 2) Should we consider requiring more than one organization/company to
> approve a PR before it is merged.
>
>
>
> Background:
>
>
>
> If only one company does a review, that can lead to undo influence as noted
> as the "The Enemies"
>  of
> the INVIOLABLES [2]:
>
> “Focus on the values of the organization, not the values of the Open Source
> project. Need to support both.”
>
> *The change would define PR approval as requiring a review/approval from
> more than the members of one company or organization.
>
>
>
>
>
> I am in favor of both these changes.
>
>
>
> David
>
>
>
> [1]
> https://github.com/apache/incubator-nuttx/pull/5320#issuecomment-1020379240
>
> [2] https://github.com/apache/incubator-nuttx/blob/master/INVIOLABLES.md



I am generally opposed to both of these. It is quite rare that we need a
crazy fast merge turn around on a PR. And if something is approved and
straight up broken in master that needs to get in then I think forgiveness
can be used to self merge.


I also generally do not have a big issue about people from the same company
reviewing and merging. I could see the arguments for shared code but then I
think we are nitpicking.   I prefer the velocity with a few oops that can
be reverted along the way if needed.  There is also parts of the code base
where the best people to review are on the same company.


I think most of the concerns here are best addressed not by process but
increasing the number of contributors who can participate. (more committers
and PPMC)


--Brennan