Re: [PATCH v5 04/15] sparc: simplify module_alloc()

2024-04-23 Thread Sam Ravnborg
Hi Mike,
On Mon, Apr 22, 2024 at 12:44:25PM +0300, Mike Rapoport wrote:
> From: "Mike Rapoport (IBM)" 
> 
> Define MODULES_VADDR and MODULES_END as VMALLOC_START and VMALLOC_END
> for 32-bit and reduce module_alloc() to
> 
>   __vmalloc_node_range(size, 1, MODULES_VADDR, MODULES_END, ...)
> 
> as with the new defines the allocations becames identical for both 32
> and 64 bits.
> 
> While on it, drop unsed include of 
> 
> Suggested-by: Sam Ravnborg 
> Signed-off-by: Mike Rapoport (IBM) 

Looks good.
Reviewed-by: Sam Ravnborg 



Re: [PATCH v4 06/15] mm/execmem, arch: convert simple overrides of module_alloc to execmem

2024-04-11 Thread Sam Ravnborg
Hi Mike.

On Thu, Apr 11, 2024 at 07:00:42PM +0300, Mike Rapoport wrote:
> From: "Mike Rapoport (IBM)" 
> 
> Several architectures override module_alloc() only to define address
> range for code allocations different than VMALLOC address space.
> 
> Provide a generic implementation in execmem that uses the parameters for
> address space ranges, required alignment and page protections provided
> by architectures.
> 
> The architectures must fill execmem_info structure and implement
> execmem_arch_setup() that returns a pointer to that structure. This way the
> execmem initialization won't be called from every architecture, but rather
> from a central place, namely a core_initcall() in execmem.
> 
> The execmem provides execmem_alloc() API that wraps __vmalloc_node_range()
> with the parameters defined by the architectures.  If an architecture does
> not implement execmem_arch_setup(), execmem_alloc() will fall back to
> module_alloc().
> 
> Signed-off-by: Mike Rapoport (IBM) 
> ---

This code snippet could be more readable ...
> diff --git a/arch/sparc/kernel/module.c b/arch/sparc/kernel/module.c
> index 66c45a2764bc..b70047f944cc 100644
> --- a/arch/sparc/kernel/module.c
> +++ b/arch/sparc/kernel/module.c
> @@ -14,6 +14,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
> @@ -21,34 +22,26 @@
>  
>  #include "entry.h"
>  
> +static struct execmem_info execmem_info __ro_after_init = {
> + .ranges = {
> + [EXECMEM_DEFAULT] = {
>  #ifdef CONFIG_SPARC64
> -
> -#include 
> -
> -static void *module_map(unsigned long size)
> -{
> - if (PAGE_ALIGN(size) > MODULES_LEN)
> - return NULL;
> - return __vmalloc_node_range(size, 1, MODULES_VADDR, MODULES_END,
> - GFP_KERNEL, PAGE_KERNEL, 0, NUMA_NO_NODE,
> - __builtin_return_address(0));
> -}
> + .start = MODULES_VADDR,
> + .end = MODULES_END,
>  #else
> -static void *module_map(unsigned long size)
> + .start = VMALLOC_START,
> + .end = VMALLOC_END,
> +#endif
> + .alignment = 1,
> + },
> + },
> +};
> +
> +struct execmem_info __init *execmem_arch_setup(void)
>  {
> - return vmalloc(size);
> -}
> -#endif /* CONFIG_SPARC64 */
> -
> -void *module_alloc(unsigned long size)
> -{
> - void *ret;
> -
> - ret = module_map(size);
> - if (ret)
> - memset(ret, 0, size);
> + execmem_info.ranges[EXECMEM_DEFAULT].pgprot = PAGE_KERNEL;
>  
> - return ret;
> + return _info;
>  }
>  
>  /* Make generic code ignore STT_REGISTER dummy undefined symbols.  */

... if the following was added:

diff --git a/arch/sparc/include/asm/pgtable_32.h 
b/arch/sparc/include/asm/pgtable_32.h
index 9e85d57ac3f2..62bcafe38b1f 100644
--- a/arch/sparc/include/asm/pgtable_32.h
+++ b/arch/sparc/include/asm/pgtable_32.h
@@ -432,6 +432,8 @@ static inline int io_remap_pfn_range(struct vm_area_struct 
*vma,

 #define VMALLOC_START   _AC(0xfe60,UL)
 #define VMALLOC_END _AC(0xffc0,UL)
+#define MODULES_VADDR   VMALLOC_START
+#define MODULES_END VMALLOC_END


Then the #ifdef CONFIG_SPARC64 could be dropped and the code would be
the same for 32 and 64 bits.

Just a drive-by comment.

Sam



Re: [PATCH 03/10] drm/atmel-hlcdc: Rename custom plane state variable

2021-01-15 Thread Sam Ravnborg
On Fri, Jan 15, 2021 at 01:56:55PM +0100, Maxime Ripard wrote:
> Subsequent reworks will pass the global atomic state in the function
> prototype, and atomic_check and atomic_update already have such a
> variable already. Let's change them to ease the rework.
> 
> Signed-off-by: Maxime Ripard 
Acked-by: Sam Ravnborg 

I assume you will push this patch as part of the series.

Sam


Re: [PATCH 00/31] Rid W=1 warnings from Video

2021-01-13 Thread Sam Ravnborg
Hi Lee,

On Wed, Jan 13, 2021 at 02:49:38PM +, Lee Jones wrote:
> This set is part of a larger effort attempting to clean-up W=1
> kernel builds, which are currently overwhelmingly riddled with
> niggly little warnings.
> 
> This patch-set clears all of the W=1 warnings currently residing
> in drivers/video.

I am sorry to say that I expect most of your nice patches to clash
with patches that is already present in drm-misc-next.

drivers/video/ are warning free with W=1 in drm-misc-next today.

I do not know why drm-misc-next is not yet pullled into linux-next.

Sam


Re: Old platforms: bring out your dead

2021-01-10 Thread Sam Ravnborg
Hi all,
> Hi Arnd!
> 
> (Please let's have this cross-posted for more visibility. I only learned 
> about this
>  while reading Phoronix news)
> 
> > I also looked at non-ARM platforms while preparing for my article. Some of
> > these look like they are no longer actively maintained or used, but I'm not
> > doing anything about those unless the maintainers would like me to:
> > 

> > * sparc/sun4m: A patch for removing 32-bit Sun sparc support (not LEON)
> >is currently under review
> 
> I don't think this has reached any agreement yet. Multiple people want it to 
> stay.

None of the people that replied have any real use of the sun4m port,
they only wanted it to stay because they had some machines or such.
In other words - people will be sad if we sunset sun4m, but it will not
hurt anyone as there are no users left.

I will include the above summary when I post v2 of the patch to sunset
sun4m and sun4d. Then we will see what we conclude in the end.

Right now in am in demolition mode as I have a new house that requires a
total refactoring. So linux stuff is lower on the priority list so v2
will wait until I have time to do any necessary follow-up.

Sam


Re: [PATCHv1] video: omapfb2: Make standard and custom DSI command mode panel driver mutually exclusive

2021-01-08 Thread Sam Ravnborg
Hi Sebatian,

On Fri, Jan 08, 2021 at 12:24:41PM +0100, Sebastian Reichel wrote:
> Standard DRM panel driver for DSI command mode panel used by omapfb2 is also
> available now. Just like the other panels its module name clashes with the
> module from drivers/video/fbdev/omap2/omapfb/displays, part of the deprecated
> omapfb2 fbdev driver. As omapfb2 can only be compiled when the omapdrm driver
> is disabled, and the DRM panel drivers are useless in that case, make the
> omapfb2 panel depend on the standard DRM panels being disabled to fix
> the name clash.
> 
> Fixes: cf64148abcfd ("drm/panel: Move OMAP's DSI command mode panel driver")
> Reported-by: Stephen Rothwell 
> Signed-off-by: Sebastian Reichel 

For a backport this looks good:
Acked-by: Sam Ravnborg 

But why is it it we need omapfb at all when we have omapdrm?
Can we sunset all or some parts of omap support in video/?
If not, what is missing to do so.

Sam

> ---
> Laurent introduced and fixed the same issue for the other panels and
> this simply replicates the same solution for DSI command mode panel.
> ---
>  drivers/video/fbdev/omap2/omapfb/displays/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/video/fbdev/omap2/omapfb/displays/Kconfig 
> b/drivers/video/fbdev/omap2/omapfb/displays/Kconfig
> index 744416dc530e..384d74a126dc 100644
> --- a/drivers/video/fbdev/omap2/omapfb/displays/Kconfig
> +++ b/drivers/video/fbdev/omap2/omapfb/displays/Kconfig
> @@ -43,6 +43,7 @@ config FB_OMAP2_PANEL_DPI
>  config FB_OMAP2_PANEL_DSI_CM
>   tristate "Generic DSI Command Mode Panel"
>   depends on BACKLIGHT_CLASS_DEVICE
> + depends on DRM_PANEL_DSI_CM = n
>   help
> Driver for generic DSI command mode panels.
>  
> -- 
> 2.29.2


Re: [PATCH] dt-bindings: Drop redundant maxItems/items

2020-12-23 Thread Sam Ravnborg
Hi Rob,

> > With one comment below,
> > Acked-by: Sam Ravnborg 
> >
> > > ---
> > > diff --git a/Documentation/devicetree/bindings/usb/renesas,usbhs.yaml 
> > > b/Documentation/devicetree/bindings/usb/renesas,usbhs.yaml
> > > index 737c1f47b7de..54c361d4a7af 100644
> > > --- a/Documentation/devicetree/bindings/usb/renesas,usbhs.yaml
> > > +++ b/Documentation/devicetree/bindings/usb/renesas,usbhs.yaml
> > > @@ -74,11 +74,8 @@ properties:
> > >
> > >phys:
> > >  maxItems: 1
> > > -items:
> > > -  - description: phandle + phy specifier pair.
> >
> > The description may help some people, so keeping the
> > description and deleting maxItems would maybe be better.
> 
> Do we really want to describe 'phys' hundreds of times? No.
Agree, for common properties we as a minimum want a phy-common.yaml
or some such - and have the description exactly once.

> The
> question I ask on the descriptions is could it be generated instead.
That could also be an idea, but assuming most people look at the source
then the same "most people" would miss the generated descriptions.

But to be clear - I see that phys: is a commonly used property so no
problem to have the description dropped here.
Ack still stands.

Sam


Re: [PATCH] dt-bindings: Drop redundant maxItems/items

2020-12-21 Thread Sam Ravnborg
Hi Rob,

On Mon, Dec 21, 2020 at 09:06:45PM -0700, Rob Herring wrote:
> 'maxItems' equal to the 'items' list length is redundant. 'maxItems' is
> preferred for a single entry while greater than 1 should have an 'items'
> list.
> 
> A meta-schema check for this is pending once these existing cases are
> fixed.
> 
> Cc: Laurent Pinchart 
> Cc: Vinod Koul 
> Cc: Mark Brown 
> Cc: Greg Kroah-Hartman 
> Cc: Jassi Brar 
> Cc: dri-de...@lists.freedesktop.org
> Cc: dmaeng...@vger.kernel.org
> Cc: alsa-de...@alsa-project.org
> Cc: linux-...@vger.kernel.org
> Signed-off-by: Rob Herring 

With one comment below,
Acked-by: Sam Ravnborg 

> ---
> diff --git a/Documentation/devicetree/bindings/usb/renesas,usbhs.yaml 
> b/Documentation/devicetree/bindings/usb/renesas,usbhs.yaml
> index 737c1f47b7de..54c361d4a7af 100644
> --- a/Documentation/devicetree/bindings/usb/renesas,usbhs.yaml
> +++ b/Documentation/devicetree/bindings/usb/renesas,usbhs.yaml
> @@ -74,11 +74,8 @@ properties:
>  
>phys:
>  maxItems: 1
> -items:
> -  - description: phandle + phy specifier pair.

The description may help some people, so keeping the
description and deleting maxItems would maybe be better.

Sam


Re: [PATCH] dt-bindings: Drop unnecessary *-supply schemas properties

2020-12-21 Thread Sam Ravnborg
Hi Rob

On Mon, Dec 21, 2020 at 04:46:59PM -0700, Rob Herring wrote:
> *-supply properties are always a single phandle, so binding schemas
> don't need a type $ref nor 'maxItems'.
> 
> A meta-schema check for this is pending once these existing cases are
> fixed.
> 
> Cc: Jonathan Cameron 
> Cc: Dmitry Torokhov 
> Cc: Laurent Pinchart 
> Cc: Mauro Carvalho Chehab 
> Cc: Sakari Ailus 
> Cc: Lee Jones 
> Cc: Mark Brown 
> Cc: Maxime Ripard 
> Cc: dri-de...@lists.freedesktop.org
> Cc: linux-...@vger.kernel.org
> Cc: linux-in...@vger.kernel.org
> Cc: linux-me...@vger.kernel.org
> Signed-off-by: Rob Herring 

For the Documentation/devicetree/bindings/display/* parts:
Acked-by: Sam Ravnborg 

Sam


Re: [RFC PATCH 0/13] sparc32: sunset sun4m and sun4d

2020-12-19 Thread Sam Ravnborg
Hi all,

On Fri, Dec 18, 2020 at 07:43:34PM +0100, Sam Ravnborg wrote:
> The sun4m and sun4d based SPARC machines was very popular in the
> 90'ties and was then replaced by the more powerful sparc64
> class of machines.

I have received a couple of mails in private.
One said it was better to sunset now when it is actually working,
so there is a working state to return to.
Another said that it would be a shame to sunset sun4m and sun4d because
there are so many machines around, and netbsd is also active on the
sparc32 area.


The second mail also re-reminded me of an interesting project
implementing SPARC V8 and the sun4m platform in VHDL.
See https://temlib.org - the author posted a new blog post a
few months ago.

temlib is, to my best knowledge, an impressive one-man project.
And this is not enough to keep sun4m around as this would
require real users that cannot just stay at their current kernel
but who need to follow upstream.

Please keep the inputs coming independent if you are pro or not
for the sunset of sun4m and sun4d.

Sam


Re: [PATCH v1 01/13] sparc32: Drop sun4m/sun4d support from head_32.S

2020-12-18 Thread Sam Ravnborg
Hi Jan,

On Fri, Dec 18, 2020 at 07:52:08PM +0100, Jan Engelhardt wrote:
> 
> On Friday 2020-12-18 19:43, Sam Ravnborg wrote:
> > notsup:
> >-.asciz  "Sparc-Linux sun4/sun4c or MMU-less not supported\n\n"
> >-.align 4
> >-
> >-sun4e_notsup:
> >-.asciz  "Sparc-Linux sun4e support does not exist\n\n"
> >+.asciz  "Sparc-Linux sun4* or MMU-less not supported\n\n"
> > .align 4
> 
> The asterisk may lead to a moment of bewilderment; sun4u/sun4v are still 
> supported.
Noted, I will come up with something better.

Sam


Re: [PATCH v1 02/13] sparc32: Drop floppy support

2020-12-18 Thread Sam Ravnborg
On Fri, Dec 18, 2020 at 09:57:47PM +0100, Arnd Bergmann wrote:
> On Fri, Dec 18, 2020 at 7:43 PM Sam Ravnborg  wrote:
> >
> > LEON do not have floppy support so we can drop it
> >
> > Signed-off-by: Sam Ravnborg 
> > Cc: "David S. Miller" 
> > Cc: Sam Ravnborg 
> > Cc: Mike Rapoport 
> > Cc: Andrew Morton 
> > Cc: Denis Efremov 
> > Cc: Willy Tarreau 
> > Cc: Christian Brauner 
> > Cc: sparcli...@vger.kernel.org
> > Cc: Arnd Bergmann 
> > Cc: Andreas Larsson 
> > ---
> >  arch/sparc/Kconfig |   2 +-
> >  arch/sparc/include/asm/floppy.h| 786 -
> >  arch/sparc/include/asm/floppy_32.h | 393 ---
> >  arch/sparc/include/asm/floppy_64.h | 779 
> 
> Rather than renaming the floppy_64.h to floppy.h, it might be easier to just
> remove the #else from floppy.h, similar to what asm/adi.h does.
That is what I had first but then thought it pointless with a wrapper
file. I will revert back to use floppy_64.h for now - we can always
consolidate header files later.

Sam


[PATCH v1 03/13] sparc32: Drop sun4m specific led driver

2020-12-18 Thread Sam Ravnborg
The led driver is only relevant for the sun4m machines.

Signed-off-by: Sam Ravnborg 
Cc: "David S. Miller" 
Cc: Sam Ravnborg 
Cc: Christian Brauner 
Cc: Stephen Rothwell 
Cc: Alexey Dobriyan 
Cc: Andrew Morton 
Cc: sparcli...@vger.kernel.org
Cc: Arnd Bergmann 
Cc: Andreas Larsson 
---
 arch/sparc/Kconfig |   9 ---
 arch/sparc/kernel/Makefile |   1 -
 arch/sparc/kernel/led.c| 146 -
 3 files changed, 156 deletions(-)
 delete mode 100644 arch/sparc/kernel/led.c

diff --git a/arch/sparc/Kconfig b/arch/sparc/Kconfig
index 2c6d8d834f9a..8447f5b7bb90 100644
--- a/arch/sparc/Kconfig
+++ b/arch/sparc/Kconfig
@@ -337,15 +337,6 @@ config SUN_PM
  Enable power management and CPU standby features on supported
  SPARC platforms.
 
-config SPARC_LED
-   tristate "Sun4m LED driver"
-   depends on SPARC32
-   help
- This driver toggles the front-panel LED on sun4m systems
- in a user-specifiable manner.  Its state can be probed
- by reading /proc/led and its blinking mode can be changed
- via writes to /proc/led
-
 config SERIAL_CONSOLE
bool
depends on SPARC32
diff --git a/arch/sparc/kernel/Makefile b/arch/sparc/kernel/Makefile
index d3a0e072ebe8..b6c9ca1d6c66 100644
--- a/arch/sparc/kernel/Makefile
+++ b/arch/sparc/kernel/Makefile
@@ -89,7 +89,6 @@ obj-$(CONFIG_SUN_PM)  += apc.o pmc.o
 
 obj-$(CONFIG_MODULES) += module.o
 obj-$(CONFIG_MODULES) += sparc_ksyms.o
-obj-$(CONFIG_SPARC_LED)   += led.o
 obj-$(CONFIG_KGDB)+= kgdb_$(BITS).o
 
 
diff --git a/arch/sparc/kernel/led.c b/arch/sparc/kernel/led.c
deleted file mode 100644
index bd48575172c3..
--- a/arch/sparc/kernel/led.c
+++ /dev/null
@@ -1,146 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-only
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#include 
-
-#define LED_MAX_LENGTH 8 /* maximum chars written to proc file */
-
-static inline void led_toggle(void)
-{
-   unsigned char val = get_auxio();
-   unsigned char on, off;
-
-   if (val & AUXIO_LED) {
-   on = 0;
-   off = AUXIO_LED;
-   } else {
-   on = AUXIO_LED;
-   off = 0;
-   }
-
-   set_auxio(on, off);
-}
-
-static struct timer_list led_blink_timer;
-static unsigned long led_blink_timer_timeout;
-
-static void led_blink(struct timer_list *unused)
-{
-   unsigned long timeout = led_blink_timer_timeout;
-
-   led_toggle();
-
-   /* reschedule */
-   if (!timeout) { /* blink according to load */
-   led_blink_timer.expires = jiffies +
-   ((1 + (avenrun[0] >> FSHIFT)) * HZ);
-   } else { /* blink at user specified interval */
-   led_blink_timer.expires = jiffies + (timeout * HZ);
-   }
-   add_timer(_blink_timer);
-}
-
-static int led_proc_show(struct seq_file *m, void *v)
-{
-   if (get_auxio() & AUXIO_LED)
-   seq_puts(m, "on\n");
-   else
-   seq_puts(m, "off\n");
-   return 0;
-}
-
-static int led_proc_open(struct inode *inode, struct file *file)
-{
-   return single_open(file, led_proc_show, NULL);
-}
-
-static ssize_t led_proc_write(struct file *file, const char __user *buffer,
- size_t count, loff_t *ppos)
-{
-   char *buf = NULL;
-
-   if (count > LED_MAX_LENGTH)
-   count = LED_MAX_LENGTH;
-
-   buf = memdup_user_nul(buffer, count);
-   if (IS_ERR(buf))
-   return PTR_ERR(buf);
-
-   /* work around \n when echo'ing into proc */
-   if (buf[count - 1] == '\n')
-   buf[count - 1] = '\0';
-
-   /* before we change anything we want to stop any running timers,
-* otherwise calls such as on will have no persistent effect
-*/
-   del_timer_sync(_blink_timer);
-
-   if (!strcmp(buf, "on")) {
-   auxio_set_led(AUXIO_LED_ON);
-   } else if (!strcmp(buf, "toggle")) {
-   led_toggle();
-   } else if ((*buf > '0') && (*buf <= '9')) {
-   led_blink_timer_timeout = simple_strtoul(buf, NULL, 10);
-   led_blink(_blink_timer);
-   } else if (!strcmp(buf, "load")) {
-   led_blink_timer_timeout = 0;
-   led_blink(_blink_timer);
-   } else {
-   auxio_set_led(AUXIO_LED_OFF);
-   }
-
-   kfree(buf);
-
-   return count;
-}
-
-static const struct proc_ops led_proc_ops = {
-   .proc_open  = led_proc_open,
-   .proc_read  = seq_read,
-   .proc_lseek = seq_lseek,
-   .proc_release   = single_release,
-   .proc_write = led_proc_write,
-};
-
-static struct proc_dir_entry *led;
-
-#define LED_VERSION"0.1"
-
-static int __init led_init(void)
-{
-   ti

[PATCH v1 08/13] sparc32: Drop sun4d/sun4m smp support

2020-12-18 Thread Sam Ravnborg
Drop the sun4m and sun4d smp support code.

The sparc32 kernel will not boot unless this is a LEON system,
so drop checks for other systems as they will not trigger.

Signed-off-by: Sam Ravnborg 
Cc: Sam Ravnborg 
Cc: Christian Brauner 
Cc: "David S. Miller" 
Cc: Mike Rapoport 
Cc: Andrew Morton 
Cc: Pekka Enberg 
Cc: Geert Uytterhoeven 
Cc: Will Deacon 
Cc: Thomas Gleixner 
Cc: Arnd Bergmann 
Cc: Andreas Larsson 
---
 arch/sparc/kernel/Makefile|   2 +-
 arch/sparc/kernel/smp_32.c| 102 +
 arch/sparc/kernel/sun4d_smp.c | 410 --
 arch/sparc/kernel/sun4m_smp.c | 273 --
 arch/sparc/mm/srmmu.c |  10 +-
 5 files changed, 8 insertions(+), 789 deletions(-)
 delete mode 100644 arch/sparc/kernel/sun4d_smp.c
 delete mode 100644 arch/sparc/kernel/sun4m_smp.c

diff --git a/arch/sparc/kernel/Makefile b/arch/sparc/kernel/Makefile
index 92a9fdbba0a5..5ddc11cfd84a 100644
--- a/arch/sparc/kernel/Makefile
+++ b/arch/sparc/kernel/Makefile
@@ -81,7 +81,7 @@ obj-$(CONFIG_SPARC_GRPCI2)+= leon_pci_grpci2.o
 obj-$(CONFIG_SPARC_GRPCI1)+= leon_pci_grpci1.o
 
 obj-$(CONFIG_SMP) += trampoline_$(BITS).o smp_$(BITS).o
-obj-$(CONFIG_SPARC32_SMP) += sun4m_smp.o sun4d_smp.o leon_smp.o
+obj-$(CONFIG_SPARC32_SMP) += leon_smp.o
 obj-$(CONFIG_SPARC64_SMP) += hvtramp.o
 
 obj-$(CONFIG_SPARC64) += auxio_64.o
diff --git a/arch/sparc/kernel/smp_32.c b/arch/sparc/kernel/smp_32.c
index 50c127ab46d5..bcda7e469da9 100644
--- a/arch/sparc/kernel/smp_32.c
+++ b/arch/sparc/kernel/smp_32.c
@@ -87,29 +87,7 @@ void __init smp_cpus_done(unsigned int max_cpus)
num, bogosum/(50/HZ),
(bogosum/(5000/HZ))%100);
 
-   switch(sparc_cpu_model) {
-   case sun4m:
-   smp4m_smp_done();
-   break;
-   case sun4d:
-   smp4d_smp_done();
-   break;
-   case sparc_leon:
-   leon_smp_done();
-   break;
-   case sun4e:
-   printk("SUN4E\n");
-   BUG();
-   break;
-   case sun4u:
-   printk("SUN4U\n");
-   BUG();
-   break;
-   default:
-   printk("UNKNOWN!\n");
-   BUG();
-   break;
-   }
+   leon_smp_done();
 }
 
 void cpu_panic(void)
@@ -196,29 +174,7 @@ void __init smp_prepare_cpus(unsigned int max_cpus)
 
smp_store_cpu_info(boot_cpu_id);
 
-   switch(sparc_cpu_model) {
-   case sun4m:
-   smp4m_boot_cpus();
-   break;
-   case sun4d:
-   smp4d_boot_cpus();
-   break;
-   case sparc_leon:
-   leon_boot_cpus();
-   break;
-   case sun4e:
-   printk("SUN4E\n");
-   BUG();
-   break;
-   case sun4u:
-   printk("SUN4U\n");
-   BUG();
-   break;
-   default:
-   printk("UNKNOWN!\n");
-   BUG();
-   break;
-   }
+   leon_boot_cpus();
 }
 
 /* Set this up early so that things like the scheduler can init
@@ -257,31 +213,7 @@ void __init smp_prepare_boot_cpu(void)
 
 int __cpu_up(unsigned int cpu, struct task_struct *tidle)
 {
-   int ret=0;
-
-   switch(sparc_cpu_model) {
-   case sun4m:
-   ret = smp4m_boot_one_cpu(cpu, tidle);
-   break;
-   case sun4d:
-   ret = smp4d_boot_one_cpu(cpu, tidle);
-   break;
-   case sparc_leon:
-   ret = leon_boot_one_cpu(cpu, tidle);
-   break;
-   case sun4e:
-   printk("SUN4E\n");
-   BUG();
-   break;
-   case sun4u:
-   printk("SUN4U\n");
-   BUG();
-   break;
-   default:
-   printk("UNKNOWN!\n");
-   BUG();
-   break;
-   }
+   int ret = leon_boot_one_cpu(cpu, tidle);
 
if (!ret) {
cpumask_set_cpu(cpu, _commenced_mask);
@@ -296,19 +228,7 @@ static void arch_cpu_pre_starting(void *arg)
local_ops->cache_all();
local_ops->tlb_all();
 
-   switch(sparc_cpu_model) {
-   case sun4m:
-   sun4m_cpu_pre_starting(arg);
-   break;
-   case sun4d:
-   sun4d_cpu_pre_starting(arg);
-   break;
-   case sparc_leon:
-   leon_cpu_pre_starting(arg);
-   break;
-   default:
-   BUG();
-   }
+   leon_cpu_pre_starting(arg);
 }
 
 static void arch_cpu_pre_online(void *arg)
@@ -323,19 +243,7 @@ static void arch_cpu_pre_online(void *arg)
local_ops->cache_all();
local_ops->tlb_all();
 
-   switch(sparc_cpu_model) {
-   case sun4m:
-   sun4m_cpu_pre_online(arg);
-   brea

[PATCH v1 12/13] sparc32: drop check for sparc_model

2020-12-18 Thread Sam Ravnborg
sparc32 is always LEON, so no need to check for the model.

Signed-off-by: Sam Ravnborg 
Cc: Sam Ravnborg 
Cc: Lorenzo Pieralisi 
Cc: "David S. Miller" 
Cc: Andrew Morton 
Cc: Mike Rapoport 
Cc: Will Deacon 
Cc: Stephen Rothwell 
Cc: Anshuman Khandual 
Cc: Mark Rutland 
Cc: Peter Zijlstra 
Cc: Arvind Sankar 
Cc: Greg Kroah-Hartman 
Cc: Arnd Bergmann 
Cc: Andreas Larsson 
---
 arch/sparc/include/asm/cpu_type.h   | 18 ---
 arch/sparc/include/asm/io_32.h  |  4 +-
 arch/sparc/include/asm/pgtable_32.h | 24 -
 arch/sparc/kernel/devices.c |  7 +--
 arch/sparc/kernel/ioport.c  |  6 +--
 arch/sparc/kernel/leon_pmc.c| 14 +++--
 arch/sparc/kernel/setup_32.c| 79 +
 7 files changed, 12 insertions(+), 140 deletions(-)

diff --git a/arch/sparc/include/asm/cpu_type.h 
b/arch/sparc/include/asm/cpu_type.h
index 2b59799859d1..3e0154c3f41d 100644
--- a/arch/sparc/include/asm/cpu_type.h
+++ b/arch/sparc/include/asm/cpu_type.h
@@ -2,28 +2,10 @@
 #ifndef __ASM_CPU_TYPE_H
 #define __ASM_CPU_TYPE_H
 
-/*
- * Sparc (general) CPU types
- */
-enum sparc_cpu {
-  sun4m   = 0x00,
-  sun4d   = 0x01,
-  sun4e   = 0x02,
-  sun4u   = 0x03, /* V8 ploos ploos */
-  sun_unknown = 0x04,
-  ap1000  = 0x05, /* almost a sun4m */
-  sparc_leon  = 0x06, /* Leon SoC */
-};
-
 #ifdef CONFIG_SPARC32
-extern enum sparc_cpu sparc_cpu_model;
 
 #define SUN4M_NCPUS4  /* Architectural limit of sun4m. 
*/
 
-#else
-
-#define sparc_cpu_model sun4u
-
 #endif
 
 #endif /* __ASM_CPU_TYPE_H */
diff --git a/arch/sparc/include/asm/io_32.h b/arch/sparc/include/asm/io_32.h
index 549f0a72280d..83abe709d120 100644
--- a/arch/sparc/include/asm/io_32.h
+++ b/arch/sparc/include/asm/io_32.h
@@ -138,11 +138,11 @@ void pci_iounmap(struct pci_dev *dev, void __iomem *);
 
 static inline int sbus_can_dma_64bit(void)
 {
-   return 0; /* actually, sparc_cpu_model==sun4d */
+   return 0;
 }
 static inline int sbus_can_burst64(void)
 {
-   return 0; /* actually, sparc_cpu_model==sun4d */
+   return 0;
 }
 struct device;
 void sbus_set_sbus64(struct device *, int);
diff --git a/arch/sparc/include/asm/pgtable_32.h 
b/arch/sparc/include/asm/pgtable_32.h
index 632cdb959542..9c4da6ed81ef 100644
--- a/arch/sparc/include/asm/pgtable_32.h
+++ b/arch/sparc/include/asm/pgtable_32.h
@@ -356,30 +356,6 @@ static inline swp_entry_t __swp_entry(unsigned long type, 
unsigned long offset)
 #define __pte_to_swp_entry(pte)((swp_entry_t) { pte_val(pte) })
 #define __swp_entry_to_pte(x)  ((pte_t) { (x).val })
 
-static inline unsigned long
-__get_phys (unsigned long addr)
-{
-   switch (sparc_cpu_model){
-   case sun4m:
-   case sun4d:
-   return ((srmmu_get_pte (addr) & 0xff00) << 4);
-   default:
-   return 0;
-   }
-}
-
-static inline int
-__get_iospace (unsigned long addr)
-{
-   switch (sparc_cpu_model){
-   case sun4m:
-   case sun4d:
-   return (srmmu_get_pte (addr) >> 28);
-   default:
-   return -1;
-   }
-}
-
 extern unsigned long *sparc_valid_addr_bitmap;
 
 /* Needs to be defined here and not in linux/mm.h, as it is arch dependent */
diff --git a/arch/sparc/kernel/devices.c b/arch/sparc/kernel/devices.c
index b3c2d51b22c4..2963e89611a3 100644
--- a/arch/sparc/kernel/devices.c
+++ b/arch/sparc/kernel/devices.c
@@ -26,8 +26,6 @@
 
 static char *cpu_mid_prop(void)
 {
-   if (sparc_cpu_model == sun4d)
-   return "cpu-id";
return "mid";
 }
 
@@ -40,8 +38,6 @@ static int check_cpu_node(phandle nd, int *cur_inst,
*prom_node = nd;
if (mid) {
*mid = prom_getintdefault(nd, cpu_mid_prop(), 0);
-   if (sparc_cpu_model == sun4m)
-   *mid &= 3;
}
return 0;
}
@@ -92,8 +88,7 @@ static int cpu_mid_compare(phandle nd, int instance, void 
*_arg)
int this_mid;
 
this_mid = prom_getintdefault(nd, cpu_mid_prop(), 0);
-   if (this_mid == desired_mid
-   || (sparc_cpu_model == sun4m && (this_mid & 3) == desired_mid))
+   if (this_mid == desired_mid)
return 0;
return -ENODEV;
 }
diff --git a/arch/sparc/kernel/ioport.c b/arch/sparc/kernel/ioport.c
index 8e1d72a16759..50fb0a8431aa 100644
--- a/arch/sparc/kernel/ioport.c
+++ b/arch/sparc/kernel/ioport.c
@@ -57,10 +57,8 @@
  */
 static inline void dma_make_coherent(unsigned long pa, unsigned long len)
 {
-   if (sparc_cpu_model == sparc_leon) {
-   if (!sparc_leon3_snooping_enabled())
-   leon_flush_dcache_all();
-   }
+   if (!sparc_leon3_snooping_enabled())
+   leon_flush_dcache_all();
 }
 
 static void __iomem *_sparc_ioremap(struct resource *res, u32 bus, u32 pa, int 
sz);

[PATCH v1 10/13] sparc32: Drop mbus support

2020-12-18 Thread Sam Ravnborg
Only used by older SAPRC HW, not used by LEON.

Signed-off-by: Sam Ravnborg 
Cc: Sam Ravnborg 
Cc: Andrew Morton 
Cc: Mike Rapoport 
Cc: Arvind Sankar 
Cc: Greg Kroah-Hartman 
Cc: Pekka Enberg 
Cc: Ira Weiny 
Cc: "David S. Miller" 
Cc: Will Deacon 
Cc: Thomas Gleixner 
Cc: Arnd Bergmann 
Cc: Andreas Larsson 
---
 arch/sparc/include/asm/elf_32.h |  2 -
 arch/sparc/include/asm/mbus.h   | 97 -
 arch/sparc/kernel/cpu.c |  1 -
 arch/sparc/kernel/setup_32.c|  1 -
 arch/sparc/mm/iommu.c   | 18 +-
 arch/sparc/mm/srmmu.c   | 48 
 6 files changed, 3 insertions(+), 164 deletions(-)
 delete mode 100644 arch/sparc/include/asm/mbus.h

diff --git a/arch/sparc/include/asm/elf_32.h b/arch/sparc/include/asm/elf_32.h
index 37a6016c9ccd..b2cca9be55c2 100644
--- a/arch/sparc/include/asm/elf_32.h
+++ b/arch/sparc/include/asm/elf_32.h
@@ -91,8 +91,6 @@ typedef struct {
unsigned intpr_q[64];
 } elf_fpregset_t;
 
-#include 
-
 /*
  * This is used to ensure we don't load something for the wrong architecture.
  */
diff --git a/arch/sparc/include/asm/mbus.h b/arch/sparc/include/asm/mbus.h
deleted file mode 100644
index 8b6dbe701b9b..
--- a/arch/sparc/include/asm/mbus.h
+++ /dev/null
@@ -1,97 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 */
-/*
- * mbus.h:  Various defines for MBUS modules.
- *
- * Copyright (C) 1995 David S. Miller (da...@caip.rutgers.edu)
- */
-
-#ifndef _SPARC_MBUS_H
-#define _SPARC_MBUS_H
-
-#include /* HyperSparc stuff */
-#include   /* Ugh, bug city... */
-
-enum mbus_module {
-   HyperSparc= 0,
-   Swift_ok  = 4,
-   Swift_bad_c   = 5,
-   Swift_lots_o_bugs = 6,
-   Tsunami   = 7,
-   Viking_12 = 8,
-   Viking_2x = 9,
-   Viking_30 = 10,
-   Viking_35 = 11,
-   Viking_new= 12,
-   TurboSparc= 13,
-   SRMMU_INVAL_MOD   = 14,
-};
-
-extern enum mbus_module srmmu_modtype;
-extern unsigned int viking_rev, swift_rev, cypress_rev;
-
-/* HW Mbus module bugs we have to deal with */
-#define HWBUG_COPYBACK_BROKEN0x0001
-#define HWBUG_ASIFLUSH_BROKEN0x0002
-#define HWBUG_VACFLUSH_BITROT0x0004
-#define HWBUG_KERN_ACCBROKEN 0x0008
-#define HWBUG_KERN_CBITBROKEN0x0010
-#define HWBUG_MODIFIED_BITROT0x0020
-#define HWBUG_PC_BADFAULT_ADDR   0x0040
-#define HWBUG_SUPERSCALAR_BAD0x0080
-#define HWBUG_PACINIT_BITROT 0x0100
-
-/* First the module type values. To find out which you have, just load
- * the mmu control register from ASI_M_MMUREG alternate address space and
- * shift the value right 28 bits.
- */
-/* IMPL field means the company which produced the chip. */
-#define MBUS_VIKING0x4   /* bleech, Texas Instruments Module */
-#define MBUS_LSI   0x3   /* LSI Logics */
-#define MBUS_ROSS  0x1   /* Ross is nice */
-#define MBUS_FMI   0x0   /* Fujitsu Microelectronics/Swift */
-
-/* Ross Module versions */
-#define ROSS_604_REV_CDE0x0   /* revisions c, d, and e */
-#define ROSS_604_REV_F  0x1   /* revision f */
-#define ROSS_6050xf   /* revision a, a.1, and a.2 */
-#define ROSS_605_REV_B  0xe   /* revision b */
-
-/* TI Viking Module versions */
-#define VIKING_REV_12   0x1   /* Version 1.2 or SPARCclassic's CPU */
-#define VIKING_REV_20x2   /* Version 2.1, 2.2, 2.3, and 2.4 */
-#define VIKING_REV_30   0x3   /* Version 3.0 */
-#define VIKING_REV_35   0x4   /* Version 3.5 */
-
-/* LSI Logics. */
-#define LSI_L64815 0x0
-
-/* Fujitsu */
-#define FMI_AURORA 0x4   /* MB8690x, a Swift module... */
-#define FMI_TURBO  0x5   /* MB86907, a TurboSparc module... */
-
-/* For multiprocessor support we need to be able to obtain the CPU id and
- * the MBUS Module id.
- */
-
-/* The CPU ID is encoded in the trap base register, 20 bits to the left of
- * bit zero, with 2 bits being significant.
- */
-#define TBR_ID_SHIFT20
-
-static inline int get_cpuid(void)
-{
-   register int retval;
-   __asm__ __volatile__("rd %%tbr, %0\n\t"
-"srl %0, %1, %0\n\t" :
-"=r" (retval) :
-"i" (TBR_ID_SHIFT));
-   return (retval & 3);
-}
-
-static inline int get_modid(void)
-{
-   return (get_cpuid() | 0x8);
-}
-
-   
-#endif /* !(_SPARC_MBUS_H) */
diff --git a/arch/sparc/kernel/cpu.c b/arch/sparc/kernel/cpu.c
index 79cd6ccfeac0..cca7de051593 100644
--- a/arch/sparc/kernel/cpu.c
+++ b/arch/sparc/kernel/cpu.c
@@ -19,7 +19,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
 #include "kernel.h"
diff --git a/arch/sparc/kernel/setup_32.c b/arch/sparc/kernel/setup_32.c
index eea43a1aef1b..b6fd87928c73 1

[PATCH v1 11/13] sparc32: Drop unused mmu models

2020-12-18 Thread Sam Ravnborg
Drop mmu models not used by LEON, including their header files.
This includes removal of unused includes in various files to fix the
build.

Signed-off-by: Sam Ravnborg 
Cc: Sam Ravnborg 
Cc: "David S. Miller" 
Cc: Will Deacon 
Cc: Andrew Morton 
Cc: Mike Rapoport 
Cc: Christian Brauner 
Cc: Thomas Gleixner 
Cc: Pekka Enberg 
Cc: Ira Weiny 
Cc: Arnd Bergmann 
Cc: Andreas Larsson 
---
 arch/sparc/include/asm/mxcc.h| 138 --
 arch/sparc/include/asm/ross.h| 192 
 arch/sparc/include/asm/swift.h   | 107 -
 arch/sparc/include/asm/tsunami.h |  65 ---
 arch/sparc/include/asm/viking.h  | 255 --
 arch/sparc/kernel/entry.S|   1 -
 arch/sparc/mm/Makefile   |   1 -
 arch/sparc/mm/hypersparc.S   | 414 -
 arch/sparc/mm/io-unit.c  |   1 -
 arch/sparc/mm/iommu.c|  31 +-
 arch/sparc/mm/mm_32.h|   1 -
 arch/sparc/mm/srmmu.c| 776 +--
 arch/sparc/mm/swift.S| 256 --
 arch/sparc/mm/tsunami.S  | 132 --
 arch/sparc/mm/viking.S   | 284 ---
 15 files changed, 21 insertions(+), 2633 deletions(-)
 delete mode 100644 arch/sparc/include/asm/mxcc.h
 delete mode 100644 arch/sparc/include/asm/ross.h
 delete mode 100644 arch/sparc/include/asm/swift.h
 delete mode 100644 arch/sparc/include/asm/tsunami.h
 delete mode 100644 arch/sparc/include/asm/viking.h
 delete mode 100644 arch/sparc/mm/hypersparc.S
 delete mode 100644 arch/sparc/mm/swift.S
 delete mode 100644 arch/sparc/mm/tsunami.S
 delete mode 100644 arch/sparc/mm/viking.S

diff --git a/arch/sparc/include/asm/mxcc.h b/arch/sparc/include/asm/mxcc.h
deleted file mode 100644
index 3a2561bea4dd..
--- a/arch/sparc/include/asm/mxcc.h
+++ /dev/null
@@ -1,138 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 */
-/*
- * mxcc.h:  Definitions of the Viking MXCC registers
- *
- * Copyright (C) 1995 David S. Miller (da...@caip.rutgers.edu)
- */
-
-#ifndef _SPARC_MXCC_H
-#define _SPARC_MXCC_H
-
-/* These registers are accessed through ASI 0x2. */
-#define MXCC_DATSTREAM   0x1C0  /* Data stream register */
-#define MXCC_SRCSTREAM   0x1C00100  /* Source stream register */
-#define MXCC_DESSTREAM   0x1C00200  /* Destination stream register */
-#define MXCC_RMCOUNT 0x1C00300  /* Count of references and misses */
-#define MXCC_STEST   0x1C00804  /* Internal self-test */
-#define MXCC_CREG0x1C00A04  /* Control register */
-#define MXCC_SREG0x1C00B00  /* Status register */
-#define MXCC_RREG0x1C00C04  /* Reset register */
-#define MXCC_EREG0x1C00E00  /* Error code register */
-#define MXCC_PREG0x1C00F04  /* Address port register */
-
-/* Some MXCC constants. */
-#define MXCC_STREAM_SIZE 0x20   /* Size in bytes of one stream r/w */
-
-/* The MXCC Control Register:
- *
- * --
- * |   | RRC | RSV |PRE|MCE|PARE|ECE|RSV|
- * --
- *  31  1098-6   5   43   2  1-0
- *
- * RRC: Controls what you read from MXCC_RMCOUNT reg.
- *  0=Misses 1=References
- * PRE: Prefetch enable
- * MCE: Multiple Command Enable
- * PARE: Parity enable
- * ECE: External cache enable
- */
-
-#define MXCC_CTL_RRC   0x0200
-#define MXCC_CTL_PRE   0x0020
-#define MXCC_CTL_MCE   0x0010
-#define MXCC_CTL_PARE  0x0008
-#define MXCC_CTL_ECE   0x0004
-
-/* The MXCC Error Register:
- *
- * 
- * |ME| RSV|CE|PEW|PEE|ASE|EIV| MOPC|ECODE|PRIV|RSV|HPADDR|
- * 
- *  31   30 29  28  27  26  25 24-15  14-7   6  5-3   2-0
- *
- * ME: Multiple Errors have occurred
- * CE: Cache consistency Error
- * PEW: Parity Error during a Write operation
- * PEE: Parity Error involving the External cache
- * ASE: ASynchronous Error
- * EIV: This register is toast
- * MOPC: MXCC Operation Code for instance causing error
- * ECODE: The Error CODE
- * PRIV: A privileged mode error? 0=no 1=yes
- * HPADDR: High PhysicalADDRess bits (35-32)
- */
-
-#define MXCC_ERR_ME 0x8000
-#define MXCC_ERR_CE 0x2000
-#define MXCC_ERR_PEW0x1000
-#define MXCC_ERR_PEE0x0800
-#define MXCC_ERR_ASE0x0400
-#define MXCC_ERR_EIV0x0200
-#define MXCC_ERR_MOPC   0x01FF8000
-#define MXCC_ERR_ECODE  0x7F80
-#define MXCC_ERR_PRIV   0x0040
-#define MXCC_ERR_HPADDR 0x000f
-
-/* The MXCC Port register:
- *
- * -
- * || MID ||
- * -
- *  3121 20-18 17 0
- *
- * MID: The moduleID of the cpu your read this from.
- */
-
-#ifndef __

[PATCH v1 13/13] sparc32: drop use of sparc_config

2020-12-18 Thread Sam Ravnborg
sparc_config were used to handle the differences between the machines.
With only LEON supported sparc_config is no longer required.

This has the added benefit that we get rid of a rw variable
with several function pointers thus reducing our attack surface.

Signed-off-by: Sam Ravnborg 
Cc: Sam Ravnborg 
Cc: Arnd Bergmann 
Cc: Andreas Larsson 
---
 arch/sparc/include/asm/timer_32.h |   1 +
 arch/sparc/kernel/irq.h   |  32 ++---
 arch/sparc/kernel/irq_32.c|   3 -
 arch/sparc/kernel/leon_kernel.c   |  27 ++--
 arch/sparc/kernel/of_device_32.c  |   4 +-
 arch/sparc/kernel/time_32.c   | 110 +-
 6 files changed, 61 insertions(+), 116 deletions(-)

diff --git a/arch/sparc/include/asm/timer_32.h 
b/arch/sparc/include/asm/timer_32.h
index eecd2696922d..1cd89a99966f 100644
--- a/arch/sparc/include/asm/timer_32.h
+++ b/arch/sparc/include/asm/timer_32.h
@@ -17,6 +17,7 @@
 #include   /* For SUN4M_NCPUS */
 
 #define SBUS_CLOCK_RATE   200 /* 2MHz */
+#define LEON_CLOCK_RATE   100
 #define TIMER_VALUE_SHIFT 9
 #define TIMER_VALUE_MASK  0x3f
 #define TIMER_LIMIT_BIT   (1 << 31)  /* Bit 31 in Counter-Timer register */
diff --git a/arch/sparc/kernel/irq.h b/arch/sparc/kernel/irq.h
index 0d9b740725b4..ba0db1e4df6f 100644
--- a/arch/sparc/kernel/irq.h
+++ b/arch/sparc/kernel/irq.h
@@ -49,33 +49,6 @@ extern struct sun4m_irq_global __iomem *sun4m_irq_global;
 #define FEAT_L10_CLOCKEVENT  (1 << 1) /* L10 timer is used as a clockevent */
 #define FEAT_L14_ONESHOT (1 << 2) /* L14 timer clockevent can oneshot */
 
-/*
- * Platform specific configuration
- * The individual platforms assign their platform
- * specifics in their init functions.
- */
-struct sparc_config {
-   void (*init_timers)(void);
-   unsigned int (*build_device_irq)(struct platform_device *op,
-unsigned int real_irq);
-
-   /* generic clockevent features - see FEAT_* above */
-   int features;
-
-   /* clock rate used for clock event timer */
-   int clock_rate;
-
-   /* one period for clock source timer */
-   unsigned int cs_period;
-
-   /* function to obtain offsett for cs period */
-   unsigned int (*get_cycles_offset)(void);
-
-   void (*clear_clock_irq)(void);
-   void (*load_profile_irq)(int cpu, unsigned int limit);
-};
-extern struct sparc_config sparc_config;
-
 unsigned int irq_alloc(unsigned int real_irq, unsigned int pil);
 void irq_link(unsigned int irq);
 void irq_unlink(unsigned int irq);
@@ -89,6 +62,11 @@ void sun4m_nmi(struct pt_regs *regs);
 /* sun4d_irq.c */
 void sun4d_handler_irq(unsigned int pil, struct pt_regs *regs);
 
+/* leon_kernel.c */
+void leon_clear_clock_irq(void);
+void leon_load_profile_irq(int cpu, unsigned int limit);
+u32 leon_cycles_offset(void);
+
 #ifdef CONFIG_SMP
 
 /* All SUN4D IPIs are sent on this IRQ, may be shared with hard IRQs */
diff --git a/arch/sparc/kernel/irq_32.c b/arch/sparc/kernel/irq_32.c
index a6af08fce796..f76f57073323 100644
--- a/arch/sparc/kernel/irq_32.c
+++ b/arch/sparc/kernel/irq_32.c
@@ -24,9 +24,6 @@
 #include "kernel.h"
 #include "irq.h"
 
