* Re: [RFT PATCH v2 09/10] arm64: dts: microchip: sparx5_pcb134: drop duplicated NOR flash
From: Steen Hegelund @ 2024-04-08 8:44 UTC (permalink / raw)
To: Krzysztof Kozlowski, Conor Dooley, Nicolas Ferre, Claudiu Beznea,
Rob Herring, Krzysztof Kozlowski, Lars Povlsen, Daniel Machon,
UNGLinuxDriver, Bjarni Jonasson, David S. Miller,
linux-arm-kernel, devicetree, linux-kernel
Cc: horatiu.vultur
In-Reply-To: <20240405190419.74162-9-krzk@kernel.org>
Hi Krzysztof,
On Fri, 2024-04-05 at 21:04 +0200, Krzysztof Kozlowski wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you
> know the content is safe
>
> Since beginning the DTS extended the SPI0 in two places adding two
> SPI
> muxes, each with same SPI NOR flash. Both used exactly the same
> chip-selects, so this was clearly buggy code. Then in commit
> d0f482bb06f9 ("arm64: dts: sparx5: Add the Sparx5 switch node") one
> SPI
> mux was removed, while keeping the SPI NOR flash node.
>
> This still leaves duplicated SPI nodes under same chip select 0,
> reported by dtc W=1 warnings:
>
> sparx5_pcb134_board.dtsi:277.10-281.4: Warning
> (unique_unit_address_if_enabled):
> /axi@600000000/spi@600104000/flash@0: duplicate unit-address (also
> used in node /axi@600000000/spi@600104000/spi@0)
>
> Steen Hegelund confirmed that in fact there is a SPI mux, thus remove
> the duplicated node without the mux.
>
> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
>
> ---
>
> Not tested on hardware
>
> Changes in v2:
> 1. Remove SPI node without mux.
> ---
> arch/arm64/boot/dts/microchip/sparx5_pcb134_board.dtsi | 9 ---------
> 1 file changed, 9 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/microchip/sparx5_pcb134_board.dtsi
> b/arch/arm64/boot/dts/microchip/sparx5_pcb134_board.dtsi
> index f165a409bc1d..2c5574734c9e 100644
> --- a/arch/arm64/boot/dts/microchip/sparx5_pcb134_board.dtsi
> +++ b/arch/arm64/boot/dts/microchip/sparx5_pcb134_board.dtsi
> @@ -272,15 +272,6 @@ gpio@1 {
> };
> };
>
> -&spi0 {
> - status = "okay";
> - flash@0 {
> - compatible = "jedec,spi-nor";
> - spi-max-frequency = <8000000>;
> - reg = <0>;
> - };
> -};
> -
> &spi0 {
> status = "okay";
> spi@0 {
> --
> 2.34.1
>
This works fine on my setup now.
Thanks for the patch series.
For this patch:
Tested-by: Steen Hegelund <Steen.Hegelund@microchip.com>
For whole series:
Reviewed-by: Steen Hegelund <Steen.Hegelund@microchip.com>
^ permalink raw reply
* Re: [PATCH v9 00/13] Introduce STM32 Firewall framework
From: Alexandre TORGUE @ 2024-04-08 8:42 UTC (permalink / raw)
To: Gatien Chevallier, Oleksii_Moisieiev, gregkh, herbert, davem,
robh+dt, krzysztof.kozlowski+dt, conor+dt, vkoul, jic23,
olivier.moysan, arnaud.pouliquen, mchehab, fabrice.gasnier,
andi.shyti, ulf.hansson, edumazet, kuba, pabeni, hugues.fruchet,
lee, will, catalin.marinas, arnd, richardcochran, Frank Rowand,
peng.fan, lars, rcsekar, wg, mkl
Cc: linux-crypto, devicetree, linux-stm32, linux-arm-kernel,
linux-kernel, dmaengine, linux-i2c, linux-iio, alsa-devel,
linux-media, linux-mmc, netdev, linux-phy, linux-serial,
linux-spi, linux-usb
In-Reply-To: <20240105130404.301172-1-gatien.chevallier@foss.st.com>
Hi Gatien,
On 1/5/24 14:03, Gatien Chevallier wrote:
> Introduce STM32 Firewall framework for STM32MP1x and STM32MP2x
> platforms. STM32MP1x(ETZPC) and STM32MP2x(RIFSC) Firewall controllers
> register to the framework to offer firewall services such as access
> granting.
>
> This series of patches is a new approach on the previous STM32 system
> bus, history is available here:
> https://lore.kernel.org/lkml/20230127164040.1047583/
>
> The need for such framework arises from the fact that there are now
> multiple hardware firewalls implemented across multiple products.
> Drivers are shared between different products, using the same code.
> When it comes to firewalls, the purpose mostly stays the same: Protect
> hardware resources. But the implementation differs, and there are
> multiple types of firewalls: peripheral, memory, ...
>
> Some hardware firewall controllers such as the RIFSC implemented on
> STM32MP2x platforms may require to take ownership of a resource before
> being able to use it, hence the requirement for firewall services to
> take/release the ownership of such resources.
>
> On the other hand, hardware firewall configurations are becoming
> more and more complex. These mecanisms prevent platform crashes
> or other firewall-related incoveniences by denying access to some
> resources.
>
> The stm32 firewall framework offers an API that is defined in
> firewall controllers drivers to best fit the specificity of each
> firewall.
>
> For every peripherals protected by either the ETZPC or the RIFSC, the
> firewall framework checks the firewall controlelr registers to see if
> the peripheral's access is granted to the Linux kernel. If not, the
> peripheral is configured as secure, the node is marked populated,
> so that the driver is not probed for that device.
>
> The firewall framework relies on the access-controller device tree
> binding. It is used by peripherals to reference a domain access
> controller. In this case a firewall controller. The bus uses the ID
> referenced by the access-controller property to know where to look
> in the firewall to get the security configuration for the peripheral.
> This allows a device tree description rather than a hardcoded peripheral
> table in the bus driver.
>
> The STM32 ETZPC device is responsible for filtering accesses based on
> security level, or co-processor isolation for any resource connected
> to it.
>
> The RIFSC is responsible for filtering accesses based on Compartment
> ID / security level / privilege level for any resource connected to
> it.
>
> STM32MP13/15/25 SoC device tree files are updated in this series to
> implement this mecanism.
>
...
After minor cosmetic fixes, series applied on stm32-next.
Seen with Arnd: it will be part on my next PR and will come through
arm-soc tree.
Thanks
Alex
^ permalink raw reply
* Re: [RESEND v3 0/2] Add support for QCM6490 and QCS6490
From: Mohammad Rafi Shaik @ 2024-04-08 8:44 UTC (permalink / raw)
To: Krzysztof Kozlowski, Srinivas Kandagatla, Banajit Goswami,
Liam Girdwood, Mark Brown, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jaroslav Kysela, Takashi Iwai
Cc: linux-arm-msm, alsa-devel, linux-sound, devicetree, linux-kernel,
quic_rohkumar
In-Reply-To: <67ca18b4-0904-41e4-8218-ecb2016d532d@kernel.org>
On 4/8/2024 11:26 AM, Krzysztof Kozlowski wrote:
> On 08/04/2024 06:23, Mohammad Rafi Shaik wrote:
>> This patchset adds support for sound card on Qualcomm QCM6490 IDP and
>> QCS6490 RB3Gen2 boards.
>>
>> Changes since v2:
>> - Modify qcm6490 compatible name as qcm6490-idp. Suggested by Dmitry
>>
>> Changes since v1:
>> - Use existing sc8280xp machine driver instead of separate driver.
>> - Modify qcs6490 compatible name as qcs6490-rb3gen2.
>>
>
> Why are you resending 15 minutes after previous round?
>
> Best regards,
> Krzysztof
>
Found one mistake in cover-letter.
Instead of qcm6490-idp given qcs6490-idp.
Modified the cover-letter and reposted.
Thanks & Regards,
Rafi.
^ permalink raw reply
* Re: [RFT PATCH v2 10/10] arm64: dts: microchip: sparx5_pcb135: drop duplicated NOR flash
From: Steen Hegelund @ 2024-04-08 8:45 UTC (permalink / raw)
To: Krzysztof Kozlowski, Conor Dooley, Nicolas Ferre, Claudiu Beznea,
Rob Herring, Krzysztof Kozlowski, Lars Povlsen, Daniel Machon,
UNGLinuxDriver, Bjarni Jonasson, David S. Miller,
linux-arm-kernel, devicetree, linux-kernel
Cc: horatiu.vultur
In-Reply-To: <20240405190419.74162-10-krzk@kernel.org>
Hi Krzysztof,
On Fri, 2024-04-05 at 21:04 +0200, Krzysztof Kozlowski wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you
> know the content is safe
>
> Since beginning the DTS extended the SPI0 in two places adding two
> SPI
> muxes, each with same SPI NOR flash. Both used exactly the same
> chip-selects, so this was clearly buggy code. Then in commit
> d0f482bb06f9 ("arm64: dts: sparx5: Add the Sparx5 switch node") one
> SPI
> mux was removed, while keeping the SPI NOR flash node.
>
> This still leaves duplicated SPI nodes under same chip select 0,
> reported by dtc W=1 warnings:
>
> sparx5_pcb135_board.dtsi:92.10-96.4: Warning
> (unique_unit_address_if_enabled):
> /axi@600000000/spi@600104000/flash@0: duplicate unit-address (also
> used in node /axi@600000000/spi@600104000/spi@0)
>
> Steen Hegelund confirmed that in fact there is a SPI mux, thus remove
> the duplicated node without the mux.
>
> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
>
> ---
>
> Not tested on hardware
>
> Changes in v2:
> 1. Remove SPI node without mux.
> ---
> arch/arm64/boot/dts/microchip/sparx5_pcb135_board.dtsi | 9 ---------
> 1 file changed, 9 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/microchip/sparx5_pcb135_board.dtsi
> b/arch/arm64/boot/dts/microchip/sparx5_pcb135_board.dtsi
> index 20016efb3656..af2f1831f07f 100644
> --- a/arch/arm64/boot/dts/microchip/sparx5_pcb135_board.dtsi
> +++ b/arch/arm64/boot/dts/microchip/sparx5_pcb135_board.dtsi
> @@ -87,15 +87,6 @@ i2cmux_s32: i2cmux-3-pins {
> };
> };
>
> -&spi0 {
> - status = "okay";
> - flash@0 {
> - compatible = "jedec,spi-nor";
> - spi-max-frequency = <8000000>;
> - reg = <0>;
> - };
> -};
> -
> &spi0 {
> status = "okay";
> spi@0 {
> --
> 2.34.1
>
This also works fine on my setup now.
Thanks for the patch series.
For this patch:
Tested-by: Steen Hegelund <Steen.Hegelund@microchip.com>
BR
Steen
^ permalink raw reply
* Re: [PATCH] ARM: dts: stm32: move can3 node from stm32f746 to stm32f769
From: Alexandre TORGUE @ 2024-04-08 8:46 UTC (permalink / raw)
To: Dario Binacchi, linux-kernel
Cc: linux-amarula, Conor Dooley, Krzysztof Kozlowski, Maxime Coquelin,
Rob Herring, devicetree, linux-arm-kernel, linux-stm32
In-Reply-To: <20240325075635.1382911-1-dario.binacchi@amarulasolutions.com>
Hi Dario
On 3/25/24 08:56, Dario Binacchi wrote:
> According to documents [1], [2] and [3], we have 2 CAN devices on the
> stm32f746 platform and 3 on the stm32f769 platform. So let's move the
> can3 node from stm32f746.dtsi to stm32f769.dtsi.
>
> [1] https://www.st.com/en/microcontrollers-microprocessors/stm32f7-series.html
> [2] RM0385: STM32F75xxx and STM32F74xxx advanced Arm®-based 32-bit MCUs
> [3] RM0410: STM32F76xxx and STM32F77xxx advanced Arm®-based 32-bit MCUs
> Fixes: df362914eead ("ARM: dts: stm32: re-add CAN support on stm32f746")
> Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
>
> ---
>
>
Applied on stm32-next.
Cheers
Alex
^ permalink raw reply
* Re: [PATCH v2 11/11] iio: dac: support the ad9739a RF DAC
From: Nuno Sá @ 2024-04-08 8:51 UTC (permalink / raw)
To: Jonathan Cameron, Nuno Sa
Cc: linux-iio, devicetree, Dragos Bogdan, Lars-Peter Clausen,
Michael Hennerich, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Olivier Moysan
In-Reply-To: <20240406174119.38b821ff@jic23-huawei>
On Sat, 2024-04-06 at 17:41 +0100, Jonathan Cameron wrote:
> On Fri, 5 Apr 2024 17:00:09 +0200
> Nuno Sa <nuno.sa@analog.com> wrote:
>
> > The AD9739A is a 14-bit, 2.5 GSPS high performance RF DACs that are capable
> > of synthesizing wideband signals from DC up to 3 GHz.
> >
> > A dual-port, source synchronous, LVDS interface simplifies the digital
> > interface with existing FGPA/ASIC technology. On-chip controllers are used
> > to manage external and internal clock domain variations over temperature to
> > ensure reliable data transfer from the host to the DAC core.
> >
> > Co-developed-by: Dragos Bogdan <dragos.bogdan@analog.com>
> > Signed-off-by: Dragos Bogdan <dragos.bogdan@analog.com>
> > Signed-off-by: Nuno Sa <nuno.sa@analog.com>
>
> The only thing I really have remaining questions on is the choice
> of chan_spec with altvoltage and voltage channels. Why does that
> split make sense? It's odd enough that some comments in the code would
> be a good thing to add.
>
> Jonathan
>
> > new file mode 100644
> > index 000000000000..9b91d66f826c
> > --- /dev/null
> > +++ b/drivers/iio/dac/ad9739a.c
> > @@ -0,0 +1,454 @@
>
> > +
> > +static struct iio_chan_spec ad9739a_channels[] = {
> > + {
> > + .type = IIO_ALTVOLTAGE,
>
> So this looks a little unusual. Perhaps some comments on why it
> is appropriate to have this channel.
>
> In reality there is only one channel I think?
Yeah, I had this same discussion internally and was also thinking in having one
channel (just ALTVOLTAGE). I ended up doing it as we have done it internally so
far. The reasoning is that we have two sources of data:
ALTVOLTAGE: It's the internally continuous wave the backend can generate. That
is in fact alternate voltage.
VOLTAGE: Is kind of what I call external source where we assume is just typical
DAC data and that typically is VOLTAGE (but for a dac like this, I think it may
very well be, if not most of the time, also alternate - the thing is, we can't
know for sure as we should be able to have both)
- Nuno Sá
^ permalink raw reply
* Re: [PATCH v9 2/6] PCI: qcom: Add ICC bandwidth vote for CPU to PCIe path
From: Krishna Chaitanya Chundru @ 2024-04-08 8:53 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Lorenzo Pieralisi, Krzysztof Wilczyński,
Bjorn Helgaas, johan+linaro, bmasney, djakov, linux-arm-msm,
devicetree, linux-kernel, linux-pci, vireshk, quic_vbadigan,
quic_skananth, quic_nitegupt, quic_parass, krzysztof.kozlowski,
Bryan O'Donoghue
In-Reply-To: <20240407143902.GB2679@thinkpad>
On 4/7/2024 8:09 PM, Manivannan Sadhasivam wrote:
> On Sun, Apr 07, 2024 at 10:07:35AM +0530, Krishna chaitanya chundru wrote:
>> To access PCIe registers, PCIe BAR space, config space the CPU-PCIe
>
> Please specify whether you are referencing PCIe host controller or endpoint
> device or both.
>
>> ICC (interconnect consumers) path should be voted otherwise it may
>
> ICC is just 'Interconnect' unless I misunderstood.
>
>> lead to NoC (Network on chip) timeout. We are surviving because of
>> other driver vote for this path.
>>
>
> s/vote/voting
>
>> As there is less access on this path compared to PCIe to mem path
>> add minimum vote i.e 1KBps bandwidth always which is recommended
>> by HW team.
>>
>
> 'which is sufficient enough to keep the path active.'
>
>> When suspending, disable this path after register space access
>> is done.
>>
>> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
>> Signed-off-by: Krishna chaitanya chundru <quic_krichai@quicinc.com>
>> ---
>> drivers/pci/controller/dwc/pcie-qcom.c | 38 ++++++++++++++++++++++++++++++----
>> 1 file changed, 34 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/pci/controller/dwc/pcie-qcom.c b/drivers/pci/controller/dwc/pcie-qcom.c
>> index 14772edcf0d3..b4893214b2d3 100644
>> --- a/drivers/pci/controller/dwc/pcie-qcom.c
>> +++ b/drivers/pci/controller/dwc/pcie-qcom.c
>> @@ -245,6 +245,7 @@ struct qcom_pcie {
>> struct phy *phy;
>> struct gpio_desc *reset;
>> struct icc_path *icc_mem;
>> + struct icc_path *icc_cpu;
>> const struct qcom_pcie_cfg *cfg;
>> struct dentry *debugfs;
>> bool suspended;
>> @@ -1409,6 +1410,9 @@ static int qcom_pcie_icc_init(struct qcom_pcie *pcie)
>> if (IS_ERR(pcie->icc_mem))
>> return PTR_ERR(pcie->icc_mem);
>>
>> + pcie->icc_cpu = devm_of_icc_get(pci->dev, "cpu-pcie");
>> + if (IS_ERR(pcie->icc_cpu))
>> + return PTR_ERR(pcie->icc_cpu);
>> /*
>> * Some Qualcomm platforms require interconnect bandwidth constraints
>> * to be set before enabling interconnect clocks.
>> @@ -1418,7 +1422,19 @@ static int qcom_pcie_icc_init(struct qcom_pcie *pcie)
>> */
>> ret = icc_set_bw(pcie->icc_mem, 0, QCOM_PCIE_LINK_SPEED_TO_BW(1));
>> if (ret) {
>> - dev_err(pci->dev, "failed to set interconnect bandwidth: %d\n",
>> + dev_err(pci->dev, "failed to set interconnect bandwidth for PCIe-MEM: %d\n",
>> + ret);
>> + return ret;
>> + }
>> +
>> + /*
>> + * Since the CPU-PCIe path is only used for activities like register
>
> Again, differentiate PCIe controller and endpoint device access.
>
Ack to all comments. I will modify in next patch.
>> + * access, Config/BAR space access, HW team has recommended to use a
>> + * minimal bandwidth of 1KBps just to keep the link active.
>> + */
>> + ret = icc_set_bw(pcie->icc_cpu, 0, kBps_to_icc(1));
>> + if (ret) {
>> + dev_err(pci->dev, "failed to set interconnect bandwidth for CPU-PCIe: %d\n",
>> ret);
>> return ret;
>> }
>> @@ -1448,7 +1464,7 @@ static void qcom_pcie_icc_update(struct qcom_pcie *pcie)
>>
>> ret = icc_set_bw(pcie->icc_mem, 0, width * QCOM_PCIE_LINK_SPEED_TO_BW(speed));
>> if (ret) {
>> - dev_err(pci->dev, "failed to set interconnect bandwidth: %d\n",
>> + dev_err(pci->dev, "failed to set interconnect bandwidth for PCIe-MEM: %d\n",
>> ret);
>> }
>> }
>> @@ -1610,7 +1626,7 @@ static int qcom_pcie_suspend_noirq(struct device *dev)
>> */
>> ret = icc_set_bw(pcie->icc_mem, 0, kBps_to_icc(1));
>> if (ret) {
>> - dev_err(dev, "Failed to set interconnect bandwidth: %d\n", ret);
>> + dev_err(dev, "Failed to set interconnect bandwidth for PCIe-MEM: %d\n", ret);
>> return ret;
>> }
>>
>> @@ -1634,7 +1650,15 @@ static int qcom_pcie_suspend_noirq(struct device *dev)
>> pcie->suspended = true;
>> }
>>
>> - return 0;
>> + /*
>> + * Remove the vote for CPU-PCIe path now, since at this point onwards,
>> + * no register access will be done.
>> + */
>
> Are you sure? Didn't we see late access to DBI registers on sc7280?
>
yeah you are correct I will add a check to disable icc only in suspend
to idle case. only in suspend to ram case we see the DBI access in sc7280
-Krishna Chaitanya
>> + ret = icc_disable(pcie->icc_cpu);
>> + if (ret)
>> + dev_err(dev, "failed to disable icc path of CPU-PCIe: %d\n", ret);
>
> s/failed to disable icc path/Failed to disable Interconnect path between CPU-PCIe
>
>> +
>> + return ret;
>> }
>>
>> static int qcom_pcie_resume_noirq(struct device *dev)
>> @@ -1642,6 +1666,12 @@ static int qcom_pcie_resume_noirq(struct device *dev)
>> struct qcom_pcie *pcie = dev_get_drvdata(dev);
>> int ret;
>>
>> + ret = icc_enable(pcie->icc_cpu);
>> + if (ret) {
>> + dev_err(dev, "failed to enable icc path of CPU-PCIe: %d\n", ret);
>
> Same as above.
>
> - Mani
>
^ permalink raw reply
* Re: [PATCH v9 3/6] dt-bindings: pci: qcom: Add opp table
From: Krishna Chaitanya Chundru @ 2024-04-08 8:53 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Lorenzo Pieralisi, Krzysztof Wilczyński,
Bjorn Helgaas, johan+linaro, bmasney, djakov, linux-arm-msm,
devicetree, linux-kernel, linux-pci, vireshk, quic_vbadigan,
quic_skananth, quic_nitegupt, quic_parass, krzysztof.kozlowski
In-Reply-To: <20240407144227.GC2679@thinkpad>
Ack to all the comments. I will modify them in next patch series.
- Krishna Chaitanya.
On 4/7/2024 8:12 PM, Manivannan Sadhasivam wrote:
> On Sun, Apr 07, 2024 at 10:07:36AM +0530, Krishna chaitanya chundru wrote:
>
> s/opp/OPP
>
>> PCIe needs to choose the appropriate performance state of RPMH power
>
> s/RPMH/RPMh
>
>> domain based upon the PCIe gen speed.
>>
>
> s/upon/on
>
>> Adding the Operating Performance Points table allows to adjust power
>> domain performance state and icc peak bw, depending on the PCIe gen
>
> s/icc/ICC
>
> s/PCIe gen speed/PCIe data rate
>
>> speed and width.
>>
>
> s/width/link width
>
>> Signed-off-by: Krishna chaitanya chundru <quic_krichai@quicinc.com>
>
> With above changes,
>
> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
>
> - Mani
>
>> ---
>> Documentation/devicetree/bindings/pci/qcom,pcie-sm8450.yaml | 4 ++++
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/pci/qcom,pcie-sm8450.yaml b/Documentation/devicetree/bindings/pci/qcom,pcie-sm8450.yaml
>> index 1496d6993ab4..d8c0afaa4b19 100644
>> --- a/Documentation/devicetree/bindings/pci/qcom,pcie-sm8450.yaml
>> +++ b/Documentation/devicetree/bindings/pci/qcom,pcie-sm8450.yaml
>> @@ -69,6 +69,10 @@ properties:
>> - const: msi6
>> - const: msi7
>>
>> + operating-points-v2: true
>> + opp-table:
>> + type: object
>> +
>> resets:
>> maxItems: 1
>>
>>
>> --
>> 2.42.0
>>
>
^ permalink raw reply
* Re: [PATCH v2] ARM: dts: stm32: add heartbeat led for stm32mp157c-ed1
From: Alexandre TORGUE @ 2024-04-08 8:54 UTC (permalink / raw)
To: patrice.chotard, robh+dt, Krzysztof Kozlowski
Cc: linux-stm32, linux-arm-kernel, linux-kernel, devicetree
In-Reply-To: <20240326075438.2891335-1-patrice.chotard@foss.st.com>
Hi Patrice
On 3/26/24 08:54, patrice.chotard@foss.st.com wrote:
> From: Patrice Chotard <patrice.chotard@foss.st.com>
>
> Add heartbeat led for stm32mp157c-ed1.
>
> Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
> ---
>
> V2 changes :
> _ add color and function properties.
>
> arch/arm/boot/dts/st/stm32mp157c-ed1.dts | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> diff --git a/arch/arm/boot/dts/st/stm32mp157c-ed1.dts b/arch/arm/boot/dts/st/stm32mp157c-ed1.dts
> index 66ed5f9921ba..525d9ca7d576 100644
> --- a/arch/arm/boot/dts/st/stm32mp157c-ed1.dts
> +++ b/arch/arm/boot/dts/st/stm32mp157c-ed1.dts
> @@ -10,6 +10,7 @@
> #include "stm32mp15-pinctrl.dtsi"
> #include "stm32mp15xxaa-pinctrl.dtsi"
> #include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/leds/common.h>
> #include <dt-bindings/mfd/st,stpmic1.h>
>
> / {
> @@ -24,6 +25,17 @@ chosen {
> stdout-path = "serial0:115200n8";
> };
>
> + led {
> + compatible = "gpio-leds";
> + led-blue {
> + gpios = <&gpiod 9 GPIO_ACTIVE_HIGH>;
> + linux,default-trigger = "heartbeat";
> + default-state = "off";
> + function = LED_FUNCTION_HEARTBEAT;
> + color = <LED_COLOR_ID_BLUE>;
> + };
> + };
> +
> memory@c0000000 {
> device_type = "memory";
> reg = <0xC0000000 0x40000000>;
Applied on stm32-next.
thanks
Alex
^ permalink raw reply
* Re: [PATCH v9 6/6] PCI: qcom: Add OPP support to scale performance state of power domain
From: Krishna Chaitanya Chundru @ 2024-04-08 9:02 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Lorenzo Pieralisi, Krzysztof Wilczyński,
Bjorn Helgaas, johan+linaro, bmasney, djakov, linux-arm-msm,
devicetree, linux-kernel, linux-pci, vireshk, quic_vbadigan,
quic_skananth, quic_nitegupt, quic_parass, krzysztof.kozlowski
In-Reply-To: <20240407150048.GE2679@thinkpad>
On 4/7/2024 8:30 PM, Manivannan Sadhasivam wrote:
> On Sun, Apr 07, 2024 at 10:07:39AM +0530, Krishna chaitanya chundru wrote:
>> QCOM Resource Power Manager-hardened (RPMh) is a hardware block which
>> maintains hardware state of a regulator by performing max aggregation of
>> the requests made by all of the clients.
>>
>> PCIe controller can operate on different RPMh performance state of power
>> domain based on the speed of the link. And this performance state varies
>> from target to target, like some controllers support GEN3 in NOM (Nominal)
>> voltage corner, while some other supports GEN3 in low SVS (static voltage
>> scaling).
>>
>> The SoC can be more power efficient if we scale the performance state
>> based on the aggregate PCIe link bandwidth.
>>
>> Add Operating Performance Points (OPP) support to vote for RPMh state based
>> on the aggregate link bandwidth.
>>
>> OPP can handle ICC bw voting also, so move ICC bw voting through OPP
>> framework if OPP entries are present.
>>
>> Different link configurations may share the same aggregate bandwidth,
>> e.g., a 2.5 GT/s x2 link and a 5.0 GT/s x1 link have the same bandwidth
>> and share the same OPP entry.
>>
>
> This info should be part of the dts change.
>
ok I will move this to dts patch in next patch series.
>> As we are moving ICC voting as part of OPP, don't initialize ICC if OPP
>> is supported.
>>
>> Before PCIe link is initialized vote for highest OPP in the OPP table,
>> so that we are voting for maximum voltage corner for the link to come up
>> in maximum supported speed.
>>
>> Signed-off-by: Krishna chaitanya chundru <quic_krichai@quicinc.com>
>> ---
>> drivers/pci/controller/dwc/pcie-qcom.c | 72 +++++++++++++++++++++++++++-------
>> 1 file changed, 58 insertions(+), 14 deletions(-)
>>
>> diff --git a/drivers/pci/controller/dwc/pcie-qcom.c b/drivers/pci/controller/dwc/pcie-qcom.c
>> index b4893214b2d3..4ad5ef3bf8fc 100644
>> --- a/drivers/pci/controller/dwc/pcie-qcom.c
>> +++ b/drivers/pci/controller/dwc/pcie-qcom.c
>> @@ -22,6 +22,7 @@
>> #include <linux/of.h>
>> #include <linux/of_gpio.h>
>> #include <linux/pci.h>
>> +#include <linux/pm_opp.h>
>> #include <linux/pm_runtime.h>
>> #include <linux/platform_device.h>
>> #include <linux/phy/pcie.h>
>> @@ -1442,15 +1443,13 @@ static int qcom_pcie_icc_init(struct qcom_pcie *pcie)
>> return 0;
>> }
>>
>> -static void qcom_pcie_icc_update(struct qcom_pcie *pcie)
>> +static void qcom_pcie_icc_opp_update(struct qcom_pcie *pcie)
>> {
>> struct dw_pcie *pci = pcie->pci;
>> - u32 offset, status;
>> + u32 offset, status, freq;
>> + struct dev_pm_opp *opp;
>> int speed, width;
>> - int ret;
>> -
>> - if (!pcie->icc_mem)
>> - return;
>> + int ret, mbps;
>>
>> offset = dw_pcie_find_capability(pci, PCI_CAP_ID_EXP);
>> status = readw(pci->dbi_base + offset + PCI_EXP_LNKSTA);
>> @@ -1462,10 +1461,26 @@ static void qcom_pcie_icc_update(struct qcom_pcie *pcie)
>> speed = FIELD_GET(PCI_EXP_LNKSTA_CLS, status);
>> width = FIELD_GET(PCI_EXP_LNKSTA_NLW, status);
>>
>> - ret = icc_set_bw(pcie->icc_mem, 0, width * QCOM_PCIE_LINK_SPEED_TO_BW(speed));
>> - if (ret) {
>> - dev_err(pci->dev, "failed to set interconnect bandwidth for PCIe-MEM: %d\n",
>> - ret);
>> + if (pcie->icc_mem) {
>> + ret = icc_set_bw(pcie->icc_mem, 0, width * QCOM_PCIE_LINK_SPEED_TO_BW(speed));
>> + if (ret) {
>> + dev_err(pci->dev, "failed to set interconnect bandwidth for PCIe-MEM: %d\n",
>
> s/failed/Failed
>
>> + ret);
>> + }
>> + } else {
>> + mbps = pcie_link_speed_to_mbps(pcie_link_speed[speed]);
>> + if (mbps < 0)
>> + return;
>> +
>> + freq = mbps * 1000;
>> + opp = dev_pm_opp_find_freq_exact(pci->dev, freq * width, true);
>
> As per the API documentation, dev_pm_opp_put() should be called for both success
> and failure case.
>
ACK.
>> + if (!IS_ERR(opp)) {
>
> So what is the action if OPP is not found for the freq?
>
There is already a vote for maximum freq in the probe, so if it fails
here we can continue here.
If you feel otherwise let me know I Can make changes as suggested.
>> + ret = dev_pm_opp_set_opp(pci->dev, opp);
>> + if (ret)
>> + dev_err(pci->dev, "Failed to set opp: freq %ld ret %d\n",
>
> 'Failed to set OPP for freq (%ld): %d'
>
>> + dev_pm_opp_get_freq(opp), ret);
>> + dev_pm_opp_put(opp);
>> + }
>> }
>> }
>>
>> @@ -1509,8 +1524,10 @@ static void qcom_pcie_init_debugfs(struct qcom_pcie *pcie)
>> static int qcom_pcie_probe(struct platform_device *pdev)
>> {
>> const struct qcom_pcie_cfg *pcie_cfg;
>> + unsigned long max_freq = INT_MAX;
>> struct device *dev = &pdev->dev;
>> struct qcom_pcie *pcie;
>> + struct dev_pm_opp *opp;
>> struct dw_pcie_rp *pp;
>> struct resource *res;
>> struct dw_pcie *pci;
>> @@ -1577,9 +1594,33 @@ static int qcom_pcie_probe(struct platform_device *pdev)
>> goto err_pm_runtime_put;
>> }
>>
>> - ret = qcom_pcie_icc_init(pcie);
>> - if (ret)
>> + /* OPP table is optional */
>> + ret = devm_pm_opp_of_add_table(dev);
>> + if (ret && ret != -ENODEV) {
>> + dev_err_probe(dev, ret, "Failed to add OPP table\n");
>> goto err_pm_runtime_put;
>> + }
>> +
>> + /*
>> + * Use highest OPP here if the OPP table is present. At the end of
>
> I believe I asked you to add the information justifying why the highest OPP
> should be used.
>
I added the info in the commit message, I will add as the comment in the
next patch.
>> + * the probe(), OPP will be updated using qcom_pcie_icc_opp_update().
>> + */
>> + if (!ret) {
>> + opp = dev_pm_opp_find_freq_floor(dev, &max_freq);
>
> Same comment as dev_pm_opp_find_freq_exact().
>
>> + if (!IS_ERR(opp)) {
>> + ret = dev_pm_opp_set_opp(dev, opp);
>> + if (ret)
>> + dev_err_probe(pci->dev, ret,
>> + "Failed to set OPP: freq %ld\n",
>
> Same comment as above.
>
>> + dev_pm_opp_get_freq(opp));
>> + dev_pm_opp_put(opp);
>
> So you want to continue even in the case of failure?
>
I wil make changes to fallback to driver voting for icc bw if it fails here.
- Krishna chaitanya,
> - Mani
>
>> + }
>> + } else {
>> + /* Skip ICC init if OPP is supported as it is handled by OPP */
>> + ret = qcom_pcie_icc_init(pcie);
>> + if (ret)
>> + goto err_pm_runtime_put;
>> + }
>>
>> ret = pcie->cfg->ops->get_resources(pcie);
>> if (ret)
>> @@ -1599,7 +1640,7 @@ static int qcom_pcie_probe(struct platform_device *pdev)
>> goto err_phy_exit;
>> }
>>
>> - qcom_pcie_icc_update(pcie);
>> + qcom_pcie_icc_opp_update(pcie);
>>
>> if (pcie->mhi)
>> qcom_pcie_init_debugfs(pcie);
>> @@ -1658,6 +1699,9 @@ static int qcom_pcie_suspend_noirq(struct device *dev)
>> if (ret)
>> dev_err(dev, "failed to disable icc path of CPU-PCIe: %d\n", ret);
>>
>> + if (!pcie->icc_mem)
>> + dev_pm_opp_set_opp(pcie->pci->dev, NULL);
>> +
>> return ret;
>> }
>>
>> @@ -1680,7 +1724,7 @@ static int qcom_pcie_resume_noirq(struct device *dev)
>> pcie->suspended = false;
>> }
>>
>> - qcom_pcie_icc_update(pcie);
>> + qcom_pcie_icc_opp_update(pcie);
>>
>> return 0;
>> }
>>
>> --
>> 2.42.0
>>
>
^ permalink raw reply
* [PATCH 1/3] dt-bindings: pinctrl: mediatek: mt7622: fix array properties
From: Rafał Miłecki @ 2024-04-08 9:05 UTC (permalink / raw)
To: Sean Wang, Linus Walleij, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Matthias Brugger, AngeloGioacchino Del Regno, Hsin-Yi Wang,
linux-mediatek, linux-gpio, devicetree, linux-arm-kernel,
Rafał Miłecki
From: Rafał Miłecki <rafal@milecki.pl>
Some properties (function groups & pins) are meant to be arrays and
should allow multiple entries out of enum sets. Use "items" for those.
Mistake was noticed during validation of in-kernel DTS files.
Fixes: b9ffc18c6388 ("dt-bindings: mediatek: convert pinctrl to yaml")
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
---
.../pinctrl/mediatek,mt7622-pinctrl.yaml | 92 ++++++++++---------
1 file changed, 49 insertions(+), 43 deletions(-)
diff --git a/Documentation/devicetree/bindings/pinctrl/mediatek,mt7622-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/mediatek,mt7622-pinctrl.yaml
index bd72a326e6e0..60f30a59f385 100644
--- a/Documentation/devicetree/bindings/pinctrl/mediatek,mt7622-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/mediatek,mt7622-pinctrl.yaml
@@ -97,7 +97,8 @@ patternProperties:
then:
properties:
groups:
- enum: [emmc, emmc_rst]
+ items:
+ enum: [emmc, emmc_rst]
- if:
properties:
function:
@@ -105,8 +106,9 @@ patternProperties:
then:
properties:
groups:
- enum: [esw, esw_p0_p1, esw_p2_p3_p4, rgmii_via_esw,
- rgmii_via_gmac1, rgmii_via_gmac2, mdc_mdio]
+ items:
+ enum: [esw, esw_p0_p1, esw_p2_p3_p4, rgmii_via_esw,
+ rgmii_via_gmac1, rgmii_via_gmac2, mdc_mdio]
- if:
properties:
function:
@@ -123,10 +125,11 @@ patternProperties:
then:
properties:
groups:
- enum: [i2s_in_mclk_bclk_ws, i2s1_in_data, i2s2_in_data,
- i2s3_in_data, i2s4_in_data, i2s_out_mclk_bclk_ws,
- i2s1_out_data, i2s2_out_data, i2s3_out_data,
- i2s4_out_data]
+ items:
+ enum: [i2s_in_mclk_bclk_ws, i2s1_in_data, i2s2_in_data,
+ i2s3_in_data, i2s4_in_data, i2s_out_mclk_bclk_ws,
+ i2s1_out_data, i2s2_out_data, i2s3_out_data,
+ i2s4_out_data]
- if:
properties:
function:
@@ -159,10 +162,11 @@ patternProperties:
then:
properties:
groups:
- enum: [pcie0_0_waken, pcie0_1_waken, pcie1_0_waken,
- pcie0_0_clkreq, pcie0_1_clkreq, pcie1_0_clkreq,
- pcie0_pad_perst, pcie1_pad_perst, pcie_pereset,
- pcie_wake, pcie_clkreq]
+ items:
+ enum: [pcie0_0_waken, pcie0_1_waken, pcie1_0_waken,
+ pcie0_0_clkreq, pcie0_1_clkreq, pcie1_0_clkreq,
+ pcie0_pad_perst, pcie1_pad_perst, pcie_pereset,
+ pcie_wake, pcie_clkreq]
- if:
properties:
function:
@@ -178,11 +182,12 @@ patternProperties:
then:
properties:
groups:
- enum: [pwm_ch1_0, pwm_ch1_1, pwm_ch1_2, pwm_ch2_0, pwm_ch2_1,
- pwm_ch2_2, pwm_ch3_0, pwm_ch3_1, pwm_ch3_2, pwm_ch4_0,
- pwm_ch4_1, pwm_ch4_2, pwm_ch4_3, pwm_ch5_0, pwm_ch5_1,
- pwm_ch5_2, pwm_ch6_0, pwm_ch6_1, pwm_ch6_2, pwm_ch6_3,
- pwm_ch7_0, pwm_0, pwm_1]
+ items:
+ enum: [pwm_ch1_0, pwm_ch1_1, pwm_ch1_2, pwm_ch2_0, pwm_ch2_1,
+ pwm_ch2_2, pwm_ch3_0, pwm_ch3_1, pwm_ch3_2, pwm_ch4_0,
+ pwm_ch4_1, pwm_ch4_2, pwm_ch4_3, pwm_ch5_0, pwm_ch5_1,
+ pwm_ch5_2, pwm_ch6_0, pwm_ch6_1, pwm_ch6_2, pwm_ch6_3,
+ pwm_ch7_0, pwm_0, pwm_1]
- if:
properties:
function:
@@ -260,33 +265,34 @@ patternProperties:
pins:
description:
An array of strings. Each string contains the name of a pin.
- enum: [GPIO_A, I2S1_IN, I2S1_OUT, I2S_BCLK, I2S_WS, I2S_MCLK, TXD0,
- RXD0, SPI_WP, SPI_HOLD, SPI_CLK, SPI_MOSI, SPI_MISO, SPI_CS,
- I2C_SDA, I2C_SCL, I2S2_IN, I2S3_IN, I2S4_IN, I2S2_OUT,
- I2S3_OUT, I2S4_OUT, GPIO_B, MDC, MDIO, G2_TXD0, G2_TXD1,
- G2_TXD2, G2_TXD3, G2_TXEN, G2_TXC, G2_RXD0, G2_RXD1, G2_RXD2,
- G2_RXD3, G2_RXDV, G2_RXC, NCEB, NWEB, NREB, NDL4, NDL5, NDL6,
- NDL7, NRB, NCLE, NALE, NDL0, NDL1, NDL2, NDL3, MDI_TP_P0,
- MDI_TN_P0, MDI_RP_P0, MDI_RN_P0, MDI_TP_P1, MDI_TN_P1,
- MDI_RP_P1, MDI_RN_P1, MDI_RP_P2, MDI_RN_P2, MDI_TP_P2,
- MDI_TN_P2, MDI_TP_P3, MDI_TN_P3, MDI_RP_P3, MDI_RN_P3,
- MDI_RP_P4, MDI_RN_P4, MDI_TP_P4, MDI_TN_P4, PMIC_SCL,
- PMIC_SDA, SPIC1_CLK, SPIC1_MOSI, SPIC1_MISO, SPIC1_CS,
- GPIO_D, WATCHDOG, RTS3_N, CTS3_N, TXD3, RXD3, PERST0_N,
- PERST1_N, WLED_N, EPHY_LED0_N, AUXIN0, AUXIN1, AUXIN2,
- AUXIN3, TXD4, RXD4, RTS4_N, CST4_N, PWM1, PWM2, PWM3, PWM4,
- PWM5, PWM6, PWM7, GPIO_E, TOP_5G_CLK, TOP_5G_DATA,
- WF0_5G_HB0, WF0_5G_HB1, WF0_5G_HB2, WF0_5G_HB3, WF0_5G_HB4,
- WF0_5G_HB5, WF0_5G_HB6, XO_REQ, TOP_RST_N, SYS_WATCHDOG,
- EPHY_LED0_N_JTDO, EPHY_LED1_N_JTDI, EPHY_LED2_N_JTMS,
- EPHY_LED3_N_JTCLK, EPHY_LED4_N_JTRST_N, WF2G_LED_N,
- WF5G_LED_N, GPIO_9, GPIO_10, GPIO_11, GPIO_12, UART1_TXD,
- UART1_RXD, UART1_CTS, UART1_RTS, UART2_TXD, UART2_RXD,
- UART2_CTS, UART2_RTS, SMI_MDC, SMI_MDIO, PCIE_PERESET_N,
- PWM_0, GPIO_0, GPIO_1, GPIO_2, GPIO_3, GPIO_4, GPIO_5,
- GPIO_6, GPIO_7, GPIO_8, UART0_TXD, UART0_RXD, TOP_2G_CLK,
- TOP_2G_DATA, WF0_2G_HB0, WF0_2G_HB1, WF0_2G_HB2, WF0_2G_HB3,
- WF0_2G_HB4, WF0_2G_HB5, WF0_2G_HB6]
+ items:
+ enum: [GPIO_A, I2S1_IN, I2S1_OUT, I2S_BCLK, I2S_WS, I2S_MCLK, TXD0,
+ RXD0, SPI_WP, SPI_HOLD, SPI_CLK, SPI_MOSI, SPI_MISO, SPI_CS,
+ I2C_SDA, I2C_SCL, I2S2_IN, I2S3_IN, I2S4_IN, I2S2_OUT,
+ I2S3_OUT, I2S4_OUT, GPIO_B, MDC, MDIO, G2_TXD0, G2_TXD1,
+ G2_TXD2, G2_TXD3, G2_TXEN, G2_TXC, G2_RXD0, G2_RXD1, G2_RXD2,
+ G2_RXD3, G2_RXDV, G2_RXC, NCEB, NWEB, NREB, NDL4, NDL5, NDL6,
+ NDL7, NRB, NCLE, NALE, NDL0, NDL1, NDL2, NDL3, MDI_TP_P0,
+ MDI_TN_P0, MDI_RP_P0, MDI_RN_P0, MDI_TP_P1, MDI_TN_P1,
+ MDI_RP_P1, MDI_RN_P1, MDI_RP_P2, MDI_RN_P2, MDI_TP_P2,
+ MDI_TN_P2, MDI_TP_P3, MDI_TN_P3, MDI_RP_P3, MDI_RN_P3,
+ MDI_RP_P4, MDI_RN_P4, MDI_TP_P4, MDI_TN_P4, PMIC_SCL,
+ PMIC_SDA, SPIC1_CLK, SPIC1_MOSI, SPIC1_MISO, SPIC1_CS,
+ GPIO_D, WATCHDOG, RTS3_N, CTS3_N, TXD3, RXD3, PERST0_N,
+ PERST1_N, WLED_N, EPHY_LED0_N, AUXIN0, AUXIN1, AUXIN2,
+ AUXIN3, TXD4, RXD4, RTS4_N, CST4_N, PWM1, PWM2, PWM3, PWM4,
+ PWM5, PWM6, PWM7, GPIO_E, TOP_5G_CLK, TOP_5G_DATA,
+ WF0_5G_HB0, WF0_5G_HB1, WF0_5G_HB2, WF0_5G_HB3, WF0_5G_HB4,
+ WF0_5G_HB5, WF0_5G_HB6, XO_REQ, TOP_RST_N, SYS_WATCHDOG,
+ EPHY_LED0_N_JTDO, EPHY_LED1_N_JTDI, EPHY_LED2_N_JTMS,
+ EPHY_LED3_N_JTCLK, EPHY_LED4_N_JTRST_N, WF2G_LED_N,
+ WF5G_LED_N, GPIO_9, GPIO_10, GPIO_11, GPIO_12, UART1_TXD,
+ UART1_RXD, UART1_CTS, UART1_RTS, UART2_TXD, UART2_RXD,
+ UART2_CTS, UART2_RTS, SMI_MDC, SMI_MDIO, PCIE_PERESET_N,
+ PWM_0, GPIO_0, GPIO_1, GPIO_2, GPIO_3, GPIO_4, GPIO_5,
+ GPIO_6, GPIO_7, GPIO_8, UART0_TXD, UART0_RXD, TOP_2G_CLK,
+ TOP_2G_DATA, WF0_2G_HB0, WF0_2G_HB1, WF0_2G_HB2, WF0_2G_HB3,
+ WF0_2G_HB4, WF0_2G_HB5, WF0_2G_HB6]
bias-disable: true
--
2.35.3
^ permalink raw reply related
* [PATCH 2/3] dt-bindings: pinctrl: mediatek: mt7622: add "antsel" function
From: Rafał Miłecki @ 2024-04-08 9:05 UTC (permalink / raw)
To: Sean Wang, Linus Walleij, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Matthias Brugger, AngeloGioacchino Del Regno, Hsin-Yi Wang,
linux-mediatek, linux-gpio, devicetree, linux-arm-kernel,
Rafał Miłecki, Chuanhong Guo
In-Reply-To: <20240408090506.21596-1-zajec5@gmail.com>
From: Rafał Miłecki <rafal@milecki.pl>
MT7622 pinctrl has ANTSEL* pins. Linux support for those was added in
the commit 19f599e83ac5 ("pinctrl: mediatek: mt7622: add antsel
pins/groups"). Include them in binding.
Cc: Chuanhong Guo <gch981213@gmail.com>
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
---
.../pinctrl/mediatek,mt7622-pinctrl.yaml | 18 ++++++++++++++++--
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/pinctrl/mediatek,mt7622-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/mediatek,mt7622-pinctrl.yaml
index 60f30a59f385..a9ab623b2697 100644
--- a/Documentation/devicetree/bindings/pinctrl/mediatek,mt7622-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/mediatek,mt7622-pinctrl.yaml
@@ -75,8 +75,8 @@ patternProperties:
function:
description:
A string containing the name of the function to mux to the group.
- enum: [emmc, eth, i2c, i2s, ir, led, flash, pcie, pmic, pwm, sd,
- spi, tdm, uart, watchdog, wifi]
+ enum: [antsel, emmc, eth, i2c, i2s, ir, led, flash, pcie, pmic, pwm,
+ sd, spi, tdm, uart, watchdog, wifi]
groups:
description:
@@ -90,6 +90,20 @@ patternProperties:
- function
allOf:
+ - if:
+ properties:
+ function:
+ const: antsel
+ then:
+ properties:
+ groups:
+ items:
+ enum: [antsel0, antsel1, antsel2, antsel3, antsel4, antsel5,
+ antsel6, antsel7, antsel8, antsel9, antsel10,
+ antsel11, antsel12, antsel13, antsel14, antsel15,
+ antsel16, antsel17, antsel18, antsel19, antsel20,
+ antsel21, antsel22, antsel23, antsel24, antsel25,
+ antsel26, antsel27, antsel28, antsel29]
- if:
properties:
function:
--
2.35.3
^ permalink raw reply related
* [PATCH 3/3] dt-bindings: pinctrl: mediatek: mt7622: add "base" reg
From: Rafał Miłecki @ 2024-04-08 9:05 UTC (permalink / raw)
To: Sean Wang, Linus Walleij, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Matthias Brugger, AngeloGioacchino Del Regno, Hsin-Yi Wang,
linux-mediatek, linux-gpio, devicetree, linux-arm-kernel,
Rafał Miłecki
In-Reply-To: <20240408090506.21596-1-zajec5@gmail.com>
From: Rafał Miłecki <rafal@milecki.pl>
Both: MT7622 and MT7629 use two reg spaces: "base" and "eint". It wasn't
covered by the binding and also example didn't match incomplete binding.
Fix it.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
---
.../bindings/pinctrl/mediatek,mt7622-pinctrl.yaml | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/pinctrl/mediatek,mt7622-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/mediatek,mt7622-pinctrl.yaml
index a9ab623b2697..eaa65512161a 100644
--- a/Documentation/devicetree/bindings/pinctrl/mediatek,mt7622-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/mediatek,mt7622-pinctrl.yaml
@@ -19,10 +19,12 @@ properties:
- mediatek,mt7629-pinctrl
reg:
- maxItems: 1
+ minItems: 2
+ maxItems: 2
reg-names:
items:
+ - const: base
- const: eint
gpio-controller: true
@@ -364,7 +366,9 @@ examples:
pio: pinctrl@10211000 {
compatible = "mediatek,mt7622-pinctrl";
- reg = <0 0x10211000 0 0x1000>;
+ reg = <0 0x10211000 0 0x1000>,
+ <0 0x10005000 0 0x1000>;
+ reg-names = "base", "eint";
gpio-controller;
#gpio-cells = <2>;
--
2.35.3
^ permalink raw reply related
* Re: [PATCH v3 0/3] arm64: dts: hi3798cv200: fix GICR size, add cache info, maintenance irq and GICH, GICV spaces
From: Yang Xiwen @ 2024-04-08 9:09 UTC (permalink / raw)
To: Krzysztof Kozlowski, Wei Xu, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jiancheng Xue, Alex Elder, Peter Griffin
Cc: linux-arm-kernel, devicetree, linux-kernel, stable
In-Reply-To: <171256140981.12523.5652563259173425537.b4-ty@linaro.org>
On 4/8/2024 3:31 PM, Krzysztof Kozlowski wrote:
> On Mon, 19 Feb 2024 23:05:25 +0800, Yang Xiwen wrote:
>> The patchset fixes some warnings reported by the kernel during boot.
>>
>> The cache size info is from Processor_Datasheet_v2XX.pdf [1], Section
>> 2.2.1 Master Processor.
>>
>> The cache line size and the set-associative info are from Cortex-A53
>> Documentation [2].
>>
>> [...]
> It's rc3 and almost one month after last ping/talk, so apparently these got
> lost. I'll take them, but let me know if this should go via different tree.
Thanks a lot. From my experience, i think this should go via HiSilicon's
tree first(which stalls now), then go to SOC tree
(git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git), finally in
torvald's tree. This was the case for some qcom dts changes about 1yr ago.
>
>
> Applied, thanks!
>
> [1/3] arm64: dts: hi3798cv200: fix the size of GICR
> https://git.kernel.org/krzk/linux-dt/c/428a575dc9038846ad259466d5ba109858c0a023
> [2/3] arm64: dts: hi3798cv200: add GICH, GICV register space and irq
> https://git.kernel.org/krzk/linux-dt/c/f00a6b9644a5668e25ad9ca5aff53b6de4b0aaf6
> [3/3] arm64: dts: hi3798cv200: add cache info
> https://git.kernel.org/krzk/linux-dt/c/c7a3ad884d1dc1302dcc3295baa18917180b8bec
>
> Best regards,
--
Regards,
Yang Xiwen
^ permalink raw reply
* [PATCH v2 0/2] Meson: R/W support for pages used by boot ROM
From: Arseniy Krasnov @ 2024-04-08 8:59 UTC (permalink / raw)
To: Miquel Raynal, Richard Weinberger, Vignesh Raghavendra,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
Kevin Hilman, Jerome Brunet, Martin Blumenstingl
Cc: linux-mtd, devicetree, linux-arm-kernel, linux-amlogic,
linux-kernel, oxffffaa, kernel, Arseniy Krasnov
Amlogic's boot ROM code needs that some pages on NAND must be written
in special "short" ECC mode with scrambling enabled. Such pages:
1) Contain some metadata about hardware.
2) Located with some interval starting from 0 offset, until some
specified offset. Interval and second offset are set in the
device tree.
This patchset adds R/W support for such pages. To enable it we can setup
it in dts:
nand-is-boot-medium;
amlogic,boot-page-last = <1024>;
amlogic,boot-page-step = <128>;
It means that each 128th page in range 0 to 1024 pages will be accessed
in special mode ("short" ECC + scrambling). In practice this feature is
needed when we want to update first block of NAND - driver will enable
required mode by itself using value from device tree.
Changelog:
v1 -> v2:
* Rename 'meson,boot-page-XXX' -> 'amlogic,boot-page-XXX'.
* Add words that 'amlogic,boot-page-step' is measured in pages.
* Remove words that 'amlogic,boot-page-XXX' depends on 'nand-is-boot-medium'.
* Make both 'amlogic,boot-page-XXX' depend on each other also, in
addition to 'nand-is-boot-medium' dependency.
Arseniy Krasnov (2):
dt-bindings: mtd: amlogic,meson-nand: support fields for boot ROM code
mtd: rawnand: meson: support R/W mode for boot ROM
.../bindings/mtd/amlogic,meson-nand.yaml | 14 +++
drivers/mtd/nand/raw/meson_nand.c | 88 +++++++++++++------
2 files changed, 73 insertions(+), 29 deletions(-)
--
2.35.0
^ permalink raw reply
* [PATCH v2 2/2] mtd: rawnand: meson: support R/W mode for boot ROM
From: Arseniy Krasnov @ 2024-04-08 8:59 UTC (permalink / raw)
To: Miquel Raynal, Richard Weinberger, Vignesh Raghavendra,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
Kevin Hilman, Jerome Brunet, Martin Blumenstingl
Cc: linux-mtd, devicetree, linux-arm-kernel, linux-amlogic,
linux-kernel, oxffffaa, kernel, Arseniy Krasnov
In-Reply-To: <20240408085931.456337-1-avkrasnov@salutedevices.com>
Boot ROM code on Meson requires that some pages on NAND must be written
in special mode: "short" ECC mode where each block is 384 bytes and
scrambling mode is on. Such pages located with the specified interval
within specified offset. Both interval and offset are located in the
device tree and used by driver if 'nand-is-boot-medium' is set for
NAND chip.
Signed-off-by: Arseniy Krasnov <avkrasnov@salutedevices.com>
---
drivers/mtd/nand/raw/meson_nand.c | 88 +++++++++++++++++++++----------
1 file changed, 59 insertions(+), 29 deletions(-)
diff --git a/drivers/mtd/nand/raw/meson_nand.c b/drivers/mtd/nand/raw/meson_nand.c
index 00ce0e5bb970..b68aac24af16 100644
--- a/drivers/mtd/nand/raw/meson_nand.c
+++ b/drivers/mtd/nand/raw/meson_nand.c
@@ -35,6 +35,7 @@
#define NFC_CMD_RB BIT(20)
#define NFC_CMD_SCRAMBLER_ENABLE BIT(19)
#define NFC_CMD_SCRAMBLER_DISABLE 0
+#define NFC_CMD_SHORTMODE_ENABLE 1
#define NFC_CMD_SHORTMODE_DISABLE 0
#define NFC_CMD_RB_INT BIT(14)
#define NFC_CMD_RB_INT_NO_PIN ((0xb << 10) | BIT(18) | BIT(16))
@@ -78,6 +79,8 @@
#define DMA_DIR(dir) ((dir) ? NFC_CMD_N2M : NFC_CMD_M2N)
#define DMA_ADDR_ALIGN 8
+#define NFC_SHORT_MODE_ECC_SZ 384
+
#define ECC_CHECK_RETURN_FF (-1)
#define NAND_CE0 (0xe << 10)
@@ -125,6 +128,8 @@ struct meson_nfc_nand_chip {
u32 twb;
u32 tadl;
u32 tbers_max;
+ u32 boot_page_last;
+ u32 boot_page_step;
u32 bch_mode;
u8 *data_buf;
@@ -298,28 +303,49 @@ static void meson_nfc_cmd_seed(struct meson_nfc *nfc, u32 seed)
nfc->reg_base + NFC_REG_CMD);
}
-static void meson_nfc_cmd_access(struct nand_chip *nand, int raw, bool dir,
- int scrambler)
+static int meson_nfc_page_is_boot(struct nand_chip *nand, int page)
+{
+ const struct meson_nfc_nand_chip *meson_chip = to_meson_nand(nand);
+
+ return (nand->options & NAND_IS_BOOT_MEDIUM) &&
+ !(page % meson_chip->boot_page_step) &&
+ (page < meson_chip->boot_page_last);
+}
+
+static void meson_nfc_cmd_access(struct nand_chip *nand, bool raw, bool dir, int page)
{
+ const struct meson_nfc_nand_chip *meson_chip = to_meson_nand(nand);
struct mtd_info *mtd = nand_to_mtd(nand);
struct meson_nfc *nfc = nand_get_controller_data(mtd_to_nand(mtd));
- struct meson_nfc_nand_chip *meson_chip = to_meson_nand(nand);
- u32 bch = meson_chip->bch_mode, cmd;
int len = mtd->writesize, pagesize, pages;
+ int scrambler;
+ u32 cmd;
- pagesize = nand->ecc.size;
+ if (nand->options & NAND_NEED_SCRAMBLING)
+ scrambler = NFC_CMD_SCRAMBLER_ENABLE;
+ else
+ scrambler = NFC_CMD_SCRAMBLER_DISABLE;
if (raw) {
len = mtd->writesize + mtd->oobsize;
cmd = len | scrambler | DMA_DIR(dir);
- writel(cmd, nfc->reg_base + NFC_REG_CMD);
- return;
- }
+ } else if (meson_nfc_page_is_boot(nand, page)) {
+ pagesize = NFC_SHORT_MODE_ECC_SZ >> 3;
+ pages = mtd->writesize / 512;
+
+ scrambler = NFC_CMD_SCRAMBLER_ENABLE;
+ cmd = CMDRWGEN(DMA_DIR(dir), scrambler, NFC_ECC_BCH8_1K,
+ NFC_CMD_SHORTMODE_ENABLE, pagesize, pages);
+ } else {
+ pagesize = nand->ecc.size >> 3;
+ pages = len / nand->ecc.size;
- pages = len / nand->ecc.size;
+ cmd = CMDRWGEN(DMA_DIR(dir), scrambler, meson_chip->bch_mode,
+ NFC_CMD_SHORTMODE_DISABLE, pagesize, pages);
+ }
- cmd = CMDRWGEN(DMA_DIR(dir), scrambler, bch,
- NFC_CMD_SHORTMODE_DISABLE, pagesize, pages);
+ if (scrambler == NFC_CMD_SCRAMBLER_ENABLE)
+ meson_nfc_cmd_seed(nfc, page);
writel(cmd, nfc->reg_base + NFC_REG_CMD);
}
@@ -743,15 +769,7 @@ static int meson_nfc_write_page_sub(struct nand_chip *nand,
if (ret)
return ret;
- if (nand->options & NAND_NEED_SCRAMBLING) {
- meson_nfc_cmd_seed(nfc, page);
- meson_nfc_cmd_access(nand, raw, DIRWRITE,
- NFC_CMD_SCRAMBLER_ENABLE);
- } else {
- meson_nfc_cmd_access(nand, raw, DIRWRITE,
- NFC_CMD_SCRAMBLER_DISABLE);
- }
-
+ meson_nfc_cmd_access(nand, raw, DIRWRITE, page);
cmd = nfc->param.chip_select | NFC_CMD_CLE | NAND_CMD_PAGEPROG;
writel(cmd, nfc->reg_base + NFC_REG_CMD);
meson_nfc_queue_rb(nand, PSEC_TO_MSEC(sdr->tPROG_max), false);
@@ -829,15 +847,7 @@ static int meson_nfc_read_page_sub(struct nand_chip *nand,
if (ret)
return ret;
- if (nand->options & NAND_NEED_SCRAMBLING) {
- meson_nfc_cmd_seed(nfc, page);
- meson_nfc_cmd_access(nand, raw, DIRREAD,
- NFC_CMD_SCRAMBLER_ENABLE);
- } else {
- meson_nfc_cmd_access(nand, raw, DIRREAD,
- NFC_CMD_SCRAMBLER_DISABLE);
- }
-
+ meson_nfc_cmd_access(nand, raw, DIRREAD, page);
ret = meson_nfc_wait_dma_finish(nfc);
meson_nfc_check_ecc_pages_valid(nfc, nand, raw);
@@ -1436,6 +1446,26 @@ meson_nfc_nand_chip_init(struct device *dev,
if (ret)
return ret;
+ if (nand->options & NAND_IS_BOOT_MEDIUM) {
+ ret = of_property_read_u32(np, "amlogic,boot-page-last",
+ &meson_chip->boot_page_last);
+ if (ret) {
+ dev_err(dev, "could not retrieve 'amlogic,boot-page-last' property: %d",
+ ret);
+ nand_cleanup(nand);
+ return ret;
+ }
+
+ ret = of_property_read_u32(np, "amlogic,boot-page-step",
+ &meson_chip->boot_page_step);
+ if (ret) {
+ dev_err(dev, "could not retrieve 'amlogic,boot-page-step' property: %d",
+ ret);
+ nand_cleanup(nand);
+ return ret;
+ }
+ }
+
ret = mtd_device_register(mtd, NULL, 0);
if (ret) {
dev_err(dev, "failed to register MTD device: %d\n", ret);
--
2.35.0
^ permalink raw reply related
* [PATCH v2 1/2] dt-bindings: mtd: amlogic,meson-nand: support fields for boot ROM code
From: Arseniy Krasnov @ 2024-04-08 8:59 UTC (permalink / raw)
To: Miquel Raynal, Richard Weinberger, Vignesh Raghavendra,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
Kevin Hilman, Jerome Brunet, Martin Blumenstingl
Cc: linux-mtd, devicetree, linux-arm-kernel, linux-amlogic,
linux-kernel, oxffffaa, kernel, Arseniy Krasnov
In-Reply-To: <20240408085931.456337-1-avkrasnov@salutedevices.com>
Boot ROM code on Meson requires that some pages on NAND must be written
in special mode: "short" ECC mode where each block is 384 bytes and
scrambling mode is on. Such pages located with the specified interval
within specified offset. Both interval and offset are located in the
device tree and used by driver if 'nand-is-boot-medium' is set for
NAND chip.
Signed-off-by: Arseniy Krasnov <avkrasnov@salutedevices.com>
---
.../bindings/mtd/amlogic,meson-nand.yaml | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/Documentation/devicetree/bindings/mtd/amlogic,meson-nand.yaml b/Documentation/devicetree/bindings/mtd/amlogic,meson-nand.yaml
index 57b6957c8415..80ba5003ca70 100644
--- a/Documentation/devicetree/bindings/mtd/amlogic,meson-nand.yaml
+++ b/Documentation/devicetree/bindings/mtd/amlogic,meson-nand.yaml
@@ -64,11 +64,25 @@ patternProperties:
items:
maximum: 0
+ amlogic,boot-page-last:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ The NFC driver needs this information to select ECC
+ algorithms supported by the boot ROM.
+
+ amlogic,boot-page-step:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ The NFC driver needs this information to select ECC
+ algorithms supported by the boot ROM (in pages).
+
unevaluatedProperties: false
dependencies:
nand-ecc-strength: [nand-ecc-step-size]
nand-ecc-step-size: [nand-ecc-strength]
+ amlogic,boot-page-last: [nand-is-boot-medium, amlogic,boot-page-step]
+ amlogic,boot-page-step: [nand-is-boot-medium, amlogic,boot-page-last]
required:
--
2.35.0
^ permalink raw reply related
* Re: [RESEND v3 0/2] Add support for QCM6490 and QCS6490
From: Srinivas Kandagatla @ 2024-04-08 9:16 UTC (permalink / raw)
To: Mohammad Rafi Shaik, Banajit Goswami, Liam Girdwood, Mark Brown,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Jaroslav Kysela,
Takashi Iwai
Cc: linux-arm-msm, alsa-devel, linux-sound, devicetree, linux-kernel,
quic_rohkumar
In-Reply-To: <20240408042331.403103-1-quic_mohs@quicinc.com>
On 08/04/2024 05:23, Mohammad Rafi Shaik wrote:
> This patchset adds support for sound card on Qualcomm QCM6490 IDP and
> QCS6490 RB3Gen2 boards.
>
> Changes since v2:
> - Modify qcm6490 compatible name as qcm6490-idp. Suggested by Dmitry
>
> Changes since v1:
> - Use existing sc8280xp machine driver instead of separate driver.
> - Modify qcs6490 compatible name as qcs6490-rb3gen2.
>
> Mohammad Rafi Shaik (2):
> ASoC: dt-bindings: qcom,sm8250: Add QCM6490 snd QCS6490 sound card
> ASoC: qcom: sc8280xp: Add support for QCM6490 and QCS6490
>
LGTM,
Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
--srini
> Documentation/devicetree/bindings/sound/qcom,sm8250.yaml | 2 ++
> sound/soc/qcom/sc8280xp.c | 2 ++
> 2 files changed, 4 insertions(+)
>
^ permalink raw reply
* Re: [PATCH v12 2/7] clk: meson: add vclk driver
From: neil.armstrong @ 2024-04-08 9:19 UTC (permalink / raw)
To: Jerome Brunet
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Martin Blumenstingl, Kevin Hilman, Michael Turquette,
Stephen Boyd, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Daniel Vetter, Jagan Teki, Nicolas Belin,
devicetree, linux-kernel, linux-amlogic, linux-clk,
linux-arm-kernel, dri-devel
In-Reply-To: <1ja5m8p4n4.fsf@starbuckisacylon.baylibre.com>
On 05/04/2024 09:00, Jerome Brunet wrote:
>
> On Thu 04 Apr 2024 at 18:59, Neil Armstrong <neil.armstrong@linaro.org> wrote:
>
>> On 04/04/2024 10:13, Jerome Brunet wrote:
>>> On Wed 03 Apr 2024 at 09:46, Neil Armstrong <neil.armstrong@linaro.org>
>>> wrote:
>>>
>>>> The VCLK and VCLK_DIV clocks have supplementary bits.
>>>>
>>>> The VCLK gate has a "SOFT RESET" bit to toggle after the whole
>>>> VCLK sub-tree rate has been set, this is implemented in
>>>> the gate enable callback.
>>>>
>>>> The VCLK_DIV clocks as enable and reset bits used to disable
>>>> and reset the divider, associated with CLK_SET_RATE_GATE it ensures
>>>> the rate is set while the divider is disabled and in reset mode.
>>>>
>>>> The VCLK_DIV enable bit isn't implemented as a gate since it's part
>>>> of the divider logic and vendor does this exact sequence to ensure
>>>> the divider is correctly set.
>>> The checkpatch warning is still there. Is it a choice or a mistake ?
>>> Documentation says "GPL v2" exists for historic reason which seems to
>>> hint "GPL" is preferred, and I suppose this is why checkpatch warns for
>>> it.
>>
>> Well I didn't see this warning, this is what I fixed:
>>
>> $ scripts/checkpatch.pl --strict drivers/clk/meson/vclk.c
>> CHECK: Alignment should match open parenthesis
>> #63: FILE: drivers/clk/meson/vclk.c:63:
>> +static unsigned long meson_vclk_div_recalc_rate(struct clk_hw *hw,
>> + unsigned long prate)
>>
>> CHECK: Alignment should match open parenthesis
>> #73: FILE: drivers/clk/meson/vclk.c:73:
>> +static int meson_vclk_div_determine_rate(struct clk_hw *hw,
>> + struct clk_rate_request *req)
>>
>> CHECK: Alignment should match open parenthesis
>> #83: FILE: drivers/clk/meson/vclk.c:83:
>> +static int meson_vclk_div_set_rate(struct clk_hw *hw, unsigned long rate,
>> + unsigned long parent_rate)
>>
>
> I would not ask a respin solely for this. It's nice to fix it but I was
> mostly after the warning TBH.
>
>> <snip>
>>
>> It seems that checking a commit triggers an extra check....
>>
>> $ scripts/checkpatch.pl --strict -G 1bac9f6aa3c3
>> WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
>> #58:
>> new file mode 100644
>>
>> <snip>
>>
>> WARNING: Prefer "GPL" over "GPL v2" - see commit bf7fbeeae6db ("module: Cure the MODULE_LICENSE "GPL" vs. "GPL v2" bogosity")
>> #203: FILE: drivers/clk/meson/vclk.c:141:
>> +MODULE_LICENSE("GPL v2");
>
> Hum, I'm running checkpatch against the mail itself, not the commit. I
> still get the warning
Patch or commit seems to trigger more tests than a file directly, anyway I sent a follow-up patch:
https://lore.kernel.org/all/20240408-amlogic-v6-9-upstream-fix-clk-module-license-v1-1-366ddc0f3db9@linaro.org/
Thanks,
Neil
>
>>
>> <snip>
>>
>> Neil
>>
>>>
>>>>
>>>> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
>>>> ---
>>>> drivers/clk/meson/Kconfig | 4 ++
>>>> drivers/clk/meson/Makefile | 1 +
>>>> drivers/clk/meson/vclk.c | 141 +++++++++++++++++++++++++++++++++++++++++++++
>>>> drivers/clk/meson/vclk.h | 51 ++++++++++++++++
>>>> 4 files changed, 197 insertions(+)
>>>>
>>>> diff --git a/drivers/clk/meson/Kconfig b/drivers/clk/meson/Kconfig
>>>> index 29ffd14d267b..8a9823789fa3 100644
>>>> --- a/drivers/clk/meson/Kconfig
>>>> +++ b/drivers/clk/meson/Kconfig
>>>> @@ -30,6 +30,10 @@ config COMMON_CLK_MESON_VID_PLL_DIV
>>>> tristate
>>>> select COMMON_CLK_MESON_REGMAP
>>>> +config COMMON_CLK_MESON_VCLK
>>>> + tristate
>>>> + select COMMON_CLK_MESON_REGMAP
>>>> +
>>>> config COMMON_CLK_MESON_CLKC_UTILS
>>>> tristate
>>>> diff --git a/drivers/clk/meson/Makefile b/drivers/clk/meson/Makefile
>>>> index 9ee4b954c896..9ba43fe7a07a 100644
>>>> --- a/drivers/clk/meson/Makefile
>>>> +++ b/drivers/clk/meson/Makefile
>>>> @@ -12,6 +12,7 @@ obj-$(CONFIG_COMMON_CLK_MESON_PLL) += clk-pll.o
>>>> obj-$(CONFIG_COMMON_CLK_MESON_REGMAP) += clk-regmap.o
>>>> obj-$(CONFIG_COMMON_CLK_MESON_SCLK_DIV) += sclk-div.o
>>>> obj-$(CONFIG_COMMON_CLK_MESON_VID_PLL_DIV) += vid-pll-div.o
>>>> +obj-$(CONFIG_COMMON_CLK_MESON_VCLK) += vclk.o
>>>> # Amlogic Clock controllers
>>>> diff --git a/drivers/clk/meson/vclk.c b/drivers/clk/meson/vclk.c
>>>> new file mode 100644
>>>> index 000000000000..45dc216941ea
>>>> --- /dev/null
>>>> +++ b/drivers/clk/meson/vclk.c
>>>> @@ -0,0 +1,141 @@
>>>> +// SPDX-License-Identifier: GPL-2.0
>>>> +/*
>>>> + * Copyright (c) 2024 Neil Armstrong <neil.armstrong@linaro.org>
>>>> + */
>>>> +
>>>> +#include <linux/module.h>
>>>> +#include "vclk.h"
>>>> +
>>>> +/* The VCLK gate has a supplementary reset bit to pulse after ungating */
>>>> +
>>>> +static inline struct meson_vclk_gate_data *
>>>> +clk_get_meson_vclk_gate_data(struct clk_regmap *clk)
>>>> +{
>>>> + return (struct meson_vclk_gate_data *)clk->data;
>>>> +}
>>>> +
>>>> +static int meson_vclk_gate_enable(struct clk_hw *hw)
>>>> +{
>>>> + struct clk_regmap *clk = to_clk_regmap(hw);
>>>> + struct meson_vclk_gate_data *vclk = clk_get_meson_vclk_gate_data(clk);
>>>> +
>>>> + meson_parm_write(clk->map, &vclk->enable, 1);
>>>> +
>>>> + /* Do a reset pulse */
>>>> + meson_parm_write(clk->map, &vclk->reset, 1);
>>>> + meson_parm_write(clk->map, &vclk->reset, 0);
>>>> +
>>>> + return 0;
>>>> +}
>>>> +
>>>> +static void meson_vclk_gate_disable(struct clk_hw *hw)
>>>> +{
>>>> + struct clk_regmap *clk = to_clk_regmap(hw);
>>>> + struct meson_vclk_gate_data *vclk = clk_get_meson_vclk_gate_data(clk);
>>>> +
>>>> + meson_parm_write(clk->map, &vclk->enable, 0);
>>>> +}
>>>> +
>>>> +static int meson_vclk_gate_is_enabled(struct clk_hw *hw)
>>>> +{
>>>> + struct clk_regmap *clk = to_clk_regmap(hw);
>>>> + struct meson_vclk_gate_data *vclk = clk_get_meson_vclk_gate_data(clk);
>>>> +
>>>> + return meson_parm_read(clk->map, &vclk->enable);
>>>> +}
>>>> +
>>>> +const struct clk_ops meson_vclk_gate_ops = {
>>>> + .enable = meson_vclk_gate_enable,
>>>> + .disable = meson_vclk_gate_disable,
>>>> + .is_enabled = meson_vclk_gate_is_enabled,
>>>> +};
>>>> +EXPORT_SYMBOL_GPL(meson_vclk_gate_ops);
>>>> +
>>>> +/* The VCLK Divider has supplementary reset & enable bits */
>>>> +
>>>> +static inline struct meson_vclk_div_data *
>>>> +clk_get_meson_vclk_div_data(struct clk_regmap *clk)
>>>> +{
>>>> + return (struct meson_vclk_div_data *)clk->data;
>>>> +}
>>>> +
>>>> +static unsigned long meson_vclk_div_recalc_rate(struct clk_hw *hw,
>>>> + unsigned long prate)
>>>> +{
>>>> + struct clk_regmap *clk = to_clk_regmap(hw);
>>>> + struct meson_vclk_div_data *vclk = clk_get_meson_vclk_div_data(clk);
>>>> +
>>>> + return divider_recalc_rate(hw, prate, meson_parm_read(clk->map, &vclk->div),
>>>> + vclk->table, vclk->flags, vclk->div.width);
>>>> +}
>>>> +
>>>> +static int meson_vclk_div_determine_rate(struct clk_hw *hw,
>>>> + struct clk_rate_request *req)
>>>> +{
>>>> + struct clk_regmap *clk = to_clk_regmap(hw);
>>>> + struct meson_vclk_div_data *vclk = clk_get_meson_vclk_div_data(clk);
>>>> +
>>>> + return divider_determine_rate(hw, req, vclk->table, vclk->div.width,
>>>> + vclk->flags);
>>>> +}
>>>> +
>>>> +static int meson_vclk_div_set_rate(struct clk_hw *hw, unsigned long rate,
>>>> + unsigned long parent_rate)
>>>> +{
>>>> + struct clk_regmap *clk = to_clk_regmap(hw);
>>>> + struct meson_vclk_div_data *vclk = clk_get_meson_vclk_div_data(clk);
>>>> + int ret;
>>>> +
>>>> + ret = divider_get_val(rate, parent_rate, vclk->table, vclk->div.width,
>>>> + vclk->flags);
>>>> + if (ret < 0)
>>>> + return ret;
>>>> +
>>>> + meson_parm_write(clk->map, &vclk->div, ret);
>>>> +
>>>> + return 0;
>>>> +};
>>>> +
>>>> +static int meson_vclk_div_enable(struct clk_hw *hw)
>>>> +{
>>>> + struct clk_regmap *clk = to_clk_regmap(hw);
>>>> + struct meson_vclk_div_data *vclk = clk_get_meson_vclk_div_data(clk);
>>>> +
>>>> + /* Unreset the divider when ungating */
>>>> + meson_parm_write(clk->map, &vclk->reset, 0);
>>>> + meson_parm_write(clk->map, &vclk->enable, 1);
>>>> +
>>>> + return 0;
>>>> +}
>>>> +
>>>> +static void meson_vclk_div_disable(struct clk_hw *hw)
>>>> +{
>>>> + struct clk_regmap *clk = to_clk_regmap(hw);
>>>> + struct meson_vclk_div_data *vclk = clk_get_meson_vclk_div_data(clk);
>>>> +
>>>> + /* Reset the divider when gating */
>>>> + meson_parm_write(clk->map, &vclk->enable, 0);
>>>> + meson_parm_write(clk->map, &vclk->reset, 1);
>>>> +}
>>>> +
>>>> +static int meson_vclk_div_is_enabled(struct clk_hw *hw)
>>>> +{
>>>> + struct clk_regmap *clk = to_clk_regmap(hw);
>>>> + struct meson_vclk_div_data *vclk = clk_get_meson_vclk_div_data(clk);
>>>> +
>>>> + return meson_parm_read(clk->map, &vclk->enable);
>>>> +}
>>>> +
>>>> +const struct clk_ops meson_vclk_div_ops = {
>>>> + .recalc_rate = meson_vclk_div_recalc_rate,
>>>> + .determine_rate = meson_vclk_div_determine_rate,
>>>> + .set_rate = meson_vclk_div_set_rate,
>>>> + .enable = meson_vclk_div_enable,
>>>> + .disable = meson_vclk_div_disable,
>>>> + .is_enabled = meson_vclk_div_is_enabled,
>>>> +};
>>>> +EXPORT_SYMBOL_GPL(meson_vclk_div_ops);
>>>> +
>>>> +MODULE_DESCRIPTION("Amlogic vclk clock driver");
>>>> +MODULE_AUTHOR("Neil Armstrong <neil.armstrong@linaro.org>");
>>>> +MODULE_LICENSE("GPL v2");
>>>> diff --git a/drivers/clk/meson/vclk.h b/drivers/clk/meson/vclk.h
>>>> new file mode 100644
>>>> index 000000000000..20b0b181db09
>>>> --- /dev/null
>>>> +++ b/drivers/clk/meson/vclk.h
>>>> @@ -0,0 +1,51 @@
>>>> +/* SPDX-License-Identifier: GPL-2.0 */
>>>> +/*
>>>> + * Copyright (c) 2024 Neil Armstrong <neil.armstrong@linaro.org>
>>>> + */
>>>> +
>>>> +#ifndef __VCLK_H
>>>> +#define __VCLK_H
>>>> +
>>>> +#include "clk-regmap.h"
>>>> +#include "parm.h"
>>>> +
>>>> +/**
>>>> + * struct meson_vclk_gate_data - vclk_gate regmap backed specific data
>>>> + *
>>>> + * @enable: vclk enable field
>>>> + * @reset: vclk reset field
>>>> + * @flags: hardware-specific flags
>>>> + *
>>>> + * Flags:
>>>> + * Same as clk_gate except CLK_GATE_HIWORD_MASK which is ignored
>>>> + */
>>>> +struct meson_vclk_gate_data {
>>>> + struct parm enable;
>>>> + struct parm reset;
>>>> + u8 flags;
>>>> +};
>>>> +
>>>> +extern const struct clk_ops meson_vclk_gate_ops;
>>>> +
>>>> +/**
>>>> + * struct meson_vclk_div_data - vclk_div regmap back specific data
>>>> + *
>>>> + * @div: divider field
>>>> + * @enable: vclk divider enable field
>>>> + * @reset: vclk divider reset field
>>>> + * @table: array of value/divider pairs, last entry should have div = 0
>>>> + *
>>>> + * Flags:
>>>> + * Same as clk_divider except CLK_DIVIDER_HIWORD_MASK which is ignored
>>>> + */
>>>> +struct meson_vclk_div_data {
>>>> + struct parm div;
>>>> + struct parm enable;
>>>> + struct parm reset;
>>>> + const struct clk_div_table *table;
>>>> + u8 flags;
>>>> +};
>>>> +
>>>> +extern const struct clk_ops meson_vclk_div_ops;
>>>> +
>>>> +#endif /* __VCLK_H */
>>>
>
>
^ permalink raw reply
* Re: [PATCH v2] dt-bindings: display: bridge: it6505: Add #sound-dai-cells
From: Doug Anderson @ 2024-04-08 9:11 UTC (permalink / raw)
To: Rob Herring, Chen-Yu Tsai
Cc: Laurent Pinchart, Krzysztof Kozlowski, dri-devel, Maxime Ripard,
Neil Armstrong, Daniel Vetter, Robert Foss, Rob Herring,
Conor Dooley, Thomas Zimmermann, David Airlie, linux-kernel,
devicetree, Jonas Karlman, Andrzej Hajda, Jernej Skrabec,
Maarten Lankhorst
In-Reply-To: <171156080808.3681700.13600868771478432605.robh@kernel.org>
Hi,
On Wed, Mar 27, 2024 at 10:33 AM Rob Herring <robh@kernel.org> wrote:
>
>
> On Wed, 27 Mar 2024 16:52:48 +0800, Chen-Yu Tsai wrote:
> > The ITE IT6505 display bridge can take one I2S input and transmit it
> > over the DisplayPort link.
> >
> > Add #sound-dai-cells (= 0) to the binding for it.
> >
> > Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
> > ---
> > Changes since v1 [1]:
> > - Reference /schemas/sound/dai-common.yaml
> > - Change "additionalProperties: false" to "unevaluatedProperties: false"
> >
> > The driver side changes [2] are still being worked on.
> >
> > [1] https://lore.kernel.org/dri-devel/20240126073511.2708574-1-wenst@chromium.org/
> > [2] https://lore.kernel.org/linux-arm-kernel/20230730180803.22570-4-jiaxin.yu@mediatek.com/
> > ---
> > .../devicetree/bindings/display/bridge/ite,it6505.yaml | 8 +++++++-
> > 1 file changed, 7 insertions(+), 1 deletion(-)
> >
>
> Reviewed-by: Rob Herring <robh@kernel.org>
Pushed to drm-misc-next:
325af1bef5b9 dt-bindings: display: bridge: it6505: Add #sound-dai-cells
^ permalink raw reply
* [PATCH] arm64: dts: imx8mp-msc-sm2s: Add i2c{1,6} sda-/scl-gpios
From: Ian Ray @ 2024-04-08 9:24 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam
Cc: Ian Ray, devicetree, imx, linux-arm-kernel, linux-kernel
Add i2c{1,6} sda-/scl-gpios with the corresponding pinmux entries.
Signed-off-by: Ian Ray <ian.ray@gehealthcare.com>
---
.../boot/dts/freescale/imx8mp-msc-sm2s.dtsi | 22 +++++++++++++++++--
1 file changed, 20 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-msc-sm2s.dtsi b/arch/arm64/boot/dts/freescale/imx8mp-msc-sm2s.dtsi
index 61c2a63efc6d..7e4327084d26 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp-msc-sm2s.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mp-msc-sm2s.dtsi
@@ -200,8 +200,11 @@ ethphy1: ethernet-phy@1 {
};
&i2c1 {
- pinctrl-names = "default";
+ pinctrl-names = "default", "gpio";
pinctrl-0 = <&pinctrl_i2c1>;
+ pinctrl-1 = <&pinctrl_i2c1_gpio>;
+ scl-gpios = <&gpio5 14 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ sda-gpios = <&gpio5 15 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
clock-frequency = <400000>;
status = "okay";
@@ -241,8 +244,11 @@ &i2c5 {
};
&i2c6 {
- pinctrl-names = "default";
+ pinctrl-names = "default", "gpio";
pinctrl-0 = <&pinctrl_i2c6>;
+ pinctrl-1 = <&pinctrl_i2c6_gpio>;
+ scl-gpios = <&gpio3 19 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ sda-gpios = <&gpio3 20 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
clock-frequency = <400000>;
status = "okay";
@@ -606,6 +612,12 @@ pinctrl_i2c1: i2c1grp {
<MX8MP_IOMUXC_I2C1_SDA__I2C1_SDA 0x400001c3>;
};
+ pinctrl_i2c1_gpio: i2c1gpiogrp {
+ fsl,pins =
+ <MX8MP_IOMUXC_I2C1_SCL__GPIO5_IO14 0x400001c3>,
+ <MX8MP_IOMUXC_I2C1_SDA__GPIO5_IO15 0x400001c3>;
+ };
+
pinctrl_i2c2: i2c2grp {
fsl,pins =
<MX8MP_IOMUXC_I2C2_SCL__I2C2_SCL 0x400001c3>,
@@ -636,6 +648,12 @@ pinctrl_i2c6: i2c6grp {
<MX8MP_IOMUXC_SAI5_RXC__I2C6_SDA 0x400001c3>;
};
+ pinctrl_i2c6_gpio: i2c5gpiogrp {
+ fsl,pins =
+ <MX8MP_IOMUXC_SAI5_RXFS__GPIO3_IO19 0x400001c3>,
+ <MX8MP_IOMUXC_SAI5_RXC__GPIO3_IO20 0x400001c3>;
+ };
+
pinctrl_lcd0_backlight: lcd0-backlightgrp {
fsl,pins =
<MX8MP_IOMUXC_GPIO1_IO05__GPIO1_IO05 0x41>;
--
2.39.2
^ permalink raw reply related
* [PATCH v3 0/2] iio: imu: inv_icm42600: add support of ICM-42688-P
From: inv.git-commit @ 2024-04-08 9:07 UTC (permalink / raw)
To: jic23, robh, krzysztof.kozlowski+dt, conor+dt
Cc: lars, linux-iio, devicetree, Jean-Baptiste Maneyrol
From: Jean-Baptiste Maneyrol <jean-baptiste.maneyrol@tdk.com>
This series is for adding support of high-end specs ICM-42688-P chip.
Changelog:
* v2: change order of chip definitions and order of patches
* v3: add patch description and resend without email IP header issue
Jean-Baptiste Maneyrol (2):
dt-bindings: iio: imu: add icm42688 inside inv_icm42600
iio: imu: inv_icm42600: add support of ICM-42688-P
.../devicetree/bindings/iio/imu/invensense,icm42600.yaml | 1 +
drivers/iio/imu/inv_icm42600/inv_icm42600.h | 2 ++
drivers/iio/imu/inv_icm42600/inv_icm42600_core.c | 5 +++++
drivers/iio/imu/inv_icm42600/inv_icm42600_i2c.c | 3 +++
drivers/iio/imu/inv_icm42600/inv_icm42600_spi.c | 3 +++
5 files changed, 14 insertions(+)
--
2.34.1
^ permalink raw reply
* Re: [PATCH v9 6/6] PCI: qcom: Add OPP support to scale performance state of power domain
From: Manivannan Sadhasivam @ 2024-04-08 9:45 UTC (permalink / raw)
To: Krishna Chaitanya Chundru
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Lorenzo Pieralisi, Krzysztof Wilczyński,
Bjorn Helgaas, johan+linaro, bmasney, djakov, linux-arm-msm,
devicetree, linux-kernel, linux-pci, vireshk, quic_vbadigan,
quic_skananth, quic_nitegupt, quic_parass, krzysztof.kozlowski
In-Reply-To: <6e9b4379-5849-73cd-4d89-5e809b4c71a4@quicinc.com>
On Mon, Apr 08, 2024 at 02:32:18PM +0530, Krishna Chaitanya Chundru wrote:
>
>
> On 4/7/2024 8:30 PM, Manivannan Sadhasivam wrote:
> > On Sun, Apr 07, 2024 at 10:07:39AM +0530, Krishna chaitanya chundru wrote:
> > > QCOM Resource Power Manager-hardened (RPMh) is a hardware block which
> > > maintains hardware state of a regulator by performing max aggregation of
> > > the requests made by all of the clients.
> > >
> > > PCIe controller can operate on different RPMh performance state of power
> > > domain based on the speed of the link. And this performance state varies
> > > from target to target, like some controllers support GEN3 in NOM (Nominal)
> > > voltage corner, while some other supports GEN3 in low SVS (static voltage
> > > scaling).
> > >
> > > The SoC can be more power efficient if we scale the performance state
> > > based on the aggregate PCIe link bandwidth.
> > >
> > > Add Operating Performance Points (OPP) support to vote for RPMh state based
> > > on the aggregate link bandwidth.
> > >
> > > OPP can handle ICC bw voting also, so move ICC bw voting through OPP
> > > framework if OPP entries are present.
> > >
> > > Different link configurations may share the same aggregate bandwidth,
> > > e.g., a 2.5 GT/s x2 link and a 5.0 GT/s x1 link have the same bandwidth
> > > and share the same OPP entry.
> > >
> >
> > This info should be part of the dts change.
> >
> ok I will move this to dts patch in next patch series.
> > > As we are moving ICC voting as part of OPP, don't initialize ICC if OPP
> > > is supported.
> > >
> > > Before PCIe link is initialized vote for highest OPP in the OPP table,
> > > so that we are voting for maximum voltage corner for the link to come up
> > > in maximum supported speed.
> > >
> > > Signed-off-by: Krishna chaitanya chundru <quic_krichai@quicinc.com>
> > > ---
> > > drivers/pci/controller/dwc/pcie-qcom.c | 72 +++++++++++++++++++++++++++-------
> > > 1 file changed, 58 insertions(+), 14 deletions(-)
> > >
> > > diff --git a/drivers/pci/controller/dwc/pcie-qcom.c b/drivers/pci/controller/dwc/pcie-qcom.c
> > > index b4893214b2d3..4ad5ef3bf8fc 100644
> > > --- a/drivers/pci/controller/dwc/pcie-qcom.c
> > > +++ b/drivers/pci/controller/dwc/pcie-qcom.c
> > > @@ -22,6 +22,7 @@
> > > #include <linux/of.h>
> > > #include <linux/of_gpio.h>
> > > #include <linux/pci.h>
> > > +#include <linux/pm_opp.h>
> > > #include <linux/pm_runtime.h>
> > > #include <linux/platform_device.h>
> > > #include <linux/phy/pcie.h>
> > > @@ -1442,15 +1443,13 @@ static int qcom_pcie_icc_init(struct qcom_pcie *pcie)
> > > return 0;
> > > }
> > > -static void qcom_pcie_icc_update(struct qcom_pcie *pcie)
> > > +static void qcom_pcie_icc_opp_update(struct qcom_pcie *pcie)
> > > {
> > > struct dw_pcie *pci = pcie->pci;
> > > - u32 offset, status;
> > > + u32 offset, status, freq;
> > > + struct dev_pm_opp *opp;
> > > int speed, width;
> > > - int ret;
> > > -
> > > - if (!pcie->icc_mem)
> > > - return;
> > > + int ret, mbps;
> > > offset = dw_pcie_find_capability(pci, PCI_CAP_ID_EXP);
> > > status = readw(pci->dbi_base + offset + PCI_EXP_LNKSTA);
> > > @@ -1462,10 +1461,26 @@ static void qcom_pcie_icc_update(struct qcom_pcie *pcie)
> > > speed = FIELD_GET(PCI_EXP_LNKSTA_CLS, status);
> > > width = FIELD_GET(PCI_EXP_LNKSTA_NLW, status);
> > > - ret = icc_set_bw(pcie->icc_mem, 0, width * QCOM_PCIE_LINK_SPEED_TO_BW(speed));
> > > - if (ret) {
> > > - dev_err(pci->dev, "failed to set interconnect bandwidth for PCIe-MEM: %d\n",
> > > - ret);
> > > + if (pcie->icc_mem) {
> > > + ret = icc_set_bw(pcie->icc_mem, 0, width * QCOM_PCIE_LINK_SPEED_TO_BW(speed));
> > > + if (ret) {
> > > + dev_err(pci->dev, "failed to set interconnect bandwidth for PCIe-MEM: %d\n",
> >
> > s/failed/Failed
> >
> > > + ret);
> > > + }
> > > + } else {
> > > + mbps = pcie_link_speed_to_mbps(pcie_link_speed[speed]);
> > > + if (mbps < 0)
> > > + return;
> > > +
> > > + freq = mbps * 1000;
> > > + opp = dev_pm_opp_find_freq_exact(pci->dev, freq * width, true);
> >
> > As per the API documentation, dev_pm_opp_put() should be called for both success
> > and failure case.
> >
> ACK.
> > > + if (!IS_ERR(opp)) {
> >
> > So what is the action if OPP is not found for the freq?
> >
> There is already a vote for maximum freq in the probe, so if it fails
> here we can continue here.
> If you feel otherwise let me know I Can make changes as suggested.
You should just log the error and continue.
> > > + ret = dev_pm_opp_set_opp(pci->dev, opp);
> > > + if (ret)
> > > + dev_err(pci->dev, "Failed to set opp: freq %ld ret %d\n",
> >
> > 'Failed to set OPP for freq (%ld): %d'
> >
> > > + dev_pm_opp_get_freq(opp), ret);
> > > + dev_pm_opp_put(opp);
> > > + }
> > > }
> > > }
> > > @@ -1509,8 +1524,10 @@ static void qcom_pcie_init_debugfs(struct qcom_pcie *pcie)
> > > static int qcom_pcie_probe(struct platform_device *pdev)
> > > {
> > > const struct qcom_pcie_cfg *pcie_cfg;
> > > + unsigned long max_freq = INT_MAX;
> > > struct device *dev = &pdev->dev;
> > > struct qcom_pcie *pcie;
> > > + struct dev_pm_opp *opp;
> > > struct dw_pcie_rp *pp;
> > > struct resource *res;
> > > struct dw_pcie *pci;
> > > @@ -1577,9 +1594,33 @@ static int qcom_pcie_probe(struct platform_device *pdev)
> > > goto err_pm_runtime_put;
> > > }
> > > - ret = qcom_pcie_icc_init(pcie);
> > > - if (ret)
> > > + /* OPP table is optional */
> > > + ret = devm_pm_opp_of_add_table(dev);
> > > + if (ret && ret != -ENODEV) {
> > > + dev_err_probe(dev, ret, "Failed to add OPP table\n");
> > > goto err_pm_runtime_put;
> > > + }
> > > +
> > > + /*
> > > + * Use highest OPP here if the OPP table is present. At the end of
> >
> > I believe I asked you to add the information justifying why the highest OPP
> > should be used.
> >
> I added the info in the commit message, I will add as the comment in the
> next patch.
>
> > > + * the probe(), OPP will be updated using qcom_pcie_icc_opp_update().
> > > + */
> > > + if (!ret) {
> > > + opp = dev_pm_opp_find_freq_floor(dev, &max_freq);
> >
> > Same comment as dev_pm_opp_find_freq_exact().
> >
> > > + if (!IS_ERR(opp)) {
> > > + ret = dev_pm_opp_set_opp(dev, opp);
> > > + if (ret)
> > > + dev_err_probe(pci->dev, ret,
> > > + "Failed to set OPP: freq %ld\n",
> >
> > Same comment as above.
> >
> > > + dev_pm_opp_get_freq(opp));
> > > + dev_pm_opp_put(opp);
> >
> > So you want to continue even in the case of failure?
> >
> I wil make changes to fallback to driver voting for icc bw if it fails here.
That's not needed. If the OPP table is present, then failure to set OPP should
be treated as a hard failure.
- Mani
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH v3 5/5] arm64: dts: ti: k3-am62*: Add PHY2 region to USB wrapper node
From: Francesco Dolcini @ 2024-04-08 9:52 UTC (permalink / raw)
To: Roger Quadros
Cc: nm, vigneshr, afd, kristo, robh+dt, krzysztof.kozlowski+dt,
conor+dt, srk, r-gunasekaran, b-liu, linux-arm-kernel, devicetree,
linux-kernel
In-Reply-To: <20240201120332.4811-6-rogerq@kernel.org>
Hello Roger,
On Thu, Feb 01, 2024 at 02:03:32PM +0200, Roger Quadros wrote:
> Add PHY2 register space to USB wrapper node. This is required
> to deal with Errata i2409.
>
> Signed-off-by: Roger Quadros <rogerq@kernel.org>
What's the status/plan for this? v6.9-rc misses it and therefore we have
this error in the logs (and of course, we miss the workaround).
[ 0.583305] dwc3-am62 f910000.dwc3-usb: invalid resource (null)
[ 0.589304] dwc3-am62 f910000.dwc3-usb: can't map PHY IOMEM resource. Won't apply i2409 fix.
Apart for the error message, the change here seems required for the
hardware to properly function (IOW IMHO it should be back-ported to stable).
Francesco
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: iio: imu: add icm42688 inside inv_icm42600
From: Krzysztof Kozlowski @ 2024-04-08 9:52 UTC (permalink / raw)
To: inv.git-commit, jic23, robh, krzysztof.kozlowski+dt, conor+dt
Cc: lars, linux-iio, devicetree, Jean-Baptiste Maneyrol
In-Reply-To: <20240408090720.847107-2-inv.git-commit@tdk.com>
On 08/04/2024 11:07, inv.git-commit@tdk.com wrote:
> From: Jean-Baptiste Maneyrol <jean-baptiste.maneyrol@tdk.com>
>
> Add bindings for ICM-42688-P chip.
>
> Signed-off-by: Jean-Baptiste Maneyrol <jean-baptiste.maneyrol@tdk.com>
> ---
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
---
This is an automated instruction, just in case, because many review tags
are being ignored. If you know the process, you can skip it (please do
not feel offended by me posting it here - no bad intentions intended).
If you do not know the process, here is a short explanation:
Please add Acked-by/Reviewed-by/Tested-by tags when posting new
versions, under or above your Signed-off-by tag. Tag is "received", when
provided in a message replied to you on the mailing list. Tools like b4
can help here. However, there's no need to repost patches *only* to add
the tags. The upstream maintainer will do that for tags received on the
version they apply.
https://elixir.bootlin.com/linux/v6.5-rc3/source/Documentation/process/submitting-patches.rst#L577
Best regards,
Krzysztof
^ 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