Kuogee Hsieh [Fri, 1 Dec 2023 23:19:43 +0000 (15:19 -0800)]
drm/msm/dp: tie dp_display_irq_handler() with dp driver
Currently the dp_display_request_irq() is executed at
msm_dp_modeset_init() which ties irq registering to the DPU device's
life cycle, while depending on resources that are released as the DP
device is torn down. Move register DP driver irq handler to
dp_display_probe() to have dp_display_irq_handler() IRQ tied with DP
device. In addition, use platform_get_irq() to retrieve irq number
from platform device directly.
Changes in v5:
-- reworded commit text as review comments at change #4
-- tear down component if failed at dp_display_request_irq()
Changes in v4:
-- delete dp->irq check at dp_display_request_irq()
Changes in v3:
-- move calling dp_display_irq_handler() to probe
Konrad Dybcio [Wed, 29 Nov 2023 14:43:59 +0000 (15:43 +0100)]
dt-bindings: display: msm: Add reg bus and rotator interconnects
Apart from the already handled data bus (MAS_MDP_Pn<->DDR), there are
other connection paths:
- a path that connects rotator block to the DDR.
- a path that needs to be handled to ensure MDSS register access
functions properly, namely the "reg bus", a.k.a the CPU-MDSS CFG
interconnect.
Describe these paths to allow using them in device trees and in the
driver.
Konrad Dybcio [Wed, 29 Nov 2023 14:43:58 +0000 (15:43 +0100)]
dt-bindings: display: msm: qcm2290-mdss: Use the non-deprecated DSI compat
The "qcom,dsi-ctrl-6g-qcm2290" has been deprecated in
commit 0c0f65c6dd44 ("dt-bindings: msm: dsi-controller-main: Add
compatible strings for every current SoC"), but the example hasn't been
updated to reflect that.
Dmitry Baryshkov [Thu, 19 Oct 2023 10:44:19 +0000 (13:44 +0300)]
drm/msm/dp: cleanup debugfs handling
Currently there are two subdirs for DP debugfs files, e.g. DP-1, created
by the drm core for the connector, and the msm_dp-DP-1, created by the
DP driver itself. Merge those two, so that there are no extraneous
connector-related subdirs.
Jessica Zhang [Fri, 27 Oct 2023 22:32:53 +0000 (15:32 -0700)]
drm: Add solid fill pixel source
Add "SOLID_FILL" as a valid pixel source. If the pixel_source property is
set to "SOLID_FILL", it will display data from the drm_plane "solid_fill"
blob property.
Jessica Zhang [Fri, 27 Oct 2023 22:32:51 +0000 (15:32 -0700)]
drm: Introduce pixel_source DRM plane property
Add support for pixel_source property to drm_plane and related
documentation. In addition, force pixel_source to
DRM_PLANE_PIXEL_SOURCE_FB in DRM_IOCTL_MODE_SETPLANE as to not break
legacy userspace.
This enum property will allow user to specify a pixel source for the
plane. Possible pixel sources will be defined in the
drm_plane_pixel_source enum.
Currently, the only pixel sources are DRM_PLANE_PIXEL_SOURCE_FB (the
default value) and DRM_PLANE_PIXEL_SOURCE_NONE.
drm/msm/dpu: try multirect based on mdp clock limits
It's certainly possible that for large resolutions a single DPU SSPP
cannot process the image without exceeding the MDP clock limits but
it can still process it in multirect mode because the source rectangles
will get divided and can fall within the MDP clock limits.
If the SSPP cannot process the image even in multirect mode, then it
will be rejected in dpu_plane_atomic_check_pipe().
Hence try using multirect for resolutions which cannot be processed
by a single SSPP without exceeding the MDP clock limits.
changes in v2:
- use crtc_state's adjusted_mode instead of mode
- fix the UBWC condition to check maxlinewidth
Rob Clark [Wed, 23 Aug 2023 21:54:56 +0000 (14:54 -0700)]
dma-buf/sw_sync: Add fence deadline support
This consists of simply storing the most recent deadline, and adding an
ioctl to retrieve the deadline. This can be used in conjunction with
the SET_DEADLINE ioctl on a fence fd for testing. Ie. create various
sw_sync fences, merge them into a fence-array, set deadline on the
fence-array and confirm that it is propagated properly to each fence.
v2: Switch UABI to express deadline as u64
v3: More verbose UAPI docs, show how to convert from timespec
v4: Better comments, track the soonest deadline, as a normal fence
implementation would, return an error if no deadline set.
Rob Clark [Wed, 23 Aug 2023 21:54:55 +0000 (14:54 -0700)]
dma-buf/sync_file: Add SET_DEADLINE ioctl
The initial purpose is for igt tests, but this would also be useful for
compositors that wait until close to vblank deadline to make decisions
about which frame to show.
Rob Clark [Wed, 23 Aug 2023 21:54:54 +0000 (14:54 -0700)]
drm/syncobj: Add deadline support for syncobj waits
Add a new flag to let userspace provide a deadline as a hint for syncobj
and timeline waits. This gives a hint to the driver signaling the
backing fences about how soon userspace needs it to compete work, so it
can adjust GPU frequency accordingly. An immediate deadline can be
given to provide something equivalent to i915 "wait boost".
v2: Use absolute u64 ns value for deadline hint, drop cap and driver
feature flag in favor of allowing count_handles==0 as a way for
userspace to probe kernel for support of new flag
v3: More verbose comments about UAPI
v4: Fix negative zero, s/deadline_ns/deadline_nsec/ for consistency with
existing ioctl struct fields
v5: Comment/description typo fixes
Carl Vanderlip [Fri, 17 Nov 2023 17:43:37 +0000 (10:43 -0700)]
accel/qaic: Expand DRM device lifecycle
Currently the QAIC DRM device registers itself when the MHI QAIC_CONTROL
channel becomes available. This is when the device is able to process
workloads. However, the DRM driver also provides the debugfs interface
bootlog for the device. If the device fails to boot to the QSM (which
brings up the MHI QAIC_CONTROL channel), the bootlog won't be available for
debugging why it failed to boot.
Change when the DRM device registers itself from when QAIC_CONTROL is
available to when the card is first probed on the PCI bus. Additionally,
make the DRM driver persist through reset/error cases so the driver
doesn't have to be reloaded to access the card again. Send
KOBJ_ONLINE/OFFLINE uevents so userspace can know when DRM device is
ready to handle requests.
Carl Vanderlip [Fri, 17 Nov 2023 17:43:36 +0000 (10:43 -0700)]
accel/qaic: Increase number of in_reset states
'in_reset' holds the state of the device. As part of bringup, the device
needs to be queried to check if it's in a valid state. Add a new state
that indicates that the device is coming up, but not ready for users
yet. Rename to 'dev_state' to better describe the variable.
Maíra Canal [Thu, 30 Nov 2023 16:40:40 +0000 (13:40 -0300)]
drm/v3d: Create a CPU job extension for the copy performance query job
A CPU job is a type of job that performs operations that requires CPU
intervention. A copy performance query job is a job that copy the complete
or partial result of a query to a buffer. In order to copy the result of
a performance query to a buffer, we need to get the values from the
performance monitors.
So, create a user extension for the CPU job that enables the creation
of a copy performance query job. This user extension will allow the creation
of a CPU job that copy the results of a performance query to a BO with the
possibility to indicate the availability with a availability bit.
Maíra Canal [Thu, 30 Nov 2023 16:40:39 +0000 (13:40 -0300)]
drm/v3d: Create a CPU job extension for the reset performance query job
A CPU job is a type of job that performs operations that requires CPU
intervention. A reset performance query job is a job that resets the
performance queries by resetting the values of the perfmons. Moreover,
we also reset the syncobjs related to the availability of the query.
So, create a user extension for the CPU job that enables the creation
of a reset performance job. This user extension will allow the creation of
a CPU job that resets the perfmons values and resets the availability syncobj.
Maíra Canal [Thu, 30 Nov 2023 16:40:38 +0000 (13:40 -0300)]
drm/v3d: Create a CPU job extension to copy timestamp query to a buffer
A CPU job is a type of job that performs operations that requires CPU
intervention. A copy timestamp query job is a job that copy the complete
or partial result of a query to a buffer. As V3D doesn't provide any
mechanism to obtain a timestamp from the GPU, it is a job that needs
CPU intervention.
So, create a user extension for the CPU job that enables the creation
of a copy timestamp query job. This user extension will allow the creation
of a CPU job that copy the results of a timestamp query to a BO with the
possibility to indicate the timestamp availability with a availability bit.
Maíra Canal [Thu, 30 Nov 2023 16:40:37 +0000 (13:40 -0300)]
drm/v3d: Create a CPU job extension for the reset timestamp job
A CPU job is a type of job that performs operations that requires CPU
intervention. A reset timestamp job is a job that resets the timestamp
queries based on the value offset of the first query. As V3D doesn't
provide any mechanism to obtain a timestamp from the GPU, it is a job
that needs CPU intervention.
So, create a user extension for the CPU job that enables the creation
of a reset timestamp job. This user extension will allow the creation of
a CPU job that resets the timestamp value in the timestamp BO and resets
the availability syncobj.
Maíra Canal [Thu, 30 Nov 2023 16:40:36 +0000 (13:40 -0300)]
drm/v3d: Create a CPU job extension for the timestamp query job
A CPU job is a type of job that performs operations that requires CPU
intervention. A timestamp query job is a job that calculates the
query timestamp and updates the query availability by signaling a
syncobj. As V3D doesn't provide any mechanism to obtain a timestamp
from the GPU, it is a job that needs CPU intervention.
So, create a user extension for the CPU job that enables the creation
of a timestamp query job. This user extension will allow the creation of
a CPU job that performs the timestamp query calculation and updates the
timestamp BO with the proper value.
Maíra Canal [Thu, 30 Nov 2023 16:40:35 +0000 (13:40 -0300)]
drm/v3d: Create a CPU job extension for a indirect CSD job
A CPU job is a type of job that performs operations that requires CPU
intervention. An indirect CSD job is a job that, when executed in the
queue, will map the indirect buffer, read the dispatch parameters, and
submit a regular dispatch. Therefore, it is a job that needs CPU
intervention.
So, create a user extension for the CPU job that enables the creation
of an indirect CSD. This user extension will allow the creation of a CSD
job linked to a CPU job. The CPU job will wait for the indirect CSD job
dependencies and, once they are signaled, it will update the CSD job
parameters.
Maíra Canal [Thu, 30 Nov 2023 16:40:34 +0000 (13:40 -0300)]
drm/v3d: Enable BO mapping
For the indirect CSD CPU job, we will need to access the internal
contents of the BO with the dispatch parameters. Therefore, create
methods to allow the mapping and unmapping of the BO.
Maíra Canal [Thu, 30 Nov 2023 16:40:32 +0000 (13:40 -0300)]
drm/v3d: Create tracepoints to track the CPU job
Create tracepoints to track the three major events of a CPU job
lifetime:
1. Submission of a `v3d_submit_cpu` IOCTL
2. Beginning of the execution of a CPU job
3. Ending of the execution of a CPU job
Maíra Canal [Thu, 30 Nov 2023 16:40:31 +0000 (13:40 -0300)]
drm/v3d: Use v3d_get_extensions() to parse CPU job data
Currently, v3d_get_extensions() only parses multisync data and assigns
it to the `struct v3d_submit_ext`. But, to implement the CPU job with
user extensions, we want v3d_get_extensions() to be able to parse CPU
job data and assign it to the `struct v3d_cpu_job`.
Therefore, allow the function v3d_get_extensions() to use `struct v3d_cpu_job *`
as a parameter. If the `struct v3d_cpu_job *` is assigned to NULL, it means
that the job is a GPU job and CPU job extensions should be rejected.
Melissa Wen [Thu, 30 Nov 2023 16:40:30 +0000 (13:40 -0300)]
drm/v3d: Add a CPU job submission
Create a new type of job, a CPU job. A CPU job is a type of job that
performs operations that requires CPU intervention. The overall idea is
to use user extensions to enable different types of CPU job, allowing the
CPU job to perform different operations according to the type of user
extension. The user extension ID identify the type of CPU job that must
be dealt.
Having a CPU job is interesting for synchronization purposes as a CPU
job has a queue like any other V3D job and can be synchoronized by the
multisync extension.
Maíra Canal [Thu, 30 Nov 2023 16:40:29 +0000 (13:40 -0300)]
drm/v3d: Decouple job allocation from job initiation
We want to allow the IOCTLs to allocate the job without initiating it.
This will be useful for the CPU job submission IOCTL, as the CPU job has
the need to use information from the user extensions. Currently, the
user extensions are parsed before the job allocation, making it
impossible to fill the CPU job when parsing the user extensions.
Therefore, decouple the job allocation from the job initiation.
Maíra Canal [Thu, 30 Nov 2023 16:40:28 +0000 (13:40 -0300)]
drm/v3d: Don't allow two multisync extensions in the same job
Currently, two multisync extensions can be added to the same job and
only the last multisync extension will be used. To avoid this
vulnerability, don't allow two multisync extensions in the same job.
Melissa Wen [Thu, 30 Nov 2023 16:40:26 +0000 (13:40 -0300)]
drm/v3d: Detach job submissions IOCTLs to a new specific file
We will include a new job submission type, the CPU job submission. For
readability and maintability, separate the job submission IOCTLs and
related operations from v3d_gem.c.
Minor fix in the CSD submission kernel doc:
CSD (texture formatting) -> CSD (compute shader).
Melissa Wen [Thu, 30 Nov 2023 16:40:25 +0000 (13:40 -0300)]
drm/v3d: Move wait BO ioctl to the v3d_bo file
IOCTLs related to BO operations reside on the file v3d_bo.c. The wait BO
ioctl is the only IOCTL regarding BOs that is placed in a different file.
So, move it to the v3d_bo.c file.
Tomi Valkeinen [Thu, 9 Nov 2023 07:38:04 +0000 (09:38 +0200)]
drm/tidss: Use DRM_PLANE_COMMIT_ACTIVE_ONLY
At the moment the driver does not use DRM_PLANE_COMMIT_ACTIVE_ONLY, but
still checks for crtc->state->active in tidss_crtc_atomic_flush(), and
skips the flush if the crtc is not active.
The exact reason why DRM_PLANE_COMMIT_ACTIVE_ONLY is not used has been
lost in history. DRM_PLANE_COMMIT_ACTIVE_ONLY does also affect the plane
updates, and I think the issue was related to multi-display systems and
moving planes between the displays. However, it is possible the issue
was only present on the older DSS hardware, handled by the omapdrm
driver (on which the tidss driver is loosely based).
Reviewing the code related to DRM_PLANE_COMMIT_ACTIVE_ONLY does not show
any issues, and testing on J7 EVM with two displays works fine.
Change the driver to use DRM_PLANE_COMMIT_ACTIVE_ONLY.
Tomi Valkeinen [Thu, 9 Nov 2023 07:38:03 +0000 (09:38 +0200)]
drm/tidss: Fix atomic_flush check
tidss_crtc_atomic_flush() checks if the crtc is enabled, and if not,
returns immediately as there's no reason to do any register changes.
However, the code checks for 'crtc->state->enable', which does not
reflect the actual HW state. We should instead look at the
'crtc->state->active' flag.
This causes the tidss_crtc_atomic_flush() to proceed with the flush even
if the active state is false, which then causes us to hit the
WARN_ON(!crtc->state->event) check.
Fix this by checking the active flag, and while at it, fix the related
debug print which had "active" and "needs modeset" wrong way.
Tomi Valkeinen [Thu, 9 Nov 2023 07:38:02 +0000 (09:38 +0200)]
drm/tidss: IRQ code cleanup
The IRQ setup code is overly complex. All we really need to do is
initialize the related fields in struct tidss_device, and request the
IRQ.
We can drop all the HW accesses, as they are pointless: the driver will
set the IRQs correctly when it needs any of the IRQs, and at probe time
we have done a reset, so we know that all the IRQs are masked by default
in the hardware.
Thus we can combine the tidss_irq_preinstall() and
tidss_irq_postinstall() into the tidss_irq_install() function, drop the
HW accesses, and drop the use of spinlock, as this is done at init time
and there can be no races.
We can also drop the HW access from the tidss_irq_uninstall(), as the
driver will anyway disable and suspend the hardware at remove time.
Tomi Valkeinen [Thu, 9 Nov 2023 07:38:01 +0000 (09:38 +0200)]
drm/tidss: Fix dss reset
The probe function calls dispc_softreset() before runtime PM is enabled
and without enabling any of the DSS clocks. This happens to work by
luck, and we need to make sure the DSS HW is active and the fclk is
enabled.
To fix the above, add a new function, dispc_init_hw(), which does:
This ensures that the reset can be successfully accomplished.
Note that we use pm_runtime_set_active(), not the normal
pm_runtime_get(). The reason for this is that at this point we haven't
enabled the runtime PM yet and also we don't want the normal resume
callback to be called: the dispc resume callback does some initial HW
setup, and it expects that the HW was off (no video ports are
streaming). If the bootloader has enabled the DSS and has set up a
boot time splash-screen, the DSS would be enabled and streaming which
might lead to issues with the normal resume callback.
Tomi Valkeinen [Thu, 9 Nov 2023 07:37:59 +0000 (09:37 +0200)]
drm/tidss: Check for K2G in in dispc_softreset()
K2G doesn't have softreset feature. Instead of having every caller of
dispc_softreset() check for K2G, move the check into dispc_softreset(),
and make dispc_softreset() return 0 in case of K2G.
Tomi Valkeinen [Thu, 9 Nov 2023 07:37:57 +0000 (09:37 +0200)]
drm/tidss: Move reset to the end of dispc_init()
We do a DSS reset in the middle of the dispc_init(). While that happens
to work now, we should really make sure that e..g the fclk, which is
acquired only later in the function, is enabled when doing a reset. This
will be handled in a later patch, but for now, let's move the
dispc_softreset() call to the end of dispc_init(), which is a sensible
place for it anyway.
Tomi Valkeinen [Thu, 9 Nov 2023 07:37:55 +0000 (09:37 +0200)]
drm/tidss: Use PM autosuspend
Use runtime PM autosuspend feature, with 1s timeout, to avoid
unnecessary suspend-resume cycles when, e.g. the userspace temporarily
turns off the crtcs when configuring the outputs.
Tomi Valkeinen [Thu, 9 Nov 2023 07:37:54 +0000 (09:37 +0200)]
drm/tidss: Use pm_runtime_resume_and_get()
Use pm_runtime_resume_and_get() instead of pm_runtime_get_sync(), which
will handle error situations better. Also fix the return, as there
should be no reason for the current complex return.
Aradhya Bhatia [Wed, 8 Nov 2023 17:16:19 +0000 (22:46 +0530)]
drm/tidss: Add support for AM62A7 DSS
Add support for the DSS controller on TI's AM62A7 SoC in the tidss
driver.
This controller has 2 video pipelines that can render 2 video planes on
over a screen, using the overlay managers. The output of the DSS comes
from video port 2 (VP2) in the form of RGB88 DPI signals, while the VP1
is tied off inside the SoC.
Also add and use a new type of VP, DISPC_VP_TIED_OFF, for the tied-off
VP1 of AM62A DSS.
Aradhya Bhatia [Wed, 8 Nov 2023 17:16:18 +0000 (22:46 +0530)]
dt-bindings: display: ti: Add support for am62a7 dss
The DSS controller on TI's AM62A7 SoC is an update from that on TI's
AM625 SoC. Like the DSS in AM625, the DSS in this SoC has 2 video
pipelines, but unlike the former, the latter only has one output port on
VP2 to service DPI display sinks.
Andrew Davis [Mon, 13 Nov 2023 20:55:01 +0000 (14:55 -0600)]
drm/omapdrm: Improve check for contiguous buffers
While a scatter-gather table having only 1 entry does imply it is
contiguous, it is a logic error to assume the inverse. Tables can have
more than 1 entry and still be contiguous. Use a proper check here.
Dan Carpenter [Thu, 30 Nov 2023 07:27:15 +0000 (10:27 +0300)]
drm/imagination: fix off by one in pvr_vm_mips_init() error handling
If the call to vmap() fails the "page_nr" is one element beyond the end
of the mips_data->pt_dma_addr[] and mips_data->pt_pages[] arrays.
The way that this is traditionally written is that we clean up the
partial loop iteration before the goto and then we can say
while (--i >= 0). At that point we know that all the elements thus
far are initialized so we don't need to have NULL checks.
Yuran Pereira [Thu, 16 Nov 2023 20:52:00 +0000 (02:22 +0530)]
drm/nouveau: Removes unnecessary args check in nouveau_uvmm_sm_prepare
Checking `args` after calling `op_map_prepare` is unnecessary since
if `op_map_prepare` was to be called with NULL args, it would lead
to a NULL pointer dereference, thus never hitting that check.
Hence remove the check and add a note to remind users of this function
to ensure that args != NULL when calling this function for a map
operation as it was suggested by Danilo [1].
Thomas Hellström [Wed, 29 Nov 2023 09:06:37 +0000 (10:06 +0100)]
Documentation/gpu: VM_BIND locking document
Add the first version of the VM_BIND locking document which is
intended to be part of the xe driver upstreaming agreement.
The document describes and discuss the locking used during exec-
functions, evicton and for userptr gpu-vmas. Intention is to be using the
same nomenclature as the drm-vm-bind-async.rst.
v2:
- s/gvm/gpu_vm/g (Rodrigo Vivi)
- Clarify the userptr seqlock with a pointer to mm/mmu_notifier.c
(Rodrigo Vivi)
- Adjust commit message accordingly.
- Add SPDX license header.
v3:
- Large update to align with the drm_gpuvm manager locking
- Add "Efficient userptr gpu_vma exec function iteration" section
- Add "Locking at bind- and unbind time" section.
v4:
- Fix tabs vs space errors by untabifying (Rodrigo Vivi)
- Minor style fixes and typos (Rodrigo Vivi)
- Clarify situations where stale GPU mappings are occurring and how
access through these mappings are blocked. (Rodrigo Vivi)
- Insert into the toctree in implementation_guidelines.rst
v5:
- Add a section about recoverable page-faults.
- Use local references to other documentation where possible
(Bagas Sanjaya)
- General documentation fixes and typos (Danilo Krummrich and
Boris Brezillon)
- Improve the documentation around locks that need to be grabbed from the
dm-fence critical section (Boris Brezillon)
- Add more references to the DRM GPUVM helpers (Danilo Krummrich and
Boriz Brezillon)
- Update the rfc/xe.rst document.
v6:
- Rework wording to improve readability (Boris Brezillon, Rodrigo Vivi,
Bagas Sanjaya)
- Various minor fixes across the document (Boris Brezillon)
Drop the default implementations for file read, write and mmap
operations. Each fbdev driver must now provide an implementation
and select any necessary helpers. If no implementation has been
set, fbdev returns an errno code to user space. The code is the
same as if the operation had not been set in the file_operations
struct.
This change makes the fbdev helpers for I/O memory optional. Most
systems only use system-memory framebuffers via DRM's fbdev emulation.
v2:
* warn once if I/O callbacks are missing (Javier)
Test in framebuffer read, write and drawing helpers if FBINFO_VIRTFB
has been set correctly. Framebuffers in I/O memory should only be
accessed with the architecture's respective helpers. Framebuffers
in system memory should be accessed with the regular load and
store operations. Presumably not all drivers get this right, so we
now warn about it.
fbdev: Move default fb_mmap code into helper function
Move the default fb_mmap code for I/O address spaces into the helper
function fb_io_mmap(). The helper can either be called via struct
fb_ops.fb_mmap or as the default if no fb_mmap has been set. Also
set the new helper in __FB_DEFAULT_IOMEM_OPS_MMAP.
In the mid-term, fb_io_mmap() is supposed to become optional. Fbdev
drivers will initialize their struct fb_ops.fb_mmap to the helper
and select a corresponding Kconfig token. The helper can then be made
optional at compile time.
fbdev: Push pgprot_decrypted() into mmap implementations
If a driver sets struct fb_ops.fb_mmap, the fbdev core automatically
calls pgprot_decrypted(). But the default fb_mmap code doesn't handle
pgprot_decrypted().
Move the call to pgprot_decrypted() into each drivers' fb_mmap function.
This only concerns fb_mmap functions for system and DMA memory. For
I/O memory, which is the default case, nothing changes. The fb_mmap
for I/O-memory can later be moved into a helper as well.
DRM's fbdev emulation handles pgprot_decrypted() internally via the
Prime helpers. Fbdev doesn't have to do anything in this case. In
cases where DRM uses deferred I/O, this patch updates fb_mmap correctly.
staging/sm750fb: Initialize fb_ops with fbdev macros
Initialize all instances of struct fb_ops with fbdev initializer
macros for framebuffers in I/O address space. Set the read/write,
draw and mmap callbacks to the correct implementation and avoid
implicit defaults. Also select the necessary helpers in Kconfig.
Fbdev drivers sometimes rely on the callbacks being NULL for a
default I/O-memory-based implementation to be invoked; hence
requiring the I/O helpers to be built in any case. Setting all
callbacks in all drivers explicitly will allow to make the I/O
helpers optional. This benefits systems that do not use these
functions.
Split up lynxfb_ops and declare each as constant. The fb_ops
instance used to be modified while initializing the driver. It is
now constant and the driver picks the correct instance, depending
on the settings for acceleration and cursor support.
fbdev/cyber2000fb: Initialize fb_ops with fbdev macros
Initialize the instance of struct fb_ops with fbdev initializer
macros for framebuffers in I/O address space. Set the read/write,
draw and mmap callbacks to the correct implementation and avoid
implicit defaults. Also select the necessary helpers in Kconfig.
Fbdev drivers sometimes rely on the callbacks being NULL for a
default I/O-memory-based implementation to be invoked; hence
requiring the I/O helpers to be built in any case. Setting all
callbacks in all drivers explicitly will allow to make the I/O
helpers optional. This benefits systems that do not use these
functions.
fbdev/wm8505fb: Initialize fb_ops to fbdev I/O-memory helpers
Initialize the instance of struct fb_ops with fbdev initializer
macros for framebuffers in DMA-able address space. This explictily
sets the read/write, draw and mmap callbacks to the correct default
implementation. Also select the necessary helpers in Kconfig.
Fbdev drivers sometimes rely on the callbacks being NULL for a
default implementation to be invoked; hence requireing the I/O
helpers to be built in any case. Setting all callbacks in all
drivers explicitly will allow to make the I/O helpers optional.
This benefits systems that do not use these functions.
Set the callbacks via macros. No functional changes.
fbdev/vt8500lcdfb: Initialize fb_ops with fbdev macros
Initialize the instance of struct fb_ops with fbdev initializer
macros for framebuffers in DMA-able virtual address space. Set the
read/write, draw and mmap callbacks to the correct implementation
and avoid implicit defaults. Also select the necessary helpers in
Kconfig.
Fbdev drivers sometimes rely on the callbacks being NULL for a
default I/O-memory-based implementation to be invoked; hence
requiring the I/O helpers to be built in any case. Setting all
callbacks in all drivers explicitly will allow to make the I/O
helpers optional. This benefits systems that do not use these
functions.
fbdev/clps711x-fb: Initialize fb_ops with fbdev macros
Initialize the instance of struct fb_ops with fbdev initializer
macros for framebuffers in I/O address space. Set the read/write,
draw and mmap callbacks to the correct implementation and avoid
implicit defaults. Also select the necessary helpers in Kconfig.
The driver previously selected drawing ops for system memory
although it operates on I/O memory. Fixed now.
Fbdev drivers sometimes rely on the callbacks being NULL for a
default I/O-memory-based implementation to be invoked; hence
requiring the I/O helpers to be built in any case. Setting all
callbacks in all drivers explicitly will allow to make the I/O
helpers optional. This benefits systems that do not use these
functions.
media/ivtvfb: Initialize fb_ops to fbdev I/O-memory helpers
Initialize the instance of struct fb_ops with fbdev initializer
macros for framebuffers in I/O address space. This explictily sets
the read/write, draw and mmap callbacks to the correct default
implementation.
Fbdev drivers sometimes rely on the callbacks being NULL for a
default implementation to be invoked; hence requireing the I/O
helpers to be built in any case. Setting all callbacks in all
drivers explicitly will allow to make the I/O helpers optional.
This benefits systems that do not use these functions.
Set the callbacks via macros. No functional changes.
Initialize the instance of struct fb_ops with fbdev initializer
macros for framebuffers in virtual address space. Set the read/write,
draw and mmap callbacks to the correct implementation and avoid
implicit defaults. Also select the necessary helpers in Kconfig.
Fbdev drivers sometimes rely on the callbacks being NULL for a
default I/O-memory-based implementation to be invoked; hence
requiring the I/O helpers to be built in any case. Setting all
callbacks in all drivers explicitly will allow to make the I/O
helpers optional. This benefits systems that do not use these
functions.
The ps3fb driver operates on system memory. Mark the framebuffer
accordingly. Helpers operating on the framebuffer memory will test
for the presence of this flag.
fbdev/au1200fb: Initialize fb_ops with fbdev macros
Initialize the instance of struct fb_ops with fbdev initializer
macros for framebuffers in DMA-able virtual address space. Set the
read/write, draw and mmap callbacks to the correct implementation
and avoid implicit defaults. Also select the necessary helpers in
Kconfig.
Fbdev drivers sometimes rely on the callbacks being NULL for a
default I/O-memory-based implementation to be invoked; hence
requiring the I/O helpers to be built in any case. Setting all
callbacks in all drivers explicitly will allow to make the I/O
helpers optional. This benefits systems that do not use these
functions.
The au1200fb driver operates on DMA-able system memory. Mark the
framebuffer accordingly. Helpers operating on the framebuffer memory
will test for the presence of this flag.
fbdev/sh_mobile_lcdcfb: Initialize fb_ops with fbdev macros
Initialize the instance of struct fb_ops with fbdev initializer
macros for framebuffers in DMA-able virtual address space. Set the
read/write, draw and mmap callbacks to the correct implementation
and avoid implicit defaults. Also select the necessary helpers in
Kconfig.
The driver uses a mixture of DMA helpers and deferred I/O. That
probably needs fixing by a driver maintainer.
Fbdev drivers sometimes rely on the callbacks being NULL for a
default I/O-memory-based implementation to be invoked; hence
requiring the I/O helpers to be built in any case. Setting all
callbacks in all drivers explicitly will allow to make the I/O
helpers optional. This benefits systems that do not use these
functions.
The sh_mobile_lcdcfb driver operates on DMA-able system memory. Mark
the framebuffer accordingly. Helpers operating on the framebuffer memory
will test for the presence of this flag.
The picolcd_fb driver operates on system memory. Mark the framebuffer
accordingly. Helpers operating on the framebuffer memory will test
for the presence of this flag.
auxdisplay/ht16k33: Initialize fb_ops with fbdev macros
Initialize the instance of struct fb_ops with fbdev initializer
macros for framebuffers in virtual address space. Set the read/write,
draw and mmap callbacks to the correct implementation and avoid
implicit defaults. Also select the necessary helpers in Kconfig.
Fbdev drivers sometimes rely on the callbacks being NULL for a
default I/O-memory-based implementation to be invoked; hence
requiring the I/O helpers to be built in any case. Setting all
callbacks in all drivers explicitly will allow to make the I/O
helpers optional. This benefits systems that do not use these
functions.
The ht16k33 driver operates on system memory. Mark the framebuffer
accordingly. Helpers operating on the framebuffer memory will test
for the presence of this flag.
auxdisplay/cfag12864bfb: Initialize fb_ops with fbdev macros
Initialize the instance of struct fb_ops with fbdev initializer
macros for framebuffers in virtual address space. Set the read/write,
draw and mmap callbacks to the correct implementation and avoid
implicit defaults. Also select the necessary helpers in Kconfig.
Fbdev drivers sometimes rely on the callbacks being NULL for a
default I/O-memory-based implementation to be invoked; hence
requiring the I/O helpers to be built in any case. Setting all
callbacks in all drivers explicitly will allow to make the I/O
helpers optional. This benefits systems that do not use these
functions.
projects / linux.git / log