From: Arnd Bergmann
get_clk_frequency_khz() is not a proper name for a global function,
and there is only one caller.
Convert viper to use the properly namespaced
pxa25x_get_clk_frequency_khz() and remove the other references.
Acked-by: Viresh Kumar
Acked-by: Robert Jarzmik
Cc: linux
From: Arnd Bergmann
Rather than poking at the smemc registers directly from the
pcmcia/pxa2xx_base driver, move those bits into machine file
to have a cleaner interface.
Cc: Dominik Brodowski
Link: https://lore.kernel.org/lkml/87d0egjzxk@belgarion.home/
Signed-off-by: Arnd Bergmann
From: Arnd Bergmann
To avoid dereferencing hardwired constant pointers from a global header
file, change the driver to use devm_platform_ioremap_resource for getting
an __iomem pointer, and then using readl/writel on that.
Each pointer dereference gets changed by a search, which leads
to a few
From: Arnd Bergmann
To avoid dereferencing hardwired constant pointers from a global header
file, change the driver to use devm_platform_ioremap_resource for getting
an __iomem pointer, and then using readl/writel on that.
Each pointer dereference gets changed by a search, which leads
to a few
From: Arnd Bergmann
The driver currently takes the hardwired FIFO address from
a header file that we want to eliminate. Change it to use
the mmio resource instead and stop including the here.
Acked-by: Mark Brown
Cc: alsa-de...@alsa-project.org
Acked-by: Robert Jarzmik
Signed-off-by: Arnd
From: Dmitry Torokhov
Now that we are using oneshot threaded IRQ this method is not used anymore.
Signed-off-by: Dmitry Torokhov
[arnd: add the db1300 change as well]
Cc: Manuel Lauss
Signed-off-by: Arnd Bergmann
---
arch/mips/alchemy/devboards/db1300.c | 9 -
drivers/input
From: Dmitry Torokhov
Instead of manually disabling and enabling interrupts and scheduling work
to access the device, let's use threaded oneshot interrupt handler. It
simplifies things.
Signed-off-by: Dmitry Torokhov
Signed-off-by: Arnd Bergmann
---
drivers/input/touchscreen/wm97xx-core.c
From: Arnd Bergmann
To avoid a dependency on the pxa platform header files with
hardcoded registers, change the driver to call a wrapper
in the pxa2xx-ac97-lib that encapsulates all the other
ac97 stuff.
Acked-by: Dmitry Torokhov
Acked-by: Robert Jarzmik
Cc: linux-in...@vger.kernel.org
Cc
From: Arnd Bergmann
The two drivers are almost identical and can work on a variety
of hardware in principle. The mainstone driver supports additional
hardware, and the zylonite driver has a few cleanup patches.
Sync the two by adding the zylonite changes into the mainstone
one, and checking
From: Arnd Bergmann
There are two different ways of flushing the ac97 queue
in this driver, selected by a compile time option.
Change this to a runtime selection to make it work when both
are enabled.
Acked-by: Dmitry Torokhov
Acked-by: Robert Jarzmik
Cc: linux-in...@vger.kernel.org
Signed
From: Arnd Bergmann
The mach/mfp.h header is only used by this one driver
for hardcoded gpio numbers. Change that to use a lookup
table instead.
Cc: Dmitry Torokhov
Cc: linux-in...@vger.kernel.org
Acked-by: Robert Jarzmik
Acked-by: Linus Walleij
Signed-off-by: Arnd Bergmann
---
arch/arm
From: Arnd Bergmann
This driver hardcodes gpio numbers without a header file.
Use lookup tables instead.
Cc: Marek Vasut
Acked-by: Dmitry Torokhov
Acked-by: Robert Jarzmik
Reviewed-by: Linus Walleij
Cc: linux-in...@vger.kernel.org
Signed-off-by: Arnd Bergmann
---
arch/arm/mach-pxa
From: Arnd Bergmann
The magician audio driver creates a codec device and gets
data from a board specific header file, both of which is
a bit suspicious. Move these into the board file itself,
using a gpio lookup table.
Acked-by: Mark Brown
Acked-by: Robert Jarzmik
Cc: alsa-de...@alsa
From: Arnd Bergmann
The audio device is allocated by the audio driver, and it uses a gpio
number from the mach/z2.h header file.
Change it to use a gpio lookup table for the device allocated by the
driver to keep the header file local to the machine.
Acked-by: Mark Brown
Cc: alsa-de...@alsa
From: Arnd Bergmann
The three eseries machines have very similar drivers for audio, all
using the mach/eseries-gpio.h header for finding the gpio numbers.
Change these to use gpio descriptors to avoid the header file
dependency.
I convert the _OFF gpio numbers into GPIO_ACTIVE_LOW ones
From: Arnd Bergmann
The audio driver should not use a hardwired gpio number
from the header. Change it to use a lookup table.
Acked-by: Mark Brown
Cc: alsa-de...@alsa-project.org
Signed-off-by: Arnd Bergmann
---
arch/arm/mach-pxa/spitz.c| 33 ++-
arch/arm/mach-pxa
From: Arnd Bergmann
Lubbock is the only machine that has three IRQs for the UDC.
These are currently hardcoded in the driver based on a
machine header file.
Change this to use platform device resources as we use for
the generic IRQ anyway.
Cc: Felipe Balbi
Cc: Greg Kroah-Hartman
Cc: linux
From: Arnd Bergmann
The audio driver should not use a hardwired gpio number
from the header. Change it to use a lookup table.
Cc: Philipp Zabel
Cc: Paul Parsons
Acked-by: Mark Brown
Acked-by: Robert Jarzmik
Cc: alsa-de...@alsa-project.org
Signed-off-by: Arnd Bergmann
---
arch/arm/mach-pxa
From: Arnd Bergmann
The audio driver should not use a hardwired gpio number
from the header. Change it to use a lookup table.
Acked-by: Mark Brown
Cc: alsa-de...@alsa-project.org
Acked-by: Robert Jarzmik
Signed-off-by: Arnd Bergmann
---
arch/arm/mach-pxa/corgi.c| 22
From: Arnd Bergmann
The poodle audio driver shows its age by using a custom
gpio api for the "locomo" support chip.
In a perfect world, this would get converted to use gpiolib
and a gpio lookup table.
As the world is not perfect, just pass all the required data
in a custom pla
From: Arnd Bergmann
The audio driver should not use a hardwired gpio number
from the header. Change it to use a lookup table.
Acked-by: Mark Brown
Acked-by: Robert Jarzmik
Cc: alsa-de...@alsa-project.org
Signed-off-by: Arnd Bergmann
---
arch/arm/mach-pxa/tosa.c | 12
sound/soc
From: Arnd Bergmann
>From inspection I found a couple of GPIO lookups that are
listed with device "gpio-pxa", but actually have a number
from a different gpio controller.
Try to rectify that here, with a guess of what the actual
device name is.
Acked-by: Robert Jarzmik
Revie
From: Arnd Bergmann
The palmld header is almost unused in drivers, the only
remaining thing now is the PATA device address, which should
really be passed as a resource.
Cc: Jens Axboe
Cc: linux-...@vger.kernel.org
Acked-by: Robert Jarzmik
Acked-by: Bartlomiej Zolnierkiewicz
Signed-off
From: Arnd Bergmann
Drivers should not rely on the contents of this file, so
move it into the platform directory directly.
Cc: Philipp Zabel
Cc: Paul Parsons
Signed-off-by: Arnd Bergmann
Link: https://lore.kernel.org/lkml/87mudkmx8g@belgarion.home/
---
arch/arm/mach-pxa/{include/mach
From: Arnd Bergmann
The drivers/pcmcia/pxa2xx_*.c are essentially part of the
board files, but for historic reasons located in drivers/pcmcia.
Move them into the same place as the actual board file to avoid
lots of machine header inclusions.
Cc: Marek Vasut
Cc: Dominik Brodowski
Cc: Jonathan
From: Arnd Bergmann
The pxa2xx-ac97-lib code is the last driver to use mach/irqs.h
for PXA. Almost everything already passes the interrupt as
a resource, so use it from there.
The one exception is the mxm8x10 machine, which apparently has
a resource-less device. Replacing it with the correct
From: Arnd Bergmann
Rather than relying on machine specific headers to
pass down the reboot status and the register locations,
use resources and platform_data.
Aside from this, keep the changes to a minimum.
Cc: Wim Van Sebroeck
Cc: Guenter Roeck
Cc: linux-watch...@vger.kernel.org
Signed-off
From: Arnd Bergmann
Only the pxafb driver uses this header, so move it into the
same directory. The SMART_* macros are required by some
platform data definitions and can go into the
linux/platform_data/video-pxafb.h header.
Acked-by: Bartlomiej Zolnierkiewicz
Acked-by: Robert Jarzmik
Cc: dri
From: Arnd Bergmann
This is a basically a platform_data file, so move it out of
the mach/* header directory.
Cc: Marek Vasut
Cc: Tomas Cech
Cc: Sergey Lapin
Acked-by: Mark Brown
Acked-by: Robert Jarzmik
Cc: alsa-de...@alsa-project.org
Signed-off-by: Arnd Bergmann
---
arch/arm/mach-pxa
From: Arnd Bergmann
There are two identical copies of mach/bitfield.h, one for
mach-sa1100 and one for mach-pxa. The pxafb driver only
makes use of two macros, which can be trivially open-coded
in the header.
Cc: dri-devel@lists.freedesktop.org
Acked-by: Bartlomiej Zolnierkiewicz
Acked
From: Arnd Bergmann
The mach/hardware.h is included in lots of places, and it provides
three different things on pxa:
- the cpu_is_pxa* macros
- an indirect inclusion of mach/addr-map.h
- the __REG() and io_pv2() helper macros
Split it up into separate and mach/pxa-regs.h
headers, then change
From: Arnd Bergmann
The file no longer contains anything useful, so remove it.
Acked-by: Robert Jarzmik
Signed-off-by: Arnd Bergmann
---
arch/arm/mach-pxa/include/mach/dma.h | 17 -
arch/arm/mach-pxa/pxa25x.c | 1 -
arch/arm/mach-pxa/pxa27x.c | 1 -
arch
From: Arnd Bergmann
This is not used by any drivers, so make it private to the
platform.
Acked-by: Robert Jarzmik
Signed-off-by: Arnd Bergmann
---
arch/arm/mach-pxa/{include/mach => }/regs-uart.h | 0
arch/arm/mach-pxa/viper.c| 2 +-
arch/arm/mach-pxa/zeu
From: Arnd Bergmann
No driver includes this any more, so don't expose it globally.
Acked-by: Robert Jarzmik
Signed-off-by: Arnd Bergmann
---
arch/arm/mach-pxa/mainstone.c| 2 +-
arch/arm/mach-pxa/{include/mach => }/mainstone.h | 2 --
2 files changed, 1 insertion(+)
From: Arnd Bergmann
Only one declaration from this header is actually used in drivers,
so move that one into the global location and leave everything else
private.
Acked-by: Robert Jarzmik
Signed-off-by: Arnd Bergmann
---
arch/arm/mach-pxa/generic.h | 6 +-
arch/arm/mach-pxa
From: Arnd Bergmann
This revisits a series I sent a few years ago:
https://lore.kernel.org/lkml/20191018154052.1276506-1-a...@arndb.de/
All the other ARMv5 conversions are under way now, with
OMAP1 being the only one still not in linux-next yet,
and PXA completing the set.
Most of the patches
From: Arnd Bergmann
With all the header files out of the way, and the clock driver
converted to the common framework, nothing stops us from building
OMAP together with the other platforms.
As usual, the decompressor support is a victim here, and is
only available when CONFIG_DEBUG_LL
support in favor of
that provided by CCF.
v2: flag tc2_ck as CLK_IS_CRITICAL (Aaro)
v3: rebase on top of soc/omap1-multiplatform-5.18,
- drop no longer needed includes from arch/arm/mach-omap1/io.c
Signed-off-by: Janusz Krzysztofik
Signed-off-by: Arnd Bergmann
---
arch/arm/mach-omap1/clock.c
implementation of clock API.
v2: use clk_prepare_enable/clk_disable_unprepare() (Peter)
Signed-off-by: Janusz Krzysztofik
Signed-off-by: Arnd Bergmann
---
sound/soc/ti/osk5912.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/sound/soc/ti/osk5912.c b/sound/soc/ti
implementation of clock API.
Signed-off-by: Janusz Krzysztofik
Signed-off-by: Arnd Bergmann
---
drivers/mmc/host/omap.c | 23 ++-
1 file changed, 14 insertions(+), 9 deletions(-)
diff --git a/drivers/mmc/host/omap.c b/drivers/mmc/host/omap.c
index 5e5af34090f1..57d39283924d
implementation of clock API.
Signed-off-by: Janusz Krzysztofik
Signed-off-by: Arnd Bergmann
---
drivers/video/fbdev/omap/hwa742.c | 6 +++---
drivers/video/fbdev/omap/lcdc.c | 6 +++---
drivers/video/fbdev/omap/sossi.c | 5 +++--
3 files changed, 9 insertions(+), 8 deletions(-)
diff --git a/drivers
implementation of clock API.
Signed-off-by: Janusz Krzysztofik
Acked-by: Alan Stern
Signed-off-by: Arnd Bergmann
---
drivers/usb/host/ohci-omap.c | 18 --
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/host/ohci-omap.c b/drivers/usb/host/ohci-omap.c
implementation of clock API.
Signed-off-by: Janusz Krzysztofik
Signed-off-by: Arnd Bergmann
---
drivers/usb/gadget/udc/omap_udc.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/gadget/udc/omap_udc.c
b/drivers/usb/gadget/udc/omap_udc.c
index
le_all() but
that op is not configured for any clock, then the function does nothing
and the op field is not needed,
- ENABLE_ON_INIT flag is set for some clocks but is never checked by any
code, then not needed.
Drop that code.
Signed-off-by: Janusz Krzysztofik
Signed-off-by: Arnd Be
: struct clk_functions,
- prototypes of functions with no implementation: clk_init(),
omap1_watchdog_recalc().
- declarations of never defined global variables: clkops_dummy.
Drop them.
Signed-off-by: Janusz Krzysztofik
Signed-off-by: Arnd Bergmann
---
arch/arm/mach-omap1/clock.c | 81
From: Janusz Krzysztofik
Since its introduction to the mainline kernel, omap1_uart_recalc() helper
makes incorrect use of clk->enable_bit as a ready to use bitmap mask while
it only provides the bit number. Fix it.
Signed-off-by: Janusz Krzysztofik
Signed-off-by: Arnd Bergmann
---
arch/
sure UART1 and UART3 are enabled early on
relevant OMAP1610 machine types while preserving bootloader UART clock
rates on others.
Signed-off-by: Janusz Krzysztofik
Signed-off-by: Arnd Bergmann
---
arch/arm/mach-omap1/clock_data.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
of clock API.
Signed-off-by: Janusz Krzysztofik
Signed-off-by: Arnd Bergmann
---
arch/arm/mach-omap1/mcbsp.c| 8
arch/arm/mach-omap1/ocpi.c | 4 ++--
arch/arm/mach-omap1/serial.c | 6 +++---
arch/arm/mach-omap1/timer32k.c | 2 +-
4 files changed, 10 insertions(+), 10 deletions
From: Arnd Bergmann
In a multiplatform randconfig kernel, one can have
CONFIG_ARCH_OMAP1 enabled, but none of the specific SoCs.
This leads to some build issues as the code is not
meant to deal with this configuration at the moment:
arch/arm/mach-omap1/io.c:86:20: error: unused function
From: Arnd Bergmann
Most of the header files are no longer referenced from outside
arch/arm/mach-omap1, so move them all to that place directly
and change their users to use the new location.
The exceptions are:
- mach/compress.h is used by the core architecture code
- mach/serial.h is used
From: Arnd Bergmann
The ISA I/O space handling in omap_cf is incompatible with
PCI drivers in a multiplatform kernel, and requires a custom
mach/io.h.
Change the driver to use pci_remap_iospace() like PCI drivers do,
so the generic ioport access can work across platforms.
To actually use
From: Arnd Bergmann
The address range 0xfee0-0xfeff is used for PCI and
PCMCIA I/O port mappings, but OMAP1 has its static mappings
there as well.
Move the OMAP1 addresses a little higher to avoid crashing
at boot.
Signed-off-by: Arnd Bergmann
---
arch/arm/Kconfig.debug
From: Arnd Bergmann
The last file in this directory is gone, and it can be removed as well.
Signed-off-by: Arnd Bergmann
---
arch/arm/Makefile | 1 -
arch/arm/plat-omap/Makefile | 9 -
2 files changed, 10 deletions(-)
delete mode 100644 arch/arm/plat-omap/Makefile
diff
From: Arnd Bergmann
The sram initialization code is the only shared omap1/2 code that
is not a standalone driver, but it is very short. Having two copies
of this code means some duplication of the sources, but actually
saves object code size as it can be inlined better.
Signed-off-by: Arnd
From: Arnd Bergmann
All the remaining features in here are either omap1
or omap2plus specific, so move them into the respective
Kconfig files.
Signed-off-by: Arnd Bergmann
---
arch/arm/Kconfig| 2 -
arch/arm/mach-omap1/Kconfig | 37 +++
arch/arm/mach-omap2/Kconfig
From: Arnd Bergmann
Most of the interface functions in plat/dma.c are only used from the
USB driver, which is practically OMAP1 specific, except for compile
testing.
The omap_get_plat_info(), omap_request_dma() and omap_free_dma()
functions are never called on omap2 because of runtime checks
From: Arnd Bergmann
No part of plat-omap/dma.c is called on omap2 any more, so
anything omap2 specific in here can simply be removed.
Signed-off-by: Arnd Bergmann
---
arch/arm/plat-omap/dma.c | 217 ++-
1 file changed, 55 insertions(+), 162 deletions
From: Arnd Bergmann
The legacy interface for omap-dma is only used on OMAP1, and the
same is true for the non-DT case. Make both of these conditional on
CONFIG_ARCH_OMAP1 being set to simplify the dependency.
The non-OMAP stub functions in include/linux/omap-dma.h are note needed
any more
From: Arnd Bergmann
Most of the plat-omap/dma.c code is specific to the USB
driver. Hide that code when it is not in use, to make it
clearer which parts are actually still required.
Signed-off-by: Arnd Bergmann
---
arch/arm/plat-omap/dma.c | 45
From: Arnd Bergmann
It has been impossible to select this driver for six years
without anyone noticing, so just kill it completely.
Fixes: 54ea18e8866a ("ARM: OMAP2+: Remove board file for H4")
Signed-off-by: Arnd Bergmann
---
arch/arm/plat-omap/Kconfig | 10 --
arch/arm
From: Arnd Bergmann
omap2 stopped using this code with commit 8d39ff3d1696 ("ARM: OMAP2+:
Remove unused legacy code for timer"), so just move it to mach-omap1 now,
along with the other half of that driver.
Signed-off-by: Arnd Bergmann
---
arch/arm/mach-omap1/Kconfig
From: Arnd Bergmann
The innovator board needs a special case for its phy control.
Move the corresponding code into the board file and out of the
common code by adding another callback.
Acked-by: Felipe Balbi
Signed-off-by: Arnd Bergmann
---
arch/arm/mach-omap1/board-innovator.c | 19
From: Arnd Bergmann
The omap-keypad driver currently relies on including mach/memory.h
implicitly, but that won't happen once omap1 is converted to
CONFIG_ARCH_MULTIPLATFORM. Include the required header
explicitly.
Signed-off-by: Arnd Bergmann
---
drivers/input/keyboard/omap-keypad.c | 1 +
1
From: Arnd Bergmann
As a preparation for cleaning up the omap1 headers, start
including linux/soc/ti/omap1-soc.h directly so we can
keep calling cpu_is_omap1510().
Signed-off-by: Arnd Bergmann
---
drivers/tty/serial/8250/8250.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/tty
From: Arnd Bergmann
As a preparation for future omap1 multiplatform support, stop
using mach/hardware.h and instead include the omap1-io.h
for low-level register access to MOD_CONF_CTRL_1.
Acked-by: Daniel Lezcano
Signed-off-by: Arnd Bergmann
---
drivers/clocksource/timer-ti-dm.c | 2 +-
1
From: Arnd Bergmann
The omap usb drivers still rely on mach/*.h headers that
are explicitly or implicitly included, but all the required
definitions are now in include/linux/soc/ti/, so use those
instead and allow compile-testing on other architectures.
Acked-by: Greg Kroah-Hartman
Acked
From: Arnd Bergmann
All the headers we actually need are now in include/linux/soc,
so use those versions instead and allow compile-testing on
other architectures.
Acked-by: Bartlomiej Zolnierkiewicz
Signed-off-by: Arnd Bergmann
---
drivers/video/backlight/Kconfig | 4 ++--
drivers
From: Arnd Bergmann
There is only one board that uses the omap_cf driver, so
moving the chipselect configuration there does not lead
to code duplication but avoids the use of mach/tc.h
in drivers.
Signed-off-by: Arnd Bergmann
---
arch/arm/mach-omap1/board-osk.c | 38
From: Arnd Bergmann
The driver has always had a FIXME about this, and it seems
like this trivial code move avoids a mach header inclusion,
so just do it.
With that out of the way, and the header file inclusions
changed to global files, the driver can also be compile-tested
on other platforms
From: Arnd Bergmann
There are three remaining header files that are used by omap1
specific device drivers:
- mach/soc.h provides cpu_is_omapXXX abstractions
- mach/hardware.h provides omap_read/omap_write functions
and physical addresses
- mach/mux.h provides an omap specific pinctrl
From: Arnd Bergmann
The register definitions in this header are used in at least four
different places, with little hope of completely cleaning that up.
Split up the file into a portion that becomes a linux-wide header
under include/linux/soc/ti/, and the parts that are actually only
needed
From: Arnd Bergmann
The obsolete camera support was removed, but a few lines remain in this
file and cause a warning:
arch/arm/mach-omap1/board-ams-delta.c:462:12: warning: 'ams_delta_camera_power'
defined but not used [-Wunused-function]
462 | static int ams_delta_camera_power(struct device
From: Arnd Bergmann
To avoid relying on the mach/irqs.h header, stop using
OMAP_LCDC_IRQ and INT_1610_SoSSI_MATCH directly in the driver
code, but instead pass these as resources.
Acked-by: Bartlomiej Zolnierkiewicz
Signed-off-by: Arnd Bergmann
---
arch/arm/mach-omap1/fb.c | 19
From: Arnd Bergmann
omapfb calls directly into the omap_set_dma_priority() function in
the DMA driver. This prevents compile-testing omapfb on other
architectures. Add an inline function next to the other ones
for non-omap configurations.
Acked-by: Bartlomiej Zolnierkiewicz
Signed-off-by: Arnd
From: Arnd Bergmann
The omapfb driver is split into platform specific code for omap1, and
driver code that is also specific to omap1.
Moving both parts into the driver directory simplifies the structure
and avoids the dependency on certain omap machine header files.
As mach/lcd_dma.h can
From: Arnd Bergmann
To avoid using the mach/omap1510.h header file, pass the correct
address as platform data.
Acked-by: Bartlomiej Zolnierkiewicz
Signed-off-by: Arnd Bergmann
---
arch/arm/mach-omap1/board-innovator.c | 3 +++
drivers/video/fbdev/omap/lcd_inn1510.c | 7 +--
2 files
From: Arnd Bergmann
A recent cleanup patch removed the only reference to a local variable
in some configurations.
Move the variable into the one block it is still used in, inside
of an #ifdef, to avoid this warning.
Fixes: 9d773f103b89 ("video: fbdev: omapfb: lcd_ams_delta: Mak
From: Arnd Bergmann
This is the full series for converting OMAP1 to multiplatform, rebased
from my 2019 attempt to do the same thing. The soc tree contains simpler
patches to do the same for iop32x, ixp4xx, ep93xx and s3c24xx, which
means we are getting closer to completing this for all ARMv5
On Wed, Apr 6, 2022 at 3:21 PM Thierry Reding wrote:
> On Wed, Mar 16, 2022 at 07:36:47PM +0100, Arnd Bergmann wrote:
> > static const struct dev_pm_ops vic_pm_ops = {
> > - SET_RUNTIME_PM_OPS(vic_runtime_suspend, vic_runtime_resume, NULL)
> > - SE
On Thu, Mar 17, 2022 at 8:15 PM Thomas Zimmermann wrote:
> Am 16.03.22 um 21:59 schrieb Arnd Bergmann:
> > On Wed, Mar 16, 2022 at 8:31 PM Thomas Zimmermann
> > wrote:
> >
> > I was going for 'depends on' in the panel drivers because I saw the same
> > being
On Wed, Mar 16, 2022 at 8:31 PM Thomas Zimmermann wrote:
> Am 16.03.22 um 20:12 schrieb Thomas Zimmermann:
> >>
> >> Adding a dependency in all drivers that select DRM_MIPI_DBI avoids
> >> the problem for now, adding the dependency in DRM_MIPI_DBI as well
> >> should help make it easier to figure
From: Arnd Bergmann
The use of the old-style SET_RUNTIME_PM_OPS() and
SET_SYSTEM_SLEEP_PM_OPS() macros requires function definitions
to be hidden to avoid
drivers/gpu/drm/tegra/vic.c:326:12: error: 'vic_runtime_suspend' defined but
not used [-Werror=unused-function]
326 | static int
From: Arnd Bergmann
The driver fails to build when the KMS helpers are disabled:
ld.lld: error: undefined symbol: drm_gem_fb_get_obj
>>> referenced by drm_mipi_dbi.c
>>> gpu/drm/drm_mipi_dbi.o:(mipi_dbi_buf_copy) in archive
>>> drivers/built-in.a
>&
On Mon, Feb 28, 2022 at 10:41 PM Fangrui Song wrote:
> >
> >More precisely, the semantics of "extern inline" functions changed
> >between ISO C90 and ISO C99.
>
> Perhaps a clearer explanation to readers is: "extern inline" and "inline" swap
> semantics with gnu_inline (-fgnu89-inline or
On Tue, Mar 1, 2022 at 11:43 AM Miguel Ojeda
wrote:
>
> On Mon, Feb 28, 2022 at 11:32 AM Arnd Bergmann wrote:
> >
> > -under ``-std=gnu89`` [gcc-c-dialect-options]_: the GNU dialect of ISO C90
> > -(including some C99 features). ``clang`` [clang]_ is also supported, see
On Mon, Feb 28, 2022 at 6:02 PM Masahiro Yamada wrote:
>
> On Mon, Feb 28, 2022 at 7:32 PM Arnd Bergmann wrote:
> >
> > From: Arnd Bergmann
> >
> > During a patch discussion, Linus brought up the option of changing
> > the C standard version from gnu89 t
On Mon, Feb 28, 2022 at 1:36 PM Jani Nikula wrote:
> >
> > One minor issue that remains is an added gcc warning for shifts of
> > negative integers when building with -Werror, which happens with the
> > 'make W=1' option, as well as for three drivers in the kernel that always
> > enable -Werror,
On Mon, Feb 28, 2022 at 12:47 PM Marco Elver wrote:
> On Mon, 28 Feb 2022 at 11:32, Arnd Bergmann wrote:
>
> > Nathan Chancellor reported an additional -Wdeclaration-after-statement
> > warning that appears in a system header on arm, this still needs a
> > work
On Mon, Feb 28, 2022 at 12:25 PM Mark Rutland wrote:
> On Mon, Feb 28, 2022 at 11:27:43AM +0100, Arnd Bergmann wrote:
> >
> > Nathan Chancellor reported an additional -Wdeclaration-after-statement
> > warning that appears in a system header on arm, this still needs a
> &
From: Arnd Bergmann
During a patch discussion, Linus brought up the option of changing
the C standard version from gnu89 to gnu99, which allows using variable
declaration inside of a for() loop. While the C99, C11 and later standards
introduce many other features, most of these are already
On Mon, Feb 28, 2022 at 1:14 AM John Stoffel wrote:
>
> On Sun, Feb 27, 2022 at 10:52:43PM +0100, Arnd Bergmann wrote:
> > From: Arnd Bergmann
> >
> > During a patch discussion, Linus brought up the option of changing
> > the C standard version from gnu89 to gnu9
On Mon, Feb 28, 2022 at 12:04 AM Alex Elder wrote:
> On 2/27/22 3:52 PM, Arnd Bergmann wrote: From: Arnd Bergmann
> > I put the suggestion into patch form, based on what we discussed
> > in the thread. I only gave it minimal testing, but it would
> > be good to have it in
On Sun, Feb 27, 2022 at 11:36 PM Linus Torvalds
wrote:
>
> And I don't want somebody with a newer compiler version to not notice
> that he or she ended up using a c17 feature, just because _that_
> compiler supported it, and then other people get build errors because
> their compilers use gnu11
From: Arnd Bergmann
During a patch discussion, Linus brought up the option of changing
the C standard version from gnu89 to gnu99, which allows using variable
declaration inside of a for() loop. While the C99, C11 and later standards
introduce many other features, most of these are already
On Tue, Feb 8, 2022 at 11:42 PM Thinh Nguyen wrote:
> Randy Dunlap wrote:
> > On 2/8/22 12:10, Thinh Nguyen wrote:
> >> Randy Dunlap wrote:
> >>> On 2/3/22 19:21, Thinh Nguyen wrote:
> Ah.. It's because I don't use old.config as the base config. I use
> x86_64_defconfig as the base plus some
On Thu, Feb 3, 2022 at 10:13 AM Thomas Zimmermann wrote:
>
> As reported in [1], DRM_PANEL_EDP depends on DRM_DP_HELPER. Select
> the option to fix the build failure. The issue has been reported
> before, when DisplayPort helpers where hidden behind the option
> CONFIG_DRM_KMS_HELPER. [2]
The
On Thu, Feb 3, 2022 at 12:55 AM Thinh Nguyen wrote:
> Arnd Bergmann wrote:
> > On Wed, Feb 2, 2022 at 1:14 AM Thinh Nguyen
> > wrote:
> >> Fabio Estevam wrote:
> >
> > CONFIG_FB should not normally be needed for booting, so unless
> > you have
On Wed, Feb 2, 2022 at 7:14 PM Verdun, Jean-Marie wrote:
>
> > This is far too big for a single patch. It needs to be broken into
> > functional chunks that can be reviewed individually. Each driver and
> > each device tree change along with it's accompanying code need to be
> > done in
On Wed, Feb 2, 2022 at 1:14 AM Thinh Nguyen wrote:
> Fabio Estevam wrote:
> > On Tue, Feb 1, 2022 at 8:06 PM Randy Dunlap wrote:
> >>
> >> On 2/1/22 15:01, Thinh Nguyen wrote:
> >>> Hi,
> >>>
> >>> One of our test setups is unable to boot (stuck at initramfs). Git
> >>> bisection points to the
On Thu, Jan 13, 2022 at 6:19 PM Philippe Cornu
wrote:
>
> DRM DRIVERS FOR STI
> -M: Benjamin Gaignard
> L: dri-devel@lists.freedesktop.org
> S: Maintained
> T: git git://anongit.freedesktop.org/drm/drm-misc
If there is no longer a maintainer, I suppose it should also be
401 - 500 of 1588 matches
Mail list logo
