dri-devel July 2020

dri-devel@lists.freedesktop.org

336 participants
772 discussions

DSI probe/bind ordering in vc4
by Maxime Ripard 03 Jul '20

03 Jul '20

Hi, I've tried to bring-up the DSI controller on the RaspberryPi4, and I've just encountered something that could make it troublesome to support. For context, the RaspberryPi has an official panel that uses a DSI->DPI bridge, a DPI panel, a touchscreen and a small micro-controller. That microcontroller controls the power management on the screen, so communicating with it is very much needed, and it's done through an i2c bus. To reflect that, the entire panel has been described in the Device Tree as an I2C device (since that's how you would control it), together with an OF-Graph endpoint linking that i2c device to the DSI controller[1]. That deviates a bit from the generic DSI binding though[2], since it requires that the panel should be a subnode of the DSI controller (which also makes sense since DCS commands is usually how you would control that device). This is where the trouble begins. Since the two devices are on entirely different buses, there's basically no guarantee on the probe order. The driver has tried to address this by using the OF-Graph and the component framework. Indeed, the DSI driver (component-based) will register a MIPI-DSI host in its probe, and call component_add[3]. If component_add fails, it will remove the DSI host and return the error code. It makes sense. The panel on the other hand will probe, and look for a DSI host through the OF-Graph [4]. If it isn't there, it will return EPROBE_DEFER, hoping that it will be available at some point. It also makes complete sense. Where the issue lies is that component_add has two very different behaviours here that will create the bug that we see on the RPi4: - If there's still components to probe, component_add will simply return 0 [5][6] - And if we're the last component to probe, component_add will then run all the bind callbacks and return the result on error of the master bind callback[7]. That master bind will usually have component_bind_all that will return the result of the bind callback of each component. Now, on the RPi4, the last component to probe is the DSI controller since it relies on a power-domain exposed by the firmware driver, so the driver core will defer its probe function until the power-domain is there [8]. We're thus pretty much guaranteed to fall in the second case above and run through all the bind callbacks. The DSI bind callback however will try to find and attach its panel, and return EPROBE_DEFER if it doesn't find it[9]. That error will then be propagated to the return code of component_bind_all, then to the master bind callback, and finally will be the return code of component_add. And since component_add is failing, we remove the DSI host. Since the DSI host isn't there, on the next occasion the i2c panel driver will not probe either, and we enter a loop that cannot really be broken, since one depends on the other. This was working on the RPi3 because the DSI is not the last driver to probe: indeed the v3d is depending on the same power domain[10][11] and is further down the list of components to add in the driver [12], so we're always in the first component_add case for DSI above, the DSI host sticks around, and the i2c driver can probe. I'm not entirely sure how we can fix that though. I guess the real flaw here is the assumption that component_add will not fail if one of the bind fails, which isn't true, but we can't really ignore those errors either since it might be something else than DSI that returns that error. One way to work around it is to make the mailbox, firmware and power domain drivers probe earlier by tweaking the initcalls at which they register, but it's not really fixing anything and compiling them as module would make it broken again. Maxime 1: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Doc… 2: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Doc… 3: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/dri… 4: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/dri… 5: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/dri… 6: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/dri… 7: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/dri… 8: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/dri… 9: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/dri… 10: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arc… 11: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arc… 12: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/dri…

2 2

[PATCH 1/2] drm/msm: Garbage collect unused resource _len fields.
by Eric Anholt 03 Jul '20

03 Jul '20

Nothing was using the lengths of these ioremaps. Signed-off-by: Eric Anholt <eric(a)anholt.net> --- drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 21 --------------------- drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 1 - drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c | 9 --------- 3 files changed, 31 deletions(-) diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c index 680527e28d09..a4ab802fee6d 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c @@ -45,20 +45,6 @@ static int dpu_kms_hw_init(struct msm_kms *kms); static void _dpu_kms_mmu_destroy(struct dpu_kms *dpu_kms); -static unsigned long dpu_iomap_size(struct platform_device *pdev, - const char *name) -{ - struct resource *res; - - res = platform_get_resource_byname(pdev, IORESOURCE_MEM, name); - if (!res) { - DRM_ERROR("failed to get memory resource: %s\n", name); - return 0; - } - - return resource_size(res); -} - #ifdef CONFIG_DEBUG_FS static int _dpu_danger_signal_status(struct seq_file *s, bool danger_status) @@ -844,7 +830,6 @@ static int dpu_kms_hw_init(struct msm_kms *kms) goto error; } DRM_DEBUG("mapped dpu address space @%pK\n", dpu_kms->mmio); - dpu_kms->mmio_len = dpu_iomap_size(dpu_kms->pdev, "mdp"); dpu_kms->vbif[VBIF_RT] = msm_ioremap(dpu_kms->pdev, "vbif", "vbif"); if (IS_ERR(dpu_kms->vbif[VBIF_RT])) { @@ -853,22 +838,16 @@ static int dpu_kms_hw_init(struct msm_kms *kms) dpu_kms->vbif[VBIF_RT] = NULL; goto error; } - dpu_kms->vbif_len[VBIF_RT] = dpu_iomap_size(dpu_kms->pdev, "vbif"); dpu_kms->vbif[VBIF_NRT] = msm_ioremap(dpu_kms->pdev, "vbif_nrt", "vbif_nrt"); if (IS_ERR(dpu_kms->vbif[VBIF_NRT])) { dpu_kms->vbif[VBIF_NRT] = NULL; DPU_DEBUG("VBIF NRT is not defined"); - } else { - dpu_kms->vbif_len[VBIF_NRT] = dpu_iomap_size(dpu_kms->pdev, - "vbif_nrt"); } dpu_kms->reg_dma = msm_ioremap(dpu_kms->pdev, "regdma", "regdma"); if (IS_ERR(dpu_kms->reg_dma)) { dpu_kms->reg_dma = NULL; DPU_DEBUG("REG_DMA is not defined"); - } else { - dpu_kms->reg_dma_len = dpu_iomap_size(dpu_kms->pdev, "regdma"); } pm_runtime_get_sync(&dpu_kms->pdev->dev); diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h index 4e32d040f1e6..13034cdb8665 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h @@ -100,7 +100,6 @@ struct dpu_kms { /* io/register spaces: */ void __iomem *mmio, *vbif[VBIF_MAX], *reg_dma; - unsigned long mmio_len, vbif_len[VBIF_MAX], reg_dma_len; struct regulator *vdd; struct regulator *mmagic; diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c index 80d3cfc14007..9f20b84d5c0a 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c @@ -37,7 +37,6 @@ struct dpu_mdss_hw_init_handler { struct dpu_mdss { struct msm_mdss base; void __iomem *mmio; - unsigned long mmio_len; struct dss_module_power mp; struct dpu_irq_controller irq_controller; struct icc_path *path[2]; @@ -292,7 +291,6 @@ int dpu_mdss_init(struct drm_device *dev) { struct platform_device *pdev = to_platform_device(dev->dev); struct msm_drm_private *priv = dev->dev_private; - struct resource *res; struct dpu_mdss *dpu_mdss; struct dss_module_power *mp; int ret = 0; @@ -308,13 +306,6 @@ int dpu_mdss_init(struct drm_device *dev) DRM_DEBUG("mapped mdss address space @%pK\n", dpu_mdss->mmio); - res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "mdss"); - if (!res) { - DRM_ERROR("failed to get memory resource for mdss\n"); - return -ENOMEM; - } - dpu_mdss->mmio_len = resource_size(res); - ret = dpu_mdss_parse_data_bus_icc_path(dev, dpu_mdss); if (ret) return ret; -- 2.26.2

