- 27 Nov, 2020 1 commit
-
-
Jinyang He authored
Apply_r_mips_26_rel() relocates instructions like j, jal and etc. These instructions consist of 6bits function field and 26bits address field. The value of target_addr as follows, ================================================================= | high 4bits | low 28bits | ================================================================= |the high 4bits of this PC | the low 26bits of instructions << 2| ================================================================= Thus, loc_orig and log_new both need high 4bits rather than high 6bits. Signed-off-by:
Jinyang He <hejinyang@loongson.cn> Signed-off-by:
Thomas Bogendoerfer <tsbogend@alpha.franken.de>
-
- 19 Nov, 2020 6 commits
-
-
Tiezhu Yang authored
As the user manual and code comment said, Loongson-3 has 4-scache banks, while Loongson-2K has only 2 banks, so we should multiply the number of scache banks, this multiply operation should be done by c->scache.sets instead of scache_size, otherwise we will get the wrong scache size when execute lscpu. For example, the scache size should be 8192K instead of 2048K on the Loongson 3A3000 and 3A4000 platform, we can see the related info in the following boot message: [loongson@linux ~]$ dmesg | grep "Unified secondary cache" [ 0.000000] Unified secondary cache 8192kB 16-way, linesize 64 bytes. [ 4.061909] Unified secondary cache 8192kB 16-way, linesize 64 bytes. [ 4.125629] Unified secondary cache 8192kB 16-way, linesize 64 bytes. [ 4.188379] Unified secondary cache 8192kB 16-way, linesize 64 bytes. E.g. without this patch: [loongson@linux ~]$ cat /sys/devices/system/cpu/cpu*/cache/index2/size 2048K 2048K 2048K 2048K [loongson@linux ~]$ lscpu | grep "L2 cache" L2 cache: 2048K With this patch: [loongson@linux ~]$ cat /sys/devices/system/cpu/cpu*/cache/index2/size 8192K 8192K 8192K 8192K [loongson@linux ~]$ lscpu | grep "L2 cache" L2 cache: 8192K Signed-off-by:
Tiezhu Yang <yangtiezhu@loongson.cn> Signed-off-by:
-
Tiezhu Yang authored
Since commit 02cf2119 ("Cleanup the mess in cpu_cache_init."), cpu_has_6k_cache and cpu_has_8k_cache have no user, r6k_cache_init() and r8k_cache_init() are not defined for over 15 years, just remove them. Signed-off-by:
-
Thomas Bogendoerfer authored
Protection map difference between RIXI and non RIXI cpus is _PAGE_NO_EXEC and _PAGE_NO_READ usage. Both already take care of cpu_has_rixi while setting up the page bits. So we just need one setup of protection map and can drop the now unused (and broken for RIXI) PAGE_* defines. Signed-off-by: -
Thomas Bogendoerfer authored
Introduce helper macro to make lines shorter. Signed-off-by: -
Thomas Bogendoerfer authored
MIPS protection bits are setup during runtime so using defines like PAGE_SHARED ignores this runtime changes. Using vm_get_page_prot to get correct page protection fixes this. Signed-off-by: -
Thomas Bogendoerfer authored
MIPS protection bits are setup during runtime so using defines like PAGE_READONLY ignores these runtime changes. To fix this we simply use the page protection of the setup vma. Signed-off-by:
-
- 17 Nov, 2020 14 commits
-
-
Álvaro Fernández Rojas authored
BCM6318 SoCs have a reset controller for certain components. Signed-off-by:
Álvaro Fernández Rojas <noltari@gmail.com> Acked-by:
Florian Fainelli <F.fainelli@gmail.com> Reviewed-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Álvaro Fernández Rojas authored
BCM63268 SoCs have a reset controller for certain components. Signed-off-by:
-
Álvaro Fernández Rojas authored
BCM6368 SoCs have a reset controller for certain components. Signed-off-by:
-
Álvaro Fernández Rojas authored
BCM6362 SoCs have a reset controller for certain components. Signed-off-by:
-
Álvaro Fernández Rojas authored
BCM6358 SoCs have a reset controller for certain components. Signed-off-by:
-
Álvaro Fernández Rojas authored
BCM6328 SoCs have a reset controller for certain components. Signed-off-by:
-
Álvaro Fernández Rojas authored
Add support for resetting blocks through the Linux reset controller subsystem for BCM63xx SoCs. Signed-off-by:
Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by:
-
Álvaro Fernández Rojas authored
Add device tree binding documentation for BCM6345 reset controller. Signed-off-by:
-
Álvaro Fernández Rojas authored
This allows to add reset controllers support. Signed-off-by:
-
周琰杰 (Zhou Yanjie) authored
1.Refresh defconfig of CI20 to support OTG and RNG. 2.Refresh defconfig of CU1000-Neo to support OTG/RNG/OST/SC16IS752. 3.Refresh defconfig of CU1830-Neo to support OTG/DTRNG/OST/SC16IS752. Tested-by:
周正 (Zhou Zheng) <sernia.zhou@foxmail.com> Tested by: H. Nikolaus Schaller <hns@goldelico.com> # CI20/jz4780 Signed-off-by:
周琰杰 (Zhou Yanjie) <zhouyanjie@wanyeetech.com> Signed-off-by:
-
周琰杰 (Zhou Yanjie) authored
1.Add OTG/OTG PHY/RNG nodes for JZ4780, CGU/OTG nodes for CI20. 2.Add OTG/OTG PHY/RNG/OST nodes for X1000, SSI/CGU/OST/OTG/SC16IS752 nodes for CU1000-Neo. 3.Add OTG/OTG PHY/DTRNG/OST nodes for X1830, SSI/CGU/OST/OTG/SC16IS752 nodes for CU1830-Neo. Tested-by:
-
Thomas Bogendoerfer authored
Pull in mips-fixes to get memblock fix. - fix bug preventing booting on several platforms - fix for build error, when modules need has_transparent_hugepage - fix for memleak in alchemy clk setup Signed-off-by: -
Zhang Qilong authored
If the clk_register fails, we should free h before function returns to prevent memleak. Fixes: 47440229 ("MIPS: Alchemy: clock framework integration of onchip clocks") Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
Zhang Qilong <zhangqilong3@huawei.com> Signed-off-by:
-
Thomas Bogendoerfer authored
The loop over all memblocks works with PFNs and not physical addresses, so we need for_each_mem_pfn_range(). Fixes: b10d6bca ("arch, drivers: replace for_each_membock() with for_each_mem_range()") Signed-off-by:
Mike Rapoport <rppt@linux.ibm.com> Reviewed-by:
Serge Semin <fancer.lancer@gmail.com>
-
- 12 Nov, 2020 16 commits
-
-
Alexander Lobakin authored
Commit c3e2ee65 ("MIPS: generic: Add support for zboot") added support for self-extracting images to Generic MIPS. However, the intended way to boot Generic MIPS kernels is using FIT Images and UHI boot protocol, but currently there's no way to make self-extracting FIT Image (only legacy uzImages). Add a target for this named "vmlinuz.itb", which will consist of vmlinuz.bin and selected DT blobs. It will allow to have the advantages of both UHI and self-extracting images. Signed-off-by:
Alexander Lobakin <alobakin@pm.me> Acked-by:
Paul Cercueil <paul@crapouillou.net> Signed-off-by:
-
Alexander Lobakin authored
1. All final targets like vmlinuz.{bin,ecoff,srec} etc. should reside in $(objtree)/arch/mips/boot, not in the root $(objtree) directory. The only file that should be left there is vmlinuz, similar to other architectures. 2. Add all the targets to $(targets) variable, so they'll be properly accounted by Kbuild. This also allows to remove redundant $(clean-files) (which were missing uzImage BTW). 3. Prefix all targets with $(obj)/$(objtree), depending on their locations. Misc: fix the identation of the 'STRIP' quiet message. Signed-off-by: -
Gregory CLEMENT authored
Add a device trees and FIT image support for the Microsemi Serval SoC which belongs to same family of the Ocelot SoC. It is based on the work of Lars Povlsen <lars.povlsen@microchip.com>. Signed-off-by:
Gregory CLEMENT <gregory.clement@bootlin.com> Acked-by:
Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by:
-
Gregory CLEMENT authored
Add a device trees and FIT image support for the Microsemi Jaguar2 SoC which belongs to same family of the Ocelot SoC. It is based on the work of Lars Povlsen <lars.povlsen@microchip.com>. Signed-off-by:
-
Gregory CLEMENT authored
Luton now has already an u-boot port so let's build FIT images. Signed-off-by:
-
Gregory CLEMENT authored
Add a device tree for the Microsemi Luton PCB091 evaluation board. It is based on the work of Lars Povlsen <lars.povlsen@microchip.com>. Signed-off-by:
-
Gregory CLEMENT authored
Add a device tree include file for the Microsemi Luton SoC which belongs to same family of the Ocelot SoC. It is based on the work of Lars Povlsen <lars.povlsen@microchip.com>. Signed-off-by:
-
Gregory CLEMENT authored
Ocelots is supported by the generic MIPS build so make it clears that LEGACY_BOARD_OCELOT is only needed for legacy boards which didn't have bootloader supporting device tree. Signed-off-by:
-
Gregory CLEMENT authored
Ocelot belongs to a family of SoC named the VCore III. In order to add these new Soc, use the new symbol SOC_VCOREIII instead of a one dedicated to Ocelot. In order to avoid regression on driver building, the MSCC_OCELOT configuration symbol is kept until the driver will be converted. Signed-off-by:
-
Gregory CLEMENT authored
Serval and Jaguar2 SoCs belong to the same family as Ocelot and Luton. Acked-by:
-
Gregory CLEMENT authored
Luton SoC belongs to the same family as Ocelot. Acked-by:
-
Necip Fazil Yildiran authored
When BCM47XX_BCMA is enabled and BCMA_DRIVER_PCI is disabled, it results in the following Kbuild warning: WARNING: unmet direct dependencies detected for BCMA_DRIVER_PCI_HOSTMODE Depends on [n]: MIPS [=y] && BCMA_DRIVER_PCI [=n] && PCI_DRIVERS_LEGACY [=y] && BCMA [=y]=y Selected by [y]: - BCM47XX_BCMA [=y] && BCM47XX [=y] && PCI [=y] The reason is that BCM47XX_BCMA selects BCMA_DRIVER_PCI_HOSTMODE without depending on or selecting BCMA_DRIVER_PCI while BCMA_DRIVER_PCI_HOSTMODE depends on BCMA_DRIVER_PCI. This can also fail building the kernel. Honor the kconfig dependency to remove unmet direct dependency warnings and avoid any potential build failures. Fixes: c1d1c5d4 ("bcm47xx: add support for bcma bus") Link: https://bugzilla.kernel.org/show_bug.cgi?id=209879Signed-off-by:
Necip Fazil Yildiran <fazilyildiran@gmail.com> Signed-off-by:
-
Necip Fazil Yildiran authored
When BCM47XX_SSB is enabled and SSB_PCIHOST is disabled, it results in the following Kbuild warning: WARNING: unmet direct dependencies detected for SSB_B43_PCI_BRIDGE Depends on [n]: SSB [=y] && SSB_PCIHOST [=n] Selected by [y]: - BCM47XX_SSB [=y] && BCM47XX [=y] && PCI [=y] The reason is that BCM47XX_SSB selects SSB_B43_PCI_BRIDGE without depending on or selecting SSB_PCIHOST while SSB_B43_PCI_BRIDGE depends on SSB_PCIHOST. This can also fail building the kernel as demonstrated in a bug report. Honor the kconfig dependency to remove unmet direct dependency warnings and avoid any potential build failures. Link: https://bugzilla.kernel.org/show_bug.cgi?id=210051Signed-off-by:
-
Serge Semin authored
In accordance with the Generic EHCI/OHCI bindings the corresponding node name is suppose to comply with the Generic USB HCD DT schema, which requires the USB nodes to have the name acceptable by the regexp: "^usb(@.*)?" . Make sure the "generic-ehci" and "generic-ohci"-compatible nodes are correctly named. Signed-off-by:
Serge Semin <Sergey.Semin@baikalelectronics.ru> Acked-by:
Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by:
-
Serge Semin authored
In accordance with the Generic EHCI/OHCI bindings the corresponding node name is suppose to comply with the Generic USB HCD DT schema, which requires the USB nodes to have the name acceptable by the regexp: "^usb(@.*)?" . Make sure the "generic-ehci" and "generic-ohci"-compatible nodes are correctly named. Signed-off-by:
-
Serge Semin authored
In accordance with the Generic EHCI/OHCI bindings the corresponding node name is suppose to comply with the Generic USB HCD DT schema, which requires the USB nodes to have the name acceptable by the regexp: "^usb(@.*)?" . Make sure the "generic-ehci" and "generic-ohci"-compatible nodes are correctly named. Signed-off-by:
-
- 11 Nov, 2020 3 commits
-
-
Tiezhu Yang authored
In play_dead function, the whole 64-bit PC mailbox was used as a indicator to determine if the master core had written boot jump information. However, after we introduced CSR mailsend, the hardware will not guarante an atomic write for the 64-bit PC mailbox. Thus we have to use the lower 32-bit which is written at the last as the jump indicator instead. Signed-off-by:
Lu Zeng <zenglu@loongson.cn> Signed-off-by:
Jun Yi <yijun@loongson.cn> Signed-off-by:
-
Tiezhu Yang authored
Loongson 3A4000+ CPU has per-core Mail_Send register to send mail, there is no need to maintain register address of each core and node, just simply specify cpu number. Signed-off-by:
Jianmin Lv <lvjianmin@loongson.cn> Signed-off-by:
-
Tiezhu Yang authored
In the current code, for example, core 1 sets Core[0, 1, 2, 3]_IPI_Enalbe register and core 2, 3 do the same thing on the 1-way Loongson64 platform, this is not necessary. Set IPI_Enable register per core by itself to avoid duplicate operations and make the logic more clear. Signed-off-by:
-
