Hi,
On Fri, Apr 15, 2022 at 05:47:45PM +0200, José Expósito wrote:
> The vc4_hdmi_encoder.hdmi_monitor field was used to cache the value
> returned by drm_detect_hdmi_monitor() in order to avoid calling it
> multiple times.
>
> Now that drm_detect_hdmi_monitor() has been replaced with
>
On Sun, Apr 17, 2022 at 01:29:18PM +, Xuezhi Zhang wrote:
> Fix the following coccicheck warning:
> drivers/gpu/drm/arm/malidp_drv.c:658:8-16:
> WARNING: use scnprintf or sprintf
>
> Signed-off-by: Xuezhi Zhang
Acked-by: Liviu Dudau
Thanks for this!
Best regards,
Liviu
> ---
>
On 14/03/2022 13:37, Devarsh Thakkar wrote:
Soft reset the display subsystem controller on startup and wait for
the reset to complete. This helps the scenario where display was
already in use by some other core before the linux was booted.
Signed-off-by: Devarsh Thakkar
---
Hi,
On Tue, Apr 12, 2022 at 07:04:57AM +, Miaoqian Lin wrote:
> If the device is already in a runtime PM enabled state
> pm_runtime_get_sync() will return 1, so a test for negative
> value should be used to check for errors.
>
> Fixes: 4078f5757144 ("drm/vc4: Add DSI driver")
>
urquell_defconfig
arm randconfig-c002-20220418
x86_64 randconfig-c001-20220418
x86_64randconfig-c001
arm randconfig-c002-20220419
ia64 allmodconfig
ia64 allyesconfig
ia64
From: Minghao Chi
Using pm_runtime_resume_and_get() to replace pm_runtime_get_sync and
pm_runtime_put_noidle. This change is just to simplify the code, no
actual functional changes.
Reported-by: Zeal Robot
Signed-off-by: Minghao Chi
---
drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 6 ++
1
Am Freitag, den 08.04.2022, 21:15 +0300 schrieb Laurent Pinchart:
> On Wed, Mar 23, 2022 at 09:06:18PM +0100, Max Krummenacher wrote:
> > Am Mittwoch, den 23.03.2022, 16:58 +0100 schrieb Maxime Ripard:
> > > On Wed, Mar 23, 2022 at 09:42:11AM +0100, Max Krummenacher wrote:
> > > > Am Freitag, den
On Tue, 19 Apr 2022 11:32:35 +0800, 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
On Tue, 19 Apr 2022 11:32:37 +0800, Rex-BC Chen wrote:
> From: "Nancy.Lin"
>
> Add vdosys1 ETHDR definition.
>
> Signed-off-by: Nancy.Lin
> Reviewed-by: Chun-Kuang Hu
> Reviewed-by: AngeloGioacchino Del Regno
>
> ---
> .../display/mediatek/mediatek,ethdr.yaml | 158 ++
On Tue, 19 Apr 2022 12:33:01 +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.
>
>
This reverts commit e2a88eabb02410267519b838fb9b79f5206769be. The commit
in question makes msm_use_mmu() check whether the DRM 'component master'
device is translated by the IOMMU. At this moment it is the 'mdss'
device.
However on platforms using the MDP5 driver (e.g. MSM8916/APQ8016,
On 19/04/2022 10:03, Aradhya Bhatia wrote:
The Display SubSystem IP on the ti's am65x soc has an additional
register space "common1" and services a maximum of 2 interrupts.
The first patch in the series adds the required updates to the yaml
file. The second patch then reflects the yaml updates
On Tue, Apr 19, 2022 at 12:04:04PM +0200, Thomas Zimmermann wrote:
> Create a platform device for each OF-declared framebuffer and have
> offb bind to these devices. Allows for real hot-unplugging and other
> drivers besides offb.
>
> Originally, offb created framebuffer devices while
Hello Geert,
Thanks a lot for your feedback.
On 4/19/22 09:52, Geert Uytterhoeven wrote:
[snip]
>> +static int ssd130x_spi_write(void *context, const void *data, size_t count)
>> +{
>> + struct ssd130x_spi_transport *t = context;
>> + struct spi_device *spi = t->spi;
>> +
Hi Javier,
On Wed, Apr 13, 2022 at 6:24 PM Javier Martinez Canillas
wrote:
> The ssd130x driver only provides the core support for these devices but it
> does not have any bus transport logic. Add a driver to interface over SPI.
>
> There is a difference in the communication protocol when using
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 explicitely in such case.
>
> This fixes the following issue observed on
A workaround makes fbdev hot-unplugging work for framebuffers without
device. The only user for this feature was offb. As each OF framebuffer
now has an associated platform device, the workaround hould no longer
be triggered. Update it with a warning and rewrite the comment. Fbdev
drivers that
Create a platform device for each OF-declared framebuffer and have
offb bind to these devices. Allows for real hot-unplugging and other
drivers besides offb.
Originally, offb created framebuffer devices while initializing its
module by parsing the OF device tree. No actual Linux device was set
Move the detection of OF framebuffers from fbdev into of platform code
and register a Linux platform device for each framebuffer. Allows for
DRM-based OF drivers and real hot-unplugging of the framebuffer.
This patchset has been tested with qemu's ppc64le emulation, which
provides a framebuffer
Hi
Am 18.04.22 um 00:37 schrieb Dmitry Osipenko:
Introduce a common DRM SHMEM shrinker. It allows to reduce code
duplication among DRM drivers that implement theirs own shrinkers.
This is initial version of the shrinker that covers basic needs of
GPU drivers, both purging and eviction of shmem
Hello Thomas,
On 4/13/22 20:09, Thomas Zimmermann wrote:
[snip]
index bc6ed750e915..bdd00d381bbc 100644
--- a/drivers/video/fbdev/core/fbmem.c
+++ b/drivers/video/fbdev/core/fbmem.c
@@ -1579,14 +1579,7 @@ static void
do_remove_conflicting_framebuffers(struct
Am 18.04.22 um 22:09 schrieb Zack Rusin:
On Tue, 2022-04-12 at 11:15 +0200, Christian König wrote:
Hi Zack,
Reviewed-by: Christian König for the
entire
series.
One nit pick is that I want to get rid of using ttm_manager_type() in
drivers and use pointers to the members directly. But that's
On 4/12/22 11:53 AM, Jason Gunthorpe wrote:
Every caller has a readily available vfio_device pointer, use that instead
of passing in a generic struct device. The struct vfio_device already
contains the group we need so this avoids complexity, extra refcountings,
and a confusing lifecycle
On 4/12/22 11:53 AM, Jason Gunthorpe wrote:
All callers have a struct vfio_device trivially available, pass it in
directly and avoid calling the expensive vfio_group_get_from_dev().
To support the unconverted kvmgt mdev driver add
mdev_legacy_get_vfio_device() which will return the
On 4/12/22 11:53, Jason Gunthorpe wrote:
Every caller has a readily available vfio_device pointer, use that instead
of passing in a generic struct device. The struct vfio_device already
contains the group we need so this avoids complexity, extra refcountings,
and a confusing lifecycle model.
...
On 4/12/22 11:53, Jason Gunthorpe wrote:
All callers have a struct vfio_device trivially available, pass it in
directly and avoid calling the expensive vfio_group_get_from_dev().
To support the unconverted kvmgt mdev driver add
mdev_legacy_get_vfio_device() which will return the vfio_device
On 4/18/22 11:44 AM, Jason Gunthorpe wrote:
On Mon, Apr 18, 2022 at 11:28:30AM -0400, Tony Krowiak wrote:
diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c
index a4555014bd1e72..8a5c46aa2bef61 100644
+++ b/drivers/vfio/vfio.c
@@ -2484,19 +2484,15 @@ static int
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
---
drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c
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 in DSI mode, with up to four data lanes.
>
> Signed-off-by: Biju Das
Thanks for your patch!
> --- /dev/null
> +++
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 explicitely in such case.
This fixes the following issue observed on Samsung Exynos4210-based Trats
board with a DSI panel (the panel
Hi Marek,
Thank you for the patch.
On Sun, Apr 17, 2022 at 04:10:11AM +0200, Marek Vasut wrote:
> In case the MXSFB is connected to a bridge, attempt to obtain bus flags
> from that bridge state too. The bus flags may specify e.g. the DE signal
> polarity.
>
> Acked-by: Alexander Stein
>
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
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
---
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),
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
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
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 |
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
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
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
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:
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
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:
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,
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
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
>
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
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:
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
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:
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: 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: 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 -
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: 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
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 ++--
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
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
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 by
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
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.
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,
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
>
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
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
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
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 ++--
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
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
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 +-
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
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
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:
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 -
From: Arnd Bergmann
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
From: Arnd Bergmann
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
Signed-off-by:
From: Arnd Bergmann
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
From: Arnd Bergmann
The battery driver uses a lot of GPIO lines, hardcoded from a
machine header file.
Change it to use a gpiod lookup table instead.
Reviewed-by: Sebastian Reichel
Acked-by: Sebastian Reichel
Cc: linux...@vger.kernel.org
Signed-off-by: Arnd Bergmann
---
From: Arnd Bergmann
The sa.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
Signed-off-by: Arnd Bergmann
---
From: Arnd Bergmann
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
Cc: Stephen Boyd
Cc: linux-...@vger.kernel.org
Link:
From: Arnd Bergmann
We have three power supplies that need similar initialization.
As a preparation for the gpio lookup table conversion, split
out the initialization into a separate function.
Reviewed-by: Sebastian Reichel
Acked-by: Sebastian Reichel
Cc: linux...@vger.kernel.org
From: Arnd Bergmann
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
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 not
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
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: Make use of the
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: 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
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
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
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
1 - 100 of 241 matches
Mail list logo
