* Re: [PATCH v2] PCI: rockchip-host: Fix rockchip_pcie_host_init_port() PERST# handling
From: Damien Le Moal @ 2024-04-01 6:59 UTC (permalink / raw)
To: Dragan Simic
Cc: Shawn Lin, Bjorn Helgaas, Heiko Stuebner, linux-pci,
Lorenzo Pieralisi, Krzysztof Wilczyński, linux-rockchip,
linux-arm-kernel
In-Reply-To: <d1ed4a0bf702d9927d4e9279f19bcf7b@manjaro.org>
On 4/1/24 04:34, Dragan Simic wrote:
> Hello Damien,
>
> Please see my comments below.
>
> On 2024-03-30 04:50, Damien Le Moal wrote:
>> The PCIe specifications (PCI Express Electromechanical Specification
>> rev
>> 2.0, section 2.6.2) mandate that the PERST# signal must remain asserted
>> for at least 100 usec (Tperst-clk) after the PCIe reference clock
>> becomes stable (if a reference clock is supplied), for at least 100
>> msec
>> after the power is stable (Tpvperl).
>>
>> In addition, the PCI Express Base SPecification Rev 2.0, section 6.6.1
>> state that the host should wait for at least 100 msec from the end of a
>> conventional reset (PERST# is de-asserted) before accessing the
>> configuration space of the attached device.
>>
>> Modify rockchip_pcie_host_init_port() by adding two 100ms sleep, one
>> before and after bringing back PESRT signal to high using the ep_gpio
>> GPIO. Comments are also added to clarify this behavior.
>>
>> Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
>> ---
>>
>> Changes from v1:
>> - Add more specification details to the commit message.
>> - Add missing msleep(100) after PERST# is deasserted.
>>
>> drivers/pci/controller/pcie-rockchip-host.c | 12 ++++++++++++
>> 1 file changed, 12 insertions(+)
>>
>> diff --git a/drivers/pci/controller/pcie-rockchip-host.c
>> b/drivers/pci/controller/pcie-rockchip-host.c
>> index 300b9dc85ecc..ff2fa27bd883 100644
>> --- a/drivers/pci/controller/pcie-rockchip-host.c
>> +++ b/drivers/pci/controller/pcie-rockchip-host.c
>> @@ -294,6 +294,7 @@ static int rockchip_pcie_host_init_port(struct
>> rockchip_pcie *rockchip)
>> int err, i = MAX_LANE_NUM;
>> u32 status;
>>
>> + /* Assert PERST */
>> gpiod_set_value_cansleep(rockchip->ep_gpio, 0);
>>
>> err = rockchip_pcie_init_port(rockchip);
>> @@ -322,8 +323,19 @@ static int rockchip_pcie_host_init_port(struct
>> rockchip_pcie *rockchip)
>> rockchip_pcie_write(rockchip, PCIE_CLIENT_LINK_TRAIN_ENABLE,
>> PCIE_CLIENT_CONFIG);
>>
>> + /*
>> + * PCIe CME specifications mandate that PERST be asserted for at
>> + * least 100ms after power is stable.
>> + */
>> + msleep(100);
>
> Perhaps it would be slightly better to use usleep_range()
> instead of msleep().
I can do that, but I fail to see the advantage. Why do you say that it may be
better ?
>
>> gpiod_set_value_cansleep(rockchip->ep_gpio, 1);
>>
>> + /*
>> + * PCIe base specifications rev 2.0 mandate that the host wait for
>> + * 100ms after completion of a conventional reset.
>> + */
>> + msleep(100);
>
> Obviously, the same comment as above applies here.
>
>> +
>> /* 500ms timeout value should be enough for Gen1/2 training */
>> err = readl_poll_timeout(rockchip->apb_base +
>> PCIE_CLIENT_BASIC_STATUS1,
>> status, PCIE_LINK_UP(status), 20,
--
Damien Le Moal
Western Digital Research
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v6 12/14] drm/mediatek: Support CRC in display driver
From: CK Hu (胡俊光) @ 2024-04-01 5:31 UTC (permalink / raw)
To: Shawn Sung (宋孝謙), chunkuang.hu@kernel.org,
angelogioacchino.delregno@collabora.com
Cc: linux-mediatek@lists.infradead.org, linux-kernel@vger.kernel.org,
Bibby Hsieh (謝濟遠),
jason-ch.chen@mediatek.corp-partner.google.com,
Nancy Lin (林欣螢), daniel@ffwll.ch,
p.zabel@pengutronix.de, dri-devel@lists.freedesktop.org,
airlied@gmail.com, sean@poorly.run, matthias.bgg@gmail.com,
fshao@chromium.org, linux-arm-kernel@lists.infradead.org
In-Reply-To: <20240322052829.9893-13-shawn.sung@mediatek.com>
Hi, Shawn:
On Fri, 2024-03-22 at 13:28 +0800, Shawn Sung wrote:
> From: Hsiao Chien Sung <shawn.sung@mediatek.com>
>
> Register CRC related function pointers to support
> CRC retrieval.
>
> Signed-off-by: Hsiao Chien Sung <shawn.sung@mediatek.com>
> ---
> drivers/gpu/drm/mediatek/mtk_crtc.c | 260
> ++++++++++++++++++++++++
> drivers/gpu/drm/mediatek/mtk_crtc.h | 38 ++++
> drivers/gpu/drm/mediatek/mtk_ddp_comp.h | 3 +
> 3 files changed, 301 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_crtc.c
> b/drivers/gpu/drm/mediatek/mtk_crtc.c
> index d811e4e73a36c..6440c5fb336d7 100644
> --- a/drivers/gpu/drm/mediatek/mtk_crtc.c
> +++ b/drivers/gpu/drm/mediatek/mtk_crtc.c
> @@ -18,6 +18,7 @@
> #include <drm/drm_atomic_helper.h>
> #include <drm/drm_probe_helper.h>
> #include <drm/drm_vblank.h>
> +#include <drm/drm_vblank_work.h>
>
> #include "mtk_crtc.h"
> #include "mtk_ddp_comp.h"
> @@ -69,6 +70,9 @@ struct mtk_crtc {
> /* lock for display hardware access */
> struct mutex hw_lock;
> bool config_updating;
> +
> + struct mtk_ddp_comp *crc_provider;
> + struct drm_vblank_work crc_work;
> };
>
> struct mtk_crtc_state {
> @@ -703,6 +707,71 @@ static void mtk_crtc_update_output(struct
> drm_crtc *crtc,
> }
> }
>
> +static void mtk_crtc_crc_work(struct kthread_work *base)
> +{
> + struct drm_vblank_work *work = to_drm_vblank_work(base);
> + struct mtk_crtc *mtk_crtc =
> + container_of(work, typeof(*mtk_crtc), crc_work);
> +
> + if (mtk_crtc->base.crc.opened) {
> + struct mtk_ddp_comp *comp = mtk_crtc->crc_provider;
> + u64 vblank = drm_crtc_vblank_count(&mtk_crtc->base);
> +
> + comp->funcs->crc_read(comp->dev);
> +
> + /* could take more than 50ms to finish */
> + drm_crtc_add_crc_entry(&mtk_crtc->base, true, vblank,
> + comp->funcs->crc_entry(comp-
> >dev));
It seems that you could regenerate cmdq packet for crc here. So crtc
atomic flush and crc could use the same mailbox channel.
Regards,
CK
> +
> + drm_vblank_work_schedule(&mtk_crtc->crc_work, vblank +
> 1, true);
> + }
> +}
> +
> +static int mtk_crtc_set_crc_source(struct drm_crtc *crtc, const char
> *src)
> +{
> + struct mtk_crtc *mtk_crtc = to_mtk_crtc(crtc);
> +
> + if (!src)
> + return -EINVAL;
> +
> + if (strcmp(src, "auto") != 0) {
> + DRM_ERROR("%s(crtc-%d): unknown source '%s'\n",
> + __func__, drm_crtc_index(crtc), src);
> + return -EINVAL;
> + }
> +
> + /*
> + * skip the first crc because the first frame (vblank + 1) is
> configured
> + * by mtk_crtc_ddp_hw_init() when atomic enable
> + */
> + drm_vblank_work_schedule(&mtk_crtc->crc_work,
> + drm_crtc_vblank_count(crtc) + 2,
> false);
> + return 0;
> +}
> +
> +static int mtk_crtc_verify_crc_source(struct drm_crtc *crtc, const
> char *src,
> + size_t *cnt)
> +{
> + struct mtk_crtc *mtk_crtc = to_mtk_crtc(crtc);
> + struct mtk_ddp_comp *comp = mtk_crtc->crc_provider;
> +
> + if (!comp) {
> + DRM_ERROR("%s(crtc-%d): no crc provider\n",
> + __func__, drm_crtc_index(crtc));
> + return -ENOENT;
> + }
> +
> + if (src && strcmp(src, "auto") != 0) {
> + DRM_ERROR("%s(crtc-%d): unknown source '%s'\n",
> + __func__, drm_crtc_index(crtc), src);
> + return -EINVAL;
> + }
> +
> + *cnt = comp->funcs->crc_cnt(comp->dev);
> +
> + return 0;
> +}
> +
> int mtk_crtc_plane_check(struct drm_crtc *crtc, struct drm_plane
> *plane,
> struct mtk_plane_state *state)
> {
> @@ -751,6 +820,8 @@ static void mtk_crtc_atomic_enable(struct
> drm_crtc *crtc,
>
> drm_crtc_vblank_on(crtc);
> mtk_crtc->enabled = true;
> +
> + drm_vblank_work_init(&mtk_crtc->crc_work, crtc,
> mtk_crtc_crc_work);
> }
>
> static void mtk_crtc_atomic_disable(struct drm_crtc *crtc,
> @@ -840,6 +911,8 @@ static const struct drm_crtc_funcs mtk_crtc_funcs
> = {
> .atomic_destroy_state = mtk_crtc_destroy_state,
> .enable_vblank = mtk_crtc_enable_vblank,
> .disable_vblank = mtk_crtc_disable_vblank,
> + .set_crc_source = mtk_crtc_set_crc_source,
> + .verify_crc_source = mtk_crtc_verify_crc_source,
> };
>
> static const struct drm_crtc_helper_funcs mtk_crtc_helper_funcs = {
> @@ -1033,6 +1106,11 @@ int mtk_crtc_create(struct drm_device
> *drm_dev, const unsigned int *path,
>
> if (comp->funcs->ctm_set)
> has_ctm = true;
> +
> + if (comp->funcs->crc_cnt &&
> + comp->funcs->crc_entry &&
> + comp->funcs->crc_read)
> + mtk_crtc->crc_provider = comp;
> }
>
> mtk_ddp_comp_register_vblank_cb(comp, mtk_crtc_ddp_irq,
> @@ -1136,3 +1214,185 @@ int mtk_crtc_create(struct drm_device
> *drm_dev, const unsigned int *path,
>
> return 0;
> }
> +
> +void mtk_crtc_init_crc(struct mtk_crtc_crc *crc, const u32
> *crc_offset_table,
> + size_t crc_count, u32 reset_offset, u32
> reset_mask)
> +{
> + crc->ofs = crc_offset_table;
> + crc->cnt = crc_count;
> + crc->rst_ofs = reset_offset;
> + crc->rst_msk = reset_mask;
> + crc->va = kcalloc(crc->cnt, sizeof(*crc->va), GFP_KERNEL);
> + if (!crc->va) {
> + DRM_ERROR("failed to allocate memory for crc\n");
> + crc->cnt = 0;
> + }
> +}
> +
> +void mtk_crtc_read_crc(struct mtk_crtc_crc *crc, void __iomem *reg)
> +{
> + if (!crc->cnt || !crc->ofs || !crc->va)
> + return;
> +
> +#if IS_REACHABLE(CONFIG_MTK_CMDQ)
> + /* sync to see the most up-to-date copy of the DMA buffer */
> + dma_sync_single_for_cpu(crc->cmdq_client.chan->mbox->dev,
> + crc->pa, crc->cnt * sizeof(*crc->va),
> + DMA_FROM_DEVICE);
> +#endif
> +}
> +
> +void mtk_crtc_destroy_crc(struct mtk_crtc_crc *crc)
> +{
> + if (!crc->cnt)
> + return;
> +
> +#if IS_REACHABLE(CONFIG_MTK_CMDQ)
> + if (crc->pa) {
> + dma_unmap_single(crc->cmdq_client.chan->mbox->dev,
> + crc->pa, crc->cnt * sizeof(*crc->va),
> + DMA_TO_DEVICE);
> + crc->pa = 0;
> + }
> + if (crc->cmdq_client.chan) {
> + mtk_drm_cmdq_pkt_destroy(&crc->cmdq_handle);
> + mbox_free_channel(crc->cmdq_client.chan);
> + crc->cmdq_client.chan = NULL;
> + }
> +#endif
> + kfree(crc->va);
> + crc->va = NULL;
> + crc->cnt = 0;
> +}
> +
> +#if IS_REACHABLE(CONFIG_MTK_CMDQ)
> +/**
> + * mtk_crtc_create_crc_cmdq - Create a CMDQ thread for syncing the
> CRCs
> + * @dev: Kernel device node of the CRC provider
> + * @crc: Pointer of the CRC to init
> + *
> + * This function will create a looping thread on GCE (Global Command
> Engine) to
> + * keep the CRC up to date by monitoring the assigned event (usually
> the frame
> + * done event) of the CRC provider, and read the CRCs from the
> registers to a
> + * shared memory for the workqueue to read. To start/stop the
> looping thread,
> + * please call `mtk_crtc_start_crc_cmdq()` and
> `mtk_crtc_stop_crc_cmdq()`
> + * defined blow.
> + *
> + * The reason why we don't update the CRCs with CPU is that the
> front porch of
> + * 4K60 timing in CEA-861 is less than 60us, and register read/write
> speed is
> + * relatively unreliable comparing to GCE due to the bus design.
> + *
> + * We must create a new thread instead of using the original one for
> plane
> + * update is because:
> + * 1. We cannot add another wait-for-event command at the end of
> cmdq packet, or
> + * the cmdq callback will delay for too long
> + * 2. Will get the CRC of the previous frame if using the existed
> wait-for-event
> + * command which is at the beginning of the packet
> + */
> +void mtk_crtc_create_crc_cmdq(struct device *dev, struct
> mtk_crtc_crc *crc)
> +{
> + int i;
> +
> + if (!crc->cnt) {
> + dev_warn(dev, "%s: not support\n", __func__);
> + goto cleanup;
> + }
> +
> + if (!crc->ofs) {
> + dev_warn(dev, "%s: not defined\n", __func__);
> + goto cleanup;
> + }
> +
> + crc->cmdq_client.client.dev = dev;
> + crc->cmdq_client.client.tx_block = false;
> + crc->cmdq_client.client.knows_txdone = true;
> + crc->cmdq_client.client.rx_callback = NULL;
> + crc->cmdq_client.chan = mbox_request_channel(&crc-
> >cmdq_client.client, 0);
> + if (IS_ERR(crc->cmdq_client.chan)) {
> + dev_warn(dev, "%s: failed to create mailbox client\n",
> __func__);
> + crc->cmdq_client.chan = NULL;
> + goto cleanup;
> + }
> +
> + if (mtk_drm_cmdq_pkt_create(&crc->cmdq_client, &crc-
> >cmdq_handle, PAGE_SIZE)) {
> + dev_warn(dev, "%s: failed to create cmdq packet\n",
> __func__);
> + goto cleanup;
> + }
> +
> + if (!crc->va) {
> + dev_warn(dev, "%s: no memory\n", __func__);
> + goto cleanup;
> + }
> +
> + /* map the entry to get a dma address for cmdq to store the crc
> */
> + crc->pa = dma_map_single(crc->cmdq_client.chan->mbox->dev,
> + crc->va, crc->cnt * sizeof(*crc->va),
> + DMA_FROM_DEVICE);
> +
> + if (dma_mapping_error(crc->cmdq_client.chan->mbox->dev, crc-
> >pa)) {
> + dev_err(dev, "%s: failed to map dma\n", __func__);
> + goto cleanup;
> + }
> +
> + if (crc->cmdq_event)
> + cmdq_pkt_wfe(&crc->cmdq_handle, crc->cmdq_event, true);
> +
> + for (i = 0; i < crc->cnt; i++) {
> + /* put crc to spr1 register */
> + cmdq_pkt_read_s(&crc->cmdq_handle, crc->cmdq_reg-
> >subsys,
> + crc->cmdq_reg->offset + crc->ofs[i],
> + CMDQ_THR_SPR_IDX1);
> +
> + /* copy spr1 register to physical address of the crc */
> + cmdq_pkt_assign(&crc->cmdq_handle, CMDQ_THR_SPR_IDX0,
> + CMDQ_ADDR_HIGH(crc->pa + i *
> sizeof(*crc->va)));
> + cmdq_pkt_write_s(&crc->cmdq_handle, CMDQ_THR_SPR_IDX0,
> + CMDQ_ADDR_LOW(crc->pa + i *
> sizeof(*crc->va)),
> + CMDQ_THR_SPR_IDX1);
> + }
> + /* reset crc */
> + mtk_ddp_write_mask(&crc->cmdq_handle, ~0, crc->cmdq_reg, 0,
> + crc->rst_ofs, crc->rst_msk);
> +
> + /* clear reset bit */
> + mtk_ddp_write_mask(&crc->cmdq_handle, 0, crc->cmdq_reg, 0,
> + crc->rst_ofs, crc->rst_msk);
> +
> + /* jump to head of the cmdq packet */
> + cmdq_pkt_jump(&crc->cmdq_handle, crc->cmdq_handle.pa_base);
> +
> + return;
> +cleanup:
> + mtk_crtc_destroy_crc(crc);
> +}
> +
> +/**
> + * mtk_crtc_start_crc_cmdq - Start the GCE looping thread for CRC
> update
> + * @crc: Pointer of the CRC information
> + */
> +void mtk_crtc_start_crc_cmdq(struct mtk_crtc_crc *crc)
> +{
> + if (!crc->cmdq_client.chan)
> + return;
> +
> + dma_sync_single_for_device(crc->cmdq_client.chan->mbox->dev,
> + crc->cmdq_handle.pa_base,
> + crc->cmdq_handle.cmd_buf_size,
> + DMA_TO_DEVICE);
> + mbox_send_message(crc->cmdq_client.chan, &crc->cmdq_handle);
> + mbox_client_txdone(crc->cmdq_client.chan, 0);
> +}
> +
> +/**
> + * mtk_crtc_stop_crc_cmdq - Stop the GCE looping thread for CRC
> update
> + * @crc: Pointer of the CRC information
> + */
> +void mtk_crtc_stop_crc_cmdq(struct mtk_crtc_crc *crc)
> +{
> + if (!crc->cmdq_client.chan)
> + return;
> +
> + /* remove all the commands from the cmdq packet */
> + mbox_flush(crc->cmdq_client.chan, 2000);
> +}
> +#endif
> diff --git a/drivers/gpu/drm/mediatek/mtk_crtc.h
> b/drivers/gpu/drm/mediatek/mtk_crtc.h
> index 388e900b6f4de..a79c4611754e4 100644
> --- a/drivers/gpu/drm/mediatek/mtk_crtc.h
> +++ b/drivers/gpu/drm/mediatek/mtk_crtc.h
> @@ -14,6 +14,34 @@
> #define MTK_MAX_BPC 10
> #define MTK_MIN_BPC 3
>
> +/**
> + * struct mtk_crtc_crc - crc related information
> + * @ofs: register offset of crc
> + * @rst_ofs: register offset of crc reset
> + * @rst_msk: register mask of crc reset
> + * @cnt: count of crc
> + * @va: pointer to the start of crc array
> + * @pa: physical address of the crc for gce to access
> + * @cmdq_event: the event to trigger the cmdq
> + * @cmdq_reg: address of the register that cmdq is going to access
> + * @cmdq_client: handler to control cmdq (mbox channel, thread
> ...etc.)
> + * @cmdq_handle: cmdq packet to store the commands
> + */
> +struct mtk_crtc_crc {
> + const u32 *ofs;
> + u32 rst_ofs;
> + u32 rst_msk;
> + size_t cnt;
> + u32 *va;
> +#if IS_REACHABLE(CONFIG_MTK_CMDQ)
> + dma_addr_t pa;
> + u32 cmdq_event;
> + struct cmdq_client_reg *cmdq_reg;
> + struct cmdq_client cmdq_client;
> + struct cmdq_pkt cmdq_handle;
> +#endif
> +};
> +
> void mtk_crtc_commit(struct drm_crtc *crtc);
> int mtk_crtc_create(struct drm_device *drm_dev, const unsigned int
> *path,
> unsigned int path_len, int priv_data_index,
> @@ -25,4 +53,14 @@ void mtk_crtc_async_update(struct drm_crtc *crtc,
> struct drm_plane *plane,
> struct drm_atomic_state *plane_state);
> struct device *mtk_crtc_dma_dev_get(struct drm_crtc *crtc);
>
> +void mtk_crtc_init_crc(struct mtk_crtc_crc *crc, const u32
> *crc_offset_table,
> + size_t crc_count, u32 reset_offset, u32
> reset_mask);
> +void mtk_crtc_read_crc(struct mtk_crtc_crc *crc, void __iomem *reg);
> +void mtk_crtc_destroy_crc(struct mtk_crtc_crc *crc);
> +#if IS_REACHABLE(CONFIG_MTK_CMDQ)
> +void mtk_crtc_create_crc_cmdq(struct device *dev, struct
> mtk_crtc_crc *crc);
> +void mtk_crtc_start_crc_cmdq(struct mtk_crtc_crc *crc);
> +void mtk_crtc_stop_crc_cmdq(struct mtk_crtc_crc *crc);
> +#endif
> +
> #endif /* MTK_CRTC_H */
> diff --git a/drivers/gpu/drm/mediatek/mtk_ddp_comp.h
> b/drivers/gpu/drm/mediatek/mtk_ddp_comp.h
> index f7fe2e08dc8e2..b9c79e740abe0 100644
> --- a/drivers/gpu/drm/mediatek/mtk_ddp_comp.h
> +++ b/drivers/gpu/drm/mediatek/mtk_ddp_comp.h
> @@ -88,6 +88,9 @@ struct mtk_ddp_comp_funcs {
> void (*remove)(struct device *dev, struct mtk_mutex *mutex);
> unsigned int (*encoder_index)(struct device *dev);
> enum drm_mode_status (*mode_valid)(struct device *dev, const
> struct drm_display_mode *mode);
> + size_t (*crc_cnt)(struct device *dev);
> + u32 *(*crc_entry)(struct device *dev);
> + void (*crc_read)(struct device *dev);
> };
>
> struct mtk_ddp_comp {
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] ASoC: dt-bindings: mt2701-wm8960: Convert to dtschema
From: Kartik Agarwala @ 2024-04-01 4:49 UTC (permalink / raw)
To: lgirdwood, broonie, robh, krzysztof.kozlowski+dt, conor+dt,
matthias.bgg, angelogioacchino.delregno
Cc: linux-sound, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek
In-Reply-To: <20240401043505.40972-1-agarwala.kartik@gmail.com>
On 4/1/24 10:05 AM, Kartik Agarwala wrote:
> Convert mt2701-wm890 bindings from text to dtschema. This is used by MediaTek mt77623a/n SoC.
Apologies for the typo, it should be mt7623a/n instead of mt77623a/n.
Regards,
Kartik Agarwala
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] ASoC: dt-bindings: mt2701-wm8960: Convert to dtschema
From: Kartik Agarwala @ 2024-04-01 4:35 UTC (permalink / raw)
To: lgirdwood, broonie, robh, krzysztof.kozlowski+dt, conor+dt,
matthias.bgg, angelogioacchino.delregno
Cc: Kartik Agarwala, linux-sound, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek
Convert mt2701-wm890 bindings from text to dtschema. This is used by MediaTek mt77623a/n SoC.
Signed-off-by: Kartik Agarwala <agarwala.kartik@gmail.com>
---
.../sound/mediatek,mt2701-wm8960.yaml | 59 +++++++++++++++++++
.../bindings/sound/mt2701-wm8960.txt | 24 --------
2 files changed, 59 insertions(+), 24 deletions(-)
create mode 100644 Documentation/devicetree/bindings/sound/mediatek,mt2701-wm8960.yaml
delete mode 100644 Documentation/devicetree/bindings/sound/mt2701-wm8960.txt
diff --git a/Documentation/devicetree/bindings/sound/mediatek,mt2701-wm8960.yaml b/Documentation/devicetree/bindings/sound/mediatek,mt2701-wm8960.yaml
new file mode 100644
index 000000000..771f14a59
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/mediatek,mt2701-wm8960.yaml
@@ -0,0 +1,59 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/mediatek,mt2701-wm8960.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek MT2701 with WM8960 CODEC
+
+maintainers:
+ - Kartik Agarwala <agarwala.kartik@gmail.com>
+
+properties:
+ compatible:
+ const: mediatek,mt2701-wm8960-machine
+
+ mediatek,platform:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: The phandle of MT2701 ASoC platform.
+
+ audio-routing:
+ $ref: /schemas/types.yaml#/definitions/non-unique-string-array
+ description: |
+ A list of the connections between audio components. Each entry is a
+ pair of strings, the first being the connection's sink, the second
+ being the connection's source.
+
+ mediatek,audio-codec:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: The phandle of the WM8960 audio codec.
+
+ pinctrl-names:
+ const: default
+
+ pinctrl-0: true
+
+unevaluatedProperties: false
+
+required:
+ - compatible
+ - mediatek,platform
+ - audio-routing
+ - mediatek,audio-codec
+ - pinctrl-names
+ - pinctrl-0
+
+examples:
+ - |
+ sound {
+ compatible = "mediatek,mt2701-wm8960-machine";
+ mediatek,platform = <&afe>;
+ audio-routing =
+ "Headphone", "HP_L",
+ "Headphone", "HP_R",
+ "LINPUT1", "AMIC",
+ "RINPUT1", "AMIC";
+ mediatek,audio-codec = <&wm8960>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&aud_pins_default>;
+ };
diff --git a/Documentation/devicetree/bindings/sound/mt2701-wm8960.txt b/Documentation/devicetree/bindings/sound/mt2701-wm8960.txt
deleted file mode 100644
index 809b609ea..000000000
--- a/Documentation/devicetree/bindings/sound/mt2701-wm8960.txt
+++ /dev/null
@@ -1,24 +0,0 @@
-MT2701 with WM8960 CODEC
-
-Required properties:
-- compatible: "mediatek,mt2701-wm8960-machine"
-- mediatek,platform: the phandle of MT2701 ASoC platform
-- audio-routing: a list of the connections between audio
-- mediatek,audio-codec: the phandles of wm8960 codec
-- pinctrl-names: Should contain only one value - "default"
-- pinctrl-0: Should specify pin control groups used for this controller.
-
-Example:
-
- sound:sound {
- compatible = "mediatek,mt2701-wm8960-machine";
- mediatek,platform = <&afe>;
- audio-routing =
- "Headphone", "HP_L",
- "Headphone", "HP_R",
- "LINPUT1", "AMIC",
- "RINPUT1", "AMIC";
- mediatek,audio-codec = <&wm8960>;
- pinctrl-names = "default";
- pinctrl-0 = <&aud_pins_default>;
- };
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH 01/11] drm/mediatek: aal: drop driver owner initialization
From: CK Hu (胡俊光) @ 2024-04-01 3:44 UTC (permalink / raw)
To: p.zabel@pengutronix.de, airlied@gmail.com, matthias.bgg@gmail.com,
krzysztof.kozlowski@linaro.org, chunkuang.hu@kernel.org,
angelogioacchino.delregno@collabora.com, daniel@ffwll.ch
Cc: dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
linux-mediatek@lists.infradead.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20240330-b4-module-owner-drm-mediatek-v1-1-fd5c4b8d633e@linaro.org>
Hi, Krzysztof:
On Sat, 2024-03-30 at 21:43 +0100, Krzysztof Kozlowski wrote:
>
> External email : Please do not click links or open attachments until
> you have verified the sender or the content.
> Core in platform_driver_register() already sets the .owner, so
> driver
> does not need to. Whatever is set here will be anyway overwritten by
> main driver calling platform_driver_register().
For the whole series,
Reviewed-by: CK Hu <ck.hu@mediatek.com>
>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> ---
> drivers/gpu/drm/mediatek/mtk_disp_aal.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_aal.c
> b/drivers/gpu/drm/mediatek/mtk_disp_aal.c
> index 40fe403086c3..f6f2c24abc93 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_aal.c
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_aal.c
> @@ -223,7 +223,6 @@ struct platform_driver mtk_disp_aal_driver = {
> .remove_new= mtk_disp_aal_remove,
> .driver= {
> .name= "mediatek-disp-aal",
> -.owner= THIS_MODULE,
> .of_match_table = mtk_disp_aal_driver_dt_match,
> },
> };
>
> --
> 2.34.1
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/7] memory: Remove the now superfluous sentinel element from ctl_table array
From: Miaohe Lin @ 2024-04-01 3:41 UTC (permalink / raw)
To: j.granados
Cc: Luis Chamberlain, linux-mm, linux-kernel, linux-fsdevel, apparmor,
linux-security-module, keyrings, linux-crypto, io-uring,
linux-riscv, linux-arm-kernel, Andrew Morton, Muchun Song,
Naoya Horiguchi, John Johansen, Paul Moore, James Morris,
Serge E. Hallyn, David Howells, Jarkko Sakkinen, Kees Cook,
Herbert Xu, David S. Miller, Jens Axboe, Pavel Begunkov,
Atish Patra, Anup Patel, Will Deacon, Mark Rutland, Paul Walmsley,
Palmer Dabbelt, Albert Ou
In-Reply-To: <20240328-jag-sysctl_remset_misc-v1-1-47c1463b3af2@samsung.com>
On 2024/3/28 23:57, Joel Granados via B4 Relay wrote:
> From: Joel Granados <j.granados@samsung.com>
>
> This commit comes at the tail end of a greater effort to remove the
> empty elements at the end of the ctl_table arrays (sentinels) which will
> reduce the overall build time size of the kernel and run time memory
> bloat by ~64 bytes per sentinel (further information Link :
> https://lore.kernel.org/all/ZO5Yx5JFogGi%2FcBo@bombadil.infradead.org/)
>
> Remove sentinel from all files under mm/ that register a sysctl table.
>
> Signed-off-by: Joel Granados <j.granados@samsung.com>
Reviewed-by: Miaohe Lin <linmiaohe@huawei.com>
Thanks.
> ---
> mm/compaction.c | 1 -
> mm/hugetlb.c | 1 -
> mm/hugetlb_vmemmap.c | 1 -
> mm/memory-failure.c | 1 -
> mm/oom_kill.c | 1 -
> mm/page-writeback.c | 1 -
> mm/page_alloc.c | 1 -
> 7 files changed, 7 deletions(-)
>
> diff --git a/mm/compaction.c b/mm/compaction.c
> index 807b58e6eb68..e8a047afca22 100644
> --- a/mm/compaction.c
> +++ b/mm/compaction.c
> @@ -3345,7 +3345,6 @@ static struct ctl_table vm_compaction[] = {
> .extra1 = SYSCTL_ZERO,
> .extra2 = SYSCTL_ONE,
> },
> - { }
> };
>
> static int __init kcompactd_init(void)
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index 23ef240ba48a..7ac5240a197d 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -5045,7 +5045,6 @@ static struct ctl_table hugetlb_table[] = {
> .mode = 0644,
> .proc_handler = hugetlb_overcommit_handler,
> },
> - { }
> };
>
> static void hugetlb_sysctl_init(void)
> diff --git a/mm/hugetlb_vmemmap.c b/mm/hugetlb_vmemmap.c
> index da177e49d956..b9a55322e52c 100644
> --- a/mm/hugetlb_vmemmap.c
> +++ b/mm/hugetlb_vmemmap.c
> @@ -679,7 +679,6 @@ static struct ctl_table hugetlb_vmemmap_sysctls[] = {
> .mode = 0644,
> .proc_handler = proc_dobool,
> },
> - { }
> };
>
> static int __init hugetlb_vmemmap_init(void)
> diff --git a/mm/memory-failure.c b/mm/memory-failure.c
> index 9349948f1abf..6a112f9ecf91 100644
> --- a/mm/memory-failure.c
> +++ b/mm/memory-failure.c
> @@ -141,7 +141,6 @@ static struct ctl_table memory_failure_table[] = {
> .extra1 = SYSCTL_ZERO,
> .extra2 = SYSCTL_ONE,
> },
> - { }
> };
>
> /*
> diff --git a/mm/oom_kill.c b/mm/oom_kill.c
> index 8d6a207c3c59..4d7a0004df2c 100644
> --- a/mm/oom_kill.c
> +++ b/mm/oom_kill.c
> @@ -724,7 +724,6 @@ static struct ctl_table vm_oom_kill_table[] = {
> .mode = 0644,
> .proc_handler = proc_dointvec,
> },
> - {}
> };
> #endif
>
> diff --git a/mm/page-writeback.c b/mm/page-writeback.c
> index 3e19b87049db..fba324e1a010 100644
> --- a/mm/page-writeback.c
> +++ b/mm/page-writeback.c
> @@ -2291,7 +2291,6 @@ static struct ctl_table vm_page_writeback_sysctls[] = {
> .mode = 0644,
> .proc_handler = proc_dointvec_jiffies,
> },
> - {}
> };
> #endif
>
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 14d39f34d336..8b9820620fe3 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -6211,7 +6211,6 @@ static struct ctl_table page_alloc_sysctl_table[] = {
> .extra2 = SYSCTL_ONE_HUNDRED,
> },
> #endif
> - {}
> };
>
> void __init page_alloc_sysctl_init(void)
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] drm/mediatek: Init `ddp_comp` with devm_kcalloc()
From: CK Hu (胡俊光) @ 2024-04-01 3:33 UTC (permalink / raw)
To: p.zabel@pengutronix.de, dianders@chromium.org,
chunkuang.hu@kernel.org
Cc: linux-kernel@vger.kernel.org, linux-mediatek@lists.infradead.org,
Jason-JH Lin (林睿祥), daniel@ffwll.ch,
dri-devel@lists.freedesktop.org,
Nathan Lu (呂東霖), airlied@gmail.com,
linux-arm-kernel@lists.infradead.org, matthias.bgg@gmail.com,
angelogioacchino.delregno@collabora.com
In-Reply-To: <20240328092248.1.I2e73c38c0f264ee2fa4a09cdd83994e37ba9f541@changeid>
Hi, Douglas:
On Thu, 2024-03-28 at 09:22 -0700, Douglas Anderson wrote:
>
> External email : Please do not click links or open attachments until
> you have verified the sender or the content.
> In the case where `conn_routes` is true we allocate an extra slot in
> the `ddp_comp` array but mtk_drm_crtc_create() never seemed to
> initialize it in the test case I ran. For me, this caused a later
> crash when we looped through the array in mtk_drm_crtc_mode_valid().
> This showed up for me when I booted with `slub_debug=FZPUA` which
> poisons the memory initially. Without `slub_debug` I couldn't
> reproduce, presumably because the later code handles the value being
> NULL and in most cases (not guaranteed in all cases) the memory the
> allocator returned started out as 0.
>
> It really doesn't hurt to initialize the array with devm_kcalloc()
> since the array is small and the overhead of initting a handful of
> elements to 0 is small. In general initting memory to zero is a safer
> practice and usually it's suggested to only use the non-initting
> alloc
> functions if you really need to.
>
> Let's switch the function to use an allocation function that zeros
> the
> memory. For me, this avoids the crash.
Reviewed-by: CK Hu <ck.hu@mediatek.com>
>
> Fixes: 01389b324c97 ("drm/mediatek: Add connector dynamic selection
> capability")
> Signed-off-by: Douglas Anderson <dianders@chromium.org>
> ---
> I don't have a ton of experience with this driver to know if the fact
> that the array item was still uninitialized when
> mtk_drm_crtc_mode_valid() ran is the sign of a bug that should be
> fixed. However, even if it is a bug and that bug is fixed then
> zeroing
> memory when we allocate is still safer. If it's a bug that this
> memory
> wasn't initialized then please consider this patch a bug report. ;-)
>
> I'll also note that I reproduced this on a downstream 6.1-based
> kernel. It appears that only mt8188 uses `conn_routes` and, as far as
> I can tell, mt8188 isn't supported upstream yet.
>
> drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> index a04499c4f9ca..29207b2756c1 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> @@ -1009,10 +1009,10 @@ int mtk_drm_crtc_create(struct drm_device
> *drm_dev,
>
> mtk_crtc->mmsys_dev = priv->mmsys_dev;
> mtk_crtc->ddp_comp_nr = path_len;
> - mtk_crtc->ddp_comp = devm_kmalloc_array(dev,
> - mtk_crtc->ddp_comp_nr +
> (conn_routes ? 1 : 0),
> - sizeof(*mtk_crtc-
> >ddp_comp),
> - GFP_KERNEL);
> + mtk_crtc->ddp_comp = devm_kcalloc(dev,
> + mtk_crtc->ddp_comp_nr +
> (conn_routes ? 1 : 0),
> + sizeof(*mtk_crtc->ddp_comp),
> + GFP_KERNEL);
> if (!mtk_crtc->ddp_comp)
> return -ENOMEM;
>
> --
> 2.44.0.396.g6e790dbe36-goog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/7] memory: Remove the now superfluous sentinel element from ctl_table array
From: Muchun Song @ 2024-04-01 3:21 UTC (permalink / raw)
To: j.granados
Cc: Andrew Morton, Miaohe Lin, Naoya Horiguchi, John Johansen,
Paul Moore, James Morris, Serge E. Hallyn, David Howells,
Jarkko Sakkinen, Kees Cook, Herbert Xu, David S. Miller,
Jens Axboe, Pavel Begunkov, Atish Patra, Anup Patel, Will Deacon,
Mark Rutland, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Luis Chamberlain, linux-mm, linux-kernel, linux-fsdevel, apparmor,
linux-security-module, keyrings, linux-crypto, io-uring,
linux-riscv, linux-arm-kernel
In-Reply-To: <20240328-jag-sysctl_remset_misc-v1-1-47c1463b3af2@samsung.com>
> On Mar 28, 2024, at 23:57, Joel Granados via B4 Relay <devnull+j.granados.samsung.com@kernel.org> wrote:
>
> From: Joel Granados <j.granados@samsung.com>
>
> This commit comes at the tail end of a greater effort to remove the
> empty elements at the end of the ctl_table arrays (sentinels) which will
> reduce the overall build time size of the kernel and run time memory
> bloat by ~64 bytes per sentinel (further information Link :
> https://lore.kernel.org/all/ZO5Yx5JFogGi%2FcBo@bombadil.infradead.org/)
>
> Remove sentinel from all files under mm/ that register a sysctl table.
>
> Signed-off-by: Joel Granados <j.granados@samsung.com>
Reviewed-by: Muchun Song <muchun.song@linux.dev>
THanks.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 0/4] KVM: arm64: TLBI fixes for the pgtable code
From: Shaoqin Huang @ 2024-04-01 2:57 UTC (permalink / raw)
To: Will Deacon, kvmarm
Cc: linux-arm-kernel, Catalin Marinas, Gavin Shan, Marc Zyngier,
Mostafa Saleh, Oliver Upton, Quentin Perret,
Raghavendra Rao Ananta, Ryan Roberts
In-Reply-To: <20240327124853.11206-1-will@kernel.org>
On 3/27/24 20:48, Will Deacon wrote:
> Hi again,
>
> This is version two of the series I previously posted on Monday:
>
> https://lore.kernel.org/r/20240325185158.8565-1-will@kernel.org
>
> We've got a long weekend coming up in the UK, so I wanted to get this
> out before I chuck the laptop in the river.
>
> Changes since v1 include:
>
> * Add Ryan's Reviewed-by on the third patch
> * Add an extra patch to ensure correct alignment of range TLBI address
> argument
> * Tweak commit messages
>
> Cheers,
>
> Will
Reviewed-by: Shaoqin Huang <shahuang@redhat.com>
>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Gavin Shan <gshan@redhat.com>
> Cc: Marc Zyngier <maz@kernel.org>
> Cc: Mostafa Saleh <smostafa@google.com>
> Cc: Oliver Upton <oliver.upton@linux.dev>
> Cc: Quentin Perret <qperret@google.com>
> Cc: Raghavendra Rao Ananta <rananta@google.com>
> Cc: Ryan Roberts <ryan.roberts@arm.com>
> Cc: Shaoqin Huang <shahuang@redhat.com>
>
> --->8
>
> Will Deacon (4):
> KVM: arm64: Don't defer TLB invalidation when zapping table entries
> KVM: arm64: Don't pass a TLBI level hint when zapping table entries
> KVM: arm64: Use TLBI_TTL_UNKNOWN in __kvm_tlb_flush_vmid_range()
> KVM: arm64: Ensure target address is granule-aligned for range TLBI
>
> arch/arm64/kvm/hyp/nvhe/tlb.c | 3 ++-
> arch/arm64/kvm/hyp/pgtable.c | 23 +++++++++++++++--------
> arch/arm64/kvm/hyp/vhe/tlb.c | 3 ++-
> 3 files changed, 19 insertions(+), 10 deletions(-)
>
--
Shaoqin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v1 2/2] net: stmmac: mmc_core: Add GMAC mmc tx/rx missing statistics
From: Minda Chen @ 2024-04-01 2:44 UTC (permalink / raw)
To: Alexandre Torgue, Jose Abreu, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Maxime Coquelin
Cc: netdev, linux-stm32, linux-arm-kernel, linux-kernel, Minda Chen
In-Reply-To: <20240401024456.41433-1-minda.chen@starfivetech.com>
The missing statistics including Rx_Receive_Error_Packets,
Rx_Control_Packets_Good and Tx_OSize_Packets_Good.
Signed-off-by: Minda Chen <minda.chen@starfivetech.com>
---
drivers/net/ethernet/stmicro/stmmac/mmc.h | 3 +++
drivers/net/ethernet/stmicro/stmmac/mmc_core.c | 6 ++++++
drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c | 3 +++
3 files changed, 12 insertions(+)
diff --git a/drivers/net/ethernet/stmicro/stmmac/mmc.h b/drivers/net/ethernet/stmicro/stmmac/mmc.h
index dff02d75d519..cc189bdc563f 100644
--- a/drivers/net/ethernet/stmicro/stmmac/mmc.h
+++ b/drivers/net/ethernet/stmicro/stmmac/mmc.h
@@ -54,6 +54,7 @@ struct stmmac_counters {
unsigned int mmc_tx_vlan_frame_g;
unsigned int mmc_tx_lpi_usec;
unsigned int mmc_tx_lpi_tran;
+ unsigned int mmc_tx_oversize_g;
/* MMC RX counter registers */
unsigned int mmc_rx_framecount_gb;
@@ -85,6 +86,8 @@ struct stmmac_counters {
unsigned int mmc_rx_discard_frames_gb;
unsigned int mmc_rx_discard_octets_gb;
unsigned int mmc_rx_align_err_frames;
+ unsigned int mmc_rx_error;
+ unsigned int mmc_rx_control_g;
/* IPv4 */
unsigned int mmc_rx_ipv4_gd;
diff --git a/drivers/net/ethernet/stmicro/stmmac/mmc_core.c b/drivers/net/ethernet/stmicro/stmmac/mmc_core.c
index b0db5f4e8fe8..948f12b18de3 100644
--- a/drivers/net/ethernet/stmicro/stmmac/mmc_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/mmc_core.c
@@ -53,6 +53,7 @@
#define MMC_TX_EXCESSDEF 0x6c
#define MMC_TX_PAUSE_FRAME 0x70
#define MMC_TX_VLAN_FRAME_G 0x74
+#define MMC_TX_OVERSIZE_G 0x78
/* MMC RX counter registers */
#define MMC_RX_FRAMECOUNT_GB 0x80
@@ -79,6 +80,8 @@
#define MMC_RX_FIFO_OVERFLOW 0xd4
#define MMC_RX_VLAN_FRAMES_GB 0xd8
#define MMC_RX_WATCHDOG_ERROR 0xdc
+#define MMC_RX_ERROR 0xe0
+#define MMC_RX_CONTROL_G 0xe4
#define MMC_TX_LPI_USEC 0xec
#define MMC_TX_LPI_TRAN 0xf0
@@ -289,6 +292,7 @@ static void dwmac_mmc_read(void __iomem *mmcaddr, struct stmmac_counters *mmc)
mmc->mmc_tx_excessdef += readl(mmcaddr + MMC_TX_EXCESSDEF);
mmc->mmc_tx_pause_frame += readl(mmcaddr + MMC_TX_PAUSE_FRAME);
mmc->mmc_tx_vlan_frame_g += readl(mmcaddr + MMC_TX_VLAN_FRAME_G);
+ mmc->mmc_tx_oversize_g += readl(mmcaddr + MMC_TX_OVERSIZE_G);
mmc->mmc_tx_lpi_usec += readl(mmcaddr + MMC_TX_LPI_USEC);
mmc->mmc_tx_lpi_tran += readl(mmcaddr + MMC_TX_LPI_TRAN);
@@ -324,6 +328,8 @@ static void dwmac_mmc_read(void __iomem *mmcaddr, struct stmmac_counters *mmc)
mmc->mmc_rx_fifo_overflow += readl(mmcaddr + MMC_RX_FIFO_OVERFLOW);
mmc->mmc_rx_vlan_frames_gb += readl(mmcaddr + MMC_RX_VLAN_FRAMES_GB);
mmc->mmc_rx_watchdog_error += readl(mmcaddr + MMC_RX_WATCHDOG_ERROR);
+ mmc->mmc_rx_error += readl(mmcaddr + MMC_RX_ERROR);
+ mmc->mmc_rx_control_g += readl(mmcaddr + MMC_RX_CONTROL_G);
mmc->mmc_rx_lpi_usec += readl(mmcaddr + MMC_RX_LPI_USEC);
mmc->mmc_rx_lpi_tran += readl(mmcaddr + MMC_RX_LPI_TRAN);
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
index e1537a57815f..4517d5162c5a 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
@@ -212,6 +212,7 @@ static const struct stmmac_stats stmmac_mmc[] = {
STMMAC_MMC_STAT(mmc_tx_excessdef),
STMMAC_MMC_STAT(mmc_tx_pause_frame),
STMMAC_MMC_STAT(mmc_tx_vlan_frame_g),
+ STMMAC_MMC_STAT(mmc_tx_oversize_g),
STMMAC_MMC_STAT(mmc_tx_lpi_usec),
STMMAC_MMC_STAT(mmc_tx_lpi_tran),
STMMAC_MMC_STAT(mmc_rx_framecount_gb),
@@ -238,6 +239,8 @@ static const struct stmmac_stats stmmac_mmc[] = {
STMMAC_MMC_STAT(mmc_rx_fifo_overflow),
STMMAC_MMC_STAT(mmc_rx_vlan_frames_gb),
STMMAC_MMC_STAT(mmc_rx_watchdog_error),
+ STMMAC_MMC_STAT(mmc_rx_error),
+ STMMAC_MMC_STAT(mmc_rx_control_g),
STMMAC_MMC_STAT(mmc_rx_lpi_usec),
STMMAC_MMC_STAT(mmc_rx_lpi_tran),
STMMAC_MMC_STAT(mmc_rx_discard_frames_gb),
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v1 1/2] net: stmmac: mmc_core: Add GMAC LPI statistics
From: Minda Chen @ 2024-04-01 2:44 UTC (permalink / raw)
To: Alexandre Torgue, Jose Abreu, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Maxime Coquelin
Cc: netdev, linux-stm32, linux-arm-kernel, linux-kernel, Minda Chen
XGMAC MMC has already added LPI statistics. GMAC MMC lack of these
statistics. Add register definition and reading the LPI statistics
from registers.
Signed-off-by: Minda Chen <minda.chen@starfivetech.com>
---
drivers/net/ethernet/stmicro/stmmac/mmc_core.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/drivers/net/ethernet/stmicro/stmmac/mmc_core.c b/drivers/net/ethernet/stmicro/stmmac/mmc_core.c
index 7eb477faa75a..b0db5f4e8fe8 100644
--- a/drivers/net/ethernet/stmicro/stmmac/mmc_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/mmc_core.c
@@ -79,6 +79,12 @@
#define MMC_RX_FIFO_OVERFLOW 0xd4
#define MMC_RX_VLAN_FRAMES_GB 0xd8
#define MMC_RX_WATCHDOG_ERROR 0xdc
+
+#define MMC_TX_LPI_USEC 0xec
+#define MMC_TX_LPI_TRAN 0xf0
+#define MMC_RX_LPI_USEC 0xf4
+#define MMC_RX_LPI_TRAN 0xf8
+
/* IPC*/
#define MMC_RX_IPC_INTR_MASK 0x100
#define MMC_RX_IPC_INTR 0x108
@@ -283,6 +289,8 @@ static void dwmac_mmc_read(void __iomem *mmcaddr, struct stmmac_counters *mmc)
mmc->mmc_tx_excessdef += readl(mmcaddr + MMC_TX_EXCESSDEF);
mmc->mmc_tx_pause_frame += readl(mmcaddr + MMC_TX_PAUSE_FRAME);
mmc->mmc_tx_vlan_frame_g += readl(mmcaddr + MMC_TX_VLAN_FRAME_G);
+ mmc->mmc_tx_lpi_usec += readl(mmcaddr + MMC_TX_LPI_USEC);
+ mmc->mmc_tx_lpi_tran += readl(mmcaddr + MMC_TX_LPI_TRAN);
/* MMC RX counter registers */
mmc->mmc_rx_framecount_gb += readl(mmcaddr + MMC_RX_FRAMECOUNT_GB);
@@ -316,6 +324,9 @@ static void dwmac_mmc_read(void __iomem *mmcaddr, struct stmmac_counters *mmc)
mmc->mmc_rx_fifo_overflow += readl(mmcaddr + MMC_RX_FIFO_OVERFLOW);
mmc->mmc_rx_vlan_frames_gb += readl(mmcaddr + MMC_RX_VLAN_FRAMES_GB);
mmc->mmc_rx_watchdog_error += readl(mmcaddr + MMC_RX_WATCHDOG_ERROR);
+ mmc->mmc_rx_lpi_usec += readl(mmcaddr + MMC_RX_LPI_USEC);
+ mmc->mmc_rx_lpi_tran += readl(mmcaddr + MMC_RX_LPI_TRAN);
+
/* IPv4 */
mmc->mmc_rx_ipv4_gd += readl(mmcaddr + MMC_RX_IPV4_GD);
mmc->mmc_rx_ipv4_hderr += readl(mmcaddr + MMC_RX_IPV4_HDERR);
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 2/2] ARM: dts: imx6qdl-udoo: Enable USB host
From: Fabio Estevam @ 2024-04-01 2:33 UTC (permalink / raw)
To: shawnguo; +Cc: broonie, linux-arm-kernel, Fabio Estevam
In-Reply-To: <20240401023347.3114484-1-festevam@gmail.com>
From: Fabio Estevam <festevam@denx.de>
Commit 8f2ca252ee1f ("ARM: dts: imx6qdl-udoo: Disable USB host to
work around boot issues") disabled USB host to avoid boot hang.
Properly describe the USB2514 USB hub to fix this issue.
Tested on a imx6q-udoo board and verified that it boots fine
and USB host functionality works.
Signed-off-by: Fabio Estevam <festevam@denx.de>
---
arch/arm/boot/dts/nxp/imx/imx6qdl-udoo.dtsi | 25 ++++++++++-----------
1 file changed, 12 insertions(+), 13 deletions(-)
diff --git a/arch/arm/boot/dts/nxp/imx/imx6qdl-udoo.dtsi b/arch/arm/boot/dts/nxp/imx/imx6qdl-udoo.dtsi
index 647ba5e623dd..14272b42f9a1 100644
--- a/arch/arm/boot/dts/nxp/imx/imx6qdl-udoo.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx6qdl-udoo.dtsi
@@ -59,16 +59,6 @@ panel_in: endpoint {
};
};
- reg_usb_h1_vbus: regulator-usb-h1-vbus {
- compatible = "regulator-fixed";
- regulator-name = "usb_h1_vbus";
- regulator-min-microvolt = <5000000>;
- regulator-max-microvolt = <5000000>;
- enable-active-high;
- startup-delay-us = <2>; /* USB2415 requires a POR of 1 us minimum */
- gpio = <&gpio7 12 0>;
- };
-
reg_panel: regulator-panel {
compatible = "regulator-fixed";
regulator-name = "lcd_panel";
@@ -285,9 +275,18 @@ &uart4 {
&usbh1 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_usbh>;
- vbus-supply = <®_usb_h1_vbus>;
- clocks = <&clks IMX6QDL_CLK_CKO>;
- status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "okay";
+
+ usb-port@1 {
+ compatible = "usb424,2514";
+ reg = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <&clks IMX6QDL_CLK_CKO>;
+ reset-gpios = <&gpio7 12 GPIO_ACTIVE_LOW>;
+ };
};
&usbotg {
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 1/2] ARM: imx_v6_v7_defconfig: Select CONFIG_USB_ONBOARD_HUB
From: Fabio Estevam @ 2024-04-01 2:33 UTC (permalink / raw)
To: shawnguo; +Cc: broonie, linux-arm-kernel, Fabio Estevam
From: Fabio Estevam <festevam@denx.de>
The imx6qdl-udoo board has a USB2514 Hub connected to the
USB Host1 port.
Select CONFIG_USB_ONBOARD_HUB so that USB hub can be functional.
Signed-off-by: Fabio Estevam <festevam@denx.de>
---
arch/arm/configs/imx_v6_v7_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/imx_v6_v7_defconfig b/arch/arm/configs/imx_v6_v7_defconfig
index 7327fce87808..b06128da94e5 100644
--- a/arch/arm/configs/imx_v6_v7_defconfig
+++ b/arch/arm/configs/imx_v6_v7_defconfig
@@ -336,6 +336,7 @@ CONFIG_USB_SERIAL_FTDI_SIO=m
CONFIG_USB_SERIAL_OPTION=m
CONFIG_USB_TEST=m
CONFIG_USB_EHSET_TEST_FIXTURE=m
+CONFIG_USB_ONBOARD_HUB=y
CONFIG_NOP_USB_XCEIV=y
CONFIG_USB_MXS_PHY=y
CONFIG_USB_GADGET=y
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [External] Re: [PATCH bpf-next v2 1/9] bpf: tracing: add support to record and check the accessed args
From: 梦龙董 @ 2024-04-01 2:28 UTC (permalink / raw)
To: Steven Rostedt
Cc: Alexei Starovoitov, Jiri Olsa, Andrii Nakryiko,
Alexei Starovoitov, Daniel Borkmann, Martin KaFai Lau, Eddy Z,
Song Liu, Yonghong Song, John Fastabend, KP Singh,
Stanislav Fomichev, Hao Luo, Alexander Gordeev,
Christian Borntraeger, Sven Schnelle, David S. Miller,
David Ahern, Dave Hansen, X86 ML, Mathieu Desnoyers,
Quentin Monnet, bpf, linux-arm-kernel, LKML, linux-riscv,
linux-s390, Network Development, linux-trace-kernel,
open list:KERNEL SELFTEST FRAMEWORK, linux-stm32
In-Reply-To: <20240330153722.65104301@gandalf.local.home>
On Sun, Mar 31, 2024 at 3:34 AM Steven Rostedt <rostedt@goodmis.org> wrote:
>
> On Sat, 30 Mar 2024 11:18:29 +0800
> 梦龙董 <dongmenglong.8@bytedance.com> wrote:
>
> > > If you really want to have thousands of functions, why not just register it
> > > with ftrace itself. It will give you the arguments via the ftrace_regs
> > > structure. Can't you just register a program as the callback?
> > >
> >
> > Ennn...I don't understand. The main purpose for
> > me to use TRACING is:
> >
> > 1. we can directly access the memory, which is more
> > efficient.
>
> I'm not sure what you mean by the above. Access what memory?
>
We need to use the helper of bpf_probe_read_kernel
when we read "skb->sk" in kprobe, and the "skb" is the
1st arg in ip_rcv(). And we can directly read "skb->sk"
in tracing, which is more efficient. Isn't it?
> > 2. we can obtain the function args in FEXIT, which
> > kretprobe can't do it. And this is the main reason.
>
> I didn't mention kretprobe. If you need access to the exit of the function,
> you can use Masami's fgraph update.
>
> fentry -> ftrace_trampoline -> your_code
>
> For fgraph:
>
> fentry -> ftrace_trampoline -> fgraph [sets up return call] -> your_entry_code
>
> function ret -> fgraph_ret_handler -> your_exit_code
>
> And you will be able to pass data from the entry to the exit code,
> including parameters.
Yeah, the fgraph sounds like a nice solution to my problem.
I'll have a try on it.
Thanks!
Menglong Dong
>
> -- Steve
>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [v1 0/3] Add i.MX8Q HSIO PHY driver support
From: Hongxing Zhu @ 2024-04-01 2:13 UTC (permalink / raw)
To: Krzysztof Kozlowski, vkoul@kernel.org, kishon@kernel.org,
robh+dt@kernel.org, krzysztof.kozlowski+dt@linaro.org,
conor+dt@kernel.org, Frank Li
Cc: linux-phy@lists.infradead.org, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, kernel@pengutronix.de, dl-linux-imx
In-Reply-To: <0b5997e9-97b3-4863-87d0-b70e9d051d42@linaro.org>
> -----Original Message-----
> From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> Sent: 2024年3月30日 19:55
> To: Hongxing Zhu <hongxing.zhu@nxp.com>; vkoul@kernel.org;
> kishon@kernel.org; robh+dt@kernel.org; krzysztof.kozlowski+dt@linaro.org;
> conor+dt@kernel.org; Frank Li <frank.li@nxp.com>
> Cc: linux-phy@lists.infradead.org; devicetree@vger.kernel.org;
> linux-arm-kernel@lists.infradead.org; linux-kernel@vger.kernel.org;
> kernel@pengutronix.de; dl-linux-imx <linux-imx@nxp.com>
> Subject: Re: [v1 0/3] Add i.MX8Q HSIO PHY driver support
>
> On 29/03/2024 09:09, Richard Zhu wrote:
> > v1 changes:
> > - Rebase to the 6.9-rc1, and constify of_phandle_args in xlate.
> > No other changes.
> >
>
> I found some RFC of this... confusing so:
> 1. v1 is the first version. If you send RFC, that RFC is v1, so anything newer is v2 or
> whatever.
>
> 2. One patchset per 24h. Give people chance to actually review your code.
Okay, got that.
Thanks for your comments and suggests.
Best Regards
Richard Zhu
>
> Best regards,
> Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [PATCH v1 2/3] dt-bindings: phy: phy-imx8-pcie: Add binding for i.MX8Q HSIO SerDes PHY
From: Hongxing Zhu @ 2024-04-01 2:12 UTC (permalink / raw)
To: Frank Li
Cc: vkoul@kernel.org, kishon@kernel.org, robh+dt@kernel.org,
krzysztof.kozlowski+dt@linaro.org, conor+dt@kernel.org,
linux-phy@lists.infradead.org, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, kernel@pengutronix.de, dl-linux-imx
In-Reply-To: <ZgbOTgtdEBJyg/By@lizhi-Precision-Tower-5810>
> -----Original Message-----
> From: Frank Li <frank.li@nxp.com>
> Sent: 2024年3月29日 22:21
> To: Hongxing Zhu <hongxing.zhu@nxp.com>
> Cc: vkoul@kernel.org; kishon@kernel.org; robh+dt@kernel.org;
> krzysztof.kozlowski+dt@linaro.org; conor+dt@kernel.org;
> linux-phy@lists.infradead.org; devicetree@vger.kernel.org;
> linux-arm-kernel@lists.infradead.org; linux-kernel@vger.kernel.org;
> kernel@pengutronix.de; dl-linux-imx <linux-imx@nxp.com>
> Subject: Re: [PATCH v1 2/3] dt-bindings: phy: phy-imx8-pcie: Add binding for
> i.MX8Q HSIO SerDes PHY
>
> On Fri, Mar 29, 2024 at 04:09:49PM +0800, Richard Zhu wrote:
> > Add binding for controller ID and HSIO configuration setting of the
> > i.MX8Q HSIO SerDes PHY.
> >
> > Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
> > ---
> > include/dt-bindings/phy/phy-imx8-pcie.h | 26
> > +++++++++++++++++++++++++
> > 1 file changed, 26 insertions(+)
>
> This one should be first patch. (1/3).
>
> After fix small improve
>
> Reviewed-by: Frank Li <Frank.Li@nxp.com>
>
Thanks for your review.
> >
> > diff --git a/include/dt-bindings/phy/phy-imx8-pcie.h
> > b/include/dt-bindings/phy/phy-imx8-pcie.h
> > index 8bbe2d6538d8..5cd5580879fa 100644
> > --- a/include/dt-bindings/phy/phy-imx8-pcie.h
> > +++ b/include/dt-bindings/phy/phy-imx8-pcie.h
> > @@ -11,4 +11,30 @@
> > #define IMX8_PCIE_REFCLK_PAD_INPUT 1
> > #define IMX8_PCIE_REFCLK_PAD_OUTPUT 2
> >
> > +/*
> > + * i.MX8QM HSIO subsystem has three lane PHYs and three controllers:
> > + * PCIEA(2 lanes capapble PCIe controller), PCIEB (only support one
> > + * lane) and SATA.
>
> Suggest add empty line between segment.
>
Okay, would be added later. Thanks.
Best Regards
Richard Zhu
> > + * In the different use cases. PCIEA can be binded to PHY lane0,
> > +lane1
> > + * or Lane0 and lane1. PCIEB can be binded to lane1 or lane2 PHY.
> > +SATA
> > + * can only be binded to last lane2 PHY.
> > + * Define i.MX8Q HSIO controller ID here to specify the controller
> > + * binded to the PHY.
> > + * Meanwhile, i.MX8QXP HSIO subsystem has one lane PHY and PCIEB(only
> > + * support one lane) controller.
> > + */
> > +#define IMX8Q_HSIO_PCIEA_ID 0
> > +#define IMX8Q_HSIO_PCIEB_ID 1
> > +#define IMX8Q_HSIO_SATA_ID 2
> > +
> > +/*
> > + * On i.MX8QM, PCIEA is mandatory required if the HSIO is enabled.
> > + * Define configurations beside PCIEA is enabled.
> > + * On i.MX8QXP, HSIO module only has PCIEB and one lane PHY.
> > + * The "IMX8Q_HSIO_CFG_PCIEB" can be used on i.MX8QXP platforms.
> > + */
> > +#define IMX8Q_HSIO_CFG_SATA 1
> > +#define IMX8Q_HSIO_CFG_PCIEB 2
> > +#define IMX8Q_HSIO_CFG_PCIEBSATA 3
> > +
> > #endif /* _DT_BINDINGS_IMX8_PCIE_H */
> > --
> > 2.37.1
> >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [v1 0/3] Add i.MX8Q HSIO PHY driver support
From: Hongxing Zhu @ 2024-04-01 2:12 UTC (permalink / raw)
To: Frank Li
Cc: vkoul@kernel.org, kishon@kernel.org, robh+dt@kernel.org,
krzysztof.kozlowski+dt@linaro.org, conor+dt@kernel.org,
linux-phy@lists.infradead.org, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, kernel@pengutronix.de, dl-linux-imx
In-Reply-To: <ZgbM4hpFhYW0QCHm@lizhi-Precision-Tower-5810>
> -----Original Message-----
> From: Frank Li <frank.li@nxp.com>
> Sent: 2024年3月29日 22:15
> To: Hongxing Zhu <hongxing.zhu@nxp.com>
> Cc: vkoul@kernel.org; kishon@kernel.org; robh+dt@kernel.org;
> krzysztof.kozlowski+dt@linaro.org; conor+dt@kernel.org;
> linux-phy@lists.infradead.org; devicetree@vger.kernel.org;
> linux-arm-kernel@lists.infradead.org; linux-kernel@vger.kernel.org;
> kernel@pengutronix.de; dl-linux-imx <linux-imx@nxp.com>
> Subject: Re: [v1 0/3] Add i.MX8Q HSIO PHY driver support
>
> On Fri, Mar 29, 2024 at 04:09:47PM +0800, Richard Zhu wrote:
> > v1 changes:
> > - Rebase to the 6.9-rc1, and constify of_phandle_args in xlate.
> > No other changes.
>
> Next time please send to imx@lists.linux.dev instead of linux-imx@nxp.com.
>
> Frank
Okay, thanks for your review.
Best Regards
Richard Zhu
>
> >
> > i.MX8Q HSIO module has PHY and mix control regions.
> > This patch-set adds i.MX8Q HSIO PHY driver support, and provides
> > standard PHY phandles that can be used by i.MX8Q PCIe or SATA driver
> > later.
> >
> > [PATCH v1 1/3] dt-bindings: phy: Add i.MX8Q HSIO SerDes PHY binding
> > [PATCH v1 2/3] dt-bindings: phy: phy-imx8-pcie: Add binding for [PATCH
> > v1 3/3] phy: freescale: imx8q-hsio: Add i.MX8Q HSIO PHY driver
> >
> > Documentation/devicetree/bindings/phy/fsl,imx8q-hsio.yaml | 143
> ++++++++++++++++++++++++
> > drivers/phy/freescale/Kconfig | 8 ++
> > drivers/phy/freescale/Makefile | 1 +
> > drivers/phy/freescale/phy-fsl-imx8q-hsio.c | 518
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> ++++++++++++++++++++++++
> > include/dt-bindings/phy/phy-imx8-pcie.h | 26 +++++
> > 5 files changed, 696 insertions(+)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [PATCH v5 0/4] Add support i.MX95 BLK CTL module clock features
From: Peng Fan @ 2024-04-01 1:32 UTC (permalink / raw)
To: Krzysztof Kozlowski, Peng Fan (OSS), Michael Turquette,
Stephen Boyd, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Abel Vesa
Cc: linux-clk@vger.kernel.org, devicetree@vger.kernel.org,
imx@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <e9809695-760e-42d2-a79c-bc2d4debdc32@linaro.org>
> Subject: Re: [PATCH v5 0/4] Add support i.MX95 BLK CTL module clock
> features
>
> On 31/03/2024 14:00, Peng Fan wrote:
> >> Subject: Re: [PATCH v5 0/4] Add support i.MX95 BLK CTL module clock
> >> features
> >>
> >> On 24/03/2024 08:51, Peng Fan (OSS) wrote:
> >>> i.MX95's several MIXes has BLK CTL module which could be used for
> >>> clk settings, QoS settings, Misc settings for a MIX. This patchset
> >>> is to add the clk feature support, including dt-bindings
> >>>
> >>> Signed-off-by: Peng Fan <peng.fan@nxp.com>
> >>> ---
> >>> Changes in v5:
> >>> - Merge bindings except the one has mux-controller
> >>> - Separate clock ID headers in a separate patch per Rob's comments
> >>
> >> Where did he suggest it?
> >
> > See
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore
> > .kernel.org%2Fall%2F20240315165422.GA1472059-
> robh%40kernel.org%2F&data
> >
> =05%7C02%7Cpeng.fan%40nxp.com%7C95289dc4bed24c3d125808dc51bc4
> 4e0%7C686
> >
> ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C638475116243825697%7
> CUnknown%7
> >
> CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwi
> LCJXV
> >
> CI6Mn0%3D%7C0%7C%7C%7C&sdata=Dt6KYhWwp%2B4NSwHJlXwUjyRqYU
> CkN0MvlSOE22w
> > vRE0%3D&reserved=0
> >
>
> He said under specific line about one specific define. There is absolutely
> nothing about splitting the header into new patch.
I misunderstood your point, I will put the header patch(patch 2/4) as the 1st patch
V6.
Thanks,
Peng.
>
> NAK
>
> Best regards,
> Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 1/4] arm64: dts: imx8: add cm40 subsystem dtsi
From: Peng Fan @ 2024-04-01 2:02 UTC (permalink / raw)
To: Frank Li
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, devicetree,
imx, linux-arm-kernel, linux-kernel, Dong Aisheng,
Alexander Stein
In-Reply-To: <20240329-m4_lpuart-v4-1-c11d9ca2a317@nxp.com>
On Fri, Mar 29, 2024 at 12:37:05PM -0400, Frank Li wrote:
>From: Dong Aisheng <aisheng.dong@nxp.com>
>
>Add cm40 subsystem dtsi.
>
>Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
>Reviewed-by: Alexander Stein <alexander.stein@ew.tq-group.com>
>Signed-off-by: Frank Li <Frank.Li@nxp.com>
>---
> arch/arm64/boot/dts/freescale/imx8-ss-cm40.dtsi | 67 +++++++++++++++++++++++++
> arch/arm64/boot/dts/freescale/imx8dxl.dtsi | 2 +
> arch/arm64/boot/dts/freescale/imx8qxp.dtsi | 1 +
> 3 files changed, 70 insertions(+)
>
>diff --git a/arch/arm64/boot/dts/freescale/imx8-ss-cm40.dtsi b/arch/arm64/boot/dts/freescale/imx8-ss-cm40.dtsi
>new file mode 100644
>index 0000000000000..10a05db06ade9
>--- /dev/null
>+++ b/arch/arm64/boot/dts/freescale/imx8-ss-cm40.dtsi
>@@ -0,0 +1,67 @@
>+// SPDX-License-Identifier: GPL-2.0+
>+/*
>+ * Copyright 2019 NXP
The time needs to be 2024, otherwise LGTM:
Reviewed-by: Peng Fan <peng.fan@nxp.com>
>+ * Dong Aisheng <aisheng.dong@nxp.com>
>+ */
>+
>+#include <dt-bindings/firmware/imx/rsrc.h>
>+
>+cm40_ipg_clk: clock-cm40-ipg {
>+ compatible = "fixed-clock";
>+ #clock-cells = <0>;
>+ clock-frequency = <132000000>;
>+ clock-output-names = "cm40_ipg_clk";
>+};
>+
>+cm40_subsys: bus@34000000 {
>+ compatible = "simple-bus";
>+ #address-cells = <1>;
>+ #size-cells = <1>;
>+ ranges = <0x34000000 0x0 0x34000000 0x4000000>;
>+ interrupt-parent = <&cm40_intmux>;
>+
>+ cm40_i2c: i2c@37230000 {
>+ compatible = "fsl,imx8qxp-lpi2c", "fsl,imx7ulp-lpi2c";
>+ reg = <0x37230000 0x1000>;
>+ interrupts = <9 IRQ_TYPE_LEVEL_HIGH>;
>+ clocks = <&cm40_i2c_lpcg IMX_LPCG_CLK_0>,
>+ <&cm40_i2c_lpcg IMX_LPCG_CLK_4>;
>+ clock-names = "per", "ipg";
>+ assigned-clocks = <&clk IMX_SC_R_M4_0_I2C IMX_SC_PM_CLK_PER>;
>+ assigned-clock-rates = <24000000>;
>+ power-domains = <&pd IMX_SC_R_M4_0_I2C>;
>+ status = "disabled";
>+ };
>+
>+ cm40_intmux: intmux@37400000 {
>+ compatible = "fsl,imx-intmux";
>+ reg = <0x37400000 0x1000>;
>+ interrupt-parent = <&gic>;
>+ interrupts = <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH>,
>+ <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>,
>+ <GIC_SPI 18 IRQ_TYPE_LEVEL_HIGH>,
>+ <GIC_SPI 19 IRQ_TYPE_LEVEL_HIGH>,
>+ <GIC_SPI 20 IRQ_TYPE_LEVEL_HIGH>,
>+ <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>,
>+ <GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH>,
>+ <GIC_SPI 23 IRQ_TYPE_LEVEL_HIGH>;
>+ interrupt-controller;
>+ #interrupt-cells = <2>;
>+ clocks = <&cm40_ipg_clk>;
>+ clock-names = "ipg";
>+ power-domains = <&pd IMX_SC_R_M4_0_INTMUX>;
>+ status = "disabled";
>+ };
>+
>+ cm40_i2c_lpcg: clock-controller@37630000 {
>+ compatible = "fsl,imx8qxp-lpcg";
>+ reg = <0x37630000 0x1000>;
>+ #clock-cells = <1>;
>+ clocks = <&clk IMX_SC_R_M4_0_I2C IMX_SC_PM_CLK_PER>,
>+ <&cm40_ipg_clk>;
>+ clock-indices = <IMX_LPCG_CLK_0>, <IMX_LPCG_CLK_4>;
>+ clock-output-names = "cm40_lpcg_i2c_clk",
>+ "cm40_lpcg_i2c_ipg_clk";
>+ power-domains = <&pd IMX_SC_R_M4_0_I2C>;
>+ };
>+};
>diff --git a/arch/arm64/boot/dts/freescale/imx8dxl.dtsi b/arch/arm64/boot/dts/freescale/imx8dxl.dtsi
>index a0674c5c55766..9d49c75a26222 100644
>--- a/arch/arm64/boot/dts/freescale/imx8dxl.dtsi
>+++ b/arch/arm64/boot/dts/freescale/imx8dxl.dtsi
>@@ -5,6 +5,7 @@
>
> #include <dt-bindings/clock/imx8-clock.h>
> #include <dt-bindings/dma/fsl-edma.h>
>+#include <dt-bindings/clock/imx8-lpcg.h>
> #include <dt-bindings/firmware/imx/rsrc.h>
> #include <dt-bindings/gpio/gpio.h>
> #include <dt-bindings/interrupt-controller/arm-gic.h>
>@@ -231,6 +232,7 @@ xtal24m: clock-xtal24m {
> };
>
> /* sorted in register address */
>+ #include "imx8-ss-cm40.dtsi"
> #include "imx8-ss-adma.dtsi"
> #include "imx8-ss-conn.dtsi"
> #include "imx8-ss-ddr.dtsi"
>diff --git a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
>index 10e16d84c0c3b..0313f295de2e9 100644
>--- a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
>+++ b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
>@@ -317,6 +317,7 @@ map0 {
> /* sorted in register address */
> #include "imx8-ss-img.dtsi"
> #include "imx8-ss-vpu.dtsi"
>+ #include "imx8-ss-cm40.dtsi"
> #include "imx8-ss-gpu0.dtsi"
> #include "imx8-ss-adma.dtsi"
> #include "imx8-ss-conn.dtsi"
>
>--
>2.34.1
>
--
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2 1/8] gpu: drm: use for_each_endpoint_of_node()
From: Kuninori Morimoto @ 2024-02-02 1:28 UTC (permalink / raw)
To: Lad Prabhakar, Alexander Shishkin, Alexandre Belloni,
Claudiu Beznea, Daniel Vetter, David Airlie, Eugen Hristev,
Greg Kroah-Hartman, Helge Deller, Laurent Pinchart,
Maarten Lankhorst, Mauro Carvalho Chehab, Maxime Ripard,
Michal Simek, Nicolas Ferre, Rob Herring, Suzuki K Poulose,
Thomas Zimmermann, Tomi Valkeinen, coresight, dri-devel,
linux-arm-kernel, linux-fbdev, linux-media
In-Reply-To: <87cyrauf0x.wl-kuninori.morimoto.gx@renesas.com>
We already have for_each_endpoint_of_node(), don't use
of_graph_get_next_endpoint() directly. Replace it.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
---
drivers/gpu/drm/omapdrm/dss/base.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/dss/base.c b/drivers/gpu/drm/omapdrm/dss/base.c
index 050ca7eafac5..5f8002f6bb7a 100644
--- a/drivers/gpu/drm/omapdrm/dss/base.c
+++ b/drivers/gpu/drm/omapdrm/dss/base.c
@@ -242,8 +242,7 @@ static void omapdss_walk_device(struct device *dev, struct device_node *node,
of_node_put(n);
- n = NULL;
- while ((n = of_graph_get_next_endpoint(node, n)) != NULL) {
+ for_each_endpoint_of_node(node, n) {
struct device_node *pn = of_graph_get_remote_port_parent(n);
if (!pn)
--
2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 7/8] video: fbdev: use for_each_endpoint_of_node()
From: Kuninori Morimoto @ 2024-04-01 0:06 UTC (permalink / raw)
To: Lad Prabhakar, Alexander Shishkin, Alexandre Belloni,
Claudiu Beznea, Daniel Vetter, David Airlie, Eugen Hristev,
Greg Kroah-Hartman, Helge Deller, Laurent Pinchart,
Maarten Lankhorst, Mauro Carvalho Chehab, Maxime Ripard,
Michal Simek, Nicolas Ferre, Rob Herring, Suzuki K Poulose,
Thomas Zimmermann, Tomi Valkeinen, coresight, dri-devel,
linux-arm-kernel, linux-fbdev, linux-media
In-Reply-To: <87cyrauf0x.wl-kuninori.morimoto.gx@renesas.com>
We already have for_each_endpoint_of_node(), don't use
of_graph_get_next_endpoint() directly. Replace it.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
---
drivers/video/fbdev/omap2/omapfb/dss/omapdss-boot-init.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/omap2/omapfb/dss/omapdss-boot-init.c b/drivers/video/fbdev/omap2/omapfb/dss/omapdss-boot-init.c
index 09f719af0d0c..d80720c84323 100644
--- a/drivers/video/fbdev/omap2/omapfb/dss/omapdss-boot-init.c
+++ b/drivers/video/fbdev/omap2/omapfb/dss/omapdss-boot-init.c
@@ -149,8 +149,7 @@ static void __init omapdss_walk_device(struct device_node *node, bool root)
of_node_put(n);
- n = NULL;
- while ((n = of_graph_get_next_endpoint(node, n)) != NULL) {
+ for_each_endpoint_of_node(node, n) {
struct device_node *pn;
pn = of_graph_get_remote_port_parent(n);
--
2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 5/8] media: platform: xilinx: use for_each_endpoint_of_node()
From: Kuninori Morimoto @ 2024-04-01 0:06 UTC (permalink / raw)
To: Lad Prabhakar, Alexander Shishkin, Alexandre Belloni,
Claudiu Beznea, Daniel Vetter, David Airlie, Eugen Hristev,
Greg Kroah-Hartman, Helge Deller, Laurent Pinchart,
Maarten Lankhorst, Mauro Carvalho Chehab, Maxime Ripard,
Michal Simek, Nicolas Ferre, Rob Herring, Suzuki K Poulose,
Thomas Zimmermann, Tomi Valkeinen, coresight, dri-devel,
linux-arm-kernel, linux-fbdev, linux-media
In-Reply-To: <87cyrauf0x.wl-kuninori.morimoto.gx@renesas.com>
We already have for_each_endpoint_of_node(), don't use
of_graph_get_next_endpoint() directly. Replace it.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
---
drivers/media/platform/xilinx/xilinx-vipp.c | 7 +------
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/media/platform/xilinx/xilinx-vipp.c b/drivers/media/platform/xilinx/xilinx-vipp.c
index 996684a73038..38818b82a575 100644
--- a/drivers/media/platform/xilinx/xilinx-vipp.c
+++ b/drivers/media/platform/xilinx/xilinx-vipp.c
@@ -205,12 +205,7 @@ static int xvip_graph_build_dma(struct xvip_composite_device *xdev)
dev_dbg(xdev->dev, "creating links for DMA engines\n");
- while (1) {
- /* Get the next endpoint and parse its link. */
- ep = of_graph_get_next_endpoint(node, ep);
- if (ep == NULL)
- break;
-
+ for_each_endpoint_of_node(node, ep) {
dev_dbg(xdev->dev, "processing endpoint %pOF\n", ep);
ret = v4l2_fwnode_parse_link(of_fwnode_handle(ep), &link);
--
2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 6/8] staging: media: atmel: use for_each_endpoint_of_node()
From: Kuninori Morimoto @ 2024-04-01 0:06 UTC (permalink / raw)
To: Lad Prabhakar, Alexander Shishkin, Alexandre Belloni,
Claudiu Beznea, Daniel Vetter, David Airlie, Eugen Hristev,
Greg Kroah-Hartman, Helge Deller, Laurent Pinchart,
Maarten Lankhorst, Mauro Carvalho Chehab, Maxime Ripard,
Michal Simek, Nicolas Ferre, Rob Herring, Suzuki K Poulose,
Thomas Zimmermann, Tomi Valkeinen, coresight, dri-devel,
linux-arm-kernel, linux-fbdev, linux-media
In-Reply-To: <87cyrauf0x.wl-kuninori.morimoto.gx@renesas.com>
We already have for_each_endpoint_of_node(), don't use
of_graph_get_next_endpoint() directly. Replace it.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
---
drivers/staging/media/deprecated/atmel/atmel-sama5d2-isc.c | 6 +-----
drivers/staging/media/deprecated/atmel/atmel-sama7g5-isc.c | 6 +-----
2 files changed, 2 insertions(+), 10 deletions(-)
diff --git a/drivers/staging/media/deprecated/atmel/atmel-sama5d2-isc.c b/drivers/staging/media/deprecated/atmel/atmel-sama5d2-isc.c
index 31b2b48085c5..cbfbec0c6cb5 100644
--- a/drivers/staging/media/deprecated/atmel/atmel-sama5d2-isc.c
+++ b/drivers/staging/media/deprecated/atmel/atmel-sama5d2-isc.c
@@ -340,13 +340,9 @@ static int isc_parse_dt(struct device *dev, struct isc_device *isc)
INIT_LIST_HEAD(&isc->subdev_entities);
- while (1) {
+ for_each_endpoint_of_node(np, epn) {
struct v4l2_fwnode_endpoint v4l2_epn = { .bus_type = 0 };
- epn = of_graph_get_next_endpoint(np, epn);
- if (!epn)
- return 0;
-
ret = v4l2_fwnode_endpoint_parse(of_fwnode_handle(epn),
&v4l2_epn);
if (ret) {
diff --git a/drivers/staging/media/deprecated/atmel/atmel-sama7g5-isc.c b/drivers/staging/media/deprecated/atmel/atmel-sama7g5-isc.c
index 020034f631f5..7c477b1d3c48 100644
--- a/drivers/staging/media/deprecated/atmel/atmel-sama7g5-isc.c
+++ b/drivers/staging/media/deprecated/atmel/atmel-sama7g5-isc.c
@@ -326,13 +326,9 @@ static int xisc_parse_dt(struct device *dev, struct isc_device *isc)
mipi_mode = of_property_read_bool(np, "microchip,mipi-mode");
- while (1) {
+ for_each_endpoint_of_node(np, epn) {
struct v4l2_fwnode_endpoint v4l2_epn = { .bus_type = 0 };
- epn = of_graph_get_next_endpoint(np, epn);
- if (!epn)
- return 0;
-
ret = v4l2_fwnode_endpoint_parse(of_fwnode_handle(epn),
&v4l2_epn);
if (ret) {
--
2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 8/8] fbdev: omapfb: use of_graph_get_remote_port()
From: Kuninori Morimoto @ 2024-04-01 0:06 UTC (permalink / raw)
To: Lad Prabhakar, Alexander Shishkin, Alexandre Belloni,
Claudiu Beznea, Daniel Vetter, David Airlie, Eugen Hristev,
Greg Kroah-Hartman, Helge Deller, Laurent Pinchart,
Maarten Lankhorst, Mauro Carvalho Chehab, Maxime Ripard,
Michal Simek, Nicolas Ferre, Rob Herring, Suzuki K Poulose,
Thomas Zimmermann, Tomi Valkeinen, coresight, dri-devel,
linux-arm-kernel, linux-fbdev, linux-media
In-Reply-To: <87cyrauf0x.wl-kuninori.morimoto.gx@renesas.com>
We already have of_graph_get_remote_port(), Let's use it.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
---
drivers/video/fbdev/omap2/omapfb/dss/dss-of.c | 15 +--------------
1 file changed, 1 insertion(+), 14 deletions(-)
diff --git a/drivers/video/fbdev/omap2/omapfb/dss/dss-of.c b/drivers/video/fbdev/omap2/omapfb/dss/dss-of.c
index 14965a3fd05b..4040e247e026 100644
--- a/drivers/video/fbdev/omap2/omapfb/dss/dss-of.c
+++ b/drivers/video/fbdev/omap2/omapfb/dss/dss-of.c
@@ -117,19 +117,6 @@ u32 dss_of_port_get_port_number(struct device_node *port)
return reg;
}
-static struct device_node *omapdss_of_get_remote_port(const struct device_node *node)
-{
- struct device_node *np;
-
- np = of_graph_get_remote_endpoint(node);
- if (!np)
- return NULL;
-
- np = of_get_next_parent(np);
-
- return np;
-}
-
struct omap_dss_device *
omapdss_of_find_source_for_first_ep(struct device_node *node)
{
@@ -141,7 +128,7 @@ omapdss_of_find_source_for_first_ep(struct device_node *node)
if (!ep)
return ERR_PTR(-EINVAL);
- src_port = omapdss_of_get_remote_port(ep);
+ src_port = of_graph_get_remote_port(ep);
if (!src_port) {
of_node_put(ep);
return ERR_PTR(-EINVAL);
--
2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 4/8] media: platform: ti: use for_each_endpoint_of_node()
From: Kuninori Morimoto @ 2024-04-01 0:05 UTC (permalink / raw)
To: Lad Prabhakar, Alexander Shishkin, Alexandre Belloni,
Claudiu Beznea, Daniel Vetter, David Airlie, Eugen Hristev,
Greg Kroah-Hartman, Helge Deller, Laurent Pinchart,
Maarten Lankhorst, Mauro Carvalho Chehab, Maxime Ripard,
Michal Simek, Nicolas Ferre, Rob Herring, Suzuki K Poulose,
Thomas Zimmermann, Tomi Valkeinen, coresight, dri-devel,
linux-arm-kernel, linux-fbdev, linux-media
In-Reply-To: <87cyrauf0x.wl-kuninori.morimoto.gx@renesas.com>
We already have for_each_endpoint_of_node(), don't use
of_graph_get_next_endpoint() directly. Replace it.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
---
drivers/media/platform/ti/am437x/am437x-vpfe.c | 12 +++++-------
drivers/media/platform/ti/davinci/vpif_capture.c | 12 ++++++------
2 files changed, 11 insertions(+), 13 deletions(-)
diff --git a/drivers/media/platform/ti/am437x/am437x-vpfe.c b/drivers/media/platform/ti/am437x/am437x-vpfe.c
index 77e12457d149..009ff68a2b43 100644
--- a/drivers/media/platform/ti/am437x/am437x-vpfe.c
+++ b/drivers/media/platform/ti/am437x/am437x-vpfe.c
@@ -2287,7 +2287,7 @@ static const struct v4l2_async_notifier_operations vpfe_async_ops = {
static struct vpfe_config *
vpfe_get_pdata(struct vpfe_device *vpfe)
{
- struct device_node *endpoint = NULL;
+ struct device_node *endpoint;
struct device *dev = vpfe->pdev;
struct vpfe_subdev_info *sdinfo;
struct vpfe_config *pdata;
@@ -2306,14 +2306,11 @@ vpfe_get_pdata(struct vpfe_device *vpfe)
if (!pdata)
return NULL;
- for (i = 0; ; i++) {
+ i = 0;
+ for_each_endpoint_of_node(dev->of_node, endpoint) {
struct v4l2_fwnode_endpoint bus_cfg = { .bus_type = 0 };
struct device_node *rem;
- endpoint = of_graph_get_next_endpoint(dev->of_node, endpoint);
- if (!endpoint)
- break;
-
sdinfo = &pdata->sub_devs[i];
sdinfo->grp_id = 0;
@@ -2371,9 +2368,10 @@ vpfe_get_pdata(struct vpfe_device *vpfe)
of_node_put(rem);
if (IS_ERR(pdata->asd[i]))
goto cleanup;
+
+ i++;
}
- of_node_put(endpoint);
return pdata;
cleanup:
diff --git a/drivers/media/platform/ti/davinci/vpif_capture.c b/drivers/media/platform/ti/davinci/vpif_capture.c
index c31a5566fc5a..3db4e82c8a80 100644
--- a/drivers/media/platform/ti/davinci/vpif_capture.c
+++ b/drivers/media/platform/ti/davinci/vpif_capture.c
@@ -1517,16 +1517,12 @@ vpif_capture_get_pdata(struct platform_device *pdev,
if (!pdata->subdev_info)
return NULL;
- for (i = 0; i < VPIF_CAPTURE_NUM_CHANNELS; i++) {
+ i = 0;
+ for_each_endpoint_of_node(pdev->dev.of_node, endpoint) {
struct v4l2_fwnode_endpoint bus_cfg = { .bus_type = 0 };
unsigned int flags;
int err;
- endpoint = of_graph_get_next_endpoint(pdev->dev.of_node,
- endpoint);
- if (!endpoint)
- break;
-
rem = of_graph_get_remote_port_parent(endpoint);
if (!rem) {
dev_dbg(&pdev->dev, "Remote device at %pOF not found\n",
@@ -1577,6 +1573,10 @@ vpif_capture_get_pdata(struct platform_device *pdev,
goto err_cleanup;
of_node_put(rem);
+
+ i++;
+ if (i >= VPIF_CAPTURE_NUM_CHANNELS)
+ break;
}
done:
--
2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ 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