[PATCH v2] of_device: removed #include that caused a recursion in included headers
Both of_platform.h and of_device.h were included each other. In of_device.h, removed unneeded #include to of_platform.h and added include to of_platform.h in the files that needs it. Signed-off-by: Hadar Gat --- v2: add include to of_platform.h in more files. (reported due other builds) arch/sparc/mm/io-unit.c | 1 + arch/sparc/mm/iommu.c | 1 + drivers/base/platform.c | 1 + drivers/bus/imx-weim.c| 1 + drivers/bus/vexpress-config.c | 1 + drivers/clk/mediatek/clk-mt7622-aud.c | 1 + drivers/dma/at_hdmac.c| 1 + drivers/dma/stm32-dmamux.c| 1 + drivers/dma/ti/dma-crossbar.c | 1 + drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 1 + drivers/gpu/drm/msm/hdmi/hdmi.c | 1 + drivers/gpu/drm/msm/msm_drv.c | 1 + drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 1 + drivers/gpu/drm/sun4i/sun4i_tcon.c| 1 + drivers/iio/adc/stm32-adc-core.c | 1 + drivers/iio/adc/stm32-dfsdm-adc.c | 1 + drivers/iio/adc/stm32-dfsdm-core.c| 1 + drivers/iommu/tegra-smmu.c| 1 + drivers/memory/atmel-ebi.c| 1 + drivers/mfd/palmas.c | 1 + drivers/mfd/ssbi.c| 1 + drivers/mtd/nand/raw/omap2.c | 1 + drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 1 + drivers/net/ethernet/ti/cpsw.c| 1 + drivers/phy/tegra/xusb.c | 1 + drivers/pinctrl/freescale/pinctrl-imx1-core.c | 1 + drivers/pinctrl/nomadik/pinctrl-nomadik.c | 1 + drivers/soc/samsung/exynos-pmu.c | 1 + drivers/soc/sunxi/sunxi_sram.c| 1 + include/linux/of_device.h | 2 -- lib/genalloc.c| 1 + 31 files changed, 30 insertions(+), 2 deletions(-) diff --git a/arch/sparc/mm/io-unit.c b/arch/sparc/mm/io-unit.c index 289276b..5638399 100644 --- a/arch/sparc/mm/io-unit.c +++ b/arch/sparc/mm/io-unit.c @@ -15,6 +15,7 @@ #include #include #include +#include #include #include diff --git a/arch/sparc/mm/iommu.c b/arch/sparc/mm/iommu.c index b00dde1..9cbb2e7 100644 --- a/arch/sparc/mm/iommu.c +++ b/arch/sparc/mm/iommu.c @@ -16,6 +16,7 @@ #include #include #include +#include #include #include diff --git a/drivers/base/platform.c b/drivers/base/platform.c index 520..f549274b 100644 --- a/drivers/base/platform.c +++ b/drivers/base/platform.c @@ -12,6 +12,7 @@ #include #include #include +#include #include #include #include diff --git a/drivers/bus/imx-weim.c b/drivers/bus/imx-weim.c index 28bb65a..8c786da 100644 --- a/drivers/bus/imx-weim.c +++ b/drivers/bus/imx-weim.c @@ -11,6 +11,7 @@ #include #include #include +#include #include #include #include diff --git a/drivers/bus/vexpress-config.c b/drivers/bus/vexpress-config.c index ff70575..12b8b0b 100644 --- a/drivers/bus/vexpress-config.c +++ b/drivers/bus/vexpress-config.c @@ -8,6 +8,7 @@ #include #include #include +#include #include diff --git a/drivers/clk/mediatek/clk-mt7622-aud.c b/drivers/clk/mediatek/clk-mt7622-aud.c index 2bd4295..8cbb68f 100644 --- a/drivers/clk/mediatek/clk-mt7622-aud.c +++ b/drivers/clk/mediatek/clk-mt7622-aud.c @@ -9,6 +9,7 @@ #include #include #include +#include #include #include "clk-mtk.h" diff --git a/drivers/dma/at_hdmac.c b/drivers/dma/at_hdmac.c index 73a2078..388f8e10 100644 --- a/drivers/dma/at_hdmac.c +++ b/drivers/dma/at_hdmac.c @@ -20,6 +20,7 @@ #include #include #include +#include #include #include "at_hdmac_regs.h" diff --git a/drivers/dma/stm32-dmamux.c b/drivers/dma/stm32-dmamux.c index 12f7637..b704896 100644 --- a/drivers/dma/stm32-dmamux.c +++ b/drivers/dma/stm32-dmamux.c @@ -16,6 +16,7 @@ #include #include #include +#include #include #include #include diff --git a/drivers/dma/ti/dma-crossbar.c b/drivers/dma/ti/dma-crossbar.c index 4ba8fa5..2c0fd44 100644 --- a/drivers/dma/ti/dma-crossbar.c +++ b/drivers/dma/ti/dma-crossbar.c @@ -10,6 +10,7 @@ #include #include #include +#include #include #define TI_XBAR_DRA7 0 diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c index c4e71ab..f523254 100644 --- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c +++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c @@ -6,6 +6,7 @@ #include #include #include +#include #include #include "a6xx_gpu.h" diff --git a/drivers/gpu/drm/msm/hdmi/hdmi.c b/drivers/gpu/drm/msm/hdmi/hdmi.c index 737453b..5034d40 100644 --- a/drivers/gpu/drm/msm/hdmi/hdmi.c +++ b/drivers/gpu/drm/msm/hdmi/hdmi.c @@ -7,6 +7,7 @@ #include #include +#include #include #include "hd
Re: [RFC 0/6] Regressions for "imply" behavior change
On Thu, 16 Apr 2020, Arnd Bergmann wrote: > On Thu, Apr 16, 2020 at 12:17 PM Jani Nikula > wrote: > > > > On Thu, 16 Apr 2020, Arnd Bergmann wrote: > > > On Thu, Apr 16, 2020 at 5:25 AM Saeed Mahameed > > > wrote: > > >> BTW how about adding a new Kconfig option to hide the details of > > >> ( BAR || !BAR) ? as Jason already explained and suggested, this will > > >> make it easier for the users and developers to understand the actual > > >> meaning behind this tristate weird condition. > > >> > > >> e.g have a new keyword: > > >> reach VXLAN > > >> which will be equivalent to: > > >> depends on VXLAN && !VXLAN > > > > > > I'd love to see that, but I'm not sure what keyword is best. For your > > > suggestion of "reach", that would probably do the job, but I'm not > > > sure if this ends up being more or less confusing than what we have > > > today. > > > > Ah, perfect bikeshedding topic! > > > > Perhaps "uses"? If the dependency is enabled it gets used as a > > dependency. > > That seems to be the best naming suggestion so far What I don't like about "uses" is that it doesn't convey the conditional dependency. It could be mistaken as being synonymous to "select". What about "depends_if" ? The rationale is that this is actually a dependency, but only if the related symbol is set (i.e. not n or empty). > Right. OTOH whoever implements it gets to pick the color of the > bikeshed. ;-) Absolutely. But some brainstorming can't hurt. Nicolas ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH trivial 0/6] Fix misspellings of "Analog Devices"
On Thu, 2020-04-16 at 12:30 +0200, Geert Uytterhoeven wrote: > [External] > > Hi all, > > In several files the company also known as ADI is spelled as "Analog > Device". However, according to https://www.analog.com/, the company > name is spelled "Analog Devices". > > Hence this patch series, one per subsystem, fixes these misspellings. > > Thanks for your comments! For the entire series: Reviewed-by: Alexandru Ardelean Many thanks :) Alex > > Geert Uytterhoeven (6): > dt-bindings: Fix misspellings of "Analog Devices" > dma: Fix misspelling of "Analog Devices" > drm: Fix misspellings of "Analog Devices" > iio: Fix misspellings of "Analog Devices" > ALSA: Fix misspellings of "Analog Devices" > ASoC: Fix misspellings of "Analog Devices" > > .../devicetree/bindings/display/bridge/adi,adv7123.txt| 4 ++-- > .../devicetree/bindings/display/bridge/adi,adv7511.txt| 4 ++-- > Documentation/devicetree/bindings/dma/adi,axi-dmac.txt| 2 +- > Documentation/devicetree/bindings/iio/dac/ad5755.txt | 2 +- > drivers/dma/Kconfig | 2 +- > drivers/gpu/drm/bridge/adv7511/Kconfig| 2 +- > drivers/gpu/drm/drm_fb_cma_helper.c | 2 +- > drivers/gpu/drm/tegra/fb.c| 2 +- > drivers/iio/adc/ad7791.c | 2 +- > drivers/iio/trigger/iio-trig-hrtimer.c| 2 +- > drivers/staging/iio/Documentation/overview.txt| 2 +- > sound/isa/ad1816a/ad1816a.c | 2 +- > sound/pci/ac97/ac97_patch.c | 2 +- > sound/pci/hda/Kconfig | 4 ++-- > sound/soc/codecs/ad1980.c | 2 +- > sound/soc/codecs/ad73311.c| 2 +- > sound/soc/codecs/wm8782.c | 2 +- > 17 files changed, 20 insertions(+), 20 deletions(-) > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 2/4] dt-bindings: display: convert atmel lcdc to DT Schema
On Wed, Apr 15, 2020 at 06:44:27PM +0200, Sam Ravnborg wrote:
> Hi Maxime.
>
> On Tue, Apr 14, 2020 at 10:30:10AM +0200, Maxime Ripard wrote:
> > On Sun, Apr 12, 2020 at 08:20:10PM +0200, Sam Ravnborg wrote:
> > > Add a new binding file to describe the bindings
> > > for the Atmel LCDC IP.
> > > This replaces the old txt based binding.
> > >
> > > The binding file describes the current binding,
> > > including properties to specify register values etc.
> > > The binding will be updated in a follow-up patch,
> > > the current binding describes the actual situation.
> > >
> > > This new binding file replaces the old .txt based
> > > binding which is deleted.
> > >
> > > Signed-off-by: Sam Ravnborg
> > > ---
> > > .../bindings/display/atmel,lcdc.txt | 88 ---
> > > .../bindings/display/atmel/lcdc.yaml | 137 ++
> > > 2 files changed, 137 insertions(+), 88 deletions(-)
> > > delete mode 100644
> > > Documentation/devicetree/bindings/display/atmel,lcdc.txt
> > > create mode 100644
> > > Documentation/devicetree/bindings/display/atmel/lcdc.yaml
> > >
> > > diff --git a/Documentation/devicetree/bindings/display/atmel,lcdc.txt
> > > b/Documentation/devicetree/bindings/display/atmel,lcdc.txt
> > > deleted file mode 100644
> > > index acb5a0132127..
> > > --- a/Documentation/devicetree/bindings/display/atmel,lcdc.txt
> > > +++ /dev/null
> > > @@ -1,88 +0,0 @@
> > > -Atmel LCDC Framebuffer
> > > --
> > > -
> > > -Required properties:
> > > -- compatible :
> > > - "atmel,at91sam9261-lcdc" ,
> > > - "atmel,at91sam9263-lcdc" ,
> > > - "atmel,at91sam9g10-lcdc" ,
> > > - "atmel,at91sam9g45-lcdc" ,
> > > - "atmel,at91sam9g45es-lcdc" ,
> > > - "atmel,at91sam9rl-lcdc" ,
> > > - "atmel,at32ap-lcdc"
> > > -- reg : Should contain 1 register ranges(address and length).
> > > - Can contain an additional register range(address and length)
> > > - for fixed framebuffer memory. Useful for dedicated memories.
> > > -- interrupts : framebuffer controller interrupt
> > > -- display: a phandle pointing to the display node
> > > -
> > > -Required nodes:
> > > -- display: a display node is required to initialize the lcd panel
> > > - This should be in the board dts.
> > > -- default-mode: a videomode within the display with timing parameters
> > > - as specified below.
> > > -
> > > -Optional properties:
> > > -- lcd-supply: Regulator for LCD supply voltage.
> > > -
> > > -Example:
> > > -
> > > - fb0: fb@0050 {
> > > - compatible = "atmel,at91sam9g45-lcdc";
> > > - reg = <0x0050 0x1000>;
> > > - interrupts = <23 3 0>;
> > > - pinctrl-names = "default";
> > > - pinctrl-0 = <&pinctrl_fb>;
> > > - display = <&display0>;
> > > - #address-cells = <1>;
> > > - #size-cells = <1>;
> > > -
> > > - };
> > > -
> > > -Example for fixed framebuffer memory:
> > > -
> > > - fb0: fb@0050 {
> > > - compatible = "atmel,at91sam9263-lcdc";
> > > - reg = <0x0070 0x1000 0x7000 0x20>;
> > > - [...]
> > > - };
> > > -
> > > -Atmel LCDC Display
> > > --
> > > -Required properties (as per of_videomode_helper):
> > > -
> > > - - atmel,dmacon: dma controller configuration
> > > - - atmel,lcdcon2: lcd controller configuration
> > > - - atmel,guard-time: lcd guard time (Delay in frame periods)
> > > - - bits-per-pixel: lcd panel bit-depth.
> > > -
> > > -Optional properties (as per of_videomode_helper):
> > > - - atmel,lcdcon-backlight: enable backlight
> > > - - atmel,lcdcon-backlight-inverted: invert backlight PWM polarity
> > > - - atmel,lcd-wiring-mode: lcd wiring mode "RGB" or "BRG"
> > > - - atmel,power-control-gpio: gpio to power on or off the LCD (as many as
> > > needed)
> > > -
> > > -Example:
> > > - display0: display {
> > > - bits-per-pixel = <32>;
> > > - atmel,lcdcon-backlight;
> > > - atmel,dmacon = <0x1>;
> > > - atmel,lcdcon2 = <0x80008002>;
> > > - atmel,guard-time = <9>;
> > > - atmel,lcd-wiring-mode = <1>;
> > > -
> > > - display-timings {
> > > - native-mode = <&timing0>;
> > > - timing0: timing0 {
> > > - clock-frequency = <900>;
> > > - hactive = <480>;
> > > - vactive = <272>;
> > > - hback-porch = <1>;
> > > - hfront-porch = <1>;
> > > - vback-porch = <40>;
> > > - vfront-porch = <1>;
> > > - hsync-len = <45>;
> > > - vsync-len = <1>;
> > > - };
> > > - };
> > > - };
> > > diff --git a/Documentation/devicetree/bindings/display/atmel/lcdc.yaml
> > > b/Documentation/devicetree/bindings/display/atmel/lcdc.yaml
> > > new file mode 100644
> > >
[PATCH 1/2] drm: panel: Set connector type for LP120UP1
The LP120UP1 is a eDP panel, set the connector type accordingly.
Signed-off-by: Enric Balletbo i Serra
---
drivers/gpu/drm/panel/panel-simple.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 3ad828eaefe1..6253635601bb 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -2168,6 +2168,7 @@ static const struct panel_desc lg_lp120up1 = {
.width = 267,
.height = 183,
},
+ .connector_type = DRM_MODE_CONNECTOR_eDP,
};
static const struct drm_display_mode lg_lp129qe_mode = {
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 2/2] drm/tegra: output: rgb: Support LVDS encoder bridge
Newer Tegra device-trees will specify a video output graph that involves
LVDS encoder bridge, This patch adds support for the LVDS encoder bridge
to the RGB output, allowing us to model display hardware properly.
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/tegra/drm.h| 2 ++
drivers/gpu/drm/tegra/output.c | 10 ++
drivers/gpu/drm/tegra/rgb.c| 34 ++
3 files changed, 46 insertions(+)
diff --git a/drivers/gpu/drm/tegra/drm.h b/drivers/gpu/drm/tegra/drm.h
index 804869799305..cccd368b6752 100644
--- a/drivers/gpu/drm/tegra/drm.h
+++ b/drivers/gpu/drm/tegra/drm.h
@@ -12,6 +12,7 @@
#include
#include
+#include
#include
#include
#include
@@ -116,6 +117,7 @@ struct tegra_output {
struct device_node *of_node;
struct device *dev;
+ struct drm_bridge *bridge;
struct drm_panel *panel;
struct i2c_adapter *ddc;
const struct edid *edid;
diff --git a/drivers/gpu/drm/tegra/output.c b/drivers/gpu/drm/tegra/output.c
index a6a711d54e88..37fc6b8c173f 100644
--- a/drivers/gpu/drm/tegra/output.c
+++ b/drivers/gpu/drm/tegra/output.c
@@ -180,6 +180,16 @@ int tegra_output_init(struct drm_device *drm, struct
tegra_output *output)
int connector_type;
int err;
+ if (output->bridge) {
+ err = drm_bridge_attach(&output->encoder, output->bridge,
+ NULL, DRM_BRIDGE_ATTACH_NO_CONNECTOR);
+ if (err) {
+ dev_err(output->dev, "cannot connect bridge: %d\n",
+ err);
+ return err;
+ }
+ }
+
if (output->panel) {
err = drm_panel_attach(output->panel, &output->connector);
if (err < 0)
diff --git a/drivers/gpu/drm/tegra/rgb.c b/drivers/gpu/drm/tegra/rgb.c
index 0562a7eb793f..0df213e92664 100644
--- a/drivers/gpu/drm/tegra/rgb.c
+++ b/drivers/gpu/drm/tegra/rgb.c
@@ -5,6 +5,7 @@
*/
#include
+#include
#include
#include
@@ -210,6 +211,7 @@ static const struct drm_encoder_helper_funcs
tegra_rgb_encoder_helper_funcs = {
int tegra_dc_rgb_probe(struct tegra_dc *dc)
{
+ const unsigned int encoder_port = 0, panel_port = 1;
struct device_node *np;
struct tegra_rgb *rgb;
int err;
@@ -226,6 +228,38 @@ int tegra_dc_rgb_probe(struct tegra_dc *dc)
rgb->output.of_node = np;
rgb->dc = dc;
+ /*
+* Tegra devices that have LVDS panel utilize LVDS-encoder bridge
+* for converting 24/18 RGB data-lanes into 8 lanes. Encoder usually
+* have a powerdown control which needs to be enabled in order to
+* transfer data to the panel. Historically devices that use an older
+* device-tree version didn't model the bridge, assuming that encoder
+* is turned ON by default, while today's DRM allows us to model LVDS
+* encoder properly.
+*
+* Newer device-trees may utilize output->encoder->panel graph.
+*
+* For older device-trees we fall back to use nvidia,panel phandle.
+*/
+ np = of_graph_get_remote_node(rgb->output.of_node, encoder_port, -1);
+ if (np) {
+ rgb->output.bridge = of_drm_find_bridge(np);
+ of_node_put(np);
+
+ if (!rgb->output.bridge)
+ return -EPROBE_DEFER;
+
+ np = of_graph_get_remote_node(rgb->output.bridge->of_node,
+ panel_port, -1);
+ if (np) {
+ rgb->output.panel = of_drm_find_panel(np);
+ of_node_put(np);
+
+ if (IS_ERR(rgb->output.panel))
+ return PTR_ERR(rgb->output.panel);
+ }
+ }
+
err = tegra_output_probe(&rgb->output);
if (err < 0)
return err;
--
2.26.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/tegra: dc: Omit superfluous error message in tegra_dc_probe()
In the function tegra_dc_probe(), when get irq failed, the function
platform_get_irq() logs an error message, so remove redundant message
here.
Signed-off-by: Tang Bin
---
drivers/gpu/drm/tegra/dc.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
index 7c70fd31a..d26fb16d6 100644
--- a/drivers/gpu/drm/tegra/dc.c
+++ b/drivers/gpu/drm/tegra/dc.c
@@ -2566,10 +2566,8 @@ static int tegra_dc_probe(struct platform_device *pdev)
return PTR_ERR(dc->regs);
dc->irq = platform_get_irq(pdev, 0);
- if (dc->irq < 0) {
- dev_err(&pdev->dev, "failed to get IRQ\n");
+ if (dc->irq < 0)
return -ENXIO;
- }
err = tegra_dc_rgb_probe(dc);
if (err < 0 && err != -ENODEV) {
--
2.20.1.windows.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/bridge: ps8640: Let panel to set the connector type
The panel connector type should be set by the panel not the bridge, so remove the connector_type assignment. Signed-off-by: Enric Balletbo i Serra --- drivers/gpu/drm/bridge/parade-ps8640.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c b/drivers/gpu/drm/bridge/parade-ps8640.c index 956b76e0a44d..13755d278db6 100644 --- a/drivers/gpu/drm/bridge/parade-ps8640.c +++ b/drivers/gpu/drm/bridge/parade-ps8640.c @@ -278,8 +278,6 @@ static int ps8640_probe(struct i2c_client *client) if (!panel) return -ENODEV; - panel->connector_type = DRM_MODE_CONNECTOR_eDP; - ps_bridge->panel_bridge = devm_drm_panel_bridge_add(dev, panel); if (IS_ERR(ps_bridge->panel_bridge)) return PTR_ERR(ps_bridge->panel_bridge); -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v12 09/11] backlight: pwm_bl: Use 64-bit division function
On Thu, Apr 16, 2020 at 10:44:20AM +0100, Lee Jones wrote: > On Wed, 08 Apr 2020, Guru Das Srinagesh wrote: > > > Since the PWM framework is switching struct pwm_state.period's datatype > > to u64, prepare for this transition by using div_u64 to handle a 64-bit > > dividend instead of a straight division operation. > > > > Cc: Lee Jones > > Cc: Daniel Thompson > > Cc: Jingoo Han > > Cc: Bartlomiej Zolnierkiewicz > > Cc: linux-...@vger.kernel.org > > Cc: dri-devel@lists.freedesktop.org > > Cc: linux-fb...@vger.kernel.org > > > > Signed-off-by: Guru Das Srinagesh > > Reviewed-by: Daniel Thompson > > --- > > drivers/video/backlight/pwm_bl.c | 3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > I see that this is part of a large set, but the remainder of the > patches have been hidden from me. Sorry about that, the full series is here: [1]. > Does this mean I can apply this patch on its own? I'll defer to Uwe on this point as I am not sure of the implications of taking in this single patch and not the entire series. Thank you. Guru Das. [1] https://www.spinics.net/lists/linux-pwm/msg12131.html ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 2/2] drm/tegra: output: rgb: Support LVDS encoder bridge
16.04.2020 20:41, Laurent Pinchart пишет:
...
>> +if (output->bridge) {
>> +err = drm_bridge_attach(&output->encoder, output->bridge,
>> +NULL, DRM_BRIDGE_ATTACH_NO_CONNECTOR);
>
> Using DRM_BRIDGE_ATTACH_NO_CONNECTOR is definitely the way to go, but
> please be aware that it will require creating a connector and an encoder
> manually (which I think this driver already does), and using the bridge
> operations to implement the connector operations. I highly recommend
> using the DRM bridge connector helper for this purpose.
Okay, I missed that there is a DRM bridge connector helper. Thank you
very much for the suggestion, I'll switch to the bridge helper in v4.
>> +if (err) {
>> +dev_err(output->dev, "cannot connect bridge: %d\n",
>> +err);
>> +return err;
>> +}
>> +}
>> +
>> if (output->panel) {
>
> May I also recommend switching to the DRM panel bridge helper ? It will
> simplify the code.
Could you please clarify what is the "DRM panel bridge helper"?
I think we won't need any additional helpers after switching to the
bridge connector helper, no?
...
>> +np = of_graph_get_remote_node(rgb->output.bridge->of_node,
>> + panel_port, -1);
>
> This shouldn't be needed, the LVDS codec bridge driver should already
> get the panel and handle it internally. You only need to handle panels
> in this driver when they're connected directly to the RGB input.
Indeed, it won't be needed if we will use the bridge connector helper.
Thank you very much for the clarifications!
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] dt-bindings: Clean-up schema indentation formatting
On 15/04/2020 19:55:48-0500, Rob Herring wrote: > Fix various inconsistencies in schema indentation. Most of these are > list indentation which should be 2 spaces more than the start of the > enclosing keyword. This doesn't matter functionally, but affects running > scripts which do transforms on the schema files. > > Signed-off-by: Rob Herring Acked-by: Alexandre Belloni > --- > .../devicetree/bindings/arm/altera.yaml | 6 +- > .../amlogic/amlogic,meson-gx-ao-secure.yaml | 2 +- > .../devicetree/bindings/arm/bitmain.yaml | 2 +- > .../devicetree/bindings/arm/nxp/lpc32xx.yaml | 9 ++- > .../bindings/arm/socionext/uniphier.yaml | 26 > .../bindings/arm/stm32/st,mlahb.yaml | 2 +- > .../bindings/arm/stm32/st,stm32-syscon.yaml | 6 +- > .../bindings/ata/faraday,ftide010.yaml| 4 +- > .../bindings/bus/allwinner,sun8i-a23-rsb.yaml | 4 +- > .../clock/allwinner,sun4i-a10-gates-clk.yaml | 8 +-- > .../devicetree/bindings/clock/fsl,plldig.yaml | 17 +++-- > .../devicetree/bindings/clock/qcom,mmcc.yaml | 16 ++--- > .../bindings/connector/usb-connector.yaml | 6 +- > .../crypto/allwinner,sun4i-a10-crypto.yaml| 14 ++-- > .../bindings/crypto/allwinner,sun8i-ce.yaml | 16 ++--- > .../bindings/crypto/amlogic,gxl-crypto.yaml | 2 +- > .../display/allwinner,sun4i-a10-hdmi.yaml | 40 ++-- > .../display/allwinner,sun4i-a10-tcon.yaml | 58 - > .../display/allwinner,sun6i-a31-mipi-dsi.yaml | 28 > .../display/allwinner,sun8i-a83t-dw-hdmi.yaml | 10 +-- > .../bindings/display/bridge/lvds-codec.yaml | 18 +++--- > .../display/panel/sony,acx424akp.yaml | 2 +- > .../display/panel/xinpeng,xpp055c272.yaml | 4 +- > .../bindings/display/renesas,cmm.yaml | 16 ++--- > .../devicetree/bindings/dma/ti/k3-udma.yaml | 8 +-- > .../bindings/gpio/brcm,xgs-iproc-gpio.yaml| 2 +- > .../bindings/gpu/arm,mali-midgard.yaml| 18 +++--- > .../devicetree/bindings/gpu/vivante,gc.yaml | 2 +- > .../devicetree/bindings/i2c/i2c-rk3x.yaml | 10 +-- > .../bindings/iio/adc/adi,ad7124.yaml | 4 +- > .../bindings/iio/adc/lltc,ltc2496.yaml| 6 +- > .../input/allwinner,sun4i-a10-lradc-keys.yaml | 4 +- > .../bindings/input/touchscreen/goodix.yaml| 2 +- > .../bindings/interconnect/qcom,msm8916.yaml | 4 +- > .../bindings/interconnect/qcom,msm8974.yaml | 4 +- > .../bindings/interconnect/qcom,qcs404.yaml| 4 +- > .../allwinner,sun7i-a20-sc-nmi.yaml | 12 ++-- > .../intel,ixp4xx-interrupt.yaml | 8 +-- > .../interrupt-controller/st,stm32-exti.yaml | 12 ++-- > .../bindings/iommu/samsung,sysmmu.yaml| 10 +-- > .../bindings/mailbox/st,stm32-ipcc.yaml | 2 +- > .../media/allwinner,sun4i-a10-csi.yaml| 28 > .../bindings/media/amlogic,gx-vdec.yaml | 14 ++-- > .../bindings/media/renesas,ceu.yaml | 28 > .../bindings/media/renesas,vin.yaml | 8 +-- > .../devicetree/bindings/media/ti,vpe.yaml | 2 +- > .../memory-controllers/fsl/imx8m-ddrc.yaml| 6 +- > .../bindings/mfd/st,stm32-lptimer.yaml| 4 +- > .../bindings/mfd/st,stm32-timers.yaml | 4 +- > .../devicetree/bindings/mfd/syscon.yaml | 12 ++-- > .../devicetree/bindings/mmc/cdns,sdhci.yaml | 2 +- > .../bindings/mmc/rockchip-dw-mshc.yaml| 16 ++--- > .../bindings/mmc/socionext,uniphier-sd.yaml | 14 ++-- > .../devicetree/bindings/mtd/denali,nand.yaml | 4 +- > .../net/allwinner,sun8i-a83t-emac.yaml| 4 +- > .../bindings/net/can/bosch,m_can.yaml | 52 +++ > .../bindings/net/renesas,ether.yaml | 4 +- > .../bindings/net/ti,cpsw-switch.yaml | 12 ++-- > .../bindings/net/ti,davinci-mdio.yaml | 27 > .../bindings/phy/intel,lgm-emmc-phy.yaml | 2 +- > .../devicetree/bindings/pwm/pwm-samsung.yaml | 16 ++--- > .../bindings/remoteproc/st,stm32-rproc.yaml | 2 +- > .../reset/brcm,bcm7216-pcie-sata-rescal.yaml | 4 +- > .../devicetree/bindings/rtc/st,stm32-rtc.yaml | 38 +-- > .../bindings/serial/amlogic,meson-uart.yaml | 16 ++--- > .../devicetree/bindings/serial/rs485.yaml | 17 ++--- > .../bindings/soc/amlogic/amlogic,canvas.yaml | 10 +-- > .../bindings/sound/renesas,fsi.yaml | 16 ++--- > .../bindings/spi/qcom,spi-qcom-qspi.yaml | 10 +-- > .../devicetree/bindings/spi/renesas,hspi.yaml | 4 +- > .../devicetree/bindings/spi/spi-pl022.yaml| 2 +- > .../bindings/spi/st,stm32-qspi.yaml | 4 +- > .../allwinner,sun4i-a10-system-control.yaml | 64 +-- > .../bindings/thermal/amlogic,thermal.yaml | 10 +-- > .../bindings/timer/arm,arch_timer.yaml| 4 +- > .../bindings/timer/arm,arch_timer_mmio.yaml | 4 +- > .../devicetree/bindings/usb/dwc2.yaml | 8 +-- > 77 files changed, 450 insertions(+), 450 deletions(-) > > diff --
[PATCH v2 5/7] drm/mediatek: mtk_dsi: Use simple encoder
The mtk_dsi driver uses an empty implementation for its encoder. Replace
the code with the generic simple encoder.
Signed-off-by: Enric Balletbo i Serra
---
Changes in v2: None
drivers/gpu/drm/mediatek/mtk_dsi.c | 14 +++---
1 file changed, 3 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
b/drivers/gpu/drm/mediatek/mtk_dsi.c
index 3400d6686c85..48361c1e9f34 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
#include "mtk_drm_ddp_comp.h"
@@ -788,15 +789,6 @@ static void mtk_output_dsi_disable(struct mtk_dsi *dsi)
dsi->enabled = false;
}
-static void mtk_dsi_encoder_destroy(struct drm_encoder *encoder)
-{
- drm_encoder_cleanup(encoder);
-}
-
-static const struct drm_encoder_funcs mtk_dsi_encoder_funcs = {
- .destroy = mtk_dsi_encoder_destroy,
-};
-
static int mtk_dsi_create_conn_enc(struct drm_device *drm, struct mtk_dsi
*dsi);
static void mtk_dsi_destroy_conn_enc(struct mtk_dsi *dsi);
@@ -1126,8 +1118,8 @@ static int mtk_dsi_encoder_init(struct drm_device *drm,
struct mtk_dsi *dsi)
{
int ret;
- ret = drm_encoder_init(drm, &dsi->encoder, &mtk_dsi_encoder_funcs,
- DRM_MODE_ENCODER_DSI, NULL);
+ ret = drm_simple_encoder_init(drm, &dsi->encoder,
+ DRM_MODE_ENCODER_DSI);
if (ret) {
DRM_ERROR("Failed to encoder init to drm\n");
return ret;
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 1/4] dt-bindings: display: convert atmel-hlcdc to DT Schema
On Wed, Apr 15, 2020 at 06:39:56PM +0200, Sam Ravnborg wrote: > Hi Maxime. > > On Tue, Apr 14, 2020 at 10:28:03AM +0200, Maxime Ripard wrote: > > Hi Sam, > > > > On Sun, Apr 12, 2020 at 08:20:09PM +0200, Sam Ravnborg wrote: > > > diff --git > > > a/Documentation/devicetree/bindings/display/atmel/hlcdc-dc.yaml > > > b/Documentation/devicetree/bindings/display/atmel/hlcdc-dc.yaml > > > new file mode 100644 > > > index ..7eb6266a25a2 > > > --- /dev/null > > > +++ b/Documentation/devicetree/bindings/display/atmel/hlcdc-dc.yaml > > > @@ -0,0 +1,102 @@ > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > > +%YAML 1.2 > > > +--- > > > +$id: http://devicetree.org/schemas/display/atmel/hlcdc-dc.yaml# > > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > > + > > > +title: Atmel HLCDC (High LCD Controller) display controller > > > + > > > +maintainers: > > > + - Sam Ravnborg > > > + - Boris Brezillon > > > + > > > +description: | > > > + The Atmel HLCDC Display Controller is subdevice of the HLCDC MFD > > > device. > > > + See ../../mfd/atmel-hlcdc.yaml for more details. > > > + > > > +properties: > > > + compatible: > > > +const: atmel,hlcdc-display-controller > > > + > > > + "#address-cells": > > > +const: 1 > > > + "#size-cells": > > > +const: 0 > > > + > > > +required: > > > + - compatible > > > + - "#address-cells" > > > + - "#size-cells" > > > + > > > +patternProperties: > > > + "^port@[0-9]$": > > > +type: object > > > +description: | > > > + A port node with endpoint definitions as defined in > > > + ../../media/video-interfaces.txt > > > + > > > +properties: > > > + "#address-cells": > > > +const: 1 > > > + > > > + "#size-cells": > > > +const: 0 > > > + > > > + reg: > > > +maxItems: 1 > > > +description: The virtual number of the port > > > + > > > +patternProperties: > > > + "^endpoint(@[0-9])$": > > > > I guess you meant ^endpoint(@[0-9])?$ instead? > > I think "^endpoint@[0-9]$" will do the trick. > No need for endpoints with numbers higher than 9. If you want to stick to pedantic DT, then if there's a single endpoint, you should avoid reg and the unit-address, and this is something that dtc will complain about (even though it's silenced in Linux), so yeah, ? seems the way to go. Maxime signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC 0/6] Regressions for "imply" behavior change
On Thu, Apr 16, 2020 at 05:58:31PM +0200, Arnd Bergmann wrote: > On Thu, Apr 16, 2020 at 4:52 PM Jason Gunthorpe wrote: > > On Thu, Apr 16, 2020 at 02:38:50PM +0200, Arnd Bergmann wrote: > > > On Thu, Apr 16, 2020 at 12:17 PM Jani Nikula > > > wrote: > > > > Of course, this is all just talk until someone(tm) posts a patch > > > > actually making the change. I've looked at the kconfig tool sources > > > > before; not going to make the same mistake again. > > > > > > Right. OTOH whoever implements it gets to pick the color of the > > > bikeshed. ;-) > > > > I hope someone takes it up, especially now that imply, which > > apparently used to do this, doesn't any more :) > > The old 'imply' was something completely different, it was more of a > 'try to select if you can so we can assume it's there, but give up > if it can only be a module and we need it to be built-in". But it seems to have done this as a side-effect, and drivers were relying on that, otherwise this series wouldn't exist.. Jason ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC 0/6] Regressions for "imply" behavior change
On Thu, Apr 16, 2020 at 02:38:50PM +0200, Arnd Bergmann wrote: > On Thu, Apr 16, 2020 at 12:17 PM Jani Nikula > wrote: > > > > On Thu, 16 Apr 2020, Arnd Bergmann wrote: > > > On Thu, Apr 16, 2020 at 5:25 AM Saeed Mahameed > > > wrote: > > >> BTW how about adding a new Kconfig option to hide the details of > > >> ( BAR || !BAR) ? as Jason already explained and suggested, this will > > >> make it easier for the users and developers to understand the actual > > >> meaning behind this tristate weird condition. > > >> > > >> e.g have a new keyword: > > >> reach VXLAN > > >> which will be equivalent to: > > >> depends on VXLAN && !VXLAN > > > > > > I'd love to see that, but I'm not sure what keyword is best. For your > > > suggestion of "reach", that would probably do the job, but I'm not > > > sure if this ends up being more or less confusing than what we have > > > today. > > > > Ah, perfect bikeshedding topic! > > > > Perhaps "uses"? If the dependency is enabled it gets used as a > > dependency. > > That seems to be the best naming suggestion so far Uses also makes sense to me. > > Of course, this is all just talk until someone(tm) posts a patch > > actually making the change. I've looked at the kconfig tool sources > > before; not going to make the same mistake again. > > Right. OTOH whoever implements it gets to pick the color of the > bikeshed. ;-) I hope someone takes it up, especially now that imply, which apparently used to do this, doesn't any more :) Jason ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/bridge: panel: Return always an error pointer in drm_panel_bridge_add()
Since commit 89958b7cd955 ("drm/bridge: panel: Infer connector type from
panel by default"), drm_panel_bridge_add() and their variants can return
NULL and an error pointer. This is fine but none of the actual users of
the API are checking for the NULL value. Instead of change all the
users, seems reasonable to return an error pointer instead. So change
the returned value for those functions when the connector type is unknown.
Suggested-by: Laurent Pinchart
Signed-off-by: Enric Balletbo i Serra
---
drivers/gpu/drm/bridge/panel.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/bridge/panel.c b/drivers/gpu/drm/bridge/panel.c
index 8461ee8304ba..7a3df0f319f3 100644
--- a/drivers/gpu/drm/bridge/panel.c
+++ b/drivers/gpu/drm/bridge/panel.c
@@ -166,7 +166,7 @@ static const struct drm_bridge_funcs
panel_bridge_bridge_funcs = {
*
* The connector type is set to @panel->connector_type, which must be set to a
* known type. Calling this function with a panel whose connector type is
- * DRM_MODE_CONNECTOR_Unknown will return NULL.
+ * DRM_MODE_CONNECTOR_Unknown will return ERR_PTR(-EINVAL).
*
* See devm_drm_panel_bridge_add() for an automatically managed version of this
* function.
@@ -174,7 +174,7 @@ static const struct drm_bridge_funcs
panel_bridge_bridge_funcs = {
struct drm_bridge *drm_panel_bridge_add(struct drm_panel *panel)
{
if (WARN_ON(panel->connector_type == DRM_MODE_CONNECTOR_Unknown))
- return NULL;
+ return ERR_PTR(-EINVAL);
return drm_panel_bridge_add_typed(panel, panel->connector_type);
}
@@ -265,7 +265,7 @@ struct drm_bridge *devm_drm_panel_bridge_add(struct device
*dev,
struct drm_panel *panel)
{
if (WARN_ON(panel->connector_type == DRM_MODE_CONNECTOR_Unknown))
- return NULL;
+ return ERR_PTR(-EINVAL);
return devm_drm_panel_bridge_add_typed(dev, panel,
panel->connector_type);
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 7/7] drm/mediatek: mtk_dsi: Create connector for bridges
Hi Laurent,
On 16/4/20 19:36, Laurent Pinchart wrote:
> Hi Enric,
>
> On Thu, Apr 16, 2020 at 08:35:26PM +0300, Laurent Pinchart wrote:
>> On Thu, Apr 16, 2020 at 05:57:19PM +0200, Enric Balletbo i Serra wrote:
>>> Use the drm_bridge_connector helper to create a connector for pipelines
>>> that use drm_bridge. This allows splitting connector operations across
>>> multiple bridges when necessary, instead of having the last bridge in
>>> the chain creating the connector and handling all connector operations
>>> internally.
>>
>> That's the right direction, but this should be done in the mtk display
>> controller driver core, not in here. I'm OK with the code being here as
>> an interim measure if needed to move forward, but that should then be
>> temporary only.
It'd be nice if we can do this as an interim measure for now, so at least we
have the embedded display working. IIUC to move that to the display controller
driver core I should also convert/rework the mtk_dpi and mtk_hdmi drivers. This
is used for the external display on my device but to fully support this I'll
also need to rework the bridge chain logic to handle the multi-sink/multi-source
use case. This is something I plan to work on but I suspect won't be easy and
will trigger lots of discussions, and, of course, some time.
So, if is fine I won't move this for now.
Thanks,
Enric
>
> I forgot to mention that the drm_encoder should also move out of the
> bridge driver to the display controller driver.
>
>>> Signed-off-by: Enric Balletbo i Serra
>>> ---
>>>
>>> Changes in v2: None
>>>
>>> drivers/gpu/drm/mediatek/mtk_dsi.c | 14 +-
>>> 1 file changed, 13 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
>>> b/drivers/gpu/drm/mediatek/mtk_dsi.c
>>> index 44718fa3d1ca..2f8876c32864 100644
>>> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
>>> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
>>> @@ -17,6 +17,7 @@
>>>
>>> #include
>>> #include
>>> +#include
>>> #include
>>> #include
>>> #include
>>> @@ -184,6 +185,7 @@ struct mtk_dsi {
>>> struct drm_bridge bridge;
>>> struct drm_bridge *panel_bridge;
>>> struct drm_bridge *next_bridge;
>>> + struct drm_connector *connector;
>>> struct phy *phy;
>>>
>>> void __iomem *regs;
>>> @@ -983,10 +985,19 @@ static int mtk_dsi_encoder_init(struct drm_device
>>> *drm, struct mtk_dsi *dsi)
>>> */
>>> dsi->encoder.possible_crtcs = 1;
>>>
>>> - ret = drm_bridge_attach(&dsi->encoder, &dsi->bridge, NULL, 0);
>>> + ret = drm_bridge_attach(&dsi->encoder, &dsi->bridge, NULL,
>>> + DRM_BRIDGE_ATTACH_NO_CONNECTOR);
>>> if (ret)
>>> goto err_cleanup_encoder;
>>>
>>> + dsi->connector = drm_bridge_connector_init(drm, &dsi->encoder);
>>> + if (IS_ERR(dsi->connector)) {
>>> + DRM_ERROR("Unable to create bridge connector\n");
>>> + ret = PTR_ERR(dsi->connector);
>>> + goto err_cleanup_encoder;
>>> + }
>>> + drm_connector_attach_encoder(dsi->connector, &dsi->encoder);
>>> +
>>> return 0;
>>>
>>> err_cleanup_encoder:
>>> @@ -1144,6 +1155,7 @@ static int mtk_dsi_probe(struct platform_device *pdev)
>>>
>>> dsi->bridge.funcs = &mtk_dsi_bridge_funcs;
>>> dsi->bridge.of_node = dev->of_node;
>>> + dsi->bridge.type = DRM_MODE_CONNECTOR_DSI;
>>
>> I think this line belongs to the patch that adds drm_bridge support to
>> this driver.
>>
>>>
>>> drm_bridge_add(&dsi->bridge);
>>>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 1/2] drm/tegra: output: Don't leak OF node on error
16.04.2020 20:27, Laurent Pinchart пишет: > Hi Dmitry, > > Thank you for the patch. > > On Thu, Apr 16, 2020 at 08:24:04PM +0300, Dmitry Osipenko wrote: >> The OF node should be put before returning error in tegra_output_probe(), >> otherwise node's refcount will be leaked. >> >> Signed-off-by: Dmitry Osipenko > > Reviewed-by: Laurent Pinchart Hello Laurent, That is the fastest kernel review I ever got, thank you :) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v10 0/2] Panel rotation patches
15.04.2020 00:32, dbasehore . пишет: > On Tue, Apr 14, 2020 at 2:18 PM Dmitry Osipenko wrote: >> >> 14.04.2020 22:32, dbasehore . пишет: >>> Hi Dmitry, sorry for the late reply. >>> >>> On Sun, Mar 8, 2020 at 12:25 PM Dmitry Osipenko wrote: 06.03.2020 03:21, Derek Basehore пишет: > This adds the plumbing for reading panel rotation from the devicetree > and sets up adding a panel property for the panel orientation on > Mediatek SoCs when a rotation is present. Hello Derek and everyone, I'm looking at adding display rotation support to NVIDIA Tegra DRM driver because some devices have display panel physically mounted upside-down, and thus, display controller's scan-out needs to be rotated by 180° in this case. Derek, yours panel-rotation patches add support for assigning panel's orientation to the connector, but then only primary display plane receives rotation value in [1], while rotation needs to be applied to all available overlay/cursor planes and this should happen in other places than [1] as well. >>> >>> This is intended. We don't correct the output in the kernel. We >>> instead rely on notifying userspace that the panel is rotated, then we >>> handle it there. >>> [1] drm_client_modeset_commit_atomic() Please also note that in a case of the scan-out rotation, plane's coordinates need to be changed in accordance to the display's rotation. I looked briefly through the DRM code and my understanding that the DRM core currently doesn't support use-case where scan-out needs to rotated based on a panel's orientation, correct? Is it the use-case you're working on for the Mediatek driver? >>> >>> Yes, we rely on userspace to rotate the output. The major reason for >>> this is because there may not be a "free" hardware rotation that can >>> be applied to the overlay. Sean Paul and others also preferred that >>> userspace control what is output to the screen instead of the kernel >>> taking care of it. This code just adds the drm property to the panel. >>> >> >> Could you please explain what that userspace is? > > This was added for Chrome OS, which uses its own graphics stack, > Ozone, instead of Xorg. > Thank you very much for the clarification. It's probably not a big problem for something monolithic and customized like ChromeOS to issue a software update in order to take into account all specifics of a particular device, but this doesn't work nicely for a generic software, like a usual Linux distro. >> AFAIK, things like Xorg modesetting don't support that orientation property. In my case it's not only the display panel which is upside-down, but also the touchscreen. Hence both display output and touchscreen input need to be rotated at once, otherwise you'll end up with either display or input being upside-down. The 180° rotation should be free on NVIDIA Tegra. There are no known limitations for the planes and BSP kernel video driver handles the plane's coordinates/framebuffer rotation within the driver. The kernel's input subsystem allows us to transparently (for userspace) remap the touchscreen input (by specifying generic touchscreen device-tree properties), while this is not the case for the DRM subsystem. @Thierry, @Sean, @Daniel, could you please help me to understand how a coordinated display / input rotation could be implemented, making the rotation transparent to the user (i.e. avoiding xorg.conf hacking and etc)? It should be nice if display's output could be flipped within the DRM driver, hiding this fact from userspace. Will it be okay if we'll add a transparent-rotation support specifically to the Tegra DRM driver? For example if device-tree contains nvidia,display-flip-y property, then the Tegra DRM driver will take care of rotating coordinates/framebuffer of the display planes. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC 0/6] Regressions for "imply" behavior change
On Thu, 2020-04-16 at 11:52 -0300, Jason Gunthorpe wrote: > On Thu, Apr 16, 2020 at 02:38:50PM +0200, Arnd Bergmann wrote: > > On Thu, Apr 16, 2020 at 12:17 PM Jani Nikula > > wrote: > > > On Thu, 16 Apr 2020, Arnd Bergmann wrote: > > > > On Thu, Apr 16, 2020 at 5:25 AM Saeed Mahameed < > > > > sae...@mellanox.com> wrote: > > > > > BTW how about adding a new Kconfig option to hide the details > > > > > of > > > > > ( BAR || !BAR) ? as Jason already explained and suggested, > > > > > this will > > > > > make it easier for the users and developers to understand the > > > > > actual > > > > > meaning behind this tristate weird condition. > > > > > > > > > > e.g have a new keyword: > > > > > reach VXLAN > > > > > which will be equivalent to: > > > > > depends on VXLAN && !VXLAN > > > > > > > > I'd love to see that, but I'm not sure what keyword is best. > > > > For your > > > > suggestion of "reach", that would probably do the job, but I'm > > > > not > > > > sure if this ends up being more or less confusing than what we > > > > have > > > > today. > > > > > > Ah, perfect bikeshedding topic! > > > > > > Perhaps "uses"? If the dependency is enabled it gets used as a > > > dependency. > > > > That seems to be the best naming suggestion so far > > Uses also makes sense to me. > > > > Of course, this is all just talk until someone(tm) posts a patch > > > actually making the change. I've looked at the kconfig tool > > > sources > > > before; not going to make the same mistake again. > > > > Right. OTOH whoever implements it gets to pick the color of the > > bikeshed. ;-) > > I hope someone takes it up, especially now that imply, which > apparently used to do this, doesn't any more :) > Well, I have a patch since yesterday.. i though You and Arnd didn't like the idea, so i dropped the whole thing :), but apparently you just didn't like the name of the new option. "uses" seems like a good name .. I will post the patch. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 6/7] drm/mediatek: mtk_dsi: Use the drm_panel_bridge API
Replace the manual panel handling code by a drm_panel_bridge. This
simplifies the driver and allows all components in the display pipeline
to be treated as bridges, paving the way to generic connector handling.
Signed-off-by: Enric Balletbo i Serra
---
Changes in v2:
- Do not set connector_type for panel here. (Sam Ravnborg)
drivers/gpu/drm/mediatek/mtk_dsi.c | 177 -
1 file changed, 19 insertions(+), 158 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
b/drivers/gpu/drm/mediatek/mtk_dsi.c
index 48361c1e9f34..44718fa3d1ca 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -182,8 +182,7 @@ struct mtk_dsi {
struct mipi_dsi_host host;
struct drm_encoder encoder;
struct drm_bridge bridge;
- struct drm_connector conn;
- struct drm_panel *panel;
+ struct drm_bridge *panel_bridge;
struct drm_bridge *next_bridge;
struct phy *phy;
@@ -212,11 +211,6 @@ static inline struct mtk_dsi *bridge_to_dsi(struct
drm_bridge *b)
return container_of(b, struct mtk_dsi, bridge);
}
-static inline struct mtk_dsi *connector_to_dsi(struct drm_connector *c)
-{
- return container_of(c, struct mtk_dsi, conn);
-}
-
static inline struct mtk_dsi *host_to_dsi(struct mipi_dsi_host *h)
{
return container_of(h, struct mtk_dsi, host);
@@ -682,16 +676,7 @@ static int mtk_dsi_poweron(struct mtk_dsi *dsi)
mtk_dsi_lane0_ulp_mode_leave(dsi);
mtk_dsi_clk_hs_mode(dsi, 0);
- if (dsi->panel) {
- if (drm_panel_prepare(dsi->panel)) {
- DRM_ERROR("failed to prepare the panel\n");
- goto err_disable_digital_clk;
- }
- }
-
return 0;
-err_disable_digital_clk:
- clk_disable_unprepare(dsi->digital_clk);
err_disable_engine_clk:
clk_disable_unprepare(dsi->engine_clk);
err_phy_power_off:
@@ -718,15 +703,7 @@ static void mtk_dsi_poweroff(struct mtk_dsi *dsi)
*/
mtk_dsi_stop(dsi);
- if (!mtk_dsi_switch_to_cmd_mode(dsi, VM_DONE_INT_FLAG, 500)) {
- if (dsi->panel) {
- if (drm_panel_unprepare(dsi->panel)) {
- DRM_ERROR("failed to unprepare the panel\n");
- return;
- }
- }
- }
-
+ mtk_dsi_switch_to_cmd_mode(dsi, VM_DONE_INT_FLAG, 500);
mtk_dsi_reset_engine(dsi);
mtk_dsi_lane0_ulp_mode_enter(dsi);
mtk_dsi_clk_ulp_mode_enter(dsi);
@@ -757,19 +734,7 @@ static void mtk_output_dsi_enable(struct mtk_dsi *dsi)
mtk_dsi_start(dsi);
- if (dsi->panel) {
- if (drm_panel_enable(dsi->panel)) {
- DRM_ERROR("failed to enable the panel\n");
- goto err_dsi_power_off;
- }
- }
-
dsi->enabled = true;
-
- return;
-err_dsi_power_off:
- mtk_dsi_stop(dsi);
- mtk_dsi_poweroff(dsi);
}
static void mtk_output_dsi_disable(struct mtk_dsi *dsi)
@@ -777,34 +742,24 @@ static void mtk_output_dsi_disable(struct mtk_dsi *dsi)
if (!dsi->enabled)
return;
- if (dsi->panel) {
- if (drm_panel_disable(dsi->panel)) {
- DRM_ERROR("failed to disable the panel\n");
- return;
- }
- }
-
mtk_dsi_poweroff(dsi);
dsi->enabled = false;
}
-static int mtk_dsi_create_conn_enc(struct drm_device *drm, struct mtk_dsi
*dsi);
-static void mtk_dsi_destroy_conn_enc(struct mtk_dsi *dsi);
-
static int mtk_dsi_bridge_attach(struct drm_bridge *bridge,
enum drm_bridge_attach_flags flags)
{
struct mtk_dsi *dsi = bridge_to_dsi(bridge);
+ struct drm_bridge *next;
- return mtk_dsi_create_conn_enc(bridge->dev, dsi);
-}
-
-static void mtk_dsi_bridge_detach(struct drm_bridge *bridge)
-{
- struct mtk_dsi *dsi = bridge_to_dsi(bridge);
+ if (dsi->next_bridge)
+ next = dsi->next_bridge;
+ else
+ next = dsi->panel_bridge;
- mtk_dsi_destroy_conn_enc(dsi);
+ /* Attach the panel or bridge to the dsi bridge */
+ return drm_bridge_attach(bridge->encoder, next, &dsi->bridge, flags);
}
static void mtk_dsi_bridge_mode_set(struct drm_bridge *bridge,
@@ -830,101 +785,13 @@ static void mtk_dsi_bridge_enable(struct drm_bridge
*bridge)
mtk_output_dsi_enable(dsi);
}
-static int mtk_dsi_connector_get_modes(struct drm_connector *connector)
-{
- struct mtk_dsi *dsi = connector_to_dsi(connector);
-
- return drm_panel_get_modes(dsi->panel, connector);
-}
-
static const struct drm_bridge_funcs mtk_dsi_bridge_funcs = {
.attach = mtk_dsi_bridge_attach,
- .detach = mtk_dsi_bridge_detach,
.disable = mtk_dsi_bridge_disable,
.enable = mtk_dsi_bridge_enable,
Re: [PATCH] staging: android: ion: Skip sync if not mapped
On Thu, Apr 16, 2020 at 12:49:56PM +0300, Dan Carpenter wrote:
> On Tue, Apr 14, 2020 at 04:18:47PM +0200, Ørjan Eide wrote:
> > @@ -238,6 +242,10 @@ static void ion_unmap_dma_buf(struct
> > dma_buf_attachment *attachment,
> > struct sg_table *table,
> > enum dma_data_direction direction)
> > {
> > + struct ion_dma_buf_attachment *a = attachment->priv;
> > +
> > + a->mapped = false;
>
> Possibly a stupid question but here we're not holding a lock. Is
> concurrency an issue?
Thanks for taking a look.
Here and in ion_map_dma_buf(), where mapped is set, this should be safe.
The callers must synchronize calls to map/unmap, and ensure that they
are called in pairs.
I think there may be a potential issue between where mapped is set here,
and where it's read in ion_dma_buf_{begin,end}_cpu_access(). Coherency
issues the mapped bool won't blow up, at worst the contents of the
buffer may be invalid as cache synchronization may have been skipped.
This is still an improvement as before it would either crash or sync the
wrong page repeatedly.
The mapped state is tied to the dma_map_sg() call, so we would need take
the buffer->lock around both dma_map_sg and setting mapped to be sure
that the buffer will always have been synced.
> > +
> > dma_unmap_sg(attachment->dev, table->sgl, table->nents, direction);
> > }
> >
> > @@ -297,6 +305,8 @@ static int ion_dma_buf_begin_cpu_access(struct dma_buf
> > *dmabuf,
> >
> > mutex_lock(&buffer->lock);
> > list_for_each_entry(a, &buffer->attachments, list) {
> > + if (!a->mapped)
> > + continue;
> > dma_sync_sg_for_cpu(a->dev, a->table->sgl, a->table->nents,
> > direction);
> > }
--
Ørjan
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 1/2] drm/tegra: output: Don't leak OF node on error
The OF node should be put before returning error in tegra_output_probe(),
otherwise node's refcount will be leaked.
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/tegra/output.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/tegra/output.c b/drivers/gpu/drm/tegra/output.c
index e36e5e7c2f69..a6a711d54e88 100644
--- a/drivers/gpu/drm/tegra/output.c
+++ b/drivers/gpu/drm/tegra/output.c
@@ -102,10 +102,10 @@ int tegra_output_probe(struct tegra_output *output)
panel = of_parse_phandle(output->of_node, "nvidia,panel", 0);
if (panel) {
output->panel = of_drm_find_panel(panel);
+ of_node_put(panel);
+
if (IS_ERR(output->panel))
return PTR_ERR(output->panel);
-
- of_node_put(panel);
}
output->edid = of_get_property(output->of_node, "nvidia,edid", &size);
@@ -113,13 +113,12 @@ int tegra_output_probe(struct tegra_output *output)
ddc = of_parse_phandle(output->of_node, "nvidia,ddc-i2c-bus", 0);
if (ddc) {
output->ddc = of_find_i2c_adapter_by_node(ddc);
+ of_node_put(ddc);
+
if (!output->ddc) {
err = -EPROBE_DEFER;
- of_node_put(ddc);
return err;
}
-
- of_node_put(ddc);
}
output->hpd_gpio = devm_gpiod_get_from_of_node(output->dev,
--
2.26.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 2/2] drm/tegra: output: rgb: Support LVDS encoder bridge
17.04.2020 00:39, Laurent Pinchart пишет: > Hi Dmitry, > > On Fri, Apr 17, 2020 at 12:15:33AM +0300, Dmitry Osipenko wrote: >> 16.04.2020 23:50, Laurent Pinchart пишет: >>> On Thu, Apr 16, 2020 at 11:21:40PM +0300, Dmitry Osipenko wrote: 16.04.2020 21:52, Dmitry Osipenko пишет: ... >> May I also recommend switching to the DRM panel bridge helper ? It will >> simplify the code. > > Could you please clarify what is the "DRM panel bridge helper"? > > I think we won't need any additional helpers after switching to the > bridge connector helper, no? Actually, I now see that the panel needs to be manually attached to the connector. >>> >>> The DRM panel bridge helper creates a bridge from a panel (with >>> devm_drm_panel_bridge_add()). You can then attach that bridge to the >>> chain, like any other bridge, and the enable/disable operations will be >>> called automatically without any need to call the panel enable/disable >>> manually as done currently. >>> Still it's not apparent to me how to get panel out of the bridge. It looks like there is no such "panel helper" for the bridge API or I just can't find it. >>> >>> You don't need to get a panel out of the bridge. You should get the >>> bridge as done today, >> >> You mean "get the panel", correct? > > Yes, sorry. > >>> and wrap it in a bridge with >>> devm_drm_panel_bridge_add(). >>> >> >> The lvds-codec already wraps panel into the bridge using >> devm_drm_panel_bridge_add() and chains it for us, please see >> lvds_codec_probe() / lvds_codec_attach(). >> >> Does it mean that lvds-codec is not supporting the new model? > > No, that *is* the new model :-) As I think I've commented during review, > when you have an LVDS encoder and a panel, you don't need to handle the > panel at all. When you have an RGB panel connected directly to the RGB > output, you need to wrap it in a bridge, exactly the same way as > lvds-codec does for its panel. > >> Everything works nicely using the old model, where bridge creates >> connector and attaches panel to it for us. >> >> [I'm still not sure what is the point to use the new model in a case of >> a simple chain of bridges] >> >> Using the new model, the connector isn't created by the bridge, so I >> need to duplicate that creation effort in the driver. Once the bridge >> connector is manually created, I need to attach panel to this connector, >> but panel is reachable only via the remote bridge (which wraps the panel). >> >> driver connector -> LVDS bridge -> panel bridge -> panel > > With the new model, > > 1. The display driver and the bridge drivers need to get hold of the >bridge directly connected to their output (for instance with >of_drm_find_panel()). If the output is connected to a panel, they >need to wrap that panel in a bridge (with >devm_drm_panel_bridge_add()). I plan, in the future, to make creation >of panel bridges automatic, so drivers won't have to care. > > 2. The display driver needs to create a dummy drm_encoder for each of >its outputs (for instance with drm_simple_encoder_init()). > > 3. The display driver needs to create a drm_connector for each of its >outputs, and implement connector operations by delegating them to the >bridges in the pipeline. Unless there's a good reason not to do so, >this should be done with drm_bridge_connector_init(). > > That's it. Every driver then focusses on its own needs, bridge drivers > handle only the device they're associated with, and the DRM core and DRM > bridge connector helper will handle all the rest. > Thank you very much for the clarification again! :) Now I realized what was the missing part.. in my case display panel is mounted upside-down and display output needs to be rotated by 180°. I have a local patch (hack) that adds orientation-property support to the panel-lvds driver and previously the panel's orientation was assigned to the connector using drm_panel_attach(), but now this attachment doesn't happen and I found that panel_lvds_get_modes() missed drm_connector_set_panel_orientation() in my patch. Everything is okay once the panel_lvds_get_modes() is corrected. I'll prepare the v4. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 4/7] drm/mediatek: mtk_dsi: Convert to bridge driver
Convert mtk_dsi to a bridge driver with built-in encoder support for
compatibility with existing component drivers.
Signed-off-by: Enric Balletbo i Serra
---
Changes in v2: None
drivers/gpu/drm/mediatek/mtk_dsi.c | 106 ++---
1 file changed, 68 insertions(+), 38 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
b/drivers/gpu/drm/mediatek/mtk_dsi.c
index 44ee884cc31c..3400d6686c85 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -180,6 +180,7 @@ struct mtk_dsi {
struct device *dev;
struct mipi_dsi_host host;
struct drm_encoder encoder;
+ struct drm_bridge bridge;
struct drm_connector conn;
struct drm_panel *panel;
struct drm_bridge *next_bridge;
@@ -205,9 +206,9 @@ struct mtk_dsi {
const struct mtk_dsi_driver_data *driver_data;
};
-static inline struct mtk_dsi *encoder_to_dsi(struct drm_encoder *e)
+static inline struct mtk_dsi *bridge_to_dsi(struct drm_bridge *b)
{
- return container_of(e, struct mtk_dsi, encoder);
+ return container_of(b, struct mtk_dsi, bridge);
}
static inline struct mtk_dsi *connector_to_dsi(struct drm_connector *c)
@@ -796,32 +797,43 @@ static const struct drm_encoder_funcs
mtk_dsi_encoder_funcs = {
.destroy = mtk_dsi_encoder_destroy,
};
-static bool mtk_dsi_encoder_mode_fixup(struct drm_encoder *encoder,
- const struct drm_display_mode *mode,
- struct drm_display_mode *adjusted_mode)
+static int mtk_dsi_create_conn_enc(struct drm_device *drm, struct mtk_dsi
*dsi);
+static void mtk_dsi_destroy_conn_enc(struct mtk_dsi *dsi);
+
+static int mtk_dsi_bridge_attach(struct drm_bridge *bridge,
+enum drm_bridge_attach_flags flags)
{
- return true;
+ struct mtk_dsi *dsi = bridge_to_dsi(bridge);
+
+ return mtk_dsi_create_conn_enc(bridge->dev, dsi);
+}
+
+static void mtk_dsi_bridge_detach(struct drm_bridge *bridge)
+{
+ struct mtk_dsi *dsi = bridge_to_dsi(bridge);
+
+ mtk_dsi_destroy_conn_enc(dsi);
}
-static void mtk_dsi_encoder_mode_set(struct drm_encoder *encoder,
-struct drm_display_mode *mode,
-struct drm_display_mode *adjusted)
+static void mtk_dsi_bridge_mode_set(struct drm_bridge *bridge,
+ const struct drm_display_mode *mode,
+ const struct drm_display_mode *adjusted)
{
- struct mtk_dsi *dsi = encoder_to_dsi(encoder);
+ struct mtk_dsi *dsi = bridge_to_dsi(bridge);
drm_display_mode_to_videomode(adjusted, &dsi->vm);
}
-static void mtk_dsi_encoder_disable(struct drm_encoder *encoder)
+static void mtk_dsi_bridge_disable(struct drm_bridge *bridge)
{
- struct mtk_dsi *dsi = encoder_to_dsi(encoder);
+ struct mtk_dsi *dsi = bridge_to_dsi(bridge);
mtk_output_dsi_disable(dsi);
}
-static void mtk_dsi_encoder_enable(struct drm_encoder *encoder)
+static void mtk_dsi_bridge_enable(struct drm_bridge *bridge)
{
- struct mtk_dsi *dsi = encoder_to_dsi(encoder);
+ struct mtk_dsi *dsi = bridge_to_dsi(bridge);
mtk_output_dsi_enable(dsi);
}
@@ -833,11 +845,12 @@ static int mtk_dsi_connector_get_modes(struct
drm_connector *connector)
return drm_panel_get_modes(dsi->panel, connector);
}
-static const struct drm_encoder_helper_funcs mtk_dsi_encoder_helper_funcs = {
- .mode_fixup = mtk_dsi_encoder_mode_fixup,
- .mode_set = mtk_dsi_encoder_mode_set,
- .disable = mtk_dsi_encoder_disable,
- .enable = mtk_dsi_encoder_enable,
+static const struct drm_bridge_funcs mtk_dsi_bridge_funcs = {
+ .attach = mtk_dsi_bridge_attach,
+ .detach = mtk_dsi_bridge_detach,
+ .disable = mtk_dsi_bridge_disable,
+ .enable = mtk_dsi_bridge_enable,
+ .mode_set = mtk_dsi_bridge_mode_set,
};
static const struct drm_connector_funcs mtk_dsi_connector_funcs = {
@@ -888,20 +901,6 @@ static int mtk_dsi_create_conn_enc(struct drm_device *drm,
struct mtk_dsi *dsi)
{
int ret;
- ret = drm_encoder_init(drm, &dsi->encoder, &mtk_dsi_encoder_funcs,
- DRM_MODE_ENCODER_DSI, NULL);
- if (ret) {
- DRM_ERROR("Failed to encoder init to drm\n");
- return ret;
- }
- drm_encoder_helper_add(&dsi->encoder, &mtk_dsi_encoder_helper_funcs);
-
- /*
-* Currently display data paths are statically assigned to a crtc each.
-* crtc 0 is OVL0 -> COLOR0 -> AAL -> OD -> RDMA0 -> UFOE -> DSI0
-*/
- dsi->encoder.possible_crtcs = 1;
-
/* If there's a bridge, attach to it and let it create the connector */
if (dsi->next_bridge) {
ret = drm_bridge_attach(&dsi->encoder, dsi->next_bridge, NULL,
@@ -1123,6 +1122,34 @@ static const st
Re: [PATCH v3 2/2] drm/tegra: output: rgb: Support LVDS encoder bridge
16.04.2020 21:52, Dmitry Osipenko пишет: ... >> May I also recommend switching to the DRM panel bridge helper ? It will >> simplify the code. > > Could you please clarify what is the "DRM panel bridge helper"? > > I think we won't need any additional helpers after switching to the > bridge connector helper, no? Actually, I now see that the panel needs to be manually attached to the connector. Still it's not apparent to me how to get panel out of the bridge. It looks like there is no such "panel helper" for the bridge API or I just can't find it. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/7] drm/bridge: ps8640: Get the EDID from eDP control
The PS8640 DSI-to-eDP bridge can retrieve the EDID, so implement the
.get_edid callback and set the flag to indicate the core to use it.
Signed-off-by: Enric Balletbo i Serra
---
Changes in v2: None
drivers/gpu/drm/bridge/parade-ps8640.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c
b/drivers/gpu/drm/bridge/parade-ps8640.c
index d3a53442d449..956b76e0a44d 100644
--- a/drivers/gpu/drm/bridge/parade-ps8640.c
+++ b/drivers/gpu/drm/bridge/parade-ps8640.c
@@ -242,8 +242,18 @@ static int ps8640_bridge_attach(struct drm_bridge *bridge,
return ret;
}
+static struct edid *ps8640_bridge_get_edid(struct drm_bridge *bridge,
+ struct drm_connector *connector)
+{
+ struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
+
+ return drm_get_edid(connector,
+ ps_bridge->page[PAGE0_DP_CNTL]->adapter);
+}
+
static const struct drm_bridge_funcs ps8640_bridge_funcs = {
.attach = ps8640_bridge_attach,
+ .get_edid = ps8640_bridge_get_edid,
.post_disable = ps8640_post_disable,
.pre_enable = ps8640_pre_enable,
};
@@ -296,6 +306,8 @@ static int ps8640_probe(struct i2c_client *client)
ps_bridge->bridge.funcs = &ps8640_bridge_funcs;
ps_bridge->bridge.of_node = dev->of_node;
+ ps_bridge->bridge.ops = DRM_BRIDGE_OP_EDID;
+ ps_bridge->bridge.type = DRM_MODE_CONNECTOR_eDP;
ps_bridge->page[PAGE0_DP_CNTL] = client;
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 7/7] drm/mediatek: mtk_dsi: Create connector for bridges
Use the drm_bridge_connector helper to create a connector for pipelines
that use drm_bridge. This allows splitting connector operations across
multiple bridges when necessary, instead of having the last bridge in
the chain creating the connector and handling all connector operations
internally.
Signed-off-by: Enric Balletbo i Serra
---
Changes in v2: None
drivers/gpu/drm/mediatek/mtk_dsi.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
b/drivers/gpu/drm/mediatek/mtk_dsi.c
index 44718fa3d1ca..2f8876c32864 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -17,6 +17,7 @@
#include
#include
+#include
#include
#include
#include
@@ -184,6 +185,7 @@ struct mtk_dsi {
struct drm_bridge bridge;
struct drm_bridge *panel_bridge;
struct drm_bridge *next_bridge;
+ struct drm_connector *connector;
struct phy *phy;
void __iomem *regs;
@@ -983,10 +985,19 @@ static int mtk_dsi_encoder_init(struct drm_device *drm,
struct mtk_dsi *dsi)
*/
dsi->encoder.possible_crtcs = 1;
- ret = drm_bridge_attach(&dsi->encoder, &dsi->bridge, NULL, 0);
+ ret = drm_bridge_attach(&dsi->encoder, &dsi->bridge, NULL,
+ DRM_BRIDGE_ATTACH_NO_CONNECTOR);
if (ret)
goto err_cleanup_encoder;
+ dsi->connector = drm_bridge_connector_init(drm, &dsi->encoder);
+ if (IS_ERR(dsi->connector)) {
+ DRM_ERROR("Unable to create bridge connector\n");
+ ret = PTR_ERR(dsi->connector);
+ goto err_cleanup_encoder;
+ }
+ drm_connector_attach_encoder(dsi->connector, &dsi->encoder);
+
return 0;
err_cleanup_encoder:
@@ -1144,6 +1155,7 @@ static int mtk_dsi_probe(struct platform_device *pdev)
dsi->bridge.funcs = &mtk_dsi_bridge_funcs;
dsi->bridge.of_node = dev->of_node;
+ dsi->bridge.type = DRM_MODE_CONNECTOR_DSI;
drm_bridge_add(&dsi->bridge);
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 2/2] drm/tegra: output: rgb: Support LVDS encoder bridge
16.04.2020 23:50, Laurent Pinchart пишет: > Hi Dmitry, > > On Thu, Apr 16, 2020 at 11:21:40PM +0300, Dmitry Osipenko wrote: >> 16.04.2020 21:52, Dmitry Osipenko пишет: >> ... May I also recommend switching to the DRM panel bridge helper ? It will simplify the code. >>> >>> Could you please clarify what is the "DRM panel bridge helper"? >>> >>> I think we won't need any additional helpers after switching to the >>> bridge connector helper, no? >> >> Actually, I now see that the panel needs to be manually attached to the >> connector. > > The DRM panel bridge helper creates a bridge from a panel (with > devm_drm_panel_bridge_add()). You can then attach that bridge to the > chain, like any other bridge, and the enable/disable operations will be > called automatically without any need to call the panel enable/disable > manually as done currently. > >> Still it's not apparent to me how to get panel out of the bridge. It >> looks like there is no such "panel helper" for the bridge API or I just >> can't find it. > > You don't need to get a panel out of the bridge. You should get the > bridge as done today, You mean "get the panel", correct? > and wrap it in a bridge with > devm_drm_panel_bridge_add(). > The lvds-codec already wraps panel into the bridge using devm_drm_panel_bridge_add() and chains it for us, please see lvds_codec_probe() / lvds_codec_attach(). Does it mean that lvds-codec is not supporting the new model? Everything works nicely using the old model, where bridge creates connector and attaches panel to it for us. [I'm still not sure what is the point to use the new model in a case of a simple chain of bridges] Using the new model, the connector isn't created by the bridge, so I need to duplicate that creation effort in the driver. Once the bridge connector is manually created, I need to attach panel to this connector, but panel is reachable only via the remote bridge (which wraps the panel). driver connector -> LVDS bridge -> panel bridge -> panel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 0/7] Convert mtk-dsi to drm_bridge API and get EDID for ps8640 bridge
The PS8640 dsi-to-eDP bridge driver is using the panel bridge API, however, not all the components in the chain have been ported to the drm_bridge API. Actually, when a panel is attached the default panel's mode is used, but in some cases we can't get display up if mode getting from eDP control EDID is not chosen. This series address that problem, first implements the .get_edid() callback in the PS8640 driver (which is not used until the conversion is done) and then, converts the Mediatek DSI driver to use the drm_bridge API. As far as I know, we're the only users of the mediatek dsi driver in mainline, so should be safe to switch to the new chain of drm_bridge API unconditionally. The patches has been tested on a Acer Chromebook R13 (Elm) running a Chrome OS userspace and checking that the valid EDID mode reported by the bridge is selected. [1] https://lore.kernel.org/lkml/20200210063523.13-1-hsi...@chromium.org/ Changes in v2: - Do not set connector_type for panel here. (Sam Ravnborg) Enric Balletbo i Serra (7): drm/bridge: ps8640: Get the EDID from eDP control drm/bridge_connector: Set default status connected for eDP connectors drm/mediatek: mtk_dsi: Rename bridge to next_bridge drm/mediatek: mtk_dsi: Convert to bridge driver drm/mediatek: mtk_dsi: Use simple encoder drm/mediatek: mtk_dsi: Use the drm_panel_bridge API drm/mediatek: mtk_dsi: Create connector for bridges drivers/gpu/drm/bridge/parade-ps8640.c | 12 ++ drivers/gpu/drm/drm_bridge_connector.c | 1 + drivers/gpu/drm/mediatek/mtk_dsi.c | 280 - 3 files changed, 101 insertions(+), 192 deletions(-) -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/tegra: dc: Use devm_platform_ioremap_resource() to simplify code
Use devm_platform_ioremap_resource() instead of
platform_get_resource()+ devm_ioremap_resource().
Signed-off-by: Tang Bin
---
drivers/gpu/drm/tegra/dc.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
index d26fb16d6..72c952b1a 100644
--- a/drivers/gpu/drm/tegra/dc.c
+++ b/drivers/gpu/drm/tegra/dc.c
@@ -2503,7 +2503,6 @@ static int tegra_dc_couple(struct tegra_dc *dc)
static int tegra_dc_probe(struct platform_device *pdev)
{
- struct resource *regs;
struct tegra_dc *dc;
int err;
@@ -2560,8 +2559,7 @@ static int tegra_dc_probe(struct platform_device *pdev)
tegra_powergate_power_off(dc->powergate);
}
- regs = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- dc->regs = devm_ioremap_resource(&pdev->dev, regs);
+ dc->regs = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(dc->regs))
return PTR_ERR(dc->regs);
--
2.20.1.windows.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 0/2] Support DRM bridges on NVIDIA Tegra
Hello, This small series adds initial support for the DRM bridges to NVIDIA Tegra DRM driver. This is required by newer device-trees where we model the LVDS encoder bridge properly. Changelog: v3: - Following recommendation from Sam Ravnborg, the new bridge attachment model is now being used, i.e. we ask bridge to *not* create a connector using the DRM_BRIDGE_ATTACH_NO_CONNECTOR flag. - The bridge is now created only for the RGB (LVDS) output, and only when necessary. For now we don't need bridges for HDMI or DSI outputs. - I noticed that we're leaking OF node in the panel's error code path, this is fixed now by the new patch "Don't leak OF node on error". v2: - Added the new "rgb: Don't register connector if bridge is used" patch, which hides the unused connector provided by the Tegra DRM driver when bridge is used, since bridge provides its own connector to us. - Please notice that the first "Support DRM bridges" patch was previously sent out as a standalone v1 change. Dmitry Osipenko (2): drm/tegra: output: Don't leak OF node on error drm/tegra: output: rgb: Support LVDS encoder bridge drivers/gpu/drm/tegra/drm.h| 2 ++ drivers/gpu/drm/tegra/output.c | 19 ++- drivers/gpu/drm/tegra/rgb.c| 34 ++ 3 files changed, 50 insertions(+), 5 deletions(-) -- 2.26.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC 0/6] Regressions for "imply" behavior change
On Thu, Apr 16, 2020 at 11:12:56AM -0400, Nicolas Pitre wrote: > On Thu, 16 Apr 2020, Arnd Bergmann wrote: > > > On Thu, Apr 16, 2020 at 12:17 PM Jani Nikula > > wrote: > > > > > > On Thu, 16 Apr 2020, Arnd Bergmann wrote: > > > > On Thu, Apr 16, 2020 at 5:25 AM Saeed Mahameed > > > > wrote: > > > >> BTW how about adding a new Kconfig option to hide the details of > > > >> ( BAR || !BAR) ? as Jason already explained and suggested, this will > > > >> make it easier for the users and developers to understand the actual > > > >> meaning behind this tristate weird condition. > > > >> > > > >> e.g have a new keyword: > > > >> reach VXLAN > > > >> which will be equivalent to: > > > >> depends on VXLAN && !VXLAN > > > > > > > > I'd love to see that, but I'm not sure what keyword is best. For your > > > > suggestion of "reach", that would probably do the job, but I'm not > > > > sure if this ends up being more or less confusing than what we have > > > > today. > > > > > > Ah, perfect bikeshedding topic! > > > > > > Perhaps "uses"? If the dependency is enabled it gets used as a > > > dependency. > > > > That seems to be the best naming suggestion so far > > What I don't like about "uses" is that it doesn't convey the conditional > dependency. It could be mistaken as being synonymous to "select". > > What about "depends_if" ? The rationale is that this is actually a > dependency, but only if the related symbol is set (i.e. not n or empty). I think that stretches the common understanding of 'depends' a bit too far.. A depends where the target can be N is just too strange. Somthing incorporating 'optional' seems like a better choice 'optionally uses' seems particularly clear and doesn't overload existing works like depends or select Jason ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/7] drm/bridge_connector: Set default status connected for eDP connectors
In an eDP application, HPD is not required and on most bridge chips useless. If HPD is not used, we need to set initial status as connected, otherwise the connector created by the drm_bridge_connector API remains in an unknown state. Signed-off-by: Enric Balletbo i Serra --- Changes in v2: None drivers/gpu/drm/drm_bridge_connector.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/drm_bridge_connector.c b/drivers/gpu/drm/drm_bridge_connector.c index c6994fe673f3..a58cbde59c34 100644 --- a/drivers/gpu/drm/drm_bridge_connector.c +++ b/drivers/gpu/drm/drm_bridge_connector.c @@ -187,6 +187,7 @@ drm_bridge_connector_detect(struct drm_connector *connector, bool force) case DRM_MODE_CONNECTOR_DPI: case DRM_MODE_CONNECTOR_LVDS: case DRM_MODE_CONNECTOR_DSI: + case DRM_MODE_CONNECTOR_eDP: status = connector_status_connected; break; default: -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 3/7] drm/mediatek: mtk_dsi: Rename bridge to next_bridge
This is really a cosmetic change just to make a bit more readable the
code after convert the driver to drm_bridge. The bridge variable name
will be used by the encoder drm_bridge, and the chained bridge will be
named next_bridge.
Signed-off-by: Enric Balletbo i Serra
---
Changes in v2: None
drivers/gpu/drm/mediatek/mtk_dsi.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
b/drivers/gpu/drm/mediatek/mtk_dsi.c
index cfa45d6abd74..44ee884cc31c 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -182,7 +182,7 @@ struct mtk_dsi {
struct drm_encoder encoder;
struct drm_connector conn;
struct drm_panel *panel;
- struct drm_bridge *bridge;
+ struct drm_bridge *next_bridge;
struct phy *phy;
void __iomem *regs;
@@ -903,8 +903,9 @@ static int mtk_dsi_create_conn_enc(struct drm_device *drm,
struct mtk_dsi *dsi)
dsi->encoder.possible_crtcs = 1;
/* If there's a bridge, attach to it and let it create the connector */
- if (dsi->bridge) {
- ret = drm_bridge_attach(&dsi->encoder, dsi->bridge, NULL, 0);
+ if (dsi->next_bridge) {
+ ret = drm_bridge_attach(&dsi->encoder, dsi->next_bridge, NULL,
+ 0);
if (ret) {
DRM_ERROR("Failed to attach bridge to drm\n");
goto err_encoder_cleanup;
@@ -1185,7 +1186,7 @@ static int mtk_dsi_probe(struct platform_device *pdev)
}
ret = drm_of_find_panel_or_bridge(dev->of_node, 0, 0,
- &dsi->panel, &dsi->bridge);
+ &dsi->panel, &dsi->next_bridge);
if (ret)
goto err_unregister_host;
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 1/8] drm: bridge: dw_mipi_dsi: add initial regmap infrastructure
On Thu, 16 Apr 2020, Enric Balletbo Serra
wrote:
Hi Adrian,
[snip]
>>
>> +static void dw_mipi_dsi_get_hw_version(struct dw_mipi_dsi
>> *dsi) +{ + regmap_read(dsi->regs, DSI_VERSION,
>> &dsi->hw_version); + dsi->hw_version &= VERSION; + if
>> (!dsi->hw_version) + dev_err(dsi->dev, "Failed
>> to read DSI hw version register\n");
>
> Is this an error that should be ignored? If you can't get the
> HW version, probably, there is something wrong with your
> hardware so, don't you need to return an error?
>
After thinking a bit more about it, that error should be a
warning.
I added it because in some cases (for eg. if the peripheral
clock is disabled) the reads can return 0 which is obviously an
invalid version and the bridge will error in the next step when
not finding a layout.
If you'll error anyway, why wait? IIUC at this point the clock
*must* be enabled, and if not, something is wrong with the
driver, I don't see any advantage on delay the error. do you
have a use case where this is called and peripheral clock
disabled?
There should be no real use-case (maybe malfunctioning HW), and we
could error out here to catch driver bugs ASAP, so I'll go this
route then :)
Thank you, much appreciated!
So I'll make this a warning in v7 and explicitely mention that
reads version == 0 can be caused by a disabled pclk.
-- Enric
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PULL] topic/phy-compliance
Merged into drm-misc-next Am 08.04.20 um 14:49 schrieb Maarten Lankhorst: > Hey, > > Here's a pull request to pull in the DP PHY Compliance series. > It's based on top of drm/drm-next, and contains all patches for core, amd and > i915. :) > > Cheers, > Maarten > > topic/phy-compliance-2020-04-08: > Topic pull request for topic/phy-compliance: > - Standardize DP_PHY_TEST_PATTERN name. > - Add support for setting/getting test pattern from sink. > - Implement DP PHY compliance to i915. > The following changes since commit 12ab316ced2c5f32ced0e6300a054db644b5444a: > > Merge tag 'amd-drm-next-5.7-2020-04-01' of > git://people.freedesktop.org/~agd5f/linux into drm-next (2020-04-08 09:34:27 > +1000) > > are available in the Git repository at: > > git://anongit.freedesktop.org/drm/drm-misc > tags/topic/phy-compliance-2020-04-08 > > for you to fetch changes up to 8cdf727119289db3a98835662eb28e1c5ad835f1: > > drm/i915/dp: Program vswing, pre-emphasis, test-pattern (2020-04-08 > 14:41:09 +0200) > > > Topic pull request for topic/phy-compliance: > - Standardize DP_PHY_TEST_PATTERN name. > - Add support for setting/getting test pattern from sink. > - Implement DP PHY compliance to i915. > > > Animesh Manna (7): > drm/amd/display: Align macro name as per DP spec > drm/dp: get/set phy compliance pattern > drm/i915/dp: Made intel_dp_adjust_train() non-static > drm/i915/dp: Preparation for DP phy compliance auto test > drm/i915/dp: Add debugfs entry for DP phy compliance > drm/i915/dp: Register definition for DP compliance register > drm/i915/dp: Program vswing, pre-emphasis, test-pattern > > drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c | 2 +- > drivers/gpu/drm/drm_dp_helper.c| 94 +++ > .../gpu/drm/i915/display/intel_display_debugfs.c | 12 +- > drivers/gpu/drm/i915/display/intel_display_types.h | 1 + > drivers/gpu/drm/i915/display/intel_dp.c| 171 > + > drivers/gpu/drm/i915/display/intel_dp.h| 1 + > .../gpu/drm/i915/display/intel_dp_link_training.c | 9 +- > .../gpu/drm/i915/display/intel_dp_link_training.h | 4 + > drivers/gpu/drm/i915/i915_reg.h| 18 +++ > include/drm/drm_dp_helper.h| 33 +++- > 10 files changed, 337 insertions(+), 8 deletions(-) > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel > -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer signature.asc Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: RFC: Drm-connector properties managed by another driver / privacy screen support
On Wed, 15 Apr 2020 17:40:46 +0200 Hans de Goede wrote: > Hi, > > On 4/15/20 5:28 PM, Jani Nikula wrote: > > On Wed, 15 Apr 2020, Hans de Goede wrote: > >> ii. Currently the "privacy-screen" property added by Rajat's > >> patch-set is an enum with 2 possible values: > >> "Enabled" > >> "Disabled" > >> > >> We could add a third value "Not Available", which would be the > >> default and then for internal panels always add the property > >> so that we avoid the problem that detecting if the laptop has > >> an internal privacy screen needs to be done before the connector > >> is registered. Then we can add some hooks which allow an > >> lcdshadow-driver to register itself against a connector later > >> (which is non trivial wrt probe order, but lets ignore that for now). > > > > I regret dropping the ball on Rajat's series (sorry!). > > > > I do think having the connector property for this is the way to go. > > I 100% agree. > > > Even > > if we couldn't necessarily figure out all the details on the kernel > > internal connections, can we settle on the property though, so we could > > move forward with Rajat's series? > > Yes please, this will also allow us to move forward with userspace > support even if for testing that we do some hacks for the kernel's > internal connections for now. > > > Moreover, do we actually need two properties, one which could indicate > > userspace's desire for the property, and another that tells the hardware > > state? > > No I do not think so. I would expect there to just be one property, > I guess that if the state is (partly) firmware controlled then there > might be a race, but we will need a notification mechanism (*) for > firmware triggered state changes anyways, so shortly after loosing > the race userspace will process the notification and it will know > about it. > > One thing which might be useful is a way to signal that the property > is read-only in case we ever hit hw where that is the case. > > > I'd so very much like to have no in-kernel/in-firmware shortcuts > > to enable/disable the privacy screen, and instead have any hardware > > buttons just be events that the userspace could react to. However I > > don't think that'll be the case unfortunately. > > In my experience with keyboard-backlight support, we will (unfortunately) > see a mix and in some case we will get a notification that the firmware > has adjusted the state, rather then just getting a keypress and > dealing with that ourselves. In some cases we may even be able to > choose, so the fw will deal with it by default but we can ask it > to just send a key-press. But I do believe that we can *not* expect > that we will always just get a keypress for userspace to deal with. Hi, let's think about how userspace uses atomic KMS UAPI. The simplest way to use atomic correctly is that userspace will for every update send the full, complete set of all properties that exist, both known and unknown to userspace (to recover from temporarily VT-switching to another KMS program that changes unknown properties). Attempting to track which properties already have their correct values in the kernel is extra work for just extra bugs. Assuming the property is userspace-writable: if kernel goes and changes the property value on its own, it will very likely be just overwritten by userspace right after if userspace does not manage to process the uevent first. If that happens and userspace later processes the uevent, userspace queries the kernel for the current proprerty state which is now what userspace wrote, not what firmware set. Therefore you end up with the firmware hotkey working only randomly. It would be much better to have the hotkey events delivered to userspace so that userspace can control the privacy screen and everything will be reliable, both the hotkeys and any GUI for it. The other reliable option is that userspace must never be able to change privacy screen state, only the hardware hotkeys can. > > Regards, > > Hans > > > *) Some udev event I guess, I sorta assume there already is a > notification mechanism for property change notifications ? Yes, such mechanism has been discussed before, see the thread containing https://lists.freedesktop.org/archives/dri-devel/2019-May/217588.html TL;DR: the mechanism exists and is called the hotplug event. But the problem with the hotplug event is that it carries no information about what changed, so userspace is forced re-discover everything about the DRM device. That thread discusses extending the hotplug event to be able to signal changes in individual properties rather than "something maybe changed, you figure out what". Thanks, pq pgpWpFwFEIMyv.pgp Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: RFC: Drm-connector properties managed by another driver / privacy screen support
On Thu, 16 Apr 2020 00:10:06 +0300 Jani Nikula wrote: > On Wed, 15 Apr 2020, Rajat Jain wrote: > > * I think having 2 properties might be a confusing UAPI. Also, we have > > existing properties like link-status that can be changed by both the > > user and the hardware. > > I think the consensus is that all properties that get changed by both > userspace and the kernel are mistakes, and the way to handle it is to > have two properties. Yes, I very much agree with Jani. I don't like KMS properties that are writable by both the driver and userspace. It's awkward to handle in userspace and fundamentally racy aside from tricks like "what you wrote is not what you read back". I have ranted against that when looking at HDCP properties, e.g.: https://lists.freedesktop.org/archives/dri-devel/2019-July/226424.html See also my other email in this thread about how userspace uses atomic KMS UAPI: you must expect that userspace will always write the property for any KMS update, even if it does not change its value, so any change done by the kernel is randomly lost unless the property is read-only or otherwise weird. Thanks, pq pgpcQPo0UGoVV.pgp Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH trivial 5/6] ALSA: Fix misspellings of "Analog Devices"
On Thu, 16 Apr 2020 12:30:57 +0200,
Geert Uytterhoeven wrote:
>
> According to https://www.analog.com/, the company name is spelled
> "Analog Devices".
>
> Signed-off-by: Geert Uytterhoeven
Applied this patch to sound git tree for-next branch.
thanks,
Takashi
> ---
> sound/isa/ad1816a/ad1816a.c | 2 +-
> sound/pci/ac97/ac97_patch.c | 2 +-
> sound/pci/hda/Kconfig | 4 ++--
> 3 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/sound/isa/ad1816a/ad1816a.c b/sound/isa/ad1816a/ad1816a.c
> index ce4c8ba2fa9873e7..ca18fe3ff8a59a9f 100644
> --- a/sound/isa/ad1816a/ad1816a.c
> +++ b/sound/isa/ad1816a/ad1816a.c
> @@ -54,7 +54,7 @@ MODULE_PARM_DESC(clockfreq, "Clock frequency for ad1816a
> driver (default = 0).")
> static const struct pnp_card_device_id snd_ad1816a_pnpids[] = {
> /* Analog Devices AD1815 */
> { .id = "ADS7150", .devs = { { .id = "ADS7150" }, { .id = "ADS7151" } }
> },
> - /* Analog Device AD1816? */
> + /* Analog Devices AD1816? */
> { .id = "ADS7180", .devs = { { .id = "ADS7180" }, { .id = "ADS7181" } }
> },
> /* Analog Devices AD1816A - added by Kenneth Platz */
> { .id = "ADS7181", .devs = { { .id = "ADS7180" }, { .id = "ADS7181" } }
> },
> diff --git a/sound/pci/ac97/ac97_patch.c b/sound/pci/ac97/ac97_patch.c
> index ebf926728c5f84af..45ef0f52ec55b803 100644
> --- a/sound/pci/ac97/ac97_patch.c
> +++ b/sound/pci/ac97/ac97_patch.c
> @@ -1356,7 +1356,7 @@ static int patch_cx20551(struct snd_ac97 *ac97)
> }
>
> /*
> - * Analog Device AD18xx, AD19xx codecs
> + * Analog Devices AD18xx, AD19xx codecs
> */
> #ifdef CONFIG_PM
> static void ad18xx_resume(struct snd_ac97 *ac97)
> diff --git a/sound/pci/hda/Kconfig b/sound/pci/hda/Kconfig
> index e1d3082a4fe93153..7ba542e45a3d7f88 100644
> --- a/sound/pci/hda/Kconfig
> +++ b/sound/pci/hda/Kconfig
> @@ -99,10 +99,10 @@ comment "Set to Y if you want auto-loading the codec
> driver"
> depends on SND_HDA=y && SND_HDA_CODEC_REALTEK=m
>
> config SND_HDA_CODEC_ANALOG
> - tristate "Build Analog Device HD-audio codec support"
> + tristate "Build Analog Devices HD-audio codec support"
> select SND_HDA_GENERIC
> help
> - Say Y or M here to include Analog Device HD-audio codec support in
> + Say Y or M here to include Analog Devices HD-audio codec support in
> snd-hda-intel driver, such as AD1986A.
>
> comment "Set to Y if you want auto-loading the codec driver"
> --
> 2.17.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 4/8] drm: imx: Add i.MX 6 MIPI DSI host platform driver
Hi Enric & Laurent,
On Wed, 15 Apr 2020, Laurent Pinchart
wrote:
Hi Enric,
On Wed, Apr 15, 2020 at 07:26:02PM +0200, Enric Balletbo Serra
wrote:
Missatge de Adrian Ratiu del dia
dt., 14 d’abr. 2020 a les 17:19:
>
> This adds support for the Synopsis DesignWare MIPI DSI v1.01
> host controller which is embedded in i.MX 6 SoCs.
>
> Based on following patches, but updated/extended to work with
> existing support found in the kernel:
>
> - drm: imx: Support Synopsys DesignWare MIPI DSI host
> controller
> Signed-off-by: Liu Ying
>
> Cc: Fabio Estevam Reviewed-by: Emil
> Velikov Tested-by: Adrian Pop
> Tested-by: Arnaud Ferraris
> Signed-off-by: Sjoerd Simons
> Signed-off-by: Martyn Welch
> Signed-off-by: Adrian Ratiu
> --- Changes since v5:
> - Reword to remove unrelated device tree patch mention
> (Fabio) - Move pllref_clk enable/disable to bind/unbind
> (Ezequiel) - Fix freescale.com -> nxp.com email addresses
> (Fabio) - Also added myself as module author (Fabio) - Use
> DRM_DEV_* macros for consistency, print more error msg
>
> Changes since v4:
> - Split off driver-specific configuration of phy timings
> due to new upstream API. - Move regmap infrastructure
> logic to separate commit (Ezequiel) - Move dsi v1.01 layout
> addition to a separate commit (Ezequiel) - Minor warnings
> and driver name fixes
>
> Changes since v3:
> - Renamed platform driver to reflect it's i.MX6
> only. (Fabio)
>
> Changes since v2:
> - Fixed commit tags. (Emil)
>
> Changes since v1:
> - Moved register definitions & regmap initialization into
> bridge module. Platform drivers get the regmap via
> plat_data after calling the bridge probe. (Emil)
> ---
> drivers/gpu/drm/imx/Kconfig| 7 +
> drivers/gpu/drm/imx/Makefile | 1 +
> drivers/gpu/drm/imx/dw_mipi_dsi-imx6.c | 409
> + 3 files changed, 417 insertions(+)
> create mode 100644 drivers/gpu/drm/imx/dw_mipi_dsi-imx6.c
>
> diff --git a/drivers/gpu/drm/imx/Kconfig
> b/drivers/gpu/drm/imx/Kconfig index
> 207bf7409dfb..b49e70e7f0fd 100644 ---
> a/drivers/gpu/drm/imx/Kconfig +++
> b/drivers/gpu/drm/imx/Kconfig @@ -39,3 +39,10 @@ config
> DRM_IMX_HDMI
> depends on DRM_IMX help
> Choose this if you want to use HDMI on i.MX6.
> + +config DRM_IMX6_MIPI_DSI + tristate "Freescale i.MX6
> DRM MIPI DSI" + select DRM_DW_MIPI_DSI + depends
> on DRM_IMX
Should it depend on CONFIG_OF too? I suspect you'll get build
errors if OF is not selected
> + help + Choose this if you want to use MIPI
> DSI on i.MX6. diff --git a/drivers/gpu/drm/imx/Makefile
> b/drivers/gpu/drm/imx/Makefile index
> 21cdcc2faabc..9a7843c59347 100644 ---
> a/drivers/gpu/drm/imx/Makefile +++
> b/drivers/gpu/drm/imx/Makefile @@ -9,3 +9,4 @@
> obj-$(CONFIG_DRM_IMX_TVE) += imx-tve.o
> obj-$(CONFIG_DRM_IMX_LDB) += imx-ldb.o
>
> obj-$(CONFIG_DRM_IMX_HDMI) += dw_hdmi-imx.o
> +obj-$(CONFIG_DRM_IMX6_MIPI_DSI) += dw_mipi_dsi-imx6.o diff
> --git a/drivers/gpu/drm/imx/dw_mipi_dsi-imx6.c
> b/drivers/gpu/drm/imx/dw_mipi_dsi-imx6.c new file mode 100644
> index ..6914db8ce8cb --- /dev/null +++
> b/drivers/gpu/drm/imx/dw_mipi_dsi-imx6.c @@ -0,0 +1,409 @@
> +// SPDX-License-Identifier: GPL-2.0+ +/* + * i.MX6 drm
> driver - MIPI DSI Host Controller + * + * Copyright (C)
> 2011-2015 Freescale Semiconductor, Inc. + * Copyright (C)
> 2019-2020 Collabora, Ltd. + */ + +#include
> +#include +#include
> +#include +#include
> +#include +#include
> +#include +#include
> +#include
> +#include +#include
> +#include + +#include "imx-drm.h" +
> +#define DSI_PWR_UP 0x04 +#define RESET
> 0 +#define POWERUPBIT(0) +
> +#define DSI_PHY_IF_CTRL0x5c +#define
> PHY_IF_CTRL_RESET 0x0 + +#define
> DSI_PHY_TST_CTRL0 0x64 +#define PHY_TESTCLK
> BIT(1) +#define PHY_UNTESTCLK 0 +#define
> PHY_TESTCLRBIT(0) +#define PHY_UNTESTCLR
> 0 + +#define DSI_PHY_TST_CTRL1 0x68 +#define
> PHY_TESTEN BIT(16) +#define PHY_UNTESTEN
> 0 +#define PHY_TESTDOUT(n)(((n) &
> 0xff) << 8) +#define PHY_TESTDIN(n) (((n) &
> 0xff) << 0) + +struct imx_mipi_dsi { + struct
> drm_encoder encoder; + struct device *dev; +
> struct regmap *mux_sel; + struct dw_mipi_dsi *mipi_dsi;
> + struct clk *pllref_clk; + + void __iomem *base;
> + unsigned int lane_mbps; +}; + +struct
> dphy_pll_testdin_map { + unsigned int max_mbps; +
> u8 testdin; +}; + +/* The table is based on 27MHz DPHY pll
> reference clock. */ +static const struct dphy_pll_testdin_map
> dptdin_map[] = { + {160, 0x04}, {180, 0x24}, {200,
> 0x44}, {210, 0x06}, + {240, 0x26}, {250, 0x46}, {270,
Re: [PATCH 1/1] video: backlight: tosa_lcd: convert to use i2c_new_client_device()
On Thu, 26 Mar 2020, Wolfram Sang wrote: > Move away from the deprecated API and return the shiny new ERRPTR where > useful. > > Signed-off-by: Wolfram Sang > --- > drivers/video/backlight/tosa_lcd.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) Applied, thanks. -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Multiple regulators for one device [was drm/panfrost: add devfreq regulator support]
On 2020-04-16 2:42 pm, Steven Price wrote: [...] Perhaps a better approach would be for Panfrost to hand over the struct regulator objects it has already got to the OPP framework. I.e. open code dev_pm_opp_set_regulators(), but instead of calling regulator_get_optional() simply populate the regulators we already have? The other benefit of that is it would provide a clear hand-over of responsibility between Panfrost handling it's own regulators and the OPP framework picking up the work. The disadvantage is that Panfrost would have to track whether the regulators have been handed over or not. Sounds like the most logical thing to do is to shuffle things around so we start by trying to set up an OPP table, then fall back to explicitly claiming clocks and regulators if necessary. Then we can easily make the devfreq decision later in probe based on how that turned out. Robin. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] drm-intel-next
heline as destroyed after rcu grace period (Chris) - Avoid live-lock with i915_vma_parked() (Chris) - Avoid gem_context->mutex for simple vma lookup (Chris) - Rely on direct submission to the queue (Chris) - Configure DSI transcoder to operate in TE GATE command mode (Vandita) - Add DI vblank calculation for command mode (Vandita) - Disable periodic command mode if programmed by GOP (Vandita) - Use private flags to indicate TE in cmd mode (Vandita) - Make fences a nice-to-have for FBC on GEN9+ (Jose) - Fix work queuing issue with mixed virtual engine/physical engine submissions (Chris) - Drop final few uses of drm_i915_private.engine (Chris) - Return early after MISSING_CASE for write_dp_sdp (Chris) - Include port sync state in the state dump (Ville) - ELSP workaround switching back to a completed context (Chris) - Include priority info in trace_ports (Chris) - Allow for different modes of interruptible i915_active_wait (Chris) - Split eb_vma into its own allocation (Chris) - Don't read perf head/tail pointers outside critical section (Lionel) - Pause CS flow before execlists reset (Chris) - Make fence revocation unequivocal (Chris) - Drop cached obj->bind_count (Chris) - Peek at the next submission for error interrupts (Chris) - Utilize rcu iteration of context engines (Chris) - Keep a per-engine request pool for power management ops (Chris) - Refactor port sync code into normal modeset flow (Ville) - Check current i915_vma.pin_count status first on unbind (Chris) - Free request pool from virtual engines (Chris) - Flush all the reloc_gpu batch (Chris) - Make exclusive awaits on i915_active optional and allow async waits (Chris) - Wait until the context is finally retired before releasing engines (Chris) - Prefer '%ps' for printing function symbol names (Chris) - Allow setting generic data pointer on intel GT debugfs (Andi) - Constify DP link computation code more (Ville) - Simplify MST master transcoder computation (Ville) - Move TRANS_DDI_FUNC_CTL2 programming where it belongs (Ville) - Move icl_get_trans_port_sync_config() into the DDI code (Ville) - Add definitions for VRR registers and bits (Aditya) - Refactor hardware fence code (Chris) - Start passing latency as parameter to WM calculation (Stanislav) - Kernel selftest and debug tracing improvements (Matt A, Chris, Mika) - Fixes to CI found corner cases and lockdep splats (Chris) - Overall fixes and refactoring to GEM code (Chris) - Overall fixes and refactoring to display code (Ville) - GuC/HuC code improvements (Daniele, Michal Wa) - Static code checker fixes (Nathan, Ville, Colin, Chris) - Fix spelling mistake (Chen) The following changes since commit 8f3d9f354286745c751374f5f1fcafee6b3f3136: Linux 5.7-rc1 (2020-04-12 12:35:55 -0700) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-2020-04-17 for you to fetch changes up to b06ef327e26367b9286a2079b31cde8d2161c0d8: drm/i915: Update DRIVER_DATE to 20200417 (2020-04-17 09:35:00 +0300) UAPI Changes: - drm/i915/perf: introduce global sseu pinning Allow userspace to request at perf/OA open full SSEU configuration on the system to be able to benchmark 3D workloads, at the cost of not being able to run media workloads. (Lionel) Userspace changes: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4021 - drm/i915/perf: add new open param to configure polling of OA buffer Let application choose how often the OA buffer should be checked on the CPU side for data availability for choosig between CPU overhead and realtime nature of data. Userspace changes: https://patchwork.freedesktop.org/series/74655/ (i915 perf recorder is a tool to capture i915 perf data for viewing in GPUVis.) - drm/i915/perf: remove generated code Removal of the machine generated perf/OA test configurations from i915. Used by Mesa v17.1-18.0, and shortly replaced by userspace supplied OA configurations. Removal of configs causes affected Mesa versions to fall back to earlier kernel behaviour (potentially missing metrics). (Lionel) Cross-subsystem Changes: - Backmerge of drm-next - Includes tag 'topic/phy-compliance-2020-04-08' from git://anongit.freedesktop.org/drm/drm-misc Driver Changes: - Fix for GitLab issue #27: Support 5k tiled dual DP display on SKL (Ville) - Fix https://github.com/thesofproject/linux/issues/1719: Broken audio after S3 resume on JSL platforms. (Kai) - Add new Tigerlake PCI IDs (Swathi D.) - Add missing Tigerlake W/As (Matt R.) - Extended Wa_2006604312 to EHL (Matt A) - Add DPCD link_rate quirk for Apple 15" MBP 2017 (v3) (Mario) - Make Wa_14010229206 apply to all Tigerlake steppings (Swathi d) - Extend hotplug detect retry on TypeC connectors to 5 seconds (Imre) - Yield the timeslice if caught waiting on a user semaphore (Chris) - Limit the residual W/A batch to Haswell due to instability on IVB/
[PATCH 4/5] backlight: led_bl: fix led -> backlight brightness mapping
The code that maps the LED default brightness to backlight levels has
two issues: 1) if the default brightness is the first backlight level
(usually 0), the code fails to find it, and 2) when the code fails to
find a backlight level, it ends up using max_brightness + 1 as the
default brightness.
Fix these two issues.
Signed-off-by: Tomi Valkeinen
---
drivers/video/backlight/led_bl.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/video/backlight/led_bl.c b/drivers/video/backlight/led_bl.c
index 63693c4f0883..021b5edd895c 100644
--- a/drivers/video/backlight/led_bl.c
+++ b/drivers/video/backlight/led_bl.c
@@ -159,10 +159,11 @@ static int led_bl_parse_levels(struct device *dev,
*/
db = priv->default_brightness;
for (i = 0 ; i < num_levels; i++) {
- if ((i && db > levels[i - 1]) && db <= levels[i])
+ if ((i == 0 || db > levels[i - 1]) && db <= levels[i])
break;
}
- priv->default_brightness = i;
+
+ priv->default_brightness = i < num_levels ? i : 0;
priv->max_brightness = num_levels - 1;
priv->levels = levels;
} else if (num_levels >= 0) {
--
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
[PATCH 1/5] backlight: led_bl: fix cosmetic issues
Fix issues reported by checkpatch. No functional changes.
Signed-off-by: Tomi Valkeinen
---
drivers/video/backlight/led_bl.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/video/backlight/led_bl.c b/drivers/video/backlight/led_bl.c
index 3f66549997c8..d4e1ce684366 100644
--- a/drivers/video/backlight/led_bl.c
+++ b/drivers/video/backlight/led_bl.c
@@ -126,7 +126,7 @@ static int led_bl_get_leds(struct device *dev,
}
static int led_bl_parse_levels(struct device *dev,
- struct led_bl_data *priv)
+ struct led_bl_data *priv)
{
struct device_node *node = dev->of_node;
int num_levels;
@@ -148,8 +148,8 @@ static int led_bl_parse_levels(struct device *dev,
return -ENOMEM;
ret = of_property_read_u32_array(node, "brightness-levels",
- levels,
- num_levels);
+levels,
+num_levels);
if (ret < 0)
return ret;
@@ -159,14 +159,15 @@ static int led_bl_parse_levels(struct device *dev,
*/
db = priv->default_brightness;
for (i = 0 ; i < num_levels; i++) {
- if ((i && db > levels[i-1]) && db <= levels[i])
+ if ((i && db > levels[i - 1]) && db <= levels[i])
break;
}
priv->default_brightness = i;
priv->max_brightness = num_levels - 1;
priv->levels = levels;
- } else if (num_levels >= 0)
+ } else if (num_levels >= 0) {
dev_warn(dev, "Not enough levels defined\n");
+ }
ret = of_property_read_u32(node, "default-brightness-level", &value);
if (!ret && value <= priv->max_brightness)
@@ -208,7 +209,8 @@ static int led_bl_probe(struct platform_device *pdev)
props.power = (priv->default_brightness > 0) ? FB_BLANK_POWERDOWN :
FB_BLANK_UNBLANK;
priv->bl_dev = backlight_device_register(dev_name(&pdev->dev),
- &pdev->dev, priv, &led_bl_ops, &props);
+&pdev->dev, priv, &led_bl_ops,
+&props);
if (IS_ERR(priv->bl_dev)) {
dev_err(&pdev->dev, "Failed to register backlight\n");
return PTR_ERR(priv->bl_dev);
--
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
[PATCH 2/5] backlight: led_bl: drop useless NULL initialization
There's no need to set 'levels' to NULL.
Signed-off-by: Tomi Valkeinen
---
drivers/video/backlight/led_bl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/backlight/led_bl.c b/drivers/video/backlight/led_bl.c
index d4e1ce684366..c46ecdfe8b0a 100644
--- a/drivers/video/backlight/led_bl.c
+++ b/drivers/video/backlight/led_bl.c
@@ -140,7 +140,7 @@ static int led_bl_parse_levels(struct device *dev,
if (num_levels > 1) {
int i;
unsigned int db;
- u32 *levels = NULL;
+ u32 *levels;
levels = devm_kzalloc(dev, sizeof(u32) * num_levels,
GFP_KERNEL);
--
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
[PATCH 3/5] backlight: led_bl: add led_access locking
led_bl does not lock 'led_access' when calling led_sysfs_disable and
led_sysfs_enable, causing the below WARN. Add the locking.
WARNING: CPU: 0 PID: 223 at drivers/leds/led-core.c:353
led_sysfs_disable+0x4c/0x5c
Signed-off-by: Tomi Valkeinen
---
drivers/video/backlight/led_bl.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/video/backlight/led_bl.c b/drivers/video/backlight/led_bl.c
index c46ecdfe8b0a..63693c4f0883 100644
--- a/drivers/video/backlight/led_bl.c
+++ b/drivers/video/backlight/led_bl.c
@@ -216,8 +216,11 @@ static int led_bl_probe(struct platform_device *pdev)
return PTR_ERR(priv->bl_dev);
}
- for (i = 0; i < priv->nb_leds; i++)
+ for (i = 0; i < priv->nb_leds; i++) {
+ mutex_lock(&priv->leds[i]->led_access);
led_sysfs_disable(priv->leds[i]);
+ mutex_unlock(&priv->leds[i]->led_access);
+ }
backlight_update_status(priv->bl_dev);
@@ -233,8 +236,11 @@ static int led_bl_remove(struct platform_device *pdev)
backlight_device_unregister(bl);
led_bl_power_off(priv);
- for (i = 0; i < priv->nb_leds; i++)
+ for (i = 0; i < priv->nb_leds; i++) {
+ mutex_lock(&priv->leds[i]->led_access);
led_sysfs_enable(priv->leds[i]);
+ mutex_unlock(&priv->leds[i]->led_access);
+ }
return 0;
}
--
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
[PATCH 5/5] backlight: led_bl: rewrite led_bl_parse_levels()
led_bl_parse_levels() is rather difficult to follow. Rewrite it with a
more obvious code flow.
Signed-off-by: Tomi Valkeinen
---
drivers/video/backlight/led_bl.c | 63
1 file changed, 32 insertions(+), 31 deletions(-)
diff --git a/drivers/video/backlight/led_bl.c b/drivers/video/backlight/led_bl.c
index 021b5edd895c..7b3889035540 100644
--- a/drivers/video/backlight/led_bl.c
+++ b/drivers/video/backlight/led_bl.c
@@ -132,50 +132,51 @@ static int led_bl_parse_levels(struct device *dev,
int num_levels;
u32 value;
int ret;
+ int i;
+ u32 *levels;
if (!node)
return -ENODEV;
num_levels = of_property_count_u32_elems(node, "brightness-levels");
- if (num_levels > 1) {
- int i;
- unsigned int db;
- u32 *levels;
-
- levels = devm_kzalloc(dev, sizeof(u32) * num_levels,
- GFP_KERNEL);
- if (!levels)
- return -ENOMEM;
-
- ret = of_property_read_u32_array(node, "brightness-levels",
-levels,
-num_levels);
- if (ret < 0)
- return ret;
-
- /*
-* Try to map actual LED brightness to backlight brightness
-* level
-*/
- db = priv->default_brightness;
+
+ if (num_levels < 0)
+ return 0;
+
+ if (num_levels == 0) {
+ dev_warn(dev, "No brightness-levels defined\n");
+ return -EINVAL;
+ }
+
+ levels = devm_kzalloc(dev, sizeof(u32) * num_levels,
+ GFP_KERNEL);
+ if (!levels)
+ return -ENOMEM;
+
+ ret = of_property_read_u32_array(node, "brightness-levels",
+levels,
+num_levels);
+ if (ret < 0)
+ return ret;
+
+ priv->max_brightness = num_levels - 1;
+ priv->levels = levels;
+
+ ret = of_property_read_u32(node, "default-brightness-level", &value);
+ if (!ret) {
+ priv->default_brightness = min(value, priv->max_brightness);
+ } else {
+ /* Map LED default-brightness to backlight brightness level */
+ unsigned int db = priv->default_brightness;
+
for (i = 0 ; i < num_levels; i++) {
if ((i == 0 || db > levels[i - 1]) && db <= levels[i])
break;
}
priv->default_brightness = i < num_levels ? i : 0;
- priv->max_brightness = num_levels - 1;
- priv->levels = levels;
- } else if (num_levels >= 0) {
- dev_warn(dev, "Not enough levels defined\n");
}
- ret = of_property_read_u32(node, "default-brightness-level", &value);
- if (!ret && value <= priv->max_brightness)
- priv->default_brightness = value;
- else if (!ret && value > priv->max_brightness)
- dev_warn(dev, "Invalid default brightness. Ignoring it\n");
-
return 0;
}
--
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 trivial 2/6] dma: Fix misspelling of "Analog Devices"
On 16-04-20, 12:30, Geert Uytterhoeven wrote: > According to https://www.analog.com/, the company name is spelled > "Analog Devices". Applied after updating the subsystem name, thanks -- ~Vinod ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: RFC: Drm-connector properties managed by another driver / privacy screen support
On Fri, 17 Apr 2020, Pekka Paalanen wrote: > On Wed, 15 Apr 2020 17:40:46 +0200 > Hans de Goede wrote: > >> Hi, >> >> On 4/15/20 5:28 PM, Jani Nikula wrote: >> > On Wed, 15 Apr 2020, Hans de Goede wrote: >> >> ii. Currently the "privacy-screen" property added by Rajat's >> >> patch-set is an enum with 2 possible values: >> >> "Enabled" >> >> "Disabled" >> >> >> >> We could add a third value "Not Available", which would be the >> >> default and then for internal panels always add the property >> >> so that we avoid the problem that detecting if the laptop has >> >> an internal privacy screen needs to be done before the connector >> >> is registered. Then we can add some hooks which allow an >> >> lcdshadow-driver to register itself against a connector later >> >> (which is non trivial wrt probe order, but lets ignore that for now). >> > >> > I regret dropping the ball on Rajat's series (sorry!). >> > >> > I do think having the connector property for this is the way to go. >> >> I 100% agree. >> >> > Even >> > if we couldn't necessarily figure out all the details on the kernel >> > internal connections, can we settle on the property though, so we could >> > move forward with Rajat's series? >> >> Yes please, this will also allow us to move forward with userspace >> support even if for testing that we do some hacks for the kernel's >> internal connections for now. >> >> > Moreover, do we actually need two properties, one which could indicate >> > userspace's desire for the property, and another that tells the hardware >> > state? >> >> No I do not think so. I would expect there to just be one property, >> I guess that if the state is (partly) firmware controlled then there >> might be a race, but we will need a notification mechanism (*) for >> firmware triggered state changes anyways, so shortly after loosing >> the race userspace will process the notification and it will know >> about it. >> >> One thing which might be useful is a way to signal that the property >> is read-only in case we ever hit hw where that is the case. >> >> > I'd so very much like to have no in-kernel/in-firmware shortcuts >> > to enable/disable the privacy screen, and instead have any hardware >> > buttons just be events that the userspace could react to. However I >> > don't think that'll be the case unfortunately. >> >> In my experience with keyboard-backlight support, we will (unfortunately) >> see a mix and in some case we will get a notification that the firmware >> has adjusted the state, rather then just getting a keypress and >> dealing with that ourselves. In some cases we may even be able to >> choose, so the fw will deal with it by default but we can ask it >> to just send a key-press. But I do believe that we can *not* expect >> that we will always just get a keypress for userspace to deal with. > > Hi, > > let's think about how userspace uses atomic KMS UAPI. The simplest way > to use atomic correctly is that userspace will for every update send the > full, complete set of all properties that exist, both known and unknown > to userspace (to recover from temporarily VT-switching to another KMS > program that changes unknown properties). Attempting to track which > properties already have their correct values in the kernel is extra > work for just extra bugs. > > Assuming the property is userspace-writable: if kernel goes and > changes the property value on its own, it will very likely be just > overwritten by userspace right after if userspace does not manage to > process the uevent first. If that happens and userspace later > processes the uevent, userspace queries the kernel for the current > proprerty state which is now what userspace wrote, not what firmware > set. > > Therefore you end up with the firmware hotkey working only randomly. > > It would be much better to have the hotkey events delivered to > userspace so that userspace can control the privacy screen and > everything will be reliable, both the hotkeys and any GUI for it. I'd like this too. However I fear this is out of our control, and OEMs have and will anyway fiddle with the privacy screen directly no matter what we say, and we can't prevent that. From their POV it's easier for them to do their value-add in components they have total control over. I emphatize with that view, even if it's counter-productive from the Linux ecosystem POV. So we'll just have to deal with it. > The other reliable option is that userspace must never be able to > change privacy screen state, only the hardware hotkeys can. That, in turn, discourages anyone from doing the right thing, and blocks us from adding any nice additional features for privacy screens that only the userspace is capable of managing. For example, controlling privacy screen based on content, which seems like an obvious feature. I suppose rf-kill is a bit similar. You'd have a userspace controlled property to state what the userspace wants, and a kernel controlled property to
[PATCH] drm/panel: panel-simple: Set AUO G101EVN010 panel type
The AUO G101EVN010 is a 18-bit LVDS panel, not a parallel panel, as
indicated by the current bus_format.
Fix the bus_format to MEDIA_BUS_FMT_RGB666_1X7X3_SPWG, and also set the
connector_type to LVDS.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/panel/panel-simple.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 3ad828eaefe1..bf781e260fe7 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -836,7 +836,8 @@ static const struct panel_desc auo_g101evn010 = {
.width = 216,
.height = 135,
},
- .bus_format = MEDIA_BUS_FMT_RGB666_1X18,
+ .bus_format = MEDIA_BUS_FMT_RGB666_1X7X3_SPWG,
+ .connector_type = DRM_MODE_CONNECTOR_LVDS,
};
static const struct drm_display_mode auo_g104sn02_mode = {
--
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
[PATCH] drm/omap: change default signal polarities and drives
If the given videomode does not specify DISPLAY_FLAG_* for the specific signal property, the driver used a default value. These defaults were never thought through, as the expectation was that all the DISPLAY_FLAGS are always set explicitly. With DRM bridge and panel drivers this is not the case, and while that issue should be resolved in the future, it's still good to have sane signal defaults. This patch changes the defaults to what the hardware has as reset defaults. Also, based on my experience, I think they make sense and are more likely correct than the defaults without this patch. Signed-off-by: Tomi Valkeinen --- drivers/gpu/drm/omapdrm/dss/dispc.c | 33 ++--- 1 file changed, 6 insertions(+), 27 deletions(-) diff --git a/drivers/gpu/drm/omapdrm/dss/dispc.c b/drivers/gpu/drm/omapdrm/dss/dispc.c index dbb90f2d2ccd..6639ee9b05d3 100644 --- a/drivers/gpu/drm/omapdrm/dss/dispc.c +++ b/drivers/gpu/drm/omapdrm/dss/dispc.c @@ -3137,33 +3137,12 @@ static void _dispc_mgr_set_lcd_timings(struct dispc_device *dispc, dispc_write_reg(dispc, DISPC_TIMING_H(channel), timing_h); dispc_write_reg(dispc, DISPC_TIMING_V(channel), timing_v); - if (vm->flags & DISPLAY_FLAGS_VSYNC_HIGH) - vs = false; - else - vs = true; - - if (vm->flags & DISPLAY_FLAGS_HSYNC_HIGH) - hs = false; - else - hs = true; - - if (vm->flags & DISPLAY_FLAGS_DE_HIGH) - de = false; - else - de = true; - - if (vm->flags & DISPLAY_FLAGS_PIXDATA_POSEDGE) - ipc = false; - else - ipc = true; - - /* always use the 'rf' setting */ - onoff = true; - - if (vm->flags & DISPLAY_FLAGS_SYNC_POSEDGE) - rf = true; - else - rf = false; + vs = !!(vm->flags & DISPLAY_FLAGS_VSYNC_LOW); + hs = !!(vm->flags & DISPLAY_FLAGS_HSYNC_LOW); + de = !!(vm->flags & DISPLAY_FLAGS_DE_LOW); + ipc = !!(vm->flags & DISPLAY_FLAGS_PIXDATA_NEGEDGE); + onoff = true; /* always use the 'rf' setting */ + rf = !!(vm->flags & DISPLAY_FLAGS_SYNC_POSEDGE); l = FLD_VAL(onoff, 17, 17) | FLD_VAL(rf, 16, 16) | -- 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
[PATCH v10 00/14] In order to readout DP SDPs, refactors the handling of DP SDPs
In order to readout DP SDPs (Secondary Data Packet: DP HDR Metadata Infoframe SDP, DP VSC SDP), it refactors handling DP SDPs codes. It adds new compute routines for DP HDR Metadata Infoframe SDP and DP VSC SDP. And new writing routines of DP SDPs (Secondary Data Packet) that uses computed configs. New reading routines of DP SDPs are added for readout. It adds a logging function for DP VSC SDP. When receiving video it is very useful to be able to log DP VSC SDP. This greatly simplifies debugging. In order to use a common VSC SDP Colorimetry calculating code on PSR, it uses a new psr vsc sdp compute routine. v2: Minor style fix v3: - Add a new drm data structure for DP VSC SDP - Replace a structure name to drm_dp_vsc_sdp from intel_dp_vsc_sdp - Move logging functions to drm core [Jani N] And use drm core's DP VSC SDP logging function - Explicitly disable unused DIPs (AVI, GCP, VS, SPD, DRM. They will be used for HDMI), when intel_dp_set_infoframes() function will be called. v4: - Use struct drm_device logging macros - Rebased v5: - Use intel_de_*() functions for register access - Add warning where a bpc is 6 and a pixel format is RGB. - Addressed review comments from Uma Add kernel docs for added data structures Rename enum dp_colorspace to dp_pixelformat Polish commit message and comments Combine the if checks of sdp.HB2 and sdp.HB3 Add 6bpc to packining and unpacking of VSC SDP v6: Fix enabled infoframe states of lspcon v7: Fix the wrong check of combination bpc 6 and RGB pixelformat v8: Rebased v9: Add clear comments to hdmi_drm_infoframe_unpack_only() and hdmi_drm_infoframe_unpack() (Laurent Pinchart) v10: - Fix packing of VSC SDP where Pixel Encoding/Colorimetry Format is not supported - When a PSR is enabled, it needs to add DP_SDP_VSC to infoframes.enable. - Change a checking of PSR state. - Skip checking of VSC SDP when a crtc config has psr. - Rebased Gwan-gyeong Mun (14): video/hdmi: Add Unpack only function for DRM infoframe drm/i915/dp: Read out DP SDPs drm: Add logging function for DP VSC SDP drm/i915: Include HDMI DRM infoframe in the crtc state dump drm/i915: Include DP HDR Metadata Infoframe SDP in the crtc state dump drm/i915: Include DP VSC SDP in the crtc state dump drm/i915: Program DP SDPs with computed configs drm/i915: Add state readout for DP HDR Metadata Infoframe SDP drm/i915: Add state readout for DP VSC SDP drm/i915: Fix enabled infoframe states of lspcon drm/i915: Program DP SDPs on pipe updates drm/i915: Stop sending DP SDPs on ddi disable drm/i915/dp: Add compute routine for DP PSR VSC SDP drm/i915/psr: Use new DP VSC SDP compute routine on PSR drivers/gpu/drm/drm_dp_helper.c | 174 drivers/gpu/drm/i915/display/intel_ddi.c | 19 +- drivers/gpu/drm/i915/display/intel_display.c | 63 +++ drivers/gpu/drm/i915/display/intel_dp.c | 406 ++- drivers/gpu/drm/i915/display/intel_dp.h | 15 +- drivers/gpu/drm/i915/display/intel_lspcon.c | 2 +- drivers/gpu/drm/i915/display/intel_psr.c | 56 +-- drivers/gpu/drm/i915/display/intel_psr.h | 6 +- drivers/gpu/drm/i915/i915_drv.h | 1 + drivers/video/hdmi.c | 65 ++- include/drm/drm_dp_helper.h | 3 + include/linux/hdmi.h | 2 + 12 files changed, 549 insertions(+), 263 deletions(-) -- 2.25.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v10 07/14] drm/i915: Program DP SDPs with computed configs
In order to use computed config for DP SDPs (DP VSC SDP and DP HDR Metadata
Infoframe SDP), it replaces intel_dp_vsc_enable() function and
intel_dp_hdr_metadata_enable() function to intel_dp_set_infoframes()
function.
And it removes unused functions.
Before:
intel_dp_vsc_enable() and intel_dp_hdr_metadata_enable() compute sdp
configs and program sdp registers on enable callback of encoder.
After:
It separates computing of sdp configs and programming of sdp register.
The compute config callback of encoder calls computing sdp configs.
The enable callback of encoder calls programming sdp register.
v3: Rebased
v5: Polish commit message [Uma]
v10: Rebased
Signed-off-by: Gwan-gyeong Mun
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_ddi.c | 3 +-
drivers/gpu/drm/i915/display/intel_dp.c | 229 ---
drivers/gpu/drm/i915/display/intel_dp.h | 6 -
3 files changed, 1 insertion(+), 237 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index be6c61bcbc9c..d9278d7553ee 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -3668,8 +3668,7 @@ static void intel_enable_ddi_dp(struct intel_atomic_state
*state,
intel_edp_backlight_on(crtc_state, conn_state);
intel_psr_enable(intel_dp, crtc_state);
- intel_dp_vsc_enable(intel_dp, crtc_state, conn_state);
- intel_dp_hdr_metadata_enable(intel_dp, crtc_state, conn_state);
+ intel_dp_set_infoframes(encoder, true, crtc_state, conn_state);
intel_edp_drrs_enable(intel_dp, crtc_state);
if (crtc_state->has_audio)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index c435098179b7..2e8efe7aa776 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -5211,235 +5211,6 @@ void intel_read_dp_sdp(struct intel_encoder *encoder,
}
}
-static void
-intel_dp_setup_vsc_sdp(struct intel_dp *intel_dp,
- const struct intel_crtc_state *crtc_state,
- const struct drm_connector_state *conn_state)
-{
- struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
- struct dp_sdp vsc_sdp = {};
-
- /* Prepare VSC Header for SU as per DP 1.4a spec, Table 2-119 */
- vsc_sdp.sdp_header.HB0 = 0;
- vsc_sdp.sdp_header.HB1 = 0x7;
-
- /*
-* VSC SDP supporting 3D stereo, PSR2, and Pixel Encoding/
-* Colorimetry Format indication.
-*/
- vsc_sdp.sdp_header.HB2 = 0x5;
-
- /*
-* VSC SDP supporting 3D stereo, + PSR2, + Pixel Encoding/
-* Colorimetry Format indication (HB2 = 05h).
-*/
- vsc_sdp.sdp_header.HB3 = 0x13;
-
- /* DP 1.4a spec, Table 2-120 */
- switch (crtc_state->output_format) {
- case INTEL_OUTPUT_FORMAT_YCBCR444:
- vsc_sdp.db[16] = 0x1 << 4; /* YCbCr 444 : DB16[7:4] = 1h */
- break;
- case INTEL_OUTPUT_FORMAT_YCBCR420:
- vsc_sdp.db[16] = 0x3 << 4; /* YCbCr 420 : DB16[7:4] = 3h */
- break;
- case INTEL_OUTPUT_FORMAT_RGB:
- default:
- /* RGB: DB16[7:4] = 0h */
- break;
- }
-
- switch (conn_state->colorspace) {
- case DRM_MODE_COLORIMETRY_BT709_YCC:
- vsc_sdp.db[16] |= 0x1;
- break;
- case DRM_MODE_COLORIMETRY_XVYCC_601:
- vsc_sdp.db[16] |= 0x2;
- break;
- case DRM_MODE_COLORIMETRY_XVYCC_709:
- vsc_sdp.db[16] |= 0x3;
- break;
- case DRM_MODE_COLORIMETRY_SYCC_601:
- vsc_sdp.db[16] |= 0x4;
- break;
- case DRM_MODE_COLORIMETRY_OPYCC_601:
- vsc_sdp.db[16] |= 0x5;
- break;
- case DRM_MODE_COLORIMETRY_BT2020_CYCC:
- case DRM_MODE_COLORIMETRY_BT2020_RGB:
- vsc_sdp.db[16] |= 0x6;
- break;
- case DRM_MODE_COLORIMETRY_BT2020_YCC:
- vsc_sdp.db[16] |= 0x7;
- break;
- case DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65:
- case DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER:
- vsc_sdp.db[16] |= 0x4; /* DCI-P3 (SMPTE RP 431-2) */
- break;
- default:
- /* sRGB (IEC 61966-2-1) / ITU-R BT.601: DB16[0:3] = 0h */
-
- /* RGB->YCBCR color conversion uses the BT.709 color space. */
- if (crtc_state->output_format == INTEL_OUTPUT_FORMAT_YCBCR420)
- vsc_sdp.db[16] |= 0x1; /* 0x1, ITU-R BT.709 */
- break;
- }
-
- /*
-* For pixel encoding formats YCbCr444, YCbCr422, YCbCr420, and Y Only,
-* the following Component Bit Depth values are defined:
-* 001b = 8bpc.
-* 010b = 10bpc.
-* 011b = 12bpc.
-* 100b = 16bpc.
-*/
- switch
[PATCH v10 11/14] drm/i915: Program DP SDPs on pipe updates
Call intel_dp_set_infoframes() function on pipe updates to make sure that we send VSC SDP and HDR Metadata Infoframe SDP (when applicable) on fastsets. Signed-off-by: Gwan-gyeong Mun Reviewed-by: Uma Shankar --- drivers/gpu/drm/i915/display/intel_ddi.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c b/drivers/gpu/drm/i915/display/intel_ddi.c index bb26ea665540..4334f516ba54 100644 --- a/drivers/gpu/drm/i915/display/intel_ddi.c +++ b/drivers/gpu/drm/i915/display/intel_ddi.c @@ -3849,6 +3849,7 @@ static void intel_ddi_update_pipe_dp(struct intel_atomic_state *state, intel_ddi_set_dp_msa(crtc_state, conn_state); intel_psr_update(intel_dp, crtc_state); + intel_dp_set_infoframes(encoder, true, crtc_state, conn_state); intel_edp_drrs_enable(intel_dp, crtc_state); intel_panel_update_backlight(state, encoder, crtc_state, conn_state); -- 2.25.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v10 14/14] drm/i915/psr: Use new DP VSC SDP compute routine on PSR
In order to use a common VSC SDP Colorimetry calculating code on PSR,
it uses a new psr vsc sdp compute routine.
Because PSR routine has its own scenario and timings of writing a VSC SDP,
the current PSR routine needs to have its own drm_dp_vsc_sdp structure
member variable on struct i915_psr.
In order to calculate colorimetry information, intel_psr_update()
function and intel_psr_enable() function extend a drm_connector_state
argument.
There are no changes to PSR mechanism.
v3: Replace a structure name to drm_dp_vsc_sdp from intel_dp_vsc_sdp
v4: Rebased
v8: Rebased
v10: When a PSR is enabled, it needs to add DP_SDP_VSC to
infoframes.enable.
It is needed for comparing between HW and pipe_state of VSC_SDP.
Signed-off-by: Gwan-gyeong Mun
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_ddi.c | 4 +-
drivers/gpu/drm/i915/display/intel_psr.c | 56 +++-
drivers/gpu/drm/i915/display/intel_psr.h | 6 ++-
drivers/gpu/drm/i915/i915_drv.h | 1 +
4 files changed, 24 insertions(+), 43 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 2d6ed59bf04b..578945ae8ca5 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -3669,7 +3669,7 @@ static void intel_enable_ddi_dp(struct intel_atomic_state
*state,
intel_dp_stop_link_train(intel_dp);
intel_edp_backlight_on(crtc_state, conn_state);
- intel_psr_enable(intel_dp, crtc_state);
+ intel_psr_enable(intel_dp, crtc_state, conn_state);
intel_dp_set_infoframes(encoder, true, crtc_state, conn_state);
intel_edp_drrs_enable(intel_dp, crtc_state);
@@ -3850,7 +3850,7 @@ static void intel_ddi_update_pipe_dp(struct
intel_atomic_state *state,
intel_ddi_set_dp_msa(crtc_state, conn_state);
- intel_psr_update(intel_dp, crtc_state);
+ intel_psr_update(intel_dp, crtc_state, conn_state);
intel_dp_set_infoframes(encoder, true, crtc_state, conn_state);
intel_edp_drrs_enable(intel_dp, crtc_state);
diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
b/drivers/gpu/drm/i915/display/intel_psr.c
index a0569fdfeb16..95d21d9f7310 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.c
+++ b/drivers/gpu/drm/i915/display/intel_psr.c
@@ -30,6 +30,7 @@
#include "intel_display_types.h"
#include "intel_psr.h"
#include "intel_sprite.h"
+#include "intel_hdmi.h"
/**
* DOC: Panel Self Refresh (PSR/SRD)
@@ -357,39 +358,6 @@ void intel_psr_init_dpcd(struct intel_dp *intel_dp)
}
}
-static void intel_psr_setup_vsc(struct intel_dp *intel_dp,
- const struct intel_crtc_state *crtc_state)
-{
- struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
- struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
- struct dp_sdp psr_vsc;
-
- if (dev_priv->psr.psr2_enabled) {
- /* Prepare VSC Header for SU as per EDP 1.4 spec, Table 6.11 */
- memset(&psr_vsc, 0, sizeof(psr_vsc));
- psr_vsc.sdp_header.HB0 = 0;
- psr_vsc.sdp_header.HB1 = 0x7;
- if (dev_priv->psr.colorimetry_support) {
- psr_vsc.sdp_header.HB2 = 0x5;
- psr_vsc.sdp_header.HB3 = 0x13;
- } else {
- psr_vsc.sdp_header.HB2 = 0x4;
- psr_vsc.sdp_header.HB3 = 0xe;
- }
- } else {
- /* Prepare VSC packet as per EDP 1.3 spec, Table 3.10 */
- memset(&psr_vsc, 0, sizeof(psr_vsc));
- psr_vsc.sdp_header.HB0 = 0;
- psr_vsc.sdp_header.HB1 = 0x7;
- psr_vsc.sdp_header.HB2 = 0x2;
- psr_vsc.sdp_header.HB3 = 0x8;
- }
-
- intel_dig_port->write_infoframe(&intel_dig_port->base,
- crtc_state,
- DP_SDP_VSC, &psr_vsc, sizeof(psr_vsc));
-}
-
static void hsw_psr_setup_aux(struct intel_dp *intel_dp)
{
struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
@@ -798,6 +766,7 @@ void intel_psr_compute_config(struct intel_dp *intel_dp,
crtc_state->has_psr = true;
crtc_state->has_psr2 = intel_psr2_config_valid(intel_dp, crtc_state);
+ crtc_state->infoframes.enable |=
intel_hdmi_infoframe_enable(DP_SDP_VSC);
}
static void intel_psr_activate(struct intel_dp *intel_dp)
@@ -880,9 +849,12 @@ static void intel_psr_enable_source(struct intel_dp
*intel_dp,
}
static void intel_psr_enable_locked(struct drm_i915_private *dev_priv,
- const struct intel_crtc_state *crtc_state)
+ const struct intel_crtc_state *crtc_state,
+ const struct drm_connector_state
*conn_state)
{
struct intel_dp *intel_dp = dev_priv->psr.dp;
+ struct intel_dig
[PATCH v10 02/14] drm/i915/dp: Read out DP SDPs
It adds code to read the DP SDPs from the video DIP and unpack them into
the crtc state.
It adds routines that read out DP VSC SDP and DP HDR Metadata Infoframe SDP
In order to unpack DP VSC SDP, it adds intel_dp_vsc_sdp_unpack() function.
It follows DP 1.4a spec. [Table 2-116: VSC SDP Header Bytes] and
[Table 2-117: VSC SDP Payload for DB16 through DB18]
In order to unpack DP HDR Metadata Infoframe SDP, it adds
intel_dp_hdr_metadata_infoframe_sdp_unpack(). And it follows DP 1.4a spec.
([Table 2-125: INFOFRAME SDP v1.2 Header Bytes] and
[Table 2-126: INFOFRAME SDP v1.2 Payload Data Bytes - DB0 through DB31])
and CTA-861-G spec. [Table-42 Dynamic Range and Mastering InfoFrame].
A naming rule and style of intel_read_dp_sdp() function references
intel_read_infoframe() function of intel_hdmi.c
v2: Minor style fix
v3: Replace a structure name to drm_dp_vsc_sdp from intel_dp_vsc_sdp
v4: Use struct drm_device logging macros
v5: Addressed review comments from Uma
- Polish commit message and comments
- Combine the if checks of sdp.HB2 and sdp.HB3
- Add 6bpc to unpacking of VSC SDP
Signed-off-by: Gwan-gyeong Mun
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_dp.c | 187
drivers/gpu/drm/i915/display/intel_dp.h | 3 +
2 files changed, 190 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 48397b2c08cf..c435098179b7 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -5024,6 +5024,193 @@ void intel_dp_set_infoframes(struct intel_encoder
*encoder,
intel_write_dp_sdp(encoder, crtc_state,
HDMI_PACKET_TYPE_GAMUT_METADATA);
}
+static int intel_dp_vsc_sdp_unpack(struct drm_dp_vsc_sdp *vsc,
+ const void *buffer, size_t size)
+{
+ const struct dp_sdp *sdp = buffer;
+
+ if (size < sizeof(struct dp_sdp))
+ return -EINVAL;
+
+ memset(vsc, 0, size);
+
+ if (sdp->sdp_header.HB0 != 0)
+ return -EINVAL;
+
+ if (sdp->sdp_header.HB1 != DP_SDP_VSC)
+ return -EINVAL;
+
+ vsc->sdp_type = sdp->sdp_header.HB1;
+ vsc->revision = sdp->sdp_header.HB2;
+ vsc->length = sdp->sdp_header.HB3;
+
+ if ((sdp->sdp_header.HB2 == 0x2 && sdp->sdp_header.HB3 == 0x8) ||
+ (sdp->sdp_header.HB2 == 0x4 && sdp->sdp_header.HB3 == 0xe)) {
+ /*
+* - HB2 = 0x2, HB3 = 0x8
+* VSC SDP supporting 3D stereo + PSR
+* - HB2 = 0x4, HB3 = 0xe
+* VSC SDP supporting 3D stereo + PSR2 with Y-coordinate of
+* first scan line of the SU region (applies to eDP v1.4b
+* and higher).
+*/
+ return 0;
+ } else if (sdp->sdp_header.HB2 == 0x5 && sdp->sdp_header.HB3 == 0x13) {
+ /*
+* - HB2 = 0x5, HB3 = 0x13
+* VSC SDP supporting 3D stereo + PSR2 + Pixel
Encoding/Colorimetry
+* Format.
+*/
+ vsc->pixelformat = (sdp->db[16] >> 4) & 0xf;
+ vsc->colorimetry = sdp->db[16] & 0xf;
+ vsc->dynamic_range = (sdp->db[17] >> 7) & 0x1;
+
+ switch (sdp->db[17] & 0x7) {
+ case 0x0:
+ vsc->bpc = 6;
+ break;
+ case 0x1:
+ vsc->bpc = 8;
+ break;
+ case 0x2:
+ vsc->bpc = 10;
+ break;
+ case 0x3:
+ vsc->bpc = 12;
+ break;
+ case 0x4:
+ vsc->bpc = 16;
+ break;
+ default:
+ MISSING_CASE(sdp->db[17] & 0x7);
+ return -EINVAL;
+ }
+
+ vsc->content_type = sdp->db[18] & 0x7;
+ } else {
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static int
+intel_dp_hdr_metadata_infoframe_sdp_unpack(struct hdmi_drm_infoframe
*drm_infoframe,
+ const void *buffer, size_t size)
+{
+ int ret;
+
+ const struct dp_sdp *sdp = buffer;
+
+ if (size < sizeof(struct dp_sdp))
+ return -EINVAL;
+
+ if (sdp->sdp_header.HB0 != 0)
+ return -EINVAL;
+
+ if (sdp->sdp_header.HB1 != HDMI_INFOFRAME_TYPE_DRM)
+ return -EINVAL;
+
+ /*
+* Least Significant Eight Bits of (Data Byte Count – 1)
+* 1Dh (i.e., Data Byte Count = 30 bytes).
+*/
+ if (sdp->sdp_header.HB2 != 0x1D)
+ return -EINVAL;
+
+ /* Most Significant Two Bits of (Data Byte Count – 1), Clear to 00b. */
+ if ((sdp->sdp_header.HB3 & 0x3) != 0)
+ return -EINVAL;
+
+ /* INFOFRAME SDP Version Number *
[PATCH v10 09/14] drm/i915: Add state readout for DP VSC SDP
Added state readout for DP VSC SDP and enabled state validation
for DP VSC SDP.
v2: Minor style fix
v3: Replace a structure name to drm_dp_vsc_sdp from intel_dp_vsc_sdp
v4: Use struct drm_device logging macros
v10: Skip checking of VSC SDP when a crtc config has psr.
Signed-off-by: Gwan-gyeong Mun
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_ddi.c | 1 +
drivers/gpu/drm/i915/display/intel_display.c | 44
2 files changed, 45 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 5dbb54b88d0e..bb26ea665540 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -4218,6 +4218,7 @@ void intel_ddi_get_config(struct intel_encoder *encoder,
bdw_get_trans_port_sync_config(pipe_config);
intel_read_dp_sdp(encoder, pipe_config,
HDMI_PACKET_TYPE_GAMUT_METADATA);
+ intel_read_dp_sdp(encoder, pipe_config, DP_SDP_VSC);
}
static enum intel_output_type
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 332d857ad455..2e20c3447cb6 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -13467,6 +13467,13 @@ intel_compare_infoframe(const union hdmi_infoframe *a,
return memcmp(a, b, sizeof(*a)) == 0;
}
+static bool
+intel_compare_dp_vsc_sdp(const struct drm_dp_vsc_sdp *a,
+const struct drm_dp_vsc_sdp *b)
+{
+ return memcmp(a, b, sizeof(*a)) == 0;
+}
+
static void
pipe_config_infoframe_mismatch(struct drm_i915_private *dev_priv,
bool fastset, const char *name,
@@ -13492,6 +13499,31 @@ pipe_config_infoframe_mismatch(struct drm_i915_private
*dev_priv,
}
}
+static void
+pipe_config_dp_vsc_sdp_mismatch(struct drm_i915_private *dev_priv,
+ bool fastset, const char *name,
+ const struct drm_dp_vsc_sdp *a,
+ const struct drm_dp_vsc_sdp *b)
+{
+ if (fastset) {
+ if (!drm_debug_enabled(DRM_UT_KMS))
+ return;
+
+ drm_dbg_kms(&dev_priv->drm,
+ "fastset mismatch in %s dp sdp\n", name);
+ drm_dbg_kms(&dev_priv->drm, "expected:\n");
+ drm_dp_vsc_sdp_log(KERN_DEBUG, dev_priv->drm.dev, a);
+ drm_dbg_kms(&dev_priv->drm, "found:\n");
+ drm_dp_vsc_sdp_log(KERN_DEBUG, dev_priv->drm.dev, b);
+ } else {
+ drm_err(&dev_priv->drm, "mismatch in %s dp sdp\n", name);
+ drm_err(&dev_priv->drm, "expected:\n");
+ drm_dp_vsc_sdp_log(KERN_ERR, dev_priv->drm.dev, a);
+ drm_err(&dev_priv->drm, "found:\n");
+ drm_dp_vsc_sdp_log(KERN_ERR, dev_priv->drm.dev, b);
+ }
+}
+
static void __printf(4, 5)
pipe_config_mismatch(bool fastset, const struct intel_crtc *crtc,
const char *name, const char *format, ...)
@@ -13693,6 +13725,17 @@ intel_pipe_config_compare(const struct
intel_crtc_state *current_config,
} \
} while (0)
+#define PIPE_CONF_CHECK_DP_VSC_SDP(name) do { \
+ if (!current_config->has_psr && !pipe_config->has_psr && \
+ !intel_compare_dp_vsc_sdp(¤t_config->infoframes.name, \
+ &pipe_config->infoframes.name)) { \
+ pipe_config_dp_vsc_sdp_mismatch(dev_priv, fastset,
__stringify(name), \
+
¤t_config->infoframes.name, \
+ &pipe_config->infoframes.name);
\
+ ret = false; \
+ } \
+} while (0)
+
#define PIPE_CONF_CHECK_COLOR_LUT(name1, name2, bit_precision) do { \
if (current_config->name1 != pipe_config->name1) { \
pipe_config_mismatch(fastset, crtc, __stringify(name1), \
@@ -13868,6 +13911,7 @@ intel_pipe_config_compare(const struct intel_crtc_state
*current_config,
PIPE_CONF_CHECK_INFOFRAME(spd);
PIPE_CONF_CHECK_INFOFRAME(hdmi);
PIPE_CONF_CHECK_INFOFRAME(drm);
+ PIPE_CONF_CHECK_DP_VSC_SDP(vsc);
PIPE_CONF_CHECK_X(sync_mode_slaves_mask);
PIPE_CONF_CHECK_I(master_transcoder);
--
2.25.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v10 01/14] video/hdmi: Add Unpack only function for DRM infoframe
It adds an unpack only function for DRM infoframe for dynamic range and
mastering infoframe readout.
It unpacks the information data block contained in the binary buffer into
a structured frame of the HDMI Dynamic Range and Mastering (DRM)
information frame.
In contrast to hdmi_drm_infoframe_unpack() function, it does not verify
a checksum.
It can be used for unpacking a DP HDR Metadata Infoframe SDP case.
DP HDR Metadata Infoframe SDP uses the same Dynamic Range and Mastering
(DRM) information (CTA-861-G spec.) such as HDMI DRM infoframe.
But DP SDP header and payload structure are different from HDMI DRM
Infoframe. Therefore unpacking DRM infoframe for DP requires skipping of
a verifying checksum.
v9: Add clear comments to hdmi_drm_infoframe_unpack_only() and
hdmi_drm_infoframe_unpack() (Laurent Pinchart)
Signed-off-by: Gwan-gyeong Mun
Reviewed-by: Uma Shankar
Cc: Laurent Pinchart
Cc: Ville Syrjala
---
drivers/video/hdmi.c | 65 +++-
include/linux/hdmi.h | 2 ++
2 files changed, 48 insertions(+), 19 deletions(-)
diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
index 856a8c4e84a2..e70792b3e367 100644
--- a/drivers/video/hdmi.c
+++ b/drivers/video/hdmi.c
@@ -1768,20 +1768,21 @@ hdmi_vendor_any_infoframe_unpack(union
hdmi_vendor_any_infoframe *frame,
}
/**
- * hdmi_drm_infoframe_unpack() - unpack binary buffer to a HDMI DRM infoframe
+ * hdmi_drm_infoframe_unpack_only() - unpack binary buffer of CTA-861-G DRM
+ *infoframe DataBytes to a HDMI DRM
+ *infoframe
* @frame: HDMI DRM infoframe
* @buffer: source buffer
* @size: size of buffer
*
- * Unpacks the information contained in binary @buffer into a structured
- * @frame of the HDMI Dynamic Range and Mastering (DRM) information frame.
- * Also verifies the checksum as required by section 5.3.5 of the HDMI 1.4
- * specification.
+ * Unpacks CTA-861-G DRM infoframe DataBytes contained in the binary @buffer
+ * into a structured @frame of the HDMI Dynamic Range and Mastering (DRM)
+ * infoframe.
*
* Returns 0 on success or a negative error code on failure.
*/
-static int hdmi_drm_infoframe_unpack(struct hdmi_drm_infoframe *frame,
-const void *buffer, size_t size)
+int hdmi_drm_infoframe_unpack_only(struct hdmi_drm_infoframe *frame,
+ const void *buffer, size_t size)
{
const u8 *ptr = buffer;
const u8 *temp;
@@ -1790,23 +1791,13 @@ static int hdmi_drm_infoframe_unpack(struct
hdmi_drm_infoframe *frame,
int ret;
int i;
- if (size < HDMI_INFOFRAME_SIZE(DRM))
- return -EINVAL;
-
- if (ptr[0] != HDMI_INFOFRAME_TYPE_DRM ||
- ptr[1] != 1 ||
- ptr[2] != HDMI_DRM_INFOFRAME_SIZE)
- return -EINVAL;
-
- if (hdmi_infoframe_checksum(buffer, HDMI_INFOFRAME_SIZE(DRM)) != 0)
+ if (size < HDMI_DRM_INFOFRAME_SIZE)
return -EINVAL;
ret = hdmi_drm_infoframe_init(frame);
if (ret)
return ret;
- ptr += HDMI_INFOFRAME_HEADER_SIZE;
-
frame->eotf = ptr[0] & 0x7;
frame->metadata_type = ptr[1] & 0x7;
@@ -1814,7 +1805,7 @@ static int hdmi_drm_infoframe_unpack(struct
hdmi_drm_infoframe *frame,
for (i = 0; i < 3; i++) {
x_lsb = *temp++;
x_msb = *temp++;
- frame->display_primaries[i].x = (x_msb << 8) | x_lsb;
+ frame->display_primaries[i].x = (x_msb << 8) | x_lsb;
y_lsb = *temp++;
y_msb = *temp++;
frame->display_primaries[i].y = (y_msb << 8) | y_lsb;
@@ -1830,6 +1821,42 @@ static int hdmi_drm_infoframe_unpack(struct
hdmi_drm_infoframe *frame,
return 0;
}
+EXPORT_SYMBOL(hdmi_drm_infoframe_unpack_only);
+
+/**
+ * hdmi_drm_infoframe_unpack() - unpack binary buffer to a HDMI DRM infoframe
+ * @frame: HDMI DRM infoframe
+ * @buffer: source buffer
+ * @size: size of buffer
+ *
+ * Unpacks the CTA-861-G DRM infoframe contained in the binary @buffer into
+ * a structured @frame of the HDMI Dynamic Range and Mastering (DRM)
+ * infoframe. It also verifies the checksum as required by section 5.3.5 of
+ * the HDMI 1.4 specification.
+ *
+ * Returns 0 on success or a negative error code on failure.
+ */
+static int hdmi_drm_infoframe_unpack(struct hdmi_drm_infoframe *frame,
+const void *buffer, size_t size)
+{
+ const u8 *ptr = buffer;
+ int ret;
+
+ if (size < HDMI_INFOFRAME_SIZE(DRM))
+ return -EINVAL;
+
+ if (ptr[0] != HDMI_INFOFRAME_TYPE_DRM ||
+ ptr[1] != 1 ||
+ ptr[2] != HDMI_DRM_INFOFRAME_SIZE)
+ return -EINVAL;
+
+ if (hdmi_infoframe_checksum(buffer, HDMI_INFOFRAME_SIZE(DRM)) != 0)
+ return -EINVAL;
+
+ ret = hdmi_drm_infoframe_unpack_only(
[PATCH v10 12/14] drm/i915: Stop sending DP SDPs on ddi disable
Call intel_dp_set_infoframes(false) function on intel_ddi_post_disable_dp() to make sure not to send VSC SDP and HDR Metadata Infoframe SDP. v5: Polish commit message [Uma] Signed-off-by: Gwan-gyeong Mun Reviewed-by: Uma Shankar --- drivers/gpu/drm/i915/display/intel_ddi.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c b/drivers/gpu/drm/i915/display/intel_ddi.c index 4334f516ba54..2d6ed59bf04b 100644 --- a/drivers/gpu/drm/i915/display/intel_ddi.c +++ b/drivers/gpu/drm/i915/display/intel_ddi.c @@ -3459,6 +3459,8 @@ static void intel_ddi_post_disable_dp(struct intel_atomic_state *state, INTEL_OUTPUT_DP_MST); enum phy phy = intel_port_to_phy(dev_priv, encoder->port); + intel_dp_set_infoframes(encoder, false, old_crtc_state, old_conn_state); + /* * Power down sink before disabling the port, otherwise we end * up getting interrupts from the sink on detecting link loss. -- 2.25.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v10 13/14] drm/i915/dp: Add compute routine for DP PSR VSC SDP
In order to use a common VSC SDP Colorimetry calculating code on PSR,
it adds a compute routine for PSR VSC SDP.
As PSR routine can not use infoframes.vsc of crtc state, it also adds new
writing of DP SDPs (Secondary Data Packet) for PSR.
PSR routine has its own scenario and timings of writing a VSC SDP.
v3: Replace a structure name to drm_dp_vsc_sdp from intel_dp_vsc_sdp
v4: Use struct drm_device logging macros
v10: 1) Fix packing of VSC SDP where Pixel Encoding/Colorimetry Format is
not supported.
2) Change a checking of PSR state.
Signed-off-by: Gwan-gyeong Mun
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_dp.c | 66 -
drivers/gpu/drm/i915/display/intel_dp.h | 8 +++
2 files changed, 72 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 2e8efe7aa776..91699efdb2f3 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -2499,8 +2499,8 @@ static void intel_dp_compute_vsc_sdp(struct intel_dp
*intel_dp,
{
struct drm_dp_vsc_sdp *vsc = &crtc_state->infoframes.vsc;
- /* When PSR is enabled, VSC SDP is handled by PSR routine */
- if (intel_psr_enabled(intel_dp))
+ /* When a crtc state has PSR, VSC SDP will be handled by PSR routine */
+ if (crtc_state->has_psr)
return;
if (!intel_dp_needs_vsc_sdp(crtc_state, conn_state))
@@ -2512,6 +2512,42 @@ static void intel_dp_compute_vsc_sdp(struct intel_dp
*intel_dp,
&crtc_state->infoframes.vsc);
}
+void intel_dp_compute_psr_vsc_sdp(struct intel_dp *intel_dp,
+ const struct intel_crtc_state *crtc_state,
+ const struct drm_connector_state *conn_state,
+ struct drm_dp_vsc_sdp *vsc)
+{
+ struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
+
+ vsc->sdp_type = DP_SDP_VSC;
+
+ if (dev_priv->psr.psr2_enabled) {
+ if (dev_priv->psr.colorimetry_support &&
+ intel_dp_needs_vsc_sdp(crtc_state, conn_state)) {
+ /* [PSR2, +Colorimetry] */
+ intel_dp_compute_vsc_colorimetry(crtc_state, conn_state,
+vsc);
+ } else {
+ /*
+* [PSR2, -Colorimetry]
+* Prepare VSC Header for SU as per eDP 1.4 spec, Table
6-11
+* 3D stereo + PSR/PSR2 + Y-coordinate.
+*/
+ vsc->revision = 0x4;
+ vsc->length = 0xe;
+ }
+ } else {
+ /*
+* [PSR1]
+* Prepare VSC Header for SU as per DP 1.4 spec, Table 2-118
+* VSC SDP supporting 3D stereo + PSR (applies to eDP v1.3 or
+* higher).
+*/
+ vsc->revision = 0x2;
+ vsc->length = 0x8;
+ }
+}
+
static void
intel_dp_compute_hdr_metadata_infoframe_sdp(struct intel_dp *intel_dp,
struct intel_crtc_state *crtc_state,
@@ -4844,6 +4880,13 @@ static ssize_t intel_dp_vsc_sdp_pack(const struct
drm_dp_vsc_sdp *vsc,
sdp->sdp_header.HB2 = vsc->revision; /* Revision Number */
sdp->sdp_header.HB3 = vsc->length; /* Number of Valid Data Bytes */
+ /*
+* Only revision 0x5 supports Pixel Encoding/Colorimetry Format as
+* per DP 1.4a spec.
+*/
+ if (vsc->revision != 0x5)
+ goto out;
+
/* VSC SDP Payload for DB16 through DB18 */
/* Pixel Encoding and Colorimetry Formats */
sdp->db[16] = (vsc->pixelformat & 0xf) << 4; /* DB16[7:4] */
@@ -4876,6 +4919,7 @@ static ssize_t intel_dp_vsc_sdp_pack(const struct
drm_dp_vsc_sdp *vsc,
/* Content Type */
sdp->db[18] = vsc->content_type & 0x7;
+out:
return length;
}
@@ -4988,6 +5032,24 @@ static void intel_write_dp_sdp(struct intel_encoder
*encoder,
intel_dig_port->write_infoframe(encoder, crtc_state, type, &sdp, len);
}
+void intel_write_dp_vsc_sdp(struct intel_encoder *encoder,
+ const struct intel_crtc_state *crtc_state,
+ struct drm_dp_vsc_sdp *vsc)
+{
+ struct intel_digital_port *intel_dig_port = enc_to_dig_port(encoder);
+ struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
+ struct dp_sdp sdp = {};
+ ssize_t len;
+
+ len = intel_dp_vsc_sdp_pack(vsc, &sdp, sizeof(sdp));
+
+ if (drm_WARN_ON(&dev_priv->drm, len < 0))
+ return;
+
+ intel_dig_port->write_infoframe(encoder, crtc_state, DP_SDP_VSC,
+ &sdp, len);
+}
+
void intel_dp_set_infoframes(struct intel_encoder
[PATCH v10 08/14] drm/i915: Add state readout for DP HDR Metadata Infoframe SDP
Added state readout for DP HDR Metadata Infoframe SDP. v9: Rebased v10: Rebased Signed-off-by: Gwan-gyeong Mun Reviewed-by: Uma Shankar --- drivers/gpu/drm/i915/display/intel_ddi.c | 8 1 file changed, 8 insertions(+) diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c b/drivers/gpu/drm/i915/display/intel_ddi.c index d9278d7553ee..5dbb54b88d0e 100644 --- a/drivers/gpu/drm/i915/display/intel_ddi.c +++ b/drivers/gpu/drm/i915/display/intel_ddi.c @@ -4145,6 +4145,9 @@ void intel_ddi_get_config(struct intel_encoder *encoder, pipe_config->fec_enable); } + pipe_config->infoframes.enable |= + intel_hdmi_infoframes_enabled(encoder, pipe_config); + break; case TRANS_DDI_MODE_SELECT_DP_MST: pipe_config->output_types |= BIT(INTEL_OUTPUT_DP_MST); @@ -4156,6 +4159,9 @@ void intel_ddi_get_config(struct intel_encoder *encoder, REG_FIELD_GET(TRANS_DDI_MST_TRANSPORT_SELECT_MASK, temp); intel_dp_get_m_n(intel_crtc, pipe_config); + + pipe_config->infoframes.enable |= + intel_hdmi_infoframes_enabled(encoder, pipe_config); break; default: break; @@ -4210,6 +4216,8 @@ void intel_ddi_get_config(struct intel_encoder *encoder, if (INTEL_GEN(dev_priv) >= 8) bdw_get_trans_port_sync_config(pipe_config); + + intel_read_dp_sdp(encoder, pipe_config, HDMI_PACKET_TYPE_GAMUT_METADATA); } static enum intel_output_type -- 2.25.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v10 04/14] drm/i915: Include HDMI DRM infoframe in the crtc state dump
Dump out the HDMI Dynamic Range and Mastering (DRM) infoframe in the normal crtc state dump. Signed-off-by: Gwan-gyeong Mun Reviewed-by: Uma Shankar --- drivers/gpu/drm/i915/display/intel_display.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c index af5b4055b38a..b9bf9bce49d6 100644 --- a/drivers/gpu/drm/i915/display/intel_display.c +++ b/drivers/gpu/drm/i915/display/intel_display.c @@ -13001,6 +13001,9 @@ static void intel_dump_pipe_config(const struct intel_crtc_state *pipe_config, if (pipe_config->infoframes.enable & intel_hdmi_infoframe_enable(HDMI_INFOFRAME_TYPE_VENDOR)) intel_dump_infoframe(dev_priv, &pipe_config->infoframes.hdmi); + if (pipe_config->infoframes.enable & + intel_hdmi_infoframe_enable(HDMI_INFOFRAME_TYPE_DRM)) + intel_dump_infoframe(dev_priv, &pipe_config->infoframes.drm); drm_dbg_kms(&dev_priv->drm, "requested mode:\n"); drm_mode_debug_printmodeline(&pipe_config->hw.mode); -- 2.25.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v10 03/14] drm: Add logging function for DP VSC SDP
When receiving video it is very useful to be able to log DP VSC SDP.
This greatly simplifies debugging.
v2: Minor style fix
v3: Move logging functions to drm core [Jani N]
v5: Rebased
v10: Rebased
Signed-off-by: Gwan-gyeong Mun
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/drm_dp_helper.c | 174
include/drm/drm_dp_helper.h | 3 +
2 files changed, 177 insertions(+)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 612a59ec8116..43e57632b00a 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -1629,3 +1629,177 @@ int drm_dp_set_phy_test_pattern(struct drm_dp_aux *aux,
return 0;
}
EXPORT_SYMBOL(drm_dp_set_phy_test_pattern);
+
+static const char *dp_pixelformat_get_name(enum dp_pixelformat pixelformat)
+{
+ if (pixelformat < 0 || pixelformat > DP_PIXELFORMAT_RESERVED)
+ return "Invalid";
+
+ switch (pixelformat) {
+ case DP_PIXELFORMAT_RGB:
+ return "RGB";
+ case DP_PIXELFORMAT_YUV444:
+ return "YUV444";
+ case DP_PIXELFORMAT_YUV422:
+ return "YUV422";
+ case DP_PIXELFORMAT_YUV420:
+ return "YUV420";
+ case DP_PIXELFORMAT_Y_ONLY:
+ return "Y_ONLY";
+ case DP_PIXELFORMAT_RAW:
+ return "RAW";
+ default:
+ return "Reserved";
+ }
+}
+
+static const char *dp_colorimetry_get_name(enum dp_pixelformat pixelformat,
+ enum dp_colorimetry colorimetry)
+{
+ if (pixelformat < 0 || pixelformat > DP_PIXELFORMAT_RESERVED)
+ return "Invalid";
+
+ switch (colorimetry) {
+ case DP_COLORIMETRY_DEFAULT:
+ switch (pixelformat) {
+ case DP_PIXELFORMAT_RGB:
+ return "sRGB";
+ case DP_PIXELFORMAT_YUV444:
+ case DP_PIXELFORMAT_YUV422:
+ case DP_PIXELFORMAT_YUV420:
+ return "BT.601";
+ case DP_PIXELFORMAT_Y_ONLY:
+ return "DICOM PS3.14";
+ case DP_PIXELFORMAT_RAW:
+ return "Custom Color Profile";
+ default:
+ return "Reserved";
+ }
+ case DP_COLORIMETRY_RGB_WIDE_FIXED: /* and DP_COLORIMETRY_BT709_YCC */
+ switch (pixelformat) {
+ case DP_PIXELFORMAT_RGB:
+ return "Wide Fixed";
+ case DP_PIXELFORMAT_YUV444:
+ case DP_PIXELFORMAT_YUV422:
+ case DP_PIXELFORMAT_YUV420:
+ return "BT.709";
+ default:
+ return "Reserved";
+ }
+ case DP_COLORIMETRY_RGB_WIDE_FLOAT: /* and DP_COLORIMETRY_XVYCC_601 */
+ switch (pixelformat) {
+ case DP_PIXELFORMAT_RGB:
+ return "Wide Float";
+ case DP_PIXELFORMAT_YUV444:
+ case DP_PIXELFORMAT_YUV422:
+ case DP_PIXELFORMAT_YUV420:
+ return "xvYCC 601";
+ default:
+ return "Reserved";
+ }
+ case DP_COLORIMETRY_OPRGB: /* and DP_COLORIMETRY_XVYCC_709 */
+ switch (pixelformat) {
+ case DP_PIXELFORMAT_RGB:
+ return "OpRGB";
+ case DP_PIXELFORMAT_YUV444:
+ case DP_PIXELFORMAT_YUV422:
+ case DP_PIXELFORMAT_YUV420:
+ return "xvYCC 709";
+ default:
+ return "Reserved";
+ }
+ case DP_COLORIMETRY_DCI_P3_RGB: /* and DP_COLORIMETRY_SYCC_601 */
+ switch (pixelformat) {
+ case DP_PIXELFORMAT_RGB:
+ return "DCI-P3";
+ case DP_PIXELFORMAT_YUV444:
+ case DP_PIXELFORMAT_YUV422:
+ case DP_PIXELFORMAT_YUV420:
+ return "sYCC 601";
+ default:
+ return "Reserved";
+ }
+ case DP_COLORIMETRY_RGB_CUSTOM: /* and DP_COLORIMETRY_OPYCC_601 */
+ switch (pixelformat) {
+ case DP_PIXELFORMAT_RGB:
+ return "Custom Profile";
+ case DP_PIXELFORMAT_YUV444:
+ case DP_PIXELFORMAT_YUV422:
+ case DP_PIXELFORMAT_YUV420:
+ return "OpYCC 601";
+ default:
+ return "Reserved";
+ }
+ case DP_COLORIMETRY_BT2020_RGB: /* and DP_COLORIMETRY_BT2020_CYCC */
+ switch (pixelformat) {
+ case DP_PIXELFORMAT_RGB:
+ return "BT.2020 RGB";
+ case DP_PIXELFORMAT_YUV444:
+ case DP_PIXELFORMAT_YUV422:
+ case DP_PIXELFORMAT_YUV420:
+ re
[PATCH v10 05/14] drm/i915: Include DP HDR Metadata Infoframe SDP in the crtc state dump
Dump out the DP HDR Metadata Infoframe SDP in the normal crtc state dump. HDMI Dynamic Range and Mastering (DRM) infoframe and DP HDR Metadata Infoframe SDP use the same member variable in infoframes of crtc state. Signed-off-by: Gwan-gyeong Mun Reviewed-by: Uma Shankar --- drivers/gpu/drm/i915/display/intel_display.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c index b9bf9bce49d6..1c2814f753f6 100644 --- a/drivers/gpu/drm/i915/display/intel_display.c +++ b/drivers/gpu/drm/i915/display/intel_display.c @@ -13004,6 +13004,9 @@ static void intel_dump_pipe_config(const struct intel_crtc_state *pipe_config, if (pipe_config->infoframes.enable & intel_hdmi_infoframe_enable(HDMI_INFOFRAME_TYPE_DRM)) intel_dump_infoframe(dev_priv, &pipe_config->infoframes.drm); + if (pipe_config->infoframes.enable & + intel_hdmi_infoframe_enable(HDMI_PACKET_TYPE_GAMUT_METADATA)) + intel_dump_infoframe(dev_priv, &pipe_config->infoframes.drm); drm_dbg_kms(&dev_priv->drm, "requested mode:\n"); drm_mode_debug_printmodeline(&pipe_config->hw.mode); -- 2.25.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v10 06/14] drm/i915: Include DP VSC SDP in the crtc state dump
Dump out the DP VSC SDP in the normal crtc state dump
v3: Replace a structure name to drm_dp_vsc_sdp from intel_dp_vsc_sdp
Use drm core's DP VSC SDP logging function
Signed-off-by: Gwan-gyeong Mun
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_display.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 1c2814f753f6..332d857ad455 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -12844,6 +12844,16 @@ intel_dump_infoframe(struct drm_i915_private *dev_priv,
hdmi_infoframe_log(KERN_DEBUG, dev_priv->drm.dev, frame);
}
+static void
+intel_dump_dp_vsc_sdp(struct drm_i915_private *dev_priv,
+ const struct drm_dp_vsc_sdp *vsc)
+{
+ if (!drm_debug_enabled(DRM_UT_KMS))
+ return;
+
+ drm_dp_vsc_sdp_log(KERN_DEBUG, dev_priv->drm.dev, vsc);
+}
+
#define OUTPUT_TYPE(x) [INTEL_OUTPUT_ ## x] = #x
static const char * const output_type_str[] = {
@@ -13007,6 +13017,9 @@ static void intel_dump_pipe_config(const struct
intel_crtc_state *pipe_config,
if (pipe_config->infoframes.enable &
intel_hdmi_infoframe_enable(HDMI_PACKET_TYPE_GAMUT_METADATA))
intel_dump_infoframe(dev_priv, &pipe_config->infoframes.drm);
+ if (pipe_config->infoframes.enable &
+ intel_hdmi_infoframe_enable(DP_SDP_VSC))
+ intel_dump_dp_vsc_sdp(dev_priv, &pipe_config->infoframes.vsc);
drm_dbg_kms(&dev_priv->drm, "requested mode:\n");
drm_mode_debug_printmodeline(&pipe_config->hw.mode);
--
2.25.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v10 10/14] drm/i915: Fix enabled infoframe states of lspcon
Compared to implementation of DP and HDMI's encoder->infoframes_enabled,
the lspcon's implementation returns its active state. (we expect enabled
infoframe states of HW.) It leads to pipe state mismatch error
when ddi_get_config is called.
Because the current implementation of lspcon is not ready to support
readout infoframes, we need to return 0 here.
In order to support readout to lspcon, we need to implement read_infoframe
and infoframes_enabled. And set_infoframes also have to set an appropriate
bit on crtc_state->infoframes.enable
Cc: Ville Syrjälä
Signed-off-by: Gwan-gyeong Mun
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_lspcon.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_lspcon.c
b/drivers/gpu/drm/i915/display/intel_lspcon.c
index d807c5648c87..6ff7b226f0a1 100644
--- a/drivers/gpu/drm/i915/display/intel_lspcon.c
+++ b/drivers/gpu/drm/i915/display/intel_lspcon.c
@@ -522,7 +522,7 @@ u32 lspcon_infoframes_enabled(struct intel_encoder *encoder,
const struct intel_crtc_state *pipe_config)
{
/* FIXME actually read this from the hw */
- return enc_to_intel_lspcon(encoder)->active;
+ return 0;
}
void lspcon_resume(struct intel_lspcon *lspcon)
--
2.25.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [drm:simple_bridge_attach [simple_bridge]] *ERROR* Fix bridge driver to make connector optional!
Hello, On Fri, Apr 17, 2020 at 02:44:22PM +0200, Maxime Ripard wrote: > On Fri, Apr 17, 2020 at 02:18:11PM +0200, H. Nikolaus Schaller wrote: > > Hi Maxime, > > I have started to test v5.7-rc1 and can't fully boot the GTA04 > > device any more. > > > > What I see in the log is: > > > > [ 28.567840] [drm:simple_bridge_attach [simple_bridge]] *ERROR* Fix > > bridge driver to make connector optional! > > [ 28.567871] omapdrm omapdrm.0: unable to attach bridge > > /ocp@6800/dss@4805/encoder@48050c00 > > [ 28.786529] omapdrm omapdrm.0: omap_modeset_init failed: ret=-22 > > [ 28.841552] omapdrm: probe of omapdrm.0 failed with error -22 > > > > This device uses the ti,opa362 chip which did have a dedicated > > omapdss driver before (which is removed now) and which seems to > > be supported by the simple_bridge now. > > > > The opa362 is sitting in the video out path from > > > > omapdrm -> venc -> opa362 -> video-out-connector. > > > > What does this error mean? How can it be fixed? > > -22 is usually EINVAL, which can be pretty much anything. A good thing to do > would be to bisect to see which actual commit broke it, but if I was to bet > on > something I guess it would be > > https://lore.kernel.org/dri-devel/20200226112514.12455-1-laurent.pinch...@ideasonboard.com/ Would "[PATCH 0/2] drm: bridge: simple-bridge: Enable usage with DRM bridge connector helper" solve it ? -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/panel: panel-simple: Set AUO G101EVN010 panel type
Hi Tomi,
Thank you for the patch.
On Fri, Apr 17, 2020 at 04:00:34PM +0300, Tomi Valkeinen wrote:
> (Adding Alex to the thread)
>
> On 17/04/2020 14:40, Tomi Valkeinen wrote:
> > The AUO G101EVN010 is a 18-bit LVDS panel, not a parallel panel, as
> > indicated by the current bus_format.
> >
> > Fix the bus_format to MEDIA_BUS_FMT_RGB666_1X7X3_SPWG, and also set the
> > connector_type to LVDS.
> >
> > Signed-off-by: Tomi Valkeinen
I'll trust you on the format,
Acked-by: Laurent Pinchart
> > ---
> > drivers/gpu/drm/panel/panel-simple.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/panel/panel-simple.c
> > b/drivers/gpu/drm/panel/panel-simple.c
> > index 3ad828eaefe1..bf781e260fe7 100644
> > --- a/drivers/gpu/drm/panel/panel-simple.c
> > +++ b/drivers/gpu/drm/panel/panel-simple.c
> > @@ -836,7 +836,8 @@ static const struct panel_desc auo_g101evn010 = {
> > .width = 216,
> > .height = 135,
> > },
> > - .bus_format = MEDIA_BUS_FMT_RGB666_1X18,
> > + .bus_format = MEDIA_BUS_FMT_RGB666_1X7X3_SPWG,
> > + .connector_type = DRM_MODE_CONNECTOR_LVDS,
> > };
> >
> > static const struct drm_display_mode auo_g104sn02_mode = {
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/panel: panel-simple: Set AUO G101EVN010 panel type
(Adding Alex to the thread)
On 17/04/2020 14:40, Tomi Valkeinen wrote:
The AUO G101EVN010 is a 18-bit LVDS panel, not a parallel panel, as
indicated by the current bus_format.
Fix the bus_format to MEDIA_BUS_FMT_RGB666_1X7X3_SPWG, and also set the
connector_type to LVDS.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/panel/panel-simple.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 3ad828eaefe1..bf781e260fe7 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -836,7 +836,8 @@ static const struct panel_desc auo_g101evn010 = {
.width = 216,
.height = 135,
},
- .bus_format = MEDIA_BUS_FMT_RGB666_1X18,
+ .bus_format = MEDIA_BUS_FMT_RGB666_1X7X3_SPWG,
+ .connector_type = DRM_MODE_CONNECTOR_LVDS,
};
static const struct drm_display_mode auo_g104sn02_mode = {
--
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/omap: change default signal polarities and drives
Hi Tomi, Thank you for the patch. On Fri, Apr 17, 2020 at 02:41:51PM +0300, Tomi Valkeinen wrote: > If the given videomode does not specify DISPLAY_FLAG_* for the specific > signal property, the driver used a default value. These defaults were > never thought through, as the expectation was that all the DISPLAY_FLAGS > are always set explicitly. > > With DRM bridge and panel drivers this is not the case, and while that > issue should be resolved in the future, it's still good to have sane > signal defaults. > > This patch changes the defaults to what the hardware has as reset > defaults. Also, based on my experience, I think they make sense and are > more likely correct than the defaults without this patch. > > Signed-off-by: Tomi Valkeinen > --- > drivers/gpu/drm/omapdrm/dss/dispc.c | 33 ++--- > 1 file changed, 6 insertions(+), 27 deletions(-) > > diff --git a/drivers/gpu/drm/omapdrm/dss/dispc.c > b/drivers/gpu/drm/omapdrm/dss/dispc.c > index dbb90f2d2ccd..6639ee9b05d3 100644 > --- a/drivers/gpu/drm/omapdrm/dss/dispc.c > +++ b/drivers/gpu/drm/omapdrm/dss/dispc.c > @@ -3137,33 +3137,12 @@ static void _dispc_mgr_set_lcd_timings(struct > dispc_device *dispc, > dispc_write_reg(dispc, DISPC_TIMING_H(channel), timing_h); > dispc_write_reg(dispc, DISPC_TIMING_V(channel), timing_v); > > - if (vm->flags & DISPLAY_FLAGS_VSYNC_HIGH) > - vs = false; > - else > - vs = true; > - > - if (vm->flags & DISPLAY_FLAGS_HSYNC_HIGH) > - hs = false; > - else > - hs = true; > - > - if (vm->flags & DISPLAY_FLAGS_DE_HIGH) > - de = false; > - else > - de = true; > - > - if (vm->flags & DISPLAY_FLAGS_PIXDATA_POSEDGE) > - ipc = false; > - else > - ipc = true; > - > - /* always use the 'rf' setting */ > - onoff = true; > - > - if (vm->flags & DISPLAY_FLAGS_SYNC_POSEDGE) > - rf = true; > - else > - rf = false; > + vs = !!(vm->flags & DISPLAY_FLAGS_VSYNC_LOW); > + hs = !!(vm->flags & DISPLAY_FLAGS_HSYNC_LOW); > + de = !!(vm->flags & DISPLAY_FLAGS_DE_LOW); > + ipc = !!(vm->flags & DISPLAY_FLAGS_PIXDATA_NEGEDGE); > + onoff = true; /* always use the 'rf' setting */ > + rf = !!(vm->flags & DISPLAY_FLAGS_SYNC_POSEDGE); Would it make sense to WARN() if flags are not set, to catch offenders and fix them ? Apart from that, Reviewed-by: Laurent Pinchart > > l = FLD_VAL(onoff, 17, 17) | > FLD_VAL(rf, 16, 16) | -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/omap: change default signal polarities and drives
Hi Tomi, On Fri, Apr 17, 2020 at 04:34:19PM +0300, Tomi Valkeinen wrote: > On 17/04/2020 16:29, Laurent Pinchart wrote: > > On Fri, Apr 17, 2020 at 02:41:51PM +0300, Tomi Valkeinen wrote: > >> If the given videomode does not specify DISPLAY_FLAG_* for the specific > >> signal property, the driver used a default value. These defaults were > >> never thought through, as the expectation was that all the DISPLAY_FLAGS > >> are always set explicitly. > >> > >> With DRM bridge and panel drivers this is not the case, and while that > >> issue should be resolved in the future, it's still good to have sane > >> signal defaults. > >> > >> This patch changes the defaults to what the hardware has as reset > >> defaults. Also, based on my experience, I think they make sense and are > >> more likely correct than the defaults without this patch. > >> > >> Signed-off-by: Tomi Valkeinen > >> --- > >> drivers/gpu/drm/omapdrm/dss/dispc.c | 33 ++--- > >> 1 file changed, 6 insertions(+), 27 deletions(-) > >> > >> diff --git a/drivers/gpu/drm/omapdrm/dss/dispc.c > >> b/drivers/gpu/drm/omapdrm/dss/dispc.c > >> index dbb90f2d2ccd..6639ee9b05d3 100644 > >> --- a/drivers/gpu/drm/omapdrm/dss/dispc.c > >> +++ b/drivers/gpu/drm/omapdrm/dss/dispc.c > >> @@ -3137,33 +3137,12 @@ static void _dispc_mgr_set_lcd_timings(struct > >> dispc_device *dispc, > >>dispc_write_reg(dispc, DISPC_TIMING_H(channel), timing_h); > >>dispc_write_reg(dispc, DISPC_TIMING_V(channel), timing_v); > >> > >> - if (vm->flags & DISPLAY_FLAGS_VSYNC_HIGH) > >> - vs = false; > >> - else > >> - vs = true; > >> - > >> - if (vm->flags & DISPLAY_FLAGS_HSYNC_HIGH) > >> - hs = false; > >> - else > >> - hs = true; > >> - > >> - if (vm->flags & DISPLAY_FLAGS_DE_HIGH) > >> - de = false; > >> - else > >> - de = true; > >> - > >> - if (vm->flags & DISPLAY_FLAGS_PIXDATA_POSEDGE) > >> - ipc = false; > >> - else > >> - ipc = true; > >> - > >> - /* always use the 'rf' setting */ > >> - onoff = true; > >> - > >> - if (vm->flags & DISPLAY_FLAGS_SYNC_POSEDGE) > >> - rf = true; > >> - else > >> - rf = false; > >> + vs = !!(vm->flags & DISPLAY_FLAGS_VSYNC_LOW); > >> + hs = !!(vm->flags & DISPLAY_FLAGS_HSYNC_LOW); > >> + de = !!(vm->flags & DISPLAY_FLAGS_DE_LOW); > >> + ipc = !!(vm->flags & DISPLAY_FLAGS_PIXDATA_NEGEDGE); > >> + onoff = true; /* always use the 'rf' setting */ > >> + rf = !!(vm->flags & DISPLAY_FLAGS_SYNC_POSEDGE); > > > > Would it make sense to WARN() if flags are not set, to catch offenders > > and fix them ? Apart from that, > > Maybe at some point, but for now it would probably be printing WARNs on all > boards. I haven't looked > at exactly which driver combinations get the bus flags/formats right, but I > have a feeling that it's > not too many. Fair enough. Maybe we should try it locally first and see how many components are faulty. > And some pieces of hardware also may be "don't care" for certain flags, so I > think it's a valid case > that a bridge/panel doesn't define some of the flags. -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/omap: change default signal polarities and drives
On 17/04/2020 16:29, Laurent Pinchart wrote: Hi Tomi, Thank you for the patch. On Fri, Apr 17, 2020 at 02:41:51PM +0300, Tomi Valkeinen wrote: If the given videomode does not specify DISPLAY_FLAG_* for the specific signal property, the driver used a default value. These defaults were never thought through, as the expectation was that all the DISPLAY_FLAGS are always set explicitly. With DRM bridge and panel drivers this is not the case, and while that issue should be resolved in the future, it's still good to have sane signal defaults. This patch changes the defaults to what the hardware has as reset defaults. Also, based on my experience, I think they make sense and are more likely correct than the defaults without this patch. Signed-off-by: Tomi Valkeinen --- drivers/gpu/drm/omapdrm/dss/dispc.c | 33 ++--- 1 file changed, 6 insertions(+), 27 deletions(-) diff --git a/drivers/gpu/drm/omapdrm/dss/dispc.c b/drivers/gpu/drm/omapdrm/dss/dispc.c index dbb90f2d2ccd..6639ee9b05d3 100644 --- a/drivers/gpu/drm/omapdrm/dss/dispc.c +++ b/drivers/gpu/drm/omapdrm/dss/dispc.c @@ -3137,33 +3137,12 @@ static void _dispc_mgr_set_lcd_timings(struct dispc_device *dispc, dispc_write_reg(dispc, DISPC_TIMING_H(channel), timing_h); dispc_write_reg(dispc, DISPC_TIMING_V(channel), timing_v); - if (vm->flags & DISPLAY_FLAGS_VSYNC_HIGH) - vs = false; - else - vs = true; - - if (vm->flags & DISPLAY_FLAGS_HSYNC_HIGH) - hs = false; - else - hs = true; - - if (vm->flags & DISPLAY_FLAGS_DE_HIGH) - de = false; - else - de = true; - - if (vm->flags & DISPLAY_FLAGS_PIXDATA_POSEDGE) - ipc = false; - else - ipc = true; - - /* always use the 'rf' setting */ - onoff = true; - - if (vm->flags & DISPLAY_FLAGS_SYNC_POSEDGE) - rf = true; - else - rf = false; + vs = !!(vm->flags & DISPLAY_FLAGS_VSYNC_LOW); + hs = !!(vm->flags & DISPLAY_FLAGS_HSYNC_LOW); + de = !!(vm->flags & DISPLAY_FLAGS_DE_LOW); + ipc = !!(vm->flags & DISPLAY_FLAGS_PIXDATA_NEGEDGE); + onoff = true; /* always use the 'rf' setting */ + rf = !!(vm->flags & DISPLAY_FLAGS_SYNC_POSEDGE); Would it make sense to WARN() if flags are not set, to catch offenders and fix them ? Apart from that, Maybe at some point, but for now it would probably be printing WARNs on all boards. I haven't looked at exactly which driver combinations get the bus flags/formats right, but I have a feeling that it's not too many. And some pieces of hardware also may be "don't care" for certain flags, so I think it's a valid case that a bridge/panel doesn't define some of the flags. 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/amd/powerplay: remove defined but not used variables
On Fri, Apr 17, 2020 at 9:16 AM Jason Yan wrote:
>
> Fix the following gcc warning:
>
> drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/vega10_powertune.c:710:46:
> warning: ‘PSMGCEDCThresholdConfig_vega10’ defined but not used
> [-Wunused-const-variable=]
> static const struct vega10_didt_config_reg
> PSMGCEDCThresholdConfig_vega10[] =
> ^~
> drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/vega10_powertune.c:654:46:
> warning: ‘PSMSEEDCThresholdConfig_Vega10’ defined but not used
> [-Wunused-const-variable=]
> static const struct vega10_didt_config_reg
> PSMSEEDCThresholdConfig_Vega10[] =
> ^~
>
> Reported-by: Hulk Robot
> Signed-off-by: Jason Yan
Applied. Thanks!
Alex
> ---
> .../amd/powerplay/hwmgr/vega10_powertune.c| 23 ---
> 1 file changed, 23 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_powertune.c
> b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_powertune.c
> index ca9b23b5abc9..9757d47dd6b8 100644
> --- a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_powertune.c
> +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_powertune.c
> @@ -651,18 +651,6 @@ static const struct vega10_didt_config_reg
> PSMSEEDCStallDelayConfig_Vega10[] =
> { 0x } /* End of list */
> };
>
> -static const struct vega10_didt_config_reg
> PSMSEEDCThresholdConfig_Vega10[] =
> -{
> -/*
> -
> - * Offset Mask
>Shift
> Value
> - *
> -
> - */
> - /* SQ EDC THRESHOLD */
> - { ixDIDT_SQ_EDC_THRESHOLD,
> DIDT_SQ_EDC_THRESHOLD__EDC_THRESHOLD_MASK,
> DIDT_SQ_EDC_THRESHOLD__EDC_THRESHOLD__SHIFT,0x },
> -
> - { 0x } /* End of list */
> -};
> -
> static const struct vega10_didt_config_reg
> PSMSEEDCCtrlResetConfig_Vega10[] =
> {
> /*
> -
> @@ -707,17 +695,6 @@ static const struct vega10_didt_config_reg
> PSMSEEDCCtrlConfig_Vega10[] =
> { 0x } /* End of list */
> };
>
> -static const struct vega10_didt_config_reg
> PSMGCEDCThresholdConfig_vega10[] =
> -{
> -/*
> -
> - * Offset Mask
>Shift
> Value
> - *
> -
> - */
> - { mmGC_EDC_THRESHOLD,
> GC_EDC_THRESHOLD__EDC_THRESHOLD_MASK,
> GC_EDC_THRESHOLD__EDC_THRESHOLD__SHIFT, 0x000 },
> -
> - { 0x } /* End of list */
> -};
> -
> static const struct vega10_didt_config_reg
> PSMGCEDCDroopCtrlConfig_vega10[] =
> {
> /*
> -
> --
> 2.21.1
>
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH -next] drm/amd/dc: remove unused variable 'video_optimized_pixel_rates'
On Fri, Apr 17, 2020 at 9:16 AM YueHaibing wrote:
>
> drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_clock_source.c:1017:50:
> warning: ‘video_optimized_pixel_rates’ defined but not used
> [-Wunused-const-variable=]
> static const struct pixel_rate_range_table_entry
> video_optimized_pixel_rates[] = {
> ^~~
>
> commit d8cd587d2bfd ("drm/amd/display: removing MODULO change for dcn2")
> left behind this unused vairable, remove it.
>
> Signed-off-by: YueHaibing
Applied. Thanks!
Alex
> ---
> .../drm/amd/display/dc/dce/dce_clock_source.c | 33 ---
> 1 file changed, 33 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/dce/dce_clock_source.c
> b/drivers/gpu/drm/amd/display/dc/dce/dce_clock_source.c
> index 2e992fbc0d71..d2ad0504b0de 100644
> --- a/drivers/gpu/drm/amd/display/dc/dce/dce_clock_source.c
> +++ b/drivers/gpu/drm/amd/display/dc/dce/dce_clock_source.c
> @@ -1014,39 +1014,6 @@ struct pixel_rate_range_table_entry {
> unsigned short div_factor;
> };
>
> -static const struct pixel_rate_range_table_entry
> video_optimized_pixel_rates[] = {
> - // /1.001 rates
> - {25170, 25180, 25200, 1000, 1001}, //25.2MHz -> 25.17
> - {59340, 59350, 59400, 1000, 1001}, //59.4Mhz -> 59.340
> - {74170, 74180, 74250, 1000, 1001}, //74.25Mhz -> 74.1758
> - {125870, 125880, 126000, 1000, 1001}, //126Mhz-> 125.87
> - {148350, 148360, 148500, 1000, 1001}, //148.5Mhz -> 148.3516
> - {167830, 167840, 168000, 1000, 1001}, //168Mhz-> 167.83
> - {222520, 222530, 222750, 1000, 1001}, //222.75Mhz -> 222.527
> - {257140, 257150, 257400, 1000, 1001}, //257.4Mhz -> 257.1429
> - {296700, 296710, 297000, 1000, 1001}, //297Mhz-> 296.7033
> - {342850, 342860, 343200, 1000, 1001}, //343.2Mhz -> 342.857
> - {395600, 395610, 396000, 1000, 1001}, //396Mhz-> 395.6
> - {409090, 409100, 409500, 1000, 1001}, //409.5Mhz -> 409.091
> - {445050, 445060, 445500, 1000, 1001}, //445.5Mhz -> 445.055
> - {467530, 467540, 468000, 1000, 1001}, //468Mhz-> 467.5325
> - {519230, 519240, 519750, 1000, 1001}, //519.75Mhz -> 519.231
> - {525970, 525980, 526500, 1000, 1001}, //526.5Mhz -> 525.974
> - {545450, 545460, 546000, 1000, 1001}, //546Mhz-> 545.455
> - {593400, 593410, 594000, 1000, 1001}, //594Mhz-> 593.4066
> - {623370, 623380, 624000, 1000, 1001}, //624Mhz-> 623.377
> - {692300, 692310, 693000, 1000, 1001}, //693Mhz-> 692.308
> - {701290, 701300, 702000, 1000, 1001}, //702Mhz-> 701.2987
> - {791200, 791210, 792000, 1000, 1001}, //792Mhz-> 791.209
> - {890100, 890110, 891000, 1000, 1001}, //891Mhz-> 890.1099
> - {1186810, 1186820, 1188000, 1000, 1001},//1188Mhz -> 1186.8131
> -
> - // *1.001 rates
> - {27020, 27030, 27000, 1001, 1000}, //27Mhz
> - {54050, 54060, 54000, 1001, 1000}, //54Mhz
> - {108100, 108110, 108000, 1001, 1000},//108Mhz
> -};
> -
> static bool dcn20_program_pix_clk(
> struct clock_source *clock_source,
> struct pixel_clk_params *pix_clk_params,
> --
> 2.17.1
>
>
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 06/17] drm/msm: dsi: Use OPP API to set clk/perf state
On SDM845 DSI needs to express a perforamnce state
requirement on a power domain depending on the clock rates.
Use OPP table from DT to register with OPP framework and use
dev_pm_opp_set_rate() to set the clk/perf state.
Signed-off-by: Rajendra Nayak
Cc: Rob Clark
Cc: Sean Paul
Cc: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/msm/dsi/dsi.h | 2 ++
drivers/gpu/drm/msm/dsi/dsi_cfg.c | 4 +--
drivers/gpu/drm/msm/dsi/dsi_host.c | 53 ++
3 files changed, 57 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/dsi/dsi.h b/drivers/gpu/drm/msm/dsi/dsi.h
index 4de771d..ba7583c 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.h
+++ b/drivers/gpu/drm/msm/dsi/dsi.h
@@ -180,10 +180,12 @@ int msm_dsi_runtime_suspend(struct device *dev);
int msm_dsi_runtime_resume(struct device *dev);
int dsi_link_clk_set_rate_6g(struct msm_dsi_host *msm_host);
int dsi_link_clk_set_rate_v2(struct msm_dsi_host *msm_host);
+int dsi_link_clk_set_rate_6g_v2(struct msm_dsi_host *msm_host);
int dsi_link_clk_enable_6g(struct msm_dsi_host *msm_host);
int dsi_link_clk_enable_v2(struct msm_dsi_host *msm_host);
void dsi_link_clk_disable_6g(struct msm_dsi_host *msm_host);
void dsi_link_clk_disable_v2(struct msm_dsi_host *msm_host);
+void dsi_link_clk_disable_6g_v2(struct msm_dsi_host *msm_host);
int dsi_tx_buf_alloc_6g(struct msm_dsi_host *msm_host, int size);
int dsi_tx_buf_alloc_v2(struct msm_dsi_host *msm_host, int size);
void *dsi_tx_buf_get_6g(struct msm_dsi_host *msm_host);
diff --git a/drivers/gpu/drm/msm/dsi/dsi_cfg.c
b/drivers/gpu/drm/msm/dsi/dsi_cfg.c
index 813d69d..773c4fe 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_cfg.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_cfg.c
@@ -210,9 +210,9 @@ static const struct msm_dsi_host_cfg_ops
msm_dsi_6g_host_ops = {
};
static const struct msm_dsi_host_cfg_ops msm_dsi_6g_v2_host_ops = {
- .link_clk_set_rate = dsi_link_clk_set_rate_6g,
+ .link_clk_set_rate = dsi_link_clk_set_rate_6g_v2,
.link_clk_enable = dsi_link_clk_enable_6g,
- .link_clk_disable = dsi_link_clk_disable_6g,
+ .link_clk_disable = dsi_link_clk_disable_6g_v2,
.clk_init_ver = dsi_clk_init_6g_v2,
.tx_buf_alloc = dsi_tx_buf_alloc_6g,
.tx_buf_get = dsi_tx_buf_get_6g,
diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index 11ae5b8..d532fab 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -111,6 +112,9 @@ struct msm_dsi_host {
struct clk *pixel_clk_src;
struct clk *byte_intf_clk;
+ struct opp_table *opp;
+ bool opp_table;
+
u32 byte_clk_rate;
u32 pixel_clk_rate;
u32 esc_clk_rate;
@@ -537,6 +541,38 @@ int dsi_link_clk_set_rate_6g(struct msm_dsi_host *msm_host)
return 0;
}
+int dsi_link_clk_set_rate_6g_v2(struct msm_dsi_host *msm_host)
+{
+ int ret;
+ struct device *dev = &msm_host->pdev->dev;
+
+ DBG("Set clk rates: pclk=%d, byteclk=%d",
+ msm_host->mode->clock, msm_host->byte_clk_rate);
+
+ ret = dev_pm_opp_set_rate(dev, msm_host->byte_clk_rate);
+ if (ret) {
+ pr_err("%s: dev_pm_opp_set_rate failed %d\n", __func__, ret);
+ return ret;
+ }
+
+ ret = clk_set_rate(msm_host->pixel_clk, msm_host->pixel_clk_rate);
+ if (ret) {
+ pr_err("%s: Failed to set rate pixel clk, %d\n", __func__, ret);
+ return ret;
+ }
+
+ if (msm_host->byte_intf_clk) {
+ ret = clk_set_rate(msm_host->byte_intf_clk,
+ msm_host->byte_clk_rate / 2);
+ if (ret) {
+ pr_err("%s: Failed to set rate byte intf clk, %d\n",
+ __func__, ret);
+ return ret;
+ }
+ }
+
+ return 0;
+}
int dsi_link_clk_enable_6g(struct msm_dsi_host *msm_host)
{
@@ -665,6 +701,13 @@ void dsi_link_clk_disable_6g(struct msm_dsi_host *msm_host)
clk_disable_unprepare(msm_host->byte_clk);
}
+void dsi_link_clk_disable_6g_v2(struct msm_dsi_host *msm_host)
+{
+ /* Drop the performance state vote */
+ dev_pm_opp_set_rate(&msm_host->pdev->dev, 0);
+ dsi_link_clk_disable_6g(msm_host);
+}
+
void dsi_link_clk_disable_v2(struct msm_dsi_host *msm_host)
{
clk_disable_unprepare(msm_host->pixel_clk);
@@ -1879,6 +1922,13 @@ int msm_dsi_host_init(struct msm_dsi *msm_dsi)
goto fail;
}
+ msm_host->opp = dev_pm_opp_set_clkname(&pdev->dev, "byte");
+ if (IS_ERR(msm_host->opp))
+ return PTR_ERR(msm_host->opp);
+ /* OPP table is optional */
+ if (!dev_pm_opp_of_add_table(&pdev->dev))
+ msm_host->opp_table = true;
+
init_completion(&msm_host->dma_comp);
init_complet
[PATCH v2 05/17] drm/msm/dpu: Use OPP API to set clk/perf state
On some qualcomm platforms DPU needs to express a perforamnce state
requirement on a power domain depennding on the clock rates.
Use OPP table from DT to register with OPP framework and use
dev_pm_opp_set_rate() to set the clk/perf state.
Signed-off-by: Rajendra Nayak
Cc: Rob Clark
Cc: Sean Paul
Cc: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 3 ++-
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 20 +++-
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 4
3 files changed, 25 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
index 11f2beb..fe5717df 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
@@ -7,6 +7,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -239,7 +240,7 @@ static int _dpu_core_perf_set_core_clk_rate(struct dpu_kms
*kms, u64 rate)
rate = core_clk->max_rate;
core_clk->rate = rate;
- return msm_dss_clk_set_rate(core_clk, 1);
+ return dev_pm_opp_set_rate(&kms->pdev->dev, core_clk->rate);
}
static u64 _dpu_core_perf_get_core_clk_rate(struct dpu_kms *kms)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index ce19f1d..cfce642 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
#include
#include
@@ -1033,11 +1034,18 @@ static int dpu_bind(struct device *dev, struct device
*master, void *data)
if (!dpu_kms)
return -ENOMEM;
+ dpu_kms->opp = dev_pm_opp_set_clkname(dev, "core");
+ if (IS_ERR(dpu_kms->opp))
+ return PTR_ERR(dpu_kms->opp);
+ /* OPP table is optional */
+ if (!dev_pm_opp_of_add_table(dev))
+ dpu_kms->opp_table = true;
+
mp = &dpu_kms->mp;
ret = msm_dss_parse_clock(pdev, mp);
if (ret) {
DPU_ERROR("failed to parse clocks, ret=%d\n", ret);
- return ret;
+ goto err;
}
platform_set_drvdata(pdev, dpu_kms);
@@ -1051,6 +1059,11 @@ static int dpu_bind(struct device *dev, struct device
*master, void *data)
priv->kms = &dpu_kms->base;
return ret;
+err:
+ if (dpu_kms->opp_table)
+ dev_pm_opp_of_remove_table(dev);
+ dev_pm_opp_put_clkname(dpu_kms->opp);
+ return ret;
}
static void dpu_unbind(struct device *dev, struct device *master, void *data)
@@ -1059,6 +1072,9 @@ static void dpu_unbind(struct device *dev, struct device
*master, void *data)
struct dpu_kms *dpu_kms = platform_get_drvdata(pdev);
struct dss_module_power *mp = &dpu_kms->mp;
+ if (dpu_kms->opp_table)
+ dev_pm_opp_of_remove_table(dev);
+ dev_pm_opp_put_clkname(dpu_kms->opp);
msm_dss_put_clk(mp->clk_config, mp->num_clk);
devm_kfree(&pdev->dev, mp->clk_config);
mp->num_clk = 0;
@@ -1090,6 +1106,8 @@ static int __maybe_unused dpu_runtime_suspend(struct
device *dev)
struct dpu_kms *dpu_kms = platform_get_drvdata(pdev);
struct dss_module_power *mp = &dpu_kms->mp;
+ /* Drop the performance state vote */
+ dev_pm_opp_set_rate(dev, 0);
rc = msm_dss_enable_clk(mp->clk_config, mp->num_clk, false);
if (rc)
DPU_ERROR("clock disable failed rc:%d\n", rc);
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
index 211f5de9..0060709 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
@@ -128,6 +128,10 @@ struct dpu_kms {
struct platform_device *pdev;
bool rpm_enabled;
+
+ struct opp_table *opp;
+ bool opp_table;
+
struct dss_module_power mp;
/* reference count bandwidth requests, so we know when we can
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 1/5] video: ssd1307fb: Convert driver to use ->probe_new()
[ added dri-devel ML to Cc: ]
On 3/24/20 6:05 PM, Andy Shevchenko wrote:
> Use the ->probe_new() callback.
>
> The driver does not use const struct i2c_device_id * argument,
> so convert it to utilise the simplified I²C driver registration.
>
> Signed-off-by: Andy Shevchenko
Patch queued for v5.8, thanks.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
> ---
> drivers/video/fbdev/ssd1307fb.c | 10 ++
> 1 file changed, 2 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/video/fbdev/ssd1307fb.c b/drivers/video/fbdev/ssd1307fb.c
> index 142535267fec..397eae246c2c 100644
> --- a/drivers/video/fbdev/ssd1307fb.c
> +++ b/drivers/video/fbdev/ssd1307fb.c
> @@ -586,8 +586,7 @@ static const struct of_device_id ssd1307fb_of_match[] = {
> };
> MODULE_DEVICE_TABLE(of, ssd1307fb_of_match);
>
> -static int ssd1307fb_probe(struct i2c_client *client,
> -const struct i2c_device_id *id)
> +static int ssd1307fb_probe(struct i2c_client *client)
> {
> struct backlight_device *bl;
> char bl_name[12];
> @@ -599,11 +598,6 @@ static int ssd1307fb_probe(struct i2c_client *client,
> void *vmem;
> int ret;
>
> - if (!node) {
> - dev_err(&client->dev, "No device tree data found!\n");
> - return -EINVAL;
> - }
> -
> info = framebuffer_alloc(sizeof(struct ssd1307fb_par), &client->dev);
> if (!info)
> return -ENOMEM;
> @@ -808,7 +802,7 @@ static const struct i2c_device_id ssd1307fb_i2c_id[] = {
> MODULE_DEVICE_TABLE(i2c, ssd1307fb_i2c_id);
>
> static struct i2c_driver ssd1307fb_driver = {
> - .probe = ssd1307fb_probe,
> + .probe_new = ssd1307fb_probe,
> .remove = ssd1307fb_remove,
> .id_table = ssd1307fb_i2c_id,
> .driver = {
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 4/5] video: ssd1307fb: Convert to atomic PWM API
[ added dri-devel ML to Cc: ]
On 3/24/20 6:05 PM, Andy Shevchenko wrote:
> Use the atomic API wherever appropriate and get rid of pwm_apply_args()
> call (the reference period and polarity are now explicitly set when
> calling pwm_apply_state()).
>
> We also make use of the pwm_set_relative_duty_cycle() helper to ease
> relative to absolute duty_cycle conversion.
>
> Signed-off-by: Andy Shevchenko
Patch queued for v5.8, thanks.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
> ---
> drivers/video/fbdev/ssd1307fb.c | 17 +
> 1 file changed, 5 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/video/fbdev/ssd1307fb.c b/drivers/video/fbdev/ssd1307fb.c
> index 7a6a44a0b7a6..6e543396002a 100644
> --- a/drivers/video/fbdev/ssd1307fb.c
> +++ b/drivers/video/fbdev/ssd1307fb.c
> @@ -79,7 +79,6 @@ struct ssd1307fb_par {
> u32 prechargep1;
> u32 prechargep2;
> struct pwm_device *pwm;
> - u32 pwm_period;
> struct gpio_desc *reset;
> struct regulator *vbat_reg;
> u32 vcomh;
> @@ -297,9 +296,9 @@ static void ssd1307fb_deferred_io(struct fb_info *info,
>
> static int ssd1307fb_init(struct ssd1307fb_par *par)
> {
> + struct pwm_state pwmstate;
> int ret;
> u32 precharge, dclk, com_invdir, compins;
> - struct pwm_args pargs;
>
> if (par->device_info->need_pwm) {
> par->pwm = pwm_get(&par->client->dev, NULL);
> @@ -308,21 +307,15 @@ static int ssd1307fb_init(struct ssd1307fb_par *par)
> return PTR_ERR(par->pwm);
> }
>
> - /*
> - * FIXME: pwm_apply_args() should be removed when switching to
> - * the atomic PWM API.
> - */
> - pwm_apply_args(par->pwm);
> + pwm_init_state(par->pwm, &pwmstate);
> + pwm_set_relative_duty_cycle(&pwmstate, 50, 100);
> + pwm_apply_state(par->pwm, &pwmstate);
>
> - pwm_get_args(par->pwm, &pargs);
> -
> - par->pwm_period = pargs.period;
> /* Enable the PWM */
> - pwm_config(par->pwm, par->pwm_period / 2, par->pwm_period);
> pwm_enable(par->pwm);
>
> dev_dbg(&par->client->dev, "Using PWM%d with a %dns period.\n",
> - par->pwm->pwm, par->pwm_period);
> + par->pwm->pwm, pwm_get_period(par->pwm));
> }
>
> /* Set initial contrast */
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 0/6] video: fbdev: controlfb: small cleanup
On 3/24/20 2:45 PM, Bartlomiej Zolnierkiewicz wrote: > Hi, > > Small cleanup for controlfb driver: > > - fix sparse warnings > - remove not working module support > - add COMPILE_TEST support > - remove redundant function prototypes > > Changes since v1 > (https://lore.kernel.org/lkml/20200116140900.26363-1-b.zolnier...@samsung.com/): > - use in_le32() instead of le32_to_cpup() > - use eieio() and dcbf() helpers > - add invalid_vram_cache() helper > - add more dummy CONFIG_PPC_PMAC=n helpers to avoid ifdefs > - add ACKs from Sam > > Best regards, > -- > Bartlomiej Zolnierkiewicz > Samsung R&D Institute Poland > Samsung Electronics > > > Bartlomiej Zolnierkiewicz (6): > video: fbdev: controlfb: fix sparse warning about using incorrect type > video: fbdev: controlfb: add COMPILE_TEST support > video: fbdev: controlfb: remove obsolete module support > video: fbdev: controlfb: remove function prototypes part #1 > video: fbdev: controlfb: remove function prototypes part #2 > video: fbdev: controlfb: remove function prototypes part #3 > > drivers/video/fbdev/Kconfig | 2 +- > drivers/video/fbdev/controlfb.c | 828 +++- > 2 files changed, 391 insertions(+), 439 deletions(-) Patches #1-6 queued for v5.8. Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 2/5] video: ssd1307fb: Introduce temporary variable to increase readability
[ added dri-devel ML to Cc: ]
On 3/24/20 6:05 PM, Andy Shevchenko wrote:
> Introduce temporary variable to increase readability of the code.
>
> Signed-off-by: Andy Shevchenko
Patch queued for v5.8 (w/ few lines over 80 characters fixed), thanks.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
> ---
> drivers/video/fbdev/ssd1307fb.c | 34 ++---
> 1 file changed, 14 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/video/fbdev/ssd1307fb.c b/drivers/video/fbdev/ssd1307fb.c
> index 397eae246c2c..84dfd7b0f682 100644
> --- a/drivers/video/fbdev/ssd1307fb.c
> +++ b/drivers/video/fbdev/ssd1307fb.c
> @@ -588,6 +588,7 @@ MODULE_DEVICE_TABLE(of, ssd1307fb_of_match);
>
> static int ssd1307fb_probe(struct i2c_client *client)
> {
> + struct device *dev = &client->dev;
> struct backlight_device *bl;
> char bl_name[12];
> struct fb_info *info;
> @@ -598,7 +599,7 @@ static int ssd1307fb_probe(struct i2c_client *client)
> void *vmem;
> int ret;
>
> - info = framebuffer_alloc(sizeof(struct ssd1307fb_par), &client->dev);
> + info = framebuffer_alloc(sizeof(struct ssd1307fb_par), dev);
> if (!info)
> return -ENOMEM;
>
> @@ -608,23 +609,20 @@ static int ssd1307fb_probe(struct i2c_client *client)
>
> par->device_info = of_device_get_match_data(&client->dev);
>
> - par->reset = devm_gpiod_get_optional(&client->dev, "reset",
> - GPIOD_OUT_LOW);
> + par->reset = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_LOW);
> if (IS_ERR(par->reset)) {
> - dev_err(&client->dev, "failed to get reset gpio: %ld\n",
> - PTR_ERR(par->reset));
> + dev_err(dev, "failed to get reset gpio: %ld\n",
> PTR_ERR(par->reset));
> ret = PTR_ERR(par->reset);
> goto fb_alloc_error;
> }
>
> - par->vbat_reg = devm_regulator_get_optional(&client->dev, "vbat");
> + par->vbat_reg = devm_regulator_get_optional(dev, "vbat");
> if (IS_ERR(par->vbat_reg)) {
> ret = PTR_ERR(par->vbat_reg);
> if (ret == -ENODEV) {
> par->vbat_reg = NULL;
> } else {
> - dev_err(&client->dev, "failed to get VBAT regulator:
> %d\n",
> - ret);
> + dev_err(dev, "failed to get VBAT regulator: %d\n", ret);
> goto fb_alloc_error;
> }
> }
> @@ -674,15 +672,14 @@ static int ssd1307fb_probe(struct i2c_client *client)
> vmem = (void *)__get_free_pages(GFP_KERNEL | __GFP_ZERO,
> get_order(vmem_size));
> if (!vmem) {
> - dev_err(&client->dev, "Couldn't allocate graphical memory.\n");
> + dev_err(dev, "Couldn't allocate graphical memory.\n");
> ret = -ENOMEM;
> goto fb_alloc_error;
> }
>
> - ssd1307fb_defio = devm_kzalloc(&client->dev, sizeof(*ssd1307fb_defio),
> -GFP_KERNEL);
> + ssd1307fb_defio = devm_kzalloc(dev, sizeof(*ssd1307fb_defio),
> GFP_KERNEL);
> if (!ssd1307fb_defio) {
> - dev_err(&client->dev, "Couldn't allocate deferred io.\n");
> + dev_err(dev, "Couldn't allocate deferred io.\n");
> ret = -ENOMEM;
> goto fb_alloc_error;
> }
> @@ -720,8 +717,7 @@ static int ssd1307fb_probe(struct i2c_client *client)
> if (par->vbat_reg) {
> ret = regulator_enable(par->vbat_reg);
> if (ret) {
> - dev_err(&client->dev, "failed to enable VBAT: %d\n",
> - ret);
> + dev_err(dev, "failed to enable VBAT: %d\n", ret);
> goto reset_oled_error;
> }
> }
> @@ -732,17 +728,15 @@ static int ssd1307fb_probe(struct i2c_client *client)
>
> ret = register_framebuffer(info);
> if (ret) {
> - dev_err(&client->dev, "Couldn't register the framebuffer\n");
> + dev_err(dev, "Couldn't register the framebuffer\n");
> goto panel_init_error;
> }
>
> snprintf(bl_name, sizeof(bl_name), "ssd1307fb%d", info->node);
> - bl = backlight_device_register(bl_name, &client->dev, par,
> -&ssd1307fb_bl_ops, NULL);
> + bl = backlight_device_register(bl_name, dev, par, &ssd1307fb_bl_ops,
> NULL);
> if (IS_ERR(bl)) {
> ret = PTR_ERR(bl);
> - dev_err(&client->dev, "unable to register backlight device:
> %d\n",
> - ret);
> + dev_err(dev, "unable to register backlight device: %d\n", ret);
> goto bl_init_error;
> }
>
> @@ -750,7 +744,7 @@ static int ssd1307fb_probe(struct i2c_client *client)
> bl->props.max_bri
Re: [PATCH -next] omapfb/dss: remove unused varible 'venc_config_pal_bdghi'
On 4/15/20 3:23 PM, YueHaibing wrote:
> drivers/video/fbdev/omap2/omapfb/dss/venc.c:212:33:
> warning: ‘venc_config_pal_bdghi’ defined but not used
> [-Wunused-const-variable=]
> static const struct venc_config venc_config_pal_bdghi = {
> ^
>
> Reported-by: Hulk Robot
> Signed-off-by: YueHaibing
Patch queued for v5.8 (w/ typo in the patch summary fixed), thanks.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
> ---
> drivers/video/fbdev/omap2/omapfb/dss/venc.c | 43 -
> 1 file changed, 43 deletions(-)
>
> diff --git a/drivers/video/fbdev/omap2/omapfb/dss/venc.c
> b/drivers/video/fbdev/omap2/omapfb/dss/venc.c
> index f81e2a46366d..d5404d56c922 100644
> --- a/drivers/video/fbdev/omap2/omapfb/dss/venc.c
> +++ b/drivers/video/fbdev/omap2/omapfb/dss/venc.c
> @@ -209,49 +209,6 @@ static const struct venc_config venc_config_ntsc_trm = {
> .gen_ctrl = 0x00F9,
> };
>
> -static const struct venc_config venc_config_pal_bdghi = {
> - .f_control = 0,
> - .vidout_ctrl= 0,
> - .sync_ctrl = 0,
> - .hfltr_ctrl = 0,
> - .x_color= 0,
> - .line21 = 0,
> - .ln_sel = 21,
> - .htrigger_vtrigger = 0,
> - .tvdetgp_int_start_stop_x = 0x00140001,
> - .tvdetgp_int_start_stop_y = 0x00010001,
> - .gen_ctrl = 0x00FB,
> -
> - .llen = 864-1,
> - .flens = 625-1,
> - .cc_carr_wss_carr = 0x2F7625ED,
> - .c_phase= 0xDF,
> - .gain_u = 0x111,
> - .gain_v = 0x181,
> - .gain_y = 0x140,
> - .black_level= 0x3e,
> - .blank_level= 0x3e,
> - .m_control = 0<<2 | 1<<1,
> - .bstamp_wss_data= 0x42,
> - .s_carr = 0x2a098acb,
> - .l21__wc_ctl= 0<<13 | 0x16<<8 | 0<<0,
> - .savid__eavid = 0x06A70108,
> - .flen__fal = 23<<16 | 624<<0,
> - .lal__phase_reset = 2<<17 | 310<<0,
> - .hs_int_start_stop_x= 0x00920358,
> - .hs_ext_start_stop_x= 0x000F035F,
> - .vs_int_start_x = 0x1a7<<16,
> - .vs_int_stop_x__vs_int_start_y = 0x000601A7,
> - .vs_int_stop_y__vs_ext_start_x = 0x01AF0036,
> - .vs_ext_stop_x__vs_ext_start_y = 0x27101af,
> - .vs_ext_stop_y = 0x05,
> - .avid_start_stop_x = 0x03530082,
> - .avid_start_stop_y = 0x0270002E,
> - .fid_int_start_x__fid_int_start_y = 0x0005008A,
> - .fid_int_offset_y__fid_ext_start_x = 0x002E0138,
> - .fid_ext_start_y__fid_ext_offset_y = 0x01380005,
> -};
> -
> const struct omap_video_timings omap_dss_pal_timings = {
> .x_res = 720,
> .y_res = 574,
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 5/5] video: ssd1307fb: Remove redundant forward declaration
[ added dri-devel ML to Cc: ]
On 3/24/20 6:05 PM, Andy Shevchenko wrote:
> There is no need to have forward declaration of struct ssd1307fb_par.
> Drop it for good.
>
> Signed-off-by: Andy Shevchenko
Patch queued for v5.8, thanks.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
> ---
> drivers/video/fbdev/ssd1307fb.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/video/fbdev/ssd1307fb.c b/drivers/video/fbdev/ssd1307fb.c
> index 6e543396002a..509cab2c8b6c 100644
> --- a/drivers/video/fbdev/ssd1307fb.c
> +++ b/drivers/video/fbdev/ssd1307fb.c
> @@ -48,8 +48,6 @@
> static u_int refreshrate = REFRESHRATE;
> module_param(refreshrate, uint, 0);
>
> -struct ssd1307fb_par;
> -
> struct ssd1307fb_deviceinfo {
> u32 default_vcomh;
> u32 default_dclk_div;
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] video: fbdev: imxfb: ensure balanced regulator usage
On 3/23/20 10:16 PM, Uwe Kleine-König wrote:
> The fbdev framework doesn't care to call the .set_power callback only on
> changes. So the driver has to care for itself that the regulator doesn't
> get disabled more often than enabled.
>
> This fixes the regulator warning
>
> unbalanced disables for lcd supply
>
> which can be triggered by doing
>
> echo 4 > /sys/class/lcd/imxfb-lcd/lcd_power
>
> twice.
>
> Signed-off-by: Uwe Kleine-König
Patch queued for v5.8, thanks.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
> ---
> drivers/video/fbdev/imxfb.c | 27 +--
> 1 file changed, 21 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/video/fbdev/imxfb.c b/drivers/video/fbdev/imxfb.c
> index 370bf2553d43..884b16efa7e8 100644
> --- a/drivers/video/fbdev/imxfb.c
> +++ b/drivers/video/fbdev/imxfb.c
> @@ -172,6 +172,7 @@ struct imxfb_info {
> int num_modes;
>
> struct regulator*lcd_pwr;
> + int lcd_pwr_enabled;
> };
>
> static const struct platform_device_id imxfb_devtype[] = {
> @@ -801,16 +802,30 @@ static int imxfb_lcd_get_power(struct lcd_device
> *lcddev)
> return FB_BLANK_UNBLANK;
> }
>
> +static int imxfb_regulator_set(struct imxfb_info *fbi, int enable)
> +{
> + int ret;
> +
> + if (enable == fbi->lcd_pwr_enabled)
> + return 0;
> +
> + if (enable)
> + ret = regulator_enable(fbi->lcd_pwr);
> + else
> + ret = regulator_disable(fbi->lcd_pwr);
> +
> + if (ret == 0)
> + fbi->lcd_pwr_enabled = enable;
> +
> + return ret;
> +}
> +
> static int imxfb_lcd_set_power(struct lcd_device *lcddev, int power)
> {
> struct imxfb_info *fbi = dev_get_drvdata(&lcddev->dev);
>
> - if (!IS_ERR(fbi->lcd_pwr)) {
> - if (power == FB_BLANK_UNBLANK)
> - return regulator_enable(fbi->lcd_pwr);
> - else
> - return regulator_disable(fbi->lcd_pwr);
> - }
> + if (!IS_ERR(fbi->lcd_pwr))
> + return imxfb_regulator_set(fbi, power == FB_BLANK_UNBLANK);
>
> return 0;
> }
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/6] video: fbdev: controlfb: fix sparse warning about using incorrect type
On 3/24/20 9:45 PM, Daniel Vetter wrote:
> On Tue, Mar 24, 2020 at 02:45:03PM +0100, Bartlomiej Zolnierkiewicz wrote:
>> Use in_le32() instead of le32_to_cpup() to fix sparse warning about
>> improper type of the argument.
>>
>> Also add missing inline keyword to control_par_to_var() definition
>> (to match function prototype).
>>
>> Acked-by: Sam Ravnborg
>> Signed-off-by: Bartlomiej Zolnierkiewicz
>> ---
>> drivers/video/fbdev/controlfb.c | 5 +++--
>> 1 file changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/video/fbdev/controlfb.c
>> b/drivers/video/fbdev/controlfb.c
>> index 38b61cdb5ca4..9625792f4413 100644
>> --- a/drivers/video/fbdev/controlfb.c
>> +++ b/drivers/video/fbdev/controlfb.c
>> @@ -313,7 +313,7 @@ static int controlfb_blank(int blank_mode, struct
>> fb_info *info)
>> container_of(info, struct fb_info_control, info);
>> unsigned ctrl;
>>
>> -ctrl = le32_to_cpup(CNTRL_REG(p,ctrl));
>> +ctrl = in_le32(CNTRL_REG(p, ctrl));
>> if (blank_mode > 0)
>> switch (blank_mode) {
>> case FB_BLANK_VSYNC_SUSPEND:
>> @@ -952,7 +952,8 @@ static int control_var_to_par(struct fb_var_screeninfo
>> *var,
>> * Convert hardware data in par to an fb_var_screeninfo
>> */
>>
>> -static void control_par_to_var(struct fb_par_control *par, struct
>> fb_var_screeninfo *var)
>> +static inline void control_par_to_var(struct fb_par_control *par,
>
> Just quick drive-by bikeshed, feel free to ignore: static inline within a
> .c file imo doesn't make sense anymore, compilers are smart enough
> nowadays. I'd just drop this.
> -Daniel
I fixed this while applying patch series, thanks!
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
>> +struct fb_var_screeninfo *var)
>> {
>> struct control_regints *rv;
>>
>> --
>> 2.24.1
>>
>> ___
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> https://protect2.fireeye.com/url?k=e81baef1-b5d19b46-e81a25be-0cc47a3003e8-c88ec3abd71f4ad4&u=https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 3/5] video: ssd1307fb: Make use of device properties
[ added dri-devel ML to Cc: ]
On 3/24/20 6:05 PM, Andy Shevchenko wrote:
> Device property API allows to gather device resources from different sources,
> such as ACPI. Convert the drivers to unleash the power of device property API.
>
> Signed-off-by: Andy Shevchenko
Patch queued for v5.8, thanks.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
> ---
> drivers/video/fbdev/ssd1307fb.c | 40 -
> 1 file changed, 19 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/video/fbdev/ssd1307fb.c b/drivers/video/fbdev/ssd1307fb.c
> index 84dfd7b0f682..7a6a44a0b7a6 100644
> --- a/drivers/video/fbdev/ssd1307fb.c
> +++ b/drivers/video/fbdev/ssd1307fb.c
> @@ -12,8 +12,7 @@
> #include
> #include
> #include
> -#include
> -#include
> +#include
> #include
> #include
> #include
> @@ -592,7 +591,6 @@ static int ssd1307fb_probe(struct i2c_client *client)
> struct backlight_device *bl;
> char bl_name[12];
> struct fb_info *info;
> - struct device_node *node = client->dev.of_node;
> struct fb_deferred_io *ssd1307fb_defio;
> u32 vmem_size;
> struct ssd1307fb_par *par;
> @@ -607,7 +605,7 @@ static int ssd1307fb_probe(struct i2c_client *client)
> par->info = info;
> par->client = client;
>
> - par->device_info = of_device_get_match_data(&client->dev);
> + par->device_info = device_get_match_data(dev);
>
> par->reset = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_LOW);
> if (IS_ERR(par->reset)) {
> @@ -627,44 +625,44 @@ static int ssd1307fb_probe(struct i2c_client *client)
> }
> }
>
> - if (of_property_read_u32(node, "solomon,width", &par->width))
> + if (device_property_read_u32(dev, "solomon,width", &par->width))
> par->width = 96;
>
> - if (of_property_read_u32(node, "solomon,height", &par->height))
> + if (device_property_read_u32(dev, "solomon,height", &par->height))
> par->height = 16;
>
> - if (of_property_read_u32(node, "solomon,page-offset",
> &par->page_offset))
> + if (device_property_read_u32(dev, "solomon,page-offset",
> &par->page_offset))
> par->page_offset = 1;
>
> - if (of_property_read_u32(node, "solomon,com-offset", &par->com_offset))
> + if (device_property_read_u32(dev, "solomon,com-offset",
> &par->com_offset))
> par->com_offset = 0;
>
> - if (of_property_read_u32(node, "solomon,prechargep1",
> &par->prechargep1))
> + if (device_property_read_u32(dev, "solomon,prechargep1",
> &par->prechargep1))
> par->prechargep1 = 2;
>
> - if (of_property_read_u32(node, "solomon,prechargep2",
> &par->prechargep2))
> + if (device_property_read_u32(dev, "solomon,prechargep2",
> &par->prechargep2))
> par->prechargep2 = 2;
>
> - if (!of_property_read_u8_array(node, "solomon,lookup-table",
> -par->lookup_table,
> -ARRAY_SIZE(par->lookup_table)))
> + if (!device_property_read_u8_array(dev, "solomon,lookup-table",
> +par->lookup_table,
> +ARRAY_SIZE(par->lookup_table)))
> par->lookup_table_set = 1;
>
> - par->seg_remap = !of_property_read_bool(node,
> "solomon,segment-no-remap");
> - par->com_seq = of_property_read_bool(node, "solomon,com-seq");
> - par->com_lrremap = of_property_read_bool(node, "solomon,com-lrremap");
> - par->com_invdir = of_property_read_bool(node, "solomon,com-invdir");
> + par->seg_remap = !device_property_read_bool(dev,
> "solomon,segment-no-remap");
> + par->com_seq = device_property_read_bool(dev, "solomon,com-seq");
> + par->com_lrremap = device_property_read_bool(dev,
> "solomon,com-lrremap");
> + par->com_invdir = device_property_read_bool(dev, "solomon,com-invdir");
> par->area_color_enable =
> - of_property_read_bool(node, "solomon,area-color-enable");
> - par->low_power = of_property_read_bool(node, "solomon,low-power");
> + device_property_read_bool(dev, "solomon,area-color-enable");
> + par->low_power = device_property_read_bool(dev, "solomon,low-power");
>
> par->contrast = 127;
> par->vcomh = par->device_info->default_vcomh;
>
> /* Setup display timing */
> - if (of_property_read_u32(node, "solomon,dclk-div", &par->dclk_div))
> + if (device_property_read_u32(dev, "solomon,dclk-div", &par->dclk_div))
> par->dclk_div = par->device_info->default_dclk_div;
> - if (of_property_read_u32(node, "solomon,dclk-frq", &par->dclk_frq))
> + if (device_property_read_u32(dev, "solomon,dclk-frq", &par->dclk_frq))
> par->dclk_frq = par->device_info->default_dclk_frq;
>
> vmem_size = DIV_ROUND_UP(par->width, 8) * par->height;
>
Re: [PATCH] video: vt8500lcdfb: fix fallthrough warning
On 4/12/20 10:21 PM, Sam Ravnborg wrote:
> Fix following warning:
> vt8500lcdfb.c: In function 'vt8500lcd_blank':
> vt8500lcdfb.c:229:6: warning: this statement may fall through
> [-Wimplicit-fallthrough=]
> if (info->fix.visual == FB_VISUAL_PSEUDOCOLOR ||
> ^
> vt8500lcdfb.c:233:2: note: here
> case FB_BLANK_UNBLANK:
> ^~~~
>
> Adding a simple "fallthrough;" fixed the warning.
> The fix was build tested.
>
> Signed-off-by: Sam Ravnborg
> Reported-by: kbuild test robot
> Fixes: e41f1a989408 ("fbdev: Implement simple blanking in pseudocolor modes
> for vt8500lcdfb")
> Cc: Alexey Charkov
> Cc: Paul Mundt
> Cc: Bartlomiej Zolnierkiewicz
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-fb...@vger.kernel.org
> Cc: # v2.6.38+
Patch queued for v5.8, thanks.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
> ---
> drivers/video/fbdev/vt8500lcdfb.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/video/fbdev/vt8500lcdfb.c
> b/drivers/video/fbdev/vt8500lcdfb.c
> index f744479dc7df..c61476247ba8 100644
> --- a/drivers/video/fbdev/vt8500lcdfb.c
> +++ b/drivers/video/fbdev/vt8500lcdfb.c
> @@ -230,6 +230,7 @@ static int vt8500lcd_blank(int blank, struct fb_info
> *info)
> info->fix.visual == FB_VISUAL_STATIC_PSEUDOCOLOR)
> for (i = 0; i < 256; i++)
> vt8500lcd_setcolreg(i, 0, 0, 0, 0, info);
> + fallthrough;
> case FB_BLANK_UNBLANK:
> if (info->fix.visual == FB_VISUAL_PSEUDOCOLOR ||
> info->fix.visual == FB_VISUAL_STATIC_PSEUDOCOLOR)
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] video: fbdev: aty128fb: remove unused 'sdr_64'
On 4/17/20 11:23 AM, Jason Yan wrote:
> Fix the following gcc warning:
>
> drivers/video/fbdev/aty/aty128fb.c:337:36: warning: ‘sdr_64’ defined but
> not used [-Wunused-const-variable=]
> static const struct aty128_meminfo sdr_64 = {
> ^~
>
> Reported-by: Hulk Robot
> Signed-off-by: Jason Yan
Patch queued for v5.8, thanks.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
> ---
> drivers/video/fbdev/aty/aty128fb.c | 14 --
> 1 file changed, 14 deletions(-)
>
> diff --git a/drivers/video/fbdev/aty/aty128fb.c
> b/drivers/video/fbdev/aty/aty128fb.c
> index d7e41c8dd533..d05d4195acad 100644
> --- a/drivers/video/fbdev/aty/aty128fb.c
> +++ b/drivers/video/fbdev/aty/aty128fb.c
> @@ -334,20 +334,6 @@ static const struct aty128_meminfo sdr_128 = {
> .name = "128-bit SDR SGRAM (1:1)",
> };
>
> -static const struct aty128_meminfo sdr_64 = {
> - .ML = 4,
> - .MB = 8,
> - .Trcd = 3,
> - .Trp = 3,
> - .Twr = 1,
> - .CL = 3,
> - .Tr2w = 1,
> - .LoopLatency = 17,
> - .DspOn = 46,
> - .Rloop = 17,
> - .name = "64-bit SDR SGRAM (1:1)",
> -};
> -
> static const struct aty128_meminfo sdr_sgram = {
> .ML = 4,
> .MB = 4,
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3] fbdev: s1d13xxxfb: add missed unregister_framebuffer in remove
On 3/24/20 2:23 PM, Chuhong Yuan wrote:
> The driver calls register_framebuffer() in probe but does not call
> unregister_framebuffer() in remove.
> Rename current remove to __s1d13xxxfb_remove() for error handler.
> Then add a new remove to call unregister_framebuffer().
>
> Signed-off-by: Chuhong Yuan
Patch queued for v5.8 (w/ extra newline removed), thanks.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
> ---
> Changes in v3:
> - Fix code style.
> - Set __s1d13xxxfb_remove() to return void.
> - Remove redundant check for info.
>
> drivers/video/fbdev/s1d13xxxfb.c | 15 +++
> 1 file changed, 11 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/video/fbdev/s1d13xxxfb.c
> b/drivers/video/fbdev/s1d13xxxfb.c
> index 8048499e398d..d51ef7619115 100644
> --- a/drivers/video/fbdev/s1d13xxxfb.c
> +++ b/drivers/video/fbdev/s1d13xxxfb.c
> @@ -721,9 +721,7 @@ static void s1d13xxxfb_fetch_hw_state(struct fb_info
> *info)
> xres, yres, xres_virtual, yres_virtual, is_color, is_dual,
> is_tft);
> }
>
> -
> -static int
> -s1d13xxxfb_remove(struct platform_device *pdev)
> +static void __s1d13xxxfb_remove(struct platform_device *pdev)
> {
> struct fb_info *info = platform_get_drvdata(pdev);
> struct s1d13xxxfb_par *par = NULL;
> @@ -749,9 +747,18 @@ s1d13xxxfb_remove(struct platform_device *pdev)
> pdev->resource[0].end - pdev->resource[0].start +1);
> release_mem_region(pdev->resource[1].start,
> pdev->resource[1].end - pdev->resource[1].start +1);
> +}
> +
> +static int s1d13xxxfb_remove(struct platform_device *pdev)
> +{
> + struct fb_info *info = platform_get_drvdata(pdev);
> +
> + unregister_framebuffer(info);
> + __s1d13xxxfb_remove(pdev);
> return 0;
> }
>
> +
> static int s1d13xxxfb_probe(struct platform_device *pdev)
> {
> struct s1d13xxxfb_par *default_par;
> @@ -895,7 +902,7 @@ static int s1d13xxxfb_probe(struct platform_device *pdev)
> return 0;
>
> bail:
> - s1d13xxxfb_remove(pdev);
> + __s1d13xxxfb_remove(pdev);
> return ret;
>
> }
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 RESEND] ARM/fbdev: sa11x0: Switch to use GPIO descriptors
[ added dri-devel ML to Cc: ]
On 4/15/20 6:50 PM, Linus Walleij wrote:
> This converts the SA11x0 frame buffer driver to use
> GPIO descriptors. Get the GPIO optional and register
> a look-up table specifically for the Shannon machine.
>
> Cc: Russell King
> Cc: Bartlomiej Zolnierkiewicz
> Signed-off-by: Linus Walleij
Patch queued for v5.8, thanks.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
> ---
> ChangeLog v1->v2:
> - Rename the GPIO line to "shannon-lcden" as this GPIO
> line has semantics that are particular to the Shannon
> platform.
> ---
> arch/arm/mach-sa1100/shannon.c | 9 +
> drivers/video/fbdev/sa1100fb.c | 20 +---
> drivers/video/fbdev/sa1100fb.h | 3 +++
> 3 files changed, 21 insertions(+), 11 deletions(-)
>
> diff --git a/arch/arm/mach-sa1100/shannon.c b/arch/arm/mach-sa1100/shannon.c
> index 5bc82e2671c6..351f891b4842 100644
> --- a/arch/arm/mach-sa1100/shannon.c
> +++ b/arch/arm/mach-sa1100/shannon.c
> @@ -104,6 +104,14 @@ static struct fixed_voltage_config shannon_cf_vcc_pdata
> __initdata = {
> .enabled_at_boot = 1,
> };
>
> +static struct gpiod_lookup_table shannon_display_gpio_table = {
> + .dev_id = "sa11x0-fb",
> + .table = {
> + GPIO_LOOKUP("gpio", 22, "shannon-lcden", GPIO_ACTIVE_HIGH),
> + { },
> + },
> +};
> +
> static void __init shannon_init(void)
> {
> sa11x0_register_fixed_regulator(0, &shannon_cf_vcc_pdata,
> @@ -113,6 +121,7 @@ static void __init shannon_init(void)
> sa11x0_register_pcmcia(0, &shannon_pcmcia0_gpio_table);
> sa11x0_register_pcmcia(1, &shannon_pcmcia1_gpio_table);
> sa11x0_ppc_configure_mcp();
> + gpiod_add_lookup_table(&shannon_display_gpio_table);
> sa11x0_register_lcd(&shannon_lcd_info);
> sa11x0_register_mtd(&shannon_flash_data, &shannon_flash_resource, 1);
> sa11x0_register_mcp(&shannon_mcp_data);
> diff --git a/drivers/video/fbdev/sa1100fb.c b/drivers/video/fbdev/sa1100fb.c
> index 2d285cc384cf..3e6e13f7a831 100644
> --- a/drivers/video/fbdev/sa1100fb.c
> +++ b/drivers/video/fbdev/sa1100fb.c
> @@ -173,7 +173,7 @@
> #include
> #include
> #include
> -#include
> +#include
> #include
> #include
> #include
> @@ -799,8 +799,8 @@ static void sa1100fb_enable_controller(struct
> sa1100fb_info *fbi)
> writel_relaxed(fbi->dbar2, fbi->base + DBAR2);
> writel_relaxed(fbi->reg_lccr0 | LCCR0_LEN, fbi->base + LCCR0);
>
> - if (machine_is_shannon())
> - gpio_set_value(SHANNON_GPIO_DISP_EN, 1);
> + if (fbi->shannon_lcden)
> + gpiod_set_value(fbi->shannon_lcden, 1);
>
> dev_dbg(fbi->dev, "DBAR1: 0x%08x\n", readl_relaxed(fbi->base + DBAR1));
> dev_dbg(fbi->dev, "DBAR2: 0x%08x\n", readl_relaxed(fbi->base + DBAR2));
> @@ -817,8 +817,8 @@ static void sa1100fb_disable_controller(struct
> sa1100fb_info *fbi)
>
> dev_dbg(fbi->dev, "Disabling LCD controller\n");
>
> - if (machine_is_shannon())
> - gpio_set_value(SHANNON_GPIO_DISP_EN, 0);
> + if (fbi->shannon_lcden)
> + gpiod_set_value(fbi->shannon_lcden, 0);
>
> set_current_state(TASK_UNINTERRUPTIBLE);
> add_wait_queue(&fbi->ctrlr_wait, &wait);
> @@ -1173,12 +1173,10 @@ static int sa1100fb_probe(struct platform_device
> *pdev)
> return ret;
> }
>
> - if (machine_is_shannon()) {
> - ret = devm_gpio_request_one(&pdev->dev, SHANNON_GPIO_DISP_EN,
> - GPIOF_OUT_INIT_LOW, "display enable");
> - if (ret)
> - return ret;
> - }
> + fbi->shannon_lcden = gpiod_get_optional(&pdev->dev, "shannon-lcden",
> + GPIOD_OUT_LOW);
> + if (IS_ERR(fbi->shannon_lcden))
> + return PTR_ERR(fbi->shannon_lcden);
>
> /* Initialize video memory */
> ret = sa1100fb_map_video_memory(fbi);
> diff --git a/drivers/video/fbdev/sa1100fb.h b/drivers/video/fbdev/sa1100fb.h
> index d0aa33b0b88a..b4363444fa5d 100644
> --- a/drivers/video/fbdev/sa1100fb.h
> +++ b/drivers/video/fbdev/sa1100fb.h
> @@ -10,6 +10,8 @@
> * for more details.
> */
>
> +struct gpio_desc;
> +
> #define LCCR0 0x /* LCD Control Reg. 0 */
> #define LCSR0x0004 /* LCD Status Reg. */
> #define DBAR1 0x0010 /* LCD DMA Base Address Reg. channel
> 1 */
> @@ -33,6 +35,7 @@ struct sa1100fb_info {
> struct device *dev;
> const struct sa1100fb_rgb *rgb[NR_RGB];
> void __iomem*base;
> + struct gpio_desc*shannon_lcden;
>
> /*
>* These are the addresses we mapped
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4] video: fbdev: vesafb: add missed release_region
On 3/29/20 4:58 PM, Chuhong Yuan wrote:
> The driver forgets to free the I/O region in remove and probe
> failure.
> Add the missed calls to fix it.
>
> Since the success of request_region() is optional, add the "region" field
> in vesafb_par to represent whether request_region() succeeds.
> Then only call release_region() when "region" is not null.
>
> Signed-off-by: Chuhong Yuan
Patch queued for v5.8, thanks.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
> ---
> Changes in v4:
> - Add a field in vesafb_par to represent whether request_region() succeeds.
> - Only call release_region() when request_region() succeeds.
> - Adjust the order in the error handler of probe.
> - Modify commit message.
>
> drivers/video/fbdev/vesafb.c | 16 +++-
> 1 file changed, 11 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/video/fbdev/vesafb.c b/drivers/video/fbdev/vesafb.c
> index a1fe24ea869b..df6de5a9dd4c 100644
> --- a/drivers/video/fbdev/vesafb.c
> +++ b/drivers/video/fbdev/vesafb.c
> @@ -32,6 +32,7 @@
> struct vesafb_par {
> u32 pseudo_palette[256];
> int wc_cookie;
> + struct resource *region;
> };
>
> static struct fb_var_screeninfo vesafb_defined = {
> @@ -411,7 +412,7 @@ static int vesafb_probe(struct platform_device *dev)
>
> /* request failure does not faze us, as vgacon probably has this
>* region already (FIXME) */
> - request_region(0x3c0, 32, "vesafb");
> + par->region = request_region(0x3c0, 32, "vesafb");
>
> if (mtrr == 3) {
> unsigned int temp_size = size_total;
> @@ -439,7 +440,7 @@ static int vesafb_probe(struct platform_device *dev)
> "vesafb: abort, cannot ioremap video memory 0x%x @
> 0x%lx\n",
> vesafb_fix.smem_len, vesafb_fix.smem_start);
> err = -EIO;
> - goto err;
> + goto err_release_region;
> }
>
> printk(KERN_INFO "vesafb: framebuffer at 0x%lx, mapped to 0x%p, "
> @@ -458,19 +459,22 @@ static int vesafb_probe(struct platform_device *dev)
>
> if (fb_alloc_cmap(&info->cmap, 256, 0) < 0) {
> err = -ENOMEM;
> - goto err;
> + goto err_release_region;
> }
> if (register_framebuffer(info)<0) {
> err = -EINVAL;
> fb_dealloc_cmap(&info->cmap);
> - goto err;
> + goto err_release_region;
> }
> fb_info(info, "%s frame buffer device\n", info->fix.id);
> return 0;
> -err:
> +err_release_region:
> arch_phys_wc_del(par->wc_cookie);
> if (info->screen_base)
> iounmap(info->screen_base);
> + if (par->region)
> + release_region(0x3c0, 32);
> +err:
> framebuffer_release(info);
> release_mem_region(vesafb_fix.smem_start, size_total);
> return err;
> @@ -481,6 +485,8 @@ static int vesafb_remove(struct platform_device *pdev)
> struct fb_info *info = platform_get_drvdata(pdev);
>
> unregister_framebuffer(info);
> + if (((struct vesafb_par *)(info->par))->region)
> + release_region(0x3c0, 32);
> framebuffer_release(info);
>
> return 0;
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4] video: fbdev: arcfb: add missed free_irq and fix the order of request_irq
On 3/24/20 2:23 PM, Chuhong Yuan wrote:
> The driver forgets to free irq in remove which is requested in
> probe.
> Add the missed call to fix it.
> Also, the position of request_irq() in probe should be put before
> register_framebuffer().
>
> Signed-off-by: Chuhong Yuan
Patch queued for v5.8, thanks.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
> ---
> Changes in v4:
> - Use info->par->irq instead of par->irq to avoid dereferencing NULL
> pointer.
>
> drivers/video/fbdev/arcfb.c | 10 ++
> 1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/video/fbdev/arcfb.c b/drivers/video/fbdev/arcfb.c
> index 314ab82e01c0..6f7838979f0a 100644
> --- a/drivers/video/fbdev/arcfb.c
> +++ b/drivers/video/fbdev/arcfb.c
> @@ -544,10 +544,6 @@ static int arcfb_probe(struct platform_device *dev)
> par->cslut[1] = 0x06;
> info->flags = FBINFO_FLAG_DEFAULT;
> spin_lock_init(&par->lock);
> - retval = register_framebuffer(info);
> - if (retval < 0)
> - goto err1;
> - platform_set_drvdata(dev, info);
> if (irq) {
> par->irq = irq;
> if (request_irq(par->irq, &arcfb_interrupt, IRQF_SHARED,
> @@ -558,6 +554,10 @@ static int arcfb_probe(struct platform_device *dev)
> goto err1;
> }
> }
> + retval = register_framebuffer(info);
> + if (retval < 0)
> + goto err1;
> + platform_set_drvdata(dev, info);
> fb_info(info, "Arc frame buffer device, using %dK of video memory\n",
> videomemorysize >> 10);
>
> @@ -593,6 +593,8 @@ static int arcfb_remove(struct platform_device *dev)
>
> if (info) {
> unregister_framebuffer(info);
> + if (irq)
> + free_irq(((struct arcfb_par *)(info->par))->irq, info);
> vfree((void __force *)info->screen_base);
> framebuffer_release(info);
> }
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: RFC: Drm-connector properties managed by another driver / privacy screen support
On Fri, Apr 17, 2020 at 11:02 AM Pekka Paalanen wrote: > > On Wed, 15 Apr 2020 17:40:46 +0200 > Hans de Goede wrote: > > > Hi, > > > > On 4/15/20 5:28 PM, Jani Nikula wrote: > > > On Wed, 15 Apr 2020, Hans de Goede wrote: > > >> ii. Currently the "privacy-screen" property added by Rajat's > > >> patch-set is an enum with 2 possible values: > > >> "Enabled" > > >> "Disabled" > > >> > > >> We could add a third value "Not Available", which would be the > > >> default and then for internal panels always add the property > > >> so that we avoid the problem that detecting if the laptop has > > >> an internal privacy screen needs to be done before the connector > > >> is registered. Then we can add some hooks which allow an > > >> lcdshadow-driver to register itself against a connector later > > >> (which is non trivial wrt probe order, but lets ignore that for now). > > > > > > I regret dropping the ball on Rajat's series (sorry!). > > > > > > I do think having the connector property for this is the way to go. > > > > I 100% agree. > > > > > Even > > > if we couldn't necessarily figure out all the details on the kernel > > > internal connections, can we settle on the property though, so we could > > > move forward with Rajat's series? > > > > Yes please, this will also allow us to move forward with userspace > > support even if for testing that we do some hacks for the kernel's > > internal connections for now. > > > > > Moreover, do we actually need two properties, one which could indicate > > > userspace's desire for the property, and another that tells the hardware > > > state? > > > > No I do not think so. I would expect there to just be one property, > > I guess that if the state is (partly) firmware controlled then there > > might be a race, but we will need a notification mechanism (*) for > > firmware triggered state changes anyways, so shortly after loosing > > the race userspace will process the notification and it will know > > about it. > > > > One thing which might be useful is a way to signal that the property > > is read-only in case we ever hit hw where that is the case. > > > > > I'd so very much like to have no in-kernel/in-firmware shortcuts > > > to enable/disable the privacy screen, and instead have any hardware > > > buttons just be events that the userspace could react to. However I > > > don't think that'll be the case unfortunately. > > > > In my experience with keyboard-backlight support, we will (unfortunately) > > see a mix and in some case we will get a notification that the firmware > > has adjusted the state, rather then just getting a keypress and > > dealing with that ourselves. In some cases we may even be able to > > choose, so the fw will deal with it by default but we can ask it > > to just send a key-press. But I do believe that we can *not* expect > > that we will always just get a keypress for userspace to deal with. > > Hi, > > let's think about how userspace uses atomic KMS UAPI. The simplest way > to use atomic correctly is that userspace will for every update send the > full, complete set of all properties that exist, both known and unknown > to userspace (to recover from temporarily VT-switching to another KMS > program that changes unknown properties). Attempting to track which > properties already have their correct values in the kernel is extra > work for just extra bugs. Uh if you do that you'll get random surprising failures if you don't also set ALLOW_MODESET, because that way you'll automatically repair link failures and stuff like that. I'm assuming your userspace only supplies all the properties for crtc and planes, and leaves connectors as-is? Otherwise you already have some fun bugs. In general I'd say userspace shouldn't write stuff it doesn't understand. If you limit yourself to just the properties you do want to (re)set, that's safe. But if you just blindly write everything all the time, random modesets, and hence random failures if you don't set ALLOW_MODESET. > Assuming the property is userspace-writable: if kernel goes and > changes the property value on its own, it will very likely be just > overwritten by userspace right after if userspace does not manage to > process the uevent first. If that happens and userspace later > processes the uevent, userspace queries the kernel for the current > proprerty state which is now what userspace wrote, not what firmware > set. > > Therefore you end up with the firmware hotkey working only randomly. > > It would be much better to have the hotkey events delivered to > userspace so that userspace can control the privacy screen and > everything will be reliable, both the hotkeys and any GUI for it. The > other reliable option is that userspace must never be able to change > privacy screen state, only the hardware hotkeys can. We have fancy new uevents which give you both the connector and the property, so you know what's going on. Also, a property which userspace and the kernel can race like you describe
Re: RFC: Drm-connector properties managed by another driver / privacy screen support
On Fri, Apr 17, 2020 at 1:55 PM Jani Nikula wrote: > > On Fri, 17 Apr 2020, Pekka Paalanen wrote: > > On Wed, 15 Apr 2020 17:40:46 +0200 > > Hans de Goede wrote: > > > >> Hi, > >> > >> On 4/15/20 5:28 PM, Jani Nikula wrote: > >> > On Wed, 15 Apr 2020, Hans de Goede wrote: > >> >> ii. Currently the "privacy-screen" property added by Rajat's > >> >> patch-set is an enum with 2 possible values: > >> >> "Enabled" > >> >> "Disabled" > >> >> > >> >> We could add a third value "Not Available", which would be the > >> >> default and then for internal panels always add the property > >> >> so that we avoid the problem that detecting if the laptop has > >> >> an internal privacy screen needs to be done before the connector > >> >> is registered. Then we can add some hooks which allow an > >> >> lcdshadow-driver to register itself against a connector later > >> >> (which is non trivial wrt probe order, but lets ignore that for now). > >> > > >> > I regret dropping the ball on Rajat's series (sorry!). > >> > > >> > I do think having the connector property for this is the way to go. > >> > >> I 100% agree. > >> > >> > Even > >> > if we couldn't necessarily figure out all the details on the kernel > >> > internal connections, can we settle on the property though, so we could > >> > move forward with Rajat's series? > >> > >> Yes please, this will also allow us to move forward with userspace > >> support even if for testing that we do some hacks for the kernel's > >> internal connections for now. > >> > >> > Moreover, do we actually need two properties, one which could indicate > >> > userspace's desire for the property, and another that tells the hardware > >> > state? > >> > >> No I do not think so. I would expect there to just be one property, > >> I guess that if the state is (partly) firmware controlled then there > >> might be a race, but we will need a notification mechanism (*) for > >> firmware triggered state changes anyways, so shortly after loosing > >> the race userspace will process the notification and it will know > >> about it. > >> > >> One thing which might be useful is a way to signal that the property > >> is read-only in case we ever hit hw where that is the case. > >> > >> > I'd so very much like to have no in-kernel/in-firmware shortcuts > >> > to enable/disable the privacy screen, and instead have any hardware > >> > buttons just be events that the userspace could react to. However I > >> > don't think that'll be the case unfortunately. > >> > >> In my experience with keyboard-backlight support, we will (unfortunately) > >> see a mix and in some case we will get a notification that the firmware > >> has adjusted the state, rather then just getting a keypress and > >> dealing with that ourselves. In some cases we may even be able to > >> choose, so the fw will deal with it by default but we can ask it > >> to just send a key-press. But I do believe that we can *not* expect > >> that we will always just get a keypress for userspace to deal with. > > > > Hi, > > > > let's think about how userspace uses atomic KMS UAPI. The simplest way > > to use atomic correctly is that userspace will for every update send the > > full, complete set of all properties that exist, both known and unknown > > to userspace (to recover from temporarily VT-switching to another KMS > > program that changes unknown properties). Attempting to track which > > properties already have their correct values in the kernel is extra > > work for just extra bugs. > > > > Assuming the property is userspace-writable: if kernel goes and > > changes the property value on its own, it will very likely be just > > overwritten by userspace right after if userspace does not manage to > > process the uevent first. If that happens and userspace later > > processes the uevent, userspace queries the kernel for the current > > proprerty state which is now what userspace wrote, not what firmware > > set. > > > > Therefore you end up with the firmware hotkey working only randomly. > > > > It would be much better to have the hotkey events delivered to > > userspace so that userspace can control the privacy screen and > > everything will be reliable, both the hotkeys and any GUI for it. > > I'd like this too. However I fear this is out of our control, and OEMs > have and will anyway fiddle with the privacy screen directly no matter > what we say, and we can't prevent that. From their POV it's easier for > them to do their value-add in components they have total control over. I > emphatize with that view, even if it's counter-productive from the Linux > ecosystem POV. > > So we'll just have to deal with it. > > > The other reliable option is that userspace must never be able to > > change privacy screen state, only the hardware hotkeys can. > > That, in turn, discourages anyone from doing the right thing, and blocks > us from adding any nice additional features for privacy screens that > only the userspace is capable of managing. For example, con
Re: RFC: Drm-connector properties managed by another driver / privacy screen support
On Fri, 2020-04-17 at 16:18 +0200, Daniel Vetter wrote: > > I suppose rf-kill is a bit similar. RfKill is actually much more complicated, and I don't really see how it is related. We may be in the situation where we cannot control the hardware state, but RfKill has two entirely separate "block" states and the real value is the logical OR of both. Also, RfKill key handling is a mess as userspace needs to tell the kernel it is handling the keys. > > You'd have a userspace controlled property to state what the userspace > > wants, and a kernel controlled property to show the hardware > > state. Userspace can ask for one or the other, and usually this happens, > > but the hardware hotkey bypasses the whole thing. > > > > It's not perfect. But I think just one property changed nilly-willy by > > both the kernel and userspace (especially when it's really not in the > > kernel's full control either) is going to be a PITA. > > Yeah that's what we've done in other cases where both kernel and > userspace can change stuff. These where just tri-states, but this here > sounds like we need all for, so best to just have 2 properties. As I see it, the requirements here are: * Userspace needs to be able to query the current state (possibly unavailable?) * Userspace needs to know whether it can set the property * Userspace needs to be notified about changes (by the firmware or possibly any other reason) But, should never get into the situation that both the firmware and software are trying to toggle the state in response to the same event. In the case of the Fn-key, we'll either deliver a key-press to userspace or just update the attribute because the firmware has already handled it. Only one of these two possibilities may happen. Benjamin signature.asc Description: This is a digitally signed message part ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/5] drm/modes: Indicate CEA-861 CE modes to user-space
On Thu, Apr 16, 2020 at 03:51:36PM +0200, Yussuf Khalil wrote:
> On Tue, 2020-04-14 at 14:41 +0200, Daniel Vetter wrote:
> > On Mon, Apr 13, 2020 at 11:40:22PM +0200, Yussuf Khalil wrote:
> > > Add a new flag to mark modes that are considered a CE mode
> > > according to the
> > > CEA-861 specification. Modes without this flag are implicitly
> > > considered to
> > > be IT modes.
> > >
> > > User-space applications may use this flag to determine possible
> > > implications of using a CE mode (e.g., limited RGB range).
> > >
> > > There is no use for this flag inside the kernel, so we set it only
> > > when
> > > communicating a mode to user-space.
> > >
> > > Signed-off-by: Yussuf Khalil
> >
> > Do we have userspace for this?
> >
> > If we go with the existing quant range property you don't need new
> > userspace for the property itself. But this flag here is new uapi, so
> > needs userspace per
> >
> > https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#open-source-userspace-requirements
> >
> > Also since this standardizes kms uapi, we need testcases per
> >
> > https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#testing-requirements-for-userspace-api
> >
> > Cheers, Daniel
> >
> > > ---
> > > drivers/gpu/drm/drm_modes.c | 14 ++
> > > include/uapi/drm/drm_mode.h | 2 ++
> > > 2 files changed, 16 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/drm_modes.c
> > > b/drivers/gpu/drm/drm_modes.c
> > > index d4d64518e11b..0d8a032f437d 100644
> > > --- a/drivers/gpu/drm/drm_modes.c
> > > +++ b/drivers/gpu/drm/drm_modes.c
> > > @@ -1973,6 +1973,14 @@ void drm_mode_convert_to_umode(struct
> > > drm_mode_modeinfo *out,
> > > break;
> > > }
> > >
> > > + if (drm_match_cea_mode(in) > 1) {
> > > + /*
> > > + * All modes in CTA-861-G Table 1 are CE modes, except
> > > 640x480p
> > > + * (VIC 1).
> > > + */
> > > + out->flags |= DRM_MODE_FLAG_CEA_861_CE_MODE;
> > > + }
> > > +
> > > strncpy(out->name, in->name, DRM_DISPLAY_MODE_LEN);
> > > out->name[DRM_DISPLAY_MODE_LEN-1] = 0;
> > > }
> > > @@ -2045,6 +2053,12 @@ int drm_mode_convert_umode(struct drm_device
> > > *dev,
> > > return -EINVAL;
> > > }
> > >
> > > + /*
> > > + * The CEA-861 CE mode flag is purely informational and
> > > intended for
> > > + * userspace only.
> > > + */
> > > + out->flags &= ~DRM_MODE_FLAG_CEA_861_CE_MODE;
> > > +
> > > out->status = drm_mode_validate_driver(dev, out);
> > > if (out->status != MODE_OK)
> > > return -EINVAL;
> > > diff --git a/include/uapi/drm/drm_mode.h
> > > b/include/uapi/drm/drm_mode.h
> > > index 735c8cfdaaa1..5e78b350b2e2 100644
> > > --- a/include/uapi/drm/drm_mode.h
> > > +++ b/include/uapi/drm/drm_mode.h
> > > @@ -124,6 +124,8 @@ extern "C" {
> > > #define DRM_MODE_FLAG_PIC_AR_256_135 \
> > > (DRM_MODE_PICTURE_ASPECT_256_135<<19)
> > >
> > > +#define DRM_MODE_FLAG_CEA_861_CE_MODE (1<<23)
> > > +
> > > #define DRM_MODE_FLAG_ALL (DRM_MODE_FLAG_PHSYNC | \
> > >DRM_MODE_FLAG_NHSYNC | \
> > >DRM_MODE_FLAG_PVSYNC | \
> > > --
> > > 2.26.0
> > >
>
> Sorry, I wasn't aware DRM had these additional requirements. I do have a user-
> space implementation in mutter and gnome-control-center that makes use of the
> new property and this flag on my local machine. I'll try to propose the branch
> upstream before sending in the next revision of this patchset.
>
> Do I understand it correctly that this will require test cases for both the
> property itself and the new flag? I'll write a patch for IGT then.
Yup. We even have some edid injection stuff so you can (for some value of
"can") test this on systems without such a monitor. That would obviously
be the gold standard for this, so that CI systems can make sure we don't
break any of this in the driver side.
-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 5/5] drm/i915: Replace "Broadcast RGB" with "RGB quantization range" property
On Thu, Apr 16, 2020 at 03:44:53PM +0200, Yussuf Khalil wrote: > On Wed, 2020-04-15 at 13:13 +0200, Daniel Vetter wrote: > > On Wed, Apr 15, 2020 at 10:33:25AM +0300, Jani Nikula wrote: > > > On Tue, 14 Apr 2020, Yussuf Khalil wrote: > > > > On Tue, 2020-04-14 at 14:34 +0200, Daniel Vetter wrote: > > > > > On Tue, Apr 14, 2020 at 02:21:06PM +0300, Jani Nikula wrote: > > > > > > On Tue, 14 Apr 2020, Jani Nikula > > > > > > > > > > > > wrote: > > > > > > > On Mon, 13 Apr 2020, Simon Ser wrote: > > > > > > > > On Monday, April 13, 2020 11:40 PM, Yussuf Khalil < > > > > > > > > d...@pp3345.net> wrote: > > > > > > > > > > > > > > > > > DRM now has a globally available "RGB quantization > > > > > > > > > range" > > > > > > > > > connector > > > > > > > > > property. i915's "Broadcast RGB" that fulfils the same > > > > > > > > > purpose is now > > > > > > > > > considered deprecated, so drop it in favor of the DRM > > > > > > > > > property. > > > > > > > > > > > > > > > > For a UAPI point-of-view, I'm not sure this is fine. Some > > > > > > > > user- > > > > > > > > space > > > > > > > > might depend on this property, dropping it would break > > > > > > > > such > > > > > > > > user-space. > > > > > > > > > > > > > > Agreed. > > > > > > > > > > > > > > > Can we make this property deprecated but still keep it > > > > > > > > for > > > > > > > > backwards > > > > > > > > compatibility? > > > > > > > > > > > > > > Would be nice to make the i915 specific property an "alias" > > > > > > > for > > > > > > > the new > > > > > > > property, however I'm not sure how you'd make that happen. > > > > > > > Otherwise > > > > > > > juggling between the two properties is going to be a > > > > > > > nightmare. > > > > > > > > > > > > Ah, the obvious easy choice is to use the property and enum > > > > > > names > > > > > > already being used by i915 and gma500, and you have no > > > > > > problem. > > > > > > Perhaps > > > > > > they're not the names you'd like, but then looking at the > > > > > > total > > > > > > lack of > > > > > > consistency across property naming makes them fit right in. > > > > > > ;) > > > > > > > > > > Yeah if we don't have contradictory usage across drivers when > > > > > modernizing > > > > > these properties, then let's just stick with the names already > > > > > there. > > > > > It's > > > > > not pretty, but works better since more userspace/internet > > > > > howtos > > > > > know how > > > > > to use this stuff. > > > > > -Daniel > > > > > > > > Note that i915's "Broadcast RGB" isn't the same as gma500's: i915 > > > > has an > > > > "Automatic" option, whereas gma500 does not. > > > > > > Adding "Automatic" option that just defaults to "Full" in gma500 > > > does > > > not break existing userspace, but allows for extending it to do > > > more > > > clever things later. > > > > gma500 could keep it's own property, without the "Automatic" value. > > We've > > done tricks like this for other properties too. > > > > > > Also, radeon has a property called > > > > "output_csc" that fulfills a similar purpose. Looking at the > > > > code, though, it > > > > seems that radeon does not adhere to the standard correctly (or I > > > > am missing > > > > something). > > > > > > > > An alternative would be to leave the existing driver-specific > > > > properties and > > > > change them to be pseudo-aliases for the "RGB quantization range" > > > > property. > > > > This can be done by letting the drivers read from and write to > > > > the new property > > > > when user-space tries to read or modify the driver's property. > > > > This way we could > > > > retain full backwards compatibility for all drivers equally. > > > > > > > > What do you think? > > > > > > I'm obviously biased and predisposed to avoid adding extra > > > complexity to > > > i915 when it's not necessary. We'd have *two* connector properties > > > for > > > the same thing until the end of time, even if one is an alias for > > > the > > > other. > > > > Yeah just pick one, and implement the others as aliases. Drivers can > > do > > the aliases in their atomic_get/set_property functions pretty easily, > > atomic properties aren't stored anywhere else than decoded (which was > > done > > partially to make stuff like this work). > > > > Coming up a new property name just so that everyone suffers equally > > feels > > silly. > > -Daniel > > Okay, I understand your point. Leaving gma500 without a proper implementation > of > the "Automatic" value isn't an option though as that would break the whole > purpose of this patchset: having a property that works precisely the same way > across all drivers. I'll build a patch that implements standards-compliant > behavior for gma500 then, so that it can use the same property as the others. Sounds best. I just generally refrain from volunteering people for work on very old and abandoned drivers. But if you're willing to type the code, I'm happy to take it. -Daniel -- Daniel Vetter Softw
Re: [PATCH] staging: android: ion: Skip sync if not mapped
On Thu, Apr 16, 2020 at 12:25:08PM +0200, Greg Kroah-Hartman wrote:
> On Tue, Apr 14, 2020 at 09:41:31PM -0700, John Stultz wrote:
> > On Tue, Apr 14, 2020 at 7:28 AM Greg Kroah-Hartman
> > wrote:
> > >
> > > On Tue, Apr 14, 2020 at 04:18:47PM +0200, Ørjan Eide wrote:
> > > > Only sync the sg-list of an Ion dma-buf attachment when the attachment
> > > > is actually mapped on the device.
> > > >
> > > > dma-bufs may be synced at any time. It can be reached from user space
> > > > via DMA_BUF_IOCTL_SYNC, so there are no guarantees from callers on when
> > > > syncs may be attempted, and dma_buf_end_cpu_access() and
> > > > dma_buf_begin_cpu_access() may not be paired.
> > > >
> > > > Since the sg_list's dma_address isn't set up until the buffer is used
> > > > on the device, and dma_map_sg() is called on it, the dma_address will be
> > > > NULL if sync is attempted on the dma-buf before it's mapped on a device.
> > > >
> > > > Before v5.0 (commit 55897af63091 ("dma-direct: merge swiotlb_dma_ops
> > > > into the dma_direct code")) this was a problem as the dma-api (at least
> > > > the swiotlb_dma_ops on arm64) would use the potentially invalid
> > > > dma_address. How that failed depended on how the device handled physical
> > > > address 0. If 0 was a valid address to physical ram, that page would get
> > > > flushed a lot, while the actual pages in the buffer would not get synced
> > > > correctly. While if 0 is an invalid physical address it may cause a
> > > > fault and trigger a crash.
> > > >
> > > > In v5.0 this was incidentally fixed by commit 55897af63091 ("dma-direct:
> > > > merge swiotlb_dma_ops into the dma_direct code"), as this moved the
> > > > dma-api to use the page pointer in the sg_list, and (for Ion buffers at
> > > > least) this will always be valid if the sg_list exists at all.
> > > >
> > > > But, this issue is re-introduced in v5.3 with
> > > > commit 449fa54d6815 ("dma-direct: correct the physical addr in
> > > > dma_direct_sync_sg_for_cpu/device") moves the dma-api back to the old
> > > > behaviour and picks the dma_address that may be invalid.
> > > >
> > > > dma-buf core doesn't ensure that the buffer is mapped on the device, and
> > > > thus have a valid sg_list, before calling the exporter's
> > > > begin_cpu_access.
> > > >
> > > > Signed-off-by: Ørjan Eide
> > > > ---
> > > > drivers/staging/android/ion/ion.c | 12
> > > > 1 file changed, 12 insertions(+)
> > > >
> > > > Resubmit without disclaimer, sorry about that.
> > > >
> > > > This seems to be part of a bigger issue where dma-buf exporters assume
> > > > that their dma-buf begin_cpu_access and end_cpu_access callbacks have a
> > > > certain guaranteed behavior, which isn't ensured by dma-buf core.
> > > >
> > > > This patch fixes this in ion only, but it also needs to be fixed for
> > > > other exporters, either handled like this in each exporter, or in
> > > > dma-buf core before calling into the exporters.
> > > >
> > > > diff --git a/drivers/staging/android/ion/ion.c
> > > > b/drivers/staging/android/ion/ion.c
> > > > index 38b51eace4f9..7b752ba0cb6d 100644
> > > > --- a/drivers/staging/android/ion/ion.c
> > > > +++ b/drivers/staging/android/ion/ion.c
> > >
> > > Now that we have the dma-buff stuff in the tree, do we even need the
> > > ion code in the kernel anymore? Can't we delete it now?
> > >
> >
> > I agree that we shouldn't be taking further (non-security/cleanup)
> > patches to the ION code.
> >
> > I'd like to give developers a little bit of a transition period (I was
> > thinking a year, but really just one LTS release that has both would
> > do) where they can move their ION heaps over to dmabuf heaps and test
> > both against the same tree.
> >
> > But I do think we can mark it as deprecated and let folks know that
> > around the end of the year it will be deleted.
>
> No one ever notices "depreciated" things, they only notice if the code
> is no longer there :)
>
> So I'm all for just deleting it and seeing who even notices...
+1 on just deleting ion and watching if anyone notices. In case you're
typing that patch, here's my:
Acked-by: Daniel Vetter
-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 trivial 3/6] drm: Fix misspellings of "Analog Devices"
On Thu, Apr 16, 2020 at 12:30:55PM +0200, Geert Uytterhoeven wrote: > According to https://www.analog.com/, the company name is spelled > "Analog Devices". > > Signed-off-by: Geert Uytterhoeven Queued for 5.8 in drm-misc-next, thanks for your patch. -Daniel > --- > drivers/gpu/drm/bridge/adv7511/Kconfig | 2 +- > drivers/gpu/drm/drm_fb_cma_helper.c| 2 +- > drivers/gpu/drm/tegra/fb.c | 2 +- > 3 files changed, 3 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/bridge/adv7511/Kconfig > b/drivers/gpu/drm/bridge/adv7511/Kconfig > index 47d4eb9e845d085c..f46a5e26b5dd6406 100644 > --- a/drivers/gpu/drm/bridge/adv7511/Kconfig > +++ b/drivers/gpu/drm/bridge/adv7511/Kconfig > @@ -6,7 +6,7 @@ config DRM_I2C_ADV7511 > select REGMAP_I2C > select DRM_MIPI_DSI > help > - Support for the Analog Device ADV7511(W)/13/33/35 HDMI encoders. > + Support for the Analog Devices ADV7511(W)/13/33/35 HDMI encoders. > > config DRM_I2C_ADV7511_AUDIO > bool "ADV7511 HDMI Audio driver" > diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c > b/drivers/gpu/drm/drm_fb_cma_helper.c > index 9801c0333eca29e9..cb2349ad338d953b 100644 > --- a/drivers/gpu/drm/drm_fb_cma_helper.c > +++ b/drivers/gpu/drm/drm_fb_cma_helper.c > @@ -2,7 +2,7 @@ > /* > * drm kms/fb cma (contiguous memory allocator) helper functions > * > - * Copyright (C) 2012 Analog Device Inc. > + * Copyright (C) 2012 Analog Devices Inc. > * Author: Lars-Peter Clausen > * > * Based on udl_fbdev.c > diff --git a/drivers/gpu/drm/tegra/fb.c b/drivers/gpu/drm/tegra/fb.c > index b8a328f538626e7a..2b0666ac681b8721 100644 > --- a/drivers/gpu/drm/tegra/fb.c > +++ b/drivers/gpu/drm/tegra/fb.c > @@ -4,7 +4,7 @@ > * Copyright (C) 2012 NVIDIA CORPORATION. All rights reserved. > * > * Based on the KMS/FB CMA helpers > - * Copyright (C) 2012 Analog Device Inc. > + * Copyright (C) 2012 Analog Devices Inc. > */ > > #include > -- > 2.17.1 > -- 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
