[PATCH 1/6] net: macb: use dummy descriptor for RBQP

[Eugen.Hristev at microchip.com <Eugen.Hristev@microchip.com>]

On 15.01.2021 06:02, Padmarao Begari wrote:
> Hi Eugen,
> 
> On Thu, Jan 14, 2021 at 4:50 PM <Eugen.Hristev@microchip.com 
> <mailto:Eugen.Hristev@microchip.com>> wrote:
> 
>     On 17.12.2020 07:22, Padmarao Begari - I30397 wrote:
>      > Hi Eugen,
>      >
>      > This series of patches break my side of work(patches) so you need to
>      > create patches after my patches are going into master branch
>     because my
>      > patches are already reviewed and tested.
> 
>     Hi,
> 
>     Could you please detail the breakage ?
> 
> 
> The breakage is the fdt relocation disabled in the board environment 
> variables so I have removed it and enabled fdt relocation in PATCH v9.

Maybe you misunderstand my question. I was asking about the sama7g5 macb 
series, which you claimed that breaks your current patch set.
This is a link to the series :
https://patchwork.ozlabs.org/project/uboot/list/?series=218367

Since you claimed that this series breaks your series, I am asking what 
exactly is the breakage. How does the fdt relocation in your board 
environment has anything to do with macb and these patches which are not 
applied ?

Thanks,
Eugen

> 
> Regards
> Padmarao
> 
>     I saw a pull request with your patches that was NAK-ed, if your two
>     macb
>     patches are tested and reviewed I could apply them to the atmel tree as
>     well and send them, if your PR is delayed. But we are interested to
>     have
>     our sama7g5 series pushed as well, so we need to know if it's ok on
>     your
>     side, and what is wrong with the sama7g5 series.
> 
>     Thanks!
>     Eugen
>      >
>      > Regards
>      > Padmarao
>      >
>     ------------------------------------------------------------------------
>      > *From:* Eugen Hristev - M18282 <Eugen.Hristev@microchip.com
>     <mailto:Eugen.Hristev@microchip.com>>
>      > *Sent:* Wednesday, December 16, 2020 12:24 PM
>      > *To:* anup.patel at wdc.com <mailto:anup.patel@wdc.com>
>     <anup.patel at wdc.com <mailto:anup.patel@wdc.com>>;
>     bin.meng at windriver.com <mailto:bin.meng@windriver.com>
>      > <bin.meng at windriver.com <mailto:bin.meng@windriver.com>>;
>     Padmarao Begari - I30397
>      > <Padmarao.Begari@microchip.com
>     <mailto:Padmarao.Begari@microchip.com>>
>      > *Cc:* Claudiu Beznea - M18063 <Claudiu.Beznea@microchip.com
>     <mailto:Claudiu.Beznea@microchip.com>>;
>      > joe.hershberger at ni.com <mailto:joe.hershberger@ni.com>
>     <joe.hershberger at ni.com <mailto:joe.hershberger@ni.com>>;
>     u-boot at lists.denx.de <mailto:u-boot@lists.denx.de>
>      > <u-boot at lists.denx.de <mailto:u-boot@lists.denx.de>>
>      > *Subject:* Re: [PATCH 1/6] net: macb: use dummy descriptor for RBQP
>      > On 03.12.2020 11:25, Claudiu Beznea wrote:
>      >> In case of multiple queues on RX side the queue scheduler
>      >> will try to use all the available configured queues (with
>      >> descriptors having TX_USED bit cleared). If at least one RBQP
>      >> points to a descriptor with a valid used bit configuration then
>      >> the reception may block as this may point to any memory. To avoid
>      >> this scenario all the queues (except queue zero) were disabled by
>      >> setting DMA descriptors with used bit set on proper RBQP. The driver
>      >> anyway uses only queue 0 for TX/RX.
>      >>
>      >> Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com
>     <mailto:claudiu.beznea@microchip.com>>
>      >> ---
>      >
>      > Hi Anup, Bin, Padmarao,
>      >
>      > I noticed on the mailing list that you have been actively working and
>      > testing the Macb driver on various platforms, we have this series
>      > outstanding and I want to make sure that it does not break
>     anything on
>      > your side, so it would be appreciated if you could have a look or
>     test
>      > it before it goes into master branch.
>      >
>      > Thanks !
>      > Eugen
>      >
>      >
>      >>?? drivers/net/macb.c | 4 +++-
>      >>?? drivers/net/macb.h | 2 ++
>      >>?? 2 files changed, 5 insertions(+), 1 deletion(-)
>      >>
>      >> diff --git a/drivers/net/macb.c b/drivers/net/macb.c
>      >> index b80a259ff757..836eb85ec96a 100644
>      >> --- a/drivers/net/macb.c
>      >> +++ b/drivers/net/macb.c
>      >> @@ -732,8 +732,10 @@ static int gmac_init_multi_queues(struct
>     macb_device *macb)
>      >>??????? flush_dcache_range(macb->dummy_desc_dma,
>     macb->dummy_desc_dma +
>      >>??????????????????????? ALIGN(MACB_TX_DUMMY_DMA_DESC_SIZE,
>     PKTALIGN));
>      >>
>      >> -???? for (i = 1; i < num_queues; i++)
>      >> +???? for (i = 1; i < num_queues; i++) {
>      >>??????????????? gem_writel_queue_TBQP(macb, macb->dummy_desc_dma,
>     i - 1);
>      >> +???????????? gem_writel_queue_RBQP(macb, macb->dummy_desc_dma,
>     i - 1);
>      >> +???? }
>      >>
>      >>??????? return 0;
>      >>?? }
>      >> diff --git a/drivers/net/macb.h b/drivers/net/macb.h
>      >> index 9b16383eba46..28c7fe306883 100644
>      >> --- a/drivers/net/macb.h
>      >> +++ b/drivers/net/macb.h
>      >> @@ -768,5 +768,7 @@
>      >>?? #define GEM_RX_CSUM_CHECKED_MASK??????????? 2
>      >>?? #define gem_writel_queue_TBQP(port, value, queue_num)?????? \
>      >>??????? writel((value), (port)->regs + GEM_TBQP(queue_num))
>      >> +#define gem_writel_queue_RBQP(port, value, queue_num)??????? \
>      >> +???? writel((value), (port)->regs + GEM_RBQP(queue_num))
>      >>
>      >>?? #endif /* __DRIVERS_MACB_H__ */
>      >>
>      >
>