[PATCH 1/6] net: macb: use dummy descriptor for RBQP
Padmarao Begari
padmarao.b at gmail.com
Fri Jan 15 13:26:59 CET 2021
Hi Eugen,
On Fri, Jan 15, 2021 at 1:34 PM <Eugen.Hristev at microchip.com> wrote:
> On 15.01.2021 06:02, Padmarao Begari wrote:
> > Hi Eugen,
> >
> > On Thu, Jan 14, 2021 at 4:50 PM <Eugen.Hristev at microchip.com
> > <mailto:Eugen.Hristev at 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 ?
>
>
My mistake, misunderstood your question,
Yes the fdt relocation has nothing to do with the macb.
We both are adding a member into struct mac_config, a dummy descriptor
for RBQP and my changes are both 32-bit and 64-bit DMA.
Regards
Padmarao
> 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 at microchip.com
> > <mailto:Eugen.Hristev at microchip.com>>
> > > *Sent:* Wednesday, December 16, 2020 12:24 PM
> > > *To:* anup.patel at wdc.com <mailto:anup.patel at wdc.com>
> > <anup.patel at wdc.com <mailto:anup.patel at wdc.com>>;
> > bin.meng at windriver.com <mailto:bin.meng at windriver.com>
> > > <bin.meng at windriver.com <mailto:bin.meng at windriver.com>>;
> > Padmarao Begari - I30397
> > > <Padmarao.Begari at microchip.com
> > <mailto:Padmarao.Begari at microchip.com>>
> > > *Cc:* Claudiu Beznea - M18063 <Claudiu.Beznea at microchip.com
> > <mailto:Claudiu.Beznea at microchip.com>>;
> > > joe.hershberger at ni.com <mailto:joe.hershberger at ni.com>
> > <joe.hershberger at ni.com <mailto:joe.hershberger at ni.com>>;
> > u-boot at lists.denx.de <mailto:u-boot at lists.denx.de>
> > > <u-boot at lists.denx.de <mailto:u-boot at 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 at microchip.com
> > <mailto:claudiu.beznea at 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__ */
> > >>
> > >
> >
>
>
More information about the U-Boot
mailing list