* [PATCH v2 4/9] dt-bindings: input: microchip,cap11xx: Add microchip,cap1126 LED reg constraints
From: Jun Yan @ 2026-06-12 7:22 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Jun Yan, linux-input, devicetree, linux-kernel
In-Reply-To: <20260612072237.1177304-1-jerrysteve1101@gmail.com>
Apply per-chip LED channel limits:
- CAP1126: max 2 channels (0-1)
- CAP1188: max 8 channels (0-7)
- CAP1106, CAP12xx: no LED support
Signed-off-by: Jun Yan <jerrysteve1101@gmail.com>
---
.../bindings/input/microchip,cap11xx.yaml | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/Documentation/devicetree/bindings/input/microchip,cap11xx.yaml b/Documentation/devicetree/bindings/input/microchip,cap11xx.yaml
index 9578c7c206a2..22a292d4a880 100644
--- a/Documentation/devicetree/bindings/input/microchip,cap11xx.yaml
+++ b/Documentation/devicetree/bindings/input/microchip,cap11xx.yaml
@@ -171,6 +171,19 @@ allOf:
patternProperties:
"^led@": false
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - microchip,cap1126
+ then:
+ patternProperties:
+ "^led@":
+ properties:
+ reg:
+ maximum: 1
+
- if:
properties:
compatible:
--
2.54.0
^ permalink raw reply related
* [PATCH v2 3/9] dt-bindings: input: microchip,cap11xx: Update datasheet URL and LED reg range
From: Jun Yan @ 2026-06-12 7:22 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Jun Yan, linux-input, devicetree, linux-kernel
In-Reply-To: <20260612072237.1177304-1-jerrysteve1101@gmail.com>
- Add datasheet links for all supported CAP11xx variants.
- Update LED node regex and replace enum constraints with minimum/maximum
for LED reg ranges in preparation for CAP1114 support.
CAP1114 has 11 LED channels. minimum/maximum constraints are easier to
maintain than long enum lists when expanding channel count later.
Signed-off-by: Jun Yan <jerrysteve1101@gmail.com>
---
.../bindings/input/microchip,cap11xx.yaml | 17 ++++++++++++++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/input/microchip,cap11xx.yaml b/Documentation/devicetree/bindings/input/microchip,cap11xx.yaml
index 7ade03f1b32b..9578c7c206a2 100644
--- a/Documentation/devicetree/bindings/input/microchip,cap11xx.yaml
+++ b/Documentation/devicetree/bindings/input/microchip,cap11xx.yaml
@@ -10,6 +10,15 @@ description: |
The Microchip CAP1xxx Family of RightTouchTM multiple-channel capacitive
touch controllers and LED drivers. The device communication via I2C only.
+ For more product information please see the links below:
+ CAP1106: https://ww1.microchip.com/downloads/en/DeviceDoc/00001624B.pdf
+ CAP1126: https://ww1.microchip.com/downloads/en/DeviceDoc/00001623B.pdf
+ CAP1188: https://ww1.microchip.com/downloads/en/DeviceDoc/00001620C.pdf
+ CAP1203: https://ww1.microchip.com/downloads/en/DeviceDoc/00001572B.pdf
+ CAP1206: https://ww1.microchip.com/downloads/en/DeviceDoc/00001567B.pdf
+ CAP1293: https://ww1.microchip.com/downloads/en/DeviceDoc/00001566B.pdf
+ CAP1298: https://ww1.microchip.com/downloads/en/DeviceDoc/00001571B.pdf
+
maintainers:
- Rob Herring <robh@kernel.org>
@@ -124,14 +133,16 @@ properties:
The number of entries must correspond to the number of channels.
patternProperties:
- "^led@[0-7]$":
+ "^led@[0-9a-f]$":
type: object
description: CAP11xx LEDs
$ref: /schemas/leds/common.yaml#
properties:
reg:
- enum: [0, 1, 2, 3, 4, 5, 6, 7]
+ description: LED channel number
+ minimum: 0
+ maximum: 7
label: true
@@ -158,7 +169,7 @@ allOf:
- microchip,cap1298
then:
patternProperties:
- "^led@[0-7]$": false
+ "^led@": false
- if:
properties:
--
2.54.0
^ permalink raw reply related
* [PATCH v2 2/9] Input: cap11xx - remove unused register macros
From: Jun Yan @ 2026-06-12 7:22 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Jun Yan, linux-input, devicetree, linux-kernel
In-Reply-To: <20260612072237.1177304-1-jerrysteve1101@gmail.com>
Remove unused register address macros and unused definitions in
the cap11xx_reg_defaults array and cap11xx_volatile_reg.
This cleanup reduces code clutter and makes the driver easier to
maintain without affecting functionality.
Signed-off-by: Jun Yan <jerrysteve1101@gmail.com>
---
drivers/input/keyboard/cap11xx.c | 58 --------------------------------
1 file changed, 58 deletions(-)
diff --git a/drivers/input/keyboard/cap11xx.c b/drivers/input/keyboard/cap11xx.c
index 485d8ba97723..686174722204 100644
--- a/drivers/input/keyboard/cap11xx.c
+++ b/drivers/input/keyboard/cap11xx.c
@@ -20,53 +20,23 @@
#define CAP11XX_REG_MAIN_CONTROL_GAIN_SHIFT (6)
#define CAP11XX_REG_MAIN_CONTROL_GAIN_MASK (0xc0)
#define CAP11XX_REG_MAIN_CONTROL_DLSEEP BIT(4)
-#define CAP11XX_REG_GENERAL_STATUS 0x02
#define CAP11XX_REG_SENSOR_INPUT 0x03
-#define CAP11XX_REG_NOISE_FLAG_STATUS 0x0a
-#define CAP11XX_REG_SENOR_DELTA(X) (0x10 + (X))
#define CAP11XX_REG_SENSITIVITY_CONTROL 0x1f
#define CAP11XX_REG_SENSITIVITY_CONTROL_DELTA_SENSE_MASK 0x70
-#define CAP11XX_REG_CONFIG 0x20
-#define CAP11XX_REG_SENSOR_ENABLE 0x21
-#define CAP11XX_REG_SENSOR_CONFIG 0x22
-#define CAP11XX_REG_SENSOR_CONFIG2 0x23
-#define CAP11XX_REG_SAMPLING_CONFIG 0x24
-#define CAP11XX_REG_CALIBRATION 0x26
-#define CAP11XX_REG_INT_ENABLE 0x27
#define CAP11XX_REG_REPEAT_RATE 0x28
#define CAP11XX_REG_SIGNAL_GUARD_ENABLE 0x29
-#define CAP11XX_REG_MT_CONFIG 0x2a
-#define CAP11XX_REG_MT_PATTERN_CONFIG 0x2b
-#define CAP11XX_REG_MT_PATTERN 0x2d
-#define CAP11XX_REG_RECALIB_CONFIG 0x2f
#define CAP11XX_REG_SENSOR_THRESH(X) (0x30 + (X))
-#define CAP11XX_REG_SENSOR_NOISE_THRESH 0x38
-#define CAP11XX_REG_STANDBY_CHANNEL 0x40
-#define CAP11XX_REG_STANDBY_CONFIG 0x41
-#define CAP11XX_REG_STANDBY_SENSITIVITY 0x42
-#define CAP11XX_REG_STANDBY_THRESH 0x43
#define CAP11XX_REG_CONFIG2 0x44
#define CAP11XX_REG_CONFIG2_ALT_POL BIT(6)
-#define CAP11XX_REG_SENSOR_BASE_CNT(X) (0x50 + (X))
-#define CAP11XX_REG_LED_POLARITY 0x73
#define CAP11XX_REG_LED_OUTPUT_CONTROL 0x74
#define CAP11XX_REG_CALIB_SENSITIVITY_CONFIG 0x80
#define CAP11XX_REG_CALIB_SENSITIVITY_CONFIG2 0x81
-
-#define CAP11XX_REG_LED_DUTY_CYCLE_1 0x90
-#define CAP11XX_REG_LED_DUTY_CYCLE_2 0x91
-#define CAP11XX_REG_LED_DUTY_CYCLE_3 0x92
#define CAP11XX_REG_LED_DUTY_CYCLE_4 0x93
-#define CAP11XX_REG_LED_DUTY_MIN_MASK (0x0f)
-#define CAP11XX_REG_LED_DUTY_MIN_MASK_SHIFT (0)
#define CAP11XX_REG_LED_DUTY_MAX_MASK (0xf0)
#define CAP11XX_REG_LED_DUTY_MAX_MASK_SHIFT (4)
#define CAP11XX_REG_LED_DUTY_MAX_VALUE (15)
-#define CAP11XX_REG_SENSOR_CALIB (0xb1 + (X))
-#define CAP11XX_REG_SENSOR_CALIB_LSB1 0xb9
-#define CAP11XX_REG_SENSOR_CALIB_LSB2 0xba
#define CAP11XX_REG_PRODUCT_ID 0xfd
#define CAP11XX_REG_MANUFACTURER_ID 0xfe
#define CAP11XX_REG_REVISION 0xff
@@ -111,37 +81,15 @@ struct cap11xx_hw_model {
static const struct reg_default cap11xx_reg_defaults[] = {
{ CAP11XX_REG_MAIN_CONTROL, 0x00 },
- { CAP11XX_REG_GENERAL_STATUS, 0x00 },
- { CAP11XX_REG_SENSOR_INPUT, 0x00 },
- { CAP11XX_REG_NOISE_FLAG_STATUS, 0x00 },
{ CAP11XX_REG_SENSITIVITY_CONTROL, 0x2f },
- { CAP11XX_REG_CONFIG, 0x20 },
- { CAP11XX_REG_SENSOR_ENABLE, 0x3f },
- { CAP11XX_REG_SENSOR_CONFIG, 0xa4 },
- { CAP11XX_REG_SENSOR_CONFIG2, 0x07 },
- { CAP11XX_REG_SAMPLING_CONFIG, 0x39 },
- { CAP11XX_REG_CALIBRATION, 0x00 },
- { CAP11XX_REG_INT_ENABLE, 0x3f },
{ CAP11XX_REG_REPEAT_RATE, 0x3f },
- { CAP11XX_REG_MT_CONFIG, 0x80 },
- { CAP11XX_REG_MT_PATTERN_CONFIG, 0x00 },
- { CAP11XX_REG_MT_PATTERN, 0x3f },
- { CAP11XX_REG_RECALIB_CONFIG, 0x8a },
{ CAP11XX_REG_SENSOR_THRESH(0), 0x40 },
{ CAP11XX_REG_SENSOR_THRESH(1), 0x40 },
{ CAP11XX_REG_SENSOR_THRESH(2), 0x40 },
{ CAP11XX_REG_SENSOR_THRESH(3), 0x40 },
{ CAP11XX_REG_SENSOR_THRESH(4), 0x40 },
{ CAP11XX_REG_SENSOR_THRESH(5), 0x40 },
- { CAP11XX_REG_SENSOR_NOISE_THRESH, 0x01 },
- { CAP11XX_REG_STANDBY_CHANNEL, 0x00 },
- { CAP11XX_REG_STANDBY_CONFIG, 0x39 },
- { CAP11XX_REG_STANDBY_SENSITIVITY, 0x02 },
- { CAP11XX_REG_STANDBY_THRESH, 0x40 },
{ CAP11XX_REG_CONFIG2, 0x40 },
- { CAP11XX_REG_LED_POLARITY, 0x00 },
- { CAP11XX_REG_SENSOR_CALIB_LSB1, 0x00 },
- { CAP11XX_REG_SENSOR_CALIB_LSB2, 0x00 },
};
static bool cap11xx_volatile_reg(struct device *dev, unsigned int reg)
@@ -149,12 +97,6 @@ static bool cap11xx_volatile_reg(struct device *dev, unsigned int reg)
switch (reg) {
case CAP11XX_REG_MAIN_CONTROL:
case CAP11XX_REG_SENSOR_INPUT:
- case CAP11XX_REG_SENOR_DELTA(0):
- case CAP11XX_REG_SENOR_DELTA(1):
- case CAP11XX_REG_SENOR_DELTA(2):
- case CAP11XX_REG_SENOR_DELTA(3):
- case CAP11XX_REG_SENOR_DELTA(4):
- case CAP11XX_REG_SENOR_DELTA(5):
return true;
}
--
2.54.0
^ permalink raw reply related
* [PATCH v2 1/9] Input: cap11xx - clean up duplicate log and add probe error logs
From: Jun Yan @ 2026-06-12 7:22 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Jun Yan, linux-input, devicetree, linux-kernel
In-Reply-To: <20260612072237.1177304-1-jerrysteve1101@gmail.com>
Duplicated device detection log exists at line 537 and line 542,
which brings redundant kernel print messages. Drop one redundant
log entry to clean up dmesg output.
Meanwhile add missing error logs when I2C communication fails
during driver probe(), helping debug.
Signed-off-by: Jun Yan <jerrysteve1101@gmail.com>
---
drivers/input/keyboard/cap11xx.c | 11 ++++-------
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/drivers/input/keyboard/cap11xx.c b/drivers/input/keyboard/cap11xx.c
index 2447c1ae2166..485d8ba97723 100644
--- a/drivers/input/keyboard/cap11xx.c
+++ b/drivers/input/keyboard/cap11xx.c
@@ -512,7 +512,7 @@ static int cap11xx_i2c_probe(struct i2c_client *i2c_client)
error = regmap_read(priv->regmap, CAP11XX_REG_PRODUCT_ID, &val);
if (error)
- return error;
+ return dev_err_probe(dev, error, "Failed to read product ID\n");
if (val != cap->product_id) {
dev_err(dev, "Product ID: Got 0x%02x, expected 0x%02x\n",
@@ -522,7 +522,7 @@ static int cap11xx_i2c_probe(struct i2c_client *i2c_client)
error = regmap_read(priv->regmap, CAP11XX_REG_MANUFACTURER_ID, &val);
if (error)
- return error;
+ return dev_err_probe(dev, error, "Failed to read manufacturer ID\n");
if (val != CAP11XX_MANUFACTURER_ID) {
dev_err(dev, "Manufacturer ID: Got 0x%02x, expected 0x%02x\n",
@@ -531,11 +531,8 @@ static int cap11xx_i2c_probe(struct i2c_client *i2c_client)
}
error = regmap_read(priv->regmap, CAP11XX_REG_REVISION, &rev);
- if (error < 0)
- return error;
-
- dev_info(dev, "CAP11XX detected, model %s, revision 0x%02x\n",
- id->name, rev);
+ if (error)
+ return dev_err_probe(dev, error, "Failed to read revision\n");
priv->model = cap;
--
2.54.0
^ permalink raw reply related
* [PATCH v2 0/9] Input: cap11xx - Add support for CAP1114
From: Jun Yan @ 2026-06-12 7:22 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Jun Yan, linux-input, devicetree, linux-kernel
CAP1114 is a 14-channel capacitive touch sensor with 11 LED outputs
and hardware reset support.
Patches 1-4 perform driver cleanup and DT binding tweaks.
Patches 5-6 add reset-gpios support for CAP11xx.
Patches 7-9 add support for CAP1114.
Changes in v2:
- Drop LED property tweaks, keep only reg changes and node regex
update in DT bindings.
- Split microchip,cap1126 LED reg constraints into a separate patch.
- Replace usleep_range() with msleep() for 500 ms delay during
reset pin handling.
- Add missing <linux/delay.h> for usleep_range() and msleep().
- Add CAP1114 to unsupported enum for microchip,signal-guard and
microchip,calib-sensitivity
- Add constraint for linux,keycodes to support CAP1114.
- When reading CAP1114 button status, mask STATUS1 to bits 0-5
and OR with STATUS2.
- Adjust code style.
- Link to v1:
https://lore.kernel.org/all/20260606150458.250606-1-jerrysteve1101@gmail.com
Jun Yan (9):
Input: cap11xx - clean up duplicate log and add probe error logs
Input: cap11xx - remove unused register macros
dt-bindings: input: microchip,cap11xx: Update datasheet URL and LED
reg range
dt-bindings: input: microchip,cap11xx: Add microchip,cap1126 LED reg
constraints
dt-bindings: input: microchip,cap11xx: Add reset-gpios property
Input: cap11xx - add reset gpio support
Input: cap11xx - refactor code for better CAP1114 support.
dt-bindings: input: microchip,cap11xx: Add CAP1114 support
Input: cap11xx - add support for CAP1114
.../bindings/input/microchip,cap11xx.yaml | 85 ++++++-
drivers/input/keyboard/cap11xx.c | 230 +++++++++++-------
2 files changed, 224 insertions(+), 91 deletions(-)
--
2.54.0
^ permalink raw reply
* Re: [PATCH v2 02/16] device property: Add fwnode_graph_get_next_port_endpoint()
From: Chen-Yu Tsai @ 2026-06-12 7:20 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Bartosz Golaszewski, Greg Kroah-Hartman, Daniel Scally,
Heikki Krogerus, Sakari Ailus, Rafael J. Wysocki,
Danilo Krummrich, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Matthias Brugger, AngeloGioacchino Del Regno, Alan Stern,
linux-acpi, driver-core, linux-pm, linux-usb, devicetree,
linux-mediatek, linux-arm-kernel, linux-kernel,
Manivannan Sadhasivam
In-Reply-To: <ailv8HpnrCH3Zb8C@ashevche-desk.local>
On Wed, Jun 10, 2026 at 11:08 PM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
>
> On Wed, Jun 10, 2026 at 04:40:36PM +0800, Chen-Yu Tsai wrote:
> > Due to design constraints of the power sequencing API, the consumer
> > must first be sure that the other side is actually a provider, or it
> > will continually get -EPROBE_DEFER when requesting the power
> > sequencing descriptor.
> >
> > In the upcoming USB power sequencing integration, the USB hub driver
> > first needs to check whether a graph connection exists, and whether
> > the other side of the connection is a supported connector type. The
> > USB port is tied to a "port" firmware node, and this new helper will
> > be used to get the endpoint under the known "port" firmware node.
>
> ...
>
> > +/**
> > + * fwnode_graph_get_next_port_endpoint - Get next endpoint firmware node in port
> > + * @port: Pointer to the target port firmware node
> > + * @prev: Previous endpoint node or %NULL to get the first
> > + *
> > + * The caller is responsible for calling fwnode_handle_put() on the returned
> > + * fwnode pointer. Note that this function also puts a reference to @prev
> > + * unconditionally.
> > + *
> > + * Return: an endpoint firmware node pointer or %NULL if no more endpoints
> > + * are available.
>
> Yeah, you see, even here is inconsistency with previously added kernel-doc.
>
> > + */
> > +struct fwnode_handle *fwnode_graph_get_next_port_endpoint(const struct fwnode_handle *port,
> > + struct fwnode_handle *prev)
> > +{
> > + struct fwnode_handle *ep;
>
> Unused?
>
> > + while (1) {
>
> This is usually harder to read and follow. It's like "pay much attention on
> the code", but here no rocket science, no code to really pay attention to.
>
> > + prev = fwnode_get_next_child_node(port, prev);
> > + if (!prev)
> > + break;
> > +
> > + if (WARN(!fwnode_name_eq(prev, "endpoint"),
> > + "non endpoint node is used (%pfw)", prev))
> > + continue;
> > +
> > + break;
> > + }
> > +
> > + return prev;
> > +}
>
> So, this can be rewritten as
>
> ep = prev;
> do {
> ep = fwnode_get_next_child_node(port, ep);
> if (fwnode_name_eq(ep, "endpoint"))
> break;
>
> WARN_ON(ep, ...);
> } while (ep);
>
> return ep;
>
> But also big question why? to WARN*(). There is no use in the entire
> property.c.
Will drop. This function was lifted from drivers/of/property.c then
adapted to the fwnode APIs, so it still has the structure of its
origin. With the WARN() gone, rewriting it as do {} while() becomes:
do {
prev = fwnode_get_next_child_node(port, prev);
if (prev && fwnode_name_eq(prev, "endpoint"))
break;
} while (prev);
return prev;
Thanks
ChenYu
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: ipq9574: Add missing PCIe global IRQs
From: Dmitry Baryshkov @ 2026-06-12 7:14 UTC (permalink / raw)
To: Kathiravan Thirumoorthy
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260610-ipq9574_pcie_global_irq-v1-1-6d6333b95c43@oss.qualcomm.com>
On Wed, Jun 10, 2026 at 10:28:27PM +0530, Kathiravan Thirumoorthy wrote:
> IPQ9574 also has the dedicated 'global' IRQ line for each PCIe controller.
> Add the same.
>
> Signed-off-by: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/ipq9574.dtsi | 24 ++++++++++++++++--------
> 1 file changed, 16 insertions(+), 8 deletions(-)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v3 2/2] phy: qcom-qmp-pcie: Add support for ipq5210 PCIe phys
From: Dmitry Baryshkov @ 2026-06-12 7:13 UTC (permalink / raw)
To: Varadarajan Narayanan
Cc: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, linux-phy, devicetree, linux-kernel
In-Reply-To: <20260610-pcie-phy-v3-2-334011b378d6@oss.qualcomm.com>
On Wed, Jun 10, 2026 at 04:46:09PM +0530, Varadarajan Narayanan wrote:
> Add support for a PCIe phys found on Qualcomm ipq5210 platform.
>
> Signed-off-by: Varadarajan Narayanan <varadarajan.narayanan@oss.qualcomm.com>
> ---
> drivers/phy/qualcomm/phy-qcom-qmp-pcie.c | 129 +++++++++++++++++++++++++++++++
> 1 file changed, 129 insertions(+)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v2 2/2] thermal/drivers/qcom/tsens: Add support for ipq9650 tsens
From: Dmitry Baryshkov @ 2026-06-12 7:11 UTC (permalink / raw)
To: Varadarajan Narayanan
Cc: amitk, thara.gopinath, rafael, daniel.lezcano, rui.zhang,
lukasz.luba, robh, krzk+dt, conor+dt, linux-pm, linux-arm-msm,
devicetree, linux-kernel, Konrad Dybcio
In-Reply-To: <20260610081241.1468507-3-varadarajan.narayanan@oss.qualcomm.com>
On Wed, Jun 10, 2026 at 01:42:41PM +0530, Varadarajan Narayanan wrote:
> ipq9650's tsens is similar to ipq5332 tsens but has different number of
> sensors. Re-use the ipq5332 data for ipq9650 and modify the sensor related
> information.
>
> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> Signed-off-by: Varadarajan Narayanan <varadarajan.narayanan@oss.qualcomm.com>
> ---
> drivers/thermal/qcom/tsens-v2.c | 8 ++++++++
> drivers/thermal/qcom/tsens.c | 3 +++
> drivers/thermal/qcom/tsens.h | 2 +-
> 3 files changed, 12 insertions(+), 1 deletion(-)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v2 01/16] device property: Add fwnode_graph_get_port_by_id()
From: Chen-Yu Tsai @ 2026-06-12 7:07 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Bartosz Golaszewski, Greg Kroah-Hartman, Daniel Scally,
Heikki Krogerus, Sakari Ailus, Rafael J. Wysocki,
Danilo Krummrich, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Matthias Brugger, AngeloGioacchino Del Regno, Alan Stern,
linux-acpi, driver-core, linux-pm, linux-usb, devicetree,
linux-mediatek, linux-arm-kernel, linux-kernel,
Manivannan Sadhasivam
In-Reply-To: <ailtMyYhbkOgaZWw@ashevche-desk.local>
On Wed, Jun 10, 2026 at 10:57 PM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
>
> On Wed, Jun 10, 2026 at 04:40:35PM +0800, Chen-Yu Tsai wrote:
> > In some cases the driver needs a reference to the port firmware node.
> > Once such case is the upcoming USB power sequencing integration. The
> > USB hub port is tied to the corresponding port firmware node if it
> > exists.
> >
> > Provide a helper for this.
>
> Okay, if it's really needed.
> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
>
> ...
>
> > +/**
> > + * fwnode_graph_get_port_by_id - get the port matching a given id
> > + * @fwnode: parent fwnode_handle containing the graph
> > + * @id: id of the port
> > + *
> > + * Return: A 'port' firmware node pointer with refcount incremented.
> > + *
> > + * The caller is responsible for calling fwnode_handle_put() on the returned
> > + * fwnode pointer.
>
> Note, the Return section must be last one in the kernel-doc. The last paragraph
> sounds to me as a better fit for main description. Basically check how other
> kernel-doc(s) in this file are organised and follow that pattern.
Will fix. I likely just copied it from the nearest function which happened
to not have a Return section. I did a quick look through and it seems many
of them are missing this.
ChenYu
^ permalink raw reply
* Re: [PATCH v7 2/2] ARM: dts: aspeed: ventura2: Add Meta ventura2 BMC
From: Andrew Lunn @ 2026-06-12 7:04 UTC (permalink / raw)
To: Kyle Hsieh
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Joel Stanley,
Andrew Jeffery, devicetree, linux-arm-kernel, linux-aspeed,
linux-kernel
In-Reply-To: <CAF7HswOi3fPMFppPoGmh0QELiPz4Po4cyWuDrEHLY2vNMyKE9g@mail.gmail.com>
> The EEPROM is physically isolated by a hardware I2C multiplexer.
> By default, the mux connects the EEPROM directly to the Marvell switch
> for its routine operation and configuration loading. The BMC's I2C bus is
> physically disconnected from the EEPROM during this time.
I think some comments would be good. It was not clear to my how this
works.
Andrew
^ permalink raw reply
* Re: [PATCH 0/3] ARM: dts: stm32: lxa: change stdout-path baud rate from 9600 to 115200
From: David Laight @ 2026-06-12 6:53 UTC (permalink / raw)
To: Ahmad Fatoum
Cc: Alexandre Torgue, Maxime Coquelin, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Leonard Göhrs,
Marc Kleine-Budde, Alexandre Torgue, devicetree, linux-stm32,
linux-arm-kernel, linux-kernel, kernel
In-Reply-To: <b4fd25b6-52e3-4b5e-8440-69545bce43e8@pengutronix.de>
On Thu, 11 Jun 2026 22:33:18 +0200
Ahmad Fatoum <a.fatoum@pengutronix.de> wrote:
> Hi David,
>
> On 6/11/26 21:43, David Laight wrote:
> > On Thu, 11 Jun 2026 20:12:32 +0200
> > Ahmad Fatoum <a.fatoum@pengutronix.de> wrote:
> >
> >> The LXA boards are the only STM32 boards that set stdout-path = &uart*
> >> instead of explicitly specifying a baud rate.
> >>
> >> This would mean the default of 9600 is used, but it goes unnoticed when
> >> booting normally as barebox fixes up a console= line that includes a
> >> baud rate.
> >>
> >> When EFI booting GRUB however, GRUB will not pass along the console=
> >> line and thus the board ends up with a 9600 baud Linux console,
> >> confusing users.
> >
> > Is it possible to determine the current baud rate (by reading the hardware
> > register) and default to that value.
> > Then if grub has initialised the uart the kernel will use the same
> > baud rate.
>
> I think so, yes. In addition to the register divider configuration, one
> would need the input clock rate as well, but that's not a problem.
>
> Do you know if any drivers already do this?
I've seen it done somewhere, certainly x86, but possibly NetBSD.
That would have been preserving the baud rate set by the bios.
You don't want the baud rate changing half way through the boot sequence.
David
>
> Nevertheless, I would like the LXA device trees changed, even if only
> to align them with all other existing STM32 device trees.
>
> Cheers,
> Ahmad
>
>
> >
> > David
> >
> >>
> >> This series fixes this. As the device trees were added at different
> >> times, they are fixed each in a separate commit with its own Fixes: tag.
> >>
> >> ---
> >> Ahmad Fatoum (3):
> >> ARM: dts: stm32: lxa-mc1: change stdout-path baud rate from 9600 to 115200
> >> ARM: dts: stm32: lxa-tac: change stdout-path baud rate from 9600 to 115200
> >> ARM: dts: stm32: fairytux2: change stdout-path baud rate from 9600 to 115200
> >>
> >> arch/arm/boot/dts/st/stm32mp153c-lxa-fairytux2.dtsi | 2 +-
> >> arch/arm/boot/dts/st/stm32mp157c-lxa-mc1.dts | 2 +-
> >> arch/arm/boot/dts/st/stm32mp15xc-lxa-tac.dtsi | 2 +-
> >> 3 files changed, 3 insertions(+), 3 deletions(-)
> >> ---
> >> base-commit: 4549871118cf616eecdd2d939f78e3b9e1dddc48
> >> change-id: 20260611-lxa-stdout-path-baudrate-7cf454cdae07
> >>
> >> Best regards,
> >> --
> >> Ahmad Fatoum <a.fatoum@pengutronix.de>
> >>
> >>
> >
> >
>
>
^ permalink raw reply
* Re: [PATCH 6/7] drm/tegra: vic: Add Tegra264 support
From: sashiko-bot @ 2026-06-12 6:47 UTC (permalink / raw)
To: Mikko Perttunen; +Cc: dri-devel, devicetree, robh, conor+dt
In-Reply-To: <20260612-t264-host1x-v1-6-8d934987de67@nvidia.com>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
New issues:
- [High] Out-of-bounds read when parsing the RISC-V firmware descriptor.
Pre-existing issues:
- [High] Out-of-bounds read and potential crash when parsing internal offsets from the loaded firmware image.
- [High] Use-After-Free in error paths of `vic_load_firmware()` due to dangling pointer.
--
commit e93ea0b6d1fe675fec33102f35c8bdffae0a5687
Author: Mikko Perttunen <mperttunen@nvidia.com>
drm/tegra: vic: Add Tegra264 support
Add support for VIC on Tegra264. The Tegra264 VIC uses a RISC-V based
Falcon microcontroller instead of the traditional Falcon previously,
and has the TRANSCFG register in a different place.
> diff --git a/drivers/gpu/drm/tegra/vic.c b/drivers/gpu/drm/tegra/vic.c
> --- a/drivers/gpu/drm/tegra/vic.c
> +++ b/drivers/gpu/drm/tegra/vic.c
[ ... ]
> @@ -85,31 +92,50 @@ static int vic_boot(struct vic *vic)
> CG_WAKEUP_DLY_CNT(4),
> NV_PVIC_MISC_PRI_VIC_CG);
[ ... ]
> + } else {
> + u32 fce_ucode_size, fce_bin_data_offset;
> + void *hdr;
> +
> + hdr = vic->falcon.firmware.virt;
> + fce_bin_data_offset = *(u32 *)(hdr + VIC_UCODE_FCE_DATA_OFFSET);
> +
> + /* Old VIC firmware needs kernel help with setting up FCE microcode. */
> + if (fce_bin_data_offset != 0x0 && fce_bin_data_offset != 0xa5a5a5a5) {
> + hdr = vic->falcon.firmware.virt +
> + *(u32 *)(hdr + VIC_UCODE_FCE_HEADER_OFFSET);
> + fce_ucode_size = *(u32 *)(hdr + FCE_UCODE_SIZE_OFFSET);
[Severity: High]
This is a pre-existing issue, but does this code perform an out-of-bounds
read when parsing internal offsets from the loaded firmware image?
It appears that nested offsets are read directly from the firmware image
without verifying that the firmware size is large enough, or that the
offsets point within the valid firmware boundaries. If a malformed or
truncated firmware file is provided, could this arbitrary offset lead to an
out-of-bounds read and a kernel page fault?
> +
> + falcon_execute_method(&vic->falcon, VIC_SET_FCE_UCODE_SIZE,
> + fce_ucode_size);
> + falcon_execute_method(
> + &vic->falcon, VIC_SET_FCE_UCODE_OFFSET,
> + (vic->falcon.firmware.iova + fce_bin_data_offset) >> 8);
> + }
[ ... ]
> @@ -277,6 +303,8 @@ static int vic_load_firmware(struct vic *vic)
>
> if (!vic->config->supports_sid) {
> vic->can_use_context = false;
> + } else if (vic->config->has_riscv) {
> + vic->can_use_context = true;
> } else if (fce_bin_data_offset != 0x0 && fce_bin_data_offset != 0xa5a5a5a5) {
> /*
> * Firmware will access FCE through STREAMID0, so context
[Severity: High]
This is a pre-existing issue, but can the error path in vic_load_firmware()
lead to a use-after-free?
If an error occurs during firmware loading, such as a failure in
falcon_load_firmware(), the cleanup path frees the allocated DMA memory
but seems to leave the firmware pointers dangling:
cleanup:
if (!client->group)
dma_free_coherent(vic->dev, size, virt, iova);
else
tegra_drm_free(tegra, size, virt, iova);
mutex_unlock(&lock);
return err;
If the device attempts to load the firmware again later, it might see
the non-null pointer, return success, and proceed to use the freed DMA
memory. Could this result in IOMMU faults and potential system crashes?
[ ... ]
> @@ -495,6 +537,7 @@ static int vic_probe(struct platform_device *pdev)
>
> vic->falcon.dev = dev;
> vic->falcon.regs = vic->regs;
> + vic->falcon.riscv = vic->config->has_riscv;
>
> err = falcon_init(&vic->falcon);
[Severity: High]
Does enabling RISC-V support here expose an out-of-bounds read when
parsing the RISC-V firmware descriptor?
In falcon_parse_firmware_desc(), the descriptor data is cast to
struct falcon_fw_riscv_desc and fields at large offsets are read without
a preceding length check on the firmware size:
struct falcon_fw_riscv_desc *desc =
(struct falcon_fw_riscv_desc *)falcon->firmware.desc_firmware->data;
falcon->firmware.code.offset = desc->code_offset;
If a truncated descriptor file is provided by userspace, could this
cause a buffer over-read and lead to a kernel page fault?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260612-t264-host1x-v1-0-8d934987de67@nvidia.com?part=6
^ permalink raw reply
* Re: [PATCH 3/7] gpu: host1x: Correctly parse linear ranges of context devices
From: sashiko-bot @ 2026-06-12 6:45 UTC (permalink / raw)
To: Mikko Perttunen; +Cc: robh, dri-devel, devicetree, conor+dt
In-Reply-To: <20260612-t264-host1x-v1-3-8d934987de67@nvidia.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] The driver synchronously frees the dynamically allocated `cdl->devs` array immediately after calling `device_unregister()`, while using an empty `.release()` callback. This violates the Linux device model and leads to a Use-After-Free.
--
commit 46b291569da04e8306d82ff644615dfc60ee956f
Author: Mikko Perttunen <mperttunen@nvidia.com>
gpu: host1x: Correctly parse linear ranges of context devices
The commit updates the parsing of the iommu-map property to support
linear ranges of context devices instead of assuming each device has
a one-length entry.
> diff --git a/drivers/gpu/host1x/context.c b/drivers/gpu/host1x/context.c
> --- a/drivers/gpu/host1x/context.c
> +++ b/drivers/gpu/host1x/context.c
[ ... ]
> @@ -34,7 +34,16 @@ int host1x_memory_context_list_init(struct host1x *host1x)
> if (err < 0)
> return 0;
>
> - cdl->len = err / 4;
> + devs = 0;
> +
> + for (i = 0; i < err / 4; i++) {
> + u32 length;
> +
> + of_property_read_u32_index(node, "iommu-map", i * 4 + 3, &length);
> + devs += length;
> + }
> +
> + cdl->len = devs;
> cdl->devs = kzalloc_objs(*cdl->devs, cdl->len);
[Severity: High]
This isn't a bug introduced by this patch, but there is a pre-existing
issue with how the cdl->devs array is managed during cleanup.
In host1x_memory_context_list_init(), if an error occurs later in the
initialization, the unreg_devices error path unregisters the devices and
immediately frees the array:
host1x_memory_context_list_init() {
...
unreg_devices:
while (i--)
device_unregister(&cdl->devs[i].dev);
kfree(cdl->devs);
...
}
The same pattern appears in host1x_memory_context_list_free() during
normal teardown.
The driver also provides a dummy release callback:
static void host1x_memory_context_release(struct device *dev)
{
/* context device is freed in host1x_memory_context_list_free() */
}
Could this lead to a use-after-free? When device_unregister() is called,
it drops the initial device reference, but sysfs or userspace might still
hold elevated references to the embedded kobjects.
Since kfree(cdl->devs) is called synchronously while references could
still exist, would userspace interaction with the sysfs attributes for
these devices during teardown end up accessing freed memory?
> if (!cdl->devs)
> return -ENOMEM;
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260612-t264-host1x-v1-0-8d934987de67@nvidia.com?part=3
^ permalink raw reply
* Re: [PATCH 5/7] drm/tegra: falcon: Add support for RISC-V external boot
From: sashiko-bot @ 2026-06-12 6:44 UTC (permalink / raw)
To: Mikko Perttunen; +Cc: dri-devel, conor+dt, robh, devicetree
In-Reply-To: <20260612-t264-host1x-v1-5-8d934987de67@nvidia.com>
Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
- [High] Missing size validation for the `.desc` firmware file allows an out-of-bounds read of the firmware descriptor buffer.
- [High] Inverted condition in `falcon_wait_idle()` for RISC-V incorrectly waits for the CPU to become active rather than idle, causing premature return.
- [High] Firmware segment offsets and sizes from the `.desc` file are not validated against the main firmware buffer size, leading to out-of-bounds DMA reads.
- [Medium] Missing endianness conversion when reading `u32` fields from the `.desc` firmware descriptor breaks on big-endian architectures.
--
commit 9b921eae84dc7cacf7c324bd76e166d6a5d942be
Author: Mikko Perttunen <mperttunen@nvidia.com>
drm/tegra: falcon: Add support for RISC-V external boot
This commit adds support for loading and booting RISC-V firmwares on Falcons
with RISC-V hardware. It introduces a new firmware layout and uses different
registers for the boot flow compared to traditional Falcons.
> diff --git a/drivers/gpu/drm/tegra/falcon.c b/drivers/gpu/drm/tegra/falcon.c
> index 17f616bbcb45b..1172356b6af3b 100644
> --- a/drivers/gpu/drm/tegra/falcon.c
> +++ b/drivers/gpu/drm/tegra/falcon.c
> @@ -26,8 +26,12 @@ int falcon_wait_idle(struct falcon *falcon)
> {
> u32 value;
>
> - return readl_poll_timeout(falcon->regs + FALCON_IDLESTATE, value,
> - (value == 0), 10, 100000);
> + if (falcon->riscv)
> + return readl_poll_timeout(falcon->regs + RISCV_CPUCTL, value,
> + (value & RISCV_CPUCTL_ACTIVE_STAT_ACTIVE), 10, 100000);
[Severity: High]
Does this condition successfully terminate when the CPU is active rather than
idle?
If falcon_boot() calls this immediately after issuing the STARTCPU command,
the processor will instantly become active, and the wait will return
immediately instead of waiting for the processor to go idle. Would negating
the condition to !(value & RISCV_CPUCTL_ACTIVE_STAT_ACTIVE) correctly wait
for the firmware boot sequence to finish?
> + else
> + return readl_poll_timeout(falcon->regs + FALCON_IDLESTATE, value,
> + (value == 0), 10, 100000);
> }
[ ... ]
> @@ -122,6 +126,17 @@ static int falcon_parse_firmware_image(struct falcon *falcon)
> return 0;
> }
>
> +static void falcon_parse_firmware_desc(struct falcon *falcon)
> +{
> + struct falcon_fw_riscv_desc *desc =
> + (struct falcon_fw_riscv_desc *)falcon->firmware.desc_firmware->data;
[Severity: High]
Is it possible for the loaded firmware file to be smaller than
sizeof(struct falcon_fw_riscv_desc)?
If a truncated or malformed .desc file is loaded from userspace, could
casting and reading desc_firmware->data here result in an out-of-bounds
memory read of the allocated buffer?
> +
> + falcon->firmware.code.offset = desc->code_offset;
> + falcon->firmware.code.size = desc->code_size;
> + falcon->firmware.data.offset = desc->data_offset;
> + falcon->firmware.data.size = desc->data_size;
[Severity: Medium]
Do these assignments need endianness conversion, such as le32_to_cpu()?
The older .bin parsing path safely copies and byte-swaps the firmware via
falcon_copy_firmware_image(). Since this RISC-V path appears to perform
no conversions, could reading these fields directly from the raw byte
array produce incorrect, byte-swapped values on big-endian architectures?
[Severity: High]
Are these offsets and sizes validated against the main firmware buffer size?
In falcon_boot(), these sizes are used to calculate bounds and program
the Falcon hardware DMA engine via falcon_copy_chunk():
falcon_boot() {
...
for (offset = 0; offset < falcon->firmware.data.size; offset += 256)
falcon_copy_chunk(falcon,
falcon->firmware.data.offset + offset,
offset, FALCON_MEMORY_DATA);
...
}
If the values are not checked to ensure
offset + size <= falcon->firmware.size, could a maliciously crafted .desc
file instruct the DMA controller to read out-of-bounds physical memory?
> +}
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260612-t264-host1x-v1-0-8d934987de67@nvidia.com?part=5
^ permalink raw reply
* Re: [PATCH 2/2] phy: qcom: qmp-pcie: Add IPQ9650 PCIe PHY support
From: Kathiravan Thirumoorthy @ 2026-06-12 6:43 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, linux-phy, devicetree, linux-kernel
In-Reply-To: <ohijjcszynmoocjarid7mo7nbtd2dqcdvqrbnzb7anjytw5m56@nguadudsz7qg>
On 6/12/2026 11:44 AM, Dmitry Baryshkov wrote:
> On Fri, Jun 12, 2026 at 08:22:02AM +0530, Kathiravan Thirumoorthy wrote:
>> On 6/12/2026 1:52 AM, Dmitry Baryshkov wrote:
>>> On Tue, Jun 09, 2026 at 03:46:56PM +0530, Kathiravan Thirumoorthy wrote:
>>>> On 6/8/2026 12:26 PM, Dmitry Baryshkov wrote:
>>>>> On Tue, Jun 02, 2026 at 02:40:18PM +0530, Kathiravan Thirumoorthy wrote:
>>>>>> The IPQ9650 platform has three Gen3 2-lane PCIe controllers and two Gen3
>>>>>> 1-lane PCIe controllers. The PHY instances also require the on-chip refgen
>>>>>> supply.
>>>>>>
>>>>>> Add the IPQ9650 Gen3 x1 and x2 QMP PCIe PHY configurations, including the
>>>>>> refgen regulator supply.
>>>>>>
>>>>>> Signed-off-by: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com>
>>>>>> ---
>>>>>> drivers/phy/qualcomm/phy-qcom-qmp-pcie.c | 220 +++++++++++++++++++++++++++++++
>>>>>> 1 file changed, 220 insertions(+)
>>>>>>
>>>>>> @@ -3378,6 +3524,10 @@ static const char * const qmp_phy_vreg_l[] = {
>>>>>> "vdda-phy", "vdda-pll",
>>>>>> };
>>>>>> +static const char * const ipq9650_qmp_phy_vreg_l[] = {
>>>>>> + "refgen",
>>>>>> +};
>>>>> Now vdda-phy / vdda-pll supplies?
>>>> Cross checked with HW team again. Along with refgen, there is a on-chip LDO
>>>> which supplies fixed voltage to the PHYs. It is enabled upon system power on
>>>> and no SW intervention is required.
>>> What is it being powered by? MX? CX?
>> It is driven by CX.
> I assume that there is no CX collapse on IPQ9650? Is CX not scaling on
> this chip. Please provide some details on the commit message.
That's right. No CX collapse on IPQ9650. Let me rewrite the commit
message as below. Hope its okay.
--
Add support for the IPQ9650 platform, which includes three Gen3 x2 PCIe
controllers and two Gen3 x1 PCIe controllers. The PHY instances require
the on-chip refgen supply.
Add the IPQ9650 Gen3 x1 and x2 QMP PCIe PHY configurations along with
the refgen regulator supply. Note that an on-chip LDO, driven by the SoC
CX, supplies the PHY voltages without requiring software control. Note
that CX power collapse is not supported on IPQ9650.
--
>
>>>> regulator-fixed doesn't take the resource 'reg'. May be should I create
>>>> another regulator driver which accepts 'reg', something similar to the
>>>> qcom-refgen-regulator? Please advise.
>>> If it doesn't require control, there is no need for a separate driver or
>>> separate supply. For example, the refgen is being references only by
>>> those devices which require software votes.
>> Thanks. Then let me respin this series on top of phy-next so that Vinod can
>> pick it up.
>>
>>>>>> +
>>>>>> static const char * const sm8550_qmp_phy_vreg_l[] = {
>>>>>> "vdda-phy", "vdda-pll", "vdda-qref",
>>>>>> };
>> --
>> linux-phy mailing list
>> linux-phy@lists.infradead.org
>> https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 4/7] gpu: host1x: Add Tegra264 support
From: sashiko-bot @ 2026-06-12 6:43 UTC (permalink / raw)
To: Mikko Perttunen; +Cc: devicetree, robh, conor+dt, dri-devel
In-Reply-To: <20260612-t264-host1x-v1-4-8d934987de67@nvidia.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] The macro `HOST1X_UCLASS_INDOFF_RWN_READ_V` is missing due to a copy-paste error that instead incorrectly duplicates the definition of `HOST1X_UCLASS_INDOFF_INDROFFSET_F(v)`.
--
commit bc3ed2efd3fa7eeadce14ecd91452f9ad7d9471e
Author: Santosh BS <santoshb@nvidia.com>
gpu: host1x: Add Tegra264 support
Add device data and chip headers for Tegra264.
> diff --git a/drivers/gpu/host1x/hw/hw_host1x10_uclass.h b/drivers/gpu/host1x/hw/hw_host1x10_uclass.h
> new file mode 100644
> index 0000000000000..abe83e67fa837
> --- /dev/null
> +++ b/drivers/gpu/host1x/hw/hw_host1x10_uclass.h
[ ... ]
> +static inline u32 host1x_uclass_indoff_indroffset_f(u32 v)
> +{
> + return (v & 0xffff) << 2;
> +}
> +#define HOST1X_UCLASS_INDOFF_INDROFFSET_F(v) \
> + host1x_uclass_indoff_indroffset_f(v)
> +static inline u32 host1x_uclass_indoff_rwn_read_v(void)
> +{
> + return 1;
> +}
> +#define HOST1X_UCLASS_INDOFF_INDROFFSET_F(v) \
> + host1x_uclass_indoff_indroffset_f(v)
[Severity: Low]
This isn't a bug, but it looks like HOST1X_UCLASS_INDOFF_INDROFFSET_F is
accidentally duplicated here instead of defining the macro wrapper
HOST1X_UCLASS_INDOFF_RWN_READ_V for host1x_uclass_indoff_rwn_read_v.
> +static inline u32 host1x_uclass_load_syncpt_payload_32_r(void)
> +{
> + return 0x4e;
> +}
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260612-t264-host1x-v1-0-8d934987de67@nvidia.com?part=4
^ permalink raw reply
* Re: [PATCH] arm64: dts: aspeed: Fix duplicate pinctrl labels and address scheme
From: Andrew Jeffery @ 2026-06-12 6:42 UTC (permalink / raw)
To: Ryan Chen, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Joel Stanley, Arnd Bergmann
Cc: devicetree, linux-arm-kernel, linux-aspeed, linux-kernel
In-Reply-To: <20260611-dtsi_fix-v1-1-ef2b7cd86d6d@aspeedtech.com>
Hi Ryan,
On Thu, 2026-06-11 at 14:50 +0800, Ryan Chen wrote:
> Fix duplicate pinctrl_tach{0-15} and pinctrl_n{cts,dcd,dsr,ri}5 labels
> in aspeed-g7-soc1-pinctrl.dtsi.
>
> Drop the cpu-index from secondary/tertiary container nodes: reduce the
> "#address-cells" from 2 to 1 and update ssp_nvic/tsp_nvic unit-address
> and reg accordingly. Also remove URL comments from the DTS.
>
> Suggested-by: Andrew Jeffery <andrew@codeconstruct.com.au>
> Fixes: e77bb5dc5759 ("arm64: dts: aspeed: Add initial AST27xx SoC device tree")
> Signed-off-by: Ryan Chen <ryan_chen@aspeedtech.com>
> ---
> This series contains follow-up fixes for the AST27xx DTS support that
> was merged into linux-next (e77bb5dc5759).
>
> Two issues were identified after merge by Andrew Jeffery during review
> of the pending v11 series:
These were identified by the sashiko bot, not so much by me, as I
hadn't got around to looking at the patches at the time. I did comment
in the replies though:
https://lore.kernel.org/all/20260609025708.ADBFE1F00893@smtp.kernel.org/
Separately, the series at hand was v9, so any subsequent revision would
have been v10, not v11. This isn't significant on its own, but it is
another contribution to the collection of small errors that are
accumulating at this point, which concerns me. Please take care.
>
> 1. Duplicate pinctrl state labels in aspeed-g7-soc1-pinctrl.dtsi caused
> dtc to abort with fatal label-redefinition errors.
However, it didn't. soc/dt @ 564edaca1486 ("Merge tag 'sunxi-dt-for-
7.2-2' of https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux
into soc/dt"), which includes the v9 patches at e77bb5dc5759 ("arm64:
dts: aspeed: Add initial AST27xx SoC device tree"), builds without
error.
Why? Well, the report from sashiko appears misleading. Usually
duplicate labels do cause an error, for example:
$ cat dle.dts
/dts-v1/;
/ {
inner: test1 {
prop-inner;
};
inner: test1 {
prop-inner;
};
};
$ dtc -o /dev/null dle.dts
dle.dts:6.15-8.4: ERROR (duplicate_node_names): /test1: Duplicate node name
ERROR: Input tree has errors, aborting (use -f to force output)
$ cat dle-1.dts
/dts-v1/;
/ { };
&{/} {
inner: test0 {
prop-inner;
};
inner: test1 {
prop-inner;
};
};
$ dtc -o /dev/null dle-1.dts
dle-1.dts:8.15-10.4: ERROR (duplicate_label): /test1: Duplicate label 'inner' on /test1 and /test0
ERROR: Input tree has errors, aborting (use -f to force output)
However, a relatively minimal reproduction of the case at hand is:
$ cat dlu.dts
/dts-v1/;
/ { };
&{/} {
inner: test1 {
prop-inner;
};
inner: test1 {
prop-inner;
};
};
$ dtc -o /dev/null dlu.dts
$
This doesn't error out. I recommend not assuming reports from the bot
are entirely accurate. Please test that its claims make sense before
proceeding.
While it's not good that there were duplicate nodes and labels, it is
good that you've tidied them up.
If there are modifications to the aspeed-g7-soc*-pinctrl.dtsi files in
the future, I ask that you them sorted first so we can minimise the
chance of falling into this trap again. The current order seems fairly
haphazard and likely contributed to the oversight.
>
> 2. The synthetic container nodes (secondary, tertiary) for sub-processor
I'm not sure synthetic is the right word here. We're still describing
the hardware, just components that have their own distinct address
spaces.
On a separate note, if you feel the need to make a list when describing
the change (e.g. in the commit message or patch notes) it's usually an
indicator that the change should be split into separate commits. Please
keep this in mind for future changes.
> interrupt controllers used a 2-cell address scheme to encode a
> <cpu-index reg-base> tuple. Since the cpu-index adds no value for
> nodes that are purely phandle anchors, Andrew requested we drop it
> and use the bare register address instead.
> ---
> arch/arm64/boot/dts/aspeed/aspeed-g7-a35.dtsi | 14 ++-
> .../boot/dts/aspeed/aspeed-g7-soc1-pinctrl.dtsi | 102 ---------------------
> 2 files changed, 6 insertions(+), 110 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/aspeed/aspeed-g7-a35.dtsi b/arch/arm64/boot/dts/aspeed/aspeed-g7-a35.dtsi
> index ef283d95649a..58193c3c3696 100644
> --- a/arch/arm64/boot/dts/aspeed/aspeed-g7-a35.dtsi
> +++ b/arch/arm64/boot/dts/aspeed/aspeed-g7-a35.dtsi
> @@ -84,32 +84,30 @@ l2: l2-cache0 {
> };
>
> secondary {
> - #address-cells = <2>;
> - /* https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/of/address.c?h=v6.16#n491 */
> + #address-cells = <1>;
> #size-cells = <0>;
> - /* https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/of/address.c?h=v6.16#n430 */
>
> - ssp_nvic: interrupt-controller@1,e000e100 {
> + ssp_nvic: interrupt-controller@e000e100 {
> compatible = "arm,v7m-nvic";
> #interrupt-cells = <2>;
> #address-cells = <0>;
> interrupt-controller;
> - reg = <1 0xe000e100>;
> + reg = <0xe000e100>;
Some other cleanups to consider are ensuring the property ordering
conforms to the DTS coding style:
https://docs.kernel.org/devicetree/bindings/dts-coding-style.html#order-of-properties-in-device-node
The following grep is likely helpful:
git grep -C1 -F 'compatible =' arch/arm64/boot/dts/aspeed
Andrew
^ permalink raw reply
* Re: [PATCH] usb: dwc3: Update nominal max votes for qcom usb
From: Dmitry Baryshkov @ 2026-06-12 6:41 UTC (permalink / raw)
To: Akash Kumar
Cc: Greg Kroah-Hartman, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-usb, linux-kernel,
linux-arm-msm, devicetree
In-Reply-To: <20260611081831.2743464-1-akash.kumar@oss.qualcomm.com>
On Thu, Jun 11, 2026 at 01:48:21PM +0530, Akash Kumar wrote:
> Increase nominal max votes to improve DDR performance and USB audio
> use case handling.
>
> Currently, Bandwidth vote for max nominal value is set to 2500,
> requiring DDR to run at 1GHz under normal load.
How comes? Please explain the math here.
>
> DDR is allowed to run under nominal range at 1.5GHz, which is
> consistent across all targets. However, with the current nominal
Which targets? Does it cover Agatti? SDX55? IPQ8064?
> vote, glitches are observed during multiple audio use cases over USB.
> Update the nominal vote to allow DDR to run more
> efficiently, enabling simultaneous multiple USB audio use cases
> without glitches.
>
> With the existing vote, throughput is around 125MB/s. The updated nominal
> value increases throughput to 145MB/s.
>
> Benefits:
>
> Enhanced performance and stability for multiple USB audio use cases.
> Improved overall system efficiency with higher throughput. Slight
> improvement in the audio KPI from 17.9ms to 16.6ms RTD-USBC.
What kind of KPI is this?
> By implementing this change, we expect to see significant improvements in
Expect or observe?
> both performance and stability, particularly for USB audio use cases,
> leading to a more efficient system overall.
>
> Signed-off-by: Akash Kumar <akakum@qti.qualcomm.com>
> ---
> drivers/usb/dwc3/dwc3-qcom.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/usb/dwc3/dwc3-qcom.c b/drivers/usb/dwc3/dwc3-qcom.c
> index f43f73ac36ff..aa43a03f3c7f 100644
> --- a/drivers/usb/dwc3/dwc3-qcom.c
> +++ b/drivers/usb/dwc3/dwc3-qcom.c
> @@ -46,9 +46,9 @@
> #define USB_MEMORY_AVG_HS_BW MBps_to_icc(240)
> #define USB_MEMORY_PEAK_HS_BW MBps_to_icc(700)
> #define USB_MEMORY_AVG_SS_BW MBps_to_icc(1000)
> -#define USB_MEMORY_PEAK_SS_BW MBps_to_icc(2500)
> -#define APPS_USB_AVG_BW 0
> -#define APPS_USB_PEAK_BW MBps_to_icc(40)
> +#define USB_MEMORY_PEAK_SS_BW MBps_to_icc(5500)
> +#define APPS_USB_AVG_BW 40
MBps_to_icc(40)
> +#define APPS_USB_PEAK_BW MBps_to_icc(80)
You've tried to explain, why we change USB_MEMORY_PEAK_SS_BW. Why are
you chahing APPS_USB_*_BW?
>
> /* Qualcomm SoCs with multiport support has up to 4 ports */
> #define DWC3_QCOM_MAX_PORTS 4
> --
> 2.43.0
>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH 1/7] dt-bindings: display: tegra: Changes to support Tegra264
From: sashiko-bot @ 2026-06-12 6:40 UTC (permalink / raw)
To: Mikko Perttunen; +Cc: devicetree, robh, dri-devel, conor+dt
In-Reply-To: <20260612-t264-host1x-v1-1-8d934987de67@nvidia.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Globally relaxing the `ranges` property weakens validation for all prior generations and fails to enforce the new requirement for Tegra264.
--
commit 318044f1bf4d519c5f4796553c5fa864bbc6d439
Author: Mikko Perttunen <mperttunen@nvidia.com>
dt-bindings: display: tegra: Changes to support Tegra264
This commit adds the nvidia,tegra264-host1x compatible string to the Tegra
host1x bindings. It updates the global ranges property to allow up to two
items, as the Tegra264 engine register range is no longer continuous.
> diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.yaml b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.yaml
> index 3563378a01af4..5b0e3158aa5be 100644
> --- a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.yaml
> +++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.yaml
[ ... ]
> @@ -57,7 +58,8 @@ properties:
> enum: [1, 2]
>
> ranges:
> - maxItems: 1
> + minItems: 1
> + maxItems: 2
[Severity: Medium]
Does globally relaxing the ranges constraint weaken validation for all prior
generations? It seems this allows older hardware to incorrectly specify two
ranges and silently pass validation.
[ ... ]
> @@ -192,6 +194,7 @@ allOf:
> contains:
> enum:
> - nvidia,tegra234-host1x
> + - nvidia,tegra264-host1x
> then:
> properties:
> reg-names:
[Severity: Medium]
Since the commit message notes Tegra264 requires two range entries, should
Tegra264 have a specific conditional block to enforce exactly two ranges
(minItems: 2, maxItems: 2)? Grouping it here without a specific constraints
block might allow a configuration with only one range entry to silently pass
validation despite the hardware requirement.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260612-t264-host1x-v1-0-8d934987de67@nvidia.com?part=1
^ permalink raw reply
* [PATCH 7/7] arm64: tegra: Add Host1x and VIC on Tegra264
From: Mikko Perttunen @ 2026-06-12 6:32 UTC (permalink / raw)
To: Thierry Reding, Jonathan Hunter, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-tegra, dri-devel, devicetree, linux-kernel, Mikko Perttunen
In-Reply-To: <20260612-t264-host1x-v1-0-8d934987de67@nvidia.com>
Tegra264 has a host1x instance with a VIC (video image compositor).
Other multimedia engines have moved outside host1x. Stream IDs are
now namespaced by device rather than being defined globally --
however, the only engine we have using context isolation is VIC so
we only define VIC's range of context devices.
Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
---
arch/arm64/boot/dts/nvidia/tegra264.dtsi | 63 ++++++++++++++++++++++++++++++++
1 file changed, 63 insertions(+)
diff --git a/arch/arm64/boot/dts/nvidia/tegra264.dtsi b/arch/arm64/boot/dts/nvidia/tegra264.dtsi
index 06d8357bdf52..fc398975a830 100644
--- a/arch/arm64/boot/dts/nvidia/tegra264.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra264.dtsi
@@ -3807,6 +3807,69 @@ its: msi-controller@40000 {
};
};
+ /* VISION MMIO */
+ bus@8180000000 {
+ compatible = "simple-bus";
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ ranges = <0x000 0x00000000 0x81 0x80000000 0x00 0x10000000>, /* MMIO (256 MiB) */
+ <0x100 0x00000000 0x00 0x20000000 0x00 0x40000000>, /* non-prefetchable memory (32-bit) */
+ <0x200 0x00000000 0xa8 0x80000000 0x57 0x80000000>; /* I/O, ECAM, prefetchable memory (64-bit) */
+
+ host1x@1200000 {
+ compatible = "nvidia,tegra264-host1x";
+ reg = <0x0 0x1200000 0x0 0x10000>,
+ <0x0 0x1210000 0x0 0x10000>,
+ <0x0 0x1240000 0x0 0x10000>;
+ reg-names = "common", "hypervisor", "vm";
+ interrupts = <GIC_SPI 327 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 328 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 329 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 330 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 331 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 332 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 333 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 334 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 325 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "syncpt0", "syncpt1", "syncpt2", "syncpt3", "syncpt4",
+ "syncpt5", "syncpt6", "syncpt7", "host1x";
+ clocks = <&bpmp TEGRA264_CLK_HOST1X>;
+ clock-names = "host1x";
+
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ ranges = <0x000 0x00000000 0x00 0x08000000 0x00 0x01000000>,
+ <0x000 0x02800000 0x00 0x0a800000 0x00 0x00800000>;
+
+ interconnects = <&mc TEGRA264_MEMORY_CLIENT_HOST1XR &emc>;
+ interconnect-names = "dma-mem";
+ iommus = <&smmu1 TEGRA264_SID_HOST1X>;
+ dma-coherent;
+
+ /* Context isolation domains */
+ iommu-map = <0 &smmu1 (TEGRA264_SID_VIC + 1) 16>;
+
+ vic@50000 {
+ compatible = "nvidia,tegra264-vic";
+ reg = <0x0 0x50000 0x0 0x40000>;
+ interrupts = <GIC_SPI 468 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&bpmp TEGRA264_CLK_VIC>;
+ clock-names = "vic";
+ resets = <&bpmp TEGRA264_RESET_VIC>;
+ reset-names = "vic";
+ power-domains = <&bpmp TEGRA264_POWER_DOMAIN_VIC>;
+ interconnects = <&mc TEGRA264_MEMORY_CLIENT_VICR &emc>,
+ <&mc TEGRA264_MEMORY_CLIENT_VICW &emc>;
+ interconnect-names = "dma-mem", "write";
+
+ iommus = <&smmu1 TEGRA264_SID_VIC>;
+ dma-coherent;
+ };
+ };
+ };
+
/* DISP_USB MMIO */
bus@8800000000 {
compatible = "simple-bus";
--
2.53.0
^ permalink raw reply related
* [PATCH 6/7] drm/tegra: vic: Add Tegra264 support
From: Mikko Perttunen @ 2026-06-12 6:32 UTC (permalink / raw)
To: Thierry Reding, Jonathan Hunter, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-tegra, dri-devel, devicetree, linux-kernel, Mikko Perttunen
In-Reply-To: <20260612-t264-host1x-v1-0-8d934987de67@nvidia.com>
Add support for VIC on Tegra264. The Tegra264 VIC uses a RISC-V based
Falcon microcontroller instead of the traditional Falcon previously,
and has the TRANSCFG register in a different place.
The .version field is set to 0x264 rather than 0x26 to allow
distinguishing between different VIC capabilities between minor version
variations of some chips.
Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
---
drivers/gpu/drm/tegra/drm.c | 1 +
drivers/gpu/drm/tegra/vic.c | 95 +++++++++++++++++++++++++++++++++------------
drivers/gpu/drm/tegra/vic.h | 9 ++---
3 files changed, 76 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index 1dcef4e7d104..28245bf5ba5f 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -1396,6 +1396,7 @@ static const struct of_device_id host1x_drm_subdevs[] = {
{ .compatible = "nvidia,tegra194-nvdec", },
{ .compatible = "nvidia,tegra234-vic", },
{ .compatible = "nvidia,tegra234-nvdec", },
+ { .compatible = "nvidia,tegra264-vic", },
{ /* sentinel */ }
};
diff --git a/drivers/gpu/drm/tegra/vic.c b/drivers/gpu/drm/tegra/vic.c
index 332c9b563d3f..46c7e00de347 100644
--- a/drivers/gpu/drm/tegra/vic.c
+++ b/drivers/gpu/drm/tegra/vic.c
@@ -8,6 +8,7 @@
#include <linux/dma-mapping.h>
#include <linux/host1x.h>
#include <linux/iommu.h>
+#include <linux/iopoll.h>
#include <linux/module.h>
#include <linux/of.h>
#include <linux/platform_device.h>
@@ -20,10 +21,16 @@
#include "falcon.h"
#include "vic.h"
+#define VIC_FALCON_DEBUGINFO 0x1094
+#define VIC_DEBUGINFO_DUMMY 0xabcd1234
+#define VIC_DEBUGINFO_CLEAR 0x0
+
struct vic_config {
const char *firmware;
unsigned int version;
bool supports_sid;
+ bool has_riscv;
+ unsigned int transcfg_offset;
};
struct vic {
@@ -54,8 +61,8 @@ static void vic_writel(struct vic *vic, u32 value, unsigned int offset)
static int vic_boot(struct vic *vic)
{
- u32 fce_ucode_size, fce_bin_data_offset, stream_id;
- void *hdr;
+ u32 stream_id;
+ u32 val;
int err = 0;
if (vic->config->supports_sid && tegra_dev_iommu_get_stream_id(vic->dev, &stream_id)) {
@@ -63,7 +70,7 @@ static int vic_boot(struct vic *vic)
value = TRANSCFG_ATT(1, TRANSCFG_SID_FALCON) |
TRANSCFG_ATT(0, TRANSCFG_SID_HW);
- vic_writel(vic, value, VIC_TFBIF_TRANSCFG);
+ vic_writel(vic, value, vic->config->transcfg_offset);
/*
* STREAMID0 is used for input/output buffers. Initialize it to SID_VIC in case
@@ -85,31 +92,50 @@ static int vic_boot(struct vic *vic)
CG_WAKEUP_DLY_CNT(4),
NV_PVIC_MISC_PRI_VIC_CG);
+ if (vic->config->has_riscv) {
+ /* Write a known pattern into DEBUGINFO register */
+ vic_writel(vic, VIC_DEBUGINFO_DUMMY, VIC_FALCON_DEBUGINFO);
+ }
+
err = falcon_boot(&vic->falcon);
if (err < 0)
return err;
- hdr = vic->falcon.firmware.virt;
- fce_bin_data_offset = *(u32 *)(hdr + VIC_UCODE_FCE_DATA_OFFSET);
-
- /* Old VIC firmware needs kernel help with setting up FCE microcode. */
- if (fce_bin_data_offset != 0x0 && fce_bin_data_offset != 0xa5a5a5a5) {
- hdr = vic->falcon.firmware.virt +
- *(u32 *)(hdr + VIC_UCODE_FCE_HEADER_OFFSET);
- fce_ucode_size = *(u32 *)(hdr + FCE_UCODE_SIZE_OFFSET);
-
- falcon_execute_method(&vic->falcon, VIC_SET_FCE_UCODE_SIZE,
- fce_ucode_size);
- falcon_execute_method(
- &vic->falcon, VIC_SET_FCE_UCODE_OFFSET,
- (vic->falcon.firmware.iova + fce_bin_data_offset) >> 8);
- }
+ if (vic->config->has_riscv) {
+ /* Check VIC has reached a proper initialized state */
+ err = readl_poll_timeout(vic->regs + VIC_FALCON_DEBUGINFO, val,
+ val == VIC_DEBUGINFO_CLEAR,
+ 1000, 2000000);
+ if (err) {
+ dev_err(vic->dev, "VIC not initialized, timeout, val=0x%x\n", val);
+ return err;
+ }
+ } else {
+ u32 fce_ucode_size, fce_bin_data_offset;
+ void *hdr;
+
+ hdr = vic->falcon.firmware.virt;
+ fce_bin_data_offset = *(u32 *)(hdr + VIC_UCODE_FCE_DATA_OFFSET);
+
+ /* Old VIC firmware needs kernel help with setting up FCE microcode. */
+ if (fce_bin_data_offset != 0x0 && fce_bin_data_offset != 0xa5a5a5a5) {
+ hdr = vic->falcon.firmware.virt +
+ *(u32 *)(hdr + VIC_UCODE_FCE_HEADER_OFFSET);
+ fce_ucode_size = *(u32 *)(hdr + FCE_UCODE_SIZE_OFFSET);
+
+ falcon_execute_method(&vic->falcon, VIC_SET_FCE_UCODE_SIZE,
+ fce_ucode_size);
+ falcon_execute_method(
+ &vic->falcon, VIC_SET_FCE_UCODE_OFFSET,
+ (vic->falcon.firmware.iova + fce_bin_data_offset) >> 8);
+ }
- err = falcon_wait_idle(&vic->falcon);
- if (err < 0) {
- dev_err(vic->dev,
- "failed to set application ID and FCE base\n");
- return err;
+ err = falcon_wait_idle(&vic->falcon);
+ if (err < 0) {
+ dev_err(vic->dev,
+ "failed to set application ID and FCE base\n");
+ return err;
+ }
}
return 0;
@@ -277,6 +303,8 @@ static int vic_load_firmware(struct vic *vic)
if (!vic->config->supports_sid) {
vic->can_use_context = false;
+ } else if (vic->config->has_riscv) {
+ vic->can_use_context = true;
} else if (fce_bin_data_offset != 0x0 && fce_bin_data_offset != 0xa5a5a5a5) {
/*
* Firmware will access FCE through STREAMID0, so context
@@ -302,7 +330,6 @@ static int vic_load_firmware(struct vic *vic)
return err;
}
-
static int __maybe_unused vic_runtime_resume(struct device *dev)
{
struct vic *vic = dev_get_drvdata(dev);
@@ -417,6 +444,7 @@ static const struct vic_config vic_t186_config = {
.firmware = NVIDIA_TEGRA_186_VIC_FIRMWARE,
.version = 0x18,
.supports_sid = true,
+ .transcfg_offset = 0x2044,
};
#define NVIDIA_TEGRA_194_VIC_FIRMWARE "nvidia/tegra194/vic.bin"
@@ -425,6 +453,7 @@ static const struct vic_config vic_t194_config = {
.firmware = NVIDIA_TEGRA_194_VIC_FIRMWARE,
.version = 0x19,
.supports_sid = true,
+ .transcfg_offset = 0x2044,
};
#define NVIDIA_TEGRA_234_VIC_FIRMWARE "nvidia/tegra234/vic.bin"
@@ -433,6 +462,18 @@ static const struct vic_config vic_t234_config = {
.firmware = NVIDIA_TEGRA_234_VIC_FIRMWARE,
.version = 0x23,
.supports_sid = true,
+ .transcfg_offset = 0x2044,
+};
+
+#define NVIDIA_TEGRA_264_VIC_FIRMWARE "nvidia/tegra264/vic.bin"
+#define NVIDIA_TEGRA_264_VIC_DESC "nvidia/tegra264/vic.bin.desc"
+
+static const struct vic_config vic_t264_config = {
+ .firmware = NVIDIA_TEGRA_264_VIC_FIRMWARE,
+ .version = 0x264,
+ .supports_sid = true,
+ .has_riscv = true,
+ .transcfg_offset = 0x2244,
};
static const struct of_device_id tegra_vic_of_match[] = {
@@ -441,6 +482,7 @@ static const struct of_device_id tegra_vic_of_match[] = {
{ .compatible = "nvidia,tegra186-vic", .data = &vic_t186_config },
{ .compatible = "nvidia,tegra194-vic", .data = &vic_t194_config },
{ .compatible = "nvidia,tegra234-vic", .data = &vic_t234_config },
+ { .compatible = "nvidia,tegra264-vic", .data = &vic_t264_config },
{ },
};
MODULE_DEVICE_TABLE(of, tegra_vic_of_match);
@@ -495,6 +537,7 @@ static int vic_probe(struct platform_device *pdev)
vic->falcon.dev = dev;
vic->falcon.regs = vic->regs;
+ vic->falcon.riscv = vic->config->has_riscv;
err = falcon_init(&vic->falcon);
if (err < 0)
@@ -571,3 +614,7 @@ MODULE_FIRMWARE(NVIDIA_TEGRA_194_VIC_FIRMWARE);
#if IS_ENABLED(CONFIG_ARCH_TEGRA_234_SOC)
MODULE_FIRMWARE(NVIDIA_TEGRA_234_VIC_FIRMWARE);
#endif
+#if IS_ENABLED(CONFIG_ARCH_TEGRA_264_SOC)
+MODULE_FIRMWARE(NVIDIA_TEGRA_264_VIC_FIRMWARE);
+MODULE_FIRMWARE(NVIDIA_TEGRA_264_VIC_DESC);
+#endif
diff --git a/drivers/gpu/drm/tegra/vic.h b/drivers/gpu/drm/tegra/vic.h
index acf35aac948b..e525a06daaba 100644
--- a/drivers/gpu/drm/tegra/vic.h
+++ b/drivers/gpu/drm/tegra/vic.h
@@ -21,11 +21,10 @@
#define CG_IDLE_CG_EN (1 << 6)
#define CG_WAKEUP_DLY_CNT(val) ((val & 0xf) << 16)
-#define VIC_TFBIF_TRANSCFG 0x00002044
-#define TRANSCFG_ATT(i, v) (((v) & 0x3) << (i * 4))
-#define TRANSCFG_SID_HW 0
-#define TRANSCFG_SID_PHY 1
-#define TRANSCFG_SID_FALCON 2
+#define TRANSCFG_ATT(i, v) (((v) & 0x3) << (i * 4))
+#define TRANSCFG_SID_HW 0
+#define TRANSCFG_SID_PHY 1
+#define TRANSCFG_SID_FALCON 2
/* Firmware offsets */
--
2.53.0
^ permalink raw reply related
* [PATCH 5/7] drm/tegra: falcon: Add support for RISC-V external boot
From: Mikko Perttunen @ 2026-06-12 6:32 UTC (permalink / raw)
To: Thierry Reding, Jonathan Hunter, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-tegra, dri-devel, devicetree, linux-kernel, Mikko Perttunen
In-Reply-To: <20260612-t264-host1x-v1-0-8d934987de67@nvidia.com>
Add support for loading and booting RISC-V firmwares on Falcons with
RISC-V hardware. The flow is mostly the same as for traditional
Falcons, with a few different registers and different firmware layout.
Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
---
drivers/gpu/drm/tegra/falcon.c | 66 +++++++++++++++++++++++++++++++++++-------
drivers/gpu/drm/tegra/falcon.h | 23 +++++++++++++++
2 files changed, 79 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/tegra/falcon.c b/drivers/gpu/drm/tegra/falcon.c
index 17f616bbcb45..1172356b6af3 100644
--- a/drivers/gpu/drm/tegra/falcon.c
+++ b/drivers/gpu/drm/tegra/falcon.c
@@ -26,8 +26,12 @@ int falcon_wait_idle(struct falcon *falcon)
{
u32 value;
- return readl_poll_timeout(falcon->regs + FALCON_IDLESTATE, value,
- (value == 0), 10, 100000);
+ if (falcon->riscv)
+ return readl_poll_timeout(falcon->regs + RISCV_CPUCTL, value,
+ (value & RISCV_CPUCTL_ACTIVE_STAT_ACTIVE), 10, 100000);
+ else
+ return readl_poll_timeout(falcon->regs + FALCON_IDLESTATE, value,
+ (value == 0), 10, 100000);
}
static int falcon_dma_wait_not_full(struct falcon *falcon)
@@ -122,6 +126,17 @@ static int falcon_parse_firmware_image(struct falcon *falcon)
return 0;
}
+static void falcon_parse_firmware_desc(struct falcon *falcon)
+{
+ struct falcon_fw_riscv_desc *desc =
+ (struct falcon_fw_riscv_desc *)falcon->firmware.desc_firmware->data;
+
+ falcon->firmware.code.offset = desc->code_offset;
+ falcon->firmware.code.size = desc->code_size;
+ falcon->firmware.data.offset = desc->data_offset;
+ falcon->firmware.data.size = desc->data_size;
+}
+
int falcon_read_firmware(struct falcon *falcon, const char *name)
{
int err;
@@ -133,7 +148,23 @@ int falcon_read_firmware(struct falcon *falcon, const char *name)
falcon->firmware.size = falcon->firmware.firmware->size;
+ if (falcon->riscv) {
+ /* Load separate descriptor */
+ char desc_name[128];
+
+ scnprintf(desc_name, sizeof(desc_name), "%s.desc", name);
+ err = request_firmware(&falcon->firmware.desc_firmware, desc_name, falcon->dev);
+ if (err < 0)
+ goto release_firmware;
+ }
+
return 0;
+
+release_firmware:
+ release_firmware(falcon->firmware.firmware);
+ falcon->firmware.firmware = NULL;
+
+ return err;
}
int falcon_load_firmware(struct falcon *falcon)
@@ -144,16 +175,22 @@ int falcon_load_firmware(struct falcon *falcon)
/* copy firmware image into local area. this also ensures endianness */
falcon_copy_firmware_image(falcon, firmware);
- /* parse the image data */
- err = falcon_parse_firmware_image(falcon);
- if (err < 0) {
- dev_err(falcon->dev, "failed to parse firmware image\n");
- return err;
+ if (falcon->riscv) {
+ falcon_parse_firmware_desc(falcon);
+ } else {
+ err = falcon_parse_firmware_image(falcon);
+ if (err < 0) {
+ dev_err(falcon->dev, "failed to parse firmware image\n");
+ return err;
+ }
}
release_firmware(firmware);
falcon->firmware.firmware = NULL;
+ release_firmware(falcon->firmware.desc_firmware);
+ falcon->firmware.desc_firmware = NULL;
+
return 0;
}
@@ -168,6 +205,9 @@ void falcon_exit(struct falcon *falcon)
{
if (falcon->firmware.firmware)
release_firmware(falcon->firmware.firmware);
+
+ if (falcon->firmware.desc_firmware)
+ release_firmware(falcon->firmware.desc_firmware);
}
int falcon_boot(struct falcon *falcon)
@@ -229,9 +269,15 @@ int falcon_boot(struct falcon *falcon)
FALCON_ITFEN_CTXEN,
FALCON_ITFEN);
- /* boot falcon */
- falcon_writel(falcon, 0x00000000, FALCON_BOOTVEC);
- falcon_writel(falcon, FALCON_CPUCTL_STARTCPU, FALCON_CPUCTL);
+ if (falcon->riscv) {
+ falcon_writel(falcon, RISCV_BCR_CTRL_CORE_SELECT_RISCV, RISCV_BCR_CTRL);
+ falcon_writel(falcon, 0x0, RISCV_BOOT_VECTOR_HI);
+ falcon_writel(falcon, 0x100000, RISCV_BOOT_VECTOR_LO);
+ falcon_writel(falcon, RISCV_CPUCTL_STARTCPU, RISCV_CPUCTL);
+ } else {
+ falcon_writel(falcon, 0x00000000, FALCON_BOOTVEC);
+ falcon_writel(falcon, FALCON_CPUCTL_STARTCPU, FALCON_CPUCTL);
+ }
err = falcon_wait_idle(falcon);
if (err < 0) {
diff --git a/drivers/gpu/drm/tegra/falcon.h b/drivers/gpu/drm/tegra/falcon.h
index 902bb7e4fd0f..37a17c6136b3 100644
--- a/drivers/gpu/drm/tegra/falcon.h
+++ b/drivers/gpu/drm/tegra/falcon.h
@@ -55,6 +55,16 @@
#define FALCON_DMATRFFBOFFS 0x0000111c
+#define RISCV_BOOT_VECTOR_LO 0x00001780
+#define RISCV_BOOT_VECTOR_HI 0x00001784
+
+#define RISCV_CPUCTL 0x00001788
+#define RISCV_CPUCTL_STARTCPU (1 << 0)
+#define RISCV_CPUCTL_ACTIVE_STAT_ACTIVE (1 << 7)
+
+#define RISCV_BCR_CTRL 0x00001a68
+#define RISCV_BCR_CTRL_CORE_SELECT_RISCV (1 << 4)
+
struct falcon_fw_bin_header_v1 {
u32 magic; /* 0x10de */
u32 version; /* version of bin format (1) */
@@ -76,6 +86,14 @@ struct falcon_fw_os_header_v1 {
u32 data_size;
};
+struct falcon_fw_riscv_desc {
+ u32 reserved[74];
+ u32 data_offset;
+ u32 data_size;
+ u32 code_offset;
+ u32 code_size;
+};
+
struct falcon_firmware_section {
unsigned long offset;
size_t size;
@@ -84,6 +102,8 @@ struct falcon_firmware_section {
struct falcon_firmware {
/* Firmware after it is read but not loaded */
const struct firmware *firmware;
+ /* RISC-V firmware descriptor */
+ const struct firmware *desc_firmware;
/* Raw firmware data */
dma_addr_t iova;
@@ -102,6 +122,9 @@ struct falcon {
struct device *dev;
void __iomem *regs;
+ /* Peregrine falcon, external boot */
+ bool riscv;
+
struct falcon_firmware firmware;
};
--
2.53.0
^ permalink raw reply related
* [PATCH 4/7] gpu: host1x: Add Tegra264 support
From: Mikko Perttunen @ 2026-06-12 6:32 UTC (permalink / raw)
To: Thierry Reding, Jonathan Hunter, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-tegra, dri-devel, devicetree, linux-kernel, Santosh BS,
Mikko Perttunen
In-Reply-To: <20260612-t264-host1x-v1-0-8d934987de67@nvidia.com>
From: Santosh BS <santoshb@nvidia.com>
Add device data and chip headers for Tegra264.
Signed-off-by: Santosh BS <santoshb@nvidia.com>
Co-developed-by: Mikko Perttunen <mperttunen@nvidia.com>
Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
---
drivers/gpu/host1x/Makefile | 3 +-
drivers/gpu/host1x/dev.c | 41 ++++++
drivers/gpu/host1x/hw/cdma_hw.c | 12 +-
drivers/gpu/host1x/hw/host1x10.c | 33 +++++
drivers/gpu/host1x/hw/host1x10.h | 15 ++
drivers/gpu/host1x/hw/host1x10_hardware.h | 21 +++
drivers/gpu/host1x/hw/hw_host1x10_common.h | 6 +
drivers/gpu/host1x/hw/hw_host1x10_hypervisor.h | 10 ++
drivers/gpu/host1x/hw/hw_host1x10_uclass.h | 181 +++++++++++++++++++++++++
drivers/gpu/host1x/hw/hw_host1x10_vm.h | 36 +++++
10 files changed, 352 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/host1x/Makefile b/drivers/gpu/host1x/Makefile
index fead483af0b4..b684fbf73841 100644
--- a/drivers/gpu/host1x/Makefile
+++ b/drivers/gpu/host1x/Makefile
@@ -17,7 +17,8 @@ host1x-y = \
hw/host1x05.o \
hw/host1x06.o \
hw/host1x07.o \
- hw/host1x08.o
+ hw/host1x08.o \
+ hw/host1x10.o
host1x-$(CONFIG_IOMMU_API) += \
context.o
diff --git a/drivers/gpu/host1x/dev.c b/drivers/gpu/host1x/dev.c
index 3f475f0e6545..d2c64728f804 100644
--- a/drivers/gpu/host1x/dev.c
+++ b/drivers/gpu/host1x/dev.c
@@ -41,6 +41,7 @@
#include "hw/host1x06.h"
#include "hw/host1x07.h"
#include "hw/host1x08.h"
+#include "hw/host1x10.h"
void host1x_common_writel(struct host1x *host1x, u32 v, u32 r)
{
@@ -287,7 +288,47 @@ static const struct host1x_info host1x08_info = {
.reserve_vblank_syncpts = false,
};
+static const struct host1x_sid_entry tegra264_sid_table[] = {
+ { /* SE1 MMIO */ .base = 0x1650, .offset = 0x90, .limit = 0x90 },
+ { /* SE2 MMIO */ .base = 0x1658, .offset = 0x90, .limit = 0x90 },
+ { /* SE4 MMIO */ .base = 0x1660, .offset = 0x90, .limit = 0x90 },
+ { /* SE1 ch */ .base = 0x1738, .offset = 0x90, .limit = 0x90 },
+ { /* SE2 ch */ .base = 0x1740, .offset = 0x90, .limit = 0x90 },
+ { /* SE4 ch */ .base = 0x1748, .offset = 0x90, .limit = 0x90 },
+ { /* VIC ch */ .base = 0x1790, .offset = 0x30, .limit = 0x30 },
+ { /* VIC MMIO */ .base = 0x1688, .offset = 0x34, .limit = 0x34 },
+ { /* TSEC MMIO */ .base = 0x1690, .offset = 0x30, .limit = 0x34 },
+ { /* VI MMIO */ .base = 0x1698, .offset = 0x800, .limit = 0x800 },
+ { /* VI_THI MMIO */ .base = 0x16a0, .offset = 0x30, .limit = 0x34 },
+ { /* ISP MMIO */ .base = 0x1680, .offset = 0x800, .limit = 0x800 },
+ { /* ISP_THI MMIO */ .base = 0x16a8, .offset = 0x30, .limit = 0x34 },
+ { /* VI2 MMIO */ .base = 0x16b8, .offset = 0x800, .limit = 0x800 },
+ { /* VI2_THI MMIO */ .base = 0x16c0, .offset = 0x30, .limit = 0x34 },
+ { /* ISP1 MMIO */ .base = 0x16c8, .offset = 0x800, .limit = 0x800 },
+ { /* ISP1_THI MMIO */ .base = 0x16d0, .offset = 0x30, .limit = 0x34 },
+};
+
+static const struct host1x_info host1x10_info = {
+ .nb_channels = 63,
+ .nb_pts = 1024,
+ .nb_mlocks = 24,
+ .nb_bases = 0,
+ .init = host1x10_init,
+ .sync_offset = 0x0,
+ .dma_mask = DMA_BIT_MASK(40),
+ .has_wide_gather = true,
+ .has_hypervisor = true,
+ .has_common = true,
+ .num_sid_entries = ARRAY_SIZE(tegra264_sid_table),
+ .sid_table = tegra264_sid_table,
+ .streamid_vm_table = { 0x1004, 128 },
+ .classid_vm_table = { 0x1404, 25 },
+ .mmio_vm_table = { 0x1504, 25 },
+ .reserve_vblank_syncpts = false,
+};
+
static const struct of_device_id host1x_of_match[] = {
+ { .compatible = "nvidia,tegra264-host1x", .data = &host1x10_info, },
{ .compatible = "nvidia,tegra234-host1x", .data = &host1x08_info, },
{ .compatible = "nvidia,tegra194-host1x", .data = &host1x07_info, },
{ .compatible = "nvidia,tegra186-host1x", .data = &host1x06_info, },
diff --git a/drivers/gpu/host1x/hw/cdma_hw.c b/drivers/gpu/host1x/hw/cdma_hw.c
index 3f3f0018eee0..e43a9cf20c27 100644
--- a/drivers/gpu/host1x/hw/cdma_hw.c
+++ b/drivers/gpu/host1x/hw/cdma_hw.c
@@ -246,23 +246,24 @@ static void timeout_release_mlock(struct host1x_cdma *cdma)
* so it turns out that if we don't /actually/ need MLOCKs, we can just
* ignore them.
*
- * As such, for now just implement this on Tegra234 where things are
- * stricter but also easy to implement.
+ * As such, for now just implement this on Tegra234 and above where things
+ * are stricter but also easy to implement.
*/
struct host1x_channel *ch = cdma_to_channel(cdma);
struct host1x *host1x = cdma_to_host1x(cdma);
u32 offset;
switch (ch->client->class) {
+ case HOST1X_CLASS_VIC:
+ offset = HOST1X_COMMON_VIC_MLOCK;
+ break;
+#if HOST1X_HW == 8
case HOST1X_CLASS_NVJPG1:
offset = HOST1X_COMMON_NVJPG1_MLOCK;
break;
case HOST1X_CLASS_NVENC:
offset = HOST1X_COMMON_NVENC_MLOCK;
break;
- case HOST1X_CLASS_VIC:
- offset = HOST1X_COMMON_VIC_MLOCK;
- break;
case HOST1X_CLASS_NVJPG:
offset = HOST1X_COMMON_NVJPG_MLOCK;
break;
@@ -272,6 +273,7 @@ static void timeout_release_mlock(struct host1x_cdma *cdma)
case HOST1X_CLASS_OFA:
offset = HOST1X_COMMON_OFA_MLOCK;
break;
+#endif
default:
WARN(1, "%s was not updated for class %u", __func__, ch->client->class);
return;
diff --git a/drivers/gpu/host1x/hw/host1x10.c b/drivers/gpu/host1x/hw/host1x10.c
new file mode 100644
index 000000000000..2800f309bf6f
--- /dev/null
+++ b/drivers/gpu/host1x/hw/host1x10.c
@@ -0,0 +1,33 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Host1x init for Tegra264 SoCs
+ *
+ * Copyright (c) 2023 NVIDIA CORPORATION & AFFILIATES. All rights reserved.
+ */
+
+/* include hw specification */
+#include "host1x10.h"
+#include "host1x10_hardware.h"
+
+/* include code */
+#define HOST1X_HW 10
+
+#include "cdma_hw.c"
+#include "channel_hw.c"
+#include "debug_hw.c"
+#include "intr_hw.c"
+#include "syncpt_hw.c"
+
+#include "../dev.h"
+
+int host1x10_init(struct host1x *host)
+{
+ host->channel_op = &host1x_channel_ops;
+ host->cdma_op = &host1x_cdma_ops;
+ host->cdma_pb_op = &host1x_pushbuffer_ops;
+ host->syncpt_op = &host1x_syncpt_ops;
+ host->intr_op = &host1x_intr_ops;
+ host->debug_op = &host1x_debug_ops;
+
+ return 0;
+}
diff --git a/drivers/gpu/host1x/hw/host1x10.h b/drivers/gpu/host1x/hw/host1x10.h
new file mode 100644
index 000000000000..577f6ff3dff5
--- /dev/null
+++ b/drivers/gpu/host1x/hw/host1x10.h
@@ -0,0 +1,15 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Host1x init for Tegra264 SoCs
+ *
+ * Copyright (c) 2023 NVIDIA CORPORATION & AFFILIATES. All rights reserved.
+ */
+
+#ifndef HOST1X_HOST1X10_H
+#define HOST1X_HOST1X10_H
+
+struct host1x;
+
+int host1x10_init(struct host1x *host);
+
+#endif
diff --git a/drivers/gpu/host1x/hw/host1x10_hardware.h b/drivers/gpu/host1x/hw/host1x10_hardware.h
new file mode 100644
index 000000000000..abbead8190b1
--- /dev/null
+++ b/drivers/gpu/host1x/hw/host1x10_hardware.h
@@ -0,0 +1,21 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Tegra host1x Register Offsets for Tegra264
+ *
+ * Copyright (c) 2023 NVIDIA CORPORATION & AFFILIATES. All rights reserved.
+ */
+
+#ifndef __HOST1X_HOST1X10_HARDWARE_H
+#define __HOST1X_HOST1X10_HARDWARE_H
+
+#include <linux/types.h>
+#include <linux/bitops.h>
+
+#include "hw_host1x10_uclass.h"
+#include "hw_host1x10_vm.h"
+#include "hw_host1x10_hypervisor.h"
+#include "hw_host1x10_common.h"
+
+#include "opcodes.h"
+
+#endif
diff --git a/drivers/gpu/host1x/hw/hw_host1x10_common.h b/drivers/gpu/host1x/hw/hw_host1x10_common.h
new file mode 100644
index 000000000000..48a632672a47
--- /dev/null
+++ b/drivers/gpu/host1x/hw/hw_host1x10_common.h
@@ -0,0 +1,6 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (c) 2023 NVIDIA CORPORATION & AFFILIATES. All rights reserved.
+ */
+
+#define HOST1X_COMMON_VIC_MLOCK 0x4060
diff --git a/drivers/gpu/host1x/hw/hw_host1x10_hypervisor.h b/drivers/gpu/host1x/hw/hw_host1x10_hypervisor.h
new file mode 100644
index 000000000000..8c9069caffa8
--- /dev/null
+++ b/drivers/gpu/host1x/hw/hw_host1x10_hypervisor.h
@@ -0,0 +1,10 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (c) 2023 NVIDIA CORPORATION & AFFILIATES. All rights reserved.
+ */
+
+#define HOST1X_HV_SYNCPT_PROT_EN 0x172c
+#define HOST1X_HV_SYNCPT_PROT_EN_CH_EN BIT(1)
+#define HOST1X_HV_CH_MLOCK_EN(x) (0x1708 + (x * 4))
+#define HOST1X_HV_CH_KERNEL_FILTER_GBUFFER(x) (0x1718 + (x * 4))
+#define HOST1X_HV_SYNCPT_VM(x) (0x0 + 4 * (x))
diff --git a/drivers/gpu/host1x/hw/hw_host1x10_uclass.h b/drivers/gpu/host1x/hw/hw_host1x10_uclass.h
new file mode 100644
index 000000000000..abe83e67fa83
--- /dev/null
+++ b/drivers/gpu/host1x/hw/hw_host1x10_uclass.h
@@ -0,0 +1,181 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (c) 2023 NVIDIA CORPORATION & AFFILIATES. All rights reserved.
+ */
+
+ /*
+ * Function naming determines intended use:
+ *
+ * <x>_r(void) : Returns the offset for register <x>.
+ *
+ * <x>_w(void) : Returns the word offset for word (4 byte) element <x>.
+ *
+ * <x>_<y>_s(void) : Returns size of field <y> of register <x> in bits.
+ *
+ * <x>_<y>_f(u32 v) : Returns a value based on 'v' which has been shifted
+ * and masked to place it at field <y> of register <x>. This value
+ * can be |'d with others to produce a full register value for
+ * register <x>.
+ *
+ * <x>_<y>_m(void) : Returns a mask for field <y> of register <x>. This
+ * value can be ~'d and then &'d to clear the value of field <y> for
+ * register <x>.
+ *
+ * <x>_<y>_<z>_f(void) : Returns the constant value <z> after being shifted
+ * to place it at field <y> of register <x>. This value can be |'d
+ * with others to produce a full register value for <x>.
+ *
+ * <x>_<y>_v(u32 r) : Returns the value of field <y> from a full register
+ * <x> value 'r' after being shifted to place its LSB at bit 0.
+ * This value is suitable for direct comparison with other unshifted
+ * values appropriate for use in field <y> of register <x>.
+ *
+ * <x>_<y>_<z>_v(void) : Returns the constant value for <z> defined for
+ * field <y> of register <x>. This value is suitable for direct
+ * comparison with unshifted values appropriate for use in field <y>
+ * of register <x>.
+ */
+
+#ifndef HOST1X_HW_HOST1X10_UCLASS_H
+#define HOST1X_HW_HOST1X10_UCLASS_H
+
+static inline u32 host1x_uclass_incr_syncpt_r(void)
+{
+ return 0x0;
+}
+#define HOST1X_UCLASS_INCR_SYNCPT \
+ host1x_uclass_incr_syncpt_r()
+static inline u32 host1x_uclass_incr_syncpt_cond_f(u32 v)
+{
+ return (v & 0xff) << 10;
+}
+#define HOST1X_UCLASS_INCR_SYNCPT_COND_F(v) \
+ host1x_uclass_incr_syncpt_cond_f(v)
+static inline u32 host1x_uclass_incr_syncpt_indx_f(u32 v)
+{
+ return (v & 0x3ff) << 0;
+}
+#define HOST1X_UCLASS_INCR_SYNCPT_INDX_F(v) \
+ host1x_uclass_incr_syncpt_indx_f(v)
+static inline u32 host1x_uclass_wait_syncpt_r(void)
+{
+ return 0x8;
+}
+#define HOST1X_UCLASS_WAIT_SYNCPT \
+ host1x_uclass_wait_syncpt_r()
+static inline u32 host1x_uclass_wait_syncpt_indx_f(u32 v)
+{
+ return (v & 0xff) << 24;
+}
+#define HOST1X_UCLASS_WAIT_SYNCPT_INDX_F(v) \
+ host1x_uclass_wait_syncpt_indx_f(v)
+static inline u32 host1x_uclass_wait_syncpt_thresh_f(u32 v)
+{
+ return (v & 0xffffff) << 0;
+}
+#define HOST1X_UCLASS_WAIT_SYNCPT_THRESH_F(v) \
+ host1x_uclass_wait_syncpt_thresh_f(v)
+static inline u32 host1x_uclass_wait_syncpt_base_r(void)
+{
+ return 0x9;
+}
+#define HOST1X_UCLASS_WAIT_SYNCPT_BASE \
+ host1x_uclass_wait_syncpt_base_r()
+static inline u32 host1x_uclass_wait_syncpt_base_indx_f(u32 v)
+{
+ return (v & 0xff) << 24;
+}
+#define HOST1X_UCLASS_WAIT_SYNCPT_BASE_INDX_F(v) \
+ host1x_uclass_wait_syncpt_base_indx_f(v)
+static inline u32 host1x_uclass_wait_syncpt_base_base_indx_f(u32 v)
+{
+ return (v & 0xff) << 16;
+}
+#define HOST1X_UCLASS_WAIT_SYNCPT_BASE_BASE_INDX_F(v) \
+ host1x_uclass_wait_syncpt_base_base_indx_f(v)
+static inline u32 host1x_uclass_wait_syncpt_base_offset_f(u32 v)
+{
+ return (v & 0xffff) << 0;
+}
+#define HOST1X_UCLASS_WAIT_SYNCPT_BASE_OFFSET_F(v) \
+ host1x_uclass_wait_syncpt_base_offset_f(v)
+static inline u32 host1x_uclass_load_syncpt_base_r(void)
+{
+ return 0xb;
+}
+#define HOST1X_UCLASS_LOAD_SYNCPT_BASE \
+ host1x_uclass_load_syncpt_base_r()
+static inline u32 host1x_uclass_load_syncpt_base_base_indx_f(u32 v)
+{
+ return (v & 0xff) << 24;
+}
+#define HOST1X_UCLASS_LOAD_SYNCPT_BASE_BASE_INDX_F(v) \
+ host1x_uclass_load_syncpt_base_base_indx_f(v)
+static inline u32 host1x_uclass_load_syncpt_base_value_f(u32 v)
+{
+ return (v & 0xffffff) << 0;
+}
+#define HOST1X_UCLASS_LOAD_SYNCPT_BASE_VALUE_F(v) \
+ host1x_uclass_load_syncpt_base_value_f(v)
+static inline u32 host1x_uclass_incr_syncpt_base_base_indx_f(u32 v)
+{
+ return (v & 0xff) << 24;
+}
+#define HOST1X_UCLASS_INCR_SYNCPT_BASE_BASE_INDX_F(v) \
+ host1x_uclass_incr_syncpt_base_base_indx_f(v)
+static inline u32 host1x_uclass_incr_syncpt_base_offset_f(u32 v)
+{
+ return (v & 0xffffff) << 0;
+}
+#define HOST1X_UCLASS_INCR_SYNCPT_BASE_OFFSET_F(v) \
+ host1x_uclass_incr_syncpt_base_offset_f(v)
+static inline u32 host1x_uclass_indoff_r(void)
+{
+ return 0x2d;
+}
+#define HOST1X_UCLASS_INDOFF \
+ host1x_uclass_indoff_r()
+static inline u32 host1x_uclass_indoff_indbe_f(u32 v)
+{
+ return (v & 0xf) << 28;
+}
+#define HOST1X_UCLASS_INDOFF_INDBE_F(v) \
+ host1x_uclass_indoff_indbe_f(v)
+static inline u32 host1x_uclass_indoff_autoinc_f(u32 v)
+{
+ return (v & 0x1) << 27;
+}
+#define HOST1X_UCLASS_INDOFF_AUTOINC_F(v) \
+ host1x_uclass_indoff_autoinc_f(v)
+static inline u32 host1x_uclass_indoff_indmodid_f(u32 v)
+{
+ return (v & 0xff) << 18;
+}
+#define HOST1X_UCLASS_INDOFF_INDMODID_F(v) \
+ host1x_uclass_indoff_indmodid_f(v)
+static inline u32 host1x_uclass_indoff_indroffset_f(u32 v)
+{
+ return (v & 0xffff) << 2;
+}
+#define HOST1X_UCLASS_INDOFF_INDROFFSET_F(v) \
+ host1x_uclass_indoff_indroffset_f(v)
+static inline u32 host1x_uclass_indoff_rwn_read_v(void)
+{
+ return 1;
+}
+#define HOST1X_UCLASS_INDOFF_INDROFFSET_F(v) \
+ host1x_uclass_indoff_indroffset_f(v)
+static inline u32 host1x_uclass_load_syncpt_payload_32_r(void)
+{
+ return 0x4e;
+}
+#define HOST1X_UCLASS_LOAD_SYNCPT_PAYLOAD_32 \
+ host1x_uclass_load_syncpt_payload_32_r()
+static inline u32 host1x_uclass_wait_syncpt_32_r(void)
+{
+ return 0x50;
+}
+#define HOST1X_UCLASS_WAIT_SYNCPT_32 \
+ host1x_uclass_wait_syncpt_32_r()
+
+#endif
diff --git a/drivers/gpu/host1x/hw/hw_host1x10_vm.h b/drivers/gpu/host1x/hw/hw_host1x10_vm.h
new file mode 100644
index 000000000000..75f5b881c561
--- /dev/null
+++ b/drivers/gpu/host1x/hw/hw_host1x10_vm.h
@@ -0,0 +1,36 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (c) 2023 NVIDIA CORPORATION & AFFILIATES. All rights reserved.
+ */
+
+#define HOST1X_CHANNEL_DMASTART 0x0000
+#define HOST1X_CHANNEL_DMASTART_HI 0x0004
+#define HOST1X_CHANNEL_DMAPUT 0x0008
+#define HOST1X_CHANNEL_DMAPUT_HI 0x000c
+#define HOST1X_CHANNEL_DMAGET 0x0010
+#define HOST1X_CHANNEL_DMAGET_HI 0x0014
+#define HOST1X_CHANNEL_DMAEND 0x0018
+#define HOST1X_CHANNEL_DMAEND_HI 0x001c
+#define HOST1X_CHANNEL_DMACTRL 0x0020
+#define HOST1X_CHANNEL_DMACTRL_DMASTOP BIT(0)
+#define HOST1X_CHANNEL_DMACTRL_DMAGETRST BIT(1)
+#define HOST1X_CHANNEL_DMACTRL_DMAINITGET BIT(2)
+#define HOST1X_CHANNEL_CMDFIFO_STAT 0x0024
+#define HOST1X_CHANNEL_CMDFIFO_STAT_EMPTY BIT(13)
+#define HOST1X_CHANNEL_CMDFIFO_RDATA 0x0028
+#define HOST1X_CHANNEL_CMDP_OFFSET 0x0030
+#define HOST1X_CHANNEL_CMDP_CLASS 0x0034
+#define HOST1X_CHANNEL_CHANNELSTAT 0x0038
+#define HOST1X_CHANNEL_CMDPROC_STOP 0x0048
+#define HOST1X_CHANNEL_TEARDOWN 0x004c
+#define HOST1X_CHANNEL_SMMU_STREAMID 0x0084
+
+#define HOST1X_SYNC_SYNCPT_CPU_INCR(x) (0x6400 + 4 * (x))
+#define HOST1X_SYNC_SYNCPT_THRESH_CPU0_INT_STATUS(x) (0x6600 + 4 * (x))
+#define HOST1X_SYNC_SYNCPT_INTR_DEST(x) (0x6684 + 4 * (x))
+#define HOST1X_SYNC_SYNCPT_THRESH_INT_ENABLE_CPU0(x) (0x770c + 4 * (x))
+#define HOST1X_SYNC_SYNCPT_THRESH_INT_DISABLE(x) (0x7790 + 4 * (x))
+#define HOST1X_SYNC_SYNCPT(x) (0x8080 + 4 * (x))
+#define HOST1X_SYNC_SYNCPT_INT_THRESH(x) (0xa088 + 4 * (x))
+#define HOST1X_SYNC_SYNCPT_CH_APP(x) (0xb090 + 4 * (x))
+#define HOST1X_SYNC_SYNCPT_CH_APP_CH(v) (((v) & 0x3f) << 8)
--
2.53.0
^ permalink raw reply related
* [PATCH 3/7] gpu: host1x: Correctly parse linear ranges of context devices
From: Mikko Perttunen @ 2026-06-12 6:32 UTC (permalink / raw)
To: Thierry Reding, Jonathan Hunter, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-tegra, dri-devel, devicetree, linux-kernel, Mikko Perttunen
In-Reply-To: <20260612-t264-host1x-v1-0-8d934987de67@nvidia.com>
The previous parsing of the iommu-map property assumed each context
device has its own one-length entry in the device tree. This has worked
fine so far, but on Tegra264 larger numbers of context devices are
usable, so it's better to support linear ranges as well.
Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
---
drivers/gpu/host1x/context.c | 13 +++++++++++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/host1x/context.c b/drivers/gpu/host1x/context.c
index d50d41c20561..52ca663902ad 100644
--- a/drivers/gpu/host1x/context.c
+++ b/drivers/gpu/host1x/context.c
@@ -23,7 +23,7 @@ int host1x_memory_context_list_init(struct host1x *host1x)
struct host1x_memory_context_list *cdl = &host1x->context_list;
struct device_node *node = host1x->dev->of_node;
struct host1x_memory_context *ctx;
- unsigned int i;
+ unsigned int devs, i;
int err;
cdl->devs = NULL;
@@ -34,7 +34,16 @@ int host1x_memory_context_list_init(struct host1x *host1x)
if (err < 0)
return 0;
- cdl->len = err / 4;
+ devs = 0;
+
+ for (i = 0; i < err / 4; i++) {
+ u32 length;
+
+ of_property_read_u32_index(node, "iommu-map", i * 4 + 3, &length);
+ devs += length;
+ }
+
+ cdl->len = devs;
cdl->devs = kzalloc_objs(*cdl->devs, cdl->len);
if (!cdl->devs)
return -ENOMEM;
--
2.53.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox