, 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
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
ff-by: Maxime Ripard
Acked-by: Sam Ravnborg
I assume you will push this patch as part of the series.
Sam
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
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'
; 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
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 737c1
a-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 737
@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
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
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:
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"
> >
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
---
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: And
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 Zi
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 Be
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 B
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
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/spa
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: Arn
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.
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
---
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: Andre
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/kern
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:
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/
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 ker
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 conn
quot;
> 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
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 a
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 dr
gt; > ; 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
> >
> >
Hi Paul
> > > >> >> +
> > > >> >> +maintainers:
> > > >> >> + - Paul Cercueil
> > > >> >> +
> > > >> >> +allOf:
> > > >> >> + - $ref: panel-common.yaml#
> > > >> >> +
> > > >> >> +properties:
> > > >> >> + compatible:
> > > >> >> +const: abt,y030xx067a
> > >
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.
>
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/bi
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(-)
le.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: S
n
> 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
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: Thier
pi_dsi_attach() failes then da a drm_panel_remove() like this:
ret = mipi_dsi_attach(dsi);
if (ret)
drm_panel_remove(&khadas_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
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
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
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
> ---
>
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
> Sig
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 sou
nfig / 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/
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
> allo
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 t
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 a
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
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
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
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
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
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
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.
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 c
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
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");
>
> Sig
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
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
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=g1mGry1fE5kvFFFrxzhPSM6q
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/
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/
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
>
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 nowada
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:
> > >
> > > &g
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):
> > >
> > &g
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 o
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 alphabetica
pu/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.fre
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
> C
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 ele
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 element
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 mes
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-varia
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-se
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 colors
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
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: Alexand
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
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:
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
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
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.
Pl
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'
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:
> > > >
>
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 'rad
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 r
-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
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/riv
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-b
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-
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
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, w
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 observ
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 Si
gree 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/driv
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
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: Qing
1 - 100 of 2319 matches
Mail list logo
