* Re: (EXT) Re: (EXT) Re: [PATCH] arm64: dts: imx8mm-venice-gw73xx-0x: add dt overlays for serial modes
From: Shawn Guo @ 2022-01-26 7:44 UTC (permalink / raw)
To: Alexander Stein
Cc: Tim Harvey, Rob Herring, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, NXP Linux Team, Device Tree Mailing List,
open list, Linux ARM Mailing List
In-Reply-To: <6686721.lOV4Wx5bFT@steina-w>
On Wed, Jan 12, 2022 at 07:58:00AM +0100, Alexander Stein wrote:
> Am Dienstag, 11. Januar 2022, 18:53:29 CET schrieb Tim Harvey:
> > On Mon, Jan 10, 2022 at 11:20 PM Alexander Stein
> >
> > <alexander.stein@ew.tq-group.com> wrote:
> > > Am Dienstag, 11. Januar 2022, 01:00:21 CET schrieb Tim Harvey:
> > > > [SNIP]
> > > >
> > > > > diff --git a/arch/arm64/boot/dts/freescale/Makefile
> > > > > b/arch/arm64/boot/dts/freescale/Makefile index
> > > > > a14a6173b765..5ec8d59347b6
> > > > > 100644
> > > > > --- a/arch/arm64/boot/dts/freescale/Makefile
> > > > > +++ b/arch/arm64/boot/dts/freescale/Makefile
> > > > > @@ -44,6 +44,9 @@ dtb-$(CONFIG_ARCH_MXC) +=
> > > > > imx8mm-var-som-symphony.dtb
> > > > >
> > > > > dtb-$(CONFIG_ARCH_MXC) += imx8mm-venice-gw71xx-0x.dtb
> > > > > dtb-$(CONFIG_ARCH_MXC) += imx8mm-venice-gw72xx-0x.dtb
> > > > > dtb-$(CONFIG_ARCH_MXC) += imx8mm-venice-gw73xx-0x.dtb
> > > > >
> > > > > +dtb-$(CONFIG_ARCH_MXC) += imx8mm-venice-gw73xx-0x-rs232-rts.dtbo
> > > > > +dtb-$(CONFIG_ARCH_MXC) += imx8mm-venice-gw73xx-0x-rs422.dtbo
> > > > > +dtb-$(CONFIG_ARCH_MXC) += imx8mm-venice-gw73xx-0x-rs485.dtbo
> > > > >
> > > > > dtb-$(CONFIG_ARCH_MXC) += imx8mm-venice-gw7901.dtb
> > > > > dtb-$(CONFIG_ARCH_MXC) += imx8mm-venice-gw7902.dtb
> > > > > dtb-$(CONFIG_ARCH_MXC) += imx8mn-beacon-kit.dtb
> > > >
> > > > [SNIP]
> > > > I'm mostly interested to see if my approach to dt fragments here and
> > > > the naming of the files makes sense to others.
> > > >
> > > > This patch causes the kernel to build dtbo files for:
> > > > arch/arm64/boot/dts/freescale/imx8mm-venice-gw73xx-0x-rs232-rts.dtbo
> > > > arch/arm64/boot/dts/freescale/imx8mm-venice-gw73xx-0x-rs422.dtbo
> > > > arch/arm64/boot/dts/freescale/imx8mm-venice-gw73xx-0x-rs485.dtbo
> > > >
> > > > The intention is that these files are used by boot firmware (U-Boot)
> > > > to adjust the dtb before passing it to the kernel.
> > >
> > > Hi Tim,
> > >
> > > do these dtbo actually work? I'm wondering because I was trying to
> > > useoverlays myself and noticed that the had to be compiled with -@ for
> > > u-boot to be able
> > > to apply them. Apparently there are 2 possibilities:
> > Alexander,
> >
> > Yes, they work, but I do manually set DTC_FLAGS=-@ when building
> > kernel dtbs to make them work.
>
> I see, I expected something like this. That's why I responded to you.
>
> > > * Set "DTC_FLAGS_[dtb] := -@" yourself
> > > See https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/
> > > commit/?id=e426d63e752bdbe7d5ba2d872319dde9ab844a07
> > >
> > > * Use dedicated overlay target
> > > See https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/
> > > commit/?id=15d16d6dadf6947ac7f9a686c615995c5a426ce2
> > >
> > > You use neither of them. IIRC just naming the target file .dtbo will not
> > > apply symbols (-Q) during dtc call. Can you verify using 'V=1'
> > > Also I'm wondering which way is the best to go.
> >
> > I wasn't aware there was a way to do this via Makefiles. It seems that
> > perhaps Rob's approach with 'kbuild: Add generic rule to apply
> > fdtoverlay' is a way to avoid having to add them all manually in the
> > first approach? I must admit I'm not sure how to use that.
>
> I tried using this myself for my custom board. I feel it is a bit cumbersome
> to get it right.
> See https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/
> arch/arm64/boot/dts/xilinx/Makefile for an example.
>
> Essentially you define your .dtb as before and add another target (e.g. sm-
> k26-revA-sck-kv-g-revA-dtbs) where you add your .dtbo _after_ the original
> .dtb. This target needs to be added to 'dtb-y' as before.
>
> I suspect this way is needed to check the .dtbo against the base .dtb if it
> actually matches.
Yeah, I like this check. Tim, could you update your patch to follow
this pattern?
Shawn
^ permalink raw reply
* Re: [PATCH net-next v2 2/3] net: macb: Added ZynqMP-specific initialization
From: Claudiu.Beznea @ 2022-01-26 7:45 UTC (permalink / raw)
To: michal.simek, robert.hancock, netdev
Cc: davem, kuba, robh+dt, Nicolas.Ferre, devicetree
In-Reply-To: <ad19fcf6-7976-4fd4-bded-97e1021c99cf@xilinx.com>
On 26.01.2022 09:30, Michal Simek wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> On 1/25/22 18:05, Robert Hancock wrote:
>> The GEM controllers on ZynqMP were missing some initialization steps which
>> are required in some cases when using SGMII mode, which uses the PS-GTR
>> transceivers managed by the phy-zynqmp driver.
>>
>> The GEM core appears to need a hardware-level reset in order to work
>> properly in SGMII mode in cases where the GT reference clock was not
>> present at initial power-on. This can be done using a reset mapped to
>> the zynqmp-reset driver in the device tree.
>>
>> Also, when in SGMII mode, the GEM driver needs to ensure the PHY is
>> initialized and powered on when it is initializing.
>>
>> Signed-off-by: Robert Hancock <robert.hancock@calian.com>
>> ---
>> drivers/net/ethernet/cadence/macb_main.c | 48 +++++++++++++++++++++++-
>> 1 file changed, 47 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/ethernet/cadence/macb_main.c
>> b/drivers/net/ethernet/cadence/macb_main.c
>> index a363da928e8b..80882908a68f 100644
>> --- a/drivers/net/ethernet/cadence/macb_main.c
>> +++ b/drivers/net/ethernet/cadence/macb_main.c
>> @@ -34,7 +34,9 @@
>> #include <linux/udp.h>
>> #include <linux/tcp.h>
>> #include <linux/iopoll.h>
>> +#include <linux/phy/phy.h>
>> #include <linux/pm_runtime.h>
>> +#include <linux/reset.h>
>> #include "macb.h"
>>
>> /* This structure is only used for MACB on SiFive FU540 devices */
>> @@ -4455,6 +4457,50 @@ static int fu540_c000_init(struct platform_device
>> *pdev)
>> return macb_init(pdev);
>> }
>>
>> +static int zynqmp_init(struct platform_device *pdev)
>> +{
>> + struct net_device *dev = platform_get_drvdata(pdev);
>> + struct macb *bp = netdev_priv(dev);
>> + int ret;
>> +
>> + if (bp->phy_interface == PHY_INTERFACE_MODE_SGMII) {
>> + /* Ensure PS-GTR PHY device used in SGMII mode is ready */
>> + struct phy *sgmii_phy = devm_phy_get(&pdev->dev, "sgmii-phy");
>> +
>> + if (IS_ERR(sgmii_phy)) {
>> + ret = PTR_ERR(sgmii_phy);
>> + dev_err_probe(&pdev->dev, ret,
>> + "failed to get PS-GTR PHY\n");
>> + return ret;
>> + }
>> +
>> + ret = phy_init(sgmii_phy);
>> + if (ret) {
>> + dev_err(&pdev->dev, "failed to init PS-GTR PHY: %d\n",
>> + ret);
>> + return ret;
>> + }
>
> I think reset below should be here to follow correct startup sequence.
If that's the case is the functionality still kept if moving phy_power_on()
in macb_open() and the correspondent phy_power_off() in macb_close() ?
Also, Robert, please handle the error path in this function (with calls to
phy_exit(), phy_power_off()) and PHY handling in macb_remove().
Thank you,
Claudiu Beznea
>
> Thanks,
> Michal
>
>
>> +
>> + ret = phy_power_on(sgmii_phy);
>> + if (ret) {
>> + dev_err(&pdev->dev, "failed to power on PS-GTR PHY:
>> %d\n",
>> + ret);
>> + return ret;
>> + }
>> + }
>> +
>> + /* Fully reset GEM controller at hardware level using zynqmp-reset
>> driver,
>> + * if mapped in device tree.
>> + */
>> + ret = device_reset_optional(&pdev->dev);
>> + if (ret) {
>> + dev_err_probe(&pdev->dev, ret, "failed to reset controller");
>> + return ret;
>> + }
>> +
>> + return macb_init(pdev);
>> +}
>> +
>> static const struct macb_usrio_config sama7g5_usrio = {
>> .mii = 0,
>> .rmii = 1,
>> @@ -4550,7 +4596,7 @@ static const struct macb_config zynqmp_config = {
>> MACB_CAPS_GEM_HAS_PTP | MACB_CAPS_BD_RD_PREFETCH,
>> .dma_burst_length = 16,
>> .clk_init = macb_clk_init,
>> - .init = macb_init,
>> + .init = zynqmp_init,
>> .jumbo_max_len = 10240,
>> .usrio = &macb_default_usrio,
>> };
^ permalink raw reply
* Re: [PATCH v21 8/8] soc: mediatek: SVS: add mt8192 SVS GPU driver
From: Roger Lu @ 2022-01-26 7:49 UTC (permalink / raw)
To: AngeloGioacchino Del Regno, Matthias Brugger,
Enric Balletbo Serra, Kevin Hilman, Rob Herring, Nicolas Boichat,
Stephen Boyd, Philipp Zabel
Cc: Fan Chen, HenryC Chen, YT Lee, Xiaoqing Liu, Charles Yang,
Angus Lin, Mark Rutland, Nishanth Menon, devicetree,
linux-arm-kernel, linux-mediatek, linux-kernel, linux-pm,
Project_Global_Chrome_Upstream_Group, Guenter Roeck
In-Reply-To: <2c0e89c6-6e9c-9d12-703f-d71e22023e7a@collabora.com>
Hi AngeloGioacchino,
Sorry for the late reply.
On Fri, 2022-01-07 at 15:33 +0100, AngeloGioacchino Del Regno wrote:
> Il 07/01/22 10:52, Roger Lu ha scritto:
> > mt8192 SVS GPU uses 2-line (high/low bank) HW architecture to provide
> > bank voltages. High bank helps update higher frequency's voltage
> > and low bank helps update lower frequency's voltage.
> >
> > Signed-off-by: Roger Lu <roger.lu@mediatek.com>
> > ---
> > drivers/soc/mediatek/mtk-svs.c | 469 ++++++++++++++++++++++++++++++++-
> > 1 file changed, 464 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/soc/mediatek/mtk-svs.c b/drivers/soc/mediatek/mtk-svs.c
> > index 93cdaecadd6d..bec6524ab33a 100644
> > --- a/drivers/soc/mediatek/mtk-svs.c
> > +++ b/drivers/soc/mediatek/mtk-svs.c
>
> ..snip..
>
> > @@ -639,9 +706,11 @@ static int svs_status_debug_show(struct seq_file *m,
> > void *v)
> >
> > ret = svs_get_zone_temperature(svsb->tzone_name, &tzone_temp);
> > if (ret)
> > - seq_printf(m, "%s: temperature ignore\n", svsb->name);
> > + seq_printf(m, "%s: temperature ignore, turn_pt = %u\n",
> > + svsb->name, svsb->turn_pt);
> > else
> > - seq_printf(m, "%s: temperature = %d\n", svsb->name, tzone_temp);
> > + seq_printf(m, "%s: temperature = %d, turn_pt = %u\n",
> > + svsb->name, tzone_temp, svsb->turn_pt);
> >
> > for (i = 0; i < svsb->opp_count; i++) {
> > opp = dev_pm_opp_find_freq_exact(svsb->opp_dev,
> > @@ -784,6 +853,181 @@ static u32 interpolate(u32 f0, u32 f1, u32 v0, u32 v1,
> > u32 fx)
> > return DIV_ROUND_UP(vx, 100);
> > }
> >
> > +static void svs_get_bank_volts_v3(struct svs_platform *svsp)
> > +{
> > + struct svs_bank *svsb = svsp->pbank;
> > + u32 i, j, *vop, vop74, vop30, mask7_0 = GENMASK(7, 0);
> > + u32 b_sft, bits8 = 8, shift_byte = 0, reg_bytes = 4;
>
> mask7_0, bits8, reg_bytes are constants, and it's not right to declare
> constants
> as variables like you're doing here.
>
> Please replace all usages of `mask7_0` with either a definition or with the
> call
> to the GENMASK macro;
> also, replace all usages of `bits8` with a definition, or just 8;
> finally, either make `reg_bytes` a `const u8` or a definition.
>
>
> In my opinion, a #define would be preferred, since the exact same comments on
> the exact same values also apply to function svs_set_bank_freq_pct_v3().
>
> After that fix, you'll get my R-b.
>
> I feel like v22 will be golden :)
No problem. I'll use GENMASK macro and replace bits8/reg_bytes with
definition. Thanks for the tutorial a lot. :)
>
> Regards,
> - Angelo
>
> > + u32 middle_index = (svsb->opp_count / 2);
> > + u32 opp_start = 0, opp_stop = 0, turn_pt = svsb->turn_pt;
> > +
> > + if (svsb->phase == SVSB_PHASE_MON &&
> > + svsb->volt_flags & SVSB_MON_VOLT_IGNORE)
> > + return;
> > +
> > + vop74 = svs_readl_relaxed(svsp, VOP74);
> > + vop30 = svs_readl_relaxed(svsp, VOP30);
> > +
> > + /* Target is to set svsb->volt[] by algorithm */
> > + if (turn_pt < middle_index) {
> > + if (svsb->type == SVSB_HIGH) {
> > + /* volt[0] ~ volt[turn_pt - 1] */
> > + for (i = 0; i < turn_pt; i++) {
> > + b_sft = bits8 * (shift_byte % reg_bytes);
> > + vop = (shift_byte < reg_bytes) ? &vop30 :
> > + &vop74;
> > + svsb->volt[i] = (*vop >> b_sft) & mask7_0;
> > + shift_byte++;
> > + }
> > + } else if (svsb->type == SVSB_LOW) {
> > + /* volt[turn_pt] + volt[j] ~ volt[opp_count - 1] */
> > + j = svsb->opp_count - 7;
> > + svsb->volt[turn_pt] = vop30 & mask7_0;
> > + shift_byte++;
> > + for (i = j; i < svsb->opp_count; i++) {
> > + b_sft = bits8 * (shift_byte % reg_bytes);
> > + vop = (shift_byte < reg_bytes) ? &vop30 :
> > + &vop74;
> > + svsb->volt[i] = (*vop >> b_sft) & mask7_0;
> > + shift_byte++;
> > + }
> > +
> > + /* volt[turn_pt + 1] ~ volt[j - 1] by interpolate */
> > + for (i = turn_pt + 1; i < j; i++)
> > + svsb->volt[i] =
> > + interpolate(svsb->freq_pct[turn_pt],
> > + svsb->freq_pct[j],
> > + svsb->volt[turn_pt],
> > + svsb->volt[j],
> > + svsb->freq_pct[i]);
> > + }
> > + } else {
> > + if (svsb->type == SVSB_HIGH) {
> > + /* volt[0] + volt[j] ~ volt[turn_pt - 1] */
> > + j = turn_pt - 7;
> > + svsb->volt[0] = vop30 & mask7_0;
> > + shift_byte++;
> > + for (i = j; i < turn_pt; i++) {
> > + b_sft = bits8 * (shift_byte % reg_bytes);
> > + vop = (shift_byte < reg_bytes) ? &vop30 :
> > + &vop74;
> > + svsb->volt[i] = (*vop >> b_sft) & mask7_0;
> > + shift_byte++;
> > + }
> > +
> > + /* volt[1] ~ volt[j - 1] by interpolate */
> > + for (i = 1; i < j; i++)
> > + svsb->volt[i] =
> > + interpolate(svsb->freq_pct[0],
> > + svsb->freq_pct[j],
> > + svsb->volt[0],
> > + svsb->volt[j],
> > + svsb->freq_pct[i]);
> > + } else if (svsb->type == SVSB_LOW) {
> > + /* volt[turn_pt] ~ volt[opp_count - 1] */
> > + for (i = turn_pt; i < svsb->opp_count; i++) {
> > + b_sft = bits8 * (shift_byte % reg_bytes);
> > + vop = (shift_byte < reg_bytes) ? &vop30 :
> > + &vop74;
> > + svsb->volt[i] = (*vop >> b_sft) & mask7_0;
> > + shift_byte++;
> > + }
> > + }
> > + }
> > +
> > + if (svsb->type == SVSB_HIGH) {
> > + opp_start = 0;
> > + opp_stop = svsb->turn_pt;
> > + } else if (svsb->type == SVSB_LOW) {
> > + opp_start = svsb->turn_pt;
> > + opp_stop = svsb->opp_count;
> > + }
> > +
> > + for (i = opp_start; i < opp_stop; i++)
> > + if (svsb->volt_flags & SVSB_REMOVE_DVTFIXED_VOLT)
> > + svsb->volt[i] -= svsb->dvt_fixed;
> > +}
> > +
> > +static void svs_set_bank_freq_pct_v3(struct svs_platform *svsp)
> > +{
> > + struct svs_bank *svsb = svsp->pbank;
> > + u32 i, j, *freq_pct, freq_pct74 = 0, freq_pct30 = 0;
> > + u32 b_sft, bits8 = 8, shift_byte = 0, reg_bytes = 4;
> > + u32 middle_index = (svsb->opp_count / 2);
> > + u32 turn_pt = middle_index;
> > +
> > + for (i = 0; i < svsb->opp_count; i++) {
> > + if (svsb->opp_dfreq[i] <= svsb->turn_freq_base) {
> > + svsb->turn_pt = i;
> > + break;
> > + }
> > + }
> > +
> > + turn_pt = svsb->turn_pt;
> > +
> > + /* Target is to fill out freq_pct74 / freq_pct30 by algorithm */
> > + if (turn_pt < middle_index) {
> > + if (svsb->type == SVSB_HIGH) {
> > + /* Edge case for preventing freq_pct30 from being 0 */
> > + if (turn_pt == 0)
> > + freq_pct30 = svsb->freq_pct[0];
> > +
> > + /* freq_pct[0] ~ freq_pct[turn_pt - 1] */
> > + for (i = 0; i < turn_pt; i++) {
> > + b_sft = bits8 * (shift_byte % reg_bytes);
> > + freq_pct = (shift_byte < reg_bytes) ?
> > + &freq_pct30 : &freq_pct74;
> > + *freq_pct |= (svsb->freq_pct[i] << b_sft);
> > + shift_byte++;
> > + }
> > + } else if (svsb->type == SVSB_LOW) {
> > + /*
> > + * freq_pct[turn_pt] +
> > + * freq_pct[opp_count - 7] ~ freq_pct[opp_count -1]
> > + */
> > + freq_pct30 = svsb->freq_pct[turn_pt];
> > + shift_byte++;
> > + j = svsb->opp_count - 7;
> > + for (i = j; i < svsb->opp_count; i++) {
> > + b_sft = bits8 * (shift_byte % reg_bytes);
> > + freq_pct = (shift_byte < reg_bytes) ?
> > + &freq_pct30 : &freq_pct74;
> > + *freq_pct |= (svsb->freq_pct[i] << b_sft);
> > + shift_byte++;
> > + }
> > + }
> > + } else {
> > + if (svsb->type == SVSB_HIGH) {
> > + /*
> > + * freq_pct[0] +
> > + * freq_pct[turn_pt - 7] ~ freq_pct[turn_pt - 1]
> > + */
> > + freq_pct30 = svsb->freq_pct[0];
> > + shift_byte++;
> > + j = turn_pt - 7;
> > + for (i = j; i < turn_pt; i++) {
> > + b_sft = bits8 * (shift_byte % reg_bytes);
> > + freq_pct = (shift_byte < reg_bytes) ?
> > + &freq_pct30 : &freq_pct74;
> > + *freq_pct |= (svsb->freq_pct[i] << b_sft);
> > + shift_byte++;
> > + }
> > + } else if (svsb->type == SVSB_LOW) {
> > + /* freq_pct[turn_pt] ~ freq_pct[opp_count - 1] */
> > + for (i = turn_pt; i < svsb->opp_count; i++) {
> > + b_sft = bits8 * (shift_byte % reg_bytes);
> > + freq_pct = (shift_byte < reg_bytes) ?
> > + &freq_pct30 : &freq_pct74;
> > + *freq_pct |= (svsb->freq_pct[i] << b_sft);
> > + shift_byte++;
> > + }
> > + }
> > + }
> > +
> > + svs_writel_relaxed(svsp, freq_pct74, FREQPCT74);
> > + svs_writel_relaxed(svsp, freq_pct30, FREQPCT30);
> > +}
> > +
> > static void svs_get_bank_volts_v2(struct svs_platform *svsp)
> > {
> > struct svs_bank *svsb = svsp->pbank;
>
>
>
> _______________________________________________
> Linux-mediatek mailing list
> Linux-mediatek@lists.infradead.org
>
https://urldefense.com/v3/__http://lists.infradead.org/mailman/listinfo/linux-mediatek__;!!CTRNKA9wMg0ARbw!2hHinI997WLSwDhGwMLxsnPzZMt8US0HmcDwqKvo2yvyiHuJ7AR4BSd7C_Z2haFK$
>
^ permalink raw reply
* Re: [RFC PATCH 0/2] Multicolor PWM LED support
From: Sven Schwermer @ 2022-01-26 7:51 UTC (permalink / raw)
To: Jacek Anaszewski, linux-leds, devicetree, linux-pwm
Cc: Sven Schwermer, pavel, robh+dt, thierry.reding, u.kleine-koenig,
lee.jones
In-Reply-To: <a147897a-2823-ad45-d727-0b96f48b4da3@gmail.com>
Hi Jacek,
Thank you for your feedback!
On 1/25/22 23:31, Jacek Anaszewski wrote:
>> 1. Currently, the max-brightness property is expected as a property to
>> the multi-led node. That seems consistent with the existing
>> multicolor class code, but I'm wondering whether it would make
>> sense to have a max-brigthness for the individual LEDs as well?
>
> For the proper mixed color calculation all sub-leds should have
> the same max_brightness as the global max_brightness.
>
> Look at how sub-led intensities are calculated in
> led_mc_calc_color_components().
>
> See also [0] and [1].
OK, thanks. That makes sense.
>> 2. The current multi-led node definition calls for a node index which
>> would in turn require the reg property to be set within the node.
>> In this context, that doesn't seem to make sense. Should this
>> requirement be lifted from leds-class-multicolor.yaml?
>
> reg is required for all DT nodes with address unit in the name.
> If you skipped the address unit, then reg would be also not required.
Yes, I realize this. However, leds-class-multicolor.yaml [0] requires
the address unit: "^multi-led@([0-9a-f])$"
Best regards,
Sven
[0] Documentation/devicetree/bindings/leds/leds-class-multicolor.yaml
^ permalink raw reply
* Re: [RFC PATCH v2 1/2] dt-bindings: leds: Add multicolor PWM LED bindings
From: Sven Schwermer @ 2022-01-26 8:02 UTC (permalink / raw)
To: Marek Behún
Cc: linux-leds, devicetree, linux-pwm, Sven Schwermer, pavel, robh+dt,
thierry.reding, u.kleine-koenig, lee.jones, post
In-Reply-To: <20220125212736.5ffafe2b@thinkpad>
Hi Marek,
On 1/25/22 21:27, Marek Behún wrote:
> what about
>
> multi-led@0 {
> color = <LED_COLOR_ID_RGB>;
> function = LED_FUNCTION_INDICATOR;
> pwms = <&pwm1 0 1000000>,
> <&pwm2 0 1000000>,
> <&pwm3 0 1000000>;
> channels = <LED_COLOR_ID_RED>,
> <LED_COLOR_ID_GREEN>,
> <LED_COLOR_ID_BLUE>;
> };
>
> I am not saying that it is necessarily better, just comenting that
> maybe it is, since it saves some space. `pwms` is phandle-array, so it
> can contain references to multiple pwms, and we have functions which
> make getting these pwms in driver code easy...
This this nice. I misunderstood the requirements by the multicolor LED
class so I didn't think this was possible. I will change my patch.
> Also this example won't compile with
> make dt_bindings_check
> because you don't have pwm1, pwm2
> and pwm3 defined...
Yes, it does. The checker compiles the example DTS snippets with this in
the header: /plugin/; // silence any missing phandle references
Best regards,
Sven
^ permalink raw reply
* Re: [RFC PATCH 0/2] Multicolor PWM LED support
From: Alexander Dahl @ 2022-01-26 8:08 UTC (permalink / raw)
To: sven
Cc: linux-leds, devicetree, linux-pwm, Sven Schwermer, pavel, dmurphy,
robh+dt, thierry.reding, u.kleine-koenig, lee.jones
In-Reply-To: <20220125092239.2006333-1-sven@svenschwermer.de>
Hello Sven,
Am Tue, Jan 25, 2022 at 10:22:37AM +0100 schrieb sven@svenschwermer.de:
> From: Sven Schwermer <sven.schwermer@disruptive-technologies.com>
> As previously discussed [1] on the linux-leds list I am missing
> multicolor PWM LED support. In the mean time I have put together a
> working prototype for such a driver. This is my first Linux driver
> so I'm hoping for some feedback. Here are some questions that came up
> while putting this thing together:
Wow, I did not expect this so quickly. Thank you. :-)
> 1. Currently, the max-brightness property is expected as a property to
> the multi-led node. That seems consistent with the existing
> multicolor class code, but I'm wondering whether it would make
> sense to have a max-brigthness for the individual LEDs as well?
> 2. The current multi-led node definition calls for a node index which
> would in turn require the reg property to be set within the node.
> In this context, that doesn't seem to make sense. Should this
> requirement be lifted from leds-class-multicolor.yaml?
> 3. I'm not currently reusing any leds-pwm code because there aren't
> too many overlaps. Does anyone have suggestions what could be
> factored out into a common source file?
>
> I would appreciate if anyone would test this code. It runs on my
> i.MX6ULL-based hardware.
>
> Best regards,
> Sven
>
> [1]: https://www.spinics.net/lists/linux-leds/msg19988.html
You can use the lore.kernel.org archive, e.g. in this case:
https://lore.kernel.org/linux-leds/b48eed49-a18e-eed1-f1f4-77b9f1eab39b@gmail.com/T/#t
Greets
Alex
>
> Sven Schwermer (2):
> dt-bindings: leds: Add multicolor PWM LED bindings
> leds: Add PWM multicolor driver
>
> .../bindings/leds/leds-pwm-multicolor.yaml | 73 +++++++
> drivers/leds/Kconfig | 8 +
> drivers/leds/Makefile | 1 +
> drivers/leds/leds-pwm-multicolor.c | 184 ++++++++++++++++++
> 4 files changed, 266 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/leds/leds-pwm-multicolor.yaml
> create mode 100644 drivers/leds/leds-pwm-multicolor.c
>
> --
> 2.35.0
>
^ permalink raw reply
* Re: [PATCH 01/12] arm64: dts: exynos: add USB DWC3 supplies to Espresso board
From: Krzysztof Kozlowski @ 2022-01-26 8:10 UTC (permalink / raw)
To: Alim Akhtar
Cc: Greg Kroah-Hartman, Rob Herring, linux-usb, devicetree,
linux-arm-kernel, linux-samsung-soc, open list
In-Reply-To: <CAGOxZ51zavNVpvUv0C17Cit+pdkERC70m5Ez3ELGpFh8tGDozQ@mail.gmail.com>
On 26/01/2022 07:58, Alim Akhtar wrote:
> Hi Krzysztof
>
> On Mon, Jan 24, 2022 at 1:34 PM Krzysztof Kozlowski
> <krzysztof.kozlowski@canonical.com> wrote:
>>
>> Add required voltage regulators for USB DWC3 block on Exynos7 Espresso
>> board. Due to lack of schematics of Espresso board, the choice of
>> regulators is approximate. What bindings call VDD10, for Exynos7 should
>> be actually called VDD09 (0.9 V). Use regulators with a matching
>> voltage range based on vendor sources for Meizu Pro 5 M576 handset (also
>> with Exynos7420).
>>
>
> I checked Espresso board schematic, it is 0.9V for the USB and supplied by LDO4
>
Thanks for checking!
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v4 0/2] Add support for LPASS Core and Audio Clock for SC7280
From: Taniya Das @ 2022-01-26 8:12 UTC (permalink / raw)
To: Stephen Boyd, Michael Turquette
Cc: Rajendra Nayak, linux-arm-msm, linux-soc, linux-clk, linux-kernel,
devicetree, robh, robh+dt, Taniya Das
[v4]
* Cleanup header file inclusion in the clock controller files.
* Update the regmap_config max_registers in all clock controller
probes.
[v3]
* Fix 'pm_clk_suspend' expansion warning in lpass_audio_cc_sc7280_probe
and lpass_aon_cc_sc7280_probe.
* Update the vco table frequencies.
* Update 'regmap_config' name for all clock controllers.
* Fix the missing 'const' for clk_init_data.
* Update the binding for 'lpass_aon' CC.
[v2]
* Drop code for "Add support for clock voting from GDSC" from
drivers/clk/qcom/gdsc.c
* Add support for runtime PM get/put from clk_summary.
* Update commit message for PLL detect lock timeout increase.
* Fix documentation bindings errors reported by DT_CHECKER_FLAGS.
* Update the driver code to take care of the following
- KCONFIG to add "select QCOM_GDSC"
- Use of "const" for pll_vco and clk_init_data
- Use of index instead of fw_name.
- Fix extra space, remove 'lpass_create_pm_clks' and corresponding code.
- cleanup 'lpass_hm_core_probe' and 'lpass_hm_sc7280_match_table'.
[v1]
This patchset supports the following.
- Few PLLs might require to a higher time to detect lock, thus increase the
polling time.
- GDSC which require clocks to be explicitly enabled before access.
- LPASS core and audio clock driver support for SC7280.
*** BLURB HERE ***
Taniya Das (2):
dt-bindings: clock: Add YAML schemas for LPASS clocks on SC7280
clk: qcom: lpass: Add support for LPASS clock controller for SC7280
.../clock/qcom,sc7280-lpasscorecc.yaml | 172 ++++
drivers/clk/qcom/Kconfig | 10 +
drivers/clk/qcom/Makefile | 1 +
drivers/clk/qcom/lpassaudiocc-sc7280.c | 838 ++++++++++++++++++
drivers/clk/qcom/lpasscorecc-sc7280.c | 431 +++++++++
.../clock/qcom,lpassaudiocc-sc7280.h | 43 +
.../clock/qcom,lpasscorecc-sc7280.h | 26 +
7 files changed, 1521 insertions(+)
create mode 100644 Documentation/devicetree/bindings/clock/qcom,sc7280-lpasscorecc.yaml
create mode 100644 drivers/clk/qcom/lpassaudiocc-sc7280.c
create mode 100644 drivers/clk/qcom/lpasscorecc-sc7280.c
create mode 100644 include/dt-bindings/clock/qcom,lpassaudiocc-sc7280.h
create mode 100644 include/dt-bindings/clock/qcom,lpasscorecc-sc7280.h
--
Qualcomm INDIA, on behalf of Qualcomm Innovation Center, Inc.is a member
of the Code Aurora Forum, hosted by the Linux Foundation.
^ permalink raw reply
* [PATCH v4 1/2] dt-bindings: clock: Add YAML schemas for LPASS clocks on SC7280
From: Taniya Das @ 2022-01-26 8:12 UTC (permalink / raw)
To: Stephen Boyd, Michael Turquette
Cc: Rajendra Nayak, linux-arm-msm, linux-soc, linux-clk, linux-kernel,
devicetree, robh, robh+dt, Taniya Das
In-Reply-To: <20220126081236.25255-1-tdas@codeaurora.org>
The LPASS(Low Power Audio Subsystem) clock provider have a bunch of generic
properties that are needed in a device tree. Also add clock ids for
LPASS core clocks and audio clock IDs for LPASS client to request for
the clocks.
Signed-off-by: Taniya Das <tdas@codeaurora.org>
---
.../clock/qcom,sc7280-lpasscorecc.yaml | 172 ++++++++++++++++++
.../clock/qcom,lpassaudiocc-sc7280.h | 43 +++++
.../clock/qcom,lpasscorecc-sc7280.h | 26 +++
3 files changed, 241 insertions(+)
create mode 100644 Documentation/devicetree/bindings/clock/qcom,sc7280-lpasscorecc.yaml
create mode 100644 include/dt-bindings/clock/qcom,lpassaudiocc-sc7280.h
create mode 100644 include/dt-bindings/clock/qcom,lpasscorecc-sc7280.h
diff --git a/Documentation/devicetree/bindings/clock/qcom,sc7280-lpasscorecc.yaml b/Documentation/devicetree/bindings/clock/qcom,sc7280-lpasscorecc.yaml
new file mode 100644
index 000000000000..bad9135489de
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,sc7280-lpasscorecc.yaml
@@ -0,0 +1,172 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/qcom,sc7280-lpasscorecc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm LPASS Core & Audio Clock Controller Binding for SC7280
+
+maintainers:
+ - Taniya Das <tdas@codeaurora.org>
+
+description: |
+ Qualcomm LPASS core and audio clock control module which supports the
+ clocks and power domains on SC7280.
+
+ See also:
+ - dt-bindings/clock/qcom,lpasscorecc-sc7280.h
+ - dt-bindings/clock/qcom,lpassaudiocc-sc7280.h
+
+properties:
+ clocks: true
+
+ clock-names: true
+
+ compatible:
+ enum:
+ - qcom,sc7280-lpassaoncc
+ - qcom,sc7280-lpassaudiocc
+ - qcom,sc7280-lpasscorecc
+ - qcom,sc7280-lpasshm
+
+ power-domains:
+ maxItems: 1
+
+ '#clock-cells':
+ const: 1
+
+ '#power-domain-cells':
+ const: 1
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - '#clock-cells'
+ - '#power-domain-cells'
+
+additionalProperties: false
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: qcom,sc7280-lpassaudiocc
+
+ then:
+ properties:
+ clocks:
+ items:
+ - description: Board XO source
+ - description: LPASS_AON_CC_MAIN_RCG_CLK_SRC
+
+ clock-names:
+ items:
+ - const: bi_tcxo
+ - const: lpass_aon_cc_main_rcg_clk_src
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,sc7280-lpassaoncc
+
+ then:
+ properties:
+ clocks:
+ items:
+ - description: Board XO source
+ - description: Board XO active only source
+ - description: LPASS_AON_CC_MAIN_RCG_CLK_SRC
+
+ clock-names:
+ items:
+ - const: bi_tcxo
+ - const: bi_tcxo_ao
+ - const: iface
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,sc7280-lpasshm
+ - qcom,sc7280-lpasscorecc
+
+ then:
+ properties:
+ clocks:
+ items:
+ - description: Board XO source
+
+ clock-names:
+ items:
+ - const: bi_tcxo
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,rpmh.h>
+ #include <dt-bindings/clock/qcom,gcc-sc7280.h>
+ #include <dt-bindings/clock/qcom,lpassaudiocc-sc7280.h>
+ #include <dt-bindings/clock/qcom,lpasscorecc-sc7280.h>
+ lpass_audiocc: clock-controller@3300000 {
+ compatible = "qcom,sc7280-lpassaudiocc";
+ reg = <0x3300000 0x30000>;
+ clocks = <&rpmhcc RPMH_CXO_CLK>,
+ <&lpass_aon LPASS_AON_CC_MAIN_RCG_CLK_SRC>;
+ clock-names = "bi_tcxo", "lpass_aon_cc_main_rcg_clk_src";
+ power-domains = <&lpass_aon LPASS_AON_CC_LPASS_AUDIO_HM_GDSC>;
+ #clock-cells = <1>;
+ #power-domain-cells = <1>;
+ };
+
+ - |
+ #include <dt-bindings/clock/qcom,rpmh.h>
+ #include <dt-bindings/clock/qcom,gcc-sc7280.h>
+ #include <dt-bindings/clock/qcom,lpassaudiocc-sc7280.h>
+ #include <dt-bindings/clock/qcom,lpasscorecc-sc7280.h>
+ lpass_hm: clock-controller@3c00000 {
+ compatible = "qcom,sc7280-lpasshm";
+ reg = <0x3c00000 0x28>;
+ clocks = <&rpmhcc RPMH_CXO_CLK>;
+ clock-names = "bi_tcxo";
+ #clock-cells = <1>;
+ #power-domain-cells = <1>;
+ };
+
+ - |
+ #include <dt-bindings/clock/qcom,rpmh.h>
+ #include <dt-bindings/clock/qcom,gcc-sc7280.h>
+ #include <dt-bindings/clock/qcom,lpassaudiocc-sc7280.h>
+ #include <dt-bindings/clock/qcom,lpasscorecc-sc7280.h>
+ lpasscore: clock-controller@3900000 {
+ compatible = "qcom,sc7280-lpasscorecc";
+ reg = <0x3900000 0x50000>;
+ clocks = <&rpmhcc RPMH_CXO_CLK>;
+ clock-names = "bi_tcxo";
+ power-domains = <&lpass_hm LPASS_CORE_CC_LPASS_CORE_HM_GDSC>;
+ #clock-cells = <1>;
+ #power-domain-cells = <1>;
+ };
+
+ - |
+ #include <dt-bindings/clock/qcom,rpmh.h>
+ #include <dt-bindings/clock/qcom,gcc-sc7280.h>
+ #include <dt-bindings/clock/qcom,lpassaudiocc-sc7280.h>
+ #include <dt-bindings/clock/qcom,lpasscorecc-sc7280.h>
+ lpass_aon: clock-controller@3380000 {
+ compatible = "qcom,sc7280-lpassaoncc";
+ reg = <0x3380000 0x30000>;
+ clocks = <&rpmhcc RPMH_CXO_CLK>, <&rpmhcc RPMH_CXO_CLK_A>,
+ <&lpasscore LPASS_CORE_CC_CORE_CLK>;
+ clock-names = "bi_tcxo", "bi_tcxo_ao","iface";
+ #clock-cells = <1>;
+ #power-domain-cells = <1>;
+ };
+
+...
diff --git a/include/dt-bindings/clock/qcom,lpassaudiocc-sc7280.h b/include/dt-bindings/clock/qcom,lpassaudiocc-sc7280.h
new file mode 100644
index 000000000000..20ef2ea673f3
--- /dev/null
+++ b/include/dt-bindings/clock/qcom,lpassaudiocc-sc7280.h
@@ -0,0 +1,43 @@
+/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
+/*
+ * Copyright (c) 2021, The Linux Foundation. All rights reserved.
+ */
+
+#ifndef _DT_BINDINGS_CLK_QCOM_LPASS_AUDIO_CC_SC7280_H
+#define _DT_BINDINGS_CLK_QCOM_LPASS_AUDIO_CC_SC7280_H
+
+/* LPASS_AUDIO_CC clocks */
+#define LPASS_AUDIO_CC_PLL 0
+#define LPASS_AUDIO_CC_PLL_OUT_AUX2 1
+#define LPASS_AUDIO_CC_PLL_OUT_AUX2_DIV_CLK_SRC 2
+#define LPASS_AUDIO_CC_PLL_OUT_MAIN_DIV_CLK_SRC 3
+#define LPASS_AUDIO_CC_CDIV_RX_MCLK_DIV_CLK_SRC 4
+#define LPASS_AUDIO_CC_CODEC_MEM0_CLK 5
+#define LPASS_AUDIO_CC_CODEC_MEM1_CLK 6
+#define LPASS_AUDIO_CC_CODEC_MEM2_CLK 7
+#define LPASS_AUDIO_CC_CODEC_MEM_CLK 8
+#define LPASS_AUDIO_CC_EXT_MCLK0_CLK 9
+#define LPASS_AUDIO_CC_EXT_MCLK0_CLK_SRC 10
+#define LPASS_AUDIO_CC_EXT_MCLK1_CLK 11
+#define LPASS_AUDIO_CC_EXT_MCLK1_CLK_SRC 12
+#define LPASS_AUDIO_CC_RX_MCLK_2X_CLK 13
+#define LPASS_AUDIO_CC_RX_MCLK_CLK 14
+#define LPASS_AUDIO_CC_RX_MCLK_CLK_SRC 15
+
+/* LPASS_AON_CC clocks */
+#define LPASS_AON_CC_PLL 0
+#define LPASS_AON_CC_PLL_OUT_EVEN 1
+#define LPASS_AON_CC_PLL_OUT_MAIN_CDIV_DIV_CLK_SRC 2
+#define LPASS_AON_CC_PLL_OUT_ODD 3
+#define LPASS_AON_CC_AUDIO_HM_H_CLK 4
+#define LPASS_AON_CC_CDIV_TX_MCLK_DIV_CLK_SRC 5
+#define LPASS_AON_CC_MAIN_RCG_CLK_SRC 6
+#define LPASS_AON_CC_TX_MCLK_2X_CLK 7
+#define LPASS_AON_CC_TX_MCLK_CLK 8
+#define LPASS_AON_CC_TX_MCLK_RCG_CLK_SRC 9
+#define LPASS_AON_CC_VA_MEM0_CLK 10
+
+/* LPASS_AON_CC power domains */
+#define LPASS_AON_CC_LPASS_AUDIO_HM_GDSC 0
+
+#endif
diff --git a/include/dt-bindings/clock/qcom,lpasscorecc-sc7280.h b/include/dt-bindings/clock/qcom,lpasscorecc-sc7280.h
new file mode 100644
index 000000000000..28ed2a07aacc
--- /dev/null
+++ b/include/dt-bindings/clock/qcom,lpasscorecc-sc7280.h
@@ -0,0 +1,26 @@
+/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
+/*
+ * Copyright (c) 2021, The Linux Foundation. All rights reserved.
+ */
+
+#ifndef _DT_BINDINGS_CLK_QCOM_LPASS_CORE_CC_SC7280_H
+#define _DT_BINDINGS_CLK_QCOM_LPASS_CORE_CC_SC7280_H
+
+/* LPASS_CORE_CC clocks */
+#define LPASS_CORE_CC_DIG_PLL 0
+#define LPASS_CORE_CC_DIG_PLL_OUT_MAIN_DIV_CLK_SRC 1
+#define LPASS_CORE_CC_DIG_PLL_OUT_ODD 2
+#define LPASS_CORE_CC_CORE_CLK 3
+#define LPASS_CORE_CC_CORE_CLK_SRC 4
+#define LPASS_CORE_CC_EXT_IF0_CLK_SRC 5
+#define LPASS_CORE_CC_EXT_IF0_IBIT_CLK 6
+#define LPASS_CORE_CC_EXT_IF1_CLK_SRC 7
+#define LPASS_CORE_CC_EXT_IF1_IBIT_CLK 8
+#define LPASS_CORE_CC_LPM_CORE_CLK 9
+#define LPASS_CORE_CC_LPM_MEM0_CORE_CLK 10
+#define LPASS_CORE_CC_SYSNOC_MPORT_CORE_CLK 11
+
+/* LPASS_CORE_CC power domains */
+#define LPASS_CORE_CC_LPASS_CORE_HM_GDSC 0
+
+#endif
--
Qualcomm INDIA, on behalf of Qualcomm Innovation Center, Inc.is a member
of the Code Aurora Forum, hosted by the Linux Foundation.
^ permalink raw reply related
* [PATCH v4 2/2] clk: qcom: lpass: Add support for LPASS clock controller for SC7280
From: Taniya Das @ 2022-01-26 8:12 UTC (permalink / raw)
To: Stephen Boyd, Michael Turquette
Cc: Rajendra Nayak, linux-arm-msm, linux-soc, linux-clk, linux-kernel,
devicetree, robh, robh+dt, Taniya Das
In-Reply-To: <20220126081236.25255-1-tdas@codeaurora.org>
The Low Power Audio subsystem core and audio clocks are required for
Audio client to be able to request for the clocks and power domains.
Signed-off-by: Taniya Das <tdas@codeaurora.org>
---
drivers/clk/qcom/Kconfig | 10 +
drivers/clk/qcom/Makefile | 1 +
drivers/clk/qcom/lpassaudiocc-sc7280.c | 838 +++++++++++++++++++++++++
drivers/clk/qcom/lpasscorecc-sc7280.c | 431 +++++++++++++
4 files changed, 1280 insertions(+)
create mode 100644 drivers/clk/qcom/lpassaudiocc-sc7280.c
create mode 100644 drivers/clk/qcom/lpasscorecc-sc7280.c
diff --git a/drivers/clk/qcom/Kconfig b/drivers/clk/qcom/Kconfig
index 42c874194d1a..7b320214c50a 100644
--- a/drivers/clk/qcom/Kconfig
+++ b/drivers/clk/qcom/Kconfig
@@ -443,6 +443,16 @@ config SC_LPASS_CORECC_7180
Say Y if you want to use LPASS clocks and power domains of the LPASS
core clock controller.
+config SC_LPASS_CORECC_7280
+ tristate "SC7280 LPASS Core & Audio Clock Controller"
+ select SC_GCC_7280
+ select QCOM_GDSC
+ help
+ Support for the LPASS(Low Power Audio Subsystem) core and audio clock
+ controller on SC7280 devices.
+ Say Y if you want to use LPASS clocks and power domains of the LPASS
+ core clock controller.
+
config SC_MSS_7180
tristate "SC7180 Modem Clock Controller"
select SC_GCC_7180
diff --git a/drivers/clk/qcom/Makefile b/drivers/clk/qcom/Makefile
index 0d98ca9be67f..53f26b59e54a 100644
--- a/drivers/clk/qcom/Makefile
+++ b/drivers/clk/qcom/Makefile
@@ -70,6 +70,7 @@ obj-$(CONFIG_SC_GPUCC_7180) += gpucc-sc7180.o
obj-$(CONFIG_SC_GPUCC_7280) += gpucc-sc7280.o
obj-$(CONFIG_SC_LPASSCC_7280) += lpasscc-sc7280.o
obj-$(CONFIG_SC_LPASS_CORECC_7180) += lpasscorecc-sc7180.o
+obj-$(CONFIG_SC_LPASS_CORECC_7280) += lpasscorecc-sc7280.o lpassaudiocc-sc7280.o
obj-$(CONFIG_SC_MSS_7180) += mss-sc7180.o
obj-$(CONFIG_SC_VIDEOCC_7180) += videocc-sc7180.o
obj-$(CONFIG_SC_VIDEOCC_7280) += videocc-sc7280.o
diff --git a/drivers/clk/qcom/lpassaudiocc-sc7280.c b/drivers/clk/qcom/lpassaudiocc-sc7280.c
new file mode 100644
index 000000000000..c97ead75f02a
--- /dev/null
+++ b/drivers/clk/qcom/lpassaudiocc-sc7280.c
@@ -0,0 +1,838 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2021, The Linux Foundation. All rights reserved.
+ */
+
+#include <linux/clk-provider.h>
+#include <linux/err.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of_device.h>
+#include <linux/pm_clock.h>
+#include <linux/pm_runtime.h>
+#include <linux/regmap.h>
+
+#include <dt-bindings/clock/qcom,lpassaudiocc-sc7280.h>
+
+#include "clk-alpha-pll.h"
+#include "clk-branch.h"
+#include "clk-rcg.h"
+#include "clk-regmap.h"
+#include "clk-regmap-divider.h"
+#include "clk-regmap-mux.h"
+#include "common.h"
+#include "gdsc.h"
+
+enum {
+ P_BI_TCXO,
+ P_LPASS_AON_CC_PLL_OUT_EVEN,
+ P_LPASS_AON_CC_PLL_OUT_MAIN,
+ P_LPASS_AON_CC_PLL_OUT_MAIN_CDIV_DIV_CLK_SRC,
+ P_LPASS_AON_CC_PLL_OUT_ODD,
+ P_LPASS_AUDIO_CC_PLL_OUT_AUX,
+ P_LPASS_AUDIO_CC_PLL_OUT_AUX2_DIV_CLK_SRC,
+ P_LPASS_AUDIO_CC_PLL_MAIN_DIV_CLK,
+};
+
+static const struct pll_vco zonda_vco[] = {
+ { 595200000UL, 3600000000UL, 0 },
+};
+
+/* 1128.96MHz configuration */
+static const struct alpha_pll_config lpass_audio_cc_pll_config = {
+ .l = 0x3a,
+ .alpha = 0xcccc,
+ .config_ctl_val = 0x08200920,
+ .config_ctl_hi_val = 0x05002001,
+ .config_ctl_hi1_val = 0x00000000,
+ .user_ctl_val = 0x03000101,
+};
+
+static struct clk_alpha_pll lpass_audio_cc_pll = {
+ .offset = 0x0,
+ .vco_table = zonda_vco,
+ .num_vco = ARRAY_SIZE(zonda_vco),
+ .regs = clk_alpha_pll_regs[CLK_ALPHA_PLL_TYPE_ZONDA],
+ .clkr = {
+ .hw.init = &(const struct clk_init_data){
+ .name = "lpass_audio_cc_pll",
+ .parent_data = &(const struct clk_parent_data){
+ .index = 0,
+ },
+ .num_parents = 1,
+ .ops = &clk_alpha_pll_zonda_ops,
+ },
+ },
+};
+
+static const struct clk_div_table post_div_table_lpass_audio_cc_pll_out_aux2[] = {
+ { 0x1, 2 },
+ { }
+};
+
+static struct clk_alpha_pll_postdiv lpass_audio_cc_pll_out_aux2 = {
+ .offset = 0x0,
+ .post_div_shift = 8,
+ .post_div_table = post_div_table_lpass_audio_cc_pll_out_aux2,
+ .num_post_div = ARRAY_SIZE(post_div_table_lpass_audio_cc_pll_out_aux2),
+ .width = 2,
+ .regs = clk_alpha_pll_regs[CLK_ALPHA_PLL_TYPE_ZONDA],
+ .clkr.hw.init = &(const struct clk_init_data){
+ .name = "lpass_audio_cc_pll_out_aux2",
+ .parent_hws = (const struct clk_hw*[]){
+ &lpass_audio_cc_pll.clkr.hw,
+ },
+ .num_parents = 1,
+ .ops = &clk_alpha_pll_postdiv_zonda_ops,
+ },
+};
+
+static const struct pll_vco lucid_vco[] = {
+ { 249600000, 2000000000, 0 },
+};
+
+/* 614.4 MHz configuration */
+static const struct alpha_pll_config lpass_aon_cc_pll_config = {
+ .l = 0x20,
+ .alpha = 0x0,
+ .config_ctl_val = 0x20485699,
+ .config_ctl_hi_val = 0x00002261,
+ .config_ctl_hi1_val = 0x329A299C,
+ .user_ctl_val = 0x00005100,
+ .user_ctl_hi_val = 0x00000805,
+ .user_ctl_hi1_val = 0x00000000,
+};
+
+static struct clk_alpha_pll lpass_aon_cc_pll = {
+ .offset = 0x0,
+ .vco_table = lucid_vco,
+ .num_vco = ARRAY_SIZE(lucid_vco),
+ .regs = clk_alpha_pll_regs[CLK_ALPHA_PLL_TYPE_LUCID],
+ .clkr = {
+ .hw.init = &(const struct clk_init_data){
+ .name = "lpass_aon_cc_pll",
+ .parent_data = &(const struct clk_parent_data){
+ .index = 0,
+ },
+ .num_parents = 1,
+ .ops = &clk_alpha_pll_lucid_ops,
+ },
+ },
+};
+
+static const struct clk_div_table post_div_table_lpass_aon_cc_pll_out_even[] = {
+ { 0x1, 2 },
+ { }
+};
+
+static struct clk_alpha_pll_postdiv lpass_aon_cc_pll_out_even = {
+ .offset = 0x0,
+ .post_div_shift = 8,
+ .post_div_table = post_div_table_lpass_aon_cc_pll_out_even,
+ .num_post_div = ARRAY_SIZE(post_div_table_lpass_aon_cc_pll_out_even),
+ .width = 4,
+ .regs = clk_alpha_pll_regs[CLK_ALPHA_PLL_TYPE_LUCID],
+ .clkr.hw.init = &(const struct clk_init_data){
+ .name = "lpass_aon_cc_pll_out_even",
+ .parent_hws = (const struct clk_hw*[]){
+ &lpass_aon_cc_pll.clkr.hw,
+ },
+ .num_parents = 1,
+ .ops = &clk_alpha_pll_postdiv_lucid_ops,
+ },
+};
+
+static const struct clk_div_table post_div_table_lpass_aon_cc_pll_out_odd[] = {
+ { 0x5, 5 },
+ { }
+};
+
+static struct clk_alpha_pll_postdiv lpass_aon_cc_pll_out_odd = {
+ .offset = 0x0,
+ .post_div_shift = 12,
+ .post_div_table = post_div_table_lpass_aon_cc_pll_out_odd,
+ .num_post_div = ARRAY_SIZE(post_div_table_lpass_aon_cc_pll_out_odd),
+ .width = 4,
+ .regs = clk_alpha_pll_regs[CLK_ALPHA_PLL_TYPE_LUCID],
+ .clkr.hw.init = &(const struct clk_init_data){
+ .name = "lpass_aon_cc_pll_out_odd",
+ .parent_hws = (const struct clk_hw*[]){
+ &lpass_aon_cc_pll.clkr.hw,
+ },
+ .num_parents = 1,
+ .ops = &clk_alpha_pll_postdiv_lucid_ops,
+ },
+};
+
+static const struct parent_map lpass_audio_cc_parent_map_0[] = {
+ { P_BI_TCXO, 0 },
+ { P_LPASS_AUDIO_CC_PLL_OUT_AUX, 3 },
+ { P_LPASS_AON_CC_PLL_OUT_ODD, 5 },
+ { P_LPASS_AUDIO_CC_PLL_OUT_AUX2_DIV_CLK_SRC, 6 },
+};
+
+static struct clk_regmap_div lpass_audio_cc_pll_out_aux2_div_clk_src;
+static struct clk_regmap_div lpass_audio_cc_pll_out_main_div_clk_src;
+
+static const struct clk_parent_data lpass_audio_cc_parent_data_0[] = {
+ { .index = 0 },
+ { .hw = &lpass_audio_cc_pll.clkr.hw },
+ { .hw = &lpass_aon_cc_pll_out_odd.clkr.hw },
+ { .hw = &lpass_audio_cc_pll_out_aux2_div_clk_src.clkr.hw },
+};
+
+static const struct parent_map lpass_aon_cc_parent_map_0[] = {
+ { P_BI_TCXO, 0 },
+ { P_LPASS_AON_CC_PLL_OUT_EVEN, 4 },
+};
+
+static const struct clk_parent_data lpass_aon_cc_parent_data_0[] = {
+ { .index = 0 },
+ { .hw = &lpass_aon_cc_pll_out_even.clkr.hw },
+};
+
+static const struct parent_map lpass_aon_cc_parent_map_1[] = {
+ { P_BI_TCXO, 0 },
+ { P_LPASS_AON_CC_PLL_OUT_ODD, 1 },
+ { P_LPASS_AUDIO_CC_PLL_MAIN_DIV_CLK, 6 },
+};
+
+static const struct clk_parent_data lpass_aon_cc_parent_data_1[] = {
+ { .index = 0 },
+ { .hw = &lpass_aon_cc_pll_out_odd.clkr.hw },
+ { .hw = &lpass_audio_cc_pll_out_main_div_clk_src.clkr.hw },
+};
+
+static const struct freq_tbl ftbl_lpass_aon_cc_main_rcg_clk_src[] = {
+ F(38400000, P_LPASS_AON_CC_PLL_OUT_EVEN, 8, 0, 0),
+ F(76800000, P_LPASS_AON_CC_PLL_OUT_EVEN, 4, 0, 0),
+ F(153600000, P_LPASS_AON_CC_PLL_OUT_EVEN, 2, 0, 0),
+ { }
+};
+
+static struct clk_rcg2 lpass_aon_cc_main_rcg_clk_src = {
+ .cmd_rcgr = 0x1000,
+ .mnd_width = 0,
+ .hid_width = 5,
+ .parent_map = lpass_aon_cc_parent_map_0,
+ .freq_tbl = ftbl_lpass_aon_cc_main_rcg_clk_src,
+ .clkr.hw.init = &(const struct clk_init_data){
+ .name = "lpass_aon_cc_main_rcg_clk_src",
+ .parent_data = lpass_aon_cc_parent_data_0,
+ .num_parents = ARRAY_SIZE(lpass_aon_cc_parent_data_0),
+ .flags = CLK_OPS_PARENT_ENABLE,
+ .ops = &clk_rcg2_ops,
+ },
+};
+
+static const struct freq_tbl ftbl_lpass_aon_cc_tx_mclk_rcg_clk_src[] = {
+ F(19200000, P_BI_TCXO, 1, 0, 0),
+ F(24576000, P_LPASS_AON_CC_PLL_OUT_ODD, 5, 0, 0),
+ { }
+};
+
+static struct clk_rcg2 lpass_aon_cc_tx_mclk_rcg_clk_src = {
+ .cmd_rcgr = 0x13004,
+ .mnd_width = 0,
+ .hid_width = 5,
+ .parent_map = lpass_aon_cc_parent_map_1,
+ .freq_tbl = ftbl_lpass_aon_cc_tx_mclk_rcg_clk_src,
+ .clkr.hw.init = &(const struct clk_init_data){
+ .name = "lpass_aon_cc_tx_mclk_rcg_clk_src",
+ .parent_data = lpass_aon_cc_parent_data_1,
+ .num_parents = ARRAY_SIZE(lpass_aon_cc_parent_data_1),
+ .ops = &clk_rcg2_ops,
+ },
+};
+
+static struct clk_regmap_div lpass_audio_cc_pll_out_aux2_div_clk_src = {
+ .reg = 0x48,
+ .shift = 0,
+ .width = 4,
+ .clkr.hw.init = &(const struct clk_init_data) {
+ .name = "lpass_audio_cc_pll_out_aux2_div_clk_src",
+ .parent_hws = (const struct clk_hw*[]){
+ &lpass_audio_cc_pll_out_aux2.clkr.hw,
+ },
+ .num_parents = 1,
+ .flags = CLK_SET_RATE_PARENT,
+ .ops = &clk_regmap_div_ro_ops,
+ },
+};
+
+static struct clk_regmap_div lpass_audio_cc_pll_out_main_div_clk_src = {
+ .reg = 0x3c,
+ .shift = 0,
+ .width = 4,
+ .clkr.hw.init = &(const struct clk_init_data) {
+ .name = "lpass_audio_cc_pll_out_main_div_clk_src",
+ .parent_hws = (const struct clk_hw*[]){
+ &lpass_audio_cc_pll.clkr.hw,
+ },
+ .num_parents = 1,
+ .flags = CLK_SET_RATE_PARENT,
+ .ops = &clk_regmap_div_ro_ops,
+ },
+};
+
+static struct clk_regmap_div lpass_aon_cc_cdiv_tx_mclk_div_clk_src = {
+ .reg = 0x13010,
+ .shift = 0,
+ .width = 4,
+ .clkr.hw.init = &(const struct clk_init_data) {
+ .name = "lpass_aon_cc_cdiv_tx_mclk_div_clk_src",
+ .parent_hws = (const struct clk_hw*[]){
+ &lpass_aon_cc_tx_mclk_rcg_clk_src.clkr.hw,
+ },
+ .num_parents = 1,
+ .flags = CLK_SET_RATE_PARENT,
+ .ops = &clk_regmap_div_ro_ops,
+ },
+};
+
+static struct clk_regmap_div lpass_aon_cc_pll_out_main_cdiv_div_clk_src = {
+ .reg = 0x80,
+ .shift = 0,
+ .width = 4,
+ .clkr.hw.init = &(const struct clk_init_data) {
+ .name = "lpass_aon_cc_pll_out_main_cdiv_div_clk_src",
+ .parent_hws = (const struct clk_hw*[]){
+ &lpass_aon_cc_pll.clkr.hw,
+ },
+ .num_parents = 1,
+ .flags = CLK_SET_RATE_PARENT,
+ .ops = &clk_regmap_div_ro_ops,
+ },
+};
+
+static const struct freq_tbl ftbl_lpass_audio_cc_ext_mclk0_clk_src[] = {
+ F(256000, P_LPASS_AON_CC_PLL_OUT_ODD, 15, 1, 32),
+ F(352800, P_LPASS_AUDIO_CC_PLL_OUT_AUX2_DIV_CLK_SRC, 10, 1, 32),
+ F(512000, P_LPASS_AON_CC_PLL_OUT_ODD, 15, 1, 16),
+ F(705600, P_LPASS_AUDIO_CC_PLL_OUT_AUX2_DIV_CLK_SRC, 10, 1, 16),
+ F(768000, P_LPASS_AON_CC_PLL_OUT_ODD, 10, 1, 16),
+ F(1024000, P_LPASS_AON_CC_PLL_OUT_ODD, 15, 1, 8),
+ F(1411200, P_LPASS_AUDIO_CC_PLL_OUT_AUX2_DIV_CLK_SRC, 10, 1, 8),
+ F(1536000, P_LPASS_AON_CC_PLL_OUT_ODD, 10, 1, 8),
+ F(2048000, P_LPASS_AON_CC_PLL_OUT_ODD, 15, 1, 4),
+ F(2822400, P_LPASS_AUDIO_CC_PLL_OUT_AUX2_DIV_CLK_SRC, 10, 1, 4),
+ F(3072000, P_LPASS_AON_CC_PLL_OUT_ODD, 10, 1, 4),
+ F(4096000, P_LPASS_AON_CC_PLL_OUT_ODD, 15, 1, 2),
+ F(5644800, P_LPASS_AUDIO_CC_PLL_OUT_AUX2_DIV_CLK_SRC, 10, 1, 2),
+ F(6144000, P_LPASS_AON_CC_PLL_OUT_ODD, 10, 1, 2),
+ F(8192000, P_LPASS_AON_CC_PLL_OUT_ODD, 15, 0, 0),
+ F(9600000, P_BI_TCXO, 2, 0, 0),
+ F(11289600, P_LPASS_AUDIO_CC_PLL_OUT_AUX2_DIV_CLK_SRC, 10, 0, 0),
+ F(12288000, P_LPASS_AON_CC_PLL_OUT_ODD, 10, 0, 0),
+ F(19200000, P_BI_TCXO, 1, 0, 0),
+ F(22579200, P_LPASS_AUDIO_CC_PLL_OUT_AUX2_DIV_CLK_SRC, 5, 0, 0),
+ F(24576000, P_LPASS_AON_CC_PLL_OUT_ODD, 5, 0, 0),
+ { }
+};
+
+static struct clk_rcg2 lpass_audio_cc_ext_mclk0_clk_src = {
+ .cmd_rcgr = 0x20004,
+ .mnd_width = 8,
+ .hid_width = 5,
+ .parent_map = lpass_audio_cc_parent_map_0,
+ .freq_tbl = ftbl_lpass_audio_cc_ext_mclk0_clk_src,
+ .clkr.hw.init = &(const struct clk_init_data){
+ .name = "lpass_audio_cc_ext_mclk0_clk_src",
+ .parent_data = lpass_audio_cc_parent_data_0,
+ .num_parents = ARRAY_SIZE(lpass_audio_cc_parent_data_0),
+ .ops = &clk_rcg2_ops,
+ },
+};
+
+static struct clk_rcg2 lpass_audio_cc_ext_mclk1_clk_src = {
+ .cmd_rcgr = 0x21004,
+ .mnd_width = 8,
+ .hid_width = 5,
+ .parent_map = lpass_audio_cc_parent_map_0,
+ .freq_tbl = ftbl_lpass_audio_cc_ext_mclk0_clk_src,
+ .clkr.hw.init = &(const struct clk_init_data){
+ .name = "lpass_audio_cc_ext_mclk1_clk_src",
+ .parent_data = lpass_audio_cc_parent_data_0,
+ .num_parents = ARRAY_SIZE(lpass_audio_cc_parent_data_0),
+ .ops = &clk_rcg2_ops,
+ },
+};
+
+static struct clk_rcg2 lpass_audio_cc_rx_mclk_clk_src = {
+ .cmd_rcgr = 0x24004,
+ .mnd_width = 8,
+ .hid_width = 5,
+ .parent_map = lpass_audio_cc_parent_map_0,
+ .freq_tbl = ftbl_lpass_audio_cc_ext_mclk0_clk_src,
+ .clkr.hw.init = &(const struct clk_init_data){
+ .name = "lpass_audio_cc_rx_mclk_clk_src",
+ .parent_data = lpass_audio_cc_parent_data_0,
+ .num_parents = ARRAY_SIZE(lpass_audio_cc_parent_data_0),
+ .ops = &clk_rcg2_ops,
+ },
+};
+
+static struct clk_regmap_div lpass_audio_cc_cdiv_rx_mclk_div_clk_src = {
+ .reg = 0x240d0,
+ .shift = 0,
+ .width = 4,
+ .clkr.hw.init = &(const struct clk_init_data) {
+ .name = "lpass_audio_cc_cdiv_rx_mclk_div_clk_src",
+ .parent_hws = (const struct clk_hw*[]){
+ &lpass_audio_cc_rx_mclk_clk_src.clkr.hw,
+ },
+ .num_parents = 1,
+ .flags = CLK_SET_RATE_PARENT,
+ .ops = &clk_regmap_div_ro_ops,
+ },
+};
+
+static struct clk_branch lpass_aon_cc_audio_hm_h_clk;
+
+static struct clk_branch lpass_audio_cc_codec_mem0_clk = {
+ .halt_reg = 0x1e004,
+ .halt_check = BRANCH_HALT,
+ .clkr = {
+ .enable_reg = 0x1e004,
+ .enable_mask = BIT(0),
+ .hw.init = &(const struct clk_init_data){
+ .name = "lpass_audio_cc_codec_mem0_clk",
+ .parent_hws = (const struct clk_hw*[]){
+ &lpass_aon_cc_audio_hm_h_clk.clkr.hw,
+ },
+ .num_parents = 1,
+ .flags = CLK_SET_RATE_PARENT,
+ .ops = &clk_branch2_ops,
+ },
+ },
+};
+
+static struct clk_branch lpass_audio_cc_codec_mem1_clk = {
+ .halt_reg = 0x1e008,
+ .halt_check = BRANCH_HALT,
+ .clkr = {
+ .enable_reg = 0x1e008,
+ .enable_mask = BIT(0),
+ .hw.init = &(const struct clk_init_data){
+ .name = "lpass_audio_cc_codec_mem1_clk",
+ .parent_hws = (const struct clk_hw*[]){
+ &lpass_aon_cc_audio_hm_h_clk.clkr.hw,
+ },
+ .num_parents = 1,
+ .flags = CLK_SET_RATE_PARENT,
+ .ops = &clk_branch2_ops,
+ },
+ },
+};
+
+static struct clk_branch lpass_audio_cc_codec_mem2_clk = {
+ .halt_reg = 0x1e00c,
+ .halt_check = BRANCH_HALT,
+ .clkr = {
+ .enable_reg = 0x1e00c,
+ .enable_mask = BIT(0),
+ .hw.init = &(const struct clk_init_data){
+ .name = "lpass_audio_cc_codec_mem2_clk",
+ .parent_hws = (const struct clk_hw*[]){
+ &lpass_aon_cc_audio_hm_h_clk.clkr.hw,
+ },
+ .num_parents = 1,
+ .flags = CLK_SET_RATE_PARENT,
+ .ops = &clk_branch2_ops,
+ },
+ },
+};
+
+static struct clk_branch lpass_audio_cc_codec_mem_clk = {
+ .halt_reg = 0x1e000,
+ .halt_check = BRANCH_HALT,
+ .clkr = {
+ .enable_reg = 0x1e000,
+ .enable_mask = BIT(0),
+ .hw.init = &(const struct clk_init_data){
+ .name = "lpass_audio_cc_codec_mem_clk",
+ .parent_hws = (const struct clk_hw*[]){
+ &lpass_aon_cc_audio_hm_h_clk.clkr.hw,
+ },
+ .num_parents = 1,
+ .flags = CLK_SET_RATE_PARENT,
+ .ops = &clk_branch2_ops,
+ },
+ },
+};
+
+static struct clk_branch lpass_audio_cc_ext_mclk0_clk = {
+ .halt_reg = 0x20018,
+ .halt_check = BRANCH_HALT,
+ .clkr = {
+ .enable_reg = 0x20018,
+ .enable_mask = BIT(0),
+ .hw.init = &(const struct clk_init_data){
+ .name = "lpass_audio_cc_ext_mclk0_clk",
+ .parent_hws = (const struct clk_hw*[]){
+ &lpass_audio_cc_ext_mclk0_clk_src.clkr.hw,
+ },
+ .num_parents = 1,
+ .flags = CLK_SET_RATE_PARENT,
+ .ops = &clk_branch2_ops,
+ },
+ },
+};
+
+static struct clk_branch lpass_audio_cc_ext_mclk1_clk = {
+ .halt_reg = 0x21018,
+ .halt_check = BRANCH_HALT,
+ .clkr = {
+ .enable_reg = 0x21018,
+ .enable_mask = BIT(0),
+ .hw.init = &(const struct clk_init_data){
+ .name = "lpass_audio_cc_ext_mclk1_clk",
+ .parent_hws = (const struct clk_hw*[]){
+ &lpass_audio_cc_ext_mclk1_clk_src.clkr.hw,
+ },
+ .num_parents = 1,
+ .flags = CLK_SET_RATE_PARENT,
+ .ops = &clk_branch2_ops,
+ },
+ },
+};
+
+static struct clk_branch lpass_audio_cc_rx_mclk_2x_clk = {
+ .halt_reg = 0x240cc,
+ .halt_check = BRANCH_HALT,
+ .clkr = {
+ .enable_reg = 0x240cc,
+ .enable_mask = BIT(0),
+ .hw.init = &(const struct clk_init_data){
+ .name = "lpass_audio_cc_rx_mclk_2x_clk",
+ .parent_hws = (const struct clk_hw*[]){
+ &lpass_audio_cc_rx_mclk_clk_src.clkr.hw,
+ },
+ .num_parents = 1,
+ .flags = CLK_SET_RATE_PARENT,
+ .ops = &clk_branch2_ops,
+ },
+ },
+};
+
+static struct clk_branch lpass_audio_cc_rx_mclk_clk = {
+ .halt_reg = 0x240d4,
+ .halt_check = BRANCH_HALT,
+ .clkr = {
+ .enable_reg = 0x240d4,
+ .enable_mask = BIT(0),
+ .hw.init = &(const struct clk_init_data){
+ .name = "lpass_audio_cc_rx_mclk_clk",
+ .parent_hws = (const struct clk_hw*[]){
+ &lpass_audio_cc_cdiv_rx_mclk_div_clk_src.clkr.hw,
+ },
+ .num_parents = 1,
+ .flags = CLK_SET_RATE_PARENT,
+ .ops = &clk_branch2_ops,
+ },
+ },
+};
+
+static struct clk_branch lpass_aon_cc_audio_hm_h_clk = {
+ .halt_reg = 0x9014,
+ .halt_check = BRANCH_HALT,
+ .clkr = {
+ .enable_reg = 0x9014,
+ .enable_mask = BIT(0),
+ .hw.init = &(const struct clk_init_data){
+ .name = "lpass_aon_cc_audio_hm_h_clk",
+ .parent_hws = (const struct clk_hw*[]){
+ &lpass_aon_cc_main_rcg_clk_src.clkr.hw,
+ },
+ .num_parents = 1,
+ .flags = CLK_SET_RATE_PARENT,
+ .ops = &clk_branch2_aon_ops,
+ },
+ },
+};
+
+static struct clk_branch lpass_aon_cc_va_mem0_clk = {
+ .halt_reg = 0x9028,
+ .halt_check = BRANCH_HALT,
+ .clkr = {
+ .enable_reg = 0x9028,
+ .enable_mask = BIT(0),
+ .hw.init = &(const struct clk_init_data){
+ .name = "lpass_aon_cc_va_mem0_clk",
+ .parent_hws = (const struct clk_hw*[]){
+ &lpass_aon_cc_main_rcg_clk_src.clkr.hw,
+ },
+ .num_parents = 1,
+ .flags = CLK_SET_RATE_PARENT,
+ .ops = &clk_branch2_ops,
+ },
+ },
+};
+
+static struct clk_branch lpass_aon_cc_tx_mclk_2x_clk = {
+ .halt_reg = 0x1300c,
+ .halt_check = BRANCH_HALT,
+ .clkr = {
+ .enable_reg = 0x1300c,
+ .enable_mask = BIT(0),
+ .hw.init = &(const struct clk_init_data){
+ .name = "lpass_aon_cc_tx_mclk_2x_clk",
+ .parent_hws = (const struct clk_hw*[]){
+ &lpass_aon_cc_tx_mclk_rcg_clk_src.clkr.hw,
+ },
+ .num_parents = 1,
+ .flags = CLK_SET_RATE_PARENT,
+ .ops = &clk_branch2_ops,
+ },
+ },
+};
+
+static struct clk_branch lpass_aon_cc_tx_mclk_clk = {
+ .halt_reg = 0x13014,
+ .halt_check = BRANCH_HALT,
+ .clkr = {
+ .enable_reg = 0x13014,
+ .enable_mask = BIT(0),
+ .hw.init = &(const struct clk_init_data){
+ .name = "lpass_aon_cc_tx_mclk_clk",
+ .parent_hws = (const struct clk_hw*[]){
+ &lpass_aon_cc_cdiv_tx_mclk_div_clk_src.clkr.hw,
+ },
+ .num_parents = 1,
+ .flags = CLK_SET_RATE_PARENT,
+ .ops = &clk_branch2_ops,
+ },
+ },
+};
+
+static struct gdsc lpass_aon_cc_lpass_audio_hm_gdsc = {
+ .gdscr = 0x9090,
+ .pd = {
+ .name = "lpass_aon_cc_lpass_audio_hm_gdsc",
+ },
+ .pwrsts = PWRSTS_OFF_ON,
+ .flags = RETAIN_FF_ENABLE,
+};
+
+static struct clk_regmap *lpass_aon_cc_sc7280_clocks[] = {
+ [LPASS_AON_CC_AUDIO_HM_H_CLK] = &lpass_aon_cc_audio_hm_h_clk.clkr,
+ [LPASS_AON_CC_VA_MEM0_CLK] = &lpass_aon_cc_va_mem0_clk.clkr,
+ [LPASS_AON_CC_CDIV_TX_MCLK_DIV_CLK_SRC] = &lpass_aon_cc_cdiv_tx_mclk_div_clk_src.clkr,
+ [LPASS_AON_CC_MAIN_RCG_CLK_SRC] = &lpass_aon_cc_main_rcg_clk_src.clkr,
+ [LPASS_AON_CC_PLL] = &lpass_aon_cc_pll.clkr,
+ [LPASS_AON_CC_PLL_OUT_EVEN] = &lpass_aon_cc_pll_out_even.clkr,
+ [LPASS_AON_CC_PLL_OUT_MAIN_CDIV_DIV_CLK_SRC] =
+ &lpass_aon_cc_pll_out_main_cdiv_div_clk_src.clkr,
+ [LPASS_AON_CC_PLL_OUT_ODD] = &lpass_aon_cc_pll_out_odd.clkr,
+ [LPASS_AON_CC_TX_MCLK_2X_CLK] = &lpass_aon_cc_tx_mclk_2x_clk.clkr,
+ [LPASS_AON_CC_TX_MCLK_CLK] = &lpass_aon_cc_tx_mclk_clk.clkr,
+ [LPASS_AON_CC_TX_MCLK_RCG_CLK_SRC] = &lpass_aon_cc_tx_mclk_rcg_clk_src.clkr,
+};
+
+static struct gdsc *lpass_aon_cc_sc7280_gdscs[] = {
+ [LPASS_AON_CC_LPASS_AUDIO_HM_GDSC] = &lpass_aon_cc_lpass_audio_hm_gdsc,
+};
+
+static struct clk_regmap *lpass_audio_cc_sc7280_clocks[] = {
+ [LPASS_AUDIO_CC_CDIV_RX_MCLK_DIV_CLK_SRC] = &lpass_audio_cc_cdiv_rx_mclk_div_clk_src.clkr,
+ [LPASS_AUDIO_CC_CODEC_MEM0_CLK] = &lpass_audio_cc_codec_mem0_clk.clkr,
+ [LPASS_AUDIO_CC_CODEC_MEM1_CLK] = &lpass_audio_cc_codec_mem1_clk.clkr,
+ [LPASS_AUDIO_CC_CODEC_MEM2_CLK] = &lpass_audio_cc_codec_mem2_clk.clkr,
+ [LPASS_AUDIO_CC_CODEC_MEM_CLK] = &lpass_audio_cc_codec_mem_clk.clkr,
+ [LPASS_AUDIO_CC_EXT_MCLK0_CLK] = &lpass_audio_cc_ext_mclk0_clk.clkr,
+ [LPASS_AUDIO_CC_EXT_MCLK0_CLK_SRC] = &lpass_audio_cc_ext_mclk0_clk_src.clkr,
+ [LPASS_AUDIO_CC_EXT_MCLK1_CLK] = &lpass_audio_cc_ext_mclk1_clk.clkr,
+ [LPASS_AUDIO_CC_EXT_MCLK1_CLK_SRC] = &lpass_audio_cc_ext_mclk1_clk_src.clkr,
+ [LPASS_AUDIO_CC_PLL] = &lpass_audio_cc_pll.clkr,
+ [LPASS_AUDIO_CC_PLL_OUT_AUX2] = &lpass_audio_cc_pll_out_aux2.clkr,
+ [LPASS_AUDIO_CC_PLL_OUT_AUX2_DIV_CLK_SRC] = &lpass_audio_cc_pll_out_aux2_div_clk_src.clkr,
+ [LPASS_AUDIO_CC_PLL_OUT_MAIN_DIV_CLK_SRC] = &lpass_audio_cc_pll_out_main_div_clk_src.clkr,
+ [LPASS_AUDIO_CC_RX_MCLK_2X_CLK] = &lpass_audio_cc_rx_mclk_2x_clk.clkr,
+ [LPASS_AUDIO_CC_RX_MCLK_CLK] = &lpass_audio_cc_rx_mclk_clk.clkr,
+ [LPASS_AUDIO_CC_RX_MCLK_CLK_SRC] = &lpass_audio_cc_rx_mclk_clk_src.clkr,
+};
+
+static struct regmap_config lpass_audio_cc_sc7280_regmap_config = {
+ .reg_bits = 32,
+ .reg_stride = 4,
+ .val_bits = 32,
+ .fast_io = true,
+};
+
+static const struct qcom_cc_desc lpass_audio_cc_sc7280_desc = {
+ .config = &lpass_audio_cc_sc7280_regmap_config,
+ .clks = lpass_audio_cc_sc7280_clocks,
+ .num_clks = ARRAY_SIZE(lpass_audio_cc_sc7280_clocks),
+};
+
+static const struct of_device_id lpass_audio_cc_sc7280_match_table[] = {
+ { .compatible = "qcom,sc7280-lpassaudiocc" },
+ { }
+};
+MODULE_DEVICE_TABLE(of, lpass_audio_cc_sc7280_match_table);
+
+static void lpassaudio_pm_runtime_disable(void *data)
+{
+ pm_runtime_disable(data);
+}
+
+static void lpassaudio_pm_clk_destroy(void *data)
+{
+ pm_clk_destroy(data);
+}
+
+static int lpassaudio_create_pm_clks(struct platform_device *pdev)
+{
+ int ret;
+
+ pm_runtime_use_autosuspend(&pdev->dev);
+ pm_runtime_set_autosuspend_delay(&pdev->dev, 50);
+ pm_runtime_enable(&pdev->dev);
+
+ ret = devm_add_action_or_reset(&pdev->dev, lpassaudio_pm_runtime_disable, &pdev->dev);
+ if (ret)
+ return ret;
+
+ ret = pm_clk_create(&pdev->dev);
+ if (ret)
+ return ret;
+
+ ret = devm_add_action_or_reset(&pdev->dev, lpassaudio_pm_clk_destroy, &pdev->dev);
+ if (ret)
+ return ret;
+
+ ret = pm_clk_add(&pdev->dev, "iface");
+ if (ret < 0)
+ dev_err(&pdev->dev, "failed to acquire iface clock\n");
+
+ return ret;
+}
+
+static int lpass_audio_cc_sc7280_probe(struct platform_device *pdev)
+{
+ const struct qcom_cc_desc *desc;
+ struct regmap *regmap;
+ int ret;
+
+ ret = lpassaudio_create_pm_clks(pdev);
+ if (ret)
+ return ret;
+
+ lpass_audio_cc_sc7280_regmap_config.name = "lpassaudio_cc";
+ lpass_audio_cc_sc7280_regmap_config.max_register = 0x2f000;
+ desc = &lpass_audio_cc_sc7280_desc;
+
+ regmap = qcom_cc_map(pdev, desc);
+ if (IS_ERR(regmap)) {
+ pm_runtime_disable(&pdev->dev);
+ return PTR_ERR(regmap);
+ }
+
+ clk_zonda_pll_configure(&lpass_audio_cc_pll, regmap, &lpass_audio_cc_pll_config);
+
+ ret = qcom_cc_really_probe(pdev, &lpass_audio_cc_sc7280_desc, regmap);
+ if (ret) {
+ dev_err(&pdev->dev, "Failed to register LPASS AUDIO CC clocks\n");
+ pm_runtime_disable(&pdev->dev);
+ return ret;
+ }
+
+ /* PLL settings */
+ regmap_write(regmap, 0x4, 0x3b);
+ regmap_write(regmap, 0x8, 0xff05);
+
+ pm_runtime_mark_last_busy(&pdev->dev);
+ pm_runtime_put_autosuspend(&pdev->dev);
+ pm_runtime_put_sync(&pdev->dev);
+
+ return ret;
+}
+
+static const struct dev_pm_ops lpass_audio_cc_pm_ops = {
+ SET_RUNTIME_PM_OPS(pm_clk_suspend, pm_clk_resume, NULL)
+};
+
+static struct platform_driver lpass_audio_cc_sc7280_driver = {
+ .probe = lpass_audio_cc_sc7280_probe,
+ .driver = {
+ .name = "lpass_audio_cc-sc7280",
+ .of_match_table = lpass_audio_cc_sc7280_match_table,
+ .pm = &lpass_audio_cc_pm_ops,
+ },
+};
+
+static const struct qcom_cc_desc lpass_aon_cc_sc7280_desc = {
+ .config = &lpass_audio_cc_sc7280_regmap_config,
+ .clks = lpass_aon_cc_sc7280_clocks,
+ .num_clks = ARRAY_SIZE(lpass_aon_cc_sc7280_clocks),
+ .gdscs = lpass_aon_cc_sc7280_gdscs,
+ .num_gdscs = ARRAY_SIZE(lpass_aon_cc_sc7280_gdscs),
+};
+
+static const struct of_device_id lpass_aon_cc_sc7280_match_table[] = {
+ { .compatible = "qcom,sc7280-lpassaoncc" },
+ { }
+};
+MODULE_DEVICE_TABLE(of, lpass_aon_cc_sc7280_match_table);
+
+static int lpass_aon_cc_sc7280_probe(struct platform_device *pdev)
+{
+ const struct qcom_cc_desc *desc;
+ struct regmap *regmap;
+ int ret;
+
+ ret = lpassaudio_create_pm_clks(pdev);
+ if (ret)
+ return ret;
+
+ lpass_audio_cc_sc7280_regmap_config.name = "lpasscc_aon";
+ lpass_audio_cc_sc7280_regmap_config.max_register = 0xa0008;
+ desc = &lpass_aon_cc_sc7280_desc;
+
+ regmap = qcom_cc_map(pdev, desc);
+ if (IS_ERR(regmap))
+ return PTR_ERR(regmap);
+
+ clk_lucid_pll_configure(&lpass_aon_cc_pll, regmap, &lpass_aon_cc_pll_config);
+
+ ret = qcom_cc_really_probe(pdev, &lpass_aon_cc_sc7280_desc, regmap);
+ if (ret)
+ dev_err(&pdev->dev, "Failed to register LPASS AON CC clocks\n");
+
+ pm_runtime_mark_last_busy(&pdev->dev);
+ pm_runtime_put_autosuspend(&pdev->dev);
+ pm_runtime_put_sync(&pdev->dev);
+
+ return ret;
+}
+
+static struct platform_driver lpass_aon_cc_sc7280_driver = {
+ .probe = lpass_aon_cc_sc7280_probe,
+ .driver = {
+ .name = "lpass_aon_cc-sc7280",
+ .of_match_table = lpass_aon_cc_sc7280_match_table,
+ .pm = &lpass_audio_cc_pm_ops,
+ },
+};
+
+static int __init lpass_audio_cc_sc7280_init(void)
+{
+ int ret;
+
+ ret = platform_driver_register(&lpass_aon_cc_sc7280_driver);
+ if (ret)
+ return ret;
+
+ return platform_driver_register(&lpass_audio_cc_sc7280_driver);
+}
+subsys_initcall(lpass_audio_cc_sc7280_init);
+
+static void __exit lpass_audio_cc_sc7280_exit(void)
+{
+ platform_driver_unregister(&lpass_audio_cc_sc7280_driver);
+ platform_driver_unregister(&lpass_aon_cc_sc7280_driver);
+}
+module_exit(lpass_audio_cc_sc7280_exit);
+
+MODULE_DESCRIPTION("QTI LPASS_AUDIO_CC SC7280 Driver");
+MODULE_LICENSE("GPL v2");
diff --git a/drivers/clk/qcom/lpasscorecc-sc7280.c b/drivers/clk/qcom/lpasscorecc-sc7280.c
new file mode 100644
index 000000000000..1f1f1bd1b68e
--- /dev/null
+++ b/drivers/clk/qcom/lpasscorecc-sc7280.c
@@ -0,0 +1,431 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2021, The Linux Foundation. All rights reserved.
+ */
+
+#include <linux/clk-provider.h>
+#include <linux/err.h>
+#include <linux/module.h>
+#include <linux/of_device.h>
+#include <linux/pm_clock.h>
+#include <linux/pm_runtime.h>
+#include <linux/regmap.h>
+
+#include <dt-bindings/clock/qcom,lpasscorecc-sc7280.h>
+
+#include "clk-alpha-pll.h"
+#include "clk-branch.h"
+#include "clk-rcg.h"
+#include "clk-regmap.h"
+#include "clk-regmap-divider.h"
+#include "common.h"
+#include "gdsc.h"
+
+enum {
+ P_BI_TCXO,
+ P_LPASS_CORE_CC_DIG_PLL_OUT_MAIN,
+ P_LPASS_CORE_CC_DIG_PLL_OUT_MAIN_DIV_CLK_SRC,
+ P_LPASS_CORE_CC_DIG_PLL_OUT_ODD,
+};
+
+static const struct pll_vco lucid_vco[] = {
+ { 249600000, 2000000000, 0 },
+};
+
+/* 614.4MHz configuration */
+static const struct alpha_pll_config lpass_core_cc_dig_pll_config = {
+ .l = 0x20,
+ .alpha = 0x0,
+ .config_ctl_val = 0x20485699,
+ .config_ctl_hi_val = 0x00002261,
+ .config_ctl_hi1_val = 0xB2923BBC,
+ .user_ctl_val = 0x00005100,
+ .user_ctl_hi_val = 0x00050805,
+ .user_ctl_hi1_val = 0x00000000,
+};
+
+static struct clk_alpha_pll lpass_core_cc_dig_pll = {
+ .offset = 0x1000,
+ .vco_table = lucid_vco,
+ .num_vco = ARRAY_SIZE(lucid_vco),
+ .regs = clk_alpha_pll_regs[CLK_ALPHA_PLL_TYPE_LUCID],
+ .clkr = {
+ .hw.init = &(struct clk_init_data){
+ .name = "lpass_core_cc_dig_pll",
+ .parent_data = &(const struct clk_parent_data){
+ .index = 0,
+ },
+ .num_parents = 1,
+ .ops = &clk_alpha_pll_lucid_ops,
+ },
+ },
+};
+
+static const struct clk_div_table post_div_table_lpass_core_cc_dig_pll_out_odd[] = {
+ { 0x5, 5 },
+ { }
+};
+
+static struct clk_alpha_pll_postdiv lpass_core_cc_dig_pll_out_odd = {
+ .offset = 0x1000,
+ .post_div_shift = 12,
+ .post_div_table = post_div_table_lpass_core_cc_dig_pll_out_odd,
+ .num_post_div = ARRAY_SIZE(post_div_table_lpass_core_cc_dig_pll_out_odd),
+ .width = 4,
+ .regs = clk_alpha_pll_regs[CLK_ALPHA_PLL_TYPE_LUCID],
+ .clkr.hw.init = &(struct clk_init_data){
+ .name = "lpass_core_cc_dig_pll_out_odd",
+ .parent_hws = (const struct clk_hw*[]){
+ &lpass_core_cc_dig_pll.clkr.hw,
+ },
+ .num_parents = 1,
+ .flags = CLK_SET_RATE_PARENT,
+ .ops = &clk_alpha_pll_postdiv_lucid_ops,
+ },
+};
+
+static struct clk_regmap_div lpass_core_cc_dig_pll_out_main_div_clk_src = {
+ .reg = 0x1054,
+ .shift = 0,
+ .width = 4,
+ .clkr.hw.init = &(struct clk_init_data) {
+ .name = "lpass_core_cc_dig_pll_out_main_div_clk_src",
+ .parent_hws = (const struct clk_hw*[]){
+ &lpass_core_cc_dig_pll.clkr.hw,
+ },
+ .num_parents = 1,
+ .flags = CLK_SET_RATE_PARENT,
+ .ops = &clk_regmap_div_ro_ops,
+ },
+};
+
+
+static const struct parent_map lpass_core_cc_parent_map_0[] = {
+ { P_BI_TCXO, 0 },
+ { P_LPASS_CORE_CC_DIG_PLL_OUT_ODD, 5 },
+};
+
+static const struct clk_parent_data lpass_core_cc_parent_data_0[] = {
+ { .index = 0 },
+ { .hw = &lpass_core_cc_dig_pll_out_odd.clkr.hw },
+};
+
+static const struct parent_map lpass_core_cc_parent_map_2[] = {
+ { P_BI_TCXO, 0 },
+ { P_LPASS_CORE_CC_DIG_PLL_OUT_MAIN, 1 },
+ { P_LPASS_CORE_CC_DIG_PLL_OUT_MAIN_DIV_CLK_SRC, 2 },
+};
+
+static const struct clk_parent_data lpass_core_cc_parent_data_ao_2[] = {
+ { .index = 1 },
+ { .hw = &lpass_core_cc_dig_pll.clkr.hw },
+ { .hw = &lpass_core_cc_dig_pll_out_main_div_clk_src.clkr.hw },
+};
+
+static const struct freq_tbl ftbl_lpass_core_cc_core_clk_src[] = {
+ F(19200000, P_BI_TCXO, 1, 0, 0),
+ F(51200000, P_LPASS_CORE_CC_DIG_PLL_OUT_MAIN_DIV_CLK_SRC, 6, 0, 0),
+ F(102400000, P_LPASS_CORE_CC_DIG_PLL_OUT_MAIN_DIV_CLK_SRC, 3, 0, 0),
+ F(204800000, P_LPASS_CORE_CC_DIG_PLL_OUT_MAIN, 3, 0, 0),
+ { }
+};
+
+static struct clk_rcg2 lpass_core_cc_core_clk_src = {
+ .cmd_rcgr = 0x1d000,
+ .mnd_width = 8,
+ .hid_width = 5,
+ .parent_map = lpass_core_cc_parent_map_2,
+ .freq_tbl = ftbl_lpass_core_cc_core_clk_src,
+ .clkr.hw.init = &(const struct clk_init_data){
+ .name = "lpass_core_cc_core_clk_src",
+ .parent_data = lpass_core_cc_parent_data_ao_2,
+ .num_parents = ARRAY_SIZE(lpass_core_cc_parent_data_ao_2),
+ .ops = &clk_rcg2_shared_ops,
+ },
+};
+
+static const struct freq_tbl ftbl_lpass_core_cc_ext_if0_clk_src[] = {
+ F(256000, P_LPASS_CORE_CC_DIG_PLL_OUT_ODD, 15, 1, 32),
+ F(512000, P_LPASS_CORE_CC_DIG_PLL_OUT_ODD, 15, 1, 16),
+ F(768000, P_LPASS_CORE_CC_DIG_PLL_OUT_ODD, 10, 1, 16),
+ F(1024000, P_LPASS_CORE_CC_DIG_PLL_OUT_ODD, 15, 1, 8),
+ F(1536000, P_LPASS_CORE_CC_DIG_PLL_OUT_ODD, 10, 1, 8),
+ F(2048000, P_LPASS_CORE_CC_DIG_PLL_OUT_ODD, 15, 1, 4),
+ F(3072000, P_LPASS_CORE_CC_DIG_PLL_OUT_ODD, 10, 1, 4),
+ F(4096000, P_LPASS_CORE_CC_DIG_PLL_OUT_ODD, 15, 1, 2),
+ F(6144000, P_LPASS_CORE_CC_DIG_PLL_OUT_ODD, 10, 1, 2),
+ F(8192000, P_LPASS_CORE_CC_DIG_PLL_OUT_ODD, 15, 0, 0),
+ F(9600000, P_BI_TCXO, 2, 0, 0),
+ F(12288000, P_LPASS_CORE_CC_DIG_PLL_OUT_ODD, 10, 0, 0),
+ F(19200000, P_BI_TCXO, 1, 0, 0),
+ F(24576000, P_LPASS_CORE_CC_DIG_PLL_OUT_ODD, 5, 0, 0),
+ { }
+};
+
+static struct clk_rcg2 lpass_core_cc_ext_if0_clk_src = {
+ .cmd_rcgr = 0x10000,
+ .mnd_width = 16,
+ .hid_width = 5,
+ .parent_map = lpass_core_cc_parent_map_0,
+ .freq_tbl = ftbl_lpass_core_cc_ext_if0_clk_src,
+ .clkr.hw.init = &(const struct clk_init_data){
+ .name = "lpass_core_cc_ext_if0_clk_src",
+ .parent_data = lpass_core_cc_parent_data_0,
+ .num_parents = ARRAY_SIZE(lpass_core_cc_parent_data_0),
+ .ops = &clk_rcg2_ops,
+ },
+};
+
+static struct clk_rcg2 lpass_core_cc_ext_if1_clk_src = {
+ .cmd_rcgr = 0x11000,
+ .mnd_width = 16,
+ .hid_width = 5,
+ .parent_map = lpass_core_cc_parent_map_0,
+ .freq_tbl = ftbl_lpass_core_cc_ext_if0_clk_src,
+ .clkr.hw.init = &(const struct clk_init_data){
+ .name = "lpass_core_cc_ext_if1_clk_src",
+ .parent_data = lpass_core_cc_parent_data_0,
+ .num_parents = ARRAY_SIZE(lpass_core_cc_parent_data_0),
+ .ops = &clk_rcg2_ops,
+ },
+};
+
+
+static struct clk_branch lpass_core_cc_core_clk = {
+ .halt_reg = 0x1f000,
+ .halt_check = BRANCH_HALT_VOTED,
+ .hwcg_reg = 0x1f000,
+ .hwcg_bit = 1,
+ .clkr = {
+ .enable_reg = 0x1f000,
+ .enable_mask = BIT(0),
+ .hw.init = &(const struct clk_init_data){
+ .name = "lpass_core_cc_core_clk",
+ .parent_hws = (const struct clk_hw*[]){
+ &lpass_core_cc_core_clk_src.clkr.hw,
+ },
+ .num_parents = 1,
+ .flags = CLK_SET_RATE_PARENT,
+ .ops = &clk_branch2_aon_ops,
+ },
+ },
+};
+
+static struct clk_branch lpass_core_cc_ext_if0_ibit_clk = {
+ .halt_reg = 0x10018,
+ .halt_check = BRANCH_HALT,
+ .clkr = {
+ .enable_reg = 0x10018,
+ .enable_mask = BIT(0),
+ .hw.init = &(const struct clk_init_data){
+ .name = "lpass_core_cc_ext_if0_ibit_clk",
+ .parent_hws = (const struct clk_hw*[]){
+ &lpass_core_cc_ext_if0_clk_src.clkr.hw,
+ },
+ .num_parents = 1,
+ .flags = CLK_SET_RATE_PARENT,
+ .ops = &clk_branch2_ops,
+ },
+ },
+};
+
+static struct clk_branch lpass_core_cc_ext_if1_ibit_clk = {
+ .halt_reg = 0x11018,
+ .halt_check = BRANCH_HALT,
+ .clkr = {
+ .enable_reg = 0x11018,
+ .enable_mask = BIT(0),
+ .hw.init = &(const struct clk_init_data){
+ .name = "lpass_core_cc_ext_if1_ibit_clk",
+ .parent_hws = (const struct clk_hw*[]){
+ &lpass_core_cc_ext_if1_clk_src.clkr.hw,
+ },
+ .num_parents = 1,
+ .flags = CLK_SET_RATE_PARENT,
+ .ops = &clk_branch2_ops,
+ },
+ },
+};
+
+static struct clk_branch lpass_core_cc_lpm_core_clk = {
+ .halt_reg = 0x1e000,
+ .halt_check = BRANCH_HALT,
+ .clkr = {
+ .enable_reg = 0x1e000,
+ .enable_mask = BIT(0),
+ .hw.init = &(const struct clk_init_data){
+ .name = "lpass_core_cc_lpm_core_clk",
+ .parent_hws = (const struct clk_hw*[]){
+ &lpass_core_cc_core_clk_src.clkr.hw,
+ },
+ .num_parents = 1,
+ .flags = CLK_SET_RATE_PARENT,
+ .ops = &clk_branch2_ops,
+ },
+ },
+};
+
+static struct clk_branch lpass_core_cc_lpm_mem0_core_clk = {
+ .halt_reg = 0x1e004,
+ .halt_check = BRANCH_HALT,
+ .clkr = {
+ .enable_reg = 0x1e004,
+ .enable_mask = BIT(0),
+ .hw.init = &(const struct clk_init_data){
+ .name = "lpass_core_cc_lpm_mem0_core_clk",
+ .parent_hws = (const struct clk_hw*[]){
+ &lpass_core_cc_core_clk_src.clkr.hw,
+ },
+ .num_parents = 1,
+ .flags = CLK_SET_RATE_PARENT,
+ .ops = &clk_branch2_ops,
+ },
+ },
+};
+
+static struct clk_branch lpass_core_cc_sysnoc_mport_core_clk = {
+ .halt_reg = 0x23000,
+ .halt_check = BRANCH_HALT_VOTED,
+ .hwcg_reg = 0x23000,
+ .hwcg_bit = 1,
+ .clkr = {
+ .enable_reg = 0x23000,
+ .enable_mask = BIT(0),
+ .hw.init = &(const struct clk_init_data){
+ .name = "lpass_core_cc_sysnoc_mport_core_clk",
+ .parent_hws = (const struct clk_hw*[]){
+ &lpass_core_cc_core_clk_src.clkr.hw,
+ },
+ .num_parents = 1,
+ .flags = CLK_SET_RATE_PARENT,
+ .ops = &clk_branch2_ops,
+ },
+ },
+};
+
+static struct gdsc lpass_core_cc_lpass_core_hm_gdsc = {
+ .gdscr = 0x0,
+ .pd = {
+ .name = "lpass_core_cc_lpass_core_hm_gdsc",
+ },
+ .pwrsts = PWRSTS_OFF_ON,
+ .flags = RETAIN_FF_ENABLE,
+};
+
+static struct clk_regmap *lpass_core_cc_sc7280_clocks[] = {
+ [LPASS_CORE_CC_CORE_CLK] = &lpass_core_cc_core_clk.clkr,
+ [LPASS_CORE_CC_CORE_CLK_SRC] = &lpass_core_cc_core_clk_src.clkr,
+ [LPASS_CORE_CC_DIG_PLL] = &lpass_core_cc_dig_pll.clkr,
+ [LPASS_CORE_CC_DIG_PLL_OUT_MAIN_DIV_CLK_SRC] =
+ &lpass_core_cc_dig_pll_out_main_div_clk_src.clkr,
+ [LPASS_CORE_CC_DIG_PLL_OUT_ODD] = &lpass_core_cc_dig_pll_out_odd.clkr,
+ [LPASS_CORE_CC_EXT_IF0_CLK_SRC] = &lpass_core_cc_ext_if0_clk_src.clkr,
+ [LPASS_CORE_CC_EXT_IF0_IBIT_CLK] = &lpass_core_cc_ext_if0_ibit_clk.clkr,
+ [LPASS_CORE_CC_EXT_IF1_CLK_SRC] = &lpass_core_cc_ext_if1_clk_src.clkr,
+ [LPASS_CORE_CC_EXT_IF1_IBIT_CLK] = &lpass_core_cc_ext_if1_ibit_clk.clkr,
+ [LPASS_CORE_CC_LPM_CORE_CLK] = &lpass_core_cc_lpm_core_clk.clkr,
+ [LPASS_CORE_CC_LPM_MEM0_CORE_CLK] = &lpass_core_cc_lpm_mem0_core_clk.clkr,
+ [LPASS_CORE_CC_SYSNOC_MPORT_CORE_CLK] = &lpass_core_cc_sysnoc_mport_core_clk.clkr,
+};
+
+static struct regmap_config lpass_core_cc_sc7280_regmap_config = {
+ .reg_bits = 32,
+ .reg_stride = 4,
+ .val_bits = 32,
+ .fast_io = true,
+};
+
+static const struct qcom_cc_desc lpass_core_cc_sc7280_desc = {
+ .config = &lpass_core_cc_sc7280_regmap_config,
+ .clks = lpass_core_cc_sc7280_clocks,
+ .num_clks = ARRAY_SIZE(lpass_core_cc_sc7280_clocks),
+};
+
+static const struct of_device_id lpass_core_cc_sc7280_match_table[] = {
+ { .compatible = "qcom,sc7280-lpasscorecc" },
+ { }
+};
+MODULE_DEVICE_TABLE(of, lpass_core_cc_sc7280_match_table);
+
+static struct gdsc *lpass_core_hm_sc7280_gdscs[] = {
+ [LPASS_CORE_CC_LPASS_CORE_HM_GDSC] = &lpass_core_cc_lpass_core_hm_gdsc,
+};
+
+static const struct qcom_cc_desc lpass_core_hm_sc7280_desc = {
+ .config = &lpass_core_cc_sc7280_regmap_config,
+ .gdscs = lpass_core_hm_sc7280_gdscs,
+ .num_gdscs = ARRAY_SIZE(lpass_core_hm_sc7280_gdscs),
+};
+
+static int lpass_core_cc_sc7280_probe(struct platform_device *pdev)
+{
+ const struct qcom_cc_desc *desc;
+ struct regmap *regmap;
+
+ lpass_core_cc_sc7280_regmap_config.name = "lpass_core_cc";
+ lpass_core_cc_sc7280_regmap_config.max_register = 0x4f004;
+ desc = &lpass_core_cc_sc7280_desc;
+
+ regmap = qcom_cc_map(pdev, desc);
+ if (IS_ERR(regmap))
+ return PTR_ERR(regmap);
+
+ clk_lucid_pll_configure(&lpass_core_cc_dig_pll, regmap, &lpass_core_cc_dig_pll_config);
+
+ return qcom_cc_really_probe(pdev, &lpass_core_cc_sc7280_desc, regmap);
+}
+
+static struct platform_driver lpass_core_cc_sc7280_driver = {
+ .probe = lpass_core_cc_sc7280_probe,
+ .driver = {
+ .name = "lpass_core_cc-sc7280",
+ .of_match_table = lpass_core_cc_sc7280_match_table,
+ },
+};
+
+static int lpass_hm_core_probe(struct platform_device *pdev)
+{
+ const struct qcom_cc_desc *desc;
+
+ lpass_core_cc_sc7280_regmap_config.name = "lpass_hm_core";
+ lpass_core_cc_sc7280_regmap_config.max_register = 0x24;
+ desc = &lpass_core_hm_sc7280_desc;
+
+ return qcom_cc_probe_by_index(pdev, 0, desc);
+}
+
+static const struct of_device_id lpass_hm_sc7280_match_table[] = {
+ { .compatible = "qcom,sc7280-lpasshm" },
+ { }
+};
+MODULE_DEVICE_TABLE(of, lpass_hm_sc7280_match_table);
+
+static struct platform_driver lpass_hm_sc7280_driver = {
+ .probe = lpass_hm_core_probe,
+ .driver = {
+ .name = "lpass_hm-sc7280",
+ .of_match_table = lpass_hm_sc7280_match_table,
+ },
+};
+
+static int __init lpass_core_cc_sc7280_init(void)
+{
+ int ret;
+
+ ret = platform_driver_register(&lpass_hm_sc7280_driver);
+ if (ret)
+ return ret;
+
+ return platform_driver_register(&lpass_core_cc_sc7280_driver);
+}
+subsys_initcall(lpass_core_cc_sc7280_init);
+
+static void __exit lpass_core_cc_sc7280_exit(void)
+{
+ platform_driver_unregister(&lpass_core_cc_sc7280_driver);
+ platform_driver_unregister(&lpass_hm_sc7280_driver);
+}
+module_exit(lpass_core_cc_sc7280_exit);
+
+MODULE_DESCRIPTION("QTI LPASS_CORE_CC SC7280 Driver");
+MODULE_LICENSE("GPL v2");
--
Qualcomm INDIA, on behalf of Qualcomm Innovation Center, Inc.is a member
of the Code Aurora Forum, hosted by the Linux Foundation.
^ permalink raw reply related
* Re: [PATCH v9 05/24] wfx: add main.c/main.h
From: Jérôme Pouiller @ 2022-01-26 8:20 UTC (permalink / raw)
To: linux-wireless, netdev, Kalle Valo
Cc: devel, linux-kernel, Greg Kroah-Hartman, David S . Miller,
devicetree, Rob Herring, linux-mmc, Pali Rohár, Ulf Hansson
In-Reply-To: <20220111171424.862764-6-Jerome.Pouiller@silabs.com>
Hi Kalle,
On Tuesday 11 January 2022 18:14:05 CET Jerome Pouiller wrote:
> From: Jérôme Pouiller <jerome.pouiller@silabs.com>
>
> Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
> ---
> drivers/net/wireless/silabs/wfx/main.c | 485 +++++++++++++++++++++++++
> drivers/net/wireless/silabs/wfx/main.h | 42 +++
> 2 files changed, 527 insertions(+)
> create mode 100644 drivers/net/wireless/silabs/wfx/main.c
> create mode 100644 drivers/net/wireless/silabs/wfx/main.h
>
[...]
> +/* The device needs data about the antenna configuration. This information in
> + * provided by PDS (Platform Data Set, this is the wording used in WF200
> + * documentation) files. For hardware integrators, the full process to create
> + * PDS files is described here:
> + * https:github.com/SiliconLabs/wfx-firmware/blob/master/PDS/README.md
> + *
> + * The PDS file is an array of Time-Length-Value structs.
> + */
> + int wfx_send_pds(struct wfx_dev *wdev, u8 *buf, size_t len)
> +{
> + int ret, chunk_type, chunk_len, chunk_num = 0;
> +
> + if (*buf == '{') {
> + dev_err(wdev->dev, "PDS: malformed file (legacy format?)\n");
> + return -EINVAL;
> + }
> + while (len > 0) {
> + chunk_type = get_unaligned_le16(buf + 0);
> + chunk_len = get_unaligned_le16(buf + 2);
> + if (chunk_len > len) {
> + dev_err(wdev->dev, "PDS:%d: corrupted file\n", chunk_num);
> + return -EINVAL;
> + }
> + if (chunk_type != WFX_PDS_TLV_TYPE) {
> + dev_info(wdev->dev, "PDS:%d: skip unknown data\n", chunk_num);
> + goto next;
> + }
> + if (chunk_len > WFX_PDS_MAX_CHUNK_SIZE)
> + dev_warn(wdev->dev, "PDS:%d: unexpectly large chunk\n", chunk_num);
> + if (buf[4] != '{' || buf[chunk_len - 1] != '}')
> + dev_warn(wdev->dev, "PDS:%d: unexpected content\n", chunk_num);
> +
> + ret = wfx_hif_configuration(wdev, buf + 4, chunk_len - 4);
> + if (ret > 0) {
> + dev_err(wdev->dev, "PDS:%d: invalid data (unsupported options?)\n",
> + chunk_num);
> + return -EINVAL;
> + }
> + if (ret == -ETIMEDOUT) {
> + dev_err(wdev->dev, "PDS:%d: chip didn't reply (corrupted file?)\n",
> + chunk_num);
> + return ret;
> + }
> + if (ret) {
> + dev_err(wdev->dev, "PDS:%d: chip returned an unknown error\n", chunk_num);
> + return -EIO;
> + }
> +next:
> + chunk_num++;
> + len -= chunk_len;
> + buf += chunk_len;
> + }
> + return 0;
> +}
Kalle, is this function what you expected? If it is right for you, I am
going to send it to the staging tree.
--
Jérôme Pouiller
^ permalink raw reply
* Re: [PATCH] Adding architectural support for HPE's GXP BMC. This is the first of a series of patches to support HPE's BMC with Linux Kernel.
From: Krzysztof Kozlowski @ 2022-01-26 8:25 UTC (permalink / raw)
To: nick.hawkins, verdun
Cc: Rob Herring, Russell King, Shawn Guo, Stanislav Jakubek,
Sam Ravnborg, Linus Walleij, Hao Fang, Arnd Bergmann,
Russell King (Oracle), Geert Uytterhoeven, Mark Rutland,
Ard Biesheuvel, Anshuman Khandual, Lukas Bulwahn, Masahiro Yamada,
devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <20220125194609.32314-1-nick.hawkins@hpe.com>
On 25/01/2022 20:46, nick.hawkins@hpe.com wrote:
> From: Nick Hawkins <nick.hawkins@hpe.com>
>
> Signed-off-by: Nick Hawkins <nick.hawkins@hpe.com>
> ---
> .../devicetree/bindings/vendor-prefixes.yaml | 2 +
> MAINTAINERS | 8 +
> arch/arm/Kconfig | 2 +
> arch/arm/boot/dts/gxp.dts | 700 ++++++++++++++++++
> arch/arm/configs/gxp_defconfig | 243 ++++++
> arch/arm/mach-hpe/Kconfig | 20 +
> arch/arm/mach-hpe/Makefile | 1 +
> arch/arm/mach-hpe/gxp.c | 63 ++
> 8 files changed, 1039 insertions(+)
> create mode 100644 arch/arm/boot/dts/gxp.dts
> create mode 100644 arch/arm/configs/gxp_defconfig
> create mode 100644 arch/arm/mach-hpe/Kconfig
> create mode 100644 arch/arm/mach-hpe/Makefile
> create mode 100644 arch/arm/mach-hpe/gxp.c
>
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
> index 294093d45a23..e8b0ec874aed 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
> @@ -515,6 +515,8 @@ patternProperties:
> description: Jiangsu HopeRun Software Co., Ltd.
> "^hp,.*":
> description: Hewlett Packard
I guess this should be renamed/clarified to "Hewlett Packard
Incorporated", since these are two different companies.
Anyway, bindings go as separate patch, first in the series.
> + "^hpe,.*":
> + description: Hewlett Packard Enterprise
> "^hsg,.*":
Best regards,
Krzysztof
^ permalink raw reply
* RE: [PATCH 0/7] mailbox: imx: misc fix and SECO MU support
From: Peng Fan @ 2022-01-26 8:28 UTC (permalink / raw)
To: Peng Fan (OSS), jassisinghbrar@gmail.com, robh+dt@kernel.org,
shawnguo@kernel.org
Cc: s.hauer@pengutronix.de, kernel@pengutronix.de, festevam@gmail.com,
dl-linux-imx, Aisheng Dong, linux-kernel@vger.kernel.org,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org
In-Reply-To: <20220104062547.2103016-1-peng.fan@oss.nxp.com>
> Subject: [PATCH 0/7] mailbox: imx: misc fix and SECO MU support
Ping..
Thanks,
Peng.
>
> From: Peng Fan <peng.fan@nxp.com>
>
> This patchset includes a few fixes for low power and i.MX8 SECO MU support
>
> Franck LENORMAND (1):
> mailbox: imx: add i.MX8 SECO MU support
>
> Peng Fan (2):
> dt-bindings: mailbox: imx-mu: add i.MX8 SECO MU support
> mailbox: imx: introduce rxdb callback
>
> Ranjani Vaidyanathan (2):
> mailbox: imx: Add support for identifying SCU wakeup source from sysfs
> mailbox: imx: enlarge timeout while reading/writing messages to SCFW
>
> Robin Gong (2):
> mailbox: imx: fix wakeup failure from freeze mode
> mailbox: imx: fix crash in resume on i.mx8ulp
>
> .../devicetree/bindings/mailbox/fsl,mu.yaml | 1 +
> drivers/mailbox/imx-mailbox.c | 249
> +++++++++++++++++-
> 2 files changed, 243 insertions(+), 7 deletions(-)
>
> --
> 2.25.1
^ permalink raw reply
* Re: [PATCH v3 6/6] RISC-V: Do not use cpumask data structure for hartid bitmap
From: Geert Uytterhoeven @ 2022-01-26 8:28 UTC (permalink / raw)
To: Atish Patra
Cc: Jessica Clarke, Atish Patra, Linux Kernel Mailing List,
Anup Patel, Albert Ou, Damien Le Moal, devicetree, Jisheng Zhang,
Krzysztof Kozlowski, linux-riscv, Palmer Dabbelt, Paul Walmsley,
Rob Herring
In-Reply-To: <CAOnJCUKJmHv2Rs3=FR3LjiZqvM5uxcVeZ3D5xRSbEeDFCeS9=Q@mail.gmail.com>
Hi Atish,
On Wed, Jan 26, 2022 at 3:21 AM Atish Patra <atishp@atishpatra.org> wrote:
> On Tue, Jan 25, 2022 at 2:26 PM Jessica Clarke <jrtc27@jrtc27.com> wrote:
> > On 20 Jan 2022, at 09:09, Atish Patra <atishp@rivosinc.com> wrote:
> > > Currently, SBI APIs accept a hartmask that is generated from struct
> > > cpumask. Cpumask data structure can hold upto NR_CPUs value. Thus, it
> > > is not the correct data structure for hartids as it can be higher
> > > than NR_CPUs for platforms with sparse or discontguous hartids.
> > >
> > > Remove all association between hartid mask and struct cpumask.
> > >
> > > Reviewed-by: Anup Patel <anup@brainfault.org> (For Linux RISC-V changes)
> > > Acked-by: Anup Patel <anup@brainfault.org> (For KVM RISC-V changes)
> > > Signed-off-by: Atish Patra <atishp@rivosinc.com>
> I am yet to reproduce it on my end.
> @Geert Uytterhoeven: can you please try the below diff on your end.
Unfortunately it doesn't fix the issue for me.
/me debugging...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH] Adding architectural support for HPE's GXP BMC. This is the first of a series of patches to support HPE's BMC with Linux Kernel.
From: Krzysztof Kozlowski @ 2022-01-26 8:41 UTC (permalink / raw)
To: Verdun, Jean-Marie, Arnd Bergmann, Hawkins, Nick
Cc: Rob Herring, Russell King, Shawn Guo, Stanislav Jakubek,
Sam Ravnborg, Linus Walleij, Hao Fang, Russell King (Oracle),
Geert Uytterhoeven, Mark Rutland, Ard Biesheuvel,
Anshuman Khandual, Lukas Bulwahn, Masahiro Yamada, DTML,
Linux Kernel Mailing List, Linux ARM
In-Reply-To: <CA8148A1-578E-4621-9714-45AB391C353A@hpe.com>
On 26/01/2022 02:49, Verdun, Jean-Marie wrote:
> Hello Arnd,
>
> I work with Nick on upstreaming the initial code for our GXP asic. Many thanks for your feedbacks.
>
> We will update accordingly. I must admit that I am a little bit lost regarding the process we shall follow to introduce a new SoC. We took the path to send first the DT side and then the drivers through a set of patch per driver. Andrew, seems to guide us into a direction where we shall have a very small DT initially and we will expand it in a step by step manner when we will get drivers approved, this might lead us into a process which might be very sequential. What is the best recommendation to follow ? Either way is ok on our side, I am just looking at the easiest solution for the code Maintainers.
The current DTS patch won't pass checkpatch because you have around 30
undocumented compatibles. The process does not have to be sequential -
quite contrary - rather parallel with several submission happening the
same time. The point is that we need to see the bindings and check
whether your DTS complies with them. Actually the check should be done
by you with dtbs_check, but let's say we also look at it.
Your patch with full-blown DTS and drivers is also good approach, except
there are no drivers sent. For example:
https://lore.kernel.org/?q=hpe%2Cgxp-i2c
https://lore.kernel.org/?q=hpe%2Cgxp-wdt
If you want to avoid building DTS sequentially, no problem, just send
the bindings and DTS.
Andrew's approach is much more flexible because it allows you to discuss
the bindings while not postponing the core part of DTS.
>
> Most of this code is intended to be used with OpenBMC and u-boot. We didn't have yet upstream anything into the bootloader, and wanted to follow a step by step approach by initially publishing into the kernel (that explain why some init also are still hardcoded in the case the bootloader doesn't provide the data, that is still work in progress, but we can have end user testing the infrastructure). We have a very small user space environment to validate that the kernel boot properly by using u-root, before getting OpenBMC fully loaded. Last but not least, as this is a BMC code, which is new to our end users, it would be just great to have default fall back if the u-boot environment is not properly setup (roughly we could code the MAC address into the umac driver, or the DT to address such cases). We plan to update uboot in the next couple of days by the way.
>
> We do not use dtsi at all for the moment, as we are generating a dtb out of the dts file and load it into our SPI image. Probably not the best approach, but this is the way it is implemented currently. The dtb is compiled outside the kernel tree for the moment using dtc compiler. We will add that step into the dts boot Makefile, it make sense. Does the dtsi is mandatory for every SoC ? I can build one if needed. But as this SoC is a BMC, the current dts is an example of what shall be configured. Many other datas related to the hardware target platform are defined into OpenBMC layers while we build for various ProLiant servers. We wanted our kernel code being readily testable that is why we have that generic dts. (GPIOS mapping is machine dependent)
The commit misses description, so I actually don't know how the
architecture looks like. For most of SoC, there is a DTSI because the
SoC is being put on different boards/products. It allows clear
separation between SoC (which could be reused) and board. If you have
only a DTS, then:
1. Where is the SoC here? How it can be re-used by different board?
2. Is it only one DTS per entire sub-architecture? No more boards? Only
one product? No even revisions or improved versions?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v6 0/2] Driver for Open Profile for DICE
From: Greg Kroah-Hartman @ 2022-01-26 9:04 UTC (permalink / raw)
To: David Brazdil
Cc: Rob Herring, Arnd Bergmann, Frank Rowand, Will Deacon,
Andrew Scull, devicetree, linux-kernel
In-Reply-To: <20220104100645.1810028-1-dbrazdil@google.com>
On Tue, Jan 04, 2022 at 10:06:43AM +0000, David Brazdil wrote:
> Open Profile for DICE is an open protocol for measured boot compatible
> with the Trusted Computing Group's Device Identifier Composition
> Engine (DICE) specification. The generated Compound Device Identifier
> (CDI) certificates represent the measured hardware/software combination
> and can be used by userspace for remote attestation and sealing.
>
> This patchset adds DeviceTree bindings for the DICE device referencing
> a reserved memory region containing the CDIs, and a driver that exposes
> the memory region to userspace via a misc device.
>
> See https://pigweed.googlesource.com/open-dice for more details.
>
> The patches are based on top of v5.16-rc8 and can also be found here:
> https://android-kvm.googlesource.com/linux topic/dice_v6
>
> Changes since v5:
> * replaced 'additionalProperties' with 'unevaluatedProperties' in DT YAML
I am going to drop this version from my review queue as I think you have
a new one instead, right?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] arm64: dts: imx8m{m,n}_venice*: add gpio-line-names
From: Shawn Guo @ 2022-01-26 9:07 UTC (permalink / raw)
To: Tim Harvey
Cc: Rob Herring, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
NXP Linux Team, devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <20211215001812.9006-1-tharvey@gateworks.com>
On Tue, Dec 14, 2021 at 04:18:12PM -0800, Tim Harvey wrote:
> Add gpio-line-names for the various GPIO's used on Gateworks Venice
> boards. Note that these GPIO's are typically 'configured' in Boot
> Firmware via gpio-hog therefore we only configure line names to keep the
> boot firmware configuration from changing on kernel init.
>
> Signed-off-by: Tim Harvey <tharvey@gateworks.com>
It doesn't apply to my imx/dt64 branch. Could you rebase?
Shawn
^ permalink raw reply
* Re: [PATCH v10 0/4] clk: meson: add a sub EMMC clock controller support
From: Liang Yang @ 2022-01-26 9:08 UTC (permalink / raw)
To: Neil Armstrong, Jerome Brunet, Kevin Hilman, Michael Turquette,
Stephen Boyd, Rob Herring, linux-clk
Cc: Martin Blumenstingl, Jianxin Pan, Victor Wan, XianWei Zhao,
Kelvin Zhang, BiChao Zheng, YongHui Yu, linux-arm-kernel,
linux-amlogic, linux-kernel, devicetree
In-Reply-To: <f5a429f2-ffbc-ea03-810a-45a0f90959a2@baylibre.com>
Hi Neil,
On 2022/1/25 22:54, Neil Armstrong wrote:
> [ EXTERNAL EMAIL ]
>
> Hi Liang,
>
> On 21/01/2022 08:45, Liang Yang wrote:
>> This driver will add a MMC clock controller driver support.
>> The original idea about adding a clock controller is during the
>> discussion in the NAND driver mainline effort[1].
>>
>> This driver is tested in the S400 board (AXG platform) with NAND driver.
>
> Thanks a lot for providing a fixed and updated version of this serie.
>
> After some chat with Jerome and Kevin, it seems the way the eMMC clock reuse
> for NAND was designed nearly 4 years doesn't look accurate anymore.
>
> Having a separate clk driver designed to replace the eMMC node when NAND is
> used on the board seems over engineered.
>
> Actually having the clock code you add in this serie _but_ directly in
> the NAND looks far better, and more coherent since having Linux runtime
> detection of eMMC vs NAND will never happen and even this serie required
> some DT modification from the bootloader.
>
> I'll let Jerome or Kevin add more details if they want, but I think you should resurrect
> the work you pushed in [1] & [2] but:
> - passing the eMMC clk registers as a third "reg" cell
Does it just need to define a 'reg' resource in NFC node and not
'syscon' here?
> - passing the same "clocks" phandle as the eMMC node
> - adding the eMMC clock code in the NAND driver directly
>
> I'm open to discussions if you consider the current approach is still superior.
I don't have persuasive ideas, but really it shares the common clock
implementation for both NFC and EMMC. and we don't need to paste the
same code in NFC and EMMC.
>
> Thanks,
> Neil
>
> [1] https://lore.kernel.org/r/20220106033130.37623-1-liang.yang@amlogic.com
> [2] https://lore.kernel.org/r/20220106032504.23310-1-liang.yang@amlogic.com
>
>>
>> Changes since v9 [10]
>> - use clk_parent_data instead of parent_names
>>
>> Changes since v8 [9]
>> - use MESON_SCLK_ONE_BASED instead of CLK_DIVIDER_ONE_BASED
>> - use struct_size to caculate onecell_data
>> - add clk-phase-delay.h
>> - define CLK_DELAY_STEP_PS_GX and CLK_DELAY_STEP_PS_AXG
>>
>> Changes since v7 [8]
>> - move meson_clk_get_phase_delay_data() from header to driver
>> - CONFIG sclk-div with COMMON_CLK_AMLOGIC instead of COMMON_CLK_AMLOGIC_AUDIO
>> - remove onecell date and ID for internal MUX clk
>> - use helper for functions for ONE_BASED in sclk-div
>> - add ONE_BASED support for duty cycle
>>
>> Changes since v6 [7]:
>> - add one based support for sclk divier
>> - alloc sclk in probe for multiple instance
>> - fix coding styles
>>
>> Changes since v5 [6]:
>> - remove divider ops with .init and use sclk_div instead
>> - drop CLK_DIVIDER_ROUND_CLOSEST in mux and div
>> - drop the useless type cast
>>
>> Changes since v4 [5]:
>> - use struct parm in phase delay driver
>> - remove 0 delay releted part in phase delay driver
>> - don't rebuild the parent name once again
>> - add divider ops with .init
>>
>> Changes since v3 [4]:
>> - separate clk-phase-delay driver
>> - replace clk_get_rate() with clk_hw_get_rate()
>> - collect Rob's R-Y
>> - drop 'meson-' prefix from compatible string
>>
>> Changes since v2 [3]:
>> - squash dt-binding clock-id patch
>> - update license
>> - fix alignment
>> - construct a clk register helper() function
>>
>> Changes since v1 [2]:
>> - implement phase clock
>> - update compatible name
>> - adjust file name
>> - divider probe() into small functions, and re-use them
>>
>> [1] https://lkml.kernel.org/r/20180628090034.0637a062@xps13
>> [2] https://lkml.kernel.org/r/20180703145716.31860-1-yixun.lan@amlogic.com
>> [3] https://lkml.kernel.org/r/20180710163658.6175-1-yixun.lan@amlogic.com
>> [4] https://lkml.kernel.org/r/20180712211244.11428-1-yixun.lan@amlogic.com
>> [5] https://lkml.kernel.org/r/20180809070724.11935-4-yixun.lan@amlogic.com
>> [6] https://lkml.kernel.org/r/1539839245-13793-1-git-send-email-jianxin.pan@amlogic.com
>> [7] https://lkml.kernel.org/r/1541089855-19356-1-git-send-email-jianxin.pan@amlogic.com
>> [8] https://lkml.kernel.org/r/1544457877-51301-1-git-send-email-jianxin.pan@amlogic.com
>> [9] https://lkml.kernel.org/r/1545063850-21504-1-git-send-email-jianxin.pan@amlogic.com
>> [10] https://lore.kernel.org/all/20220113115745.45826-1-liang.yang@amlogic.com/
>> Liang Yang (4):
>> clk: meson: add one based divider support for sclk
>> clk: meson: add emmc sub clock phase delay driver
>> clk: meson: add DT documentation for emmc clock controller
>> clk: meson: add sub MMC clock controller driver
>>
>> .../bindings/clock/amlogic,mmc-clkc.yaml | 64 ++++
>> drivers/clk/meson/Kconfig | 18 ++
>> drivers/clk/meson/Makefile | 2 +
>> drivers/clk/meson/clk-phase-delay.c | 69 ++++
>> drivers/clk/meson/clk-phase-delay.h | 20 ++
>> drivers/clk/meson/mmc-clkc.c | 302 ++++++++++++++++++
>> drivers/clk/meson/sclk-div.c | 59 ++--
>> drivers/clk/meson/sclk-div.h | 3 +
>> include/dt-bindings/clock/amlogic,mmc-clkc.h | 14 +
>> 9 files changed, 529 insertions(+), 22 deletions(-)
>> create mode 100644 Documentation/devicetree/bindings/clock/amlogic,mmc-clkc.yaml
>> create mode 100644 drivers/clk/meson/clk-phase-delay.c
>> create mode 100644 drivers/clk/meson/clk-phase-delay.h
>> create mode 100644 drivers/clk/meson/mmc-clkc.c
>> create mode 100644 include/dt-bindings/clock/amlogic,mmc-clkc.h
>>
>
> .
^ permalink raw reply
* Re: [PATCH v3 6/6] RISC-V: Do not use cpumask data structure for hartid bitmap
From: Geert Uytterhoeven @ 2022-01-26 9:10 UTC (permalink / raw)
To: Atish Patra
Cc: Jessica Clarke, Atish Patra, Linux Kernel Mailing List,
Anup Patel, Albert Ou, Damien Le Moal, devicetree, Jisheng Zhang,
Krzysztof Kozlowski, linux-riscv, Palmer Dabbelt, Paul Walmsley,
Rob Herring
In-Reply-To: <CAMuHMdW+ZO0=Qc8NCWujZUq=L-LZJpcd7oZo4MxRFYMmcURXVQ@mail.gmail.com>
Hi Atish,
On Wed, Jan 26, 2022 at 9:28 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> On Wed, Jan 26, 2022 at 3:21 AM Atish Patra <atishp@atishpatra.org> wrote:
> > On Tue, Jan 25, 2022 at 2:26 PM Jessica Clarke <jrtc27@jrtc27.com> wrote:
> > > On 20 Jan 2022, at 09:09, Atish Patra <atishp@rivosinc.com> wrote:
> > > > Currently, SBI APIs accept a hartmask that is generated from struct
> > > > cpumask. Cpumask data structure can hold upto NR_CPUs value. Thus, it
> > > > is not the correct data structure for hartids as it can be higher
> > > > than NR_CPUs for platforms with sparse or discontguous hartids.
> > > >
> > > > Remove all association between hartid mask and struct cpumask.
> > > >
> > > > Reviewed-by: Anup Patel <anup@brainfault.org> (For Linux RISC-V changes)
> > > > Acked-by: Anup Patel <anup@brainfault.org> (For KVM RISC-V changes)
> > > > Signed-off-by: Atish Patra <atishp@rivosinc.com>
>
> > I am yet to reproduce it on my end.
> > @Geert Uytterhoeven: can you please try the below diff on your end.
>
> Unfortunately it doesn't fix the issue for me.
>
> /me debugging...
Found it: after this commit, the SBI_EXT_RFENCE_REMOTE_FENCE_I and
SBI_EXT_RFENCE_REMOTE_SFENCE_VMA ecalls are now called with
hmask = 0x8000000000000001 and hbase = 1 instead of hmask = 3 and
hbase = 0.
cpuid 1 maps to hartid 0
cpuid 0 maps to hartid 1
__sbi_rfence_v02:364: cpuid 1 hartid 0
__sbi_rfence_v02:377: hartid 0 hbase 1
hmask |= 1UL << (hartid - hbase);
oops
__sbi_rfence_v02_call:303: SBI_EXT_RFENCE_REMOTE_FENCE_I hmask
8000000000000001 hbase 1
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH V5 6/9] arm64: dts: imx8mn: add GPC node
From: Shawn Guo @ 2022-01-26 9:10 UTC (permalink / raw)
To: Adam Ford
Cc: linux-arm-kernel, tharvey, aford, michael, jagan, Lucas Stach,
Rob Herring, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
NXP Linux Team, devicetree, linux-kernel
In-Reply-To: <20211215004626.2241839-7-aford173@gmail.com>
On Tue, Dec 14, 2021 at 06:46:23PM -0600, Adam Ford wrote:
> Add the DT node for the GPC, including all the PGC power domains,
> some of them are not fully functional yet, as they require interaction
> with the blk-ctrls to properly power up/down the peripherals.
>
> Signed-off-by: Adam Ford <aford173@gmail.com>
> Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
Applied #6 ~ #9, thanks!
^ permalink raw reply
* Re: [PATCH v5 02/16] dt-bindings: clock: Add bindings definitions for FSD CMU blocks
From: Sylwester Nawrocki @ 2022-01-26 9:12 UTC (permalink / raw)
To: Alim Akhtar, linux-arm-kernel, linux-kernel
Cc: soc, linux-clk, devicetree, olof, arnd, linus.walleij,
catalin.marinas, robh+dt, krzysztof.kozlowski, linux-samsung-soc,
pankaj.dubey, sboyd, linux-fsd
In-Reply-To: <20220124141644.71052-3-alim.akhtar@samsung.com>
On 24.01.2022 15:16, Alim Akhtar wrote:
> Clock controller driver of FSD platform is designed to have separate
> instances for each particular CMU. So clock IDs in this bindings header
> also start from 1 for each CMU block.
>
> Cc: linux-fsd@tesla.com
> Reported-by: kernel test robot <lkp@intel.com>
> [robot: reported missing #endif]
> Acked-by: Stephen Boyd <sboyd@kernel.org>
> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
> Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
> Signed-off-by: Alim Akhtar <alim.akhtar@samsung.com>
Acked-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
^ permalink raw reply
* Re: [PATCH 3/4] iio: adc: xilinx-ams: Fixed wrong sequencer register settings
From: Michael Tretter @ 2022-01-26 9:12 UTC (permalink / raw)
To: Robert Hancock
Cc: lars@metafoo.de, robh+dt@kernel.org, jic23@kernel.org,
devicetree@vger.kernel.org, michal.simek@xilinx.com,
linux-iio@vger.kernel.org, manish.narani@xilinx.com,
linux-arm-kernel@lists.infradead.org, kernel@pengutronix.de,
anand.ashok.dumbre@xilinx.com
In-Reply-To: <4c5fb3899a8aafa34106a668bcb2807b6f073036.camel@calian.com>
On Tue, 25 Jan 2022 16:15:05 +0000, Robert Hancock wrote:
> On Tue, 2022-01-25 at 09:21 +0100, Michael Tretter wrote:
> > On Wed, 19 Jan 2022 19:02:45 -0600, Robert Hancock wrote:
> > > Register settings used for the sequencer configuration register
> > > were incorrect, causing some inputs to not be read properly.
> > >
> > > Fixes: d5c70627a794 ("iio: adc: Add Xilinx AMS driver")
> > > Signed-off-by: Robert Hancock <robert.hancock@calian.com>
> > > ---
> > > drivers/iio/adc/xilinx-ams.c | 4 ++--
> > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/iio/adc/xilinx-ams.c b/drivers/iio/adc/xilinx-ams.c
> > > index b93864362dac..199027c93cdc 100644
> > > --- a/drivers/iio/adc/xilinx-ams.c
> > > +++ b/drivers/iio/adc/xilinx-ams.c
> > > @@ -91,8 +91,8 @@
> > >
> > > #define AMS_CONF1_SEQ_MASK GENMASK(15, 12)
> > > #define AMS_CONF1_SEQ_DEFAULT FIELD_PREP(AMS_CONF1_SEQ_MASK,
> > > 0)
> > > -#define AMS_CONF1_SEQ_CONTINUOUS FIELD_PREP(AMS_CONF1_SEQ_MASK, 1)
> > > -#define AMS_CONF1_SEQ_SINGLE_CHANNEL FIELD_PREP(AMS_CONF1_SEQ_MASK,
> > > 2)
> > > +#define AMS_CONF1_SEQ_CONTINUOUS FIELD_PREP(AMS_CONF1_SEQ_MASK, 2)
> > > +#define AMS_CONF1_SEQ_SINGLE_CHANNEL FIELD_PREP(AMS_CONF1_SEQ_MASK,
> > > 3)
> >
> > The TRM states that Continuous Loop Mode is 2, but Single Pass Sequence Mode
> > is 1, not 3. Is there a reason, why you need to set both bits?
>
> Single pass sequence mode (1) just runs the same sequence only once. To read
> these values it needs to switch to single channel mode (3).
>
> The register bits are defined in Table 3-8 of
> https://www.xilinx.com/support/documentation/user_guides/ug580-ultrascale-sysmon.pdf
> .
Thanks for the clarification.
Reviewed-by: Michael Tretter <m.tretter@pengutronix.de>
>
> >
> > Michael
> >
> > >
> > > #define AMS_REG_SEQ0_MASK GENMASK(15, 0)
> > > #define AMS_REG_SEQ2_MASK GENMASK(21, 16)
> > > --
> > > 2.31.1
> > >
> > >
> > > _______________________________________________
> > > linux-arm-kernel mailing list
> > > linux-arm-kernel@lists.infradead.org
> > > https://urldefense.com/v3/__http://lists.infradead.org/mailman/listinfo/linux-arm-kernel__;!!IOGos0k!yGFEjSC1BL20lwurby914len0HCLXyzarwxKJP9Jx30qv_qrERSkRJUiVo_2MdusMVA$
> > >
> --
> Robert Hancock
> Senior Hardware Designer, Calian Advanced Technologies
> www.calian.com
^ permalink raw reply
* Re: [PATCH v5 03/16] dt-bindings: clock: Document FSD CMU bindings
From: Sylwester Nawrocki @ 2022-01-26 9:13 UTC (permalink / raw)
To: Alim Akhtar, linux-arm-kernel, linux-kernel
Cc: soc, linux-clk, devicetree, olof, arnd, linus.walleij,
catalin.marinas, robh+dt, krzysztof.kozlowski, linux-samsung-soc,
pankaj.dubey, sboyd, linux-fsd
In-Reply-To: <20220124141644.71052-4-alim.akhtar@samsung.com>
On 24.01.2022 15:16, Alim Akhtar wrote:
> Add dt-schema documentation for Tesla FSD SoC clock controller.
>
> Cc: linux-fsd@tesla.com
> Acked-by: Stephen Boyd <sboyd@kernel.org>
> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
> Signed-off-by: Alim Akhtar <alim.akhtar@samsung.com>
Acked-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
^ permalink raw reply
* Re: [PATCH v5 04/16] clk: samsung: fsd: Add initial clock support
From: Sylwester Nawrocki @ 2022-01-26 9:14 UTC (permalink / raw)
To: Alim Akhtar, linux-arm-kernel, linux-kernel
Cc: soc, linux-clk, devicetree, olof, arnd, linus.walleij,
catalin.marinas, robh+dt, krzysztof.kozlowski, linux-samsung-soc,
pankaj.dubey, sboyd, linux-fsd, Jayati Sahu, Ajay Kumar
In-Reply-To: <20220124141644.71052-5-alim.akhtar@samsung.com>
On 24.01.2022 15:16, Alim Akhtar wrote:
> Add initial clock support for FSD (Full Self-Driving) SoC
> which is required to bring-up platforms based on this SoC.
>
> Also, fix the build error reported by the kernel test robot [1].
> Cc: linux-fsd@tesla.com
> Reported-by: kernel test robot <lkp@intel.com>
> Signed-off-by: Jayati Sahu <jayati.sahu@samsung.com>
> Signed-off-by: Ajay Kumar <ajaykumar.rs@samsung.com>
> Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
> Signed-off-by: Alim Akhtar <alim.akhtar@samsung.com>
Acked-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
^ permalink raw reply
* Re: [PATCH v5 05/16] clk: samsung: fsd: Add cmu_peric block clock information
From: Sylwester Nawrocki @ 2022-01-26 9:15 UTC (permalink / raw)
To: Alim Akhtar, linux-arm-kernel, linux-kernel
Cc: soc, linux-clk, devicetree, olof, arnd, linus.walleij,
catalin.marinas, robh+dt, krzysztof.kozlowski, linux-samsung-soc,
pankaj.dubey, sboyd, linux-fsd, Aswani Reddy, Niyas Ahmed S T,
Chandrasekar R, Jayati Sahu, Sriranjani P, Ajay Kumar
In-Reply-To: <20220124141644.71052-6-alim.akhtar@samsung.com>
On 24.01.2022 15:16, Alim Akhtar wrote:
> Add CMU_PERIC block clock information needed for various IPs
> functions found in this block.
>
> Cc: linux-fsd@tesla.com
> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
> Signed-off-by: Aswani Reddy <aswani.reddy@samsung.com>
> Signed-off-by: Niyas Ahmed S T <niyas.ahmed@samsung.com>
> Signed-off-by: Chandrasekar R <rcsekar@samsung.com>
> Signed-off-by: Jayati Sahu <jayati.sahu@samsung.com>
> Signed-off-by: Sriranjani P <sriranjani.p@samsung.com>
> Signed-off-by: Ajay Kumar <ajaykumar.rs@samsung.com>
> Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
> Signed-off-by: Alim Akhtar <alim.akhtar@samsung.com>
Acked-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
^ 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