3 3

[PATCH v6 1/2] dt-binding: Add DSI/LVDS TC358775 bridge bindings
by Vinay Simha BN 03 Jul '20

03 Jul '20

Signed-off-by: Vinay Simha BN <simhavcs(a)gmail.com> --- v1: Initial version wast .txt file v2: From txt to yaml file format v3: * Andrzej Hajda review comments incorporated dual port lvds implemented * Laurent Pinchart review comments incorporated dsi lanes property removed and it is dynamically picked from the dsi ports VESA/JEIDA format picked from panel-lvds dts v4: * Sam Ravnborg review comments incorporated }' is indented properly in examples data-lanes description for single-link and dual-link lvds --- .../display/bridge/toshiba,tc358775.yaml | 215 ++++++++++++++++++ 1 file changed, 215 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/bridge/toshiba,tc358775.yaml diff --git a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358775.yaml b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358775.yaml new file mode 100644 index 000000000000..9ddd63bee403 --- /dev/null +++ b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358775.yaml @@ -0,0 +1,215 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/bridge/toshiba,tc358775.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Toshiba TC358775 DSI to LVDS bridge bindings + +maintainers: + - Vinay Simha BN <simhavcs(a)gmail.com> + +description: | + This binding supports DSI to LVDS bridge TC358775 + + MIPI DSI-RX Data 4-lane, CLK 1-lane with data rates up to 800 Mbps/lane. + Video frame size: + Up to 1600x1200 24-bit/pixel resolution for single-link LVDS display panel + limited by 135 MHz LVDS speed + Up to WUXGA (1920x1200 24-bit pixels) resolution for dual-link LVDS display + panel, limited by 270 MHz LVDS speed. + +properties: + compatible: + const: toshiba,tc358775 + + reg: + maxItems: 1 + description: i2c address of the bridge, 0x0f + + vdd-supply: + maxItems: 1 + description: 1.2V LVDS Power Supply + + vddio-supply: + maxItems: 1 + description: 1.8V IO Power Supply + + stby-gpios: + maxItems: 1 + description: Standby pin, Low active + + reset-gpios: + maxItems: 1 + description: Hardware reset, Low active + + ports: + type: object + description: + A node containing input and output port nodes with endpoint definitions + as documented in + Documentation/devicetree/bindings/media/video-interfaces.txt + properties: + "#address-cells": + const: 1 + + "#size-cells": + const: 0 + + port@0: + type: object + description: | + DSI Input. The remote endpoint phandle should be a + reference to a valid mipi_dsi_host device node. + + port@1: + type: object + description: | + Video port for LVDS output (panel or connector). + + port@2: + type: object + description: | + Video port for Dual link LVDS output (panel or connector). + + required: + - port@0 + - port@1 + +required: + - compatible + - reg + - vdd-supply + - vddio-supply + - stby-gpios + - reset-gpios + - ports + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + /* For single-link LVDS display panel */ + + i2c@78b8000 { + /* On High speed expansion */ + label = "HS-I2C2"; + reg = <0x078b8000 0x500>; + clock-frequency = <400000>; /* fastmode operation */ + #address-cells = <1>; + #size-cells = <0>; + + tc_bridge: bridge@f { + compatible = "toshiba,tc358775"; + reg = <0x0f>; + + vdd-supply = <&pm8916_l2>; + vddio-supply = <&pm8916_l6>; + + stby-gpios = <&msmgpio 99 GPIO_ACTIVE_LOW>; + reset-gpios = <&msmgpio 72 GPIO_ACTIVE_LOW>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + d2l_in_test: endpoint { + remote-endpoint = <&dsi0_out>; + }; + }; + + port@1 { + reg = <1>; + lvds_out: endpoint { + remote-endpoint = <&panel_in>; + }; + }; + }; + }; + }; + + dsi@1a98000 { + reg = <0x1a98000 0x25c>; + reg-names = "dsi_ctrl"; + + ports { + #address-cells = <1>; + #size-cells = <0>; + port@1 { + reg = <1>; + dsi0_out: endpoint { + remote-endpoint = <&d2l_in_test>; + data-lanes = <0 1 2 3>; + }; + }; + }; + }; + + - | + /* For dual-link LVDS display panel */ + + i2c@78b8000 { + /* On High speed expansion */ + label = "HS-I2C2"; + reg = <0x078b8000 0x500>; + clock-frequency = <400000>; /* fastmode operation */ + #address-cells = <1>; + #size-cells = <0>; + + tc_bridge_dual: bridge@f { + compatible = "toshiba,tc358775"; + reg = <0x0f>; + + vdd-supply = <&pm8916_l2>; + vddio-supply = <&pm8916_l6>; + + stby-gpios = <&msmgpio 99 GPIO_ACTIVE_LOW>; + reset-gpios = <&msmgpio 72 GPIO_ACTIVE_LOW>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + d2l_in_dual: endpoint { + remote-endpoint = <&dsi0_out_dual>; + }; + }; + + port@1 { + reg = <1>; + lvds0_out: endpoint { + remote-endpoint = <&panel_in0>; + }; + }; + + port@2 { + reg = <2>; + lvds1_out: endpoint { + remote-endpoint = <&panel_in1>; + }; + }; + }; + }; + }; + + dsi@1a98000 { + reg = <0x1a98000 0x25c>; + reg-names = "dsi_ctrl"; + + ports { + #address-cells = <1>; + #size-cells = <0>; + port@1 { + reg = <1>; + dsi0_out_dual: endpoint { + remote-endpoint = <&d2l_in_dual>; + data-lanes = <0 1 2 3>; + }; + }; + }; + }; +... -- 2.17.1

