* [PATCH v10 03/27] drm/connector: hdmi: Create an HDMI sub-state
From: Maxime Ripard @ 2024-03-21 15:28 UTC (permalink / raw)
To: Maarten Lankhorst, Thomas Zimmermann, David Airlie, Daniel Vetter,
Jonathan Corbet, Sandy Huang, Heiko Stübner, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland
Cc: Hans Verkuil, Sebastian Wick, Ville Syrjälä, dri-devel,
linux-arm-kernel, linux-doc, linux-kernel, linux-media,
linux-rockchip, linux-sunxi, Maxime Ripard, Dave Stevenson
In-Reply-To: <20240321-kms-hdmi-connector-state-v10-0-e6c178361898@kernel.org>
The next features we will need to share across drivers will need to
store some parameters for drivers to use, such as the selected output
format.
Let's create a new connector sub-state dedicated to HDMI controllers,
that will eventually store everything we need.
Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Signed-off-by: Maxime Ripard <mripard@kernel.org>
---
drivers/gpu/drm/drm_atomic_state_helper.c | 35 +++++++++++++++++++++++++++++++
include/drm/drm_atomic_state_helper.h | 4 ++++
include/drm/drm_connector.h | 7 +++++++
3 files changed, 46 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c b/drivers/gpu/drm/drm_atomic_state_helper.c
index 519228eb1095..8f459aaa8ef4 100644
--- a/drivers/gpu/drm/drm_atomic_state_helper.c
+++ b/drivers/gpu/drm/drm_atomic_state_helper.c
@@ -569,10 +569,26 @@ void drm_atomic_helper_connector_tv_reset(struct drm_connector *connector)
drm_atomic_helper_connector_tv_margins_reset(connector);
}
EXPORT_SYMBOL(drm_atomic_helper_connector_tv_reset);
+/**
+ * __drm_atomic_helper_connector_hdmi_reset() - Initializes all HDMI @drm_connector_state resources
+ * @connector: DRM connector
+ * @new_conn_state: connector state to reset
+ *
+ * Initializes all HDMI resources from a @drm_connector_state without
+ * actually allocating it. This is useful for HDMI drivers, in
+ * combination with __drm_atomic_helper_connector_reset() or
+ * drm_atomic_helper_connector_reset().
+ */
+void __drm_atomic_helper_connector_hdmi_reset(struct drm_connector *connector,
+ struct drm_connector_state *new_conn_state)
+{
+}
+EXPORT_SYMBOL(__drm_atomic_helper_connector_hdmi_reset);
+
/**
* drm_atomic_helper_connector_tv_check - Validate an analog TV connector state
* @connector: DRM Connector
* @state: the DRM State object
*
@@ -618,10 +634,29 @@ int drm_atomic_helper_connector_tv_check(struct drm_connector *connector,
return 0;
}
EXPORT_SYMBOL(drm_atomic_helper_connector_tv_check);
+/**
+ * drm_atomic_helper_connector_hdmi_check() - Helper to check HDMI connector atomic state
+ * @connector: DRM Connector
+ * @state: the DRM State object
+ *
+ * Provides a default connector state check handler for HDMI connectors.
+ * Checks that a desired connector update is valid, and updates various
+ * fields of derived state.
+ *
+ * RETURNS:
+ * Zero on success, or an errno code otherwise.
+ */
+int drm_atomic_helper_connector_hdmi_check(struct drm_connector *connector,
+ struct drm_atomic_state *state)
+{
+ return 0;
+}
+EXPORT_SYMBOL(drm_atomic_helper_connector_hdmi_check);
+
/**
* __drm_atomic_helper_connector_duplicate_state - copy atomic connector state
* @connector: connector object
* @state: atomic connector state
*
diff --git a/include/drm/drm_atomic_state_helper.h b/include/drm/drm_atomic_state_helper.h
index b9740edb2658..b8bdd366104d 100644
--- a/include/drm/drm_atomic_state_helper.h
+++ b/include/drm/drm_atomic_state_helper.h
@@ -69,11 +69,15 @@ void drm_atomic_helper_plane_destroy_state(struct drm_plane *plane,
void __drm_atomic_helper_connector_state_reset(struct drm_connector_state *conn_state,
struct drm_connector *connector);
void __drm_atomic_helper_connector_reset(struct drm_connector *connector,
struct drm_connector_state *conn_state);
void drm_atomic_helper_connector_reset(struct drm_connector *connector);
+void __drm_atomic_helper_connector_hdmi_reset(struct drm_connector *connector,
+ struct drm_connector_state *new_conn_state);
void drm_atomic_helper_connector_tv_reset(struct drm_connector *connector);
+int drm_atomic_helper_connector_hdmi_check(struct drm_connector *connector,
+ struct drm_atomic_state *state);
int drm_atomic_helper_connector_tv_check(struct drm_connector *connector,
struct drm_atomic_state *state);
void drm_atomic_helper_connector_tv_margins_reset(struct drm_connector *connector);
void
__drm_atomic_helper_connector_duplicate_state(struct drm_connector *connector,
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 4491c4c2fb6e..000a2a156619 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -1029,10 +1029,17 @@ struct drm_connector_state {
/**
* @hdr_output_metadata:
* DRM blob property for HDR output metadata
*/
struct drm_property_blob *hdr_output_metadata;
+
+ /**
+ * @hdmi: HDMI-related variable and properties. Filled by
+ * @drm_atomic_helper_connector_hdmi_check().
+ */
+ struct {
+ } hdmi;
};
/**
* struct drm_connector_funcs - control connectors on a given device
*
--
2.44.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v10 01/27] drm/connector: Introduce an HDMI connector initialization function
From: Maxime Ripard @ 2024-03-21 15:28 UTC (permalink / raw)
To: Maarten Lankhorst, Thomas Zimmermann, David Airlie, Daniel Vetter,
Jonathan Corbet, Sandy Huang, Heiko Stübner, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland
Cc: Hans Verkuil, Sebastian Wick, Ville Syrjälä, dri-devel,
linux-arm-kernel, linux-doc, linux-kernel, linux-media,
linux-rockchip, linux-sunxi, Maxime Ripard, Dave Stevenson,
Sui Jingfeng
In-Reply-To: <20240321-kms-hdmi-connector-state-v10-0-e6c178361898@kernel.org>
A lot of the various HDMI drivers duplicate some logic that depends on
the HDMI spec itself and not really a particular hardware
implementation.
Output BPC or format selection, infoframe generation are good examples
of such areas.
This creates a lot of boilerplate, with a lot of variations, which makes
it hard for userspace to rely on, and makes it difficult to get it right
for drivers.
In the next patches, we'll add a lot of infrastructure around the
drm_connector and drm_connector_state structures, which will allow to
abstract away the duplicated logic. This infrastructure comes with a few
requirements though, and thus we need a new initialization function.
Hopefully, this will make drivers simpler to handle, and their behaviour
more consistent.
Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Reviewed-by: Sui Jingfeng <sui.jingfeng@linux.dev>
Signed-off-by: Maxime Ripard <mripard@kernel.org>
---
drivers/gpu/drm/drm_connector.c | 39 +++++++++++++++++++++++++++++++++++++++
include/drm/drm_connector.h | 5 +++++
2 files changed, 44 insertions(+)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index b0516505f7ae..d9961cce8245 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -450,10 +450,49 @@ int drmm_connector_init(struct drm_device *dev,
return 0;
}
EXPORT_SYMBOL(drmm_connector_init);
+/**
+ * drmm_connector_hdmi_init - Init a preallocated HDMI connector
+ * @dev: DRM device
+ * @connector: A pointer to the HDMI connector to init
+ * @funcs: callbacks for this connector
+ * @connector_type: user visible type of the connector
+ * @ddc: optional pointer to the associated ddc adapter
+ *
+ * Initialises a preallocated HDMI connector. Connectors can be
+ * subclassed as part of driver connector objects.
+ *
+ * Cleanup is automatically handled with a call to
+ * drm_connector_cleanup() in a DRM-managed action.
+ *
+ * The connector structure should be allocated with drmm_kzalloc().
+ *
+ * Returns:
+ * Zero on success, error code on failure.
+ */
+int drmm_connector_hdmi_init(struct drm_device *dev,
+ struct drm_connector *connector,
+ const struct drm_connector_funcs *funcs,
+ int connector_type,
+ struct i2c_adapter *ddc)
+{
+ int ret;
+
+ if (!(connector_type == DRM_MODE_CONNECTOR_HDMIA ||
+ connector_type == DRM_MODE_CONNECTOR_HDMIB))
+ return -EINVAL;
+
+ ret = drmm_connector_init(dev, connector, funcs, connector_type, ddc);
+ if (ret)
+ return ret;
+
+ return 0;
+}
+EXPORT_SYMBOL(drmm_connector_hdmi_init);
+
/**
* drm_connector_attach_edid_property - attach edid property.
* @connector: the connector
*
* Some connector types like DRM_MODE_CONNECTOR_VIRTUAL do not get a
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index fe88d7fc6b8f..4491c4c2fb6e 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -1902,10 +1902,15 @@ int drm_connector_init_with_ddc(struct drm_device *dev,
int drmm_connector_init(struct drm_device *dev,
struct drm_connector *connector,
const struct drm_connector_funcs *funcs,
int connector_type,
struct i2c_adapter *ddc);
+int drmm_connector_hdmi_init(struct drm_device *dev,
+ struct drm_connector *connector,
+ const struct drm_connector_funcs *funcs,
+ int connector_type,
+ struct i2c_adapter *ddc);
void drm_connector_attach_edid_property(struct drm_connector *connector);
int drm_connector_register(struct drm_connector *connector);
void drm_connector_unregister(struct drm_connector *connector);
int drm_connector_attach_encoder(struct drm_connector *connector,
struct drm_encoder *encoder);
--
2.44.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v10 02/27] drm/tests: connector: Add tests for drmm_connector_hdmi_init
From: Maxime Ripard @ 2024-03-21 15:28 UTC (permalink / raw)
To: Maarten Lankhorst, Thomas Zimmermann, David Airlie, Daniel Vetter,
Jonathan Corbet, Sandy Huang, Heiko Stübner, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland
Cc: Hans Verkuil, Sebastian Wick, Ville Syrjälä, dri-devel,
linux-arm-kernel, linux-doc, linux-kernel, linux-media,
linux-rockchip, linux-sunxi, Maxime Ripard, Dave Stevenson
In-Reply-To: <20240321-kms-hdmi-connector-state-v10-0-e6c178361898@kernel.org>
We just introduced a new initialization function for our connectors, so
let's build a kunit test suite for it as well.
Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Signed-off-by: Maxime Ripard <mripard@kernel.org>
---
drivers/gpu/drm/tests/drm_connector_test.c | 123 +++++++++++++++++++++++++++++
1 file changed, 123 insertions(+)
diff --git a/drivers/gpu/drm/tests/drm_connector_test.c b/drivers/gpu/drm/tests/drm_connector_test.c
index 44f82ed2a958..261d4109946d 100644
--- a/drivers/gpu/drm/tests/drm_connector_test.c
+++ b/drivers/gpu/drm/tests/drm_connector_test.c
@@ -170,10 +170,132 @@ static struct kunit_suite drmm_connector_init_test_suite = {
.name = "drmm_connector_init",
.init = drm_test_connector_init,
.test_cases = drmm_connector_init_tests,
};
+/*
+ * Test that the registration of a bog standard connector works as
+ * expected and doesn't report any error.
+ */
+static void drm_test_connector_hdmi_init_valid(struct kunit *test)
+{
+ struct drm_connector_init_priv *priv = test->priv;
+ int ret;
+
+ ret = drmm_connector_hdmi_init(&priv->drm, &priv->connector,
+ &dummy_funcs,
+ DRM_MODE_CONNECTOR_HDMIA,
+ &priv->ddc);
+ KUNIT_EXPECT_EQ(test, ret, 0);
+}
+
+/*
+ * Test that the registration of a connector without a DDC adapter
+ * doesn't report any error.
+ */
+static void drm_test_connector_hdmi_init_null_ddc(struct kunit *test)
+{
+ struct drm_connector_init_priv *priv = test->priv;
+ int ret;
+
+ ret = drmm_connector_hdmi_init(&priv->drm, &priv->connector,
+ &dummy_funcs,
+ DRM_MODE_CONNECTOR_HDMIA,
+ NULL);
+ KUNIT_EXPECT_EQ(test, ret, 0);
+}
+
+/*
+ * Test that the registration of an HDMI connector with an HDMI
+ * connector type succeeds.
+ */
+static void drm_test_connector_hdmi_init_type_valid(struct kunit *test)
+{
+ struct drm_connector_init_priv *priv = test->priv;
+ unsigned int connector_type = *(unsigned int *)test->param_value;
+ int ret;
+
+ ret = drmm_connector_hdmi_init(&priv->drm, &priv->connector,
+ &dummy_funcs,
+ connector_type,
+ &priv->ddc);
+ KUNIT_EXPECT_EQ(test, ret, 0);
+}
+
+static const unsigned int drm_connector_hdmi_init_type_valid_tests[] = {
+ DRM_MODE_CONNECTOR_HDMIA,
+ DRM_MODE_CONNECTOR_HDMIB,
+};
+
+static void drm_connector_hdmi_init_type_desc(const unsigned int *type, char *desc)
+{
+ sprintf(desc, "%s", drm_get_connector_type_name(*type));
+}
+
+KUNIT_ARRAY_PARAM(drm_connector_hdmi_init_type_valid,
+ drm_connector_hdmi_init_type_valid_tests,
+ drm_connector_hdmi_init_type_desc);
+
+/*
+ * Test that the registration of an HDMI connector with an !HDMI
+ * connector type fails.
+ */
+static void drm_test_connector_hdmi_init_type_invalid(struct kunit *test)
+{
+ struct drm_connector_init_priv *priv = test->priv;
+ unsigned int connector_type = *(unsigned int *)test->param_value;
+ int ret;
+
+ ret = drmm_connector_hdmi_init(&priv->drm, &priv->connector,
+ &dummy_funcs,
+ connector_type,
+ &priv->ddc);
+ KUNIT_EXPECT_LT(test, ret, 0);
+}
+
+static const unsigned int drm_connector_hdmi_init_type_invalid_tests[] = {
+ DRM_MODE_CONNECTOR_Unknown,
+ DRM_MODE_CONNECTOR_VGA,
+ DRM_MODE_CONNECTOR_DVII,
+ DRM_MODE_CONNECTOR_DVID,
+ DRM_MODE_CONNECTOR_DVIA,
+ DRM_MODE_CONNECTOR_Composite,
+ DRM_MODE_CONNECTOR_SVIDEO,
+ DRM_MODE_CONNECTOR_LVDS,
+ DRM_MODE_CONNECTOR_Component,
+ DRM_MODE_CONNECTOR_9PinDIN,
+ DRM_MODE_CONNECTOR_DisplayPort,
+ DRM_MODE_CONNECTOR_TV,
+ DRM_MODE_CONNECTOR_eDP,
+ DRM_MODE_CONNECTOR_VIRTUAL,
+ DRM_MODE_CONNECTOR_DSI,
+ DRM_MODE_CONNECTOR_DPI,
+ DRM_MODE_CONNECTOR_WRITEBACK,
+ DRM_MODE_CONNECTOR_SPI,
+ DRM_MODE_CONNECTOR_USB,
+};
+
+KUNIT_ARRAY_PARAM(drm_connector_hdmi_init_type_invalid,
+ drm_connector_hdmi_init_type_invalid_tests,
+ drm_connector_hdmi_init_type_desc);
+
+static struct kunit_case drmm_connector_hdmi_init_tests[] = {
+ KUNIT_CASE(drm_test_connector_hdmi_init_valid),
+ KUNIT_CASE(drm_test_connector_hdmi_init_null_ddc),
+ KUNIT_CASE_PARAM(drm_test_connector_hdmi_init_type_valid,
+ drm_connector_hdmi_init_type_valid_gen_params),
+ KUNIT_CASE_PARAM(drm_test_connector_hdmi_init_type_invalid,
+ drm_connector_hdmi_init_type_invalid_gen_params),
+ { }
+};
+
+static struct kunit_suite drmm_connector_hdmi_init_test_suite = {
+ .name = "drmm_connector_hdmi_init",
+ .init = drm_test_connector_init,
+ .test_cases = drmm_connector_hdmi_init_tests,
+};
+
struct drm_get_tv_mode_from_name_test {
const char *name;
enum drm_connector_tv_mode expected_mode;
};
@@ -234,10 +356,11 @@ static struct kunit_suite drm_get_tv_mode_from_name_test_suite = {
.name = "drm_get_tv_mode_from_name",
.test_cases = drm_get_tv_mode_from_name_tests,
};
kunit_test_suites(
+ &drmm_connector_hdmi_init_test_suite,
&drmm_connector_init_test_suite,
&drm_get_tv_mode_from_name_test_suite
);
MODULE_AUTHOR("Maxime Ripard <maxime@cerno.tech>");
--
2.44.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v10 00/27] drm/connector: Create HDMI Connector infrastructure
From: Maxime Ripard @ 2024-03-21 15:28 UTC (permalink / raw)
To: Maarten Lankhorst, Thomas Zimmermann, David Airlie, Daniel Vetter,
Jonathan Corbet, Sandy Huang, Heiko Stübner, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland
Cc: Hans Verkuil, Sebastian Wick, Ville Syrjälä, dri-devel,
linux-arm-kernel, linux-doc, linux-kernel, linux-media,
linux-rockchip, linux-sunxi, Maxime Ripard, Dave Stevenson,
Sui Jingfeng, Pekka Paalanen, Maíra Canal
Hi,
Here's a series that creates some extra infrastructure specifically
targeted at HDMI controllers.
The idea behind this series came from a recent discussion on IRC during
which we discussed infoframes generation of i915 vs everything else.
Infoframes generation code still requires some decent boilerplate, with
each driver doing some variation of it.
In parallel, while working on vc4, we ended up converting a lot of i915
logic (mostly around format / bpc selection, and scrambler setup) to
apply on top of a driver that relies only on helpers.
While currently sitting in the vc4 driver, none of that logic actually
relies on any driver or hardware-specific behaviour.
The only missing piece to make it shareable are a bunch of extra
variables stored in a state (current bpc, format, RGB range selection,
etc.).
The initial implementation was relying on some generic subclass of
drm_connector to address HDMI connectors, with a bunch of helpers that
will take care of all the "HDMI Spec" related code. Scrambler setup is
missing at the moment but can easily be plugged in.
The feedback was that creating a connector subclass like was done for
writeback would prevent the adoption of those helpers since it couldn't
be used in all situations (like when the connector driver can implement
multiple output) and required more churn to cast between the
drm_connector and its subclass. The decision was thus to provide a set
of helper and to store the required variables in drm_connector and
drm_connector_state. This what has been implemented now.
Hans Verkuil also expressed interest in implementing a mechanism in v4l2
to retrieve infoframes from HDMI receiver and implementing a tool to
decode (and eventually check) infoframes. His current work on
edid-decode to enable that based on that series can be found here:
https://git.linuxtv.org/hverkuil/edid-decode.git/log/?h=hverkuil
And some more context here:
https://lore.kernel.org/dri-devel/50db7366-cd3d-4675-aaad-b857202234de@xs4all.nl/
This series thus leverages the infoframe generation code to expose it
through debugfs.
I also used the occasion to unit-test everything but the infoframe
generation, which can come later once I get a proper understanding of
what the infoframe are supposed to look like. This required to add some
extra kunit helpers and infrastructure to have multiple EDIDs and allow
each test to run with a particular set of capabilities.
This entire series has been tested on a Pi4, passes all its unittests
(125 new tests), and has only been build-tested for sunxi and rockchip.
Let me know what you think,
Maxime
Signed-off-by: Maxime Ripard <mripard@kernel.org>
---
Changes in v10:
- Drop the YUV422 fallback, and adjust the tests accordingly
- Fix HDMI infoframe handling
- Remove the infoframe copy in drm_connector
- Add a TODO that drm_hdmi_avi_infoframe_quant_range() only works for
RGB
- Add a TODO for the YUV420 selection
- Fix a few bugs in vc4
- Change the logging from driver to KMS for the helpers
- Drop UPDATE_INFOFRAME macro
- Add infoframe code logging
- Document the selection of 8bpc for VIC1
- Rename state to conn_state where relevant
- Link to v9: https://lore.kernel.org/r/20240311-kms-hdmi-connector-state-v9-0-d45890323344@kernel.org
Changes in v9:
- Generate every infoframe but the HDMI vendor one if has_hdmi_infoframe
isn't set
- Fix typos in the doc
- Removed undef for inexisting macro
- Improve the Broadcast RGB sanitation test
- Make EDID bytes array const
- Link to v8: https://lore.kernel.org/r/20240307-kms-hdmi-connector-state-v8-0-ef6a6f31964b@kernel.org
Changes in v8:
- Drop applied patches
- Drop the YUV limited range mention in the Broadcast RGB documentation
- Rephrase the vc4_dummy_plane removal commit log
- Move infroframe mutex initialisation to the main drm_connector_init
function to make sure it's always initialised
- Link to v7: https://lore.kernel.org/r/20240222-kms-hdmi-connector-state-v7-0-8f4af575fce2@kernel.org
Changes in v7:
- Rebased on top of current next
- Only consider the Broadcast RGB property if the output format is RGB,
and use a limited range otherwise
- Document the fact that Broadcast RGB only applies if the output format
is RGB
- Add some test to make sure we always get a limited range if we have a
YCbCr output format.
- Link to v6: https://lore.kernel.org/r/20240212-kms-hdmi-connector-state-v6-0-f4bcdc979e6f@kernel.org
Changes in v6:
- Rebased on top of current next
- Split the tests into separate patches
- Improve the Broadcast RGB documentation
- Link to v5: https://lore.kernel.org/r/20231207-kms-hdmi-connector-state-v5-0-6538e19d634d@kernel.org
Changes in v5:
- Dropped the connector init arg checking patch, and the related kunit
tests
- Dropped HDMI Vendor infoframes in rockchip inno_hdmi
- Fixed the build warnings
- Link to v4: https://lore.kernel.org/r/20231128-kms-hdmi-connector-state-v4-0-c7602158306e@kernel.org
Changes in v4:
- Create unit tests for everything but infoframes
- Fix a number of bugs identified by the unit tests
- Rename DRM (Dynamic Range and Mastering) infoframe file to HDR_DRM
- Drop RFC status
- Link to v3: https://lore.kernel.org/r/20231031-kms-hdmi-connector-state-v3-0-328b0fae43a7@kernel.org
Changes in v3:
- Made sure the series work on the RaspberryPi4
- Handle YUV420 in the char clock rate computation
- Use the maximum bpc value the connector allows at reset
- Expose the RGB Limited vs Full Range value in the connector state
instead of through a helper
- Fix Broadcast RGB documentation
- Add more debug logging
- Small fixes here and there
- Link to v2: https://lore.kernel.org/r/20230920-kms-hdmi-connector-state-v2-0-17932daddd7d@kernel.org
Changes in v2:
- Change from a subclass to a set of helpers for drm_connector and
drm_connector state
- Don't assume that all drivers support RGB, YUV420 and YUV422 but make
them provide a bitfield instead.
- Don't assume that all drivers support the Broadcast RGB property but
make them call the registration helper.
- Document the Broacast RGB property
- Convert the inno_hdmi and sun4i_hdmi driver.
- Link to v1: https://lore.kernel.org/r/20230814-kms-hdmi-connector-state-v1-0-048054df3654@kernel.org
---
Maxime Ripard (27):
drm/connector: Introduce an HDMI connector initialization function
drm/tests: connector: Add tests for drmm_connector_hdmi_init
drm/connector: hdmi: Create an HDMI sub-state
drm/connector: hdmi: Add output BPC to the connector state
drm/tests: Add output bpc tests
drm/connector: hdmi: Add support for output format
drm/tests: Add output formats tests
drm/connector: hdmi: Add HDMI compute clock helper
drm/tests: Add HDMI TDMS character rate tests
drm/connector: hdmi: Calculate TMDS character rate
drm/tests: Add TDMS character rate connector state tests
drm/connector: hdmi: Add custom hook to filter TMDS character rate
drm/tests: Add HDMI connector rate filter hook tests
drm/connector: hdmi: Compute bpc and format automatically
drm/tests: Add HDMI connector bpc and format tests
drm/connector: hdmi: Add Broadcast RGB property
drm/tests: Add tests for Broadcast RGB property
drm/connector: hdmi: Add RGB Quantization Range to the connector state
drm/tests: Add RGB Quantization tests
drm/connector: hdmi: Add Infoframes generation
drm/tests: Add infoframes test
drm/connector: hdmi: Create Infoframe DebugFS entries
drm/vc4: hdmi: Switch to HDMI connector
drm/vc4: tests: Remove vc4_dummy_plane structure
drm/vc4: tests: Convert to plane creation helper
drm/rockchip: inno_hdmi: Switch to HDMI connector
drm/sun4i: hdmi: Switch to HDMI connector
Documentation/gpu/kms-properties.csv | 1 -
drivers/gpu/drm/Kconfig | 1 +
drivers/gpu/drm/drm_atomic.c | 11 +
drivers/gpu/drm/drm_atomic_state_helper.c | 690 ++++++++
drivers/gpu/drm/drm_atomic_uapi.c | 4 +
drivers/gpu/drm/drm_connector.c | 265 +++
drivers/gpu/drm/drm_debugfs.c | 152 ++
drivers/gpu/drm/rockchip/inno_hdmi.c | 143 +-
drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 80 +-
drivers/gpu/drm/tests/Makefile | 1 +
.../gpu/drm/tests/drm_atomic_state_helper_test.c | 1736 ++++++++++++++++++++
drivers/gpu/drm/tests/drm_connector_test.c | 1059 +++++++++++-
drivers/gpu/drm/tests/drm_kunit_edid.h | 482 ++++++
drivers/gpu/drm/vc4/tests/vc4_mock.c | 6 +-
drivers/gpu/drm/vc4/tests/vc4_mock.h | 9 +-
drivers/gpu/drm/vc4/tests/vc4_mock_plane.c | 44 +-
drivers/gpu/drm/vc4/vc4_hdmi.c | 643 +-------
drivers/gpu/drm/vc4/vc4_hdmi.h | 44 +-
drivers/gpu/drm/vc4/vc4_hdmi_phy.c | 6 +-
include/drm/drm_atomic_state_helper.h | 12 +
include/drm/drm_connector.h | 233 +++
21 files changed, 4853 insertions(+), 769 deletions(-)
---
base-commit: 43d95569d4f1651692d6e84af890692232b7b891
change-id: 20230814-kms-hdmi-connector-state-616787e67927
Best regards,
--
Maxime Ripard <mripard@kernel.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 2/2] remoteproc: mediatek: Don't parse extraneous subnodes for multi-core
From: Mathieu Poirier @ 2024-03-21 15:27 UTC (permalink / raw)
To: AngeloGioacchino Del Regno
Cc: andersson, matthias.bgg, tzungbi, tinghan.shen, linux-remoteproc,
linux-kernel, linux-arm-kernel, linux-mediatek, wenst, kernel
In-Reply-To: <20240321084614.45253-3-angelogioacchino.delregno@collabora.com>
On Thu, Mar 21, 2024 at 09:46:14AM +0100, AngeloGioacchino Del Regno wrote:
> When probing multi-core SCP, this driver is parsing all sub-nodes of
> the scp-cluster node, but one of those could be not an actual SCP core
> and that would make the entire SCP cluster to fail probing for no good
> reason.
>
> To fix that, in scp_add_multi_core() treat a subnode as a SCP Core by
> parsing only available subnodes having compatible "mediatek,scp-core".
>
> Fixes: 1fdbf0cdde98 ("remoteproc: mediatek: Probe SCP cluster on multi-core SCP")
> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> ---
> drivers/remoteproc/mtk_scp.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/remoteproc/mtk_scp.c b/drivers/remoteproc/mtk_scp.c
> index 67518291a8ad..fbe1c232dae7 100644
> --- a/drivers/remoteproc/mtk_scp.c
> +++ b/drivers/remoteproc/mtk_scp.c
> @@ -1096,6 +1096,9 @@ static int scp_add_multi_core(struct platform_device *pdev,
> cluster_of_data = (const struct mtk_scp_of_data **)of_device_get_match_data(dev);
>
> for_each_available_child_of_node(np, child) {
> + if (!of_device_is_compatible(child, "mediatek,scp-core"))
> + continue;
> +
Interesting - what else gets stashed under the remote processor node? I don't
see anything specified in the bindings.
Thanks,
Mathieu
> if (!cluster_of_data[core_id]) {
> ret = -EINVAL;
> dev_err(dev, "Not support core %d\n", core_id);
> --
> 2.44.0
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/2] remoteproc: mediatek: Make sure IPI buffer fits in L2TCM
From: Mathieu Poirier @ 2024-03-21 15:25 UTC (permalink / raw)
To: AngeloGioacchino Del Regno
Cc: andersson, matthias.bgg, tzungbi, tinghan.shen, linux-remoteproc,
linux-kernel, linux-arm-kernel, linux-mediatek, wenst, kernel
In-Reply-To: <20240321084614.45253-2-angelogioacchino.delregno@collabora.com>
Good day,
On Thu, Mar 21, 2024 at 09:46:13AM +0100, AngeloGioacchino Del Regno wrote:
> The IPI buffer location is read from the firmware that we load to the
> System Companion Processor, and it's not granted that both the SRAM
> (L2TCM) size that is defined in the devicetree node is large enough
> for that, and while this is especially true for multi-core SCP, it's
> still useful to check on single-core variants as well.
>
> Failing to perform this check may make this driver perform R/W
> oeprations out of the L2TCM boundary, resulting (at best) in a
s/oeprations/operations
I will fix that when I apply the patch.
> kernel panic.
>
> To fix that, check that the IPI buffer fits, otherwise return a
> failure and refuse to boot the relevant SCP core (or the SCP at
> all, if this is single core).
>
> Fixes: 3efa0ea743b7 ("remoteproc/mediatek: read IPI buffer offset from FW")
> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> ---
> drivers/remoteproc/mtk_scp.c | 10 +++++++++-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/remoteproc/mtk_scp.c b/drivers/remoteproc/mtk_scp.c
> index a35409eda0cf..67518291a8ad 100644
> --- a/drivers/remoteproc/mtk_scp.c
> +++ b/drivers/remoteproc/mtk_scp.c
> @@ -132,7 +132,7 @@ static int scp_elf_read_ipi_buf_addr(struct mtk_scp *scp,
> static int scp_ipi_init(struct mtk_scp *scp, const struct firmware *fw)
> {
> int ret;
> - size_t offset;
> + size_t buf_sz, offset;
>
> /* read the ipi buf addr from FW itself first */
> ret = scp_elf_read_ipi_buf_addr(scp, fw, &offset);
> @@ -144,6 +144,14 @@ static int scp_ipi_init(struct mtk_scp *scp, const struct firmware *fw)
> }
> dev_info(scp->dev, "IPI buf addr %#010zx\n", offset);
>
> + /* Make sure IPI buffer fits in the L2TCM range assigned to this core */
> + buf_sz = sizeof(*scp->recv_buf) + sizeof(*scp->send_buf);
> +
> + if (scp->sram_size < buf_sz + offset) {
> + dev_err(scp->dev, "IPI buffer does not fit in SRAM.\n");
> + return -EOVERFLOW;
> + }
> +
> scp->recv_buf = (struct mtk_share_obj __iomem *)
> (scp->sram_base + offset);
> scp->send_buf = (struct mtk_share_obj __iomem *)
> --
> 2.44.0
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [PATCH v2] ARM: unwind: improve unwinders for noreturn case
From: David Laight @ 2024-03-21 15:20 UTC (permalink / raw)
To: 'Russell King'
Cc: Ard Biesheuvel, 'Jiangfeng Xiao', arnd@arndb.de,
keescook@chromium.org, haibo.li@mediatek.com,
angelogioacchino.delregno@collabora.com, amergnat@baylibre.com,
akpm@linux-foundation.org, dave.hansen@linux.intel.com,
douzhaolei@huawei.com, gustavoars@kernel.org, jpoimboe@kernel.org,
kepler.chenxin@huawei.com, kirill.shutemov@linux.intel.com,
linux-hardening@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, linux-arm-kernel@lists.infradead.org,
nixiaoming@huawei.com, peterz@infradead.org, wangbing6@huawei.com,
wangfangpeng1@huawei.com, jannh@google.com, willy@infradead.org
In-Reply-To: <ZfxKiQuNM/zruxSd@shell.armlinux.org.uk>
From: Russell King
> Sent: 21 March 2024 14:56
>
> On Thu, Mar 21, 2024 at 02:37:28PM +0000, David Laight wrote:
> > From: Russell King
> > > Sent: 21 March 2024 13:08
> > >
> > > On Thu, Mar 21, 2024 at 12:57:07PM +0000, David Laight wrote:
> > > > From: Russell King
> > > > > Sent: 21 March 2024 12:23
> > > > ...
> > > > > > That might mean you can get the BL in the middle of a function
> > > > > > but where the following instruction is for the 'no stack frame'
> > > > > > side of the branch.
> > > > > > That is very likely to break any stack offset calculations.
> > > > >
> > > > > No it can't. At any one point in the function, the stack has to be in
> > > > > a well defined state, so that access to local variables can work, and
> > > > > also the stack can be correctly unwound. If there exists a point in
> > > > > the function body which can be reached where the stack could be in two
> > > > > different states, then the stack can't be restored to the parent
> > > > > context.
> > > >
> > > > Actually you can get there with a function that has a lot of args.
> > > > So you can have:
> > > > if (...) {
> > > > push x
> > > > bl func
> > > > add %sp, #8
> > > > }
> > > > code;
> > > > which is fine.
> > >
> > > No you can't.... and that isn't even Arm code. Arm doesn't use %sp.
> > > Moreover, that "bl" will stomp over the link register, meaning this
> > > function can not return.
> >
...
>
> Don't show me Arm64 assembly when we're discussing Arm32.
Oops - I'd assumed no one did 32bit :-)
In any case it is much the same, see https://godbolt.org/z/7dcbKrs76
f4:
push {r3, lr}
subs r3, r0, #0
ble .L2
mov r2, r3
mov r1, r3
bl f
.L2:
pop {r3, pc}
f5:
subs r3, r0, #0
ble .L6
push {lr}
sub sp, sp, #12
mov r2, r3
mov r1, r3
str r3, [sp]
bl f
.L6:
bx lr
That is with -mno-sched-prolog but with 5+ args they spill to stack
and the %sp change is pulled into the conditional.
It does look like %lr is being saved (and for arm64 I think).
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH RFC] arm64: dts: lx2160a: extend 32-bit, and add 64-bit pci regions
From: Josua Mayer @ 2024-03-21 15:13 UTC (permalink / raw)
To: Shawn Guo, Li Yang, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Yazan Shhady, Jon Nettleton, linux-arm-kernel, devicetree,
linux-kernel, Josua Mayer
LX2160 SoC pci-e controller supports 64-bit memory regions up to 16GB,
32-bit regions up to 3GB and 16-bit regions up to 64k.
For each pci-e controller:
- extend the existing 32-bit regions to 3GB size
- add 16-bit region
- add 64-bit region
Marked RFC because I would like some advice on the io resource flags.
This allocation was tested on SolidRun Clearfog-CX with EDK2 firmware
(ACPI) on pcie5, and later adapted for device-tree.
The device-tree configuration was tested with pcie3 and pcie5 and nxp
lsdk-21.08 based u-boot.
Fixes allocation of large, and 64-bit BARs as requested by many pci
cards, especially graphics processors or AI accelerators, e.g.:
[ 2.941187] pci 0000:01:00.0: BAR 0: no space for [mem size 0x200000000 64bit pref]
[ 2.948834] pci 0000:01:00.0: BAR 0: failed to assign [mem size 0x200000000 64bit pref]
Signed-off-by: Josua Mayer <josua@solid-run.com>
---
arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi | 24 ++++++++++++++++++------
1 file changed, 18 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
index 6640b49670ae..3ab1db6f54e2 100644
--- a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
@@ -1134,7 +1134,9 @@ pcie1: pcie@3400000 {
apio-wins = <8>;
ppio-wins = <8>;
bus-range = <0x0 0xff>;
- ranges = <0x82000000 0x0 0x40000000 0x80 0x40000000 0x0 0x40000000>; /* non-prefetchable memory */
+ ranges = <0x02102000 0x84 0x00000000 0x84 0x00000000 0x04 0x00000000>, /* 64-Bit Window - prefetchable */
+ <0x82000000 0x00 0x40000000 0x80 0x40000000 0x00 0xc0000000>, /* 32-Bit Window - non-prefetchable */
+ <0x02000000 0x00 0x00000000 0x80 0x10000000 0x00 0x00010000>; /* 16-Bit IO Window */
msi-parent = <&its>;
#interrupt-cells = <1>;
interrupt-map-mask = <0 0 0 7>;
@@ -1162,7 +1164,9 @@ pcie2: pcie@3500000 {
apio-wins = <8>;
ppio-wins = <8>;
bus-range = <0x0 0xff>;
- ranges = <0x82000000 0x0 0x40000000 0x88 0x40000000 0x0 0x40000000>; /* non-prefetchable memory */
+ ranges = <0x02102000 0x8c 0x00000000 0x8c 0x00000000 0x04 0x00000000>, /* 64-Bit Window - prefetchable */
+ <0x82000000 0x00 0x40000000 0x88 0x40000000 0x00 0xc0000000>, /* 32-Bit Window - non-prefetchable */
+ <0x02000000 0x00 0x00000000 0x88 0x10000000 0x00 0x00010000>; /* 16-Bit IO Window */
msi-parent = <&its>;
#interrupt-cells = <1>;
interrupt-map-mask = <0 0 0 7>;
@@ -1190,7 +1194,9 @@ pcie3: pcie@3600000 {
apio-wins = <256>;
ppio-wins = <24>;
bus-range = <0x0 0xff>;
- ranges = <0x82000000 0x0 0x40000000 0x90 0x40000000 0x0 0x40000000>; /* non-prefetchable memory */
+ ranges = <0x02102000 0x94 0x00000000 0x94 0x00000000 0x04 0x00000000>, /* 64-Bit Window - prefetchable */
+ <0x82000000 0x00 0x40000000 0x90 0x40000000 0x00 0xc0000000>, /* 32-Bit Window - non-prefetchable */
+ <0x02000000 0x00 0x00000000 0x90 0x10000000 0x00 0x00010000>; /* 16-Bit IO Window */
msi-parent = <&its>;
#interrupt-cells = <1>;
interrupt-map-mask = <0 0 0 7>;
@@ -1218,7 +1224,9 @@ pcie4: pcie@3700000 {
apio-wins = <8>;
ppio-wins = <8>;
bus-range = <0x0 0xff>;
- ranges = <0x82000000 0x0 0x40000000 0x98 0x40000000 0x0 0x40000000>; /* non-prefetchable memory */
+ ranges = <0x02102000 0x9c 0x00000000 0x9c 0x00000000 0x04 0x00000000>, /* 64-Bit Window - prefetchable */
+ <0x82000000 0x00 0x40000000 0x98 0x40000000 0x00 0xc0000000>, /* 32-Bit Window - non-prefetchable */
+ <0x02000000 0x00 0x00000000 0x98 0x10000000 0x00 0x00010000>; /* 16-Bit IO Window */
msi-parent = <&its>;
#interrupt-cells = <1>;
interrupt-map-mask = <0 0 0 7>;
@@ -1246,7 +1254,9 @@ pcie5: pcie@3800000 {
apio-wins = <256>;
ppio-wins = <24>;
bus-range = <0x0 0xff>;
- ranges = <0x82000000 0x0 0x40000000 0xa0 0x40000000 0x0 0x40000000>; /* non-prefetchable memory */
+ ranges = <0x02102000 0xa4 0x00000000 0xa4 0x00000000 0x04 0x00000000>, /* 64-Bit Window - prefetchable */
+ <0x82000000 0x00 0x40000000 0xa0 0x40000000 0x00 0xc0000000>, /* 32-Bit Window - non-prefetchable */
+ <0x02000000 0x00 0x00000000 0xa0 0x10000000 0x00 0x00010000>; /* 16-Bit IO Window */
msi-parent = <&its>;
#interrupt-cells = <1>;
interrupt-map-mask = <0 0 0 7>;
@@ -1274,7 +1284,9 @@ pcie6: pcie@3900000 {
apio-wins = <8>;
ppio-wins = <8>;
bus-range = <0x0 0xff>;
- ranges = <0x82000000 0x0 0x40000000 0xa8 0x40000000 0x0 0x40000000>; /* non-prefetchable memory */
+ ranges = <0x02102000 0xac 0x00000000 0xac 0x00000000 0x04 0x00000000>, /* 64-Bit Window - prefetchable */
+ <0x82000000 0x00 0x40000000 0xa8 0x40000000 0x00 0xc0000000>, /* 32-Bit Window - non-prefetchable */
+ <0x02000000 0x00 0x00000000 0xa8 0x10000000 0x00 0x00010000>; /* 16-Bit IO Window */
msi-parent = <&its>;
#interrupt-cells = <1>;
interrupt-map-mask = <0 0 0 7>;
---
base-commit: e8f897f4afef0031fe618a8e94127a0934896aba
change-id: 20240118-lx2160-pci-4bdb196e58f3
Sincerely,
--
Josua Mayer <josua@solid-run.com>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH 2/3] dt-bindings: remoteproc: add Versal-NET platform
From: Tanmay Shah @ 2024-03-21 15:13 UTC (permalink / raw)
To: Krzysztof Kozlowski, andersson, mathieu.poirier, robh+dt,
krzysztof.kozlowski+dt, conor+dt, michal.simek, ben.levinsky
Cc: linux-remoteproc, devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <5025fb10-3bcc-43b1-ae85-b556f1c0415f@linaro.org>
On 3/21/24 2:39 AM, Krzysztof Kozlowski wrote:
> On 20/03/2024 16:14, Tanmay Shah wrote:
>>
>>
>> On 3/20/24 2:40 AM, Krzysztof Kozlowski wrote:
>>> On 19/03/2024 15:42, Tanmay Shah wrote:
>>>>
>>>>
>>>> On 3/19/24 12:30 AM, Krzysztof Kozlowski wrote:
>>>>> On 19/03/2024 01:51, Tanmay Shah wrote:
>>>>>> Hello Krzysztof,
>>>>>>
>>>>>> Thanks for reviews. Please find my comments below.
>>>>>>
>>>>>> On 3/17/24 1:53 PM, Krzysztof Kozlowski wrote:
>>>>>>> On 15/03/2024 22:15, Tanmay Shah wrote:
>>>>>>>> AMD-Xilinx Versal-NET platform is successor of Versal platform. It
>>>>>>>> contains multiple clusters of cortex-R52 real-time processing units.
>>>>>>>> Each cluster contains two cores of cortex-R52 processors. Each cluster
>>>>>>>> can be configured in lockstep mode or split mode.
>>>>>>>>
>>>>>>>> Each R52 core is assigned 128KB of TCM memory. ATCM memory is 64KB, BTCM
>>>>>>>> and CTCM memoreis are 32KB each. Each TCM memory has its own dedicated
>>>>>>>> power-domain that needs to be requested before using it.
>>>>>>>>
>>>>>>>> Signed-off-by: Tanmay Shah <tanmay.shah@amd.com>
>>>>>>>> ---
>>>>>>>> .../remoteproc/xlnx,zynqmp-r5fss.yaml | 220 +++++++++++++++---
>>>>>>>> 1 file changed, 184 insertions(+), 36 deletions(-)
>>>>>>>>
>>>>>>>> diff --git a/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml b/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml
>>>>>>>> index 711da0272250..55654ee02eef 100644
>>>>>>>> --- a/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml
>>>>>>>> +++ b/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml
>>>>>>>> @@ -18,7 +18,9 @@ description: |
>>>>>>>>
>>>>>>>> properties:
>>>>>>>> compatible:
>>>>>>>> - const: xlnx,zynqmp-r5fss
>>>>>>>> + enum:
>>>>>>>> + - xlnx,zynqmp-r5fss
>>>>>>>> + - xlnx,versal-net-r52fss
>>>>>>>>
>>>>>>>> "#address-cells":
>>>>>>>> const: 2
>>>>>>>> @@ -64,7 +66,9 @@ patternProperties:
>>>>>>>>
>>>>>>>> properties:
>>>>>>>> compatible:
>>>>>>>> - const: xlnx,zynqmp-r5f
>>>>>>>> + enum:
>>>>>>>> + - xlnx,zynqmp-r5f
>>>>>>>> + - xlnx,versal-net-r52f
>>>>>>>>
>>>>>>>> reg:
>>>>>>>> minItems: 1
>>>>>>>> @@ -135,9 +139,11 @@ required:
>>>>>>>> allOf:
>>>>>>>> - if:
>>>>>>>> properties:
>>>>>>>> - xlnx,cluster-mode:
>>>>>>>> - enum:
>>>>>>>> - - 1
>>>>>>>> + compatible:
>>>>>>>> + contains:
>>>>>>>> + enum:
>>>>>>>> + - xlnx,versal-net-r52fss
>>>>>>>
>>>>>>> Why do you touch these lines?
>>>>>>>
>>>>>>>> +
>>>>>>>> then:
>>>>>>>> patternProperties:
>>>>>>>> "^r5f@[0-9a-f]+$":
>>>>>>>> @@ -149,16 +155,14 @@ allOf:
>>>>>>>> items:
>>>>>>>> - description: ATCM internal memory
>>>>>>>> - description: BTCM internal memory
>>>>>>>> - - description: extra ATCM memory in lockstep mode
>>>>>>>> - - description: extra BTCM memory in lockstep mode
>>>>>>>> + - description: CTCM internal memory
>>>>>>>>
>>>>>>>> reg-names:
>>>>>>>> minItems: 1
>>>>>>>> items:
>>>>>>>> - - const: atcm0
>>>>>>>> - - const: btcm0
>>>>>>>> - - const: atcm1
>>>>>>>> - - const: btcm1
>>>>>>>> + - const: atcm
>>>>>>>> + - const: btcm
>>>>>>>> + - const: ctcm
>>>>>>>>
>>>>>>>> power-domains:
>>>>>>>> minItems: 2
>>>>>>>> @@ -166,33 +170,70 @@ allOf:
>>>>>>>> - description: RPU core power domain
>>>>>>>> - description: ATCM power domain
>>>>>>>> - description: BTCM power domain
>>>>>>>> - - description: second ATCM power domain
>>>>>>>> - - description: second BTCM power domain
>>>>>>>> + - description: CTCM power domain
>>>>>>>>
>>>>>>>> else:
>>>>>>>> - patternProperties:
>>>>>>>> - "^r5f@[0-9a-f]+$":
>>>>>>>> - type: object
>>>>>>>> -
>>>>>>>> - properties:
>>>>>>>> - reg:
>>>>>>>> - minItems: 1
>>>>>>>> - items:
>>>>>>>> - - description: ATCM internal memory
>>>>>>>> - - description: BTCM internal memory
>>>>>>>> -
>>>>>>>> - reg-names:
>>>>>>>> - minItems: 1
>>>>>>>> - items:
>>>>>>>> - - const: atcm0
>>>>>>>> - - const: btcm0
>>>>>>>> -
>>>>>>>> - power-domains:
>>>>>>>> - minItems: 2
>>>>>>>> - items:
>>>>>>>> - - description: RPU core power domain
>>>>>>>> - - description: ATCM power domain
>>>>>>>> - - description: BTCM power domain
>>>>>>>> + allOf:
>>>>>>>> + - if:
>>>>>>>> + properties:
>>>>>>>> + xlnx,cluster-mode:
>>>>>>>> + enum:
>>>>>>>> + - 1
>>>>>>>
>>>>>>> Whatever you did here, is not really readable. You have now multiple
>>>>>>> if:then:if:then embedded.
>>>>>>
>>>>>> For ZynqMP platform, TCM can be configured differently in lockstep mode
>>>>>> and split mode.
>>>>>>
>>>>>> For Versal-NET no such configuration is available, but new CTCM memory
>>>>>> is added.
>>>>>>
>>>>>> So, I am trying to achieve following representation of TCM for both:
>>>>>>
>>>>>> if: versal-net compatible
>>>>>> then:
>>>>>> ATCM - 64KB
>>>>>> BTCM - 32KB
>>>>>> CTCM - 32KB
>>>>>>
>>>>>> else: (ZynqMP compatible)
>>>>>> if:
>>>>>> xlnx,cluster-mode (lockstep mode)
>>>>>> then:
>>>>>> ATCM0 - 64KB
>>>>>> BTCM0 - 64KB
>>>>>> ATCM1 - 64KB
>>>>>> BTCM1 - 64KB
>>>>>> else: (split mode)
>>>>>> ATCM0 - 64KB
>>>>>> BTCM0 - 64KB
>>>>>>
>>>>>>
>>>>>> If bindings are getting complicated, does it make sense to introduce
>>>>>> new file for Versal-NET bindings? Let me know how you would like me
>>>>>> to proceed.
>>>>>
>>>>> All this is broken in your previous patchset, but now we nicely see.
>>>>>
>>>>> No, this does not work like this. You do not have entirely different
>>>>> programming models in one device, don't you?
>>>>>
>>>>
>>>> I don't understand what do you mean? Programming model is same. Only number
>>>> of TCMs are changing based on configuration and platform. I can certainly
>>>> list different compatible for different platforms as requested. But other than
>>>> that not sure what needs to be fixed.
>>>
>>> You cannot have same programming model with different memory mappings.
>>> Anyway, please follow writing bindings rules: all of your different
>>> devices must have dedicated compatible. I really though we talked about
>>> two IPs on same SoC...
>>
>> I agree that Versal compatible should be added, I will do that in next revision.
>>
>> For ZynqMP case, it is two IPs on same SOC. In lockstep mode and split mode,
>> same SOC is configuring TCM differently.
>>
>> How this should be resolved for Versal-NET ? Driver avoids such TCM configuration
>> for Versal-NET.
>
> Binding should describe the hardware, not what driver is doing
> currently, so the question is: does your device have such properties or
> not? Anyway, you need compatible per each variant and each SoC
> implementation.
Thanks for reviews.
Okay in that case I believe I should add one more property to current bindings for TCM
configuration.
From our discussion I conclude to following next steps:
1) I will send Versal and Versal-NET support as part of previous series (v14) so we get
bigger picture in the first place.
2) Add separate compatible for versal platform.
Use device compatible string to maintain
backward compatibility and not machine (root node) compatible string.
3) Add tcm,mode property in bindings and each device must configure TCM based on that
property only and not based on compatible string.
4) Versal-NET will disallow tcm,mode property in bindings as no such configuration is
possible for that platform.
I hope I got everything. I will test and send v14 of previous series accordingly.
Tanmay
>
> Best regards,
> Krzysztof
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] net: stmmac: Do not enable/disable runtime PM for PCI devices
From: Jiri Pirko @ 2024-03-21 15:04 UTC (permalink / raw)
To: Mikhail Malyshev
Cc: Alexandre Torgue, Jose Abreu, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Maxime Coquelin, netdev, linux-stm32,
linux-arm-kernel, linux-kernel
In-Reply-To: <20240321-stmmac-fix-v1-1-3aef470494c6@gmail.com>
Thu, Mar 21, 2024 at 02:54:15PM CET, mike.malyshev@gmail.com wrote:
>Common function stmmac_dvr_probe is called for both PCI and non-PCI
>device. For PCI devices pm_runtime_enable/disable are called by framework
>and should not be called by the driver.
I don't follow. The rest of the pm_runtime* functions are okay to call,
but enable() is not. Why? You need to provide more reasoning.
>
>For PCI devices plat->pdev != NULL. Use this fact to detect PCI devices
Sentence ends with "."
I assume this is a bug fix. Do you have a trace or some other symptoms?
Please add it to the patch description. You also need to add "Fixes"
tag.
Make sure you read:
https://www.kernel.org/doc/html/next/process/maintainer-netdev.html?highlight=network#tl-dr
Thanks
pw-bot: cr
>
>Signed-off-by: Mikhail Malyshev <mike.malyshev@gmail.com>
>---
> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 9 +++++++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
>diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>index 24cd80490d19..db45d8dbc1eb 100644
>--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>@@ -7743,7 +7743,9 @@ int stmmac_dvr_probe(struct device *device,
>
> pm_runtime_get_noresume(device);
> pm_runtime_set_active(device);
>- if (!pm_runtime_enabled(device))
>+
>+ /* For PCI devices PM is disabled/enabled by the framework */
>+ if (!priv->plat->pdev)
> pm_runtime_enable(device);
>
> if (priv->hw->pcs != STMMAC_PCS_TBI &&
>@@ -7846,7 +7848,10 @@ void stmmac_dvr_remove(struct device *dev)
> mutex_destroy(&priv->lock);
> bitmap_free(priv->af_xdp_zc_qps);
>
>- pm_runtime_disable(dev);
>+ /* For PCI devices PM is disabled/enabled by the framework */
>+ if (!priv->plat->pdev)
>+ pm_runtime_disable(dev);
>+
> pm_runtime_put_noidle(dev);
> }
> EXPORT_SYMBOL_GPL(stmmac_dvr_remove);
>
>---
>base-commit: 23956900041d968f9ad0f30db6dede4daccd7aa9
>change-id: 20240321-stmmac-fix-f506d52882d2
>
>Best regards,
>--
>Mikhail Malyshev <mike.malyshev@gmail.com>
>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 0/2] Fixes NULL pointer access in spi-mt65xx.c
From: Mark Brown @ 2024-03-21 15:01 UTC (permalink / raw)
To: AngeloGioacchino Del Regno, Fei Shao
Cc: Daniel Kurtz, Matthias Brugger, linux-arm-kernel, linux-kernel,
linux-mediatek, linux-spi
In-Reply-To: <20240321070942.1587146-1-fshao@chromium.org>
On Thu, 21 Mar 2024 15:08:56 +0800, Fei Shao wrote:
> This series contains two patches for spi-mt65xx.c, both focusing on its
> interrupt handler mtk_spi_interrupt().
>
> The first patch is to fix a NULL pointer access in the interrupt
> handler, which is first found on a MT8186 Chromebook device when the
> system tries to establish host communication with its embedded
> controller.
>
> [...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next
Thanks!
[1/2] spi: spi-mt65xx: Fix NULL pointer access in interrupt handler
commit: a20ad45008a7c82f1184dc6dee280096009ece55
[2/2] spi: spi-mt65xx: Rename a variable in interrupt handler
(no commit info)
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 0/5] Add RK816 PMIC support
From: Dragan Simic @ 2024-03-21 15:01 UTC (permalink / raw)
To: Alex Bee
Cc: Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Heiko Stuebner, Linus Walleij, Liam Girdwood, Mark Brown,
Chris Zhong, Zhang Qing, devicetree, linux-arm-kernel,
linux-rockchip, linux-kernel, linux-gpio
In-Reply-To: <20240321143911.90210-2-knaerzche@gmail.com>
Hello Alex,
On 2024-03-21 15:39, Alex Bee wrote:
> This series aims to add support for Rockchip RK816 PMIC series. As per
> datasheet it's targeted for RK3126/RK3128 (RK816-1), RK1108 (RK816-2)
> and
> PX3-SE (RK816-3) but might be used for other SoCs as well. The mfd
> consists
> of an integrated RTC, a GPIO controller, two 32k clock outputs, a power
> key
> (output), 4 buck- and 5 ldo regulators, 3 regulator-switches, and
> charger
> with integrated fuel gauge. Charger and fuel gauge are not part of this
> series. Two of the switches (otg/boost) are part of the binding, but
> not of
> the driver. They must only ever by enabled if no battery charging is
> happening, but it will be enabled automatically if a battery is
> attached.
> Thus they need some incorporation of a yet to be added charger driver.
> Integration in the existing rk8xx-infrastructure was pretty
> straightforward
> and only needed very little tweaking. In order to not further bloat the
> driver(s) too much with additional definitions I tried to re-use
> existing
> ones wherever possible.
>
> The patches are loosely based on the vendor's implementation, verified
> against the datasheet and tested/measured on RK3126 board. As they are
> touching several subsystems I'm sending them (very) early for the
> 6.10-cycle.
I went quickly through all patches in the series except the one that
adds
the bindings, and I've spotted no glaring issues. My main focus was on
ensuring there should be no regressions.
Thus, not worth a Reviewed-by tag, but still counting as a review.
> Alex Bee (5):
> dt-bindings: mfd: Add rk816 binding
> mfd: rk8xx: Add RK816 support
> pinctrl: rk805: Add rk816 pinctrl support
> regulator: rk808: Support apply_bit for
> rk808_set_suspend_voltage_range
> regulator: rk808: Add RK816 support
>
> .../bindings/mfd/rockchip,rk816.yaml | 259 ++++++++++++++++++
> drivers/mfd/Kconfig | 4 +-
> drivers/mfd/rk8xx-core.c | 103 +++++++
> drivers/mfd/rk8xx-i2c.c | 45 ++-
> drivers/pinctrl/pinctrl-rk805.c | 68 +++++
> drivers/regulator/rk808-regulator.c | 218 ++++++++++++++-
> include/linux/mfd/rk808.h | 141 ++++++++++
> 7 files changed, 831 insertions(+), 7 deletions(-)
> create mode 100644
> Documentation/devicetree/bindings/mfd/rockchip,rk816.yaml
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v5 14/27] iommu/arm-smmu-v3: Make changing domains be hitless for ATS
From: Michael Shavit @ 2024-03-21 14:57 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: iommu, Joerg Roedel, linux-arm-kernel, Robin Murphy, Will Deacon,
Eric Auger, Jean-Philippe Brucker, Moritz Fischer, Nicolin Chen,
patches, Shameerali Kolothum Thodi
In-Reply-To: <CAKHBV26dSY+Gy-x9HTWVCcNMyAkB1g+Y+dv-Lg+-furpu9bnSw@mail.gmail.com>
On Thu, Mar 21, 2024 at 10:53 PM Michael Shavit <mshavit@google.com> wrote:
>
> On Thu, Mar 21, 2024 at 9:28 PM Jason Gunthorpe <jgg@nvidia.com> wrote:
> >
> > On Thu, Mar 21, 2024 at 08:26:43PM +0800, Michael Shavit wrote:
> > > Overall I think the patch works, but it took me a while to really
> > > digest the big picture. Just to make sure I fully understand:
> > >
> > > We're trying to satisfy the following invariants for correctness:
> > > 1. Devices cannot get translations from a domain that was detached
> > > after arm_smmu_attach_dev() returns.
> >
> > Yes, regardless of ATS this is the API requirement.
> >
> > > 2. Devices cannot get cached translations from a domain after
> > > arm_smmu_atc_inv_domain() returns, regardless of whether the domain is
> > > simultaneously being attached/detached from a device.
> >
> > There is no simultaneously here since the group lock is held by the
> > core code.
>
> I meant a call to arm_smmu_attach_dev concurrent with
> arm_smmu_atc_inv_domain (through tlb_flush_all).
>
> >
> > > Apart from note point 2. above, the behaviour of translations while in
> > > the middle of an arm_smmu_attach_dev doesn't have well defined
> > > requirements:
> > > 1. Before this patch, devices may get translations belonging to the
> > > old domain, then aborts or identity translations, and then the new
> > > domain while arm_smmu_attach_dev() is in progress.
> >
> > Yes
> >
> > > 2. Ater this patch, devices may get an arbitrary mix of translations
> > > belonging to the old domain and the new domain while
> > > arm_smmu_attach_dev() is in progress.
> >
> > Yes, but no aborts.
> >
> > > While disabling and re-enabling ATS inside arm_smmu_attach_dev() would
> > > meet the same requirements as this patch, it's not optimal since the
> > > device may still have traffic on other pasids than the one being
> > > manipulated.
> >
> > Yes, we can't just disable ATS due to the PASIDs. A SVA PASID might be
> > present and disabling ATS to change the RID domain would completely
> > wreck it. Today this scenario is prevented by sva_enable, which is
> > removed in following patches.
>
> What do you mean by wrecking? We might slow it down to a crawl but we
> wouldn't be corrupting or destroying anything by disabling ATS while
> SVA is running would we?
> Oh does disabling ATS abort all transactions rather than making it transparent?
>
> >
> > I added this note for context to the commit message:
> >
> > This is part of the bigger picture to allow changing the RID domain while
> > a PASID is in use. If a SVA PASID is relying on ATS to function then
> > changing the RID domain cannot just temporarily toggle ATS off without
> > also wrecking the SVA PASID. The new infrastructure here is organized so
> > that the PASID attach/detach flows will make use of it as well in
> > following patches.
Huh ok yeah, I thought this was just enabling/disabling caching of
translations in the ATC but looks like it's disabling translation for
those PCIe devices.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2] ARM: unwind: improve unwinders for noreturn case
From: Russell King (Oracle) @ 2024-03-21 14:56 UTC (permalink / raw)
To: David Laight
Cc: Ard Biesheuvel, 'Jiangfeng Xiao', arnd@arndb.de,
keescook@chromium.org, haibo.li@mediatek.com,
angelogioacchino.delregno@collabora.com, amergnat@baylibre.com,
akpm@linux-foundation.org, dave.hansen@linux.intel.com,
douzhaolei@huawei.com, gustavoars@kernel.org, jpoimboe@kernel.org,
kepler.chenxin@huawei.com, kirill.shutemov@linux.intel.com,
linux-hardening@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, linux-arm-kernel@lists.infradead.org,
nixiaoming@huawei.com, peterz@infradead.org, wangbing6@huawei.com,
wangfangpeng1@huawei.com, jannh@google.com, willy@infradead.org
In-Reply-To: <9d6057b110034c04b6b590522c8c69cc@AcuMS.aculab.com>
On Thu, Mar 21, 2024 at 02:37:28PM +0000, David Laight wrote:
> From: Russell King
> > Sent: 21 March 2024 13:08
> >
> > On Thu, Mar 21, 2024 at 12:57:07PM +0000, David Laight wrote:
> > > From: Russell King
> > > > Sent: 21 March 2024 12:23
> > > ...
> > > > > That might mean you can get the BL in the middle of a function
> > > > > but where the following instruction is for the 'no stack frame'
> > > > > side of the branch.
> > > > > That is very likely to break any stack offset calculations.
> > > >
> > > > No it can't. At any one point in the function, the stack has to be in
> > > > a well defined state, so that access to local variables can work, and
> > > > also the stack can be correctly unwound. If there exists a point in
> > > > the function body which can be reached where the stack could be in two
> > > > different states, then the stack can't be restored to the parent
> > > > context.
> > >
> > > Actually you can get there with a function that has a lot of args.
> > > So you can have:
> > > if (...) {
> > > push x
> > > bl func
> > > add %sp, #8
> > > }
> > > code;
> > > which is fine.
> >
> > No you can't.... and that isn't even Arm code. Arm doesn't use %sp.
> > Moreover, that "bl" will stomp over the link register, meaning this
> > function can not return.
>
> With 9+ arguments they spill to see https://godbolt.org/z/Yj3ovd8bY
>
> Where the compiler generates:
> f9:
> cmp w0, 0
> ble .L2
> sub sp, sp, #32
> mov w7, w0
> mov w6, w0
> mov w5, w0
> mov w4, w0
> mov w3, w0
> stp x29, x30, [sp, 16]
> add x29, sp, 16
> mov w2, w0
> mov w1, w0
> str w0, [sp]
> bl f
> .L2:
> ret
Don't show me Arm64 assembly when we're discussing Arm32.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v5 14/27] iommu/arm-smmu-v3: Make changing domains be hitless for ATS
From: Michael Shavit @ 2024-03-21 14:53 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: iommu, Joerg Roedel, linux-arm-kernel, Robin Murphy, Will Deacon,
Eric Auger, Jean-Philippe Brucker, Moritz Fischer, Nicolin Chen,
patches, Shameerali Kolothum Thodi
In-Reply-To: <20240321132839.GK1044235@nvidia.com>
On Thu, Mar 21, 2024 at 9:28 PM Jason Gunthorpe <jgg@nvidia.com> wrote:
>
> On Thu, Mar 21, 2024 at 08:26:43PM +0800, Michael Shavit wrote:
> > Overall I think the patch works, but it took me a while to really
> > digest the big picture. Just to make sure I fully understand:
> >
> > We're trying to satisfy the following invariants for correctness:
> > 1. Devices cannot get translations from a domain that was detached
> > after arm_smmu_attach_dev() returns.
>
> Yes, regardless of ATS this is the API requirement.
>
> > 2. Devices cannot get cached translations from a domain after
> > arm_smmu_atc_inv_domain() returns, regardless of whether the domain is
> > simultaneously being attached/detached from a device.
>
> There is no simultaneously here since the group lock is held by the
> core code.
I meant a call to arm_smmu_attach_dev concurrent with
arm_smmu_atc_inv_domain (through tlb_flush_all).
>
> > Apart from note point 2. above, the behaviour of translations while in
> > the middle of an arm_smmu_attach_dev doesn't have well defined
> > requirements:
> > 1. Before this patch, devices may get translations belonging to the
> > old domain, then aborts or identity translations, and then the new
> > domain while arm_smmu_attach_dev() is in progress.
>
> Yes
>
> > 2. Ater this patch, devices may get an arbitrary mix of translations
> > belonging to the old domain and the new domain while
> > arm_smmu_attach_dev() is in progress.
>
> Yes, but no aborts.
>
> > While disabling and re-enabling ATS inside arm_smmu_attach_dev() would
> > meet the same requirements as this patch, it's not optimal since the
> > device may still have traffic on other pasids than the one being
> > manipulated.
>
> Yes, we can't just disable ATS due to the PASIDs. A SVA PASID might be
> present and disabling ATS to change the RID domain would completely
> wreck it. Today this scenario is prevented by sva_enable, which is
> removed in following patches.
What do you mean by wrecking? We might slow it down to a crawl but we
wouldn't be corrupting or destroying anything by disabling ATS while
SVA is running would we?
Oh does disabling ATS abort all transactions rather than making it transparent?
>
> I added this note for context to the commit message:
>
> This is part of the bigger picture to allow changing the RID domain while
> a PASID is in use. If a SVA PASID is relying on ATS to function then
> changing the RID domain cannot just temporarily toggle ATS off without
> also wrecking the SVA PASID. The new infrastructure here is organized so
> that the PASID attach/detach flows will make use of it as well in
> following patches.
>
> Thanks,
> Jason
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/4] dt-bindings: arm: qcom,coresight-funnel: Add label for multi-ouput
From: Suzuki K Poulose @ 2024-03-21 14:52 UTC (permalink / raw)
To: Rob Herring, Tao Zhang
Cc: Mathieu Poirier, Alexander Shishkin, Konrad Dybcio, Mike Leach,
Krzysztof Kozlowski, Jinlong Mao, Leo Yan, Greg Kroah-Hartman,
coresight, linux-arm-kernel, linux-kernel, devicetree,
Tingwei Zhang, Yuanfang Zhang, Trilok Soni, Song Chai,
linux-arm-msm, andersson
In-Reply-To: <20240321144226.GA1689544-robh@kernel.org>
On 21/03/2024 14:42, Rob Herring wrote:
> On Thu, Mar 21, 2024 at 04:32:04PM +0800, Tao Zhang wrote:
>> Add new property "label" to label the source corresponding to the
>> output connection. When the funnel supports multi-output, this
>> property needs to be introduced to mark which source component a
>> certain output connection corresponds to.
>>
>> Signed-off-by: Tao Zhang <quic_taozha@quicinc.com>
>> ---
>> .../arm/arm,coresight-dynamic-funnel.yaml | 34 ++++++++++++++++---
>> 1 file changed, 30 insertions(+), 4 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/arm/arm,coresight-dynamic-funnel.yaml b/Documentation/devicetree/bindings/arm/arm,coresight-dynamic-funnel.yaml
>> index 44a1041cb0fc..cde62c286d29 100644
>> --- a/Documentation/devicetree/bindings/arm/arm,coresight-dynamic-funnel.yaml
>> +++ b/Documentation/devicetree/bindings/arm/arm,coresight-dynamic-funnel.yaml
>> @@ -66,13 +66,39 @@ properties:
>> $ref: /schemas/graph.yaml#/properties/port
>>
>> out-ports:
>> - $ref: /schemas/graph.yaml#/properties/ports
>> - additionalProperties: false
>> -
>> + type: object
>> properties:
>> + "#address-cells":
>> + const: 1
>> +
>> + "#size-cells":
>> + const: 0
>> +
>> port:
>> + type: object
>> +
>> + patternProperties:
>> + '^port(@[0-7])?$':
>> + type: object
>> description: Output connection to CoreSight Trace bus
>> - $ref: /schemas/graph.yaml#/properties/port
>
> Nope, now you have no constraints on port node properties. Please look
> at how other bindings are done to add properties on endpoint node.
>
>> +
>> + patternProperties:
>> + "^endpoint(@[0-9a-f]+)?$":
>> + type: object
>> + properties:
>> + remote-endpoint:
>> + description: |
>> + phandle to an 'endpoint' subnode of a remote device node.
>> + $ref: /schemas/types.yaml#/definitions/phandle
>
> Don't need this.
>
>> + label:
>> + description: Label the source corresponding to the output connection
>> + $ref: /schemas/types.yaml#/definitions/string
>
> label already has a type.
>
> As this node is an output, aren't you labeling what the destination is,
> not the "source"?
>
> Why can't you look at the remote connection to identify what it is?
+1
Suzuki
>
>
>> + oneOf:
>> + - required:
>> + - port
>> + - required:
>> + - "#address-cells"
>> + - "#size-cells"
>
> The common schema that you removed handles this.
>
> Rob
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v5 3/4] firmware: arm_scmi: Add SCMI v3.2 pincontrol protocol basic support
From: Dan Carpenter @ 2024-03-21 14:46 UTC (permalink / raw)
To: Peng Fan (OSS)
Cc: Sudeep Holla, Cristian Marussi, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Oleksii Moisieiev, Linus Walleij, Shawn Guo,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
NXP Linux Team, linux-arm-kernel, linux-kernel, devicetree,
linux-gpio, AKASHI Takahiro, Peng Fan
In-Reply-To: <20240314-pinctrl-scmi-v5-3-b19576e557f2@nxp.com>
On Thu, Mar 14, 2024 at 09:35:20PM +0800, Peng Fan (OSS) wrote:
> +enum scmi_pinctrl_protocol_cmd {
> + PINCTRL_ATTRIBUTES = 0x3,
> + PINCTRL_LIST_ASSOCIATIONS = 0x4,
> + PINCTRL_CONFIG_GET = 0x5,
> + PINCTRL_CONFIG_SET = 0x6,
> + PINCTRL_FUNCTION_SELECT = 0x7,
PINCTRL_FUNCTION_SELECT was removed from the spec so the other cmds were
renumbered. I'm still going through and reviewing this file. I'll
hopefully be done tomorrow.
> + PINCTRL_REQUEST = 0x8,
> + PINCTRL_RELEASE = 0x9,
> + PINCTRL_NAME_GET = 0xa,
> + PINCTRL_SET_PERMISSIONS = 0xb
> +};
> +
[ snip ]
> +static int scmi_pinctrl_attributes(const struct scmi_protocol_handle *ph,
> + enum scmi_pinctrl_selector_type type,
> + u32 selector, char *name,
> + unsigned int *n_elems)
> +{
> + int ret;
> + struct scmi_xfer *t;
> + struct scmi_msg_pinctrl_attributes *tx;
> + struct scmi_resp_pinctrl_attributes *rx;
> +
> + if (!name)
> + return -EINVAL;
> +
> + ret = scmi_pinctrl_validate_id(ph, selector, type);
> + if (ret)
> + return ret;
> +
> + ret = ph->xops->xfer_get_init(ph, PINCTRL_ATTRIBUTES, sizeof(*tx),
> + sizeof(*rx), &t);
> + if (ret)
> + return ret;
> +
> + tx = t->tx.buf;
> + rx = t->rx.buf;
> + tx->identifier = cpu_to_le32(selector);
> + tx->flags = cpu_to_le32(type);
> +
> + ret = ph->xops->do_xfer(ph, t);
> + if (!ret) {
> + if (n_elems)
> + *n_elems = NUM_ELEMS(rx->attributes);
> +
> + strscpy(name, rx->name, SCMI_SHORT_NAME_MAX_SIZE);
> + }
> +
> + ph->xops->xfer_put(ph, t);
> +
> + /*
> + * If supported overwrite short name with the extended one;
> + * on error just carry on and use already provided short name.
> + */
> + if (!ret && EXT_NAME_FLAG(rx->attributes))
^^^^
Dereferencing "rx" after the ph->xops->xfer_put() is a use after free
(racy).
> + ph->hops->extended_name_get(ph, PINCTRL_NAME_GET, selector,
> + (u32 *)&type, name,
> + SCMI_MAX_STR_SIZE);
> + return ret;
> +}
[ snip ]
> +static int scmi_pinctrl_request(const struct scmi_protocol_handle *ph,
> + u32 identifier,
> + enum scmi_pinctrl_selector_type type)
> +{
> + int ret;
> + struct scmi_xfer *t;
> + struct scmi_msg_request *tx;
> +
> + if (type == FUNCTION_TYPE)
> + return -EINVAL;
> +
> + ret = scmi_pinctrl_validate_id(ph, identifier, type);
> + if (ret)
> + return ret;
> +
> + ret = ph->xops->xfer_get_init(ph, PINCTRL_REQUEST, sizeof(*tx), 0, &t);
Missing error check.
if (ret)
return ret;
> +
> + tx = t->tx.buf;
> + tx->identifier = cpu_to_le32(identifier);
> + tx->flags = cpu_to_le32(type);
> +
> + ret = ph->xops->do_xfer(ph, t);
> + ph->xops->xfer_put(ph, t);
> +
> + return ret;
> +}
> +
> +static int scmi_pinctrl_pin_request(const struct scmi_protocol_handle *ph,
> + u32 pin)
> +{
> + return scmi_pinctrl_request(ph, pin, PIN_TYPE);
> +}
> +
> +static int scmi_pinctrl_free(const struct scmi_protocol_handle *ph,
> + u32 identifier,
> + enum scmi_pinctrl_selector_type type)
> +{
> + int ret;
> + struct scmi_xfer *t;
> + struct scmi_msg_request *tx;
> +
> + if (type == FUNCTION_TYPE)
> + return -EINVAL;
> +
> + ret = scmi_pinctrl_validate_id(ph, identifier, type);
> + if (ret)
> + return ret;
> +
> + ret = ph->xops->xfer_get_init(ph, PINCTRL_RELEASE, sizeof(*tx), 0, &t);
if (ret)
return ret;
> +
> + tx = t->tx.buf;
> + tx->identifier = cpu_to_le32(identifier);
> + tx->flags = cpu_to_le32(type);
> +
> + ret = ph->xops->do_xfer(ph, t);
> + ph->xops->xfer_put(ph, t);
> +
> + return ret;
> +}
[ snip ]
> +enum scmi_pinctrl_conf_type {
> + SCMI_PIN_NONE = 0x0,
This is SCMI_PIN_DEFAULT now.
> + SCMI_PIN_BIAS_BUS_HOLD = 0x1,
> + SCMI_PIN_BIAS_DISABLE = 0x2,
> + SCMI_PIN_BIAS_HIGH_IMPEDANCE = 0x3,
> + SCMI_PIN_BIAS_PULL_UP = 0x4,
> + SCMI_PIN_BIAS_PULL_DEFAULT = 0x5,
> + SCMI_PIN_BIAS_PULL_DOWN = 0x6,
> + SCMI_PIN_DRIVE_OPEN_DRAIN = 0x7,
> + SCMI_PIN_DRIVE_OPEN_SOURCE = 0x8,
> + SCMI_PIN_DRIVE_PUSH_PULL = 0x9,
> + SCMI_PIN_DRIVE_STRENGTH = 0xA,
> + SCMI_PIN_INPUT_DEBOUNCE = 0xB,
> + SCMI_PIN_INPUT_MODE = 0xC,
> + SCMI_PIN_PULL_MODE = 0xD,
> + SCMI_PIN_INPUT_VALUE = 0xE,
> + SCMI_PIN_INPUT_SCHMITT = 0xF,
> + SCMI_PIN_LOW_POWER_MODE = 0x10,
> + SCMI_PIN_OUTPUT_MODE = 0x11,
> + SCMI_PIN_OUTPUT_VALUE = 0x12,
> + SCMI_PIN_POWER_SOURCE = 0x13,
> + SCMI_PIN_SLEW_RATE = 0x20,
^^^^
This is a decimal vs hex bug. It should 0x14. I think this enum would
be more readable in decimal anyway.
> + SCMI_PIN_OEM_START = 0xC0,
> + SCMI_PIN_OEM_END = 0xFF,
> +};
But I'm still trying to review the code so I'll probably respond more
tomorrow.
regards,
dan carpenter
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/4] dt-bindings: arm: qcom,coresight-funnel: Add label for multi-ouput
From: Rob Herring @ 2024-03-21 14:42 UTC (permalink / raw)
To: Tao Zhang
Cc: Mathieu Poirier, Suzuki K Poulose, Alexander Shishkin,
Konrad Dybcio, Mike Leach, Krzysztof Kozlowski, Jinlong Mao,
Leo Yan, Greg Kroah-Hartman, coresight, linux-arm-kernel,
linux-kernel, devicetree, Tingwei Zhang, Yuanfang Zhang,
Trilok Soni, Song Chai, linux-arm-msm, andersson
In-Reply-To: <1711009927-17873-2-git-send-email-quic_taozha@quicinc.com>
On Thu, Mar 21, 2024 at 04:32:04PM +0800, Tao Zhang wrote:
> Add new property "label" to label the source corresponding to the
> output connection. When the funnel supports multi-output, this
> property needs to be introduced to mark which source component a
> certain output connection corresponds to.
>
> Signed-off-by: Tao Zhang <quic_taozha@quicinc.com>
> ---
> .../arm/arm,coresight-dynamic-funnel.yaml | 34 ++++++++++++++++---
> 1 file changed, 30 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/arm/arm,coresight-dynamic-funnel.yaml b/Documentation/devicetree/bindings/arm/arm,coresight-dynamic-funnel.yaml
> index 44a1041cb0fc..cde62c286d29 100644
> --- a/Documentation/devicetree/bindings/arm/arm,coresight-dynamic-funnel.yaml
> +++ b/Documentation/devicetree/bindings/arm/arm,coresight-dynamic-funnel.yaml
> @@ -66,13 +66,39 @@ properties:
> $ref: /schemas/graph.yaml#/properties/port
>
> out-ports:
> - $ref: /schemas/graph.yaml#/properties/ports
> - additionalProperties: false
> -
> + type: object
> properties:
> + "#address-cells":
> + const: 1
> +
> + "#size-cells":
> + const: 0
> +
> port:
> + type: object
> +
> + patternProperties:
> + '^port(@[0-7])?$':
> + type: object
> description: Output connection to CoreSight Trace bus
> - $ref: /schemas/graph.yaml#/properties/port
Nope, now you have no constraints on port node properties. Please look
at how other bindings are done to add properties on endpoint node.
> +
> + patternProperties:
> + "^endpoint(@[0-9a-f]+)?$":
> + type: object
> + properties:
> + remote-endpoint:
> + description: |
> + phandle to an 'endpoint' subnode of a remote device node.
> + $ref: /schemas/types.yaml#/definitions/phandle
Don't need this.
> + label:
> + description: Label the source corresponding to the output connection
> + $ref: /schemas/types.yaml#/definitions/string
label already has a type.
As this node is an output, aren't you labeling what the destination is,
not the "source"?
Why can't you look at the remote connection to identify what it is?
> + oneOf:
> + - required:
> + - port
> + - required:
> + - "#address-cells"
> + - "#size-cells"
The common schema that you removed handles this.
Rob
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH net v2 0/2] MT7530 DSA subdriver fix VLAN egress and handling of all link-local frames
From: Jakub Kicinski @ 2024-03-21 14:42 UTC (permalink / raw)
To: Konstantin Ryabitsev
Cc: Arınç ÜNAL, Paolo Abeni, Daniel Golle,
DENG Qingfang, Sean Wang, Andrew Lunn, Florian Fainelli,
Vladimir Oltean, David S. Miller, Eric Dumazet, Matthias Brugger,
AngeloGioacchino Del Regno, netdev, linux-kernel, linux-mediatek,
linux-arm-kernel, Bartel Eerdekens, erkin.bozoglu, mithat.guner
In-Reply-To: <20240321-tentacled-pearl-ferret-efd5be@lemur>
On Thu, 21 Mar 2024 09:19:02 -0400 Konstantin Ryabitsev wrote:
> On Thu, Mar 21, 2024 at 02:29:19PM +0300, Arınç ÜNAL wrote:
> > > For future memory: I think the SoB in the cover letter is not required,
> > > and is, at least to me, a bit confusing.
> > >
> > > No action needed here, I'll keep this unmodified, but I suggest to omit
> > > it in future submission.
> >
> > b4 puts it on the cover letter so it's not my doing.
>
> This is done because many subsystems use the cover letter as the merge commit
> message.
Could be wrong, but I think it was DaveM who originated this practice,
in networking..
> Those subsystems who don't follow this practice don't generally care
> if there's a Signed-Off-By in the cover letter anyway, so I don't see why this
> is a concern that it's there.
Because we have to remove it, extra work. And the benefit of adding it
in the first place is unclear.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 5/5] regulator: rk808: Add RK816 support
From: Alex Bee @ 2024-03-21 14:39 UTC (permalink / raw)
To: Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Heiko Stuebner, Linus Walleij, Liam Girdwood, Mark Brown
Cc: Chris Zhong, Zhang Qing, devicetree, linux-arm-kernel,
linux-rockchip, linux-kernel, linux-gpio, Alex Bee
In-Reply-To: <20240321143911.90210-2-knaerzche@gmail.com>
Add support for rk816 to the exisiting rk808 regulator driver.
The infrastructure of the driver can be re-used as is. A peculiarity for
this version is, that BUCK1/BUCK2 have a (common) bit which needs to
toggled after a voltage change to "confirm" the change. Regulator regmap
takes care of that by defining a apply_bit and apply_reg for those
regulators.
Signed-off-by: Alex Bee <knaerzche@gmail.com>
---
drivers/regulator/rk808-regulator.c | 202 +++++++++++++++++++++++++++-
1 file changed, 201 insertions(+), 1 deletion(-)
diff --git a/drivers/regulator/rk808-regulator.c b/drivers/regulator/rk808-regulator.c
index a6a563e402d0..7a9cd991039b 100644
--- a/drivers/regulator/rk808-regulator.c
+++ b/drivers/regulator/rk808-regulator.c
@@ -158,6 +158,11 @@
RK8XX_DESC_COM(_id, _match, _supply, _min, _max, _step, _vreg, \
_vmask, _ereg, _emask, 0, 0, _etime, &rk808_reg_ops)
+#define RK816_DESC(_id, _match, _supply, _min, _max, _step, _vreg, \
+ _vmask, _ereg, _emask, _disval, _etime) \
+ RK8XX_DESC_COM(_id, _match, _supply, _min, _max, _step, _vreg, \
+ _vmask, _ereg, _emask, _emask, _disval, _etime, &rk816_reg_ops)
+
#define RK817_DESC(_id, _match, _supply, _min, _max, _step, _vreg, \
_vmask, _ereg, _emask, _disval, _etime) \
RK8XX_DESC_COM(_id, _match, _supply, _min, _max, _step, _vreg, \
@@ -258,7 +263,7 @@ static const unsigned int rk808_buck1_2_ramp_table[] = {
2000, 4000, 6000, 10000
};
-/* RK817 RK809 */
+/* RK817/RK809/RK816 (buck 1/2 only) */
static const unsigned int rk817_buck1_4_ramp_table[] = {
3000, 6300, 12500, 25000
};
@@ -640,6 +645,38 @@ static int rk808_set_suspend_disable(struct regulator_dev *rdev)
rdev->desc->enable_mask);
}
+static const struct rk8xx_register_bit rk816_suspend_bits[] = {
+ RK8XX_REG_BIT(RK818_SLEEP_SET_OFF_REG1, 0),
+ RK8XX_REG_BIT(RK818_SLEEP_SET_OFF_REG1, 1),
+ RK8XX_REG_BIT(RK818_SLEEP_SET_OFF_REG1, 2),
+ RK8XX_REG_BIT(RK818_SLEEP_SET_OFF_REG1, 3),
+ RK8XX_REG_BIT(RK818_SLEEP_SET_OFF_REG2, 0),
+ RK8XX_REG_BIT(RK818_SLEEP_SET_OFF_REG2, 1),
+ RK8XX_REG_BIT(RK818_SLEEP_SET_OFF_REG2, 2),
+ RK8XX_REG_BIT(RK818_SLEEP_SET_OFF_REG2, 3),
+ RK8XX_REG_BIT(RK818_SLEEP_SET_OFF_REG2, 4),
+ RK8XX_REG_BIT(RK818_SLEEP_SET_OFF_REG2, 5),
+ RK8XX_REG_BIT(RK818_SLEEP_SET_OFF_REG1, 5),
+ RK8XX_REG_BIT(RK818_SLEEP_SET_OFF_REG1, 6),
+};
+
+static int rk816_set_suspend_enable(struct regulator_dev *rdev)
+{
+ int rid = rdev_get_id(rdev);
+
+ return regmap_update_bits(rdev->regmap, rk816_suspend_bits[rid].reg,
+ rk816_suspend_bits[rid].bit,
+ rk816_suspend_bits[rid].bit);
+}
+
+static int rk816_set_suspend_disable(struct regulator_dev *rdev)
+{
+ int rid = rdev_get_id(rdev);
+
+ return regmap_update_bits(rdev->regmap, rk816_suspend_bits[rid].reg,
+ rk816_suspend_bits[rid].bit, 0);
+}
+
static int rk817_set_suspend_enable_ctrl(struct regulator_dev *rdev,
unsigned int en)
{
@@ -913,6 +950,54 @@ static const struct regulator_ops rk809_buck5_ops_range = {
.set_suspend_disable = rk817_set_suspend_disable,
};
+static const struct regulator_ops rk816_buck1_2_ops_ranges = {
+ .list_voltage = regulator_list_voltage_linear_range,
+ .map_voltage = regulator_map_voltage_linear_range,
+ .get_voltage_sel = regulator_get_voltage_sel_regmap,
+ .set_voltage_sel = regulator_set_voltage_sel_regmap,
+ .set_voltage_time_sel = regulator_set_voltage_time_sel,
+ .enable = regulator_enable_regmap,
+ .disable = regulator_disable_regmap,
+ .is_enabled = regulator_is_enabled_regmap,
+ .set_mode = rk8xx_set_mode,
+ .get_mode = rk8xx_get_mode,
+ .set_suspend_mode = rk8xx_set_suspend_mode,
+ .set_ramp_delay = regulator_set_ramp_delay_regmap,
+ .set_suspend_voltage = rk808_set_suspend_voltage_range,
+ .set_suspend_enable = rk816_set_suspend_enable,
+ .set_suspend_disable = rk816_set_suspend_disable,
+};
+
+static const struct regulator_ops rk816_buck4_ops_ranges = {
+ .list_voltage = regulator_list_voltage_linear_range,
+ .map_voltage = regulator_map_voltage_linear_range,
+ .get_voltage_sel = regulator_get_voltage_sel_regmap,
+ .set_voltage_sel = regulator_set_voltage_sel_regmap,
+ .set_voltage_time_sel = regulator_set_voltage_time_sel,
+ .enable = regulator_enable_regmap,
+ .disable = regulator_disable_regmap,
+ .is_enabled = regulator_is_enabled_regmap,
+ .set_mode = rk8xx_set_mode,
+ .get_mode = rk8xx_get_mode,
+ .set_suspend_mode = rk8xx_set_suspend_mode,
+ .set_suspend_voltage = rk808_set_suspend_voltage_range,
+ .set_suspend_enable = rk816_set_suspend_enable,
+ .set_suspend_disable = rk816_set_suspend_disable,
+};
+
+static const struct regulator_ops rk816_reg_ops = {
+ .list_voltage = regulator_list_voltage_linear,
+ .map_voltage = regulator_map_voltage_linear,
+ .get_voltage_sel = regulator_get_voltage_sel_regmap,
+ .set_voltage_sel = regulator_set_voltage_sel_regmap,
+ .enable = regulator_enable_regmap,
+ .disable = regulator_disable_regmap,
+ .is_enabled = rk8xx_is_enabled_wmsk_regmap,
+ .set_suspend_voltage = rk808_set_suspend_voltage,
+ .set_suspend_enable = rk816_set_suspend_enable,
+ .set_suspend_disable = rk816_set_suspend_disable,
+};
+
static const struct regulator_ops rk817_reg_ops = {
.list_voltage = regulator_list_voltage_linear,
.map_voltage = regulator_map_voltage_linear,
@@ -1392,6 +1477,117 @@ static const struct regulator_desc rk809_reg[] = {
DISABLE_VAL(3)),
};
+static const struct linear_range rk816_buck_4_voltage_ranges[] = {
+ REGULATOR_LINEAR_RANGE(800000, 0, 26, 100000),
+ REGULATOR_LINEAR_RANGE(3500000, 27, 31, 0),
+};
+
+static const struct regulator_desc rk816_reg[] = {
+ {
+ .name = "DCDC_REG1",
+ .supply_name = "vcc1",
+ .of_match = of_match_ptr("DCDC_REG1"),
+ .regulators_node = of_match_ptr("regulators"),
+ .id = RK816_ID_DCDC1,
+ .ops = &rk816_buck1_2_ops_ranges,
+ .type = REGULATOR_VOLTAGE,
+ .n_voltages = 64,
+ .linear_ranges = rk805_buck_1_2_voltage_ranges,
+ .n_linear_ranges = ARRAY_SIZE(rk805_buck_1_2_voltage_ranges),
+ .vsel_reg = RK818_BUCK1_ON_VSEL_REG,
+ .vsel_mask = RK818_BUCK_VSEL_MASK,
+ .apply_reg = RK816_DCDC_EN_REG2,
+ .apply_bit = RK816_BUCK_DVS_CONFIRM,
+ .enable_reg = RK816_DCDC_EN_REG1,
+ .enable_mask = BIT(4) | BIT(0),
+ .enable_val = BIT(4) | BIT(0),
+ .disable_val = BIT(4),
+ .ramp_reg = RK818_BUCK1_CONFIG_REG,
+ .ramp_mask = RK808_RAMP_RATE_MASK,
+ .ramp_delay_table = rk817_buck1_4_ramp_table,
+ .n_ramp_values = ARRAY_SIZE(rk817_buck1_4_ramp_table),
+ .of_map_mode = rk8xx_regulator_of_map_mode,
+ .owner = THIS_MODULE,
+ }, {
+ .name = "DCDC_REG2",
+ .supply_name = "vcc2",
+ .of_match = of_match_ptr("DCDC_REG2"),
+ .regulators_node = of_match_ptr("regulators"),
+ .id = RK816_ID_DCDC2,
+ .ops = &rk816_buck1_2_ops_ranges,
+ .type = REGULATOR_VOLTAGE,
+ .n_voltages = 64,
+ .linear_ranges = rk805_buck_1_2_voltage_ranges,
+ .n_linear_ranges = ARRAY_SIZE(rk805_buck_1_2_voltage_ranges),
+ .vsel_reg = RK818_BUCK2_ON_VSEL_REG,
+ .vsel_mask = RK818_BUCK_VSEL_MASK,
+ .apply_reg = RK816_DCDC_EN_REG2,
+ .apply_bit = RK816_BUCK_DVS_CONFIRM,
+ .enable_reg = RK816_DCDC_EN_REG1,
+ .enable_mask = BIT(5) | BIT(1),
+ .enable_val = BIT(5) | BIT(1),
+ .disable_val = BIT(5),
+ .ramp_reg = RK818_BUCK2_CONFIG_REG,
+ .ramp_mask = RK808_RAMP_RATE_MASK,
+ .ramp_delay_table = rk817_buck1_4_ramp_table,
+ .n_ramp_values = ARRAY_SIZE(rk817_buck1_4_ramp_table),
+ .of_map_mode = rk8xx_regulator_of_map_mode,
+ .owner = THIS_MODULE,
+ }, {
+ .name = "DCDC_REG3",
+ .supply_name = "vcc3",
+ .of_match = of_match_ptr("DCDC_REG3"),
+ .regulators_node = of_match_ptr("regulators"),
+ .id = RK816_ID_DCDC3,
+ .ops = &rk808_switch_ops,
+ .type = REGULATOR_VOLTAGE,
+ .n_voltages = 1,
+ .enable_reg = RK816_DCDC_EN_REG1,
+ .enable_mask = BIT(6) | BIT(2),
+ .enable_val = BIT(6) | BIT(2),
+ .disable_val = BIT(6),
+ .of_map_mode = rk8xx_regulator_of_map_mode,
+ .owner = THIS_MODULE,
+ }, {
+ .name = "DCDC_REG4",
+ .supply_name = "vcc4",
+ .of_match = of_match_ptr("DCDC_REG4"),
+ .regulators_node = of_match_ptr("regulators"),
+ .id = RK816_ID_DCDC4,
+ .ops = &rk816_buck4_ops_ranges,
+ .type = REGULATOR_VOLTAGE,
+ .n_voltages = 32,
+ .linear_ranges = rk816_buck_4_voltage_ranges,
+ .n_linear_ranges = ARRAY_SIZE(rk816_buck_4_voltage_ranges),
+ .vsel_reg = RK818_BUCK4_ON_VSEL_REG,
+ .vsel_mask = RK818_BUCK4_VSEL_MASK,
+ .enable_reg = RK816_DCDC_EN_REG1,
+ .enable_mask = BIT(7) | BIT(3),
+ .enable_val = BIT(7) | BIT(3),
+ .disable_val = BIT(7),
+ .of_map_mode = rk8xx_regulator_of_map_mode,
+ .owner = THIS_MODULE,
+ },
+ RK816_DESC(RK816_ID_LDO1, "LDO_REG1", "vcc5", 800, 3400, 100,
+ RK818_LDO1_ON_VSEL_REG, RK818_LDO_VSEL_MASK,
+ RK816_LDO_EN_REG1, ENABLE_MASK(0), DISABLE_VAL(0), 400),
+ RK816_DESC(RK816_ID_LDO2, "LDO_REG2", "vcc5", 800, 3400, 100,
+ RK818_LDO2_ON_VSEL_REG, RK818_LDO_VSEL_MASK,
+ RK816_LDO_EN_REG1, ENABLE_MASK(1), DISABLE_VAL(1), 400),
+ RK816_DESC(RK816_ID_LDO3, "LDO_REG3", "vcc5", 800, 3400, 100,
+ RK818_LDO3_ON_VSEL_REG, RK818_LDO_VSEL_MASK,
+ RK816_LDO_EN_REG1, ENABLE_MASK(2), DISABLE_VAL(2), 400),
+ RK816_DESC(RK816_ID_LDO4, "LDO_REG4", "vcc6", 800, 3400, 100,
+ RK818_LDO4_ON_VSEL_REG, RK818_LDO_VSEL_MASK,
+ RK816_LDO_EN_REG1, ENABLE_MASK(3), DISABLE_VAL(3), 400),
+ RK816_DESC(RK816_ID_LDO5, "LDO_REG5", "vcc6", 800, 3400, 100,
+ RK818_LDO5_ON_VSEL_REG, RK818_LDO_VSEL_MASK,
+ RK816_LDO_EN_REG2, ENABLE_MASK(0), DISABLE_VAL(0), 400),
+ RK816_DESC(RK816_ID_LDO6, "LDO_REG6", "vcc6", 800, 3400, 100,
+ RK818_LDO6_ON_VSEL_REG, RK818_LDO_VSEL_MASK,
+ RK816_LDO_EN_REG2, ENABLE_MASK(1), DISABLE_VAL(1), 400),
+};
+
static const struct regulator_desc rk817_reg[] = {
{
.name = "DCDC_REG1",
@@ -1714,6 +1910,10 @@ static int rk808_regulator_probe(struct platform_device *pdev)
regulators = rk809_reg;
nregulators = RK809_NUM_REGULATORS;
break;
+ case RK816_ID:
+ regulators = rk816_reg;
+ nregulators = ARRAY_SIZE(rk816_reg);
+ break;
case RK817_ID:
regulators = rk817_reg;
nregulators = RK817_NUM_REGULATORS;
--
2.43.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 4/5] regulator: rk808: Support apply_bit for rk808_set_suspend_voltage_range
From: Alex Bee @ 2024-03-21 14:39 UTC (permalink / raw)
To: Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Heiko Stuebner, Linus Walleij, Liam Girdwood, Mark Brown
Cc: Chris Zhong, Zhang Qing, devicetree, linux-arm-kernel,
linux-rockchip, linux-kernel, linux-gpio, Alex Bee
In-Reply-To: <20240321143911.90210-2-knaerzche@gmail.com>
rk808_set_suspend_voltage_range currently does not account the existence of
apply_bit/apply_reg.
This adds support for those in same way it is done in
regulator_set_voltage_sel_regmap and is required for the upcoming RK816
support
Signed-off-by: Alex Bee <knaerzche@gmail.com>
---
drivers/regulator/rk808-regulator.c | 16 +++++++++++++---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/regulator/rk808-regulator.c b/drivers/regulator/rk808-regulator.c
index d89ae7f16d7a..a6a563e402d0 100644
--- a/drivers/regulator/rk808-regulator.c
+++ b/drivers/regulator/rk808-regulator.c
@@ -534,15 +534,25 @@ static int rk808_set_suspend_voltage_range(struct regulator_dev *rdev, int uv)
{
unsigned int reg;
int sel = regulator_map_voltage_linear_range(rdev, uv, uv);
+ int ret;
if (sel < 0)
return -EINVAL;
reg = rdev->desc->vsel_reg + RK808_SLP_REG_OFFSET;
- return regmap_update_bits(rdev->regmap, reg,
- rdev->desc->vsel_mask,
- sel);
+ ret = regmap_update_bits(rdev->regmap, reg,
+ rdev->desc->vsel_mask,
+ sel);
+ if (ret)
+ return ret;
+
+ if (rdev->desc->apply_bit)
+ ret = regmap_update_bits(rdev->regmap, rdev->desc->apply_reg,
+ rdev->desc->apply_bit,
+ rdev->desc->apply_bit);
+
+ return ret;
}
static int rk805_set_suspend_enable(struct regulator_dev *rdev)
--
2.43.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 3/5] pinctrl: rk805: Add rk816 pinctrl support
From: Alex Bee @ 2024-03-21 14:39 UTC (permalink / raw)
To: Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Heiko Stuebner, Linus Walleij, Liam Girdwood, Mark Brown
Cc: Chris Zhong, Zhang Qing, devicetree, linux-arm-kernel,
linux-rockchip, linux-kernel, linux-gpio, Alex Bee
In-Reply-To: <20240321143911.90210-2-knaerzche@gmail.com>
This adds support for RK816 to the exising rk805 pinctrl driver
It has a single pin which can be configured as input from a thermistor (for
instance in an attached battery) or as a gpio.
Signed-off-by: Alex Bee <knaerzche@gmail.com>
---
drivers/pinctrl/pinctrl-rk805.c | 68 +++++++++++++++++++++++++++++++++
1 file changed, 68 insertions(+)
diff --git a/drivers/pinctrl/pinctrl-rk805.c b/drivers/pinctrl/pinctrl-rk805.c
index 56d916f2cee6..cf0305477e7a 100644
--- a/drivers/pinctrl/pinctrl-rk805.c
+++ b/drivers/pinctrl/pinctrl-rk805.c
@@ -93,6 +93,11 @@ enum rk806_pinmux_option {
RK806_PINMUX_FUN5,
};
+enum rk816_pinmux_option {
+ RK816_PINMUX_GPIO,
+ RK816_PINMUX_TS,
+};
+
enum {
RK805_GPIO0,
RK805_GPIO1,
@@ -104,6 +109,10 @@ enum {
RK806_GPIO_DVS3
};
+enum {
+ RK816_GPIO0,
+};
+
static const char *const rk805_gpio_groups[] = {
"gpio0",
"gpio1",
@@ -115,6 +124,10 @@ static const char *const rk806_gpio_groups[] = {
"gpio_pwrctrl3",
};
+static const char *const rk816_gpio_groups[] = {
+ "gpio0",
+};
+
/* RK805: 2 output only GPIOs */
static const struct pinctrl_pin_desc rk805_pins_desc[] = {
PINCTRL_PIN(RK805_GPIO0, "gpio0"),
@@ -128,6 +141,11 @@ static const struct pinctrl_pin_desc rk806_pins_desc[] = {
PINCTRL_PIN(RK806_GPIO_DVS3, "gpio_pwrctrl3"),
};
+/* RK816 */
+static const struct pinctrl_pin_desc rk816_pins_desc[] = {
+ PINCTRL_PIN(RK816_GPIO0, "gpio0"),
+};
+
static const struct rk805_pin_function rk805_pin_functions[] = {
{
.name = "gpio",
@@ -176,6 +194,21 @@ static const struct rk805_pin_function rk806_pin_functions[] = {
},
};
+static const struct rk805_pin_function rk816_pin_functions[] = {
+ {
+ .name = "gpio",
+ .groups = rk816_gpio_groups,
+ .ngroups = ARRAY_SIZE(rk816_gpio_groups),
+ .mux_option = RK816_PINMUX_GPIO,
+ },
+ {
+ .name = "ts",
+ .groups = rk816_gpio_groups,
+ .ngroups = ARRAY_SIZE(rk816_gpio_groups),
+ .mux_option = RK816_PINMUX_TS,
+ },
+};
+
static const struct rk805_pin_group rk805_pin_groups[] = {
{
.name = "gpio0",
@@ -207,6 +240,14 @@ static const struct rk805_pin_group rk806_pin_groups[] = {
}
};
+static const struct rk805_pin_group rk816_pin_groups[] = {
+ {
+ .name = "gpio0",
+ .pins = { RK816_GPIO0 },
+ .npins = 1,
+ },
+};
+
#define RK805_GPIO0_VAL_MSK BIT(0)
#define RK805_GPIO1_VAL_MSK BIT(1)
@@ -255,6 +296,19 @@ static struct rk805_pin_config rk806_gpio_cfgs[] = {
}
};
+#define RK816_FUN_MASK BIT(2)
+#define RK816_VAL_MASK BIT(3)
+#define RK816_DIR_MASK BIT(4)
+
+static struct rk805_pin_config rk816_gpio_cfgs[] = {
+ {
+ .reg = RK818_IO_POL_REG,
+ .val_msk = RK816_VAL_MASK,
+ .fun_msk = RK816_FUN_MASK,
+ .dir_msk = RK816_DIR_MASK,
+ },
+};
+
/* generic gpio chip */
static int rk805_gpio_get(struct gpio_chip *chip, unsigned int offset)
{
@@ -439,6 +493,8 @@ static int rk805_pinctrl_gpio_request_enable(struct pinctrl_dev *pctldev,
return _rk805_pinctrl_set_mux(pctldev, offset, RK805_PINMUX_GPIO);
case RK806_ID:
return _rk805_pinctrl_set_mux(pctldev, offset, RK806_PINMUX_FUN5);
+ case RK816_ID:
+ return _rk805_pinctrl_set_mux(pctldev, offset, RK816_PINMUX_GPIO);
}
return -ENOTSUPP;
@@ -588,6 +644,18 @@ static int rk805_pinctrl_probe(struct platform_device *pdev)
pci->pin_cfg = rk806_gpio_cfgs;
pci->gpio_chip.ngpio = ARRAY_SIZE(rk806_gpio_cfgs);
break;
+ case RK816_ID:
+ pci->pins = rk816_pins_desc;
+ pci->num_pins = ARRAY_SIZE(rk816_pins_desc);
+ pci->functions = rk816_pin_functions;
+ pci->num_functions = ARRAY_SIZE(rk816_pin_functions);
+ pci->groups = rk816_pin_groups;
+ pci->num_pin_groups = ARRAY_SIZE(rk816_pin_groups);
+ pci->pinctrl_desc.pins = rk816_pins_desc;
+ pci->pinctrl_desc.npins = ARRAY_SIZE(rk816_pins_desc);
+ pci->pin_cfg = rk816_gpio_cfgs;
+ pci->gpio_chip.ngpio = ARRAY_SIZE(rk816_gpio_cfgs);
+ break;
default:
dev_err(&pdev->dev, "unsupported RK805 ID %lu\n",
pci->rk808->variant);
--
2.43.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 2/5] mfd: rk8xx: Add RK816 support
From: Alex Bee @ 2024-03-21 14:39 UTC (permalink / raw)
To: Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Heiko Stuebner, Linus Walleij, Liam Girdwood, Mark Brown
Cc: Chris Zhong, Zhang Qing, devicetree, linux-arm-kernel,
linux-rockchip, linux-kernel, linux-gpio, Alex Bee
In-Reply-To: <20240321143911.90210-2-knaerzche@gmail.com>
This integrates RK816 support in the this existing rk8xx mfd driver.
This version has unaligned interrupt registers, which requires to define a
separate get_irq_reg callback for the regmap. Apart from that the
integration is straightforward and the existing structures can be used as
is. The initialisation sequence has been taken from vendor kernel.
Signed-off-by: Alex Bee <knaerzche@gmail.com>
---
drivers/mfd/Kconfig | 4 +-
drivers/mfd/rk8xx-core.c | 103 ++++++++++++++++++++++++++++
drivers/mfd/rk8xx-i2c.c | 45 +++++++++++-
include/linux/mfd/rk808.h | 141 ++++++++++++++++++++++++++++++++++++++
4 files changed, 290 insertions(+), 3 deletions(-)
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 4b023ee229cf..2e7286cc98e4 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -1225,7 +1225,7 @@ config MFD_RK8XX
select MFD_CORE
config MFD_RK8XX_I2C
- tristate "Rockchip RK805/RK808/RK809/RK817/RK818 Power Management Chip"
+ tristate "Rockchip RK805/RK808/RK809/RK816/RK817/RK818 Power Management Chip"
depends on I2C && OF
select MFD_CORE
select REGMAP_I2C
@@ -1233,7 +1233,7 @@ config MFD_RK8XX_I2C
select MFD_RK8XX
help
If you say yes here you get support for the RK805, RK808, RK809,
- RK817 and RK818 Power Management chips.
+ RK816, RK817 and RK818 Power Management chips.
This driver provides common support for accessing the device
through I2C interface. The device supports multiple sub-devices
including interrupts, RTC, LDO & DCDC regulators, and onkey.
diff --git a/drivers/mfd/rk8xx-core.c b/drivers/mfd/rk8xx-core.c
index e2261b68b844..a616f159d8d4 100644
--- a/drivers/mfd/rk8xx-core.c
+++ b/drivers/mfd/rk8xx-core.c
@@ -28,6 +28,10 @@ static const struct resource rtc_resources[] = {
DEFINE_RES_IRQ(RK808_IRQ_RTC_ALARM),
};
+static const struct resource rk816_rtc_resources[] = {
+ DEFINE_RES_IRQ(RK816_IRQ_RTC_ALARM),
+};
+
static const struct resource rk817_rtc_resources[] = {
DEFINE_RES_IRQ(RK817_IRQ_RTC_ALARM),
};
@@ -87,6 +91,21 @@ static const struct mfd_cell rk808s[] = {
},
};
+static const struct mfd_cell rk816s[] = {
+ { .name = "rk805-pinctrl", },
+ { .name = "rk808-clkout", },
+ { .name = "rk808-regulator", },
+ { .name = "rk805-pwrkey",
+ .num_resources = ARRAY_SIZE(rk805_key_resources),
+ .resources = rk805_key_resources,
+ },
+ {
+ .name = "rk808-rtc",
+ .num_resources = ARRAY_SIZE(rk816_rtc_resources),
+ .resources = rk816_rtc_resources,
+ },
+};
+
static const struct mfd_cell rk817s[] = {
{ .name = "rk808-clkout", },
{ .name = "rk808-regulator", },
@@ -148,6 +167,17 @@ static const struct rk808_reg_data rk808_pre_init_reg[] = {
VB_LO_SEL_3500MV },
};
+static const struct rk808_reg_data rk816_pre_init_reg[] = {
+ { RK818_BUCK1_CONFIG_REG, RK817_RAMP_RATE_MASK,
+ RK817_RAMP_RATE_12_5MV_PER_US },
+ { RK818_BUCK2_CONFIG_REG, RK817_RAMP_RATE_MASK,
+ RK817_RAMP_RATE_12_5MV_PER_US },
+ { RK818_BUCK4_CONFIG_REG, BUCK_ILMIN_MASK, BUCK_ILMIN_250MA },
+ { RK808_THERMAL_REG, TEMP_HOTDIE_MSK, TEMP105C},
+ { RK808_VB_MON_REG, VBAT_LOW_VOL_MASK | VBAT_LOW_ACT_MASK,
+ RK808_VBAT_LOW_3V0 | EN_VABT_LOW_SHUT_DOWN },
+};
+
static const struct rk808_reg_data rk817_pre_init_reg[] = {
{RK817_RTC_CTRL_REG, RTC_STOP, RTC_STOP},
/* Codec specific registers */
@@ -350,6 +380,59 @@ static const struct regmap_irq rk808_irqs[] = {
},
};
+static const unsigned int rk816_irq_status_offsets[] = {
+ (RK816_INT_STS_REG1 - RK816_INT_STS_REG1),
+ (RK816_INT_STS_REG2 - RK816_INT_STS_REG1),
+ (RK816_INT_STS_REG3 - RK816_INT_STS_REG1),
+};
+
+static const unsigned int rk816_irq_mask_offsets[] = {
+ (RK816_INT_STS_MSK_REG1 - RK816_INT_STS_MSK_REG1),
+ (RK816_INT_STS_MSK_REG2 - RK816_INT_STS_MSK_REG1),
+ (RK816_INT_STS_MSK_REG3 - RK816_INT_STS_MSK_REG1),
+};
+
+static const unsigned int rk816_get_irq_reg(struct regmap_irq_chip_data *data,
+ unsigned int base, int index)
+{
+ unsigned int irq_reg = base;
+
+ switch (base) {
+ case RK816_INT_STS_REG1:
+ irq_reg += rk816_irq_status_offsets[index];
+ break;
+ case RK816_INT_STS_MSK_REG1:
+ irq_reg += rk816_irq_mask_offsets[index];
+ break;
+ }
+
+ return irq_reg;
+};
+
+static const struct regmap_irq rk816_irqs[] = {
+ /* INT_STS_REG1 IRQs */
+ REGMAP_IRQ_REG(RK816_IRQ_PWRON_FALL, 0, RK816_INT_STS_PWRON_FALL),
+ REGMAP_IRQ_REG(RK816_IRQ_PWRON_RISE, 0, RK816_INT_STS_PWRON_RISE),
+
+ /* INT_STS_REG2 IRQs */
+ REGMAP_IRQ_REG(RK816_IRQ_VB_LOW, 1, RK816_INT_STS_VB_LOW),
+ REGMAP_IRQ_REG(RK816_IRQ_PWRON, 1, RK816_INT_STS_PWRON),
+ REGMAP_IRQ_REG(RK816_IRQ_PWRON_LP, 1, RK816_INT_STS_PWRON_LP),
+ REGMAP_IRQ_REG(RK816_IRQ_HOTDIE, 1, RK816_INT_STS_HOTDIE),
+ REGMAP_IRQ_REG(RK816_IRQ_RTC_ALARM, 1, RK816_INT_STS_RTC_ALARM),
+ REGMAP_IRQ_REG(RK816_IRQ_RTC_PERIOD, 1, RK816_INT_STS_RTC_PERIOD),
+ REGMAP_IRQ_REG(RK816_IRQ_USB_OV, 1, RK816_INT_STS_USB_OV),
+
+ /* INT_STS3 IRQs */
+ REGMAP_IRQ_REG(RK816_IRQ_PLUG_IN, 2, RK816_INT_STS_PLUG_IN),
+ REGMAP_IRQ_REG(RK816_IRQ_PLUG_OUT, 2, RK816_INT_STS_PLUG_OUT),
+ REGMAP_IRQ_REG(RK816_IRQ_CHG_OK, 2, RK816_INT_STS_CHG_OK),
+ REGMAP_IRQ_REG(RK816_IRQ_CHG_TE, 2, RK816_INT_STS_CHG_TE),
+ REGMAP_IRQ_REG(RK816_IRQ_CHG_TS, 2, RK816_INT_STS_CHG_TS),
+ REGMAP_IRQ_REG(RK816_IRQ_CHG_CVTLIM, 2, RK816_INT_STS_CHG_CVTLIM),
+ REGMAP_IRQ_REG(RK816_IRQ_DISCHG_ILIM, 2, RK816_INT_STS_DISCHG_ILIM),
+};
+
static const struct regmap_irq rk818_irqs[] = {
/* INT_STS */
[RK818_IRQ_VOUT_LO] = {
@@ -482,6 +565,18 @@ static const struct regmap_irq_chip rk808_irq_chip = {
.init_ack_masked = true,
};
+static const struct regmap_irq_chip rk816_irq_chip = {
+ .name = "rk816",
+ .irqs = rk816_irqs,
+ .num_irqs = ARRAY_SIZE(rk816_irqs),
+ .num_regs = 3,
+ .get_irq_reg = rk816_get_irq_reg,
+ .status_base = RK816_INT_STS_REG1,
+ .mask_base = RK816_INT_STS_MSK_REG1,
+ .ack_base = RK816_INT_STS_REG1,
+ .init_ack_masked = true,
+};
+
static struct regmap_irq_chip rk817_irq_chip = {
.name = "rk817",
.irqs = rk817_irqs,
@@ -530,6 +625,7 @@ static int rk808_power_off(struct sys_off_data *data)
reg = RK817_SYS_CFG(3);
bit = DEV_OFF;
break;
+ case RK816_ID:
case RK818_ID:
reg = RK818_DEVCTRL_REG;
bit = DEV_OFF;
@@ -637,6 +733,13 @@ int rk8xx_probe(struct device *dev, int variant, unsigned int irq, struct regmap
cells = rk808s;
nr_cells = ARRAY_SIZE(rk808s);
break;
+ case RK816_ID:
+ rk808->regmap_irq_chip = &rk816_irq_chip;
+ pre_init_reg = rk816_pre_init_reg;
+ nr_pre_init_regs = ARRAY_SIZE(rk816_pre_init_reg);
+ cells = rk816s;
+ nr_cells = ARRAY_SIZE(rk816s);
+ break;
case RK818_ID:
rk808->regmap_irq_chip = &rk818_irq_chip;
pre_init_reg = rk818_pre_init_reg;
diff --git a/drivers/mfd/rk8xx-i2c.c b/drivers/mfd/rk8xx-i2c.c
index 75b5cf09d5a0..69a6b297d723 100644
--- a/drivers/mfd/rk8xx-i2c.c
+++ b/drivers/mfd/rk8xx-i2c.c
@@ -1,6 +1,6 @@
// SPDX-License-Identifier: GPL-2.0-only
/*
- * Rockchip RK808/RK818 Core (I2C) driver
+ * Rockchip RK805/RK808/RK816/RK817/RK818 Core (I2C) driver
*
* Copyright (c) 2014, Fuzhou Rockchip Electronics Co., Ltd
* Copyright (C) 2016 PHYTEC Messtechnik GmbH
@@ -49,6 +49,35 @@ static bool rk808_is_volatile_reg(struct device *dev, unsigned int reg)
return false;
}
+static bool rk816_is_volatile_reg(struct device *dev, unsigned int reg)
+{
+ /*
+ * Technically the ROUND_30s bit makes RTC_CTRL_REG volatile, but
+ * we don't use that feature. It's better to cache.
+ */
+
+ switch (reg) {
+ case RK808_SECONDS_REG ... RK808_WEEKS_REG:
+ case RK808_RTC_STATUS_REG:
+ case RK808_VB_MON_REG:
+ case RK808_THERMAL_REG:
+ case RK816_DCDC_EN_REG1:
+ case RK816_DCDC_EN_REG2:
+ case RK816_INT_STS_REG1:
+ case RK816_INT_STS_REG2:
+ case RK816_INT_STS_REG3:
+ case RK808_DEVCTRL_REG:
+ case RK816_SUP_STS_REG:
+ case RK816_GGSTS_REG:
+ case RK816_ZERO_CUR_ADC_REGH:
+ case RK816_ZERO_CUR_ADC_REGL:
+ case RK816_GASCNT_REG(0) ... RK816_BAT_VOL_REGL:
+ return true;
+ }
+
+ return false;
+}
+
static bool rk817_is_volatile_reg(struct device *dev, unsigned int reg)
{
/*
@@ -100,6 +129,14 @@ static const struct regmap_config rk808_regmap_config = {
.volatile_reg = rk808_is_volatile_reg,
};
+static const struct regmap_config rk816_regmap_config = {
+ .reg_bits = 8,
+ .val_bits = 8,
+ .max_register = RK816_DATA_REG(18),
+ .cache_type = REGCACHE_MAPLE,
+ .volatile_reg = rk816_is_volatile_reg,
+};
+
static const struct regmap_config rk817_regmap_config = {
.reg_bits = 8,
.val_bits = 8,
@@ -123,6 +160,11 @@ static const struct rk8xx_i2c_platform_data rk809_data = {
.variant = RK809_ID,
};
+static const struct rk8xx_i2c_platform_data rk816_data = {
+ .regmap_cfg = &rk816_regmap_config,
+ .variant = RK816_ID,
+};
+
static const struct rk8xx_i2c_platform_data rk817_data = {
.regmap_cfg = &rk817_regmap_config,
.variant = RK817_ID,
@@ -161,6 +203,7 @@ static const struct of_device_id rk8xx_i2c_of_match[] = {
{ .compatible = "rockchip,rk805", .data = &rk805_data },
{ .compatible = "rockchip,rk808", .data = &rk808_data },
{ .compatible = "rockchip,rk809", .data = &rk809_data },
+ { .compatible = "rockchip,rk816", .data = &rk816_data },
{ .compatible = "rockchip,rk817", .data = &rk817_data },
{ .compatible = "rockchip,rk818", .data = &rk818_data },
{ },
diff --git a/include/linux/mfd/rk808.h b/include/linux/mfd/rk808.h
index 78e167a92483..8b27fb2fafa8 100644
--- a/include/linux/mfd/rk808.h
+++ b/include/linux/mfd/rk808.h
@@ -113,6 +113,145 @@ enum rk808_reg {
#define RK808_INT_STS_MSK_REG2 0x4f
#define RK808_IO_POL_REG 0x50
+/* RK816 */
+enum rk816_reg {
+ RK816_ID_DCDC1,
+ RK816_ID_DCDC2,
+ RK816_ID_DCDC3,
+ RK816_ID_DCDC4,
+ RK816_ID_LDO1,
+ RK816_ID_LDO2,
+ RK816_ID_LDO3,
+ RK816_ID_LDO4,
+ RK816_ID_LDO5,
+ RK816_ID_LDO6,
+ RK816_ID_BOOST,
+ RK816_ID_OTG_SW,
+};
+
+enum rk816_irqs {
+ /* INT_STS_REG1 */
+ RK816_IRQ_PWRON_FALL,
+ RK816_IRQ_PWRON_RISE,
+
+ /* INT_STS_REG2 */
+ RK816_IRQ_VB_LOW,
+ RK816_IRQ_PWRON,
+ RK816_IRQ_PWRON_LP,
+ RK816_IRQ_HOTDIE,
+ RK816_IRQ_RTC_ALARM,
+ RK816_IRQ_RTC_PERIOD,
+ RK816_IRQ_USB_OV,
+
+ /* INT_STS_REG3 */
+ RK816_IRQ_PLUG_IN,
+ RK816_IRQ_PLUG_OUT,
+ RK816_IRQ_CHG_OK,
+ RK816_IRQ_CHG_TE,
+ RK816_IRQ_CHG_TS,
+ RK816_IRQ_CHG_CVTLIM,
+ RK816_IRQ_DISCHG_ILIM,
+};
+
+/* power channel registers */
+#define RK816_DCDC_EN_REG1 0x23
+
+#define RK816_DCDC_EN_REG2 0x24
+#define RK816_BOOST_EN BIT(1)
+#define RK816_OTG_EN BIT(2)
+#define RK816_BOOST_EN_MSK BIT(5)
+#define RK816_OTG_EN_MSK BIT(6)
+#define RK816_BUCK_DVS_CONFIRM BIT(7)
+
+#define RK816_LDO_EN_REG1 0x27
+
+#define RK816_LDO_EN_REG2 0x28
+
+/*interrupt registers and irq definitions*/
+#define RK816_INT_STS_REG1 0x49
+#define RK816_INT_STS_MSK_REG1 0x4a
+#define RK816_INT_STS_PWRON_FALL BIT(5)
+#define RK816_INT_STS_PWRON_RISE BIT(6)
+
+#define RK816_INT_STS_REG2 0x4c
+#define RK816_INT_STS_MSK_REG2 0x4d
+#define RK816_INT_STS_VB_LOW BIT(1)
+#define RK816_INT_STS_PWRON BIT(2)
+#define RK816_INT_STS_PWRON_LP BIT(3)
+#define RK816_INT_STS_HOTDIE BIT(4)
+#define RK816_INT_STS_RTC_ALARM BIT(5)
+#define RK816_INT_STS_RTC_PERIOD BIT(6)
+#define RK816_INT_STS_USB_OV BIT(7)
+
+#define RK816_INT_STS_REG3 0x4e
+#define RK816_INT_STS_MSK_REG3 0x4f
+#define RK816_INT_STS_PLUG_IN BIT(0)
+#define RK816_INT_STS_PLUG_OUT BIT(1)
+#define RK816_INT_STS_CHG_OK BIT(2)
+#define RK816_INT_STS_CHG_TE BIT(3)
+#define RK816_INT_STS_CHG_TS BIT(4)
+#define RK816_INT_STS_CHG_CVTLIM BIT(6)
+#define RK816_INT_STS_DISCHG_ILIM BIT(7)
+
+/* charger, boost and OTG registers */
+#define RK816_OTG_BUCK_LDO_CONFIG_REG 0x2a
+#define RK816_CHRG_CONFIG_REG 0x2b
+#define RK816_BOOST_ON_VESL_REG 0x54
+#define RK816_BOOST_SLP_VSEL_REG 0x55
+#define RK816_CHRG_BOOST_CONFIG_REG 0x9a
+#define RK816_SUP_STS_REG 0xa0
+#define RK816_USB_CTRL_REG 0xa1
+#define RK816_CHRG_CTRL(x) (0xa3 + (x))
+#define RK816_BAT_CTRL_REG 0xa6
+#define RK816_BAT_HTS_TS_REG 0xa8
+#define RK816_BAT_LTS_TS_REG 0xa9
+
+/* adc and fuel gauge registers */
+#define RK816_TS_CTRL_REG 0xac
+#define RK816_ADC_CTRL_REG 0xad
+#define RK816_GGCON_REG 0xb0
+#define RK816_GGSTS_REG 0xb1
+#define RK816_ZERO_CUR_ADC_REGH 0xb2
+#define RK816_ZERO_CUR_ADC_REGL 0xb3
+#define RK816_GASCNT_CAL_REG(x) (0xb7 - (x))
+#define RK816_GASCNT_REG(x) (0xbb - (x))
+#define RK816_BAT_CUR_AVG_REGH 0xbc
+#define RK816_BAT_CUR_AVG_REGL 0xbd
+#define RK816_TS_ADC_REGH 0xbe
+#define RK816_TS_ADC_REGL 0xbf
+#define RK816_USB_ADC_REGH 0xc0
+#define RK816_USB_ADC_REGL 0xc1
+#define RK816_BAT_OCV_REGH 0xc2
+#define RK816_BAT_OCV_REGL 0xc3
+#define RK816_BAT_VOL_REGH 0xc4
+#define RK816_BAT_VOL_REGL 0xc5
+#define RK816_RELAX_ENTRY_THRES_REGH 0xc6
+#define RK816_RELAX_ENTRY_THRES_REGL 0xc7
+#define RK816_RELAX_EXIT_THRES_REGH 0xc8
+#define RK816_RELAX_EXIT_THRES_REGL 0xc9
+#define RK816_RELAX_VOL1_REGH 0xca
+#define RK816_RELAX_VOL1_REGL 0xcb
+#define RK816_RELAX_VOL2_REGH 0xcc
+#define RK816_RELAX_VOL2_REGL 0xcd
+#define RK816_RELAX_CUR1_REGH 0xce
+#define RK816_RELAX_CUR1_REGL 0xcf
+#define RK816_RELAX_CUR2_REGH 0xd0
+#define RK816_RELAX_CUR2_REGL 0xd1
+#define RK816_CAL_OFFSET_REGH 0xd2
+#define RK816_CAL_OFFSET_REGL 0xd3
+#define RK816_NON_ACT_TIMER_CNT_REG 0xd4
+#define RK816_VCALIB0_REGH 0xd5
+#define RK816_VCALIB0_REGL 0xd6
+#define RK816_VCALIB1_REGH 0xd7
+#define RK816_VCALIB1_REGL 0xd8
+#define RK816_FCC_GASCNT_REG(x) (0xdc - (x))
+#define RK816_IOFFSET_REGH 0xdd
+#define RK816_IOFFSET_REGL 0xde
+#define RK816_SLEEP_CON_SAMP_CUR_REG 0xdf
+
+/* general purpose data registers 0xe0 ~ 0xf2 */
+#define RK816_DATA_REG(x) (0xe0 + (x))
+
/* RK818 */
#define RK818_DCDC1 0
#define RK818_LDO1 4
@@ -791,6 +930,7 @@ enum rk806_dvs_mode {
#define VOUT_LO_INT BIT(0)
#define CLK32KOUT2_EN BIT(0)
+#define TEMP105C 0x08
#define TEMP115C 0x0c
#define TEMP_HOTDIE_MSK 0x0c
#define SLP_SD_MSK (0x3 << 2)
@@ -1191,6 +1331,7 @@ enum {
RK806_ID = 0x8060,
RK808_ID = 0x0000,
RK809_ID = 0x8090,
+ RK816_ID = 0x8160,
RK817_ID = 0x8170,
RK818_ID = 0x8180,
};
--
2.43.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 1/5] dt-bindings: mfd: Add rk816 binding
From: Alex Bee @ 2024-03-21 14:39 UTC (permalink / raw)
To: Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Heiko Stuebner, Linus Walleij, Liam Girdwood, Mark Brown
Cc: Chris Zhong, Zhang Qing, devicetree, linux-arm-kernel,
linux-rockchip, linux-kernel, linux-gpio, Alex Bee
In-Reply-To: <20240321143911.90210-2-knaerzche@gmail.com>
Add DT binding document for Rockchip's RK816 PMIC
Signed-off-by: Alex Bee <knaerzche@gmail.com>
---
.../bindings/mfd/rockchip,rk816.yaml | 259 ++++++++++++++++++
1 file changed, 259 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/rockchip,rk816.yaml
diff --git a/Documentation/devicetree/bindings/mfd/rockchip,rk816.yaml b/Documentation/devicetree/bindings/mfd/rockchip,rk816.yaml
new file mode 100644
index 000000000000..b46de99f60ff
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/rockchip,rk816.yaml
@@ -0,0 +1,259 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/rockchip,rk816.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: RK816 Power Management Integrated Circuit
+
+maintainers:
+ - Chris Zhong <zyw@rock-chips.com>
+ - Zhang Qing <zhangqing@rock-chips.com>
+
+description: |
+ Rockchip RK816 series PMIC. This device consists of an i2c controlled MFD
+ that includes regulators, a RTC, a gpio controller, and a power button.
+
+properties:
+ compatible:
+ enum:
+ - rockchip,rk816
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ '#clock-cells':
+ description: |
+ See <dt-bindings/clock/rockchip,rk808.h> for clock IDs.
+ const: 1
+
+ clock-output-names:
+ description:
+ From common clock binding to override the default output clock name.
+ maxItems: 2
+
+ gpio-controller: true
+
+ '#gpio-cells':
+ const: 2
+
+ system-power-controller:
+ type: boolean
+ description:
+ Telling whether or not this PMIC is controlling the system power.
+
+ wakeup-source:
+ type: boolean
+ description:
+ Device can be used as a wakeup source.
+
+ vcc1-supply:
+ description:
+ The input supply for DCDC_REG1.
+
+ vcc2-supply:
+ description:
+ The input supply for DCDC_REG2.
+
+ vcc3-supply:
+ description:
+ The input supply for DCDC_REG3.
+
+ vcc4-supply:
+ description:
+ The input supply for DCDC_REG4.
+
+ vcc5-supply:
+ description:
+ The input supply for LDO_REG1, LDO_REG2, and LDO_REG3.
+
+ vcc6-supply:
+ description:
+ The input supply for LDO_REG4, LDO_REG5, and LDO_REG6.
+
+ vcc7-supply:
+ description:
+ The input supply for BOOST.
+
+ vcc8-supply:
+ description:
+ The input supply for OTG_SWITCH.
+
+ regulators:
+ type: object
+ patternProperties:
+ "^(DCDC_REG[1-4]|LDO_REG[1-6]|BOOST|OTG_SWITCH)$":
+ type: object
+ $ref: ../regulator/regulator.yaml#
+ unevaluatedProperties: false
+ unevaluatedProperties: false
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - "#clock-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/pinctrl/rockchip.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/gpio/gpio.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ rk816: pmic@1a {
+ compatible = "rockchip,rk816";
+ reg = <0x1a>;
+ interrupt-parent = <&gpio0>;
+ interrupts = <RK_PA2 IRQ_TYPE_LEVEL_LOW>;
+
+ clock-output-names = "xin32k", "rk816-clkout2";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pmic_int_l>;
+ gpio-controller;
+ system-power-controller;
+ wakeup-source;
+ #clock-cells = <1>;
+ #gpio-cells = <2>;
+
+ vcc1-supply = <&vcc_sys>;
+ vcc2-supply = <&vcc_sys>;
+ vcc3-supply = <&vcc_sys>;
+ vcc4-supply = <&vcc_sys>;
+ vcc5-supply = <&vcc33_io>;
+ vcc6-supply = <&vcc_sys>;
+
+ regulators {
+ vdd_cpu: DCDC_REG1 {
+ regulator-name = "vdd_cpu";
+ regulator-min-microvolt = <750000>;
+ regulator-max-microvolt = <1450000>;
+ regulator-ramp-delay = <6001>;
+ regulator-initial-mode = <1>;
+ regulator-always-on;
+ regulator-boot-on;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdd_logic: DCDC_REG2 {
+ regulator-name = "vdd_logic";
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <1250000>;
+ regulator-ramp-delay = <6001>;
+ regulator-initial-mode = <1>;
+ regulator-always-on;
+ regulator-boot-on;
+
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <1000000>;
+ };
+ };
+
+ vcc_ddr: DCDC_REG3 {
+ regulator-name = "vcc_ddr";
+ regulator-initial-mode = <1>;
+ regulator-always-on;
+ regulator-boot-on;
+
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ };
+ };
+
+ vcc33_io: DCDC_REG4 {
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-name = "vcc33_io";
+ regulator-initial-mode = <1>;
+ regulator-always-on;
+ regulator-boot-on;
+
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <3300000>;
+ };
+ };
+
+ vccio_pmu: LDO_REG1 {
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-name = "vccio_pmu";
+ regulator-always-on;
+ regulator-boot-on;
+
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <3300000>;
+ };
+ };
+
+ vcc_tp: LDO_REG2 {
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-name = "vcc_tp";
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdd_10: LDO_REG3 {
+ regulator-min-microvolt = <1000000>;
+ regulator-max-microvolt = <1000000>;
+ regulator-name = "vdd_10";
+ regulator-always-on;
+ regulator-boot-on;
+
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <1000000>;
+ };
+ };
+
+ vcc18_lcd: LDO_REG4 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-name = "vcc18_lcd";
+
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <1800000>;
+ };
+ };
+
+ vccio_sd: LDO_REG5 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-name = "vccio_sd";
+
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <3300000>;
+ };
+ };
+
+ vdd10_lcd: LDO_REG6 {
+ regulator-min-microvolt = <1000000>;
+ regulator-max-microvolt = <1000000>;
+ regulator-name = "vdd10_lcd";
+
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <1000000>;
+ };
+ };
+ };
+ };
+ };
--
2.43.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 0/5] Add RK816 PMIC support
From: Alex Bee @ 2024-03-21 14:39 UTC (permalink / raw)
To: Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Heiko Stuebner, Linus Walleij, Liam Girdwood, Mark Brown
Cc: Chris Zhong, Zhang Qing, devicetree, linux-arm-kernel,
linux-rockchip, linux-kernel, linux-gpio, Alex Bee
This series aims to add support for Rockchip RK816 PMIC series. As per
datasheet it's targeted for RK3126/RK3128 (RK816-1), RK1108 (RK816-2) and
PX3-SE (RK816-3) but might be used for other SoCs as well. The mfd consists
of an integrated RTC, a GPIO controller, two 32k clock outputs, a power key
(output), 4 buck- and 5 ldo regulators, 3 regulator-switches, and charger
with integrated fuel gauge. Charger and fuel gauge are not part of this
series. Two of the switches (otg/boost) are part of the binding, but not of
the driver. They must only ever by enabled if no battery charging is
happening, but it will be enabled automatically if a battery is attached.
Thus they need some incorporation of a yet to be added charger driver.
Integration in the existing rk8xx-infrastructure was pretty straightforward
and only needed very little tweaking. In order to not further bloat the
driver(s) too much with additional definitions I tried to re-use existing
ones wherever possible.
The patches are loosely based on the vendor's implementation, verified
against the datasheet and tested/measured on RK3126 board. As they are
touching several subsystems I'm sending them (very) early for the
6.10-cycle.
Alex Bee (5):
dt-bindings: mfd: Add rk816 binding
mfd: rk8xx: Add RK816 support
pinctrl: rk805: Add rk816 pinctrl support
regulator: rk808: Support apply_bit for
rk808_set_suspend_voltage_range
regulator: rk808: Add RK816 support
.../bindings/mfd/rockchip,rk816.yaml | 259 ++++++++++++++++++
drivers/mfd/Kconfig | 4 +-
drivers/mfd/rk8xx-core.c | 103 +++++++
drivers/mfd/rk8xx-i2c.c | 45 ++-
drivers/pinctrl/pinctrl-rk805.c | 68 +++++
drivers/regulator/rk808-regulator.c | 218 ++++++++++++++-
include/linux/mfd/rk808.h | 141 ++++++++++
7 files changed, 831 insertions(+), 7 deletions(-)
create mode 100644 Documentation/devicetree/bindings/mfd/rockchip,rk816.yaml
--
2.43.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox