- 29 Apr, 2022 5 commits
-
-
Arnd Bergmann authored
Moving the plat-omap files triggered a sparse warning for omap1 and omap2 that is now in a different file from before. Found some more sparse warnings here that I address by making sure the declaration is visible to both the caller and the callee, or they are static mach-omap1/fb.c:33:17: warning: symbol 'omap_fb_resources' was not declared. Should it be static? mach-omap1/timer32k.c:215:12: warning: symbol 'omap_init_clocksource_32k' was not declared. Should it be static? mach-omap1/i2c.c:36:12: warning: symbol 'omap_i2c_add_bus' was not declared. Should it be static? mach-omap1/i2c.c:115:12: warning: symbol 'omap_register_i2c_bus_cmdline' was not declared. Should it be static? mach-omap1/i2c.c:140:12: warning: symbol 'omap_register_i2c_bus' was not declared. Should it be static? mach-omap2/dma.c:180:34: warning: symbol 'dma_plat_info' was not declared. Should it be static? mach-omap2/omap4-common.c:116:6: warning: symbol 'omap_interconnect_sync' was not declared. Should it be static? mach-omap2/omap-iommu.c:113:5: warning: symbol 'omap_iommu_set_pwrdm_constraint' was not declared. Should it be static? Reported-by:
kernel test robot <lkp@intel.com> Reviewed-by:
Tony Lindgren <tony@atomide.com> Tested-by:
Arnd Bergmann <arnd@arndb.de>
-
Arnd Bergmann authored
Moving sram code from plat-omap got the attention of the kernel test robot. I found a few more places with related warnings because the sram references are a mix of kernel pointers and __iomem pointers: mach-omap1/sram-init.c:56:17: warning: cast removes address space '__iomem' of expression mach-omap1/board-ams-delta.c:667:9: warning: incorrect type in argument 1 (different base types) mach-omap2/sram.c:78:17: warning: cast removes address space '__iomem' of expression mach-omap2/omap4-common.c:142:27: warning: incorrect type in assignment (different address spaces) mach-omap2/omap4-common.c:142:27: expected void [noderef] __iomem *static [toplevel] sram_sync mach-omap2/omap4-common.c:142:27: got void * mach-omap2/pm34xx.c:113:45: warning: incorrect type in argument 1 (different address spaces) mach-omap2/pm34xx.c:113:45: expected void [noderef] __iomem *save_regs mach-omap2/pm34xx.c:113:45: got void *extern [addressable] [toplevel] omap3_secure_ram_storage There is no good solution here, as sram is a bit special in this regard. Change the annotations to at least shut up the warnings. Reported-by:
-
Arnd Bergmann authored
Two of the remaining four headers are never used, the other two are only used inside of the platform code. Move them next to the files that include them and remove the Makefile trick that adds the include path. Acked-by:
Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by:
-
Arnd Bergmann authored
The files in include/mach are only used from mach/davinci, so they are no longer needed in the traditional location. Move them to arch/arm/mach-davinci/ and drop the logic for the special include path. The mach/uncompress.h file is not used at all and can just be removed. Signed-off-by: -
Arnd Bergmann authored
mach/serial.h is only included from arch/arm/mach-omap2/serial.h, and the other two files are unused and empty. Remove the directory by relocating the contents of mach/serial.h and dropping all other references. Reviewed-by:
-
- 22 Apr, 2022 21 commits
-
-
Arnd Bergmann authored
The ap_init_early function is defined a global but has no declaration, so it produces a warning: arch/arm/mach-versatile/integrator_ap.c:148:13: warning: no previous prototype for 'ap_init_early' [-Wmissing-prototypes The function could be made 'static' but since it's empty, we can just remove it. Reported-by:
-
Arnd Bergmann authored
Merge branch 'omap1/multiplatform-prep' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc into arm/multiplatform This is the full series for converting OMAP1 to multiplatform, rebased from my 2019 attempt to do the same thing. The soc tree contains simpler patches to do the same for iop32x, ixp4xx, ep93xx and s3c24xx, which means we are getting closer to completing this for all ARMv5 platforms (I have patches for PXA, which is the last one remaining). Janusz already tested the branch separately and did the missing work for the common-clk conversion after my previous approach was broken. Aaro found one regression during additional testing, this is fixed now. Acked-by:
Aaro Koskinen <aaro.koskinen@iki.fi> Signed-off-by:
-
Arnd Bergmann authored
The include directory is gone, so stop passing the command line flag. Reported-by:
-
Tony Lindgren authored
Janusz has been active with improving and testing the omap1 SoC support and has been recently working on adding support for the common clock framework. Signed-off-by:
Janusz Krzysztofik <jmkrzyszt@gmail.com> Acked-by:
-
Julia Lawall authored
Various spelling mistakes in comments. Detected with the help of Coccinelle. Signed-off-by:
Julia Lawall <Julia.Lawall@inria.fr> Reviewed-by:
-
Julia Lawall authored
Various spelling mistakes in comments. Detected with the help of Coccinelle. Signed-off-by:
-
Janusz Krzysztofik authored
There are some OMAP1 clock code bits that have no effect: - crystal_type variable is set to 0 but never changed, then crystal_type == 2 condition is never true and ck_ref.rate never set to 19200000, - clk->ops->allow_idle() is called from omap_clk_enable_autoidle_all() but that op is not configured for any clock, then the function does nothing and the op field is not needed, - ENABLE_ON_INIT flag is set for some clocks but is never checked by any code, then not needed. Drop that code. Signed-off-by:
-
Janusz Krzysztofik authored
The code of OMAP1 clocks contains quite a few unused elements: - functions and function like macros never called: clk_reparent(), recalculate_root_clocks(), clk_enable_init_clocks(), omap_clk_get_by_name(), omap_clk_disable_autoidle_all(), __clk_get_parent(clk), __clk_get_rate(), - unused structure fields: - clkops: .find_idlest(), .find_companion(), .deny_idle(), - clk: .src_offset, as well as .clkdm -- no longer present but still mentioned in comments, - definitions of unused flags: INVERT_ENABLE, CLOCK_CLKOUTX2, - definitions of unused data types: struct clk_functions, - prototypes of functions with no implementation: clk_init(), omap1_watchdog_recalc(). - declarations of never defined global variables: clkops_dummy. Drop them. Signed-off-by: -
Janusz Krzysztofik authored
Since its introduction to the mainline kernel, omap1_uart_recalc() helper makes incorrect use of clk->enable_bit as a ready to use bitmap mask while it only provides the bit number. Fix it. Signed-off-by:
-
Janusz Krzysztofik authored
Commit ef772f2e ("ARM: OMAP: Fix CONFIG_DEBUG_LL") was supposed to fix low level debugging, most possibly by early enabling UART clocks. The fix actually introduced early reset of most bits of MOD_CONF_CTRL_0 register, with the exception of UART1 and UART2 clock related bits which were set high. However, UART1 clock bit can play different roles on different OMAP1 variants. On OMAP1610 it enables the clock as intended, but on OMAP1510 it switches the clock rate from 12 to 48 MHz. Even worth, for UART2 the bit changes its clock rate also on OMAP1610. As a result, UART rates set by a bootloader can be unintentionally changed early on kernel boot and low level debugging broken, not fixed. Besides, reset of all other bits was not justified. Don't touch register bits not related to UART clocks. Also, don't touch the bit of UART2 clock. Make sure UART1 and UART3 are enabled early on relevant OMAP1610 machine types while preserving bootloader UART clock rates on others. Signed-off-by:
-
Janusz Krzysztofik authored
In preparation for conversion of OMAP1 clocks to common clock framework, identify arch/arm/mach-omap1 local users of those clocks and update them to call clk_prepare_enable/clk_disable_unprepare() instead of just clk_enable/disable(), as required by CCF implementation of clock API. Signed-off-by:
-
Arnd Bergmann authored
In a multiplatform randconfig kernel, one can have CONFIG_ARCH_OMAP1 enabled, but none of the specific SoCs. This leads to some build issues as the code is not meant to deal with this configuration at the moment: arch/arm/mach-omap1/io.c:86:20: error: unused function 'omap1_map_common_io' [-Werror,-Wunused-function] arch/arm/mach-omap1/pm.h:113:2: error: "Power management for this processor not implemented yet" [-Werror,-W#warnings] Use the same trick as on OMAP2 and guard the actual compilation of platform code with another Makefile ifdef check based on an option that depends on having at least one SoC enabled. The io.c file still needs to get compiled to allow building device drivers with a dependency on CONFIG_ARCH_OMAP1. Acked-by:
-
Arnd Bergmann authored
Most of the header files are no longer referenced from outside arch/arm/mach-omap1, so move them all to that place directly and change their users to use the new location. The exceptions are: - mach/compress.h is used by the core architecture code - mach/serial.h is used by mach/compress.h The mach/memory.h is empty and gets removed in the process, avoiding the need for CONFIG_NEED_MACH_MEMORY_H. Acked-by:
-
Arnd Bergmann authored
The ISA I/O space handling in omap_cf is incompatible with PCI drivers in a multiplatform kernel, and requires a custom mach/io.h. Change the driver to use pci_remap_iospace() like PCI drivers do, so the generic ioport access can work across platforms. To actually use that code, we have to select CONFIG_PCI here. Acked-by:
-
Arnd Bergmann authored
The address range 0xfee00000-0xfeffffff is used for PCI and PCMCIA I/O port mappings, but OMAP1 has its static mappings there as well. Move the OMAP1 addresses a little higher to avoid crashing at boot. Acked-by:
-
Arnd Bergmann authored
The last file in this directory is gone, and it can be removed as well. Acked-by:
-
Arnd Bergmann authored
The sram initialization code is the only shared omap1/2 code that is not a standalone driver, but it is very short. Having two copies of this code means some duplication of the sources, but actually saves object code size as it can be inlined better. Acked-by:
-
Arnd Bergmann authored
All the remaining features in here are either omap1 or omap2plus specific, so move them into the respective Kconfig files. Acked-by:
-
Arnd Bergmann authored
Most of the interface functions in plat/dma.c are only used from the USB driver, which is practically OMAP1 specific, except for compile testing. The omap_get_plat_info(), omap_request_dma() and omap_free_dma() functions are never called on omap2 because of runtime checks. Acked-by:
-
Arnd Bergmann authored
No part of plat-omap/dma.c is called on omap2 any more, so anything omap2 specific in here can simply be removed. Acked-by:
-
Arnd Bergmann authored
The legacy interface for omap-dma is only used on OMAP1, and the same is true for the non-DT case. Make both of these conditional on CONFIG_ARCH_OMAP1 being set to simplify the dependency. The non-OMAP stub functions in include/linux/omap-dma.h are note needed any more either now, because they are only called on OMAP1. Acked-by:
Vinod Koul <vkoul@kernel.org> Signed-off-by:
-
- 21 Apr, 2022 14 commits
-
-
Krzysztof Kozlowski authored
The Samsung S3C24xx and S3C64xx platforms are very old designs. S3C2416 was introduced in 2008 and S3C6410 in 2009/2010. They are not widely available anymore - out-of-stock on FriendlyArm (one of manufacturers of boards) and only few specialist stores still offer them for quite a high price. The community around these platforms was not very active, so I suspect no one really uses them anymore. Maintenance takes precious time so there is little sense in keeping them alive if there are no real users. Let's mark all S3C24xx and S3C64xx platforms as deprecated and mention possible removal in after 2022 for the first and 2024 for the lattere. The deprecation message will be as text in Kconfig, build message (not a warning though) and runtime print error. If there are any users, they might respond and postpone the removal. Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Acked-by:
Heiko Stuebner <heiko@sntech.de> Acked-by:
Tomasz Figa <tomasz.figa@gmail.com> Acked-by:
-
Arnd Bergmann authored
Most of the plat-omap/dma.c code is specific to the USB driver. Hide that code when it is not in use, to make it clearer which parts are actually still required. Acked-by:
-
Arnd Bergmann authored
It has been impossible to select this driver for six years without anyone noticing, so just kill it completely. Fixes: 54ea18e8 ("ARM: OMAP2+: Remove board file for H4") Acked-by:
-
Arnd Bergmann authored
omap2 stopped using this code with commit 8d39ff3d ("ARM: OMAP2+: Remove unused legacy code for timer"), so just move it to mach-omap1 now, along with the other half of that driver. Acked-by:
-
Arnd Bergmann authored
The innovator board needs a special case for its phy control. Move the corresponding code into the board file and out of the common code by adding another callback. Acked-by:
Felipe Balbi <felipe.balbi@linux.intel.com> Acked-by:
-
Arnd Bergmann authored
The omap-keypad driver currently relies on including mach/memory.h implicitly, but that won't happen once omap1 is converted to CONFIG_ARCH_MULTIPLATFORM. Include the required header explicitly. Acked-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Acked-by:
-
Arnd Bergmann authored
As a preparation for cleaning up the omap1 headers, start including linux/soc/ti/omap1-soc.h directly so we can keep calling cpu_is_omap1510(). Acked-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by:
-
Arnd Bergmann authored
As a preparation for future omap1 multiplatform support, stop using mach/hardware.h and instead include the omap1-io.h for low-level register access to MOD_CONF_CTRL_1. Acked-by:
Daniel Lezcano <daniel.lezcano@linaro.org> Acked-by:
-
Arnd Bergmann authored
The omap usb drivers still rely on mach/*.h headers that are explicitly or implicitly included, but all the required definitions are now in include/linux/soc/ti/, so use those instead and allow compile-testing on other architectures. Acked-by:
-
Arnd Bergmann authored
All the headers we actually need are now in include/linux/soc, so use those versions instead and allow compile-testing on other architectures. Acked-by:
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Acked-by:
-
Arnd Bergmann authored
There is only one board that uses the omap_cf driver, so moving the chipselect configuration there does not lead to code duplication but avoids the use of mach/tc.h in drivers. Acked-by:
-
Arnd Bergmann authored
The driver has always had a FIXME about this, and it seems like this trivial code move avoids a mach header inclusion, so just do it. With that out of the way, and the header file inclusions changed to global files, the driver can also be compile-tested on other platforms. Acked-by:
Mark Brown <broonie@kernel.org> Acked-by:
-
Arnd Bergmann authored
There are three remaining header files that are used by omap1 specific device drivers: - mach/soc.h provides cpu_is_omapXXX abstractions - mach/hardware.h provides omap_read/omap_write functions and physical addresses - mach/mux.h provides an omap specific pinctrl abstraction This is generally not how we do platform abstractions today, and it would be good to completely get rid of these in favor of passing information through platform devices and the pinctrl subsystem. However, given that nobody is working on that, just move it one step forward by splitting out the header files that are used by drivers today from the machine headers that are only used internally. Acked-by:
-
Arnd Bergmann authored
The register definitions in this header are used in at least four different places, with little hope of completely cleaning that up. Split up the file into a portion that becomes a linux-wide header under include/linux/soc/ti/, and the parts that are actually only needed by board files. Acked-by:
-
