mirror of
https://github.com/BobTheBlinker/android_kernel_motorola_sm6375.git
synced 2026-10-29 11:11:45 -04:00
Merge branch 'drm-next' of git://people.freedesktop.org/~airlied/linux
Pull drm updates from Dave Airlie:
"I Was Almost Tempted To Capitalise Every Word, but then I decided I
couldn't read it myself!
I've also got one pull request for the sti driver outstanding. It
relied on a commit in Greg's tree and I didn't find out in time, that
commit is in your tree now so I might send that along once this is
merged.
I also had the accidental misfortune to have access to a Skylake on my
desk for a few days, and I've had to encourage Intel to try harder,
which seems to be happening now.
Here is the main drm-next pull request for 4.4.
Highlights:
New driver:
vc4 driver for the Rasberry Pi VPU.
(From Eric Anholt at Broadcom.)
Core:
Atomic fbdev support
Atomic helpers for runtime pm
dp/aux i2c STATUS_UPDATE handling
struct_mutex usage cleanups.
Generic of probing support.
Documentation:
Kerneldoc for VGA switcheroo code.
Rename to gpu instead of drm to reflect scope.
i915:
Skylake GuC firmware fixes
HPD A support
VBT backlight fallbacks
Fastboot by default for some systems
FBC work
BXT/SKL workarounds
Skylake deeper sleep state fixes
amdgpu:
Enable GPU scheduler by default
New atombios opcodes
GPUVM debugging options
Stoney support.
Fencing cleanups.
radeon:
More efficient CS checking
nouveau:
gk20a instance memory handling improvements.
Improved PGOB detection and GK107 support
Kepler GDDR5 PLL statbility improvement
G8x/GT2xx reclock improvements
new userspace API compatiblity fixes.
virtio-gpu:
Add 3D support - qemu 2.5 has it merged for it's gtk backend.
msm:
Initial msm88896 (snapdragon 8200)
exynos:
HDMI cleanups
Enable mixer driver byt default
Add DECON-TV support
vmwgfx:
Move to using memremap + fixes.
rcar-du:
Add support for R8A7793/4 DU
armada:
Remove support for non-component mode
Improved plane handling
Power savings while in DPMS off.
tda998x:
Remove unused slave encoder support
Use more HDMI helpers
Fix EDID read handling
dwhdmi:
Interlace video mode support for ipu-v3/dw_hdmi
Hotplug state fixes
Audio driver integration
imx:
More color formats support.
tegra:
Minor fixes/improvements"
[ Merge fixup: remove unused variable 'dev' that had all uses removed in
commit 4e270f0880: "drm/gem: Drop struct_mutex requirement from
drm_gem_mmap_obj" ]
* 'drm-next' of git://people.freedesktop.org/~airlied/linux: (764 commits)
drm/vmwgfx: Relax irq locking somewhat
drm/vmwgfx: Properly flush cursor updates and page-flips
drm/i915/skl: disable display side power well support for now
drm/i915: Extend DSL readout fix to BDW and SKL.
drm/i915: Do graphics device reset under forcewake
drm/i915: Skip fence installation for objects with rotated views (v4)
vga_switcheroo: Drop client power state VGA_SWITCHEROO_INIT
drm/amdgpu: group together common fence implementation
drm/amdgpu: remove AMDGPU_FENCE_OWNER_MOVE
drm/amdgpu: remove now unused fence functions
drm/amdgpu: fix fence fallback check
drm/amdgpu: fix stoping the scheduler timeout
drm/amdgpu: cleanup on error in amdgpu_cs_ioctl()
drm/i915: Fix locking around GuC firmware load
drm/amdgpu: update Fiji's Golden setting
drm/amdgpu: update Fiji's rev id
drm/amdgpu: extract common code in vi_common_early_init
drm/amd/scheduler: don't oops on failure to load
drm/amdgpu: don't oops on failure to load (v2)
drm/amdgpu: don't VT switch on suspend
...
This commit is contained in:
Linus Torvalds
commit
3e82806b97
468 changed files with 53369 additions and 9828 deletions
|
|
@ -14,7 +14,7 @@ DOCBOOKS := z8530book.xml device-drivers.xml \
|
|||
genericirq.xml s390-drivers.xml uio-howto.xml scsi.xml \
|
||||
80211.xml debugobjects.xml sh.xml regulator.xml \
|
||||
alsa-driver-api.xml writing-an-alsa-driver.xml \
|
||||
tracepoint.xml drm.xml media_api.xml w1.xml \
|
||||
tracepoint.xml gpu.xml media_api.xml w1.xml \
|
||||
writing_musb_glue_layer.xml crypto-API.xml iio.xml
|
||||
|
||||
include Documentation/DocBook/media/Makefile
|
||||
|
|
|
|||
|
|
@ -2,9 +2,9 @@
|
|||
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
|
||||
"http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" []>
|
||||
|
||||
<book id="drmDevelopersGuide">
|
||||
<book id="gpuDevelopersGuide">
|
||||
<bookinfo>
|
||||
<title>Linux DRM Developer's Guide</title>
|
||||
<title>Linux GPU Driver Developer's Guide</title>
|
||||
|
||||
<authorgroup>
|
||||
<author>
|
||||
|
|
@ -40,6 +40,16 @@
|
|||
</address>
|
||||
</affiliation>
|
||||
</author>
|
||||
<author>
|
||||
<firstname>Lukas</firstname>
|
||||
<surname>Wunner</surname>
|
||||
<contrib>vga_switcheroo documentation</contrib>
|
||||
<affiliation>
|
||||
<address>
|
||||
<email>[email protected]</email>
|
||||
</address>
|
||||
</affiliation>
|
||||
</author>
|
||||
</authorgroup>
|
||||
|
||||
<copyright>
|
||||
|
|
@ -51,6 +61,10 @@
|
|||
<year>2012</year>
|
||||
<holder>Laurent Pinchart</holder>
|
||||
</copyright>
|
||||
<copyright>
|
||||
<year>2015</year>
|
||||
<holder>Lukas Wunner</holder>
|
||||
</copyright>
|
||||
|
||||
<legalnotice>
|
||||
<para>
|
||||
|
|
@ -69,6 +83,13 @@
|
|||
<revremark>Added extensive documentation about driver internals.
|
||||
</revremark>
|
||||
</revision>
|
||||
<revision>
|
||||
<revnumber>1.1</revnumber>
|
||||
<date>2015-10-11</date>
|
||||
<authorinitials>LW</authorinitials>
|
||||
<revremark>Added vga_switcheroo documentation.
|
||||
</revremark>
|
||||
</revision>
|
||||
</revhistory>
|
||||
</bookinfo>
|
||||
|
||||
|
|
@ -78,9 +99,9 @@
|
|||
<title>DRM Core</title>
|
||||
<partintro>
|
||||
<para>
|
||||
This first part of the DRM Developer's Guide documents core DRM code,
|
||||
helper libraries for writing drivers and generic userspace interfaces
|
||||
exposed by DRM drivers.
|
||||
This first part of the GPU Driver Developer's Guide documents core DRM
|
||||
code, helper libraries for writing drivers and generic userspace
|
||||
interfaces exposed by DRM drivers.
|
||||
</para>
|
||||
</partintro>
|
||||
|
||||
|
|
@ -138,14 +159,10 @@
|
|||
<para>
|
||||
At the core of every DRM driver is a <structname>drm_driver</structname>
|
||||
structure. Drivers typically statically initialize a drm_driver structure,
|
||||
and then pass it to one of the <function>drm_*_init()</function> functions
|
||||
to register it with the DRM subsystem.
|
||||
</para>
|
||||
<para>
|
||||
Newer drivers that no longer require a <structname>drm_bus</structname>
|
||||
structure can alternatively use the low-level device initialization and
|
||||
registration functions such as <function>drm_dev_alloc()</function> and
|
||||
<function>drm_dev_register()</function> directly.
|
||||
and then pass it to <function>drm_dev_alloc()</function> to allocate a
|
||||
device instance. After the device instance is fully initialized it can be
|
||||
registered (which makes it accessible from userspace) using
|
||||
<function>drm_dev_register()</function>.
|
||||
</para>
|
||||
<para>
|
||||
The <structname>drm_driver</structname> structure contains static
|
||||
|
|
@ -296,83 +313,12 @@ char *date;</synopsis>
|
|||
</sect3>
|
||||
</sect2>
|
||||
<sect2>
|
||||
<title>Device Registration</title>
|
||||
<para>
|
||||
A number of functions are provided to help with device registration.
|
||||
The functions deal with PCI and platform devices, respectively.
|
||||
</para>
|
||||
!Edrivers/gpu/drm/drm_pci.c
|
||||
!Edrivers/gpu/drm/drm_platform.c
|
||||
<para>
|
||||
New drivers that no longer rely on the services provided by the
|
||||
<structname>drm_bus</structname> structure can call the low-level
|
||||
device registration functions directly. The
|
||||
<function>drm_dev_alloc()</function> function can be used to allocate
|
||||
and initialize a new <structname>drm_device</structname> structure.
|
||||
Drivers will typically want to perform some additional setup on this
|
||||
structure, such as allocating driver-specific data and storing a
|
||||
pointer to it in the DRM device's <structfield>dev_private</structfield>
|
||||
field. Drivers should also set the device's unique name using the
|
||||
<function>drm_dev_set_unique()</function> function. After it has been
|
||||
set up a device can be registered with the DRM subsystem by calling
|
||||
<function>drm_dev_register()</function>. This will cause the device to
|
||||
be exposed to userspace and will call the driver's
|
||||
<structfield>.load()</structfield> implementation. When a device is
|
||||
removed, the DRM device can safely be unregistered and freed by calling
|
||||
<function>drm_dev_unregister()</function> followed by a call to
|
||||
<function>drm_dev_unref()</function>.
|
||||
</para>
|
||||
<title>Device Instance and Driver Handling</title>
|
||||
!Pdrivers/gpu/drm/drm_drv.c driver instance overview
|
||||
!Edrivers/gpu/drm/drm_drv.c
|
||||
</sect2>
|
||||
<sect2>
|
||||
<title>Driver Load</title>
|
||||
<para>
|
||||
The <methodname>load</methodname> method is the driver and device
|
||||
initialization entry point. The method is responsible for allocating and
|
||||
initializing driver private data, performing resource allocation and
|
||||
mapping (e.g. acquiring
|
||||
clocks, mapping registers or allocating command buffers), initializing
|
||||
the memory manager (<xref linkend="drm-memory-management"/>), installing
|
||||
the IRQ handler (<xref linkend="drm-irq-registration"/>), setting up
|
||||
vertical blanking handling (<xref linkend="drm-vertical-blank"/>), mode
|
||||
setting (<xref linkend="drm-mode-setting"/>) and initial output
|
||||
configuration (<xref linkend="drm-kms-init"/>).
|
||||
</para>
|
||||
<note><para>
|
||||
If compatibility is a concern (e.g. with drivers converted over from
|
||||
User Mode Setting to Kernel Mode Setting), care must be taken to prevent
|
||||
device initialization and control that is incompatible with currently
|
||||
active userspace drivers. For instance, if user level mode setting
|
||||
drivers are in use, it would be problematic to perform output discovery
|
||||
& configuration at load time. Likewise, if user-level drivers
|
||||
unaware of memory management are in use, memory management and command
|
||||
buffer setup may need to be omitted. These requirements are
|
||||
driver-specific, and care needs to be taken to keep both old and new
|
||||
applications and libraries working.
|
||||
</para></note>
|
||||
<synopsis>int (*load) (struct drm_device *, unsigned long flags);</synopsis>
|
||||
<para>
|
||||
The method takes two arguments, a pointer to the newly created
|
||||
<structname>drm_device</structname> and flags. The flags are used to
|
||||
pass the <structfield>driver_data</structfield> field of the device id
|
||||
corresponding to the device passed to <function>drm_*_init()</function>.
|
||||
Only PCI devices currently use this, USB and platform DRM drivers have
|
||||
their <methodname>load</methodname> method called with flags to 0.
|
||||
</para>
|
||||
<sect3>
|
||||
<title>Driver Private Data</title>
|
||||
<para>
|
||||
The driver private hangs off the main
|
||||
<structname>drm_device</structname> structure and can be used for
|
||||
tracking various device-specific bits of information, like register
|
||||
offsets, command buffer status, register state for suspend/resume, etc.
|
||||
At load time, a driver may simply allocate one and set
|
||||
<structname>drm_device</structname>.<structfield>dev_priv</structfield>
|
||||
appropriately; it should be freed and
|
||||
<structname>drm_device</structname>.<structfield>dev_priv</structfield>
|
||||
set to NULL when the driver is unloaded.
|
||||
</para>
|
||||
</sect3>
|
||||
<sect3 id="drm-irq-registration">
|
||||
<title>IRQ Registration</title>
|
||||
<para>
|
||||
|
|
@ -465,6 +411,18 @@ char *date;</synopsis>
|
|||
</para>
|
||||
</sect3>
|
||||
</sect2>
|
||||
<sect2>
|
||||
<title>Bus-specific Device Registration and PCI Support</title>
|
||||
<para>
|
||||
A number of functions are provided to help with device registration.
|
||||
The functions deal with PCI and platform devices respectively and are
|
||||
only provided for historical reasons. These are all deprecated and
|
||||
shouldn't be used in new drivers. Besides that there's a few
|
||||
helpers for pci drivers.
|
||||
</para>
|
||||
!Edrivers/gpu/drm/drm_pci.c
|
||||
!Edrivers/gpu/drm/drm_platform.c
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
<!-- Internals: memory management -->
|
||||
|
|
@ -3646,10 +3604,11 @@ void (*postclose) (struct drm_device *, struct drm_file *);</synopsis>
|
|||
plane properties to default value, so that a subsequent open of the
|
||||
device will not inherit state from the previous user. It can also be
|
||||
used to execute delayed power switching state changes, e.g. in
|
||||
conjunction with the vga-switcheroo infrastructure. Beyond that KMS
|
||||
drivers should not do any further cleanup. Only legacy UMS drivers might
|
||||
need to clean up device state so that the vga console or an independent
|
||||
fbdev driver could take over.
|
||||
conjunction with the vga_switcheroo infrastructure (see
|
||||
<xref linkend="vga_switcheroo"/>). Beyond that KMS drivers should not
|
||||
do any further cleanup. Only legacy UMS drivers might need to clean up
|
||||
device state so that the vga console or an independent fbdev driver
|
||||
could take over.
|
||||
</para>
|
||||
</sect2>
|
||||
<sect2>
|
||||
|
|
@ -3747,11 +3706,14 @@ int num_ioctls;</synopsis>
|
|||
</para></listitem>
|
||||
<listitem><para>
|
||||
DRM_UNLOCKED - The ioctl handler will be called without locking
|
||||
the DRM global mutex
|
||||
the DRM global mutex. This is the enforced default for kms drivers
|
||||
(i.e. using the DRIVER_MODESET flag) and hence shouldn't be used
|
||||
any more for new drivers.
|
||||
</para></listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
</para>
|
||||
!Edrivers/gpu/drm/drm_ioctl.c
|
||||
</sect2>
|
||||
</sect1>
|
||||
<sect1>
|
||||
|
|
@ -3949,8 +3911,8 @@ int num_ioctls;</synopsis>
|
|||
|
||||
<partintro>
|
||||
<para>
|
||||
This second part of the DRM Developer's Guide documents driver code,
|
||||
implementation details and also all the driver-specific userspace
|
||||
This second part of the GPU Driver Developer's Guide documents driver
|
||||
code, implementation details and also all the driver-specific userspace
|
||||
interfaces. Especially since all hardware-acceleration interfaces to
|
||||
userspace are driver specific for efficiency and other reasons these
|
||||
interfaces can be rather substantial. Hence every driver has its own
|
||||
|
|
@ -4051,6 +4013,7 @@ int num_ioctls;</synopsis>
|
|||
<title>High Definition Audio</title>
|
||||
!Pdrivers/gpu/drm/i915/intel_audio.c High Definition Audio over HDMI and Display Port
|
||||
!Idrivers/gpu/drm/i915/intel_audio.c
|
||||
!Iinclude/drm/i915_component.h
|
||||
</sect2>
|
||||
<sect2>
|
||||
<title>Panel Self Refresh PSR (PSR/SRD)</title>
|
||||
|
|
@ -4237,6 +4200,20 @@ int num_ioctls;</synopsis>
|
|||
!Idrivers/gpu/drm/i915/i915_gem_shrinker.c
|
||||
</sect2>
|
||||
</sect1>
|
||||
<sect1>
|
||||
<title>GuC-based Command Submission</title>
|
||||
<sect2>
|
||||
<title>GuC</title>
|
||||
!Pdrivers/gpu/drm/i915/intel_guc_loader.c GuC-specific firmware loader
|
||||
!Idrivers/gpu/drm/i915/intel_guc_loader.c
|
||||
</sect2>
|
||||
<sect2>
|
||||
<title>GuC Client</title>
|
||||
!Pdrivers/gpu/drm/i915/i915_guc_submission.c GuC-based command submissison
|
||||
!Idrivers/gpu/drm/i915/i915_guc_submission.c
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title> Tracing </title>
|
||||
<para>
|
||||
|
|
@ -4260,4 +4237,50 @@ int num_ioctls;</synopsis>
|
|||
</chapter>
|
||||
!Cdrivers/gpu/drm/i915/i915_irq.c
|
||||
</part>
|
||||
|
||||
<part id="vga_switcheroo">
|
||||
<title>vga_switcheroo</title>
|
||||
<partintro>
|
||||
!Pdrivers/gpu/vga/vga_switcheroo.c Overview
|
||||
</partintro>
|
||||
|
||||
<chapter id="modes_of_use">
|
||||
<title>Modes of Use</title>
|
||||
<sect1>
|
||||
<title>Manual switching and manual power control</title>
|
||||
!Pdrivers/gpu/vga/vga_switcheroo.c Manual switching and manual power control
|
||||
</sect1>
|
||||
<sect1>
|
||||
<title>Driver power control</title>
|
||||
!Pdrivers/gpu/vga/vga_switcheroo.c Driver power control
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
<chapter id="pubfunctions">
|
||||
<title>Public functions</title>
|
||||
!Edrivers/gpu/vga/vga_switcheroo.c
|
||||
</chapter>
|
||||
|
||||
<chapter id="pubstructures">
|
||||
<title>Public structures</title>
|
||||
!Finclude/linux/vga_switcheroo.h vga_switcheroo_handler
|
||||
!Finclude/linux/vga_switcheroo.h vga_switcheroo_client_ops
|
||||
</chapter>
|
||||
|
||||
<chapter id="pubconstants">
|
||||
<title>Public constants</title>
|
||||
!Finclude/linux/vga_switcheroo.h vga_switcheroo_client_id
|
||||
!Finclude/linux/vga_switcheroo.h vga_switcheroo_state
|
||||
</chapter>
|
||||
|
||||
<chapter id="privstructures">
|
||||
<title>Private structures</title>
|
||||
!Fdrivers/gpu/vga/vga_switcheroo.c vgasr_priv
|
||||
!Fdrivers/gpu/vga/vga_switcheroo.c vga_switcheroo_client
|
||||
</chapter>
|
||||
|
||||
!Cdrivers/gpu/vga/vga_switcheroo.c
|
||||
!Cinclude/linux/vga_switcheroo.h
|
||||
</part>
|
||||
|
||||
</book>
|
||||
65
Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt
Normal file
65
Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt
Normal file
|
|
@ -0,0 +1,65 @@
|
|||
Broadcom VC4 (VideoCore4) GPU
|
||||
|
||||
The VC4 device present on the Raspberry Pi includes a display system
|
||||
with HDMI output and the HVS (Hardware Video Scaler) for compositing
|
||||
display planes.
|
||||
|
||||
Required properties for VC4:
|
||||
- compatible: Should be "brcm,bcm2835-vc4"
|
||||
|
||||
Required properties for Pixel Valve:
|
||||
- compatible: Should be one of "brcm,bcm2835-pixelvalve0",
|
||||
"brcm,bcm2835-pixelvalve1", or "brcm,bcm2835-pixelvalve2"
|
||||
- reg: Physical base address and length of the PV's registers
|
||||
- interrupts: The interrupt number
|
||||
See bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt
|
||||
|
||||
Required properties for HVS:
|
||||
- compatible: Should be "brcm,bcm2835-hvs"
|
||||
- reg: Physical base address and length of the HVS's registers
|
||||
- interrupts: The interrupt number
|
||||
See bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt
|
||||
|
||||
Required properties for HDMI
|
||||
- compatible: Should be "brcm,bcm2835-hdmi"
|
||||
- reg: Physical base address and length of the two register ranges
|
||||
("HDMI" and "HD", in that order)
|
||||
- interrupts: The interrupt numbers
|
||||
See bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt
|
||||
- ddc: phandle of the I2C controller used for DDC EDID probing
|
||||
- clocks: a) hdmi: The HDMI state machine clock
|
||||
b) pixel: The pixel clock.
|
||||
|
||||
Optional properties for HDMI:
|
||||
- hpd-gpios: The GPIO pin for HDMI hotplug detect (if it doesn't appear
|
||||
as an interrupt/status bit in the HDMI controller
|
||||
itself). See bindings/pinctrl/brcm,bcm2835-gpio.txt
|
||||
|
||||
Example:
|
||||
pixelvalve@7e807000 {
|
||||
compatible = "brcm,bcm2835-pixelvalve2";
|
||||
reg = <0x7e807000 0x100>;
|
||||
interrupts = <2 10>; /* pixelvalve */
|
||||
};
|
||||
|
||||
hvs@7e400000 {
|
||||
compatible = "brcm,bcm2835-hvs";
|
||||
reg = <0x7e400000 0x6000>;
|
||||
interrupts = <2 1>;
|
||||
};
|
||||
|
||||
hdmi: hdmi@7e902000 {
|
||||
compatible = "brcm,bcm2835-hdmi";
|
||||
reg = <0x7e902000 0x600>,
|
||||
<0x7e808000 0x100>;
|
||||
interrupts = <2 8>, <2 9>;
|
||||
ddc = <&i2c2>;
|
||||
hpd-gpios = <&gpio 46 GPIO_ACTIVE_HIGH>;
|
||||
clocks = <&clocks BCM2835_PLLH_PIX>,
|
||||
<&clocks BCM2835_CLOCK_HSM>;
|
||||
clock-names = "pixel", "hdmi";
|
||||
};
|
||||
|
||||
vc4: gpu {
|
||||
compatible = "brcm,bcm2835-vc4";
|
||||
};
|
||||
|
|
@ -2,6 +2,7 @@ Qualcomm adreno/snapdragon hdmi output
|
|||
|
||||
Required properties:
|
||||
- compatible: one of the following
|
||||
* "qcom,hdmi-tx-8996"
|
||||
* "qcom,hdmi-tx-8994"
|
||||
* "qcom,hdmi-tx-8084"
|
||||
* "qcom,hdmi-tx-8974"
|
||||
|
|
@ -21,6 +22,7 @@ Required properties:
|
|||
Optional properties:
|
||||
- qcom,hdmi-tx-mux-en-gpio: hdmi mux enable pin
|
||||
- qcom,hdmi-tx-mux-sel-gpio: hdmi mux select pin
|
||||
- power-domains: reference to the power domain(s), if available.
|
||||
- pinctrl-names: the pin control state names; should contain "default"
|
||||
- pinctrl-0: the default pinctrl state (active)
|
||||
- pinctrl-1: the "sleep" pinctrl state
|
||||
|
|
@ -35,6 +37,7 @@ Example:
|
|||
reg-names = "core_physical";
|
||||
reg = <0x04a00000 0x1000>;
|
||||
interrupts = <GIC_SPI 79 0>;
|
||||
power-domains = <&mmcc MDSS_GDSC>;
|
||||
clock-names =
|
||||
"core_clk",
|
||||
"master_iface_clk",
|
||||
|
|
|
|||
|
|
@ -11,13 +11,14 @@ Required properties:
|
|||
- clock-names: the following clocks are required:
|
||||
* "core_clk"
|
||||
* "iface_clk"
|
||||
* "lut_clk"
|
||||
* "src_clk"
|
||||
* "hdmi_clk"
|
||||
* "mpd_clk"
|
||||
|
||||
Optional properties:
|
||||
- gpus: phandle for gpu device
|
||||
- clock-names: the following clocks are optional:
|
||||
* "lut_clk"
|
||||
|
||||
Example:
|
||||
|
||||
|
|
|
|||
|
|
@ -5,7 +5,9 @@ Required Properties:
|
|||
- compatible: must be one of the following.
|
||||
- "renesas,du-r8a7779" for R8A7779 (R-Car H1) compatible DU
|
||||
- "renesas,du-r8a7790" for R8A7790 (R-Car H2) compatible DU
|
||||
- "renesas,du-r8a7791" for R8A7791 (R-Car M2) compatible DU
|
||||
- "renesas,du-r8a7791" for R8A7791 (R-Car M2-W) compatible DU
|
||||
- "renesas,du-r8a7793" for R8A7793 (R-Car M2-N) compatible DU
|
||||
- "renesas,du-r8a7794" for R8A7794 (R-Car E2) compatible DU
|
||||
|
||||
- reg: A list of base address and length of each memory resource, one for
|
||||
each entry in the reg-names property.
|
||||
|
|
@ -22,9 +24,9 @@ Required Properties:
|
|||
- clock-names: Name of the clocks. This property is model-dependent.
|
||||
- R8A7779 uses a single functional clock. The clock doesn't need to be
|
||||
named.
|
||||
- R8A7790 and R8A7791 use one functional clock per channel and one clock
|
||||
per LVDS encoder. The functional clocks must be named "du.x" with "x"
|
||||
being the channel numerical index. The LVDS clocks must be named
|
||||
- R8A779[0134] use one functional clock per channel and one clock per LVDS
|
||||
encoder (if available). The functional clocks must be named "du.x" with
|
||||
"x" being the channel numerical index. The LVDS clocks must be named
|
||||
"lvds.x" with "x" being the LVDS encoder numerical index.
|
||||
- In addition to the functional and encoder clocks, all DU versions also
|
||||
support externally supplied pixel clocks. Those clocks are optional.
|
||||
|
|
@ -43,7 +45,9 @@ corresponding to each DU output.
|
|||
-----------------------------------------------------------------------------
|
||||
R8A7779 (H1) DPAD 0 DPAD 1 -
|
||||
R8A7790 (H2) DPAD LVDS 0 LVDS 1
|
||||
R8A7791 (M2) DPAD LVDS 0 -
|
||||
R8A7791 (M2-W) DPAD LVDS 0 -
|
||||
R8A7793 (M2-N) DPAD LVDS 0 -
|
||||
R8A7794 (E2) DPAD 0 DPAD 1 -
|
||||
|
||||
|
||||
Example: R8A7790 (R-Car H2) DU
|
||||
|
|
|
|||
|
|
@ -932,11 +932,11 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
|
|||
The filter can be disabled or changed to another
|
||||
driver later using sysfs.
|
||||
|
||||
drm_kms_helper.edid_firmware=[<connector>:]<file>
|
||||
Broken monitors, graphic adapters and KVMs may
|
||||
send no or incorrect EDID data sets. This parameter
|
||||
allows to specify an EDID data set in the
|
||||
/lib/firmware directory that is used instead.
|
||||
drm_kms_helper.edid_firmware=[<connector>:]<file>[,[<connector>:]<file>]
|
||||
Broken monitors, graphic adapters, KVMs and EDIDless
|
||||
panels may send no or incorrect EDID data sets.
|
||||
This parameter allows to specify an EDID data sets
|
||||
in the /lib/firmware directory that are used instead.
|
||||
Generic built-in EDID data sets are used, if one of
|
||||
edid/1024x768.bin, edid/1280x1024.bin,
|
||||
edid/1680x1050.bin, or edid/1920x1080.bin is given
|
||||
|
|
@ -945,7 +945,10 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
|
|||
available in Documentation/EDID/HOWTO.txt. An EDID
|
||||
data set will only be used for a particular connector,
|
||||
if its name and a colon are prepended to the EDID
|
||||
name.
|
||||
name. Each connector may use a unique EDID data
|
||||
set by separating the files with a comma. An EDID
|
||||
data set with no connector name will be used for
|
||||
any connectors not explicitly specified.
|
||||
|
||||
dscc4.setup= [NET]
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue