On Mon, Mar 18, 2024 at 02:49:47PM +0100, Maxime Ripard wrote: > Hi, > > On Fri, Mar 15, 2024 at 10:22:05AM +0200, Ville Syrjälä wrote: > > On Mon, Mar 11, 2024 at 03:49:48PM +0100, Maxime Ripard wrote: > > > Infoframes in KMS is usually handled by a bunch of low-level helpers > > > that require quite some boilerplate for drivers. This leads to > > > discrepancies with how drivers generate them, and which are actually > > > sent. > > > > > > Now that we have everything needed to generate them in the HDMI > > > connector state, we can generate them in our common logic so that > > > drivers can simply reuse what we precomputed. > > > > > > Signed-off-by: Maxime Ripard <mripard@kernel.org> > > > --- > > > drivers/gpu/drm/Kconfig | 1 + > > > drivers/gpu/drm/drm_atomic_state_helper.c | 323 +++++++++++++++++++++ > > > drivers/gpu/drm/drm_connector.c | 14 + > > > .../gpu/drm/tests/drm_atomic_state_helper_test.c | 1 + > > > drivers/gpu/drm/tests/drm_connector_test.c | 12 + > > > include/drm/drm_atomic_state_helper.h | 8 + > > > include/drm/drm_connector.h | 133 +++++++++ > > > 7 files changed, 492 insertions(+) > > > > > > diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig > > > index 872edb47bb53..ad9c467e20ce 100644 > > > --- a/drivers/gpu/drm/Kconfig > > > +++ b/drivers/gpu/drm/Kconfig > > > @@ -97,10 +97,11 @@ config DRM_KUNIT_TEST > > > If in doubt, say "N". > > > > > > config DRM_KMS_HELPER > > > tristate > > > depends on DRM > > > + select DRM_DISPLAY_HDMI_HELPER > > > help > > > CRTC helpers for KMS drivers. > > > > > > config DRM_DEBUG_DP_MST_TOPOLOGY_REFS > > > bool "Enable refcount backtrace history in the DP MST helpers" > > > diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c b/drivers/gpu/drm/drm_atomic_state_helper.c > > > index e66272c0d006..2bf53666fc9d 100644 > > > --- a/drivers/gpu/drm/drm_atomic_state_helper.c > > > +++ b/drivers/gpu/drm/drm_atomic_state_helper.c > > > @@ -36,10 +36,12 @@ > > > #include <drm/drm_plane.h> > > > #include <drm/drm_print.h> > > > #include <drm/drm_vblank.h> > > > #include <drm/drm_writeback.h> > > > > > > +#include <drm/display/drm_hdmi_helper.h> > > > + > > > #include <linux/slab.h> > > > #include <linux/dma-fence.h> > > > > > > /** > > > * DOC: atomic state reset and initialization > > > @@ -912,10 +914,143 @@ hdmi_compute_config(const struct drm_connector *connector, > > > } > > > > > > return -EINVAL; > > > } > > > > > > +static int hdmi_generate_avi_infoframe(const struct drm_connector *connector, > > > + struct drm_connector_state *state) > > > +{ > > > + const struct drm_display_mode *mode = > > > + connector_state_get_mode(state); > > > + struct drm_connector_hdmi_infoframe *infoframe = > > > + &state->hdmi.infoframes.avi; > > > + struct hdmi_avi_infoframe *frame = > > > + &infoframe->data.avi; > > > + bool is_full_range = state->hdmi.is_full_range; > > > + enum hdmi_quantization_range rgb_quant_range = > > > + is_full_range ? HDMI_QUANTIZATION_RANGE_FULL : HDMI_QUANTIZATION_RANGE_LIMITED; > > > + int ret; > > > + > > > + ret = drm_hdmi_avi_infoframe_from_display_mode(frame, connector, mode); > > > + if (ret) > > > + return ret; > > > + > > > + frame->colorspace = state->hdmi.output_format; > > > + > > > + drm_hdmi_avi_infoframe_quant_range(frame, connector, mode, rgb_quant_range); > > > > drm_hdmi_avi_infoframe_quant_range() doesn't handle YCbCr currently. > > I guess it's not really a problem anymore if we drop YUV422 selection, > but I'll add a comment. > > > > + drm_hdmi_avi_infoframe_colorimetry(frame, state); > > > + drm_hdmi_avi_infoframe_bars(frame, state); > > > + > > > + infoframe->set = true; > > > + > > > + return 0; > > > +} > > > + > > <snip> > > > + > > > +#define UPDATE_INFOFRAME(c, os, ns, i) \ > > > + write_or_clear_infoframe(c, \ > > > + &(c)->hdmi.infoframes.i, \ > > > + &(os)->hdmi.infoframes.i, \ > > > + &(ns)->hdmi.infoframes.i) > > > > This macro feels like pointless obfuscation to me. > > I'll remove it then. > > > <snip> > > > @@ -1984,20 +2063,73 @@ struct drm_connector { > > > > > > /** > > > * @hdmi: HDMI-related variable and properties. > > > */ > > > struct { > > > +#define DRM_CONNECTOR_HDMI_VENDOR_LEN 8 > > > + /** > > > + * @vendor: HDMI Controller Vendor Name > > > + */ > > > + unsigned char vendor[DRM_CONNECTOR_HDMI_VENDOR_LEN] __nonstring; > > > + > > > +#define DRM_CONNECTOR_HDMI_PRODUCT_LEN 16 > > > + /** > > > + * @product: HDMI Controller Product Name > > > + */ > > > + unsigned char product[DRM_CONNECTOR_HDMI_PRODUCT_LEN] __nonstring; > > > + > > > /** > > > * @supported_formats: Bitmask of @hdmi_colorspace > > > * supported by the controller. > > > */ > > > unsigned long supported_formats; > > > > > > /** > > > * @funcs: HDMI connector Control Functions > > > */ > > > const struct drm_connector_hdmi_funcs *funcs; > > > + > > > + /** > > > + * @infoframes: Current Infoframes output by the connector > > > + */ > > > + struct { > > > + /** > > > + * @lock: Mutex protecting against concurrent access to > > > + * the infoframes, most notably between KMS and ALSA. > > > + */ > > > + struct mutex lock; > > > + > > > + /** > > > + * @audio: Current Audio Infoframes structure. Protected > > > + * by @lock. > > > + */ > > > + struct drm_connector_hdmi_infoframe audio; > > > + > > > + /** > > > + * @avi: Current AVI Infoframes structure. Protected by > > > + * @lock. > > > + */ > > > + struct drm_connector_hdmi_infoframe avi; > > > + > > > + /** > > > + * @hdr_drm: Current DRM (Dynamic Range and Mastering) > > > + * Infoframes structure. Protected by @lock. > > > + */ > > > + struct drm_connector_hdmi_infoframe hdr_drm; > > > + > > > + /** > > > + * @spd: Current SPD Infoframes structure. Protected by > > > + * @lock. > > > + */ > > > + struct drm_connector_hdmi_infoframe spd; > > > + > > > + /** > > > + * @vendor: Current HDMI Vendor Infoframes structure. > > > + * Protected by @lock. > > > + */ > > > + struct drm_connector_hdmi_infoframe hdmi; > > > + } infoframes; > > > } hdmi; > > > > What's the deal with this bloat? These are already tracked in the > > connector's state so this looks entirely redundant. > > The next patch in this series is about adding debugfs entries to read > the infoframes, and thus we need to care about concurrency between > debugfs files accesses and commits. Copying the things we care about > from the state to the entity is the typical solution for that, but I > guess we could also take the proper locks and access the current > connector state. Yeah, just lock and dump the latest state. That is the only thing that should of interest to anyone in userspace. Also are you actually adding some kind of ad-hoc state dump things just for these? Why not do whatever is needed to include them in the normal .atomic_state_print() stuff? -- Ville Syrjälä Intel _______________________________________________ Linux-rockchip mailing list Linux-rockchip@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip
Hi Dmitry, On 15/03/24 17:07, Dmitry Baryshkov wrote: > On Wed, 6 Mar 2024 at 05:08, Vignesh Raman <vignesh.raman@collabora.com> wrote: >> >> Uprev IGT and add amd, v3d, vc4 and vgem specific >> tests to testlist. Have testlist.txt per driver >> and include a base testlist so that the driver >> specific tests will run only on those hardware. >> Also add testlists to the MAINTAINERS file. > > I think we should move away from specifying tests explicitly. They can > easily get out of sync. A month ago I had to manually go through the > list of the tests and update it to follow changes in the IGT. > > I think we should directly use testlist.txt from IGT and then filter > it out using skips. So we use the test-list-full.txt or test-list.txt from IGT and generate a single testlist for drm-ci when we uprev IGT? Instead of adding the below to skips file for different driver, msm_.* ^amdgpu.* panfrost_.* v3d_.* vc4_.* If we have a separate testlist for each driver, we can update the main testlist.txt along with individual testlist for each driver. We just need to move the driver specific tests from main testlist to individual driver testlist file. Please let me know your thoughts. Thanks. Regards, Vignesh _______________________________________________ Linux-rockchip mailing list Linux-rockchip@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip
[-- Attachment #1.1: Type: text/plain, Size: 6605 bytes --] Hi, On Fri, Mar 15, 2024 at 10:22:05AM +0200, Ville Syrjälä wrote: > On Mon, Mar 11, 2024 at 03:49:48PM +0100, Maxime Ripard wrote: > > Infoframes in KMS is usually handled by a bunch of low-level helpers > > that require quite some boilerplate for drivers. This leads to > > discrepancies with how drivers generate them, and which are actually > > sent. > > > > Now that we have everything needed to generate them in the HDMI > > connector state, we can generate them in our common logic so that > > drivers can simply reuse what we precomputed. > > > > Signed-off-by: Maxime Ripard <mripard@kernel.org> > > --- > > drivers/gpu/drm/Kconfig | 1 + > > drivers/gpu/drm/drm_atomic_state_helper.c | 323 +++++++++++++++++++++ > > drivers/gpu/drm/drm_connector.c | 14 + > > .../gpu/drm/tests/drm_atomic_state_helper_test.c | 1 + > > drivers/gpu/drm/tests/drm_connector_test.c | 12 + > > include/drm/drm_atomic_state_helper.h | 8 + > > include/drm/drm_connector.h | 133 +++++++++ > > 7 files changed, 492 insertions(+) > > > > diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig > > index 872edb47bb53..ad9c467e20ce 100644 > > --- a/drivers/gpu/drm/Kconfig > > +++ b/drivers/gpu/drm/Kconfig > > @@ -97,10 +97,11 @@ config DRM_KUNIT_TEST > > If in doubt, say "N". > > > > config DRM_KMS_HELPER > > tristate > > depends on DRM > > + select DRM_DISPLAY_HDMI_HELPER > > help > > CRTC helpers for KMS drivers. > > > > config DRM_DEBUG_DP_MST_TOPOLOGY_REFS > > bool "Enable refcount backtrace history in the DP MST helpers" > > diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c b/drivers/gpu/drm/drm_atomic_state_helper.c > > index e66272c0d006..2bf53666fc9d 100644 > > --- a/drivers/gpu/drm/drm_atomic_state_helper.c > > +++ b/drivers/gpu/drm/drm_atomic_state_helper.c > > @@ -36,10 +36,12 @@ > > #include <drm/drm_plane.h> > > #include <drm/drm_print.h> > > #include <drm/drm_vblank.h> > > #include <drm/drm_writeback.h> > > > > +#include <drm/display/drm_hdmi_helper.h> > > + > > #include <linux/slab.h> > > #include <linux/dma-fence.h> > > > > /** > > * DOC: atomic state reset and initialization > > @@ -912,10 +914,143 @@ hdmi_compute_config(const struct drm_connector *connector, > > } > > > > return -EINVAL; > > } > > > > +static int hdmi_generate_avi_infoframe(const struct drm_connector *connector, > > + struct drm_connector_state *state) > > +{ > > + const struct drm_display_mode *mode = > > + connector_state_get_mode(state); > > + struct drm_connector_hdmi_infoframe *infoframe = > > + &state->hdmi.infoframes.avi; > > + struct hdmi_avi_infoframe *frame = > > + &infoframe->data.avi; > > + bool is_full_range = state->hdmi.is_full_range; > > + enum hdmi_quantization_range rgb_quant_range = > > + is_full_range ? HDMI_QUANTIZATION_RANGE_FULL : HDMI_QUANTIZATION_RANGE_LIMITED; > > + int ret; > > + > > + ret = drm_hdmi_avi_infoframe_from_display_mode(frame, connector, mode); > > + if (ret) > > + return ret; > > + > > + frame->colorspace = state->hdmi.output_format; > > + > > + drm_hdmi_avi_infoframe_quant_range(frame, connector, mode, rgb_quant_range); > > drm_hdmi_avi_infoframe_quant_range() doesn't handle YCbCr currently. I guess it's not really a problem anymore if we drop YUV422 selection, but I'll add a comment. > > + drm_hdmi_avi_infoframe_colorimetry(frame, state); > > + drm_hdmi_avi_infoframe_bars(frame, state); > > + > > + infoframe->set = true; > > + > > + return 0; > > +} > > + > <snip> > > + > > +#define UPDATE_INFOFRAME(c, os, ns, i) \ > > + write_or_clear_infoframe(c, \ > > + &(c)->hdmi.infoframes.i, \ > > + &(os)->hdmi.infoframes.i, \ > > + &(ns)->hdmi.infoframes.i) > > This macro feels like pointless obfuscation to me. I'll remove it then. > <snip> > > @@ -1984,20 +2063,73 @@ struct drm_connector { > > > > /** > > * @hdmi: HDMI-related variable and properties. > > */ > > struct { > > +#define DRM_CONNECTOR_HDMI_VENDOR_LEN 8 > > + /** > > + * @vendor: HDMI Controller Vendor Name > > + */ > > + unsigned char vendor[DRM_CONNECTOR_HDMI_VENDOR_LEN] __nonstring; > > + > > +#define DRM_CONNECTOR_HDMI_PRODUCT_LEN 16 > > + /** > > + * @product: HDMI Controller Product Name > > + */ > > + unsigned char product[DRM_CONNECTOR_HDMI_PRODUCT_LEN] __nonstring; > > + > > /** > > * @supported_formats: Bitmask of @hdmi_colorspace > > * supported by the controller. > > */ > > unsigned long supported_formats; > > > > /** > > * @funcs: HDMI connector Control Functions > > */ > > const struct drm_connector_hdmi_funcs *funcs; > > + > > + /** > > + * @infoframes: Current Infoframes output by the connector > > + */ > > + struct { > > + /** > > + * @lock: Mutex protecting against concurrent access to > > + * the infoframes, most notably between KMS and ALSA. > > + */ > > + struct mutex lock; > > + > > + /** > > + * @audio: Current Audio Infoframes structure. Protected > > + * by @lock. > > + */ > > + struct drm_connector_hdmi_infoframe audio; > > + > > + /** > > + * @avi: Current AVI Infoframes structure. Protected by > > + * @lock. > > + */ > > + struct drm_connector_hdmi_infoframe avi; > > + > > + /** > > + * @hdr_drm: Current DRM (Dynamic Range and Mastering) > > + * Infoframes structure. Protected by @lock. > > + */ > > + struct drm_connector_hdmi_infoframe hdr_drm; > > + > > + /** > > + * @spd: Current SPD Infoframes structure. Protected by > > + * @lock. > > + */ > > + struct drm_connector_hdmi_infoframe spd; > > + > > + /** > > + * @vendor: Current HDMI Vendor Infoframes structure. > > + * Protected by @lock. > > + */ > > + struct drm_connector_hdmi_infoframe hdmi; > > + } infoframes; > > } hdmi; > > What's the deal with this bloat? These are already tracked in the > connector's state so this looks entirely redundant. The next patch in this series is about adding debugfs entries to read the infoframes, and thus we need to care about concurrency between debugfs files accesses and commits. Copying the things we care about from the state to the entity is the typical solution for that, but I guess we could also take the proper locks and access the current connector state. Maxime [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 228 bytes --] [-- Attachment #2: Type: text/plain, Size: 170 bytes --] _______________________________________________ Linux-rockchip mailing list Linux-rockchip@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip
Instead of using 'min_queued_buffers' field to specify the minimum number of buffers to be allocated when calling REQBUF use 'min_reqbufs_allocation' field which is dedicated to this purpose. Change the minimum requested buffers to 2 for vivid-meta-out and vivid-touch-cap drivers when creating the queues. That allows to remove code which prohibe to allocate only one buffer in their respective queue setup functions. While at it rename vivid_create_queue() parameter. Signed-off-by: Benjamin Gaignard <benjamin.gaignard@collabora.com> --- version 21.1: - Change min requested buffers for vivid-meta-out and vivid-touch-cap. - Remove useless call in their queue setup functions. drivers/media/test-drivers/vimc/vimc-capture.c | 2 +- drivers/media/test-drivers/vivid/vivid-core.c | 8 ++++---- drivers/media/test-drivers/vivid/vivid-meta-out.c | 4 ---- drivers/media/test-drivers/vivid/vivid-touch-cap.c | 4 ---- 4 files changed, 5 insertions(+), 13 deletions(-) diff --git a/drivers/media/test-drivers/vimc/vimc-capture.c b/drivers/media/test-drivers/vimc/vimc-capture.c index 2a2d19d23bab..97693561f1e4 100644 --- a/drivers/media/test-drivers/vimc/vimc-capture.c +++ b/drivers/media/test-drivers/vimc/vimc-capture.c @@ -432,7 +432,7 @@ static struct vimc_ent_device *vimc_capture_add(struct vimc_device *vimc, q->mem_ops = vimc_allocator == VIMC_ALLOCATOR_DMA_CONTIG ? &vb2_dma_contig_memops : &vb2_vmalloc_memops; q->timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC; - q->min_queued_buffers = 2; + q->min_reqbufs_allocation = 2; q->lock = &vcapture->lock; q->dev = v4l2_dev->dev; diff --git a/drivers/media/test-drivers/vivid/vivid-core.c b/drivers/media/test-drivers/vivid/vivid-core.c index 159c72cbb5bf..e2d4f10003f3 100644 --- a/drivers/media/test-drivers/vivid/vivid-core.c +++ b/drivers/media/test-drivers/vivid/vivid-core.c @@ -861,7 +861,7 @@ static const struct media_device_ops vivid_media_ops = { static int vivid_create_queue(struct vivid_dev *dev, struct vb2_queue *q, u32 buf_type, - unsigned int min_queued_buffers, + unsigned int min_reqbufs_allocation, const struct vb2_ops *ops) { if (buf_type == V4L2_BUF_TYPE_VIDEO_CAPTURE && dev->multiplanar) @@ -898,7 +898,7 @@ static int vivid_create_queue(struct vivid_dev *dev, q->mem_ops = allocators[dev->inst] == 1 ? &vb2_dma_contig_memops : &vb2_vmalloc_memops; q->timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC; - q->min_queued_buffers = supports_requests[dev->inst] ? 0 : min_queued_buffers; + q->min_reqbufs_allocation = min_reqbufs_allocation; q->lock = &dev->mutex; q->dev = dev->v4l2_dev.dev; q->supports_requests = supports_requests[dev->inst]; @@ -1364,7 +1364,7 @@ static int vivid_create_queues(struct vivid_dev *dev) if (dev->has_meta_out) { /* initialize meta_out queue */ ret = vivid_create_queue(dev, &dev->vb_meta_out_q, - V4L2_BUF_TYPE_META_OUTPUT, 1, + V4L2_BUF_TYPE_META_OUTPUT, 2, &vivid_meta_out_qops); if (ret) return ret; @@ -1373,7 +1373,7 @@ static int vivid_create_queues(struct vivid_dev *dev) if (dev->has_touch_cap) { /* initialize touch_cap queue */ ret = vivid_create_queue(dev, &dev->vb_touch_cap_q, - V4L2_BUF_TYPE_VIDEO_CAPTURE, 1, + V4L2_BUF_TYPE_VIDEO_CAPTURE, 2, &vivid_touch_cap_qops); if (ret) return ret; diff --git a/drivers/media/test-drivers/vivid/vivid-meta-out.c b/drivers/media/test-drivers/vivid/vivid-meta-out.c index 4a569a6e58be..82ab3b26914e 100644 --- a/drivers/media/test-drivers/vivid/vivid-meta-out.c +++ b/drivers/media/test-drivers/vivid/vivid-meta-out.c @@ -18,7 +18,6 @@ static int meta_out_queue_setup(struct vb2_queue *vq, unsigned int *nbuffers, struct device *alloc_devs[]) { struct vivid_dev *dev = vb2_get_drv_priv(vq); - unsigned int q_num_bufs = vb2_get_num_buffers(vq); unsigned int size = sizeof(struct vivid_meta_out_buf); if (!vivid_is_webcam(dev)) @@ -31,9 +30,6 @@ static int meta_out_queue_setup(struct vb2_queue *vq, unsigned int *nbuffers, sizes[0] = size; } - if (q_num_bufs + *nbuffers < 2) - *nbuffers = 2 - q_num_bufs; - *nplanes = 1; return 0; } diff --git a/drivers/media/test-drivers/vivid/vivid-touch-cap.c b/drivers/media/test-drivers/vivid/vivid-touch-cap.c index 4b3c6ea0afde..3888c21b4d0c 100644 --- a/drivers/media/test-drivers/vivid/vivid-touch-cap.c +++ b/drivers/media/test-drivers/vivid/vivid-touch-cap.c @@ -13,7 +13,6 @@ static int touch_cap_queue_setup(struct vb2_queue *vq, unsigned int *nbuffers, struct device *alloc_devs[]) { struct vivid_dev *dev = vb2_get_drv_priv(vq); - unsigned int q_num_bufs = vb2_get_num_buffers(vq); struct v4l2_pix_format *f = &dev->tch_format; unsigned int size = f->sizeimage; @@ -24,9 +23,6 @@ static int touch_cap_queue_setup(struct vb2_queue *vq, unsigned int *nbuffers, sizes[0] = size; } - if (q_num_bufs + *nbuffers < 2) - *nbuffers = 2 - q_num_bufs; - *nplanes = 1; return 0; } -- 2.40.1 _______________________________________________ Linux-rockchip mailing list Linux-rockchip@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip
On Mon, Mar 18, 2024 at 01:05:22PM +0100, Maxime Ripard wrote: > Hi Ville, > > Thanks for your review ! > > On Fri, Mar 15, 2024 at 10:05:16AM +0200, Ville Syrjälä wrote: > > On Mon, Mar 11, 2024 at 03:49:42PM +0100, Maxime Ripard wrote: > > > +static bool > > > +sink_supports_format_bpc(const struct drm_connector *connector, > > > + const struct drm_display_info *info, > > > + const struct drm_display_mode *mode, > > > + unsigned int format, unsigned int bpc) > > > +{ > > > + struct drm_device *dev = connector->dev; > > > + u8 vic = drm_match_cea_mode(mode); > > > + > > > + if (vic == 1 && bpc != 8) { > > > + drm_dbg(dev, "VIC1 requires a bpc of 8, got %u\n", bpc); > > > > Use of drm_dbg() for kms stuff is surprising. > > > > > + return false; > > > + } > > > > I don't think we have this in i915. My original impression was that you > > can use higher color depth if you can determine the sink capabilities, > > but all sinks are required to accept 640x480@8bpc as a fallback. > > > > but CTA-861-H says: > > "5.4 Color Coding & Quantization > > Component Depth: The coding shall be N-bit, where N = 8, 10, 12, or 16 > > bits/component — except in the case of the default 640x480 Video Timing 1, > > where the value of N shall be 8." > > > > So that does seem to imply that you're supposed to use exactly 8bpc. > > Though the word "default" in there is confusing. Are they specifically > > using that to indicate that this is about the fallback behaviour, or > > is it just indicating that it is a "default mode that always has to > > be supported". Dunno. I guess no real harm in forcing 8bpc for 640x480 > > since no one is likely to use that for any high fidelity stuff. > > My understanding was that CTA-861 mandates that 640x480@60Hz is > supported, and mentions it being the default timing on a few occurences, > like in section 4 - Video Formats and Waveform Timings that states "This > section describes the default IT 640x480 Video Timing as well as all of > the standard CE Video Timings.", or Section 6.2 - Describing Video > Formats in EDID "The 640x480@60Hz flag, in the Established Timings area, > shall always be set, since the 640x480p format is a mandatory default > timing." > > So my understanding is that default here applies to the timing itself, > and not the bpc, and is thus the second interpretation you suggested. > > I'll add a comment to make it clearer. > > > > +static int > > > +hdmi_compute_format(const struct drm_connector *connector, > > > + struct drm_connector_state *state, > > > + const struct drm_display_mode *mode, > > > + unsigned int bpc) > > > +{ > > > + struct drm_device *dev = connector->dev; > > > + > > > + if (hdmi_try_format_bpc(connector, state, mode, bpc, HDMI_COLORSPACE_RGB)) { > > > + state->hdmi.output_format = HDMI_COLORSPACE_RGB; > > > + return 0; > > > + } > > > + > > > + if (hdmi_try_format_bpc(connector, state, mode, bpc, HDMI_COLORSPACE_YUV422)) { > > > + state->hdmi.output_format = HDMI_COLORSPACE_YUV422; > > > + return 0; > > > + } > > > > Looks like you're preferring YCbCr 4:2:2 over RGB 8bpc. Not sure > > if that's a good tradeoff to make. > > Yeah, indeed. I guess it's a judgement call on whether we prioritise > lowering the bpc over selecting YUV422, but I guess I can try all > available RGB bpc before falling back to YUV422. > > > In i915 we don't currently expose 4:2:2 at all because it doesn't > > help in getting a working display, and we have no uapi for the > > user to force it if they really want 4:2:2 over RGB. > > I guess if the priority is given to lowering bpc, then it indeed doesn't > make sense to support YUV422, since the limiting factor is likely to be > the TMDS char rate and YUV422 12 bpc is equivalent to RGB 8bpc there. > > dw-hdmi on the other hand will always put YUV422 and YUV444 before RGB > for a given bpc, which is weird to me: > https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c#L2696 > > What is even weirder to me is that YUV422 is explicitly stated to be > 12bpc only, so there's some invalid configurations there (8 and 10 bpc). > > And given that it's order by decreasing order of preference, I'm pretty > sure it'll never actually pick any YUV or RGB > 8bpc format since RGB > 8bpc is super likely to be always available and thus picked first. 8bpc RGB is in fact mandatory. > > If we want to converge, I think we should amend this code to support > YUV420 for YUV420-only modes first, and then the RGB options like i915 > is doing. And then if someone is interested in more, we can always > expand it to other formats. > > > > + > > > + drm_dbg(dev, "Failed. No Format Supported for that bpc count.\n"); > > > + > > > + return -EINVAL; > > > +} > > > + > > > +static int > > > +hdmi_compute_config(const struct drm_connector *connector, > > > + struct drm_connector_state *state, > > > + const struct drm_display_mode *mode) > > > +{ > > > + struct drm_device *dev = connector->dev; > > > + unsigned int max_bpc = clamp_t(unsigned int, > > > + state->max_bpc, > > > + 8, connector->max_bpc); > > > + unsigned int bpc; > > > + int ret; > > > + > > > + for (bpc = max_bpc; bpc >= 8; bpc -= 2) { > > > + drm_dbg(dev, "Trying with a %d bpc output\n", bpc); > > > + > > > + ret = hdmi_compute_format(connector, state, mode, bpc); > > > > Hmm. Actually I'm not sure your 4:2:2 stuff even works since you > > check for bpc==12 in there and only call this based on the max_bpc. > > I'm not convinced max_bpc would actually be 12 for a sink that > > supports YCbCr 4:2:2 but not 12bpc RGB. > > It's another discussion we had in an earlier version, but yeah we lack > the infrastructure to support those for now. I still believe it would > require an increased max_bpc to select YUV422, otherwise things would be > pretty inconsistent with other YUV formats. Ideally I'd like to know the actual color depth of the panel independently of the supported signal color depths. Unfortunately I don't think EDID gives us that. Can't recall if DisplayID might have something a bit more sensible. Given how info->bpc works right now, I suppose it would make sense to bump it up to 12 when 4:2:2 is supported. But I've not thought through the actual implications such a change. > But yeah, we need to provide a hook to report we don't support RGB > > 8bpc for HDMI 1.4 devices. Which goes back to the previous question > actually, I believe it would still provide value to support YUV422 on > those devices, with something like: > > for (bpc = max_bpc; bpc >= 8; bpc -= 2) { > if (!connector->hdmi->funcs->validate_config(mode, RGB, bpc)) > continue; > > // Select RGB with bpc > ... > } > > if (connector->hdmi->funcs->validate_config(mode, YUV) && > hdmi_try_format_bpc(..., mode, 12, YUV422) { > // Select YUV422, 12 bpc > ... > } > > What do you think? Since 8bpc RGB must always be supported this looks like dead code to me. -- Ville Syrjälä Intel _______________________________________________ Linux-rockchip mailing list Linux-rockchip@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip
On 18/03/2024 11:06 am, Hans Verkuil wrote: > Hi Benjamin, > > On 14/03/2024 4:32 pm, Benjamin Gaignard wrote: >> Instead of using 'min_queued_buffers' field to specify the >> minimum number of buffers to be allocated when calling REQBUF >> use 'min_reqbufs_allocation' field which is dedicated to this >> purpose. >> >> While at it rename vivid_create_queue() parameter. >> >> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@collabora.com> >> --- >> drivers/media/test-drivers/vimc/vimc-capture.c | 2 +- >> drivers/media/test-drivers/vivid/vivid-core.c | 4 ++-- >> 2 files changed, 3 insertions(+), 3 deletions(-) >> >> diff --git a/drivers/media/test-drivers/vimc/vimc-capture.c b/drivers/media/test-drivers/vimc/vimc-capture.c >> index 2a2d19d23bab..97693561f1e4 100644 >> --- a/drivers/media/test-drivers/vimc/vimc-capture.c >> +++ b/drivers/media/test-drivers/vimc/vimc-capture.c >> @@ -432,7 +432,7 @@ static struct vimc_ent_device *vimc_capture_add(struct vimc_device *vimc, >> q->mem_ops = vimc_allocator == VIMC_ALLOCATOR_DMA_CONTIG >> ? &vb2_dma_contig_memops : &vb2_vmalloc_memops; >> q->timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC; >> - q->min_queued_buffers = 2; >> + q->min_reqbufs_allocation = 2; >> q->lock = &vcapture->lock; >> q->dev = v4l2_dev->dev; >> >> diff --git a/drivers/media/test-drivers/vivid/vivid-core.c b/drivers/media/test-drivers/vivid/vivid-core.c >> index 159c72cbb5bf..11b8520d9f57 100644 >> --- a/drivers/media/test-drivers/vivid/vivid-core.c >> +++ b/drivers/media/test-drivers/vivid/vivid-core.c >> @@ -861,7 +861,7 @@ static const struct media_device_ops vivid_media_ops = { >> static int vivid_create_queue(struct vivid_dev *dev, >> struct vb2_queue *q, >> u32 buf_type, >> - unsigned int min_queued_buffers, >> + unsigned int min_reqbufs_allocation, >> const struct vb2_ops *ops) >> { >> if (buf_type == V4L2_BUF_TYPE_VIDEO_CAPTURE && dev->multiplanar) >> @@ -898,7 +898,7 @@ static int vivid_create_queue(struct vivid_dev *dev, >> q->mem_ops = allocators[dev->inst] == 1 ? &vb2_dma_contig_memops : >> &vb2_vmalloc_memops; >> q->timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC; >> - q->min_queued_buffers = supports_requests[dev->inst] ? 0 : min_queued_buffers; >> + q->min_reqbufs_allocation = min_reqbufs_allocation; >> q->lock = &dev->mutex; >> q->dev = dev->v4l2_dev.dev; >> q->supports_requests = supports_requests[dev->inst]; > > How did you test this series? If I run the test-media script using the patch > v4l2-compliance (the v9 series) I get two failures. Both are traced to code > in vivid: meta_out_queue_setup() and touch_cap_queue_setup(): > > Both have this code: > > if (*nplanes) { > if (sizes[0] < size) > return -EINVAL; > } else { > sizes[0] = size; > } > > if (q_num_bufs + *nbuffers < 2) > *nbuffers = 2 - q_num_bufs; > > *nplanes = 1; > return 0; > > It's the *nbuffers assignment that is wrong. Looking at vivid-core.c I see > that vivid_create_queue() is called with min_reqbufs_allocation set to 1 for > these two devices. I think that should be 2, and then the code above can > be dropped. Note that if that 'if (q_num_bufs + *nbuffers < 2)' is dropped, then you should also drop the q_num_bufs assignment at the beginning of the function since that is now no longer used. Regards, Hans > > It is probably best to post a v21.1 3/9 patch only. > > Regards, > > Hans > > > _______________________________________________ Linux-rockchip mailing list Linux-rockchip@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip
[-- Attachment #1.1: Type: text/plain, Size: 6289 bytes --] Hi Ville, Thanks for your review ! On Fri, Mar 15, 2024 at 10:05:16AM +0200, Ville Syrjälä wrote: > On Mon, Mar 11, 2024 at 03:49:42PM +0100, Maxime Ripard wrote: > > +static bool > > +sink_supports_format_bpc(const struct drm_connector *connector, > > + const struct drm_display_info *info, > > + const struct drm_display_mode *mode, > > + unsigned int format, unsigned int bpc) > > +{ > > + struct drm_device *dev = connector->dev; > > + u8 vic = drm_match_cea_mode(mode); > > + > > + if (vic == 1 && bpc != 8) { > > + drm_dbg(dev, "VIC1 requires a bpc of 8, got %u\n", bpc); > > Use of drm_dbg() for kms stuff is surprising. > > > + return false; > > + } > > I don't think we have this in i915. My original impression was that you > can use higher color depth if you can determine the sink capabilities, > but all sinks are required to accept 640x480@8bpc as a fallback. > > but CTA-861-H says: > "5.4 Color Coding & Quantization > Component Depth: The coding shall be N-bit, where N = 8, 10, 12, or 16 > bits/component — except in the case of the default 640x480 Video Timing 1, > where the value of N shall be 8." > > So that does seem to imply that you're supposed to use exactly 8bpc. > Though the word "default" in there is confusing. Are they specifically > using that to indicate that this is about the fallback behaviour, or > is it just indicating that it is a "default mode that always has to > be supported". Dunno. I guess no real harm in forcing 8bpc for 640x480 > since no one is likely to use that for any high fidelity stuff. My understanding was that CTA-861 mandates that 640x480@60Hz is supported, and mentions it being the default timing on a few occurences, like in section 4 - Video Formats and Waveform Timings that states "This section describes the default IT 640x480 Video Timing as well as all of the standard CE Video Timings.", or Section 6.2 - Describing Video Formats in EDID "The 640x480@60Hz flag, in the Established Timings area, shall always be set, since the 640x480p format is a mandatory default timing." So my understanding is that default here applies to the timing itself, and not the bpc, and is thus the second interpretation you suggested. I'll add a comment to make it clearer. > > +static int > > +hdmi_compute_format(const struct drm_connector *connector, > > + struct drm_connector_state *state, > > + const struct drm_display_mode *mode, > > + unsigned int bpc) > > +{ > > + struct drm_device *dev = connector->dev; > > + > > + if (hdmi_try_format_bpc(connector, state, mode, bpc, HDMI_COLORSPACE_RGB)) { > > + state->hdmi.output_format = HDMI_COLORSPACE_RGB; > > + return 0; > > + } > > + > > + if (hdmi_try_format_bpc(connector, state, mode, bpc, HDMI_COLORSPACE_YUV422)) { > > + state->hdmi.output_format = HDMI_COLORSPACE_YUV422; > > + return 0; > > + } > > Looks like you're preferring YCbCr 4:2:2 over RGB 8bpc. Not sure > if that's a good tradeoff to make. Yeah, indeed. I guess it's a judgement call on whether we prioritise lowering the bpc over selecting YUV422, but I guess I can try all available RGB bpc before falling back to YUV422. > In i915 we don't currently expose 4:2:2 at all because it doesn't > help in getting a working display, and we have no uapi for the > user to force it if they really want 4:2:2 over RGB. I guess if the priority is given to lowering bpc, then it indeed doesn't make sense to support YUV422, since the limiting factor is likely to be the TMDS char rate and YUV422 12 bpc is equivalent to RGB 8bpc there. dw-hdmi on the other hand will always put YUV422 and YUV444 before RGB for a given bpc, which is weird to me: https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c#L2696 What is even weirder to me is that YUV422 is explicitly stated to be 12bpc only, so there's some invalid configurations there (8 and 10 bpc). And given that it's order by decreasing order of preference, I'm pretty sure it'll never actually pick any YUV or RGB > 8bpc format since RGB 8bpc is super likely to be always available and thus picked first. If we want to converge, I think we should amend this code to support YUV420 for YUV420-only modes first, and then the RGB options like i915 is doing. And then if someone is interested in more, we can always expand it to other formats. > > + > > + drm_dbg(dev, "Failed. No Format Supported for that bpc count.\n"); > > + > > + return -EINVAL; > > +} > > + > > +static int > > +hdmi_compute_config(const struct drm_connector *connector, > > + struct drm_connector_state *state, > > + const struct drm_display_mode *mode) > > +{ > > + struct drm_device *dev = connector->dev; > > + unsigned int max_bpc = clamp_t(unsigned int, > > + state->max_bpc, > > + 8, connector->max_bpc); > > + unsigned int bpc; > > + int ret; > > + > > + for (bpc = max_bpc; bpc >= 8; bpc -= 2) { > > + drm_dbg(dev, "Trying with a %d bpc output\n", bpc); > > + > > + ret = hdmi_compute_format(connector, state, mode, bpc); > > Hmm. Actually I'm not sure your 4:2:2 stuff even works since you > check for bpc==12 in there and only call this based on the max_bpc. > I'm not convinced max_bpc would actually be 12 for a sink that > supports YCbCr 4:2:2 but not 12bpc RGB. It's another discussion we had in an earlier version, but yeah we lack the infrastructure to support those for now. I still believe it would require an increased max_bpc to select YUV422, otherwise things would be pretty inconsistent with other YUV formats. But yeah, we need to provide a hook to report we don't support RGB > 8bpc for HDMI 1.4 devices. Which goes back to the previous question actually, I believe it would still provide value to support YUV422 on those devices, with something like: for (bpc = max_bpc; bpc >= 8; bpc -= 2) { if (!connector->hdmi->funcs->validate_config(mode, RGB, bpc)) continue; // Select RGB with bpc ... } if (connector->hdmi->funcs->validate_config(mode, YUV) && hdmi_try_format_bpc(..., mode, 12, YUV422) { // Select YUV422, 12 bpc ... } What do you think? Maxime [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 228 bytes --] [-- Attachment #2: Type: text/plain, Size: 170 bytes --] _______________________________________________ Linux-rockchip mailing list Linux-rockchip@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip
Hi Benjamin, On 14/03/2024 4:32 pm, Benjamin Gaignard wrote: > Instead of using 'min_queued_buffers' field to specify the > minimum number of buffers to be allocated when calling REQBUF > use 'min_reqbufs_allocation' field which is dedicated to this > purpose. > > While at it rename vivid_create_queue() parameter. > > Signed-off-by: Benjamin Gaignard <benjamin.gaignard@collabora.com> > --- > drivers/media/test-drivers/vimc/vimc-capture.c | 2 +- > drivers/media/test-drivers/vivid/vivid-core.c | 4 ++-- > 2 files changed, 3 insertions(+), 3 deletions(-) > > diff --git a/drivers/media/test-drivers/vimc/vimc-capture.c b/drivers/media/test-drivers/vimc/vimc-capture.c > index 2a2d19d23bab..97693561f1e4 100644 > --- a/drivers/media/test-drivers/vimc/vimc-capture.c > +++ b/drivers/media/test-drivers/vimc/vimc-capture.c > @@ -432,7 +432,7 @@ static struct vimc_ent_device *vimc_capture_add(struct vimc_device *vimc, > q->mem_ops = vimc_allocator == VIMC_ALLOCATOR_DMA_CONTIG > ? &vb2_dma_contig_memops : &vb2_vmalloc_memops; > q->timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC; > - q->min_queued_buffers = 2; > + q->min_reqbufs_allocation = 2; > q->lock = &vcapture->lock; > q->dev = v4l2_dev->dev; > > diff --git a/drivers/media/test-drivers/vivid/vivid-core.c b/drivers/media/test-drivers/vivid/vivid-core.c > index 159c72cbb5bf..11b8520d9f57 100644 > --- a/drivers/media/test-drivers/vivid/vivid-core.c > +++ b/drivers/media/test-drivers/vivid/vivid-core.c > @@ -861,7 +861,7 @@ static const struct media_device_ops vivid_media_ops = { > static int vivid_create_queue(struct vivid_dev *dev, > struct vb2_queue *q, > u32 buf_type, > - unsigned int min_queued_buffers, > + unsigned int min_reqbufs_allocation, > const struct vb2_ops *ops) > { > if (buf_type == V4L2_BUF_TYPE_VIDEO_CAPTURE && dev->multiplanar) > @@ -898,7 +898,7 @@ static int vivid_create_queue(struct vivid_dev *dev, > q->mem_ops = allocators[dev->inst] == 1 ? &vb2_dma_contig_memops : > &vb2_vmalloc_memops; > q->timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC; > - q->min_queued_buffers = supports_requests[dev->inst] ? 0 : min_queued_buffers; > + q->min_reqbufs_allocation = min_reqbufs_allocation; > q->lock = &dev->mutex; > q->dev = dev->v4l2_dev.dev; > q->supports_requests = supports_requests[dev->inst]; How did you test this series? If I run the test-media script using the patch v4l2-compliance (the v9 series) I get two failures. Both are traced to code in vivid: meta_out_queue_setup() and touch_cap_queue_setup(): Both have this code: if (*nplanes) { if (sizes[0] < size) return -EINVAL; } else { sizes[0] = size; } if (q_num_bufs + *nbuffers < 2) *nbuffers = 2 - q_num_bufs; *nplanes = 1; return 0; It's the *nbuffers assignment that is wrong. Looking at vivid-core.c I see that vivid_create_queue() is called with min_reqbufs_allocation set to 1 for these two devices. I think that should be 2, and then the code above can be dropped. It is probably best to post a v21.1 3/9 patch only. Regards, Hans _______________________________________________ Linux-rockchip mailing list Linux-rockchip@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip
Hi Ondrej, On Sat, Mar 16, 2024 at 12:02:41AM +0100, Ondřej Jirman wrote: > From: Ondrej Jirman <megi@xff.cz> > > - RK3399 has input/output limit of main path 4416 x 3312 > - PX30 has input/output limit of main path 3264 x 2448 > - i.MX8MP has input/output limit of main path 4096 x 3072 > > Use rkisp1_info struct to encode the limits. > > Signed-off-by: Ondrej Jirman <megi@xff.cz> Looks good to me. Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> > --- > v2: > - adapt to i.MX8MP merged for v6.9 > > drivers/media/platform/rockchip/rkisp1/rkisp1-common.h | 6 ++++-- > drivers/media/platform/rockchip/rkisp1/rkisp1-csi.c | 5 +++-- > drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c | 6 ++++++ > drivers/media/platform/rockchip/rkisp1/rkisp1-isp.c | 9 +++++---- > drivers/media/platform/rockchip/rkisp1/rkisp1-resizer.c | 4 ++-- > 5 files changed, 20 insertions(+), 10 deletions(-) > > diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-common.h b/drivers/media/platform/rockchip/rkisp1/rkisp1-common.h > index 26573f6ae575..b4c958b93629 100644 > --- a/drivers/media/platform/rockchip/rkisp1/rkisp1-common.h > +++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-common.h > @@ -34,8 +34,6 @@ struct regmap; > #define RKISP1_ISP_SD_SINK BIT(1) > > /* min and max values for the widths and heights of the entities */ > -#define RKISP1_ISP_MAX_WIDTH 4032 > -#define RKISP1_ISP_MAX_HEIGHT 3024 > #define RKISP1_ISP_MIN_WIDTH 32 > #define RKISP1_ISP_MIN_HEIGHT 32 > > @@ -140,6 +138,8 @@ enum rkisp1_feature { > * @isr_size: number of entries in the @isrs array > * @isp_ver: ISP version > * @features: bitmask of rkisp1_feature features implemented by the ISP > + * @max_width: maximum input frame width > + * @max_height: maximum input frame height > * > * This structure contains information about the ISP specific to a particular > * ISP model, version, or integration in a particular SoC. > @@ -151,6 +151,8 @@ struct rkisp1_info { > unsigned int isr_size; > enum rkisp1_cif_isp_version isp_ver; > unsigned int features; > + unsigned int max_width; > + unsigned int max_height; > }; > > /* > diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-csi.c b/drivers/media/platform/rockchip/rkisp1/rkisp1-csi.c > index 4202642e0523..841e58c20f7f 100644 > --- a/drivers/media/platform/rockchip/rkisp1/rkisp1-csi.c > +++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-csi.c > @@ -307,6 +307,7 @@ static int rkisp1_csi_set_fmt(struct v4l2_subdev *sd, > struct v4l2_subdev_state *sd_state, > struct v4l2_subdev_format *fmt) > { > + struct rkisp1_csi *csi = to_rkisp1_csi(sd); > const struct rkisp1_mbus_info *mbus_info; > struct v4l2_mbus_framefmt *sink_fmt, *src_fmt; > > @@ -326,10 +327,10 @@ static int rkisp1_csi_set_fmt(struct v4l2_subdev *sd, > > sink_fmt->width = clamp_t(u32, fmt->format.width, > RKISP1_ISP_MIN_WIDTH, > - RKISP1_ISP_MAX_WIDTH); > + csi->rkisp1->info->max_width); > sink_fmt->height = clamp_t(u32, fmt->format.height, > RKISP1_ISP_MIN_HEIGHT, > - RKISP1_ISP_MAX_HEIGHT); > + csi->rkisp1->info->max_height); > > fmt->format = *sink_fmt; > > diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c b/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c > index bb0202386c70..0535ce57e862 100644 > --- a/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c > +++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c > @@ -510,6 +510,8 @@ static const struct rkisp1_info px30_isp_info = { > .features = RKISP1_FEATURE_MIPI_CSI2 > | RKISP1_FEATURE_SELF_PATH > | RKISP1_FEATURE_DUAL_CROP, > + .max_width = 3264, > + .max_height = 2448, > }; > > static const char * const rk3399_isp_clks[] = { > @@ -531,6 +533,8 @@ static const struct rkisp1_info rk3399_isp_info = { > .features = RKISP1_FEATURE_MIPI_CSI2 > | RKISP1_FEATURE_SELF_PATH > | RKISP1_FEATURE_DUAL_CROP, > + .max_width = 4416, > + .max_height = 3312, > }; > > static const char * const imx8mp_isp_clks[] = { > @@ -551,6 +555,8 @@ static const struct rkisp1_info imx8mp_isp_info = { > .isp_ver = RKISP1_V_IMX8MP, > .features = RKISP1_FEATURE_MAIN_STRIDE > | RKISP1_FEATURE_DMA_34BIT, > + .max_width = 4096, > + .max_height = 3072, > }; > > static const struct of_device_id rkisp1_of_match[] = { > diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-isp.c b/drivers/media/platform/rockchip/rkisp1/rkisp1-isp.c > index e45a213baf49..f787a7e91e3e 100644 > --- a/drivers/media/platform/rockchip/rkisp1/rkisp1-isp.c > +++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-isp.c > @@ -517,6 +517,7 @@ static int rkisp1_isp_enum_frame_size(struct v4l2_subdev *sd, > struct v4l2_subdev_state *sd_state, > struct v4l2_subdev_frame_size_enum *fse) > { > + struct rkisp1_isp *isp = to_rkisp1_isp(sd); > const struct rkisp1_mbus_info *mbus_info; > > if (fse->pad == RKISP1_ISP_PAD_SINK_PARAMS || > @@ -539,9 +540,9 @@ static int rkisp1_isp_enum_frame_size(struct v4l2_subdev *sd, > return -EINVAL; > > fse->min_width = RKISP1_ISP_MIN_WIDTH; > - fse->max_width = RKISP1_ISP_MAX_WIDTH; > + fse->max_width = isp->rkisp1->info->max_width; > fse->min_height = RKISP1_ISP_MIN_HEIGHT; > - fse->max_height = RKISP1_ISP_MAX_HEIGHT; > + fse->max_height = isp->rkisp1->info->max_height; > > return 0; > } > @@ -772,10 +773,10 @@ static void rkisp1_isp_set_sink_fmt(struct rkisp1_isp *isp, > > sink_fmt->width = clamp_t(u32, format->width, > RKISP1_ISP_MIN_WIDTH, > - RKISP1_ISP_MAX_WIDTH); > + isp->rkisp1->info->max_width); > sink_fmt->height = clamp_t(u32, format->height, > RKISP1_ISP_MIN_HEIGHT, > - RKISP1_ISP_MAX_HEIGHT); > + isp->rkisp1->info->max_height); > > /* > * Adjust the color space fields. Accept any color primaries and > diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-resizer.c b/drivers/media/platform/rockchip/rkisp1/rkisp1-resizer.c > index 6f3931ca5b51..e22cc2db24cf 100644 > --- a/drivers/media/platform/rockchip/rkisp1/rkisp1-resizer.c > +++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-resizer.c > @@ -494,10 +494,10 @@ static void rkisp1_rsz_set_sink_fmt(struct rkisp1_resizer *rsz, > > sink_fmt->width = clamp_t(u32, format->width, > RKISP1_ISP_MIN_WIDTH, > - RKISP1_ISP_MAX_WIDTH); > + rsz->rkisp1->info->max_width); > sink_fmt->height = clamp_t(u32, format->height, > RKISP1_ISP_MIN_HEIGHT, > - RKISP1_ISP_MAX_HEIGHT); > + rsz->rkisp1->info->max_height); > > /* > * Adjust the color space fields. Accept any color primaries and > -- > 2.44.0 > _______________________________________________ Linux-rockchip mailing list Linux-rockchip@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip
On 3/8/24 08:27, Sebastian Reichel wrote: > [removed DT people from CC, since this is all about clocks now] > > Hello Ilya, > > On Fri, Mar 08, 2024 at 10:23:31AM +0300, Ilya K wrote: >> This change seems to make my Orange Pi 5 (RK3588S) lock up on boot >> :( Any suggestions on how to debug this? It doesn't really log >> much... > > I suppose with this change you explicitly mean the last patch, which > has not yet been applied? That patch effectively allows some clocks > to be disabled, that have previously been marked as critical (and > thus always-on). > > If that results in a boot lockup, I expect you have a peripheral > driver, that does not enable a required clock (e.g. because of a > missing clock reference). Sebastian, Another Orange Pi 5 owner here... I likewise ran into trouble with this patch. I have been playing with your rk3588 branch from the Collabora gitlab and was also experiencing hangs on boot on my OPi5. I bisected your branch and found that the GATE_LINK support commit was the problem for me. Digging in, I found that the problem behind the hang was that I was not getting the aclk_nvm_root which in turn caused DMA transactions to the SFC driver to hang. ... [ 2.804519] rockchip-sfc fe2b0000.spi: DMA wait for transfer finish timeout [ 2.805127] rockchip-sfc fe2b0000.spi: xfer data failed ret -110 dir 1 ... Setting aclk_nvm_root to critical allows the system to boot. However not all is well as I do get errors like the following which also seem to indicate further clock problems: [ 6.296554] rockchip-pm-domain fd8d8000.power-management:power-controller: failed to set idle on domain 'vo0', val=0 I assume that the con-ops of your patch is analogous to the downstream "clock-link" driver. (ie. you are looking for PM events to cause the pm_clk_suspend()/pm_clk_resume() routines to enable/disable the linked (second parent) clocks). This wasn't happening for me. Unlike in the downstream implementation, the gate_link devices' dev->driver pointer was null. So that when rpm_resume() was being called, it would make its way to pm_generic_runtime_resume() which then would do nothing. The end result is that I would have a prepare count of 1 on aclk_nvm_root, but an enable count of 0 so it would get disabled (orig patch w/o marking this critical). I did a quick hacky proof of concept where I set up the pm ops on the clk-rk3588 driver to point to the pm_clk_suspend/pm_clk_resume routines like downstream did. I used device_bind_driver() to forceably bind the clk-rk3588 driver to the gate link devices it was setting up. This worked for me. With those changes I then was able to boot without needing to set aclk_nvm_root as critical. Further, it cleaned up the power-controller error messages on the sdio and vo0 domains. The force bind I did doesn't feel like a particularly clean solution to me. However, I am not knowledgeable enough in the (platform) device model to know what the right way to do this is without fully doing what downstream did and having DT nodes for the various gate link devices. But it seems to prove out that having the driver bound to the devices with the relevant runtime pm ops is the missing piece in my use case on the OPi5. Hope this additional data point helps! -- Chad LeClair _______________________________________________ Linux-rockchip mailing list Linux-rockchip@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip
[-- Attachment #1.1: Type: text/plain, Size: 1317 bytes --] On Fri, Mar 15, 2024 at 07:18:05PM +0500, Dmitry Yashin wrote: > FET3588-C is an System on Module made by Forlinx based on Rockchip RK3588. > This SoM used by OK3588-C Board. > > FET3588-C features: > - Rockchip RK3588 > - LPDDR4 4/8 GB > - eMMC 32/64 GB > > Add devicetree binding for Forlinx FET3588-C SoM. > > Signed-off-by: Dmitry Yashin <dmt.yashin@gmail.com> Acked-by: Conor Dooley <conor.dooley@microchip.com> Thanks, Conor. > --- > Documentation/devicetree/bindings/arm/rockchip.yaml | 7 +++++++ > 1 file changed, 7 insertions(+) > > diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml > index 5cf5cbef2cf5..d87f4955f509 100644 > --- a/Documentation/devicetree/bindings/arm/rockchip.yaml > +++ b/Documentation/devicetree/bindings/arm/rockchip.yaml > @@ -211,6 +211,13 @@ properties: > - const: firefly,rk3568-roc-pc > - const: rockchip,rk3568 > > + - description: Forlinx FET3588-C SoM > + items: > + - enum: > + - forlinx,ok3588-c > + - const: forlinx,fet3588-c > + - const: rockchip,rk3588 > + > - description: FriendlyElec NanoPi R2 series boards > items: > - enum: > -- > 2.44.0 > [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 228 bytes --] [-- Attachment #2: Type: text/plain, Size: 170 bytes --] _______________________________________________ Linux-rockchip mailing list Linux-rockchip@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip
[-- Attachment #1.1: Type: text/plain, Size: 341 bytes --] On Sat, Mar 16, 2024 at 03:11:00PM +0800, Jianfeng Liu wrote: > Add Hantro G1 VPU compatible string for RK3588. > RK3588 has the same Hantro G1 ip as RK3568, which are both > known as VDPU121 in TRM of RK3568 and RK3588. > > Signed-off-by: Jianfeng Liu <liujianfeng1994@gmail.com> Acked-by: Conor Dooley <conor.dooley@microchip.com> [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 228 bytes --] [-- Attachment #2: Type: text/plain, Size: 170 bytes --] _______________________________________________ Linux-rockchip mailing list Linux-rockchip@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip
Add Hantro G1 VPU compatible string for RK3588. RK3588 has the same Hantro G1 ip as RK3568, which are both known as VDPU121 in TRM of RK3568 and RK3588. Signed-off-by: Jianfeng Liu <liujianfeng1994@gmail.com> --- Documentation/devicetree/bindings/media/rockchip-vpu.yaml | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Documentation/devicetree/bindings/media/rockchip-vpu.yaml b/Documentation/devicetree/bindings/media/rockchip-vpu.yaml index c57e1f488..4f667db91 100644 --- a/Documentation/devicetree/bindings/media/rockchip-vpu.yaml +++ b/Documentation/devicetree/bindings/media/rockchip-vpu.yaml @@ -31,6 +31,9 @@ properties: - items: - const: rockchip,rk3228-vpu - const: rockchip,rk3399-vpu + - items: + - const: rockchip,rk3588-vdpu121 + - const: rockchip,rk3568-vpu reg: maxItems: 1 -- 2.34.1 _______________________________________________ Linux-rockchip mailing list Linux-rockchip@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip
Enable Hantro G1 video decoder in RK3588's devicetree. Tested with FFmpeg v4l2_request code taken from [1] with MPEG2, H.264 and VP8 samples. [1] https://github.com/LibreELEC/LibreELEC.tv/blob/master/packages/multimedia/ffmpeg/patches/v4l2-request/ffmpeg-001-v4l2-request.patch Signed-off-by: Jianfeng Liu <liujianfeng1994@gmail.com> --- arch/arm64/boot/dts/rockchip/rk3588s.dtsi | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) diff --git a/arch/arm64/boot/dts/rockchip/rk3588s.dtsi b/arch/arm64/boot/dts/rockchip/rk3588s.dtsi index 87b83c87b..2e411c80a 100644 --- a/arch/arm64/boot/dts/rockchip/rk3588s.dtsi +++ b/arch/arm64/boot/dts/rockchip/rk3588s.dtsi @@ -646,6 +646,26 @@ i2c0: i2c@fd880000 { status = "disabled"; }; + vpu: video-codec@fdb50000 { + compatible = "rockchip,rk3588-vdpu121", "rockchip,rk3568-vpu"; + reg = <0x0 0xfdb50000 0x0 0x800>; + interrupts = <GIC_SPI 119 IRQ_TYPE_LEVEL_HIGH 0>; + clocks = <&cru ACLK_VPU>, <&cru HCLK_VPU>; + clock-names = "aclk", "hclk"; + iommus = <&vdpu_mmu>; + power-domains = <&power RK3588_PD_VDPU>; + }; + + vdpu_mmu: iommu@fdb50800 { + compatible = "rockchip,rk3588-iommu", "rockchip,rk3568-iommu"; + reg = <0x0 0xfdb50800 0x0 0x40>; + interrupts = <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH 0>; + clock-names = "aclk", "iface"; + clocks = <&cru ACLK_VPU>, <&cru HCLK_VPU>; + power-domains = <&power RK3588_PD_VDPU>; + #iommu-cells = <0>; + }; + vop: vop@fdd90000 { compatible = "rockchip,rk3588-vop"; reg = <0x0 0xfdd90000 0x0 0x4200>, <0x0 0xfdd95000 0x0 0x1000>; -- 2.34.1 _______________________________________________ Linux-rockchip mailing list Linux-rockchip@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip
This is the v4 version of this series adding hantro g1 video decoder support for rk3588. RK3588 has Hantro G1 video decoder known as VDPU121 in TRM of RK3588 which is capable to decode MPEG2/H.264/VP8 up to 1920x1088. This vpu ip is also found in RK3568. Test results from fluster can be found from thread of v3[1] https://lore.kernel.org/all/20240118080602.9028-1-liujianfeng1994@gmail.com/ Changes in v4: - Change compatible string to rockchip,rk3588-vdpu121 - Link to v3: https://lore.kernel.org/all/20231231151112.3994194-1-liujianfeng1994@gmail.com/ Jianfeng Liu (2): arm64: dts: rockchip: Add Hantro G1 VPU support for RK3588 dt-bindings: media: rockchip-vpu: Add rk3588 vdpu121 compatible string .../bindings/media/rockchip-vpu.yaml | 3 +++ arch/arm64/boot/dts/rockchip/rk3588s.dtsi | 20 +++++++++++++++++++ 2 files changed, 23 insertions(+) -- 2.34.1 _______________________________________________ Linux-rockchip mailing list Linux-rockchip@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip
From: Ondrej Jirman <megi@xff.cz> - RK3399 has input/output limit of main path 4416 x 3312 - PX30 has input/output limit of main path 3264 x 2448 - i.MX8MP has input/output limit of main path 4096 x 3072 Use rkisp1_info struct to encode the limits. Signed-off-by: Ondrej Jirman <megi@xff.cz> --- v2: - adapt to i.MX8MP merged for v6.9 drivers/media/platform/rockchip/rkisp1/rkisp1-common.h | 6 ++++-- drivers/media/platform/rockchip/rkisp1/rkisp1-csi.c | 5 +++-- drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c | 6 ++++++ drivers/media/platform/rockchip/rkisp1/rkisp1-isp.c | 9 +++++---- drivers/media/platform/rockchip/rkisp1/rkisp1-resizer.c | 4 ++-- 5 files changed, 20 insertions(+), 10 deletions(-) diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-common.h b/drivers/media/platform/rockchip/rkisp1/rkisp1-common.h index 26573f6ae575..b4c958b93629 100644 --- a/drivers/media/platform/rockchip/rkisp1/rkisp1-common.h +++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-common.h @@ -34,8 +34,6 @@ struct regmap; #define RKISP1_ISP_SD_SINK BIT(1) /* min and max values for the widths and heights of the entities */ -#define RKISP1_ISP_MAX_WIDTH 4032 -#define RKISP1_ISP_MAX_HEIGHT 3024 #define RKISP1_ISP_MIN_WIDTH 32 #define RKISP1_ISP_MIN_HEIGHT 32 @@ -140,6 +138,8 @@ enum rkisp1_feature { * @isr_size: number of entries in the @isrs array * @isp_ver: ISP version * @features: bitmask of rkisp1_feature features implemented by the ISP + * @max_width: maximum input frame width + * @max_height: maximum input frame height * * This structure contains information about the ISP specific to a particular * ISP model, version, or integration in a particular SoC. @@ -151,6 +151,8 @@ struct rkisp1_info { unsigned int isr_size; enum rkisp1_cif_isp_version isp_ver; unsigned int features; + unsigned int max_width; + unsigned int max_height; }; /* diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-csi.c b/drivers/media/platform/rockchip/rkisp1/rkisp1-csi.c index 4202642e0523..841e58c20f7f 100644 --- a/drivers/media/platform/rockchip/rkisp1/rkisp1-csi.c +++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-csi.c @@ -307,6 +307,7 @@ static int rkisp1_csi_set_fmt(struct v4l2_subdev *sd, struct v4l2_subdev_state *sd_state, struct v4l2_subdev_format *fmt) { + struct rkisp1_csi *csi = to_rkisp1_csi(sd); const struct rkisp1_mbus_info *mbus_info; struct v4l2_mbus_framefmt *sink_fmt, *src_fmt; @@ -326,10 +327,10 @@ static int rkisp1_csi_set_fmt(struct v4l2_subdev *sd, sink_fmt->width = clamp_t(u32, fmt->format.width, RKISP1_ISP_MIN_WIDTH, - RKISP1_ISP_MAX_WIDTH); + csi->rkisp1->info->max_width); sink_fmt->height = clamp_t(u32, fmt->format.height, RKISP1_ISP_MIN_HEIGHT, - RKISP1_ISP_MAX_HEIGHT); + csi->rkisp1->info->max_height); fmt->format = *sink_fmt; diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c b/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c index bb0202386c70..0535ce57e862 100644 --- a/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c +++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c @@ -510,6 +510,8 @@ static const struct rkisp1_info px30_isp_info = { .features = RKISP1_FEATURE_MIPI_CSI2 | RKISP1_FEATURE_SELF_PATH | RKISP1_FEATURE_DUAL_CROP, + .max_width = 3264, + .max_height = 2448, }; static const char * const rk3399_isp_clks[] = { @@ -531,6 +533,8 @@ static const struct rkisp1_info rk3399_isp_info = { .features = RKISP1_FEATURE_MIPI_CSI2 | RKISP1_FEATURE_SELF_PATH | RKISP1_FEATURE_DUAL_CROP, + .max_width = 4416, + .max_height = 3312, }; static const char * const imx8mp_isp_clks[] = { @@ -551,6 +555,8 @@ static const struct rkisp1_info imx8mp_isp_info = { .isp_ver = RKISP1_V_IMX8MP, .features = RKISP1_FEATURE_MAIN_STRIDE | RKISP1_FEATURE_DMA_34BIT, + .max_width = 4096, + .max_height = 3072, }; static const struct of_device_id rkisp1_of_match[] = { diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-isp.c b/drivers/media/platform/rockchip/rkisp1/rkisp1-isp.c index e45a213baf49..f787a7e91e3e 100644 --- a/drivers/media/platform/rockchip/rkisp1/rkisp1-isp.c +++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-isp.c @@ -517,6 +517,7 @@ static int rkisp1_isp_enum_frame_size(struct v4l2_subdev *sd, struct v4l2_subdev_state *sd_state, struct v4l2_subdev_frame_size_enum *fse) { + struct rkisp1_isp *isp = to_rkisp1_isp(sd); const struct rkisp1_mbus_info *mbus_info; if (fse->pad == RKISP1_ISP_PAD_SINK_PARAMS || @@ -539,9 +540,9 @@ static int rkisp1_isp_enum_frame_size(struct v4l2_subdev *sd, return -EINVAL; fse->min_width = RKISP1_ISP_MIN_WIDTH; - fse->max_width = RKISP1_ISP_MAX_WIDTH; + fse->max_width = isp->rkisp1->info->max_width; fse->min_height = RKISP1_ISP_MIN_HEIGHT; - fse->max_height = RKISP1_ISP_MAX_HEIGHT; + fse->max_height = isp->rkisp1->info->max_height; return 0; } @@ -772,10 +773,10 @@ static void rkisp1_isp_set_sink_fmt(struct rkisp1_isp *isp, sink_fmt->width = clamp_t(u32, format->width, RKISP1_ISP_MIN_WIDTH, - RKISP1_ISP_MAX_WIDTH); + isp->rkisp1->info->max_width); sink_fmt->height = clamp_t(u32, format->height, RKISP1_ISP_MIN_HEIGHT, - RKISP1_ISP_MAX_HEIGHT); + isp->rkisp1->info->max_height); /* * Adjust the color space fields. Accept any color primaries and diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-resizer.c b/drivers/media/platform/rockchip/rkisp1/rkisp1-resizer.c index 6f3931ca5b51..e22cc2db24cf 100644 --- a/drivers/media/platform/rockchip/rkisp1/rkisp1-resizer.c +++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-resizer.c @@ -494,10 +494,10 @@ static void rkisp1_rsz_set_sink_fmt(struct rkisp1_resizer *rsz, sink_fmt->width = clamp_t(u32, format->width, RKISP1_ISP_MIN_WIDTH, - RKISP1_ISP_MAX_WIDTH); + rsz->rkisp1->info->max_width); sink_fmt->height = clamp_t(u32, format->height, RKISP1_ISP_MIN_HEIGHT, - RKISP1_ISP_MAX_HEIGHT); + rsz->rkisp1->info->max_height); /* * Adjust the color space fields. Accept any color primaries and -- 2.44.0 _______________________________________________ Linux-rockchip mailing list Linux-rockchip@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip
Hi David, On Fri, Mar 15, 2024 at 02:33:53PM -0700, David Rientjes wrote: > Joerg, is this series anticipated to be queued up in the core branch of > git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git so it gets into > linux-next? > > This observability seems particularly useful so that we can monitor and > alert on any unexpected increases (unbounded memory growth from this > subsystem has in the past caused us issues before the memory is otherwise > not observable by host software). > > Or are we still waiting on code reviews from some folks that we should > ping? A few more reviews would certainly help, but I will also do a review on my own. If things are looking good I can merge it into the iommu tree when 6.9-rc3 is released (which is the usual time I start merging new stuff). Regards, Joerg _______________________________________________ Linux-rockchip mailing list Linux-rockchip@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip
On Thu, 22 Feb 2024, Pasha Tatashin wrote: > Pasha Tatashin (11): > iommu/vt-d: add wrapper functions for page allocations > iommu/dma: use iommu_put_pages_list() to releae freelist > iommu/amd: use page allocation function provided by iommu-pages.h > iommu/io-pgtable-arm: use page allocation function provided by > iommu-pages.h > iommu/io-pgtable-dart: use page allocation function provided by > iommu-pages.h > iommu/exynos: use page allocation function provided by iommu-pages.h > iommu/rockchip: use page allocation function provided by iommu-pages.h > iommu/sun50i: use page allocation function provided by iommu-pages.h > iommu/tegra-smmu: use page allocation function provided by > iommu-pages.h > iommu: observability of the IOMMU allocations > iommu: account IOMMU allocated memory > > Documentation/admin-guide/cgroup-v2.rst | 2 +- > Documentation/filesystems/proc.rst | 4 +- > drivers/iommu/amd/amd_iommu.h | 8 - > drivers/iommu/amd/init.c | 91 ++++++------ > drivers/iommu/amd/io_pgtable.c | 13 +- > drivers/iommu/amd/io_pgtable_v2.c | 20 +-- > drivers/iommu/amd/iommu.c | 13 +- > drivers/iommu/dma-iommu.c | 7 +- > drivers/iommu/exynos-iommu.c | 14 +- > drivers/iommu/intel/dmar.c | 16 +- > drivers/iommu/intel/iommu.c | 47 ++---- > drivers/iommu/intel/iommu.h | 2 - > drivers/iommu/intel/irq_remapping.c | 16 +- > drivers/iommu/intel/pasid.c | 18 +-- > drivers/iommu/intel/svm.c | 11 +- > drivers/iommu/io-pgtable-arm.c | 15 +- > drivers/iommu/io-pgtable-dart.c | 37 ++--- > drivers/iommu/iommu-pages.h | 186 ++++++++++++++++++++++++ > drivers/iommu/rockchip-iommu.c | 14 +- > drivers/iommu/sun50i-iommu.c | 7 +- > drivers/iommu/tegra-smmu.c | 18 ++- > include/linux/mmzone.h | 5 +- > mm/vmstat.c | 3 + > 23 files changed, 361 insertions(+), 206 deletions(-) > create mode 100644 drivers/iommu/iommu-pages.h > Joerg, is this series anticipated to be queued up in the core branch of git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git so it gets into linux-next? This observability seems particularly useful so that we can monitor and alert on any unexpected increases (unbounded memory growth from this subsystem has in the past caused us issues before the memory is otherwise not observable by host software). Or are we still waiting on code reviews from some folks that we should ping? Thanks! _______________________________________________ Linux-rockchip mailing list Linux-rockchip@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip
On Thu, 22 Feb 2024, Pasha Tatashin wrote: > Free the IOMMU page tables via iommu_put_pages_list(). The page tables > were allocated via iommu_alloc_* functions in architecture specific > places, but are released in dma-iommu if the freelist is gathered during > map/unmap operations into iommu_iotlb_gather data structure. > > Currently, only iommu/intel that does that. > > Signed-off-by: Pasha Tatashin <pasha.tatashin@soleen.com> Acked-by: David Rientjes <rientjes@google.com> _______________________________________________ Linux-rockchip mailing list Linux-rockchip@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip
On 2024-03-15 16:02, Himanshu Bhavani wrote: >> Unfortunately, this isn't an acceptable change to the Rock64 dts file. >> Yes, there's the second built-in Ethernet interface in the RK3328 SoC, >> but the Rock64 layout doesn't expose it as a separate physical network >> interface, i.e. it isn't available as a port. > > I was wondering if the Rock64 lacks a port. > According to this link: https://pine64.org/devices/rock64/, > it seems that there is a physical network interface available on the > sbc. As I already described in my previous response, there's another Ethernet interface in the RK3328 SoC, which the Rock64 is based on, but there's no second Ethernet port on the actual printed circuit board. That's simply how the Rock64 was designed and manufactured. >> Such a change would be fine to be applied to the dts by hand, by >> someone >> who actually adds a second physical network port to their Rock64. _______________________________________________ Linux-rockchip mailing list Linux-rockchip@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip
Hello Simic, >Unfortunately, this isn't an acceptable change to the Rock64 dts file. >Yes, there's the second built-in Ethernet interface in the RK3328 SoC, >but the Rock64 layout doesn't expose it as a separate physical network >interface, i.e. it isn't available as a port. I was wondering if the Rock64 lacks a port. According to this link: https://pine64.org/devices/rock64/, it seems that there is a physical network interface available on the sbc. >Such a change would be fine to be applied to the dts by hand, by someone >who actually adds a second physical network port to their Rock64. _______________________________________________ Linux-rockchip mailing list Linux-rockchip@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip
OK3588-C is the carrier board for FET3588-C System on Module. OK3588-C features: - 2x 1GbE Realtek RTL8211F Ethernet - 1x HDMI Type A out - 1x HDMI Type A in - 3x USB 3.1 Type C (2x OTG and 1x serial console) - 1x USB 2.0 Type A - 1x USB 3.0 & USB 2.0 Combo M.2 M Key (4G/5G modem) - 1x PCIE 2.0 M.2 E Key (1 lane) - 1x PCIE 2.0 PCIe (1 lane) - 1x PCIE 3.0 PCIe (4 lanes) - 1x TF scard slot - 5x MIPI CSI - 2x MIP DSI - 2x CAN2.0B - 1x RS485 - 1x NAU8822 onboard audio - 1x FAN connector - 1x RTC - 20-pin expansion header - ADC keys Add support for Forlinx OK3588-C board. Signed-off-by: Dmitry Yashin <dmt.yashin@gmail.com> --- arch/arm64/boot/dts/rockchip/Makefile | 1 + .../boot/dts/rockchip/rk3588-ok3588-c.dts | 390 ++++++++++++++++++ 2 files changed, 391 insertions(+) create mode 100644 arch/arm64/boot/dts/rockchip/rk3588-ok3588-c.dts diff --git a/arch/arm64/boot/dts/rockchip/Makefile b/arch/arm64/boot/dts/rockchip/Makefile index a7b30e11beaf..39357fb293ad 100644 --- a/arch/arm64/boot/dts/rockchip/Makefile +++ b/arch/arm64/boot/dts/rockchip/Makefile @@ -107,6 +107,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-edgeble-neu6b-io.dtb dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-evb1-v10.dtb dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-jaguar.dtb dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-nanopc-t6.dtb +dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-ok3588-c.dtb dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-orangepi-5-plus.dtb dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-quartzpro64.dtb dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-rock-5b.dtb diff --git a/arch/arm64/boot/dts/rockchip/rk3588-ok3588-c.dts b/arch/arm64/boot/dts/rockchip/rk3588-ok3588-c.dts new file mode 100644 index 000000000000..9977928b7677 --- /dev/null +++ b/arch/arm64/boot/dts/rockchip/rk3588-ok3588-c.dts @@ -0,0 +1,390 @@ +// SPDX-License-Identifier: (GPL-2.0+ OR MIT) + +/dts-v1/; +#include "rk3588-forlinx-fet3588-c.dtsi" + +/ { + model = "Forlinx OK3588-C Board"; + compatible = "forlinx,ok3588-c", "forlinx,fet3588-c", "rockchip,rk3588"; + + aliases { + ethernet0 = &gmac0; + ethernet1 = &gmac1; + mmc1 = &sdmmc; + }; + + adc-keys-0 { + compatible = "adc-keys"; + io-channels = <&saradc 0>; + io-channel-names = "buttons"; + keyup-threshold-microvolt = <1800000>; + poll-interval = <100>; + + button-maskrom { + label = "Maskrom"; + linux,code = <KEY_SETUP>; + press-threshold-microvolt = <400>; + }; + }; + + adc-keys-1 { + compatible = "adc-keys"; + io-channels = <&saradc 1>; + io-channel-names = "buttons"; + keyup-threshold-microvolt = <1800000>; + poll-interval = <100>; + + button-volume-up { + label = "V+/Recovery"; + linux,code = <KEY_VOLUMEUP>; + press-threshold-microvolt = <17000>; + }; + + button-volume-down { + label = "V-"; + linux,code = <KEY_VOLUMEDOWN>; + press-threshold-microvolt = <417000>; + }; + + button-menu { + label = "Menu"; + linux,code = <KEY_MENU>; + press-threshold-microvolt = <890000>; + }; + + button-escape { + label = "ESC"; + linux,code = <KEY_ESC>; + press-threshold-microvolt = <1235000>; + }; + }; + + analog-sound { + compatible = "simple-audio-card"; + pinctrl-names = "default"; + pinctrl-0 = <&hp_detect>; + simple-audio-card,name = "RK3588 OK3588-C Audio"; + simple-audio-card,bitclock-master = <&masterdai>; + simple-audio-card,format = "i2s"; + simple-audio-card,frame-master = <&masterdai>; + simple-audio-card,hp-det-gpio = <&gpio1 RK_PB2 GPIO_ACTIVE_HIGH>; + simple-audio-card,mclk-fs = <256>; + simple-audio-card,pin-switches = "Headphones", "Speaker"; + simple-audio-card,widgets = + "Headphones", "Headphones", + "Speaker", "Speaker", + "Microphone", "Internal Microphone", + "Microphone", "Headset Microphone"; + simple-audio-card,routing = + "Headphones", "LHP", + "Headphones", "RHP", + "Speaker", "LSPK", + "Speaker", "RSPK", + "LMICP", "Headset Microphone", + "RMICP", "Internal Microphone"; + + simple-audio-card,cpu { + sound-dai = <&i2s0_8ch>; + }; + + masterdai: simple-audio-card,codec { + sound-dai = <&nau8822>; + }; + }; + + fan: pwm-fan { + compatible = "pwm-fan"; + cooling-levels = <0 95 145 195 255>; + fan-supply = <&vcc12v_dcin>; + pwms = <&pwm2 0 50000 0>; + #cooling-cells = <2>; + }; + + vcc12v_dcin: vcc12v-dcin-regulator { + compatible = "regulator-fixed"; + regulator-name = "vcc12v_dcin"; + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <12000000>; + regulator-max-microvolt = <12000000>; + }; + + vcc1v8_sys: vcc1v8-sys-regulator { + compatible = "regulator-fixed"; + regulator-name = "vcc1v8_sys"; + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <1800000>; + vin-supply = <&vcc3v3_sys>; + }; + + vcc3v3_sys: vcc3v3-sys-regulator { + compatible = "regulator-fixed"; + regulator-name = "vcc3v3_sys"; + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <3300000>; + regulator-max-microvolt = <3300000>; + vin-supply = <&vcc5v0_sys>; + }; + + vcc3v3_pcie2x1l0: vcc3v3-pcie2x1l0-regulator { + compatible = "regulator-fixed"; + regulator-name = "vcc3v3_pcie2x1l0"; + regulator-min-microvolt = <3300000>; + regulator-max-microvolt = <3300000>; + startup-delay-us = <50000>; + vin-supply = <&vcc5v0_sys>; + }; + + vcc3v3_pcie2x1l2: vcc3v3-pcie2x1l2-regulator { + compatible = "regulator-fixed"; + regulator-name = "vcc3v3_pcie2x1l2"; + regulator-min-microvolt = <3300000>; + regulator-max-microvolt = <3300000>; + startup-delay-us = <5000>; + vin-supply = <&vcc5v0_sys>; + }; + + vcc3v3_pcie30: vcc3v3_pcie30-regulator { + compatible = "regulator-fixed"; + regulator-name = "vcc3v3_pcie30"; + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <3300000>; + regulator-max-microvolt = <3300000>; + vin-supply = <&vcc5v0_sys>; + }; + + vcc5v0_sys: vcc5v0-sys-regulator { + compatible = "regulator-fixed"; + regulator-name = "vcc5v0_sys"; + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <5000000>; + regulator-max-microvolt = <5000000>; + vin-supply = <&vcc12v_dcin>; + }; +}; + +&gmac0 { + clock_in_out = "output"; + phy-handle = <&rgmii_phy0>; + phy-mode = "rgmii-rxid"; + pinctrl-0 = <&gmac0_miim + &gmac0_tx_bus2 + &gmac0_rx_bus2 + &gmac0_rgmii_clk + &gmac0_rgmii_bus>; + pinctrl-names = "default"; + tx_delay = <0x44>; + rx_delay = <0x00>; + status = "okay"; +}; + +&gmac1 { + clock_in_out = "output"; + phy-handle = <&rgmii_phy1>; + phy-mode = "rgmii-rxid"; + pinctrl-0 = <&gmac1_miim + &gmac1_tx_bus2 + &gmac1_rx_bus2 + &gmac1_rgmii_clk + &gmac1_rgmii_bus>; + pinctrl-names = "default"; + tx_delay = <0x44>; + rx_delay = <0x00>; + status = "okay"; +}; + +&i2c2 { + status = "okay"; + + tca6424a: gpio-controller@23 { + compatible = "ti,tca6424"; + reg = <0x23>; + gpio-controller; + #gpio-cells = <2>; + + interrupt-parent = <&gpio1>; + interrupts = <RK_PA4 IRQ_TYPE_EDGE_FALLING>; + interrupt-controller; + #interrupt-cells = <2>; + + pinctrl-names = "default"; + pinctrl-0 = <&tca6424a_int>; + vcc-supply = <&vcc3v3_sys>; + }; +}; + +&i2c5 { + status = "okay"; + pinctrl-names = "default"; + pinctrl-0 = <&i2c5m2_xfer>; + + pcf8563: rtc@51 { + compatible = "nxp,pcf8563"; + reg = <0x51>; + }; +}; + +&i2c7 { + status = "okay"; + + nau8822: nau8822@1a { + compatible = "nuvoton,nau8822"; + reg = <0x1a>; + clocks = <&cru I2S0_8CH_MCLKOUT>; + clock-names = "mclk"; + assigned-clocks = <&cru I2S0_8CH_MCLKOUT>; + assigned-clock-rates = <12288000>; + #sound-dai-cells = <0>; + }; +}; + + +&i2s0_8ch { + pinctrl-names = "default"; + pinctrl-0 = <&i2s0_lrck + &i2s0_mclk + &i2s0_sclk + &i2s0_sdi0 + &i2s0_sdo0>; + status = "okay"; +}; + +&mdio0 { + rgmii_phy0: ethernet-phy@1 { + /* RTL8211F */ + compatible = "ethernet-phy-id001c.c916", + "ethernet-phy-ieee802.3-c22"; + reg = <0x1>; + pinctrl-names = "default"; + pinctrl-0 = <&rtl8211f_0_rst>; + reset-assert-us = <20000>; + reset-deassert-us = <100000>; + reset-gpios = <&gpio0 RK_PB0 GPIO_ACTIVE_LOW>; + }; +}; + +&mdio1 { + rgmii_phy1: ethernet-phy@2 { + /* RTL8211F */ + compatible = "ethernet-phy-id001c.c916", + "ethernet-phy-ieee802.3-c22"; + reg = <0x2>; + pinctrl-names = "default"; + pinctrl-0 = <&rtl8211f_1_rst>; + reset-assert-us = <20000>; + reset-deassert-us = <100000>; + reset-gpios = <&gpio1 RK_PB4 GPIO_ACTIVE_LOW>; + }; +}; + +&pcie2x1l0 { + pinctrl-names = "default"; + pinctrl-0 = <&pcie2_0_rst>; + reset-gpios = <&gpio4 RK_PA5 GPIO_ACTIVE_HIGH>; + vpcie3v3-supply = <&vcc3v3_pcie2x1l0>; + status = "okay"; +}; + +&pcie2x1l2 { + pinctrl-names = "default"; + pinctrl-0 = <&pcie2_2_rst>; + reset-gpios = <&gpio3 RK_PD1 GPIO_ACTIVE_HIGH>; + vpcie3v3-supply = <&vcc3v3_pcie2x1l2>; + status = "okay"; +}; + +&pcie30phy { + status = "okay"; +}; + +&pcie3x4 { + pinctrl-names = "default"; + pinctrl-0 = <&pcie3_rst>; + reset-gpios = <&gpio4 RK_PB6 GPIO_ACTIVE_HIGH>; + vpcie3v3-supply = <&vcc3v3_pcie30>; + status = "okay"; +}; + +&pinctrl { + audio { + hp_detect: hp-detect { + rockchip,pins = <1 RK_PB2 RK_FUNC_GPIO &pcfg_pull_none>; + }; + }; + + rtl8211f { + rtl8211f_0_rst: rtl8211f-0-rst { + rockchip,pins = <0 RK_PB0 RK_FUNC_GPIO &pcfg_pull_none>; + }; + rtl8211f_1_rst: rtl8211f-1-rst { + rockchip,pins = <1 RK_PB4 RK_FUNC_GPIO &pcfg_pull_none>; + }; + }; + + tca6424a { + tca6424a_int: tca6424a-int { + rockchip,pins = <1 RK_PA4 RK_FUNC_GPIO &pcfg_pull_up>; + }; + }; + + pcie2 { + pcie2_0_rst: pcie2-0-rst { + rockchip,pins = <4 RK_PA5 RK_FUNC_GPIO &pcfg_pull_none>; + }; + + pcie2_2_rst: pcie2-2-rst { + rockchip,pins = <3 RK_PD1 RK_FUNC_GPIO &pcfg_pull_none>; + }; + }; + + pcie3 { + pcie3_rst: pcie3-rst { + rockchip,pins = <4 RK_PB6 RK_FUNC_GPIO &pcfg_pull_none>; + }; + }; +}; + +&pwm2 { + status = "okay"; +}; + +&saradc { + vref-supply = <&avcc_1v8_s0>; + status = "okay"; +}; + +&sdmmc { + max-frequency = <200000000>; + no-sdio; + no-mmc; + bus-width = <4>; + cap-mmc-highspeed; + cap-sd-highspeed; + cd-gpios = <&gpio0 RK_PA4 GPIO_ACTIVE_LOW>; + disable-wp; + sd-uhs-sdr104; + vmmc-supply = <&vcc_3v3_s3>; + vqmmc-supply = <&vccio_sd_s0>; + status = "okay"; +}; + +&u2phy2 { + status = "okay"; +}; + +&u2phy2_host { + status = "okay"; +}; + +&u2phy3 { + status = "okay"; +}; + +&u2phy3_host { + status = "okay"; +}; -- 2.44.0 _______________________________________________ Linux-rockchip mailing list Linux-rockchip@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip
FET3588-C is an System on Module made by Forlinx based on Rockchip RK3588. This SoM used by OK3588-C Board. FET3588-C features: - Rockchip RK3588 - LPDDR4 4/8 GB - eMMC 32/64 GB Add support for Forlinx FET3588-C SoM. Signed-off-by: Dmitry Yashin <dmt.yashin@gmail.com> --- .../rockchip/rk3588-forlinx-fet3588-c.dtsi | 556 ++++++++++++++++++ 1 file changed, 556 insertions(+) create mode 100644 arch/arm64/boot/dts/rockchip/rk3588-forlinx-fet3588-c.dtsi diff --git a/arch/arm64/boot/dts/rockchip/rk3588-forlinx-fet3588-c.dtsi b/arch/arm64/boot/dts/rockchip/rk3588-forlinx-fet3588-c.dtsi new file mode 100644 index 000000000000..487427d18d93 --- /dev/null +++ b/arch/arm64/boot/dts/rockchip/rk3588-forlinx-fet3588-c.dtsi @@ -0,0 +1,556 @@ +// SPDX-License-Identifier: (GPL-2.0+ OR MIT) + +#include <dt-bindings/gpio/gpio.h> +#include <dt-bindings/input/input.h> +#include <dt-bindings/leds/common.h> +#include "rk3588.dtsi" + +/ { + compatible = "forlinx,fet3588-c", "rockchip,rk3588"; + + aliases { + mmc0 = &sdhci; + }; + + chosen { + stdout-path = "serial2:1500000n8"; + }; + + leds { + compatible = "gpio-leds"; + pinctrl-names = "default"; + pinctrl-0 = <&led_rgb_b>; + + io-led { + function = LED_FUNCTION_STATUS; + color = <LED_COLOR_ID_BLUE>; + gpios = <&gpio0 RK_PA0 GPIO_ACTIVE_HIGH>; + linux,default-trigger = "heartbeat"; + }; + }; + + pcie20_avdd0v85: pcie20-avdd0v85-regulator { + compatible = "regulator-fixed"; + regulator-name = "pcie20_avdd0v85"; + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <850000>; + regulator-max-microvolt = <850000>; + vin-supply = <&vdd_0v85_s0>; + }; + + pcie20_avdd1v8: pcie20-avdd1v8-regulator { + compatible = "regulator-fixed"; + regulator-name = "pcie20_avdd1v8"; + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <1800000>; + vin-supply = <&avcc_1v8_s0>; + }; + + pcie30_avdd1v8: pcie30-avdd1v8-regulator { + compatible = "regulator-fixed"; + regulator-name = "pcie30_avdd1v8"; + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <1800000>; + vin-supply = <&avcc_1v8_s0>; + }; + + pcie30_avdd0v75: pcie30-avdd0v75-regulator { + compatible = "regulator-fixed"; + regulator-name = "pcie30_avdd0v75"; + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <750000>; + regulator-max-microvolt = <750000>; + vin-supply = <&avdd_0v75_s0>; + }; + + vcc4v0_sys: vcc4v0-sys-regulator { + compatible = "regulator-fixed"; + regulator-name = "vcc4v0_sys"; + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <4000000>; + regulator-max-microvolt = <4000000>; + vin-supply = <&vcc12v_dcin>; + }; + + vcc_1v1_nldo_s3: vcc-1v1-nldo-s3-regulator { + compatible = "regulator-fixed"; + regulator-name = "vcc_1v1_nldo_s3"; + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <1100000>; + regulator-max-microvolt = <1100000>; + vin-supply = <&vcc5v0_sys>; + }; + +}; + +&combphy0_ps { + status = "okay"; +}; + +&combphy1_ps { + status = "okay"; +}; + +&combphy2_psu { + status = "okay"; +}; + +&cpu_b0 { + cpu-supply = <&vdd_cpu_big0_s0>; + mem-supply = <&vdd_cpu_big0_s0>; +}; + +&cpu_b1 { + cpu-supply = <&vdd_cpu_big0_s0>; + mem-supply = <&vdd_cpu_big0_s0>; +}; + +&cpu_b2 { + cpu-supply = <&vdd_cpu_big1_s0>; + mem-supply = <&vdd_cpu_big1_s0>; +}; + +&cpu_b3 { + cpu-supply = <&vdd_cpu_big1_s0>; + mem-supply = <&vdd_cpu_big1_s0>; +}; + +&cpu_l0 { + cpu-supply = <&vdd_cpu_lit_s0>; + mem-supply = <&vdd_cpu_lit_mem_s0>; +}; + +&cpu_l1 { + cpu-supply = <&vdd_cpu_lit_s0>; + mem-supply = <&vdd_cpu_lit_mem_s0>; +}; + +&cpu_l2 { + cpu-supply = <&vdd_cpu_lit_s0>; + mem-supply = <&vdd_cpu_lit_mem_s0>; +}; + +&cpu_l3 { + cpu-supply = <&vdd_cpu_lit_s0>; + mem-supply = <&vdd_cpu_lit_mem_s0>; +}; + +&i2c0 { + pinctrl-names = "default"; + pinctrl-0 = <&i2c0m2_xfer>; + status = "okay"; + + vdd_cpu_big0_s0: regulator@42 { + compatible = "rockchip,rk8602"; + reg = <0x42>; + fcs,suspend-voltage-selector = <1>; + regulator-name = "vdd_cpu_big0_s0"; + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <550000>; + regulator-max-microvolt = <1050000>; + regulator-ramp-delay = <2300>; + vin-supply = <&vcc4v0_sys>; + + regulator-state-mem { + regulator-off-in-suspend; + }; + }; + + vdd_cpu_big1_s0: regulator@43 { + compatible = "rockchip,rk8603", "rockchip,rk8602"; + reg = <0x43>; + fcs,suspend-voltage-selector = <1>; + regulator-name = "vdd_cpu_big1_s0"; + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <550000>; + regulator-max-microvolt = <1050000>; + regulator-ramp-delay = <2300>; + vin-supply = <&vcc4v0_sys>; + + regulator-state-mem { + regulator-off-in-suspend; + }; + }; +}; + +&i2c1 { + status = "okay"; + pinctrl-names = "default"; + pinctrl-0 = <&i2c1m2_xfer>; + + vdd_npu_s0: regulator@42 { + compatible = "rockchip,rk8602"; + reg = <0x42>; + fcs,suspend-voltage-selector = <1>; + regulator-name = "vdd_npu_s0"; + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <550000>; + regulator-max-microvolt = <950000>; + regulator-ramp-delay = <2300>; + vin-supply = <&vcc4v0_sys>; + + regulator-state-mem { + regulator-off-in-suspend; + }; + }; +}; + +&pinctrl { + leds { + led_rgb_b: led-rgb-b { + rockchip,pins = <0 RK_PA0 RK_FUNC_GPIO &pcfg_pull_none>; + }; + }; +}; + +&sdhci { + bus-width = <8>; + no-sdio; + no-sd; + non-removable; + mmc-hs400-1_8v; + mmc-hs400-enhanced-strobe; + status = "okay"; +}; + +&spi2 { + status = "okay"; + assigned-clocks = <&cru CLK_SPI2>; + assigned-clock-rates = <200000000>; + pinctrl-names = "default"; + pinctrl-0 = <&spi2m2_cs0 &spi2m2_pins>; + num-cs = <1>; + + pmic@0 { + compatible = "rockchip,rk806"; + spi-max-frequency = <1000000>; + reg = <0x0>; + + interrupt-parent = <&gpio0>; + interrupts = <7 IRQ_TYPE_LEVEL_LOW>; + + pinctrl-names = "default"; + pinctrl-0 = <&pmic_pins>, <&rk806_dvs1_null>, + <&rk806_dvs2_null>, <&rk806_dvs3_null>; + + system-power-controller; + + vcc1-supply = <&vcc5v0_sys>; + vcc2-supply = <&vcc5v0_sys>; + vcc3-supply = <&vcc5v0_sys>; + vcc4-supply = <&vcc5v0_sys>; + vcc5-supply = <&vcc5v0_sys>; + vcc6-supply = <&vcc5v0_sys>; + vcc7-supply = <&vcc5v0_sys>; + vcc8-supply = <&vcc5v0_sys>; + vcc9-supply = <&vcc5v0_sys>; + vcc10-supply = <&vcc5v0_sys>; + vcc11-supply = <&vcc_2v0_pldo_s3>; + vcc12-supply = <&vcc5v0_sys>; + vcc13-supply = <&vcc_1v1_nldo_s3>; + vcc14-supply = <&vcc_1v1_nldo_s3>; + vcca-supply = <&vcc5v0_sys>; + + gpio-controller; + #gpio-cells = <2>; + + rk806_dvs1_null: dvs1-null-pins { + pins = "gpio_pwrctrl1"; + function = "pin_fun0"; + }; + + rk806_dvs2_null: dvs2-null-pins { + pins = "gpio_pwrctrl2"; + function = "pin_fun0"; + }; + + rk806_dvs3_null: dvs3-null-pins { + pins = "gpio_pwrctrl3"; + function = "pin_fun0"; + }; + + regulators { + vdd_gpu_s0: vdd_gpu_mem_s0: dcdc-reg1 { + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <550000>; + regulator-max-microvolt = <950000>; + regulator-ramp-delay = <12500>; + regulator-name = "vdd_gpu_s0"; + regulator-enable-ramp-delay = <400>; + + regulator-state-mem { + regulator-off-in-suspend; + }; + }; + + vdd_cpu_lit_s0: vdd_cpu_lit_mem_s0: dcdc-reg2 { + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <550000>; + regulator-max-microvolt = <950000>; + regulator-ramp-delay = <12500>; + regulator-name = "vdd_cpu_lit_s0"; + + regulator-state-mem { + regulator-off-in-suspend; + }; + }; + + vdd_log_s0: dcdc-reg3 { + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <675000>; + regulator-max-microvolt = <750000>; + regulator-ramp-delay = <12500>; + regulator-name = "vdd_log_s0"; + + regulator-state-mem { + regulator-off-in-suspend; + regulator-suspend-microvolt = <750000>; + }; + }; + + vdd_vdenc_s0: vdd_vdenc_mem_s0: dcdc-reg4 { + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <550000>; + regulator-max-microvolt = <950000>; + regulator-ramp-delay = <12500>; + regulator-name = "vdd_vdenc_s0"; + + regulator-state-mem { + regulator-off-in-suspend; + }; + }; + + vdd_ddr_s0: dcdc-reg5 { + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <675000>; + regulator-max-microvolt = <900000>; + regulator-ramp-delay = <12500>; + regulator-name = "vdd_ddr_s0"; + + regulator-state-mem { + regulator-off-in-suspend; + regulator-suspend-microvolt = <850000>; + }; + }; + + vdd2_ddr_s3: dcdc-reg6 { + regulator-always-on; + regulator-boot-on; + regulator-name = "vdd2_ddr_s3"; + + regulator-state-mem { + regulator-on-in-suspend; + }; + }; + + vcc_2v0_pldo_s3: dcdc-reg7 { + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <2000000>; + regulator-max-microvolt = <2000000>; + regulator-ramp-delay = <12500>; + regulator-name = "vdd_2v0_pldo_s3"; + + regulator-state-mem { + regulator-on-in-suspend; + regulator-suspend-microvolt = <2000000>; + }; + }; + + vcc_3v3_s3: dcdc-reg8 { + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <3300000>; + regulator-max-microvolt = <3300000>; + regulator-name = "vcc_3v3_s3"; + + regulator-state-mem { + regulator-on-in-suspend; + regulator-suspend-microvolt = <3300000>; + }; + }; + + vddq_ddr_s0: dcdc-reg9 { + regulator-always-on; + regulator-boot-on; + regulator-name = "vddq_ddr_s0"; + + regulator-state-mem { + regulator-off-in-suspend; + }; + }; + + vcc_1v8_s3: dcdc-reg10 { + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <1800000>; + regulator-name = "vcc_1v8_s3"; + + regulator-state-mem { + regulator-on-in-suspend; + regulator-suspend-microvolt = <1800000>; + }; + }; + + avcc_1v8_s0: pldo-reg1 { + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <1800000>; + regulator-name = "avcc_1v8_s0"; + + regulator-state-mem { + regulator-off-in-suspend; + }; + }; + + vcc_1v8_s0: pldo-reg2 { + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <1800000>; + regulator-name = "vcc_1v8_s0"; + + regulator-state-mem { + regulator-off-in-suspend; + regulator-suspend-microvolt = <1800000>; + }; + }; + + avdd_1v2_s0: pldo-reg3 { + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <1200000>; + regulator-max-microvolt = <1200000>; + regulator-name = "avdd_1v2_s0"; + + regulator-state-mem { + regulator-off-in-suspend; + }; + }; + + vcc_3v3_s0: pldo-reg4 { + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <3300000>; + regulator-max-microvolt = <3300000>; + regulator-ramp-delay = <12500>; + regulator-name = "vcc_3v3_s0"; + + regulator-state-mem { + regulator-off-in-suspend; + }; + }; + + vccio_sd_s0: pldo-reg5 { + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <3300000>; + regulator-ramp-delay = <12500>; + regulator-name = "vccio_sd_s0"; + + regulator-state-mem { + regulator-off-in-suspend; + }; + }; + + pldo6_s3: pldo-reg6 { + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <1800000>; + regulator-name = "pldo6_s3"; + + regulator-state-mem { + regulator-on-in-suspend; + regulator-suspend-microvolt = <1800000>; + }; + }; + + vdd_0v75_s3: nldo-reg1 { + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <750000>; + regulator-max-microvolt = <750000>; + regulator-name = "vdd_0v75_s3"; + + regulator-state-mem { + regulator-on-in-suspend; + regulator-suspend-microvolt = <750000>; + }; + }; + + vdd_ddr_pll_s0: nldo-reg2 { + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <850000>; + regulator-max-microvolt = <850000>; + regulator-name = "vdd_ddr_pll_s0"; + + regulator-state-mem { + regulator-off-in-suspend; + regulator-suspend-microvolt = <850000>; + }; + }; + + avdd_0v75_s0: nldo-reg3 { + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <750000>; + regulator-max-microvolt = <750000>; + regulator-name = "avdd_0v75_s0"; + + regulator-state-mem { + regulator-off-in-suspend; + }; + }; + + vdd_0v85_s0: nldo-reg4 { + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <850000>; + regulator-max-microvolt = <850000>; + regulator-name = "vdd_0v85_s0"; + + regulator-state-mem { + regulator-off-in-suspend; + }; + }; + + vdd_0v75_s0: nldo-reg5 { + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <750000>; + regulator-max-microvolt = <750000>; + regulator-name = "vdd_0v75_s0"; + + regulator-state-mem { + regulator-off-in-suspend; + }; + }; + }; + }; +}; + +&uart2 { + pinctrl-0 = <&uart2m0_xfer>; + status = "okay"; +}; -- 2.44.0 _______________________________________________ Linux-rockchip mailing list Linux-rockchip@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip
FET3588-C is an System on Module made by Forlinx based on Rockchip RK3588. This SoM used by OK3588-C Board. FET3588-C features: - Rockchip RK3588 - LPDDR4 4/8 GB - eMMC 32/64 GB Add devicetree binding for Forlinx FET3588-C SoM. Signed-off-by: Dmitry Yashin <dmt.yashin@gmail.com> --- Documentation/devicetree/bindings/arm/rockchip.yaml | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml index 5cf5cbef2cf5..d87f4955f509 100644 --- a/Documentation/devicetree/bindings/arm/rockchip.yaml +++ b/Documentation/devicetree/bindings/arm/rockchip.yaml @@ -211,6 +211,13 @@ properties: - const: firefly,rk3568-roc-pc - const: rockchip,rk3568 + - description: Forlinx FET3588-C SoM + items: + - enum: + - forlinx,ok3588-c + - const: forlinx,fet3588-c + - const: rockchip,rk3588 + - description: FriendlyElec NanoPi R2 series boards items: - enum: -- 2.44.0 _______________________________________________ Linux-rockchip mailing list Linux-rockchip@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip
This series add support for Forlinx RK3588 based SoM and carrier board. Devicetree split into .dtsi (FET3588-C SoM) and .dts (OK3588-C Board). Dmitry Yashin (3): dt-bindings: arm: rockchip: add Forlinx FET3588-C arm64: dts: rockchip: add Forlinx FET3588-C arm64: dts: rockchip: add Forlinx OK3588-C .../devicetree/bindings/arm/rockchip.yaml | 7 + arch/arm64/boot/dts/rockchip/Makefile | 1 + .../rockchip/rk3588-forlinx-fet3588-c.dtsi | 556 ++++++++++++++++++ .../boot/dts/rockchip/rk3588-ok3588-c.dts | 390 ++++++++++++ 4 files changed, 954 insertions(+) create mode 100644 arch/arm64/boot/dts/rockchip/rk3588-forlinx-fet3588-c.dtsi create mode 100644 arch/arm64/boot/dts/rockchip/rk3588-ok3588-c.dts -- 2.44.0 _______________________________________________ Linux-rockchip mailing list Linux-rockchip@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip