Re: [PATCH v2 13/20] drm/nouveau: Remove references to struct drm_device.pdev
ping for a review of the nouveau patch
Am 01.12.20 um 11:35 schrieb Thomas Zimmermann:
Using struct drm_device.pdev is deprecated. Convert nouveau to struct
drm_device.dev. No functional changes.
Signed-off-by: Thomas Zimmermann
Cc: Ben Skeggs
---
drivers/gpu/drm/nouveau/dispnv04/arb.c | 12 +++-
drivers/gpu/drm/nouveau/dispnv04/disp.h | 14 --
drivers/gpu/drm/nouveau/dispnv04/hw.c | 10 ++
drivers/gpu/drm/nouveau/nouveau_abi16.c | 7 ---
drivers/gpu/drm/nouveau/nouveau_acpi.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_bios.c | 11 ---
drivers/gpu/drm/nouveau/nouveau_connector.c | 10 ++
drivers/gpu/drm/nouveau/nouveau_drm.c | 5 ++---
drivers/gpu/drm/nouveau/nouveau_fbcon.c | 6 --
drivers/gpu/drm/nouveau/nouveau_vga.c | 20
10 files changed, 58 insertions(+), 39 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv04/arb.c
b/drivers/gpu/drm/nouveau/dispnv04/arb.c
index 9d4a2d97507e..1d3542d6006b 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/arb.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/arb.c
@@ -200,16 +200,17 @@ nv04_update_arb(struct drm_device *dev, int VClk, int bpp,
int MClk = nouveau_hw_get_clock(dev, PLL_MEMORY);
int NVClk = nouveau_hw_get_clock(dev, PLL_CORE);
uint32_t cfg1 = nvif_rd32(device, NV04_PFB_CFG1);
+ struct pci_dev *pdev = to_pci_dev(dev->dev);
sim_data.pclk_khz = VClk;
sim_data.mclk_khz = MClk;
sim_data.nvclk_khz = NVClk;
sim_data.bpp = bpp;
sim_data.two_heads = nv_two_heads(dev);
- if ((dev->pdev->device & 0x) == 0x01a0 /*CHIPSET_NFORCE*/ ||
- (dev->pdev->device & 0x) == 0x01f0 /*CHIPSET_NFORCE2*/) {
+ if ((pdev->device & 0x) == 0x01a0 /*CHIPSET_NFORCE*/ ||
+ (pdev->device & 0x) == 0x01f0 /*CHIPSET_NFORCE2*/) {
uint32_t type;
- int domain = pci_domain_nr(dev->pdev->bus);
+ int domain = pci_domain_nr(pdev->bus);
pci_read_config_dword(pci_get_domain_bus_and_slot(domain, 0, 1),
0x7c, &type);
@@ -251,11 +252,12 @@ void
nouveau_calc_arb(struct drm_device *dev, int vclk, int bpp, int *burst, int
*lwm)
{
struct nouveau_drm *drm = nouveau_drm(dev);
+ struct pci_dev *pdev = to_pci_dev(dev->dev);
if (drm->client.device.info.family < NV_DEVICE_INFO_V0_KELVIN)
nv04_update_arb(dev, vclk, bpp, burst, lwm);
- else if ((dev->pdev->device & 0xfff0) == 0x0240 /*CHIPSET_C51*/ ||
-(dev->pdev->device & 0xfff0) == 0x03d0 /*CHIPSET_C512*/) {
+ else if ((pdev->device & 0xfff0) == 0x0240 /*CHIPSET_C51*/ ||
+(pdev->device & 0xfff0) == 0x03d0 /*CHIPSET_C512*/) {
*burst = 128;
*lwm = 0x0480;
} else
diff --git a/drivers/gpu/drm/nouveau/dispnv04/disp.h
b/drivers/gpu/drm/nouveau/dispnv04/disp.h
index 5ace5e906949..f0a24126641a 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/disp.h
+++ b/drivers/gpu/drm/nouveau/dispnv04/disp.h
@@ -130,7 +130,7 @@ static inline bool
nv_two_heads(struct drm_device *dev)
{
struct nouveau_drm *drm = nouveau_drm(dev);
- const int impl = dev->pdev->device & 0x0ff0;
+ const int impl = to_pci_dev(dev->dev)->device & 0x0ff0;
if (drm->client.device.info.family >= NV_DEVICE_INFO_V0_CELSIUS && impl != 0x0100 &&
impl != 0x0150 && impl != 0x01a0 && impl != 0x0200)
@@ -142,14 +142,14 @@ nv_two_heads(struct drm_device *dev)
static inline bool
nv_gf4_disp_arch(struct drm_device *dev)
{
- return nv_two_heads(dev) && (dev->pdev->device & 0x0ff0) != 0x0110;
+ return nv_two_heads(dev) && (to_pci_dev(dev->dev)->device & 0x0ff0) !=
0x0110;
}
static inline bool
nv_two_reg_pll(struct drm_device *dev)
{
struct nouveau_drm *drm = nouveau_drm(dev);
- const int impl = dev->pdev->device & 0x0ff0;
+ const int impl = to_pci_dev(dev->dev)->device & 0x0ff0;
if (impl == 0x0310 || impl == 0x0340 || drm->client.device.info.family >= NV_DEVICE_INFO_V0_CURIE)
return true;
@@ -160,9 +160,11 @@ static inline bool
nv_match_device(struct drm_device *dev, unsigned device,
unsigned sub_vendor, unsigned sub_device)
{
- return dev->pdev->device == device &&
- dev->pdev->subsystem_vendor == sub_vendor &&
- dev->pdev->subsystem_device == sub_device;
+ struct pci_dev *pdev = to_pci_dev(dev->dev);
+
+ return pdev->device == device &&
+ pdev->subsystem_vendor == sub_vendor &&
+ pdev->subsystem_device == sub_device;
}
#include
diff --git a/drivers/gpu/drm/nouveau/dispnv04/hw.c
b/drivers/gpu/drm/nouveau/dispnv04/hw.c
index b674d68ef28a..f7d35657aa64 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/hw.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/hw.c
@@ -214,14
Re: [PATCH] drm/bridge: ti-sn65dsi86: Implement the pwm_chip
Hello,
On Mon, Dec 07, 2020 at 10:40:22PM -0600, Bjorn Andersson wrote:
> The SN65DSI86 provides the ability to supply a PWM signal on GPIO 4,
> with the primary purpose of controlling the backlight of the attached
> panel. Add an implementation that exposes this using the standard PWM
> framework, to allow e.g. pwm-backlight to expose this to the user.
>
> Special thanks to Doug Anderson for suggestions related to the involved
> math.
Did you test this with CONFIG_PWM_DEBUG? (I think you didn't, because
otherwise there would be a .get_state callback.)
> @@ -162,6 +171,12 @@ struct ti_sn_bridge {
> struct gpio_chipgchip;
> DECLARE_BITMAP(gchip_output, SN_NUM_GPIOS);
> #endif
> +#if defined(CONFIG_PWM)
Would it make sense to introduce a separate config symbol for this?
Something like CONFIG_PWM_SN65DSI87?
> + struct pwm_chip pchip;
> + boolpwm_enabled;
> + unsigned intpwm_refclk;
> + atomic_tpwm_pin_busy;
struct ti_sn_bridge has a kernel doc comment describing all members,
please add a description of the members you introduced here. Please also
point out that you use pwm_pin_busy to protect against concurrent use of
the pin as PWM and GPIO.
> +#endif
> };
>
> static const struct regmap_range ti_sn_bridge_volatile_ranges[] = {
> @@ -499,6 +514,14 @@ static void ti_sn_bridge_set_refclk_freq(struct
> ti_sn_bridge *pdata)
>
> regmap_update_bits(pdata->regmap, SN_DPPLL_SRC_REG, REFCLK_FREQ_MASK,
> REFCLK_FREQ(i));
> +
> +#if defined(CONFIG_PWM)
> + /*
> + * The PWM refclk is based on the value written to SN_DPPLL_SRC_REG,
> + * regardless of its actual sourcing.
> + */
> + pdata->pwm_refclk = ti_sn_bridge_refclk_lut[i];
> +#endif
I don't understand this code. 'i' seems to be something more special
than a counter variable, so I wonder if it should have a better name.
(This is however an issue separate from this patch, but it would be
great to first make the code a bit better understandable. Or is this
only me?)
> }
>
> static void ti_sn_bridge_set_dsi_rate(struct ti_sn_bridge *pdata)
> @@ -981,6 +1004,161 @@ static int ti_sn_bridge_parse_dsi_host(struct
> ti_sn_bridge *pdata)
> return 0;
> }
>
> +#if defined(CONFIG_PWM)
> +static int ti_sn_pwm_pin_request(struct ti_sn_bridge *pdata)
> +{
> + return atomic_xchg(&pdata->pwm_pin_busy, 1) ? -EBUSY : 0;
> +}
> +
> +static void ti_sn_pwm_pin_release(struct ti_sn_bridge *pdata)
> +{
> + atomic_set(&pdata->pwm_pin_busy, 0);
> +}
> +
> +static struct ti_sn_bridge *
> +pwm_chip_to_ti_sn_bridge(struct pwm_chip *chip)
All your functions share the same function prefix (which is fine), but
this one doesn't.
> +{
> + return container_of(chip, struct ti_sn_bridge, pchip);
> +}
> [...]
> + if (state->enabled) {
> + /*
> + * Per the datasheet the PWM frequency is given by:
> + *
> + * PWM_FREQ = REFCLK_FREQ / (PWM_PRE_DIV * BACKLIGHT_SCALE + 1)
> + *
> + * In order to find the PWM_FREQ that best suits the requested
> + * state->period, the PWM_PRE_DIV is calculated with the
> + * maximum possible number of steps (BACKLIGHT_SCALE_MAX). The
> + * actual BACKLIGHT_SCALE is then adjusted down to match the
> + * requested period.
> + *
> + * The BACKLIGHT value is then calculated against the
> + * BACKLIGHT_SCALE, based on the requested duty_cycle and
> + * period.
> + */
> + pwm_freq = NSEC_PER_SEC / state->period;
Here you should better have some range checking. Consider for example
state->period being > NSEC_PER_SEC. (Hint: This makes pwm_freq = 0 and
in the next line you divide by pwm_freq.)
> + pre_div = DIV_ROUND_UP(pdata->pwm_refclk / pwm_freq - 1,
> BACKLIGHT_SCALE_MAX);
> + scale = (pdata->pwm_refclk / pwm_freq - 1) / pre_div;
I'm still trying to wrap my head around this calculation, but dividing
by the result of a division is always loosing precision. This is really
involved and I'm willing to bet this can be done easier and with more
precision.
... some time later ...
You wrote "PWM_FREQ = REFCLK_FREQ / (PWM_PRE_DIV * BACKLIGHT_SCALE + 1)",
so (I think) that means you have:
period = (PWM_PRE_DIV * BACKLIGHT_SCALE + 1) / refclk
right? I deduce from your formula how the duty_cycle is defined and I
think it's:
duty_cycle = (PWM_PRE_DIV * BACKLIGHT + 1) / refclk
is this right? And now your idea to "best suite the requested period" is
to select a small divider such that you can still use a big value in
SCALE to define the period and so have a fine separation for the
duty_cycle, right?
I will stop doing maths here now until you confirm my steps up to now
are right.
> + backlight = sca
Re: [PATCH drm/hisilicon v2 1/2] drm/hisilicon: Use managed mode-config init
在 2020/12/7 17:22, Thomas Zimmermann 写道:
Hi
Am 07.12.20 um 10:05 schrieb Tian Tao:
Using drmm_mode_config_init() sets up managed release of modesetting
resources.
Individual patches usually contain a changelog to highlight the
difference to previous versions. Please add one before committing the
Just to be sure: I don't need to add a changlog to this individual
patch, right?
patch. Your cover letter for the series already does this correctly.
Signed-off-by: Tian Tao
Reviewed-by: Thomas Zimmermann
Thanks for all these updates.
Thank you for your constant help with the review code and your careful
guidance!
---
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 14 +++---
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h | 1 -
2 files changed, 3 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
index 3687753..7f01213 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
@@ -96,8 +96,9 @@ static int hibmc_kms_init(struct hibmc_drm_private
*priv)
struct drm_device *dev = &priv->dev;
int ret;
- drm_mode_config_init(dev);
- priv->mode_config_initialized = true;
+ ret = drmm_mode_config_init(dev);
+ if (ret)
+ return ret;
dev->mode_config.min_width = 0;
dev->mode_config.min_height = 0;
@@ -125,14 +126,6 @@ static int hibmc_kms_init(struct
hibmc_drm_private *priv)
return 0;
}
-static void hibmc_kms_fini(struct hibmc_drm_private *priv)
-{
- if (priv->mode_config_initialized) {
- drm_mode_config_cleanup(&priv->dev);
- priv->mode_config_initialized = false;
- }
-}
-
/*
* It can operate in one of three modes: 0, 1 or Sleep.
*/
@@ -262,7 +255,6 @@ static int hibmc_unload(struct drm_device *dev)
drm_atomic_helper_shutdown(dev);
pci_disable_msi(dev->pdev);
- hibmc_kms_fini(priv);
dev->dev_private = NULL;
return 0;
}
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
index a49c10e..7d263f4 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
@@ -42,7 +42,6 @@ struct hibmc_drm_private {
struct drm_crtc crtc;
struct drm_encoder encoder;
struct hibmc_connector connector;
- bool mode_config_initialized;
};
static inline struct hibmc_connector *to_hibmc_connector(struct
drm_connector *connector)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH drm/hisilicon v2 0/2] Code refactoring
patch #1 is used drmm_mode_config_init() to do code refactoring. patch #2 is deleted unused variable ‘priv’ to avoid warning. Changes since v1: patch #1 is removed the unused structure member variable mode_config_initialized. Tian Tao (2): drm/hisilicon: Use managed mode-config init drm/hisilicon: Delete unused local parameters drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 19 --- drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h | 1 - 2 files changed, 4 insertions(+), 16 deletions(-) -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 0/9] drm/vc4: hdmi: Support the 10/12 bit output
Hi, Here's some patches to enable the HDR output in the RPi4/BCM2711 HDMI controller. Let me know what you think, Maxime Changes from v4: - Added the tags from Thomas - Fixed an issue with the clock doubling - Changed a comment to match the code being introduced Changes from v3: - Don't dereference the connector->state pointer if kzalloc failed Changes from v2: - Rebased on current drm-misc-next - Fixed a bug that was dropping the refresh rate when the bpc count was increased Changes from v1: - Added the coccinelle script to the first patch - Fixed the pixel_rate ramp up Maxime Ripard (9): drm/vc4: hvs: Align the HVS atomic hooks to the new API drm/vc4: Pass the atomic state to encoder hooks drm/vc4: hdmi: Take into account the clock doubling flag in atomic_check drm/vc4: hdmi: Don't access the connector state in reset if kmalloc fails drm/vc4: hdmi: Create a custom connector state drm/vc4: hdmi: Store pixel frequency in the connector state drm/vc4: hdmi: Use the connector state pixel rate for the PHY drm/vc4: hdmi: Limit the BCM2711 to the max without scrambling drm/vc4: hdmi: Enable 10/12 bpc output drivers/gpu/drm/vc4/vc4_crtc.c | 22 ++-- drivers/gpu/drm/vc4/vc4_drv.h | 14 +-- drivers/gpu/drm/vc4/vc4_hdmi.c | 154 +--- drivers/gpu/drm/vc4/vc4_hdmi.h | 23 +++-- drivers/gpu/drm/vc4/vc4_hdmi_phy.c | 8 +- drivers/gpu/drm/vc4/vc4_hdmi_regs.h | 9 ++ drivers/gpu/drm/vc4/vc4_hvs.c | 8 +- drivers/gpu/drm/vc4/vc4_txp.c | 8 +- 8 files changed, 197 insertions(+), 49 deletions(-) -- 2.28.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 1/8] dt-bindings: display: simple: fix alphabetical order for EDT compatibles
Reorder it alphabetically and remove one double entry. Signed-off-by: Oleksij Rempel --- .../bindings/display/panel/panel-simple.yaml | 14 ++ 1 file changed, 6 insertions(+), 8 deletions(-) diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml index edb53ab0d9eb..7e459ff974dd 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml @@ -105,26 +105,24 @@ properties: - dlc,dlc1010gig # Emerging Display Technology Corp. 3.5" QVGA TFT LCD panel - edt,et035012dm6 +# Emerging Display Technology Corp. 5.7" VGA TFT LCD panel + - edt,et057090dhu # Emerging Display Technology Corp. 480x272 TFT Display with capacitive touch - edt,etm043080dh6gp # Emerging Display Technology Corp. 480x272 TFT Display - edt,etm0430g0dh6 -# Emerging Display Technology Corp. 5.7" VGA TFT LCD panel - - edt,et057090dhu -# Emerging Display Technology Corp. WVGA TFT Display with capacitive touch - - edt,etm070080dh6 -# Emerging Display Technology Corp. WVGA TFT Display with capacitive touch - - edt,etm0700g0dh6 # Emerging Display Technology Corp. WVGA TFT Display with capacitive touch # Same as ETM0700G0DH6 but with inverted pixel clock. - edt,etm070080bdh6 +# Emerging Display Technology Corp. WVGA TFT Display with capacitive touch +# Same timings as the ETM0700G0DH6, but with resistive touch. + - edt,etm070080dh6 # Emerging Display Technology Corp. WVGA TFT Display with capacitive touch # Same display as the ETM0700G0BDH6, but with changed hardware for the # backlight and the touch interface. - edt,etm070080edh6 # Emerging Display Technology Corp. WVGA TFT Display with capacitive touch -# Same timings as the ETM0700G0DH6, but with resistive touch. - - edt,etm070080dh6 + - edt,etm0700g0dh6 # Evervision Electronics Co. Ltd. VGG804821 5.0" WVGA TFT LCD Panel - evervision,vgg804821 # Foxlink Group 5" WVGA TFT LCD panel -- 2.29.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Fix drm.h uapi header for Windows
That would work, but that's kind of an annoying requirement. I would prefer the header to be self-sufficient. Thanks, James On Mon, Dec 7, 2020 at 2:47 AM Simon Ser wrote: > On Monday, December 7th, 2020 at 11:44 AM, Pekka Paalanen < > ppaala...@gmail.com> wrote: > > > But then, the code in the header should be literally > > > > #ifndef DRM_FOURCC_STANDALONE > > #include "drm.h" > > #endif > > > > without an #else branch. > > As long as there is a #include "drm_basic_types.h" right before > (drm_fourcc.h needs __u32 and __u64), I believe this can work too > indeed. > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/8] drm/vc4: DSI improvements and BCM2711 support
On Thu, Dec 03, 2020 at 03:19:15PM +, Dave Stevenson wrote: > Hi Maxime > > On Thu, 3 Dec 2020 at 13:25, Maxime Ripard wrote: > > > > Hi, > > > > Here's a series adding support for the DSI0 controller in the BCM2835 and > > the > > DSI1 controller found in the BCM2711. > > > > Let me know what you think, > > Maxime > > Thanks for that series - your using a variant structure is much > cleaner than the hack I had. > > For those that I didn't author (ie 1, 3, and 4) > Reviewed-by: Dave Stevenson Applied 1-7 to drm-misc-next Thanks! Maxime signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 3/6] dt-bindings: display: add Unisoc's dpu bindings
From: Kevin Tang
DPU (Display Processor Unit) is the Display Controller for the Unisoc SoCs
which transfers the image data from a video memory buffer to an internal
LCD interface.
Cc: Orson Zhai
Cc: Chunyan Zhang
Signed-off-by: Kevin Tang
---
.../bindings/display/sprd/sprd,sharkl3-dpu.yaml| 83 ++
1 file changed, 83 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/sprd/sprd,sharkl3-dpu.yaml
diff --git
a/Documentation/devicetree/bindings/display/sprd/sprd,sharkl3-dpu.yaml
b/Documentation/devicetree/bindings/display/sprd/sprd,sharkl3-dpu.yaml
new file mode 100644
index 000..a9052e1
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/sprd/sprd,sharkl3-dpu.yaml
@@ -0,0 +1,83 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/sprd/sprd,sharkl3-dpu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Unisoc Sharkl3 Display Processor Unit (DPU)
+
+maintainers:
+ - Kevin Tang
+
+description: |
+ DPU (Display Processor Unit) is the Display Controller for the Unisoc SoCs
+ which transfers the image data from a video memory buffer to an internal
+ LCD interface.
+
+properties:
+ compatible:
+const: sprd,sharkl3-dpu
+
+ reg:
+maxItems: 1
+description:
+ Physical base address and length of the DPU registers set
+
+ interrupts:
+maxItems: 1
+description:
+ The interrupt signal from DPU
+
+ clocks:
+minItems: 2
+
+ clock-names:
+items:
+ - const: clk_src_128m
+ - const: clk_src_384m
+
+ power-domains:
+maxItems: 1
+description: A phandle to DPU power domain node.
+
+ iommus:
+maxItems: 1
+description: A phandle to DPU iommu node.
+
+ port:
+type: object
+description:
+ A port node with endpoint definitions as defined in
+ Documentation/devicetree/bindings/media/video-interfaces.txt.
+ That port should be the output endpoint, usually output to
+ the associated DSI.
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+ - port
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+dpu: dpu@6300 {
+compatible = "sprd,sharkl3-dpu";
+reg = <0x6300 0x1000>;
+interrupts = ;
+clock-names = "clk_src_128m", "clk_src_384m";
+
+clocks = <&pll CLK_TWPLL_128M>,
+ <&pll CLK_TWPLL_384M>;
+
+dpu_port: port {
+dpu_out: endpoint {
+remote-endpoint = <&dsi_in>;
+};
+};
+};
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 1/8] dt-bindings: display: simple: fix alphabetical order for EDT compatibles
On Sat, Dec 05, 2020 at 08:32:29PM +0100, Sam Ravnborg wrote: > Hi Oleksij > Thanks for fixing this, but something is not correct. > I think you switched around the order of comment and compatible. Ack, i confused my self with comments like: > > - - edt,etm0700g0dh6 > > -# Emerging Display Technology Corp. WVGA TFT Display with > > capacitive touch > > -# Same as ETM0700G0DH6 but with inverted pixel clock. > >- edt,etm070080bdh6 Do this comments actually make any sense? All of this devices are kind of similar to each other. > On Wed, Dec 02, 2020 at 09:18:19AM +0100, Oleksij Rempel wrote: > > Reorder it alphabetically and remove one double entry. > > > > Signed-off-by: Oleksij Rempel > > --- > > .../bindings/display/panel/panel-simple.yaml | 16 +++- > > 1 file changed, 7 insertions(+), 9 deletions(-) > > > > diff --git > > a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml > > b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml > > index edb53ab0d9eb..428b03342fea 100644 > > --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml > > +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml > > @@ -106,26 +106,24 @@ properties: > > # Emerging Display Technology Corp. 3.5" QVGA TFT LCD panel > >- edt,et035012dm6 > > # Emerging Display Technology Corp. 480x272 TFT Display with > > capacitive touch > > + - edt,et057090dhu > > +# Emerging Display Technology Corp. WVGA TFT Display with > > capacitive touch > >- edt,etm043080dh6gp > > # Emerging Display Technology Corp. 480x272 TFT Display > >- edt,etm0430g0dh6 > > # Emerging Display Technology Corp. 5.7" VGA TFT LCD panel > > - - edt,et057090dhu > > -# Emerging Display Technology Corp. WVGA TFT Display with > > capacitive touch > > - - edt,etm070080dh6 > > -# Emerging Display Technology Corp. WVGA TFT Display with > > capacitive touch > > # Emerging Display Technology Corp. WVGA TFT Display with > > capacitive touch > > # Same display as the ETM0700G0BDH6, but with changed hardware for > > the > > # backlight and the touch interface. > > + - edt,etm070080dh6 > > +# Emerging Display Technology Corp. WVGA TFT Display with > > capacitive touch > >- edt,etm070080edh6 > > # Emerging Display Technology Corp. WVGA TFT Display with > > capacitive touch > > # Same timings as the ETM0700G0DH6, but with resistive touch. > > - - edt,etm070080dh6 > > -# Evervision Electronics Co. Ltd. VGG804821 5.0" WVGA TFT LCD Panel > > + - edt,etm0700g0dh6 > > +# Emerging Display Technology Corp. WVGA TFT Display with > > capacitive touch > > +# Same as ETM0700G0DH6 but with inverted pixel clock. > >- evervision,vgg804821 > > # Foxlink Group 5" WVGA TFT LCD panel > >- foxlink,fl500wvr00-a0t > > It goes like this > > # This is the comment > - compatible,for-the-comment > > I always look at the first entry when I need to check the order. > Also the comment for evervision,vgg804821 seems to be lost in the above. ack. Regards, Oleksij -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 2/8] dt-bindings: display: simple: add EDT compatibles already supported by the driver
Some EDT compatibles are already supported by the driver but will fail on checkpatch script. Fix it by syncing dt-bindings documentation with the driver. Signed-off-by: Oleksij Rempel --- .../devicetree/bindings/display/panel/panel-simple.yaml| 3 +++ 1 file changed, 3 insertions(+) diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml index 7e459ff974dd..46e5b2a5a011 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml @@ -107,6 +107,7 @@ properties: - edt,et035012dm6 # Emerging Display Technology Corp. 5.7" VGA TFT LCD panel - edt,et057090dhu + - edt,et070080dh6 # Emerging Display Technology Corp. 480x272 TFT Display with capacitive touch - edt,etm043080dh6gp # Emerging Display Technology Corp. 480x272 TFT Display @@ -121,8 +122,10 @@ properties: # Same display as the ETM0700G0BDH6, but with changed hardware for the # backlight and the touch interface. - edt,etm070080edh6 + - edt,etm0700g0bdh6 # Emerging Display Technology Corp. WVGA TFT Display with capacitive touch - edt,etm0700g0dh6 + - edt,etm0700g0edh6 # Evervision Electronics Co. Ltd. VGG804821 5.0" WVGA TFT LCD Panel - evervision,vgg804821 # Foxlink Group 5" WVGA TFT LCD panel -- 2.29.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 6/6] drm/sprd: add Unisoc's drm mipi dsi&dphy driver
Adds dsi host controller support for the Unisoc's display subsystem.
Adds dsi phy support for the Unisoc's display subsystem.
Only MIPI DSI Displays supported, DP/TV/HMDI will be support
in the feature.
v1:
- Remove dphy and dsi graph binding, merge the dphy driver into the dsi.
Cc: Orson Zhai
Cc: Chunyan Zhang
Signed-off-by: Kevin Tang
---
drivers/gpu/drm/sprd/Makefile |8 +-
drivers/gpu/drm/sprd/dw_dsi_ctrl.c | 792 +
drivers/gpu/drm/sprd/dw_dsi_ctrl.h | 1475
drivers/gpu/drm/sprd/dw_dsi_ctrl_ppi.c | 275 ++
drivers/gpu/drm/sprd/dw_dsi_ctrl_ppi.h | 34 +
drivers/gpu/drm/sprd/megacores_pll.c | 316 +++
drivers/gpu/drm/sprd/megacores_pll.h | 146
drivers/gpu/drm/sprd/sprd_drm.c|1 +
drivers/gpu/drm/sprd/sprd_drm.h|1 +
drivers/gpu/drm/sprd/sprd_dsi.c| 1145 +
drivers/gpu/drm/sprd/sprd_dsi.h| 106 +++
11 files changed, 4297 insertions(+), 2 deletions(-)
create mode 100644 drivers/gpu/drm/sprd/dw_dsi_ctrl.c
create mode 100644 drivers/gpu/drm/sprd/dw_dsi_ctrl.h
create mode 100644 drivers/gpu/drm/sprd/dw_dsi_ctrl_ppi.c
create mode 100644 drivers/gpu/drm/sprd/dw_dsi_ctrl_ppi.h
create mode 100644 drivers/gpu/drm/sprd/megacores_pll.c
create mode 100644 drivers/gpu/drm/sprd/megacores_pll.h
create mode 100644 drivers/gpu/drm/sprd/sprd_dsi.c
create mode 100644 drivers/gpu/drm/sprd/sprd_dsi.h
diff --git a/drivers/gpu/drm/sprd/Makefile b/drivers/gpu/drm/sprd/Makefile
index 0ba48f2..599a2ca 100644
--- a/drivers/gpu/drm/sprd/Makefile
+++ b/drivers/gpu/drm/sprd/Makefile
@@ -1,7 +1,11 @@
# SPDX-License-Identifier: GPL-2.0
obj-y := sprd_drm.o \
- sprd_dpu.o
+ sprd_dpu.o \
+ sprd_dsi.o \
+ dpu_r2p0.o \
+ dw_dsi_ctrl.o \
+ dw_dsi_ctrl_ppi.o \
+ megacores_pll.o
-obj-y += dpu_r2p0.o
diff --git a/drivers/gpu/drm/sprd/dw_dsi_ctrl.c
b/drivers/gpu/drm/sprd/dw_dsi_ctrl.c
new file mode 100644
index 000..1470d7d
--- /dev/null
+++ b/drivers/gpu/drm/sprd/dw_dsi_ctrl.c
@@ -0,0 +1,792 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2020 Unisoc Inc.
+ */
+
+#include
+#include
+#include
+#include
+
+#include "dw_dsi_ctrl.h"
+
+/*
+ * Modify power status of DSI Host core
+ */
+void dsi_power_enable(struct dsi_context *ctx, int enable)
+{
+ struct dsi_reg *reg = (struct dsi_reg *)ctx->base;
+
+ writel(enable, ®->SOFT_RESET);
+}
+/*
+ * Enable/disable DPI video mode
+ */
+void dsi_video_mode(struct dsi_context *ctx)
+{
+ struct dsi_reg *reg = (struct dsi_reg *)ctx->base;
+
+ writel(0, ®->DSI_MODE_CFG);
+}
+/*
+ * Enable command mode (Generic interface)
+ */
+void dsi_cmd_mode(struct dsi_context *ctx)
+{
+ struct dsi_reg *reg = (struct dsi_reg *)ctx->base;
+
+ writel(1, ®->DSI_MODE_CFG);
+}
+
+bool dsi_is_cmd_mode(struct dsi_context *ctx)
+{
+ struct dsi_reg *reg = (struct dsi_reg *)ctx->base;
+
+ return readl(®->DSI_MODE_CFG);
+}
+/*
+ * Configure the read back virtual channel for the generic interface
+ */
+void dsi_rx_vcid(struct dsi_context *ctx, u8 vc)
+{
+ struct dsi_reg *reg = (struct dsi_reg *)ctx->base;
+ union _0x1C virtual_channel_id;
+
+ virtual_channel_id.val = readl(®->VIRTUAL_CHANNEL_ID);
+ virtual_channel_id.bits.gen_rx_vcid = vc;
+
+ writel(virtual_channel_id.val, ®->VIRTUAL_CHANNEL_ID);
+}
+/*
+ * Write the DPI video virtual channel destination
+ */
+void dsi_video_vcid(struct dsi_context *ctx, u8 vc)
+{
+ struct dsi_reg *reg = (struct dsi_reg *)ctx->base;
+ union _0x1C virtual_channel_id;
+
+ virtual_channel_id.val = readl(®->VIRTUAL_CHANNEL_ID);
+ virtual_channel_id.bits.video_pkt_vcid = vc;
+
+ writel(virtual_channel_id.val, ®->VIRTUAL_CHANNEL_ID);
+}
+/*
+ * Set DPI video mode type (burst/non-burst - with sync pulses or events)
+ */
+void dsi_dpi_video_burst_mode(struct dsi_context *ctx, int mode)
+{
+ struct dsi_reg *reg = (struct dsi_reg *)ctx->base;
+ union _0x38 vid_mode_cfg;
+
+ vid_mode_cfg.val = readl(®->VID_MODE_CFG);
+ vid_mode_cfg.bits.vid_mode_type = mode;
+
+ writel(vid_mode_cfg.val, ®->VID_MODE_CFG);
+}
+/*
+ * Set DPI video color coding
+ */
+void dsi_dpi_color_coding(struct dsi_context *ctx, int coding)
+{
+ struct dsi_reg *reg = (struct dsi_reg *)ctx->base;
+ union _0x20 dpi_video_format;
+
+ dpi_video_format.val = readl(®->DPI_VIDEO_FORMAT);
+ dpi_video_format.bits.dpi_video_mode_format = coding;
+
+ writel(dpi_video_format.val, ®->DPI_VIDEO_FORMAT);
+}
+/*
+ * Configure the Horizontal Line time
+ * param "byte_cycle" taken to transmit the total of the horizontal line
+ */
+void dsi_dpi_hline_time(struct dsi_context *ctx, u16 byte_cycle)
+{
+ struct dsi_reg *reg = (struct dsi_reg *)ctx->base;
+ union _0x2C video_line_time;
+
+ video_line_time.val = readl(®->VIDEO_LINE_TIME);
+
Re: [PATCH] drm: Fix drm.h uapi header for Windows
I'm not completely sure what you're saying, but doesn't drm_base_types.h (now drm_basic_types.h) make things robust to header order? The patch is in another email. You can also see it here: https://github.com/jpark37/linux/commit/0cc8ae750bfd9eab7e31c7de6aa84f24682f4f18 Thanks, James On Mon, Dec 7, 2020 at 12:51 AM Pekka Paalanen wrote: > On Fri, 4 Dec 2020 11:07:41 -0800 > James Park wrote: > > > I could adjust the block to look like this: > > > > #ifdef DRM_FOURCC_STANDALONE > > #if defined(__linux__) > > #include > > #else > > #include > > typedef uint32_t __u32; > > typedef uint64_t __u64; > > #endif > > #else > > #include "drm.h" > > #endif > > > > Alternatively, I could create a new common header to be included from > both > > drm.h and drm_fourcc.h, drm_base_types.h or something like that: > > > > #ifdef DRM_FOURCC_STANDALONE > > #include "drm_base_types.h" > > #else > > #include "drm.h" > > #endif > > Hi, > > my point is, any solution relying on DRM_FOURCC_STANDALONE will fail > sometimes, because there is no reason why userspace would *not* #define > DRM_FOURCC_STANDALONE. Hence, #ifdef DRM_FOURCC_STANDALONE is > completely moot, you have to make the headers work in any include > order when DRM_FOURCC_STANDALONE is defined anyway. > > > Thanks. > pq > > > On Fri, Dec 4, 2020 at 7:58 AM Daniel Vetter wrote: > > > > > On Fri, Dec 4, 2020 at 9:12 AM Pekka Paalanen > wrote: > > > > > > > > On Thu, 3 Dec 2020 21:45:14 +0100 > > > > Daniel Vetter wrote: > > > > > > > > > On Thu, Dec 3, 2020 at 7:55 PM James Park < > james.p...@lagfreegames.com> > > > wrote: > > > > > > > > > > > > The trailing underscore for DRM_FOURCC_STANDALONE_ isn't > > > > > > intentional, right? Should I put all the integer types, or just > the > > > > > > ones that are used in that file? > > > > > > > > > > Yeah that trailing _ just slipped in. And I'd just do the types > > > > > already used. I don't think anything else than __u32 (for drm > fourcc) > > > > > and __u64 (for drm modifier) is needed. > > > > > > > > Hi, > > > > > > > > can that create conflicts if userspace first includes drm_fourcc.h > and > > > > then drm.h? > > > > > > > > I would find it natural to userspace have generic headers including > > > > drm_fourcc.h and then DRM-specific C-files including drm.h as well > > > > (through libdrm headers). I think Weston might already do this. > > > > > > > > The generic userspace (weston) header would obviously #define > > > > DRM_FOURCC_STANDALONE, because it is used by non-DRM C-files as > well. > > > > > > Hm yes that would break. I guess we could just include the linux types > > > header for this. And I guess on windows you'd need to have that from > > > somewhere. Or we just require that users of the standalone header pull > > > the right header or defines in first? > > > -Daniel > > > -- > > > Daniel Vetter > > > Software Engineer, Intel Corporation > > > http://blog.ffwll.ch > > > > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 0/7] dma-buf: Performance improvements for system heap & a system-uncached implementation
Le vendredi 13 novembre 2020 à 21:39 +0100, Daniel Vetter a écrit : > On Thu, Nov 12, 2020 at 08:11:02PM -0800, John Stultz wrote: > > On Thu, Nov 12, 2020 at 1:32 AM Daniel Vetter wrote: > > > On Thu, Nov 12, 2020 at 11:09:04AM +0530, Sumit Semwal wrote: > > > > On Tue, 10 Nov 2020 at 09:19, John Stultz > > > > wrote: > > > > > > > > > > Hey All, > > > > > So just wanted to send my last revision of my patch series > > > > > of performance optimizations to the dma-buf system heap. > > > > > > > > Thanks very much for your patches - I think the first 5 patches look > > > > good to me. > > > > > > > > I know there was a bit of discussion over adding a new system-uncached > > > > heap v/s using a flag to identify that; I think I prefer the separate > > > > heap idea, but lets ask one last time if any one else has any real > > > > objections to it. > > > > > > > > Daniel, Christian: any comments from your side on this? > > > > > > I do wonder a bit where the userspace stack for this all is, since tuning > > > allocators without a full stack is fairly pointless. dma-buf heaps is a > > > bit in a limbo situation here it feels like. > > > > As mentioned in the system-uncached patch: > > Pending opensource users of this code include: > > * AOSP HiKey960 gralloc: > > - https://android-review.googlesource.com/c/device/linaro/hikey/+/1399519 > > - Visibly improves performance over the system heap > > * AOSP Codec2 (possibly, needs more review): > > - > > https://android-review.googlesource.com/c/platform/frameworks/av/+/1360640/17/media/codec2/vndk/C2DmaBufAllocator.cpp#325 > > > > Additionally both the HiKey, HiKey960 grallocs and Codec2 are already > > able to use the current dmabuf heaps instead of ION. > > > > So I'm not sure what you mean by limbo, other than it being in a > > transition state where the interface is upstream and we're working on > > moving vendors to it from ION (which is staged to be dropped in 5.11). > > Part of that work is making sure we don't regress the performance > > expectations. > > The mesa thing below, since if we test this with some downstream kernel > drivers or at least non-mesa userspace I'm somewhat worried we're just > creating a nice split world between the android gfx world and the > mesa/linux desktop gfx world. > > But then that's kinda how android rolls, so *shrug* > > > > Plus I'm vary of anything related to leaking this kind of stuff beyond the > > > dma-api because dma api maintainers don't like us doing that. But > > > personally no concern on that front really, gpus need this. It's just that > > > we do need solid justification I think if we land this. Hence back to > > > first point. > > > > > > Ideally first point comes in the form of benchmarking on android together > > > with a mesa driver (or mesa + some v4l driver or whatever it takes to > > > actually show the benefits, I have no idea). > > > > Tying it with mesa is a little tough as the grallocs for mesa devices > > usually use gbm (gralloc.gbm or gralloc.minigbm). Swapping the > > allocation path for dmabuf heaps there gets a little complex as last I > > tried that (when trying to get HiKey working with Lima graphics, as > > gbm wouldn't allocate the contiguous buffers required by the display), > > I ran into issues with the drm_hwcomposer and mesa expecting the gbm > > private handle metadata in the buffer when it was passed in. > > > > But I might take a look at it again. I got a bit lost digging through > > the mesa gbm allocation paths last time. > > > > I'll also try to see if I can find a benchmark for the codec2 code > > (using dmabuf heaps with and without the uncached heap) on on db845c > > (w/ mesa), as that is already working and I suspect that might be > > close to what you're looking for. > > tbh I think trying to push for this long term is the best we can hope for. > > Media is also a lot more *meh* since it's deeply fragmented and a lot less > of it upstream than on the gles/display side. Sorry to jump in, but I'd like to reset a bit. The Media APIs are a lot more generic, most of the kernel API is usable without specific knowledge of the HW. Pretty much all APIs are exercised through v4l2-ctl and v4l2-compliance on the V4L2 side (including performance testing). It would be pretty straight forward to demonstrate the use of DMABuf heaps (just do live resolution switching, you'll beat the internal V4L2 allocator without even looking at DMA cache optimization). > > I think confirming that this at least doesn't horrible blow up on a > gralloc/gbm+mesa stack would be useful I think. > -Daniel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 3/5] thermal: devfreq_cooling: add new registration functions with Energy Model
On 12/3/20 3:40 PM, Daniel Lezcano wrote:
On 18/11/2020 13:03, Lukasz Luba wrote:
The Energy Model (EM) framework supports devices such as Devfreq. Create
new registration functions which automatically register EM for the thermal
devfreq_cooling devices. This patch prepares the code for coming changes
which are going to replace old power model with the new EM.
Signed-off-by: Lukasz Luba
---
drivers/thermal/devfreq_cooling.c | 99 ++-
include/linux/devfreq_cooling.h | 22 +++
2 files changed, 120 insertions(+), 1 deletion(-)
diff --git a/drivers/thermal/devfreq_cooling.c
b/drivers/thermal/devfreq_cooling.c
index 925523694462..b354271742c5 100644
--- a/drivers/thermal/devfreq_cooling.c
+++ b/drivers/thermal/devfreq_cooling.c
@@ -50,6 +50,8 @@ static DEFINE_IDA(devfreq_ida);
* @capped_state: index to cooling state with in dynamic power budget
* @req_max_freq: PM QoS request for limiting the maximum frequency
*of the devfreq device.
+ * @em:Energy Model for the associated Devfreq device
+ * @em_registered: Devfreq cooling registered the EM and should free it.
*/
struct devfreq_cooling_device {
int id;
@@ -63,6 +65,8 @@ struct devfreq_cooling_device {
u32 res_util;
int capped_state;
struct dev_pm_qos_request req_max_freq;
+ struct em_perf_domain *em;
This pointer is not needed, it is in the struct device.
It is just a helper pointer, to make the code simpler and avoid nested
pointers:
struct device *dev = dfc->devfreq->dev.parent
and then using dev->em
The code is cleaner with dfc->em, but let me have a look if I can
remove it and still have a clean code.
+ bool em_registered;
The boolean em_registered is not needed because of the test in the
function em_dev_unregister_perf_domain():
if (IS_ERR_OR_NULL(dev) || !dev->em_pd)
return;
Logically if the 'em' was not initialized, it must be NULL, the
corresponding struct device was zero-allocated.
It was needed for devfreq cooling to know who registered the EM.
If there is 2 frameworks and driver and all could register EM,
this code cannot blindly unregister EM in it's code. The EM might
be used still by PowerCap DTM, so the unregister might be called
explicitly by the driver.
But I will rewrite the register function and make it way simpler,
just registration of EM (stopping when it failed) and then cooling
device. Also unregister will be simpler.
Driver will have to keep the order of unregister functions for two
frameworks and call unregister devfreq cooling device as last one,
because it will remove the EM.
};
static int devfreq_cooling_get_max_state(struct thermal_cooling_device *cdev,
@@ -583,22 +587,115 @@ struct thermal_cooling_device
*devfreq_cooling_register(struct devfreq *df)
}
EXPORT_SYMBOL_GPL(devfreq_cooling_register);
+/**
+ * devfreq_cooling_em_register_power() - Register devfreq cooling device with
+ * power information and attempt to register Energy Model (EM)
+ * @df:Pointer to devfreq device.
+ * @dfc_power: Pointer to devfreq_cooling_power.
+ * @em_cb: Callback functions providing the data of the EM
+ *
+ * Register a devfreq cooling device and attempt to register Energy Model. The
+ * available OPPs must be registered for the device.
+ *
+ * If @dfc_power is provided, the cooling device is registered with the
+ * power extensions. If @em_cb is provided it will be called for each OPP to
+ * calculate power value and cost. If @em_cb is not provided then simple Energy
+ * Model is going to be used, which requires "dynamic-power-coefficient" a
+ * devicetree property.
+ */
+struct thermal_cooling_device *
+devfreq_cooling_em_register_power(struct devfreq *df,
+ struct devfreq_cooling_power *dfc_power,
+ struct em_data_callback *em_cb)
+{
+ struct thermal_cooling_device *cdev;
+ struct devfreq_cooling_device *dfc;
+ struct device_node *np = NULL;
+ struct device *dev;
+ int nr_opp, ret;
+
+ if (IS_ERR_OR_NULL(df))
+ return ERR_PTR(-EINVAL);
+
+ dev = df->dev.parent;
Why the parent ?
The parent has OPPs and we are calling em_perf_domain_register() or
dev_pm_opp_of_register_em() (which in addition needs DT node) for that
device.
The old devfreq cooling code also had dev parent, to enable/disenable
OPPs.
+
+ if (em_cb) {
+ nr_opp = dev_pm_opp_get_opp_count(dev);
+ if (nr_opp <= 0) {
+ dev_err(dev, "No valid OPPs found\n");
+ return ERR_PTR(-EINVAL);
+ }
+
+ ret = em_dev_register_perf_domain(dev, nr_opp, em_cb, NULL,
false);
+ } else {
+ ret = dev_pm_opp_of_register_em(dev, NULL);
+ }
+
+ if (ret)
+ dev_warn(dev, "Unable to register EM for d
[PATCH v7 7/8] dt-bindings: arm: fsl: add Plymovent BAS board
Add Plymovent Group BV BAS iMX6dl based board Signed-off-by: Oleksij Rempel Acked-by: Rob Herring --- Documentation/devicetree/bindings/arm/fsl.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml index 36c5a0c5ace2..490cbc75b18a 100644 --- a/Documentation/devicetree/bindings/arm/fsl.yaml +++ b/Documentation/devicetree/bindings/arm/fsl.yaml @@ -364,6 +364,7 @@ properties: - fsl,imx6dl-sabresd# i.MX6 DualLite SABRE Smart Device Board - karo,imx6dl-tx6dl # Ka-Ro electronics TX6U Modules - kontron,imx6dl-samx6i # Kontron i.MX6 Solo SMARC Module + - ply,plybas# Plymovent BAS board - ply,plym2m# Plymovent M2M board - poslab,imx6dl-savageboard # Poslab SavageBoard Dual - prt,prtrvt# Protonic RVT board -- 2.29.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH drm/hisilicon v2 2/2] drm/hisilicon: Delete unused local parameters
delete unused variable ‘priv’ to avoid warning.
Signed-off-by: Tian Tao
Reviewed-by: Thomas Zimmermann
---
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
index 7f01213..7e91ef1 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
@@ -250,12 +250,9 @@ static int hibmc_hw_init(struct hibmc_drm_private *priv)
static int hibmc_unload(struct drm_device *dev)
{
- struct hibmc_drm_private *priv = to_hibmc_drm_private(dev);
-
drm_atomic_helper_shutdown(dev);
-
pci_disable_msi(dev->pdev);
- dev->dev_private = NULL;
+
return 0;
}
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: drm_basic_types.h, DRM_FOURCC_STANDALONE
I'd noticed the #if could be combined, but they weren't in drm,h when they
could have been, so I didn't want to depart from the existing pattern.
I think "One of the BSDs" is more informative than "Not Linux" if that
statement is still true. Given the aversion to making drm.h robust to
Windows, I don't think we want to imply compatibility that isn't there.
Thanks,
James
On Mon, Dec 7, 2020 at 1:45 AM Simon Ser wrote:
> On Sunday, December 6th, 2020 at 1:39 AM, James Park <
> jpar...@lagfreegames.com> wrote:
>
> > Create drm_basic_types.h to define types previously defined by drm.h.
> >
> > Use DRM_FOURCC_STANDALONE to include drm_fourcc.h, replacing drm.h
> > dependency with drm_basic_types.h.
>
> This approach looks better to me than the other alternatives.
>
> > This will allow Mesa to port code to Windows more easily.
> >
> > Signed-off-by: James Park
> > ---
> > include/uapi/drm/drm.h | 14 ++
> > include/uapi/drm/drm_basic_types.h | 52
> ++
> > include/uapi/drm/drm_fourcc.h | 4 +++
> > 3 files changed, 58 insertions(+), 12 deletions(-)
> > create mode 100644 include/uapi/drm/drm_basic_types.h
> >
> > diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
> > index 808b48a..a7f38fc 100644
> > --- a/include/uapi/drm/drm.h
> > +++ b/include/uapi/drm/drm.h
> > @@ -36,32 +36,22 @@
> > #ifndef _DRM_H_
> > #define _DRM_H_
> >
> > +#include "drm_basic_types.h"
> > +
> > #if defined(__KERNEL__)
> >
> > -#include
> > #include
> > typedef unsigned int drm_handle_t;
> >
> > #elif defined(__linux__)
> >
> > -#include
> > #include
> > typedef unsigned int drm_handle_t;
> >
> > #else /* One of the BSDs */
> >
> > -#include
> > #include
> > #include
> > -typedef int8_t __s8;
> > -typedef uint8_t __u8;
> > -typedef int16_t __s16;
> > -typedef uint16_t __u16;
> > -typedef int32_t __s32;
> > -typedef uint32_t __u32;
> > -typedef int64_t __s64;
> > -typedef uint64_t __u64;
> > -typedef size_t __kernel_size_t;
> > typedef unsigned long drm_handle_t;
> >
> > #endif
> > diff --git a/include/uapi/drm/drm_basic_types.h
> b/include/uapi/drm/drm_basic_types.h
> > new file mode 100644
> > index 000..b3c00bb
> > --- /dev/null
> > +++ b/include/uapi/drm/drm_basic_types.h
> > @@ -0,0 +1,52 @@
> > +/*
> > + * Copyright 1999 Precision Insight, Inc., Cedar Park, Texas.
> > + * Copyright 2000 VA Linux Systems, Inc., Sunnyvale, California.
> > + * All rights reserved.
> > + *
> > + * Permission is hereby granted, free of charge, to any person
> obtaining a
> > + * copy of this software and associated documentation files (the
> "Software"),
> > + * to deal in the Software without restriction, including without
> limitation
> > + * the rights to use, copy, modify, merge, publish, distribute,
> sublicense,
> > + * and/or sell copies of the Software, and to permit persons to whom the
> > + * Software is furnished to do so, subject to the following conditions:
> > + *
> > + * The above copyright notice and this permission notice (including the
> next
> > + * paragraph) shall be included in all copies or substantial portions
> of the
> > + * Software.
> > + *
> > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> EXPRESS OR
> > + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
> MERCHANTABILITY,
> > + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT
> SHALL
> > + * VA LINUX SYSTEMS AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM,
> DAMAGES OR
> > + * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
> > + * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> > + * OTHER DEALINGS IN THE SOFTWARE.
> > + */
> > +
> > +#ifndef _DRM_BASIC_TYPES_H_
> > +#define _DRM_BASIC_TYPES_H_
> > +
> > +#if defined(__KERNEL__)
> > +
> > +#include
> > +
> > +#elif defined(__linux__)
>
> Nit: these two #ifs can be combined together.
>
> > +#include
> > +
> > +#else /* One of the BSDs */
>
> Maybe replace with /* Not Linux */?
>
> > +#include
> > +typedef int8_t __s8;
> > +typedef uint8_t __u8;
> > +typedef int16_t __s16;
> > +typedef uint16_t __u16;
> > +typedef int32_t __s32;
> > +typedef uint32_t __u32;
> > +typedef int64_t __s64;
> > +typedef uint64_t __u64;
> > +typedef size_t __kernel_size_t;
> > +
> > +#endif
> > +
> > +#endif
> > diff --git a/include/uapi/drm/drm_fourcc.h
> b/include/uapi/drm/drm_fourcc.h
> > index 82f3278..5eb07a5 100644
> > --- a/include/uapi/drm/drm_fourcc.h
> > +++ b/include/uapi/drm/drm_fourcc.h
> > @@ -24,7 +24,11 @@
> > #ifndef DRM_FOURCC_H
> > #define DRM_FOURCC_H
> >
> > +#ifdef DRM_FOURCC_STANDALONE
> > +#include "drm_basic_types.h"
> > +#else
> > #include "drm.h"
> > +#endif
> >
> > #if defined(__cplusplus)
> > extern "C" {
> > --
> > 2.7.4
> >
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
[PATCH] drm/tidss: Use the new api devm_drm_irq_install
Use devm_drm_irq_install to register interrupts so that
drm_irq_uninstall is not needed to be called.
Signed-off-by: Tian Tao
---
drivers/gpu/drm/tidss/tidss_drv.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/tidss/tidss_drv.c
b/drivers/gpu/drm/tidss/tidss_drv.c
index 66e3c86e..48e1f9d 100644
--- a/drivers/gpu/drm/tidss/tidss_drv.c
+++ b/drivers/gpu/drm/tidss/tidss_drv.c
@@ -173,7 +173,7 @@ static int tidss_probe(struct platform_device *pdev)
goto err_runtime_suspend;
}
- ret = drm_irq_install(ddev, irq);
+ ret = devm_irq_install(ddev, irq);
if (ret) {
dev_err(dev, "drm_irq_install failed: %d\n", ret);
goto err_runtime_suspend;
@@ -219,8 +219,6 @@ static int tidss_remove(struct platform_device *pdev)
drm_atomic_helper_shutdown(ddev);
- drm_irq_uninstall(ddev);
-
#ifndef CONFIG_PM
/* If we don't have PM, we need to call suspend manually */
dispc_runtime_suspend(tidss->dispc);
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Fix drm.h uapi header for Windows
Not to make too big a deal of it, but the idea was that if you went out of your way to define DRM_FOURCC_STANDALONE in your code base, that you would also go through the pain of removing drm.h includes elsewhere. It's too annoying of an implication to document/communicate, so I'm happier with the other DRM_FOURCC_STANDALONE solution that pulls the basic types into a common header. Thanks, James On Mon, Dec 7, 2020 at 1:49 AM Simon Ser wrote: > On Monday, December 7th, 2020 at 9:57 AM, James Park < > james.p...@lagfreegames.com> wrote: > > > I could adjust the block to look like this: > > > > #ifdef DRM_FOURCC_STANDALONE > > #if defined(__linux__) > > #include > > #else > > #include > > typedef uint32_t __u32; > > typedef uint64_t __u64; > > #endif > > #else > > #include "drm.h" > > #endif > > This approach still breaks on BSDs when DRM_FOURCC_STANDALONE is defined > and > drm.h is included afterwards. > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 3/8] dt-bindings: display: simple: Add Kyocera tcg070wvlq panel
So far, this panel seems to be compatible with "lg,lb070wv8", on other hand it is better to set this compatible in the devicetree. So, let's add it for now only to the dt-binding documentation to fix the checkpatch warnings. Signed-off-by: Oleksij Rempel --- .../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml index 46e5b2a5a011..206ff74db53e 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml @@ -172,6 +172,8 @@ properties: - koe,tx26d202vm0bwa # Kaohsiung Opto-Electronics. TX31D200VM0BAA 12.3" HSXGA LVDS panel - koe,tx31d200vm0baa +# Kyocera Corporation 7" WVGA (800x480) transmissive color TFT + - kyo,tcg070wvlq # Kyocera Corporation 12.1" XGA (1024x768) TFT LCD panel - kyo,tcg121xglp # LeMaker BL035-RGB-002 3.5" QVGA TFT LCD panel -- 2.29.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v11 09/10] PM / devfreq: tegra30: Support interconnect and OPPs from device-tree
07.12.2020 04:32, Chanwoo Choi пишет: > On 12/4/20 4:24 AM, Dmitry Osipenko wrote: >> This patch moves ACTMON driver away from generating OPP table by itself, >> transitioning it to use the table which comes from device-tree. This >> change breaks compatibility with older device-trees and brings support >> for the interconnect framework to the driver. This is a mandatory change >> which needs to be done in order to implement interconnect-based memory >> DVFS, i.e. device-trees need to be updated. Now ACTMON issues a memory >> bandwidth requests using dev_pm_opp_set_bw() instead of driving EMC clock >> rate directly. >> >> Tested-by: Peter Geis >> Tested-by: Nicolas Chauvet >> Acked-by: Chanwoo Choi >> Signed-off-by: Dmitry Osipenko >> --- ... > > Applied it. Thanks for your work for a long time. > Thank you! ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: drm_basic_types.h, DRM_FOURCC_STANDALONE
The original code blocks in drm.h look identical to me. I see: #include #include typedef unsigned int drm_handle_t; Good point about drm_basic_types.h. I'll change it to say "Not Linux" after waiting a bit for more feedback. Thanks, James On Mon, Dec 7, 2020 at 1:59 AM Simon Ser wrote: > On Monday, December 7th, 2020 at 10:55 AM, James Park < > james.p...@lagfreegames.com> wrote: > > > I'd noticed the #if could be combined, but they weren't in drm,h when > > they could have been, so I didn't want to depart from the existing > > pattern. > > I see. The original code really needed the two branches and > drm_basic_types.h doesn't. But let's see what others think. > > > I think "One of the BSDs" is more informative than "Not Linux" if > > that statement is still true. Given the aversion to making drm.h > > robust to Windows, I don't think we want to imply compatibility that > > isn't there. > > Well, drm_basic_types.h would be included on Windows as well from > drm_fourcc.h, right? > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7 2/3] drm: Add support for the LogiCVC display controller
On Wed, Dec 02, 2020 at 05:06:40PM +0100, Paul Kocialkowski wrote:
> > > +static void logicvc_crtc_atomic_begin(struct drm_crtc *drm_crtc,
> > > + struct drm_atomic_state *state)
> > > +{
> > > + struct logicvc_crtc *crtc = logicvc_crtc(drm_crtc);
> > > + struct drm_crtc_state *crtc_state =
> > > + drm_atomic_get_old_crtc_state(state, drm_crtc);
> > > + struct drm_device *drm_dev = drm_crtc->dev;
> > > + unsigned long flags;
> > > +
> > > + /* Register pending event, only if vblank is already on. */
> > > + if (drm_crtc->state->event && crtc_state->active) {
> > > + spin_lock_irqsave(&drm_dev->event_lock, flags);
> > > + WARN_ON(drm_crtc_vblank_get(drm_crtc) != 0);
> > > +
> > > + crtc->event = drm_crtc->state->event;
> > > + drm_crtc->state->event = NULL;
> > > +
> > > + spin_unlock_irqrestore(&drm_dev->event_lock, flags);
> > > + }
> > > +}
> >
> > That's unusual to do it in atomic_begin, why do you need it?
>
> This is to cover the case where we need to send a page flip event but the
> crtc is already on. In that case, neither atomic_enable nor atomic_disable
> will be called so we need to rely on atomic_begin to grab that event.
> This happens for example when a single plane is updated.
>
> The same thing is done in e.g. sun4i-drm.
Yeah, but I'm not sure why that's needed in the first place on sun4i-drm
either. This looks to me as either something that should be handled by
the helpers, or isn't needed at all. Just like the other times you
fiddle with the vblank in your driver.
I looked around and the only drivers that have that logic seem to be ARM
HDLCD, Atmel HCLDC, Meson, Tegra. This looks like it might be some cargo
cult.
Daniel, do you know why that would be needed?
> > > +static void logicvc_version_print(struct logicvc_drm *logicvc)
> > > +{
> > > + u32 version;
> > > +
> > > + regmap_read(logicvc->regmap, LOGICVC_IP_VERSION_REG, &version);
> > > +
> > > + DRM_INFO("LogiCVC version %d.%02d.%c\n",
> > > + (int)LOGICVC_FIELD_GET(LOGICVC_IP_VERSION_MAJOR, version),
> > > + (int)LOGICVC_FIELD_GET(LOGICVC_IP_VERSION_MINOR, version),
> > > + (char)LOGICVC_FIELD_GET(LOGICVC_IP_VERSION_LEVEL, version) +
> > > + 'a');
> >
> > DRM_DEV_INFO?
>
> Okay but now according to Sam, "DRM_DEV_ERROR() and friends are deprecated"
> so I wonder which is the right one to use at this point.
AFAIU, it's drm_info / drm_err
> > > +static void logicvc_encoder_enable(struct drm_encoder *drm_encoder)
> > > +{
> > > + struct logicvc_drm *logicvc = logicvc_drm(drm_encoder->dev);
> > > + struct logicvc_interface *interface =
> > > + logicvc_interface_from_drm_encoder(drm_encoder);
> > > +
> > > + regmap_update_bits(logicvc->regmap, LOGICVC_POWER_CTRL_REG,
> > > +LOGICVC_POWER_CTRL_VIDEO_ENABLE,
> > > +LOGICVC_POWER_CTRL_VIDEO_ENABLE);
> > > +
> > > + if (interface->drm_panel) {
> > > + drm_panel_prepare(interface->drm_panel);
> > > +
> > > + /* Encoder enable is too early to enable the panel and a white
> > > + * screen will be seen if the panel gets enabled before the
> > > + * first page flip is done (and no other framebuffer
> > > + * configuration remains from the boot software). */
> > > + interface->drm_panel_enabled = false;
> > > + }
> > > +}
> >
> > That's fishy (and the similar stuff in commit_tail). Is it because you
> > need to have the CRTC powered before the encoder?
> >
> > If so, you should try the commit_tail_rpm variant, it makes sure the
> > CRTC is powered on before making a commit.
>
> No, this is unrelated to CRTC vs encoder enable order. Instead, it's about
> panel enable order: I don't want to enable the panel before a buffer was
> flipped on the CRTC otherwise a blank/white/garbage screen will be shown.
Well, since the encoder will enable the panel, it's kind of related
though?
> This is why this drm_panel_enabled variable is used to make sure we don't
> enable the panel before.
>
> This is nothing specific to my hardware, but a general concern that probably
> exists in every DRM driver. Nobody really seems to care about it but I've
> decided that I would in this driver. Now if you think this is too exotic,
> I don't mind removing it.
If this is a concern of yours and affects multiple drivers, then it
should be fixed in the core, not in one particular driver.
> > > +static void logicvc_connector_destroy(struct drm_connector
> > > *drm_connector)
> > > +{
> > > + drm_connector_cleanup(drm_connector);
> > > +}
> >
> > I guess you don't need that intermediate function?
>
> I would need to check if that call is necessary or if some implied mechanism
> calls it for me already.
What I meant is that you don't need logicvc_connector_destroy, you can
directly set the atomic_destroy_state to drm_connector_cleanup.
Maximey
signature.asc
Description: PGP signature
Re: [PATCH v6 2/8] dt-bindings: display: simple: add EDT compatibles already supported by the driver
On Sat, Dec 05, 2020 at 08:35:38PM +0100, Sam Ravnborg wrote: > Hi Oleksij, > > On Wed, Dec 02, 2020 at 09:18:20AM +0100, Oleksij Rempel wrote: > > Some EDT compatibles are already supported by the driver but will fail > > on checkpatch script. Fix it by syncing dt-bindings documentation with the > > driver. > > > > Signed-off-by: Oleksij Rempel > > --- > > .../devicetree/bindings/display/panel/panel-simple.yaml| 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git > > a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml > > b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml > > index 428b03342fea..0bb3e67fb58c 100644 > > --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml > > +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml > > @@ -108,10 +108,12 @@ properties: > > # Emerging Display Technology Corp. 480x272 TFT Display with > > capacitive touch > >- edt,et057090dhu > > # Emerging Display Technology Corp. WVGA TFT Display with > > capacitive touch > > + - edt,et070080dh6 > >- edt,etm043080dh6gp > > # Emerging Display Technology Corp. 480x272 TFT Display > >- edt,etm0430g0dh6 > > # Emerging Display Technology Corp. 5.7" VGA TFT LCD panel > > + - edt,etm0700g0bdh6 > >- edt,etm070080bdh6 > The order is wrong here. edt,etm070080bdh6 comes before edt,etm0700g0bdh6. > I checked with "sort" in my editor just to make sure. I would really like to remove this useless comments. It make sorting so mach easier. > > # Emerging Display Technology Corp. WVGA TFT Display with > > capacitive touch > > # Same display as the ETM0700G0BDH6, but with changed hardware for > > the > > @@ -124,6 +126,7 @@ properties: > >- edt,etm0700g0dh6 > > # Emerging Display Technology Corp. WVGA TFT Display with > > capacitive touch > > # Same as ETM0700G0DH6 but with inverted pixel clock. > > + - edt,etm0700g0edh6 > >- evervision,vgg804821 > > # Foxlink Group 5" WVGA TFT LCD panel > >- foxlink,fl500wvr00-a0t > > Sam > -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 5/8] dt-bindings: arm: fsl: add Plymovent M2M board
Add Plymovent Group BV M2M iMX6dl based board Signed-off-by: Oleksij Rempel Acked-by: Rob Herring --- Documentation/devicetree/bindings/arm/fsl.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml index 4772f64c4463..36c5a0c5ace2 100644 --- a/Documentation/devicetree/bindings/arm/fsl.yaml +++ b/Documentation/devicetree/bindings/arm/fsl.yaml @@ -364,6 +364,7 @@ properties: - fsl,imx6dl-sabresd# i.MX6 DualLite SABRE Smart Device Board - karo,imx6dl-tx6dl # Ka-Ro electronics TX6U Modules - kontron,imx6dl-samx6i # Kontron i.MX6 Solo SMARC Module + - ply,plym2m# Plymovent M2M board - poslab,imx6dl-savageboard # Poslab SavageBoard Dual - prt,prtrvt# Protonic RVT board - prt,prtvt7# Protonic VT7 board -- 2.29.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/5] thermal: devfreq_cooling: get a copy of device status
On 12/3/20 4:09 PM, Daniel Lezcano wrote:
On 03/12/2020 16:38, Lukasz Luba wrote:
On 12/3/20 1:09 PM, Daniel Lezcano wrote:
On 18/11/2020 13:03, Lukasz Luba wrote:
Devfreq cooling needs to now the correct status of the device in order
to operate. Do not rely on Devfreq last_status which might be a stale
data
and get more up-to-date values of the load.
Devfreq framework can change the device status in the background. To
mitigate this situation make a copy of the status structure and use it
for internal calculations.
In addition this patch adds normalization function, which also makes
sure
that whatever data comes from the device, it is in a sane range.
Signed-off-by: Lukasz Luba
---
drivers/thermal/devfreq_cooling.c | 52 +--
1 file changed, 43 insertions(+), 9 deletions(-)
diff --git a/drivers/thermal/devfreq_cooling.c
b/drivers/thermal/devfreq_cooling.c
index 659c0143c9f0..925523694462 100644
--- a/drivers/thermal/devfreq_cooling.c
+++ b/drivers/thermal/devfreq_cooling.c
@@ -227,20 +227,46 @@ static inline unsigned long
get_total_power(struct devfreq_cooling_device *dfc,
voltage);
}
+static void _normalize_load(struct devfreq_dev_status *status)
+{
+ /* Make some space if needed */
+ if (status->busy_time > 0x) {
+ status->busy_time >>= 10;
+ status->total_time >>= 10;
+ }
+
+ if (status->busy_time > status->total_time)
+ status->busy_time = status->total_time;
How the condition above is possible?
They should, be checked by the driver, but I cannot trust
and have to check for all corner cases: (div by 0, overflow
one of them, etc). The busy_time and total_time are unsigned long,
which means 4B on 32bit machines.
If these values are coming from device counters, which count every
busy cycle and total cycles of a clock of a device running at e.g.
1GHz they would overflow every ~4s.
I don't think it is up to this routine to check the driver is correctly
implemented, especially at every call to get_requested_power.
If the normalization ends up by doing this kind of thing, there is
certainly something wrong in the 'status' computation to be fixed before
submitting this series.
Normally IPA polling are 1s and 100ms, it's platform specific. But there
are also 'empty' periods when IPA sees temperature very low and does not
even call the .get_requested_power() callbacks for the cooling devices,
just grants max freq to all. This is problematic. I am investigating it
and will propose a solution for IPA soon.
I would avoid all of this if devfreq core would have default for all
devices a reliable polling timer... Let me check some possibilities also
for this case.
Ok, may be create an API to compute the 'idle,busy,total times' to be
used by the different the devfreq drivers and then fix the overflow in
this common place.
Yes, I have this plan, but I have to close this patch series. To go
forward with this, I will drop the normalization function and will keep
only the code of safe copy of the 'status', so using busy_time and
total_time will be safe.
I will address this computation and normalization in different patch
series. There might be a need of a new API as you pointed out, which
is out-of-scope of this patch set.
+ status->busy_time *= 100;
+ status->busy_time /= status->total_time ? : 1;
+
+ /* Avoid division by 0 */
+ status->busy_time = status->busy_time ? : 1;
+ status->total_time = 100;
Why not base the normalization on 1024? and use an intermediate u64.
You are the 2nd reviewer who is asking this. I tried to keep 'load' as
in range [0, 100] since we also have 'load' in cpufreq cooling in this
range. Maybe I should switch to 1024 (Ionela was also asking for this).
Well it is common practice to compute normalization with 1024 because
the division is a bit shift and the compiler optimize the code very well
with that value.
I will keep this 1024 in mind for the next topic series.
Regards,
Lukasz
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 3/8] dt-bindings: display: simple: Add Kyocera tcg070wvlq panel
On Sat, Dec 05, 2020 at 08:36:39PM +0100, Sam Ravnborg wrote: > On Wed, Dec 02, 2020 at 09:18:21AM +0100, Oleksij Rempel wrote: > > So far, this panel seems to be compatible with "lg,lb070wv8", on other > > hand it is better to set this compatible in the devicetree. So, let's > > add it for now only to the dt-binding documentation to fix the > > checkpatch warnings. > > > > Signed-off-by: Oleksij Rempel > > --- > > .../devicetree/bindings/display/panel/panel-simple.yaml | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git > > a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml > > b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml > > index 0bb3e67fb58c..8f7a0e409eee 100644 > > --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml > > +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml > > @@ -172,6 +172,7 @@ properties: > >- koe,tx26d202vm0bwa > > # Kaohsiung Opto-Electronics. TX31D200VM0BAA 12.3" HSXGA LVDS panel > >- koe,tx31d200vm0baa > > + - kyo,tcg070wvlq > Can you provine a comment here about what panel it is? By searching for this part I can't find any unified name. Each re-seller seems to use something own, and inventing one seems to make no real sense as well. Regards, Oleksij -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 4/8] drm/vc4: hdmi: Create a custom connector state
When run with a higher bpc than 8, the clock of the HDMI controller needs
to be adjusted. Let's create a connector state that will be used at
atomic_check and atomic_enable to compute and store the clock rate
associated to the state.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 27 +--
drivers/gpu/drm/vc4/vc4_hdmi.h | 10 ++
2 files changed, 35 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index 112c09873eb4..862c93708e9a 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -170,18 +170,41 @@ static int vc4_hdmi_connector_get_modes(struct
drm_connector *connector)
static void vc4_hdmi_connector_reset(struct drm_connector *connector)
{
- drm_atomic_helper_connector_reset(connector);
+ struct vc4_hdmi_connector_state *conn_state =
kzalloc(sizeof(*conn_state), GFP_KERNEL);
+
+ if (connector->state)
+ __drm_atomic_helper_connector_destroy_state(connector->state);
+
+ kfree(connector->state);
+
+ __drm_atomic_helper_connector_reset(connector, &conn_state->base);
if (connector->state)
drm_atomic_helper_connector_tv_reset(connector);
}
+static struct drm_connector_state *
+vc4_hdmi_connector_duplicate_state(struct drm_connector *connector)
+{
+ struct drm_connector_state *conn_state = connector->state;
+ struct vc4_hdmi_connector_state *vc4_state =
conn_state_to_vc4_hdmi_conn_state(conn_state);
+ struct vc4_hdmi_connector_state *new_state;
+
+ new_state = kzalloc(sizeof(*new_state), GFP_KERNEL);
+ if (!new_state)
+ return NULL;
+
+ __drm_atomic_helper_connector_duplicate_state(connector,
&new_state->base);
+
+ return &new_state->base;
+}
+
static const struct drm_connector_funcs vc4_hdmi_connector_funcs = {
.detect = vc4_hdmi_connector_detect,
.fill_modes = drm_helper_probe_single_connector_modes,
.destroy = vc4_hdmi_connector_destroy,
.reset = vc4_hdmi_connector_reset,
- .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
+ .atomic_duplicate_state = vc4_hdmi_connector_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
};
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.h b/drivers/gpu/drm/vc4/vc4_hdmi.h
index 0526a9cf608a..2cf5362052e2 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.h
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.h
@@ -180,6 +180,16 @@ encoder_to_vc4_hdmi(struct drm_encoder *encoder)
return container_of(_encoder, struct vc4_hdmi, encoder);
}
+struct vc4_hdmi_connector_state {
+ struct drm_connector_state base;
+};
+
+static inline struct vc4_hdmi_connector_state *
+conn_state_to_vc4_hdmi_conn_state(struct drm_connector_state *conn_state)
+{
+ return container_of(conn_state, struct vc4_hdmi_connector_state, base);
+}
+
void vc4_hdmi_phy_init(struct vc4_hdmi *vc4_hdmi,
struct drm_display_mode *mode);
void vc4_hdmi_phy_disable(struct vc4_hdmi *vc4_hdmi);
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH drm/hisilicon v2 0/2] Code refactoring
patch #1 is used drmm_mode_config_init() to do code refactoring. patch #2 is deleted unused variable ‘priv’ to avoid warning. Changes since v1: Remove the unused structure member variable mode_config_initialized. Tian Tao (2): drm/hisilicon: Use managed mode-config init drm/hisilicon: Delete unused local parameters drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 19 --- drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h | 1 - 2 files changed, 4 insertions(+), 16 deletions(-) -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 6/8] drm/vc4: hdmi: Use the connector state pixel rate for the PHY
The PHY initialisation parameters are not based on the pixel clock but
the TMDS clock rate which can be the pixel clock in the standard case,
but could be adjusted based on some parameters like the bits per color.
Since the TMDS clock rate is stored in our custom connector state
already, let's reuse it from there instead of computing it again.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 2 +-
drivers/gpu/drm/vc4/vc4_hdmi.h | 9 -
drivers/gpu/drm/vc4/vc4_hdmi_phy.c | 8 +---
3 files changed, 10 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index c1667cfe37db..795fd23c8f58 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -714,7 +714,7 @@ static void vc4_hdmi_encoder_pre_crtc_configure(struct
drm_encoder *encoder,
vc4_hdmi->variant->reset(vc4_hdmi);
if (vc4_hdmi->variant->phy_init)
- vc4_hdmi->variant->phy_init(vc4_hdmi, mode);
+ vc4_hdmi->variant->phy_init(vc4_hdmi, vc4_conn_state);
HDMI_WRITE(HDMI_SCHEDULER_CONTROL,
HDMI_READ(HDMI_SCHEDULER_CONTROL) |
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.h b/drivers/gpu/drm/vc4/vc4_hdmi.h
index bca6943de884..6cc5b6652cca 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.h
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.h
@@ -21,10 +21,9 @@ to_vc4_hdmi_encoder(struct drm_encoder *encoder)
return container_of(encoder, struct vc4_hdmi_encoder, base.base);
}
-struct drm_display_mode;
-
struct vc4_hdmi;
struct vc4_hdmi_register;
+struct vc4_hdmi_connector_state;
enum vc4_hdmi_phy_channel {
PHY_LANE_0 = 0,
@@ -82,7 +81,7 @@ struct vc4_hdmi_variant {
/* Callback to initialize the PHY according to the mode */
void (*phy_init)(struct vc4_hdmi *vc4_hdmi,
-struct drm_display_mode *mode);
+struct vc4_hdmi_connector_state *vc4_conn_state);
/* Callback to disable the PHY */
void (*phy_disable)(struct vc4_hdmi *vc4_hdmi);
@@ -192,13 +191,13 @@ conn_state_to_vc4_hdmi_conn_state(struct
drm_connector_state *conn_state)
}
void vc4_hdmi_phy_init(struct vc4_hdmi *vc4_hdmi,
- struct drm_display_mode *mode);
+ struct vc4_hdmi_connector_state *vc4_conn_state);
void vc4_hdmi_phy_disable(struct vc4_hdmi *vc4_hdmi);
void vc4_hdmi_phy_rng_enable(struct vc4_hdmi *vc4_hdmi);
void vc4_hdmi_phy_rng_disable(struct vc4_hdmi *vc4_hdmi);
void vc5_hdmi_phy_init(struct vc4_hdmi *vc4_hdmi,
- struct drm_display_mode *mode);
+ struct vc4_hdmi_connector_state *vc4_conn_state);
void vc5_hdmi_phy_disable(struct vc4_hdmi *vc4_hdmi);
void vc5_hdmi_phy_rng_enable(struct vc4_hdmi *vc4_hdmi);
void vc5_hdmi_phy_rng_disable(struct vc4_hdmi *vc4_hdmi);
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi_phy.c
b/drivers/gpu/drm/vc4/vc4_hdmi_phy.c
index 057796b54c51..36535480f8e2 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi_phy.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi_phy.c
@@ -127,7 +127,8 @@
#define OSCILLATOR_FREQUENCY 5400
-void vc4_hdmi_phy_init(struct vc4_hdmi *vc4_hdmi, struct drm_display_mode
*mode)
+void vc4_hdmi_phy_init(struct vc4_hdmi *vc4_hdmi,
+ struct vc4_hdmi_connector_state *conn_state)
{
/* PHY should be in reset, like
* vc4_hdmi_encoder_disable() does.
@@ -339,11 +340,12 @@ static void vc5_hdmi_reset_phy(struct vc4_hdmi *vc4_hdmi)
HDMI_WRITE(HDMI_TX_PHY_POWERDOWN_CTL, BIT(10));
}
-void vc5_hdmi_phy_init(struct vc4_hdmi *vc4_hdmi, struct drm_display_mode
*mode)
+void vc5_hdmi_phy_init(struct vc4_hdmi *vc4_hdmi,
+ struct vc4_hdmi_connector_state *conn_state)
{
const struct phy_lane_settings *chan0_settings, *chan1_settings,
*chan2_settings, *clock_settings;
const struct vc4_hdmi_variant *variant = vc4_hdmi->variant;
- unsigned long long pixel_freq = mode->clock * 1000;
+ unsigned long long pixel_freq = conn_state->pixel_rate;
unsigned long long vco_freq;
unsigned char word_sel;
u8 vco_sel, vco_div;
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 4/8] dt-bindings: vendor-prefixes: Add an entry for Plymovent
Add "ply" entry for Plymovent Group BV: https://www.plymovent.com/ Signed-off-by: Oleksij Rempel Acked-by: Rob Herring --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 6a9be2bbbcb6..8332d50301ea 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -840,6 +840,8 @@ patternProperties: description: PLDA "^plx,.*": description: Broadcom Corporation (formerly PLX Technology) + "^ply,.*": +description: Plymovent Group BV "^pni,.*": description: PNI Sensor Corporation "^pocketbook,.*": -- 2.29.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 6/8] ARM: dts: add Plymovent M2M board
Plymovent M2M is a control interface produced for the Plymovent filter
systems.
Co-Developed-by: David Jander
Signed-off-by: David Jander
Signed-off-by: Oleksij Rempel
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/imx6dl-plym2m.dts | 446
2 files changed, 447 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6dl-plym2m.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 3ab9d58428cf..31249fc5f85c 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -461,6 +461,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
imx6dl-pico-hobbit.dtb \
imx6dl-pico-nymph.dtb \
imx6dl-pico-pi.dtb \
+ imx6dl-plym2m.dtb \
imx6dl-prtrvt.dtb \
imx6dl-prtvt7.dtb \
imx6dl-rex-basic.dtb \
diff --git a/arch/arm/boot/dts/imx6dl-plym2m.dts
b/arch/arm/boot/dts/imx6dl-plym2m.dts
new file mode 100644
index ..4d0d3d3386af
--- /dev/null
+++ b/arch/arm/boot/dts/imx6dl-plym2m.dts
@@ -0,0 +1,446 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/*
+ * Copyright (c) 2014 Protonic Holland
+ * Copyright (c) 2020 Oleksij Rempel , Pengutronix
+ */
+
+/dts-v1/;
+#include
+#include
+#include "imx6dl.dtsi"
+
+/ {
+ model = "Plymovent M2M board";
+ compatible = "ply,plym2m", "fsl,imx6dl";
+
+ chosen {
+ stdout-path = &uart4;
+ };
+
+ backlight: backlight {
+ compatible = "pwm-backlight";
+ pwms = <&pwm1 0 500 0>;
+ brightness-levels = <0 1000>;
+ num-interpolated-steps = <20>;
+ default-brightness-level = <19>;
+ power-supply = <®_12v0>;
+ };
+
+ display {
+ compatible = "fsl,imx-parallel-display";
+ pinctrl-0 = <&pinctrl_ipu1_disp>;
+ pinctrl-names = "default";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ display_in: endpoint {
+ remote-endpoint = <&ipu1_di0_disp0>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ display_out: endpoint {
+ remote-endpoint = <&panel_in>;
+ };
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_leds>;
+
+ led-0 {
+ label = "debug0";
+ function = LED_FUNCTION_STATUS;
+ gpios = <&gpio1 8 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "heartbeat";
+ };
+ };
+
+ panel {
+ compatible = "edt,etm0700g0bdh6";
+ backlight = <&backlight>;
+ power-supply = <®_3v3>;
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <&display_out>;
+ };
+ };
+ };
+
+ clk50m_phy: phy-clock {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <5000>;
+ };
+
+ reg_3v3: regulator-3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "3v3";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ };
+
+ reg_5v0: regulator-5v0 {
+ compatible = "regulator-fixed";
+ regulator-name = "5v0";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ };
+
+ reg_12v0: regulator-12v0 {
+ compatible = "regulator-fixed";
+ regulator-name = "12v0";
+ regulator-min-microvolt = <1200>;
+ regulator-max-microvolt = <1200>;
+ };
+};
+
+&can1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_can1>;
+ xceiver-supply = <®_5v0>;
+ status = "okay";
+};
+
+&ecspi1 {
+ cs-gpios = <&gpio3 19 GPIO_ACTIVE_LOW>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ecspi1>;
+ status = "okay";
+
+ flash@0 {
+ compatible = "jedec,spi-nor";
+ reg = <0>;
+ spi-max-frequency = <2000>;
+ };
+};
+
+&ecspi2 {
+ cs-gpios = <&gpio2 26 GPIO_ACTIVE_LOW>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ecspi2>;
+ status = "okay";
+
+ touchscreen@0 {
+ compatible = "ti,tsc2046";
+ reg = <0>;
+ pinctrl-0 = <&pinctrl_tsc2046>;
+ pinctrl-names ="default";
+ spi-max-frequency = <10>;
+ interrupts-extended = <&gpio3 20 I
Re: [PATCH] drm: Fix drm.h uapi header for Windows
Oh, I thought you meant:
#include "drm_basic_types.h"
#include "drm_fourcc.h"
Yours should work too. I don't have a preference vs. what I already have,
so if no one says anything, I can switch over to yours.
Thanks,
James
On Mon, Dec 7, 2020 at 2:53 AM Simon Ser wrote:
> On Monday, December 7th, 2020 at 11:49 AM, James Park <
> james.p...@lagfreegames.com> wrote:
>
> > That would work, but that's kind of an annoying requirement. I would
> > prefer the header to be self-sufficient.
>
> I don't want to make it more confusing than before, but here Pekka (I
> think) suggests to replace this:
>
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index 82f3278..5eb07a5 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -24,7 +24,11 @@
> #ifndef DRM_FOURCC_H
> #define DRM_FOURCC_H
>
> +#ifdef DRM_FOURCC_STANDALONE
> +#include "drm_basic_types.h"
> +#else
> #include "drm.h"
> +#endif
>
> #if defined(__cplusplus)
> extern "C" {
>
> With this:
>
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index 82f3278..5eb07a5 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -24,7 +24,11 @@
> #ifndef DRM_FOURCC_H
> #define DRM_FOURCC_H
>
> +#include "drm_basic_types.h"
> +
> +#ifndef DRM_FOURCC_STANDALONE
> #include "drm.h"
> +#endif
>
> #if defined(__cplusplus)
> extern "C" {
>
> That wouldn't change whether the header is self-sufficient or not,
> would it?
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH drm/hisilicon v2 1/2] drm/hisilicon: Use managed mode-config init
Using drmm_mode_config_init() sets up managed release of modesetting
resources.
v2:
Remove the unused structure member variable mode_config_initialized.
Signed-off-by: Tian Tao
Reviewed-by: Thomas Zimmermann
---
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 14 +++---
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h | 1 -
2 files changed, 3 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
index 3687753..7f01213 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
@@ -96,8 +96,9 @@ static int hibmc_kms_init(struct hibmc_drm_private *priv)
struct drm_device *dev = &priv->dev;
int ret;
- drm_mode_config_init(dev);
- priv->mode_config_initialized = true;
+ ret = drmm_mode_config_init(dev);
+ if (ret)
+ return ret;
dev->mode_config.min_width = 0;
dev->mode_config.min_height = 0;
@@ -125,14 +126,6 @@ static int hibmc_kms_init(struct hibmc_drm_private *priv)
return 0;
}
-static void hibmc_kms_fini(struct hibmc_drm_private *priv)
-{
- if (priv->mode_config_initialized) {
- drm_mode_config_cleanup(&priv->dev);
- priv->mode_config_initialized = false;
- }
-}
-
/*
* It can operate in one of three modes: 0, 1 or Sleep.
*/
@@ -262,7 +255,6 @@ static int hibmc_unload(struct drm_device *dev)
drm_atomic_helper_shutdown(dev);
pci_disable_msi(dev->pdev);
- hibmc_kms_fini(priv);
dev->dev_private = NULL;
return 0;
}
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
index a49c10e..7d263f4 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
@@ -42,7 +42,6 @@ struct hibmc_drm_private {
struct drm_crtc crtc;
struct drm_encoder encoder;
struct hibmc_connector connector;
- bool mode_config_initialized;
};
static inline struct hibmc_connector *to_hibmc_connector(struct drm_connector
*connector)
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 5/8] drm/vc4: hdmi: Store pixel frequency in the connector state
The pixel rate is for now quite simple to compute, but with more features
(30 and 36 bits output, YUV output, etc.) will depend on a bunch of
connectors properties.
Let's store the rate we have to run the pixel clock at in our custom
connector state, and compute it in atomic_check.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 26 +-
drivers/gpu/drm/vc4/vc4_hdmi.h | 1 +
2 files changed, 26 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index 862c93708e9a..c1667cfe37db 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -194,6 +194,7 @@ vc4_hdmi_connector_duplicate_state(struct drm_connector
*connector)
if (!new_state)
return NULL;
+ new_state->pixel_rate = vc4_state->pixel_rate;
__drm_atomic_helper_connector_duplicate_state(connector,
&new_state->base);
return &new_state->base;
@@ -611,9 +612,29 @@ static void vc4_hdmi_recenter_fifo(struct vc4_hdmi
*vc4_hdmi)
"VC4_HDMI_FIFO_CTL_RECENTER_DONE");
}
+static struct drm_connector_state *
+vc4_hdmi_encoder_get_connector_state(struct drm_encoder *encoder,
+struct drm_atomic_state *state)
+{
+ struct drm_connector_state *conn_state;
+ struct drm_connector *connector;
+ unsigned int i;
+
+ for_each_new_connector_in_state(state, connector, conn_state, i) {
+ if (conn_state->best_encoder == encoder)
+ return conn_state;
+ }
+
+ return NULL;
+}
+
static void vc4_hdmi_encoder_pre_crtc_configure(struct drm_encoder *encoder,
struct drm_atomic_state *state)
{
+ struct drm_connector_state *conn_state =
+ vc4_hdmi_encoder_get_connector_state(encoder, state);
+ struct vc4_hdmi_connector_state *vc4_conn_state =
+ conn_state_to_vc4_hdmi_conn_state(conn_state);
struct drm_display_mode *mode = &encoder->crtc->state->adjusted_mode;
struct vc4_hdmi *vc4_hdmi = encoder_to_vc4_hdmi(encoder);
unsigned long pixel_rate, hsm_rate;
@@ -625,7 +646,7 @@ static void vc4_hdmi_encoder_pre_crtc_configure(struct
drm_encoder *encoder,
return;
}
- pixel_rate = mode->clock * 1000 * ((mode->flags & DRM_MODE_FLAG_DBLCLK)
? 2 : 1);
+ pixel_rate = vc4_conn_state->pixel_rate;
ret = clk_set_rate(vc4_hdmi->pixel_clock, pixel_rate);
if (ret) {
DRM_ERROR("Failed to set pixel clock rate: %d\n", ret);
@@ -797,6 +818,7 @@ static int vc4_hdmi_encoder_atomic_check(struct drm_encoder
*encoder,
struct drm_crtc_state *crtc_state,
struct drm_connector_state *conn_state)
{
+ struct vc4_hdmi_connector_state *vc4_state =
conn_state_to_vc4_hdmi_conn_state(conn_state);
struct drm_display_mode *mode = &crtc_state->adjusted_mode;
struct vc4_hdmi *vc4_hdmi = encoder_to_vc4_hdmi(encoder);
unsigned long long pixel_rate = mode->clock * 1000;
@@ -824,6 +846,8 @@ static int vc4_hdmi_encoder_atomic_check(struct drm_encoder
*encoder,
if (pixel_rate > vc4_hdmi->variant->max_pixel_clock)
return -EINVAL;
+ vc4_state->pixel_rate = pixel_rate;
+
return 0;
}
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.h b/drivers/gpu/drm/vc4/vc4_hdmi.h
index 2cf5362052e2..bca6943de884 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.h
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.h
@@ -182,6 +182,7 @@ encoder_to_vc4_hdmi(struct drm_encoder *encoder)
struct vc4_hdmi_connector_state {
struct drm_connector_state base;
+ unsigned long long pixel_rate;
};
static inline struct vc4_hdmi_connector_state *
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 1/9] drm/vc4: hvs: Align the HVS atomic hooks to the new API
Since the CRTC setup in vc4 is split between the PixelValves/TXP and the
HVS, only the PV/TXP atomic hooks were updated in the previous commits, but
it makes sense to update the HVS ones too.
Reviewed-by: Thomas Zimmermann
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_crtc.c | 4 +---
drivers/gpu/drm/vc4/vc4_drv.h | 4 ++--
drivers/gpu/drm/vc4/vc4_hvs.c | 8 +---
drivers/gpu/drm/vc4/vc4_txp.c | 8 ++--
4 files changed, 10 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
index 06088854c647..e02e499885ed 100644
--- a/drivers/gpu/drm/vc4/vc4_crtc.c
+++ b/drivers/gpu/drm/vc4/vc4_crtc.c
@@ -503,8 +503,6 @@ static void vc4_crtc_atomic_disable(struct drm_crtc *crtc,
static void vc4_crtc_atomic_enable(struct drm_crtc *crtc,
struct drm_atomic_state *state)
{
- struct drm_crtc_state *old_state = drm_atomic_get_old_crtc_state(state,
-crtc);
struct drm_device *dev = crtc->dev;
struct vc4_crtc *vc4_crtc = to_vc4_crtc(crtc);
struct drm_encoder *encoder = vc4_get_crtc_encoder(crtc);
@@ -517,7 +515,7 @@ static void vc4_crtc_atomic_enable(struct drm_crtc *crtc,
*/
drm_crtc_vblank_on(crtc);
- vc4_hvs_atomic_enable(crtc, old_state);
+ vc4_hvs_atomic_enable(crtc, state);
if (vc4_encoder->pre_crtc_configure)
vc4_encoder->pre_crtc_configure(encoder);
diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
index c5f2944d5bc6..c47c85533805 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.h
+++ b/drivers/gpu/drm/vc4/vc4_drv.h
@@ -918,8 +918,8 @@ extern struct platform_driver vc4_hvs_driver;
void vc4_hvs_stop_channel(struct drm_device *dev, unsigned int output);
int vc4_hvs_get_fifo_from_output(struct drm_device *dev, unsigned int output);
int vc4_hvs_atomic_check(struct drm_crtc *crtc, struct drm_crtc_state *state);
-void vc4_hvs_atomic_enable(struct drm_crtc *crtc, struct drm_crtc_state
*old_state);
-void vc4_hvs_atomic_disable(struct drm_crtc *crtc, struct drm_crtc_state
*old_state);
+void vc4_hvs_atomic_enable(struct drm_crtc *crtc, struct drm_atomic_state
*state);
+void vc4_hvs_atomic_disable(struct drm_crtc *crtc, struct drm_atomic_state
*state);
void vc4_hvs_atomic_flush(struct drm_crtc *crtc, struct drm_crtc_state *state);
void vc4_hvs_dump_state(struct drm_device *dev);
void vc4_hvs_unmask_underrun(struct drm_device *dev, int channel);
diff --git a/drivers/gpu/drm/vc4/vc4_hvs.c b/drivers/gpu/drm/vc4/vc4_hvs.c
index b72b2bd05a81..04396dec63fc 100644
--- a/drivers/gpu/drm/vc4/vc4_hvs.c
+++ b/drivers/gpu/drm/vc4/vc4_hvs.c
@@ -391,11 +391,12 @@ static void vc4_hvs_update_dlist(struct drm_crtc *crtc)
}
void vc4_hvs_atomic_enable(struct drm_crtc *crtc,
- struct drm_crtc_state *old_state)
+ struct drm_atomic_state *state)
{
struct drm_device *dev = crtc->dev;
struct vc4_dev *vc4 = to_vc4_dev(dev);
- struct vc4_crtc_state *vc4_state = to_vc4_crtc_state(crtc->state);
+ struct drm_crtc_state *new_crtc_state =
drm_atomic_get_new_crtc_state(state, crtc);
+ struct vc4_crtc_state *vc4_state = to_vc4_crtc_state(new_crtc_state);
struct drm_display_mode *mode = &crtc->state->adjusted_mode;
bool oneshot = vc4_state->feed_txp;
@@ -404,9 +405,10 @@ void vc4_hvs_atomic_enable(struct drm_crtc *crtc,
}
void vc4_hvs_atomic_disable(struct drm_crtc *crtc,
- struct drm_crtc_state *old_state)
+ struct drm_atomic_state *state)
{
struct drm_device *dev = crtc->dev;
+ struct drm_crtc_state *old_state = drm_atomic_get_old_crtc_state(state,
crtc);
struct vc4_crtc_state *vc4_state = to_vc4_crtc_state(old_state);
unsigned int chan = vc4_state->assigned_channel;
diff --git a/drivers/gpu/drm/vc4/vc4_txp.c b/drivers/gpu/drm/vc4/vc4_txp.c
index 34612edcabbd..4a26750b5e93 100644
--- a/drivers/gpu/drm/vc4/vc4_txp.c
+++ b/drivers/gpu/drm/vc4/vc4_txp.c
@@ -406,23 +406,19 @@ static int vc4_txp_atomic_check(struct drm_crtc *crtc,
static void vc4_txp_atomic_enable(struct drm_crtc *crtc,
struct drm_atomic_state *state)
{
- struct drm_crtc_state *old_state = drm_atomic_get_old_crtc_state(state,
-crtc);
drm_crtc_vblank_on(crtc);
- vc4_hvs_atomic_enable(crtc, old_state);
+ vc4_hvs_atomic_enable(crtc, state);
}
static void vc4_txp_atomic_disable(struct drm_crtc *crtc,
struct drm_atomic_state *state)
{
- struct drm_crtc_state *old_state = drm_atomic_get_old_crtc_state(state,
-crtc);
struct drm_device *dev = crtc->dev;
[PATCH v5 9/9] drm/vc4: hdmi: Enable 10/12 bpc output
The BCM2711 supports higher bpc count than just 8, so let's support it in
our driver.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 71 -
drivers/gpu/drm/vc4/vc4_hdmi.h | 1 +
drivers/gpu/drm/vc4/vc4_hdmi_regs.h | 9
3 files changed, 80 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index f4ff6b5db484..fb30ddd842b1 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -76,6 +76,17 @@
#define VC5_HDMI_VERTB_VSPO_SHIFT 16
#define VC5_HDMI_VERTB_VSPO_MASK VC4_MASK(29, 16)
+#define VC5_HDMI_DEEP_COLOR_CONFIG_1_INIT_PACK_PHASE_SHIFT 8
+#define VC5_HDMI_DEEP_COLOR_CONFIG_1_INIT_PACK_PHASE_MASK VC4_MASK(10, 8)
+
+#define VC5_HDMI_DEEP_COLOR_CONFIG_1_COLOR_DEPTH_SHIFT 0
+#define VC5_HDMI_DEEP_COLOR_CONFIG_1_COLOR_DEPTH_MASK VC4_MASK(3, 0)
+
+#define VC5_HDMI_GCP_CONFIG_GCP_ENABLE BIT(31)
+
+#define VC5_HDMI_GCP_WORD_1_GCP_SUBPACKET_BYTE_1_SHIFT 8
+#define VC5_HDMI_GCP_WORD_1_GCP_SUBPACKET_BYTE_1_MASK VC4_MASK(15, 8)
+
# define VC4_HD_M_SW_RST BIT(2)
# define VC4_HD_M_ENABLE BIT(0)
@@ -179,6 +190,9 @@ static void vc4_hdmi_connector_reset(struct drm_connector
*connector)
kfree(connector->state);
+ conn_state->base.max_bpc = 8;
+ conn_state->base.max_requested_bpc = 8;
+
__drm_atomic_helper_connector_reset(connector, &conn_state->base);
if (connector->state)
@@ -228,12 +242,20 @@ static int vc4_hdmi_connector_init(struct drm_device *dev,
vc4_hdmi->ddc);
drm_connector_helper_add(connector, &vc4_hdmi_connector_helper_funcs);
+ /*
+* Some of the properties below require access to state, like bpc.
+* Allocate some default initial connector state with our reset helper.
+*/
+ if (connector->funcs->reset)
+ connector->funcs->reset(connector);
+
/* Create and attach TV margin props to this connector. */
ret = drm_mode_create_tv_margin_properties(dev);
if (ret)
return ret;
drm_connector_attach_tv_margin_properties(connector);
+ drm_connector_attach_max_bpc_property(connector, 8, 12);
connector->polled = (DRM_CONNECTOR_POLL_CONNECT |
DRM_CONNECTOR_POLL_DISCONNECT);
@@ -499,6 +521,7 @@ static void vc5_hdmi_csc_setup(struct vc4_hdmi *vc4_hdmi,
bool enable)
}
static void vc4_hdmi_set_timings(struct vc4_hdmi *vc4_hdmi,
+struct drm_connector_state *state,
struct drm_display_mode *mode)
{
bool hsync_pos = mode->flags & DRM_MODE_FLAG_PHSYNC;
@@ -542,7 +565,9 @@ static void vc4_hdmi_set_timings(struct vc4_hdmi *vc4_hdmi,
HDMI_WRITE(HDMI_VERTB0, vertb_even);
HDMI_WRITE(HDMI_VERTB1, vertb);
}
+
static void vc5_hdmi_set_timings(struct vc4_hdmi *vc4_hdmi,
+struct drm_connector_state *state,
struct drm_display_mode *mode)
{
bool hsync_pos = mode->flags & DRM_MODE_FLAG_PHSYNC;
@@ -562,6 +587,9 @@ static void vc5_hdmi_set_timings(struct vc4_hdmi *vc4_hdmi,
mode->crtc_vsync_end -
interlaced,
VC4_HDMI_VERTB_VBP));
+ unsigned char gcp;
+ bool gcp_en;
+ u32 reg;
HDMI_WRITE(HDMI_VEC_INTERFACE_XBAR, 0x354021);
HDMI_WRITE(HDMI_HORZA,
@@ -587,6 +615,39 @@ static void vc5_hdmi_set_timings(struct vc4_hdmi *vc4_hdmi,
HDMI_WRITE(HDMI_VERTB0, vertb_even);
HDMI_WRITE(HDMI_VERTB1, vertb);
+ switch (state->max_bpc) {
+ case 12:
+ gcp = 6;
+ gcp_en = true;
+ break;
+ case 10:
+ gcp = 5;
+ gcp_en = true;
+ break;
+ case 8:
+ default:
+ gcp = 4;
+ gcp_en = false;
+ break;
+ }
+
+ reg = HDMI_READ(HDMI_DEEP_COLOR_CONFIG_1);
+ reg &= ~(VC5_HDMI_DEEP_COLOR_CONFIG_1_INIT_PACK_PHASE_MASK |
+VC5_HDMI_DEEP_COLOR_CONFIG_1_COLOR_DEPTH_MASK);
+ reg |= VC4_SET_FIELD(2, VC5_HDMI_DEEP_COLOR_CONFIG_1_INIT_PACK_PHASE) |
+ VC4_SET_FIELD(gcp, VC5_HDMI_DEEP_COLOR_CONFIG_1_COLOR_DEPTH);
+ HDMI_WRITE(HDMI_DEEP_COLOR_CONFIG_1, reg);
+
+ reg = HDMI_READ(HDMI_GCP_WORD_1);
+ reg &= ~VC5_HDMI_GCP_WORD_1_GCP_SUBPACKET_BYTE_1_MASK;
+ reg |= VC4_SET_FIELD(gcp, VC5_HDMI_GCP_WORD_1_GCP_SUBPACKET_BYTE_1);
+ HDMI_WRITE(HDMI_GCP_WORD_1, reg);
+
+ reg = HDMI_READ(HDMI_GCP_CONFIG);
+ reg &= ~VC5_HDMI_GCP_CONFIG_GCP_ENABLE;
+ reg |= gcp_en ? VC5_HDMI_GCP_CONFIG_GCP_ENABLE : 0;
+ HDMI_WRITE(HDMI_GCP_CONFI
[PATCH drm/hisilicon v2 1/2] drm/hisilicon: Use managed mode-config init
Using drmm_mode_config_init() sets up managed release of modesetting
resources.
Signed-off-by: Tian Tao
---
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 14 +++---
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h | 1 -
2 files changed, 3 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
index 3687753..7f01213 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
@@ -96,8 +96,9 @@ static int hibmc_kms_init(struct hibmc_drm_private *priv)
struct drm_device *dev = &priv->dev;
int ret;
- drm_mode_config_init(dev);
- priv->mode_config_initialized = true;
+ ret = drmm_mode_config_init(dev);
+ if (ret)
+ return ret;
dev->mode_config.min_width = 0;
dev->mode_config.min_height = 0;
@@ -125,14 +126,6 @@ static int hibmc_kms_init(struct hibmc_drm_private *priv)
return 0;
}
-static void hibmc_kms_fini(struct hibmc_drm_private *priv)
-{
- if (priv->mode_config_initialized) {
- drm_mode_config_cleanup(&priv->dev);
- priv->mode_config_initialized = false;
- }
-}
-
/*
* It can operate in one of three modes: 0, 1 or Sleep.
*/
@@ -262,7 +255,6 @@ static int hibmc_unload(struct drm_device *dev)
drm_atomic_helper_shutdown(dev);
pci_disable_msi(dev->pdev);
- hibmc_kms_fini(priv);
dev->dev_private = NULL;
return 0;
}
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
index a49c10e..7d263f4 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
@@ -42,7 +42,6 @@ struct hibmc_drm_private {
struct drm_crtc crtc;
struct drm_encoder encoder;
struct hibmc_connector connector;
- bool mode_config_initialized;
};
static inline struct hibmc_connector *to_hibmc_connector(struct drm_connector
*connector)
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 8/8] drm/vc4: hdmi: Enable 10/12 bpc output
The BCM2711 supports higher bpc count than just 8, so let's support it in
our driver.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 71 -
drivers/gpu/drm/vc4/vc4_hdmi.h | 1 +
drivers/gpu/drm/vc4/vc4_hdmi_regs.h | 9
3 files changed, 80 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index e759ebd5fa34..8006bddc8fbb 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -76,6 +76,17 @@
#define VC5_HDMI_VERTB_VSPO_SHIFT 16
#define VC5_HDMI_VERTB_VSPO_MASK VC4_MASK(29, 16)
+#define VC5_HDMI_DEEP_COLOR_CONFIG_1_INIT_PACK_PHASE_SHIFT 8
+#define VC5_HDMI_DEEP_COLOR_CONFIG_1_INIT_PACK_PHASE_MASK VC4_MASK(10, 8)
+
+#define VC5_HDMI_DEEP_COLOR_CONFIG_1_COLOR_DEPTH_SHIFT 0
+#define VC5_HDMI_DEEP_COLOR_CONFIG_1_COLOR_DEPTH_MASK VC4_MASK(3, 0)
+
+#define VC5_HDMI_GCP_CONFIG_GCP_ENABLE BIT(31)
+
+#define VC5_HDMI_GCP_WORD_1_GCP_SUBPACKET_BYTE_1_SHIFT 8
+#define VC5_HDMI_GCP_WORD_1_GCP_SUBPACKET_BYTE_1_MASK VC4_MASK(15, 8)
+
# define VC4_HD_M_SW_RST BIT(2)
# define VC4_HD_M_ENABLE BIT(0)
@@ -179,6 +190,9 @@ static void vc4_hdmi_connector_reset(struct drm_connector
*connector)
kfree(connector->state);
+ conn_state->base.max_bpc = 8;
+ conn_state->base.max_requested_bpc = 8;
+
__drm_atomic_helper_connector_reset(connector, &conn_state->base);
if (connector->state)
@@ -228,12 +242,20 @@ static int vc4_hdmi_connector_init(struct drm_device *dev,
vc4_hdmi->ddc);
drm_connector_helper_add(connector, &vc4_hdmi_connector_helper_funcs);
+ /*
+* Some of the properties below require access to state, like bpc.
+* Allocate some default initial connector state with our reset helper.
+*/
+ if (connector->funcs->reset)
+ connector->funcs->reset(connector);
+
/* Create and attach TV margin props to this connector. */
ret = drm_mode_create_tv_margin_properties(dev);
if (ret)
return ret;
drm_connector_attach_tv_margin_properties(connector);
+ drm_connector_attach_max_bpc_property(connector, 8, 12);
connector->polled = (DRM_CONNECTOR_POLL_CONNECT |
DRM_CONNECTOR_POLL_DISCONNECT);
@@ -499,6 +521,7 @@ static void vc5_hdmi_csc_setup(struct vc4_hdmi *vc4_hdmi,
bool enable)
}
static void vc4_hdmi_set_timings(struct vc4_hdmi *vc4_hdmi,
+struct drm_connector_state *state,
struct drm_display_mode *mode)
{
bool hsync_pos = mode->flags & DRM_MODE_FLAG_PHSYNC;
@@ -542,7 +565,9 @@ static void vc4_hdmi_set_timings(struct vc4_hdmi *vc4_hdmi,
HDMI_WRITE(HDMI_VERTB0, vertb_even);
HDMI_WRITE(HDMI_VERTB1, vertb);
}
+
static void vc5_hdmi_set_timings(struct vc4_hdmi *vc4_hdmi,
+struct drm_connector_state *state,
struct drm_display_mode *mode)
{
bool hsync_pos = mode->flags & DRM_MODE_FLAG_PHSYNC;
@@ -562,6 +587,9 @@ static void vc5_hdmi_set_timings(struct vc4_hdmi *vc4_hdmi,
mode->crtc_vsync_end -
interlaced,
VC4_HDMI_VERTB_VBP));
+ unsigned char gcp;
+ bool gcp_en;
+ u32 reg;
HDMI_WRITE(HDMI_VEC_INTERFACE_XBAR, 0x354021);
HDMI_WRITE(HDMI_HORZA,
@@ -587,6 +615,39 @@ static void vc5_hdmi_set_timings(struct vc4_hdmi *vc4_hdmi,
HDMI_WRITE(HDMI_VERTB0, vertb_even);
HDMI_WRITE(HDMI_VERTB1, vertb);
+ switch (state->max_bpc) {
+ case 12:
+ gcp = 6;
+ gcp_en = true;
+ break;
+ case 10:
+ gcp = 5;
+ gcp_en = true;
+ break;
+ case 8:
+ default:
+ gcp = 4;
+ gcp_en = false;
+ break;
+ }
+
+ reg = HDMI_READ(HDMI_DEEP_COLOR_CONFIG_1);
+ reg &= ~(VC5_HDMI_DEEP_COLOR_CONFIG_1_INIT_PACK_PHASE_MASK |
+VC5_HDMI_DEEP_COLOR_CONFIG_1_COLOR_DEPTH_MASK);
+ reg |= VC4_SET_FIELD(2, VC5_HDMI_DEEP_COLOR_CONFIG_1_INIT_PACK_PHASE) |
+ VC4_SET_FIELD(gcp, VC5_HDMI_DEEP_COLOR_CONFIG_1_COLOR_DEPTH);
+ HDMI_WRITE(HDMI_DEEP_COLOR_CONFIG_1, reg);
+
+ reg = HDMI_READ(HDMI_GCP_WORD_1);
+ reg &= ~VC5_HDMI_GCP_WORD_1_GCP_SUBPACKET_BYTE_1_MASK;
+ reg |= VC4_SET_FIELD(gcp, VC5_HDMI_GCP_WORD_1_GCP_SUBPACKET_BYTE_1);
+ HDMI_WRITE(HDMI_GCP_WORD_1, reg);
+
+ reg = HDMI_READ(HDMI_GCP_CONFIG);
+ reg &= ~VC5_HDMI_GCP_CONFIG_GCP_ENABLE;
+ reg |= gcp_en ? VC5_HDMI_GCP_CONFIG_GCP_ENABLE : 0;
+ HDMI_WRITE(HDMI_GCP_CONFI
[PATCH v1 1/6] dt-bindings: display: add Unisoc's drm master bindings
From: Kevin Tang
The Unisoc DRM master device is a virtual device needed to list all
DPU devices or other display interface nodes that comprise the
graphics subsystem
Unisoc's display pipeline have several components as below
description, multi display controllers and corresponding physical interfaces.
For different display scenarios, dpu0 and dpu1 maybe binding to
different encoder.
E.g:
dpu0 and dpu1 both binding to DSI for dual mipi-dsi display;
dpu0 binding to DSI for primary display, and dpu1 binding to DP for external
display;
Cc: Orson Zhai
Cc: Chunyan Zhang
Signed-off-by: Kevin Tang
---
.../display/sprd/sprd,display-subsystem.yaml | 64 ++
1 file changed, 64 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/sprd/sprd,display-subsystem.yaml
diff --git
a/Documentation/devicetree/bindings/display/sprd/sprd,display-subsystem.yaml
b/Documentation/devicetree/bindings/display/sprd/sprd,display-subsystem.yaml
new file mode 100644
index 000..3d107e9
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/sprd/sprd,display-subsystem.yaml
@@ -0,0 +1,64 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/sprd/sprd,display-subsystem.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Unisoc DRM master device
+
+maintainers:
+ - Kevin Tang
+
+description: |
+ The Unisoc DRM master device is a virtual device needed to list all
+ DPU devices or other display interface nodes that comprise the
+ graphics subsystem.
+
+ Unisoc's display pipeline have several components as below description,
+ multi display controllers and corresponding physical interfaces.
+ For different display scenarios, dpu0 and dpu1 maybe binding to different
+ encoder.
+
+ E.g:
+ dpu0 and dpu1 both binding to DSI for dual mipi-dsi display;
+ dpu0 binding to DSI for primary display, and dpu1 binding to DP for external
display;
+
+ +-+
+ | |
+ |+-+ |
+ ++ | +++-+|DPHY/CPHY| | +--+
+ |+->+dpu0+--->+MIPI|DSI +--->+Combo+->+Panel0|
+ |AXI | | +++-++-+ | +--+
+ || | ^ |
+ || | | |
+ || | +---+ |
+ || | | |
+ |APB | | +--+-++---++---+ | +--+
+ |+->+dpu1+--->+DisplayPort+--->+PHY+->+Panel1|
+ || | +++---++---+ | +--+
+ ++ | |
+ +-+
+
+properties:
+ compatible:
+const: sprd,display-subsystem
+
+ ports:
+$ref: /schemas/types.yaml#/definitions/phandle-array
+description:
+ Should contain a list of phandles pointing to display interface port
+ of DPU devices.
+
+required:
+ - compatible
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+display-subsystem {
+compatible = "sprd,display-subsystem";
+ports = <&dpu_out>;
+};
+
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 5/9] drm/vc4: hdmi: Create a custom connector state
When run with a higher bpc than 8, the clock of the HDMI controller needs
to be adjusted. Let's create a connector state that will be used at
atomic_check and atomic_enable to compute and store the clock rate
associated to the state.
Acked-by: Thomas Zimmermann
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 27 +--
drivers/gpu/drm/vc4/vc4_hdmi.h | 10 ++
2 files changed, 35 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index 61039cc89d9d..744396c8dcb9 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -170,18 +170,41 @@ static int vc4_hdmi_connector_get_modes(struct
drm_connector *connector)
static void vc4_hdmi_connector_reset(struct drm_connector *connector)
{
- drm_atomic_helper_connector_reset(connector);
+ struct vc4_hdmi_connector_state *conn_state =
kzalloc(sizeof(*conn_state), GFP_KERNEL);
+
+ if (connector->state)
+ __drm_atomic_helper_connector_destroy_state(connector->state);
+
+ kfree(connector->state);
+
+ __drm_atomic_helper_connector_reset(connector, &conn_state->base);
if (connector->state)
drm_atomic_helper_connector_tv_reset(connector);
}
+static struct drm_connector_state *
+vc4_hdmi_connector_duplicate_state(struct drm_connector *connector)
+{
+ struct drm_connector_state *conn_state = connector->state;
+ struct vc4_hdmi_connector_state *vc4_state =
conn_state_to_vc4_hdmi_conn_state(conn_state);
+ struct vc4_hdmi_connector_state *new_state;
+
+ new_state = kzalloc(sizeof(*new_state), GFP_KERNEL);
+ if (!new_state)
+ return NULL;
+
+ __drm_atomic_helper_connector_duplicate_state(connector,
&new_state->base);
+
+ return &new_state->base;
+}
+
static const struct drm_connector_funcs vc4_hdmi_connector_funcs = {
.detect = vc4_hdmi_connector_detect,
.fill_modes = drm_helper_probe_single_connector_modes,
.destroy = vc4_hdmi_connector_destroy,
.reset = vc4_hdmi_connector_reset,
- .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
+ .atomic_duplicate_state = vc4_hdmi_connector_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
};
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.h b/drivers/gpu/drm/vc4/vc4_hdmi.h
index 0526a9cf608a..2cf5362052e2 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.h
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.h
@@ -180,6 +180,16 @@ encoder_to_vc4_hdmi(struct drm_encoder *encoder)
return container_of(_encoder, struct vc4_hdmi, encoder);
}
+struct vc4_hdmi_connector_state {
+ struct drm_connector_state base;
+};
+
+static inline struct vc4_hdmi_connector_state *
+conn_state_to_vc4_hdmi_conn_state(struct drm_connector_state *conn_state)
+{
+ return container_of(conn_state, struct vc4_hdmi_connector_state, base);
+}
+
void vc4_hdmi_phy_init(struct vc4_hdmi *vc4_hdmi,
struct drm_display_mode *mode);
void vc4_hdmi_phy_disable(struct vc4_hdmi *vc4_hdmi);
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH] drm/panel: Make backlight attachment lazy
Some bridge chips, such as the TI SN65DSI86 DSI/eDP bridge, provides
means of generating a PWM signal for backlight control of the attached
panel. The provided PWM chip is typically controlled by the
pwm-backlight driver, which if tied to the panel will provide DPMS.
But with the current implementation the panel will refuse to probe
because the bridge driver has yet to probe and register the PWM chip,
and the bridge driver will refuse to probe because it's unable to find
the panel.
Mitigate this catch-22 situation by allowing the panel driver to probe
and retry the attachment of the backlight as the panel is turned on or
off.
Signed-off-by: Bjorn Andersson
---
drivers/gpu/drm/drm_panel.c | 47 +++--
include/drm/drm_panel.h | 8 +++
2 files changed, 43 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/drm_panel.c b/drivers/gpu/drm/drm_panel.c
index f634371c717a..7487329bd22d 100644
--- a/drivers/gpu/drm/drm_panel.c
+++ b/drivers/gpu/drm/drm_panel.c
@@ -43,6 +43,34 @@ static LIST_HEAD(panel_list);
* take look at drm_panel_bridge_add() and devm_drm_panel_bridge_add().
*/
+#if IS_REACHABLE(CONFIG_BACKLIGHT_CLASS_DEVICE)
+static int drm_panel_of_backlight_lazy(struct drm_panel *panel)
+{
+ struct backlight_device *backlight;
+
+ if (!panel || !panel->dev)
+ return -EINVAL;
+
+ backlight = devm_of_find_backlight(panel->dev);
+
+ if (IS_ERR(backlight)) {
+ if (PTR_ERR(backlight) == -EPROBE_DEFER) {
+ panel->backlight_init_pending = true;
+ return 0;
+ }
+
+ return PTR_ERR(backlight);
+ }
+
+ panel->backlight = backlight;
+ panel->backlight_init_pending = false;
+
+ return 0;
+}
+#else
+static int drm_panel_of_backlight_lazy(struct drm_panel *panel) { return 0; }
+#endif
+
/**
* drm_panel_init - initialize a panel
* @panel: DRM panel
@@ -161,6 +189,9 @@ int drm_panel_enable(struct drm_panel *panel)
return ret;
}
+ if (panel->backlight_init_pending)
+ drm_panel_of_backlight_lazy(panel);
+
ret = backlight_enable(panel->backlight);
if (ret < 0)
DRM_DEV_INFO(panel->dev, "failed to enable backlight: %d\n",
@@ -187,6 +218,9 @@ int drm_panel_disable(struct drm_panel *panel)
if (!panel)
return -EINVAL;
+ if (panel->backlight_init_pending)
+ drm_panel_of_backlight_lazy(panel);
+
ret = backlight_disable(panel->backlight);
if (ret < 0)
DRM_DEV_INFO(panel->dev, "failed to disable backlight: %d\n",
@@ -328,18 +362,7 @@ EXPORT_SYMBOL(of_drm_get_panel_orientation);
*/
int drm_panel_of_backlight(struct drm_panel *panel)
{
- struct backlight_device *backlight;
-
- if (!panel || !panel->dev)
- return -EINVAL;
-
- backlight = devm_of_find_backlight(panel->dev);
-
- if (IS_ERR(backlight))
- return PTR_ERR(backlight);
-
- panel->backlight = backlight;
- return 0;
+ return drm_panel_of_backlight_lazy(panel);
}
EXPORT_SYMBOL(drm_panel_of_backlight);
#endif
diff --git a/include/drm/drm_panel.h b/include/drm/drm_panel.h
index 33605c3f0eba..b126abebb2f3 100644
--- a/include/drm/drm_panel.h
+++ b/include/drm/drm_panel.h
@@ -149,6 +149,14 @@ struct drm_panel {
*/
struct backlight_device *backlight;
+ /**
+* @backlight_init_pending
+*
+* Backlight driver is not yet available so further attempts to
+* initialize @backlight is necessary.
+*/
+ bool backlight_init_pending;
+
/**
* @funcs:
*
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: drm_basic_types.h, DRM_FOURCC_STANDALONE
Create drm_basic_types.h to define types previously defined by drm.h.
Use DRM_FOURCC_STANDALONE to include drm_fourcc.h without drm.h.
This will allow Mesa to port code to Windows more easily.
Signed-off-by: James Park
---
include/uapi/drm/drm.h | 12 ++---
include/uapi/drm/drm_basic_types.h | 52 ++
include/uapi/drm/drm_fourcc.h | 4 +++
3 files changed, 58 insertions(+), 10 deletions(-)
create mode 100644 include/uapi/drm/drm_basic_types.h
diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index 808b48a..d9ba922 100644
--- a/include/uapi/drm/drm.h
+++ b/include/uapi/drm/drm.h
@@ -36,6 +36,8 @@
#ifndef _DRM_H_
#define _DRM_H_
+#include "drm_basic_types.h"
+
#if defined(__KERNEL__)
#include
@@ -50,18 +52,8 @@ typedef unsigned int drm_handle_t;
#else /* One of the BSDs */
-#include
#include
#include
-typedef int8_t __s8;
-typedef uint8_t __u8;
-typedef int16_t __s16;
-typedef uint16_t __u16;
-typedef int32_t __s32;
-typedef uint32_t __u32;
-typedef int64_t __s64;
-typedef uint64_t __u64;
-typedef size_t __kernel_size_t;
typedef unsigned long drm_handle_t;
#endif
diff --git a/include/uapi/drm/drm_basic_types.h
b/include/uapi/drm/drm_basic_types.h
new file mode 100644
index 000..da1f2c0
--- /dev/null
+++ b/include/uapi/drm/drm_basic_types.h
@@ -0,0 +1,52 @@
+/*
+ * Copyright 1999 Precision Insight, Inc., Cedar Park, Texas.
+ * Copyright 2000 VA Linux Systems, Inc., Sunnyvale, California.
+ * All rights reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * VA LINUX SYSTEMS AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#ifndef _DRM_BASIC_TYPES_H_
+#define _DRM_BASIC_TYPES_H_
+
+#if defined(__KERNEL__)
+
+#include
+
+#elif defined(__linux__)
+
+#include
+
+#else /* Not Linux */
+
+#include
+typedef int8_t __s8;
+typedef uint8_t __u8;
+typedef int16_t __s16;
+typedef uint16_t __u16;
+typedef int32_t __s32;
+typedef uint32_t __u32;
+typedef int64_t __s64;
+typedef uint64_t __u64;
+typedef size_t __kernel_size_t;
+
+#endif
+
+#endif
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 82f3278..539870f 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -24,7 +24,11 @@
#ifndef DRM_FOURCC_H
#define DRM_FOURCC_H
+#include "drm_basic_types.h"
+
+#ifndef DRM_FOURCC_STANDALONE
#include "drm.h"
+#endif
#if defined(__cplusplus)
extern "C" {
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 0/8] mainline Plymovent M2M and BAS board
changes v7: - panel-simple.yaml: fix comments and part order - panel-simple.yaml: invent a product description for the Kyocera tcg070wvlq panel changes v6: - do more panel-simple.yaml related cleanups changes v5: - rebase against latest shawngup/for-next - add patch to fix checkpatch warning on PLYM2M dts changes v4: - add PLYBAS board - PLYM2M: add touchscreen node - PLYM2M: add rename led nodes to led-x changes v3: - use old style copyright text changes v2: - fsl.yaml: reorder ply,plym2m - imx6dl-plym2m.dts: use hyphen instead of underscore in phy-clock Oleksij Rempel (8): dt-bindings: display: simple: fix alphabetical order for EDT compatibles dt-bindings: display: simple: add EDT compatibles already supported by the driver dt-bindings: display: simple: Add Kyocera tcg070wvlq panel dt-bindings: vendor-prefixes: Add an entry for Plymovent dt-bindings: arm: fsl: add Plymovent M2M board ARM: dts: add Plymovent M2M board dt-bindings: arm: fsl: add Plymovent BAS board ARM: dts: add Plymovent BAS board .../devicetree/bindings/arm/fsl.yaml | 2 + .../bindings/display/panel/panel-simple.yaml | 19 +- .../devicetree/bindings/vendor-prefixes.yaml | 2 + arch/arm/boot/dts/Makefile| 2 + arch/arm/boot/dts/imx6dl-plybas.dts | 394 arch/arm/boot/dts/imx6dl-plym2m.dts | 446 ++ 6 files changed, 857 insertions(+), 8 deletions(-) create mode 100644 arch/arm/boot/dts/imx6dl-plybas.dts create mode 100644 arch/arm/boot/dts/imx6dl-plym2m.dts -- 2.29.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 4/6] drm/sprd: add Unisoc's drm display controller driver
Adds DPU(Display Processor Unit) support for the Unisoc's display subsystem. It's support multi planes, scaler, rotation, PQ(Picture Quality) and more. Cc: Orson Zhai Cc: Chunyan Zhang Signed-off-by: Kevin Tang --- drivers/gpu/drm/sprd/Kconfig| 1 + drivers/gpu/drm/sprd/Makefile | 6 +- drivers/gpu/drm/sprd/dpu_r2p0.c | 598 drivers/gpu/drm/sprd/sprd_dpu.c | 457 ++ drivers/gpu/drm/sprd/sprd_dpu.h | 175 drivers/gpu/drm/sprd/sprd_drm.c | 1 + drivers/gpu/drm/sprd/sprd_drm.h | 2 + 7 files changed, 1238 insertions(+), 2 deletions(-) create mode 100644 drivers/gpu/drm/sprd/dpu_r2p0.c create mode 100644 drivers/gpu/drm/sprd/sprd_dpu.c create mode 100644 drivers/gpu/drm/sprd/sprd_dpu.h diff --git a/drivers/gpu/drm/sprd/Kconfig b/drivers/gpu/drm/sprd/Kconfig index 6e80cc9..9b4ef9a 100644 --- a/drivers/gpu/drm/sprd/Kconfig +++ b/drivers/gpu/drm/sprd/Kconfig @@ -3,6 +3,7 @@ config DRM_SPRD depends on ARCH_SPRD || COMPILE_TEST depends on DRM && OF select DRM_KMS_HELPER + select VIDEOMODE_HELPERS select DRM_GEM_CMA_HELPER select DRM_KMS_CMA_HELPER select DRM_MIPI_DSI diff --git a/drivers/gpu/drm/sprd/Makefile b/drivers/gpu/drm/sprd/Makefile index 86d95d9..0ba48f2 100644 --- a/drivers/gpu/drm/sprd/Makefile +++ b/drivers/gpu/drm/sprd/Makefile @@ -1,5 +1,7 @@ # SPDX-License-Identifier: GPL-2.0 -subdir-ccflags-y += -I$(srctree)/$(src) +obj-y := sprd_drm.o \ + sprd_dpu.o + +obj-y += dpu_r2p0.o -obj-y := sprd_drm.o diff --git a/drivers/gpu/drm/sprd/dpu_r2p0.c b/drivers/gpu/drm/sprd/dpu_r2p0.c new file mode 100644 index 000..46ab8b3 --- /dev/null +++ b/drivers/gpu/drm/sprd/dpu_r2p0.c @@ -0,0 +1,598 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Copyright (C) 2020 Unisoc Inc. + */ + +#include +#include +#include +#include + +#include "sprd_dpu.h" + +/* Global control registers */ +#define REG_DPU_CTRL 0x04 +#define REG_DPU_CFG0 0x08 +#define REG_DPU_CFG1 0x0C +#define REG_DPU_CFG2 0x10 +#define REG_PANEL_SIZE 0x20 +#define REG_BLEND_SIZE 0x24 +#define REG_BG_COLOR 0x2C + +/* Layer0 control registers */ +#define REG_LAY_BASE_ADDR0 0x30 +#define REG_LAY_BASE_ADDR1 0x34 +#define REG_LAY_BASE_ADDR2 0x38 +#define REG_LAY_CTRL 0x40 +#define REG_LAY_SIZE 0x44 +#define REG_LAY_PITCH 0x48 +#define REG_LAY_POS0x4C +#define REG_LAY_ALPHA 0x50 +#define REG_LAY_PALLETE0x58 +#define REG_LAY_CROP_START 0x5C + +/* Interrupt control registers */ +#define REG_DPU_INT_EN 0x1E0 +#define REG_DPU_INT_CLR0x1E4 +#define REG_DPU_INT_STS0x1E8 + +/* DPI control registers */ +#define REG_DPI_CTRL 0x1F0 +#define REG_DPI_H_TIMING 0x1F4 +#define REG_DPI_V_TIMING 0x1F8 + +/* MMU control registers */ +#define REG_MMU_EN 0x800 +#define REG_MMU_VPN_RANGE 0x80C +#define REG_MMU_VAOR_ADDR_RD 0x818 +#define REG_MMU_VAOR_ADDR_WR 0x81C +#define REG_MMU_INV_ADDR_RD0x820 +#define REG_MMU_INV_ADDR_WR0x824 +#define REG_MMU_PPN1 0x83C +#define REG_MMU_RANGE1 0x840 +#define REG_MMU_PPN2 0x844 +#define REG_MMU_RANGE2 0x848 + +/* Global control bits */ +#define BIT_DPU_RUNBIT(0) +#define BIT_DPU_STOP BIT(1) +#define BIT_DPU_REG_UPDATE BIT(2) +#define BIT_DPU_IF_EDPIBIT(0) +#define BIT_DPU_COEF_NARROW_RANGE BIT(4) +#define BIT_DPU_Y2R_COEF_ITU709_STANDARD BIT(5) + +/* Layer control bits */ +#define BIT_DPU_LAY_EN BIT(0) +#define BIT_DPU_LAY_LAYER_ALPHA(0x01 << 2) +#define BIT_DPU_LAY_COMBO_ALPHA(0x02 << 2) +#define BIT_DPU_LAY_FORMAT_YUV422_2PLANE (0x00 << 4) +#define BIT_DPU_LAY_FORMAT_YUV420_2PLANE (0x01 << 4) +#define BIT_DPU_LAY_FORMAT_YUV420_3PLANE (0x02 << 4) +#define BIT_DPU_LAY_FORMAT_ARGB(0x03 << 4) +#define BIT_DPU_LAY_FORMAT_RGB565 (0x04 << 4) +#define BIT_DPU_LAY_DATA_ENDIAN_B0B1B2B3 (0x00 << 8) +#define BIT_DPU_LAY_DATA_ENDIAN_B3B2B1B0 (0x01 << 8) +#define BIT_DPU_LAY_NO_SWITCH (0x00 << 10) +#define BIT_DPU_LAY_RB_OR_UV_SWITCH(0x01 << 10) +#define BIT_DPU_LAY_MODE_BLEND_NORMAL (0x00 << 16) +#define BIT_DPU_LAY_MODE_BLEND_PREMULT (0x01 << 16) + +/* Interrupt control & status bits */ +#define BIT_DPU_INT_DONE BIT(0) +#define BIT_DPU_INT_TE BIT(1) +#define BIT_DPU_INT_ERRBIT(2) +#define BIT_DPU_INT_UPDATE_DONEBIT(4) +#define BIT_DPU_INT_VSYNC BIT(5) +#define BIT_DPU_INT_FBC_PLD_ERR
[PATCH v4 7/8] drm/vc4: hdmi: Limit the BCM2711 to the max without scrambling
Unlike the previous generations, the HSM clock limitation is way above
what we can reach without scrambling, so let's move the maximum
frequency we support to the maximum clock frequency without scrambling.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index 795fd23c8f58..e759ebd5fa34 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -82,6 +82,8 @@
#define CEC_CLOCK_FREQ 4
#define VC4_HSM_MID_CLOCK 149985000
+#define HDMI_14_MAX_TMDS_CLK (340 * 1000 * 1000)
+
static int vc4_hdmi_debugfs_regs(struct seq_file *m, void *unused)
{
struct drm_info_node *node = (struct drm_info_node *)m->private;
@@ -1908,7 +1910,7 @@ static const struct vc4_hdmi_variant
bcm2711_hdmi0_variant = {
.encoder_type = VC4_ENCODER_TYPE_HDMI0,
.debugfs_name = "hdmi0_regs",
.card_name = "vc4-hdmi-0",
- .max_pixel_clock= 29700,
+ .max_pixel_clock= HDMI_14_MAX_TMDS_CLK,
.registers = vc5_hdmi_hdmi0_fields,
.num_registers = ARRAY_SIZE(vc5_hdmi_hdmi0_fields),
.phy_lane_mapping = {
@@ -1934,7 +1936,7 @@ static const struct vc4_hdmi_variant
bcm2711_hdmi1_variant = {
.encoder_type = VC4_ENCODER_TYPE_HDMI1,
.debugfs_name = "hdmi1_regs",
.card_name = "vc4-hdmi-1",
- .max_pixel_clock= 29700,
+ .max_pixel_clock= HDMI_14_MAX_TMDS_CLK,
.registers = vc5_hdmi_hdmi1_fields,
.num_registers = ARRAY_SIZE(vc5_hdmi_hdmi1_fields),
.phy_lane_mapping = {
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 5/8] drm/vc4: hdmi: Store pixel frequency in the connector state
Hi Thomas,
On Mon, Dec 07, 2020 at 03:14:49PM +0100, Thomas Zimmermann wrote:
> Am 07.12.20 um 14:39 schrieb Maxime Ripard:
> > The pixel rate is for now quite simple to compute, but with more features
> > (30 and 36 bits output, YUV output, etc.) will depend on a bunch of
> > connectors properties.
> >
> > Let's store the rate we have to run the pixel clock at in our custom
> > connector state, and compute it in atomic_check.
> >
> > Signed-off-by: Maxime Ripard
> > ---
> > drivers/gpu/drm/vc4/vc4_hdmi.c | 26 +-
> > drivers/gpu/drm/vc4/vc4_hdmi.h | 1 +
> > 2 files changed, 26 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> > index 862c93708e9a..c1667cfe37db 100644
> > --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> > +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> > @@ -194,6 +194,7 @@ vc4_hdmi_connector_duplicate_state(struct drm_connector
> > *connector)
> > if (!new_state)
> > return NULL;
> > + new_state->pixel_rate = vc4_state->pixel_rate;
> > __drm_atomic_helper_connector_duplicate_state(connector,
> > &new_state->base);
> > return &new_state->base;
> > @@ -611,9 +612,29 @@ static void vc4_hdmi_recenter_fifo(struct vc4_hdmi
> > *vc4_hdmi)
> > "VC4_HDMI_FIFO_CTL_RECENTER_DONE");
> > }
> > +static struct drm_connector_state *
> > +vc4_hdmi_encoder_get_connector_state(struct drm_encoder *encoder,
> > +struct drm_atomic_state *state)
> > +{
> > + struct drm_connector_state *conn_state;
> > + struct drm_connector *connector;
> > + unsigned int i;
> > +
> > + for_each_new_connector_in_state(state, connector, conn_state, i) {
> > + if (conn_state->best_encoder == encoder)
> > + return conn_state;
> > + }
> > +
> > + return NULL;
> > +}
> > +
> > static void vc4_hdmi_encoder_pre_crtc_configure(struct drm_encoder
> > *encoder,
> > struct drm_atomic_state *state)
> > {
> > + struct drm_connector_state *conn_state =
> > + vc4_hdmi_encoder_get_connector_state(encoder, state);
> > + struct vc4_hdmi_connector_state *vc4_conn_state =
> > + conn_state_to_vc4_hdmi_conn_state(conn_state);
> > struct drm_display_mode *mode = &encoder->crtc->state->adjusted_mode;
> > struct vc4_hdmi *vc4_hdmi = encoder_to_vc4_hdmi(encoder);
> > unsigned long pixel_rate, hsm_rate;
> > @@ -625,7 +646,7 @@ static void vc4_hdmi_encoder_pre_crtc_configure(struct
> > drm_encoder *encoder,
> > return;
> > }
> > - pixel_rate = mode->clock * 1000 * ((mode->flags & DRM_MODE_FLAG_DBLCLK)
> > ? 2 : 1);
>
> Has (mode->flags & DRM_MODE_FLAG_DBLCLK) been lost? I cannot find it any
> longer. The code in atomic_check() looks significantly different.
Indeed, it's a mistake from a previous patch. I'll send a fix for that one too.
Thanks!
Maxime
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 0/8] drm/vc4: hdmi: Support the 10/12 bit output
Hi, Here's some patches to enable the HDR output in the RPi4/BCM2711 HDMI controller. Let me know what you think, Maxime Changes from v3: - Don't dereference the connector->state pointer if kzalloc failed Changes from v2: - Rebased on current drm-misc-next - Fixed a bug that was dropping the refresh rate when the bpc count was increased Changes from v1: - Added the coccinelle script to the first patch - Fixed the pixel_rate ramp up Maxime Ripard (8): drm/vc4: hvs: Align the HVS atomic hooks to the new API drm/vc4: Pass the atomic state to encoder hooks drm/vc4: hdmi: Don't access the connector state in reset if kmalloc fails drm/vc4: hdmi: Create a custom connector state drm/vc4: hdmi: Store pixel frequency in the connector state drm/vc4: hdmi: Use the connector state pixel rate for the PHY drm/vc4: hdmi: Limit the BCM2711 to the max without scrambling drm/vc4: hdmi: Enable 10/12 bpc output drivers/gpu/drm/vc4/vc4_crtc.c | 22 ++-- drivers/gpu/drm/vc4/vc4_drv.h | 14 +-- drivers/gpu/drm/vc4/vc4_hdmi.c | 151 +--- drivers/gpu/drm/vc4/vc4_hdmi.h | 21 +++- drivers/gpu/drm/vc4/vc4_hdmi_phy.c | 8 +- drivers/gpu/drm/vc4/vc4_hdmi_regs.h | 9 ++ drivers/gpu/drm/vc4/vc4_hvs.c | 8 +- drivers/gpu/drm/vc4/vc4_txp.c | 8 +- 8 files changed, 193 insertions(+), 48 deletions(-) -- 2.28.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH][next] drm/mediatek: avoid dereferencing a null hdmi_phy on an error message
On Mon, 2020-12-07 at 15:09 +, Colin King wrote:
> From: Colin Ian King
>
> Currently there is a null pointer check for hdmi_phy that implies it
> may be null, however a dev_err messages dereferences this potential null
> pointer. Avoid a null pointer dereference by only emitting the dev_err
> message if hdmi_phy is non-null. It is a moot point if the error message
> needs to be printed at all, but since this is a relatively new piece of
> code it may be useful to keep the message in for the moment in case there
> are unforseen errors that need to be reported.
>
> Addresses-Coverity: ("Dereference after null check")
> Fixes: be28b6507c46 ("drm/mediatek: separate hdmi phy to different file")
> Signed-off-by: Colin Ian King
> ---
> drivers/phy/mediatek/phy-mtk-hdmi.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/phy/mediatek/phy-mtk-hdmi.c
> b/drivers/phy/mediatek/phy-mtk-hdmi.c
> index c5c61f5a9ea0..5184054783c7 100644
> --- a/drivers/phy/mediatek/phy-mtk-hdmi.c
> +++ b/drivers/phy/mediatek/phy-mtk-hdmi.c
> @@ -84,8 +84,9 @@ mtk_hdmi_phy_dev_get_ops(const struct mtk_hdmi_phy
> *hdmi_phy)
> hdmi_phy->conf->hdmi_phy_disable_tmds)
> return &mtk_hdmi_phy_dev_ops;
>
> - dev_err(hdmi_phy->dev, "Failed to get dev ops of phy\n");
> - return NULL;
> + if (hdmi_phy)
> + dev_err(hdmi_phy->dev, "Failed to get dev ops of phy\n");
> + return NULL;
indentation: one tab before return
Thanks
> }
>
> static void mtk_hdmi_phy_clk_get_data(struct mtk_hdmi_phy *hdmi_phy,
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 8/8] ARM: dts: add Plymovent BAS board
Plymovent BAS is a base system controller produced for the Plymovent filter
systems.
Co-Developed-by: David Jander
Signed-off-by: David Jander
Signed-off-by: Oleksij Rempel
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/imx6dl-plybas.dts | 394
2 files changed, 395 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6dl-plybas.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 31249fc5f85c..ee725aebc3a8 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -461,6 +461,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
imx6dl-pico-hobbit.dtb \
imx6dl-pico-nymph.dtb \
imx6dl-pico-pi.dtb \
+ imx6dl-plybas.dtb \
imx6dl-plym2m.dtb \
imx6dl-prtrvt.dtb \
imx6dl-prtvt7.dtb \
diff --git a/arch/arm/boot/dts/imx6dl-plybas.dts
b/arch/arm/boot/dts/imx6dl-plybas.dts
new file mode 100644
index ..333c306aa946
--- /dev/null
+++ b/arch/arm/boot/dts/imx6dl-plybas.dts
@@ -0,0 +1,394 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/*
+ * Copyright (c) 2014 Protonic Holland
+ * Copyright (c) 2020 Oleksij Rempel , Pengutronix
+ */
+
+/dts-v1/;
+#include
+#include
+#include "imx6dl.dtsi"
+
+/ {
+ model = "Plymovent BAS board";
+ compatible = "ply,plybas", "fsl,imx6dl";
+
+ chosen {
+ stdout-path = &uart4;
+ };
+
+ gpio_keys {
+ compatible = "gpio-keys";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ autorepeat;
+
+ button@20 {
+ label = "START";
+ linux,code = <31>;
+ gpios = <&gpio5 8 GPIO_ACTIVE_LOW>;
+ };
+
+ button@21 {
+ label = "CLEAN";
+ linux,code = <46>;
+ gpios = <&gpio5 9 GPIO_ACTIVE_LOW>;
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_leds>;
+
+ led-0 {
+ label = "debug0";
+ gpios = <&gpio1 8 GPIO_ACTIVE_HIGH>;
+ };
+
+ led-1 {
+ label = "debug1";
+ gpios = <&gpio1 9 GPIO_ACTIVE_HIGH>;
+ };
+
+ led-2 {
+ label = "light_tower1";
+ gpios = <&gpio4 22 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "heartbeat";
+ };
+
+ led-3 {
+ label = "light_tower2";
+ gpios = <&gpio4 23 GPIO_ACTIVE_HIGH>;
+ };
+
+ led-4 {
+ label = "light_tower3";
+ gpios = <&gpio4 24 GPIO_ACTIVE_HIGH>;
+ };
+
+ led-5 {
+ label = "light_tower4";
+ gpios = <&gpio4 25 GPIO_ACTIVE_HIGH>;
+ };
+ };
+
+ clk50m_phy: phy-clock {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <5000>;
+ };
+
+ reg_5v0: regulator-5v0 {
+ compatible = "regulator-fixed";
+ regulator-name = "5v0";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ };
+};
+
+&can1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_can1>;
+ xceiver-supply = <®_5v0>;
+ status = "okay";
+};
+
+&can2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_can2>;
+ xceiver-supply = <®_5v0>;
+ status = "okay";
+};
+
+&ecspi1 {
+ cs-gpios = <&gpio3 19 GPIO_ACTIVE_LOW>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ecspi1>;
+ status = "okay";
+
+ flash@0 {
+ compatible = "jedec,spi-nor";
+ reg = <0>;
+ spi-max-frequency = <2000>;
+ };
+};
+
+&fec {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_enet>;
+ phy-mode = "rmii";
+ clocks = <&clks IMX6QDL_CLK_ENET>,
+<&clks IMX6QDL_CLK_ENET>,
+<&clk50m_phy>;
+ clock-names = "ipg", "ahb", "ptp";
+ phy-handle = <&rgmii_phy>;
+ status = "okay";
+
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* Microchip KSZ8081RNA PHY */
+ rgmii_phy: ethernet-phy@0 {
+ reg = <0>;
+ interrupts-extended = <&gpio4 30 IRQ_TYPE_LEVEL_LOW>;
+ reset-gpios = <&gpio4 26 GPIO_ACTIVE_LOW>;
+ reset-assert-us = <1>;
+ reset-deassert-us = <300>;
+ };
+ };
+};
+
+&gpio1 {
+ gpio-line-names =
Re: [PATCH v4 2/8] drm/vc4: Pass the atomic state to encoder hooks
On Mon, Dec 07, 2020 at 03:16:40PM +0100, Thomas Zimmermann wrote: > > > Am 07.12.20 um 14:39 schrieb Maxime Ripard: > > We'll need to access the connector state in our encoder setup, so let's > > just pass the whole DRM state to our private encoder hooks. > > > > Signed-off-by: Maxime Ripard > > This becomes relevant in patch 5, I guess? Yep, we can't access the connector state from the crtc state alone, hence why the change is needed. > If so > > Acked-by: Thomas Zimmermann Thanks! Maxime signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 7/9] drm/vc4: hdmi: Use the connector state pixel rate for the PHY
The PHY initialisation parameters are not based on the pixel clock but
the TMDS clock rate which can be the pixel clock in the standard case,
but could be adjusted based on some parameters like the bits per color.
Since the TMDS clock rate is stored in our custom connector state
already, let's reuse it from there instead of computing it again.
Acked-by: Thomas Zimmermann
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 2 +-
drivers/gpu/drm/vc4/vc4_hdmi.h | 11 +--
drivers/gpu/drm/vc4/vc4_hdmi_phy.c | 8 +---
3 files changed, 11 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index 83699105c7a5..5310e06efc82 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -714,7 +714,7 @@ static void vc4_hdmi_encoder_pre_crtc_configure(struct
drm_encoder *encoder,
vc4_hdmi->variant->reset(vc4_hdmi);
if (vc4_hdmi->variant->phy_init)
- vc4_hdmi->variant->phy_init(vc4_hdmi, mode);
+ vc4_hdmi->variant->phy_init(vc4_hdmi, vc4_conn_state);
HDMI_WRITE(HDMI_SCHEDULER_CONTROL,
HDMI_READ(HDMI_SCHEDULER_CONTROL) |
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.h b/drivers/gpu/drm/vc4/vc4_hdmi.h
index bca6943de884..60c53d7c9bad 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.h
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.h
@@ -21,10 +21,9 @@ to_vc4_hdmi_encoder(struct drm_encoder *encoder)
return container_of(encoder, struct vc4_hdmi_encoder, base.base);
}
-struct drm_display_mode;
-
struct vc4_hdmi;
struct vc4_hdmi_register;
+struct vc4_hdmi_connector_state;
enum vc4_hdmi_phy_channel {
PHY_LANE_0 = 0,
@@ -80,9 +79,9 @@ struct vc4_hdmi_variant {
void (*set_timings)(struct vc4_hdmi *vc4_hdmi,
struct drm_display_mode *mode);
- /* Callback to initialize the PHY according to the mode */
+ /* Callback to initialize the PHY according to the connector state */
void (*phy_init)(struct vc4_hdmi *vc4_hdmi,
-struct drm_display_mode *mode);
+struct vc4_hdmi_connector_state *vc4_conn_state);
/* Callback to disable the PHY */
void (*phy_disable)(struct vc4_hdmi *vc4_hdmi);
@@ -192,13 +191,13 @@ conn_state_to_vc4_hdmi_conn_state(struct
drm_connector_state *conn_state)
}
void vc4_hdmi_phy_init(struct vc4_hdmi *vc4_hdmi,
- struct drm_display_mode *mode);
+ struct vc4_hdmi_connector_state *vc4_conn_state);
void vc4_hdmi_phy_disable(struct vc4_hdmi *vc4_hdmi);
void vc4_hdmi_phy_rng_enable(struct vc4_hdmi *vc4_hdmi);
void vc4_hdmi_phy_rng_disable(struct vc4_hdmi *vc4_hdmi);
void vc5_hdmi_phy_init(struct vc4_hdmi *vc4_hdmi,
- struct drm_display_mode *mode);
+ struct vc4_hdmi_connector_state *vc4_conn_state);
void vc5_hdmi_phy_disable(struct vc4_hdmi *vc4_hdmi);
void vc5_hdmi_phy_rng_enable(struct vc4_hdmi *vc4_hdmi);
void vc5_hdmi_phy_rng_disable(struct vc4_hdmi *vc4_hdmi);
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi_phy.c
b/drivers/gpu/drm/vc4/vc4_hdmi_phy.c
index 057796b54c51..36535480f8e2 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi_phy.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi_phy.c
@@ -127,7 +127,8 @@
#define OSCILLATOR_FREQUENCY 5400
-void vc4_hdmi_phy_init(struct vc4_hdmi *vc4_hdmi, struct drm_display_mode
*mode)
+void vc4_hdmi_phy_init(struct vc4_hdmi *vc4_hdmi,
+ struct vc4_hdmi_connector_state *conn_state)
{
/* PHY should be in reset, like
* vc4_hdmi_encoder_disable() does.
@@ -339,11 +340,12 @@ static void vc5_hdmi_reset_phy(struct vc4_hdmi *vc4_hdmi)
HDMI_WRITE(HDMI_TX_PHY_POWERDOWN_CTL, BIT(10));
}
-void vc5_hdmi_phy_init(struct vc4_hdmi *vc4_hdmi, struct drm_display_mode
*mode)
+void vc5_hdmi_phy_init(struct vc4_hdmi *vc4_hdmi,
+ struct vc4_hdmi_connector_state *conn_state)
{
const struct phy_lane_settings *chan0_settings, *chan1_settings,
*chan2_settings, *clock_settings;
const struct vc4_hdmi_variant *variant = vc4_hdmi->variant;
- unsigned long long pixel_freq = mode->clock * 1000;
+ unsigned long long pixel_freq = conn_state->pixel_rate;
unsigned long long vco_freq;
unsigned char word_sel;
u8 vco_sel, vco_div;
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 0/6] Add Unisoc's drm kms module
ChangeList: RFC v1: 1. only upstream modeset and atomic at first commit. 2. remove some unused code; 3. use alpha and blend_mode properties; 3. add yaml support; 4. remove auto-adaptive panel driver; 5. bugfix RFC v2: 1. add sprd crtc and plane module for KMS, preparing for multi crtc&encoder 2. remove gem drivers, use generic CMA handlers 3. remove redundant "module_init", all the sub modules loading by KMS RFC v3: 1. multi crtc&encoder design have problem, so rollback to v1 RFC v4: 1. update to gcc-linaro-7.5.0 2. update to Linux 5.6-rc3 3. remove pm_runtime support 4. add COMPILE_TEST, remove unused kconfig 5. "drm_dev_put" on drm_unbind 6. fix some naming convention issue 7. remove semaphore lock for crtc flip 8. remove static variables RFC v5: 1. optimize encoder and connector code implementation 2. use "platform_get_irq" and "platform_get_resource" 3. drop useless function return type, drop unless debug log 4. custom properties should be separate, so drop it 5. use DRM_XXX replase pr_xxx 6. drop dsi&dphy hal callback ops 7. drop unless callback ops checking 8. add comments for sprd dpu structure RFC v6: 1. Access registers via readl/writel 2. Checking for unsupported KMS properties (format, rotation, blend_mode, etc) on plane_check ops 3. Remove always true checks for dpu core ops RFC v7: 1. Fix DTC unit name warnings 2. Fix the problem of maintainers 3. Call drmm_mode_config_init to mode config init 4. Embed drm_device in sprd_drm and use devm_drm_dev_alloc 5. Replace DRM_XXX with drm_xxx on KMS module, but not suitable for other subsystems 6. Remove plane_update stuff, dpu handles all the HW update in crtc->atomic_flush 7. Dsi&Dphy Code structure adjustment, all move to "sprd/" v0: 1. Remove dpu_core_ops stuff layer for sprd drtc driver, but dpu_layer need to keeping. Because all the HW update in crtc->atomic_flush, we need temporary storage all layers for the dpu pageflip of atomic_flush. 2. Add ports subnode with port@X. v1: 1. Remove dphy and dsi graph binding, merge the dphy driver into the dsi. 2. Add commit messages for Unisoc's virtual nodes. Kevin Tang (6): dt-bindings: display: add Unisoc's drm master bindings drm/sprd: add Unisoc's drm kms master dt-bindings: display: add Unisoc's dpu bindings drm/sprd: add Unisoc's drm display controller driver dt-bindings: display: add Unisoc's mipi dsi controller bindings drm/sprd: add Unisoc's drm mipi dsi&dphy driver .../display/sprd/sprd,display-subsystem.yaml | 64 + .../bindings/display/sprd/sprd,sharkl3-dpu.yaml| 83 ++ .../display/sprd/sprd,sharkl3-dsi-host.yaml| 107 ++ drivers/gpu/drm/Kconfig|2 + drivers/gpu/drm/Makefile |1 + drivers/gpu/drm/sprd/Kconfig | 13 + drivers/gpu/drm/sprd/Makefile | 11 + drivers/gpu/drm/sprd/dpu_r2p0.c| 598 drivers/gpu/drm/sprd/dw_dsi_ctrl.c | 792 +++ drivers/gpu/drm/sprd/dw_dsi_ctrl.h | 1475 drivers/gpu/drm/sprd/dw_dsi_ctrl_ppi.c | 275 drivers/gpu/drm/sprd/dw_dsi_ctrl_ppi.h | 34 + drivers/gpu/drm/sprd/megacores_pll.c | 316 + drivers/gpu/drm/sprd/megacores_pll.h | 146 ++ drivers/gpu/drm/sprd/sprd_dpu.c| 457 ++ drivers/gpu/drm/sprd/sprd_dpu.h| 175 +++ drivers/gpu/drm/sprd/sprd_drm.c| 224 +++ drivers/gpu/drm/sprd/sprd_drm.h| 19 + drivers/gpu/drm/sprd/sprd_dsi.c| 1145 +++ drivers/gpu/drm/sprd/sprd_dsi.h| 106 ++ 20 files changed, 6043 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/sprd/sprd,display-subsystem.yaml create mode 100644 Documentation/devicetree/bindings/display/sprd/sprd,sharkl3-dpu.yaml create mode 100644 Documentation/devicetree/bindings/display/sprd/sprd,sharkl3-dsi-host.yaml create mode 100644 drivers/gpu/drm/sprd/Kconfig create mode 100644 drivers/gpu/drm/sprd/Makefile create mode 100644 drivers/gpu/drm/sprd/dpu_r2p0.c create mode 100644 drivers/gpu/drm/sprd/dw_dsi_ctrl.c create mode 100644 drivers/gpu/drm/sprd/dw_dsi_ctrl.h create mode 100644 drivers/gpu/drm/sprd/dw_dsi_ctrl_ppi.c create mode 100644 drivers/gpu/drm/sprd/dw_dsi_ctrl_ppi.h create mode 100644 drivers/gpu/drm/sprd/megacores_pll.c create mode 100644 drivers/gpu/drm/sprd/megacores_pll.h create mode 100644 drivers/gpu/drm/sprd/sprd_dpu.c create mode 100644 drivers/gpu/drm/sprd/sprd_dpu.h create mode 100644 drivers/gpu/drm/sprd/sprd_drm.c create mode 100644 drivers/gpu/drm/sprd/sprd_drm.h create mode 100644 drivers/gpu/drm/sprd/sprd_dsi.c create mode 100644 drivers/gpu/drm/sprd/sprd_dsi.h -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freede
[PATCH v4 2/8] drm/vc4: Pass the atomic state to encoder hooks
We'll need to access the connector state in our encoder setup, so let's
just pass the whole DRM state to our private encoder hooks.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_crtc.c | 18 ++
drivers/gpu/drm/vc4/vc4_drv.h | 10 +-
drivers/gpu/drm/vc4/vc4_hdmi.c | 15 ++-
3 files changed, 25 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
index e02e499885ed..a3439756594c 100644
--- a/drivers/gpu/drm/vc4/vc4_crtc.c
+++ b/drivers/gpu/drm/vc4/vc4_crtc.c
@@ -403,7 +403,9 @@ static void require_hvs_enabled(struct drm_device *dev)
SCALER_DISPCTRL_ENABLE);
}
-static int vc4_crtc_disable(struct drm_crtc *crtc, unsigned int channel)
+static int vc4_crtc_disable(struct drm_crtc *crtc,
+ struct drm_atomic_state *state,
+ unsigned int channel)
{
struct drm_encoder *encoder = vc4_get_crtc_encoder(crtc);
struct vc4_encoder *vc4_encoder = to_vc4_encoder(encoder);
@@ -435,13 +437,13 @@ static int vc4_crtc_disable(struct drm_crtc *crtc,
unsigned int channel)
mdelay(20);
if (vc4_encoder && vc4_encoder->post_crtc_disable)
- vc4_encoder->post_crtc_disable(encoder);
+ vc4_encoder->post_crtc_disable(encoder, state);
vc4_crtc_pixelvalve_reset(crtc);
vc4_hvs_stop_channel(dev, channel);
if (vc4_encoder && vc4_encoder->post_crtc_powerdown)
- vc4_encoder->post_crtc_powerdown(encoder);
+ vc4_encoder->post_crtc_powerdown(encoder, state);
return 0;
}
@@ -468,7 +470,7 @@ int vc4_crtc_disable_at_boot(struct drm_crtc *crtc)
if (channel < 0)
return 0;
- return vc4_crtc_disable(crtc, channel);
+ return vc4_crtc_disable(crtc, NULL, channel);
}
static void vc4_crtc_atomic_disable(struct drm_crtc *crtc,
@@ -484,7 +486,7 @@ static void vc4_crtc_atomic_disable(struct drm_crtc *crtc,
/* Disable vblank irq handling before crtc is disabled. */
drm_crtc_vblank_off(crtc);
- vc4_crtc_disable(crtc, old_vc4_state->assigned_channel);
+ vc4_crtc_disable(crtc, state, old_vc4_state->assigned_channel);
/*
* Make sure we issue a vblank event after disabling the CRTC if
@@ -518,14 +520,14 @@ static void vc4_crtc_atomic_enable(struct drm_crtc *crtc,
vc4_hvs_atomic_enable(crtc, state);
if (vc4_encoder->pre_crtc_configure)
- vc4_encoder->pre_crtc_configure(encoder);
+ vc4_encoder->pre_crtc_configure(encoder, state);
vc4_crtc_config_pv(crtc);
CRTC_WRITE(PV_CONTROL, CRTC_READ(PV_CONTROL) | PV_CONTROL_EN);
if (vc4_encoder->pre_crtc_enable)
- vc4_encoder->pre_crtc_enable(encoder);
+ vc4_encoder->pre_crtc_enable(encoder, state);
/* When feeding the transposer block the pixelvalve is unneeded and
* should not be enabled.
@@ -534,7 +536,7 @@ static void vc4_crtc_atomic_enable(struct drm_crtc *crtc,
CRTC_READ(PV_V_CONTROL) | PV_VCONTROL_VIDEN);
if (vc4_encoder->post_crtc_enable)
- vc4_encoder->post_crtc_enable(encoder);
+ vc4_encoder->post_crtc_enable(encoder, state);
}
static enum drm_mode_status vc4_crtc_mode_valid(struct drm_crtc *crtc,
diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
index c47c85533805..b404cd3ab0d8 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.h
+++ b/drivers/gpu/drm/vc4/vc4_drv.h
@@ -444,12 +444,12 @@ struct vc4_encoder {
enum vc4_encoder_type type;
u32 clock_select;
- void (*pre_crtc_configure)(struct drm_encoder *encoder);
- void (*pre_crtc_enable)(struct drm_encoder *encoder);
- void (*post_crtc_enable)(struct drm_encoder *encoder);
+ void (*pre_crtc_configure)(struct drm_encoder *encoder, struct
drm_atomic_state *state);
+ void (*pre_crtc_enable)(struct drm_encoder *encoder, struct
drm_atomic_state *state);
+ void (*post_crtc_enable)(struct drm_encoder *encoder, struct
drm_atomic_state *state);
- void (*post_crtc_disable)(struct drm_encoder *encoder);
- void (*post_crtc_powerdown)(struct drm_encoder *encoder);
+ void (*post_crtc_disable)(struct drm_encoder *encoder, struct
drm_atomic_state *state);
+ void (*post_crtc_powerdown)(struct drm_encoder *encoder, struct
drm_atomic_state *state);
};
static inline struct vc4_encoder *
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index afc178b0d89f..5a608ed1d75e 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -357,7 +357,8 @@ static void vc4_hdmi_set_infoframes(struct drm_encoder
*encoder)
vc4_hdmi_set_audio_infoframe(encoder);
}
-static void vc4_hdmi_encoder_post_crtc_disable(struct drm_encoder *encoder)
+static void vc4_hdmi
Re: [PATCH] drm: drm_basic_types.h, DRM_FOURCC_STANDALONE
Create drm_basic_types.h to define types previously defined by drm.h. Use DRM_FOURCC_STANDALONE to include drm_fourcc.h without drm.h. This will allow Mesa to port code to Windows more easily. Signed-off-by: James Park James Park (1): drm: drm_basic_types.h, DRM_FOURCC_STANDALONE include/uapi/drm/drm.h | 12 ++--- include/uapi/drm/drm_basic_types.h | 52 ++ include/uapi/drm/drm_fourcc.h | 4 +++ 3 files changed, 58 insertions(+), 10 deletions(-) create mode 100644 include/uapi/drm/drm_basic_types.h -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 6/9] drm/vc4: hdmi: Store pixel frequency in the connector state
The pixel rate is for now quite simple to compute, but with more features
(30 and 36 bits output, YUV output, etc.) will depend on a bunch of
connectors properties.
Let's store the rate we have to run the pixel clock at in our custom
connector state, and compute it in atomic_check.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 26 +-
drivers/gpu/drm/vc4/vc4_hdmi.h | 1 +
2 files changed, 26 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index 744396c8dcb9..83699105c7a5 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -194,6 +194,7 @@ vc4_hdmi_connector_duplicate_state(struct drm_connector
*connector)
if (!new_state)
return NULL;
+ new_state->pixel_rate = vc4_state->pixel_rate;
__drm_atomic_helper_connector_duplicate_state(connector,
&new_state->base);
return &new_state->base;
@@ -611,9 +612,29 @@ static void vc4_hdmi_recenter_fifo(struct vc4_hdmi
*vc4_hdmi)
"VC4_HDMI_FIFO_CTL_RECENTER_DONE");
}
+static struct drm_connector_state *
+vc4_hdmi_encoder_get_connector_state(struct drm_encoder *encoder,
+struct drm_atomic_state *state)
+{
+ struct drm_connector_state *conn_state;
+ struct drm_connector *connector;
+ unsigned int i;
+
+ for_each_new_connector_in_state(state, connector, conn_state, i) {
+ if (conn_state->best_encoder == encoder)
+ return conn_state;
+ }
+
+ return NULL;
+}
+
static void vc4_hdmi_encoder_pre_crtc_configure(struct drm_encoder *encoder,
struct drm_atomic_state *state)
{
+ struct drm_connector_state *conn_state =
+ vc4_hdmi_encoder_get_connector_state(encoder, state);
+ struct vc4_hdmi_connector_state *vc4_conn_state =
+ conn_state_to_vc4_hdmi_conn_state(conn_state);
struct drm_display_mode *mode = &encoder->crtc->state->adjusted_mode;
struct vc4_hdmi *vc4_hdmi = encoder_to_vc4_hdmi(encoder);
unsigned long pixel_rate, hsm_rate;
@@ -625,7 +646,7 @@ static void vc4_hdmi_encoder_pre_crtc_configure(struct
drm_encoder *encoder,
return;
}
- pixel_rate = mode->clock * 1000 * ((mode->flags & DRM_MODE_FLAG_DBLCLK)
? 2 : 1);
+ pixel_rate = vc4_conn_state->pixel_rate;
ret = clk_set_rate(vc4_hdmi->pixel_clock, pixel_rate);
if (ret) {
DRM_ERROR("Failed to set pixel clock rate: %d\n", ret);
@@ -797,6 +818,7 @@ static int vc4_hdmi_encoder_atomic_check(struct drm_encoder
*encoder,
struct drm_crtc_state *crtc_state,
struct drm_connector_state *conn_state)
{
+ struct vc4_hdmi_connector_state *vc4_state =
conn_state_to_vc4_hdmi_conn_state(conn_state);
struct drm_display_mode *mode = &crtc_state->adjusted_mode;
struct vc4_hdmi *vc4_hdmi = encoder_to_vc4_hdmi(encoder);
unsigned long long pixel_rate = mode->clock * 1000;
@@ -827,6 +849,8 @@ static int vc4_hdmi_encoder_atomic_check(struct drm_encoder
*encoder,
if (pixel_rate > vc4_hdmi->variant->max_pixel_clock)
return -EINVAL;
+ vc4_state->pixel_rate = pixel_rate;
+
return 0;
}
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.h b/drivers/gpu/drm/vc4/vc4_hdmi.h
index 2cf5362052e2..bca6943de884 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.h
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.h
@@ -182,6 +182,7 @@ encoder_to_vc4_hdmi(struct drm_encoder *encoder)
struct vc4_hdmi_connector_state {
struct drm_connector_state base;
+ unsigned long long pixel_rate;
};
static inline struct vc4_hdmi_connector_state *
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 1/8] drm/vc4: hvs: Align the HVS atomic hooks to the new API
Since the CRTC setup in vc4 is split between the PixelValves/TXP and the
HVS, only the PV/TXP atomic hooks were updated in the previous commits, but
it makes sense to update the HVS ones too.
Reviewed-by: Thomas Zimmermann
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_crtc.c | 4 +---
drivers/gpu/drm/vc4/vc4_drv.h | 4 ++--
drivers/gpu/drm/vc4/vc4_hvs.c | 8 +---
drivers/gpu/drm/vc4/vc4_txp.c | 8 ++--
4 files changed, 10 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
index 06088854c647..e02e499885ed 100644
--- a/drivers/gpu/drm/vc4/vc4_crtc.c
+++ b/drivers/gpu/drm/vc4/vc4_crtc.c
@@ -503,8 +503,6 @@ static void vc4_crtc_atomic_disable(struct drm_crtc *crtc,
static void vc4_crtc_atomic_enable(struct drm_crtc *crtc,
struct drm_atomic_state *state)
{
- struct drm_crtc_state *old_state = drm_atomic_get_old_crtc_state(state,
-crtc);
struct drm_device *dev = crtc->dev;
struct vc4_crtc *vc4_crtc = to_vc4_crtc(crtc);
struct drm_encoder *encoder = vc4_get_crtc_encoder(crtc);
@@ -517,7 +515,7 @@ static void vc4_crtc_atomic_enable(struct drm_crtc *crtc,
*/
drm_crtc_vblank_on(crtc);
- vc4_hvs_atomic_enable(crtc, old_state);
+ vc4_hvs_atomic_enable(crtc, state);
if (vc4_encoder->pre_crtc_configure)
vc4_encoder->pre_crtc_configure(encoder);
diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
index c5f2944d5bc6..c47c85533805 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.h
+++ b/drivers/gpu/drm/vc4/vc4_drv.h
@@ -918,8 +918,8 @@ extern struct platform_driver vc4_hvs_driver;
void vc4_hvs_stop_channel(struct drm_device *dev, unsigned int output);
int vc4_hvs_get_fifo_from_output(struct drm_device *dev, unsigned int output);
int vc4_hvs_atomic_check(struct drm_crtc *crtc, struct drm_crtc_state *state);
-void vc4_hvs_atomic_enable(struct drm_crtc *crtc, struct drm_crtc_state
*old_state);
-void vc4_hvs_atomic_disable(struct drm_crtc *crtc, struct drm_crtc_state
*old_state);
+void vc4_hvs_atomic_enable(struct drm_crtc *crtc, struct drm_atomic_state
*state);
+void vc4_hvs_atomic_disable(struct drm_crtc *crtc, struct drm_atomic_state
*state);
void vc4_hvs_atomic_flush(struct drm_crtc *crtc, struct drm_crtc_state *state);
void vc4_hvs_dump_state(struct drm_device *dev);
void vc4_hvs_unmask_underrun(struct drm_device *dev, int channel);
diff --git a/drivers/gpu/drm/vc4/vc4_hvs.c b/drivers/gpu/drm/vc4/vc4_hvs.c
index b72b2bd05a81..04396dec63fc 100644
--- a/drivers/gpu/drm/vc4/vc4_hvs.c
+++ b/drivers/gpu/drm/vc4/vc4_hvs.c
@@ -391,11 +391,12 @@ static void vc4_hvs_update_dlist(struct drm_crtc *crtc)
}
void vc4_hvs_atomic_enable(struct drm_crtc *crtc,
- struct drm_crtc_state *old_state)
+ struct drm_atomic_state *state)
{
struct drm_device *dev = crtc->dev;
struct vc4_dev *vc4 = to_vc4_dev(dev);
- struct vc4_crtc_state *vc4_state = to_vc4_crtc_state(crtc->state);
+ struct drm_crtc_state *new_crtc_state =
drm_atomic_get_new_crtc_state(state, crtc);
+ struct vc4_crtc_state *vc4_state = to_vc4_crtc_state(new_crtc_state);
struct drm_display_mode *mode = &crtc->state->adjusted_mode;
bool oneshot = vc4_state->feed_txp;
@@ -404,9 +405,10 @@ void vc4_hvs_atomic_enable(struct drm_crtc *crtc,
}
void vc4_hvs_atomic_disable(struct drm_crtc *crtc,
- struct drm_crtc_state *old_state)
+ struct drm_atomic_state *state)
{
struct drm_device *dev = crtc->dev;
+ struct drm_crtc_state *old_state = drm_atomic_get_old_crtc_state(state,
crtc);
struct vc4_crtc_state *vc4_state = to_vc4_crtc_state(old_state);
unsigned int chan = vc4_state->assigned_channel;
diff --git a/drivers/gpu/drm/vc4/vc4_txp.c b/drivers/gpu/drm/vc4/vc4_txp.c
index 34612edcabbd..4a26750b5e93 100644
--- a/drivers/gpu/drm/vc4/vc4_txp.c
+++ b/drivers/gpu/drm/vc4/vc4_txp.c
@@ -406,23 +406,19 @@ static int vc4_txp_atomic_check(struct drm_crtc *crtc,
static void vc4_txp_atomic_enable(struct drm_crtc *crtc,
struct drm_atomic_state *state)
{
- struct drm_crtc_state *old_state = drm_atomic_get_old_crtc_state(state,
-crtc);
drm_crtc_vblank_on(crtc);
- vc4_hvs_atomic_enable(crtc, old_state);
+ vc4_hvs_atomic_enable(crtc, state);
}
static void vc4_txp_atomic_disable(struct drm_crtc *crtc,
struct drm_atomic_state *state)
{
- struct drm_crtc_state *old_state = drm_atomic_get_old_crtc_state(state,
-crtc);
struct drm_device *dev = crtc->dev;
Re: [PATCH v2] drm/vc4: hdmi: Don't poll for the infoframes status on setup
On Fri, Dec 04, 2020 at 03:36:11PM +, Dave Stevenson wrote: > Hi Maxime > > On Thu, 3 Dec 2020 at 07:46, Maxime Ripard wrote: > > > > The infoframes are sent at a regular interval as a data island packet, > > so we don't need to wait for them to be sent when we're setting them up. > > > > However, we do need to poll when we're enabling since the we can't > > update the packet RAM until it has been sent. > > > > Let's add a boolean flag to tell whether we want to poll or not to > > support both cases. > > > > Suggested-by: Dave Stevenson > > Signed-off-by: Maxime Ripard > > That looks like it should do what was intended - thanks. > > Reviewed-by: Dave Stevenson Applied, thanks! Maxime signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 07/11] dt-bindings: phy: convert MIP DSI PHY binding to YAML schema
On Mon, 2020-12-07 at 15:19 -0600, Rob Herring wrote:
> On Wed, Nov 18, 2020 at 04:21:22PM +0800, Chunfeng Yun wrote:
> > Convert MIPI DSI PHY binding to YAML schema mediatek,dsi-phy.yaml
> >
> > Cc: Chun-Kuang Hu
> > Signed-off-by: Chunfeng Yun
> > ---
> > v3: new patch
> > ---
> > .../display/mediatek/mediatek,dsi.txt | 18 +---
> > .../bindings/phy/mediatek,dsi-phy.yaml| 83 +++
> > 2 files changed, 84 insertions(+), 17 deletions(-)
> > create mode 100644
> > Documentation/devicetree/bindings/phy/mediatek,dsi-phy.yaml
> >
> > diff --git
> > a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt
> > b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt
> > index f06f24d405a5..8238a86686be 100644
> > --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt
> > +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt
> > @@ -22,23 +22,7 @@ Required properties:
> > MIPI TX Configuration Module
> >
> >
> > -The MIPI TX configuration module controls the MIPI D-PHY.
> > -
> > -Required properties:
> > -- compatible: "mediatek,-mipi-tx"
> > -- the supported chips are mt2701, 7623, mt8173 and mt8183.
> > -- reg: Physical base address and length of the controller's registers
> > -- clocks: PLL reference clock
> > -- clock-output-names: name of the output clock line to the DSI encoder
> > -- #clock-cells: must be <0>;
> > -- #phy-cells: must be <0>.
> > -
> > -Optional properties:
> > -- drive-strength-microamp: adjust driving current, should be 3000 ~ 6000.
> > And
> > - the step is 200.
> > -- nvmem-cells: A phandle to the calibration data provided by a nvmem
> > device. If
> > - unspecified default values shall be used.
> > -- nvmem-cell-names: Should be "calibration-data"
> > +See phy/mediatek,dsi-phy.yaml
> >
> > Example:
> >
> > diff --git a/Documentation/devicetree/bindings/phy/mediatek,dsi-phy.yaml
> > b/Documentation/devicetree/bindings/phy/mediatek,dsi-phy.yaml
> > new file mode 100644
> > index ..87f8df251ab0
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/phy/mediatek,dsi-phy.yaml
> > @@ -0,0 +1,83 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +# Copyright (c) 2020 MediaTek
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/phy/mediatek,dsi-phy.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: MediaTek MIPI Display Serial Interface (DSI) PHY binding
> > +
> > +maintainers:
> > + - Chun-Kuang Hu
> > + - Chunfeng Yun
> > +
> > +description: The MIPI DSI PHY supports up to 4-lane output.
> > +
> > +properties:
> > + $nodename:
> > +pattern: "^dsi-phy@[0-9a-f]+$"
> > +
> > + compatible:
> > +enum:
> > + - mediatek,mt2701-mipi-tx
> > + - mediatek,mt7623-mipi-tx
> > + - mediatek,mt8173-mipi-tx
> > +
> > + reg:
> > +maxItems: 1
> > +
> > + clocks:
> > +items:
> > + - description: PLL reference clock
> > +
> > + clock-output-names:
> > +maxItems: 1
> > +
> > + "#phy-cells":
> > +const: 0
> > +
> > + "#clock-cells":
> > +const: 0
> > +
> > + nvmem-cells:
> > +maxItems: 1
> > +description: A phandle to the calibration data provided by a nvmem
> > device,
> > + if unspecified, default values shall be used.
> > +
> > + nvmem-cell-names:
> > +items:
> > + - const: calibration-data
> > +
> > + drive-strength-microamp:
> > +description: adjust driving current, the step is 200.
>
> multipleOf: 200
Got it.
>
> > +$ref: /schemas/types.yaml#/definitions/uint32
>
> Can drop. Standard unit suffixes have a type already.
Ok, thanks a lot
>
> > +minimum: 2000
> > +maximum: 6000
> > +default: 4600
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - clocks
> > + - clock-output-names
> > + - "#phy-cells"
> > + - "#clock-cells"
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > + - |
> > +#include
> > +dsi-phy@10215000 {
> > +compatible = "mediatek,mt8173-mipi-tx";
> > +reg = <0x10215000 0x1000>;
> > +clocks = <&clk26m>;
> > +clock-output-names = "mipi_tx0_pll";
> > +drive-strength-microamp = <4000>;
> > +nvmem-cells= <&mipi_tx_calibration>;
> > +nvmem-cell-names = "calibration-data";
> > +#clock-cells = <0>;
> > +#phy-cells = <0>;
> > +};
> > +
> > +...
> > --
> > 2.18.0
> >
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Fix drm.h uapi header for Windows
I updated the patch earlier today incorporating the suggestions. I also had
to bring back "#include " to drm.h because there's some
sanity check that fails, as if it doesn't scan past the first level of
#includes..
- James
On Mon, Dec 7, 2020 at 3:14 AM Pekka Paalanen wrote:
> On Mon, 07 Dec 2020 10:53:49 +
> Simon Ser wrote:
>
> > On Monday, December 7th, 2020 at 11:49 AM, James Park <
> james.p...@lagfreegames.com> wrote:
> >
> > > That would work, but that's kind of an annoying requirement. I would
> > > prefer the header to be self-sufficient.
> >
> > I don't want to make it more confusing than before, but here Pekka (I
> > think) suggests to replace this:
> >
> > diff --git a/include/uapi/drm/drm_fourcc.h
> b/include/uapi/drm/drm_fourcc.h
> > index 82f3278..5eb07a5 100644
> > --- a/include/uapi/drm/drm_fourcc.h
> > +++ b/include/uapi/drm/drm_fourcc.h
> > @@ -24,7 +24,11 @@
> > #ifndef DRM_FOURCC_H
> > #define DRM_FOURCC_H
> >
> > +#ifdef DRM_FOURCC_STANDALONE
> > +#include "drm_basic_types.h"
> > +#else
> > #include "drm.h"
> > +#endif
> >
> > #if defined(__cplusplus)
> > extern "C" {
> >
> > With this:
> >
> > diff --git a/include/uapi/drm/drm_fourcc.h
> b/include/uapi/drm/drm_fourcc.h
> > index 82f3278..5eb07a5 100644
> > --- a/include/uapi/drm/drm_fourcc.h
> > +++ b/include/uapi/drm/drm_fourcc.h
> > @@ -24,7 +24,11 @@
> > #ifndef DRM_FOURCC_H
> > #define DRM_FOURCC_H
> >
> > +#include "drm_basic_types.h"
> > +
> > +#ifndef DRM_FOURCC_STANDALONE
> > #include "drm.h"
> > +#endif
> >
> > #if defined(__cplusplus)
> > extern "C" {
> >
> > That wouldn't change whether the header is self-sufficient or not,
> > would it?
>
> Exactly this.
>
> This communicates properly that DRM_FOURCC_STANDALONE only affects
> whether drm.h gets pulled in or not, and there are no other effects.
>
> This also makes testing better: when you unconditionally include
> drm_basic_types.h, you are more likely to catch breakage there.
>
> For functionality, it makes no difference. Whether userspace does
>
> #include "drm.h"
> #define DRM_FOURCC_STANDALONE
> #include "drm_fourcc.h"
>
> or
>
> #define DRM_FOURCC_STANDALONE
> #include "drm_fourcc.h"
> #include "drm.h"
>
> the result must always be good.
>
>
> Thanks,
> pq
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: (subset) [PATCH 000/141] Fix fall-through warnings for Clang
On Fri, 20 Nov 2020 12:21:39 -0600, Gustavo A. R. Silva wrote: > This series aims to fix almost all remaining fall-through warnings in > order to enable -Wimplicit-fallthrough for Clang. > > In preparation to enable -Wimplicit-fallthrough for Clang, explicitly > add multiple break/goto/return/fallthrough statements instead of just > letting the code fall through to the next case. > > [...] Applied to 5.11/scsi-queue, thanks! [054/141] target: Fix fall-through warnings for Clang https://git.kernel.org/mkp/scsi/c/492096ecfa39 -- Martin K. Petersen Oracle Linux Engineering ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH drm/hisilicon v2 2/2] drm/hisilicon: Delete unused local parameters
delete unused variable ‘priv’ to avoid warning.
Signed-off-by: Tian Tao
Reviewed-by: Thomas Zimmermann
---
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
index 7f01213..7e91ef1 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
@@ -250,12 +250,9 @@ static int hibmc_hw_init(struct hibmc_drm_private *priv)
static int hibmc_unload(struct drm_device *dev)
{
- struct hibmc_drm_private *priv = to_hibmc_drm_private(dev);
-
drm_atomic_helper_shutdown(dev);
-
pci_disable_msi(dev->pdev);
- dev->dev_private = NULL;
+
return 0;
}
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 8/9] drm/vc4: hdmi: Limit the BCM2711 to the max without scrambling
Unlike the previous generations, the HSM clock limitation is way above
what we can reach without scrambling, so let's move the maximum
frequency we support to the maximum clock frequency without scrambling.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index 5310e06efc82..f4ff6b5db484 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -82,6 +82,8 @@
#define CEC_CLOCK_FREQ 4
#define VC4_HSM_MID_CLOCK 149985000
+#define HDMI_14_MAX_TMDS_CLK (340 * 1000 * 1000)
+
static int vc4_hdmi_debugfs_regs(struct seq_file *m, void *unused)
{
struct drm_info_node *node = (struct drm_info_node *)m->private;
@@ -1911,7 +1913,7 @@ static const struct vc4_hdmi_variant
bcm2711_hdmi0_variant = {
.encoder_type = VC4_ENCODER_TYPE_HDMI0,
.debugfs_name = "hdmi0_regs",
.card_name = "vc4-hdmi-0",
- .max_pixel_clock= 29700,
+ .max_pixel_clock= HDMI_14_MAX_TMDS_CLK,
.registers = vc5_hdmi_hdmi0_fields,
.num_registers = ARRAY_SIZE(vc5_hdmi_hdmi0_fields),
.phy_lane_mapping = {
@@ -1937,7 +1939,7 @@ static const struct vc4_hdmi_variant
bcm2711_hdmi1_variant = {
.encoder_type = VC4_ENCODER_TYPE_HDMI1,
.debugfs_name = "hdmi1_regs",
.card_name = "vc4-hdmi-1",
- .max_pixel_clock= 29700,
+ .max_pixel_clock= HDMI_14_MAX_TMDS_CLK,
.registers = vc5_hdmi_hdmi1_fields,
.num_registers = ARRAY_SIZE(vc5_hdmi_hdmi1_fields),
.phy_lane_mapping = {
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 3/9] drm/vc4: hdmi: Take into account the clock doubling flag in atomic_check
Reported-by: Thomas Zimmermann
Fixes: 63495f6b4aed ("drm/vc4: hdmi: Make sure our clock rate is within limits")
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index 5a608ed1d75e..a88aa20beeb6 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -796,6 +796,9 @@ static int vc4_hdmi_encoder_atomic_check(struct drm_encoder
*encoder,
pixel_rate = mode->clock * 1000;
}
+ if (mode->flags & DRM_MODE_FLAG_DBLCLK)
+ pixel_rate = pixel_rate * 2;
+
if (pixel_rate > vc4_hdmi->variant->max_pixel_clock)
return -EINVAL;
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 3/4] tpm_tis: Disable interrupts if interrupt storm detected
On Sun, Dec 06, 2020 at 08:26:16PM +0100, Thomas Gleixner wrote: > Just as a side note. I was looking at tpm_tis_probe_irq_single() and > that function is leaking the interrupt request if any of the checks > afterwards fails, except for the final interrupt probe check which does > a cleanup. That means on fail before that the interrupt handler stays > requested up to the point where the module is removed. If that's a > shared interrupt and some other device is active on the same line, then > each interrupt from that device will call into the TPM code. Something > like the below is needed. > > Also the X86 autoprobe mechanism is interesting: > > if (IS_ENABLED(CONFIG_X86)) > for (i = 3; i <= 15; i++) > if (!tpm_tis_probe_irq_single(chip, intmask, 0, i)) > return; > > The third argument is 'flags' which is handed to request_irq(). So that > won't ever be able to probe a shared interrupt. But if an interrupt > number > 0 is handed to tpm_tis_core_init() the interrupt is requested > with IRQF_SHARED. Same issue when the chip has an interrupt number in > the register. It's also requested exclusive which is pretty likely > to fail on ancient x86 machines. It is very likely none of this works any more, it has been repeatedly reworked over the years and just left behind out of fear someone needs it. I've thought it should be deleted for a while now. I suppose the original logic was to try and probe without SHARED because a probe would need exclusive access to the interrupt to tell if the TPM was actually the source, not some other device. It is all very old and very out of step with current thinking, IMHO. I skeptical that TPM interrupts were ever valuable enough to deserve this in the first place. Jason ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 3/8] drm/vc4: hdmi: Don't access the connector state in reset if kmalloc fails
drm_atomic_helper_connector_reset uses kmalloc which, from an API
standpoint, can fail, and thus setting connector->state to NULL.
However, our reset hook then calls drm_atomic_helper_connector_tv_reset
that will access connector->state without checking if it's a valid
pointer or not.
Make sure we don't end up accessing a NULL pointer.
Suggested-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index 5a608ed1d75e..112c09873eb4 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -171,7 +171,9 @@ static int vc4_hdmi_connector_get_modes(struct
drm_connector *connector)
static void vc4_hdmi_connector_reset(struct drm_connector *connector)
{
drm_atomic_helper_connector_reset(connector);
- drm_atomic_helper_connector_tv_reset(connector);
+
+ if (connector->state)
+ drm_atomic_helper_connector_tv_reset(connector);
}
static const struct drm_connector_funcs vc4_hdmi_connector_funcs = {
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 02/13] video: fbdev: core: Fix kernel-doc warnings in fbmon + fb_notify
On 12/7/20 12:16 AM, Thomas Zimmermann wrote: > Hi > > Am 06.12.20 um 20:37 schrieb Randy Dunlap: >> On 12/6/20 11:02 AM, Sam Ravnborg wrote: >>> Fix kernel-doc warnings reported when using W=1 >>> >>> v2: >>> - Improve subject (Lee) >>> >>> v3: >>> - Add RETURNS documentation (Thomas) >> >> Hi Sam, >> >> Yes, RETURNS: will work. It just looks like any kernel-doc section name, >> such as Context: or Note:. >> However, the documented format for return info is "Return:". >> (see Documentation/doc-guide/kernel-doc.rst) > > Thanks for the note. I asked for RETURNS: because the rest of the file > appears to be using it. Returns: is certainly the better alternative. I > didn't know there was a difference. > > Best regards > Thomas > I'm not insisting on using Return: It can stay the same as the rest of the file IMO. >> >> >>> Signed-off-by: Sam Ravnborg >>> Cc: Lee Jones >>> Cc: Sam Ravnborg >>> Cc: Randy Dunlap >>> Cc: Bartlomiej Zolnierkiewicz >>> Cc: Daniel Vetter >>> Cc: "Alexander A. Klimov" >>> --- >>> drivers/video/fbdev/core/fb_notify.c | 10 ++ >>> drivers/video/fbdev/core/fbmon.c | 2 +- >>> 2 files changed, 11 insertions(+), 1 deletion(-) -- ~Randy ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 2/6] drm/sprd: add Unisoc's drm kms master
Adds drm support for the Unisoc's display subsystem.
This is drm kms driver, this driver provides support for the
application framework in Android, Yocto and more.
Application framework can access Unisoc's display internel
peripherals through libdrm or libkms, it's test ok by modetest
(DRM/KMS test tool) and Android HWComposer.
Cc: Orson Zhai
Cc: Chunyan Zhang
Signed-off-by: Kevin Tang
---
drivers/gpu/drm/Kconfig | 2 +
drivers/gpu/drm/Makefile| 1 +
drivers/gpu/drm/sprd/Kconfig| 12 +++
drivers/gpu/drm/sprd/Makefile | 5 +
drivers/gpu/drm/sprd/sprd_drm.c | 222
drivers/gpu/drm/sprd/sprd_drm.h | 16 +++
6 files changed, 258 insertions(+)
create mode 100644 drivers/gpu/drm/sprd/Kconfig
create mode 100644 drivers/gpu/drm/sprd/Makefile
create mode 100644 drivers/gpu/drm/sprd/sprd_drm.c
create mode 100644 drivers/gpu/drm/sprd/sprd_drm.h
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 147d61b..15b4e13 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -388,6 +388,8 @@ source "drivers/gpu/drm/tidss/Kconfig"
source "drivers/gpu/drm/xlnx/Kconfig"
+source "drivers/gpu/drm/sprd/Kconfig"
+
# Keep legacy drivers last
menuconfig DRM_LEGACY
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 8156900..d3001e7 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -124,3 +124,4 @@ obj-$(CONFIG_DRM_ASPEED_GFX) += aspeed/
obj-$(CONFIG_DRM_MCDE) += mcde/
obj-$(CONFIG_DRM_TIDSS) += tidss/
obj-y += xlnx/
+obj-$(CONFIG_DRM_SPRD) += sprd/
diff --git a/drivers/gpu/drm/sprd/Kconfig b/drivers/gpu/drm/sprd/Kconfig
new file mode 100644
index 000..6e80cc9
--- /dev/null
+++ b/drivers/gpu/drm/sprd/Kconfig
@@ -0,0 +1,12 @@
+config DRM_SPRD
+ tristate "DRM Support for Unisoc SoCs Platform"
+ depends on ARCH_SPRD || COMPILE_TEST
+ depends on DRM && OF
+ select DRM_KMS_HELPER
+ select DRM_GEM_CMA_HELPER
+ select DRM_KMS_CMA_HELPER
+ select DRM_MIPI_DSI
+ help
+ Choose this option if you have a Unisoc chipset.
+ If M is selected the module will be called sprd_drm.
+
diff --git a/drivers/gpu/drm/sprd/Makefile b/drivers/gpu/drm/sprd/Makefile
new file mode 100644
index 000..86d95d9
--- /dev/null
+++ b/drivers/gpu/drm/sprd/Makefile
@@ -0,0 +1,5 @@
+# SPDX-License-Identifier: GPL-2.0
+
+subdir-ccflags-y += -I$(srctree)/$(src)
+
+obj-y := sprd_drm.o
diff --git a/drivers/gpu/drm/sprd/sprd_drm.c b/drivers/gpu/drm/sprd/sprd_drm.c
new file mode 100644
index 000..ec101de
--- /dev/null
+++ b/drivers/gpu/drm/sprd/sprd_drm.c
@@ -0,0 +1,222 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2020 Unisoc Inc.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "sprd_drm.h"
+
+#define DRIVER_NAME"sprd"
+#define DRIVER_DESC"Spreadtrum SoCs' DRM Driver"
+#define DRIVER_DATE"20200201"
+#define DRIVER_MAJOR 1
+#define DRIVER_MINOR 0
+
+static const struct drm_mode_config_helper_funcs sprd_drm_mode_config_helper =
{
+ .atomic_commit_tail = drm_atomic_helper_commit_tail_rpm,
+};
+
+static const struct drm_mode_config_funcs sprd_drm_mode_config_funcs = {
+ .fb_create = drm_gem_fb_create,
+ .atomic_check = drm_atomic_helper_check,
+ .atomic_commit = drm_atomic_helper_commit,
+};
+
+static void sprd_drm_mode_config_init(struct drm_device *drm)
+{
+ drm->mode_config.min_width = 0;
+ drm->mode_config.min_height = 0;
+ drm->mode_config.max_width = 8192;
+ drm->mode_config.max_height = 8192;
+ drm->mode_config.allow_fb_modifiers = true;
+
+ drm->mode_config.funcs = &sprd_drm_mode_config_funcs;
+ drm->mode_config.helper_private = &sprd_drm_mode_config_helper;
+}
+
+DEFINE_DRM_GEM_CMA_FOPS(sprd_drm_fops);
+
+static struct drm_driver sprd_drm_drv = {
+ .driver_features= DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC,
+ .fops = &sprd_drm_fops,
+
+ /* GEM Operations */
+ DRM_GEM_CMA_DRIVER_OPS,
+
+ .name = DRIVER_NAME,
+ .desc = DRIVER_DESC,
+ .date = DRIVER_DATE,
+ .major = DRIVER_MAJOR,
+ .minor = DRIVER_MINOR,
+};
+
+static int sprd_drm_bind(struct device *dev)
+{
+ struct drm_device *drm = dev_get_drvdata(dev);
+ int ret;
+
+ ret = drmm_mode_config_init(drm);
+ if (ret)
+ return ret;
+
+ sprd_drm_mode_config_init(drm);
+
+ /* bind and init sub drivers */
+ ret = component_bind_all(drm->dev, drm);
+ if (ret) {
+ drm_err(drm, "failed to bind all component.\n");
+ goto err_dc_cleanup;
+ }
+
+ /* vblank init */
+ ret = drm_vblank_init(dr
[PATCH v1 5/6] dt-bindings: display: add Unisoc's mipi dsi controller bindings
From: Kevin Tang
Adds MIPI DSI Controller
support for Unisoc's display subsystem.
Cc: Orson Zhai
Cc: Chunyan Zhang
Signed-off-by: Kevin Tang
---
.../display/sprd/sprd,sharkl3-dsi-host.yaml| 107 +
1 file changed, 107 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/sprd/sprd,sharkl3-dsi-host.yaml
diff --git
a/Documentation/devicetree/bindings/display/sprd/sprd,sharkl3-dsi-host.yaml
b/Documentation/devicetree/bindings/display/sprd/sprd,sharkl3-dsi-host.yaml
new file mode 100644
index 000..f7ee6b2
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/sprd/sprd,sharkl3-dsi-host.yaml
@@ -0,0 +1,107 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/sprd/sprd,sharkl3-dsi-host.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Unisoc MIPI DSI Controller
+
+maintainers:
+ - Kevin Tang
+
+properties:
+ compatible:
+const: sprd,sharkl3-dsi-host
+
+ reg:
+maxItems: 1
+description:
+ Physical base address and length of the registers set for the device.
+
+ interrupts:
+maxItems: 2
+description:
+ Should contain DSI interrupt.
+
+ clocks:
+minItems: 1
+
+ clock-names:
+items:
+ - const: clk_src_96m
+
+ power-domains:
+maxItems: 1
+description: A phandle to DSIM power domain node
+
+ ports:
+type: object
+
+properties:
+ "#address-cells":
+const: 1
+
+ "#size-cells":
+const: 0
+
+ port@0:
+type: object
+description:
+ A port node with endpoint definitions as defined in
+ Documentation/devicetree/bindings/media/video-interfaces.txt.
+ That port should be the input endpoint, usually coming from
+ the associated DPU.
+ port@1:
+type: object
+description:
+ A port node with endpoint definitions as defined in
+ Documentation/devicetree/bindings/media/video-interfaces.txt.
+ That port should be the output endpoint, usually output to
+ the associated panel.
+
+required:
+ - "#address-cells"
+ - "#size-cells"
+ - port@0
+ - port@1
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+dsi: dsi@6310 {
+compatible = "sprd,sharkl3-dsi-host";
+reg = <0x6310 0x1000>;
+interrupts = ,
+ ;
+clock-names = "clk_src_96m";
+clocks = <&pll CLK_TWPLL_96M>;
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+port@0 {
+reg = <0>;
+dsi_in: endpoint {
+remote-endpoint = <&dpu_out>;
+};
+};
+port@1 {
+reg = <1>;
+dsi_out: endpoint {
+remote-endpoint = <&panel_in>;
+};
+};
+};
+};
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 2/9] drm/vc4: Pass the atomic state to encoder hooks
We'll need to access the connector state in our encoder setup, so let's
just pass the whole DRM state to our private encoder hooks.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_crtc.c | 18 ++
drivers/gpu/drm/vc4/vc4_drv.h | 10 +-
drivers/gpu/drm/vc4/vc4_hdmi.c | 15 ++-
3 files changed, 25 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
index e02e499885ed..a3439756594c 100644
--- a/drivers/gpu/drm/vc4/vc4_crtc.c
+++ b/drivers/gpu/drm/vc4/vc4_crtc.c
@@ -403,7 +403,9 @@ static void require_hvs_enabled(struct drm_device *dev)
SCALER_DISPCTRL_ENABLE);
}
-static int vc4_crtc_disable(struct drm_crtc *crtc, unsigned int channel)
+static int vc4_crtc_disable(struct drm_crtc *crtc,
+ struct drm_atomic_state *state,
+ unsigned int channel)
{
struct drm_encoder *encoder = vc4_get_crtc_encoder(crtc);
struct vc4_encoder *vc4_encoder = to_vc4_encoder(encoder);
@@ -435,13 +437,13 @@ static int vc4_crtc_disable(struct drm_crtc *crtc,
unsigned int channel)
mdelay(20);
if (vc4_encoder && vc4_encoder->post_crtc_disable)
- vc4_encoder->post_crtc_disable(encoder);
+ vc4_encoder->post_crtc_disable(encoder, state);
vc4_crtc_pixelvalve_reset(crtc);
vc4_hvs_stop_channel(dev, channel);
if (vc4_encoder && vc4_encoder->post_crtc_powerdown)
- vc4_encoder->post_crtc_powerdown(encoder);
+ vc4_encoder->post_crtc_powerdown(encoder, state);
return 0;
}
@@ -468,7 +470,7 @@ int vc4_crtc_disable_at_boot(struct drm_crtc *crtc)
if (channel < 0)
return 0;
- return vc4_crtc_disable(crtc, channel);
+ return vc4_crtc_disable(crtc, NULL, channel);
}
static void vc4_crtc_atomic_disable(struct drm_crtc *crtc,
@@ -484,7 +486,7 @@ static void vc4_crtc_atomic_disable(struct drm_crtc *crtc,
/* Disable vblank irq handling before crtc is disabled. */
drm_crtc_vblank_off(crtc);
- vc4_crtc_disable(crtc, old_vc4_state->assigned_channel);
+ vc4_crtc_disable(crtc, state, old_vc4_state->assigned_channel);
/*
* Make sure we issue a vblank event after disabling the CRTC if
@@ -518,14 +520,14 @@ static void vc4_crtc_atomic_enable(struct drm_crtc *crtc,
vc4_hvs_atomic_enable(crtc, state);
if (vc4_encoder->pre_crtc_configure)
- vc4_encoder->pre_crtc_configure(encoder);
+ vc4_encoder->pre_crtc_configure(encoder, state);
vc4_crtc_config_pv(crtc);
CRTC_WRITE(PV_CONTROL, CRTC_READ(PV_CONTROL) | PV_CONTROL_EN);
if (vc4_encoder->pre_crtc_enable)
- vc4_encoder->pre_crtc_enable(encoder);
+ vc4_encoder->pre_crtc_enable(encoder, state);
/* When feeding the transposer block the pixelvalve is unneeded and
* should not be enabled.
@@ -534,7 +536,7 @@ static void vc4_crtc_atomic_enable(struct drm_crtc *crtc,
CRTC_READ(PV_V_CONTROL) | PV_VCONTROL_VIDEN);
if (vc4_encoder->post_crtc_enable)
- vc4_encoder->post_crtc_enable(encoder);
+ vc4_encoder->post_crtc_enable(encoder, state);
}
static enum drm_mode_status vc4_crtc_mode_valid(struct drm_crtc *crtc,
diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
index c47c85533805..b404cd3ab0d8 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.h
+++ b/drivers/gpu/drm/vc4/vc4_drv.h
@@ -444,12 +444,12 @@ struct vc4_encoder {
enum vc4_encoder_type type;
u32 clock_select;
- void (*pre_crtc_configure)(struct drm_encoder *encoder);
- void (*pre_crtc_enable)(struct drm_encoder *encoder);
- void (*post_crtc_enable)(struct drm_encoder *encoder);
+ void (*pre_crtc_configure)(struct drm_encoder *encoder, struct
drm_atomic_state *state);
+ void (*pre_crtc_enable)(struct drm_encoder *encoder, struct
drm_atomic_state *state);
+ void (*post_crtc_enable)(struct drm_encoder *encoder, struct
drm_atomic_state *state);
- void (*post_crtc_disable)(struct drm_encoder *encoder);
- void (*post_crtc_powerdown)(struct drm_encoder *encoder);
+ void (*post_crtc_disable)(struct drm_encoder *encoder, struct
drm_atomic_state *state);
+ void (*post_crtc_powerdown)(struct drm_encoder *encoder, struct
drm_atomic_state *state);
};
static inline struct vc4_encoder *
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index afc178b0d89f..5a608ed1d75e 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -357,7 +357,8 @@ static void vc4_hdmi_set_infoframes(struct drm_encoder
*encoder)
vc4_hdmi_set_audio_infoframe(encoder);
}
-static void vc4_hdmi_encoder_post_crtc_disable(struct drm_encoder *encoder)
+static void vc4_hdmi
Re: [PATCH v3 1/6] dt-bindings: display: imx: Add i.MX8qxp/qm DPU binding
On Mon, 2020-12-07 at 10:56 -0600, Rob Herring wrote: > On Mon, 07 Dec 2020 11:20:55 +0800, Liu Ying wrote: > > This patch adds bindings for i.MX8qxp/qm Display Processing Unit. > > > > Signed-off-by: Liu Ying > > --- > > Note that this depends on the 'two cell binding' clock patch set which has > > already landed in Shawn's i.MX clk/imx git branch. Otherwise, imx8-lpcg.h > > won't be found. > > > > v2->v3: > > * No change. > > > > v1->v2: > > * Fix yamllint warnings. > > * Require bypass0 and bypass1 clocks for both i.MX8qxp and i.MX8qm, as the > > display controller subsystem spec does say that they exist. > > * Use new dt binding way to add clocks in the example. > > * Trivial tweaks for the example. > > > > .../bindings/display/imx/fsl,imx8qxp-dpu.yaml | 416 > > + > > 1 file changed, 416 insertions(+) > > create mode 100644 > > Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dpu.yaml > > > > Reviewed-by: Rob Herring Same to 2/6 and 3/6, will also use enum instead of oneOf+const for this one in the next version, if no objections. Thanks, Liu Ying ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 4/9] drm/vc4: hdmi: Don't access the connector state in reset if kmalloc fails
drm_atomic_helper_connector_reset uses kmalloc which, from an API
standpoint, can fail, and thus setting connector->state to NULL.
However, our reset hook then calls drm_atomic_helper_connector_tv_reset
that will access connector->state without checking if it's a valid
pointer or not.
Make sure we don't end up accessing a NULL pointer.
Acked-by: Thomas Zimmermann
Suggested-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index a88aa20beeb6..61039cc89d9d 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -171,7 +171,9 @@ static int vc4_hdmi_connector_get_modes(struct
drm_connector *connector)
static void vc4_hdmi_connector_reset(struct drm_connector *connector)
{
drm_atomic_helper_connector_reset(connector);
- drm_atomic_helper_connector_tv_reset(connector);
+
+ if (connector->state)
+ drm_atomic_helper_connector_tv_reset(connector);
}
static const struct drm_connector_funcs vc4_hdmi_connector_funcs = {
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/bridge: ti-sn65dsi86: Implement the pwm_chip
The SN65DSI86 provides the ability to supply a PWM signal on GPIO 4,
with the primary purpose of controlling the backlight of the attached
panel. Add an implementation that exposes this using the standard PWM
framework, to allow e.g. pwm-backlight to expose this to the user.
Special thanks to Doug Anderson for suggestions related to the involved
math.
Signed-off-by: Bjorn Andersson
---
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 202 ++
1 file changed, 202 insertions(+)
diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
index f27306c51e4d..43c0acba57ab 100644
--- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
+++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
@@ -4,6 +4,7 @@
* datasheet: https://www.ti.com/lit/ds/symlink/sn65dsi86.pdf
*/
+#include
#include
#include
#include
@@ -14,6 +15,7 @@
#include
#include
#include
+#include
#include
#include
@@ -89,6 +91,11 @@
#define SN_ML_TX_MODE_REG 0x96
#define ML_TX_MAIN_LINK_OFF 0
#define ML_TX_NORMAL_MODE BIT(0)
+#define SN_PWM_PRE_DIV_REG 0xA0
+#define SN_BACKLIGHT_SCALE_REG 0xA1
+#define BACKLIGHT_SCALE_MAX 0x
+#define SN_BACKLIGHT_REG 0xA3
+#define SN_PWM_EN_INV_REG 0xA5
#define SN_AUX_CMD_STATUS_REG 0xF4
#define AUX_IRQ_STATUS_AUX_RPLY_TOUT BIT(3)
#define AUX_IRQ_STATUS_AUX_SHORT BIT(5)
@@ -111,6 +118,8 @@
#define SN_LINK_TRAINING_TRIES 10
+#define SN_PWM_GPIO3
+
/**
* struct ti_sn_bridge - Platform data for ti-sn65dsi86 driver.
* @dev: Pointer to our device.
@@ -162,6 +171,12 @@ struct ti_sn_bridge {
struct gpio_chipgchip;
DECLARE_BITMAP(gchip_output, SN_NUM_GPIOS);
#endif
+#if defined(CONFIG_PWM)
+ struct pwm_chip pchip;
+ boolpwm_enabled;
+ unsigned intpwm_refclk;
+ atomic_tpwm_pin_busy;
+#endif
};
static const struct regmap_range ti_sn_bridge_volatile_ranges[] = {
@@ -499,6 +514,14 @@ static void ti_sn_bridge_set_refclk_freq(struct
ti_sn_bridge *pdata)
regmap_update_bits(pdata->regmap, SN_DPPLL_SRC_REG, REFCLK_FREQ_MASK,
REFCLK_FREQ(i));
+
+#if defined(CONFIG_PWM)
+ /*
+* The PWM refclk is based on the value written to SN_DPPLL_SRC_REG,
+* regardless of its actual sourcing.
+*/
+ pdata->pwm_refclk = ti_sn_bridge_refclk_lut[i];
+#endif
}
static void ti_sn_bridge_set_dsi_rate(struct ti_sn_bridge *pdata)
@@ -981,6 +1004,161 @@ static int ti_sn_bridge_parse_dsi_host(struct
ti_sn_bridge *pdata)
return 0;
}
+#if defined(CONFIG_PWM)
+static int ti_sn_pwm_pin_request(struct ti_sn_bridge *pdata)
+{
+ return atomic_xchg(&pdata->pwm_pin_busy, 1) ? -EBUSY : 0;
+}
+
+static void ti_sn_pwm_pin_release(struct ti_sn_bridge *pdata)
+{
+ atomic_set(&pdata->pwm_pin_busy, 0);
+}
+
+static struct ti_sn_bridge *
+pwm_chip_to_ti_sn_bridge(struct pwm_chip *chip)
+{
+ return container_of(chip, struct ti_sn_bridge, pchip);
+}
+
+static int ti_sn_pwm_request(struct pwm_chip *chip, struct pwm_device *pwm)
+{
+ struct ti_sn_bridge *pdata = pwm_chip_to_ti_sn_bridge(chip);
+
+ return ti_sn_pwm_pin_request(pdata);
+}
+
+static void ti_sn_pwm_free(struct pwm_chip *chip, struct pwm_device *pwm)
+{
+ struct ti_sn_bridge *pdata = pwm_chip_to_ti_sn_bridge(chip);
+
+ ti_sn_pwm_pin_release(pdata);
+}
+
+static int ti_sn_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
+ const struct pwm_state *state)
+{
+ struct ti_sn_bridge *pdata = pwm_chip_to_ti_sn_bridge(chip);
+ unsigned int pwm_en_inv;
+ unsigned int backlight;
+ unsigned int pwm_freq;
+ unsigned int pre_div;
+ unsigned int scale;
+ int ret;
+
+ if (!pdata->pwm_enabled) {
+ ret = pm_runtime_get_sync(pdata->dev);
+ if (ret < 0)
+ return ret;
+
+ ret = regmap_update_bits(pdata->regmap, SN_GPIO_CTRL_REG,
+SN_GPIO_MUX_MASK << (2 * SN_PWM_GPIO),
+SN_GPIO_MUX_SPECIAL << (2 *
SN_PWM_GPIO));
+ if (ret) {
+ dev_err(pdata->dev, "failed to mux in PWM function\n");
+ goto out;
+ }
+ }
+
+ if (state->enabled) {
+ /*
+* Per the datasheet the PWM frequency is given by:
+*
+* PWM_FREQ = REFCLK_FREQ / (PWM_PRE_DIV * BACKLIGHT_SCALE + 1)
+*
+* In order to find the PWM_FREQ that best suits the requested
+* state->period, the PWM_PRE_DIV is
Re: [PATCH v11 00/10] Introduce memory interconnect for NVIDIA Tegra SoCs
05.12.2020 17:09, Krzysztof Kozlowski пишет: > On Thu, 3 Dec 2020 22:24:29 +0300, Dmitry Osipenko wrote: >> This series brings initial support for memory interconnect to Tegra20, >> Tegra30 and Tegra124 SoCs. >> >> For the starter only display controllers and devfreq devices 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. In particular this series >> fixes distorted display output on T30 Ouya and T124 TK1 devices. >> >> [...] > > Applied, thanks! > > [01/10] dt-bindings: memory: tegra20: emc: Document opp-supported-hw property > [02/10] memory: tegra20: Support hardware versioning and clean up OPP table > initialization > [03/10] memory: tegra30: Support interconnect framework > commit: 01a51facb74fb337ff9fe734caa85dd6e246ef48 > > Best regards, > Awesome, thanks! Good to have the warning splat silenced. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/4] phy: phy-fsl-imx8-mipi-dphy: Add i.MX8qxp LVDS PHY mode support
Hi Liu, On Fri, Dec 04, 2020 at 03:33:40PM +0800, Liu Ying wrote: > Hi, > > This series adds i.MX8qxp LVDS PHY mode support for the Mixel PHY in the > Freescale i.MX8qxp SoC. This looks good to me from the NWL and actual phy driver part. I'll comment in the individual patches but leave comments on the extension of the generic phy struct to someone knowledgeable with that part. What display controllers do you intend to drive that with? Cheers, -- Guido > > The Mixel PHY is MIPI DPHY + LVDS PHY combo, which can works in either > MIPI DPHY mode or LVDS PHY mode. The PHY mode is controlled by i.MX8qxp > SCU firmware. The PHY driver would call a SCU function to configure the > mode. > > The PHY driver is already supporting the Mixel MIPI DPHY in i.MX8mq SoC, > where it appears to be a single MIPI DPHY. > > > Patch 1/4 sets PHY mode in the Northwest Logic MIPI DSI host controller > bridge driver, since i.MX8qxp SoC embeds this controller IP to support > MIPI DSI displays together with the Mixel PHY. > > Patch 2/4 allows LVDS PHYs to be configured through the generic PHY functions > and through a custom structure added to the generic PHY configuration union. > > Patch 3/4 adds dt binding support for the Mixel combo PHY in i.MX8qxp SoC. > > Patch 4/4 adds the i.MX8qxp LVDS PHY mode support in the Mixel PHY driver. > > > Welcome comments, thanks. > > > Liu Ying (4): > drm/bridge: nwl-dsi: Set PHY mode in nwl_dsi_enable() > phy: Add LVDS configuration options > dt-bindings: phy: mixel: mipi-dsi-phy: Add Mixel combo PHY support for > i.MX8qxp > phy: freescale: phy-fsl-imx8-mipi-dphy: Add i.MX8qxp LVDS PHY mode > support > > .../devicetree/bindings/phy/mixel,mipi-dsi-phy.txt | 8 +- > drivers/gpu/drm/bridge/nwl-dsi.c | 6 + > drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c | 266 > - > include/linux/phy/phy-lvds.h | 48 > include/linux/phy/phy.h| 4 + > 5 files changed, 320 insertions(+), 12 deletions(-) > create mode 100644 include/linux/phy/phy-lvds.h > > -- > 2.7.4 > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/4] drm/bridge: nwl-dsi: Set PHY mode in nwl_dsi_enable()
Hi,
On Fri, Dec 04, 2020 at 03:33:41PM +0800, Liu Ying wrote:
> The Northwest Logic MIPI DSI host controller embedded in i.MX8qxp
> works with a Mixel MIPI DPHY + LVDS PHY combo to support either
> a MIPI DSI display or a LVDS display. So, this patch calls
> phy_set_mode() from nwl_dsi_enable() to set PHY mode to MIPI DPHY
> explicitly.
>
> Cc: Guido Günther
> Cc: Robert Chiras
> Cc: Martin Kepplinger
> Cc: Andrzej Hajda
> Cc: Neil Armstrong
> Cc: Laurent Pinchart
> Cc: Jonas Karlman
> Cc: Jernej Skrabec
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: NXP Linux Team
> Signed-off-by: Liu Ying
> ---
> drivers/gpu/drm/bridge/nwl-dsi.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/gpu/drm/bridge/nwl-dsi.c
> b/drivers/gpu/drm/bridge/nwl-dsi.c
> index 66b6740..be6bfc5 100644
> --- a/drivers/gpu/drm/bridge/nwl-dsi.c
> +++ b/drivers/gpu/drm/bridge/nwl-dsi.c
> @@ -678,6 +678,12 @@ static int nwl_dsi_enable(struct nwl_dsi *dsi)
> return ret;
> }
>
> + ret = phy_set_mode(dsi->phy, PHY_MODE_MIPI_DPHY);
> + if (ret < 0) {
> + DRM_DEV_ERROR(dev, "Failed to set DSI phy mode: %d\n", ret);
> + goto uninit_phy;
> + }
> +
> ret = phy_configure(dsi->phy, phy_cfg);
> if (ret < 0) {
> DRM_DEV_ERROR(dev, "Failed to configure DSI phy: %d\n", ret);
Reviewed-by: Guido Günther
-- Guido
> --
> 2.7.4
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/4] dt-bindings: phy: mixel: mipi-dsi-phy: Add Mixel combo PHY support for i.MX8qxp
Hi Liu, Since we now gain optional properties validation would become even more useful. Could you look into converting to YAML before adding more values? Cheers, -- Guido On Fri, Dec 04, 2020 at 03:33:43PM +0800, Liu Ying wrote: > Add support for Mixel MIPI DPHY + LVDS PHY combo IP > as found on Freescale i.MX8qxp SoC. > > Cc: Guido Günther > Cc: Kishon Vijay Abraham I > Cc: Vinod Koul > Cc: Rob Herring > Cc: NXP Linux Team > Signed-off-by: Liu Ying > --- > Documentation/devicetree/bindings/phy/mixel,mipi-dsi-phy.txt | 8 +++- > 1 file changed, 7 insertions(+), 1 deletion(-) > > diff --git a/Documentation/devicetree/bindings/phy/mixel,mipi-dsi-phy.txt > b/Documentation/devicetree/bindings/phy/mixel,mipi-dsi-phy.txt > index 9b23407..0afce99 100644 > --- a/Documentation/devicetree/bindings/phy/mixel,mipi-dsi-phy.txt > +++ b/Documentation/devicetree/bindings/phy/mixel,mipi-dsi-phy.txt > @@ -4,9 +4,13 @@ The Mixel MIPI-DSI PHY IP block is e.g. found on i.MX8 > platforms (along the > MIPI-DSI IP from Northwest Logic). It represents the physical layer for the > electrical signals for DSI. > > +The Mixel PHY IP block found on i.MX8qxp is a combo PHY that can work > +in either MIPI-DSI PHY mode or LVDS PHY mode. > + > Required properties: > -- compatible: Must be: > +- compatible: Should be one of: >- "fsl,imx8mq-mipi-dphy" > + - "fsl,imx8qxp-mipi-dphy" > - clocks: Must contain an entry for each entry in clock-names. > - clock-names: Must contain the following entries: >- "phy_ref": phandle and specifier referring to the DPHY ref clock > @@ -14,6 +18,8 @@ Required properties: > - #phy-cells: number of cells in PHY, as defined in >Documentation/devicetree/bindings/phy/phy-bindings.txt >this must be <0> > +- fsl,syscon: Phandle to a system controller, as required by the PHY > + in i.MX8qxp SoC. > > Optional properties: > - power-domains: phandle to power domain > -- > 2.7.4 > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/4] phy: freescale: phy-fsl-imx8-mipi-dphy: Add i.MX8qxp LVDS PHY mode support
Hi Liu,
some minor comments inline:
On Fri, Dec 04, 2020 at 03:33:44PM +0800, Liu Ying wrote:
> i.MX8qxp SoC embeds a Mixel MIPI DPHY + LVDS PHY combo which supports
> either a MIPI DSI display or a LVDS display. The PHY mode is controlled
> by SCU firmware and the driver would call a SCU firmware function to
> configure the PHY mode. The single LVDS PHY has 4 data lanes to support
> a LVDS display. Also, with a master LVDS PHY and a slave LVDS PHY, they
> may work together to support a LVDS display with 8 data lanes(usually, dual
> LVDS link display). Note that this patch supports the LVDS PHY mode only
> for the i.MX8qxp Mixel combo PHY, i.e., the MIPI DPHY mode is yet to be
> supported, so for now error would be returned from ->set_mode() if MIPI
> DPHY mode is passed over to it for the combo PHY.
>
> Cc: Guido Günther
> Cc: Robert Chiras
> Cc: Kishon Vijay Abraham I
> Cc: Vinod Koul
> Cc: Shawn Guo
> Cc: Sascha Hauer
> Cc: Pengutronix Kernel Team
> Cc: Fabio Estevam
> Cc: NXP Linux Team
> Signed-off-by: Liu Ying
> ---
> drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c | 266
> -
> 1 file changed, 255 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c
> b/drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c
> index a95572b..37084a9 100644
> --- a/drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c
> +++ b/drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c
> @@ -4,17 +4,31 @@
> * Copyright 2019 Purism SPC
> */
>
> +#include
> #include
> #include
> #include
> +#include
> +#include
> #include
> #include
> +#include
> #include
> #include
> #include
> #include
> #include
> #include
> +#include
> +
> +/* Control and Status Registers(CSR) */
> +#define PHY_CTRL 0x00
> +#define CCM_MASKGENMASK(7, 5)
> +#define CCM(n) FIELD_PREP(CCM_MASK, (n))
> +#define CA_MASK GENMASK(4, 2)
> +#define CA(n) FIELD_PREP(CA_MASK, (n))
> +#define RFB BIT(1)
> +#define LVDS_EN BIT(0)
>
> /* DPHY registers */
> #define DPHY_PD_DPHY 0x00
> @@ -55,8 +69,15 @@
> #define PWR_ON 0
> #define PWR_OFF 1
>
> +#define MIN_VCO_FREQ 64000
> +#define MAX_VCO_FREQ 15
> +
> +#define MIN_LVDS_REFCLK_FREQ 2400
> +#define MAX_LVDS_REFCLK_FREQ 15000
> +
> enum mixel_dphy_devtype {
> MIXEL_IMX8MQ,
> + MIXEL_IMX8QXP,
> };
>
> struct mixel_dphy_devdata {
> @@ -65,6 +86,7 @@ struct mixel_dphy_devdata {
> u8 reg_rxlprp;
> u8 reg_rxcdrp;
> u8 reg_rxhs_settle;
> + bool is_combo; /* MIPI DPHY and LVDS PHY combo */
> };
>
> static const struct mixel_dphy_devdata mixel_dphy_devdata[] = {
> @@ -74,6 +96,10 @@ static const struct mixel_dphy_devdata
> mixel_dphy_devdata[] = {
> .reg_rxlprp = 0x40,
> .reg_rxcdrp = 0x44,
> .reg_rxhs_settle = 0x48,
> + .is_combo = false,
> + },
> + [MIXEL_IMX8QXP] = {
> + .is_combo = true,
> },
> };
>
> @@ -95,8 +121,12 @@ struct mixel_dphy_cfg {
> struct mixel_dphy_priv {
> struct mixel_dphy_cfg cfg;
> struct regmap *regmap;
> + struct regmap *lvds_regmap;
> struct clk *phy_ref_clk;
> const struct mixel_dphy_devdata *devdata;
> + struct imx_sc_ipc *ipc_handle;
> + bool is_slave;
> + int id;
> };
>
> static const struct regmap_config mixel_dphy_regmap_config = {
> @@ -317,7 +347,8 @@ static int mixel_dphy_set_pll_params(struct phy *phy)
> return 0;
> }
>
> -static int mixel_dphy_configure(struct phy *phy, union phy_configure_opts
> *opts)
> +static int
> +mixel_dphy_configure_mipi_dphy(struct phy *phy, union phy_configure_opts
> *opts)
> {
> struct mixel_dphy_priv *priv = phy_get_drvdata(phy);
> struct mixel_dphy_cfg cfg = { 0 };
> @@ -345,15 +376,118 @@ static int mixel_dphy_configure(struct phy *phy, union
> phy_configure_opts *opts)
> return 0;
> }
>
> +static int
> +mixel_dphy_configure_lvds_phy(struct phy *phy, union phy_configure_opts
> *opts)
> +{
> + struct mixel_dphy_priv *priv = phy_get_drvdata(phy);
> + struct phy_configure_opts_lvds *lvds_opts = &opts->lvds;
> + unsigned long data_rate;
> + unsigned long fvco;
> + u32 rsc;
> + u32 co;
> + int ret;
> +
> + priv->is_slave = lvds_opts->is_slave;
> +
> + /* LVDS interface pins */
> + regmap_write(priv->lvds_regmap, PHY_CTRL, CCM(0x5) | CA(0x4) | RFB);
> +
> + /* enable MODE8 only for slave LVDS PHY */
> + rsc = priv->id ? IMX_SC_R_MIPI_1 : IMX_SC_R_MIPI_0;
> + ret = imx_sc_misc_set_control(priv->ipc_handle, rsc, IMX_SC_C_DUAL_MODE,
> + lvds_opts->is_slave);
> + if (ret) {
> + dev_err(&phy->dev, "Failed to configure MODE8: %d\n", ret);
> + r
Re: [PATCH] drm/ttm: fix unused function warning
Am 08.12.20 um 09:18 schrieb Martin Peres:
On 04/12/2020 18:51, Arnd Bergmann wrote:
From: Arnd Bergmann
ttm_pool_type_count() is not used when debugfs is disabled:
drivers/gpu/drm/ttm/ttm_pool.c:243:21: error: unused function
'ttm_pool_type_count' [-Werror,-Wunused-function]
static unsigned int ttm_pool_type_count(struct ttm_pool_type *pt)
Move the definition into the #ifdef block.
Fixes: d099fc8f540a ("drm/ttm: new TT backend allocation pool v3")
Signed-off-by: Arnd Bergmann
Thanks Arnd! The patch looks good to me:
Reviewed-by: Martin Peres
Reviewed-by: Christian König
---
drivers/gpu/drm/ttm/ttm_pool.c | 29 ++---
1 file changed, 14 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_pool.c
b/drivers/gpu/drm/ttm/ttm_pool.c
index 5455b2044759..7b2f60616750 100644
--- a/drivers/gpu/drm/ttm/ttm_pool.c
+++ b/drivers/gpu/drm/ttm/ttm_pool.c
@@ -239,21 +239,6 @@ static struct page *ttm_pool_type_take(struct
ttm_pool_type *pt)
return p;
}
-/* Count the number of pages available in a pool_type */
-static unsigned int ttm_pool_type_count(struct ttm_pool_type *pt)
-{
- unsigned int count = 0;
- struct page *p;
-
- spin_lock(&pt->lock);
- /* Only used for debugfs, the overhead doesn't matter */
- list_for_each_entry(p, &pt->pages, lru)
- ++count;
- spin_unlock(&pt->lock);
-
- return count;
-}
-
/* Initialize and add a pool type to the global shrinker list */
static void ttm_pool_type_init(struct ttm_pool_type *pt, struct
ttm_pool *pool,
enum ttm_caching caching, unsigned int order)
@@ -543,6 +528,20 @@ void ttm_pool_fini(struct ttm_pool *pool)
EXPORT_SYMBOL(ttm_pool_fini);
#ifdef CONFIG_DEBUG_FS
+/* Count the number of pages available in a pool_type */
+static unsigned int ttm_pool_type_count(struct ttm_pool_type *pt)
+{
+ unsigned int count = 0;
+ struct page *p;
+
+ spin_lock(&pt->lock);
+ /* Only used for debugfs, the overhead doesn't matter */
+ list_for_each_entry(p, &pt->pages, lru)
+ ++count;
+ spin_unlock(&pt->lock);
+
+ return count;
+}
/* Dump information about the different pool types */
static void ttm_pool_debugfs_orders(struct ttm_pool_type *pt,
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 2/4] drm/i915/pmu: Use kstat_irqs to get interrupt count
On Sun, Dec 06, 2020 at 10:33:09PM +0100, Thomas Gleixner wrote: > On Sun, Dec 06 2020 at 17:38, Thomas Gleixner wrote: > > On Fri, Dec 04 2020 at 18:43, Jerry Snitselaar wrote: > >> Now that kstat_irqs is exported, get rid of count_interrupts in > >> i915_pmu.c > > > > May I ask why this has been merged in the first place? > > > > Nothing in a driver has ever to fiddle with the internals of an irq > > descriptor. We have functions for properly accessing them. Just because > > C allows to fiddle with everything is not a justification. If the > > required function is not exported then adding the export with a proper > > explanation is not asked too much. > > > > Also this lacks protection or at least a comment why this can be called > > safely and is not subject to a concurrent removal of the irq descriptor. > > The same problem exists when calling kstat_irqs(). It's even documented > > at the top of the function. > > And as pointed out vs. that TPM thing this really could have been a > trivial > > i915->irqs++; > > in the interrupt handler and a read of that instead of iterating over > all possible cpus and summing it up. Oh well... I'm fine with that. > Thanks, > > tglx /Jarkko ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 6/6] dt-binding: display: mantix: Add compatible for panel from YS
Hi, On Mon, Dec 07, 2020 at 03:32:06PM -0600, Rob Herring wrote: > On Wed, 18 Nov 2020 09:29:53 +0100, Guido Günther wrote: > > This panel from Shenzhen Yashi Changhua Intelligent Technology Co > > uses the same driver IC but a different LCD. > > > > Signed-off-by: Guido Günther > > Reviewed-by: Linus Walleij > > --- > > .../devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml | 1 + > > 1 file changed, 1 insertion(+) > > > > Acked-by: Rob Herring > Thanks! I've appplied the series to drm-misc-next now. Cheers, -- Guido ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 00/16] Add support for DP-HDMI2.1 PCON
On Tue, 08 Dec 2020, Ankit Nautiyal wrote: > This patch series attempts to add support for a DP-HDMI2.1 Protocol > Convertor. The VESA spec for the HDMI2.1 PCON are proposed in Errata > E5 to DisplayPort_v2.0: > https://vesa.org/join-vesamemberships/member-downloads/?action=stamp&fileid=42299 > The details are mentioned in: > VESA DP-to-HDMI PCON Specification Standalone Document > https://groups.vesa.org/wg/DP/document/15651 > > This series starts with adding support for FRL (Fixed Rate Link) > Training between the PCON and HDMI2.1 sink. > As per HDMI2.1 specification, a new data-channel or lane is added in > FRL mode, by repurposing the TMDS clock Channel. Through FRL, higher > bit-rate can be supported, ie. up to 12 Gbps/lane (48 Gbps over 4 > lanes). > > With these patches, the HDMI2.1 PCON can be configured to achieve FRL > training based on the maximum FRL rate supported by the panel, source > and the PCON. > The approach is to add the support for FRL training between PCON and > HDMI2.1 sink and gradually add other blocks for supporting higher > resolutions and other HDMI2.1 features, that can be supported by pcon > for the sources that do not natively support HDMI2.1. > > This is done before the DP Link training between the source and PCON > is started. In case of FRL training is not achieved, the PCON will > work in the regular TMDS mode, without HDMI2.1 feature support. > Any interruption in FRL training between the PCON and HDMI2.1 sink is > notified through IRQ_HPD. On receiving the IRQ_HPD the concerned DPCD > registers are read and FRL training is re-attempted. > > Currently, we have tested the FRL training and are able to enable 4K > display with TGL Platform + Realtek PCON RTD2173 with HDMI2.1 supporting > panel. Per IRC chat with Maarten and Daniel, once all the reviews are in, I'll add a topic branch and apply the patches there, so we can merge the branch to both drm-misc-next and drm-intel-next. BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/tidss: Use the new api devm_drm_irq_install
Hi Tian,
I love your patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on drm-exynos/exynos-drm-next
tegra-drm/drm/tegra/for-next drm-tip/drm-tip linus/master v5.10-rc7
next-20201207]
[cannot apply to drm/drm-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Tian-Tao/drm-tidss-Use-the-new-api-devm_drm_irq_install/20201208-155323
base: git://anongit.freedesktop.org/drm-intel for-linux-next
config: h8300-randconfig-r016-20201208 (attached as .config)
compiler: h8300-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
#
https://github.com/0day-ci/linux/commit/c31dcdd7b0bbfc11fa4ff1f81164483b478025c4
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Tian-Tao/drm-tidss-Use-the-new-api-devm_drm_irq_install/20201208-155323
git checkout c31dcdd7b0bbfc11fa4ff1f81164483b478025c4
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
ARCH=h8300
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
drivers/gpu/drm/tidss/tidss_drv.c: In function 'tidss_probe':
>> drivers/gpu/drm/tidss/tidss_drv.c:176:8: error: implicit declaration of
>> function 'devm_irq_install'; did you mean 'drm_irq_install'?
>> [-Werror=implicit-function-declaration]
176 | ret = devm_irq_install(ddev, irq);
|^~~~
|drm_irq_install
cc1: some warnings being treated as errors
vim +176 drivers/gpu/drm/tidss/tidss_drv.c
162
163 ret = tidss_modeset_init(tidss);
164 if (ret < 0) {
165 if (ret != -EPROBE_DEFER)
166 dev_err(dev, "failed to init DRM/KMS (%d)\n",
ret);
167 goto err_runtime_suspend;
168 }
169
170 irq = platform_get_irq(pdev, 0);
171 if (irq < 0) {
172 ret = irq;
173 goto err_runtime_suspend;
174 }
175
> 176 ret = devm_irq_install(ddev, irq);
177 if (ret) {
178 dev_err(dev, "drm_irq_install failed: %d\n", ret);
179 goto err_runtime_suspend;
180 }
181
182 drm_kms_helper_poll_init(ddev);
183
184 drm_mode_config_reset(ddev);
185
186 ret = drm_dev_register(ddev, 0);
187 if (ret) {
188 dev_err(dev, "failed to register DRM device\n");
189 goto err_irq_uninstall;
190 }
191
192 drm_fbdev_generic_setup(ddev, 32);
193
194 dev_dbg(dev, "%s done\n", __func__);
195
196 return 0;
197
198 err_irq_uninstall:
199 drm_irq_uninstall(ddev);
200
201 err_runtime_suspend:
202 #ifndef CONFIG_PM
203 dispc_runtime_suspend(tidss->dispc);
204 #endif
205 pm_runtime_disable(dev);
206
207 return ret;
208 }
209
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: drm_basic_types.h, DRM_FOURCC_STANDALONE
May I ask what exactly fails when you drop #include from drm.h? ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/6] drm/dsc, drm/dp, and /drm/i915: rc model size updates
For whatever reason this old series was never merged. Please let's get this done. For i915 DP this still needs a patch to start using the model size from DPCD. BR, Jani. Jani Nikula (6): drm/dsc: use rc_model_size from DSC config for PPS drm/i915/dsc: configure hardware using specified rc_model_size drm/i915/dsc: make rc_model_size an encoder defined value drm/dsc: add helper for calculating rc buffer size from DPCD drm/i915/bios: fill in DSC rc_model_size from VBT drm/i915/dsi: use VBT data for rc_model_size drivers/gpu/drm/drm_dsc.c | 30 +-- drivers/gpu/drm/i915/display/intel_bios.c | 11 +++-- drivers/gpu/drm/i915/display/intel_dp.c | 8 ++ drivers/gpu/drm/i915/display/intel_vdsc.c | 4 +-- include/drm/drm_dsc.h | 1 + 5 files changed, 41 insertions(+), 13 deletions(-) -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amdgpu: make DRM_AMD_DC x86-only again
On Mon, Dec 7, 2020 at 1:57 PM Arnd Bergmann wrote: > > On Mon, Dec 7, 2020 at 9:50 PM Christian König > wrote: > > Am 07.12.20 um 21:47 schrieb Alex Deucher: > > > On Fri, Dec 4, 2020 at 3:13 AM Arnd Bergmann wrote: > > >> From: Arnd Bergmann > > >> > > >> As the DRM_AMD_DC_DCN3_0 code was x86-only and fails to build on > > >> arm64, merging it into DRM_AMD_DC means that the top-level symbol > > >> is now x86-only as well. > > >> > > >> Compilation fails on arm64 with clang-12 with > > >> > > >> drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn30/display_mode_vba_30.c:3641:6: > > >> error: stack frame size of 2416 bytes in function > > >> 'dml30_ModeSupportAndSystemConfigurationFull' > > >> [-Werror,-Wframe-larger-than=] > > >> void dml30_ModeSupportAndSystemConfigurationFull(struct display_mode_lib > > >> *mode_lib) > > >> > > >> I tried to see if the stack usage can be reduced, but this is code > > >> that is described as "This file is gcc-parsable HW gospel, coming > > >> straight from HW engineers." and is written in a way that is inherently > > >> nonportable and not meant to be understood by humans. > > >> > > >> There are probably no non-x86 users of this code, so simplify > > >> the dependency list accordingly. > > > + Daniel, Timothy > > > > > > Others contributed code to enable this on PPC64 and ARM64. > > > Unfortunately, we don't have these platforms to test with within AMD. > > > Does PPC64 have the same stack limitations as ARM64? Harry, Leo, can > > > you take a look at fixing the stack usage? > > > > This reminds me that I wanted to reply on this. > > > > 2416 is even to much on x86 if you add -Werror :) > > > > So this needs to be fixed anyway. > > Right, looking at my latest randconfig logs, I see the same problem on x86 > builds with clang as well, though I'm not entirely sure which other > configuration > options are needed to trigger it. > > So my patch can be disregarded, but I agree this needs a better fix, > either in clang or in the dcn driver. If you could give https://github.com/ClangBuiltLinux/frame-larger-than a spin again, I would appreciate any feedback. -- Thanks, ~Nick Desaulniers ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/6] drm/dsc: use rc_model_size from DSC config for PPS
The PPS is supposed to reflect the DSC config instead of hard coding the rc_model_size. Make it so. Currently all users of drm_dsc_pps_payload_pack() hard code the size to 8192 also in the DSC config, so this change should have no impact, other than allowing the drivers to use other sizes as needed. Cc: Alex Deucher Cc: Harry Wentland Cc: Manasi Navare Cc: Vandita Kulkarni Reviewed-by: Vandita Kulkarni Signed-off-by: Jani Nikula --- drivers/gpu/drm/drm_dsc.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_dsc.c b/drivers/gpu/drm/drm_dsc.c index 4a475d9696ff..09afbc01ea94 100644 --- a/drivers/gpu/drm/drm_dsc.c +++ b/drivers/gpu/drm/drm_dsc.c @@ -186,8 +186,7 @@ void drm_dsc_pps_payload_pack(struct drm_dsc_picture_parameter_set *pps_payload, pps_payload->flatness_max_qp = dsc_cfg->flatness_max_qp; /* PPS 38, 39 */ - pps_payload->rc_model_size = - cpu_to_be16(DSC_RC_MODEL_SIZE_CONST); + pps_payload->rc_model_size = cpu_to_be16(dsc_cfg->rc_model_size); /* PPS 40 */ pps_payload->rc_edge_factor = DSC_RC_EDGE_FACTOR_CONST; -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/6] drm/i915/dsc: configure hardware using specified rc_model_size
The rc_model_size is specified in the DSC config, and the hardware
programming should respect that instead of hard coding a value of 8192.
Regardless, the rc_model_size in DSC config is currently hard coded to
the same value, so this should have no impact, other than allowing the
use of other sizes as needed.
Cc: Manasi Navare
Cc: Vandita Kulkarni
Reviewed-by: Vandita Kulkarni
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_vdsc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_vdsc.c
b/drivers/gpu/drm/i915/display/intel_vdsc.c
index e2716a67b281..22d08679844f 100644
--- a/drivers/gpu/drm/i915/display/intel_vdsc.c
+++ b/drivers/gpu/drm/i915/display/intel_vdsc.c
@@ -741,7 +741,7 @@ static void intel_dsc_pps_configure(const struct
intel_crtc_state *crtc_state)
/* Populate PICTURE_PARAMETER_SET_9 registers */
pps_val = 0;
- pps_val |= DSC_RC_MODEL_SIZE(DSC_RC_MODEL_SIZE_CONST) |
+ pps_val |= DSC_RC_MODEL_SIZE(vdsc_cfg->rc_model_size) |
DSC_RC_EDGE_FACTOR(DSC_RC_EDGE_FACTOR_CONST);
drm_info(&dev_priv->drm, "PPS9 = 0x%08x\n", pps_val);
if (!is_pipe_dsc(crtc_state)) {
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/6] drm/i915/dsc: make rc_model_size an encoder defined value
Move the intialization of the rc_model_size from the common code into encoder code, allowing different encoders to specify the size according to their needs. Keep using the hard coded value in the encoders for now to make this a non-functional change. Cc: Manasi Navare Cc: Vandita Kulkarni Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/display/icl_dsi.c| 3 +++ drivers/gpu/drm/i915/display/intel_dp.c | 8 drivers/gpu/drm/i915/display/intel_vdsc.c | 2 -- 3 files changed, 11 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c b/drivers/gpu/drm/i915/display/icl_dsi.c index a9439b415603..676e40172fe9 100644 --- a/drivers/gpu/drm/i915/display/icl_dsi.c +++ b/drivers/gpu/drm/i915/display/icl_dsi.c @@ -1535,6 +1535,9 @@ static int gen11_dsi_dsc_compute_config(struct intel_encoder *encoder, vdsc_cfg->convert_rgb = true; + /* FIXME: initialize from VBT */ + vdsc_cfg->rc_model_size = DSC_RC_MODEL_SIZE_CONST; + ret = intel_dsc_compute_params(encoder, crtc_state); if (ret) return ret; diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c index cb5e42c3ecd5..b2bc0c8c39c7 100644 --- a/drivers/gpu/drm/i915/display/intel_dp.c +++ b/drivers/gpu/drm/i915/display/intel_dp.c @@ -2289,6 +2289,14 @@ static int intel_dp_dsc_compute_params(struct intel_encoder *encoder, u8 line_buf_depth; int ret; + /* +* RC_MODEL_SIZE is currently a constant across all configurations. +* +* FIXME: Look into using sink defined DPCD DP_DSC_RC_BUF_BLK_SIZE and +* DP_DSC_RC_BUF_SIZE for this. +*/ + vdsc_cfg->rc_model_size = DSC_RC_MODEL_SIZE_CONST; + ret = intel_dsc_compute_params(encoder, crtc_state); if (ret) return ret; diff --git a/drivers/gpu/drm/i915/display/intel_vdsc.c b/drivers/gpu/drm/i915/display/intel_vdsc.c index 22d08679844f..f58cc5700784 100644 --- a/drivers/gpu/drm/i915/display/intel_vdsc.c +++ b/drivers/gpu/drm/i915/display/intel_vdsc.c @@ -454,8 +454,6 @@ int intel_dsc_compute_params(struct intel_encoder *encoder, else if (vdsc_cfg->bits_per_component == 12) vdsc_cfg->mux_word_size = DSC_MUX_WORD_SIZE_12_BPC; - /* RC_MODEL_SIZE is a constant across all configurations */ - vdsc_cfg->rc_model_size = DSC_RC_MODEL_SIZE_CONST; /* InitialScaleValue is a 6 bit value with 3 fractional bits (U3.3) */ vdsc_cfg->initial_scale_value = (vdsc_cfg->rc_model_size << 3) / (vdsc_cfg->rc_model_size - vdsc_cfg->initial_offset); -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/6] drm/dsc: add helper for calculating rc buffer size from DPCD
Add a helper for calculating the rc buffer size from the DCPD offsets
DP_DSC_RC_BUF_BLK_SIZE and DP_DSC_RC_BUF_SIZE.
Cc: Alex Deucher
Cc: Harry Wentland
Cc: Manasi Navare
Cc: Vandita Kulkarni
Reviewed-by: Vandita Kulkarni
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_dsc.c | 27 +++
include/drm/drm_dsc.h | 1 +
2 files changed, 28 insertions(+)
diff --git a/drivers/gpu/drm/drm_dsc.c b/drivers/gpu/drm/drm_dsc.c
index 09afbc01ea94..ff602f7ec65b 100644
--- a/drivers/gpu/drm/drm_dsc.c
+++ b/drivers/gpu/drm/drm_dsc.c
@@ -49,6 +49,33 @@ void drm_dsc_dp_pps_header_init(struct dp_sdp_header
*pps_header)
}
EXPORT_SYMBOL(drm_dsc_dp_pps_header_init);
+/**
+ * drm_dsc_dp_rc_buffer_size - get rc buffer size in bytes
+ * @rc_buffer_block_size: block size code, according to DPCD offset 62h
+ * @rc_buffer_size: number of blocks - 1, according to DPCD offset 63h
+ *
+ * return:
+ * buffer size in bytes, or 0 on invalid input
+ */
+int drm_dsc_dp_rc_buffer_size(u8 rc_buffer_block_size, u8 rc_buffer_size)
+{
+ int size = 1024 * (rc_buffer_size + 1);
+
+ switch (rc_buffer_block_size) {
+ case DP_DSC_RC_BUF_BLK_SIZE_1:
+ return 1 * size;
+ case DP_DSC_RC_BUF_BLK_SIZE_4:
+ return 4 * size;
+ case DP_DSC_RC_BUF_BLK_SIZE_16:
+ return 16 * size;
+ case DP_DSC_RC_BUF_BLK_SIZE_64:
+ return 64 * size;
+ default:
+ return 0;
+ }
+}
+EXPORT_SYMBOL(drm_dsc_dp_rc_buffer_size);
+
/**
* drm_dsc_pps_payload_pack() - Populates the DSC PPS
*
diff --git a/include/drm/drm_dsc.h b/include/drm/drm_dsc.h
index 53c51231b31c..cf43561e60fa 100644
--- a/include/drm/drm_dsc.h
+++ b/include/drm/drm_dsc.h
@@ -603,6 +603,7 @@ struct drm_dsc_pps_infoframe {
} __packed;
void drm_dsc_dp_pps_header_init(struct dp_sdp_header *pps_header);
+int drm_dsc_dp_rc_buffer_size(u8 rc_buffer_block_size, u8 rc_buffer_size);
void drm_dsc_pps_payload_pack(struct drm_dsc_picture_parameter_set *pps_sdp,
const struct drm_dsc_config *dsc_cfg);
int drm_dsc_compute_rc_parameters(struct drm_dsc_config *vdsc_cfg);
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/6] drm/i915/bios: fill in DSC rc_model_size from VBT
The VBT fields match the DPCD data, so use the same helper. Cc: Manasi Navare Cc: Vandita Kulkarni Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/display/intel_bios.c | 11 +++ 1 file changed, 3 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_bios.c b/drivers/gpu/drm/i915/display/intel_bios.c index 4cc949b228f2..06c3310446a2 100644 --- a/drivers/gpu/drm/i915/display/intel_bios.c +++ b/drivers/gpu/drm/i915/display/intel_bios.c @@ -2555,16 +2555,11 @@ static void fill_dsc(struct intel_crtc_state *crtc_state, crtc_state->dsc.slice_count); /* -* FIXME: Use VBT rc_buffer_block_size and rc_buffer_size for the -* implementation specific physical rate buffer size. Currently we use -* the required rate buffer model size calculated in -* drm_dsc_compute_rc_parameters() according to VESA DSC Annex E. -* * The VBT rc_buffer_block_size and rc_buffer_size definitions -* correspond to DP 1.4 DPCD offsets 0x62 and 0x63. The DP DSC -* implementation should also use the DPCD (or perhaps VBT for eDP) -* provided value for the buffer size. +* correspond to DP 1.4 DPCD offsets 0x62 and 0x63. */ + vdsc_cfg->rc_model_size = drm_dsc_dp_rc_buffer_size(dsc->rc_buffer_block_size, + dsc->rc_buffer_size); /* FIXME: DSI spec says bpc + 1 for this one */ vdsc_cfg->line_buf_depth = VBT_DSC_LINE_BUFFER_DEPTH(dsc->line_buffer_depth); -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 6/6] drm/i915/dsi: use VBT data for rc_model_size
Stop overriding the VBT defined value for rc_model_size. Cc: Vandita Kulkarni Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/display/icl_dsi.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c b/drivers/gpu/drm/i915/display/icl_dsi.c index 676e40172fe9..a9439b415603 100644 --- a/drivers/gpu/drm/i915/display/icl_dsi.c +++ b/drivers/gpu/drm/i915/display/icl_dsi.c @@ -1535,9 +1535,6 @@ static int gen11_dsi_dsc_compute_config(struct intel_encoder *encoder, vdsc_cfg->convert_rgb = true; - /* FIXME: initialize from VBT */ - vdsc_cfg->rc_model_size = DSC_RC_MODEL_SIZE_CONST; - ret = intel_dsc_compute_params(encoder, crtc_state); if (ret) return ret; -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/4] phy: Add LVDS configuration options
Hi Liu,
Thank you for the patch.
On Fri, Dec 04, 2020 at 03:33:42PM +0800, Liu Ying wrote:
> This patch allows LVDS PHYs to be configured through
> the generic functions and through a custom structure
> added to the generic union.
>
> The parameters added here are based on common LVDS PHY
> implementation practices. The set of parameters
> should cover all potential users.
>
> Cc: Kishon Vijay Abraham I
> Cc: Vinod Koul
> Cc: NXP Linux Team
> Signed-off-by: Liu Ying
> ---
> include/linux/phy/phy-lvds.h | 48
>
> include/linux/phy/phy.h | 4
> 2 files changed, 52 insertions(+)
> create mode 100644 include/linux/phy/phy-lvds.h
>
> diff --git a/include/linux/phy/phy-lvds.h b/include/linux/phy/phy-lvds.h
> new file mode 100644
> index ..1b5b9d6
> --- /dev/null
> +++ b/include/linux/phy/phy-lvds.h
> @@ -0,0 +1,48 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Copyright 2020 NXP
> + */
> +
> +#ifndef __PHY_LVDS_H_
> +#define __PHY_LVDS_H_
> +
> +/**
> + * struct phy_configure_opts_lvds - LVDS configuration set
> + *
> + * This structure is used to represent the configuration state of a
> + * LVDS phy.
> + */
> +struct phy_configure_opts_lvds {
> + /**
> + * @bits_per_lane_and_dclk_cycle:
> + *
> + * Number of bits per data lane and differential clock cycle.
> + */
> + unsigned int bits_per_lane_and_dclk_cycle;
I see in patch 4/4 that you only support 7, can the value be any
different ?
> +
> + /**
> + * @differential_clk_rate:
> + *
> + * Clock rate, in Hertz, of the LVDS differential clock.
> + */
> + unsigned long differential_clk_rate;
> +
> + /**
> + * @lanes:
> + *
> + * Number of active, consecutive, data lanes, starting from
> + * lane 0, used for the transmissions.
> + */
> + unsigned int lanes;
> +
> + /**
> + * @is_slave:
> + *
> + * Boolean, true if the phy is a slave which works together
> + * with a master phy to support dual link transmission,
> + * otherwise a regular phy or a master phy.
> + */
> + bool is_slave;
> +};
> +
> +#endif /* __PHY_LVDS_H_ */
> diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
> index e435bdb..d450b44 100644
> --- a/include/linux/phy/phy.h
> +++ b/include/linux/phy/phy.h
> @@ -17,6 +17,7 @@
> #include
>
> #include
> +#include
> #include
>
> struct phy;
> @@ -51,10 +52,13 @@ enum phy_mode {
> * the MIPI_DPHY phy mode.
> * @dp: Configuration set applicable for phys supporting
> * the DisplayPort protocol.
> + * @lvds:Configuration set applicable for phys supporting
> + * the LVDS phy mode.
> */
> union phy_configure_opts {
> struct phy_configure_opts_mipi_dphy mipi_dphy;
> struct phy_configure_opts_dpdp;
> + struct phy_configure_opts_lvds lvds;
> };
>
> /**
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH] drm/panel: Make backlight attachment lazy
On Mon, Dec 07, 2020 at 10:44:46PM -0600, Bjorn Andersson wrote: > Some bridge chips, such as the TI SN65DSI86 DSI/eDP bridge, provides > means of generating a PWM signal for backlight control of the attached > panel. The provided PWM chip is typically controlled by the > pwm-backlight driver, which if tied to the panel will provide DPMS. > > But with the current implementation the panel will refuse to probe > because the bridge driver has yet to probe and register the PWM chip, > and the bridge driver will refuse to probe because it's unable to find > the panel. What you're describing is basically a circular dependency. Can't we get rid of that in some other way? Why exactly does the bridge driver refuse to probe if the panel can't be found? In other words, I see how the bridge would /use/ the panel in that it forward a video stream to it. But how does the panel /use/ the bridge? Thierry signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH][next] drm/mediatek: avoid dereferencing a null hdmi_phy on an error message
On 08-12-20, 09:50, Chunfeng Yun wrote:
> On Mon, 2020-12-07 at 15:09 +, Colin King wrote:
> > From: Colin Ian King
> >
> > Currently there is a null pointer check for hdmi_phy that implies it
> > may be null, however a dev_err messages dereferences this potential null
> > pointer. Avoid a null pointer dereference by only emitting the dev_err
> > message if hdmi_phy is non-null. It is a moot point if the error message
> > needs to be printed at all, but since this is a relatively new piece of
> > code it may be useful to keep the message in for the moment in case there
> > are unforseen errors that need to be reported.
> >
> > Addresses-Coverity: ("Dereference after null check")
> > Fixes: be28b6507c46 ("drm/mediatek: separate hdmi phy to different file")
> > Signed-off-by: Colin Ian King
> > ---
> > drivers/phy/mediatek/phy-mtk-hdmi.c | 5 +++--
> > 1 file changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/phy/mediatek/phy-mtk-hdmi.c
> > b/drivers/phy/mediatek/phy-mtk-hdmi.c
> > index c5c61f5a9ea0..5184054783c7 100644
> > --- a/drivers/phy/mediatek/phy-mtk-hdmi.c
> > +++ b/drivers/phy/mediatek/phy-mtk-hdmi.c
> > @@ -84,8 +84,9 @@ mtk_hdmi_phy_dev_get_ops(const struct mtk_hdmi_phy
> > *hdmi_phy)
> > hdmi_phy->conf->hdmi_phy_disable_tmds)
> > return &mtk_hdmi_phy_dev_ops;
> >
> > - dev_err(hdmi_phy->dev, "Failed to get dev ops of phy\n");
> > - return NULL;
> > + if (hdmi_phy)
> > + dev_err(hdmi_phy->dev, "Failed to get dev ops of phy\n");
> > + return NULL;
> indentation: one tab before return
I have applied this and fixed the indent while applying
--
~Vinod
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 0/2] drm: add DisplayPort connector
On 03/12/2020 23:24, Sam Ravnborg wrote: > Hi Tomi, > On Thu, Dec 03, 2020 at 01:52:21PM +0200, Tomi Valkeinen wrote: >> Hi DRM Bridge maintainers, >> >> On 30/11/2020 13:29, Tomi Valkeinen wrote: >>> Hi, >>> >>> This series adds the DT bindings and a driver for DisplayPort connector. >>> >>> Minor changes since v3: >>> - Added Laurent's reviewed-bys >>> - Added $ref to graph schema >>> - Use 'ret' instead of 'r' >>> - Add the missing period >>> >>> Tomi >>> >>> Tomi Valkeinen (2): >>> dt-bindings: dp-connector: add binding for DisplayPort connector >>> drm/bridge: display-connector: add DP support >>> >>> .../display/connector/dp-connector.yaml | 56 +++ >>> drivers/gpu/drm/bridge/display-connector.c| 46 ++- >>> 2 files changed, 100 insertions(+), 2 deletions(-) >>> create mode 100644 >>> Documentation/devicetree/bindings/display/connector/dp-connector.yaml >>> >> >> Is it ok for me to push this to drm-misc-next, or does one of the bridge >> maintainers want to handle >> that? > > IMO apply them to drm-misc-next. > But I am not bridge maintainer so... There has been no comments, so pushing today. Tomi -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/ttm: cleanup BO size handling
On Tue, Dec 08, 2020 at 12:33:00AM +0800, Christian König wrote:
> Based on an idea from Dave, but cleaned up a bit.
>
> We had multiple fields for essentially the same thing.
>
> Now bo->size is the original size of the BO in arbitrary
> units, usually bytes.
>
> bo->mem.num_pages is the size in number of pages in the
> resource domain of bo->mem.mem_type.
>
> Signed-off-by: Christian König
Reviewed-by: Huang Rui
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 2 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c | 2 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_object.c| 2 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_object.h| 4 +--
> drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h | 2 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 6 ++--
> drivers/gpu/drm/amd/amdgpu/mes_v10_1.c| 2 +-
> drivers/gpu/drm/nouveau/nouveau_bo.c | 10 +++---
> drivers/gpu/drm/nouveau/nouveau_display.c | 8 ++---
> drivers/gpu/drm/nouveau/nouveau_prime.c | 4 +--
> drivers/gpu/drm/nouveau/nv17_fence.c | 2 +-
> drivers/gpu/drm/nouveau/nv50_fence.c | 2 +-
> drivers/gpu/drm/qxl/qxl_object.h | 2 +-
> drivers/gpu/drm/radeon/radeon_cs.c| 3 +-
> drivers/gpu/drm/radeon/radeon_object.c| 13
> drivers/gpu/drm/radeon/radeon_object.h| 4 +--
> drivers/gpu/drm/radeon/radeon_prime.c | 4 +--
> drivers/gpu/drm/radeon/radeon_trace.h | 2 +-
> drivers/gpu/drm/radeon/radeon_ttm.c | 2 +-
> drivers/gpu/drm/ttm/ttm_bo.c | 33 ++-
> drivers/gpu/drm/ttm/ttm_bo_util.c | 11 +++
> drivers/gpu/drm/ttm/ttm_bo_vm.c | 6 ++--
> drivers/gpu/drm/ttm/ttm_tt.c | 2 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_blit.c | 4 +--
> drivers/gpu/drm/vmwgfx/vmwgfx_bo.c| 6 ++--
> drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c | 2 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 4 +--
> drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c | 5 ++-
> drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 2 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_page_dirty.c| 8 ++---
> drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 2 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_shader.c| 3 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c | 4 +--
> drivers/gpu/drm/vmwgfx/vmwgfx_surface.c | 7 ++--
> include/drm/ttm/ttm_bo_api.h | 6 ++--
> include/drm/ttm/ttm_resource.h| 1 -
> 36 files changed, 82 insertions(+), 100 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
> index e5919efca870..c4c93f19d273 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
> @@ -269,7 +269,7 @@ static struct sg_table *amdgpu_dma_buf_map(struct
> dma_buf_attachment *attach,
> case TTM_PL_TT:
> sgt = drm_prime_pages_to_sg(obj->dev,
> bo->tbo.ttm->pages,
> - bo->tbo.num_pages);
> + bo->tbo.ttm->num_pages);
> if (IS_ERR(sgt))
> return sgt;
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
> index 056cb87d09ea..52bcd1b5582f 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
> @@ -121,7 +121,7 @@ uint64_t amdgpu_gmc_agp_addr(struct ttm_buffer_object *bo)
> {
> struct amdgpu_device *adev = amdgpu_ttm_adev(bo->bdev);
>
> - if (bo->num_pages != 1 || bo->ttm->caching == ttm_cached)
> + if (bo->ttm->num_pages != 1 || bo->ttm->caching == ttm_cached)
> return AMDGPU_BO_INVALID_OFFSET;
>
> if (bo->ttm->dma_address[0] + PAGE_SIZE >= adev->gmc.agp_size)
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> index c6c9723d3d8a..381ecc4788d5 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> @@ -787,7 +787,7 @@ int amdgpu_bo_kmap(struct amdgpu_bo *bo, void **ptr)
> if (r < 0)
> return r;
>
> - r = ttm_bo_kmap(&bo->tbo, 0, bo->tbo.num_pages, &bo->kmap);
> + r = ttm_bo_kmap(&bo->tbo, 0, bo->tbo.mem.num_pages, &bo->kmap);
> if (r)
> return r;
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
> index ed47cbac4f75..176ed3615151 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
> @@ -174,12 +174,12 @@ static inline void amdgpu_bo_unreserve(struct amdgpu_bo
> *bo)
>
> static inline unsigned long amdgpu_bo_size(struct amdgpu_bo *bo)
> {
> - return bo->tbo.num_pages << PAGE_SHIFT;
> + return bo->tb
Re: [PATCH v5 09/29] drm/omap: dsi: cleanup dispc channel usage
Hi Tomi,
Thank you for the patch.
On Tue, Dec 08, 2020 at 02:28:35PM +0200, Tomi Valkeinen wrote:
> The "channel" usage in omap dsi driver is confusing. As the first step,
> change "channel" to "dispc_channel" when dealing with the dispc channel.
>
> Signed-off-by: Tomi Valkeinen
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/omapdrm/dss/dsi.c | 16
> 1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c
> b/drivers/gpu/drm/omapdrm/dss/dsi.c
> index c78ae99c8742..cf0dc4872d14 100644
> --- a/drivers/gpu/drm/omapdrm/dss/dsi.c
> +++ b/drivers/gpu/drm/omapdrm/dss/dsi.c
> @@ -3978,10 +3978,10 @@ static int dsi_configure_dispc_clocks(struct dsi_data
> *dsi)
>
> static int dsi_display_init_dispc(struct dsi_data *dsi)
> {
> - enum omap_channel channel = dsi->output.dispc_channel;
> + enum omap_channel dispc_channel = dsi->output.dispc_channel;
> int r;
>
> - dss_select_lcd_clk_source(dsi->dss, channel, dsi->module_id == 0 ?
> + dss_select_lcd_clk_source(dsi->dss, dispc_channel, dsi->module_id == 0 ?
> DSS_CLK_SRC_PLL1_1 :
> DSS_CLK_SRC_PLL2_1);
>
> @@ -4017,19 +4017,19 @@ static int dsi_display_init_dispc(struct dsi_data
> *dsi)
> dss_mgr_unregister_framedone_handler(&dsi->output,
> dsi_framedone_irq_callback, dsi);
> err:
> - dss_select_lcd_clk_source(dsi->dss, channel, DSS_CLK_SRC_FCK);
> + dss_select_lcd_clk_source(dsi->dss, dispc_channel, DSS_CLK_SRC_FCK);
> return r;
> }
>
> static void dsi_display_uninit_dispc(struct dsi_data *dsi)
> {
> - enum omap_channel channel = dsi->output.dispc_channel;
> + enum omap_channel dispc_channel = dsi->output.dispc_channel;
>
> if (dsi->mode == OMAP_DSS_DSI_CMD_MODE)
> dss_mgr_unregister_framedone_handler(&dsi->output,
> dsi_framedone_irq_callback, dsi);
>
> - dss_select_lcd_clk_source(dsi->dss, channel, DSS_CLK_SRC_FCK);
> + dss_select_lcd_clk_source(dsi->dss, dispc_channel, DSS_CLK_SRC_FCK);
> }
>
> static int dsi_configure_dsi_clocks(struct dsi_data *dsi)
> @@ -4846,12 +4846,12 @@ static int dsi_set_config(struct omap_dss_device
> *dssdev,
> }
>
> /*
> - * Return a hardcoded channel for the DSI output. This should work for
> + * Return a hardcoded dispc channel for the DSI output. This should work for
> * current use cases, but this can be later expanded to either resolve
> * the channel in some more dynamic manner, or get the channel as a user
> * parameter.
> */
> -static enum omap_channel dsi_get_channel(struct dsi_data *dsi)
> +static enum omap_channel dsi_get_dispc_channel(struct dsi_data *dsi)
> {
> switch (dsi->data->model) {
> case DSI_MODEL_OMAP3:
> @@ -5403,7 +5403,7 @@ static int dsi_init_output(struct dsi_data *dsi)
>
> out->type = OMAP_DISPLAY_TYPE_DSI;
> out->name = dsi->module_id == 0 ? "dsi.0" : "dsi.1";
> - out->dispc_channel = dsi_get_channel(dsi);
> + out->dispc_channel = dsi_get_dispc_channel(dsi);
> out->dsi_ops = &dsi_ops;
> out->of_port = 0;
> out->bus_flags = DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 10/29] drm/omap: dsi: rename 'channel' to 'vc'
Hi Tomi,
Thank you for the patch.
On Tue, Dec 08, 2020 at 02:28:36PM +0200, Tomi Valkeinen wrote:
> The "channel" usage in omap dsi driver is confusing. We have three
> different "channels":
>
> 1) DSI virtual channel ID. This is a number from 0 to 3, included in the
> packet payload.
>
> 2) VC. This is a register block in the DSI IP. There are four of those
> blocks. A VC is a DSI "pipeline", with defined fifo settings, data
> source (cpu or dispc), and some other settings. It has no relation to
> the 1).
>
> 3) dispc channel. It's the "pipeline" number dispc uses to send pixel
> data.
>
> The previous patch handled the third case.
>
> To start fixing 1) and 2), we first rename all uses of 'channel' to
> 'vc', as in most of the cases that is the correct thing to use.
>
> However, in some places 1) and 2) have gotten mixed up (i.e. the code
> uses msg->channel when it should use vc), which will be fixed in the
> following patch.
>
> Note that mixing 1) and 2) currently is "fine", as at the moment we only
> support DSI peripherals with DSI virtual channel 0, and we always use
> VC0 to send data. So both 1) and 2) are always 0.
>
> Signed-off-by: Tomi Valkeinen
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/omapdrm/dss/dsi.c | 220 +++---
> 1 file changed, 110 insertions(+), 110 deletions(-)
>
> diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c
> b/drivers/gpu/drm/omapdrm/dss/dsi.c
> index cf0dc4872d14..273159e8f992 100644
> --- a/drivers/gpu/drm/omapdrm/dss/dsi.c
> +++ b/drivers/gpu/drm/omapdrm/dss/dsi.c
> @@ -214,7 +214,7 @@ static void dsi_set_ulps_auto(struct dsi_data *dsi, bool
> enable);
> static int dsi_display_init_dispc(struct dsi_data *dsi);
> static void dsi_display_uninit_dispc(struct dsi_data *dsi);
>
> -static int dsi_vc_send_null(struct dsi_data *dsi, int channel);
> +static int dsi_vc_send_null(struct dsi_data *dsi, int vc);
>
> static ssize_t _omap_dsi_host_transfer(struct dsi_data *dsi,
> const struct mipi_dsi_msg *msg);
> @@ -376,7 +376,7 @@ struct dsi_data {
> /* space for a copy used by the interrupt handler */
> struct dsi_isr_tables isr_tables_copy;
>
> - int update_channel;
> + int update_vc;
> #ifdef DSI_PERF_MEASURE
> unsigned int update_bytes;
> #endif
> @@ -639,7 +639,7 @@ static void print_irq_status(u32 status)
> #undef PIS
> }
>
> -static void print_irq_status_vc(int channel, u32 status)
> +static void print_irq_status_vc(int vc, u32 status)
> {
> if (status == 0)
> return;
> @@ -650,7 +650,7 @@ static void print_irq_status_vc(int channel, u32 status)
> #define PIS(x) (status & DSI_VC_IRQ_##x) ? (#x " ") : ""
>
> pr_debug("DSI VC(%d) IRQ 0x%x: %s%s%s%s%s%s%s%s%s\n",
> - channel,
> + vc,
> status,
> PIS(CS),
> PIS(ECC_CORR),
> @@ -1031,7 +1031,7 @@ static int dsi_unregister_isr(struct dsi_data *dsi,
> omap_dsi_isr_t isr,
> return r;
> }
>
> -static int dsi_register_isr_vc(struct dsi_data *dsi, int channel,
> +static int dsi_register_isr_vc(struct dsi_data *dsi, int vc,
> omap_dsi_isr_t isr, void *arg, u32 mask)
> {
> unsigned long flags;
> @@ -1040,18 +1040,18 @@ static int dsi_register_isr_vc(struct dsi_data *dsi,
> int channel,
> spin_lock_irqsave(&dsi->irq_lock, flags);
>
> r = _dsi_register_isr(isr, arg, mask,
> - dsi->isr_tables.isr_table_vc[channel],
> - ARRAY_SIZE(dsi->isr_tables.isr_table_vc[channel]));
> + dsi->isr_tables.isr_table_vc[vc],
> + ARRAY_SIZE(dsi->isr_tables.isr_table_vc[vc]));
>
> if (r == 0)
> - _omap_dsi_set_irqs_vc(dsi, channel);
> + _omap_dsi_set_irqs_vc(dsi, vc);
>
> spin_unlock_irqrestore(&dsi->irq_lock, flags);
>
> return r;
> }
>
> -static int dsi_unregister_isr_vc(struct dsi_data *dsi, int channel,
> +static int dsi_unregister_isr_vc(struct dsi_data *dsi, int vc,
>omap_dsi_isr_t isr, void *arg, u32 mask)
> {
> unsigned long flags;
> @@ -1060,11 +1060,11 @@ static int dsi_unregister_isr_vc(struct dsi_data
> *dsi, int channel,
> spin_lock_irqsave(&dsi->irq_lock, flags);
>
> r = _dsi_unregister_isr(isr, arg, mask,
> - dsi->isr_tables.isr_table_vc[channel],
> - ARRAY_SIZE(dsi->isr_tables.isr_table_vc[channel]));
> + dsi->isr_tables.isr_table_vc[vc],
> + ARRAY_SIZE(dsi->isr_tables.isr_table_vc[vc]));
>
> if (r == 0)
> - _omap_dsi_set_irqs_vc(dsi, channel);
> + _omap_dsi_set_irqs_vc(dsi, vc);
>
> spin_unlock_irqrestore(&dsi->irq_lock, flags);
>
> @@ -2232,9 +2232,9 @@ static int dsi_force_tx_stop_mode_io(struct dsi_data
> *dsi)
> return 0;
> }
>
> -static bool dsi_vc