-/* platform specific irq setup */
-struct sparc_config sparc_config;
-
 unsigned long arch_local_irq_save(void)
 {
unsigned long retval;
diff --git a/arch/sparc/kernel/leon_kernel.c b/arch/sparc/kernel/leon_kernel.c
index 49b37a0dcc2b..491dff89f52c 100644
--- a/arch/sparc/kernel/leon_kernel.c
+++ b/arch/sparc/kernel/leon_kernel.c
@@ -239,12 +239,6 @@ unsigned int leon_build_device_irq(unsigned int real_irq,
return irq;
 }
 
-static unsigned int _leon_build_device_irq(struct platform_device *op,
-  unsigned int real_irq)
-{
-   return leon_build_device_irq(real_irq, handle_simple_irq, "edge", 0);
-}
-
 void leon_update_virq_handling(unsigned int virq,
  irq_flow_handler_t flow_handler,
  const char *name, int do_ack)
@@ -260,7 +254,7 @@ void leon_update_virq_handling(unsigned int virq,
irq_set_chip_data(virq, (void *)mask);
 }
 
-static u32 leon_cycles_offset(void)
+u32 leon_cycles_offset(void)
 {
u32 rld, val, ctrl, off;
 
@@ -314,14 +308,6 @@ void __init leon_init_timers(void)
u32 config;
u32 ctrl;
 
-   sparc_config.get_cycles_offset = leon_cycles_offset;
-   sparc_config.cs_period = 100 / HZ;
-   sparc_config.features |= FEAT_L10_CLOCKSOURCE;
-
-#ifndef CONFIG_SMP
-   sparc_config.features |= FEAT_L10_CLOCKEVENT;
-#endif
-
leondebug_irq_disable = 0;
leon_debug_irqout = 0;
master_l10_counter = (u32 __iomem *)_master_l10_counter;
@@ -436,7 +422,7 @@ void __init leon_init_timers(void)
err = request_irq(irq, leon_percpu_timer_ce_interrupt,
  IRQF_PERCPU | IRQF_TIMER, "timer", NULL);
 #else
-   irq = _l

[PATCH v1 09/13] sparc32: Drop pcic support

2020-12-18 Thread Sam Ravnborg
pcic is only used by MicroSPARC-IIep and not relevant for LEON.

Signed-off-by: Sam Ravnborg 
Cc: "David S. Miller" 
Cc: Sam Ravnborg 
Cc: Christian Brauner 
Cc: Mike Rapoport 
Cc: Andrew Morton 
Cc: sparcli...@vger.kernel.org
Cc: Arnd Bergmann 
Cc: Andreas Larsson 
---
 arch/sparc/Kconfig|   5 -
 arch/sparc/include/asm/pcic.h | 130 --
 arch/sparc/kernel/Makefile|   1 -
 arch/sparc/kernel/entry.S |  48 --
 arch/sparc/kernel/irq_32.c|   1 -
 arch/sparc/kernel/kernel.h|   4 -
 arch/sparc/kernel/pcic.c  | 830 --
 arch/sparc/kernel/time_32.c   |   6 +-
 8 files changed, 1 insertion(+), 1024 deletions(-)
 delete mode 100644 arch/sparc/include/asm/pcic.h
 delete mode 100644 arch/sparc/kernel/pcic.c

diff --git a/arch/sparc/Kconfig b/arch/sparc/Kconfig
index 8447f5b7bb90..a22b55024a46 100644
--- a/arch/sparc/Kconfig
+++ b/arch/sparc/Kconfig
@@ -427,11 +427,6 @@ config SUN_LDOMS
  Say Y here is you want to support virtual devices via
  Logical Domains.
 
-config PCIC_PCI
-   bool
-   depends on PCI && SPARC32 && !SPARC_LEON
-   default y
-
 config LEON_PCI
bool
depends on PCI && SPARC_LEON
diff --git a/arch/sparc/include/asm/pcic.h b/arch/sparc/include/asm/pcic.h
deleted file mode 100644
index 238376b1ffcc..
--- a/arch/sparc/include/asm/pcic.h
+++ /dev/null
@@ -1,130 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 */
-/*
- * pcic.h: JavaEngine 1 specific PCI definitions.
- *
- * Copyright (C) 1998 V. Roganov and G. Raiko
- */
-
-#ifndef __SPARC_PCIC_H
-#define __SPARC_PCIC_H
-
-#ifndef __ASSEMBLY__
-
-#include 
-#include 
-#include 
-#include 
-#include 
-
-struct linux_pcic {
-void __iomem*pcic_regs;
-unsigned long   pcic_io;
-void __iomem*pcic_config_space_addr;
-void __iomem*pcic_config_space_data;
-   struct resource pcic_res_regs;
-   struct resource pcic_res_io;
-   struct resource pcic_res_cfg_addr;
-   struct resource pcic_res_cfg_data;
-struct linux_pbm_info   pbm;
-   struct pcic_ca2irq  *pcic_imap;
-   int pcic_imdim;
-};
-
-#ifdef CONFIG_PCIC_PCI
-int pcic_present(void);
-int pcic_probe(void);
-void pci_time_init(void);
-void sun4m_pci_init_IRQ(void);
-#else
-static inline int pcic_present(void) { return 0; }
-static inline int pcic_probe(void) { return 0; }
-static inline void pci_time_init(void) {}
-static inline void sun4m_pci_init_IRQ(void) {}
-#endif
-#endif
-
-/* Size of PCI I/O space which we relocate. */
-#define PCI_SPACE_SIZE  0x100   /* 16 MB */
-
-/* PCIC Register Set. */
-#define PCI_DIAGNOSTIC_00x40/* 32 bits */
-#define PCI_SIZE_0  0x44/* 32 bits */
-#define PCI_SIZE_1  0x48/* 32 bits */
-#define PCI_SIZE_2  0x4c/* 32 bits */
-#define PCI_SIZE_3  0x50/* 32 bits */
-#define PCI_SIZE_4  0x54/* 32 bits */
-#define PCI_SIZE_5  0x58/* 32 bits */
-#define PCI_PIO_CONTROL 0x60/* 8  bits */
-#define PCI_DVMA_CONTROL0x62/* 8  bits */
-#define  PCI_DVMA_CONTROL_INACTIVITY_REQ(1<<0)
-#define  PCI_DVMA_CONTROL_IOTLB_ENABLE  (1<<0)
-#define  PCI_DVMA_CONTROL_IOTLB_DISABLE 0
-#define  PCI_DVMA_CONTROL_INACTIVITY_ACK(1<<4)
-#define PCI_INTERRUPT_CONTROL   0x63/* 8  bits */
-#define PCI_CPU_INTERRUPT_PENDING   0x64/* 32 bits */
-#define PCI_DIAGNOSTIC_10x68/* 16 bits */
-#define PCI_SOFTWARE_INT_CLEAR  0x6a/* 16 bits */
-#define PCI_SOFTWARE_INT_SET0x6e/* 16 bits */
-#define PCI_SYS_INT_PENDING 0x70/* 32 bits */
-#define  PCI_SYS_INT_PENDING_PIO   0x4000
-#define  PCI_SYS_INT_PENDING_DMA   0x2000
-#define  PCI_SYS_INT_PENDING_PCI   0x1000
-#define  PCI_SYS_INT_PENDING_APSR  0x0800
-#define PCI_SYS_INT_TARGET_MASK 0x74/* 32 bits */
-#define PCI_SYS_INT_TARGET_MASK_CLEAR   0x78/* 32 bits */
-#define PCI_SYS_INT_TARGET_MASK_SET 0x7c/* 32 bits */
-#define PCI_SYS_INT_PENDING_CLEAR   0x83/* 8  bits */
-#define  PCI_SYS_INT_PENDING_CLEAR_ALL 0x80
-#define  PCI_SYS_INT_PENDING_CLEAR_PIO 0x40
-#define  PCI_SYS_INT_PENDING_CLEAR_DMA 0x20
-#define  PCI_SYS_INT_PENDING_CLEAR_PCI 0x10
-#define PCI_IOTLB_CONTROL   0x84/* 8  bits */
-#define PCI_INT_SELECT_LO   0x88/* 16 bits */
-#define PCI_ARBITRATION_SELECT  0x8a/* 16 bits */
-#define PCI_INT_SELECT_HI   0x8c/* 16 bits */
-#define PCI_HW_INT_OUTPUT   0x8e/* 16 bits */
-#define PCI_IOTLB_

[PATCH v1 07/13] sparc32: Drop sun4m/sun4d specific irq handling

2020-12-18 Thread Sam Ravnborg
Some of the sun4m irq infrastructure is used by LEON too,
so keep that and drop the rest.

Signed-off-by: Sam Ravnborg 
Cc: Sam Ravnborg 
Cc: Christian Brauner 
Cc: "David S. Miller" 
Cc: Andrew Morton 
Cc: Mike Rapoport 
Cc: Pekka Enberg 
Cc: Geert Uytterhoeven 
Cc: Ira Weiny 
Cc: Arnd Bergmann 
Cc: Andreas Larsson 
---
 arch/sparc/include/asm/irq_32.h |   1 -
 arch/sparc/kernel/Makefile  |   2 +-
 arch/sparc/kernel/irq_32.c  |  30 +-
 arch/sparc/kernel/kernel.h  |  13 -
 arch/sparc/kernel/sun4d_irq.c   | 494 
 arch/sparc/kernel/sun4m_irq.c   | 240 
 arch/sparc/mm/io-unit.c |   2 -
 7 files changed, 2 insertions(+), 780 deletions(-)
 delete mode 100644 arch/sparc/kernel/sun4d_irq.c

diff --git a/arch/sparc/include/asm/irq_32.h b/arch/sparc/include/asm/irq_32.h
index 43ec2609b811..c820a6e967ae 100644
--- a/arch/sparc/include/asm/irq_32.h
+++ b/arch/sparc/include/asm/irq_32.h
@@ -18,7 +18,6 @@
 #define irq_canonicalize(irq)  (irq)
 
 void __init init_IRQ(void);
-void __init sun4d_init_sbi_irq(void);
 
 #define NO_IRQ 0x
 
diff --git a/arch/sparc/kernel/Makefile b/arch/sparc/kernel/Makefile
index b2735fb29c89..92a9fdbba0a5 100644
--- a/arch/sparc/kernel/Makefile
+++ b/arch/sparc/kernel/Makefile
@@ -30,7 +30,7 @@ obj-y   += traps_$(BITS).o
 
 # IRQ
 obj-y   += irq_$(BITS).o
-obj-$(CONFIG_SPARC32)   += sun4m_irq.o sun4d_irq.o
+obj-$(CONFIG_SPARC32)   += sun4m_irq.o
 
 obj-y   += process_$(BITS).o
 obj-y   += process.o
diff --git a/arch/sparc/kernel/irq_32.c b/arch/sparc/kernel/irq_32.c
index 510184c3aa17..135170f362c1 100644
--- a/arch/sparc/kernel/irq_32.c
+++ b/arch/sparc/kernel/irq_32.c
@@ -235,36 +235,8 @@ void handler_irq(unsigned int pil, struct pt_regs *regs)
set_irq_regs(old_regs);
 }
 
-/* djhr
- * This could probably be made indirect too and assigned in the CPU
- * bits of the code. That would be much nicer I think and would also
- * fit in with the idea of being able to tune your kernel for your machine
- * by removing unrequired machine and device support.
- *
- */
-
 void __init init_IRQ(void)
 {
-   switch (sparc_cpu_model) {
-   case sun4m:
-   pcic_probe();
-   if (pcic_present())
-   sun4m_pci_init_IRQ();
-   else
-   sun4m_init_IRQ();
-   break;
-
-   case sun4d:
-   sun4d_init_IRQ();
-   break;
-
-   case sparc_leon:
-   leon_init_IRQ();
-   break;
-
-   default:
-   prom_printf("Cannot initialize IRQs on this Sun machine...");
-   break;
-   }
+   leon_init_IRQ();
 }
 
diff --git a/arch/sparc/kernel/kernel.h b/arch/sparc/kernel/kernel.h
index e313d2e15ba9..8b7cc8899122 100644
--- a/arch/sparc/kernel/kernel.h
+++ b/arch/sparc/kernel/kernel.h
@@ -94,7 +94,6 @@ void unexpected_irq(int irq, void *dev_id, struct pt_regs * 
regs);
 void init_IRQ(void);
 
 /* sun4m_irq.c */
-void sun4m_init_IRQ(void);
 void sun4m_unmask_profile_irq(void);
 void sun4m_clear_profile_irq(int cpu);
 
@@ -107,18 +106,6 @@ void __init smp4m_smp_done(void);
 void smp4m_cross_call_irq(void);
 void smp4m_percpu_timer_interrupt(struct pt_regs *regs);
 
-/* sun4d_irq.c */
-extern spinlock_t sun4d_imsk_lock;
-
-void sun4d_init_IRQ(void);
-int sun4d_request_irq(unsigned int irq,
-  irq_handler_t handler,
-  unsigned long irqflags,
-  const char *devname, void *dev_id);
-int show_sun4d_interrupts(struct seq_file *, void *);
-void sun4d_distribute_irqs(void);
-void sun4d_free_irq(unsigned int irq, void *dev_id);
-
 /* sun4d_smp.c */
 void sun4d_cpu_pre_starting(void *arg);
 void sun4d_cpu_pre_online(void *arg);
diff --git a/arch/sparc/kernel/sun4d_irq.c b/arch/sparc/kernel/sun4d_irq.c
deleted file mode 100644
index 7140cff04b54..
--- a/arch/sparc/kernel/sun4d_irq.c
+++ /dev/null
@@ -1,494 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0
-/*
- * SS1000/SC2000 interrupt handling.
- *
- *  Copyright (C) 1997,1998 Jakub Jelinek (j...@sunsite.mff.cuni.cz)
- *  Heavily based on arch/sparc/kernel/irq.c.
- */
-
-#include 
-#include 
-#include 
-
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#include "kernel.h"
-#include "irq.h"
-
-/* Sun4d interrupts fall roughly into two categories.  SBUS and
- * cpu local.  CPU local interrupts cover the timer interrupts
- * and whatnot, and we encode those as normal PILs between
- * 0 and 15.
- * SBUS interrupts are encodes as a combination of board, level and slot.
- */
-
-struct sun4d_handler_data {
-   unsigned int cpuid;/* target cpu */
-   unsigned int real_irq; /* interrupt level */
-};
-
-
-static unsigned int sun4d_encode_irq(int board, int lvl, int slot)
-{
-   return (board + 1

[PATCH v1 05/13] sparc32: Drop run-time patching of ipi trap

2020-12-18 Thread Sam Ravnborg
There is no longer any need for the run-time patching of the ipi trap
with the removal of sun4m and sun4d. Remove the patching and drop the
ipi implementation for the two machines.

The patch includes removal of patching from pcic as this was needed to
fix the build. pcic will be removed in a later commit.

Signed-off-by: Sam Ravnborg 
Cc: Mike Rapoport 
Cc: Andrew Morton 
Cc: Sam Ravnborg 
Cc: Christian Brauner 
Cc: "David S. Miller" 
Cc: Geert Uytterhoeven 
Cc: Pekka Enberg 
Cc: Arnd Bergmann 
Cc: Andreas Larsson 
---
 arch/sparc/kernel/entry.S | 70 ++-
 arch/sparc/kernel/kernel.h|  4 --
 arch/sparc/kernel/leon_smp.c  |  3 --
 arch/sparc/kernel/pcic.c  | 11 --
 arch/sparc/kernel/sun4d_smp.c |  3 --
 arch/sparc/kernel/ttable_32.S |  9 ++---
 6 files changed, 7 insertions(+), 93 deletions(-)

diff --git a/arch/sparc/kernel/entry.S b/arch/sparc/kernel/entry.S
index 9985b08a3467..1a2e20a7e584 100644
--- a/arch/sparc/kernel/entry.S
+++ b/arch/sparc/kernel/entry.S
@@ -174,32 +174,6 @@ maybe_smp4m_msg_check_resched:
 maybe_smp4m_msg_out:
RESTORE_ALL
 
-   .align  4
-   .globl  linux_trap_ipi15_sun4m
-linux_trap_ipi15_sun4m:
-   SAVE_ALL
-   sethi   %hi(0x8000), %o2
-   GET_PROCESSOR4M_ID(o0)
-   sethi   %hi(sun4m_irq_percpu), %l5
-   or  %l5, %lo(sun4m_irq_percpu), %o5
-   sll %o0, 2, %o0
-   ld  [%o5 + %o0], %o5
-   ld  [%o5 + 0x00], %o3   ! sun4m_irq_percpu[cpu]->pending
-   andcc   %o3, %o2, %g0
-   be  sun4m_nmi_error ! Must be an NMI async memory error
-st %o2, [%o5 + 0x04]   ! 
sun4m_irq_percpu[cpu]->clear=0x8000
-   WRITE_PAUSE
-   ld  [%o5 + 0x00], %g0   ! sun4m_irq_percpu[cpu]->pending
-   WRITE_PAUSE
-   or  %l0, PSR_PIL, %l4
-   wr  %l4, 0x0, %psr
-   WRITE_PAUSE
-   wr  %l4, PSR_ET, %psr
-   WRITE_PAUSE
-   callsmp4m_cross_call_irq
-nop
-   b   ret_trap_lockless_ipi
-clr%l6
 
.globl  smp4d_ticker
/* SMP per-cpu ticker interrupts are handled specially. */
@@ -220,44 +194,6 @@ smp4d_ticker:
WRITE_PAUSE
RESTORE_ALL
 
-   .align  4
-   .globl  linux_trap_ipi15_sun4d
-linux_trap_ipi15_sun4d:
-   SAVE_ALL
-   sethi   %hi(CC_BASE), %o4
-   sethi   %hi(MXCC_ERR_ME|MXCC_ERR_PEW|MXCC_ERR_ASE|MXCC_ERR_PEE), %o2
-   or  %o4, (CC_EREG - CC_BASE), %o0
-   ldda[%o0] ASI_M_MXCC, %o0
-   andcc   %o0, %o2, %g0
-   bne 1f
-sethi  %hi(BB_STAT2), %o2
-   lduba   [%o2] ASI_M_CTL, %o2
-   andcc   %o2, BB_STAT2_MASK, %g0
-   bne 2f
-or %o4, (CC_ICLR - CC_BASE), %o0
-   sethi   %hi(1 << 15), %o1
-   stha%o1, [%o0] ASI_M_MXCC   /* Clear PIL 15 in MXCC's ICLR */
-   or  %l0, PSR_PIL, %l4
-   wr  %l4, 0x0, %psr
-   WRITE_PAUSE
-   wr  %l4, PSR_ET, %psr
-   WRITE_PAUSE
-   callsmp4d_cross_call_irq
-nop
-   b   ret_trap_lockless_ipi
-clr%l6
-
-1: /* MXCC error */
-2: /* BB error */
-   /* Disable PIL 15 */
-   set CC_IMSK, %l4
-   lduha   [%l4] ASI_M_MXCC, %l5
-   sethi   %hi(1 << 15), %l7
-   or  %l5, %l7, %l5
-   stha%l5, [%l4] ASI_M_MXCC
-   /* FIXME */
-1: b,a 1b
-
.globl  smpleon_ipi
.extern leon_ipi_interrupt
/* SMP per-cpu IPI interrupts are handled specially. */
@@ -618,11 +554,11 @@ sun4m_nmi_error:
 
 #ifndef CONFIG_SMP
.align  4
-   .globl  linux_trap_ipi15_sun4m
-linux_trap_ipi15_sun4m:
+   .globl  linux_trap_ipi15_leon
+linux_trap_ipi15_leon:
SAVE_ALL
 
-   ba  sun4m_nmi_error
+   ba  sun4m_nmi_error
 nop
 #endif /* CONFIG_SMP */
 
diff --git a/arch/sparc/kernel/kernel.h b/arch/sparc/kernel/kernel.h
index 7328d13875e4..c9e1b13d955f 100644
--- a/arch/sparc/kernel/kernel.h
+++ b/arch/sparc/kernel/kernel.h
@@ -135,10 +135,6 @@ void leonsmp_ipi_interrupt(void);
 void leon_cross_call_irq(void);
 
 /* head_32.S */
-extern unsigned int t_nmi[];
-extern unsigned int linux_trap_ipi15_sun4d[];
-extern unsigned int linux_trap_ipi15_sun4m[];
-
 extern struct tt_entry trapbase;
 extern struct tt_entry trapbase_cpu1;
 extern struct tt_entry trapbase_cpu2;
diff --git a/arch/sparc/kernel/leon_smp.c b/arch/sparc/kernel/leon_smp.c
index 1eed26d423fb..b0d75783d337 100644
--- a/arch/sparc/kernel/leon_smp.c
+++ b/arch/sparc/kernel/leon_smp.c
@@ -461,8 +461,5 @@ static const struct sparc32_ipi_ops leon_ipi_ops = {
 
 void __init leon_init_smp(void)
 {
-   /* Patch ipi15 trap table */
-   t_nmi[1] = t_nmi[1] + (linux_trap_ipi15_leon - linux_trap_ipi15_sun4m);
-
sparc32_ipi_ops = _ipi_ops;
 }
diff --git a/arch/sparc/kernel/pcic.c b/arch/sparc/kernel/pcic.c
index ee4c9a9a171c..87bdcb16019b 100644
--- a/arch/sparc/kernel/pcic.c

[PATCH v1 01/13] sparc32: Drop sun4m/sun4d support from head_32.S

2020-12-18 Thread Sam Ravnborg
Remove the most obvious parts of sun4* support from head_32.S.
Use a single print if a sun4* machine is detected thus restricting
boots to LEON machines.

Signed-off-by: Sam Ravnborg 
Cc: "David S. Miller" 
Cc: Sam Ravnborg 
Cc: Will Deacon 
Cc: Arnd Bergmann 
Cc: Andreas Larsson 
---
 arch/sparc/kernel/head_32.S | 190 ++--
 1 file changed, 9 insertions(+), 181 deletions(-)

diff --git a/arch/sparc/kernel/head_32.S b/arch/sparc/kernel/head_32.S
index be30c8d4cc73..b7b14250cbe0 100644
--- a/arch/sparc/kernel/head_32.S
+++ b/arch/sparc/kernel/head_32.S
@@ -45,11 +45,7 @@ cputypvar:
.align 4
 
 notsup:
-   .asciz  "Sparc-Linux sun4/sun4c or MMU-less not supported\n\n"
-   .align 4
-
-sun4e_notsup:
-.asciz  "Sparc-Linux sun4e support does not exist\n\n"
+   .asciz  "Sparc-Linux sun4* or MMU-less not supported\n\n"
.align 4
 
 /* The trap-table - located in the __HEAD section */
@@ -215,114 +211,10 @@ not_a_sun4:
be  leon_remap  /* It is a LEON - jump */
 nop
 
-   /* Sanity-check, is MMU enabled */
-   lda [%g0] ASI_M_MMUREGS, %g1
-   andcc   %g1, 1, %g0
-   be  halt_notsup
-nop
-
-   /* Check for a viking (TI) module. */
-   cmp %g3, PSR_IMPL_TI
-   bne srmmu_not_viking
-nop
-
-   /* Figure out what kind of viking we are on.
-* We need to know if we have to play with the
-* AC bit and disable traps or not.
-*/
-
-   /* I've only seen MicroSparc's on SparcClassics with this
-* bit set.
-*/
-   set 0x800, %g2
-   lda [%g0] ASI_M_MMUREGS, %g3! peek in the control 
reg
-   and %g2, %g3, %g3
-   subcc   %g3, 0x0, %g0
-   bnz srmmu_not_viking! is in mbus 
mode
-nop
-
-   rd  %psr, %g3   ! DO NOT TOUCH %g3
-   andn%g3, PSR_ET, %g2
-   wr  %g2, 0x0, %psr
-   WRITE_PAUSE
-
-   /* Get context table pointer, then convert to
-* a physical address, which is 36 bits.
-*/
-   set AC_M_CTPR, %g4
-   lda [%g4] ASI_M_MMUREGS, %g4
-   sll %g4, 0x4, %g4   ! We use this below
-   ! DO NOT TOUCH %g4
-
-   /* Set the AC bit in the Viking's MMU control reg. */
-   lda [%g0] ASI_M_MMUREGS, %g5! DO NOT TOUCH %g5
-   set 0x8000, %g6 ! AC bit mask
-   or  %g5, %g6, %g6   ! Or it in...
-   sta %g6, [%g0] ASI_M_MMUREGS! Close your eyes...
-
-   /* Grrr, why does it seem like every other load/store
-* on the sun4m is in some ASI space...
-* Fine with me, let's get the pointer to the level 1
-* page table directory and fetch its entry.
-*/
-   lda [%g4] ASI_M_BYPASS, %o1 ! This is a level 1 ptr
-   srl %o1, 0x4, %o1   ! Clear low 4 bits
-   sll %o1, 0x8, %o1   ! Make physical
-
-   /* Ok, pull in the PTD. */
-   lda [%o1] ASI_M_BYPASS, %o2 ! This is the 0x0 16MB 
pgd
-
-   /* Calculate to KERNBASE entry. */
-   add %o1, KERNBASE >> (PGDIR_SHIFT - 2), %o3
-
-   /* Poke the entry into the calculated address. */
-   sta %o2, [%o3] ASI_M_BYPASS
-
-   /* I don't get it Sun, if you engineered all these
-* boot loaders and the PROM (thank you for the debugging
-* features btw) why did you not have them load kernel
-* images up in high address space, since this is necessary
-* for ABI compliance anyways?  Does this low-mapping provide
-* enhanced interoperability?
-*
-* "The PROM is the computer."
-*/
-
-   /* Ok, restore the MMU control register we saved in %g5 */
-   sta %g5, [%g0] ASI_M_MMUREGS! POW... ouch
-
-   /* Turn traps back on.  We saved it in %g3 earlier. */
-   wr  %g3, 0x0, %psr  ! tick tock, tick tock
-
-   /* Now we burn precious CPU cycles due to bad engineering. */
-   WRITE_PAUSE
-
-   /* Wow, all that just to move a 32-bit value from one
-* place to another...  Jump to high memory.
-*/
-   

[PATCH v1 02/13] sparc32: Drop floppy support

2020-12-18 Thread Sam Ravnborg
LEON do not have floppy support so we can drop it

Signed-off-by: Sam Ravnborg 
Cc: "David S. Miller" 
Cc: Sam Ravnborg 
Cc: Mike Rapoport 
Cc: Andrew Morton 
Cc: Denis Efremov 
Cc: Willy Tarreau 
Cc: Christian Brauner 
Cc: sparcli...@vger.kernel.org
Cc: Arnd Bergmann 
Cc: Andreas Larsson 
---
 arch/sparc/Kconfig |   2 +-
 arch/sparc/include/asm/floppy.h| 786 -
 arch/sparc/include/asm/floppy_32.h | 393 ---
 arch/sparc/include/asm/floppy_64.h | 779 
 arch/sparc/kernel/entry.S  | 137 -
 arch/sparc/kernel/irq.h|   3 -
 arch/sparc/kernel/irq_32.c |  93 
 arch/sparc/kernel/kernel.h |   2 -
 8 files changed, 779 insertions(+), 1416 deletions(-)
 delete mode 100644 arch/sparc/include/asm/floppy_32.h
 delete mode 100644 arch/sparc/include/asm/floppy_64.h

diff --git a/arch/sparc/Kconfig b/arch/sparc/Kconfig
index c9c34dc52b7d..2c6d8d834f9a 100644
--- a/arch/sparc/Kconfig
+++ b/arch/sparc/Kconfig
@@ -200,7 +200,7 @@ config GENERIC_CALIBRATE_DELAY
 
 config ARCH_MAY_HAVE_PC_FDC
bool
-   default y
+   default y if SPARC64
 
 config EMULATED_CMPXCHG
bool
diff --git a/arch/sparc/include/asm/floppy.h b/arch/sparc/include/asm/floppy.h
index 4b315802e635..070c8c1f5c8f 100644
--- a/arch/sparc/include/asm/floppy.h
+++ b/arch/sparc/include/asm/floppy.h
@@ -1,9 +1,779 @@
 /* SPDX-License-Identifier: GPL-2.0 */
-#ifndef ___ASM_SPARC_FLOPPY_H
-#define ___ASM_SPARC_FLOPPY_H
-#if defined(__sparc__) && defined(__arch64__)
-#include 
-#else
-#include 
-#endif
-#endif
+/* floppy.h: Sparc specific parts of the Floppy driver.
+ *
+ * Copyright (C) 1996, 2007, 2008 David S. Miller (da...@davemloft.net)
+ * Copyright (C) 1997 Jakub Jelinek (j...@sunsite.mff.cuni.cz)
+ *
+ * Ultra/PCI support added: Sep 1997  Eddie C. Dost  (e...@skynet.be)
+ */
+
+#ifndef __ASM_SPARC64_FLOPPY_H
+#define __ASM_SPARC64_FLOPPY_H
+
+#include 
+#include 
+#include 
+
+#include 
+
+/*
+ * Define this to enable exchanging drive 0 and 1 if only drive 1 is
+ * probed on PCI machines.
+ */
+#undef PCI_FDC_SWAP_DRIVES
+
+
+/* References:
+ * 1) Netbsd Sun floppy driver.
+ * 2) NCR 82077 controller manual
+ * 3) Intel 82077 controller manual
+ */
+struct sun_flpy_controller {
+   volatile unsigned char status1_82077; /* Auxiliary Status reg. 1 */
+   volatile unsigned char status2_82077; /* Auxiliary Status reg. 2 */
+   volatile unsigned char dor_82077; /* Digital Output reg. */
+   volatile unsigned char tapectl_82077; /* Tape Control reg */
+   volatile unsigned char status_82077;  /* Main Status Register. */
+#define drs_82077  status_82077   /* Digital Rate Select reg. */
+   volatile unsigned char data_82077;/* Data fifo. */
+   volatile unsigned char ___unused;
+   volatile unsigned char dir_82077; /* Digital Input reg. */
+#define dcr_82077  dir_82077  /* Config Control reg. */
+};
+
+/* You'll only ever find one controller on an Ultra anyways. */
+static struct sun_flpy_controller *sun_fdc = (struct sun_flpy_controller *)-1;
+unsigned long fdc_status;
+static struct platform_device *floppy_op = NULL;
+
+struct sun_floppy_ops {
+   unsigned char   (*fd_inb) (unsigned long port, unsigned int reg);
+   void(*fd_outb) (unsigned char value, unsigned long base,
+   unsigned int reg);
+   void(*fd_enable_dma) (void);
+   void(*fd_disable_dma) (void);
+   void(*fd_set_dma_mode) (int);
+   void(*fd_set_dma_addr) (char *);
+   void(*fd_set_dma_count) (int);
+   unsigned int(*get_dma_residue) (void);
+   int (*fd_request_irq) (void);
+   void(*fd_free_irq) (void);
+   int (*fd_eject) (int);
+};
+
+static struct sun_floppy_ops sun_fdops;
+
+#define fd_inb(base, reg) sun_fdops.fd_inb(base, reg)
+#define fd_outb(value, base, reg) sun_fdops.fd_outb(value, base, reg)
+#define fd_enable_dma()   sun_fdops.fd_enable_dma()
+#define fd_disable_dma()  sun_fdops.fd_disable_dma()
+#define fd_request_dma()  (0) /* nothing... */
+#define fd_free_dma() /* nothing... */
+#define fd_clear_dma_ff() /* nothing... */
+#define fd_set_dma_mode(mode) sun_fdops.fd_set_dma_mode(mode)
+#define fd_set_dma_addr(addr) sun_fdops.fd_set_dma_addr(addr)
+#define fd_set_dma_count(count)   sun_fdops.fd_set_dma_count(count)
+#define get_dma_residue(x)sun_fdops.get_dma_residue()
+#define fd_request_irq()  sun_fdops.fd_request_irq()
+#define fd_free_irq() sun_fdops.fd_free_irq()
+#define fd_eject(drive)   sun_fdops.fd_eject(drive)
+
+/* Super paranoid... */
+#undef HAVE_DISABLE_HLT
+
+static int sun_floppy_types[2] = { 0, 0 };
+
+/* Here is where we catch the floppy driver tr

[PATCH v1 06/13] sparc32: Drop patching of interrupt vector

2020-12-18 Thread Sam Ravnborg
Drop the sun4m specific handling and the patching that
takes place in sun4d and LEON.

Signed-off-by: Sam Ravnborg 
Cc: Sam Ravnborg 
Cc: Andrew Morton 
Cc: Mike Rapoport 
Cc: Christian Brauner 
Cc: "David S. Miller" 
Cc: Arnd Bergmann 
Cc: Andreas Larsson 
---
 arch/sparc/kernel/entry.S   | 98 -
 arch/sparc/kernel/kernel.h  |  1 -
 arch/sparc/kernel/leon_kernel.c | 16 --
 arch/sparc/kernel/sun4d_irq.c   | 25 -
 4 files changed, 140 deletions(-)

diff --git a/arch/sparc/kernel/entry.S b/arch/sparc/kernel/entry.S
index 1a2e20a7e584..e7cf5013aa40 100644
--- a/arch/sparc/kernel/entry.S
+++ b/arch/sparc/kernel/entry.S
@@ -79,15 +79,6 @@ bad_trap_handler:
 real_irq_entry:
SAVE_ALL
 
-#ifdef CONFIG_SMP
-   .globl  patchme_maybe_smp_msg
-
-   cmp %l7, 11
-patchme_maybe_smp_msg:
-   bgu maybe_smp4m_msg
-nop
-#endif
-
 real_irq_continue:
or  %l0, PSR_PIL, %g2
wr  %g2, 0x0, %psr
@@ -105,95 +96,6 @@ patch_handler_irq:
RESTORE_ALL
 
 #ifdef CONFIG_SMP
-   /* SMP per-cpu ticker interrupts are handled specially. */
-smp4m_ticker:
-   bne real_irq_continue+4
-or %l0, PSR_PIL, %g2
-   wr  %g2, 0x0, %psr
-   WRITE_PAUSE
-   wr  %g2, PSR_ET, %psr
-   WRITE_PAUSE
-   callsmp4m_percpu_timer_interrupt
-add%sp, STACKFRAME_SZ, %o0
-   wr  %l0, PSR_ET, %psr
-   WRITE_PAUSE
-   RESTORE_ALL
-
-#define GET_PROCESSOR4M_ID(reg)\
-   rd  %tbr, %reg; \
-   srl %reg, 12, %reg; \
-   and %reg, 3, %reg;
-
-   /* Here is where we check for possible SMP IPI passed to us
-* on some level other than 15 which is the NMI and only used
-* for cross calls.  That has a separate entry point below.
-*
-* IPIs are sent on Level 12, 13 and 14. See IRQ_IPI_*.
-*/
-maybe_smp4m_msg:
-   GET_PROCESSOR4M_ID(o3)
-   sethi   %hi(sun4m_irq_percpu), %l5
-   sll %o3, 2, %o3
-   or  %l5, %lo(sun4m_irq_percpu), %o5
-   sethi   %hi(0x7000), %o2! Check all soft-IRQs
-   ld  [%o5 + %o3], %o1
-   ld  [%o1 + 0x00], %o3   ! sun4m_irq_percpu[cpu]->pending
-   andcc   %o3, %o2, %g0
-   be,asmp4m_ticker
-cmp%l7, 14
-   /* Soft-IRQ IPI */
-   st  %o2, [%o1 + 0x04]   ! 
sun4m_irq_percpu[cpu]->clear=0x7000
-   WRITE_PAUSE
-   ld  [%o1 + 0x00], %g0   ! sun4m_irq_percpu[cpu]->pending
-   WRITE_PAUSE
-   or  %l0, PSR_PIL, %l4
-   wr  %l4, 0x0, %psr
-   WRITE_PAUSE
-   wr  %l4, PSR_ET, %psr
-   WRITE_PAUSE
-   srl %o3, 28, %o2! shift for simpler checks below
-maybe_smp4m_msg_check_single:
-   andcc   %o2, 0x1, %g0
-   beq,a   maybe_smp4m_msg_check_mask
-andcc  %o2, 0x2, %g0
-   callsmp_call_function_single_interrupt
-nop
-   andcc   %o2, 0x2, %g0
-maybe_smp4m_msg_check_mask:
-   beq,a   maybe_smp4m_msg_check_resched
-andcc  %o2, 0x4, %g0
-   callsmp_call_function_interrupt
-nop
-   andcc   %o2, 0x4, %g0
-maybe_smp4m_msg_check_resched:
-   /* rescheduling is done in RESTORE_ALL regardless, but incr stats */
-   beq,a   maybe_smp4m_msg_out
-nop
-   callsmp_resched_interrupt
-nop
-maybe_smp4m_msg_out:
-   RESTORE_ALL
-
-
-   .globl  smp4d_ticker
-   /* SMP per-cpu ticker interrupts are handled specially. */
-smp4d_ticker:
-   SAVE_ALL
-   or  %l0, PSR_PIL, %g2
-   sethi   %hi(CC_ICLR), %o0
-   sethi   %hi(1 << 14), %o1
-   or  %o0, %lo(CC_ICLR), %o0
-   stha%o1, [%o0] ASI_M_MXCC   /* Clear PIL 14 in MXCC's ICLR */
-   wr  %g2, 0x0, %psr
-   WRITE_PAUSE
-   wr  %g2, PSR_ET, %psr
-   WRITE_PAUSE
-   callsmp4d_percpu_timer_interrupt
-add%sp, STACKFRAME_SZ, %o0
-   wr  %l0, PSR_ET, %psr
-   WRITE_PAUSE
-   RESTORE_ALL
-
.globl  smpleon_ipi
.extern leon_ipi_interrupt
/* SMP per-cpu IPI interrupts are handled specially. */
diff --git a/arch/sparc/kernel/kernel.h b/arch/sparc/kernel/kernel.h
index c9e1b13d955f..e313d2e15ba9 100644
--- a/arch/sparc/kernel/kernel.h
+++ b/arch/sparc/kernel/kernel.h
@@ -146,7 +146,6 @@ extern char cputypval[];
 extern unsigned long lvl14_save[4];
 extern unsigned int real_irq_entry[];
 extern unsigned int smp4d_ticker[];
-extern unsigned int patchme_maybe_smp_msg[];
 
 /* trampoline_32.S */
 extern unsigned long sun4m_cpu_startup;
diff --git a/arch/sparc/kernel/leon_kernel.c b/arch/sparc/kernel/leon_kernel.c
index 39229940d725..49b37a0dcc2b 100644
--- a/arch/sparc/kernel/leon_kernel.c
+++ b/arch/sparc/kernel/leon_kernel.c
@@ -423,22 +423,6 @@ void __init leon_init_timers(void)
if (eirq != 0)
leon_eirq_setup(ei

[PATCH v1 04/13] sparc32: Drop auxio support

2020-12-18 Thread Sam Ravnborg
auxio is not supported by LEON - so drop it.

Signed-off-by: Sam Ravnborg 
Cc: Sam Ravnborg 
Cc: "David S. Miller" 
Cc: Christian Brauner 
Cc: Andrew Morton 
Cc: Mike Rapoport 
Cc: Dmitry Safonov <0x7f454...@gmail.com>
Cc: Peter Zijlstra 
Cc: Al Viro 
Cc: Arnd Bergmann 
Cc: Andreas Larsson 
---
 arch/sparc/include/asm/auxio_32.h |  73 +---
 arch/sparc/kernel/Makefile|   2 +-
 arch/sparc/kernel/apc.c   |  14 ---
 arch/sparc/kernel/auxio_32.c  | 140 --
 arch/sparc/kernel/devices.c   |   3 -
 arch/sparc/kernel/kernel.h|   4 -
 arch/sparc/kernel/pmc.c   |  10 ---
 arch/sparc/kernel/process_32.c|  10 ---
 arch/sparc/prom/misc_32.c |   2 -
 9 files changed, 3 insertions(+), 255 deletions(-)
 delete mode 100644 arch/sparc/kernel/auxio_32.c

diff --git a/arch/sparc/include/asm/auxio_32.h 
b/arch/sparc/include/asm/auxio_32.h
index 852457c7a265..e2335ddd359d 100644
--- a/arch/sparc/include/asm/auxio_32.h
+++ b/arch/sparc/include/asm/auxio_32.h
@@ -1,43 +1,12 @@
 /* SPDX-License-Identifier: GPL-2.0 */
 /*
- * auxio.h:  Definitions and code for the Auxiliary I/O register.
+ * Dummy definitions for the Auxiliary I/O register.
  *
  * Copyright (C) 1995 David S. Miller (da...@caip.rutgers.edu)
  */
 #ifndef _SPARC_AUXIO_H
 #define _SPARC_AUXIO_H
 
-#include 
-
-/* This register is an unsigned char in IO space.  It does two things.
- * First, it is used to control the front panel LED light on machines
- * that have it (good for testing entry points to trap handlers and irq's)
- * Secondly, it controls various floppy drive parameters.
- */
-#define AUXIO_ORMEIN  0xf0/* All writes must set these bits. */
-#define AUXIO_ORMEIN4M0xc0/* sun4m - All writes must set these bits. */
-#define AUXIO_FLPY_DENS   0x20/* Floppy density, high if set. Read only. */
-#define AUXIO_FLPY_DCHG   0x10/* A disk change occurred.  Read only. */
-#define AUXIO_EDGE_ON 0x10/* sun4m - On means Jumper block is in. */
-#define AUXIO_FLPY_DSEL   0x08/* Drive select/start-motor. Write only. */
-#define AUXIO_LINK_TEST   0x08/* sun4m - On means TPE Carrier detect. */
-
-/* Set the following to one, then zero, after doing a pseudo DMA transfer. */
-#define AUXIO_FLPY_TCNT   0x04/* Floppy terminal count. Write only. */
-
-/* Set the following to zero to eject the floppy. */
-#define AUXIO_FLPY_EJCT   0x02/* Eject floppy disk.  Write only. */
-#define AUXIO_LED 0x01/* On if set, off if unset. Read/Write */
-
-#ifndef __ASSEMBLY__
-
-/*
- * NOTE: these routines are implementation dependent--
- * understand the hardware you are querying!
- */
-void set_auxio(unsigned char bits_on, unsigned char bits_off);
-unsigned char get_auxio(void); /* .../asm/floppy.h */
-
 /*
  * The following routines are provided for driver-compatibility
  * with sparc64 (primarily sunlance.c)
@@ -46,44 +15,6 @@ unsigned char get_auxio(void); /* .../asm/floppy.h */
 #define AUXIO_LTE_ON1
 #define AUXIO_LTE_OFF   0
 
-/* auxio_set_lte - Set Link Test Enable (TPE Link Detect)
- *
- * on - AUXIO_LTE_ON or AUXIO_LTE_OFF
- */
-#define auxio_set_lte(on) \
-do { \
-   if(on) { \
-   set_auxio(AUXIO_LINK_TEST, 0); \
-   } else { \
-   set_auxio(0, AUXIO_LINK_TEST); \
-   } \
-} while (0)
-
-#define AUXIO_LED_ON1
-#define AUXIO_LED_OFF   0
-
-/* auxio_set_led - Set system front panel LED
- *
- * on - AUXIO_LED_ON or AUXIO_LED_OFF
- */
-#define auxio_set_led(on) \
-do { \
-   if(on) { \
-   set_auxio(AUXIO_LED, 0); \
-   } else { \
-   set_auxio(0, AUXIO_LED); \
-   } \
-} while (0)
-
-#endif /* !(__ASSEMBLY__) */
-
-
-/* AUXIO2 (Power Off Control) */
-extern volatile u8 __iomem *auxio_power_register;
-
-#defineAUXIO_POWER_DETECT_FAILURE  32
-#defineAUXIO_POWER_CLEAR_FAILURE   2
-#defineAUXIO_POWER_OFF 1
-
+#define auxio_set_lte(on)
 
 #endif /* !(_SPARC_AUXIO_H) */
diff --git a/arch/sparc/kernel/Makefile b/arch/sparc/kernel/Makefile
index b6c9ca1d6c66..b2735fb29c89 100644
--- a/arch/sparc/kernel/Makefile
+++ b/arch/sparc/kernel/Makefile
@@ -84,7 +84,7 @@ obj-$(CONFIG_SMP) += trampoline_$(BITS).o 
smp_$(BITS).o
 obj-$(CONFIG_SPARC32_SMP) += sun4m_smp.o sun4d_smp.o leon_smp.o
 obj-$(CONFIG_SPARC64_SMP) += hvtramp.o
 
-obj-y += auxio_$(BITS).o
+obj-$(CONFIG_SPARC64) += auxio_64.o
 obj-$(CONFIG_SUN_PM)  += apc.o pmc.o
 
 obj-$(CONFIG_MODULES) += module.o
diff --git a/arch/sparc/kernel/apc.c b/arch/sparc/kernel/apc.c
index ecd05bc0a104..93f5934bbbe1 100644
--- a/arch/sparc/kernel/apc.c
+++ b/arch/sparc/kernel/apc.c
@@ -19,15 +19,9 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 
-/* Debugging
- * 
- * #define APC_DEBUG_LED
- */
-
 #define APC_MINOR  MISC_DYNAMIC_MINOR
 #define APC_OBPNAME"power-management"
 #define APC_DEV

[RFC PATCH 0/13] sparc32: sunset sun4m and sun4d

2020-12-18 Thread Sam Ravnborg
The sun4m and sun4d based SPARC machines was very popular in the
90'ties and was then replaced by the more powerful sparc64
class of machines.
Today there is only Gentoo that to my best knowledge supports
sparc32 and people have moved on to more capable HW.

Cobham Gaisler have variants of the LEON processer that
runs sparc32 - and they are in production today.

With this patchset I propose to sunset sun4m and sun4d and move
focus to a more streamlined support for LEON.

One downside is that qemu supports sun4m - and we may loose
some testing possibilities when sun4m is dropped. qemu supports
LEON to some degree - I have not yet tried it out.

Andreas from Gaisler have indicated that they may be more active
upstream on sparc32 - and this will only be easier with a kernel
where the legacy stuff is dropped.

I decided to divide up the patches to make it possible to review
the set as some of the patches touches assembler and these parts
could use some extra eyes if we move forward with this.

For now it builds with the configurations I have tried.

Looking forward for feedback if sunsetting is a good idea or not.

Sam

Sam Ravnborg (13):
  sparc32: Drop sun4m/sun4d support from head_32.S
  sparc32: Drop floppy support
  sparc32: Drop sun4m specific led driver
  sparc32: Drop auxio support
  sparc32: Drop run-time patching of ipi trap
  sparc32: Drop patching of interrupt vector
  sparc32: Drop sun4m/sun4d specific irq handling
  sparc32: Drop sun4d/sun4m smp support
  sparc32: Drop pcic support
  sparc32: Drop mbus support
  sparc32: Drop unused mmu models
  sparc32: drop check for sparc_model
  sparc32: drop use of sparc_config

Note: I dunno why git does not see floppy_64.h=>floppy.h as a rename??

 arch/sparc/Kconfig  |  16 +-
 arch/sparc/include/asm/auxio_32.h   |  73 +---
 arch/sparc/include/asm/cpu_type.h   |  18 -
 arch/sparc/include/asm/elf_32.h |   2 -
 arch/sparc/include/asm/floppy.h | 786 -
 arch/sparc/include/asm/floppy_32.h  | 393 -
 arch/sparc/include/asm/floppy_64.h  | 779 -
 arch/sparc/include/asm/io_32.h  |   4 +-
 arch/sparc/include/asm/irq_32.h |   1 -
 arch/sparc/include/asm/mbus.h   |  97 -
 arch/sparc/include/asm/mxcc.h   | 138 --
 arch/sparc/include/asm/pcic.h   | 130 --
 arch/sparc/include/asm/pgtable_32.h |  24 -
 arch/sparc/include/asm/ross.h   | 192 
 arch/sparc/include/asm/swift.h  | 107 -
 arch/sparc/include/asm/timer_32.h   |   1 +
 arch/sparc/include/asm/tsunami.h|  65 ---
 arch/sparc/include/asm/viking.h | 255 ---
 arch/sparc/kernel/Makefile  |   8 +-
 arch/sparc/kernel/apc.c |  14 -
 arch/sparc/kernel/auxio_32.c| 140 --
 arch/sparc/kernel/cpu.c |   1 -
 arch/sparc/kernel/devices.c |  10 +-
 arch/sparc/kernel/entry.S   | 354 +--
 arch/sparc/kernel/head_32.S | 190 +---
 arch/sparc/kernel/ioport.c  |   6 +-
 arch/sparc/kernel/irq.h |  35 +-
 arch/sparc/kernel/irq_32.c  | 127 +-
 arch/sparc/kernel/kernel.h  |  28 --
 arch/sparc/kernel/led.c | 146 ---
 arch/sparc/kernel/leon_kernel.c |  43 +-
 arch/sparc/kernel/leon_pmc.c|  14 +-
 arch/sparc/kernel/leon_smp.c|   3 -
 arch/sparc/kernel/of_device_32.c|   4 +-
 arch/sparc/kernel/pcic.c| 841 
 arch/sparc/kernel/pmc.c |  10 -
 arch/sparc/kernel/process_32.c  |  10 -
 arch/sparc/kernel/setup_32.c|  80 +---
 arch/sparc/kernel/smp_32.c  | 102 +
 arch/sparc/kernel/sun4d_irq.c   | 519 --
 arch/sparc/kernel/sun4d_smp.c   | 413 --
 arch/sparc/kernel/sun4m_irq.c   | 240 --
 arch/sparc/kernel/sun4m_smp.c   | 273 
 arch/sparc/kernel/time_32.c | 114 +++--
 arch/sparc/kernel/ttable_32.S   |   9 +-
 arch/sparc/mm/Makefile  |   1 -
 arch/sparc/mm/hypersparc.S  | 414 --
 arch/sparc/mm/io-unit.c |   3 -
 arch/sparc/mm/iommu.c   |  49 +--
 arch/sparc/mm/mm_32.h   |   1 -
 arch/sparc/mm/srmmu.c   | 834 +--
 arch/sparc/mm/swift.S   | 256 ---
 arch/sparc/mm/tsunami.S | 132 --
 arch/sparc/mm/viking.S  | 284 
 arch/sparc/prom/misc_32.c   |   2 -
 55 files changed, 905 insertions(+), 7886 deletions(-)




Re: [PATCH 1/2] futex: mark futex_detect_cmpxchg() as 'noinline'

2020-12-17 Thread Sam Ravnborg
Hi Arnd,

> > I think we would be better served dropping support for sun4m and sun4d
> > from the kernel.
> 
> This seems appropriate as well to me.

I did a quick hack:
20 files changed, 40 insertions(+), 3051 deletions(-)

All the leon stuff is kept and there is room for more cleaning up.
The kernel can build a sparc32_defconfig with the Gaisler toochain.
This was a one hour quick hack that I cannot commit - it needs to be
split up to allow some resemble of review.

And it touched only arch/sparc/ - no sparc32 specific drivers were
dropped.

If we decide to chase this and we can drop sun4m/sun4d then maintaining
leon will be simpler as a nice side effect.

Sam


Re: [PATCH] dt-bindings: display: bridge: tc358768: Remove maintainer information

2020-12-17 Thread Sam Ravnborg
Hi Peter.

On Wed, Dec 16, 2020 at 09:44:59AM +0200, Peter Ujfalusi wrote:
> 
> On 15/12/2020 16.26, Rob Herring wrote:
> > On Tue, 15 Dec 2020 14:42:27 +0200, Peter Ujfalusi wrote:
> >> My employment with TI is coming to an end and I will not have access to
> >> the board where this bridge is connected to.
> >>
> >> It is better to remove a soon bouncing email address.
> >>
> >> Signed-off-by: Peter Ujfalusi 
> >> ---
> >>  .../devicetree/bindings/display/bridge/toshiba,tc358768.yaml   | 3 ---
> >>  1 file changed, 3 deletions(-)
> >>
> > 
> > My bot found errors running 'make dt_binding_check' on your patch:
> > 
> > yamllint warnings/errors:
> > 
> > dtschema/dtc warnings/errors:
> > /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml:
> >  'maintainers' is a required property
> > /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml:
> >  ignoring, error in schema: 
> > warning: no schema found in file: 
> > ./Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml
> 
> Right, so it is not that easy to not been able to maintain this... :o
> 
> Who should be documented as maintainer?
> Andrzej, Neil, David or Daniel?

I have no problem being listed as maintainer despite my very limited
knowledge on the HW. So unless you end up volunteering then just
add me.

Sam


Re: [PATCH] dt-bindings/display: abt,y030xx067a: Fix binding

2020-12-16 Thread Sam Ravnborg
On Thu, Dec 17, 2020 at 12:59:45AM +, Paul Cercueil wrote:
> The binding should use "unevaluatedProperties" instead of
> "additionalProperties", since it is a SPI device and may have
> SPI-related Device Tree properties, for instance the "spi-max-frequency"
> property that is present in the example.
> 
> Fixes: e366a644c69d ("dt-bindings: display: Add ABT Y030XX067A panel 
> bindings")
> Signed-off-by: Paul Cercueil 
Reviewed-by: Sam Ravnborg 


Re: [PATCH 1/2] futex: mark futex_detect_cmpxchg() as 'noinline'

2020-12-15 Thread Sam Ravnborg
Hi Arnd,

On Tue, Dec 15, 2020 at 12:26:10PM +0100, Arnd Bergmann wrote:
> On Tue, Dec 15, 2020 at 7:09 AM Guo Ren  wrote:
> > On Mon, Dec 14, 2020 at 9:15 PM Arnd Bergmann  wrote:
> > > I had a look at what other architectures always implement
> > > futex_atomic_cmpxchg_inatomic() or can use the asm-generic non-SMP 
> > > version,
> > > and I found that it's pretty much all of them, the odd ones being just 
> > > sparc32
> > > and csky, which use asm-generic/futex.h but do have an SMP option,
> > > as well as xtensa
> > >
> > > I would guess that for csky, this is a mistake, as the architecture is 
> > > fairly
> > > new and should be able to implement it. Not sure about sparc32.
> >
> > The c610, c807, c810 don't support SMP, so futex_cmpxchg_enabled = 1
> > with asm-generic's implementation.
> > For c860, there is no HAVE_FUTEX_CMPXCHG and cmpxchg_inatomic/inuser
> > implementation, so futex_cmpxchg_enabled = 0.
> >
> > Thx for point it out, we'll implement cmpxchg_inatomic/inuser for C860
> > and still use asm-generic for non-smp CPUs.
> 
> Sounds good to me.
> 
> With that, I would suggest we actually remove the -ENOSYS fallback
> for arch_futex_atomic_op_inuser() and futex_atomic_cmpxchg_inatomic()
> in asm-generic/futex.h as well as the HAVE_FUTEX_CMPXCHG Kconfig
> symbol, plus these additional fixups:
> 
> - for xtensa and mips configurations without ll/sc, fall back to the
>   asm-generic version. These are all uniprocessor, while the
>   corresponding SMP machines have a working
>   arch_futex_atomic_op_inuser().
> 
> - Disable SMP support for sun4m/sun4d. From the historic git
>   tree, it's unclear how well this ever worked, and very few machines
>   of this class ever existed
Yeah, I have collection of sparc32 machines that I played around with
once. Including one sun4d that I brought from a friendly Linux fellow in
the UK. But somehow I lost interest as this is all very nice machines
but not useful for anything real work.

I think we would be better served dropping support for sun4m and sun4d
from the kernel.

Last I suggested deleting sun4m/sun4d the argument to keep sun4m was that
QEMU supports sun4m - which is a good argument for sun4m. I dunno what
would be needed to migrate QEMU to LEON, see below.

> 
> - Mark SMP for LEON as temporarily broken. As I see in the LEON
>   patch set, they have changes to enable compare-and-swap-atomic
>   instructions unconditionally, as all SMP Leons have those and
>   seem to require this support already for other things.
LEON on the other hand could have some nice future. They are right now
stuck on an older kernel and someone that was motivated should be able
to get LEON4 running on latest upstream.
We had it working in the past - but is was around the time I lost my
sparc interest and no-one jumped in to move it much more forward.

So in other words - no complains for the plan you outline.

Sam


Re: [RFC PATCH] drm/panel: Make backlight attachment lazy

2020-12-07 Thread Sam Ravnborg
Hi Bjorn,
On Mon, Dec 07, 2020 at 10:44:46PM -0600, Bjorn Andersson wrote:
> Some bridge chips, such as the TI SN65DSI86 DSI/eDP bridge, provides
> means of generating a PWM signal for backlight control of the attached
> panel. The provided PWM chip is typically controlled by the
> pwm-backlight driver, which if tied to the panel will provide DPMS.
> 
> But with the current implementation the panel will refuse to probe
> because the bridge driver has yet to probe and register the PWM chip,
> and the bridge driver will refuse to probe because it's unable to find
> the panel.
> 
> Mitigate this catch-22 situation by allowing the panel driver to probe
> and retry the attachment of the backlight as the panel is turned on or
> off.
> 
> Signed-off-by: Bjorn Andersson 
> ---
>  drivers/gpu/drm/drm_panel.c | 47 +++--
>  include/drm/drm_panel.h |  8 +++
>  2 files changed, 43 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_panel.c b/drivers/gpu/drm/drm_panel.c
> index f634371c717a..7487329bd22d 100644
> --- a/drivers/gpu/drm/drm_panel.c
> +++ b/drivers/gpu/drm/drm_panel.c
> @@ -43,6 +43,34 @@ static LIST_HEAD(panel_list);
>   * take look at drm_panel_bridge_add() and devm_drm_panel_bridge_add().
>   */
>  
> +#if IS_REACHABLE(CONFIG_BACKLIGHT_CLASS_DEVICE)
> +static int drm_panel_of_backlight_lazy(struct drm_panel *panel)
> +{
> + struct backlight_device *backlight;
> +
> + if (!panel || !panel->dev)
> + return -EINVAL;
> +
> + backlight = devm_of_find_backlight(panel->dev);
> +
> + if (IS_ERR(backlight)) {
> + if (PTR_ERR(backlight) == -EPROBE_DEFER) {
> + panel->backlight_init_pending = true;
> + return 0;
> + }
> +
> + return PTR_ERR(backlight);
Use dev_err_probe()

> + }
> +
> + panel->backlight = backlight;
> + panel->backlight_init_pending = false;
> +
> + return 0;
> +}
> +#else
> +static int drm_panel_of_backlight_lazy(struct drm_panel *panel) { return 0; }
> +#endif
> +
>  /**
>   * drm_panel_init - initialize a panel
>   * @panel: DRM panel
> @@ -161,6 +189,9 @@ int drm_panel_enable(struct drm_panel *panel)
>   return ret;
>   }
>  
> + if (panel->backlight_init_pending)
> + drm_panel_of_backlight_lazy(panel);
> +
>   ret = backlight_enable(panel->backlight);
>   if (ret < 0)
>   DRM_DEV_INFO(panel->dev, "failed to enable backlight: %d\n",
> @@ -187,6 +218,9 @@ int drm_panel_disable(struct drm_panel *panel)
>   if (!panel)
>   return -EINVAL;
>  
> + if (panel->backlight_init_pending)
> + drm_panel_of_backlight_lazy(panel);
> +
>   ret = backlight_disable(panel->backlight);
>   if (ret < 0)
>   DRM_DEV_INFO(panel->dev, "failed to disable backlight: %d\n",
> @@ -328,18 +362,7 @@ EXPORT_SYMBOL(of_drm_get_panel_orientation);
>   */
>  int drm_panel_of_backlight(struct drm_panel *panel)
>  {
> - struct backlight_device *backlight;
> -
> - if (!panel || !panel->dev)
> - return -EINVAL;
> -
> - backlight = devm_of_find_backlight(panel->dev);
> -
> - if (IS_ERR(backlight))
> - return PTR_ERR(backlight);
> -
> - panel->backlight = backlight;
> - return 0;
> + return drm_panel_of_backlight_lazy(panel);
Could you update the drm_panel_of_backlight() implementation (and
do not forget the documentation) and avoid drm_panel_of_backlight_lazy()?

Sam

>  }
>  EXPORT_SYMBOL(drm_panel_of_backlight);
>  #endif
> diff --git a/include/drm/drm_panel.h b/include/drm/drm_panel.h
> index 33605c3f0eba..b126abebb2f3 100644
> --- a/include/drm/drm_panel.h
> +++ b/include/drm/drm_panel.h
> @@ -149,6 +149,14 @@ struct drm_panel {
>*/
>   struct backlight_device *backlight;
>  
> + /**
> +  * @backlight_init_pending
> +  *
> +  * Backlight driver is not yet available so further attempts to
> +  * initialize @backlight is necessary.
> +  */
> + bool backlight_init_pending;
> +

We have not done so today for other fields, but it would be good
to document this is for drm_panel use only and drivers shall not touch.

Sam


Re: [PATCH] drm/kmb: fix array bounds warning

2020-12-05 Thread Sam Ravnborg
Hi Anitha,
On Mon, Nov 30, 2020 at 10:19:13PM +, Chrisanthus, Anitha wrote:
> Hi Arnd,
> Thanks for your patch.
> 
> > -Original Message-
> > From: Arnd Bergmann 
> > Sent: Sunday, November 29, 2020 12:09 PM
> > To: Chrisanthus, Anitha ; Dea, Edmund J
> > ; David Airlie ; Daniel Vetter
> > ; Sam Ravnborg 
> > Cc: Arnd Bergmann ; lkp ; dri-
> > de...@lists.freedesktop.org; linux-kernel@vger.kernel.org
> > Subject: [PATCH] drm/kmb: fix array bounds warning
> > 
> > From: Arnd Bergmann 
> > 
> > gcc warns about an out-of-bounds access when the using nonzero
> > values for 'plane_id' on kmb->plane_status:
...

> Looks good.
> 
> Reviewed-by: Anitha Chrisanthus 

You wanted a little time to get comforable with dim, so I picked up this
patch and pushed it to drm-misc-next.

Sam


Re: [PATCH 2/4] dt-bindings: display: Add ABT Y030XX067A panel bindings

2020-12-05 Thread Sam Ravnborg
Hi Paul

> > >  >>  >>  +
> > >  >>  >>  +maintainers:
> > >  >>  >>  +  - Paul Cercueil 
> > >  >>  >>  +
> > >  >>  >>  +allOf:
> > >  >>  >>  +  - $ref: panel-common.yaml#
> > >  >>  >>  +
> > >  >>  >>  +properties:
> > >  >>  >>  +  compatible:
> > >  >>  >>  +const: abt,y030xx067a
> > >  >>  >>  +
> > >  >>  >>  +  backlight: true
> > >  >>  >>  +  port: true
> > >  >>  >>  +  power-supply: true
> > >  >>  >>  +  reg: true
> > >  >>  >>  +  reset-gpios: true
> > >  >>  >
> > >  >>  > The binding is missing:
> > >  >>  > required:
> > >  >>  >   - compatible
> > >  >>  >   - reg
> > >  >>  >   - power-supply
> > >  >>  >   - reset-gpios
> > >  >>  >   - ...
> > >  >>  >
> > >  >>  > additionalProperties: false
> > >  >>  >
> > >  >>  > So r-b only with these added.
> > >  >>
> > >  >>  Stupid mistake, sorry about that.
> > >  >>
> > >  >>  I'll V2.
> > >  >
> > >  > I don't have any V2 in my inbox, but looks like it is in
> > > linux-next
> > >  > now:
> > > 
> > >  Yes, Sam told me on IRC I could fix it while applying and avoid the
> > > V2.
> > > 
> > >  > 
> > > /builds/robherring/linux-dt-bindings/Documentation/devicetree/bindings/display/panel/abt,y030xx067a.example.dt.yaml:
> > >  > panel@0: 'spi-max-frequency' does not match any of the regexes:
> > >  > 'pinctrl-[0-9]+'
> > >  >  From schema:
> > >  > 
> > > /builds/robherring/linux-dt-bindings/Documentation/devicetree/bindings/display/panel/abt,y030xx067a.yaml
> > > 
> > >  "make dt_binding_check
> > > DT_SCHEMA_FILES=Documentation/devicetree/bindings/display/panel/abt,y030xx067a.yaml"
> > >  doesn't complain here :(
> > 
> > Even if you do 'touch
> > Documentation/devicetree/bindings/display/panel/abt,y030xx067a.yaml'
> > or do a clean build?
> > 
> > I can't think of any kernel or dt-schema changes which would explain
> > the difference. This is purely related to 'additionalProperties:
> > false'.
> 
> Ok, I see it now.
> Should I use 'unevaluatedProperties: false' instead?

Yes, the issue here is that you add a number of spi properties to the
binding. And you cannot or at least shall not, list them all in this
binding.
So when evaluating the binding the spi-max-frequency should be allowed,
and when a full DT file is checked the tools will catch it there is a
binding that is not known - as you tell it with "unevaluatedProperties:
false" that all prperties must be known.

Sam


Re: [PATCH v6 3/8] dt-bindings: display: simple: Add Kyocera tcg070wvlq panel

2020-12-05 Thread Sam Ravnborg
On Wed, Dec 02, 2020 at 09:18:21AM +0100, Oleksij Rempel wrote:
> So far, this panel seems to be compatible with "lg,lb070wv8", on other
> hand it is better to set this compatible in the devicetree. So, let's
> add it for now only to the dt-binding documentation to fix the
> checkpatch warnings.
> 
> Signed-off-by: Oleksij Rempel 
> ---
>  .../devicetree/bindings/display/panel/panel-simple.yaml  | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git 
> a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml 
> b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
> index 0bb3e67fb58c..8f7a0e409eee 100644
> --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
> +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
> @@ -172,6 +172,7 @@ properties:
>- koe,tx26d202vm0bwa
>  # Kaohsiung Opto-Electronics. TX31D200VM0BAA 12.3" HSXGA LVDS panel
>- koe,tx31d200vm0baa
> +  - kyo,tcg070wvlq
Can you provine a comment here about what panel it is?

>  # Kyocera Corporation 12.1" XGA (1024x768) TFT LCD panel
>- kyo,tcg121xglp
>  # LeMaker BL035-RGB-002 3.5" QVGA TFT LCD panel
> -- 
> 2.29.2
> 
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v6 2/8] dt-bindings: display: simple: add EDT compatibles already supported by the driver

2020-12-05 Thread Sam Ravnborg
Hi Oleksij,

On Wed, Dec 02, 2020 at 09:18:20AM +0100, Oleksij Rempel wrote:
> Some EDT compatibles are already supported by the driver but will fail
> on checkpatch script. Fix it by syncing dt-bindings documentation with the
> driver.
> 
> Signed-off-by: Oleksij Rempel 
> ---
>  .../devicetree/bindings/display/panel/panel-simple.yaml| 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git 
> a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml 
> b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
> index 428b03342fea..0bb3e67fb58c 100644
> --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
> +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
> @@ -108,10 +108,12 @@ properties:
>  # Emerging Display Technology Corp. 480x272 TFT Display with 
> capacitive touch
>- edt,et057090dhu
>  # Emerging Display Technology Corp. WVGA TFT Display with capacitive 
> touch
> +  - edt,et070080dh6
>- edt,etm043080dh6gp
>  # Emerging Display Technology Corp. 480x272 TFT Display
>- edt,etm0430g0dh6
>  # Emerging Display Technology Corp. 5.7" VGA TFT LCD panel
> +  - edt,etm0700g0bdh6
>- edt,etm070080bdh6
The order is wrong here. edt,etm070080bdh6 comes before edt,etm0700g0bdh6.
I checked with "sort" in my editor just to make sure.

>  # Emerging Display Technology Corp. WVGA TFT Display with capacitive 
> touch
>  # Same display as the ETM0700G0BDH6, but with changed hardware for 
> the
> @@ -124,6 +126,7 @@ properties:
>- edt,etm0700g0dh6
>  # Emerging Display Technology Corp. WVGA TFT Display with capacitive 
> touch
>  # Same as ETM0700G0DH6 but with inverted pixel clock.
> +  - edt,etm0700g0edh6
>- evervision,vgg804821
>  # Foxlink Group 5" WVGA TFT LCD panel
>- foxlink,fl500wvr00-a0t

Sam


Re: [PATCH v6 1/8] dt-bindings: display: simple: fix alphabetical order for EDT compatibles

2020-12-05 Thread Sam Ravnborg
Hi Oleksij

On Wed, Dec 02, 2020 at 09:18:19AM +0100, Oleksij Rempel wrote:
> Reorder it alphabetically and remove one double entry.
> 
> Signed-off-by: Oleksij Rempel 
> ---
>  .../bindings/display/panel/panel-simple.yaml | 16 +++-
>  1 file changed, 7 insertions(+), 9 deletions(-)
> 
> diff --git 
> a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml 
> b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
> index edb53ab0d9eb..428b03342fea 100644
> --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
> +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
> @@ -106,26 +106,24 @@ properties:
>  # Emerging Display Technology Corp. 3.5" QVGA TFT LCD panel
>- edt,et035012dm6
>  # Emerging Display Technology Corp. 480x272 TFT Display with 
> capacitive touch
> +  - edt,et057090dhu
> +# Emerging Display Technology Corp. WVGA TFT Display with capacitive 
> touch
>- edt,etm043080dh6gp
>  # Emerging Display Technology Corp. 480x272 TFT Display
>- edt,etm0430g0dh6
>  # Emerging Display Technology Corp. 5.7" VGA TFT LCD panel
> -  - edt,et057090dhu
> -# Emerging Display Technology Corp. WVGA TFT Display with capacitive 
> touch
> -  - edt,etm070080dh6
> -# Emerging Display Technology Corp. WVGA TFT Display with capacitive 
> touch
> -  - edt,etm0700g0dh6
> -# Emerging Display Technology Corp. WVGA TFT Display with capacitive 
> touch
> -# Same as ETM0700G0DH6 but with inverted pixel clock.
>- edt,etm070080bdh6
>  # Emerging Display Technology Corp. WVGA TFT Display with capacitive 
> touch
>  # Same display as the ETM0700G0BDH6, but with changed hardware for 
> the
>  # backlight and the touch interface.
> +  - edt,etm070080dh6
> +# Emerging Display Technology Corp. WVGA TFT Display with capacitive 
> touch
>- edt,etm070080edh6
>  # Emerging Display Technology Corp. WVGA TFT Display with capacitive 
> touch
>  # Same timings as the ETM0700G0DH6, but with resistive touch.
> -  - edt,etm070080dh6
> -# Evervision Electronics Co. Ltd. VGG804821 5.0" WVGA TFT LCD Panel
> +  - edt,etm0700g0dh6
> +# Emerging Display Technology Corp. WVGA TFT Display with capacitive 
> touch
> +# Same as ETM0700G0DH6 but with inverted pixel clock.
>- evervision,vgg804821
>  # Foxlink Group 5" WVGA TFT LCD panel
>- foxlink,fl500wvr00-a0t

Thanks for fixing this, but something is not correct.
I think you switched around the order of comment and compatible.

It goes like this

  # This is the comment
- compatible,for-the-comment

I always look at the first entry when I need to check the order.
Also the comment for evervision,vgg804821 seems to be lost in the above.

Sam


Re: [PATCH] drm: panel: Fully transition panel_desc kerneldoc to inline style

2020-12-05 Thread Sam Ravnborg
Hi Douglas,

On Tue, Dec 01, 2020 at 12:59:12PM -0800, Douglas Anderson wrote:
> In commit 131f909ad55f ("drm: panel: simple: Fixup the struct
> panel_desc kernel doc") I transitioned the more deeply nested
> kerneldoc comments into the inline style.  Apparently it is desirable
> to continue the job and move _everything_ in this struct to inline.
> Let's do it.
> 
> While doing this, we also add a short summary for the whole struct to
> fix a warning when we run with extra warnings, AKA:
>   scripts/kernel-doc -v -rst drivers/gpu/drm/panel/panel-simple.c
> 
> The warning was:
>   drivers/gpu/drm/panel/panel-simple.c:42: warning: missing initial short 
> description on line:
>    * struct panel_desc
> 
> Suggested-by: Sam Ravnborg 
> Signed-off-by: Douglas Anderson 
> Cc: Douglas Anderson 
> Cc: Sam Ravnborg 
> Cc: Thierry Reding 
> Cc: dri-de...@lists.freedesktop.org
> ---
> 
>  drivers/gpu/drm/panel/panel-simple.c | 43 +---
>  1 file changed, 27 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/gpu/drm/panel/panel-simple.c 
> b/drivers/gpu/drm/panel/panel-simple.c
> index 216cde33b5c4..33d53abdb1fb 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -39,31 +39,36 @@
>  #include 
>  
>  /**
> - * struct panel_desc
> - * @modes: Pointer to array of fixed modes appropriate for this panel.  If
> - * only one mode then this can just be the address of this the mode.
While applying I fixed this up like this:
> - * only one mode then this can just be the address of the mode.

Applied to drm-misc-next - thanks for doing this. Much nicer now.

Sam


Re: [PATCH v2] drm: panel: add flags to BOE NV110WTM-N61

2020-12-05 Thread Sam Ravnborg
Hi Douglas,

On Tue, Dec 01, 2020 at 12:56:11PM -0800, Douglas Anderson wrote:
> I forgot to add these when posting up the support for BOE
> NV110WTM-N61.  Add them now.
> 
> Fixes: a96ee0f6b58d ("drm: panel: simple: Add BOE NV110WTM-N61")
> Signed-off-by: Douglas Anderson 
> Cc: Douglas Anderson 
> Cc: Sam Ravnborg 
> Cc: Thierry Reding 
> Cc: dri-de...@lists.freedesktop.org

Thanks for noticing my fumbling and fixing this up in the correct way.
Applied to drm-misc-next.

Sam


Re: [PATCH 1/1] dt-bindings: eliminate yamllint warnings

2020-12-05 Thread Sam Ravnborg
On Fri, Dec 04, 2020 at 10:42:26AM +0800, Zhen Lei wrote:
> All warnings are related only to "wrong indentation", except one:
> Documentation/devicetree/bindings/media/i2c/mipi-ccs.yaml:4:1: \
> [error] missing document start "---" (document-start)
> 
> Signed-off-by: Zhen Lei 
> Cc: Rob Herring 
> Cc: Michael Turquette 
> Cc: Stephen Boyd 
> Cc: Shawn Guo 
> Cc: Sascha Hauer 
> Cc: Pengutronix Kernel Team 
> Cc: Fabio Estevam 
> Cc: NXP Linux Team 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: Sumit Semwal 
> Cc: Thierry Reding 
> Cc: Sam Ravnborg 
> Cc: Hans Verkuil 
> Cc: Mauro Carvalho Chehab 
> Cc: Sakari Ailus 
> Cc: Ricardo Ribalda 
> Cc: Ulf Hansson 
> Cc: Matthias Brugger 
> Cc: Liam Girdwood 
> Cc: Mark Brown 

For the bindings/display/* parts:
Acked-by: Sam Ravnborg 


Re: [PATCH v2 2/2] drm: panel: add Khadas TS050 panel driver

2020-12-05 Thread Sam Ravnborg
Hi Neil,

> +
> +static int khadas_ts050_panel_probe(struct mipi_dsi_device *dsi)
> +{
> + struct khadas_ts050_panel *khadas_ts050;
> + int err;
> +
> + dsi->lanes = 4;
> + dsi->format = MIPI_DSI_FMT_RGB888;
> + dsi->mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_BURST |
> +   MIPI_DSI_MODE_LPM | MIPI_DSI_MODE_EOT_PACKET;
> +
> + khadas_ts050 = devm_kzalloc(>dev, sizeof(*khadas_ts050),
> + GFP_KERNEL);
> + if (!khadas_ts050)
> + return -ENOMEM;
> +
> + mipi_dsi_set_drvdata(dsi, khadas_ts050);
> + khadas_ts050->link = dsi;
> +
> + err = khadas_ts050_panel_add(khadas_ts050);
> + if (err < 0)
> + return err;
> +
> + return mipi_dsi_attach(dsi);
> +}

If mipi_dsi_attach() failes then da a drm_panel_remove() like this:

ret = mipi_dsi_attach(dsi);
if (ret)
drm_panel_remove(_ts050->base);

    return ret;

This is again something several panels gets wrong.

With this fixed:
Reviewed-by: Sam Ravnborg 

I assume you will fix it while applying.

Sam


Re: [PATCH drm/hisilicon 2/3] drm/irq: Add the new api to install irq

2020-12-03 Thread Sam Ravnborg
Hi Tian,

> > +   ret = devm_add_action_or_reset(dev->dev, devm_drm_irq_uninstall, dev);
> > +   if (ret)
> > +   devm_drm_irq_uninstall(dev);
> devm_add_action_or_reset() will call devm_drm_irq_uninstall() if ret is
> != 0. See include/device.h.
> 
> I guess that is the "_or_reset" part of the name that can tell us that.
> So you can drop the if condition as it just will cause the code to call
> drm_irq_uninstall() twice.

Noticed this was fixed in v2 - so all is fine here.

Sam


Re: [PATCH drm/hisilicon 2/3] drm/irq: Add the new api to install irq

2020-12-03 Thread Sam Ravnborg
Hi Tian.

On Wed, Dec 02, 2020 at 04:47:14PM +0800, Tian Tao wrote:
> Add new api devm_drm_irq_install() to register interrupts,
> no need to call drm_irq_uninstall() when the drm module is removed.
> 
> Signed-off-by: Tian Tao 

Just a few details to fix.

Sam

> ---
>  drivers/gpu/drm/drm_irq.c | 35 +++
>  include/drm/drm_irq.h |  2 +-
>  2 files changed, 36 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> index 09d6e9e..b363dec 100644
> --- a/drivers/gpu/drm/drm_irq.c
> +++ b/drivers/gpu/drm/drm_irq.c
> @@ -214,6 +214,41 @@ int drm_irq_uninstall(struct drm_device *dev)
>  }
>  EXPORT_SYMBOL(drm_irq_uninstall);
>  
> +static void devm_drm_irq_uninstall(void *data)
> +{
> + drm_irq_uninstall(data);
> +}
> +
> +/**
> + * devm_drm_irq_install - install IRQ handler
> + * @dev: DRM device
> + * @irq: IRQ number to install the handler for
> + *
> + * devm_drm_irq_install is a  help function of drm_irq_install.
Drop the extra space after "is a"
> + *
> + * if the driver uses devm_drm_irq_install, there is no need
Start with capital "I" in If
> + * to call drm_irq_uninstall when the drm module get unloaded,
> + * as this will done automagically.
> + *
> + * Returns:
> + * Zero on success or a negative error code on failure.
> + */
> +int devm_drm_irq_install(struct drm_device *dev, int irq)
> +{
> + int ret;
> +
> + ret = drm_irq_install(dev, irq);
> + if (ret)
> + return ret;
> +
> + ret = devm_add_action_or_reset(dev->dev, devm_drm_irq_uninstall, dev);
> + if (ret)
> + devm_drm_irq_uninstall(dev);
devm_add_action_or_reset() will call devm_drm_irq_uninstall() if ret is
!= 0. See include/device.h.

I guess that is the "_or_reset" part of the name that can tell us that.
So you can drop the if condition as it just will cause the code to call
drm_irq_uninstall() twice.

> +
> + return ret;
> +}
> +EXPORT_SYMBOL(devm_drm_irq_install);
> +
>  #if IS_ENABLED(CONFIG_DRM_LEGACY)
>  int drm_legacy_irq_control(struct drm_device *dev, void *data,
>  struct drm_file *file_priv)
> diff --git a/include/drm/drm_irq.h b/include/drm/drm_irq.h
> index d77f6e6..631b22f 100644
> --- a/include/drm/drm_irq.h
> +++ b/include/drm/drm_irq.h
> @@ -28,5 +28,5 @@ struct drm_device;
>  
>  int drm_irq_install(struct drm_device *dev, int irq);
>  int drm_irq_uninstall(struct drm_device *dev);
> -
> +int devm_drm_irq_install(struct drm_device *dev, int irq);
>  #endif
> -- 
> 2.7.4
> 
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v5 1/6] dt-bindings: display: simple: Add EDT ETM0700G0BDH6 display

2020-12-01 Thread Sam Ravnborg
Hi Oleksij

On Tue, Dec 01, 2020 at 10:27:37AM +0100, Oleksij Rempel wrote:
> This display is already supported by the panel-simple driver, so add it
> to the bindings documentation.
> 
> This patch is needed to fix checkpatch warnings for the PLYM2M dts.
> 
> Signed-off-by: Oleksij Rempel 
> ---
>  .../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git 
> a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml 
> b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
> index edb53ab0d9eb..a011d9e44af3 100644
> --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
> +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
> @@ -117,6 +117,8 @@ properties:
>- edt,etm0700g0dh6
>  # Emerging Display Technology Corp. WVGA TFT Display with capacitive 
> touch
>  # Same as ETM0700G0DH6 but with inverted pixel clock.
> +  - edt,etm0700g0bdh6
> +# Emerging Display Technology Corp. WVGA TFT Display with capacitive 
> touch
>- edt,etm070080bdh6
>  # Emerging Display Technology Corp. WVGA TFT Display with capacitive 
> touch
>  # Same display as the ETM0700G0BDH6, but with changed hardware for 
> the

The panels should be listed in alphabetic order which is not the case
here. Could you fix the alphabetic order for the edt panels and then
insert the new panel in the right spot?

Sam


Re: [PATCH v5] drm/bridge: add it6505 driver

2020-12-01 Thread Sam Ravnborg
Hi Allen.
On Tue, Dec 01, 2020 at 01:44:41PM +0800, allen wrote:
> This adds support for the iTE IT6505.
> This device can convert DPI signal to DP output.
> 
> From: Allen Chen 
> Signed-off-by: Jitao Shi 
> Signed-off-by: Pi-Hsun Shih 
> Signed-off-by: Yilun Lin 
> Signed-off-by: Hermes Wu 
> Signed-off-by: Allen Chen 

I recall I provided the same comment as last time, but may remember
wrong.

New bridge drivers shall support that connector creation is optional.
This driver does not do that - see following code snippet:

+   if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR) {
+   DRM_ERROR("Fix bridge driver to make connector optional!");
+   return -EINVAL;
+   }
+

I did not check, but likely the drive needs to implment some of the
connector hooks too. (detect, get_edid, etc).

Please include a changelog too - it can be very hard to remember what
feedback was provided when one reviews several patches/week.

Sam


Re: [PATCH 0/5] drop unused BACKLIGHT_GENERIC option

2020-11-30 Thread Sam Ravnborg
Hi Krzysztof,
On Mon, Nov 30, 2020 at 10:25:01PM +0200, Krzysztof Kozlowski wrote:
> On Mon, Nov 30, 2020 at 08:11:33PM +0100, Sam Ravnborg wrote:
> > On Mon, Nov 30, 2020 at 03:21:32PM +, Andrey Zhizhikin wrote:
> > > Since the removal of generic_bl driver from the source tree in commit
> > > 7ecdea4a0226 ("backlight: generic_bl: Remove this driver as it is
> > > unused") BACKLIGHT_GENERIC config option became obsolete as well and
> > > therefore subject to clean-up from all configuration files.
> > > 
> > > This series introduces patches to address this removal, separated by
> > > architectures in the kernel tree.
> > > 
> > > Andrey Zhizhikin (5):
> > >   ARM: configs: drop unused BACKLIGHT_GENERIC option
> > >   arm64: defconfig: drop unused BACKLIGHT_GENERIC option
> > >   MIPS: configs: drop unused BACKLIGHT_GENERIC option
> > >   parisc: configs: drop unused BACKLIGHT_GENERIC option
> > >   powerpc/configs: drop unused BACKLIGHT_GENERIC option
> > 
> > For defconfigs I expect arch maintainers to do a make xxxdefconfig / make
> > savedefconfig / cp defconfig ... run now and then - this will remove
> > all such symbols.
> 
> savedefconfig can be tricky because of risk of loosing options:
> 1. it will remove options which became the default or became selected,
> 2. later when the default is changed or selecting option is removed, the
>first option from #1 will not be brought back.
> 
> This was already for example with DEBUG_FS and the conclusion that time
> was - do not run savedefconfig automatically.
> 
> Therefore if some symbol(s) can be safely removed, patch is welcomed.

Thanks for letting me know, I have missed that discussion and
was obviously not aware.
I already acked'ed the patches and hope the soc people will pick them
up.

Sam


Re: [PATCH 0/5] drop unused BACKLIGHT_GENERIC option

2020-11-30 Thread Sam Ravnborg
On Mon, Nov 30, 2020 at 03:21:32PM +, Andrey Zhizhikin wrote:
> Since the removal of generic_bl driver from the source tree in commit
> 7ecdea4a0226 ("backlight: generic_bl: Remove this driver as it is
> unused") BACKLIGHT_GENERIC config option became obsolete as well and
> therefore subject to clean-up from all configuration files.
> 
> This series introduces patches to address this removal, separated by
> architectures in the kernel tree.
> 
> Andrey Zhizhikin (5):
>   ARM: configs: drop unused BACKLIGHT_GENERIC option
>   arm64: defconfig: drop unused BACKLIGHT_GENERIC option
>   MIPS: configs: drop unused BACKLIGHT_GENERIC option
>   parisc: configs: drop unused BACKLIGHT_GENERIC option
>   powerpc/configs: drop unused BACKLIGHT_GENERIC option

For defconfigs I expect arch maintainers to do a make xxxdefconfig / make
savedefconfig / cp defconfig ... run now and then - this will remove
all such symbols.

If the patches goes in like they are submitted then:
Acked-by: Sam Ravnborg 

> 
>  arch/arm/configs/at91_dt_defconfig  | 1 -
>  arch/arm/configs/cm_x300_defconfig  | 1 -
>  arch/arm/configs/colibri_pxa300_defconfig   | 1 -
>  arch/arm/configs/jornada720_defconfig   | 1 -
>  arch/arm/configs/magician_defconfig | 1 -
>  arch/arm/configs/mini2440_defconfig | 1 -
>  arch/arm/configs/omap2plus_defconfig| 1 -
>  arch/arm/configs/pxa3xx_defconfig   | 1 -
>  arch/arm/configs/qcom_defconfig | 1 -
>  arch/arm/configs/sama5_defconfig| 1 -
>  arch/arm/configs/sunxi_defconfig| 1 -
>  arch/arm/configs/tegra_defconfig| 1 -
>  arch/arm/configs/u8500_defconfig| 1 -
>  arch/arm64/configs/defconfig| 1 -
>  arch/mips/configs/gcw0_defconfig| 1 -
>  arch/mips/configs/gpr_defconfig | 1 -
>  arch/mips/configs/lemote2f_defconfig| 1 -
>  arch/mips/configs/loongson3_defconfig   | 1 -
>  arch/mips/configs/mtx1_defconfig| 1 -
>  arch/mips/configs/rs90_defconfig| 1 -
>  arch/parisc/configs/generic-64bit_defconfig | 1 -
>  arch/powerpc/configs/powernv_defconfig  | 1 -
>  22 files changed, 22 deletions(-)
> 
> 
> base-commit: b65054597872ce3aefbc6a666385eabdf9e288da
> prerequisite-patch-id: bfd382cf1dc021d20204f10ea9403319c1c32b12
> prerequisite-patch-id: 5397c0c8648bb3e0b830207ea867138c11c6e644
> prerequisite-patch-id: a3c284dff5fe6d02828918a886db6a8ed3197e20
> -- 
> 2.17.1


Re: [PATCH v4 2/5] drm: panel: simple: Defer unprepare delay till next prepare to shorten it

2020-11-29 Thread Sam Ravnborg
Hi Douglas,
On Mon, Nov 09, 2020 at 05:00:56PM -0800, Douglas Anderson wrote:
> It is believed that all of the current users of the "unprepare" delay
> don't actually need to wait the amount of time specified directly in
> the unprepare phase.  The purpose of the delay that's specified is to
> allow the panel to fully power off so that we don't try to power it
> back on before it's managed to full power down.
> 
> Let's use this observation to avoid the fixed delay that we currently
> have.  Instead of delaying, we'll note the current time when the
> unprepare happens.  If someone then tries to prepare the panel later
> and not enough time has passed, we'll do the delay before starting the
> prepare phase.
> 
> Signed-off-by: Douglas Anderson 

Applied to drm-misc-next.

Sam


Re: [PATCH v4 3/5] drm: panel: simple: Allow specifying the delay from prepare to enable

2020-11-29 Thread Sam Ravnborg
Hi Douglas,

On Mon, Nov 09, 2020 at 05:00:57PM -0800, Douglas Anderson wrote:
> On the panel I'm looking at, there's an 80 ms minimum time between HPD
> being asserted by the panel and setting the backlight enable GPIO.
> While we could just add an 80 ms "enable" delay, this is not ideal.
> Link training is allowed to happen in parallel with this delay so the
> fixed 80 ms delay over-delays.
> 
> We'll support this by logging the time at the end of prepare and then
> delaying in enable if enough time hasn't passed.
> 
> Signed-off-by: Douglas Anderson 
Applied too.

Sam


Re: [PATCH v4 4/5] drm: panel: simple: Add BOE NV110WTM-N61

2020-11-29 Thread Sam Ravnborg
Hi Douglas,

On Mon, Nov 09, 2020 at 05:00:58PM -0800, Douglas Anderson wrote:
> Add support for the BOE NV110WTM-N61 panel.  The EDID lists two modes
> (one for 60 Hz refresh rate and one for 40 Hz), so we'll list both of
> them here.
> 
> Note that the panel datasheet requires 80 ms between HPD asserting and
> the backlight power being turned on.  We'll use the new timing
> constraints structure to do this cleanly.  This assumes that the
> backlight will be enabled _after_ the panel enable finishes.  This is
> how it works today and seems a sane assumption.
> 
> Signed-off-by: Douglas Anderson 

I applied the binding patch (bindings before driver patch),
and added the missing flags while applying this patch.
All to drm-misc-next.

Sam


Re: [PATCH v4 1/5] drm: panel: simple: Fixup the struct panel_desc kernel doc

2020-11-29 Thread Sam Ravnborg
Hi Douglas,
On Mon, Nov 09, 2020 at 05:00:55PM -0800, Douglas Anderson wrote:
> When I run:
>   scripts/kernel-doc -rst drivers/gpu/drm/panel/panel-simple.c
> 
> I see that several of the kernel-doc entries aren't showing up because
> they don't specify the full path down the hierarchy.  Let's fix that
> and also move to inline kernel docs.
> 
> Signed-off-by: Douglas Anderson 

Thanks, applied to drm-misc-next.

Could you do a follow-up patch that moves the rest as inline comments
and verify that all fields are described.  (W=1 should show no warnings).
That would be appreciated!

Sam


Re: [PATCH 0/3] drm/ingenic: Add support for delta-RGB panels

2020-11-29 Thread Sam Ravnborg
Hi Paul.

On Thu, Nov 19, 2020 at 03:55:56PM +, Paul Cercueil wrote:
> Hi,
> 
> This patchset adds support for delta-RGB panels to the ingenic-drm
> driver. Delta-RGB panels have diamond-pattern subpixel layout, and
> expect odd lines to have RGB subpixel ordering, and even lines to have
> GBR subpixel ordering.
> 
> Such panel is used in the YLM (aka. Anbernic) RG-99, RG-300, RG-280M
> and RG-280V handheld gaming consoles.
> 
> Cheers,
> -Paul
> 
> Paul Cercueil (3):
>   drm/ingenic: Compute timings according to adjusted_mode->crtc_*
>   drm/ingenic: Properly compute timings when using a 3x8-bit panel
>   drm/ingenic: Add support for serial 8-bit delta-RGB panels

Strange panel, at least strange bit order.
Patches looks good and are all:
Reviewed-by: Sam Ravnborg 


Re: [PATCH] omapfb: fbcon: remove trailing semicolon in macro definition

2020-11-29 Thread Sam Ravnborg
Hi Tom,
On Fri, Nov 27, 2020 at 11:05:08AM -0800, t...@redhat.com wrote:
> From: Tom Rix 
> 
> The macro use will already have a semicolon.
> 
> Signed-off-by: Tom Rix 

Thanks, applied to drm-misc-next.

Sam


Re: [PATCH] msm/mdp5: Fix some kernel-doc warnings

2020-11-29 Thread Sam Ravnborg
Hi Rob,
On Sun, Nov 29, 2020 at 10:12:40AM -0800, Rob Clark wrote:
> From: Rob Clark 
> 
> Fixes the following W=1 kernel build warning(s):
> 
>  drivers/gpu/drm/msm/disp/mdp5/mdp5_ctl.c:227: warning: Function parameter or 
> member 'ctl' not described in 'mdp5_ctl_set_encoder_state'
>  drivers/gpu/drm/msm/disp/mdp5/mdp5_ctl.c:227: warning: Function parameter or 
> member 'pipeline' not described in 'mdp5_ctl_set_encoder_state'
>  drivers/gpu/drm/msm/disp/mdp5/mdp5_ctl.c:227: warning: Function parameter or 
> member 'enabled' not described in 'mdp5_ctl_set_encoder_state'
>  drivers/gpu/drm/msm/disp/mdp5/mdp5_ctl.c:227: warning: Excess function 
> parameter 'enable' description in 'mdp5_ctl_set_encoder_state'
>  drivers/gpu/drm/msm/disp/mdp5/mdp5_ctl.c:529: warning: Function parameter or 
> member 'ctl' not described in 'mdp5_ctl_commit'
>  drivers/gpu/drm/msm/disp/mdp5/mdp5_ctl.c:529: warning: Function parameter or 
> member 'pipeline' not described in 'mdp5_ctl_commit'
>  drivers/gpu/drm/msm/disp/mdp5/mdp5_ctl.c:529: warning: Function parameter or 
> member 'flush_mask' not described in 'mdp5_ctl_commit'
>  drivers/gpu/drm/msm/disp/mdp5/mdp5_ctl.c:529: warning: Function parameter or 
> member 'start' not described in 'mdp5_ctl_commit'
> 
> Cc: Lee Jones 
> Signed-off-by: Rob Clark 

Looks fine,
Acked-by: Sam Ravnborg 


Re: [PATCH] drm/ingenic: Add basic PM support

2020-11-28 Thread Sam Ravnborg
Hi Paul.

On Sat, Nov 28, 2020 at 05:16:06PM +, Paul Cercueil wrote:
> Call drm_mode_config_helper_suspend() and
> drm_mode_config_helper_resume() on suspend and resume, respectively.
> 
> This makes sure that the display stack is properly disabled when the
> hardware is put to sleep.
> 
> Signed-off-by: Paul Cercueil 

As discussed on irc, with resume fixed to return the result of the
drm_mode_config_helper_resume() call.

Reviewed-by: Sam Ravnborg 


Re: [PATCH 1/2] panel-simple: add Innolux N125HCE-GN1

2020-11-24 Thread Sam Ravnborg
Hi Lukas.

On Tue, Nov 24, 2020 at 06:26:04PM +0100, Lukas F. Hartmann wrote:
> The Innolux N125HCE-GN1 display is used in the MNT Reform 2.0 laptop,
> attached via eDP to a SN65DSI86 MIPI-DSI to eDP bridge.
> 
> Signed-off-by: Lukas F. Hartmann 

Danke, applied to drm-misc-next.

Sam


Re: [PATCH 2/2] dt-bindings: display/panel: add Innolux N125HCE-GN1

2020-11-24 Thread Sam Ravnborg
Hi Lukas

On Tue, Nov 24, 2020 at 06:26:06PM +0100, Lukas F. Hartmann wrote:
> The Innolux N125HCE-GN1 display is used in the MNT Reform 2.0 laptop,
> attached via eDP to a SN65DSI86 MIPI-DSI to eDP bridge. This patch
> contains the DT binding for "innolux,n125hce-gn1".
> 
> Signed-off-by: Lukas F. Hartmann 

bindings before their usage, so this should be first patch.

> ---
>  .../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git 
> a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml 
> b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
> index edb53ab0d..03b3e0b9d 100644
> --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
> +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
> @@ -160,6 +160,8 @@ properties:
>  # Innolux Corporation 11.6" WXGA (1366x768) TFT LCD panel
>- innolux,n116bge
>  # InnoLux 15.6" WXGA TFT LCD panel
> +  - innolux,n125hce-gn1
> +# InnoLux 13.3" FHD (1920x1080) eDP TFT LCD panel

Comments before the compatible.

I applied this first and reordered the comment - so both details are
handled.

Applied to drm-misc-next.

Sam


Re: [PATCH v2 1/6] drm/panel: st7703: Use dev_err_probe

2020-11-23 Thread Sam Ravnborg
On Wed, Nov 18, 2020 at 09:29:48AM +0100, Guido Günther wrote:
> Less code and easier probe deferral debugging.
> 
> Signed-off-by: Guido Günther 
> Reviewed-by: Linus Walleij 

Nice.

I hope someone comes around and update all panel drivers to use
dev_err_probe. It is simpler and better than the current code.
And it will fix a lot of drivers that are noisy during deferral.

Sam


Re: [PATCH v2 0/6] drm/panel: mantix and st7703 fixes and additions

2020-11-23 Thread Sam Ravnborg
Hi Guido,

On Wed, Nov 18, 2020 at 09:29:47AM +0100, Guido Günther wrote:
> This adds new panel type to the mantix driver as found on the Librem 5 and
> fixes a glitch in the init sequence (affecting both panels). The fix is at the
> start of the series to make backporting simpler.
> It also adds a patch to make st7703 use dev_err_probe().
> 
> changes from v1
> - as per review comments by Linus Walleij
>   - fix alphabetical ordering in 
> Documentation/devicetree/bindings/vendor-prefixes.yaml
> 
> https://lore.kernel.org/dri-devel/CACRpkdao_TMcpRsdK=7k5fnkjse0bqwk58iwu0xsxddndcf...@mail.gmail.com/
>   - add reviewed by to all except 5/6, thanks
> 
> Guido Günther (6):
>   drm/panel: st7703: Use dev_err_probe
>   drm/panel: mantix: Tweak init sequence
>   drm/panel: mantix: Allow to specify default mode for different panels
>   drm/panel: mantix: Support panel from Shenzhen Yashi Changhua
> Intelligent Technology Co
>   dt-bindings: vendor-prefixes: Add ys vendor prefix
The above are all:
Reviewed-by: Sam Ravnborg 

>   dt-binding: display: mantix: Add compatible for panel from YS
Please fix the subjects to read "dt-bindings" - just to be consistent.
With that:
Reviewed-by: Sam Ravnborg 


Sam


Re: [PATCH] via/via_irq: use __func__ to replace string function name

2020-11-23 Thread Sam Ravnborg
Hi Bernard.

On Wed, Nov 18, 2020 at 11:29:55PM -0800, Bernard Zhao wrote:
> This change also fix checkpatch.pl warning:
> WARNING: Prefer using '"%s...", __func__' to using
> 'via_driver_irq_postinstall', this function's name, in a string
> + DRM_DEBUG("via_driver_irq_postinstall\n");
> 
> Signed-off-by: Bernard Zhao 
> ---
>  drivers/gpu/drm/via/via_irq.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/via/via_irq.c b/drivers/gpu/drm/via/via_irq.c
> index 24cc445169e2..56ce5d4ee24a 100644
> --- a/drivers/gpu/drm/via/via_irq.c
> +++ b/drivers/gpu/drm/via/via_irq.c
> @@ -308,7 +308,7 @@ int via_driver_irq_postinstall(struct drm_device *dev)
>   drm_via_private_t *dev_priv = (drm_via_private_t *) dev->dev_private;
>   u32 status;
>  
> - DRM_DEBUG("via_driver_irq_postinstall\n");
> + DRM_DEBUG("fun: %s\n", __func__);

DRM_DEBUG() will print the name of the calling function so the use of
__func__ here is not relevant.


For this old driver we should try to limit patches to bug fixing and
infrastructure updates.

Sam


Re: [PATCH 2/2] drm: panel: add Khadas TS050 panel driver

2020-11-23 Thread Sam Ravnborg
Hi Neil.

Looks good but a few comments in the following that needs some attention.

Sam

On Mon, Nov 23, 2020 at 03:33:54PM +0100, Neil Armstrong wrote:
> This add support for the Khadas TS050 1080x1920 5" LCD DSI panel designed to 
> work
> with the Khadas Edge-V, Captain, VIM3 and VIM3L Single Board Computers.
> It provides a MIPI DSI interface to the host, a built-in LED backlight
> and touch controller.
> 
> The init values was taken from the vendor source tree, comments were added to 
> the
> know values but most of the init table is undocumented.
> 
> Signed-off-by: Neil Armstrong 
> ---
>  drivers/gpu/drm/panel/Kconfig  |  11 +
>  drivers/gpu/drm/panel/Makefile |   1 +
>  drivers/gpu/drm/panel/panel-khadas-ts050.c | 876 +
>  3 files changed, 888 insertions(+)
>  create mode 100644 drivers/gpu/drm/panel/panel-khadas-ts050.c
> 
> diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
> index b4e021ea30f9..8fec45b2ce02 100644
> --- a/drivers/gpu/drm/panel/Kconfig
> +++ b/drivers/gpu/drm/panel/Kconfig
> @@ -145,6 +145,17 @@ config DRM_PANEL_JDI_LT070ME05000
> The panel has a 1200(RGB)×1920 (WUXGA) resolution and uses
> 24 bit per pixel.
>  
> +config DRM_PANEL_KHADAS_TS050
> + tristate "Khadas TS050 panel"
> + depends on OF
> + depends on DRM_MIPI_DSI
> + depends on BACKLIGHT_CLASS_DEVICE
> + help
> +   Say Y here if you want to enable support for Khadas TS050 TFT-LCD
> +   panel module. The panel has a 1080x1920 resolution and uses
> +   24 bit RGB per pixel. It provides a MIPI DSI interface to
> +   the host, a built-in LED backlight and touch controller.
> +
>  config DRM_PANEL_KINGDISPLAY_KD097D04
>   tristate "Kingdisplay kd097d04 panel"
>   depends on OF
> diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
> index ebbf488c7eac..03496695e03f 100644
> --- a/drivers/gpu/drm/panel/Makefile
> +++ b/drivers/gpu/drm/panel/Makefile
> @@ -13,6 +13,7 @@ obj-$(CONFIG_DRM_PANEL_ILITEK_IL9322) += 
> panel-ilitek-ili9322.o
>  obj-$(CONFIG_DRM_PANEL_ILITEK_ILI9881C) += panel-ilitek-ili9881c.o
>  obj-$(CONFIG_DRM_PANEL_INNOLUX_P079ZCA) += panel-innolux-p079zca.o
>  obj-$(CONFIG_DRM_PANEL_JDI_LT070ME05000) += panel-jdi-lt070me05000.o
> +obj-$(CONFIG_DRM_PANEL_KHADAS_TS050) += panel-khadas-ts050.o
>  obj-$(CONFIG_DRM_PANEL_KINGDISPLAY_KD097D04) += panel-kingdisplay-kd097d04.o
>  obj-$(CONFIG_DRM_PANEL_LEADTEK_LTK050H3146W) += panel-leadtek-ltk050h3146w.o
>  obj-$(CONFIG_DRM_PANEL_LEADTEK_LTK500HD1829) += panel-leadtek-ltk500hd1829.o
> diff --git a/drivers/gpu/drm/panel/panel-khadas-ts050.c 
> b/drivers/gpu/drm/panel/panel-khadas-ts050.c
> new file mode 100644
> index ..856fcad69306
> --- /dev/null
> +++ b/drivers/gpu/drm/panel/panel-khadas-ts050.c
> @@ -0,0 +1,876 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2020 BayLibre, SAS
> + * Author: Neil Armstrong 
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
Panels do not use DRM_ or drm_ for logging, so this include is not
needed.

> +
> +struct khadas_ts050_panel {
> + struct drm_panel base;
> + struct mipi_dsi_device *link;
> +
> + struct regulator *supply;
> + struct gpio_desc *reset_gpio;
> + struct gpio_desc *enable_gpio;
> +
> + bool prepared;
> + bool enabled;
> +};
> +
> +struct khadas_ts050_panel_cmd {
> + u8 cmd;
> + u8 data;
> +};
> +
> +/* Only the CMD1 User Command set is documented */
> +static const struct khadas_ts050_panel_cmd init_code[] = {
> + /* Select Unknown CMD Page (Undocumented) */
> + {0xff, 0xee},
...
> + {0xd4, 0x04}, /* RGBMIPICTRL: VSYNC front porch = 4 */
> +};
> +
> +static inline
> +struct khadas_ts050_panel *to_khadas_ts050_panel(struct drm_panel *panel)
> +{
> + return container_of(panel, struct khadas_ts050_panel, base);
> +}
> +
> +static int khadas_ts050_panel_prepare(struct drm_panel *panel)
> +{
> + struct khadas_ts050_panel *khadas_ts050 = to_khadas_ts050_panel(panel);
> + int err, regulator_err;
> + unsigned int i;
> +
> + if (khadas_ts050->prepared)
> + return 0;
> +
> + gpiod_set_value_cansleep(khadas_ts050->enable_gpio, 0);
> +
> + err = regulator_enable(khadas_ts050->supply);
> + if (err < 0)
> + return err;
> +
> + gpiod_set_value_cansleep(khadas_ts050->enable_gpio, 1);
> +
> + msleep(60);
> +
> + gpiod_set_value_cansleep(khadas_ts050->reset_gpio, 1);
> +
> + usleep_range(1, 11000);
> +
> + gpiod_set_value_cansleep(khadas_ts050->reset_gpio, 0);
> +
> + /* Select CMD2 page 4 (Undocumented) */
> + mipi_dsi_dcs_write(khadas_ts050->link, 0xff, (u8[]){ 0x05 }, 1);
> +
> + /* Reload CMD1: Don't reload default value to register */
> + 

Re: [PATCH 1/2] dt-bindings: panel-simple-dsi: add Khadas TS050 panel bindings

2020-11-23 Thread Sam Ravnborg
On Mon, Nov 23, 2020 at 03:33:53PM +0100, Neil Armstrong wrote:
> This add the bindings for the Khadas TS050 1080x1920 5" LCD DSI panel 
> designed to work
> with the Khadas Edge-V, Captain, VIM3 and VIM3L Single Board Computers.
> 
> Signed-off-by: Neil Armstrong 
Reviewed-by: Sam Ravnborg 


Re: [PATCH 000/141] Fix fall-through warnings for Clang

2020-11-22 Thread Sam Ravnborg
Hi James.

> > > If none of the 140 patches here fix a real bug, and there is no
> > > change to machine code then it sounds to me like a W=2 kind of a
> > > warning.
> > 
> > FWIW, this series has found at least one bug so far:
> > https://lore.kernel.org/lkml/CAFCwf11izHF=g1mGry1fE5kvFFFrxzhPSM6qKAO8gxSp=kr...@mail.gmail.com/
> 
> 
> Well, it's a problem in an error leg, sure, but it's not a really
> compelling reason for a 141 patch series, is it?  All that fixing this
> error will do is get the driver to print "oh dear there's a problem"
> under four more conditions than it previously did.

You are asking the wrong question here.

Yuo should ask  how many hours could have been saved by all the bugs
people have been fighting with and then fixed *before* the code
hit the kernel at all.

My personal experience is that I, more than once, have had errors
related to a missing break in my code. So this warnings is IMO a win.

And if we are only ~100 patches to have it globally enabled then it is a
no-brainer in my book.

Sam


Re: [PATCH 134/141] video: fbdev: lxfb_ops: Fix fall-through warnings for Clang

2020-11-22 Thread Sam Ravnborg
Hi Gustavo,
On Fri, Nov 20, 2020 at 12:40:32PM -0600, Gustavo A. R. Silva wrote:
> In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
> by explicitly adding a break statement instead of letting the code fall
> through to the next case.
> 
> Link: https://github.com/KSPP/linux/issues/115
> Signed-off-by: Gustavo A. R. Silva 

Thanks, applied this and the following patch to drm-misc-next.
Looks forward to have this warning enabled.

One can only wonder how many hours will be saved by lettting the
compiler tell you a break is missing. This is the kind of bugs you can
stare you blind at.

Sam


Re: [PATCH 079/141] drm: Fix fall-through warnings for Clang

2020-11-22 Thread Sam Ravnborg
Hi Gustavo,
On Fri, Nov 20, 2020 at 12:35:17PM -0600, Gustavo A. R. Silva wrote:
> In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
> by explicitly adding a break statement instead of letting the code fall
> through to the next case.
> 
> Link: https://github.com/KSPP/linux/issues/115
> Signed-off-by: Gustavo A. R. Silva 

thanks, applied to drm-misc-next.

Sam

> ---
>  drivers/gpu/drm/drm_bufs.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/drm_bufs.c b/drivers/gpu/drm/drm_bufs.c
> index 7a01d0918861..aeb1327e3077 100644
> --- a/drivers/gpu/drm/drm_bufs.c
> +++ b/drivers/gpu/drm/drm_bufs.c
> @@ -77,6 +77,7 @@ static struct drm_map_list *drm_find_matching_map(struct 
> drm_device *dev,
>   if ((entry->map->offset & 0x) ==
>   (map->offset & 0x))
>   return entry;
> + break;
>   default: /* Make gcc happy */
>   ;
>   }
> -- 
> 2.27.0
> 
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 084/141] drm/via: Fix fall-through warnings for Clang

2020-11-22 Thread Sam Ravnborg
On Fri, Nov 20, 2020 at 12:35:54PM -0600, Gustavo A. R. Silva wrote:
> In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
> by explicitly adding a break statement instead of letting the code fall
> through to the next case.
> 
> Link: https://github.com/KSPP/linux/issues/115
> Signed-off-by: Gustavo A. R. Silva 

Thanks, also applied to drm-misc-next.

Sam

> ---
>  drivers/gpu/drm/via/via_irq.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/via/via_irq.c b/drivers/gpu/drm/via/via_irq.c
> index 24cc445169e2..a3e0fb5b8671 100644
> --- a/drivers/gpu/drm/via/via_irq.c
> +++ b/drivers/gpu/drm/via/via_irq.c
> @@ -364,6 +364,7 @@ int via_wait_irq(struct drm_device *dev, void *data, 
> struct drm_file *file_priv)
>   irqwait->request.sequence +=
>   atomic_read(_irq->irq_received);
>   irqwait->request.type &= ~_DRM_VBLANK_RELATIVE;
> + break;
>   case VIA_IRQ_ABSOLUTE:
>   break;
>   default:
> -- 
> 2.27.0
> 
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v4 10/27] video: fix some kernel-doc markups

2020-11-16 Thread Sam Ravnborg
Hi Daniel
> > Feel free to just merge it via your tree. Patches here are pretty
> > much independent ;-)
> 
> Ok I put it into drm-misc-next. I kinda assumed since there's also a huge
> effort going on to shut up warnings, plus I think kerneldoc issues are
> reported by a bunch of build bots nowadays. So assumed you pile this all
> up.

Any reason "drm: fix some kernel-doc markups" was not applied?

Sam


Re: [PATCH 12/40] drm/pl111/pl111_display: Make local function static

2020-11-16 Thread Sam Ravnborg
Hi Lee,
On Mon, Nov 16, 2020 at 10:25:30AM +, Lee Jones wrote:
> On Mon, 16 Nov 2020, Sam Ravnborg wrote:
> 
> > Hi Lee,
> > On Mon, Nov 16, 2020 at 08:40:23AM +, Lee Jones wrote:
> > > On Sat, 14 Nov 2020, Sam Ravnborg wrote:
> > > 
> > > > Hi Lee,
> > > > On Fri, Nov 13, 2020 at 01:49:10PM +, Lee Jones wrote:
> > > > > Fixes the following W=1 kernel build warning(s):
> > > > > 
> > > > >  drivers/gpu/drm/pl111/pl111_display.c:356:6: warning: no previous 
> > > > > prototype for ‘pl111_display_disable’ [-Wmissing-prototypes]
> > > > > 
> > > > > Cc: Eric Anholt 
> > > > > Cc: David Airlie 
> > > > > Cc: Daniel Vetter 
> > > > > Cc: dri-de...@lists.freedesktop.org
> > > > > Signed-off-by: Lee Jones 
> > > > 
> > > > Eric's was not copied on this or the other pl111 patch.
> > > > Added Eric so he can be aware of this fix.
> > > 
> > > Eric Anholt?
> > > 
> > > He's on Cc?
> > Not on the original mail I received.
> 
> Looks fine to me:
> 
> Date: Fri, 13 Nov 2020 13:49:10 +
> From: Lee Jones 
> To: lee.jo...@linaro.org
> Cc: linux-kernel@vger.kernel.org, Eric Anholt , David Airlie 
> , Daniel Vetter , 
> dri-de...@lists.freedesktop.org
> Subject: [PATCH 12/40] drm/pl111/pl111_display: Make local function static
> 
> Also reflected in Gmail:
> 
>  https://i.imgur.com/d69YTzz.png

Strange indeed. In lore Eric is not included:
https://lore.kernel.org/dri-devel/20201113134938.4004947-13-lee.jo...@linaro.org/

I consider this a fluke in the force, and will not worry more about it.

Sam


Re: [PATCH 12/40] drm/pl111/pl111_display: Make local function static

2020-11-16 Thread Sam Ravnborg
Hi Lee,
On Mon, Nov 16, 2020 at 08:40:23AM +, Lee Jones wrote:
> On Sat, 14 Nov 2020, Sam Ravnborg wrote:
> 
> > Hi Lee,
> > On Fri, Nov 13, 2020 at 01:49:10PM +, Lee Jones wrote:
> > > Fixes the following W=1 kernel build warning(s):
> > > 
> > >  drivers/gpu/drm/pl111/pl111_display.c:356:6: warning: no previous 
> > > prototype for ‘pl111_display_disable’ [-Wmissing-prototypes]
> > > 
> > > Cc: Eric Anholt 
> > > Cc: David Airlie 
> > > Cc: Daniel Vetter 
> > > Cc: dri-de...@lists.freedesktop.org
> > > Signed-off-by: Lee Jones 
> > 
> > Eric's was not copied on this or the other pl111 patch.
> > Added Eric so he can be aware of this fix.
> 
> Eric Anholt?
> 
> He's on Cc?
Not on the original mail I received.

Sam


Re: [PATCH 1/5] drm/panel/samsung-sofef00: Add panel for OnePlus 6/T devices

2020-11-14 Thread Sam Ravnborg
Hi Caleb,
On Thu, Nov 12, 2020 at 04:21:13PM +, Caleb Connolly wrote:
> The OnePlus 6/T devices use different panels however they are
> functionally identical with the only differences being the resolution.
> The panels also don't seem to be used by any other devices, just combine
> them into one driver.
> 
> The panels are: samsung,sofef00
> and samsung,s6e3fc2x01
> 
> Signed-off-by: Caleb Connolly 

Thanks, applied to drm-misc-next.
Fixed a few checkpatch --strict warnings when applying.
Please check with --strict in the future.

Sam


Re: [PATCH 2/5] dt-bindings: panel-simple-dsi: add samsung panels for OnePlus 6/T

2020-11-14 Thread Sam Ravnborg
Hi Caleb,
On Thu, Nov 12, 2020 at 04:21:30PM +, Caleb Connolly wrote:
> Add compatibles for the samsung,sofef00 and samsung,s6e3fc2x01 panels
> used in the OnePlus 6 & 6T respectively.
> 
> Signed-off-by: Caleb Connolly 

Thansk, applied to drm-misc-next.
Fixed so entries are sorted alphabetically when applying.

Sam


Re: [PATCH 13/40] drm/panel/panel-tpo-tpg110: Correct misnaming and supply missing param description

2020-11-14 Thread Sam Ravnborg
Hi Lee,
On Fri, Nov 13, 2020 at 01:49:11PM +, Lee Jones wrote:
> Fixes the following W=1 kernel build warning(s):
> 
>  drivers/gpu/drm/panel/panel-tpo-tpg110.c:94: warning: Function parameter or 
> member 'panel_mode' not described in 'tpg110'
>  drivers/gpu/drm/panel/panel-tpo-tpg110.c:372: warning: Function parameter or 
> member 'connector' not described in 'tpg110_get_modes'
> 
> Cc: Linus Walleij 
> Cc: Thierry Reding 
> Cc: Sam Ravnborg 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: dri-de...@lists.freedesktop.org
> Signed-off-by: Lee Jones 
Thanks, applied to drm-misc-next. Only one warning left in drm/panel/,
which I will submit a patch for in a minute.

Sam


Re: [PATCH 12/40] drm/pl111/pl111_display: Make local function static

2020-11-14 Thread Sam Ravnborg
Hi Lee,
On Fri, Nov 13, 2020 at 01:49:10PM +, Lee Jones wrote:
> Fixes the following W=1 kernel build warning(s):
> 
>  drivers/gpu/drm/pl111/pl111_display.c:356:6: warning: no previous prototype 
> for ‘pl111_display_disable’ [-Wmissing-prototypes]
> 
> Cc: Eric Anholt 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: dri-de...@lists.freedesktop.org
> Signed-off-by: Lee Jones 

Eric's was not copied on this or the other pl111 patch.
Added Eric so he can be aware of this fix.

Sam

> ---
>  drivers/gpu/drm/pl111/pl111_display.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/pl111/pl111_display.c 
> b/drivers/gpu/drm/pl111/pl111_display.c
> index b3e8697cafcf1..69c02e7c82b7e 100644
> --- a/drivers/gpu/drm/pl111/pl111_display.c
> +++ b/drivers/gpu/drm/pl111/pl111_display.c
> @@ -353,7 +353,7 @@ static void pl111_display_enable(struct 
> drm_simple_display_pipe *pipe,
>   drm_crtc_vblank_on(crtc);
>  }
>  
> -void pl111_display_disable(struct drm_simple_display_pipe *pipe)
> +static void pl111_display_disable(struct drm_simple_display_pipe *pipe)
>  {
>   struct drm_crtc *crtc = >crtc;
>   struct drm_device *drm = crtc->dev;
> -- 
> 2.25.1
> 
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH][next] drm/kmb: fix array out-of-bounds writes to kmb->plane_status[]

2020-11-13 Thread Sam Ravnborg
Hi Colin.
On Fri, Nov 13, 2020 at 03:04:34PM +, Colin Ian King wrote:
> On 13/11/2020 14:55, Sam Ravnborg wrote:
> > Hi Colin.
> > 
> > On Fri, Nov 13, 2020 at 12:01:21PM +, Colin King wrote:
> >> From: Colin Ian King 
> >>
> >> Writes to elements in the kmb->plane_status array in function
> >> kmb_plane_atomic_disable are overrunning the array when plane_id is
> >> more than 1 because currently the array is KMB_MAX_PLANES elements
> >> in size and this is currently #defined as 1.  Fix this by defining
> >> KMB_MAX_PLANES to 4.
> > 
> > I fail to follow you here.
> > In kmb_plane_init() only one plane is allocated - with id set to 0.
> > So for now only one plane is allocated thus kmb_plane_atomic_disable()
> > is only called for this plane.
> > 
> > With your change we will start allocating four planes, something that is
> > not tested.
> > 
> > Do I miss something?
> > 
> > Sam
> > 
> 
> The static analysis from coverity on linux-next suggested that there was
> an array overflow as follows:
> 
> 108 static void kmb_plane_atomic_disable(struct drm_plane *plane,
> 109 struct drm_plane_state *state)
> 110 {
> 
>1. Condition 0 /* !!(!__builtin_types_compatible_p() &&
> !__builtin_types_compatible_p()) */, taking false branch.
> 
> 111struct kmb_plane *kmb_plane = to_kmb_plane(plane);
> 
>2. assignment: Assigning: plane_id = kmb_plane->id.
> 
> 112int plane_id = kmb_plane->id;
> 113struct kmb_drm_private *kmb;
> 114
> 115kmb = to_kmb(plane->dev);
> 116
> 
>3. Switch case value LAYER_3.
> 
> 117switch (plane_id) {
> 118case LAYER_0:
> 119kmb->plane_status[plane_id].ctrl = LCD_CTRL_VL1_ENABLE;
> 120break;

With the current code this is the only case that hits.
So coverity is right that if we hit other cases that would result in a
bug. But kmb_plane->id will for now not have other values than 0.

So it is a subtle false positive.
There is some "dead" code here - but this is in preparation for more
than one layer and we will keep the code for now, unless Anitha chimes
in and says otherwise.

Sam

> 121case LAYER_1:
> 
>(#2 of 4): Out-of-bounds write (OVERRUN)
> 
> 122kmb->plane_status[plane_id].ctrl = LCD_CTRL_VL2_ENABLE;
> 123break;
> 124case LAYER_2:
> 
>(#3 of 4): Out-of-bounds write (OVERRUN)
> 
> 125kmb->plane_status[plane_id].ctrl = LCD_CTRL_GL1_ENABLE;
> 126break;
> 
>4. equality_cond: Jumping to case LAYER_3.
> 
> 127case LAYER_3:
> 
>(#1 of 4): Out-of-bounds write (OVERRUN)
>5. overrun-local: Overrunning array kmb->plane_status of 1 8-byte
> elements at element index 3 (byte offset 31) using index plane_id (which
> evaluates to 3).
> 
> 128kmb->plane_status[plane_id].ctrl = LCD_CTRL_GL2_ENABLE;
> 129break;
> 130}
> 131
> 
>(#4 of 4): Out-of-bounds write (OVERRUN)
> 
> 132kmb->plane_status[plane_id].disable = true;
> 133 }
> 134
> 
> So it seems the assignments to  kmb->plane_status[plane_id] are
> overrunning the array since plane_status is allocated as 1 element and
> yet plane_id can be 0..3
> 
> I could be misunderstanding this, or it may be a false positive.
> 
> Colin


Re: [PATCH][next] drm/kmb: fix array out-of-bounds writes to kmb->plane_status[]

2020-11-13 Thread Sam Ravnborg
Hi Colin.

On Fri, Nov 13, 2020 at 12:01:21PM +, Colin King wrote:
> From: Colin Ian King 
> 
> Writes to elements in the kmb->plane_status array in function
> kmb_plane_atomic_disable are overrunning the array when plane_id is
> more than 1 because currently the array is KMB_MAX_PLANES elements
> in size and this is currently #defined as 1.  Fix this by defining
> KMB_MAX_PLANES to 4.

I fail to follow you here.
In kmb_plane_init() only one plane is allocated - with id set to 0.
So for now only one plane is allocated thus kmb_plane_atomic_disable()
is only called for this plane.

With your change we will start allocating four planes, something that is
not tested.

Do I miss something?

Sam



Re: [PATCH] drm: bridge: dw-hdmi: Avoid resetting force in the detect function

2020-11-12 Thread Sam Ravnborg
Hi Jonathan
On Sat, Oct 31, 2020 at 07:17:47PM +1100, Jonathan Liu wrote:
> It has been observed that resetting force in the detect function can
> result in the PHY being powered down in response to hot-plug detect
> being asserted, even when the HDMI connector is forced on.
> 
> Enabling debug messages and adding a call to dump_stack() in
> dw_hdmi_phy_power_off() shows the following in dmesg:
> [  160.637413] dwhdmi-rockchip ff94.hdmi: EVENT=plugin
> [  160.637433] dwhdmi-rockchip ff94.hdmi: PHY powered down in 0 iterations
> 
> Call trace:
> dw_hdmi_phy_power_off
> dw_hdmi_phy_disable
> dw_hdmi_update_power
> dw_hdmi_detect
> dw_hdmi_connector_detect
> drm_helper_probe_detect_ctx
> drm_helper_hpd_irq_event
> dw_hdmi_irq
> irq_thread_fn
> irq_thread
> kthread
> ret_from_fork
> 
> Fixes: 381f05a7a842 ("drm: bridge/dw_hdmi: add connector mode forcing")
> Signed-off-by: Jonathan Liu 

Applied to drm-misc-fixes.

Sam


Re: [PATCH 04/30] drm/via/via_dma: Remove set but unused variable 'agp_base'

2020-11-12 Thread Sam Ravnborg
Hi Lee,
On Thu, Nov 12, 2020 at 07:00:13PM +, Lee Jones wrote:
> Fixes the following W=1 kernel build warning(s):
> 
>  drivers/gpu/drm/via/via_dma.c: In function ‘via_cmdbuf_jump’:
>  drivers/gpu/drm/via/via_dma.c:596:11: warning: variable ‘agp_base’ set but 
> not used [-Wunused-but-set-variable]
> 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: dri-de...@lists.freedesktop.org
> Signed-off-by: Lee Jones 

Applied to drm-misc-next.
So this is then the final from this set...

Sam


Re: [PATCH 02/30] include: drm: drm_atomic: Artificially use 'crtc' to avoid 'not used' warning

2020-11-12 Thread Sam Ravnborg
Hi Lee,

On Thu, Nov 12, 2020 at 07:00:11PM +, Lee Jones wrote:
> The precedent has already been set by other macros in the same file.
> 
> Fixes the following W=1 kernel build warning(s):
> 
>  drivers/gpu/drm/vkms/vkms_drv.c:55:19: warning: variable ‘crtc’ set but not 
> used [-Wunused-but-set-variable]
>  55 | struct drm_crtc *crtc;
>  | ^~~~
> 
> Cc: Maarten Lankhorst 
> Cc: Maxime Ripard 
> Cc: Thomas Zimmermann 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: Rob Clark 
> Cc: dri-de...@lists.freedesktop.org
> Signed-off-by: Lee Jones 

Also applied to drm-misc-next.
This was the last patch from this batch I will process.
The others are left for the maintainers to pick up.

Sam


Re: [PATCH 27/30] drm/sti/sti_hdmi: Move 'colorspace_mode_names' array to where its used

2020-11-12 Thread Sam Ravnborg
Hi Lee,
On Thu, Nov 12, 2020 at 07:00:36PM +, Lee Jones wrote:
> Fixes the following W=1 kernel build warning(s):
> 
>  drivers/gpu/drm/sti/sti_hdmi.h:36:40: warning: ‘colorspace_mode_names’ 
> defined but not used [-Wunused-const-variable=]
>  36 | static const struct drm_prop_enum_list colorspace_mode_names[] = {
>  | ^
> 
> Cc: Benjamin Gaignard 
> Cc: Vincent Abriou 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: Philipp Zabel 
> Cc: dri-de...@lists.freedesktop.org
> Signed-off-by: Lee Jones 

Applied to drm-misc-next,

Sam


Re: [PATCH 01/30] drm/savage/savage_bci: Remove set but never used 'aper_rsrc' and 'fb_rsrc'

2020-11-12 Thread Sam Ravnborg
On Thu, Nov 12, 2020 at 07:00:10PM +, Lee Jones wrote:
> The comment about them (also removed) says:
> 
>  /* fb_rsrc and aper_rsrc aren't really used currently, but still exist
>   * in case we decide we need information on the BAR for BSD in the
>   * future.
>   */
> 
> Well that was written 12 years ago in 2008.  We are now in the future
> and they are still superfluous.  We can always add them again at a
> later date if they are ever required.
> 
> Fixes the following W=1 kernel build warning(s):
> 
>  drivers/gpu/drm/savage/savage_bci.c: In function ‘savage_driver_firstopen’:
>  drivers/gpu/drm/savage/savage_bci.c:580:24: warning: variable ‘aper_rsrc’ 
> set but not used [-Wunused-but-set-variable]
>  drivers/gpu/drm/savage/savage_bci.c:580:15: warning: variable ‘fb_rsrc’ set 
> but not used [-Wunused-but-set-variable]
> 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: dri-de...@lists.freedesktop.org
> Signed-off-by: Lee Jones 
> ---

Thanks, applied to drm-misc-next.

Sam



Re: [PATCH 17/30] drm/atmel-hlcdc/atmel_hlcdc_plane: Fix documentation formatting and add missing description

2020-11-12 Thread Sam Ravnborg
On Thu, Nov 12, 2020 at 07:00:26PM +, Lee Jones wrote:
> Fixes the following W=1 kernel build warning(s):
> 
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c:283:6: warning: no previous 
> prototype for ‘atmel_hlcdc_plane_setup_scaler’ [-Wmissing-prototypes]
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c:44: warning: cannot 
> understand function prototype: 'struct atmel_hlcdc_plane_state '
> 
> Cc: Sam Ravnborg 
> Cc: Boris Brezillon 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: Nicolas Ferre 
> Cc: Alexandre Belloni 
> Cc: Ludovic Desroches 
> Cc: dri-de...@lists.freedesktop.org
> Cc: linux-arm-ker...@lists.infradead.org
> Signed-off-by: Lee Jones 

Thanks, applied to drm-misc-next.

Sam



Re: [PATCH 13/30] drm/atmel-hlcdc/atmel_hlcdc_crtc: Apply correct formatting to struct docs

2020-11-12 Thread Sam Ravnborg
On Thu, Nov 12, 2020 at 07:00:22PM +, Lee Jones wrote:
> And fix-up a misnamed member description.
> 
> Fixes the following W=1 kernel build warning(s):
> 
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c:33: warning: cannot 
> understand function prototype: 'struct atmel_hlcdc_crtc_state '
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c:52: warning: cannot 
> understand function prototype: 'struct atmel_hlcdc_crtc '
> 
> Cc: Sam Ravnborg 
> Cc: Boris Brezillon 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: Nicolas Ferre 
> Cc: Alexandre Belloni 
> Cc: Ludovic Desroches 
> Cc: Jean-Jacques Hiblot 
> Cc: dri-de...@lists.freedesktop.org
> Cc: linux-arm-ker...@lists.infradead.org
> Signed-off-by: Lee Jones 

Thanks, applied to drm-misc-next.

Sam



Re: [PATCH 16/30] drm/atmel-hlcdc/atmel_hlcdc_plane: Staticise local function 'atmel_hlcdc_plane_setup_scaler()'

2020-11-12 Thread Sam Ravnborg
On Thu, Nov 12, 2020 at 07:00:25PM +, Lee Jones wrote:
> Fixes the following W=1 kernel build warning(s):
> 
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c:283:6: warning: no previous 
> prototype for ‘atmel_hlcdc_plane_setup_scaler’ [-Wmissing-prototypes]
> 
> Cc: Sam Ravnborg 
> Cc: Boris Brezillon 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: Nicolas Ferre 
> Cc: Alexandre Belloni 
> Cc: Ludovic Desroches 
> Cc: dri-de...@lists.freedesktop.org
> Cc: linux-arm-ker...@lists.infradead.org
> Signed-off-by: Lee Jones 

Thanks, applied to drm-misc-next.

Sam



Re: [PATCH][next] drm/kmb: fix spelling mistakes in drm_info and drm_dbg messages

2020-11-11 Thread Sam Ravnborg
Hi Colin,

On Mon, Nov 09, 2020 at 11:12:25AM +, Colin King wrote:
> From: Colin Ian King 
> 
> There are two spelling mistakes of the word sync in drm_info
> and drm_dbg messages. Fix these.
> 
> Signed-off-by: Colin Ian King 

Thanks, applied to drm-misc-next.

Sam


Re: [PATCH] drm/panel: add missing platform_driver_unregister() on error path

2020-11-10 Thread Sam Ravnborg
Hi Yang,

On Wed, Nov 11, 2020 at 02:44:25PM +0800, Yang Yingliang wrote:
> If mipi_dsi_driver_register() failed, platform_driver_unregister()
> need be called.
> 
> Fixes: 210fcd9d9cf1 ("drm/panel: Add support for Panasonic VVX10F004B0")
> Reported-by: Hulk Robot 
> Signed-off-by: Yang Yingliang 

Thanks for the patch but this is already fixed in drm-misx-next.
See:

commit f2e66f212a9de04afc2caa5ec79057c0ac75c728
drm: panel: simple: add missing platform_driver_unregister() in 
panel_simple_init

Sam


Re: [PATCH 15/20] drm/radeon/r600d: Move 'rc600_*' prototypes into shared header

2020-11-10 Thread Sam Ravnborg
Hi Lee,

> > the *d.h headers are supposed to just be hardware definitions.  I'd
> > prefer to keep driver stuff out of them.
> 
> That's fine (I did wonder if that were the case).
> 
> I need an answer from you and Sam whether I can create new headers.
> 
> For me, it is the right thing to do.

Please follow the advice of Alex for the radeon driver.

Sam


Re: [PATCH] drm/ingenic: ipu: Search for scaling coefs up to 102% of?? the screen

2020-11-10 Thread Sam Ravnborg
Hi Paul,
On Tue, Nov 10, 2020 at 08:50:22AM +, Paul Cercueil wrote:
> Hi,
> 
> Le sam. 7 nov. 2020 à 20:33, Sam Ravnborg  a écrit :
> > Hi Paul.
> > 
> > On Thu, Nov 05, 2020 at 08:39:05AM +, Paul Cercueil wrote:
> > >  Increase the scaled image's theorical width/height until we find a
> > >  configuration that has valid scaling coefficients, up to 102% of the
> > >  screen's resolution. This makes sure that we can scale from almost
> > >  every resolution possible at the cost of a very small distorsion.
> > >  The CRTC_W / CRTC_H are not modified.
> > > 
> > >  This algorithm was already in place but would not try to go above
> > > the
> > >  screen's resolution, and as a result would only work if the CRTC_W /
> > >  CRTC_H were smaller than the screen resolution. It will now try
> > > until it
> > >  reaches 102% of the screen's resolution.
> > > 
> > >  Signed-off-by: Paul Cercueil 
> > 
> > Looks like the patch does what the descriptions says.
> > So in other words - look OK to me. I am not confident enogh for a r-b
> > but my code reading is enough to warrant an a-b:
> > Acked-by: Sam Ravnborg 
> 
> Note that this algorithm exists mostly as a band-aid for a missing
> functionality: it is not possible for userspace to request the closest mode
> that would encapsulate the provided one, because the GEM buffer is created
> beforehand. If there was a way to let the kernel tweak the mode, I could
> write a better algorithm that would result in a better looking picture.

Could you add this nice explanation to the changelog so when we wonder
why this was done in some years we can dig up this from git history.

Sam


Re: [PATCH 17/19] drm/radeon/radeon_kms: Fix misnaming of 'radeon_info_ioctl's dev param

2020-11-09 Thread Sam Ravnborg
On Mon, Nov 09, 2020 at 08:10:13PM +, Lee Jones wrote:
> On Mon, 09 Nov 2020, Sam Ravnborg wrote:
> 
> > Hi Alex,
> > On Mon, Nov 09, 2020 at 02:50:35PM -0500, Alex Deucher wrote:
> > > On Fri, Nov 6, 2020 at 4:50 PM Lee Jones  wrote:
> > > >
> > > > Fixes the following W=1 kernel build warning(s):
> > > >
> > > >  drivers/gpu/drm/radeon/radeon_kms.c:226: warning: Function parameter 
> > > > or member 'dev' not described in 'radeon_info_ioctl'
> > > >  drivers/gpu/drm/radeon/radeon_kms.c:226: warning: Excess function 
> > > > parameter 'rdev' description in 'radeon_info_ioctl'
> > > >
> > > > Cc: Alex Deucher 
> > > > Cc: "Christian König" 
> > > > Cc: David Airlie 
> > > > Cc: Daniel Vetter 
> > > > Cc: amd-...@lists.freedesktop.org
> > > > Cc: dri-de...@lists.freedesktop.org
> > > > Signed-off-by: Lee Jones 
> > > > ---
> > > >  drivers/gpu/drm/radeon/radeon_kms.c | 2 +-
> > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/radeon/radeon_kms.c 
> > > > b/drivers/gpu/drm/radeon/radeon_kms.c
> > > > index 0d8fbabffcead..21c206795c364 100644
> > > > --- a/drivers/gpu/drm/radeon/radeon_kms.c
> > > > +++ b/drivers/gpu/drm/radeon/radeon_kms.c
> > > > @@ -213,7 +213,7 @@ static void radeon_set_filp_rights(struct 
> > > > drm_device *dev,
> > > >  /**
> > > >   * radeon_info_ioctl - answer a device specific request.
> > > >   *
> > > > - * @rdev: radeon device pointer
> > > > + * @dev: radeon device pointer
> > > 
> > > This should be:
> > > + * @dev: drm device pointer
> > 
> > good spot. I am continuing the work on radeon and will post a patchset
> > that contains only radeon fixes with Lee's patches and a few more by me.
> > I will fix the above.
> 
> What do you mean by "continuing on"?
> 
> How will you prevent your work from conflicting with my current effort?

Quoting from previous mail in this thread:

  "
  > > How would you like me to move forward?
  >
  > Fix the thousand of warnings in other places :-)
  > I will take a look at radeon and post a new series based on your work
  > with all W=1 warnings fixed.

  I'll drop this patch and carry on ploughing through the rest of them.
"

Here I promised you to fix all warnings in the radeon driver.
And despite this being more work than anticipated a promise is a
promise. So therefore I started working on this.

If you want to do the rest of the radeon driver you are welcome and I
will gladly drop this again. Just let me know your preference.

Sam


Re: [PATCH 17/19] drm/radeon/radeon_kms: Fix misnaming of 'radeon_info_ioctl's dev param

2020-11-09 Thread Sam Ravnborg
Hi Alex,
On Mon, Nov 09, 2020 at 02:50:35PM -0500, Alex Deucher wrote:
> On Fri, Nov 6, 2020 at 4:50 PM Lee Jones  wrote:
> >
> > Fixes the following W=1 kernel build warning(s):
> >
> >  drivers/gpu/drm/radeon/radeon_kms.c:226: warning: Function parameter or 
> > member 'dev' not described in 'radeon_info_ioctl'
> >  drivers/gpu/drm/radeon/radeon_kms.c:226: warning: Excess function 
> > parameter 'rdev' description in 'radeon_info_ioctl'
> >
> > Cc: Alex Deucher 
> > Cc: "Christian König" 
> > Cc: David Airlie 
> > Cc: Daniel Vetter 
> > Cc: amd-...@lists.freedesktop.org
> > Cc: dri-de...@lists.freedesktop.org
> > Signed-off-by: Lee Jones 
> > ---
> >  drivers/gpu/drm/radeon/radeon_kms.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/radeon/radeon_kms.c 
> > b/drivers/gpu/drm/radeon/radeon_kms.c
> > index 0d8fbabffcead..21c206795c364 100644
> > --- a/drivers/gpu/drm/radeon/radeon_kms.c
> > +++ b/drivers/gpu/drm/radeon/radeon_kms.c
> > @@ -213,7 +213,7 @@ static void radeon_set_filp_rights(struct drm_device 
> > *dev,
> >  /**
> >   * radeon_info_ioctl - answer a device specific request.
> >   *
> > - * @rdev: radeon device pointer
> > + * @dev: radeon device pointer
> 
> This should be:
> + * @dev: drm device pointer

good spot. I am continuing the work on radeon and will post a patchset
that contains only radeon fixes with Lee's patches and a few more by me.
I will fix the above.

Sam


Re: [PATCH 10/19] drm/radeon/radeon: Move prototype into shared header

2020-11-09 Thread Sam Ravnborg
Hi Lee,
> > 
> > Other public functions in radeon_device.c have their prototype in
> > radeon.h - for example radeon_is_px()
> > 
> > Add radeon_device_is_virtual() there so we avoiid this new header.
> 
> Oh yes, I remember why this wasn't a suitable solution now:
> 
> The macro "radeon_init" in radeon.h clashes with the init function of
> the same name in radeon_drv.c:
> 
>   In file included from drivers/gpu/drm/radeon/radeon_drv.c:53:
>   drivers/gpu/drm/radeon/radeon_drv.c:620:31: error: expected identifier or 
> ‘(’ before ‘void’
>   620 | static int __init radeon_init(void)
...
> 
> How would you like me to move forward?

Fix the thousand of warnings in other places :-)
I will take a look at radeon and post a new series based on your work
with all W=1 warnings fixed.

Sam


Re: [PATCH] drm/msm: dsi: Constify dsi_host_ops

2020-11-08 Thread Sam Ravnborg
On Sun, Nov 08, 2020 at 11:37:38PM +0100, Rikard Falkeborn wrote:
> The only usage of dsi_host_ops is to assign its address to the ops field
> in the mipi_dsi_host struct, which is a const pointer. Make it const to
> allow the compiler to put it in read-only memory.
> 
> Signed-off-by: Rikard Falkeborn 
Reviewed-by: Sam Ravnborg 

With this patch all struct mipi_dsi_host_ops are const - good.
I expect the msm folks to pick it up.

Sam


Re: [PATCH] video: fbdev: riva: remove some unused varibles

2020-11-08 Thread Sam Ravnborg
Hi Alex,

On Sun, Nov 08, 2020 at 04:01:59PM +0800, Alex Shi wrote:
> Couple of variables are actually useless, remove them to save some gcc
> warning:
> drivers/video/fbdev/riva/riva_hw.c:250:21: warning: variable ‘mlwm’ set
> but not used [-Wunused-but-set-variable]
> drivers/video/fbdev/riva/riva_hw.c:665:15: warning: variable ‘vraw’ set
> but not used [-Wunused-but-set-variable]
> drivers/video/fbdev/riva/riva_hw.c:665:9: warning: variable ‘craw’ set
> but not used [-Wunused-but-set-variable]
> drivers/video/fbdev/riva/riva_hw.c:659:73: warning: variable ‘align’ set
> but not used [-Wunused-but-set-variable]
> drivers/video/fbdev/riva/riva_hw.c:659:50: warning: variable
> ‘color_key_enable’ set but not used [-Wunused-but-set-variable]
> 
> Signed-off-by: Alex Shi 
> Cc: Antonino Daplas  
> Cc: linux-fb...@vger.kernel.org 
> Cc: dri-de...@lists.freedesktop.org 
> Cc: linux-kernel@vger.kernel.org 

Thanks, applied to drm-misc-next. The fix will appear in -next in a week
or so.

Sam


Re: [PATCH v1] video: hyperv_fb: include vmalloc.h

2020-11-08 Thread Sam Ravnborg
Hi Olaf.

On Fri, Nov 06, 2020 at 07:39:41PM +0100, Olaf Hering wrote:
> hvfb_getmem uses vzalloc, therefore vmalloc.h should be included.
> 
> Fixes commit d21987d709e807ba7bbf47044deb56a3c02e8be4 ("video: hyperv:
> hyperv_fb: Support deferred IO for Hyper-V frame buffer driver")
> 
> Signed-off-by: Olaf Hering 

Thanks.
Applied to drm-misc-fixes - as it smells like a build fix in some
configurations.

Sam


Re: [PATCH] drm/panel: simple: Add flags to boe_nv133fhm_n61

2020-11-08 Thread Sam Ravnborg
Hi Stephen
On Fri, Nov 06, 2020 at 10:23:33AM -0800, Stephen Boyd wrote:
> Reading the EDID of this panel shows that these flags should be set. Set
> them so that we match what is in the EDID.
> 
> Cc: Douglas Anderson 
> Cc: Bjorn Andersson 
> Fixes: b0c664cc80e8 ("panel: simple: Add BOE NV133FHM-N61")
> Signed-off-by: Stephen Boyd 

Applied to drm-misc-next as I could not see this was needed in mainline.
Or at least not urgently.
Let me know if this should be expeditet to current -rc

Sam


Re: [PATCH] drm: remove unneeded break

2020-11-08 Thread Sam Ravnborg
Hi Tom
On Mon, Oct 19, 2020 at 07:06:41PM +0200, Sam Ravnborg wrote:
> Hi Tom
> On Mon, Oct 19, 2020 at 09:31:15AM -0700, t...@redhat.com wrote:
> > From: Tom Rix 
> > 
> > A break is not needed if it is preceded by a return or break
> > 
> > Signed-off-by: Tom Rix 
> 
> Looks good and builds with no warnings.
> 
> One of the diffs made me - "oh this looks wrong". But after I looked again
> it was right and the resulting code is more readable - so good.
> 
> Acked-by: Sam Ravnborg 
> 
> Was tempted to just apply to drm-misc-next but will give others the
> opportunity to chime in.

Thanks.
Now applied to drm-misc-next - will show up in -next in a week or so.

Sam


Re: [PATCH v3 2/3] drm/bridge: sii902x: Enable I/O and core VCC supplies if present

2020-11-08 Thread Sam Ravnborg
Hi Alexandru

On Tue, Oct 20, 2020 at 05:14:58PM -0500, Alexandru Gagniuc wrote:
> On the SII9022, the IOVCC and CVCC12 supplies must reach the correct
> voltage before the reset sequence is initiated. On most boards, this
> assumption is true at boot-up, so initialization succeeds.
> 
> However, when we try to initialize the chip with incorrect supply
> voltages, it will not respond to I2C requests. sii902x_probe() fails
> with -ENXIO.
> 
> To resolve this, look for the "iovcc" and "cvcc12" regulators, and
> make sure they are enabled before starting the reset sequence. If
> these supplies are not available in devicetree, then they will default
> to dummy-regulator. In that case everything will work like before.
> 
> This was observed on a STM32MP157C-DK2 booting in u-boot falcon mode.
> On this board, the supplies would be set by the second stage
> bootloader, which does not run in falcon mode.
> 
> Signed-off-by: Alexandru Gagniuc 

Thanks, applied series to drm-misc-next. I fixed two
checkpatch --strict warnings while applying.

Sam


Re: [PATCH] drm: bridge: dw-hdmi: Avoid resetting force in the detect function

2020-11-08 Thread Sam Ravnborg
Hi Russell,

On Sun, Nov 08, 2020 at 09:57:25AM +, Russell King - ARM Linux admin wrote:
> On Sun, Nov 08, 2020 at 10:53:22AM +0100, Sam Ravnborg wrote:
> > Russell,
> > 
> > On Sat, Oct 31, 2020 at 07:17:47PM +1100, Jonathan Liu wrote:
> > > It has been observed that resetting force in the detect function can
> > > result in the PHY being powered down in response to hot-plug detect
> > > being asserted, even when the HDMI connector is forced on.
> > > 
> > > Enabling debug messages and adding a call to dump_stack() in
> > > dw_hdmi_phy_power_off() shows the following in dmesg:
> > > [  160.637413] dwhdmi-rockchip ff94.hdmi: EVENT=plugin
> > > [  160.637433] dwhdmi-rockchip ff94.hdmi: PHY powered down in 0 
> > > iterations
> > > 
> > > Call trace:
> > > dw_hdmi_phy_power_off
> > > dw_hdmi_phy_disable
> > > dw_hdmi_update_power
> > > dw_hdmi_detect
> > > dw_hdmi_connector_detect
> > > drm_helper_probe_detect_ctx
> > > drm_helper_hpd_irq_event
> > > dw_hdmi_irq
> > > irq_thread_fn
> > > irq_thread
> > > kthread
> > > ret_from_fork
> > > 
> > > Fixes: 381f05a7a842 ("drm: bridge/dw_hdmi: add connector mode forcing")
> > > Signed-off-by: Jonathan Liu 
> > 
> > you are the original author of this code - any comments on this patch?
> 
> No further comments beyond what has already been discussed, and the
> long and short of it is it's been so long that I don't remember why
> that code was there. Given that, I'm not even in a position to ack
> the change. Sorry.
Thanks for the quick reply.

Given that this fixes a problem for Jonathan I will apply this to -fixes
if there is no other feedback the next couple of days.
If it introduces regression we can take it from there.

Jonathan - please ping me if I forget.

Sam


Re: [PATCH RESEND v2] drm/bridge/tc358775: Fixes bus formats read

2020-11-08 Thread Sam Ravnborg
Hi Laurent,

On Thu, Oct 22, 2020 at 12:15:47PM +0530, Vinay Simha BN wrote:
> - atomic_check removed
> - video data input and output formats added
> - bus formats read from drm_bridge_state.output_bus_cfg.format
>   and .atomic_get_input_bus_fmts() instead of connector
> 
> Signed-off-by: Vinay Simha BN 

could you try to find time to review this patch?

You already provided valuable feedback and it looks fine to me.
But it would be perfect if you could find time to take a look.

Thanks in advance,

Sam

> 
> ---
> v1:
>  * Laurent Pinchart review comments incorporated
>drm_bridge_state.output_bus_cfg.format
>instead of connector
> v2:
>  * Laurent Pinchart review comments incorporated
>atomic_check removed
>video data input and output formats added
> ---
>  drivers/gpu/drm/bridge/tc358775.c | 75 
> ++-
>  1 file changed, 58 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/tc358775.c 
> b/drivers/gpu/drm/bridge/tc358775.c
> index 2272adc..cc27570 100644
> --- a/drivers/gpu/drm/bridge/tc358775.c
> +++ b/drivers/gpu/drm/bridge/tc358775.c
> @@ -271,6 +271,20 @@ struct tc_data {
>   struct gpio_desc*stby_gpio;
>   u8  lvds_link; /* single-link or dual-link */
>   u8  bpc;
> + u32 output_bus_fmt;
> +};
> +
> +static const u32 tc_lvds_in_bus_fmts[] = {
> + MEDIA_BUS_FMT_RGB565_1X16,
> + MEDIA_BUS_FMT_RGB666_1X18,
> + MEDIA_BUS_FMT_RGB666_1X24_CPADHI,
> + MEDIA_BUS_FMT_RBG888_1X24,
> +};
> +
> +static const u32 tc_lvds_out_bus_fmts[] = {
> + MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA,
> + MEDIA_BUS_FMT_RGB888_1X7X4_SPWG,
> + MEDIA_BUS_FMT_RGB666_1X7X3_SPWG,
>  };
>  
>  static inline struct tc_data *bridge_to_tc(struct drm_bridge *b)
> @@ -359,19 +373,6 @@ static void d2l_write(struct i2c_client *i2c, u16 addr, 
> u32 val)
>   ret, addr);
>  }
>  
> -/* helper function to access bus_formats */
> -static struct drm_connector *get_connector(struct drm_encoder *encoder)
> -{
> - struct drm_device *dev = encoder->dev;
> - struct drm_connector *connector;
> -
> - list_for_each_entry(connector, >mode_config.connector_list, head)
> - if (connector->encoder == encoder)
> - return connector;
> -
> - return NULL;
> -}
> -
>  static void tc_bridge_enable(struct drm_bridge *bridge)
>  {
>   struct tc_data *tc = bridge_to_tc(bridge);
> @@ -380,7 +381,10 @@ static void tc_bridge_enable(struct drm_bridge *bridge)
>   u32 val = 0;
>   u16 dsiclk, clkdiv, byteclk, t1, t2, t3, vsdelay;
>   struct drm_display_mode *mode;
> - struct drm_connector *connector = get_connector(bridge->encoder);
> + struct drm_bridge_state *state =
> + drm_priv_to_bridge_state(bridge->base.state);
> +
> + tc->output_bus_fmt = state->output_bus_cfg.format;
>  
>   mode = >encoder->crtc->state->adjusted_mode;
>  
> @@ -451,14 +455,13 @@ static void tc_bridge_enable(struct drm_bridge *bridge)
>   d2l_write(tc->i2c, LVPHY0, LV_PHY0_PRBS_ON(4) | LV_PHY0_ND(6));
>  
>   dev_dbg(tc->dev, "bus_formats %04x bpc %d\n",
> - connector->display_info.bus_formats[0],
> + tc->output_bus_fmt,
>   tc->bpc);
>   /*
>* Default hardware register settings of tc358775 configured
>* with MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA jeida-24 format
>*/
> - if (connector->display_info.bus_formats[0] ==
> - MEDIA_BUS_FMT_RGB888_1X7X4_SPWG) {
> + if (tc->output_bus_fmt == MEDIA_BUS_FMT_RGB888_1X7X4_SPWG) {
>   /* VESA-24 */
>   d2l_write(tc->i2c, LV_MX0003, LV_MX(LVI_R0, LVI_R1, LVI_R2, 
> LVI_R3));
>   d2l_write(tc->i2c, LV_MX0407, LV_MX(LVI_R4, LVI_R7, LVI_R5, 
> LVI_G0));
> @@ -590,6 +593,40 @@ static int tc358775_parse_dt(struct device_node *np, 
> struct tc_data *tc)
>   return 0;
>  }
>  
> +static u32 *
> +tc_bridge_get_input_bus_fmts(struct drm_bridge *bridge,
> +  struct drm_bridge_state *bridge_state,
> +  struct drm_crtc_state *crtc_state,
> +  struct drm_connector_state *conn_state,
> +  u32 output_fmt,
> +  unsigned int *num_input_fmts)
> +{
> + u32 *input_fmts = NULL;
> + u8 i;
> +
> + *num_input_fmts = 0;
> +
> + for (i = 0 ; i < ARRAY_SIZE(tc_lvds_out_bus_fmts) ; ++i) {
> + if (output_fmt == tc_lvds_out_bus_fmts[i])
> + break;
> + }
> +
> + if (i == ARRAY_SIZE(tc_lvds_out_bus_fmts))
> + return NULL;
> +
> + *num_input_fmts = ARRAY_SIZE(tc_lvds_in_bus_fmts);
> +
> + input_fmts = kcalloc(*num_input_fmts, ARRAY_SIZE(tc_lvds_in_bus_fmts),
> +  GFP_KERNEL);
> + if (!input_fmts)
> + return NULL;
> +
> + for (i = 0; i 

Re: [PATCH] drm: xlnx: Use dma_request_chan for DMA channel request

2020-11-08 Thread Sam Ravnborg
Hi Peter.

On Fri, Oct 23, 2020 at 12:46:02PM +0300, Peter Ujfalusi wrote:
> There is no need to use the of_dma_request_slave_channel() directly as
> dma_request_chan() is going to try to get the channel via OF as well.
> 
> Signed-off-by: Peter Ujfalusi 

I took a look at this and agree on your analysis.
Reviewed-by: Sam Ravnborg 

I expect the maintainers to pick up this patch.

Sam

> ---
>  drivers/gpu/drm/xlnx/zynqmp_disp.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/xlnx/zynqmp_disp.c 
> b/drivers/gpu/drm/xlnx/zynqmp_disp.c
> index 98bd48f13fd1..a4405d081aca 100644
> --- a/drivers/gpu/drm/xlnx/zynqmp_disp.c
> +++ b/drivers/gpu/drm/xlnx/zynqmp_disp.c
> @@ -28,7 +28,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> @@ -1316,8 +1315,7 @@ static int zynqmp_disp_layer_request_dma(struct 
> zynqmp_disp *disp,
>  
>   snprintf(dma_channel_name, sizeof(dma_channel_name),
>"%s%u", dma_names[layer->id], i);
> - dma->chan = of_dma_request_slave_channel(disp->dev->of_node,
> -  dma_channel_name);
> + dma->chan = dma_request_chan(disp->dev, dma_channel_name);
>   if (IS_ERR(dma->chan)) {
>   dev_err(disp->dev, "failed to request dma channel\n");
>   ret = PTR_ERR(dma->chan);
> -- 
> Peter
> 
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
> 
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH] drm: bridge: cdns: Kconfig: Switch over dependency to ARCH_K3

2020-11-08 Thread Sam Ravnborg
Hi Nishanth

On Mon, Oct 26, 2020 at 11:54:41AM -0500, Nishanth Menon wrote:
> With the integration of chip-id detection scheme in kernel[1], there
> is no specific need to maintain multitudes of SoC specific config
> options, discussed as per [2], we have deprecated the usage in other
> places for v5.10-rc1. Fix the missing user so that we can clean up the
> configs in v5.11.
> 
> [1] drivers/soc/ti/k3-socinfo.c commit 907a2b7e2fc7 ("soc: ti: add k3 
> platforms chipid module driver")
> [2] 
> https://lore.kernel.org/linux-arm-kernel/20200908112534.t5bgrjf7y3a6l2ss@akan/
> 
> Fixes: afba7e6c5fc1 ("rm: bridge: cdns-mhdp8546: Add TI J721E wrapper")
> Cc: Swapnil Jakhade 
> Cc: Tomi Valkeinen 
> Cc: Laurent Pinchart 
> Cc: Yuti Amonkar 
> Cc: Jyri Sarha 
> Signed-off-by: Nishanth Menon 

Applied to drm-misc-fixes with Tomi's r-b
Fixed the "Fixes" line while applying - someone ate a 'd'

Sam

> ---
>  drivers/gpu/drm/bridge/cadence/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/bridge/cadence/Kconfig 
> b/drivers/gpu/drm/bridge/cadence/Kconfig
> index 511d67b16d14..ef8c230e0f62 100644
> --- a/drivers/gpu/drm/bridge/cadence/Kconfig
> +++ b/drivers/gpu/drm/bridge/cadence/Kconfig
> @@ -13,7 +13,7 @@ config DRM_CDNS_MHDP8546
>  if DRM_CDNS_MHDP8546
>  
>  config DRM_CDNS_MHDP8546_J721E
> - depends on ARCH_K3_J721E_SOC || COMPILE_TEST
> + depends on ARCH_K3 || COMPILE_TEST
>   bool "J721E Cadence DPI/DP wrapper support"
>   default y
>   help
> -- 
> 2.28.0
> 
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH] drm: panel: simple: add missing platform_driver_unregister() in panel_simple_init

2020-11-08 Thread Sam Ravnborg
Hi Qinglang

On Sat, Oct 31, 2020 at 09:18:56AM +0800, Qinglang Miao wrote:
> Add the missing platform_driver_unregister() before return
> from panel_simple_init in the error handling case when failed
> to register panel_simple_dsi_driver with CONFIG_DRM_MIPI_DSI
> enabled.
> 
> Signed-off-by: Qinglang Miao 

Looks relevant, applied to drm-misc-next.

Sam


  1   2   3   4   5   6   7   8   9   10   >