Message ID | 20200521003443.11385-1-Sergey.Semin@baikalelectronics.ru |
---|---|
Headers | show |
Series | mips: Prepare MIPS-arch code for Baikal-T1 SoC support | expand |
On Thu, May 21, 2020 at 03:34:29AM +0300, Serge Semin wrote: > [nip] > > This patchset is rebased and tested on the mainline Linux kernel 5.7-rc4: > base-commit: 0e698dfa2822 ("Linux 5.7-rc4") > tag: v5.7-rc4 Thomas, Please note that this patchset is based on the Linux 5.7-rc4 tree (it most likely will get cleanly applied on rc6 as well), while mips-next is still at rc1. Due to that the patchset fails to be applied on mips-next. I think it would be better first to merge the last Linux tree into the mips-next, then try to merge this patchset in. Should you have any problem after that, please let me know. I'll resend the patchset being rebased on top of the new mips-next tree. -Sergey
On Thu, May 21, 2020 at 03:34:37AM +0300, Serge Semin wrote: > Indeed according to the MIPS32 Privileged Resource Architecgture the MAAR > pair register address field either takes [12:31] bits for non-XPA systems > and [12:55] otherwise. In any case the current address mask is just > wrong for 64-bit and 32-bits XPA chips. So lets extend it to 59-bits > of physical address value. This shall cover the 64-bits architecture and > systems with XPA enabled, and won't cause any problem for non-XPA 32-bit > systems, since address values exceeding the architecture specific MAAR > mask will be just truncated with setting zeros in the unsupported upper > bits. > > Co-developed-by: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru> > Signed-off-by: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru> > Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> > Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de> > Cc: Paul Burton <paulburton@kernel.org> > Cc: Ralf Baechle <ralf@linux-mips.org> > Cc: Arnd Bergmann <arnd@arndb.de> > Cc: Rob Herring <robh+dt@kernel.org> > Cc: devicetree@vger.kernel.org > > --- > > Changelog v3: > - In accordance with MIPS32/64 Privileged Resource Architecture Extend > the MAAR Addr mask to value [12:55] instead of P5600-specific [12:35]. > --- > arch/mips/include/asm/mipsregs.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) applied to mips-next. Thomas.
On Thu, May 21, 2020 at 03:42:17AM +0300, Serge Semin wrote: > On Thu, May 21, 2020 at 03:34:29AM +0300, Serge Semin wrote: > > > > This patchset is rebased and tested on the mainline Linux kernel 5.7-rc4: > > base-commit: 0e698dfa2822 ("Linux 5.7-rc4") > > tag: v5.7-rc4 > > Thomas, > Please note that this patchset is based on the Linux 5.7-rc4 tree (it most likely > will get cleanly applied on rc6 as well), while mips-next is still at rc1. Due > to that the patchset fails to be applied on mips-next. I think it would be > better first to merge the last Linux tree into the mips-next, then try to merge > this patchset in. Should you have any problem after that, please let me know. > I'll resend the patchset being rebased on top of the new mips-next tree. no, that's not how it works. Please rebase your patches on top of mips-next. Thank you. Thomas.
On Thu, May 21, 2020 at 9:18 AM Thomas Bogendoerfer <tsbogend@alpha.franken.de> wrote: > On Thu, May 21, 2020 at 03:42:17AM +0300, Serge Semin wrote: > > On Thu, May 21, 2020 at 03:34:29AM +0300, Serge Semin wrote: > > > > > > This patchset is rebased and tested on the mainline Linux kernel 5.7-rc4: > > > base-commit: 0e698dfa2822 ("Linux 5.7-rc4") > > > tag: v5.7-rc4 > > > > Thomas, > > Please note that this patchset is based on the Linux 5.7-rc4 tree (it most likely > > will get cleanly applied on rc6 as well), while mips-next is still at rc1. Due > > to that the patchset fails to be applied on mips-next. I think it would be > > better first to merge the last Linux tree into the mips-next, then try to merge > > this patchset in. Should you have any problem after that, please let me know. > > I'll resend the patchset being rebased on top of the new mips-next tree. > > no, that's not how it works. Please rebase your patches on top of > mips-next. Thank you. Right, backmerges should generally be avoided. However if something between rc1 and rc4 is required to make Baikal-T1 work, rebasing it to rc1 would make it non-bisectable, which is also bad. Serge, are you aware of something in -rc4 that is needed as a dependency? Arnd
Hello! On 21.05.2020 3:34, Serge Semin wrote: > CDMM may be available not only MIPS R2 architectures, but also in ^ on -re, it's singular > newer MIPS R5 chips. For instance our P5600 chip has one. Lets mark > the CDMM bus being supported for that MIPS arch too. > > Co-developed-by: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru> > Signed-off-by: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru> > Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> > Reviewed-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de> > Cc: Paul Burton <paulburton@kernel.org> > Cc: Ralf Baechle <ralf@linux-mips.org> > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> > Cc: Arnd Bergmann <arnd@arndb.de> > Cc: Olof Johansson <olof@lixom.net> > Cc: Rob Herring <robh+dt@kernel.org> > Cc: linux-mips@vger.kernel.org > Cc: devicetree@vger.kernel.org [...] MBR, Sergei
On Thu, May 21, 2020 at 01:25:21PM +0300, Sergei Shtylyov wrote: > Hello! > > On 21.05.2020 3:34, Serge Semin wrote: > > > CDMM may be available not only MIPS R2 architectures, but also in > ^ on -re, it's singular Thanks, Sergey. Got it. I'll fix it in the next revision. > > > newer MIPS R5 chips. For instance our P5600 chip has one. Lets mark Probably also: ^ Let's Right? -Sergey > > the CDMM bus being supported for that MIPS arch too. > > > > Co-developed-by: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru> > > Signed-off-by: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru> > > Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> > > Reviewed-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de> > > Cc: Paul Burton <paulburton@kernel.org> > > Cc: Ralf Baechle <ralf@linux-mips.org> > > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> > > Cc: Arnd Bergmann <arnd@arndb.de> > > Cc: Olof Johansson <olof@lixom.net> > > Cc: Rob Herring <robh+dt@kernel.org> > > Cc: linux-mips@vger.kernel.org > > Cc: devicetree@vger.kernel.org > [...] > > MBR, Sergei
Hello Arnd. On Thu, May 21, 2020 at 09:30:08AM +0200, Arnd Bergmann wrote: > On Thu, May 21, 2020 at 9:18 AM Thomas Bogendoerfer > <tsbogend@alpha.franken.de> wrote: > > On Thu, May 21, 2020 at 03:42:17AM +0300, Serge Semin wrote: > > > On Thu, May 21, 2020 at 03:34:29AM +0300, Serge Semin wrote: > > > > > > > > This patchset is rebased and tested on the mainline Linux kernel 5.7-rc4: > > > > base-commit: 0e698dfa2822 ("Linux 5.7-rc4") > > > > tag: v5.7-rc4 > > > > > > Thomas, > > > Please note that this patchset is based on the Linux 5.7-rc4 tree (it most likely > > > will get cleanly applied on rc6 as well), while mips-next is still at rc1. Due > > > to that the patchset fails to be applied on mips-next. I think it would be > > > better first to merge the last Linux tree into the mips-next, then try to merge > > > this patchset in. Should you have any problem after that, please let me know. > > > I'll resend the patchset being rebased on top of the new mips-next tree. > > > > no, that's not how it works. Please rebase your patches on top of > > mips-next. Thank you. > > Right, backmerges should generally be avoided. However if something > between rc1 and rc4 is required to make Baikal-T1 work, rebasing it to > rc1 would make it non-bisectable, which is also bad. > > Serge, are you aware of something in -rc4 that is needed as a dependency? Not I am aware of. Regarding my suggestion. It's not like I was going to delegate a work or something. It's that a merge conflict is connected with MODULE_PROC_FAMILY macro being moved to a dedicated file vermagic.h file: 62d0fd591db1 ("arch: split MODULE_ARCH_VERMAGIC definitions out to <asm/vermagic.h>"). Since I've already fixed it, Thomas wouldn't need to worry about the problem anymore if he first merged the kernel master branch in first, which he would have done anyway eventually. Since it's not an option and as you said backmerges should be avoided, then I'll rebase the patchset onto the mips-next, and then resend. -Sergey > > Arnd
On Thu, May 21, 2020 at 09:14:57AM +0200, Thomas Bogendoerfer wrote: > On Thu, May 21, 2020 at 03:42:17AM +0300, Serge Semin wrote: > > On Thu, May 21, 2020 at 03:34:29AM +0300, Serge Semin wrote: > > > > > > This patchset is rebased and tested on the mainline Linux kernel 5.7-rc4: > > > base-commit: 0e698dfa2822 ("Linux 5.7-rc4") > > > tag: v5.7-rc4 > > > > Thomas, > > Please note that this patchset is based on the Linux 5.7-rc4 tree (it most likely > > will get cleanly applied on rc6 as well), while mips-next is still at rc1. Due > > to that the patchset fails to be applied on mips-next. I think it would be > > better first to merge the last Linux tree into the mips-next, then try to merge > > this patchset in. Should you have any problem after that, please let me know. > > I'll resend the patchset being rebased on top of the new mips-next tree. > > no, that's not how it works. Please rebase your patches on top of > mips-next. Thank you. Ok. I'll do it shortly and discard the commit 37353ec964e8 ("mips: MAAR: Use more precise address mask") since you have already applied it on to the mips-next branch. -Sergey > > Thomas. > > -- > Crap can work. Given enough thrust pigs will fly, but it's not necessarily a > good idea. [ RFC1925, 2.3 ]
On 21.05.2020 15:58, Serge Semin wrote: >>> CDMM may be available not only MIPS R2 architectures, but also in >> ^ on -re, it's singular > > Thanks, Sergey. Got it. I'll fix it in the next revision. > >>> newer MIPS R5 chips. For instance our P5600 chip has one. Lets mark > Probably also: ^ Let's > Right? Yes. Thanks for replying. :-) > > -Sergey > >>> the CDMM bus being supported for that MIPS arch too. > >>> >>> Co-developed-by: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru> >>> Signed-off-by: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru> >>> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> >>> Reviewed-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de> >>> Cc: Paul Burton <paulburton@kernel.org> >>> Cc: Ralf Baechle <ralf@linux-mips.org> >>> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> >>> Cc: Arnd Bergmann <arnd@arndb.de> >>> Cc: Olof Johansson <olof@lixom.net> >>> Cc: Rob Herring <robh+dt@kernel.org> >>> Cc: linux-mips@vger.kernel.org >>> Cc: devicetree@vger.kernel.org >> [...] MBR, Sergei