Fix two warnings due to file rename:
WARNING: kernel-doc './scripts/kernel-doc -rst -enable-lineno -function
csr support for dmc ./drivers/gpu/drm/i915/intel_csr.c' failed with return code
1
WARNING: kernel-doc './scripts/kernel-doc -rst -enable-lineno -internal
./drivers/gpu/dr
Several references got broken due to txt to ReST conversion.
Several of them can be automatically fixed with:
scripts/documentation-file-ref-check --fix
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/admin-guide/kernel-parameters.txt | 10 +-
Documentation/filesyst
Several DT references got broken due to txt->yaml conversion.
Those are auto-fixed by running:
scripts/documentation-file-ref-check --fix
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/devicetree/bindings/arm/arm,scmi.txt| 2 +-
Documentation/devicetree/bindings/arm/arm
Hi Sam,
On Fri, Feb 21, 2020 at 06:18:30PM +0100, Sam Ravnborg wrote:
> Hi Laurent.
>
> > Why ô why did I have to start the DRM/KMS documentation effort years
> > ago, to see it biting me back now ? :-)
>
> Thats obviously because you and countless others are some were nice
> people that like the
Hi,
I am trying to reproduce a syzkaller bug found in the vkms:
- WARNING in vkms_gem_free_object
- https://groups.google.com/forum/#!msg/syzkaller-bugs/_oARhriB1SA/PelnW1BqAwAJ
However, I was not very successful in this task. As I don't know how to deal
with syzkaller and I am not sure if I am f
On Fri, Feb 21, 2020 at 10:36 PM Chris Wilson wrote:
> Quoting Daniel Vetter (2020-02-21 21:02:30)
> > For two reasons:
> >
> > - The driver core clears this already for us after we're unloaded in
> > __device_release_driver().
>
> Even if we abort before loading?
>
> History notes that i915_pci
On Sat, Feb 22, 2020 at 10:48 AM Daniel Vetter wrote:
>
> On Fri, Feb 21, 2020 at 10:36 PM Chris Wilson
> wrote:
> > Quoting Daniel Vetter (2020-02-21 21:02:30)
> > > For two reasons:
> > >
> > > - The driver core clears this already for us after we're unloaded in
> > > __device_release_driver
On Sat, Feb 22, 2020 at 10:03 AM Melissa Wen wrote:
>
> Hi,
>
> I am trying to reproduce a syzkaller bug found in the vkms:
> - WARNING in vkms_gem_free_object
> -
> https://groups.google.com/forum/#!msg/syzkaller-bugs/_oARhriB1SA/PelnW1BqAwAJ
>
> However, I was not very successful in this task.
On Fri, Feb 21, 2020 at 10:21:18PM +0100, Sam Ravnborg wrote:
> Hi Kevin.
>
> On Fri, Feb 21, 2020 at 03:48:51PM +0800, Kevin Tang wrote:
> > From: Kevin Tang
> >
> > The Unisoc DRM master device is a virtual device needed to list all
> > DPU devices or other display interface nodes that compris
Replace the manual encoder->bridge_chain walk with the
drm_for_each_bridge_in_chain() macro. Drivers should not touch the
bridge_chain field directly.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/tidss/tidss_encoder.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/dri
Hi,
On 2/21/20 10:02 PM, Daniel Vetter wrote:
With this we can drop the final kfree from the release function.
Signed-off-by: Daniel Vetter
Cc: Hans de Goede
Patch looks good to me:
Reviewed-by: Hans de Goede
Regards,
Hans
---
drivers/gpu/drm/tiny/gm12u320.c | 3 ++-
1 file change
Hi,
On 2/21/20 10:03 PM, Daniel Vetter wrote:
The drm_mode_config_cleanup call we can drop, and all the allocations
we can switch over to drmm_kzalloc. Unfortunately the work queue is
still present, so can't get rid of the drm_driver->release function
outright.
Signed-off-by: Daniel Vetter
Cc:
Hi,
On 2/21/20 10:03 PM, Daniel Vetter wrote:
Only drops the drm_dev_put, but hey a few lines!
Signed-off-by: Daniel Vetter
Cc: Hans de Goede
Cc: "Noralf Trønnes"
Patch looks good to me:
Reviewed-by: Hans de Goede
Regards,
Hans
---
drivers/gpu/drm/tiny/gm12u320.c | 19 +++
Hi,
On 2/21/20 10:03 PM, Daniel Vetter wrote:
Also there's a race in the disconnect implemenation. First shut
down, then unplug, leaves a window where userspace could sneak
in and restart the entire machinery.
With this we can also delete the very un-atomic global pipe_enabled
tracking.
Patch
Hi Tomi.
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -2397,7 +2397,8 @@ static const struct panel_desc
> osddisplays_osd070t1718_19ts = {
> .height = 91,
> },
> .bus_format = MEDIA_BUS_FMT_RGB888_1X24,
> -.bus_fla
Hi Marek.
On Thu, Feb 20, 2020 at 01:07:00PM +0100, Marek Szyprowski wrote:
> Add proper MODULE_DEVICE_TABLE structure with SPI IDs to allow proper
> creation of SPI modalias string and fix autoloading module for this driver.
>
> Signed-off-by: Marek Szyprowski
Thanks,
applied to drm-misc-next
Hi,
On 2/21/20 10:03 PM, Daniel Vetter wrote:
Instead of having a work item that never stops (which really should be
a kthread), with a dedicated workqueue to not upset anyone else, use a
delayed work. A bunch of changes:
- We can throw out all the custom wakeup and requeue logic and state
t
Hi Ville.
Nice patch - and diffstat looks good:
> 63 files changed, 217 insertions(+), 392 deletions(-)
There is an item in the Documentation/gpu/todo.rst that
describes this.
Could you drop this from todo.rst in this patch too.
> diff --git a/drivers/gpu/drm/mcde/mcde_dsi.c b/drivers/gpu/drm/m
On Sat, Feb 22, 2020 at 1:30 PM Hans de Goede wrote:
>
> Hi,
>
> On 2/21/20 10:03 PM, Daniel Vetter wrote:
> > Instead of having a work item that never stops (which really should be
> > a kthread), with a dedicated workqueue to not upset anyone else, use a
> > delayed work. A bunch of changes:
> >
From: Colin Ian King
Variable dw is being initialized with a value that is never read,
it is assigned a new value later on. The assignment is redundant
and can be removed.
Addresses-Coverity: ("Unused value")
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 2 +-
1
Quoting Colin King (2020-02-22 13:47:55)
> From: Colin Ian King
>
> Variable dw is being initialized with a value that is never read,
> it is assigned a new value later on. The assignment is redundant
> and can be removed.
>
> Addresses-Coverity: ("Unused value")
> Signed-off-by: Colin Ian King
If an enable GPIO is declared in the firmware, assert it when enabling
the bridge and deassert it when disabling it.
Signed-off-by: Laurent Pinchart
Reviewed-by: Andrzej Hajda
Reviewed-by: Stefan Agner
Reviewed-by: Boris Brezillon
Reviewed-by: Maxime Ripard
Acked-by: Sam Ravnborg
Tested-by:
Display connectors are modelled in DT as a device node, but have so far
been handled manually in several bridge drivers. This resulted in
duplicate code in several bridge drivers, with slightly different (and
thus confusing) logics.
In order to fix this, implement a bridge driver for display conne
The hdmi_avi_infoframe_init() never needs to return an error, change its
return type to void.
Signed-off-by: Laurent Pinchart
Reviewed-by: Andrzej Hajda
Acked-by: Bartlomiej Zolnierkiewicz
Reviewed-by: Boris Brezillon
Acked-by: Sam Ravnborg
Tested-by: Sebastian Reichel
Reviewed-by: Sebastian
The drm_encoder.bridge_chain is not meant to be touched manually by
drivers. Make this clear in the documentation.
Signed-off-by: Laurent Pinchart
---
include/drm/drm_encoder.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/drm/drm_encoder.h b/include/drm/drm_encod
The drm_bridge_funcs atomic_state_duplicate and atomic_state_destroy
operations are erroneously documented as having a default implementation
if not implemented in bridge drivers. This isn't correct, fix the
documentation.
Signed-off-by: Laurent Pinchart
---
include/drm/drm_bridge.h | 20 +++
The dumb-vga-dac driver is a simple DRM bridge driver for simple VGA
DACs that don't require configuration. Other non-VGA bridges fall in a
similar category, and would benefit from a common driver. Prepare for
this by renaming the internal symbols from dumb-vga-dac to
simple-bridge.
Signed-off-by:
The TI OPA362 is an analog video amplifier controlled through a GPIO. Add
support for it to the simple-bridge driver.
Signed-off-by: Laurent Pinchart
Reviewed-by: Andrzej Hajda
Reviewed-by: Boris Brezillon
Reviewed-by: Maxime Ripard
Reviewed-by: Tomi Valkeinen
Acked-by: Sam Ravnborg
Tested-b
Now that a driver is available for display connectors, replace the
manual connector handling code with usage of the DRM bridge API. The
tfp410 driver doesn't deal with the display connector directly anymore,
but still delegates drm_connector operations to the next bridge. This
brings us one step cl
Hello,
This patch series is the sixth attempt to (nearly, see [1]) complete the
rework of the omapdrm driver to move to drm_bridge and drm_panel.
Version 2, available at [2], explains in its long cover letter the
rationale for the changes. I won't duplicate it here as it is still
valid as-is.
Co
The dumb-vga-dac driver can support simple DRM bridges without being
limited to VGA DACs. Rename it to simple-bridge.
Signed-off-by: Laurent Pinchart
Reviewed-by: Andrzej Hajda
Reviewed-by: Boris Brezillon
Acked-by: Maxime Ripard
Acked-by: Sam Ravnborg
Tested-by: Sebastian Reichel
Reviewed-b
Clean up the drm_bridge overview documentation, and expand the
operations documentation to provide more details on API usage.
Signed-off-by: Laurent Pinchart
---
Documentation/gpu/drm-kms-helpers.rst | 6 +--
drivers/gpu/drm/drm_bridge.c | 76 ---
2 files change
Implement the newly added bridge connector operations, allowing the
usage of drm_bridge_panel with drm_bridge_connector.
Signed-off-by: Laurent Pinchart
Reviewed-by: Boris Brezillon
Reviewed-by: Sam Ravnborg
Tested-by: Sebastian Reichel
Reviewed-by: Sebastian Reichel
---
Changes since v2:
-
Bring the omapdss-specific .read_edid() operation in sync with the
drm_bridge .get_edid() operation to ease code reuse.
Signed-off-by: Laurent Pinchart
Reviewed-by: Tomi Valkeinen
Tested-by: Sebastian Reichel
Reviewed-by: Sebastian Reichel
---
Changes since v1:
- Keep MAX_EDID macro
---
driv
The drm_display_info structure contains many fields related to HDMI
sinks, but none that identifies if a sink compliant with CEA-861 (EDID)
shall be treated as an HDMI sink or a DVI sink. Add such a flag, and
populate it according to section 8.3.3 ("DVI/HDMI Device
Discrimination") of the HDMI v1.3
To support implementation of DRM connectors on top of DRM bridges
instead of by bridges, the drm_bridge needs to expose new operations and
data:
- Output detection, hot-plug notification, mode retrieval and EDID
retrieval operations
- Bitmask of supported operations
- Bridge output type
- I2C ad
As part of the move to drm_bridge ops, the dssdev ops will become empty
for some of the internal encoders. Make them optional in the driver to
allow them to be removed completely, easing the transition.
Signed-off-by: Laurent Pinchart
Reviewed-by: Tomi Valkeinen
Tested-by: Sebastian Reichel
Rev
In preparation of adding DRM bridge support to the hdmi4 encoder code,
rework the EDID read to isolate data read.
The hdmi_read_edid() function is the main entry point. It performs all
initialisation steps required prior to reading the EDID (such as
ensuring the device is powered on), as well as c
Now that the HDMI outputs are driven fully through the drm_bridge API
their omap_dss_device operations are not used anymore. Remove them.
Signed-off-by: Laurent Pinchart
Reviewed-by: Tomi Valkeinen
Tested-by: Sebastian Reichel
Reviewed-by: Sebastian Reichel
---
drivers/gpu/drm/omapdrm/dss/hdm
drm_connector.c contains a map of connector types (DRM_MODE_CONNECTOR_*)
to name strings, but doesn't expose it. This leads to drivers having to
store a similar map.
Add a new drm_get_connector_type_name() helper function that return a
name string for a connector type.
Signed-off-by: Laurent Pinc
Most bridge drivers create a DRM connector to model the connector at the
output of the bridge. This model is historical and has worked pretty
well so far, but causes several issues:
- It prevents supporting more complex display pipelines where DRM
connector operations are split over multiple compo
The TI TPD12S015 is an HDMI level shifter and ESD protector controlled
through GPIOs. Add a DRM bridge driver for the device.
Signed-off-by: Laurent Pinchart
Reviewed-by: Tomi Valkeinen
Acked-by: Sam Ravnborg
Tested-by: Sebastian Reichel
Reviewed-by: Sebastian Reichel
---
Changes since v2:
-
The tfp410 driver can operate as part of a pipeline where the
drm_connector is created by the display controller. Enable this mode of
operation by skipping creation of a drm_connector internally.
Signed-off-by: Laurent Pinchart
Reviewed-by: Boris Brezillon
Acked-by: Sam Ravnborg
Tested-by: Seba
Create a new simple_bridge_info structure that stores information about
the bridge model, and store the bridge timings in there, along with the
connector type. Use that new structure for of_device_id data. This
enables support for non-VGA bridges.
Signed-off-by: Laurent Pinchart
Reviewed-by: Andr
In order to integrate with a chain of drm_bridge, the internal HDMI4
encoder has to expose the EDID read operation through the drm_bridge
API. Register a bridge at initialisation time to do so.
For the time being make the next bridge in the chain optional as the
HDMI output is still based on omap_
Replace the manual panel handling code by a drm_panel_bridge. This
simplifies the driver and allows all components in the display pipeline
to be treated as bridges, paving the way to generic connector handling.
Signed-off-by: Laurent Pinchart
Reviewed-by: Tomi Valkeinen
Tested-by: Sebastian Reic
In order to integrate with a chain of drm_bridge, the internal VENC
encoder has to expose the mode valid, fixup and set, the enable and
disable and the get modes operations through the drm_bridge API.
Register a bridge at initialisation time to do so.
Most of those operations are removed from the
In preparation for a connector creation helper based on a chain of
bridges, add a flag to the drm_bridge structure to report support for
interlaced modes. This will be used to set the connector's
interlace_allowed flag.
Signed-off-by: Laurent Pinchart
Tested-by: Sebastian Reichel
Reviewed-by: Se
Move the omap_dss_device .set_timings(), .enable() and .disable()
operations to the drm_bridge functions. As the drm_bridge for the HDMI
encoder is unconditionally registered and attached, those operations
will be called at the appropriate time.
The omapdss device .set_infoframe() and .set_hdmi_mo
The HDMI4 encoder is transitioning to the drm_bridge API, implement the
last missing operation.
Signed-off-by: Laurent Pinchart
Reviewed-by: Tomi Valkeinen
Tested-by: Sebastian Reichel
Reviewed-by: Sebastian Reichel
---
drivers/gpu/drm/omapdrm/dss/hdmi4.c | 10 ++
1 file changed, 10 i
Use the drm_bridge_connector helper to create a connector for pipelines
that use drm_bridge. This allows splitting connector operations across
multiple bridges when necessary, instead of having the last bridge in
the chain creating the connector and handling all connector operations
internally.
Si
Now that the VENC output is driven fully through the drm_bridge API its
omap_dss_device operations are not used anymore. Remove them.
Signed-off-by: Laurent Pinchart
Reviewed-by: Tomi Valkeinen
Tested-by: Sebastian Reichel
Reviewed-by: Sebastian Reichel
---
drivers/gpu/drm/omapdrm/dss/venc.c
In order to integrate with a chain of drm_bridge, the internal HDMI5
encoder has to expose the EDID read operation through the drm_bridge
API. Register a bridge at initialisation time to do so.
For the time being make the next bridge in the chain optional as the
HDMI output is still based on omap_
This makes it easier to quickly locate duplicate includes.
Signed-off-by: Laurent Pinchart
Reviewed-by: Tomi Valkeinen
Tested-by: Sebastian Reichel
Reviewed-by: Sebastian Reichel
---
drivers/gpu/drm/omapdrm/dss/dpi.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git
Group functions based on their purpose and split them in sections to
make the source code easier to navigate.
No functional change is included.
Signed-off-by: Laurent Pinchart
Reviewed-by: Tomi Valkeinen
Tested-by: Sebastian Reichel
Reviewed-by: Sebastian Reichel
---
drivers/gpu/drm/omapdrm/
In order to support drm_bridge-based pipeline, the internal HDMI
encoders will need to expose the EDID read operation through the
drm_bridge API, and thus to expose a drm_bridge instance corresponding
to the encoder. The HDMI encoders are however handled as omap_dss_device
instances, which conflict
Remove the omap_connector_get_hdmi_mode() function as the HDMI mode can
be accessed directly from the connector's display info.
Signed-off-by: Laurent Pinchart
Reviewed-by: Tomi Valkeinen
Acked-by: Sam Ravnborg
Tested-by: Sebastian Reichel
Reviewed-by: Sebastian Reichel
---
drivers/gpu/drm/o
In preparation of adding DRM bridge support to the hdmi5 encoder code,
rework the EDID read to isolate data read.
The hdmi_read_edid() function is the main entry point. It performs all
initialisation steps required prior to reading the EDID (such as
ensuring the device is powered on), as well as c
The dpi_set_pll_clk() and dpi_set_dispc_clk() return various information
through pointer arguments that are never used by the callers. Remove
them to simplify the clock setting API.
Signed-off-by: Laurent Pinchart
Reviewed-by: Tomi Valkeinen
Tested-by: Sebastian Reichel
Reviewed-by: Sebastian R
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
The omapdss_hdmi_ops .set_hdmi_mode() and .set_infoframe() operations
operations are not used anymore, remove them.
Signed-off-by: Laurent Pinchart
Reviewed-by: Tomi Valkeinen
Tested-by: Sebastian Reichel
Reviewed-by: Sebastian Reichel
---
drivers/gpu/drm/omapdrm/dss/omapdss.h | 3 ---
driv
Now that the omap_dss_device EDID read operation has been removed,
simplify the bridge-based EDID access by merging multiple functions
together.
Signed-off-by: Laurent Pinchart
Reviewed-by: Tomi Valkeinen
Tested-by: Sebastian Reichel
Reviewed-by: Sebastian Reichel
---
drivers/gpu/drm/omapdrm/
This makes it easier to quickly locate duplicate includes.
Signed-off-by: Laurent Pinchart
Reviewed-by: Tomi Valkeinen
Tested-by: Sebastian Reichel
Reviewed-by: Sebastian Reichel
---
drivers/gpu/drm/omapdrm/dss/sdi.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/
The TPD12S015, OPA362 and analog and HDMI connectors are now supported
by DRM bridge drivers, and the omapdrm HDMI and VENC outputs can be
handled through the drm_bridge API. Switch the outputs to drm_bridge by
making the next bridge mandatory and removing the related
omapdrm-specific display drive
Most bridge drivers create a DRM connector to model the connector at the
output of the bridge. This model is historical and has worked pretty
well so far, but causes several issues:
- It prevents supporting more complex display pipelines where DRM
connector operations are split over multiple compo
Move the omap_dss_device .set_timings(), .enable() and .disable()
operations to the drm_bridge functions. As the drm_bridge for the HDMI
encoder is unconditionally registered and attached, those operations
will be called at the appropriate time.
The omapdss device .set_infoframe() and .set_hdmi_mo
In order to integrate with a chain of drm_bridge, the internal DPI
output has to expose its operations through the drm_bridge API.
Register a bridge at initialisation time to do so and remove the
omap_dss_device operations that are now unused.
Signed-off-by: Laurent Pinchart
Tested-by: Sebastian
In order to integrate with a chain of drm_bridge, the internal SDI
output has to expose its operations through the drm_bridge API.
Register a bridge at initialisation time to do so and remove the
omap_dss_device operations that are now unused.
Signed-off-by: Laurent Pinchart
Reviewed-by: Tomi Val
Move the code that computes the DRM connector type for the
omapdss_device display type to a new omapdss_device_connector_type()
function for later reuse.
Signed-off-by: Laurent Pinchart
Reviewed-by: Tomi Valkeinen
Acked-by: Sam Ravnborg
Tested-by: Sebastian Reichel
Reviewed-by: Sebastian Reich
Now that the omap_dss_device EDID read operation has been removed,
simplify the bridge-based EDID access by merging multiple functions
together.
Signed-off-by: Laurent Pinchart
Reviewed-by: Tomi Valkeinen
Tested-by: Sebastian Reichel
Reviewed-by: Sebastian Reichel
---
drivers/gpu/drm/omapdrm/
The omap_dss_device .pre_enable(), .post_disable() and .set_timings()
are not used anymore. Remove them.
Signed-off-by: Laurent Pinchart
Reviewed-by: Tomi Valkeinen
Tested-by: Sebastian Reichel
Reviewed-by: Sebastian Reichel
---
drivers/gpu/drm/omapdrm/dss/base.c | 26 ---
dri
When the DSS initialises its output DPI and SDI ports, failures don't
clean up previous successfully initialised ports. This can lead to
resource leak or memory corruption. Fix it.
Reported-by: Hans Verkuil
Signed-off-by: Laurent Pinchart
Reviewed-by: Tomi Valkeinen
Acked-by: Sam Ravnborg
Test
The omapdss_of_find_connected_device() function isn't used anymore,
remove it.
Signed-off-by: Laurent Pinchart
Reviewed-by: Tomi Valkeinen
Tested-by: Sebastian Reichel
Reviewed-by: Sebastian Reichel
---
drivers/gpu/drm/omapdrm/dss/Makefile | 2 +-
drivers/gpu/drm/omapdrm/dss/dss-of.c | 28
Inline the omapdss_display_get() in its only caller to simplify the
code.
Signed-off-by: Laurent Pinchart
Reviewed-by: Tomi Valkeinen
Tested-by: Sebastian Reichel
Reviewed-by: Sebastian Reichel
---
drivers/gpu/drm/omapdrm/dss/display.c | 9 -
drivers/gpu/drm/omapdrm/dss/omapdss.h | 1
Due to the removal of several omapdrm display drivers, the omapdss HPD,
detected and EDID operations are not used anymore. Remove them and all
related code.
Signed-off-by: Laurent Pinchart
Reviewed-by: Tomi Valkeinen
Tested-by: Sebastian Reichel
Reviewed-by: Sebastian Reichel
---
drivers/gpu/
The omap_connector implementation is now used for DSI only. Hardcode its
type and drop unused code.
Signed-off-by: Laurent Pinchart
Tested-by: Sebastian Reichel
Reviewed-by: Sebastian Reichel
Reviewed-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/dss/base.c | 23 --
dri
On Fri, Feb 21, 2020 at 10:02:46PM +0100, Daniel Vetter wrote:
> These are the leftover drivers that didn't have a ->release hook that
> needed to be updated.
>
> Signed-off-by: Daniel Vetter
> Cc: "James (Qian) Wang"
> Cc: Liviu Dudau
> Cc: Mihail Atanassov
> Cc: Russell King
> Cc: Hans de G
The drm_driver structure contains pointers to functions, which can be an
attack vector if an attacker can corrupt the structure. The DRM core
however never modifies the structure, so it could be declared as const
in drivers. Modify the DRM core to take const struct drm_driver
pointers in all APIs.
The drm_driver structure contains a single field (legacy_dev_list) that
is modified by the DRM core, used to store a linked list of legacy DRM
devices associated with the driver. In order to make the structure
const, move the field out to a global variable. This requires locking
access to the globa
The drm_driver structure is never modified, make it const. The improves
security by avoiding writable function pointers.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/rcar_du_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_d
Hello,
This patch series makes it possible for DRM drivers to declare their
struct drm_driver as a static const. This improves security by avoiding
function pointers in writable memory.
The change turned out to be fairly easy, with preparation in patch 1/3
that moves the only non-const field out
On Sat, Feb 22, 2020 at 4:01 PM Laurent Pinchart
wrote:
>
> Clean up the drm_bridge overview documentation, and expand the
> operations documentation to provide more details on API usage.
>
> Signed-off-by: Laurent Pinchart
> ---
> Documentation/gpu/drm-kms-helpers.rst | 6 +--
> drivers/gpu/dr
Hi Daniel,
On Sat, Feb 22, 2020 at 04:32:58PM +0100, Daniel Vetter wrote:
> On Sat, Feb 22, 2020 at 4:01 PM Laurent Pinchart wrote:
> >
> > Clean up the drm_bridge overview documentation, and expand the
> > operations documentation to provide more details on API usage.
> >
> > Signed-off-by: Laure
On Sat, Feb 22, 2020 at 4:01 PM Laurent Pinchart
wrote:
>
> To support implementation of DRM connectors on top of DRM bridges
> instead of by bridges, the drm_bridge needs to expose new operations and
> data:
>
> - Output detection, hot-plug notification, mode retrieval and EDID
> retrieval oper
On Sat, Feb 22, 2020 at 4:01 PM Laurent Pinchart
wrote:
>
> Most bridge drivers create a DRM connector to model the connector at the
> output of the bridge. This model is historical and has worked pretty
> well so far, but causes several issues:
>
> - It prevents supporting more complex display pi
Clean up the drm_bridge overview documentation, and expand the
operations documentation to provide more details on API usage.
Signed-off-by: Laurent Pinchart
Reviewed-by: Daniel Vetter
---
Change since v7:
- Detail how bridge operations are used by atomic helpers
---
Documentation/gpu/drm-kms-
Most bridge drivers create a DRM connector to model the connector at the
output of the bridge. This model is historical and has worked pretty
well so far, but causes several issues:
- It prevents supporting more complex display pipelines where DRM
connector operations are split over multiple compo
Most bridge drivers create a DRM connector to model the connector at the
output of the bridge. This model is historical and has worked pretty
well so far, but causes several issues:
- It prevents supporting more complex display pipelines where DRM
connector operations are split over multiple compo
On Sat, Feb 22, 2020 at 10:00:03AM +0100, Mauro Carvalho Chehab wrote:
> Several references got broken due to txt to ReST conversion.
>
> Several of them can be automatically fixed with:
>
> scripts/documentation-file-ref-check --fix
>
> Signed-off-by: Mauro Carvalho Chehab
> ---
> Docum
This doesn't do anything except auto-init drm_agp support when you
call drm_get_pci_dev(). Which amdgpu stopped doing with
commit b58c11314a1706bf094c489ef5cb28f76478c704
Author: Alex Deucher
Date: Fri Jun 2 17:16:31 2017 -0400
drm/amdgpu: drop deprecated drm_get_pci_dev and drm_put_dev
N
It's the last user, and more importantly, it's the last non-legacy
user of anything in drm_pci.c.
The only tricky bit is the agp initialization. But a close look shows
that radeon does not use the drm_agp midlayer (the main use of that is
drm_bufs for legacy drivers), and instead could use the agp
Only user left is the shadow attach for legacy drivers.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_pci.c | 22 +++---
include/drm/drm_pci.h | 11 ---
2 files changed, 3 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/drm_pci.c b/drivers/gpu/drm/
On Sat, Feb 22, 2020 at 05:24:28PM +0200, Laurent Pinchart wrote:
> The drm_driver structure contains a single field (legacy_dev_list) that
> is modified by the DRM core, used to store a linked list of legacy DRM
> devices associated with the driver. In order to make the structure
> const, move the
On Sat, Feb 22, 2020 at 05:24:29PM +0200, Laurent Pinchart wrote:
> The drm_driver structure contains pointers to functions, which can be an
> attack vector if an attacker can corrupt the structure. The DRM core
> however never modifies the structure, so it could be declared as const
> in drivers.
On Sat, Feb 22, 2020 at 05:24:30PM +0200, Laurent Pinchart wrote:
> The drm_driver structure is never modified, make it const. The improves
> security by avoiding writable function pointers.
>
> Signed-off-by: Laurent Pinchart
I wonder whether there's some magic somewhere we could do to enlist t
On 2020-02-21 09:20, Daniel Vetter wrote:
On Thu, Feb 20, 2020 at 01:24:00PM -0800, jsa...@codeaurora.org wrote:
On 2020-02-20 12:14, Daniel Vetter wrote:
> On Thu, Feb 20, 2020 at 10:45:57AM -0800, jsa...@codeaurora.org wrote:
> > Hello All,
> >
> > I am seeking recommendations for DRM compatib
Hi Kevin/tang.
Thanks for the quick and detailed feedback.
Your questions are addressed below.
Sam
> > > +static int sprd_drm_bind(struct device *dev)
> > > +{
> > > + struct drm_device *drm;
> > > + struct sprd_drm *sprd;
> > > + int err;
> > > +
> > > + drm = drm_dev_a
Hi Qiang,
I love your patch! Yet something to improve:
[auto build test ERROR on drm-tip/drm-tip]
[cannot apply to drm-exynos/exynos-drm-next drm-intel/for-linux-next
tegra-drm/drm/tegra/for-next linus/master v5.6-rc2 next-20200221]
[if your patch is applied to the wrong git tree, please drop us
From: Sean Paul
[ Upstream commit db735fc4036bbe1fbe606819b5f0ff26cc76cdff ]
Turning on CONFIG_DMA_API_DEBUG_SG results in the following error:
[ 12.078665] msm ae0.mdss: DMA-API: mapping sg segment longer than device
claims to support [len=3526656] [max=65536]
[ 12.089870] WARNING: CP
From: Isabel Zhang
[ Upstream commit c134c3cabae46a56ab2e1f5e5fa49405e1758838 ]
[Why]
Starting from 14nm, the PLL is built into the PHY and the PLL is mapped
to PHY on 1 to 1 basis. In the code, the DP port is mapped to a PLL that was not
initialized. This causes DP to HDMI dongle to not light u
1 - 100 of 113 matches
Mail list logo
