Message ID | 20210311154055.3496076-1-emil.l.velikov@gmail.com (mailing list archive) |
---|---|
Headers |
Received: from vger.kernel.org ([23.128.96.18]) by www.linuxtv.org with esmtp (Exim 4.92) (envelope-from <linux-media-owner@vger.kernel.org>) id 1lKNS0-00BtCQ-7K; Thu, 11 Mar 2021 15:42:15 +0000 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234257AbhCKPlW (ORCPT <rfc822;mkrufky@linuxtv.org> + 1 other); Thu, 11 Mar 2021 10:41:22 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46630 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234232AbhCKPlE (ORCPT <rfc822;linux-media@vger.kernel.org>); Thu, 11 Mar 2021 10:41:04 -0500 Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [IPv6:2a00:1450:4864:20::432]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 65695C061574 for <linux-media@vger.kernel.org>; Thu, 11 Mar 2021 07:41:04 -0800 (PST) Received: by mail-wr1-x432.google.com with SMTP id v15so2394155wrx.4 for <linux-media@vger.kernel.org>; Thu, 11 Mar 2021 07:41:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=q4dPzQoidf5vtocnR10xIvJiNylBWsI78KoL3BBU9vQ=; b=I+bAsulCdkt+lVCylDNKLobwxXzgSLuVltYeHq+F0SXZTNT1+Ol1lT2fq8F1tpy40D c2Iju/OcLhSXSaxISalcVRTgUt2Bm1hb2KTRtoIOvdNPgqYaoZkhDUqFM8ChzjkxU5Lb u1+vrIMYZJgtvAhCurjORzz6uTgeno2Ohg25IbE7il6TQ02YSFjc7FRPVDKgKOTVhlgc 7gC9lvn/flsNmggOafASCfjJdzXv+aEOo3HoXvTewmNF6bEpLu/AjywVY27FD+fTtC00 E16EPhfWQYKDCt2YdABfIQtOtjm69nTzMrgm2NI1jRVtbBTuDuZ4dnX6iUxmmy/cekBw 5Awg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=q4dPzQoidf5vtocnR10xIvJiNylBWsI78KoL3BBU9vQ=; b=DN6+AWywOm8gq7lVCvb2/PwhwzMGKNW4fKEwMxCYxujdxQb6dh+ITZqTCnf6TWqn+1 H3+1+klYQUHrJS4d2vznInR33AdHVZMmscT3uiP5rJvKa0WmBeUo8cWHGZiFt1W/BBRN VlLClo/eyqQxPslPs22tu3EsNAgcIs9CiMO643uKzAguhhVetCZdwKmueFG+ssIYswWx 3lI5+xqFFy/OFZ+KapUhN1rGFVZjMUGRrta7KNv56NIokcz2scOz/JtNzi7l3NBxegl0 THl4etS46jsE2wCsZ0VW6bvkZjBvVJLjGlk7Tm6ipMJS4hlVgRmnwr3PuTa1PbO7UPe7 N1qg== X-Gm-Message-State: AOAM5315uhsVHH03CSVUXPR31pu1bJY1CNeDYAogOfHUPG4EyRujq1IM mchjp8P5bBTdJYqMzXLL3dk= X-Google-Smtp-Source: ABdhPJxU1HuvUtEcMRItxvCfrPrKwoGRw1pHQPExwdjuUkuMll+2Tmw5tpIE5jkSGL+KA66RYcqraw== X-Received: by 2002:adf:cd8c:: with SMTP id q12mr9248759wrj.185.1615477263160; Thu, 11 Mar 2021 07:41:03 -0800 (PST) Received: from arch-x1c3.. ([2a00:5f00:102:0:b16d:9752:8f38:7d6b]) by smtp.gmail.com with ESMTPSA id a17sm4008547wmj.9.2021.03.11.07.41.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 11 Mar 2021 07:41:02 -0800 (PST) From: Emil Velikov <emil.l.velikov@gmail.com> To: Ezequiel Garcia <ezequiel@collabora.com>, Philipp Zabel <p.zabel@pengutronix.de>, linux-media@vger.kernel.org, linux-rockchip@lists.infradead.org, Nicolas Ferre <nicolas.ferre@microchip.com> Cc: emil.l.velikov@gmail.com Subject: [PATCH v2 00/10] Microship SAMA5D4 VPU support et al Date: Thu, 11 Mar 2021 15:40:45 +0000 Message-Id: <20210311154055.3496076-1-emil.l.velikov@gmail.com> X-Mailer: git-send-email 2.30.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: <linux-media.vger.kernel.org> X-Mailing-List: linux-media@vger.kernel.org X-LSpam-Score: -2.5 (--) X-LSpam-Report: No, score=-2.5 required=5.0 tests=BAYES_00=-1.9,DKIM_SIGNED=0.1,DKIM_VALID=-0.1,DKIM_VALID_AU=-0.1,FREEMAIL_FORGED_FROMDOMAIN=0.001,FREEMAIL_FROM=0.001,HEADER_FROM_DIFFERENT_DOMAINS=0.5,MAILING_LIST_MULTI=-1 autolearn=ham autolearn_force=no |
Series |
Microship SAMA5D4 VPU support et al
|
|
Message
Emil Velikov
March 11, 2021, 3:40 p.m. UTC
Hi all This series adds support for the Microchip SAMA5D4 VPU, which it based on the Hantro G1. The hardware can support up-to 1280x720 for each of the MPEG2, VP8 and H264 codecs. There is only a single decoder and no encoders on the SoC. The Hantro G1 post-processing is also enabled on the platform. To minimise duplication, the series starts with a few small cleanups. As you may have noticed, this is my first patches series to linux-media, so any tips how to make this as smoother process are appreciated. Changes in v2: - Add testing results in the cover letter (thanks Eze) - s/Atmel/Microchip/ through the series (thanks Nicolas) - Split defconfig change into separate commit (thanks Eze, Nicolas) - Added Reviewed-by and Fixes tags (thanks Philipp) - Split DT into separate commit, wrote binding document, fixup minor DT warnings (thanks Eze) - Rebased on top of 5.12-rc2, as per Linus' email to avoid 5.12-rc1 https://lwn.net/Articles/848265/ Testing ------- - v4l-compliance Command used: v4l2-compliance -m0 Output summary: v4l2-compliance 1.21.0-4740, 32 bits, 32-bit time_t v4l2-compliance SHA: f253495fa6de 2021-03-06 15:32:09 Compliance test for hantro-vpu device /dev/media0: Total for hantro-vpu device /dev/media0: 8, Succeeded: 8, Failed: 0, Warnings: 0 Compliance test for hantro-vpu device /dev/video0: Total for hantro-vpu device /dev/video0: 46, Succeeded: 46, Failed: 0, Warnings: 0 - Post-processor testing Command used: gst-launch-1.0 -v filesrc location=test.mp4 ! decodebin3 ! video/x-raw,format=YUY2 ! ... Confirmed the VPU is used by observing the interrupts triggering, strace showed extra v4l2 ioctls - VIDIOC_S_FMT(... V4L2_PIX_FMT_YUYV ...) - MPEG2 testing, custom ffmpeg from https://github.com/Kwiboo/FFmpeg/commits/v4l2-request-hwaccel-4.3 Command used: ffmpeg -hwaccel drm -i mpeg2.mpeg2 -f rawvideo -pix_fmt yuv420p out.raw Confirmed the VPU is used by observing the interrupts triggering, strace showed the v4l2 ioctls being used plus played back the resulting file. - VP8 testing, using fluster Command used: fluster.py run -ts VP8-TEST-VECTORS -d GStreamer-VP8-V4L2SL-Gst1.0 Output summary: Running test suite VP8-TEST-VECTORS with decoder GStreamer-VP8-V4L2SL-Gst1.0 Ran 61 tests in 103.273s FAILED (failures=9, errors=2) - H264 testing, using fluster Command used: fluster.py run -ts JVT-AVC_V1 -d GStreamer-H.264-V4L2SL-Gst1.0 Output summary: Running test suite JVT-AVC_V1 with decoder GStreamer-H.264-V4L2SL-Gst1.0 Ran 135 tests in 420.444s FAILED (failures=9, errors=55) Looking forward to your feedback, Emil Emil Velikov (10): media: hantro: use G1_REG_INTERRUPT directly for the mpeg2 media: hantro: imx: reuse MB_DIM define media: hantro: imx: remove duplicate dec_base init media: hantro: imx: remove unused include media: hantro: introduce hantro_g1.c for common API media: dt-bindings: Document SAMA5D4 VDEC bindings media: hantro: add initial SAMA5D4 support ARM: dts: sama5d4: enable Hantro G1 VDEC ARM: configs: at91: sama5: update with savedefconfig ARM: configs: at91: sama5: enable the Hantro G1 engine .../media/microchip,sama5d4-vdec.yaml | 59 +++++++++ arch/arm/boot/dts/sama5d4.dtsi | 9 ++ arch/arm/configs/sama5_defconfig | 40 +++--- drivers/staging/media/hantro/Kconfig | 10 +- drivers/staging/media/hantro/Makefile | 4 + drivers/staging/media/hantro/hantro_drv.c | 3 + drivers/staging/media/hantro/hantro_g1.c | 39 ++++++ .../media/hantro/hantro_g1_mpeg2_dec.c | 5 +- drivers/staging/media/hantro/hantro_hw.h | 4 + drivers/staging/media/hantro/imx8m_vpu_hw.c | 27 +--- drivers/staging/media/hantro/rk3288_vpu_hw.c | 36 +----- .../staging/media/hantro/sama5d4_vdec_hw.c | 117 ++++++++++++++++++ 12 files changed, 274 insertions(+), 79 deletions(-) create mode 100644 Documentation/devicetree/bindings/media/microchip,sama5d4-vdec.yaml create mode 100644 drivers/staging/media/hantro/hantro_g1.c create mode 100644 drivers/staging/media/hantro/sama5d4_vdec_hw.c
Comments
On Thu, 2021-03-11 at 15:40 +0000, Emil Velikov wrote: > Hi all > > This series adds support for the Microchip SAMA5D4 VPU, which it based > on the Hantro G1. > > The hardware can support up-to 1280x720 for each of the MPEG2, VP8 and > H264 codecs. There is only a single decoder and no encoders on the SoC. > > The Hantro G1 post-processing is also enabled on the platform. > > To minimise duplication, the series starts with a few small cleanups. > > > As you may have noticed, this is my first patches series to linux-media, > so any tips how to make this as smoother process are appreciated. > > > Changes in v2: > - Add testing results in the cover letter (thanks Eze) > - s/Atmel/Microchip/ through the series (thanks Nicolas) > - Split defconfig change into separate commit (thanks Eze, Nicolas) > - Added Reviewed-by and Fixes tags (thanks Philipp) > - Split DT into separate commit, wrote binding document, fixup minor DT > warnings (thanks Eze) > - Rebased on top of 5.12-rc2, as per Linus' email to avoid 5.12-rc1 > https://lwn.net/Articles/848265/ > > > > Testing > ------- > > - v4l-compliance > > Command used: > v4l2-compliance -m0 > > Output summary: > > v4l2-compliance 1.21.0-4740, 32 bits, 32-bit time_t > v4l2-compliance SHA: f253495fa6de 2021-03-06 15:32:09 > > Compliance test for hantro-vpu device /dev/media0: > > Total for hantro-vpu device /dev/media0: 8, Succeeded: 8, Failed: 0, > Warnings: 0 > > Compliance test for hantro-vpu device /dev/video0: > > Total for hantro-vpu device /dev/video0: 46, Succeeded: 46, Failed: 0, > Warnings: 0 > > > - Post-processor testing > > Command used: > gst-launch-1.0 -v filesrc location=test.mp4 ! decodebin3 ! > video/x-raw,format=YUY2 ! ... > > Confirmed the VPU is used by observing the interrupts triggering, strace > showed extra v4l2 ioctls - VIDIOC_S_FMT(... V4L2_PIX_FMT_YUYV ...) > > > - MPEG2 testing, custom ffmpeg from > https://github.com/Kwiboo/FFmpeg/commits/v4l2-request-hwaccel-4.3 > > Command used: > ffmpeg -hwaccel drm -i mpeg2.mpeg2 -f rawvideo -pix_fmt yuv420p out.raw > > Confirmed the VPU is used by observing the interrupts triggering, strace > showed the v4l2 ioctls being used plus played back the resulting file. > > > - VP8 testing, using fluster > > Command used: > fluster.py run -ts VP8-TEST-VECTORS -d GStreamer-VP8-V4L2SL-Gst1.0 > > Output summary: > > Running test suite VP8-TEST-VECTORS with decoder GStreamer-VP8-V4L2SL-Gst1.0 > Ran 61 tests in 103.273s > > FAILED (failures=9, errors=2) > > > - H264 testing, using fluster > > Command used: > fluster.py run -ts JVT-AVC_V1 -d GStreamer-H.264-V4L2SL-Gst1.0 > > Output summary: > > Running test suite JVT-AVC_V1 with decoder GStreamer-H.264-V4L2SL-Gst1.0 > Ran 135 tests in 420.444s > > FAILED (failures=9, errors=55) > > > Looking forward to your feedback, > Emil > > > Emil Velikov (10): > media: hantro: use G1_REG_INTERRUPT directly for the mpeg2 > media: hantro: imx: reuse MB_DIM define > media: hantro: imx: remove duplicate dec_base init > media: hantro: imx: remove unused include > media: hantro: introduce hantro_g1.c for common API For patches 1-5: Reviewed-by: Ezequiel Garcia <ezequiel@collabora.com> > media: dt-bindings: Document SAMA5D4 VDEC bindings This one need to be reviewed by DT maintainers, I think. > media: hantro: add initial SAMA5D4 support For patch 7: Reviewed-by: Ezequiel Garcia <ezequiel@collabora.com> > ARM: dts: sama5d4: enable Hantro G1 VDEC > ARM: configs: at91: sama5: update with savedefconfig > ARM: configs: at91: sama5: enable the Hantro G1 engine > These need review from Microchip maintainers. Thanks! Ezequiel > .../media/microchip,sama5d4-vdec.yaml | 59 +++++++++ > arch/arm/boot/dts/sama5d4.dtsi | 9 ++ > arch/arm/configs/sama5_defconfig | 40 +++--- > drivers/staging/media/hantro/Kconfig | 10 +- > drivers/staging/media/hantro/Makefile | 4 + > drivers/staging/media/hantro/hantro_drv.c | 3 + > drivers/staging/media/hantro/hantro_g1.c | 39 ++++++ > .../media/hantro/hantro_g1_mpeg2_dec.c | 5 +- > drivers/staging/media/hantro/hantro_hw.h | 4 + > drivers/staging/media/hantro/imx8m_vpu_hw.c | 27 +--- > drivers/staging/media/hantro/rk3288_vpu_hw.c | 36 +----- > .../staging/media/hantro/sama5d4_vdec_hw.c | 117 ++++++++++++++++++ > 12 files changed, 274 insertions(+), 79 deletions(-) > create mode 100644 Documentation/devicetree/bindings/media/microchip,sama5d4-vdec.yaml > create mode 100644 drivers/staging/media/hantro/hantro_g1.c > create mode 100644 drivers/staging/media/hantro/sama5d4_vdec_hw.c >
On Tue, 16 Mar 2021 at 17:23, Ezequiel Garcia <ezequiel@collabora.com> wrote: > On Thu, 2021-03-11 at 15:40 +0000, Emil Velikov wrote: > > Emil Velikov (10): > > media: hantro: use G1_REG_INTERRUPT directly for the mpeg2 > > media: hantro: imx: reuse MB_DIM define > > media: hantro: imx: remove duplicate dec_base init > > media: hantro: imx: remove unused include > > media: hantro: introduce hantro_g1.c for common API > > For patches 1-5: > > Reviewed-by: Ezequiel Garcia <ezequiel@collabora.com> > > > media: dt-bindings: Document SAMA5D4 VDEC bindings > > This one need to be reviewed by DT maintainers, I think. > Rob can you help with this one? > > media: hantro: add initial SAMA5D4 support > > For patch 7: > > Reviewed-by: Ezequiel Garcia <ezequiel@collabora.com> > > > ARM: dts: sama5d4: enable Hantro G1 VDEC > > ARM: configs: at91: sama5: update with savedefconfig > > ARM: configs: at91: sama5: enable the Hantro G1 engine > > > > These need review from Microchip maintainers. > Alexandre, Ludovic, Nicolas Do you have any input of the patches or series as a whole? If you prefer we can drop the last two patches for the defconfig. I've included those for posterity. Thanks for the review Eze. Would you recommend that I resend the series with your R-B or it's better to wait for feedback from others? -Emil
Emil, On 24/03/2021 at 13:49, Emil Velikov wrote: > On Tue, 16 Mar 2021 at 17:23, Ezequiel Garcia <ezequiel@collabora.com> wrote: > >> On Thu, 2021-03-11 at 15:40 +0000, Emil Velikov wrote: >>> Emil Velikov (10): >>> media: hantro: use G1_REG_INTERRUPT directly for the mpeg2 >>> media: hantro: imx: reuse MB_DIM define >>> media: hantro: imx: remove duplicate dec_base init >>> media: hantro: imx: remove unused include >>> media: hantro: introduce hantro_g1.c for common API >> >> For patches 1-5: >> >> Reviewed-by: Ezequiel Garcia <ezequiel@collabora.com> >> >>> media: dt-bindings: Document SAMA5D4 VDEC bindings >> >> This one need to be reviewed by DT maintainers, I think. >> > Rob can you help with this one? > >>> media: hantro: add initial SAMA5D4 support >> >> For patch 7: >> >> Reviewed-by: Ezequiel Garcia <ezequiel@collabora.com> >> >>> ARM: dts: sama5d4: enable Hantro G1 VDEC >>> ARM: configs: at91: sama5: update with savedefconfig >>> ARM: configs: at91: sama5: enable the Hantro G1 engine >>> >> >> These need review from Microchip maintainers. >> > Alexandre, Ludovic, Nicolas > Do you have any input of the patches or series as a whole? The patch series looks good to me. If needed on patches that we don't take ourselves, you can add my: Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com> Now, when we have the tag from Rob, how to coordinate these different pieces? Will it go through the media git tree? Will we benefit from a stable branch to share or will we just have to wait for the driver to hit Mainline before adding the defconfig and DT patches? > If you prefer we can drop the last two patches for the defconfig. I've > included those for posterity. No strong opinion on my side, except that defconfig stuff might be better handled in at91 + arm-soc trees because we'll have other changes to queue for 5.13. > Thanks for the review Eze. > Would you recommend that I resend the series with your R-B or it's > better to wait for feedback from others? Thanks a lot for this nice work. Best regards,
Le jeudi 11 mars 2021 à 15:40 +0000, Emil Velikov a écrit : > Hi all > > This series adds support for the Microchip SAMA5D4 VPU, which it based > on the Hantro G1. Perhaps in your next version you could fix the object line, you wrote Microship instead of Microchip. > > The hardware can support up-to 1280x720 for each of the MPEG2, VP8 and > H264 codecs. There is only a single decoder and no encoders on the SoC. > > The Hantro G1 post-processing is also enabled on the platform. > > To minimise duplication, the series starts with a few small cleanups. > > > As you may have noticed, this is my first patches series to linux-media, > so any tips how to make this as smoother process are appreciated. > > > Changes in v2: > - Add testing results in the cover letter (thanks Eze) > - s/Atmel/Microchip/ through the series (thanks Nicolas) > - Split defconfig change into separate commit (thanks Eze, Nicolas) > - Added Reviewed-by and Fixes tags (thanks Philipp) > - Split DT into separate commit, wrote binding document, fixup minor DT > warnings (thanks Eze) > - Rebased on top of 5.12-rc2, as per Linus' email to avoid 5.12-rc1 > https://lwn.net/Articles/848265/ > > > > Testing > ------- > > - v4l-compliance > > Command used: > v4l2-compliance -m0 > > Output summary: > > v4l2-compliance 1.21.0-4740, 32 bits, 32-bit time_t > v4l2-compliance SHA: f253495fa6de 2021-03-06 15:32:09 > > Compliance test for hantro-vpu device /dev/media0: > > Total for hantro-vpu device /dev/media0: 8, Succeeded: 8, Failed: 0, > Warnings: 0 > > Compliance test for hantro-vpu device /dev/video0: > > Total for hantro-vpu device /dev/video0: 46, Succeeded: 46, Failed: 0, > Warnings: 0 > > > - Post-processor testing > > Command used: > gst-launch-1.0 -v filesrc location=test.mp4 ! decodebin3 ! > video/x-raw,format=YUY2 ! ... > > Confirmed the VPU is used by observing the interrupts triggering, strace > showed extra v4l2 ioctls - VIDIOC_S_FMT(... V4L2_PIX_FMT_YUYV ...) > > > - MPEG2 testing, custom ffmpeg from > https://github.com/Kwiboo/FFmpeg/commits/v4l2-request-hwaccel-4.3 > > Command used: > ffmpeg -hwaccel drm -i mpeg2.mpeg2 -f rawvideo -pix_fmt yuv420p out.raw > > Confirmed the VPU is used by observing the interrupts triggering, strace > showed the v4l2 ioctls being used plus played back the resulting file. > > > - VP8 testing, using fluster > > Command used: > fluster.py run -ts VP8-TEST-VECTORS -d GStreamer-VP8-V4L2SL-Gst1.0 > > Output summary: > > Running test suite VP8-TEST-VECTORS with decoder GStreamer-VP8-V4L2SL-Gst1.0 > Ran 61 tests in 103.273s > > FAILED (failures=9, errors=2) > > > - H264 testing, using fluster > > Command used: > fluster.py run -ts JVT-AVC_V1 -d GStreamer-H.264-V4L2SL-Gst1.0 > > Output summary: > > Running test suite JVT-AVC_V1 with decoder GStreamer-H.264-V4L2SL-Gst1.0 > Ran 135 tests in 420.444s > > FAILED (failures=9, errors=55) > > > Looking forward to your feedback, > Emil > > > Emil Velikov (10): > media: hantro: use G1_REG_INTERRUPT directly for the mpeg2 > media: hantro: imx: reuse MB_DIM define > media: hantro: imx: remove duplicate dec_base init > media: hantro: imx: remove unused include > media: hantro: introduce hantro_g1.c for common API > media: dt-bindings: Document SAMA5D4 VDEC bindings > media: hantro: add initial SAMA5D4 support > ARM: dts: sama5d4: enable Hantro G1 VDEC > ARM: configs: at91: sama5: update with savedefconfig > ARM: configs: at91: sama5: enable the Hantro G1 engine > > .../media/microchip,sama5d4-vdec.yaml | 59 +++++++++ > arch/arm/boot/dts/sama5d4.dtsi | 9 ++ > arch/arm/configs/sama5_defconfig | 40 +++--- > drivers/staging/media/hantro/Kconfig | 10 +- > drivers/staging/media/hantro/Makefile | 4 + > drivers/staging/media/hantro/hantro_drv.c | 3 + > drivers/staging/media/hantro/hantro_g1.c | 39 ++++++ > .../media/hantro/hantro_g1_mpeg2_dec.c | 5 +- > drivers/staging/media/hantro/hantro_hw.h | 4 + > drivers/staging/media/hantro/imx8m_vpu_hw.c | 27 +--- > drivers/staging/media/hantro/rk3288_vpu_hw.c | 36 +----- > .../staging/media/hantro/sama5d4_vdec_hw.c | 117 ++++++++++++++++++ > 12 files changed, 274 insertions(+), 79 deletions(-) > create mode 100644 Documentation/devicetree/bindings/media/microchip,sama5d4-vdec.yaml > create mode 100644 drivers/staging/media/hantro/hantro_g1.c > create mode 100644 drivers/staging/media/hantro/sama5d4_vdec_hw.c >
On 24/03/2021 14:44:14+0100, Nicolas Ferre wrote: > Now, when we have the tag from Rob, how to coordinate these different > pieces? Will it go through the media git tree? Will we benefit from a stable > branch to share or will we just have to wait for the driver to hit Mainline > before adding the defconfig and DT patches? > I think the defconfig and dt patches can go through at91 as soon as we get Rob's ack. There is no build dependency so it can be taken at any time. Worst case, we end up with a selected config option that doesn't exist.
Greetings all, On Thu, 25 Mar 2021 at 08:48, Alexandre Belloni <alexandre.belloni@bootlin.com> wrote: > > On 24/03/2021 14:44:14+0100, Nicolas Ferre wrote: > > Now, when we have the tag from Rob, how to coordinate these different > > pieces? Will it go through the media git tree? Will we benefit from a stable > > branch to share or will we just have to wait for the driver to hit Mainline > > before adding the defconfig and DT patches? > > Thanks for the Acked-by Nicolas. > > I think the defconfig and dt patches can go through at91 as soon as we > get Rob's ack. There is no build dependency so it can be taken at any > time. Worst case, we end up with a selected config option that doesn't > exist. > My personal preference is to merge everything in one go. I believe it will be easier from maintainer's point of view, plus odds of conflicts with the AT91 tree are close to zero. Then again, as long as the maintainers are happy - I'm fine either way. Thanks Emil
On 25/03/2021 at 09:48, Alexandre Belloni wrote: > On 24/03/2021 14:44:14+0100, Nicolas Ferre wrote: >> Now, when we have the tag from Rob, how to coordinate these different >> pieces? Will it go through the media git tree? Will we benefit from a stable >> branch to share or will we just have to wait for the driver to hit Mainline >> before adding the defconfig and DT patches? >> > > I think the defconfig and dt patches can go through at91 as soon as we > get Rob's ack. There is no build dependency so it can be taken at any > time. Worst case, we end up with a selected config option that doesn't > exist. Agreed, and it simplify things. My only concern is with triggering some of the bots while checking for DT compatible string definition. Regards, Nicolas
On 25/03/2021 at 15:22, Emil Velikov wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe > > Greetings all, > > On Thu, 25 Mar 2021 at 08:48, Alexandre Belloni > <alexandre.belloni@bootlin.com> wrote: >> >> On 24/03/2021 14:44:14+0100, Nicolas Ferre wrote: >>> Now, when we have the tag from Rob, how to coordinate these different >>> pieces? Will it go through the media git tree? Will we benefit from a stable >>> branch to share or will we just have to wait for the driver to hit Mainline >>> before adding the defconfig and DT patches? >>> > Thanks for the Acked-by Nicolas. > >> >> I think the defconfig and dt patches can go through at91 as soon as we >> get Rob's ack. There is no build dependency so it can be taken at any >> time. Worst case, we end up with a selected config option that doesn't >> exist. >> > My personal preference is to merge everything in one go. > I believe it will be easier from maintainer's point of view, plus odds > of conflicts with the AT91 tree are close to zero. > > Then again, as long as the maintainers are happy - I'm fine either way. I'm taking defconfig 2 last patches of your series right now. No need to include them in subsequent versions. For DT, I'm waiting for settlement on refined code. As indicated by Alexandre, changes will need to travel through arm-soc tree so we'll coordinate when patches are ready. Thanks a lot! Best regards, Nicolas
On Mon, 29 Mar 2021 at 10:54, Nicolas Ferre <nicolas.ferre@microchip.com> wrote: > > On 25/03/2021 at 15:22, Emil Velikov wrote: > > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe > > > > Greetings all, > > > > On Thu, 25 Mar 2021 at 08:48, Alexandre Belloni > > <alexandre.belloni@bootlin.com> wrote: > >> > >> On 24/03/2021 14:44:14+0100, Nicolas Ferre wrote: > >>> Now, when we have the tag from Rob, how to coordinate these different > >>> pieces? Will it go through the media git tree? Will we benefit from a stable > >>> branch to share or will we just have to wait for the driver to hit Mainline > >>> before adding the defconfig and DT patches? > >>> > > Thanks for the Acked-by Nicolas. > > > >> > >> I think the defconfig and dt patches can go through at91 as soon as we > >> get Rob's ack. There is no build dependency so it can be taken at any > >> time. Worst case, we end up with a selected config option that doesn't > >> exist. > >> > > My personal preference is to merge everything in one go. > > I believe it will be easier from maintainer's point of view, plus odds > > of conflicts with the AT91 tree are close to zero. > > > > Then again, as long as the maintainers are happy - I'm fine either way. > > I'm taking defconfig 2 last patches of your series right now. No need to > include them in subsequent versions. > > For DT, I'm waiting for settlement on refined code. As indicated by > Alexandre, changes will need to travel through arm-soc tree so we'll > coordinate when patches are ready. > Ack, dropped from v3 (also fixed the Microchip typo). Thanks again Emil