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 ? 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__ */ > >> > > >
