Re: [patch V4] lib: GCD: Use binary GCD algorithm instead of Euclidean
> diff --git a/arch/sparc/Kconfig b/arch/sparc/Kconfig > index 57ffaf2..ca675ed 100644 > --- a/arch/sparc/Kconfig > +++ b/arch/sparc/Kconfig > @@ -42,6 +42,7 @@ config SPARC > select ODD_RT_SIGACTION > select OLD_SIGSUSPEND > select ARCH_HAS_SG_CHAIN > + select CPU_NO_EFFICIENT_FFS > > config SPARC32 > def_bool !64BIT sparc64 have an efficient ffs implementation. We use run-time patching to use the proper version depending on the actual sparc cpu. As this is determinded at config time, then let the sparc cpu that has the efficient ffs benefit from this. In other words - select CPU_NO_EFFICIENT_FFS only for SPARC32. Sam ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 1/2] dma-mapping: zero memory returned from dma_alloc_*
Hi Christoph, I stumbled upon this one: #define __get_dma_pages(gfp_mask, order) \ __get_free_pages((gfp_mask) | GFP_DMA, (order)) (include/linux/gfp.h) Should it also have the __GFP_ZERO treatment? Or maybe this is already done in your tree.. As for the sparc bits: Acked-by: Sam Ravnborg [sparc] Sam ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 2/2] dt-bindings: Document the Synopsys ARC HDMI TX bindings
Hi Eugeniy.
On Mon, Mar 16, 2020 at 05:46:47PM +0300, Eugeniy Paltsev wrote:
> This patch adds documentation of device tree bindings for the Synopsys
> HDMI 2.0 TX encoder driver for ARC SoCs.
>
> Signed-off-by: Eugeniy Paltsev
> ---
> .../display/bridge/snps,arc-dw-hdmi.txt | 73 +++
New bindings in DT Schema format please (.yaml files).
We are working on migrating all bindings to DT Schema format.
Sam
> 1 file changed, 73 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/bridge/snps,arc-dw-hdmi.txt
>
> diff --git
> a/Documentation/devicetree/bindings/display/bridge/snps,arc-dw-hdmi.txt
> b/Documentation/devicetree/bindings/display/bridge/snps,arc-dw-hdmi.txt
> new file mode 100644
> index ..d5e006b392cc
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/snps,arc-dw-hdmi.txt
> @@ -0,0 +1,73 @@
> +Synopsys DesignWare HDMI 2.0 TX encoder driver for ARC SoCs
> +
> +
> +The HDMI transmitter is a Synopsys DesignWare HDMI 2.0 TX controller IP
> +with a companion of Synopsys DesignWare HDMI 2.0 TX PHY IP.
> +
> +These DT bindings follow the Synopsys DWC HDMI TX bindings defined in
> +Documentation/devicetree/bindings/display/bridge/dw_hdmi.txt
> +with the following device-specific properties.
> +
> +
> +Required properties:
> +
> +- compatible : Shall contain
> + - "snps,dw-hdmi-hsdk" for HSDK4xD compatible HDMI TX
> +
> +- reg: See dw_hdmi.txt.
> +- interrupts: HDMI interrupt number.
> +- clocks: See dw_hdmi.txt.
> +- clock-names: Must contain "iahb" and "isfr" as defined in dw_hdmi.txt.
> +- ports: See dw_hdmi.txt. The DWC HDMI shall have one port numbered 0
> + corresponding to the video input of the controller and one port numbered 1
> + corresponding to its HDMI output.
> +
> +Example:
> +
> +hdmi: hdmi@0x1 {
> + compatible = "snps,dw-hdmi-hsdk";
> + reg = <0x1 0x1>;
> + reg-io-width = <4>;
> + interrupts = <14>;
> + clocks = <&apbclk>, <&hdmi_pix_clk>;
> + clock-names = "iahb", "isfr";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + hdmi_enc_input: endpoint {
> + remote-endpoint = <&pgu_output>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> + hdmi_enc_out: endpoint {
> + remote-endpoint = <&hdmi_con>;
> + };
> + };
> + };
> +};
> +
> +hdmi-out {
> + ...
> +
> + port {
> + hdmi_con: endpoint {
> + remote-endpoint = <&hdmi_enc_out>;
> + };
> + };
> +};
> +
> +pgu {
> + ...
> +
> + port_o: port {
> + pgu_output: endpoint {
> + remote-endpoint = <&hdmi_enc_input>;
> + };
> + };
> +};
> --
> 2.21.1
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v2 1/2] DRM: ARC: add HDMI 2.0 TX encoder support
Hi Eugeniy.
On Tue, Apr 14, 2020 at 05:44:01PM +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.
Drivers looks lean and clean.
Acked-by: Sam Ravnborg
But really take this as I found no whitespace erros or something...
A few drive-by comments below.
Sam
>
> 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 | 126 ++
> 5 files changed, 141 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
I am confused about the filename of the binding.
Binding files are often named after their compatible.
But the compatible is: snps,dw-hdmi-hsdk
And the biding file seems to be named after the driver name.
This seems wrong - and I do nto see it explained.
> +
> 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 ..4869dd668a51
> --- /dev/null
> +++ b/drivers/gpu/drm/arc/arc-dw-hdmi.c
> @@ -0,0 +1,126 @@
> +// 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
> +#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[] = {
> +
Re: [PATCH v2 2/2] dt-bindings: Document the Synopsys ARC HDMI TX bindings
Hi Eugeniy.
On Tue, Apr 14, 2020 at 05:44:02PM +0300, Eugeniy Paltsev wrote:
> This patch adds documentation of device tree bindings for the Synopsys
> HDMI 2.0 TX encoder driver for ARC SoCs.
>
> Signed-off-by: Eugeniy Paltsev
Acked-by: Sam Ravnborg
with a few nits addressed.
As already mentioned - the filename confuses.
Maybe tell why in changelog - og fix filename to follow compatible.
> ---
> .../display/bridge/snps,arc-dw-hdmi.yaml | 131 ++
> 1 file changed, 131 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/bridge/snps,arc-dw-hdmi.yaml
>
> diff --git
> a/Documentation/devicetree/bindings/display/bridge/snps,arc-dw-hdmi.yaml
> b/Documentation/devicetree/bindings/display/bridge/snps,arc-dw-hdmi.yaml
> new file mode 100644
> index ..f52fc3b114b0
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/snps,arc-dw-hdmi.yaml
> @@ -0,0 +1,131 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/bridge/snps,arc-dw-hdmi.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Synopsys DesignWare HDMI 2.0 TX encoder driver
> +
> +maintainers:
> + - Eugeniy Paltsev
> +
> +description: |
> + The HDMI transmitter is a Synopsys DesignWare HDMI 2.0 TX controller IP
> + with a companion of Synopsys DesignWare HDMI 2.0 TX PHY IP.
> +
> + These DT bindings follow the Synopsys DWC HDMI TX bindings defined in
> + Documentation/devicetree/bindings/display/bridge/dw_hdmi.txt
> + with the following device-specific properties.
> +
> +properties:
> + compatible:
> +const: snps,dw-hdmi-hsdk
> +
> + reg:
> +maxItems: 1
> +description: |
> + Memory mapped base address and length of the DWC HDMI TX registers.
> +
> + clocks:
> +items:
> + - description: The bus clock for AHB / APB
> + - description: The internal register configuration clock
> +
> + clock-names:
> +items:
> + - const: iahb
> + - const: isfr
> +
> + reg-io-width:
> +allOf:
> + - $ref: /schemas/types.yaml#/definitions/uint32
> + - enum: [1, 4]
> +description:
> + Width of the registers specified by the reg property. The
> + value is expressed in bytes and must be equal to 1 or 4 if
> specified.
> + The register width defaults to 1 if the property is not present.
> +
> + ports:
> +type: object
> +description: |
> + A ports node with endpoint definitions as defined in
> + Documentation/devicetree/bindings/media/video-interfaces.txt
> +
> +properties:
> + "#address-cells":
> +const: 1
> +
> + "#size-cells":
> +const: 0
> +
> + port@0:
> +type: object
> +description: |
> + Video input endpoints of the controller.
> + Usually the associated with PGU.
Please rephrase this sentence. I am not sure how to read it.
> +
> + port@1:
> +type: object
> +description: |
> + Output endpoints of the controller. HDMI connector.
> +
> +required:
> + - "#address-cells"
> + - "#size-cells"
> + - port@0
> + - port@1
> +
> +required:
> + - compatible
> + - reg
> + - clocks
> + - clock-names
> + - ports
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +hdmi: hdmi@0x1 {
hdmi
> +compatible = "snps,dw-hdmi-hsdk";
> +reg = <0x1 0x1>;
> +reg-io-width = <4>;
> +interrupts = <14>;
> +clocks = <&apbclk>, <&hdmi_pix_clk>;
> +clock-names = "iahb", "isfr";
> +
> +ports {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +port@0 {
> +reg = <0>;
> +hdmi_enc_input: endpoint {
> +remote-endpoint = <&pgu_output>;
> +};
> +};
> +
> +port@1 {
> +reg = <1>;
> +hdmi_enc_out: endpoint {
> +remote-endpoint = <&hdmi_con>;
> +};
> +};
> +};
> +};
> +
> +hdmi-out {
> +port {
> +hdmi_con: endpoint {
> +remote-endpoint = <&hdmi_enc_out>;
> +};
> +};
> +};
> +
> +pgu {
> +port_o: port {
> +pgu_output: endpoint {
> +remote-endpoint = <&hdmi_enc_input>;
> +};
> +};
> +};
> --
> 2.21.1
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v2 15/18] sparc64: remove CONFIG_SET_FS support
Hi Arnd. On Wed, Feb 16, 2022 at 02:13:29PM +0100, Arnd Bergmann wrote: > From: Arnd Bergmann > > sparc64 uses address space identifiers to differentiate between kernel > and user space, using ASI_P for kernel threads but ASI_AIUS for normal > user space, with the option of changing between them. > > As nothing really changes the ASI any more, just hardcode ASI_AIUS > everywhere. Kernel threads are not allowed to access __user pointers > anyway. > > Signed-off-by: Arnd Bergmann > --- > arch/sparc/include/asm/processor_64.h | 4 > arch/sparc/include/asm/switch_to_64.h | 4 +--- > arch/sparc/include/asm/thread_info_64.h | 4 +--- > arch/sparc/include/asm/uaccess_64.h | 20 +--- > arch/sparc/kernel/process_64.c | 12 > arch/sparc/kernel/traps_64.c| 2 -- > arch/sparc/lib/NGmemcpy.S | 3 +-- > arch/sparc/mm/init_64.c | 7 --- > 8 files changed, 8 insertions(+), 48 deletions(-) I think you somehow missed the Kconfig change, and also the related sparc32 change which continue to have set_fs() after this patch. I did not manage to review the patch - as I am too unfamiliar with the code paths and the set_fs() removal changes. Sam ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v2 15/18] sparc64: remove CONFIG_SET_FS support
Hi Arnd, On Wed, Feb 16, 2022 at 07:34:59PM +0100, Sam Ravnborg wrote: > Hi Arnd. > > On Wed, Feb 16, 2022 at 02:13:29PM +0100, Arnd Bergmann wrote: > > From: Arnd Bergmann > > > > sparc64 uses address space identifiers to differentiate between kernel > > and user space, using ASI_P for kernel threads but ASI_AIUS for normal > > user space, with the option of changing between them. > > > > As nothing really changes the ASI any more, just hardcode ASI_AIUS > > everywhere. Kernel threads are not allowed to access __user pointers > > anyway. > > > > Signed-off-by: Arnd Bergmann > > --- > > arch/sparc/include/asm/processor_64.h | 4 > > arch/sparc/include/asm/switch_to_64.h | 4 +--- > > arch/sparc/include/asm/thread_info_64.h | 4 +--- > > arch/sparc/include/asm/uaccess_64.h | 20 +--- > > arch/sparc/kernel/process_64.c | 12 > > arch/sparc/kernel/traps_64.c| 2 -- > > arch/sparc/lib/NGmemcpy.S | 3 +-- > > arch/sparc/mm/init_64.c | 7 --- > > 8 files changed, 8 insertions(+), 48 deletions(-) > > I think you somehow missed the Kconfig change, and also the related > sparc32 change which continue to have set_fs() after this patch. I now notice the sparc32 bits are in the last patch. To avoid breaking bisect-ability on sparc64 I think you need to merge the sparc32 changes with this patch, unless the sparc64 changes can coexist with CONFIG_SET_FS continue to be set. Sam ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v2 18/18] uaccess: drop maining CONFIG_SET_FS users
Hi Arnd,
Fix spelling in $subject...
sparc/Kconfig b/arch/sparc/Kconfig
> index 9f6f9bce5292..9276f321b3e3 100644
> --- a/arch/sparc/Kconfig
> +++ b/arch/sparc/Kconfig
> @@ -46,7 +46,6 @@ config SPARC
> select LOCKDEP_SMALL if LOCKDEP
> select NEED_DMA_MAP_STATE
> select NEED_SG_DMA_LENGTH
> - select SET_FS
> select TRACE_IRQFLAGS_SUPPORT
>
> config SPARC32
> @@ -101,6 +100,7 @@ config SPARC64
> select HAVE_SETUP_PER_CPU_AREA
> select NEED_PER_CPU_EMBED_FIRST_CHUNK
> select NEED_PER_CPU_PAGE_FIRST_CHUNK
> + select SET_FS
This looks wrong - looks like some merge went wrong here.
>
> config ARCH_PROC_KCORE_TEXT
> def_bool y
> diff --git a/arch/sparc/include/asm/processor_32.h
> b/arch/sparc/include/asm/processor_32.h
> index 647bf0ac7beb..b26c35336b51 100644
> --- a/arch/sparc/include/asm/processor_32.h
> +++ b/arch/sparc/include/asm/processor_32.h
> @@ -32,10 +32,6 @@ struct fpq {
> };
> #endif
>
> -typedef struct {
> - int seg;
> -} mm_segment_t;
> -
> /* The Sparc processor specific thread struct. */
> struct thread_struct {
> struct pt_regs *kregs;
> @@ -50,11 +46,9 @@ struct thread_struct {
> unsigned long fsr;
> unsigned long fpqdepth;
> struct fpq fpqueue[16];
> - mm_segment_t current_ds;
> };
>
> #define INIT_THREAD { \
> - .current_ds = KERNEL_DS, \
> .kregs = (struct pt_regs *)(init_stack+THREAD_SIZE)-1 \
> }
>
> diff --git a/arch/sparc/include/asm/uaccess_32.h
> b/arch/sparc/include/asm/uaccess_32.h
> index 367747116260..9fd6c53644b6 100644
> --- a/arch/sparc/include/asm/uaccess_32.h
> +++ b/arch/sparc/include/asm/uaccess_32.h
> @@ -12,19 +12,6 @@
> #include
>
> #include
> -
> -/* Sparc is not segmented, however we need to be able to fool access_ok()
> - * when doing system calls from kernel mode legitimately.
> - *
> - * "For historical reasons, these macros are grossly misnamed." -Linus
> - */
> -
> -#define KERNEL_DS ((mm_segment_t) { 0 })
> -#define USER_DS ((mm_segment_t) { -1 })
> -
> -#define get_fs() (current->thread.current_ds)
> -#define set_fs(val) ((current->thread.current_ds) = (val))
> -
> #include
>
> /* Uh, these should become the main single-value transfer routines..
> diff --git a/arch/sparc/kernel/process_32.c b/arch/sparc/kernel/process_32.c
> index 2dc0bf9fe62e..88c0c14aaff0 100644
> --- a/arch/sparc/kernel/process_32.c
> +++ b/arch/sparc/kernel/process_32.c
> @@ -300,7 +300,6 @@ int copy_thread(unsigned long clone_flags, unsigned long
> sp, unsigned long arg,
> extern int nwindows;
> unsigned long psr;
> memset(new_stack, 0, STACKFRAME_SZ + TRACEREG_SZ);
> - p->thread.current_ds = KERNEL_DS;
> ti->kpc = (((unsigned long) ret_from_kernel_thread) - 0x8);
> childregs->u_regs[UREG_G1] = sp; /* function */
> childregs->u_regs[UREG_G2] = arg;
> @@ -311,7 +310,6 @@ int copy_thread(unsigned long clone_flags, unsigned long
> sp, unsigned long arg,
> }
> memcpy(new_stack, (char *)regs - STACKFRAME_SZ, STACKFRAME_SZ +
> TRACEREG_SZ);
> childregs->u_regs[UREG_FP] = sp;
> - p->thread.current_ds = USER_DS;
> ti->kpc = (((unsigned long) ret_from_fork) - 0x8);
> ti->kpsr = current->thread.fork_kpsr | PSR_PIL;
> ti->kwim = current->thread.fork_kwim;
Other than the above the sparc32 changes looks fine, and with the Kconf
stuff fixed:
Acked-by: Sam Ravnborg # for sparc32 changes
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH V5 04/26] sparc/mm: Move protection_map[] inside the platform
Hi Anshuman,
On Mon, Jun 27, 2022 at 10:28:11AM +0530, Anshuman Khandual wrote:
> This moves protection_map[] inside the platform and while here, also enable
> ARCH_HAS_VM_GET_PAGE_PROT on 32 bit platforms via DECLARE_VM_GET_PAGE_PROT.
>
> Cc: "David S. Miller"
> Cc: sparcli...@vger.kernel.org
> Cc: linux-ker...@vger.kernel.org
> Signed-off-by: Anshuman Khandual
> ---
> arch/sparc/Kconfig | 2 +-
> arch/sparc/include/asm/pgtable_32.h | 19 ---
> arch/sparc/include/asm/pgtable_64.h | 19 ---
> arch/sparc/mm/init_32.c | 20
> arch/sparc/mm/init_64.c | 3 +++
> 5 files changed, 24 insertions(+), 39 deletions(-)
>
> diff --git a/arch/sparc/Kconfig b/arch/sparc/Kconfig
> index ba449c47effd..09f868613a4d 100644
> --- a/arch/sparc/Kconfig
> +++ b/arch/sparc/Kconfig
> @@ -13,6 +13,7 @@ config 64BIT
> config SPARC
> bool
> default y
> + select ARCH_HAS_VM_GET_PAGE_PROT
> select ARCH_MIGHT_HAVE_PC_PARPORT if SPARC64 && PCI
> select ARCH_MIGHT_HAVE_PC_SERIO
> select DMA_OPS
> @@ -84,7 +85,6 @@ config SPARC64
> select PERF_USE_VMALLOC
> select ARCH_HAVE_NMI_SAFE_CMPXCHG
> select HAVE_C_RECORDMCOUNT
> - select ARCH_HAS_VM_GET_PAGE_PROT
> select HAVE_ARCH_AUDITSYSCALL
> select ARCH_SUPPORTS_ATOMIC_RMW
> select ARCH_SUPPORTS_DEBUG_PAGEALLOC
> diff --git a/arch/sparc/include/asm/pgtable_32.h
> b/arch/sparc/include/asm/pgtable_32.h
> index 4866625da314..8ff549004fac 100644
> --- a/arch/sparc/include/asm/pgtable_32.h
> +++ b/arch/sparc/include/asm/pgtable_32.h
> @@ -64,25 +64,6 @@ void paging_init(void);
>
> extern unsigned long ptr_in_current_pgd;
>
> -/* xwr */
> -#define __P000 PAGE_NONE
> -#define __P001 PAGE_READONLY
> -#define __P010 PAGE_COPY
> -#define __P011 PAGE_COPY
> -#define __P100 PAGE_READONLY
> -#define __P101 PAGE_READONLY
> -#define __P110 PAGE_COPY
> -#define __P111 PAGE_COPY
> -
> -#define __S000 PAGE_NONE
> -#define __S001 PAGE_READONLY
> -#define __S010 PAGE_SHARED
> -#define __S011 PAGE_SHARED
> -#define __S100 PAGE_READONLY
> -#define __S101 PAGE_READONLY
> -#define __S110 PAGE_SHARED
> -#define __S111 PAGE_SHARED
> -
> /* First physical page can be anywhere, the following is needed so that
> * va-->pa and vice versa conversions work properly without performance
> * hit for all __pa()/__va() operations.
> diff --git a/arch/sparc/include/asm/pgtable_64.h
> b/arch/sparc/include/asm/pgtable_64.h
> index 4679e45c8348..a779418ceba9 100644
> --- a/arch/sparc/include/asm/pgtable_64.h
> +++ b/arch/sparc/include/asm/pgtable_64.h
> @@ -187,25 +187,6 @@ bool kern_addr_valid(unsigned long addr);
> #define _PAGE_SZHUGE_4U _PAGE_SZ4MB_4U
> #define _PAGE_SZHUGE_4V _PAGE_SZ4MB_4V
>
> -/* These are actually filled in at boot time by sun4{u,v}_pgprot_init() */
> -#define __P000 __pgprot(0)
> -#define __P001 __pgprot(0)
> -#define __P010 __pgprot(0)
> -#define __P011 __pgprot(0)
> -#define __P100 __pgprot(0)
> -#define __P101 __pgprot(0)
> -#define __P110 __pgprot(0)
> -#define __P111 __pgprot(0)
> -
> -#define __S000 __pgprot(0)
> -#define __S001 __pgprot(0)
> -#define __S010 __pgprot(0)
> -#define __S011 __pgprot(0)
> -#define __S100 __pgprot(0)
> -#define __S101 __pgprot(0)
> -#define __S110 __pgprot(0)
> -#define __S111 __pgprot(0)
> -
> #ifndef __ASSEMBLY__
>
> pte_t mk_pte_io(unsigned long, pgprot_t, int, unsigned long);
> diff --git a/arch/sparc/mm/init_32.c b/arch/sparc/mm/init_32.c
> index 1e9f577f084d..8693e4e28b86 100644
> --- a/arch/sparc/mm/init_32.c
> +++ b/arch/sparc/mm/init_32.c
> @@ -302,3 +302,23 @@ void sparc_flush_page_to_ram(struct page *page)
> __flush_page_to_ram(vaddr);
> }
> EXPORT_SYMBOL(sparc_flush_page_to_ram);
> +
> +static pgprot_t protection_map[16] __ro_after_init = {
This can be const - like done for powerpc and others.
sparc32 and sparc64 uses each their own - and I do not see sparc32 do
any modifications to protection_map.
With this change:
Reviewed-by: Sam Ravnborg
> + [VM_NONE] = PAGE_NONE,
> + [VM_READ] = PAGE_READONLY,
> + [VM_WRITE] = PAGE_COPY,
> + [VM_WRITE | VM_READ]= PAGE_COPY,
> + [VM_EXEC] = PAGE_READONLY,
> + [VM_EXEC | VM_
Re: [PATCH 0/5] fbdev: Move framebuffer I/O helpers to
Hi Thomas. On Wed, Apr 26, 2023 at 03:04:15PM +0200, Thomas Zimmermann wrote: > Fbdev provides helpers for framebuffer I/O, such as fb_readl(), > fb_writel() or fb_memcpy_to_fb(). The implementation of each helper > depends on the architecture. It's still all located in fbdev's main > header file . Move all of it into each archtecture's > , with shared code in . For once I think this cleanup is moving things in the wrong direction. The fb_* helpers predates the generic io.h support and try to add a generic layer for read read / write operations. The right fix would be to migrate fb_* to use the io helpers we have today - so we use the existing way to handle the architecture specific details. >From a quick look there seems to be some challenges but the current helpers that re-do part of io.h is not the way forward and hiding them in arch/include/asm/fb.h seems counter productive. Sam ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 0/5] fbdev: Move framebuffer I/O helpers to
Hi Thomas, On Thu, Apr 27, 2023 at 09:22:47AM +0200, Thomas Zimmermann wrote: > Hi Sam > > Am 26.04.23 um 21:21 schrieb Sam Ravnborg: > > Hi Thomas. > > > > On Wed, Apr 26, 2023 at 03:04:15PM +0200, Thomas Zimmermann wrote: > > > Fbdev provides helpers for framebuffer I/O, such as fb_readl(), > > > fb_writel() or fb_memcpy_to_fb(). The implementation of each helper > > > depends on the architecture. It's still all located in fbdev's main > > > header file . Move all of it into each archtecture's > > > , with shared code in . > > > > For once I think this cleanup is moving things in the wrong direction. > > > > The fb_* helpers predates the generic io.h support and try to > > add a generic layer for read read / write operations. > > > > The right fix would be to migrate fb_* to use the io helpers > > we have today - so we use the existing way to handle the architecture > > specific details. > > I looked through the existing versions of the fb_() I/O helpers. They can > apparently be implemented with the regular helpers of similar names. > > I'm not sure, but even Sparc looks compatible. At least these sbus_ > functions seem to be equivalent to the __raw_() I/O helpers of similar > names. > Do you still have that Sparc emulator? I used qemu the last time I played with sparc and saved the instructions somewhere how to redo it - but that would use to bohcs driver only I think. I have saprc machines, but none of these are easy to get operational. We can always ask on sparclinux to get some testing feedback. > > > > > From a quick look there seems to be some challenges but the current > > helpers that re-do part of io.h is not the way forward and hiding them > > in arch/include/asm/fb.h seems counter productive. > > Which challenges did you see? sparc was the main thing - but maybe I did not look close enough. And then I tried to map the macros to some of the more highlevel ones from io.h, but as Arnd says the __raw* is the way to go here. Sam ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v2 1/5] fbdev/matrox: Remove trailing whitespaces
On Fri, Apr 28, 2023 at 11:27:07AM +0200, Thomas Zimmermann wrote: > Fix coding style. No functional changes. > > Signed-off-by: Thomas Zimmermann Reviewed-by: Sam Ravnborg Sam ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v2 2/5] ipu-v3: Include
On Fri, Apr 28, 2023 at 11:27:08AM +0200, Thomas Zimmermann wrote: > The code uses readl() and writel(). Include the header file to > get the declarations. > > Signed-off-by: Thomas Zimmermann Reviewed-by: Sam Ravnborg > --- > drivers/gpu/ipu-v3/ipu-prv.h | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/gpu/ipu-v3/ipu-prv.h b/drivers/gpu/ipu-v3/ipu-prv.h > index 291ac1bab66d..d4621b1ea7f1 100644 > --- a/drivers/gpu/ipu-v3/ipu-prv.h > +++ b/drivers/gpu/ipu-v3/ipu-prv.h > @@ -8,6 +8,7 @@ > > struct ipu_soc; > > +#include > #include > #include > #include > -- > 2.40.0 ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v2 3/5] fbdev: Include in various drivers
On Fri, Apr 28, 2023 at 11:27:09AM +0200, Thomas Zimmermann wrote: > The code uses writel() and similar I/O-memory helpers. Include > the header file to get the declarations. > > Signed-off-by: Thomas Zimmermann Reviewed-by: Sam Ravnborg > --- > drivers/video/fbdev/arcfb.c | 1 + > drivers/video/fbdev/aty/atyfb.h | 2 ++ > drivers/video/fbdev/wmt_ge_rops.c | 2 ++ > 3 files changed, 5 insertions(+) > > diff --git a/drivers/video/fbdev/arcfb.c b/drivers/video/fbdev/arcfb.c > index 45e64016db32..d631d53f42ad 100644 > --- a/drivers/video/fbdev/arcfb.c > +++ b/drivers/video/fbdev/arcfb.c > @@ -41,6 +41,7 @@ > #include > #include > #include > +#include > #include > #include > #include > diff --git a/drivers/video/fbdev/aty/atyfb.h b/drivers/video/fbdev/aty/atyfb.h > index 465f55beb97f..30da3e82ed3c 100644 > --- a/drivers/video/fbdev/aty/atyfb.h > +++ b/drivers/video/fbdev/aty/atyfb.h > @@ -3,8 +3,10 @@ > * ATI Frame Buffer Device Driver Core Definitions > */ > > +#include > #include > #include > + > /* > * Elements of the hardware specific atyfb_par structure > */ > diff --git a/drivers/video/fbdev/wmt_ge_rops.c > b/drivers/video/fbdev/wmt_ge_rops.c > index 42255d27a1db..99c7b0aea615 100644 > --- a/drivers/video/fbdev/wmt_ge_rops.c > +++ b/drivers/video/fbdev/wmt_ge_rops.c > @@ -9,7 +9,9 @@ > > #include > #include > +#include > #include > + > #include "core/fb_draw.h" > #include "wmt_ge_rops.h" > > -- > 2.40.0 ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v2 4/5] fbdev: Include in drivers
On Fri, Apr 28, 2023 at 11:27:10AM +0200, Thomas Zimmermann wrote:
> Fbdev's main header file, , includes to get
> declarations of I/O helper functions. From these declaratons, it later
> defines framebuffer I/O helpers, such as fb_{read,write}[bwlq]() or
> fb_memset().
>
> The framebuffer I/O helpers pre-date Linux' current I/O code and will
> be replaced by regular I/O helpers. Prepare this change by adding an
> include statement for to all source files that use the
> framebuffer I/O helpers. They will still get declarations of the I/O
> functions even after has been cleaned up.
When fb.h uses a symbol from io.h, then it shall include that
file so it is self contained.
So it is wrong to push the io.h include to the users of
fb_{read,write,xxx}. Maybe fb.h only uses macros as is the case here,
but that is no excuse nt to include io.h.
Drop these changes.
> Driver source
> files that already include convert to .
This is a nice cleanup - we should keep that.
Sam
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v2 5/5] fbdev: Define framebuffer I/O from Linux' I/O functions
Hi Thomas,
On Fri, Apr 28, 2023 at 11:27:11AM +0200, Thomas Zimmermann wrote:
> Implement framebuffer I/O helpers, such as fb_read*() and fb_write*()
> with Linux' regular I/O functions. Remove all ifdef cases for the
> various architectures.
>
> Most of the supported architectures use __raw_() I/O functions or treat
> framebuffer memory like regular memory. This is also implemented by the
> architectures' I/O function, so we can use them instead.
>
> Sparc uses SBus to connect to framebuffer devices. It provides respective
> implementations of the framebuffer I/O helpers. The involved sbus_()
> I/O helpers map to the same code as Sparc's regular I/O functions. As
> with other platforms, we can use those instead.
>
> We leave a TODO item to replace all fb_() functions with their regular
> I/O counterparts throughout the fbdev drivers.
>
> Signed-off-by: Thomas Zimmermann
> ---
> include/linux/fb.h | 63 +++---
> 1 file changed, 15 insertions(+), 48 deletions(-)
>
> diff --git a/include/linux/fb.h b/include/linux/fb.h
> index 08cb47da71f8..4aa9e90edd17 100644
> --- a/include/linux/fb.h
> +++ b/include/linux/fb.h
> @@ -15,7 +15,6 @@
> #include
> #include
> #include
> -#include
>
> struct vm_area_struct;
> struct fb_info;
> @@ -511,58 +510,26 @@ struct fb_info {
> */
> #define STUPID_ACCELF_TEXT_SHIT
>
> -// This will go away
> -#if defined(__sparc__)
> -
> -/* We map all of our framebuffers such that big-endian accesses
> - * are what we want, so the following is sufficient.
> +/*
> + * TODO: Update fbdev drivers to call the I/O helpers directly and
> + * remove the fb_() tokens.
> */
When the __raw_* variants are used, as Geert points out, then I think
the memcpy / memset can be replaced, but the rest seems fine to keep.
My personal opinion is that __raw_* is for macro use etc, and not
something to use everywhere. So I like the fb_read/fb_write macros.
But that is just my color of the bikeshed.
Sam
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v2 0/5] fbdev: Use regular I/O function for framebuffers
Hi Thomas, On Fri, Apr 28, 2023 at 11:27:06AM +0200, Thomas Zimmermann wrote: > (was: fbdev: Move framebuffer I/O helpers to ) > > Fbdev provides helpers for framebuffer I/O, such as fb_readl(), > fb_writel() or fb_memcpy_to_fb(). The implementation of each helper > depends on the architecture, but they all come down to regular I/O > functions of similar names. So use the regular functions instead. > > The first patch a simple whitespace cleanup. > > Until now, contained an include of . As this > will go away patches 2 to 4 prepare include statements in the various > drivers. Source files that use regular I/O helpers, such as readl(), > now include . Source files that use framebuffer I/O > helpers, such as fb_readl(), also include . > > Patch 5 replaces the architecture-based if-else branching in > by define statements that map to Linux' I/O fucntions. > > After this change has been merged and included in a few release > without complains, we can update the drivers to regular I/O functions > and remove the fbdev-specific defines. > > The patchset has been built for a variety of platforms, such as x86-64, > arm, aarch64, ppc64, parisc, m64k, mips and sparc. > > v2: > * use Linux I/O helpers (Sam, Arnd) Much better, thanks! Sam ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v2 5/5] fbdev: Define framebuffer I/O from Linux' I/O functions
Hi Thomas, On Fri, Apr 28, 2023 at 04:18:38PM +0200, Thomas Zimmermann wrote: > I'd be happy to have fb_() wrappers that are I/O helpers without > ordering guarantees. I'd just wouldn't want them in How about throwing them into a new drm_fb.h header file. This header file could be the home for all the fb stuff that is shared between drm and the legacy fbdev. Then we may slowly migrate more fbdev stuff to drm and let the legacy fbdev stuff use the maintained drm stuff. Dunno, the pain may not be worth it. Sam ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v3 4/6] fbdev: Include via
Hi Thomas,
On Tue, May 02, 2023 at 03:02:21PM +0200, Thomas Zimmermann wrote:
> Fbdev's main header file, , includes to get
> declarations for I/O helper functions. From these declarations, it
> later defines framebuffer I/O helpers, such as fb_{read,write}[bwlq]()
> or fb_memset().
>
> The framebuffer I/O helpers depend on the system architecture and
> will therefore be moved into . Prepare this change by first
> adding an include statement for to .
> Include in all source files that use the framebuffer I/O
> helpers, so that they still get the necessary I/O functions.
>
...
>
> diff --git a/drivers/video/fbdev/arkfb.c b/drivers/video/fbdev/arkfb.c
> index 60a96fdb5dd8..fd38e8a073b8 100644
> --- a/drivers/video/fbdev/arkfb.c
> +++ b/drivers/video/fbdev/arkfb.c
> @@ -27,6 +27,8 @@
> #include /* Why should fb driver call console functions?
> because console_lock() */
> #include
>
> +#include
When we have a header like linux/fb.h - it is my understanding that it is
preferred to include that file, and not the asm/fb.h variant.
This is assuming the linux/fb.h contains the generic stuff, and includes
asm/fb.h for the architecture specific parts.
So drivers will include linux/fb.h and then they automatically get the
architecture specific parts from asm/fb.h.
In other words, drivers are not supposed to include asm/fb.h, if
linux.fb.h exists - and linux/fb.h shall include the asm/fb.h.
If the above holds true, then it is wrong and not needed to add asm/fb.h
as seen above.
There are countless examples where the above are not followed,
but to my best understanding the above it the preferred way to do it.
Sam
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v3 5/6] fbdev: Move framebuffer I/O helpers into
Hi Thomas,
On Tue, May 02, 2023 at 03:02:22PM +0200, Thomas Zimmermann wrote:
> Implement framebuffer I/O helpers, such as fb_read*() and fb_write*(),
> in the architecture's header file or the generic one.
In reality they are now all implemented in the generic one.
>
> The common case has been the use of regular I/O functions, such as
> __raw_readb() or memset_io(). A few architectures used plain system-
> memory reads and writes. Sparc used helpers for its SBus.
>
> The architectures that used special cases provide the same code in
> their __raw_*() I/O helpers. So the patch replaces this code with the
> __raw_*() functions and moves it to for all
> architectures.
Which is also documented here.
>
> v3:
> * implement all architectures with generic helpers
> * support reordering and native byte order (Geert, Arnd)
>
> Signed-off-by: Thomas Zimmermann
> ---
> include/asm-generic/fb.h | 101 +++
> include/linux/fb.h | 53
> 2 files changed, 101 insertions(+), 53 deletions(-)
>
> diff --git a/include/asm-generic/fb.h b/include/asm-generic/fb.h
> index 6922dd248c51..0540eccdbeca 100644
> --- a/include/asm-generic/fb.h
> +++ b/include/asm-generic/fb.h
> @@ -31,4 +31,105 @@ static inline int fb_is_primary_device(struct fb_info
> *info)
> }
> #endif
>
> +/*
> + * I/O helpers for the framebuffer. Prefer these functions over their
> + * regular counterparts. The regular I/O functions provide in-order
> + * access and swap bytes to/from little-endian ordering. Neither is
> + * required for framebuffers. Instead, the helpers read and write
> + * raw framebuffer data. Independent operations can be reordered for
> + * improved performance.
> + */
> +
> +#ifndef fb_readb
> +static inline u8 fb_readb(const volatile void __iomem *addr)
> +{
> + return __raw_readb(addr);
> +}
> +#define fb_readb fb_readb
> +#endif
When we need to provide an architecture specific variant the
#ifndef foo
...
#define foo foo
can be added. Right now it is just noise as no architectures provide
their own variants.
But I am missing something somewhere as I cannot see how this builds.
asm-generic now provide the fb_read/fb_write helpers.
But for example sparc has an architecture specifc fb.h so it will not
use the asm-generic variant. So I wonder how sparc get hold of the
asm-generic fb.h file?
Maybe it is obvious, but I miss it.
Sam
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v3 6/6] fbdev: Rename fb_mem*() helpers
Hi Thomas.
On Tue, May 02, 2023 at 03:02:23PM +0200, Thomas Zimmermann wrote:
> Update the names of the fb_mem*() helpers to be consistent with their
> regular counterparts. Hence, fb_memset() now becomes fb_memset_io(),
> fb_memcpy_fromfb() now becomes fb_memcpy_fromio() and fb_memcpy_tofb()
> becomes fb_memcpy_toio(). No functional changes.
>
> Signed-off-by: Thomas Zimmermann
> ---
...
>
> -#ifndef fb_memcpy_fromfb
> -static inline void fb_memcpy_fromfb(void *to, const volatile void __iomem
> *from, size_t n)
> +#ifndef fb_memcpy_fromio
> +static inline void fb_memcpy_fromio(void *to, const volatile void __iomem
> *from, size_t n)
> {
> memcpy_fromio(to, from, n);
> }
> -#define fb_memcpy_fromfb fb_memcpy_fromfb
> +#define fb_memcpy_fromio fb_memcpy_fromio
> #endif
>
> -#ifndef fb_memcpy_tofb
> -static inline void fb_memcpy_tofb(volatile void __iomem *to, const void
> *from, size_t n)
> +#ifndef fb_memcpy_toio
> +static inline void fb_memcpy_toio(volatile void __iomem *to, const void
> *from, size_t n)
> {
> memcpy_toio(to, from, n);
> }
> -#define fb_memcpy_tofb fb_memcpy_tofb
> +#define fb_memcpy_toio fb_memcpy_toio
> #endif
>
> #ifndef fb_memset
> -static inline void fb_memset(volatile void __iomem *addr, int c, size_t n)
> +static inline void fb_memset_io(volatile void __iomem *addr, int c, size_t n)
> {
> memset_io(addr, c, n);
> }
> -#define fb_memset fb_memset
> +#define fb_memset fb_memset_io
The static inlines wrappers does not provide any value, and could be replaced by
direct calls to memcpy_fromio(), memcpy_toio(), memset_io().
If you decide to keep the wrappers I will not hold you back, so the
patch has my:
Reviewed-by: Sam Ravnborg
But I prefer the direct calls without the wrappers
Sam
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v3 5/6] fbdev: Move framebuffer I/O helpers into
Hi Thomas, > > But I am missing something somewhere as I cannot see how this builds. > > asm-generic now provide the fb_read/fb_write helpers. > > But for example sparc has an architecture specifc fb.h so it will not > > use the asm-generic variant. So I wonder how sparc get hold of the > > asm-generic fb.h file? > > All architecture's files include , so that they > all get the interfaces which they don't define themselves. For Sparc, this > is at [1]. > > Best regards > Thomas > > > [1] > https://cgit.freedesktop.org/drm/drm-tip/tree/arch/sparc/include/asm/fb.h#n19 > > > > > Maybe it is obvious, but I miss it. OK, it was obvious and I missed it. I looked at the mainline kernel, and not the drm-tip variant. Sorry for the noise. Sam ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v3 6/6] fbdev: Rename fb_mem*() helpers
Hi Thomas,
On Wed, May 03, 2023 at 10:15:46AM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 02.05.23 um 22:08 schrieb Sam Ravnborg:
> > Hi Thomas.
> >
> > On Tue, May 02, 2023 at 03:02:23PM +0200, Thomas Zimmermann wrote:
> > > Update the names of the fb_mem*() helpers to be consistent with their
> > > regular counterparts. Hence, fb_memset() now becomes fb_memset_io(),
> > > fb_memcpy_fromfb() now becomes fb_memcpy_fromio() and fb_memcpy_tofb()
> > > becomes fb_memcpy_toio(). No functional changes.
> > >
> > > Signed-off-by: Thomas Zimmermann
> > > ---
> > ...
> > > -#ifndef fb_memcpy_fromfb
> > > -static inline void fb_memcpy_fromfb(void *to, const volatile void
> > > __iomem *from, size_t n)
> > > +#ifndef fb_memcpy_fromio
> > > +static inline void fb_memcpy_fromio(void *to, const volatile void
> > > __iomem *from, size_t n)
> > > {
> > > memcpy_fromio(to, from, n);
> > > }
> > > -#define fb_memcpy_fromfb fb_memcpy_fromfb
> > > +#define fb_memcpy_fromio fb_memcpy_fromio
> > > #endif
> > > -#ifndef fb_memcpy_tofb
> > > -static inline void fb_memcpy_tofb(volatile void __iomem *to, const void
> > > *from, size_t n)
> > > +#ifndef fb_memcpy_toio
> > > +static inline void fb_memcpy_toio(volatile void __iomem *to, const void
> > > *from, size_t n)
> > > {
> > > memcpy_toio(to, from, n);
> > > }
> > > -#define fb_memcpy_tofb fb_memcpy_tofb
> > > +#define fb_memcpy_toio fb_memcpy_toio
> > > #endif
> > > #ifndef fb_memset
> > > -static inline void fb_memset(volatile void __iomem *addr, int c, size_t
> > > n)
> > > +static inline void fb_memset_io(volatile void __iomem *addr, int c,
> > > size_t n)
> > > {
> > > memset_io(addr, c, n);
> > > }
> > > -#define fb_memset fb_memset
> > > +#define fb_memset fb_memset_io
> >
> > The static inlines wrappers does not provide any value, and could be
> > replaced by
> > direct calls to memcpy_fromio(), memcpy_toio(), memset_io().
> >
> > If you decide to keep the wrappers I will not hold you back, so the
> > patch has my:
> > Reviewed-by: Sam Ravnborg
> >
> > But I prefer the direct calls without the wrappers
>
> At first I was also skeptical if those fb_mem*() wrappers are needed. But
> Arnd mentioned that there are subtle differences between the current code
> and Linux' mem*_io() functions. Keeping the wrappers might be needed.
Saw the dialog, and agree that keeping current behaviour is the way to
go for now even if this is more code and wrappers.
Sam
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v4 4/6] fbdev: Include instead of
Hi Thomas, On Thu, May 04, 2023 at 09:45:37AM +0200, Thomas Zimmermann wrote: > Replace include statements for with . Fixes > the coding style: if a header is available in asm/ and linux/, it > is preferable to include the header from linux/. This only affects > a few source files, most of which already include . > > Suggested-by: Sam Ravnborg > Signed-off-by: Thomas Zimmermann Thanks, Reviewed-by: Sam Ravnborg ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 09/22] [v2] arch: fix asm-offsets.c building with -Wmissing-prototypes
On Wed, Nov 08, 2023 at 01:58:30PM +0100, Arnd Bergmann wrote: > From: Arnd Bergmann > > When -Wmissing-prototypes is enabled, the some asm-offsets.c files fail > to build, even when this warning is disabled in the Makefile for normal > files: > > arch/sparc/kernel/asm-offsets.c:22:5: error: no previous prototype for > 'sparc32_foo' [-Werror=missing-prototypes] > arch/sparc/kernel/asm-offsets.c:48:5: error: no previous prototype for 'foo' > [-Werror=missing-prototypes] > > Address this by making use of the same trick as x86, marking these > functions as 'static __used' to avoid the need for a prototype > by not drop them in dead-code elimination. > > Suggested-by: Masahiro Yamada > Link: > https://lore.kernel.org/lkml/cak7lnarfemfk0du4hed19ex_g6tuc5wg0zp+l1ayvdpof4y...@mail.gmail.com/ > Signed-off-by: Arnd Bergmann Looks good. I sometimes looks at sparc patches so I looked at this one. Reviewed-by: Sam Ravnborg ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v2 3/3] arch: Rename fbdev header and source files
Hi Thomas,
On Wed, Mar 27, 2024 at 09:41:31PM +0100, Thomas Zimmermann wrote:
> The per-architecture fbdev code has no dependencies on fbdev and can
> be used for any video-related subsystem. Rename the files to 'video'.
> Use video-sti.c on parisc as the source file depends on CONFIG_STI_CORE.
>
> Further update all includes statements, includ guards, and Makefiles.
^ missing 'e'
> Also update a few strings and comments to refer to video instead of
> fbdev.
>
> Signed-off-by: Thomas Zimmermann
> Cc: Vineet Gupta
> Cc: Catalin Marinas
> Cc: Will Deacon
> Cc: Huacai Chen
> Cc: WANG Xuerui
> Cc: Geert Uytterhoeven
> Cc: Thomas Bogendoerfer
> Cc: "James E.J. Bottomley"
> Cc: Helge Deller
> Cc: Michael Ellerman
> Cc: Nicholas Piggin
> Cc: Yoshinori Sato
> Cc: Rich Felker
> Cc: John Paul Adrian Glaubitz
> Cc: "David S. Miller"
> Cc: Andreas Larsson
> Cc: Thomas Gleixner
> Cc: Ingo Molnar
> Cc: Borislav Petkov
> Cc: Dave Hansen
> Cc: x...@kernel.org
> Cc: "H. Peter Anvin"
If the patch is changed to use the Kbuild file to pick the generic
variant of video.h then it is:
Reviewed-by: Sam Ravnborg
I also added an unrelated sparc comment, that can be addressed another
time.
Sam
> ---
> arch/arc/include/asm/fb.h| 8
> arch/arc/include/asm/video.h | 8
> arch/arm/include/asm/fb.h| 6 --
> arch/arm/include/asm/video.h | 6 ++
> arch/arm64/include/asm/fb.h | 10 --
> arch/arm64/include/asm/video.h | 10 ++
> arch/loongarch/include/asm/{fb.h => video.h} | 8
> arch/m68k/include/asm/{fb.h => video.h} | 8
> arch/mips/include/asm/{fb.h => video.h} | 12 ++--
> arch/parisc/include/asm/{fb.h => video.h}| 8
> arch/parisc/video/Makefile | 2 +-
> arch/parisc/video/{fbdev.c => video-sti.c} | 2 +-
> arch/powerpc/include/asm/{fb.h => video.h} | 8
> arch/powerpc/kernel/pci-common.c | 2 +-
> arch/sh/include/asm/fb.h | 7 ---
> arch/sh/include/asm/video.h | 7 +++
> arch/sparc/include/asm/{fb.h => video.h} | 8
> arch/sparc/video/Makefile| 2 +-
> arch/sparc/video/{fbdev.c => video.c}| 4 ++--
> arch/x86/include/asm/{fb.h => video.h} | 8
> arch/x86/video/Makefile | 2 +-
> arch/x86/video/{fbdev.c => video.c} | 3 ++-
> include/asm-generic/Kbuild | 2 +-
> include/asm-generic/{fb.h => video.h}| 6 +++---
> include/linux/fb.h | 2 +-
> 25 files changed, 75 insertions(+), 74 deletions(-)
> delete mode 100644 arch/arc/include/asm/fb.h
> create mode 100644 arch/arc/include/asm/video.h
> delete mode 100644 arch/arm/include/asm/fb.h
> create mode 100644 arch/arm/include/asm/video.h
> delete mode 100644 arch/arm64/include/asm/fb.h
> create mode 100644 arch/arm64/include/asm/video.h
> rename arch/loongarch/include/asm/{fb.h => video.h} (86%)
> rename arch/m68k/include/asm/{fb.h => video.h} (86%)
> rename arch/mips/include/asm/{fb.h => video.h} (76%)
> rename arch/parisc/include/asm/{fb.h => video.h} (68%)
> rename arch/parisc/video/{fbdev.c => video-sti.c} (96%)
> rename arch/powerpc/include/asm/{fb.h => video.h} (76%)
> delete mode 100644 arch/sh/include/asm/fb.h
> create mode 100644 arch/sh/include/asm/video.h
> rename arch/sparc/include/asm/{fb.h => video.h} (89%)
> rename arch/sparc/video/{fbdev.c => video.c} (86%)
> rename arch/x86/include/asm/{fb.h => video.h} (77%)
> rename arch/x86/video/{fbdev.c => video.c} (97%)
> rename include/asm-generic/{fb.h => video.h} (96%)
>
> diff --git a/arch/arc/include/asm/fb.h b/arch/arc/include/asm/fb.h
> deleted file mode 100644
> index 9c2383d29cbb9..0
> --- a/arch/arc/include/asm/fb.h
> +++ /dev/null
> @@ -1,8 +0,0 @@
> -/* SPDX-License-Identifier: GPL-2.0 */
> -
> -#ifndef _ASM_FB_H_
> -#define _ASM_FB_H_
> -
> -#include
> -
> -#endif /* _ASM_FB_H_ */
> diff --git a/arch/arc/include/asm/video.h b/arch/arc/include/asm/video.h
> new file mode 100644
> index 0..8ff7263727fe7
> --- /dev/null
> +++ b/arch/arc/include/asm/video.h
> @@ -0,0 +1,8 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +
> +#ifndef _ASM_VIDEO_H_
> +#define _ASM_VIDEO_H_
> +
> +#include
> +
> +#endif /* _ASM_VIDEO_H_ */
arch/arc/i
Re: [PATCH v2 1/3] arch: Select fbdev helpers with CONFIG_VIDEO
On Wed, Mar 27, 2024 at 09:41:29PM +0100, Thomas Zimmermann wrote: > Various Kconfig options selected the per-architecture helpers for > fbdev. But none of the contained code depends on fbdev. Standardize > on CONFIG_VIDEO, which will allow to add more general helpers for > video functionality. > > CONFIG_VIDEO protects each architecture's video/ directory. This > allows for the use of more fine-grained control for each directory's > files, such as the use of CONFIG_STI_CORE on parisc. > > v2: > - sparc: rebased onto Makefile changes > > Signed-off-by: Thomas Zimmermann > Cc: "James E.J. Bottomley" > Cc: Helge Deller > Cc: "David S. Miller" > Cc: Andreas Larsson > Cc: Thomas Gleixner > Cc: Ingo Molnar > Cc: Borislav Petkov > Cc: Dave Hansen > Cc: x...@kernel.org > Cc: "H. Peter Anvin" Reviewed-by: Sam Ravnborg ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v2 2/3] arch: Remove struct fb_info from video helpers
Hi Thomas, On Wed, Mar 27, 2024 at 09:41:30PM +0100, Thomas Zimmermann wrote: > The per-architecture video helpers do not depend on struct fb_info > or anything else from fbdev. Remove it from the interface and replace > fb_is_primary_device() with video_is_primary_device(). The new helper > is similar in functionality, but can operate on non-fbdev devices. > > Signed-off-by: Thomas Zimmermann > Cc: "James E.J. Bottomley" > Cc: Helge Deller > Cc: "David S. Miller" > Cc: Andreas Larsson > Cc: Thomas Gleixner > Cc: Ingo Molnar > Cc: Borislav Petkov > Cc: Dave Hansen > Cc: x...@kernel.org > Cc: "H. Peter Anvin" Reviewed-by: Sam Ravnborg ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
