+ linux-wireless, netdev
Jani Nikula writes:
> On Thu, 14 Apr 2022, Greg Kroah-Hartman wrote:
>> On Thu, Apr 14, 2022 at 03:30:32PM +0300, Jani Nikula wrote:
>>> Hey, I've sent this before, ages ago, but haven't really followed
>>> through with it. I still think it would be useful for many
From: Zack Rusin
v2: Add the last part of the ref count fix which was spotted by
Philipp Sieweck where the ref count of cpu writers is off due to
ERESTARTSYS or EBUSY during bo waits.
The initial GEM port broke refcounting on shareable (prime) surfaces and
memory evictions. The prime surfaces
On Thu, 2022-04-07 at 10:59 +0200, Christian König wrote:
> Rework the internals of the dma_resv object to allow adding more than
> one
> write fence and remember for each fence what purpose it had.
>
> This allows removing the workaround from amdgpu which used a container
> for
> this instead.
>
On Mon 11 Apr 13:47 PDT 2022, Sean Paul wrote:
> From: Sean Paul
>
> This patch adds the register ranges required for HDCP key injection and
> HDCP TrustZone interaction as described in the dt-bindings for the
> sc7180 dp controller.
Can you please mention why this is only done for trogdor and
I am dropping this change because originally I had made this only to
show usage of drm_writeback_connector_init_with_encoder().
For writeback functionality, vc4 doesnt need this and this seems redundant.
To show the usage of drm_writeback_connector_init_with_encoder(), I have
posted the MSM
Make changes to dpu_encoder to support virtual encoder needed
to support writeback for dpu.
changes in v2:
- add the writeback parts to dpu_encoder_helper_phys_cleanup
- rebase on tip of msm-next and fix related dependencies
- get the writeback blocks directly from RM
add dpu encoder APIs to prepare and cleanup writeback job
for the writeback encoder. These shall be invoked from the
prepare_wb_job/cleanup_wb_job hooks of the drm_writeback
framework.
changes in v2:
- rebased on tip of msm-next
Signed-off-by: Abhinav Kumar
Reviewed-by: Dmitry Baryshkov
kms_writeback test cases also verify with a null fb for the
writeback connector job. In addition there are also other
commit paths which can result in kickoffs without a valid
framebuffer like while closing the fb which results in the
callback to drm_atomic_helper_dirtyfb() which internally
Add a reset_intf_cfg operation for dpu_hw_ctl to reset the
entire CTL path by disabling each component namely layer mixer,
3d-merge and interface blocks.
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c | 32 ++
Introduce the dpu_encoder_phys_* for the writeback interface
to handle writeback specific hardware programming.
changes in v2:
- rebase on msm-next and fix related dependencies namely
the irq cleanup
- move cdp_cfg, aspace out of dpu_encoder_phys_wb
- leave a
Add writeback blocks to the sm8250 DPU hardware catalog. Other
chipsets support writeback too but add it to sm8250 to prototype
the feature so that it can be easily extended to other chipsets.
changes in v2:
- none
Signed-off-by: Abhinav Kumar
Reviewed-by: Dmitry Baryshkov
---
Add an API to reset the encoder related hw blocks to ensure
a proper teardown of the pipeline. At the moment this is being
used only for the writeback encoder but eventually we can start
using this for all interfaces.
changes in v2:
- split the writeback part to another commit
_dpu_plane_get_qos_lut() is not specific to just dpu_plane.
It can take any fill level and return the LUT matching it.
This can be used even for other modules like dpu_writeback.
Move _dpu_plane_get_qos_lut() to the common dpu_hw_util file
and rename it to _dpu_hw_get_qos_lut().
Signed-off-by:
Add writeback block information while capturing the display
snapshot.
Signed-off-by: Abhinav Kumar
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
Add writeback blocks to DPU resource manager so that
the encoders can directly request them through RM.
changes in v2:
- stop global tracking of WB blocks similar to INTF
- align usage of hw_wb to be similar to that of hw_intf
Signed-off-by: Abhinav Kumar
---
Initialize dpu encoder and connector for writeback if the
target supports it in the catalog.
changes in v2:
- start initialing the encoder for writeback since we
have migrated to using drm_writeback_connector_init_with_encoder()
- instead of checking for WB_2 inside
Introduce the dpu_writeback module which serves as the
interface between dpu operations and the drm_writeback.
This module manages the connector related operations for
dpu writeback.
changes in v2:
- start using drm_writeback_connector_init_with_encoder()
- drop unnecessary
For vendors drivers which pass an already allocated and
initialized encoder especially for cases where the encoder
hardware is shared OR the writeback encoder shares the resources
with the rest of the display pipeline introduce a new API,
drm_writeback_connector_init_with_encoder() which expects
Add changes to support writeback module in the dpu_hw_ctl
interface.
changes in v2:
- keep only the wb specific changes to reset_intf_cfg
- use cfg->intf / cfg->wb to identify intf or wb
- use bit-wise OR for the wb bits while programming
Signed-off-by: Abhinav Kumar
---
Add the dpu_hw_wb abstraction to program registers related to the
writeback block. These will be invoked once all the configuration
is set and ready to be programmed to the registers.
changes in v2:
- remove multiple empty lines at the end of the file
- change
For some vendor driver implementations, display hardware can
be shared between the encoder used for writeback and the physical
display.
In addition resources such as clocks and interrupts can
also be shared between writeback and the real encoder.
To accommodate such vendor drivers and hardware,
Clients of drm_writeback_connector_init() initialize the
possible_crtcs and then invoke the call to this API.
To simplify things, allow passing possible_crtcs as a parameter
to drm_writeback_connector_init() and make changes to the
other drm drivers to make them compatible with this change.
This series adds support for writeback block on DPU. Writeback
block is extremely useful to validate boards having no physical displays
in addition to many other use-cases where we want to get the output
of the display pipeline to examine whether issue is with the display
pipeline or with the
Hi Ian,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on staging/staging-testing]
url:
https://github.com/intel-lab-lkp/linux/commits/Ian-Cowan/Staging-fbtft-Fix-style-problem-in-header/20220420-040428
base:
In the error handling path, the clk_prepare_enable() function
call should be balanced by a corresponding 'clk_disable_unprepare()'
call , as already done in the remove function.
Fixes: 3424e3a4f844 ("drm: bridge: analogix/dp: split exynos dp driver to
bridge directory")
Signed-off-by: Miaoqian
From: Heiko Schocher
Add Startek KD070WVFPA043-C069A 7" TFT LCD panel support.
Signed-off-by: Heiko Schocher
Signed-off-by: Fabio Estevam
---
drivers/gpu/drm/panel/panel-simple.c | 33
1 file changed, 33 insertions(+)
diff --git
From: Fabio Estevam
Add Startek KD070WVFPA043-C069A 7" TFT LCD panel compatible string.
Signed-off-by: Fabio Estevam
---
.../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git
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.
Also, we need to call pm_runtime_put_noidle() when pm_runtime_get_sync()
fails, so use pm_runtime_resume_and_get() instead. this function
i915_vma_reopen checked if the vma is closed before without taking the
lock. So multiple threads could attempt removing the vma.
Instead the lock needs to be taken before actually checking.
Cc: Chris Wilson
Cc: intel-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Closes:
On Tue, Apr 12, 2022 at 3:30 AM Patrik Jakobsson
wrote:
>
> On Tue, Apr 12, 2022 at 3:48 AM James Hilliard
> wrote:
> >
> > On Mon, Apr 11, 2022 at 3:27 AM Patrik Jakobsson
> > wrote:
> > >
> > > On Sun, Apr 10, 2022 at 10:05 PM James Hilliard
> > > wrote:
> > > >
> > > > On Sun, Apr 10, 2022
The current compatible strings for SSD130x I2C controllers contain both an
"fb" and "-i2c" suffixes. It seems to indicate that are for a fbdev driver
and also that are for devices that can be accessed over an I2C bus.
But a DT is supposed to describe the hardware and not Linux implementation
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 4-wire SPI
instead of I2C. For the latter, a control byte that contains a D/C# field
The current compatible strings for SSD130x I2C controllers contain an "fb"
and "-i2c" suffixes. These have been deprecated and more correct ones were
added, that don't encode a subsystem or bus used to interface the devices.
Signed-off-by: Javier Martinez Canillas
Acked-by: Mark Brown
These are declared in the ssd130x-i2c transport driver but the information
is not I2C specific, and could be used by other SSD130x transport drivers.
Move them to the ssd130x core driver and just set the OF device entries to
an ID that could be used to lookup the correct device info from an
The Solomon SSD130x OLED displays can either have an I2C or SPI interface,
add to the schema the properties and examples for OLED devices under SPI.
Signed-off-by: Javier Martinez Canillas
Acked-by: Mark Brown
Reviewed-by: Geert Uytterhoeven
---
(no changes since v4)
Changes in v4:
- Add a
Hello,
This series adds a ssd130x-spi driver that provides a 4-wire SPI transport
support for SSD130x OLED controllers that can be accessed over a SPI bus.
The driver is quite similar to existing ssd130x-i2c driver that is used by
I2C controllers, but there is a difference in the protocol used
Hi Paul,
On 4/14/2022 2:52 AM, Paul Menzel wrote:
[Cc: -kernel test robot ]
Dear Alex, dear Richard,
Am 13.04.22 um 15:00 schrieb Alex Deucher:
On Wed, Apr 13, 2022 at 3:43 AM Paul Menzel wrote:
Thank you for sending out v4.
Am 12.04.22 um 23:50 schrieb Richard Gong:
Active State Power
typo in the subject
pannel --> panel
Otherwise,
Reviewed-by: Abhinav Kumar
On 4/19/2022 2:37 PM, Dmitry Baryshkov wrote:
Unable to handle kernel paging request at virtual address fe2b
Mem abort info:
ESR = 0x9604
EC = 0x25: DABT (current EL), IL = 32 bits
SET = 0,
Unable to handle kernel paging request at virtual address fe2b
Mem abort info:
ESR = 0x9604
EC = 0x25: DABT (current EL), IL = 32 bits
SET = 0, FnV = 0
EA = 0, S1PTW = 0
FSC = 0x04: level 0 translation fault
Data abort info:
ISV = 0, ISS = 0x0004
CM = 0, WnR = 0
On 2022-04-19 22:08, Dmitry Baryshkov wrote:
On 20/04/2022 00:04, Robin Murphy wrote:
On 2022-04-19 14:04, Dmitry Baryshkov wrote:
This reverts commit e2a88eabb02410267519b838fb9b79f5206769be. The commit
in question makes msm_use_mmu() check whether the DRM 'component master'
device is
Hi Nathan,
On 4/13/2022 10:40 AM, Nathan Chancellor wrote:
Hi Richard,
On Tue, Apr 12, 2022 at 04:50:00PM -0500, Richard Gong wrote:
Active State Power Management (ASPM) feature is enabled since kernel 5.14.
There are some AMD GFX cards (such as WX3200 and RX640) that won't work
with
On 20/04/2022 00:04, Robin Murphy wrote:
On 2022-04-19 14:04, Dmitry Baryshkov wrote:
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
On 2022-04-19 14:04, Dmitry Baryshkov wrote:
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
On 4/6/2022 2:40 AM, Vinod Koul wrote:
From: Dmitry Baryshkov
DPU supports different topologies for the case when multiple INTFs are
being driven by the single phys_enc. The driver defaults to using 3DMux
in such cases. Don't use it if DSC merge is used instead.
Suggested-by: Abhinav Kumar
On 4/19/22 10:22, Thomas Zimmermann wrote:
> 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
The Board of Directors election and the vote on the By-laws concluded at
23:59 UTC on 18 April 2022. There are 80 current Members of the X.Org
Foundation, and 52 Members cast votes. This is a 65.0% turn out.
In the election of the Directors to the Board of the X.Org Foundation,
the results were
On 4/14/2022 5:24 PM, Dmitry Baryshkov wrote:
On 15/04/2022 01:16, Abhinav Kumar wrote:
On 2/4/2022 3:19 PM, Dmitry Baryshkov wrote:
On 05/02/2022 00:17, Abhinav Kumar wrote:
Introduce the dpu_encoder_phys_* for the writeback interface
to handle writeback specific hardware programming.
Removed an unnecessary semicolon at the end of a macro call
Signed-off-by: Ian Cowan
---
drivers/staging/fbtft/fbtft.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/fbtft/fbtft.h b/drivers/staging/fbtft/fbtft.h
index 2c2b5f1c1df3..aa66760e1a9c 100644
---
Quoting Biju Das (2022-04-19 15:24:53)
> 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
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: 634de1db0e9bbeb90d7b01020e59ec3dab4d38a1 Add linux-next specific
files for 20220419
Error/Warning reports:
https://lore.kernel.org/linux-mm/202204081656.6x4pfen4-...@intel.com
https
On 4/19/22 09:37, Arnd Bergmann wrote:
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:
You might want to drop this one, it seems to be causing some issues on
older generations.. I'll be sending another PR shortly with a revert.
https://patchwork.freedesktop.org/patch/482453
BR,
-R
On Tue, Apr 19, 2022 at 11:15 AM Sasha Levin wrote:
>
> From: Robin Murphy
>
> [ Upstream commit
From: Xiaoke Wang
[ Upstream commit 047ae66556b7feb11bd4f81f46627cff95e7 ]
kzalloc() is a memory allocation function which can return NULL when
some internal memory errors happen. So it is better to check it to
prevent potential wrong memory access.
Besides, since mdp5_plane_reset() is
From: Xiaoke Wang
[ Upstream commit 047ae66556b7feb11bd4f81f46627cff95e7 ]
kzalloc() is a memory allocation function which can return NULL when
some internal memory errors happen. So it is better to check it to
prevent potential wrong memory access.
Besides, since mdp5_plane_reset() is
From: Xiaoke Wang
[ Upstream commit 047ae66556b7feb11bd4f81f46627cff95e7 ]
kzalloc() is a memory allocation function which can return NULL when
some internal memory errors happen. So it is better to check it to
prevent potential wrong memory access.
Besides, since mdp5_plane_reset() is
From: Robin Murphy
[ Upstream commit e2a88eabb02410267519b838fb9b79f5206769be ]
Even if some IOMMU has registered itself on the platform "bus", that
doesn't necessarily mean it provides translation for the device we
care about. Replace iommu_present() with a more appropriate check.
From: Xiaoke Wang
[ Upstream commit 047ae66556b7feb11bd4f81f46627cff95e7 ]
kzalloc() is a memory allocation function which can return NULL when
some internal memory errors happen. So it is better to check it to
prevent potential wrong memory access.
Besides, since mdp5_plane_reset() is
From: Robin Murphy
[ Upstream commit e2a88eabb02410267519b838fb9b79f5206769be ]
Even if some IOMMU has registered itself on the platform "bus", that
doesn't necessarily mean it provides translation for the device we
care about. Replace iommu_present() with a more appropriate check.
From: Xiaoke Wang
[ Upstream commit 047ae66556b7feb11bd4f81f46627cff95e7 ]
kzalloc() is a memory allocation function which can return NULL when
some internal memory errors happen. So it is better to check it to
prevent potential wrong memory access.
Besides, since mdp5_plane_reset() is
From: Robin Murphy
[ Upstream commit e2a88eabb02410267519b838fb9b79f5206769be ]
Even if some IOMMU has registered itself on the platform "bus", that
doesn't necessarily mean it provides translation for the device we
care about. Replace iommu_present() with a more appropriate check.
From: Xiaoke Wang
[ Upstream commit 047ae66556b7feb11bd4f81f46627cff95e7 ]
kzalloc() is a memory allocation function which can return NULL when
some internal memory errors happen. So it is better to check it to
prevent potential wrong memory access.
Besides, since mdp5_plane_reset() is
From: Xiaoke Wang
[ Upstream commit f75e582b0c3ee8f0bddc2248cc8b9175f29c5937 ]
kzalloc() is a memory allocation function which can return NULL when
some internal memory errors happen. So it is better to check it to
prevent potential wrong memory access.
Signed-off-by: Xiaoke Wang
Reviewed-by:
From: Robin Murphy
[ Upstream commit e2a88eabb02410267519b838fb9b79f5206769be ]
Even if some IOMMU has registered itself on the platform "bus", that
doesn't necessarily mean it provides translation for the device we
care about. Replace iommu_present() with a more appropriate check.
From: Xiaoke Wang
[ Upstream commit 047ae66556b7feb11bd4f81f46627cff95e7 ]
kzalloc() is a memory allocation function which can return NULL when
some internal memory errors happen. So it is better to check it to
prevent potential wrong memory access.
Besides, since mdp5_plane_reset() is
From: Xiaoke Wang
[ Upstream commit f75e582b0c3ee8f0bddc2248cc8b9175f29c5937 ]
kzalloc() is a memory allocation function which can return NULL when
some internal memory errors happen. So it is better to check it to
prevent potential wrong memory access.
Signed-off-by: Xiaoke Wang
Reviewed-by:
From: Rob Clark
[ Upstream commit 7242795d520d3fb48e005e3c96ba54bb59639d6e ]
The mutex wasn't really protecting anything before. Before the previous
patch we could still be racing with the scheduler's kthread, as that is
not necessarily frozen yet. Now that we've parked the sched threads,
the
From: Rob Clark
[ Upstream commit f7eab1ddb9f8bc99206e3efa8d34ca1d2faca209 ]
Signed-off-by: Rob Clark
Link: https://lore.kernel.org/r/20220310234611.424743-2-robdcl...@gmail.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/msm/adreno/adreno_device.c | 6 +++---
1 file changed, 3
On Tue, Apr 19, 2022 at 06:16:07PM +0200, Robert Foss wrote:
> 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
On Thu, 7 Apr 2022 at 20:56, Marek Vasut wrote:
>
> The driver currently hard-codes DSI lane count to two, however the chip
> is capable of operating in 1..4 DSI lanes mode. Parse 'data-lanes' DT
> property and program the result into DSI_CTRL register.
>
> Signed-off-by: Marek Vasut
> Cc: Jagan
On Fri, 8 Apr 2022 at 10:21, AngeloGioacchino Del Regno
wrote:
>
> Il 08/04/22 03:30, Nícolas F. R. A. Prado ha scritto:
> > As defined in the anx7625 dt-binding, the analogix,lane0-swing and
> > analogix,lane1-swing properties are uint8 arrays. Yet, the driver was
> > reading the array as if it
On Mon, Apr 18, 2022 at 11:25:15AM -0400, Jason J. Herne wrote:
> 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
Adds support to AFFINE image processing accelerator on Toshiba Visconti ARM
SoCs.
This accelerator supoorts affine transform, lens undistortion and LUT transform.
Signed-off-by: Yuji Ishikawa
Reviewed-by: Nobuhiro Iwamatsu
---
drivers/soc/visconti/Kconfig | 6 +
Adds the Device Tree binding documentation that allows to describe
the AFFINE image processing accelerator found in Toshiba Visconti SoCs.
Signed-off-by: Yuji Ishikawa
Reviewed-by: Nobuhiro Iwamatsu
---
.../soc/visconti/toshiba,visconti-affine.yaml | 53 +++
1 file changed, 53
This series is the AFFINE image processing accelerator driver for Toshiba's ARM
SoC, Visconti[0].
This provides DT binding documentation, device driver, MAINTAINER files.
Best regards,
Yuji
[0]:
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
freed again in si_dpm_fini() function which is called when the function
returns an
Signed-off-by: Yuji Ishikawa
Reviewed-by: Nobuhiro Iwamatsu
---
MAINTAINERS | 2 ++
1 file changed, 2 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index dd36acc87..231b2c6f9 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2796,12 +2796,14 @@ F:
Adds common operations for image processing accelerator drivers
including dma-buf control and ioctl definitiion
Signed-off-by: Yuji Ishikawa
Reviewed-by: Nobuhiro Iwamatsu
---
drivers/soc/Kconfig | 1 +
drivers/soc/Makefile | 1 +
drivers/soc/visconti/Kconfig
Hi Paul,
Le jeu., avril 7 2022 at 11:34:08 +0200, Paul Kocialkowski
a écrit :
With the previous rework of drm_of_find_panel_or_bridge only
-EPROBE_DEFER is returned while previous behavior allowed -ENODEV
to be returned when the port/endpoint is either missing or
unavailable.
Make the
From: Arnd Bergmann
PXA is now ready to be built into a single kernel with all the
other ARMv5 platforms, so change the Kconfig bit to finish it
off. The mach/uncompress.h support is the last bit that goes away,
getting replaced with the normal DEBUG_LL based approach.
Signed-off-by: Arnd
From: Arnd Bergmann
Using MTD-XIP does not work on multiplatform kernels because
it requires SoC specific register accesses to be done from
low-level flash handling functions in RAM while the rest of the
kernel sits in flash.
I found no evidence of anyone still actually using this feature,
so
From: Arnd Bergmann
None of the headers are included from outside of the mach-pxa
directory, so move them all in there.
Signed-off-by: Arnd Bergmann
---
arch/arm/mach-pxa/am300epd.c | 2 +-
arch/arm/mach-pxa/balloon3.h | 2 +-
From: Arnd Bergmann
On a kernel that includes both ARMv4 and XScale support,
the copypage function fails to build with invalid
instructions.
Since these are only called on an actual XScale processor,
annotate the assembly with the correct .arch directive.
Signed-off-by: Arnd Bergmann
---
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
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 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
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 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
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
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
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
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
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: 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 -
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 for
1 - 100 of 241 matches
Mail list logo
