* Re: [PATCH v2 02/18] PCI: endpoint: Introduce pci_epc_map_align()
From: Dan Carpenter @ 2024-04-05 8:38 UTC (permalink / raw)
To: oe-kbuild, Damien Le Moal, Manivannan Sadhasivam,
Lorenzo Pieralisi, Kishon Vijay Abraham I, Shawn Lin,
Krzysztof Wilczyński, Bjorn Helgaas, Heiko Stuebner,
linux-pci, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
devicetree
Cc: lkp, oe-kbuild-all, linux-rockchip, linux-arm-kernel,
Rick Wertenbroek, Wilfred Mallawa, Niklas Cassel
In-Reply-To: <20240330041928.1555578-3-dlemoal@kernel.org>
Hi Damien,
kernel test robot noticed the following build warnings:
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Damien-Le-Moal/PCI-endpoint-Introduce-pci_epc_function_is_valid/20240330-122311
base: https://git.kernel.org/pub/scm/linux/kernel/git/pci/pci.git next
patch link: https://lore.kernel.org/r/20240330041928.1555578-3-dlemoal%40kernel.org
patch subject: [PATCH v2 02/18] PCI: endpoint: Introduce pci_epc_map_align()
config: parisc-randconfig-r071-20240405 (https://download.01.org/0day-ci/archive/20240405/202404051508.hvNRDVZq-lkp@intel.com/config)
compiler: hppa-linux-gcc (GCC) 13.2.0
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
| Closes: https://lore.kernel.org/r/202404051508.hvNRDVZq-lkp@intel.com/
smatch warnings:
drivers/pci/endpoint/pci-epc-core.c:493 pci_epc_map_align() error: we previously assumed 'features' could be null (see line 487)
vim +/features +493 drivers/pci/endpoint/pci-epc-core.c
9d2f10d2ace040 Damien Le Moal 2024-03-30 458 int pci_epc_map_align(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
9d2f10d2ace040 Damien Le Moal 2024-03-30 459 u64 pci_addr, size_t size, struct pci_epc_map *map)
9d2f10d2ace040 Damien Le Moal 2024-03-30 460 {
9d2f10d2ace040 Damien Le Moal 2024-03-30 461 const struct pci_epc_features *features;
9d2f10d2ace040 Damien Le Moal 2024-03-30 462 size_t mask;
9d2f10d2ace040 Damien Le Moal 2024-03-30 463 int ret;
9d2f10d2ace040 Damien Le Moal 2024-03-30 464
9d2f10d2ace040 Damien Le Moal 2024-03-30 465 if (!pci_epc_function_is_valid(epc, func_no, vfunc_no))
9d2f10d2ace040 Damien Le Moal 2024-03-30 466 return -EINVAL;
9d2f10d2ace040 Damien Le Moal 2024-03-30 467
9d2f10d2ace040 Damien Le Moal 2024-03-30 468 if (!size || !map)
9d2f10d2ace040 Damien Le Moal 2024-03-30 469 return -EINVAL;
9d2f10d2ace040 Damien Le Moal 2024-03-30 470
9d2f10d2ace040 Damien Le Moal 2024-03-30 471 memset(map, 0, sizeof(*map));
9d2f10d2ace040 Damien Le Moal 2024-03-30 472 map->pci_addr = pci_addr;
9d2f10d2ace040 Damien Le Moal 2024-03-30 473 map->pci_size = size;
9d2f10d2ace040 Damien Le Moal 2024-03-30 474
9d2f10d2ace040 Damien Le Moal 2024-03-30 475 if (epc->ops->map_align) {
9d2f10d2ace040 Damien Le Moal 2024-03-30 476 mutex_lock(&epc->lock);
9d2f10d2ace040 Damien Le Moal 2024-03-30 477 ret = epc->ops->map_align(epc, func_no, vfunc_no, map);
9d2f10d2ace040 Damien Le Moal 2024-03-30 478 mutex_unlock(&epc->lock);
9d2f10d2ace040 Damien Le Moal 2024-03-30 479 return ret;
9d2f10d2ace040 Damien Le Moal 2024-03-30 480 }
9d2f10d2ace040 Damien Le Moal 2024-03-30 481
9d2f10d2ace040 Damien Le Moal 2024-03-30 482 /*
9d2f10d2ace040 Damien Le Moal 2024-03-30 483 * Assume a fixed alignment constraint as specified by the controller
9d2f10d2ace040 Damien Le Moal 2024-03-30 484 * features.
9d2f10d2ace040 Damien Le Moal 2024-03-30 485 */
9d2f10d2ace040 Damien Le Moal 2024-03-30 486 features = pci_epc_get_features(epc, func_no, vfunc_no);
9d2f10d2ace040 Damien Le Moal 2024-03-30 @487 if (!features || !features->align) {
^^^^^^^^^
Check for NULL
9d2f10d2ace040 Damien Le Moal 2024-03-30 488 map->map_pci_addr = pci_addr;
9d2f10d2ace040 Damien Le Moal 2024-03-30 489 map->map_size = size;
9d2f10d2ace040 Damien Le Moal 2024-03-30 490 map->map_ofst = 0;
Missing return 0?
9d2f10d2ace040 Damien Le Moal 2024-03-30 491 }
9d2f10d2ace040 Damien Le Moal 2024-03-30 492
9d2f10d2ace040 Damien Le Moal 2024-03-30 @493 mask = features->align - 1;
^^^^^^^^^^
9d2f10d2ace040 Damien Le Moal 2024-03-30 494 map->map_pci_addr = map->pci_addr & ~mask;
9d2f10d2ace040 Damien Le Moal 2024-03-30 495 map->map_ofst = map->pci_addr & mask;
9d2f10d2ace040 Damien Le Moal 2024-03-30 496 map->map_size = ALIGN(map->map_ofst + map->pci_size, features->align);
9d2f10d2ace040 Damien Le Moal 2024-03-30 497
9d2f10d2ace040 Damien Le Moal 2024-03-30 498 return 0;
9d2f10d2ace040 Damien Le Moal 2024-03-30 499 }
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: Fixing the devicetree of Rock 5 Model B (and possibly others)
From: Pratham Patel @ 2024-04-05 8:32 UTC (permalink / raw)
To: Saravana Kannan
Cc: Dragan Simic, sebastian.reichel, devicetree, linux-arm-kernel,
linux-rockchip, linux-kernel, regressions, stable
In-Reply-To: <D0A2ZL6S8UG6.2BQKIBQWYB36D@thefossguy.com>
On Wednesday, April 3rd, 2024 at 06:33, Pratham Patel <prathampatel@thefossguy.com> wrote:
>
>
> On Wed Apr 3, 2024 at 6:16 AM IST, Saravana Kannan wrote:
>
> > On Tue, Apr 2, 2024 at 4:32 PM Pratham Patel
> > prathampatel@thefossguy.com wrote:
> >
> > > On Tue Apr 2, 2024 at 4:54 AM IST, Saravana Kannan wrote:
> > >
> > > > On Sat, Mar 23, 2024 at 10:10 AM Dragan Simic dsimic@manjaro.org wrote:
> > > >
> > > > > Hello Pratham,
> > > > >
> > > > > On 2024-03-23 18:02, Pratham Patel wrote:
> > > > >
> > > > > > I looked at the patch and tried several things, neither resulted in
> > > > > > anything that would point me to the core issue. Then I tried this:
> > > > >
> > > > > Could you, please, clarify a bit what's the actual issue you're
> > > > > experiencing on your Rock 5B?
> > > >
> > > > Pratham, can you reply to this please? I don't really understand what
> > > > your issue is for me to be able to help.
> > >
> > > Hi,
> > >
> > > I apologize for not replying. Somehow, I did not notice the reply from
> > > Dragan. :(
> > >
> > > Since this patch was applied, an issue in the Rock 5B's DT has been
> > > unearthed which now results in the kernel being unable to boot properly.
> > >
> > > Following is the relevant call trace from the UART capture:
> > >
> > > [ 21.595068] Call trace:
> > > [ 21.595288] smp_call_function_many_cond+0x174/0x5f8
> > > [ 21.595728] on_each_cpu_cond_mask+0x2c/0x40
> > > [ 21.596109] cpuidle_register_driver+0x294/0x318
> > > [ 21.596524] cpuidle_register+0x24/0x100
> > > [ 21.596875] psci_cpuidle_probe+0x2e4/0x490
> > > [ 21.597247] platform_probe+0x70/0xd0
> > > [ 21.597575] really_probe+0x18c/0x3d8
> > > [ 21.597905] __driver_probe_device+0x84/0x180
> > > [ 21.598294] driver_probe_device+0x44/0x120
> > > [ 21.598669] __device_attach_driver+0xc4/0x168
> > > [ 21.599063] bus_for_each_drv+0x8c/0xf0
> > > [ 21.599408] __device_attach+0xa4/0x1c0
> > > [ 21.599748] device_initial_probe+0x1c/0x30
> > > [ 21.600118] bus_probe_device+0xb4/0xc0
> > > [ 21.600462] device_add+0x68c/0x888
> > > [ 21.600775] platform_device_add+0x19c/0x270
> > > [ 21.601154] platform_device_register_full+0xdc/0x178
> > > [ 21.601602] psci_idle_init+0xa0/0xc8
> > > [ 21.601934] do_one_initcall+0x60/0x290
> > > [ 21.602275] kernel_init_freeable+0x20c/0x3e0
> > > [ 21.602664] kernel_init+0x2c/0x1f8
> > > [ 21.602979] ret_from_fork+0x10/0x20
> >
> > This doesn't make a lot of sense. "remote-endpoint" shouldn't be
> > related to anything to do with psci cpuidle. I'm guessing something
> > else is failing much earlier in boot that's indirectly causing this
> > somehow? Can you please take a look at what's failing earlier and let
> > us know? Or see what driver probe is failing up to this point but used
> > to work in the good case.
>
>
> I'm pretty new to this, "just starting". I'm not sure how to do that,
> since the kernel doesn't really "move forward". I will verify if
> a8037ceb8964 fixes it or not and get back by the end of this week.
>
> > Also, where is the dts file that corresponds to this board in upstream? Is it
> > arch/arm64/boot/dts/rockchip/rk3588-rock-5b.dts
>
>
> Yes.
>
> > > > Also, can you give the output of <debugfs>/devices_deferred for the
> > > > good vs bad case?
> > >
> > > I can't provide you with requested output from the bad case, since the
> > > kernel never moves past this to an initramfs rescue shell, but following
> > > is the output from v6.8.1 (with aforementioned patch reverted).
> > >
> > > # cat /sys/kernel/debug/devices_deferred
> > > fc400000.usb platform: wait for supplier /phy@fed90000/usb3-port
> > > 1-0022 typec_fusb302: cannot register tcpm port
> > > fc000000.usb platform: wait for supplier /phy@fed80000/usb3-port
> > >
> > > It seems that v6.8.2 works without needing to revert the patch. I will
> > > have to look into this sometime this week but it seems like
> > > a8037ceb8964 (arm64: dts: rockchip: drop rockchip,trcm-sync-tx-only from rk3588 i2s)
> > > seems to be the one that fixed the root issue. I will have to test it
> > > sometime later this week.
> >
> > Ok, once you find the patch that fixes things, let me know too.
I confirm that a8037ceb8964 fixed this issue for me. Now, v6.8.2+ boots on my Rock 5B,
with my distro's config and the arm64 defconfig.
-- Pratham Patel
^ permalink raw reply
* Re: [PATCH v8 3/7] PCI: qcom: Add ICC bandwidth vote for CPU to PCIe path
From: Manivannan Sadhasivam @ 2024-04-05 8:29 UTC (permalink / raw)
To: Krishna Chaitanya Chundru
Cc: Bjorn Andersson, Konrad Dybcio, Lorenzo Pieralisi,
Krzysztof Wilczyński, Rob Herring, Bjorn Helgaas,
Krzysztof Kozlowski, Conor Dooley, Manivannan Sadhasivam,
Rob Herring, Johan Hovold, Brian Masney, Georgi Djakov,
linux-arm-msm, linux-pci, devicetree, linux-kernel, vireshk,
quic_vbadigan, quic_skananth, quic_nitegupt, quic_parass,
Bryan O'Donoghue
In-Reply-To: <9d878f69-c9d1-1ee4-f80e-1d8f16c6920e@quicinc.com>
On Tue, Mar 05, 2024 at 04:23:21PM +0530, Krishna Chaitanya Chundru wrote:
>
>
> On 3/4/2024 11:11 PM, Manivannan Sadhasivam wrote:
> > On Sat, Mar 02, 2024 at 09:29:57AM +0530, Krishna chaitanya chundru wrote:
> > > To access PCIe registers, PCIe BAR space, config space the CPU-PCIe
> > > ICC (interconnect consumers) path should be voted otherwise it may
> > > lead to NoC (Network on chip) timeout. We are surviving because of
> > > other driver vote for this path.
> > >
> > > As there is less access on this path compared to PCIe to mem path
> > > add minimum vote i.e 1KBps bandwidth always.
> >
> > Please add the info that 1KBps is what shared by the HW team.
> >
> Ack to all the comments
> > >
> > > When suspending, disable this path after register space access
> > > is done.
> > >
> > > Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
> > > Signed-off-by: Krishna chaitanya chundru <quic_krichai@quicinc.com>
> > > ---
> > > drivers/pci/controller/dwc/pcie-qcom.c | 38 ++++++++++++++++++++++++++++++++--
> > > 1 file changed, 36 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/pci/controller/dwc/pcie-qcom.c b/drivers/pci/controller/dwc/pcie-qcom.c
> > > index 10f2d0bb86be..a0266bfe71f1 100644
> > > --- a/drivers/pci/controller/dwc/pcie-qcom.c
> > > +++ b/drivers/pci/controller/dwc/pcie-qcom.c
[...]
> > > + ret = icc_disable(pcie->icc_cpu);
> > > + if (ret) {
> > > + dev_err(dev, "failed to disable icc path of cpu-pcie: %d\n", ret);
> >
> > "CPU-PCIe"
> >
> > > + if (pcie->suspended) {
> > > + qcom_pcie_host_init(&pcie->pci->pp);
> >
> > Interesting. So if icc_disable() fails, can the IP continue to function?
> >
> As the ICC already enable before icc_disable() fails, the IP should work.
If icc_disable() fails, then most likely something is wrong with RPMh. How can
the IP continue to work in that case?
- Mani
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH v8 7/7] PCI: qcom: Add OPP support to scale performance state of power domain
From: Manivannan Sadhasivam @ 2024-04-05 8:23 UTC (permalink / raw)
To: Krishna Chaitanya Chundru
Cc: Manivannan Sadhasivam, Bjorn Andersson, Konrad Dybcio,
Lorenzo Pieralisi, Krzysztof Wilczyński, Rob Herring,
Bjorn Helgaas, Krzysztof Kozlowski, Conor Dooley, Rob Herring,
Johan Hovold, Brian Masney, Georgi Djakov, linux-arm-msm,
linux-pci, devicetree, linux-kernel, vireshk, quic_vbadigan,
quic_skananth, quic_nitegupt, quic_parass
In-Reply-To: <c74e326e-285d-854e-5e54-329079152df2@quicinc.com>
On Tue, Mar 05, 2024 at 04:44:20PM +0530, Krishna Chaitanya Chundru wrote:
>
>
> On 3/4/2024 11:35 PM, Manivannan Sadhasivam wrote:
> > On Sat, Mar 02, 2024 at 09:30:01AM +0530, Krishna chaitanya chundru wrote:
> > > QCOM Resource Power Manager-hardened (RPMh) is a hardware block which
> > > maintains hardware state of a regulator by performing max aggregation of
> > > the requests made by all of the clients.
> > >
> > > PCIe controller can operate on different RPMh performance state of power
> > > domain based on the speed of the link. And this performance state varies
> > > from target to target, like some controllers support GEN3 in NOM (Nominal)
> > > voltage corner, while some other supports GEN3 in low SVS (static voltage
> > > scaling).
> > >
> > > The SoC can be more power efficient if we scale the performance state
> > > based on the aggregate PCIe link bandwidth.
> > >
> > > Add Operating Performance Points (OPP) support to vote for RPMh state based
> > > on the aggregate link bandwidth.
> > >
> > > OPP can handle ICC bw voting also, so move ICC bw voting through OPP
> > > framework if OPP entries are present.
> > >
> > > Different link configurations may share the same aggregate bandwidth,
> > > e.g., a 2.5 GT/s x2 link and a 5.0 GT/s x1 link have the same bandwidth
> > > and share the same OPP entry.
> > >
> > > As we are moving ICC voting as part of OPP, don't initialize ICC if OPP
> > > is supported.
> > >
> > > Signed-off-by: Krishna chaitanya chundru <quic_krichai@quicinc.com>
> > > ---
> > > drivers/pci/controller/dwc/pcie-qcom.c | 81 +++++++++++++++++++++++++++-------
> > > 1 file changed, 66 insertions(+), 15 deletions(-)
> > >
> > > diff --git a/drivers/pci/controller/dwc/pcie-qcom.c b/drivers/pci/controller/dwc/pcie-qcom.c
> > > index a0266bfe71f1..2ec14bfafcfc 100644
> > > --- a/drivers/pci/controller/dwc/pcie-qcom.c
> > > +++ b/drivers/pci/controller/dwc/pcie-qcom.c
[...]
> > > static int qcom_pcie_link_transition_count(struct seq_file *s, void *data)
> > > @@ -1472,8 +1491,10 @@ static void qcom_pcie_init_debugfs(struct qcom_pcie *pcie)
> > > static int qcom_pcie_probe(struct platform_device *pdev)
> > > {
> > > const struct qcom_pcie_cfg *pcie_cfg;
> > > + unsigned long max_freq = INT_MAX;
> > > struct device *dev = &pdev->dev;
> > > struct qcom_pcie *pcie;
> > > + struct dev_pm_opp *opp;
> > > struct dw_pcie_rp *pp;
> > > struct resource *res;
> > > struct dw_pcie *pci;
> > > @@ -1540,9 +1561,36 @@ static int qcom_pcie_probe(struct platform_device *pdev)
> > > goto err_pm_runtime_put;
> > > }
> > > - ret = qcom_pcie_icc_init(pcie);
> > > - if (ret)
> > > + /* OPP table is optional */
> > > + ret = devm_pm_opp_of_add_table(dev);
> > > + if (ret && ret != -ENODEV) {
> > > + dev_err_probe(dev, ret, "Failed to add OPP table\n");
> > > goto err_pm_runtime_put;
> > > + }
> > > +
> > > + /*
> > > + * Use highest OPP here if the OPP table is present. At the end of
> >
> > Why highest opp? For ICC, we set minimal bandwidth before.
> >
> In OPP we are voting for both ICC and voltage corner also, if we didn't vote
> for maximum voltage core the PCIe link may not come in maximum supported
> speed. Due to that we are voting for Maximum value.
>
Okay, then this information should be part of the comment.
- Mani
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH 4/4] clk: en7523: add EN7581 support
From: Lorenzo Bianconi @ 2024-04-05 8:17 UTC (permalink / raw)
To: AngeloGioacchino Del Regno
Cc: linux-clk, mturquette, sboyd, linux-arm-kernel, robh+dt,
krzysztof.kozlowski+dt, conor+dt, nbd, john, devicetree, dd,
catalin.marinas, will, upstream, lorenzo.bianconi83
In-Reply-To: <0297a8ab-2f62-4f03-b2ed-87180a47c57c@collabora.com>
[-- Attachment #1: Type: text/plain, Size: 9826 bytes --]
> Il 03/04/24 18:20, Lorenzo Bianconi ha scritto:
> > Introduce EN7581 clock support to clk-en7523 driver.
> >
> > Tested-by: Zhengping Zhang <zhengping.zhang@airoha.com>
> > Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
> > ---
> > drivers/clk/clk-en7523.c | 130 +++++++++++++++++++++++++++++++++++++--
> > 1 file changed, 125 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/clk/clk-en7523.c b/drivers/clk/clk-en7523.c
> > index c7def87b74c6..51a6c0cc7f58 100644
> > --- a/drivers/clk/clk-en7523.c
> > +++ b/drivers/clk/clk-en7523.c
> > @@ -4,13 +4,16 @@
> > #include <linux/clk-provider.h>
> > #include <linux/io.h>
> > #include <linux/of.h>
> > +#include <linux/of_device.h>
> > #include <linux/platform_device.h>
> > #include <dt-bindings/clock/en7523-clk.h>
> > #define REG_PCI_CONTROL 0x88
> > #define REG_PCI_CONTROL_PERSTOUT BIT(29)
> > #define REG_PCI_CONTROL_PERSTOUT1 BIT(26)
> > +#define REG_PCI_CONTROL_REFCLK_EN0 BIT(23)
> > #define REG_PCI_CONTROL_REFCLK_EN1 BIT(22)
> > +#define REG_PCI_CONTROL_PERSTOUT2 BIT(16)
> > #define REG_GSW_CLK_DIV_SEL 0x1b4
> > #define REG_EMI_CLK_DIV_SEL 0x1b8
> > #define REG_BUS_CLK_DIV_SEL 0x1bc
> > @@ -18,10 +21,25 @@
> > #define REG_SPI_CLK_FREQ_SEL 0x1c8
> > #define REG_NPU_CLK_DIV_SEL 0x1fc
> > #define REG_CRYPTO_CLKSRC 0x200
> > -#define REG_RESET_CONTROL 0x834
> > +#define REG_RESET_CONTROL2 0x830
>
> Wait what? The RESET2 register comes before RESET1 ?!?!
>
> Is this a typo? :-)
actually not :)
>
> > +#define REG_RESET2_CONTROL_PCIE2 BIT(27)
> > +#define REG_RESET_CONTROL1 0x834
> > #define REG_RESET_CONTROL_PCIEHB BIT(29)
> > #define REG_RESET_CONTROL_PCIE1 BIT(27)
> > #define REG_RESET_CONTROL_PCIE2 BIT(26)
> > +/* EN7581 */
> > +#define REG_PCIE0_MEM 0x00
> > +#define REG_PCIE0_MEM_MASK 0x04
> > +#define REG_PCIE1_MEM 0x08
> > +#define REG_PCIE1_MEM_MASK 0x0c
> > +#define REG_PCIE2_MEM 0x10
> > +#define REG_PCIE2_MEM_MASK 0x14
> > +#define REG_PCIE_RESET_OPEN_DRAIN 0x018c
> > +#define REG_PCIE_RESET_OPEN_DRAIN_MASK GENMASK(2, 0)
> > +#define REG_NP_SCU_PCIC 0x88
> > +#define REG_NP_SCU_SSTR 0x9c
> > +#define REG_PCIE_XSI0_SEL_MASK GENMASK(14, 13)
> > +#define REG_PCIE_XSI1_SEL_MASK GENMASK(12, 11)
> > struct en_clk_desc {
> > int id;
> > @@ -207,14 +225,14 @@ static int en7523_pci_prepare(struct clk_hw *hw)
> > usleep_range(1000, 2000);
> > /* Reset to default */
> > - val = readl(np_base + REG_RESET_CONTROL);
> > + val = readl(np_base + REG_RESET_CONTROL1);
> > mask = REG_RESET_CONTROL_PCIE1 | REG_RESET_CONTROL_PCIE2 |
> > REG_RESET_CONTROL_PCIEHB;
> > - writel(val & ~mask, np_base + REG_RESET_CONTROL);
> > + writel(val & ~mask, np_base + REG_RESET_CONTROL1);
> > usleep_range(1000, 2000);
> > - writel(val | mask, np_base + REG_RESET_CONTROL);
> > + writel(val | mask, np_base + REG_RESET_CONTROL1);
> > msleep(100);
> > - writel(val & ~mask, np_base + REG_RESET_CONTROL);
> > + writel(val & ~mask, np_base + REG_RESET_CONTROL1);
> > usleep_range(5000, 10000);
> > /* Release device */
> > @@ -262,6 +280,64 @@ static struct clk_hw *en7523_register_pcie_clk(struct device *dev,
> > return &cg->hw;
> > }
> > +static int en7581_pci_is_enabled(struct clk_hw *hw)
> > +{
> > + struct en_clk_gate *cg = container_of(hw, struct en_clk_gate, hw);
> > + u32 val, mask;
> > +
> > + mask = REG_PCI_CONTROL_REFCLK_EN0 | REG_PCI_CONTROL_REFCLK_EN1;
> > + val = readl(cg->base + REG_PCI_CONTROL);
> > + return (val & mask) == mask;
> > +}
> > +
> > +static int en7581_pci_prepare(struct clk_hw *hw)
> > +{
> > + struct en_clk_gate *cg = container_of(hw, struct en_clk_gate, hw);
> > + void __iomem *np_base = cg->base;
> > + u32 val, mask;
> > +
> > + mask = REG_RESET_CONTROL_PCIE1 | REG_RESET_CONTROL_PCIE2 |
> > + REG_RESET_CONTROL_PCIEHB;
> > + val = readl(np_base + REG_RESET_CONTROL1);
> > + writel(val & ~mask, np_base + REG_RESET_CONTROL1);
> > + val = readl(np_base + REG_RESET_CONTROL2);
> > + writel(val & ~REG_RESET2_CONTROL_PCIE2, np_base + REG_RESET_CONTROL2);
> > + usleep_range(5000, 10000);
> > +
> > + mask = REG_PCI_CONTROL_REFCLK_EN0 | REG_PCI_CONTROL_REFCLK_EN1 |
> > + REG_PCI_CONTROL_PERSTOUT1 | REG_PCI_CONTROL_PERSTOUT2 |
> > + REG_PCI_CONTROL_PERSTOUT;
>
> I'm not sure that this is actually something to control in a clock driver...
>
> the right thing to do would be to add a reset controller to this clock driver
> and then assert/deassert reset in the PCIe PHY/MAC driver.
>
> Perhaps REFCLK_EN0/EN1 can be manipulated in a .enable() callback, treating
> this really just as what it appears to really be: a gate clock! (hint: check
> clk-gate.c)
ack, I will look into it.
>
> > + val = readl(np_base + REG_PCI_CONTROL);
> > + writel(val | mask, np_base + REG_PCI_CONTROL);
> > + msleep(250);
> > +
> > + return 0;
> > +}
> > +
> > +static void en7581_pci_unprepare(struct clk_hw *hw)
> > +{
> > + struct en_clk_gate *cg = container_of(hw, struct en_clk_gate, hw);
> > + void __iomem *np_base = cg->base;
> > + u32 val, mask;
> > +
> > + mask = REG_PCI_CONTROL_REFCLK_EN0 | REG_PCI_CONTROL_REFCLK_EN1 |
>
> ...and this should be a clk-gate .disable() callback, I guess :-)
ack, I will look into it.
>
> > + REG_PCI_CONTROL_PERSTOUT1 | REG_PCI_CONTROL_PERSTOUT2 |
> > + REG_PCI_CONTROL_PERSTOUT;
> > + val = readl(np_base + REG_PCI_CONTROL);
> > + writel(val & ~mask, np_base + REG_PCI_CONTROL);
> > + usleep_range(1000, 2000);
> > +
> > + mask = REG_RESET_CONTROL_PCIE1 | REG_RESET_CONTROL_PCIE2 |
> > + REG_RESET_CONTROL_PCIEHB;
> > + val = readl(np_base + REG_RESET_CONTROL1);
> > + writel(val | mask, np_base + REG_RESET_CONTROL1);
> > + mask = REG_RESET_CONTROL_PCIE1 | REG_RESET_CONTROL_PCIE2;
> > + writel(val | mask, np_base + REG_RESET_CONTROL1);
> > + val = readl(np_base + REG_RESET_CONTROL2);
> > + writel(val | REG_RESET_CONTROL_PCIE2, np_base + REG_RESET_CONTROL2);
> > + msleep(100);
> > +}
> > +
> > static void en7523_register_clocks(struct device *dev, struct clk_hw_onecell_data *clk_data,
> > void __iomem *base, void __iomem *np_base)
> > {
> > @@ -291,6 +367,37 @@ static void en7523_register_clocks(struct device *dev, struct clk_hw_onecell_dat
> > clk_data->num = EN7523_NUM_CLOCKS;
> > }
> > +static int en7581_clk_hw_init(struct platform_device *pdev,
> > + void __iomem *base,
> > + void __iomem *np_base)
> > +{
> > + void __iomem *pb_base;
> > + u32 val;
> > +
> > + pb_base = devm_platform_ioremap_resource(pdev, 2);
> > + if (IS_ERR(pb_base))
> > + return PTR_ERR(pb_base);
> > +
> > + val = readl(np_base + REG_NP_SCU_SSTR);
> > + val &= ~(REG_PCIE_XSI0_SEL_MASK | REG_PCIE_XSI1_SEL_MASK);
> > + writel(val, np_base + REG_NP_SCU_SSTR);
> > + val = readl(np_base + REG_NP_SCU_PCIC);
> > + writel(val | 3, np_base + REG_NP_SCU_PCIC);
>
> What is 3?
>
> #define SOMETHING 3 ??
actullay I do not know what it means since write in the pcie_ctrl subfield of
REG_NP_SCU_PCIC but it is a GENMASK(7, 0) and I do not have any more info
about it.
>
> > +
> > + writel(0x20000000, pb_base + REG_PCIE0_MEM);
> > + writel(0xfc000000, pb_base + REG_PCIE0_MEM_MASK);
> > + writel(0x24000000, pb_base + REG_PCIE1_MEM);
> > + writel(0xfc000000, pb_base + REG_PCIE1_MEM_MASK);
> > + writel(0x28000000, pb_base + REG_PCIE2_MEM);
> > + writel(0xfc000000, pb_base + REG_PCIE2_MEM_MASK);
>
> And... this is .. some BIT() and some GENMASK() as far as I understand...
> do we have any clue about what you're setting to those registers?
same as above, they seems undocumented.
@airoha folks: any input about them?
>
> Can MediaTek/Airoha help with this, please?
>
> #define SOMETHING BIT(29) /* this is 0x20000000 */
> #define SOME_MASK GENMASK(31, 26) /* this is 0xfc00000 */
>
> > +
> > + val = readl(base + REG_PCIE_RESET_OPEN_DRAIN);
> > + writel(val | REG_PCIE_RESET_OPEN_DRAIN_MASK,
> > + base + REG_PCIE_RESET_OPEN_DRAIN);
> > +
> > + return 0;
> > +}
> > +
> > static int en7523_clk_probe(struct platform_device *pdev)
> > {
> > struct device_node *node = pdev->dev.of_node;
> > @@ -306,6 +413,12 @@ static int en7523_clk_probe(struct platform_device *pdev)
> > if (IS_ERR(np_base))
> > return PTR_ERR(np_base);
> > + if (of_device_is_compatible(node, "airoha,en7581-scu")) {
> > + r = en7581_clk_hw_init(pdev, base, np_base);
> > + if (r)
> > + return r;
> > + }
> > +
> > clk_data = devm_kzalloc(&pdev->dev,
> > struct_size(clk_data, hws, EN7523_NUM_CLOCKS),
> > GFP_KERNEL);
> > @@ -329,8 +442,15 @@ static const struct clk_ops en7523_pcie_ops = {
> > .unprepare = en7523_pci_unprepare,
> > };
>
> static const struct clk_en7523_pdata en7581_pdata = {
> .init = en7581_clk_hw_init, /* if (pdata->init) pdata->init(x, y, z) */
> .ops = en7581_pcie_ops,
> };
>
> or, alternatively:
>
> static const struct .... = {
> .init = ...,
> .ops = (const struct clk_ops) {
> .is_enabled = en7581_pci_is_enabled,
> .... etc
> }
ack, I will fix it.
Regards,
Lorenzo
> };
>
> Cheers,
> Angelo
>
> > +static const struct clk_ops en7581_pcie_ops = {
> > + .is_enabled = en7581_pci_is_enabled,
> > + .prepare = en7581_pci_prepare,
> > + .unprepare = en7581_pci_unprepare,
> > +};
> > +
> > static const struct of_device_id of_match_clk_en7523[] = {
> > { .compatible = "airoha,en7523-scu", .data = &en7523_pcie_ops },
> > + { .compatible = "airoha,en7581-scu", .data = &en7581_pcie_ops },
> > { /* sentinel */ }
> > };
>
> -
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH RESEND v3 2/2] Input: atmel_mxt_ts - support poweroff in suspend
From: Stefan Eichenberger @ 2024-04-05 8:15 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: nick, robh+dt, krzysztof.kozlowski+dt, conor+dt, nicolas.ferre,
alexandre.belloni, claudiu.beznea, linus.walleij, linux-input,
devicetree, linux-arm-kernel, linux-kernel, francesco.dolcini,
Stefan Eichenberger
In-Reply-To: <ZfSYp6aV6bRhlPUJ@google.com>
Hi Dmitry,
Thanks for the feedback, I had a first look at the changes and I'm not
sure if we would break some use cases. Therfore, here some questions.
On Fri, Mar 15, 2024 at 11:51:19AM -0700, Dmitry Torokhov wrote:
> > diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c b/drivers/input/touchscreen/atmel_mxt_ts.c
> > index 542a31448c8f..2d5655385702 100644
> > --- a/drivers/input/touchscreen/atmel_mxt_ts.c
> > +++ b/drivers/input/touchscreen/atmel_mxt_ts.c
> > @@ -317,6 +317,7 @@ struct mxt_data {
> > struct gpio_desc *reset_gpio;
> > struct gpio_desc *wake_gpio;
> > bool use_retrigen_workaround;
> > + bool poweroff_sleep;
> >
> > /* Cached parameters from object table */
> > u16 T5_address;
> > @@ -2799,15 +2800,18 @@ static int mxt_configure_objects(struct mxt_data *data,
> > dev_warn(dev, "Error %d updating config\n", error);
> > }
> >
> > - if (data->multitouch) {
> > - error = mxt_initialize_input_device(data);
> > - if (error)
> > - return error;
> > - } else {
> > - dev_warn(dev, "No touch object detected\n");
> > - }
> > + /* If input device is not already registered */
> > + if (!data->input_dev) {
> > + if (data->multitouch) {
> > + error = mxt_initialize_input_device(data);
> > + if (error)
> > + return error;
> > + } else {
> > + dev_warn(dev, "No touch object detected\n");
> > + }
> >
> > - mxt_debug_init(data);
> > + mxt_debug_init(data);
> > + }
> >
> > return 0;
> > }
> > @@ -3325,6 +3329,8 @@ static int mxt_probe(struct i2c_client *client)
> > msleep(MXT_RESET_INVALID_CHG);
> > }
> >
> > + data->poweroff_sleep = device_property_read_bool(&client->dev,
> > + "atmel,poweroff-sleep");
> > /*
> > * Controllers like mXT1386 have a dedicated WAKE line that could be
> > * connected to a GPIO or to I2C SCL pin, or permanently asserted low.
> > @@ -3387,12 +3393,21 @@ static int mxt_suspend(struct device *dev)
> > if (!input_dev)
> > return 0;
> >
> > - mutex_lock(&input_dev->mutex);
> > + if (!device_may_wakeup(dev) && data->poweroff_sleep) {
> > + if (data->reset_gpio)
> > + gpiod_set_value(data->reset_gpio, 1);
> >
> > - if (input_device_enabled(input_dev))
> > - mxt_stop(data);
> > + regulator_bulk_disable(ARRAY_SIZE(data->regulators),
> > + data->regulators);
> > + data->T44_address = 0;
> > + } else {
> > + mutex_lock(&input_dev->mutex);
> > +
> > + if (input_device_enabled(input_dev))
> > + mxt_stop(data);
> >
> > - mutex_unlock(&input_dev->mutex);
> > + mutex_unlock(&input_dev->mutex);
> > + }
>
> This all should go into mxt_stop(), so that if device is closed, or
> inhibited, you power it down as well (if you can).
We would then have to power it up during probe to see if the device is
threre, read the configuration and power it down again afterwards until
the device is opened. If the device is in bootloader mode we would most
likely have to keep the power on all the time and never turn it off,
right?
>
> >
> > disable_irq(data->irq);
> >
> > @@ -3408,14 +3423,37 @@ static int mxt_resume(struct device *dev)
> > if (!input_dev)
> > return 0;
> >
> > - enable_irq(data->irq);
> > + if (!device_may_wakeup(dev) && data->poweroff_sleep) {
> > + int ret;
> >
> > - mutex_lock(&input_dev->mutex);
> > + ret = regulator_bulk_enable(ARRAY_SIZE(data->regulators),
> > + data->regulators);
> > + if (ret) {
> > + dev_err(dev, "failed to enable regulators: %d\n",
> > + ret);
> > + return ret;
> > + }
> > + msleep(MXT_BACKUP_TIME);
> >
> > - if (input_device_enabled(input_dev))
> > - mxt_start(data);
> > + if (data->reset_gpio) {
> > + /* Wait a while and then de-assert the RESET GPIO line */
> > + msleep(MXT_RESET_GPIO_TIME);
> > + gpiod_set_value(data->reset_gpio, 0);
> > + msleep(MXT_RESET_INVALID_CHG);
> > + }
> >
> > - mutex_unlock(&input_dev->mutex);
> > + /* This also enables the irq again */
> > + mxt_initialize(data);
>
> And this needs to go into mxt_start(). Also, we should make sure that
> once resume operation completes the device is fully operational. That
> means you should not request the firmware asynchronously in
> mxt_initialize() in case you are in the resume path. I think you should
> also unwind mxt_initialize() and mxt_configure_objects() to make it
> clear what is the part of initial initialization and what is part of
> re-initializing during resume. The configuration that is exposed to
> userspace (resolution, number of objects, other properties) should stay
> the same, the configuration of the chip itself (power mode, etc) should
> be restored.
Here we would most likely have to load the firmware (configuration)
synchronously all the time if the poweroff_sleep flag is set. Ths makes
sure that the device is ready when we open the device. Would this delay
be acceptable when opening the input device? Normally the configuration
is not that big and should load quite fast.
Regards,
Stefan
^ permalink raw reply
* Re: [PATCH v2] dt-bindings: crypto: ti,omap-sham: Convert to dtschema
From: Animesh Agarwal @ 2024-04-05 8:12 UTC (permalink / raw)
To: Herbert Xu
Cc: David S. Miller, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-crypto, devicetree, linux-kernel
In-Reply-To: <Zg+tgFFDkwLvWgLv@gondor.apana.org.au>
On Fri, Apr 5, 2024 at 1:21 PM Herbert Xu <herbert@gondor.apana.org.au> wrote:
> Patch applied. Thanks.
Glad to hear. Thanks!
---
Animesh Agarwal
^ permalink raw reply
* Re: [PATCH RFT 0/7] arm64: qcom: allow up to 4 lanes for the Type-C DisplayPort Altmode
From: Neil Armstrong @ 2024-04-05 8:08 UTC (permalink / raw)
To: Luca Weiss, Konrad Dybcio, Bjorn Andersson
Cc: Vinod Koul, Kishon Vijay Abraham I, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Abhinav Kumar, linux-arm-msm,
linux-phy, devicetree, linux-kernel
In-Reply-To: <D064242SMIVM.1GUC1I9GE9IGC@fairphone.com>
Hi Luca,
On 29/03/2024 10:02, Luca Weiss wrote:
> On Tue Mar 26, 2024 at 10:02 PM CET, Konrad Dybcio wrote:
>> On 16.03.2024 5:01 PM, Bjorn Andersson wrote:
>>> On Fri, Mar 15, 2024 at 06:35:15PM +0100, Neil Armstrong wrote:
>>>> On 15/03/2024 18:19, Luca Weiss wrote:
>>>>> On Thu Feb 29, 2024 at 2:07 PM CET, Neil Armstrong wrote:
>>>>>> Register a typec mux in order to change the PHY mode on the Type-C
>>>>>> mux events depending on the mode and the svid when in Altmode setup.
>>>>>>
>>>>>> The DisplayPort phy should be left enabled if is still powered on
>>>>>> by the DRM DisplayPort controller, so bail out until the DisplayPort
>>>>>> PHY is not powered off.
>>>>>>
>>>>>> The Type-C Mode/SVID only changes on plug/unplug, and USB SAFE states
>>>>>> will be set in between of USB-Only, Combo and DisplayPort Only so
>>>>>> this will leave enough time to the DRM DisplayPort controller to
>>>>>> turn of the DisplayPort PHY.
>>>>>>
>>>>>> The patchset also includes bindings changes and DT changes.
>>>>>>
>>>>>> This has been successfully tested on an SM8550 board, but the
>>>>>> Thinkpad X13s deserved testing between non-PD USB, non-PD DisplayPort,
>>>>>> PD USB Hubs and PD Altmode Dongles to make sure the switch works
>>>>>> as expected.
>>>>>>
>>>>>> The DisplayPort 4 lanes setup can be check with:
>>>>>> $ cat /sys/kernel/debug/dri/ae01000.display-controller/DP-1/dp_debug
>>>>>> name = msm_dp
>>>>>> drm_dp_link
>>>>>> rate = 540000
>>>>>> num_lanes = 4
>>>>>
>>>>> Hi Neil,
>>>>>
>>>>> I tried this on QCM6490/SC7280 which should also support 4-lane DP but I
>>>>> haven't had any success so far.
>>>>>
>>> [..]
>>>>> [ 1775.563969] [drm:dp_ctrl_link_train] *ERROR* max v_level reached
>>>>> [ 1775.564031] [drm:dp_ctrl_link_train] *ERROR* link training #1 failed. ret=-11
>>>>
>>>> Interesting #1 means the 4 lanes are not physically connected to the other side,
>>>> perhaps QCM6490/SC7280 requires a specific way to enable the 4 lanes in the PHY,
>>>> or some fixups in the init tables.
>>>>
>>>
>>> I tested the same on rb3gen2 (qcs6490) a couple of weeks ago, with the
>>> same outcome. Looking at the AUX reads, after switching to 4-lane the
>>> link training is failing on all 4 lanes, in contrast to succeeding only
>>> on the first 2 if you e.g. forget to mux the other two.
>>>
>>> As such, my expectation is that there's something wrong in the QMP PHY
>>> (or possibly redriver) for this platform.
>>
>> Do we have any downstream tag where 4lane dp works? I'm willing to believe
>> the PHY story..
>
> Just tested on Fairphone 5 downstream and 4 lane appears to work there.
> This is with an USB-C to HDMI adapter that only does HDMI.
>
> FP5:/ # cat /sys/kernel/debug/drm_dp/dp_debug
> state=0x20a5
> link_rate=270000
> num_lanes=4
> resolution=2560x1440@60Hz
> pclock=241500KHz
> bpp=24
> test_req=DP_LINK_STATUS_UPDATED
> lane_count=4
> bw_code=10
> v_level=0
> p_level=0
>
> Sources are here:
> https://gerrit-public.fairphone.software/plugins/gitiles/kernel/msm-5.4/+/refs/heads/odm/rc/target/13/fp5
> And probably more importantly techpack/display:
> https://gerrit-public.fairphone.software/plugins/gitiles/platform/vendor/opensource/display-drivers/+/refs/heads/odm/rc/target/13/fp5
> Dts if useful:
> https://gerrit-public.fairphone.software/plugins/gitiles/kernel/msm-extra/devicetree/+/refs/heads/kernel/13/fp5
Could you retry with this applied ?
https://lore.kernel.org/all/20240405000111.1450598-1-swboyd@chromium.org/
Thanks,
Neil
>
> Regards
> Luca
>
>>
>> Konrad
>
^ permalink raw reply
* Re: [PATCH] dt-bindings: usb: Document the Microchip USB2514 hub
From: Krzysztof Kozlowski @ 2024-04-05 8:04 UTC (permalink / raw)
To: Fabio Estevam, gregkh
Cc: robh, krzk+dt, conor+dt, linux-usb, devicetree, Fabio Estevam
In-Reply-To: <20240404164140.662361-1-festevam@gmail.com>
On 04/04/2024 18:41, Fabio Estevam wrote:
> From: Fabio Estevam <festevam@denx.de>
>
> Document the Microchip USB2514, USB2412, and USB2417 USB hubs.
There is 2514b already. Why it cannot be there? Is the existing file
only for I2C interface and here you add on-board-hub approach interface?
If so, mention it briefly in commit msg (one sentence is enough).
>
> Signed-off-by: Fabio Estevam <festevam@denx.de>
> ---
> .../bindings/usb/microchip,usb2514.yaml | 53 +++++++++++++++++++
> 1 file changed, 53 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/usb/microchip,usb2514.yaml
>
> diff --git a/Documentation/devicetree/bindings/usb/microchip,usb2514.yaml b/Documentation/devicetree/bindings/usb/microchip,usb2514.yaml
> new file mode 100644
> index 000000000000..8df7a5adfbe8
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/usb/microchip,usb2514.yaml
> @@ -0,0 +1,53 @@
> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/usb/microchip,usb2514.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Microchip USB2514 Hub Controller
> +
> +maintainers:
> + - Fabio Estevam <festevam@gmail.com>
> +
> +properties:
> + compatible:
> + enum:
> + - usb424,2412
> + - usb424,2514
> + - usb424,2417
Please keep the list ordered.
> +
> + reg: true
> +
> + reset-gpios:
> + description: GPIO connected to the RESET_N pin.
> +
> + vdd-supply:
> + description: 3.3V power supply.
> +
> + clocks:
> + description: External 24MHz clock connected to the CLKIN pin.
maxItems.
> +
> +required:
> + - compatible
> + - reg
> +
> +unevaluatedProperties: true
No, this must be false.
This does not make really sense. You miss $ref... and when you do not
have $ref you should use additionalProperties: false. Open existing
bindings for device of the same class.
> +
> +examples:
> + - |
> + #include <dt-bindings/clock/imx6qdl-clock.h>
> + #include <dt-bindings/gpio/gpio.h>
> +
> + usb {
> + dr_mode = "host";
Drop property, it's kind of expected/obvious and we want to limit
chances schema will complain about something unrelated to your device.
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + hub@1 {
> + compatible = "usb424,2514";
Inconsistent indentation. Use 4 spaces for example indentation.
> + reg = <1>;
> + clocks = <&clks IMX6QDL_CLK_CKO>;
> + reset-gpios = <&gpio7 12 GPIO_ACTIVE_LOW>;
> + vdd-supply = <®_3v3_hub>;
> + };
> + };
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v5] dt-bindings: serial: actions,owl-uart: convert to dtschema
From: Kanak Shilledar @ 2024-04-05 8:02 UTC (permalink / raw)
Cc: daniel.baluta, Kanak Shilledar, Krzysztof Kozlowski,
Greg Kroah-Hartman, Jiri Slaby, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Andreas Färber, Manivannan Sadhasivam,
linux-kernel, linux-serial, devicetree, linux-arm-kernel,
linux-actions
From: Kanak Shilledar <kanakshilledar111@protonmail.com>
Convert the Actions Semi Owl UART to newer DT schema.
Created DT schema based on the .txt file which had
`compatible`, `reg` and `interrupts` as the
required properties. This binding is used by Actions S500, S700
and S900 SoC. S700 and S900 use the same UART compatible string.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Kanak Shilledar <kanakshilledar111@protonmail.com>
---
Changes in v5
- rebased the patch
- sent to all the maintainers
Changes in v4
- updated commit message
- `clocks` property is removed from the required section.
- remove disabled status from example devicetree
---
.../bindings/serial/actions,owl-uart.txt | 16 -------
.../bindings/serial/actions,owl-uart.yaml | 48 +++++++++++++++++++
2 files changed, 48 insertions(+), 16 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/serial/actions,owl-uart.txt
create mode 100644 Documentation/devicetree/bindings/serial/actions,owl-uart.yaml
diff --git a/Documentation/devicetree/bindings/serial/actions,owl-uart.txt b/Documentation/devicetree/bindings/serial/actions,owl-uart.txt
deleted file mode 100644
index aa873eada02d..000000000000
--- a/Documentation/devicetree/bindings/serial/actions,owl-uart.txt
+++ /dev/null
@@ -1,16 +0,0 @@
-Actions Semi Owl UART
-
-Required properties:
-- compatible : "actions,s500-uart", "actions,owl-uart" for S500
- "actions,s900-uart", "actions,owl-uart" for S900
-- reg : Offset and length of the register set for the device.
-- interrupts : Should contain UART interrupt.
-
-
-Example:
-
- uart3: serial@b0126000 {
- compatible = "actions,s500-uart", "actions,owl-uart";
- reg = <0xb0126000 0x1000>;
- interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>;
- };
diff --git a/Documentation/devicetree/bindings/serial/actions,owl-uart.yaml b/Documentation/devicetree/bindings/serial/actions,owl-uart.yaml
new file mode 100644
index 000000000000..ab1c4514ae93
--- /dev/null
+++ b/Documentation/devicetree/bindings/serial/actions,owl-uart.yaml
@@ -0,0 +1,48 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/serial/actions,owl-uart.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Actions Semi Owl UART
+
+maintainers:
+ - Kanak Shilledar <kanakshilledar111@protonmail.com>
+
+allOf:
+ - $ref: serial.yaml
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - actions,s500-uart
+ - actions,s900-uart
+ - const: actions,owl-uart
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/actions,s500-cmu.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ uart0: serial@b0126000 {
+ compatible = "actions,s500-uart", "actions,owl-uart";
+ reg = <0xb0126000 0x1000>;
+ clocks = <&cmu CLK_UART0>;
+ interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>;
+ };
--
2.34.1
^ permalink raw reply related
* Re: [PATCH] arm64: dts: mediatek: mt7981: add watchdog & WiFi controllers
From: AngeloGioacchino Del Regno @ 2024-04-05 8:02 UTC (permalink / raw)
To: Matthias Brugger, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Rafał Miłecki
Cc: AngeloGioacchino Del Regno, Chunfeng Yun, Greg Kroah-Hartman,
Daniel Golle, linux-usb, linux-arm-kernel, linux-mediatek,
devicetree, linux-kernel, Rafał Miłecki
In-Reply-To: <20240221085547.27840-1-zajec5@gmail.com>
On Wed, 21 Feb 2024 09:55:47 +0100, Rafał Miłecki wrote:
> MT7981 (Filogic 820) is a low cost version of MT7986 (Filogic 830) with
> the same watchdog controller. It also comes with on-SoC 802.11ax
> wireless.
>
>
Applied to v6.9-next/dts64, thanks!
[1/1] arm64: dts: mediatek: mt7981: add watchdog & WiFi controllers
commit: 452f39543ce4cebda3471931b0efc6a46e765458
Cheers,
Angelo
^ permalink raw reply
* Re: (subset) [PATCH 1/2] dt-bindings: usb: mtk-xhci: add compatible for MT7988
From: AngeloGioacchino Del Regno @ 2024-04-05 8:02 UTC (permalink / raw)
To: Matthias Brugger, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Rafał Miłecki
Cc: AngeloGioacchino Del Regno, Chunfeng Yun, Greg Kroah-Hartman,
Daniel Golle, linux-usb, linux-arm-kernel, linux-mediatek,
devicetree, linux-kernel, Rafał Miłecki
In-Reply-To: <20240213130044.1976-1-zajec5@gmail.com>
On Tue, 13 Feb 2024 14:00:43 +0100, Rafał Miłecki wrote:
> From: Rafał Miłecki <rafal@milecki.pl>
>
> MT7988 SoC contains two on-SoC XHCI controllers. Add proper binding.
>
>
Applied to v6.9-next/dts64, thanks!
[2/2] arm64: dts: mediatek: mt7988: add XHCI controllers
commit: 4ee20d528b0487f879f789e010fe2269bc1b2f71
Cheers,
Angelo
^ permalink raw reply
* Re: [PATCH] arm64: dts: mediatek: mt7986: prefix BPI-R3 cooling maps with "map-"
From: AngeloGioacchino Del Regno @ 2024-04-05 8:02 UTC (permalink / raw)
To: Matthias Brugger, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Rafał Miłecki
Cc: AngeloGioacchino Del Regno, Sam Shih, Lorenzo Bianconi,
David S . Miller, Daniel Golle, Frank Wunderlich, devicetree,
linux-kernel, linux-arm-kernel, linux-mediatek,
Rafał Miłecki
In-Reply-To: <20240213061459.17917-1-zajec5@gmail.com>
On Tue, 13 Feb 2024 07:14:59 +0100, Rafał Miłecki wrote:
> This fixes:
> arch/arm64/boot/dts/mediatek/mt7986a-bananapi-bpi-r3.dtb: thermal-zones: cpu-thermal:cooling-maps: 'cpu-active-high', 'cpu-active-low', 'cpu-active-med' do not match any of the regexes: '^map[-a-zA-Z0-9]*$', 'pinctrl-[0-9]+'
> from schema $id: http://devicetree.org/schemas/thermal/thermal-zones.yaml#
>
>
Applied to v6.9-fixes/dts64, thanks!
[1/1] arm64: dts: mediatek: mt7986: prefix BPI-R3 cooling maps with "map-"
commit: f8c65a5e4560781f2ea175d8f26cd75ac98e8d78
Cheers,
Angelo
^ permalink raw reply
* Re: [PATCH] arm64: dts: mediatek: mt2712: fix validation errors
From: AngeloGioacchino Del Regno @ 2024-04-05 8:02 UTC (permalink / raw)
To: Matthias Brugger, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Rafał Miłecki
Cc: AngeloGioacchino Del Regno, Sam Shih, Lorenzo Bianconi,
David S . Miller, Daniel Golle, Frank Wunderlich, devicetree,
linux-kernel, linux-arm-kernel, linux-mediatek,
Rafał Miłecki
In-Reply-To: <20240301074741.8362-1-zajec5@gmail.com>
On Fri, 01 Mar 2024 08:47:41 +0100, Rafał Miłecki wrote:
> 1. Fixup infracfg clock controller binding
> It also acts as reset controller so #reset-cells is required.
> 2. Use -pins suffix for pinctrl
>
> This fixes:
> arch/arm64/boot/dts/mediatek/mt2712-evb.dtb: syscon@10001000: '#reset-cells' is a required property
> from schema $id: http://devicetree.org/schemas/arm/mediatek/mediatek,infracfg.yaml#
> arch/arm64/boot/dts/mediatek/mt2712-evb.dtb: pinctrl@1000b000: 'eth_default', 'eth_sleep', 'usb0_iddig', 'usb1_iddig' do not match any of the regexes: 'pinctrl-[0-9]+', 'pins$'
> from schema $id: http://devicetree.org/schemas/pinctrl/mediatek,mt65xx-pinctrl.yaml#
>
> [...]
Applied to v6.9-fixes/dts64, thanks!
[1/1] arm64: dts: mediatek: mt2712: fix validation errors
commit: 3baac7291effb501c4d52df7019ebf52011e5772
Cheers,
Angelo
^ permalink raw reply
* Re: [PATCH 1/3] arm64: dts: mediatek: mt7986: drop invalid properties from ethsys
From: AngeloGioacchino Del Regno @ 2024-04-05 8:02 UTC (permalink / raw)
To: Matthias Brugger, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Rafał Miłecki
Cc: AngeloGioacchino Del Regno, Sam Shih, Lorenzo Bianconi,
David S . Miller, Daniel Golle, Frank Wunderlich, devicetree,
linux-kernel, linux-arm-kernel, linux-mediatek,
Rafał Miłecki
In-Reply-To: <20240213053739.14387-1-zajec5@gmail.com>
On Tue, 13 Feb 2024 06:37:37 +0100, Rafał Miłecki wrote:
> Mediatek ethsys controller / syscon binding doesn't allow any subnodes
> so "#address-cells" and "#size-cells" are redundant (actually:
> disallowed).
>
> This fixes:
> arch/arm64/boot/dts/mediatek/mt7986a-bananapi-bpi-r3.dtb: syscon@15000000: '#address-cells', '#size-cells' do not match any of the regexes: 'pinctrl-[0-9]+'
> from schema $id: http://devicetree.org/schemas/clock/mediatek,ethsys.yaml#
>
> [...]
Applied to v6.9-fixes/dts64, thanks!
[1/3] arm64: dts: mediatek: mt7986: drop invalid properties from ethsys
commit: 3b449bfd2ff6c5d3ceecfcb18528ff8e1b4ac2fd
[2/3] arm64: dts: mediatek: mt7986: drop "#reset-cells" from Ethernet controller
commit: 9bd88afc94c3570289a0f1c696578b3e1f4e3169
[3/3] arm64: dts: mediatek: mt7986: drop invalid thermal block clock
commit: 970f8b01bd7719a22e577ba6c78e27f9ccf22783
Cheers,
Angelo
^ permalink raw reply
* Re: [PATCH 17/17] MAINTAINERS: Add phy-gs101-ufs file to Tensor GS101.
From: Krzysztof Kozlowski @ 2024-04-05 8:00 UTC (permalink / raw)
To: Peter Griffin, mturquette, sboyd, robh, krzk+dt, conor+dt, vkoul,
kishon, alim.akhtar, avri.altman, bvanassche, s.nawrocki,
cw00.choi, jejb, martin.petersen, chanho61.park, ebiggers
Cc: linux-scsi, linux-phy, devicetree, linux-clk, linux-samsung-soc,
linux-kernel, linux-arm-kernel, tudor.ambarus, andre.draszik,
saravanak, willmcvicker
In-Reply-To: <20240404122559.898930-18-peter.griffin@linaro.org>
On 04/04/2024 14:25, Peter Griffin wrote:
> Add the newly created ufs phy for GS101 to MAINTAINERS.
>
> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> ---
> MAINTAINERS | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 491d48f7c2fa..48ac9bd64f22 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -9256,6 +9256,7 @@ S: Maintained
> F: Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
> F: arch/arm64/boot/dts/exynos/google/
> F: drivers/clk/samsung/clk-gs101.c
> +F: drivers/phy/samsung/phy-gs101-ufs.c
This could go also via phy-tree:
Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 16/17] scsi: ufs: host: ufs-exynos: Add support for Tensor gs101 SoC
From: Krzysztof Kozlowski @ 2024-04-05 7:59 UTC (permalink / raw)
To: Peter Griffin, mturquette, sboyd, robh, krzk+dt, conor+dt, vkoul,
kishon, alim.akhtar, avri.altman, bvanassche, s.nawrocki,
cw00.choi, jejb, martin.petersen, chanho61.park, ebiggers
Cc: linux-scsi, linux-phy, devicetree, linux-clk, linux-samsung-soc,
linux-kernel, linux-arm-kernel, tudor.ambarus, andre.draszik,
saravanak, willmcvicker
In-Reply-To: <20240404122559.898930-17-peter.griffin@linaro.org>
On 04/04/2024 14:25, Peter Griffin wrote:
> Add a dedicated compatible and drv_data with associated
> hooks for gs101 SoC found on Pixel 6.
>
> Note we make use of the previously added EXYNOS_UFS_OPT_UFSPR_SECURE
> option, to skip initialisation of UFSPR registers as these are only
> accessible via SMC call.
>
> EXYNOS_UFS_OPT_TIMER_TICK_SELECT option is also set to select tick
> source. This has been done so as not to effect any existing platforms.
>
> DBG_OPTION_SUITE on gs101 has different address offsets to other SoCs
> so these register offsets now come from uic_attr struct.
>
> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> ---
Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 15/17] scsi: ufs: host: ufs-exynos: add some pa_dbg_ register offsets into drvdata
From: Krzysztof Kozlowski @ 2024-04-05 7:59 UTC (permalink / raw)
To: Peter Griffin, mturquette, sboyd, robh, krzk+dt, conor+dt, vkoul,
kishon, alim.akhtar, avri.altman, bvanassche, s.nawrocki,
cw00.choi, jejb, martin.petersen, chanho61.park, ebiggers
Cc: linux-scsi, linux-phy, devicetree, linux-clk, linux-samsung-soc,
linux-kernel, linux-arm-kernel, tudor.ambarus, andre.draszik,
saravanak, willmcvicker
In-Reply-To: <20240404122559.898930-16-peter.griffin@linaro.org>
On 04/04/2024 14:25, Peter Griffin wrote:
> This allows these registers to be at different offsets or not
> exist at all on some SoCs variants.
>
> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> ---
> drivers/ufs/host/ufs-exynos.c | 38 ++++++++++++++++++++++++-----------
> drivers/ufs/host/ufs-exynos.h | 6 +++++-
> 2 files changed, 31 insertions(+), 13 deletions(-)
Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 14/17] scsi: ufs: host: ufs-exynos: allow max frequencies up to 267Mhz
From: Krzysztof Kozlowski @ 2024-04-05 7:58 UTC (permalink / raw)
To: Peter Griffin, mturquette, sboyd, robh, krzk+dt, conor+dt, vkoul,
kishon, alim.akhtar, avri.altman, bvanassche, s.nawrocki,
cw00.choi, jejb, martin.petersen, chanho61.park, ebiggers
Cc: linux-scsi, linux-phy, devicetree, linux-clk, linux-samsung-soc,
linux-kernel, linux-arm-kernel, tudor.ambarus, andre.draszik,
saravanak, willmcvicker
In-Reply-To: <20240404122559.898930-15-peter.griffin@linaro.org>
On 04/04/2024 14:25, Peter Griffin wrote:
> Platforms such as Tensor gs101 the pclk frequency is 267Mhz.
> Increase PCLK_AVAIL_MAX so we don't fail the frequency check.
>
> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> ---
Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 13/17] scsi: ufs: host: ufs-exynos: add EXYNOS_UFS_OPT_TIMER_TICK_SELECT option
From: Krzysztof Kozlowski @ 2024-04-05 7:58 UTC (permalink / raw)
To: Peter Griffin, mturquette, sboyd, robh, krzk+dt, conor+dt, vkoul,
kishon, alim.akhtar, avri.altman, bvanassche, s.nawrocki,
cw00.choi, jejb, martin.petersen, chanho61.park, ebiggers
Cc: linux-scsi, linux-phy, devicetree, linux-clk, linux-samsung-soc,
linux-kernel, linux-arm-kernel, tudor.ambarus, andre.draszik,
saravanak, willmcvicker
In-Reply-To: <20240404122559.898930-14-peter.griffin@linaro.org>
On 04/04/2024 14:25, Peter Griffin wrote:
> This option is intended to be set for SoCs that have HCI_V2P1_CTRL
> register and can select their tick source via IA_TICK_SEL bit.
>
> Source clock selection for timer tick
> 0x0 = Bus clock (aclk)
> 0x1 = Function clock (mclk)
>
> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> ---
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 12/17] scsi: ufs: host: ufs-exynos: Add EXYNOS_UFS_OPT_UFSPR_SECURE option
From: Krzysztof Kozlowski @ 2024-04-05 7:57 UTC (permalink / raw)
To: Peter Griffin, mturquette, sboyd, robh, krzk+dt, conor+dt, vkoul,
kishon, alim.akhtar, avri.altman, bvanassche, s.nawrocki,
cw00.choi, jejb, martin.petersen, chanho61.park, ebiggers
Cc: linux-scsi, linux-phy, devicetree, linux-clk, linux-samsung-soc,
linux-kernel, linux-arm-kernel, tudor.ambarus, andre.draszik,
saravanak, willmcvicker
In-Reply-To: <20240404122559.898930-13-peter.griffin@linaro.org>
On 04/04/2024 14:25, Peter Griffin wrote:
> This option is intended to be set on platforms whose ufspr
> registers are only accessible via smc call (such as gs101).
>
> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 11/17] phy: samsung-ufs: ufs: Add support for gs101 UFS phy tuning
From: Krzysztof Kozlowski @ 2024-04-05 7:57 UTC (permalink / raw)
To: Peter Griffin, mturquette, sboyd, robh, krzk+dt, conor+dt, vkoul,
kishon, alim.akhtar, avri.altman, bvanassche, s.nawrocki,
cw00.choi, jejb, martin.petersen, chanho61.park, ebiggers
Cc: linux-scsi, linux-phy, devicetree, linux-clk, linux-samsung-soc,
linux-kernel, linux-arm-kernel, tudor.ambarus, andre.draszik,
saravanak, willmcvicker
In-Reply-To: <20240404122559.898930-12-peter.griffin@linaro.org>
On 04/04/2024 14:25, Peter Griffin wrote:
> Add the m-phy tuning values for gs101 UFS phy and SoC callbacks
> gs101_phy_wait_for_calibration() and gs101_phy_wait_for_cdr_lock().
>
> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> ---
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 10/17] phy: samsung-ufs: ufs: Add SoC callbacks for calibration and clk data recovery
From: Krzysztof Kozlowski @ 2024-04-05 7:56 UTC (permalink / raw)
To: Peter Griffin, mturquette, sboyd, robh, krzk+dt, conor+dt, vkoul,
kishon, alim.akhtar, avri.altman, bvanassche, s.nawrocki,
cw00.choi, jejb, martin.petersen, chanho61.park, ebiggers
Cc: linux-scsi, linux-phy, devicetree, linux-clk, linux-samsung-soc,
linux-kernel, linux-arm-kernel, tudor.ambarus, andre.draszik,
saravanak, willmcvicker
In-Reply-To: <20240404122559.898930-11-peter.griffin@linaro.org>
On 04/04/2024 14:25, Peter Griffin wrote:
> Some SoCs like gs101 don't fit in well with the existing pll lock and
> clock data recovery (CDR) callback used by existing exynos platforms.
>
> Allow SoCs to specifify and implement their own calibration and CDR
> functions that can be called by the generic samsung phy code.
>
> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> ---
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 2/2] arm64: dts: mediatek: mt7988: add XHCI controllers
From: AngeloGioacchino Del Regno @ 2024-04-05 7:56 UTC (permalink / raw)
To: Rafał Miłecki, Matthias Brugger, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: Chunfeng Yun, Greg Kroah-Hartman, Daniel Golle, linux-usb,
linux-arm-kernel, linux-mediatek, devicetree, linux-kernel,
Rafał Miłecki
In-Reply-To: <20240213130044.1976-2-zajec5@gmail.com>
Il 13/02/24 14:00, Rafał Miłecki ha scritto:
> From: Rafał Miłecki <rafal@milecki.pl>
>
> Add bindings of two on-SoC XHCI controllers.
>
> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
^ permalink raw reply
* Re: [PATCH 08/17] clk: samsung: gs101: add support for cmu_hsi2
From: Krzysztof Kozlowski @ 2024-04-05 7:55 UTC (permalink / raw)
To: Peter Griffin, mturquette, sboyd, robh, krzk+dt, conor+dt, vkoul,
kishon, alim.akhtar, avri.altman, bvanassche, s.nawrocki,
cw00.choi, jejb, martin.petersen, chanho61.park, ebiggers
Cc: linux-scsi, linux-phy, devicetree, linux-clk, linux-samsung-soc,
linux-kernel, linux-arm-kernel, tudor.ambarus, andre.draszik,
saravanak, willmcvicker
In-Reply-To: <20240404122559.898930-9-peter.griffin@linaro.org>
On 04/04/2024 14:25, Peter Griffin wrote:
> CMU_HSI2 is the clock management unit used for the hsi2 block.
> HSI stands for High Speed Interface and as such it generates
> clocks for PCIe, UFS and MMC card.
>
> This patch adds support for the muxes, dividers, and gates in
> cmu_hsi2.
>
> CLK_GOUT_HSI2_HSI2_CMU_HSI2_PCLK is marked as CLK_IS_CRITICAL
> as disabling it leads to an immediate system hang.
>
> CLK_GOUT_HSI2_SYSREG_HSI2_PCLK is also marked CLK_IS_CRITICAL.
> A hang is not observed with fine grained clock control, but
> UFS IP does not function with syscon controlling this clock
> just around hsi2_sysreg register accesses.
>
> CLK_GOUT_HSI2_GPIO_HSI2_PCLK is marked CLK_IGNORE_UNUSED until
> the exynos pinctrl clock patches land then it can be removed.
>
> Some clocks in this unit have very long names. To help with this
> the clock name mangling strategy was updated to include removing
> the following sub-strings.
> - G4X2_DWC_PCIE_CTL_
> - G4X1_DWC_PCIE_CTL_
> - PCIE_SUB_CTRL_
> - INST_0_
> - LN05LPE_
> - TM_WRAPPER_
> - SF_
>
> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
>
> ---
> Updated regex for clock name mangling
> sed \
> -e 's|^PLL_LOCKTIME_PLL_\([^_]\+\)|fout_\L\1_pll|' \
> \
> -e 's|^PLL_CON0_MUX_CLKCMU_\([^_]\+\)_\(.*\)|mout_\L\1_\2|' \
> -e 's|^PLL_CON0_PLL_\(.*\)|mout_pll_\L\1|' \
> -e 's|^CLK_CON_MUX_MUX_CLK_\(.*\)|mout_\L\1|' \
> -e '/^PLL_CON[1-4]_[^_]\+_/d' \
> -e '/^[^_]\+_CMU_[^_]\+_CONTROLLER_OPTION/d' \
> -e '/^CLKOUT_CON_BLK_[^_]\+_CMU_[^_]\+_CLKOUT0/d' \
> \
> -e 's|_IPCLKPORT||' \
> -e 's|_RSTNSYNC||' \
> -e 's|_G4X2_DWC_PCIE_CTL||' \
> -e 's|_G4X1_DWC_PCIE_CTL||' \
> -e 's|_PCIE_SUB_CTRL||' \
> -e 's|_INST_0||g' \
> -e 's|_LN05LPE||' \
> -e 's|_TM_WRAPPER||' \
> -e 's|_SF||' \
> \
> -e 's|^CLK_CON_DIV_DIV_CLK_\([^_]\+\)_\(.*\)|dout_\L\1_\2|' \
> \
> -e 's|^CLK_CON_BUF_CLKBUF_\([^_]\+\)_\(.*\)|gout_\L\1_\2|' \
> -e 's|^CLK_CON_GAT_CLK_BLK_\([^_]\+\)_UID_\(.*\)|gout_\L\1_\2|' \
> -e 's|^gout_[^_]\+_[^_]\+_cmu_\([^_]\+\)_pclk$|gout_\1_\1_pclk|' \
> -e 's|^CLK_CON_GAT_GOUT_BLK_\([^_]\+\)_UID_\(.*\)|gout_\L\1_\2|' \
> -e 's|^CLK_CON_GAT_CLK_\([^_]\+\)_\(.*\)|gout_\L\1_clk_\L\1_\2|' \
> \
> -e '/^\(DMYQCH\|PCH\|QCH\|QUEUE\)_/d'
> ---
> drivers/clk/samsung/clk-gs101.c | 558 +++++++++++++++++++++++
> include/dt-bindings/clock/google,gs101.h | 63 +++
Bindings are separate patches.
> 2 files changed, 621 insertions(+)
>
> diff --git a/drivers/clk/samsung/clk-gs101.c b/drivers/clk/samsung/clk-gs101.c
> index d065e343a85d..b9f84c7d5c22 100644
> --- a/drivers/clk/samsung/clk-gs101.c
> +++ b/drivers/clk/samsung/clk-gs101.c
> @@ -22,6 +22,7 @@
> #define CLKS_NR_MISC (CLK_GOUT_MISC_XIU_D_MISC_ACLK + 1)
> #define CLKS_NR_PERIC0 (CLK_GOUT_PERIC0_SYSREG_PERIC0_PCLK + 1)
> #define CLKS_NR_PERIC1 (CLK_GOUT_PERIC1_SYSREG_PERIC1_PCLK + 1)
> +#define CLKS_NR_HSI2 (CLK_GOUT_HSI2_XIU_P_HSI2_ACLK + 1)
>
> /* ---- CMU_TOP ------------------------------------------------------------- */
>
> @@ -3409,6 +3410,560 @@ static const struct samsung_cmu_info peric1_cmu_info __initconst = {
> .clk_name = "bus",
> };
>
> +/* ---- CMU_HSI2 ---------------------------------------------------------- */
> +
> +/* Register Offset definitions for CMU_HSI2 (0x14400000) */
> +#define PLL_CON0_MUX_CLKCMU_HSI2_BUS_USER 0x0600
> +#define PLL_CON1_MUX_CLKCMU_HSI2_BUS_USER 0x0604
> +#define PLL_CON0_MUX_CLKCMU_HSI2_MMC_CARD_USER 0x0610
> +#define PLL_CON1_MUX_CLKCMU_HSI2_MMC_CARD_USER 0x0614
> +#define PLL_CON0_MUX_CLKCMU_HSI2_PCIE_USER 0x0620
> +#define PLL_CON1_MUX_CLKCMU_HSI2_PCIE_USER 0x0624
> +#define PLL_CON0_MUX_CLKCMU_HSI2_UFS_EMBD_USER 0x0630
> +#define PLL_CON1_MUX_CLKCMU_HSI2_UFS_EMBD_USER 0x0634
> +#define HSI2_CMU_HSI2_CONTROLLER_OPTION 0x0800
> +#define CLKOUT_CON_BLK_HSI2_CMU_HSI2_CLKOUT0 0x0810
> +#define CLK_CON_GAT_CLK_BLK_HSI2_UID_PCIE_GEN4_1_IPCLKPORT_PCIE_003_PCIE_SUB_CTRL_INST_0_PHY_REFCLK_IN 0x2000
> +#define CLK_CON_GAT_CLK_BLK_HSI2_UID_PCIE_GEN4_1_IPCLKPORT_PCIE_004_PCIE_SUB_CTRL_INST_0_PHY_REFCLK_IN 0x2004
> +#define CLK_CON_GAT_CLK_BLK_HSI2_UID_SSMT_PCIE_IA_GEN4A_1_IPCLKPORT_ACLK 0x2008
> +#define CLK_CON_GAT_CLK_BLK_HSI2_UID_SSMT_PCIE_IA_GEN4A_1_IPCLKPORT_PCLK 0x200c
> +#define CLK_CON_GAT_CLK_BLK_HSI2_UID_SSMT_PCIE_IA_GEN4B_1_IPCLKPORT_ACLK 0x2010
> +#define CLK_CON_GAT_CLK_BLK_HSI2_UID_SSMT_PCIE_IA_GEN4B_1_IPCLKPORT_PCLK 0x2014
> +#define CLK_CON_GAT_GOUT_BLK_HSI2_UID_D_TZPC_HSI2_IPCLKPORT_PCLK 0x201c
> +#define CLK_CON_GAT_GOUT_BLK_HSI2_UID_GPC_HSI2_IPCLKPORT_PCLK 0x2020
> +#define CLK_CON_GAT_GOUT_BLK_HSI2_UID_GPIO_HSI2_IPCLKPORT_PCLK 0x2024
> +#define CLK_CON_GAT_GOUT_BLK_HSI2_UID_HSI2_CMU_HSI2_IPCLKPORT_PCLK 0x2028
> +#define CLK_CON_GAT_GOUT_BLK_HSI2_UID_LHM_AXI_P_HSI2_IPCLKPORT_I_CLK 0x202c
> +#define CLK_CON_GAT_GOUT_BLK_HSI2_UID_LHS_ACEL_D_HSI2_IPCLKPORT_I_CLK 0x2030
> +#define CLK_CON_GAT_GOUT_BLK_HSI2_UID_MMC_CARD_IPCLKPORT_I_ACLK 0x2034
> +#define CLK_CON_GAT_GOUT_BLK_HSI2_UID_MMC_CARD_IPCLKPORT_SDCLKIN 0x2038
> +#define CLK_CON_GAT_GOUT_BLK_HSI2_UID_PCIE_GEN4_1_IPCLKPORT_PCIE_003_G4X2_DWC_PCIE_CTL_INST_0_DBI_ACLK_UG 0x203c
> +#define CLK_CON_GAT_GOUT_BLK_HSI2_UID_PCIE_GEN4_1_IPCLKPORT_PCIE_003_G4X2_DWC_PCIE_CTL_INST_0_MSTR_ACLK_UG 0x2040
> +#define CLK_CON_GAT_GOUT_BLK_HSI2_UID_PCIE_GEN4_1_IPCLKPORT_PCIE_003_G4X2_DWC_PCIE_CTL_INST_0_SLV_ACLK_UG 0x2044
> +#define CLK_CON_GAT_GOUT_BLK_HSI2_UID_PCIE_GEN4_1_IPCLKPORT_PCIE_003_PCIE_SUB_CTRL_INST_0_I_DRIVER_APB_CLK 0x2048
> +#define CLK_CON_GAT_GOUT_BLK_HSI2_UID_PCIE_GEN4_1_IPCLKPORT_PCIE_004_G4X1_DWC_PCIE_CTL_INST_0_DBI_ACLK_UG 0x204c
> +#define CLK_CON_GAT_GOUT_BLK_HSI2_UID_PCIE_GEN4_1_IPCLKPORT_PCIE_004_G4X1_DWC_PCIE_CTL_INST_0_MSTR_ACLK_UG 0x2050
> +#define CLK_CON_GAT_GOUT_BLK_HSI2_UID_PCIE_GEN4_1_IPCLKPORT_PCIE_004_G4X1_DWC_PCIE_CTL_INST_0_SLV_ACLK_UG 0x2054
> +#define CLK_CON_GAT_GOUT_BLK_HSI2_UID_PCIE_GEN4_1_IPCLKPORT_PCIE_004_PCIE_SUB_CTRL_INST_0_I_DRIVER_APB_CLK 0x2058
> +#define CLK_CON_GAT_GOUT_BLK_HSI2_UID_PCIE_GEN4_1_IPCLKPORT_PCS_PMA_INST_0_PHY_UDBG_I_APB_PCLK 0x205c
> +#define CLK_CON_GAT_GOUT_BLK_HSI2_UID_PCIE_GEN4_1_IPCLKPORT_PCS_PMA_INST_0_PIPE_PAL_PCIE_INST_0_I_APB_PCLK 0x2060
> +#define CLK_CON_GAT_GOUT_BLK_HSI2_UID_PCIE_GEN4_1_IPCLKPORT_PCS_PMA_INST_0_SF_PCIEPHY210X2_LN05LPE_QCH_TM_WRAPPER_INST_0_I_APB_PCLK 0x2064
Is it doable to use shorter register names while still keeping them
close to datasheet/manual? This one is a bit too much... actually most
of them are quite too much. :)
...
> +
> /* ---- platform_driver ----------------------------------------------------- */
>
> static int __init gs101_cmu_probe(struct platform_device *pdev)
> @@ -3432,6 +3987,9 @@ static const struct of_device_id gs101_cmu_of_match[] = {
> }, {
> .compatible = "google,gs101-cmu-peric1",
> .data = &peric1_cmu_info,
> + }, {
> + .compatible = "google,gs101-cmu-hsi2",
> + .data = &hsi2_cmu_info,
Keep these also alphabetically ordered by compatible.
Best regards,
Krzysztof
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox