To complement panel-simple.yaml, create panel-simple-lvds-dual-ports.yaml.
panel-simple-lvds-dual-ports.yaml is for all simple LVDS panels that
have dual LVDS ports and require only a single power-supply.
The first port receives odd pixels, and the second port receives even pixels.
Optionally, a backlight and an enable GPIO can be specified as properties.
Panels with swapped pixel order, if any, need dedicated bindings.
Migrate 'auo,g133han01', 'auo,g185han01', 'auo,g190ean01',
'koe,…
[View More]tx26d202vm0bwa' and 'nlt,nl192108ac18-02d' over to the new file.
The objectives with one file for all the simple LVDS panels with dual ports are:
- Make it simpler to add bindings for this kind of LVDS panels
- Keep the number of bindings file lower
- Keep the binding documentation for this kind of LVDS panels more consistent
- Make it possible for drivers to get pixel order via
drm_of_lvds_get_dual_link_pixel_order(), as the 'ports' property is required
Suggested-by: Sam Ravnborg <sam(a)ravnborg.org>
Cc: Thierry Reding <thierry.reding(a)gmail.com>
Cc: Sam Ravnborg <sam(a)ravnborg.org>
Cc: David Airlie <airlied(a)linux.ie>
Cc: Daniel Vetter <daniel(a)ffwll.ch>
Cc: Rob Herring <robh+dt(a)kernel.org>
Cc: Lucas Stach <l.stach(a)pengutronix.de>
Cc: Sebastian Reichel <sebastian.reichel(a)collabora.com>
Signed-off-by: Liu Ying <victor.liu(a)nxp.com>
---
v5->v6:
* Use OF graph schema.
* Drop Rob's R-b tag, as review is needed.
v4->v5:
* Require the 'ports' property and update commit message accordingly. (Rob)
* Add Rob's R-b tag.
v3->v4:
* Add type and descriptions for dual-lvds-{odd,even}-pixels properties.
Also, update descriptions for port@0 and port@1 properties accordingly. (Rob)
v2->v3:
* Do not allow 'port' property. (Rob)
* Define port number. (Rob)
* Specify 'dual-lvds-odd-pixels' and 'dual-lvds-even-pixels' properties. (Rob)
v1->v2:
* Correct pixel order in example LVDS panel node.
.../panel/panel-simple-lvds-dual-ports.yaml | 116 +++++++++++++++++++++
.../bindings/display/panel/panel-simple.yaml | 10 --
2 files changed, 116 insertions(+), 10 deletions(-)
create mode 100644 Documentation/devicetree/bindings/display/panel/panel-simple-lvds-dual-ports.yaml
diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple-lvds-dual-ports.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple-lvds-dual-ports.yaml
new file mode 100644
index 00000000..274e89b
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/panel-simple-lvds-dual-ports.yaml
@@ -0,0 +1,116 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/panel-simple-lvds-dual-ports.ya…
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Simple LVDS panels with one power supply and dual LVDS ports
+
+maintainers:
+ - Liu Ying <victor.liu(a)nxp.com>
+ - Thierry Reding <thierry.reding(a)gmail.com>
+ - Sam Ravnborg <sam(a)ravnborg.org>
+
+description: |
+ This binding file is a collection of the LVDS panels that
+ has dual LVDS ports and requires only a single power-supply.
+ The first port receives odd pixels, and the second port receives even pixels.
+ There are optionally a backlight and an enable GPIO.
+ The panel may use an OF graph binding for the association to the display,
+ or it may be a direct child node of the display.
+
+ If the panel is more advanced a dedicated binding file is required.
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+
+ compatible:
+ enum:
+ # compatible must be listed in alphabetical order, ordered by compatible.
+ # The description in the comment is mandatory for each compatible.
+
+ # AU Optronics Corporation 13.3" FHD (1920x1080) TFT LCD panel
+ - auo,g133han01
+ # AU Optronics Corporation 18.5" FHD (1920x1080) TFT LCD panel
+ - auo,g185han01
+ # AU Optronics Corporation 19.0" (1280x1024) TFT LCD panel
+ - auo,g190ean01
+ # Kaohsiung Opto-Electronics Inc. 10.1" WUXGA (1920 x 1200) LVDS TFT LCD panel
+ - koe,tx26d202vm0bwa
+ # NLT Technologies, Ltd. 15.6" FHD (1920x1080) LVDS TFT LCD panel
+ - nlt,nl192108ac18-02d
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: The first sink port.
+
+ properties:
+ dual-lvds-odd-pixels:
+ type: boolean
+ description: The first sink port for odd pixels.
+
+ required:
+ - dual-lvds-odd-pixels
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: The second sink port.
+
+ properties:
+ dual-lvds-even-pixels:
+ type: boolean
+ description: The second sink port for even pixels.
+
+ required:
+ - dual-lvds-even-pixels
+
+ required:
+ - port@0
+ - port@1
+
+ backlight: true
+ enable-gpios: true
+ power-supply: true
+
+additionalProperties: false
+
+required:
+ - compatible
+ - ports
+ - power-supply
+
+examples:
+ - |
+ panel: panel-lvds {
+ compatible = "koe,tx26d202vm0bwa";
+ power-supply = <&vdd_lcd_reg>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ dual-lvds-odd-pixels;
+ reg = <0>;
+
+ panel_lvds0_in: endpoint {
+ remote-endpoint = <&lvds0_out>;
+ };
+ };
+
+ port@1 {
+ dual-lvds-even-pixels;
+ reg = <1>;
+
+ panel_lvds1_in: endpoint {
+ remote-endpoint = <&lvds1_out>;
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
index 35b42ee..e7718d2 100644
--- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
+++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
@@ -57,14 +57,8 @@ properties:
- auo,g104sn02
# AU Optronics Corporation 12.1" (1280x800) TFT LCD panel
- auo,g121ean01
- # AU Optronics Corporation 13.3" FHD (1920x1080) TFT LCD panel
- - auo,g133han01
# AU Optronics Corporation 15.6" (1366x768) TFT LCD panel
- auo,g156xtn01
- # AU Optronics Corporation 18.5" FHD (1920x1080) TFT LCD panel
- - auo,g185han01
- # AU Optronics Corporation 19.0" (1280x1024) TFT LCD panel
- - auo,g190ean01
# AU Optronics Corporation 31.5" FHD (1920x1080) TFT LCD panel
- auo,p320hvn03
# AU Optronics Corporation 21.5" FHD (1920x1080) color TFT LCD panel
@@ -171,8 +165,6 @@ properties:
- kingdisplay,kd116n21-30nv-a010
# Kaohsiung Opto-Electronics Inc. 5.7" QVGA (320 x 240) TFT LCD panel
- koe,tx14d24vm1bpa
- # Kaohsiung Opto-Electronics Inc. 10.1" WUXGA (1920 x 1200) LVDS TFT LCD panel
- - koe,tx26d202vm0bwa
# Kaohsiung Opto-Electronics. TX31D200VM0BAA 12.3" HSXGA LVDS panel
- koe,tx31d200vm0baa
# Kyocera Corporation 12.1" XGA (1024x768) TFT LCD panel
@@ -209,8 +201,6 @@ properties:
- neweast,wjfh116008a
# Newhaven Display International 480 x 272 TFT LCD panel
- newhaven,nhd-4.3-480272ef-atxl
- # NLT Technologies, Ltd. 15.6" FHD (1920x1080) LVDS TFT LCD panel
- - nlt,nl192108ac18-02d
# New Vision Display 7.0" 800 RGB x 480 TFT LCD panel
- nvd,9128
# OKAYA Electric America, Inc. RS800480T-7X0GP 7" WVGA LCD panel
--
2.7.4
[View Less]
Next, let's start introducing the HPD pin mappings for Intel's new gen9_bc
platform in order to make hotplugging display connectors work. Since
gen9_bc is just a TGP PCH along with a CML CPU, except with the same HPD
mappings as ICL, we simply add a skl_hpd_pin function that is shared
between gen9 and gen9_bc which handles both the traditional gen9 HPD pin
mappings and the Icelake HPD pin mappings that gen9_bc uses.
Changes since v4:
* Split this into its own commit
* Introduce skl_hpd_pin() …
[View More]like vsyrjala suggested and use that instead of
sticking our HPD pin mappings in TGP code
Cc: Matt Roper <matthew.d.roper(a)intel.com>
Cc: Jani Nikula <jani.nikula(a)linux.intel.com>
Cc: Ville Syrjala <ville.syrjala(a)linux.intel.com>
[originally from Tejas's work]
Signed-off-by: Tejas Upadhyay <tejaskumarx.surendrakumar.upadhyay(a)intel.com>
Signed-off-by: Lyude Paul <lyude(a)redhat.com>
---
drivers/gpu/drm/i915/display/intel_ddi.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c b/drivers/gpu/drm/i915/display/intel_ddi.c
index 3c4003605f93..01b171f52694 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -3954,6 +3954,14 @@ static enum hpd_pin cnl_hpd_pin(struct drm_i915_private *dev_priv,
return HPD_PORT_A + port - PORT_A;
}
+static enum hpd_pin skl_hpd_pin(struct drm_i915_private *dev_priv, enum port port)
+{
+ if (HAS_PCH_TGP(dev_priv))
+ return icl_hpd_pin(dev_priv, port);
+
+ return HPD_PORT_A + port - PORT_A;
+}
+
#define port_tc_name(port) ((port) - PORT_TC1 + '1')
#define tc_port_name(tc_port) ((tc_port) - TC_PORT_1 + '1')
@@ -4070,6 +4078,8 @@ void intel_ddi_init(struct drm_i915_private *dev_priv, enum port port)
encoder->hpd_pin = icl_hpd_pin(dev_priv, port);
else if (IS_GEN(dev_priv, 10))
encoder->hpd_pin = cnl_hpd_pin(dev_priv, port);
+ else if (IS_GEN(dev_priv, 9))
+ encoder->hpd_pin = skl_hpd_pin(dev_priv, port);
else
encoder->hpd_pin = intel_hpd_pin_default(dev_priv, port);
--
2.29.2
[View Less]
This series adds support to Nouveau for atomic memory operations on OpenCL
shared virtual memory (SVM). This is achieved using the atomic PTE bits on
the GPU to only permit atomic operations to system memory when a page is
not mapped in userspace on the CPU.
This is implemented by adding a mode to migrate_vma_pages() which unmaps
and isolates existing pages from the CPU and pins them. The original
userspace page table entries are migrated to point to device private pages
allocated by the …
[View More]driver. This allows the driver to enable GPU atomic access
to the page as it will receive a callback when CPU userspace needs to
access it.
In response to this callback the driver revokes the atomic access
permission from the GPU and migrates entries to point back to the original
page. The original page is unpinned as part of the migration operation
which also returns it to the LRU.
Patch 3 contains the bulk of the memory management changes to implement
unmap and pin.
Patches 6-9 extend Nouveau to use the new mode to allow system wide atomics
for OpenCL SVM to be implemented on Nouveau.
This has been tested using the latest upstream Mesa userspace with a simple
OpenCL test program which checks the results of atomic GPU operations on a
buffer whilst also writing to the same buffer from the CPU.
Problems yet to be addressed:
Recent changes to pin_user_pages() prevent the creation of pinned pages in
ZONE_MOVABLE. This series allows pinned pages to be created in ZONE_MOVABLE
as attempts to migrate may fail which would be fatal to userspace.
In this case migration of the pinned page is unnecessary as the page can be
unpinned at anytime by having the driver revoke atomic permission as it
does for the migrate_to_ram() callback. However a method of calling this
when memory needs to be moved has yet to be resolved so any discussion is
welcome.
Alistair Popple (9):
mm/migrate.c: Always allow device private pages to migrate
mm/migrate.c: Allow pfn flags to be passed to migrate_vma_setup()
mm/migrate: Add a unmap and pin migration mode
Documentation: Add unmap and pin to HMM
hmm-tests: Add test for unmap and pin
nouveau/dmem: Only map migrating pages
nouveau/svm: Refactor nouveau_range_fault
nouveau/dmem: Add support for multiple page types
nouveau/svm: Implement atomic SVM access
Documentation/vm/hmm.rst | 22 +-
arch/powerpc/kvm/book3s_hv_uvmem.c | 4 +-
drivers/gpu/drm/nouveau/include/nvif/if000c.h | 1 +
drivers/gpu/drm/nouveau/nouveau_dmem.c | 190 +++++++++++++++---
drivers/gpu/drm/nouveau/nouveau_dmem.h | 9 +
drivers/gpu/drm/nouveau/nouveau_svm.c | 148 +++++++++++---
drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.h | 1 +
.../drm/nouveau/nvkm/subdev/mmu/vmmgp100.c | 6 +
include/linux/migrate.h | 2 +
include/linux/migrate_mode.h | 1 +
lib/test_hmm.c | 109 ++++++++--
lib/test_hmm_uapi.h | 1 +
mm/migrate.c | 82 +++++---
tools/testing/selftests/vm/hmm-tests.c | 49 +++++
14 files changed, 524 insertions(+), 101 deletions(-)
--
2.20.1
[View Less]
This series attempts to enable V3D on BCM2711, the SoC available on the
Raspberry Pi 4 family of boards.
Due to the lack of documentation some things are taken as it from
testing/downstream implementation[1], which I'm hilighting here:
- It's not clear that the following is 100% true, maybe someone can confirm:
"In BCM2711 the new ARGON ASB took over V3D. The old ASB is still
present with the ISP and H264 bits, and V3D is in the same place in the
new ASB as the old one."
- Patch #10 I …
[View More]took as is from the downstream implementation, I can't really
provide an exact explanation on what changed HW wise.
Ultimately, I need confirmation from the Broadcom folks that they are alright
with patch #12 (deleting pm ops in V3D).
With all this, I get a more or less stable experience using mesa 20.3.4 and
X11/Gnome.
Regards,
Nicolas
---
Changes since v1:
- Use 'reg-names'
- Correct ASB names
- Add missing binding patch for V3D
- Address Stefan's comments
Nicolas Saenz Julienne (16):
dt-bindings: soc: bcm: bcm2835-pm: Convert bindings to DT schema
dt-bindings: soc: bcm: bcm2835-pm: Introduce reg-names
dt-bindings: soc: bcm: bcm2835-pm: Add support for bcm2711
ARM: dts: bcm2835/bcm2711: Introduce reg-names in watchdog node
ARM: dts: bcm2711: Use proper compatible in PM/Watchdog node
mfd: bcm2835-pm: Rename asb to rpivid_asb
mfd: bcm2835-pm: Use 'reg-names' to get resources
mfd: bcm2835-pm: Add support for BCM2711
soc: bcm: bcm2835-power: Add support for BCM2711's Argon ASB
soc: bcm: bcm2835-power: Bypass power_on/off() calls
dt-bindings: gpu: v3d: Add BCM2711's compatible
drm/v3d: Get rid of pm code
drm/v3d: Add support for bcm2711
ARM: dts: bcm2711: Enable V3D
ARM: configs: Enable DRM_V3D
arm64: config: Enable DRM_V3D
.../devicetree/bindings/gpu/brcm,bcm-v3d.yaml | 1 +
.../bindings/soc/bcm/brcm,bcm2835-pm.txt | 46 ----------
.../bindings/soc/bcm/brcm,bcm2835-pm.yaml | 88 +++++++++++++++++++
arch/arm/boot/dts/bcm2711.dtsi | 15 +++-
arch/arm/boot/dts/bcm2835-common.dtsi | 1 +
arch/arm/configs/multi_v7_defconfig | 1 +
arch/arm64/configs/defconfig | 1 +
drivers/gpu/drm/v3d/Kconfig | 2 +-
drivers/gpu/drm/v3d/v3d_debugfs.c | 18 +---
drivers/gpu/drm/v3d/v3d_drv.c | 12 +--
drivers/gpu/drm/v3d/v3d_gem.c | 9 --
drivers/mfd/bcm2835-pm.c | 83 ++++++++++++-----
drivers/soc/bcm/bcm2835-power.c | 82 +++++++++++------
include/linux/mfd/bcm2835-pm.h | 3 +-
14 files changed, 225 insertions(+), 137 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/soc/bcm/brcm,bcm2835-pm.txt
create mode 100644 Documentation/devicetree/bindings/soc/bcm/brcm,bcm2835-pm.yaml
--
2.30.0
[View Less]
Hi Dave, Daniel,
Just a single revert to fix a blank screen.
The following changes since commit 92bf22614b21a2706f4993b278017e437f7785b3:
Linux 5.11-rc7 (2021-02-07 13:57:38 -0800)
are available in the Git repository at:
https://gitlab.freedesktop.org/agd5f/linux.git tags/amd-drm-fixes-5.11-2021-02-10
for you to fetch changes up to cf050f96e0970a557601953ed7269d07a7885078:
Revert "drm/amd/display: Update NV1x SR latency values" (2021-02-09 23:23:18 -0500)
--------------------------…
[View More]--------------------------------------
amd-drm-fixes-5.11-2021-02-10:
amdgpu:
- Blank screen fix
----------------------------------------------------------------
Alex Deucher (1):
Revert "drm/amd/display: Update NV1x SR latency values"
drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
[View Less]
Hi,
these two patches fix non-working HDMI deep color output on DCE-8.3,
AMD Mullins when amdgpu-kms is used with Displaycore force-enabled,
ie. for radeon.cik_support=0 amdgpu.cik_support=1 amdgpu.dc=1:
I suspect they might fix similar problems on other older asics of
DCE-11.0 and earlier.
Patch 1/2 is a fix for some oddity i found while hunting for the
HDMI deep color bug. It fixes what looks like an obvious mistake,
but the fix did not improve or degrade anything, so maybe the hw
doesn't …
[View More]care all too much about the wrong clamping/truncation mask?
Anyway, it makes the code less confusing.
Patch 2/2 fixes HDMI deep color output at 10 bpc or 12 bpc output
on AMD Mullins, DCE-8.3, where at output_bpc 10 or 12 the display
would be scrambled. With the patch, the display looks correct, and
photometer measurements on a HDR-10 monitor suggest we probably get
the correct output signal. I found the fix by comparing DC against
the classic amdgpu-kms and radeon-kms modesetting path, readding
missing stuff.
Given other encoder/pixelclock setup functions than the ones used
on DCE-8.3 showed the same omissions, i added missing code there as
well, but i couldn't test it due to lack of hw, so i hope that fixes
instead of breaks things on asic's other than DCE-8.3.
I also created a similar patch for DCE-11.2 and later, not included
here, but during testing on a Raven Ridge DCN-1, the patch neither
helped nor hurt. Output was correct without the patch, and adding the
patch didn't change or break anything on DCN-1. Looking at disassembled
AtomBios tables for DCN-1 and a DCE-11.2, i think AtomBios may not do
much with the info that was missing, which would explain why the
current upstream code seems to work fine without it? At least as
verified on DCN-1. I can't test on DCE-11.2 or DCE-12 due to lack
of hw with actual HDMI output. But it would be interesting for me to
know what changed wrt. Atombios in later asic versions to make some
of this setup apparently redundant in DC?
Do you test DC wrt. HDMI deep color starting at a specific DCE
revision, given that the bug went unnoticed in DCE-8.3, but things
seem to be fine on at least DCN-1?
Thanks,
-mario
[View Less]