On 6/26/2024 9:07 PM, Konrad Dybcio wrote:
On 26.06.2024 2:37 PM, Krishna chaitanya chundru wrote:
QPS615 switch needs to configured after powering on and before
PCIe link was up.
As the PCIe controller driver already enables the PCIe link training
at the host side, stop the link training.
Otherwise the moment we turn on the switch it will participate in
the link training and link may come before switch is configured through
i2c.
The switch can be configured different ways like changing de-emphasis
settings of the switch, disabling unused ports etc and these settings
can vary from board to board, for that reason the sequence is taken
from the firmware file which contains the address of the slave, to address
and data to be written to the switch. The driver reads the firmware file
and parses them to apply those configurations to the switch.
Signed-off-by: Krishna chaitanya chundru <quic_krichai@xxxxxxxxxxx>
---
[...]
+static int qcom_qps615_pwrctl_init(struct qcom_qps615_pwrctl_ctx *ctx)
+{
+ struct device *dev = ctx->pwrctl.dev;
+ struct qcom_qps615_pwrctl_i2c_setting *set;
+ const struct firmware *fw;
+ const u8 *pos, *eof;
+ int ret;
+ u32 val;
+
+ ret = request_firmware(&fw, "qcom/qps615.bin", dev);
Is this driver only going to serve one model of the device, that will use
this specific firmware file, ever?
In other words, is QPS615 super special and no other chip like it will be
ever made?
[...]
+
+ bridge->ops->stop_link(bus);
This is turbo intrusive. What if there are more devices on this bus?
The expectation of this API from the controller driver is to stop link
training only when the link is not up.
- krishna chaitanya.
Konrad
