- 20 Aug, 2020 11 commits
-
-
Arnd Bergmann authored
Rather than have the cpufreq drivers touch include the common headers to get the constants, add a small indirection. This is still not the proper way that would do this through the common clk API, but it lets us kill off the header file usage. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Acked-by:
Viresh Kumar <viresh.kumar@linaro.org> Link: https://lore.kernel.org/r/20200806182059.2431-37-krzk@kernel.org [krzk: Rebase and fix -Wold-style-definition] Signed-off-by:
Krzysztof Kozlowski <krzk@kernel.org>
-
Arnd Bergmann authored
There are two identical copies of the s3c2412_cpufreq_setrefresh function: a static one in the cpufreq driver and a global version in iotiming-s3c2412.c. As the function requires the use of a hardcoded register address from a header that we want to not be visible to drivers, just move the existing global function and add a declaration in one of the cpufreq header files. Signed-off-by:
-
Arnd Bergmann authored
The cpufreq drivers are split between the machine directory and the drivers/cpufreq directory. In order to share header files after we convert s3c to multiplatform, those headers have to live in a different global location. Move them to linux/soc/samsung/ in lack of a better place. Signed-off-by:
-
Arnd Bergmann authored
Each of the cpufreq drivers uses a fixed set of register bits, copy those definitions into the drivers to avoid including mach/regs-clock.h. [krzk: Fix build by copying also S3C2410_LOCKTIME] Signed-off-by:
-
Arnd Bergmann authored
The s3c2410fb driver is too deeply intertwined with the s3c24xx platform code. Change it in a way that avoids the use of platform header files but having all interface data in a platform_data header, and the private register definitions next to the driver itself. One ugly bit here is that the driver pokes directly into gpio registers, which are owned by another driver. Passing the mapped addresses in platform_data is somewhat suboptimal, but it is a small improvement over the previous version. Signed-off-by:
-
Arnd Bergmann authored
Once we move to sparse irqs, the irq_desc[] array is no longer accessible, so replace the two uses in bast-irq.c. The first one can use irq_to_desc(), the second one seems completely unneeded as we already have a pointer to the correct descriptor. Signed-off-by:
-
Arnd Bergmann authored
The IRQ_EINT0 constant is a platform detail that is defined in mach/irqs.h and not visible to drivers once that header is made private. Since the same calculation already happens in s3c24xx_set_fiq, just return the value from there. Signed-off-by:
Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20200806182059.2431-31-krzk@kernel.orgSigned-off-by:
-
Arnd Bergmann authored
Preparing for a later conversion to sparse IRQs, this ensures that the mach/irqs.h header is still visible in files that reference an IRQ number. Signed-off-by:
-
Arnd Bergmann authored
Rather than call the internal s3c_gpio_cfgall_range() function through a platform header, move the code into the set_power callback that is already exported by the board, and add a default implementation. In DT mode, the code already does not set the pin config, so nothing changes there. Signed-off-by:
Ulf Hansson <ulf.hansson@linaro.org> Link: https://lore.kernel.org/r/20200806182059.2431-29-krzk@kernel.org [krzk: Rebase and correct set_power in mach-h1940.c] Signed-off-by:
-
Arnd Bergmann authored
The s3c_gpio_cfgall_range() function is an internal interface of the samsung gpio driver and should not be called directly by drivers, so move the iis pin initialization into the boards. This means the pin configuration is only run once at early boot, rather than each time the driver binds, but the effect should be the same. Note that the s3c2412-i2s driver has no boards using it in mainline linux, the driver gets selected for the jive machine but is never instantiated. Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Acked-by:
-
Krzysztof Kozlowski authored
Merge tag 'samsung-platdrv-boards' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into next/soc-s3c-cleanup Pull Samsung S3C ASoC cleanup patches from Mark Brown. These patches are part of the entire cleanup series so all further work depends on them.
-
- 19 Aug, 2020 29 commits
-
-
Arnd Bergmann authored
The fiq handler needs access to some register definitions that should not be used directly by device drivers. Since this is closely related to the irqchip driver anyway, move it into the same place. Signed-off-by:
-
Arnd Bergmann authored
There are multiple drivers using the private adc interface. It seems unlikely that they would ever get converted to iio, so make the current state official by making the header file global. The s3c2410_ts driver needs a couple of register definitions as well. Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Acked-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Acked-by:
Sebastian Reichel <sre@kernel.org> Link: https://lore.kernel.org/r/20200806182059.2431-22-krzk@kernel.orgSigned-off-by:
-
Arnd Bergmann authored
It was a good idea to move it out at first, but the irqchip code is still tightly connected to the s3c24xx platform code and uses multiple internal header files, so just move it back for the time being to avoid those dependencies. Signed-off-by:
Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20200806182059.2431-21-krzk@kernel.orgSigned-off-by:
-
Arnd Bergmann authored
The file is mostly specific to the driver, the few bits that are actually used by the platform code get moved to mach/map.h instead. Signed-off-by:
-
Arnd Bergmann authored
This header is empty and conflicts with the s3c24xx version of the same file when we merge the two, so stop including it. Signed-off-by:
Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20200806182059.2431-19-krzk@kernel.orgSigned-off-by:
-
Arnd Bergmann authored
The plat-samsung directory and mach-s5pv210 can be build completely independently, so split the two Kconfig symbols CONFIG_PLAT_SAMSUNG and CONFIG_ARCH_S5PV210. Signed-off-by:
Thierry Reding <thierry.reding@gmail.com> Acked-by:
-
Arnd Bergmann authored
The pm save/restore code is fairly small, so in order to separate the s3c and s5p platforms, adding an s5p specific copy instead of sharing it is actually easier. Signed-off-by:
-
Arnd Bergmann authored
This is the only part of plat-samsung that is really shared between the s3c and s5p ports. Moving it to drivers/soc/ lets us make them completely independent. Signed-off-by:
-
Arnd Bergmann authored
The constant requires indirectly including a machine header file, but it's not actually used any more since commit 87b132bc ("ASoC: samsung: s3c24{xx,12}-i2s: port to use generic dmaengine API"), so remove it completely. Signed-off-by:
-
Arnd Bergmann authored
Avoid machine specific headers by using a gpio lookup table combined with a platform_driver for this board. Signed-off-by:
-
Arnd Bergmann authored
Avoid machine specific headers by using a gpio lookup table combined with a platform_driver for this board. Signed-off-by:
-
Arnd Bergmann authored
Avoid machine specific headers by using a gpio lookup table combined with a platform_driver for this board. Signed-off-by:
-
Arnd Bergmann authored
Now that no code in arch/arm is shared between mach-exynos and the others, make the split formal. Signed-off-by:
-
Arnd Bergmann authored
The only part of plat-samsung that is shared with arch-exynos is the CPU identification code. Having a separate exynos_cpu_id variable makes the two completely independent and is actually a bit less code in total. Signed-off-by:
-
Arnd Bergmann authored
Before we can separate plat-samsung from the individual platforms, this one has to get moved to a place where it remains accessible. Signed-off-by:
-
Arnd Bergmann authored
The pm-debug code is one of the few things shared between s3c24xx/s3c64xx and the newer s5pv210. In order to make s5pv210 independent of plat-samsung, change the common bits of this code to no longer reference the s3c specific bits. In particular, all the CPU checks need to be moved out of the common code into platform specific files. Signed-off-by:
-
Arnd Bergmann authored
On s3c24xx and s3c64xx, this is just a wrapper around s3c_pm_debug_init_uart(), but this function does not exist on s5pv210, which always uses an empty stub as CONFIG_SAMSUNG_ATAGS is normally not set. In a configuration that supports both s5pv210 and s3c64xx, we would always call the s3c64xx function, which is probably incorrect when running on s5pv210. Remove the function call completely on s5pv210 and skip the wrapper on s3c as a cleanup. As a side-effect, the s3c64xx behavior is now always the same, regardless of whether it is a DT-only configuration or both DT and ATAGS are supported for booting. Signed-off-by:
-
Arnd Bergmann authored
This file has not had any callers since linux-4.7, so stop building it. Fixes: 5901f4c2 ("ARM: EXYNOS: Remove SROM related register settings from mach-exynos") Signed-off-by:
-
Krzysztof Kozlowski authored
Remove unused 'udc' variable to fix compile warnings: drivers/usb/gadget/udc/s3c2410_udc.c: In function 's3c2410_udc_dequeue': drivers/usb/gadget/udc/s3c2410_udc.c:1268:22: warning: variable 'udc' set but not used [-Wunused-but-set-variable] Signed-off-by:Nathan Chancellor <natechancellor@gmail.com> Link: https://lore.kernel.org/r/20200731074122.6484-1-krzk@kernel.org
-
Arnd Bergmann authored
There is no real phy driver, so s3c-hsudc just pokes the registers itself. Improve this a little by making it a platform data callback like we do for gpios. There is only one board using this driver, and it's unlikely that another would be added, so this is a minimal workaround. Signed-off-by:
-
Arnd Bergmann authored
The resources are correctly initialized, so just use them instead of relying on hardcoded data from platform headers. Signed-off-by:
Felipe Balbi <balbi@kernel.org> Link: https://lore.kernel.org/r/20200806182059.2431-8-krzk@kernel.orgSigned-off-by:
-
Arnd Bergmann authored
s3c24xx has a custom implementation of the inb/outb family of I/O accessors, implementing both general register access and ISA I/O port through a multiplexer. As far as I can tell, the first case has never been needed, and certainly is not used now, as drivers only use inb/outb to actually driver ISA or PCI port I/O. Similarly, the special ISA support is limited to a single machine, the Simtec Electronics BAST (EB2410ITX) with its PC/104 expansion connector, all other machines could simply use the generic implementation from asm/io.h that expects a single memory-mapped address range for byte, word and dword access. As no other machines besides BAST actually selects CONFIG_ISA, this is likely not even necessary. As a cleanup, remove support for the non-ISA access from the helpers, and make the ISA access use the virtual address window that we use elsewhere for PCI I/O ports. In configurations without the BAST machine, this now falls back on the generic implementation from asm/io.h, but the mach/io.h header is still relied on to include a number of other header files implicitly. Signed-off-by:
-
Krzysztof Kozlowski authored
Passing pointers directly as platform data is fragile and undocumented. Better to create a platform data structure which explicitly documents what is passed to the driver. Suggested-by:
Tomasz Figa <tomasz.figa@gmail.com> Signed-off-by:
Stephen Boyd <sboyd@kernel.org> Link: https://lore.kernel.org/r/20200806182059.2431-6-krzk@kernel.org
-
Arnd Bergmann authored
The clk driver uses both a function call into an exported platform file and a direct register access to a hardcoded virtual address for accessing the MISCCR register, both become are a problem for a multiplatform kernel because of the header file dependency. Make this an indirect function call through platform data instead. Signed-off-by:
-
Arnd Bergmann authored
There are two functions in this file that are never called from anywhere else, so they should be static to allow the compiler to optimize it better and not pollute the global namespace. Signed-off-by:
-
Arnd Bergmann authored
The gpio controller names differ between s3c24xx and s3c64xx, and it seems that these all got the wrong names, using GPx instead of GPIOx. Fixes: d2951dfa ("mmc: s3cmci: Use the slot GPIO descriptor") Signed-off-by:
-
Krzysztof Kozlowski authored
Commit f6361c6b ("ARM: S3C24XX: remove separate restart code") removed usage of the watchdog reset platform code in favor of the Samsung SoC watchdog driver. However the latter was not selected thus S3C24xx platforms lost reset abilities. Cc: <stable@vger.kernel.org> Fixes: f6361c6b ("ARM: S3C24XX: remove separate restart code") Signed-off-by:
-
Krzysztof Kozlowski authored
Similarly to commit f6361c6b ("ARM: S3C24XX: remove separate restart code"), the platform watchdog reset code can be removed in favor of a generic watchdog driver which already handles reset. This allows removal of a bunch of machine code and fixes also W=1 compile warnings: arch/arm/plat-samsung/watchdog-reset.c:29:6: warning: no previous prototype for 'samsung_wdt_reset' [-Wmissing-prototypes] arch/arm/plat-samsung/watchdog-reset.c:69:13: warning: no previous prototype for 'samsung_wdt_reset_of_init' [-Wmissing-prototypes] arch/arm/plat-samsung/watchdog-reset.c:89:13: warning: no previous prototype for 'samsung_wdt_reset_init' [-Wmissing-prototypes] The generic watchdog-based system reset is not exactly the same as before. The previous method had a fallback to soft_restart() which now is gone. The commit also removes a FIXME note about calling s3c64xx_clk_init() inside s3c64xx_init_irq(). No one fixed this since long time and the note is not meaningful anymore because watchdog part is removed. Signed-off-by:
-
Krzysztof Kozlowski authored
A separate Kconfig option HAVE_S3C2410_WATCHDOG for Samsung SoCs is not really needed and the s3c24xx watchdog driver can depend on Samsung ARM architectures instead. The "HAVE_xxx_WATCHDOG" pattern of dependency is not popular and Samsung platforms are here exceptions. All others just depend on CONFIG_ARCH_xxx. This makes the code slightly smaller without any change in functionality. Signed-off-by:
-