4 7

dummy-backlight
by Frédéric Pierret 03 Jul '20

03 Jul '20

Dear all, I'm working on a simple kernel module currently called "dummy-backlight" (https://github.com/fepitre/dummy-backlight) which creates a testing backlight. After loaded, this driver allows to modify integer values of the virtual backlight created through its sysfs attributes directly. In the context of the Qubes OS project, it allows to setup into a VM, a virtual backlight and managing the hardware backlight into the VM directly thanks to a communication channel with the host system. I'm writing to you to know if you would be interested to have such module into kernel. Another name could be "virtual-backlight". I've written a similar module for PSU too (https://lore.kernel.org/linux-pm/a8223cce-636f-578b-7304-eb0e4868e018@qubes…) where a nice suggestion of improvement has been made to use a misc device for controlling attributes instead of sysfs directly. Indeed, it's appropriated in case of multiple PSU but maybe for a (only one?) "dummy-backligh", using two sysfs attributes is enough. Any kind of improvements are very welcomed. Thank you. Best regards, Frédéric Pierret

1 0

[PATCH] drm: connector: Indent code using tabs.
by Suraj Upadhyay 03 Jul '20

03 Jul '20

Replace space-indents with tab-indents. Issues found with checkpatch. Signed-off-by: Suraj Upadhyay <usuraj35(a)gmail.com> --- drivers/gpu/drm/drm_connector.c | 38 ++++++++++++++++----------------- 1 file changed, 19 insertions(+), 19 deletions(-) diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c index 00e40a26a800..441d4075dfa5 100644 --- a/drivers/gpu/drm/drm_connector.c +++ b/drivers/gpu/drm/drm_connector.c @@ -1906,11 +1906,11 @@ int drm_connector_set_path_property(struct drm_connector *connector, int ret; ret = drm_property_replace_global_blob(dev, - &connector->path_blob_ptr, - strlen(path) + 1, - path, - &connector->base, - dev->mode_config.path_property); + &connector->path_blob_ptr, + strlen(path) + 1, + path, + &connector->base, + dev->mode_config.path_property); return ret; } EXPORT_SYMBOL(drm_connector_set_path_property); @@ -1936,11 +1936,11 @@ int drm_connector_set_tile_property(struct drm_connector *connector) if (!connector->has_tile) { ret = drm_property_replace_global_blob(dev, - &connector->tile_blob_ptr, - 0, - NULL, - &connector->base, - dev->mode_config.tile_property); + &connector->tile_blob_ptr, + 0, + NULL, + &connector->base, + dev->mode_config.tile_property); return ret; } @@ -1951,11 +1951,11 @@ int drm_connector_set_tile_property(struct drm_connector *connector) connector->tile_h_size, connector->tile_v_size); ret = drm_property_replace_global_blob(dev, - &connector->tile_blob_ptr, - strlen(tile) + 1, - tile, - &connector->base, - dev->mode_config.tile_property); + &connector->tile_blob_ptr, + strlen(tile) + 1, + tile, + &connector->base, + dev->mode_config.tile_property); return ret; } EXPORT_SYMBOL(drm_connector_set_tile_property); @@ -2024,10 +2024,10 @@ int drm_connector_update_edid_property(struct drm_connector *connector, ret = drm_property_replace_global_blob(dev, &connector->edid_blob_ptr, - size, - edid, - &connector->base, - dev->mode_config.edid_property); + size, + edid, + &connector->base, + dev->mode_config.edid_property); if (ret) return ret; return drm_connector_set_tile_property(connector); -- 2.17.1

1 0

[PATCH v2 00/91] drm/vc4: Support BCM2711 Display Pipeline
by Maxime Ripard 03 Jul '20

03 Jul '20

