| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Rationale:
Reduces attack surface on kernel devs opening the links for MITM
as HTTPS traffic is much harder to manipulate.
Deterministic algorithm:
For each file:
If not .svg:
For each line:
If doesn't contain `\bxmlns\b`:
For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`:
If both the HTTP and HTTPS versions
return 200 OK and serve the same content:
Replace HTTP with HTTPS.
Signed-off-by: Alexander A. Klimov <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Look up backlight device using devm_of_find_backlight().
This simplifies the code and prevents us from hardcoding
the node name in the driver.
Signed-off-by: Sam Ravnborg <[email protected]>
Reviewed-by: Tomi Valkeinen <[email protected]>
Cc: Tomi Valkeinen <[email protected]>
Cc: Zheng Bin <[email protected]>
Cc: Kate Stewart <[email protected]>
Cc: Enrico Weigelt <[email protected]>
Cc: Allison Randal <[email protected]>
Cc: Laurent Pinchart <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: Kefeng Wang <[email protected]>
Cc: Sam Ravnborg <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
The DSS core looks up the next device connected to an output by
traversing the OF graph. It currently hardcodes the local port number to
0, which breaks any output with a different port number (SDI on OMAP3
and any DPI output but the first one). Fix this by repurposing the
currently unused of_ports bitmask in omap_dss_device with an of_port
output port number, and use it to traverse the OF graph.
Signed-off-by: Laurent Pinchart <[email protected]>
Reviewed-by: Tomi Valkeinen <[email protected]>
Tested-by: Sebastian Reichel <[email protected]>
Reviewed-by: Sebastian Reichel <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Fixes coccicheck warning:
drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c:681:1-15: WARNING: Assignment of 0/1 to bool variable
drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c:732:1-15: WARNING: Assignment of 0/1 to bool variable
Reported-by: Hulk Robot <[email protected]>
Signed-off-by: Zheng Bin <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Pull drm updates from Dave Airlie:
"The biggest thing in this is the AMD Navi GPU support, this again
contains a bunch of header files that are large. These are the new AMD
RX5700 GPUs that just recently became available.
New drivers:
- ST-Ericsson MCDE driver
- Ingenic JZ47xx SoC
UAPI change:
- HDR source metadata property
Core:
- HDR inforframes and EDID parsing
- drm hdmi infoframe unpacking
- remove prime sg_table caching into dma-buf
- New gem vram helpers to reduce driver code
- Lots of drmP.h removal
- reservation fencing fix
- documentation updates
- drm_fb_helper_connector removed
- mode name command handler rewrite
fbcon:
- Remove the fbcon notifiers
ttm:
- forward progress fixes
dma-buf:
- make mmap call optional
- debugfs refcount fixes
- dma-fence free with pending signals fix
- each dma-buf gets an inode
Panels:
- Lots of additional panel bindings
amdgpu:
- initial navi10 support
- avoid hw reset
- HDR metadata support
- new thermal sensors for vega asics
- RAS fixes
- use HMM rather than MMU notifier
- xgmi topology via kfd
- SR-IOV fixes
- driver reload fixes
- DC use a core bpc attribute
- Aux fixes for DC
- Bandwidth calc updates for DC
- Clock handling refactor
- kfd VEGAM support
vmwgfx:
- Coherent memory support changes
i915:
- HDR Support
- HDMI i2c link
- Icelake multi-segmented gamma support
- GuC firmware update
- Mule Creek Canyon PCH support for EHL
- EHL platform updtes
- move i915.alpha_support to i915.force_probe
- runtime PM refactoring
- VBT parsing refactoring
- DSI fixes
- struct mutex dependency reduction
- GEM code reorg
mali-dp:
- Komeda driver features
msm:
- dsi vs EPROBE_DEFER fixes
- msm8998 snapdragon 835 support
- a540 gpu support
- mdp5 and dpu interconnect support
exynos:
- drmP.h removal
tegra:
- misc fixes
tda998x:
- audio support improvements
- pixel repeated mode support
- quantisation range handling corrections
- HDMI vendor info fix
armada:
- interlace support fix
- overlay/video plane register handling refactor
- add gamma support
rockchip:
- RX3328 support
panfrost:
- expose perf counters via hidden ioctls
vkms:
- enumerate CRC sources list
ast:
- rework BO handling
mgag200:
- rework BO handling
dw-hdmi:
- suspend/resume support
rcar-du:
- R8A774A1 Soc Support
- LVDS dual-link mode support
- Additional formats
- Misc fixes
omapdrm:
- DSI command mode display support
stm
- fb modifier support
- runtime PM support
sun4i:
- use vmap ops
vc4:
- binner bo binding rework
v3d:
- compute shader support
- resync/sync fixes
- job management refactoring
lima:
- NULL pointer in irq handler fix
- scheduler default timeout
virtio:
- fence seqno support
- trace events
bochs:
- misc fixes
tc458767:
- IRQ/HDP handling
sii902x:
- HDMI audio support
atmel-hlcdc:
- misc fixes
meson:
- zpos support"
* tag 'drm-next-2019-07-16' of git://anongit.freedesktop.org/drm/drm: (1815 commits)
Revert "Merge branch 'vmwgfx-next' of git://people.freedesktop.org/~thomash/linux into drm-next"
Revert "mm: adjust apply_to_pfn_range interface for dropped token."
mm: adjust apply_to_pfn_range interface for dropped token.
drm/amdgpu/navi10: add uclk activity sensor
drm/amdgpu: properly guard the generic discovery code
drm/amdgpu: add missing documentation on new module parameters
drm/amdgpu: don't invalidate caches in RELEASE_MEM, only do the writeback
drm/amd/display: avoid 64-bit division
drm/amdgpu/psp11: simplify the ucode register logic
drm/amdgpu: properly guard DC support in navi code
drm/amd/powerplay: vega20: fix uninitialized variable use
drm/amd/display: dcn20: include linux/delay.h
amdgpu: make pmu support optional
drm/amd/powerplay: Zero initialize current_rpm in vega20_get_fan_speed_percent
drm/amd/powerplay: Zero initialize freq in smu_v11_0_get_current_clk_freq
drm/amd/powerplay: Use memset to initialize metrics structs
drm/amdgpu/mes10.1: Fix header guard
drm/amd/powerplay: add temperature sensor support for navi10
drm/amdgpu: fix scheduler timeout calc
drm/amdgpu: Prepare for hmm_range_register API change (v2)
...
|
|
Based on 2 normalized pattern(s):
this program is free software you can redistribute it and or modify
it under the terms of the gnu general public license version 2 as
published by the free software foundation
this program is free software you can redistribute it and or modify
it under the terms of the gnu general public license version 2 as
published by the free software foundation #
extracted by the scancode license scanner the SPDX license identifier
GPL-2.0-only
has been chosen to replace the boilerplate/reference in 4122 file(s).
Signed-off-by: Thomas Gleixner <[email protected]>
Reviewed-by: Enrico Weigelt <[email protected]>
Reviewed-by: Kate Stewart <[email protected]>
Reviewed-by: Allison Randal <[email protected]>
Cc: [email protected]
Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
|
|
Using dev_get_drvdata directly.
Cc: Tomi Valkeinen <[email protected]>
Cc: David Airlie <[email protected]>
Cc: Daniel Vetter <[email protected]>
Cc: [email protected]
Signed-off-by: Kefeng Wang <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
The omap_dss_device type and output_type fields differ mostly for
historical reasons. The output_type field is required for all devices
but the display at the end of the pipeline, and must be set to
OMAP_DISPLAY_TYPE_NONE for the latter. The type field is required for
all devices but the internal encoder, for which it is ignored.
The only reason why the output_type field must be set to
OMAP_DISPLAY_TYPE_NONE for the display at the end of the pipeline is to
identify omap_dss_device instances corresponding to displays. This is
not documented and confusing.
Clean the code by adding a new display field to the omap_dss_device
structure to identify displays, and merge the type and output_type
fields.
Signed-off-by: Laurent Pinchart <[email protected]>
Reviewed-by: Sebastian Reichel <[email protected]>
Tested-by: Sebastian Reichel <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
The omap_dss_device .check_timings() and .set_timings() operations
operate on struct videomode, while the DRM API operates on struct
drm_display_mode. This forces conversion from to videomode in the
callers. While that's not a problem per se, it creates a difference with
the drm_bridge API.
Replace the videomode parameter to the .check_timings() and
.set_timings() operations with a drm_display_mode. This pushed the
conversion to videomode down to the DSS devices in some cases. If needed
they will be converted to operate on drm_display_mode natively.
Signed-off-by: Laurent Pinchart <[email protected]>
Reviewed-by: Sebastian Reichel <[email protected]>
Tested-by: Sebastian Reichel <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
The source pointer will be removed to the omap_dss_device structure.
Store it internally in the DSI panel driver data.
Signed-off-by: Laurent Pinchart <[email protected]>
Reviewed-by: Sebastian Reichel <[email protected]>
Tested-by: Sebastian Reichel <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
Instead of manually iterating over the dss devices in the pipeline to
find the first one that implements the .get_modes() operation, add a new
operation flag for .get_modes() and use the omap_connector_find_device()
helper function to locate the right dss device.
Signed-off-by: Laurent Pinchart <[email protected]>
Reviewed-by: Sebastian Reichel <[email protected]>
Tested-by: Sebastian Reichel <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
Now that the .get_modes() operations takes a drm_connector and fills it
with modes, it becomes easy to fill display information in the same
operation without requiring a separate .get_size() opearation.
Signed-off-by: Laurent Pinchart <[email protected]>
Reviewed-by: Sebastian Reichel <[email protected]>
Tested-by: Sebastian Reichel <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
omap_dss_device operations expose fixed video timings through a
.get_timings() operation that return a single timing for the device. To
prepare for the move to drm_bridge, modify the API to instead add DRM
modes directly to the connector.
As this puts more burden on display devices, we also create a helper
function for panels to add a single DRM mode from the panel video
timings.
Signed-off-by: Laurent Pinchart <[email protected]>
Reviewed-by: Sebastian Reichel <[email protected]>
Tested-by: Sebastian Reichel <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
The omapdrm and omapdss drivers are architectured based on display
pipelines made of multiple components handled from sink (display) to
source (DSS output). This is incompatible with the DRM bridge and panel
APIs that handle components from source to sink.
Reconcile the omapdrm and omapdss drivers with the DRM bridge and panel
model by reversing the direction of the DSS device .enable() and
.disable() operations. This completes the move to the DRM bridge model,
with the notable exception of the DSI pipelines that will require more
work.
We also adapt the omapdss shutdown handler dss_shutdown() to shut down
all active pipelines starting from the pipeline output device instead of
the display device.
As a consequence the for_each_dss_display() macro isn't used and can be
removed, and the omapdss_device_get_next() function underlying the macro
can be simplified to search for output devices only.
Signed-off-by: Laurent Pinchart <[email protected]>
Reviewed-by: Sebastian Reichel <[email protected]>
Tested-by: Sebastian Reichel <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
The displays (connectors, panels and encoders) bail out from their
.enable() and .disable() handlers if the dss device is already enabled
or disabled. Those safety checks are not needed when the functions are
called through the omapdss_device_ops, as the .enable() and .disable()
handlers are called from the DRM atomic helpers that already guarantee
that no double enabling or disabling can occur.
However, the handlers are also called directly from the .remove()
handler. While this shouldn't be needed either as the modules can't be
removed as long as the device is in use, it's still a good practice to
disable the device explicitly. There is currently a safety check in
.remove() in some drivers but not all of them.
Remove the safety checks from the .enable() and .disable() handlers, and
add missing ones in the .remove() handler.
Signed-off-by: Laurent Pinchart <[email protected]>
Reviewed-by: Sebastian Reichel <[email protected]>
Tested-by: Sebastian Reichel <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
All .enable() and .disable() handlers for panels and connectors share
common code that validates and updates the device's state. Move it to
common locations in the omap_encoder_enable() and omap_encoder_disable()
handlers.
The enabled check in the .disable() handler is left untouched, it will
be addressed separately.
Signed-off-by: Laurent Pinchart <[email protected]>
Reviewed-by: Sebastian Reichel <[email protected]>
Tested-by: Sebastian Reichel <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
omap_dss_device instances have two ops structures, omap_dss_driver and
omap_dss_device_ops. The former is used for devices at the end of the
pipeline (a.k.a. display devices), and the latter for intermediate
devices.
Having two sets of operations isn't convenient as code that iterates
over omap_dss_device instances need to take them both into account.
There's currently a reasonably small amount of such code, but more will
be introduced to move the driver away from recursive operations. To
simplify current and future code, move all operations that are not
specific to the display device to the omap_dss_device_ops.
Signed-off-by: Laurent Pinchart <[email protected]>
Reviewed-by: Sebastian Reichel <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
The omapdrm and omapdss drivers are architectured based on display
pipelines made of multiple components handled from sink (display) to
source (DSS output). This is incompatible with the DRM bridge and panel
APIs that handle components from source to sink.
To reconcile the omapdrm and omapdss drivers with the DRM bridge and
panel model, we need to reverse the direction of the DSS device
operations. Start with the connect and disconnect operations.
Signed-off-by: Laurent Pinchart <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
The omapdss_of_find_source_for_first_ep() function locates the source
corresponding to the first endpoint of the first port of a device node.
We can easily extend it to locate sinks as well by passing the port
number as a parameter. This will be useful to find sinks in encoders
drivers.
Extend the function and rename it to omapdss_of_find_connected_device()
to reflect its new extended purpose.
Additionally, it is useful to differentiate between failures to return
the connected device because no link exists in the device tree for the
requested port, or because the connected device as described in the
device tree is invalid or not probed yet. Return NULL in the first case
and an error code in the second case, and update the callers
accordingly.
Signed-off-by: Laurent Pinchart <[email protected]>
Reviewed-by: Sebastian Reichel <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
The omap_dss_device port_num field stores the DT port number associated
with the device. The field is used in different ways depending on the
device type:
- For DPI outputs, the port number is used as an identifier of the DPI
instance
- For sources, the port number is used to look up the omap_dss_device by
DT port node
As omap_dss_device instances are only looked up as sources by sinks,
setting the field to the number of the source port works for both use
cases.
However, to enable looking up sinks, we need to record all the ports
associated with an omap_dss_device. Do so by turning the port_num field
into an of_ports bitmask. For DPI outputs the port number is
additionally stored in the dpi_data structure as the output ID.
Signed-off-by: Laurent Pinchart <[email protected]>
Reviewed-by: Sebastian Reichel <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
Storing the dss_device pointer in the omap_dss_device structure will
allow accessing the dss_device from the dss_mgr API functions.
Signed-off-by: Laurent Pinchart <[email protected]>
Reviewed-by: Sebastian Reichel <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
The functions operate on any omap_dss_device, move them from display.c
to base.c. While at it rename them to match the naming of the other
functions operating on struct omap_dss_device.
Signed-off-by: Laurent Pinchart <[email protected]>
Reviewed-by: Sebastian Reichel <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
The panel devices list isn't used anymore, all panel devices are
accessed through the global devices list. Remove it.
Signed-off-by: Laurent Pinchart <[email protected]>
Reviewed-by: Sebastian Reichel <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
Split the function into omapdss_display_init() to perform
display-specific initialization of the omap_dss_device, and
omapdss_register_display() to register the device. The latter will then
be replaced by more generic registration.
Signed-off-by: Laurent Pinchart <[email protected]>
Reviewed-by: Sebastian Reichel <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
All connectors, encoders and panels store a pointer to their input
omap_dss_device in the panel driver data structure. This duplicates the
src field in the omap_dss_device structure. Remove the private copy and
use the src field.
Signed-off-by: Laurent Pinchart <[email protected]>
Reviewed-by: Sebastian Reichel <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
In preparation for the move of checks from the disconnect handlers to
the omapdss_device_disconnect() function, replace direct calls to the
disconnect handlers at remove time with calls to
omapdss_device_disconnect().
Signed-off-by: Laurent Pinchart <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
The connectors, encoders and display duplicate the same debug messages
and connection checks in their omap_dss_device connect and disconnect
handlers. Move the code to the connect and disconnect wrappers.
To simplify the code the connect function returns -EBUSY unconditionally
if the device is already connected. This doesn't cause any change in
practice: the connect handler of displays is never called on a connected
device as it is only invoked during omapdrm initialization.
Signed-off-by: Laurent Pinchart <[email protected]>
Reviewed-by: Sebastian Reichel <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
The omap_dss_device objects model display components and are connected
at runtime to create display pipelines. The connect and disconnect
operations implemented by each component contain lots of duplicate code.
As a first step towards fixing this, create new functions to wrap the
direct calls to those operations and use them.
Signed-off-by: Laurent Pinchart <[email protected]>
Reviewed-by: Sebastian Reichel <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
The various types of omapdss_*_ops structures define multiple operations
that are not specific to a bus type. To simplify the code and remove
dependencies on specific bus types move those operations to a common
structure. Operations that are specific to a bus type are kept in the
specialized ops structures.
Signed-off-by: Laurent Pinchart <[email protected]>
Reviewed-by: Sebastian Reichel <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
The omap_dss_device panel.dsi_pix_fmt and panel.dsi_mode fields are
unused. Remove them.
Signed-off-by: Laurent Pinchart <[email protected]>
Reviewed-by: Sebastian Reichel <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
The omap_dss_device structure stores a videomode. All the connector and
panel drivers that use omap_dss_device also store the videomode in their
own panel_drv_data structures. There's no need to duplicate, remove the
videomode field from omap_dss_device.
Signed-off-by: Laurent Pinchart <[email protected]>
Reviewed-by: Sebastian Reichel <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
The structure contains function pointers that don't need to be modified.
Make all its instances const to improve security.
Signed-off-by: Laurent Pinchart <[email protected]>
Reviewed-by: Sebastian Reichel <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
The driver accesses the ddata->in field before it gets set in the
dsicm_connect() function. Use the local in pointer variable instead.
Fixes: 7877632b4cd0 ("drm: omapdrm: displays: Get panel source at connect time")
Signed-off-by: Laurent Pinchart <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
The connector drivers need a handle to the source they are connected to
in order to control the source.
All drivers get that handle at probe time, resulting in probe deferral
when the source hasn't been probed yet. However they don't need the
handle until their connect handler is called.
Move retrieval of the source handle to the connect handler to avoid
probe deferrals.
Signed-off-by: Laurent Pinchart <[email protected]>
Reviewed-by: Sebastian Reichel <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
No panel is instantiated through platform data anymore, there is no
need to check for OF node presence.
Signed-off-by: Laurent Pinchart <[email protected]>
Reviewed-by: Sebastian Reichel <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
The kernel favours 'unsigned int' over plain 'unsigned'. Replace all
occurences of the latter by the former. This avoid lots of checkpatch
complaints in patches that touch lines where a plain 'unsigned' is used.
Signed-off-by: Laurent Pinchart <[email protected]>
Reviewed-by: Sebastian Reichel <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
Having the filename in the header serves little purpose and is
often wrong after renames as it is here in several places, just
drop it from all omapdrm files.
While we are here unify the copyright tags to the TI recommended style.
Signed-off-by: Andrew F. Davis <[email protected]>
|
|
Use the new descriptor based GPIO API instead of
the legacy one, which results in cleaner code
with less lines of code.
Signed-off-by: Sebastian Reichel <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
Droid 4 has a command mode DSI panel, which does not have/use
DSI based backlight support. This adds proper support for this
using a backlight phandle property, which follows the common
panel binding.
If no backlight phandle is found, it is assumed, that the
native backlight should be used instead. This is used by
the Nokia N950.
Signed-off-by: Sebastian Reichel <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
Add support to load physical size information from DT using
the properties defined by the common panel binding.
Signed-off-by: Sebastian Reichel <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
Add support for regulators used by panels found inside
of the Nokia N950, N9 and Motorola Droid 4.
Signed-off-by: Sebastian Reichel <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
This adds support for get_timings() and check_timings()
to get the driver working and properly initializes the
timing information from DT.
Signed-off-by: Tony Lindgren <[email protected]>
Signed-off-by: Sebastian Reichel <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
attribute_groups are not supposed to change at runtime. All functions
working with attribute_groups provided by <linux/sysfs.h> work with const
attribute_group. So mark the non-const structs as const.
File size before:
text data bss dec hex filename
4669 464 0 5133 140d panel-dsi-cm.o
File size After adding 'const':
text data bss dec hex filename
4725 400 0 5125 1405 panel-dsi-cm.o
Signed-off-by: Arvind Yadav <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
get_resolution is not used, remove it.
Signed-off-by: Tomi Valkeinen <[email protected]>
Reviewed-by: Laurent Pinchart <[email protected]>
|
|
recommended_bpp hasn't been used for ages, remove the code.
Signed-off-by: Tomi Valkeinen <[email protected]>
Reviewed-by: Laurent Pinchart <[email protected]>
|
|
<linux/sched.h> into <linux/sched/signal.h>
Fix up affected files that include this signal functionality via sched.h.
Acked-by: Linus Torvalds <[email protected]>
Cc: Mike Galbraith <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: [email protected]
Signed-off-by: Ingo Molnar <[email protected]>
|
|
By linking the sizeof to a variable type the code will be less prone to
bugs due to future type changes of variables.
Signed-off-by: Laurent Pinchart <[email protected]>
Reviewed-by: Daniel Vetter <[email protected]>
Reviewed-by: Tomi Valkeinen <[email protected]>
|
|
Use 'vm' to refer to a struct videomode instead of 'p', 't', 'timings' or
something else.
The code will be easier to follow if we use consistent names.
Signed-off-by: Peter Ujfalusi <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
omap_video_timings can be replaced with the generic videomode in omapdrm
and the omap_video_timings can be removed.
This patch will replace the omap_video_timings with videomode.
With the change we no longer need the functions to convert to/from
videomode and drm_display_mode to omap_video_timings, these can be removed
as well.
Signed-off-by: Peter Ujfalusi <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|
|
omap_video_timings struct have the same members as struct videomode, but
their types are different. As first step change the types of the
omap_video_timings struct members to match their counterpart in
struct videomode to catch any type cast related issues.
Signed-off-by: Peter Ujfalusi <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
|