* [PATCH v1, 1/3] mtk-vcodec: Support MT8186
From: Yunfei Dong @ 2022-01-22 7:56 UTC (permalink / raw)
To: Yunfei Dong, Alexandre Courbot, Hans Verkuil, Tzung-Bi Shih,
Tiffany Lin, Andrew-CT Chen, Mauro Carvalho Chehab, Rob Herring,
Matthias Brugger, Tomasz Figa
Cc: George Sun, Xiaoyong Lu, Hsin-Yi Wang, Fritz Koenig,
Dafna Hirschfeld, Benjamin Gaignard, Daniel Vetter, dri-devel,
Irui Wang, AngeloGioacchino Del Regno, Steve Cho, linux-media,
devicetree, linux-kernel, linux-arm-kernel, srv_heupstream,
linux-mediatek, Project_Global_Chrome_Upstream_Group
In-Reply-To: <20220122075606.19373-1-yunfei.dong@mediatek.com>
Adds MT8186's compatible "mediatek,mt8186-vcodec-dec".
Adds MT8186's device private data mtk_vdec_single_core_pdata.
Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com>
---
.../platform/mtk-vcodec/mtk_vcodec_dec.h | 1 +
.../platform/mtk-vcodec/mtk_vcodec_dec_drv.c | 4 ++++
.../mtk-vcodec/mtk_vcodec_dec_stateless.c | 19 +++++++++++++++++++
3 files changed, 24 insertions(+)
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.h b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.h
index 66cd6d2242c3..4572f92826f2 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.h
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.h
@@ -69,6 +69,7 @@ extern const struct media_device_ops mtk_vcodec_media_ops;
extern const struct mtk_vcodec_dec_pdata mtk_vdec_8173_pdata;
extern const struct mtk_vcodec_dec_pdata mtk_vdec_8183_pdata;
extern const struct mtk_vcodec_dec_pdata mtk_lat_sig_core_pdata;
+extern const struct mtk_vcodec_dec_pdata mtk_vdec_single_core_pdata;
/*
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 6b52eaeedafa..2d21d0010c9c 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c
@@ -464,6 +464,10 @@ static const struct of_device_id mtk_vcodec_match[] = {
.compatible = "mediatek,mt8192-vcodec-dec",
.data = &mtk_lat_sig_core_pdata,
},
+ {
+ .compatible = "mediatek,mt8186-vcodec-dec",
+ .data = &mtk_vdec_single_core_pdata,
+ },
{},
};
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 3770e8117488..4b83f00a8857 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_stateless.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_stateless.c
@@ -522,3 +522,22 @@ const struct mtk_vcodec_dec_pdata mtk_lat_sig_core_pdata = {
.is_subdev_supported = true,
.hw_arch = MTK_VDEC_LAT_SINGLE_CORE,
};
+
+const struct mtk_vcodec_dec_pdata mtk_vdec_single_core_pdata = {
+ .init_vdec_params = mtk_init_vdec_params,
+ .ctrls_setup = mtk_vcodec_dec_ctrls_setup,
+ .vdec_vb2_ops = &mtk_vdec_request_vb2_ops,
+ .vdec_formats = mtk_video_formats,
+ .num_formats = &num_formats,
+ .default_out_fmt = &default_out_format,
+ .default_cap_fmt = &default_cap_format,
+ .vdec_framesizes = mtk_vdec_framesizes,
+ .num_framesizes = &num_framesizes,
+ .uses_stateless_api = true,
+ .worker = mtk_vdec_worker,
+ .flush_decoder = mtk_vdec_flush_decoder,
+ .cap_to_disp = mtk_vdec_stateless_cap_to_disp,
+ .get_cap_buffer = vdec_get_cap_buffer,
+ .is_subdev_supported = true,
+ .hw_arch = MTK_VDEC_PURE_SINGLE_CORE,
+};
--
2.25.1
^ permalink raw reply related
* [PATCH v1, 0/3] support mt8186 decoder
From: Yunfei Dong @ 2022-01-22 7:56 UTC (permalink / raw)
To: Yunfei Dong, Alexandre Courbot, Hans Verkuil, Tzung-Bi Shih,
Tiffany Lin, Andrew-CT Chen, Mauro Carvalho Chehab, Rob Herring,
Matthias Brugger, Tomasz Figa
Cc: George Sun, Xiaoyong Lu, Hsin-Yi Wang, Fritz Koenig,
Dafna Hirschfeld, Benjamin Gaignard, Daniel Vetter, dri-devel,
Irui Wang, AngeloGioacchino Del Regno, Steve Cho, linux-media,
devicetree, linux-kernel, linux-arm-kernel, srv_heupstream,
linux-mediatek, Project_Global_Chrome_Upstream_Group
Firstly, add mt8186 compatible and private data, then add document for
compatible "mediatek,mt8186-vcodec-dec". For mt8186 is single core
architecture, need to add new interface for h264 hardware decoder.
Patche 1 add mt8186 compatible and private data.
Patche 2 add mt8186 compatible document.
Patche 3 add h264 single core driver.
---
This patch depends on "support for MT8192 decoder"[1]
[1] https://patchwork.kernel.org/project/linux-mediatek/patch/20220122035316.18179-1-yunfei.dong@mediatek.com/
---
Yunfei Dong (3):
mtk-vcodec: Support MT8186
dt-bindings: media: mtk-vcodec: Adds decoder dt-bindings for mt8186
mtk-vcodec: add h264 decoder driver for mt8186
.../media/mediatek,vcodec-subdev-decoder.yaml | 4 +-
.../platform/mtk-vcodec/mtk_vcodec_dec.h | 1 +
.../platform/mtk-vcodec/mtk_vcodec_dec_drv.c | 4 +
.../mtk-vcodec/mtk_vcodec_dec_stateless.c | 19 ++
.../mtk-vcodec/vdec/vdec_h264_req_multi_if.c | 164 ++++++++++++++++++
.../media/platform/mtk-vcodec/vdec_drv_if.c | 5 +-
.../media/platform/mtk-vcodec/vdec_drv_if.h | 1 +
7 files changed, 196 insertions(+), 2 deletions(-)
--
2.25.1
^ permalink raw reply
* [PATCH v1, 3/3] mtk-vcodec: add h264 decoder driver for mt8186
From: Yunfei Dong @ 2022-01-22 7:56 UTC (permalink / raw)
To: Yunfei Dong, Alexandre Courbot, Hans Verkuil, Tzung-Bi Shih,
Tiffany Lin, Andrew-CT Chen, Mauro Carvalho Chehab, Rob Herring,
Matthias Brugger, Tomasz Figa
Cc: George Sun, Xiaoyong Lu, Hsin-Yi Wang, Fritz Koenig,
Dafna Hirschfeld, Benjamin Gaignard, Daniel Vetter, dri-devel,
Irui Wang, AngeloGioacchino Del Regno, Steve Cho, linux-media,
devicetree, linux-kernel, linux-arm-kernel, srv_heupstream,
linux-mediatek, Project_Global_Chrome_Upstream_Group
In-Reply-To: <20220122075606.19373-1-yunfei.dong@mediatek.com>
Add h264 decode driver to support mt8186. For the architecture
is single core, need to add new interface to decode.
Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com>
---
.../mtk-vcodec/vdec/vdec_h264_req_multi_if.c | 164 ++++++++++++++++++
.../media/platform/mtk-vcodec/vdec_drv_if.c | 5 +-
.../media/platform/mtk-vcodec/vdec_drv_if.h | 1 +
3 files changed, 169 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/mtk-vcodec/vdec/vdec_h264_req_multi_if.c b/drivers/media/platform/mtk-vcodec/vdec/vdec_h264_req_multi_if.c
index 1567dbc63e95..5541edbafed2 100644
--- a/drivers/media/platform/mtk-vcodec/vdec/vdec_h264_req_multi_if.c
+++ b/drivers/media/platform/mtk-vcodec/vdec/vdec_h264_req_multi_if.c
@@ -137,6 +137,9 @@ struct vdec_h264_slice_share_info {
* @vsi : vsi used for lat
* @vsi_core : vsi used for core
*
+ * @vsi_ctx : Local VSI data for this decoding context
+ * @h264_slice_param : the parameters that hardware use to decode
+ *
* @resolution_changed : resolution changed
* @realloc_mv_buf : reallocate mv buffer
* @cap_num_planes : number of capture queue plane
@@ -152,6 +155,9 @@ struct vdec_h264_slice_inst {
struct vdec_h264_slice_vsi *vsi;
struct vdec_h264_slice_vsi *vsi_core;
+ struct vdec_h264_slice_vsi vsi_ctx;
+ struct vdec_h264_slice_lat_dec_param h264_slice_param;
+
unsigned int resolution_changed;
unsigned int realloc_mv_buf;
unsigned int cap_num_planes;
@@ -196,6 +202,61 @@ static int vdec_h264_slice_fill_decode_parameters(struct vdec_h264_slice_inst *i
return 0;
}
+static int get_vdec_sig_decode_parameters(struct vdec_h264_slice_inst *inst)
+{
+ const struct v4l2_ctrl_h264_decode_params *dec_params;
+ const struct v4l2_ctrl_h264_sps *sps;
+ const struct v4l2_ctrl_h264_pps *pps;
+ const struct v4l2_ctrl_h264_scaling_matrix *scaling_matrix;
+ struct vdec_h264_slice_lat_dec_param *slice_param = &inst->h264_slice_param;
+ struct v4l2_h264_reflist_builder reflist_builder;
+ u8 *p0_reflist = slice_param->decode_params.ref_pic_list_p0;
+ u8 *b0_reflist = slice_param->decode_params.ref_pic_list_b0;
+ u8 *b1_reflist = slice_param->decode_params.ref_pic_list_b1;
+
+ dec_params =
+ mtk_vdec_h264_get_ctrl_ptr(inst->ctx, V4L2_CID_STATELESS_H264_DECODE_PARAMS);
+ if (IS_ERR(dec_params))
+ return PTR_ERR(dec_params);
+
+ sps = mtk_vdec_h264_get_ctrl_ptr(inst->ctx, V4L2_CID_STATELESS_H264_SPS);
+ if (IS_ERR(sps))
+ return PTR_ERR(sps);
+
+ pps = mtk_vdec_h264_get_ctrl_ptr(inst->ctx, V4L2_CID_STATELESS_H264_PPS);
+ if (IS_ERR(pps))
+ return PTR_ERR(pps);
+
+ scaling_matrix =
+ mtk_vdec_h264_get_ctrl_ptr(inst->ctx, V4L2_CID_STATELESS_H264_SCALING_MATRIX);
+ if (IS_ERR(scaling_matrix))
+ return PTR_ERR(scaling_matrix);
+
+ mtk_vdec_h264_update_dpb(dec_params, inst->dpb);
+
+ mtk_vdec_h264_copy_sps_params(&slice_param->sps, sps);
+ mtk_vdec_h264_copy_pps_params(&slice_param->pps, pps);
+ mtk_vdec_h264_copy_scaling_matrix(&slice_param->scaling_matrix, scaling_matrix);
+
+ mtk_vdec_h264_copy_decode_params(&slice_param->decode_params, dec_params, inst->dpb);
+ mtk_vdec_h264_fill_dpb_info(inst->ctx, &slice_param->decode_params,
+ slice_param->h264_dpb_info);
+
+ /* Build the reference lists */
+ v4l2_h264_init_reflist_builder(&reflist_builder, dec_params, sps, inst->dpb);
+ v4l2_h264_build_p_ref_list(&reflist_builder, p0_reflist);
+
+ v4l2_h264_build_b_ref_lists(&reflist_builder, b0_reflist, b1_reflist);
+ /* Adapt the built lists to the firmware's expectations */
+ mtk_vdec_h264_fixup_ref_list(p0_reflist, reflist_builder.num_valid);
+ mtk_vdec_h264_fixup_ref_list(b0_reflist, reflist_builder.num_valid);
+ mtk_vdec_h264_fixup_ref_list(b1_reflist, reflist_builder.num_valid);
+ memcpy(&inst->vsi_ctx.h264_slice_params, slice_param,
+ sizeof(inst->vsi_ctx.h264_slice_params));
+
+ return 0;
+}
+
static void vdec_h264_slice_fill_decode_reflist(struct vdec_h264_slice_inst *inst,
struct vdec_h264_slice_lat_dec_param *slice_param,
struct vdec_h264_slice_share_info *share_info)
@@ -584,6 +645,102 @@ static int vdec_h264_slice_decode(void *h_vdec, struct mtk_vcodec_mem *bs,
return err;
}
+static int vdec_h264_slice_single_decode(void *h_vdec, struct mtk_vcodec_mem *bs,
+ struct vdec_fb *unused, bool *res_chg)
+{
+ struct vdec_h264_slice_inst *inst = (struct vdec_h264_slice_inst *)h_vdec;
+ struct vdec_vpu_inst *vpu = &inst->vpu;
+ struct mtk_video_dec_buf *src_buf_info, *dst_buf_info;
+ struct vdec_fb *fb;
+ unsigned char *buf;
+ unsigned int nal_start_idx, data[2], i;
+ u64 y_fb_dma, c_fb_dma;
+ struct mtk_vcodec_mem *mem;
+ int err;
+
+ /* bs NULL means flush decoder */
+ if (!bs)
+ return vpu_dec_reset(vpu);
+
+ fb = inst->ctx->dev->vdec_pdata->get_cap_buffer(inst->ctx);
+ src_buf_info = container_of(bs, struct mtk_video_dec_buf, bs_buffer);
+ dst_buf_info = container_of(fb, struct mtk_video_dec_buf, frame_buffer);
+
+ y_fb_dma = fb ? (u64)fb->base_y.dma_addr : 0;
+ c_fb_dma = fb ? (u64)fb->base_c.dma_addr : 0;
+ mtk_vcodec_debug(inst, "+ [%d] FB y_dma=%llx c_dma=%llx va=0x%llx",
+ inst->ctx->decoded_frame_cnt, y_fb_dma, c_fb_dma, (u64)fb);
+
+ inst->vsi_ctx.dec.bs_buf_addr = (u64)bs->dma_addr;
+ inst->vsi_ctx.dec.bs_buf_size = bs->size;
+ inst->vsi_ctx.dec.y_fb_dma = y_fb_dma;
+ inst->vsi_ctx.dec.c_fb_dma = c_fb_dma;
+ inst->vsi_ctx.dec.vdec_fb_va = (u64)(uintptr_t)fb;
+
+ v4l2_m2m_buf_copy_metadata(&src_buf_info->m2m_buf.vb,
+ &dst_buf_info->m2m_buf.vb, true);
+ err = get_vdec_sig_decode_parameters(inst);
+ if (err)
+ goto err_free_fb_out;
+
+ buf = (unsigned char *)bs->va;
+ nal_start_idx = mtk_vdec_h264_find_start_code(buf, bs->size);
+ if (nal_start_idx < 0) {
+ err = -EINVAL;
+ goto err_free_fb_out;
+ }
+ inst->vsi_ctx.dec.nal_info = buf[nal_start_idx];
+
+ *res_chg = inst->resolution_changed;
+ if (inst->resolution_changed) {
+ mtk_vcodec_debug(inst, "- resolution changed -");
+ if (inst->realloc_mv_buf) {
+ err = vdec_h264_slice_alloc_mv_buf(inst, &inst->ctx->picinfo);
+ inst->realloc_mv_buf = false;
+ if (err)
+ goto err_free_fb_out;
+ }
+ inst->resolution_changed = false;
+
+ for (i = 0; i < H264_MAX_MV_NUM; i++) {
+ mem = &inst->mv_buf[i];
+ inst->vsi_ctx.mv_buf_dma[i] = mem->dma_addr;
+ }
+ }
+
+ memcpy(inst->vpu.vsi, &inst->vsi_ctx, sizeof(inst->vsi_ctx));
+ err = vpu_dec_start(vpu, data, 2);
+ if (err)
+ goto err_free_fb_out;
+
+ /* wait decoder done interrupt */
+ err = mtk_vcodec_wait_for_done_ctx(inst->ctx, MTK_INST_IRQ_RECEIVED,
+ WAIT_INTR_TIMEOUT_MS, MTK_VDEC_CORE);
+ if (err)
+ mtk_vcodec_err(inst, "core decode timeout: pic_%d",
+ inst->ctx->decoded_frame_cnt);
+
+ inst->vsi->dec.timeout = !!err;
+ err = vpu_dec_end(vpu);
+ if (err)
+ goto err_free_fb_out;
+
+ memcpy(&inst->vsi_ctx, inst->vpu.vsi, sizeof(inst->vsi_ctx));
+ mtk_vcodec_debug(inst, "pic[%d] crc: 0x%x 0x%x 0x%x 0x%x 0x%x 0x%x 0x%x 0x%x",
+ inst->ctx->decoded_frame_cnt,
+ inst->vsi_ctx.dec.crc[0], inst->vsi_ctx.dec.crc[1],
+ inst->vsi_ctx.dec.crc[2], inst->vsi_ctx.dec.crc[3],
+ inst->vsi_ctx.dec.crc[4], inst->vsi_ctx.dec.crc[5],
+ inst->vsi_ctx.dec.crc[6], inst->vsi_ctx.dec.crc[7]);
+err_free_fb_out:
+ inst->ctx->dev->vdec_pdata->cap_to_disp(inst->ctx, fb, err);
+ mtk_vcodec_debug(inst, "dec frame number: %d err: %d",
+ inst->ctx->decoded_frame_cnt, err);
+ inst->ctx->decoded_frame_cnt++;
+
+ return err;
+}
+
static int vdec_h264_slice_get_param(void *h_vdec, enum vdec_get_param_type type,
void *out)
{
@@ -612,3 +769,10 @@ const struct vdec_common_if vdec_h264_slice_lat_if = {
.get_param = vdec_h264_slice_get_param,
.deinit = vdec_h264_slice_deinit,
};
+
+const struct vdec_common_if vdec_h264_slice_single_if = {
+ .init = vdec_h264_slice_init,
+ .decode = vdec_h264_slice_single_decode,
+ .get_param = vdec_h264_slice_get_param,
+ .deinit = vdec_h264_slice_deinit,
+};
diff --git a/drivers/media/platform/mtk-vcodec/vdec_drv_if.c b/drivers/media/platform/mtk-vcodec/vdec_drv_if.c
index 2d3a45781359..e22b577d692a 100644
--- a/drivers/media/platform/mtk-vcodec/vdec_drv_if.c
+++ b/drivers/media/platform/mtk-vcodec/vdec_drv_if.c
@@ -21,7 +21,10 @@ int vdec_if_init(struct mtk_vcodec_ctx *ctx, unsigned int fourcc)
switch (fourcc) {
case V4L2_PIX_FMT_H264_SLICE:
if (ctx->dev->vdec_pdata->hw_arch == MTK_VDEC_PURE_SINGLE_CORE) {
- ctx->dec_if = &vdec_h264_slice_if;
+ if (ctx->dev->vdec_pdata->is_subdev_supported)
+ ctx->dec_if = &vdec_h264_slice_single_if;
+ else
+ ctx->dec_if = &vdec_h264_slice_if;
ctx->hw_id = MTK_VDEC_CORE;
} else {
ctx->dec_if = &vdec_h264_slice_lat_if;
diff --git a/drivers/media/platform/mtk-vcodec/vdec_drv_if.h b/drivers/media/platform/mtk-vcodec/vdec_drv_if.h
index e383a04db7b8..991c04e65c79 100644
--- a/drivers/media/platform/mtk-vcodec/vdec_drv_if.h
+++ b/drivers/media/platform/mtk-vcodec/vdec_drv_if.h
@@ -57,6 +57,7 @@ struct vdec_fb_node {
extern const struct vdec_common_if vdec_h264_if;
extern const struct vdec_common_if vdec_h264_slice_if;
extern const struct vdec_common_if vdec_h264_slice_lat_if;
+extern const struct vdec_common_if vdec_h264_slice_single_if;
extern const struct vdec_common_if vdec_vp8_if;
extern const struct vdec_common_if vdec_vp8_slice_if;
extern const struct vdec_common_if vdec_vp9_if;
--
2.25.1
^ permalink raw reply related
* [PATCH v1, 2/3] dt-bindings: media: mtk-vcodec: Adds decoder dt-bindings for mt8186
From: Yunfei Dong @ 2022-01-22 7:56 UTC (permalink / raw)
To: Yunfei Dong, Alexandre Courbot, Hans Verkuil, Tzung-Bi Shih,
Tiffany Lin, Andrew-CT Chen, Mauro Carvalho Chehab, Rob Herring,
Matthias Brugger, Tomasz Figa
Cc: George Sun, Xiaoyong Lu, Hsin-Yi Wang, Fritz Koenig,
Dafna Hirschfeld, Benjamin Gaignard, Daniel Vetter, dri-devel,
Irui Wang, AngeloGioacchino Del Regno, Steve Cho, linux-media,
devicetree, linux-kernel, linux-arm-kernel, srv_heupstream,
linux-mediatek, Project_Global_Chrome_Upstream_Group
In-Reply-To: <20220122075606.19373-1-yunfei.dong@mediatek.com>
Adds decoder dt-bindings for mt8186.
Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com>
---
.../bindings/media/mediatek,vcodec-subdev-decoder.yaml | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/media/mediatek,vcodec-subdev-decoder.yaml b/Documentation/devicetree/bindings/media/mediatek,vcodec-subdev-decoder.yaml
index d587fc3e39fb..6415c9f29130 100644
--- a/Documentation/devicetree/bindings/media/mediatek,vcodec-subdev-decoder.yaml
+++ b/Documentation/devicetree/bindings/media/mediatek,vcodec-subdev-decoder.yaml
@@ -47,7 +47,9 @@ description: |
properties:
compatible:
- const: mediatek,mt8192-vcodec-dec
+ enum:
+ - mediatek,mt8192-vcodec-dec
+ - mediatek,mt8186-vcodec-dec
reg:
maxItems: 1
--
2.25.1
^ permalink raw reply related
* Re: [GIT PULL] Devicetree fixes for v5.17, take 1
From: pr-tracker-bot @ 2022-01-22 8:06 UTC (permalink / raw)
To: Rob Herring; +Cc: Linus Torvalds, linux-kernel, devicetree, Frank Rowand
In-Reply-To: <YesPMjmwx4snvWDQ@robh.at.kernel.org>
The pull request you sent on Fri, 21 Jan 2022 13:53:22 -0600:
> git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git tags/devicetree-fixes-for-5.17-1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/0809edbae347a224ca1b59fb8be1c2d54389c2c6
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
^ permalink raw reply
* Re: [RFC PATCH v2 3/7] media: dt-bindings: media: Add bindings for bcm2835-unicam
From: Jean-Michel Hautbois @ 2022-01-22 8:38 UTC (permalink / raw)
To: Laurent Pinchart
Cc: dave.stevenson, devicetree, kernel-list, linux-arm-kernel,
linux-kernel, linux-media, linux-rpi-kernel, lukasz, mchehab,
naush, robh, tomi.valkeinen
In-Reply-To: <YetBdVY57T3QrUNa@pendragon.ideasonboard.com>
Hi Laurent,
On 22/01/2022 00:27, Laurent Pinchart wrote:
> Hi Jean-Michel,
>
> Thank you for the patch.
>
> On Fri, Jan 21, 2022 at 09:18:06AM +0100, Jean-Michel Hautbois wrote:
>> Introduce the dt-bindinds documentation for bcm2835 CCP2/CSI2 camera
>
> s/bindinds/bindings/
>
> I'd mention "Unicam" somewhere here.
>
>> interface. Also add a MAINTAINERS entry for it.
Oh my, I tis not the right dts bindings patch, I mixed up my trees... :-/
Sorry for this I will send a v2.1 soon...
>>
>> Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
>> Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
>> Signed-off-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com>
>> ---
>> Dave: I assumed you were the maintainer for this file, as I based it on the
>> bcm2835-unicam.txt file. Are you happy to be added directly as the
>> maintainer, or should this be specified as "Raspberry Pi Kernel
>> Maintenance <kernel-list@raspberrypi.com>"
>> - in v2: multiple corrections to pass the bot checking as Rob kindly
>> told me.
>> ---
>> .../bindings/media/brcm,bcm2835-unicam.yaml | 103 ++++++++++++++++++
>> MAINTAINERS | 6 +
>> 2 files changed, 109 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/media/brcm,bcm2835-unicam.yaml
>>
>> diff --git a/Documentation/devicetree/bindings/media/brcm,bcm2835-unicam.yaml b/Documentation/devicetree/bindings/media/brcm,bcm2835-unicam.yaml
>> new file mode 100644
>> index 000000000000..1427514142cf
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/media/brcm,bcm2835-unicam.yaml
>> @@ -0,0 +1,103 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/media/brcm,bcm2835-unicam.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Broadcom BCM283x Camera Interface (Unicam)
>> +
>> +maintainers:
>> + - Dave Stevenson <dave.stevenson@raspberrypi.com>
>> +
>> +description: |-
>> + The Unicam block on BCM283x SoCs is the receiver for either
>> + CSI-2 or CCP2 data from image sensors or similar devices.
>> +
>> + The main platform using this SoC is the Raspberry Pi family of boards.
>> + On the Pi the VideoCore firmware can also control this hardware block,
>> + and driving it from two different processors will cause issues.
>> + To avoid this, the firmware checks the device tree configuration
>> + during boot. If it finds device tree nodes called csi0 or csi1 then
>> + it will stop the firmware accessing the block, and it can then
>> + safely be used via the device tree binding.
>
> As mentioned in the review of the DT integration, the nodes should
> ideally be called just "csi", not "csi0" and "csi1" (maybe Rob could
> confirm this ?). Dave, is there a way the firmware could be updated to
> also hand over control of the Unicam instances to Linux when a "csi"
> node is found, not just "csi0" or "csi1" ?
>
> Given that the node names are significant, they should be enforced in
> the YAML schema.
>
>> +
>> +properties:
>> + compatible:
>> + const: brcm,bcm2835-unicam
>> +
>> + reg:
>> + description:
>> + physical base address and length of the register sets for the device.
>
> This can be dropped.
>
>> + maxItems: 1
>
> There are two items in the example below. How does this validate ?
>
>> +
>> + interrupts:
>> + description: the IRQ line for this Unicam instance.
>
> This can be dropped.
>
>> + maxItems: 1
>> +
>> + clocks:
>> + description: |-
>> + list of clock specifiers, corresponding to entries in clock-names
>> + property.
>
> clocks:
> items:
> - description: The clock for ...
> - description: The clock for ...
>
> (with the two descriptions matching the LP and VPU clocks, I don't know
> what they are).
>
>> +
>> + clock-names:
>> + items:
>> + - const: lp
>> + - const: vpu
>> +
>> + port:
>> + $ref: /schemas/graph.yaml#/properties/port
>> +
>> +required:
>> + - compatible
>> + - reg
>> + - interrupts
>> + - clocks
>> + - clock-names
>> + - port
>> +
>> +additionalProperties: False
>> +
>> +examples:
>> + - |
>> + csi1: csi1@7e801000 {
>> + compatible = "brcm,bcm2835-unicam";
>> + reg = <0x7e801000 0x800>,
>> + <0x7e802004 0x4>;
>> + interrupts = <2 7>;
>
> Let's use the Pi 4 device tree as an example, as that's what we're
> upstreaming first.
>
>> + clocks = <&clocks BCM2835_CLOCK_CAM1>,
>
> This will fail to compile without a proper #include, did you get this to
> pass validation ?
>
>> + <&firmware_clocks 4>;
>> + clock-names = "lp", "vpu";
>> + port {
>> + csi1_ep: endpoint {
>> + remote-endpoint = <&tc358743_0>;
>> + data-lanes = <1 2>;
>> + };
>> + };
>> + };
>> +
>> + i2c0: i2c@7e205000 {
>> + tc358743: csi-hdmi-bridge@0f {
>> + compatible = "toshiba,tc358743";
>> + reg = <0x0f>;
>> + clocks = <&tc358743_clk>;
>> + clock-names = "refclk";
>> +
>> + tc358743_clk: bridge-clk {
>> + compatible = "fixed-clock";
>> + #clock-cells = <0>;
>> + clock-frequency = <27000000>;
>> + };
>> +
>> + port {
>> + tc358743_0: endpoint {
>> + remote-endpoint = <&csi1_ep>;
>> + clock-lanes = <0>;
>> + data-lanes = <1 2>;
>> + clock-noncontinuous;
>> + link-frequencies =
>> + /bits/ 64 <297000000>;
>> + };
>> + };
>> + };
>> + };
>
> I'd drop this node completely.
>
>> +...
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 33f75892f98e..07f238fd5ff9 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -3679,6 +3679,12 @@ F: Documentation/media/v4l-drivers/bcm2835-isp.rst
>> F: drivers/staging/vc04_services/bcm2835-isp
>> F: include/uapi/linux/bcm2835-isp.h
>>
>> +BROADCOM BCM2835 CAMERA DRIVER
>> +M: Raspberry Pi Kernel Maintenance <kernel-list@raspberrypi.com>
>> +L: linux-media@vger.kernel.org
>> +S: Maintained
>> +F: Documentation/devicetree/bindings/media/brcm,bcm2835-unicam.yaml
>> +
>> BROADCOM BCM47XX MIPS ARCHITECTURE
>> M: Hauke Mehrtens <hauke@hauke-m.de>
>> M: Rafał Miłecki <zajec5@gmail.com>
>
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: sm8150: Add ufs power-domain entries
From: kernel test robot @ 2022-01-22 8:52 UTC (permalink / raw)
To: Bhupesh Sharma, linux-arm-msm
Cc: kbuild-all, bhupesh.sharma, bhupesh.linux, linux-kernel,
devicetree, robh+dt, bjorn.andersson, agross, Rob Herring
In-Reply-To: <20220120082803.15535-1-bhupesh.sharma@linaro.org>
Hi Bhupesh,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on robh/for-next]
[also build test ERROR on v5.16 next-20220121]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url: https://github.com/0day-ci/linux/commits/Bhupesh-Sharma/arm64-dts-qcom-sm8150-Add-ufs-power-domain-entries/20220120-162925
base: https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
config: arm64-randconfig-s032-20220117 (https://download.01.org/0day-ci/archive/20220122/202201221606.gzXiP4VV-lkp@intel.com/config)
compiler: aarch64-linux-gcc (GCC) 11.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# apt-get install sparse
# sparse version: v0.6.4-dirty
# https://github.com/0day-ci/linux/commit/e9cea3a4d3c4706f9cef18f55b07d3bc389a051a
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review Bhupesh-Sharma/arm64-dts-qcom-sm8150-Add-ufs-power-domain-entries/20220120-162925
git checkout e9cea3a4d3c4706f9cef18f55b07d3bc389a051a
# save the config file to linux build tree
mkdir build_dir
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-11.2.0 make.cross C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' O=build_dir ARCH=arm64 SHELL=/bin/bash
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
All errors (new ones prefixed by >>):
>> Error: arch/arm64/boot/dts/qcom/sm8150.dtsi:1641.26-27 syntax error
FATAL ERROR: Unable to parse input tree
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* Re: [PATCH v3 2/3] dt-bindings: pwm: Document clk based PWM controller
From: Krzysztof Kozlowski @ 2022-01-22 10:13 UTC (permalink / raw)
To: Sean Anderson, Nikita Travkin
Cc: thierry.reding, lee.jones, u.kleine-koenig, robh+dt, sboyd,
linus.walleij, masneyb, linux-pwm, devicetree,
linux-kernel@vger.kernel.org, ~postmarketos/upstreaming
In-Reply-To: <1d9b1db0-981d-f77a-063a-69c8a4d53343@seco.com>
On 21/01/2022 22:34, Sean Anderson wrote:
>
>
> On 1/21/22 2:34 AM, Krzysztof Kozlowski wrote:
>> On Thu, 20 Jan 2022 at 17:15, Nikita Travkin <nikita@trvn.ru> wrote:
>>>
>>> Add YAML devicetree binding for clk based PWM controller
>>>
>>> Signed-off-by: Nikita Travkin <nikita@trvn.ru>
>>> --
>>> Changes in v2:
>>> - fix the file name.
>>> ---
>>> .../devicetree/bindings/pwm/clk-pwm.yaml | 45 +++++++++++++++++++
>>> 1 file changed, 45 insertions(+)
>>> create mode 100644 Documentation/devicetree/bindings/pwm/clk-pwm.yaml
>>>
>>> diff --git a/Documentation/devicetree/bindings/pwm/clk-pwm.yaml b/Documentation/devicetree/bindings/pwm/clk-pwm.yaml
>>> new file mode 100644
>>> index 000000000000..4fb2c1baaad4
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/pwm/clk-pwm.yaml
>>> @@ -0,0 +1,45 @@
>>> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
>>> +%YAML 1.2
>>> +---
>>> +$id: http://devicetree.org/schemas/pwm/clk-pwm.yaml#
>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>> +
>>> +title: Clock based PWM controller
>>> +
>>> +maintainers:
>>> + - Nikita Travkin <nikita@trvn.ru>
>>> +
>>> +description: |
>>> + Some systems have clocks that can be exposed to external devices.
>>> + (e.g. by muxing them to GPIO pins)
>>> + It's often possible to control duty-cycle of such clocks which makes them
>>> + suitable for generating PWM signal.
>>> +
>>> +allOf:
>>> + - $ref: pwm.yaml#
>>> +
>>> +properties:
>>> + compatible:
>>> + const: clk-pwm
>>> +
>>> + clocks:
>>> + description: Clock used to generate the signal.
>>> + maxItems: 1
>>> +
>>> + "#pwm-cells":
>>> + const: 2
>>> +
>>> +unevaluatedProperties: false
>>> +
>>> +required:
>>> + - clocks
>>> +
>>> +examples:
>>> + - |
>>> + pwm-flash {
>>
>> Node names should be generic (see devicetree specification), so just "pwm".
>
> And then what will you do if you have two clock-based pwms?
The same as we do with fixed clocks, keys and so on:
pwm-0
pwm-1
pwm-2
A descriptive suffix also appears, but there is no justification to use
it here. There is only one node in the example.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 1/3] spi: dt-bindings: samsung: Add fsd spi compatible
From: Krzysztof Kozlowski @ 2022-01-22 10:33 UTC (permalink / raw)
To: Andi Shyti
Cc: Alim Akhtar, linux-arm-kernel, linux-kernel, devicetree,
linus.walleij, robh+dt, linux-samsung-soc, pankaj.dubey, broonie,
linux-spi, linux-fsd, Adithya K V
In-Reply-To: <YevcOlARxNcBeDJE@jack.zhora.eu>
On Sat, 22 Jan 2022 at 11:28, Andi Shyti <andi@etezian.org> wrote:
>
> Hi Krzysztof and Alim,
>
> On Fri, Jan 21, 2022 at 07:33:15PM +0100, Krzysztof Kozlowski wrote:
> > On 20/01/2022 20:24, Alim Akhtar wrote:
> > > Adds spi controller dt-binding compatible information for
> > > Tesla Full Self-Driving (FSD) SoC.
> > >
> > > Cc: linux-fsd@tesla.com
> > > Signed-off-by: Adithya K V <adithya.kv@samsung.com>
> > > Signed-off-by: Alim Akhtar <alim.akhtar@samsung.com>
> > > ---
> > > Documentation/devicetree/bindings/spi/samsung,spi.yaml | 1 +
> > > 1 file changed, 1 insertion(+)
> >
> > I think you forgot to mention - in cover letter - that this depends on
> > my Samsung SPI bindings conversion to dtschema.
>
> It's written in the cover letter:
>
> "Note: This series is depended on [1] patches which adds
> support of FSD SoC and on Krzysztof's v5 [2] of spi schema
> changes"
Indeed, it is. I simply could not find the cover letter so I assumed
none was sent, but it just got hidden.
^ permalink raw reply
* Re: [PATCH v2 2/3] spi: s3c64xx: Add spi port configuration for Tesla FSD SoC
From: Andi Shyti @ 2022-01-22 10:32 UTC (permalink / raw)
To: Alim Akhtar
Cc: linux-arm-kernel, linux-kernel, devicetree, linus.walleij,
robh+dt, krzysztof.kozlowski, linux-samsung-soc, pankaj.dubey,
broonie, andi, linux-spi, linux-fsd, Aswani Reddy
In-Reply-To: <20220120192438.25555-3-alim.akhtar@samsung.com>
Hi Alim,
> Adds compatible and port configuration for spi controller
> for Tesla Full Self-Driving SoC.
please next time be a bit clearer in the cover letter. I think
you want to say:
"This patch adds the compatible..."
But it's anyway recommended to use the imperative form:
"Add the compatible blah blah blah...."
> Cc: linux-fsd@tesla.com
> Signed-off-by: Aswani Reddy <aswani.reddy@samsung.com>
> Signed-off-by: Alim Akhtar <alim.akhtar@samsung.com>
Other than that, looks good to me:
Reviewed-by: Andi Shyti <andi@etezian.org>
Thanks,
Andi
^ permalink raw reply
* Re: [PATCH v2 3/3] arm64: dts: fsd: Add SPI device nodes
From: Andi Shyti @ 2022-01-22 10:42 UTC (permalink / raw)
To: Alim Akhtar
Cc: linux-arm-kernel, linux-kernel, devicetree, linus.walleij,
robh+dt, krzysztof.kozlowski, linux-samsung-soc, pankaj.dubey,
broonie, andi, linux-spi, Aswani Reddy, linux-fsd
In-Reply-To: <20220120192438.25555-4-alim.akhtar@samsung.com>
Hi Alim and Aswani,
On Fri, Jan 21, 2022 at 12:54:38AM +0530, Alim Akhtar wrote:
> From: Aswani Reddy <aswani.reddy@samsung.com>
>
> Adds device tree node for SPI IPs
>
> Cc: linux-fsd@tesla.com
> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
> Signed-off-by: Aswani Reddy <aswani.reddy@samsung.com>
> Signed-off-by: Alim Akhtar <alim.akhtar@samsung.com>
Reviewed-by: Andi Shyti <andi@etezian.org>
Please, also allow me another nit-commnent for the next patches:
the tag section is in chronological order. I suppose that first
Aswani wrote the patch, then you sent it to the mailing list and
at the end Krzysztof has reviewed it, this means that the right
order is:
Signed-off-by: Aswani Reddy <aswani.reddy@samsung.com>
Signed-off-by: Alim Akhtar <alim.akhtar@samsung.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Thank you,
Andi
^ permalink raw reply
* Re: [PATCH v2 1/3] spi: dt-bindings: samsung: Add fsd spi compatible
From: Andi Shyti @ 2022-01-22 10:28 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Alim Akhtar, linux-arm-kernel, linux-kernel, devicetree,
linus.walleij, robh+dt, linux-samsung-soc, pankaj.dubey, broonie,
andi, linux-spi, linux-fsd, Adithya K V
In-Reply-To: <aa172f14-2328-fc7c-0063-5c0033970d1d@canonical.com>
Hi Krzysztof and Alim,
On Fri, Jan 21, 2022 at 07:33:15PM +0100, Krzysztof Kozlowski wrote:
> On 20/01/2022 20:24, Alim Akhtar wrote:
> > Adds spi controller dt-binding compatible information for
> > Tesla Full Self-Driving (FSD) SoC.
> >
> > Cc: linux-fsd@tesla.com
> > Signed-off-by: Adithya K V <adithya.kv@samsung.com>
> > Signed-off-by: Alim Akhtar <alim.akhtar@samsung.com>
> > ---
> > Documentation/devicetree/bindings/spi/samsung,spi.yaml | 1 +
> > 1 file changed, 1 insertion(+)
>
> I think you forgot to mention - in cover letter - that this depends on
> my Samsung SPI bindings conversion to dtschema.
It's written in the cover letter:
"Note: This series is depended on [1] patches which adds
support of FSD SoC and on Krzysztof's v5 [2] of spi schema
changes"
Alim, you can also add:
Reviewed-by: Andi Shyti <andi@etezian.org>
Thank you,
Andi
^ permalink raw reply
* RE: [RFC 21/28] dt-bindings: display: bridge: Document RZ/G2L MIPI DSI TX bindings
From: Biju Das @ 2022-01-22 11:19 UTC (permalink / raw)
To: Rob Herring
Cc: David Airlie, Daniel Vetter, dri-devel@lists.freedesktop.org,
devicetree@vger.kernel.org, Geert Uytterhoeven, Chris Paterson,
Biju Das, Prabhakar Mahadev Lad,
linux-renesas-soc@vger.kernel.org
In-Reply-To: <YetYPCwJeVMAO+6F@robh.at.kernel.org>
Hi Rob,
Thanks for the review.
> Subject: Re: [RFC 21/28] dt-bindings: display: bridge: Document RZ/G2L
> MIPI DSI TX bindings
>
> On Wed, Jan 12, 2022 at 05:46:05PM +0000, Biju Das wrote:
> > The RZ/G2L MIPI DSI TX is embedded in the Renesas RZ/G2L family SoC's.
> > It can operate in DSI mode, with up to four data lanes.
> >
> > Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
> > ---
> > .../bindings/display/bridge/renesas,dsi.yaml | 143
> > ++++++++++++++++++
> > 1 file changed, 143 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/display/bridge/renesas,dsi.yaml
> >
> > diff --git
> > a/Documentation/devicetree/bindings/display/bridge/renesas,dsi.yaml
> > b/Documentation/devicetree/bindings/display/bridge/renesas,dsi.yaml
> > new file mode 100644
> > index 000000000000..8e56a9c53cc5
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/bridge/renesas,dsi.yam
> > +++ l
> > @@ -0,0 +1,143 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2
> > +---
> > +$id:
> > +https://jpn01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevi
> > +cetree.org%2Fschemas%2Fdisplay%2Fbridge%2Frenesas%2Cdsi.yaml%23&d
> > +ata=04%7C01%7Cbiju.das.jz%40bp.renesas.com%7C0494a54e80ad4334fbd208d9
> > +dd43393b%7C53d82571da1947e49cb4625a166a4a2a%7C0%7C0%7C637784103062464
> > +167%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBT
> > +iI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=krF2TinxFIRvSQWNMrJpAjUpkk
> > +cghJsFzWIOmh2Nwno%3D&reserved=0
> > +$schema:
> > +https://jpn01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevi
> > +cetree.org%2Fmeta-schemas%2Fcore.yaml%23&data=04%7C01%7Cbiju.das.
> > +jz%40bp.renesas.com%7C0494a54e80ad4334fbd208d9dd43393b%7C53d82571da19
> > +47e49cb4625a166a4a2a%7C0%7C0%7C637784103062464167%7CUnknown%7CTWFpbGZ
> > +sb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%
> > +3D%7C3000&sdata=XrwV3g0Jw0%2Bsi0J5PygxWTw614a0%2FtQGDF2HeMdBVsA%3
> > +D&reserved=0
> > +
> > +title: Renesas R-Car MIPI DSI Encoder
> > +
> > +maintainers:
> > + - Biju Das <biju.das.jz@bp.renesas.com>
> > +
> > +description: |
> > + This binding describes the MIPI DSI encoder embedded in the Renesas
> > + RZ/G2L family of SoC's. The encoder can operate in DSI mode with up
> > + to four data lanes.
>
> Need a ref to dsi-controller.yaml.
Agreed. Will add this.
>
> > +
> > +properties:
> > + compatible:
> > + enum:
> > + - renesas,r9a07g044-mipi-dsi # for RZ/G2L
> > +
> > + reg:
> > + items:
> > + - description: Link register
> > + - description: D-PHY register
>
> D-PHY isn't a separate block?
MIPI-DSI Tx module composed of MIPI DSI-2 Host Controller (LINK), and MIPI D-PHY Tx (DPHY).
Basically both D-PHY and Link are integrated inside MIPI-DSI Tx module.
Regards,
Biju
>
> > +
> > + clocks:
> > + items:
> > + - description: DSI D-PHY PLL multiplied clock
> > + - description: DSI D-PHY system clock
> > + - description: DSI AXI bus clock
> > + - description: DSI Register access clock
> > + - description: DSI Video clock
> > + - description: DSI D_PHY Escape mode Receive clock
> > +
> > + clock-names:
> > + items:
> > + - const: pllclk
> > + - const: sysclk
> > + - const: aclk
> > + - const: pclk
> > + - const: vclk
> > + - const: lpclk
> > +
> > + power-domains:
> > + maxItems: 1
> > +
> > + resets:
> > + items:
> > + - description: MIPI_DSI_CMN_RSTB
> > + - description: MIPI_DSI_ARESET_N
> > + - description: MIPI_DSI_PRESET_N
> > +
> > + reset-names:
> > + items:
> > + - const: rst
> > + - const: arst
> > + - const: prst
> > +
> > + ports:
> > + $ref: /schemas/graph.yaml#/properties/ports
> > +
> > + properties:
> > + port@0:
> > + $ref: /schemas/graph.yaml#/properties/port
> > + description: Parallel input port
> > +
> > + port@1:
> > + $ref: /schemas/graph.yaml#/$defs/port-base
> > + unevaluatedProperties: false
> > + description: DSI output port
> > +
> > + properties:
> > + endpoint:
> > + $ref: /schemas/media/video-interfaces.yaml#
> > + unevaluatedProperties: false
> > +
> > + properties:
> > + data-lanes:
> > + minItems: 1
> > + maxItems: 4
> > +
> > + required:
> > + - data-lanes
> > +
> > + required:
> > + - port@0
> > + - port@1
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - clocks
> > + - clock-names
> > + - power-domains
> > + - resets
> > + - reset-names
> > + - ports
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > + - |
> > + #include <dt-bindings/clock/r9a07g044-cpg.h>
> > +
> > + dsi0: dsi@10860000 {
> > + compatible = "renesas,r9a07g044-mipi-dsi";
> > + reg = <0x10860000 0x10000>,
> > + <0x10850000 0x10000>;
> > + power-domains = <&cpg>;
> > + clocks = <&cpg CPG_MOD R9A07G044_MIPI_DSI_PLLCLK>,
> > + <&cpg CPG_MOD R9A07G044_MIPI_DSI_SYSCLK>,
> > + <&cpg CPG_MOD R9A07G044_MIPI_DSI_ACLK>,
> > + <&cpg CPG_MOD R9A07G044_MIPI_DSI_PCLK>,
> > + <&cpg CPG_MOD R9A07G044_MIPI_DSI_VCLK>,
> > + <&cpg CPG_MOD R9A07G044_MIPI_DSI_LPCLK>;
> > + clock-names = "pllclk", "sysclk", "aclk", "pclk", "vclk",
> "lpclk";
> > + resets = <&cpg R9A07G044_MIPI_DSI_CMN_RSTB>,
> > + <&cpg R9A07G044_MIPI_DSI_ARESET_N>,
> > + <&cpg R9A07G044_MIPI_DSI_PRESET_N>;
> > + reset-names = "rst", "arst", "prst";
> > +
> > + ports {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + port@0 {
> > + reg = <0>;
> > + dsi0_in: endpoint {
> > + remote-endpoint = <&du_out_dsi0>;
> > + };
> > + };
> > +
> > + port@1 {
> > + reg = <1>;
> > + dsi0_out: endpoint {
> > + data-lanes = <1 2 3 4>;
> > + remote-endpoint = <&adv7535_in>;
> > + };
> > + };
> > + };
> > + };
> > +...
> > --
> > 2.17.1
> >
> >
^ permalink raw reply
* RE: [RFC 17/28] dt-bindings: display: renesas,du: Document r9a07g044l bindings
From: Biju Das @ 2022-01-22 11:20 UTC (permalink / raw)
To: Rob Herring
Cc: David Airlie, Daniel Vetter, Laurent Pinchart, Kieran Bingham,
dri-devel@lists.freedesktop.org,
linux-renesas-soc@vger.kernel.org, devicetree@vger.kernel.org,
Geert Uytterhoeven, Chris Paterson, Biju Das,
Prabhakar Mahadev Lad
In-Reply-To: <YetXdDHGnHDV2LSM@robh.at.kernel.org>
Hi Rob,
Thanks for the feedback.
> Subject: Re: [RFC 17/28] dt-bindings: display: renesas,du: Document
> r9a07g044l bindings
>
> On Wed, Jan 12, 2022 at 05:46:01PM +0000, Biju Das wrote:
> > Extend the Renesas DU display bindings to support the r9a07g044l RZ/G2L.
> >
> > Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
> > ---
> > .../bindings/display/renesas,du.yaml | 54 +++++++++++++++++++
> > 1 file changed, 54 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/display/renesas,du.yaml
> b/Documentation/devicetree/bindings/display/renesas,du.yaml
> > index 13efea574584..fc050b1088f3 100644
> > --- a/Documentation/devicetree/bindings/display/renesas,du.yaml
> > +++ b/Documentation/devicetree/bindings/display/renesas,du.yaml
> > @@ -40,6 +40,7 @@ properties:
> > - renesas,du-r8a77990 # for R-Car E3 compatible DU
> > - renesas,du-r8a77995 # for R-Car D3 compatible DU
> > - renesas,du-r8a779a0 # for R-Car V3U compatible DU
> > + - renesas,du-r9a07g044l # for RZ/G2L compatible DU
> >
> > reg:
> > maxItems: 1
> > @@ -824,6 +825,59 @@ allOf:
> > - reset-names
> > - renesas,vsps
> >
> > + - if:
> > + properties:
> > + compatible:
> > + contains:
> > + enum:
> > + - renesas,du-r9a07g044l
> > + then:
> > + properties:
> > + clocks:
> > + items:
> > + - description: LCDC Main clock
> > + - description: LCDC Register Access Clock
> > + - description: LCDC Video Clock
> > +
> > + clock-names:
> > + items:
> > + - const: du.0
> > + - const: pclk
> > + - const: vclk
> > +
> > + interrupts:
> > + maxItems: 1
> > +
> > + resets:
> > + maxItems: 1
> > +
> > + reset-names:
> > + items:
> > + - const: du.0
> > +
> > + ports:
> > + properties:
> > + port@0:
> > + description: DPAD 0
> > + port@1:
> > + description: DSI 0
> > + port@2: false
> > + port@3: false
> > +
> > + required:
> > + - port@0
> > + - port@1
> > +
> > + renesas,vsps:
> > + minItems: 1
>
> The minimum number of items is 1 by default if not otherwise specified.
>
> maxItems: 1 ???
Agreed, I should use maxItems: 1
Regards,
Biju
>
> > +
> > + required:
> > + - clock-names
> > + - interrupts
> > + - resets
> > + - reset-names
> > + - renesas,vsps
> > +
> > additionalProperties: false
> >
> > examples:
> > --
> > 2.17.1
> >
> >
^ permalink raw reply
* RE: [RFC 19/28] media: dt-bindings: media: renesas,vsp1: Document RZ/{G2L,V2L} VSPD bindings
From: Biju Das @ 2022-01-22 11:23 UTC (permalink / raw)
To: Rob Herring
Cc: Mauro Carvalho Chehab, Laurent Pinchart, Kieran Bingham,
linux-media@vger.kernel.org, linux-renesas-soc@vger.kernel.org,
devicetree@vger.kernel.org, Geert Uytterhoeven, Chris Paterson,
Biju Das, Prabhakar Mahadev Lad
In-Reply-To: <YetXnJf85MMlJjAW@robh.at.kernel.org>
Hi Rob,
Thanks for the review.
> Subject: Re: [RFC 19/28] media: dt-bindings: media: renesas,vsp1: Document
> RZ/{G2L,V2L} VSPD bindings
>
> On Wed, Jan 12, 2022 at 05:46:03PM +0000, Biju Das wrote:
> > Document VSPD found in RZ/G2L and RZ/V2L family SoC's.
> >
> > Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
> > ---
> > Documentation/devicetree/bindings/media/renesas,vsp1.yaml | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/Documentation/devicetree/bindings/media/renesas,vsp1.yaml
> b/Documentation/devicetree/bindings/media/renesas,vsp1.yaml
> > index 990e9c1dbc43..b27ee23d2b29 100644
> > --- a/Documentation/devicetree/bindings/media/renesas,vsp1.yaml
> > +++ b/Documentation/devicetree/bindings/media/renesas,vsp1.yaml
> > @@ -19,6 +19,7 @@ properties:
> > enum:
> > - renesas,vsp1 # R-Car Gen2 and RZ/G1
> > - renesas,vsp2 # R-Car Gen3 and RZ/G2
> > + - renesas,vsp2-r9a07g044 # RZ/G2L and RZ/V2L
> >
> > reg:
> > maxItems: 1
> > @@ -27,7 +28,8 @@ properties:
> > maxItems: 1
> >
> > clocks:
> > - maxItems: 1
> > + minItems: 1
> > + maxItems: 3
>
> You have to define what each one is once you have more than 1.
Agreed, Will define each clocks.
Regards,
Biju
>
> >
> > power-domains:
> > maxItems: 1
> > --
> > 2.17.1
> >
> >
^ permalink raw reply
* [PATCH v2 0/4] Add I2C and PWM support for T234
From: Akhil R @ 2022-01-22 11:23 UTC (permalink / raw)
To: devicetree, digetx, jonathanh, ldewangan, linux-i2c, linux-kernel,
linux-tegra, mperttunen, robh+dt, thierry.reding
Cc: akhilrajeev
The patchset contains driver and devicetree changes to support I2C and
PWM for Tegra234
v2->v1:
* Reverted changes in i2c-tegra.c. using tegra194_i2c_hw for tegra234
as the values are compatible.
Akhil R (4):
dt-bindings: Add headers for Tegra234 I2C
arm64: tegra: Add Tegra234 I2C devicetree nodes
dt-bindings: Add headers for Tegra234 PWM
arm64: tegra: Add Tegra234 PWM devicetree nodes
arch/arm64/boot/dts/nvidia/tegra234.dtsi | 133 +++++++++++++++++++++++++++++
include/dt-bindings/clock/tegra234-clock.h | 36 ++++++++
include/dt-bindings/reset/tegra234-reset.h | 16 ++++
3 files changed, 185 insertions(+)
--
2.7.4
^ permalink raw reply
* [PATCH v2 1/4] dt-bindings: Add headers for Tegra234 I2C
From: Akhil R @ 2022-01-22 11:23 UTC (permalink / raw)
To: devicetree, digetx, jonathanh, ldewangan, linux-i2c, linux-kernel,
linux-tegra, mperttunen, robh+dt, thierry.reding
Cc: akhilrajeev
In-Reply-To: <1642850607-20664-1-git-send-email-akhilrajeev@nvidia.com>
Add dt-bindings header files for I2C controllers for Tegra234
Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
---
include/dt-bindings/clock/tegra234-clock.h | 19 +++++++++++++++++++
include/dt-bindings/reset/tegra234-reset.h | 8 ++++++++
2 files changed, 27 insertions(+)
diff --git a/include/dt-bindings/clock/tegra234-clock.h b/include/dt-bindings/clock/tegra234-clock.h
index 8d7e66e..5d05c19 100644
--- a/include/dt-bindings/clock/tegra234-clock.h
+++ b/include/dt-bindings/clock/tegra234-clock.h
@@ -30,5 +30,24 @@
#define TEGRA234_CLK_PLLC4 237U
/** @brief 32K input clock provided by PMIC */
#define TEGRA234_CLK_CLK_32K 289U
+/** @brief output of mux controlled by CLK_RST_CONTROLLER_CLK_SOURCE_I2C1 */
+#define TEGRA234_CLK_I2C1 48U
+/** @brief output of mux controlled by CLK_RST_CONTROLLER_CLK_SOURCE_I2C2 */
+#define TEGRA234_CLK_I2C2 49U
+/** @brief output of mux controlled by CLK_RST_CONTROLLER_CLK_SOURCE_I2C3 */
+#define TEGRA234_CLK_I2C3 50U
+/** output of mux controlled by CLK_RST_CONTROLLER_CLK_SOURCE_I2C4 */
+#define TEGRA234_CLK_I2C4 51U
+/** @brief output of mux controlled by CLK_RST_CONTROLLER_CLK_SOURCE_I2C6 */
+#define TEGRA234_CLK_I2C6 52U
+/** @brief output of mux controlled by CLK_RST_CONTROLLER_CLK_SOURCE_I2C7 */
+#define TEGRA234_CLK_I2C7 53U
+/** @brief output of mux controlled by CLK_RST_CONTROLLER_CLK_SOURCE_I2C8 */
+#define TEGRA234_CLK_I2C8 54U
+/** @brief output of mux controlled by CLK_RST_CONTROLLER_CLK_SOURCE_I2C9 */
+#define TEGRA234_CLK_I2C9 55U
+
+/** @brief PLLP clk output */
+#define TEGRA234_CLK_PLLP_OUT0 102U
#endif
diff --git a/include/dt-bindings/reset/tegra234-reset.h b/include/dt-bindings/reset/tegra234-reset.h
index 50e13bc..e07e898 100644
--- a/include/dt-bindings/reset/tegra234-reset.h
+++ b/include/dt-bindings/reset/tegra234-reset.h
@@ -12,6 +12,14 @@
*/
#define TEGRA234_RESET_SDMMC4 85U
#define TEGRA234_RESET_UARTA 100U
+#define TEGRA234_RESET_I2C1 24U
+#define TEGRA234_RESET_I2C2 29U
+#define TEGRA234_RESET_I2C3 30U
+#define TEGRA234_RESET_I2C4 31U
+#define TEGRA234_RESET_I2C6 32U
+#define TEGRA234_RESET_I2C7 33U
+#define TEGRA234_RESET_I2C8 34U
+#define TEGRA234_RESET_I2C9 35U
/** @} */
--
2.7.4
^ permalink raw reply related
* [PATCH v2 2/4] arm64: tegra: Add Tegra234 I2C devicetree nodes
From: Akhil R @ 2022-01-22 11:23 UTC (permalink / raw)
To: devicetree, digetx, jonathanh, ldewangan, linux-i2c, linux-kernel,
linux-tegra, mperttunen, robh+dt, thierry.reding
Cc: akhilrajeev
In-Reply-To: <1642850607-20664-1-git-send-email-akhilrajeev@nvidia.com>
Add device tree nodes for Tegra234 I2C controllers
Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
---
arch/arm64/boot/dts/nvidia/tegra234.dtsi | 121 +++++++++++++++++++++++++++++++
1 file changed, 121 insertions(+)
diff --git a/arch/arm64/boot/dts/nvidia/tegra234.dtsi b/arch/arm64/boot/dts/nvidia/tegra234.dtsi
index 6b6f1580..c686827 100644
--- a/arch/arm64/boot/dts/nvidia/tegra234.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra234.dtsi
@@ -144,6 +144,96 @@
status = "disabled";
};
+ gen1_i2c: i2c@3160000 {
+ compatible = "nvidia,tegra194-i2c";
+ reg = <0x3160000 0x100>;
+ status = "disabled";
+ interrupts = <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>;
+ clock-frequency = <400000>;
+ clocks = <&bpmp TEGRA234_CLK_I2C1
+ &bpmp TEGRA234_CLK_PLLP_OUT0>;
+ assigned-clocks = <&bpmp TEGRA234_CLK_I2C1>;
+ assigned-clock-parents = <&bpmp TEGRA234_CLK_PLLP_OUT0>;
+ clock-names = "div-clk", "parent";
+ resets = <&bpmp TEGRA234_RESET_I2C1>;
+ reset-names = "i2c";
+ };
+
+ cam_i2c: i2c@3180000 {
+ compatible = "nvidia,tegra194-i2c";
+ reg = <0x3180000 0x100>;
+ interrupts = <GIC_SPI 27 IRQ_TYPE_LEVEL_HIGH>;
+ status = "disabled";
+ clock-frequency = <400000>;
+ clocks = <&bpmp TEGRA234_CLK_I2C3
+ &bpmp TEGRA234_CLK_PLLP_OUT0>;
+ assigned-clocks = <&bpmp TEGRA234_CLK_I2C3>;
+ assigned-clock-parents = <&bpmp TEGRA234_CLK_PLLP_OUT0>;
+ clock-names = "div-clk", "parent";
+ resets = <&bpmp TEGRA234_RESET_I2C3>;
+ reset-names = "i2c";
+ };
+
+ dp_aux_ch1_i2c: i2c@3190000 {
+ compatible = "nvidia,tegra194-i2c";
+ reg = <0x3190000 0x100>;
+ interrupts = <GIC_SPI 28 IRQ_TYPE_LEVEL_HIGH>;
+ status = "disabled";
+ clock-frequency = <100000>;
+ clocks = <&bpmp TEGRA234_CLK_I2C4
+ &bpmp TEGRA234_CLK_PLLP_OUT0>;
+ assigned-clocks = <&bpmp TEGRA234_CLK_I2C4>;
+ assigned-clock-parents = <&bpmp TEGRA234_CLK_PLLP_OUT0>;
+ clock-names = "div-clk", "parent";
+ resets = <&bpmp TEGRA234_RESET_I2C4>;
+ reset-names = "i2c";
+ };
+
+ dp_aux_ch0_i2c: i2c@31b0000 {
+ compatible = "nvidia,tegra194-i2c";
+ reg = <0x31b0000 0x100>;
+ interrupts = <GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH>;
+ status = "disabled";
+ clock-frequency = <100000>;
+ clocks = <&bpmp TEGRA234_CLK_I2C6
+ &bpmp TEGRA234_CLK_PLLP_OUT0>;
+ assigned-clocks = <&bpmp TEGRA234_CLK_I2C6>;
+ assigned-clock-parents = <&bpmp TEGRA234_CLK_PLLP_OUT0>;
+ clock-names = "div-clk", "parent";
+ resets = <&bpmp TEGRA234_RESET_I2C6>;
+ reset-names = "i2c";
+ };
+
+ dp_aux_ch2_i2c: i2c@31c0000 {
+ compatible = "nvidia,tegra194-i2c";
+ reg = <0x31c0000 0x100>;
+ interrupts = <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>;
+ status = "disabled";
+ clock-frequency = <100000>;
+ clocks = <&bpmp TEGRA234_CLK_I2C7
+ &bpmp TEGRA234_CLK_PLLP_OUT0>;
+ assigned-clocks = <&bpmp TEGRA234_CLK_I2C7>;
+ assigned-clock-parents = <&bpmp TEGRA234_CLK_PLLP_OUT0>;
+ clock-names = "div-clk", "parent";
+ resets = <&bpmp TEGRA234_RESET_I2C7>;
+ reset-names = "i2c";
+ };
+
+ dp_aux_ch3_i2c: i2c@31e0000 {
+ compatible = "nvidia,tegra194-i2c";
+ reg = <0x31e0000 0x100>;
+ interrupts = <GIC_SPI 33 IRQ_TYPE_LEVEL_HIGH>;
+ status = "disabled";
+ clock-frequency = <100000>;
+ clocks = <&bpmp TEGRA234_CLK_I2C9
+ &bpmp TEGRA234_CLK_PLLP_OUT0>;
+ assigned-clocks = <&bpmp TEGRA234_CLK_I2C9>;
+ assigned-clock-parents = <&bpmp TEGRA234_CLK_PLLP_OUT0>;
+ clock-names = "div-clk", "parent";
+ resets = <&bpmp TEGRA234_RESET_I2C9>;
+ reset-names = "i2c";
+ };
+
mmc@3460000 {
compatible = "nvidia,tegra234-sdhci", "nvidia,tegra186-sdhci";
reg = <0x03460000 0x20000>;
@@ -212,6 +302,37 @@
#mbox-cells = <2>;
};
+ gen2_i2c: i2c@c240000 {
+ compatible = "nvidia,tegra194-i2c";
+ reg = <0xc240000 0x100>;
+ interrupts = <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>;
+ status = "disabled";
+ clock-frequency = <100000>;
+ clocks = <&bpmp TEGRA234_CLK_I2C2
+ &bpmp TEGRA234_CLK_PLLP_OUT0>;
+ clock-names = "div-clk", "parent";
+ assigned-clocks = <&bpmp TEGRA234_CLK_I2C2>;
+ assigned-clock-parents = <&bpmp TEGRA234_CLK_PLLP_OUT0>;
+ resets = <&bpmp TEGRA234_RESET_I2C2>;
+ reset-names = "i2c";
+ };
+
+ gen8_i2c: i2c@c250000 {
+ compatible = "nvidia,tegra194-i2c";
+ reg = <0xc250000 0x100>;
+ nvidia,hw-instance-id = <0x7>;
+ interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>;
+ status = "disabled";
+ clock-frequency = <400000>;
+ clocks = <&bpmp TEGRA234_CLK_I2C8
+ &bpmp TEGRA234_CLK_PLLP_OUT0>;
+ clock-names = "div-clk", "parent";
+ assigned-clocks = <&bpmp TEGRA234_CLK_I2C8>;
+ assigned-clock-parents = <&bpmp TEGRA234_CLK_PLLP_OUT0>;
+ resets = <&bpmp TEGRA234_RESET_I2C8>;
+ reset-names = "i2c";
+ };
+
rtc@c2a0000 {
compatible = "nvidia,tegra234-rtc", "nvidia,tegra20-rtc";
reg = <0x0c2a0000 0x10000>;
--
2.7.4
^ permalink raw reply related
* [PATCH v2 3/4] dt-bindings: Add headers for Tegra234 PWM
From: Akhil R @ 2022-01-22 11:23 UTC (permalink / raw)
To: devicetree, digetx, jonathanh, ldewangan, linux-i2c, linux-kernel,
linux-tegra, mperttunen, robh+dt, thierry.reding
Cc: akhilrajeev
In-Reply-To: <1642850607-20664-1-git-send-email-akhilrajeev@nvidia.com>
Add dt-bindings header files for PWM of Tegra234
Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
---
include/dt-bindings/clock/tegra234-clock.h | 17 +++++++++++++++++
include/dt-bindings/reset/tegra234-reset.h | 8 ++++++++
2 files changed, 25 insertions(+)
diff --git a/include/dt-bindings/clock/tegra234-clock.h b/include/dt-bindings/clock/tegra234-clock.h
index 5d05c19..9d17309 100644
--- a/include/dt-bindings/clock/tegra234-clock.h
+++ b/include/dt-bindings/clock/tegra234-clock.h
@@ -50,4 +50,21 @@
/** @brief PLLP clk output */
#define TEGRA234_CLK_PLLP_OUT0 102U
+/** @brief output of mux controlled by CLK_RST_CONTROLLER_CLK_SOURCE_PWM1 */
+#define TEGRA234_CLK_PWM1 105U
+/** @brief output of mux controlled by CLK_RST_CONTROLLER_CLK_SOURCE_PWM2 */
+#define TEGRA234_CLK_PWM2 106U
+/** @brief output of mux controlled by CLK_RST_CONTROLLER_CLK_SOURCE_PWM3 */
+#define TEGRA234_CLK_PWM3 107U
+/** @brief output of mux controlled by CLK_RST_CONTROLLER_CLK_SOURCE_PWM4 */
+#define TEGRA234_CLK_PWM4 108U
+/** @brief output of mux controlled by CLK_RST_CONTROLLER_CLK_SOURCE_PWM5 */
+#define TEGRA234_CLK_PWM5 109U
+/** @brief output of mux controlled by CLK_RST_CONTROLLER_CLK_SOURCE_PWM6 */
+#define TEGRA234_CLK_PWM6 110U
+/** @brief output of mux controlled by CLK_RST_CONTROLLER_CLK_SOURCE_PWM7 */
+#define TEGRA234_CLK_PWM7 111U
+/** @brief output of mux controlled by CLK_RST_CONTROLLER_CLK_SOURCE_PWM8 */
+#define TEGRA234_CLK_PWM8 112U
+
#endif
diff --git a/include/dt-bindings/reset/tegra234-reset.h b/include/dt-bindings/reset/tegra234-reset.h
index e07e898..288524f 100644
--- a/include/dt-bindings/reset/tegra234-reset.h
+++ b/include/dt-bindings/reset/tegra234-reset.h
@@ -20,6 +20,14 @@
#define TEGRA234_RESET_I2C7 33U
#define TEGRA234_RESET_I2C8 34U
#define TEGRA234_RESET_I2C9 35U
+#define TEGRA234_RESET_PWM1 68U
+#define TEGRA234_RESET_PWM2 69U
+#define TEGRA234_RESET_PWM3 70U
+#define TEGRA234_RESET_PWM4 71U
+#define TEGRA234_RESET_PWM5 72U
+#define TEGRA234_RESET_PWM6 73U
+#define TEGRA234_RESET_PWM7 74U
+#define TEGRA234_RESET_PWM8 75U
/** @} */
--
2.7.4
^ permalink raw reply related
* [PATCH v2 4/4] arm64: tegra: Add Tegra234 PWM devicetree nodes
From: Akhil R @ 2022-01-22 11:23 UTC (permalink / raw)
To: devicetree, digetx, jonathanh, ldewangan, linux-i2c, linux-kernel,
linux-tegra, mperttunen, robh+dt, thierry.reding
Cc: akhilrajeev
In-Reply-To: <1642850607-20664-1-git-send-email-akhilrajeev@nvidia.com>
Add device tree nodes for Tegra234 PWM
Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
---
arch/arm64/boot/dts/nvidia/tegra234.dtsi | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/arch/arm64/boot/dts/nvidia/tegra234.dtsi b/arch/arm64/boot/dts/nvidia/tegra234.dtsi
index c686827..cbebf1e 100644
--- a/arch/arm64/boot/dts/nvidia/tegra234.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra234.dtsi
@@ -234,6 +234,18 @@
reset-names = "i2c";
};
+ pwm1: pwm@3280000 {
+ compatible = "nvidia,tegra194-pwm",
+ "nvidia,tegra186-pwm";
+ reg = <0x3280000 0x10000>;
+ clocks = <&bpmp TEGRA234_CLK_PWM1>;
+ clock-names = "pwm";
+ resets = <&bpmp TEGRA234_RESET_PWM1>;
+ reset-names = "pwm";
+ status = "disabled";
+ #pwm-cells = <2>;
+ };
+
mmc@3460000 {
compatible = "nvidia,tegra234-sdhci", "nvidia,tegra186-sdhci";
reg = <0x03460000 0x20000>;
--
2.7.4
^ permalink raw reply related
* Re: [PATCH RFC 1/4] brcmfmac: use separate firmware for 43430 revision 4
From: Stefan Wahren @ 2022-01-22 12:35 UTC (permalink / raw)
To: Rob Herring, Florian Fainelli, Nicolas Saenz Julienne,
Arend van Spriel, Franky Lin, Hante Meuleman, Chi-hsien Lin,
Wright Feng, Chung-hsien Hsu, Kalle Valo
Cc: Ray Jui, Scott Branden, bcm-kernel-feedback-list, Arnd Bergmann,
Olof Johansson, Phil Elwell, devicetree, soc, linux-arm-kernel,
linux-wireless, brcm80211-dev-list.pdl, linux-rpi-kernel
In-Reply-To: <1641068812-5851-2-git-send-email-stefan.wahren@i2se.com>
Am 01.01.22 um 21:26 schrieb Stefan Wahren:
> A separate firmware is needed, for Broadcom 43430 revision 4. This
> chip can be found on e.g. certain revisions of Raspberry Pi Zero 2 W.
> Original firmware file from IC vendor is named 'brcmfmac43436-sdio.bin',
> but brcmfmac and also btbcm drivers report chip id 43430, so requested
> firmware file name is 'brcmfmac43430c0-sdio.bin' in line with other
> 43430 revisions.
>
> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
> ---
>
> Hi,
> i'm not sure about all these mappings. All i can say is that the wifi
> interface of the RPi Zero 2 cames up with this patch.
gentle ping (yes, i'm aware of the merge window)
>
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
> index 8effeb7..c79bd47 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
> @@ -618,6 +618,7 @@ BRCMF_FW_DEF(43430A0, "brcmfmac43430a0-sdio");
> /* Note the names are not postfixed with a1 for backward compatibility */
> BRCMF_FW_CLM_DEF(43430A1, "brcmfmac43430-sdio");
> BRCMF_FW_DEF(43430B0, "brcmfmac43430b0-sdio");
> +BRCMF_FW_CLM_DEF(43430C0, "brcmfmac43430c0-sdio");
> BRCMF_FW_CLM_DEF(43455, "brcmfmac43455-sdio");
> BRCMF_FW_DEF(43456, "brcmfmac43456-sdio");
> BRCMF_FW_CLM_DEF(4354, "brcmfmac4354-sdio");
> @@ -649,7 +650,8 @@ static const struct brcmf_firmware_mapping brcmf_sdio_fwnames[] = {
> BRCMF_FW_ENTRY(BRCM_CC_4339_CHIP_ID, 0xFFFFFFFF, 4339),
> BRCMF_FW_ENTRY(BRCM_CC_43430_CHIP_ID, 0x00000001, 43430A0),
> BRCMF_FW_ENTRY(BRCM_CC_43430_CHIP_ID, 0x00000002, 43430A1),
> - BRCMF_FW_ENTRY(BRCM_CC_43430_CHIP_ID, 0xFFFFFFFC, 43430B0),
> + BRCMF_FW_ENTRY(BRCM_CC_43430_CHIP_ID, 0x00000004, 43430C0),
> + BRCMF_FW_ENTRY(BRCM_CC_43430_CHIP_ID, 0xFFFFFFF8, 43430B0),
> BRCMF_FW_ENTRY(BRCM_CC_4345_CHIP_ID, 0x00000200, 43456),
> BRCMF_FW_ENTRY(BRCM_CC_4345_CHIP_ID, 0xFFFFFDC0, 43455),
> BRCMF_FW_ENTRY(BRCM_CC_4354_CHIP_ID, 0xFFFFFFFF, 4354),
^ permalink raw reply
* Re: [PATCH v3 4/6] dt-bindings: interrupt-controller: realtek,rtl-intc: require parents
From: Sander Vanheule @ 2022-01-22 12:49 UTC (permalink / raw)
To: Rob Herring
Cc: linux-kernel, devicetree, Thomas Gleixner, Marc Zyngier,
Birger Koblitz, Bert Vermeulen, John Crispin
In-Reply-To: <Yes6NFgUmcIcc5mm@robh.at.kernel.org>
Hi Rob,
On Fri, 2022-01-21 at 16:56 -0600, Rob Herring wrote:
> On Sun, Jan 09, 2022 at 03:54:35PM +0100, Sander Vanheule wrote:
> > The interrupt router has 32 inputs and up to 15 outputs, and the way
> > these are mapped to each other is runtime configurable. The outputs of
> > this interrupt router on the other hand, are connected to a fixed set of
> > parent interrupts. This means that "interrupt-map" is inappropriate, and
> > rather a list of parent interrupts should be specified.
>
> I'm not sure why interrupt-map is not appropriate. It is not appropriate
> if you have to touch the interrupt router h/w in servicing the
> interrupts. If you just need one time configuration of the mapping, then
> it should be fine to use I think.
If interrupt-map is used, then AFAICT there are no hooks to inform the driver that a
translation has occurred. How should the interrupt controller driver then know how to set
up the routing? Commit de4adddcbcc2 ("of/irq: Add a quirk for controllers with their own
definition of interrupt-map") added a quirk for the original binding/driver, but that
requires open-coding an interrupt-map parser in the driver.
What this binding doesn't mention (I can add it), is that there are also two IRQ status
registers to:
- unmask/mask SoC interrupts
- read the current status of the SoC interrupts
In theory, if the routing is set up correctly (and the IRQ permanently unmasked), I think
one could treat interrupt-map as intended, and connect SoC peripheral IRQ handlers
directly to the parent interrupts. But then the interrupt subsystem would need to check
all attached handlers. This interrupt router/controller allows to check which peripheral
is triggering the parent IRQ, which should be more efficient.
These interrupt controllers are also used on multi-threaded systems, where each hardware
thread has its own IRQ controller. I'm still experimenting with the implementation, but
there the routing registers would be used to set the CPU affinity of SoC interrupts.
I have to say that I'm not very familiar with the kernel code that handles all this
though, so maybe I'm just missing something?
> > Two-part compatibles are introduced to be able to require "interrupts"
> > for new devicetrees. The relevant descriptions are extended or added to
> > more clearly describe the inputs and outputs of this router. The old
> > compatible, "interrupt-map" and "#address-cells", is deprecated.
> > Interrupt specifiers for new compatibles will require two cells, to
> > indicate the output selection.
> >
> > To prevent spurious changes when more SoCs are added, "allOf" is used
> > with one "if", and the compatible enum only has one item.
> >
> > The example is updated to provide a correct example for RTL8380 SoCs.
> >
> > Signed-off-by: Sander Vanheule <sander@svanheule.net>
> > ---
> > .../realtek,rtl-intc.yaml | 78 ++++++++++++++-----
> > 1 file changed, 58 insertions(+), 20 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/interrupt-controller/realtek,rtl-
> > intc.yaml b/Documentation/devicetree/bindings/interrupt-controller/realtek,rtl-
> > intc.yaml
> > index 9e76fff20323..aab8d44010af 100644
> > --- a/Documentation/devicetree/bindings/interrupt-controller/realtek,rtl-intc.yaml
> > +++ b/Documentation/devicetree/bindings/interrupt-controller/realtek,rtl-intc.yaml
> > @@ -6,6 +6,10 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
> >
> > title: Realtek RTL SoC interrupt controller devicetree bindings
> >
> > +description:
> > + Interrupt router for Realtek MIPS SoCs, allowing each SoC interrupt to be
> > + routed to one parent interrupt, or left disconnected.
> > +
> > maintainers:
> > - Birger Koblitz <mail@birger-koblitz.de>
> > - Bert Vermeulen <bert@biot.com>
> > @@ -13,45 +17,79 @@ maintainers:
> >
> > properties:
> > compatible:
> > - const: realtek,rtl-intc
> > + oneOf:
> > + - items:
> > + - enum:
> > + - realtek,rtl8380-intc
> > + - const: realtek,rtl-intc
> > + - const: realtek,rtl-intc
> > + deprecated: true
> >
> > - "#interrupt-cells":
> > - const: 1
> > + "#interrupt-cells": true
> >
> > reg:
> > maxItems: 1
> >
> > interrupts:
> > - maxItems: 1
> > + minItems: 1
> > + maxItems: 15
> > + description:
> > + List of parent interrupts, in the order that they are connected to this
> > + interrupt router's outputs.
> >
> > interrupt-controller: true
> >
> > - "#address-cells":
> > - const: 0
> > -
> > - interrupt-map:
> > - description: Describes mapping from SoC interrupts to CPU interrupts
> > -
> > required:
> > - compatible
> > - reg
> > - "#interrupt-cells"
> > - interrupt-controller
> > - - "#address-cells"
> > - - interrupt-map
> > +
> > +allOf:
> > + - if:
> > + properties:
> > + compatible:
> > + const: realtek,rtl-intc
> > + then:
> > + properties:
> > + "#interrupt-cells":
> > + const: 1
> > +
> > + "#address-cells":
> > + const: 0
> > +
> > + interrupt-map: true
> > + required:
> > + - "#address-cells"
> > + - interrupt-map
> > + else:
> > + properties:
> > + "#interrupt-cells":
> > + description:
> > + Two cells to specify which line to connect to, and which output it should
> > + be routed to. Both cells use a zero-based index.
>
> Picking the index picks the priority? Which is higher priority?
Yes, picking an output will select the (implied) priority. If the parent interrupts are
the six MIPS CPU HW interrupts, then CPU IRQ7 has the highest priority, and IRQ2 has the
lowest priority. All known implementations connect output (0..5) to CPU IRQ(2..7), so
lower output index then means lower priority.
Best,
Sander
>
>
> > + const: 2
> > + required:
> > + - interrupts
> >
> > additionalProperties: false
> >
> > examples:
> > - |
> > intc: interrupt-controller@3000 {
> > - compatible = "realtek,rtl-intc";
> > - #interrupt-cells = <1>;
> > + compatible = "realtek,rtl8380-intc", "realtek,rtl-intc";
> > + #interrupt-cells = <2>;
> > interrupt-controller;
> > - reg = <0x3000 0x20>;
> > - #address-cells = <0>;
> > - interrupt-map =
> > - <31 &cpuintc 2>,
> > - <30 &cpuintc 1>,
> > - <29 &cpuintc 5>;
> > + reg = <0x3000 0x18>;
> > +
> > + interrupt-parent = <&cpuintc>;
> > + interrupts = <2>, <3>, <4>, <5>, <6>;
> > + };
> > +
> > + irq-consumer@0 {
> > + reg = <0 4>;
> > + interrupt-parent = <&intc>;
> > + interrupts =
> > + <19 3>, /* IRQ 19, routed to output 3 (cpuintc 5) */
> > + <18 4>; /* IRQ 18, routed to output 4 (cpuintc 6) */
> > };
> > --
> > 2.33.1
> >
> >
^ permalink raw reply
* [PATCH] ARM: dts: exynos: use define for TMU clock on Exynos4412
From: Krzysztof Kozlowski @ 2022-01-22 13:14 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, devicetree, linux-arm-kernel,
linux-samsung-soc, linux-kernel
Replace clock hard-coded number with a define from bindings. No
functional change.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
---
arch/arm/boot/dts/exynos4412.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/exynos4412.dtsi b/arch/arm/boot/dts/exynos4412.dtsi
index d3802046c8b8..aa0b61b59970 100644
--- a/arch/arm/boot/dts/exynos4412.dtsi
+++ b/arch/arm/boot/dts/exynos4412.dtsi
@@ -813,7 +813,7 @@ &tmu {
interrupt-parent = <&combiner>;
interrupts = <2 4>;
reg = <0x100C0000 0x100>;
- clocks = <&clock 383>;
+ clocks = <&clock CLK_TMU_APBIF>;
clock-names = "tmu_apbif";
status = "disabled";
};
--
2.32.0
^ permalink raw reply related
* [PATCH 1/3] ARM: dts: exynos: drop old thermal properties from Exynos4210
From: Krzysztof Kozlowski @ 2022-01-22 13:25 UTC (permalink / raw)
To: Rafael J. Wysocki, Daniel Lezcano, Amit Kucheria, Zhang Rui,
Rob Herring, Krzysztof Kozlowski, Bartlomiej Zolnierkiewicz,
linux-pm, devicetree, linux-arm-kernel, linux-samsung-soc,
linux-kernel
The samsung,tmu_gain and samsung,tmu_reference_voltage properties of
Exynos Thermal Management Unit driver are not used since April 2018.
They were removed with commit fccfe0993b5d ("thermal: exynos: remove
parsing of samsung,tmu_gain property") and commit 61020d189dbc
("thermal: exynos: remove parsing of samsung, tmu_reference_voltage
property"), so drop them also from Exynos4210 DTS.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
---
I'll take this patch via Samsung SoC. Adding here for reference, so
Rob's robot will not spot DTS issues when checking against dtschema.
---
arch/arm/boot/dts/exynos4210.dtsi | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4210.dtsi b/arch/arm/boot/dts/exynos4210.dtsi
index 7e7d65ce6585..2c25cc37934e 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -527,8 +527,6 @@ &tmu {
compatible = "samsung,exynos4210-tmu";
clocks = <&clock CLK_TMU_APBIF>;
clock-names = "tmu_apbif";
- samsung,tmu_gain = <15>;
- samsung,tmu_reference_voltage = <7>;
};
#include "exynos4210-pinctrl.dtsi"
--
2.32.0
^ permalink raw reply related
* [PATCH 3/3] MAINTAINERS: thermal: samsung: drop obsolete properties
From: Krzysztof Kozlowski @ 2022-01-22 13:25 UTC (permalink / raw)
To: Rafael J. Wysocki, Daniel Lezcano, Amit Kucheria, Zhang Rui,
Rob Herring, Krzysztof Kozlowski, Bartlomiej Zolnierkiewicz,
linux-pm, devicetree, linux-arm-kernel, linux-samsung-soc,
linux-kernel
In-Reply-To: <20220122132554.65192-1-krzysztof.kozlowski@canonical.com>
Update the Samsung Exynos SoC thermal driver entry to match reality and
add Krzysztof Kozlowski as co-maintainer (as he maintains entire Samsung
SoC). The rationale:
1. Bartlomiej's Samsung email bounces, since he is not working in
Samsung for some time.
2. The mentioned Lukasz Majewski's Git tree was not updated
since 2015.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
---
MAINTAINERS | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 27730a5a6345..928fb4cebe09 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -17118,11 +17118,12 @@ S: Supported
F: drivers/net/ethernet/samsung/sxgbe/
SAMSUNG THERMAL DRIVER
-M: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
+M: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
+M: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
L: linux-pm@vger.kernel.org
L: linux-samsung-soc@vger.kernel.org
-S: Supported
-T: git https://github.com/lmajewski/linux-samsung-thermal.git
+S: Maintained
+F: Documentation/devicetree/bindings/thermal/samsung,exynos-thermal.yaml
F: drivers/thermal/samsung/
SAMSUNG USB2 PHY DRIVER
--
2.32.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox