Re: [PATCH v2] fbmem: don't allow too huge resolutions
On Wed, Sep 1, 2021 at 3:15 AM Tetsuo Handa
wrote:
> syzbot is reporting page fault at vga16fb_fillrect() [1], for
> vga16fb_check_var() is failing to detect multiplication overflow.
>
> if (vxres * vyres > maxmem) {
> vyres = maxmem / vxres;
> if (vyres < yres)
> return -ENOMEM;
> }
>
> Since no module would accept too huge resolutions where multiplication
> overflow happens, let's reject in the common path.
>
> Link: https://syzkaller.appspot.com/bug?extid=04168c8063cfdde1db5e [1]
> Reported-by: syzbot
> Debugged-by: Randy Dunlap
> Signed-off-by: Tetsuo Handa
Reviewed-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 2/5] drm/ttm: add busy and idle placement flags
Am 31.08.21 um 15:18 schrieb Daniel Vetter: On Tue, Aug 31, 2021 at 01:21:07PM +0200, Christian König wrote: More flexible than the busy placements. Signed-off-by: Christian König --- drivers/gpu/drm/ttm/ttm_bo.c| 8 +++- include/drm/ttm/ttm_placement.h | 6 ++ 2 files changed, 13 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c index 0a3127436f61..c7034040c67f 100644 --- a/drivers/gpu/drm/ttm/ttm_bo.c +++ b/drivers/gpu/drm/ttm/ttm_bo.c @@ -834,6 +834,9 @@ int ttm_bo_mem_space(struct ttm_buffer_object *bo, const struct ttm_place *place = &placement->placement[i]; struct ttm_resource_manager *man; + if (place->flags & TTM_PL_FLAG_BUSY) + continue; + man = ttm_manager_type(bdev, place->mem_type); if (!man || !ttm_resource_manager_used(man)) continue; @@ -860,6 +863,9 @@ int ttm_bo_mem_space(struct ttm_buffer_object *bo, const struct ttm_place *place = &placement->busy_placement[i]; struct ttm_resource_manager *man; + if (place->flags & TTM_PL_FLAG_IDLE) + continue; + man = ttm_manager_type(bdev, place->mem_type); if (!man || !ttm_resource_manager_used(man)) continue; @@ -869,7 +875,7 @@ int ttm_bo_mem_space(struct ttm_buffer_object *bo, if (likely(!ret)) return 0; - if (ret && ret != -EBUSY) + if (ret != -EBUSY) goto error; } diff --git a/include/drm/ttm/ttm_placement.h b/include/drm/ttm/ttm_placement.h index 8995c9e4ec1b..63f7217354c0 100644 --- a/include/drm/ttm/ttm_placement.h +++ b/include/drm/ttm/ttm_placement.h @@ -53,6 +53,12 @@ /* For multihop handling */ #define TTM_PL_FLAG_TEMPORARY (1 << 2) +/* Placement is only used when we are evicting */ +#define TTM_PL_FLAG_BUSY (1 << 3) + +/* Placement is only used when we are not evicting */ +#define TTM_PL_FLAG_IDLE (1 << 4) Using an enum for this (with BIT() macro or so) and then slapping kerneldoc on top would be nice. That way you can also use the same enum in parameters and structures and it's all a bit easier to find and connect. I don't really like to define flags as enums since they are not really an enumeration. But some more kerneldoc sounds like a good idea to me. Otherwise I think this series makes sense, but probably better for nouveau folks to do review/testing. Yeah, agree completely. I can do some smoke testing with nouveau, but that's about it. Christian. -Daniel + /** * struct ttm_place * -- 2.25.1
[PATCH] dma-buf: cleanup kerneldoc of removed component
The seqno-fence was removed, cleanup the kerneldoc include as well.
Signed-off-by: Christian König
Fixes: 992c238188a8 ("dma-buf: nuke seqno-fence")
---
Documentation/driver-api/dma-buf.rst | 6 --
1 file changed, 6 deletions(-)
diff --git a/Documentation/driver-api/dma-buf.rst
b/Documentation/driver-api/dma-buf.rst
index f5ac4c90b237..2cd7db82d9fe 100644
--- a/Documentation/driver-api/dma-buf.rst
+++ b/Documentation/driver-api/dma-buf.rst
@@ -176,12 +176,6 @@ DMA Fences Functions Reference
.. kernel-doc:: include/linux/dma-fence.h
:internal:
-Seqno Hardware Fences
-~
-
-.. kernel-doc:: include/linux/seqno-fence.h
- :internal:
-
DMA Fence Array
~~~
--
2.25.1
Re: [diagnostic TDR mode patches] unify our solution opinions/suggestions in one thread
Hi Monk, On Wed, Sep 1, 2021 at 3:23 AM Liu, Monk wrote: > > [AMD Official Use Only] > > > Hi Daniel/Christian/Andrey > > > > It looks the voice from you three are spread over those email floods to me, > the feature we are working on (diagnostic TDR scheme) is pending there for > more than 6 month (we started it from feb 2021). For me your project exists since a few weeks at most, because that is when your team showed up on dri-devel. That you already spent 6 months on this within amd, on a code area that very much affects shared code, without kicking of any thread on dri-devel isn't great, but also not something we can fix, since time machines don't exist. So we have to make the best out of the situation and move ahead where we are. From my understanding you've done a bunch of changes to the scheduler code. As far as I can see there's been two related things your team has done: - remove some allocations from scheduler code, because that can lead to deadlocks. I've kicked up this topic quite a while ago here https://lore.kernel.org/dri-devel/20200604081224.863494-10-daniel.vet...@ffwll.ch/ This is just one patch of the entire series. This is an area where we really need a consistent solution across all drm/sched drivers, not something that individual drivers just fix in their own way. - the other one is the timeout issue for the patches you cite here. Again there's been discussion on this on dri-devel with Boris from panfrost about how we can handle at least some of the races in tdr. That resulted in lots of discussions and documentation improvements. Those patches are merged now, link https://lore.kernel.org/dri-devel/20210625133327.2598825-2-boris.brezil...@collabora.com/ There's been more than just this, also quite some doc patches from Boris that explain how it's all supposed to work and be race-free. Again your driver isn't the only one with interesting TDR races. Your team hasn't been active in any of these discussions, but now suddenly pops up out of nowhere and demands that your approach needs to land asap. That's really not how upstream works. The other thing where I'm struggling is that there's a lot of missing context for outsiders. The patches sometimes come with zero commit message, for tricky concurrency bugs. And there's no context with what you've done already on the amdgpu side (since that never showed up on dri-devel), which makes constructive discussions here really hard. Now fixing these bugs is obviously good, but the way this is supposed to work when touching shared infrastructure is: - Before you start merging anything kick off an RFC thread on dri-devel (or whatever the topic really is about) about the problem you have and how your trying to solve it. This can be just text if it's a big thing, but it can also already include some proof of concept solution in the form of patches. - Then we iterate on the solution, across drivers and shared code _together_. Not "merge amdgpu code first, then get annoyed when the core changes don't land immediately after you've practially finished the project". - This might mean changes to other drivers if we need to adjust interfaces. On the plus side you can plan much better, because you know you have upstream buy-in before you start to put in real work on the project. > Honestly speaking the email ways that we are using now is not friendly and > quite painful to me …. Yes this is painful :-( I think the best way forward is to go through the above process again and essentially restart. So submit a complete patch series with problem descriptions, solution you picked, why you picked that, all the amdgpu patches to get there and the core patches too. Since it sounds like a bunch of this has all landed already you probably need a patch 1 that goes back to 6 months ago so that we can see the overall direction, and review whether that's the right one or not. The not-so-painful approach would have been to do this from the start, 6 months ago. It would definitely have helped if the tdr discussion we've had just a few months ago would have involved your team too, I'm sure there would have been some good insights from amd's side. I'd really want you and your engineers involved here, so let's do this properly! Cheers, Daniel > Can we try to put all our opinions, suggestions, or even objects here > together, let’s go through them one by one, it’s too hard for us to reply > each email on different questions . > > > > For [PATCH 1/2] drm/sched: fix the bug of time out calculation(v4) > > > > This is a fixing patch on the timeout timer in scheduler, can we complete > this one first ? it should already resolved all the questions and suggestions. > > > > For [PATCH 2/2] drm/sched: serialize job_timeout and scheduler > > > > I think I already explained the questions raised by Daniel in other thread , > regarding why I use __kthread_should_park() > > For other aspects, can we put all our opinion synthesized here ? > > > > Thanks ! > > > > -
[PATCH v6, 00/15] Using component framework to support multi hardware decode
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
Changes compared with v4:
- Fix comments for patch 4/15
>> + if (dev->is_comp_supported) {
>> + ret = mtk_vcodec_init_master(dev);
>> + if (ret < 0)
>> + goto err_component_match;
>> + } else {
>> + platform_set_drvdata(pdev, dev);
>> + }
Fix platform_set_drvdata.
- Fix build error for patch 9/15
- Add depend patch in case of error header file for patch 13/15
Changes compared with v3:
- Fix return value for patch 1/15
- Fix comments for patch 4/15
> Looking up "mediatek,mtk-vcodec-core" to determine if it uses component
framwork sounds like...
Add prameter in pdata, for all platform will use compoent after mt8183
>> + if (dev->is_comp_supported) {
>> + ret = mtk_vcodec_init_master(dev);
>> + if (ret < 0)
>> + goto err_component_match;
>> + } else {
>> + platform_set_drvdata(pdev, dev);
>> + }
> + Has asked the same question in [1]. Why it removes the
> +platform_set_drvdata() above? mtk_vcodec_init_master() also calls
platform_set_drvdata().
Must call component_master_add_with_match after platform_set_drvdata for
component architecture.
- Fix yaml files check fail for patch 5/15
- Fix yaml file check fail for patch 14/15
Changes compared with v1:
- Fix many comments for patch 3/14
- Remove unnecessary code for patch 4/14
- Using enum mtk_vdec_hw_count instead of magic numbers for patch 6/14
- Reconstructed get/put lat buffer for lat and core hardware for patch 7/14
- Using yaml format to instead of txt file for patch 12/14
Yunfei Dong (15):
media: mtk-vcodec: Get numbers of register bases from DT
media: mtk-vcodec: Align vcodec wake up interrupt interface
media: mtk-vcodec: Refactor vcodec pm interface
media: mtk-vcodec: Use component framework to manage each hardware
information
dt-bindings: media: mtk-vcodec: Separate video encoder and decoder
dt-bindings
media: mtk-vcodec: Use pure single core for MT8183
media: mtk-vcodec: Add irq interface for multi hardware
media: mtk-vcodec: Add msg queue feature for lat and core architecture
media: mtk-vcodec: Generalize power and clock on/off interfaces
media: mtk-vcodec: Add new interface to lock different hardware
media: mtk-vcodec: Add core thread
media: mtk-vcodec: Support 34bits dma address for vdec
dt-bindings: media: mtk-vcodec: Adds decoder dt-bindings for mt8192
media: mtk-vcodec: Add core dec and dec end ipi msg
media: mtk-vcodec: Use codec type to separate different hardware
.../media/mediatek,vcodec-comp-decoder.yaml | 192
.../media/mediatek,vcodec-decoder.yaml| 175 +++
.../media/mediatek,vcodec-encoder.yaml| 185 +++
.../bindings/media/mediatek-vcodec.txt| 130
drivers/media/platform/mtk-vcodec/Makefile| 2 +
.../platform/mtk-vcodec/mtk_vcodec_dec.c | 4 +-
.../platform/mtk-vcodec/mtk_vcodec_dec.h | 1 +
.../platform/mtk-vcodec/mtk_vcodec_dec_drv.c | 276 ++---
.../platform/mtk-vcodec/mtk_vcodec_dec_hw.c | 184 +++
.../platform/mtk-vcodec/mtk_vcodec_dec_hw.h | 53
.../platform/mtk-vcodec/mtk_vcodec_dec_pm.c | 98 --
.../platform/mtk-vcodec/mtk_vcodec_dec_pm.h | 13 +-
.../mtk-vcodec/mtk_vcodec_dec_stateful.c | 2 +
.../mtk-vcodec/mtk_vcodec_dec_stateless.c | 2 +
.../platform/mtk-vcodec/mtk_vcodec_drv.h | 71 -
.../platform/mtk-vcodec/mtk_vcodec_enc_drv.c | 12 +-
.../platform/mtk-
[PATCH v6, 02/15] media: mtk-vcodec: Align vcodec wake up interrupt interface
Vdec and venc can use the same function to wake up interrupt event.
Reviewed-by: Tzung-Bi Shih
Signed-off-by: Yunfei Dong
---
drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c | 9 +
drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h | 8
drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_drv.c | 8
3 files changed, 9 insertions(+), 16 deletions(-)
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 983e0f2831af..8db9cdc66043 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c
@@ -31,13 +31,6 @@
module_param(mtk_v4l2_dbg_level, int, 0644);
module_param(mtk_vcodec_dbg, bool, 0644);
-/* Wake up context wait_queue */
-static void wake_up_ctx(struct mtk_vcodec_ctx *ctx)
-{
- ctx->int_cond = 1;
- wake_up_interruptible(&ctx->queue);
-}
-
static irqreturn_t mtk_vcodec_dec_irq_handler(int irq, void *priv)
{
struct mtk_vcodec_dev *dev = priv;
@@ -69,7 +62,7 @@ static irqreturn_t mtk_vcodec_dec_irq_handler(int irq, void
*priv)
writel((readl(vdec_misc_addr) & ~VDEC_IRQ_CLR),
dev->reg_base[VDEC_MISC] + VDEC_IRQ_CFG_REG);
- wake_up_ctx(ctx);
+ wake_up_ctx(ctx, MTK_INST_IRQ_RECEIVED);
mtk_v4l2_debug(3,
"mtk_vcodec_dec_irq_handler :wake up ctx %d,
dec_done_status=%x",
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
index d4f840a7bbcb..3b1e5e3a450e 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
@@ -472,4 +472,12 @@ static inline struct mtk_vcodec_ctx *ctrl_to_ctx(struct
v4l2_ctrl *ctrl)
return container_of(ctrl->handler, struct mtk_vcodec_ctx, ctrl_hdl);
}
+/* Wake up context wait_queue */
+static inline void wake_up_ctx(struct mtk_vcodec_ctx *ctx, unsigned int reason)
+{
+ ctx->int_cond = 1;
+ ctx->int_type = reason;
+ wake_up_interruptible(&ctx->queue);
+}
+
#endif /* _MTK_VCODEC_DRV_H_ */
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_drv.c
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_drv.c
index 4167e865b23f..2828df77020c 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_drv.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_drv.c
@@ -73,14 +73,6 @@ static const struct mtk_video_fmt
mtk_video_formats_capture_mt8183[] = {
},
};
-/* Wake up context wait_queue */
-static void wake_up_ctx(struct mtk_vcodec_ctx *ctx, unsigned int reason)
-{
- ctx->int_cond = 1;
- ctx->int_type = reason;
- wake_up_interruptible(&ctx->queue);
-}
-
static void clean_irq_status(unsigned int irq_status, void __iomem *addr)
{
if (irq_status & MTK_VENC_IRQ_STATUS_PAUSE)
--
2.25.1
[PATCH v6, 01/15] media: mtk-vcodec: Get numbers of register bases from DT
Different platform may has different numbers of register bases. Gets the
numbers of register bases from DT (sizeof(u32) * 4 bytes for each).
Reviewed-by: Tzung-Bi Shih
Signed-off-by: Yunfei Dong
---
.../platform/mtk-vcodec/mtk_vcodec_dec_drv.c | 37 ++-
1 file changed, 28 insertions(+), 9 deletions(-)
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 55ae198dbcf9..983e0f2831af 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c
@@ -78,6 +78,30 @@ static irqreturn_t mtk_vcodec_dec_irq_handler(int irq, void
*priv)
return IRQ_HANDLED;
}
+static int mtk_vcodec_get_reg_bases(struct mtk_vcodec_dev *dev)
+{
+ struct platform_device *pdev = dev->plat_dev;
+ int reg_num, i;
+
+ /* Sizeof(u32) * 4 bytes for each register base. */
+ reg_num = of_property_count_elems_of_size(pdev->dev.of_node, "reg",
+ sizeof(u32) * 4);
+ if (reg_num <= 0 || reg_num > NUM_MAX_VDEC_REG_BASE) {
+ dev_err(&pdev->dev, "Invalid register property size: %d\n",
reg_num);
+ return -EINVAL;
+ }
+
+ for (i = 0; i < reg_num; i++) {
+ dev->reg_base[i] = devm_platform_ioremap_resource(pdev, i);
+ if (IS_ERR(dev->reg_base[i]))
+ return PTR_ERR(dev->reg_base[i]);
+
+ mtk_v4l2_debug(2, "reg[%d] base=%p", i, dev->reg_base[i]);
+ }
+
+ return 0;
+}
+
static int fops_vcodec_open(struct file *file)
{
struct mtk_vcodec_dev *dev = video_drvdata(file);
@@ -206,7 +230,7 @@ static int mtk_vcodec_probe(struct platform_device *pdev)
struct resource *res;
phandle rproc_phandle;
enum mtk_vcodec_fw_type fw_type;
- int i, ret;
+ int ret;
dev = devm_kzalloc(&pdev->dev, sizeof(*dev), GFP_KERNEL);
if (!dev)
@@ -238,14 +262,9 @@ static int mtk_vcodec_probe(struct platform_device *pdev)
goto err_dec_pm;
}
- for (i = 0; i < NUM_MAX_VDEC_REG_BASE; i++) {
- dev->reg_base[i] = devm_platform_ioremap_resource(pdev, i);
- if (IS_ERR((__force void *)dev->reg_base[i])) {
- ret = PTR_ERR((__force void *)dev->reg_base[i]);
- goto err_res;
- }
- mtk_v4l2_debug(2, "reg[%d] base=%p", i, dev->reg_base[i]);
- }
+ ret = mtk_vcodec_get_reg_bases(dev);
+ if (ret)
+ goto err_res;
res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
if (res == NULL) {
--
2.25.1
[PATCH v6, 05/15] dt-bindings: media: mtk-vcodec: Separate video encoder and decoder dt-bindings
Decoder will use component framework to manage hardware, it is big
difference with encoder.
Reviewed-by: Rob Herring
Signed-off-by: Yunfei Dong
---
.../media/mediatek,vcodec-decoder.yaml| 175 +
.../media/mediatek,vcodec-encoder.yaml| 185 ++
.../bindings/media/mediatek-vcodec.txt| 130
3 files changed, 360 insertions(+), 130 deletions(-)
create mode 100644
Documentation/devicetree/bindings/media/mediatek,vcodec-decoder.yaml
create mode 100644
Documentation/devicetree/bindings/media/mediatek,vcodec-encoder.yaml
delete mode 100644 Documentation/devicetree/bindings/media/mediatek-vcodec.txt
diff --git
a/Documentation/devicetree/bindings/media/mediatek,vcodec-decoder.yaml
b/Documentation/devicetree/bindings/media/mediatek,vcodec-decoder.yaml
new file mode 100644
index ..b6b97110024d
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/mediatek,vcodec-decoder.yaml
@@ -0,0 +1,175 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iommu/mediatek,vcodec-encoder.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Mediatek Video Decode Accelerator With Component
+
+maintainers:
+ - Yunfei Dong
+
+description: |+
+ Mediatek Video Decode is the video decode hardware present in Mediatek
+ SoCs which supports high resolution decoding functionalities.
+
+properties:
+ compatible:
+enum:
+ - mediatek,mt8173-vcodec-dec
+ - mediatek,mt8183-vcodec-dec
+
+ reg:
+maxItems: 12
+
+ interrupts:
+maxItems: 1
+
+ clocks:
+maxItems: 8
+
+ clock-names:
+items:
+ - const: vcodecpll
+ - const: univpll_d2
+ - const: clk_cci400_sel
+ - const: vdec_sel
+ - const: vdecpll
+ - const: vencpll
+ - const: venc_lt_sel
+ - const: vdec_bus_clk_src
+
+ assigned-clocks: true
+
+ assigned-clock-parents: true
+
+ assigned-clock-rates: true
+
+ power-domains:
+maxItems: 1
+
+ iommus:
+minItems: 1
+maxItems: 32
+description: |
+ List of the hardware port in respective IOMMU block for current Socs.
+ Refer to bindings/iommu/mediatek,iommu.yaml.
+
+ dma-ranges:
+maxItems: 1
+description: |
+ Describes the physical address space of IOMMU maps to memory.
+
+ mediatek,larb:
+$ref: /schemas/types.yaml#/definitions/phandle
+maxItems: 1
+description: |
+ Must contain the local arbiters in the current Socs.
+
+ mediatek,vpu:
+$ref: /schemas/types.yaml#/definitions/phandle
+maxItems: 1
+description:
+ Describes point to vpu.
+
+ mediatek,scp:
+$ref: /schemas/types.yaml#/definitions/phandle
+maxItems: 1
+description:
+ Describes point to scp.
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+ - iommus
+ - assigned-clocks
+ - assigned-clock-parents
+
+allOf:
+ - if:
+ properties:
+compatible:
+ contains:
+enum:
+ - mediatek,mt8183-vcodec-dec
+
+then:
+ required:
+- mediatek,scp
+
+ - if:
+ properties:
+compatible:
+ contains:
+enum:
+ - mediatek,mt8173-vcodec-dec
+
+then:
+ required:
+- mediatek,vpu
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+#include
+#include
+#include
+
+vcodec_dec: vcodec@1600 {
+ compatible = "mediatek,mt8173-vcodec-dec";
+ reg = <0 0x1600 0 0x100>, /*VDEC_SYS*/
+ <0 0x1602 0 0x1000>, /*VDEC_MISC*/
+ <0 0x16021000 0 0x800>, /*VDEC_LD*/
+ <0 0x16021800 0 0x800>, /*VDEC_TOP*/
+ <0 0x16022000 0 0x1000>, /*VDEC_CM*/
+ <0 0x16023000 0 0x1000>, /*VDEC_AD*/
+ <0 0x16024000 0 0x1000>, /*VDEC_AV*/
+ <0 0x16025000 0 0x1000>, /*VDEC_PP*/
+ <0 0x16026800 0 0x800>, /*VP8_VD*/
+ <0 0x16027000 0 0x800>, /*VP6_VD*/
+ <0 0x16027800 0 0x800>, /*VP8_VL*/
+ <0 0x16028400 0 0x400>; /*VP9_VD*/
+ interrupts = ;
+ mediatek,larb = <&larb1>;
+ iommus = <&iommu M4U_PORT_HW_VDEC_MC_EXT>,
+ <&iommu M4U_PORT_HW_VDEC_PP_EXT>,
+ <&iommu M4U_PORT_HW_VDEC_AVC_MV_EXT>,
+ <&iommu M4U_PORT_HW_VDEC_PRED_RD_EXT>,
+ <&iommu M4U_PORT_HW_VDEC_PRED_WR_EXT>,
+ <&iommu M4U_PORT_HW_VDEC_UFO_EXT>,
+ <&iommu M4U_PORT_HW_VDEC_VLD_EXT>,
+ <&iommu M4U_PORT_HW_VDEC_VLD2_EXT>;
+ mediatek,vpu = <&vpu>;
+ power-domains = <&scpsys MT8173_POWER_DOMAIN_VDEC>;
+ clocks = <&apmixedsys CLK_APMIXED_VCODECPLL>,
+ <&topckgen CLK_TOP_UNIVPLL_D2>,
+ <&topckgen CLK_TOP_CCI400_SEL>,
+ <&topckgen CLK_TOP_VDEC_SEL>,
+ <&topckgen CLK_TOP_VCODECPLL>,
+ <&apmixedsys CLK_APMIXED_VENCPLL>,
+ <&topckgen CLK_TOP_VENC_LT_SEL>
[PATCH v6, 03/15] media: mtk-vcodec: Refactor vcodec pm interface
Using the needed param for pm init/release function and remove unused
param mtkdev in 'struct mtk_vcodec_pm'.
Reviewed-by: Tzung-Bi Shih
Signed-off-by: Yunfei Dong
---
.../platform/mtk-vcodec/mtk_vcodec_dec_drv.c | 6 ++---
.../platform/mtk-vcodec/mtk_vcodec_dec_pm.c | 22 ---
.../platform/mtk-vcodec/mtk_vcodec_dec_pm.h | 5 +++--
.../platform/mtk-vcodec/mtk_vcodec_drv.h | 1 -
.../platform/mtk-vcodec/mtk_vcodec_enc_pm.c | 1 -
5 files changed, 15 insertions(+), 20 deletions(-)
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 8db9cdc66043..dd749d41c75a 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c
@@ -249,7 +249,7 @@ static int mtk_vcodec_probe(struct platform_device *pdev)
if (IS_ERR(dev->fw_handler))
return PTR_ERR(dev->fw_handler);
- ret = mtk_vcodec_init_dec_pm(dev);
+ ret = mtk_vcodec_init_dec_pm(dev->plat_dev, &dev->pm);
if (ret < 0) {
dev_err(&pdev->dev, "Failed to get mt vcodec clock source");
goto err_dec_pm;
@@ -379,7 +379,7 @@ static int mtk_vcodec_probe(struct platform_device *pdev)
err_dec_alloc:
v4l2_device_unregister(&dev->v4l2_dev);
err_res:
- mtk_vcodec_release_dec_pm(dev);
+ mtk_vcodec_release_dec_pm(&dev->pm);
err_dec_pm:
mtk_vcodec_fw_release(dev->fw_handler);
return ret;
@@ -422,7 +422,7 @@ static int mtk_vcodec_dec_remove(struct platform_device
*pdev)
video_unregister_device(dev->vfd_dec);
v4l2_device_unregister(&dev->v4l2_dev);
- mtk_vcodec_release_dec_pm(dev);
+ mtk_vcodec_release_dec_pm(&dev->pm);
mtk_vcodec_fw_release(dev->fw_handler);
return 0;
}
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c
index 6038db96f71c..20bd157a855c 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c
@@ -13,18 +13,15 @@
#include "mtk_vcodec_dec_pm.h"
#include "mtk_vcodec_util.h"
-int mtk_vcodec_init_dec_pm(struct mtk_vcodec_dev *mtkdev)
+int mtk_vcodec_init_dec_pm(struct platform_device *pdev,
+ struct mtk_vcodec_pm *pm)
{
struct device_node *node;
- struct platform_device *pdev;
- struct mtk_vcodec_pm *pm;
+ struct platform_device *larb_pdev;
struct mtk_vcodec_clk *dec_clk;
struct mtk_vcodec_clk_info *clk_info;
int i = 0, ret = 0;
- pdev = mtkdev->plat_dev;
- pm = &mtkdev->pm;
- pm->mtkdev = mtkdev;
dec_clk = &pm->vdec_clk;
node = of_parse_phandle(pdev->dev.of_node, "mediatek,larb", 0);
if (!node) {
@@ -32,13 +29,12 @@ int mtk_vcodec_init_dec_pm(struct mtk_vcodec_dev *mtkdev)
return -1;
}
- pdev = of_find_device_by_node(node);
+ larb_pdev = of_find_device_by_node(node);
of_node_put(node);
- if (WARN_ON(!pdev)) {
+ if (WARN_ON(!larb_pdev)) {
return -1;
}
- pm->larbvdec = &pdev->dev;
- pdev = mtkdev->plat_dev;
+ pm->larbvdec = &larb_pdev->dev;
pm->dev = &pdev->dev;
dec_clk->clk_num =
@@ -82,10 +78,10 @@ int mtk_vcodec_init_dec_pm(struct mtk_vcodec_dev *mtkdev)
return ret;
}
-void mtk_vcodec_release_dec_pm(struct mtk_vcodec_dev *dev)
+void mtk_vcodec_release_dec_pm(struct mtk_vcodec_pm *pm)
{
- pm_runtime_disable(dev->pm.dev);
- put_device(dev->pm.larbvdec);
+ pm_runtime_disable(pm->dev);
+ put_device(pm->larbvdec);
}
int mtk_vcodec_dec_pw_on(struct mtk_vcodec_pm *pm)
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.h
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.h
index 280aeaefdb65..a3df6aef6cb9 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.h
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.h
@@ -9,8 +9,9 @@
#include "mtk_vcodec_drv.h"
-int mtk_vcodec_init_dec_pm(struct mtk_vcodec_dev *dev);
-void mtk_vcodec_release_dec_pm(struct mtk_vcodec_dev *dev);
+int mtk_vcodec_init_dec_pm(struct platform_device *pdev,
+ struct mtk_vcodec_pm *pm);
+void mtk_vcodec_release_dec_pm(struct mtk_vcodec_pm *pm);
int mtk_vcodec_dec_pw_on(struct mtk_vcodec_pm *pm);
void mtk_vcodec_dec_pw_off(struct mtk_vcodec_pm *pm);
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
index 3b1e5e3a450e..973b0b3649c6 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
@@ -195,7 +195,6 @@ struct mtk_vcodec_pm {
struct mtk_vcodec_clk venc_clk;
struct device *larbvenc;
struct device *dev;
- struct mtk_vcodec_dev *mtkdev;
};
/*
[PATCH v6, 04/15] media: mtk-vcodec: Use component framework to manage each hardware information
Uses component framework to manage each hardware information which
includes irq/power/clk. The hardware includes LAT0, LAT1 and CORE.
Signed-off-by: Yunfei Dong
---
drivers/media/platform/mtk-vcodec/Makefile| 1 +
.../platform/mtk-vcodec/mtk_vcodec_dec.h | 1 +
.../platform/mtk-vcodec/mtk_vcodec_dec_drv.c | 194 +++---
.../platform/mtk-vcodec/mtk_vcodec_dec_hw.c | 184 +
.../platform/mtk-vcodec/mtk_vcodec_dec_hw.h | 49 +
.../mtk-vcodec/mtk_vcodec_dec_stateful.c | 1 +
.../mtk-vcodec/mtk_vcodec_dec_stateless.c | 1 +
.../platform/mtk-vcodec/mtk_vcodec_drv.h | 19 ++
8 files changed, 416 insertions(+), 34 deletions(-)
create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_hw.c
create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_hw.h
diff --git a/drivers/media/platform/mtk-vcodec/Makefile
b/drivers/media/platform/mtk-vcodec/Makefile
index ca8e9e7a9c4e..edeb3b66e9e9 100644
--- a/drivers/media/platform/mtk-vcodec/Makefile
+++ b/drivers/media/platform/mtk-vcodec/Makefile
@@ -15,6 +15,7 @@ mtk-vcodec-dec-y := vdec/vdec_h264_if.o \
mtk_vcodec_dec_stateful.o \
mtk_vcodec_dec_stateless.o \
mtk_vcodec_dec_pm.o \
+ mtk_vcodec_dec_hw.o \
mtk-vcodec-enc-y := venc/venc_vp8_if.o \
venc/venc_h264_if.o \
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.h
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.h
index 9fbd24186c1a..c509224cbff4 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.h
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.h
@@ -66,6 +66,7 @@ extern const struct v4l2_ioctl_ops mtk_vdec_ioctl_ops;
extern const struct v4l2_m2m_ops mtk_vdec_m2m_ops;
extern const struct media_device_ops mtk_vcodec_media_ops;
+extern struct platform_driver mtk_vdec_comp_driver;
/*
* mtk_vdec_lock/mtk_vdec_unlock are for ctx instance to
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 dd749d41c75a..4c6f4d7612fa 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c
@@ -5,6 +5,7 @@
* Tiffany Lin
*/
+#include
#include
#include
#include
@@ -18,19 +19,90 @@
#include "mtk_vcodec_drv.h"
#include "mtk_vcodec_dec.h"
+#include "mtk_vcodec_dec_hw.h"
#include "mtk_vcodec_dec_pm.h"
#include "mtk_vcodec_intr.h"
-#include "mtk_vcodec_util.h"
#include "mtk_vcodec_fw.h"
-#define VDEC_HW_ACTIVE 0x10
-#define VDEC_IRQ_CFG 0x11
-#define VDEC_IRQ_CLR 0x10
-#define VDEC_IRQ_CFG_REG 0xa4
-
module_param(mtk_v4l2_dbg_level, int, 0644);
module_param(mtk_vcodec_dbg, bool, 0644);
+static struct of_device_id mtk_vdec_drv_ids[] = {
+ {
+ .compatible = "mediatek,mtk-vcodec-lat",
+ .data = (void *)MTK_VDEC_LAT0,
+ },
+ {
+ .compatible = "mediatek,mtk-vcodec-core",
+ .data = (void *)MTK_VDEC_CORE,
+ },
+ {},
+};
+
+static inline int mtk_vdec_compare_of(struct device *dev, void *data)
+{
+ return dev->of_node == data;
+}
+
+static inline void mtk_vdec_release_of(struct device *dev, void *data)
+{
+ of_node_put(data);
+}
+
+static inline int mtk_vdec_bind(struct device *dev)
+{
+ struct mtk_vcodec_dev *data = dev_get_drvdata(dev);
+
+ return component_bind_all(dev, data);
+}
+
+static inline void mtk_vdec_unbind(struct device *dev)
+{
+ struct mtk_vcodec_dev *data = dev_get_drvdata(dev);
+
+ component_unbind_all(dev, data);
+}
+
+static const struct component_master_ops mtk_vdec_ops = {
+ .bind = mtk_vdec_bind,
+ .unbind = mtk_vdec_unbind,
+};
+
+static struct component_match *mtk_vcodec_match_add(
+ struct mtk_vcodec_dev *vdec_dev)
+ {
+ struct platform_device *pdev = vdec_dev->plat_dev;
+ struct component_match *match = NULL;
+ struct device_node *comp_node;
+ enum mtk_vdec_hw_id comp_idx;
+ const struct of_device_id *of_id;
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(mtk_vdec_drv_ids); i++) {
+ of_id = &mtk_vdec_drv_ids[i];
+ comp_node = of_find_compatible_node(NULL, NULL,
+ of_id->compatible);
+ if (!comp_node)
+ continue;
+
+ if (!of_device_is_available(comp_node)) {
+ of_node_put(comp_node);
+ dev_err(&pdev->dev, "Fail to get MMSYS node\n");
+ continue;
+ }
+
+ comp_idx = (enum mtk_vdec_hw_id)of_id->data;
+ mtk_v4l2_debug(4, "Get
component:hw_id(%d),vdec_dev(0x%p),comp_node(0x%p)\n",
+ comp_idx, vdec_dev, comp_node);
+ vdec_dev->component_node[comp_idx] = comp_node;
+
+ component_match_add_release(&pdev->dev, &match
[PATCH v6, 06/15] media: mtk-vcodec: Use pure single core for MT8183
Separates different architecture for hardware: pure_sin_core
and lat_sin_core. MT8183 is pure single core. Uses .hw_arch to
distinguish.
Signed-off-by: Yunfei Dong
---
.../platform/mtk-vcodec/mtk_vcodec_dec_stateful.c | 1 +
.../platform/mtk-vcodec/mtk_vcodec_dec_stateless.c | 1 +
drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h | 10 ++
3 files changed, 12 insertions(+)
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_stateful.c
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_stateful.c
index 4f9a80ce15d8..138f6fcb36bb 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_stateful.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_stateful.c
@@ -624,4 +624,5 @@ const struct mtk_vcodec_dec_pdata mtk_vdec_8173_pdata = {
.worker = mtk_vdec_worker,
.flush_decoder = mtk_vdec_flush_decoder,
.is_comp_supported = false,
+ .hw_arch = MTK_VDEC_PURE_SINGLE_CORE,
};
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_stateless.c
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_stateless.c
index 762633572b49..12c243d6dff3 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_stateless.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_stateless.c
@@ -358,4 +358,5 @@ const struct mtk_vcodec_dec_pdata mtk_vdec_8183_pdata = {
.worker = mtk_vdec_worker,
.flush_decoder = mtk_vdec_flush_decoder,
.is_comp_supported = false,
+ .hw_arch = MTK_VDEC_PURE_SINGLE_CORE,
};
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
index e530757a9b5a..1d0798fd9adf 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
@@ -323,6 +323,14 @@ enum mtk_chip {
MTK_MT8192,
};
+/**
+ * struct mtk_vdec_hw_arch - Used to separate different hardware architecture
+ */
+enum mtk_vdec_hw_arch {
+ MTK_VDEC_PURE_SINGLE_CORE,
+ MTK_VDEC_LAT_SINGLE_CORE,
+};
+
/**
* struct mtk_vcodec_dec_pdata - compatible data for each IC
* @init_vdec_params: init vdec params
@@ -341,6 +349,7 @@ enum mtk_chip {
* @num_framesizes: count of video decoder frame sizes
*
* @chip: chip this decoder is compatible with
+ * @hw_arch: hardware arch is used to separate pure_sin_core and lat_sin_core
*
* @is_comp_supported: true: using compoent framework, false: not support
* @uses_stateless_api: whether the decoder uses the stateless API with
requests
@@ -363,6 +372,7 @@ struct mtk_vcodec_dec_pdata {
const int num_framesizes;
enum mtk_chip chip;
+ enum mtk_vdec_hw_arch hw_arch;
bool is_comp_supported;
bool uses_stateless_api;
--
2.25.1
[PATCH v6, 07/15] media: mtk-vcodec: Add irq interface for multi hardware
Adds irq interface for multi hardware.
Signed-off-by: Yunfei Dong
---
.../platform/mtk-vcodec/mtk_vcodec_dec_drv.c | 33 +--
.../platform/mtk-vcodec/mtk_vcodec_dec_hw.c | 2 +-
.../platform/mtk-vcodec/mtk_vcodec_drv.h | 25 ++
.../platform/mtk-vcodec/mtk_vcodec_enc_drv.c | 4 +--
.../platform/mtk-vcodec/mtk_vcodec_intr.c | 27 +++
.../platform/mtk-vcodec/mtk_vcodec_intr.h | 4 +--
.../platform/mtk-vcodec/vdec/vdec_h264_if.c | 2 +-
.../mtk-vcodec/vdec/vdec_h264_req_if.c| 2 +-
.../platform/mtk-vcodec/vdec/vdec_vp8_if.c| 2 +-
.../platform/mtk-vcodec/vdec/vdec_vp9_if.c| 2 +-
.../platform/mtk-vcodec/venc/venc_h264_if.c | 2 +-
.../platform/mtk-vcodec/venc/venc_vp8_if.c| 2 +-
12 files changed, 71 insertions(+), 36 deletions(-)
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 4c6f4d7612fa..f096ad1c01ac 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c
@@ -68,6 +68,20 @@ static const struct component_master_ops mtk_vdec_ops = {
.unbind = mtk_vdec_unbind,
};
+static int mtk_vcodec_get_hw_count(struct mtk_vcodec_dev *dev)
+{
+ switch (dev->vdec_pdata->hw_arch) {
+ case MTK_VDEC_PURE_SINGLE_CORE:
+ return MTK_VDEC_ONE_CORE;
+ case MTK_VDEC_LAT_SINGLE_CORE:
+ return MTK_VDEC_ONE_LAT_ONE_CORE;
+ default:
+ mtk_v4l2_err("not support hw arch:%d",
+ dev->vdec_pdata->hw_arch);
+ return MTK_VDEC_NO_HW;
+ }
+}
+
static struct component_match *mtk_vcodec_match_add(
struct mtk_vcodec_dev *vdec_dev)
{
@@ -134,7 +148,7 @@ static irqreturn_t mtk_vcodec_dec_irq_handler(int irq, void
*priv)
writel((readl(vdec_misc_addr) & ~VDEC_IRQ_CLR),
dev->reg_base[VDEC_MISC] + VDEC_IRQ_CFG_REG);
- wake_up_ctx(ctx, MTK_INST_IRQ_RECEIVED);
+ wake_up_ctx(ctx, MTK_INST_IRQ_RECEIVED, 0);
mtk_v4l2_debug(3,
"mtk_vcodec_dec_irq_handler :wake up ctx %d,
dec_done_status=%x",
@@ -223,7 +237,7 @@ static int fops_vcodec_open(struct file *file)
{
struct mtk_vcodec_dev *dev = video_drvdata(file);
struct mtk_vcodec_ctx *ctx = NULL;
- int ret = 0;
+ int ret = 0, i, hw_count;
struct vb2_queue *src_vq;
ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
@@ -237,7 +251,19 @@ static int fops_vcodec_open(struct file *file)
v4l2_fh_add(&ctx->fh);
INIT_LIST_HEAD(&ctx->list);
ctx->dev = dev;
- init_waitqueue_head(&ctx->queue);
+
+ if (ctx->dev->vdec_pdata->is_comp_supported) {
+ hw_count = mtk_vcodec_get_hw_count(dev);
+ if (!hw_count) {
+ ret = -EINVAL;
+ goto err_init_queue;
+ }
+ for (i = 0; i < hw_count; i++)
+ init_waitqueue_head(&ctx->queue[i]);
+ } else {
+ init_waitqueue_head(&ctx->queue[0]);
+ }
+
mutex_init(&ctx->lock);
ctx->type = MTK_INST_DECODER;
@@ -294,6 +320,7 @@ static int fops_vcodec_open(struct file *file)
err_m2m_ctx_init:
v4l2_ctrl_handler_free(&ctx->ctrl_hdl);
err_ctrls_setup:
+err_init_queue:
v4l2_fh_del(&ctx->fh);
v4l2_fh_exit(&ctx->fh);
kfree(ctx);
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_hw.c
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_hw.c
index 5e1b7670ba5b..7a31afd294ba 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_hw.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_hw.c
@@ -87,7 +87,7 @@ static irqreturn_t mtk_vdec_comp_irq_handler(int irq, void
*priv)
writel(dec_done_status | VDEC_IRQ_CFG, vdec_misc_addr);
writel(dec_done_status & ~VDEC_IRQ_CLR, vdec_misc_addr);
- wake_up_ctx(ctx, MTK_INST_IRQ_RECEIVED);
+ wake_up_ctx(ctx, MTK_INST_IRQ_RECEIVED, dev->comp_idx);
mtk_v4l2_debug(3, "wake up ctx %d, dec_done_status=%x",
ctx->id, dec_done_status);
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
index 1d0798fd9adf..08fd43106fc7 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
@@ -104,6 +104,16 @@ enum mtk_vdec_hw_id {
MTK_VDEC_HW_MAX,
};
+/**
+ * struct mtk_vdec_hw_count - Supported hardware count
+ */
+enum mtk_vdec_hw_count {
+ MTK_VDEC_NO_HW = 0,
+ MTK_VDEC_ONE_CORE,
+ MTK_VDEC_ONE_LAT_ONE_CORE,
+ MTK_VDEC_MAX_HW_COUNT,
+};
+
/*
* struct mtk_video_fmt - Structure used to store information about
pixelformats
*/
@@ -293,9 +303,9 @@ struct mtk_vcodec_ctx {
struct vdec_pic_info picinfo;
int dpb_size;
- int int_cond;
[PATCH v6, 09/15] media: mtk-vcodec: Generalize power and clock on/off interfaces
Generalizes power and clock on/off interfaces to support different hardware.
Signed-off-by: Yunfei Dong
---
.../platform/mtk-vcodec/mtk_vcodec_dec_drv.c | 6 +-
.../platform/mtk-vcodec/mtk_vcodec_dec_hw.c | 2 +-
.../platform/mtk-vcodec/mtk_vcodec_dec_hw.h | 4 +
.../platform/mtk-vcodec/mtk_vcodec_dec_pm.c | 76 ++--
.../platform/mtk-vcodec/mtk_vcodec_dec_pm.h | 8 +-
.../platform/mtk-vcodec/mtk_vcodec_drv.h | 2 +
.../platform/mtk-vcodec/mtk_vcodec_util.c | 87 ---
.../platform/mtk-vcodec/mtk_vcodec_util.h | 8 +-
.../media/platform/mtk-vcodec/vdec_drv_if.c | 21 ++---
9 files changed, 174 insertions(+), 40 deletions(-)
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 f096ad1c01ac..109f7de126a1 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c
@@ -126,7 +126,7 @@ static irqreturn_t mtk_vcodec_dec_irq_handler(int irq, void
*priv)
void __iomem *vdec_misc_addr = dev->reg_base[VDEC_MISC] +
VDEC_IRQ_CFG_REG;
- ctx = mtk_vcodec_get_curr_ctx(dev);
+ ctx = mtk_vcodec_get_curr_ctx(dev, MTK_VDEC_CORE);
/* check if HW active or not */
cg_status = readl(dev->reg_base[0]);
@@ -286,7 +286,7 @@ static int fops_vcodec_open(struct file *file)
mtk_vcodec_dec_set_default_params(ctx);
if (v4l2_fh_is_singular(&ctx->fh)) {
- ret = mtk_vcodec_dec_pw_on(&dev->pm);
+ ret = mtk_vcodec_dec_pw_on(dev, MTK_VDEC_LAT0);
if (ret < 0)
goto err_load_fw;
/*
@@ -347,7 +347,7 @@ static int fops_vcodec_release(struct file *file)
mtk_vcodec_dec_release(ctx);
if (v4l2_fh_is_singular(&ctx->fh))
- mtk_vcodec_dec_pw_off(&dev->pm);
+ mtk_vcodec_dec_pw_off(dev, MTK_VDEC_LAT0);
v4l2_fh_del(&ctx->fh);
v4l2_fh_exit(&ctx->fh);
v4l2_ctrl_handler_free(&ctx->ctrl_hdl);
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_hw.c
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_hw.c
index 7a31afd294ba..714df68ffb19 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_hw.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_hw.c
@@ -68,7 +68,7 @@ static irqreturn_t mtk_vdec_comp_irq_handler(int irq, void
*priv)
void __iomem *vdec_misc_addr = dev->reg_base[VDEC_COMP_MISC] +
VDEC_IRQ_CFG_REG;
- ctx = mtk_vcodec_get_curr_ctx(dev->master_dev);
+ ctx = mtk_vcodec_get_curr_ctx(dev->master_dev, dev->comp_idx);
/* check if HW active or not */
cg_status = readl(dev->reg_base[VDEC_COMP_SYS]);
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_hw.h
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_hw.h
index 8d6e818a3474..0a4c2e6f5df2 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_hw.h
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_hw.h
@@ -32,6 +32,8 @@ enum mtk_comp_hw_reg_idx {
* @master_dev: master device
* @reg_base: Mapped address of MTK Vcodec registers.
*
+ * @curr_ctx: The context that is waiting for codec hardware
+ *
* @dec_irq: decoder irq resource
* @pm: power management control
* @comp_idx: component index
@@ -41,6 +43,8 @@ struct mtk_vdec_comp_dev {
struct mtk_vcodec_dev *master_dev;
void __iomem *reg_base[VDEC_COMP_MAX];
+ struct mtk_vcodec_ctx *curr_ctx;
+
int dec_irq;
struct mtk_vcodec_pm pm;
int comp_idx;
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c
index 20bd157a855c..183d4c4e36f0 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c
@@ -5,11 +5,13 @@
*/
#include
+#include
#include
#include
#include
#include
+#include "mtk_vcodec_dec_hw.h"
#include "mtk_vcodec_dec_pm.h"
#include "mtk_vcodec_util.h"
@@ -84,10 +86,23 @@ void mtk_vcodec_release_dec_pm(struct mtk_vcodec_pm *pm)
put_device(pm->larbvdec);
}
-int mtk_vcodec_dec_pw_on(struct mtk_vcodec_pm *pm)
+int mtk_vcodec_dec_pw_on(struct mtk_vcodec_dev *vdec_dev, int comp_idx)
{
+ struct mtk_vdec_comp_dev *comp_dev;
+ struct mtk_vcodec_pm *pm;
int ret;
+ if (vdec_dev->vdec_pdata->is_comp_supported) {
+ comp_dev = mtk_vcodec_get_hw_dev(vdec_dev, comp_idx);
+ if (!comp_dev) {
+ mtk_v4l2_err("Failed to get hw dev\n");
+ return -EINVAL;
+ }
+ pm = &comp_dev->pm;
+ } else {
+ pm = &vdec_dev->pm;
+ }
+
ret = pm_runtime_resume_and_get(pm->dev);
if (ret)
mtk_v4l2_err("pm_runtime_resum
[PATCH v6, 08/15] media: mtk-vcodec: Add msg queue feature for lat and core architecture
For lat and core architecture, lat thread will send message to core
thread when lat decode done. Core hardware will use the message
from lat to decode, then free message to lat thread when decode done.
Signed-off-by: Yunfei Dong
---
drivers/media/platform/mtk-vcodec/Makefile| 1 +
.../platform/mtk-vcodec/mtk_vcodec_drv.h | 5 +
.../platform/mtk-vcodec/vdec_msg_queue.c | 258 ++
.../platform/mtk-vcodec/vdec_msg_queue.h | 151 ++
4 files changed, 415 insertions(+)
create mode 100644 drivers/media/platform/mtk-vcodec/vdec_msg_queue.c
create mode 100644 drivers/media/platform/mtk-vcodec/vdec_msg_queue.h
diff --git a/drivers/media/platform/mtk-vcodec/Makefile
b/drivers/media/platform/mtk-vcodec/Makefile
index edeb3b66e9e9..5000e59da576 100644
--- a/drivers/media/platform/mtk-vcodec/Makefile
+++ b/drivers/media/platform/mtk-vcodec/Makefile
@@ -11,6 +11,7 @@ mtk-vcodec-dec-y := vdec/vdec_h264_if.o \
mtk_vcodec_dec_drv.o \
vdec_drv_if.o \
vdec_vpu_if.o \
+ vdec_msg_queue.o \
mtk_vcodec_dec.o \
mtk_vcodec_dec_stateful.o \
mtk_vcodec_dec_stateless.o \
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
index 08fd43106fc7..4ad0566e715d 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
@@ -15,7 +15,9 @@
#include
#include
#include
+
#include "mtk_vcodec_util.h"
+#include "vdec_msg_queue.h"
#define MTK_VCODEC_DRV_NAME"mtk_vcodec_drv"
#define MTK_VCODEC_DEC_NAME"mtk-vcodec-dec"
@@ -282,6 +284,8 @@ struct vdec_pic_info {
* @decoded_frame_cnt: number of decoded frames
* @lock: protect variables accessed by V4L2 threads and worker thread such as
* mtk_video_dec_buf.
+ *
+ * @msg_queue: msg queue used to store lat buffer information.
*/
struct mtk_vcodec_ctx {
enum mtk_instance_type type;
@@ -325,6 +329,7 @@ struct mtk_vcodec_ctx {
int decoded_frame_cnt;
struct mutex lock;
+ struct vdec_msg_queue msg_queue;
};
enum mtk_chip {
diff --git a/drivers/media/platform/mtk-vcodec/vdec_msg_queue.c
b/drivers/media/platform/mtk-vcodec/vdec_msg_queue.c
new file mode 100644
index ..d66ed98c79a9
--- /dev/null
+++ b/drivers/media/platform/mtk-vcodec/vdec_msg_queue.c
@@ -0,0 +1,258 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2021 MediaTek Inc.
+ * Author: Yunfei Dong
+ */
+
+#include
+#include
+#include
+
+#include "mtk_vcodec_dec_pm.h"
+#include "mtk_vcodec_drv.h"
+#include "vdec_msg_queue.h"
+
+#define VDEC_LAT_SLICE_HEADER_SZ(640 * 1024)
+#define VDEC_ERR_MAP_SZ_AVC ((8192 / 16) * (4352 / 16) / 8)
+
+/* lat write decoded hardware information to trans buffer,
+ * and core will read the trans buffer to decode again. The
+ * trans buffer size of FHD and 4K bitstreams are different.
+ */
+static int vde_msg_queue_get_trans_size(int width, int height)
+{
+ if (width > 1920 || height > 1088)
+ return (30 * 1024 * 1024);
+ else
+ return 6 * 1024 * 1024;
+}
+
+void vdec_msg_queue_init_ctx(struct vdec_msg_queue_ctx *ctx,
+ int hardware_index)
+{
+ init_waitqueue_head(&ctx->ready_to_use);
+ INIT_LIST_HEAD(&ctx->ready_queue);
+ spin_lock_init(&ctx->ready_lock);
+ ctx->ready_num = 0;
+ ctx->hardware_index = hardware_index;
+}
+
+int vdec_msg_queue_init(
+ struct vdec_msg_queue *msg_queue,
+ struct mtk_vcodec_ctx *ctx,
+ core_decode_cb_t core_decode,
+ int private_size)
+{
+ struct vdec_lat_buf *lat_buf;
+ int i, err;
+
+ /* already init msg queue */
+ if (msg_queue->wdma_addr.size)
+ return 0;
+
+ vdec_msg_queue_init_ctx(&msg_queue->lat_ctx, MTK_VDEC_LAT0);
+ msg_queue->wdma_addr.size = vde_msg_queue_get_trans_size(
+ ctx->picinfo.buf_w, ctx->picinfo.buf_h);
+
+ err = mtk_vcodec_mem_alloc(ctx, &msg_queue->wdma_addr);
+ if (err) {
+ mtk_v4l2_err("failed to allocate wdma_addr buf");
+ return -ENOMEM;
+ }
+ msg_queue->wdma_rptr_addr = msg_queue->wdma_addr.dma_addr;
+ msg_queue->wdma_wptr_addr = msg_queue->wdma_addr.dma_addr;
+
+ for (i = 0; i < NUM_BUFFER_COUNT; i++) {
+ lat_buf = &msg_queue->lat_buf[i];
+
+ lat_buf->wdma_err_addr.size = VDEC_ERR_MAP_SZ_AVC;
+ err = mtk_vcodec_mem_alloc(ctx, &lat_buf->wdma_err_addr);
+ if (err) {
+ mtk_v4l2_err("failed to allocate wdma_err_addr
buf[%d]", i);
+ goto mem_alloc_err;
+ }
+
+ lat_buf->slice_bc_addr.size = VDEC_LAT_SLICE_HEADER_SZ;
+ err = mtk_vcodec_mem_alloc(ctx, &lat_buf->slice_bc_addr);
+ if (err) {
+
[PATCH v6, 11/15] media: mtk-vcodec: Add core thread
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.
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 e448cb238c7f..002352fcf8de 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c
@@ -405,6 +405,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 f1e63acaec76..b6f030a6e55f 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_PLANES 3
#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
@@ -465,6 +466,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
*/
struct mtk_vcodec_dev {
struct v4l2_device v4l2_dev;
@@ -505,6 +509,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;
};
static inline struct mtk_vcodec_ctx *fh_to_ctx(struct v4l2_fh *fh)
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 codec
+ */
+int vdec_msg_queue_core_thead(void *data);
+
#endif
--
2.25.1
[PATCH v6, 10/15] media: mtk-vcodec: Add new interface to lock different hardware
For add new hardware, not only need to lock lat hardware, also
need to lock core hardware in case of different instance start
to decoder at the same time.
Signed-off-by: Yunfei Dong
---
drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c | 4 ++--
drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c | 6 +++---
drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h | 2 +-
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
index 2b334a8a81c6..130ecef2e766 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
@@ -105,12 +105,12 @@ static int vidioc_decoder_cmd(struct file *file, void
*priv,
void mtk_vdec_unlock(struct mtk_vcodec_ctx *ctx)
{
- mutex_unlock(&ctx->dev->dec_mutex);
+ mutex_unlock(&ctx->dev->dec_mutex[ctx->hw_id]);
}
void mtk_vdec_lock(struct mtk_vcodec_ctx *ctx)
{
- mutex_lock(&ctx->dev->dec_mutex);
+ mutex_lock(&ctx->dev->dec_mutex[ctx->hw_id]);
}
void mtk_vcodec_dec_release(struct mtk_vcodec_ctx *ctx)
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 109f7de126a1..e448cb238c7f 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c
@@ -373,7 +373,7 @@ static int mtk_vcodec_probe(struct platform_device *pdev)
struct video_device *vfd_dec;
phandle rproc_phandle;
enum mtk_vcodec_fw_type fw_type;
- int ret;
+ int i, ret;
dev = devm_kzalloc(&pdev->dev, sizeof(*dev), GFP_KERNEL);
if (!dev)
@@ -405,8 +405,8 @@ static int mtk_vcodec_probe(struct platform_device *pdev)
goto err_dec_pm;
}
- mutex_init(&dev->dec_mutex);
- mutex_init(&dev->dev_mutex);
+ for (i = 0; i < MTK_VDEC_HW_MAX; i++)
+ mutex_init(&dev->dec_mutex[i]);
spin_lock_init(&dev->irqlock);
snprintf(dev->v4l2_dev.name, sizeof(dev->v4l2_dev.name), "%s",
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
index a8242389ad24..f1e63acaec76 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
@@ -496,7 +496,7 @@ struct mtk_vcodec_dev {
int dec_irq;
int enc_irq;
- struct mutex dec_mutex;
+ struct mutex dec_mutex[MTK_VDEC_HW_MAX];
struct mutex enc_mutex;
struct mtk_vcodec_pm pm;
--
2.25.1
[PATCH v6, 14/15] media: mtk-vcodec: Add core dec and dec end ipi msg
Add core dec and dec end ipi msg: AP_IPIMSG_DEC_CORE/AP_IPIMSG_DEC_CORE_END.
Signed-off-by: Yunfei Dong
---
.../media/platform/mtk-vcodec/vdec_ipi_msg.h | 4
.../media/platform/mtk-vcodec/vdec_vpu_if.c| 12
.../media/platform/mtk-vcodec/vdec_vpu_if.h| 18 ++
3 files changed, 34 insertions(+)
diff --git a/drivers/media/platform/mtk-vcodec/vdec_ipi_msg.h
b/drivers/media/platform/mtk-vcodec/vdec_ipi_msg.h
index 5f45a537beb4..9d8079c4f976 100644
--- a/drivers/media/platform/mtk-vcodec/vdec_ipi_msg.h
+++ b/drivers/media/platform/mtk-vcodec/vdec_ipi_msg.h
@@ -18,12 +18,16 @@ enum vdec_ipi_msgid {
AP_IPIMSG_DEC_END = 0xA002,
AP_IPIMSG_DEC_DEINIT = 0xA003,
AP_IPIMSG_DEC_RESET = 0xA004,
+ AP_IPIMSG_DEC_CORE = 0xA005,
+ AP_IPIMSG_DEC_CORE_END = 0xA006,
VPU_IPIMSG_DEC_INIT_ACK = 0xB000,
VPU_IPIMSG_DEC_START_ACK = 0xB001,
VPU_IPIMSG_DEC_END_ACK = 0xB002,
VPU_IPIMSG_DEC_DEINIT_ACK = 0xB003,
VPU_IPIMSG_DEC_RESET_ACK = 0xB004,
+ VPU_IPIMSG_DEC_CORE_ACK = 0xB005,
+ VPU_IPIMSG_DEC_CORE_END_ACK = 0xB006,
};
/**
diff --git a/drivers/media/platform/mtk-vcodec/vdec_vpu_if.c
b/drivers/media/platform/mtk-vcodec/vdec_vpu_if.c
index 5dffc459a33d..bfd8e87dceff 100644
--- a/drivers/media/platform/mtk-vcodec/vdec_vpu_if.c
+++ b/drivers/media/platform/mtk-vcodec/vdec_vpu_if.c
@@ -85,6 +85,8 @@ static void vpu_dec_ipi_handler(void *data, unsigned int len,
void *priv)
case VPU_IPIMSG_DEC_END_ACK:
case VPU_IPIMSG_DEC_DEINIT_ACK:
case VPU_IPIMSG_DEC_RESET_ACK:
+ case VPU_IPIMSG_DEC_CORE_ACK:
+ case VPU_IPIMSG_DEC_CORE_END_ACK:
break;
default:
@@ -191,11 +193,21 @@ int vpu_dec_start(struct vdec_vpu_inst *vpu, uint32_t
*data, unsigned int len)
return err;
}
+int vpu_dec_core(struct vdec_vpu_inst *vpu)
+{
+ return vcodec_send_ap_ipi(vpu, AP_IPIMSG_DEC_CORE);
+}
+
int vpu_dec_end(struct vdec_vpu_inst *vpu)
{
return vcodec_send_ap_ipi(vpu, AP_IPIMSG_DEC_END);
}
+int vpu_dec_core_end(struct vdec_vpu_inst *vpu)
+{
+ return vcodec_send_ap_ipi(vpu, AP_IPIMSG_DEC_CORE_END);
+}
+
int vpu_dec_deinit(struct vdec_vpu_inst *vpu)
{
return vcodec_send_ap_ipi(vpu, AP_IPIMSG_DEC_DEINIT);
diff --git a/drivers/media/platform/mtk-vcodec/vdec_vpu_if.h
b/drivers/media/platform/mtk-vcodec/vdec_vpu_if.h
index c2ed5b6cab8b..ae24b75d1649 100644
--- a/drivers/media/platform/mtk-vcodec/vdec_vpu_if.h
+++ b/drivers/media/platform/mtk-vcodec/vdec_vpu_if.h
@@ -82,4 +82,22 @@ int vpu_dec_deinit(struct vdec_vpu_inst *vpu);
*/
int vpu_dec_reset(struct vdec_vpu_inst *vpu);
+/**
+ * vpu_dec_core - core start decoding, basically the function will be invoked
once
+ * every frame.
+ *
+ * @vpu : instance for vdec_vpu_inst
+ */
+int vpu_dec_core(struct vdec_vpu_inst *vpu);
+
+/**
+ * vpu_dec_core_end - core end decoding, basically the function will be
invoked once
+ * when core HW decoding done and receive interrupt
successfully. The
+ * decoder in VPU will updata hardware information and deinit
hardware
+ * and check if there is a new decoded frame available to
display.
+ *
+ * @vpu : instance for vdec_vpu_inst
+ */
+int vpu_dec_core_end(struct vdec_vpu_inst *vpu);
+
#endif
--
2.25.1
[PATCH v6, 13/15] dt-bindings: media: mtk-vcodec: Adds decoder dt-bindings for mt8192
Adds decoder dt-bindings for mt8192. Signed-off-by: Yunfei Dong --- v6: add decoder block diagram for Laurent's comments. This patch depends on "Mediatek MT8192 clock support"[1]. The definition of decoder clocks are in mt8192-clk.h, and this patch already in clk tree[1]. [1]https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git/commit/?h=clk-next&id=f35f1a23e0e12e3173e9e9dedbc150d139027189 --- .../media/mediatek,vcodec-comp-decoder.yaml | 192 ++ 1 file changed, 192 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/mediatek,vcodec-comp-decoder.yaml diff --git a/Documentation/devicetree/bindings/media/mediatek,vcodec-comp-decoder.yaml b/Documentation/devicetree/bindings/media/mediatek,vcodec-comp-decoder.yaml new file mode 100644 index ..2184cf7ef9e3 --- /dev/null +++ b/Documentation/devicetree/bindings/media/mediatek,vcodec-comp-decoder.yaml @@ -0,0 +1,192 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iommu/mediatek,vcodec-comp-decoder.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Mediatek Video Decode Accelerator With Component + +maintainers: + - Yunfei Dong + +description: |+ + Mediatek Video Decode is the video decode hardware present in Mediatek + SoCs which supports high resolution decoding functionalities. Required + master and component node. + + About the Decoder Hardware Block Diagram, please check below: + ++-++ +| || +| input -> lat HW -> lat buffer --|--> lat buffer -> core HW -> output | +||| | || | ++||---+-||-+ + || lat thread | core thread|| +-||-|| + || || + \/\/ + +--+ + |enable/disable| + | clk powerirqiommu port | + | (lat/lat soc/core0/core1)| + +--+ + + As above, mean in master device, mean in component device. + The information of each hardware will be stored in each component device. There + are two thread in master device: lat and core. Enable/disable the lat clk/power/irq + when lat hardware 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. + +properties: + compatible: + - enum: + - mediatek,mt8192-vcodec-dec # for lat hardware + - mediatek,mtk-vcodec-lat # for core hardware + - mediatek,mtk-vcodec-core + + reg: +maxItems: 1 + + interrupts: +maxItems: 1 + + clocks: +maxItems: 5 + + clock-names: +items: + - const: vdec-sel + - const: vdec-soc-vdec + - const: vdec-soc-lat + - const: vdec-vdec + - const: vdec-top + + power-domains: +maxItems: 1 + + iommus: +minItems: 1 +maxItems: 32 +description: | + List of the hardware port in respective IOMMU block for current Socs. + Refer to bindings/iommu/mediatek,iommu.yaml. + + dma-ranges: +maxItems: 1 +description: | + Describes the physical address space of IOMMU maps to memory. + + mediatek,scp: +$ref: /schemas/types.yaml#/definitions/phandle +maxItems: 1 +description: + Describes point to scp. + +required: + - compatible + - reg + - iommus + - dma-ranges + +allOf: + - if: #master node + properties: +compatible: + contains: +enum: + - mediatek,mt8192-vcodec-dec # for lat hardware + +then: + required: +- mediatek,scp + + - if: #component node + properties: +compatible: + contains: +enum: + - mediatek,mtk-vcodec-lat # for core hardware + - mediatek,mtk-vcodec-core + +then: + required: +- interrupts +- clocks +- clock-names +- assigned-clocks +- assigned-clock-parents +- power-domains + + +additionalProperties: false + +examples: + - | +#include +#include +#include +#include +#include + +vcodec_dec: vcodec_dec@1600 { +compatible = "mediatek,mt8192-vcodec-dec"; +reg = <0 0x1600 0 0x1000>; /* VDEC_SYS */ +mediatek,scp = <&scp>; +iommus = <&iom
[PATCH v6, 15/15] media: mtk-vcodec: Use codec type to separate different hardware
There are just one core thread, in order to separeate different
hardware, using codec type to separeate it in scp driver.
Signed-off-by: Yunfei Dong
---
.../media/platform/mtk-vcodec/vdec_ipi_msg.h | 12 ---
.../media/platform/mtk-vcodec/vdec_vpu_if.c | 34 ---
.../media/platform/mtk-vcodec/vdec_vpu_if.h | 4 +++
3 files changed, 41 insertions(+), 9 deletions(-)
diff --git a/drivers/media/platform/mtk-vcodec/vdec_ipi_msg.h
b/drivers/media/platform/mtk-vcodec/vdec_ipi_msg.h
index 9d8079c4f976..c488f0c40190 100644
--- a/drivers/media/platform/mtk-vcodec/vdec_ipi_msg.h
+++ b/drivers/media/platform/mtk-vcodec/vdec_ipi_msg.h
@@ -35,6 +35,8 @@ enum vdec_ipi_msgid {
* @msg_id : vdec_ipi_msgid
* @vpu_inst_addr : VPU decoder instance address. Used if ABI version < 2.
* @inst_id : instance ID. Used if the ABI version >= 2.
+ * @codec_type : Codec fourcc
+ * @reserved : reserved param
*/
struct vdec_ap_ipi_cmd {
uint32_t msg_id;
@@ -42,6 +44,8 @@ struct vdec_ap_ipi_cmd {
uint32_t vpu_inst_addr;
uint32_t inst_id;
};
+ uint32_t codec_type;
+ uint32_t reserved;
};
/**
@@ -59,12 +63,12 @@ struct vdec_vpu_ipi_ack {
/**
* struct vdec_ap_ipi_init - for AP_IPIMSG_DEC_INIT
* @msg_id : AP_IPIMSG_DEC_INIT
- * @reserved : Reserved field
+ * @codec_type : Codec fourcc
* @ap_inst_addr : AP video decoder instance address
*/
struct vdec_ap_ipi_init {
uint32_t msg_id;
- uint32_t reserved;
+ uint32_t codec_type;
uint64_t ap_inst_addr;
};
@@ -77,7 +81,7 @@ struct vdec_ap_ipi_init {
* H264 decoder [0]:buf_sz [1]:nal_start
* VP8 decoder [0]:width/height
* VP9 decoder [0]:profile, [1][2] width/height
- * @reserved : Reserved field
+ * @codec_type : Codec fourcc
*/
struct vdec_ap_ipi_dec_start {
uint32_t msg_id;
@@ -86,7 +90,7 @@ struct vdec_ap_ipi_dec_start {
uint32_t inst_id;
};
uint32_t data[3];
- uint32_t reserved;
+ uint32_t codec_type;
};
/**
diff --git a/drivers/media/platform/mtk-vcodec/vdec_vpu_if.c
b/drivers/media/platform/mtk-vcodec/vdec_vpu_if.c
index bfd8e87dceff..c84fac52fe26 100644
--- a/drivers/media/platform/mtk-vcodec/vdec_vpu_if.c
+++ b/drivers/media/platform/mtk-vcodec/vdec_vpu_if.c
@@ -100,18 +100,29 @@ static void vpu_dec_ipi_handler(void *data, unsigned int
len, void *priv)
static int vcodec_vpu_send_msg(struct vdec_vpu_inst *vpu, void *msg, int len)
{
- int err;
+ int err, id, msgid;
- mtk_vcodec_debug(vpu, "id=%X", *(uint32_t *)msg);
+ msgid = *(uint32_t *)msg;
+ mtk_vcodec_debug(vpu, "id=%X", msgid);
vpu->failure = 0;
vpu->signaled = 0;
- err = mtk_vcodec_fw_ipi_send(vpu->ctx->dev->fw_handler, vpu->id, msg,
+ if (vpu->ctx->dev->vdec_pdata->hw_arch == MTK_VDEC_LAT_SINGLE_CORE) {
+ if (msgid == AP_IPIMSG_DEC_CORE ||
+ msgid == AP_IPIMSG_DEC_CORE_END)
+ id = vpu->core_id;
+ else
+ id = vpu->id;
+ } else {
+ id = vpu->id;
+ }
+
+ err = mtk_vcodec_fw_ipi_send(vpu->ctx->dev->fw_handler, id, msg,
len, 2000);
if (err) {
mtk_vcodec_err(vpu, "send fail vpu_id=%d msg_id=%X status=%d",
- vpu->id, *(uint32_t *)msg, err);
+ id, msgid, err);
return err;
}
@@ -131,6 +142,7 @@ static int vcodec_send_ap_ipi(struct vdec_vpu_inst *vpu,
unsigned int msg_id)
msg.vpu_inst_addr = vpu->inst_addr;
else
msg.inst_id = vpu->inst_id;
+ msg.codec_type = vpu->codec_type;
err = vcodec_vpu_send_msg(vpu, &msg, sizeof(msg));
mtk_vcodec_debug(vpu, "- id=%X ret=%d", msg_id, err);
@@ -149,14 +161,25 @@ int vpu_dec_init(struct vdec_vpu_inst *vpu)
err = mtk_vcodec_fw_ipi_register(vpu->ctx->dev->fw_handler, vpu->id,
vpu->handler, "vdec", NULL);
- if (err != 0) {
+ if (err) {
mtk_vcodec_err(vpu, "vpu_ipi_register fail status=%d", err);
return err;
}
+ if (vpu->ctx->dev->vdec_pdata->hw_arch == MTK_VDEC_LAT_SINGLE_CORE) {
+ err = mtk_vcodec_fw_ipi_register(vpu->ctx->dev->fw_handler,
+vpu->core_id, vpu->handler,
+"vdec", NULL);
+ if (err) {
+ mtk_vcodec_err(vpu, "vpu_ipi_register core fail
status=%d", err);
+ return err;
+ }
+ }
+
memset(&msg, 0, sizeof(msg));
msg.msg_id = AP_IPIMSG_DEC_INIT;
msg.ap_inst_addr = (unsigned long)vpu;
+ msg.codec_type = vpu->codec_type;
mtk_vcodec_debug(vpu, "vdec_inst=%
[PATCH v6, 12/15] media: mtk-vcodec: Support 34bits dma address for vdec
Use the dma_set_mask_and_coherent helper to set vdec DMA bit mask to support 34bits iova space(16GB) that the mt8192 iommu HW support. Whole the iova range separate to 0~4G/4G~8G/8G~12G/12G~16G, regarding which iova range VDEC actually locate, it depends on the dma-ranges property of vdec dtsi node. Signed-off-by: Yunfei Dong --- drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c | 3 +++ 1 file changed, 3 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 002352fcf8de..1a8d9308327d 100644 --- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c +++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c @@ -417,6 +417,9 @@ static int mtk_vcodec_probe(struct platform_device *pdev) } } + if (of_get_property(pdev->dev.of_node, "dma-ranges", NULL)) + dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(34)); + for (i = 0; i < MTK_VDEC_HW_MAX; i++) mutex_init(&dev->dec_mutex[i]); spin_lock_init(&dev->irqlock); -- 2.25.1
Re: [PATCH v2 1/2] drm/msm/dsi: Use "ref" fw clock instead of global name for VCO parent
Hi Stephen, On 2021-08-31 22:35:12, Stephen Boyd wrote: > Quoting Marijn Suijten (2021-08-30 16:10:26) > > > > I'm 95% sure this shouldn't cause any problems given current DTs and > > their history, but that's probably not enough. This might also impact > > DTs that have not yet been upstreamed, but afaik the general stance is > > to not care and actually serve as a fair hint/warning before new DTs > > make it to the list. > > > > If there is a protocol in place to deprecate, warn, and eventually > > remove this reliance on global clock names I'm more than happy to add > > .name as a temporary fallback, even if likely unneeded. Otherwise we > > might never get rid of it. > > I'm not aware of any protocol to deprecate, warn, and remove the > fallback name. It's a fallback because it can't ever really be removed. That is unfortunate, I was hoping for a breaking "kernel release" at some point where we could say "no more, update your DTs first". But that may not be possible in every scenario? > Anyway, if you're not willing to add the .name then that's fine. I feel like .name has caused more problems for us than it solves, but in a fallback position it might be fine. My main gripe is that I don't want DT to rely on the clock to also be discoverable through the clock tree, which we've seen on many occasions (not sure if the former was done upstream, but: "xo" being renamed to "xo_board", and DSI PLL clocks loosing +1 causing a naming mismatch with what mmcc expects, to name some examples). Omitting .name is the only way to enforce that. > We can > deal with the problem easily by adding a .name in the future if someone > complains that things aren't working. Sound like a plan? If so, it's > probably good to add some sort of note in the commit text so that when > the bisector lands on this patch they can realize that this > intentionally broke them. I'm all for this but lack the industrial knowledge to sign off on the approach. Bjorn and Dmitry should ack/agree before going ahead (you may wonder why I'm worrying about getting clock drivers and DT in sync on platforms I don't own...): We have the following situations: - apq8064 used the wrong clock. Bjorn acknowledged that landing the DT fix in 5.15, and this patch in 5.16 should give enough time for DT to be updated (this is nothing we can fix with .name anyway). - msm8974 doesn't have the clock at all. Dmitry recommended to add .name for this specific case, but I'm wondering if the 5.15 -> 5.16 window is enough to update DTs too? - msm8916 and sdm845 had the missing "ref" clock added three years ago. Would a 5.16 kernel still work in any meaningful way with a DT that old? Should we decide on a case-by-case basis whether to add .name, ie. only for (some/all) of the aforementioned SoCs? Thanks! - Marijn
Re: [PATCH v2 2/2] clk: qcom: gcc-sdm660: Remove transient global "xo" clock
On 2021-08-31 22:35:56, Stephen Boyd wrote: > Quoting Marijn Suijten (2021-08-30 11:24:45) > > The DSI PHY/PLL was relying on a global "xo" clock to be found, but the > > real clock is named "xo_board" in the DT. The standard nowadays is to > > never use global clock names anymore but require the firmware (DT) to > > provide every clock binding explicitly with .fw_name. The DSI PLLs have > > since been converted to this mechanism (specifically 14nm for SDM660) > > and this transient clock can now be removed. > > > > This issue was originally discovered in: > > https://lore.kernel.org/linux-arm-msm/386db1a6-a1cd-3c7d-a88e-dc83f8a1b...@somainline.org/ > > and prevented the removal of "xo" at that time. > > > > Signed-off-by: Marijn Suijten > > --- > > Presumably this wants to go with the first one. What are you referring to with "the first one"? This patch can only go in after patch 1/2 of this series, unless you are suggesting to squash it with Bjorns cleanup and making sure that lands after the fix in the DSI? > Acked-by: Stephen Boyd
Re: [RFC PATCH 0/4] Allow to use DRM fbdev emulation layer with CONFIG_FB disabled
On 8/31/21 2:35 PM, Daniel Vetter wrote: > On Sat, Aug 28, 2021 at 12:02:21AM +0200, Javier Martinez Canillas wrote: [snip] >> >> We talked about a drmcon with Peter Robinson as well but then decided that a >> way to disable CONFIG_FB but still having the DRM fbdev emulation could be a >> intermediary step, hence these RFC patches. >> >> But yes, I agree that a drmcon would be the proper approach for this, to not >> need any fbdev support at all. We will just keep the explicit disable for the >> fbdev drivers then in the meantime. > > I think the only intermediate step would be to disable the fbdev uapi > (char node and anything in sysfs), while still registering against the > fbcon layer so you have a console. > Right, $subject disabled the sysfs interface but left the fbdev chardev. I can try to do a v2 that also disables that interface but just keep the fbcon part. > But looking at the things syzbot finds the really problematic code is all > in the fbcon and console layer in general, and /dev/fb0 seems pretty > solid. > Yes, but still would be an improvement in the sense that no legacy fbdev uAPI will be exposed and so user-space would only depend on the DRM/KMS interface. > I think for a substantial improvement here in robustness what you really > want is > - kmscon in userspace > - disable FB layer > - ideally also disable console/vt layer in the kernel Earlier in the thread it was mentioned that an in-kernel drmcon could be used instead. My worry with kmscon is that moving something as critical as console output to user-space might make harder to troubleshoot early booting issues. And also that will require user-space changes. An in-kernel drmcon could be a drop-in replacement though. > - have a minimal emergency/boot-up log thing in drm, patches for that > floated around a few times > Interesting. Do you have any pointers for this? My search-fu failed me when trying to find these patches. Best regards, -- Javier Martinez Canillas Linux Engineering Red Hat
[PATCH v2 10/52] dt-bindings: display: Move idk-1110wr to panel-lvds
The Advantech IDK-2121WR Device Tree binding doesn't really add any
useful content that is not already present in the panel-lvds binding
aside from a requirement on the data-mapping.
Let's move it to the generic panel-lvds binding
Cc: dri-devel@lists.freedesktop.org
Cc: Laurent Pinchart
Cc: Sam Ravnborg
Cc: Thierry Reding
Signed-off-by: Maxime Ripard
---
.../display/panel/advantech,idk-1110wr.yaml | 69 ---
.../bindings/display/panel/lvds.yaml | 22 --
2 files changed, 15 insertions(+), 76 deletions(-)
delete mode 100644
Documentation/devicetree/bindings/display/panel/advantech,idk-1110wr.yaml
diff --git
a/Documentation/devicetree/bindings/display/panel/advantech,idk-1110wr.yaml
b/Documentation/devicetree/bindings/display/panel/advantech,idk-1110wr.yaml
deleted file mode 100644
index 93878c2cd370..
--- a/Documentation/devicetree/bindings/display/panel/advantech,idk-1110wr.yaml
+++ /dev/null
@@ -1,69 +0,0 @@
-# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
-%YAML 1.2
-$id: http://devicetree.org/schemas/display/panel/advantech,idk-1110wr.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: Advantech IDK-1110WR 10.1" WSVGA LVDS Display Panel
-
-maintainers:
- - Lad Prabhakar
- - Thierry Reding
-
-allOf:
- - $ref: lvds.yaml#
-
-properties:
- compatible:
-items:
- - const: advantech,idk-1110wr
- - {} # panel-lvds, but not listed here to avoid false select
-
- data-mapping:
-const: jeida-24
-
- width-mm:
-const: 223
-
- height-mm:
-const: 125
-
- panel-timing: true
- port: true
-
-additionalProperties: false
-
-required:
- - compatible
-
-examples:
- - |+
-panel {
- compatible = "advantech,idk-1110wr", "panel-lvds";
-
- width-mm = <223>;
- height-mm = <125>;
-
- data-mapping = "jeida-24";
-
- panel-timing {
-/* 1024x600 @60Hz */
-clock-frequency = <5120>;
-hactive = <1024>;
-vactive = <600>;
-hsync-len = <240>;
-hfront-porch = <40>;
-hback-porch = <40>;
-vsync-len = <10>;
-vfront-porch = <15>;
-vback-porch = <10>;
- };
-
- port {
-panel_in: endpoint {
- remote-endpoint = <&lvds_encoder>;
-};
- };
-};
-
-...
diff --git a/Documentation/devicetree/bindings/display/panel/lvds.yaml
b/Documentation/devicetree/bindings/display/panel/lvds.yaml
index 49460c9dceea..e4e49e06f302 100644
--- a/Documentation/devicetree/bindings/display/panel/lvds.yaml
+++ b/Documentation/devicetree/bindings/display/panel/lvds.yaml
@@ -28,15 +28,23 @@ description: |+
allOf:
- $ref: panel-common.yaml#
+ - if:
+ properties:
+compatible:
+ contains:
+const: advantech,idk-1110wr
+
+then:
+ properties:
+data-mapping:
+ const: jeida-24
properties:
compatible:
-contains:
- const: panel-lvds
-description:
- Shall contain "panel-lvds" in addition to a mandatory panel-specific
- compatible string defined in individual panel bindings. The "panel-lvds"
- value shall never be used on its own.
+items:
+ - enum:
+ - advantech,idk-1110wr
+ - const: panel-lvds
data-mapping:
enum:
@@ -112,6 +120,6 @@ oneOf:
- required:
- ports
-additionalProperties: true
+unevaluatedProperties: false
...
--
2.31.1
[PATCH v2 11/52] dt-bindings: display: Move idk-2121wr to panel-lvds
The Advantech IDK-2121WR Device Tree binding uses most of the panel-lvds
binding, aside from a requirement on the data-mapping and the
definition of the dual link binding.
The LVDS dual link binding applies to any panel with a dual-link setup,
and thus could be made generic, and we can move the data-mapping
requirement to a conditional.
Let's move it to the generic panel-lvds binding
Cc: dri-devel@lists.freedesktop.org
Cc: Laurent Pinchart
Cc: Sam Ravnborg
Cc: Thierry Reding
Signed-off-by: Maxime Ripard
---
.../display/panel/advantech,idk-2121wr.yaml | 121 --
.../bindings/display/panel/lvds.yaml | 88 -
2 files changed, 87 insertions(+), 122 deletions(-)
delete mode 100644
Documentation/devicetree/bindings/display/panel/advantech,idk-2121wr.yaml
diff --git
a/Documentation/devicetree/bindings/display/panel/advantech,idk-2121wr.yaml
b/Documentation/devicetree/bindings/display/panel/advantech,idk-2121wr.yaml
deleted file mode 100644
index 67682fe77f10..
--- a/Documentation/devicetree/bindings/display/panel/advantech,idk-2121wr.yaml
+++ /dev/null
@@ -1,121 +0,0 @@
-# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
-%YAML 1.2
-$id: http://devicetree.org/schemas/display/panel/advantech,idk-2121wr.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: Advantech IDK-2121WR 21.5" Full-HD dual-LVDS panel
-
-maintainers:
- - Lad Prabhakar
- - Thierry Reding
-
-description: |
- The IDK-2121WR from Advantech is a Full-HD dual-LVDS panel.
- A dual-LVDS interface is a dual-link connection with even pixels traveling
- on one link, and with odd pixels traveling on the other link.
-
- The panel expects odd pixels on the first port, and even pixels on the
- second port, therefore the ports must be marked accordingly (with either
- dual-lvds-odd-pixels or dual-lvds-even-pixels).
-
-properties:
- compatible:
-items:
- - const: advantech,idk-2121wr
- - {} # panel-lvds, but not listed here to avoid false select
-
- width-mm:
-const: 476
-
- height-mm:
-const: 268
-
- data-mapping:
-const: vesa-24
-
- panel-timing: true
-
- ports:
-$ref: /schemas/graph.yaml#/properties/ports
-
-properties:
- port@0:
-$ref: /schemas/graph.yaml#/$defs/port-base
-unevaluatedProperties: false
-description: The sink for odd pixels.
-properties:
- dual-lvds-odd-pixels: true
-
-required:
- - dual-lvds-odd-pixels
-
- port@1:
-$ref: /schemas/graph.yaml#/$defs/port-base
-unevaluatedProperties: false
-description: The sink for even pixels.
-properties:
- dual-lvds-even-pixels: true
-
-required:
- - dual-lvds-even-pixels
-
-required:
- - port@0
- - port@1
-
-additionalProperties: false
-
-required:
- - compatible
- - width-mm
- - height-mm
- - data-mapping
- - panel-timing
- - ports
-
-examples:
- - |+
-panel-lvds {
- compatible = "advantech,idk-2121wr", "panel-lvds";
-
- width-mm = <476>;
- height-mm = <268>;
-
- data-mapping = "vesa-24";
-
- panel-timing {
-clock-frequency = <14850>;
-hactive = <1920>;
-vactive = <1080>;
-hsync-len = <44>;
-hfront-porch = <88>;
-hback-porch = <148>;
-vfront-porch = <4>;
-vback-porch = <36>;
-vsync-len = <5>;
- };
-
- ports {
-#address-cells = <1>;
-#size-cells = <0>;
-
-port@0 {
- reg = <0>;
- dual-lvds-odd-pixels;
- panel_in0: endpoint {
-remote-endpoint = <&lvds0_out>;
- };
-};
-
-port@1 {
- reg = <1>;
- dual-lvds-even-pixels;
- panel_in1: endpoint {
-remote-endpoint = <&lvds1_out>;
- };
-};
- };
-};
-
-...
diff --git a/Documentation/devicetree/bindings/display/panel/lvds.yaml
b/Documentation/devicetree/bindings/display/panel/lvds.yaml
index e4e49e06f302..9b3b329e4e67 100644
--- a/Documentation/devicetree/bindings/display/panel/lvds.yaml
+++ b/Documentation/devicetree/bindings/display/panel/lvds.yaml
@@ -39,11 +39,26 @@ allOf:
data-mapping:
const: jeida-24
+ - if:
+ properties:
+compatible:
+ contains:
+const: advantech,idk-2121wr
+
+then:
+ properties:
+data-mapping:
+ const: vesa-24
+
+ required:
+- ports
+
properties:
compatible:
items:
- enum:
- advantech,idk-1110wr
+ - advantech,idk-2121wr
- const: panel-lvds
data-mapping:
@@ -105,7 +120,34 @@ properties:
data lanes, transmitting bits for slots 6 to 0 instead of 0 to 6.
port: true
- ports: true
+
+ ports:
+$ref: /schemas/graph.yaml#/properties/ports
+
+properties:
+ port@0:
+$ref: /schemas/graph.yaml#/$defs/port-base
+unevaluatedPr
[PATCH v2 12/52] dt-bindings: display: Move ee101ia-01d to panel-lvds
The Innolux EE101IA-01D Device Tree binding doesn't really add any
useful content that is not already present in the panel-lvds binding.
Let's move it to the generic panel-lvds binding
Cc: dri-devel@lists.freedesktop.org
Cc: Laurent Pinchart
Cc: Sam Ravnborg
Cc: Thierry Reding
Signed-off-by: Maxime Ripard
---
.../display/panel/innolux,ee101ia-01d.yaml| 31 ---
.../bindings/display/panel/lvds.yaml | 1 +
2 files changed, 1 insertion(+), 31 deletions(-)
delete mode 100644
Documentation/devicetree/bindings/display/panel/innolux,ee101ia-01d.yaml
diff --git
a/Documentation/devicetree/bindings/display/panel/innolux,ee101ia-01d.yaml
b/Documentation/devicetree/bindings/display/panel/innolux,ee101ia-01d.yaml
deleted file mode 100644
index a69681e724cb..
--- a/Documentation/devicetree/bindings/display/panel/innolux,ee101ia-01d.yaml
+++ /dev/null
@@ -1,31 +0,0 @@
-# SPDX-License-Identifier: GPL-2.0
-%YAML 1.2
-$id: http://devicetree.org/schemas/display/panel/innolux,ee101ia-01d.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: Innolux Corporation 10.1" EE101IA-01D WXGA (1280x800) LVDS panel
-
-maintainers:
- - Heiko Stuebner
- - Thierry Reding
-
-allOf:
- - $ref: lvds.yaml#
-
-properties:
- compatible:
-items:
- - const: innolux,ee101ia-01d
- - {} # panel-lvds, but not listed here to avoid false select
-
- backlight: true
- enable-gpios: true
- power-supply: true
- width-mm: true
- height-mm: true
- panel-timing: true
- port: true
-
-additionalProperties: false
-...
diff --git a/Documentation/devicetree/bindings/display/panel/lvds.yaml
b/Documentation/devicetree/bindings/display/panel/lvds.yaml
index 9b3b329e4e67..91a6d97a96e0 100644
--- a/Documentation/devicetree/bindings/display/panel/lvds.yaml
+++ b/Documentation/devicetree/bindings/display/panel/lvds.yaml
@@ -59,6 +59,7 @@ properties:
- enum:
- advantech,idk-1110wr
- advantech,idk-2121wr
+ - innolux,ee101ia-01d
- const: panel-lvds
data-mapping:
--
2.31.1
[PATCH v2 13/52] dt-bindings: display: aa104xd12: Remove unused vcc-supply
The Mitsubishi AA140XD12 Device Tree Binding was requiring a vcc-supply
property. However, neither the existing device trees using that binding,
nor the driver were actually using that property which is also redundant
with power-supply. Let's just drop it.
Cc: dri-devel@lists.freedesktop.org
Cc: Laurent Pinchart
Cc: Sam Ravnborg
Cc: Thierry Reding
Signed-off-by: Maxime Ripard
---
.../bindings/display/panel/mitsubishi,aa104xd12.yaml | 5 -
1 file changed, 5 deletions(-)
diff --git
a/Documentation/devicetree/bindings/display/panel/mitsubishi,aa104xd12.yaml
b/Documentation/devicetree/bindings/display/panel/mitsubishi,aa104xd12.yaml
index b5e7ee230fa6..b595edd58bbb 100644
--- a/Documentation/devicetree/bindings/display/panel/mitsubishi,aa104xd12.yaml
+++ b/Documentation/devicetree/bindings/display/panel/mitsubishi,aa104xd12.yaml
@@ -19,9 +19,6 @@ properties:
- const: mitsubishi,aa104xd12
- {} # panel-lvds, but not listed here to avoid false select
- vcc-supply:
-description: Reference to the regulator powering the panel VCC pins.
-
data-mapping:
const: jeida-24
@@ -38,14 +35,12 @@ additionalProperties: false
required:
- compatible
- - vcc-supply
examples:
- |+
panel {
compatible = "mitsubishi,aa104xd12", "panel-lvds";
- vcc-supply = <&vcc_3v3>;
width-mm = <210>;
height-mm = <158>;
--
2.31.1
[PATCH v2 14/52] dt-bindings: display: aa104xd12: Fix data-mapping
The Mitsubishi AA140XD12 Device Tree Binding was requiring a
data-mapping property value which was set to another value in the
existing Device Trees. Fix this.
Cc: dri-devel@lists.freedesktop.org
Cc: Laurent Pinchart
Cc: Sam Ravnborg
Cc: Thierry Reding
Signed-off-by: Maxime Ripard
---
.../bindings/display/panel/mitsubishi,aa104xd12.yaml | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
a/Documentation/devicetree/bindings/display/panel/mitsubishi,aa104xd12.yaml
b/Documentation/devicetree/bindings/display/panel/mitsubishi,aa104xd12.yaml
index b595edd58bbb..2d1c85e377cd 100644
--- a/Documentation/devicetree/bindings/display/panel/mitsubishi,aa104xd12.yaml
+++ b/Documentation/devicetree/bindings/display/panel/mitsubishi,aa104xd12.yaml
@@ -20,7 +20,7 @@ properties:
- {} # panel-lvds, but not listed here to avoid false select
data-mapping:
-const: jeida-24
+const: jeida-18
width-mm:
const: 210
@@ -45,7 +45,7 @@ examples:
width-mm = <210>;
height-mm = <158>;
- data-mapping = "jeida-24";
+ data-mapping = "jeida-18";
panel-timing {
/* 1024x768 @65Hz */
--
2.31.1
[PATCH v2 15/52] dt-bindings: display: Move aa104xd12 to panel-lvds
The Mitsubishi AA104XD12 Device Tree binding doesn't really add any
useful content that is not already present in the panel-lvds binding
aside from a requirement on the data-mapping.
Let's move it to the generic panel-lvds binding
Cc: dri-devel@lists.freedesktop.org
Cc: Laurent Pinchart
Cc: Sam Ravnborg
Cc: Thierry Reding
Signed-off-by: Maxime Ripard
---
.../bindings/display/panel/lvds.yaml | 12
.../display/panel/mitsubishi,aa104xd12.yaml | 70 ---
2 files changed, 12 insertions(+), 70 deletions(-)
delete mode 100644
Documentation/devicetree/bindings/display/panel/mitsubishi,aa104xd12.yaml
diff --git a/Documentation/devicetree/bindings/display/panel/lvds.yaml
b/Documentation/devicetree/bindings/display/panel/lvds.yaml
index 91a6d97a96e0..09a818a60f2e 100644
--- a/Documentation/devicetree/bindings/display/panel/lvds.yaml
+++ b/Documentation/devicetree/bindings/display/panel/lvds.yaml
@@ -28,6 +28,17 @@ description: |+
allOf:
- $ref: panel-common.yaml#
+ - if:
+ properties:
+compatible:
+ contains:
+const: mitsubishi,aa104xd12
+
+then:
+ properties:
+data-mapping:
+ const: jeida-18
+
- if:
properties:
compatible:
@@ -60,6 +71,7 @@ properties:
- advantech,idk-1110wr
- advantech,idk-2121wr
- innolux,ee101ia-01d
+ - mitsubishi,aa104xd12
- const: panel-lvds
data-mapping:
diff --git
a/Documentation/devicetree/bindings/display/panel/mitsubishi,aa104xd12.yaml
b/Documentation/devicetree/bindings/display/panel/mitsubishi,aa104xd12.yaml
deleted file mode 100644
index 2d1c85e377cd..
--- a/Documentation/devicetree/bindings/display/panel/mitsubishi,aa104xd12.yaml
+++ /dev/null
@@ -1,70 +0,0 @@
-# SPDX-License-Identifier: GPL-2.0
-%YAML 1.2
-$id: http://devicetree.org/schemas/display/panel/mitsubishi,aa104xd12.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: Mitsubishi AA104XD12 10.4" XGA LVDS Display Panel
-
-maintainers:
- - Laurent Pinchart
- - Thierry Reding
-
-allOf:
- - $ref: lvds.yaml#
-
-properties:
- compatible:
-items:
- - const: mitsubishi,aa104xd12
- - {} # panel-lvds, but not listed here to avoid false select
-
- data-mapping:
-const: jeida-18
-
- width-mm:
-const: 210
-
- height-mm:
-const: 158
-
- panel-timing: true
- port: true
-
-additionalProperties: false
-
-required:
- - compatible
-
-examples:
- - |+
-
-panel {
- compatible = "mitsubishi,aa104xd12", "panel-lvds";
-
- width-mm = <210>;
- height-mm = <158>;
-
- data-mapping = "jeida-18";
-
- panel-timing {
-/* 1024x768 @65Hz */
-clock-frequency = <6500>;
-hactive = <1024>;
-vactive = <768>;
-hsync-len = <136>;
-hfront-porch = <20>;
-hback-porch = <160>;
-vfront-porch = <3>;
-vback-porch = <29>;
-vsync-len = <6>;
- };
-
- port {
-panel_in: endpoint {
- remote-endpoint = <&lvds_encoder>;
-};
- };
-};
-
-...
--
2.31.1
[PATCH v2 16/52] dt-bindings: display: aa121td01: Remove unused vcc-supply
The Mitsubishi AA121TD01 Device Tree Binding was requiring a vcc-supply
property. However, neither the existing device trees using that binding,
nor the driver were actually using that property which is also redundant
with power-supply. Let's just drop it.
Cc: dri-devel@lists.freedesktop.org
Cc: Laurent Pinchart
Cc: Sam Ravnborg
Cc: Thierry Reding
Signed-off-by: Maxime Ripard
---
.../bindings/display/panel/mitsubishi,aa121td01.yaml | 5 -
1 file changed, 5 deletions(-)
diff --git
a/Documentation/devicetree/bindings/display/panel/mitsubishi,aa121td01.yaml
b/Documentation/devicetree/bindings/display/panel/mitsubishi,aa121td01.yaml
index 977c50a85b67..b0f1d4eff12d 100644
--- a/Documentation/devicetree/bindings/display/panel/mitsubishi,aa121td01.yaml
+++ b/Documentation/devicetree/bindings/display/panel/mitsubishi,aa121td01.yaml
@@ -19,9 +19,6 @@ properties:
- const: mitsubishi,aa121td01
- {} # panel-lvds, but not listed here to avoid false select
- vcc-supply:
-description: Reference to the regulator powering the panel VCC pins.
-
data-mapping:
const: jeida-24
@@ -38,13 +35,11 @@ additionalProperties: false
required:
- compatible
- - vcc-supply
examples:
- |+
panel {
compatible = "mitsubishi,aa121td01", "panel-lvds";
- vcc-supply = <&vcc_3v3>;
width-mm = <261>;
height-mm = <163>;
--
2.31.1
[PATCH v2 17/52] dt-bindings: display: aa121td01: Fix data-mapping
The Mitsubishi AA121TD01 Device Tree Binding was requiring a
data-mapping property value which was set to another value in the
existing Device Trees. Fix this.
Cc: dri-devel@lists.freedesktop.org
Cc: Laurent Pinchart
Cc: Sam Ravnborg
Cc: Thierry Reding
Signed-off-by: Maxime Ripard
---
.../bindings/display/panel/mitsubishi,aa121td01.yaml | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
a/Documentation/devicetree/bindings/display/panel/mitsubishi,aa121td01.yaml
b/Documentation/devicetree/bindings/display/panel/mitsubishi,aa121td01.yaml
index b0f1d4eff12d..467a0ed4d444 100644
--- a/Documentation/devicetree/bindings/display/panel/mitsubishi,aa121td01.yaml
+++ b/Documentation/devicetree/bindings/display/panel/mitsubishi,aa121td01.yaml
@@ -20,7 +20,7 @@ properties:
- {} # panel-lvds, but not listed here to avoid false select
data-mapping:
-const: jeida-24
+const: jeida-18
width-mm:
const: 261
@@ -44,7 +44,7 @@ examples:
width-mm = <261>;
height-mm = <163>;
- data-mapping = "jeida-24";
+ data-mapping = "jeida-18";
panel-timing {
/* 1280x800 @60Hz */
--
2.31.1
[PATCH v2 18/52] dt-bindings: display: Move aa121td01 to panel-lvds
The Mitsubishi AA121TD01 Device Tree binding doesn't really add any
useful content that is not already present in the panel-lvds binding
aside from a requirement on the data-mapping.
Let's move it to the generic panel-lvds binding
Cc: dri-devel@lists.freedesktop.org
Cc: Laurent Pinchart
Cc: Sam Ravnborg
Cc: Thierry Reding
Signed-off-by: Maxime Ripard
---
.../bindings/display/panel/lvds.yaml | 5 +-
.../display/panel/mitsubishi,aa121td01.yaml | 69 ---
2 files changed, 4 insertions(+), 70 deletions(-)
delete mode 100644
Documentation/devicetree/bindings/display/panel/mitsubishi,aa121td01.yaml
diff --git a/Documentation/devicetree/bindings/display/panel/lvds.yaml
b/Documentation/devicetree/bindings/display/panel/lvds.yaml
index 09a818a60f2e..22f6cf1e134d 100644
--- a/Documentation/devicetree/bindings/display/panel/lvds.yaml
+++ b/Documentation/devicetree/bindings/display/panel/lvds.yaml
@@ -32,7 +32,9 @@ allOf:
properties:
compatible:
contains:
-const: mitsubishi,aa104xd12
+enum:
+ - mitsubishi,aa104xd12
+ - mitsubishi,aa121td01
then:
properties:
@@ -72,6 +74,7 @@ properties:
- advantech,idk-2121wr
- innolux,ee101ia-01d
- mitsubishi,aa104xd12
+ - mitsubishi,aa121td01
- const: panel-lvds
data-mapping:
diff --git
a/Documentation/devicetree/bindings/display/panel/mitsubishi,aa121td01.yaml
b/Documentation/devicetree/bindings/display/panel/mitsubishi,aa121td01.yaml
deleted file mode 100644
index 467a0ed4d444..
--- a/Documentation/devicetree/bindings/display/panel/mitsubishi,aa121td01.yaml
+++ /dev/null
@@ -1,69 +0,0 @@
-# SPDX-License-Identifier: GPL-2.0
-%YAML 1.2
-$id: http://devicetree.org/schemas/display/panel/mitsubishi,aa121td01.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: Mitsubishi AA121TD01 12.1" WXGA LVDS Display Panel
-
-maintainers:
- - Laurent Pinchart
- - Thierry Reding
-
-allOf:
- - $ref: lvds.yaml#
-
-properties:
- compatible:
-items:
- - const: mitsubishi,aa121td01
- - {} # panel-lvds, but not listed here to avoid false select
-
- data-mapping:
-const: jeida-18
-
- width-mm:
-const: 261
-
- height-mm:
-const: 163
-
- panel-timing: true
- port: true
-
-additionalProperties: false
-
-required:
- - compatible
-
-examples:
- - |+
-panel {
- compatible = "mitsubishi,aa121td01", "panel-lvds";
-
- width-mm = <261>;
- height-mm = <163>;
-
- data-mapping = "jeida-18";
-
- panel-timing {
-/* 1280x800 @60Hz */
-clock-frequency = <7100>;
-hactive = <1280>;
-vactive = <800>;
-hsync-len = <70>;
-hfront-porch = <20>;
-hback-porch = <70>;
-vsync-len = <5>;
-vfront-porch = <3>;
-vback-porch = <15>;
- };
-
- port {
-panel_in: endpoint {
- remote-endpoint = <&lvds_encoder>;
-};
- };
-};
-
-...
--
2.31.1
[PATCH v2 20/52] dt-bindings: display: panel-lvds: Document missing panel compatibles
A few panel-lvds compatibles were never documented. Let's add them. Cc: dri-devel@lists.freedesktop.org Cc: Laurent Pinchart Cc: Sam Ravnborg Cc: Thierry Reding Signed-off-by: Maxime Ripard --- Documentation/devicetree/bindings/display/panel/lvds.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/display/panel/lvds.yaml b/Documentation/devicetree/bindings/display/panel/lvds.yaml index 1563d57bc793..b2e8f5b263d7 100644 --- a/Documentation/devicetree/bindings/display/panel/lvds.yaml +++ b/Documentation/devicetree/bindings/display/panel/lvds.yaml @@ -73,10 +73,12 @@ properties: - enum: - advantech,idk-1110wr - advantech,idk-2121wr + - auo,b101ew05 - innolux,ee101ia-01d - mitsubishi,aa104xd12 - mitsubishi,aa121td01 - sgd,gktw70sdae4se + - tbs,a711-panel - const: panel-lvds data-mapping: -- 2.31.1
[PATCH v2 19/52] dt-bindings: display: Move gktw70sdae4se to panel-lvds
The Solomon Goldentek Display GKTW70SDAE4SE Device Tree binding doesn't
really add any useful content that is not already present in the
panel-lvds binding aside from a requirement on the data-mapping.
Let's move it to the generic panel-lvds binding
Cc: dri-devel@lists.freedesktop.org
Cc: Laurent Pinchart
Cc: Sam Ravnborg
Cc: Thierry Reding
Signed-off-by: Maxime Ripard
---
.../bindings/display/panel/lvds.yaml | 2 +
.../display/panel/sgd,gktw70sdae4se.yaml | 68 ---
2 files changed, 2 insertions(+), 68 deletions(-)
delete mode 100644
Documentation/devicetree/bindings/display/panel/sgd,gktw70sdae4se.yaml
diff --git a/Documentation/devicetree/bindings/display/panel/lvds.yaml
b/Documentation/devicetree/bindings/display/panel/lvds.yaml
index 22f6cf1e134d..1563d57bc793 100644
--- a/Documentation/devicetree/bindings/display/panel/lvds.yaml
+++ b/Documentation/devicetree/bindings/display/panel/lvds.yaml
@@ -35,6 +35,7 @@ allOf:
enum:
- mitsubishi,aa104xd12
- mitsubishi,aa121td01
+ - sgd,gktw70sdae4se
then:
properties:
@@ -75,6 +76,7 @@ properties:
- innolux,ee101ia-01d
- mitsubishi,aa104xd12
- mitsubishi,aa121td01
+ - sgd,gktw70sdae4se
- const: panel-lvds
data-mapping:
diff --git
a/Documentation/devicetree/bindings/display/panel/sgd,gktw70sdae4se.yaml
b/Documentation/devicetree/bindings/display/panel/sgd,gktw70sdae4se.yaml
deleted file mode 100644
index e63a570ae59d..
--- a/Documentation/devicetree/bindings/display/panel/sgd,gktw70sdae4se.yaml
+++ /dev/null
@@ -1,68 +0,0 @@
-# SPDX-License-Identifier: GPL-2.0
-%YAML 1.2
-$id: http://devicetree.org/schemas/display/panel/sgd,gktw70sdae4se.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: Solomon Goldentek Display GKTW70SDAE4SE 7" WVGA LVDS Display Panel
-
-maintainers:
- - Neil Armstrong
- - Thierry Reding
-
-allOf:
- - $ref: lvds.yaml#
-
-properties:
- compatible:
-items:
- - const: sgd,gktw70sdae4se
- - {} # panel-lvds, but not listed here to avoid false select
-
- data-mapping:
-const: jeida-18
-
- width-mm:
-const: 153
-
- height-mm:
-const: 86
-
- panel-timing: true
- port: true
-
-additionalProperties: false
-
-required:
- - compatible
-
-examples:
- - |+
-panel {
- compatible = "sgd,gktw70sdae4se", "panel-lvds";
-
- width-mm = <153>;
- height-mm = <86>;
-
- data-mapping = "jeida-18";
-
- panel-timing {
-clock-frequency = <3200>;
-hactive = <800>;
-vactive = <480>;
-hback-porch = <39>;
-hfront-porch = <39>;
-vback-porch = <29>;
-vfront-porch = <13>;
-hsync-len = <47>;
-vsync-len = <2>;
- };
-
- port {
-panel_in: endpoint {
- remote-endpoint = <&lvds_encoder>;
-};
- };
-};
-
-...
--
2.31.1
Re: [PATCH] drm/vc4: Make use of the helper function devm_platform_ioremap_resource()
On Tue, Aug 31, 2021 at 09:59:03PM +0800, Cai Huoqing wrote: > Use the devm_platform_ioremap_resource() helper instead of > calling platform_get_resource() and devm_ioremap_resource() > separately > > Signed-off-by: Cai Huoqing Applied, thanks Maxime signature.asc Description: PGP signature
Re: [PATCH] drm/sun4i: Make use of the helper function devm_platform_ioremap_resource()
On Tue, Aug 31, 2021 at 09:57:39PM +0800, Cai Huoqing wrote: > Use the devm_platform_ioremap_resource() helper instead of > calling platform_get_resource() and devm_ioremap_resource() > separately > > Signed-off-by: Cai Huoqing Applied, thanks Maxime signature.asc Description: PGP signature
Re: [PATCH] drm/sun4i: Fix macros in sun8i_csc.h
On Wed, Sep 01, 2021 at 11:13:01AM +0800, Chen-Yu Tsai wrote:
> On Wed, Sep 1, 2021 at 2:48 AM Jernej Skrabec
> wrote:
> >
> > Macros SUN8I_CSC_CTRL() and SUN8I_CSC_COEFF() don't follow usual
> > recommendation of having arguments enclosed in parenthesis. While that
> > didn't change anything for quiet sometime, it actually become important
>
> ^ Typo
>
> > after CSC code rework with commit ea067aee45a8 ("drm/sun4i: de2/de3:
> > Remove redundant CSC matrices").
> >
> > Without this fix, colours are completely off for supported YVU formats
> > on SoCs with DE2 (A64, H3, R40, etc.).
> >
> > Fix the issue by enclosing macro arguments in parenthesis.
> >
> > Cc: sta...@vger.kernel.org # 5.12+
> > Fixes: 883029390550 ("drm/sun4i: Add DE2 CSC library")
> > Reported-by: Roman Stratiienko
> > Signed-off-by: Jernej Skrabec
>
> Otherwise,
>
> Reviewed-by: Chen-Yu Tsai
Fixed the typo and applied, thanks
Maxime
signature.asc
Description: PGP signature
Re: [Intel-gfx] [PATCH 7/8] drm/i915/gem: Correct the locking and pin pattern for dma-buf (v8)
Hi, Jason, A quick question below: On 7/23/21 7:21 PM, Jason Ekstrand wrote: From: Thomas Hellström If our exported dma-bufs are imported by another instance of our driver, that instance will typically have the imported dma-bufs locked during dma_buf_map_attachment(). But the exporter also locks the same reservation object in the map_dma_buf() callback, which leads to recursive locking. So taking the lock inside _pin_pages_unlocked() is incorrect. Additionally, the current pinning code path is contrary to the defined way that pinning should occur. Remove the explicit pin/unpin from the map/umap functions and move them to the attach/detach allowing correct locking to occur, and to match the static dma-buf drm_prime pattern. Add a live selftest to exercise both dynamic and non-dynamic exports. v2: - Extend the selftest with a fake dynamic importer. - Provide real pin and unpin callbacks to not abuse the interface. v3: (ruhl) - Remove the dynamic export support and move the pinning into the attach/detach path. v4: (ruhl) - Put pages does not need to assert on the dma-resv v5: (jason) - Lock around dma_buf_unmap_attachment() when emulating a dynamic importer in the subtests. - Use pin_pages_unlocked v6: (jason) - Use dma_buf_attach instead of dma_buf_attach_dynamic in the selftests Why did we drop the dynamic importer from the selftests? Shouldn't we try to ensure compatibility with dynamic importers? /Thomas
RE: [diagnostic TDR mode patches] unify our solution opinions/suggestions in one thread
[AMD Official Use Only] Daniel >From the link you share it looks you(or someone else) have quite a bunch >patches that changes DRM_SCHED or even amdgpu, by that case before they are >merged to kernel tree I'm wondering if any AMD develop reviewed them ? They looks to me somehow conflicting with what we changed in our repo It is really a chaos for AMDer if someone else out side of AMD changes our kernel driver (or/and scheduler) without reviewed by AMDer, just like we are requiring your review if we tend to change scheduler's logic here This one changes AMD's code: https://lore.kernel.org/dri-devel/20210625133327.2598825-2-boris.brezil...@collabora.com/ And I didn't see any reviewed-by from AMDers ... This one also touches AMD's code: https://lore.kernel.org/dri-devel/20200604081224.863494-12-daniel.vet...@ffwll.ch/ Which is conflicting with one patch we submitted (in our repo rightnow), and neither see AMDder gave a review-by on this one (let me know if I missed it) Thanks -- Monk Liu | Cloud-GPU Core team -- -Original Message- From: amd-gfx On Behalf Of Daniel Vetter Sent: Wednesday, September 1, 2021 4:18 PM To: Liu, Monk Cc: Koenig, Christian ; Grodzovsky, Andrey ; Chen, JingWen ; DRI Development ; amd-...@lists.freedesktop.org Subject: Re: [diagnostic TDR mode patches] unify our solution opinions/suggestions in one thread Hi Monk, On Wed, Sep 1, 2021 at 3:23 AM Liu, Monk wrote: > > [AMD Official Use Only] > > > Hi Daniel/Christian/Andrey > > > > It looks the voice from you three are spread over those email floods to me, > the feature we are working on (diagnostic TDR scheme) is pending there for > more than 6 month (we started it from feb 2021). For me your project exists since a few weeks at most, because that is when your team showed up on dri-devel. That you already spent 6 months on this within amd, on a code area that very much affects shared code, without kicking of any thread on dri-devel isn't great, but also not something we can fix, since time machines don't exist. So we have to make the best out of the situation and move ahead where we are. From my understanding you've done a bunch of changes to the scheduler code. As far as I can see there's been two related things your team has done: - remove some allocations from scheduler code, because that can lead to deadlocks. I've kicked up this topic quite a while ago here https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fdri-devel%2F20200604081224.863494-10-daniel.vetter%40ffwll.ch%2F&data=04%7C01%7Cmonk.liu%40amd.com%7Cd90ad990ac1a499c266208d96d21138d%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637660811106940372%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=pG5sG5pjVXEAMaahvfNS11VwbHkYWRuWrtHFXM9mEyo%3D&reserved=0 This is just one patch of the entire series. This is an area where we really need a consistent solution across all drm/sched drivers, not something that individual drivers just fix in their own way. - the other one is the timeout issue for the patches you cite here. Again there's been discussion on this on dri-devel with Boris from panfrost about how we can handle at least some of the races in tdr. That resulted in lots of discussions and documentation improvements. Those patches are merged now, link https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fdri-devel%2F20210625133327.2598825-2-boris.brezillon%40collabora.com%2F&data=04%7C01%7Cmonk.liu%40amd.com%7Cd90ad990ac1a499c266208d96d21138d%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637660811106940372%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=m6U6tJbX2x38xiwQXE1oV0sz2BxXZfPlcouyqIqPZNU%3D&reserved=0 There's been more than just this, also quite some doc patches from Boris that explain how it's all supposed to work and be race-free. Again your driver isn't the only one with interesting TDR races. Your team hasn't been active in any of these discussions, but now suddenly pops up out of nowhere and demands that your approach needs to land asap. That's really not how upstream works. The other thing where I'm struggling is that there's a lot of missing context for outsiders. The patches sometimes come with zero commit message, for tricky concurrency bugs. And there's no context with what you've done already on the amdgpu side (since that never showed up on dri-devel), which makes constructive discussions here really hard. Now fixing these bugs is obviously good, but the way this is supposed to work when touching shared infrastructure is: - Before you start merging anything kick off an RFC thread on dri-devel (or whatever the topic really is about) about the problem you have and how your trying to solve it. This can be just text if it's a big thing, but
RE: [diagnostic TDR mode patches] unify our solution opinions/suggestions in one thread
[AMD Official Use Only] >> For me your project exists since a few weeks at most, because that is when >> your team showed up on dri-devel. That you already spent 6 months on this >> within amd, on a code area that very much affects shared code, without >> kicking of any thread on dri-devel isn't great, but also not something we >> can fix, since time machines don't exist. This is partially true, because in the past months our change only resident in AMD driver, it is till now that we found we had to make changes in SCHED level >> Your team hasn't been active in any of these discussions, but now suddenly >> pops up out of nowhere and demands that your approach needs to land asap. >> That's really not how upstream works. if our changes on DRI level part cannot get merged soon that's fine, we can discuss more, but that's not suddenly pops up from nowhere, we already worked on it for months inside of AMD drivers. >> I think the best way forward is to go through the above process again and >> essentially restart. So submit a complete patch series with problem >> descriptions, solution you picked, why you picked that, all the amdgpu >> patches to get there and the core patches too. Since it sounds like a bunch >> of this has all landed already you probably need a patch 1 that goes back to >> 6 months ago so that we can see the overall direction, and review whether >> that's the right one or not. We are not objecting this approach, we didn't do that because previously all what we need to do is resident inside AMD driver ... because we try to avoid change DRI/DRM interface part ... For the patches you shows to us with links I'm sorry that due to some IT infrastructure reason me and my team didn't see it before (we kind of work in AMD repo ... the patches you shows didn't get merged in our repo yet...) One thing I also want to emphasis here: if any code need change inside AMD driver please always let us know and review. Thanks -- Monk Liu | Cloud-GPU Core team -- -Original Message- From: amd-gfx On Behalf Of Daniel Vetter Sent: Wednesday, September 1, 2021 4:18 PM To: Liu, Monk Cc: Koenig, Christian ; Grodzovsky, Andrey ; Chen, JingWen ; DRI Development ; amd-...@lists.freedesktop.org Subject: Re: [diagnostic TDR mode patches] unify our solution opinions/suggestions in one thread Hi Monk, On Wed, Sep 1, 2021 at 3:23 AM Liu, Monk wrote: > > [AMD Official Use Only] > > > Hi Daniel/Christian/Andrey > > > > It looks the voice from you three are spread over those email floods to me, > the feature we are working on (diagnostic TDR scheme) is pending there for > more than 6 month (we started it from feb 2021). For me your project exists since a few weeks at most, because that is when your team showed up on dri-devel. That you already spent 6 months on this within amd, on a code area that very much affects shared code, without kicking of any thread on dri-devel isn't great, but also not something we can fix, since time machines don't exist. So we have to make the best out of the situation and move ahead where we are. From my understanding you've done a bunch of changes to the scheduler code. As far as I can see there's been two related things your team has done: - remove some allocations from scheduler code, because that can lead to deadlocks. I've kicked up this topic quite a while ago here https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fdri-devel%2F20200604081224.863494-10-daniel.vetter%40ffwll.ch%2F&data=04%7C01%7Cmonk.liu%40amd.com%7Cd90ad990ac1a499c266208d96d21138d%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637660811106940372%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=pG5sG5pjVXEAMaahvfNS11VwbHkYWRuWrtHFXM9mEyo%3D&reserved=0 This is just one patch of the entire series. This is an area where we really need a consistent solution across all drm/sched drivers, not something that individual drivers just fix in their own way. - the other one is the timeout issue for the patches you cite here. Again there's been discussion on this on dri-devel with Boris from panfrost about how we can handle at least some of the races in tdr. That resulted in lots of discussions and documentation improvements. Those patches are merged now, link https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fdri-devel%2F20210625133327.2598825-2-boris.brezillon%40collabora.com%2F&data=04%7C01%7Cmonk.liu%40amd.com%7Cd90ad990ac1a499c266208d96d21138d%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637660811106940372%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=m6U6tJbX2x38xiwQXE1oV0sz2BxXZfPlcouyqIqPZNU%3D&reserved=0 There's been more than just this, also quite some doc patches from Boris that explain how it's all supposed to w
[PATCH v9 2/2] drm/tiny: add driver for newhaven,1.8-128160EF
This patch adds support for Newhaven's NHD-1.8-128160EF display, featuring
an Ilitek ILI9163 controller.
Signed-off-by: Daniel Mack
Acked-by: Daniel Vetter
Acked-by: Thomas Zimmermann
---
drivers/gpu/drm/tiny/Kconfig | 13 ++
drivers/gpu/drm/tiny/Makefile | 1 +
drivers/gpu/drm/tiny/ili9163.c | 224 +
3 files changed, 238 insertions(+)
create mode 100644 drivers/gpu/drm/tiny/ili9163.c
diff --git a/drivers/gpu/drm/tiny/Kconfig b/drivers/gpu/drm/tiny/Kconfig
index d46f95d9196d..ca2d9255548b 100644
--- a/drivers/gpu/drm/tiny/Kconfig
+++ b/drivers/gpu/drm/tiny/Kconfig
@@ -67,6 +67,19 @@ config TINYDRM_HX8357D
If M is selected the module will be called hx8357d.
+config TINYDRM_ILI9163
+ tristate "DRM support for ILI9163 display panels"
+ depends on DRM && SPI
+ select BACKLIGHT_CLASS_DEVICE
+ select DRM_KMS_CMA_HELPER
+ select DRM_KMS_HELPER
+ select DRM_MIPI_DBI
+ help
+ DRM driver for the following Ilitek ILI9163 panels:
+ * NHD-1.8-128160EF 128x160 TFT
+
+ If M is selected the module will be called ili9163.
+
config TINYDRM_ILI9225
tristate "DRM support for ILI9225 display panels"
depends on DRM && SPI
diff --git a/drivers/gpu/drm/tiny/Makefile b/drivers/gpu/drm/tiny/Makefile
index 9cc847e756da..c96c663c3499 100644
--- a/drivers/gpu/drm/tiny/Makefile
+++ b/drivers/gpu/drm/tiny/Makefile
@@ -5,6 +5,7 @@ obj-$(CONFIG_DRM_CIRRUS_QEMU) += cirrus.o
obj-$(CONFIG_DRM_GM12U320) += gm12u320.o
obj-$(CONFIG_DRM_SIMPLEDRM)+= simpledrm.o
obj-$(CONFIG_TINYDRM_HX8357D) += hx8357d.o
+obj-$(CONFIG_TINYDRM_ILI9163) += ili9163.o
obj-$(CONFIG_TINYDRM_ILI9225) += ili9225.o
obj-$(CONFIG_TINYDRM_ILI9341) += ili9341.o
obj-$(CONFIG_TINYDRM_ILI9486) += ili9486.o
diff --git a/drivers/gpu/drm/tiny/ili9163.c b/drivers/gpu/drm/tiny/ili9163.c
new file mode 100644
index ..b0953e1aa3ed
--- /dev/null
+++ b/drivers/gpu/drm/tiny/ili9163.c
@@ -0,0 +1,224 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define ILI9163_FRMCTR10xb1
+
+#define ILI9163_PWCTRL10xc0
+#define ILI9163_PWCTRL20xc1
+#define ILI9163_VMCTRL10xc5
+#define ILI9163_VMCTRL20xc7
+#define ILI9163_PWCTRLA0xcb
+#define ILI9163_PWCTRLB0xcf
+
+#define ILI9163_EN3GAM 0xf2
+
+#define ILI9163_MADCTL_BGR BIT(3)
+#define ILI9163_MADCTL_MV BIT(5)
+#define ILI9163_MADCTL_MX BIT(6)
+#define ILI9163_MADCTL_MY BIT(7)
+
+static void yx240qv29_enable(struct drm_simple_display_pipe *pipe,
+struct drm_crtc_state *crtc_state,
+struct drm_plane_state *plane_state)
+{
+ struct mipi_dbi_dev *dbidev = drm_to_mipi_dbi_dev(pipe->crtc.dev);
+ struct mipi_dbi *dbi = &dbidev->dbi;
+ u8 addr_mode;
+ int ret, idx;
+
+ if (!drm_dev_enter(pipe->crtc.dev, &idx))
+ return;
+
+ DRM_DEBUG_KMS("\n");
+
+ ret = mipi_dbi_poweron_conditional_reset(dbidev);
+ if (ret < 0)
+ goto out_exit;
+ if (ret == 1)
+ goto out_enable;
+
+ /* Gamma */
+ mipi_dbi_command(dbi, MIPI_DCS_SET_GAMMA_CURVE, 0x04);
+ mipi_dbi_command(dbi, ILI9163_EN3GAM, 0x00);
+
+ /* Frame Rate */
+ mipi_dbi_command(dbi, ILI9163_FRMCTR1, 0x0a, 0x14);
+
+ /* Power Control */
+ mipi_dbi_command(dbi, ILI9163_PWCTRL1, 0x0a, 0x00);
+ mipi_dbi_command(dbi, ILI9163_PWCTRL2, 0x02);
+
+ /* VCOM */
+ mipi_dbi_command(dbi, ILI9163_VMCTRL1, 0x2f, 0x3e);
+ mipi_dbi_command(dbi, ILI9163_VMCTRL2, 0x40);
+
+ /* Memory Access Control */
+ mipi_dbi_command(dbi, MIPI_DCS_SET_PIXEL_FORMAT,
MIPI_DCS_PIXEL_FMT_16BIT);
+
+ mipi_dbi_command(dbi, MIPI_DCS_EXIT_SLEEP_MODE);
+ msleep(100);
+
+ mipi_dbi_command(dbi, MIPI_DCS_SET_DISPLAY_ON);
+ msleep(100);
+
+out_enable:
+ switch (dbidev->rotation) {
+ default:
+ addr_mode = ILI9163_MADCTL_MX | ILI9163_MADCTL_MY;
+ break;
+ case 90:
+ addr_mode = ILI9163_MADCTL_MX | ILI9163_MADCTL_MV;
+ break;
+ case 180:
+ addr_mode = 0;
+ break;
+ case 270:
+ addr_mode = ILI9163_MADCTL_MY | ILI9163_MADCTL_MV;
+ break;
+ }
+ addr_mode |= ILI9163_MADCTL_BGR;
+ mipi_dbi_command(dbi, MIPI_DCS_SET_ADDRESS_MODE, addr_mode);
+ mipi_dbi_enable_flush(dbidev, crtc_state, plane_state);
+out_exit:
+ drm_dev_exit(idx);
+}
+
+static const struct drm_simple_display_pipe_funcs ili9163_pipe_funcs = {
+ .enable = yx240qv
[PATCH v9 1/2] dt-bindings: display: add bindings for newhaven, 1.8-128160EF
This adds documentation for a new ILI9163 based, SPI connected display.
Signed-off-by: Daniel Mack
Reviewed-by: Rob Herring
---
.../bindings/display/ilitek,ili9163.txt | 27 +++
1 file changed, 27 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/ilitek,ili9163.txt
diff --git a/Documentation/devicetree/bindings/display/ilitek,ili9163.txt
b/Documentation/devicetree/bindings/display/ilitek,ili9163.txt
new file mode 100644
index ..fee119991c14
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/ilitek,ili9163.txt
@@ -0,0 +1,27 @@
+Ilitek ILI9163 display panels
+
+This binding is for display panels using an Ilitek ILI9163 controller in SPI
+mode.
+
+Required properties:
+- compatible: "newhaven,1.8-128160EF", "ilitek,ili9163"
+- dc-gpios:D/C pin
+- reset-gpios: Reset pin
+
+The node for this driver must be a child node of a SPI controller, hence
+all mandatory properties described in ../spi/spi-bus.txt must be specified.
+
+Optional properties:
+- rotation:panel rotation in degrees counter clockwise (0,90,180,270)
+- backlight: phandle of the backlight device attached to the panel
+
+Example:
+ display@0{
+ compatible = "newhaven,1.8-128160EF", "ilitek,ili9163"
+ reg = <0>;
+ spi-max-frequency = <3200>;
+ dc-gpios = <&gpio0 9 GPIO_ACTIVE_HIGH>;
+ reset-gpios = <&gpio0 8 GPIO_ACTIVE_HIGH>;
+ rotation = <270>;
+ backlight = <&backlight>;
+ };
--
2.31.1
[PATCH v9 0/2] gpu: drm: add driver for ili9361 panel
This is v9 of the series. Changelog: v2 -> v3: * Turn Documentation into yaml format v3 -> v4: * Fix reference error in yaml file v4 -> v5: * More yaml file documentation fixes v5 -> v6: * More yaml file documentation fixes v6 -> v7: * Fix ordering of patches v7 -> v8: * More yaml file documentation fixes v8 -> v9: * Addressed some minor issues pointed out by Thomas Zimmermann * Rebased Daniel Mack (2): dt-bindings: display: add bindings for newhaven,1.8-128160EF drm/tiny: add driver for newhaven,1.8-128160EF .../bindings/display/ilitek,ili9163.txt | 27 +++ drivers/gpu/drm/tiny/Kconfig | 13 + drivers/gpu/drm/tiny/Makefile | 1 + drivers/gpu/drm/tiny/ili9163.c| 224 ++ 4 files changed, 265 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/ilitek,ili9163.txt create mode 100644 drivers/gpu/drm/tiny/ili9163.c -- 2.31.1
Re: [PATCH] drm/shmobile: Make use of the helper function devm_platform_ioremap_resource()
On 31/08/2021 14:57, Cai Huoqing wrote: > Use the devm_platform_ioremap_resource() helper instead of > calling platform_get_resource() and devm_ioremap_resource() > separately > > Signed-off-by: Cai Huoqing Reviewed-by: Kieran Bingham > --- > drivers/gpu/drm/shmobile/shmob_drm_drv.c | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/shmobile/shmob_drm_drv.c > b/drivers/gpu/drm/shmobile/shmob_drm_drv.c > index 7db01904d18d..80078a9fd7f6 100644 > --- a/drivers/gpu/drm/shmobile/shmob_drm_drv.c > +++ b/drivers/gpu/drm/shmobile/shmob_drm_drv.c > @@ -192,7 +192,6 @@ static int shmob_drm_probe(struct platform_device *pdev) > struct shmob_drm_platform_data *pdata = pdev->dev.platform_data; > struct shmob_drm_device *sdev; > struct drm_device *ddev; > - struct resource *res; > unsigned int i; > int ret; > > @@ -215,8 +214,7 @@ static int shmob_drm_probe(struct platform_device *pdev) > > platform_set_drvdata(pdev, sdev); > > - res = platform_get_resource(pdev, IORESOURCE_MEM, 0); > - sdev->mmio = devm_ioremap_resource(&pdev->dev, res); > + sdev->mmio = devm_platform_ioremap_resource(pdev, 0); > if (IS_ERR(sdev->mmio)) > return PTR_ERR(sdev->mmio); > >
Re: [PATCH] drm/arm/hdlcd: Make use of the helper function devm_platform_ioremap_resource()
On Tue, Aug 31, 2021 at 03:43:19PM +0800, Cai Huoqing wrote:
> Use the devm_platform_ioremap_resource() helper instead of
> calling platform_get_resource() and devm_ioremap_resource()
> separately
>
> Signed-off-by: Cai Huoqing
Acked-by: Liviu Dudau
Many thanks,
Liviu
> ---
> drivers/gpu/drm/arm/hdlcd_drv.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/arm/hdlcd_drv.c b/drivers/gpu/drm/arm/hdlcd_drv.c
> index 479c2422a2e0..72e63c8fad4e 100644
> --- a/drivers/gpu/drm/arm/hdlcd_drv.c
> +++ b/drivers/gpu/drm/arm/hdlcd_drv.c
> @@ -129,7 +129,6 @@ static int hdlcd_load(struct drm_device *drm, unsigned
> long flags)
> {
> struct hdlcd_drm_private *hdlcd = drm->dev_private;
> struct platform_device *pdev = to_platform_device(drm->dev);
> - struct resource *res;
> u32 version;
> int ret;
>
> @@ -144,8 +143,7 @@ static int hdlcd_load(struct drm_device *drm, unsigned
> long flags)
> atomic_set(&hdlcd->dma_end_count, 0);
> #endif
>
> - res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> - hdlcd->mmio = devm_ioremap_resource(drm->dev, res);
> + hdlcd->mmio = devm_platform_ioremap_resource(pdev, 0);
> if (IS_ERR(hdlcd->mmio)) {
> DRM_ERROR("failed to map control registers area\n");
> ret = PTR_ERR(hdlcd->mmio);
> --
> 2.25.1
>
--
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---
¯\_(ツ)_/¯
Re: [PATCH] drm: rcar-du: Make use of the helper function devm_platform_ioremap_resource()
On 31/08/2021 08:54, Cai Huoqing wrote:
> Use the devm_platform_ioremap_resource() helper instead of
> calling platform_get_resource() and devm_ioremap_resource()
> separately
>
> Signed-off-by: Cai Huoqing
Reviewed-by: Kieran Bingham
> ---
> drivers/gpu/drm/rcar-du/rcar_du_drv.c | 4 +---
> drivers/gpu/drm/rcar-du/rcar_lvds.c | 4 +---
> 2 files changed, 2 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> index 4ac26d08ebb4..ebec4b7269d1 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> @@ -570,7 +570,6 @@ static void rcar_du_shutdown(struct platform_device *pdev)
> static int rcar_du_probe(struct platform_device *pdev)
> {
> struct rcar_du_device *rcdu;
> - struct resource *mem;
> int ret;
>
> /* Allocate and initialize the R-Car device structure. */
> @@ -585,8 +584,7 @@ static int rcar_du_probe(struct platform_device *pdev)
> platform_set_drvdata(pdev, rcdu);
>
> /* I/O resources */
> - mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> - rcdu->mmio = devm_ioremap_resource(&pdev->dev, mem);
> + rcdu->mmio = devm_platform_ioremap_resource(pdev, 0);
> if (IS_ERR(rcdu->mmio))
> return PTR_ERR(rcdu->mmio);
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_lvds.c
> b/drivers/gpu/drm/rcar-du/rcar_lvds.c
> index d061b8de748f..a64d910b0500 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_lvds.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_lvds.c
> @@ -802,7 +802,6 @@ static int rcar_lvds_probe(struct platform_device *pdev)
> {
> const struct soc_device_attribute *attr;
> struct rcar_lvds *lvds;
> - struct resource *mem;
> int ret;
>
> lvds = devm_kzalloc(&pdev->dev, sizeof(*lvds), GFP_KERNEL);
> @@ -825,8 +824,7 @@ static int rcar_lvds_probe(struct platform_device *pdev)
> lvds->bridge.funcs = &rcar_lvds_bridge_ops;
> lvds->bridge.of_node = pdev->dev.of_node;
>
> - mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> - lvds->mmio = devm_ioremap_resource(&pdev->dev, mem);
> + lvds->mmio = devm_platform_ioremap_resource(pdev, 0);
> if (IS_ERR(lvds->mmio))
> return PTR_ERR(lvds->mmio);
>
>
Re: [RFC] Make use of non-dynamic dmabuf in RDMA
Am 01.09.21 um 13:20 schrieb Gal Pressman: On 24/08/2021 20:32, Jason Gunthorpe wrote: On Tue, Aug 24, 2021 at 10:27:23AM -0700, John Hubbard wrote: On 8/24/21 2:32 AM, Christian König wrote: Am 24.08.21 um 11:06 schrieb Gal Pressman: On 23/08/2021 13:43, Christian König wrote: Am 21.08.21 um 11:16 schrieb Gal Pressman: On 20/08/2021 17:32, Jason Gunthorpe wrote: On Fri, Aug 20, 2021 at 03:58:33PM +0300, Gal Pressman wrote: ... IIUC, we're talking about three different exporter "types": - Dynamic with move_notify (requires ODP) - Dynamic with revoke_notify - Static Which changes do we need to make the third one work? Basically none at all in the framework. You just need to properly use the dma_buf_pin() function when you start using a buffer (e.g. before you create an attachment) and the dma_buf_unpin() function after you are done with the DMA-buf. I replied to your previous mail, but I'll ask again. Doesn't the pin operation migrate the memory to host memory? Sorry missed your previous reply. And yes at least for the amdgpu driver we migrate the memory to host memory as soon as it is pinned and I would expect that other GPU drivers do something similar. Well...for many topologies, migrating to host memory will result in a dramatically slower p2p setup. For that reason, some GPU drivers may want to allow pinning of video memory in some situations. Ideally, you've got modern ODP devices and you don't even need to pin. But if not, and you still hope to do high performance p2p between a GPU and a non-ODP Infiniband device, then you would need to leave the pinned memory in vidmem. So I think we don't want to rule out that behavior, right? Or is the thinking more like, "you're lucky that this old non-ODP setup works at all, and we'll make it work by routing through host/cpu memory, but it will be slow"? I think it depends on the user, if the user creates memory which is permanently located on the GPU then it should be pinnable in this way without force migration. But if the memory is inherently migratable then it just cannot be pinned in the GPU at all as we can't indefinately block migration from happening eg if the CPU touches it later or something. So are we OK with exporters implementing dma_buf_pin() without migrating the memory? I think so, yes. If so, do we still want a move_notify callback for non-dynamic importers? A noop? Well we could make the move_notify callback optional, e.g. so that you get the new locking approach but still pin the buffers manually with dma_buf_pin(). Regards, Christian.
[PATCH] drm/v3d: Make use of the helper function devm_platform_ioremap_resource_byname()
Use the devm_platform_ioremap_resource_byname() helper instead of
calling platform_get_resource_byname() and devm_ioremap_resource()
separately
Signed-off-by: Cai Huoqing
---
drivers/gpu/drm/v3d/v3d_drv.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/v3d/v3d_drv.c b/drivers/gpu/drm/v3d/v3d_drv.c
index 9403c3b36aca..c1deab2cf38d 100644
--- a/drivers/gpu/drm/v3d/v3d_drv.c
+++ b/drivers/gpu/drm/v3d/v3d_drv.c
@@ -206,10 +206,7 @@ MODULE_DEVICE_TABLE(of, v3d_of_match);
static int
map_regs(struct v3d_dev *v3d, void __iomem **regs, const char *name)
{
- struct resource *res =
- platform_get_resource_byname(v3d_to_pdev(v3d), IORESOURCE_MEM,
name);
-
- *regs = devm_ioremap_resource(v3d->drm.dev, res);
+ *regs = devm_platform_ioremap_resource_byname(v3d_to_pdev(v3d), name);
return PTR_ERR_OR_ZERO(*regs);
}
--
2.25.1
Re: [PATCH] panfrost: Don't cleanup the job if it was successfully queued
On 31/08/2021 14:35, Boris Brezillon wrote:
> The labels are misleading. Even though they are all prefixed with 'fail_'
> the success case also takes that path, and we should definitely not
> cleanup the job if it's been queued. While at it, let's rename those
> labels so we don't do the same mistake again.
>
> Fixes: 53516280cc38 ("drm/panfrost: use scheduler dependency tracking")
> Signed-off-by: Boris Brezillon
Reviewed-by: Steven Price
And also unlike last time...
Tested-by: Steven Price
Thanks for the clean up - I should have actually tested the previous
patch, but from the diff (and the previous label names) it was obviously
correct™! But it of course blows up pretty quickly without this change.
Thanks,
Steve
> ---
> drivers/gpu/drm/panfrost/panfrost_drv.c | 19 ++-
> 1 file changed, 10 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c
> b/drivers/gpu/drm/panfrost/panfrost_drv.c
> index 16212b6b202e..077cbbfa506b 100644
> --- a/drivers/gpu/drm/panfrost/panfrost_drv.c
> +++ b/drivers/gpu/drm/panfrost/panfrost_drv.c
> @@ -253,7 +253,7 @@ static int panfrost_ioctl_submit(struct drm_device *dev,
> void *data,
> job = kzalloc(sizeof(*job), GFP_KERNEL);
> if (!job) {
> ret = -ENOMEM;
> - goto fail_out_sync;
> + goto out_put_syncout;
> }
>
> kref_init(&job->refcount);
> @@ -270,29 +270,30 @@ static int panfrost_ioctl_submit(struct drm_device
> *dev, void *data,
>&job->file_priv->sched_entity[slot],
>NULL);
> if (ret)
> - goto fail_job_put;
> + goto out_put_job;
>
> ret = panfrost_copy_in_sync(dev, file, args, job);
> if (ret)
> - goto fail_job;
> + goto out_cleanup_job;
>
> ret = panfrost_lookup_bos(dev, file, args, job);
> if (ret)
> - goto fail_job;
> + goto out_cleanup_job;
>
> ret = panfrost_job_push(job);
> if (ret)
> - goto fail_job;
> + goto out_cleanup_job;
>
> /* Update the return sync object for the job */
> if (sync_out)
> drm_syncobj_replace_fence(sync_out, job->render_done_fence);
>
> -fail_job:
> - drm_sched_job_cleanup(&job->base);
> -fail_job_put:
> +out_cleanup_job:
> + if (ret)
> + drm_sched_job_cleanup(&job->base);
> +out_put_job:
> panfrost_job_put(job);
> -fail_out_sync:
> +out_put_syncout:
> if (sync_out)
> drm_syncobj_put(sync_out);
>
>
Harden the dma-fence documentation a bit more
Hi guys, while it is in most cases technically possible to not have a reference to the dma_fence when adding a callback it is usually a good idea to make sure to always have a reference anyway. Otherwise we can indeed see cases where this doesn't really work as intended like for example in the now fixed EPOLL code. Regards, Christian.
[PATCH 1/2] dma-buf: clarify dma_fence_ops->wait documentation
This callback is pretty much deprecated and should not be used by new
implementations.
Clarify that in the documentation as well.
Signed-off-by: Christian König
---
include/linux/dma-fence.h | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/include/linux/dma-fence.h b/include/linux/dma-fence.h
index 6ffb4b2c6371..a44e42b86c2a 100644
--- a/include/linux/dma-fence.h
+++ b/include/linux/dma-fence.h
@@ -214,19 +214,15 @@ struct dma_fence_ops {
* Custom wait implementation, defaults to dma_fence_default_wait() if
* not set.
*
-* The dma_fence_default_wait implementation should work for any fence,
as long
-* as @enable_signaling works correctly. This hook allows drivers to
-* have an optimized version for the case where a process context is
-* already available, e.g. if @enable_signaling for the general case
-* needs to set up a worker thread.
+* Deprecated and should not be used by new implementations. Only used
+* by existing implementations which need special handling for their
+* hardware reset procedure.
*
* Must return -ERESTARTSYS if the wait is intr = true and the wait was
* interrupted, and remaining jiffies if fence has signaled, or 0 if
wait
* timed out. Can also return other error values on custom
implementations,
* which should be treated as if the fence is signaled. For example a
hardware
* lockup could be reported like that.
-*
-* This callback is optional.
*/
signed long (*wait)(struct dma_fence *fence,
bool intr, signed long timeout);
--
2.25.1
[PATCH 2/2] dma-buf: clarify dma_fence_add_callback documentation
That the caller doesn't need to keep a reference is rather risky and not defensive at all. Especially dma_buf_poll got that horrible wrong, so better remove that sentence and also clarify that the callback might be called in atomic or interrupt context. Signed-off-by: Christian König --- drivers/dma-buf/dma-fence.c | 13 + 1 file changed, 5 insertions(+), 8 deletions(-) diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c index ce0f5eff575d..1e82ecd443fa 100644 --- a/drivers/dma-buf/dma-fence.c +++ b/drivers/dma-buf/dma-fence.c @@ -616,20 +616,17 @@ EXPORT_SYMBOL(dma_fence_enable_sw_signaling); * @cb: the callback to register * @func: the function to call * + * Add a software callback to the fence. The caller should keep a reference to + * the fence. + * * @cb will be initialized by dma_fence_add_callback(), no initialization * by the caller is required. Any number of callbacks can be registered * to a fence, but a callback can only be registered to one fence at a time. * - * Note that the callback can be called from an atomic context. If - * fence is already signaled, this function will return -ENOENT (and + * If fence is already signaled, this function will return -ENOENT (and * *not* call the callback). * - * Add a software callback to the fence. Same restrictions apply to - * refcount as it does to dma_fence_wait(), however the caller doesn't need to - * keep a refcount to fence afterward dma_fence_add_callback() has returned: - * when software access is enabled, the creator of the fence is required to keep - * the fence alive until after it signals with dma_fence_signal(). The callback - * itself can be called from irq context. + * Note that the callback can be called from an atomic context or irq context. * * Returns 0 in case of success, -ENOENT if the fence is already signaled * and -EINVAL in case of error. -- 2.25.1
Re: [Intel-gfx] [PATCH v3 1/2] drm/i915/opregion: add support for mailbox #5 EDID
Hi,
On Tue, Aug 31, 2021 at 11:30 AM Jani Nikula wrote:
>
> On Tue, 17 Aug 2021, Anisse Astier wrote:
> > The ACPI OpRegion Mailbox #5 ASLE extension may contain an EDID to be
> > used for the embedded display. Add support for using it via by adding
> > the EDID to the list of available modes on the connector, and use it for
> > eDP when available.
> >
> > If a panel's EDID is broken, there may be an override EDID set in the
> > ACPI OpRegion mailbox #5. Use it if available.
> >
> > Fixes the GPD Win Max laptop display, which seems to only use this
> > mechanism to provide a proper EDID for its eDP screen. It would have
> > been better to provide the EDID through the ACPI _DDC method instead, to
> > have a more generic solution, but it seems the designers of this system
> > did not consider it, and shipped the firmware without it.
>
> The question is whether the opregion EDID should be used for override or
> fallback. The patch at hand is kind of neither, it just unconditionally
> adds the modes from the opregion EDID to the connector. For your
> display, they apparently end up also being the only mode(s), with one of
> them being used as the fixed mode. (Otherwise the orientation quirk
> wouldn't work.)
Yes, I agree it should be a fallback, at least for this hardware.
>
> What does drm_get_edid() return for you? Maybe we should do something
> like this instead:
>
> mutex_lock(&dev->mode_config.mutex);
> edid = drm_get_edid(connector, &intel_dp->aux.ddc);
> + if (!edid)
> + edid = intel_opregion_get_edid(intel_connector);
> if (edid) {
> if (drm_add_edid_modes(connector, edid)) {
> drm_connector_update_edid_property(connector, edid);
Yes, I just tried this, it works well since drm_get_edid() does not
return an EDID.
>
> This way we'll actually use all the other bits in the EDID, not just the
> modes. And if it needs to become override rather than fallback, the
> solution is:
>
> mutex_lock(&dev->mode_config.mutex);
> - edid = drm_get_edid(connector, &intel_dp->aux.ddc);
> + edid = intel_opregion_get_edid(intel_connector);
> + if (!edid)
> + edid = drm_get_edid(connector, &intel_dp->aux.ddc);
> if (edid) {
> if (drm_add_edid_modes(connector, edid)) {
> drm_connector_update_edid_property(connector, edid);
>
> In any case, I think it's just plain wrong to use both the display and
> opregion EDIDs at the same time. It's probably all around safer to start
> with fallback.
It will be in the next iteration.
>
> Please find some further comments inline.
>
> > Based on original patch series by: Jani Nikula
> > https://patchwork.kernel.org/project/intel-gfx/patch/20200828061941.17051-1-jani.nik...@intel.com/
> >
> > Changes since Jani Nikula's series:
> > - EDID is copied and validated with drm_edid_is_valid
> > - Mode is now added via drm_add_edid_modes instead of using override
> >mechanism
> > - squashed the two patches
> >
> > Cc: Jani Nikula
> > Cc: Uma Shankar
> > Cc: Ville Syrjälä
> > Signed-off-by: Anisse Astier
> > ---
> > drivers/gpu/drm/i915/display/intel_dp.c | 3 +
> > drivers/gpu/drm/i915/display/intel_opregion.c | 69 ++-
> > drivers/gpu/drm/i915/display/intel_opregion.h | 8 +++
> > 3 files changed, 79 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > b/drivers/gpu/drm/i915/display/intel_dp.c
> > index 75d4ebc66941..f9254c0df1a2 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > @@ -5183,6 +5183,9 @@ static bool intel_edp_init_connector(struct intel_dp
> > *intel_dp,
> > goto out_vdd_off;
> > }
> >
> > + /* Set up override EDID, if any, from ACPI OpRegion */
> > + intel_opregion_edid_probe(intel_connector);
> > +
> > mutex_lock(&dev->mode_config.mutex);
> > edid = drm_get_edid(connector, &intel_dp->aux.ddc);
> > if (edid) {
> > diff --git a/drivers/gpu/drm/i915/display/intel_opregion.c
> > b/drivers/gpu/drm/i915/display/intel_opregion.c
> > index 3855fba70980..b1b87ed758ba 100644
> > --- a/drivers/gpu/drm/i915/display/intel_opregion.c
> > +++ b/drivers/gpu/drm/i915/display/intel_opregion.c
> > @@ -196,6 +196,8 @@ struct opregion_asle_ext {
> > #define ASLE_IUER_WINDOWS_BTN(1 << 1)
> > #define ASLE_IUER_POWER_BTN (1 << 0)
> >
> > +#define ASLE_PHED_EDID_VALID_MASK0x3
> > +
> > /* Software System Control Interrupt (SWSCI) */
> > #define SWSCI_SCIC_INDICATOR (1 << 0)
> > #define SWSCI_SCIC_MAIN_FUNCTION_SHIFT 1
> > @@ -909,8 +911,10 @@ int intel_opregion_setup(struct drm_i915_private
> > *dev_priv)
> > opregion->asle->ardy = ASLE_ARDY_NOT_READY;
> > }
> >
> > - if (mboxes & MBOX_ASLE_EXT)
> > + if (mboxes & MBOX_ASLE_EXT) {
> > drm_dbg(&dev_priv->drm
Re: [PATCH v6, 15/15] media: mtk-vcodec: Use codec type to separate different hardware
Hi
On 01.09.21 10:32, Yunfei Dong wrote:
There are just one core thread, in order to separeate different
hardware, using codec type to separeate it in scp driver.
this code seems to relate to the vpu driver not the scp driver.
Is there a corresponding code added to the vpu driver that test the codec_type?
Signed-off-by: Yunfei Dong
---
.../media/platform/mtk-vcodec/vdec_ipi_msg.h | 12 ---
.../media/platform/mtk-vcodec/vdec_vpu_if.c | 34 ---
.../media/platform/mtk-vcodec/vdec_vpu_if.h | 4 +++
3 files changed, 41 insertions(+), 9 deletions(-)
diff --git a/drivers/media/platform/mtk-vcodec/vdec_ipi_msg.h
b/drivers/media/platform/mtk-vcodec/vdec_ipi_msg.h
index 9d8079c4f976..c488f0c40190 100644
--- a/drivers/media/platform/mtk-vcodec/vdec_ipi_msg.h
+++ b/drivers/media/platform/mtk-vcodec/vdec_ipi_msg.h
@@ -35,6 +35,8 @@ enum vdec_ipi_msgid {
* @msg_id: vdec_ipi_msgid
* @vpu_inst_addr : VPU decoder instance address. Used if ABI version < 2.
* @inst_id : instance ID. Used if the ABI version >= 2.
+ * @codec_type : Codec fourcc
+ * @reserved : reserved param
*/
struct vdec_ap_ipi_cmd {
uint32_t msg_id;
@@ -42,6 +44,8 @@ struct vdec_ap_ipi_cmd {
uint32_t vpu_inst_addr;
uint32_t inst_id;
};
+ uint32_t codec_type;
+ uint32_t reserved;
};
/**
@@ -59,12 +63,12 @@ struct vdec_vpu_ipi_ack {
/**
* struct vdec_ap_ipi_init - for AP_IPIMSG_DEC_INIT
* @msg_id: AP_IPIMSG_DEC_INIT
- * @reserved : Reserved field
+ * @codec_type : Codec fourcc
* @ap_inst_addr : AP video decoder instance address
*/
struct vdec_ap_ipi_init {
uint32_t msg_id;
- uint32_t reserved;
+ uint32_t codec_type;
uint64_t ap_inst_addr;
};
@@ -77,7 +81,7 @@ struct vdec_ap_ipi_init {
*H264 decoder [0]:buf_sz [1]:nal_start
*VP8 decoder [0]:width/height
*VP9 decoder [0]:profile, [1][2] width/height
- * @reserved : Reserved field
+ * @codec_type : Codec fourcc
*/
struct vdec_ap_ipi_dec_start {
uint32_t msg_id;
@@ -86,7 +90,7 @@ struct vdec_ap_ipi_dec_start {
uint32_t inst_id;
};
uint32_t data[3];
- uint32_t reserved;
+ uint32_t codec_type;
};
/**
diff --git a/drivers/media/platform/mtk-vcodec/vdec_vpu_if.c
b/drivers/media/platform/mtk-vcodec/vdec_vpu_if.c
index bfd8e87dceff..c84fac52fe26 100644
--- a/drivers/media/platform/mtk-vcodec/vdec_vpu_if.c
+++ b/drivers/media/platform/mtk-vcodec/vdec_vpu_if.c
@@ -100,18 +100,29 @@ static void vpu_dec_ipi_handler(void *data, unsigned int
len, void *priv)
static int vcodec_vpu_send_msg(struct vdec_vpu_inst *vpu, void *msg, int len)
{
- int err;
+ int err, id, msgid;
- mtk_vcodec_debug(vpu, "id=%X", *(uint32_t *)msg);
+ msgid = *(uint32_t *)msg;
+ mtk_vcodec_debug(vpu, "id=%X", msgid);
vpu->failure = 0;
vpu->signaled = 0;
- err = mtk_vcodec_fw_ipi_send(vpu->ctx->dev->fw_handler, vpu->id, msg,
+ if (vpu->ctx->dev->vdec_pdata->hw_arch == MTK_VDEC_LAT_SINGLE_CORE) {
+ if (msgid == AP_IPIMSG_DEC_CORE ||
+ msgid == AP_IPIMSG_DEC_CORE_END)
+ id = vpu->core_id;
+ else
+ id = vpu->id;
+ } else {
+ id = vpu->id;
+ }
+
+ err = mtk_vcodec_fw_ipi_send(vpu->ctx->dev->fw_handler, id, msg,
len, 2000);
so
if (err) {
mtk_vcodec_err(vpu, "send fail vpu_id=%d msg_id=%X status=%d",
- vpu->id, *(uint32_t *)msg, err);
+ id, msgid, err);
return err;
}
@@ -131,6 +142,7 @@ static int vcodec_send_ap_ipi(struct vdec_vpu_inst *vpu, unsigned int msg_id)
msg.vpu_inst_addr = vpu->inst_addr;
else
msg.inst_id = vpu->inst_id;
+ msg.codec_type = vpu->codec_type;
err = vcodec_vpu_send_msg(vpu, &msg, sizeof(msg));
mtk_vcodec_debug(vpu, "- id=%X ret=%d", msg_id, err);
@@ -149,14 +161,25 @@ int vpu_dec_init(struct vdec_vpu_inst *vpu)
err = mtk_vcodec_fw_ipi_register(vpu->ctx->dev->fw_handler, vpu->id,
vpu->handler, "vdec", NULL);
- if (err != 0) {
+ if (err) {
could be nice to send a patch with other such fixes,
anyway it is better to send unrelated fixes in a separate patch
mtk_vcodec_err(vpu, "vpu_ipi_register fail status=%d", err);
return err;
}
+ if (vpu->ctx->dev->vdec_pdata->hw_arch == MTK_VDEC_LAT_SINGLE_CORE) {
+ err = mtk_vcodec_fw_ipi_register(vpu->ctx->dev->fw_handler,
+vpu->core_id, vpu->handler,
+"vdec", NULL);
+ if (err) {
+ mtk_vcodec_err(vp
[Bug 211277] sometimes crash at s2ram-wake (Ryzen 3500U): amdgpu, drm, commit_tail, amdgpu_dm_atomic_commit_tail
https://bugzilla.kernel.org/show_bug.cgi?id=211277 --- Comment #41 from kolAflash (kolafl...@kolahilft.de) --- I can confirm Jeromes result. Bug is gone with pci=noats. (Debian-11 kernel 5.10.0-8-amd64) I ran 50 suspend/standby rounds. Also I used the notebook for 2 days and suspended it multiple times without issues. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
Re: [PATCH v2 1/5] dt-bindings: reserved-memory: Document memory region specifier
On Fri, Jul 02, 2021 at 05:16:25PM +0300, Dmitry Osipenko wrote:
> 01.07.2021 21:14, Thierry Reding пишет:
> > On Tue, Jun 08, 2021 at 06:51:40PM +0200, Thierry Reding wrote:
> >> On Fri, May 28, 2021 at 06:54:55PM +0200, Thierry Reding wrote:
> >>> On Thu, May 20, 2021 at 05:03:06PM -0500, Rob Herring wrote:
> On Fri, Apr 23, 2021 at 06:32:30PM +0200, Thierry Reding wrote:
> > From: Thierry Reding
> >
> > Reserved memory region phandle references can be accompanied by a
> > specifier that provides additional information about how that specific
> > reference should be treated.
> >
> > One use-case is to mark a memory region as needing an identity mapping
> > in the system's IOMMU for the device that references the region. This is
> > needed for example when the bootloader has set up hardware (such as a
> > display controller) to actively access a memory region (e.g. a boot
> > splash screen framebuffer) during boot. The operating system can use the
> > identity mapping flag from the specifier to make sure an IOMMU identity
> > mapping is set up for the framebuffer before IOMMU translations are
> > enabled for the display controller.
> >
> > Signed-off-by: Thierry Reding
> > ---
> > .../reserved-memory/reserved-memory.txt | 21 +++
> > include/dt-bindings/reserved-memory.h | 8 +++
> > 2 files changed, 29 insertions(+)
> > create mode 100644 include/dt-bindings/reserved-memory.h
>
> Sorry for being slow on this. I have 2 concerns.
>
> First, this creates an ABI issue. A DT with cells in 'memory-region'
> will not be understood by an existing OS. I'm less concerned about this
> if we address that with a stable fix. (Though I'm pretty sure we've
> naively added #?-cells in the past ignoring this issue.)
> >>>
> >>> A while ago I had proposed adding memory-region*s* as an alternative
> >>> name for memory-region to make the naming more consistent with other
> >>> types of properties (think clocks, resets, gpios, ...). If we added
> >>> that, we could easily differentiate between the "legacy" cases where
> >>> no #memory-region-cells was allowed and the new cases where it was.
> >>>
> Second, it could be the bootloader setting up the reserved region. If a
> node already has 'memory-region', then adding more regions is more
> complicated compared to adding new properties. And defining what each
> memory-region entry is or how many in schemas is impossible.
> >>>
> >>> It's true that updating the property gets a bit complicated, but it's
> >>> not exactly rocket science. We really just need to splice the array. I
> >>> have a working implemention for this in U-Boot.
> >>>
> >>> For what it's worth, we could run into the same issue with any new
> >>> property that we add. Even if we renamed this to iommu-memory-region,
> >>> it's still possible that a bootloader may have to update this property
> >>> if it already exists (it could be hard-coded in DT, or it could have
> >>> been added by some earlier bootloader or firmware).
> >>>
> Both could be addressed with a new property. Perhaps something like
> 'iommu-memory-region = <&phandle>;'. I think the 'iommu' prefix is
> appropriate given this is entirely because of the IOMMU being in the
> mix. I might feel differently if we had other uses for cells, but I
> don't really see it in this case.
> >>>
> >>> I'm afraid that down the road we'll end up with other cases and then we
> >>> might proliferate a number of *-memory-region properties with varying
> >>> prefixes.
> >>>
> >>> I am aware of one other case where we might need something like this: on
> >>> some Tegra SoCs we have audio processors that will access memory buffers
> >>> using a DMA engine. These processors are booted from early firmware
> >>> using firmware from system memory. In order to avoid trashing the
> >>> firmware, we need to reserve memory. We can do this using reserved
> >>> memory nodes. However, the audio DMA engine also uses the SMMU, so we
> >>> need to make sure that the firmware memory is marked as reserved within
> >>> the SMMU. This is similar to the identity mapping case, but not exactly
> >>> the same. Instead of creating a 1:1 mapping, we just want that IOVA
> >>> region to be reserved (i.e. IOMMU_RESV_RESERVED instead of
> >>> IOMMU_RESV_DIRECT{,_RELAXABLE}).
> >>>
> >>> That would also fall into the IOMMU domain, but we can't reuse the
> >>> iommu-memory-region property for that because then we don't have enough
> >>> information to decide which type of reservation we need.
> >>>
> >>> We could obviously make iommu-memory-region take a specifier, but we
> >>> could just as well use memory-regions in that case since we have
> >>> something more generic anyway.
> >>>
> >>> With the #memory-region-cells proposal, we can easily extend the cell in
> >>> the specifier with
Re: [RFC PATCH 0/4] Allow to use DRM fbdev emulation layer with CONFIG_FB disabled
Hi Daniel, > > I think for a substantial improvement here in robustness what you really > want is > - kmscon in userspace > - disable FB layer > - ideally also disable console/vt layer in the kernel > - have a minimal emergency/boot-up log thing in drm, patches for that > floated around a few times I assume you refer to this work by David Herrmann: "[RFC] drm: add kernel-log renderer" https://lists.freedesktop.org/archives/dri-devel/2014-March/055136.html Very interesting. Does anyone knows why this never hit mainline? Sam - who is looking forward to winter with more time for hacking again
Re: [PATCH v9 0/2] gpu: drm: add driver for ili9361 panel
Hi Daniel, On Wed, Sep 01, 2021 at 12:30:38PM +0200, Daniel Mack wrote: > This is v9 of the series. > > Changelog: > > v2 -> v3: > * Turn Documentation into yaml format ... > Daniel Mack (2): > dt-bindings: display: add bindings for newhaven,1.8-128160EF > drm/tiny: add driver for newhaven,1.8-128160EF > > .../bindings/display/ilitek,ili9163.txt | 27 +++ Despite the changelog the patch contains a .txt file. Did you push the right patchset? Sam
Re: [PATCH] dma-buf: cleanup kerneldoc of removed component
Hi Christian,
On Wed, 1 Sept 2021 at 13:30, Christian König
wrote:
>
> The seqno-fence was removed, cleanup the kerneldoc include as well.
>
> Signed-off-by: Christian König
> Fixes: 992c238188a8 ("dma-buf: nuke seqno-fence")
Thanks for fixing; LGTM, please feel free to add my
Acked-by: Sumit Semwal
Or I could push it as well, if you'd like.
> ---
> Documentation/driver-api/dma-buf.rst | 6 --
> 1 file changed, 6 deletions(-)
>
> diff --git a/Documentation/driver-api/dma-buf.rst
> b/Documentation/driver-api/dma-buf.rst
> index f5ac4c90b237..2cd7db82d9fe 100644
> --- a/Documentation/driver-api/dma-buf.rst
> +++ b/Documentation/driver-api/dma-buf.rst
> @@ -176,12 +176,6 @@ DMA Fences Functions Reference
> .. kernel-doc:: include/linux/dma-fence.h
> :internal:
>
> -Seqno Hardware Fences
> -~
> -
> -.. kernel-doc:: include/linux/seqno-fence.h
> - :internal:
> -
> DMA Fence Array
> ~~~
>
> --
> 2.25.1
>
Best,
Sumit.
Re: [PATCH v2 07/63] skbuff: Switch structure bounds to struct_group()
For the drivers/net/wireguard part, Reviewed-by: Jason A. Donenfeld
[PATCH]: drm/panfrost: Dual licence the Mali GPU headers in GPL-2 and MIT.
drm/panfrost: Dual licence the Mali GPU headers in GPL-2 and MIT. Signed-off-by: Ruslan Bukin diff --git a/drivers/gpu/drm/panfrost/panfrost_features.h b/drivers/gpu/drm/panfrost/panfrost_features.h index 5056777c7744..23c4973c377f 100644 --- a/drivers/gpu/drm/panfrost/panfrost_features.h +++ b/drivers/gpu/drm/panfrost/panfrost_features.h @@ -1,4 +1,4 @@ -/* SPDX-License-Identifier: GPL-2.0 */ +/* SPDX-License-Identifier: GPL-2.0 or MIT */ /* (C) COPYRIGHT 2014-2018 ARM Limited. All rights reserved. */ /* Copyright 2019 Linaro, Ltd., Rob Herring */ #ifndef __PANFROST_FEATURES_H__ diff --git a/drivers/gpu/drm/panfrost/panfrost_issues.h b/drivers/gpu/drm/panfrost/panfrost_issues.h index 8e59d765bf19..cc6f7943ada2 100644 --- a/drivers/gpu/drm/panfrost/panfrost_issues.h +++ b/drivers/gpu/drm/panfrost/panfrost_issues.h @@ -1,4 +1,4 @@ -/* SPDX-License-Identifier: GPL-2.0 */ +/* SPDX-License-Identifier: GPL-2.0 or MIT */ /* (C) COPYRIGHT 2014-2018 ARM Limited. All rights reserved. */ /* Copyright 2019 Linaro, Ltd., Rob Herring */ #ifndef __PANFROST_ISSUES_H__ diff --git a/drivers/gpu/drm/panfrost/panfrost_regs.h b/drivers/gpu/drm/panfrost/panfrost_regs.h index dc9df5457f1c..ebd52c4abddc 100644 --- a/drivers/gpu/drm/panfrost/panfrost_regs.h +++ b/drivers/gpu/drm/panfrost/panfrost_regs.h @@ -1,4 +1,4 @@ -/* SPDX-License-Identifier: GPL-2.0 */ +/* SPDX-License-Identifier: GPL-2.0 or MIT */ /* Copyright 2018 Marty E. Plummer */ /* Copyright 2019 Linaro, Ltd, Rob Herring */ /*
Re: [PATCH v6 0/3] support gce on mt8192 platform
On Mon, Aug 2, 2021 at 3:47 PM Yongqiang Niu wrote: > > Change since v5: > -rebase on linux 5.14-rc1 > > Yongqiang Niu (3): > dt-binding: gce: add gce header file for mt8192 > arm64: dts: mt8192: add gce node > mailbox: cmdq: add mt8192 support Looks like all the driver parts are in -next, but the dts patch is not. Can you resend that patch after the merge window? Thanks ChenYu
Re: [diagnostic TDR mode patches] unify our solution opinions/suggestions in one thread
On Wed, Sep 1, 2021 at 6:19 AM Liu, Monk wrote: > > [AMD Official Use Only] > > Daniel > > From the link you share it looks you(or someone else) have quite a bunch > patches that changes DRM_SCHED or even amdgpu, by that case before they are > merged to kernel tree I'm wondering if any AMD develop reviewed them ? > > They looks to me somehow conflicting with what we changed in our repo > > It is really a chaos for AMDer if someone else out side of AMD changes our > kernel driver (or/and scheduler) without reviewed by AMDer, just like we are > requiring your review if we tend to change scheduler's logic here > > This one changes AMD's code: > https://lore.kernel.org/dri-devel/20210625133327.2598825-2-boris.brezil...@collabora.com/ > And I didn't see any reviewed-by from AMDers ... > > This one also touches AMD's code: > https://lore.kernel.org/dri-devel/20200604081224.863494-12-daniel.vet...@ffwll.ch/ > Which is conflicting with one patch we submitted (in our repo rightnow), and > neither see AMDder gave a review-by on this one (let me know if I missed it) > Monk, this is not how upstream works. You need to participate. That's how communities work. There's a reason all these discussions happen on public mailing lists. The patch author can't be expected to know every person on every vendor team to CC with a patch. If you have concerns, you need to raise them when the patches are being discussed. Alex > Thanks > > -- > Monk Liu | Cloud-GPU Core team > -- > > -Original Message- > From: amd-gfx On Behalf Of Daniel > Vetter > Sent: Wednesday, September 1, 2021 4:18 PM > To: Liu, Monk > Cc: Koenig, Christian ; Grodzovsky, Andrey > ; Chen, JingWen ; DRI > Development ; amd-...@lists.freedesktop.org > Subject: Re: [diagnostic TDR mode patches] unify our solution > opinions/suggestions in one thread > > Hi Monk, > > On Wed, Sep 1, 2021 at 3:23 AM Liu, Monk wrote: > > > > [AMD Official Use Only] > > > > > > Hi Daniel/Christian/Andrey > > > > > > > > It looks the voice from you three are spread over those email floods to me, > > the feature we are working on (diagnostic TDR scheme) is pending there for > > more than 6 month (we started it from feb 2021). > > For me your project exists since a few weeks at most, because that is when > your team showed up on dri-devel. That you already spent 6 months on this > within amd, on a code area that very much affects shared code, without > kicking of any thread on dri-devel isn't great, but also not something we can > fix, since time machines don't exist. > > So we have to make the best out of the situation and move ahead where we are. > From my understanding you've done a bunch of changes to the scheduler code. > As far as I can see there's been two related things your team has done: > > - remove some allocations from scheduler code, because that can lead to > deadlocks. I've kicked up this topic quite a while ago here > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fdri-devel%2F20200604081224.863494-10-daniel.vetter%40ffwll.ch%2F&data=04%7C01%7Cmonk.liu%40amd.com%7Cd90ad990ac1a499c266208d96d21138d%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637660811106940372%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=pG5sG5pjVXEAMaahvfNS11VwbHkYWRuWrtHFXM9mEyo%3D&reserved=0 > > This is just one patch of the entire series. This is an area where we really > need a consistent solution across all drm/sched drivers, not something that > individual drivers just fix in their own way. > > - the other one is the timeout issue for the patches you cite here. > Again there's been discussion on this on dri-devel with Boris from panfrost > about how we can handle at least some of the races in tdr. > That resulted in lots of discussions and documentation improvements. > Those patches are merged now, link > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fdri-devel%2F20210625133327.2598825-2-boris.brezillon%40collabora.com%2F&data=04%7C01%7Cmonk.liu%40amd.com%7Cd90ad990ac1a499c266208d96d21138d%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637660811106940372%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=m6U6tJbX2x38xiwQXE1oV0sz2BxXZfPlcouyqIqPZNU%3D&reserved=0 > > There's been more than just this, also quite some doc patches from Boris that > explain how it's all supposed to work and be race-free. > Again your driver isn't the only one with interesting TDR races. > > Your team hasn't been active in any of these discussions, but now suddenly > pops up out of nowhere and demands that your approach needs to land asap. > That's really not how upstream works. > > The other thing where I'm struggling is that there's a lot of missing context > for outsiders. The patches sometimes come with ze
Re: [PATCH v1 03/14] mm: add iomem vma selection for memory migration
Am 2021-09-01 um 4:29 a.m. schrieb Christoph Hellwig: > On Mon, Aug 30, 2021 at 01:04:43PM -0400, Felix Kuehling wrote: driver code is not really involved in updating the CPU mappings. Maybe it's something we need to do in the migration helpers. >>> It looks like I'm totally misunderstanding what you are adding here >>> then. Why do we need any special treatment at all for memory that >>> has normal struct pages and is part of the direct kernel map? >> The pages are like normal memory for purposes of mapping them in CPU >> page tables and for coherent access from the CPU. > That's the user page tables. What about the kernel direct map? > If there is a normal kernel struct page backing there really should > be no need for the pgmap. I'm not sure. The physical address ranges are in the UEFI system address map as special-purpose memory. Does Linux create the struct pages and kernel direct map for that without a pgmap call? I didn't see that last time I went digging through that code. > >> From an application >> perspective, we want file-backed and anonymous mappings to be able to >> use DEVICE_PUBLIC pages with coherent CPU access. The goal is to >> optimize performance for GPU heavy workloads while minimizing the need >> to migrate data back-and-forth between system memory and device memory. > I don't really understand that part. file backed pages are always > allocated by the file system using the pagecache helpers, that is > using the page allocator. Anonymouns memory also always comes from > the page allocator. I'm coming at this from my experience with DEVICE_PRIVATE. Both anonymous and file-backed pages should be migrateable to DEVICE_PRIVATE memory by the migrate_vma_* helpers for more efficient access by our GPU. (*) It's part of the basic premise of HMM as I understand it. I would expect the same thing to work for DEVICE_PUBLIC memory. (*) I believe migrating file-backed pages to DEVICE_PRIVATE doesn't currently work, but that's something I'm hoping to fix at some point. > >> The pages are special in two ways: >> >> 1. The memory is managed not by the Linux buddy allocator, but by the >> GPU driver's TTM memory manager > Why? It's a system architectural decision based on the access latency to the memory and the expected use cases that we do not want the GPU driver and the Linux buddy allocator and VM subsystem competing for the same device memory. > >> 2. We want to migrate data in response to GPU page faults and >> application hints using the migrate_vma helpers > Why? Device memory has much higher bandwidth and much lower latency than regular system memory for the GPU to access. It's essential for enabling good GPU application performance. Page-based memory migration enables good performance with more intuitive programming models such as managed/unified memory in HIP or unified shared memory in OpenMP. We do this on our discrete GPUs with DEVICE_PRIVATE memory. I see DEVICE_PUBLIC as an improved version of DEVICE_PRIVATE that allows the CPU to map the device memory coherently to minimize the need for migrations when CPU and GPU access the same memory concurrently or alternatingly. But we're not going as far as putting that memory entirely under the management of the Linux memory manager and VM subsystem. Our (and HPE's) system architects decided that this memory is not suitable to be used like regular NUMA system memory by the Linux memory manager. Regards, Felix
Re: [Intel-gfx] [PATCH v7 10/17] drm/i915/pxp: interfaces for using protected objects
On Tue, Aug 31, 2021 at 03:01:51PM -0700, Daniele Ceraolo Spurio wrote:
>
>
> > > +}
> > > +
> > > +void intel_pxp_invalidate(struct intel_pxp *pxp)
> > > +{
> > > + struct drm_i915_private *i915 = pxp_to_gt(pxp)->i915;
> > > + struct i915_gem_context *ctx, *cn;
> > > +
> > > + /* ban all contexts marked as protected */
> > > + spin_lock_irq(&i915->gem.contexts.lock);
> > > + list_for_each_entry_safe(ctx, cn, &i915->gem.contexts.list, link) {
> > > + struct i915_gem_engines_iter it;
> > > + struct intel_context *ce;
> > > +
> > > + if (!kref_get_unless_zero(&ctx->ref))
> > > + continue;
> > > +
> > > + if (likely(!i915_gem_context_uses_protected_content(ctx))) {
> > > + i915_gem_context_put(ctx);
> > > + continue;
> > > + }
> > > +
> > > + spin_unlock_irq(&i915->gem.contexts.lock);
> > > +
> > > + /*
> > > + * By the time we get here, the HW keys are already long gone,
> > > + * so any batch using them that's already on the engines is very
> > > + * likely a lost cause (and it has probably already hung the
> > > + * engine). Therefore, we skip attempting to pull the running
> > > + * context out of the HW and we prioritize bringing the session
> > > + * back as soon as possible.
> > > + * For each context we ban we increase the ctx->guilty_count, so
> > > + * that userspace can see that all the intel contexts have been
> > > + * banned (on a non-recoverable gem context, guilty intel
> > > + * contexts are banned immediately on reset, so we report the
> > > + * same way here).
> > hmm... but guilty specifically means that they indeed caused the GPU hang.
> > does the umd really need this indication? any other way of doing this?
>
> The request from Daniel was to re-use the existing interface and AFAICT the
> guilty_count is the only one we have for this. The alternative would be to
> add a new flag (like I had in the previous version of this patch), but that
> was shot down already. Lionel can probably comment more on the UMD
> requirements for this since it was a request from the mesa side.
Daniel and Lionel, could you please comment here?
Are we really expanding the guilty from the hang meaning?
Is it really better than creating the new flag?
>
>
> > > + */
> > > + for_each_gem_engine(ce, i915_gem_context_lock_engines(ctx), it)
> > > + if (!intel_context_ban(ce, NULL))
> > > + atomic_inc(&ctx->guilty_count);
> > > + i915_gem_context_unlock_engines(ctx);
> > > +
> > > + /*
> > > + * The context has been killed, no need to keep the wakeref.
> > > + * This is safe from races because the only other place this
> > > + * is touched is context_close and we're holding a ctx ref
> > > + */
> > The comments make sense, but maybe we should avoid the optimization here,
> > but maybe we should avoid the optimization and just keep it locked?
>
> The lock released above the comment and the one taken after the pm_put are
> different ones, so even if we don't release the wakeref here we still need
> to do the same locking steps. Or did you mean something different with
> keeping it locked?
oh, please ignore me here. I thought it was the same locking...
>
> Thanks,
> Daniele
>
> >
> > > + if (ctx->pxp_wakeref) {
> > > + intel_runtime_pm_put(&i915->runtime_pm,
> > > + ctx->pxp_wakeref);
> > > + ctx->pxp_wakeref = 0;
> > > + }
> > > +
> > > + spin_lock_irq(&i915->gem.contexts.lock);
> > > + list_safe_reset_next(ctx, cn, link);
> > > + i915_gem_context_put(ctx);
> > > + }
> > > + spin_unlock_irq(&i915->gem.contexts.lock);
> > > +}
> > > +
> > > diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.h
> > > b/drivers/gpu/drm/i915/pxp/intel_pxp.h
> > > index 8f1e86caa53f..f942bdd2af0c 100644
> > > --- a/drivers/gpu/drm/i915/pxp/intel_pxp.h
> > > +++ b/drivers/gpu/drm/i915/pxp/intel_pxp.h
> > > @@ -9,6 +9,8 @@
> > > #include "gt/intel_gt_types.h"
> > > #include "intel_pxp_types.h"
> > > +struct drm_i915_gem_object;
> > > +
> > > static inline struct intel_gt *pxp_to_gt(const struct intel_pxp *pxp)
> > > {
> > > return container_of(pxp, struct intel_gt, pxp);
> > > @@ -33,6 +35,10 @@ void intel_pxp_fini_hw(struct intel_pxp *pxp);
> > > void intel_pxp_mark_termination_in_progress(struct intel_pxp *pxp);
> > > int intel_pxp_wait_for_arb_start(struct intel_pxp *pxp);
> > > +
> > > +int intel_pxp_key_check(struct intel_pxp *pxp, struct
> > > drm_i915_gem_object *obj);
> > > +
> > > +void intel_pxp_invalidate(struct intel_pxp *pxp);
> > > #else
> > > static inline void intel_pxp_init(struct intel_pxp *pxp)
> > > {
> > > @@ -46,6 +52,12 @@ static inline int intel_pxp_wait_for_arb_start(s
Re: [PATCH v9 0/2] gpu: drm: add driver for ili9361 panel
Hi Sam, On 9/1/21 4:20 PM, Sam Ravnborg wrote: > Hi Daniel, > > On Wed, Sep 01, 2021 at 12:30:38PM +0200, Daniel Mack wrote: >> This is v9 of the series. >> >> Changelog: >> >> v2 -> v3: >> * Turn Documentation into yaml format > > ... > >> Daniel Mack (2): >> dt-bindings: display: add bindings for newhaven,1.8-128160EF >> drm/tiny: add driver for newhaven,1.8-128160EF >> >> .../bindings/display/ilitek,ili9163.txt | 27 +++ > > Despite the changelog the patch contains a .txt file. > Did you push the right patchset? Meh, you're right. Something went wrong in the rebase. Thanks for spotting this! Will send a v10 in a minute! Daniel
Re: [Intel-gfx] [PATCH v7 14/17] drm/i915/pxp: black pixels on pxp disabled
On Fri, Aug 27, 2021 at 06:27:35PM -0700, Daniele Ceraolo Spurio wrote:
> From: Anshuman Gupta
>
> When protected sufaces has flipped and pxp session is disabled,
> display black pixels by using plane color CTM correction.
>
> v2:
> - Display black pixels in async flip too.
>
> v3:
> - Removed the black pixels logic for async flip. [Ville]
> - Used plane state to force black pixels. [Ville]
>
> v4 (Daniele): update pxp_is_borked check.
>
> v5: rebase on top of v9 plane decryption moving the decrypt check
> (Juston)
>
> Cc: Ville Syrjälä
> Cc: Gaurav Kumar
> Cc: Shankar Uma
> Signed-off-by: Anshuman Gupta
> Signed-off-by: Daniele Ceraolo Spurio
> Signed-off-by: Juston Li
> Reviewed-by: Rodrigo Vivi #v4
The end result looks identical to me, so my rv-b remains valid.
> Reviewed-by: Uma Shankar
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 12 -
> .../drm/i915/display/intel_display_types.h| 3 ++
> .../drm/i915/display/skl_universal_plane.c| 36 ++-
> drivers/gpu/drm/i915/i915_reg.h | 46 +++
> 4 files changed, 94 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index f04d98fcea46..146c87440cc6 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -9157,6 +9157,11 @@ static bool bo_has_valid_encryption(struct
> drm_i915_gem_object *obj)
> return intel_pxp_key_check(&i915->gt.pxp, obj, false) == 0;
> }
>
> +static bool pxp_is_borked(struct drm_i915_gem_object *obj)
> +{
> + return i915_gem_object_is_protected(obj) &&
> !bo_has_valid_encryption(obj);
> +}
> +
> static int intel_atomic_check_planes(struct intel_atomic_state *state)
> {
> struct drm_i915_private *dev_priv = to_i915(state->base.dev);
> @@ -9218,10 +9223,13 @@ static int intel_atomic_check_planes(struct
> intel_atomic_state *state)
> new_plane_state = intel_atomic_get_new_plane_state(state,
> plane);
> old_plane_state = intel_atomic_get_old_plane_state(state,
> plane);
> fb = new_plane_state->hw.fb;
> - if (fb)
> + if (fb) {
> new_plane_state->decrypt =
> bo_has_valid_encryption(intel_fb_obj(fb));
> - else
> + new_plane_state->force_black =
> pxp_is_borked(intel_fb_obj(fb));
> + } else {
> new_plane_state->decrypt = old_plane_state->decrypt;
> + new_plane_state->force_black =
> old_plane_state->force_black;
> + }
> }
>
> return 0;
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> b/drivers/gpu/drm/i915/display/intel_display_types.h
> index 6d4ea1d5bf7b..05d2e6676387 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -632,6 +632,9 @@ struct intel_plane_state {
> /* Plane pxp decryption state */
> bool decrypt;
>
> + /* Plane state to display black pixels when pxp is borked */
> + bool force_black;
> +
> /* plane control register */
> u32 ctl;
>
> diff --git a/drivers/gpu/drm/i915/display/skl_universal_plane.c
> b/drivers/gpu/drm/i915/display/skl_universal_plane.c
> index 55e3f093b951..c4adcb3e12b3 100644
> --- a/drivers/gpu/drm/i915/display/skl_universal_plane.c
> +++ b/drivers/gpu/drm/i915/display/skl_universal_plane.c
> @@ -1002,6 +1002,33 @@ static u32 skl_surf_address(const struct
> intel_plane_state *plane_state,
> }
> }
>
> +static void intel_load_plane_csc_black(struct intel_plane *intel_plane)
> +{
> + struct drm_i915_private *dev_priv = to_i915(intel_plane->base.dev);
> + enum pipe pipe = intel_plane->pipe;
> + enum plane_id plane = intel_plane->id;
> + u16 postoff = 0;
> +
> + drm_dbg_kms(&dev_priv->drm, "plane color CTM to black %s:%d\n",
> + intel_plane->base.name, plane);
> + intel_de_write_fw(dev_priv, PLANE_CSC_COEFF(pipe, plane, 0), 0);
> + intel_de_write_fw(dev_priv, PLANE_CSC_COEFF(pipe, plane, 1), 0);
> +
> + intel_de_write_fw(dev_priv, PLANE_CSC_COEFF(pipe, plane, 2), 0);
> + intel_de_write_fw(dev_priv, PLANE_CSC_COEFF(pipe, plane, 3), 0);
> +
> + intel_de_write_fw(dev_priv, PLANE_CSC_COEFF(pipe, plane, 4), 0);
> + intel_de_write_fw(dev_priv, PLANE_CSC_COEFF(pipe, plane, 5), 0);
> +
> + intel_de_write_fw(dev_priv, PLANE_CSC_PREOFF(pipe, plane, 0), 0);
> + intel_de_write_fw(dev_priv, PLANE_CSC_PREOFF(pipe, plane, 1), 0);
> + intel_de_write_fw(dev_priv, PLANE_CSC_PREOFF(pipe, plane, 2), 0);
> +
> + intel_de_write_fw(dev_priv, PLANE_CSC_POSTOFF(pipe, plane, 0), postoff);
> + intel_de_write_fw(dev_priv, PLANE_CSC_POSTOFF(pipe, plane, 1), postoff);
> + intel_de_write_fw(dev_priv, PLANE_CSC_POSTOFF(pipe, plane, 2), postoff);
> +}
> +
> static
[PATCH v10 0/2] gpu: drm: add driver for ili9361 panel
This is v10 of the series. Changelog: v2 -> v3: * Turn Documentation into yaml format v3 -> v4: * Fix reference error in yaml file v4 -> v5: * More yaml file documentation fixes v5 -> v6: * More yaml file documentation fixes v6 -> v7: * Fix ordering of patches v7 -> v8: * More yaml file documentation fixes v8 -> v9: * Addressed some minor issues pointed out by Thomas Zimmermann * Rebased v9 -> v10: * Re-apply the yaml file in favour of the txt file Daniel Mack (2): dt-bindings: display: add bindings for newhaven,1.8-128160EF drm/tiny: add driver for newhaven,1.8-128160EF .../display/panel/ilitek,ili9163.yaml | 69 ++ drivers/gpu/drm/tiny/Kconfig | 13 + drivers/gpu/drm/tiny/Makefile | 1 + drivers/gpu/drm/tiny/ili9163.c| 224 ++ 4 files changed, 307 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/ilitek,ili9163.yaml create mode 100644 drivers/gpu/drm/tiny/ili9163.c -- 2.31.1
[PATCH v10 1/2] dt-bindings: display: add bindings for newhaven, 1.8-128160EF
This adds documentation for a new ILI9163 based, SPI connected display.
Signed-off-by: Daniel Mack
Reviewed-by: Rob Herring
---
.../display/panel/ilitek,ili9163.yaml | 69 +++
1 file changed, 69 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/ilitek,ili9163.yaml
diff --git
a/Documentation/devicetree/bindings/display/panel/ilitek,ili9163.yaml
b/Documentation/devicetree/bindings/display/panel/ilitek,ili9163.yaml
new file mode 100644
index ..7e7a8362b951
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/ilitek,ili9163.yaml
@@ -0,0 +1,69 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/ilitek,ili9163.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Ilitek ILI9163 display panels device tree bindings
+
+maintainers:
+ - Daniel Mack
+
+description:
+ This binding is for display panels using an Ilitek ILI9163 controller in SPI
+ mode.
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+items:
+ - enum:
+ - newhaven,1.8-128160EF
+ - const: ilitek,ili9163
+
+ spi-max-frequency:
+maximum: 3200
+
+ dc-gpios:
+maxItems: 1
+description: Display data/command selection (D/CX)
+
+ backlight: true
+ reg: true
+ reset-gpios: true
+ rotation: true
+
+required:
+ - compatible
+ - reg
+ - dc-gpios
+ - reset-gpios
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+
+backlight: backlight {
+compatible = "gpio-backlight";
+gpios = <&gpio 22 GPIO_ACTIVE_HIGH>;
+};
+spi {
+#address-cells = <1>;
+#size-cells = <0>;
+
+display@0 {
+compatible = "newhaven,1.8-128160EF", "ilitek,ili9163";
+reg = <0>;
+spi-max-frequency = <3200>;
+dc-gpios = <&gpio0 24 GPIO_ACTIVE_HIGH>;
+reset-gpios = <&gpio0 25 GPIO_ACTIVE_HIGH>;
+rotation = <180>;
+backlight = <&backlight>;
+};
+};
+
+...
--
2.31.1
[PATCH v10 2/2] drm/tiny: add driver for newhaven,1.8-128160EF
This patch adds support for Newhaven's NHD-1.8-128160EF display, featuring
an Ilitek ILI9163 controller.
Signed-off-by: Daniel Mack
Acked-by: Daniel Vetter
Acked-by: Thomas Zimmermann
---
drivers/gpu/drm/tiny/Kconfig | 13 ++
drivers/gpu/drm/tiny/Makefile | 1 +
drivers/gpu/drm/tiny/ili9163.c | 224 +
3 files changed, 238 insertions(+)
create mode 100644 drivers/gpu/drm/tiny/ili9163.c
diff --git a/drivers/gpu/drm/tiny/Kconfig b/drivers/gpu/drm/tiny/Kconfig
index d46f95d9196d..ca2d9255548b 100644
--- a/drivers/gpu/drm/tiny/Kconfig
+++ b/drivers/gpu/drm/tiny/Kconfig
@@ -67,6 +67,19 @@ config TINYDRM_HX8357D
If M is selected the module will be called hx8357d.
+config TINYDRM_ILI9163
+ tristate "DRM support for ILI9163 display panels"
+ depends on DRM && SPI
+ select BACKLIGHT_CLASS_DEVICE
+ select DRM_KMS_CMA_HELPER
+ select DRM_KMS_HELPER
+ select DRM_MIPI_DBI
+ help
+ DRM driver for the following Ilitek ILI9163 panels:
+ * NHD-1.8-128160EF 128x160 TFT
+
+ If M is selected the module will be called ili9163.
+
config TINYDRM_ILI9225
tristate "DRM support for ILI9225 display panels"
depends on DRM && SPI
diff --git a/drivers/gpu/drm/tiny/Makefile b/drivers/gpu/drm/tiny/Makefile
index 9cc847e756da..c96c663c3499 100644
--- a/drivers/gpu/drm/tiny/Makefile
+++ b/drivers/gpu/drm/tiny/Makefile
@@ -5,6 +5,7 @@ obj-$(CONFIG_DRM_CIRRUS_QEMU) += cirrus.o
obj-$(CONFIG_DRM_GM12U320) += gm12u320.o
obj-$(CONFIG_DRM_SIMPLEDRM)+= simpledrm.o
obj-$(CONFIG_TINYDRM_HX8357D) += hx8357d.o
+obj-$(CONFIG_TINYDRM_ILI9163) += ili9163.o
obj-$(CONFIG_TINYDRM_ILI9225) += ili9225.o
obj-$(CONFIG_TINYDRM_ILI9341) += ili9341.o
obj-$(CONFIG_TINYDRM_ILI9486) += ili9486.o
diff --git a/drivers/gpu/drm/tiny/ili9163.c b/drivers/gpu/drm/tiny/ili9163.c
new file mode 100644
index ..b0953e1aa3ed
--- /dev/null
+++ b/drivers/gpu/drm/tiny/ili9163.c
@@ -0,0 +1,224 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define ILI9163_FRMCTR10xb1
+
+#define ILI9163_PWCTRL10xc0
+#define ILI9163_PWCTRL20xc1
+#define ILI9163_VMCTRL10xc5
+#define ILI9163_VMCTRL20xc7
+#define ILI9163_PWCTRLA0xcb
+#define ILI9163_PWCTRLB0xcf
+
+#define ILI9163_EN3GAM 0xf2
+
+#define ILI9163_MADCTL_BGR BIT(3)
+#define ILI9163_MADCTL_MV BIT(5)
+#define ILI9163_MADCTL_MX BIT(6)
+#define ILI9163_MADCTL_MY BIT(7)
+
+static void yx240qv29_enable(struct drm_simple_display_pipe *pipe,
+struct drm_crtc_state *crtc_state,
+struct drm_plane_state *plane_state)
+{
+ struct mipi_dbi_dev *dbidev = drm_to_mipi_dbi_dev(pipe->crtc.dev);
+ struct mipi_dbi *dbi = &dbidev->dbi;
+ u8 addr_mode;
+ int ret, idx;
+
+ if (!drm_dev_enter(pipe->crtc.dev, &idx))
+ return;
+
+ DRM_DEBUG_KMS("\n");
+
+ ret = mipi_dbi_poweron_conditional_reset(dbidev);
+ if (ret < 0)
+ goto out_exit;
+ if (ret == 1)
+ goto out_enable;
+
+ /* Gamma */
+ mipi_dbi_command(dbi, MIPI_DCS_SET_GAMMA_CURVE, 0x04);
+ mipi_dbi_command(dbi, ILI9163_EN3GAM, 0x00);
+
+ /* Frame Rate */
+ mipi_dbi_command(dbi, ILI9163_FRMCTR1, 0x0a, 0x14);
+
+ /* Power Control */
+ mipi_dbi_command(dbi, ILI9163_PWCTRL1, 0x0a, 0x00);
+ mipi_dbi_command(dbi, ILI9163_PWCTRL2, 0x02);
+
+ /* VCOM */
+ mipi_dbi_command(dbi, ILI9163_VMCTRL1, 0x2f, 0x3e);
+ mipi_dbi_command(dbi, ILI9163_VMCTRL2, 0x40);
+
+ /* Memory Access Control */
+ mipi_dbi_command(dbi, MIPI_DCS_SET_PIXEL_FORMAT,
MIPI_DCS_PIXEL_FMT_16BIT);
+
+ mipi_dbi_command(dbi, MIPI_DCS_EXIT_SLEEP_MODE);
+ msleep(100);
+
+ mipi_dbi_command(dbi, MIPI_DCS_SET_DISPLAY_ON);
+ msleep(100);
+
+out_enable:
+ switch (dbidev->rotation) {
+ default:
+ addr_mode = ILI9163_MADCTL_MX | ILI9163_MADCTL_MY;
+ break;
+ case 90:
+ addr_mode = ILI9163_MADCTL_MX | ILI9163_MADCTL_MV;
+ break;
+ case 180:
+ addr_mode = 0;
+ break;
+ case 270:
+ addr_mode = ILI9163_MADCTL_MY | ILI9163_MADCTL_MV;
+ break;
+ }
+ addr_mode |= ILI9163_MADCTL_BGR;
+ mipi_dbi_command(dbi, MIPI_DCS_SET_ADDRESS_MODE, addr_mode);
+ mipi_dbi_enable_flush(dbidev, crtc_state, plane_state);
+out_exit:
+ drm_dev_exit(idx);
+}
+
+static const struct drm_simple_display_pipe_funcs ili9163_pipe_funcs = {
+ .enable = yx240qv
Re: [PATCH v7 13/17] drm/i915/pxp: Add plane decryption support
On Fri, Aug 27, 2021 at 06:27:34PM -0700, Daniele Ceraolo Spurio wrote:
> From: Anshuman Gupta
>
> Add support to enable/disable PLANE_SURF Decryption Request bit.
> It requires only to enable plane decryption support when following
> condition met.
> 1. PXP session is enabled.
> 2. Buffer object is protected.
>
> v2:
> - Used gen fb obj user_flags instead gem_object_metadata. [Krishna]
>
> v3:
> - intel_pxp_gem_object_status() API changes.
>
> v4: use intel_pxp_is_active (Daniele)
>
> v5: rebase and use the new protected object status checker (Daniele)
>
> v6: used plane state for plane_decryption to handle async flip
> as suggested by Ville.
>
> v7: check pxp session while plane decrypt state computation. [Ville]
> removed pointless code. [Ville]
>
> v8 (Daniele): update PXP check
>
> v9: move decrypt check after icl_check_nv12_planes() when overlays
> have fb set (Juston)
>
> v10 (Daniele): update PXP check again to match rework in earlier patches and
> don't consider protection valid if the object has not been used in an
> execbuf beforehand.
Reviewed-by: Rodrigo Vivi
>
> Cc: Bommu Krishnaiah
> Cc: Huang Sean Z
> Cc: Gaurav Kumar
> Cc: Ville Syrjälä
> Signed-off-by: Anshuman Gupta
> Signed-off-by: Daniele Ceraolo Spurio
> Signed-off-by: Juston Li
> Reviewed-by: Rodrigo Vivi #v8
> Reviewed-by: Uma Shankar #v9
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 26 +++
> .../drm/i915/display/intel_display_types.h| 3 +++
> .../drm/i915/display/skl_universal_plane.c| 15 ---
> .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 2 +-
> drivers/gpu/drm/i915/i915_reg.h | 1 +
> drivers/gpu/drm/i915/pxp/intel_pxp.c | 9 ---
> drivers/gpu/drm/i915/pxp/intel_pxp.h | 7 +++--
> 7 files changed, 54 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index fe5ad599c218..f04d98fcea46 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -70,6 +70,8 @@
> #include "gt/intel_rps.h"
> #include "gt/gen8_ppgtt.h"
>
> +#include "pxp/intel_pxp.h"
> +
> #include "g4x_dp.h"
> #include "g4x_hdmi.h"
> #include "i915_drv.h"
> @@ -9148,13 +9150,23 @@ static int intel_bigjoiner_add_affected_planes(struct
> intel_atomic_state *state)
> return 0;
> }
>
> +static bool bo_has_valid_encryption(struct drm_i915_gem_object *obj)
> +{
> + struct drm_i915_private *i915 = to_i915(obj->base.dev);
> +
> + return intel_pxp_key_check(&i915->gt.pxp, obj, false) == 0;
> +}
> +
> static int intel_atomic_check_planes(struct intel_atomic_state *state)
> {
> struct drm_i915_private *dev_priv = to_i915(state->base.dev);
> struct intel_crtc_state *old_crtc_state, *new_crtc_state;
> struct intel_plane_state *plane_state;
> struct intel_plane *plane;
> + struct intel_plane_state *new_plane_state;
> + struct intel_plane_state *old_plane_state;
> struct intel_crtc *crtc;
> + const struct drm_framebuffer *fb;
> int i, ret;
>
> ret = icl_add_linked_planes(state);
> @@ -9202,6 +9214,16 @@ static int intel_atomic_check_planes(struct
> intel_atomic_state *state)
> return ret;
> }
>
> + for_each_new_intel_plane_in_state(state, plane, plane_state, i) {
> + new_plane_state = intel_atomic_get_new_plane_state(state,
> plane);
> + old_plane_state = intel_atomic_get_old_plane_state(state,
> plane);
> + fb = new_plane_state->hw.fb;
> + if (fb)
> + new_plane_state->decrypt =
> bo_has_valid_encryption(intel_fb_obj(fb));
> + else
> + new_plane_state->decrypt = old_plane_state->decrypt;
> + }
> +
> return 0;
> }
>
> @@ -9488,6 +9510,10 @@ static int intel_atomic_check_async(struct
> intel_atomic_state *state)
> drm_dbg_kms(&i915->drm, "Color range cannot be changed
> in async flip\n");
> return -EINVAL;
> }
> +
> + /* plane decryption is allow to change only in synchronous
> flips */
> + if (old_plane_state->decrypt != new_plane_state->decrypt)
> + return -EINVAL;
> }
>
> return 0;
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> b/drivers/gpu/drm/i915/display/intel_display_types.h
> index c7bcf9183447..6d4ea1d5bf7b 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -629,6 +629,9 @@ struct intel_plane_state {
>
> struct intel_fb_view view;
>
> + /* Plane pxp decryption state */
> + bool decrypt;
> +
> /* plane control register */
> u32 ctl;
>
> diff --git a/drivers/gpu/drm/i915/display/skl_universal_plane.c
> b/drivers/gpu/drm/i915/di
Re: [Intel-gfx] [PATCH 2/7] drm/i915/guc: put all guc objects in lmem when available
On Wed, 1 Sept 2021 at 03:21, wrote:
>
> From: Daniele Ceraolo Spurio
>
> The firmware binary has to be loaded from lmem and the recommendation is
> to put all other objects in there as well. Note that we don't fall back
> to system memory if the allocation in lmem fails because all objects are
> allocated during driver load and if we have issues with lmem at that point
> something is seriously wrong with the system, so no point in trying to
> handle it.
>
> Cc: Matthew Auld
> Cc: Abdiel Janulgue
> Cc: Michal Wajdeczko
> Cc: Vinay Belgaumkar
> Cc: Radoslaw Szwichtenberg
> Signed-off-by: Daniele Ceraolo Spurio
> Signed-off-by: Matthew Brost
> ---
> drivers/gpu/drm/i915/gem/i915_gem_lmem.c | 26
> drivers/gpu/drm/i915/gem/i915_gem_lmem.h | 4 ++
> drivers/gpu/drm/i915/gt/uc/intel_guc.c| 9 ++-
> drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c | 13 ++--
> drivers/gpu/drm/i915/gt/uc/intel_huc.c| 14 -
> drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 75 +--
> 6 files changed, 128 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
> b/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
> index eb345305dc52..034226c5d4d0 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
> @@ -103,6 +103,32 @@ __i915_gem_object_create_lmem_with_ps(struct
> drm_i915_private *i915,
> size, page_size, flags);
> }
>
> +struct drm_i915_gem_object *
> +i915_gem_object_create_lmem_from_data(struct drm_i915_private *i915,
> + const void *data, size_t size)
> +{
> + struct drm_i915_gem_object *obj;
> + void *map;
> +
> + obj = i915_gem_object_create_lmem(i915,
> + round_up(size, PAGE_SIZE),
> + I915_BO_ALLOC_CONTIGUOUS);
Maybe push the ALLOC_CONTIG into the caller and expose the flags
instead, assuming it's still needed for something GuC related?
pin_map() at least no longer has that constraint.
Re: [PATCH] drm: rcar-du: Improve kernel log messages when initializing encoders
On 22/08/2021 01:39, Laurent Pinchart wrote:
> Improve the debugging and error messages printing when initializing
> encoders by replacing the output number by the output name, printing the
> bridge OF node name, and the error code of failed operations.
>
> While at it, move the related rcar_du_output enumeration from
> rcar_du_crtc.h to rcar_du_drv.h as it's not specific to the CRTC.
>
It would be nice if you applied "drm: rcar-du: Sort the DU outputs" [0]
before this patch.
[0]
https://patchwork.kernel.org/project/linux-renesas-soc/patch/20210622232024.3215248-2-kieran.bing...@ideasonboard.com/
But I can always rebase that later otherwise.
Reviewed-by: Kieran Bingham
> Signed-off-by: Laurent Pinchart
> ---
> drivers/gpu/drm/rcar-du/rcar_du_crtc.h| 11 ---
> drivers/gpu/drm/rcar-du/rcar_du_drv.c | 18 ++
> drivers/gpu/drm/rcar-du/rcar_du_drv.h | 13 +
> drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 12 +++-
> drivers/gpu/drm/rcar-du/rcar_du_kms.c | 4 ++--
> 5 files changed, 40 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
> b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
> index 5f2940c42225..66e8839db708 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
> @@ -93,17 +93,6 @@ struct rcar_du_crtc_state {
>
> #define to_rcar_crtc_state(s) container_of(s, struct rcar_du_crtc_state,
> state)
>
> -enum rcar_du_output {
> - RCAR_DU_OUTPUT_DPAD0,
> - RCAR_DU_OUTPUT_DPAD1,
> - RCAR_DU_OUTPUT_LVDS0,
> - RCAR_DU_OUTPUT_LVDS1,
> - RCAR_DU_OUTPUT_HDMI0,
> - RCAR_DU_OUTPUT_HDMI1,
> - RCAR_DU_OUTPUT_TCON,
> - RCAR_DU_OUTPUT_MAX,
> -};
> -
> int rcar_du_crtc_create(struct rcar_du_group *rgrp, unsigned int swindex,
> unsigned int hwindex);
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> index 4ac26d08ebb4..d4dc101dc1d7 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> @@ -502,6 +502,24 @@ static const struct of_device_id rcar_du_of_table[] = {
>
> MODULE_DEVICE_TABLE(of, rcar_du_of_table);
>
> +const char *rcar_du_output_name(enum rcar_du_output output)
> +{
> + static const char * const names[] = {
> + [RCAR_DU_OUTPUT_DPAD0] = "DPAD0",
> + [RCAR_DU_OUTPUT_DPAD1] = "DPAD1",
> + [RCAR_DU_OUTPUT_LVDS0] = "LVDS0",
> + [RCAR_DU_OUTPUT_LVDS1] = "LVDS1",
> + [RCAR_DU_OUTPUT_HDMI0] = "HDMI0",
> + [RCAR_DU_OUTPUT_HDMI1] = "HDMI1",
> + [RCAR_DU_OUTPUT_TCON] = "TCON",
> + };
> +
> + if (output >= ARRAY_SIZE(names) || !names[output])
> + return "UNKNOWN";
> +
> + return names[output];
> +}
> +
> /*
> -
> * DRM operations
> */
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.h
> b/drivers/gpu/drm/rcar-du/rcar_du_drv.h
> index 02ca2d0e1b55..859fd5992601 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_drv.h
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.h
> @@ -33,6 +33,17 @@ struct rcar_du_device;
>
> #define RCAR_DU_QUIRK_ALIGN_128B BIT(0) /* Align pitches to 128 bytes */
>
> +enum rcar_du_output {
> + RCAR_DU_OUTPUT_DPAD0,
> + RCAR_DU_OUTPUT_DPAD1,
> + RCAR_DU_OUTPUT_LVDS0,
> + RCAR_DU_OUTPUT_LVDS1,
> + RCAR_DU_OUTPUT_HDMI0,
> + RCAR_DU_OUTPUT_HDMI1,
> + RCAR_DU_OUTPUT_TCON,
> + RCAR_DU_OUTPUT_MAX,
> +};
> +
> /*
> * struct rcar_du_output_routing - Output routing specification
> * @possible_crtcs: bitmask of possible CRTCs for the output
> @@ -126,4 +137,6 @@ static inline void rcar_du_write(struct rcar_du_device
> *rcdu, u32 reg, u32 data)
> iowrite32(data, rcdu->mmio + reg);
> }
>
> +const char *rcar_du_output_name(enum rcar_du_output output);
> +
> #endif /* __RCAR_DU_DRV_H__ */
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
> b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
> index 4bf4e25d7f01..3977aaa1ab5a 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
> @@ -103,8 +103,8 @@ int rcar_du_encoder_init(struct rcar_du_device *rcdu,
> return -ENOLINK;
> }
>
> - dev_dbg(rcdu->dev, "initializing encoder %pOF for output %u\n",
> - enc_node, output);
> + dev_dbg(rcdu->dev, "initializing encoder %pOF for output %s\n",
> + enc_node, rcar_du_output_name(output));
>
> renc = drmm_encoder_alloc(&rcdu->ddev, struct rcar_du_encoder, base,
> &rcar_du_encoder_funcs, DRM_MODE_ENCODER_NONE,
> @@ -118,8 +118,9 @@ int rcar_du_encoder_init(struct rcar_du_device *rcdu,
> ret = drm_bridge_attach(&renc->base, bridge, NULL,
> DRM_BRIDGE_ATTACH_NO_CONNECTOR);
> if (ret) {
> -
[PATCH V6 0/2] drm/vkms: Add virtual hardware module
This patchset adds support for emulating virtual hardware with VKMS. The virtual hardware mode can be enabled by using the following command while loading the module: sudo modprobe vkms enable_virtual_hw=1 The first patch is prep work for adding virtual_hw mode and refactors the plane composition in vkms by adding a helper function vkms_composer_common() which can be used for both vblank mode and virtual mode. The second patch adds virtual hardware support as a module option. It adds new atomic helper functions for the virtual mode and uses the existing atomic helpers for vblank mode This gives us two sets of drm_crtc_funcs and drm_crtc_helper_funcs structs for both modes, making the code flow cleaner and easier to debug. This patchset has been tested with the igt tests- kms_writeback, kms_atomic, kms_lease, kms_flip, kms_pipe_get_crc and preserves results except for subtests related to crc reads and vertical blanking, in which case, tests are skipped. Sumera Priyadarsini (2): drm/vkms: Refactor vkms_composer_worker() to prep for virtual_hw mode drm/vkms: Add support for virtual hardware mode drivers/gpu/drm/vkms/vkms_composer.c | 92 +-- drivers/gpu/drm/vkms/vkms_crtc.c | 43 - drivers/gpu/drm/vkms/vkms_drv.c | 16 +++-- drivers/gpu/drm/vkms/vkms_drv.h | 4 ++ drivers/gpu/drm/vkms/vkms_writeback.c | 3 +- 5 files changed, 117 insertions(+), 41 deletions(-) -- 2.31.1
[PATCH V6 1/2] drm/vkms: Refactor vkms_composer_worker() to prep for virtual_hw mode
Add a new function vkms_composer_common(). The actual plane
composition work has been moved to the helper function,
vkms_composer_common() which is called by vkms_composer_worker()
and will be called in the implementation of virtual_hw mode
as well.
Signed-off-by: Sumera Priyadarsini
---
Changes in V5:
- Move vkms_crtc_composer() to the patch that introduces
virtual_hw mode (Melissa)
- Fix checkpatch errors(Melissa)
Changes in V4:
- Fix warning
Changes in V3:
- Refactor patchset (Melissa)
Change in V2:
- Add vkms_composer_common() (Daniel)
---
drivers/gpu/drm/vkms/vkms_composer.c | 75
drivers/gpu/drm/vkms/vkms_drv.h | 2 +
2 files changed, 45 insertions(+), 32 deletions(-)
diff --git a/drivers/gpu/drm/vkms/vkms_composer.c
b/drivers/gpu/drm/vkms/vkms_composer.c
index 9e8204be9a14..bca746fb5b53 100644
--- a/drivers/gpu/drm/vkms/vkms_composer.c
+++ b/drivers/gpu/drm/vkms/vkms_composer.c
@@ -206,6 +206,47 @@ static int compose_active_planes(void **vaddr_out,
return 0;
}
+int vkms_composer_common(struct vkms_crtc_state *crtc_state,
+struct vkms_output *out, bool wb_pending, uint32_t
*crc32)
+{
+ struct vkms_composer *primary_composer = NULL;
+ struct vkms_plane_state *act_plane = NULL;
+ void *vaddr_out = NULL;
+ int ret;
+
+ if (crtc_state->num_active_planes >= 1) {
+ act_plane = crtc_state->active_planes[0];
+ if (act_plane->base.base.plane->type == DRM_PLANE_TYPE_PRIMARY)
+ primary_composer = act_plane->composer;
+ }
+
+ if (!primary_composer)
+ return -EINVAL;
+ if (wb_pending)
+ vaddr_out = crtc_state->active_writeback->data[0].vaddr;
+
+ ret = compose_active_planes(&vaddr_out, primary_composer, crtc_state);
+
+ if (ret) {
+ if ((ret == -EINVAL || ret == -ENOMEM) && !wb_pending)
+ kfree(vaddr_out);
+ return ret;
+ }
+
+ *crc32 = compute_crc(vaddr_out, primary_composer);
+
+ if (wb_pending) {
+ drm_writeback_signal_completion(&out->wb_connector, 0);
+ spin_lock_irq(&out->composer_lock);
+ crtc_state->wb_pending = false;
+ spin_unlock_irq(&out->composer_lock);
+ } else {
+ kfree(vaddr_out);
+ }
+
+ return 0;
+}
+
/**
* vkms_composer_worker - ordered work_struct to compute CRC
*
@@ -222,10 +263,7 @@ void vkms_composer_worker(struct work_struct *work)
composer_work);
struct drm_crtc *crtc = crtc_state->base.crtc;
struct vkms_output *out = drm_crtc_to_vkms_output(crtc);
- struct vkms_composer *primary_composer = NULL;
- struct vkms_plane_state *act_plane = NULL;
bool crc_pending, wb_pending;
- void *vaddr_out = NULL;
u32 crc32 = 0;
u64 frame_start, frame_end;
int ret;
@@ -247,37 +285,10 @@ void vkms_composer_worker(struct work_struct *work)
if (!crc_pending)
return;
- if (crtc_state->num_active_planes >= 1) {
- act_plane = crtc_state->active_planes[0];
- if (act_plane->base.base.plane->type == DRM_PLANE_TYPE_PRIMARY)
- primary_composer = act_plane->composer;
- }
-
- if (!primary_composer)
+ ret = vkms_composer_common(crtc_state, out, wb_pending, &crc32);
+ if (ret == -EINVAL)
return;
- if (wb_pending)
- vaddr_out = crtc_state->active_writeback->data[0].vaddr;
-
- ret = compose_active_planes(&vaddr_out, primary_composer,
- crtc_state);
- if (ret) {
- if (ret == -EINVAL && !wb_pending)
- kfree(vaddr_out);
- return;
- }
-
- crc32 = compute_crc(vaddr_out, primary_composer);
-
- if (wb_pending) {
- drm_writeback_signal_completion(&out->wb_connector, 0);
- spin_lock_irq(&out->composer_lock);
- crtc_state->wb_pending = false;
- spin_unlock_irq(&out->composer_lock);
- } else {
- kfree(vaddr_out);
- }
-
/*
* The worker can fall behind the vblank hrtimer, make sure we catch up.
*/
diff --git a/drivers/gpu/drm/vkms/vkms_drv.h b/drivers/gpu/drm/vkms/vkms_drv.h
index d48c23d40ce5..6f5f63591c20 100644
--- a/drivers/gpu/drm/vkms/vkms_drv.h
+++ b/drivers/gpu/drm/vkms/vkms_drv.h
@@ -137,6 +137,8 @@ int vkms_verify_crc_source(struct drm_crtc *crtc, const
char *source_name,
size_t *values_cnt);
/* Composer Support */
+int vkms_composer_common(struct vkms_crtc_state *crtc_state, struct
vkms_output *out,
+bool wb_pending, uint32_t *crcs);
void vkms_composer_worker(struct work_struct *work);
void vkms_set_composer(struct vkms_output *ou
[PATCH V6 2/2] drm/vkms: Add support for virtual hardware mode
Add a virtual hardware or vblank-less mode as a module
to enable VKMS to emulate virtual hardware drivers. This means
no vertical blanking events occur and pageflips are completed
arbitrarily and when required for updating the frame.
Add a new drm_crtc_funcs struct, vkms_vblankless_crtc_funcs and a
drm_crtc_helper_funcs struct, vkms_vblankless_crtc_helper_funcs()
which hold the atomic helpers for virtual hardware mode.
The existing vkms_crtc_funcs struct and vkms_crtc_helper_funcs
struct hold atomic helpers for the default vblank mode.
This makes the code flow clearer and testing
virtual hardware mode easier.
Add a function vkms_crtc_composer() which calls the helper function,
vkms_composer_common() for plane composition in vblank-less mode.
vkms_crtc_composer() is directly called in the atomic hook in
vkms_crtc_atomic_begin().
However, some crc captures still use vblanks which causes the crc-based
igt tests to crash. So, no CRC functions are called in vblankless mode
for now and will be implemented in a later patch.
This patchset has been tested with the igt tests- kms_writeback, kms_atomic
, kms_lease, kms_flip, kms_pipe_get_crc and preserves results except for
subtests related to crc reads and vertical blanking, in which case,
tests are skipped.
The patch is based on Rodrigo Siqueira's
patch(https://patchwork.freedesktop.org/patch/316851/?series=48469&rev=3)
and the ensuing review.
Signed-off-by: Sumera Priyadarsini
---
Changes in V6:
- Skip CRC functions in vblankless mode
- Refactor helper function names(Melissa)
Changes in V5:
- Move vkms_crtc_composer() to this patch(Melissa)
- Add more clarification for "vblank-less" mode(Pekka)
- Replace kzalloc() with kvmalloc() in compose_active_planes()
to fix memory allocation error for output frame
- Fix checkpatch warnings (Melissa)
Changes in V3:
- Refactor patchset(Melissa)
Changes in V2:
- Add atomic helper functions in a separate struct for virtual hardware
mode (Daniel)
- Remove spinlock across 'vkms_output->lock' in vkms_crtc.c(Daniel)
- Add vkms_composer_common() (Daniel)
---
drivers/gpu/drm/vkms/vkms_composer.c | 21 +++--
drivers/gpu/drm/vkms/vkms_crtc.c | 43 +--
drivers/gpu/drm/vkms/vkms_drv.c | 16 +++---
drivers/gpu/drm/vkms/vkms_drv.h | 2 ++
drivers/gpu/drm/vkms/vkms_writeback.c | 3 +-
5 files changed, 74 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/vkms/vkms_composer.c
b/drivers/gpu/drm/vkms/vkms_composer.c
index bca746fb5b53..a009589b2c3a 100644
--- a/drivers/gpu/drm/vkms/vkms_composer.c
+++ b/drivers/gpu/drm/vkms/vkms_composer.c
@@ -176,11 +176,12 @@ static int compose_active_planes(void **vaddr_out,
{
struct drm_framebuffer *fb = &primary_composer->fb;
struct drm_gem_object *gem_obj = drm_gem_fb_get_obj(fb, 0);
+
const void *vaddr;
int i;
if (!*vaddr_out) {
- *vaddr_out = kzalloc(gem_obj->size, GFP_KERNEL);
+ *vaddr_out = kvmalloc(gem_obj->size, GFP_KERNEL);
if (!*vaddr_out) {
DRM_ERROR("Cannot allocate memory for output frame.");
return -ENOMEM;
@@ -229,7 +230,7 @@ int vkms_composer_common(struct vkms_crtc_state *crtc_state,
if (ret) {
if ((ret == -EINVAL || ret == -ENOMEM) && !wb_pending)
- kfree(vaddr_out);
+ kvfree(vaddr_out);
return ret;
}
@@ -241,7 +242,7 @@ int vkms_composer_common(struct vkms_crtc_state *crtc_state,
crtc_state->wb_pending = false;
spin_unlock_irq(&out->composer_lock);
} else {
- kfree(vaddr_out);
+ kvfree(vaddr_out);
}
return 0;
@@ -296,6 +297,20 @@ void vkms_composer_worker(struct work_struct *work)
drm_crtc_add_crc_entry(crtc, true, frame_start++, &crc32);
}
+void vkms_crtc_composer(struct vkms_crtc_state *crtc_state)
+{
+ struct drm_crtc *crtc = crtc_state->base.crtc;
+ struct vkms_output *out = drm_crtc_to_vkms_output(crtc);
+ u32 crc32 = 0;
+ int ret;
+
+ ret = vkms_composer_common(crtc_state, out, crtc_state->wb_pending,
&crc32);
+ if (ret == -EINVAL)
+ return;
+
+ drm_crtc_add_crc_entry(crtc, true, 0, &crc32);
+}
+
static const char * const pipe_crc_sources[] = {"auto"};
const char *const *vkms_get_crc_sources(struct drm_crtc *crtc,
diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c b/drivers/gpu/drm/vkms/vkms_crtc.c
index 57bbd32e9beb..4a933553e0e4 100644
--- a/drivers/gpu/drm/vkms/vkms_crtc.c
+++ b/drivers/gpu/drm/vkms/vkms_crtc.c
@@ -174,6 +174,15 @@ static const struct drm_crtc_funcs vkms_crtc_funcs = {
.verify_crc_source = vkms_verify_crc_source,
};
+static const struct drm_crtc_funcs vkms_vblankless_crtc_funcs = {
+ .set_config = drm_atomic_helper_set_config,
+ .destroy= drm_crtc_cl
[PATCH 2/2] dt-bindings: display: Add bindings for Novatek NT35950
The nt35950 IC from Novatek is a Driver IC used to drive MIPI-DSI panels,
with Static RAM for content retention in command mode and also supports
video mode with VESA Frame Buffer Compression or Display Stream Compression
on single, or dual dsi port(s).
This DDIC is also capable of upscaling an input image to the panel's native
resolution, for example it can upscale a 1920x1080 input to 3840x2160 with
either bilinear interpolation or pixel duplication.
Signed-off-by: AngeloGioacchino Del Regno
---
.../display/panel/novatek,nt35950.yaml| 106 ++
1 file changed, 106 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/novatek,nt35950.yaml
diff --git
a/Documentation/devicetree/bindings/display/panel/novatek,nt35950.yaml
b/Documentation/devicetree/bindings/display/panel/novatek,nt35950.yaml
new file mode 100644
index ..377a05d48a02
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/novatek,nt35950.yaml
@@ -0,0 +1,106 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/novatek,nt35950.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Novatek NT35950-based display panels
+
+maintainers:
+ - AngeloGioacchino Del Regno
+
+description: |
+ The nt35950 IC from Novatek is a Driver IC used to drive MIPI-DSI panels,
+ with Static RAM for content retention in command mode and also supports
+ video mode with VESA Frame Buffer Compression or Display Stream Compression
+ on single, or dual dsi port(s).
+ This DDIC is also capable of upscaling an input image to the panel's native
+ resolution, for example it can upscale a 1920x1080 input to 3840x2160 with
+ either bilinear interpolation or pixel duplication.
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+items:
+ - enum:
+ - sharp,ls055d1sx04
+ - const: novatek,nt35950
+description: This indicates the panel manufacturer of the panel
+ that is in turn using the NT35950 panel driver. The compatible
+ string determines how the NT35950 panel driver shall be configured
+ to work with the indicated panel. The novatek,nt35950 compatible shall
+ always be provided as a fallback.
+
+ reset-gpios:
+maxItems: 1
+description: phandle of gpio for reset line - This should be 8mA, gpio
+ can be configured using mux, pinctrl, pinctrl-names (active high)
+
+ avdd-supply:
+description: positive boost supply regulator
+ avee-supply:
+description: negative boost supply regulator
+ dvdd-supply:
+description: regulator that supplies the digital voltage
+ vddio-supply:
+description: regulator that supplies the I/O voltage
+
+ backlight: true
+ ports: true
+ reg: true
+
+required:
+ - compatible
+ - reg
+ - reset-gpios
+ - avdd-supply
+ - avee-supply
+ - dvdd-supply
+ - vddio-supply
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+
+dsi0 {
+#address-cells = <1>;
+#size-cells = <0>;
+
+panel@0 {
+compatible = "sharp,ls055d1sx04", "novatek,nt35950";
+reg = <0>;
+
+backlight = <&pmi8998_wled>;
+reset-gpios = <&tlmm 94 GPIO_ACTIVE_HIGH>;
+
+avdd-supply = <&lab>;
+avee-supply = <&ibb>;
+dvdd-supply = <&disp_dvdd_vreg>;
+vddio-supply = <&vreg_l14a_1p85>;
+
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+port@0 {
+reg = <0>;
+panel_in0: endpoint {
+remote-endpoint = <&dsi0_out>;
+};
+};
+
+port@1 {
+reg = <1>;
+panel_in1: endpoint {
+remote-endpoint = <&dsi1_out>;
+};
+};
+};
+};
+};
+
+...
--
2.32.0
[PATCH 1/2] drm/panel: Add driver for Novatek NT35950 DSI DriverIC panels
Add a driver for panels using the Novatek NT35950 Display Driver IC,
including support for the Sharp LS055D1SX04, found in some Sony Xperia
Z5 Premium and XZ Premium smartphones.
Signed-off-by: AngeloGioacchino Del Regno
---
drivers/gpu/drm/panel/Kconfig | 11 +
drivers/gpu/drm/panel/Makefile| 1 +
drivers/gpu/drm/panel/panel-novatek-nt35950.c | 702 ++
3 files changed, 714 insertions(+)
create mode 100644 drivers/gpu/drm/panel/panel-novatek-nt35950.c
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index ab5a52c71ec5..1cf064d597a2 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -271,6 +271,17 @@ config DRM_PANEL_NOVATEK_NT35510
around the Novatek NT35510 display controller, such as some
Hydis panels.
+config DRM_PANEL_NOVATEK_NT35950
+ tristate "Novatek NT35950 DSI panel"
+ depends on OF
+ depends on DRM_MIPI_DSI
+ depends on BACKLIGHT_CLASS_DEVICE
+ help
+ Say Y here if you want to enable support for the panels built
+ around the Novatek NT35950 display controller, such as some
+ Sharp panels used in Sony Xperia Z5 Premium and XZ Premium
+ mobile phones.
+
config DRM_PANEL_NOVATEK_NT36672A
tristate "Novatek NT36672A DSI panel"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 1b494d479ffd..190b5f90af4d 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -25,6 +25,7 @@ obj-$(CONFIG_DRM_PANEL_LG_LB035Q02) += panel-lg-lb035q02.o
obj-$(CONFIG_DRM_PANEL_LG_LG4573) += panel-lg-lg4573.o
obj-$(CONFIG_DRM_PANEL_NEC_NL8048HL11) += panel-nec-nl8048hl11.o
obj-$(CONFIG_DRM_PANEL_NOVATEK_NT35510) += panel-novatek-nt35510.o
+obj-$(CONFIG_DRM_PANEL_NOVATEK_NT35950) += panel-novatek-nt35950.o
obj-$(CONFIG_DRM_PANEL_NOVATEK_NT36672A) += panel-novatek-nt36672a.o
obj-$(CONFIG_DRM_PANEL_NOVATEK_NT39016) += panel-novatek-nt39016.o
obj-$(CONFIG_DRM_PANEL_MANTIX_MLAF057WE51) += panel-mantix-mlaf057we51.o
diff --git a/drivers/gpu/drm/panel/panel-novatek-nt35950.c
b/drivers/gpu/drm/panel/panel-novatek-nt35950.c
new file mode 100644
index ..d42c7af0d75c
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-novatek-nt35950.c
@@ -0,0 +1,702 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Novatek NT35950 DriverIC panels driver
+ *
+ * Copyright (c) 2021 AngeloGioacchino Del Regno
+ *
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+
+#define MCS_CMD_MAUCCTR0xf0 /* Manufacturer command
enable */
+#define MCS_PARAM_SCALER_FUNCTION 0x58 /* Scale-up function */
+#define MCS_PARAM_SCALEUP_MODE 0xc9
+ #define MCS_SCALEUP_SIMPLE0x0
+ #define MCS_SCALEUP_BILINEAR BIT(0)
+ #define MCS_SCALEUP_DUPLICATE (BIT(0) | BIT(4))
+
+/* VESA Display Stream Compression param */
+#define MCS_PARAM_VESA_DSC_ON 0x03
+
+/* Data Compression mode */
+#define MCS_PARAM_DATA_COMPRESSION 0x90
+ #define MCS_DATA_COMPRESSION_NONE 0x00
+ #define MCS_DATA_COMPRESSION_FBC 0x02
+ #define MCS_DATA_COMPRESSION_DSC 0x03
+
+/* Display Output control */
+#define MCS_PARAM_DISP_OUTPUT_CTRL 0xb4
+ #define MCS_DISP_OUT_SRAM_EN BIT(0)
+ #define MCS_DISP_OUT_VIDEO_MODE BIT(4)
+
+/* VESA Display Stream Compression setting */
+#define MCS_PARAM_VESA_DSC_SETTING 0xc0
+
+/* SubPixel Rendering (SPR) */
+#define MCS_PARAM_SPR_EN 0xe3
+#define MCS_PARAM_SPR_MODE 0xef
+ #define MCS_SPR_MODE_YYG_RAINBOW_RGB 0x01
+
+#define NT35950_VREG_MAX 4
+
+struct nt35950 {
+ struct drm_panel panel;
+ struct drm_connector *connector;
+ struct mipi_dsi_device *dsi[2];
+ struct regulator_bulk_data vregs[NT35950_VREG_MAX];
+ struct gpio_desc *reset_gpio;
+ const struct nt35950_panel_desc *desc;
+
+ int cur_mode;
+ u8 last_page;
+ bool prepared;
+};
+
+struct nt35950_panel_mode {
+ const struct drm_display_mode mode;
+
+ bool enable_sram;
+ bool is_video_mode;
+ u8 scaler_on;
+ u8 scaler_mode;
+ u8 compression;
+ u8 spr_en;
+ u8 spr_mode;
+};
+
+struct nt35950_panel_desc {
+ const char *model_name;
+ const struct mipi_dsi_device_info dsi_info;
+ const struct nt35950_panel_mode *mode_data;
+
+ bool is_dual_dsi;
+ u8 num_lanes;
+ u8 num_modes;
+};
+
+static inline struct nt35950 *to_nt35950(struct drm_panel *panel)
+{
+ return container_of(panel, struct nt35950, panel);
+}
+
+#define dsi_dcs_write_seq(dsi, seq...) do {\
+ static const u8 d[] = { seq }; \
+ int ret;\
+
[PATCH 2/2] dt-bindings: display: Document BOE BF060Y8M-AJ0 panel compatible
Document the boe,bf060y8m-aj0 panel.
Signed-off-by: AngeloGioacchino Del Regno
---
.../display/panel/boe,bf060y8m-aj0.yaml | 81 +++
1 file changed, 81 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/boe,bf060y8m-aj0.yaml
diff --git
a/Documentation/devicetree/bindings/display/panel/boe,bf060y8m-aj0.yaml
b/Documentation/devicetree/bindings/display/panel/boe,bf060y8m-aj0.yaml
new file mode 100644
index ..a8f3afa922c8
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/boe,bf060y8m-aj0.yaml
@@ -0,0 +1,81 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/boe,bf060y8m-aj0.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: BOE BF060Y8M-AJ0 5.99" 1080x2160 AMOLED Panel
+
+maintainers:
+ - AngeloGioacchino Del Regno
+
+description: |
+ This is a 5.99" 1080x2160 16.7M Color active matrix AMOLED
+ video mode panel module on MIPI-DSI 4-Lane interface, GGRB
+ pixel arrangement, 63 micrometers pitch, with an active
+ area of 68.04 x 136.08 millimeters.
+ Each pixel is divided into red and green dots, or blue and
+ green dots, and two pixels share red or blue dots which are
+ arranged in vertical stripe.
+ The DriverIC for this panel module is SW43404.
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+const: boe,bf060y8m-aj0
+
+ elvdd-supply:
+description: EL Driving positive (VDD) supply (4.40-4.80V)
+ elvss-supply:
+description: EL Driving negative (VSS) supply (-5.00V to -1.40V)
+ vcc-supply:
+description: Core (TSP) voltage supply (2.70-3.60V)
+ vci-supply:
+description: DriverIC Operation supply (2.60-3.60V)
+ vddio-supply:
+description: I/O voltage supply (1.62-1.98V)
+
+ port: true
+ reg: true
+ reset-gpios: true
+
+required:
+ - compatible
+ - elvdd-supply
+ - elvss-supply
+ - vcc-supply
+ - vci-supply
+ - vddio-supply
+ - reg
+ - reset-gpios
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+
+dsi {
+#address-cells = <1>;
+#size-cells = <0>;
+panel@0 {
+compatible = "boe,bf060y8m-aj0";
+reg = <0>;
+
+reset-gpios = <&tlmm 94 GPIO_ACTIVE_HIGH>;
+
+vcc-supply = <&disp_vcc_vreg>;
+vddio-supply = <&disp_vddio_vreg>;
+vci-supply = <&disp_vci_vreg>;
+elvdd-supply = <&disp_elvdd_vreg>;
+elvss-supply = <&disp_elvss_vreg>;
+
+port {
+panel_in: endpoint {
+remote-endpoint = <&dsi0_out>;
+};
+};
+};
+};
--
2.32.0
[PATCH 1/2] drm/panel: Add BOE BF060Y8M-AJ0 5.99" AMOLED panel driver
This adds support for the BOE BF060Y8M-AJ0 5.99" AMOLED module
that can be found in some F(x)Tec Pro1 and Elephone U1 devices.
Signed-off-by: AngeloGioacchino Del Regno
---
drivers/gpu/drm/panel/Kconfig | 11 +
drivers/gpu/drm/panel/Makefile| 1 +
.../gpu/drm/panel/panel-boe-bf060y8m-aj0.c| 445 ++
3 files changed, 457 insertions(+)
create mode 100644 drivers/gpu/drm/panel/panel-boe-bf060y8m-aj0.c
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index beb581b96ecd..ab5a52c71ec5 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -37,6 +37,17 @@ config DRM_PANEL_ASUS_Z00T_TM5P5_NT35596
NT35596 1080x1920 video mode panel as found in some Asus
Zenfone 2 Laser Z00T devices.
+config DRM_PANEL_BOE_BF060Y8M_AJ0
+ tristate "Boe BF060Y8M-AJ0 panel"
+ depends on OF
+ depends on DRM_MIPI_DSI
+ depends on BACKLIGHT_CLASS_DEVICE
+ help
+ Say Y here if you want to enable support for Boe BF060Y8M-AJ0
+ 5.99" AMOLED modules. The panel has a 1080x2160 resolution and
+ uses 24 bit RGB per pixel. It provides a MIPI DSI interface to
+ the host and backlight is controlled through DSI commands.
+
config DRM_PANEL_BOE_HIMAX8279D
tristate "Boe Himax8279d panel"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index c8132050bcec..1b494d479ffd 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -2,6 +2,7 @@
obj-$(CONFIG_DRM_PANEL_ABT_Y030XX067A) += panel-abt-y030xx067a.o
obj-$(CONFIG_DRM_PANEL_ARM_VERSATILE) += panel-arm-versatile.o
obj-$(CONFIG_DRM_PANEL_ASUS_Z00T_TM5P5_NT35596) +=
panel-asus-z00t-tm5p5-n35596.o
+obj-$(CONFIG_DRM_PANEL_BOE_BF060Y8M_AJ0) += panel-boe-bf060y8m-aj0.o
obj-$(CONFIG_DRM_PANEL_BOE_HIMAX8279D) += panel-boe-himax8279d.o
obj-$(CONFIG_DRM_PANEL_BOE_TV101WUM_NL6) += panel-boe-tv101wum-nl6.o
obj-$(CONFIG_DRM_PANEL_DSI_CM) += panel-dsi-cm.o
diff --git a/drivers/gpu/drm/panel/panel-boe-bf060y8m-aj0.c
b/drivers/gpu/drm/panel/panel-boe-bf060y8m-aj0.c
new file mode 100644
index ..8d080004b86c
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-boe-bf060y8m-aj0.c
@@ -0,0 +1,445 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * BOE BF060Y8M-AJ0 5.99" MIPI-DSI OLED Panel on SW43404 DriverIC
+ *
+ * Copyright (c) 2020 AngeloGioacchino Del Regno
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define DCS_ALLOW_HBM_RANGE0x0c
+#define DCS_DISALLOW_HBM_RANGE 0x08
+
+enum boe_bf060y8m_aj0_supplies {
+ BF060Y8M_VREG_VCC,
+ BF060Y8M_VREG_VDDIO,
+ BF060Y8M_VREG_VCI,
+ BF060Y8M_VREG_EL_VDD,
+ BF060Y8M_VREG_EL_VSS,
+ BF060Y8M_VREG_MAX
+};
+
+struct boe_bf060y8m_aj0 {
+ struct drm_panel panel;
+ struct mipi_dsi_device *dsi;
+ struct regulator_bulk_data vregs[BF060Y8M_VREG_MAX];
+ struct gpio_desc *reset_gpio;
+ bool prepared;
+};
+
+static inline
+struct boe_bf060y8m_aj0 *to_boe_bf060y8m_aj0(struct drm_panel *panel)
+{
+ return container_of(panel, struct boe_bf060y8m_aj0, panel);
+}
+
+#define dsi_dcs_write_seq(dsi, seq...) do {\
+ static const u8 d[] = { seq }; \
+ int ret;\
+ ret = mipi_dsi_dcs_write_buffer(dsi, d, ARRAY_SIZE(d)); \
+ if (ret < 0)\
+ return ret; \
+ } while (0)
+
+static void boe_bf060y8m_aj0_reset(struct boe_bf060y8m_aj0 *boe)
+{
+ gpiod_set_value_cansleep(boe->reset_gpio, 0);
+ usleep_range(2000, 3000);
+ gpiod_set_value_cansleep(boe->reset_gpio, 1);
+ usleep_range(15000, 16000);
+ gpiod_set_value_cansleep(boe->reset_gpio, 0);
+ usleep_range(5000, 6000);
+}
+
+static int boe_bf060y8m_aj0_on(struct boe_bf060y8m_aj0 *boe)
+{
+ struct mipi_dsi_device *dsi = boe->dsi;
+ struct device *dev = &dsi->dev;
+ int ret;
+
+ dsi_dcs_write_seq(dsi, 0xb0, 0xa5, 0x00);
+ dsi_dcs_write_seq(dsi, 0xb2, 0x00, 0x4c);
+ dsi_dcs_write_seq(dsi, MIPI_DCS_SET_3D_CONTROL, 0x10);
+ dsi_dcs_write_seq(dsi, MIPI_DCS_WRITE_POWER_SAVE, DCS_ALLOW_HBM_RANGE);
+ dsi_dcs_write_seq(dsi, 0xf8,
+ 0x00, 0x08, 0x10, 0x00, 0x22, 0x00, 0x00, 0x2d);
+
+ ret = mipi_dsi_dcs_exit_sleep_mode(dsi);
+ if (ret < 0) {
+ dev_err(dev, "Failed to exit sleep mode: %d\n", ret);
+ return ret;
+ }
+ msleep(30);
+
+ dsi_dcs_write_seq(dsi, 0xb0, 0xa5, 0x00);
+ dsi_dcs_write_seq(dsi, 0xc0,
+ 0x08, 0x48, 0x65, 0x33, 0x33, 0x33,
+
[PATCH 1/2] drm/msm/dpu: Add a function to retrieve the current CTL status
Add a function that returns whether the requested CTL is active or not:
this will be used in a later commit to fix command mode panel issues.
Signed-off-by: AngeloGioacchino Del Regno
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c | 6 ++
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h | 7 +++
2 files changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
index 64740ddb983e..3b6fd73eb3a8 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
@@ -91,6 +91,11 @@ static inline void dpu_hw_ctl_trigger_start(struct
dpu_hw_ctl *ctx)
DPU_REG_WRITE(&ctx->hw, CTL_START, 0x1);
}
+static inline bool dpu_hw_ctl_is_started(struct dpu_hw_ctl *ctx)
+{
+ return !!(DPU_REG_READ(&ctx->hw, CTL_START) & BIT(0));
+}
+
static inline void dpu_hw_ctl_trigger_pending(struct dpu_hw_ctl *ctx)
{
trace_dpu_hw_ctl_trigger_prepare(ctx->pending_flush_mask,
@@ -579,6 +584,7 @@ static void _setup_ctl_ops(struct dpu_hw_ctl_ops *ops,
ops->get_pending_flush = dpu_hw_ctl_get_pending_flush;
ops->get_flush_register = dpu_hw_ctl_get_flush_register;
ops->trigger_start = dpu_hw_ctl_trigger_start;
+ ops->is_started = dpu_hw_ctl_is_started;
ops->trigger_pending = dpu_hw_ctl_trigger_pending;
ops->reset = dpu_hw_ctl_reset_control;
ops->wait_reset_status = dpu_hw_ctl_wait_reset_status;
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h
index 806c171e5df2..ac1544474022 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h
@@ -61,6 +61,13 @@ struct dpu_hw_ctl_ops {
*/
void (*trigger_start)(struct dpu_hw_ctl *ctx);
+ /**
+* check if the ctl is started
+* @ctx : ctl path ctx pointer
+* @Return: true if started, false if stopped
+*/
+ bool (*is_started)(struct dpu_hw_ctl *ctx);
+
/**
* kickoff prepare is in progress hw operation for sw
* controlled interfaces: DSI cmd mode and WB interface
--
2.32.0
[PATCH 2/2] drm/msm/dpu: Fix timeout issues on command mode panels
In function dpu_encoder_phys_cmd_wait_for_commit_done we are always checking if the relative CTL is started by waiting for an interrupt to fire: it is fine to do that, but then sometimes we call this function while the CTL is up and has never been put down, but that interrupt gets raised only when the CTL gets a state change from 0 to 1 (disabled to enabled), so we're going to wait for something that will never happen on its own. Solving this while avoiding to restart the CTL is actually possible and can be done by just checking if it is already up and running when the wait_for_commit_done function is called: in this case, so, if the CTL was already running, we can say that the commit is done if the command transmission is complete (in other terms, if the interface has been flushed). Signed-off-by: AngeloGioacchino Del Regno --- drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c index aa01698d6b25..b5b1b555ac4e 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c @@ -682,6 +682,9 @@ static int dpu_encoder_phys_cmd_wait_for_commit_done( if (!dpu_encoder_phys_cmd_is_master(phys_enc)) return 0; + if (phys_enc->hw_ctl->ops.is_started) + return dpu_encoder_phys_cmd_wait_for_tx_complete(phys_enc); + return _dpu_encoder_phys_cmd_wait_for_ctl_start(phys_enc); } -- 2.32.0
[PATCH 1/5] drm: Add drm_fixed_16_16 helper
This constructs a fixed 16.16 rational, useful to specify the minimum
and maximum scaling in drm_atomic_helper_check_plane_state. It is
open-coded as a macro in multiple drivers, so let's share the helper.
Signed-off-by: Alyssa Rosenzweig
---
include/drm/drm_fixed.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/include/drm/drm_fixed.h b/include/drm/drm_fixed.h
index 553210c02ee0..df1f369b4918 100644
--- a/include/drm/drm_fixed.h
+++ b/include/drm/drm_fixed.h
@@ -208,4 +208,9 @@ static inline s64 drm_fixp_exp(s64 x)
return sum;
}
+static inline int drm_fixed_16_16(s32 mult, s32 div)
+{
+ return (mult << 16) / div;
+}
+
#endif
--
2.30.2
[PATCH 2/5] drm/meson: Use common drm_fixed_16_16 helper
Replace our open-coded FRAC_16_16 with the common drm_fixed_16_16
helper to reduce code duplication between drivers.
Signed-off-by: Alyssa Rosenzweig
Cc: linux-amlo...@lists.infradead.org
---
drivers/gpu/drm/meson/meson_overlay.c | 7 +++
drivers/gpu/drm/meson/meson_plane.c | 5 ++---
2 files changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/meson/meson_overlay.c
b/drivers/gpu/drm/meson/meson_overlay.c
index dfef8afcc245..d8fc6bbb332f 100644
--- a/drivers/gpu/drm/meson/meson_overlay.c
+++ b/drivers/gpu/drm/meson/meson_overlay.c
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
#include "meson_overlay.h"
#include "meson_registers.h"
@@ -162,8 +163,6 @@ struct meson_overlay {
};
#define to_meson_overlay(x) container_of(x, struct meson_overlay, base)
-#define FRAC_16_16(mult, div)(((mult) << 16) / (div))
-
static int meson_overlay_atomic_check(struct drm_plane *plane,
struct drm_atomic_state *state)
{
@@ -181,8 +180,8 @@ static int meson_overlay_atomic_check(struct drm_plane
*plane,
return drm_atomic_helper_check_plane_state(new_plane_state,
crtc_state,
- FRAC_16_16(1, 5),
- FRAC_16_16(5, 1),
+ drm_fixed_16_16(1, 5),
+ drm_fixed_16_16(5, 1),
true, true);
}
diff --git a/drivers/gpu/drm/meson/meson_plane.c
b/drivers/gpu/drm/meson/meson_plane.c
index 8640a8a8a469..4fae9ebbf178 100644
--- a/drivers/gpu/drm/meson/meson_plane.c
+++ b/drivers/gpu/drm/meson/meson_plane.c
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
#include "meson_plane.h"
#include "meson_registers.h"
@@ -68,8 +69,6 @@ struct meson_plane {
};
#define to_meson_plane(x) container_of(x, struct meson_plane, base)
-#define FRAC_16_16(mult, div)(((mult) << 16) / (div))
-
static int meson_plane_atomic_check(struct drm_plane *plane,
struct drm_atomic_state *state)
{
@@ -92,7 +91,7 @@ static int meson_plane_atomic_check(struct drm_plane *plane,
*/
return drm_atomic_helper_check_plane_state(new_plane_state,
crtc_state,
- FRAC_16_16(1, 5),
+ drm_fixed_16_16(1, 5),
DRM_PLANE_HELPER_NO_SCALING,
false, true);
}
--
2.30.2
[PATCH 3/5] drm/msm: Use common drm_fixed_16_16 helper
Replace our open-coded FRAC_16_16 with the common drm_fixed_16_16
helper to reduce code duplication between drivers.
Signed-off-by: Alyssa Rosenzweig
Cc: linux-arm-...@vger.kernel.org
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 2 +-
drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c | 8
drivers/gpu/drm/msm/msm_drv.h | 3 +--
3 files changed, 6 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index c989621209aa..fc9a9f544110 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -964,7 +964,7 @@ static int dpu_plane_atomic_check(struct drm_plane *plane,
crtc_state = drm_atomic_get_new_crtc_state(state,
new_plane_state->crtc);
- min_scale = FRAC_16_16(1, pdpu->pipe_sblk->maxupscale);
+ min_scale = drm_fixed_16_16(1, pdpu->pipe_sblk->maxupscale);
ret = drm_atomic_helper_check_plane_state(new_plane_state, crtc_state,
min_scale,
pdpu->pipe_sblk->maxdwnscale
<< 16,
diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c
index c6b69afcbac8..079b0662ee3c 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c
@@ -199,8 +199,8 @@ static int mdp5_plane_atomic_check_with_state(struct
drm_crtc_state *crtc_state,
return -ERANGE;
}
- min_scale = FRAC_16_16(1, 8);
- max_scale = FRAC_16_16(8, 1);
+ min_scale = drm_fixed_16_16(1, 8);
+ max_scale = drm_fixed_16_16(8, 1);
ret = drm_atomic_helper_check_plane_state(state, crtc_state,
min_scale, max_scale,
@@ -381,8 +381,8 @@ static int mdp5_plane_atomic_async_check(struct drm_plane
*plane,
plane->state->fb != new_plane_state->fb)
return -EINVAL;
- min_scale = FRAC_16_16(1, 8);
- max_scale = FRAC_16_16(8, 1);
+ min_scale = drm_fixed_16_16(1, 8);
+ max_scale = drm_fixed_16_16(8, 1);
ret = drm_atomic_helper_check_plane_state(new_plane_state, crtc_state,
min_scale, max_scale,
diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
index 8b005d1ac899..b5aa94024a42 100644
--- a/drivers/gpu/drm/msm/msm_drv.h
+++ b/drivers/gpu/drm/msm/msm_drv.h
@@ -32,6 +32,7 @@
#include
#include
#include
+#include
struct msm_kms;
struct msm_gpu;
@@ -51,8 +52,6 @@ struct msm_disp_state;
#define MAX_BRIDGES8
#define MAX_CONNECTORS 8
-#define FRAC_16_16(mult, div)(((mult) << 16) / (div))
-
struct msm_file_private {
rwlock_t queuelock;
struct list_head submitqueues;
--
2.30.2
[PATCH 4/5] drm/rockchip: Use common drm_fixed_16_16 helper
Replace our open-coded FRAC_16_16 with the common drm_fixed_16_16
helper to reduce code duplication between drivers.
Signed-off-by: Alyssa Rosenzweig
Cc: linux-rockc...@lists.infradead.org
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 9 +
drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 1 -
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index ba9e14da41b4..9428fcba400f 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -29,6 +29,7 @@
#include
#include
#include
+#include
#ifdef CONFIG_DRM_ANALOGIX_DP
#include
@@ -789,9 +790,9 @@ static int vop_plane_atomic_check(struct drm_plane *plane,
struct vop_win *vop_win = to_vop_win(plane);
const struct vop_win_data *win = vop_win->data;
int ret;
- int min_scale = win->phy->scl ? FRAC_16_16(1, 8) :
+ int min_scale = win->phy->scl ? drm_fixed_16_16(1, 8) :
DRM_PLANE_HELPER_NO_SCALING;
- int max_scale = win->phy->scl ? FRAC_16_16(8, 1) :
+ int max_scale = win->phy->scl ? drm_fixed_16_16(8, 1) :
DRM_PLANE_HELPER_NO_SCALING;
if (!crtc || WARN_ON(!fb))
@@ -1037,9 +1038,9 @@ static int vop_plane_atomic_async_check(struct drm_plane
*plane,
plane);
struct vop_win *vop_win = to_vop_win(plane);
const struct vop_win_data *win = vop_win->data;
- int min_scale = win->phy->scl ? FRAC_16_16(1, 8) :
+ int min_scale = win->phy->scl ? drm_fixed_16_16(1, 8) :
DRM_PLANE_HELPER_NO_SCALING;
- int max_scale = win->phy->scl ? FRAC_16_16(8, 1) :
+ int max_scale = win->phy->scl ? drm_fixed_16_16(8, 1) :
DRM_PLANE_HELPER_NO_SCALING;
struct drm_crtc_state *crtc_state;
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
index 857d97cdc67c..cada12e653cc 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
@@ -335,7 +335,6 @@ enum vop_pol {
DEN_NEGATIVE = 2
};
-#define FRAC_16_16(mult, div)(((mult) << 16) / (div))
#define SCL_FT_DEFAULT_FIXPOINT_SHIFT 12
#define SCL_MAX_VSKIPLINES 4
#define MIN_SCL_FT_AFTER_VSKIP 1
--
2.30.2
[PATCH 5/5] drm/zte: Use common drm_fixed_16_16 helper
Replace our open-coded FRAC_16_16 with the common drm_fixed_16_16
helper to reduce code duplication between drivers.
Signed-off-by: Alyssa Rosenzweig
---
drivers/gpu/drm/zte/zx_plane.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/zte/zx_plane.c b/drivers/gpu/drm/zte/zx_plane.c
index 93bcca428e35..80f61d79be83 100644
--- a/drivers/gpu/drm/zte/zx_plane.c
+++ b/drivers/gpu/drm/zte/zx_plane.c
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
#include "zx_common_regs.h"
#include "zx_drm_drv.h"
@@ -43,8 +44,6 @@ static const uint32_t vl_formats[] = {
*/
};
-#define FRAC_16_16(mult, div)(((mult) << 16) / (div))
-
static int zx_vl_plane_atomic_check(struct drm_plane *plane,
struct drm_atomic_state *state)
{
@@ -53,8 +52,8 @@ static int zx_vl_plane_atomic_check(struct drm_plane *plane,
struct drm_framebuffer *fb = plane_state->fb;
struct drm_crtc *crtc = plane_state->crtc;
struct drm_crtc_state *crtc_state;
- int min_scale = FRAC_16_16(1, 8);
- int max_scale = FRAC_16_16(8, 1);
+ int min_scale = drm_fixed_16_16(1, 8);
+ int max_scale = drm_fixed_16_16(8, 1);
if (!crtc || WARN_ON(!fb))
return 0;
--
2.30.2
Re: [git pull] drm for 5.15-rc1
On Mon, Aug 30, 2021 at 10:53 PM Dave Airlie wrote: > > There are a bunch of conflicts with your tree, but none of them seem > too serious, but I might have missed something. No worries. I enjoyed seeing the AMD code-names in the conflicts, they are using positively kernel-level naming. That said, I wonder why AMD people can't use consistent formatting, mixing ALL-CAPS with underscores, spaces, whatever: /* Sienna_Cichlid */ /* Yellow Carp */ /* Navy_Flounder */ /* DIMGREY_CAVEFISH */ /* Aldebaran */ /* CYAN_SKILLFISH */ /* BEIGE_GOBY */ which shows a distinct lack of professionalism and caring in the silly naming. Linus
[PATCH 1/3] drm/msm/dpu1: Add DMA2, DMA3 clock control to enum
The enum dpu_clk_ctrl_type misses DPU_CLK_CTRL_DMA{2,3} even though
this driver does actually handle both, if present: add the two in
preparation for adding support for SoCs having them.
Signed-off-by: AngeloGioacchino Del Regno
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
index d2a945a27cfa..059e1402b7d0 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
@@ -432,6 +432,8 @@ enum dpu_clk_ctrl_type {
DPU_CLK_CTRL_RGB3,
DPU_CLK_CTRL_DMA0,
DPU_CLK_CTRL_DMA1,
+ DPU_CLK_CTRL_DMA2,
+ DPU_CLK_CTRL_DMA3,
DPU_CLK_CTRL_CURSOR0,
DPU_CLK_CTRL_CURSOR1,
DPU_CLK_CTRL_INLINE_ROT0_SSPP,
--
2.32.0
[PATCH 2/3] drm/msm/dpu1: Add MSM8998 to hw catalog
Bringup functionality for MSM8998 in the DPU, driver which is mostly
the same as SDM845 (just a few variations).
Signed-off-by: AngeloGioacchino Del Regno
---
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 335 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 1 +
drivers/gpu/drm/msm/msm_drv.c | 1 +
3 files changed, 326 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
index b131fd376192..f2cc715af782 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -16,6 +16,9 @@
BIT(DPU_SSPP_CSC_10BIT) | BIT(DPU_SSPP_CDP) |\
BIT(DPU_SSPP_TS_PREFILL) | BIT(DPU_SSPP_EXCL_RECT))
+#define VIG_MSM8998_MASK \
+ (VIG_MASK | BIT(DPU_SSPP_SCALER_QSEED3))
+
#define VIG_SDM845_MASK \
(VIG_MASK | BIT(DPU_SSPP_QOS_8LVL) | BIT(DPU_SSPP_SCALER_QSEED3))
@@ -25,6 +28,11 @@
#define VIG_SM8250_MASK \
(VIG_MASK | BIT(DPU_SSPP_QOS_8LVL) | BIT(DPU_SSPP_SCALER_QSEED3LITE))
+#define DMA_MSM8998_MASK \
+ (BIT(DPU_SSPP_SRC) | BIT(DPU_SSPP_QOS) |\
+ BIT(DPU_SSPP_TS_PREFILL) | BIT(DPU_SSPP_TS_PREFILL_REC1) |\
+ BIT(DPU_SSPP_CDP) | BIT(DPU_SSPP_EXCL_RECT))
+
#define DMA_SDM845_MASK \
(BIT(DPU_SSPP_SRC) | BIT(DPU_SSPP_QOS) | BIT(DPU_SSPP_QOS_8LVL) |\
BIT(DPU_SSPP_TS_PREFILL) | BIT(DPU_SSPP_TS_PREFILL_REC1) |\
@@ -33,6 +41,9 @@
#define DMA_CURSOR_SDM845_MASK \
(DMA_SDM845_MASK | BIT(DPU_SSPP_CURSOR))
+#define DMA_CURSOR_MSM8998_MASK \
+ (DMA_MSM8998_MASK | BIT(DPU_SSPP_CURSOR))
+
#define MIXER_SDM845_MASK \
(BIT(DPU_MIXER_SOURCESPLIT) | BIT(DPU_DIM_LAYER))
@@ -49,6 +60,8 @@
#define MERGE_3D_SM8150_MASK (0)
+#define DSPP_MSM8998_MASK (BIT(DPU_DSPP_PCC) | BIT(DPU_DSPP_GC))
+
#define DSPP_SC7180_MASK BIT(DPU_DSPP_PCC)
#define INTF_SDM845_MASK (0)
@@ -181,6 +194,22 @@ static const uint32_t plane_formats_yuv[] = {
* DPU sub blocks config
*/
/* DPU top level caps */
+static const struct dpu_caps msm8998_dpu_caps = {
+ .max_mixer_width = DEFAULT_DPU_OUTPUT_LINE_WIDTH,
+ .max_mixer_blendstages = 0x7,
+ .qseed_type = DPU_SSPP_SCALER_QSEED3,
+ .smart_dma_rev = DPU_SSPP_SMART_DMA_V1,
+ .ubwc_version = DPU_HW_UBWC_VER_10,
+ .has_src_split = true,
+ .has_dim_layer = true,
+ .has_idle_pc = true,
+ .has_3d_merge = true,
+ .max_linewidth = DEFAULT_DPU_OUTPUT_LINE_WIDTH,
+ .pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
+ .max_hdeci_exp = MAX_HORZ_DECIMATION,
+ .max_vdeci_exp = MAX_VERT_DECIMATION,
+};
+
static const struct dpu_caps sdm845_dpu_caps = {
.max_mixer_width = DEFAULT_DPU_OUTPUT_LINE_WIDTH,
.max_mixer_blendstages = 0xb,
@@ -251,6 +280,35 @@ static const struct dpu_caps sc7280_dpu_caps = {
.pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
};
+static const struct dpu_mdp_cfg msm8998_mdp[] = {
+ {
+ .name = "top_0", .id = MDP_TOP,
+ .base = 0x0, .len = 0x458,
+ .features = 0,
+ .highest_bank_bit = 0x2,
+ .clk_ctrls[DPU_CLK_CTRL_VIG0] = {
+ .reg_off = 0x2AC, .bit_off = 0},
+ .clk_ctrls[DPU_CLK_CTRL_VIG1] = {
+ .reg_off = 0x2B4, .bit_off = 0},
+ .clk_ctrls[DPU_CLK_CTRL_VIG2] = {
+ .reg_off = 0x2BC, .bit_off = 0},
+ .clk_ctrls[DPU_CLK_CTRL_VIG3] = {
+ .reg_off = 0x2C4, .bit_off = 0},
+ .clk_ctrls[DPU_CLK_CTRL_DMA0] = {
+ .reg_off = 0x2AC, .bit_off = 8},
+ .clk_ctrls[DPU_CLK_CTRL_DMA1] = {
+ .reg_off = 0x2B4, .bit_off = 8},
+ .clk_ctrls[DPU_CLK_CTRL_DMA2] = {
+ .reg_off = 0x2C4, .bit_off = 8},
+ .clk_ctrls[DPU_CLK_CTRL_DMA3] = {
+ .reg_off = 0x2C4, .bit_off = 12},
+ .clk_ctrls[DPU_CLK_CTRL_CURSOR0] = {
+ .reg_off = 0x3A8, .bit_off = 15},
+ .clk_ctrls[DPU_CLK_CTRL_CURSOR1] = {
+ .reg_off = 0x3B0, .bit_off = 15},
+ },
+};
+
static const struct dpu_mdp_cfg sdm845_mdp[] = {
{
.name = "top_0", .id = MDP_TOP,
@@ -339,6 +397,39 @@ static const struct dpu_mdp_cfg sc7280_mdp[] = {
/*
* CTL sub blocks config
*/
+static const struct dpu_ctl_cfg msm8998_ctl[] = {
+ {
+ .name = "ctl_0", .id = CTL_0,
+ .base = 0x1000, .len = 0x94,
+ .features = BIT(DPU_CTL_SPLIT_DISPLAY),
+ .intr_start = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 9),
+ },
+ {
+ .name = "ctl_1", .id = CTL_1,
+ .base = 0x1200, .len = 0x94,
+ .features = 0,
+ .intr_start = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 10),
+ },
+ {
+ .n
[PATCH 3/3] dt-bindings: display: msm: Add binding for msm8998 dpu
Add yaml binding for msm8998 dpu1 support.
Signed-off-by: AngeloGioacchino Del Regno
---
.../bindings/display/msm/dpu-msm8998.yaml | 220 ++
1 file changed, 220 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/msm/dpu-msm8998.yaml
diff --git a/Documentation/devicetree/bindings/display/msm/dpu-msm8998.yaml
b/Documentation/devicetree/bindings/display/msm/dpu-msm8998.yaml
new file mode 100644
index ..db435342ecbf
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/msm/dpu-msm8998.yaml
@@ -0,0 +1,220 @@
+# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/msm/dpu-msm8998.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Display DPU dt properties for MSM8998 target
+
+maintainers:
+ - AngeloGioacchino Del Regno
+
+description: |
+ Device tree bindings for MSM Mobile Display Subsystem(MDSS) that encapsulates
+ sub-blocks like DPU display controller, DSI and DP interfaces etc. Device
tree
+ bindings of MDSS and DPU are mentioned for MSM8998 target.
+
+properties:
+ compatible:
+items:
+ - const: qcom,msm8998-mdss
+
+ reg:
+maxItems: 1
+
+ reg-names:
+const: mdss
+
+ power-domains:
+maxItems: 1
+
+ clocks:
+items:
+ - description: Display AHB clock
+ - description: Display AXI clock
+ - description: Display core clock
+
+ clock-names:
+items:
+ - const: iface
+ - const: bus
+ - const: core
+
+ interrupts:
+maxItems: 1
+
+ interrupt-controller: true
+
+ "#address-cells": true
+
+ "#size-cells": true
+
+ "#interrupt-cells":
+const: 1
+
+ iommus:
+items:
+ - description: Phandle to apps_smmu node with SID mask for Hard-Fail
port0
+
+ ranges: true
+
+patternProperties:
+ "^display-controller@[0-9a-f]+$":
+type: object
+description: Node containing the properties of DPU.
+
+properties:
+ compatible:
+items:
+ - const: qcom,msm8998-dpu
+
+ reg:
+items:
+ - description: Address offset and size for mdp register set
+ - description: Address offset and size for regdma register set
+ - description: Address offset and size for vbif register set
+ - description: Address offset and size for non-realtime vbif
register set
+
+ reg-names:
+items:
+ - const: mdp
+ - const: regdma
+ - const: vbif
+ - const: vbif_nrt
+
+ clocks:
+items:
+ - description: Display ahb clock
+ - description: Display axi clock
+ - description: Display mem-noc clock
+ - description: Display core clock
+ - description: Display vsync clock
+
+ clock-names:
+items:
+ - const: iface
+ - const: bus
+ - const: mnoc
+ - const: core
+ - const: vsync
+
+ interrupts:
+maxItems: 1
+
+ power-domains:
+maxItems: 1
+
+ operating-points-v2: true
+ ports:
+$ref: /schemas/graph.yaml#/properties/ports
+description: |
+ Contains the list of output ports from DPU device. These ports
+ connect to interfaces that are external to the DPU hardware,
+ such as DSI, DP etc. Each output port contains an endpoint that
+ describes how it is connected to an external interface.
+
+properties:
+ port@0:
+$ref: /schemas/graph.yaml#/properties/port
+description: DPU_INTF1 (DSI1)
+
+ port@1:
+$ref: /schemas/graph.yaml#/properties/port
+description: DPU_INTF2 (DSI2)
+
+required:
+ - port@0
+ - port@1
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - clocks
+ - interrupts
+ - power-domains
+ - operating-points-v2
+ - ports
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - power-domains
+ - clocks
+ - interrupts
+ - interrupt-controller
+ - iommus
+ - ranges
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+#include
+
+display-subsystem@c90 {
+compatible = "qcom,msm8998-mdss";
+reg = <0x0c90 0x1000>;
+reg-names = "mdss";
+
+clocks = <&mmcc MDSS_AHB_CLK>,
+ <&mmcc MDSS_AXI_CLK>,
+ <&mmcc MDSS_MDP_CLK>;
+clock-names = "iface", "bus", "core";
+
+#address-cells = <1>;
+#interrupt-cells = <1>;
+#size-cells = <1>;
+
+interrupts = ;
+interrupt-controller;
+iommus = <&mmss_smmu 0>;
+
+power-domains = <&mmcc MDSS_GDSC>;
+ranges;
+status = "disabled";
+
+display-controller@c901000 {
+compatible = "qcom,msm8998-dpu";
+reg = <0x0c901000 0x8f000>,
+ <0x0c9a8e00 0xf0>,
+ <0x0c9b 0x2008>,
+
Re: [PATCH 1/5] drm: Add drm_fixed_16_16 helper
Hi Alyssa,
Thank you for the patch.
On Wed, Sep 01, 2021 at 01:54:27PM -0400, Alyssa Rosenzweig wrote:
> This constructs a fixed 16.16 rational, useful to specify the minimum
> and maximum scaling in drm_atomic_helper_check_plane_state. It is
> open-coded as a macro in multiple drivers, so let's share the helper.
>
> Signed-off-by: Alyssa Rosenzweig
> ---
> include/drm/drm_fixed.h | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/include/drm/drm_fixed.h b/include/drm/drm_fixed.h
> index 553210c02ee0..df1f369b4918 100644
> --- a/include/drm/drm_fixed.h
> +++ b/include/drm/drm_fixed.h
> @@ -208,4 +208,9 @@ static inline s64 drm_fixp_exp(s64 x)
> return sum;
> }
>
Missing documentation :-)
> +static inline int drm_fixed_16_16(s32 mult, s32 div)
You should return a s32.
The function name isn't very explicit, and departs from the naming
scheme of other functions in the same file. As fixed-point numbers are
stored in a s64 for the drm_fixp_* helpers, we shouldn't rese the
drm_fixp_ prefix, maybe drm_fixp_s16_16_ would be a good prefix. The
function should probably be named drm_fixp_s16_16 from_fraction() then,
but then the same logic should possibly be replicated to ensure optimal
precision. I wonder if it wouldn't be best to simply use
drm_fixp_from_fraction() and shift the result right by 16 bits.
> +{
> + return (mult << 16) / div;
> +}
> +
> #endif
--
Regards,
Laurent Pinchart
Re: [git pull] drm for 5.15-rc1
On Wed, Sep 1, 2021 at 10:57 AM Linus Torvalds
wrote:
>
> No worries. I enjoyed seeing the AMD code-names in the conflicts, they
> are using positively kernel-level naming.
Oh, I spoke too soon.
The conflict in amdgpu_ras_eeprom.c is trivial to fix up, but the
*code* is garbage.
It does this (from commit 14fb496a84f1: "drm/amdgpu: set RAS EEPROM
address from VBIOS"):
...
control->i2c_address = 0;
if (amdgpu_atomfirmware_ras_rom_addr(adev,
(uint8_t*)&control->i2c_address))
{
if (control->i2c_address == 0xA0)
control->i2c_address = 0;
...
and honestly, that just hurts to look at. It's completely wrong, even
if it happens to work on a little-endian machine.
Yes, yes, BE is irrelevant, and doubly so for an AMD GPU driver, but still.
It's assigning a 8-bit value to a 32-bit entity by doing a pointer
cast on the address, and then mixing things up by using/assigning to
that same field.
That's just *wrong* and nasty.
Oh, the resolution would be easy - just take that broken code as-is -
but I can't actually make myself do that.
So I fixed it up to not be that incredibly ugly garbage.
Please holler if I did something wrong.
Linus
Re: [git pull] drm for 5.15-rc1
The pull request you sent on Tue, 31 Aug 2021 15:53:10 +1000: > git://anongit.freedesktop.org/drm/drm tags/drm-next-2021-08-31-1 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/477f70cd2a67904e04c2c2b9bd0fa2e95222f2f6 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [diagnostic TDR mode patches] unify our solution opinions/suggestions in one thread
On Thu, 2 Sept 2021 at 01:20, Alex Deucher wrote: > > On Wed, Sep 1, 2021 at 6:19 AM Liu, Monk wrote: > > > > [AMD Official Use Only] > > > > Daniel > > > > From the link you share it looks you(or someone else) have quite a bunch > > patches that changes DRM_SCHED or even amdgpu, by that case before they are > > merged to kernel tree I'm wondering if any AMD develop reviewed them ? > > > > They looks to me somehow conflicting with what we changed in our repo > > > > It is really a chaos for AMDer if someone else out side of AMD changes our > > kernel driver (or/and scheduler) without reviewed by AMDer, just like we > > are requiring your review if we tend to change scheduler's logic here > > > > This one changes AMD's code: > > https://lore.kernel.org/dri-devel/20210625133327.2598825-2-boris.brezil...@collabora.com/ > > And I didn't see any reviewed-by from AMDers ... > > > > This one also touches AMD's code: > > https://lore.kernel.org/dri-devel/20200604081224.863494-12-daniel.vet...@ffwll.ch/ > > Which is conflicting with one patch we submitted (in our repo rightnow), > > and neither see AMDder gave a review-by on this one (let me know if I > > missed it) > > > > Monk, this is not how upstream works. You need to participate. > That's how communities work. There's a reason all these discussions > happen on public mailing lists. The patch author can't be expected to > know every person on every vendor team to CC with a patch. If you > have concerns, you need to raise them when the patches are being > discussed. > I'm not sure I can add much to help this along, I'm sure Alex has some internal training, Once your driver is upstream, it belongs to upstream, you can maintain it, but you no longer control it 100%, it's a tradeoff, it's not one companies always understand. Usually people are fine developing away internally, but once interaction with other parts of the kernel/subsystem is required they have the realisation that they needed to work upstream 6 months earlier. The best time to interact with upstream was 6 months ago, the second best time is now. Dave.
Re: [git pull] drm for 5.15-rc1
On Wed, Sep 1, 2021 at 2:33 PM Linus Torvalds
wrote:
>
> On Wed, Sep 1, 2021 at 10:57 AM Linus Torvalds
> wrote:
> >
> > No worries. I enjoyed seeing the AMD code-names in the conflicts, they
> > are using positively kernel-level naming.
>
> Oh, I spoke too soon.
>
> The conflict in amdgpu_ras_eeprom.c is trivial to fix up, but the
> *code* is garbage.
>
> It does this (from commit 14fb496a84f1: "drm/amdgpu: set RAS EEPROM
> address from VBIOS"):
>
> ...
> control->i2c_address = 0;
>
> if (amdgpu_atomfirmware_ras_rom_addr(adev,
> (uint8_t*)&control->i2c_address))
> {
> if (control->i2c_address == 0xA0)
> control->i2c_address = 0;
> ...
>
> and honestly, that just hurts to look at. It's completely wrong, even
> if it happens to work on a little-endian machine.
>
> Yes, yes, BE is irrelevant, and doubly so for an AMD GPU driver, but still.
>
> It's assigning a 8-bit value to a 32-bit entity by doing a pointer
> cast on the address, and then mixing things up by using/assigning to
> that same field.
>
> That's just *wrong* and nasty.
>
> Oh, the resolution would be easy - just take that broken code as-is -
> but I can't actually make myself do that.
>
> So I fixed it up to not be that incredibly ugly garbage.
>
> Please holler if I did something wrong.
Fix looks good. Thanks,
Alex
Re: [PATCH] dt-bindings: display: add missing simple-framebuffer formats
Hi Rob, On Dienstag, 31. August 2021 23:30:15 CEST Rob Herring wrote: > On Sat, Aug 28, 2021 at 01:02:05PM +0200, Luca Weiss wrote: > > Document all formats currently present in include/linux/platform_data/ > > simplefb.h > > > > Signed-off-by: Luca Weiss > > --- > > > > .../bindings/display/simple-framebuffer.yaml | 12 > > 1 file changed, 12 insertions(+) > > > > diff --git > > a/Documentation/devicetree/bindings/display/simple-framebuffer.yaml > > b/Documentation/devicetree/bindings/display/simple-framebuffer.yaml index > > c2499a7906f5..c1acd2859ae8 100644 > > --- a/Documentation/devicetree/bindings/display/simple-framebuffer.yaml > > +++ b/Documentation/devicetree/bindings/display/simple-framebuffer.yaml > > > > @@ -83,13 +83,25 @@ properties: > >format: > > description: > > > > >Format of the framebuffer: > > +* `a1r5g5b5` - 16-bit pixels, d[15]=a, d[14:10]=r, d[9:5]=g, > > d[4:0]=b +* `a2r10g10b10` - 32-bit pixels, d[31:30]=a, > > d[29:20]=r, d[19:10]=g, d[9:0]=b > Not a new problem, but are these 32-bit big or little endian words? That > should be figured out before we add more. As I'm neither involved in the driver nor really have any knowledge on pixel formats, maybe the maintainers of the binding can help out here? (Bartlomiej Zolnierkiewicz & Hans de Goede, both are CC'ed) I can probably dig through the sources and guess but documentation should be written without guessing :) Regards Luca
VKMS: New plane formats
Hi, I'm working to add new plane formats to vkms. But I don't know what should be the behavior in the situation that we received multiple planes with different formats from the users-space. For example, if the user chooses: - DRM_FORMAT_ARGB16161616 to the primary plane - DRM_FORMAT_ARGB to the cursor - DRM_FORMAT_YUV42 to the overlay What should be the output format that will be used to calculate the crc? DRM_FORMAT_ARGB16161616? My idea was to convert all the planes to the primary, but I'm not sure if it is the right approach. Best regards, --- Igor M. A. Torrente
[PATCH v3 00/16] eDP: Support probing eDP panels dynamically instead of hardcoding
The goal of this patch series is to move away from hardcoding exact
eDP panels in device tree files. As discussed in the various patches
in this series (I'm not repeating everything here), most eDP panels
are 99% probable and we can get that last 1% by allowing two "power
up" delays to be specified in the device tree file and then using the
panel ID (found in the EDID) to look up additional power sequencing
delays for the panel.
This patch series is the logical contiunation of a previous patch
series where I proposed solving this problem by adding a
board-specific compatible string [1]. In the discussion that followed
it sounded like people were open to something like the solution
proposed in this new series.
In version 2 I got rid of the idea that we could have a "fallback"
compatible string that we'd use if we didn't recognize the ID in the
EDID. This simplifies the bindings a lot and the implementation
somewhat. As a result of not having a "fallback", though, I'm not
confident in transitioning any existing boards over to this since
we'll have to fallback to very conservative timings if we don't
recognize the ID from the EDID and I can't guarantee that I've seen
every panel that might have shipped on an existing product. The plan
is to use "edp-panel" only on new boards or new revisions of old
boards where we can guarantee that every EDID that ships out of the
factory has an ID in the table.
Version 3 of this series now splits out all eDP panels to their own
driver and adds the generic eDP panel support to this new driver. I
believe this is what Sam was looking for [2].
[1] https://lore.kernel.org/r/yfkqaxomowyye...@google.com/
[2] https://lore.kernel.org/r/yrtsfntn%2ft8fl...@ravnborg.org/
Changes in v3:
- Decode hex product ID w/ same endianness as everyone else.
- ("Reorder logicpd_type_28...") patch new for v3.
- Split eDP panels patch new for v3.
- Move wayward panels patch new for v3.
- ("Non-eDP panels don't need "HPD" handling") new for v3.
- Split the delay structure out patch just on eDP now.
- ("Better describe eDP panel delays") new for v3.
- Fix "prepare_to_enable" patch new for v3.
- ("Don't re-read the EDID every time") moved to eDP only patch.
- Generic "edp-panel" handled by the eDP panel driver now.
- Change init order to we power at the end.
- Adjust endianness of product ID.
- Fallback to conservative delays if panel not recognized.
- Add Sharp LQ116M1JW10 to table.
- Add AUO B116XAN06.1 to table.
- Rename delays more generically so they can be reused.
Changes in v2:
- No longer allow fallback to panel-simple.
- Add "-ms" suffix to delays.
- Don't support a "fallback" panel. Probed panels must be probed.
- Not based on patch to copy "desc"--just allocate for probed panels.
- Add "-ms" suffix to delays.
Douglas Anderson (16):
dt-bindings: drm/panel-simple-edp: Introduce generic eDP panels
drm/edid: Break out reading block 0 of the EDID
drm/edid: Allow the querying/working with the panel ID from the EDID
drm/panel-simple: Reorder logicpd_type_28 / mitsubishi_aa070mc01
drm/panel-simple-edp: Split eDP panels out of panel-simple
ARM: configs: Everyone who had PANEL_SIMPLE now gets PANEL_SIMPLE_EDP
arm64: defconfig: Everyone who had PANEL_SIMPLE now gets
PANEL_SIMPLE_EDP
MIPS: configs: Everyone who had PANEL_SIMPLE now gets PANEL_SIMPLE_EDP
drm/panel-simple-edp: Move some wayward panels to the eDP driver
drm/panel-simple: Non-eDP panels don't need "HPD" handling
drm/panel-simple-edp: Split the delay structure out
drm/panel-simple-edp: Better describe eDP panel delays
drm/panel-simple-edp: hpd_reliable shouldn't be subtraced from
hpd_absent
drm/panel-simple-edp: Fix "prepare_to_enable" if panel doesn't handle
HPD
drm/panel-simple-edp: Don't re-read the EDID every time we power off
the panel
drm/panel-simple-edp: Implement generic "edp-panel"s probed by EDID
.../bindings/display/panel/panel-edp.yaml | 188 ++
arch/arm/configs/at91_dt_defconfig|1 +
arch/arm/configs/exynos_defconfig |1 +
arch/arm/configs/imx_v6_v7_defconfig |1 +
arch/arm/configs/lpc32xx_defconfig|1 +
arch/arm/configs/multi_v5_defconfig |1 +
arch/arm/configs/multi_v7_defconfig |1 +
arch/arm/configs/omap2plus_defconfig |1 +
arch/arm/configs/qcom_defconfig |1 +
arch/arm/configs/realview_defconfig |1 +
arch/arm/configs/sama5_defconfig |1 +
arch/arm/configs/shmobile_defconfig |1 +
arch/arm/configs/sunxi_defconfig |1 +
arch/arm/configs/tegra_defconfig |1 +
arch/arm/configs/versatile_defconfig |1 +
arch/arm/configs/vexpress_defconfig |1 +
arch/arm64/configs/defconfig |1 +
arch/mips/configs/qi_lb60_defconfig |1 +
arch/mips/configs/rs90_defconfig |1 +
drivers/gpu/drm/drm_edid.c
[PATCH v3 01/16] dt-bindings: drm/panel-simple-edp: Introduce generic eDP panels
eDP panels generally contain almost everything needed to control them in their EDID. This comes from their DP heritage were a computer needs to be able to properly control pretty much any DP display that's plugged into it. The one big issue with eDP panels and the reason that we need a panel driver for them is that the power sequencing can be different per panel. While it is true that eDP panel sequencing can be arbitrarily complex, in practice it turns out that many eDP panels are compatible with just some slightly different delays. See the contents of the bindings file introduced in this patch for some details. The fact that eDP panels are 99% probable and that the power sequencing (especially power up) can be compatible between many panels means that there's a constant desire to plug multiple different panels into the same board. This could be for second sourcing purposes or to support multiple SKUs (maybe a 11" and a 13", for instance). As discussed [1], it should be OK to support this by adding two properties to the device tree to specify the delays needed for powering up the panel the first time. We'll create a new "edp-panel" bindings file and define the two delays that might need to be specified. NOTE: in the vast majority of the cases (HPD is hooked up and isn't glitchy or is debounced) even these delays aren't needed. [1] https://lore.kernel.org/r/CAD=FV=vzyompwqzzwdhjgh5cjjww_ecm-wqveivz-bdgxjp...@mail.gmail.com Signed-off-by: Douglas Anderson Reviewed-by: Rob Herring --- (no changes since v2) Changes in v2: - No longer allow fallback to panel-simple. - Add "-ms" suffix to delays. .../bindings/display/panel/panel-edp.yaml | 188 ++ 1 file changed, 188 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/panel-edp.yaml diff --git a/Documentation/devicetree/bindings/display/panel/panel-edp.yaml b/Documentation/devicetree/bindings/display/panel/panel-edp.yaml new file mode 100644 index ..6a621376ff86 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/panel-edp.yaml @@ -0,0 +1,188 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/panel-edp.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Probable (via DP AUX / EDID) eDP Panels with simple poweron sequences + +maintainers: + - Douglas Anderson + +description: | + This binding file can be used to indicate that an eDP panel is connected + to a Embedded DisplayPort AUX bus (see display/dp-aux-bus.yaml) without + actually specifying exactly what panel is connected. This is useful for + the case that more than one different panel could be connected to the + board, either for second-sourcing purposes or to support multiple SKUs + with different LCDs that hook up to a common board. + + As per above, a requirement for using this binding is that the panel is + represented under the DP AUX bus. This means that we can use any + information provided by the DP AUX bus (including the EDID) to identify + the panel. We can use this to identify display size, resolution, and + timings among other things. + + One piece of information about eDP panels that is typically _not_ + provided anywhere on the DP AUX bus is the power sequencing timings. + This is the reason why, historically, we've always had to explicitly + list eDP panels. We solve that here with two tricks. The "worst case" + power on timings for any panels expected to be connected to a board are + specified in these bindings. Once we've powered on, it's expected that + the operating system will lookup the panel in a table (based on EDID + information) to figure out other power sequencing timings. + + eDP panels in general can have somewhat arbitrary power sequencing + requirements. However, even though it's arbitrary in general, the + vast majority of panel datasheets have a power sequence diagram that + looks the exactly the same as every other panel. Each panel datasheet + cares about different timings in this diagram but the fact that the + diagram is so similar means we can come up with a single driver to + handle it. + + These diagrams all look roughly like this, sometimes labeled with + slightly different numbers / lines but all pretty much the same + sequence. This is because much of this diagram comes straight from + the eDP Standard. + +__ + Vdd ___/::\ / + _/:: \_/ + ::: :<--T10-->::: +:+---+-+-+ + eDP ---+ Black video | Src vid | Blk vid + + Display :+---+-+-+ +: ___:_