Hi everyone, Here's a (pretty long) series to introduce support in the VC4 DRM driver for the display pipeline found in the BCM2711 (and thus the RaspberryPi 4). The main differences are that there's two HDMI controllers and that there's more pixelvalve now. Those pixelvalve come with a mux in the HVS that still have only 3 FIFOs. Both of those differences are breaking a bunch of expectations in the driver, so we first need a good bunch of cleanup and reworks to introduce support for the new controllers. Similarly, the HDMI controller has all its registers shuffled and split in multiple controllers now, so we need a bunch of changes to support this as well. Only the HDMI support is enabled for now (even though the DPI output has been tested too). There's a couple of rough edges still that should be addressed in the next versions: - After a modeset, it's likely that the pixels will be shifted by one. - Dual output doesn't work - The transposer (and thus writeback) doesn't work either and conflicts with the output mux too. Let me know if you have any comments Maxime Cc: bcm-kernel-feedback-list(a)broadcom.com Cc: devicetree(a)vger.kernel.org Cc: Kamal Dasu <kdasu.kdev(a)gmail.com> Cc: linux-clk(a)vger.kernel.org Cc: linux-i2c(a)vger.kernel.org Cc: Michael Turquette <mturquette(a)baylibre.com> Cc: Philipp Zabel <p.zabel(a)pengutronix.de> Cc: Rob Herring <robh+dt(a)kernel.org> Cc: Stephen Boyd <sboyd(a)kernel.org> Cc: Wolfram Sang <wsa(a)the-dreams.de> Changes from v1: - Rebased on top of 5.7-rc1 - Run checkpatch - Added audio support - Fixed some HDMI timeouts - Swiched to clk_hw_register_gate_parent_data - Reorder Kconfig symbols in drivers/i2c/busses - Make the firmware clocks a child of the firmware node - Switch DVP clock driver to clk_hw interface - constify raspberrypi_clk_data in raspberrypi_clock_property - Don't mark firmware clocks as IGNORE_UNUSED - Change from reset_ms to reset_us in reset-simple, and add a bit more comments - Remove generic clk patch to test if a NULL pointer is returned - Removed misleading message in the is_prepared renaming patch commit message - Constify HDMI controller variants - Fix a bug in the allocation size of the clk data array - Added a mention in the DT binding conversion patches about the breakage - Merged a few fixes from kbuild - Fixed a few bisection and CEC build issues - Collected Acked-by and Reviewed-by - Change Dave email address to raspberrypi.com Dave Stevenson (6): drm/vc4: Add support for the BCM2711 HVS5 drm/vc4: plane: Improve LBM usage drm/vc4: hdmi: Use reg-names to retrieve the HDMI audio registers drm/vc4: hdmi: Reset audio infoframe on encoder_enable if previously streaming drm/vc4: hdmi: Set the b-frame marker to the match ALSA's default. drm/vc4: hdmi: Add audio-related callbacks Florian Fainelli (1): dt-bindings: arm: bcm: Convert BCM2835 firmware binding to YAML Maxime Ripard (84): i2c: brcmstb: Allow to compile it on BCM2835 dt-bindings: clock: Add a binding for the RPi Firmware clocks firmware: rpi: Only create clocks device if we don't have a node for it clk: bcm: rpi: Allow the driver to be probed by DT clk: bcm: rpi: Statically init clk_init_data clk: bcm: rpi: Use clk_hw_register for pllb_arm clk: bcm: rpi: Remove global pllb_arm clock pointer clk: bcm: rpi: Make sure pllb_arm is removed clk: bcm: rpi: Remove pllb_arm_lookup global pointer clk: bcm: rpi: Switch to clk_hw_register_clkdev clk: bcm: rpi: Make sure the clkdev lookup is removed clk: bcm: rpi: Create a data structure for the clocks clk: bcm: rpi: Add clock id to data clk: bcm: rpi: Pass the clocks data to the firmware function clk: bcm: rpi: Rename is_prepared function clk: bcm: rpi: Split pllb clock hooks clk: bcm: rpi: Make the PLLB registration function return a clk_hw clk: bcm: rpi: Add DT provider for the clocks clk: bcm: rpi: Discover the firmware clocks ARM: dts: bcm2711: Add firmware clocks node reset: Move reset-simple header out of drivers/reset reset: simple: Add reset callback dt-bindings: clock: Add BCM2711 DVP binding clk: bcm: Add BCM2711 DVP driver ARM: dts: bcm2711: Add HDMI DVP dt-bindings: display: Convert VC4 bindings to schemas dt-bindings: display: vc4: dpi: Add missing clock-names property dt-bindings: display: vc4: dsi: Add missing clock properties dt-bindings: display: vc4: hdmi: Add missing clock-names property dt-bindings: display: vc4: Document BCM2711 VC5 drm/vc4: drv: Add include guards drm/vc4: drv: Support BCM2711 dt-bindings: display: Add support for the BCM2711 HVS drm/vc4: hvs: Boost the core clock during modeset drm/vc4: plane: Move planes creation to its own function drm/vc4: plane: Move additional planes creation to driver drm/vc4: plane: Register all the planes at once drm/vc4: plane: Create overlays for any CRTC drm/vc4: plane: Create more planes drm/vc4: crtc: Rename SoC data structures drm/vc4: crtc: Move crtc state to common header drm/vc4: crtc: Deal with different number of pixel per clock drm/vc4: crtc: Use a shared interrupt drm/vc4: crtc: Turn static const variable into a define drm/vc4: crtc: Move the cob allocation outside of bind drm/vc4: crtc: Rename HVS channel to output drm/vc4: crtc: Use local chan variable drm/vc4: crtc: Enable and disable the PV in atomic_enable / disable drm/vc4: crtc: Assign output to channel automatically drm/vc4: crtc: Add FIFO depth to vc4_crtc_data drm/vc4: crtc: Add function to compute FIFO level bits drm/vc4: crtc: Rename HDMI encoder type to HDMI0 drm/vc4: crtc: Add HDMI1 encoder type drm/vc4: crtc: Remove redundant call to drm_crtc_enable_color_mgmt drm/vc4: crtc: Disable color management for HVS5 dt-bindings: display: vc4: pv: Add BCM2711 pixel valves drm/vc4: crtc: Add BCM2711 pixelvalves drm/vc4: hdmi: Use debugfs private field drm/vc4: hdmi: Move structure to header drm/vc4: hdmi: rework connectors and encoders drm/vc4: hdmi: Remove DDC argument to connector_init drm/vc4: hdmi: Rename hdmi to vc4_hdmi drm/vc4: hdmi: Move accessors to vc4_hdmi drm/vc4: hdmi: Use local vc4_hdmi directly drm/vc4: hdmi: Add container_of macros for encoders and connectors drm/vc4: hdmi: Pass vc4_hdmi to CEC code drm/vc4: hdmi: Remove vc4_dev hdmi pointer drm/vc4: hdmi: Remove vc4_hdmi_connector drm/vc4: hdmi: Introduce resource init and variant drm/vc4: hdmi: Implement a register layout abstraction drm/vc4: hdmi: Add reset callback drm/vc4: hdmi: Add PHY init and disable function drm/vc4: hdmi: Add PHY RNG enable / disable function drm/vc4: hdmi: Add a CSC setup callback drm/vc4: hdmi: Store the encoder type in the variant structure drm/vc4: hdmi: Deal with multiple debugfs files drm/vc4: hdmi: Move CEC init to its own function drm/vc4: hdmi: Add CEC support flag drm/vc4: hdmi: Remove unused CEC_CLOCK_DIV define drm/vc4: hdmi: Rename drm_encoder pointer in mode_valid drm/vc4: hdmi: Adjust HSM clock rate depending on pixel rate drm/vc4: hdmi: Support the BCM2711 HDMI controllers dt-bindings: display: vc4: hdmi: Add BCM2711 HDMI controllers bindings ARM: dts: bcm2711: Enable the display pipeline Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.txt | 14 +- Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml | 59 +++- Documentation/devicetree/bindings/clock/brcm,bcm2711-dvp.yaml | 47 ++- Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt | 174 +-------- Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml | 109 +++++- Documentation/devicetree/bindings/display/brcm,bcm2835-dpi.yaml | 72 +++- Documentation/devicetree/bindings/display/brcm,bcm2835-dsi0.yaml | 84 ++++- Documentation/devicetree/bindings/display/brcm,bcm2835-hdmi.yaml | 80 ++++- Documentation/devicetree/bindings/display/brcm,bcm2835-hvs.yaml | 53 ++- Documentation/devicetree/bindings/display/brcm,bcm2835-pixelvalve0.yaml | 45 ++- Documentation/devicetree/bindings/display/brcm,bcm2835-txp.yaml | 37 ++- Documentation/devicetree/bindings/display/brcm,bcm2835-v3d.yaml | 42 ++- Documentation/devicetree/bindings/display/brcm,bcm2835-vc4.yaml | 35 ++- Documentation/devicetree/bindings/display/brcm,bcm2835-vec.yaml | 44 ++- MAINTAINERS | 2 +- arch/arm/boot/dts/bcm2711-rpi-4-b.dts | 51 ++- arch/arm/boot/dts/bcm2711.dtsi | 130 +++++- drivers/clk/bcm/Kconfig | 1 +- drivers/clk/bcm/Makefile | 1 +- drivers/clk/bcm/clk-bcm2711-dvp.c | 127 ++++++- drivers/clk/bcm/clk-raspberrypi.c | 280 +++++++++---- drivers/firmware/raspberrypi.c | 17 +- drivers/gpu/drm/vc4/Makefile | 1 +- drivers/gpu/drm/vc4/vc4_crtc.c | 328 +++++++++------ drivers/gpu/drm/vc4/vc4_drv.c | 5 +- drivers/gpu/drm/vc4/vc4_drv.h | 58 ++- drivers/gpu/drm/vc4/vc4_hdmi.c | 1536 ++++++++++++++++++++++++++++++++++++++++++------------------------------ drivers/gpu/drm/vc4/vc4_hdmi.h | 179 ++++++++- drivers/gpu/drm/vc4/vc4_hdmi_phy.c | 508 ++++++++++++++++++++++++- drivers/gpu/drm/vc4/vc4_hdmi_regs.h | 451 +++++++++++++++++++++- drivers/gpu/drm/vc4/vc4_hvs.c | 25 +- drivers/gpu/drm/vc4/vc4_kms.c | 181 +++++++- drivers/gpu/drm/vc4/vc4_plane.c | 271 +++++++++---- drivers/gpu/drm/vc4/vc4_regs.h | 173 +++----- drivers/i2c/busses/Kconfig | 4 +- drivers/reset/reset-simple.c | 27 +- drivers/reset/reset-simple.h | 41 +-- drivers/reset/reset-socfpga.c | 3 +- drivers/reset/reset-sunxi.c | 3 +- drivers/reset/reset-uniphier-glue.c | 3 +- include/linux/reset/reset-simple.h | 47 ++- include/soc/bcm2835/raspberrypi-firmware.h | 5 +- 42 files changed, 4109 insertions(+), 1244 deletions(-) delete mode 100644 Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.txt create mode 100644 Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml create mode 100644 Documentation/devicetree/bindings/clock/brcm,bcm2711-dvp.yaml delete mode 100644 Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt create mode 100644 Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml create mode 100644 Documentation/devicetree/bindings/display/brcm,bcm2835-dpi.yaml create mode 100644 Documentation/devicetree/bindings/display/brcm,bcm2835-dsi0.yaml create mode 100644 Documentation/devicetree/bindings/display/brcm,bcm2835-hdmi.yaml create mode 100644 Documentation/devicetree/bindings/display/brcm,bcm2835-hvs.yaml create mode 100644 Documentation/devicetree/bindings/display/brcm,bcm2835-pixelvalve0.yaml create mode 100644 Documentation/devicetree/bindings/display/brcm,bcm2835-txp.yaml create mode 100644 Documentation/devicetree/bindings/display/brcm,bcm2835-v3d.yaml create mode 100644 Documentation/devicetree/bindings/display/brcm,bcm2835-vc4.yaml create mode 100644 Documentation/devicetree/bindings/display/brcm,bcm2835-vec.yaml create mode 100644 drivers/clk/bcm/clk-bcm2711-dvp.c create mode 100644 drivers/gpu/drm/vc4/vc4_hdmi.h create mode 100644 drivers/gpu/drm/vc4/vc4_hdmi_phy.c create mode 100644 drivers/gpu/drm/vc4/vc4_hdmi_regs.h delete mode 100644 drivers/reset/reset-simple.h create mode 100644 include/linux/reset/reset-simple.h base-commit: cb3692197b5da2fb898335eec1640db14d92e52e -- git-series 0.9.1

11 141

[PATCH v7 00/13] Add support for PinePhone LCD panel
by Ondrej Jirman 03 Jul '20

03 Jul '20

This patchset adds support for the LCD panel of PinePhone. I've tested this on PinePhone 1.0 and 1.2. Please take a look. thank you and regards, Ondrej Jirman Changes in v7: - Removed mode.vrefresh, rebased onto next-20200701 - v6->v7 diff: https://megous.com/dl/tmp/v6-v7.patch Changes in v6: - Fixed spacing in yaml - Fixed wrong vccio->iovcc supply name in the bindings doc - I noticed that the original driver uses a delay of 20ms in the init function to achieve a combined total of 120ms required from post-reset to display_on. I've added a similar delay to xbd599_init, so that xbd599 panel also has the right timing. (patch 9) - v5->v6 diff: https://megous.com/dl/tmp/v5-v6.patch - Added review/ack tags - Learned to run dt_binding_check by myself ;) Changes in v5: - rewritten on top of rocktech-jh057n00900 driver - rocktech-jh057n00900 renamed to st7703 (controller name) - converted rocktech-jh057n00900 bindings to yaml and extended for xbd599 Changes in v4: - use ->type from the mode instead of hardcoding (Samuel) - move init_sequence to ->prepare (Samuel) - move anti-flicker delay to ->enable, explain it (Samuel) - add enter_sleep after display_off (Samuel) - drop ->disable (move code to ->unprepare) - add ID bytes dumping (Linus) (I can't test it since allwinner DSI driver has a broken dcs_read function, and I didn't manage to fix it.) - document magic bytes (Linus) - assert reset during powerup - cleanup powerup timings according to the datasheet Changes in v3: - Panel driver renamed to the name of the LCD controller - Re-organize the driver slightly to more easily support more panels based on the same controller. - Add patch to enable the touchscreen to complete the LCD support on PinePhone. - Dropped the "DSI fix" patch (the driver seems to work for me without it) - Improved brightness levels handling: - PinePhone 1.0 uses default levels generated by the driver - On PinePhone 1.1 duty cycles < 20% lead to black screen, so default levels can't be used. Martijn Braam came up with a list of duty cycle values that lead to perception of linear brigtness level <-> light intensity on PinePhone 1.1 - There was some feedback on v2 about this being similar to st7701. It's only similar in name. Most of the "user commands" are different, so I opted to keep this in a new driver instead of creating st770x. Anyone who likes to check the differences, here are datasheets: - https://megous.com/dl/tmp/ST7703_DS_v01_20160128.pdf - https://megous.com/dl/tmp/ST7701.pdf Changes in v2: - DT Example fix. - DT Format fix. - Raised copyright info to 2020. - Sort panel operation functions. - Sort inclusion. -- For phone owners: -- There's an open question on how to set the backlight brightness values on post 1.0 revision phone, since lower duty cycles (< 10-20%) lead to backlight being black. It would be nice if more people can test the various backlight levels on 1.1 and 1.2 revision with this change in dts: brightness-levels = <0 1000>; num-interpolated-steps = <1000>; and report at what brightness level the backlight turns on. So far it seems this has a wide range. Lowest useable duty cycle for me is ~7% on 1.2 and for Martijn ~20% on 1.1. Icenowy Zheng (2): dt-bindings: vendor-prefixes: Add Xingbangda arm64: dts: sun50i-a64-pinephone: Enable LCD support on PinePhone Ondrej Jirman (11): dt-bindings: panel: Convert rocktech,jh057n00900 to yaml dt-bindings: panel: Add compatible for Xingbangda XBD599 panel drm/panel: rocktech-jh057n00900: Rename the driver to st7703 drm/panel: st7703: Rename functions from jh057n prefix to st7703 drm/panel: st7703: Prepare for supporting multiple panels drm/panel: st7703: Move code specific to jh057n closer together drm/panel: st7703: Move generic part of init sequence to enable callback drm/panel: st7703: Add support for Xingbangda XBD599 drm/panel: st7703: Enter sleep after display off drm/panel: st7703: Assert reset prior to powering down the regulators arm64: dts: sun50i-a64-pinephone: Add touchscreen support .../display/panel/rocktech,jh057n00900.txt | 23 - .../display/panel/rocktech,jh057n00900.yaml | 70 ++ .../devicetree/bindings/vendor-prefixes.yaml | 2 + .../allwinner/sun50i-a64-pinephone-1.1.dts | 19 + .../dts/allwinner/sun50i-a64-pinephone.dtsi | 54 ++ drivers/gpu/drm/panel/Kconfig | 26 +- drivers/gpu/drm/panel/Makefile | 2 +- .../drm/panel/panel-rocktech-jh057n00900.c | 423 ----------- drivers/gpu/drm/panel/panel-sitronix-st7703.c | 654 ++++++++++++++++++ 9 files changed, 813 insertions(+), 460 deletions(-) delete mode 100644 Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.txt create mode 100644 Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.yaml delete mode 100644 drivers/gpu/drm/panel/panel-rocktech-jh057n00900.c create mode 100644 drivers/gpu/drm/panel/panel-sitronix-st7703.c -- 2.27.0

5 21

[PATCH v2 00/14] drm/ast: Managed modesetting
by Thomas Zimmermann 03 Jul '20

03 Jul '20

This is the first patchset to convert ast to use managed interfaces. These patches address modesetting. I expect that there will be at least one more set of patches for memory management and one for device structures. Patches 1 to 11 tackle HW cursor handling. The overall point is to get cursor support out of the plane functions and put the code into helpers. There are quite a few improvements that make cursors easier and faster to use. Patch 10 converts cursors to managed release. With cursors out of the way, modesetting initialization is much more simple. Patches 12 to 14 put all related code next to each other and switch to managed initialization. The patchset was tested on AST2100 hardware. v2: * use to_ast_private() instead of struct drm_device.dev_private (Sam) Thomas Zimmermann (14): drm/ast: Move cursor functions to ast_cursor.c drm/ast: Pass struct ast_private instance to cursor init/fini functions drm/ast: Move cursor fb pinning and mapping into helper drm/ast: Update cursor image and checksum from same function drm/ast: Move cursor pageflip into helper drm/ast: Replace ast_cursor_move() with ast_cursor_show() drm/ast: Don't enable HW cursors twice during atomic update drm/ast: Add helper to hide cursor drm/ast: Keep cursor HW BOs mapped drm/ast: Managed cursor release drm/ast: Init cursors before creating modesetting structures drm/ast: Replace struct ast_crtc with struct drm_crtc drm/ast: Use managed mode-config init drm/ast: Initialize mode setting in ast_mode_config_init() drivers/gpu/drm/ast/Makefile | 3 +- drivers/gpu/drm/ast/ast_cursor.c | 289 +++++++++++++++++++++++++++ drivers/gpu/drm/ast/ast_drv.h | 19 +- drivers/gpu/drm/ast/ast_main.c | 35 +--- drivers/gpu/drm/ast/ast_mode.c | 322 ++++++------------------------- 5 files changed, 359 insertions(+), 309 deletions(-) create mode 100644 drivers/gpu/drm/ast/ast_cursor.c -- 2.27.0

2 19

[Bug 208179] New: [amdgpu] black screen after exiting X
by bugzilla-daemon＠bugzilla.kernel.org 03 Jul '20

03 Jul '20

https://bugzilla.kernel.org/show_bug.cgi?id=208179 Bug ID: 208179 Summary: [amdgpu] black screen after exiting X Product: Drivers Version: 2.5 Kernel Version: 5.7.2 Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri(a)kernel-bugs.osdl.org Reporter: shlomo(a)fastmail.com CC: daniel(a)ffwll.ch, dri-devel(a)lists.freedesktop.org Regression: Yes After exiting X on a virtual terminal that isn't tty1, the screen becomes all black instead of showing the text tty. Keyboard input still goes to the text tty, but I can't see what I'm typing. After this happens, a workaround is to switch to a different virtual terminal (with Ctrl+Alt+FN) that is in text mode (not running X) and then switch back. Then the text tty is visible and works normally. Switching to a different virtual terminal that is running X and then switching back doesn't help. The problematic virtual terminal is still all black. My graphics card is Gigabyte Radeon RX VEGA 56 GAMING OC 8G. (amdgpu) The bug appeared after upgrading Arch linux 5.6.15.arch1-1 to 5.7.2.arch1-1. The first bad commit is 64914da24ea95d2b2f7017d014d74c26005d8780 (drm/fbdev-helper: don't force restores). The previous commit e81a2557e0650ee0ce37ba14476ddb709d6daf57 is good. When testing these two commits, I needed to cherry-pick the following fixes: a9a3ed1eff3601b63aea4fb462d8b3b92c7c1e7e (x86: Fix early boot crash on gcc-10, third try) e33a814e772cdc36436c8c188d8c42d019fda639 (scripts/dtc: Remove redundant YYLOC global declaration) df6d4f9db79c1a5d6f48b59db35ccd1e9ff9adfc (x86/boot/compressed: Don't declare __force_order in kaslr_64.c) These are needed when compiling with GCC 10 to fix compilation errors and a hang on boot. -- You are receiving this mail because: You are on the CC list for the bug. You are watching the assignee of the bug.

1 5

[PATCH v4 00/37] Introduce memory interconnect for NVIDIA Tegra SoCs
by Dmitry Osipenko 03 Jul '20

03 Jul '20

Hello, This series brings initial support for memory interconnect to Tegra20 and Tegra30 SoCs. For the starter only display controllers are getting interconnect API support, others could be supported later on. The display controllers have the biggest demand for interconnect API right now because dynamic memory frequency scaling can't be done safely without taking into account bandwidth requirement from the displays. Changelog: v4: - All drivers that use interconnect API now select it in the Kconfig in order to properly express the build dependency. - The IS_ENABLED(CONFIG_INTERCONNECT) is dropped now from all patches. - Added MODULE_AUTHOR() to the modularized drivers, for completeness. - Added missed TEGRA_MC Kconfig dependency for the Tegra20 EMC driver. - Added more acks from Rob Herring that I accidentally missed to add in v3. v3: - Added acks from Rob Herring that were given to some of the v2 patches. - Specified name of the TRM documentation chapter in the patch "dt-bindings: host1x: Document new interconnect properties", which was suggested by Rob Herring in the review comment to v2. - Added patches that allow EMC drivers to be compiled as a loadable kernel modules. This came up during of the v2 review when Georgi Djakov pointed out that interconnect-core could be compiled as a kernel module. Please note that the Tegra124 EMC driver is compile-tested only, I don't have Tegra124 HW. - In the review comment to [1] Stephen Boyd suggested that it will be better not to make changes to clk API, which was needed in order to avoid clashing of the interconnect driver with the devfreq in regards to memory clk-rate rounding. [1] https://patchwork.ozlabs.org/project/linux-tegra/patch/20200330231617.17079… Stephen Boyd suggested that instead we should provide OPP table via DT. I tried to investigate whether this could be done and turned out it's a bit complicated. Technically it should be doable, but: 1. For now we don't fully support voltage scaling of the CORE regulator and so OPP table in the DT isn't really needed today. We can generate table from the memory timings, which is what Tegra devfreq drivers already do. 2. The OPP table should be defined in the DT for the Memory Controller node and then its usage somehow should be shared by both interconnect and devfreq drivers. It's not obvious what's the best way to do it. So, it will be much better to postpone the DT OPP table addition until these questions are resolved. We can infer OPPs from the memory timings and we could get the memory rates from the memory driver directly, avoiding the problems induced by the clk API usage. This idea is implemented in v3, see these patches: PM / devfreq: tegra20: Use MC timings for building OPP table PM / devfreq: tegra30: Use MC timings for building OPP table v2: - Instead of a single dma-mem interconnect path, the paths are now defined per memory client. - The EMC provider now uses #interconnect-cells=<0>. - Dropped Tegra124 because there is no enough information about how to properly calculate required EMC clock rate for it and I don't have hardware for testing. Somebody else will have to work on it. - Moved interconnect providers code into drivers/memory/tegra/*. - Added "Create tegra20-devfreq device" patch because interconnect is not very usable without the devfreq memory auto-scaling since memory freq will be fixed to the display's requirement. Artur Świgoń (1): interconnect: Relax requirement in of_icc_get_from_provider() Dmitry Osipenko (36): clk: Export clk_hw_reparent() clk: tegra: Remove Memory Controller lock clk: tegra: Export Tegra20 EMC kernel symbols memory: tegra20-emc: Make driver modular memory: tegra30-emc: Make driver modular memory: tegra124-emc: Make driver modular memory: tegra124-emc: Use devm_platform_ioremap_resource soc/tegra: fuse: Export tegra_read_ram_code() memory: tegra20-emc: Initialize MC timings PM / devfreq: tegra20: Silence deferred probe error PM / devfreq: tegra30: Silence deferred probe error PM / devfreq: tegra20: Use MC timings for building OPP table PM / devfreq: tegra30: Use MC timings for building OPP table PM / devfreq: tegra20: Add error messages to tegra_devfreq_target() PM / devfreq: tegra30: Add error messages to tegra_devfreq_target() PM / devfreq: tegra20: Adjust clocks conversion ratio and polling interval PM / devfreq: tegra20: Relax Kconfig dependency dt-bindings: memory: tegra20: mc: Document new interconnect property dt-bindings: memory: tegra20: emc: Document new interconnect property dt-bindings: memory: tegra30: mc: Document new interconnect property dt-bindings: memory: tegra30: emc: Document new interconnect property dt-bindings: host1x: Document new interconnect properties dt-bindings: memory: tegra20: Add memory client IDs dt-bindings: memory: tegra30: Add memory client IDs ARM: tegra: Add interconnect properties to Tegra20 device-tree ARM: tegra: Add interconnect properties to Tegra30 device-tree memory: tegra: Register as interconnect provider memory: tegra20-emc: Use devm_platform_ioremap_resource memory: tegra20-emc: Continue probing if timings are missing in device-tree memory: tegra20-emc: Register as interconnect provider memory: tegra20-emc: Create tegra20-devfreq device memory: tegra30-emc: Continue probing if timings are missing in device-tree memory: tegra30-emc: Register as interconnect provider drm/tegra: dc: Support memory bandwidth management drm/tegra: dc: Tune up high priority request controls for Tegra20 drm/tegra: dc: Extend debug stats with total number of events .../display/tegra/nvidia,tegra20-host1x.txt | 68 +++++ .../memory-controllers/nvidia,tegra20-emc.txt | 2 + .../memory-controllers/nvidia,tegra20-mc.txt | 3 + .../nvidia,tegra30-emc.yaml | 6 + .../memory-controllers/nvidia,tegra30-mc.yaml | 5 + arch/arm/boot/dts/tegra20.dtsi | 22 +- arch/arm/boot/dts/tegra30.dtsi | 23 +- drivers/clk/clk.c | 1 + drivers/clk/tegra/clk-divider.c | 4 +- drivers/clk/tegra/clk-tegra114.c | 6 +- drivers/clk/tegra/clk-tegra124-emc.c | 63 ++-- drivers/clk/tegra/clk-tegra124.c | 8 +- drivers/clk/tegra/clk-tegra20-emc.c | 3 + drivers/clk/tegra/clk-tegra20.c | 3 +- drivers/clk/tegra/clk-tegra30.c | 3 +- drivers/clk/tegra/clk.h | 14 +- drivers/devfreq/Kconfig | 2 +- drivers/devfreq/tegra20-devfreq.c | 52 ++-- drivers/devfreq/tegra30-devfreq.c | 115 +++++-- drivers/gpu/drm/tegra/Kconfig | 1 + drivers/gpu/drm/tegra/dc.c | 289 +++++++++++++++++- drivers/gpu/drm/tegra/dc.h | 13 + drivers/gpu/drm/tegra/drm.c | 19 ++ drivers/gpu/drm/tegra/plane.c | 1 + drivers/gpu/drm/tegra/plane.h | 4 +- drivers/interconnect/core.c | 11 +- drivers/memory/tegra/Kconfig | 9 +- drivers/memory/tegra/mc.c | 117 +++++++ drivers/memory/tegra/mc.h | 8 + drivers/memory/tegra/tegra124-emc.c | 36 ++- drivers/memory/tegra/tegra20-emc.c | 215 +++++++++++-- drivers/memory/tegra/tegra30-emc.c | 156 ++++++++-- drivers/soc/tegra/fuse/tegra-apbmisc.c | 2 + include/dt-bindings/memory/tegra20-mc.h | 53 ++++ include/dt-bindings/memory/tegra30-mc.h | 67 ++++ include/linux/clk/tegra.h | 11 + include/soc/tegra/emc.h | 16 - include/soc/tegra/mc.h | 3 + 38 files changed, 1235 insertions(+), 199 deletions(-) delete mode 100644 include/soc/tegra/emc.h -- 2.26.0

4 61

← Newer
1
...
67
68
69
70
71
72
73
...
78
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel July 2020