Hi Eugen, On Fri, Jan 15, 2021 at 1:34 PM <eugen.hris...@microchip.com> wrote:
> On 15.01.2021 06:02, Padmarao Begari wrote: > > Hi Eugen, > > > > On Thu, Jan 14, 2021 at 4:50 PM <eugen.hris...@microchip.com > > <mailto:eugen.hris...@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.hris...@microchip.com > > <mailto:eugen.hris...@microchip.com>> > > > *Sent:* Wednesday, December 16, 2020 12:24 PM > > > *To:* anup.pa...@wdc.com <mailto:anup.pa...@wdc.com> > > <anup.pa...@wdc.com <mailto:anup.pa...@wdc.com>>; > > bin.m...@windriver.com <mailto:bin.m...@windriver.com> > > > <bin.m...@windriver.com <mailto:bin.m...@windriver.com>>; > > Padmarao Begari - I30397 > > > <padmarao.beg...@microchip.com > > <mailto:padmarao.beg...@microchip.com>> > > > *Cc:* Claudiu Beznea - M18063 <claudiu.bez...@microchip.com > > <mailto:claudiu.bez...@microchip.com>>; > > > joe.hershber...@ni.com <mailto:joe.hershber...@ni.com> > > <joe.hershber...@ni.com <mailto:joe.hershber...@ni.com>>; > > u-boot@lists.denx.de <mailto:u-boot@lists.denx.de> > > > <u-boot@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.bez...@microchip.com > > <mailto:claudiu.bez...@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__ */ > > >> > > > > > > >
