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/plat-omap/Makefi
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 +-
drivers
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 either
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(-)
dif
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.
S
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 | 49
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 Bergm
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 --gi
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 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 that c
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 by
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 'omap1_m
From: Janusz Krzysztofik
In preparation for conversion of OMAP1 clocks to common clock framework,
identify arch/arm/mach-omap1 local users of those clocks and update them
to call clk_prepare_enable/clk_disable_unprepare() instead of just
clk_enable/disable(), as required by CCF implementation of
From: Janusz Krzysztofik
Commit ef772f2ee31e ("ARM: OMAP: Fix CONFIG_DEBUG_LL") was supposed to fix
low level debugging, most possibly by early enabling UART clocks. The fix
actually introduced early reset of most bits of MOD_CONF_CTRL_0 register,
with the exception of UART1 and UART2 clock rela
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/arm/m
Hi
Am 19.04.22 um 15:30 schrieb Rob Herring:
...
-#ifndef CONFIG_PPC
static const struct of_device_id reserved_mem_matches[] = {
{ .compatible = "qcom,rmtfs-mem" },
{ .compatible = "qcom,cmd-db" },
@@ -520,33 +519,81 @@ static const struct of_device_id reserved_mem_matches[] =
From: Janusz Krzysztofik
The code of OMAP1 clocks contains quite a few unused elements:
- functions and function like macros never called: clk_reparent(),
recalculate_root_clocks(), clk_enable_init_clocks(),
omap_clk_get_by_name(), omap_clk_disable_autoidle_all(),
__clk_get_parent(clk), __c
From: Janusz Krzysztofik
There are some OMAP1 clock code bits that have no effect:
- crystal_type variable is set to 0 but never changed, then
crystal_type == 2 condition is never true and ck_ref.rate never set to
1920,
- clk->ops->allow_idle() is called from omap_clk_enable_autoidle_all(
From: Janusz Krzysztofik
The driver, OMAP1 specific, now omits clk_prepare/unprepare() steps, not
supported by OMAP1 custom implementation of clock API. However, non-CCF
stubs of those functions exist for use on such platforms until converted
to CCF.
Update the driver to be compatible with CCF
From: Janusz Krzysztofik
The driver, OMAP1 specific, now omits clk_prepare/unprepare() steps, not
supported by OMAP1 custom implementation of clock API. However, non-CCF
stubs of those functions exist for use on such platforms until converted
to CCF.
Update the driver to be compatible with CCF
From: Janusz Krzysztofik
OMAP1 LCDC drivers now omit clk_prepare/unprepare() steps, not supported
by OMAP1 custom implementation of clock API. However, non-CCF stubs of
those functions exist for use on such platforms until converted to CCF.
Update the drivers to be compatible with CCF implement
From: Janusz Krzysztofik
The driver, OMAP specific, now omits clk_prepare/unprepare() steps, not
supported by OMAP custom implementation of clock API. However, non-CCF
stubs of those functions exist for use on such platforms until converted
to CCF.
Update the driver to be compatible with CCF im
From: Janusz Krzysztofik
The driver, OMAP1 specific, now omits clk_prepare/unprepare() steps, not
supported by OMAP1 custom implementation of clock API. However, non-CCF
stubs of those functions exist for use on such platforms until converted
to CCF.
Update the driver to be compatible with CCF
From: Janusz Krzysztofik
OMAP1 still uses its own implementation of standard clock API defined in
include/linux/clk.h. Internals of that implementation are not visible
outside OMAP1 directory. As a consequence, device drivers are not able to
register clocks potentially provided by peripheral de
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 is configur
On Wed, 30 Mar 2022 at 23:23, Marek Vasut wrote:
>
> Add driver for Lontium LT9211 Single/Dual-Link DSI/LVDS or Single DPI to
> Single-link/Dual-Link DSI/LVDS or Single DPI bridge. This chip is highly
> capable at converting formats, but sadly it is also highly undocumented.
>
> This driver is wri
On Tue, 19 Apr 2022 at 04:29, Xin Ji wrote:
>
> On Thu, Apr 14, 2022 at 05:00:04PM +0800, Hsin-Yi Wang wrote:
> > Speaker may share I2S with DP and .get_eld callback will be called when
> > speaker is playing. When HDMI wans't connected, the connector will be
> > null. Instead of return an error,
Am 19.04.22 um 15:59 schrieb Cai Huoqing:
The NVIDIA Deep Learning Accelerator (NVDLA) is an open source IP
which is integrated into NVIDIA Jetson AGX Xavier,
so add driver support for this accelerator.
Signed-off-by: Cai Huoqing
Well doesn't looks so bad on first glance (regarding coding st
The NVIDIA Deep Learning Accelerator (NVDLA) is an open source IP
which is integrated into Jetson AGX Xavier. After adding the driver
support for it, I add the driver info of the NVDLA to MAINTAINERS file.
Signed-off-by: Cai Huoqing
---
MAINTAINERS | 7 +++
1 file changed, 7 insertions(+)
d
The NVIDIA Deep Learning Accelerator (NVDLA) is an open source IP
which is integrated into NVIDIA Jetson AGX Xavier,
so add driver support for this accelerator.
NVDLA introduce:
http://nvdla.org/primer.html
User mode driver:
https://github.com/caihuoq/nvdla/tree/main/sw/umd
Cai Huoqing (2):
M
On Tue, 19 Apr 2022 at 15:37, Arnd Bergmann wrote:
>
> 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
>
On Tue, Apr 19, 2022 at 12:33:01PM +0530, Aradhya Bhatia wrote:
> The DSS IP on the ti-am65x soc supports an additional register space,
> named "common1". Further. the IP services a maximum number of 2
> interrupts.
>
> Add the missing register space "common1" and the additional interrupt.
>
> Si
Connector detection using poll method won't work in case of bridge
attached to the encoder with the flag DRM_BRIDGE_ATTACH_NO_CONNECTOR, as
the code defaults to HPD.
Enable DRM_BRIDGE_OP_HPD based on HPD interrupt availability, so that
it will fall back to polling, if HPD is not available.
Signed
Applied with minor change to drop the prototype in dcn10_hubp.h. Thanks!
Alex
On Fri, Apr 15, 2022 at 2:21 PM Tales Lelo da Aparecida
wrote:
>
> It's a local function, let's make it static.
>
> Signed-off-by: Tales Lelo da Aparecida
> ---
> drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hubp.c |
On 19 4月 22 16:07:44, Christian König wrote:
> Am 19.04.22 um 15:59 schrieb Cai Huoqing:
> > The NVIDIA Deep Learning Accelerator (NVDLA) is an open source IP
> > which is integrated into NVIDIA Jetson AGX Xavier,
> > so add driver support for this accelerator.
> >
> > Signed-off-by: Cai Huoqing
Applied. Thanks!
On Tue, Apr 19, 2022 at 8:49 AM Keita Suzuki
wrote:
>
> In function si_parse_power_table(), array adev->pm.dpm.ps and its member
> is allocated. If the allocation of each member fails, the array itself
> is freed and returned with an error code. However, the array is later
> fre
Add bindings for Lontium LT9211 Single/Dual-Link DSI/LVDS or Single DPI to
Single-link/Dual-Link DSI/LVDS or Single DPI bridge. This chip is highly
capable at converting formats, but sadly it is also highly undocumented.
Reviewed-by: Rob Herring
Signed-off-by: Marek Vasut
Cc: Laurent Pinchart
C
Add driver for Lontium LT9211 Single/Dual-Link DSI/LVDS or Single DPI to
Single-link/Dual-Link DSI/LVDS or Single DPI bridge. This chip is highly
capable at converting formats, but sadly it is also highly undocumented.
This driver is written without any documentation from Lontium and based
only on
Applied. Thanks!
On Mon, Apr 18, 2022 at 3:48 PM Tom Rix wrote:
>
> Smatch reports this issue
> virtual_link_hwss.c:32:6: warning: symbol
> 'virtual_setup_stream_attribute' was not declared.
> Should it be static?
>
> virtual_setup_stream_attribute is only used in
> virtual_link_hwss.c, but
On Tue, 19 Apr 2022 at 16:40, Marek Vasut wrote:
>
> Add bindings for Lontium LT9211 Single/Dual-Link DSI/LVDS or Single DPI to
> Single-link/Dual-Link DSI/LVDS or Single DPI bridge. This chip is highly
> capable at converting formats, but sadly it is also highly undocumented.
>
> Reviewed-by: Rob
Hi Geert,
Thanks for the feedback.
> Subject: Re: [PATCH v2 1/2] dt-bindings: display: bridge: Document RZ/G2L
> MIPI DSI TX bindings
>
> Hi Biju,
>
> On Mon, Mar 28, 2022 at 8:49 AM Biju Das
> wrote:
> > The RZ/G2L MIPI DSI TX is embedded in the Renesas RZ/G2L family SoC's.
> > It can operate
Applied. Thanks!
On Sat, Apr 16, 2022 at 2:48 PM Tom Rix wrote:
>
> evergreen_default_state and evergreen_default_size are only
> used in evergreen.c. Single file symbols should be static.
> So move their definitions to evergreen_blit_shaders.h
> and change their storage-class-specifier to stat
On 19/04/2022 05:32, Rex-BC Chen wrote:
From: "Nancy.Lin"
Add vdosys1 RDMA definition.
Signed-off-by: Nancy.Lin
Reviewed-by: AngeloGioacchino Del Regno
---
.../display/mediatek/mediatek,mdp-rdma.yaml | 86 +++
1 file changed, 86 insertions(+)
create mode 100644
Do
On 19/04/2022 05:32, Rex-BC Chen wrote:
From: "jason-jh.lin"
In the SoC before, such as mt8173, it has 2 pipelines binding to one
mmsys with the same clock driver and the same power domain.
In mt8195, there are 4 pipelines binding to 4 different mmsys, such as
vdosys0, vdosys1, vppsys0 and
On 19/04/2022 05:32, Rex-BC Chen wrote:
From: "jason-jh.lin"
Power:
1. Add description for power-domains property.
GCE:
1. Add description for mboxes property.
2. Add description for mediatek,gce-client-reg property.
Signed-off-by: jason-jh.lin
Reviewed-by: AngeloGioacchino Del Regno
Re
Applied the series with minor fix to capitalize the U in Compute Unit. Thanks!
Alex
On Fri, Apr 15, 2022 at 3:52 PM Tales Lelo da Aparecida
wrote:
>
> Add missing acronyms to the amdgppu glossary.
>
> Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/1939#note_1309737
> Signed-off-by: Tal
On Sat, Apr 16, 2022 at 11:41 AM Julia Lawall wrote:
>
> From: kernel test robot
>
> Use max to simplify the code.
>
> Generated by: scripts/coccinelle/misc/minmax.cocci
>
> CC: Denis Efremov
> Reported-by: kernel test robot
> Signed-off-by: kernel test robot
> Signed-off-by: Julia Lawall
Th
Matthias Brugger 於 2022年4月19日 週二 下午10:57寫道：
>
>
>
> On 19/04/2022 05:32, Rex-BC Chen wrote:
> > From: "Nancy.Lin"
> >
> > Add vdosys1 RDMA definition.
> >
> > Signed-off-by: Nancy.Lin
> > Reviewed-by: AngeloGioacchino Del Regno
> >
> > ---
> > .../display/mediatek/mediatek,mdp-rdma.yaml |
These patches coninue work started by AngeloGioacchino Del Regno in the
previous cycle by further decoupling and dissecting MDSS and MDP drivers
probe/binding paths.
This removes code duplication between MDP5 and DPU1 MDSS drivers, by
merging them and moving to the top level.
Changes since v5:
-
MDP5 and DPU1 both provide the driver handling the MDSS region, which
handles the irq domain and (incase of DPU1) adds some init for the UBWC
controller. Unify those two pieces of code into a common driver.
Reviewed-by: Abhinav Kumar
Reviewed-by: Stephen Boyd
Signed-off-by: Dmitry Baryshkov
---
MSM DRM driver already allows one to compile out the DP or DSI support.
Add support for disabling other features like MDP4/MDP5/DPU drivers or
direct HDMI output support.
Suggested-by: Stephen Boyd
Reviewed-by: Stephen Boyd
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/Kconfig
Let's make the match's data pointer a (sub-)driver's private data. The
only user currently is the msm_drm_init() function, using this data to
select kms_init callback. Pass this callback through the driver's
private data instead.
Reviewed-by: Stephen Boyd
Reviewed-by: Abhinav Kumar
Signed-off-by
Since now there is just one mdss subdriver, drop all the indirection,
make msm_mdss struct completely opaque (and defined inside msm_mdss.c)
and call mdss functions directly.
Reviewed-by: Abhinav Kumar
Reviewed-by: Stephen Boyd
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/msm_drv.c
The msm_mdss serves several roles at this moment. It provides IRQ domain
used by MDP5 and DPU drivers but it also serves as a component master
for both those usecases. MDP4 (which does not have separate MDSS device)
is the component master on it's own.
Remove this assymmetry and make both MDP5 and
Currently the msm platform driver is a multiplex handling several cases:
- headless GPU-only driver,
- MDP4 with flat device nodes,
- MDP5/DPU MDSS with all the nodes being children of MDSS node.
This results in not-so-perfect code, checking the hardware version
(MDP4/MDP5/DPU) in several places,
On 19/04/2022 09:16, Haowen Bai wrote:
Since mdp5_state is initialized twice at the same time, so
we make code simple and easy to understand by delete one.
Signed-off-by: Haowen Bai
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c | 2 --
1 file changed, 2 de
On Tue, 19 Apr 2022 at 16:25, Biju Das wrote:
>
> Connector detection using poll method won't work in case of bridge
> attached to the encoder with the flag DRM_BRIDGE_ATTACH_NO_CONNECTOR, as
> the code defaults to HPD.
>
> Enable DRM_BRIDGE_OP_HPD based on HPD interrupt availability, so that
> it
On Tue, 19 Apr 2022 at 11:41, Jagan Teki wrote:
>
> On Tue, Apr 19, 2022 at 2:44 PM Marek Szyprowski
> wrote:
> >
> > If panel_bridge_attach() happens after DRM device registration, the
> > created connector will not be registered by the DRM core anymore. Fix
> > this by registering it explicitel
Hi Biju,
Thank you for the patch.
On Tue, Apr 19, 2022 at 03:24:53PM +0100, Biju Das wrote:
> Connector detection using poll method won't work in case of bridge
> attached to the encoder with the flag DRM_BRIDGE_ATTACH_NO_CONNECTOR, as
> the code defaults to HPD.
>
> Enable DRM_BRIDGE_OP_HPD bas
Remove loops over hw_vbif. Instead always VBIF's idx as an index in the
array. This fixes an error in dpu_kms_hw_init(), where we fill
dpu_kms->hw_vbif[i], but check for an error pointer at
dpu_kms->hw_vbif[vbif_idx].
Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support")
Signed-off-by: Dmitry Ba
As suggested by Abhinav, rework VBIF handling, simplifying the code.
Changes since v1:
- Fix array index comparison in patch 1 (as noted by Abhinav)
Dmitry Baryshkov (3):
drm/msm/dpu: index dpu_kms->hw_vbif using vbif_idx
drm/msm/dpu: fix error handling around dpu_hw_vbif_init
drm/msm/dpu:
We do not expect to have other VBIFs. Drop VBIF_n indices and always use
VBIF_RT and VBIF_NRT.
Reviewed-by: Abhinav Kumar
Signed-off-by: Dmitry Baryshkov
---
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 4 +--
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h | 6 ++--
drivers/gpu/drm/msm/disp
Using IS_ERR_OR_NULL() together with PTR_ERR() is a typical mistake. If
the value is NULL, then the function will return 0 instead of a proper
return code. Moreover dpu_hw_vbif_init() function can not return NULL.
So, replace corresponding IS_ERR_OR_NULL() call with IS_ERR().
Reviewed-by: Abhinav
On 08/03/2022 23:46, Stephen Boyd wrote:
Quoting Dmitry Baryshkov (2022-03-03 23:58:58)
On Fri, 4 Mar 2022 at 07:31, Stephen Boyd wrote:
Quoting Dmitry Baryshkov (2022-03-03 20:23:06)
On Fri, 4 Mar 2022 at 01:32, Stephen Boyd wrote:
Quoting Dmitry Baryshkov (2022-02-16 21:55:27)
The only
On Sun, 17 Apr 2022 03:45:49 +0200, Marek Vasut wrote:
> Add compatible string for i.MX8MP LCDIF variant. This is called LCDIFv3
> and is completely different from the LCDIFv3 found in i.MX23 in that it
> has a completely scrambled register layout compared to all previous LCDIF
> variants. The new
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
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
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(+), 3 del
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/zeus.c
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
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
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-by: Robe
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/bal
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-d
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
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
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
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 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-by: Arn
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
Reviewed-by: Linus Walle
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/p
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 platform_data structu
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 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
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.
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
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
cons
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-pr
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-project.o
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/mainston
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/mac
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-of
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 for
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: als
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 | 4
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/t
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 Berg
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&replace, which leads
to
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&replace, which leads
to
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
---
ar
1 - 100 of 246 matches
Mail list logo
