Re: [PATCH] drm/ssd130x: Fix pre-charge period setting
On Thu, Jul 7, 2022 at 5:37 AM Javier Martinez Canillas wrote: > > Hello Ezequiel, > > Thanks a lot for your patch. > > On 7/6/22 20:41, Ezequiel Garcia wrote: > > Fix small typo which causes the mask for the 'precharge1' setting > > to be used with the 'precharge2' value. > > > > Signed-off-by: Ezequiel Garcia > > --- > > drivers/gpu/drm/solomon/ssd130x.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/solomon/ssd130x.c > > b/drivers/gpu/drm/solomon/ssd130x.c > > index 0839dd6e..f4886e66ff34 100644 > > --- a/drivers/gpu/drm/solomon/ssd130x.c > > +++ b/drivers/gpu/drm/solomon/ssd130x.c > > @@ -350,7 +350,7 @@ static int ssd130x_init(struct ssd130x_device *ssd130x) > > > > /* Set precharge period in number of ticks from the internal clock */ > > precharge = (SSD130X_SET_PRECHARGE_PERIOD1_SET(ssd130x->prechargep1) | > > - SSD130X_SET_PRECHARGE_PERIOD1_SET(ssd130x->prechargep2)); > > + SSD130X_SET_PRECHARGE_PERIOD2_SET(ssd130x->prechargep2)); > > It's a typo indeed. Nice catch! > > I wonder how did you notice this. Or was it just looking at the code ? > Indeed, I was just reviewing the code while getting a SH1106 display to work. > Acked-by: Javier Martinez Canillas > > I'll push it to drm-misc (drm-misc-fixes). > Thanks! Ezequiel > -- > Best regards, > > Javier Martinez Canillas > Linux Engineering > Red Hat >
[PATCH] drm/ssd130x: Fix pre-charge period setting
Fix small typo which causes the mask for the 'precharge1' setting to be used with the 'precharge2' value. Signed-off-by: Ezequiel Garcia --- drivers/gpu/drm/solomon/ssd130x.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/solomon/ssd130x.c b/drivers/gpu/drm/solomon/ssd130x.c index 0839dd6e..f4886e66ff34 100644 --- a/drivers/gpu/drm/solomon/ssd130x.c +++ b/drivers/gpu/drm/solomon/ssd130x.c @@ -350,7 +350,7 @@ static int ssd130x_init(struct ssd130x_device *ssd130x) /* Set precharge period in number of ticks from the internal clock */ precharge = (SSD130X_SET_PRECHARGE_PERIOD1_SET(ssd130x->prechargep1) | -SSD130X_SET_PRECHARGE_PERIOD1_SET(ssd130x->prechargep2)); +SSD130X_SET_PRECHARGE_PERIOD2_SET(ssd130x->prechargep2)); ret = ssd130x_write_cmd(ssd130x, 2, SSD130X_SET_PRECHARGE_PERIOD, precharge); if (ret < 0) return ret; -- 2.34.3
Re: [PATCH v10, 00/19] Support multi hardware decode using of_platform_populate
Hi Yunfei,
On Tue, 16 Nov 2021 at 08:42, yunfei.d...@mediatek.com
wrote:
>
> Hi Ezequiel,
>
> Thanks for you suggestion.
> On Sun, 2021-11-14 at 19:04 -0300, Ezequiel Garcia wrote:
> > Hi Yunfei,
> >
> > On Thu, 11 Nov 2021 at 01:15, Yunfei Dong
> > wrote:
> > >
> > > This series adds support for multi hardware decode into mtk-vcodec,
> > > by first adding use
> > > of_platform_populate to manage each hardware information:
> > > interrupt, clock, register
> > > bases and power. Secondly add core work queue to deal with core
> > > hardware message,
> > > at the same time, add msg queue for different hardware share
> > > messages. Lastly, the
> > > architecture of different specs are not the same, using specs type
> > > to separate them.
> > >
> > > This series has been tested with both MT8183 and MT8173. Decoding
> > > was working for both chips.
> > >
> >
> > How are you testing Decoding? If you are running some test suite, it
> > would
> > be good to add such information.
> >
> For 8183 and 8173, these patches don't have influence for them, can
> work well.
>
> These patches are used for mt8192 and 8195. We do cts/gts/stress test
> to check our drivers.
What is the meaning of cts/gts/stress tests?
Could you share the sources of the test?
Thanks,
Ezequiel
> > Are you testing some edge-cases such as parallel/concurrent decoding,
> > removing the driver while streaming, and so on? This should help
> > catch
> > some typical issues.
> >
> > Thanks,
> > Ezequiel
> >
> Thanks,
> Yunfei Dong
> > > Patches 1~3 rewrite get register bases and power on/off interface.
> > > Patches 4 export decoder pm interfaces.
> > > Patches 5 add to support 8192.
> > > Patch 6 support multi hardware.
> > > Patch 7 separate video encoder and decoder document
> > > Patch 8-17 add interfaces to support core hardware.
> > > Patch 18-19 remove mtk_vcodec_release_dec/enc_pm interfaces.
> > > ---
> > > changes compared with v9:
> > > - need not to build ko, just export pm interfaces for patch 04/19.
> > > - fix comments for patch 06/19
> > >
> > > changes compared with v8:
> > > - add new patch 18~19 to remove mtk_vcodec_release_de/enc_pm
> > > interfaces.
> > > - fix spelling mistakes for patch 17/19
> > > - fix yaml comments for patch 15/19
> > >
> > > Changes compared with v7:
> > > - add new patch 4 to build decoder pm file as module
> > > - add new patch 5 to support 8192
> > > - fix comments for patch 6/17
> > > - change some logic for using work queue instead of create thread
> > > for core hardware decode for patch 10/17
> > > - using work queue for hardware decode instead of create thread for
> > > patch 13/17
> > > - add returen value for patch 14/17
> > > - fix yaml check fail 15/17
> > >
> > > Changes compared with v6:
> > > - Use of_platform_populate to manage multi hardware, not component
> > > framework for patch 4/15
> > > - Re-write dtsi document for hardware architecture changed for
> > > patch 13/15 -The dtsi will write like below in patch 13/15:
> > > vcodec_dec: vcodec_dec@1600 {
> > > compatible = "mediatek,mt8192-vcodec-dec";
> > > #address-cells = <2>;
> > > #size-cells = <2>;
> > > ranges;
> > > reg = <0 0x1600 0 0x1000>; /* VDEC_SYS */
> > > mediatek,scp = <&scp>;
> > > iommus = <&iommu0 M4U_PORT_L4_VDEC_MC_EXT>;
> > > dma-ranges = <0x1 0x0 0x0 0x4000 0x0 0xfff0>;
> > > vcodec_lat {
> > > compatible = "mediatek,mtk-vcodec-lat";
> > > reg = <0 0x1601 0 0x800>; /*
> > > VDEC_MISC */
> > > reg-name = "reg-misc";
> > > interrupts = ;
> > > iommus = <&iommu0 M4U_PORT_L5_VDEC_LAT0_VLD_EXT>,
> > > <&iommu0 M4U_PORT_L5_VDEC_LAT0_VLD2_EXT>,
> > > <&iommu0 M4U_PORT_L5_VDEC_LAT0_AVC_MV_EXT>,
> > > <&iommu0 M4U_PORT_L5_VDEC_LAT0_PRED_RD_EXT>,
> > > <&iommu0 M4U_PORT_L5_VDEC_LAT0_TILE_EXT>,
> > > <&iommu0 M4U_PORT_L5_VDEC_LAT0_WDMA_EXT>,
> >
Re: [PATCH v10, 00/19] Support multi hardware decode using of_platform_populate
Hi Yunfei,
On Thu, 11 Nov 2021 at 01:15, Yunfei Dong wrote:
>
> This series adds support for multi hardware decode into mtk-vcodec, by first
> adding use
> of_platform_populate to manage each hardware information: interrupt, clock,
> register
> bases and power. Secondly add core work queue to deal with core hardware
> message,
> at the same time, add msg queue for different hardware share messages.
> Lastly, the
> architecture of different specs are not the same, using specs type to
> separate them.
>
> This series has been tested with both MT8183 and MT8173. Decoding was working
> for both chips.
>
How are you testing Decoding? If you are running some test suite, it would
be good to add such information.
Are you testing some edge-cases such as parallel/concurrent decoding,
removing the driver while streaming, and so on? This should help catch
some typical issues.
Thanks,
Ezequiel
> Patches 1~3 rewrite get register bases and power on/off interface.
> Patches 4 export decoder pm interfaces.
> Patches 5 add to support 8192.
> Patch 6 support multi hardware.
> Patch 7 separate video encoder and decoder document
> Patch 8-17 add interfaces to support core hardware.
> Patch 18-19 remove mtk_vcodec_release_dec/enc_pm interfaces.
> ---
> changes compared with v9:
> - need not to build ko, just export pm interfaces for patch 04/19.
> - fix comments for patch 06/19
>
> changes compared with v8:
> - add new patch 18~19 to remove mtk_vcodec_release_de/enc_pm interfaces.
> - fix spelling mistakes for patch 17/19
> - fix yaml comments for patch 15/19
>
> Changes compared with v7:
> - add new patch 4 to build decoder pm file as module
> - add new patch 5 to support 8192
> - fix comments for patch 6/17
> - change some logic for using work queue instead of create thread for core
> hardware decode for patch 10/17
> - using work queue for hardware decode instead of create thread for patch
> 13/17
> - add returen value for patch 14/17
> - fix yaml check fail 15/17
>
> Changes compared with v6:
> - Use of_platform_populate to manage multi hardware, not component framework
> for patch 4/15
> - Re-write dtsi document for hardware architecture changed for patch 13/15
> -The dtsi will write like below in patch 13/15:
> vcodec_dec: vcodec_dec@1600 {
> compatible = "mediatek,mt8192-vcodec-dec";
> #address-cells = <2>;
> #size-cells = <2>;
> ranges;
> reg = <0 0x1600 0 0x1000>; /* VDEC_SYS */
> mediatek,scp = <&scp>;
> iommus = <&iommu0 M4U_PORT_L4_VDEC_MC_EXT>;
> dma-ranges = <0x1 0x0 0x0 0x4000 0x0 0xfff0>;
> vcodec_lat {
> compatible = "mediatek,mtk-vcodec-lat";
> reg = <0 0x1601 0 0x800>; /* VDEC_MISC */
> reg-name = "reg-misc";
> interrupts = ;
> iommus = <&iommu0 M4U_PORT_L5_VDEC_LAT0_VLD_EXT>,
> <&iommu0 M4U_PORT_L5_VDEC_LAT0_VLD2_EXT>,
> <&iommu0 M4U_PORT_L5_VDEC_LAT0_AVC_MV_EXT>,
> <&iommu0 M4U_PORT_L5_VDEC_LAT0_PRED_RD_EXT>,
> <&iommu0 M4U_PORT_L5_VDEC_LAT0_TILE_EXT>,
> <&iommu0 M4U_PORT_L5_VDEC_LAT0_WDMA_EXT>,
> <&iommu0 M4U_PORT_L5_VDEC_LAT0_RG_CTRL_DMA_EXT>,
> <&iommu0 M4U_PORT_L5_VDEC_UFO_ENC_EXT>;
> clocks = <&topckgen CLK_TOP_VDEC_SEL>,
> <&vdecsys_soc CLK_VDEC_SOC_VDEC>,
> <&vdecsys_soc CLK_VDEC_SOC_LAT>,
> <&vdecsys_soc CLK_VDEC_SOC_LARB1>,
> <&topckgen CLK_TOP_MAINPLL_D4>;
> clock-names = "vdec-sel", "vdec-soc-vdec", "vdec-soc-lat",
> "vdec-vdec", "vdec-top";
> assigned-clocks = <&topckgen CLK_TOP_VDEC_SEL>;
> assigned-clock-parents = <&topckgen CLK_TOP_MAINPLL_D4>;
> power-domains = <&spm MT8192_POWER_DOMAIN_VDEC>;
> };
>
> vcodec_core {
> compatible = "mediatek,mtk-vcodec-core";
> reg = <0 0x16025000 0 0x1000>; /* VDEC_CORE_MISC */
> reg-names = "reg-misc";
> interrupts = ;
> iommus = <&iommu0 M4U_PORT_L4_VDEC_MC_EXT>,
> <&iommu0 M4U_PORT_L4_VDEC_UFO_EXT>,
> <&iommu0 M4U_PORT_L4_VDEC_PP_EXT>,
> <&iommu0 M4U_PORT_L4_VDEC_PRED_RD_EXT>,
> <&iommu0 M4U_PORT_L4_VDEC_PRED_WR_EXT>,
> <&iommu0 M4U_PORT_L4_VDEC_PPWRAP_EXT>,
> <&iommu0 M4U_PORT_L4_VDEC_TILE_EXT>,
> <&iommu0 M4U_PORT_L4_VDEC_VLD_EXT>,
> <&iommu0 M4U_PORT_L4_VDEC_VLD2_EXT>,
> <&iommu0 M4U_PORT_L4_VDEC_AVC_MV_EXT>,
> <&iommu0 M4U_PORT_L4_VDEC_RG_CTRL_DMA_EXT>;
> clocks = <&topckgen CLK_TOP_VDEC_SEL>,
> <&vdecsys CLK_VDEC_VDEC>,
> <&vdecsys CLK_VDEC_LAT>,
> <&vdecsys CLK_VDEC_LARB1>,
>
Re: [PATCH v10, 15/19] dt-bindings: media: mtk-vcodec: Adds decoder dt-bindings for mt8192
Yunfei, On Thu, 11 Nov 2021 at 01:15, Yunfei Dong wrote: > > Adds decoder dt-bindings for mt8192. > > Signed-off-by: Yunfei Dong > --- > .../media/mediatek,vcodec-subdev-decoder.yaml | 261 ++ > 1 file changed, 261 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/media/mediatek,vcodec-subdev-decoder.yaml > > diff --git > a/Documentation/devicetree/bindings/media/mediatek,vcodec-subdev-decoder.yaml > b/Documentation/devicetree/bindings/media/mediatek,vcodec-subdev-decoder.yaml > new file mode 100644 > index ..1886fae6e39d > --- /dev/null > +++ > b/Documentation/devicetree/bindings/media/mediatek,vcodec-subdev-decoder.yaml > @@ -0,0 +1,261 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > + > +%YAML 1.2 > +--- > +$id: > "http://devicetree.org/schemas/media/mediatek,vcodec-subdev-decoder.yaml#"; > +$schema: "http://devicetree.org/meta-schemas/core.yaml#"; > + > +title: Mediatek Video Decode Accelerator With Multi Hardware > + > +maintainers: > + - Yunfei Dong > + > +description: | > + Mediatek Video Decode is the video decode hardware present in Mediatek > + SoCs which supports high resolution decoding functionalities. Required > + main and subdev device node. > + > + About the Decoder Hardware Block Diagram, please check below: > + > ++-++ > +| || > +| input -> lat HW -> lat buffer --|--> lat buffer -> core HW -> output | To be completely honest, I can't really understand what is the meaning of the blocks with input -> lat hw -> lat buffer, and how this means lat- and core- are children of some parent. > +||| | || | > ++||---+-||-+ > + || lat thread | core thread|| > + > -||-|| > + || || > + \/\/ > + +--+ > + |enable/disable| > + | clk powerirqiommu port | > + | (lat/lat soc/core0/core1)| > + +--+ > + > + As above, mean in main device, mean in subdev device. The > information > + of each hardware will be stored in subdev device. There are two workqueues > in main device: > + lat and core. Enable/disable the lat clk/power/irq when lat need to work > through hardware > + index, core is the same. > + > + Normally the smi common may not the same for each hardware, can't combine > all hardware in > + one node, or leading to iommu fault when access dram data. > + To what extent the lat- and core- devices are really "children" or "subdevices" of the video-codec@1600 device? I.e. what resources do they share? What are the details of their bus topology? > + > +examples: > + - | > +#include > +#include > +#include > +#include > +#include > + > +video-codec@1600 { > +compatible = "mediatek,mt8192-vcodec-dec"; > +reg = <0x1600 0x1000>; /* VDEC_SYS */ > +mediatek,scp = <&scp>; > +iommus = <&iommu0 M4U_PORT_L4_VDEC_MC_EXT>; > +dma-ranges = <0x1 0x0 0x0 0x4000 0x0 0xfff0>; > +#address-cells = <1>; > +#size-cells = <1>; > +ranges; > +vcodec-lat@1601 { > +compatible = "mediatek,mtk-vcodec-lat"; > +reg = <0x1601 0x800>; > +interrupts = ; > +iommus = <&iommu0 M4U_PORT_L5_VDEC_LAT0_VLD_EXT>, > +<&iommu0 M4U_PORT_L5_VDEC_LAT0_VLD2_EXT>, > +<&iommu0 M4U_PORT_L5_VDEC_LAT0_AVC_MV_EXT>, > +<&iommu0 M4U_PORT_L5_VDEC_LAT0_PRED_RD_EXT>, > +<&iommu0 M4U_PORT_L5_VDEC_LAT0_TILE_EXT>, > +<&iommu0 M4U_PORT_L5_VDEC_LAT0_WDMA_EXT>, > +<&iommu0 M4U_PORT_L5_VDEC_LAT0_RG_CTRL_DMA_EXT>, > +<&iommu0 M4U_PORT_L5_VDEC_UFO_ENC_EXT>; > +clocks = <&topckgen CLK_TOP_VDEC_SEL>, > +<&vdecsys_soc CLK_VDEC_SOC_VDEC>, > +<&vdecsys_soc CLK_VDEC_SOC_LAT>, > +<&vdecsys_soc CLK_VDEC_SOC_LARB1>, > +<&topckgen CLK_TOP_MAINPLL_D4>; > +clock-names = "sel", "soc-vdec", "soc-lat", "vdec", "top"; > +assigned-clocks = <&topckgen CLK_TOP_VDEC_SEL>; > +assigned-clock-parents = <&topckgen CLK_TOP_MAINPLL_D4>; > +power-domains = <&spm MT8192_POWER_DOMAIN_VDEC>; > +}; > + > +vcodec-core@16025000 { >
Re: [PATCH v6, 00/15] Using component framework to support multi hardware decode
Hi Yunfei, On Tue, 12 Oct 2021 at 22:17, yunfei.d...@mediatek.com wrote: > > Hi Ezequiel, > > Thanks for your feedback, > > The driver can work well now according to your advice with > of_platform_populate interface. > > In order to separate parent node with children node, parent node is > master device, children node is component device. > > The master and component are registered platform device. > > > Could you please help to review the patch again when you are free: > > https://patchwork.linuxtv.org/project/linux-media/cover/20211011070247.792-1-yunfei.d...@mediatek.com/ > I'm glad you managed to simplify the driver. I tried applying the patches but they don't apply on media master. Please push a branch to gitlab or github or somewhere public. Keep in mind that when you need people to review your code, it's generally good practice to try to make it easy on them. The harder you make it, the less inclined people will be to spend time on your work. Thanks, Ezequiel
Re: [PATCH v7, 11/15] media: mtk-vcodec: Add core thread
Hi Yunfei,
On Mon, Oct 11, 2021 at 03:02:43PM +0800, Yunfei Dong wrote:
> Core thread:
> 1. Gets lat_buf from core msg queue.
> 2. Proceeds core decode.
> 3. Puts the lat_buf back to lat msg queue.
>
> Both H264 and VP9 rely on the core thread.
>
Avoid the kthread API and instead go with the workqueue API.
See Documentation/core-api/workqueue.rst and include/linux/workqueue.h.
Thanks!
Ezequiel
> Signed-off-by: Yunfei Dong
> ---
> .../platform/mtk-vcodec/mtk_vcodec_dec_drv.c | 12 +++
> .../platform/mtk-vcodec/mtk_vcodec_drv.h | 7
> .../platform/mtk-vcodec/vdec_msg_queue.c | 32 +++
> .../platform/mtk-vcodec/vdec_msg_queue.h | 6
> 4 files changed, 57 insertions(+)
>
> diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c
> b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c
> index e21e0c4bcd86..de83e3b821b4 100644
> --- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c
> +++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c
> @@ -364,6 +364,18 @@ static int mtk_vcodec_probe(struct platform_device *pdev)
> goto err_dec_pm;
> }
>
> + if (VDEC_LAT_ARCH(dev->vdec_pdata->hw_arch)) {
> + vdec_msg_queue_init_ctx(&dev->msg_queue_core_ctx,
> + MTK_VDEC_CORE);
> + dev->kthread_core = kthread_run(vdec_msg_queue_core_thead, dev,
> + "mtk-%s", "core");
> + if (IS_ERR(dev->kthread_core)) {
> + dev_err(&pdev->dev, "Failed to create core thread");
> + ret = PTR_ERR(dev->kthread_core);
> + goto err_res;
> + }
> + }
> +
> for (i = 0; i < MTK_VDEC_HW_MAX; i++)
> mutex_init(&dev->dec_mutex[i]);
> spin_lock_init(&dev->irqlock);
> diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
> b/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
> index 9d072c082f73..68a9b1a2d3b3 100644
> --- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
> +++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
> @@ -27,6 +27,7 @@
> #define MTK_VCODEC_MAX_PLANES3
> #define MTK_V4L2_BENCHMARK 0
> #define WAIT_INTR_TIMEOUT_MS 1000
> +#define VDEC_LAT_ARCH(hw_arch) ((hw_arch) >= MTK_VDEC_LAT_SINGLE_CORE)
>
> /*
> * enum mtk_hw_reg_idx - MTK hw register base index
> @@ -466,6 +467,9 @@ struct mtk_vcodec_enc_pdata {
> * @comp_dev: component hardware device
> * @component_node: component node
> *
> + * @kthread_core: thread used for core hardware decode
> + * @msg_queue_core_ctx: msg queue context used for core thread
> + *
> * @hardware_bitmap: used to record hardware is ready or not
> */
> struct mtk_vcodec_dev {
> @@ -508,6 +512,9 @@ struct mtk_vcodec_dev {
> void *comp_dev[MTK_VDEC_HW_MAX];
> struct device_node *component_node[MTK_VDEC_HW_MAX];
>
> + struct task_struct *kthread_core;
> + struct vdec_msg_queue_ctx msg_queue_core_ctx;
> +
> DECLARE_BITMAP(hardware_bitmap, MTK_VDEC_HW_MAX);
> };
>
> diff --git a/drivers/media/platform/mtk-vcodec/vdec_msg_queue.c
> b/drivers/media/platform/mtk-vcodec/vdec_msg_queue.c
> index d66ed98c79a9..665f571eab4b 100644
> --- a/drivers/media/platform/mtk-vcodec/vdec_msg_queue.c
> +++ b/drivers/media/platform/mtk-vcodec/vdec_msg_queue.c
> @@ -256,3 +256,35 @@ void vdec_msg_queue_deinit(
> kfree(lat_buf->private_data);
> }
> }
> +
> +int vdec_msg_queue_core_thead(void *data)
> +{
> + struct mtk_vcodec_dev *dev = data;
> + struct vdec_lat_buf *lat_buf;
> + struct mtk_vcodec_ctx *ctx;
> +
> + set_freezable();
> + for (;;) {
> + try_to_freeze();
> + if (kthread_should_stop())
> + break;
> +
> + lat_buf = vdec_msg_queue_dqbuf(&dev->msg_queue_core_ctx);
> + if (!lat_buf)
> + continue;
> +
> + ctx = lat_buf->ctx;
> + mtk_vcodec_set_curr_ctx(dev, ctx, MTK_VDEC_CORE);
> +
> + if (!lat_buf->core_decode)
> + mtk_v4l2_err("Core decode callback func is NULL");
> + else
> + lat_buf->core_decode(lat_buf);
> +
> + mtk_vcodec_set_curr_ctx(dev, NULL, MTK_VDEC_CORE);
> + vdec_msg_queue_qbuf(&ctx->msg_queue.lat_ctx, lat_buf);
> + }
> +
> + mtk_v4l2_debug(3, "Video Capture Thread End");
> + return 0;
> +}
> diff --git a/drivers/media/platform/mtk-vcodec/vdec_msg_queue.h
> b/drivers/media/platform/mtk-vcodec/vdec_msg_queue.h
> index 1905ce713592..b5745b144140 100644
> --- a/drivers/media/platform/mtk-vcodec/vdec_msg_queue.h
> +++ b/drivers/media/platform/mtk-vcodec/vdec_msg_queue.h
> @@ -148,4 +148,10 @@ void vdec_msg_queue_deinit(
> struct vdec_msg_queue *msg_queue,
> struct mtk_vcodec_ctx *ctx);
>
> +/**
> + * vdec_msg_queue_core_thead - used for core decoder.
> + * @data: private data used for each
Re: [PATCH v6, 00/15] Using component framework to support multi hardware decode
On Sun, 26 Sept 2021 at 05:27, yunfei.d...@mediatek.com wrote: > > Hi Ezequiel, > > Could you please help to give some feedback when you are free for iommu > limitation? > How about you work on the architecture I originally suggested? As the saying goes, talk is cheap, show us the code. So let's see the code and let's discuss the limitations with the code. > According to google's suggestion, it's better not to use v4l2 async > also. Hum? I haven't seen such objection on the mailing list. Thanks, Ezequiel
Re: [PATCH v6, 00/15] Using component framework to support multi hardware decode
On Wed, 1 Sept 2021 at 05:32, Yunfei Dong wrote:
>
> This series adds support for multi hardware decode into mtk-vcodec, by first
> adding component framework to manage each hardware information: interrupt,
> clock, register bases and power. Secondly add core thread to deal with core
> hardware message, at the same time, add msg queue for different hardware
> share messages. Lastly, the architecture of different specs are not the same,
> using specs type to separate them.
>
> This series has been tested with both MT8183 and MT8173. Decoding was working
> for both chips.
>
> Patches 1~3 rewrite get register bases and power on/off interface.
>
> Patch 4 add component framework to support multi hardware.
>
> Patch 5 separate video encoder and decoder document
>
> Patches 6-15 add interfaces to support core hardware.
>
> This patch dependents on : "media: mtk-vcodec: support for MT8183 decoder"[1]
> and
> "Mediatek MT8192 clock support"[2].
>
> 1: Multi hardware decode is based on stateless decoder, MT8183 is the first
> time
> to add stateless decoder. Otherwise it will cause conflict. This patch will be
> accepted in 5.15[1].
>
> 2: The definition of decoder clocks are in mt8192-clk.h, this patch already
> in clk tree[2].
>
> [1]https://patchwork.linuxtv.org/project/linux-media/list/?series=5826
> [2]https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git/commit/?h=clk-next&id=f35f1a23e0e12e3173e9e9dedbc150d139027189
>
> Changes compared with v5:
> -Add decoder hardware block diagram for patch 13/15
>
The discussion on v5 was still on-going, so sending this v6
is not helpful. The context for v5's discussion is now harder to find.
Please avoid sending a new version without properly
discussing all the feedback, and without reaching consensus.
This is very important, please keep it in mind.
Specifically, the feedback on v5 was NAK, with the request to avoid
using any async framework, and instead try to find a simpler solution.
For instance, you can model things with a bus-like pattern,
which ties all the devices together, under a parent node.
This pattern is common in the kernel, the parent
node can use of_platform_populate or similar
(git grep of_platform_populate, you will see plenty of examples).
You will still have to do some work to have the proper
regs resources, but this is doable. Each child is a device,
so it can have its own resources (clocks, interrupts, iommus).
You don't need any async framework.
vcodec_dec: vcodec_dec@1600 {
compatible = "mediatek,mt8192-vcodec-dec";
reg = ;
mediatek,scp = <&scp>;
iommus = <&iommu0 M4U_PORT_L4_VDEC_MC_EXT>;
dma-ranges = <0x1 0x0 0x0 0x4000 0x0 0xfff0>;
vcodec_lat@0x1 {
compatible = "mediatek,mtk-vcodec-lat";
reg = <0x1 0x800>; /* VDEC_MISC */
interrupts = ;
// etc
};
vcodec_core@0x25000 {
compatible = "mediatek,mtk-vcodec-core";
reg = <0x25000 0x1000>; /* VDEC_CORE_MISC */
interrupts = ;
// etc
};
};
Thanks,
Ezequiel
Re: [PATCH] MAINTAINERS: Add dri-devel for component.[hc]
Hi Daniel, On Thu, 26 Aug 2021 at 06:13, Daniel Vetter wrote: > > dri-devel is the main user, and somehow there's been the assumption > that component stuff is unmaintained. > > References: > https://lore.kernel.org/dri-devel/CAAEAJfDWOzCJxZFNtxeT7Cvr2pWbYrfz-YnA81sVNs-rM=8...@mail.gmail.com/ > Cc: Ezequiel Garcia > Cc: Greg Kroah-Hartman > Cc: "Rafael J. Wysocki" > Signed-off-by: Daniel Vetter > --- > MAINTAINERS | 5 + > 1 file changed, 5 insertions(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index ac58d0032abd..7cdc19815ec4 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -5707,6 +5707,11 @@ F: Documentation/admin-guide/blockdev/ > F: drivers/block/drbd/ > F: lib/lru_cache.c > > +DRIVER COMPONENT FRAMEWORK > +L: dri-devel@lists.freedesktop.org > +F: drivers/base/component.c > +F: include/linux/component.h > + Thanks for taking care of this, much appreciated. Ezequiel
Re: [PATCH v5, 00/15] Using component framework to support multi hardware decode
On Sun, 22 Aug 2021 at 13:50, Daniel Vetter wrote: > > On Wed, Aug 18, 2021 at 4:12 PM Ezequiel Garcia > wrote: > > > > +danvet > > > > Hi, > > > > On Tue, 10 Aug 2021 at 23:58, Yunfei Dong wrote: > > > > > > This series adds support for multi hardware decode into mtk-vcodec, by > > > first > > > adding component framework to manage each hardware information: interrupt, > > > clock, register bases and power. Secondly add core thread to deal with > > > core > > > hardware message, at the same time, add msg queue for different hardware > > > share messages. Lastly, the architecture of different specs are not the > > > same, > > > using specs type to separate them. > > > > > > > I don't think it's a good idea to introduce the component API in the > > media subsystem. It doesn't seem to be maintained, IRC there's not even > > a maintainer for it, and it has some issues that were never addressed. > > Defacto dri-devel folks are maintainer component.c, but also I'm not > aware of anything missing there? > A while ago, I tried to fix a crash in the Rockchip DRM driver (I was then told there can be similar issues on the IMX driver too, but I forgot the details of that). I sent a patchset trying to address it and got total silence back. Although you could argue the issue is in how drivers use the component API, AFAICR the abuse is spreaded across a few drivers, so it felt more reasonable to improve the component API itself, instead of changing all the drivers. See below: https://patchwork.kernel.org/project/linux-rockchip/cover/20200120170602.3832-1-ezequ...@collabora.com/ > There has been discussions that in various drm subsystems like > drm_bridge or drm_panel a few things are missing, which prevent > drivers from moving _away_ from component.c to the more specific > solutions for panel/bridges. But nothing that's preventing them from > using component.c itself. > > I'm happy to merge a MAINTAINERS patch to clarify the situation if > that's needed. Indeed, that would be good. Thanks, Ezequiel
Re: [PATCH v5, 00/15] Using component framework to support multi hardware decode
On Fri, 20 Aug 2021 at 04:59, yunfei.d...@mediatek.com wrote: > > Hi Ezequiel, > > Thanks for your detail feedback. > > On Thu, 2021-08-19 at 11:10 -0300, Ezequiel Garcia wrote: > > On Thu, 19 Aug 2021 at 04:13, yunfei.d...@mediatek.com > > wrote: > > > > > > Hi Ezequiel, > > > > > > Thanks for your suggestion. > > > > > > On Wed, 2021-08-18 at 11:11 -0300, Ezequiel Garcia wrote: > > > > +danvet > > > > > > > > Hi, > > > > > > > > On Tue, 10 Aug 2021 at 23:58, Yunfei Dong > > > > wrote: > > > > > > > > > > This series adds support for multi hardware decode into mtk-vcodec, > > > > > by first > > > > > adding component framework to manage each hardware information: > > > > > interrupt, > > > > > clock, register bases and power. Secondly add core thread to deal > > > > > with core > > > > > hardware message, at the same time, add msg queue for different > > > > > hardware > > > > > share messages. Lastly, the architecture of different specs are not > > > > > the same, > > > > > using specs type to separate them. > > > > > > > > > > > > > I don't think it's a good idea to introduce the component API in the > > > > media subsystem. It doesn't seem to be maintained, IRC there's not > > > > even > > > > a maintainer for it, and it has some issues that were never > > > > addressed. > > > > > > > > It would be really important to avoid it. Is it really needed in the > > > > first place? > > > > > > > > Thanks, > > > > Ezequiel > > > > > > For there are many hardware need to use, mt8192 is three and mt8195 is > > > five. Maybe need more to be used in the feature. > > > > > > Each hardware has independent clk/power/iommu port/irq. > > > Use component interface in prob to get each component's information. > > > Just enable the hardware when need to use it, very convenient and > > > simple. > > > > > > I found that there are many modules use component to manage hardware > > > information, such as iommu and drm etc. > > > > > > > Many drivers support multiple hardware variants, where each variant > > has a different number of clocks or interrupts, see for instance > > struct hantro_variant which allows to expose different codec cores, > > some having both decoder/encoder, and some having just a decoder. > > > > The component API is mostly used by DRM to aggregate independent > > subdevices (called components) into an aggregated driver. > > > > For instance, a DRM driver needs to glue together the HDMI, MIPI, > > and plany controller, or any other hardware arrangement where > > devices can be described independently. > > > The usage scenario is very similar with drm and iommu, So decide to use > component framework. > Decode has three/five or more hardwares, these hardware are independent. > For mt8183 just need core hardware to decode, but mt8192 has lat,soc and > core hardware to decode. When lat need to use, just enable lat hardware, > core is the same.And mt8195 will has two cores, each core can work well > independent. > > For each component device just used to open their power/clk/iommu > port/irq when master need to enable it. The main logic is in master > device. > > > The component API may look simple but has some issues, it's not easy > > to debug, and can cause troubles if not used as expected [1]. > > It's worth making sure you actually need a framework > > to glue different devices together. > > > Each hardware has its index, master can get hardware information > according these index, looks not complex. What do you mean about not > easy to debug? > > > > Do you have any other suggestion for this architecture? > > > > > > > Looking at the different patchsets that are posted, it's not clear > > to me what exactly are the different architectures that you intend > > to support, can you some documentation which clarifies that? > > > Have five hardwares lat,soc,core0,core1 and main. Lat thread can use lat > soc and main, core thread can use soc,lat, core0 and core1. Core thread > can be used or not for different project. Can you explain what are these lat,soc and core threads for? > Also Need to use these > hardware dynamic at the same time. So I use component framework, just > need to know the used hardware index according to different > project.Need not to do complex logic to manage these hardwares. > I am not thrilled to see the component framework introduced to the media subsystem. Like I said, it has no clear maintainer, and it's not easy to use. The media subsystem has some support which AFAIK does the same thing, see v4l2-async, which is maintained by media people. Please push a branch based on media/master containing these changes. I see there are other patch series for this device, but it's hard to track which goes first, etc. Thanks, Ezequiel
Re: [PATCH v5, 00/15] Using component framework to support multi hardware decode
On Thu, 19 Aug 2021 at 04:13, yunfei.d...@mediatek.com wrote: > > Hi Ezequiel, > > Thanks for your suggestion. > > On Wed, 2021-08-18 at 11:11 -0300, Ezequiel Garcia wrote: > > +danvet > > > > Hi, > > > > On Tue, 10 Aug 2021 at 23:58, Yunfei Dong > > wrote: > > > > > > This series adds support for multi hardware decode into mtk-vcodec, > > > by first > > > adding component framework to manage each hardware information: > > > interrupt, > > > clock, register bases and power. Secondly add core thread to deal > > > with core > > > hardware message, at the same time, add msg queue for different > > > hardware > > > share messages. Lastly, the architecture of different specs are not > > > the same, > > > using specs type to separate them. > > > > > > > I don't think it's a good idea to introduce the component API in the > > media subsystem. It doesn't seem to be maintained, IRC there's not > > even > > a maintainer for it, and it has some issues that were never > > addressed. > > > > It would be really important to avoid it. Is it really needed in the > > first place? > > > > Thanks, > > Ezequiel > > For there are many hardware need to use, mt8192 is three and mt8195 is > five. Maybe need more to be used in the feature. > > Each hardware has independent clk/power/iommu port/irq. > Use component interface in prob to get each component's information. > Just enable the hardware when need to use it, very convenient and > simple. > > I found that there are many modules use component to manage hardware > information, such as iommu and drm etc. > Many drivers support multiple hardware variants, where each variant has a different number of clocks or interrupts, see for instance struct hantro_variant which allows to expose different codec cores, some having both decoder/encoder, and some having just a decoder. The component API is mostly used by DRM to aggregate independent subdevices (called components) into an aggregated driver. For instance, a DRM driver needs to glue together the HDMI, MIPI, and plany controller, or any other hardware arrangement where devices can be described independently. The component API may look simple but has some issues, it's not easy to debug, and can cause troubles if not used as expected [1]. It's worth making sure you actually need a framework to glue different devices together. > Do you have any other suggestion for this architecture? > Looking at the different patchsets that are posted, it's not clear to me what exactly are the different architectures that you intend to support, can you some documentation which clarifies that? Thanks, Ezequiel [1] https://patchwork.kernel.org/project/linux-rockchip/cover/20200120170602.3832-1-ezequ...@collabora.com/
Re: [PATCH v5, 00/15] Using component framework to support multi hardware decode
+danvet Hi, On Tue, 10 Aug 2021 at 23:58, Yunfei Dong wrote: > > This series adds support for multi hardware decode into mtk-vcodec, by first > adding component framework to manage each hardware information: interrupt, > clock, register bases and power. Secondly add core thread to deal with core > hardware message, at the same time, add msg queue for different hardware > share messages. Lastly, the architecture of different specs are not the same, > using specs type to separate them. > I don't think it's a good idea to introduce the component API in the media subsystem. It doesn't seem to be maintained, IRC there's not even a maintainer for it, and it has some issues that were never addressed. It would be really important to avoid it. Is it really needed in the first place? Thanks, Ezequiel
Re: [PATCH 09/12] media: hantro: Enable H.264 on Rockchip VDPU2
Hi Alex, On Sat, 2021-06-26 at 10:33 +0200, Alex Bee wrote: > Hi Ezequiel, > > Am 26.06.21 um 02:46 schrieb Ezequiel Garcia: > > (Adding Nicolas) > > > > Hi Alex, > > > > On Fri, 2021-06-25 at 01:13 +0200, Alex Bee wrote: > > > Hi Ezequiel, > > > > > > Am 24.06.21 um 20:26 schrieb Ezequiel Garcia: > > > > Given H.264 support for VDPU2 was just added, let's enable it. > > > > For now, this is only enabled on platform that don't have > > > > an RKVDEC core, such as RK3328. > > > Is there any reason, you do not want to enabe H.264 on RK3399? I know > > > H.264 can be done by by rkvdec already, but from what I understand that > > > shouldn't be an issue: The first decoder found that meets the > > > requirements will be taken. > > > > > Thanks a lot the review. > > > > I really doubt userspace stacks are readily supporting that strategy. > > > > The first decoder device supporting the codec format will be selected, > > I doubt features such as profile and levels are checked to decide > > which decoder to use. > > > > I'd rather play safe on the kernel side and avoid offering > > two competing devices for the same codec. > > I wasn't aware of that. Current ffmpeg v4l2_request implementation seems > to not do VIDIOC_ENUM_FRAMESIZES - so we might end up being able to > decode up to 1920x1088 only if hantro decoder is picked/checked first. > Speaking of ffmpeg, now that MPEG-2, VP8 and H.264 control interfaces are stable, I think one of the next priorities would be to push Jonas' ffmpeg patches. It would be really cool if someone could take the lead on that front, as it would reduce kodi's out of tree stack, enable mpv, and so on. -- Kindly, Ezequiel
Re: [PATCH 12/12] media: hantro: Add support for the Rockchip PX30
Hi Alex,
On Fri, 2021-06-25 at 00:39 +0200, Alex Bee wrote:
> Hi Ezequiel,
>
> Am 24.06.21 um 20:26 schrieb Ezequiel Garcia:
> > From: Paul Kocialkowski
> >
> > The PX30 SoC includes both the VDPU2 and VEPU2 blocks which are similar
> > to the RK3399 (Hantro G1/H1 with shuffled registers).
> >
> > Signed-off-by: Paul Kocialkowski
> > Signed-off-by: Ezequiel Garcia
> > ---
> > drivers/staging/media/hantro/hantro_drv.c | 1 +
> > drivers/staging/media/hantro/hantro_hw.h | 1 +
> > .../staging/media/hantro/rockchip_vpu_hw.c | 28 +++
> > 3 files changed, 30 insertions(+)
> >
> > diff --git a/drivers/staging/media/hantro/hantro_drv.c
> > b/drivers/staging/media/hantro/hantro_drv.c
> > index 9b5415176bfe..8a2edd67f2c6 100644
> > --- a/drivers/staging/media/hantro/hantro_drv.c
> > +++ b/drivers/staging/media/hantro/hantro_drv.c
> > @@ -582,6 +582,7 @@ static const struct v4l2_file_operations hantro_fops = {
> >
> > static const struct of_device_id of_hantro_match[] = {
> > #ifdef CONFIG_VIDEO_HANTRO_ROCKCHIP
> > + { .compatible = "rockchip,px30-vpu", .data = &px30_vpu_variant, },
> > { .compatible = "rockchip,rk3036-vpu", .data = &rk3036_vpu_variant,
> > },
> > { .compatible = "rockchip,rk3066-vpu", .data = &rk3066_vpu_variant,
> > },
> > { .compatible = "rockchip,rk3288-vpu", .data = &rk3288_vpu_variant,
> > },
> > diff --git a/drivers/staging/media/hantro/hantro_hw.h
> > b/drivers/staging/media/hantro/hantro_hw.h
> > index 9296624654a6..df7b5e3a57b9 100644
> > --- a/drivers/staging/media/hantro/hantro_hw.h
> > +++ b/drivers/staging/media/hantro/hantro_hw.h
> > @@ -209,6 +209,7 @@ enum hantro_enc_fmt {
> >
> > extern const struct hantro_variant imx8mq_vpu_g2_variant;
> > extern const struct hantro_variant imx8mq_vpu_variant;
> > +extern const struct hantro_variant px30_vpu_variant;
> > extern const struct hantro_variant rk3036_vpu_variant;
> > extern const struct hantro_variant rk3066_vpu_variant;
> > extern const struct hantro_variant rk3288_vpu_variant;
> > diff --git a/drivers/staging/media/hantro/rockchip_vpu_hw.c
> > b/drivers/staging/media/hantro/rockchip_vpu_hw.c
> > index e4e3b5e7689b..e7f56e30b4a8 100644
> > --- a/drivers/staging/media/hantro/rockchip_vpu_hw.c
> > +++ b/drivers/staging/media/hantro/rockchip_vpu_hw.c
> > @@ -16,6 +16,7 @@
> >
> > #define RK3066_ACLK_MAX_FREQ (300 * 1000 * 1000)
> > #define RK3288_ACLK_MAX_FREQ (400 * 1000 * 1000)
> > +#define PX30_ACLK_MAX_FREQ (300 * 1000 * 1000)
> >
>
> Not sure it is required (besides semantics) to introduce a new
> *ACLK_MAX_FREQ here. rk3036_vpu_hw_init could be used to entirely
> replace px30_vpu_hw_init in px30_vpu_variant.
>
> (Maybe we can find some more common names, after we know which variant
> combinations exist)
>
TBH, I considered getting rid of all the macros and just use something
like 300 * MHZ.
Another alternative is to encode the clock rate in struct hantro_variant
itself.
In any case, I don't see this adding any value, so maybe I'll
just reuse rk3036_vpu_hw_init as you suggest.
> > /*
> > * Supported formats.
> > @@ -279,6 +280,12 @@ static int rockchip_vpu_hw_init(struct hantro_dev *vpu)
> > return 0;
> > }
> >
> > +static int px30_vpu_hw_init(struct hantro_dev *vpu)
> > +{
> > + clk_set_rate(vpu->clocks[0].clk, PX30_ACLK_MAX_FREQ);
> > + return 0;
> > +}
> > +
> > static void rk3066_vpu_dec_reset(struct hantro_ctx *ctx)
> > {
> > struct hantro_dev *vpu = ctx->dev;
> > @@ -452,6 +459,10 @@ static const char * const rockchip_vpu_clk_names[] = {
> > "aclk", "hclk"
> > };
> >
> > +static const char * const px30_clk_names[] = {
> > + "aclk", "hclk"
> > +};
> > +
> > /* VDPU1/VEPU1 */
> >
> > const struct hantro_variant rk3036_vpu_variant = {
> > @@ -548,3 +559,20 @@ const struct hantro_variant rk3399_vpu_variant = {
> > .clk_names = rockchip_vpu_clk_names,
> > .num_clocks = ARRAY_SIZE(rockchip_vpu_clk_names)
> > };
> > +
> > +const struct hantro_variant px30_vpu_variant = {
> > + .enc_offset = 0x0,
> > + .enc_fmts = rockchip_vpu_enc_fmts,
> > + .num_enc_fmts = ARRAY_SIZE(rockchip_vpu_enc_fmts),
> > + .dec_offset = 0x400,
> > + .dec_fmts = rk3399_vpu_dec_fmts,
> > + .num_dec_fmts = ARRAY_SIZE(rk3399_vpu_dec_fmts),
> > + .codec = HANTRO_JPEG_ENCODER | HANTRO_MPEG2_DECODER |
> > + HANTRO_VP8_DECODER | HANTRO_H264_DECODER,
> > + .codec_ops = rk3399_vpu_codec_ops,
> > + .irqs = rockchip_vpu2_irqs,
> > + .num_irqs = ARRAY_SIZE(rockchip_vpu2_irqs),
> > + .init = px30_vpu_hw_init,
> > + .clk_names = px30_clk_names,
> > + .num_clocks = ARRAY_SIZE(px30_clk_names)
> Better re-use rockchip_vpu_clk_names for these two.
Ah, this slipped through. You are right of course.
--
Kindly,
Ezequiel
Re: [PATCH 10/12] dt-bindings: media: rockchip-vpu: Add PX30 compatible
Hey Dafna, Thanks a lot for reviewing this. On Fri, 2021-06-25 at 12:21 +0300, Dafna Hirschfeld wrote: > Hi, > > On 24.06.21 21:26, Ezequiel Garcia wrote: > > From: Paul Kocialkowski > > > > The Rockchip PX30 SoC has a Hantro VPU that features a decoder (VDPU2) > > and an encoder (VEPU2). > > > > Signed-off-by: Paul Kocialkowski > > Signed-off-by: Ezequiel Garcia > > --- > > Documentation/devicetree/bindings/media/rockchip-vpu.yaml | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/Documentation/devicetree/bindings/media/rockchip-vpu.yaml > > b/Documentation/devicetree/bindings/media/rockchip-vpu.yaml > > index b88172a59de7..3b9c5aa91fcc 100644 > > --- a/Documentation/devicetree/bindings/media/rockchip-vpu.yaml > > +++ b/Documentation/devicetree/bindings/media/rockchip-vpu.yaml > > @@ -28,6 +28,9 @@ properties: > > - items: > > - const: rockchip,rk3228-vpu > > - const: rockchip,rk3399-vpu > > + - items: > > + - const: rockchip,px30-vpu > > + - const: rockchip,rk3399-vpu > > This rk3399 compatible is already mentioned in the last 'items' list, should > we add it again? > What we are mandating here is that "rockchip,px30-vpu" can only be used with "rockchip,rk3399-vpu". I.e.: compatible = "rockchip,px30-vpu", "rockchip,rk3399-vpu"; -- Kindly, Ezequiel
Re: [PATCH 09/12] media: hantro: Enable H.264 on Rockchip VDPU2
(Adding Nicolas) Hi Alex, On Fri, 2021-06-25 at 01:13 +0200, Alex Bee wrote: > Hi Ezequiel, > > Am 24.06.21 um 20:26 schrieb Ezequiel Garcia: > > Given H.264 support for VDPU2 was just added, let's enable it. > > For now, this is only enabled on platform that don't have > > an RKVDEC core, such as RK3328. > > Is there any reason, you do not want to enabe H.264 on RK3399? I know > H.264 can be done by by rkvdec already, but from what I understand that > shouldn't be an issue: The first decoder found that meets the > requirements will be taken. > Thanks a lot the review. I really doubt userspace stacks are readily supporting that strategy. The first decoder device supporting the codec format will be selected, I doubt features such as profile and levels are checked to decide which decoder to use. I'd rather play safe on the kernel side and avoid offering two competing devices for the same codec. Kindly, Ezequiel
[PATCH 08/12] media: hantro: Add H.264 support for Rockchip VDPU2
From: Jonas Karlman Rockchip VDPU2 core is present on RK3328, RK3326/PX30, RK3399 and others. It's similar to Hantro G1, but it's not compatible with it. Signed-off-by: Jonas Karlman Signed-off-by: Ezequiel Garcia --- drivers/staging/media/hantro/Makefile | 1 + drivers/staging/media/hantro/hantro_hw.h | 1 + .../media/hantro/rockchip_vpu2_hw_h264_dec.c | 491 ++ 3 files changed, 493 insertions(+) create mode 100644 drivers/staging/media/hantro/rockchip_vpu2_hw_h264_dec.c diff --git a/drivers/staging/media/hantro/Makefile b/drivers/staging/media/hantro/Makefile index 287370188d2a..90036831fec4 100644 --- a/drivers/staging/media/hantro/Makefile +++ b/drivers/staging/media/hantro/Makefile @@ -13,6 +13,7 @@ hantro-vpu-y += \ hantro_g2_hevc_dec.o \ hantro_g1_vp8_dec.o \ rockchip_vpu2_hw_jpeg_enc.o \ + rockchip_vpu2_hw_h264_dec.o \ rockchip_vpu2_hw_mpeg2_dec.o \ rockchip_vpu2_hw_vp8_dec.o \ hantro_jpeg.o \ diff --git a/drivers/staging/media/hantro/hantro_hw.h b/drivers/staging/media/hantro/hantro_hw.h index 7a8048afe357..9296624654a6 100644 --- a/drivers/staging/media/hantro/hantro_hw.h +++ b/drivers/staging/media/hantro/hantro_hw.h @@ -241,6 +241,7 @@ dma_addr_t hantro_h264_get_ref_buf(struct hantro_ctx *ctx, u16 hantro_h264_get_ref_nbr(struct hantro_ctx *ctx, unsigned int dpb_idx); int hantro_h264_dec_prepare_run(struct hantro_ctx *ctx); +int rockchip_vpu2_h264_dec_run(struct hantro_ctx *ctx); int hantro_g1_h264_dec_run(struct hantro_ctx *ctx); int hantro_h264_dec_init(struct hantro_ctx *ctx); void hantro_h264_dec_exit(struct hantro_ctx *ctx); diff --git a/drivers/staging/media/hantro/rockchip_vpu2_hw_h264_dec.c b/drivers/staging/media/hantro/rockchip_vpu2_hw_h264_dec.c new file mode 100644 index ..64a6330475eb --- /dev/null +++ b/drivers/staging/media/hantro/rockchip_vpu2_hw_h264_dec.c @@ -0,0 +1,491 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Hantro VPU codec driver + * + * Copyright (c) 2014 Rockchip Electronics Co., Ltd. + * Hertz Wong + * Herman Chen + * + * Copyright (C) 2014 Google, Inc. + * Tomasz Figa + */ + +#include +#include + +#include + +#include "hantro_hw.h" +#include "hantro_v4l2.h" + +#define VDPU_SWREG(nr) ((nr) * 4) + +#define VDPU_REG_DEC_OUT_BASE VDPU_SWREG(63) +#define VDPU_REG_RLC_VLC_BASE VDPU_SWREG(64) +#define VDPU_REG_QTABLE_BASE VDPU_SWREG(61) +#define VDPU_REG_DIR_MV_BASE VDPU_SWREG(62) +#define VDPU_REG_REFER_BASE(i) (VDPU_SWREG(84 + (i))) +#define VDPU_REG_DEC_E(v) ((v) ? BIT(0) : 0) + +#define VDPU_REG_DEC_ADV_PRE_DIS(v)((v) ? BIT(11) : 0) +#define VDPU_REG_DEC_SCMD_DIS(v) ((v) ? BIT(10) : 0) +#define VDPU_REG_FILTERING_DIS(v) ((v) ? BIT(8) : 0) +#define VDPU_REG_PIC_FIXED_QUANT(v)((v) ? BIT(7) : 0) +#define VDPU_REG_DEC_LATENCY(v)(((v) << 1) & GENMASK(6, 1)) + +#define VDPU_REG_INIT_QP(v)(((v) << 25) & GENMASK(30, 25)) +#define VDPU_REG_STREAM_LEN(v) (((v) << 0) & GENMASK(23, 0)) + +#define VDPU_REG_APF_THRESHOLD(v) (((v) << 17) & GENMASK(30, 17)) +#define VDPU_REG_STARTMB_X(v) (((v) << 8) & GENMASK(16, 8)) +#define VDPU_REG_STARTMB_Y(v) (((v) << 0) & GENMASK(7, 0)) + +#define VDPU_REG_DEC_MODE(v) (((v) << 0) & GENMASK(3, 0)) + +#define VDPU_REG_DEC_STRENDIAN_E(v)((v) ? BIT(5) : 0) +#define VDPU_REG_DEC_STRSWAP32_E(v)((v) ? BIT(4) : 0) +#define VDPU_REG_DEC_OUTSWAP32_E(v)((v) ? BIT(3) : 0) +#define VDPU_REG_DEC_INSWAP32_E(v) ((v) ? BIT(2) : 0) +#define VDPU_REG_DEC_OUT_ENDIAN(v) ((v) ? BIT(1) : 0) +#define VDPU_REG_DEC_IN_ENDIAN(v) ((v) ? BIT(0) : 0) + +#define VDPU_REG_DEC_DATA_DISC_E(v)((v) ? BIT(22) : 0) +#define VDPU_REG_DEC_MAX_BURST(v) (((v) << 16) & GENMASK(20, 16)) +#define VDPU_REG_DEC_AXI_WR_ID(v) (((v) << 8) & GENMASK(15, 8)) +#define VDPU_REG_DEC_AXI_RD_ID(v) (((v) << 0) & GENMASK(7, 0)) + +#define VDPU_REG_START_CODE_E(v) ((v) ? BIT(22) : 0) +#define VDPU_REG_CH_8PIX_ILEAV_E(v)((v) ? BIT(21) : 0) +#define VDPU_REG_RLC_MODE_E(v) ((v) ? BIT(20) : 0) +#define VDPU_REG_PIC_INTERLACE_E(v)((v) ? BIT(17) : 0) +#define VDPU_REG_PIC_FIELDMODE_E(v)((v) ? BIT(16) : 0) +#define VDPU_REG_PIC_TOPFIELD_E(v) ((v) ? BIT(13) : 0) +#define VDPU_REG_WRITE_MVS_E(v)((v) ? BIT(10) : 0) +#define VDPU_REG_SEQ_MBAFF_E(v)((v) ? BIT(7) : 0) +#define VDPU_REG_PICORD_COUNT_E(v) ((v) ? BIT(6) : 0) +#define VDPU_REG_DEC_TIMEOUT_E(v) ((v) ? BIT(5) : 0) +#define VDPU_REG_DEC_CLK_GATE_E(v) ((v) ? BIT(4) : 0) + +#define VDPU_REG_PRED_BC_TAP_0_0(v)(((v) << 22) &
[PATCH 04/12] hantro: Make struct hantro_variant.init() optional
The hantro_variant.init() function is there for platforms
to perform hardware-specific initialization, such as
clock rate bumping.
Not all platforms require it, so make it optional.
Signed-off-by: Ezequiel Garcia
---
drivers/staging/media/hantro/hantro.h | 4 ++--
drivers/staging/media/hantro/hantro_drv.c | 10 ++
drivers/staging/media/hantro/sama5d4_vdec_hw.c | 6 --
3 files changed, 8 insertions(+), 12 deletions(-)
diff --git a/drivers/staging/media/hantro/hantro.h
b/drivers/staging/media/hantro/hantro.h
index a70c386de6f1..c2e2dca38628 100644
--- a/drivers/staging/media/hantro/hantro.h
+++ b/drivers/staging/media/hantro/hantro.h
@@ -61,8 +61,8 @@ struct hantro_irq {
* @num_postproc_fmts: Number of post-processor formats.
* @codec: Supported codecs
* @codec_ops: Codec ops.
- * @init: Initialize hardware.
- * @runtime_resume:reenable hardware after power gating
+ * @init: Initialize hardware, optional.
+ * @runtime_resume:reenable hardware after power gating, optional.
* @irqs: array of irq names and interrupt handlers
* @num_irqs: number of irqs in the array
* @clk_names: array of clock names
diff --git a/drivers/staging/media/hantro/hantro_drv.c
b/drivers/staging/media/hantro/hantro_drv.c
index 31d8449ca1d2..9b5415176bfe 100644
--- a/drivers/staging/media/hantro/hantro_drv.c
+++ b/drivers/staging/media/hantro/hantro_drv.c
@@ -942,10 +942,12 @@ static int hantro_probe(struct platform_device *pdev)
}
}
- ret = vpu->variant->init(vpu);
- if (ret) {
- dev_err(&pdev->dev, "Failed to init VPU hardware\n");
- return ret;
+ if (vpu->variant->init) {
+ ret = vpu->variant->init(vpu);
+ if (ret) {
+ dev_err(&pdev->dev, "Failed to init VPU hardware\n");
+ return ret;
+ }
}
pm_runtime_set_autosuspend_delay(vpu->dev, 100);
diff --git a/drivers/staging/media/hantro/sama5d4_vdec_hw.c
b/drivers/staging/media/hantro/sama5d4_vdec_hw.c
index 58ae72c2b723..9c3b8cd0b239 100644
--- a/drivers/staging/media/hantro/sama5d4_vdec_hw.c
+++ b/drivers/staging/media/hantro/sama5d4_vdec_hw.c
@@ -64,11 +64,6 @@ static const struct hantro_fmt sama5d4_vdec_fmts[] = {
},
};
-static int sama5d4_hw_init(struct hantro_dev *vpu)
-{
- return 0;
-}
-
/*
* Supported codec ops.
*/
@@ -109,7 +104,6 @@ const struct hantro_variant sama5d4_vdec_variant = {
.codec = HANTRO_MPEG2_DECODER | HANTRO_VP8_DECODER |
HANTRO_H264_DECODER,
.codec_ops = sama5d4_vdec_codec_ops,
- .init = sama5d4_hw_init,
.irqs = sama5d4_irqs,
.num_irqs = ARRAY_SIZE(sama5d4_irqs),
.clk_names = sama5d4_clk_names,
--
2.30.0
[PATCH 09/12] media: hantro: Enable H.264 on Rockchip VDPU2
Given H.264 support for VDPU2 was just added, let's enable it.
For now, this is only enabled on platform that don't have
an RKVDEC core, such as RK3328.
Signed-off-by: Ezequiel Garcia
---
.../staging/media/hantro/rockchip_vpu_hw.c| 26 ++-
1 file changed, 25 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/media/hantro/rockchip_vpu_hw.c
b/drivers/staging/media/hantro/rockchip_vpu_hw.c
index 3ccc16413f42..e4e3b5e7689b 100644
--- a/drivers/staging/media/hantro/rockchip_vpu_hw.c
+++ b/drivers/staging/media/hantro/rockchip_vpu_hw.c
@@ -162,6 +162,19 @@ static const struct hantro_fmt rk3399_vpu_dec_fmts[] = {
.fourcc = V4L2_PIX_FMT_NV12,
.codec_mode = HANTRO_MODE_NONE,
},
+ {
+ .fourcc = V4L2_PIX_FMT_H264_SLICE,
+ .codec_mode = HANTRO_MODE_H264_DEC,
+ .max_depth = 2,
+ .frmsize = {
+ .min_width = 48,
+ .max_width = 1920,
+ .step_width = MB_DIM,
+ .min_height = 48,
+ .max_height = 1088,
+ .step_height = MB_DIM,
+ },
+ },
{
.fourcc = V4L2_PIX_FMT_MPEG2_SLICE,
.codec_mode = HANTRO_MODE_MPEG2_DEC,
@@ -388,6 +401,12 @@ static const struct hantro_codec_ops
rk3399_vpu_codec_ops[] = {
.init = hantro_jpeg_enc_init,
.exit = hantro_jpeg_enc_exit,
},
+ [HANTRO_MODE_H264_DEC] = {
+ .run = rockchip_vpu2_h264_dec_run,
+ .reset = rockchip_vpu2_dec_reset,
+ .init = hantro_h264_dec_init,
+ .exit = hantro_h264_dec_exit,
+ },
[HANTRO_MODE_MPEG2_DEC] = {
.run = rockchip_vpu2_mpeg2_dec_run,
.reset = rockchip_vpu2_dec_reset,
@@ -433,6 +452,8 @@ static const char * const rockchip_vpu_clk_names[] = {
"aclk", "hclk"
};
+/* VDPU1/VEPU1 */
+
const struct hantro_variant rk3036_vpu_variant = {
.dec_offset = 0x400,
.dec_fmts = rk3066_vpu_dec_fmts,
@@ -495,11 +516,14 @@ const struct hantro_variant rk3288_vpu_variant = {
.num_clocks = ARRAY_SIZE(rockchip_vpu_clk_names)
};
+/* VDPU2/VEPU2 */
+
const struct hantro_variant rk3328_vpu_variant = {
.dec_offset = 0x400,
.dec_fmts = rk3399_vpu_dec_fmts,
.num_dec_fmts = ARRAY_SIZE(rk3399_vpu_dec_fmts),
- .codec = HANTRO_MPEG2_DECODER | HANTRO_VP8_DECODER,
+ .codec = HANTRO_MPEG2_DECODER | HANTRO_VP8_DECODER |
+HANTRO_H264_DECODER,
.codec_ops = rk3399_vpu_codec_ops,
.irqs = rockchip_vdpu2_irqs,
.num_irqs = ARRAY_SIZE(rockchip_vdpu2_irqs),
--
2.30.0
[PATCH 07/12] media: hantro: h264: Move reference picture number to a helper
Add a hantro_h264_get_ref_nbr() helper function to get the reference
picture numbers. This will be used by the Rockchip VDPU2 H.264 driver.
Signed-off-by: Ezequiel Garcia
---
drivers/staging/media/hantro/hantro_g1_h264_dec.c | 14 ++
drivers/staging/media/hantro/hantro_h264.c| 11 +++
drivers/staging/media/hantro/hantro_hw.h | 2 ++
3 files changed, 15 insertions(+), 12 deletions(-)
diff --git a/drivers/staging/media/hantro/hantro_g1_h264_dec.c
b/drivers/staging/media/hantro/hantro_g1_h264_dec.c
index 6faacfc44c7c..236ce24ca00c 100644
--- a/drivers/staging/media/hantro/hantro_g1_h264_dec.c
+++ b/drivers/staging/media/hantro/hantro_g1_h264_dec.c
@@ -126,7 +126,6 @@ static void set_params(struct hantro_ctx *ctx, struct
vb2_v4l2_buffer *src_buf)
static void set_ref(struct hantro_ctx *ctx)
{
- struct v4l2_h264_dpb_entry *dpb = ctx->h264_dec.dpb;
const u8 *b0_reflist, *b1_reflist, *p_reflist;
struct hantro_dev *vpu = ctx->dev;
int reg_num;
@@ -143,17 +142,8 @@ static void set_ref(struct hantro_ctx *ctx)
* subsequential reference pictures.
*/
for (i = 0; i < HANTRO_H264_DPB_SIZE; i += 2) {
- reg = 0;
- if (dpb[i].flags & V4L2_H264_DPB_ENTRY_FLAG_LONG_TERM)
- reg |= G1_REG_REF_PIC_REFER0_NBR(dpb[i].pic_num);
- else
- reg |= G1_REG_REF_PIC_REFER0_NBR(dpb[i].frame_num);
-
- if (dpb[i + 1].flags & V4L2_H264_DPB_ENTRY_FLAG_LONG_TERM)
- reg |= G1_REG_REF_PIC_REFER1_NBR(dpb[i + 1].pic_num);
- else
- reg |= G1_REG_REF_PIC_REFER1_NBR(dpb[i + 1].frame_num);
-
+ reg = G1_REG_REF_PIC_REFER0_NBR(hantro_h264_get_ref_nbr(ctx,
i)) |
+ G1_REG_REF_PIC_REFER1_NBR(hantro_h264_get_ref_nbr(ctx, i
+ 1));
vdpu_write_relaxed(vpu, reg, G1_REG_REF_PIC(i / 2));
}
diff --git a/drivers/staging/media/hantro/hantro_h264.c
b/drivers/staging/media/hantro/hantro_h264.c
index 6d72136760e7..0b4d2491be3b 100644
--- a/drivers/staging/media/hantro/hantro_h264.c
+++ b/drivers/staging/media/hantro/hantro_h264.c
@@ -348,6 +348,17 @@ dma_addr_t hantro_h264_get_ref_buf(struct hantro_ctx *ctx,
return dma_addr;
}
+u16 hantro_h264_get_ref_nbr(struct hantro_ctx *ctx, unsigned int dpb_idx)
+{
+ const struct v4l2_h264_dpb_entry *dpb = &ctx->h264_dec.dpb[dpb_idx];
+
+ if (!(dpb->flags & V4L2_H264_DPB_ENTRY_FLAG_ACTIVE))
+ return 0;
+ if (dpb->flags & V4L2_H264_DPB_ENTRY_FLAG_LONG_TERM)
+ return dpb->pic_num;
+ return dpb->frame_num;
+}
+
int hantro_h264_dec_prepare_run(struct hantro_ctx *ctx)
{
struct hantro_h264_dec_hw_ctx *h264_ctx = &ctx->h264_dec;
diff --git a/drivers/staging/media/hantro/hantro_hw.h
b/drivers/staging/media/hantro/hantro_hw.h
index ce678fedaad6..7a8048afe357 100644
--- a/drivers/staging/media/hantro/hantro_hw.h
+++ b/drivers/staging/media/hantro/hantro_hw.h
@@ -238,6 +238,8 @@ void hantro_jpeg_enc_done(struct hantro_ctx *ctx);
dma_addr_t hantro_h264_get_ref_buf(struct hantro_ctx *ctx,
unsigned int dpb_idx);
+u16 hantro_h264_get_ref_nbr(struct hantro_ctx *ctx,
+ unsigned int dpb_idx);
int hantro_h264_dec_prepare_run(struct hantro_ctx *ctx);
int hantro_g1_h264_dec_run(struct hantro_ctx *ctx);
int hantro_h264_dec_init(struct hantro_ctx *ctx);
--
2.30.0
[PATCH 10/12] dt-bindings: media: rockchip-vpu: Add PX30 compatible
From: Paul Kocialkowski The Rockchip PX30 SoC has a Hantro VPU that features a decoder (VDPU2) and an encoder (VEPU2). Signed-off-by: Paul Kocialkowski Signed-off-by: Ezequiel Garcia --- Documentation/devicetree/bindings/media/rockchip-vpu.yaml | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Documentation/devicetree/bindings/media/rockchip-vpu.yaml b/Documentation/devicetree/bindings/media/rockchip-vpu.yaml index b88172a59de7..3b9c5aa91fcc 100644 --- a/Documentation/devicetree/bindings/media/rockchip-vpu.yaml +++ b/Documentation/devicetree/bindings/media/rockchip-vpu.yaml @@ -28,6 +28,9 @@ properties: - items: - const: rockchip,rk3228-vpu - const: rockchip,rk3399-vpu + - items: + - const: rockchip,px30-vpu + - const: rockchip,rk3399-vpu reg: maxItems: 1 -- 2.30.0
[PATCH 11/12] arm64: dts: rockchip: Add VPU support for the PX30
From: Paul Kocialkowski
The PX30 has a VPU (both decoder and encoder) with a dedicated IOMMU.
Describe these two entities in device-tree.
Signed-off-by: Paul Kocialkowski
Signed-off-by: Ezequiel Garcia
---
arch/arm64/boot/dts/rockchip/px30.dtsi | 23 +++
1 file changed, 23 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/px30.dtsi
b/arch/arm64/boot/dts/rockchip/px30.dtsi
index 09baa8a167ce..892eb074775b 100644
--- a/arch/arm64/boot/dts/rockchip/px30.dtsi
+++ b/arch/arm64/boot/dts/rockchip/px30.dtsi
@@ -1016,6 +1016,29 @@ gpu: gpu@ff40 {
status = "disabled";
};
+ vpu: video-codec@ff442000 {
+ compatible = "rockchip,px30-vpu", "rockchip,rk3399-vpu";
+ reg = <0x0 0xff442000 0x0 0x800>;
+ interrupts = ,
+;
+ interrupt-names = "vepu", "vdpu";
+ clocks = <&cru ACLK_VPU>, <&cru HCLK_VPU>;
+ clock-names = "aclk", "hclk";
+ iommus = <&vpu_mmu>;
+ power-domains = <&power PX30_PD_VPU>;
+ };
+
+ vpu_mmu: iommu@ff442800 {
+ compatible = "rockchip,iommu";
+ reg = <0x0 0xff442800 0x0 0x100>;
+ interrupts = ;
+ interrupt-names = "vpu_mmu";
+ clocks = <&cru ACLK_VPU>, <&cru HCLK_VPU>;
+ clock-names = "aclk", "iface";
+ #iommu-cells = <0>;
+ power-domains = <&power PX30_PD_VPU>;
+ };
+
dsi: dsi@ff45 {
compatible = "rockchip,px30-mipi-dsi";
reg = <0x0 0xff45 0x0 0x1>;
--
2.30.0
[PATCH 02/12] arm64: dts: rockchip: Add panel orientation to Odroid Go Advance
The Odroid Go Advance panel is rotated, so let's reflect this
in the device tree.
Signed-off-by: Ezequiel Garcia
---
arch/arm64/boot/dts/rockchip/rk3326-odroid-go2.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3326-odroid-go2.dts
b/arch/arm64/boot/dts/rockchip/rk3326-odroid-go2.dts
index 49c97f76df77..cca19660e60a 100644
--- a/arch/arm64/boot/dts/rockchip/rk3326-odroid-go2.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3326-odroid-go2.dts
@@ -240,6 +240,7 @@ panel@0 {
iovcc-supply = <&vcc_lcd>;
reset-gpios = <&gpio3 RK_PC0 GPIO_ACTIVE_LOW>;
vdd-supply = <&vcc_lcd>;
+ rotation = <270>;
port {
mipi_in_panel: endpoint {
--
2.30.0
Re: [PATCH 02/12] arm64: dts: rockchip: Add panel orientation to Odroid Go Advance
On Thu, 2021-06-24 at 20:37 +0200, Heiko Stübner wrote: > Am Donnerstag, 24. Juni 2021, 20:26:02 CEST schrieb Ezequiel Garcia: > > The Odroid Go Advance panel is rotated, so let's reflect this > > in the device tree. > > > > Signed-off-by: Ezequiel Garcia > > similar patch already applied for 5.14: > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/arch/arm64/boot/dts/rockchip/rk3326-odroid-go2.dts?id=edb39de5d731f147c7b08c4a5eb246ae1dbdd947 Great minds think alike! :) Thanks, Ezequiel
[PATCH 05/12] media: hantro: Avoid redundant hantro_get_{dst, src}_buf() calls
Getting the next src/dst buffer is relatively expensive
so avoid doing it multiple times.
Signed-off-by: Ezequiel Garcia
---
.../staging/media/hantro/hantro_g1_h264_dec.c | 17 -
.../staging/media/hantro/hantro_g1_vp8_dec.c | 18 +-
.../media/hantro/rockchip_vpu2_hw_vp8_dec.c | 19 +--
3 files changed, 26 insertions(+), 28 deletions(-)
diff --git a/drivers/staging/media/hantro/hantro_g1_h264_dec.c
b/drivers/staging/media/hantro/hantro_g1_h264_dec.c
index 5c792b7bcb79..2aa37baad0c3 100644
--- a/drivers/staging/media/hantro/hantro_g1_h264_dec.c
+++ b/drivers/staging/media/hantro/hantro_g1_h264_dec.c
@@ -19,13 +19,12 @@
#include "hantro_hw.h"
#include "hantro_v4l2.h"
-static void set_params(struct hantro_ctx *ctx)
+static void set_params(struct hantro_ctx *ctx, struct vb2_v4l2_buffer *src_buf)
{
const struct hantro_h264_dec_ctrls *ctrls = &ctx->h264_dec.ctrls;
const struct v4l2_ctrl_h264_decode_params *dec_param = ctrls->decode;
const struct v4l2_ctrl_h264_sps *sps = ctrls->sps;
const struct v4l2_ctrl_h264_pps *pps = ctrls->pps;
- struct vb2_v4l2_buffer *src_buf = hantro_get_src_buf(ctx);
struct hantro_dev *vpu = ctx->dev;
u32 reg;
@@ -226,22 +225,20 @@ static void set_ref(struct hantro_ctx *ctx)
}
}
-static void set_buffers(struct hantro_ctx *ctx)
+static void set_buffers(struct hantro_ctx *ctx, struct vb2_v4l2_buffer
*src_buf)
{
const struct hantro_h264_dec_ctrls *ctrls = &ctx->h264_dec.ctrls;
- struct vb2_v4l2_buffer *src_buf, *dst_buf;
+ struct vb2_v4l2_buffer *dst_buf;
struct hantro_dev *vpu = ctx->dev;
dma_addr_t src_dma, dst_dma;
size_t offset = 0;
- src_buf = hantro_get_src_buf(ctx);
- dst_buf = hantro_get_dst_buf(ctx);
-
/* Source (stream) buffer. */
src_dma = vb2_dma_contig_plane_dma_addr(&src_buf->vb2_buf, 0);
vdpu_write_relaxed(vpu, src_dma, G1_REG_ADDR_STR);
/* Destination (decoded frame) buffer. */
+ dst_buf = hantro_get_dst_buf(ctx);
dst_dma = hantro_get_dec_buf_addr(ctx, &dst_buf->vb2_buf);
/* Adjust dma addr to start at second line for bottom field */
if (ctrls->decode->flags & V4L2_H264_DECODE_PARAM_FLAG_BOTTOM_FIELD)
@@ -276,6 +273,7 @@ static void set_buffers(struct hantro_ctx *ctx)
int hantro_g1_h264_dec_run(struct hantro_ctx *ctx)
{
struct hantro_dev *vpu = ctx->dev;
+ struct vb2_v4l2_buffer *src_buf;
int ret;
/* Prepare the H264 decoder context. */
@@ -284,9 +282,10 @@ int hantro_g1_h264_dec_run(struct hantro_ctx *ctx)
return ret;
/* Configure hardware registers. */
- set_params(ctx);
+ src_buf = hantro_get_src_buf(ctx);
+ set_params(ctx, src_buf);
set_ref(ctx);
- set_buffers(ctx);
+ set_buffers(ctx, src_buf);
hantro_end_prepare_run(ctx);
diff --git a/drivers/staging/media/hantro/hantro_g1_vp8_dec.c
b/drivers/staging/media/hantro/hantro_g1_vp8_dec.c
index 2afd5996d75f..6180b23e7d94 100644
--- a/drivers/staging/media/hantro/hantro_g1_vp8_dec.c
+++ b/drivers/staging/media/hantro/hantro_g1_vp8_dec.c
@@ -367,13 +367,12 @@ static void cfg_tap(struct hantro_ctx *ctx,
}
static void cfg_ref(struct hantro_ctx *ctx,
- const struct v4l2_ctrl_vp8_frame *hdr)
+ const struct v4l2_ctrl_vp8_frame *hdr,
+ struct vb2_v4l2_buffer *vb2_dst)
{
struct hantro_dev *vpu = ctx->dev;
- struct vb2_v4l2_buffer *vb2_dst;
dma_addr_t ref;
- vb2_dst = hantro_get_dst_buf(ctx);
ref = hantro_get_ref(ctx, hdr->last_frame_ts);
if (!ref) {
@@ -405,16 +404,14 @@ static void cfg_ref(struct hantro_ctx *ctx,
}
static void cfg_buffers(struct hantro_ctx *ctx,
- const struct v4l2_ctrl_vp8_frame *hdr)
+ const struct v4l2_ctrl_vp8_frame *hdr,
+ struct vb2_v4l2_buffer *vb2_dst)
{
const struct v4l2_vp8_segment *seg = &hdr->segment;
struct hantro_dev *vpu = ctx->dev;
- struct vb2_v4l2_buffer *vb2_dst;
dma_addr_t dst_dma;
u32 reg;
- vb2_dst = hantro_get_dst_buf(ctx);
-
/* Set probability table buffer address */
vdpu_write_relaxed(vpu, ctx->vp8_dec.prob_tbl.dma,
G1_REG_ADDR_QTABLE);
@@ -436,6 +433,7 @@ int hantro_g1_vp8_dec_run(struct hantro_ctx *ctx)
{
const struct v4l2_ctrl_vp8_frame *hdr;
struct hantro_dev *vpu = ctx->dev;
+ struct vb2_v4l2_buffer *vb2_dst;
size_t height = ctx->dst_fmt.height;
size_t width = ctx->dst_fmt.width;
u32 mb_width, mb_height;
@@ -499,8 +497,10 @@ int hantro_g1_vp8_dec_run(struct hantro_ctx *ctx)
cfg_qp(ctx, hdr);
[PATCH 12/12] media: hantro: Add support for the Rockchip PX30
From: Paul Kocialkowski
The PX30 SoC includes both the VDPU2 and VEPU2 blocks which are similar
to the RK3399 (Hantro G1/H1 with shuffled registers).
Signed-off-by: Paul Kocialkowski
Signed-off-by: Ezequiel Garcia
---
drivers/staging/media/hantro/hantro_drv.c | 1 +
drivers/staging/media/hantro/hantro_hw.h | 1 +
.../staging/media/hantro/rockchip_vpu_hw.c| 28 +++
3 files changed, 30 insertions(+)
diff --git a/drivers/staging/media/hantro/hantro_drv.c
b/drivers/staging/media/hantro/hantro_drv.c
index 9b5415176bfe..8a2edd67f2c6 100644
--- a/drivers/staging/media/hantro/hantro_drv.c
+++ b/drivers/staging/media/hantro/hantro_drv.c
@@ -582,6 +582,7 @@ static const struct v4l2_file_operations hantro_fops = {
static const struct of_device_id of_hantro_match[] = {
#ifdef CONFIG_VIDEO_HANTRO_ROCKCHIP
+ { .compatible = "rockchip,px30-vpu", .data = &px30_vpu_variant, },
{ .compatible = "rockchip,rk3036-vpu", .data = &rk3036_vpu_variant, },
{ .compatible = "rockchip,rk3066-vpu", .data = &rk3066_vpu_variant, },
{ .compatible = "rockchip,rk3288-vpu", .data = &rk3288_vpu_variant, },
diff --git a/drivers/staging/media/hantro/hantro_hw.h
b/drivers/staging/media/hantro/hantro_hw.h
index 9296624654a6..df7b5e3a57b9 100644
--- a/drivers/staging/media/hantro/hantro_hw.h
+++ b/drivers/staging/media/hantro/hantro_hw.h
@@ -209,6 +209,7 @@ enum hantro_enc_fmt {
extern const struct hantro_variant imx8mq_vpu_g2_variant;
extern const struct hantro_variant imx8mq_vpu_variant;
+extern const struct hantro_variant px30_vpu_variant;
extern const struct hantro_variant rk3036_vpu_variant;
extern const struct hantro_variant rk3066_vpu_variant;
extern const struct hantro_variant rk3288_vpu_variant;
diff --git a/drivers/staging/media/hantro/rockchip_vpu_hw.c
b/drivers/staging/media/hantro/rockchip_vpu_hw.c
index e4e3b5e7689b..e7f56e30b4a8 100644
--- a/drivers/staging/media/hantro/rockchip_vpu_hw.c
+++ b/drivers/staging/media/hantro/rockchip_vpu_hw.c
@@ -16,6 +16,7 @@
#define RK3066_ACLK_MAX_FREQ (300 * 1000 * 1000)
#define RK3288_ACLK_MAX_FREQ (400 * 1000 * 1000)
+#define PX30_ACLK_MAX_FREQ (300 * 1000 * 1000)
/*
* Supported formats.
@@ -279,6 +280,12 @@ static int rockchip_vpu_hw_init(struct hantro_dev *vpu)
return 0;
}
+static int px30_vpu_hw_init(struct hantro_dev *vpu)
+{
+ clk_set_rate(vpu->clocks[0].clk, PX30_ACLK_MAX_FREQ);
+ return 0;
+}
+
static void rk3066_vpu_dec_reset(struct hantro_ctx *ctx)
{
struct hantro_dev *vpu = ctx->dev;
@@ -452,6 +459,10 @@ static const char * const rockchip_vpu_clk_names[] = {
"aclk", "hclk"
};
+static const char * const px30_clk_names[] = {
+ "aclk", "hclk"
+};
+
/* VDPU1/VEPU1 */
const struct hantro_variant rk3036_vpu_variant = {
@@ -548,3 +559,20 @@ const struct hantro_variant rk3399_vpu_variant = {
.clk_names = rockchip_vpu_clk_names,
.num_clocks = ARRAY_SIZE(rockchip_vpu_clk_names)
};
+
+const struct hantro_variant px30_vpu_variant = {
+ .enc_offset = 0x0,
+ .enc_fmts = rockchip_vpu_enc_fmts,
+ .num_enc_fmts = ARRAY_SIZE(rockchip_vpu_enc_fmts),
+ .dec_offset = 0x400,
+ .dec_fmts = rk3399_vpu_dec_fmts,
+ .num_dec_fmts = ARRAY_SIZE(rk3399_vpu_dec_fmts),
+ .codec = HANTRO_JPEG_ENCODER | HANTRO_MPEG2_DECODER |
+HANTRO_VP8_DECODER | HANTRO_H264_DECODER,
+ .codec_ops = rk3399_vpu_codec_ops,
+ .irqs = rockchip_vpu2_irqs,
+ .num_irqs = ARRAY_SIZE(rockchip_vpu2_irqs),
+ .init = px30_vpu_hw_init,
+ .clk_names = px30_clk_names,
+ .num_clocks = ARRAY_SIZE(px30_clk_names)
+};
--
2.30.0
[PATCH 06/12] media: hantro: h264: Move DPB valid and long-term bitmaps
In order to reuse these bitmaps, move this process to
struct hantro_h264_dec_hw_ctx. This will be used by
the Rockchip VDPU2 H.264 driver.
Signed-off-by: Ezequiel Garcia
---
.../staging/media/hantro/hantro_g1_h264_dec.c | 17 ++---
drivers/staging/media/hantro/hantro_h264.c | 13 +
drivers/staging/media/hantro/hantro_hw.h| 4
3 files changed, 19 insertions(+), 15 deletions(-)
diff --git a/drivers/staging/media/hantro/hantro_g1_h264_dec.c
b/drivers/staging/media/hantro/hantro_g1_h264_dec.c
index 2aa37baad0c3..6faacfc44c7c 100644
--- a/drivers/staging/media/hantro/hantro_g1_h264_dec.c
+++ b/drivers/staging/media/hantro/hantro_g1_h264_dec.c
@@ -129,25 +129,12 @@ static void set_ref(struct hantro_ctx *ctx)
struct v4l2_h264_dpb_entry *dpb = ctx->h264_dec.dpb;
const u8 *b0_reflist, *b1_reflist, *p_reflist;
struct hantro_dev *vpu = ctx->dev;
- u32 dpb_longterm = 0;
- u32 dpb_valid = 0;
int reg_num;
u32 reg;
int i;
- /*
-* Set up bit maps of valid and long term DPBs.
-* NOTE: The bits are reversed, i.e. MSb is DPB 0.
-*/
- for (i = 0; i < HANTRO_H264_DPB_SIZE; ++i) {
- if (dpb[i].flags & V4L2_H264_DPB_ENTRY_FLAG_ACTIVE)
- dpb_valid |= BIT(HANTRO_H264_DPB_SIZE - 1 - i);
-
- if (dpb[i].flags & V4L2_H264_DPB_ENTRY_FLAG_LONG_TERM)
- dpb_longterm |= BIT(HANTRO_H264_DPB_SIZE - 1 - i);
- }
- vdpu_write_relaxed(vpu, dpb_valid << 16, G1_REG_VALID_REF);
- vdpu_write_relaxed(vpu, dpb_longterm << 16, G1_REG_LT_REF);
+ vdpu_write_relaxed(vpu, ctx->h264_dec.dpb_valid, G1_REG_VALID_REF);
+ vdpu_write_relaxed(vpu, ctx->h264_dec.dpb_longterm, G1_REG_LT_REF);
/*
* Set up reference frame picture numbers.
diff --git a/drivers/staging/media/hantro/hantro_h264.c
b/drivers/staging/media/hantro/hantro_h264.c
index ed6eaf11d96f..6d72136760e7 100644
--- a/drivers/staging/media/hantro/hantro_h264.c
+++ b/drivers/staging/media/hantro/hantro_h264.c
@@ -229,12 +229,25 @@ static void prepare_table(struct hantro_ctx *ctx)
const struct v4l2_ctrl_h264_decode_params *dec_param = ctrls->decode;
struct hantro_h264_dec_priv_tbl *tbl = ctx->h264_dec.priv.cpu;
const struct v4l2_h264_dpb_entry *dpb = ctx->h264_dec.dpb;
+ u32 dpb_longterm = 0;
+ u32 dpb_valid = 0;
int i;
for (i = 0; i < HANTRO_H264_DPB_SIZE; ++i) {
tbl->poc[i * 2] = dpb[i].top_field_order_cnt;
tbl->poc[i * 2 + 1] = dpb[i].bottom_field_order_cnt;
+
+ /*
+* Set up bit maps of valid and long term DPBs.
+* NOTE: The bits are reversed, i.e. MSb is DPB 0.
+*/
+ if (dpb[i].flags & V4L2_H264_DPB_ENTRY_FLAG_ACTIVE)
+ dpb_valid |= BIT(HANTRO_H264_DPB_SIZE - 1 - i);
+ if (dpb[i].flags & V4L2_H264_DPB_ENTRY_FLAG_LONG_TERM)
+ dpb_longterm |= BIT(HANTRO_H264_DPB_SIZE - 1 - i);
}
+ ctx->h264_dec.dpb_valid = dpb_valid << 16;
+ ctx->h264_dec.dpb_longterm = dpb_longterm << 16;
tbl->poc[32] = dec_param->top_field_order_cnt;
tbl->poc[33] = dec_param->bottom_field_order_cnt;
diff --git a/drivers/staging/media/hantro/hantro_hw.h
b/drivers/staging/media/hantro/hantro_hw.h
index 5dcf65805396..ce678fedaad6 100644
--- a/drivers/staging/media/hantro/hantro_hw.h
+++ b/drivers/staging/media/hantro/hantro_hw.h
@@ -89,12 +89,16 @@ struct hantro_h264_dec_reflists {
* @dpb: DPB
* @reflists: P/B0/B1 reflists
* @ctrls: V4L2 controls attached to a run
+ * @dpb_longterm: DPB long-term
+ * @dpb_valid: DPB valid
*/
struct hantro_h264_dec_hw_ctx {
struct hantro_aux_buf priv;
struct v4l2_h264_dpb_entry dpb[HANTRO_H264_DPB_SIZE];
struct hantro_h264_dec_reflists reflists;
struct hantro_h264_dec_ctrls ctrls;
+ u32 dpb_longterm;
+ u32 dpb_valid;
};
/**
--
2.30.0
[PATCH 03/12] hantro: vp8: Move noisy WARN_ON to vpu_debug
When the VP8 decoders can't find a reference frame,
the driver falls back to the current output frame.
This will probably produce some undesirable results,
leading to frame corruption, but shouldn't cause
noisy warnings.
Signed-off-by: Ezequiel Garcia
Acked-by: Nicolas Dufresne
---
drivers/staging/media/hantro/hantro_g1_vp8_dec.c| 13 ++---
.../staging/media/hantro/rockchip_vpu2_hw_vp8_dec.c | 13 ++---
2 files changed, 20 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/media/hantro/hantro_g1_vp8_dec.c
b/drivers/staging/media/hantro/hantro_g1_vp8_dec.c
index 96622a7f8279..2afd5996d75f 100644
--- a/drivers/staging/media/hantro/hantro_g1_vp8_dec.c
+++ b/drivers/staging/media/hantro/hantro_g1_vp8_dec.c
@@ -376,12 +376,17 @@ static void cfg_ref(struct hantro_ctx *ctx,
vb2_dst = hantro_get_dst_buf(ctx);
ref = hantro_get_ref(ctx, hdr->last_frame_ts);
- if (!ref)
+ if (!ref) {
+ vpu_debug(0, "failed to find last frame ts=%llu\n",
+ hdr->last_frame_ts);
ref = vb2_dma_contig_plane_dma_addr(&vb2_dst->vb2_buf, 0);
+ }
vdpu_write_relaxed(vpu, ref, G1_REG_ADDR_REF(0));
ref = hantro_get_ref(ctx, hdr->golden_frame_ts);
- WARN_ON(!ref && hdr->golden_frame_ts);
+ if (!ref && hdr->golden_frame_ts)
+ vpu_debug(0, "failed to find golden frame ts=%llu\n",
+ hdr->golden_frame_ts);
if (!ref)
ref = vb2_dma_contig_plane_dma_addr(&vb2_dst->vb2_buf, 0);
if (hdr->flags & V4L2_VP8_FRAME_FLAG_SIGN_BIAS_GOLDEN)
@@ -389,7 +394,9 @@ static void cfg_ref(struct hantro_ctx *ctx,
vdpu_write_relaxed(vpu, ref, G1_REG_ADDR_REF(4));
ref = hantro_get_ref(ctx, hdr->alt_frame_ts);
- WARN_ON(!ref && hdr->alt_frame_ts);
+ if (!ref && hdr->alt_frame_ts)
+ vpu_debug(0, "failed to find alt frame ts=%llu\n",
+ hdr->alt_frame_ts);
if (!ref)
ref = vb2_dma_contig_plane_dma_addr(&vb2_dst->vb2_buf, 0);
if (hdr->flags & V4L2_VP8_FRAME_FLAG_SIGN_BIAS_ALT)
diff --git a/drivers/staging/media/hantro/rockchip_vpu2_hw_vp8_dec.c
b/drivers/staging/media/hantro/rockchip_vpu2_hw_vp8_dec.c
index 951b55f58a61..704607511b57 100644
--- a/drivers/staging/media/hantro/rockchip_vpu2_hw_vp8_dec.c
+++ b/drivers/staging/media/hantro/rockchip_vpu2_hw_vp8_dec.c
@@ -453,12 +453,17 @@ static void cfg_ref(struct hantro_ctx *ctx,
vb2_dst = hantro_get_dst_buf(ctx);
ref = hantro_get_ref(ctx, hdr->last_frame_ts);
- if (!ref)
+ if (!ref) {
+ vpu_debug(0, "failed to find last frame ts=%llu\n",
+ hdr->last_frame_ts);
ref = vb2_dma_contig_plane_dma_addr(&vb2_dst->vb2_buf, 0);
+ }
vdpu_write_relaxed(vpu, ref, VDPU_REG_VP8_ADDR_REF0);
ref = hantro_get_ref(ctx, hdr->golden_frame_ts);
- WARN_ON(!ref && hdr->golden_frame_ts);
+ if (!ref && hdr->golden_frame_ts)
+ vpu_debug(0, "failed to find golden frame ts=%llu\n",
+ hdr->golden_frame_ts);
if (!ref)
ref = vb2_dma_contig_plane_dma_addr(&vb2_dst->vb2_buf, 0);
if (hdr->flags & V4L2_VP8_FRAME_FLAG_SIGN_BIAS_GOLDEN)
@@ -466,7 +471,9 @@ static void cfg_ref(struct hantro_ctx *ctx,
vdpu_write_relaxed(vpu, ref, VDPU_REG_VP8_ADDR_REF2_5(2));
ref = hantro_get_ref(ctx, hdr->alt_frame_ts);
- WARN_ON(!ref && hdr->alt_frame_ts);
+ if (!ref && hdr->alt_frame_ts)
+ vpu_debug(0, "failed to find alt frame ts=%llu\n",
+ hdr->alt_frame_ts);
if (!ref)
ref = vb2_dma_contig_plane_dma_addr(&vb2_dst->vb2_buf, 0);
if (hdr->flags & V4L2_VP8_FRAME_FLAG_SIGN_BIAS_ALT)
--
2.30.0
[PATCH 01/12] drm/panel: kd35t133: Add panel orientation support
Parse the device tree rotation specifier, and set a DRM
connector orientation property. The property can then be read
by compositors to apply hardware plane rotation or a GPU transform.
Signed-off-by: Ezequiel Garcia
---
drivers/gpu/drm/panel/panel-elida-kd35t133.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-elida-kd35t133.c
b/drivers/gpu/drm/panel/panel-elida-kd35t133.c
index fe5ac3ef9018..5987d28c874c 100644
--- a/drivers/gpu/drm/panel/panel-elida-kd35t133.c
+++ b/drivers/gpu/drm/panel/panel-elida-kd35t133.c
@@ -39,6 +39,7 @@
struct kd35t133 {
struct device *dev;
struct drm_panel panel;
+ enum drm_panel_orientation orientation;
struct gpio_desc *reset_gpio;
struct regulator *vdd;
struct regulator *iovcc;
@@ -216,6 +217,7 @@ static int kd35t133_get_modes(struct drm_panel *panel,
connector->display_info.width_mm = mode->width_mm;
connector->display_info.height_mm = mode->height_mm;
drm_mode_probed_add(connector, mode);
+ drm_connector_set_panel_orientation(connector, ctx->orientation);
return 1;
}
@@ -258,6 +260,12 @@ static int kd35t133_probe(struct mipi_dsi_device *dsi)
return ret;
}
+ ret = of_drm_get_panel_orientation(dev->of_node, &ctx->orientation);
+ if (ret) {
+ dev_err(dev, "%pOF: failed to get orientation %d\n",
dev->of_node, ret);
+ return ret;
+ }
+
mipi_dsi_set_drvdata(dsi, ctx);
ctx->dev = dev;
--
2.30.0
[PATCH 00/12] hantro: Enable H.264 VDPU2 (Odroid Advance Go)
This series adds support for H.264 decoding on the PX30, RK3328
and RK3326 platforms, enabling the VDPU2 core.
Given it's tested on the Odroid Advance Go, patches 1 and 2
add the basic support to report the panel orientation to
userspace (Heiko, if you like them, feel free to pick them).
Weston (for instance) picks up the orientation automagically
and rotates the render.
Patches 3 and 4 are just low-hanging fruit that was on my backlog.
Patches 5, 6 and 7 add some helpers to avoid duplicating some processes
between Hantro G1 and VDPU2. Patches 8 and 9 enable the VDPU2 H.264.
The implementation is based on a patch from Jonas Karlman [1], which
I forwarded ported to mainline.
Finally, patches 10 to 12 add support for the VPU on Rockchip PX30 SoCs.
These patches are based on patches submitted by Paul Kocialkowski [2],
which I ported and adjusted a bit.
Tested on i.MX8MQ EVK and RK3326 Odroid Advance Go, the latter
is able to decode a 1080p sample at ~100fps nicely.
Fluster conformance testing is looking good as well, and producing
expected results:
RK3326:
Ran 135 tests in 480.067s
FAILED (failures=9, errors=54)
i.MX8MQ:
Ran 135 tests in 337.491s
FAILED (failures=9, errors=54)
[1]
https://lore.kernel.org/linux-media/he1pr06mb40119de07d38060f531d1070ac...@he1pr06mb4011.eurprd06.prod.outlook.com/
[2] https://lore.kernel.org/patchwork/cover/1361795/
Ezequiel Garcia (8):
drm/panel: kd35t133: Add panel orientation support
arm64: dts: rockchip: Add panel orientation to Odroid Go Advance
hantro: vp8: Move noisy WARN_ON to vpu_debug
hantro: Make struct hantro_variant.init() optional
media: hantro: Avoid redundant hantro_get_{dst,src}_buf() calls
media: hantro: h264: Move DPB valid and long-term bitmaps
media: hantro: h264: Move reference picture number to a helper
media: hantro: Enable H.264 on Rockchip VDPU2
Jonas Karlman (1):
media: hantro: Add H.264 support for Rockchip VDPU2
Paul Kocialkowski (3):
dt-bindings: media: rockchip-vpu: Add PX30 compatible
arm64: dts: rockchip: Add VPU support for the PX30
media: hantro: Add support for the Rockchip PX30
.../bindings/media/rockchip-vpu.yaml | 3 +
arch/arm64/boot/dts/rockchip/px30.dtsi| 23 +
.../boot/dts/rockchip/rk3326-odroid-go2.dts | 1 +
drivers/gpu/drm/panel/panel-elida-kd35t133.c | 8 +
drivers/staging/media/hantro/Makefile | 1 +
drivers/staging/media/hantro/hantro.h | 4 +-
drivers/staging/media/hantro/hantro_drv.c | 11 +-
.../staging/media/hantro/hantro_g1_h264_dec.c | 48 +-
.../staging/media/hantro/hantro_g1_vp8_dec.c | 31 +-
drivers/staging/media/hantro/hantro_h264.c| 24 +
drivers/staging/media/hantro/hantro_hw.h | 8 +
.../media/hantro/rockchip_vpu2_hw_h264_dec.c | 491 ++
.../media/hantro/rockchip_vpu2_hw_vp8_dec.c | 32 +-
.../staging/media/hantro/rockchip_vpu_hw.c| 54 +-
.../staging/media/hantro/sama5d4_vdec_hw.c| 6 -
15 files changed, 671 insertions(+), 74 deletions(-)
create mode 100644 drivers/staging/media/hantro/rockchip_vpu2_hw_h264_dec.c
--
2.30.0
Re: [PATCH v13 0/4] drm/panfrost: Add support for mt8183 GPU
Hi Neil, On Mon, 26 Apr 2021 at 06:59, Neil Armstrong wrote: > > Hi, > > On 21/04/2021 07:28, Nicolas Boichat wrote: > > Hi! > > > > This is just a rebase of the v11, untested (but it seems like > > Neil Armstrong recently tested it), with small changes in > > binding and dts. v11 cover follows: > > > > Follow-up on the v5 [1], things have gotten significantly > > better in the last year, thanks to the efforts on Bifrost > > support by the Collabora team (and probably others I'm not > > aware of). > > > > I've been testing this series on a MT8183/kukui device, with a > > chromeos-5.10 kernel [2], and got basic Chromium OS UI up with > > mesa 20.3.2 (lots of artifacts though). > > > > devfreq is currently not supported, as we'll need: > > - Clock core support for switching the GPU core clock (see 2/4). > > - Platform-specific handling of the 2-regulator (see 3/4). > > > > Since the latter is easy to detect, patch 3/4 just disables > > devfreq if the more than one regulator is specified in the > > compatible matching table. > > > > [1] > > https://patchwork.kernel.org/project/linux-mediatek/cover/20200306041345.259332-1-drink...@chromium.org/ > > [2] https://crrev.com/c/2608070 > > > > Changes in v13: > > - devfreq: Fix conflict resolution mistake when rebasing, didn't > >even compile. Oops. > > > > Changes in v12: > > - binding: Fix min/maxItems logic (Rob Herring) > > - Add gpu node to mt8183-pumpkin.dts as well (Neil Armstrong). > > > > Changes in v11: > > - binding: power-domain-names not power-domainS-names > > - mt8183*.dts: remove incorrect supply-names > > > > Changes in v10: > > - Fix the binding to make sure sram-supply property can be provided. > > > > Changes in v9: > > - Explain why devfreq needs to be disabled for GPUs with >1 > >regulators. > > > > Changes in v8: > > - Use DRM_DEV_INFO instead of ERROR > > > > Changes in v7: > > - Fix GPU ID in commit message > > - Fix GPU ID in commit message > > > > Changes in v6: > > - Rebased, actually tested with recent mesa driver. > > - Add gpu regulators to kukui dtsi as well. > > - Power domains are now attached to spm, not scpsys > > - Drop R-B. > > - devfreq: New change > > - Context conflicts, reflow the code. > > - Use ARRAY_SIZE for power domains too. > > > > Changes in v5: > > - Rename "2d" power domain to "core2" > > - Rename "2d" power domain to "core2" (keep R-B again). > > - Change power domain name from 2d to core2. > > > > Changes in v4: > > - Add power-domain-names description > >(kept Alyssa's reviewed-by as the change is minor) > > - Add power-domain-names to describe the 3 domains. > >(kept Alyssa's reviewed-by as the change is minor) > > - Add power domain names. > > > > Changes in v3: > > - Match mt8183-mali instead of bifrost, as we require special > >handling for the 2 regulators and 3 power domains. > > > > Changes in v2: > > - Use sram instead of mali_sram as SRAM supply name. > > - Rename mali@ to gpu@. > > > > Nicolas Boichat (4): > > dt-bindings: gpu: mali-bifrost: Add Mediatek MT8183 > > arm64: dts: mt8183: Add node for the Mali GPU > > drm/panfrost: devfreq: Disable devfreq when num_supplies > 1 > > drm/panfrost: Add mt8183-mali compatible string > > > > .../bindings/gpu/arm,mali-bifrost.yaml| 30 - > > arch/arm64/boot/dts/mediatek/mt8183-evb.dts | 5 + > > .../arm64/boot/dts/mediatek/mt8183-kukui.dtsi | 5 + > > .../boot/dts/mediatek/mt8183-pumpkin.dts | 5 + > > arch/arm64/boot/dts/mediatek/mt8183.dtsi | 105 ++ > > drivers/gpu/drm/panfrost/panfrost_devfreq.c | 9 ++ > > drivers/gpu/drm/panfrost/panfrost_drv.c | 10 ++ > > 7 files changed, 168 insertions(+), 1 deletion(-) > > > > Seems this version is ready to be applied if we get a review on the DT ? > > Mathias ? could you have a look ? > Given Rob has Acked the DT bindings, I think it's OK to apply patches 1, 3 and 4 via drm-misc, letting Mediatek people sort out the DT changes. My two unsolicited cents :-) Ezequiel
Re: [PATCH] drm/panel: kd35t133: allow using non-continuous dsi clock
On Sat, 6 Feb 2021 at 10:50, Heiko Stuebner wrote:
>
> The panel is able to work when dsi clock is non-continuous, thus
> the system power consumption can be reduced using such feature.
>
> Add MIPI_DSI_CLOCK_NON_CONTINUOUS to panel's mode_flags.
>
> Also the flag actually becomes necessary after
> commit c6d94e37bdbb ("drm/bridge/synopsys: dsi: add support for
> non-continuous HS clock")
> and without it the panel only emits stripes instead of output.
>
Looks like c6d94e37bdbb landed in v5.10, so we should add:
Fixes: c6d94e37bdbb ("drm/bridge/synopsys: dsi: add support for
non-continuous HS clock")
Cc: sta...@vger.kernel.org # 5.10+
With this fix, my Odroid Go2 has display.
Tested-by: Ezequiel Garcia
Thanks,
Ezequiel
> Signed-off-by: Heiko Stuebner
> ---
> drivers/gpu/drm/panel/panel-elida-kd35t133.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/panel/panel-elida-kd35t133.c
> b/drivers/gpu/drm/panel/panel-elida-kd35t133.c
> index bc36aa3c1123..fe5ac3ef9018 100644
> --- a/drivers/gpu/drm/panel/panel-elida-kd35t133.c
> +++ b/drivers/gpu/drm/panel/panel-elida-kd35t133.c
> @@ -265,7 +265,8 @@ static int kd35t133_probe(struct mipi_dsi_device *dsi)
> dsi->lanes = 1;
> dsi->format = MIPI_DSI_FMT_RGB888;
> dsi->mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_BURST |
> - MIPI_DSI_MODE_LPM | MIPI_DSI_MODE_EOT_PACKET;
> + MIPI_DSI_MODE_LPM | MIPI_DSI_MODE_EOT_PACKET |
> + MIPI_DSI_CLOCK_NON_CONTINUOUS;
>
> drm_panel_init(&ctx->panel, &dsi->dev, &kd35t133_funcs,
>DRM_MODE_CONNECTOR_DSI);
> --
> 2.29.2
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> 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] drm/panel: elida-kd35t133: allow using non-continuous dsi clock
On Fri, 19 Feb 2021 at 00:14, Chris Morgan wrote:
>
> This fixes an issue with the panel not working after
> commit c6d94e37bdbb ("drm/bridge/synopsys: dsi: add support for
> non-continuous HS clock").
> With this change the panel inits successfully and displays an image.
>
> Signed-off-by: Chris Morgan
> ---
> drivers/gpu/drm/panel/panel-elida-kd35t133.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/panel/panel-elida-kd35t133.c
> b/drivers/gpu/drm/panel/panel-elida-kd35t133.c
> index bc36aa3c1123..fe5ac3ef9018 100644
> --- a/drivers/gpu/drm/panel/panel-elida-kd35t133.c
> +++ b/drivers/gpu/drm/panel/panel-elida-kd35t133.c
> @@ -265,7 +265,8 @@ static int kd35t133_probe(struct mipi_dsi_device *dsi)
> dsi->lanes = 1;
> dsi->format = MIPI_DSI_FMT_RGB888;
> dsi->mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_BURST |
> - MIPI_DSI_MODE_LPM | MIPI_DSI_MODE_EOT_PACKET;
> + MIPI_DSI_MODE_LPM | MIPI_DSI_MODE_EOT_PACKET |
> + MIPI_DSI_CLOCK_NON_CONTINUOUS;
>
> drm_panel_init(&ctx->panel, &dsi->dev, &kd35t133_funcs,
>DRM_MODE_CONNECTOR_DSI);
> --
> 2.25.1
>
I kindly appreciate you taking the time to debug this one.
It looks good, but also seems like Heiko already sent the same fix:
https://www.spinics.net/lists/kernel/msg3824932.html
Thanks,
Eze
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Odroid GO Advance display in mainline (Re: [PATCH 1/2] drm/panel: add rotation support for Elida KD35T133 panels)
(Now with Heiko's address fixed)
On Sat, 13 Feb 2021 at 10:53, Ezequiel Garcia
wrote:
>
> Hi Chris,
>
> I'm hijacking this discussion a bit.
>
> I recently tried to boot maline on my Odroid GOA, which I managed to do,
> except the display wasn't displaying anything :-)
>
> Everything looks good on a quick look, the Inno PHY driver is here,
> and there's a DRM card registered with the right mode 320x240 and
> connected status (which I suppose doesn't mean much in this case).
> Also, the backlight is on.
>
> Looks like this is working for you, so I was wondering if maybe
> this would ring a bell, or perhaps you're aware of any patches
> we are missing in v5.11-rc7 (which is what I'm basing on).
> Or maybe I'm missing some config?...
>
> Any ideas would be welcome!
>
> Ezequiel
>
> On Fri, 12 Feb 2021 at 12:51, Chris Morgan wrote:
> >
> > Update the panel to allow setting the rotation value in device tree.
> >
> > Signed-off-by: Chris Morgan
> > ---
> > drivers/gpu/drm/panel/panel-elida-kd35t133.c | 8
> > 1 file changed, 8 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/panel/panel-elida-kd35t133.c
> > b/drivers/gpu/drm/panel/panel-elida-kd35t133.c
> > index bc36aa3c1123..d8534406d1ef 100644
> > --- a/drivers/gpu/drm/panel/panel-elida-kd35t133.c
> > +++ b/drivers/gpu/drm/panel/panel-elida-kd35t133.c
> > @@ -42,6 +42,7 @@ struct kd35t133 {
> > struct gpio_desc *reset_gpio;
> > struct regulator *vdd;
> > struct regulator *iovcc;
> > + enum drm_panel_orientation orientation;
> > bool prepared;
> > };
> >
> > @@ -216,6 +217,7 @@ static int kd35t133_get_modes(struct drm_panel *panel,
> > connector->display_info.width_mm = mode->width_mm;
> > connector->display_info.height_mm = mode->height_mm;
> > drm_mode_probed_add(connector, mode);
> > + drm_connector_set_panel_orientation(connector, ctx->orientation);
> >
> > return 1;
> > }
> > @@ -258,6 +260,12 @@ static int kd35t133_probe(struct mipi_dsi_device *dsi)
> > return ret;
> > }
> >
> > + ret = of_drm_get_panel_orientation(dev->of_node, &ctx->orientation);
> > + if (ret < 0) {
> > + dev_err(dev, "%pOF: failed to get orientation %d\n",
> > dev->of_node, ret);
> > + return ret;
> > + }
> > +
> > mipi_dsi_set_drvdata(dsi, ctx);
> >
> > ctx->dev = dev;
> > --
> > 2.25.1
> >
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > 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
Odroid GO Advance display in mainline (Re: [PATCH 1/2] drm/panel: add rotation support for Elida KD35T133 panels)
Hi Chris,
I'm hijacking this discussion a bit.
I recently tried to boot maline on my Odroid GOA, which I managed to do,
except the display wasn't displaying anything :-)
Everything looks good on a quick look, the Inno PHY driver is here,
and there's a DRM card registered with the right mode 320x240 and
connected status (which I suppose doesn't mean much in this case).
Also, the backlight is on.
Looks like this is working for you, so I was wondering if maybe
this would ring a bell, or perhaps you're aware of any patches
we are missing in v5.11-rc7 (which is what I'm basing on).
Or maybe I'm missing some config?...
Any ideas would be welcome!
Ezequiel
On Fri, 12 Feb 2021 at 12:51, Chris Morgan wrote:
>
> Update the panel to allow setting the rotation value in device tree.
>
> Signed-off-by: Chris Morgan
> ---
> drivers/gpu/drm/panel/panel-elida-kd35t133.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/gpu/drm/panel/panel-elida-kd35t133.c
> b/drivers/gpu/drm/panel/panel-elida-kd35t133.c
> index bc36aa3c1123..d8534406d1ef 100644
> --- a/drivers/gpu/drm/panel/panel-elida-kd35t133.c
> +++ b/drivers/gpu/drm/panel/panel-elida-kd35t133.c
> @@ -42,6 +42,7 @@ struct kd35t133 {
> struct gpio_desc *reset_gpio;
> struct regulator *vdd;
> struct regulator *iovcc;
> + enum drm_panel_orientation orientation;
> bool prepared;
> };
>
> @@ -216,6 +217,7 @@ static int kd35t133_get_modes(struct drm_panel *panel,
> connector->display_info.width_mm = mode->width_mm;
> connector->display_info.height_mm = mode->height_mm;
> drm_mode_probed_add(connector, mode);
> + drm_connector_set_panel_orientation(connector, ctx->orientation);
>
> return 1;
> }
> @@ -258,6 +260,12 @@ static int kd35t133_probe(struct mipi_dsi_device *dsi)
> return ret;
> }
>
> + ret = of_drm_get_panel_orientation(dev->of_node, &ctx->orientation);
> + if (ret < 0) {
> + dev_err(dev, "%pOF: failed to get orientation %d\n",
> dev->of_node, ret);
> + return ret;
> + }
> +
> mipi_dsi_set_drvdata(dsi, ctx);
>
> ctx->dev = dev;
> --
> 2.25.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> 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 1/4] drm: Add Keem Bay VPU codec DRM
Hello everyone, (Adding some Hantro developers) On Fri, 9 Oct 2020 at 19:15, Daniel Vetter wrote: > > On Fri, Oct 09, 2020 at 07:57:52PM +0800, kuhanh.murugasen.krish...@intel.com > wrote: > > From: "Murugasen Krishnan, Kuhanh" > > > > This is a new DRM media codec driver for Intel's Keem Bay SOC which > > integrates the Verisilicon's Hantro Video Processor Unit (VPU) IP. > > The SoC couples an ARM Cortex A53 CPU with an Intel Movidius VPU. > > > > Hantro VPU IP is a series of video decoder and encoder semiconductor IP > > cores, > > which can be flexibly configured for video surveillance, multimedia consumer > > products, Internet of Things, cloud service products, data centers, aerial > > photography and recorders, thereby providing video transcoding and > > multi-channel > > HD video encoding and decoding. > > > > Hantro VPU IP consists of Hantro VC8000D for decoder and Hantro VC8000E for > > encoder. > > Before you guys even start reviewing or discussing this: good news everyone! Verisilicon Hantro VPU support is in mainline since a few releases now. How about you run a quick "git grep hantro -- drivers/" and see for yourself :-) ? Spoiler alert: we currently support G1 core, supporting MPEG-2, H.264, VP8 and some post-processor features. We are working on G2 for HEVC and VP9, and we have patches ready for VC8000D for H264. Given the VPU is stateless, it requires quite a bit of work on the application side. There are implementations in GStreamer (see v4l2codecs plugin), Chromium, and Ffmpeg. Given all the stateless codec drivers depend on the stateless controls APIs, and given this API is still marked as experimental/unstable, the drivers are in staging. Other than this, these drivers are just as good as any, and have been shipped for quite some time now. I expect to move them out of staging soon, just as soon as we clean and stabilize this control API. I will be happy to review patches adding Keem Bay support, to be honest, unsure what that implies, but we'll see. Thanks, Ezequiel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: drm/bridge: Synopsys DW-HDMI bridge driver for the Ingenic JZ4780 (was Re: Specialising the Synopsys DW-HDMI bridge driver for the Ingenic JZ4780)
On Thu, 10 Sep 2020 at 04:54, H. Nikolaus Schaller wrote: > > Hi Ezequiel, > > > Am 27.08.2020 um 09:21 schrieb H. Nikolaus Schaller : > > > > Hi Ezequiel, > > > >> Am 24.08.2020 um 19:38 schrieb Ezequiel Garcia > >> : > >> > >> On Mon, 24 Aug 2020 at 13:05, H. Nikolaus Schaller > >> wrote: > >>> > >>> Hi Ezequiel, > >> > >> The fix is just re-organizing the code a bit. Just pushed a possible > >> fix for that (following the IPU handling by Paul Cercueil), > >> please feel free to test this: > >> > >> https://gitlab.collabora.com/linux/0day/-/commits/jz4780-drm-hdmi-module-fix-v5.9-rc2 > > > > Works well (after doing a minor fix to the CI20 defconfig)! > > > >> > >> FWIW, my test setup uses mainline vanilla U-Boot v2020.07. > >> The kernel is loaded via TFTP. Debian mipsel is mounted via NFS > >> (which means dm9000 works). I'm testing with weston and modetest. > >> > >> Note that enabling DRM_INGENIC_IPU will make the driver > >> fail to load, as the IPU is not optional (and not present on ci20.dts). > >> A minor thing to fix. > >> > >> Cheers, > >> Ezequiel > >> > >>> And it seems to differ significantly from what Paul has developed recently > >>> to make it work. It seems to be quite lucky that we have a working setup > >>> now :) > >>> > >>>> Nikolaus, Paul: Do you have plans to submit these? > >>> > >>> Yes, as soon as we are sure that it works (and when it doesn't). > >>> > >>> But thanks to your work it is now much easier to improve things, since we > >>> are no longer looking for a break-through but just have to avoid > >>> regressions. > >>> > >>>> If not, I'll be happy to get them out the door for review. > >>> > >>> Let it mature a little first and have it tested on more setups and rebased > >>> to mainline v5.9-rc2 :) > > > > > >> Am 24.08.2020 um 23:11 schrieb Paul Cercueil : > >> > >> DRM drivers follow their own schedule, you should rebase to drm-misc-next > >> instead. > >> > > > > With the comment from Paul, I think it is best if you push them for review. > > > > My patch set based on v5.9-rc2 is here (including one EFUSE patch which I > > have > > included only for making my Ethernet interface work for testing): > > > > https://git.goldelico.com/?p=letux-kernel.git;a=shortlog;h=refs/heads/letux/jz4780-hdmi-v5 > > > > Please take it, do the required squashes and rebasing and post them for > > discussion to the > > appropriate lists. > > I hope you are well. Do you plan to do the squash and rebase and posts? > Hi Nikolaus, I wanted to use the component API for the the dw hdmi glue driver but somehow it wasn't probing and I haven't had time to debug it. Using the component API consistently would allow to do some cleanups IMHO. Thanks, Ezequiel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
DMA-BUF Heaps BoF notes (Re: [RFC] Experimental DMA-BUF Device Heaps)
Dear all, Here are the notes we took during the BoF. I believe the meeting was super interesting. Although it felt a bit short for the topic, we left with a few interesting ideas. Thanks everyone! Ezequiel --- LPC 2020 BoF: Negotiating DMA-BUF Heaps Attendees: * Brian Starkey * Daniel Stone * Ezequiel Garcia * James Jones * John Reitan * Laura Abbott * Laurent Pinchart * Sumit Semwal * Robert Beckett # Replacing subsystem memory allocators with dma-buf heaps * Laurent: we should not have subsystem implement their own allocator. Using heaps could be a good idea. * Laura: Wary to add too much support to heaps, from the ION experience. * Laurent: V4L2: most drivers use videobuf2, which is a fairly complex piece of code. Three constraints, sg, contig, and vmalloc: these are fairly generic and not video-specific, why can't these just use heaps? * Brian: In-kernel API will most likely just care of dma-buf not necessarily FDs. This was discussed recently, see "Role of DMA Heaps vs GEM in allocation",https://www.spinics.net/lists/dri-devel/msg268103.html * Do we expect to get a non-file descriptor identifier for a dma-buf? No. * Laurent proposes a two steps API (similar to existing GEM API), where we have one interface to allocate a buffer, with an identifier local to a process, and then another interface to wrap the buffer on a dma-buf (fd). * If devices are not meant to be shared, then we might want to avoid the DMA-BUF design entirely. As Sumit mentioned, the fundamental idea behind DMA-BUF is that they are expected to be shared. OTOH, it was mentioned that sometimes we don't know if a buffer will be shared or not, so that's why the ability to wrap a buffer over dma-buf is useful. * New subsytems would possibly want to avoid implementing its own allocator interface. But unfortunately, we don't want to produce a fd per buffer, so that will mean a new subsystem will eventually require its own API (GEM-like). If a subsystem doesn't need many buffers, and the FD semantic is fine, then it would be acceptable to avoid a subsystem-specific API. * It would be interesting to experiment replacing videobuf2-dma-contig with just dma-buf heap usage, and see what kind of code save we'd save. * John Stultz has ideas around providing in-kernel accessors for the heaps - the idea is for drivers to not have to implement full exporter functionality for an already existing dma-buf heap type. * Drawback to this idea of reusing dma-buf heaps to allocate buffers, is that it means marking every buffer that gets exported as shareable. * The benefits in having a centralized implementation would be in unifying the semantics, reusable concepts that can be used to build future APIs around, rather than trying to created unified APIs around disparate kernel allocation APIs at only the userspace level. * Robert: Is there an in-kernel user for the in-kernel dma-buf request? A possible answer would be for scratch buffers. The idea would be to avoid getting details wrong. However, doing this would allow every buffer to be exportable. Also, it sounds like this means re-implementing DMA-API? * DMA-BUF are designed to be shared, not necessarily an allocator. * Want something to expose device-local memory to rest of kernel. Could be a dma-buf heap? ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/2] drm/ingenic: Fix driver not probing when IPU port is missing
Hi Paul,
On Thu, 27 Aug 2020 at 09:04, Paul Cercueil wrote:
>
> Even if support for the IPU was compiled in, we may run on a device
> (e.g. the Qi LB60) where the IPU is not available, or simply with an old
> devicetree without the IPU node. In that case the ingenic-drm refused to
> probe.
>
> Fix the driver so that it will probe even if the IPU node is not present
> in devicetree (but then IPU support is disabled of course).
>
> v2: Take a different approach
>
> Fixes: fc1acf317b01 ("drm/ingenic: Add support for the IPU")
> Signed-off-by: Paul Cercueil
> ---
> drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 19 +++
> 1 file changed, 11 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> index c1bcb93aed2d..b7074161ccf0 100644
> --- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> +++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> @@ -673,7 +673,7 @@ static void ingenic_drm_unbind_all(void *d)
> component_unbind_all(priv->dev, &priv->drm);
> }
>
> -static int ingenic_drm_bind(struct device *dev)
> +static int ingenic_drm_bind(struct device *dev, bool has_components)
> {
> struct platform_device *pdev = to_platform_device(dev);
> const struct jz_soc_info *soc_info;
> @@ -808,7 +808,7 @@ static int ingenic_drm_bind(struct device *dev)
> return ret;
> }
>
> - if (IS_ENABLED(CONFIG_DRM_INGENIC_IPU)) {
> + if (IS_ENABLED(CONFIG_DRM_INGENIC_IPU) && has_components) {
> ret = component_bind_all(dev, drm);
> if (ret) {
> if (ret != -EPROBE_DEFER)
> @@ -939,6 +939,11 @@ static int ingenic_drm_bind(struct device *dev)
> return ret;
> }
>
> +static int ingenic_drm_bind_with_components(struct device *dev)
> +{
> + return ingenic_drm_bind(dev, true);
> +}
> +
> static int compare_of(struct device *dev, void *data)
> {
> return dev->of_node == data;
> @@ -957,7 +962,7 @@ static void ingenic_drm_unbind(struct device *dev)
> }
>
> static const struct component_master_ops ingenic_master_ops = {
> - .bind = ingenic_drm_bind,
> + .bind = ingenic_drm_bind_with_components,
> .unbind = ingenic_drm_unbind,
> };
>
> @@ -968,14 +973,12 @@ static int ingenic_drm_probe(struct platform_device
> *pdev)
> struct device_node *np;
>
> if (!IS_ENABLED(CONFIG_DRM_INGENIC_IPU))
> - return ingenic_drm_bind(dev);
> + return ingenic_drm_bind(dev, false);
>
> /* IPU is at port address 8 */
> np = of_graph_get_remote_node(dev->of_node, 8, 0);
How about we get rid of this (seems a bit odd to rely on port address) ?
Rockchip-drm driver has a nice approach, and I think we might need
something like that going forward, to support dw-hdmi.
Thanks,
Ezequiel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [v2] dma-buf: heaps: bugfix for selftest failure
Hi Leon, Shuah,
Thanks for the fix. I had this issue pending to fix,
but have been lazy about it, I appreciate you are taking care of it!
On Sat, 7 Mar 2020 at 11:03, Leon He wrote:
>
> From: Leon He
>
> There are two errors in the dmabuf-heap selftest:
> 1. The 'char name[5]' was not initialized to zero, which will cause
>strcmp(name, "vgem") failed in check_vgem().
> 2. The return value of test_alloc_errors() should be reversed, other-
>wise the while loop in main() will be broken.
>
> Signed-off-by: Leon He
> ---
> tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c
> b/tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c
> index cd5e1f6..836b185 100644
> --- a/tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c
> +++ b/tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c
> @@ -22,7 +22,7 @@
> static int check_vgem(int fd)
> {
> drm_version_t version = { 0 };
> - char name[5];
> + char name[5] = { 0 };
> int ret;
>
As Shuah already mentioned, I think we want to use strncmp
to be on the safe side.
> version.name_len = 4;
> @@ -357,7 +357,7 @@ static int test_alloc_errors(char *heap_name)
> if (heap_fd >= 0)
> close(heap_fd);
>
> - return ret;
> + return !ret;
I agree with Shuah, this change makes no sense, just drop it.
I think the fact this test was broken and nobody noticed
uncovers the fact that the test isn't being run.
Any reason why this test isn't a regular TARGET?
Or any idea how we can make sure this is run by CIs
and any other testing system?
Thanks!
Ezequiel
> }
>
> int main(void)
> --
> 2.7.4
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: drm/bridge: Synopsys DW-HDMI bridge driver for the Ingenic JZ4780 (was Re: Specialising the Synopsys DW-HDMI bridge driver for the Ingenic JZ4780)
On Mon, 24 Aug 2020 at 13:05, H. Nikolaus Schaller wrote: > > Hi Ezequiel, > > > Am 24.08.2020 um 15:46 schrieb Ezequiel Garcia > > : > > > > On Fri, 21 Aug 2020 at 19:24, Paul Cercueil wrote: > >> > >> > >> > >> Le sam. 22 août 2020 à 0:11, Paul Boddie a > >> écrit : > >> > >> If you send clean patches, there's no reason for me not to merge them. > >> > > > > I'd really like to see HDMI support on my CI20 being merged. Thank to > > recent ingenic-drm work and thanks for Paul Boddie and Nikolaus work, > > the patches are IMO quite clean. > > I have done some testing and it appears that it only works if DRM is > compiled into the kernel. At least in my setup. If DRM and/or HDMI are made > modules there is no video or code doesn't compile completely. > > We have to analyse that further. > Ah! That's true. The fix is just re-organizing the code a bit. Just pushed a possible fix for that (following the IPU handling by Paul Cercueil), please feel free to test this: https://gitlab.collabora.com/linux/0day/-/commits/jz4780-drm-hdmi-module-fix-v5.9-rc2 FWIW, my test setup uses mainline vanilla U-Boot v2020.07. The kernel is loaded via TFTP. Debian mipsel is mounted via NFS (which means dm9000 works). I'm testing with weston and modetest. Note that enabling DRM_INGENIC_IPU will make the driver fail to load, as the IPU is not optional (and not present on ci20.dts). A minor thing to fix. Cheers, Ezequiel > And it seems to differ significantly from what Paul has developed recently > to make it work. It seems to be quite lucky that we have a working setup now > :) > > > Nikolaus, Paul: Do you have plans to submit these? > > Yes, as soon as we are sure that it works (and when it doesn't). > > But thanks to your work it is now much easier to improve things, since we > are no longer looking for a break-through but just have to avoid regressions. > > > If not, I'll be happy to get them out the door for review. > > Let it mature a little first and have it tested on more setups and rebased > to mainline v5.9-rc2 :) > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: drm/bridge: Synopsys DW-HDMI bridge driver for the Ingenic JZ4780 (was Re: Specialising the Synopsys DW-HDMI bridge driver for the Ingenic JZ4780)
On Fri, 21 Aug 2020 at 19:24, Paul Cercueil wrote: > > > > Le sam. 22 août 2020 à 0:11, Paul Boddie a > écrit : > > On Friday, 21 August 2020 15:32:46 CEST Ezequiel Garcia wrote: > >> On Thu, 20 Aug 2020 at 19:49, Paul Boddie > >> wrote: > >> > > >> > It still doesn't work for me. I still get "Input not supported" > >> from my > >> > monitor. It is a DVI monitor connected via a HDMI adapter, but > >> EDID > >> > probing > >> > works and, as I noted previously, the HDMI/LCDC can be made to > >> work (and > >> > obviously did work in the 3.18 kernel). > >> > >> This means the dw_hdmi encoder driver is still not good enough > >> to support your adapter. I haven't yet compared v3.18 vendor > >> with our version, but I'm afraid that the dw_hdmi stack has > >> probably changed quite a bit, so a comparison will be difficult. > > > > I would have to look at this again to check, but although I may have > > referred > > to the 3.18 HDMI driver (drivers/gpu/drm/jz4780/dwc_hdmi.c), I'm > > fairly sure I > > used the more recent driver > > (drivers/gpu/drm/bridge/synopsys/dw_hdmi.c) as my > > primary reference when making the hardware work with the L4 Runtime > > Environment. But the actual functionality with regard to setting > > registers in > > the HDMI peripheral is mostly identical between both forms of the > > driver. > > > > (This makes sense because few people are likely to have access to the > > proprietary documentation. In fact, few people are likely to have > > even tried > > to deduce what is doing on. One of the register value tables suggests > > that one > > of the values would really need to be different, if you consider the > > patterns > > involved, which means that either the documentation mentions this > > special case > > or that a mistake has been made that has not yet been exposed through > > real > > world use.) > > > >> The natural debug path for me would be to checkout v3.18, > >> connect your DVI monitor and make a dump of all the > >> dw_hdmi registers, then make the same dump for our > >> mainline kernel -- making sure we are comparing the same > >> mode. > > > > It is possible that something does not get initialised in the same > > way, and > > Nikolaus and I have been working with register dumps, although I > > haven't been > > generating them myself within Linux. So it is possible that I am > > missing some > > misconfiguration in the driver that causes an incompatibility with my > > monitor. > > > > It should be noted that the initialisation is simpler with the DVI > > mode, > > thankfully. The "AVI infoframe" stuff (going from memory) is > > completely > > skipped, as are a range of other things, which made my > > reimplementation effort > > somewhat quicker. I also didn't bother with the audio functionality, > > but then > > I don't think DVI has any audio channels, either. > > > > One reason for implementing drivers for L4Re was to determine what is > > actually > > needed to initialise the hardware correctly, doing so in an > > environment that > > has been quicker to test than Linux has been (given some very old > > development > > hardware I have been using until recently). Another reason is that I > > actually > > want to get the CI20 hardware working with L4Re, which it was > > originally > > supposed to do, but in fact that effort was never actually finished. > > > >> > I downloaded it from here: > >> > > >> > > >> https://gitlab.collabora.com/linux/0day/-/tree/jz4780-drm-hdmi-v5.9-rc1 > >> > > >> > (I was going to clone the repository late last night, but it was > >> taking a > >> > long time and I also didn't want to clone everything yet again.) > >> > >> If you want to avoid cloning the same things over and over > >> you can use git-clone --reference. And if you want to checkout > >> just a single branch, git now has --single-branch. > >> > >> For instance, (assuming a torvalds/ local repo): > >> > >> git clone -b letux/jz4780-hdmi-v4 --single-branch > >> git://git.goldelico.com/letux-kernel.git --reference torvalds/ letux > > > > Thanks for the tip! I guess I will spare everyone my thoughts about > > git's > > never-endi
Re: drm/bridge: Synopsys DW-HDMI bridge driver for the Ingenic JZ4780 (was Re: Specialising the Synopsys DW-HDMI bridge driver for the Ingenic JZ4780)
On Thu, 20 Aug 2020 at 19:49, Paul Boddie wrote: > > On Thursday, 20 August 2020 10:19:45 CEST H. Nikolaus Schaller wrote: > > > > Yes, it works!!! > > It still doesn't work for me. I still get "Input not supported" from my > monitor. It is a DVI monitor connected via a HDMI adapter, but EDID probing > works and, as I noted previously, the HDMI/LCDC can be made to work (and > obviously did work in the 3.18 kernel). > This means the dw_hdmi encoder driver is still not good enough to support your adapter. I haven't yet compared v3.18 vendor with our version, but I'm afraid that the dw_hdmi stack has probably changed quite a bit, so a comparison will be difficult. The natural debug path for me would be to checkout v3.18, connect your DVI monitor and make a dump of all the dw_hdmi registers, then make the same dump for our mainline kernel -- making sure we are comparing the same mode. > I used my usual recipe for kernel compilation: > > ARCH=mips CROSS_COMPILE=mipsel-linux-gnu- make ci20_defconfig > ARCH=mips CROSS_COMPILE=mipsel-linux-gnu- make menuconfig > ARCH=mips CROSS_COMPILE=mipsel-linux-gnu- make -j8 uImage > ARCH=mips CROSS_COMPILE=mipsel-linux-gnu- make -j8 modules > ARCH=mips CROSS_COMPILE=mipsel-linux-gnu- make -j8 dtbs > sudo sh -c 'INSTALL_MOD_PATH=nn ARCH=mips CROSS_COMPILE=mipsel-linux-gnu- \ > make modules_install' > sudo sh -c 'INSTALL_PATH=nn/boot ARCH=mips CROSS_COMPILE=mipsel-linux-gnu- \ > make dtbs_install' > sudo cp arch/mips/boot/uImage nn/boot/ > > This was with a snapshot archive made from the following changeset: > > b911b4883bfe4f7fa753ac2ff42b25fa6b3055e2 > > I downloaded it from here: > > https://gitlab.collabora.com/linux/0day/-/tree/jz4780-drm-hdmi-v5.9-rc1 > > (I was going to clone the repository late last night, but it was taking a long > time and I also didn't want to clone everything yet again.) > If you want to avoid cloning the same things over and over you can use git-clone --reference. And if you want to checkout just a single branch, git now has --single-branch. For instance, (assuming a torvalds/ local repo): git clone -b letux/jz4780-hdmi-v4 --single-branch git://git.goldelico.com/letux-kernel.git --reference torvalds/ letux > > There are some unexpected things related to CONFIG settings on my setup > > (maybe missing modules) but for the first time I can see the boot log on the > > panel. > > > This needs some more investigation, but seems at least a good start. > > > > Yes it is! > > > > I can now git diff the code and the CONFIG. > > > > So it seems we have indeed a breakthrough. > > > > Thanks to all who did contribute (even behind the scenes in the DRM > > subsystem), Nikolaus > > Before trying this new branch, I did try and tidy up the branch I had been > working on. I didn't notice all the changes and the new ingenic-drm-drv.c > file, having assumed that not much would have changed in the DRM driver. > > Nevertheless, my attempts at integrating the different branches can be found > in the paulb-jz4780-ci20-hdmi-5.9-rc1 branch, mentioned earlier. > > It would be nice to reconcile the JZ4780 support with the evolving upstream > support, accommodating the extended descriptors and the extra register usage. > I think that's already done in the patches I've cleaned up. The only thing left to check is plane offset and overlay enablement. > Paul > > P.S. I noticed a few problems with the 5.9-rc1 branches such as powering down > not actually removing the power and, in my own branch, networking not working > reliably (or maybe even at all), with the tedious progress indicator never > terminating in the boot sequence. So, once again, it is another case of half a > step forwards and about three steps back. > Life (and kernel) is like this: sometimes you need to take three steps back to make a jump forward :-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC] Experimental DMA-BUF Device Heaps
On Mon, 2020-08-17 at 20:49 -0700, James Jones wrote: > On 8/17/20 8:18 AM, Brian Starkey wrote: > > Hi Ezequiel, > > > > On Sun, Aug 16, 2020 at 02:22:46PM -0300, Ezequiel Garcia wrote: > > > This heap is basically a wrapper around DMA-API dma_alloc_attrs, > > > which will allocate memory suitable for the given device. > > > > > > The implementation is mostly a port of the Contiguous Videobuf2 > > > memory allocator (see videobuf2/videobuf2-dma-contig.c) > > > over to the DMA-BUF Heap interface. > > > > > > The intention of this allocator is to provide applications > > > with a more system-agnostic API: the only thing the application > > > needs to know is which device to get the buffer for. > > > > > > Whether the buffer is backed by CMA, IOMMU or a DMA Pool > > > is unknown to the application. > > > > > > I'm not really expecting this patch to be correct or even > > > a good idea, but just submitting it to start a discussion on DMA-BUF > > > heap discovery and negotiation. > > > > > > > My initial reaction is that I thought dmabuf heaps are meant for use > > to allocate buffers for sharing across devices, which doesn't fit very > > well with having per-device heaps. > > > > For single-device allocations, would using the buffer allocation > > functionality of that device's native API be better in most > > cases? (Some other possibly relevant discussion at [1]) > > > > I can see that this can save some boilerplate for devices that want > > to expose private chunks of memory, but might it also lead to 100 > > aliases for the system's generic coherent memory pool? > > > > I wonder if a set of helpers to allow devices to expose whatever they > > want with minimal effort would be better. > > I'm rather interested on where this goes, as I was toying with using > some sort of heap ID as a basis for a "device-local" constraint in the > memory constraints proposals Simon and I will be discussing at XDC this > year. It would be rather elegant if there was one type of heap ID used > universally throughout the kernel that could provide a unique handle for > the shared system memory heap(s), as well as accelerator-local heaps on > fancy NICs, GPUs, NN accelerators, capture devices, etc. so apps could > negotiate a location among themselves. This patch seems to be a step > towards that in a way, but I agree it would be counterproductive if a > bunch of devices that were using the same underlying system memory ended > up each getting their own heap ID just because they used some SW > framework that worked that way. > > Would appreciate it if you could send along a pointer to your BoF if it > happens! > Here is it: https://linuxplumbersconf.org/event/7/contributions/818/ It would be great to see you there and discuss this, given I was hoping we could talk about how to meet a userspace allocator library expectations as well. Thanks, Ezequiel > Thanks, > -James > > > Cheers, > > -Brian > > > > 1. > > https://lore.kernel.org/dri-devel/57062477-30e7-a3de-6723-a50d03a40...@kapsi.fi/ > > > > > Given Plumbers is just a couple weeks from now, I've submitted > > > a BoF proposal to discuss this, as perhaps it would make > > > sense to discuss this live? > > > > > > Not-signed-off-by: Ezequiel Garcia ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC] Experimental DMA-BUF Device Heaps
Hi Brian, Thanks a lot for reviewing this patch. I'm happy my humble proof-of-concept is able to spark some interest and raise some questions. On Mon, 2020-08-17 at 16:18 +0100, Brian Starkey wrote: > Hi Ezequiel, > > On Sun, Aug 16, 2020 at 02:22:46PM -0300, Ezequiel Garcia wrote: > > This heap is basically a wrapper around DMA-API dma_alloc_attrs, > > which will allocate memory suitable for the given device. > > > > The implementation is mostly a port of the Contiguous Videobuf2 > > memory allocator (see videobuf2/videobuf2-dma-contig.c) > > over to the DMA-BUF Heap interface. > > > > The intention of this allocator is to provide applications > > with a more system-agnostic API: the only thing the application > > needs to know is which device to get the buffer for. > > > > Whether the buffer is backed by CMA, IOMMU or a DMA Pool > > is unknown to the application. > > > > I'm not really expecting this patch to be correct or even > > a good idea, but just submitting it to start a discussion on DMA-BUF > > heap discovery and negotiation. > > > > My initial reaction is that I thought dmabuf heaps are meant for use > to allocate buffers for sharing across devices, which doesn't fit very > well with having per-device heaps. > That's true. > For single-device allocations, would using the buffer allocation > functionality of that device's native API be better in most > cases? (Some other possibly relevant discussion at [1]) > That may be true for existing subsystems. However, how about a new subsystem/API wanting to leverage the heap API and avoid exposing yet another allocator API? And then, also, if we have an allocator API, perhaps we could imagine a future where applications would only need to worry about that, and not about each per-framework allocator. > I can see that this can save some boilerplate for devices that want > to expose private chunks of memory, but might it also lead to 100 > aliases for the system's generic coherent memory pool? > The idea (even if PoC) was to let drivers decide if they are special enough to add themselves (via dev_dma_heap_add). Aliasing the heap would be ceratainly too much (although trying it for every device was a fun experiment to watch). Thanks, Ezequiel > I wonder if a set of helpers to allow devices to expose whatever they > want with minimal effort would be better. > > Cheers, > -Brian > > 1. > https://lore.kernel.org/dri-devel/57062477-30e7-a3de-6723-a50d03a40...@kapsi.fi/ > > > Given Plumbers is just a couple weeks from now, I've submitted > > a BoF proposal to discuss this, as perhaps it would make > > sense to discuss this live? > > > > Not-signed-off-by: Ezequiel Garcia ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC] Experimental DMA-BUF Device Heaps
Hi John, Thanks a ton for taking the time to go thru this. On Mon, 2020-08-17 at 21:13 -0700, John Stultz wrote: > On Sun, Aug 16, 2020 at 10:23 AM Ezequiel Garcia > wrote: > > This heap is basically a wrapper around DMA-API dma_alloc_attrs, > > which will allocate memory suitable for the given device. > > > > The implementation is mostly a port of the Contiguous Videobuf2 > > memory allocator (see videobuf2/videobuf2-dma-contig.c) > > over to the DMA-BUF Heap interface. > > > > The intention of this allocator is to provide applications > > with a more system-agnostic API: the only thing the application > > needs to know is which device to get the buffer for. > > > > Whether the buffer is backed by CMA, IOMMU or a DMA Pool > > is unknown to the application. > > My hesitancy here is that the main reason we have DMA BUF Heaps, and > ION before it, was to expose different types of memory allocations to > userspace. The main premise that often these buffers are shared with > multiple devices, which have differing constraints and it is userspace > that best understands the path a buffer will take through a series of > devices. So userspace is best positioned to determine what type of > memory should be allocated to satisfy the various devices constraints > (there were some design attempts to allow DMA BUFs to use multiple > attach with deferred alloc at map time to handle this constraint > solving in-kernel, but it was never adopted in practice). > > This however, requires some system specific policy - implemented in > the Android userspace by gralloc which maps "usage" types (device > pipeline flows) to heaps. I liken it to fstab, which helps map mount > points to partitions - it's not going to be the same on every system. > > What you seem to be proposing seems a bit contrary to this premise - > Userland doesn't know what type of memory it needs, but given a device > can somehow find the heap it should allocate for? This seems to assume > the buffer is only to be used with a single device? > Single-device usage wasn't the intention. I see now that this patch looks too naive and it's confusing. The idea is of course to get buffers that can be shared. I'm thinking you need to share your picture buffer with a decoder, a renderer, possibly something else. Each with its own set of constraints and limitations. Of course, a buffer that works for device A may be unsuitable for device B and so this per-device heap is surely way too naive. As you rightly mention, the main intention of this RFC is to question exactly the current premise: "userspace knows". I fail to see how will (generic and system-agnostic) applications know which heap to use. Just for completion, let me throw a simple example: i.MX 8M and some Rockchip platforms share the same VPU block, except the latter have an IOMMU. So applications would need to query an iommu presence to get buffer from CMA or not. > There was at some point a discussion where folks (maybe it was > DanielV? I can't remember...) suggested having something like a sysfs > device node link from a device to a dma-buf heap chardev. This seems > like it would add a similar behavior as what you're proposing, however > without adding possibly a ton of new device specific heaps to the > /dev/dma_heap/ dir. However, we would potentially need any missing > heap types added first. > > > I'm not really expecting this patch to be correct or even > > a good idea, but just submitting it to start a discussion on DMA-BUF > > heap discovery and negotiation. > > > > Given Plumbers is just a couple weeks from now, I've submitted > > a BoF proposal to discuss this, as perhaps it would make > > sense to discuss this live? > > I do think it's an interesting idea. I agree that having every driver > implement a dmabuf exporter is a bit silly, but I also think Brian's > point that maybe we need some drm helper functions that provide > similar functionality along with a more standardized device ioctl for > single device allocations might be better. > I'm unsure we should treat single device specially. Exposing device limitations and constraints properly, allowing some sort of negotation would hopefully solve single device and shared requirements. Thanks, Ezequiel > thanks > -john ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: drm/bridge: Synopsys DW-HDMI bridge driver for the Ingenic JZ4780 (was Re: Specialising the Synopsys DW-HDMI bridge driver for the Ingenic JZ4780)
On Wed, 19 Aug 2020 at 15:50, H. Nikolaus Schaller wrote: > > Hi Ezequiel, > > > Am 19.08.2020 um 12:21 schrieb Ezequiel Garcia > > : > > > > Hello, > > > > First of all, I'd like to thank everyone for the great work > > on ingenic-drm. The driver is in very good shape > > and a pleasure to work with. > > > > Yesterday, I checked out branch "paulb-jz4780-ci20-hdmi-5.8-rc5", > > from git.goldelico.com/letux-kernel.git, rebased it on v5.9-rc1, > > and then run weston over HDMI (how often > > weston runs on mips, uh? :) > > Wow! > > > The edid of my monitor is properly read > > and modetest reports all modes. > > > > I've only tested the primary plane, for some reason > > the overlay is not working as expected, but it must > > be probably some minor thing. > > > > As for the bus format, I have just added a skip > > for CONNECTOR_HDMIA types in the encoder > > atomic check. And then MEDIA_BUS_FMT_RGB888_1X24 > > is hardcoded if there are no bus formats negotiated > > Cool! > > > Paul et al, if you guys can rebase your work on v5.9-rc1 > > and Cc I will be happy to review and test the patches. > > I have tried our latest letux-5.9-rc1 tree (with Pauls fixes) > on my setup but screen remains black and the kernel was stuck > after showing "login:" and reported > > [ 490.680469] rcu: INFO: rcu_preempt self-detected stall on CPU > > Maybe, can you share your rebased tree to clearly identify the > subtle differences? Maybe I have broken something by the rebase. > Sure. Please give this a try and let me know if it works for you. I've cleaned and squashed your changes, hopefully I've kept the correct authorship for all of them. https://gitlab.collabora.com/linux/0day/-/commits/jz4780-drm-hdmi-v5.9-rc1 This should be enough to get an fbcon, launch weston, etc. However, there are few things that still don't look right. Seems planes X,Y offset is not working, and also enabling a second plane results in both planes going black for good. This needs some more investigation, but seems at least a good start. Thanks again for all the good work, Ezequiel > > Cheers & thanks again, > > Eze > > Thanks and best regards, > Nikolaus > > > > > > > > > > > > On Tue, 7 Jul 2020 at 04:27, Paul Boddie wrote: > >> > >> On Monday, 6 July 2020 14:12:24 CEST Neil Armstrong wrote: > >>> > >>> On 06/07/2020 01:57, Paul Boddie wrote: > >>>> > >>>> It also seems to be appropriate to set the input_bus_format on the > >>>> platform- specific HDMI driver; otherwise, I doubt that appropriate bus > >>>> encodings will be chosen in the Synopsys driver. > >>> > >>> It does but when not provided, it doesn't use it. > >>> > >>> It's handled in drm_atomic_bridge_chain_select_bus_fmts() : > >>> if (conn->display_info.num_bus_formats && > >>> conn->display_info.bus_formats) > >>> out_bus_fmts[0] = conn->display_info.bus_formats[0]; > >>> else > >>> out_bus_fmts[0] = MEDIA_BUS_FMT_FIXED; > >> > >> OK. I thought I'd seen this somewhere, but I had started to think that > >> input_bus_format would remain initialised (presumably to zero) and this > >> would > >> then cause the Synopsys driver to not change the bus format to the actual > >> default. > >> > >> [...] > >> > >>>> Testing against 5.8-rc3 with the above changes seems to have moved the > >>>> needle slightly. Although I still get "Input not supported" from my > >>>> monitor, running modetest now gives a different error: > >>>> > >>>> modetest -D /dev/dri/card0 -M ingenic-drm -s 34@32:1280x1024-60.02 > >>>> > >>>> ...now yields this: > >>>> > >>>> setting mode 1280x1024-60.02Hz@XR24 on connectors 34, crtc 32 > >>>> failed to set gamma: Invalid argument > >>> > >>> This is because you don't provide the gamma setup ioctl, it's not a fatal > >>> error at all. It should be warning since it's optional. > >>> > >>> Did you check all modes ? > >> > >> I have checked a few more. Currently, testing them is awkward because it > >> involves switching my monitor to DVI input, getting "Input Not Supported", > >> unplugging the cable, and then the hotplug event has most likely caused a > >> bad > >> pointer dereference in ingenic_drm_crtc_atomic_flush and thus a kernel > >> panic. > >> > >> So, I'll try and fix this panic, which appears to be due to the DRM driver > >> accessing a null framebuffer pointer (presumably having been invalidated > >> elsewhere upon unplugging), and see if I can't get some more information > >> about > >> the state of the peripherals. > >> > >> Paul > >> > >> > >> ___ > >> dri-devel mailing list > >> dri-devel@lists.freedesktop.org > >> 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: drm/bridge: Synopsys DW-HDMI bridge driver for the Ingenic JZ4780 (was Re: Specialising the Synopsys DW-HDMI bridge driver for the Ingenic JZ4780)
Hello, First of all, I'd like to thank everyone for the great work on ingenic-drm. The driver is in very good shape and a pleasure to work with. Yesterday, I checked out branch "paulb-jz4780-ci20-hdmi-5.8-rc5", from git.goldelico.com/letux-kernel.git, rebased it on v5.9-rc1, and then run weston over HDMI (how often weston runs on mips, uh? :) The edid of my monitor is properly read and modetest reports all modes. I've only tested the primary plane, for some reason the overlay is not working as expected, but it must be probably some minor thing. As for the bus format, I have just added a skip for CONNECTOR_HDMIA types in the encoder atomic check. And then MEDIA_BUS_FMT_RGB888_1X24 is hardcoded if there are no bus formats negotiated. Paul et al, if you guys can rebase your work on v5.9-rc1 and Cc I will be happy to review and test the patches. Cheers & thanks again, Eze On Tue, 7 Jul 2020 at 04:27, Paul Boddie wrote: > > On Monday, 6 July 2020 14:12:24 CEST Neil Armstrong wrote: > > > > On 06/07/2020 01:57, Paul Boddie wrote: > > > > > > It also seems to be appropriate to set the input_bus_format on the > > > platform- specific HDMI driver; otherwise, I doubt that appropriate bus > > > encodings will be chosen in the Synopsys driver. > > > > It does but when not provided, it doesn't use it. > > > > It's handled in drm_atomic_bridge_chain_select_bus_fmts() : > > if (conn->display_info.num_bus_formats && > > conn->display_info.bus_formats) > > out_bus_fmts[0] = conn->display_info.bus_formats[0]; > > else > > out_bus_fmts[0] = MEDIA_BUS_FMT_FIXED; > > OK. I thought I'd seen this somewhere, but I had started to think that > input_bus_format would remain initialised (presumably to zero) and this would > then cause the Synopsys driver to not change the bus format to the actual > default. > > [...] > > > > Testing against 5.8-rc3 with the above changes seems to have moved the > > > needle slightly. Although I still get "Input not supported" from my > > > monitor, running modetest now gives a different error: > > > > > > modetest -D /dev/dri/card0 -M ingenic-drm -s 34@32:1280x1024-60.02 > > > > > > ...now yields this: > > > > > > setting mode 1280x1024-60.02Hz@XR24 on connectors 34, crtc 32 > > > failed to set gamma: Invalid argument > > > > This is because you don't provide the gamma setup ioctl, it's not a fatal > > error at all. It should be warning since it's optional. > > > > Did you check all modes ? > > I have checked a few more. Currently, testing them is awkward because it > involves switching my monitor to DVI input, getting "Input Not Supported", > unplugging the cable, and then the hotplug event has most likely caused a bad > pointer dereference in ingenic_drm_crtc_atomic_flush and thus a kernel panic. > > So, I'll try and fix this panic, which appears to be due to the DRM driver > accessing a null framebuffer pointer (presumably having been invalidated > elsewhere upon unplugging), and see if I can't get some more information about > the state of the peripherals. > > Paul > > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > 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
[RFC] Experimental DMA-BUF Device Heaps
This heap is basically a wrapper around DMA-API dma_alloc_attrs,
which will allocate memory suitable for the given device.
The implementation is mostly a port of the Contiguous Videobuf2
memory allocator (see videobuf2/videobuf2-dma-contig.c)
over to the DMA-BUF Heap interface.
The intention of this allocator is to provide applications
with a more system-agnostic API: the only thing the application
needs to know is which device to get the buffer for.
Whether the buffer is backed by CMA, IOMMU or a DMA Pool
is unknown to the application.
I'm not really expecting this patch to be correct or even
a good idea, but just submitting it to start a discussion on DMA-BUF
heap discovery and negotiation.
Given Plumbers is just a couple weeks from now, I've submitted
a BoF proposal to discuss this, as perhaps it would make
sense to discuss this live?
Not-signed-off-by: Ezequiel Garcia
---
drivers/dma-buf/heaps/Kconfig | 9 +
drivers/dma-buf/heaps/Makefile | 1 +
drivers/dma-buf/heaps/device_heap.c | 268
include/linux/device.h | 5 +
include/linux/dma-heap.h| 6 +
5 files changed, 289 insertions(+)
create mode 100644 drivers/dma-buf/heaps/device_heap.c
diff --git a/drivers/dma-buf/heaps/Kconfig b/drivers/dma-buf/heaps/Kconfig
index a5eef06c4226..2bb3604184bd 100644
--- a/drivers/dma-buf/heaps/Kconfig
+++ b/drivers/dma-buf/heaps/Kconfig
@@ -12,3 +12,12 @@ config DMABUF_HEAPS_CMA
Choose this option to enable dma-buf CMA heap. This heap is backed
by the Contiguous Memory Allocator (CMA). If your system has these
regions, you should say Y here.
+
+config DMABUF_HEAPS_DEVICES
+ bool "DMA-BUF Device DMA Heap (Experimental)"
+ depends on DMABUF_HEAPS
+ help
+ Choose this option to enable dma-buf per-device heap. This heap is
backed
+ by the DMA-API and it's an Experimental feature, meant mostly for
testing
+ and experimentation.
+ Just say N here.
diff --git a/drivers/dma-buf/heaps/Makefile b/drivers/dma-buf/heaps/Makefile
index 6e54cdec3da0..c691d85b3044 100644
--- a/drivers/dma-buf/heaps/Makefile
+++ b/drivers/dma-buf/heaps/Makefile
@@ -2,3 +2,4 @@
obj-y += heap-helpers.o
obj-$(CONFIG_DMABUF_HEAPS_SYSTEM) += system_heap.o
obj-$(CONFIG_DMABUF_HEAPS_CMA) += cma_heap.o
+obj-$(CONFIG_DMABUF_HEAPS_DEVICES) += device_heap.o
diff --git a/drivers/dma-buf/heaps/device_heap.c
b/drivers/dma-buf/heaps/device_heap.c
new file mode 100644
index ..1803dc622dd8
--- /dev/null
+++ b/drivers/dma-buf/heaps/device_heap.c
@@ -0,0 +1,268 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * DMABUF Device DMA heap exporter
+ *
+ * Copyright (C) 2020, Collabora Ltd.
+ *
+ * Based on:
+ * videobuf2-dma-contig.c - DMA contig memory allocator for videobuf2
+ * Copyright (C) 2010 Samsung Electronics
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct dev_dmabuf_attachment {
+ struct sg_table sgt;
+ enum dma_data_direction dma_dir;
+};
+
+struct dev_dmabuf {
+ struct dma_heap *heap;
+ struct dma_buf *dmabuf;
+ struct device *dev;
+ size_t size;
+ void *vaddr;
+ dma_addr_t dma_addr;
+ unsigned long attrs;
+
+ struct sg_table sgt;
+};
+
+static struct sg_table *dev_dmabuf_ops_map(struct dma_buf_attachment
*db_attach,
+ enum dma_data_direction dma_dir)
+{
+ struct dev_dmabuf_attachment *attach = db_attach->priv;
+ /* stealing dmabuf mutex to serialize map/unmap operations */
+ struct mutex *lock = &db_attach->dmabuf->lock;
+ struct sg_table *sgt;
+
+ mutex_lock(lock);
+
+ sgt = &attach->sgt;
+ /* return previously mapped sg table */
+ if (attach->dma_dir == dma_dir) {
+ mutex_unlock(lock);
+ return sgt;
+ }
+
+ /* release any previous cache */
+ if (attach->dma_dir != DMA_NONE) {
+ dma_unmap_sg_attrs(db_attach->dev, sgt->sgl, sgt->orig_nents,
+ attach->dma_dir, DMA_ATTR_SKIP_CPU_SYNC);
+ attach->dma_dir = DMA_NONE;
+ }
+
+ /*
+* mapping to the client with new direction, no cache sync
+* required see comment in .dmabuf_ops_detach()
+*/
+ sgt->nents = dma_map_sg_attrs(db_attach->dev, sgt->sgl, sgt->orig_nents,
+ dma_dir, DMA_ATTR_SKIP_CPU_SYNC);
+ if (!sgt->nents) {
+ dev_err(db_attach->dev, "failed to map scatterlist\n");
+ mutex_unlock(lock);
+ return ERR_PTR(-EIO);
+ }
+
+ attach->dma_dir = dma_dir;
+
+ mutex_unlock(lock);
+
+ return sgt;
+}
+
+static void dev_dmabuf_ops_
Re: [PATCH v9 00/11] Genericize DW MIPI DSI bridge and add i.MX 6 driver
Hi Neil, On Wed, 2020-07-01 at 09:35 +0300, Adrian Ratiu wrote: > Hi Neil, > > On Mon, 29 Jun 2020, Neil Armstrong > wrote: > > Hi Adrian, > > > > On 09/06/2020 19:49, Adrian Ratiu wrote: > > > [Re-submitting to cc dri-devel, sorry about the noise] Hello > > > all, v9 cleanly applies on top of latest next-20200609 tree. > > > v9 does not depend on other patches as the last binding doc has > > > been merged. All feedback up to this point has been > > > addressed. Specific details in individual patch changelogs. > > > The biggest changes are the deprecation of the Synopsys DW > > > bridge bind() API in favor of of_drm_find_bridge() and .attach > > > callbacks, the addition of a TODO entry which outlines future > > > planned bridge driver refactorings and a reordering of some > > > i.MX 6 patches to appease checkpatch. The idea behind the > > > TODO is to get this regmap and i.MX 6 driver merged and then do > > > the rest of refactorings in-tree because it's easier and the > > > refactorings themselves are out-of-scope of this series which > > > is adding i.MX 6 support and is quite big already, so please, > > > if there are more refactoring ideas, let's add them to the TODO > > > doc. :) I intend to tackle those after this series is merged to > > > avoid two complex inter-dependent simultaneous series. > > > > This has been around here for a long time and you seem to have > > addressed all the reviews. > > > > > As always more testing is welcome especially on Rockchip and > > > STM SoCs. > > > > It has been tested on STM, but I'd like a feedback on RK > > platform before applying the bridge parts. > > > > Can the imx & stm patches be applied separately ? > > > > Yes the IMX and STM patches can be applied separately, they just > both depend on the common regmap patches. > It's been a month so I think it's a good idea to go forward applying IMX and STM patches (probably with the usual rebase dance). As for Rockchip... > The binding API removal change which directly touches RK can also > be applied separately, but unfortunately I do not have access to a > RK board with a DSI display to test it (or the bridge regmap logic > on RK btw...), I just "eye-balled" the RK code based on the public > docs and it LGTM. > ... I'll be getting some DSI hardware to help with the pending Rockchip issues, so we can tackle Rockchip as well. I'm quite sure we'll loop Heiko as well if needed :-) Cheers, Ezequiel > > Neil > > > > > Big thank you to everyone who has contributed to this up to now, > > > Adrian > > > > > > Adrian Ratiu (11): > > > drm: bridge: dw_mipi_dsi: add initial regmap infrastructure > > > drm: bridge: dw_mipi_dsi: abstract register access using reg_fields > > > drm: bridge: dw_mipi_dsi: add dsi v1.01 support > > > drm: bridge: dw_mipi_dsi: remove bind/unbind API > > > dt-bindings: display: add i.MX6 MIPI DSI host controller doc > > > ARM: dts: imx6qdl: add missing mipi dsi properties > > > drm: imx: Add i.MX 6 MIPI DSI host platform driver > > > drm: stm: dw-mipi-dsi: let the bridge handle the HW version check > > > drm: bridge: dw-mipi-dsi: split low power cfg register into fields > > > drm: bridge: dw-mipi-dsi: fix bad register field offsets > > > Documentation: gpu: todo: Add dw-mipi-dsi consolidation plan > > > > > > .../display/imx/fsl,mipi-dsi-imx6.yaml| 112 +++ > > > Documentation/gpu/todo.rst| 25 + > > > arch/arm/boot/dts/imx6qdl.dtsi| 8 + > > > drivers/gpu/drm/bridge/synopsys/Kconfig | 1 + > > > drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 713 -- > > > drivers/gpu/drm/imx/Kconfig | 8 + > > > drivers/gpu/drm/imx/Makefile | 1 + > > > drivers/gpu/drm/imx/dw_mipi_dsi-imx6.c| 399 ++ > > > .../gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 7 +- > > > drivers/gpu/drm/stm/dw_mipi_dsi-stm.c | 16 +- > > > 10 files changed, 1059 insertions(+), 231 deletions(-) > > > create mode 100644 > > > Documentation/devicetree/bindings/display/imx/fsl,mipi-dsi-imx6.yaml > > > create mode 100644 drivers/gpu/drm/imx/dw_mipi_dsi-imx6.c > > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] dma-buf: heap-helpers: Set dma-buf exporter name
Currently the heap helper uses DEFINE_DMA_BUF_EXPORT_INFO,
which uses KBUILD_MODNAME for the dma_buf_export_info.exp_name.
This effectively makes all dma-bufs exported by the heap
helper as coming from "heap-helpers", instead of the actual heap name
(cma, system, etc).
Fix this by adding a dma-heap name getter, and then setting
dma_buf_export_info.exp_name.
Signed-off-by: Ezequiel Garcia
---
drivers/dma-buf/dma-heap.c | 5 +
drivers/dma-buf/heaps/heap-helpers.c | 1 +
include/linux/dma-heap.h | 2 ++
3 files changed, 8 insertions(+)
diff --git a/drivers/dma-buf/dma-heap.c b/drivers/dma-buf/dma-heap.c
index afd22c9dbdcf..13d001ee381a 100644
--- a/drivers/dma-buf/dma-heap.c
+++ b/drivers/dma-buf/dma-heap.c
@@ -190,6 +190,11 @@ void *dma_heap_get_drvdata(struct dma_heap *heap)
return heap->priv;
}
+const char *dma_heap_get_name(struct dma_heap *heap)
+{
+ return heap->name;
+}
+
struct dma_heap *dma_heap_add(const struct dma_heap_export_info *exp_info)
{
struct dma_heap *heap, *h, *err_ret;
diff --git a/drivers/dma-buf/heaps/heap-helpers.c
b/drivers/dma-buf/heaps/heap-helpers.c
index 9f964ca3f59c..47ecf9518442 100644
--- a/drivers/dma-buf/heaps/heap-helpers.c
+++ b/drivers/dma-buf/heaps/heap-helpers.c
@@ -30,6 +30,7 @@ struct dma_buf *heap_helper_export_dmabuf(struct
heap_helper_buffer *buffer,
{
DEFINE_DMA_BUF_EXPORT_INFO(exp_info);
+ exp_info.exp_name = dma_heap_get_name(buffer->heap);
exp_info.ops = &heap_helper_ops;
exp_info.size = buffer->size;
exp_info.flags = fd_flags;
diff --git a/include/linux/dma-heap.h b/include/linux/dma-heap.h
index 454e354d1ffb..0acf7e71afb5 100644
--- a/include/linux/dma-heap.h
+++ b/include/linux/dma-heap.h
@@ -50,6 +50,8 @@ struct dma_heap_export_info {
*/
void *dma_heap_get_drvdata(struct dma_heap *heap);
+const char *dma_heap_get_name(struct dma_heap *heap);
+
/**
* dma_heap_add - adds a heap to dmabuf heaps
* @exp_info: information needed to register this heap
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dma-buf: heap-helpers: Set dma-buf exporter name
On Fri, 14 Aug 2020 at 23:20, John Stultz wrote: > > On Fri, Aug 14, 2020 at 7:25 AM Ezequiel Garcia > wrote: > > > > Currently the heap helper uses DEFINE_DMA_BUF_EXPORT_INFO, > > which uses KBUILD_MODNAME for the dma_buf_export_info.exp_name. > > > > This effectively makes all dma-bufs exported by the heap > > helper as coming from "heap-helpers", instead of the actual heap name > > (cma, system, etc). > > > > Fix this by adding a dma-heap name getter, and then setting > > dma_buf_export_info.exp_name. > > > > Signed-off-by: Ezequiel Garcia > > Untested, but looks sane to me. > > Acked-by: John Stultz > Cool. > On a slightly related note, I'm starting to regret the current > heap-helpers approach (Andrew probably gets an "I told you so" there > :). While it avoids a lot of duplication, it's really an all or > nothing approach, and doesn't really compare well to other drm style > helper functions. I may eventually try to break the system and cma > implementations out of the helper code and try to consider a different > approach to avoid the duplication. > Fully agreed :-) It definitely looks too rigid right now. Cheers, Ezequiel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC][PATCH v2 2/2] dma-heap: Add a system-uncached heap
Hi John,
Thanks for the patch.
On Fri, 14 Aug 2020 at 03:25, John Stultz wrote:
>
> This adds a heap that allocates non-contiguous buffers that are
> marked as writecombined, so they are not cached by the CPU.
>
What's the rationale for exposing the memory
attribute as a new heap, instead of just introducing flags?
I guess this calls for some guidelines on what situations
call for a separate heap, and when it's just a modifier flag.
Thanks!
Ezequiel
> This is useful, as most graphics buffers are usually not touched
> by the CPU or only written into once by the CPU. So when mapping
> the buffer over and over between devices, we can skip the CPU
> syncing, which saves a lot of cache management overhead, greatly
> improving performance.
>
> For folk using ION, there was a ION_FLAG_CACHED flag, which
> signaled if the returned buffer should be CPU cacheable or not.
> With DMA-BUF heaps, we have no such flag, and by default the
> current heaps (system and cma) produce CPU cachable buffers.
> So for folks transitioning from ION to DMA-BUF Heaps, this fills
> in some of that missing functionality.
>
> This does have a few "ugly" bits that were required to get
> the buffer properly flushed out initially which I'd like to
> improve. So feedback would be very welcome!
>
> Many thanks to Liam Mark for his help to get this working.
>
> Cc: Sumit Semwal
> Cc: Andrew F. Davis
> Cc: Benjamin Gaignard
> Cc: Liam Mark
> Cc: Laura Abbott
> Cc: Brian Starkey
> Cc: Hridya Valsaraju
> Cc: Robin Murphy
> Cc: linux-me...@vger.kernel.org
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: John Stultz
> ---
> v2:
> * Fix build issue on sh reported-by: kernel test robot
> * Rework to use for_each_sgtable_sg(), dma_map_sgtable(), and
> for_each_sg_page() along with numerous other cleanups suggested
> by Robin Murphy
> ---
> drivers/dma-buf/heaps/Kconfig| 10 +
> drivers/dma-buf/heaps/Makefile | 1 +
> drivers/dma-buf/heaps/system_uncached_heap.c | 371 +++
> 3 files changed, 382 insertions(+)
> create mode 100644 drivers/dma-buf/heaps/system_uncached_heap.c
>
> diff --git a/drivers/dma-buf/heaps/Kconfig b/drivers/dma-buf/heaps/Kconfig
> index a5eef06c4226..420b0ed0a512 100644
> --- a/drivers/dma-buf/heaps/Kconfig
> +++ b/drivers/dma-buf/heaps/Kconfig
> @@ -5,6 +5,16 @@ config DMABUF_HEAPS_SYSTEM
> Choose this option to enable the system dmabuf heap. The system heap
> is backed by pages from the buddy allocator. If in doubt, say Y.
>
> +config DMABUF_HEAPS_SYSTEM_UNCACHED
> + bool "DMA-BUF Uncached System Heap"
> + depends on DMABUF_HEAPS
> + help
> + Choose this option to enable the uncached system dmabuf heap. This
> + heap is backed by pages from the buddy allocator, but pages are
> setup
> + for write combining. This avoids cache management overhead, and can
> + be faster if pages are mostly untouched by the cpu. If in doubt,
> + say Y.
> +
> config DMABUF_HEAPS_CMA
> bool "DMA-BUF CMA Heap"
> depends on DMABUF_HEAPS && DMA_CMA
> diff --git a/drivers/dma-buf/heaps/Makefile b/drivers/dma-buf/heaps/Makefile
> index 6e54cdec3da0..085685ec478f 100644
> --- a/drivers/dma-buf/heaps/Makefile
> +++ b/drivers/dma-buf/heaps/Makefile
> @@ -1,4 +1,5 @@
> # SPDX-License-Identifier: GPL-2.0
> obj-y += heap-helpers.o
> obj-$(CONFIG_DMABUF_HEAPS_SYSTEM) += system_heap.o
> +obj-$(CONFIG_DMABUF_HEAPS_SYSTEM_UNCACHED) += system_uncached_heap.o
> obj-$(CONFIG_DMABUF_HEAPS_CMA) += cma_heap.o
> diff --git a/drivers/dma-buf/heaps/system_uncached_heap.c
> b/drivers/dma-buf/heaps/system_uncached_heap.c
> new file mode 100644
> index ..3b8e699bcae7
> --- /dev/null
> +++ b/drivers/dma-buf/heaps/system_uncached_heap.c
> @@ -0,0 +1,371 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Uncached System DMA-Heap exporter
> + *
> + * Copyright (C) 2020 Linaro Ltd.
> + *
> + * Based off of Andrew Davis' SRAM heap:
> + * Copyright (C) 2019 Texas Instruments Incorporated - http://www.ti.com/
> + * Andrew F. Davis
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +struct uncached_heap {
> + struct dma_heap *heap;
> +};
> +
> +struct uncached_heap_buffer {
> + struct dma_heap *heap;
> + struct list_head attachments;
> + struct mutex lock;
> + unsigned long len;
> + struct sg_table sg_table;
> + int vmap_cnt;
> + void *vaddr;
> +};
> +
> +struct dma_heap_attachment {
> + struct device *dev;
> + struct sg_table *table;
> + struct list_head list;
> +};
> +
> +static struct sg_table *dup_sg_table(struct sg_table *table)
> +{
> + struct sg_table *new_table;
> + int ret, i;
> + struct scatterlist *sg, *new_sg;
> +
> + new_table = kzalloc(sizeof(*new_
Re: KASAN: use-after-free Read in vkms_dumb_create
On Tue, 28 Apr 2020 at 09:47, Hillf Danton wrote: > > > Sun, 26 Apr 2020 20:48:12 -0700 > > syzbot found the following crash on: > > > > HEAD commit:c578ddb3 Merge tag 'linux-kselftest-5.7-rc3' of git://git... > > git tree: upstream > > console output: https://syzkaller.appspot.com/x/log.txt?x=10fbf0d810 > > kernel config: https://syzkaller.appspot.com/x/.config?x=b7a70e992f2f9b68 > > dashboard link: https://syzkaller.appspot.com/bug?extid=e3372a2afe1e7ef04bc7 > > compiler: gcc (GCC) 9.0.0 20181231 (experimental) > > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1543833010 > > > > Bisection is inconclusive: the first bad commit could be any of: > > > > 85b5bafb drm/cma-helper: Remove drm_fb_cma_fbdev_init_with_funcs() > > dff1c703 drm/tinydrm: Use drm_fbdev_generic_setup() > > 23167fa9 drm/panel: simple: Add support for Rocktech RK070ER9427 LCD panel > > 9060d7f4 drm/fb-helper: Finish the generic fbdev emulation > > 2230ca12 dt-bindings: display: Document the EDT et* displays in one file. > > e896c132 drm/debugfs: Add internal client debugfs file > > 894a677f drm/cma-helper: Use the generic fbdev emulation > > aa7e6455 drm/panel: Add support for the EDT ETM0700G0BDH6 > > 244007ec drm/pl111: Set .gem_prime_vmap and .gem_prime_mmap > > aad34de2 drm/panel: Add support for the EDT ETM0700G0EDH6 > > 7a6aca49 dt-bindings: Add vendor prefix for DLC Display Co., Ltd. > > d536540f drm/fb-helper: Add generic fbdev emulation .fb_probe function > > 0ca0c827 drm/panel: simple: Add DLC DLC0700YZG-1 panel > > c76f0f7c drm: Begin an API for in-kernel clients > > 5ba57bab drm: vkms: select DRM_KMS_HELPER > > 5fa8e4a2 drm/panel: Make of_drm_find_panel() return an ERR_PTR() instead of > > NULL > > 008095e0 drm/vc4: Add support for the transposer block > > c59eb3cf drm/panel: Let of_drm_find_panel() return -ENODEV when the panel > > is disabled > > 1ebe99a7 drm/vc4: Call drm_atomic_helper_fake_vblank() in the commit path > > 2e64a174 drm/of: Make drm_of_find_panel_or_bridge() fail when the device is > > disabled > > 1b9883ea drm/vc4: Support the case where the DSI device is disabled > > 6fb42b66 drm/atomic: Call fake_vblank() from the generic commit_tail() > > helpers > > b0b7aa40 dt-bindings: display: Add DT bindings for BOE HV070WSA-100 panel > > b25c60af drm/crtc: Add a generic infrastructure to fake VBLANK events > > 184d3cf4 drm/vc4: Use wait_for_flip_done() instead of wait_for_vblanks() > > ae8cf41b drm/panel: simple: Add support for BOE HV070WSA-100 panel to > > simple-panel > > 814bde99 drm/connector: Make ->atomic_commit() optional > > 955f60db drm: Add support for extracting sync signal drive edge from > > videomode > > 3b39ad7a drm/panel: simple: Add newhaven, nhd-4.3-480272ef-atxl LCD > > 425132fd drm/connector: Pass a drm_connector_state to ->atomic_commit() > > a5d2ade6 drm/panel: simple: Add support for Innolux G070Y2-L01 > > b82c1f8f drm/atomic: Avoid connector to writeback_connector casts > > 03fa9aa3 dt-bindings: Add DataImage, Inc. vendor prefix > > 73915b2b drm/writeback: Fix the "overview" section of the doc > > 97ceb1fb drm/panel: simple: Add support for DataImage SCF0700C48GGU18 > > e22e9531 Merge drm-upstream/drm-next into drm-misc-next > > 3d5664f9 drm/panel: ili9881c: Fix missing assignment to error return ret > > a0120245 drm/crc: Only report a single overflow when a CRC fd is opened > > 7ad4e463 drm/panel: p079zca: Refactor panel driver to support multiple > > panels > > 8adbbb2e drm/stm: ltdc: rework reset sequence > > 48bd379a drm/panel: p079zca: Add variable unprepare_delay properties > > 7868e507 drm/stm: ltdc: filter mode pixel clock vs pad constraint > > 731edd4c dt-bindings: Add Innolux P097PFG panel bindings > > f8878bb2 drm: print plane state normalized zpos value > > ca52bea9 drm/atomic-helper: Use bitwise or for filling a bitmask > > de04a462 drm/panel: p079zca: Support Innolux P097PFG panel > > 2bb7a39c dt-bindings: Add vendor prefix for kingdisplay > > a65020d0 drm/v3d: Fix a grammar nit in the scheduler docs. > > 2dd4f211 drm/v3d: Add missing v3d documentation structure. > > ebc950fd dt-bindings: Add KINGDISPLAY KD097D04 panel bindings > > cd0e0ca6 drm/panel: type promotion bug in s6e8aa0_read_mtp_id() > > e0d01811 drm/v3d: Remove unnecessary dma_fence_ops. > > 624bb0c0 drm/v3d: Delay the scheduler timeout if we're still making > > progress. > > b6d83fcc drm/panel: p079zca: Use of_device_get_match_data() > > 408633d2 drm/v3d: use new return type vm_fault_t in v3d_gem_fault > > decac6b0 dt-bindings: display: sun4i-drm: Add R40 display engine compatible > > 0b7510d1 drm/tilcdc: Use drm_connector_has_possible_encoder() > > d978a94b drm/sun4i: Add R40 display engine compatible > > af11942e drm/sun4i: tcon-top: Cleanup clock handling > > f8222409 drm/msm: Use drm_connector_has_possible_encoder() > > 38cb8d96 drm: Add drm_connector_has_possible_encoder() > > da82107e drm/sun4i: tcon: Release node when traversing of graph > > 7a667775 dt-bindin
[PATCH] drm/vkms: Hold gem object while still in-use
We need to keep the reference to the drm_gem_object
until the last access by vkms_dumb_create.
Therefore, the put the object after it is used.
This fixes a use-after-free issue reported by syzbot.
While here, change vkms_gem_create() symbol to static.
Reported-and-tested-by: syzbot+e3372a2afe1e7ef04...@syzkaller.appspotmail.com
Signed-off-by: Ezequiel Garcia
---
drivers/gpu/drm/vkms/vkms_drv.h | 5 -
drivers/gpu/drm/vkms/vkms_gem.c | 11 ++-
2 files changed, 6 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/vkms/vkms_drv.h b/drivers/gpu/drm/vkms/vkms_drv.h
index eda04ffba7b1..f4036bb0b9a8 100644
--- a/drivers/gpu/drm/vkms/vkms_drv.h
+++ b/drivers/gpu/drm/vkms/vkms_drv.h
@@ -117,11 +117,6 @@ struct drm_plane *vkms_plane_init(struct vkms_device
*vkmsdev,
enum drm_plane_type type, int index);
/* Gem stuff */
-struct drm_gem_object *vkms_gem_create(struct drm_device *dev,
- struct drm_file *file,
- u32 *handle,
- u64 size);
-
vm_fault_t vkms_gem_fault(struct vm_fault *vmf);
int vkms_dumb_create(struct drm_file *file, struct drm_device *dev,
diff --git a/drivers/gpu/drm/vkms/vkms_gem.c b/drivers/gpu/drm/vkms/vkms_gem.c
index 2e01186fb943..c541fec57566 100644
--- a/drivers/gpu/drm/vkms/vkms_gem.c
+++ b/drivers/gpu/drm/vkms/vkms_gem.c
@@ -97,10 +97,10 @@ vm_fault_t vkms_gem_fault(struct vm_fault *vmf)
return ret;
}
-struct drm_gem_object *vkms_gem_create(struct drm_device *dev,
- struct drm_file *file,
- u32 *handle,
- u64 size)
+static struct drm_gem_object *vkms_gem_create(struct drm_device *dev,
+ struct drm_file *file,
+ u32 *handle,
+ u64 size)
{
struct vkms_gem_object *obj;
int ret;
@@ -113,7 +113,6 @@ struct drm_gem_object *vkms_gem_create(struct drm_device
*dev,
return ERR_CAST(obj);
ret = drm_gem_handle_create(file, &obj->gem, handle);
- drm_gem_object_put_unlocked(&obj->gem);
if (ret)
return ERR_PTR(ret);
@@ -142,6 +141,8 @@ int vkms_dumb_create(struct drm_file *file, struct
drm_device *dev,
args->size = gem_obj->size;
args->pitch = pitch;
+ drm_gem_object_put_unlocked(gem_obj);
+
DRM_DEBUG_DRIVER("Created object of size %lld\n", size);
return 0;
--
2.26.0.rc2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: KASAN: use-after-free Read in vkms_dumb_create
n.c:57 [inline]
> kasan_set_free_info mm/kasan/common.c:317 [inline]
> __kasan_slab_free+0xf7/0x140 mm/kasan/common.c:456
> __cache_free mm/slab.c:3426 [inline]
> kfree+0x109/0x2b0 mm/slab.c:3757
> drm_gem_object_free+0xf0/0x1f0 drivers/gpu/drm/drm_gem.c:983
> kref_put include/linux/kref.h:65 [inline]
> drm_gem_object_put_unlocked drivers/gpu/drm/drm_gem.c:1017 [inline]
> drm_gem_object_put_unlocked+0x190/0x1c0 drivers/gpu/drm/drm_gem.c:1002
> vkms_gem_create drivers/gpu/drm/vkms/vkms_gem.c:116 [inline]
> vkms_gem_create drivers/gpu/drm/vkms/vkms_gem.c:100 [inline]
> vkms_dumb_create+0x14d/0x290 drivers/gpu/drm/vkms/vkms_gem.c:138
> drm_mode_create_dumb+0x27c/0x300 drivers/gpu/drm/drm_dumb_buffers.c:94
> drm_ioctl_kernel+0x220/0x2f0 drivers/gpu/drm/drm_ioctl.c:787
> drm_ioctl+0x4c9/0x980 drivers/gpu/drm/drm_ioctl.c:887
> vfs_ioctl fs/ioctl.c:47 [inline]
> ksys_ioctl+0x11a/0x180 fs/ioctl.c:763
> __do_sys_ioctl fs/ioctl.c:772 [inline]
> __se_sys_ioctl fs/ioctl.c:770 [inline]
> __x64_sys_ioctl+0x6f/0xb0 fs/ioctl.c:770
> do_syscall_64+0xf6/0x7d0 arch/x86/entry/common.c:295
> entry_SYSCALL_64_after_hwframe+0x49/0xb3
>
> The buggy address belongs to the object at 88809e537000
> which belongs to the cache kmalloc-1k of size 1024
> The buggy address is located 272 bytes inside of
> 1024-byte region [88809e537000, 88809e537400)
> The buggy address belongs to the page:
> page:ea0002794dc0 refcount:1 mapcount:0 mapping:e8234a18 index:0x0
> flags: 0xfffe000200(slab)
> raw: 00fffe000200 ea00027a3608 ea0002749008 8880aa000c40
> raw: 88809e537000 00010002
> page dumped because: kasan: bad access detected
>
> Memory state around the buggy address:
> 88809e537000: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> 88809e537080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> >88809e537100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ^
> 88809e537180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> 88809e537200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ======
>
>
> ---
> This bug is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkal...@googlegroups.com.
>
> syzbot will keep track of this bug report. See:
> https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
> For information about bisection process see: https://goo.gl/tpsmEJ#bisection
> syzbot can test patches for this bug, for details see:
> https://goo.gl/tpsmEJ#testing-patches
#syz test: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
c578ddb3
>From 58035231aa036d5710286e242ec9b6d1f2995c85 Mon Sep 17 00:00:00 2001
From: Ezequiel Garcia
Date: Mon, 27 Apr 2020 10:15:06 -0300
Subject: [PATCH] vkms: Hold gem object while in use
Signed-off-by: Ezequiel Garcia
---
drivers/gpu/drm/vkms/vkms_gem.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vkms/vkms_gem.c b/drivers/gpu/drm/vkms/vkms_gem.c
index 2e01186fb943..023e6a45fbf8 100644
--- a/drivers/gpu/drm/vkms/vkms_gem.c
+++ b/drivers/gpu/drm/vkms/vkms_gem.c
@@ -113,7 +113,6 @@ struct drm_gem_object *vkms_gem_create(struct
drm_device *dev,
return ERR_CAST(obj);
ret = drm_gem_handle_create(file, &obj->gem, handle);
- drm_gem_object_put_unlocked(&obj->gem);
if (ret)
return ERR_PTR(ret);
@@ -142,6 +141,8 @@ int vkms_dumb_create(struct drm_file *file, struct
drm_device *dev,
args->size = gem_obj->size;
args->pitch = pitch;
+ drm_gem_object_put_unlocked(gem_obj);
+
DRM_DEBUG_DRIVER("Created object of size %lld\n", size);
return 0;
--
2.26.0.rc2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: KASAN: use-after-free Read in vkms_dumb_create
n.c:57 [inline]
> kasan_set_free_info mm/kasan/common.c:317 [inline]
> __kasan_slab_free+0xf7/0x140 mm/kasan/common.c:456
> __cache_free mm/slab.c:3426 [inline]
> kfree+0x109/0x2b0 mm/slab.c:3757
> drm_gem_object_free+0xf0/0x1f0 drivers/gpu/drm/drm_gem.c:983
> kref_put include/linux/kref.h:65 [inline]
> drm_gem_object_put_unlocked drivers/gpu/drm/drm_gem.c:1017 [inline]
> drm_gem_object_put_unlocked+0x190/0x1c0 drivers/gpu/drm/drm_gem.c:1002
> vkms_gem_create drivers/gpu/drm/vkms/vkms_gem.c:116 [inline]
> vkms_gem_create drivers/gpu/drm/vkms/vkms_gem.c:100 [inline]
> vkms_dumb_create+0x14d/0x290 drivers/gpu/drm/vkms/vkms_gem.c:138
> drm_mode_create_dumb+0x27c/0x300 drivers/gpu/drm/drm_dumb_buffers.c:94
> drm_ioctl_kernel+0x220/0x2f0 drivers/gpu/drm/drm_ioctl.c:787
> drm_ioctl+0x4c9/0x980 drivers/gpu/drm/drm_ioctl.c:887
> vfs_ioctl fs/ioctl.c:47 [inline]
> ksys_ioctl+0x11a/0x180 fs/ioctl.c:763
> __do_sys_ioctl fs/ioctl.c:772 [inline]
> __se_sys_ioctl fs/ioctl.c:770 [inline]
> __x64_sys_ioctl+0x6f/0xb0 fs/ioctl.c:770
> do_syscall_64+0xf6/0x7d0 arch/x86/entry/common.c:295
> entry_SYSCALL_64_after_hwframe+0x49/0xb3
>
> The buggy address belongs to the object at 88809e537000
> which belongs to the cache kmalloc-1k of size 1024
> The buggy address is located 272 bytes inside of
> 1024-byte region [88809e537000, 88809e537400)
> The buggy address belongs to the page:
> page:ea0002794dc0 refcount:1 mapcount:0 mapping:e8234a18 index:0x0
> flags: 0xfffe000200(slab)
> raw: 00fffe000200 ea00027a3608 ea0002749008 8880aa000c40
> raw: 88809e537000 00010002
> page dumped because: kasan: bad access detected
>
> Memory state around the buggy address:
> 88809e537000: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> 88809e537080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> >88809e537100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ^
> 88809e537180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> 88809e537200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ======
>
>
> ---
> This bug is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkal...@googlegroups.com.
>
> syzbot will keep track of this bug report. See:
> https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
> For information about bisection process see: https://goo.gl/tpsmEJ#bisection
> syzbot can test patches for this bug, for details see:
> https://goo.gl/tpsmEJ#testing-patches
Let's see if this works...
#syz test: upstream c578ddb3
>From 58035231aa036d5710286e242ec9b6d1f2995c85 Mon Sep 17 00:00:00 2001
From: Ezequiel Garcia
Date: Mon, 27 Apr 2020 10:15:06 -0300
Subject: [PATCH] vkms: Hold gem object while in use
Signed-off-by: Ezequiel Garcia
---
drivers/gpu/drm/vkms/vkms_gem.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vkms/vkms_gem.c b/drivers/gpu/drm/vkms/vkms_gem.c
index 2e01186fb943..023e6a45fbf8 100644
--- a/drivers/gpu/drm/vkms/vkms_gem.c
+++ b/drivers/gpu/drm/vkms/vkms_gem.c
@@ -113,7 +113,6 @@ struct drm_gem_object *vkms_gem_create(struct
drm_device *dev,
return ERR_CAST(obj);
ret = drm_gem_handle_create(file, &obj->gem, handle);
- drm_gem_object_put_unlocked(&obj->gem);
if (ret)
return ERR_PTR(ret);
@@ -142,6 +141,8 @@ int vkms_dumb_create(struct drm_file *file, struct
drm_device *dev,
args->size = gem_obj->size;
args->pitch = pitch;
+ drm_gem_object_put_unlocked(gem_obj);
+
DRM_DEBUG_DRIVER("Created object of size %lld\n", size);
return 0;
--
2.26.0.rc2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 4/5] drm: imx: Add i.MX 6 MIPI DSI host platform driver
Hello Fabio, Adrian:
On Mon, 2020-03-30 at 08:49 -0300, Fabio Estevam wrote:
> Hi Adrian,
>
> On Mon, Mar 30, 2020 at 8:34 AM Adrian Ratiu
> wrote:
> > 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
> >
> > - ARM: dtsi: imx6qdl: Add support for MIPI DSI host controller
> > Signed-off-by: Liu Ying
>
> This one looks like a devicetree patch, but this patch does not touch
> devicetree.
>
> > + ret = clk_prepare_enable(dsi->pllref_clk);
> > + if (ret) {
> > + dev_err(dev, "%s: Failed to enable pllref_clk\n", __func__);
> > + return ret;
> > + }
> > +
> > + dsi->mux_sel = syscon_regmap_lookup_by_phandle(dev->of_node,
> > "fsl,gpr");
> > + if (IS_ERR(dsi->mux_sel)) {
> > + ret = PTR_ERR(dsi->mux_sel);
> > + dev_err(dev, "%s: Failed to get GPR regmap: %d\n",
> > + __func__, ret);
> > + return ret;
>
> You should disable the dsi->pllref_clk clock prior to returning the error.
>
Another approach could be moving the clock on and off to
to component_ops.{bind,unbind} (as rockhip driver does).
What exactly is the PLL clock needed for? Would it make sense
to move it some of the PHY power on/off? (Maybe not, but it's worthing
checking).
Also, it seems the other IP blocks have this PLL clock, so maybe
it could be moved to the dw_mipi_dsi core? This could be something
for a follow-up, to avoid creeping this series.
Thanks,
Ezequiel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 4/5] drm: imx: Add i.MX 6 MIPI DSI host platform driver
On Tue, 2020-03-31 at 00:31 +0300, Adrian Ratiu wrote:
> On Mon, 30 Mar 2020, Ezequiel Garcia
> wrote:
> > Hello Fabio, Adrian:
> >
> > On Mon, 2020-03-30 at 08:49 -0300, Fabio Estevam wrote:
> > > Hi Adrian, On Mon, Mar 30, 2020 at 8:34 AM Adrian Ratiu
> > > wrote:
> > > > 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
> > > > - ARM: dtsi: imx6qdl: Add support for MIPI DSI host
> > > > controller
> > > > Signed-off-by: Liu Ying
> > > This one looks like a devicetree patch, but this patch does
> > > not touch devicetree.
> > > > + ret = clk_prepare_enable(dsi->pllref_clk); + if
> > > > (ret) { + dev_err(dev, "%s: Failed to enable
> > > > pllref_clk\n", __func__); + return ret; +
> > > > } + + dsi->mux_sel =
> > > > syscon_regmap_lookup_by_phandle(dev->of_node, "fsl,gpr"); +
> > > > if (IS_ERR(dsi->mux_sel)) { + ret =
> > > > PTR_ERR(dsi->mux_sel); + dev_err(dev, "%s:
> > > > Failed to get GPR regmap: %d\n", +
> > > > __func__, ret); + return ret;
> > > You should disable the dsi->pllref_clk clock prior to
> > > returning the error.
> >
> > Another approach could be moving the clock on and off to to
> > component_ops.{bind,unbind} (as rockhip driver does).
> >
> > What exactly is the PLL clock needed for? Would it make sense to
> > move it some of the PHY power on/off? (Maybe not, but it's
> > worthing checking).
> >
> > Also, it seems the other IP blocks have this PLL clock, so maybe
> > it could be moved to the dw_mipi_dsi core? This could be
> > something for a follow-up, to avoid creeping this series.
>
> Hi Ezequiel,
>
> pll is the video reference clock which drives the data lanes and
> yes all drivers have it as it's a basic requirement, so moving it
> to the common bridge is indeed a good idea, however this kind of
> driver refactoring is out of scope for this specific patch series,
> because, for now, I'd like to get the regmap and the imx6 driver
> in, once that is done we can think how to further abstract away
> common logic and slim down the existing drivers further.
>
> Basically I just want to avoid feature creep as I expect v6 to be
> ~ 8 patches big and the series is already over 1200 lines.
>
Oh, absolutely: if there's one thing I try to avoid is
feature creep -- together with bikeshedding!
Do note however, that you could move the PLL clock handling
to component_ops.{bind,unbind} and maybe simplify the error
handling.
(BTW, great work!)
Cheers,
Ezequiel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v9 3/4] soc: mediatek: Move mt8173 MMSYS to platform driver
On Wed, 2020-02-26 at 07:40 -0800, Randy Dunlap wrote: > On 2/26/20 2:54 AM, Enric Balletbo i Serra wrote: > > diff --git a/drivers/soc/mediatek/Kconfig b/drivers/soc/mediatek/Kconfig > > index 2114b563478c..dcd6481a14d0 100644 > > --- a/drivers/soc/mediatek/Kconfig > > +++ b/drivers/soc/mediatek/Kconfig > > @@ -44,4 +44,11 @@ config MTK_SCPSYS > > Say yes here to add support for the MediaTek SCPSYS power domain > > driver. > > > > +config MT8173_MMSYS > > + bool "MediaTek MT8173 MMSYS Support" > > Hi, > Can this be tristate instead of bool? > Wouldn't that conflict with the driver being a builtin_platform_driver, or am I just confusing things badly? Thanks, Ezequiel > + depends on COMMON_CLK_MT8173 > > + help > > + Say yes here to add support for the MediaTek MT8173 Multimedia > > + Subsystem (MMSYS). > > + > > endmenu > > thanks. > -- > ~Randy > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: shrinker: Add a prefix on purging logs
On Wed, 2020-01-22 at 09:04 +0100, Daniel Vetter wrote: > On Sat, Dec 14, 2019 at 01:20:49PM -0300, Ezequiel Garcia wrote: > > It's not entirely obvious why these messages have > > "info" severity. In any case, add a proper driver prefix > > to give the user a bit of context of where they are coming from. > > So the i915 one makes some sense, it's for oom. Which shouldn't happen > often. Then panfrost/msm ones are imo dubious and should be changed to one > of the drm debug ones. Looks like copypasta fail, we might want to change > all of them to drm debugging ones (well maybe keep the i915 one as a drm > info output). Sounds good. I can submit follow up patches for that. Meanwhile, this patch seems good to go, right? Thanks, Ezequiel > -Daniel > > > Signed-off-by: Ezequiel Garcia > > --- > > drivers/gpu/drm/i915/gem/i915_gem_shrinker.c | 2 ++ > > drivers/gpu/drm/msm/msm_gem_shrinker.c | 2 ++ > > drivers/gpu/drm/panfrost/panfrost_gem_shrinker.c | 2 ++ > > 3 files changed, 6 insertions(+) > > > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c > > b/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c > > index 3a926a8755c6..cd0372a1d936 100644 > > --- a/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c > > +++ b/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c > > @@ -4,6 +4,8 @@ > > * Copyright © 2008-2015 Intel Corporation > > */ > > > > +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt > > + > > #include > > #include > > #include > > diff --git a/drivers/gpu/drm/msm/msm_gem_shrinker.c > > b/drivers/gpu/drm/msm/msm_gem_shrinker.c > > index 722d61668a97..0620d441a2cc 100644 > > --- a/drivers/gpu/drm/msm/msm_gem_shrinker.c > > +++ b/drivers/gpu/drm/msm/msm_gem_shrinker.c > > @@ -4,6 +4,8 @@ > > * Author: Rob Clark > > */ > > > > +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt > > + > > #include "msm_drv.h" > > #include "msm_gem.h" > > > > diff --git a/drivers/gpu/drm/panfrost/panfrost_gem_shrinker.c > > b/drivers/gpu/drm/panfrost/panfrost_gem_shrinker.c > > index 458f0fa68111..b9d0e821c3f6 100644 > > --- a/drivers/gpu/drm/panfrost/panfrost_gem_shrinker.c > > +++ b/drivers/gpu/drm/panfrost/panfrost_gem_shrinker.c > > @@ -6,6 +6,8 @@ > > * Author: Rob Clark > > */ > > > > +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt > > + > > #include > > > > #include > > -- > > 2.22.0 > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/rockchip: Add GEM create ioctl support
From: Mark Yao
Add driver-specific GEM create/offset ioctls, to allow users
to create objects of arbitrary size.
These are required to allocate buffers to be shared with
video decoder block, with hardware-specific needs such as
macroblock alignment and extra room for motion vectors.
Signed-off-by: Mark Yao
Signed-off-by: Douglas Anderson
Signed-off-by: Ezequiel Garcia
---
drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 11
drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 21 +++
drivers/gpu/drm/rockchip/rockchip_drm_gem.h | 13 +
include/uapi/drm/rockchip_drm.h | 61 +
4 files changed, 106 insertions(+)
create mode 100644 include/uapi/drm/rockchip_drm.h
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
index ca12a35483f9..bd35a0b1aa5a 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
#include "rockchip_drm_drv.h"
#include "rockchip_drm_fb.h"
@@ -206,6 +207,14 @@ static void rockchip_drm_unbind(struct device *dev)
drm_dev_put(drm_dev);
}
+static const struct drm_ioctl_desc rockchip_ioctls[] = {
+ DRM_IOCTL_DEF_DRV(ROCKCHIP_GEM_CREATE, rockchip_gem_create_ioctl,
+ DRM_UNLOCKED | DRM_AUTH),
+ DRM_IOCTL_DEF_DRV(ROCKCHIP_GEM_MAP_OFFSET,
+ rockchip_gem_map_offset_ioctl,
+ DRM_UNLOCKED | DRM_AUTH),
+};
+
static const struct file_operations rockchip_drm_driver_fops = {
.owner = THIS_MODULE,
.open = drm_open,
@@ -230,6 +239,8 @@ static struct drm_driver rockchip_drm_driver = {
.gem_prime_vmap = rockchip_gem_prime_vmap,
.gem_prime_vunmap = rockchip_gem_prime_vunmap,
.gem_prime_mmap = rockchip_gem_mmap_buf,
+ .ioctls = rockchip_ioctls,
+ .num_ioctls = ARRAY_SIZE(rockchip_ioctls),
.fops = &rockchip_drm_driver_fops,
.name = DRIVER_NAME,
.desc = DRIVER_DESC,
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
index 0d1884684dcb..315fa67d5668 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
@@ -12,6 +12,7 @@
#include
#include
#include
+#include
#include "rockchip_drm_drv.h"
#include "rockchip_drm_gem.h"
@@ -428,6 +429,26 @@ int rockchip_gem_dumb_create(struct drm_file *file_priv,
return PTR_ERR_OR_ZERO(rk_obj);
}
+int rockchip_gem_map_offset_ioctl(struct drm_device *drm, void *data,
+ struct drm_file *file_priv)
+{
+ struct drm_rockchip_gem_map_off *args = data;
+
+ return drm_gem_dumb_map_offset(file_priv, drm, args->handle,
+ &args->offset);
+}
+
+int rockchip_gem_create_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *file_priv)
+{
+ struct drm_rockchip_gem_create *args = data;
+ struct rockchip_gem_object *rk_obj;
+
+ rk_obj = rockchip_gem_create_with_handle(file_priv, dev, args->size,
+&args->handle);
+ return PTR_ERR_OR_ZERO(rk_obj);
+}
+
/*
* Allocate a sg_table for this GEM object.
* Note: Both the table's contents, and the sg_table itself must be freed by
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_gem.h
b/drivers/gpu/drm/rockchip/rockchip_drm_gem.h
index 7ffc541bea07..87fe58b05bf6 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_gem.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_gem.h
@@ -50,4 +50,17 @@ void rockchip_gem_free_object(struct drm_gem_object *obj);
int rockchip_gem_dumb_create(struct drm_file *file_priv,
struct drm_device *dev,
struct drm_mode_create_dumb *args);
+
+/*
+ * request gem object creation and buffer allocation as the size
+ * that it is calculated with framebuffer information such as width,
+ * height and bpp.
+ */
+int rockchip_gem_create_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *file_priv);
+
+/* get buffer offset to map to user space. */
+int rockchip_gem_map_offset_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *file_priv);
+
#endif /* _ROCKCHIP_DRM_GEM_H */
diff --git a/include/uapi/drm/rockchip_drm.h b/include/uapi/drm/rockchip_drm.h
new file mode 100644
index ..3185f72f36b9
--- /dev/null
+++ b/include/uapi/drm/rockchip_drm.h
@@ -0,0 +1,61 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+/*
+ * Copyright (c) Fuzhou Rockchip Electronics Co.Ltd
+ * Authors:
+ * Mark Yao
+ *
+ * base on exynos_drm.h
+ */
+
+#ifndef _ROCKCHIP_DRM_H
+#define _ROCKCHIP
Re: [PATCH libdrm 1/2] modetest: Fix segmentation fault
Hi everyone,
Any feedback here?
At least this one should be pretty straightforward
to merge, so I'm not sure it deserves a 6-month delay.
If anyone can take a look, I'd appreciate it.
Thanks!
Ezequiel
On Mon, 2019-07-22 at 13:08 -0300, Ezequiel Garcia wrote:
> When a mode is set with just a connector "-s foo",
> we get a nasty segmentation fault. Fix it.
>
> Signed-off-by: Ezequiel Garcia
> ---
> tests/modetest/modetest.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
> index e66be6607e00..5e628127a130 100644
> --- a/tests/modetest/modetest.c
> +++ b/tests/modetest/modetest.c
> @@ -1695,6 +1695,8 @@ static int parse_connector(struct pipe_arg *pipe, const
> char *arg)
> return -1;
>
> /* Parse the remaining parameters. */
> + if (!endp)
> + return -1;
> if (*endp == '@') {
> arg = endp + 1;
> pipe->crtc_id = strtoul(arg, &endp, 10);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: shrinker: Add a prefix on purging logs
On Sat, 2019-12-14 at 13:20 -0300, Ezequiel Garcia wrote: > It's not entirely obvious why these messages have > "info" severity. In any case, add a proper driver prefix > to give the user a bit of context of where they are coming from. > > Signed-off-by: Ezequiel Garcia Gentle ping. Thanks, Ezequiel > --- > drivers/gpu/drm/i915/gem/i915_gem_shrinker.c | 2 ++ > drivers/gpu/drm/msm/msm_gem_shrinker.c | 2 ++ > drivers/gpu/drm/panfrost/panfrost_gem_shrinker.c | 2 ++ > 3 files changed, 6 insertions(+) > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c > b/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c > index 3a926a8755c6..cd0372a1d936 100644 > --- a/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c > +++ b/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c > @@ -4,6 +4,8 @@ > * Copyright © 2008-2015 Intel Corporation > */ > > +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt > + > #include > #include > #include > diff --git a/drivers/gpu/drm/msm/msm_gem_shrinker.c > b/drivers/gpu/drm/msm/msm_gem_shrinker.c > index 722d61668a97..0620d441a2cc 100644 > --- a/drivers/gpu/drm/msm/msm_gem_shrinker.c > +++ b/drivers/gpu/drm/msm/msm_gem_shrinker.c > @@ -4,6 +4,8 @@ > * Author: Rob Clark > */ > > +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt > + > #include "msm_drv.h" > #include "msm_gem.h" > > diff --git a/drivers/gpu/drm/panfrost/panfrost_gem_shrinker.c > b/drivers/gpu/drm/panfrost/panfrost_gem_shrinker.c > index 458f0fa68111..b9d0e821c3f6 100644 > --- a/drivers/gpu/drm/panfrost/panfrost_gem_shrinker.c > +++ b/drivers/gpu/drm/panfrost/panfrost_gem_shrinker.c > @@ -6,6 +6,8 @@ > * Author: Rob Clark > */ > > +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt > + > #include > > #include ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/panfrost: Prefix interrupt handlers' names
On Sat, 2019-12-14 at 01:59 -0300, Ezequiel Garcia wrote:
> Currently, the interrupt lines requested by Panfrost
> use unmeaningful names, which adds some obscurity
> to interrupt introspection (i.e. any tool based
> on procfs' interrupts file).
>
> In order to improve this, prefix each requested
> interrupt with the module name: panfrost-{gpu,job,mmu}.
>
> Signed-off-by: Ezequiel Garcia
Gentle ping.
Thanks,
Ezequiel
> ---
> v2:
> * Use consistent naming, as suggested by Alyssa, Neil and Robin.
>
> drivers/gpu/drm/panfrost/panfrost_gpu.c | 2 +-
> drivers/gpu/drm/panfrost/panfrost_job.c | 2 +-
> drivers/gpu/drm/panfrost/panfrost_mmu.c | 6 --
> 3 files changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/panfrost/panfrost_gpu.c
> b/drivers/gpu/drm/panfrost/panfrost_gpu.c
> index f67ed925c0ef..af2aa6b3bce3 100644
> --- a/drivers/gpu/drm/panfrost/panfrost_gpu.c
> +++ b/drivers/gpu/drm/panfrost/panfrost_gpu.c
> @@ -348,7 +348,7 @@ int panfrost_gpu_init(struct panfrost_device *pfdev)
> return -ENODEV;
>
> err = devm_request_irq(pfdev->dev, irq, panfrost_gpu_irq_handler,
> -IRQF_SHARED, "gpu", pfdev);
> +IRQF_SHARED, KBUILD_MODNAME "-gpu", pfdev);
> if (err) {
> dev_err(pfdev->dev, "failed to request gpu irq");
> return err;
> diff --git a/drivers/gpu/drm/panfrost/panfrost_job.c
> b/drivers/gpu/drm/panfrost/panfrost_job.c
> index 05c85f45a0de..3bd79ebb6c40 100644
> --- a/drivers/gpu/drm/panfrost/panfrost_job.c
> +++ b/drivers/gpu/drm/panfrost/panfrost_job.c
> @@ -480,7 +480,7 @@ int panfrost_job_init(struct panfrost_device *pfdev)
> return -ENODEV;
>
> ret = devm_request_irq(pfdev->dev, irq, panfrost_job_irq_handler,
> -IRQF_SHARED, "job", pfdev);
> +IRQF_SHARED, KBUILD_MODNAME "-job", pfdev);
> if (ret) {
> dev_err(pfdev->dev, "failed to request job irq");
> return ret;
> diff --git a/drivers/gpu/drm/panfrost/panfrost_mmu.c
> b/drivers/gpu/drm/panfrost/panfrost_mmu.c
> index 842bdd7cf6be..806958434726 100644
> --- a/drivers/gpu/drm/panfrost/panfrost_mmu.c
> +++ b/drivers/gpu/drm/panfrost/panfrost_mmu.c
> @@ -612,9 +612,11 @@ int panfrost_mmu_init(struct panfrost_device *pfdev)
> if (irq <= 0)
> return -ENODEV;
>
> - err = devm_request_threaded_irq(pfdev->dev, irq,
> panfrost_mmu_irq_handler,
> + err = devm_request_threaded_irq(pfdev->dev, irq,
> + panfrost_mmu_irq_handler,
> panfrost_mmu_irq_handler_thread,
> - IRQF_SHARED, "mmu", pfdev);
> + IRQF_SHARED, KBUILD_MODNAME "-mmu",
> + pfdev);
>
> if (err) {
> dev_err(pfdev->dev, "failed to request mmu irq");
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/5] drm/rockchip: Fix unbind/bind
This series is an attempt to fix the unbind/bind crash (due to an use-after-free bug) found on rockchip-drm driver. The problem lies in the way the driver uses the component API. Currently, rockchip_drm_unbind calls component_unbind_all before drm_mode_config_cleanup, the former releasing the memory where the DRM objects are embedded. The series goal is basically to fix all the components, making proper use of the respective .destroy hooks, making sure there are no use-after-free or double-free issues. The first patch is likely the most controversial, which is required because component_bind_all will call component_unbind without calling drm_mode_config_cleanup, if any component fails to bind. As mentioned above, this is problematic in the DRM framework. Thanks! Ezequiel Ezequiel Garcia (5): component: Add an API to cleanup before unbind drm/rockchip: Fix the device unbind order drm/rockchip: vop: Fix CRTC unbind drm/rockchip: lvds: Fix component unbind drm/rockchip: rk3066_hdmi: Cleanup component unbind drivers/base/component.c| 9 +++- drivers/gpu/drm/rockchip/rk3066_hdmi.c | 8 +-- drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 20 +--- drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 56 - drivers/gpu/drm/rockchip/rockchip_lvds.c| 20 include/linux/component.h | 10 +++- 6 files changed, 60 insertions(+), 63 deletions(-) -- 2.25.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/5] drm/rockchip: lvds: Fix component unbind
Remove the explicit encoder disable: it's
already part of the CRTC shutdown, in both
atomic and legacy API cases.
Also, encoder and connector cleanup is performed
by the DRM .destroy hooks, for encoder and connector
respectively. It can be removed as well.
Finally, move the panel detach call to the connector
.destroy hook, where it belongs.
Signed-off-by: Ezequiel Garcia
---
drivers/gpu/drm/rockchip/rockchip_lvds.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_lvds.c
b/drivers/gpu/drm/rockchip/rockchip_lvds.c
index f25a36743cbd..154f14a317d7 100644
--- a/drivers/gpu/drm/rockchip/rockchip_lvds.c
+++ b/drivers/gpu/drm/rockchip/rockchip_lvds.c
@@ -100,9 +100,18 @@ static inline int rockchip_lvds_name_to_output(const char
*s)
return -EINVAL;
}
+static void
+rockchip_lvds_connector_destroy(struct drm_connector *connector)
+{
+ struct rockchip_lvds *lvds = connector_to_lvds(connector);
+
+ drm_panel_detach(lvds->panel);
+ drm_connector_cleanup(connector);
+}
+
static const struct drm_connector_funcs rockchip_lvds_connector_funcs = {
.fill_modes = drm_helper_probe_single_connector_modes,
- .destroy = drm_connector_cleanup,
+ .destroy = rockchip_lvds_connector_destroy,
.reset = drm_atomic_helper_connector_reset,
.atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
@@ -675,16 +684,7 @@ static int rockchip_lvds_bind(struct device *dev, struct
device *master,
static void rockchip_lvds_unbind(struct device *dev, struct device *master,
void *data)
{
- struct rockchip_lvds *lvds = dev_get_drvdata(dev);
- const struct drm_encoder_helper_funcs *encoder_funcs;
-
- encoder_funcs = lvds->soc_data->helper_funcs;
- encoder_funcs->disable(&lvds->encoder);
- if (lvds->panel)
- drm_panel_detach(lvds->panel);
pm_runtime_disable(dev);
- drm_connector_cleanup(&lvds->connector);
- drm_encoder_cleanup(&lvds->encoder);
}
static const struct component_ops rockchip_lvds_component_ops = {
--
2.25.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/5] drm/rockchip: vop: Fix CRTC unbind
In order to fix device unbinding, the CRTC release path needs to
be fixed. Get rid of the use-after-free issue that arise
for calling drm_crtc_cleanup() prematurely, by moving
all the CRTC resource release to the crtc.destroy() hook.
The vop_unbind() function is only responsible for the release
of driver-specific (i.e. vop-specific) resources.
Signed-off-by: Ezequiel Garcia
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 56 -
1 file changed, 20 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index d04b3492bdac..87c43097da7e 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -1387,6 +1387,11 @@ static const struct drm_crtc_helper_funcs
vop_crtc_helper_funcs = {
static void vop_crtc_destroy(struct drm_crtc *crtc)
{
+ struct vop *vop = to_vop(crtc);
+
+ drm_flip_work_cleanup(&vop->fb_unref_work);
+ drm_self_refresh_helper_cleanup(crtc);
+ of_node_put(crtc->port);
drm_crtc_cleanup(crtc);
}
@@ -1606,12 +1611,22 @@ static void vop_plane_add_properties(struct drm_plane
*plane,
DRM_MODE_ROTATE_0 | flags);
}
+static void vop_plane_cleanup(struct vop *vop)
+{
+ struct drm_device *drm_dev = vop->drm_dev;
+ struct drm_plane *plane, *tmp;
+
+ list_for_each_entry_safe(plane, tmp, &drm_dev->mode_config.plane_list,
+head)
+ drm_plane_cleanup(plane);
+}
+
static int vop_create_crtc(struct vop *vop)
{
const struct vop_data *vop_data = vop->data;
struct device *dev = vop->dev;
struct drm_device *drm_dev = vop->drm_dev;
- struct drm_plane *primary = NULL, *cursor = NULL, *plane, *tmp;
+ struct drm_plane *primary = NULL, *cursor = NULL;
struct drm_crtc *crtc = &vop->crtc;
struct device_node *port;
int ret;
@@ -1625,6 +1640,7 @@ static int vop_create_crtc(struct vop *vop)
for (i = 0; i < vop_data->win_size; i++) {
struct vop_win *vop_win = &vop->win[i];
const struct vop_win_data *win_data = vop_win->data;
+ struct drm_plane *plane;
if (win_data->type != DRM_PLANE_TYPE_PRIMARY &&
win_data->type != DRM_PLANE_TYPE_CURSOR)
@@ -1714,42 +1730,10 @@ static int vop_create_crtc(struct vop *vop)
err_cleanup_crtc:
drm_crtc_cleanup(crtc);
err_cleanup_planes:
- list_for_each_entry_safe(plane, tmp, &drm_dev->mode_config.plane_list,
-head)
- drm_plane_cleanup(plane);
+ vop_plane_cleanup(vop);
return ret;
}
-static void vop_destroy_crtc(struct vop *vop)
-{
- struct drm_crtc *crtc = &vop->crtc;
- struct drm_device *drm_dev = vop->drm_dev;
- struct drm_plane *plane, *tmp;
-
- drm_self_refresh_helper_cleanup(crtc);
-
- of_node_put(crtc->port);
-
- /*
-* We need to cleanup the planes now. Why?
-*
-* The planes are "&vop->win[i].base". That means the memory is
-* all part of the big "struct vop" chunk of memory. That memory
-* was devm allocated and associated with this component. We need to
-* free it ourselves before vop_unbind() finishes.
-*/
- list_for_each_entry_safe(plane, tmp, &drm_dev->mode_config.plane_list,
-head)
- vop_plane_destroy(plane);
-
- /*
-* Destroy CRTC after vop_plane_destroy() since vop_disable_plane()
-* references the CRTC.
-*/
- drm_crtc_cleanup(crtc);
- drm_flip_work_cleanup(&vop->fb_unref_work);
-}
-
static int vop_initial(struct vop *vop)
{
struct reset_control *ahb_rst;
@@ -2020,7 +2004,8 @@ static int vop_bind(struct device *dev, struct device
*master, void *data)
err_disable_pm_runtime:
pm_runtime_disable(&pdev->dev);
- vop_destroy_crtc(vop);
+ vop_plane_cleanup(vop);
+ vop_crtc_destroy(&vop->crtc);
return ret;
}
@@ -2032,7 +2017,6 @@ static void vop_unbind(struct device *dev, struct device
*master, void *data)
rockchip_rgb_fini(vop->rgb);
pm_runtime_disable(dev);
- vop_destroy_crtc(vop);
clk_unprepare(vop->aclk);
clk_unprepare(vop->hclk);
--
2.25.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/5] component: Add an API to cleanup before unbind
Some users of the component API have a special model
for the allocation and release of its resources:
resources are allocated by an API but then
released by other means.
This contrasts with the current component API
assumption: .unbind must undo everything that .bind did.
An example of this is the DRM framework, which expects
registered objects (connectors, planes, CRTCs, etc)
to be released by respective drm_xxx_funcs.destroy hooks.
The drm_xxx_funcs.destroy call is done either directly
by drm_mode_config_cleanup() or in a refcounted fashion,
depending on the type of object.
For example, a DRM CRTC object is registered by
drm_crtc_init_with_planes(), and then released by drm_crtc_cleanup(),
which is normally called from the drm_crtc_funcs.destroy hook.
Now, in this model, drm_mode_config_cleanup() should
always be called before component_unbind() to avoid
use-after-free situations (because each component
has a devres group).
However, component_bind_all() calls component_unbind
on binded components, if any component in the chain
fails to bind.
In order to allow this special case, and following Alan Kay:
"simple things should be simple, complex things should be possible"
introduce an extension to component_bind_all, which takes an extra
cleanup callback, to be called when binding fails to perform
extra cleanup steps.
This new API allows the following simple pattern:
void unbind_cleanup(...)
{
drm_mode_config_cleanup(drm_dev);
}
int foo_bind()
{
component_bind_all_or_cleanup(dev, drm_dev, unbind_cleanup);
}
void foo_unbind()
{
drm_mode_config_cleanup(drm_dev);
component_unbind_all(dev, drm_dev);
}
Each DRM component then uses the respective .destroy
hooks to destroy DRM resources, and the .unbind
hooks to release non-DRM resources.
Arguably, this could be viewed as Very Ugly. However, it handles
this complex case, making it possible to fix the current
unbind crashes that some DRM drivers suffer from,
in a non-invasive way, keeping the DRM resource handling model.
Signed-off-by: Ezequiel Garcia
---
drivers/base/component.c | 9 +++--
include/linux/component.h | 10 +-
2 files changed, 16 insertions(+), 3 deletions(-)
diff --git a/drivers/base/component.c b/drivers/base/component.c
index 532a3a5d8f63..371cff9208cf 100644
--- a/drivers/base/component.c
+++ b/drivers/base/component.c
@@ -622,12 +622,14 @@ static int component_bind(struct component *component,
struct master *master,
* component_bind_all - bind all components of an aggregate driver
* @master_dev: device with the aggregate driver
* @data: opaque pointer, passed to all components
+ * @cleanup: optional cleanup callback.
*
* Binds all components of the aggregate @dev by passing @data to their
* &component_ops.bind functions. Should be called from
* &component_master_ops.bind.
*/
-int component_bind_all(struct device *master_dev, void *data)
+int component_bind_all_or_cleanup(struct device *master_dev,
+ void *data, void (*cleanup)(void *data))
{
struct master *master;
struct component *c;
@@ -650,6 +652,9 @@ int component_bind_all(struct device *master_dev, void
*data)
}
if (ret != 0) {
+ if (cleanup)
+ cleanup(data);
+
for (; i > 0; i--)
if (!master->match->compare[i - 1].duplicate) {
c = master->match->compare[i - 1].component;
@@ -659,7 +664,7 @@ int component_bind_all(struct device *master_dev, void
*data)
return ret;
}
-EXPORT_SYMBOL_GPL(component_bind_all);
+EXPORT_SYMBOL_GPL(component_bind_all_or_cleanup);
static int __component_add(struct device *dev, const struct component_ops *ops,
int subcomponent)
diff --git a/include/linux/component.h b/include/linux/component.h
index 16de18f473d7..1a5c7b772de3 100644
--- a/include/linux/component.h
+++ b/include/linux/component.h
@@ -38,7 +38,15 @@ int component_add_typed(struct device *dev, const struct
component_ops *ops,
int subcomponent);
void component_del(struct device *, const struct component_ops *);
-int component_bind_all(struct device *master, void *master_data);
+int component_bind_all_or_cleanup(struct device *master,
+ void *master_data,
+ void (*cleanup)(void *data));
+
+static inline int component_bind_all(struct device *master, void *master_data)
+{
+ return component_bind_all_or_cleanup(master, master_data, NULL);
+}
+
void component_unbind_all(struct device *master, void *master_data);
struct master;
--
2.25.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/5] drm/rockchip: rk3066_hdmi: Cleanup component unbind
Remove drm_connector_unregister() since it should be
used only by drivers that call drm_dev_register
explicitly.
Also, call the DRM cleanups directly, instead of
(ab)using the destroy hooks, for readability reasons.
Signed-off-by: Ezequiel Garcia
---
drivers/gpu/drm/rockchip/rk3066_hdmi.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rk3066_hdmi.c
b/drivers/gpu/drm/rockchip/rk3066_hdmi.c
index fe203d38664e..5a2d62a2cf50 100644
--- a/drivers/gpu/drm/rockchip/rk3066_hdmi.c
+++ b/drivers/gpu/drm/rockchip/rk3066_hdmi.c
@@ -518,7 +518,6 @@ rk3066_hdmi_probe_single_connector_modes(struct
drm_connector *connector,
static void rk3066_hdmi_connector_destroy(struct drm_connector *connector)
{
- drm_connector_unregister(connector);
drm_connector_cleanup(connector);
}
@@ -819,8 +818,8 @@ static int rk3066_hdmi_bind(struct device *dev, struct
device *master,
return 0;
err_cleanup_hdmi:
- hdmi->connector.funcs->destroy(&hdmi->connector);
- hdmi->encoder.funcs->destroy(&hdmi->encoder);
+ drm_connector_cleanup(&hdmi->connector);
+ drm_encoder_cleanup(&hdmi->encoder);
err_disable_i2c:
i2c_put_adapter(hdmi->ddc);
err_disable_hclk:
@@ -834,9 +833,6 @@ static void rk3066_hdmi_unbind(struct device *dev, struct
device *master,
{
struct rk3066_hdmi *hdmi = dev_get_drvdata(dev);
- hdmi->connector.funcs->destroy(&hdmi->connector);
- hdmi->encoder.funcs->destroy(&hdmi->encoder);
-
i2c_put_adapter(hdmi->ddc);
clk_disable_unprepare(hdmi->hclk);
}
--
2.25.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/5] drm/rockchip: Fix the device unbind order
In order to cleanup the configuration, destroying the components
in the pipeline, the components must be present.
Therefore, cleanup the config first, and unbind the components
later.
Signed-off-by: Ezequiel Garcia
---
drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 20
1 file changed, 12 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
index 20ecb1508a22..ca12a35483f9 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
@@ -108,6 +108,11 @@ static void rockchip_iommu_cleanup(struct drm_device
*drm_dev)
iommu_domain_free(private->domain);
}
+static void unbind_cleanup(void *data)
+{
+ drm_mode_config_cleanup((struct drm_device *)data);
+}
+
static int rockchip_drm_bind(struct device *dev)
{
struct drm_device *drm_dev;
@@ -140,13 +145,13 @@ static int rockchip_drm_bind(struct device *dev)
rockchip_drm_mode_config_init(drm_dev);
/* Try to bind all sub drivers. */
- ret = component_bind_all(dev, drm_dev);
+ ret = component_bind_all_or_cleanup(dev, drm_dev, unbind_cleanup);
if (ret)
- goto err_mode_config_cleanup;
+ goto err_free;
ret = drm_vblank_init(drm_dev, drm_dev->mode_config.num_crtc);
if (ret)
- goto err_unbind_all;
+ goto err_drm_cleanup;
drm_mode_config_reset(drm_dev);
@@ -158,7 +163,7 @@ static int rockchip_drm_bind(struct device *dev)
ret = rockchip_drm_fbdev_init(drm_dev);
if (ret)
- goto err_unbind_all;
+ goto err_drm_cleanup;
/* init kms poll for handling hpd */
drm_kms_helper_poll_init(drm_dev);
@@ -171,10 +176,9 @@ static int rockchip_drm_bind(struct device *dev)
err_kms_helper_poll_fini:
drm_kms_helper_poll_fini(drm_dev);
rockchip_drm_fbdev_fini(drm_dev);
-err_unbind_all:
- component_unbind_all(dev, drm_dev);
-err_mode_config_cleanup:
+err_drm_cleanup:
drm_mode_config_cleanup(drm_dev);
+ component_unbind_all(dev, drm_dev);
rockchip_iommu_cleanup(drm_dev);
err_free:
drm_dev->dev_private = NULL;
@@ -193,8 +197,8 @@ static void rockchip_drm_unbind(struct device *dev)
drm_kms_helper_poll_fini(drm_dev);
drm_atomic_helper_shutdown(drm_dev);
- component_unbind_all(dev, drm_dev);
drm_mode_config_cleanup(drm_dev);
+ component_unbind_all(dev, drm_dev);
rockchip_iommu_cleanup(drm_dev);
drm_dev->dev_private = NULL;
--
2.25.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v22 2/2] drm/bridge: Add I2C based driver for ps8640 bridge
Hi Enric, Note that this series is marked as v22, but it's really the 23th. Some minor comments below, it's looking really now. Reviewed-by: Ezequiel Garcia On Mon, 2019-12-23 at 15:35 +0100, Enric Balletbo i Serra wrote: > From: Jitao Shi > > This patch adds drm_bridge driver for parade DSI to eDP bridge chip. > > Signed-off-by: Jitao Shi > Reviewed-by: Daniel Kurtz > [uli: followed API changes, removed FW update feature] > Signed-off-by: Ulrich Hecht > Signed-off-by: Enric Balletbo i Serra > Tested-by: Hsin-Yi Wang > --- > One of the reviews from Laurent was to use 'i2c_new_ancillary_device'. I > didn't change this for two reasons. > 1) It doesn't have a devm version, so the remove path is more simple > using the devm_i2c_new_dummy_device family. > 2) IIUC the ancillary function is useful when you want to retrieve the > address from the firmware or DT, that's not really the case here, as we > have a base address and fixed offset to the base address which I think > is not configurable. > > Let me know if you still think that I should use the ancillary call. > > Changes in v23: > - Merge mute/unmute functions into one (Nicolas Boichat) > - Use enum for ENABLE/DISABLE instead of bool (Ezequiel Garcia) > - Rename mute/unmute to vdo_control and fix error messages (Nicolas Boichat > and Enric) > - Add space between address and address parameter 'address%02x' (Nicolas > Boichat) > - Add Tested-by Hsin-Yi > - Added me as author after the refactor > > Changes in v22: > - Remove sysfs attributes because are not really used (Enric Balletbo) > - Use enum for address page offsets (Ezequiel Garcia) > - Remove enable tracking (Enric Balletbo) > - Use panel_bridge API (Laurent Pinchart) > - Do not use kernel-doc format for non kernel-doc formatted commands (Enric > Balletbo) > - Remove verbose message for PAGE1_VSTART command (Ezequiel Garcia) > - Use time_is_after_jiffies idiom (Ezequiel Garcia) > - Remove unused macros (Ezequiel Garcia) > - Fix weird alignment in dsi->mode_flags (Laurent Pinchart) > - Use drm_of_find_panel_or_bridge helper (Laurent Pinchart) > - Remove mode-sel-gpios as is not used (Laurent Pinchart) > - Remove error messages to get gpios as the core will already report it > (Enric Balletbo) > - Remove redundant message getting the regulators (Laurent Pinchart) > - Rename sleep-gpios to powerdown-gpios (Laurent Pinchart) > - Use ARRAY_SIZE(ps_bridge->page) instead of MAX_DEV when possible (Laurent > Pinchart) > - Fix race with userspace accessing the sysfs attributes (Laurent Pinchart) > - Remove id_table as is only used on DR platforms (Laurent Pinchart) > - Convert to new i2c device probe() (Laurent Pinchart) > - Use i2c_smbus_read/write helpers instead of open coding it (Laurent > Pinchart) > - Remove unnused global variables (Laurent Pinchart) > - Remove unnused fields in ps8640 struct (Laurent Pinchart) > - Remove commented-out headers (Laurent Pinchart) > > Changes in v21: > - Use devm_i2c_new_dummy_device and fix build issue using deprecated > i2c_new_dummy > - Fix build issue due missing drm_bridge.h > - Do not remove in ps8640_remove device managed resources > > Changes in v19: > - fixed return value of ps8640_probe() when no panel is found > > Changes in v18: > - followed DRM API changes > - use DEVICE_ATTR_RO() > - remove firmware update code > - add SPDX identifier > > Changes in v17: > - remove some unused head files. > - add macros for ps8640 pages. > - remove ddc_i2c client > - add mipi_dsi_device_register_full > - remove the manufacturer from the name and i2c_device_id > > Changes in v16: > - Disable ps8640 DSI MCS Function. > - Rename gpios name more clearly. > - Tune the ps8640 power on sequence. > > Changes in v15: > - Drop drm_connector_(un)register calls from parade ps8640. >The main DRM driver mtk_drm_drv now calls >drm_connector_register_all() after drm_dev_register() in the >mtk_drm_bind() function. That function should iterate over all >connectors and call drm_connector_register() for each of them. >So, remove drm_connector_(un)register calls from parade ps8640. > > Changes in v14: > - update copyright info. > - change bridge_to_ps8640 and connector_to_ps8640 to inline function. > - fix some coding style. > - use sizeof as array counter. > - use drm_get_edid when read edid. > - add mutex when firmware updating. > > Changes in v13: > - add const on data, ps8640_write_bytes(struct i2c_client *client, const u8 > *data, u16 data_len) > - fix PAGE2_SW_REST tyro. > - move the buf[3] init to entrance of the function. > > Changes in
Re: [PATCH v22 1/2] Documentation: bridge: Add documentation for ps8640 DT properties
Hi Enric, Rob,
On Mon, 2019-12-23 at 15:35 +0100, Enric Balletbo i Serra wrote:
> From: Jitao Shi
>
> Add documentation for DT properties supported by
> ps8640 DSI-eDP converter.
>
> Signed-off-by: Jitao Shi
> Acked-by: Rob Herring
> Reviewed-by: Philipp Zabel
> Signed-off-by: Ulrich Hecht
> Signed-off-by: Enric Balletbo i Serra
[..]
> +
> + ports:
> +type: object
> +description:
> + A node containing DSI input & output port nodes with endpoint
> + definitions as documented in
> + Documentation/devicetree/bindings/media/video-interfaces.txt
> + Documentation/devicetree/bindings/graph.txt
> +properties:
> + port@0:
> +type: object
> +description: |
> + Video port for DSI input
> +
> + port@1:
> +type: object
> +description: |
> + Video port for eDP output (panel or connector).
> +
> +required:
> + - port@0
> +
Is it correct to require port@0 ? This could be called port@1
or port@2, and IIUC it should bind the same.
Thanks,
Ezequiel
> +required:
> + - compatible
> + - reg
> + - powerdown-gpios
> + - reset-gpios
> + - vdd12-supply
> + - vdd33-supply
> + - ports
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +#include
> +i2c0 {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +ps8640: edp-bridge@18 {
> +compatible = "parade,ps8640";
> +reg = <0x18>;
> +powerdown-gpios = <&pio 116 GPIO_ACTIVE_LOW>;
> +reset-gpios = <&pio 115 GPIO_ACTIVE_LOW>;
> +vdd12-supply = <&ps8640_fixed_1v2>;
> +vdd33-supply = <&mt6397_vgp2_reg>;
> +
> +ports {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +port@0 {
> +reg = <0>;
> +ps8640_in: endpoint {
> +remote-endpoint = <&dsi0_out>;
> +};
> +};
> +
> +port@1 {
> +reg = <1>;
> +ps8640_out: endpoint {
> +remote-endpoint = <&panel_in>;
> + };
> +};
> +};
> +};
> +};
> +
> --
> 2.20.1
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v21 2/2] drm/bridge: Add I2C based driver for ps8640 bridge
On Wed, 2019-12-18 at 16:21 +0100, Enric Balletbo i Serra wrote: > Hi Ezequiel, > > Many thanks for the review, I am just preparing the next version to send. > [..] > > > + > > > +#define PAGE1_VSTART 0x6b > > > +#define PAGE2_SPI_CFG3 0x82 > > > +#define I2C_TO_SPI_RESET 0x20 > > > +#define PAGE2_ROMADD_BYTE1 0x8e > > > +#define PAGE2_ROMADD_BYTE2 0x8f > > > +#define PAGE2_SWSPI_WDATA0x90 > > > +#define PAGE2_SWSPI_RDATA0x91 > > > +#define PAGE2_SWSPI_LEN 0x92 > > > +#define PAGE2_SWSPI_CTL 0x93 > > > +#define TRIGGER_NO_READBACK 0x05 > > > +#define TRIGGER_READBACK 0x01 > > > +#define PAGE2_SPI_STATUS 0x9e > > > +#define SPI_READY0x0c > > > +#define PAGE2_GPIO_L 0xa6 > > > +#define PAGE2_GPIO_H 0xa7 > > > +#define PS_GPIO9 BIT(1) > > > +#define PAGE2_IROM_CTRL 0xb0 > > > +#define IROM_ENABLE 0xc0 > > > +#define IROM_DISABLE 0x80 > > > +#define PAGE2_SW_RESET 0xbc > > > +#define SPI_SW_RESET BIT(7) > > > +#define MPU_SW_RESET BIT(6) > > > +#define PAGE2_ENCTLSPI_WR0xda > > > +#define PAGE2_I2C_BYPASS 0xea > > > +#define I2C_BYPASS_EN0xd0 > > > +#define PAGE2_MCS_EN 0xf3 > > > +#define MCS_EN BIT(0) > > > +#define PAGE3_SET_ADD0xfe > > > +#define PAGE3_SET_VAL0xff > > > +#define VDO_CTL_ADD 0x13 > > > +#define VDO_DIS 0x18 > > > +#define VDO_EN 0x1c > > > +#define PAGE4_REV_L 0xf0 > > > +#define PAGE4_REV_H 0xf1 > > > +#define PAGE4_CHIP_L 0xf2 > > > +#define PAGE4_CHIP_H 0xf3 > > > + > > > +#define PAGE0_DP_CNTL0 > > > > Unused macro. > > > > > +#define PAGE1_VDO_BDG1 > > > +#define PAGE2_TOP_CNTL 2 > > > +#define PAGE3_DSI_CNTL1 3 > > > +#define PAGE4_MIPI_PHY 4 > > > > Ditto... maybe others as well? > > > > I removed all the unused macros. > In this case, given these PAGEX_XXX refer to the I2C ancillaries, maybe you can leave them. Moreover, I'd put them in an enum, to emphasize their relationship. Regards, Ezequiel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Warnings in DRM code when removing/unbinding a driver
Hi John,
On Mon, 2019-12-16 at 17:23 +, John Garry wrote:
> Hi all,
>
> Enabling CONFIG_DEBUG_TEST_DRIVER_REMOVE causes many warns on a system
> with the HIBMC hw:
>
> [ 27.788806] WARNING: CPU: 24 PID: 1 at
> drivers/gpu/drm/drm_gem_vram_helper.c:564 bo_driver_move_notify+0x8c/0x98
A total shot in the dark. This might make no sense,
but it's worth a try:
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
index 2fd4ca91a62d..69bb0e29da88 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
@@ -247,9 +247,8 @@ static int hibmc_unload(struct drm_device *dev)
{
struct hibmc_drm_private *priv = dev->dev_private;
- hibmc_fbdev_fini(priv);
-
drm_atomic_helper_shutdown(dev);
+ hibmc_fbdev_fini(priv);
if (dev->irq_enabled)
drm_irq_uninstall(dev);
Hope it helps,
Ezequiel
> [ 27.798969] Modules linked in:
> [ 27.802018] CPU: 24 PID: 1 Comm: swapper/0 Tainted: GB
> 5.5.0-rc1-dirty #565
> [ 27.810358] Hardware name: Huawei D06 /D06, BIOS Hisilicon D06 UEFI
> RC0 - V1.16.01 03/15/2019
> [ 27.818872] pstate: 20c9 (nzCv daif +PAN +UAO)
> [ 27.823654] pc : bo_driver_move_notify+0x8c/0x98
> [ 27.828262] lr : bo_driver_move_notify+0x40/0x98
> [ 27.832868] sp : 00236f0677e0
> [ 27.836173] x29: 00236f0677e0 x28: a0001454e5e0
> [ 27.841476] x27: 002366e52128 x26: a000149e67b0
> [ 27.846779] x25: 002366e523e0 x24: 002336936120
> [ 27.852082] x23: 0023346f4010 x22: 002336936128
> [ 27.857385] x21: a000149c15c0 x20: 0023369361f8
> [ 27.862687] x19: 002336936000 x18: 1258
> [ 27.867989] x17: 1190 x16: 11d0
> [ 27.873292] x15: 1348 x14: a00012d68190
> [ 27.878595] x13: 0006 x12: 140003241f91
> [ 27.883897] x11: 940003241f91 x10: dfffa000
> [ 27.889200] x9 : 940003241f92 x8 : 0001
> [ 27.894502] x7 : a0001920fc88 x6 : 940003241f92
> [ 27.899804] x5 : 940003241f92 x4 : 0023369363a0
> [ 27.905107] x3 : a00010c104b8 x2 : dfffa000
> [ 27.910409] x1 : 0003 x0 : 0001
> [ 27.915712] Call trace:
> [ 27.918151] bo_driver_move_notify+0x8c/0x98
> [ 27.922412] ttm_bo_cleanup_memtype_use+0x54/0x100
> [ 27.927194] ttm_bo_put+0x3a0/0x5d0
> [ 27.930673] drm_gem_vram_object_free+0xc/0x18
> [ 27.935109] drm_gem_object_free+0x34/0xd0
> [ 27.939196] drm_gem_object_put_unlocked+0xc8/0xf0
> [ 27.943978] hibmc_user_framebuffer_destroy+0x20/0x40
> [ 27.949020] drm_framebuffer_free+0x48/0x58
> [ 27.953194] drm_mode_object_put.part.1+0x90/0xe8
> [ 27.957889] drm_mode_object_put+0x28/0x38
> [ 27.961976] hibmc_fbdev_fini+0x54/0x78
> [ 27.965802] hibmc_unload+0x2c/0xd0
> [ 27.969281] hibmc_pci_remove+0x2c/0x40
> [ 27.973109] pci_device_remove+0x6c/0x140
> [ 27.977110] really_probe+0x174/0x548
> [ 27.980763] driver_probe_device+0x7c/0x148
> [ 27.984936] device_driver_attach+0x94/0xa0
> [ 27.989109] __driver_attach+0xa8/0x110
> [ 27.992935] bus_for_each_dev+0xe8/0x158
> [ 27.996849] driver_attach+0x30/0x40
> [ 28.000415] bus_add_driver+0x234/0x2f0
> [ 28.004241] driver_register+0xbc/0x1d0
> [ 28.008067] __pci_register_driver+0xbc/0xd0
> [ 28.012329] hibmc_pci_driver_init+0x20/0x28
> [ 28.016590] do_one_initcall+0xb4/0x254
> [ 28.020417] kernel_init_freeable+0x27c/0x328
> [ 28.024765] kernel_init+0x10/0x118
> [ 28.028245] ret_from_fork+0x10/0x18
> [ 28.031813] ---[ end trace 35a83b71b657878d ]---
> [ 28.036503] [ cut here ]
> [ 28.041115] WARNING: CPU: 24 PID: 1 at
> drivers/gpu/drm/drm_gem_vram_helper.c:40 ttm_buffer_object_destroy+0x4c/0x80
> [ 28.051537] Modules linked in:
> [ 28.054585] CPU: 24 PID: 1 Comm: swapper/0 Tainted: GB W
> 5.5.0-rc1-dirty #565
> [ 28.062924] Hardware name: Huawei D06 /D06, BIOS Hisilicon D06 UEFI
> RC0 - V1.16.01 03/15/2019
>
> [snip]
>
> Indeed, simply unbinding the device from the driver causes the same sort
> of issue:
>
> root@(none)$ cd ./bus/pci/drivers/hibmc-drm/
> root@(none)$ ls
> :05:00.0 bind new_idremove_id ueventunbind
> root@(none)$ echo \:05\:00.0 > unbind
> [ 116.074352] [ cut here ]
> [ 116.078978] WARNING: CPU: 17 PID: 1178 at
> drivers/gpu/drm/drm_gem_vram_helper.c:40 ttm_buffer_object_destroy+0x4c/0x80
> [ 116.089661] Modules linked in:
> [ 116.092711] CPU: 17 PID: 1178 Comm: sh Tainted: GB W
> 5.5.0-rc1-dirty #565
> [ 116.100704] Hardware name: Huawei D06 /D06, BIOS Hisilicon D06 UEFI
> RC0 - V1.16.01 03/15/2019
> [ 116.109218] pstate: 2049 (nzCv daif +PAN -UAO)
> [ 116.114001] pc : ttm_buffer_object_destroy+0x4c/0x80
> [ 116.118956] lr : ttm_buffer_object_de
Re: [PATCH v21 2/2] drm/bridge: Add I2C based driver for ps8640 bridge
On Mon, 2019-12-16 at 14:58 +0100, Enric Balletbo i Serra wrote: > From: Jitao Shi > > This patch adds drm_bridge driver for parade DSI to eDP bridge chip. > > Signed-off-by: Jitao Shi > Reviewed-by: Daniel Kurtz > Reviewed-by: Enric Balletbo i Serra > [uli: followed API changes, removed FW update feature] > Signed-off-by: Ulrich Hecht > Signed-off-by: Enric Balletbo i Serra > --- > > Changes in v21: > - Use devm_i2c_new_dummy_device and fix build issue using deprecated > i2c_new_dummy > - Fix build issue due missing drm_bridge.h > - Do not remove in ps8640_remove device managed resources > > Changes in v19: > - fixed return value of ps8640_probe() when no panel is found > > Changes in v18: > - followed DRM API changes > - use DEVICE_ATTR_RO() > - remove firmware update code > - add SPDX identifier > > Changes in v17: > - remove some unused head files. > - add macros for ps8640 pages. > - remove ddc_i2c client > - add mipi_dsi_device_register_full > - remove the manufacturer from the name and i2c_device_id > > Changes in v16: > - Disable ps8640 DSI MCS Function. > - Rename gpios name more clearly. > - Tune the ps8640 power on sequence. > > Changes in v15: > - Drop drm_connector_(un)register calls from parade ps8640. >The main DRM driver mtk_drm_drv now calls >drm_connector_register_all() after drm_dev_register() in the >mtk_drm_bind() function. That function should iterate over all >connectors and call drm_connector_register() for each of them. >So, remove drm_connector_(un)register calls from parade ps8640. > > Changes in v14: > - update copyright info. > - change bridge_to_ps8640 and connector_to_ps8640 to inline function. > - fix some coding style. > - use sizeof as array counter. > - use drm_get_edid when read edid. > - add mutex when firmware updating. > > Changes in v13: > - add const on data, ps8640_write_bytes(struct i2c_client *client, const u8 > *data, u16 data_len) > - fix PAGE2_SW_REST tyro. > - move the buf[3] init to entrance of the function. > > Changes in v12: > - fix hw_chip_id build warning > > Changes in v11: > - Remove depends on I2C, add DRM depends > - Reuse ps8640_write_bytes() in ps8640_write_byte() > - Use timer check for polling like the routines in > - Fix no drm_connector_unregister/drm_connector_cleanup when > ps8640_bridge_attach fail > - Check the ps8640 hardware id in ps8640_validate_firmware > - Remove fw_version check > - Move ps8640_validate_firmware before ps8640_enter_bl > - Add ddc_i2c unregister when probe fail and ps8640_remove > > drivers/gpu/drm/bridge/Kconfig | 11 + > drivers/gpu/drm/bridge/Makefile| 1 + > drivers/gpu/drm/bridge/parade-ps8640.c | 655 + > 3 files changed, 667 insertions(+) > create mode 100644 drivers/gpu/drm/bridge/parade-ps8640.c > > diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig > index 4734f6993858..3e0a63011723 100644 > --- a/drivers/gpu/drm/bridge/Kconfig > +++ b/drivers/gpu/drm/bridge/Kconfig > @@ -101,6 +101,17 @@ config DRM_PARADE_PS8622 > ---help--- > Parade eDP-LVDS bridge chip driver. > > +config DRM_PARADE_PS8640 > + tristate "Parade PS8640 MIPI DSI to eDP Converter" > + depends on OF > + select DRM_KMS_HELPER > + select DRM_MIPI_DSI > + select DRM_PANEL > + help > + Choose this option if you have PS8640 for display > + The PS8640 is a high-performance and low-power > + MIPI DSI to eDP converter > + > config DRM_SIL_SII8620 > tristate "Silicon Image SII8620 HDMI/MHL bridge" > depends on OF > diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile > index 1c0c92667ac4..91490c595b38 100644 > --- a/drivers/gpu/drm/bridge/Makefile > +++ b/drivers/gpu/drm/bridge/Makefile > @@ -8,6 +8,7 @@ obj-$(CONFIG_DRM_LVDS_ENCODER) += lvds-encoder.o > obj-$(CONFIG_DRM_MEGACHIPS_STDP_GE_B850V3_FW) += > megachips-stdp-ge-b850v3-fw.o > obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o > obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o > +obj-$(CONFIG_DRM_PARADE_PS8640) += parade-ps8640.o > obj-$(CONFIG_DRM_SIL_SII8620) += sil-sii8620.o > obj-$(CONFIG_DRM_SII902X) += sii902x.o > obj-$(CONFIG_DRM_SII9234) += sii9234.o > diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c > b/drivers/gpu/drm/bridge/parade-ps8640.c > new file mode 100644 > index ..ab896ceb1a42 > --- /dev/null > +++ b/drivers/gpu/drm/bridge/parade-ps8640.c > @@ -0,0 +1,655 @@ > +// SPDX-License-Identifier: GPL-2.0-only > +/* > + * Copyright (c) 2016 MediaTek Inc. > + */ > + > +#include > +#include > +//#include Commented stuff should gone. > +#include > +#include > +#include > +#include > +#include > +//#include Ditto. > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#define PAGE1_VSTART 0x6b > +#define PAGE2_SPI_CFG3 0x82 > +
Re: [PATCH v4 1/4] drm: bridge: dw_mipi_dsi: access registers via a regmap
Hi Adrian,
Thanks for the patch. This is nice consolidation work.
I'm Ccing Heiko for the Rockchip part.
See below for some comments.
On Mon, 2019-12-02 at 21:33 +0200, AdrianAdrian Ratiu wrote:
> Convert the common bridge code and the two rockchip & stm drivers
> which currently use it to the regmap API in anticipation for further
> changes to make it more generic and add older DSI host controller
> support as found on i.mx6 based devices.
>
> The regmap becomes an internal state of the bridge. No functional
> changes other than requiring the platform drivers to use the
> pre-configured regmap supplied by the bridge after its probe() call
> instead of ioremp'ing the registers themselves.
>
> In subsequent commits the bridge will become able to detect the
> DSI host core version and init the regmap with different register
> layouts. The platform drivers will continue to use the regmap without
> modifications or worrying about the specific layout in use (in other
> words the layout is abstracted away via the regmap).
>
> Suggested-by: Boris Brezillon
> Reviewed-by: Neil Armstrong
> Reviewed-by: Emil Velikov
> Signed-off-by: Adrian Ratiu
> ---
> drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 215 ++
> .../gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 17 +-
At least for Rockchip, I'd rather see this done in two
steps: first some regmap infrastructure introduced,
and then in a follow-up patch, the rockchip driver
moved to it.
It's safer, and better from a bisection POV, and from
a first look it seems doable.
> drivers/gpu/drm/stm/dw_mipi_dsi-stm.c | 34 ++-
It would be good to do try the same for STM. It's also
simpler to review that way.
> include/drm/bridge/dw_mipi_dsi.h | 2 +-
> 4 files changed, 145 insertions(+), 123 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> index b6e793bb653c..6cb57807f3f9 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> @@ -15,6 +15,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> #include
> @@ -226,7 +227,7 @@ struct dw_mipi_dsi {
> struct mipi_dsi_host dsi_host;
> struct drm_bridge *panel_bridge;
> struct device *dev;
> - void __iomem *base;
> + struct regmap *regs;
>
You have the regmap here...
>
> struct clk *pclk;
>
[..]
> @@ -954,7 +952,6 @@ static int dw_mipi_dsi_rockchip_probe(struct
> platform_device *pdev)
> }
>
> dsi->dev = dev;
> - dsi->pdata.base = dsi->base;
> dsi->pdata.max_data_lanes = dsi->cdata->max_data_lanes;
> dsi->pdata.phy_ops = &dw_mipi_dsi_rockchip_phy_ops;
> dsi->pdata.host_ops = &dw_mipi_dsi_rockchip_host_ops;
> @@ -970,6 +967,8 @@ static int dw_mipi_dsi_rockchip_probe(struct
> platform_device *pdev)
> goto err_clkdisable;
> }
>
> + dsi->regs = dsi->pdata.regs;
> +
... and this goes for both STM and Rockchip: I don't think you need neither
the struct dw_mipi_dsi_plat_data.regs nor the
structdw_mipi_dsi_{rockchip, stm}.regs. You should be able to
just access the regmap via the struct dw_mipi_dsi.
[..]
>
> err_dsi_probe:
> @@ -474,7 +472,7 @@ static struct platform_driver dw_mipi_dsi_stm_driver = {
> .remove = dw_mipi_dsi_stm_remove,
> .driver = {
> .of_match_table = dw_mipi_dsi_stm_dt_ids,
> - .name = "stm32-display-dsi",
> + .name = DRIVER_NAME,
Unrelated change, please drop it.
> .pm = &dw_mipi_dsi_stm_pm_ops,
> },
> };
Thanks,
Ezequiel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: shrinker: Add a prefix on purging logs
It's not entirely obvious why these messages have "info" severity. In any case, add a proper driver prefix to give the user a bit of context of where they are coming from. Signed-off-by: Ezequiel Garcia --- drivers/gpu/drm/i915/gem/i915_gem_shrinker.c | 2 ++ drivers/gpu/drm/msm/msm_gem_shrinker.c | 2 ++ drivers/gpu/drm/panfrost/panfrost_gem_shrinker.c | 2 ++ 3 files changed, 6 insertions(+) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c b/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c index 3a926a8755c6..cd0372a1d936 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c @@ -4,6 +4,8 @@ * Copyright © 2008-2015 Intel Corporation */ +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt + #include #include #include diff --git a/drivers/gpu/drm/msm/msm_gem_shrinker.c b/drivers/gpu/drm/msm/msm_gem_shrinker.c index 722d61668a97..0620d441a2cc 100644 --- a/drivers/gpu/drm/msm/msm_gem_shrinker.c +++ b/drivers/gpu/drm/msm/msm_gem_shrinker.c @@ -4,6 +4,8 @@ * Author: Rob Clark */ +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt + #include "msm_drv.h" #include "msm_gem.h" diff --git a/drivers/gpu/drm/panfrost/panfrost_gem_shrinker.c b/drivers/gpu/drm/panfrost/panfrost_gem_shrinker.c index 458f0fa68111..b9d0e821c3f6 100644 --- a/drivers/gpu/drm/panfrost/panfrost_gem_shrinker.c +++ b/drivers/gpu/drm/panfrost/panfrost_gem_shrinker.c @@ -6,6 +6,8 @@ * Author: Rob Clark */ +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt + #include #include -- 2.22.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/panfrost: Prefix interrupt handlers' names
Currently, the interrupt lines requested by Panfrost
use unmeaningful names, which adds some obscurity
to interrupt introspection (i.e. any tool based
on procfs' interrupts file).
In order to improve this, prefix each requested
interrupt with the module name: panfrost-{gpu,job,mmu}.
Signed-off-by: Ezequiel Garcia
---
v2:
* Use consistent naming, as suggested by Alyssa, Neil and Robin.
drivers/gpu/drm/panfrost/panfrost_gpu.c | 2 +-
drivers/gpu/drm/panfrost/panfrost_job.c | 2 +-
drivers/gpu/drm/panfrost/panfrost_mmu.c | 6 --
3 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_gpu.c
b/drivers/gpu/drm/panfrost/panfrost_gpu.c
index f67ed925c0ef..af2aa6b3bce3 100644
--- a/drivers/gpu/drm/panfrost/panfrost_gpu.c
+++ b/drivers/gpu/drm/panfrost/panfrost_gpu.c
@@ -348,7 +348,7 @@ int panfrost_gpu_init(struct panfrost_device *pfdev)
return -ENODEV;
err = devm_request_irq(pfdev->dev, irq, panfrost_gpu_irq_handler,
- IRQF_SHARED, "gpu", pfdev);
+ IRQF_SHARED, KBUILD_MODNAME "-gpu", pfdev);
if (err) {
dev_err(pfdev->dev, "failed to request gpu irq");
return err;
diff --git a/drivers/gpu/drm/panfrost/panfrost_job.c
b/drivers/gpu/drm/panfrost/panfrost_job.c
index 05c85f45a0de..3bd79ebb6c40 100644
--- a/drivers/gpu/drm/panfrost/panfrost_job.c
+++ b/drivers/gpu/drm/panfrost/panfrost_job.c
@@ -480,7 +480,7 @@ int panfrost_job_init(struct panfrost_device *pfdev)
return -ENODEV;
ret = devm_request_irq(pfdev->dev, irq, panfrost_job_irq_handler,
- IRQF_SHARED, "job", pfdev);
+ IRQF_SHARED, KBUILD_MODNAME "-job", pfdev);
if (ret) {
dev_err(pfdev->dev, "failed to request job irq");
return ret;
diff --git a/drivers/gpu/drm/panfrost/panfrost_mmu.c
b/drivers/gpu/drm/panfrost/panfrost_mmu.c
index 842bdd7cf6be..806958434726 100644
--- a/drivers/gpu/drm/panfrost/panfrost_mmu.c
+++ b/drivers/gpu/drm/panfrost/panfrost_mmu.c
@@ -612,9 +612,11 @@ int panfrost_mmu_init(struct panfrost_device *pfdev)
if (irq <= 0)
return -ENODEV;
- err = devm_request_threaded_irq(pfdev->dev, irq,
panfrost_mmu_irq_handler,
+ err = devm_request_threaded_irq(pfdev->dev, irq,
+ panfrost_mmu_irq_handler,
panfrost_mmu_irq_handler_thread,
- IRQF_SHARED, "mmu", pfdev);
+ IRQF_SHARED, KBUILD_MODNAME "-mmu",
+ pfdev);
if (err) {
dev_err(pfdev->dev, "failed to request mmu irq");
--
2.22.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/panfrost: Prefix interrupt handlers' names
Hey everyone,
Thanks for the quick comments.
(Feedback for kernel patches on the same day, am I dreaming??)
On Fri, 2019-12-13 at 13:46 +, Robin Murphy wrote:
> On 13/12/2019 1:18 pm, Neil Armstrong wrote:
> > Hi,
> >
> > On 13/12/2019 13:39, Ezequiel Garcia wrote:
> > > Currently, the interrupt lines requested by Panfrost
> > > use ambiguous names, which adds some obscurity
> > > to interrupt introspection (i.e. any tool based
> > > on procfs' interrupts file).
> > >
> > > In order to improve this, prefix each requested
> > > interrupt with either the module name or the device
> > > name, where possible.
> > >
> > > Signed-off-by: Ezequiel Garcia
> > > ---
> > > drivers/gpu/drm/panfrost/panfrost_gpu.c | 2 +-
> > > drivers/gpu/drm/panfrost/panfrost_job.c | 2 +-
> > > drivers/gpu/drm/panfrost/panfrost_mmu.c | 6 --
> > > 3 files changed, 6 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/panfrost/panfrost_gpu.c
> > > b/drivers/gpu/drm/panfrost/panfrost_gpu.c
> > > index f67ed925c0ef..0355c4a78eaa 100644
> > > --- a/drivers/gpu/drm/panfrost/panfrost_gpu.c
> > > +++ b/drivers/gpu/drm/panfrost/panfrost_gpu.c
> > > @@ -348,7 +348,7 @@ int panfrost_gpu_init(struct panfrost_device *pfdev)
> > > return -ENODEV;
> > >
> > > err = devm_request_irq(pfdev->dev, irq,
> > > panfrost_gpu_irq_handler,
> > > -IRQF_SHARED, "gpu", pfdev);
> > > +IRQF_SHARED, dev_name(pfdev->dev), pfdev);
> > > if (err) {
> > > dev_err(pfdev->dev, "failed to request gpu irq");
> > > return err;
> > > diff --git a/drivers/gpu/drm/panfrost/panfrost_job.c
> > > b/drivers/gpu/drm/panfrost/panfrost_job.c
> > > index 05c85f45a0de..3bd79ebb6c40 100644
> > > --- a/drivers/gpu/drm/panfrost/panfrost_job.c
> > > +++ b/drivers/gpu/drm/panfrost/panfrost_job.c
> > > @@ -480,7 +480,7 @@ int panfrost_job_init(struct panfrost_device *pfdev)
> > > return -ENODEV;
> > >
> > > ret = devm_request_irq(pfdev->dev, irq,
> > > panfrost_job_irq_handler,
> > > -IRQF_SHARED, "job", pfdev);
> > > +IRQF_SHARED, KBUILD_MODNAME "-job", pfdev);
> > > if (ret) {
> > > dev_err(pfdev->dev, "failed to request job irq");
> > > return ret;
> > > diff --git a/drivers/gpu/drm/panfrost/panfrost_mmu.c
> > > b/drivers/gpu/drm/panfrost/panfrost_mmu.c
> > > index 842bdd7cf6be..806958434726 100644
> > > --- a/drivers/gpu/drm/panfrost/panfrost_mmu.c
> > > +++ b/drivers/gpu/drm/panfrost/panfrost_mmu.c
> > > @@ -612,9 +612,11 @@ int panfrost_mmu_init(struct panfrost_device *pfdev)
> > > if (irq <= 0)
> > > return -ENODEV;
> > >
> > > - err = devm_request_threaded_irq(pfdev->dev, irq,
> > > panfrost_mmu_irq_handler,
> > > + err = devm_request_threaded_irq(pfdev->dev, irq,
> > > + panfrost_mmu_irq_handler,
> > > panfrost_mmu_irq_handler_thread,
> > > - IRQF_SHARED, "mmu", pfdev);
> > > + IRQF_SHARED, KBUILD_MODNAME "-mmu",
> > > + pfdev);
> > >
> > > if (err) {
> > > dev_err(pfdev->dev, "failed to request mmu irq");
> > >
> >
> > Why don't you use dev_name(pfdev->dev) everywhere ?
>
> Agreed, while the current implementation may be confusing it is at least
> self-consistent. TBH it would probably be sufficient to save the bother
> of allocating strings and just settle on "panfrost-{gpu,job,mmu}", since
> upstream users are unlikely to ever come across a system with more than
> one Mali in it ;)
>
> And FWIW note that "GPU" really is the specific hardware name of that
> IRQ output; it's not just a generic fill-in for "the one that isn't the
> Job or MMU IRQ".
>
Yeah, that makese sense. So how about we go for "panfrost-{job,mmu}"
and leave the "gpu" one?
Or "panfrost-{gpu,job,mmu}" for consistency?
Thanks,
Eze
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/panfrost: Prefix interrupt handlers' names
Currently, the interrupt lines requested by Panfrost
use ambiguous names, which adds some obscurity
to interrupt introspection (i.e. any tool based
on procfs' interrupts file).
In order to improve this, prefix each requested
interrupt with either the module name or the device
name, where possible.
Signed-off-by: Ezequiel Garcia
---
drivers/gpu/drm/panfrost/panfrost_gpu.c | 2 +-
drivers/gpu/drm/panfrost/panfrost_job.c | 2 +-
drivers/gpu/drm/panfrost/panfrost_mmu.c | 6 --
3 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_gpu.c
b/drivers/gpu/drm/panfrost/panfrost_gpu.c
index f67ed925c0ef..0355c4a78eaa 100644
--- a/drivers/gpu/drm/panfrost/panfrost_gpu.c
+++ b/drivers/gpu/drm/panfrost/panfrost_gpu.c
@@ -348,7 +348,7 @@ int panfrost_gpu_init(struct panfrost_device *pfdev)
return -ENODEV;
err = devm_request_irq(pfdev->dev, irq, panfrost_gpu_irq_handler,
- IRQF_SHARED, "gpu", pfdev);
+ IRQF_SHARED, dev_name(pfdev->dev), pfdev);
if (err) {
dev_err(pfdev->dev, "failed to request gpu irq");
return err;
diff --git a/drivers/gpu/drm/panfrost/panfrost_job.c
b/drivers/gpu/drm/panfrost/panfrost_job.c
index 05c85f45a0de..3bd79ebb6c40 100644
--- a/drivers/gpu/drm/panfrost/panfrost_job.c
+++ b/drivers/gpu/drm/panfrost/panfrost_job.c
@@ -480,7 +480,7 @@ int panfrost_job_init(struct panfrost_device *pfdev)
return -ENODEV;
ret = devm_request_irq(pfdev->dev, irq, panfrost_job_irq_handler,
- IRQF_SHARED, "job", pfdev);
+ IRQF_SHARED, KBUILD_MODNAME "-job", pfdev);
if (ret) {
dev_err(pfdev->dev, "failed to request job irq");
return ret;
diff --git a/drivers/gpu/drm/panfrost/panfrost_mmu.c
b/drivers/gpu/drm/panfrost/panfrost_mmu.c
index 842bdd7cf6be..806958434726 100644
--- a/drivers/gpu/drm/panfrost/panfrost_mmu.c
+++ b/drivers/gpu/drm/panfrost/panfrost_mmu.c
@@ -612,9 +612,11 @@ int panfrost_mmu_init(struct panfrost_device *pfdev)
if (irq <= 0)
return -ENODEV;
- err = devm_request_threaded_irq(pfdev->dev, irq,
panfrost_mmu_irq_handler,
+ err = devm_request_threaded_irq(pfdev->dev, irq,
+ panfrost_mmu_irq_handler,
panfrost_mmu_irq_handler_thread,
- IRQF_SHARED, "mmu", pfdev);
+ IRQF_SHARED, KBUILD_MODNAME "-mmu",
+ pfdev);
if (err) {
dev_err(pfdev->dev, "failed to request mmu irq");
--
2.22.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 00/21] drm: Add support for bus-format negotiation
On Sun, 2019-11-24 at 08:32 +0100, Boris Brezillon wrote: > On Sun, 24 Nov 2019 09:46:41 +0900 > Ezequiel Garcia wrote: > > > Hi Boris, Neil, > > > > On Wed, 2019-10-23 at 17:44 +0200, Boris Brezillon wrote: > > > This patch series aims at adding support for runtime bus-format > > > negotiation between all elements of the > > > 'encoder -> bridges -> connector/display' section of the pipeline. > > > > > > In order to support that, we need drm bridges to fully take part in the > > > atomic state validation process, which requires adding a > > > drm_bridge_state and a new drm_bridge_funcs.atomic_check() hook. > > > Once those basic building blocks are in place, we can add new hooks to > > > allow bus format negotiation (those are called just before > > > ->atomic_check()). The bus format selection is done at runtime by > > > testing all possible combinations across the whole bridge chain until > > > one is reported to work. > > > > > > Major changes since v2: > > > * Get rid of the dummy bridge embedded in drm_encoder and let encoder > > > drivers provide their own bridge element > > > * Clarify APIs and improve the doc > > > * Propagate bus flags by default > > > > > > Major changes since the RFC: > > > > > > * Add a dummy bridge to the drm_encoder object so that vc4 and exynos > > > DSI drivers can implement the pre_enable/post_disable hooks instead > > > of manually setting encoder->bridge to NULL to control the > > > enable/disable sequence. This change is also a first step towards > > > drm_bridge/drm_encoder unification. New encoder drivers should > > > stop implementing drm_encoder_helper_funcs and switch to > > > drm_bridge_funcs. Existing drivers can be converted progressively > > > (already have a branch where I started converting some of them [1]) > > > * rework the bus format negotiation to give more control to bridge > > > drivers in the selection process (driver can select at runtime which > > > input bus format they support for a specific output bus format based > > > on any information available in the connector, crtc and bridge state. > > > > > > A more detailed changelog is provided in each patch. > > > > > > This patch series is also available here [2]. > > > > > > Thanks, > > > > > > Boris > > > > > > [1]https://github.com/bbrezillon/linux-0day/commits/drm-encoder-bridge > > > [2]https://github.com/bbrezillon/linux-0day/commits/drm-bridge-busfmt-v3 > > > > > > *** BLURB HERE *** > > > > > > Boris Brezillon (21): > > > drm/vc4: Declare the DSI encoder as a bridge element > > > drm/exynos: Don't reset bridge->next > > > drm/exynos: Declare the DSI encoder as a bridge element > > > drm/bridge: Rename bridge helpers targeting a bridge chain > > > drm/bridge: Introduce drm_bridge_chain_get_next_bridge() > > > drm: Stop accessing encoder->bridge directly > > > > Patches 1 to 6 seem to be reviewed, and appear as a good > > step forward. > > AFAICT, patch 1 and 3 are not reviewed, which is kind of blocking me > for patch 4-6. I can (and plan to) apply patch 2. Ah, you are right. Let's add Eric for vc4 and Inki for exynos. For reference, here is the series: https://patchwork.kernel.org/project/dri-devel/list/?series=192359 Thanks, Ezequiel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 00/21] drm: Add support for bus-format negotiation
Hi Boris, Neil, On Wed, 2019-10-23 at 17:44 +0200, Boris Brezillon wrote: > This patch series aims at adding support for runtime bus-format > negotiation between all elements of the > 'encoder -> bridges -> connector/display' section of the pipeline. > > In order to support that, we need drm bridges to fully take part in the > atomic state validation process, which requires adding a > drm_bridge_state and a new drm_bridge_funcs.atomic_check() hook. > Once those basic building blocks are in place, we can add new hooks to > allow bus format negotiation (those are called just before > ->atomic_check()). The bus format selection is done at runtime by > testing all possible combinations across the whole bridge chain until > one is reported to work. > > Major changes since v2: > * Get rid of the dummy bridge embedded in drm_encoder and let encoder > drivers provide their own bridge element > * Clarify APIs and improve the doc > * Propagate bus flags by default > > Major changes since the RFC: > > * Add a dummy bridge to the drm_encoder object so that vc4 and exynos > DSI drivers can implement the pre_enable/post_disable hooks instead > of manually setting encoder->bridge to NULL to control the > enable/disable sequence. This change is also a first step towards > drm_bridge/drm_encoder unification. New encoder drivers should > stop implementing drm_encoder_helper_funcs and switch to > drm_bridge_funcs. Existing drivers can be converted progressively > (already have a branch where I started converting some of them [1]) > * rework the bus format negotiation to give more control to bridge > drivers in the selection process (driver can select at runtime which > input bus format they support for a specific output bus format based > on any information available in the connector, crtc and bridge state. > > A more detailed changelog is provided in each patch. > > This patch series is also available here [2]. > > Thanks, > > Boris > > [1]https://github.com/bbrezillon/linux-0day/commits/drm-encoder-bridge > [2]https://github.com/bbrezillon/linux-0day/commits/drm-bridge-busfmt-v3 > > *** BLURB HERE *** > > Boris Brezillon (21): > drm/vc4: Declare the DSI encoder as a bridge element > drm/exynos: Don't reset bridge->next > drm/exynos: Declare the DSI encoder as a bridge element > drm/bridge: Rename bridge helpers targeting a bridge chain > drm/bridge: Introduce drm_bridge_chain_get_next_bridge() > drm: Stop accessing encoder->bridge directly Patches 1 to 6 seem to be reviewed, and appear as a good step forward. Perhaps we can consider merging these first? That way, we can reduce the patches needed to rebase and submit on each iteration. Regards, Ezequiel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv3/RFC 4/4] drm/rockchip: Add support for afbc
Hello Andrzej,
Thanks a lot for the patch.
Reviewed-by: Ezequiel Garcia
On Thu, 2019-11-21 at 18:22 +0100, Andrzej Pietrasiewicz wrote:
> This patch adds support for afbc handling. afbc is a compressed format
> which reduces the necessary memory bandwidth.
>
> Co-developed-by: Mark Yao
> Signed-off-by: Mark Yao
> Signed-off-by: Andrzej Pietrasiewicz
> ---
> drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 29
> drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 142 +++-
> drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 12 ++
> drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 84 +++-
> 4 files changed, 263 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> index ca01234c037c..7eaa3fdc03b2 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> @@ -8,6 +8,7 @@
>
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -18,6 +19,8 @@
> #include "rockchip_drm_fb.h"
> #include "rockchip_drm_gem.h"
>
> +#define ROCKCHIP_MAX_AFBC_WIDTH 2560
> +
> static const struct drm_framebuffer_funcs rockchip_drm_fb_funcs = {
> .destroy = drm_gem_fb_destroy,
> .create_handle = drm_gem_fb_create_handle,
> @@ -32,6 +35,32 @@ rockchip_fb_alloc(struct drm_device *dev, const struct
> drm_mode_fb_cmd2 *mode_cm
> int ret;
> int i;
>
> + if (drm_is_afbc(mode_cmd->modifier[0])) {
> + struct drm_afbc afbc;
> +
> + drm_afbc_get_parameters(mode_cmd, &afbc);
> +
> + if (afbc.offset) {
> + DRM_WARN("AFBC plane offset must be zero!\n");
> +
> + return ERR_PTR(-EINVAL);
> + }
> +
> + if (afbc.tile_w != 16 || afbc.tile_h != 16) {
> + DRM_WARN("Unsupported afbc tile w/h [%d/%d]\n",
> + afbc.tile_w, afbc.tile_h);
> +
I think it's important to stick to using always "AFBC" or
always ", i.e. to be consisten in user messages.
Makes grepping easier.
[..]
> @@ -846,6 +960,23 @@ static void vop_plane_atomic_update(struct drm_plane
> *plane,
>
> spin_lock(&vop->reg_lock);
>
> + if (fb->modifier ==
> + DRM_FORMAT_MOD_ARM_AFBC(AFBC_FORMAT_MOD_BLOCK_SIZE_16x16 |
> + AFBC_FORMAT_MOD_SPARSE)) {
You check this modifier condition a few times, how about
having a helper for it?
> + int afbc_format = vop_convert_afbc_format(fb->format->format);
> +
> + VOP_AFBC_SET(vop, format, afbc_format | AFBC_TILE_16x16);
> + VOP_AFBC_SET(vop, hreg_block_split, 0);
> + VOP_AFBC_SET(vop, win_sel, VOP_WIN_TO_INDEX(vop_win));
> + VOP_AFBC_SET(vop, hdr_ptr, dma_addr);
> + VOP_AFBC_SET(vop, pic_size, act_info);
> +
> + /*
> + * The window being udated becomes the AFBC window
> + */
> + vop->afbc_win = vop_win;
> + }
> +
> VOP_WIN_SET(vop, win, format, format);
> VOP_WIN_SET(vop, win, yrgb_vir, DIV_ROUND_UP(fb->pitches[0], 4));
> VOP_WIN_SET(vop, win, yrgb_mst, dma_addr);
> @@ -1001,6 +1132,7 @@ static const struct drm_plane_funcs vop_plane_funcs = {
> .reset = drm_atomic_helper_plane_reset,
> .atomic_duplicate_state = drm_atomic_helper_plane_duplicate_state,
> .atomic_destroy_state = drm_atomic_helper_plane_destroy_state,
> + .format_mod_supported = rockchip_mod_supported,
> };
>
> static int vop_crtc_enable_vblank(struct drm_crtc *crtc)
> @@ -1340,6 +1472,10 @@ static void vop_crtc_atomic_flush(struct drm_crtc
> *crtc,
>
> spin_lock(&vop->reg_lock);
>
> + /*
> + * Enable AFBC if there is some AFBC window, disable otherwise
> + */
Nitpick: no need for multi-line style comments, if the comment
is a single line. Also, you might want to end the comment with a stop.
Thanks!
Eze
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv3/RFC 1/4] drm/arm: Factor out generic afbc helpers
Hi Andrzej,
Thanks for the series. It's certainly going well.
Please see some minor comments below.
On Thu, 2019-11-21 at 18:22 +0100, Andrzej Pietrasiewicz wrote:
> These are useful for other users of afbc, e.g. rockchip.
>
> Signed-off-by: Andrzej Pietrasiewicz
> ---
> drivers/gpu/drm/Makefile | 2 +-
> drivers/gpu/drm/drm_afbc.c| 84 +++
> drivers/gpu/drm/drm_fourcc.c | 11 +++-
> drivers/gpu/drm/drm_framebuffer.c | 71 +-
> include/drm/drm_afbc.h| 35 +
> 5 files changed, 199 insertions(+), 4 deletions(-)
> create mode 100644 drivers/gpu/drm/drm_afbc.c
> create mode 100644 include/drm/drm_afbc.h
>
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index d9bcc9f2a0a4..3a58f30b83a6 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -44,7 +44,7 @@ drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o
> drm_dsc.o drm_probe_helper
> drm_simple_kms_helper.o drm_modeset_helper.o \
> drm_scdc_helper.o drm_gem_framebuffer_helper.o \
> drm_atomic_state_helper.o drm_damage_helper.o \
> - drm_format_helper.o drm_self_refresh_helper.o
> + drm_format_helper.o drm_self_refresh_helper.o drm_afbc.o
>
> drm_kms_helper-$(CONFIG_DRM_PANEL_BRIDGE) += bridge/panel.o
> drm_kms_helper-$(CONFIG_DRM_FBDEV_EMULATION) += drm_fb_helper.o
> diff --git a/drivers/gpu/drm/drm_afbc.c b/drivers/gpu/drm/drm_afbc.c
> new file mode 100644
> index ..f308c4719546
> --- /dev/null
> +++ b/drivers/gpu/drm/drm_afbc.c
> @@ -0,0 +1,84 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * (C) 2019 Collabora Ltd.
> + *
> + * author: Andrzej Pietrasiewicz
> + *
> + */
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +/**
> + * drm_afbc_get_superblk_wh - extract afbc block width/height from modifier
> + * @modifier: the modifier to be looked at
> + * @w: address of a place to store the block width
> + * @h: address of a place to store the block height
> + *
> + * Returns: true if the modifier describes a supported block size
> + */
> +bool drm_afbc_get_superblk_wh(u64 modifier, u32 *w, u32 *h)
> +{
Name nitpicking: drm_afbc_get_superblock_size. The coding-style
guide has a chapter on naming and suggests avoiding stuff like
"superblk".
> + switch (modifier & AFBC_FORMAT_MOD_BLOCK_SIZE_MASK) {
> + case AFBC_FORMAT_MOD_BLOCK_SIZE_16x16:
> + *w = 16;
> + *h = 16;
> + break;
> + case AFBC_FORMAT_MOD_BLOCK_SIZE_32x8:
> + *w = 32;
> + *h = 8;
> + break;
> + case AFBC_FORMAT_MOD_BLOCK_SIZE_64x4:
> + /* fall through */
> + case AFBC_FORMAT_MOD_BLOCK_SIZE_32x8_64x4:
> + /* fall through */
> + default:
> + DRM_DEBUG_KMS("Invalid AFBC_FORMAT_MOD_BLOCK_SIZE: %lld.\n",
> + modifier & AFBC_FORMAT_MOD_BLOCK_SIZE_MASK);
> + return false;
> + }
> + return true;
> +}
> +EXPORT_SYMBOL_GPL(drm_afbc_get_superblk_wh);
> +
> +/**
> + * drm_afbc_get_parameters - extract afbc parameters from mode command
> + * @mode_cmd: mode command to be looked at
> + * @afbc: address of a struct to be filled in
> + */
> +void drm_afbc_get_parameters(const struct drm_mode_fb_cmd2 *mode_cmd,
> + struct drm_afbc *afbc)
> +{
> + drm_afbc_get_superblk_wh(mode_cmd->modifier[0],
> + &afbc->tile_w, &afbc->tile_h);
> + afbc->width = mode_cmd->pitches[0];
> + afbc->height =
> + DIV_ROUND_UP(mode_cmd->height, afbc->tile_h) * afbc->tile_h;
> + afbc->offset = mode_cmd->offsets[0];
> +}
> +EXPORT_SYMBOL(drm_afbc_get_parameters);
> +
Not sure if this was discussed before, but why some
are EXPORT_SYMBOL and others are exported as _GPL?
> +/**
> + * drm_is_afbc - test if the modifier describes an afbc buffer
> + * @modifier - modifier to be tested
> + *
> + * Returns: true if the modifier describes an afbc buffer
> + */
> +bool drm_is_afbc(u64 modifier)
> +{
> + /* is it ARM AFBC? */
> + if ((modifier & DRM_FORMAT_MOD_ARM_AFBC(0)) == 0)
> + return false;
> +
> + /* Block size must be known */
> + if ((modifier & AFBC_FORMAT_MOD_BLOCK_SIZE_MASK) == 0)
> + return false;
> +
> + return true;
> +}
> +EXPORT_SYMBOL_GPL(drm_is_afbc);
> diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> index c630064ccf41..8d9f197cc0ab 100644
> --- a/drivers/gpu/drm/drm_fourcc.c
> +++ b/drivers/gpu/drm/drm_fourcc.c
> @@ -27,6 +27,7 @@
> #include
> #include
>
> +#include
> #include
> #include
>
> @@ -322,8 +323,14 @@ drm_get_format_info(struct drm_device *dev,
> {
> const struct drm_format_info *info = NULL;
>
> - if (dev->mode_config.funcs->get_format_info)
> - info = dev->mode_config
[PATCH v5 3/3] ARM: dts: rockchip: Add RK3288 VOP gamma LUT address
RK3288 SoC VOPs have optional support Gamma LUT setting,
which requires specifying the Gamma LUT address in the devicetree.
Signed-off-by: Ezequiel Garcia
Reviewed-by: Douglas Anderson
---
Changes from v4:
* None.
Changes from v3:
* None.
Changes from v2:
* None.
Changes from v1:
* Drop reg-names, as suggested by Doug.
---
arch/arm/boot/dts/rk3288.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index cc893e154fe5..c6fc633ace80 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -1023,7 +1023,7 @@
vopb: vop@ff93 {
compatible = "rockchip,rk3288-vop";
- reg = <0x0 0xff93 0x0 0x19c>;
+ reg = <0x0 0xff93 0x0 0x19c>, <0x0 0xff931000 0x0 0x1000>;
interrupts = ;
clocks = <&cru ACLK_VOP0>, <&cru DCLK_VOP0>, <&cru HCLK_VOP0>;
clock-names = "aclk_vop", "dclk_vop", "hclk_vop";
@@ -1073,7 +1073,7 @@
vopl: vop@ff94 {
compatible = "rockchip,rk3288-vop";
- reg = <0x0 0xff94 0x0 0x19c>;
+ reg = <0x0 0xff94 0x0 0x19c>, <0x0 0xff941000 0x0 0x1000>;
interrupts = ;
clocks = <&cru ACLK_VOP1>, <&cru DCLK_VOP1>, <&cru HCLK_VOP1>;
clock-names = "aclk_vop", "dclk_vop", "hclk_vop";
--
2.22.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 2/3] drm/rockchip: Add optional support for CRTC gamma LUT
Add an optional CRTC gamma LUT support, and enable it on RK3288.
This is currently enabled via a separate address resource,
which needs to be specified in the devicetree.
The address resource is required because on some SoCs, such as
RK3288, the LUT address is after the MMU address, and the latter
is supported by a different driver. This prevents the DRM driver
from requesting an entire register space.
The current implementation works for RGB 10-bit tables, as that
is what seems to work on RK3288.
Signed-off-by: Ezequiel Garcia
---
Changes from v4:
* Cleaned-up gamma_set implementation, addressing
feedback from Sean Paul.
Changes from v3:
* Move to atomic_enable and atomic_begin,
as discussed with Sean Paul.
* Dropped the Reviewed-bys.
Changes from v2:
* None.
Changes from v1:
* drop explicit linear LUT after finding a proper
way to disable gamma correction.
* avoid setting gamma is the CRTC is not active.
* s/int/unsigned int as suggested by Jacopo.
* only enable color management and set gamma size
if gamma LUT is supported, suggested by Doug.
* drop the reg-names usage, and instead just use indexed reg
specifiers, suggested by Doug.
Changes from RFC:
* Request (an optional) address resource for the LUT.
* Drop support for RK3399, which doesn't seem to work
out of the box and needs more research.
* Support pass-thru setting when GAMMA_LUT is NULL.
* Add a check for the gamma size, as suggested by Ilia.
* Move gamma setting to atomic_commit_tail, as pointed
out by Jacopo/Laurent, is the correct way.
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 120
drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 2 +
drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 2 +
3 files changed, 124 insertions(+)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 613404f86668..5d9e37ba4aa5 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -139,6 +139,7 @@ struct vop {
uint32_t *regsbak;
void __iomem *regs;
+ void __iomem *lut_regs;
/* physical map length of vop register */
uint32_t len;
@@ -1048,6 +1049,79 @@ static bool vop_crtc_mode_fixup(struct drm_crtc *crtc,
return true;
}
+static bool vop_dsp_lut_is_enabled(struct vop *vop)
+{
+ return vop_read_reg(vop, 0, &vop->data->common->dsp_lut_en);
+}
+
+static void vop_crtc_write_gamma_lut(struct vop *vop, struct drm_crtc *crtc)
+{
+ struct drm_color_lut *lut = crtc->state->gamma_lut->data;
+ unsigned int i;
+
+ for (i = 0; i < crtc->gamma_size; i++) {
+ u32 word;
+
+ word = (drm_color_lut_extract(lut[i].red, 10) << 20) |
+ (drm_color_lut_extract(lut[i].green, 10) << 10) |
+ drm_color_lut_extract(lut[i].blue, 10);
+ writel(word, vop->lut_regs + i * 4);
+ }
+}
+
+static void vop_crtc_gamma_set(struct vop *vop, struct drm_crtc *crtc,
+ struct drm_crtc_state *old_state)
+{
+ struct drm_crtc_state *state = crtc->state;
+ unsigned int idle;
+ int ret;
+
+ if (!vop->lut_regs)
+ return;
+ /*
+* To disable gamma (gamma_lut is null) or to write
+* an update to the LUT, clear dsp_lut_en.
+*/
+ spin_lock(&vop->reg_lock);
+ VOP_REG_SET(vop, common, dsp_lut_en, 0);
+ vop_cfg_done(vop);
+ spin_unlock(&vop->reg_lock);
+
+ /*
+* In order to write the LUT to the internal memory,
+* we need to first make sure the dsp_lut_en bit is cleared.
+*/
+ ret = readx_poll_timeout(vop_dsp_lut_is_enabled, vop,
+idle, !idle, 5, 30 * 1000);
+ if (ret) {
+ DRM_DEV_ERROR(vop->dev, "display LUT RAM enable timeout!\n");
+ return;
+ }
+
+ if (!state->gamma_lut)
+ return;
+
+ spin_lock(&vop->reg_lock);
+ vop_crtc_write_gamma_lut(vop, crtc);
+ VOP_REG_SET(vop, common, dsp_lut_en, 1);
+ vop_cfg_done(vop);
+ spin_unlock(&vop->reg_lock);
+}
+
+static void vop_crtc_atomic_begin(struct drm_crtc *crtc,
+ struct drm_crtc_state *old_crtc_state)
+{
+ struct vop *vop = to_vop(crtc);
+
+ /*
+* Only update GAMMA if the 'active' flag is not changed,
+* otherwise it's updated by .atomic_enable.
+*/
+ if (crtc->state->color_mgmt_changed &&
+ !crtc->state->active_changed)
+ vop_crtc_gamma_set(vop, crtc, old_crtc_state);
+}
+
static void vop_crtc_atomic_enable(struct drm_crtc *crtc,
struct drm_crtc_state *old_state)
{
@@ -1075,6 +1149,14 @@ static void vop_crtc_atomic_enable(
[PATCH v5 1/3] dt-bindings: display: rockchip: document VOP gamma LUT address
Add the register specifier description for an
optional gamma LUT address.
Signed-off-by: Ezequiel Garcia
Reviewed-by: Douglas Anderson
Reviewed-by: Rob Herring
---
Changes from v4:
* None.
Changes from v3:
* None.
Changes from v2:
* None.
Changes from v1:
* Drop reg-names, suggested by Doug.
---
.../devicetree/bindings/display/rockchip/rockchip-vop.txt | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git
a/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt
b/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt
index 4f58c5a2d195..8b3a5f514205 100644
--- a/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt
+++ b/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt
@@ -20,6 +20,10 @@ Required properties:
"rockchip,rk3228-vop";
"rockchip,rk3328-vop";
+- reg: Must contain one entry corresponding to the base address and length
+ of the register space. Can optionally contain a second entry
+ corresponding to the CRTC gamma LUT address.
+
- interrupts: should contain a list of all VOP IP block interrupts in the
order: VSYNC, LCD_SYSTEM. The interrupt specifier
format depends on the interrupt controller used.
@@ -48,7 +52,7 @@ Example:
SoC specific DT entry:
vopb: vopb@ff93 {
compatible = "rockchip,rk3288-vop";
- reg = <0xff93 0x19c>;
+ reg = <0x0 0xff93 0x0 0x19c>, <0x0 0xff931000 0x0 0x1000>;
interrupts = ;
clocks = <&cru ACLK_VOP0>, <&cru DCLK_VOP0>, <&cru HCLK_VOP0>;
clock-names = "aclk_vop", "dclk_vop", "hclk_vop";
--
2.22.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 0/3] RK3288 Gamma LUT
New iteration, seems that we are finally converging. For this v5, we are only doing some changes on the gamma_set implementation. As a result, the code is more readable. See the changelog in patch 2 for more information. Thanks! Ezequiel Garcia (3): dt-bindings: display: rockchip: document VOP gamma LUT address drm/rockchip: Add optional support for CRTC gamma LUT ARM: dts: rockchip: Add RK3288 VOP gamma LUT address .../display/rockchip/rockchip-vop.txt | 6 +- arch/arm/boot/dts/rk3288.dtsi | 4 +- drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 120 ++ drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 2 + drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 2 + 5 files changed, 131 insertions(+), 3 deletions(-) -- 2.22.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 2/3] drm/rockchip: Add optional support for CRTC gamma LUT
Hello Sean,
Thanks for the thourough review.
On Wed, 9 Oct 2019 at 15:01, Sean Paul wrote:
>
> On Tue, Oct 08, 2019 at 08:00:37PM -0300, Ezequiel Garcia wrote:
> > Add an optional CRTC gamma LUT support, and enable it on RK3288.
> > This is currently enabled via a separate address resource,
> > which needs to be specified in the devicetree.
> >
> > The address resource is required because on some SoCs, such as
> > RK3288, the LUT address is after the MMU address, and the latter
> > is supported by a different driver. This prevents the DRM driver
> > from requesting an entire register space.
> >
> > The current implementation works for RGB 10-bit tables, as that
> > is what seems to work on RK3288.
> >
> > Signed-off-by: Ezequiel Garcia
>
> Hey Ezequiel,
> Just a few comments on the actual content of the patch as opposed to my higher
> level comments yesterday. I think we're almost there, thanks for sticking this
> out!
>
> > ---
> > Changes from v3:
> > * Move to atomic_enable and atomic_begin,
> > as discussed with Sean Paul.
> > * Dropped the Reviewed-bys.
> > Changes from v2:
> > * None.
> > Changes from v1:
> > * drop explicit linear LUT after finding a proper
> > way to disable gamma correction.
> > * avoid setting gamma is the CRTC is not active.
> > * s/int/unsigned int as suggested by Jacopo.
> > * only enable color management and set gamma size
> > if gamma LUT is supported, suggested by Doug.
> > * drop the reg-names usage, and instead just use indexed reg
> > specifiers, suggested by Doug.
> > Changes from RFC:
> > * Request (an optional) address resource for the LUT.
> > * Drop support for RK3399, which doesn't seem to work
> > out of the box and needs more research.
> > * Support pass-thru setting when GAMMA_LUT is NULL.
> > * Add a check for the gamma size, as suggested by Ilia.
> > * Move gamma setting to atomic_commit_tail, as pointed
> > out by Jacopo/Laurent, is the correct way.
> > ---
> > drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 1 +
> > drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 125
> > drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 5 +
> > drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 2 +
> > 4 files changed, 133 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> > b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> > index ca01234c037c..697ee04b85cf 100644
> > --- a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> > +++ b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> > @@ -17,6 +17,7 @@
> > #include "rockchip_drm_drv.h"
> > #include "rockchip_drm_fb.h"
> > #include "rockchip_drm_gem.h"
> > +#include "rockchip_drm_vop.h"
>
> Leftover from the previous version?
>
Yup.
> >
> > static const struct drm_framebuffer_funcs rockchip_drm_fb_funcs = {
> > .destroy = drm_gem_fb_destroy,
> > diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> > b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> > index 613404f86668..85c1269a1218 100644
> > --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> > +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> > @@ -139,6 +139,7 @@ struct vop {
> >
> > uint32_t *regsbak;
> > void __iomem *regs;
> > + void __iomem *lut_regs;
> >
> > /* physical map length of vop register */
> > uint32_t len;
> > @@ -1048,6 +1049,84 @@ static bool vop_crtc_mode_fixup(struct drm_crtc
> > *crtc,
> > return true;
> > }
> >
> > +static bool vop_dsp_lut_is_enable(struct vop *vop)
>
> *enabled
>
Good catch.
> > +{
> > + return vop_read_reg(vop, 0, &vop->data->common->dsp_lut_en);
> > +}
> > +
> > +static void vop_crtc_write_gamma_lut(struct vop *vop, struct drm_crtc
> > *crtc)
> > +{
> > + struct drm_color_lut *lut = crtc->state->gamma_lut->data;
> > + unsigned int i;
> > +
> > + for (i = 0; i < crtc->gamma_size; i++) {
> > + u32 word;
> > +
> > + word = (drm_color_lut_extract(lut[i].red, 10) << 20) |
> > +(drm_color_lut_extract(lut[i].green, 10) << 10) |
> > + drm_color_lut_extract(lut[i].blue, 10);
> > + writel(word, vop->lut_regs + i * 4);
> > + }
> > +}
> > +
> > +static void vop_crtc_gamma_set(struct vop *vop, struct drm_crtc *crtc,
> > +
[PATCH v4 2/3] drm/rockchip: Add optional support for CRTC gamma LUT
Add an optional CRTC gamma LUT support, and enable it on RK3288.
This is currently enabled via a separate address resource,
which needs to be specified in the devicetree.
The address resource is required because on some SoCs, such as
RK3288, the LUT address is after the MMU address, and the latter
is supported by a different driver. This prevents the DRM driver
from requesting an entire register space.
The current implementation works for RGB 10-bit tables, as that
is what seems to work on RK3288.
Signed-off-by: Ezequiel Garcia
---
Changes from v3:
* Move to atomic_enable and atomic_begin,
as discussed with Sean Paul.
* Dropped the Reviewed-bys.
Changes from v2:
* None.
Changes from v1:
* drop explicit linear LUT after finding a proper
way to disable gamma correction.
* avoid setting gamma is the CRTC is not active.
* s/int/unsigned int as suggested by Jacopo.
* only enable color management and set gamma size
if gamma LUT is supported, suggested by Doug.
* drop the reg-names usage, and instead just use indexed reg
specifiers, suggested by Doug.
Changes from RFC:
* Request (an optional) address resource for the LUT.
* Drop support for RK3399, which doesn't seem to work
out of the box and needs more research.
* Support pass-thru setting when GAMMA_LUT is NULL.
* Add a check for the gamma size, as suggested by Ilia.
* Move gamma setting to atomic_commit_tail, as pointed
out by Jacopo/Laurent, is the correct way.
---
drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 1 +
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 125
drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 5 +
drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 2 +
4 files changed, 133 insertions(+)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
index ca01234c037c..697ee04b85cf 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
@@ -17,6 +17,7 @@
#include "rockchip_drm_drv.h"
#include "rockchip_drm_fb.h"
#include "rockchip_drm_gem.h"
+#include "rockchip_drm_vop.h"
static const struct drm_framebuffer_funcs rockchip_drm_fb_funcs = {
.destroy = drm_gem_fb_destroy,
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 613404f86668..85c1269a1218 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -139,6 +139,7 @@ struct vop {
uint32_t *regsbak;
void __iomem *regs;
+ void __iomem *lut_regs;
/* physical map length of vop register */
uint32_t len;
@@ -1048,6 +1049,84 @@ static bool vop_crtc_mode_fixup(struct drm_crtc *crtc,
return true;
}
+static bool vop_dsp_lut_is_enable(struct vop *vop)
+{
+ return vop_read_reg(vop, 0, &vop->data->common->dsp_lut_en);
+}
+
+static void vop_crtc_write_gamma_lut(struct vop *vop, struct drm_crtc *crtc)
+{
+ struct drm_color_lut *lut = crtc->state->gamma_lut->data;
+ unsigned int i;
+
+ for (i = 0; i < crtc->gamma_size; i++) {
+ u32 word;
+
+ word = (drm_color_lut_extract(lut[i].red, 10) << 20) |
+ (drm_color_lut_extract(lut[i].green, 10) << 10) |
+ drm_color_lut_extract(lut[i].blue, 10);
+ writel(word, vop->lut_regs + i * 4);
+ }
+}
+
+static void vop_crtc_gamma_set(struct vop *vop, struct drm_crtc *crtc,
+ struct drm_crtc_state *old_crtc_state)
+{
+ unsigned int idle;
+ int ret;
+
+ /*
+* In order to write the LUT to the internal memory,
+* we need to first make sure the dsp_lut_en bit is cleared.
+*/
+ spin_lock(&vop->reg_lock);
+ VOP_REG_SET(vop, common, dsp_lut_en, 0);
+ vop_cfg_done(vop);
+ spin_unlock(&vop->reg_lock);
+
+ /*
+* If the CRTC is not active, dsp_lut_en will not get cleared.
+* Apparently we still need to do the above step to for
+* gamma correction to be disabled.
+*/
+ if (!crtc->state->active)
+ return;
+
+ ret = readx_poll_timeout(vop_dsp_lut_is_enable, vop,
+idle, !idle, 5, 30 * 1000);
+ if (ret) {
+ DRM_DEV_ERROR(vop->dev, "display LUT RAM enable timeout!\n");
+ return;
+ }
+
+ if (crtc->state->gamma_lut &&
+ (!old_crtc_state->gamma_lut || (crtc->state->gamma_lut->base.id !=
+ old_crtc_state->gamma_lut->base.id))) {
+
+ spin_lock(&vop->reg_lock);
+
+ vop_crtc_write_gamma_lut(vop, crtc);
+ VOP_REG_SET(vop, common, dsp_lut_en, 1);
+ vop_cfg_done(vop);
+
+
[PATCH v4 0/3] RK3288 Gamma LUT
Following Sean's comments, here's a new version. On this new iteration, we modify the GAMMA LUT on .atomic_enable and .atomic_begin. With this change, the GAMMA settings are effectively re-applied after resuming the machine, so the previous patch "RFC: drm/atomic-helper: Reapply color transformation after resume" is now dropped. Also, I dropped Reviewed-bys tags on patch 2, given the implementation is a bit different now. Thanks! Ezequiel Garcia (3): dt-bindings: display: rockchip: document VOP gamma LUT address drm/rockchip: Add optional support for CRTC gamma LUT ARM: dts: rockchip: Add RK3288 VOP gamma LUT address .../display/rockchip/rockchip-vop.txt | 6 +- arch/arm/boot/dts/rk3288.dtsi | 4 +- drivers/gpu/drm/rockchip/rockchip_drm_fb.c| 1 + drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 125 ++ drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 5 + drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 2 + 6 files changed, 140 insertions(+), 3 deletions(-) -- 2.22.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 3/3] ARM: dts: rockchip: Add RK3288 VOP gamma LUT address
RK3288 SoC VOPs have optional support Gamma LUT setting,
which requires specifying the Gamma LUT address in the devicetree.
Signed-off-by: Ezequiel Garcia
Reviewed-by: Douglas Anderson
---
Changes from v3:
* None.
Changes from v2:
* None.
Changes from v1:
* Drop reg-names, as suggested by Doug.
---
arch/arm/boot/dts/rk3288.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index cc893e154fe5..c6fc633ace80 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -1023,7 +1023,7 @@
vopb: vop@ff93 {
compatible = "rockchip,rk3288-vop";
- reg = <0x0 0xff93 0x0 0x19c>;
+ reg = <0x0 0xff93 0x0 0x19c>, <0x0 0xff931000 0x0 0x1000>;
interrupts = ;
clocks = <&cru ACLK_VOP0>, <&cru DCLK_VOP0>, <&cru HCLK_VOP0>;
clock-names = "aclk_vop", "dclk_vop", "hclk_vop";
@@ -1073,7 +1073,7 @@
vopl: vop@ff94 {
compatible = "rockchip,rk3288-vop";
- reg = <0x0 0xff94 0x0 0x19c>;
+ reg = <0x0 0xff94 0x0 0x19c>, <0x0 0xff941000 0x0 0x1000>;
interrupts = ;
clocks = <&cru ACLK_VOP1>, <&cru DCLK_VOP1>, <&cru HCLK_VOP1>;
clock-names = "aclk_vop", "dclk_vop", "hclk_vop";
--
2.22.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 1/3] dt-bindings: display: rockchip: document VOP gamma LUT address
Add the register specifier description for an
optional gamma LUT address.
Signed-off-by: Ezequiel Garcia
Reviewed-by: Douglas Anderson
Reviewed-by: Rob Herring
---
Changes from v3:
* None.
Changes from v2:
* None.
Changes from v1:
* Drop reg-names, suggested by Doug.
---
.../devicetree/bindings/display/rockchip/rockchip-vop.txt | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git
a/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt
b/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt
index 4f58c5a2d195..8b3a5f514205 100644
--- a/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt
+++ b/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt
@@ -20,6 +20,10 @@ Required properties:
"rockchip,rk3228-vop";
"rockchip,rk3328-vop";
+- reg: Must contain one entry corresponding to the base address and length
+ of the register space. Can optionally contain a second entry
+ corresponding to the CRTC gamma LUT address.
+
- interrupts: should contain a list of all VOP IP block interrupts in the
order: VSYNC, LCD_SYSTEM. The interrupt specifier
format depends on the interrupt controller used.
@@ -48,7 +52,7 @@ Example:
SoC specific DT entry:
vopb: vopb@ff93 {
compatible = "rockchip,rk3288-vop";
- reg = <0xff93 0x19c>;
+ reg = <0x0 0xff93 0x0 0x19c>, <0x0 0xff931000 0x0 0x1000>;
interrupts = ;
clocks = <&cru ACLK_VOP0>, <&cru DCLK_VOP0>, <&cru HCLK_VOP0>;
clock-names = "aclk_vop", "dclk_vop", "hclk_vop";
--
2.22.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 3/5] drm/rockchip: Add optional support for CRTC gamma LUT
On Tue, 2019-10-08 at 16:03 -0400, Sean Paul wrote:
> On Tue, Oct 08, 2019 at 04:33:35PM -0300, Ezequiel Garcia wrote:
> > On Tue, 2019-10-08 at 16:23 -0300, Ezequiel Garcia wrote:
> > > Hello Sean,
> > >
> > > On Mon, 2019-10-07 at 14:54 -0400, Sean Paul wrote:
> > > > On Mon, Sep 30, 2019 at 07:28:00PM -0300, Ezequiel Garcia wrote:
> > > > > Add an optional CRTC gamma LUT support, and enable it on RK3288.
> > > > > This is currently enabled via a separate address resource,
> > > > > which needs to be specified in the devicetree.
> > > > >
> > > > > The address resource is required because on some SoCs, such as
> > > > > RK3288, the LUT address is after the MMU address, and the latter
> > > > > is supported by a different driver. This prevents the DRM driver
> > > > > from requesting an entire register space.
> > > > >
> > > > > The current implementation works for RGB 10-bit tables, as that
> > > > > is what seems to work on RK3288.
> > > > >
> > > > > Signed-off-by: Ezequiel Garcia
> > > > > Reviewed-by: Douglas Anderson
> > > > > Reviewed-by: Jacopo Mondi
> > > > > ---
> > > > > Changes from v2:
> > > > > * None.
> > > > >
> > > > > Changes from v1:
> > > > > * drop explicit linear LUT after finding a proper
> > > > > way to disable gamma correction.
> > > > > * avoid setting gamma is the CRTC is not active.
> > > > > * s/int/unsigned int as suggested by Jacopo.
> > > > > * only enable color management and set gamma size
> > > > > if gamma LUT is supported, suggested by Doug.
> > > > > * drop the reg-names usage, and instead just use indexed reg
> > > > > specifiers, suggested by Doug.
> > > > >
> > > > > Changes from RFC:
> > > > > * Request (an optional) address resource for the LUT.
> > > > > * Drop support for RK3399, which doesn't seem to work
> > > > > out of the box and needs more research.
> > > > > * Support pass-thru setting when GAMMA_LUT is NULL.
> > > > > * Add a check for the gamma size, as suggested by Ilia.
> > > > > * Move gamma setting to atomic_commit_tail, as pointed
> > > > > out by Jacopo/Laurent, is the correct way.
> > > > > ---
> > > > > drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 3 +
> > > > > drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 114
> > > > >
> > > > > drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 7 ++
> > > > > drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 2 +
> > > > > 4 files changed, 126 insertions(+)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> > > > > b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> > > > > index dba352ec0ee3..fd1d987698ab 100644
> > > > > --- a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> > > > > +++ b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> > > > > @@ -17,6 +17,7 @@
> > > > > #include "rockchip_drm_drv.h"
> > > > > #include "rockchip_drm_fb.h"
> > > > > #include "rockchip_drm_gem.h"
> > > > > +#include "rockchip_drm_vop.h"
> > > > >
> > > > > static const struct drm_framebuffer_funcs rockchip_drm_fb_funcs = {
> > > > > .destroy = drm_gem_fb_destroy,
> > > > > @@ -112,6 +113,8 @@ rockchip_atomic_helper_commit_tail_rpm(struct
> > > > > drm_atomic_state *old_state)
> > > > >
> > > > > drm_atomic_helper_commit_modeset_disables(dev, old_state);
> > > > >
> > > > > + rockchip_drm_vop_gamma_set(old_state);
> > > > > +
> > > >
> > > > Instead of duplicating the commit_tail helper, could you just implement
> > > > .atomic_begin() and call this from there? I think the only hitch is if
> > > > you
> > > > need this to be completed before crtc->atomic_enable(), at which point
> > > > you
> > > > might need to call it from vop_crtc_atomic_enable() and then detect
> > > > that in
> > > > atomic_begin()
> > > >
> > >
> > > I think moving this
Re: [PATCH v3 3/5] drm/rockchip: Add optional support for CRTC gamma LUT
On Tue, 2019-10-08 at 16:23 -0300, Ezequiel Garcia wrote:
> Hello Sean,
>
> On Mon, 2019-10-07 at 14:54 -0400, Sean Paul wrote:
> > On Mon, Sep 30, 2019 at 07:28:00PM -0300, Ezequiel Garcia wrote:
> > > Add an optional CRTC gamma LUT support, and enable it on RK3288.
> > > This is currently enabled via a separate address resource,
> > > which needs to be specified in the devicetree.
> > >
> > > The address resource is required because on some SoCs, such as
> > > RK3288, the LUT address is after the MMU address, and the latter
> > > is supported by a different driver. This prevents the DRM driver
> > > from requesting an entire register space.
> > >
> > > The current implementation works for RGB 10-bit tables, as that
> > > is what seems to work on RK3288.
> > >
> > > Signed-off-by: Ezequiel Garcia
> > > Reviewed-by: Douglas Anderson
> > > Reviewed-by: Jacopo Mondi
> > > ---
> > > Changes from v2:
> > > * None.
> > >
> > > Changes from v1:
> > > * drop explicit linear LUT after finding a proper
> > > way to disable gamma correction.
> > > * avoid setting gamma is the CRTC is not active.
> > > * s/int/unsigned int as suggested by Jacopo.
> > > * only enable color management and set gamma size
> > > if gamma LUT is supported, suggested by Doug.
> > > * drop the reg-names usage, and instead just use indexed reg
> > > specifiers, suggested by Doug.
> > >
> > > Changes from RFC:
> > > * Request (an optional) address resource for the LUT.
> > > * Drop support for RK3399, which doesn't seem to work
> > > out of the box and needs more research.
> > > * Support pass-thru setting when GAMMA_LUT is NULL.
> > > * Add a check for the gamma size, as suggested by Ilia.
> > > * Move gamma setting to atomic_commit_tail, as pointed
> > > out by Jacopo/Laurent, is the correct way.
> > > ---
> > > drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 3 +
> > > drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 114
> > > drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 7 ++
> > > drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 2 +
> > > 4 files changed, 126 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> > > b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> > > index dba352ec0ee3..fd1d987698ab 100644
> > > --- a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> > > +++ b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> > > @@ -17,6 +17,7 @@
> > > #include "rockchip_drm_drv.h"
> > > #include "rockchip_drm_fb.h"
> > > #include "rockchip_drm_gem.h"
> > > +#include "rockchip_drm_vop.h"
> > >
> > > static const struct drm_framebuffer_funcs rockchip_drm_fb_funcs = {
> > > .destroy = drm_gem_fb_destroy,
> > > @@ -112,6 +113,8 @@ rockchip_atomic_helper_commit_tail_rpm(struct
> > > drm_atomic_state *old_state)
> > >
> > > drm_atomic_helper_commit_modeset_disables(dev, old_state);
> > >
> > > + rockchip_drm_vop_gamma_set(old_state);
> > > +
> >
> > Instead of duplicating the commit_tail helper, could you just implement
> > .atomic_begin() and call this from there? I think the only hitch is if you
> > need this to be completed before crtc->atomic_enable(), at which point you
> > might need to call it from vop_crtc_atomic_enable() and then detect that in
> > atomic_begin()
> >
>
> I think moving this to .atomic_begin might be enough. Let me send a new
> series and we can see how that goes.
>
Oh, before going forward, pleaste note that the first iteration
of this patch (as noted in the changelog) was applying the gamma lut
on .atomic_flush. However, Laurent and Jacopo pointed out that
it might add some tearing to do so, and that's why it was moved
to commit_tail.
I have to admit I'm not too sure about the difference between
applying this gamma LUT on atomic_begin or atomic_flush,
perhaps you can clarify that?
Thanks!
Ezequiel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 3/5] drm/rockchip: Add optional support for CRTC gamma LUT
Hello Sean,
On Mon, 2019-10-07 at 14:54 -0400, Sean Paul wrote:
> On Mon, Sep 30, 2019 at 07:28:00PM -0300, Ezequiel Garcia wrote:
> > Add an optional CRTC gamma LUT support, and enable it on RK3288.
> > This is currently enabled via a separate address resource,
> > which needs to be specified in the devicetree.
> >
> > The address resource is required because on some SoCs, such as
> > RK3288, the LUT address is after the MMU address, and the latter
> > is supported by a different driver. This prevents the DRM driver
> > from requesting an entire register space.
> >
> > The current implementation works for RGB 10-bit tables, as that
> > is what seems to work on RK3288.
> >
> > Signed-off-by: Ezequiel Garcia
> > Reviewed-by: Douglas Anderson
> > Reviewed-by: Jacopo Mondi
> > ---
> > Changes from v2:
> > * None.
> >
> > Changes from v1:
> > * drop explicit linear LUT after finding a proper
> > way to disable gamma correction.
> > * avoid setting gamma is the CRTC is not active.
> > * s/int/unsigned int as suggested by Jacopo.
> > * only enable color management and set gamma size
> > if gamma LUT is supported, suggested by Doug.
> > * drop the reg-names usage, and instead just use indexed reg
> > specifiers, suggested by Doug.
> >
> > Changes from RFC:
> > * Request (an optional) address resource for the LUT.
> > * Drop support for RK3399, which doesn't seem to work
> > out of the box and needs more research.
> > * Support pass-thru setting when GAMMA_LUT is NULL.
> > * Add a check for the gamma size, as suggested by Ilia.
> > * Move gamma setting to atomic_commit_tail, as pointed
> > out by Jacopo/Laurent, is the correct way.
> > ---
> > drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 3 +
> > drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 114
> > drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 7 ++
> > drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 2 +
> > 4 files changed, 126 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> > b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> > index dba352ec0ee3..fd1d987698ab 100644
> > --- a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> > +++ b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> > @@ -17,6 +17,7 @@
> > #include "rockchip_drm_drv.h"
> > #include "rockchip_drm_fb.h"
> > #include "rockchip_drm_gem.h"
> > +#include "rockchip_drm_vop.h"
> >
> > static const struct drm_framebuffer_funcs rockchip_drm_fb_funcs = {
> > .destroy = drm_gem_fb_destroy,
> > @@ -112,6 +113,8 @@ rockchip_atomic_helper_commit_tail_rpm(struct
> > drm_atomic_state *old_state)
> >
> > drm_atomic_helper_commit_modeset_disables(dev, old_state);
> >
> > + rockchip_drm_vop_gamma_set(old_state);
> > +
>
> Instead of duplicating the commit_tail helper, could you just implement
> .atomic_begin() and call this from there? I think the only hitch is if you
> need this to be completed before crtc->atomic_enable(), at which point you
> might need to call it from vop_crtc_atomic_enable() and then detect that in
> atomic_begin()
>
I think moving this to .atomic_begin might be enough. Let me send a new
series and we can see how that goes.
Thanks for reviewing,
Ezequiel
[PATCH v3 4/5] ARM: dts: rockchip: Add RK3288 VOP gamma LUT address
RK3288 SoC VOPs have optional support Gamma LUT setting,
which requires specifying the Gamma LUT address in the devicetree.
Signed-off-by: Ezequiel Garcia
Reviewed-by: Douglas Anderson
---
Changes from v2:
* None.
Changes from v1:
* Drop reg-names, as suggested by Doug.
---
arch/arm/boot/dts/rk3288.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index cc893e154fe5..c6fc633ace80 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -1023,7 +1023,7 @@
vopb: vop@ff93 {
compatible = "rockchip,rk3288-vop";
- reg = <0x0 0xff93 0x0 0x19c>;
+ reg = <0x0 0xff93 0x0 0x19c>, <0x0 0xff931000 0x0 0x1000>;
interrupts = ;
clocks = <&cru ACLK_VOP0>, <&cru DCLK_VOP0>, <&cru HCLK_VOP0>;
clock-names = "aclk_vop", "dclk_vop", "hclk_vop";
@@ -1073,7 +1073,7 @@
vopl: vop@ff94 {
compatible = "rockchip,rk3288-vop";
- reg = <0x0 0xff94 0x0 0x19c>;
+ reg = <0x0 0xff94 0x0 0x19c>, <0x0 0xff941000 0x0 0x1000>;
interrupts = ;
clocks = <&cru ACLK_VOP1>, <&cru DCLK_VOP1>, <&cru HCLK_VOP1>;
clock-names = "aclk_vop", "dclk_vop", "hclk_vop";
--
2.22.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
