- 07 May, 2022 28 commits
-
-
Arnd Bergmann authored
There are two drivers in arch/arm/plat-pxa: mfp and ssp. Both of them should ideally not be needed at all, as there are proper subsystems to replace them. OTOH, they are self-contained and can simply be normal SoC drivers, so move them over there to eliminate one more of the plat-* directories. Acked-by: Robert Jarzmik <robert.jarzmik@free.fr> (mach-pxa) Acked-by: Lubomir Rintel <lkundrak@v3.sk> (mach-mmp) Signed-off-by:Arnd Bergmann <arnd@arndb.de>
-
Arnd Bergmann authored
In a multiplatform kernel that includes both pxa and mmp, we get a link failure from the clash of two pxa_register_device functions. Rename the one in mach-mmp to mmp_register_device, along with with the rename of pxa_device_desc. Acked-by:
Lubomir Rintel <lkundrak@v3.sk> Signed-off-by:
-
Arnd Bergmann authored
There are two tavorevb boards in the kernel, one using a PXA930 chip in mach-pxa, and one using the later PXA910 chip in mach-mmp. They use the same board number, which is generally a bad idea, and in a multiplatform kernel, we can end up with funny link errors like this one resulting from two boards gettting controlled by the same Kconfig symbol: arch/arm/mach-mmp/tavorevb.o: In function `tavorevb_init': tavorevb.c:(.init.text+0x4c): undefined reference to `pxa910_device_uart1' tavorevb.c:(.init.text+0x50): undefined reference to `pxa910_device_gpio' tavorevb.o:(.arch.info.init+0x54): undefined reference to `pxa910_init_irq' tavorevb.o:(.arch.info.init+0x58): undefined reference to `pxa910_timer_init' The mach-pxa TavorEVB seems much more complete than the mach-mmp one that supports only uart, gpio and ethernet. Further, I could find no information about the board on the internet aside from references to the Linux kernel, so I assume this was never available outside of Marvell and can be removed entirely. There is a third board named TavorEVB in the Kconfig description, but this refers to the "TTC_DKB" machine. The two are clearly related, so I change the Kconfig description to just list both names. Cc: Lubomir Rintel <lkundrak@v3.sk> Reviewed-by:
-
Arnd Bergmann authored
The sa1111.h header defines some constants using the bitfield macros, but those are only used on sa1100, not on pxa, and the users include the bitfield header through mach/hardware.h. Acked-by:
Robert Jarzmik <robert.jarzmik@free.fr> Signed-off-by:
-
Arnd Bergmann authored
The clock register definitions are now used (almost) exclusively in the clk driver, and that relies on no other mach/*.h header files any more. Remove the dependency on mach/pxa*-regs.h by addressing the registers as offsets from a void __iomem * pointer, which is either passed from a board file, or (for the moment) ioremapped at boot time from a hardcoded address in case of DT (this should be moved into the DT of course). Cc: linux-clk@vger.kernel.org Acked-by:
Stephen Boyd <sboyd@kernel.org> Acked-by:
-
Arnd Bergmann authored
The get_sdram_rows() and get_memclkdiv() helpers need smemc register that are separate from the clk registers, move them out of the clk driver, and use an extern declaration instead. Cc: Michael Turquette <mturquette@baylibre.com> Cc: Stephen Boyd <sboyd@kernel.org> Cc: linux-clk@vger.kernel.org Link: https://lore.kernel.org/lkml/87pnielzo4.fsf@belgarion.home/Signed-off-by:
-
Arnd Bergmann authored
The driver needs some low-level register access for setting the core and bus frequencies. These registers are owned by the clk driver, so move the low-level access into that driver with a slightly higher-level interface and avoid any machine header file dependencies. Cc: Michael Turquette <mturquette@baylibre.com> Cc: Stephen Boyd <sboyd@kernel.org> Acked-by:
Viresh Kumar <viresh.kumar@linaro.org> Cc: linux-clk@vger.kernel.org Cc: linux-pm@vger.kernel.org Signed-off-by:
-
Arnd Bergmann authored
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:
-
Arnd Bergmann authored
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 <linux@dominikbrodowski.net> Link: https://lore.kernel.org/lkml/87d0egjzxk.fsf@belgarion.home/Signed-off-by:
-
Arnd Bergmann authored
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&replace, which leads to a few overlong lines, but seems less risky than trying to clean up the code at the same time. Acked-by:
Mark Brown <broonie@kernel.org> Acked-by:
-
Arnd Bergmann authored
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&replace, which leads to a few overlong lines, but seems less risky than trying to clean up the code at the same time. Cc: alsa-devel@alsa-project.org Acked-by:
-
Arnd Bergmann authored
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:
-
Dmitry Torokhov authored
Now that we are using oneshot threaded IRQ this method is not used anymore. Signed-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> [arnd: add the db1300 change as well] Cc: Manuel Lauss <manuel.lauss@gmail.com> Signed-off-by:
-
Dmitry Torokhov authored
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:
-
Arnd Bergmann authored
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:
-
Arnd Bergmann authored
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 for the zylonite board to order to keep the default behavior (interrupt enabled) there. Acked-by:
-
Arnd Bergmann authored
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:
-
Arnd Bergmann authored
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 <dmitry.torokhov@gmail.com> Cc: linux-input@vger.kernel.org Acked-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Arnd Bergmann authored
This driver hardcodes gpio numbers without a header file. Use lookup tables instead. Cc: Marek Vasut <marek.vasut@gmail.com> Acked-by:
-
Arnd Bergmann authored
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:
-
Arnd Bergmann authored
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:
-
Arnd Bergmann authored
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 for consistency here. Acked-by:
-
Arnd Bergmann authored
The audio driver should not use a hardwired gpio number from the header. Change it to use a lookup table. Acked-by:
-
Arnd Bergmann authored
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 <balbi@kernel.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: linux-usb@vger.kernel.org Acked-by:
-
Arnd Bergmann authored
The audio driver should not use a hardwired gpio number from the header. Change it to use a lookup table. Cc: Philipp Zabel <philipp.zabel@gmail.com> Cc: Paul Parsons <lost.distance@yahoo.com> Acked-by:
-
Arnd Bergmann authored
The audio driver should not use a hardwired gpio number from the header. Change it to use a lookup table. Acked-by:
-
Arnd Bergmann authored
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 platform_data structure. to avoid the globally visible mach/poodle.h header. Acked-by:
-
Linus Walleij authored
The Tosa device (Sharp SL-6000) has a mishmash driver set-up for the Toshiba TC6393xb MFD that includes a battery charger and touchscreen and has some kind of relationship to the SoC sound driver for the AC97 codec. Other devices define a chip like this but seem only half-implemented, not really handling battery charging etc. This patch switches the Toshiba MFD device to provide GPIO descriptors to the battery charger and SoC codec. As a result some descriptors need to be moved out of the Tosa boardfile and new one added: all SoC GPIO resources to these drivers now comes from the main boardfile, while the MFD provide GPIOs for its portions. As a result we can request one GPIO from our own GPIO chip and drop two hairy callbacks into the board file. This platform badly needs to have its drivers split up and converted to device tree probing to handle this quite complex relationship in an orderly manner. I just do my best in solving the GPIO descriptor part of the puzzle. Please don't ask me to fix everything that is wrong with these driver to todays standards, I am just trying to fix one aspect. I do try to use modern devres resource management and handle deferred probe using new functions where appropriate. Cc: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> Cc: Dirk Opfer <dirk@opfer-online.de> Cc: Robert Jarzmik <robert.jarzmik@free.fr> Cc: Daniel Mack <daniel@zonque.org> Cc: Haojian Zhuang <haojian.zhuang@gmail.com> Cc: Lee Jones <lee.jones@linaro.org> Cc: Liam Girdwood <lgirdwood@gmail.com> Reviewed-by:
Dmitry Baryshkov <dbaryshkov@gmail.com> Acked-by:
Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by:
-
- 20 Apr, 2022 2 commits
-
-
Arnd Bergmann authored
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:
-
Arnd Bergmann authored
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: linux-ide@vger.kernel.org Acked-by:
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Acked-by:
Damien Le Moal <damien.lemoal@opensource.wdc.com> Signed-off-by:
-
- 19 Apr, 2022 10 commits
-
-
Arnd Bergmann authored
Drivers should not rely on the contents of this file, so move it into the platform directory directly. Cc: Philipp Zabel <philipp.zabel@gmail.com> Cc: Paul Parsons <lost.distance@yahoo.com> Signed-off-by:
-
Arnd Bergmann authored
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 <marek.vasut@gmail.com> Cc: Dominik Brodowski <linux@dominikbrodowski.net> Cc: Jonathan Cameron <jic23@cam.ac.uk> Signed-off-by: -
Arnd Bergmann authored
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 one enables the driver here as well. Cc: alsa-devel@alsa-project.org Acked-by:
-
Arnd Bergmann authored
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 <wim@linux-watchdog.org> Cc: linux-watchdog@vger.kernel.org Acked-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
-
Arnd Bergmann authored
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:
-
Arnd Bergmann authored
This is a basically a platform_data file, so move it out of the mach/* header directory. Cc: Marek Vasut <marek.vasut@gmail.com> Cc: Tomas Cech <sleep_walker@suse.com> Cc: Sergey Lapin <slapin@ossfans.org> Acked-by:
-
Arnd Bergmann authored
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:
-
Arnd Bergmann authored
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 <linux/soc/pxa/cpu.h> and mach/pxa-regs.h headers, then change all the files that use mach/hardware.h to include the exact set of those three headers that they actually need, allowing for further more targeted cleanup. linux/soc/pxa/cpu.h can remain permanently exported and is now in a global location along with similar headers. pxa-regs.h and addr-map.h are only used in a very small number of drivers now and can be moved to arch/arm/mach-pxa/ directly when those drivers are to pass the necessary data as resources. Cc: Michael Turquette <mturquette@baylibre.com> Cc: Stephen Boyd <sboyd@kernel.org> Acked-by:
Ulf Hansson <ulf.hansson@linaro.org> Cc: Dominik Brodowski <linux@dominikbrodowski.net> Acked-by:
Alexandre Belloni <alexandre.belloni@bootlin.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Guenter Roeck <linux@roeck-us.net> Acked-by:
-
Arnd Bergmann authored
The file no longer contains anything useful, so remove it. Acked-by:
-
Arnd Bergmann authored
This is not used by any drivers, so make it private to the platform. Acked-by:
-
