Re: [PATCH V2 63/63] clocksources: Switch back to the clksrc table
On 06/16/2016 11:27 PM, Daniel Lezcano wrote: > All the clocksource drivers's init function are now converted to return > an error code. CLOCKSOURCE_OF_DECLARE is no longer used as well as the > clksrc-of table. > > Let's convert back the names: > - CLOCKSOURCE_OF_DECLARE_RET => CLOCKSOURCE_OF_DECLARE > - clksrc-of-ret => clksrc-of > > Signed-off-by: Daniel Lezcano > --- > arch/arc/kernel/time.c| 6 +++--- > arch/arm/kernel/smp_twd.c | 6 +++--- > arch/microblaze/kernel/timer.c| 2 +- > arch/mips/ralink/cevt-rt3352.c| 2 +- > arch/nios2/kernel/time.c | 2 +- > drivers/clocksource/arm_arch_timer.c | 6 +++--- > drivers/clocksource/arm_global_timer.c| 2 +- > drivers/clocksource/armv7m_systick.c | 2 +- > drivers/clocksource/asm9260_timer.c | 2 +- > drivers/clocksource/bcm2835_timer.c | 2 +- > drivers/clocksource/bcm_kona_timer.c | 4 ++-- > drivers/clocksource/cadence_ttc_timer.c | 2 +- > drivers/clocksource/clksrc-dbx500-prcmu.c | 2 +- > drivers/clocksource/clksrc-probe.c| 14 -- > drivers/clocksource/clksrc_st_lpc.c | 2 +- > drivers/clocksource/clps711x-timer.c | 2 +- > drivers/clocksource/dw_apb_timer_of.c | 8 > drivers/clocksource/exynos_mct.c | 4 ++-- > drivers/clocksource/fsl_ftm_timer.c | 2 +- > drivers/clocksource/h8300_timer16.c | 2 +- > drivers/clocksource/h8300_timer8.c| 2 +- > drivers/clocksource/h8300_tpu.c | 2 +- > drivers/clocksource/meson6_timer.c| 2 +- > drivers/clocksource/mips-gic-timer.c | 2 +- > drivers/clocksource/moxart_timer.c| 2 +- > drivers/clocksource/mps2-timer.c | 2 +- > drivers/clocksource/mtk_timer.c | 2 +- > drivers/clocksource/mxs_timer.c | 2 +- > drivers/clocksource/nomadik-mtu.c | 2 +- > drivers/clocksource/pxa_timer.c | 2 +- > drivers/clocksource/qcom-timer.c | 4 ++-- > drivers/clocksource/rockchip_timer.c | 8 > drivers/clocksource/samsung_pwm_timer.c | 8 > drivers/clocksource/sun4i_timer.c | 2 +- > drivers/clocksource/tango_xtal.c | 2 +- > drivers/clocksource/tegra20_timer.c | 4 ++-- > drivers/clocksource/time-armada-370-xp.c | 6 +++--- > drivers/clocksource/time-efm32.c | 4 ++-- > drivers/clocksource/time-lpc32xx.c| 2 +- > drivers/clocksource/time-orion.c | 2 +- > drivers/clocksource/time-pistachio.c | 2 +- > drivers/clocksource/timer-atlas7.c| 2 +- > drivers/clocksource/timer-atmel-pit.c | 2 +- > drivers/clocksource/timer-atmel-st.c | 2 +- > drivers/clocksource/timer-digicolor.c | 2 +- > drivers/clocksource/timer-imx-gpt.c | 24 > drivers/clocksource/timer-integrator-ap.c | 2 +- > drivers/clocksource/timer-keystone.c | 2 +- > drivers/clocksource/timer-nps.c | 4 ++-- > drivers/clocksource/timer-oxnas-rps.c | 4 ++-- > drivers/clocksource/timer-prima2.c| 2 +- > drivers/clocksource/timer-sp804.c | 4 ++-- > drivers/clocksource/timer-stm32.c | 2 +- > drivers/clocksource/timer-sun5i.c | 4 ++-- > drivers/clocksource/timer-ti-32k.c| 2 +- > drivers/clocksource/timer-u300.c | 2 +- > drivers/clocksource/versatile.c | 4 ++-- > drivers/clocksource/vf_pit_timer.c| 2 +- > drivers/clocksource/vt8500_timer.c| 2 +- > drivers/clocksource/zevio-timer.c | 2 +- > include/asm-generic/vmlinux.lds.h | 2 -- > include/linux/clocksource.h | 5 + > 62 files changed, 98 insertions(+), 117 deletions(-) > [...] > diff --git a/drivers/clocksource/timer-oxnas-rps.c > b/drivers/clocksource/timer-oxnas-rps.c > index 0d99f40..bd887e2 100644 > --- a/drivers/clocksource/timer-oxnas-rps.c > +++ b/drivers/clocksource/timer-oxnas-rps.c > @@ -293,5 +293,5 @@ err_alloc: > return ret; > } > > -CLOCKSOURCE_OF_DECLARE_RET(ox810se_rps, > -"oxsemi,ox810se-rps-timer", oxnas_rps_timer_init); > +CLOCKSOURCE_OF_DECLARE(ox810se_rps, > +"oxsemi,ox810se-rps-timer", oxnas_rps_timer_init); For the OXNAS part : Acked-by: Neil Armstrong Thanks, Neil ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 2/7] clocksource: Rename CLOCKSOURCE_OF_DECLARE
7 @@ static int __init oxnas_rps_timer_init(struct device_node > *np) > return ret; > } > > -CLOCKSOURCE_OF_DECLARE(ox810se_rps, > +TIMER_OF_DECLARE(ox810se_rps, > "oxsemi,ox810se-rps-timer", oxnas_rps_timer_init); > -CLOCKSOURCE_OF_DECLARE(ox820_rps, > +TIMER_OF_DECLARE(ox820_rps, > "oxsemi,ox820se-rps-timer", oxnas_rps_timer_init); [...] For the timer-oxnas-rps driver, Acked-by: Neil Armstrong Thanks for the rework, Neil ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 4/7] dt-bindings: chosen: Add clocksource and clockevent selection
Hi,
On 10/09/2019 15:47, Claudiu Beznea wrote:
> From: Alexandre Belloni
>
> Some timer drivers may behave either as clocksource or clockevent
> or both. Until now, in case of platforms with multiple hardware
> resources of the same type, the drivers were chosing the first
> registered hardware resource as clocksource/clockevent and the
> next one as clockevent/clocksource. Other were using different
> compatibles (one for each functionality, although its about the
> same hardware). Add DT bindings to be able to choose the
> functionality of a timer.
>
> Signed-off-by: Alexandre Belloni
> Signed-off-by: Claudiu Beznea
> ---
> Documentation/devicetree/bindings/chosen.txt | 20
> 1 file changed, 20 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/chosen.txt
> b/Documentation/devicetree/bindings/chosen.txt
> index 45e79172a646..aad3034cdbdf 100644
> --- a/Documentation/devicetree/bindings/chosen.txt
> +++ b/Documentation/devicetree/bindings/chosen.txt
> @@ -135,3 +135,23 @@ e.g.
> linux,initrd-end = <0x8280>;
> };
> };
> +
> +linux,clocksource and linux,clockevent
> +--
> +
> +Those nodes have a timer property. This property is a phandle to the timer
> to be
> +chosen as the clocksource or clockevent. This is only useful when the
> platform
> +has multiple identical timers and it is not possible to let linux make the
> +correct choice.
> +
> +/ {
> + chosen {
> + linux,clocksource {
> + timer = <&timer0>;
> + };
> +
> + linux,clockevent {
> + timer = <&timer1>;
> + };
> + };
> +};
>
Why not in aliases ?
aliases {
clocksource0 = &timer0;
clockevent0 = &timer1;
};
since we can have multiple of each, we should not limit ourselves to 1 clkevent
and 1 clksource.
In the aliases case, each driver would expose both capabilities, and the core
would select
what to enable.
Neil
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v3 1/2] DRM: ARC: add HDMI 2.0 TX encoder support
On 15/04/2020 19:33, Daniel Vetter wrote:
> On Wed, Apr 15, 2020 at 02:29:28AM +0300, Eugeniy Paltsev wrote:
>> The Synopsys ARC SoCs (like HSDK4xD) include on-chip DesignWare HDMI
>> encoders. Support them with a platform driver to provide platform glue
>> data to the dw-hdmi driver.
>>
>> Acked-by: Sam Ravnborg
>> Signed-off-by: Eugeniy Paltsev
>> ---
>> MAINTAINERS | 6 ++
>> drivers/gpu/drm/Makefile | 2 +-
>> drivers/gpu/drm/arc/Kconfig | 7 ++
>> drivers/gpu/drm/arc/Makefile | 1 +
>> drivers/gpu/drm/arc/arc-dw-hdmi.c | 116 ++
>> 5 files changed, 131 insertions(+), 1 deletion(-)
>> create mode 100644 drivers/gpu/drm/arc/arc-dw-hdmi.c
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index a6fbdf354d34..2aaed1190370 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -1258,6 +1258,12 @@ S:Supported
>> F: drivers/gpu/drm/arc/
>> F: Documentation/devicetree/bindings/display/snps,arcpgu.txt
>>
>> +ARC DW HDMI DRIVER
>> +M: Eugeniy Paltsev
>> +S: Supported
>> +F: drivers/gpu/drm/arc/arc-dw-hdmi.c
>> +F: Documentation/devicetree/bindings/display/bridge/snps,arc-dw-hdmi.yaml
>> +
>> ARCNET NETWORK LAYER
>> M: Michael Grzeschik
>> L: net...@vger.kernel.org
>> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
>> index 6493088a0fdd..5b0bcf7f45cd 100644
>> --- a/drivers/gpu/drm/Makefile
>> +++ b/drivers/gpu/drm/Makefile
>> @@ -109,7 +109,7 @@ obj-y+= panel/
>> obj-y += bridge/
>> obj-$(CONFIG_DRM_FSL_DCU) += fsl-dcu/
>> obj-$(CONFIG_DRM_ETNAVIV) += etnaviv/
>> -obj-$(CONFIG_DRM_ARCPGU)+= arc/
>> +obj-y += arc/
>> obj-y += hisilicon/
>> obj-$(CONFIG_DRM_ZTE) += zte/
>> obj-$(CONFIG_DRM_MXSFB) += mxsfb/
>> diff --git a/drivers/gpu/drm/arc/Kconfig b/drivers/gpu/drm/arc/Kconfig
>> index e8f3d63e0b91..baec9d2a4fba 100644
>> --- a/drivers/gpu/drm/arc/Kconfig
>> +++ b/drivers/gpu/drm/arc/Kconfig
>> @@ -8,3 +8,10 @@ config DRM_ARCPGU
>>Choose this option if you have an ARC PGU controller.
>>
>>If M is selected the module will be called arcpgu.
>> +
>> +config DRM_ARC_DW_HDMI
>> +tristate "ARC DW HDMI"
>> +depends on DRM && OF
>> +select DRM_DW_HDMI
>> +help
>> + Synopsys DW HDMI driver for various ARC development boards
>> diff --git a/drivers/gpu/drm/arc/Makefile b/drivers/gpu/drm/arc/Makefile
>> index c7028b7427b3..7a156d8c2c3c 100644
>> --- a/drivers/gpu/drm/arc/Makefile
>> +++ b/drivers/gpu/drm/arc/Makefile
>> @@ -1,3 +1,4 @@
>> # SPDX-License-Identifier: GPL-2.0-only
>> arcpgu-y := arcpgu_crtc.o arcpgu_hdmi.o arcpgu_sim.o arcpgu_drv.o
>> obj-$(CONFIG_DRM_ARCPGU) += arcpgu.o
>> +obj-$(CONFIG_DRM_ARC_DW_HDMI) += arc-dw-hdmi.o
>> diff --git a/drivers/gpu/drm/arc/arc-dw-hdmi.c
>> b/drivers/gpu/drm/arc/arc-dw-hdmi.c
>> new file mode 100644
>> index ..46a6ee09b302
>> --- /dev/null
>> +++ b/drivers/gpu/drm/arc/arc-dw-hdmi.c
>> @@ -0,0 +1,116 @@
>> +// SPDX-License-Identifier: GPL-2.0+
>> +//
>> +// Synopsys DW HDMI driver for various ARC development boards
>> +//
>> +// Copyright (C) 2020 Synopsys
>> +// Author: Eugeniy Paltsev
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +static const struct dw_hdmi_mpll_config snps_hdmi_mpll_cfg[] = {
>> +{
>> +2700, {
>> +{ 0x00B3, 0x },
>> +{ 0x00B3, 0x },
>> +{ 0x00B3, 0x }
>> +},
>> +}, {
>> +7425, {
>> +{ 0x0072, 0x0001},
>> +{ 0x0072, 0x0001},
>> +{ 0x0072, 0x0001}
>> +},
>> +}, {
>> +14850, {
>> +{ 0x0051, 0x0002},
>> +{ 0x0051, 0x0002},
>> +{ 0x0051, 0x0002}
>> +},
>> +}, {
>> +~0UL, {
>> +{ 0x00B3, 0x },
>> +{ 0x00B3, 0x },
>> +{ 0x00B3, 0x },
>> +},
>> +}
>> +};
>> +
>> +static const struct dw_hdmi_curr_ctrl snps_hdmi_cur_ctr[] = {
>> +/* pixelclkbpp8bpp10 bpp12 */
>> +{ 2700, { 0x, 0x, 0x }, },
>> +{ 7425, { 0x0008, 0x0008, 0x0008 }, },
>> +{ 14850, { 0x001b, 0x001b, 0x001b }, },
>> +{ ~0UL, { 0x, 0x, 0x }, }
>> +};
>> +
>> +
>> +static const struct dw_hdmi_phy_config snps_hdmi_phy_config[] = {
>> +/* pixelclk symbol termvlev */
>> +{ 2700, 0x8009, 0x0004, 0x0232},
>> +{ 7425, 0x8009, 0x0004, 0x0232},
>> +{ 14850, 0x8009, 0x0004, 0x0232},
>> +{ ~0UL, 0x8009, 0x0004, 0x0232}
>> +};
>> +
>> +static struct dw_hdmi_plat_data snps_dw_hdmi_drv_data = {
>> +.mpll_cfg = snps_hdmi_mpll_cfg,
>> +.cur_ctr= snps_hdmi
Re: [PATCH 18/21] ARM: drop SMP support for ARM11MPCore
On 27/03/2023 14:13, Arnd Bergmann wrote: From: Arnd Bergmann The cache management operations for noncoherent DMA on ARMv6 work in two different ways: * When CONFIG_DMA_CACHE_RWFO is set, speculative prefetches on in-flight DMA buffers lead to data corruption when the prefetched data is written back on top of data from the device. * When CONFIG_DMA_CACHE_RWFO is disabled, a cache flush on one CPU is not seen by the other core(s), leading to inconsistent contents accross the system. As a consequence, neither configuration is actually safe to use in a general-purpose kernel that is used on both MPCore systems and ARM1176 with prefetching enabled. We could add further workarounds to make the behavior more dynamic based on the system, but realistically, there are close to zero remaining users on any ARM11MPCore anyway, and nobody seems too interested in it, compared to the more popular ARM1176 used in BMC2835 and AST2500. The Oxnas platform has some minimal support in OpenWRT, but most of the drivers and dts files never made it into the mainline kernel, while the Arm Versatile/Realview platform mainly serves as a reference system but is not necessary to be kept working once all other ARM11MPCore are gone. Acked-by: Neil Armstrong It's sad but it's the reality, there's no chance full OXNAS support will ever come upstream and no real work has been done for years. I think OXNAS support can be programmed for removal for next release, it would need significant work to rework current support to make it acceptable before trying to upstream missing bits anyway. Thanks, Neil Take the easy way out here and drop support for multiprocessing on ARMv6, along with the CONFIG_DMA_CACHE_RWFO option and the cache management implementation for it. This also helps with other ARMv6 issues, but for the moment leaves the ability to build a kernel that can run on both ARMv7 SMP and single-processor ARMv6, which we probably want to stop supporting as well, but not as part of this series. Cc: Neil Armstrong Cc: Daniel Golle Cc: Linus Walleij Cc: linux-ox...@groups.io Signed-off-by: Arnd Bergmann --- I could use some help clarifying the above changelog text to describe the exact problem, and how the CONFIG_DMA_CACHE_RWFO actually works on MPCore. The TRMs for both 1176 and 11MPCore only describe prefetching into the instruction cache, not the data cache, but this can end up in the outercache as a result. The 1176 has some extra control bits to control prefetching, but I found no reference that explains why an MPCore does not run into the problem. --- arch/arm/mach-oxnas/Kconfig| 4 - arch/arm/mach-oxnas/Makefile | 1 - arch/arm/mach-oxnas/headsmp.S | 23 -- arch/arm/mach-oxnas/platsmp.c | 96 -- arch/arm/mach-versatile/platsmp-realview.c | 4 - arch/arm/mm/Kconfig| 19 - arch/arm/mm/cache-v6.S | 31 --- 7 files changed, 178 deletions(-) delete mode 100644 arch/arm/mach-oxnas/headsmp.S delete mode 100644 arch/arm/mach-oxnas/platsmp.c diff --git a/arch/arm/mach-oxnas/Kconfig b/arch/arm/mach-oxnas/Kconfig index a9ded7079268..a054235c3d6c 100644 --- a/arch/arm/mach-oxnas/Kconfig +++ b/arch/arm/mach-oxnas/Kconfig @@ -28,10 +28,6 @@ config MACH_OX820 bool "Support OX820 Based Products" depends on ARCH_MULTI_V6 select ARM_GIC - select DMA_CACHE_RWFO if SMP - select HAVE_SMP - select HAVE_ARM_SCU if SMP - select HAVE_ARM_TWD if SMP help Include Support for the Oxford Semiconductor OX820 SoC Based Products. diff --git a/arch/arm/mach-oxnas/Makefile b/arch/arm/mach-oxnas/Makefile index 0e78ecfe6c49..a4e40e534e6a 100644 --- a/arch/arm/mach-oxnas/Makefile +++ b/arch/arm/mach-oxnas/Makefile @@ -1,2 +1 @@ # SPDX-License-Identifier: GPL-2.0-only -obj-$(CONFIG_SMP) += platsmp.o headsmp.o diff --git a/arch/arm/mach-oxnas/headsmp.S b/arch/arm/mach-oxnas/headsmp.S deleted file mode 100644 index 9c0f1479f33a.. --- a/arch/arm/mach-oxnas/headsmp.S +++ /dev/null @@ -1,23 +0,0 @@ -/* SPDX-License-Identifier: GPL-2.0-only */ -/* - * Copyright (C) 2013 Ma Haijun - * Copyright (c) 2003 ARM Limited - * All Rights Reserved - */ -#include -#include - - __INIT - -/* - * OX820 specific entry point for secondary CPUs. - */ -ENTRY(ox820_secondary_startup) - mov r4, #0 - /* invalidate both caches and branch target cache */ - mcr p15, 0, r4, c7, c7, 0 - /* -* we've been released from the holding pen: secondary_stack -* should now contain the SVC stack for this core -*/ - b secondary_startup diff --git a/arch/arm/mach-oxnas/platsmp.c b/arch/arm/mach-oxnas/platsmp.c deleted file mode 100644 index f0a50b9e61df.. --- a/arch/arm/mach-oxnas/platsmp.c +++ /dev/null @@ -1,96 +0,0 @@ -/
Re: [PATCH 18/21] ARM: drop SMP support for ARM11MPCore
Le 30/03/2023 à 12:03, Arnd Bergmann a écrit : On Thu, Mar 30, 2023, at 09:48, Neil Armstrong wrote: On 27/03/2023 14:13, Arnd Bergmann wrote: From: Arnd Bergmann The cache management operations for noncoherent DMA on ARMv6 work in two different ways: * When CONFIG_DMA_CACHE_RWFO is set, speculative prefetches on in-flight DMA buffers lead to data corruption when the prefetched data is written back on top of data from the device. * When CONFIG_DMA_CACHE_RWFO is disabled, a cache flush on one CPU is not seen by the other core(s), leading to inconsistent contents accross the system. As a consequence, neither configuration is actually safe to use in a general-purpose kernel that is used on both MPCore systems and ARM1176 with prefetching enabled. We could add further workarounds to make the behavior more dynamic based on the system, but realistically, there are close to zero remaining users on any ARM11MPCore anyway, and nobody seems too interested in it, compared to the more popular ARM1176 used in BMC2835 and AST2500. The Oxnas platform has some minimal support in OpenWRT, but most of the drivers and dts files never made it into the mainline kernel, while the Arm Versatile/Realview platform mainly serves as a reference system but is not necessary to be kept working once all other ARM11MPCore are gone. Acked-by: Neil Armstrong It's sad but it's the reality, there's no chance full OXNAS support will ever come upstream and no real work has been done for years. I think OXNAS support can be programmed for removal for next release, it would need significant work to rework current support to make it acceptable before trying to upstream missing bits anyway. Ok, thanks for your reply! To clarify, do you think we should plan for removal after the next stable release (6.3, removed in 6.4), or after the next LTS release (probably 6.6, removed in 6.7)? As far as I understand, the next OpenWRT release (23.x) will be based on linux-5.15, and the one after that (24.x) would likely still use 6.1, unless they skip an LTS kernel. I think it's ok to remove it ASAP, or at least before the next LTS, not having SMP makes the platform barely usable so the earliest is the best. Neil Arnd ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
